CVE-2010-3654 : Adobe Flash Player Button Remote Code Execution

Chers lecteurs ZATAZ, faîtes-vous parti des 191 340 visiteurs sur le mois d’Octobre qui ont utilisé 94 versions Flash différentes ?! Si vous n’avez pas Flash d’installé, alors Internet pour vous doit être une plaie, mais dites-vous que vous risquez moins que les autres lecteurs de ZATAZ. Si vous faites partis des visiteurs ayant Flash d’installé, et que vous utilisez Adobe Reader, vous risquez de voir vos ordinateurs se transformer en passerelles à pirates informatique.

J’aime les statistiques et je vais vous en faire profiter.

  • 102 543 visiteurs ont la version 10.1 r85 de Flash d’installée.
  • 20 505 visiteurs ont la version 10.1 r82 de Flash d’installée.
  • 15 639 visiteurs ont la version 10.0 r45 de Flash d’installée.
  • 12 513 visiteurs ont la version 10.1 r53 de Flash d’installée.
  • 10 048 visiteurs ont la version 10.0 r32 de Flash d’installée.
  • 5 234 visiteurs ont la version 10.0 r22 de Flash d’installée.
  • 5 144 visiteurs ont la version 10.0 r42 de Flash d’installée.
  • 1 747 visiteurs ont la version 10.0 r12 de Flash d’installée.
  • 1 365 visiteurs ont la version 9.0 r124 de Flash d’installée.
  • Et finalement 11 044 n’ont pas de version de Flash détectée.
Adobe Flash version repartition for October 2010 on 191 340 users
Adobe Flash version repartition for October 2010 on 191 340 users

Mais ne vous inquiétez pas, si vous utilisez Adobe Reader, vous êtes tous des cibles potentielles d’internautes malveillants. La faute à APSA10-05, une des nombreuses vulnérabilités critiques découvertes ces derniers mois sur les produits Adobe.

Le 28 Octobre Fortinet annonce de façon synchronisée avec Adobe qu’un 0day, en cours d’exploitation sur Internet, a été détecté et que celui-ci permettrait de compromettre vos ordinateurs, lors de la lecture d’un PDF contenant une animation Flash malveillante.

Toutes les versions de Flash sont affectées, même la dernière version 10.1.85.3 disponible, et toutes les versions 9.x, dont la dernière en date, de Adobe Reader, que ce soit sous Windows, Macintosh, Linux, Solaris ou encore Android.

La mise à jour de Flash est prévue par Adobe, pour Windows, Macintosh, Linux, et Solaris le 4 Novembre (soit 8 jours après la découverte). Pour Android, il vous faudra attendre le 9 Novembre (soit 13 jours après la découverte), et pour les mises à jour de Adobe Reader le 15 Novembre (soit près de 20 jours après la découverte).

Ci-dessous une petite vidéo qui montre la facilité d’exploitation de cette vulnérabilité avec Metasploit.

En attendant les mises à jour, serrez les fesses, n’ouvrez pas de documents PDF, ne surfez plus sur Internet et priez pour qu’il n’y ait pas un autre 0day Flash qui soit découvert la semaine prochaine.

CVE-2010-3552 ou l’absurdité de la divulgation responsable et de la négligence caractérisée

Chers lecteurs ZATAZ, vous être près de 84% d’entre-vous ayant le support Java d’activé sur vos navigateurs Internet, l’avez-vous mis à jour dernièrement ? Si non, vous risquez de voir vos ordinateurs se transformer en passerelles à pirates informatique. Si oui, vous pensez être protégé, mais que neni, une nouvelle vulnérabilité, un nouveau “0day” est sûrement déjà en cours d’exploitation.

Chers lecteurs ZATAZ résidants en France, savez-vous que depuis l’activation de Hadopi, vous êtes tenus à une obligation de démontrer comme quoi vous avez mis tous les moyens en oeuvre pour vous protéger au cas ou vous sauriez soupçonné d’enfreinte au code de la propriété intellectuelle. Donc de façon claire, vous devez connaître vos faiblesses, vos vulnérabilité et démontrer que vous avez mis les moyens en oeuvre pour y remédier.

Ci-dessous une petite anecdote qui démontre l’absurdité de mettre la responsabilité de sécurisation sur l’internaute lambda qui ne connait rien à l’informatique, qui ne connait pas grand chose d’Internet, sauf Facebook (parce que les copains y sont), Twitter et Youtube. Qui démontre l’absurdité de la relation “déontologique” entre les professionnels de la sécurité informatique et les fournisseurs finaux. Qui démontre le peu de prise en compte des risques légaux que vous encourez en tant qu’internaute lambda par les fournisseurs finaux.

Le 20 Juillet 2010, ZDI (Zero Day Initiative) a rapporté une vulnérabilité dans Java Runtime Environment (JRE) à l’éditeur Oracle. ZDI joue, la plupart du temps, l’intermédiaire entre le chercheur en sécurité informatique qui a découvert la vulnérabilité et le fournisseur final de l’application vulnérable. Ce rôle d’intermédiaire est important pour la suite de cet article.

Cette vulnérabilité n’était bien sûr pas dévoilée au public, afin de laisser le temps au fournisseur de régler la situation (principe déontologique). Le 12 Octobre, près de trois mois après cette notification, une mise à jour est fournie par Oracle (SUN Java 6 Update 22) et la vulnérabilité est dévoilée au grand public (enfin dans un langage de spécialistes…) sous l’acronyme CVE-2010-3552.

Ce que l’on peut apprendre du bulletin de notification “ZDI-10-206” est que ZDI, et Oracle, créditent “Stephen Fewer” de l’entreprise “Harmony Security” pour la découverte. Cette vulnérabilité pourrait permettre à des internautes malveillants d’exécuter du code arbitraire sur les ordinateurs où les versions vulnérables de Oracle JRE sont installées. La seule interaction requise, pour l’exploitation de la vulnérabilité, est que l’internaute cible surfe sur un site web malveillant. Le nom de la DLL (JP2IEXP.dll), ainsi que quelques détails sur les parties de codes affectés sont fournis, mais sans plus de détails.

Ce qui est intéressant dans cette histoire, et ce qui s’est déjà vu plusieurs fois, c’est qu’un autre chercheur en sécurité informatique, Berend-Jan Wever, aurait lui aussi découvert la même vulnérabilité, mais le 31 Août 2010, alors que la vulnérabilité n’était pas encore dévoilée publiquement. Ce chercheur en sécurité informatique fournissait beaucoup plus de détails, comme la version vulnérable (SUN Java 6 Update 21, qui était alors la dernière version disponible), ainsi qu’un PoC (Proof of Concept) permettant de reproduire la vulnérabilité.

Il aura fallu peu de temps après la révélation au grand public de cette vulnérabilité, pour que l’équipe Rapid7 industrialise cette vulnérabilité, le 25 Octobre, en l’intégrant à sa suite gratuite de “pen-test” Metasploit. L’exploitation de cette vulnérabilité en devenait alors d’autant plus simple et permettait à peu près à n’importe quel internaute de prendre la main sur l’ordinateur de son voisin. Ci-dessous une petite vidéo réalisée maison pour vous démontrer la facilité d’exploitation de cette vulnérabilité.

Donc, la vulnérabilité a été dévoilée au fournisseur le 20 Juillet par un premier chercheur, un deuxième chercheur découvre la même vulnérabilité le 30 Août, et le fournisseur propose une mise à jour pour combler la vulnérabilité le 12 Octobre, soit près de trois mois après sa “première” découverte ! Il est classique dans le monde de la recherche en sécurité informatique de laisser le temps au fournisseur de corriger la vulnérabilité (principe déontologique), mais pendant ce temps là les internautes comme vous et moi, pouvons être les victimes de ce qui est appelée communément un “0day” (d’ailleurs qui n’en est plus un, car connu par le fournisseur) exploité par le crime organisé sévissant sur Internet.

Deux chercheurs qui trouvent en si peu de temps d’intervalle la même vulnérabilité, ne pensez-vous pas que d’autres “chercheurs”, moins respectueux des bonnes pratiques du “monde professionnel” de la sécurité informatique, aient aussi pu trouver cette même vulnérabilité ?

La pression légale augmentant au jour le jour contre les internautes, pour que ceux-ci démontrent qu’ils se protègent, en vain, fait que le système “déontologique” actuel est voué à mourir. Une nouvelle relation entre les chercheurs en sécurité informatique et les fournisseurs doit s’établir, une nouvelle relation entre le fournisseur et le consommateur final doit naître.

SUC020 : Potential FTP non anonymous Login and/or Brute-Force attempt

  • Use Case Reference : SUC020
  • Use Case Title : Potential FTP non anonymous Login and/or Brute-Force attempt
  • Use Case Detection : Firewall / IDS / FTP logs
  • Attacker Class : Opportunists / Targeting Opportunists
  • Attack Sophistication : Unsophisticated / Low
  • Identified tool(s) : Random
  • Source IP(s) : Random
  • Source Countries : Random
  • Source Port(s) : Random
  • Destination Port(s) : 21/TCP

Possible(s) correlation(s) :

  • FTP brute force bot.

Source(s) :

Emerging Threats SIG 2002383 triggers are :

  • The FTP server should return the error code “530” and the string “Login”, or the string “User”, or the string “Failed”, or the string “Not”.
  • The source port should be the port 21 of the HOME_NET FTP server in destination of an EXTERNAL_NET IP.
  • Alerts every 5 occurrences of the event targeting the same EXTERNAL_NET IP during 300 seconds.

Emerging Threats SIG 2003303 triggers are :

  • The string “USER” should be present.
  • The strings “PASS”, “anonymous” or “ftp” shouldn’t not be present.
  • The source IP should be part of EXTERNAL_NET in destination of HOME_NET ftp server on port 21.
  • Alert on every occurrence.
Emerging Threat SIG 2010643 triggers are :
  • The string “USER” should be present.
  • The string “administrator” should be present.
  • The source IP should be part of EXTERNAL_NET in destination of HOME_NET ftp server on port 21.
  • Alerts every 5 occurrences of the event targeting the same EXTERNAL_NET IP during 60 seconds.
SIG 2002383 1 Week events activity
SIG 2002383 1 Week events activity
SIG 2003303 1 Week events activity
SIG 2003303 1 Week events activity
SIG 2010643 1 Week events activity
SIG 2010643 1 Week events activity
SIG 2002383 1 month events activity
SIG 2002383 1 month events activity
SIG 2003303 1 month events activity
SIG 2003303 1 month events activity
SIG 2010643 1 month events activity
SIG 2010643 1 month events activity
1 Month TOP 10 source IPs for SIG 2002383
1 Month TOP 10 source IPs for SIG 2002383
1 Month TOP 10 source IPs for SIG 2003303
1 Month TOP 10 source IPs for SIG 2003303
1 Month TOP 10 source IPs for SIG 2010643
1 Month TOP 10 source IPs for SIG 2010643
TOP 20 source countries for SIG 2002383
TOP 20 source countries for SIG 2002383
TOP 20 source countries for SIG 2003303
TOP 20 source countries for SIG 2003303
TOP 20 source countries for SIG 2010643
TOP 20 source countries for SIG 2010643

EDB-ID-15130 : Barracuda Networks Spam & Virus Firewall LFI extended to more products

The 10/09/2010, Tiago Ferreira, submitted a new HTTP scanner auxiliary module to the Metasploit team, “barracuda_directory_traversal“, how was added in the Metasploit Framework SVN.

Interested by this new scanner, I decided to take a look on the initial linked references (OSVDB 68301 / SA41609 / EDB-ID 15130).

At this time EDB-ID 15130 was the initial reference, with 27/09/2010 as creation date, and the associated 0day only mention “Barracuda Networks  Spam & Virus Firewall version 4.1.1.021” as affected product. Today it is still the case. Secunia Advisory was created the 01/10/2010, and only mentioned the same product as the EDB-ID. OSVDB reference was created the 03/10/2010, and same as the other references only mentioned the same affected product.

I decided to test the vulnerability, but first of all I had to find some vulnerable targets. For this purpose SHODAN was the key for my searches. Just type “barracuda” in the SHODAN search engine and you will find hundreds of results.

Directly with SHODAN result i saw different Barracuda fingerprints :

  • Barracuda Link Balancer
  • Barracuda Load Balancer
  • Barracuda Spam Firewall
  • Barracuda Spam & Virus Firewall
  • etc.

To see the scanner in action I tested, with Metasploit, all IPs of the “Barracuda Spam & Firewall” fingerprint. Evidence are clear, more than 90% of the targets where vulnerable. Intrigued by the others fingerprints, I decided to test the exploit by hand, not with Metasploit, on “normally non vulnerable” products. I was surprised when i saw that these products where also vulnerable to this vulnerability. Decided, then, to test it with Metasploit. But the tool returned me that the products where not vulnerables.

Something was wrong with the Metasploit scanner, and/or something was wrong with the references.

In order to improve Metasploit, a tool I love, i opened an issue for the Metasploit team, and decided to find the real reason on these differences.

Here under is the final word of the story.

ShadowHatesYou submitted the 0day to Exploit DB the 27/09/2010, but 28/09/2010 Barracuda has release a security update for most of they products. This discovery was credited to “Randy Janinda” and “Sanjeev Sinha” by Barracuda. The affected products were :

  • Barracuda IM Firewall 3.4.01.004 and earlier
  • Barracuda Link Balancer 2.1.1.010 and earlier
  • Barracuda Load Balancer 3.3.1.005 and earlier
  • Barracuda Message Archiver 2.2.1.005 and earlier
  • Barracuda Spam & Virus Firewall 4.1.2.006 and earlier
  • Barracuda SSL VPN 1.7.2.004 and earlier
  • Barracuda Web Application Firewall 7.4.0.022 and earlier
  • Barracuda Web Filter 4.3.0.013 and earlier

Just take a look on the day between the 0day and the Barracuda security advisory, is there any relation ship between ShadowHatesYou and the 2 credited guys? Also the initial affected product version was 4.1.1.021, but as described by Barracuda the upper affected version was 4.1.2.006. So ShadowHatesYou wasn’t aware that more products and upper versions where affected.

So after these Metasploit issue updates, OSVDB and Secunia have update they’re references for all Barracuda affected products and versions.

Now, after the extension of this vulnerability to more products, you have, in the wild wild Internet, thousands of Barracuda vulnerable products, how permit to a bad guy to take a complete control on the administration interface (to create firewall rules in order to access to the internal network, to route the internal network to a malicious target, etc, etc). These affected networks could be considered as completely compromised.