Lors de la conférence de sécurité BlackHat 2009, Stefan Esser, chercheur réputé pour ses nombreuses découvertes concernant le moteur PHP, a rendu publiques deux vulnérabilités "0-day" dans le moteur PHP :

• Une vulnérabilité de type fuite d'information dans la fonction explode(), pouvant être exploitée afin de lire certaines structures internes du moteur (Réf. Lexsi 12585) ;
• Une vulnérabilité de type corruption de la mémoire dans la fonction "usort()" (Réf. Lexsi 12304).

Ces deux vulnérabilités font partie d'une classe de vulnérabilités que Stefan Esser nomme "Vulnérabilités d'interruption", consistant à stopper l'exécution d'une fonction interne de PHP afin d'en modifier les arguments, avant de rendre la main à la fonction. Ceci permet par exemple de modifier le type d'une variable, de "string" en "array", afin de pouvoir lire la structure représentant le tableau du point de vue du moteur PHP.

La combinaison de ces deux vulnérabilités permet d'obtenir un accès complet à la mémoire du processus en cours, par le biais suivant :

• On créé en mémoire une fausse structure représentant une chaîne de caractères commençant à l'adresse 0 et de taille 0x7fffffff ;
• On récupère l'adresse en mémoire de cette fausse structure grâce à la première vulnérabilité ;
• On corrompt l'une des entrées d'un tableau en insérant notre fausse structure grâce à la seconde vulnérabilité.

Nous nous retrouvons donc alors avec une entrée de tableau représentant une chaîne de caractères commençant à l'adresse 0 et de taille 0x7fffffff, ce qui nous procure un accès complet au 2 premiers Go de la mémoire du processus.
Une exploitation plus détaillée de ces vulnérabilités est disponible sur le blog Sécurité Offensive.

Si ces vulnérabilités ne permettent pas directement de compromettre un serveur web, elles deviennent particulièrement critiques dans le cas où il est possible pour un tiers d'exécuter du code PHP arbitraire, tel que dans les environnements d'hébergement mutualisé.
En effet, un accès complet à la mémoire du processus permet à un attaquant de reconfigurer complètement le moteur PHP, rendant inutiles les protections telles que safe_mode, open_basedir ou les disable_functions, voire même d'exécuter directement du code arbitraire avec les privilèges du serveur web.

Ces vulnérabilités ont été corrigées silencieusement (aucune apparition dans le ChangeLog) dans les versions suivantes de PHP :

• vulnérabilité explode() : version 5.3.1 (la branche 5.2.x n'a actuellement pas de correctif) ;
• vulnérabilité usort() : versions 5.2.11 et 5.3.1.

La réponse de Stefan Esser n'a pas tardé, et celui-ci a présenté peu de temps après une façon simple de contourner la protection contre l'exploitation de la vulnérabilité dans usort() grâce à la variable $_SESSION.
Cette nouvelle vulnérabilité a été corrigée dans la version 5.2.12 de PHP (Réf. Lexsi 12689) en modifiant certaines propriétés de la variable, et était cette fois-ci présente dans le ChangeLog.

Malheureusement, les corrections silencieuses de vulnérabilités posent des problèmes aux mainteneurs de paquets des principales distributions GNU/Linux, qui ne voient pas de mise à jour de sécurité à backporter dans leurs paquets. En effet, les versions de base de ces paquets sont généralement anciennes (version 5.2.6 dans Debian, par exemple), et les correctifs de sécurité doivent être intégrés à ces anciennes versions, sans pour autant y intégrer les autres modifications. Ces vulnérabilités, corrigées dans le moteur PHP depuis la mi-décembre 2009, ne sont pas corrigées dans la plupart des distributions Linux faisant office de serveurs Web :

• Red Hat Enterprise Linux : aucune mention des vulnérabilités dans explode() et usort(), seule la correction concernant la variable $_SESSION est abordée, mais le verdict est sans appel :

This flaw can be used by PHP script author to bypass restrictions such as safe_mode or open_basedir
Red Hat does not treat such issue as security flaws

• Mandriva Enterprise Server : aucune mention des vulnérabilité dans explode() et usort() ;
• Debian Lenny : la vulnérabilité concernant la variable $_SESSION vient d'être corrigée. Toutefois, les deux autres vulnérabilités n'ayant pas été corrigée, le risque est toujours autant présent ;
• Ubuntu : les correctifs sécurité d'Ubuntu se basant sur ceux de Debian, les vulnérabilités ne sont pas non plus corrigées.

Certaines distributions intégrant les versions 5.2.12 ou 5.3.1 de PHP sont quand à elles protégées de facto (OpenSuSE 11.2, Mandriva Linux 2010, Fedora 11/12 ...). Malheureusement, celles-ci sont beaucoup plus rares dans le domaine de l'hébergement, où l'on retrouve surtout des Red Hat Enterprise Server et des Debian.

Following the recent 0-day in Internet Explorer (Réf Lexsi 12808) and the Operation Aurora, the 16-bit subsystem of Windows is vulnerable to a privilege escalation vulnerability. All Windows versions are vulnerable, from NT 3.1 (!) to Windows 7.

Vulnerability (Réf Lexsi 12828) impacts the VDM (Virtual DOS Machine) component of Windows, whose role is to allow 16-bit real mode applications to run in a 32-bit environment system in protected mode, via the virtual 8086 mode provided by the processor. When the General Protection Fault (0x0d interruption) handler restores the context and stack, it verifies that the context and stack are valid, but bases its verification on 3 assumptions which can be bypassed, allowing an attacker to provides his own context and stack. Tavis Ormandy (Google) has published the details on Full-Disclosure, with an exploitation code.

Here is the scenario:

1. a process in launched (for example cmd.exe)
2. the base address of Ntoskrnl is determined
3. a memory scan is performed to find the offset of Ki386BiosCallReturnAddress() from Ntoskrnl
4. a 16-bit application is run (for example debug.exe) to initialize the NTVDM context
5. a DLL is injected into the ntvdm.exe process

The DLL performs the following operations:

1. the address of Ki386BiosCallReturnAddress() is retrieved via a n environment variable passed by the previous binary
2. a fake kernel stack frame is set with a return address pointing to any function (payload)
3. in the current TEB, VDM_TIB.VdmContext.Esi is set to point to our fake stack and VDM_TIB.VdmContext.Eip to Ki386BiosCallReturnAddress()
4. NtVdmControl() is called to trigger the vulnerability and execute our function in the context of the kernel

Once the vulnerability has been successfully exploited, the payload grabs the security token of the SYSTEM process and overwrites the token of the target process (cmd.exe). On the capture below displaying a Windows 7 system, the token of the initial process on the left maps the Lexsi user, whereas the token of the newly created cmd.exe on the right has become SYSTEM:

Tavis Ormandy did contacted Microsoft in last June, but decided to publish his vulnerability in a non-responsible way. However, a GPO can be deployed to disable the 16-bit subsystem and block the exploitation.

Après la récente 0-day dans Internet Explorer (Réf Lexsi 12808) et l'Opération Aurora, c'est au tour du sous-système 16 bits de Windows d'être vulnérable à une élévation locale de privilèges. Toutes les versions de Windows sont affectées, de NT 3.1 (!) à Windows 7.

La vulnérabilité (Réf Lexsi 12828) affecte le composant VDM (Virtual DOS Machine) de Windows, chargé de permettre aux applications 16 bits en mode réel de s'exécuter dans un environnement 32 bits en mode protégé, via le mode 8086 virtuel du processeur. Lors de la restauration du contexte et de la pile par le gestionnaire de l'interruption General Protection Fault (interruption 0x0d), celui-ci vérifie qu'ils sont valides, mais se base sur 3 assertions qui peuvent être contournées une par une, permettant de fournir son propre contexte et sa pile noyau. Tavis Ormandy (Google) a publié les détails sur Full-Disclosure, accompagné d'un code d'exploitation.

La séquence est la suivante :

1. lancement d'un processus (ici cmd.exe)
2. détermination de l'adresse de base de Ntoskrnl
3. scan en mémoire à la recherche de l'offset de Ki386BiosCallReturnAddress() par rapport à Ntoskrnl
4. lancement d'une application 16 bits quelconque (ex : debug.exe) pour initialiser le sous-système NTVDM
5. injection d'une DLL dans le processus ntvdm.exe

La DLL effectue alors les opérations suivantes :

1. récupération de l'adresse de Ki386BiosCallReturnAddress() passé en variable d'environnement par le binaire précédent
2. mise en place d'une fausse pile noyau avec comme sauvegarde de l'adresse de retour une fonction quelconque (payload)
3. dans le TEB courant, on fait pointer VDM_TIB.VdmContext.Esi vers notre fausse pile et VDM_TIB.VdmContext.Eip vers l'adresse de Ki386BiosCallReturnAddress()
4. exécution de NtVdmControl() pour déclencher la vulnérabilité et exécuter notre fonction quelconque dans le contexte du noyau

Une fois la vulnérabilité correctement exploitée, la payload recherche le jeton de sécurité du processus SYSTEM et remplace celui du processus ciblé (cmd.exe). Sur la capture ci-dessous issue de Windows 7, on voit par exemple que le jeton du processus initial à gauche correspond à l'utilisateur Lexsi, alors que celui du nouveau cmd.exe à droite est devenu SYSTEM :

Tavis Ormandy avait contacté Microsoft au mois de juin dernier, mais a tout de même décidé de publier cette vulnérabilité de manière "non responsable". Heureusement, il suffit de déployer la GPO permettant de désactiver le sous-système 16 bits pour ne plus être vulnérable.

Adobe recently released versions 8.2 and 9.3 of Acrobat/Reader, patching several critical vulnerabilities including the recent "newPlayer()" 0-day (Réf Lexsi 12676).

As system vulnerabilities will become more and more difficult to find and exploit, vulnerabilities in third-party applications will be more and more exploited in massive or targeted attacks. Among these applications, Adobe Flash Player and Adobe Acrobat/Reader are the most exploited. F-Secure has recently indicated that Adobe Acrobat/Reader has been used in almost 50% of targeted attacks using malicious documents in 2009, which is almost twice as much as in 2008.

In this context, it seems interesting to look at how antivirus compare when handling this kind of malicious documents. Let's take the latest Adobe Acrobat/Reader 0-day we mentioned above, for which an exploitation code has been available in the Metasploit framework since the 15th December. According to our tests, the PDF generated by Metasploit is currently detected by 6 antivirus out of the main 19 AV products:

Now, let's make it a bit more real. Using the Origami framework presented at the SSTIC conference (Rennes, France) in 2009, it is easy to inject the exploitation code and a payload from Metasploit into any legitimate PDF. There are many ways to automate the execution of the JavaScript code; here we have chosen to add an annotation to a page. The user will be reading its (apparently) legitimate document, until he reaches the malicious page which will trigger the execution of the payload (this behaviour should enhance the attack credibility :).

With the same exploitation code, it is however somewhat surprising to see that only 2 out of 19 AV now detect the malicious version of this legitimate PDF:

What should we conclude? First, we could say that it is not AV's role to detect exploitation codes, but malicious malware that will be dropped. Namely, it would not be surprising that an antivirus does not raise an alarm on an exploitation code that executes calc.exe. However, most (if not all) antivirus products include such signatures against PDF exploitation codes; detecting them in the first case but not in the second case can therefore be seen as a weakness in document parsing engines.

Petit patch day pour Microsoft (une seule vulnérabilité), mais Oracle et Adobe en ont aussi profité pour publier des mises à jour de sécurité critiques.

Microsoft n'a publié qu'un seul bulletin ce mois-ci :
MS10-001 : vulnérabilité dans le parsing des polices EOT, permettant d'exécuter du code arbitraire (Réf Lexsi 12790)

La vulnérabilité dans le composant SMB de Windows 2008 R2 et Windows 7 (Réf Lexsi 12542) n'est toujours pas corrigée, alors que le code d'exploitation est publié depuis 2 mois.

Quant à la vulnérabilité dans IIS dans la gestion du caractère ";" dans les URL (permettant de faire exécuter en tant que script ASP un fichier nommé foo.asp;bar.jpg) (Réf Lexsi 12724), elle reste sans correctif alors qu'elle est triviale à exploiter ; les conditions nécessaires (un répertoire accessible à la fois en écriture et en exécution) ne sont pas celles par défaut et sont même officiellement déconseillées, mais il n'est malheureusement pas rare de les rencontrer dans la nature.

Dans le cadre de sa publication trimestrielle, Oracle a publié de nouvelles versions de ses principaux produits (Database, Application Server, etc) corrigeant un total de 24 vulnérabilités. Trois vulnérabilités ont un score CVSSv2 de 10.

Adobe a également publié les versions 8.2 et 9.3 d'Acrobat/Reader, corrigeant plusieurs vulnérabilités critiques dont la récente 0-day dans la méthode JavaScript "newPlayer()" (Réf Lexsi 12676).

Petite digression sur les codes d'exploitation. Il est couramment admis qu'à mesure que les vulnérabilités système vont devenir de plus en plus difficile à trouver et/ou à exploiter, les vulnérabilités dans les applications tierces courantes vont être de plus en plus utilisées, de façon massive ou ciblée. Parmi ces applications, Adobe Flash Player et surtout Adobe Acrobat/Reader sont les plus exploitées. F-Secure a par exemple récemment indiqué qu'Adobe Acrobat/Reader était utilisé dans près de 50% des attaques ciblées en 2009 utilisant des documents malveillants, soit quasiment deux fois plus qu'en 2008.

Dans ce contexte, il semble pertinent de s'intéresser de près à l'efficacité des produits antivirus sur ce type de document malveillant. Prenons par exemple la 0-day dans Adobe Acrobat/Reader évoquée ci-dessus, pour laquelle un code d'exploitation est disponible dans le framework Metasploit depuis le 15/12. D'après nos tests, le PDF généré par Metasploit est aujourd'hui détecté par 6 antivirus sur les 19 principaux du marché :

Plaçons-nous maintenant dans un cas réel. Pour cela, nous allons prendre un fichier PDF légitime quelconque et y injecter le code d'exploitation et la payload fournis par Metasploit grâce au framework Origami présenté au SSTIC en 2009. Il existe de nombreuses manières de lancer du code JavaScript (ici celui directement issu de l'exploit Metasploit) automatiquement à l'ouverture d'un PDF ; nous allons ici choisir d'ajouter une annotation à une page. L'utilisateur lira ainsi tranquillement son document soi-disant légitime, jusqu'à atteindre la page piégée qui déclenchera l'exécution de la payload (de quoi augmenter la crédibilité de l'attaque :).

La surprise provient alors de la détection antivirale qui chute brusquement (le code d'exploitation étant identique) lors de l'utilisation de ce PDF légitime piégé, comparé au PDF directement fourni par Metasploit : seulement 2 sur les 19 testés.

Que penser de ces résultats ? Au premier abord, on pourrait se dire que ce n'est pas le rôle des antivirus de détecter des codes d'exploitation, mais plutôt les malware éventuellement droppés. Pour ainsi dire, on n'en voudrait pas à un antivirus de ne pas lever d'alerte sur un code d'exploitation exécutant calc.exe. Cependant, la plupart des antivirus intègrent effectivement des signatures pour les codes d'exploitation PDF ; les détecter dans le premier cas mais pas dans le second peut donc être considéré comme une faiblesse des moteurs d'analyse de documents.

L'annonce fracassante de Google, dont des secrets industriels auraient été volés par des hackers chinois, fait énormément de bruit aujourd'hui, et relance l'arlésienne de l'espionnage économique venu de Chine.

En réalité, très peu de détails ont été révélés sur cette attaque : Google parle d'une part d'une intrusion qui aurait également affecté d'autres entreprises, puis dans un deuxième temps, mentionne des vols de comptes d'opposants au gouvernement chinois par phishing ou par malware. Ce mélange de modes opératoires très différents rend difficile d'estimer la réalité et l'ampleur de ces attaques.

Aucun moyen donc d'analyser sérieusement cette annonce sous l'angle de la sécurité. Le mystère restera entier à moins que la firme dévoile davantage d'informations. Par contre, il nous semble opportun de replacer cette annonce dans son contexte : elle arrive en effet à point nommé pour Google, dont les récentes déclarations de son PDG à propos du respect de la vie privée des internautes avaient provoqué un tollé. La position de Google sur la Chine a toujours été compliquée : d'un côté, la firme a toujours refusé de collaborer avec le gouvernement chinois en fournissant les adresses IP des dissidents qui utilisent son réseau -- bien qu'en certaines occasions et dans d'autres pays, elle ait pu s'adonner à ce genre de pratiques (lien, lien) ; et de l'autre côté, le moteur de recherche Google.cn a toujours répondu présent face aux demandes pressentes du gouvernement chinois pour censurer certains sites web, pour leur caractère pornographique ou politiquement incorrect.

Il faut donc lire cette annonce comme une occasion pour Google d'endosser de nouveau un rôle de chevalier blanc, largement émoussé avec les années : Google, qui avait bâti sa réputation sympathique sur la voie alternative qu'il proposait face à l'acteur dominant Microsoft, a bien changé et désormais agace, assumant un rôle de Goliath, attaqué de toutes parts pour son arrogance et ses positions dominantes. La firme joue donc probablement un gros coup de bluff : qui imaginerait que le gouvernement chinois autoriserait Google à sortir de sa politique de censure du web ? Qui croirait un instant que Google tournerait définitivement le dos à un marché de plus de 300 millions d'internautes, le plus grand marché au monde ? Et quel poids possède Google dans les négociations, écrasé par Baidu qui totalise 77% des parts du marché de la recherche Internet en Chine ?

More and more companies choose to use strong authentication to ensure security, which is no more assured by a simple password. It is indeed easy to find by an attacker, either through social engineering, keylogging, brute force cracking or rainbow table ...

What is called strong authentication is the combination of two authentication factors among these three:

• What I know: the password is in this category;
• What I own: it may be a smart card, magnetic stripe, RFID, or a USB token;
• What I am: this is biometrics, which may be the fingerprint, the iris, or the palm of the hand.

So, if you wish to implement a strong authentication mechanism, it must meet two of these factors. A combination often encountered is the combination of a smart card or USB token (containing the data identifying the user, usually an X.509 certificate), with a PIN code to unlock it (combination "What I have" + "What I know").

However, biometrics appears more and more in the chain, especially fingerprints, replacing the PIN to unlock the smart card (combination "What I have" + "What I am "). This biometrics has several advantages compared with the password:

• the user does not need to remember a complex password;
• it is more difficult to steal the user's fingerprint.

The user feels much more secure, in addition to acquire a certain ease of use. But is he really more secured?

Firstly, it has been proven that it is easy to reconstruct a fingerprint found e.g. on a glass, to spoof a simple fingerprint reader.

Secondly, the use of biometrics in France is regulated by the CNIL. Regarding access management by fingerprint, the CNIL states that a user's biometric information must not be centralized in a database. In our case, they must be stored on the smart card. This can then cause a problem when implementing the software for the strong authentication.

When strong authentication is based on a couple smart card / PIN, it may be interesting for the convenience of users to add the ability to unlock the smart card by using their fingerprint. The verification of biometric data can then be made in the application managing the authentication, on the user's host. This implementation raises the following issues:

• the user's biometric data must be available on the smart card for reading for everyone (so the program can access it for comparison). It may of course be encrypted, and the application has the key to decipher it;
• once the user identified, the application must be able to send information (e.g. PIN) to the card to unlock the information it contains, and thus authenticate the user. For this, the application must know this information. This is naturally stored, available for reading for everyone (encrypted again) on the smart card.

The introduction of biometrics then decreases the system's security, having the smart card is sufficient to retrieve information (often the PIN, having recovered the cryptographic key of the application ), and then authenticate.

A secure way to implement this type of strong authentication (biometric + smart card) is the Match On Card technology, which allows verification of the fingerprint directly within the chip. This ensures that the card manages the unlocking of the authentication certificate, only if the fingerprint presented corresponds to the one recorded.

Biometrics is an interesting technology with its advantages and limits to manage authentication, but as always, everything depends on implementation.

De plus en plus d'entreprises font le choix d'utiliser de l'authentification forte, afin de garantir une sécurité qui n'est aujourd'hui plus assurée par un simple mot de passe. Celui-ci est en effet facilement trouvable par un attaquant, que ce soit par ingénierie sociale, keylogging, cassage par force brute ou rainbow tables ...

Ce que l'on nomme authentification forte est la combinaison de deux facteurs d'authentification parmi les trois suivants :

• Ce que je sais : c'est dans cette catégorie qu'entre le mot de passe ;
• Ce que je possède : il peut s'agir ici d'une carte à puce, à bande magnétique, RFID ou encore d'un token USB ;
• Ce que je suis : il s'agit ici d'éléments biométriques, qui peuvent être l'empreinte digitale, l'empreinte rétinienne, ou encore la paume de la main.

Dés lors, si l'on souhaite mettre en place un mécanisme d'authentification forte, il faut réunir deux de ces facteurs. Une combinaison souvent rencontrée est l'association d'une carte à puce ou d'un token usb (contenant les données d'identification de l'utilisateur, le plus souvent un certificat X.509), avec un code PIN permettant de la/le déverrouiller (combinaison "ce que je possède" + "ce que je sais").

Toutefois, on constate de plus en plus l'apparition de la biométrie dans la chaîne, et plus particulièrement des empreintes digitales, remplaçant le code PIN pour le déverrouillage de la carte à puce (combinaison "ce que je possède" + "ce que je suis"). Cette biométrie a plusieurs atouts comparé au mot de passe :

• l'utilisateur n'a pas à se souvenir d'un mot de passe compliqué ;
• l'utilisateur se fait plus difficilement voler son empreinte digitale.

L'utilisateur se sent ainsi plus en sécurité, en plus d'avoir gagné un certain confort d'utilisation. Mais l'est-il vraiment ?

Tout d'abord, il a été prouvé qu'il est facile de reconstituer une empreinte digitale trouvée par exemple sur un verre, afin de tromper un lecteur d'empreintes peu regardant.

Ensuite, l'utilisation de la biométrie en France est règlementée par la CNIL. Concernant les gestions d'accès par empreinte digitale, la CNIL stipule que les informations biométriques d'un utilisateur ne doivent pas être centralisées dans une base de données. Dans notre cas de figure, celles-ci doivent donc être stockées sur la carte à puce. Ceci peut alors poser un problème lors de l'implémentation logicielle de l'authentification forte.

Dans le cas où l'authentification forte repose sur un couple carte à puce / code PIN, il peut être intéressant pour le confort des utilisateurs d'ajouter la possibilité de déverrouiller la carte à puce par le biais de leur empreinte digitale. La vérification des données biométriques peut alors s'effectuer dans l'application gérant l'authentification, donc au niveau du poste utilisateur. Cette implémentation pose les problèmes suivants :

• les données biométriques de l'utilisateur doivent être disponibles sur la carte à puce en lecture pour tout le monde (pour que le programme puisse y accéder pour comparaison). Celles-ci peuvent bien sûr être chiffrée, et l'application dispose de la clé permettant de les déchiffrer ;
• une fois l'utilisateur reconnu, l'application doit être à même d'envoyer une information (par exemple un code PIN) à la carte afin de déverrouiller les informations qu'elle contient, et ainsi authentifier l'utilisateur. Pour cela, l'application doit connaître cette information. Celle-ci est donc tout naturellement stockée, en lecture pour tout le monde (chiffrée là aussi), sur la carte à puce.

L'introduction de la biométrie introduit alors une baisse de la sécurité du système; il suffit en effet de disposer de la carte à puce pour retrouver l'information (donc souvent le code PIN, en ayant récupéré la clé de chiffrement de l'application), et s'authentifier.

Une façon sécurisée de mettre en place ce type d'authentification forte (biométrie + carte à puce) est alors la technologie Match On Card, permettant d'effectuer la vérification de l'empreinte digitale directement au sein de la carte à puce. On s'assure alors que c'est la carte qui gère le déverrouillage du certificat d'authentification, uniquement si l'empreinte présentée correspond à celle enregistrée.

La biométrie est donc une technologie intéressante avec ses avantages et ses limites pour gérer des authentifications, mais comme toujours, tout dépend de l'implémentation.

Reading one of the last ISC's diaries reminds a trick we recently encountered during a malicious PDF document's analysis.

It explains a somewhat special shellcode method in a PDF exploiting the latest 0-day vulnerability in Adobe Reader (Lexsi Ref. 12676). Indeed, it is very small (38 bytes only), and will search through the memory pages of the process to find a certain pattern, then jump to its address to continue execution. The pattern is in a compressed stream object within the malicious PDF document. The second shellcode decodes and runs two executables, also contained in the PDF. The first will open a non-malicious PDF document, while the second is a malware attempting to connect to a control channel.

The method we encountered is substantially identical. The vulnerability exploited is a heap-based buffer overflow in U3D file management (Lexsi Ref. 12415), and the heap-spraying trick is used to format the heap for the execution redirection. A quick look at the document shows that the injected shellcode in the heap is as follows:

Once loaded into the debugger, we face with a rather conventional beginning (for details, see this previous shellcode analysis):

• a loop is responsible for deciphering the shellcode by XOR-ing all the bytes with the value "0xF9"

• then, it will look for the addresses of several Windows API functions

The next step is more interesting: the shellcode will perform a brute-force of open file descriptors until finding one whose header corresponds to a PDF file, then check for some patterns located at certain offsets.

This will allow the shellcode to obtain a handle to the malicious PDF document, and to extract and decode a second shellcode by reading it at a specific offset. The result is very similar to the ISC's analysis: the second shellcode will open a non-malicious PDF document and run a downloader binary included in the malicious PDF.

This method allows to search a second stage shellcode more reliably than by browsing the memory pages of the process, in which there is a risk of finding a sequence of bytes corresponding to the desired pattern without being the beginning of the shellcode, or trigger an error by accessing unmapped memory.

Fervent utilisateur de Facebook depuis quelques semaines, j’ai très vite succombé à ses charmes, et ai également vite pu constater l’ampleur des dégâts en matière de sécurité. Et au fond, je crois qu’il ne faudra jamais attendre de Facebook (ou de tout autre réseau social personnel) qu’il développe chez ses utilisateurs une quelconque culture de la sécurité face aux risques qu’il porte : la sécurité est tout simplement antinomique de Facebook, pour des raisons intrinsèques au réseau.

Il n’y aura jamais de contrôles d’identité sur Facebook. Le premier réseau social qui mettra en place des contrôles d’identité réels à l’inscription se suicidera. Ce n’est pas une question de moyens : aujourd’hui il est évidemment impensable de demander aux utilisateurs de Facebook de fournir à l’entreprise une copie de leur carte d’identité à chaque inscription ; mais même à l’avenir, lorsque ces contrôles seront automatisables par l’informatisation des documents d’identité nationaux, aucun réseau social majeur n’y prêtera attention : la raison est toute simple, un réseau social existe d’abord parce qu’il offre un espace de liberté suffisant à ses utilisateurs pour leur permettre de changer d’identité. Et contrairement aux déclarations publiques de certains, il existe mille raisons légitimes pour changer d’identité : signer un article sous un pseudonyme, par exemple, est une pratique extrêmement répandue dans la presse et qui ne choque personne ; de même qu’adopter un surnom fantaisiste est à la racine même de tous les systèmes de messagerie instantanée, à commencer par les systèmes de radio amateur, des décennies avant la généralisation d’Internet. De plus, changer d’identité ne signifie évidemment pas usurper une identité.

Il n’y aura pas d’authentification forte avant longtemps – voire jamais. Là encore, l’authentification forte contredit l’un des piliers des réseaux sociaux personnels : la gratuité. N’oublions pas que Facebook a recherché sa rentabilité organique pendant des années, et que ce n’est que tout récemment que l’entreprise a commencé à gagner de l’argent autrement qu’en attirant des investisseurs. Il est donc très loin, le jour où Facebook dépensera ne serait-ce que quelques Euros pour déployer un token d’authentification à chacun de ses 200 millions d’utilisateurs. Inconcevable également, l’option de rendre Facebook payant : le réseau disparaîtrait en quelques semaines en perdant 95% de ses internautes, qui se reporteraient sur des équivalents gratuits. L’authentification par mot de passe, reconnue comme obsolète depuis des années et attaquée par tout cheval de Troie qui se respecte, a donc encore de beaux jours devant elle, et les comptes Facebook continueront d’être usurpés en masse par les criminels.

Il n’y aura jamais de modération adéquate. Il faudrait rien moins qu’une armée pour modérer le réseau de façon préventive : ne serait-ce que lire un échantillon d’un dixième de pourcent des messages échangés quotidiennement sur Facebook relève des douze travaux d’Hercule. Du côté de la modération corrective, point d’espoir non plus : d’une part, les signalements d’abus sont extrêmement rares, trop rares pour faire remonter à la surface les dérives vraiment graves sur le réseau ; d’autre part, la fermeture d’un groupe / d’une page / d’un profil sont des évènements vécus comme traumatisants pour les principaux concernés, et la société évite donc les fermetures inconsidérées sur un simple signalement, et privilégie les cas graves ; enfin, et c’est sans doute la raison principale : Facebook est devenu le pendant libertaire de sociétés de plus en plus sous contrôle. Les évènements qu’on ne peut pas écrire dans la presse ou commenter en public, par l’effet de la censure, on les relate sur Facebook ; les opinions contestataires, pratiques marginales, ou simplement les coups de gueule qu’on n’ose pas exprimer en public, on les libère sur Facebook. Facebook est devenu l’un des réceptacles de notre droit à l’irresponsabilité et à la contradiction, et le jour où il faudra s’y conduire de manière responsable et cohérente, le réseau s’effondrera tout seul.

Et enfin, les salariés utiliseront toujours Facebook sur leur lieu de travail. Non pas parce qu’il est difficile de bloquer l’accès à ce site – c’est techniquement très simple ; non plus en raison du prétendu choc des générations, les « jeunes » - la fameuse « génération Y » - étant soupçonnés d’allergie massive à l’autorité et aux pratiques managériales traditionnelles ; mais d’abord parce que l’usage de Facebook sur le lieu de travail n’est pas une question de sécurité, mais de productivité. Qu’un salarié utilise Facebook sur son lieu de travail ou à la maison, le risque est le même, en termes de fuites d’information. S’il a l’intention de commenter publiquement son travail, il le fera de toutes façons, et peut-être même de manière encore plus virulente à la maison s’il en a été empêché sur son lieu de travail. Le véritable enjeu, c’est sa productivité, le temps qu’il y passe en ne travaillant pas ; mais sur cette route, Facebook est loin d’être le seul gouffre de productivité sur le web, et suivre ce raisonnement jusqu’au bout reviendrait à filtrer les flux à base d’une liste blanche de sites dédiés à l’activité professionnelle du salarié, en interdisant tous les autres sites. En dehors de certains cas très précis, un tel filtrage en liste blanche est globalement impensable, l’activité quotidienne de beaucoup de salariés reposant sur la consultation de sources d’information sur le web, impossibles à identifier au préalable.

Il me paraît ainsi évident que le principe même de sécurité est incompatible avec Facebook. Mais au final, est-ce si grave ?