Zacznę od stwierdzenia, które powtarzam tak często, jak tylko mam okazję. Bezpieczeństwo nie jest celem samym w sobie, bezpieczeństwo musi czemuś służyć. To "coś" to niekoniecznie jest dobre samopoczucie bezpieczników. Celem aplikacji jest realizowanie jej celów biznesowych z zachowaniem akceptowalnego poziomu ryzyka. W wielu miejscach pewne rzeczy można zrobić lepiej. Widziałem ważne mechanizmy bezpieczeństwa, które są zaimplementowane źle. Widziałem pozorne mechanizmy bezpieczeństwa (ach ten security theater) zaimplementowane źle, widziałem też kompletnie nieprzydatne mechanizmy bezpieczeństwa (rozwiązujące nie ten problem, co trzeba), które akurat zostały zaimplementowane dobrze...
Za wrażenia artystyczne punktów brak
Najpiękniejsze rozwiązanie techniczne (jeśli ktoś jest na tyle dziwny, by dostrzegać piękno w takich rzeczach) nie wpływa znacząco na ryzyko, jeśli rozwiązuje nie ten problem, co trzeba. Fort Eben-Emael może i był "piękny", podobnie jak linia Linia Maginota, ale oba zabezpieczenia się nie sprawdziły. Może dlatego, że generałowie przygotowują swoje armie do wojny, która już była. Zmienił się sposób prowadzenia wojny, a wróg zachował się nie tak, jak powinien. Jak mógł...
Niestety, podobne tendencje można zauważyć również w przypadku bezpieczeństwa IT. Wciąż pewne "uświęcone tradycją" rozwiązania są uporczywie stosowane, choć świat się zmienił. Mógłbym tu po raz kolejny wspomnieć o klawiaturach wirtualnych lub hasłach maskowanych. Innym przykładem mogą być kanapkowe firewalle (najlepiej trzy, koniecznie różnych firm) na wejściu do sieci i jedna wielka płaska sieć wewnątrz. Podział "dobrzy my" i "źli oni" już od dawna jest niewystarczający.
Obrońcy mają być skuteczni. Mogą być toporni, ale mają być skuteczni. To samo tyczy się atakujących. Im zależy na osiągnięciu określonych celów, a nie na łamaniu każdego napotkanego zabezpieczenia, zwłaszcza, jeśli jego pokonanie nie jest konieczne do osiągnięcia ich celów.
Podobna sytuacja jest w przypadku testów bezpieczeństwa. Testy bezpieczeństwa to nie jest security research. Jeśli największe ryzyko jest związane z topornymi podatnościami (SQLi, błędy kontroli dostępu, zarządzanie sesją, CSRF), to trzeba zacisnąć zęby i skupić się w pierwszej kolejności na tym. To nie znaczy, że innych rzeczy nie należy zauważać/odnotować, ale trzeba umieć wybrać co w danym przypadku może być istotniejsze. Tak, jak czasem trzeba zastosować Triage i, niestety, oznaczyć kogoś jako Lost.
Opowiem pewną historię. Testowałem kiedyś aplikację i tak jak jedni widzą białe myszki czy różowe słonie, ja widziałem wszędzie padding oracle (polecam: CBC padding attacks). Miejsca, w których szyfrowanie było wykorzystane sugerowały, że być może w ten sposób chronione jest coś, czym można manipulować. Mniej dla zabawy, bardziej dla zysku. Oczywiście jak zwykle w takich sytuacjach okazało się, że standardowe narzędzia (np. PadBuster) niespecjalnie się w tym przypadku sprawdzają. Nie pozostało więc innego, niż zakasać rękawy, chwycić węża w łapy i napisać własne narzędzie, prawda?
Niezupełnie. Rozwiązanie problemu z padding oracle jest trywialne - trzeba dodać MAC. Temat zaparkowałem, choć kolejne przypadki skrzętnie odnotowywałem. Z czasem dowiedziałem się, że klucze i IV są statyczne i wspólne dla wszystkich użytkowników. Na podstawie tej wiedzy mogłem testować też kontrolę dostępu - po prostu wykorzystywałem zaszyfrowaną postać istotnych parametrów. Odroczona gratyfikacja i tym razem okazała się przynosić zyski - znalazłem miejsce, w którym nie musiałem się bawić w padding oracle, zamiast tego aplikacja grzecznie szyfrowała i odszyfrowywała to, o co ją poprosiłem.
Zupełnie inaczej przedstawia się sytuacja, w której potencjalnie słabe szyfrowanie jest istotnym mechanizmem bezpieczeństwa i jego pokonanie pozwala atakującemu osiągnąć właściwie wszystkie jego cele. Wówczas tematu nie można tak łatwo parkować, chyba, że jest jeszcze kilka innych sposobów osiągnięcia tych samych celów, potencjalnie w łatwiejszy sposób.
Skoro już jestem przy takich tematach, warto wspomnieć o prezentacji Building a cost-benefit model for application security testing Pawła Krawczyka. Kravietz przedstawił tu podejście (pewien model), z którym w znacznym stopniu się zgadzam. Tak jak nie każdą aplikację warto testować z taką samą uwagą, tak i nie każdy scenariusz ataku jest jednakowo ważny.
Tu miałem napisać o pewnym modelu/eksperymencie, nad którym jakiś czas temu spędziłem kilka chwil, ale po namyśle odłożyłem sobie to na później.
Drugi tekst, o którym chcę wspomnieć to Whats the point of application pen testing? Ten akurat pozostawię bez komentarza. Ale za to z cytatem:
Just as you can't "test quality in" to a system, you can't "test security in" either. It's not possible to exhaustively pen test a large system — it would take too long and it wouldn't be cost effective to even try.
I tym optymistycznym akcentem kończę.
