Testowanie bezpieczeństwa aplikacji wygenerowanych przez AI (film, 7m)
W erze rosnącej popularności webcodingu, Kamil Bernasiński postanowił stworzyć trzy aplikacje za pomocą sztucznej inteligencji, a następnie spróbować je schakować. W pierwszym odcinku testował aplikację do transferu plików i wymiany wiadomości, napisaną w PHP przez czat GPT. Ustawił maszynę wirtualną, przesłał pliki oraz skonfigurował bazę danych. Po zalogowaniu użytkownik zastał prosty panel z trzema modułami: uploadowaniem plików, wysyłaniem wiadomości i zarządzaniem. Kamil zauważył, że aplikacja nie miała zabezpieczeń przed CSRF ani flag na ciasteczku sesyjnym, co wzbudziło jego niepokój. Tymczasem, po zalogowaniu się, odkrył, że komunikacja między użytkownikami działała, ale dane wprowadzane do aplikacji nie były odpowiednio enkodowane, co stwarzało ryzyko ataku cross-site scripting (XSS).
Kamil postanowił przetestować tę podatność, próbując ukraść sesję innego użytkownika. Wprowadził złośliwy kod w wiadomości, co pozwoliło mu przejąć ciasteczko sesyjne ofiary po tym, jak ofiara otworzyła zakładkę wiadomości. Okazało się, że kod aplikacji nie weryfikował przesyłanych plików, co prowadziło do istotnych luk w bezpieczeństwie, tym bardziej, że Kamil mógł z powodzeniem przesłać pliki PHP jako WebShell. Kiedy próbował zaimplementować zabezpieczenia, czat AI zasugerował, aby dodał weryfikację przesyłanych plików oraz zabezpieczenia przed CSRF, co Kamilowi dało nadzieję na poprawę.
Gdy Kamil zastosował rekomendacje czata, pojawiły się nowe wyzwania. Mimo że aplikacja zablokowała upload plików PHP, udało mu się ominąć to zabezpieczenie, zmieniając nagłówek content-type i przesyłając złośliwy plik. Tylko dzięki odpowiedniej dyrektywie w pliku htaccess, kod nie został uruchomiony, co nakłoniło Kamila do eksperymentowania z innymi technikami, takimi jak path traversal. Docierając do wniosku, że można nadpisać istniejące pliki, Kamil z sukcesem zmienił zasady w pliku htaccess, co umożliwiło mu ponowne uruchomienie niebezpiecznych skryptów.
Następnie Kamil postanowił sprawdzić aplikację, stworzoną na bazie Cloud, mającą na celu uzyskanie HTML z wybranej strony przez użytkownika. Sprawdzając zabezpieczenia aplikacji, Marcin dostrzegł, że początkowo aplikacja nie weryfikowała źródła danych, co pozwalało na odczytanie poufnych informacji. Cloud jednak dostosował kod, dodając blokady dla adresów localhost. Również, mimo zaawansowanej walidacji, Kamil postanowił spróbować ataku DNS rebinding, lecz odnotował, że jego wysiłki nie przyniosły skutku.
Na koniec Kamil zbadał prostą aplikację tudylisty, która działała na frameworku Flask. Jak podkreślił, w tej aplikacji brakowało znacznych luk w zabezpieczeniach, co pokazuje postęp w generowanym kodzie przez AI. Mimo to, Kamil zauważył, że złośliwy plik HTML mógł zniszczyć wszystkie zadania ofiary z powodu braku implementacji tokenu CSRF. Kamil na koniec wskazał, że kod generowany przez sztuczną inteligencję nie jest jeszcze wystarczająco bezpieczny. Przy obecnych czasach, obawiając się o bezpieczeństwo, zdecydowanie zaleca przeprowadzenie testów penetracyjnych zanim użytkownicy zdecydują się na wprowadzenie aplikacji na rynek, zwłaszcza przy ograniczonych środkach. Na moment pisania artykułu, film ma 5259 wyświetleń oraz 239 polubień, co wskazuje na zainteresowanie tematem wśród użytkowników.
Toggle timeline summary
-
Prelegent omawia tworzenie trzech aplikacji internetowych wspomaganych przez sztuczną inteligencję i próby ich zhackowania.
-
Pierwsza aplikacja służy do transferu plików i wiadomości, rozwinięta w PHP.
-
Aplikacja ma panel logowania, ale brakuje jej podstawowych nagłówków bezpieczeństwa.
-
Po zalogowaniu użytkownicy uzyskują dostęp do podstawowego panelu z ograniczoną funkcjonalnością.
-
Aplikacja nie koduje wejścia użytkownika, co czyni ją podatną na ataki XSS.
-
Prelegent testuje przejęcie sesji na podstawie znalezionych luk.
-
Funkcja przesyłania plików ma krytyczne luki, które umożliwiają atakującym przesyłanie złośliwych plików.
-
AI sugeruje środki ochrony, takie jak walidacja plików i wyłączenie wykonania PHP w folderze przesyłania.
-
Po zastosowaniu zabezpieczeń próby przesłania shell'a internetowego są skutecznie blokowane.
-
Aplikacja poprawiła się pod względem podatności na ataki XSS.
-
Nowe zadanie polega na testowaniu aplikacji generowanej przez AI pod kątem podatności SSRF.
-
Kod teraz zawiera walidację wejścia użytkownika, aby zapobiec atakom SSRF.
-
Prelegent identyfikuje sposób na obejście zabezpieczeń aplikacji za pomocą JavaScript.
-
Ostatnia aplikacja to prosty menedżer zadań bez poważnych luk bezpieczeństwa.
-
Prelegent podsumowuje, że kod generowany przez AI nie jest zbyt bezpieczny.
Transcription
W erze rosnącej popularności webcodingu wygenerowałem trzy aplikacje za pomocą AI, a następnie spróbowałem je schakować. Zobaczcie jak mi poszło. Na pierwszy ogień leci aplikacja służąca do transferu plików oraz wymiany wiadomości napisane w PHP przez czat GPT. Postawiłem więc maszynę wirtualną, przerzuciłem pliki, skonfigurowałem bazę danych i ruszyłem. Jak widać aplikacja wita nas panelem logowania z opcją rejestracji. Na pierwszy rzut oka nie posiada ona nagłówku bezpieczeństwa, zabezpieczeń przed CSRF oraz flag na ciasteczku sesyjnym. Po zalogowaniu widzimy ubogi panel z trzema modułami. Uploadem plików, wysyłaniem wiadomości oraz wylegowywaniem. Jak widać wymienianie wiadomości między użytkownikami działa. Sprawdźmy czy aplikacja poprawnie enkoduje wprowadzane przez nas dane wprowadzając tak HTML. Jak możemy zauważyć u drugiego użytkownika tak zostaje wykonany, co jest dla nas wskazówką, że aplikacja może być podatna na start cross-site scripting. W celu zweryfikowania podatności spróbujmy ukraść sesję drugiego użytkownika. Do wiadomości wprowadzamy tak IMG odwołujący się do postawionego przez atakującego serwera plików i podającego w parametrze token sesyjny. Następnie klikamy wyślij. Żeby atak zadziałał ofiara musi jedynie przejść do zakładki wiadomości. Po wykonaniu tej czynności atakujący sprawdza swój serwer HTTP. Jak możemy zauważyć atak zadziałał i mamy ciasteczko sesyjne ofiary. Teraz atakujący podmieniając je w DevTools może przyjąć konto ofiary, co możemy zweryfikować patrząc na otrzymane wiadomości. Następną funkcjonalnością w tej aplikacji jest upload plików. Jak możemy się dowiedzieć z kodu system nie sprawdza jakie dokumenty przesyłamy, co w tym przypadku kończy się krytyczną podatnością. Atakujący jest w stanie wygrać na serwer WebShell, który sprawia, że hacker przejmuje kontrolę nad serwerem i może wywoływać na nim dowolne komendy. My dla przykładu uruchomimy kalkulator. Warto również dodać, że tutaj także jesteśmy w stanie wykonać atak cross-site scripting przez upload obrazka SVG. Żeby nie było tak łatwo podnieśmy poprzeczkę. Poprośmy czata o to, żeby wprowadził zabezpieczenia. Jak możemy zauważyć agent AI zaproponował weryfikację przesłanych plików i wyłączenie silnika PHP w folderze upload. Oprócz tego podał kod na ochronę przed XSS, CSRF oraz brute-force na panelu logowania. Po zastosowaniu rekomendacji niczym wybitny wipe-koder zaufałem czatowi i przeszedłem do ponownego testowania. Sprawdźmy czy teraz aplikacja jest bezpieczna skupiając się na najgroźniejszych podatnościach. Przy ponownej próbie wgrania web-shella dostałem komunikat informujący mnie o tym, że pliki PHP nie są akceptowane. Po przesłaniu zapytania do BERPA wystarczyło jedynie zmienić content-type na odpowiadające obrazku i nasz plik został przesłany na serwer. Po otwarciu pliku widać jednak było, że kod nie został uruchomiony ze względu na dyrektywę znajdującą się w dodanym pliku htaccess. Moim pierwszym pomysłem na ominięcie tego zabezpieczenia było użycie path traversal podczas uploadu pliku w celu wgrania go folder wyżej, gdzie dyrektywa nie obowiązywała. Ten pomysł był jednak blokowany przez użycie funkcji basename, która wycinała znaki odpowiadające za manipulację lokalizacji zapisu pliku. W związku z tym zaatakowałem z innej strony. Skoro htaccess blokujący egzekucję skryptu znajdował się w folderze uploads, do którego można było wrzucać pliki, to prawdopodobnie istniała opcja nadpisania istniejącego już pliku dyrektywą zezwalającą na uruchomienie kodu PHP z tego folderu. Okazało się, że miałem rację. Nadpisałem dane pliku htaccess na takie, które były dla mnie przydatne i w ten sposób udało się pokonać następną przeszkodę, co sprawiało, że po raz kolejny mogłem uruchamiać złośliwy kod na serwerze. Ale co z XSS? Czy został on poprawiony? Okazuje się, że tak. Kod został przepisany w bezpieczny sposób przez zastosowanie funkcji html.specialcharts przy zwracaniu informacji. Postanowiłem jednak udowodnić czatowi, że jestem w stanie go przezwyciężyć, więc wróciłem do czytania kodu. Okazało się, że na tej samej podstronie, w miejscu w którym wyświetlani są użytkownicy, wypisywani są oni za pomocą konkatenacji. Sprawia to, że jeżeli stworzymy użytkownika z payloadem w loginie, będziemy w stanie ponownie wykonać kod JavaScript w przeglądarce ofiary. 1.0 Sprawdźmy jak poradzi sobie Cloud z wygenerowaniem aplikacji w Javier. Za zadanie miał on wygenerować system służący do pozyskiwania kodu html ze wskazanej strony przez użytkownika. Celem tego zadania jest sprawdzenie, czy agent AI zabezpieczy aplikację w wystarczający sposób, żeby uchronić się przed atakiem SSRF. Aby to sprawdzić, na serwerze tworzymy również tajny plik, wyłączając do niego dostęp użytkownikom z zewnątrz. Naszym celem jest odczytanie tego pliku mimo nałożonych restrykcji. Jak widać w kodzie, aplikacja nie weryfikuje, czy serwer odwołuje się do samego siebie, co sprawia, że jesteśmy w stanie odczytać plik. Pójdźmy jednak krok dalej i powiedzmy Cloud, żeby zabezpieczył aplikację przed atakiem SSRF tak dobrze jak umie. W kodzie widzimy zmiany. Agent AI dodał walidację na dane wprowadzane przez użytkownika. Od teraz nie możemy odwoływać się bezpośrednio na localhosta. Lista zablokowanych adresów została bardzo dobrze stworzona, ponieważ nieważne, czy używałem adresów IPv4, IPv6, czy próbowałem ominąć zabezpieczenie przez użycie innego enkodowania znaków, nic nie działało. Po analizie kodu stwierdziłem, że spróbuję ataku DNS rebinding, w którym serwer za pierwszym razem rozwiązuje adres na taki, który przechodzi przez filtry, a za drugim serwer DNS zmienia adres IP na lokalny. Uznałem, że była szansa na wykorzystanie tej techniki, ponieważ aplikacja rozwiązywała adres dwukrotnie. Niestety domyślny payload nie działał, a debugowanie wykazało, że adres nie zostaje zrotowany po pierwszym zapytaniu. Zacząłem zastanawiać się, czy jest to winokraszowanie przez javę i odłożyłem temat na później w celu głębszego zbadania. Okazało się jednak, że zanim do tego przystąpiłem, udało się znaleźć sposób na pokonanie aplikacji. Jak widzimy w kodzie, aplikacja używa JSOB do pobrania kodu HTML bez użycia metody followRedirect ustawionej na false. Sprawia to, że w tym przypadku jesteśmy w stanie odwołać się do zewnętrznego serwera, który przez nagłówek location przekierowuje nas na localhosta. Konsekwencją tego jest uzyskanie przez nas dostępu do wrażliwych informacji przez użycie następującego payloadu. 2.0 Ostatnią aplikacją była prosta tudylista we flasku stworzona ponownie przez cloud. Umożliwiała ona rejestrację, logowanie oraz zarządzanie zadaniami. Po spędzeniu czasu nad testowaniem oraz analizą kodu okazało się, że aplikacja nie posiada znaczących ubytków z perspektywy bezpieczeństwa. W każdym miejscu dane od użytkownika zwracane były w bezpieczny sposób, a userzy w aplikacji nie mogli sobie nawzajem dodawać, czytać ani usuwać zadań. Wyjątkiem była możliwość spreparowania złośliwego piku HTML usuwającego wszystkie zadania ofiary po jego otwarciu i interakcji. Było to spowodowane brakiem implementacji tokenu CSRF. Jak widzimy, kod generowany przez AI na obecną chwilę nie należy do najbezpieczniejszych. Dlatego jeżeli jesteś osobą nietechniczną lub początkującym programistą i planujesz następny startup o wielkości Facebooka, a do dyspozycji masz jedynie 20 dolarów na plan premiów o PLAI, to lepiej odłóż trochę na porządne testy penetracyjne.