Strona 1 z 1

Zabezpieczenie serwera przed śmieciami typu C99Shell

: 27 kwietnia 2011, 20:55
autor: ubunciak
Mamy taki problem, że poprzez dziurawe oprogramowanie klientów (prym wiedzie OsCommerce) jacyś kretyni wrzucają śmieci typu C99shell.
  • W php.ini poblokowaliśmy disabled_functions,
  • php chodzi na suexec suPHP,
  • open_basedir oczywiście zawężony tylko do katalogu użytkownika
Co mimo wszystko znowu pozwoliło komuś na odczytanie /etc/httpd/conf/httpd.conf i dopisanie jakiegoś śmiecia. Prawdę mówiąc nie mam pojęcia jak - bawiłem się tym C99 i za ,,cukierka'' nie dało się odczytać zawartości katalogu jak i samej konfiguracji.

Macie sugestie co jeszcze zrobić aby przyblokować te śmieci?
  • mod_security - strasznie obciąża serwer, a poza tym to też półśrodek
  • pewnie trzeba by coś też z /tmp zrobić
  • Ale jak ktoś mógł jeszcze odczytać ten konfig?

: 28 kwietnia 2011, 07:49
autor: ionicDC
Jeśli masz uruchamiane php z prawami użytkownika i open_basedir to nie jest możliwe by z poziomu wirtualki ktoś się dostał do /etc/ - albo dziura jest w innym miejscu albo jest jakaś niewycięta funkcja.
/tmp zrób w trybie no_exec. Czy Twoi użytkownicy mają dostęp do powłoki?

: 28 kwietnia 2011, 09:51
autor: ubunciak
/tmp - jest noexec, nawet nie zauważyłem.
Nie ma powłoki dla ludzi.
Wycięte funkcje: exec, system, passthru, shell_exec, ini_alter, popen, show_source, proc_nice, proc_terminate, proc_get_status, proc_close, pfsockopen, leak, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, dl, symlink, escapeshellarg, escapeshellcmd, proc_close, proc_open.
Facet wrzucił jakiś syf poprzez oscommerce (google79868768767.php), następnie zaczął grzebać w powłoce ale co nie wiem, przesyłane to było przez POST, więc w logach jest tylko wywołanie skryptu.

Facet wrzucił jakiś syf poprzez oscommerce (google79868768767.php), następnie zaczął grzebać w powłoce ale co nie wiem, przesyłane to było przez POST, więc w logach jest tylko wywołanie skryptu.
W
/tmp/ znalazłem zrobiony przez tego użytkownika katalog, a w nim kopię httpd.conf no i w /etc/ dopisał co chciał.

Admin też twierdzi, że wszystko gra, no ale jak gra skoro nie gra.

: 02 maja 2011, 13:18
autor: shyte

Kod: Zaznacz cały

load_file, show_source, passthru, popen, proc_open, disk_free_space, diskfreespace, leak, tmpfile, escapeshellcmd, php_uname, putenv, getmyuid, leak, listen, diskfreespace, tmpfile, link, ignore_user_abord, dl, highlight_file, source,fpaththru, virtual, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam,posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix_getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit,posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid,posix_setuid, posix_times, posix_ttyname, posix_uname, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate,openssl_csr_export_to_file, openssl_csr_export, openssl_csr_new, openssl_csr_sign, openssl_error_string, openssl_free_key,openssl_get_privatekey, openssl_get_publickey, openssl_open, openssl_pkcs7_decrypt, openssl_pkcs7_encrypt, openssl_pkcs7_sign,openssl_pkcs7_verify, openssl_pkey_export_to_file, openssl_pkey_export, openssl_pkey_free, openssl_pkey_get_private,openssl_pkey_get_public, openssl_pkey_new, openssl_private_decrypt, openssl_private_encrypt, openssl_public_decrypt,openssl_public_encrypt, openssl_seal, openssl_sign, openssl_verify, openssl_x509_check_private_key, openssl_x509_checkpurpose,openssl_x509_export_to_file, openssl_x509_export, openssl_x509_free, openssl_x509_parse, openssl_x509_read, curl_version, ftp_fput,disk_total_space, getrusage, fileowner, filegroup, system, exec, shell_exec, shell, symlink, readdir, opendir, dir, disktotalspace
To powinno załatwić sprawę.
U mnie tak mam i za pomocą takich badziewi jak c99, nie można odczytać żadnych plików ani katalogów.

: 04 czerwca 2011, 15:32
autor: ubunciak
Niestety nie załatwiło, coś permanentnie dopisuje do php.ini linijkę z wczytywaniem jakiegoś śmiecia, który umieszcza w jednym z katalogów. Szczerze mówiąc kończą mi się pomysły gdzie jest ta dziura, coraz mniej pomysłów.

Co dziwniejsze php.ini ma prawa root/root a data modyfikacji jest sprzed kilku dni co jest ewidentną nieprawdą. Nie wiem jak można edytować plik żeby jego data się nie zmieniła? Nie wiem gdzie jeszcze wyśledzić co za syf mi to robi.

: 04 czerwca 2011, 16:12
autor: grzesiek
Zobacz co jest uruchomione

Kod: Zaznacz cały

pstree -pca

: 04 czerwca 2011, 16:23
autor: ubunciak
Nie ma nic podejrzanego. To musi być szybka akcja przez www/php choć nie wiem jak zważając na te suphp i blokowanie wszystkiego.

: 05 czerwca 2011, 13:58
autor: Bastian
Jestes pewnien, że w ogóle wykorzystuje php do ataków? Może to exploity jakiejś innej usługi?

: 05 czerwca 2011, 14:57
autor: ubunciak
Nie jestem pewien. Tak mi się tylko wydaje. Wcześniej na bank było przez www/php (dziura w oscommerce) oraz znalazłem tego C99. Potem zablokowałem wszystko j.w. ale problem nie zniknął. Gdybym jakimś oprogramowaniem mógł dociec kto i jak dopisuje śmieci do php.ini to by było łatwiej. A tak to ciężko znaleźć cokolwiek w logach.

: 06 czerwca 2011, 11:00
autor: Bastian
Trzeba by zacząć od tego co raportuje rkhunter albo chkrootkit, a następnie:

Kod: Zaznacz cały

netstat -lap
zeby przekonać się co tak naprawdę udostępnia Twój serwer. Do tego

Kod: Zaznacz cały

iptables -L
a potem jeszcze nmapem sprawdzić co się da wyciągnąć z Twojego serwera. Wersje oprogramowania na serwerze są uaktualniane?