Seltsame Datenbankeinträge. Wo ist die Sicherheitslücke?

Saugkraft

Aktives Mitglied
Thread Starter
Dabei seit
20.02.2005
Beiträge
8.998
Reaktionspunkte
3.190
Hi Leute,

in letzter Zeit haben wir immer mal wieder eigenartige Datenbankeinträge und offenbar eine Sicherheitslücke. Entweder im Formular oder vielleicht über eine Drive-by Infektion im Browser.

Das Formular selbst ist geschützt im Intranet. Die Identität wird per Sessionvariable überprüft. Eine Infektion von außen halte ich also für unwahrscheinlich. Die Seite wird zwar per Ajax aufgerufen, die URL ist aber öffentlich nicht einsehbar.

Der Code ist nicht nur bei uns zu finden, sondern auf diversen Webseiten.

An den Feldinhalt wird in etwa folgendes angehängt:
Code:
</title><style>.anof{position:absolute;clip:rect(456px,auto,auto,456px);}</style><div class=anof>best <a href=http://katpaydayloans.com >payday loans</a></div>

Die Class und die URL wechseln.

Das Problem ist: Über Google finde ich einen Haufen Websites mit diesem Code aber keine Problemlösung, bzw. -beschreibung, woher die Einträge kommen.

Hat jemand von euch eine Idee?
 
Ich würde glatt mal tippen, das es sich bei deiner Seite um ein Forum oder Gästebuch mit Gastzugang handelt.

Die Intention dürfte sein, dass für den Fall, dass die Eingabe nicht in Safe HTML umgewandelt wird, ein Link auf dieser Seite entsteht. Dieser dürfte sich für den Seitenbetreiber positiv auf sein Google Ranking auswirken (Backlinking).

Im schlimmsten Fall Ist die Seite eine Virenschleuder ...
 
kannst du die identität des formular abschickers nicht auch mit in die DB schreiben, damit du das eingrenzen kannst.
wahrscheinlich irgendein javascript exploit, wo dann bei einem POST das ganze mit dran gehängt wird.
 
Nee, die Seite ist nicht öffentlich. Sofern ich nicht vollkommen blind bin, kann das Problem eigentlich nur von Berechtigten kommen. Zum einen ist die Seite nicht gelistet und so tief in der Verzeichnisstruktur, dass ein Crawlen im Grunde unmöglich ist, zum anderen wird beim Ausführen des Skripts zuerst gepfrüft, ob die Session gültig ist und falls das nicht der Fall ist, sofort umgeleitet.

Die Intention ist klar. Stimmt. Das kann eigentlich nur Backlinking sein. Virenschleuder kann ich ausschließen weil kein Skript ausgeführt wird.

Die Frage ist, wie ich dahinter komme, woher die Einträge kommen. Möglich ist ja z.B. ein infiziertes System beim Client. Jedesmal wenn die Seite im IE oder Firefox aufgerufen wird, wird ein Eintrag erzeugt.
 
kannst du die identität des formular abschickers nicht auch mit in die DB schreiben, damit du das eingrenzen kannst.
wahrscheinlich irgendein javascript exploit, wo dann bei einem POST das ganze mit dran gehängt wird.
Hab ich auch schon überlegt. Dürfte eine gute Lösung sein.

Ein Exploit vermute ich auch. Es soll ja Leute geben, die noch mit uralten Browsern surfen. Ich konnte nur nirgendwo eine Liste mit bekannten Fehlern alter Browser finden, sonst hätte ich da schonmal geschaut. Weiß da jemand von euch was?
 
Nee, die Seite ist nicht öffentlich. Sofern ich nicht vollkommen blind bin, kann das Problem eigentlich nur von Berechtigten kommen. Zum einen ist die Seite nicht gelistet und so tief in der Verzeichnisstruktur, dass ein Crawlen im Grunde unmöglich ist
Ist sie über das Internet erreichbar?
Google crawlt die unglaublichsten Sachen.
 
Grundsätzlich ja. Sie ist aber definitiv nicht indiziert. Selbst wenn ich nach allen möglichen Kriterien suche und dabei echt kreativ bin, wird da nix gefunden. Das Intranet ist wirklich nicht bekannt. Das einzige, was auftaucht, ist die Login-Seite. Die liegt aber auf einem völlig anderen Pfad und leitet per serverseitigem Skript um. Sprich: Die URL ist nicht auffindbar.

Trotzdem kann bei einem infizierten System die URL natürlich irgendwohin übermittelt worden sein. Keine Ahnung.. Vielleicht gibt es ja Viren, Schädlinge, etc., die die aktuell im Browser angezeigte Seite irgendwo hin schicken.

Aber auch damit kommt man eigentlich nicht weiter. Die Seite, die in Frage kommt, schickt die Daten per AJAX an eine andere Seite. In die Richtung ging mein erster Gedanke. Die URL ist natürlich im Seitenkopf hinterlegt. Die Seite mit dem Insert überprüft aber erst die Identität bevor was anderes passiert.

Selbst wenn das fehlschlagen sollte.. Das Update Skript ist an eine Benutzer-id gebunden. Da müsste schon eine Schleife durch laufen, die die ID inkrementiert und per Zufall die richtige erwischt. Ich kann mir kaum vorstellen, dass jemand so viel Aufwand betreibt wo es so viele unsichere Formulare im Web gibt.
 
Grundsätzlich ja. Sie ist aber definitiv nicht indiziert. Selbst wenn ich nach allen möglichen Kriterien suche und dabei echt kreativ bin, wird da nix gefunden.
Das heißt nix - in Google findest Du auch links auf private Webcams oder Druckereinstellungsseiten
 
Du sagst es ja.. Du findest Links. Die Seite finde ich nicht. Nicht über den Dateinamen, nicht über bestimmte Stichworte, die auftauchen müssten. Nix.

Ich drück's mal so aus: Wenn auf der Seite mindestens 3 Mal "hppgoon" auftauchen würde und ich bei Google danach suche und 0 Ergebnisse bekomme.. Wie soll die Seite dann indiziert sein?
 
Muss ja nicht Google sein. Man baut einen eigenen Crawler und immer wenn man eine Form findet, sendet man diese mit dem Script ab.
 
Der würde aber auch nicht zu der Seite gelangen. Die ist von außen nicht zu finden. Die URL ist erst nach dem Login sichtbar. Wenn der Crawler nicht authentifiziert ist, findet er auch keinen Link.

Ein schwaches Passwort kann auch nicht die Ursache sein. Betroffen sind zwei DB-Felder. Und zwar alle Einträge, die einen Text enthalten. Da wird der Text einfach angehängt. Die Datensätze mit leeren Feldern bleiben unangetastet. Bei einem schwachen Passwort kommt der Crawler zwar an den Link, kann aber nur den jeweiligen Datensatz ändern. Nicht alle.

Klingt vielleicht ein bisschen als würde ich alles negieren. Ist aber nicht so. Der Input ist ein prima Brainstorming. So kann ich zumindest überlegen, was es nicht sein kann. :)
 
Ich hab im Google Cache auch schon Inhalte von Seiten gefunden, die eigentlich per .htaccess-Passwort geschützt waren.
 
Auch den Inhalt oder nur die Seite selbst?
 
Schau mal ob irgendwo auf deinen Seiten komischer Code zu finden ist.
Fängt meistens mit <qpi an und endet mit </qpi>

Wenn das der Fall ist, dann wurde deine Seite von aussen gehackt. Innerhalb dieses <qpi Tags findest du dann Javascriptcode der die wahnwitzigsten Dinge tut.

Und wenn dann Lösung:
Erstens alle FTP Zugangsdaten ändern.
Zweitens alle Dateien durchgehen und nach qpi suchen. Alles von <qpi bis /qpi> entfernen.
Drittens Beten

Ausserdem würde ich per IP Location alle Länder sperren, die nicht zu eurem Clientelkreis gehören.
Für Bäckerei Müller aus Darmstadt macht es keinen Sinn wenn jemand aus Taiwan auf die Seite schaut.

Denn solche Hacks kommen nie aus Deutschland selbst. Das sind immer so dritte Welt Länder bei denen der Urheber nicht zurückverfolgt werden kann.
Proxys würde ich generell sperren. Denn wer mit einem Proxy surft hat fast immer was zu verbergen.

Es gibt auch Ausnahmen. Auch in Deutschland sitzen böse progger. Wenn es ein dummer Progger ist, dann hinterlässt er eine korrekte IP Adresse anhand derer du den Hacker identifizieren und rechtlich vorgehen kannst.
Ein schlauer Progger verwendet einen Proxy. Und die ja wie gesagt sperren. :)

Aber totale Sicherheit gibt es nie. Jeden Tag steht ein neuer mit einer besseren Idee und mehr böswilligen Gedanken auf.

So. Das war das Wort zum Sonntag :)
 
Zurück
Oben Unten