Hack Attack aus P***n?

[AlexBausW]

Hallo alle,

Wie jeden Tag bekomme ich morgens als erstes einen aktuellen, skriptgenerierten Auszug aus dem Errorlog per E-Mail auf den Tisch. Heute war ich verwundert, außer den üblichen 404 eine Reihe von fehlgeschlagenen Requests nach "irgendwas" vorzufinden. Und zwar handelt es sich wohl um einen sytematischen Angriff, der ca. 20 Minuten (ab ~9:42 Uhr) dauerte.

Unter http://ahnenforschung.net/logs/error_log-20040210.txt habe ich mal einen leicht geänderten Auszug aus dem gestrigen Error-Logfile des Apachen abgelegt (aaaaa/ ist das Userverzeichnis für die Webadminstrationsoberfläche und /path/to ist das Installationsverzeichnis für den Apachen.

Kann damit irgendwer etwas anfangen? Googlen nach den gesuchten Programmen brachte nicht viel, außer daß Lotus-Notes-Domino-Server wohl ziemlich unsicher sind.

Bis jetzt ist klar, daß jemand von der entsprechenden IP  (gehört Tel-Energo S.A. aus Polen) aus mit einen Programm versuchte, alle möglichen Sicherheistlücken in möglicherweise installierten Programmen sowie dem Apachen und seinen Modulen zu "testen". Sendmail und Popper wurden auch (anscheinend erfolglos) belästigt. Zu guter letzt (eigentlich während des ganzen Angriffs) hat sich der (oder die) Gute mehrfach per FTP  eingeloggt (als anonymous sogar einmal erfolgreich), aber laut xferlog keine Daten heruntergeladen. All dies geschah von perun.daemon.pl [81.15.197.239] aus. Ach ja, den sshd wollte er (oder sie) wohl auch - und zwar anscheinend zuerst - übertölpeln. Zumindest lässt sich das imho aus den Logfiles lesen.

Hat jemand ähnliches schon mal mitgemacht oder davon gehört?
Wenn nicht, schaut mal alle eure Logfiles durch! ;)

Gruß Alex

[Daniela Koller]

Hi Alex

Hat jemand ähnliches schon mal mitgemacht oder davon gehört?
Wenn nicht, schaut mal alle eure Logfiles durch! ;)

Security-Scanner machen so etwas. Sie scannen nach bekannten Lücken bei den Standarddiensten. Afair ist zb. Nessus so ein Teil (danach wird auch gescannt).

Das Log sieht so aus als hätte der Angriff Erfolg haben können und evtl auch gehabt. Da scheint unter anderem auch ein SQL-Inject gelaufen zu sein. Es gibt zwar entsprechende Fehlermeldungen aber die deuten darauf hin, dass du Glück gehabt hast. Du scheinst in einem PHP-Script die Werte von den Query-Parametern nicht sauber mit Escape-Zeichen für gefährliche Eingaben wie ' zu versehen.

Gruss Daniela

[AlexBausW]

Hallo Daniela,

Vielen Dank schon mal für Deine Antwort.

Hat jemand ähnliches schon mal mitgemacht oder davon gehört?
Wenn nicht, schaut mal alle eure Logfiles durch! ;)

Security-Scanner machen so etwas. Sie scannen nach bekannten Lücken bei den Standarddiensten. Afair ist zb. Nessus so ein Teil (danach wird auch gescannt).

Aber welches Tool geht _so_ vor. Anscheinend wurde das Ding ja auch erst kürzlich zusammengestrickt, da glaube ich wirklich alle Bugs, die letztens so durch Bugtraq liefen, getestet wurden. Was mich aber am brennendsten interressiert ist, wer ein solches Tool so gezielt einsetzt. Habe ich mit weiteren Scans der anderen auf dem Server gehosteten Domains zu rechnen? Hat ein solcher Scan nicht sogar strafrechtliche Relevanz? Und kann man in Polen den Täter anhand der Logs Dingfest machen, d.h. lohnt sich eine Strafanzeige überhaupt? Die IP lässt sich ja eindeutig zuordnen, und ein Proxy hängt da wohl auch nicht dran.

Das Log sieht so aus als hätte der Angriff Erfolg haben können und evtl auch gehabt. Da scheint unter anderem auch ein SQL-Inject gelaufen zu sein. Es gibt zwar entsprechende Fehlermeldungen aber die deuten darauf hin, dass du Glück gehabt hast. Du scheinst in einem PHP-Script die Werte von den Query-Parametern nicht sauber mit Escape-Zeichen für gefährliche Eingaben wie ' zu versehen.

Ich habe den SQL-Inject mal rekonstruiert. Es wurde dabei versucht in die Passwortabfrage der Webadministrationsoberfläche für die Kunden einfach ein ' als Username einzugeben. Das führte bei den anschließenden Abfragen des zugehörigen Passwortes aus der MySQL-Datenbank zu einem Fehler, da die PHP-Userauthentikations-Variable ungeprüft verwendet wird. Und tatsächlich konnte ich mit einer entsprechend abgeänderten SQL-Injektion den User "überspringen" und benötigte nur noch das richtige Passwort. Aber ohne Passwort ist glücklicherweise keine Authentikation möglich. Das werde ich aber trotzdem mal patchen, bis ich ein Update einspielen kann. :)

Gruß Alex

[Christian Kruse]

Hallo AlexBausW,

Hat jemand ähnliches schon mal mitgemacht oder davon gehört?
Wenn nicht, schaut mal alle eure Logfiles durch! ;)

Security-Scanner machen so etwas. Sie scannen nach bekannten Lücken bei
den Standarddiensten. Afair ist zb. Nessus so ein Teil (danach wird auch gescannt).

Ja.

Aber welches Tool geht _so_ vor. Anscheinend wurde das Ding ja auch erst
kürzlich zusammengestrickt, da glaube ich wirklich alle Bugs, die letztens
so durch Bugtraq liefen, getestet wurden.

Die werden laufend aktualisiert :)

Was mich aber am brennendsten interressiert ist, wer ein solches Tool so
gezielt einsetzt.

Das wiederum ist ne andere Frage. Die zu beantworten dürfte schwierig werden.

Habe ich mit weiteren Scans der anderen auf dem Server gehosteten Domains
zu rechnen?

Auch die Frage lässt sich nicht beantworten ;)

Hat ein solcher Scan nicht sogar strafrechtliche Relevanz?

Seit dem 1.1.2004 ist AFAIR derartiges per EU-Richtlinie verboten.

Und kann man in Polen den Täter anhand der Logs Dingfest machen, d.h.
lohnt sich eine Strafanzeige überhaupt? Die IP lässt sich ja eindeutig
zuordnen, und ein Proxy hängt da wohl auch nicht dran.

Du kannst es ja versuchen, aber ich bezweifle, dass du da sehr viel Erfolg
haben wirst. Die Daten dürfen nur der Polizei offen gelegt werden, und ob die
über die Landesgrenzen hinweg daran kommt, ist zweifelhaft.

Ich habe den SQL-Inject mal rekonstruiert. Es wurde dabei versucht in
die Passwortabfrage der Webadministrationsoberfläche für die Kunden
einfach ein ' als Username einzugeben.

Ich würde empfehlen, alle User-Parameter durch die Funktionen mysql_escape_string,
pgsql_escape_string, ... laufen zu lassen ;)

Grüße,
 CK

[Daniela Koller]

Hi Christian

Die werden laufend aktualisiert :)

Nichtmal nötig. Einfach für die neuesten Lücken zusätzliche Plugins runterladen reicht. Die sind auch sehr schnell verfügbar.

Gruss Daniela

[aitee]

Ich würde empfehlen, alle User-Parameter durch die Funktionen mysql_escape_string,
pgsql_escape_string, ... laufen zu lassen ;)

Wozu?

[Daniela Koller]

Hi aitee

Ich würde empfehlen, alle User-Parameter durch die Funktionen mysql_escape_string,
pgsql_escape_string, ... laufen zu lassen ;)

Wozu?

Weil sonst SQL-Injection Attacken möglich sind sobald in irgend einem Stringfeld Daten aus einem Formular auftauchen. Du kannst sie natürlich auch selber validieren aber es ist einfacher und verlässlicher, dass den erprobten Funktionen vom Interface zu überlassen. Speziellere Validationen musst du natürlich sowieso noch selber machen.

Gruss Daniela

[aitee]

Hi aitee

Ich würde empfehlen, alle User-Parameter durch die Funktionen mysql_escape_string,
pgsql_escape_string, ... laufen zu lassen ;)

Wozu?

Weil sonst SQL-Injection Attacken möglich sind sobald in irgend einem Stringfeld Daten aus einem Formular auftauchen. Du kannst sie natürlich auch selber validieren aber es ist einfacher und verlässlicher, dass den erprobten Funktionen vom Interface zu überlassen. Speziellere Validationen musst du natürlich sowieso noch selber machen.

Gruss Daniela

... aber das prüft doch nur ob im String ein "%20" oder ein "_" vorhanden ist ... ??

[Daniela Koller]

Hi aitee

... aber das prüft doch nur ob im String ein "%20" oder ein "_" vorhanden ist ... ??

Ehm, nein? Wozu auch, Leerzeichen sind völlig uninteressant. Wichtig sind vorallem ' und " weil man damit weitere Bedingungen anhängen könnte wie zb or 1 = 1. Hätte nette Nebenwirkungen. Evtl wird auch noch % und _ gesondert behandet, weis ich aber jetzt nicht auswändig.

Gruss Daniela

P.S: Lass die Fullquotes sein, die nerven. Begrüssung und Gruss wären auch kein Luxus

[aitee]

P.S: Lass die Fullquotes sein, die nerven. Begrüssung und Gruss wären auch kein Luxus

• Fullquotes? In welchem Kontext?
• Und wenn ich schon mittem im Gespräch mit den Leuten bin, muss ich wohl nicht jedesmal eine Begrüßung hinzufügen, oda? :>

[Sven Rautenberg]

Moin!

• Und wenn ich schon mittem im Gespräch mit den Leuten bin, muss ich wohl nicht jedesmal eine Begrüßung hinzufügen, oda? :>

Schwache Argumentation. Gegen Tippfaulheit hilft </my>.

- Sven Rautenberg

[Christian Kruse]

Hallo aitee,

... aber das prüft doch nur ob im String ein "%20" oder ein "_" vorhanden ist ... ??

Die Escaping-Routinen escapen einen String, so dass er in der entsprechenden Datenbank-Umgebung keine besondere Bedeutung mehr hat. So wird z. B. aus dem SQL-Statement (SQL-Injection!)

"SELECT * FROM blahr WHERE y = "x"; delete * from geheim where "a" = "a";

sobald er durch mysql_escape_string gelaufen ist folgendes:

"SELECT * FROM blahr WHERE y = "x"; delete from geheim where "a" = "a";

Siehst du den wichtigen(!) Unterschied? Die erste Query wurde durch eine
SQL-Injection manipuliert, in der zweiten dagegen konnte die Attacke abgefangen
werden.

Grüße,
 CK

[Thomas Luethi]

Hallo,

Die Moeglichkeit der SQL-Injection ist mir bekannt, und ich
wende deshalb in PHP auch mysql_escape_string() an u.s.w.

Was ich mich aber schon laenger frage:
Inwiefern ist dieses Beispiel heute noch praxisrelevant?

AFAIK wuerde bei einem solchen String:

"SELECT * FROM blahr WHERE y = "x"; delete * from geheim where "a" = "a";

der von PHP an MySQL uebergeben wird, doch (wenn ueberhaupt)
nur das erste Statement, also der SELECT-Teil, von MySQL
ausgefuehrt.
(Konkret: PHP 4.3.x, MySQL 3.23.x)
Oder habe ich da etwas falsch im Kopf?

So richtig gefaehrlich wird es IMHO doch erst,
wenn man Angaben von der Benutzerseite
direkt in DELETE-Statements einbaut.

Benutzer-Eingabe: x, vorgesehen:
DELETE FROM blahr WHERE y="x"
boese Eingabe/SQL-Injection ohne Pruefung fuehrt zu:
DELETE FROM blahr WHERE y="x" OR "1"="1"
Dann ist die ganze Tabelle geloescht...

mfg
Thomas

[Christian Kruse]

Hallo Thomas,

AFAIK wuerde bei einem solchen String:

"SELECT * FROM blahr WHERE y = "x"; delete * from geheim where "a" = "a";

der von PHP an MySQL uebergeben wird, doch (wenn ueberhaupt)
nur das erste Statement, also der SELECT-Teil, von MySQL
ausgefuehrt.

Für MySQL mag das stimmen, aber nicht unbedingt für andere DBMS. Ist mir
übrigens neu, dass das nicht mehr geht.

Benutzer-Eingabe: x, vorgesehen:
DELETE FROM blahr WHERE y="x"
boese Eingabe/SQL-Injection ohne Pruefung fuehrt zu:
DELETE FROM blahr WHERE y="x" OR "1"="1"
Dann ist die ganze Tabelle geloescht...

Ein besseres Beispiel im MySQL-Kontext, ja.

Grüße,
 CK

[Andreas Korthaus]

Hi Thomas!

Was ich mich aber schon laenger frage:
Inwiefern ist dieses Beispiel heute noch praxisrelevant?

Oh - mehr denn je!
Vor allem durch die vielen billigen rootserver Angebote wächst die Zahl der Hobby-Admins, und entsprechend dramatisch sinkt das durchschnittliche Sicherheits-Niveau der Server, das heißt sie werden als Angriffsziele immer interessanter...

Auf einem gut gewarteten und sicher konfigurierten System ist es normalerweise nicht so schlimm wenn ein PHP-Script Sicherheitslücken enthält, weil das normalerweise nicht reichen sollte um wirklich Zugriff auf den Server zu bekommen (Wobei unberechtigter Zugriff und Manipulation von Daten schon mehr als schlimm genug sein kann, nur sind die meisten Angriffe heute nicht so gezielt).
Wenn allerdings Hein Blöd sich nen Root-Server (billiger, geiler, veralteter...) mietet, schön für 19,95 im Monat, darauf findet er dann ein schön altes Suse 8.0 welches im originalen Zustand schon zig böse Sicherheitslücken enthält, ein bisschen mit Confixx rumspielt und dann getreu dem Motte "never change a running system" nichts mehr anfasst um bloß nichts kaputt zu machen, dann natürlich postnuke installiert, am besten noch ne schön alte Version von irgendner Computerbild-CD oder einem veralteten Software-Archiv...

...dann wäre es für das kleine, pickelige, 12-jährige Script-kiddie schon fast unhöflich diese ach so nette Einladung den Server zu übernehmen auszuschlagen...

Aber selbst wenn Dein Server von nem Profi gewartet wird (wovon man im shared hosting auch nicht immer ausgehen kann...), schützt dieser Dich nicht vor Datenverlusten/Manipulationen durch eigene Blödheit.

Gut, bin jetzt ein bisschen vom Thema abgekommen ;-)

SQL-Injection ist eines von vielen Angriffsszenarien, aber Vergleichbares gilt für alle Funktionen die Code in der Shell ausführen(exec() & co.), hierfür gibt es  escapeshellarg() und escapeshellcmd() zum escapen, natürlich sollte man nach Möglichkeit gar keine Parameter direkt übergeben, und wenn nur nach ordentlicher Prüfung/Validierung, und natürlich escaped.
Und genauso gilt dasselbe für Funktionen die PHP-Code ausführen, wie include()...

Die ganzen Leute die glauben include() sei der Ersatz für Frames, ich wette die Hälfte von denen reißen sich damit riesige Sicherheitslücken in Ihren Server. Und wenn der dann schlecht konfiguriert/gewartet ist...

AFAIK wuerde bei einem solchen String:

"SELECT * FROM blahr WHERE y = "x"; delete * from geheim where "a" = "a";

der von PHP an MySQL uebergeben wird, doch (wenn ueberhaupt)
nur das erste Statement, also der SELECT-Teil, von MySQL
ausgefuehrt.
(Konkret: PHP 4.3.x, MySQL 3.23.x)
Oder habe ich da etwas falsch im Kopf?

Das stimmt schon, aber man kann auch durch entsprechende Manipulation bei SELECT an Daten kommen die man eigentlich nicht zu Gesicht bekommen dürfte.

So richtig gefaehrlich wird es IMHO doch erst,
wenn man Angaben von der Benutzerseite
direkt in DELETE-Statements einbaut.

Ja, DELETE, UPDATE, kann alles Schaden anrichten wenn man nicht aufpasst. Aber wie gesagt kann auch SELECT Schaden anrichten, wenn auch nicht in Form von Datenverlust, aber eine sensitive Information in falschen Händen kann auch schlimmer sein als verlorene Daten...

Viele Grüße
Andreas

[Christian Kruse]

Hallo Thomas,

übrigens ist eine grosse MS-URL anfällig gewesen für eine SQL-Injection-Attacke (sie
haben da wohl PHP+MySQL benutzt), so dass es möglich war, beliebigen(!) PHP-Code
auszuführen.

Grüße,
 CK

[Andreas Korthaus]

Hi Christian!

"SELECT * FROM blahr WHERE y = "x"; delete * from geheim where "a" = "a";

sobald er durch mysql_escape_string gelaufen ist folgendes:

"SELECT * FROM blahr WHERE y = "x"; delete from geheim where "a" = "a";

Dann ist sowas wohl grob fahrlässig (funktioniert aber in MySQL), oder?

$sql = "DELETE FROM blahr WHERE id = ".mysql_real_escape_string($id);

denn da könnte ja theoretisch sowas draus werden:

$sql = "DELETE FROM blahr WHERE id = 1 or 1 = 1;"

Das heißt also nicht nur escapen sondern Werte auch unbedingt mit ' einschließen:

$sql = "DELETE FROM blahr WHERE id = '".mysql_real_escape_string($id)."'";

Viele Grüße
Andreas

[aitee]

Das heißt also nicht nur escapen sondern Werte auch unbedingt mit ' einschließen:

$sql = "DELETE FROM blahr WHERE id = '".mysql_real_escape_string($id)."'";

Ich dachte numerische Werte dürfen nicht in '' eingeschlossen werden?

[aitee]

"SELECT * FROM blahr WHERE y = "x"; delete * from geheim where "a" = "a";

sobald er durch mysql_escape_string gelaufen ist folgendes:

"SELECT * FROM blahr WHERE y = "x"; delete from geheim where "a" = "a";

Siehst du den wichtigen(!) Unterschied? Die erste Query wurde durch eine
SQL-Injection manipuliert, in der zweiten dagegen konnte die Attacke abgefangen
werden.

Ich glaube schon ... das Ergebnis wäre dann ein Select ohne Ergebniswerte?

[Andreas Korthaus]

Hi!

... aber das prüft doch nur ob im String ein "%20" oder ein "_" vorhanden ist ... ??

kleine Ergänzung:

<http://de3.php.net/manual/de/function.mysql-real-escape-string.php -> >http://www.mysql.com/doc/de/mysql_real_escape_string.html

Grüße
Andreas

[AlexBausW]

Hallo Christian,

[...]

Was mich aber am brennendsten interressiert ist, wer ein solches Tool so
gezielt einsetzt.

Das wiederum ist ne andere Frage. Die zu beantworten dürfte schwierig werden.

Sind aber meine Informationen, wo der Angriff herkommt einigermaßen verlässlich, oder könnte sich ein Angreifer hinter dieser IP nur versteckt haben?

Habe ich mit weiteren Scans der anderen auf dem Server gehosteten Domains
zu rechnen?

Auch die Frage lässt sich nicht beantworten ;)

Na dann muss ich mal abwarten, und die Kunden eindringlich darauf hinweisen, Ihre eingesetzten Programme zu aktualisieren.

Hat ein solcher Scan nicht sogar strafrechtliche Relevanz?

Seit dem 1.1.2004 ist AFAIR derartiges per EU-Richtlinie verboten.

Das wäre ja dann auch eine Grundlage, sobald Polen in der EU ist. Wann war das nochmal? ;))

Und kann man in Polen den Täter anhand der Logs Dingfest machen, d.h.
lohnt sich eine Strafanzeige überhaupt? Die IP lässt sich ja eindeutig
zuordnen, und ein Proxy hängt da wohl auch nicht dran.

Du kannst es ja versuchen, aber ich bezweifle, dass du da sehr viel Erfolg
haben wirst. Die Daten dürfen nur der Polizei offen gelegt werden, und ob die
über die Landesgrenzen hinweg daran kommt, ist zweifelhaft.

Ich habe dem Geschäftsführer des Hosters empfohlen wenigstens eine Strafanzeige zu stellen, und den "Eigentümer" der IP zu informieren.

Ich habe den SQL-Inject mal rekonstruiert. Es wurde dabei versucht in
die Passwortabfrage der Webadministrationsoberfläche für die Kunden
einfach ein ' als Username einzugeben.

Ich würde empfehlen, alle User-Parameter durch die Funktionen mysql_escape_string,
pgsql_escape_string, ... laufen zu lassen ;)

Leider kann ich das nicht bei allen Kunden überprüfen.
Aber die kritischen Stellen habe ich mal gepatched, so daß unerwünschte Zeichen gelöscht werden.

Gruß Alex

[aitee]

Sind aber meine Informationen, wo der Angriff herkommt einigermaßen verlässlich, oder könnte sich ein Angreifer hinter dieser IP nur versteckt haben?

Wenn das Tool das er einsetzt so funktioniert, dass es eine Server Version auf irgend einen Unix Server hosten kann, und er nur mit einem Client die Daten harvestet, dann siehts schlecht aus für Dich :>

Es sei denn er (oder sie?) ist so dumm und hostet es auf seinem eigenen Server ;)

[Christian Kruse]

Hallo AlexBausW,

Was mich aber am brennendsten interressiert ist, wer ein solches Tool so
gezielt einsetzt.

Das wiederum ist ne andere Frage. Die zu beantworten dürfte schwierig werden.

Sind aber meine Informationen, wo der Angriff herkommt einigermaßen verlässlich,
oder könnte sich ein Angreifer hinter dieser IP nur versteckt haben?

Sie sind in soweit verlässlich, als dass der Angriff (ich nenns einfach mal so)
von da aus gestartet wurde. Aber nicht unbedingt ist der Besitzer des Servers
auch der Angreifer.

Grüße,
 CK

[AlexBausW]

Hallo Christian Kruse,

[...]

Sind aber meine Informationen, wo der Angriff herkommt einigermaßen verlässlich,
oder könnte sich ein Angreifer hinter dieser IP nur versteckt haben?

Sie sind in soweit verlässlich, als dass der Angriff (ich nenns einfach mal so)
von da aus gestartet wurde. Aber nicht unbedingt ist der Besitzer des Servers
auch der Angreifer.

Das Tool gibt doch aber bestimmt seine Daten an seinen Herrn und Meister weiter. Kann man dann aus den Logfiles des Servers lesen, wer die Daten abholt/zugesandt bekommt?

Zumindest ist es doch sicherlich eine gute Idee, den Serveradministrator darüber zu informieren, daß bei ihm ein "Hacker"-Tool läuft.

Gruß Alex

[Christian Kruse]

Hallo Alex,

Hallo Christian Kruse,

Warum so förmlich? ;)

Sie sind in soweit verlässlich, als dass der Angriff (ich nenns einfach mal so)
von da aus gestartet wurde. Aber nicht unbedingt ist der Besitzer des Servers
auch der Angreifer.

Das Tool gibt doch aber bestimmt seine Daten an seinen Herrn und Meister weiter.

Wahrscheinlich, ja.

Kann man dann aus den Logfiles des Servers lesen, wer die Daten abholt/zugesandt
bekommt?

Das hängt davon ab, wie der Administrator den Server konfiguriert hat. Prinzipiell
ist das möglich, ja, aber es ist nicht üblich, Netzwerk-Verkehr mitzuschneiden,
da die Logfiles dann ziemlich gross werden. Allerdings könnte man prüfen, ob der
Angreifer vielleicht SSH benutzt hat. In dem Fall wird in der Standard-Konfig
mitgeloggt, wann er sich von wo verbindet.

Zumindest ist es doch sicherlich eine gute Idee, den Serveradministrator
darüber zu informieren, daß bei ihm ein "Hacker"-Tool läuft.

Ja, auf jeden Fall.

Grüße,
 CK