Otwarte przekierowanie przy instalacji motywu Shopify
Otwarte przekierowanie przy logowaniu do Shopify
xix
xxi
xxii
xxiii
xxiii
2
3
3
3
HPP po stronie serwera
HPP po stronie klienta
Przyciski do udostępniania na HackerOne
Wnioski
Anulowanie subskrypcji powiadomień na Twitterze
Wnioski
Web Intents Twittera
Wnioski
Podsumowanie
CROSS-SITE
Uwierzytelnianie.
CSRF przez żądanie GET
CSRF przez żądanie POST
Ochrona przed atakami CSRF
Odłączenie Twittera z Shopify.
Zmiana stref użytkowników Instacart.
Przejęcie konta Badoo
CROSS-SITE SCRIPTING
Rodzaje podatności XSS
Hurtownia Shopify
Wnioski
Formatowanie walut w Shopify
Wnioski
Stored XSS w mailu
Wnioski
Wyszukiwarka zdjęć Google
Stored XSS w menedżerze tagów Google
Wnioski
United Airlines XSS
Wnioski
Podsumowanie
8 TEMPLATE INJECTION
Template injection po stronie serwera
Template injection po stronie klienta.
Template injection w Uberze przez AngularJS
Wnioski
Template Injection w Uberze przez Flask i Jinja2
Dynamiczne renderowanie w Rails
Template injection w Smarty
Wnioski
Podsumowanie
Bazy danych
Przeciwdziałanie SQLi
Blind SQLi w Yahoo! Sports
Wnioski
Uber Blind SQLi
SQLi w Drupal
Podsumowanie
Demonstracja zagrożeń podatności SSRF
Wywoływanie żądań GET vs. POST
Wykonywanie “ślepych” SSRF-ów
Atakowanie użytkowników przy użyciu odpowiedzi SSRF
SSRF w ESEA oraz wysyłanie zapytań o metadane AWS .
Wnioski
SSRF wewnętrznego DNS Google
Wnioski
Wewnętrzne skanowanie portów przy użyciu webhooków
Wnioski
Podsumowanie
11 XML EXTERNAL ENTITY
eXtensible Markup Language
Document Type Definition
Zewnętrzny DTD
Wewnętrzny DTD
Encje XML
Jak działają ataki XXE
Dostęp do odczytu w Google
Wnioski
XXE w Facebooku
Wnioski
XXE w Wikiloc
Wnioski
Podsumowanie
ZDALNE WYKONANIE KODU
Wykonywanie poleceń shell
Wykonywanie funkcji
Strategie na eskalację zdalnego wykonania kodu
RCE w bibliotece ImageMagick
Wnioski
Algolia RCE na facebooksearch.algolia.com
Wnioski
RCE przez SSH
Wnioski
Podsumowanie
Przepełnienie bufora
Odczyt poza granicami bufora.
Przepełnienie typu całkowitego w PHP ftp_genlist()
Wnioski
Moduł hotshot w Pythonie
Wnioski
Odczyt poza granicami bufora w Libcurl
Wnioski
Podsumowanie
14
PRZEJĘCIE SUBDOMENY
Jak działają nazwy domen?
Jak działa przejęcie subdomeny?
Przejęcie subdomeny Ubiquiti
Wnioski
Przypisanie Scan.me do Zendesk
Wnioski
Przejęcie subdomeny Shopify Windsor
Wnioski
Przejęcie Snapchata przez Fastly.
Wnioski
Przejęcie Legal Robot
Wnioski
Przejęcie Uber SendGrid
Wnioski
Podsumowanie
15
RACE CONDITION
Kilkukrotne zaakceptowanie zaproszenia do HackerOne
Wnioski
Przekroczenie limitu zaproszeń do Keybase.
Wnioski
Race condition w płatnościach HackerOne
Wnioski
Race condition w Shopify Partners
Wnioski
Podsumowanie
INSECURE
Szukanie prostych IDOR-ów
Szukanie bardziej złożonych IDOR-ów
Eskalacja uprawnień w Binary.com
Wnioski
Tworzenie aplikacji w Moneybird
Wnioski
Kradzież tokena API w Twitter Mopub
Wnioski
Ujawnianie informacji o klientach ACME
Wnioski
Podsumowanie
PODATNOŚCI OAUTH
Przepływ pracy OAuth
Kradzież tokenów OAuth w Slack
Wnioski
Logowanie z domyślnym hasłem
Wnioski
Kradzież tokenów logowania Microsoft
Wnioski
Przechwytywanie tokenów dostępu Facebooka
Wnioski
Podsumowanie
Omijanie uprawnień administratora w Shopify
Wnioski
Omijanie zabezpieczeń konta na Twitterze
Wnioski
Manipulacja wartością Signal w HackerOne
Wnioski
Niepoprawne uprawnienia bucket-u S3 w HackerOne
Wnioski
Omijanie dwuetapowej weryfikacji GitLab
Wnioski
Ujawnienie informacji o kodzie PHP Yahoo!
Wnioski
Głosowanie w Hacktivity
Wnioski
Dostęp do instalacji pamięci podręcznej PornHub
Wnioski
Podsumowanie
Rekonesans
Enumeracja subdomen
Skanowanie portów
Wykonywanie zrzutów ekranu
Odkrywanie zawartości
Historia błędów
Testowanie aplikacji
Zbiór technologii
Mapowanie funkcjonalności
Znajdowanie podatności
Idąc dalej
Automatyzacja swojej pracy
Sprawdzanie aplikacji mobilnych
Identyfikacja nowej funkcjonalności
Śledzenie plików JavaScript
Poznawanie technologii .
Podsumowanie
20
ZGŁASZANIE PODATNOŚCI
Sprawdź zasady programu bug bounty
Dodaj szczegóły; następnie dodaj ich więcej
Sprawdź podatność dwa razy
Twoja reputacja
Szacunek do drugiej strony
Atrakcyjne nagrody
Podsumowanie
Serwery proxy
Enumeracja subdomen
Rekonesans
Zrzuty ekranu
Skanowanie portów
Rozpoznanie aplikacji
Narzędzia do hakowania
Analiza aplikacji mobilnych
Wtyczki do przeglądarki
B
ŹRÓDŁA
Kursy online
Platformy Bug Bounty
Rekomendowane zasoby
Filmy
Rekomendowane blogi
SKOROWIDZ
WST Ę P
Ta książka wprowadzi Cię do obszernego
świata hackingu etycznego lub inaczej procesu odpowiedzialnego odkrywania podatności bezpieczeństwa i zgłaszania ich do właścicieli aplikacji. Kiedy sam zaczyna ł em naukę hakowania, nie tylko chciałem wiedzieć, jakie podatności hakerzy znajdują, ale również, jak to robią.
Szukałem wszędzie informacji, lecz zawsze pozostawałem z tymi samymi pytaniami:
• Jakie podatności hakerzy znajdują w aplikacjach?
• Jak hakerzy uczyli się o tych podatnościach?
• Jak hakerzy zaczynają infiltrację strony?
• Jak wygląda samo hakowanie? Wszystko jest zautomatyzowane, czy może robione ręcznie?
• Jak mogę zacząć hakować i znajdować podatności?
W końcu znalazłem się na HackerOne, platformie bug bounty stworzonej do łączenia hakerów etycznych z firmami, które szukają osób do przetestowania ich aplikacji. HackerOne pozwala hakerom i firmom upubliczniać błędy, które zostały znalezione i naprawione. Czytając te ujawnione zgłoszenia, starałem się zrozumieć, w jaki sposób ludzie znajdują podatności oraz jak je wykorzystują. Często musiałem przeczytać to samo zgłoszenie dwa lub trzy razy, zanim je zrozumiałem. Tak samo jak pozostali początkujący, zdałem sobie sprawę z tego, że mógłbym wynieść o wiele więcej z objaśnień znalezionych podatności, gdyby były napisane prostym językiem.
Na tropie błędów. Przewodnik hakerski jest na to autorską odpowiedzią, która pomoże Ci zrozumieć wiele rodzajów podatności w aplikacjach internetowych. Nauczysz się szukać podatności, zgłaszać je, zarabiać na tym oraz, przy okazji, pisać bezpieczny kod. Książka ta nie omawia jedynie pomyślnych przykładów: znajdziesz w niej również błędy i wyciągnięte wnioski, z których wiele należy do mnie.
Do czasu, gdy skończysz czytanie, postawisz swój pierwszy krok w kierunku zwiększania bezpieczeństwa oraz powinieneś być w stanie zarabiać na tym pieniądze.
Dla kogo jest ta książka?
Ta książka została napisana z myślą o początkujących hakerach. Nie ma znaczenia, czy tworzysz strony internetowe, czy projektujesz je, czy jesteś rodzicem przebywającym w domu, 10-letnim dzieckiem, czy 75-letnim emerytem.
Powiedziawszy to, choć nie jest to warunek konieczny do hakowania, pewne doświadczenie w programowaniu i znajomość z technologiami internetowymi mogą okazać się pomocne. Na przykład nie musisz być programistą internetowym, aby być hakerem, jednak znajomość podstawowego hipertekstowego języka znaczników (HTML), struktury strony internetowej, wyglądu kaskadowych arkuszy stylów (CSS) oraz tego, w jaki sposób JavaScript dynamicznie wchodzi w interakcję z witrynami, pomogą Ci odkrywać podatności i oceniać znaczenie znalezionych błędów.
Umiejętność programowania moż e pomóc, gdy szukasz podatnoś ci dotyczących logiki aplikacji oraz przy domysłach, gdzie programista mógł popełnić błędy. Jeśli potrafisz patrzeć z punktu widzenia programistów, zgadywać, w jaki sposób coś zostało zaimplementowane, bądź czytać ich kod (o ile jest dostępny), będziesz miał większą szansę na powodzenie.
Jeśli chcesz nauczyć się programowania, polecam Ci sprawdzić darmowe kursy na platformach Udacity oraz Coursera. Dodatkowe materiały znajdziesz w załączniku B.
Jak czytać tę książkę?
Każdy rozdział, który omawia określony rodzaj podatności, zbudowany jest w następujący sposób:
1. Opis rodzaju podatności.
2. Przykłady podatności.
3. Podsumowanie wraz z wnioskami.
Każdy przykład podatności zawiera następujące części:
1. Moją ocenę trudności w szukaniu i udowadnianiu tej podatności.
2. Adres URL powiązany z miejscem, w którym dana podatność została znaleziona.
3. Link do oryginalnego zgłoszenia bądź artykułu.
4. Data zgłoszenia podatności.
5. Kwota otrzymana za przesłanie informacji.
6. Przejrzysty opis podatności.
7. Wnioski, które warto zapamiętać
Nie ma potrzeby czytania tej książki od deski do deski. Jeśli znajdziesz konkretny rozdział, którym jesteś zainteresowany, przeczytaj go najpierw. W niektórych przypadkach odnoszę się do pojęć omawianych w poprzednich rozdziałach, jednak robiąc to, staram się odnotować miejsce, w którym zdefiniowałem ten termin, dzięki czemu łatwiej Ci będzie znaleźć odpowiednią sekcję. Podczas hakowania trzymaj tę książkę otwartą
Co znajdziesz w tej książce?
Oto przegląd tego, co znajdziesz w każdym z rozdziałów:
Rozdział 1: Podstawy Bug Bounty wyjaśnia, czym są podatności oraz programy bug bounty, oraz tłumaczy różnice między klientem a serwerem. Omawia również, w jaki sposób działa internet, a w tym żądania HTTP, odpowiedzi i metody, oraz co to znaczy, że HTTP jest bezstanowy.
Rozdział 2: Otwarte przekierowanie omawia ataki, które wykorzystują zaufanie użytkowników do określonej domeny w celu przekierowywania ich do innej.
Rozdział 3: HTTP Parameter Pollution omawia sposób, w jaki hakerzy manipulują żądaniami HTTP, wstrzykując dodatkowe parametry, którym dana witryna ufa, prowadząc w ten sposób do nieoczekiwanych rezultatów.
Rozdział 4: Cross-Site Request Forgery wyjaśnia sposób, w jaki atakujący może wykorzystać złośliwą stronę, aby przeglądarka ofiary wykonała żądanie HTTP do innej strony. Strona, która otrzymuje żądanie, postępuje tak, jakby żądanie zostało wysłane umyślnie przez ofiarę.
Rozdział 5: HTML Injection i fałszowanie treści tłumaczy, w jaki sposób złośliwy użytkownik może wstrzykiwać własne elementy HTML na docelowe strony internetowe.
Rozdział 6: Carriage Return Line Feed Injection pokazuje, jak atakujący wstrzykują zakodowane znaki do wiadomości HTTP, aby zmienić to, w jaki sposób interpretują je serwery, proxy i przeglądarki.
Rozdział 7: Cross-Site Scripting wyjaśnia, w jaki sposób atakują cy wykorzystują strony, które nie filtrują danych wejściowych użytkownika, w celu wykonywania na nich własnego kodu JavaScript.
Rozdział 8: Template Injection pokazuje, jak atakujący wykorzystują template engine’y w przypadku, gdy strona nie filtruje odpowiednio wejścia użytkownika i używa ich w swoich szablonach. Rozdział pokrywa zarówno przypadki po stronie klienta, jak i serwera.
Rozdział 9: SQL Injection opisuje, jak podatność po stronie aplikacji (serwera) może pozwolić atakującemu na zaatakowanie bazy danych.
Rozdział 10: Server-Side Request Forgery wyjaśnia, w jaki sposób atakujący sprawiają, że serwer wykonuje niezamierzone żądania.
Rozdział 11: XML External Entity pokazuje, jak atakujący wykorzystują sposób, w jaki aplikacja parsuje dane wejściowe XML i przetwarza w nich zewnętrzne encje.
Rozdział 12: Zdalne wykonanie kodu dotyczy wykorzystywania serwera bądź aplikacji do uruchomienia na nich własnego kodu.
Rozdzia ł 13: Podatno ś ci w manualnej obs ł udze pami ę ci omawia sposoby, w jakie hakerzy wykorzystują zarządzanie pamięcią aplikacji do powodowania niezamierzonych działań, włączając w to możliwość wykonywania własnych poleceń.
Rozdział 14: Przejęcie subdomeny pokazuje, w jaki sposób atakujący może przejąć kontrolę nad subdomeną w imieniu uprawnionej domeny.
Rozdział 15: Race Condition wyjaśnia, jak atakujący wykorzystują sytuacje, w których zmiana warunku początkowego danego procesu ma wpływ na jego końcowy wynik.
Rozdzia ł 16: Insecure Direct Object Reference omawia wszelkie podatności pojawiające się, gdy atakujący ma dostęp do odniesienia do obiektu, do którego nie powinien mieć dostępu, na przykład pliku, rekordu w bazie danych bądź konta.
Rozdział 17: Podatności OAuth pokazuje błędy w implementacji protokołu stworzonego do uproszczenia i ustandaryzowania bezpiecznego uwierzytelniania w aplikacjach internetowych, mobilnych i desktopowych.
Rozdział 18: Podatności w logice i konfiguracji aplikacji wyjaśnia, w jaki sposób atakujący mogą wykorzystać wadliwą logikę w kodzie lub błąd w konfiguracji do wykonania niezamierzonych działań.
Rozdział 19: Poszukiwanie podatności na własną rękę dostarcza wskazówki, gdzie i jak szukać podatności, bazując na moich doświadczeniach i metodologii. Ten rozdział nie jest jednak poradnikiem krok po kroku do włamywania się na stronę.
Rozdział 20: Zgłaszanie podatności omawia, w jaki sposób pisać wiarygodne i informacyjne zgłoszenia podatności, dzięki czemu programy nie odrzucą twoich raportów.
Załącznik A: Narzędzia omawia popularne narzędzia stworzone do hakowania, włączając w to przechwytywanie ruchu sieciowego, enumerację subdomen, wykonywanie zrzutów ekranu i wiele więcej.
Załącznik B: Źródła stanowi listę dodatkowych materiałów do dalszego rozwoju w dziedzinie hackingu. Znajdziesz tu między innymi ćwiczenia online, popularne platformy bug bounty i polecane blogi.
Zastrzeżenie dotyczące hakowania
Patrząc na upublicznione zgłoszenia podatności, a dokładniej na kwoty pieniędzy, które hakerzy za nie otrzymują, naturalnie może się wydawać, że hacking to łatwa i szybka droga do wzbogacenia się. Tak jednak nie jest.
Poszukiwanie błędów potrafi być satysfakcjonujące, jednak mało prawdopodobne jest, że napotkasz wiele historii o porażkach, które zdarzają się po drodze (z wyjątkiem tej książki, gdzie dzielę się kilkoma naprawę kompromitującymi opowieściami). Ponieważ będziesz głównie słyszał o sukcesach hakerów, możesz rozwinąć nierealistyczne oczekiwania wobec swojej hakerskiej przygody.
Sukces może przyjść do Ciebie bardzo szybko. Jednak jeśli masz problemy ze znajdowaniem błędów, nie przestawaj się zagłębiać. Programiści zawsze będą pisać nowy kod, a błędy stanowią nieuniknioną część tego procesu. Im bardziej się starasz, tym więcej błędów będziesz znajdował. W tej sprawie możesz śmiało do mnie napisać na Twitterze @yaworsk i dać znać, jak sobie radzisz. Nawet jeśli nie odnosisz sukcesów, chciałbym to od Ciebie usłyszeć. Bug hunting potrafi być samotną pracą, szczególnie jeśli sprawia Ci trudności. Jednak wspaniale jest też wspólnie świętować, a może nawet znajdziesz coś, co będę mógł zamieścić w następnym wydaniu tej książki.
Powodzenia i szczęśliwego hakowania.
Wappalyzer b d BuiltWith, lub przegl daj c ród o strony i szukaj c atrybutów ng-. Jak ju wspomnia em, starsze wersje AngularJS implementowa y Sandboxa, lecz wersja, której u ywa Uber, by a podatna na ucieczk . W tym przypadku zatem podatno CSTI oznacza a mo liwo wykonania XSS. U ywaj c poni szego JavaScriptu w adresie URL, Kettle dokona ucieczki z Sandboxa AngularJS i uruchomi funkcj alert:
Dekonstrukcja tego payloadu wychodzi poza zakres tej ksi ki, bior c pod uwag publikacje licznych obej Sandboxa AngularJS oraz usuni cia ich w wersji 1.6. W ka dym b d razie ko cowym rezultatem payloadu alert jest okno pop-up. Ten dowód pokaza Uberowi, e atakuj cy móg wykorzysta t podatno CSTI do wykonania XSS-a, co mog o skutkowa zagro eniem kont deweloperów i powi zanych aplikacji.
Wnioski
Po ustaleniu, czy witryna korzysta z template engine’a po stronie klienta, rozpocznij testy od przes ania prostych adunków, korzystaj c ze standardowej sk adni dla danego engine’a, takiej jak {{7*7}} dla AngularJS, i sprawdzania renderowanych rezultatów. Je li adunek zosta wykonany, sprawd wersj AngularJS, której strona u ywa, wpisuj c Angular.version w przegldarkowej konsoli dla deweloperów. Je li wersja jest wy sza ni 1.6, mo esz przes a payload z wy ej wymienionych róde bez omijania Sandboxa. Je li jest ni sza ni 1.6, b dziesz musia znale obej cie dostosowane do wersji AngularJS, której aplikacja u ywa.
Template Injection w Uberze przez Flask i Jinja2
Poziom trudno ci: redni
URL: https://riders.uber.com/
ród o: https://hackerone.com/reports/125980/
Data zg oszenia: 25 marca 2016
Nagroda: 10 000 $
Podczas hakowania wa na jest identy kacja technologii u ywanej przez dan rm . Kiedy Uber uruchomi swój publiczny program bug bounty na portalu HackerOne, do czy do niego „map skarbów” pod adresem https://eng.uber.com/bug-bounty/ (ulepszona wersja mapy zosta a opublikowana w sierpniu 2017 roku na stronie https://medium.com/uber-security-privacy/
uber-bug-bounty-treasure-map-17192af85c1a/). Mapa zidenty kowa a szereg wra liwych funkcjonalno ci obs ugiwanych przez Ubera, do czaj c do tego oprogramowanie, którego u ywa a ka da z nich.
Na tej mapie Uber ujawni , e witryna riders.uber.com zosta a zbudowana przy u yciu Node.js Express i Backbone.js, z których adne nie wyró nia si jako potencjalne zagro enie atakiem SSTI. Jednak strony vault.uber.com i partners.uber.com zosta y napisane przy u yciu Flask oraz Jinja2. Jinja2 to template engine, który w przypadku niepoprawnej kon guracji pozwala na zdalne wykonanie kodu. Mimo e witryna riders.uber.com nie u ywa a Jinja2, je li dostarcza a dane wej ciowe do subdomeny valut b d partners, a te strony ufa y wej ciu, które otrzymuj , atakuj cy móg by w stanie wykona atak SSTI.
Orange Tsai, haker, który odkry t podatno , w celu rozpocz cia testów na podatno SSTI wpisa {{1+1}} jako swoj nazw . Szuka jakiejkolwiek interakcji, która odbywa a si mi dzy subdomenami.
W swoim artykule Orange wyja nia, e jakakolwiek zmiana w pro lu na riders.uber.com skutkowa a wiadomo ci e-mail z powiadomieniem dla w a ciciela pro lu o zmianach (jest to cz sta praktyka bezpiecze stwa). Zmieniaj c swoj nazw na {{1+1}}, otrzyma wiadomo z 2 w swojej nazwie, tak jak pokazuje to rysunek 8.1.
Rysunek 8.1. E-mail, który otrzyma Orange, wykonywa kod wstrzykni ty do nazwy pro lu
Widz c to zachowanie, hakerowi od razu za wieci a si czerwona lampka, poniewa Uber obliczy jego wyra enie i umie ci wynik jako nazw prolu. Orange nast pnie próbowa przes a kod w Pythonie {% for c in [1,2,3]%} {{c,c,c}} {% endfor %} w celu sprawdzenia dzia ania odkrytej podatno ci na bardziej z o onych operacjach. Ten kod iteruje przez tablic [1,2,3] i wypisuje ka dy numer trzy razy. E-mail na rysunku 8.2 pokazuje nazw Orange’a wy wietlan w postaci dziewi ciu cyfr, które s rezultatem wykonania p tli for, potwierdzaj c tym samym jego odkrycie. Jinja2 równie implementuje Sandboxa, co ogranicza mo liwo wykonywania dostarczonego kodu, lecz w niektórych sytuacjach mo na go omin . W tym przypadku Orange by w stanie to zrobi od razu.
SERVER-SIDE REQUES T FORGERY
Podatność typu Server-Side Request Forgery (SSRF) pozwala atakującemu na manipulację żądaniami serwera. Podobnie jak podatno ść cross-site request forgery (CSRF), SSRF nadu ż ywa innego systemu, aby wykona ć niezamierzone akcje. Podczas gdy CSRF wykorzystuje innego u ż ytkownika, SSRF wykorzystuje serwer docelowej aplikacji. Tak samo jak CSRF, podatności SSRF mogą by ć ró ż ne w skutkach i sposobach wykonania. Sam jednak fakt, że możesz wysyłać żądania z docelowego serwera do innych serwerów, nie oznacza, ż e aplikacja jest podatna. Aplikacje mogą umyślnie zezwalać na takie zachowanie. Z tego powodu ważne jest, aby zademonstrować możliwości wykorzystania, które otwiera znaleziony SSRF.
Demonstracja zagrożeń podatności SSRF
W zależności od tego, w jaki sposób witryna jest zorganizowana, serwer podatny na SSRF może wykonywać żądania HTTP do wewnętrznej sieci albo na zewnętrzny adres. Zdolność podatnego serwera do wykonywania żądań decyduje o tym, co można zrobić ze znalezionym SSRF-em.
Niektóre wi ę ksze strony internetowe maj ą zapory, które blokuj ą zewnętrzny ruch przed dostępem do wewnętrznych serwerów: na przykład witryna ma ograniczoną liczbę publicznych serwerów, które przyjmują żądania HTTP od odwiedzających. Następnie wysyłają otrzymane żądania na pozostałe serwery, które są już poza dostępem publicznym. Częstym przykładem jest serwer z bazą danych, będący zazwyczaj niedostępny dla internetu. Kiedy logujesz się na stronę, która komunikuje się z serwerem bazy danych, przesyłasz nazwę użytkownika i hasło przez standardowy formularz internetowy. Następnie witryna, która otrzyma Twoje żądanie, wykonuje swoje własne żądanie do serwera z bazą danych przy użyciu podanych przez Ciebie danych. Potem serwer z bazą danych wyśle odpowiedź do serwera aplikacji, a ten przekaże informacje do Ciebie. Podczas tego procesu często nie zdajesz sobie sprawy z tego, że zewnętrzny serwer bazy danych w ogóle istnieje. Podatne serwery, które pozwalają atakującemu kontrolować żądania do wewnętrznych serwerów, mogą doprowadzić do ujawnienia prywatnych informacji. Na przykład, jeżeli w poprzednim przykładzie istniałby SSRF, to móg ł by on pozwoli ć atakuj ą cemu przesy ł a ć żą dania do serwera bazy danych i uzyskać informacje, do których nie powinien mieć dostępu. Podatności SSRF dostarczają atakującym możliwość komunikacji z wewnętrzną siecią.
Załóżmy, że znalazłeś SSRF, jednak podatna strona nie ma wewnętrznych serwerów lub serwery te nie są dostępne przez podatność. W takim przypadku sprawdź, czy możesz wykonywać żądania do zewnętrznych stron z podatnego serwera. Jeżeli uda Ci się wykorzystać docelowy serwer tak, aby komunikował się z twoim własnym serwerem, możesz użyć żądanych informacji, aby poznać szczegóły oprogramowania, z którego korzysta docelowa aplikacja. Być może będziesz też w stanie kontrolować odpowiedź Na przyk ł ad mo ż liwe jest konwertowanie zewn ę trznych żą da ń na wewnętrzne, pod warunkiem, że podatny serwer śledzi przekierowania –trik, który pokazał mi Justin Kennedy. W niektórych przypadkach strona nie pozwoli na dostęp do wewnętrznych adresów IP, ale nawiąże połączenie z zewnętrznymi witrynami. Jeśli tak będzie, możesz zwrócić odpowiedź HTTP z kodem 301, 302, 303 lub 307, które oznaczają przekierowanie. Ponieważ masz kontrolę nad odpowiedziami, możesz skierować serwer na wewnętrzny adres IP, aby przetestować, czy prześledzi on odpowiedź 301 i wykona żądanie HTTP do wewnętrznej sieci.
Alternatywą jest użycie odpowiedzi z własnego serwera, aby sprawdzić obecność innych podatności, takich jak SQLi albo XXS, tak jak zostało to
Niektórzy b ęd ą importowa ć jedn ą , a niektórzy tysią c. W j ę zykach bez zarządzania pamięcią musisz sprawdzić liczbę importowanych transakcji, a następnie przydzielić im odpowiednią ilość pamięci. W przypadku gdy programista nie bierze pod uwagę tego, ile pamięci potrzebuje aplikacja, pojawiają się takie błędy, jak przepełnienie bufora.
Szukanie i exploitowanie podatności pamięci jest na tyle skomplikowane, że na sam ten temat zostały napisane całe książki. Z tego powodu ten rozdział jest jedynie wstępem do tematu omawiającym tylko dwa z wielu innych rodzajów podatności pamięci: przepełnienie bufora oraz odczyt poza granicami bufora. Jeśli jesteś zainteresowany dalszym zgłębianiem wiedzy w tym zakresie, polecam przeczytać Hacking: The Art of Exploitation autorstwa
Jona Ericksona bądź A Bug Hunter’s Diary: A Guided Tour Through the Wilds of Software Security napisaną przez Tobiasa Kleina.
Przepełnienie bufora
Przepełnienie bufora następuje tam, gdzie aplikacja zapisuje dane, których jest zbyt wiele dla przypisanej im pamięci. Przepełnienie bufora prowadzi w najlepszym przypadku do nieprzewidywalnego zachowania aplikacji, a w najgorszym do poważnej podatności bezpieczeństwa. Kiedy atakujący może kontrolować przepełnienie w celu wykonania własnego kodu, jest on w stanie narazić aplikację bądź nawet, zależnie od uprawnień użytkownika, cały serwer. Ten typ podatności jest podobny do przykładów RCE z rozdziału 12. Przepełnienie bufora najczęściej pojawia się wtedy, gdy programista zapomni sprawdzić wielkość zapisywanych danych do zmiennej. Zdarzają się również pomyłki w obliczeniach co do ilości pamięci, jakiej wymagają dane. Ponieważ tego rodzaju błędy zdarzają się na wiele sposobów, zbadamy tylko jeden typ – pominięcie kontroli długości. W języku C pominięcie kontroli długości zazwyczaj wiąże się z użyciem funkcji, które modyfikują pamięć, takich jak strcpy() i memcpy(). Ten typ błędu może pojawić się również tam, gdzie programiści używają funkcji alokacji pamięci, takich jak malloc() lub calloc(). Funkcja strcpy() (oraz memcpy()) przyjmuje dwa parametry: bufor, do którego mają zostać skopiowane dane, oraz dane do skopiowania. Oto przykład w języku C:
#include <string.h> int main()
{
char src[16]="hello world";
char dest[16];
strcpy(dest, src);
printf("src is %s\n", src); printf("dest is %s\n", dest); return 0; }
W tym przykładzie scr przyjmuje ciąg "hello world" , który ma 11 znaków długości, wliczając w to spację. Ten kod przydziela 16 bajtów dla src oraz dest (każdy znak zajmuje 1 bajt). Ponieważ każdy znak wymaga 1 bajta pamięci, a ciąg znaków musi się kończyć znakiem null (\0), ciąg "hello world" wymaga w sumie 12 bajtów, co oczywiście mieści się w granicach przydzielonych 16 bajtów. Funkcja strcpy() kopiuje ciąg z src do dest . Sformułowania printf w wyświetlają poniższy tekst:
src is hello world dest is hello world
Powyższy kod działa tak, jakbyśmy tego oczekiwali. Co jeśli jednak ktoś chciałby wyraźnie zaakcentować to powitanie? Rozważmy następujący przykład:
Mamy tutaj pięć dodatkowych wykrzykników, co zwiększa sumę znaków w ciągu do 16. Programista pamiętał, że wszystkie ciągi w języku C muszą być zakończone znakiem null (\0). Przydzielił 17 bajtów do src , jednakże zapomniał zrobić to samo dla dest . Po skompilowaniu i uruchomieniu programu oczom programisty ukazuje się następujące wyjście: src is dest is hello world!!!!!
Zmienna src jest pusta mimo przypisania do niej 'hello world!!!!!'. Dzieje się to z powodu tego, w jaki sposób C alokuje pamięć na stosie. Adresy pamięci na stosie są przydzielane rosnąco, tak więc zmienna zdefiniowana w programie wcześniej będzie mieć niższy adres pamięci od tej zdefiniowanej później. W tym przypadku src jest dodany do stosu pierwszy, a dopiero za nim dest. Kiedy następuje przepełnienie, 17 znaków dla 'hello world!!!!!!' zostaje zapisane w zmiennej dest, jednak znak null (\0) zostaje wypchnięty do pierwszego znaku zmiennej src. Ponieważ znaki null oznaczają koniec ciągu, src ukazuje się jako pusty.
