Jest “dziura”. I co z tego?

Pod wpisem 0b10 | 0b01 exploit Kravietz umieścił kilka ciekawych myśli. Na przykład w tym komentarzu poruszony został temat, który chciałbym rozwinąć. Zacznijmy od myśli przewodniej:

Ale mechanizm bezpieczeństwa, żeby działał, musi być relewantny. (...)

Ja chciałbym podejść do tego tematu z nieco innej strony. We wspomnianym wpisie mówiłem o celach intruza. Można zidentyfikować cele, które być może chce osiągnąć atakujący i zastosować takie zabezpieczenia, które osiągnięcie określonego celu uniemożliwią. W trakcie testów należy natomiast zweryfikować, czy zastosowane mechanizmy bezpieczeństwa są pełne (nie brakuje jakiegoś) i skuteczne. Brak typowo stosowanego mechanizmu bezpieczeństwa (przykładowo flagi httpOnly) sam w sobie nie musi być podatnością, bo w konkretnym przypadku nie prowadzi do zrealizowania się żadnego konkretnego (sensownego) celu.

Relewantny musi być nie tylko mechanizm bezpieczeństwa, ale również cel intruza. Albo inaczej – cel intruza rzeczywiście musi być celem intruza, a nie czymś, co nam się wydaje, że intruz będzie chciał osiągnąć. W trakcie testów bywają czasem takie sytuacje, w których udaje się coś osiągnąć, ale w zasadzie nie wiadomo co z tego wynika. Wpływ na ryzyko, który ma wykryta podatność, po głębszym przemyśleniu sprawy może okazać się... iluzoryczny. Wówczas nawet trudno nazwać znalezisko podatnością.

Choć sposobów wyceny ryzyka jest wiele, co do zasady ryzyko jest iloczynem prawdopodobieństwa wystąpienia zdarzenia oraz skutków, które wystąpienie zdarzenia powoduje (warto też zapoznać się z artykułem dotyczącym ryzyka na wikipedii). Operacja mnożenia ma to do siebie, że jej wynikiem będzie zerem, jeśli dowolny z czynników jest zerem. Tak więc wpływ podatności na ryzyko będzie bliski lub równy zeru, jeśli:

By lepiej to przedstawić, kilka przykładów. Pierwszy przykład tradycyjnie dotyczy XSS. Przy pomocy XSS można zrobić wiele. Co, gdy ten XSS to w zasadzie self-xss i ofiara sama musi osadzić sobie payload? Można to oczywiście zrobić. Można na przykład połączyć ze sobą content extraction, CSRF i clickjacking po to, by osadzić payload w kontekście ofiary, ale prawdopodobieństwo powodzenia takiego ataku, jest niskie. Jaki to ma wpływ na testy bezpieczeństwa? Jeśli czas jest ograniczony lepiej skupić się na tych scenariuszach, które będą miały istotny wpływ na ryzyko. Oczywiście będą miały wpływ na ryzyko jeżeli uda się je zrealizować.

Inny przykład. Wyobraźmy sobie funkcję przelew własny , która służy do tego, by klient przelewał środki między swoimi kontami. W wielu przypadkach przelew własny nie wymaga autoryzacji. Naturalnym celem intruza może być więc nadużycie tej funkcji do wykonania przelewu na cudze konto. Jeśli taka możliwość istnieje, wystarczy by atakujący uzyskał dane uwierzytelniające ofiary (lub przejął sesję) i będzie on w stanie wyprowadzić środki z konta ofiary. Jeśli jednak przelew wewnętrzny wymaga autoryzacji (kody SMS), to atrakcyjność tej funkcji spada, staje się ona w zasadzie taka sama, jak w dla normalnego przelewu. Sposób ataku też będzie praktycznie taki sam, choć mogę przypuszczać, że szansa powodzenia ataku będzie jednak nieco wyższa – funkcja przelewu własnego może mieć większe zaufanie ze strony ofiary (patrz też: Jak i z jakim skutkiem atakowałem kody SMS).

Albo jeszcze inny przykład. Jednym ze sposobów ochrony przed CSRF jest konieczność ponownego wpisania hasła przez użytkownika. Być może i hasło użytkownika jest łatwiejsze do odgadnięcia niż 256 bitowy losowy token ale jeśli intruz jest w stanie to zrobić, to token też tu nie pomoże, bo... atakujący po prostu zaloguje się na konto ofiary i wykona pożądaną operację bez użycia CSRF.

I właśnie ten ostatni przykład jest najbliższy tego, o czym chciałem napisać. Jakiś czas temu był “błąd” w systemie internetowym jednego z banków, który pozwalał na wydrukowanie potwierdzenia przelewu przed zrealizowaniem transakcji. Czyli teoretycznie mogła zaistnieć taka sytuacja:

W tej chwili atakujący dysponuje wydrukiem potwierdzenia przelewu, który w rzeczywistości nie zostanie zrealizowany. Czy może to być cel intruza? Cóż, o ile posiadanie fałszywego potwierdzenia przelewu jak najbardziej może być celem intruza, to osiągnięcie tego celu w opisany sposób jest po prostu głupie. Wygenerowanie dokumentu, który będzie wyglądał jak autentyczne potwierdzenie przelewu możliwe jest na wiele innych, łatwiejszych sposobów. Istnienie opisanej “podatności” nie daje atakującemu nic czego ten nie może osiągnąć w inny sposób.

Jaki jest morał z tej przydługiej i nieco pokrętnej historii? Taki, że zanim jakiś cel intruza trafi na listę rzeczy do sprawdzenia, trzeba się zastanowić czy ma on sens. Innymi słowy ktoś musi nosić czarny kapelusz i szukać dziury w całym. Jeśli ktoś ma na to ochotę, ostrzegam – zupełnie nie rozumiem dlaczego takie “pesymistyczne” i “negatywne” podejście wkurza innych :)

Jest jeszcze drugi wniosek. Podatność ma niewielki wpływ na ryzyko nie tylko wtedy, gdy jest trudna do wykorzystania, lub skutki jej wykorzystania są niewielkie. Na ryzyko może nie wpływać również w istotny sposób podatność, która pozwala na osiągnięcie czegoś, co atakujący i tak może osiągnąć w inny, równie łatwy lub łatwiejszy sposób. W opisywanym przypadku atakujący mógł sfałszować potwierdzenie przelewu na wiele innych sposobów. Innym przykładem takiej sytuacji może być SQLi w aplikacji administracyjnej, do której dostęp mają wyłącznie administratorzy, którzy i tak mają bezpośredni dostęp do bazy danych.

A na koniec zagadka – w jakim przypadku opisany sposób uzyskania potwierdzenia przelewu, który w rzeczywistości nie został wykonany, jednak ma (większy) sens?

Oryginał tego wpisu dostępny jest pod adresem Jest “dziura”. I co z tego?

Autor: Paweł Goleń