Dipl.-Inform. Carsten Eilers

Im Juni liefen laut Sucuri Security mindestens zwei groß angelegte SQL-Injection-Angriffe auf ASP.NET-Websites, die Code für Drive-by-Infektionen einschleusen. Das ist nichts Neues, das gab es auch schon 2008. Da fragt man sich doch, wo die Entwickler die letzten Jahre verschlafen haben und warum es immer noch so viele angreifbare Anwendungen gibt. Ist ASP etwa unsicherer als PHP, dem das doch eigentlich nachgesagt wird? Oder interessiert sich außer den Cyberkriminellen niemand für ASP-Webanwendungen, alle anderen stürzen sich auf PHP-Anwendungen? Wenn ich mir die Exploits in der Exploit Database ansehe, entsteht jedenfalls dieser Eindruck: Jede Menge Exploits für PHP-Anwendungen, deutlich weniger für ASP, und darunter dann noch viele zu Datenbankdateien im Webroot-Verzeichnis. Sind ASP-Anwendungen womöglich unsicher, weil sich die Entwickler entweder in falscher Sicherheit wiegen oder einfach nicht wissen, dass es überhaupt so etwas wie SQL-Injection gibt?

Massenangriffe nach altem Muster

Die Angriffe erfolgen nach dem seit 2008, bekannten Muster: Alle Textfelder der Datenbank werden mit dem Schadcode gefüllt, irgend eines davon wird dann (so hoffen die Angreifer) schon unverändert ausgegeben. Die SQL-Injection-Angriffe richten sich nicht gegen bestimmte Anwendungen oder Erweiterungen sondern sind allgemein gegen alle ASP-Anwendungen gerichtet, die den Cyberkriminellen vor die virtuelle Flinte geraten. Zu den Opfern gehören laut Sophos die Websites der Jerusalem Post und von A.S. Roma, was die Römer aber nicht wahrhaben wollen. ScanSafe berichtet, dass die Website des Wall Street Journal (WSJ.com) indirekt Opfer der Angriffe wurde: Eine Partner-Website, von der Inhalte eingebunden wurden, wurde kompromittiert und die infizierten Seiten vom Wall Street Journal eingebunden.

Altes Muster, aber neue Exploits

Die Angriffe folgen zwar dem altbekannten Muster, setzen aber laut Armorize auf einen neuen Exploit für die Drive-by-Infektionen: Ausgenutzt wird die Anfang Juni von Adobe gemeldete 0-Day-Schwachstelle im Flash Player, Adobe Reader und Acrobat. Die wurde zwar inzwischen im Flash Player behoben, Patches für Adobe Reader und Acrobat wurden aber erst für den 29. Juni angekündigt.

Die Websense Security Labs haben den Angriff ebenfalls analysiert und ein Video des Angriffs erstellt.

Gefahr nicht gebannt

Zwar konnte zumindest eine der Domains, von denen der Schadcode geladen wurde, durch die Shadowserver Foundation lahm gelegt werden, trotzdem besteht weiterhin Gefahr. Zum einen durch von anderen Domains nachgeladenem Schadcode, zum anderen durch die weiterhin vorhandenen SQL-Injection-Schwachstellen. Die Cyberkriminellen können die Anwendungen immer wieder mit neuem Schadcode infizieren, solange die ausgenutzten Schwachstellen nicht behoben werden.

Einmal aufräumen, bitte!

Falls Sie eine ASP-Webanwendung betreiben oder entwickelt haben: Prüfen Sie möglichst bald, ob damit noch alles in Ordnung ist. Wurde der Server mit Schadcode infiziert, löschen Sie den sofort und beheben Sie vor allem die dann vorhandene SQL-Injection-Schwachstelle(n). Sonst ist der Server sehr schnell erneut mit dem Schadcode infiziert.

Wenn Ihre Anwendung noch nicht betroffen ist, prüfen Sie, ob es SQL-Injection-Schwachstellen gibt. Die aktuellen Angriffe erfolgen wie mit einer virtuellen Schrotflinte: Der SQL-Injection-Code wird in alle in Frage kommenden Parameter eingeschleust und versucht dann seinerseits, alle in Frage kommenden Felder der Datenbank mit dem Schadcode zu füllen. Es wird Web-seitig keine einzige spezifische Schwachstelle ausgenutzt, weder im IIS noch in der SQL-Datenbank noch in irgend einer bestimmten Webanwendung. Daher kann jede ASP-Anwendung zum Opfer werden, sofern sie eine SQL-Injection-Schwachstelle enthält.

SSH: Mit Brute-Force auf ein neues Ziel

Außer ASP-Anwendungen gibt es zur Zeit noch andere Ziele massenhafter Angriffe: Das Internet Storm Center warnt vor Brute-Force-Angriffen auf SSH-Zugänge, die anscheinend von Botnets ausgehen. Ein einziger SSH-Benutzer mit schwachem Passwort reicht aus, um den Server zu kompromittieren. Außer der üblichen Passwort-Authentifizierung wird diesmal auch die Keyboard-Interactive-Authentication angegriffen. Was die Angreifer vorhaben, ist nicht bekannt, mit Sicherheit werden kompromittierte Server aber im Rahmen weiterer krimineller Machenschaften, vielleicht als Ausgangspunkt weiterer Angriffe oder für Drive-by-Infektionen, missbraucht werden.

Mögliche Gegenmaßnahmen wurden im Handler's Diary des ISC bereits in der Vergangenheit aufgeführt, darunter die Nutzung eines anderen Ports als des Standard-Ports 22, der Einsatz eines Tools zur Abwehr von Brute-Force-Angriffen und das Deaktivieren von root-Logins. Bei den aktuellen Angriffen muss außerdem darauf geachtet werden, dass die Server korrekt konfiguriert sind und nicht etwa unabsichtlich ein Zugang mittels Keyboard-Interactive Authentifizierung möglich ist.

Security by Obscurity?

Der Vorschlag des ISC, für SSH einen anderen Port als den Standard-Port zu verwenden, klingt eigentlich nach der allgemein verachteten 'Security by Obscurity'. Die Verwendung eines anderen Ports schützt natürlich überhaupt nicht vor einem Angriff, wenn die Angreifer den Port erst mal gefunden haben, aber dafür müssen sie ihn erst mal suchen. Bei einem gezielten Angriff würde der Port natürlich schnell gefunden, bei den aktuellen Brute-Force-Angriffen durch ein Botnet wird der Server durch den geänderten Port aber erst mal aus der Schusslinie genommen. Solange die Cyberkriminellen genug über Port 22 angreifbare Server finden, suchen sie nicht nach anderen Zielen.

Das ist natürlich kein Grund, auf weitergehende Schutzmaßnahmen zu verzichten. Solange die aber nicht vergessen werden, spricht nichts dagegen, sich vor den Angreifern zusätzlich zu verbergen. Ganz im Gegenteil gibt es mindestens ein gutes Argument dafür: Die Brute-Force-Angriffe führen zu einer unnötigen Belastung des Servers, die u.U. auch zu einem DoS führen können, dem man durch den Wechsel des Ports entgeht.

Carsten Eilers