La brêche

Étape 1 – Analyse du binaire svc_updater (présent sur le serveur NAS)

Pour répondre à la première question, il faut décompiler et analyser le binaire svc_updater.
Pour ce faire, nous allons utiliser un outil tel que Ghidra.

Une fois le binaire chargé dans Ghidra, nous pouvons commencer à explorer sa structure et son fonctionnement. On remarque rapidement que quasiment l’intégralité du code se trouve dans la fonction main.

Après analyse et lecture du code, on observe que plusieurs fonctions permettant de binder un socket sont utilisées.
Après avoir consulté la documentation afin de comprendre comment fonctionne le bind d’un socket, on s’intéresse plus particulièrement à la fonction getaddrinfo() et à ses paramètres.

D’après la documentation, le troisième argument de la fonction getaddrinfo() est un pointeur vers une structure addrinfo, qui contient des informations sur l’adresse à laquelle le socket doit être liée.

Notamment, le protocole utilisé pour le socket est spécifié dans le champ ai_protocol de cette structure

La variable local_138 est un pointeur vers une structure addrinfo qui contient des informations sur l’adresse de liaison du socket.
Grâce à la documentation de la structure addrinfo, on peut identifier les valeurs suivantes :

3 correspond à SOCK_RAW

1 correspond au protocole Internet Control Message Protocol

10 correspond à AF_INET6, ce qui signifie que le socket est de type IPv6

0x3a correspond à 58, la valeur associée à Internet Control Message Protocol v6

Cela nous permet de déterminer avec précision le protocole utilisé par le socket.

Étape 2 – Analyse du binaire data_handler (présent sur le PC d’Alysson) et découverte du mot de passe

Dans un premier temps, nous allons exécuter le binaire data_handler avec un argument pour observer son comportement

On observe que le binaire réagit et affiche un message d’erreur "Incorrect password".
On va donc décompiler le binaire avec Ghidra pour trouver cette chaine de caractères et essayer de trouver le mot de passe.

Une fois la chaine de caractères localisée, on remonte le code et on observe que la fonction is_correct_password est appelée

En analysant cette fonction, on remarque 4 fonctions qui attirent notre attention :

En analysant la première fonction on observe plusieurs valeurs qui sont stockées dans un tableau

Quand on regarde la correspondance des valeurs dans la table ASCII on remarque que seuls les éléments stockés dans la variable
local_78 sont des caractères ASCII qui correspondent à _event

Nous allons donc analyser les autres fonctions pour comprendre comment récuperer les valeurs.

Dans la première fonction, on observe un XOR avec la valeur 0x42

Nous observons une loop qui va de 0 à 4, on peut donc déduire que un caractère ascii xoré avec 0x42 donne les premiers caractères du mot de passe.
En reprenant les valeurs du tableau, on trouve les 4 premiers caractères du mot de passe : F1C_.

Dans la deuxième fonction, on observe un XOR avec la valeur 0x39

Dans cette fonction, la loop va de 4 à 19, on peut donc déduire qu'un caractère ascii xoré avec 0x39 donne les caractères du mot de passe de la 5ᵉ à la 19ᵉ position.
En reprenant les valeurs du tableau, on trouve les caractères du mot de passe de la 5ᵉ à la 19ᵉ position : What_an_amazing.

Étape 3 – Découverte de l'url d'exfiltration

Plus loin de la fonction main on peut apercevoir une fonction qui s'appelle send_data

En examinant la fonction send_data, on peut observer une commande curl effectuée

On sait que curl nous permet de faire des requêtes HTTP ou des requêtes HTTP secure, ce qui nous laisse le choix.
Il suffit donc de déterminer vers quelle URL est envoyée la donnée.

Plus haut dans la fonction on peut voir une variable se nommant url_xor qui se fait xorée avec la valeur 0x5a

En déchiffrant le xor, on peut obtenir l'url complète.

Étape 4 – Identification de l’attaquant

Grâce au déchiffrement de l'url à l'étape 3, cela nous permet de voir dans l'url le nom de l'attaque.
Car l'api github est composée de https://api.github.com/repos///issues.