W najnowszym odcinku podcastu skupiono się na aktualnych wyzwaniach z zakresu cyberbezpieczeństwa, które dotykają zarówno gigantów motoryzacyjnych, jak i sektor publiczny. Omówiono spektakularne wycieki danych z Mercedes-Benz i BMW, podkreślając kluczową rolę higieny cyfrowej, zwłaszcza w kontekście zarządzania sekretami w publicznych i prywatnych repozytoriach GitHub oraz niewłaściwie skonfigurowanych usługach chmurowych, takich jak Azure Blob Storage. Analiza tych incydentów dostarcza praktycznych wniosków dla specjalistów IT i inżynierów bezpieczeństwa, wskazując na konieczność proaktywnego skanowania infrastruktury pod kątem wrażliwych danych oraz znaczenie edukacji pracowników w zakresie bezpiecznych praktyk programistycznych.
Dalsza część odcinka porusza kwestie zaawansowanych technik hakowania web-aplikacji oraz roli sztucznej inteligencji w testach penetracyjnych. Przedstawiono najnowszą listę top 10 technik hakowania web-aplikacji Portswiggera, ze szczególnym uwzględnieniem problemów związanych z różnicami w parserach, co stanowi cenną wskazówkę dla red teamerów i testerów penetracyjnych dążących do rozwijania swoich umiejętności w ofensywnym cyberbezpieczeństwie. Podkreślono również wciąż aktualne zagrożenie Cross-Site Scripting (XSS), analizując niedawne ataki na instytucje rządowe, co pokazuje, że nawet podstawowe podatności pozostają wektorem dla zaawansowanych cyberataków. Na koniec, z dużą dozą sceptycyzmu, dyskutowano o możliwości zastąpienia pentesterów przez duże modele językowe, wskazując na obecne ograniczenia AI w kontekście rzeczywistych scenariuszy cyberataków.
Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.
Transkrypcja
Andrzej: Dzień dobry, dzień dobry. Cześć, Krzysiek. Spotkamy się kolejny raz po miesiącu. Jak widać, zaszły pewne zmiany. Mamy już trochę ładniejsze tło, ładniejsze podpisy. No i nawet może audio będzie lepsze. Też widzę, że, Krzysiek, lepiej wyglądasz. Znaczy, zawsze dobrze wyglądasz, ale dzisiaj wyglądasz jeszcze lepiej niż zwykle. Więc możemy startować. Startować z naszą analizą dynamiczną.
Krzysztof: Dokładnie. Dzięki Andrzej, witam słuchaczy, tak twarze trochę ładniejsze, tryby portretowe ustawione, więc możemy zaczynać.
Andrzej: Zasługa aparatów i kamery. Dobra, Krzysiek, w tym miesiącu przygotowaliśmy dla słuchaczy trochę mniej newsów, dlatego żeby jednak gdzieś tam timeboxować w około jednej godziny, a nie podbijać prawie pod dwie, bo zdajemy sobie sprawę, że może być to po prostu męczące. Jedna godzina jest bardziej doable, więc każdy z nas ma po trzy znaleziska. Krzysiek ma swoje trzy, ja mam swoje trzy. I dobra, to startuj, tak jak ostatnio, ty wystartuj ze swoim, a potem ja przejdę do twojego, ale oczywiście też będę miał pewnie jakiś komentarz do twojego znaleziska.
Krzysztof: Okej, no to zaczynamy. W lutym. miały miejsce dwa ciekawe incydenty, które łączą się w bardzo fajny sposób. Mówię tutaj o wyciekach z dwóch firm gigantów tak naprawdę branży motoryzacyjnej, niemieckiej branży motoryzacyjnej, i obie z tych firm stały się ofiarami własnych błędów w kontekście higieny, zarządzania sekretami, ale z pewnych dwóch różnych perspektyw, dlatego te dwa przypadki są dosyć ciekawe i chciałem je poruszyć właśnie w ramach analizy dynamicznej. Zaczynając od tego incydentu, który miał miejsce w firmie Mercedes, zespół Red Hand Labs na początku lutego poinformował, że znalazł w publicznym repozytorium token do instancji GitHub Enterprise, która była i jest najprawdopodobniej własnością firmy Mercedes-Benz. I token ten został upubliczniony przez pracownika Mercedesa, pracownika na pełen etat, w pełnym wymiarze czasu, w jego osobistym repozytorium, które było na GitHubie prywatne, czyli token się w jakiś magiczny sposób znalazł w jego publicznym repozytorium. I teraz tak, token ten pozwalał na pełen dostęp do repozytoriów hostowanych w ramach tej instancji GitHub Enterprise. Teraz dochodzimy tak naprawdę do sedna problemu, bo o ile to, że ten token wyciekł jest jedną sprawą, to drugą sprawą w kontekście higieny sekretów jest to, że w tych repozytoriach hostowanych na tej instancji GitHub Enterprise znaleziono, jak na ironię, kolejne sekrety, kolejne klucze API, kolejne klucze do popularnych usług chmurowych czy poświadczenia pozwalające uzyskać dostęp do baz danych. Token znalazł się w repozytorium tego pracownika pod koniec września ubiegłego roku, a został znaleziony przez badaczy 11 stycznia. Oczywiście cała akcja ze strony badaczy była koordynowana przez przez serwis TechCrunch i dopiero po tym jak faktycznie Mercedes odwołał, zabrał dostęp temu tokenowi do instancji GitHub Enterprise. to wszystko zostało upublicznione. I teraz tak, jakby Mercedes na samym końcu nie komentuje sprawy pod kątem tego, czy w ramach analizy postincydentalnej wykryto, że ten token w tym przedziale czasu, czyli mówimy tutaj końcówka września, początek stycznia, został wykorzystany przez atakujących, tego nie wiemy, zanim został tak naprawdę znaleziony przez badaczy. I mam tutaj, Andrzej, do Ciebie pytanie, ponieważ takie przeświadczenie, że nasze prywatne repozytoria w pewien sposób oddzielają nas, tworzą taką barierę i bezpieczną przestrzeń dla tego, co tam trzymamy. Czy w ramach swojej pracy jako konsultant spotykasz się z takimi argumentami, w których Ludzie mówią, ok, nawet jeżeli wypuszuję ten sekret, jeżeli on się znajdzie w zdalnym repozytorium, ale ono jest prywatne, to w zasadzie nic się nie stało.
Andrzej: Świetne pytanie, ja nawet popchnę to trochę dalej. Nie tylko nic się nie stało, ale generalnie kto by pushował sekret, albo jest podejście, kto by popełnił taki błąd, a nawet jeżeli już jest założenie, że no dobra, no dobra, faktycznie można było popełnić taki błąd, no ale co się tak naprawdę stanie, właśnie tak jak mówisz, skoro to jest repozytorium prywatne. My, jak dobrze wiemy, sporo rzeczy może się wydarzyć, natomiast ja chciałbym tutaj słuchaczom jeszcze raz jasno nadmienić przypadek, o którym mówisz, bo ty go świetnie rozumiesz, ja go też świetnie rozumiem, ale wydaje mi się, że odbiorca, szczególnie jeżeli pierwszy raz słyszy o problemie sekretów, to może mu tutaj umknąć to sedno problemu. W tym konkretnym przypadku sednem problemu nie jest sytuacja, w której zostało upublicznione repozytorium samego Mercedesa i w nim był kluczyk. To jest taki standardowy przypadek, gdzie to repozytorium firmy jest w jakiś sposób upublicznione i w tym repozytorium pojawia się sekret, który końcem końców wylatuje do przestrzeni publicznej. To jest taki najbardziej typowy przypadek. Swoją drogą wiem, że rynek, programiści często gęsto nawet ten kawałek niejako trochę ignorują albo nie są świadomi tego zagrożenia, ale tutaj mamy inny przypadek. Tutaj mamy trochę bardziej skomplikowany przypadek, ponieważ ten sekret nie wyszedł przez repozytorium samego Mercedesa. Sekret należał do Mercedesa. ale on wyciekł poprzez prywatne konto githubowe pracownika Mercedesa. Tak jak tam nadmieniłeś ten sekret, w jaki sposób się tam pojawił? Czy ten pracownik być może omyłkowo dodał ten sekret do swojego projektu, albo zrobił to umyślnie, bo musiał na przykład coś w jakiś szybki sposób, będąc w domu, zdiagnozować, zdebugować, więc potrzebował dostęp do jakiegoś serwisu. Trudno powiedzieć tutaj takiej wariacji, w jaki sposób to się wydarzyło. Można sobie mnożyć tych sposobów, na pomyłkę jest wiele, ale warto zauważyć, że to jest osobny przypadek od tego pierwszego, czyli od upublicznienia samego repozytorium Mercedesa. Tutaj to repozytorium należało do pracownika Mercedesa, było jego jakimś prywatnym, ale w sensie moim osobistym kontem na GitHubie, a nie czymś, co należało do Mercedesa. To, co należało do Mercedesa, to był ten sekret. I te dwa przypadki należy rozgraniczyć, ponieważ istnieją narzędzia, Notabene, o ile dobrze kojarzę, to nawet są spięte z GitHubem. Istnieją narzędzia, które rozwiązują dokładnie ten problem, czyli które szukają klientów korporacyjnych po to, żeby szukać sekretów tych klientów korporacyjnych w repozytoriach osobistych ich pracowników. I taką firmą jest GitGuardian. I tutaj notabene dodam, że Ja też kiedyś nie do końca rozumiałem różnicy pomiędzy jednym i drugim, natomiast na reddicie, o ile dobrze pamiętam, kiedyś się wypowiedziałem właśnie w wątku odnośnie sekretów i odnośnie startupu GitGuardian i sam founder GitGuardiana do mnie podbił i mi wytłumaczył, że a, ale Andrzej tutaj nie do końca, to nie jest tak, my rozwiązujemy trochę inny problem, I jak mi to wytłumaczył, to powiedział, że faktycznie to jest zupełnie inny problem i jak najbardziej ma to taki biznes case. Więc odpowiadając trochę szeroko na twoje pytanie, z mojej praktyki niestety ten ogólny problem sekretów w repozytorach, pomimo tego, że jest rozpoznawalny jako nie powinniśmy mieć sekretów w plikach konfiguracyjnych, to jest to widziane bardziej jako zła praktyka inżynieryjna, a nie jako coś, co ma jakieś implikacje związane z bezpieczeństwem, no bo często gęsto jest założenie, że skoro repozytorium jest prywatne, to w takim wypadku nie ma problemu. A jak wiemy, to akurat nie jest. niestety Nie można tego w taki prosty sposób zaakceptować, bo każde repozytorium, które jest prywatne, nic nie stoi na przeszkodzie, żeby prędzej czy później stało się publiczne. No a wtedy zaczyna być to problem, no bo git niejako z założenia samego business case’u zapamiętuje historię, więc można pójść wstecz, wstecz, wstecz i po prostu popatrzeć, co tam kiedyś było. No to sytuacja pod kątem sekretów nie jest najlepsza, natomiast faktycznie to, co tutaj powiedzieliście odnośnie Mercedesa, ta ciekawość tego, że to wyszło przez pracownika, to jest dla mnie mega ciekawe i pamiętam, że wrzuciłeś to na LinkedIna i już wtedy sobie myślałem, o kurczę, ale super przypadek, będę miał na szkolenia, żeby pokazywać. taki real case scenariu, bo co innego jeżeli ja powiem o jakimś teoretycznym ataku, teoretycznym wycieku, a co innego jeżeli mam konkretny przykład, o patrzcie tutaj, tutaj się stało dokładnie to, tutaj dokładnie ten scenariusz się zmaterializował.
Krzysztof: Tak, fajnie, że można się podpierać, znaczy fajnie i niefajnie, zależy z jakiej perspektywy mówimy, ale z punktu widzenia ludzi, którzy przygotowują programistów pod kątem wytwarzania, bezpiecznie oprogramowania, to taki przykład jest taki hands-on, tak, no faktycznie to się wydarzyło, to nie są bajki z mchu i paproci, a tutaj w kontekście sekretów, przechodząc, odbijając piłeczkę w trochę inny kąt BMW. Bo, tak jak powiedziałem na samym początku, w tym samym miesiącu BMW mówiąc trochę ironicznie, nie chciało być gorsze, no i też doszło do incydentu, co prawda nie w lutym, ale w lutym został on upubliczniony, więc znowu badacze bezpieczeństwa z firmy tym razem Sockradar znalazł, badacz ten znalazł niepoprawnie skonfigurowany kubełek na ażurze, to chyba jest kubełek na ażurze, ja z ażurem nie mam zbyt dużego doświadczenia, tam chyba to się nazywa blob storage, ale wszyscy wiedzą, o co chodzi. więc ten kubełek był niepoprawnie skonfigurowany i pozwalał na publiczny dostęp. I w tym kubełku znaleziono pliki, w których znajdowały się poświadczenia m.in. do baz danych dla środowisk deweloperskich oraz produkcyjnych, dane uwierzytelniające pozwalające na dostęp do innych usług np. takich jak Azure Docker, czy klucze pozwalające na dostęp do prywatnych kubełków w ramach ażura. Nie udało się oszacować w ramach analizy przez jaki czas ten blob storage był publiczny i możliwy do infiltrowania potencjalnie przez atakujących. BMW w oświadczeniu całkowicie się odcina, mówi, że w zasadzie żadne dane klientów w wyniku tego incydentu nie zostały naruszone, ale ja bym chciał tutaj podkreślić, że tutaj mamy Problem, na który patrzymy z troszeczkę innego kąta, bo tu nie mówimy o repozytoriach, mówimy o kubełkach, mówimy o naszych storage’ach w cloudzie, o naszych przestrzeniach, gdzie przechowujemy pliki w cloudzie, to jest całkowicie nowa powierzchnia ataku, która często bywa zapomniana, pozostawiona troszeczkę sama sobie i w której też pchamy rzeczy, które nie najlepiej tam pasują, no między innymi sekrety. I teraz jeżeli pomyślelibyśmy sobie o tym, że definiujemy takie zasoby właśnie jak kubełek na S3 czy kubełek na ażurze jako infrastructure as a code, no to taki problem, w którym ten kubełek jest publiczny, możemy bardzo łatwo wyłapać z samej definicji takiego zasobu, deklarując go jako Infrastructure as a Code. To jest jedna kwestia, definiowanie tego typu zasobów właśnie zarządzając nimi poprzez kod, a druga kwestia jest taka, że te przestrzenie, ten storage w cloudzie też możemy regularnie, periodycznie skanować pod kątem sekretów. Są narzędzia, które na to pozwalają, pierwszy z brzegu, Travelhawk, o ile dobrze kojarzę, już wspiera skanowanie zarówno tego, co jest na GCP, tego, co jest na AWS i tych blob storage’ów na Azure, także to też jest miejsce, o które powinniśmy z pewnością zadbać, jeżeli chodzi o higienę i bezpieczeństwo naszych sekretów.
Andrzej: Wiesz co, ja tutaj mam jeszcze jedno pytanie do tego poprzedniego case’u. Oczywiście twoja uwaga o tym, że BMW chciał dorównać Mercedesowi. Jak to zwykle BMW jest, no powiedzmy w jakiejś percepcji, ogółu stoi trochę niżej niż Mercedes, więc jak Mercedes coś wypuszcza, to BMW chce dorównać, no to Mercedes miał wyciek, no to BMW nie mogło być gorsza. Też ma wyciek. Ale żarty na bok, bo co do samego Mercedesa… Jeszcze naszło mnie jedno pytanie. Może będziesz miał jakąś swoją teorię, co się zadziało. Natomiast ja wiem, że w GitHubie są funkcjonalności, już pomijam GitGuardiana, ale są wbudowane funkcjonalności, które skanują to, co wrzucamy do repozytorium pod kątem sekretów. I moje pytanie jest, jak to się wydarzyło, że to nie zostało wykryte, że takie narzędzie tego nie wykryło? No bo GitHub jednak te funkcjonalności posiada, on posiada kilka funkcjonalności, ale jedna z nich potrafi jasno powiedzieć, że o tutaj mamy sekret i coś powinniśmy z nim zrobić. To jak sądzisz, co tutaj mogło pójść? nie tak?
Krzysztof: Teorie są dwie, nic nigdzie nie było tak naprawdę oficjalnie stwierdzone, ale ciekawostka jest taka, że to co mamy w ramach instancji GitHub Enterprise, kiedy kupujemy licencję na GitHub w wersji właśnie Enterprise, nie zawiera w sobie pakietu advanced security. Ten Advanced Security Package to jest dodatkowy perk, który możemy dokupić dodatkowo do Enterprise’a, a skanowanie sekretów jako feature, jako funkcjonalność, którą GitHub udostępnia, znajduje się właśnie, jeżeli chodzi o prywatne repozytoria, znajduje się właśnie w tym pakiecie Advanced Security, Moja teoria jest taka, że może tylko Advanced Security nie mieli, albo po prostu ta funkcjonalność nie była włączona, tak?
Andrzej: Ok, nie wiem, ale się domyślam, która z opcji była tutaj tą poprawną odpowiedzią. I jeszcze może nie tyle, może nie tyle pytań, ale komentarz mam do tego case’u, a może też do dwóch. Natomiast do tego case’u na pewno. To, co mi się podoba, jedną z rzeczy, która mi się podoba w firmach technologicznych, szczególnie tych z Silicon Valley, to to, że jeżeli jest fuck up, to często gęsto jest faktyczne post mortem upublicznione, nie tylko wewnątrz organizacji, że ludzie, inżynierzy wewnątrz organizacji mogą się dowiedzieć, co faktycznie poszło nie tak, po to, żeby uniknąć tego w przyszłości, ale też jest to upublicznione dla szerszej publiki, więc szersza publika po pierwsze może lepiej zrozumieć, jak doszło do tego problemu, Powiedzmy, że niesmak pozostanie, ale jest trochę mniej tej goryczy, bo bardziej zrozumiem tę drugą stronę, jeżeli dostanę jakieś wytłumaczenie. A dwa, że od strony takiej czysto inżynieryjnej, projektowania, działania, bycia proaktywnym, można po prostu uczyć się na czyichś błędach. Więc jeżeli już popełniliśmy błąd, to dobrze byłoby się podzielić postmortem i powiedzieć, jak do tego doszło i co będziemy robić w przyszłości, co chcemy zrobić w przyszłości, żeby nie popełnić tego samego błędu. No i otworzyć się też na szerszą publikę, bo szersza publika też może nam podać jakieś ciekawe rozwiązania albo wziąć nasze rozwiązanie. I to mi się bardzo podoba w firmach technologicznych, że od tego nie uciekają. Natomiast w takich, no powiedzmy Mercedes czy BMW było firmą technologiczną, ale bardziej 100 lat temu. Bardziej w takich, teraz to już jest po prostu firma produkcyjna, która już nie jest powiedzmy cutting edge i taka firma No niestety, jak widać, niechętnie upublicznia jasne postmortem, które odpowiada na takie dość podstawowe pytania, czyli jak faktycznie doszło do tego problemu. Tak jak tam wspomniałeś, nie było nawet opisane, czy był jakiś dostęp przez ten token, czy nie było. Takie rzeczy, wydaje mi się, powinny być opisane w momencie, gdy coś takiego się dzieje. Nie chcę powiedzieć, że powinno być to wymagane prawnie, bo ja generalnie jestem przeciwko odgórnym regulacjom. No ale jak widać, jeżeli tych regulacji nie ma, to vendorzy, ale nie tylko vendorzy, tylko manufakturerzy, generalnie organizacje firmy, raczej nie chcą się takimi informacjami dzielić. I znowu, nie wiem, choć się domyślam, dlaczego. Bo zakładam, że po prostu wyglądałoby to gorzej niż nam się wydaje.
Krzysztof: Tak, no niestety, jednozdaniowe komunikaty w biurach prasowych, a szkoda, bo nie żyjemy już w tych czasach, w których ktoś wytyka palcem przynajmniej większość profesjonalistów i mówi, haha, ale frajerzy, zobaczcie, nie? Więc tak.
Andrzej: Tak, wydaje mi się, że te czasy są już za nami. Dobra, teraz przejdziemy do mojego znaleziska. Moje znalezisko dotyczy czegoś, o czym pewnie słyszałeś. W zasadzie wydaje mi się, że każdy, kto pracuje w bezpieczeństwie, o tym słyszał. Chociaż nie każdy musi trzymać tak mocną rękę na pulsie, żeby aż głęboko wchodzić w to, o czym powiem. Mianowicie w zeszłym miesiącu, w lutym, została wypuszczona najnowsza lista top 10 technik hakowania web aplikacji z poprzedniego roku, z minionego roku, z roku 2023. I nie chodzi mi tutaj o OWASP Top 10, to jest zupełnie co innego. Chodzi mi o listę technik atakowania web aplikacji wypuszczaną przez firmę Portswigger. Przez firmę, która tworzy takie dość popularne narzędzie Burp, Burp Intruder. Każdy pentester będzie je kojarzył. I od paru lat Portswiger wypuszcza takie zestawienia różnych badań odnośnie ataku bezpieczeństwa web aplikacji z poprzedniego roku i zwyczajowo dzieje się to właśnie w lutym. i w tym roku dostaliśmy kolejną nową listę. Całość tej listy dla mnie jest pewnego rodzaju ciekawostką. Wydaje mi się, że dla naszego standardowego odbiorcy też raczej pozostanie to w sferze jakiejś takiej ciekawostki niż czegoś, w co naprawdę trzeba wchodzić. Zaraz wytłumaczę dlaczego. pozostaje pewnego rodzaju ciekawostką, bo owszem, są tam zaprezentowane, bardzo zaawansowane ataki na web-aplikacje. No właśnie, ale one są często, gęsto naprawdę bardzo zaawansowane. i o ile pentesterzy zyskują faktycznie, jeżeli się obracają i wiedzą, trzymają rękę na pulsie i faktycznie znają najnowsze sposoby atakowania web aplikacji. Szczególnie ten tester, który chce iść w kierunku rozwoju, w red teamingu, w takim ofensywnym cyberbezpieczeństwie, w faktycznie atakowaniu web aplikacji nowych, nowych organizacji up-to-date technologicznych, to faktycznie ma to sens, ale typowy tester bezpieczeństwa, który raczej przykładowo chce iść w kierunku bezpieczeństwa aplikacji, to taka osoba niekoniecznie musi znać bardzo skomplikowane ataki nowych aplikacji z prostej przyczyny. Typowa web aplikacja ma dużo więcej niskowiszących problemów bezpieczeństwa niż przykładowo HTTP Testing czy Request Smuggling. To są takie bardzo ezoteryczne ataki, które owszem są bardzo ciekawe na poziomie technicznym. Często mogą dotykać web aplikacje, ale Jak wszystko w cyberbezpieczeństwie jest to pewnego rodzaju prawdopodobieństwo i prawdopodobieństwo eksploitacji jakiejś nisko wiszącej podatności, takiej jak XSS, czy przykładowo problemy z dostępem do z dostępem do różnych obiektów w obrębie web aplikacji czy systemu IT. Te problemy są po prostu dużo częściej spotykane i należałoby najpierw wyeliminować to, co wisi nisko, a dopiero potem ewentualnie brać się za coś, wisi wyżej, raz, że wisi wyżej, a dwa, przez to, że wisi wyżej, no niejako wymaga większej umiejętności od osoby, która miałaby to wykorzystać, która miałaby to wyeksploitować. Dodatkowo jeszcze są dwa fakty, które chciałbym tutaj wymienić. Pierwszy fakt to jest to, że kilka z tych pozycji, które zostały wylistowane, ja nie będę przechodził przez wszystkie, natomiast kilka z nich tak naprawdę zamyka się w obrębie takiej jednej szerszej klasy problemów. I to nie tylko w tej liście. W listach z lat poprzednich podobnie, jest bardzo podobna sytuacja. I ta klasa problemów to problem związany z różnicami pomiędzy parserami. Czyli przykładowo mam webaplikację, która korzysta z jednego parsera. To może być dla uproszczenia w jakimś stosie technologicznym. Przykładowo mam webaplikację napisaną w Ruby on Rails i korzystam sobie z parsera JSON. I następnie ta aplikacja przetwarza tego JSON, a potem go wysyła do innego mikroserwisu, który jest napisany w Pythonie. I tam już używam Flask. I różnice pomiędzy parsowaniem tych plików czyli implementacją tych dwóch osobnych parserów w jednym staku technologicznym i drugim staku technologicznym, czasami pozwalają na ciekawe problemy na poziomie implementacyjnym, ale też dużo częściej na poziomie logicznym. Przykładowo jedna implementacja coś zostawi albo coś pominie, a druga implementacja będzie tego oczekiwać. No i mogą wtedy pojawić się problemy. I takich problemów pomiędzy rozjazdem, pomiędzy jednym parserem, a drugim parserem jest całkiem sporo w ostatnich latach, właśnie w bezpieczeństwie web-aplikacji i szczególnie właśnie na tej liście top 10 web hacking techniques od Port Swigera. Praktycznie co roku się powtarza przynajmniej jedna, ale najczęściej dwie, trzy pozycje są właśnie wokół tej szerszej krasy problemów. To jeden komentarz, więc jeżeli ktoś chciałby zrobić badanie, chciałby znaleźć coś ciekawego, to powinien przyjrzeć się różnicom pomiędzy parserami na różnych kawałkach web aplikacji, ale też ogólnej infrastruktury. To jest jedna uwaga, a druga to, że w tym roku, podobnie chyba jak w poprzednim, bo w poprzednim chyba też mieliśmy Polaka na liście. Jedna technika była wprowadzona, była opracowana przez Polaka, w tym roku też mamy, przez Piotra Bazydło. Piotrek pracuje w ZDI, czyli Zero Day Initiative. To jest taka inicjatywa, która skupuje Zero Day’e z rynku. Oni też tworzą takie dość, nazwijmy to, igrzyska w hakowaniu aplikacji, które się nazywają Pwn2Own. Chyba są dwie instacje rocznie. No i fajnie, gratulacje dla Piotrka, że znalazł, że opracował ciekawą technikę hakowania, deserializacji w ekosystemie .NET. I po prostu zawsze miło się robi na serduszku, jak widzę jakiś polski akcent w różnego rodzaju takich opracowaniach wysokiego kalibru, bo jednak ta lista jest naprawdę wysokiego kalibru. Te problemy, które tam są, są bardzo ciekawe, tylko po prostu raczej są kierowane do bardzo wąskiego grona mocnych specjalistów, którzy chcą jeszcze mocniej się specjalizować konkretnie w jakichś ofensywnych działaniach. I powiedz mi, bo teraz mam pytanie ja do Ciebie, Krzysztofie, powiedz mi, zakładam, że widziałeś, że ta lista została upubliczniona, przyglądałeś się jej trochę mocniej w tym roku, czy raczej potraktowałeś to jako pewnego rodzaju ciekawostkę, rzuciłeś okiem i poszedłeś dalej rozwiązywać faktyczne problemy bezpieczeństwa?
Krzysztof: Będąc całkowicie szczerym, to rzuciłem na nią po prostu okiem z lotu ptaka, nie wchodziłem głębiej w te techniki eksploitacji tych podatności, bo one są, tak jak sam wspomniałeś, po prostu ezoteryczne. Tych problemów związanych z nisko wiszącymi owocami jest dużo, dużo więcej. Skupiając się na tym tak naprawdę, próbując wyeksploitować to w projekcie, tak naprawdę mogę przepalić dziesiątki godzin na tym, żeby szukać tego, co jest napisane na tej liście, co nie znaczy, że to są naprawdę całkiem ciekawe, fajne, wartościowe, na pewno wartościowe researche. którymi po prostu warto się zapoznać, ale nie poświęcając temu więcej czasu niż na zwykłe zapoznanie się z tym, czy czytanie tego. Dla Piotrka gratulacje. I tutaj jedna moja uwaga, komentarz bardziej. Ja zauważyłem, że ta lista ma to do siebie, że część z tych problemów wydaje się jakby być odkopana z przeszłości. Zwróć Andrzej uwagę na przykład na SMTP smuggling, tak? To jest nic innego jak po prostu przejście na inny protokół, kilka lat temu Fruere robił Http smuggling, który też został odkopany z przeszłości, więc ja widzę tutaj taki pattern, wzorzec, że oni bardzo mocno autorzy, researcherzy z BIRP-a bardzo często sięgają w przeszłość i opracowują te problemy na nowo, być może w nowym kontekście, w nowych stosach technologicznych. nabierają one na znaczeniu, więc tutaj taka jedna moja uwaga. A druga, co powiedziałaś o różnicach w parserach, to tylko takie zajawie, bardzo ciekawy research, który od zawsze chodził mi po głowie od samego początku, od kiedy wchodziłem w bezpieczeństwo, to jest research takiego kolesia, który nazywa się, albo to jest jego pseudonim, Orange, Orange Tsai, i miał świetną prelekcję bodajże na Defconie albo na Black Hatcie dotyczącą różnic w parsowaniu adresów URL. w różnych bibliotekach, w różnych paczkach, w różnych stosach technologicznych. I tam ta prelekcja dotyczyła konkretnie tego, jak można te różnice wykorzystać w kontekście ataków server-side request forgery. Także to też było mega spoko.
Andrzej: Tak, konkretnie papierek się nazywa A New Era of SSRF Attacks. Był prezentowany, wydaje mi się, że faktycznie na plakacie chyba. Nie jestem pewien, czy nawet nie był prezentowany na obu. Natomiast Orange Tsai to jest wysokiego kalibru researcher. To, co wypuszcza, zawsze jest bardzo dobrej jakości. Ale to, tym papierku, o którym teraz wspomniałeś, o tym badaniu, o tym researchu, ono jest też bardzo dobrze opisane. tak naprawdę jak się słucha, jak się czyta, to jest to bardzo takie zrozumiałe. Jest takie przejście od A do B, od B do C, od C do D. Wszystko ma swój jakiś logiczny ciąg. Nie ma tam takich dziur pozostawionych dla odbiorcy, że ja muszę się czegoś domyślić, żeby przeskoczyć na kolejny poziom zrozumienia tego, o czym teraz autor mówi. Nie, nie ma czegoś takiego tam. Więc jest to nie tylko bardzo ciekawy research, ale również jest po prostu dobrze opisany przez tego badacza, jest to zrozumiałe nawet dla ludzi, którzy nie mają jakiegoś super doświadczenia z bezpieczeństwem. Wystarczy podstawowe doświadczenie po prostu z programowaniem i z używaniem pewnych parserów w swojej codziennej pracy. Więc to badanie naprawdę jest… Jak już zacząłeś mówić, to od razu mi do głowy przyszło, że zaraz będzie Orange Tsai ze swoimi parserami Urly. Tak, tak, tak, to było świetne badanie. I tak jak powiedziałeś, ja też tutaj dopowiem jeszcze swój komentarz, od którego trochę zacząłem. Mianowicie, tak, te ataki są ezoteryczne. Osoby związane z ofensywnym testowaniem bezpieczeństwa web-aplikacji, dobrze, żeby wiedziały, co w trawie piszczy, ale o ile nie jesteśmy naprawdę mocno tym zajarani i nie chce mieć mocno, mocno specjalizacji związaną z no już nawet testami penetracyjnymi i red teamingiem, to w zasadzie jest to taka ciekawostka. Ja też nie wchodziłem mocno w szczegóły, przynajmniej na ten moment, a nawet jak w niektóre wchodziłem w poprzednich latach mocniej w szczegóły w tych podatności, to raczej od takiej strony chętnie się dowiem, co tam poszło. nie tak, od takiej zaspokojenia ciekawości, a nie, że będę testował pod tym kątem web-aplikacji, dlatego że niskowyszących poziomów jest dużo, dużo, dużo więcej i niestety najpierw trzeba wyeliminować te wszystkie problemy, a dopiero potem można się skupiać na czymś, co jest mega, mega zaawansowane. i raczej jest to taka ciekawostka, nazwijmy to pewnego rodzaju nie tyle zagadka, ale jest to pewnego rodzaju challenge intelektualny, żeby zrozumieć, jak działa dany atak, niż coś, co faktycznie potem będzie się wykorzystywać w swojej day-to-day work, bo raczej tego nie będziemy robić. Jest to bardzo ograniczony wycinek i będę szczery, Przeciętnemu słuchaczowi naszego podcastu raczej odradzam tracenie czasu na wchodzenie mocno szczegółowo w poszczególne ataki, po prostu nie ma to za bardzo sensu. Jest zbyt mały gain, a zbyt dużo czasu się poświęci. I wydaje mi się, że w ostatniej analizie dynamicznej. też wspomnieliśmy o tym, że patrząc wstecz, analizując różnego rodzaju ataki, które były w historii, można znaleźć kolejne, nazwijmy to, instancje w nowych stosach technologicznych. I tak jak powiedziałeś, to jest świetny kierunek. badań, on się pojawia na tej liście bardzo często i widać go tak naprawdę z roku na rok, no i nie bez powodu, bo to jest po prostu skuteczne. Obcina nam to ten kawałek, że musimy wymyślać koło na nowo. Nie, bierzemy problem, który kiedyś czegoś dotyczył, Zgłębiamy go i się zastanawiamy, czy być może uda nam się znaleźć jakąś jego nową instancję w systemach, które się pisze dzisiaj. Dobrze. No to w zasadzie tyle o technikach hackowania w aplikacji top 10 z zeszłego roku. I możemy wskoczyć w twoje kolejne znalezisko. To będzie na czasie. Będzie na czasie, jedziesz.
Krzysztof: Tak, jak wszystko, co jest związane z dużymi modelami językowymi. Więc w lutym wyszedł bardzo ciekawy papierek, w którym badacze opisują swój eksperyment, w którym porównano kilka dużych modeli językowych. Ja tutaj od razu streszczę, bo nie ma to tutaj większego sensu, że najlepszy w tym całym badaniu był GPT-4. Chodziło o to, że Postanowiono sprawdzić, jak radzą sobie duże modele językowe, tak jak powiedziałem, jak radzi sobie GPT-4 w hakowaniu aplikacji webowych i czy jest w stanie zastąpić pentesterów, ludzi, którzy zajmują się testowaniem bezpieczeństwa aplikacji właśnie w tym kontekście webowym. Więc infrastruktura tam była opisana troszeczkę po łebkach i z tego, co udało mi się wyciągnąć z tego badania, to wyglądało to tak, że GPT-4 komunikował się z headlessową przeglądarką opartą o Chromium za pomocą takiego popularnego frameworka, który tutaj puszczam oczko w stronę wszystkich testerów i QA’ów, Playwright. To jest framework, który służy do tego, aby automatyzować czynności w przeglądarce, głównie w Chrome. No i GPT miał też, oprócz tego, że miał dostęp do tej instancji headlessowej przeglądarki, to miał też dostęp do powłoki, aby mieć dostęp do takich narzędzi jak CURL, żeby wysyłać requesty, czy dostęp do po prostu interpretera Pythona. i badacze nakarmili GPT-4 w tym eksperymencie, nakarmili go sześcioma dokumentami z publicznie dostępnych źródeł, które bardzo szeroko mówią o tym, w jaki sposób podchodzić do testowania bezpieczeństwa aplikacji webowych, czy mówiąc bardziej geeki, w jaki sposób hakować aplikacje webowe. Tutaj nie podano z jakich konkretnych źródeł korzystano, także tutaj puszczam oczko w stronę Maćka, który koordynuje OWASP Cheat Series. Nie wiadomo, czy Cheat Series Kube, tak? Dobrze mówię Kube?
Andrzej: Kuba, Kuba, Jakub, ale Maćkowski.
Krzysztof: Dokładnie, więc nie wiadomo, czy Cheat Series został wykorzystany do tego, żeby hackować strony za pomocą LLM-ów. Jeżeli chodzi o prompt, to tutaj też ten prompt, który został użyty, nie został upubliczniony z racji tego, aby nie kusić losu, ale jedyne, co tam badacze nam podają, to to, że w tym prompcie kierowali się takimi czterema zasadami. żeby agent był kreatywny, próbował różnych strategii, te strategie, które będą obiecujące rozwijać, a te strategie, które będą failowały, po prostu od razu zmieniać na inne. No i tak, ten cały eksperyment został przeprowadzony na sandboxowanej, odizolowanej od internetu aplikacji, takiej pełnoprawnej aplikacji, gdzie mieliśmy osobno napisany front-end, oczywiście back-end, no i gdzieś tam też z tyłu za tym wszystkim stała jakaś baza danych. Przetestowano 15 klas znanych podatności, także mieliśmy tutaj tak naprawdę cały wachlarz który gdzieś tam możemy znaleźć w popularnych dokumentach listujących podatności czy klasy problemów takich jak OWASP.ten, a tutaj tak naprawdę od XSS przez SQL injection po server-side request forgery. Co ciekawe, agent był w stanie wykonywać nawet bardzo złożone zadania wymagające ok. 40 kroków w przypadku np. ataków SQL injection i tylu kroków potrzebował, żeby ekstrachować całą schemę bazy, a następnie dane z poszczególnych tabel, ale kończyło się to sukcesem. Jeżeli chodzi o taki success rate, no to schodząc troszeczkę na prostszy poziom, w kontekście XSS-ów w pięciu próbach odnotowano skuteczność na poziomie 80%, czyli cztery próby były zakończone tym, że udało się wykorzystać XSS-a w tej aplikacji. Najmniejszy success rate z takich znanych podatności, o których nasi słuchacze może mieli okazję słyszeć, no to właśnie jest server-side weakest forgery, tutaj 20% na 5 prób. I tak, powiedziałem na początku, że postanowili sprawdzić, czy uda się zastąpić ludzi, tak, pentesterów, ludzi zajmujących się testowaniem aplikacji webowych pod kątem bezpieczeństwa. No i tak, średni koszt wykonania ataku przez takiego agenta, który wykorzystywał właśnie duży model językowy, w tym kontekście mówimy tutaj o GPT-4, wynosił trochę ponad cztery dolary za próbę, tak? Czyli domniemam, że tyle tych requestów, za tyle tych requestów zostali po prostu gdzieś tam pod spodem zcharge’owani. I przy ogólnej skuteczności Ataku, biorąc pod uwagę wszystkie te podatności, które oni tam testowali, na poziomie 42% całkowity koszt Ataku na jedną stronę internetową, jedną aplikację, bo oni to mówią o stronach internetowych, ale to są po prostu aplikacje Adobe, wynosił niecałe 10, niecałe 10 dolarów. I teraz tak, w podsumowaniu Jest stwierdzenie, że jeżeli średniorocznie taki Pentester zarabia 100 tys. dolarów, najprawdopodobniej to jest wartość wyciągnięta z amerykańskiego rynku, tak przypuszczam, bo badacze są ze Stanów Zjednoczonych, no to koszt takiego agenta, który właśnie opiera się o duży model językowy, będzie około 8 razy niższy, a tutaj oczywiście autorzy zaznaczają, że te szacunki są dosyć mocno przybliżone i nie mają na celu powodowania zamętu na rynku i masowego przechodzenia i zastąpiania ludzi właśnie poprzez takiego typu agenta.
Andrzej: Jasne. Ja mam tutaj pierwsze pytanie, a tych pytań to może mam nawet więcej, ale pierwsze można powiedzieć bardzo ważne. To w końcu LLM zastąpi Pentesterów czy nie? Bo ja słyszałem taką teorię, że Dust potrafi zastąpić Pentesterów, ale w praktyce to jakoś tego jeszcze nie widziałem. To może LLM zastąpi Pentesterów?
Krzysztof: Dobre pytanie. Oni tutaj też na samym końcu apelują o roztropność w upublicznianiu dużych modeli językowych do szerszej masy, więc może gdzieś z tyłu czyha taka obawa, że faktycznie może duże modele językowe będą w stanie zastąpić. Z mojej opinii, podkreślając, że nie jestem ekspertem od AI, czy mówiąc bardziej dokładnie od spraw związanych z uczeniem maszynowym, wydaje mi się, że przynajmniej w przypadku nisko wiszących owoców, podatności, które są relatywnie proste w eksploatacji, Elemy już mogą efektywnie nas wspierać czy zastąpić. Tutaj mam jeszcze pewne wątpliwości.
Andrzej: Tak, ja mam nawet bardzo duże wątpliwości, szczególnie biorąc pod uwagę, że o ile dobrze wyłapałem, to to badanie nie posiadało… Badacze nie udostępnili, jasno, aplikacji, web-aplikacji kodowych i podatności, więc co innego? znaleźć podatności w den vulnerable web application napisanej w PHP, gdzie tak naprawdę jest okno dialogowe i trzeba tam… Jak mamy input, jak tam wbijemy najbardziej podstawowy payload XSS, to voilà, już mamy podatność. A co innego? znaleźć się w aplikacji, gdzie to nie będzie podane na tacy, tylko faktycznie będzie trzeba przejść pewną jakąś interakcję z systemem, żeby dojść w ogóle do ścieżki, która może posiadać podatność i jeszcze potem to wykryć i popchnąć dalej, jeżeli mówimy przykładowo o SQL Injection. badania, w których metodyka, metodologia, to co było badane, na czym było badane, nie jest udostępniane, to dla mnie to już jest takie aha, czyli chcesz coś przede mną ukryć. Bo gdybyś nie chciał, to byś mi to po prostu wszystko dał. Ja mógłbym sobie je, mógłbym sobie to tworzyć. Mam takie bardzo mocne spojrzenie na badania, że tak naprawdę to, co jest podstawą, Moja opinia jest pochodną opinii Baladżygo Srinivasana, gdzie Baladży twierdzi, że podstawą nauki, jako nauki science, jest replication. Albo jestem w stanie zreplikować to, co mówisz, że odkryłeś, albo nie jestem. Jak nie jestem, to twoje badania są mało warte, dyplomatycznie to ujmując. I więc jeżeli nie chcesz czegoś udostępnić, bo ja nie mogę tego zreplikować, no to twoje badania można wrzucić między bajki. Stąd, no, przeczytałem, też mi się gdzieś tam przewinęło to badanie przez oczy, rzuciłem na to okiem, wiadomo, przeskanowałem abstrakt i już przeczytałem, już miałem oczy, o czym tam było. Ale teraz jak to wyjaśniłeś, to jeszcze bardziej podchodzę do tego sceptycznie. Po prostu sceptycznie. Jeżeli ktoś coś przede mną ukrywa, to to nie jest dobrze. To na pewno o czymś dobrym nie świadczy. No i jeżeli jeszcze mówi takie bajki typu, no trzeba roztropnić, podchodzić do LLM-ów, bo nam skakują światy. Tutaj też się nie zgadzam. Biorąc pod uwagę, że jestem ekspertem domenowym w cyberbezpieczeństwie, to nie zgadzam się z wizją Chamafa Palihapatiya, który się udzielał w zeszłym roku w swoim podcaście All In. Tam jest czterech gości, omawiają z tego dnia na tydzień pewne rzeczy w technologii, no i wtedy poruszali właśnie temat AI-ów, LLM-ów. I czamaw był zdania, że taki LLM jest w stanie znaleźć Zero Day’e, a potem jeszcze napisać na nie exploit. No takie pierdoły to może opowiadać osoba, która w życiu nie znalazła Zero Day’a i nie napisała na niego exploita. Bo jakby to zrobiła, to wiedziałaby, że to nie jest taka trywialna sprawa i LLM, przynajmniej jeszcze na chwilę obecną, tego nie zrobi. W zasadzie żaden automat tego nie zrobi. Wydaje mi się, że jeszcze przez jakiś czas możemy spać spokojnie, można włożyć pomiędzy bajki. Natomiast można tego na pewno używać jako pewnego rodzaju kompaniona, jako pewnego rodzaju asystenta przy szukaniu bezpieczeństwa, czy w web aplikacjach, czy w jakichkolwiek aplikacjach. Więc na pewno można używać tego jako asystenta. ale żeby po prostu puścić taki system i odkrywać i jeszcze eksploatować podatności, to podchodzę do tego mocno, mocno sceptycznie i jestem zdania Jestem zdania proof of concept or get the fuck off. Więc po co or get the fuck off? Bo inaczej się po prostu do tego nie da podejść. Tym bardziej, że kojarzę różnego rodzaju akcje takie jak DARPA Cyber Challenge. Nie, to miało jakąś inną nazwę, no to już lata temu. Dziesięć lat temu, to 2014, gdzie właśnie między innymi premis był taki, że firmy fazowały zestaw aplikacji, a potem miały automatycznie napisać exploity, mówimy o niskopoziomowych aplikacjach napisanych w CC++, a potem miały automatycznie wygenerować exploity i schakować dany system. No i oczywiście kilka, kilka dużych vendorów usług bezpieczeństwa stanęło do tego, do tego challenge’u lata temu. Wiadomo, ktoś tam wygrał, ale te systemy nie były takie, że puścimy go na Windowsa i on tam nam pisze nam, eksploita na Zero Day w Windowsie, sam go zhakuje i jeszcze wszystko będzie działać. Jeszcze nam tam implant wstawi i sam system się jeszcze nie posypie. To są tak skomplikowane kawałki, że no… Tak jak mówię, jestem w stanie w to uwierzyć, ale musiałbym zobaczyć proof of concept, a nie tylko teorię, bo w teorii to wiele rzeczy może być, a nie chodzi o może być, tylko prawdopodobieństwo tego bycia i tylko proof of concept jest w stanie zwiększyć to prawdopodobieństwo albo je zobrazować. Natomiast samo takie gadanie i jeszcze nie pokazywanie technikaliów swojego researchu dla mnie to jest taki duży, duży, duży. Więc ten news ja osobiście wsadzę trochę między bajki.
Krzysztof: No tak jak mówisz Andrzej, tutaj faktycznie gdybyśmy mieli do czynienia z aplikacją, która, taką prawdziwie produkcyjną aplikacją, gdzie tych elementów jest więcej niż trzy, czyli frontend, backend i baza danych, tylko pojawiłby się jeszcze może jakiś Redis, może coś do kolejkowania, jakiś Rabbit i tak dalej, jakieś mikroserwisy, które gdzieś tam orbitowałyby dookoła tego API, tego backendu, to okej, faktycznie i wtedy puścić i sprawdzić jaki jest koszt takiego LLM-a, jak szybko udałoby mu się coś w takim systemie znaleźć, a tutaj mamy jednak dosyć sterylne warunki. Zakładam, że to było po prostu jakieś okno dialogowe, które reflektowało wartość.
Andrzej: Exactly. Tym bardziej, jeżeli miałbym system, który faktycznie potrafi znajdować podatności i jeszcze je eksploitować, czyli miałbym już system, miałbym już tego LNM-u, miałbym to spięte, to bardzo łatwo jest podstawić mu inny target, pokazać mu, wskazać mu inną web-aplikację. No to co, nie zrobiłbyś tego? No oczywiście, że byś to zrobił. Ale efekty pewnie będą pozostawiały wiele do życzenia, więc nie chciałbyś się tym podzielić, bo niejako zaprzeczyłbyś swojej tezie, że LLM-y faktycznie potrafią hakować web-aplikacje. Więc po prostu nie zrobisz tego, bo sobie sam strzelisz w kolaną, więc pokażesz tylko to, co jest wyrównane z twoją odgórnie przyjętą tezą, że LLM-y mogą hakować web-aplikacje. co oczywiście gdzieś tam wynika z natury ludzkiej, jeżeli poświęciłem x czasu na wykonanie jakiegoś badania. No to potem nie chcę pokazać, że mi nie wyszło, co oczywiście jest trochę dziwne, bo to nie jest, że nie wyszło w nauce. Większość rzeczy nie wychodzi. Naprawdę o to w tym chodzi, żeby zweryfikować, że coś nie działa. To, co działa i to, co jest faktycznym jakimś odkryciem przełomowym, a nawet nie przełomowym, ale małą cegiełką, która jest odkryciem, czyli coś, co działa, tego jest dużo mniej. Natomiast eksperymenty, które nie działają, też oczywiście mają bardzo dużą wartość. I teraz od razu mi do głowy przychodzi taki eksperyment, kurczę, teraz nie pamiętam nazwy, ale był taki gościu, który jeszcze przed upublicznieniem podatności w procesorach Intela w 2019 roku, bardzo popularny, Meltdown Spectre, to rok wcześniej, czyli 2018, o ile dobrze pamiętam, to był pierwszy kwartał, on wypuścił takiego blog posta, w którym opisywał nieudane eksperymenty właśnie odnośnie tego ataku. To był ktoś zupełnie inny od tych osób, które końcem końców odkryły i opisały Meltdown i Spectre. On był osobnym aktorem tutaj. Natomiast on upublicznił te swoje nieudane eksperymenty. Czyli miał takie przeczucie, że coś tu może być nie tak. Ale nie udało mu się tego popchnąć o krok dalej. Ale ci badacze wykorzystali te jego obserwacje. Więc pomimo tego, że jemu się to nie udało, to poprzez upublicznienie prawdziwego przebiegu wydarzeń. Po prostu mi się nie udało. Ale patrzcie, zrobiłem to, to, to, to. Nie udało mi się? Może wam się uda? Może wy będziecie wiedzieć coś, czego ja nie wiem? Może wam uda się zauważyć coś, czego mi się nie uda zauważyć? No to jak najbardziej ma sens. No i akurat to jest jeden z takich przypadków, gdzie faktycznie tak było. A potem, już po całym wypuszczeniu Spectre i Meltdown, O ile dobrze pamiętam, a pamięć mam dość dobrą, Joanna Rutkowska, taka znana polska badaczka niskopoziomowego bezpieczeństwa, też na Twitterze pisała, że oni, czyli Invisible Things Labs, jej firma, w której pracował m.in. Rafał Wojtczuk, ale też Aleksander Tereszkin, Obydwaj chyba już są zupełnie gdzie indziej, natomiast bardzo mocni gracze w bezpieczeństwie niskopoziomowym. No i ona napisała na Twitterze, że oni też patrzyli na to, patrzyli na ten rodzaj ataków. już praktycznie dziewięć lat wcześniej, bo oni patrzyli w okolicach 2010 roku, ale też im nie wyszło. Nie byli w stanie tego popchnąć dalej. I po prostu nie popchnęli. Ale też patrzyli w tym kierunku. Czyli np. wykonali, jeżeli byłaby to pewnego rodzaju ścieżka, to wykonali trzy kroki. No kurczę, nie widzieli, gdzie można pójść dalej, to się cofnęli i poszli dalej. Następnie przyszedł ten kolejny gościu, który wykonał pięć kroków, też nie widział dalej ścieżki, więc się cofnął. A potem przyszedł ktoś, kto miał świeże spojrzenie, kto być może miał więcej czasu, kto być może miał większą przestrzeń na tego typu działanie, bo to też była młodsza osoba. I on już przeszedł całą ścieżkę. Doszedł przez te pięć kroków, nagle zobaczył ścieżkę, jasną sobie wytyczył, przeszedł i on faktycznie odkrył tę podatność. udało mu się to zreprodukować. Natomiast to pokazuje, że jednak dzielenie się, tutaj zrobiłem taki mocny wywód, ale dzielenie się nawet rzeczami, które nam się nie udały, mogą mieć po pierwsze dla nas samych wartość, no bo ten autor, który wypuścił tego blogposta o tej porażce, końcem końcu wylądował pracując przy procesorach w Intelu, o ile dobrze pamiętam, został zatrudniony do pracy nad badaniami właśnie związanymi z podatnościami w procesorach. I gdyby nie to wszystko, no to prawdopodobnie jego historia podczułaby się inaczej, ale dla autora jest to na plus, ale szerzej… No użyję tego słowa szerzej, dla ludzkości też jest to mocno na plus, bo inni ludzie po prostu zauważyli coś, udało im się popnąć coś dalej. Przykładowo Joanna Rutkowska, Invisible Things Labs, o ile pamiętam, oni nie upubliczniły swoich badań wtedy w 2010. Też o ile dobrze kojarzę, to oni chyba robili to komercyjnie dla kogoś, więc to nie jest tak, że mogli sobie po prostu, nie mogli tego pewnie upublicznić. No ale gdyby upublicznili, to kto wie, może te podatności związane z procesorami mielibyśmy wtedy. Nie wiadomo, trudno jest powiedzieć. Natomiast dzielenie się nawet porażkami, których w życiu mamy więcej, może być nie tylko dla nas samych przydatne, ale też przede wszystkim może być przydatne dla wszystkich obserwatorów, którzy poświęcą czas na zgłębienie naszej porażki. Kurczę, ale osobnym audytorem przynajmniej.
Krzysztof: Bardzo się ciekawałem, że nie znałem tej całej historii tych smaczków stojących za meldedownem, więc dzięki. Nauczyłem się czegoś w ramach tej dygresji. Lecimy dalej.
Andrzej: Lecimy dalej, dygresja była mocna. Teraz dość krótko, jak będziesz miał komentarz, to dodaj go na koniec. Dla mnie jest to dość krótka historia, natomiast podoba mi się jedna rzecz w tej historii, na którą chciałbym zwrócić uwagę, bo ja zawsze na nią zwracam uwagę, jak tylko ją gdzieś zobaczę. Mianowicie w zeszłym miesiącu dość głośno się odbiło, nawet w polskim internecie, nawet w polskim cyberprzestrzeni, Ransomware, który się nazywa Lockbit, został niejako przejęty przez FBI i jeszcze jedną organizację w stylu FBI, tylko z Wielkiej Brytanii, nie pamiętam, jak to się u nich tam nazywa, ale generalnie został przejęty przez Nation State. I jak to się stało? Bo to jest ciekawe. Nie jest samo ciekawe to, że ten ransomware, lockbit został przejęty. Oczywiście to, powiedzmy, jest fajnie. Fajnie, że cyberprzestępcy stracili bramkę, a obrońcy zyskali ten punkt. To jest super. Natomiast w tej całej operacji, która nosi nazwę Kronos, mnie osobiście najbardziej zaciekawi sposób. albo przynajmniej domniemany sposób, w jaki sposób wydarzyło się to przejęcie tych serwerów, tych paneli administracyjnych Logbita. A mianowicie wydarzyło się to przez podatny interpreter PHP. I to jest dla mnie super ciekawe i jak tylko mam okazję, to staram się to zawsze, zawsze wypunktować. tutaj konkretnie podatny był interpreter, czyli podatność nie była w kodzie PHP, nie była w tej web-aplikacji napisanej w PHP, ale była o jeden poziom niżej, była w interpreterze PHP. Czyli tak naprawdę tutaj konkretnie podatność była w parsowaniu plików PHAR, to są archiwa PHPowe,
Krzysztof: Więc
Andrzej: parsując te archiwa, interpreter miał podatność, po prostu problem z obsługą pamięci, o ile dobrze pamiętam, to były jakieś buffer overflow plus jeszcze jedna, więc tam były dwie, dwa różne prymitywy, które można było strigerować. Natomiast generalnie chodzi o to, że podatny był interpreter PHP, a nie sam skrypt PHP, czyli tak jakby ci cybersbuje, że tak to nazwę, oni napisali web aplikację w sposób bezpieczny, ten panel był bezpieczny. ale przez to, że przetwarzał te pliki na podatnej instancji PHP, czyli używał podatnego interpretera PHP, a ta podatność to była podatność typu 0day, więc nikt o niej wcześniej nie wiedział, no to przez to, że używał tego podatnego interpretera PHP, po wgraniu tego pliku udało się BI wykonać kod w obrębie interpretera PHP, No i automatycznie wejść na system, a potem już skalować uprawnienia. Tego nie wiemy, jak to zrobili, natomiast przejęli końcem końców te maszyny, a tym punktem wejścia, tym inicjalnym wektorem była właśnie podatność w interpreterze PHP. Nie w samym skrypcie PHP, nie w tej web-aplikacji, tylko w interpreterze PHP. I dla mnie to jest mega ciekawe, Cały czas ze swojego doświadczenia wiem, że programiści często gestą nie mają do końca dobrego zrozumienia, gdy mówi się właśnie o tych podatnościach, które dotyczą tego, co jest niżej, tego, co wykonuje kod. To może być interpreter PHP, ale to równie dobrze może być wirtualna maszyna Java czy .NET. I niejako mieszają jedno z drugim. Jeżeli ktoś nie mając doświadczenia i mając wcześniejszego backgroundu, przeczytałby opis tej podatności, opis tego logbita, tej całej operacji Kronos, mógłby dojść do wniosku, że podatność była w PHP, w skrypcie PHP. A ona nie była w skrypcie PHP, ona była w tym interpreterze PHP. Trochę więcej o tym opowiem w pierwszym sezonie nowego podcastu, tam będę schodził do tych tematów, ale w tym konkretnym przypadku warto sobie to zanotować, że podatność może być na poziomie web-aplikacji, ale oczywiście może być też na poziomie tego, co wykonuje kod naszej web-aplikacji, i to jest najczęściej albo jakiegoś rodzaju interpreter, albo jakiegoś rodzaju wirtualną maszynę, jeżeli mówimy o Java czy .NET. Czy ty masz jakiś komentarz do tej sprawy, Krzysiek?
Krzysztof: Ja mam małe pytanko z małym komentarzem. Czy ty, Andrzej, słyszałeś… Historia jest zabawna i może jest zabawna dla naszych słuchaczy. Dlaczego najprawdopodobniej nieaktualizowana była tam wersja PHP na serwerze? Czy może słyszałeś tłumaczenie tego gościa? Nie słyszałem, nie słyszałem. Więc tłumaczenie było takie w luźnym tłumaczeniu, bo mam przed sobą teraz tą wiadomość, którą, tą notkę, którą napisał i opublikował, że 19 lutego zobaczył, że strona zwraca 502 bet gateway, no więc zrestartował NGINX-a, nic się nie zmieniło. Zrestartował MySQL-a, nic się nie zmieniło. Zrestartował procesy FPM-owe PHP-a, strona zadziałała. No i stwierdził, dobra, Nie będę się tym więcej zajmował, no bo przez te 5 lat jak operuję LockBeat stałem się na tyle leniwy pływając w pieniążkach i tak o tym piszę, że po prostu wróciłem na mój jacht i bawiłem się w luźnym tłumaczeniu z dziewczynami dalej, no a o 20.47 już jednak stwierdził, że może zajrzy Faktycznie, co się dzisiaj okazało się, że to FBI już powoli zawijało tam całą infrastrukturę, infrastrukturę Logbita. Co więcej, gościu, który zarządza tą, zarządza tą infrastrukturą mówi, że okej, teraz faktycznie już jestem trochę mniej leniwy i podbiłem wersję PHP do najnowszej, więc jeżeli znacie jakiegoś 0daya na najnowszego PHP, to przyjdźcie najpierw do mnie, ja wam za to zapłacę, żeby po prostu ta sytuacja się już w przyszłości nie po prostu nie ponowiła, nie?
Andrzej: Tutaj ja mam taki komentarz, że jeżeli już przeprowadzamy tego typu nazwijmy to operacje, to zawsze raczej z tyłu głowy powinniśmy mieć priorytety, jednak priorytetem powinna być nasza operacja, a nie jacht i dziewczynki, bo trzeba mieć jasny priorytet w życiu. I tutaj te priorytety się już trochę zamazały, coś tu się popsuło. To moja jedna uwaga, trochę taka śmieszki, heheszki, ale taka bardziej poważna dla słuchacza. Oczywiście dało się w pewien sposób tego uniknąć. To nie jest tak, że nie dałoby się tego robić. Można byłoby sandboxować PHP, można byłoby i to sandboxować w mocniejszym, albo w lżejszym wydaniu, ale są różnego rodzaju inne sposoby, w jakich można byłoby zmniejszać krytyczność nawet posiadania takiej podatności, jak podatność, która jest w interpreterze, podatność Zero Day, której nie jesteśmy w stanie odkryć, dałoby się mitygować ten problem. Tylko trzeba było po prostu podejść do tego trochę poważniej niż kupię tam jakiś serwerek VPS-a i puszczę PHP. Da się to robić, da się to mitygować, ogólne ryzyko, nawet w sytuacji, w której ktoś by przejął tego Nawet w sytuacji, w której ktoś by był w stanie wejść i wyeksploitować tego PHP, to miałby mocno ograniczone sposoby eskalowania tego. No ale oczywiście też trzeba dołożyć tutaj uwagę, że powinno być jakiś rodzaj monitorowania. Ja nie chcę pomagać cyberprzestępcom, ale niech się ogarną. Szczególnie jeżeli ktoś zarabia ileś tam milionów, No nie wiem, jestem z niesmaczonym podejściem do bezpieczeństwa całej tej operacji.
Krzysztof: Tak, dokładnie.
Andrzej: Dobra, Krzysiek, tyle o PHP, już go zostawmy, chociaż moglibyśmy jakiś taki kącik zrobić, że w każdym razie dynamicznie trochę kopać PHP.
Krzysztof: Chociaż Andrzej, jakby nie patrzeć, no to PHP stał się tutaj bohaterem, tak? Dzięki podatnej wersji, najprawdopodobniej dzięki podatnej wersji PHP udało się zawinąć największą grupę zajmującą się ransomwarem, także… Dziękujemy, PHP.
Andrzej: W sumie faktycznie, tak na to nie popatrzyłem, więc PHP nawet wtedy, kiedy nas zawodzi, to jednak szerzej na to patrząc może wyjść obroną ręką i znowu pomóc szerzej rozumianej ludzkości.
Krzysztof: Dokładnie.
Andrzej: Dobra, Krzysiek, kolejny, kolejny news należy do ciebie z tego, co widzę. I tam jest coś, wow, jest coś o XSS. Dobra, oddaję ci głos.
Krzysztof: Jest o XSS, jest o Nation State, jest troszeczkę o sytuacji, która dzieje się, może nie o sytuacji, ale o wojnie pomiędzy Rosją a Ukrainą. Jest taka firma Recorded Future, wydała bardzo fajny raport w lutym. Ta firma w ogóle szczerze się zajmuje dostarczaniem po prostu threat intelligence’u do dużych firm, do dużych korporacji. i wydała bardzo fajny raport, w którym opisuje jak grupa oznaczona jako TAK-70, oznaczona przez analityków bezpieczeństwa, to jest grupa najprawdopodobniej powiązana z rosyjskim wywiadem wojskowym GieRu, wykorzystywała podatność CVE-2023-5631, to jest podatność, która umożliwiała wstrzyknięcie złośliwego kodu JavaScript, czyli mówimy tutaj o XSS-ach, w kliencie webowym poczty Roundcube. I teraz tak, ta podatność była bardzo prosta, ponieważ na samym końcu takiej wiadomości mailowej, która trafiała do takiego klienta pocztowego, po prostu znajdował się tak SVG, No i w tagu SVG zaszyty był kolejny tag, tag
Andrzej: image,
Krzysztof: który po prostu w sobie już na event handlerze onError uruchamiał złośliwy kod JavaScript, który to z kolei dodawał do drzewa dom, tak, skrypt i zaciągał logikę atakujących która polegała na tym, że eksfiltrowano zawartości skrzynek tych klientów, a ta kampania była targetowana przeciwko głównie urzędnikom wysokiego szczebla w Polsce, na Ukrainie, jak i Gruzji. i nie tylko urzędników, bo również ludzi związanych, szerzej mówiąc, z wojskiem. I teraz tak, jedną kwestią jest to, że był tam XSS w tej wiadomości, atakujący musieli przeprowadzić jakąś kampanię wysyłając maile, trzeba było w tego maila po prostu kliknąć. Tak naprawdę efort, nakład pracy, który musiał zostać poczyniony przez ofiarę był relatywnie niski, nie trzeba było zrobić nic więcej jak wejść w tego maila, nie trzeba było kliknąć jeszcze jakichś linki itd. Wszystko działo się w obrębie tego klienta webowego tej poczty. Ale tutaj to, co mnie uderza, to to, że cross-site scripting dalej trzyma się mocno i nic nie zapowiada się, żeby dało się go łatwo zdetronizować. Ja sobie przed naszą rozmową, Andrzej, spojrzałem na taki bardzo ciekawy raport HackerOne’a, który zresztą ty też bardzo często przytaczasz w kontekście OWASP Top 10. Rapport HackerOne za 2023 rok na temat najczęściej zgłaszalnych podatności w ramach programów Bug Bounty na tej platformie. I chciałem sprawdzić, czy XSS jest dalej na pierwszym miejscu. I tak, dalej jest na pierwszym miejscu i jest to dla mnie po prostu porażające, jak podatność, która została już opisana na 50 tysięcy sposobów, którą doskonale wiemy, w jaki sposób mitygować, jak się przed nią bronić, przyglądarki, które przez ostatnie lata wdrożyły naprawdę wiele mechanizmów, aby żeby ułatwić pracę programistom i dalej kontynuują rozwój na rzecz tego, aby pozbyć się tego problemu raz na zawsze. Tutaj np. myślę sobie o tym, że Sanitizer API ma być po prostu dostępne by default w przeglądalce. domyślnie, nie będziesz musiał nawet wyciągnąć żadnej paczki, to i tak na dzień dzisiejszy obrona przed XSS-ami jest naprawdę relatywnie prosta, a to, co zostało tutaj wykorzystane przez rosyjski wywiad wojskowy najprawdopodobniej, to jest podatność, która wygląda jak z najprostszego poradnika, jak wejść w XSS-y, czyli tak, skrypt, tak, SVG, w środku umieszczasz image z SRC, które nie istnieje i dodajesz event handler on error, który zawsze się wykona, no bo ten source przecież nie da się do tego source’a dobić, więc tutaj ten event handler zawsze zadziała, to jest po prostu dla mnie porażające, jak do takich rzeczy może dochodzić.
Andrzej: Dla mnie to też jest porażające. Sytuacja jest bardzo podobna do problemów niskopoziomowych z zarządzaniem pamięcią, do Stack Based Buffer Overflow, do Heap Based Buffer Overflow, gdzie tak naprawdę sam problem, samą podatność znam od lat. Pierwsza instancja publiczna Stack Based Buffer Overflow to głośny robak Roberta Morrisa. juniora, nie seniora, senior pracował wtedy w MSA, a jego syn studiował na MIT. i to była pierwsza instancja wykorzystania właśnie podatności przepełnienia WUFORa w exploicie, w exploicie, który faktycznie zaczął coś robić, no to to było już 40, nie, to było 30, ponad 30, ponad 30 lat temu. i w dalszym ciągu mamy te problemy i pomimo tego, że mamy, tak samo właśnie jak w świecie web-aplikacji mamy pełno różnych litigacji, to wszystko to jest tak naprawdę pewnego rodzaju łatania, ta podatność i tak może się pojawić i i tak może być tak, że będzie się dała ją wyeksploatować. I podobnie z XSS-ami. Świetnie rozumiemy, na czym polega, a jednak cały czas się pojawiają I jakoś końca nie widać, jakoś końca nie widać. Pewnie przyczyn jest kilka, chociażby jedną jest to, że ci deweloperzy, którzy się nauczą czym jest XSS, oni może już nie popełniają tych problemów, ale pojawiają się inni, którzy wchodzą i oni popełniają te błędy. Więc to jest pierwsza myśl, dlaczego cały czas możemy mieć z tym problemy. a druga no to jest po prostu zwykłe ciśnięcie. Biznesu interesuje feature, a nie czy ten feature jest bezpieczny, więc też nie chcę przerzucać tutaj winy na nikogo, bo tutaj nie chodzi o przerzucanie czyja to sprawka, tylko ogólnie szerzej, jeżeli mówimy o ogólnie inżynierii oprogramowania, no to jest ten problem i w dalszym ciągu jako całość rynku sobie z nim nie radzimy, nieważne o jakiej konkretnie roli mówimy, albo to radzenie wychodzi nam tak sobie. To co mi się podoba, bo wspomniałeś o tym, że ja często wspominam HackerOne Top 10, w pewnego rodzaju kontraście do OAS Top Ten. Tak jest, tak jest, bo jeżeli ktoś zdaje sobie sprawę w jaki sposób jest budowany OAS Top Ten i w jaki sposób jest budowany HackerOne Top Ten, no to zobaczy pewnego rodzaju różnicę i przez tę różnicę czasami lepiej wykorzystać OAS Top Ten, a czasami lepiej wykorzystać HackerOne Top Ten. Mam tu na myśli to, że HackerOne Top Ten jest budowany na bazie raportów dostarczanych do platformy HackerOne. I te raporty by definition, z definicji, one dotyczą firm raczej technologicznych, albo przynajmniej takich, które traktują technologię jako first class citizen i w ogóle mają programy bug bounty, czyli w ogóle uczestniczą w czymś takim i jeszcze mają zewnętrzną pomoc w postaci hacker one. Więc te firmy przez to, jakie mają podejście do technologii, będą też używały innych stosów technologicznych. niż bardziej tradycyjne firmy, takie jak przykładowo duzi gracze na rynku finansów czy ubezpieczeń. I przez to, że używamy pewnego rodzaju innych technologii, innych stosunków technologicznych, no to te problemy związane z tymi technologiami są trochę inne. Oczywiście i w jednej i w drugiej możemy mieć ten sam problem. Natomiast typowe problemy dla Java będą trochę inne niż typowe problemy dla Ruby on Rails, które będą jeszcze inne niż typowe problemy dla PHP. Te zbiory będą oczywiście miały punkty wspólne, ale będą miały też punkty rozłączne, będą miały problemy, które w danym ekosystemie raczej się nie pojawiają, bo raczej trzeba byłoby zrobić coś naprawdę dziwnego, żeby one się pojawiły, albo w ogóle nie mają za bardzo prawa się pojawić. No i biorąc pod uwagę, że HackerOneTop10 jest budowany na bazie tych podatności, albo inaczej, na bazie feed’u i raportów do takich firm, no to stoi w jakiegoś, w jakiejś kontrze do sposobu budowania OWST, który jest budowany na podstawie ankiet dostarczanych przez firmy pentesterskie, które no raczej z racji tego, kogo testują, raczej testują dużych graczy, raczej Fortune 500. Więc przez to, skąd bierzemy dane, Będziemy mieć trochę inny wynik, trochę inną końcową dystrybucję tych podatności. I to raz, to jest jeden duży punkt. No a dwa, HackerOne Top Ten jest bliższy CWE, gdzie te podatności raczej starają się być faktyczną, atomiczną podatnością, a nie tak jak w przypadku obecnego OW Top Ten, gdzie raczej mówimy o klasach problemów niż o pojedynczych problemach. Tutaj przykładowo w tym HackerOneTop10 mamy podatność Cross-Site Scripting i nawet mamy to wylistowane i rozbite na Cross-Site Scripting Reflected, na XSS Stored i na XSS Dom. Czyli tak naprawdę na 10 pozycji, które mamy, 3 z nich to XSS. bo mamy wszystkie z nich, mamy Reflected, mamy Start i mamy DOM. A tak naprawdę w końcu wszystko to jest XSS, bo niejako pozwala nam to samo, ale w kodzie jest to innego rodzaju pomyłka. Więc skoro jest to innego rodzaju pomyłka na poziomie kodu, to na poziomie poprowadzania też będzie trochę inna, a skoro będzie trochę inna, to należałoby to rozróżnienie dorzucić. I oni tutaj właśnie w HackerOne Top 10 to rozróżnienie dodają. Natomiast w OWT raczej mówimy o konkretnych klasach, które, jak to klasy mają do siebie, klasyfikują wiele różnych jakichś entities, jakichś bytów w jedną większą całość, wsadzając po prostu elementy do… worka, więc ten HackerOne Top 10 będzie tutaj przydatny. Co do samego tego ataku, to ja o nim nie słyszałem, jakoś totalnie mi umknął, faktycznie ciekawy. Moje pytanie co do tego, to jest ile faktycznie, no bo tutaj mówimy o atakowaniu Ukrainy, Polski i Gruzji, to moje pytanie byłoby ile jest tych podatnych wersji Roundcube’a w użyciu w administracji publicznej czy w wojsku? Nie wiem, oczywiście nie ma takiej informacji, ale pewnie jest na tyle, że opłacało się przeprowadzić taką operację. Cyberbezpieczeństwo, szczególnie atakowanie, nie jest w próżni. Nation State czy nawet grupa przestępcza nie będzie robiła czegoś for fun, tylko musi mieć jakiś konkretny cel i musi mieć wystarczająco wysokie prawdopodobieństwo, że ten cel osiągnie, żeby zacząć coś robić, żeby poświęcić na to środki. I skoro poświęcili na to środki, to stawiam na to, że wcześniej odbył się jakiś rodzaj rekonesans, jakaś enumeracja, z której wyszło, że w naszych krajach, na Ukrainie, w Polsce, w Gruzji, ten roundcube jest faktycznie używany w administracji publicznej, w jakimś szerszym lub węższym, ale na tyle szerokim zakresie, że po prostu gra była warta świeczki. Co też jest niejako trochę ciekawe, że to użycie występuje. Dobrze, Krzysiek, jeżeli masz jakieś końcowe komentarze, to możesz dorzucić. Ja nie będę już poruszał tego swojego ostatniego kawałka, który przygotowałem, bo dobijamy do półtorej godziny. Chcieliśmy, żeby dzisiaj było jednak trochę krócej. W przyszłości będziemy chcieli jeszcze, żeby to się timeboxowało w godzinie. Dzisiaj nam nie wyszło, ale i tak jest lepiej niż ostatnio. A pamiętajcie, trzeba iterować małymi krokami do przodu. Iterate upon success. Ostatnio było prawie dwie godziny, teraz będzie już półtorej godziny, to może kolejnym razem wstrzelimy się akurat w godzinę.
Krzysztof: Tak, następnym razem po jednym temacie na łeb. I w godzinę się wyrobimy.
Andrzej: Tak, ja po prostu nie mogę tych dygresji o tych wszystkich researchach wsadzać, to wtedy będzie trochę szybciej.
Krzysztof: Ale być może one będą i budują też wartość dla naszych słuchaczy. Bardzo dziękuję. Wracając jeszcze do randki, bo to powiedziałem, że poraża mnie to, że XSS i tak dalej, pomimo tego, że to jest tak prosto wyprowadzić i tak dalej. Relatywnie prosto. Jeżeli chodzi o tutaj klienty webowe, tutaj mówimy o mailach, to sprawa też może nie być tak trwialna, bo jednak treść, którą przychodzi, chcemy wyświetlić w sposób atrakcyjny, więc chcemy pewnie zachować dużą ilość tagów HTML-owych itd., więc to na pewno nie sprowadza się do tego, że ha, wdrożę sobie sanitizer, wdrożę sobie dom Purify’a i wytnę 80% treści maila i mój użytkownik tak naprawdę końcowy nie zobaczy nic w tym mailu, bo restrykcyjny sanitizer po prostu wali wszystko, więc tutaj na pewno to nie sprowadza się tylko i wyłącznie do drżenia sanitizera, tam pewnie można było zrobić wiele innych rzeczy, już nie wchodząc w technikalia.
Andrzej: Tak, tutaj świetna uwaga na koniec. Często, gęsto, oczywiście my trochę może z takiego pewnego rodzaju zmęczenia materiałem, bo po prostu widzimy to na co dzień, te wszystkie podatności, no to często po prostu się rzuca taką uwagę, że no kurczę, trzeba byłoby to już rozwiązać, ale ja myślę, że każdy bezpiecznik z zacięciem inżyniera zdaje sobie doskonale z tego sprawę, że O ile można klasyfikować pewne przypadki, to raczej zawsze trzeba się przyjrzeć konkretnemu przypadkowi, nawet jeżeli wchodzi w pewną generalizację. I często nie jest tak, że ktoś faktycznie totalnie o czymś nie pomyślał, tylko problem sam domenowy może być trudny do rozwiązania. Tak jak mówisz, jeżeli mówimy o kliencie pocztowym, który z założenia musi dbać o user interface, o user experience tego użytkownika, który z niego korzysta, no to sprawa po prostu nie jest taka łatwa, żeby wyciąć to, co nam się nie podoba. Moglibyśmy to zrobić, ale to jest to, o czym ostatnio mówiliśmy w naszej rozmowie prywatnej, że bezpieczeństwo końców nie jest nie jest główną wartością, to nie jest tak, że coś może być bezpieczne w stu procentach, jak jest nieużywalne. Nie, coś najpierw musi być używalne, a potem być może dobrze by było, gdyby było bezpieczne. Ta wartość biznesowa, rozwiązanie problemu z drugiej strony jest ważniejsza niż rozwiązanie go w stuprocentowy, bezpieczny sposób. I niejako można się na to oburzać, ale gdyby tak nie było, to odbiorca, czyli klient końcowy, po prostu nie przyjął tego rozwiązania. Skoro je przyjmuje i korzysta, to najwidoczniej uważa, że wartość, którą z tego wyciąga, jest większa niż potencjalne ryzyko, jeżeli coś się stanie. No bo gdyby naprawdę klienci końcowi, gdyby im zależało na bezpieczeństwie, no to by nie kupowali niebezpiecznych produktów i by to wymagali na dostawcach oprogramowania. Skoro tak nie jest, a najwidoczniej tak nie jest, no to trzeba się niestety pogodzić z rzeczywistością, że bezpieczeństwo jest czymś dodatkowym i według mnie przyjęcie takiej strategii jest pewnego rodzaju wyzwoleniem z takich, nazwijmy to, mentalnych łańcuchów, gdzie coś musi być zero-jedynkowe, tylko pomyślenie, aha, dobra, Jeżeli bezpieczeństwo jest czymś dodatkowym, to co ja mogę zrobić, żeby zabezpieczyć to na tyle, na ile mogę i żeby dodać jak najwięcej wartości do wszystkich innych, strumieni biznesowych, które tak naprawdę tworzą tę wartość biznesową, która generuje pieniądze. Czyli grać do jednej bramki i co ja mogę zrobić na tyle, na ile się da, a nie przyjmować zero-jedynkowego podejścia, które ja oczywiście też na początku swojej kariery przyjmowałem. Nie przyjmować zero-jedynkowego podejścia, że coś musi być albo takie, albo takie, że nie ma nic pomiędzy. Niestety, jak wiele rzeczy w życiu to jest pewne odcienie szarości, gradient, a nie coś czarne i białe. W życiu jest mało rzeczy, które są bardzo mocno czarno-białe. Raczej jest więcej takich szarych rzeczy.
Krzysztof: Tak jak mówisz Andrzej, bardzo łatwo jest wpaść w taką pułapkę, szczególnie na początku, jeżeli ktoś wchodzi w bezpieczeństwo, czy zaczyna się interesować tym tematem, takiego bardzo binarnego spojrzenia zero-jedynkowego, albo coś jest bezpieczne, albo wcale niebezpieczne. A ten biznesowy kontekst w zarządzaniu bezpieczeństwem, zarządzaniu bezpieczeństwem aplikacji, produktów, szerzej mówiąc, systemów, to jest bardzo ciekawy temat, który mam nadzieję, że kiedyś uda nam się poruszyć w ramach jakiegoś epizodu podcastu, szczególnie kiedy mamy gdzieś też z tyłu głowy taką racjonalną analizę ryzyka i potrzeb. Także tutaj już chyba będziemy powoli stawiać kropkę na dzisiaj.
Andrzej: Tak, tak, stawiamy definitywnie kropkę. Bardzo dziękuję za to podsumowanie. No i ja na pewno podejmę rękawicę i bardzo chętnie o tym porozmawiam, a słuchaczom już teraz niejako zdradzimy. Rąbka tajemnicy, że tak, gdzieś mamy w planach porozmawianie na takie bardziej przyziemne spojrzenie na bezpieczeństwo, bardziej racjonalne i wyrównane też z biznesem. Tak, żeby przedstawić to na to, jak my patrzymy. To nie jest tak, że koniecznie trzeba patrzeć tak jak my. My mamy jakąś swoją wizję, ale to… Mamy wojnę idei, niech wygra najlepsza idea. My mamy swoją i nie boimy się jej przedstawić, ale to dopiero w przyszłości. Dobrze, w takim wypadku z mojej strony serdecznie dziękuję za kolejną edycję analizy dynamicznej, dzięki Krzysiek. Trzy słowa na koniec i będziemy kończyć.
Krzysztof: Ja też bardzo dziękuję, dajcie znać jak wypadliśmy w tym nowym anturażu, na tym nowym tle, bo faktycznie jest nowe, no i zapraszamy za miesiąc.
Andrzej: Tak, jest czadowo. Dajcie koniecznie znać, czy w komentarzu, czy podbijcie do nas na jakieś DM, nie krępujcie się, ale będziemy bardzo wdzięczni za feedback i być może też za to, o czym wy chcielibyście posłuchać w jakichś tematycznych odcinkach. Tutaj zawsze jesteśmy otwarci mocno na feedback, no bo na koniec dnia robimy to nie dla siebie, no ale po części właśnie dla szerszej społeczności IT, bo nie tylko dla bezpieczników, dla szerszej społeczności IT. Z mojej strony to tyle, dzięki i do zobaczenia kolejnym razem.
Krzysztof: Dzięki, do zobaczenia, hej.
Andrzej: Na razie.