Archive
May 2012 Cyber Attacks Timeline (Part II)
As usual, here it is the second part of the Cyber Attacks Timeline for the month of May 2012: a month particularly rich of Cyber Events. As you will probably know, the Flame malware has monopolized the attention, deserving the most attention from the Information Security Professional.
Nevertheless the scene has offered many interesting events, among which it worths to mention the breach of 123,000 federal employees records, the breach affecting University of Nebraska, and, last but not least, the breach against WHCMS (which, as we will soon see, has proved to be fatal for its author).
The hacktivist front is still hot and preannounces another hot summer. On the other hand the authors of several remarkable cyber-criminal actions are probably going to leave the scene: the long trail of arrests made by Law Enforcement Agencies against hackers has continued in this month and has hence led to the arrest of Cosmo, the leader of the infamous group UGNazi, which claimed to be the author of the Cyber Attack against WHCMS.
In your opinion are the arrests against hackers really going to stop the growing number of Cyber Attacks (acting as a deterrent)?
If you want to have an idea of how fragile our data are inside the cyberspace, have a look at the timelines of the main Cyber Attacks in 2011 and 2012 (regularly updated), and follow @paulsparrows on Twitter for the latest updates.
After the jump you find all the references, and at this link the first part covering 1-15 May.
What Security Vendors Said One Year Ago…
I did not resist, so after publishing the summary of Security Predictions for 2012, I checked out what security vendors predicted one year ago for 2011. Exactly as I did in my previous post, at the beginning of 2011 I collected the security predictions in a similar post (in Italian). I also published in May an update (in English) since, during the Check Point Experience in Barcelona held in May 2011, the Israeli security firm published its predictions. Even if the latters have been published nearly at the half of 2011, for the sake of completeness, I decided to insert them as well in this year-to-year comparison.
Then, I included Symantec (for which this year I did not find any prediction), McAfee, Trend Micro, Kaspersky, Sophos and Cisco. I included Check Point in a second time and I did not include Fortinet, At that time I missed their five security predictions, which I only discovered later so I decided to provide an addendum for this post including Fortinet as well in order to provide a deeper perspective.
The security predictions for 2011 are summarized in the following chart, which reports what the vendors (with the partial above described exception of Checkpoint) expected for the past year in terms of Information Security trends.
But a strict side-by-side comparison with the 2012 information security predictions (extracted by my previous post) is more helpful and meaningful:

As you may notice mobile threats were on top even among the predictions for 2011. This prediction came easily true most of all for Android which suffered (and keeps on suffering) a huge increase in malware detection samples (even if the overall security risk remains contained). Social Media were on top as well: they have been crucial for the Wind of the Changes blown by the Arab Spring but in the same time Social Media have raised many security concerns for reputation, the so called Social Network Poisoning (who remembers Primoris Era?). Although 2011 was the year of the Anonymous, hacktvism ranked “only” at number 4, behind Advanced Persistent Threats, which however played a crucial role for information security (an APT was deployed for the infamous RSA Breach, but it was not an isolated case).
Also botnets, web threats and application vulnerabilities ranked at the top of Security predictions for last year (and came true). As far as botnets are concerned, fortunately 2011 was a very important year for their shutdown (for instance Hlux/Kelihos, Coreflood, Rustock). In several cases the botnets were taken down thanks to joint operations between private sectors and law enforcement agencies (another prediction came true). On the application side, this prediction came true most of all thanks to the Sony breach, the Liza Moon infection and the huge rate of SQLi based attacks and ASP.NET vulnerabilities. We have also assisted to an hard blow to SSL/TLS and XML Encryption.
But what is more surprising (and amusing) in my opinion is not to emphasize which predictions were correct, but rather to notice which predictions were dramatically wrong: it looks like that, against the predictions, virtualization threats were snubbed by cybercrookers in 2011 (and nearly do not appear in 2012). But the most amusing fact is that no security vendor (among the ones analyzed) was able to predict the collapse of the Certification Authority model thanks most of all to the Comodo and Diginotar Breaches.
Another Certification Authority Breached (the 12th!)
This year is nearly at the end but it looks like it is really endless, at least from an Information Security Perspective. As a matter of fact this 2011 will leave an heavy and embarassing heritage to Information Security: the Certification Authority authentication model, which has been continuously under siege in this troubled year; a siege that seems endless and which has shown its ultimate expression on the alleged compromise of yet another Dutch Certification Authority: Gemnet.
Gemnet, an affiliate of KPN, has suspended certificate signing operation after an intrusion on its publicly accessible instance of phpMyAdmin (a web interface for managing SQL Database) which was, against any acceptable best practice, exposed on the Internet and not protected by password. As in case of Diginotar, another Dutch Certification Authority which declared Bankrupt few days after being compromised by the infamous Comodo Hacker, Gamnet has the Dutch government among its customers including the Ministry of Security and Justice, Bank of Dutch Municipalities and the police.
After the intrusion, the attacker claimed to have manipulated the databases, and to allegedly have been able to gain control over the system and all of the documents contained on it, although KPN, claims the documents contained on the server were all publicly available. Moreover the attacker claimed the attack was successful since he could obtain the password (braTica4) used for administrative tasks on the server. As a precaution, while further information is collected about the incident, Gemnet CSP, KPN’s certificate authority division, has also suspended access to their website.
The breach is very different, in purpose and motivations, from the one occurred to Diginotar, at the end of July, which led to the issuance of more than 500 bogus Certificates (on behalf of Google, Microsoft, and other companies). In case of Diginotar the certificates were used to intercept about 300,000 Iranians, as part of what was called “Operation Black Tulip“, a campaign aimed to eavesdrop and hijack dissidents’ emails. For the chronicles, the same author of the Diginotar hack, the Infamous Comodo Hacker, had already compromised another Certification Authority earlier this year, Comodo (which was at the origin of his nickname). In both cases, the hacks were performed for political reasons, respectively as a retaliation for the Massacre of Srebrenica (in which the Comodo Hacker claimed the Dutch UN Blue Helmets did not do enough to prevent it), and as a retaliation for Stuxnet, allegedly developed in a joint effort by Israel and US to delay Iranian Nuclear Program.
But although resounding, these are not the only examples of attacks or security incidents targeting Certification Authorities: after all, the attacks against CAs started virtually in 2010 with the infamous 21th century weapon Stuxnet, that could count among its records, the fact to be the first malware using a driver signed with a valid certificate belonging to Realtek Semiconductor Corps. A technique also used by Duqu, the so called Duqu’s son.
Since then, I counted 11 other breaches, perpetrated for different purposes: eavesdropping (as is the case of the Infamous Comodo Hacker), malware driver signatures, or “simple” compromised servers (with DDoS tools as in case of KPN).
At this point I wonder what else we could deploy to protect our identity, given that two factor authentication has been breached, CAs are under siege, and also SSL needs a substantial revision. Identity protection is getting more and more important, since our privacy is constantly under attack, but we are dangerously running out of ammunitions.
(Click below for references)
The Beauty (RC4) and The BEAST (TLS)
Hard times for Information Security and for the authentication models it had been built upon. The inglorious falls of SecureID and Certification Authority Authentication models were not enough in this troubled 2011 and now it looks like the last authentication bastion was breached after Thai Duong and Juliano Rizzo unleashed their BEAST (Browser Exploit Against SSL/TLS) attack.
The attack exploits a well known vulnerability on CBC mode encryption algorythms (such as AES and 3DES) which affects SSL and TLS 1.0. CBC mode encryption divides the plaintext in fixed size blocks (usually 128 bits). In this mode of operation each block of ciphertext is not directly encrypted, rather, before undergoing the operation, is XORed with the previous Ciphertext. Of course the first block of the message may not be XORed with any previous Ciphertext and for this reason an hard-guessable random vector, called IV or Inizialization Vector is chosen to inizialize the encryption process.
During an encryption session (think for instance to an HTTPS session) several TLS messages are transmitted inside the same encryption channel and here come the troubles: unfortunately TLS 1.0 implementation does not use a new IV for each TLS message, that is the ciphertext of the last block of the previous message is used as the Inizialization Vector of the new message. Unfortunately this approach limits the unpredictability of the Inizialization vector: an attacker could in theory try to guess some plaintext somewhere in the encryption stream and inject a crafted plaintext so that if the encrypted output of that block corresponds exactly to the ciphertext of the block in which the guessed original message was encrypted, this means that the attacker’s guess was right. The attack is made possible in theory just because the CBC mode use the output of the previous block as the IV for the next plaintext block.
From a more formal point of view a nice and very clear description is reported at this link which I report in the following lines:
Consider the case where we have a connection between Alice and Bob. You observe a record which you know contains Alice’s password in block i, i.e., Mi is Alice’s password. Say you have a guess for Alice’s password: you think it might be P. Now, if you know that the next record will be encrypted with IV X, and you can inject a chosen record, you inject:
X ⊕ Ci-1 ⊕ P
When this gets encrypted, X get XORed in, with the result that the plaintext block fed to the encryption algorithm is:
Ci-1 ⊕ P
If P == Mi, then the new ciphertext block will be the same as Ci, which reveals that your guess is right.
The question then becomes how the attacker would know the next IV to be used. However, because the IV for record j is the CBC residue of record j-1 all the attacker needs to do is observe the traffic on the wire and then make sure that the data they inject is encrypted as the next record, using the previous record’s CBC residue as the IV.
So apparently nothing new under the sun, except the fact the attack scenario is higly unlikely since the attacker should find a way to guess some patterns and inject some well known patterns inside the encrypted channel unless…
Unless the attacker could inject a large amount of known malicious data at a time (in order to limit the guessable plaintext in each block) and use a Web server side method to inject them.
This is exactly where the two main features of the BEAST attack rely: what if an attacker could guess where the encrypted password is located inside the encrypted channel, and split the original block in several 16 bytes blocks in which a single byte contains the original character of the password and the remaining 15 bytes contain the malicious known padding? Quite Easy! The attacker should try “only” 2^8 (256) possible values in order to guess the first character and obtain the same encrypted output than the crafted plaintext. Once guessed the first character, he could obtain the IV for the next block from the ciphertext, and guess the next character of the password in the next block with the same method: the first byte is known to be the first character of the password, the second byte is the unknown quantity and the other 14 bytes contain the malicious known padding. Shifting up to the last block the attacker could obtain the password.
Of course in theory there is still a big issue consisting in the injection of the known pattern in the encryption channel. In order to overcome it the attackers used a method (for which so far few details were disclosed) leveraging Web Sockets, a technology which provides for bi-directional, full-duplex communications channels, over a single TCP Socket. In a meshed-up world, Web Sockets are used for instance when a Web Server redirects a browser to another server to get a certain content (for instance an embedded Image). In Web Socket models, the browser handshakes directly with the remote server and verify if the connection is ok from the first server (origin based consent).
The same article mentioned above delineates how Web Sockets may be exploited to perpetrate the attack:
Say the attacker wants to recover the cookie for
https://www.google.com/. He stands up a page with any origin he controls (e.g.,http://www.attacker.com/. This page hosts JS that initiates a WebSockets connection tohttps://www.google.com/. Because WebSockets allows cross-origin requests, he can initiate a HTTPS connection to the target server if the target server allows it (e.g., because it wants to allow mash-ups). Because the URL is provided by the attacker, he can make it arbitrarily long and therefore put the Cookie wherever he wants it with respect to the CBC block boundary. Once he has captured the encrypted block with the cookie, he can then send arbitrary new packets via WebSockets with his appropriately constructed plaintext blocks as described above. There are a few small obstacles to do with the framing, but Rizzo and Duong claim that these can be overcome and those claims seem plausible.
Although TLS 1.1 and 1.2 introduce a randomizaton of the IV for each message, the dramatic thing is that TLS 1.1 has been published in 2006 but it is far from being commonly adopted. The funny thing is that in order to mitigate the attack Web Servers should use a cipher which does not involve CBC mode, as for instance RC4 (back to the future).
Google servers already use RC4 while Chrome developers are testing a workaround. Will RC4 be enough to save the infosec world from the fall of authentication?
Related articles
- Tor and the BEAST SSL attack (torproject.org)
- Chrome and the BEAST (imperialviolet.org)
An Industry Wide Attack
9/9/2011: Globalsign admitted evidence of a breach to the web server hosting the www website:
Today we found evidence of a breach to the web server hosting the www website. The breached web server has always been isolated from all other infrastructure and is used only to serve the http://www.globalsign.com website. At present there is no further evidence of breach other than the isolated www web server. As an additional precaution, we continue to monitor all activity to all services closely. The investigation and high threat approach to returning services to normal continues.
Starting from March 2011, one might say that the authentication bastions have been crumbling one after another. In hindsight, one event in particular occurred during March 2011 has been mostly underestimated. Of course I am not referring to the RSA affair, but to the Comodo Hack, whose only blame was to happen too close in time to the RSA Breach, which ended up obfuscating its impact for the Information Security Landscape … At least until August 2011.
As a matter of fact when, immediately after the Comodo Hack, the so called Comodo Hacker published on pastebin his declaration of Cyberwar, no one considered the hypothesis that other Certification Authorities could have been equally compromised. Consequently, although the hack was classified as a serious cyberattack, driven by a political matrix and capable to establish a new (unwelcome) record, it was considered an isolated episode, mainly due to the scarce attention to application security by the targeted Comodo partner. Moreover the final target (Google) and the political reasons behind the attack deserved much more attention than the means used to perpetrate the attack itself: the first-time compromission of a Certification Authority, a completely inedited attack vector.
Nearly four months later, the Diginotar hack (again an attack with alleged political reasons behind although according to Trend Micro it targeted Iranian Internet users) has shown to the world the weaknesses of our authentication model and its chain of trust. Not only the hacker was able to forge more than 500 fake Code Sign and SSL certificates, but he also claimed to have access to other four CAs, quoting explicitly GlobalSign, and indirectly another one StartCom, which was able to avoid the hack since its CEO was sitting in front of the HSM during the attack, although the Comodo Hacker claims to own email, DB Backup and Customer data.
Trust in Diginotar Certificate Authority has been revoked from all browsers and OSes, permanently from all Mozilla Products, but not from Smartphones, with heavy consequences for the Dutch government’s PKIoverheid (PKIgovernment) program. Of course, easily predictable, the assertions from Comodo Hacker triggered panic between cert providers. On September the 6th GlobalSign decided to temporary cease issuance of all certificates as a precautionary measure and appointed Fox-IT to perform an intensive audit (Fox-IT is the same Dutch Cybsersecurity Company which performed the audit on Diginotar); on September the 7th Symantec released a statement to reassure their customers their infrastructure has been audited and it is not compromised. A similar announcement has been published by Thawte after an erroneous report from a Dutch Government agency according to which the Security firm had been breached. Unfortunately the story does not end here and although the Comodo Hacker promises further disclosures.
If I can spend few words on the question, the best way to describe it is to quote a statement from GlobalSign: “these claims (from Comodo Hacker) represent an industry wide attack”. Said in simple words: the aftermaths of the Diginotar hack will force to rethink the current authentication model and chain of trust (even because authentication technologies and vendors are increasingly tied) even if we seriously risk to run out of ammo: in this year we lost tokens and CAs… Now What Else?






