Category Archives: Uncategorized

XDocCrypt/Dorifel – Document encrypting and network spreading virus

Posted on by

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:

184.82.162.163

184.22.103.202

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 0×25000 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 http://www.damnthoseproblems.com/ for listing a lot of the information during the attack shared with the public.

Update:

SurfRight has provided a decryptor.

McAfee extra.dat file:  https://www.medusoft.eu/w32xdoccrypt-a/#.UCNwk03N-Ao

TrendMicro has detections for Dorifel / QUERVAR here.

MIME Sniffing: feature or vulnerability?

Posted on by

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.

Onze visie op de eigen slagkracht van de overheid

Posted on by

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

Posted on by

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 STATS.org, 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.