Читать книгу Na tropie błędów. Przewodnik hakerski - Peter Yaworski - Страница 16

Poziom trudności: Niski

URL: N/A

Źródło: https://www.hackerone.com/reports/111968/

Data zgłoszenia: 20 stycznia 2016

Nagroda: 500 $

Niektóre strony internetowe próbują się chronić przed otwartymi przekierowaniami przez implementację stron pośredniczących, które wyświetlają się przed ukazaniem oczekiwanej zawartości. Za każdym razem, gdy przekierowujesz użytkownika na URL, możesz wyświetlić pośredniczącą stronę z wiadomością wyjaśniającą użytkownikowi to, że opuszcza domenę, na której się znajduje. W rezultacie, jeżeli przekierowująca strona pokazuje fałszywy login lub próbuje udawać zaufaną stronę, użytkownik będzie wiedział, że jest przekierowywany. To podejście stosuje serwis HackerOne w przypadku większości linków ze swojej strony; na przykład dla linków w zgłoszeniach błędów.

Możesz używać stron pośredniczących, by uniknąć podatności na przekierowania, jednakże komplikacje, które wynikają z tego, w jaki sposób strona wchodzi w interakcję z innymi, może doprowadzić do uszkodzenia linków. HackerOne używa Zendesk, serwisu obsługi klienta w systemie ticketowym, na subdomenie https://support.hackerone.com/. Poprzednio, jeśli po hackerone.com wpisałeś /zendesk_session, przeglądarka przekierowywała Cię z platformy HackerOne na ich platformę Zendesk bez stron pośredniczących, ponieważ adresy URL zawierające domenę hackerone.com były zaufanymi linkami. (Obecnie HackerOne przekierowuje z https://support.hackerone.com na docs.hackerone.com, no chyba że przesyłasz wniosek o pomoc przez URL /hc/en-us/requests/new.) Niestety jednak każdy mógł utworzyć swoje konto Zendesk i przekazać je do parametru /redirect_to_account?state=. Utworzone konto Zendesk mogło następnie przekierowywać na inną stronę nienależącą do Zendesk bądź HackerOne. Ponieważ Zendesk zezwalał na przekierowania między kontami bez pośredniczących stron, użytkownik mógł zostać wysłany na niezaufaną stronę bez ostrzeżenia. Jako rozwiązanie HackerOne zaczął identyfikować linki zawierające zendesk_session jako zewnętrzne, a tym samym wyświetlać ostrzeżenie po ich kliknięciu.

W celu potwierdzenia tej podatności, haker Mahmoud Jamal stworzył konto na platformie Zendesk z subdomeną http://compayn.zendesk.com. Następnie dodał następujący kod JavaScript do pliku nagłówka, używając edytora motywów Zendesk, który pozwalał administratorom na dostosowywanie wyglądu ich strony:

<script>document.location.href = <<http://evil.com>>;</script>

Używając tego kodu, Jamal instruował przeglądarkę, by odwiedziła http://evil.com. Tag <script> oznacza kod JavaScript, a document odnosi się do całego dokumentu HTML, który Zendesk zwraca jako informację dla strony internetowej. Kropki i nazwy następujące po document są jego właściwościami. Właściwości zawierają informację i wartości, które albo opisują obiekt, albo mogą być manipulowane, by zmienić obiekt. Możesz zatem użyć właściwości location do kontroli strony internetowej, którą Twoja przeglądarka wyświetla i użyć podwłaściwości href (która jest właściwością location) do przekierowania przeglądarki do zdefiniowanej strony. Odwiedzenie następującego linku przekierowywało ofiary do subdomeny Zendesk należącej do Jamala, która zawierała skrypt przekierowujący ich przeglądarki na http://evil.com:

https://hackerone.com/zendesk_session?locale_id=1&return_to=https: //support.hackerone.com/ping/redirect_to_account?state=compayn:/

Ponieważ ten link zawiera domenę hackerone.com, pośrednicząca strona nie wyświetlała się, a użytkownik nie wiedział, że strona, którą odwiedza, jest niebezpieczna. Co ciekawe, Jamal wcześniej zgłosił problem z brakującą stroną pośredniczącą do Zendeska, lecz zgłoszenie zostało zignorowane. Instynktownie nie zaprzestał poszukiwań i w końcu odkrył atak przez  JavaScript, który przekonał HackerOne do wypłacenia nagrody.

Wnioski

Gdy poszukujesz podatności, miej na uwadze fakt, iż zewnętrzne serwisy, których używają strony, otwierają nowe miejsca na poszukiwania. Podatność na stronie HackerOne istniała tylko dzięki ich współpracy z Zendesk-iem.

Dodatkowo, gdy znajdziesz błąd, mogą zdarzyć się przypadki, gdzie Twoje uwagi dotyczące bezpieczeństwa nie będą zrozumiane przez osobę reagującą na Twoje zgłoszenie. Z tego powodu przedyskutujemy zgłoszenia znalezionych błędów w rozdziale 19, który uszczegóławia to, co powinieneś dołączyć do raportu, jak budować współpracę z firmami i wszelkie pozostałe informacje. Jeśli popracujesz nad opisem znalezionej podatności w raporcie, Twoje starania pomogą w płynnym rozwiązaniu.

Oprócz tego pojawią się sytuacje, gdy firmy nie zgodzą się z Tobą. W takich przypadkach kontynuuj poszukiwania, tak jak to zrobił Jamal, i sprawdź, czy możesz udowodnić niebezpieczeństwo, łącząc kilka podatności naraz, by zademonstrować ich wpływ.