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:
- skutki jej wykorzystania są (prawie) żadne,
- jej wykorzystanie jest (bardzo) mało prawdopodobne,
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:
- atakujący składa dyspozycję przelewu, operacja czeka na realizację (sesję ELIXIR),
- atakujący, korzystając z istniejącej podatności, drukuje potwierdzenie przelewu,
- atakujący anuluje złożony wcześniej przelew,
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?
Ale osobiście widzę zastosowanie użycia oryginalnego dokumentu potwierdzającego przelew mającego taką samą moc prawną jak druczek z pieczątkami (chociaz nie wiem jaka naprawde one maja, to jednak jest jakis respekt w spoleczenstwie). Np. nie mamy pieniedzy na cos teraz, albo firma nie ma na cos istotnego srodkow, wtedy robi sobie takie potwierdzenie, mydli kontrahentom oczy przez kilka dni, a potem wysyla prawdziwy przelew, ktore tyle lecial bo banki są niekompetentne.
Cóż, oczywiście, że masz rację w wielu kwestiach (;D), ale pragnę zauważyć, że wszystko zależy od tego czy chodzi o moje studenckie konto czy Pani z Księgowości. Chociaż i tak b. prawdopodobne, że można spodziewać się phishingu/załączników w poczcie bardziej niż wyszukanych ataków. Bezpieczeństwo całego systemu ogranicza w końcu element najgorzej zabezpieczony, a to pewnie będzie ludzka psychika.
Inną kwestią jest to, że coraz częściej docierają do nas informacje o atakach celowanych, wyszukanych technicznie, wyrafinowanych wręcz. Dlatego chce wiedzieć, że dany atak jest niemożliwy, a nie mało prawdopodobny, szczególnie w systemach takich jak bankowe.
Obaj trafiliście w ten przypadek, który ma więcej sensu. Konkretnie chodziło mi właśnie o podpis cyfrowy, który między innymi mBank stosuje w przypadku plików PDF. Jeśli chodzi o pomysł Bartosza to nie spotkałem się z tego typu danymi osadzanymi na przelewie. Po pierwsze takie dane ("podpis") trzeba wygenerować, po drugie druga strona musi mieć możliwość ich weryfikacji. Oczywiście taki system można stworzyć, ale ma to sens znikomy, jeśli skorzystałby z tego może promil użytkowników, pewnie jeszcze mniej.
Dalszą część dyskusji chyba przeniosę do oddzielnego wpisu, bo temat jest po pierwsze za długi do komentarza, a po drugie właśnie dostałem zabawki do zabawy i trochę nie jestem w stanie się skupić nad merytoryką
Tylko raz, niestety, spotkałem się z możliwością przesłania PDFa mailem.
Co do weryfikacji takiego podpisu, to chyba nie jest problem napisania aplikacji na smartfony, których jest coraz więcej, skanującej QRCode.
Największym problemem, jak zwykle, byłby wspólny standard tych kodów
Wracając do okienka - jeśli musisz pokazać potwierdzenie przelewu, to z dużym prawdopodobieństwem ONI mają na Ciebie dobre namiary (np. jeśli pokazujesz to w urzędzie). Może i uzyskasz krótkotrwały sukces, ale za to w perspektywie masz sprawę za fałszowanie dokumentów. Jak dla mnie umiarkowana perspektywa, choć inni ludzie mogą mieć wyższy poziom tolerancji ryzyka.