Lambda malware : the hidden threat in excel spreadsheets – Yonatan Baum, Daniel Wolfman
https://lehack.org/fr/track/lambda-malware-the-hidden-threat-in-excel-spreadsheets/
Yonatan Baum et Daniel Wolfman présentent leurs recherches autour de la fonction Excel Lambda. Leur objectif est de trouver une nouvelle méthode d’attaque via Excel qui ne serait pas détectée par VirusTotal. Ce type d’attaque par ingénierie sociale demandant à un utilisateur d’ouvrir un fichier avec du code malveillant fonctionne en effet encore aujourd’hui.
La fonction Lambda est tout d’abord présentée : elle permet de ne pas écrire de code, et, sans passer par le VBA, de mettre en place des fonctions personnalisées. Des formules peuvent être utilisées et sont réutilisables dans d’autres contextes. Le tout est présenté comme très simple d’utilisation.
Une question se pose alors : l’utiliser à des fins malveillantes est-il possible ?
Les chercheurs se posent l’objectif suivant :
- Infecter une machine avec un fichier joint malveillant
- Utiliser Lambda
- Ne pas être détecté
Les contraintes de l’environnement sont : macros activées, exécution d’un powershell malveillant pour le POC, VirusTotal pour les tests de détection et pas de sandbox.
Un test témoin est donc réalisé, avec l’insertion d’une macro classique dans un fichier Excel : 17 détections sur VirusTotal.
Un premier test est effectué avec l’utilisation de GetPayload() pour récupérer un code du type « LAMBDA(“powershell…”) » : 7 détections sur VirusTotal.
Un second test consistant à chiffrer par chiffrement asymétrique la ligne d’exécution de la payload est ajouté. Le point d’entrée de l’exécution est un decrypt de cette ligne : 2 détections sur VirusTotal.
Les chercheurs tentent alors d’utiliser Lambda et du VBA.
Dans un fichier Excel, Lambda sert à récupérer un script VBA en ligne. Ce script permet de télécharger un fichier zip (fonction utilisée régulièrement, même par des éléments non malveillants). Lambda exécute ensuite le script présent dans le zip. Ce script est déjà sur le système et n’est donc pas considéré comme une menace. L’accès via un shell distant est alors obtenu : 0 détection sur VirusTotal.
Yonatan Baum et Daniel Wolfman ne connaissent pas de malware qui utilise Lambda à l’heure actuelle. Ils rappellent cependant que les tests n’ont été effectués qu’avec de l’analyse statique. Avec de l’analyse dynamique, ou en sandbox, des comportements similaires auraient pu être détectés, mais cela coûte cher et demande du temps et des ressources.
Parasitage de serveur for fun and profit – Damien Cauquil
https://lehack.org/fr/track/parasitage-de-serveur-for-fun-and-profit/
Damien Cauquil de Quarkslab nous présente des recherches sur le stockage de données en ligne et les méthodes détournées et indésirables pour le faire.
Le stockage cloud apporte une notion de responsabilité à la personne qui héberge les données. C’est un système avec de nombreuses contraintes, dont celle du coût.
La solution est le stockage en ligne sur des partages de fichiers. Mozilla a permis cela via Firefox Send pour du stockage temporaire, mais a stoppé ce service.
Les recherches se tournent donc vers le parasitage de serveur afin d’héberger des données sans ces contraintes.
De nombreuses possibilités existent, par exemple, l’utilisation d’images comme vecteur pour contenir des fichiers, tout comme on peut le voir sur imgur. Damien Cauquil fait d’ailleurs référence à la conférence d’Angel Albertini sur les formats de fichiers spéciaux (https://www.youtube.com/watch?v=hdCs6bPM4is) et l’obfuscation de données via cette méthode.
Finalement, il aborde le point central de sa conférence : la manipulation des sessions web.
Les cookies ont une certaine durée de vie dans le navigateur allant en moyenne de 16 à plus de 30 jours. Elles sont supprimées côté utilisateur, mais pas côté serveur.
Des informations encodées en base64 peuvent être injectées en grande quantité dans des champs d’input. Un test a été réalisé avec 300 kilo-octets. Firefox permet d’effectuer cette interaction plus rapidement que chrome, et c’est un évènement qui est rarement monitoré.
Ces informations peuvent ensuite être récupérées via le cookie de session. Le cookie-manager du serveur distant est donc utilisé pour stocker des informations.
Un utilisateur pourrait ainsi stocker des fichiers de façon indésirable et y accéder en conservant et utilisant seulement des cookies de sessions. De plus, passer ces derniers lui permettrait de partager les données avec un autre utilisateur.
Le temps de stockage de l’information sur le serveur n’est pas connu et la taille est sans doute limitée.
Ce type d’action peut permettre de :
- Provoquer un déni de service
- Stocker et/ou partager des fichiers
- Stocker de façon non sollicité (pédopornographie ou autre)
- Passer des C2 (imgur a déjà été utilisé pour passer des commandes)
Beaucoup de sites vulnérables ont été reportés.
Damien Cauquil conclut sa conférence par un rappel à la loi, avec un focus sur les articles 323-1, 323-2 et 323-3 du code pénal et sur l’illégalité de ce genre d’action.
Du driver Windows à l’EDR – Aurélien Chalot
https://lehack.org/fr/track/du-driver-windows-a-ledr/
Aurélien Chalot, hackeur et chercheur en sécurité chez Orange CyberDéfense, nous a présenté ses recherches autour des méthodes de détection de logiciels malveillants et du développement de driver Windows.
La première partie de cette conférence a servi d’introduction aux mécanismes de détection statique, via notamment une analyse heuristique (nom de l’exécutable, métadata) ou grâce aux signatures (hash). Ces techniques sont assez rudimentaires, et ne permettent pas une analyse très poussée du comportement d’un programme. Les développeurs de solutions de sécurité ont donc eu l’idée de récupérer diverses informations directement au sein du kernel. Tout ceci a pris fin en 2006 suite à l’implémentation de PatchGuard, empêchant l’accès aux différentes structures du noyau.
En réponse aux vives protestations et menaces de procès de la part d’entreprises comme Symantec ne pouvant plus commercialiser leurs produits, Microsoft a mis à disposition les callback objects, permettant de recevoir des notifications de la part du noyau Windows si certaines conditions sont réunies. Les deuxièmes et troisièmes parties de la conférence ont porté sur la présentation du concept de driver Windows ainsi que l’implémentation de kernel callbacks au travers d’un exemple simple (monitoring de la création d’un processus et détection de mimikatz).
Les EDR sont des logiciels hautement complexes et la programmation de driver est très sensible, la moindre erreur provoquant un crash du noyau et donc de la machine. La solution suivante présentée dans l’avant-dernière partie de la conférence a donc majoritairement été adoptée : développer un driver récupérant divers évènements depuis le noyau, puis une multitude d’outils (agents) servant à effectuer des analyses (statique, mémoire, …) permettant, ou non, la poursuite de l’exécution. Il est également possible de modifier NTDLL.ddl, dernière frontière entre user et kernel space afin de monitorer dynamiquement les fonctions de l’API Windows appelées par différents programmes et détecter un potentiel comportement malveillant.
La conférence se termine sur une démonstration de l’EDR développé pour l’occasion ainsi que la présentation d’un challenge dont l’objectif est d’injecter du shellcode dans un processus notepad, et donc de contourner la détection.
Prototype pollution and where to find them
https://lehack.org/track/prototype-pollution-and-where-to-find-them/
Lors de cette présentation, BitK et SakiiR nous ont tout d’abord donné un aperçu de ce que sont les prototypes JavaScript ainsi que les attaques par pollution pouvant être menées sur eux. Ils ont ensuite présenté un de leur outil permettant d’identifier les morceaux de code exploitables avec ces attaques. Puis, ils ont terminé avec une démonstration de cet outil sur des bibliothèques JavaScript populaires.
Dans un premier temps, ils nous ont expliqué que les prototypes en JavaScript sont un mécanisme permettant de faire hériter des propriétés d’un objet à un autre.
Puis, à travers un exemple, il nous est présenté ce qu’est une attaque par pollution. On y apprend que si un utilisateur malveillant peut écrire dans le prototype d’un objet A alors il peut modifier la propriété d’un autre objet B si l’objet B a le même prototype que l’objet A.
Ainsi un attaquant peut prendre le contrôle des valeurs par défaut des propriétés des objets et, dans le pire cas, d’exécuter du code à distance sur les applications vulnérables.
Ils ont continué avec la présentation de leur outil « pp-finder » permettant d’identifier les « gadgets » (morceaux de code) exploitables avec les attaques par pollution de prototypes. Pour cela, ils ont créé un module qui sera chargé avant tous les autres et qui permet d’injecter des « hooks » (points d’ancrage). Grâce à ce module, ils peuvent notamment contrôler et modifier les fonctions qui importent les bibliothèques, pour analyser leur code en tant réel et ainsi détecter des gadgets vulnérables.
Et enfin, ils ont terminé avec une démonstration de leur outil avec un exemple dans lequel la bibliothèque « express » est utilisée pour héberger un simple site Web, qui renvoie juste un message lors de son accès.
À partir de ce simple exemple, au moins 30 gadgets semblent être vulnérables. Ils nous précisent néanmoins qu’ils ne sont tous pas forcément exploitable et qu’un travail manuel est nécessaire pour vérifier leur exploitabilité.
C’est un outil très intéressant qui peut permettre de faciliter les audits « whitebox » en aidant les chercheurs à identifier facilement les vulnérabilités dans de nombreuses lignes de code.
Il est disponible en open source sur github : https://github.com/yeswehack/pp-finder.
