One of our minions (he was introduced in this blog entry a while ago) recently came to us asking for advice: he was about to automate yet another task, by using his Python-fu, and realized that he misses entries in the file system as well as in the registry.
Notably, he only sees this behaviour on 64bit-versions of the Windows operating system:
Left: Windows Explorer (64bit) lists several folders and files. Right: Python application (32bit) only lists the folder Microsoft.
The left image shows the folder C:\Windows\System32\Tasks as seen in the Windows Explorer, the right image as seen in a simple 32bit-python application. Only the subfolder Microsoft is listed there. Something is amiss.
Below is the code to produce the right image, when executed in a 32bit-version of Python:
import glob, os
for pathfilename in glob.glob(r"C:\Windows\System32\Tasks\*"):
print pathfilename
On a daily basis we collect tons of Spam emails, which we analyze for malicious content. Of course, this is not done manually by our thousands of minions, but automated using some Python-fu. Python is a programming language that comes with many libraries, making it easy for us to quickly perform such tasks.
Python’s email library deals with, well, emails. And it does it well. But on October 3rd, we encountered an attachment that wasn’t there – at least according to Python’s email library.
Left: Outlook Web does not show the attachment Right: Thunderbird does show the attachment
Now how could that happen?
Emails do have a certain structure, which is described nicely in RFC #822, RFC #2822, RFC #5322, RFC #2045, RFC #2046, RFC #2047, RFC #2049, RFC #2231, RFC #4288 and RFC #4289. Even though these RFC’s are clear in their own way, an illustration might help (we focus on multipart emails only) to understand why Python’s email library got fooled.
While Trojans like Dyre and Dridex are dominating malware-related news, we take the time to have a closer look at Tinba (Tiny Banker, Zusy, Illi), yet another Trojan which targets Windows users. In the first part of this post, we give a short historical review, followed by hints about how to detect (and remove) this threat on an infected system. In the second part, we have a look at a portion of the Trojan’s code which enhances its communication resilience, and how we can leverage these properties for defensive purposes.
Tinba is a fine piece of work, initially purely written in assembly. CSIS discovered it back in May 2012, and it contained WebInject capability and rootkit functionality in a binary of just 20 KB. The source code of Tinba leaked in July 2014, helping bad guys to create their own, extended versions.
The source code of Tinba leaked in July 2014. Shown are some preparations to hook ZwQueryDirectoryFile.
Tinba on steroids was discovered in September 2014. Two main features are worth noting: First, each binary comes with a public key to check incoming control messages for authenticity and integrity. Second, there is a domain generation algorithm (DGA), which we will discuss later. In October 2014, Tinba entered Switzerland, mainly to phish for credit card information.
Tinba tried to phish credit card information.
Like other commodity Trojans, Tinba checks whether it is running in a virtual machine/sandboxed environment by checking the hard-disk size or looking for user interaction. According to abuse.ch, there was an intense distribution of Tinba in Switzerland early this year. Such spam campaigns can happen again at any time, so it is of use to know how to detect Tinba on an infected system and remove it.
Even though Tinba has the ability to hide directories and files (rootkit functionality), cybercriminals were wondering why they should bother using it. Why not simply hide directories and files with the “hidden” flag, which works for most users? Thus, it is relatively simple for a computer-savvy user to remove this version of Tinba from an infected (see instructions below).
A randomly named directory, which contains the Trojan itself, can be hidden by setting its attributes to “hidden”.
sagt sinngemäss Jeremiah Grossman [1], ein alter Hase im Bereich der Web Application Security. Zwar vertreibt seine Firma auch einen eigenen Webbrowser mit Fokus auf Security und vor allem Privacy, Recht hat er trotzdem: Täglich verwenden wir Technologien, welche das Etikett “Broken by Design” tragen (sollten). In diesem Artikel befassen wir uns mit zwei Themen: Cross Site Request (Forgery) CSR(F) und Certificate Authorities (CA). Die Probleme sind seit Jahren bekannt. Heute wurde gerade wieder ein CSRF-Exploit für WordPress 3.9.1 publiziert. Und ja, das ist die aktuelle WordPress-Version.
CSR(F) – Cross Site Request (Forgery)
Cross Site Request Forgery ist im Gegensatz zu seinem Bruder Cross Site Scripting nur marginal bekannt. Dennoch belegte CSRF 2010 in den OWASP Top Ten Platz 5, und im Jahr 2013 immerhin noch Platz 8. Es handelt sich folglich um eine häufige und durchaus kritische Sicherheitslücke in Webapplikationen. Doch was ist CSRF und was hat das mit “Broken by Design” zu tun?
Viele Webseiten binden externe Ressourcen, beispielsweise Bilder, Javascripts oder Werbung, ein. Das Adjektiv extern verweist hierbei auf eine andere Domäne. Ein Beispiel: Was geschieht, wenn man auf die Webseite einer typischen Schweizer Tageszeitung http://www.typischeschweizertageszeitung.ch/ geht?
Es werden Ressourcen von typischeschweizertageszeitung.ch geladen.
Es werden weitere Ressourcen von beispielsweise adtech.de, cxense.com, cxpublic.com, visualrevenue.com, wemfbox.ch etc. geladen.
Es werden von cxpublic.com wiederum weitere Ressourcen von 2mdn.net, serving-sys.com etc. geladen.
Diese Anfragen für externe Ressourcen nennt man Cross Site Requests. Und jetzt? Zunächst muss man sich fragen, wer denn diese Requests im Auftrag von typischeschweizertageszeitung.ch ausführt: der Browser. Anschliessend muss man verstehen, dass dieser Request unter Verwendung sämtlicher lokal gespeicherter Daten (insbesondere Cookies) für diese externe Domäne abgesetzt wird. Schauen wir uns ein relativ harmloses Beispiel an:
<html>
<head>
<script type="text/javascript">
function csrf() {
alert("Auf 192.168.1.1 läuft ein Apache Server unter OpenBSD.");
}
function nocsrf() {
alert("Test fehlgeschlagen, aber vielleicht funktioniert etwas anderes? ...");
}
</script>
</head>
<body>
<img src="http://192.168.1.1/openbsd_pb.gif" onload="csrf()" onerror="nocsrf()">
</body>
</html>
Im zweiten Teil dieser mehrteiligen Serie definierten wir den Begriff Ausführbare Datei und zeigten, was hinter Anti-Debugging steckt. Die Analyse der Malware war dynamisch, das heisst, der bösartige Code wurde effektiv ausgeführt – und das Analysesystem mit grosser Wahrscheinlichkeit infiziert. Wäre es daher nicht praktisch, die Analyse in einer virtuellen Umgebung durchzuführen? Mit einem Knopfdruck ist der saubere Zustand wieder hergestellt. Eine Idee, die auf der Hand liegt. Entsprechend haben sich die Autoren bösartiger Software dazu Gedanken gemacht und eine Technik entwickelt, diesen Umstand auszunutzen – Anti-VM: Läuft die Malware in einer virtuellen Maschine, so gehe davon aus, dass es sich um einen Malware-Analysten handelt und mache nichts böses.
Bevor wir darauf eingehen – lohnt es sich überhaupt das anzuschauen? Werden nicht bald alle Maschinen virtuell laufen? Schön möglich, aber im Moment nicht und die Anti-VM-Technik wird erstaunlich oft angewandt. Gemäss einer Untersuchung von Qualys [1] (im Jahr 2012) implementieren 90% der untersuchten Malwaresamples (4 Millionen Stück) mindestens eine Anti-Malware-Technik – mit über 80% bei weitem am häufigsten Anti-VM.
Anti-Malware Techniken. Quelle: Qualys 2012
Notabene: 2.9 der 4 Millionen untersuchten Malwaresamples greifen auf eine Anti-VM-Methode namens IN zurück – weshalb wir uns in diesem Artikel hauptsächlich damit beschäftigen.
Virtuelle Maschinen unterscheiden sich von physikalischen Maschinen. Diese Unterschiede können offensichtlich sein: Installierte Software (VMware-Tools), Laufende Prozesse (vmtoolsd.exe), Herstellerkennung der (virtuellen) Netzwerkkarte (00:0c:29:xx:xx:xx), Harddisk-Bezeichnungen etc. Aber einige Unterschiede sind erst in den Tiefen des Betriebssystems zu finden. Die erste Detektion einer virtuellen Umgebung auf nicht-triviale Art wird Joanna Rutkowska von Invisible Things Lab attributiert. Ihr Code aus dem Jahr 2004 wird häufig wie folgt zitiert[2]:
Im ersten Teil dieser mehrteiligen Serie führten wir in die Grundprinzipien von Maschinen- und Assemblerbefehlen ein und zeigten, was hinter Anti-Disassembly steckt. Es wurde kein Code ausgeführt, weshalb wir von statischer Analyse sprachen. Heute beschäftigen wir uns mit der Störung der dynamischen Analyse, im speziellen mit Debugging, und daher heisst diese Folge Anti-Debugging.
Was ist eigentlich eine ausführbare Datei? Wie erkennt ein Betriebssystem, dass abzuarbeitende Maschinenbefehle vorliegen und es sich nicht um ein Bild handelt? Das hat etwas mit dieser Folge zu tun? Ganz bestimmt.
Es ist nicht einfach, eine geschlossene Definition für den Begriff Ausführbare Datei zu geben [1], da je nach Situation unterschiedliche Konzepte greifen. Eine Datei mit der Endung .bat (Batchdatei) wird von einem Windows-Betriebssystem als Kommandozeilen-Skript interpretiert – und ausgeführt. Eine Datei mit keiner Endung aber bestimmten Bytes am Anfang wird wiederum als PE-Datei erkannt – und ausgeführt. PE-Dateien sind den meisten PC-Benutzern bekannt: Diese Dateien haben typischerweise die Endung .exe.
In dieser mehrteiligen Serie möchten wir Ihnen Techniken vorstellen, die das Leben eines Malwareanalysten erschweren, sprich abwechslungsreich und spannend machen. Im ersten Teil behandeln wir Anti-Disassembly und führen in die Thematik ein.
Warum macht ein Computer eigentlich, was er macht? Und was hat das mit dem Thema dieser Reihe zu tun? Zwei zentrale Fragen, welche im Folgenden beantwortet werden.
Entwickler erstellen Computerprogramme meist in einer Sprache, die intuitiv verständlich ist. Man bezeichnet das Ergebnis dieser Schreibbemühungen als Quellcode.
10 REM Hello World in BASIC
20 PRINT "Hello World!"
Viel kann der Computer (oder genauer gesagt die CPU) damit nicht anfangen. Der Quellcode muss in eine Sprache übersetzt werden, welche die CPU versteht – in eine Abfolge von Maschinenbefehlen.
SWITCH Security-Blog 