Dipl.-Inform. Carsten Eilers

Forscher von Kaspersky Lab sind seit einiger Zeit einer Gruppe von Angreifern auf der Spur, die sie wegen deren Vorliebe für Krypto-Algorithmen "Equation Group" genannt haben. Die Angreifer sind vermutlich seit 1996 aktiv und setzen eine Vielzahl von (unter anderem 0-Day-)Exploits und Tools ein. Darunter auch welche, mit denen die Firmware von Harddisks von über einem Dutzend Herstellern, darunter Seagate, Western Digital, Toshiba, Maxtor und IBM kompromittiert werden kann. Und die manipulierte Firmware kann dann den Rechner infizieren. Immer und immer wieder. Hey, erinnert das nicht irgendwie an BadBIOS? Laut Kaspersky kam dieser Angriff aber nur bei einigen ausgewählten Zielen zum Einsatz. Zu denen BadBIOS-Opfer und -Entdecker Dragos Ruiu wohl kaum gehört.

Die "Equation Group" nutzte unter anderem auch einige der von Stuxnet genutzten 0-Day-Exploits. Und das, bevor Stuxnet aktiv wurde. Das (und weitere Indizien) legt den Verdacht nahe, dass die USA hinter der "Equation Group" stecken. Denn dass Stuxnet von den USA und Israel entwickelt wurden, wurde ja bereits zugegeben.

Kaspersky hat angekündigt, in den nächsten Tagen weitere Details zur "Equation Group" zu veröffentlichen. Den Anfang mach eine allgemeine FAQ (PDF). Da bin ich ja mal gespannt, was noch alles raus kommt. Vielleicht können wir BadBIOS ja doch bald als bestätigt abhaken?

Carbanak - Klauen wird doch direkt vom Bank-Server!

Kaspersky Lab, Interpol, Europol und Institutionen verschiedener Länder haben einen groß angelegten Cyber-Raubzug aufgedeckt. Die Cyberkriminellen haben sich nicht mit dem "Kleingeld" der Onlinebanking-Nutzer zufrieden gegeben, wie alle anderen Cyber-Bankräuber bisher. Sondern ihre Schadsoftware gleich auf den Rechnern von Bank-Angestellten eingeschleust und sich direkt bei den Banken bedient. Ihre Beute: Bis zu 1 Milliarde US-Dollar bei bis zu 100 Finanzinstituten weltweit (Kompletter Bericht von Kaspersky Lab als PDF).

Nachdem die Schadsoftware per Spear-Phishing auf die Rechner von Bankangestellten praktiziert worden war drangen die Angreifer weiter ins lokale Netz vor und spähten die Arbeitsweise der Angestellten aus. Wobei sie auch auf Videoaufzeichnungen von Überwachungskameras zurück griffen. Wenn genug Informationen gesammelt waren ging der eigentliche Raubzug los. So wurden zum Beispiel die Buchhaltungen der Banken oder auch Geldautomaten manipuliert und Geld an die Cyberkriminellen überwiesen oder ausgezahlt.

Brian Krebs hat die Angriffe bereits im Dezember 2014 beschrieben, ebenso Graham Clueley. Deren Artikel basierten auf den Forschungsergebnissen von FoxIT und Group-IB (Bericht als PDF). Zu den Unterschieden zwischen Carbanak und dem von FoxIT und Group-IB "Anunak" genannten Angriffen hat FoxIT eine FAQ veröffentlicht.

Früher habe ich immer gesagt "Warum sollten die Kriminellen meinen Rechner angreifen, da gibt es doch nichts zu holen - die Server der Banken sind viel interessanter, da liegt das Geld!". Das war noch vor der Verbreitung von Online-Banking, und mit dessen Siegeszug begann bekanntlich auch der Raubzug der Cyberkriminellen gegen die Onlinebanking-Nutzer. Weshalb sollten die sich auch mit den gut gesicherten Bank-Servern herum schlagen, wenn sie viel leichter Millionen von Onlinebanking-Nutzern auf deren deutlich schlechter gesicherten Rechnern angreifen konnten?

Inzwischen werden zwar nicht unbedingt die Rechner an sich, aber doch zumindest das Onlinebanking immer besser geschützt, so dass sich die Hintermänner von Carbanak wohl gesagt haben "Wieso mit dem Kleinvieh abgeben, schlachten wir doch gleich die dicke, fette Geldkuh!" Und das im Grunde mit den gleichen Taktiken, die sie gegen die Onlinebanking-Nutzer erfolgreich genutzt haben: Daten ausspähen, Überweisungen manipulieren. Ebenso einfach wie genial, da muss man erst mal drauf kommen!

Der JASBUG in Windows - Gebt den Entdeckern etwas Ruhm!

Am Februar-Patchday hat Microsoft auch eine Schwachstelle namens "JASBUG" behoben. Interessant ist mal wieder der Grund für die Namenswahl. Wir hatten bisher zum Beispiel den Heartbleed-Bug in der Heartbeat-Erweiterung von OpenSSL, die ShellShock-Schwachstelle in der Gnu Bourne Again Shell, das "Padding Oracle On Downgraded Legacy Encryption", kurz Poodle genannt, in TLS - und jetzt gibt es den JASBUG.

BUG ist klar, das ist der englische Begriff für einen Fehler, wie er auch schon im Heartbleed Bug vor kam. Und JAS? Das ist ja wohl das, wo der Fehler drin steckt. Oder hat was mit dem Fehler zu tun. Sollte man jedenfalls erwarten. Aber nicht so in diesem Fall: JAS ist der Name eines der beiden Unternehmen, die die Schwachstelle entdeckt haben: JAS Global Advisors. Das zweite Unternehmen, simMachines, hat seinen Namen nicht im Namen des Fehlers verewigt. Was ich gut verstehen kann. Wer will schon, dass sein Name auf immer und ewig mit einem Fehler verbunden wird? Also ich schätze ja, langfristig IST das ein Fehler. Denn irgendwann wird man sich nicht mehr daran erinnern, dass JAS Global Advisors den JASBUG gefunden hat, sondern nur, dass die damit was zu tun haben. Vermutlich waren sie dann ja wohl dafür verantwortlich, oder?

Tatsächlich verantwortlich ist natürlich Microsoft. Ursache des Problems ist kein Implementierungs-, sondern ein Design-Fehler in den Gruppenrichtlinien (Group Policy), und der liegt lange zurück. So lange, dass die nun mit den Security Bulletins MS15-011 (kritisch, Remote Code Execution) und MS15-014 (wichtig, Umgehen von Schutzmaßnahmen, konkret sind MitM-Angriffe möglich) behobenen Schwachstellen nicht in allen betroffenen Windows-Versionen komplett behoben werden können: In Windows Server 2003 wären für das Beheben der ersten Schwachstelle so gravierende Änderungen nötig, dass es danach Probleme mit der Systemstabilität und manchen Programmen geben würde. Weshalb man auf einen Patch für diese Version verzichtet hat.

Die Schwachstelle wird unter anderem durch eine neue Schutzfunktion, dem abgesicherten UNC-Zugriff (UNC Hardened Access), behoben. Die erlaubt es dem Admin, verschiedene Anforderungen fest zu legen:

• RequireMutualAuthentication sorgt dafür, dass der Client die Identität des Servers überprüft, so dass ein Man-in-the-Middle bemerkt würde.
• RequireIntegrity sorgt dafür, dass die Integrität der Datenpakete über Prüfsummen gesichert wird.
• RequirePrivacy sorgt dafür, dass die Verbindung verschlüsselt wird.

Um in den Genuss dieser Schutzmaßnahmen zu kommen, müssen sie jedoch konfiguriert werden.

Weitere Details zur Schwachstelle gibt es in Microsofts Security Research & Defense Blog und auf der Website von JAS Global Advisors (mit einer Ergänzung).

Carsten Eilers