Fox-IT International blog

MIME Sniffing: feature or vulnerability?

May 8, 2012 by joostbijl

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

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

Posted in Uncategorized | Leave a Comment »

Critical analysis of Microsoft Operation B71

April 12, 2012 by joostbijl

A little over 2 weeks ago Microsoft announced operation B71. It was being brought as the biggest blow to ZeuS botnets in history, and was picked up in the media globally. A released movie showed Microsoft personnel executing a preliminary injunction in a civil case and seizing a server in Scranton, PA. In their words: “Hopefully this action will disrupt not only one but multiple botnets and allows Microsoft to get visibility into the criminal organization which really runs and develops the ZeuS family of malware”. A spokesperson for FS-ISAC said, “we have sat back and we have taken it, I think we need to go onto the offensive.” Also the former DHS Cyber Chief mentions that for Microsoft and the Financial Industry to combat these types of threats they need to work together. A spokesperson for NACHA mentions that fighting these threats is not as easy as finding individuals or groups that are causing these problems, but that they operate in very intricate networks in a very sophisticated way. Mr. Boscovich from Microsoft adds that they are very technical and very hard to identify and that they are hard to prosecute criminally.

We have some reservations on this whole operation, which in light of the above statements, will become very twisted and will leave you with an uneasy feeling. I suggest reading the entire article, so you can form your own opinion. Microsoft has actually released the affidavits (statements of facts) and accompanying documents on a website reachable at http://www.zeuslegalnotice.com/.

We have waited with publishing this response in anticipation of Microsoft publishing a statement of rectification on their recent operation b71 regarding some of the background on events that took place. This blog post will detail that background to some extent, so that the public knows and also the Microsoft customers and partners in this Operation b71 know what Microsoft did in order to offer their so called protection of their customers.

Seizing servers

So the movie shows that Microsoft seized one server. In total there were two servers seized, one containing an installation of a ZeuS variant named Ice-IX. This is a commercially available kit based off of the leaked source code of the original ZeuS. The other server functioned as a SpyEye controller, which was a Trojan very popular in 2011 but its popularity declined dramatically by the end of 2011 due to lack of updates. Ice-IX is 99.9% the same as the original ZeuS with some small additions and modifications. The last available SpyEye backend code was also freely downloadable from ‘The Internet’, so that is not going to reveal anything new.

If the code on these servers is not interesting what else could they have been looking for? Would Microsoft be able to find something linking to the actual criminals running these two seized servers? Very unlikely, especially with servers like these which are not bulletproof hosted. The criminals know those systems are going to be taken offline sooner or later and might be inspected. So they will leave as little or no information on these systems and also often the logging of the server is disabled, or if it is not, it only contains an IP address of a VPN gateway or Socks proxy that the criminals used to manage the server. All in all, we expect this will not reveal any information … at least not the supposed “visibility into the criminal organization which really runs and develops the ZeuS family of malware” as stated in the released video. One of the botnets was up and running again within 24 hours of the takedown on a brand new c&c server and continued with its business as usual.

Seizing domains

Another thing Microsoft did was seize a large number of domains used by ‘criminals’ for the purpose of pointing the malware on infected systems to the actual IP address of the C&C server. Not only for making communication to those domains impossible, well actually not at all, instead the domains were pointed to nameservers under control of Microsoft on the 24th of March 2012. The nameservers used were NS1 and NS2 at microsoftinternetsafety.net. Among the large set of domain names were old domains (from early 2011), parked, unused, expired and also legitimately used domains. This proves there was little to no verification done on the data by Microsoft or the Judges in this case. Looking for example at the .nl domains (page 14 of Prelim_Inj_Pt4.pdf) we see a number of sites which are just legitimate. Perhaps at some point in time these were used as an update server, redirect server or proxy for C&C traffic. This also directly indicates a lot of mislabeling of domains and their purpose, which as we now know was not just the case for the .nl TLD. For sure Microsoft has a very liberal interpretation of the word dropzone for example.

Now a problem occurred because a lot of the domains were not registered by criminals but by security companies and NGOs, who use these domains to look for communications by infected systems, with the intention of using it as a feed for ISPs and similar organizations to indicate that systems have been compromised with a Trojan. This process is called sinkholing, often this occurs through the registering of backup domains or domains generated by a domain generating algorithm. So these security companies and NGOs lost a part of their domains and thus a part of their intelligence feed, and were also marked as being potentially a contact for the criminals. These mistakes have not been fixed at the time of writing over 2 weeks after the domains have been seized, which can be easily observed as the sinkholed domains are easily recognizable.

An even more interesting part of this paragraph, is actually in the affidavits, linked above. In Debenham_Decl_Part_1.pdf act 113 it is mentioned that regarding the seized domains that are pointed to Microsoft controlled DNS servers, the A record will point to a server that has the following property: “The Microsoft computers are configured to capture only the IP addresses of computers that are attempting to establish contact. They are deliberately configured to break-off the communication before any content is received.”

An interesting statement as this is far from the reality of how it works. A simple test will show that a connection is actually setup completely to at least to port 80, port 443 and port 8080, with a full TCP handshake. This is already more than described above. Then the server will receive data, which includes not only a single packet of data, but multiple. At the end of Microsoft they are actually processing the packet data, seemingly specifically for HTTP formatted data. This means (and yes we tested it) that Microsoft will received the HTTP request with full headers and actually also POST data which will contain sensitive information about the victims, including usernames, email addresses , passwords and personally identifiable information. This definitely indicates that it is different from what was stated in the affidavits.

Statements and facts presented by Microsoft

In the affidavits you can find a great deal of that information that is freely available on the Internet. It is interesting to notice that this is presented as verifiable facts just because it was available on a website or as download. These websites and documents are statements of questionable source and it goes too far to actually go into every detail of each paper, but when I was reading it I found many presented facts which I know to be incorrect. For example one of the included whitepapers states that the latest version at the time of writing in 2010 of the ZeuS Trojan would be version 1.6, which is simply false. The last ZeuS version in the major version 1, is actually 1.3.X.X which was released by the end of 2009 and further updated with fixed in the beginning of 2010. And version 1.4 was actually never really released and not for sale, but was merely the beta version for the 2.0 release which was released in 2010.

Another statement on page 5 of Debenham_Decl_Part_1.pdf it is indicated that ZeuS was first identified in 2007, this is verifiable incorrect and it was researched in 2006 and it was published about in a great write up by Michael Ligh et al. This is another indication of sloppy research done on the end of Microsoft.

On page 2 of Debenham_Decl_Part_1.pdf, act 3, it is stated that ZeuS, Ice-IX and Spyeye can be seen as the same because they incorporate ZeuS code, and are from then on referenced to as “Zeus botnets”. To prove this fact there are appendices that claim to verify this fact, including a reference to a blog posting of the IT Security journalist Brian Krebs. Note that there has been a lot of talk about SpyZeuS and it being the next great threat to the worlds IT infrastructure and online banking in general, but in reality this was all make belief. Obviously SpyEye contains tricks used in ZeuS, obviously SpyEye supports the ZeuS webinjects format, as do a dozen other banking Trojans. Let’s just make a comparison, there is Windows and there is Linux, and both support NTFS, is it now logical to call Linux a Windows variant? No, they are both just an operating system, and SpyEye and ZeuS are both a Trojan.

Also in some of the statements such as the one in Debenham_Decl_Part_1.pdf act 22, you can see that the author writes that the email addresses of domain registrations can be used to contact john doe 1-39. This is a bit off as there has obviously been little to no verification that the domains were related to the unnamed defendants. Actually we are pretty sure they have not done anything like that, they have only supplied a pretty limited list of domains obtained from zeus and spyeye configurations.

Another interesting observation from our end is that in the documents we found no clear references to the usage of exploit kits, which is the main method of infection employed for infecting systems with banking malware. This seems odd and perhaps they did not want to overcomplicate things, or perhaps they wanted to put the focus more directly on the NACHA spam mails which is one of the plaintiffs.

On page 51 of Summons.pdf the actor named “duo” is apparently mislabeled as “D frank”, which is different from the declaration from Debenham.

John doe information

This last part brings us on the most interesting part of this whole write up on operation b71, we were surprised to see the contents of the Summons.pdf and the declaration of Debenham. This includes a lot of information on actors involved within the ZeuS operations, the SpyEye author and individual SpyEye users but also completely unrelated actors. This information includes nicknames, email addresses, icq numbers and jabber addresses.

And when looking at those details we found some interesting details on some of the described john doe’s. The information therein was 100% identical to information we had supplied to a certain mailing list. This mailing list has the restriction that data being shared can only be used with the permission of the person who supplied that data. The information was in exactly the same order and contained exactly the same amount of information on those john does that we and also a friendly information security company had provided. Since the order and amount of information was 100% identical, and the data then also being used out of context and misinterpreted, meant that the person who interpreted it did not have the right background to fully understand the data.

For us this felt as a major blow as we spent a lot of time in getting this kind of information, while a corporate giant like Microsoft is now using this information without reaching out to the persons who supplied that information, for their own marketing and public relation purposes. From our end we can confirm that this information was never supplied for the purposes that Microsoft used it for. This whole action of Microsoft brings a major blow to the entire information sharing between information security companies on mailing lists and working groups.

Closing statements

The actions by Microsoft were thus definitely disruptive, but not so much for the criminals as they can easily setup their botnets again, if they lost any in the first place. The cost of setting up a new botnet for those that might have been disabled is very cheap, for about 10,000 USD you can setup a botnet with about 100,000 systems from a single popular country, which will typically be enough for a quick return on investment. The disruptive effect on the information security industry and the public private partnerships which have emerged is however devastating. The level of trust and the potential losses in effectiveness of information collection is becoming a major issue with information sharing, especially when taking into account these kinds of leaks. What we will see in the near future and also already now is a hesitation of partnering organizations to provide information on what is current, instead only vague information will be shared that is not actionable.

To reference the words of the Former DHS Cyber Chief, that working together, he mentioned, has now become an interesting proposal . Everyone in the industry at least now knows Microsoft is an untrustworthy partner who will go through great lengths to betray those who it works together with and will not claim responsibility for their mistakes. In light of the whole Responsible Disclosure debate from the end of Microsoft this unauthorized and uncoordinated use and publication of information protected under an NDA is obviously troublesome and shows how Microsoft only cares about protecting their own interests.

Also in light of the statement made in the video “how the criminal networks are intricate and how the individuals are hard to identify”, letting them know you are looking for them, and exactly with what information is not really going to help anyone’s objectives apart from that of the criminals themselves. At the same Monday we saw several actors register new accounts and jabber addresses, and reintroduced themselves to their partners in crime. Obviously this will make future attempts to attribute information to a person difficult as now you have to not only attribute actions to a single identity but also link those two or multiple identities together.

When it comes to what the actual harm is, Microsoft has endangered the success of countless ongoing investigations in both the private as the public sector all over the world from east to west. Obviously as most of these folks are located in Russia and Eastern Europe, the cooperation between parties in those regions and in western countries on both public and private sector side has been hurt more than you can expect, and also years of trust building has potentially been lost. It is not so much about this individual investigation but more about the global issue of partnerships between countries and regions and also between the private and public sector. In our discussions with Law Enforcement Officers, private investigators and members of NGOs researching these threats from across the globe we have found nothing but disappointment and disbelief regarding the irresponsible actions executed by Microsoft. Various other researchers have outed their disappointment earlier:
http://countermeasures.trendmicro.eu/dont-be-dumb-keep-schtumm/ and https://twitter.com/#!/sempersecurus/status/184344304788045825

By the end of the Microsoft PR/marketing movie I was laughing out loud and at the same time crying. As if these people actually reside in a country where Microsoft can prosecute them and as if you can actually find them, when you actually have to steal intelligence collected by others in the first place. No, you know who is doing the real laughing now. That are the criminals, who are the ones that really achieved victory over the entire industry by Microsoft’s irresponsible actions.

Summary

To summarize what has happened, Microsoft has publicly announced a takedown of ZeuS, Ice-IX and SpyEye botnets and has listed a large number of domain names which are supposedly involved and attempted to seize all these domain names. The lists of domains were unverified and contained domains which had a legitimate use.

Microsoft’s declaration contained statements which were incorrect and even contain misleading information regarding the invasion of privacy regarding the victims of ZeuS botnets, as their personal information may end up in the hands of Microsoft.
A large amount of information that identify the so called john doe’s for this case, has no apparent source or is not verifiable to any extent in the published information. We know that a large part of this information was sourced from individuals and organizations without their consent, breaking various NDA’s and unspoken rules.

This irresponsible action by Microsoft has led to hampering and even compromising a number of large international investigations in the US, Europe and Asia that we knew of and also helped with. It has also damaged and will continue to damage international relationships between public parties and also private parties. It also sets back cooperation between public and private parties, so called public private partnerships, as sharing will stop or will be definitely less valuable than it used to be for all parties involved.

Advice for the future

This has obviously been a major setback for everyone involved, not only those directly involved but also slowly but surely for those who are fighting the same battle and who are now confronted with this issue. How things should have been done, where do we go from here? Well, the first step is communicating. When you are planning an action you talk about it with as many people you know are going to be affected by the actions you are going to execute. If you need a key piece of evidence supplied by someone else, ask that person if it is possible to use this information without risking their information position. This is not just a thing private parties should learn, but public parties as well.

A second step is sharing, which goes both ways, and sharing is caring. While it is not always possible to share everything, it is definitely worth sharing things, sometimes raw data, sometimes an analysis or for example indicators or advice. Doing this allows people to reach out to one another because they know they can help on a specific topic and this results to a better common understanding of the working topic. It is really not a shame that you have to admit someone else just knows more about a certain topic than you, and if you prove you can handle information without risking each others positions that is a perfect start for a working relationship.

Preventing misuse of the information shared is impossible; the only thing we can rely on is trust within a group, and the repercussions on abusing this trust. In the case of the recent events I can only conclude that it is going to take a long time before Microsoft has regained its trust with the rest of the industry, and it is unfortunately that a few bad apples have now ruined it for everyone else.

Apart from trust there is one more thing, and that is due diligence, there is no other explanation than Microsoft not having done any due diligence in their actions and verification of data and sources in this case. They wanted to have a quick win, they might have gotten their quick win, but in the process sacrificed a lot. The advice is, check where the data is coming from, check it with your sources, get the confirmation that you can use it. Do not proceed until you are sure everyone has agreed and everything has been verified as much as can be possibly expected from you. Listing and seizing sinkholes and legitimate domains should be limited to a few and not dozens as was the case here.

The good thing to note is, information sharing has not completely stopped, people are still exchanging information, but for how long… and what are they not sharing? Only time will tell how this setback will affect us all in the long run.

Michael Sandee, Principal Security Expert at Fox IT

Posted in Blog | 12 Comments »

Post mortem report on the sinowal/nu.nl incident

March 16, 2012 by joostbijl

March 14^th 2012, another normal day in the office, I looked at my massive to-do list and had planned quite some work for the day. And like every normal day my planning of the day is rudely interrupted by another incident. Our network analysts at the Security Operations Center looked very busy, and they were calling in for help from the Intel department. The SOC was very busy handling many incidents which started exactly from 11:30 CET. We analyzed the network traffic, the exploit kit and the installed Trojans and found it to be common Eastern European/Russian cybercrime components known as Nuclear Pack exploit kit, SmokeLoader and the Sinowal/Torpig/Mebroot Trojan. We contacted SurfRight to inform them this was happening, but fortunately they were already working on it. We had met with SurfRight a week earlier and discussed the problems with the Sinowal MBR infection and the lack of detection and removal in most current cleaning/removal products, they also knew about it and were still working on it. So this was a good time for them to invest some extra time into it, and with success as within a short time they were able to add detection and next day they had the bootkit cleaning functionality ready.

The second step was to investigate which site was responsible for the infection, typically on large websites which have many visitors a day, the infection comes from an advertisement. Possibly through a compromised advertising service redirecting many visitors to an exploit kit. This happened, for example, in August 2011. Interestingly that attack on OpenX ad server software was also used to distribute the Sinowal malware. Another method used is the purchase of legitimate advertisements for a certain country, and after the advertiser has checked the ads to be legitimate, modify the page to forward visitors to an exploit kit, this technique is known as malvertising. Malvertising actually requires money, so often stolen creditcards are used to buff the advertising account credits to allow many clicks before the credit runs out.

So, we started to look at the data we had available, when looking at network traffic it does not add any hints on where the compromise is, as the redirect is added to the DOM of the main page, so the referrer to the exploit kit is actually http://www.nu.nl. Due to the earlier incident in August 2011 I started looking at the downloaded content from the advertisement servers. Some time passed, it is painful work manually puzzling through all the data to find a needle in a haystack. Well, I could not find the source of infection, while our browser sandbox system indicated every hit for nu.nl was causing a redirect to the exploit kit. It started to puzzle me and only one thing remained, looking at the files of the nu.nl website itself, there was nothing which stood out on the main page such as a remote script, iframe or obfuscated javascript. I started to download the various javascript files where one stood out because it had a modification date of exactly 11:30:00 CET.

  HTTP/1.1 200 OK
  Server: Apache
  Vary: Host
  Last-Modified: Wed, 14 Mar 2012 10:30:00 GMT
  Cache-Control: max-age=86400
  Expires: Thu, 15 Mar 2012 10:31:54 GMT
  Content-Type: application/x-javascript
  P3P: policyref="http://www.nu.nl/w3c/p3p.xml", CP="NON DSP COR NID CURa ADMa DEVa PSAa PSDa IVAa IVDa OUR IND UNI COM NAV INT STA"
  Content-Length: 2290
...

Response headers of http://www.nu.nl/files/g.js

The javascript is obfuscated with a simple obfuscator, but when you would look at this manually it would be easy to skip it as javascript files are often packed or compressed to save bandwidth. The file was simple and for us only interesting to see where it would redirect clients, which was interesting as it redirected systems specifically with Windows Vista/7/8 to a separate location in the Nuclear Pack exploit kit. We were already in contact with nu.nl and forwarded the malicious script location to them and it was deleted soon after. Both the mainpage modification by including g.js and the script were added recently.

<script src=”hxxp://www.nu.nl/files/g.js” type=”text/javascript”></script>

After the file was overwritten with ‘OK’ at 13:23 CET by the nu.nl staff, the site still caused infections in our sandbox, we rechecked the main site and instead of g.js it now contained a link to gs.js.

<script src=”hxxp://www.nu.nl/files/gs.js” type=”text/javascript”></script>

This file was created before at 13:09:10 CET:

HTTP/1.1 200 OK
Server: Apache
Vary: Host
Last-Modified: Wed, 14 Mar 2012 12:09:10 GMT
Cache-Control: max-age=86400
Expires: Thu, 15 Mar 2012 12:27:41 GMT
Content-Type: application/x-javascript
P3P: policyref="http://www.nu.nl/w3c/p3p.xml", CP="NON DSP COR NID CURa ADMa DEVa PSAa PSDa IVAa IVDa OUR IND UNI COM NAV INT STA"
Content-Length: 2127
...

Response headers of http://www.nu.nl/files/gs.js

We informed the nu.nl staff of this change and at 13:42 CET the gs.js file was overwritten with ‘OK’ by the nu.nl staff. At this time we experienced no infections in our browser sandbox.

The amount of visitors to nu.nl around lunch time on a work day are of course huge, especially from corporate networks. The amount of alerts our Security Operations Center staff was getting combined with how effective the exploit for java typically is, with around one in eight visitors being infected, a little over 12%, led us to believe this was a huge incident and we scaled up our research efforts. At some networks there were hundreds of successful infections which, comparing to the previously referenced incident in August 2011, was of a completely different scale. Also the relative low profile presence of the exploit kit named Nuclear Pack, the use of newly setup hosts and URLs and the use of blocking of visitors outside of NL, which all results in less effective blocking by security products, such as blacklisting. Our educated estimation based on the amount of infections of previous incidents of similar scales makes it very plausible that the amount of infections is 100.000 or more, we found no hints that the related server hosting the exploit kit and C&C for SmokeLoader was overloaded, so that was not a factor that played any role during this infection campaign.

The exact time of publishing the initial g.js might indicate that there might have been a task for publishing introduced in the CMS system, which further increases the likelihood that this was a well planned attack. We suspect this because the exploit kit, the executables and the smokeloader C&C server were all created for the purpose of infecting visitors of nu.nl. The domains, urls and server were not blacklisted during the attack and the 2 smokeloader executables were virgin crypted and were not detected by any anti-virus product that we used to analyze the binary. Even 9 hours after the smokeloader Trojan executables were in the wild, the executables were not recognized by the majority of anti-virus products as can be seen at:

https://www.virustotal.com/file/e625fdb49695886ee2781d6e2c3755f7fc8c9c56ca208bdd14e51f11466abe10/analysis/1331756363/

https://www.virustotal.com/file/c667f39573b4bbd10aa26e841a9dda3ab0407de12606e9a58e16fc9427ce7dc1/analysis/1331756265/

The exploit kits were located at the following URLs:

Windows Vista/7/8 systems were redirected to:

hxxp://svitart .in/index.php?adaebb3f91ea88ba4bc624b6625e5d52
hxxp://svitchudes .in/index.php?9a41e20f564247648add4e6f1ec18e65

Windows XP and other systems were redirected to:

hxxp://accbud .in/index.php?4cfcb816db07831247fe5e2db2878634
hxxp://accent6 .in/index.php?0acb5dbb36f93141b027d416261af42e

A successfully exploited system through one of the three vulnerabilities will download and execute the following url:

/server_privileges.php?<random>=<digit>

An example:

/server_privileges.php?36d3677b09fc971f6d37ac96b1d2cf56=3

This will load files from the system which are located on:

hxxp://accent6 .in/files/load1.exe (for Windows XP and earlier systems)
hxxp://accent6 .in/files/load2.exe (for Windows Vista/7/8 systems)

Both files, load1.exe and load2.exe were uploaded on the exploit kit server at 09:26 CET on the 14^th of March 2012.

The IP addresses used for these exploit kits were 188.95.50.55, 188.95.50.56, 188.95.50.57 and 188.95.50.58 which were hosted in The Netherlands at serverboost.nl, and not in India as indicated by other publications. We provided the domains and the IP addresses to Spamhaus and also contacted serverboost.nl directly. Thanks to the quick work of Spamhaus, within a short time the exploit kit domains and the active and backup domain for the smokeloader bot were taken offline, and soon after the server itself was also taken offline which made the SmokeLoader botnet defunct, even if there were cached DNS entries. While the systems were still infected, the botnet was no longer under the control of the attacker.

The SmokeLoader Trojan is a resident downloader Trojan which has become more and more popular amongst cybercriminals since the end of 2011. Its basic purpose is to make sure the system remains infected and can be used to infect the system with other malware, other malware in the market are for example DLoader2010, MyLoader and Bredolab. This version was slightly different than previous versions we analyzed.

The Trojan main body is executed in a different way than most similar trojans, it creates a suspended svchost.exe using CreateProcessInternalA and not CreateProcessA, this is used to bypass userland hooking code used in some sandboxes, it creates a section in the current process, copies the Trojan body to it, and maps this section from the remote process. The Trojan body is a position independent block of code and data and not a full MZ executable. So it does not inject a complete decrypted Trojan executable in the remote process, but only the Trojan executable body which was also done similarly in the DLoader2010 malware family. It does not overwrite the existing svchost.exe binary completely in memory, but maps only the Trojan body in the suspended svchost.exe process and overwrites the entry point of the svchost.exe binary in memory with a push ret combination that pushes the location of the mapped Trojan body to the stack which causes the next return instruction to divert to the Trojan code block. The Trojan body decrypts itself and resolves its own imports.

The Trojan copies itself to the Application Data folder (Windows XP/2000) or AppData\Roaming folder (Windows Vista/7), and uses a filename based on the pVolumeSerialNumber, which it will xor with 0x6454263F and the last 6 characters of the result are used as the filename with appended .exe. To make sure the Trojan starts on boot It will create a registry entry pointing to the copied executable in:

HKEY CURRENT USER
Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
Stardock

The Trojan monitors this startup key and when it is deleted, it will add it again, using a watchdog thread. The Trojan code also keeps a file handle open to the executable to make it more difficult to remove.

This variant of SmokeLoader connected to the following urls for command and control traffic:

hxxp://prolesok .in /sml/index.php
hxxp://accedoproductmd .in /sml/index.php

The sent traffic is encrypted with xor and encoded by base64, but the downloaded binary is sent in plain over the wire. The decrypted traffic looks like the following:

cmd=getload&login=<botid>&sel=PiuPi&ver=5.1&bits=0&file=0&run=ok

The botid is calculated from the md5 of the computername with concatenated the pVolumeSerialNumber xor 0x6454263F, resulting in a 40byte string, which is used on the serverside to distinguish bots, which is stored in the cname column in the database, which is the unique key for the bot.

Extract from SmokeLoader database schema:

CREATE TABLE `bots` (
 `id` int(11) NOT NULL auto_increment,
 ...
`cname` varchar(80) NOT NULL,
...
`seller` varchar(5) NOT NULL,
 ...
PRIMARY KEY  (`id`),
 UNIQUE KEY `cname` (`cname`)
 ) ENGINE=MyISAM  DEFAULT CHARSET=cp1251 AUTO_INCREMENT=1;"

Extract from SmokeLoader PHP code:

mysql_query("INSERT INTO `bots` (`id`, `ip`, `os`, `country`, `time`, `cname`, `work`, `seller`, `bits`)
VALUES ('', '".$ip."', '".$os."', '".$country."', '".time()."', '".$login."', '1', '".$sel."', '".$bits."')
ON DUPLICATE KEY UPDATE time=".time().";");

Interesting is that the sel= parameter is the seller id which comes from the common use of having varying infection sources, in case you distribute your SmokeLoader binary via different methods or pay per install providers you can distinguish the number of loads of the SmokeLoader binary. In this case the seller nickname is ‘PiuPi’, which is embedded in the SmokeLoader binary, as you can see in the above database scheme the seller id is only five characters long. Interestingly the five characters match a user on AntiChat, a Russian language underground forum, which was compromised and its database leaked a few years ago. The full nickname is `piupiupo’ using a Yandex email address, a Russian free mail provider, and from the database leak we can see that in 2010 he logged in from a Russian IP address located in Moscow, which belongs to a consumer ISP.

Now comes the interesting part, the SmokeLoader C&C server distributed Sinowal, which has been around for a good 6 years now and has been active in The Netherlands from time to time since 2007. The SmokeLoader distributed a component known as ‘miniloader’, which downloads the installer component from the Sinowal installer server. On Windows 2000 and Windows XP it will install the MBR bootkit, which is used since the end of 2007 as the method of startup, which is also commonly referred to as Mebroot. Only a few security products are able to detect this modified MBR from a running system and even less are able to actually clean it. HitmanPro from SurfRight and Tdsskiller from Kaspersky are two products that were confirmed to remove the bootkit component on Windows 2000 and Windows XP systems. On Windows Vista and Seven systems the threat would install a userland component but we have not verified this during the nu.nl compromise.

We have investigated a couple hundred infections on corporate networks, but one odd thing appeared, the Trojan did appear to be malfunctioning, from all the infections we investigated, only one infection actually connected to the Sinowal command and control infrastructure that would indicate a successful infection. We are not sure why this happens and are unable to verify the reason for this. We have heard the same story from other researchers in the field and are not able to verify why this happens, but time will tell…

Michael Sandee et al

Principal Security Expert

Posted in Blog | Tagged mebroot, nu.nl, nuclear pack, post mortem, sinowal, smoke loader, torpig | 23 Comments »

RSA-512 Certificates abused in the wild

November 21, 2011 by joostbijl

During recent weeks we have observed several interesting publications which have a direct relation to an investigation we worked on recently. On one hand there was a Certificate Authority being revoked by Mozilla, Microsoft and Google (Chrome), on the other hand there was the disclosure of a malware attack by Mikko Hypponen (FSecure) using a government issued certificate signed by the same Certificate Authority. That case however is not self-contained and a whole range of malicious software had been signed with valid certificates. The malicious software involved was used in targeted attacks focused on governments, political organizations and the defense industry. The big question is of course, what happened, and how did the attackers obtain access to these certificates? We will explain here in detail how the attackers have used known techniques to bypass the Microsoft Windows code signing security model.

Recently Mikko Hypponen wrote a blog on the F-Secure weblog detailing the discovery of a certificate used to sign in the wild malware. Specifically this malware was embedded in a PDF exploit and shipped in August 2011. Initially Mikko also believed the certificate was stolen, as that is very common in these days, with a large amount of malware families having support, or optional support, for stealing certificates from the infected system. Apparently someone Mikko spoke to mentioned something along the lines that it had been stolen a long time ago. During the GovCert.nl symposium Mikko mentioned the certificate again, but now he mentioned that according to the people involved with investigating the case in Malaysia it likely wasn’t stolen.

The reason why Mikko looked at this specific sample and this certificate was likely the recent revocation of Digisign Server ID (Enrich) by Microsoft and earlier by Mozilla. The interesting part in those articles is that Microsoft does not mention anything about the code signing abilities of certificates while Mozilla does. Microsoft does mention that the certificates were not fraudulently issued but were duplicated due to cryptographically weak keys. The option of stolen certificates is left completely in the middle here.

The whole commotion around Digisign was actually caused by an investigation completed by Fox-IT in mid-October, in which we recovered a number of signed executables embedded in exploits and downloaded additionally by any of the executables. While our investigation did not focus on the signing of those executables, the report was shared in the relevant community, and if you looked at the 4 certificates initially found, it was easy to determine that all were 512bit RSA and used on HTTPS websites, which were still up at the time of writing. Later during our investigation we encountered 5 more certificates which also were used to successfully sign malware throughout 2011 by the same attacker, all 512 bit RSA.

So it is rather obvious what happened, all related RSA-512 keys had been factored and also abused to sign malicious software for the purpose of infiltrating high value targets. You might ask how difficult it is to execute an attack against RSA-512, well, over 12 years ago the RSA-512 challenge was successfully factored. Also we still encounter RSA-512 in protection systems deployed even today, with relatively modern hardware in a small cluster, relatively inexpensive, it takes a couple of weeks. With the lifetime of these certificates being a couple of years, the attackers had plenty of time to do the factoring.

So the reason why Digisign Server ID (Enrich)/DigiCert Sdn. Bhd, was revoked was because their certificates had no CRL in the certificate which allowed to easily revoke the certificate. Also all those certificates were issued without a purpose, in which case the certificates can be used for anything. The certificates we found to be used in the wild recently are:

lfxsys.lfx.com.my (Digicert Sdn. Bhd.)
webmail.jaring.my (Digicert Sdn. Bhd.)
mcrs2.digicert.com.my (Digicert Sdn. Bhd.)
ad-idmapp.cityofbristol.ac.uk (Cybertrust)
stfmail.ccn.ac.uk (Cybertrust)
skillsforge.londonmet.ac.uk (Cybertrust)
agreement.syniverse.com (GlobalSign Inc)
www.esupplychain.com.tw (TAIWAN-CA.COM Inc.)
ahi.anthem.com (Anthem Inc)

Additionally an external party found several other samples which contained 512 bit RSA certificates signed by Digicert Sdn. Bhd:

payments.bnm.gov.my (Digicert Sdn. Bhd.)
www.fbcm.com.my (Digicert Sdn. Bhd.)

One of those samples was found in August 2010, and possibly used back in March 2010, indicating how long this issue has been going on without any clear action from the industry. Microsoft whose platform has been targeted by this is the victim of this, and I think that Microsoft should not have relied on weak security properties for a security solution that can apparently be bypassed by parties far outside of the control of Microsoft. Microsoft could simply deny verification of executables which have been signed with a 512bit RSA key after a certain date, as 512 bit RSA has been considered weak for a long time. From the article at TechNet it is clear that Microsoft understand the problem and that they have acted on this accordingly, but the question is if it was not a bit late. Also interesting is that none of the samples have an actual timestamp, we think this is another design decision made that makes these executables pass verification, but it might cause the executables to no longer pass verification after the certificate has expired, we were unable to test this however.

Also one certificate that was used, ahi.anthem.com, did not have the “Digital Signature” property in “Key Usage”, thus it should not have passed verification. But we wonder if that indeed is true, as why would the attackers go through great lengths of factoring the RSA key and using it to sign their executables, if it did not pass verification? Either the attackers overlooked something here, or the digital signature verification system in Windows is at fault. We are however unable to verify this as the relevant certificate has expired in April 2011.

So the problem will solve itself eventually with CAs no longer signing 512 bit and more attention is given on the subject. The model of code signing certificates is however not very good as even the expensive code signing certificates can be stolen, and this can be done by simple off-the-shelf malware, such as ZeuS and SpyEye. But let’s focus on the issue at hand, how could we go about finding other certificates that might have been abused or could be abused, but that we do not have the executables from to prove it? Well someone already did all the work for us, that would be Peter Eckersly (EFF), Jesse Burns (iSec Partners) and Chris Palmer (EFF) who have worked in 2010 on EFF SSL Observatory that has indexed certificates used on port 443 (HTTPS). They have done presentations on this various times and we want to explicitly thank these guys for their hard work.

So we have used the database from mid-2010 which might be more close to the data the attackers had. So lets see, if we check the 9 certificates we have found being abused in the wild:

DigitalSignature Key Usage    Ext. Key Usage    RSA bits   Common Name
+                             -                 512        ad-idmapp.cityofbristol.ac.uk
+                             -                 512        agreement.syniverse.com
-                             -                 512        ahi.anthem.com
+                             -                 512        lfxsys.lfx.com.my
+                             -                 512        mcrs2.digicert.com.my
+                             -                 512        payments.bnm.gov.my
+                             -                 512        skillsforge.londonmet.ac.uk
+                             -                 512        stfmail.ccn.ac.uk
+                             -                 512        webmail.jaring.my
+                             -                 512        www.esupplychain.com.tw
+                             -                 512        www.fbcm.com.my

Bingo, they are all there, this is a good indication the people who found these certificates used a similar method to find these certificates, scanning port 443 (HTTPS) for valid 512 bit RSA certificates with no Extended Key Usage property defined and being usable. Note again that the ahi.anthem.com has no Digital Signature Key Usage property.

Okay, so now let’s see what other certificates there are in the database from mid-2010 which match similar search criteria, that were valid according the the certificates from Microsoft at the time and have not expired yet.

Key Usage    Ext. Key Usage    RSA bits   Common Name                    Issuer
DigSign
+            -                 512        www.altinokburo.com.tr         GlobalSign nv-sa
+            -                 512        mijn.trust-id.nl               DigiNotar B.V.
+            -                 512        applicaties-preprod1.digid.nl  DigiNotar B.V.
+            -                 512        as-preprod1.digid.nl           DigiNotar B.V.
+            -                 512        was-preprod1.digid.nl          DigiNotar B.V.
+            -                 512        applicaties-preprod2.digid.nl  DigiNotar B.V.
+            -                 512        as-preprod2.digid.nl           DigiNotar B.V.
+            -                 512        was-preprod2.digid.nl          DigiNotar B.V.
+            -                 512        supplier.sappi.com             GlobalSign nv-sa
+            -                 512        suppliertest.sappi.com         GlobalSign nv-sa
+            -                 512        mcrs2.digicert.com.my          Digicert Sdn. Bhd.
+            -                 512        mcrs.digicert.com.my           Digicert Sdn. Bhd.
+            -                 512        skillsforge.londonmet.ac.uk    Cybertrust

Okay, we can find two certificates in there which we know that have been abused, specifically skillsforge.londonmet.ac.uk and mcrs2.digicert.com.my, those have 512 bit RSA keys that have been factored. All other certificates seem to have been either revoked directly or indirectly, these are the ones related to DigiNotar and Digicert Sdn. Bhd/Digisign Server ID (Enrich). Others have been individually revoked after they have been replaced in the past. So, it looks like indeed the problem has been solved by revoking trust in Digicert Sdn. Bhd. and DigiNotar B.V. (unrelated) and revoking those specific certificates. We have not observed in the wild usage of other certificates such as the ones signed by DigiNotar, possibly there are other constraints which make it unusable for Code Signing. We will leave it as an exercise to the reader to inspect the other databases which the EFF SSL Observatory has created to find other certificates.

Concluding we can say that definitely there has been a lot of attention on Certificate Authorities and their procedures and also with several incidents such as the forging of data to match an md5 signature and the more recent DigiNotar incident. But this specific issue, while factoring is widely known, had not been addressed and has been used over a year for targeted break-ins of high value targets. While it has not been used for signing of drivers as far as we know, as was done with the stolen certificates used in the Stuxnet and Duqu attacks, it did play a part in the attacks we have observed and as such we think that letting the issue unaddressed for such a long time might have helped the attackers. It was trivial to find these certificates using published data by EFF and luckily it appears that all known certificates have now been revoked, but the question is if there are more certificates which have not been recorded in a database and have been, for example, used on other ports than HTTPS. The fact remains that the code signing mechanism is relying on trust in many parties which are not necessarily trusted, as human error and intentional or unintentional bypassing of procedures can break the entire security model.

Download the print version here.

Michael Sandee, sandee@fox-it.com
Principal Security Expert at Fox-IT

Posted in Blog | Tagged Certificates, RSA | 20 Comments »

Onze visie op de eigen slagkracht van de overheid

November 15, 2011 by cryptoron

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

Posted in Uncategorized | 1 Comment »

Presentatie Fox-IT op Infosecurity NL 2011

November 9, 2011 by joostbijl

Op 2 en 3 November 2011 heeft Eward Driehuis een seminar gegeven op de Infosecurity beurs. Onderwerp van het seminar is “Spotten van fraude in online bankieren via analyse netwerkverkeer”. Hieronder vind je de videoregistratie en de slides:

Posted in Eventreport | Tagged detact, infosecurity | Leave a Comment »

Over het CDA en het bestraffen van gebruik van crypto

June 2, 2011 by cryptoron

Nieuwe opsporingsmethoden hard nodig, maar dan wel de goede. Blijf van crypto af!

Gisteren voerde de tweede kamer een debat met minister Opstelten over Cyber Security in Nederland. Aanleiding was de in februari gepubliceerde Nationale Cyber Security Strategie. Die strategie moet Nederland helpen om digitaal veilig te worden. Over de strategie zelf heb ik al eerder geschreven. Het CDA heeft bij monde van Coşkun Çörüz gevraagd om nieuwe wetgeving rondom het gebruik van encryptie in bepaalde strafzaken. Als voorbeeld noemde hij het verhogen van de strafmaat als een verdachte zijn wachtwoorden niet wil afgeven. Als we Nederland werkelijk digitaal veilig willen maken, zou de overheid juist dit soort technologie moeten aanmoedigen. Wetgeving over het gebruik van cryptografie bereikt juist het tegenovergestelde. Daarnaast zou de politie geholpen zijn bij andere bevoegdheden om dit soort zaken wel effectief te kunnen aanpakken.

Aanleiding voor het CDA om met dit verzoek te komen is de zaak van Robert M. Robert wordt verdacht van het misbruik van vele kinderen. In zijn huis zijn beveiligde computers aangetroffen waarvan de politie de beveiliging niet kon doorbreken. Gelukkig heeft de verdachte uiteindelijk zelf zijn wachtwoord(en) afgegeven zodat de politie toch met het onderzoek verder kon.

In de wereld van kinderpornografie komen we heel veel cryptografie tegen. Deze pedofielen hebben een enorm hoog security bewustzijn. Ze schrijven goede handleidingen over hoe je jezelf moet beveiligen. Vaak gaat dat niet eens om beveiliging tegen de politie maar willen ze zichzelf ook niet prijsgeven aan familieleden die mogelijk van dezelfde computers gebruik maken. In deze handleidingen wordt verwezen naar goede software, en er zitten ook goede instructies bij. Bijvoorbeeld over hoe je een ‘sterk’ wachtwoord kiest. De tools zijn eenvoudig te vinden, makkelijk in gebruik en vaak nog gratis ook. Daarom worden ze niet alleen door de bad guys gebruikt, maar is bijvoorbeeld ook de laptop waar ik dit op schrijf versleuteld met precies hetzelfde programma dat Robert M. gebruikte.

De gebruikte software in combinatie met sterke wachtwoorden maakt het uiteindelijk ondoenlijk voor de politie om de versleutelde gegevens weer zichtbaar te maken. De politie staat er trouwens niet alleen voor. Ze kunnen een beroep doen op het NFI dat op dit gebied heel hoog aangeschreven staat. Toch zal het hen ook niet lukken, ongeacht hoeveel wiskundigen ze zullen aannemen of hoeveel kraakcomputers worden aangeschaft.

Wat hebben we nu al geregeld met sleutels en wachtwoorden in onze wetgeving? Op dit moment kan de politie in het kader van een strafrechtelijk onderzoek aan een ieder die een sleutel bezit afdwingen om deze af te geven. Ze mogen dit verlangen van zowel individuen als ook bedrijven. Alleen de verdachte zelf hoeft zijn sleutel niet af te geven. Dat is omdat we in Nederland een belangrijk uitgangspunt hanteren: De verdachte hoeft niet mee te werken aan zijn eigen veroordeling. Het CDA snapt ook wel dat we daar niet zo snel vanaf kunnen stappen, maar zoekt het in bijvoorbeeld een zwaardere straf omdat een verdachte zijn wachtwoord niet prijsgeeft. Ik neem aan dat de #whiskeyleaks juristen hier nog wel meer over zullen schrijven.

Een ander argument waarom dit een heel slecht idee is, hebben we aan Julian Assange te danken. Hij is namelijk een van de founding fathers van het concept Deniable Encryption. Een toepassing van deniable encryption werkt als volgt. Ik heb mijn harde schijf versleuteld. Als ik wil inloggen om gewoon mijn werk te doen type ik wachtwoord A in. Op verschillende luchthavens kan je gevraagd worden om een werkende laptop te tonen, en verlangen de security mensen daar ter plekke dat je je wachtwoord invoert. Natuurlijk wil ik niet dat die mensen mijn vertrouwelijke gegevens kunnen zien, en dan heb ik de mogelijkheid om wachtwoord B in te typen. Als ik dat doe, start ook keurig mijn laptop op, en zal je een versie Windows installatie tegenkomen. Daarin staan dus totaal geen vertrouwelijke gegevens. Wat nu zo aardig is van deniable encryption is dat je zonder kennis van de wachtwoorden totaal niet kan bewijzen dat er nog meer informatie op de harde schijf staat. Als het beveiligingsprogramma goed geschreven is, dan kunnen zelfs die knappe koppen bij het NFI het niet bewijzen. Als een verdachte dus niet op een andere manier verklapt aan de politie dat er nog meer geheimen op zijn computer staan, zal het nooit bewezen kunnen worden.

Het thema van het debat in de kamer ging over Nationale Veiligheid en in het bijzonder de cyber security strategie. Het doel van de strategie is om Nederland digitaal weerbaarder te maken. Een heel goed hulpmiddel daarbij is de inzet van cryptografie. Dat is ook waarom ik het zelf zo graag gebruik. En omdat ik het veel gebruik heb ik ook wel eens een beveiligde hardeschijf rondslingeren waarvan ik werkelijk het wachtwoord vergeten ben. We moeten toch niet een situatie creeren waarbij mensen bang worden om hun gegevens te beveiligen voor het geval ze ooit verdachte worden. Want gaat die politieman bij het verhoor geloven dat ik echt mijn wachtwoord vergeten ben?

Gelukkig zijn de meeste criminelen dom en laten ze zo veel sporen achter dat de politie toch al genoeg heeft om een zaak rond te krijgen. De groep van kinderporno liefhebbers is echter een bijzondere. Zij zijn vaak heel handig met computers en weten precies hoe je het de politie zo moeilijk mogelijk maakt. En ze hebben dan ook nog de discipline om zich daaraan te houden. Daarom is het van belang dat de politie de ruimte krijgt om in die gevallen goed onderzoek te doen. Dat kan bijvoorbeeld door de politie de bevoegdheid te geven om in kinderporno groepen te infilteren of te hacken. Jammer dat het CDA de minister daar niet nog een keer op heeft gewezen.

Posted in Opinie | Tagged cda, crypto, encryption, kinderporno, politiek | Leave a Comment »

Older Posts »