Błąd za 25 dolarów wart 500 000: AI właśnie wywróciło model kosztów VDP

Koszt znalezienia krytycznego błędu właśnie się załamał. Badacz z Searchlight Cyber skierował czołowy model na rdzeń WordPressa, wydał około 25 dolarów na moc obliczeniową w ciągu mniej więcej dziesięciu godzin i wydobył podatność SQL injection typu pre-auth, która eskaluje do zdalnego wykonania kodu — klasę błędów, którą brokerzy exploitów wyceniają nawet na 500 000 dolarów. To nie jest opowieść o spamie AI. To jego dokładne przeciwieństwo — i zarazem scenariusz awarii, którego prawie żaden program ujawniania podatności nie miał w budżecie: fala prawdziwie ważnych, prawdziwie krytycznych zgłoszeń napływających szybciej, niż jakikolwiek dyżur triażu zdąży je potwierdzić, zweryfikować i wypłacić za nie nagrody.

Jeśli prowadzisz program ujawniania podatności (VDP) albo program bug bounty, cały twój model kosztów opiera się na jednym cichym założeniu: że znalezienie krytycznego błędu jest kosztowne i rzadkie. To założenie właśnie się rozsypało. Oto co to oznacza dla twoich SLA, budżetu na nagrody i kolejki triażu — oraz co zmienić jeszcze w tym kwartale.

Co się właściwie wydarzyło i co jest potwierdzone

Adam Kues, badacz z Searchlight Cyber, zaadaptował przepis na promptowanie AI w wieloagentowy zestaw do polowania na podatności i skierował czołowy model na kod źródłowy WordPressa. Badacz podaje, że wykrycie podatności SQL injection typu pre-auth, eskalującej do RCE, zajęło ponad dziesięć godzin czasu pracy modelu i kosztowało około 25 dolarów. Następnie odtworzył ją na standardowej instalacji WordPressa, prosząc model o wykradzenie adresu e-mail administratora — a model wypisał ten adres w kilka minut. Wstrzymał publikację i przygotował zgłoszenie do ujawnienia.

Liczą się tu dwa punkty odniesienia i tylko jeden jest niezależnie potwierdzony. Kwota 25 dolarów i dziesięć godzin działania modelu to relacja samego badacza o własnej pracy, więc traktuj je jako deklarację, a nie potwierdzony fakt. Wycena 500 000 dolarów to ta, którą da się sprawdzić: publiczny cennik Exploit Acquisition Program firmy Crowdfense podaje „WordPress (RCE): 500k USD” — ten sam poziom co zdalne wykonanie kodu w Apache HTTP Server i Microsoft IIS, powyżej Nginxa wycenianego na 350 tys. i znacznie powyżej innych systemów zarządzania treścią, jak Joomla (40 tys.) czy Drupal (25 tys.). Pułap szarego rynku jest realny — to nie retoryczny ozdobnik. W źródle nie przypisano żadnego CVE, a dokładna nazwa modelu pochodzi z narracji artykułu, nie ze specyfikacji gotowego produktu.

Cała historia tkwi w tej różnicy. Koszt znalezienia: około 25 dolarów. Wartość dla atakującego: nawet pół miliona dolarów. Te dwie liczby kiedyś były mniej więcej skorelowane, bo między nimi siedziała rzadka ludzka wiedza ekspercka. AI właśnie usunęło człowieka jako wąskie gardło.

„Śmieci AI” były łatwym problemem

Od dwóch lat branżowa dyskusja o AI i bug bounty toczy się wokół szumu. Zmyślone CVE, zahalucynowane nazwy funkcji, szablonowe zgłoszenia — zalew tandetnych, masowo produkowanych śmieci, przez które opiekun curl Daniel Stenberg publicznie dał upust frustracji wobec generowanych przez AI zgłoszeń marnujących jego czas. Sami pisaliśmy o tym scenariuszu awarii w artykule Śmieci AI zalewają triaż bug bounty. Śmieci marnują godziny triażu. Są irytujące, kosztowne przy dużej skali, a obrońcy włożyli sporo wysiłku w dostrojenie filtrów, które je odrzucają.

Znalezisko w WordPressie to dokładna odwrotność — i prawdopodobnie coś gorszego. To wysokiej jakości, wysokiej wagi sygnał, wytwarzany z prędkością maszyny i przy niemal zerowym koszcie krańcowym. Śmieci zagrażają twojemu czasowi triażu. Fala prawdziwych zgłoszeń krytycznych zagraża trzem rzeczom naraz: twojemu SLA na potwierdzenie, budżetowi na nagrody i procesowi łatania. Dostroiłeś swój proces przyjmowania zgłoszeń pod odrzucanie śmieci. Nie zaplanowałeś budżetu na obfitość złota.

Oto niewygodna rzeczywistość operacyjna: oba scenariusze awarii nadchodzą teraz razem. Ta sama technologia, która produkuje ważne zgłoszenia krytyczne, tworzy też przekonujące fałszywki, prawdziwe, lecz stare CVE zgłaszane ponownie jako nowe oraz wiarygodne odwołania w kodzie do funkcji, które nie istnieją. Triaż nie może już zakładać, że zgłoszenie jest albo wiarygodne, albo bezwartościowe. Musi zakładać, że oba tryby są aktywne w tej samej kolejce, każdego dnia.

Dlaczego tanie odkrywanie rozbija model kosztów bug bounty

Wycena bug bounty koduje ukryty układ. Znalezienie krytycznego błędu jest kosztowne i rzadkie, więc nagroda rzędu kilku tysięcy dolarów to sprawiedliwy podział wartości z rzadkim ekspertem, który wybrał ujawnienie zamiast szarego rynku. Kiedy koszt odkrycia spada do 25 dolarów, ten układ się odwraca. Broker nadal płaci 500 000 dolarów, bo ofensywna wartość RCE typu pre-auth na setkach milionów instalacji się nie zmieniła. Ale wypłata programu, często o jeden do trzech rzędów wielkości niższa, wygląda teraz jak błąd zaokrąglenia zarówno wobec prawdziwej wartości błędu, jak i liczby takich błędów, które za chwilę napłyną.

Zestawmy trzy liczby obok siebie:

Problem nie polega na tym, że programy są skąpe. Chodzi o to, że załamanie kosztu odkrywania poszerzyło i tak już dużą przepaść między tym, ile błąd jest wart dla atakującego, a tym, ile obrońca może racjonalnie zapłacić — a jednocześnie zwielokrotniło liczbę takich błędów, które program otrzyma. Badacz, który potrafi produkować zgłoszenia krytyczne po 25 dolarów za sztukę, staje przed ostrym wyborem: zgłosić do programu, który płaci — o ile w ogóle — 5 000 dolarów i narzuca warunki ujawniania — albo sprzedać brokerowi za 500 000. Tanie odkrywanie nie tylko obciąża moce przerobowe triażu. Zaostrza pokusę pójścia na szary rynek dokładnie w przypadku najpoważniejszych zgłoszeń, które twój program najbardziej potrzebuje otrzymać.

Żaden samodzielnie hostowany program nigdy nie dorówna brokerowi. To nie jest cel, a udawanie, że jest inaczej, marnuje wiarygodność. Realistycznym celem jest przyciągnięcie dużej grupy badaczy, którzy woleliby ujawnić, o ile tarcie i różnica w wypłacie są duże, ale nie obraźliwe. To problem projektowania programu, w którym trzy czynniki naprawdę decydują o wyniku.

Trzy rzeczy, które każdy właściciel VDP musi teraz dostroić na nowo

Tanie odkrywanie nie wymaga nowej platformy. Wymaga dostrojenia trzech podstaw, które twój program już ma albo powinien mieć: poziomów SLA, ekonomii nagród i mocy przerobowych triażu. Samodzielnie hostowany moduł CSIRT w Kit koduje każdą z nich jako konfigurację, więc użyję jego ustawień domyślnych jako konkretnego punktu odniesienia. Zasady obowiązują niezależnie od tego, czy używasz Kit, HackerOne, czy pliku security.txt i wspólnej skrzynki.

Dostrojenie SLA: oddziel „usłyszeliśmy cię” od „naprawiliśmy to”

Jednolite SLA załamuje się pod falą ważnych zgłoszeń krytycznych. Rozwiązaniem jest rozbicie jednej obietnicy na dwie. Potwierdzenie jest tanie i szybkie: mówi „człowiek ma twoje zgłoszenie i zegar tyka”. Rozwiązanie jest kosztowne i wolne: mówi „to jest załatane”. Mieszanie ich oznacza, że każdy skok napływu zagraża twojemu publicznemu zobowiązaniu do naprawy rzeczy w terminie, którego już nie kontrolujesz.

Zarezerwuj najbardziej napięte cele rozwiązania tylko dla najwyższego poziomu ważności, żeby fala zgłoszeń krytycznych nie mogła w praktyce zablokować twojej kolejki. Csirt::SlaConfig w Kit ma domyślnie dokładnie taki układ: obietnicę potwierdzenia w 72 godziny, a następnie cele rozwiązania stopniowane według ważności — 24 godziny dla super-critical, 72 godziny dla critical, 7 dni dla high i coraz dłuższe dla medium i low. Sedno tego projektu w tym, że potwierdzenie pozostaje stałe i tanie, podczas gdy rozwiązanie skaluje się z ważnością. Kiedy w ciągu tygodnia napłynie sto ważnych zgłoszeń, wciąż możesz dotrzymać „usłyszeliśmy cię, w ciągu 72 godzin” dla wszystkich, a „naprawiliśmy to, w ciągu 24 godzin” tylko dla prawdziwych dziesiątek (CVSS 10.0).

Nowa wycena nagród: zbuduj dający się obronić najwyższy poziom i politykę deduplikacji

Twój słownik ważności potrzebuje pasma powyżej „critical”. AI za chwilę wydobędzie więcej prawdziwych CVSS 10.0, niż programy historycznie widziały przez rok, a RCE sprzed uwierzytelnienia na ogromnej bazie instalacji to dokładnie to. Kit modeluje to poziomem super_critical (CVSS 10.0) stojącym powyżej critical (9.0 do 9.9) oraz stopniowanym BountyMatrixConfig, który biegnie od 0 dolarów za informacyjne aż do 5 000–10 000 dolarów za super-critical.

Bądź szczery co do tego, czym jest ten najwyższy poziom. Hojna domyślna kwota 5 000–10 000 dolarów w samodzielnie hostowanym Kit wciąż jest 50–100 razy niższa od ceny brokera za dokładnie ten błąd, który znalazł Kues. Tej przepaści nie zamkniesz, więc przestań próbować. To, co możesz zrobić, to zwiększyć nachylenie krzywej i poszerzyć jej szczyt tak, żeby najpoważniejsze zgłoszenia wyraźnie opłacało się zgłaszać, a nie odkładać do szuflady. Przechodzimy przez to szczegółowo w artykule jak ułożyć poziomy nagród w bug bounty.

Następnie dodaj politykę deduplikacji, bo nagle zaczyna dźwigać realny ciężar. Kiedy wielu badaczy kieruje ten sam model na ten sam popularny cel, kolizja na identycznych błędach nie jest ryzykiem — jest przewidywalnym wynikiem. Bez jasnej, opublikowanej reguły „pierwsze ważne zgłoszenie wygrywa” będziesz przepalać wiarygodność na rozstrzyganie sporów o to, kto zgłosił pierwszy — dokładnie ten scenariusz omawiamy w artykule rozstrzyganie sporów o wypłaty w bug bounty. Kit domyślnie włącza deduplikację w swoim TriageConfig właśnie z tego powodu.

Triaż z prędkością maszyny: odsiewaj śmieci i przyspieszaj prawdziwe zgłoszenia krytyczne

Triaż ma teraz dwa zadania, które ciągną w przeciwne strony. Musi odrzucać przekonujące fałszywki oraz szybko walidować prawdziwy sygnał wysokiej wagi — często w tej samej kolejce tego samego dnia. Triaż w ludzkim tempie nie udźwignie obu tych zadań naraz przy dużej liczbie zgłoszeń.

Odsiewanie to pierwsza połowa. Csirt::AiScreening w Kit wylicza ai_confidence_score (od 0,0 do 1,0 — prawdopodobieństwo, że zgłoszenie to śmieci AI) i oznacza znane sygnały fabrykacji: zahalucynowane funkcje, zmyślone CVE, wcześniejsze CVE podane jako nowe czy zgłoszenia bez konkretnego proof of concept. Ta warstwa powstała z myślą o problemie śmieci i wciąż musi działać, bo śmieci nie znikną.

Ale odsiewanie to tylko połowa nowego problemu. Nowy front to szybka ścieżka dla ważnych zgłoszeń krytycznych. Oznacza to automatyczną eskalację i kierowanie na dyżur, żeby super-critical nigdy nie leżało w kolejce, czekając, aż ktoś je zauważy. TriageConfig w Kit obsługuje poziomy ważności do eskalacji (domyślnie critical i super_critical), wymogi ponownego testu oraz automatyczne przypisanie do osoby na dyżurze, podpięte do rotacji dyżurów i PagerDuty. Wniosek dla każdego właściciela programu: filtrowanie śmieci to dziś absolutne minimum; szybka walidacja i priorytetyzacja prawdziwego sygnału przy dużej liczbie zgłoszeń to umiejętność, którą naprawdę musisz zbudować w następnej kolejności.

Co zrobić w tym kwartale

Nie przebijesz oferty brokera i nie musisz. Potrzebujesz programu na tyle szybkiego, wiarygodnego i sprawnie zorganizowanego, żeby badacz, który woli ujawnić, nie znalazł w tarciu po twojej stronie żadnej wymówki, by mimo to pójść do brokera. Konkretnie:

1. Rozdziel SLA. Opublikuj szybki, stały cel potwierdzenia oraz cele rozwiązania stopniowane według ważności. Zarezerwuj najbardziej napięty cel rozwiązania dla najwyższego poziomu powyżej „critical”.
2. Dodaj pasmo super-critical i podnieś wycenę szczytu. Poszerz krzywą nagród i zwiększ jej nachylenie tak, żeby prawdziwe dziesiątki opłacało się zgłaszać. Zaakceptuj różnicę wobec cen brokerów; zamknij tę część różnicy, która jest obraźliwa.
3. Opublikuj regułę deduplikacji, zanim będzie potrzebna. Wygrywa pierwsze ważne, w pełni odtwarzalne zgłoszenie. Napisz to na piśmie teraz, a nie w trakcie sporu.
4. Prowadź dwustronny triaż. Wyliczaj prawdopodobieństwo autorstwa AI, żeby wyłapać fałszywki, i automatycznie eskaluj ważne zgłoszenia krytyczne na dyżur, żeby nic poważnego nie czekało w kolejce.
5. Mierz czas potwierdzenia. Jeśli nie widzisz swojego czasu do potwierdzenia w rozbiciu na poziomy ważności, nie obronisz go, gdy nadejdzie fala.

Koszt znalezienia krytycznego błędu spadł do 25 dolarów. Wartość tego błędu dla atakującego nie drgnęła. Twój program żyje w przepaści między tymi liczbami, a przepaść właśnie się poszerzyła i zrobiło się w niej tłoczniej. Programy, które przetrwają najbliższy rok, nie będą tymi z największą pulą nagród. Będą tymi, które potwierdzają szybko, wyceniają uczciwie, deduplikują sprawiedliwie i eskalują prawdziwe zgłoszenia krytyczne, zanim ktokolwiek inny w ogóle otworzy zgłoszenie.

Jak CSIRT w Kit radzi sobie z falą

Kit to platforma dla startupów oparta na AI od podstaw, a jej samodzielnie hostowany moduł CSIRT i VDP istnieje właśnie dlatego, że założyciele domyślnie kończą jako właściciele triażu bezpieczeństwa. Dostarcza cztery mechanizmy, których wymaga ta zmiana, jako konfigurację, a nie projekt: pasmo ważności super_critical powyżej critical, rozdzielone SLA na potwierdzenie i rozwiązanie, stopniowaną matrycę nagród, którą możesz wycenić na nowo, deduplikację i automatyczną eskalację na dyżur oraz screening AI, który wylicza prawdopodobieństwo, że zgłoszenie to śmieci.

Jedno, czego nie robi: nie udaje brokera płacącego 500 000 dolarów — i właśnie w tej szczerości tkwi sedno. Sprawnie zorganizowany, szybki, przejrzysty program przyciąga badaczy, którzy woleliby ujawnić niż sprzedać, o ile nie sprawisz, że ujawnianie będzie powolne, nieprzejrzyste lub obraźliwe. Krzywa kosztów znajdowania krytycznych błędów się załamała. Projekt twojego programu to jedyny czynnik, który wciąż w pełni kontrolujesz — dostrój go więc przed falą, a nie w jej trakcie.