J

eśli interesują nas wcześniejsze dwie części to znajdziemy je tu (1) i tu (2). Przejdźmy teraz do kolejnej części. W ciągu ostatnich lat bezpieczeństwo webaplikacji stało się bardzo ważnym tematem w dziedzinie IT. Zalety, jakie oferuje sieć sprawiły, że bardzo ważne usługi zostają opracowane jako aplikacje internetowe. Wymagania biznesowe związane z bezpieczeństwem wspomnianych aplikacji również uległy przemianie. Oprócz dobrych praktyk programistycznych wymagane są też dobre praktyki bezpieczeństwa. Stosowane są dodatkowe zabezpieczenia takie, jak WAF (ang. Web Application Firewall). Zapory sieciowe aplikacji to transparentne zapory ogniowe warstwy siódmej, które kontrolują ruch sieciowy i “próbują” chronić aplikację przed atakami.

Przykładowy schemat komunikacji użytkownika z chronioną aplikacją może prezentować się następująco:

[Użytkownik] ---> [Internet] ---> [WAF] ---> [Webaplikacja]

Jeśli komunikacja ta odbywa się za pomocą już przyjętego standardu SSL/TLS to istnieje możliwość “oszukania” zapory sieciowej. Jak wiemy, uścisk dłoni SSL składa się trzech głównych faz:

1. Klient/server hello:

Wymiana uścisku zaczyna się od klienta, który wysyła wiadomość ClientHello. Wiadomość ta zawiera wszystkie informacje, których potrzebuje serwer, w tym obsługiwane zestawy szyfrów i wersje SSL/TLS. Po otrzymaniu wiadomości serwer odpowiada wiadomością ServerHello, która zawiera podobne informacje, jakie otrzymaliśmy od strony klienta: obsługiwane zestawy szyfrów i wersje SSL/TLS, jakie zostaną użyte podczas połączenia.

2. Wymiana certyfikatów:

Po inicjalizacji połączenia serwer musi potwierdzić swoją tożsamość klientowi. Dlatego wysyła on certyfikat SSL/TLS klientowi, a ten sprawdza czy jest on zaufany i kontynuuje połączenie.

3. Wymiana kluczy:

Kiedy bezpieczny tunel jest zestawiony – serwer i klient wymieniają się kluczami, które zostaną użyte do szyfrowania i deszyfrowania danych.

Wektor ataku:

Jeśli do połączenia z webaplikacją zostanie użyty zestaw szyfrów, którego nie wspiera WAF – teoretycznie nie będzie on w stanie zidentyfikować ataku, ponieważ nie będzie on w stanie “zobaczyć” przepływu danych. Załóżmy, że WAF wybranego dostawcy według dokumentacji obsługuje następujące algorytmy szyfrujące:

SSLv3:

SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA

TLS/1.0 – 1.2:

TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_EXPORT1024_WITH_RC4_56_MD5
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_RC4_128_MD5 = { 0x000x04 }
TLS_RSA_WITH_RC4_128_SHA = { 0x000x05 }
TLS_RSA_WITH_DES_CBC_SHA = { 0x000x09 }

Kolejnym krokiem jest zidentyfikowanie szyfrów, które obsługuje webaplikacja. Najprostszą metodą jest użycie narzędzia sslscan lub skorzystanie z serwisu Qualys SSL Labs:

sslscan https://webaplikacja.net/ | grep Accept

Powyższe polecenie pokaże nam wszystkie wspierane przez webaplikację wersje SSL/TLS oraz szyfry. Wystarczy teraz porównać wyniki skanowania narzędziem sslscan z informacjami w dokumentacji WAF:

Accepted TLSv1 256 bits ECDHE-RSA-AES256-SHA

Powyższy szyfr jest wspierany przez webaplikację (lub serwer, który ją udostępnia), ale nie przez aplikacyjną zaporę ogniową. W celu dowodu koncepcji skonfigurujmy WAF tak, aby blokował żądania odwołujące się do ścieżki: /ssl-test:

agresor@darkstar:~$ curl -XGET https://waf.test.lan/ssl-test
Error 403 (Forbidden).

Spróbujmy teraz wykonać to samo żądnie z użyciem odpowiedniego (nieobsługiwanego przez niego) szyfru:

agresor@darkstar:~$ curl -XGET --ciphers ECDHE-RSA-AES256-SHA https://waf.test.lan/ssl-test
Hello Moto!

Jak widzimy z powyższej odpowiedzi udało nam się ominąć ochronę WAF.

Więcej informacji: Bypassing Web-Application Firewalls by abusing SSL/TLS