Pentester: doomed to fail?

Druga odsłona przemyśleń dotyczących pracy (pen)testera.

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:

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%25. 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...

Oryginał tego wpisu dostępny jest pod adresem Pentester: doomed to fail?

Autor: Paweł Goleń