Het is geweldig om te zien dat het vastzetten van certificaten steeds meer wordt toegepast in Android-apps. Wanneer ik een app tegenkom die verbindingsfouten genereert terwijl ik probeer verzoeken te proxyen, raak ik meer geïnteresseerd in dieper duiken. Dat was het geval toen ik onlangs de Subway-app gebruikte. Het terugdraaien van de APK bracht cert-pinning aan het licht, naast enkele andere interessante bevindingen.
Het starten van de app tijdens het proxyen van verzoeken veroorzaakte deze fout:
Vastzetten is eenvoudig genoeg om te omzeilen. Ik begon met het decompileren van de app en het analyseren van de broncode voor het vastzetten van trefwoorden. Ik vond feitelijk vastgezette implementaties in twee afzonderlijke klassen die werden geïmplementeerd X509TrustManager. Hier is een van de methoden die vastzetten afdwingen:
// Code removed at request of Subway leadership
Dit omzeilen was net zo eenvoudig als het toevoegen van een return-instructie in de smali-code om de pincode in de bovenstaande methode over te slaan. Let op de toevoeging van de retour-nietig verklaring hieronder:
// Code removed at request of Subway leadership
Nadat ik de app opnieuw had gecompileerd en geïnstalleerd, was ik verrast toen ik deze nieuwe fout zag:
Subway gebruikte een aangepast verificatieproces voor app-handtekeningen om te voorkomen dat de APK ongedaan werd gemaakt. Ik pakte de bron voor vermeldingen van dit proces en traceerde het terug naar de volgende methode:
// Code removed at request of Subway leadership
Dit was een interessante poging om reverse engineering te voorkomen, hoewel het feitelijk slechts een kleine vertraging veroorzaakte. Om dit proces te omzeilen, heb ik eenvoudigweg een regel toegevoegd om de uitvoering van de methode over te slaan door een andere toe te voegen retour-nietig lijn, vergelijkbaar met het pinning-bypass-proces hierboven.
// Code removed at request of Subway leadership
Nadat ik de app opnieuw had gecompileerd en geïnstalleerd, kon ik met succes proxyverzoeken verwerken:
Tijdens mijn onderzoek kwam ik dit tegen dit Reddit-bericht. Blijkbaar was Subway ook aan het bepalen of het apparaat van de gebruiker was geroot. Ik zocht rond in de bron en bevestigde vermeldingen van rootdetectiemethoden.
// Code removed at request of Subway leadership
Dit is een goed voorbeeld van een app die beveiliging zeer serieus neemt, maar ik ben niet helemaal zeker van de redenering achter het rootcontroleproces. Hoewel technieken voor het vastzetten van certificaten en het verifiëren van handtekeningen over het algemeen een goed idee zijn, belemmeren ze het reverse engineering-proces slechts in geringe mate.