Im Zusammenhang mit meinem Posting "JTL-Wawi und das veröffentlichte SA-Passwort" stellte Ralph die Frage, wie kritisch es ist, wenn ich eine Anwendung nutze, die immer mit dem Sysadmin arbeitet. In dem Posting habe ich schon beschrieben, warum es für einen Angreifer ein so großes Geschenk ist an das SA-Passwort zu kommen. Kurz gesagt, er kann sich damit bislang meistens zum Administrator am Server machen.
Im konkreten Fall kann zunächst jeder Depp einen Angriff durchführen solange das im Internet veröffentlichte Default-Passwort nicht geändert wird. Gehen wir also mal davon aus, ein Admin ändert das SA-Passwort. Wie gefährdet bin ich dann als Nutzer so einer Software?
Wenn man einschätzen will, wie kritisch eine Lücke ist, dann muss man zwei Fragen beantworten:
- Wie schlimm ist es, wenn jemand die Lücke ausnutzt?
- Wie schwierig ist es, die Lücke auszunutzen?
Wie lauten die Antworten in diesem konkreten Fall, wenn die Software als Prozess am Arbeitsplatz ausgeführt wird?
Wie schlimm ist es, wenn jemand die Lücke ausnutzt?
Worst Case! Weil der SQL-Server-Dienst im Systemkontext läuft, ist der Server kompromittiert oder der Einzelarbeitsplatz kann komplett aus der Ferne übernommen werden, ja nachdem wo der SQL Server installiert wurde. Nichts ist mehr sicher, dem Angreifer ist nichts unmöglich.
Wie schwierig ist es, die Lücke auszunutzen?
Es sind mehrere Lücken, die beide damit zu tun haben, dass die Anwendung am Arbeitsplatz ausgeführt wird und damit im Kontext des Benutzers:
- Das SA-Passwort wird beim Einrichten an eine Stelle geschrieben, die jeder Benutzer lesen kann. Die verwendete Verschlüsselungsmethoden sind leicht protokollierbar, der Schlüssel ist ebenso zugänglich. Das ist für einen ernsthaften Angreifer die einfachste Methode: Die Software bei sich installieren, in aller Ruhe ausspähen und einen Exploit schreiben, der anderen zur Verfügung gestellt werden kann.
- Während des Zugriffs kann jeder Prozess, der im gleichen Benutzerkontext läuft wie das JTL-WAWI, den JTL-WAWI-Prozess ausspähen: er kann den Hauptspeicher durchwühlen, die von der Anwendung verwendeten Schnittstellen sniffen oder sich sogar als Debugger an den Prozess hängen. Wenigstens seit Windows-XP hat jeder Windows-Benutzer das Recht die "eigenen" Prozesse derart zu untersuchen. Viele Entwickler glauben offenbar dazu wären Admin-Rechte nötig. Daher habe ich beschlossen für diese Zielgruppe ein Buch zur Sicherheit von Anwendungen mit SQL-Server zu schreiben. Mal schauen, ob es auf Interesse stößt.
Als Angreifer haben wir also zwei Angriffspunkte, um an das begehrte SA-Kennwort zu bekommen. Wie man das ganz konkret macht, beschreibe ich hier absichtlich nicht. Angehende Skript-Kids möchte ich nicht zu unüberlegten (weil kriminellen) Handlungen verleiten. Aber seien Sie sicher, dass die bösen Jungs wissen wie das funktioniert. Jeder Fachinformatiker im ersten Lehrjahr sollte dazu in der Lage sein. Ebenso reichen die im Informatikunterricht vermittelten Kenntnisse, um sich da einzulesen.
Es ist nur die Frage, ob Angreifer sich die Mühe machen. Das hängt davon ab, was zu holen ist und wie verbreitet die Software ist und wo der Angreifer sitzt?
Wo sitzt der Angreifer?
Falls mein Geschäft eine Oneman-Show ist und die Software nur auf einem Einzelarbeitsplatz läuft, dann dürfte der Angriff am ehesten über das Internet erfolgen, z.B. durch Ausnutzen einer bekannten, noch ungelösten Lücke (z.B. Internet-Explorer oder Flash) oder einfach per Mailanhang z.B. (präpariertes PDF). Der Schädlich könnte schauen, ob er in der Registry das SA-Kennwort findet, anhand des ebenfalls dort stehenden Schlüssels entschlüsselt und ggf. via SQL Server sein schändliches Werk tun.
Falls der SQL-Server im Netzwerk auf einem Server installiert ist, dann dürften mehrere Mitarbeiter vorhanden sein. Für jeden Arbeitsplatz gilt die gleiche Angriffsmöglichkeit wie beim Einzelplatz. Zugleich kommt noch hinzu, dass ein Mitarbeiter anhand einer der vielen Anleitungen einen Sniffer startet (sehr einfach, auch für absolute Laien), das SA-Kennwort erspäht (dito) und dann die Grenzen der Möglichkeiten erprobt (mit Excel zum SQL Server verbinden ist nicht schwer, über SQL Server andere Dateien auslesen erfordert schon mehr Skills). Je nach Motivation des Mitarbeiters kann er sich dann austoben: Die Möglichkeiten reichen vom Stillen der Neugier (steht dort auch, was die Kollegen verdienen) und Kundendaten mitnehmen (um den geplante Start in sie Selbstständigkeit zu erleichtern) bis hin zur Rache (Festplatte formatieren, weil Gehaltserhöhung nicht bekommen, MS fühlt sich ungerecht behandelt, ihm wurde gekündigt, …)
Weil es geht…
In den letzten Jahren kam ein Trend auf, der alle obigen Ausführungen relativiert. Mit den sogenannten Skript-Kids kamen Angriffe hinzu, wo die Angreifer keine wirtschaftlichen Betrachtungen anstellen: Lohnt sich der Aufwand, was ist zu holen, … ? Gerade weil es so einfach ist, werden von meist Jugendlichen Angriffe ausgeführt, einfach nur weil es geht und sie Grenzen austesten wollen. Die Motivation ist hier der Spaß am Knobeln und vielleicht der Prestige-Gewinn im Freundeskreis. Weil es ihnen nicht darum geht damit Geld zu machen, ist es ihnen egal wie lange sie dafür brauchen, sie haben ja nach der Schule meist viel Zeit. Viele der besonders populären Angriffe der letzten Jahre auf Sony etc. waren so motiviert. Die öffentliche Bestrafung einiger der Skript-Kids führte aber in meinen Augen nicht dazu, dass weniger Angriffe durchgeführt werden. Die Kiddies prahlen damit halt nicht mehr so öffentlich.
Und die benötigte Kenntnisse? SQL lernen bayerische Gymnasiasten in der 9ten Klasse…
Update 3.2.2013: Zuschriften entnahm ich, dass einige nicht glauben, dass auch mit normalen Benutzerrechte die beschriebenen Spionageaktionen möglich sind. Daher können interessierte Entwickler anhand dieser Anleitung die benötigten Rechte selber überprüfen.
