Meldung vom 24.04.2008 - Heise-Security

Hunderttausende Webseiten (IIS mit anhängendem MS-SqlServer) seien mit schädlichem JavaScript infiziert. Einschließlich Servern von Regierungseinrichtungen und UNO.

Prinzip: Einschleusen von Code der Form

man sieht: Eine Hexadezimalcodierung eines Strings, der anschließend ausgeführt wird. Dieser sucht alle Textfelder, hängt an diese JavaScript an, das lädt JavaScript-Code von einem chinesischen Server. Der JavaScript-Code versucht, Trojaner bei ungepatchten Clients einzubauen.

Weiterer Link vom 24.04: http://www.f-secure.com/weblog/archives/00001427.html
Ähnlich 22.04: http://securitylabs.websense.com/content/Alerts/3070.aspx

Alleine eine Suche nach nihaorr1 listet über 300.000 Fundstellen mit Servern, die gehackt worden sind.

Seinerzeit Vermutung: Über alte, nicht gepatchte Bugs in der Microsoft-Software würde das gehen.

Etwas später setzt sich Microsoft damit auseinander: Heise-Security,
Blogeintrag
IIS.NET - Blog

Tatsächlich war es wohl kein Ausnützen eines Bugs, sondern schlicht und einfach ein relativ automatisiertes Testen auf Sql-Injektionen.

Das kann natürlich auch auf jedem anderen System wiederholt werden, hier wird das allgemein interessant.

Sprich: Es scheint inzwischen Tools zu geben, die automatisiert auf Sql-Injektionen testen und damit Server der Reihe nach durchtesten. Und man sieht auch: Es interessiert gar nicht, den Server platt zu machen. Sondern interessant ist, daß der Server nun JavaScript ausliefert, das einen Hack beim Client ermöglicht. Was auf dem Server ist, ist völlig uninteressant. Auf den Clients kann man dann bsp. die Kommunikation zur Online-Bank per Keylogger mitschneiden. Und angesichts heutiger Laiennutzer muß womöglich nicht einmal ein Bug ausgenutzt werden: Es genügt womöglich ein Download-Angebot für ein Musikstück, das in Wirklichkeit eine Exe-Datei ist.

Im aktuellen c't hats einen mehrseiten Bericht über aktuelle Bedrohungen und Cyberangriffe. Interessant und gleichzeitig irgendwie auch schockierend zu lesen...

Man hat fast schon das Gefühl, dass wenn man heutzutage nicht stündlich Betriebssystem, Browser, Acrobat-Reader, Flash, etc. aktualisiert man ein Emmenthaler System hat. Und auch wenn man ständig aktualisiert, es trotzdem noch irgendwelche Lücken gibt, die über XSS oder sonstwelche Attacken ausgenutzt werden können.

Eine sehr interessante Schlussbemerkung! Das zeigt sich, dass immer noch viele (Web-)Programmierer Benutzereingaben ungenügend verifizieren, obwohl man mit wenig Aufwand solche Sicherheitslücken schliessen könnte.

[So, nochmals ein klein wenig Zeit gehabt und in der Doku nachgeguckt]

Auf eines sollte ich da noch hinweisen, auch wenn hier zunächst wohl viele sagen werden: 'Das betraf ja bloß den MS-SqlServer, ich nutze mySql'.

Code der Form

ist in der Version 5 auch bei mySql möglich.

mySql kennt nun auch die Möglichkeit, mit Cast binär codierte Zeichenfolgen als Strings zu decodieren. Das Ergebnis ist, daß die injizierte Zeichenfolge kein einziges ' mehr enthält.

Gibt es also irgendeine Stelle im Code, bei dem ein Ausdruck der Form

genutzt wird und wird $id (intendiert als Zahl) roh übergeben, ohne daß das überprüft wird, dann kann eine Zeichenfolge der obigen Struktur eingeschleust und ausgeführt werden.

Existieren solche Tools, die automatisiert MS-Sqlserver abfragen, jetzt schon, dann ist es nur eine Frage der Zeit, bis es auch automatisierte Tools für mySql geben wird.

So, der Mist geht weiter: Heise-Meldung von heute nachmittag.

Es sind nun auch reihenweise deutsche Seiten betroffen, so daß Nutzer beim Surfen draufstoßen könnten.

Kritisch ist wohl ein CMS des Herstellers Interlogics (Quelle: Heise). Eingeschleust werden Links zu banner82.com, adw95.com oder anderen Seiten. Wenn man bei google sucht, gibt es bereits massig infizierte Domains.

Grade habe ich mal folgenden Code gebastelt:

Der Code durchsucht alle Textspalten, ob in diesen die Zeichenfolgen 'banner82', 'adw95' oder 'script' drin sind. Normalerweise sollte diese Suche über eine ganze Datenbank nichts liefern. Liefert sie Ergebnisse, so muß man en detail durchgucken, ob Inhalte eingeschleust worden sind (das Wort 'script' kann ja auch absichtlich drinstehen).


Prinzip: Diesen Code in einer Datenbank ausführen. Der Code sucht sich alle Textspalten, baut dynamisch einen Sql-Code zusammen, der all diese Spalten durchsucht und gibt das Ergebnis hinten aus:

Datenbank - Schema - Tabelle - Spalte - Inhalt

Voraussetzung: SqlServer 2005. SqlServer-2000 - Nutzer müssen statt 'nvarchar(Max)' den 'nvarchar(4000)' oder - falls die Spalten keine Sonderzeichen enthalten - 'varchar(8000)' zur Deklaration von @cmd nutzen.

Alternativ könnte man auch nach dem Wort 'script' suchen. Nach dem, was bis jetzt bekannt ist, müßten die JavaScript-Schlüsselwörter unmaskiert in der Datenbank drinstehen.

Edit: Ach du grüne Neune: Grade nach deutschen Seiten gesucht:

banner82 site:.de

adw95 site:.de

guenstiger.de scheint es erwischt zu haben.

Edit 18:25: Code geändert, so daß auch text/ntext durchsucht wird. Da klappt kein Lower, in diesem Fall muß man die Sortierung auf Groß/Kleinschreibung ignorieren setzen.

Ich wünschte ich würde irgendetwas davon verstehen

Leider werde ich als "Leihe" nicht so ganz über die Tragweite der "injektionen" schlau ...
Hat da jemand eine Vermutung was hier die Ziele sein sollen, die erreicht werden sollen.

Wohl fraglich das es bei einer reinen injektion bleiben soll ... was haben die vor ?!

Lg Faxnix

Früher war die Idee "Verschaffe Dir Zugriff und feiere dich". D.h. die Pseudonyme und Logos wurden auf den übernommenen Webseiten ersetzt. Dabei ist Sql Injection nur ein Weg von vielen um sich mit einer Sicherheitslücke Zugriff zu verschaffen.

Die Idee hierbei ist, dass sich der Angreifer Zugriff auf den Content einer Webseite verschafft (in diesem Fall mittels SQL Injection). Weiter sollst Du als Webseitenbetreiber dies nicht merken. Hauptziel ist es Links in Deine Seite einzuschleusen. D.h. die Angreifer möchten sich durch betrogene Empfehlungen (Links auf der gehackten Webseite) in den Google SERPs nach oben schummeln um mehr Traffic auf die eigenen Webseiten zu ziehen um diesen zu monetarisieren.

Alternativ kann auch direkt Traffic gezogen werden bzw. die Webseite für weiteres Seeding benutzt werden (die Besucher dieser Webseite können mit Viren und Trojanern beworfen werden).

Das spannenste was ich je gesehen habe, war ein ausgewachsener Webtrojaner, der sich in WP SW eingenistet hat und remote steuerbar wie auch updatebar und versteckbar war.

Die obigen Angriffe sind von einer neuartigen Qualität.

Es geht bei ihnen darum, massenhaft JavaScript-Code per iFrame einzuschleusen. Die gehackten Server sollen allerdings wie gewohnt weiterlaufen, damit sie ganz normal Besucher kriegen.

Jemand, der mit einem nicht vollständig gepatchten Rechner nun eine solche (mit einem iFrame verzierte) Domain aufruft, kriegt damit womöglich einen Trojaner oder Keylogger untergeschoben. Die gehackten Server sind also nur Mittel zum Zweck, um an möglichst viele Clients und die dortigen Daten direkt ranzukommen.

Im Prinzip müßte man sich einmal das JavaScript runterladen.

Grade will ich das mit meinem Download.exe machen. Beide Server (banner82 / adw95) sind nicht mehr auflösbar. Entweder sind die Urls von den Providern blockiert oder die (bsp. deutschen) Provider blocken den Zugriff auf diese Domains ab.

Das löst zwar das Problem für den Augenblick. Aber solange auf den Servern so eine hackbare Software läuft, solange sind diese Server beliebig angreifbar und lassen sich damit für eigene Zwecke verwenden.

Da hier externer JS-Code eingebunden ist, ist das im Prinzip auch schon updatebar.

Ohne angreifbare Datenbanken und Skripte werden wir in unserer internetten Welt wohl nicht mehr auskommen. Nach eigenen Erfahrungen mit PHP-Skripten, mit deren Hilfe Malware auf meinem Webspace installiert wurde, kam ich dazu, ein bestimmtes Projekt täglich zu prüfen, bis ich es lösche, weil ich derzeit an einer anderen Lösung arbeite.

Trotzdem denke ich, daß aus Bequemlichkeit und Faulheit ohne Not zu viele unsichere CMS eingesetzt werden. Es ist ein Irrglaube, wir müßten jetzt dieses gefährliche Zeug benutzen, weil statische HTML-Seiten Unsinn seien. Ich habe lange Monate gebraucht, bis ich diese Propaganda anzweifelte.

Letzte Woche fand ich einen Weg, mit HTML, CSS und PHP5 Internetpräsenzen aufzubauen, die prinzipiell in der Anzahl der Unterseiten genausowenig begrenzt sind wie ein traditionelles WCMS.

Natürlich frage ich mich als Laie, ob PHP-Seiten, die keine Parameter übergeben, überhaupt hackbar sind. Das werden die Fachleute wissen. Jedenfalls freue ich mich über meine Lösung, die keine Skriptsammlung von 50 kBytes, 500 kBytes oder 5 Mbytes braucht, um zu funktionieren.

Ich stelle diesen etwas anderen Ansatz in englischer Sprache auf meiner Internetseite openWCMS.org vor. Mein Motto dabei ist: "ASAP As simple as possible!"

Entschuldige, Hans, aber wenn du PHP einsetzt, zumindest so wie in einem Text beschrieben, dann sind das keine statischen HTML-Seiten mehr.
Kann es sein das du da etwas mit der Terminologie durcheinander bringst?

Das nennt sich KISS: keep it simple stupid! Wenn ich ASAP höre, dann mach ich schnell

Die Idee eines solches CMS ist, dass man sich mit einer dynamischen Sprache, eg. PHP statische Seiten generiert, die nur noch abgerufen und nur bei Update des Inhaltes neu generiert werden. Ich hab das schon mit einzelnen Topics hier gemacht, als xk Besucher in der Minute auf ein Thema kamen. Allerdings hab ich den Link von Hans nicht angeschaut.

Ich wollte auf etwas anderes hinaus. Der über eine Lücke eingeschleuste Code war darauf ausgelegt ein "Trojaner Framework" zu stellen, welches einmal infiziert von dem Puppetmaster bei ändernden Ramenbedingungen angepasst werden konnte. Zudem ging es nicht darum Clients zu infizieren, sondern schlicht darum Links zu platzieren.

Ich konnte banner82 schon bei Deinem Beitrag am 30ten nicht mehr auflösen. adw95 hab ich gar nicht erst probiert.

Ah, netter Gedanke.
Aber wirklich ur für selten aktualisierte Seiten, hm?

Irgendwo habe ich letztens gelesen das der erste Layer der Puppetmaster im Schnitt nurnoch wenige Stunden online ist.

Wie kann man denn verhindern, dass so ein Code Schaden anrichtet? Reicht da die Funktion mysql_real_escape_string() in PHP?

Ich hoffe jetzt mal ganz *bösartig*, dass von diesen Angriffen nur die Windoof-Clients betroffen sind und ich mich mit meinem Mac sicher fühlen darf.

Die Mehrheit der Besucher auf meinen Webseiten kommen allerdings mit einem anfälligen Betriebssystem daher, und es liegt nicht in meinem Interesse diese zu infizieren. Wie aber kann ich konkret dagegen vorgehen? Wenn ich Daten vom Formular in die Datenbank schreibe, dann so wie es im Handbuch steht.

Das Feld wird 1:1 in die Spalte geschrieben. In wie weit schützt mich der folgende Code?

In diesem Zusammenhang möchte ich auch Mail-Formulare ansprechen. Wie verhindere ich, dass diese als Spam-Schleuder missbraucht werden können?

Gruss René

Du kannst doch einfach die PHP Funktion mysql_real_escape_string verwenden

Wenn du das nicht machst, ist das übrigens nicht nur ein Problem für die Windows-Clients... So kann man nämlich alle möglichen Befehle in der Datenbank absetzen...

Balsam auf meine Seele :-)

Es wird in Zukunft noch viel grössere und gravierende Angriffe geben.

Andere Frage: Warum hat jeder User das GEfühl, er müsste mit Admin Rechten unterwegs sein?

Warum hat jeder Webmaster/Firma das Gefühl er müsste einen eigenen Webserverver haben?

Warum darf sich jeder, welcher einen Code editor hat Programmierer nennen?

Was wir heute in der IT haben lässt sich wie folgt abbilden:
5 Jähriger hat im Kindergarten ein Auto gebaut. Sein 3jähriger sohn hat es zu schrott gefahren.

Ich möchte auf einen älteren Beitrag dazu verweisen: http://www.ayom.com/topic-21056.html?hl=

Da gibt es ein Beispiel von mir, dass auch mysql-real-escape-string nicht ein Sorglos-Paktet ist.