Na tropie błędów. Przewodnik hakerski. Peter Yaworski

Чтение книги онлайн.

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

      Data zgłoszenia: 6 grudnia 2015

      Nagroda: 500 $

      Drugi przykład otwartego przekierowania jest podobny do pierwszego, z wyjątkiem tego, że zamiast parametru URL docelową domenę określa wartość parametru na końcu subdomeny Shopify. Normalnie ta funkcjonalność byłaby używana do odsyłania użytkownika na określoną stronę w obrębie jednego sklepu. Jednakże atakujący wciąż mogą manipulować tymi adresami, aby przekierować przeglądarkę z dala od subdomeny Shopify, na witrynę atakującego przez dodanie znaków, które zmienią znaczenie URL.

      W przypadku tego błędu, po zalogowaniu do Shopify, serwis używał parametru checkout_url do przekierowania użytkownika. Dla zobrazowania powiedzmy, że ofiara odwiedza następujący adres:

      Zostałaby przekierowana na URL http://mystore.myshopify.com.<attacker>.com/, który nie jest domeną Shopify.

      Ponieważ URL kończy się .<attacker>.com, a wyszukiwarki DNS używają nazwy domeny wysuniętej najdalej na prawo w adresie, przekierowanie zostaje wykonane na domenę <attacker>.com. Zatem gdy http://mystore.myshopify.com.<attacker>.com/ zostaje wysłany do wyszukiwarki DNS, zostanie dopasowany do <attacker>.com, którego Shopify nie ma, a nie myshopify.com, tak jak Shopify miał w zamiarze. Mimo że atakujący nie byłby w stanie wysłać ofiary na dowolną stronę, mógłby go wysłać na inną domenę przez dodanie specjalnych znaków, takich jak kropka, do wartości, którymi może manipulować.

      Wnioski

      Jeśli tylko możesz kontrolować końcowy fragment adresu URL używanego przez stronę, dodanie specjalnych znaków URL może zmienić znaczenie danego adresu i przekierować użytkownika na inną domenę. Powiedzmy, że możesz kontrolować jedynie wartość parametru checkout_url oraz zauważysz, że parametr jest dodawany do gotowego adresu URL, takiego jak  http://mystore.myshopify.com/. Spróbuj dodawać specjalne znaki URL, takie  jak kropka lub @, w celu przetestowania możliwości kontroli lokalizacji przekierowania.

      Przekierowanie pośrednie na HackerOne

      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:

      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:

      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ę СКАЧАТЬ