25 juin 2019

Retour sur le Hack In Paris – 9e édition – Jour 2

IronPython… OMFG V2.0

Par Marcello Slavati

Marcello Salvati, un chercheur/développeur en sécurité offensive bien connu dans ce domaine, fait une présentation sur IronPython et les autres langages tel que BooLang permettant d’utiliser le framework .NET. Cette utilisation repose sur le principe de CLR (Common Language Runtime), l’équivalent de la machine virtuelle Java JVM.

L’avantage lors de l’utilisation de langages .NET tierce est de contourner les défenses mises en place par le PowerShell. En effet, étant donné que ce dernier est utilisé depuis des années afin de réaliser des attaques en phase de post exploitation, Microsoft a renforcé ses « défenses » et il est désormais plus difficile de passer inaperçu. Ces langages tiers permettent ainsi d’exécuter du code PowerShell sans passer par l’exécutable natif, et reste seulement en mémoire.

Marcello fait donc la présentation de quelques charges malveillantes (payloads) avec ces langages. Il commence par l’implémentation Python, appelé IronPython, et conclut que celui-ci n’est pas le plus adapté, car l’appel de fonctions natives .NET intégrées dans un script ne fonctionne pas.

Par la suite, il nous parle de BooLang et de ClearScript, qui permettent d’appeler des fonctions natives .NET. Voici un exemple de code ClearScript permettant de faire apparaitre une calculatrice :

Il conclut la présentation en parlant du fait qu’il existe de nombreux langages tiers .NET et qu’il y a de nombreuses possibilités, mais qu’il faut plus de recherche dans ce domaine.

Les payloads offensifs créés par Marcello sont disponibles à cette adresse : https://github.com/byt3bl33d3r/OffensiveDLR

Enfin, il présente également un outil permettant d’automatiser l’utilisation de ces derniers : https://github.com/byt3bl33d3r/SILENTTRINITY

Abusing Google Play billing for fun and unlimited credits!

Par Guillaume Lopes

Au cours de cette présentation, Guillaume montre que l’implémentation de certaines applications faisant appel à l’API de paiement de Google Play sont vulnérables. Le défaut de sécurité permet sur certaines applications telles que Snoopy pop, Fruit Ninja ou Doodle jump de ne pas aller jusqu’au bout du paiement tout en obtenant des crédits dans ces applications.

Le fonctionnement simplifié de la réalisation d’un paiement depuis une application Android a dans un premier temps été présenté. Celui-ci se compose des étapes suivantes :

  1. L’utilisateur initie la demande de paiement depuis l’application
  2. L’application effectue une requête de paiement à l’application Google Play en intégrant son iFrame
  3. L’utilisateur entre dans l’iFrame de Google Play ses données bancaires (numéros de carte de crédit, compte Paypal, etc.) nécessaires pour la réalisation du paiement
  4. L’application cliente Google Play communique ces informations au back end de Google Play, qui lui renvoie un objet JSON contenant les informations permettant de savoir si le paiement a pu être correctement effectué.
  5. Ce fichier est ensuite transmis à l’application qui se charge de vérifier avec le serveur de Google Play que le paiement a bien été validé.

L’objet JSON est signé par le serveur de Google Play utilisant sa clé privée. Pour vérifier la signature, il suffit d’utiliser la clé publique du serveur. Il est fortement conseillé de vérifier la signature côté serveur. Cependant, certaines applications font cette vérification côté client. Le problème qui se pose est qu’un attaquant peut vérifier un paiement en suivant les étapes présentées ci-dessous :

Par ailleurs, certaines bibliothèques, tel que Unity, possèdent également ce défaut. L’utilisation de ces bibliothèques au sein d’une application la rendent vulnérable comme Guillaume a pu le montrer avec l’application Fruit Ninja.

Thomas Zellner

Thomas ZELLNER : Consultant BSSI

Laisser un commentaire

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