Paweł Goleń, blog

O co chodzi z tymi zasobami

Czasami najłatwiej posłużyć się przykładem. W przypadku prostej aplikacji, którą wymyśliłem na potrzeby wyjaśnienia koncepcji dekompozycji aplikacji, jako zasoby prawdopodobnie każdy łatwo zidentyfikuje:

• dane uwierzytelniające użytkowników,
• dane prywatne użytkowników (na przykład jakieś ustawienia),
• dane o produktach,

Wyróżnienie tych zasobów jest dość łatwe, ponieważ są one do pewnego stopnia namacalne, mówi się o nich, pamięta. Nie można jednak utożsamiać zasobów (assets) wyłącznie z danymi.

Trochę mniej namacalne zasoby...

Do listy interesujących dla atakującego zasobów można dodać jeszcze na przykład takie elementy:

• możliwość uruchamiania kodu w kontekście serwera WWW,
• możliwość uruchamiania kodu w kontekście serwera bazy danych,
• możliwość wykorzystania zasobów serwera (adresu IP, łącza, mocy obliczeniowych, miejsca na dysku),

Po co atakujący chciałby wykonywać kod w kontekście serwera WWW, bazy danych, czy korzystać z zasobów serwera?

Wykonanie kodu w kontekście serwera WWW możliwe jest choćby przez wciąż dość powszechne błędy typu Remote File Inclusion. Dzięki temu atakujący może zainstalować na serwerze swoje własne skrypty, które może wykorzystać na przykład do rozsyłania spamu, wykorzystując w tym celu "czysty" (nie listowany w bazach RBL) adres IP oraz łącze serwera i jego moce obliczeniowe.

Podobnie jest w przypadku wykonania kodu w kontekście bazy danych. Być może ujawnienie wymienionych na początku zasobów (danych) nie jest specjalnie istotne, ale wykorzystując błędy typu sql-injection, atakujący może zrobić wiele innych rzeczy, niż tylko poznać dane zawarte w bazie. Tutaj wystarczy przypomnieć o xp_cmdshell w MS SQL. Dzięki uruchomieniu własnego kodu, atakujący znów może wykorzystać zasoby serwera do swoich celów, na przykład do rozpowszechniania malware.

Mam nadzieję, że powyższe przykłady pokazują, iż nawet pozornie mało istotna aplikacja może przestawiać jakąś wartość dla atakującego, która może być powodem ataku. Nawet jeśli ta wartość wydaje się być umieszczona niejako "poza aplikacją", jak przykładowe moce obliczeniowe serwera.

...i jeszcze bardziej abstrakcyjne...

Warto również rozważyć takie zasoby:

• wizerunek (i jego wykorzystanie),
• reputacja (i jej utrata),
• dostępność (i brak dostępności),

Wykorzystanie (cudzego) wizerunku może być istotne dla atakującego. Może chcieć na przykład wykorzystać zaufanie jakim użytkownicy darzą dany serwis i wykorzystać je w trakcie ataku phishingowego, lub do rozpowszechnienia malware (skoro to jest na tej stronie, to nie może być to złośliwe oprogramowanie).

Reputacja również jest zasobem, a jej utrata może spowodować poważne konsekwencje. Wyobraźmy sobie sytuację, w której mało istotny serwis banku (na przykład forum dyskusyjne dla klientów) zostaje skompromitowany. Serwis ten sam w sobie nie ma żadnego związku z systemem transakcyjnym, nie są ujawniane żadne dane klientów, działanie banku nie zostaje w żaden sposób zakłócone. Może wydawać się, że skutki takiego zdarzenia nie powinny być szczególnie istotne, ale prawdopodobnie będą. Informacja na temat takiego zdarzenia na pewno zostanie skwapliwie nagłośniona i prawdopodobnie podchwycona przez media. W rezultacie do klientów (i potencjalnych klientów) dotrze informacja "dane klientów banku X nie są bezpieczne". W tym przypadku nie działa zasada "nie ważne co mówią, ważne, że mówią" i błahe z pozoru zdarzenie może spowodować wcale nie pomijalne straty finansowe (utrata klientów lub potencjalnych klientów).

Także dostępność serwisu jest zasobem. Jeśli na przykład atakujący będzie w stanie spowodować, że aplikacja nie jest dostępna, lub działa nieakceptowalnie wolno, to może spowodować to wymierne straty. W przypadku aplikacji typu bankowość internetowa czy system aukcyjny ta strata jest chyba dość intuicyjna. Taką stratę jednak może ponieść nawet osoba wynajmująca pokoje gościnne, jeśli z jakiegoś powodu strona, na której umieszcza swoją ofertę będzie niedostępna.

Inne przykłady

W przypadku bankowości internetowej ważnym zasobem jest możliwość wykonywania operacji bankowych. Szczególnie miło widzianym, jeśli te operacje można wykonać na cudzym koncie. Konto, na którym nie ma pieniędzy, również przedstawia pewną wartość (pranie pieniędzy, stacja "przesiadkowa" przy wyprowadzaniu pieniędzy od klientów banku).

Popularność Naszej Klasy, oraz zainteresowanie łamaniem haseł pokazuje, że tożsamość też jest pewną wartością, która może być interesująca dla atakującego. Nie jest to żadna nowina, od dawna przecież istnieje problem kradzieży tożsamości.

Kradzież tożsamości może być również celem atakującego w przypadku serwisów aukcyjnych. Użytkownicy zwracają uwagę na to jak długo dany sprzedający (lub kupujący) działa, jakie są opinie na jego temat u innych użytkowników. Jeśli ktoś chce zrobić przekręt, to większą szansę na jego powodzeni ma wówczas, gdy jest użytkownikiem "zaufanym", czyli celem jest kradzież tożsamości/wizerunku/reputacji godnego zaufania sprzedawcy. Oczywiście, takiego użytkownika można sobie we własnym zakresie "wyhodować".

Jest jeszcze jeden temat, który trudna ująć w sposób racjonalny. Jest to czysta ludzka złośliwość, którą można określić również jako bezmyślny wandalizm. Taki atakujący jest jednak mało zmotywowany i w przypadku, gdy strona nie padnie pod naporem "zaawansowanych narzędzi", to wandal znajdzie sobie prawdopodobnie inny, łatwiejszy cel.

To już wiadomo po co

To, co do tej pory napisałem pozwala odpowiedzieć na pytanie po co ktoś chce poświęcić czas na atakowanie aplikacji. Dalsza część tego tekstu jest już luźniej związana z tematem testów penetracyjnych, w szczególności to, o czym piszę wcale nie musi być ich elementem.

A z tymi zasobami to problem jest...

Z zasobami jest problem. Trzeba je zidentyfikować i określić ich istotność, określić, kto ma do nich dostęp. Jeśli zamawiający test penetracyjny oczekuje, że zespół testujący wykona to zadanie w sposób należyty, to jest w błędzie. W przypadku części zasobów (i części aplikacji) rzeczywiście jest tak, że zespół testujący na podstawie swojej wiedzy i doświadczeń ze wcześniejszych projektów, może zidentyfikować istotne zasoby. Im bardziej aplikacja jest specyficzna, nietypowa, tym trudniejsze jest to zadanie. Listę zasobów (przynajmniej tych najbardziej oczywistych) powinien przygotować (albo otrzymać od autorów aplikacji) zamawiający testy. Dlaczego? Dlatego, że między innymi na podstawie tej listy powinien podjąć decyzję o celowości przeprowadzenia takiego testu.

Z doświadczenia wiem jednak, że z tym bywa różnie. Przy zarządzaniu bezpieczeństwem informacji do znudzenia powtarza się, że należy wykonać identyfikację zasobów (w tym wypadku określanych często jako aktywów informacji), a każdy z takich aktywów powinien mieć swojego właściciela, który jest odpowiedzialny za bezpieczeństwo informacji. Właścicielem powinien być ktoś z biznesu, kto z tych informacji korzysta, kto zna ich wartość. W praktyce często zadanie identyfikacji aktywów (zasobów) chciano sprzedać "działowi bezpieczeństwa".

Kto ma dostęp do...

Podobnie jak w przypadku punktów wejścia, tak i w przypadku zasobów należy określić jaki poziom dostępu jest wymagany w celu dostępu do określonego zasobu. Będzie to przydatne przy identyfikacji zagrożeń. Na przykład w sposób prezentowany poniżej. Dla przykładowej aplikacji zidentyfikowane zostały następujące poziomy dostępu:

• użytkownicy nieuwierzytelnieni,
• użytkownicy uwierzytelnieni,
• administratorzy,
• aplikacja WWW (tożsamość pod jaką działa kod serwisu WWW),
• serwer bazy danych (tożsamość pod jaką działa kod procedur SQL),

Dla tej pierwszej grupy zasobów, lista dostępu będzie wyglądała mniej więcej tak:

• dane uwierzytelniające użytkowników,
  • administratorzy,
  • serwer bazy danych,
  • użytkownicy uwierzytelnieni (tylko do swoich danych),
• dane prywatne użytkowników (ustawienia),
  • użytkownicy uwierzytelnieni (tylko do swoich danych),
  • administratorzy,
  • serwer bazy danych,
  • aplikacja WWW,
• dane o produktach,
  • administratorzy,
  • serwer baz danych,
  • aplikacja WWW,
  • użytkownicy uwierzytelnieni,

Po co robić coś takiego? Na przykład do generowania listy zagrożeń, która dla tych trzech zasobów mogłaby wyglądać następująco:

• Zagrożenia związane z danymi uwierzytelniającymi użytkowników
  • Ujawnienie danych uwierzytelniających użytkownikom anonimowym (nieuwierzytelnionym),
  • Ujawnienie danych uwierzytelniających użytkownikom uwierzytelnionym (dane innych użytkowników),
  • Ujawnienie danych uwierzytelniających aplikacji serwera WWW,
• Zagrożenia związane z danymi prywatnymi użytkowników
  • Ujawnienie danych prywatnych użytkownikom anonimowym (nieuwierzytelnionym),
  • Ujawnienie danych prywatnych użytkownikom uwierzytelnionym (dane innych użytkowników)
• Zagrożenia związane z danymi produktów
  • Ujawnienie danych produktów użytkownikom anonimowym (nieuwierzytelnionym),

W rzeczywistości należałoby uwzględnić oczywiście nie tylko ujawnienie danych, ale również nieuprawnione usunięcie, modyfikację czy dopisanie danych.

Tutaj można na chwilę zatrzymać się przy "ujawnieniu danych uwierzytelniających aplikacji serwera WWW". Chodzi o to, że dane uwierzytelniające zapisane są w bazie danych, na przykład w postaci nazwy użytkownika i hasha hasła. Baza danych oferuje procedurę składowaną służącą do weryfikacji poprawności pary nazwa użytkownika, hasło. Aplikacja WWW woła procedurę w trakcie procesu uwierzytelnienia użytkownika i przekazuje do niej dane uwierzytelniające przekazane przez użytkownika. Procedura w bazie danych weryfikuje ich poprawność i zwraca rezultat. Sama aplikacja nie musi jednak odczytywać danych uwierzytelniających z tabeli, wystarczy, gdy będzie miała prawa do wołania odpowiednich procedur. Taka specyficzna forma praktycznego wykorzystania zasady need to know.

Jeśli uda się wygenerować w miarę kompletną listę zasobów w danym systemie i określić macierz dostępu do nich dla poszczególnych poziomów dostępu, to generowanie listy zagrożeń w tym zakresie staje się zajęciem niemalże czysto mechanicznym, co nie oznacza, że lista taka będzie kompletna (a czasami może zawierać mało sensowne pozycje). Może być jednak pomocna przy przygotowywaniu scenariuszy testowych, w szczególności dla stwierdzenia, czy jakiś test jest celowy. Dla przykładu na podstawie powyższych rozważań można stwierdzić, że celowe będą testy mające na celu uzyskanie dostępu do danych produktów przez użytkownika nieuwierzytelnionego, takie same testy w kontekście użytkownika uwierzytelnionego już sensu nie mają, bo użytkownik dostęp do tych danych posiada. Jeśli znaleziony zostanie błąd, który pozwoli użytkownikowi nieuwierzytelnionemu na uzyskanie danych produktów, będzie to podatność (słabość w systemie, która pozwala "zrealizować się" zagrożeniu). Jeśli do wykorzystania tego błędu będzie potrzebne uwierzytelnienie się w aplikacji, to taki błąd ciężko już nazwać podatnością, ponieważ nie ma żadnego zagrożenia, które jest realizowane za jego pośrednictwem. Nie zmienia to faktu, że taki błąd istnieje (działanie systemu niezgodne ze specyfikacją) i powinien być naprawiony, jednak priorytet takich zmian jest znacznie niższy, niż w przypadku podatności.

W bielszym pudełku

Temat zasobów świadomie pominąłem w tekście o dekompozycji aplikacji. W zależności od tego, jaki test ma być przeprowadzony (w szczególności w zależności od tego jak wiele o obiekcie testów wie zespół testujący), taka analiza zasobów może okazać się niemożliwa (przy podejściu "black box"). Tego typu podejście sprawdzać się może w przypadku, gdy testy penetracyjne są prowadzone z pozycji "white box". Jeszcze lepiej takie podejście sprawdzi się, jeśli zostanie ono wykorzystane na etapie tworzenia aplikacji, w celu określenia mechanizmów zabezpieczeń, które powinny być zaimplementowane w celu zapewnienia odpowiedniego bezpieczeństwa danych. Wówczas test penetracyjny może polegać na weryfikacji poprawności implementacji zastosowanych zabezpieczeń.