Merkwürdige Zugriffe

[sabre]

Ich hatte gerade eben einige interessante Zugriffe auf mein Gästebuch nach folgendem Schema:
http://www.powie.de/cms/mod/gb/kommentar.php?id=-1/**/union/**/select/**/1,2,3,4,5,6,7,8,9,10,11,12,13,14,15/*\" rel=\"external nofollow\">Click
Interessant ist, dass es dabei zu einer Ausgabe kommt. Ich habe gerade nicht den Kopf dazu mir das genauer anzuschauen, aber was haltet ihr davon?

[Powie]

Danke für die Info. Wie bist du darauf gekommen? Über das Apache Logfile!?
Die ID wurde in der kommentar.php nicht gefiltert.

Interessant ist, dass es dabei zu einer Ausgabe kommt. Ich habe gerade nicht den Kopf dazu mir das genauer anzuschauen, aber was haltet ihr davon?[/quote]
SQL Injection. In diesem Falle nicht weiter tragisch, da die betroffene Tabelle eh nur die Postings enthält.

[sabre]

Original von Powie Danke für die Info. Wie bist du darauf gekommen? Über das Apache Logfile!?
[/quote]
Zufall /uploads/emoticons/icon_e_smile.gif.f7ec63a2b1c3d90a9415e40455642502.gif\" alt=\":-)\" /> Ein Bot für Bannereinblendungen hat einen 404-Zugriffsfehler verursacht, weil er wohl die Seite crawlen wollte, auf der vorher ein Banner eingeblendet wurde. Ich logge solche Fehlzugriffe weg und lass sie mir regelmäßig per mail schicken...

SQL Injection. In diesem Falle nicht weiter tragisch, da die betroffene Tabelle eh nur die Postings enthält.[/quote]
Jain, hab grade einen Blick in die logfiles geworfen, und dabei den Versuch entdeckt auf die usertabelle zuzugreifen.

[...]/**/union/**/select/**/1,concat(char(117,115,101,114,110,97,109,101,58),username,char(32,112,119,100,58),pwd),4,5,6,7,8,9,10,11,12,13,14,15/**/from/**/pfuser/* 

 <= hier kommt zwar ein DB-Fehler, aber möglicherweise funktioniert das, wenn man die Spaltenbreite der usertabelle weiß oder wie auch immer. Ich kann hier während der Arbeitszeit nicht mit dem nötigen Synthax auseinandersetzen und so lange rumprobieren bis es möglicherweise funktioniert /uploads/emoticons/icon_e_smile.gif.f7ec63a2b1c3d90a9415e40455642502.gif\" alt=\":-)\" />
Glücklicherweise habe ich einen Tabellenprefix eingestellt, der nicht offensichtlich ist /uploads/emoticons/icon_e_wink.gif.3167d127940f44558fbf1ccd9b6d60a9.gif\" alt=\";-)\" />

[Powie]

habs mal probiert, das liefert aber auch wenn man das Prefix kennen würde nichts zurück.
Interessant wäre zu wissen auf welches Script die Anfrage ging, anmelden ist damit nicht ,möglich...!

[sabre]

Ich konnts gerade verifizieren, dass mit der Lücke der Hash des admin-users ausgespäht werden könnte.
Ich hab den fix mal ganz fix eingebaut /uploads/emoticons/icon_e_wink.gif.3167d127940f44558fbf1ccd9b6d60a9.gif\" alt=\";-)\" />

[Powie]

Mein error_log ist voll davon. Hier wird versucht zum Beispiel auf die /cms/news/activate.php...... zu posten, das File gibts aber garnicht. Auf einer anderen Maschine find ich das auch im Access_loog, hier wird ein Joomla CMS angegriffen, sowie ein wordpress blog. Scheint also Methode dahinter zu sein so nach Lücken zu spähen.

[sabre]

Ja, bei mir ist auch alles voll von solchen Zugriffen, das ist normal. Es ging hier aber explizit um ein pScript ging (bzw. pSys) und auchh erfolgreich gewesen wäre, wenn ich keinen Tabellenprefix eingestellt hätte. Das pSys bzw. die nicht mehr gepflegten pScripte scheinen sich langsam zu einem interessanten Angriffsziel zu entwickeln /uploads/emoticons/icon_e_smile.gif.f7ec63a2b1c3d90a9415e40455642502.gif\" alt=\":-)\" />
btw: das obige Beispiel mit username und pwd ist so angepasst, dass es nicht funktionieren kann. Ich wollte nur die Richtung zeigen und keine Anleitung schreiben /uploads/emoticons/icon_e_wink.gif.3167d127940f44558fbf1ccd9b6d60a9.gif\" alt=\";-)\" />

Jain, hab grade einen Blick in die logfiles geworfen, und dabei den Versuch entdeckt auf die usertabelle zuzugreifen.[/quote]
Ok, das ist natürlich auch was anderes, als Du in deinem ersten Post geschrieben hast. Du solltest dein Passwort ändern.

<= hier kommt zwar ein DB-Fehler, aber möglicherweise funktioniert das, wenn man die Spaltenbreite der usertabelle weiß oder wie auch immer.[/quote]
Exakt. Ein UNION SELECT muss immer genau so viele Spalten zurückliefern, wie eigentlich Spalten selektiert wurden.

Glücklicherweise habe ich einen Tabellenprefix eingestellt, der nicht offensichtlich ist[/quote]
Das stimmt zumindest so lange, wie keines der Skripte SQL-Fehlermeldungen einfach durchreicht. Sicher sein kannst Du diesbezüglich nicht.

Scheint also Methode dahinter zu sein so nach Lücken zu spähen.[/quote]
Ja. Rechenzeit ist so günstig, dass es effizienter ist, direkt den Exploit zu testen, als lange mit der Suche nach betroffenen Applikationen zuzubringen. Typisch sind auch NIMDAs oder Code Red (II), die Apache angreifen - obwohl beide nur mit dem IIS funktionieren.