Druga odsłona przemyśleń dotyczących pracy (pen)testera.
Pentester: doomed to fail?
Niech będzie aplikacja A, z którą powiązany będzie zbiór V. Elementami v zbioru V są podatności. Jeśli za warunek sukcesu testów uznamy zidentyfikowanie wszystkich podatności, wówczas sytuacja (pen)testera jest niewesoła. Zwłaszcza w porównaniu z sytuacją atakującego, któremu wystarczy znalezienie jednej podatności. Jeśli do tego dodamy dysproporcję sił i środków, (pen)testerzy mają przewalone...
Jaka dysproporcja? Proszę bardzo:
- aplikację testuje ograniczony zespół, atakować może każdy z ponad miliarda użytkowników Internetu,
- czas testów jest ograniczony założeniami projektu, atakujący mają czas ograniczony jedynie "czasem życia" aplikacji,
- atakujący mogą pracować w lepszych warunkach,
- atakujący mogą mieć lepszą (nowszą) wiedzę,
- atakujący mogą mieć więcej szczęścia,
- (...),
Dwa pierwsze punkty tym razem pominę, choć wrócę do nich w przyszłości. Odnośnie pozostałych punktów kilka wyjaśnień poniżej.
Testy bezpieczeństwa aplikacji to metodyczna, monotonna praca wymagająca dużej uwagi i skupienia, podobnie zresztą jak testowanie aplikacji w ramach quality assurance. Zdolność przeciętnego człowieka do utrzymania koncentracji jest ograniczona i dodatkowo uzależniona od wielu czynników. Jeśli w otoczeniu jest głośno (bo akurat za ścianą jest remont), gorąco (bo awaria klimatyzacji), krzesło jest niewygodne, dostarczony przez klienta sprzęt woli zajmować się sobą, pracujący w tym samym pomieszczeniu ludzie dostają głupawki (bo akurat piątek), albo jestem normalnie głodny (oj tak, nie lubię być głodny, robię się agresywny) moja koncentracja spada. Można tu podać jeszcze dziesiątki innych czynników rozpraszających, zresztą każdy jest inny i każdego irytować może co innego, a rozpraszające czynniki mogą wydawać się innym absurdalne.
Tak wiem - złej baletnicy.... Tylko, że nie są to wymówki, ale ograniczenia człowieka i jego umysłu. Tu warto wspomnieć o firmie Specialisterne (patrz też na wiki), w której znaczącą część pracowników stanowią ludzie z ASD. Okazuje się, że osoby autystyczne mogą mieć predyspozycje do takich właśnie monotonnych, metodycznych zadań.
Kwestia wiedzy to w zasadzie kwestia statystyki, porównanie ilości osób wchodzących w skład zespołu testującego oraz ilości osób (potencjalnie) atakujących aplikację. Można tu kontynuować rozważania przywołując pojęcia typu "cecha populacji" albo "rozkład normalny", ale ja nie o tym... Chciałem zwrócić uwagę na inną kwestię. Aplikacje korzystają z wielu modułów (gotowych bibliotek). Błąd w aplikacji może wynikać z błędu w takich "zewnętrznych" modułach, że wspomnę choćby o Apache Struts org.apache.struts.taglib.html.Constants.CANCEL Validation Bypass. Ciekawym przeżyciem może być również test bezpieczeństwa infrastruktury opartych na produktach Microsoftu, którego czas trwania "zawiera" w sobie patch tuesday.
Wreszcie ostatni punkt - szczęście. Tak, jest to kwestia istotna. Można mówić też trochę o intuicji czy doświadczeniu w podobnych aplikacjach, ale to nie zawsze wystarczy. Sposobów interakcji użytkownika z aplikacją jest bardzo, bardzo wiele i raczej nie zdarza się, by pokrycie testami wynosiło 100%. A "przypadek użycia", w którym występuje podatność, może być na przykład następujący: wypełnij formatkę (krok 1), wypełnij formatkę (krok drugi), wybierz dwukrotnie akcję "wstecz" (...). Po wykonaniu tych operacji okazuje się, że w tym (i tylko tym) przypadku funkcja wypełniania formatki wcześniej wpisanymi danymi, wypisze dane bez właściwego kodowania.
Wracając do początku - jeśli sukcesem (pen)testera ma być znalezienie wszystkich błędów (funkcjonalnych, bezpieczeństwa), to w zasadzie na sukces ma on szanse mizerne... I to właśnie jedna z moich podstawowych refleksji odnośnie bezpieczeństwa aplikacji internetowych i przydatności testów bezpieczeństwa opartych na wyszukiwaniu podatności. Dlatego też podobają mi się wszelkiego rodzaju opracowania dotyczące SDLC (np. Microsoft SDL, BSIMM, OpenSAAM). Bo to nie chodzi o to, by znaleźć podatność, tylko o to, by później ona została usunięta i nie pojawiła się ponownie przy najbliższej okazji...
1. nie po to wynajmuje pentestera zeby filozofowal
2. jak mi pentester powie ze nie znajdzie podatnosci ale upewni sie ze zostanie zalatana to raczej nie bede zainteresowany jego uslugami
3. nie jest problemem pentestera czy klient zalata podatnosc czy nie, czy ma procedury czy nie ma... pentester ma znalezc "dziure w calym"
4. zdanie nielogiczne... trudno zalatac cos (nawet majac najlepsze procedury) jezeli sie tego "nie odnajdzie" najpierw...
2. Chodzi o znalezienie braku/nieskuteczności "security controls", które może powodować podatność,
3. Klasyczne podejście "zrobić test i zapomnieć", na szczęście coraz większej ilości klientów zależy na zwiększeniu bezpieczeństwa/zmniejszeniu ryzyka niż posiadaniu dupokrytki dla audytu,
4. Patrz punkt 2. Usuwając lub prawidłowo implementując "security controls" masz sporą szansę na usunięcie podatności, która nie została wykryta i znacznie zmniejszasz szanse wprowadzenia takich podatności w przyszłości,
Ależ testy penetracyjne nie służą do identyfikowania wszystkich podatności tylko do wskazania podatności praktycznych, oczywistych, rażących czy dostępnych w danym scenariuszu użycia.
Jeśli chcemy zlokalizować WSZYSTKIE podatności to prowadzimy analizę formalną w stylu Common Criteria, ale kosztuje to i trwa sto razy więcej niż test penetracyjny. Dlatego też nikt tego nie robi dopóki nie jest to naprawdę niezbędne ze względu na straszliwą wartość chronionego dobra
Szczególnie niewdzięcznym tematem jest sql injection, które może wystąpić praktycznie w każdym parametrze. Jego skutki są takie same, niezależnie czy występuje w funkcji używanej przez 99% użytkowników, czy na jakiejś zapomnianej formatce, którą odwiedzi 0,01% użytkowników...
Jeśli np. w czasie testu uzyskuję błąd od ODBC i jestem w stanie zbudować na bazie tego SQL injection, to raportuję to jako SQL injection. Jeśli nie - bo np. operują na prepared statements, to raportuję jako niewystarczającą walidację danych wejściowych i zbytnią gadatliwość serwera.
Ponieważ jednak równocześnie często jestem osobą odbierającą raporty firm zewnętrznych, to mogę powiedzieć, że absolutnie nie mam do wykonawcy wyrzutów jeśli nie będzie w stanie zademonstrować PoC. Nie widzę pożytku z płacenia wykonawcy za spędzenie kilkunastu dodatkowych godzin na prowadzoną w ciemno próbę zbudowania działającego SQL injection - przecież to można w 5 minut stwierdzić biorąc developera i kod źródłowy.
Oczywiście, mogłeś mieć odmienne doświadczenia co wynika z faktu, że są różni zamawiający Wydaje mi się, że właśnie dla uniknięcia podobnych pretensji powstał ASVS.
Wykonawcy też są różni - w czerwcu musiałem spędzić dwa dni na dyskusjach z klientem, bo renomowana amerykańska firma pentesterska bezmyślnie skojarzyła ataki na RC4 i MD5 z ich implementacją w SSL.