Tytuł tego wpisu to zapożyczenie z piosenki KNŻ, dobrze on ilustruje to, o czym chcę tym razem napisać. No właśnie? Co się stanie (a przynajmniej powinno się stać) w przypadku, gdy będzie miał miejsce "incydent", czyli mówiąc wprost - gdy ktoś się włamie? Niestety, nadal często stosowane jest podejście na zasadzie "posprzątać i udawać, że nic się nie stało". Problem w tym, że tak naprawdę to jest błędne koło - skoro ktoś się włamał, to musi istnieć podatność, która na to pozwala. Usunięcie skutków ataku nie usuwa podatności, a więc atak może się powtórzyć...
Co się z tobą stanie, gdy ci ufać przestanę?
Próba "ukrycia" faktu włamania jest zrozumiała. Nie jest to powód do dumy, może niekorzystnie wpłynąć na wizerunek firmy, spowodować wymierne straty finansowe. Dodatkowo nader często sytuacja "włamanie" nie jest przewidziana w planach działania i tak naprawdę nikt nie wie, co należy robić. To ŹLE, firma powinna mieć swoją procedurę obsługi tego typu incydentów, nie koniecznie własnymi środkami - plany te mogą zakładać współpracę z zewnętrznymi firmami, policją, prokuraturą.
Działania te powinny uwzględnić działania, które umożliwią udzielenie odpowiedzi na pytania:
- co się stało,
- jak to się stało,
Następnie należy odpowiedzieć na pytanie "Co zrobić, by incydent się nie powtórzył". Nie jest dobrą praktyką dążenie do jak najszybszego przywrócenia systemu/aplikacji do działania, kosztem odpowiedzi na dwa wymienione wcześniej pytania. Niedostępność systemu/aplikacji jest zła, ale gorsze jest ponowne uruchomienie systemu, który staje się wkrótce ofiarą takiego samego ataku. Oczywiście nie każdy incydent powoduje "zatrzymanie" aplikacji, czasami mogą być pewne objawy, które sugerują, że dzieje się coś złego. Takie sytuacje też nie mogą być ignorowane.
Pytanie "co zrobić, by incydent się nie powtórzył" nie może zawężać się jedynie do doraźnego usunięcia konkretnej podatności. Należy wyszukać innych, podobnych. W przeciwnym razie działania naprawcze przypominać będą zatykanie palcem kolejnych dziur w tamie.
Dlaczego o tym piszę? By uniknąć na przykład takich sytuacji:
Ktoś włamuje się na serwer WWW, umieszcza swoją własną treść (warez), administratorzy usuwają skutki włamania. Całość powtarza się co mniej więcej 24 godziny. Firewall jest włączony, wszystkie poprawki zainstalowane, magia? Nie, nie magia. SQL Injection, SQL Server 2000 działający na koncie LocalSystem, brak jakiegokolwiek hardeningu. Wystarczyło przejrzeć logi IIS by wiedzieć, co się dzieje...
Ktoś włamuje się na serwer, modyfikuje aplikację. Administratorzy (prawdopodobnie) usuwają podatność, która została wykorzystana w trakcie włamania, ale aplikacja nie jest przywrócona do stanu "czystego". Poprzednia podatność nie jest już włamywaczowi potrzebna. Okazuje się, że nie istnieje "oryginał" aplikacji. Jej jedyny "egzemplarz" istnieje na zaatakowanym serwerze... Cóż, nie trzeba kłaść wzorca aplikacji obok wzorca metra w Sèvres pod Paryżem, jednak posiadanie jednej jedynej instancji aplikacji jest po prostu GŁUPIE.
Formatka zawiera dwa pola wyboru (dropdown). W jednym z nich zgłoszony jest SQL Injection. Poprawiona wersja aplikacji zawiera SQL Injection w drugim z tych pól... Inżynieria oprogramowania nie jest nową dziedziną!
W ramach ciekawostki: Web Application Incident Response & Forensics: A Whole New Ball Game!
