Dzisiaj taka mało przyjemna sprawa :/ Jakiś czas temu pewna osoba dostała maila, którego można by streścić słowami: “wasza aplikacja jest dziurawa, mam hasła do bazy, proponuje 150zł i wykonam odpowiednie poprawki bezpieczeństwa”. Śliska sprawa tym bardziej, że napisała to osoba udzielająca się na polskim forum Kohany, notabene także czytelnik tego bloga Nie chce tego komentować, za to proponuje lekturę wpisu Vagli. Skupmy się na samym problemie.

Problem dotyczy frameworka KohanaPHP od wersji (chyba 2.2) w której dodano internal cache w konfiguracji. Internal cache to solidny kop wydajnościowy uzyskiwany poprzez zbuforowanie na ustalony okres czasu całej konfiguracji frameworka oraz wszystkich ścieżek dostępu. Zserializowane tablice są zapisywane w formie tekstowej w katalogu /application/cache/. Nie jestem teraz w stanie stwierdzić czy złą konstrukcję .htaccess posiadała oficjalna paczka z tego czasu czy to jest kwestia indywidualnych zmian. Ważne jest abyście sprawdzili swoje poprzednie produkcje i mieli to na uwadze zestawiając nowe (jednocześnie zmieniając .htaccess standardowo dostarczany z frameworkiem). W każdym razie zestawienie inne niż kierowanie wszystkiego (z pominięciem np. css/img/js itp.) na index.php może spowodować to, że ów katalog z cache będzie swobodnie dostępny z poziomu przeglądarki, a tym samym dostęp do loginu/hasła do bazy danych stoi otworem

ps. to też jeden z powodów dla którego zawsze sugeruję przenoszenie katalogów z aplikacją i frameworkiem POZA katalog główny (tzw. webroot) dostępny na zewnątrz. W Kohanie jest to bardzo proste do uzyskania: edytujemy plik index.php zmieniając $kohana_application, $kohana_modules i $kohana_system na odpowiednie ścieżki (np. "../enginemojejstrony/application").

Ostatnio dużo się pisze na temat sql injection zapominając o innych groźnych atakach. Całkiem niedawno ktoś przez mój serwer, a konkretnie przez jeden z skryptów php typu ‘kontakt’ wysłał masę spamu na AOL przez co AOLowcy się na mnie obrazili

Pierwsze co zrobiłem to odpowiedni wpis w mod_security. Na sieci znalazłem wiele wersji np:

SecFilterSelective ARGS_VALUES “\n[[:space:]]*(to|bcc|cc)[[:space:]]*:.*@”

co niestety nie dało rady (?!) spam poszedł jeszcze raz. (na gotroot.com znajdziecie więcej regułek do mod_security).

Spam poszedł przez specjalnie spreparowany mail w MIME. W takim wypadku najlepiej filtrować inputa w poszukiwaniu róznych znaków np.

< ?php
$from=$_POST["sender"];
if (eregi(”\r”,$from) || eregi(”\n”,$from)){
die(”Why ?? ”);
}
?>

(/n = %0A /r=%0D)

Dopiero to wychwyciło wstrzyknięty spam kodowany w MIME. Więcej o tym (wraz z przykładami) można przeczytać na SecurePHP.

Póki nie miałem własnego serwera nie sądziłem, że można być narażonym na kilkaset różnych ataków dziennie Logi mod_security normalnie puchną. Najwięcej jest ataków na phpBB, awstats i wordpressa. Boty szukające takich skryptów najlepiej od razu banować bo potrafią one setki razy dziennie zapuszczać tysiące requestów

Dzisiaj polecam wam artykuł Łukasza “Anakina” Lacha pt. “PHP – Bezpieczne programowanie”. Sql/code/shell/email injection, cross-site scripting, cross-site request forgery, HTTP response splitting, directory traversal, session fixation/poisoning/injection w pigułce. Zdecydowanie należy zapoznać się z tymi pojęciami jeśli do tej pory były dla was nieznane. Kolorystyka bloga nie zachęca do czytania, ale wierzcie mi, warto przeczytać.

“ModSecurity is an open source intrusion detection and prevention engine for web applications (or a web application firewall). Operating as an Apache Web server module or standalone, the purpose of ModSecurity is to increase web application security, protecting web applications from known and unknown attacks.”

1. Instalacja mod_security
Oczywiście w naszym kochanym Debianie nie bawimy sie w jakieś zbędne kompilacje tylko załatwiamy sprawę szybko i po męsku:

apt-get install libapache2-mod-security
a2enmod mod-security
/etc/init.d/apache2 force-reload

i po sprawie

2. Konfiguracja mod_security

3. mod_security rules – ogromna baza regułek dla tego moda, na bieżąco aktualizowana. Kupa na prawdę dobrej roboty.

Zadanie domowe na dzisiaj: skanowanie systemu w poszukiwaniu różnych niebezpiecznych świństw jakich teraz pełno się ’szwenda’

Rootkit Hunter

Rootkit scanner is scanning tool to ensure you for about 99.9%* you’re clean of nasty tools. This tool scans for rootkits, backdoors and local exploits by running tests like:

- MD5 hash compare
- Look for default files used by rootkits
- Wrong file permissions for binaries
- Look for suspected strings in LKM and KLD modules
- Look for hidden files
- Optional scan within plaintext and binary files

Rootkit Hunter is released as GPL licensed project and free for everyone to use.

* No, not really 99.9%.. It’s just another security layer

chkrootkit

chkrootkit is a tool to locally check for signs of a rootkit. It
contains:
* chkrootkit: a shell script that checks system binaries for
rootkit modification.
* ifpromisc.c: checks if the network interface is in promiscuous
mode.
* chklastlog.c: checks for lastlog deletions.
* chkwtmp.c: checks for wtmp deletions.
* check_wtmpx.c: checks for wtmpx deletions. (Solaris only)
* chkproc.c: checks for signs of LKM trojans.
* chkdirs.c: checks for signs of LKM trojans.
* strings.c: quick and dirty strings replacement.
* chkutmp.c: checks for utmp deletions.

Bardzo przydatne skrypty. Na szczęscie nic mi niewykryły ale za to przypomniały aby przyblokować pare funkcji w ssh.