Transcription

Cześć! Błędy, luki, zero-day'e to ogólnie chleb powszedni cyberbezpiecznikowej branży. Na tyle, że można się nimi wręcz znudzić, bo każdego dnia pojawiają się tysiące nowych. Codziennie mamy nowe. Ale raz na jakiś czas trafia się jakaś perełka, jakaś gwiazda roka, która trzęsie całym światem, trafiając nawet do popularnych mediów. I tym razem też tak jest, ale wcale nie dlatego, że kładzie ona krytyczne systemy, od których zależą losy ludzkości. Po raz pierwszy, przynajmniej oficjalnie, podatność zero-day w oprogramowaniu odnalazła sztuczna inteligencja. I to tak samodzielnie. A to brzmi już naprawdę bardzo interesująco. Zapraszam. Zacznijmy od odrobiny historii. Struktur, zespołów czy innych projektów w obrębie Google'a jest naprawdę sporo. W dodatku ich śmiertelność jest bardzo wysoka, bo Google znane jest z tego, że lubi sobie czasem zrobić coś ciekawego, żeby po paru latach totalnie znienacka stwierdzić, że to jednak bez sensu i zostawić wszystkich korzystających z takiego inboxa na lodzie. Tak, nadal wkurzam się na samo wspomnienie. Na szczęście są też takie projekty, którym udało się jakimś cudem w tak niesprzyjającym środowisku przetrwać i to ponad dekadę od momentu sformalizowania. Mówię o Project Zero, czyli pionie odpowiedzialnym za poszukiwanie podatności, w szczególności zero-dayów, w produktach głównie Google, ale nie tylko. Do Project Zero należał on dziś choćby GeoHot czy topowi polscy hakerzy, a na koncie mają oni odnalezienie luki również u bezpośredniej konkurencji, czyli u Apple'a czy w Microsoft'cie. Mieli też swój udział w opisaniu albo współodkryciu CloudBleeda, Meltdown, Spectre czy Forced Entry, a więc nie są to pierwsze lepsze leszcze. Jednak, aby latami pozostawać na topie w tak dynamicznej branży, nie można pozwolić sobie na zasypianie gruszek w popiele. Szukają więc stale coraz to nowszych rozwiązań, które nie tylko ułatwiają ich pracę, ale też zwiększają wachlarz dostępnych narzędzi. Nic więc dziwnego, że skierowali swój wzrok na AI w ramach projektu Naptime. Jednym z wielu miejsc, gdzie postanowiono poszukać zastosowań dla sztucznej inteligencji jest projekt Naptime, czyli drzemka. Skąd ta nazwa? To proste. Badacze chcą mieć więcej czasu na odpoczynek w czasie, kiedy AI będzie robić ich robotę. To wielkie modele językowe mają wejść w rolę niezależnego pentestera, który nie tylko jest w stanie analizować niewyobrażalne wręcz wielkie zbiory danych, ale też przy tym nigdy się nie męczy. Wystarczy tylko prąd i karty graficzne. Bardzo dużo kart graficznych. Ale to wcale nie jest tak, że automatyzacja zawitała do tego świata dopiero teraz. O nie. Jest wręcz przeciwnie. Po prostu projekt Naptime ma na celu wynieść się na nowy, zdecydowanie wyższy niż dotychczas poziom. W dodatku w miejscu, w którym konkurencja uważa, że jest to na razie niewykonalne. Jak Google'owi badacze mają zamiar tego dokonać? A no stosując wszystkie najnowsze trendy, jak choćby agentowe podejście do rozbudowanych systemów AI. Bierze się dobrze znane modele, jak choćby GPT-4 czy Gemini, doucza je w zakresie wykonywania bardzo wyspecjalizowanych zadań i spina ich większą liczbę w jeden system dysponujący po prostu paletą narzędzi właściwych do rozwiązywania pomniejszych zadań. Mowa tu choćby o interaktywnym środowisku programistycznym czy debagerze. Model ma dokonać analizy, postawić tezę, a potem sprawdzić jej prawdziwość. Autonomicznie, co ważne, takie hipotezy stawiane przez model mają jedną ważną cechę. Można je przetestować, a ich wynik jest łatwy w ocenie i nie budzi wątpliwości. Bo w uproszczeniu, albo luka jest i da się ją wykorzystać, albo jej nie ma. Warto więc postawić na takie sprawdzenie mocny nacisk, aby były wykonywane z dostateczną starannością, bo to od nich w największym stopniu wszystko zależy. Ostatnim, na co zwracają uwagę badacze z Google, jest sprawdzanie wielu hipotyz równolegle z weryfikacją wyniku po prostu na wyjściu, co ma znacznie podnosić wydajność takiego procesu. No i kiedy w dodatku da się takiemu systemowi możliwość, a przede wszystkim odpowiedni czas, aby mógł wyciągnąć ze swoich działań wnioski i adaptować swoje działanie, to można daleko zajść. Jak daleko? Efektem takiego podejścia był nawet dwudziestokrotny wzrost wyników w przeprowadzonych przez Google testach. Badacze informowali już w czerwcu, że dostarczenie odpowiedniej jakości narzędzi LLM-om pozwala prowadzić w miarę niezależne pentesty. Owszem, dość proste oraz w środowisku zadań z kategorii CTF, gdzie wiadomo, że jest jakaś konkretna luka do znalezienia, a nie szuka niepodatności w realnych produktach, ale to całkiem niezły pierwszy krok. Tylko skoro mowa o testach, a raczej pewnym ich specjalnie wybranym podzbiorze w dodatku testach syntetycznych, to nie ma tu żadnego przełożenia na rzeczywiste problemy, prawda? Okazuje się, że z drzemki można nie tylko się obudzić, gdy czar pryska, ale też pójść w drugą stronę. Zapaść w zimowy sen. A tak bez metafor na około, bo ta w sumie średnio mi wyszła, to w Google doszło do pewnych organizacyjnych zmian i nie, nie zabili, przynajmniej tym razem, projektu Zero. Po prostu z Naptajn zrodził się Big Sleep, Wielki Sen, bo w projekt dodatkowo zaangażowana do pomocy ludzi odpowiedzialnych za Deep Mind, czyli takie AI na pełnej k***e. Pozwoliło to na pewno znacznie przyspieszyć ewolucję wirtualnego pentestera, bo już w październiku doszło do nielada przełomu. Wielki model językowy odnalazł podatność w bazie danych SQLite, a to rozwiązanie wykorzystywane naprawdę bardzo szeroko w niezliczonych produktach, więc jakiekolwiek ewentualne podatności mogą mieć daleko idące skutki na łańcuch wytwarzania oprogramowania. Samo odkrycie luźno bazowało na nieco wcześniejszych pracach innych badaczy. Team Atlanta z zawodów AI Cyber Challenge organizowanych przez amerykańskie jednostki rządowe. Ich narzędzie, Atlantis, też jest LLM-em służącym do wykrywania i naprawy bugów, ale nie było ono jeszcze na ten czas na tyle samodzielne, aby można było mówić o jakimś wielkim przełomie. Co więc i jak odkrył Big Sleep? To błąd kategorii niedopełnienie bufora. Co ciekawe, odnaleziono go w kodzie źródłowym jeszcze przed opublikowaniem nowej, zawierającej go wersji SQLite. Utrzymujący pakiet mogli dzięki temu naprawić tę lukę niezwłocznie, a więc ta nigdy nie trafiła do użytkowników i nikt potencjalnie nie był zagrożony. No chyba, że lubi życie na krawędzi i korzystał z buildów Nightly na Prodzie. Pozdro dla takich wariatów, nie zmieniajcie się. Na czym polegał znaleziony błąd? W dużym skrócie jedna ze zmiennych przechowujących identyfikator kolumny bazy danych mogła przyjmować wartość ujemną "-1". To jeszcze nie błąd sam w sobie, a udokumentowana funkcjonalność. Przyjęcie przez nią właśnie wartości "-1", sprawia, że funkcja zwróci nie numer kolumny, a numer wiersza, do którego się odwołujemy. Pewnie wykorzystuje się to np. do transponowania bazy, zamieniając kolumny na wiersze i odwrotnie, ale to tylko moje podejrzenie. Co jednak istotne, jeżeli jakaś zmienna może, choć w bardzo rzadkim przypadku, przybierać wartość na pierwszy rzut oka nielogiczną i służy to w jakimś celu, to trzeba dobrze udokumentować takie zachowanie, aby nikt nie był zdziwiony, kiedy to się wydarzy. Następnie zadaniem wszystkich programistów odwołujących się w swoich fragmentach kodu do tego elementu jest poprawna implementacja takiego zachowania. No i, jak się pewnie domyślacie, jedna z tysięcy funkcji w kodzie SQLite nie była przygotowana na tę ewentualność. Z tego też powodu, jeśli akurat zmienna przyjmowała wartość ujemną, a funkcja z luką odwołała się do niej, aby zapisać jakieś dane, to mogła próbować zapisywać je w wierszu o ujemnym identyfikatorze, a więc nieistniejącym, co oczywiście może prowadzić do wielu nieprzewidzianych zachowań. To oczywiście nieco bardziej skomplikowane, ale chyba łapiecie z grubsza o co chodzi. Bardziej dociekliwych odsyłam po prostu do zalinkowanych w opisie źródeł. Badacze przyznali, że nie tylko wykorzystanie tej podatności w realnym świecie byłoby bardzo skomplikowane, ale też człowiekowi znaleźć ją nie byłoby łatwo. A model językowy dał sobie z tym radę. Przechodził on krok po kroku od idei do rozwiązania zadanego problemu. Najpierw odczytał cały udostępniony mu kod. Na podstawie tego przygotował kilka hipotez wartych sprawdzenia. Następnie przeprowadził testy i używając debaggera monitorował efekty. Kiedy jednak nic nie znalazł, zrobił krok wstecz i zmienił zadanie testowe. Odnalazł, że zmienna powinna zawierać się w określonym zakresie, jednak w pewnym konkretnym przypadku może z niego wypadać, co powoduje błędy. Co ciekawe, badacze postanowili też przebadać, czy to specyficzne odkrycie byłoby możliwe z wykorzystaniem innych, prostszych narzędzi. Skorzystali z fuzingu, czyli metody automatycznego zasypywania aplikacji różnymi parametrami w poszukiwaniu miejsc, gdzie niespodziewana wartość może wywołać jakiś dziwny efekt. Mimo naprowadzania na to konkretne miejsce, fuzing nie zakończył się jednak sukcesem i nie znalazł tej podatności. To pierwszy znany przypadek, kiedy to właśnie sztuczna inteligencja odnalazła jakiś błąd i niesie to za sobą liczne implikacje, których jeszcze pewnie nawet nie znamy. Ale po kolei, po pierwsze i najważniejsze, pozwala to poszukiwać luk w oprogramowaniu znacznie szerzej i szybciej, w dodatku robiąc to na bardzo wczesnym etapie, jeszcze przed dostarczeniem kodu na produkcję. Może to oznaczać, że w przyszłości firmy, przynajmniej z kategorii tych poważniejszych, będą dostarczać nam oprogramowanie z mniejszą liczbą luk. Będzie ono po prostu w wyższej jakości, a my staniemy się nieco bezpieczniejsi, bo nareszcie tempo testowania kodu może nadążać będzie za tempem jego powstawania. Pozwoli to doprowadzić do sytuacji, choć to pewnie tylko moje życzeniowe myślenie, w której w końcu po tylu latach toczenia nierównej walki, to obrońcy zyskają nieco przewagi nad atakującymi, a nie będą jedynie z różnym efektem próbować ich gonić. Czego Wam i sobie serdecznie życzę. Ale z drugiej strony, AI to po prostu narzędzie, które będzie i w sumie już jest wykorzystywane nie tylko po dobrej stronie mocy, ale też przez różnych cyberprzestępców. Ułatwia choćby przeprowadzanie kampanii phishingowych, generując teksty maili, które są w miarę wysokiej jakości, co pozwala łatwiej oszukiwać potencjalne ofiary, ale to dopiero początek. Główny w wielu kręgach z jailbreakowania modeli językowych Pliny the Liberator pokazał ostatnio schemat, w którym agent AI loguje się do poczty elektronicznej, przygotowuje całkiem zaawansowane oprogramowanie ransomware, pisze phishingowego maila, a potem wysyła go do swojej ofiary. Owszem, to wszystko wydarzyło się na razie w warunkach laboratoryjnych, ale nie minie wiele czasu, zanim to samo zrobią cyberprzestępcy albo grupy APT. O ile już tego nie robią. Co robić i jak żyć? Wykorzystanie narzędzi AI nie jest pierwszą próbą automatyzacji testów oprogramowania. O nie. Masz do dyspozycji różne mechanizmy, które to znacznie ułatwiają. W większości przypadków to właśnie fazery są jednymi z najlepszych narzędzi do poszukiwania błędów w oprogramowaniu. Eskulite również z nich korzystał, ale nie wyłapały one opisywanego błędu, który sztucznej inteligencji udało się odkryć. Czy to więc ich koniec? No nie. Badacze Google wielokrotnie podkreślają, że to wszystko dopiero pierwsze testy i jesteśmy w tym zakresie na początku drogi. Bo musisz wiedzieć, że Big Sleep skupia się na pewnym bardzo niewielkim wycinku kategorii podatności. Chodzi o takie, których warianty wcześniej już odkryto i naprawiono, ale być może niezbyt dokładnie albo nie wszędzie. To nie przypadek. Czym bardziej problem, który dasz do rozwiązania modelowi, będzie zbliżony do tego, które napotkał w zbiorze danych nauczających lub kontekście, któremu nadasz, tym uzyskany wynik będzie lepszy. Ale widząc tempo rozwoju narzędzi opartych o AI, pewnie już niedługo znajdzie się dla niej więcej zastosowań. I to już wszystko na dziś. Tymczasem dziękuję za Waszą uwagę i do zobaczenia!