19 Feb Trust but verify: when CAs fall short Stefano Ortolani
14 Aug The Mystery of the Encrypted Gauss Payload GReAT
10 Feb When Certificate Authority Business Models and Vendor Certificate Policies Clash Kurt Baumgartner
24 Sep The SSL Sky is Falling? Kurt Baumgartner
18 May Lab Matters - Travel Tips: Stay Secure on the Road Ryan Naraine
Join our blog
You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.
On Feb 12th 2013, FireEye announced the discovery of an Adobe Reader 0-day exploit which is used to drop a previously unknown, advanced piece of malware. We called this new malware "ItaDuke" because it reminded us of Duqu and because of the ancient Italian comments in the shellcode copied from Dante Alighieri's "Divine Comedy".
Since the original announcement, we have observed several new attacks using the same exploit (CVE-2013-0640) which drop other malware. Between these, we've observed a couple of incidents which are so unusual in many ways that we-ve decided to analyse them in depth.
Together with our partner CrySyS Lab, we've performed a detailed analysis of these unusual incidents which suggest a new, previously unknown threat actor. For the CrySyS Lab analysis, please read [here]. For our analysis, please read below.
Key findings include:
• The MiniDuke attackers are still active at this time and have created malware as recently as February 20, 2013. To compromise the victims, the attackers used extremely effective social engineering techniques which involved sending malicious PDF documents to their targets. The PDFs were highly relevant and well-crafted content that fabricated human rights seminar information (ASEM) and Ukraine-s foreign policy and NATO membership plans.
These malicious PDF files were rigged with exploits attacking Adobe Reader versions 9, 10 and 11, bypassing its sandbox.
• Once the system is exploited, a very small downloader is dropped onto the victim-s disc that-s only 20KB in size. This downloader is unique per system and contains a customized backdoor written in Assembler. When loaded at system boot, the downloader uses a set of mathematical calculations to determine the computer-s unique fingerprint, and in turn uses this data to uniquely encrypt its communications later.
• If the target system meets the pre-defined requirements, the malware will use Twitter (unbeknownst to the user) and start looking for specific tweets from pre-made accounts. These accounts were created by MiniDuke-s Command and Control (C2) operators and the tweets maintain specific tags labeling encrypted URLs for the backdoors.
These URLs provide access to the C2s, which then provide potential commands and encrypted transfers of additional backdoors onto the system via GIF files.
• Based on the analysis, it appears that the MiniDuke-s creators provide a dynamic backup system that also can fly under the radar - if Twitter isn-t working or the accounts are down, the malware can use Google Search to find the encrypted strings to the next C2. This model is flexible and enables the operators to constantly change how their backdoors retrieve further commands or malcode as needed.
• Once the infected system locates the C2, it receives encrypted backdoors that are obfuscated within GIF files and disguised as pictures that appear on a victim-s machine.
Once they are downloaded to the machine, they can fetch a larger backdoor which carries out the cyberespionage activities, through functions such as copy file, move file, remove file, make directory, kill process and of course, download and execute new malware and lateral movement tools.
• The final stage backdoor connects to two servers, one in Panama and one in Turkey to receive the instructions from the attackers.
• The attackers left a small clue in the code, in the form of the number 666 (0x29A hex) before one of the decryption subroutines:
• By analysing the logs from the command servers, we have observed 59 unique victims in 23 countries:
Belgium, Brazil, Bulgaria, Czech Republic, Georgia, Germany, Hungary, Ireland, Israel, Japan, Latvia, Lebanon, Lithuania, Montenegro, Portugal, Romania, Russian Federation, Slovenia, Spain, Turkey, Ukraine, United Kingdom and United States.
For the detailed analysis and information on how to protect against the attack, please read:
We’ve recently experienced yet another case of a root certificate authority (CA from now on) losing control of its own certificates. And yet again, we have been waiting for either the CA or the browser to do something about it. This whole mess stems, once again, from both a governance and a technical problem. First, only the very same CA that issued a certificate can later revoke it. Second, although web browsers implement several techniques to check the certificate’s revocation status, errors in the procedure are rarely considered hard failures.
NULL != encSection
NULL != pathVar && curPos < pathVarSize
NULL != progFilesDirs && curPos < progFilesDirsSize
NULL != isExpected
NULL != key
(NULL != result) && (NULL !=str1) && (NULL != str2)
The files also contain an encrypted resource “100” that seems to be the actual payload, given the relatively small size of the encrypted sections. It is most likely that the section “.exsdat” contains the code for decrypting the resource and executing its contents.
A very important “internet trust” discussion is underway that has been hidden behind closed doors for years and in part, still is. While the Comodo , Diginotar, and Verisign Certificate Authority breaches forced discussion and action into the open, this time, this “dissolution of trust” discussion trigger seems to have been volunteered by Trustwave's policy clarification, and followup discussions on Mozilla's bugzilla tracking and mozilla.dev.security.policy .
The issue at hand is the willful issuance of subordinate CAs from trusted roots for 'managing encrypted traffic', used for MitM eavesdropping, or wiretapping, of SSL/TLS encrypted communications. In other words, individuals attempting to communicate over twitter, gmail, facebook, their banking website, and other sensitive sites with their browser may have their secure communications unknowingly sniffed - even their browser or applications are fooled. An active marketplace of hardware devices has been developed and built up around tapping these communications. In certain lawful situations, this may be argued as legitimate, as with certain known DLP solutions within corporations. But even then, there are other ways for corporate organizations to implement DLP. Why even have CA's if their trust is so easily co-opted? And the arbitrary issuance of these certificates without proper oversight or auditing in light of browser (and other software implemented in many servers and on desktops, like NSS ) vendor policies is at the heart of the matter. Should browser, OS and server software vendors continue to extend trust to these Certificate Authorities when the CA’s activities conflict with the software vendors’ CA policies?
With headlines like "New cyber threat compromises financial information - Experts say new threat could affect millions of sites", you would think that the trust model of the internet is finally crumbled.
Following an hour long Friday evening wait for the demo, the Ekoparty demo for the SSL hack was staged. And it was interesting that the attack succeeded in cracking the SSL confidentiality model as implemented by the Mozilla Firefox browser when communicating with paypal.com web servers over https. At the same time, it seemed to be an impractical exploit targeting a weakness that was fixed three months ago in Chromium source code.
Also of note, is the fact that the attack has been well known for almost 10 years, it's just that there hasn't been a practical exploit implementing the attack. And that they refined their blockwise attack model far better than previous chosen-plaintext attack models, making it more effective than prior attacks.
For related technical information, and thoughts from relevant developers and researchers, please check out my "Related Links" list to the right side of the post text. I try to be thorough in my selection.
UPDATE(9/26): Microsoft advises that they are investigating the matter for their Internet Explorer browser customers, stating that the issue is low risk anyways, "Considering the attack scenario, this vulnerability is not considered high risk to customers". Perhaps they were one of the browser vendors that were not contacted about the vulnerability.
For business travelers, the use of a laptop to stay connected to access business documents and connect to office resources is an absolute necessity. In this Lab Matters webcast, Kaspersky Lab malware researcher Stefan Tanase provides some general travel tips and advice to assist in protecting you, your laptop and your corporate data while you are on the road.
Since we posted about the compromised CA incident and related browser fixes, the incident has been labeled "Comodogate". Quite a bit of information has been released since then. There is even a voice that claimed responsibility for the breach, allegedly describing his attack and proving his success by disclosing a private key.
The CEO of Comodo (the Certificate Authority compromised in this incident) stirred an alphabet soup of speculation regarding attribution, or who may have performed the break-in and their motivations. At one point, he even compared the recent RSA incident as related, claiming the entire authentication layer of the internet is under attack. While the RSA-gate incident may seem to be coming from another, yet connected, part of the world, it was another attack on the trust inherent in authentication and cryptography services. There is more than a kernel of truth to the statement.
It is easy to say that authentication services are under attack across the internet. It's a lot like saying the browser is under attack in a flash of the obvious.
The voice that came forward and claimed responsibility for the attack and certificate theft posted the actual private key for one of the stolen certificates. It was data (outside of the CA and the true developers) only the thief could possess. You can verify the key yourself by following these instructions. He has done faceless interviews, he has assumed a twitter account and replied to all sorts of questions and tweets.
The author(s) is actively talking about his self. It's interesting reading the text from this voice, because its author is allegedly a source of the breakdown of the fundamental trust of authentication and trust on the internet as we know it. The voice comes across as though the reader should trust the character behind it. Can interested parties trust that this individual is *just* a 21 year old student as they claim? Why would you?