Décrypter les paquets TLS entre les applications Windows 8 et Azure

Question

view on stackexchange narkive permalink

Dans le développement d'applications Windows Store pour Windows 8, il existe une classe appelée remoteSettings qui permet à un développeur de stocker des lots de données afin que l'utilisateur y ait accès sur plusieurs machines, à condition qu'il soit connecté avec le même compte .

J'ai connecté WireShark et j'ai découvert que le paquet était stocké dans Azure et sécurisé avec TLS. Je voudrais moi-même MITM pour pouvoir déchiffrer le paquet et voir si les données sont chiffrées sur Azure.

Je n'ai évidemment pas la clé privée pour Azure, donc j'aimerais savoir si n'importe qui a une idée sur la façon de réaliser cette analyse MITM.

Answer 1

view on stackexchange narkive permalink

Une autre chose que vous pourriez faire, qui est peut-être exagérée mais qui est utile dans d'autres scénarios, est d'intercepter la création du secret principal TLS de 48 octets. Pour de nombreuses applications Windows (y compris IE), cela se produit dans lsass.exe dans la fonction suivante (tirée de Win7 SP1 32 bits):

  Appelant: ncrypt! _Tls1ComputeMasterKey @ 32 + 0x57 EIP: ncrypt! _PRF @ 40 + 0x11a  

Vous pouvez ensuite décrypter les paquets capturés après coup dans Wireshark en définissant (Pre) -Master-Secret log nom de fichier dans les préférences SSL à un fichier de fichier qui ressemble à:

  RSA session ID: 87492B3586DE289FAE1598B0A19CC7BCCB69371993F2C0DF32438034E06FE3FBMaster-clé: F58C0EFA2BF87602646B318400DFEB0C8CCDE59408C9F13C6D923F6208743BD34EA8BA17BCE02B9BD8DFED5A58036068  

La session L'ID ici peut être trouvé dans les en-têtes TLS (non chiffrés) du flux qui vous intéresse. (Ne vous laissez pas berner par le RSA - cela fonctionne pour toutes les connexions TLS quelle que soit la suite de chiffrement utilisée.)

L'avantage de cette méthode est que, puisque vous ne faites pas un homme au milieu, l'application cliente n'a pas à faire confiance à votre CA, qui est particulièrement pratique si vous essayez d'inverser certains logiciels malveillants qui font réellement de la cryptographie.

L'inconvénient est que vous devez pouvoir déboguer lsass.exe , ce qui peut être rusé; vous trouverez des informations sur la façon de procéder ici.

Answer 2

view on stackexchange narkive permalink

Si les données sont transmises en HTTPS, vous pouvez essayer l'approche classique de l'homme du milieu de Fiddler. Je ne sais pas si le magasin Windows respecte les paramètres du proxy ou s'il a un certificat épinglé. S'il respecte les paramètres du proxy, ce qu'il devrait, et qu'il n'a pas de certificat épinglé, vous devriez pouvoir le manipuler de manière triviale avec Fiddler.

Si les données ne sont pas ' t HTTPS et le certificat ne sont pas épinglés, une option est de proxy la connexion sécurisée en utilisant SSLNetcat. Ce que vous faites, c'est que vous modifiez votre fichier hosts afin que l'exécutable Store se connecte à SSLNetcat en cours d'exécution localement, puis vous configurez SSLNetcat de sorte qu'il utilise un certificat pour lequel vous avez la clé privée. Ensuite, il vous suffit de demander à SSLNetcat de transmettre les données directement à un programme de votre choix ou de saisir les clés privées dans Wireshark et de les utiliser pour renifler le trafic.

Si les données ne sont pas HTTPS, si le certificat est dans le binaire est épinglé et non stocké dans un fichier, vous pouvez soit patcher l'exécutable du Windows Store et remplacer le certificat par le vôtre pour lequel vous avez la clé privée. OpenSSL devrait être en mesure de générer facilement un certificat de remplacement pour vous. Cette clé privée peut ensuite être entrée dans Wireshark qui décryptera ensuite le trafic.

Vous êtes assez proche du territoire de protection contre la copie, vous pourriez donc rencontrer un certain nombre de complications.

Answer 3

view on stackexchange narkive permalink

Il existe un certain nombre d'approches que vous pouvez adopter pour extraire la clé locale utilisée par Windows Store et l'introduire dans Wireshark, cependant, je pense que votre meilleur pari est d'injecter une DLL qui accroche les fonctions Network IO send () et recv () hors de votre processus.

Vous pouvez essayer de le faire vous-même à un "bas niveau", mais dans l'intérêt du pragmatisme, vous seriez sage d'examiner Microsoft Detours pour l'accrochage, il y a tellement d'exemples qui l'utilisent - c'est facile assez maintenant que connaître votre prototype de fonction est la seule exigence essentielle.

Answer 4

view on stackexchange narkive permalink

Vous pouvez également essayer oSpy qui, en gros, accroche les appels d'API appropriés et vous permet de voir les données avant et après qu'elles aient été chiffrées / déchiffrées.

oSpy est un outil qui aide au reverse-engineering de logiciels fonctionnant sur la plate-forme Windows. [...] lorsque le reniflage est effectué au niveau de l'API, il permet une vue beaucoup plus fine de ce qui se passe. [...] si une application utilise une communication cryptée, il est également facile d'intercepter ces appels. oSpy intercepte déjà une de ces API et est l'API utilisée par MSN Messenger, Google Talk, etc. pour crypter / décrypter les données HTTPS.

Answer 5

view on stackexchange narkive permalink

Très probablement, Windows 8 utilise WinINet pour se connecter à l'App Store. Si tel est le cas, vous pouvez voir les flux non chiffrés s'accrocher à wininet.dll au lieu d'utiliser un proxy. HookME fait cela et il a été présenté l'année dernière dans BlackHat.

Vous devez probablement apporter des modifications mineures pour le compiler et l'utiliser sous Windows 8.