Monday, February 11, 2013

Cyber-espionage tool - Gauss

[Note: This post was written in August 2012 but I never finished it to my satisfaction so it didn't get posted. Posting it here now because I loved this font signaling trick and wanted to write about. One advantage of posting 6 months later is I can report on what they found after 6 months of analysis, see below.]

Kaspersky has been spearheading a rash of discovery and analysis of advanced cyber-espionage tools that they (and others) are attributing to "nation-states". Stuxnet broke ground in 2011 and eventually even the hardened skeptics admitted it was state sponsored... then came Flame, Duqu and now Gauss this summer.

I didn't write as multiple people have covered these topics at length, I'm pretty confident things are nearing saturation when my wife mentions them to me. But a couple of things are interesting. First, it seems that either nation states are getting more active in this space, or AV companies are getting better at detecting them. I'm curious which it is. Second, Gauss demonstrated that the authors learned from at least some of the mistakes that Stuxnet made. Particularly of interest to me was their use of an encrypted payload that was keyed to the system configuration and not reversible. (Unlike Stuxnet, which had a child-like "if PCI device address = xyz, than decrypt) approach. I'd considered this possibility 6 years ago when learning about ABE (Attribute Based Encryption), which enables the implementor to use attributes as part of the key in a one way function. In the case of Gauss, they simply hashed the %PATH%” environment string and the name of the directory in %PROGRAMFILES% so that analysts don't know what variables are necessary to unlock the encrypted payload.

Another interesting feature of Gauss is its installation of a custom font, called Palida narrow.

Kaspersky had no idea why it was installed. But the researchers at Crysys have some good hypotheses:

One possibility is that there are other components using Palida for some reasons. E.g., tricking with some characters on web pages to hide alerts, or similar, not really clear operations.
A very far-fetched idea is that Gauss uses the font for printed material. It actually tricks some parts of the system to substitute fonts with Palida, so any prints will contain Palida. Later, printed documents could be identified by looking on the tiny specialities of the font.
A third, and more probable idea is that Palida installation can be in fact detected remotely by web servers, thus the Palida installation is a marker to identify infected computers that visit some specially crafted web pages.

They go on to document how web developers could use CSS style pages to determine if a font is installed on a system or not. If the browser discovers it doesn't have the font it can be directed to a URL to retrieve the proper font file. By hosting this on a site controlled by the attacker they can determine if a given system has Gauss installed. A writeup with code is provided on the Crysys page.

Another possibility is the font is inserted to create a vulnerability that provides a backdoor into the system. Fonts have been used in attacks in the past, this could just be another opportunity for future access. More specifically, the TrueType font DLL was exploited by Duqu, which is alleged to be developed by the same people that developed Gauss due to their architectural similarities.

[Feb, 2013] The Wired article I linked to describing Gauss says that both Kaspersky and Crysys believe that signaling was the intent and I agree that is clearly most likely. Given the targeted, sensitive nature of the attack and the limited number of machines it was on (and lessons learned from Stuxnet landing all sorts of unintended locations) and the fact nobody has identified (or reported at least) a vulnerability resulting from the Palida vulnerability signaling just makes sense. Easy to check, subtle, and useful.

As of August 15th the Internet traffic on Gauss drops significantly and people were recognizing they had a serious, unsolved mystery on their hands and were setting out to crack it. An article on ZDNet in September points out it still hasn't been cracked. In December they posted about a cracking tool trying to target the MD5 hash used to protect the payload decryption targeting/fingerprinting module. (Which incidentally runs MD5 10,000 times... not surprising it hasn't been broken yet!)

February 5, 2013 the hack cracking tool was updated to a new version (see history here) and there was no information indicating anything other than a complete stonewall. (They still haven't cracked the encrypted payload or identified what the font is used for).

No comments:

Post a Comment

Share It