Detecting Ticketbleed (CVE-2016-9244)

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.

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.

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.

The two rules can be found on our GitHub Gists:

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

Identify packets containing SSL session identifiers:


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!

Malvertising: Not all Java from is legitimate

Isn’t it ironic getting a Java exploit via, the primary source for one of the most common used browser plugins? Current malvertising campaigns are able to do this. This blog post details a relatively new trend: real-time advertisement bidding platforms being infiltrated by cyber criminals spreading malware.




Malvertising has changed over the years starting with exploitation of weak advertisement management panels and has now evolved into pretending to be a legit third party advertiser with social engineering. The current malvertising techniques are quite deceptive and most of the times only noticeable at the client side.

Combating this malvertising technique is hard due to the large layered setup of the bidding platforms currently in place. It can be a malicious advertiser 3 layers down in the chain but it can also be on the 1st level. Trust is the current system many advertisers use but it seems to be insufficient for today’s malvertising campaigns and techniques, a new system needs to be implemented in order to combat them.

Findings in network monitoring

Over the last week, from Tuesday august 19th until Friday august 22nd, the Security Operations Center of Fox-IT’s ProtACT service observed multiple high-profile websites redirecting their visitors to malware. These websites have not been compromised themselves, but are the victim of malvertising. This means an advertisement provider, providing its services to a small part of a website, serves malicious advertisement aimed at infecting visitors with malware.

While monitoring network traffic to and from workstations we observed a higher than usual amount of infections. When investigating these incidents in depth we noticed that they were infected with advertisements served via high-profile websites. During this period at least the following websites were observed redirecting and/or serving malicious advertisements to their visitors:


The advertisement in this case included the Angler exploit kit. Upon landing on this exploit kit a few checks were done to confirm whether the user is running a vulnerable version of either Java, Flash or Silverlight. If the user was deemed vulnerable the exploit kit would embed an exploit initiating a download of a malicious payload, in this campaign it was the Asprox malware. This whole process of malvertising towards an exploit kit is also visualized in the image at the top of this post.
Please note, a visitor does not need to click on the malicious advertisements in order to get infected. This all happens silently in the background as the ad is loaded by the user’s browser.

One aspect of advertisement networks that makes tracking these threats really complicated is ‘retargetting’. Retargetting is the process of one or multiple ad and content providers leaving tracking data, cookies or other files, so the next time an advertiser can deliver different advertisement as was shown the previous time. A website that rents advertisement space can sometimes show retargetted advertisement without knowing. The way it works is that a user with an interesting set of tracking cookies and other metadata for a certain adprovider is retargetted from the original advertisement content on the website to the modified or personalized data. We have seen examples where the website that helped with the ad redirect to infect a user had no idea it was helping the delivery of certain content for a certain adprovider.

While half the world is already familiar with exploitation of browser plugins, keep in mind drive-by and water-hole attacks are not solely focusing on the common browsers. A couple of months ago we also noticed advertisement loaded by the ‘Skype’-application was also serving malicious content.

In both cases Fox-IT contacted the affected advertiser, AppNexus in these cases, to quickly stop the malvertising.

The problem

The biggest problem with these malicious advertisements is that separating good from bad is a difficult process in the world of online advertising. With specific schemes such as real-time bidding, bad advertisements can remain hidden for extended periods of time. The Dutch website has recently published a detailed article about the problem here.

AppNexus as an example for this case, is one of the companies providing real-time bidding on advertisements and is used by many of the top ranking websites.

What is real-time bidding?

Real-time bidding is a process many advertisers have to serve ads. When a user visits a website, for example, this triggers a bidding request among the affiliates of the advertiser who will get to see meta-data about the visiting user. This metadata can include: geographical location, browser type, and web browsing history. The affiliates in their turn then automatically bid on this impression. The highest bidding advertisers gets to display their ad. In the case of this malvertising campaign the malicious advertisers were the highest bidders. For more details please see

The Payload

The aim of the exploit kit is to execute a malicious file on the visitor’s computer to infect them. The Angler exploitkit has been observed to deliver different payloads in the last few days. Although the dropped malware can vary, Fox-IT has only seen the Asprox malware being spread with this campaign.

Update (August 27th): It was pointed out by Kimberly on twitter that it was in fact Rerdom that was distributed which we mistook for Asprox ( Although, Asprox and Rerdrom do have a close relationship and affiliate with each other. More about the Asprox ecosystem can be read here on the StopMalvertising website: [ Urgent eviction notification – A deeper dive into the Asprox Ecosystem ].

Asprox is a notorious spam botnet which has upped its game over these past few months by using the infected machines to perform advertisement clicking fraud. Since this move the actors behind this botnet have started spreading Asprox on a much larger scale, at first via e-mail attachments and now by employing various exploit kits. Statistics provided by FireEye provided back in May 2014 shows big fluctuations in the botnet size and botnet activity:

FireEye Asprox tracking

In 2013 Trendmicro also published a paper about Asprox which explained the variety of functionality of the botnet. While Asprox is known as a spam botnet to most the spam is only 1 component of a modular botnet called Asprox. Asprox has gone through many changes and modifications which includes spam modules, website scanning modules and even credential stealing modules. This history and current events show Asprox is still actively being developed and used.

Indicators of compromise

These IOC’s relate to the malvertising campaign on the high-ranked websites specifically. The advertisement content first redirects to: ( which will give redirects towards the exploit kit.

The exploit kit:

Domains that were observed:

  • (on port 37702)
  • (on port 37702)

PassiveDNS logging shows 3 IP’s having been associated with these domains:


All the exploit kit hosts were observed using port 37702. Running exploit kits on high ports at best prevents certain network tools from logging the HTTP connections, as these are typically configured to monitor only HTTP ports. It does mean this exploit kit is blocked on a lot of corporate networks as they do not allow for browsing outside the normal HTTP ports, port 80 (or proxy ports) and 443 for SSL.

The ‘Asprox’ malware:

Since this botnet makes use of a fast flux technique the domain names make for better indicators of compromise than IP’s:


The following MD5 hash was seen for the dropped payload:

  • Crypted payload: 554c5dbb12e3fd382ce16e5bb34a17c2
  • Decrypted payload: 5304bc5b9454e6bc5a0ba2bff0eba605


There is no silver bullet to protect yourself from malvertising. At a minimum:

  • Enable click-to-play in your browser. This prevents 3rd party plugins from executing automatically.
  • Keep all plugins running in the browser up-to-date using tools like Secunia PSI.
  • Consider turning off unneeded plugins if you don’t use them. For example, Java can be installed without the web-plugin component lowering the risk of exploitation and infection.

Usage of Adblockers

In cases of malvertising on websites ad blockers are usually effective in blocking redirects.
However, on the case of Skype on May 15th it would have been insufficient. Most adblockers are part of the Browsers as an add-on, incapable of filtering for other applications. Skype makes use of Adobe Flash to display certain advertisements, this happens to be a plugin which the Angler can exploit.

Fox-IT Security Research Team

Not quite the average exploit kit: Zuponcic

A couple of weeks ago at the FOX-IT SOC, we noticed Zuponcic attempting to infect one of our clients protected networks. The incident was caused by a person visiting the website of Suriname’s Ministry of Finance,

This post connects three recent developments in the realm of malware infections: .htaccess server compromise, the Zuponcic exploit kit and the Ponmocup botnet. It seems that the defacto standard of exploit kits is getting competition. Understanding how this exploit kit works will give you a better chance of defending against it and for identifying the .htaccess compromise on your server.

Looking back at clients that have been affected by Zuponcic there had been a significant increase in compromised websites serving this kit starting June 2012, including some relatively big Dutch websites along the way, such as and
This is interesting as websites hosting this kit have to be compromised due to the nature of the redirects. It seems the trend of using compromised website to attack users continues. As a sidenote, Zuponcic is not the actual name of this exploit kit, its real name is unknown. The first website it was found redirecting on was, this is where the name came from.

Analysis of the attack

The way in which someone has to land on a compromised website for Zuponcic to become active is very carefully crafted and the redirection process is dependent on multiple conditions. This process is started via an .htaccess file which is placed in every (sub)folder of the compromised host. This file makes sure the referrer is either a search engine, webmail or social media website and that crawlers are not affected by checking for known IP’s and user-agents. A sample of this .htaccess file on a compromised server:


If all of these conditions are met, the victim is redirected to the Zuponcic landing page via one of the 60 redirection patterns a single .htaccess file has to offer. These redirect patterns try to follow the ones seen in legitimate advertise networks. They imitate urls seen for OpenX, Google Ads and a lot of others, this to mask its true redirect purpose. In the htaccess the section of the fake advertisement URL redirects looks like this:


Mapping this whole redirection scheme in a flowchart looks like this:

zuponcic_redirect_flowAfter the redirection process, Zuponcic carefully attempts to infect the victim, this type of attack is dependent on the victims setup. The flow for the attack looks like this:


Zuponcic only targets Java on the clients from what we have seen. Besides Java exploits, Zuponcic also tries to social engineer the user. When a victim does not have Java enabled or the browser used is not Internet Explorer, a ZIP file is presented. This file has to manually be downloaded and executed by the victim. To make the download seem appealing, a form of social engineering is used by having the name of the ZIP file consist of two random triggers words in combination with the keyword(s) used in the search engine.


The attack initiated when a victim uses Internet Explorer 8, originally described on Malwageddon’s blog, used a signed Java Applet to perform a drive-by.

The Java applet is signed with a valid certificate which is most likely stolen. During the Zuponcic campaign three of these certificates have been spotted. The two certificates originally used belonged to Triton IT d.o.o (UserTrust) and R.P. InfoSystems (VeriSign). After both of these had expired the switch was made to the certificate owned by “Kurz Instruments, Inc.” (GlobalSign), and is currently still being used:

Kurz Instruments Inc Certificate

We have seen the following 3 certificates being used on the different Java exploits used by Zuponcic:

  • Subject: Kurz Instruments, Inc.
  • Fingerprint: 8A:DC:2D:8B:B5:3C:DC:93:C9:80:C4:F6:C0:80:59:73:8B:88:19:16
  • Issuer: GlobalSign
  • Subject: R P Infosystems Pvt Ltd
  • Fingerprint: BB:48:74:0F:01:E6:7F:EE:A6:06:96:4B:D5:81:A7:30:BF:D0:54:D7
  • Issuer: VeriSign
  • Subject: iLoq Oy
  • Fingerprint: 76:90:09:5B:C3:FC:9F:9D:74:98:56:F6:E1:DD:22:C0:89:44:F7:F9
  • Issuer: VeriSign

If a victim uses Internet Explorer 10, a JAR file is sent to at that person to be downloaded. The JAR, named with the same pattern as the ZIP file, contains the embedded payload. The payload is again RC4 encrypted. Interestingly enough the key is based on the hash of the victims IP. A snippet of this can be seen in the deobfuscated Java lines below:


For all instances the payload is the same: Ponmocup. Hashes for the two signed Java exploits seen being used:

  • 8d7028a0a0bf1e98fe90b5c3abb19059  (IE10.jar)
  • caa4cbe00c30458198a05a0cddddc1cd  (IE8.jar)

Hashes for samples we have seen (they are repackaged almost every time so this list will keep growing):

  • eb958d6e68cc635df16ade31227f0608  (bar__installer.exe)
  • bf1bd2fe9531224b619603cdaa575d61  (clickme__go.exe)
  • 9fd575356db4dc48a7c9f99de4fc358d  (daily_tool_.exe)
  • 7b9f5ba2ef5a6b94a4380be66e08e33f  (fixer__setup.exe)
  • aafa234b5db771d8df18c0f6719f264e  (folder__auto.exe)
  • 4888fafc13ad367954d96c0d913c316e  (full_setup_.exe)
  • 207c4ffd729c946ce261da6143c633fb  (instant_runme_.exe)
  • 6377d0a5bb8d183e8c3769016967f9fc  (internet__auto.exe)
  • c9e180a512f226a4c9da30c11498bfcd  (internet_setup_.exe)
  • 2f30863d70dbfb119c4b7185f5f7023a  (now_run_.exe)
  • 0dce01b2e5b566fc23da6f5a42d4ab8c  (private_www_relisound.exe)
  • 78cf24f2f6beeb9e4b2cb051073af066  (pure__run.exe)
  • f5835ab4ed47f1525a8da75e5134d452  (total_relisound_www.exe)
  • 244100de819e9943a1b76098a1f4d67a  (video_install_.exe)
  • 0f6280fce950601aca118be6312e0bfd  (viewer_relisound_www.exe)
  • 50d8bf638bd60c81de1790c2e0725a98  (windows__auto.exe)


The .htaccess compromise, Zuponcic and Ponmocup campaign have all been described seperately, but a connection has never been made between the three. From what we have seen it seems Ponmocup is behind this exploit kit as the only files ever seen being dropped from this are Ponmocup payloads. If you want to know more about Ponmocup, Tom Ueltschi has been investigating this botnet for a while now, read about it on his blog.

The amount of websites seen redirecting to this exploit kit is not as big as some of the others out there but what stands out are the ranking of these sites. They all have a lot of traffic and appear as the first domains for many frequently used search queries. This correlates with their method of redirecting for users only coming from the search engines.

Maarten van Dantzig, Yonathan Klijnsma & Barry Weymes, Security Specialists at Fox-IT

DNS takeover redirects thousands of websites to malware

Starting on Mon, 5 august 2013, 06:57:30 Fox-IT’s monitoring service detected a redirect occurring initially on 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 was compromised we found out that the DNS servers were giving back responses with the same IP every time:

The nameserver responses for as an example:

;; ANSWER SECTION:        300        IN        NS        300        IN        NS
;; ADDITIONAL SECTION:        7200        IN        A        7200        IN        A

Analysis of the attack

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

Malicious iframe

The host at the time was responding with 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/1.1" - - "-" "Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0"
"GET HTTP/1.1" - - "" "Mozilla/5.0 (Windows NT 5.1; rv:21.0) Gecko/20100101 Firefox/21.0"
"GET HTTP/1.1" - - "-" "Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_32"
"GET HTTP/1.1" - - "-" "Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_32"
"GET HTTP/1.1" - - "-" "Internet"

The first request is to 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:

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


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

XDocCrypt/Dorifel – Document encrypting and network spreading virus

Another day, another malware, and today it was an unknown Delphi application which encrypts your office documents on your non-root and non-CD/DVD drives and prepends it with a copy of itself, turning a document into an executable. Great, everybody loves these kinds of things as your entire IT dependant organization will grind to a complete halt if it hits your organization. So, how did people get infected by this? Well as it seems it was not a drive-by exploit on a large news site or some compromised advertisement server which caused this malware to run, but instead an already existing ZeuS variant named Citadel which downloaded and executed “a.exe”.

Should you worry about all those encrypted document files on your network…, what you should really worry about, is that there apparently was/is a trojan (ZeuS/Citadel) on your network that was doing active C&C communications and has been leaking all kinds of information from your organization for days, weeks or perhaps even months. And apparently none of your IT security defenses has removed it, has blocked it and neither has signaled you that there was something wrong on that system. If you were hit, you will likely start asking yourself some questions now… A properly configured IDS would have picked up the attack earlier and you would have been notified of the event.

Communication to the following IP addresses might indicate malicious behavior on your system:

So the big question is, why did it encrypt files… because it is not ransomware as it has no ransom note, the answer is, because they can. Interesting are also the references to the FGint library and RSA crypto, which was probably a failed experiment on behalf of the author. But RSA was not used for the encrypted documents, no it was something much more common in malicious software, actually the most common crypto apart from plain xor… RC4.

So, how would you recover such a file? Well the best method would be to use the RC4 key and use the standard RC4 implementation and decrypt the crypted document. You can find this from the separator “[+++scarface+++]” at offset 0x24a00 or 0x25000 depending on the infector version, and not forgetting to skip the last 7 0-bytes, otherwise Office will likely complain when opening the file. The RC4 key appears to be consistent in all versions: \x0d\x0a\x05\x0f\x59\x7b\x38\x5a\x5b\x36\x31\x69\x7e\x0d\x0d\x09

An alternative method for the less adventurous, or perhaps more adventurous users, if you actually run the file, it will decrypt and save a copy of the document to the same filename with “–.doc” appended to it and open it in the default application for that file type. In case nothing else works, or perhaps in case of modified crypto in newer versions and failing tools, this might be a quick way to recover an important file. Note: we do not advise this, but if you have to do this, please do it in a virtual machine without network connectivity. The actual function in the executable used for this is:

You can see in the function the separator of the file scarface, but encrypted with another common encryption function in malicious software, rot13. Other interesting strings are “SayHellotomyLittleFriend” a quote from the movie Scarface and “BreakingBad” a TV series.

The big question is of course, what is the purpose of this Trojan, one might suspect it is ransomware, but without a ransom note I guess that would be a no go. The fact that it infects shares means that it will spread to other systems that open the infected ‘documents’ on a share. Additionally HTTP based connection functionality suggests that the Trojan has additional download tasks and likely executes additional payloads on systems that have been infected. Given the Modus Operandi of this operation, it is likely that it downloads the Citadel Trojan and this entire attack was just to increase the size of the botnet through spreading of network shares. Currently however there appears to be no task defined and no additional malware is downloaded.

The interesting thing with this attack is that it appears to target NL pretty badly with over 2200 infections during the night, with the majority of the infections taking place in The Netherlands and only around 100 in Denmark and only few in other countries. The loader panel can be observed below:

All together it is a pretty interesting attack, which is obviously very visible due to the fallout with encrypted documents. And also due to the large amount of public sector organizations which were heavily affected by this attack.

Thanks to SurfRight for infected office document samples and the blog at for listing a lot of the information during the attack shared with the public.


SurfRight has provided a decryptor.

McAfee extra.dat file:

TrendMicro has detections for Dorifel / QUERVAR here.

MIME Sniffing: feature or vulnerability?

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.


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:

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.


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.

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’.


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

Onze visie op de eigen slagkracht van de overheid

Na operatie Black Tulip (Diginotar) en Lektober staat ICT beveiliging volop in de aandacht. Het is inmiddels algemeen bekend hoezeer onze maatschappij van ICT afhankelijk is geworden en hoe relatief kwetsbaar we zijn voor cyberbedreigingen.


De rol van de Nederlandse overheid is hierbij een onderwerp van discussie. De vraag is of zij voldoende in staat is om onze samenleving cyberveilig te maken en te houden. Omdat onze naam Fox-IT bij deze discussies regelmatig opkomt, lijkt het ons passend, dat wij onze visie hierop delen.


Allereerst ervaren wij de recente aandacht voor het onderwerp cyber security als positief. Een aantal maanden geleden werden binnen de politiek nog regelmatig serieuze vraagtekens gezet bij het realiteitsgehalte van cyberdreigingen. Inmiddels lijkt bij iedereen duidelijk geworden, dat we het niet over een fictief probleem hebben.


Wij zijn als nichespeler op dit gebied al geruime tijd actief. Wij hebben in die tijd specifieke kennis en vaardigheden kunnen opbouwen, waarmee we ons internationaal hebben kunnen onderscheiden. Het lijkt ons niet meer dan logisch dat deze expertise nog niet overal binnen de overheid aanwezig is. Het is gezien de recente incidenten wel van belang, dat de overheid deze expertise nu snel gaat opbouwen. De eerste stappen daarvoor zijn gezet in de vorm van een Nationale Cyber Security Strategie, een Nationale Cyber Security Raad en (binnenkort) een Nationaal Cyber Security Centrum.


Wij doen sinds enige tijd de oproep aan onze overheid om zich in haar beleid allereerst te richten op het zelf opdoen van concrete operationele kennis en vaardigheden. Op basis daarvan ontstaat ‘situational awareness‘. Daarna kan de overheid een leidende rol nemen om de vitale delen van onze maatschappij voldoende af te (laten) schermen. Het cyber security probleem vraagt volgens ons om deze regie.


Wij dragen graag ons steentje bij. Dat past bij onze missie: ‘het leveren van een technische, innovatieve bijdrage aan een veiliger samenleving‘.


Wij zijn er van overtuigd, dat we binnen Nederland dit actuele probleem kunnen ombuigen in een kans om ons internationaal te onderscheiden. Noem het maar De Digitale Deltawerken. Er is voldoende kennis binnen Nederland aanwezig. We moeten er alleen nog maar een paar slimme digitale dijken van bouwen..


For a more secure society!



Directie Fox-IT

Forbes: Bert Hubert explains the DNS issue with China

Sucked Into China’s Internet
It began with a jovial “Hi there!” on a fairly obscure listserv for discussing DNS operational issues. DNS denotes Domain Name System, a process that converts typed Web addresses into a series of phone-number like IP numbers which, in turn, enable you to “call up” a Web site from any of hundreds of servers.

Unlike the old days of phone calls, you don’t necessarily get directed straight to the person you want to speak to; in fact, for the Internet to operate the way it does, you might end up finding the Web site you want to read by going through a server halfway across the world. Usually, the system tries to connect you with the fastest server, which tends to be one fairly close by in geographic terms. But not always.

This is where DNS interacts with another acronym, BGP — Border Gateway Protocol. If DNS is an address book, think of BGP as a mapping program for Internet routers to reach that address. But neither technology is yet capable of authenticating valid addresses and routes, and not all servers are located in friendly countries.

Why is this important?

On March 24 Mauricio Vergara Ereche, a DNS administrator in Chile, noticed something distinctly odd in the routing of requests for Facebook, YouTube, Twitter and up to 30 other sites. Instead of retrieving the authoritative “.com” site, the Web users retrieved IP numbers located in China, which turned out to be completely different sites or error messages. It didn’t happen with every request, but it did happen with three requests originating from Chile and one from California that were routed through a server in Sweden.

Suddenly four people had been transported into China’s rigidly controlled Internet, although by whom and whether by design is unclear. As Dan Kaminsky, director of penetration testing at IOActive, cautions, attempts to interrupt route server traffic in flight have all the crudity of trying to pinpoint a target with a Scud: the effects are unpredictable and therefore the outcome may appear to be intentional when it really isn’t.

Even so, while China’s DNS servers routinely prevent its own people from accessing Facebook and other sites, this appeared to be the first time that Westerners trying to access Facebook were directed towards the same internal Chinese system of servers by a server inside China. Whether by error or design, China was redirecting global DNS traffic; its Great Firewall, which kept politically unacceptable material out, was sucking the outside world into the Chinese Internet. And if this could happen to Web sites, it could also happen to e-mail.

The first response on the listserv came from Bert Hubert of security company Fox-IT, a supplier of state-secret-level security solutions, and the founder of the software PowerDNS “Wow,” he wrote from the Netherlands. “This is stunning.” Rodney Joffe, senior vice president and senior technologist at Neustar, and one of the few people on the planet who knows how the Internet really works, told CNET. “This was a real world example of the Net security industry’s worst nightmare.”

But Joffe’s comment came at the end of the CNET article, which headlined the event in rather anodyne terms as a “mystery mix up.” PC World called it a “networking error,” inviting all but the hardened geeks to ignore the article, and the general media either focused on the clashes between Google and China, or continued speculating on whether people would swoon over or be flummoxed by Apple’s iPad.

“The media is not seeing the significance of this event,” says Hubert, via e-mail, “which is probably partially due to it not being explained very well…We struggle to explain these issues to our governments. At stake is little less than the ‘sovereignty’ of in-country Internet communications. In other words, can a country control where its e-mail goes. It turns out that it can’t.”

Because neither DNS nor BGP can yet establish “authenticity” — that the Facebook you download is the real Facebook — Internet users could, in theory, not just be denied access by being sucked into China’s Internet, they could be directed without knowing it to a simulacrum of Facebook or to any Internet site. Authenticating protocols exist, but by the time they would be widely implemented, they could be out-of-date.

The implications of a simulated Internet go far beyond censorship. “For example,” writes Hubert, “e-mail could be routed via untrusted servers that only make a copy but otherwise provide for high-fidelity retransmission.”

The dilemma for cybersecurity, says Kaminsky, is that the recent, exponential growth in fraud has created a crisis in law enforcement and, potentially, national security; and yet, at the same time, the Internet is not the kind of geopolitical environment where conventional law enforcement or statecraft easily apply. The Internet, says Kaminsky is a place where “non-state actors are the kings in a land without geography — or borders.” Imposing practical sovereignty by tightly controlling the fiber-optic links between countries is possible, but what will be the consequences for the Internet and economic growth if states start doing this? Kaminsky worries about states resorting to “clumsy tools to get that darn Internet under control,” and doing far more damage than good in the process.

Teasing out the implications of March 24 sent cyber and national security wonks into overdrive in Washington last week, with nary a comment from the press. Which is probably how government would prefer to deal with such issues. The consensus within the cybersecurity world is that there was one journalist who really had a handle on these issues — Brian Krebs — or rather, there was. The Washington Post laid him off on Dec. 31.

Trevor Butterworth is the editor of, an affiliate of George Mason University that looks at how numbers are used in public policy and the media. He writes a weekly column for Forbes.