Testing the Security of AI-Generated Applications (film, 7m)
In an era of growing popularity of webcoding, Kamil Bernasiński decided to create three applications using AI and then attempted to hack them. In the first test, he focused on a file transfer and messaging application, written in PHP by GPT chat. He set up a virtual machine, migrated the files, and configured the database. Upon logging in, he found a simple panel with three modules: file uploads, messaging, and management. Kamil noticed that the app lacked CSRF protections and session cookie flags, which raised concerns. Moreover, after logging in, he discovered that user communication worked, but the input data was not properly encoded, posing a risk of cross-site scripting (XSS).
Kamil decided to test this vulnerability by attempting to steal another user's session. He inserted malicious code into the message, which allowed him to capture the victim's session cookie after the victim opened the messages tab. The application proved it was unsafely coded, as the system did not verify the uploaded files, leading to significant vulnerabilities. Kamil successfully uploaded PHP files as a WebShell. When he tried to implement security measures, the AI chat suggested adding validation for uploaded files and CSRF protection, giving Kamil hope for improvement.
After implementing the AI's recommendations, new challenges arose. Even though the application blocked PHP file uploads, he managed to circumvent this by changing the content-type header and successfully uploaded the malicious file. Due to specific directives in the htaccess file, the code was not executed, prompting Kamil to experiment with techniques like path traversal. Eventually, he concluded that he could overwrite existing files, successfully changing htaccess rules, which allowed him to again execute harmful scripts.
Next, Kamil examined a Cloud-generated application aimed at fetching HTML from a user-specified webpage. In his security checks, Kamil discovered that initially, the application did not verify the data source, allowing sensitive information to be retrieved. The Cloud, however, adjusted the code to block the localhost address. Also, despite advanced validation, Kamil decided to attempt a DNS rebinding attack but noted that his efforts proved ineffective.
Finally, Kamil evaluated a simple to-do list application built on the Flask framework. He noted that this application lacked significant security flaws, showcasing the progress in code generated by AI. Nonetheless, Kamil observed that a malicious HTML file could delete all the victim's tasks due to the absence of a CSRF token. In his concluding thoughts, Kamil remarked that AI-generated code is not yet sufficiently secure. In today’s world, being cautious about security, he strongly recommends conducting penetration tests before launching applications, especially when resources are limited. As of the time of writing this article, the video has 5259 views and 239 likes, indicating strong interest in the topic among viewers.
Toggle timeline summary
-
The speaker discusses creating three AI-assisted web applications and attempts to hack them.
-
The first application is for file transfer and messaging, developed in PHP.
-
The application has a login panel but lacks essential security headers.
-
After logging in, users access a basic panel with limited functionality.
-
The application fails to encode user input, making it vulnerable to cross-site scripting.
-
The speaker tests session hijacking based on the vulnerabilities found.
-
The file upload feature has critical vulnerabilities allowing attackers to upload malicious files.
-
AI suggests safeguards like file validation and disabling PHP execution in the upload folder.
-
After applying protections, attempts to upload a web shell are blocked successfully.
-
The application has improved against XSS vulnerabilities.
-
A new task involves testing an AI-generated application against SSRF vulnerabilities.
-
The code now includes user input validation to prevent SSRF attacks.
-
The speaker identifies a way to bypass the application’s security using JavaScript.
-
The final application is a simple task manager with no major security flaws.
-
The speaker concludes that the AI-generated code is not very secure.
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.