SWITCH Security-Blog

SWITCH-CERT IT-Security Blog

Sicherheit_Icon_virus_echt


Einführung in die Anti-Malware-Analyse – Teil 3: Anti-VM

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

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]:

int swallow_redpill () {
   unsigned char m[2+4], rpill[] = "\x0f\x01\x0d\x00\x00\x00\x00\xc3";
   *((unsigned*)&rpill[3]) = (unsigned)m;
   ((void(*)())&rpill)();
   return (m[5]>0xd0) ? 1 : 0;
}

…auch bekannt als “Red Pill”. Continue reading

News


IT-Security-Links #47

winkel_290x315px


Unser SWITCH Security-Report für Januar 2013 ist verfügbar

Die aktuelle Ausgabe unseres monatlich erscheinenden ‘SWITCHcert Reports zu aktuellen Trends im Bereich IT-Security und Privacy‘ ist soeben erschienen.

Themen diesen Monat:

  • Start-ups versprechen Hilfe zur digitalen Selbstverteidigung – und halten nicht immer Wort
  • Die Cloud-Branche sortiert sich neu – die Kunden auch
  • Das Weihnachtsgeschäft floriert – Karten- & Identitätsdiebstahl auch
  • Neues vom Mobile-Payment-Markt: Paypal setzt auf Bezahlen per Zuruf
  • 30. Treffen des Chaos Computer Clubs ganz im Snowden-Fieber
  • Facebook entgeht nichts – auch nicht das, was keiner wissen soll
  • Und wie immer Links zu spannenden Präsentationen, Artikeln und Videos rund um die Themen IT-Security und -Privacy.

Zum Download (PDF):

securityreport

Haben Sie einen unserer vorigen Security-Reports verpasst? Hier kommen Sie zum Archiv.

News


IT-Security-Links #46

Sicherheit_Icon_DNSSEC


SWITCH DNS/DNSSEC Audit

SWITCH is regularly assessing parts of the registry infrastructure in technical audits. The goal of these audits is to find operational or software vulnerabilities before attackers do. For 2013 we wanted to audit the DNS/DNSSEC related aspects of the registry and DNS name server service operation. The introduction of DNSSEC for the ch. and li. zones in early 2010 brought a lot of changes to our DNS management software, the registry application and to the registrar interface. Naturally, most changes occurred in the DNS management software, which is responsible for properly signing the zones and rolling the keys.

In 2009, when we started the DNSSEC project internally, mature support for DNSSEC was close to inexistent, so we ended up writing our own scripts and tools around ISC BIND. In the mean time BIND added support for inline-signing and OpenDNSSEC matured a lot, just to name a few examples. If you are on the verge of signing your zone, I suggest you look at already existing solutions first. I don’t think that today there is still a need to develop your own script and tools. However, ours have been in production since then. So we felt, it was high time to get an independent view on our implementation.

Continue reading