Paweł Goleń, blog

Do znudzenia można i trzeba powtarzać, że bezpieczeństwo nie jest stanem, lecz procesem. To, co jest bezpieczne dziś, nie musi być takie jutro. Ataki stają się coraz bardziej wyrafinowane, sposób działania intruzów się zmienia, bo zmienia się stan bezpieczeństwa samych aplikacji.

Stworzenie absolutnie bezpiecznej aplikacji jest niemożliwe. Można poprawić jakość produktu poprzez uwzględnienie kwestii bezpieczeństwa w trakcie projektowania aplikacji, odpowiednie szkolenia programistów, określenie odpowiednich praktyk odnośnie zasad programowania, użycie odpowiednich wzorców projektowych, przeglądy kodu, testy penetracyjne, (...). Rezultatem jest bezpieczniejsza aplikacja, ale nie absolutnie bezpieczna. W szczególności nie można zakładać, że jeśli testy penetracyjne nie wykazały istnienia podatności, to żadne podatności nie istnieją i nie zostaną one znalezione przez intruzów. Wynika to z faktu, że potencjalnych intruzów jest więcej i mają zdecydowanie więcej czasu niż zespół realizujący testy.

Troska o bezpieczeństwo aplikacji nie może kończyć się z chwilą wdrożenia jej na produkcję. Nie powinna się ona również ograniczyć do okresowych testów wykorzystywanej aplikacji. Warto jest zbierać informacje o działaniu aplikacji, próbach przełamania jej zabezpieczeń oraz ich skuteczności. Inaczej mówiąc - warto monitorować jak ONI atakują aplikację i weryfikować, czy aplikacja jest odporna na tego typu ataki. Pomysł wcale nie jest oryginalny, wywiad i szpiegostwo znane jest ludzkości od wieków. W temacie bezpieczeństwa można wspomnieć choćby o Microsoft Security Intelligence Report, zresztą cały projekt Honeynet ma podobną motywację.

Szczególnym przypadkiem jest analiza powłamaniowa. Zaistnienie incydentu jest zdarzeniem zdecydowanie nieporządanym, ale skoro już do niego doszło, należy wyciągnąć z niego jakieś wnioski (wnioski, a nie koniecznie konsekwencje). Skupianie się na przywróceniu działania systemu nie jest dobrą drogą, w końcu szaleństwem jest oczekiwanie innych rezultatów jeśli robi się coś wciąż w ten sam sposób, zresztą ten temat już poruszałem: Co się z tobą stanie, gdy ci ufać przestanę?. Analiza powłamaniowa w tym przypadku pozwoli na ustalenie co właściwie się stało i jak to się stało (jak działał intruz), co z kolei pozwoli na taką modyfikację systemu, by intruz nie mógł do niego ponownie się włamać (a przynajmniej nie mógł tego zrobić w ten sam sposób, co za pierwszym razem). Ważne jest również uprzątnięcie ewentualnych pozostawionych przez intruza pamiątek (nie mówię o śladach, tylko o "pułapkach" postaci backdora czy jakiejś bomby logicznej).

By działania móc analizować, trzeba mieć dane na ich temat. Dane mogą być zbierane na różnych poziomach, przykładowo mogą być to logi serwera WWW, logi aplikacyjne, logi wykorzystanych systemów IDS/IPS czy logi WAF.

W większości przypadków posiadanie samych tylko logów serwera WWW jest zdecydowanie niewystarczające. Brak jest choćby informacji o parametrach i ich wartościach przekazywanych za pomocą metody POST, informacja o odpowiedzi aplikacji również jest mocno ograniczona, sprowadza się właściwie do statusu odpowiedzi oraz jej wielkości. Informacje te są oczywiście przydatne, ale na temat tego jak zachowała się aplikacja mówią stosunkowo niewiele. Tu posłużę się zresztą przykładem.

Przykład dotyczy udostępnionego przeze mnie wyzwania (http://bootcamp.threats.pl/lesson08/). Obserwując odwołania do danej ścieżki (tu przy pomocy Mandiant Highlighter) można zauważyć pewną anomalię:

Jest ona jeszcze wyraźniej widoczna przy zastosowaniu skali liniowej (poprzedni wykres był w skali logarytmicznej):

Wykres ten w jednoznaczny sposób pokazuje, że w pewnej chwili nastąpiło wyjątkowo intensywne zainteresowanie aplikacją, przez co ilość odwołań w jednostce czasu nagle wielokrotnie przekroczyła wartości dla niej typowe. Oczywiście nie każda taka sytuacja musi być objawem (udanego) włamania, równie dobrze może to być skutek znalezienia się na wykopie, można jednak sprawdzić z czego wynika tak nagłe zainteresowanie. Wówczas okazuje się, że nagłe zainteresowanie nie jest jedynym dziwnym symptomem. Na uwagę również zasługuje anomalia:

Anomalia ta została zaznaczona czerwoną ramką. Wykres po prawej stronie pokazuje spojrzenie "z lotu ptaka" na zawartość pliku tekstowego, w szczególności długość poszczególnych linii. Jak widać w logu pojawia się dość duży blok linii wyraźnie krótszych. Data i godzina pojawienia się tego bloku pokrywa się z prezentowanym na poprzednich wykresach pikiem. Wpisy te zawierają puste pole referer oraz nietypową nazwę agenta.

Wpisy w logu mówią jaka ścieżka (plik) stał się nagle tak bardzo popularny, brak jest natomiast informacji jakie parametry były przekazywane do tego pliku, a że jakieś były można się domyślić, ponieważ wykorzystywana była również metoda POST (tak, można wykorzystać metodę POST bez przekazywania żadnych parametrów, tylko po co?). W przypadku wszystkich zapytań z tego bloku odpowiedzią serwera było 200, a więc każde żądanie zakończyło się powodzeniem, co jednak nie mówi nic o odpowiedzi samej aplikacji. Jedyną różnicą (i jednocześnie informacją o odpowiedzi aplikacji), jaką można zauważyć jest długość odpowiedzi, tu występują dwie wartości: 1841 oraz 1880. Na tej podstawie można się domyślać, że w tym czasie serwer zwracał dwie różne odpowiedzi, a idąc dalej - można domniemywać, że jest to ślad po wykorzystaniu blind sql injection. Odfiltrowując te dwie wartości można znaleźć dwie interesujące linie (zaznaczone kolorem):

Patrząc na ich daty i korelując z komentarzami na blogu dość łatwo można ustalić, kto i dlaczego je zostawił. Zresztą ?logout też dużo mówi.

W efekcie wiadomo, że coś się stało, że prawdopodobnie komuś udało się zalogować do systemu, można domniemywać (albo inaczej - na podstawie wiedzy eksperckiej zakładać), że zrobił to za pomocą błędu typu blind sql injection, brak jest natomiast jakichkolwiek informacji jak to zrobił. Pozostaje jedynie zbadanie atakowanej funkcji, co być może pozwoli na ustalenie sposobu, w jaki została nadużyta, co bywa często frustrujące.

Wykorzystanie w tym miejscu WAF w trybie logowania być może dałoby więcej informacji. Być może parametry przesyłane przez intruza wzbudziłyby jedną z jego reguł i spowodowały zarejestrowanie dodatkowej informacji, co zdecydowanie. Swoją drogą mogłoby to spowodować pewien efekt uboczny w kontekście uwierzytelnienia użytkownika. Czy ktoś wie o jakim efekcie ubocznym mowa i czy w tej konkretnej implementacji miałoby to istotne znaczenie?