(or, how many cool words can you fit into one title)

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:

[The MiniDuke Mystery: PDF 0-day Government Spy Assembler 0x29A Micro Backdoor.PDF]

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.

There are many remaining mysteries in the Gauss and Flame stories. For instance, how do people get infected with the malware? Or, what is the purpose of the uniquely named “Palida Narrow” font that Gauss installs?

Perhaps the most interesting mystery is Gauss’ encrypted warhead. Gauss contains a module named “Godel” that features an encrypted payload. The malware tries to decrypt this payload using several strings from the system and, upon success, executes it. Despite our best efforts, we were unable to break the encryption. So today we are presenting all the available information about the payload in the hope that someone can find a solution and unlock its secrets. We are asking anyone interested in cryptology and mathematics to join us in solving the mystery and extracting the hidden payload.

The containers

Infected USB sticks have two files that contain several encrypted sections. Named “System32.dat” and “System32.bin”, they are 32-bit and 64-bit versions of the same code. These files are loaded from infected drives using the well-known LNK exploit introduced by Stuxnet. Their primary goal is to extract a lot of information about the victim system and write it back to a file on the drive named “.thumbs.db”. Several known versions of the files contain three encrypted sections (one code section, two data sections).

The decryption key for these sections is generated dynamically and depends on the features of the victim system, preventing anyone except the designated target(s) from extracting the contents of the sections.

By the way, the 64-bit version of the module has some debug information left in it. The module contains debug assertion strings and names of the modules:

.\loader.cpp
NULL != encSection
Path
NULL != pathVar && curPos < pathVarSize
NULL != progFilesDirs && curPos < progFilesDirsSize
NULL != isExpected
NULL != key
(NULL != result) && (NULL !=str1) && (NULL != str2)
.\encryption_funcs.cpp

The data

The mysterious encrypted data is stored in three sections:

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.

So there seems to be another good security reason to use Google's Chrome browser, for those of you highly sensitive to security issues. Also interesting were some of the tricks they used to make it work. While they couldn't get it to work in pure javascript or flash, they implemented the exploit in a Java applet and attacked the stream between Firefox and https://paypal.com. The "tricks" they used to bypass "Same Origin Policy" with Java were surprising, and they came up with the entire stolen session cookie with which to log in to paypal.com as the victim over http in under three minutes. While I am sure that the other browser vendors will update their CBC encryption routines to better randomize their IV and overcome this attack as suggested almost ten years ago, one could use Chrome and maintain secure communications in regards to this exploit. To me, this exploit is a low risk one because of its impracticality. Whether they properly disclosed their work to all browser vendors, giving developers plenty of time prior to disclosure remains a question to me, but they did contact at least the Chrome team. Interesting research and impressive effort implementing a difficult to work concept certainly. These guys know crypto and communications technologies. But the sky has not fallen. Yet.

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?

As most travelers know, many airports and VIP lounges offer Wi-Fi connectivity but, unfortunately, these connection are rarely encrypted.   Here’s an example:

 
All data sent and received travels in clear text, which means anyone could intercept the data for malicious purposes.  This unencrypted data could include passwords, logins, financial information like PIN codes, etc.
Many people also know that it’s always better to use a VPN connection.  However, in many cases,  VPN connection are filtered out and blocked by rules on the network firewall. I tried two different protocols and both were blocked.  Mostly network administrators don’t allow using VPNs from Public WiFi access points only because they want to make sure the network isn’t be used for malicious purposes without any readable network logs.  These policies actually allow to the bad guys to launch really easy  man-in-the-middle  attacks when all traffic pass through a malicious host.

The reality is that using a public Wi-Fi service can expose your really sensitive data to cybercriminals. Recently, we saw some famous people lose their Facebook and other social network passwords by using open (insecure) Wi-Fi connections.

So what is the solution when your VPN is blocked? Well, in some cases, an SSL (https) connection may help. Please, before going to any Website, type in the address bar https:// and then the domain name. After the page is loaded, please check if the certificate used for encryption is a valid one and issued to the site you’re visiting. If you see something wrong with the certificate, stop using the site.
Another solution is to use a cable Ethernet connection instead of a WiFi. Many lounges have such connection as well; it will be much safer for you.
In any case if you’re connected from a public place, it’s better not to use eBanking or ePayment services. That data is the main target for criminals. So, travel safe and keep your personal data safe as well!

Back in the Middle Ages, a password was exactly what it said: a simple word that could be used to gain access to a castle, a secret meeting or any other closed area. These days it’s less likely to be a word, but rather a string of characters like “hTfd4Xz”.

There are situations where passwords don't need to be very complex, since the user will be forced to wait a couple of seconds after each attempt (e.g. when logging on to a server), or because the system will block further attempts after a wrong password has been entered several times (e.g. ATMs). This means that simply trying all possible variants (a brute force attack) isn’t going to be very useful.

However, the story’s very different for encrypted data devices – if they fall into the wrong hands, an attacker can just plug them into his computer and try out all passwords without any limitations.

Most encryption programs don't ask the user to enter the encryption key itself, but a password which is then used to generate the final key. Like any password, one for an encryption program should be relatively complex. A hundred years ago a password like "King Richard" would have been adequate. But today it could be cracked within seconds, using a dictionary attack.

Just ten years ago, 40 bit keys and passwords were seen as “secure enough”. But once again, today it would take just a couple of hours to try all the possible variations.

Nowadays, 128 bit should be the minimum and 256 bit is becoming the standard. This is where the problem lies: if the data itself is protected using a 256-bit-key, the password should be the same length, otherwise the high-level encryption itself is useless.

Let's assume that upper case, lower case and numbers are all valid password characters – that gives 62 possibilities per position. With 43 positions, there are about 1.18e+77 possible variants, which is close to a 256 bit key (1.15e+77 possibilities). But who can memorize a password with 43 characters- for example, "jZ85xfbgGjf52d2sS8gd43ahfFR5rG3qZ4wF425FfVf"? And who has enough time to even type such a random string of letters and numbers? And such passwords are hardly likely to motivate users to change them regularly, which is of course recommended.

So what other options are there? Tips like creating passwords using the initial letters of easy to memorize sentences (e.g. "My cat likes to bounce off my furniture" -> "Mcltbomf") aren’t very helpful – the statistical likelihood of certain letters occurring decreases the randomness of such a password, and therefore its usefulness. Such passwords might make the user feel better, but they don't provide any real security.

Let's face it: the power of today’s decryption technologies has overtaken our ability to memorize complex passwords. Until someone invents a way to extend human memory, a password stored on a USB token or other device is the only answer - with the associated risk that the device might be stolen together with your encrypted data.

It’s sad, but true - when it comes to data encryption, the password has had its day.