OWASP Top Ten 2021: A04: Insecure Design. Przegląd przypadków.

Ogólnie, w najnowszej wersji OWASP TOP10 widoczne jest podejście, w którym większy nacisk kładzie się na właściwą konfigurację, projektowanie i deployment aplikacji, aniżeli stricte na podatności techniczne. „Insecure Design” niewątpliwie jest jednym z bardziej wyraźnych tego przejawów.

Pierwszą istotną rzeczą jest to, że należy odróżniać niebezpieczny design od niebezpiecznej implementacji. Innymi słowy, punkt A04 dotyczy sytuacji, w których implementacja może być doskonała i pozbawiona błędów, ale nadal będziemy mówili o błędzie/ryzyku bezpieczeństwa ze względu na niewłaściwe założenia w fazie projektowania. Oczywiście może to też działać w drugą stronę – aplikacja może być dobrze zaprojektowana, ale błędy w implementacji narażą ją na ataki.

Jakie więc przykłady błędów można by zaklasyfikować pod Insecure Design? Pierwszym przykładem jaki podaje sam OWASP jest implementacja mechanizmu resetu hasła opierającego się o pytania i odpowiedzi. Bardzo często odpowiedzi na pytania w tego typu mechanizmach mogą być powszechnie znane lub możliwe do odnalezienia z wykorzystaniem serwisów społecznościowych. Myślimy tutaj o pytaniach typu: „Imię żony?”, „Jak nazywał się Twój najlepszy przyjaciel z dzieciństwa?”, czy „Jak nazywa się Twój pies?”. Zauważmy, że niezależnie od jakości implementacji tego mechanizmu, jest on obarczony ryzykiem z samej swojej natury.

W celu poszukania kolejnych przykładów kwalifikujących się pod A04: Insecure Design, posłużymy się listą CWE znajdującą się na końcu opisu każdego ryzyka z OWASP TOP 10. CWE (Common Weakness Enumeration) to lista często występujących słabości w oprogramowaniu. Każdy punkt z OWASP TOP10 ma przypisanych kilka lub nawet kilkanaście różnych CWE.

Szczegółowe komunikaty o błędach w logach

Jednym z pierwszych przypisanych do Insecure Design jest CWE-209: Generation of Error Message Containing Sensitive Information – czyli generowanie komunikatów o błędach zawierających wrażliwe informacje. W pierwszej chwili może się wydawać, że ten błąd raczej podpada pod niewłaściwą konfigurację (bo często wyświetlanie błędów można wyłączyć jednym ustawieniem konfiguracyjnym), ale istnieją scenariusze, w których to właśnie etap projektowania może wprowadzać tutaj problemu. Wezmę przykład z życia wzięty – z pentestu sprzed kilku lat. Pewna aplikacja była podatna na błąd typu path traversal, tzn. miałem możliwość odczytu dowolnych plików na dysku serwera. Udało mi się odgadnąć ścieżkę, pod którą przechowywane są logi.

Jeżeli w aplikacji wystąpił jakiś błąd, wówczas logowana była informacja o błędzie, a razem z nim parametry zapytania – z uwzględnieniem ciasteczek! Mogłem zatem odczytywać ten log co jakiś czas, sprawdzać czy wystąpiły jakieś błędy, a jeśli tak – to mogłem przejąć konto użytkownika, bo znałem jego numer sesji.

Zauważmy, że błąd jaki tutaj popełniono polegał na samym założeniu, że w logach należy przechowywać numery sesji użytkowników.

Walidacja tylko po stronie klienta

Innym CWE wymienionym w punkcie A04 jest CWE-602: Client-Side Enforcement of Server-Side Security. Krótko mówiąc, chodzi w nim o implementację pewnych zabezpieczeń tylko na poziomie klienta (czyli w przypadku aplikacji webowych będziemy mieli tutaj zazwyczaj na myśli JavaScript), choć powinny one być zaimplementowane też na poziomie serwera.

Realnych przykładów tego typu błędów można znaleźć mnóstwo. Swego czasu na szkoleniach webowych Securitum pokazywaliśmy błąd na realnym urządzeniu Cisco, w którym można było wykonać dowolny kod po stronie urządzenia. Błąd zaczyna się od tego, że w panelu administracyjnego tego routera istnieje funkcjonalność ping. Pod spodem było wykonywane faktyczne polecenie ping. W interfejsie należało podać adres IP lub nazwę hosta, który chcemy pingować. Po stronie klienta ta nazwa hosta była weryfikowana, tj. próba wpisania jakiejkolwiek „podejrzanej” nazwy hosta (np. zawierającej takie znaki jak średnik czy nowa linia) skutkowały błędem.

Wystarczyło jednak przechwycić zapytanie do urządzenia za pomocą dowolnego narzędzia typu proxy, by bezpośrednio do serwera wysłać nazwę hosta np. 127.0.0.1; rm -rf *. Serwer już nie protestował i faktycznie wykonał to kolejne polecenie.

Przechowywanie haseł w postaci odwracalnej

Przyjrzyjmy się innemu CWE: CWE-257: Storing Passwords in a Recoverable Format – przechowywanie haseł w postaci odwracalnej. Mówimy o tej słabości w kontekście złego projektu aplikacji, choć moim zdaniem można by ją zaklasyfikować również do innych punktów OWASP TOP10:. A02 – Cryptographic Failures oraz A07 – Identification and Authentication Failures.

Jak powszechnie wiadomo (miejmy nadzieję!) hasła powinny być przechowywane w postaci jednokierunkowej funkcji skrótu. Dzięki temu w przypadku ewentualnego wycieku haseł z bazy danych, napastnicy nie poznają od razu haseł użytkowników, tylko muszą je wcześniej złamać. W przypadku użycia silnej polityki haseł i soli – ten proces może być bardzo długotrwały, czy wręcz być praktycznie niewykonalny w sensownym czasie.

Niektóre systemy przechowują jednak hasła w postaci odwracalnej, tj. najczęściej zaszyfrowane. Jeśli więc napastnik uzyska równocześnie dostęp do bazy haseł oraz do klucza szyfrującego – dostaje od razu wszystkie hasła. Ale nawet jeśli tego klucza szyfrującego nie będzie miał, to może się okazać, że pewne hasła i tak będzie się dało złamać.

Ciekawym przykładem jest tutaj wyciek haseł z Adobe z 2013 roku. Wyciekły wówczas zaszyfrowane hasła (a klucza czy algorytmu szyfrującego nie uzyskano), ale i tak na podstawie podpowiedzi do hasła można było ustalić jakie hasło się kryło pod danym szyfrogramem.

Przykładowy szyfrogram z tego wycieku: lez6oZcL1DDAhZNKBW56+w==. Wskazówki do przypomnienia hasła to m.in. „sport”, „game”, „beach”, „v”. Czy domyślacie się już jakie to hasło? 😄 Niedługo po wycieku powstała strona Adobe Crossword, w której celem jest odgadywanie haseł z wycieku Adobe w formie krzyżówek. Polecam na nudę!

Wrażliwe dane w parametrach GET

Ostatnim przykładem, któremu się przyjrzymy w tym tekście jest CWE-598: Use of GET Request Method With Sensitive Query Strings. Zapytania typu GET co do zasady powinny służyć tylko do odczytywania danych, a parametry w nich przekazywane nie powinny zawierać danych wrażliwych. Dzieje się tak, ponieważ adresy URL mogą być przechowywane w historii przeglądarki czy pośrednich serwerach proxy, przekazywane w nagłówku Referer, odkładać się w logach itp.

Jako ilustrację, dlaczego przesyłanie tego typu danych w GET jest złym pomysłem, niech posłuży jedna linia z access.log z Sekuraka:

1.2.3.4 – – [02/Nov/2021:13:00:26 +0000] „GET /wp-content/uploads/2021/10/Zrzut-ekranu-2021-10-28-o-14.34.32.png HTTP/1.1” 304 140 „https://XXXXXXXXX/app/?version=60&login=radoslaw.XXXXX@XXXX.pl” „Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36”

Tego typu wpisów było więcej. Krótko mówiąc: pewna aplikacja w adresie URL ma zapisany login aktualnego użytkownika. Następnie ten login (a właściwie: te loginy) lądują na serwerze Sekuraka w nagłówku Referer.

Podsumowanie

W tekście omówiłem kilka prostych przykłady ryzyka A04: Insecure Design z najnowszej wersji OWASP TOP10. Przychodzą wam do głowy inne przykłady występowania tego typu ryzyka? Dajcie znać w komentarzach!

— Michał Bentkowski, prowadzi szkolenie: praktyczne wprowadzenie do OWASP Top Ten