Wprowadzenie
Cześć!
Ja jestem Kacper Szurek a to 39 odcinek podcastu o bezpieczeństwie.
W tym tygodniu:
Jak zmiana daty urodzenia na Twitterze, może sprawić nie lada kłopoty.
Dlaczego nie warto używać wyrażeń regularnych do sprawdzania poprawności domeny.
Shodan monitor - czyli ostatni bastion bezpieczeństwa naszych serwerów.
Dystrybucja Windowsa dla pentesterów? Parę słów na temat commando VM.
Jak testować bezpieczeństwo sklepów internetowych. Szybkie i proste metody do sprawdzenia.
Co to jest credential stuffing i jak się przed nim obronić.
A także o ekosystemie rozszerzeń do WordPressa.
Podcast ten można również znaleźć na Spotify oraz Google i Apple Podcasts oraz Anchor.
Jeżeli ten materiał Ci się spodobał rozważ zostawienie gwiazdki i recenzji w aplikacji Apple Podcasty.
Więcej informacji na temat bezpieczeństwa znajdziesz na naszej grupie od 0 do pentestera na Facebooku.
Zapraszam do słuchania.
Podszywanie się pod znane osoby na Twitterze
Jakiś czas temu opowiadałem o scamie na Twitterze, gdzie podszywano się pod konto Elona Muska.
Wtedy to obiecywano przesłanie bitcoinów w zamian za dokonanie weryfikacji - czyli jeżeli wyślemy nasze własne kryptowaluty, otrzymamy inne - od kogoś.
Ale nie o pieniądzach tym razem, a o żarcie powiązanym z datą urodzenia.
Obecnie modne jest wprowadzanie nowych schematów kolorystycznych w różnego rodzaju produktach.
I właśnie to zostało wykorzystane przez dowcipnisiów na Twitterze.
Masowo zaczęły się pojawiać obrazki sugerujące, iż zmiana roku naszego urodzenia w ustawieniach tej platformy sprawi, że naszym oczom ukaże się nowa, ukryta kolorystyka.
Rzeczywistość jest zgoła inna.
Ten rok urodzenia sprawi bowiem, że Twitter potraktuje nas jako użytkownika mającego 12 lat.
A jak głosi regulamin serwisu - nie jest możliwe korzystanie z niego, jeżeli nie mamy co najmniej 13 lat.
To sprawia, że zmieniając datę urodzenia - sami nakładamy na siebie automatyczną blokadę konta.
Czyli - nie możemy z niego korzystać, aż do momentu skontaktowania się z pomocą techniczną i odkręcenia całego zamieszania.
Tym razem jest to tylko nieszkodliwy żart i nauczka - aby nie wierzyć wszystkiemu, co zobaczymy w Internecie.
Co ciekawe, ostatnimi czasy Twitter udostępnił czarną kolorystkę swojej strony - z punktu widzenia socjotechniki był to więc idealny moment na wymyślenie takiego żartu.
Bez większego zastanowienia bowiem - jeżeli udostępnili nowy kolor, może przygotowali również ukrytą kolorystykę.
Zwłaszcza, że wszystko działo się w okolicy 1 kwietnia czyli w Prima Aprilis, kiedy to w Internecie ciężko rozróżnić prawdę od fałszu.
Z punktu nauki - fajnie było by również zobaczyć jaki procent użytkowników nabrał się na tą wiadomość.
Ciekawe - co by się stało, gdyby zamiast zmiany daty urodzenia sugerowano usunięcie konta.
Czy wtedy taki pseudo żart odniósłby równie wielki sukces?
Dlaczego nie warto używać wyrażeń regularnych
Pozostając na Twitterze.
Jedna z firm opublikowała zdjęcie, na którym widniał kawałek kodu - wraz z dopiskiem - czy potrafisz dostrzec błąd?
W kodzie tym mieliśmy do czynienia z wyrażeniem regularnym, które sprawdzało poprawność domeny.
Jeżeli test dawał pozytywny wynik - parametr od użytkownika był wykorzystywany do przekierowania go pod podany w taki sposób adres.
Mamy tu zatem idealny przykład zabezpieczenia przed atakiem typu open redirection - kiedy to serwis posiada funkcjonalność pozwalającą na przekierowanie użytkownika pod inną domenę.
Takie opcje powinny być odpowiednio zabezpieczane, aby przestępcy nie mogli użyć naszego serwisu do przekierowywania użytkowników pod złośliwe adresy URL.
Zazwyczaj więc sprawdza się domenę, pod którą ma zostać przekierowany użytkownik i pozwala się na użycie tylko określonej listy adresów - którym ufamy albo które kontrolujemy.
Jedną z opcji implementacji takiego rozwiązania jest wykorzystanie wyrażeń regularnych.
I właśnie z takim kawałkiem kodu mamy tutaj do czynienia.
Po krótce opiszę co znajduje się w tym wyrażeniu.
Całość - zaczyna się od symbolu Karety - czyli znaku nazywanego czasami daszkiem albo dzióbkiem.
Oznacza on, że podany przez użytkownika ciąg musi się zaczynać od danego wyrażenia.
Dalej sprawdza się, czy parametr zaczyna się od ciągu https. Następnie musi zostać podany wyraz składający się z co najmniej jednej litery lub cyfry.
Całość musi być zakończona ciągiem security.com
Jest to więc standardowy mechanizm, który umożliwia przekierowywanie jedynie do subdomen w domenie security.com.
Na pozór wszystko wydaje się w porządku.
Problem jest jak zwykle w detalach.
W wyrażeniach regularnych bowiem - kropka oznacza dowolny jeden znak.
Aby kropka była kropką - musi być poprzedzona znakiem backslash.
Tutaj natomiast mamy do czynienia z ciągiem security [kropka] com
Zamiast więc kropki możemy podać cokolwiek.
Teoretycznie - błąd ten dalej nie jest możliwy do wykorzystania.
Owszem, możemy przekierować kogoś pod cokolwiek security dowolna_litera com - ale nie jest to prawidłowa domena, którą można zakupić.
Ale - ostatnimi czasy, pojawia się sporo nowych, różnych nazw domenowych.
Mamy zatem domenę dev, live, club, czy też app.
Mamy też domenę security.
To sprawia, że błąd - staje się możliwy do wykorzystania.
Możemy więc zakupić dowolną nazwę w stylu: to-jest-moja-nazwa.security
Dalej wyrażenie regularne oczekuje na kropkę - czyli dowolny, jeden znak.
Tym znakiem może być zatem slash - który to oddziela nazwy katalogów w adresie URL.
Tym samym dowolnanazwa.security/com jest prawidłowym adresem, pasującym do tego wyrażenia.
W tym wypadku /com oznacza katalog com w obrębie domeny dowolnanazwa a nie domenę z końcówką com.
Jedna kropka - a tyle zamieszania.
Co to jest credential stuffing?
Z roku na rok mamy do czynienia z coraz większa ilością wycieków.
To sprawia że credential stuffing będzie coraz popularniejszy.
Ale co oznacza ten termin?
Mamy z nim do czynienia, kiedy to loginy i hasła uzyskane z wycieków są używane do próby zalogowania się do naszego serwisu.
Wykorzystuje się zatem tutaj istniejące pary wartości login-hasło, które używane były na jakiejś stronie internetowej.
Ponieważ część użytkowników używa tych samych danych w różnych witrynach - istnieje prawdopodobieństwo, że te same wartości mogą zadziałać w wielu różnych miejscach.
Trzeba tutaj nadmienić, iż termin ten jest inny od ataków brute force.
Tam bowiem atakujący próbuje zgadnąć hasło danego użytkownika próbując wszystkich prawdopodobnych kombinacji.
Tutaj nie testuje wszystkich kombinacji a jedynie te, które istniały wcześniej w wycieku.
Jak zatem ochronić się przed takimi atakami?
Metodologia jest tutaj podobna jak w przypadku ataków siłowych.
Warto zacząć od podstawowych metod, czyli wprowadzenia captchy po kilkukrotnych błędnych próbach zalogowania.
Takie przepisanie tekstu z losowo generowanego obrazka może znacząco spowolnić cały proceder.
Ale to nie wszystko.
Inną opcją jest sprawdzanie z jakiej puli adresowej pochodzi IP klienta, łączącego się z naszą stroną.
Obecnie, dostępnych jest wielu usługodawców usług chmurowych.
DigitalOcean, Amazon czy też OVH.
Jeżeli adres IP należy do ich puli, istnieje spore prawdopodobieństwo - że nie mamy do czynienia z realnym użytkownikiem - a z robotem.
Tą samą informację możemy uzyskać chociażby z nagłówków User Agent.
Jeżeli atakujący jest zbyt leniwy, to nie zmieni standardowych nagłówków używanych przez dane narzędzia.
Podstawowe żądania HTTP można bowiem przesyłać wykorzystując chociażby komendę curl - która pozwala na przekazywanie parametrów POST pod podany adres URL.
Standardowo, narzędzie to w nagłówku User-Agent przesyła tekst curl wraz z numerem wersji.
Owszem, może to być łatwo zmienione przy pomocy odpowiedniego przełącznika - wszystko zależy z jak zaawansowanym atakującym mamy do czynienia.
Bardziej doświadczeni atakujący mogą bowiem symulować zwykłego użytkownika korzystając z trybu headless mode w Google Chrome.
Mówiąc w prostych słowach - pozwala on na wykorzystanie funkcji przeglądarki bez wyświetlania interfejsu graficznego.
Może więc być w prosty sposób wykorzystywany do automatyzacji niektórych procesów.
Ale i na rozpoznawanie tego trybu są metody.
Warto zainteresować się zmienną navigator.webdriver dostępną z poziomu kodu JavaScript.
Inną opcją jest wykorzystywanie funkcji odpowiedzialnych za fingerprinting.
Tutaj próbujemy rozpoznać czy dany użytkownik jest tą samą osobą na podstawie wielu drobnych artefaktów.
Począwszy od adresu IP czy też języka przeglądarki a skończywszy na zainstalowanych czcionkach czy też zainstalowanej karcie graficznej.
Jak jeść w restauracjach za darmo?
Jak jeść w najlepszych nowojorskich restauracja za darmo przy użyciu kilku skryptów, sztucznej inteligencji, Instagrama i odrobiony cierpliwości?
Teraz o historii pewnego człowieka, który opisuje jak, wykorzystując profil na Instagramie, udało mu się żywić w dużym mieście.
Historia momentami brzmi niewiarygodnie - zwłaszcza, iż najlepsze restauracje podobnych zapytań otrzymują zapewne tysiące.
Niemniej jednak warto posłuchać jak można zautomatyzować niektóre czynności sprawiając, iż nagle możemy stać się właścicielami popularnego konta na serwisie społecznościowym.
Idea całego rozwiązania jest prosta.
Jeżeli jesteś właścicielem popularnego profilu ze sporą oglądalnością - recenzja restauracji w ramach Twojego profilu może przynieść restauracji pewne korzyści finansowe.
Stąd też, darmowy posiłek może być małą kwotą w zamian za takową recenzję.
I rzeczywiście - taki model biznesowy zapewne sprawdza się w przypadku kulinarnych blogerów i vlogerów.
Ale co w przypadku, gdy jesteś programistą, którego zżycie nie jest tak ciekawe i nie opiera się na ciągłych podróżach i lifestyle’u?
Jeżeli nie jesteś fotografem - nie posiadasz zdjęć, które mogłyby zachęcić Twoją widownię do dawania lajków i subskrybowania profilu.
Ale kto powiedział, że publikowane zdjęcia muszą być Twoje?
Przecież możesz użyć czyjejś pracy - wystarczy tylko, że ją odpowiednio podpiszesz i podlinkujesz do oryginalnego autora fotografii.
I tu dochodzimy do szczegółów implementacyjnych całego rozwiązania.
Na początku, autor ręcznie przygotował listę kont na Instagramie, które wrzucały zdjęcia Nowego Jorku.
Następnie przygotował skrypt, który korzystając z tej listy pobierał nowe fotografie, które mogłyby być używane na jego własnym profilu.
Dodatkowo - dopisał opcję wykrywania reklam na tych zdjęciach.
Nie wszystkie zdjęcia bowiem to zdjęcia budynków czy też krajobrazów - czasami były to po prostu reklamy jakichś produktów.
Przy użyciu sztucznej inteligencji możliwe jest jednak wyeliminowanie tego rodzaju wpisów.
Zazwyczaj mają one mniejszą liczbę interakcji, mogą też mieć wyłączoną możliwość komentowania.
W opisach znajdują się słowa kluczowe „Kup teraz” lub też link do produktu poniżej.
Nie każde zdjęcie nadaje się jednak na nasz profil.
Nam chodzi o jak największą ilość interakcji.
Jeżeli coś działało w przeszłości - istnieje spora szansa że zadziała również teraz.
Łącząc te wszystkie informacje ze sobą - uzyskujemy automat.
Zbiera on najpierw zdjęcia z innych profili, wybiera te pasujące a następnie automatycznie je publikuje.
Co więcej, automat sam wybiera restauracje z terenu miasta i wysyła do nich informacje, z prośbą o darmowy lunch.
Automatycznie dodaje do obserwowanych profile innych osób - z myślą iż te, w odpowiedzi odwdzięczą się tym samym.
Równocześnie, po dwóch dniach usuwa je z obserwowanych - i powtarza całą operację dla nowych kont.
W ten sposób - profil rośnie w siłę.
A im większe liczby tym większe możliwości.
Całość wydaje się zbyt piękna, aby była możliwa.
Pytanie bowiem czy Instagram nie blokuje takich interakcji traktując je jako potencjalnie złośliwe?
Jeżeli nie, może rzeczywiście ilość zapytań i automatyzacja pracy sprawiają, iż opisana metoda działa?
Kto wie.
Ataki na konkurencje przy użyciu WordPress-a
WordPress to najpopularniejszy system blogowy na świecie.
Myślę, że ta popularność wzięła się głownie z prostoty i możliwości szybkiego rozszerzania jego możliwości i wyglądu.
Wystarczy jedynie ściągnąć odpowiednie rozszerzenie i skopiować je do katalogu na naszym serwerze.
I już - właśnie doinstalowaliśmy nową funkcję, która praktycznie od razu zaczyna działać i wykonywać nasze komendy.
Te dodatki tworzone są przez zewnętrznych użytkowników.
Praktycznie każdy może stworzyć swój kod i umieścić go w repozytorium.
To sprawia, że jakość różnych rozwiązań bywa dyskusyjna.
Potwierdzają to liczby - jeżeli spojrzymy na ilość błędów bezpieczeństwa w dodatkach względem samego silnika - widzimy jak duże są dysproporcje.
Ale ta cała popularność sprawiła, że na rynku pojawiło się sporo firm, które z tworzenia rozszerzeń i motywów stworzyło biznes.
Tylko, że zarabianie na tym prawdziwych pieniędzy nie jest takie proste - z racji dużego współzawodnictwa.
Ostatnio wykryto interesujący przypadek w kodzie dołączanym do jednego z motywów, który można było zakupić na jednej z platform sprzedażowych.
Podczas analizy kodu wykryto wiele ciekawych, dodatkowych funkcji.
Ich ocenę pozostawiam Tobie, drogi słuchaczu.
Pierwsza z nich pobierała treść pliku z serwerów producenta motywu, a następnie wykonywała połączenie do serwera, którego nazwa znajdowała się w tym pliku.
Kod ten wykonywał się co godzinę.
Jest to więc przykład ataku DDOS - gdzie różne serwery łączą się z tym samym adresem w kółko, próbując wysycić jego zasoby sprawiając, iż dana witryna przestanie odpowiadać na żądania klientów.
Tak się niefortunnie składa, że tak atakowana witryna należała do konkurencji, która również zajmowała się tworzeniem motywów do WordPressa.
Ale to nie wszystko.
Dalej mamy do czynienia z kodem, który podmieniał treść odnośnika w kodzie strony.
Jeżeli zatem na naszym blogu umieściliśmy odnośnik do witryny A - kawałek kodu automatycznie w tle podmieniał go na witrynę B.
Dalej, ponownie kontakt z adresem producenta.
Teraz pobierano adresy email.
Jeżeli w naszym systemie istniało konto administratora o takim adresie - jego hasło było automatycznie zmieniane na inne, kontrolowane przez właścicieli.
Tutaj więc mamy do czynienia z klasycznym przykładem backdoora - kiedy to można zmienić hasło administratora z zewnątrz.
Co więcej: jeżeli nasza witryna uruchomiona była w obrębie jednego z serwerów - adres URL naszej strony był automatycznie przesyłany do twórców.
Na koniec wisienka na torcie: funkcja, która usuwała całą naszą bazę danych, a także inna, która zatrzymywała inne rozszerzenia zewnętrznych producentów.
Te kawałki kodu zostały dostrzeżone w tym samym momencie przez dwie, niezależne firmy.
Po ich reakcji - podejrzany kod został usunięty z najnowszej wersji motywu.
Pozostaje pytanie: w jakim celu ten kod istniał w tym rozszerzeniu?
Czy firma padła ofiarą ataku, w którym to przestępcy chcieli ją zdyskredytować?
Tego zapewne już nigdy się nie dowiemy.
Warto tu jednak wspomnieć o bezpieczeństwie instalowania dodatków na naszej stronie.
W wyszukiwarkach można bowiem znaleźć tak zwane wersje nulled - czyli płatne rozszerzenia dostępne za darmo na nielegalnych stronach.
Warto na nie uważać - zazwyczaj bowiem owszem, oferują podaną funkcjonalność, ale równocześnie zawierają złośliwy kod, który daje przestępcom dostęp do naszego serwera.
Monitorowanie własnych serwerów przy użyciu shodan.io
Shodan - czyli wielokrotnie omawiana tutaj wyszukiwarka serwerów, wprowadziła nową usługę w ramach swojej witryny.
Nazywa się ona monitor i pozwala na monitorowanie określonych przez nas zakresów adresów IP.
Dodatkowo, oprócz zdefiniowania zakresu, możliwe jest także ustawienie tak zwanych triggerów, czyli akcji, o których zostaniemy powiadomieni.
Jedną z opcji możliwych do wyboru jest malware - kiedy to otrzymamy notyfikację, jeżeli pod podanym zakresem IP serwis wykryje artefakty, mogące świadczyć o infekcji danej maszyny.
Równie dobrze, może nas również poinformować o wygaśnięciu certyfikatu SSL powiązanego z danym adresem.
Dzięki temu możemy zobaczyć jak wygląda nasza infrastruktura z zewnątrz - to znaczy z punktu widzenia atakujących.
Ciekawy sposób na sprawdzenie, czy aby przez przypadek gdzieś w naszej infrastrukturze nie został wystawiony port inny niż 22.
Zwłaszcza, że to monitorowanie działa w trybie ciągłym - to znaczy Shodan nieustannie odpytuje adresy w poszukiwaniu wprowadzonych zmian.
Dzięki temu - jeżeli poprzez błędną konfigurację dojdzie do wystawienia chociażby serwera mongodb na świat - jesteśmy w stanie dużo szybciej zareagować na taki incydent.
Oczywiście - podobną funkcjonalność można uzyskać samemu, chociażby poprzez użycie nmapa i skanowanie całej sieci co jakiś czas.
Tutaj jednak płacimy za gotowe, działające rozwiązanie oraz za wygodę użytkowania.
Commando VM - Windowsowa wersja Kali Linux
Jeżeli zajmujesz się bezpieczeństwem, to zapewne kojarzysz nazwę Kali Linux - czyli dystrybucję specjalnie przygotowaną z myślą o osobach powiązanych z bezpieczeństwem.
Tam to mamy gotowy i działający obraz Linuxa wraz z preinstalowanymi aplikacjami i narzędziami, przydatnymi podczas pracy pentestera czy też osób zajmujących się red teamingiem.
Ale - czasami konieczne jest używanie systemu Windows, ponieważ niektóre narzędzia działają tylko tam.
Dotychczasowo zatem, każdy z badaczy posiadał własną wirtualną maszynę, na której instalował potrzebne do swojej pracy aplikacje.
Z racji licencji na jakiej dostępny jest Windows, problematyczne jest udostępnianie takiego obrazu w Internecie.
Tak narodziło się commando VM - czyli próba stworzenia wersji Windowsa, z preinstalowanymi narzędziami.
Tutaj, przyjęto nieco inne założenia.
System należy zainstalować i aktywować samemu.
I dopiero na tak przygotowanym obrazie uruchamiamy odpowiedni skrypt.
On to jest odpowiedzialny za pobranie i instalację wszystkich potrzebnych narzędzi.
A jest ich całkiem sporo.
W pakiecie otrzymujemy bowiem nmapa, Wiresharka, Pythona, narzędzia sysinternals, mimikatza czy też x64 debugger.
Jednym słowem 140 narzędzi gotowych do działania.
Co ważniejsze - w narzędzie wbudowany jest aktualizator.
Jeżeli wiec pomysł zostanie podchwycony i stanie się pewnego rodzaju standardem - jest wielce prawdopodobne, iż będziemy mogli liczyć na dalsze rozwijanie, dodawanie nowych skryptów i programów, a także aktualizacje tych istniejących.
Osobiście trzymam kciuki.
Jak testować sklepy internetowe?
Sklepy Internetowe to skomplikowane skrypty sprawiające, że nasze zakupy stają się rzeczywistością.
Jak je testować z punktu widzenia bezpieczeństwa?
Tego można się było dowiedzieć na prezentacji OWASP w Wielkiej Brytanii.
Po pierwsze, warto przyjrzeć się wszystkiemu, co może zmienić cenę.
A jest tego sporo: opcję dowozu, ilość, zniżki, kod VAT, region kupującego czy też waluta.
Niektóre wartości mogą nie być podane wprost - tylko w jakiś sposób zaszyfrowane lub zakodowane.
Co z odpowiedziami z serwera obsługującego płatności?
Czy można zmodyfikować zwracaną przez niego kwotę lub identyfikator zakupu?
Jeśli tak - jest wysoce prawdopodobne, że jedną płatnością możliwe będzie zatwierdzenie wielu różnych transakcji.
Czy obsługa koszyka jest prawidłowa?
Klasyczny przykład: dodajemy do niego tani przedmiot.
Przechodzimy do płatności.
W nowej zakładce przeglądarki dodajemy nowe produkty lub zmieniamy ilość, wcześniej dodanych rzeczy.
Przy pomocy wcześniej otwartej zakładki płatności dokonujemy zakupu.
Jeżeli sklep jest błędnie zaimplementowany - nie odświeży ceny i wykorzysta tą, przed dodaniem nowych produktów.
Innym pomysłem jest sprawdzenie czy cena produktu nie jest przesyłana do serwera ze strony kodu użytkownika.
Wtedy to odpowiednio manipulując tym parametrem, możemy zakupić coś za ułamek wartości.
A co w przypadku obsługi wielu walut?
Czy sprawdzane jest w jakiej walucie dokonano transakcji?
Przykład: po kliknięciu kup teraz, otwierana jest podstrona Paypala - w której to użytkownik ma do zapłaty 20 EURO.
A co w przypadku, gdy takie żądanie zostanie zmodyfikowane - tak aby kwota pozostała bez zmian, lecz wybrano inną walutę?
1 Rupia indyjska to około 6 groszy.
Kwota będzie się zgadzać - różnica wyłącznie w walucie, która niekoniecznie musi być porównywana po stronie skryptu.
W dokumencie można również wyczytać o atakach race conditio, czy też różnicach, w jaki sposób różne języki programowania przetrzymują informacje na temat liczb.
I to już wszystko w tym tygodniu.
Jeżeli Ci się spodobało, zostaw komentarz i łapkę w górę pod tym filmem.
A my widzimy się już za tydzień.
Cześć!
Icon made by Smashicons, Freepik, pongsakornRed www.flaticon.com
