Improving custom shellcode detection

La détection de shellcode a toujours été notre manière d’appréhender des 0-days.

Nous considérons qu’il est impossible de détecter des 0-days, étant par définition totalement imprédictible :

  • Chaque 0-days aura une forme différente suivant la vulnérabilité.
  • Chaque personne qui codera un exploit le fera différemment suivant la vulnérabilité.

Le seul moyen qui nous semble intéressant concerne la détection du PAYLOAD qui sera forcément injecté dans l’exploitation de la vulnérabilité.

Plusieurs problématiques existent et demandent beaucoup de R&D à nos équipes afin d’être le plus exhaustifs possible.

Pour rappel, voici ce que nous traitons déjà :

  1. Attaques en ROP (BROP / SROP / etc) : permet d’éviter l’injection de shellcode directement (traité par CODEBREAKER en v2 via la détection des gadgets). En attente de la version 2.5.3 pour passer du statut expérimental à « Production ready »
  2. Attaques avec des shellcodes polymorphes encodés (CODEBREAKER détecte l’encodage et désassemble en temps réel) puis tente une « translation » du shellcode (voir les articles sur Shikata Ganai par exemple)
  3. Shellcode public : une simple règle (REGEX ou autre) fait l’affaire (oui oui ! Il en existent encore qui font ça…)
  4. Shellcode Custom (générateur de shellcode ou conception manuelle) : CODEBREAKER détecte désormais ce type d’attaque sous Linux et Windows X86 (la partie linux X86 est encore en expérimentale… donc désactivé par défaut)

 

Depuis le début, la détection des shellcodes encodés ne produit aucun faux positif. Le problème des shellcodes Custom est qu’il existe des milliards de possibilités, et que plus les flux sont aléatoires, plus les faux positifs deviennent probables. Typiquement, plusieurs clients nous ont remonté des shellcodes Custom sur des flux type IPSEC ou SSL (aléa maximum à cause du chiffrement).

En conséquence, nous avons amélioré, dans la version 2.5.1, la détection des shellcodes Custom avec la détection des faux positifs potentiels pour aider à la décision. Pour cela, on détecte les arguments (args des SYSCALL par exemple) qui semblent invalides. Nous avons donc poussé le concept jusqu’à extraire les arguments des appels système afin de vérifier leur validité : un algorithme vérifie alors les positions des registres (en émulation) afin de comprendre si cela suit une logique déterministe.

Ainsi voici deux exemples :

Les arguments parlent d’eux-mêmes…

Voici un faux-positif :

Au-delà de provoquer une erreur dans l’émulation, on voit bien que les arguments sont invalides et nous indiquons aux exploitants la forte possibilité de faux-positifs.

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

17 − douze =