Atak „LLM Jacking”
Analizujemy atak „LLM Jacking”, w którym cyberprzestępcy wykorzystują luki (np. w frameworku Laravel) do kradzieży kluczy do usług chmurowych. Następnie używają ich do uruchamiania dużych modeli językowych (LLM) na koszt ofiar. Zamiast sprzedawać klucze, oferują dostęp do usługi reverse proxy, co jest dyskretniejszym sposobem monetyzacji skradzionych zasobów. Koszty takiej operacji mogą przekraczać 46 tys. dolarów dziennie. Podkreślono znaczenie monitorowania środowisk chmurowych (np. za pomocą CloudTrail czy CloudWatch) w celu wykrywania nieprawidłowości.
Skuteczność kampanii phishingowych i inne zagrożenia
Drugim tematem jest nieskuteczność obecnych testów phishingowych, które demotywują użytkowników zamiast ich edukować. Google rozwiązało problem phishingu u siebie, wprowadzając sprzętowe klucze bezpieczeństwa, co jest najskuteczniejszą metodą obrony. Poruszono również problem „dependency confusion” w zarządzaniu pakietami oraz omówiono rekomendacje CISA i NSA dotyczące zabezpieczania środowisk CI/CD, w tym znaczenie higieny poświadczeń, dwuskładnikowego uwierzytelniania i zasady najmniejszych uprawnień.
Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.
Transkrypcja
Andrzej: Dzień dobry. Kolejny odcinek naszego podcastu, podcastu Bezpiecznego Kodu. Spotykamy się z Krzyśkiem dzisiaj w trochę innym wydaniu, bo jak można zauważyć jest to nagrywany remote i po stronie Krzyśka i po stronie mojej. To jest jeden format, który będziemy kontynuować w przyszłości. Nie zawsze możemy spotkać się na miejscu. Możemy spotykać się na miejscu, w szczególności gdy spotykamy się w połowie Polski, natomiast tak day to day Krzysiek jest ze Szczecina, a ja jestem, no Krzysiek jest ze Szczecina jak Krzysztof Jarzyna. Właśnie i też Krzysztof. Może Krzysiek jest Jarzyną. Kto wie? Kto wie? Właśnie. Mam nadzieję, że tak, to będzie łatwiej robić biznesy. A ja jestem z Warszawy. Dobra, więc startujemy w trochę innym wydaniu. Mam nadzieję, że będzie równie dobrze jak na miejscu. Już o to się postara nasz montażysta. Pozdrawiamy. No i co, Krzysiek? Wskakujemy, wskakujemy. Nie ma co przeciągać, bo ludzie czekają na nową porcję ciekawostek, które wyłowiliśmy.
Krzysztof: Dokładnie. Cześć, witajcie jeszcze raz z połem wstępu. Faktycznie łatwiej jest nagrywać w połowie Polski, gdzieś w okolicach Poznaniu. No dzisiaj musimy sobie radzić w warunkach domowych, ale mamy nadzieję, że nie będzie to umniejszało jakości. Na pewno nie będzie umniejszało jakości. Okej, słuchajcie, wskakujemy w pierwszego newsa, pierwszy artykuł, który przeczytałem dla Was i chciałbym go Wam streścić. W zasadzie, tak jak wspominaliśmy przez poprzednie kilka odcinków, boom na elemy. powoduje to, że wypływają nowe problemy związane z bezpieczeństwem. Nowe, stare, bo tak naprawdę to są problemy, które w pewnym sensie są odgrzanym kotletem. i w tym momencie tutaj Sysdig prezentuje nam swój mini research w kontekście ataku, który autorsko nazwał jako LLM Jacking, czyli kradzież kluczy do usług chmurowych i wykorzystanie tych kluczy celem ich dalszej odsprzedaży, może nie odsprzedaży samych kluczy, ale dostępu do tych modeli, które są hostowane w środowiskach chmurowych. I tak, tutaj Sysdig opisuje, że namierzył kampanię, która targetowała podatną wersję frameworka PHPowego, bardzo popularnego, mówimy tutaj o Laravelu, więc znowu PHP, jakby nie patrzeć. Ale nie, oczywiście żartujemy generalnie. Może to spotkać każdy z tak technologicznych, tutaj Sysdig akurat opisuje tą konkretną podaśność w Laravelu. Nie wchodząc w szczegóły, pozwalała ona na zdalne wykonanie kodu na serwerze, na którym operował Laravel, więc jeżeli mówimy tutaj o kradzieży tokenów, to wektor najprawdopodobniej wyglądał w taki sposób, że po uruchomieniu kodu w trakcie egzekucji tego kodu po prostu były dampowane zmienne środowiskowe, no i jeżeli w tych zmiennych środowiskowych znaleziono klucze do usług chmurowych, no to natychmiastowy sposób były one odpytywane, aby zbadać zdolność, czy jesteśmy w stanie na nich uruchomić model LLM-owy. I tutaj w zasadzie powiem wam szczerze, że cały ten atak LLM Jacking jest niczym innym jak pewną wariacją czegoś, co jeszcze do niedawna było popularne, w sensie dalej jest popularne, czyli crypto jacking, gdzie hakerzy włamując się albo przechwytując dane poświadczające do usług humorowych, po prostu uruchomiali na instancjach takich jak EC2 w kontekście AWS-a swoje maszynki do kopania kryptowalut, więc LMJacking to jest nic innego jak pewna wariacja tego ataku właśnie w kontekście wykorzystania dużych modeli językowych, za które użycie płaci ofiara będąca nieświadomą, że ten klucz gdzieś tam wyciekł. To co jest ciekawe w tym ataku to to, że tak naprawdę atakujący wykorzystali tutaj taki model reverse proxy, kradnąc te klucze do różnych usług chmurowych, na których można hostować swoje duże modele językowe, nie odsprzedawali tych kluczy bezpośrednio do innych przestępców, klucze mieliby kupić, tylko sprzedawali dostęp do usługi, która tak naprawdę pozwalała na interakcję z tymi modelami, które były hostowane po stronie naszych ofiar. Więc tak naprawdę pozwalało im to na monetyzację tego całego ataku. Przestępcy tutaj są całkiem inteligentni i nie pozbywają się tak szybko tych kluczy. Targetowane były takie usługi jak Antrophic, AWS Bedrock, który w zasadzie w swoim portfolio posiada praktycznie większość dużych modeli językowych, których można uruchomić w ramach właśnie AWS-a. usługi LLM-owe, które można uruchomić na ażurze, Eleven Labs, Vertex AI od GCP, no i popularne OpenAI. I oni po prostu kradli te klucze z tych, może nie z tych usług, ale do tych usług, wykorzystując m.in. tą podatność w Laravelu, a następnie poprzez taki model Reverse Proxy sprzedawali dostęp do swojej usługi, która komunikowała się z tamtymi dużymi modelami językowymi.
Andrzej: Wiesz co Krzysiek, ja tutaj wejdę w słowo, bo powiedziałeś, że ciekawą rzeczą jest to w jaki sposób wykorzystywali. Dla mnie oczywiście to jest bardzo ciekawe, właśnie dlatego, że nie robili tego tak w bardzo taki pośredni sposób, bezpośredni, tylko właśnie robili to w pośredni. co niejako od strony, może nie ofiary, ale tej osoby, która by to odkupowała, czyli tego użytkownika końcowego, no to wszystko wyglądałoby całkiem okej. Kupuję po prostu usługę. Nie jestem tutaj żadnym paserem. A jednak jesteś paserem i to jest faktycznie ciekawa uwaga. Natomiast ja, korzystając z okazji, ja wiem, wspomniałem się o tym, ale chciałbym powiedzieć, że no pechap, pechap się przewija. Ja wiem, że to nie jest, ja wiem, że to nie jest wina La Ravela, ale no za każdym razem, jak jest jakiś atak i pojawia się pechap, to mam taką, no uśmiech na twarzy się sam pojawia.
Krzysztof: No tak, przecież nie tak dawno temu wspominaliśmy o kompromitacji największego vendora Ransomware, SSService. Jak on miał? Nie pamiętam. Ja sobie nie przypomnę, ale też przez podatność w samym PHP, która była wykorzystana przez amerykańskie służby do tego, żeby przejąć i zawinąć ten serwis w całości. Podrzucimy w referencjach link do tego odcinka, o którym tam wspominaliśmy. To był jeden z pierwszych odcinków.
Andrzej: Tak, to był pierwszy albo drugi. Natomiast ja chciałbym wypunktować, to był taki, nazwijmy to mini żarcik, ale to co mi się od razu rzuciło w oczy, w ucho, jak o tym wspomniałeś, to nawiązanie, bo nie wiem czy zauważyłeś tą koneksję, ale nawiązanie do tego o czym mówiliśmy w ostatnim odcinku na temat Data Bridge Investigations Report, debira. Tam, nie wiem czy pamiętasz, ale wnioskiem autorów było, że Generalitive AI, AI’e, LLM’y w zeszłym roku Pomimo tego, że eksperci, specjaliści od security mówili o tym, jak ono nie będzie strasznie wykorzystywane przez cyberprzestępców, to jednak w realnym życiu nie jest przez nie wykorzystywane. A tam gdzie jest, czyli tam gdzie faktycznie jest wspominajka o Gen AI-u czy LLM-ach w Darknecie, to jest ono wspominane właśnie w tym kontekście, czyli od sprzedaży kredenszali, kredek do usług tego typu, czyli nie jest wykorzystywane przy np. kampaniach phishingowych do wygenerowania jakiegoś tekstu, obrazków, etc. Tylko jest wykorzystywane tam, gdzie ja odsprzedaję cały zestaw, cały zbiór różnych kredek, które potem ktoś może wykorzystać po to, żeby nie płacić za te usługi, tylko skorzystać z tych skompromitowanych kredenszali. Mamy dokładnie ten kawałek. Oczywiście model biznesowy w tym casie, o którym Ty teraz mówisz jest trochę inny. Model biznesowy tych cyberprzestępców. Ale znowu, no niejako się trochę potwierdza to, te wnioski z debira, o którym wspomnialiśmy ostatnio. I to od razu mi się gdzieś tam zapaliła lampka w głowie.
Krzysztof: Tak, zwłaszcza, że wykorzystywanie tych dużych modeli językowych nie jest taniej. Myślę, że każdy kto próbował integrować się z takim API i operować z tym produkcyjnie wie z jakimi kosztami trzeba się mierzyć. Tutaj wysyłając odpowiednią ilość tokenów i odpowiednią ilość tokenów odbierając przez token mam na myśli tą pojedynczą cząstkę, ten unit tego co jest liczone przez duże modele językowe jako token. To może być słowo, to może być jedna litera, to w zależności od tego jak już działa ten tokenizer po stronie dużych modeli językowych. Kończąc ten mój wywód o Sysdigu i ich researchu, chciałbym napomnieć jakie oni szacowali koszta tutaj w przypadku modelu od Antrophic Clouda. Tutaj researcherzy policzyli, że jeżeli byśmy tak naprawdę działali z pełną przepustowością, gdyby ten model był wykorzystywany 24 godziny na dobę, przy założeniu, że maksymalnie w ciągu godziny jesteśmy w stanie wysłać 500 tysięcy tokenów i 500 tysięcy tokenów odebrać, no to koszt tutaj wyniósłby około 46, no ponad 46 tysięcy dolarów. w kontekście cennika AWS-a, tak? Czyli gdybyśmy uruchomili Clouda 2 na AWS Bedrocku, no to i przy założeniu, że on by był cały czas na pełnej przypustowości wykorzystywany przez tą reverse proxy, które zestawili atakujący, no to ofiara zapłaciłaby 46, ponad 46 tysięcy dolarów.
Andrzej: Sporo, sporo. I zapłaciłaby za dobę, tak?
Krzysztof: Za dobę, tak, za dobę. To jest za dobę takie przeliczenie Pira z drzwi za dobę przy takim pełnym wykorzystaniu 24 godziny na dobę.
Andrzej: No to bardzo dużo. 10 dni 460 tys. miesiąc ma 30 dni, więc razy 1,5 bańki za miesiąc korzystania. Dość kosztowne, jeśli popatrzymy na to od strony tego, no nazwijmy to, w jak prosty sposób można uniknąć tego problemu, nie korzystając z PHP. Oczywiście żartuję. Nie, po prostu nie trzymając kredek tam gdzie nie powinno i być.
Krzysztof: To jest jedna kwestia, którą Sysdig porusza w konkluzjach tego artykułu, a druga jest taka, żeby też jednak zestawić odpowiedni monitoring, szczególnie w środowiskach chmurowych, bo w AWS-ie można by było wykryć jakby inicjalizację takiego modelu poprzez usługi takie jak CloudTrail czy CloudWatch, więc tutaj monitoring w kontekście usług chmurowych jest niezwykle istotny, szczególnie w kontekście np. kosztów.
Andrzej: Tak, to jest po prostu kluczowe w zasadzie wchodzenie w chmurę a nie włączeniu w swój model od razu. w jaki sposób będę monitorował koszty. No jest można powiedzieć kręceniem liny na własną szyję. Nie jest zbyt roztropne. Dokładnie. Ja mam jeszcze. Ja mam jeszcze jedną uwagę, taką tyci. tyci, bo wspomniałeś tam o Eleven Labs. To chciałbym wspomnieć, bo nie każdy zdaje sobie z tego sprawę, natomiast Eleven Labs jest polskim startupem AI, który dostał duże pieniądze na rozwój. Jest tworzony przez mały zespół, znaczy mały w porównaniu do startupów kalifornijskich, które potrafią mieć sporo tych pracowników. No i jest taką, nazwijmy to, naszą polską perełką w ekosystemie AI-owym, bo w tym wertykalu, w którym oni się specjalizują, czyli konkretnie w generowaniu głosu, bo nie wynika to bezpośrednio z nazwy, ale Element Labs zajmuje się generacją głosu. Przykładowo weźmy mój głos i teraz zacznijmy mówić w języku angielskim, ale moim głosem. No to oni są tutaj przodownikiem pracy. Są cutting edge i tutaj chyba nie mają konkurencji, która jest od nich lepsza lub nawet, która jest blisko nich. Więc oni tutaj naprawdę, naprawdę chłopaki zrobili świetną robotę.
Krzysztof: To bardzo ciekawe.
Andrzej: Warto wiedzieć.
Krzysztof: Ja też się czegoś w takim razie teraz nauczyłem. Nie wiedziałem, że Eleven Labs jest z Polski.
Andrzej: Jest polskie, jest polskie. Dobra, teraz wskakując w mojego newsa. To jest w zasadzie dość świeże, bo wyszło już tam w drugiej połowie maja, ale od razu rzuciło mi się w oczy, bo to jest temat, który ja po prostu lubię. I może nie chodzi o sam temat, bo będę mówił o phishingu, ale to co lubię w tym temacie, o którym zaraz opowiem, to to jak podchodzą bezpiecznicy do bezpieczeństwa i że często jest to po prostu nieskuteczne. Jest to nieskuteczne, sami siebie klepiemy po plecach, ale na koniec dnia organizacje ani użytkownicy ani nie są bezpieczniejsi, ani nie są bardziej zadowoleni ze swojego user experience związanego ze wszystkimi kontrolami bezpieczeństwa, które są nieefektywne, a tylko dodają tarcia do ogólnej pracy. I mówię teraz konkretnie o poście On Fire Drills and Fishing Tests od Google, więc dość duża firma, dość duży zespół bezpieczeństwa, można powiedzieć, że jeden z największych na świecie, który nie jedno, nie dwa widział, który co więcej jest jednym z nielicznych zespołów na świecie, który faktycznie musi się mierzyć z atakami ze strony Nation State. innych rządów. i nie tylko musi się mierzyć, ale był też w przeszłości przez nich schakowany. Przynajmniej jeżeli mówimy o czymś publicznym, o Operacji Aurora z 2009 roku, gdzie Google i wiele różnych innych firm z Silicon Valley zostało schakowanych przez rząd. Teraz nie dam sobie ręki uciąć, który rząd, ale wydaje mi się, że to była Korea. Ale ta zła Korea, nie ta dobra, czyli Korea Północna. Więc swoje widzieli. Jest to zespół, który jest może nieunikatowy, ale jest jednym z najbardziej unikatowych zespołów bezpieczeństwa na świecie po prostu przez skalę działania firmy Google i oni Oni napisali taki post, w którym niejako porównują obecne kampanie phishingowe do tego, w jaki sposób wyglądały alarmy przeciwpożarowe i te ćwiczenia przeciwpożarowe na początku XX wieku, pod koniec XIX i na początku XX wtedy, kiedy industrializacja wchodziła na pełnej parze. I ludzie zaczynali się koncentrować w dużych ośrodkach miejskich. I wtedy zaczęliśmy mieć problem z pożarami. Oczywiście problem z pożarami to nie zaczął się wtedy. Ten problem to był od wielu, wielu, wielu, od setek lat. Nawet od tysięcy lat. Natomiast problem po prostu zyskał jeszcze więcej na znaczeniu, no bo kompresując miasta mieliśmy budynki blisko siebie, no i każdy pojedynczy pożar mógł bardzo szybko się rozprzestrzenić na inne budynki i można nawet, mogło spalić się całe miasto. Był taki dość duży pożar kiedyś w Chicago, chyba w Chicago. Ale ręki w lomu sobie nie nam…
Krzysztof: Chyba w Londynie, wielki pożar w Londynie?
Andrzej: W Londynie też, ale w Londynie wydaje mi się, że był wcześniej. Wcześniej, tak. Tak, w tych późniejszych okresach, jak już mieliśmy nazwijmy to miasta, które wyglądają na powiedzmy wzór naszych obecnych, to wydaje mi się, że był wielki pożar Chicago, ale to nie ma znaczenia. Dlatego, że to co ma tutaj znaczenie, to to, że w pewnym momencie jako ludzie doszliśmy do wniosku, że okej, tak nie może być, musimy pomyśleć nad jakimiś procedurami bezpieczeństwa, które ułatwią nam na szybsze reagowanie, idealnie na może nie proaktywne, bo tutaj proaktywne musi być najpierw pożar, ale proaktywnie chcemy się przygotować do tego pożaru, czyli już wykazacie pewną proaktywnością przed pożarem, bo pewne rzeczy możemy przetestować. No i stąd się wzięły te całe ćwiczenia przeciwpożarowe, ale Ciekawym wnioskiem z tego artykułu jest to, że te ćwiczenia przeciwpożarowe one wcale na początku tej drogi wcale nie obniżyły ilości ofiar. Wręcz przeciwnie. Ofiar przybyło. Czemu? Dlatego, że zaczęły się pojawiać ofiary w samych ćwiczeniach przeciwpożarowych. Więc tam ludzie przykładowo byli zdeptani przez tłum. Więc nie dość, że mieliśmy ofiary z samych pożarów, to jeszcze na tą liczbę musielibyśmy dołożyć tych, którzy polegli albo stała im się krzyda przy ćwiczeniach przeciwpożarowych. Co jest, można powiedzieć, sytuacją nieoptymalną. I to jest ważne, że oczywiście nastąpiła pewna ewolucja, no bo tam gdzie mamy realne straty, a strata zdrowia czy życia jest realną stratą, gdzie trudno jest nam się tak pogodzić z tym, że ktoś stracił życie lub zdrowie, ani tej samej osobie, ani ludziom wokół, czyli rodzinie i przyjaciołom. Więc był mocny nacisk, że no tak nie może być, musimy coś zrobić. I oczywiście te ćwiczenia przeciwpożarowe wyewoluowały. Natomiast jedną z takich ważnych ewolucji, kierunku tej ewolucji i stanu, który mamy na przykład teraz, to myślę, że każdy znaje sobie doskonale sprawę, szczególnie jeśli pracuje w budynkach takich biurowych, że ćwiczenia przeciwpożarowe są jasno ogłaszane i jest jasno napisane, że jest to ćwiczenie przeciwpożarowe, że jest to ćwiczenie. nikt nie włącza alarmu i nie mówi mamy pożar a potem na koniec testu mówi a nie chwileczka to było tylko ćwiczenie jest super nie z góry jest wiadomo że to będzie ćwiczenie z góry jest wiadomo kiedy ono będzie i czemu. żeby nie włączać paniki żeby ten system który mamy w głowie odnośnie paniki był włączany wtedy kiedy mamy faktyczny pożar a nie wtedy kiedy nie mamy tego pożaru. i I chcemy się przygotować idealnie w ten sposób, żeby ten system paniki w ogóle nie był włączony. Czyli, że nawet jeżeli wystąpi pożar, to żeby było, a dobra, to ja już to przerabiałem, ja wiem co trzeba zrobić, trzeba tutaj zejść schodami, nie można używać windy, trzeba spotkać się w tym konkretnym punkcie etc. Czyli chcemy nauczyć użytkowników, żeby nie panikowali, żeby robili coś, co już wcześniej robili. i Google Google doszło do tego samego wniosku, że jeżeli chcemy nauczyć naszych użytkowników odpowiedni zachowań, to nie możemy przeprowadzać testów phishingowych w taki sposób, w jaki w tej chwili są przeprowadzane. Czyli, że są przeprowadzane jako niespodzianka, że użytkownicy, którzy kliknęli link, potem są wysyłani na mandatory security awareness training odnośnie phishingu, że po prostu takie coś nie działa. I patrząc wstecz, widzimy, że to nie działa. To też trochę łączy się z tym, o czym mówiłem w odcinku poprzednim odnośnie Data Bridge Investigations Report, bo tam też było o phishingu. Nie możemy oczekiwać od użytkowników końcowych, że nie będą klikać w linki na maszynie, która służy do klikania w linki. Więc jeżeli korzystamy z komputera, to większość pracy polega kliknięciu w link, przynajmniej w chwili obecnej, jeżeli mówimy o web, o internecie, to większość pracy polega na kliknięciu w jakiś link, przeczytaniu tego, co tam jest i odniesieniu się do tego. Jak można oczekiwać od użytkownika nie klikania w linki na maszynie, która w większości czasu służy do klikania w linki? Jest to co najmniej zabawne, albo dokładanie dodatkowych requirementów, że ale to jeżeli przed kliknięciem zastanów się, czy ten link jest dobry, czy nie. Znowu, jeśli poddajemy sobie te minuty, które musimy poświęcić na zastanawianie się, to nagle wyjdzie nam, że w cyklu tygodniowym, miesięcznym, rotnym musimy dodać x godzin, x nawet dni czy tygodni do samego zastanawiania się nad tym, czy ja mogę kliknąć w ten link, czy nie. Jeszcze jeżeli nałożymy na to ilość maili, które otrzymuje typowy pracownik biurowy, to są dziesiątki, setki maili dziennie, no to po prostu to się nie skaluje. I to co należałoby zrobić, to oczywiście to o czym ostatnio wspomniałem i to też było od Google, gdzie realne rozwiązanie ataków phishingowych, skuteczności ataków phishingowych u Google było rozwiązane poprzez po prostu wprowadzenie kluczyków sprzętowych. Więc nawet jeżeli ktoś się złapie na phishing, to kluczyk sprzętowy go chroni. I to jest rozwiązanie, które broni w 100%. Oczywiście ono ma swój koszt, no bo trzeba każdemu sprawdzić kluczyk sprzętowy, a potem trzeba jeszcze obsługiwać wszystkie przypadki, w których ten kluczyk sprzętowy się po prostu zgubi. Więc to dodaje kosztu procesu biznesowego, ale faktycznie rozwiązuje problem phishingu. Natomiast to, co nie rozwiązuje problemu phishingu, to kampanię. i to znowu ja mówię to z własnego doświadczenia i można powiedzieć jako dowód anegdotyczny i niejako wynika to z prostej logiki, którą mógłbym wyłożyć i udowodnić. Nawet nie trzeba tego testować. Google to za mnie przetestowało i doszli do tych samych wniosków, że jednak przykłady phishingowe, no nie powinny, kampanie phishingowe takie testowe nie powinny być uruchamiane tak jak są teraz uruchamiane, tylko raczej chcemy, celem jest nauczenie użytkownika, nie jego karanie, tylko nauczenie użytkownika jak może wyglądać taki e-mail i to jest cel. I musimy od razu też założyć, że spora część użytkowników się tego po prostu nie nauczy. I OK. I musimy ich chronić. To jest dodatkowa kontrola, która nigdy w 100% nie będzie skuteczna. Nie o to tutaj chodzi. Natomiast zmienienie podejścia do kampanii phishingowych właśnie na takie, które jasno mówią, na przykład tutaj jest pokazany egzampum, konkretnego adresu, że Hello, I am a phishing email. This is a drill. This is only a drill. Czyli jasna informacja odnośnie tego, że to jest kampania phishingowa. To nie jest coś, co faktycznie powinieneś kliknąć, ale ma to na celu edukację i przypomnienie ci. Też trzeba pamiętać, że jako ludzie uczymy się poprzez powtarzanie poprzez repetitive, poprzez powtarzanie, ale też powtarzanie rozłożone w czasie. Więc jeśli będziemy wysyłać takie maile, to pierwszy, drugi, trzeci, czwarty, piąty może nie siądzie, ale siódmy, ósmy, dziewiąty siądzie. Każdy marketer doskonale zna liczbę siedem, mniej więcej. średnia jest taka, że odbiorca musi zobaczyć nasz przekaz siedem razy, żeby go w ogóle odnotować. Więc jeśli nie zobaczy go siedem razy, to tak jakby w ogóle nawet nie ma szansy, że go odnotuje. 7 to jest taka dolna liczba i w kampaniach fishingowych też można byłoby do tego tak podejść, że ten odbiorca musi ich widzieć wiele po to żeby w ogóle zacząć żeby musi gdzieś tam huk w głowie. zrobił więc ten. Ten artykuł od Google’a bardzo mi się spodobał. Przede wszystkim po prostu wnioski i coś niejako trochę potwierdza moje spojrzenie na bezpieczeństwo, że to nie polega na tym, żeby karać i próbować nabrać użytkownika, tylko celem jest, żeby go czegoś nauczyć. A skoro celem jest, żeby go czegoś nauczyć, to całe ćwiczenie musi być zrobione wokół tego, żeby optymalnie uczyć odbiorcę tego, czego chcemy go nauczyć, a nie próbować go nabrać, bo to po prostu jest nieskuteczne. Jest nieskuteczne, a jeszcze tworzy antagonizmy pomiędzy użytkownikami a bezpieczeństwem, które być może jakaś ze stron chciałaby utrzymywać. te antagonizmy, ale ten antagonizm w organizacji też jest po prostu nieskuteczny. Bezpieczeństwo jest po to, żeby dołożyć wszelkich starań, żeby organizacja była bezpieczna, ale nie może tego próbować realizować poprzez skłócanie innych członków organizacji, którzy w zasadzie wytwarzają wartość, którą potem organizacja sprzedaje i generuje revenue. Więc nie można tak robić. No bo czemu? Bo będzie to nieefektywne i bezpieczeństwo będzie marginalizowane. Będzie marginalizowane i powinno być marginalizowane, bo na koniec dnia liczy się biznes, a nie żebym robił coś bezpiecznie. Jest mało przypadków, w których bezpieczeństwo jest na pierwszym miejscu albo jest ex aequo z innymi rzeczami. To są takie przypadki jak przykładowo elektrownie jądrowe czy inne tego typu. ale w takim typowym day-to-day biznesie bezpieczeństwo nie stoi na pierwszym miejscu, nigdy nie będzie stało na pierwszym miejscu i nie powinno stać na pierwszym miejscu, nie powinno stać nawet na drugim czy trzecim. Są ważniejsze KPI, tak to nazwę.
Krzysztof: Dokładnie, niech pierwszy rzuci kamieniem z nas, kto operuje w warunkach infrastruktury krytycznej. Ja jeszcze nie miałem okazji poznać kogoś takiego reszepowa za mocne nerwy. A to, co mi się podoba w tym, co przedstawiłeś Andrzej, to jest ta analogia do ćwiczeń pożarowych i fajnie, że Google wychodzi i czerpie z z innych dziedzin życia tutaj. Przypomina mi to, co czytałem w kontekście sekretów. Znowu o tym powiem, ale kiedyś czytałem taki artykuł, który porównywał właśnie szum generowany przez skanery dotyczące sekretów w naszym kodzie. do tego jak się ma aparatura medyczna w szpitalach. I był bardzo fajny white paper, który był prowadzony bodajże w sieci amerykańskich szpitali, w których też była taka analogia do tego, że jeżeli te wszystkie aparatury będą za każdym razem pikać, no to pielęgniarki, lekarze, personel medyczny będzie po prostu zmęczony tą ilością alertów, więc my tutaj świat IT może czerpać garściami z różnych innych dziedzin życia, no i fajnie, że Google właśnie tutaj to porównuje. fishing, testy fishingowe do testów z zakresu ćwiczeń właśnie przeciwpożarowych.
Andrzej: Ja powiem więcej Krzysztofie. Ja tutaj wejdę głębiej dlatego, że cyberbezpieczeństwo jest dość młodą dziedziną nauki, inżynierii i skorzystałoby bardzo, bardzo mocno, gdyby popatrzyło na inne odłamy nauki, które musiały się zmierzać i dalej muszą się mierzyć z podobnymi problemami. Przykładowo Systems Engineering, ale pod kątem systemów krytycznych takich jak właśnie elektrownie jądrowe. Sam Ci w sobotę podsyłałem papierek od Navy amerykańskiego, od US Navy, który opisuje w jaki sposób powinna być budowana dynamika grupy, całego zespołu, który operuje statkiem, który jest napędzany napędem jądrowym. I było po prostu opisane jak powinna wyglądać kultura takiej jednostki na poziomie właśnie organizacji, na poziomie grupy, na poziomie ludzi. Jakie powinny być zasady i jakie zasady powinny być tam zaszczepione i kultywowane po to, żeby uniknąć jakichkolwiek problemów związanych właśnie z samym napędem jądrowym. I takie rzeczy są dostępne, one są opisywane, można je znaleźć, tylko trzeba wykazać się pewną chęcią. No oczywiście najpierw trzeba zauważyć pewne połączenia, ale jak już je zobaczymy, to wykazać się chęcią poszukania, wejścia w temat i wiele z tych zasad, Wiele z tych problemów, które mamy w cyberbezpieczeństwie jest już rozwiązanych po prostu w innych, w innych systemach, które niosą ze sobą duże ryzyko. Kolejna rzecz to na przykład CITRE, Reliability Engineers, SRE, którzy mierzyli się z wieloma problemami, z którymi mierzą się bezpiecznicy i oni się mierzyli z nimi pomiędzy 2000 a 2010. Wtedy, kiedy ta dziedzina była budowana, potem trochę szybciej, szybciej doszli do pewnych rozwiązań i też od nich możemy się sporo nauczyć. Albo coś co, coś co teraz, ostatnio byłem na urlopie, Krzysiek wie, i jak wracając sobie pomyślałem, patrzyłem po prostu na całe lotnisko i pomyślałem, że okej, ciekawe czy są jakieś książki, jakieś papierki, jakieś opracowania, które opisują systemy kontroli, systemy bezpieczeństwa właśnie związane z lotniskiem, bo jak jesteśmy na lotnisku i widzimy tą całą płytę startową, no to widzimy tam pełno różnych rysunków, widzimy, że jest to żyjący organizm, widzimy, że ludzie jeżdżą na tych wózkach, chodzą, wiele rzeczy się dzieje, to na pewno wszystko jest częścią jakiegoś większego systemu, systemu, który jest złożony z wielu różnych procesów, wiele z tych procesów jest krytycznych, Te krytyczne są oparte na czyt listy. Chciałbym poczytać o tym w jaki sposób jest budowane na poziomie właśnie procesów bezpieczeństwo, jak jest wbudowywane bezpieczeństwo w cały taki system związany z obsługą lotniska. bo na pewno jest, są takie opracowania i na pewno wiele wniosków, wiele podobieństw do cyberbezpieczeństwa, do procesu budowania software’u można wyciągnąć i wiele rozwiązań, problemów można po prostu od nich wyciągnąć i zaimplementować je u nas, po prostu przełożyć je nawet jeden do jeden w niektórych przypadkach. Więc taka myśl, która gdzieś tam mi wpadła i którą będę musiał sobie w kolejnych tygodniach rozwinąć, poszukać, zobaczyć i być może coś uda się tam znaleźć. W zasadzie jestem pewien, że uda się coś znaleźć.
Krzysztof: Obserwujcie, gdyby Andrzej gdzieś tam się pojawił w okolicach Okęcia i coś próbował zmanstrować.
Andrzej: Tak, bezpieczeństwo fizyczne uważajcie na Andrzeja.
Krzysztof: Okej, no także widzicie, że poprzez analogię, przynajmniej w cyberbezpieczeństwie, ale nie tylko, możemy sobie bardzo ułatwić i rozwiązać pewne problemy, z którymi się zmagamy. Okej, wskakujemy teraz do kolejnego materiału, który chciałbym poruszyć, chcielibyśmy poruszyć razem z Wami. To jest materiał, który tak naprawdę już swoje kilka miesięcy dobrych ma. Ja do niego bardzo często wracam. To jest poradnik autorstwa amerykańskiej organizacji ds. bezpieczeństwa infrastruktury i cyberbezpieczeństwa oraz słynnego dzięki Edwardowi Snowdenowi NSA, czyli Narodowej Agencji Bezpieczeństwa. Poradnik, który mówi o tym, w jaki sposób bronić w ogóle nasze środowiska CI, CICD. Ja chciałbym poruszyć ten temat tego poradnika na kanwie tego, że w zasadzie w ostatnim czasie widzimy wzrost ilości ataków właśnie na nasze środowiska CI. Nie będę przechodził przez cały ten poradnik, on ma 23 strony, jest relatywnie krótki. To, co mi się w nim bardzo podoba, to to, że jest, mówiąc bez ogródek, pozbawiony takiego marketingowego bullshitu, bo nie wiem, Andrzej, czy się ze mną zgodzi, już często jest tak, że jeżeli jest jakiś paper wydawany przez jakąś firmę, która dewelopuje jakieś rozwiązanie w kontekście cyber security, to on jest troszeczkę pisany pod to dane rozwiązanie. Przedstawiają tam jakieś problemy związane z bezpieczeństwem i od razu próbują wcisnąć swoją odpowiedź, czyli swoją usługę na rozwiązanie tego problemu.
Andrzej: Oczywiście jest to zrozumiałe, no jeśli firma rozwiązuje jakiś problem, to w jej interesie jest pisanie o tym problemie i po prostu pokazywanie swojego rozwiązania, jak my możemy Ci pomóc rozwiązać ten problem. i oczywiście jest to jak najbardziej zrozumiałe, to raz, a dwa, każdy na tym korzysta, bo można się czegoś nauczyć, a jednocześnie można nawet po prostu rozwiązanie dane kupić, przetestować i w nie wejść i rozwiązać dany problem, więc tutaj nie chodzi o to, żeby przerzucać się, że firmy tak robią, bo to jest jak najbardziej tak powinno, tak powinny robić, tylko faktycznie nie można przeginać, a czasami zdarzają się sytuacje, gdzie widać, że dany post, czy dany papierek jest typową ulotką sprzedażową. Więc ta wartość musi być. Najpierw dajemy wartość, a potem ewentualnie dajemy nasz sales pitch, a nie tylko sales pitch, a tam wartości będzie 5%. To za mało.
Krzysztof: Dokładnie, dokładnie do takich papierków się odnosiłem, więc spodoba mi się tutaj, że nie uświadczycie tego w tym poradniku, nie uświadczycie tutaj nazwy własnej żadnej firmy czy rozwiązania, która pomoże Wam rozwiązać te problemy, o których pisze CISA i NSA, ale uświadczycie to, że ten poradnik jest naprawdę bardzo fajnie i metodycznie opisany i co prawda na pierwszy rzut oka to może się wydawać dosyć skomplikowane, ale jak zaczniecie to czytać na początku i tak jest glosariusz, który opisuje wszystkie terminy, którymi posługuje się NSA i CISA w tym poradniku, to wiele rzeczy zacznie Wam się łączyć w głowie. To, co ja bym chciał opowiedzieć w kontekście tego poradnika, to jest trzy scenariusze zagrożeń, o których CISA i NSA wspomina scenariusze zagrożeń, które właśnie dotyczą naszych środowisk CICD. I zaczynając od pierwszego scenariusza, tutaj CISA i NSA mówi o tym, że cyberprzestępcy w pewien sposób, kiedy otrzymają mogą otrzymać dostęp do naszych środowisk CI właśnie poprzez kompromitację np. kluczy SSH czy loginu i hasła do GitHub’a czy do GitLab’a czyli do naszych systemów gdzie trzymamy nasze zdalne repozytoria bądź poprzez kompromitację tokenów do API tychże usług. Taki token to może być Personal Access Token znany z GitLab’a czy z GitHub’a. No i teraz niech pierwszy rzuci kamieniem ten, który generując sobie taki token w inpucie, gdzie ustawiamy jego czas przydatności, zostawiał ten input po prostu pusty po to, żeby oby przypadkiem ten token mu nie wygasł. No i CISA wskazuje tutaj na to, że powinniśmy zwrócić uwagę przede wszystkim na higienę korzystania z naszych danych poświadczających, uwierzytelniających do tych usług, ale nie tylko. Mówi też o tym, że w zasadzie idąc dalej, nawet jeżeli cyberprzestępca otrzyma dostęp do naszych danych uwierzytelniających, no to wszystko co dzieje się w kontekście zdalnych repozytoriów, Wszystko co chcemy zmerge’ować do głównej głęzi, do głównego brancza powinno podlegać jakiejś kontroli, czyli każde repozytorium w zasadzie powinno być sprawdzane na dwie ręce. Nie ma takiej opcji, żeby jakikolwiek z repozytoriów w naszej organizacji pojedyncza osoba była w stanie sama zaoperować swój Merge Request czy Pull Request i zmerge’ować coś do develop’a czy nie daj Boże do nie daj Boże, do mastera. Tutaj też jest wskazywane to, aby oczywiście zabezpieczyć nasze konta, więc w zasadzie zarówno w GitLabie, jak i w GitHubie, mówiąc o tych największych rozwiązaniach w kontekście zdalnych repozytorów, jak i środowisk CI-CD, warto jest wymusić używanie uwierzytelnienia dwuskładnikowego. No bo nawet jeżeli nasze hasło wycieknie, no to jest to, co powtarzamy jak mantra, zawsze trzeba będzie skorzystać jeszcze z tego drugiego czynnika. oraz implementacja list privilege dla CICD. Często gęsto jest tak w organizacjach, że do środowisk takich jak właśnie GitHub czy GitLab dostęp mają nie tylko deweloperzy, ale również engineering managerowie czy powiedzmy product ownerzy, product managerzy. celem trakowania pewnych statystyk i metryk, m.in. metryk związanych z DOROM od Google’a czy innymi tego typu frameworkami. I TISA mówi tutaj bardzo wyraźnie przez ten punkt, że nie wszyscy muszą mieć możliwość np. uruchamiania pewnych pipeline’ów, które są w tych systemach, do tych repozytoriów podpięte. Każdy użytkownik w naszej organizacji tego typu systemów powinien mieć minimum uprawnień, żeby dobrze wykonywać swoją pracę i nic ponad to. Drugi scenariusz, o którym mówi CISA i NSA to jest kompromitacja naszego supply chain, naszego łańcucha dostaw poprzez jakąś bibliotekę, którą zaciągamy, kontener dockerowy, który wykorzystujemy w ramach budowania czegoś w naszym CIU, bądź poprzez jakieś narzędzie, które wykorzystujemy właśnie podczas budowy naszej aplikacji. No i tutaj W zasadzie rekomendacje dotyczące mitygacji są jasne, czyli nie powinniśmy pozwalać tak naprawdę na możliwość dołączenia niezaufanej paczki. Dzisiaj jeszcze będziemy mówić o tych niezaufanych, złośliwych paczkach. Niezaufany to mogą być też takie w kontekście organizacji, która posiada własny prywatny rejestr paczek, takie, które pochodzą po prostu z internetu. Duże organizacje, o ile mają taką możliwość, o ile ich stać, to utrzymują własne rejestry paczek wewnętrznie, które są odpowiednio filtrowane i w zasadzie płacą za to, żeby mieć ten sygnał, a nie szum w swoich rejestrach. Chciałeś coś dodać, Andrzej, w kontekście analizowanego kodu, commitów?
Andrzej: Tak, niekoniecznie pod kątem analizowanego kodu i commitów, tylko tych repozytorów, o których wspomniałeś. Organizacje często mają własne repozytoria głównie z tego powodu, że po prostu mają większe portfolio aplikacji. i opłaca im się utrzymywać swoje własne repozytorium. Przede wszystkim dlatego, żeby nie ściągać cały czas z oficjalnych repo, tylko ściągać z własnej infrastruktury. To po prostu zmniejsza nawet nie tyle koszt, co zmniejsza szybkość, albo inaczej zwiększa szybkość i pozwala też na budowanie paczek w jakimś jednym konkretnym centralnym repo. Bo zakładam, że mówimy tutaj o przykładowo Artifactory, są na Taipie, Nexusie. Ale to taka mała uwaga, ciśnij dalej.
Krzysztof: Tutaj taka wskazówka od NSA i CIS. Szczególnie w kontekście bardziej zaawansowanych organizacji warto jest pomyśleć, aktywnie obserwować to, co się dzieje w runtime’ie na maszynach, na których hostujemy nasze runnery. Na przykład wykorzystując tego typu rozwiązania jak Falco, o zgrozo od Sysdig’a, o którym mówiliśmy wcześniej, ono jest już open source’owe. Czyli jeżeli w trakcie budowania jakiejś aplikacji nagle się okazuje, że ten to, co się dzieje w trakcie budowania, próbuje np. dampować zmienne środowiskowe z runnera, czy odczytywać jakieś pliki na fail systemie, no to np. korzystając z Falco i predefiniowanych tam reguł, albo pisząc własne reguły, będziemy w stanie dostrzec pewną anomalię i pewne nieprawidłowości. Więc tutaj CISA mówi o rozwiązaniach typu EDR, pewnie dosyć zaawansowanych, ale można wykorzystać też rzeczy open source’owe. Oczywiście zalecenia, które mówią o tym, żeby utrzymywać nasze runnery i wszystko to, co w nich wykorzystujemy do budowania up to date. Trzeci scenariusz to jest kompromitacja naszego środowiska CICD, np. w kontekście takich sytuacji, w których nasze repozytorium jest osobnym bytem całkowicie, Tak jak możemy mieć to w takiej sytuacji, kiedy mamy Jenkinsa jako nasz build system, a GitHub czy GitLab jest tylko miejscem, w którym przytrzymujemy kod, czyli kompromitowany jest wtedy sam Jenkins. i to nie jest wcale tak bardzo abstrakcyjne. Na początku tego roku Jenkins przechodził mały kryzys w związku z podatnością, która umożliwiła odczytywanie plików z filesystemu, więc atakujący bardzo szybko przeszli do aktywnego rekonesansu, wykorzystując stosowne narzędzia i wyszukiwali instancje, publicznie wystawione instancje Jenkinsa i kompromitowali po prostu środowiska CI, włamując się do nich i dampując przy okazji sekrety. Więc tak, takie trzy scenariusze zagrożenia, o których mówi CISA i NSA, ten papierek nie jest może jakimś super świeżą sprawą, bo tak jak powiedziałem, ma już kilka miesięcy. ale polecam do niego zajrzeć, szczególnie jeżeli jesteś sysopsem, dwopsem czy generalnie opsem i zarządzasz infrastrukturą, być może część z tych rekomendacji jesteś w stanie wdrożyć relatywnie niskim kosztem, tak jak na przykład na przykład wymuszenie uwierzytelnienia dwuskładnikowego dla wszystkich, którzy mają dostęp do czy to twojego build systemu, a jeżeli korzystasz z GitHuba, w którym masz to zintegrowane, no to do takiego całego jakby portfolio związanego z i utrzymywaniem repozytorów i ECI.
Andrzej: To, co ja tutaj dodam, to to, że te wszystkie porady, one są bardzo oczywiste i często można się spotkać z taką opinią właśnie od osób operacyjnych, że no kurczę, no to przecież to każdy wie, że to trzeba tak robić, to nic szczególnie odkrywczego. Zgadza się, to nie jest nic odkrywczego, to jest coś, co powtarza, ale Wartość, która leży tutaj przykładowo w tym konkretnym papierku, o którym Ty mówisz, wypuszczonym przez NSA i przez CISE. Wartość tutaj jest taka, że mając taki oficjalny dokument możemy lepiej wykorzystać, może nawet nie lepiej, ale możemy go wykorzystać przy wnioskowaniu o budżet lub przy argumentacji o to, żeby coś zrobić, żeby pewne zmiany wprowadzić. Czemu? Bo możemy się oprzeć na takim dokumencie i powiedzieć, o proszę, my już dawno chcieliśmy zrobić uwierzytelnianie dwuskładnikowe do krytycznych elementów naszej infrastruktury odpowiadającej za budowanie jakichś paczek. Ale Wy, biznes, nie chcieliście się na to zgodzić. No to patrzcie, teraz tutaj CISA i NSA jasno mówią, że to powinno być zrobione. To powinno być zrobione. Oczywiście taką argumentację można poprzeć dalszą ilością danych na temat ataków, które cały czas z roku na rok się zwiększają właśnie na systemy budowania software’u i paczek, które są częścią software’u. Więc to nie chodzi o to tylko, żeby wziąć jeden dokument, ale żeby użyć go do argumentacji w momencie, kiedy chcemy wprowadzić jakieś zmiany. i takiej uargumentowana pozycja wygląda dużo lepiej, ale też nam samym pozwala się zastanowić, co ma większy sens, co ma mniejszy sens, co ma przez to większy priorytet, co ma mniejszy priorytet. I odnieść sukces właśnie w takim przedstawianiu tego do biznesu, no bo też biznes niejako kalkuluje zyski i straty i inaczej podejdzie do argumentacji, która jest typu powinniśmy to zrobić, bo tak, a inaczej podejdzie do argumentacji, która opiera się na czymś, co jest po prostu uznane. Tutaj nie ma się co obrażać na świat, no po prostu tak. Tak to działa, więc takie papierki można wykorzystywać właśnie przy przybudowaniu argumentacji do zmian, które chcemy wprowadzać w organizacji. Czy to większych, czy to mniejszych. By the way, znalazłem ten artykuł o Chicago Fire, Great Chicago Fire w 1871, więc faktycznie coś takiego miało miejsce. Nie wydawało mi się, tylko faktycznie było. No i tam prawie 300 osób poniosło śmierć. Było na obszarze około 9 kilometrów kwadratowych, więc całkiem duży obszar spłonął. 17 tysięcy budynków. zostało zniszczonych i koszt całkowity obliczony na tamten czas wynosił 222 miliony dolarów. No a jeśli weźmiemy to przeliczymy przez inflację, no to koszt dzisiejszy, a przynajmniej na rok 2022, przypominam mamy 2024, inflacja jeszcze poszybowała do góry, no ale na 2022 wynosił 5,4 miliarda. nie milion, po angielsku to miliard, więc bardzo dużo, koszt był duży, no i wiele różnych pożarów doprowadziło do tego, żeby wprowadzić pewne zmiany, przygotowania i ten artykuł z Google’a tutaj zrobił świetne połączenie pomiędzy właśnie pożarami a phishingiem. Kolejna, kolejna wrzutka, no może nie tylko, nie tyle wrzutka, to coś, co gdzieś tam wpadło mi ostatnio na maila, bo subskrybuję listę Openwallową, to, to slajdy z prelekcji, więc to jeszcze nie jest prelekcja z Offensiveconu od, od, kurczę, teraz zapomnę, zapomnę, od Aleksandra, Aleksandra Poljakowa, chyba, chyba tak, się nazywa głównodowodzący Open Walla, czyli autor John Deripera i wielu innych narzędzi związanych z bezpieczeństwem. Solar Designer taki manik. Solar Designera to myślę, że Stara Gwardia powinna bez problemu kojarzyć. To jest taki old schoolowy haker. który na bezpieczeństwie zjadł zęby. Ja o nim pierwszy raz usłyszałem, no jak wchodziłem w hakowanie mając 11-12 lat. No i do tej pory siedzi, do tej pory w tym siedzi i zrobił taką prezentację, prelekcję odnośnie tego w jaki sposób hakuje się hasła, o tym jak to wyglądało w przyszłości, jak to wygląda teraz i co może przynieść przyszłość. Ja nie będę odnosił się do żadnych konkretnych faktów, które były wyłonione w tej prezentacji z dwóch powodów. Po pierwsze dość trudno się ją czyta, ona jest wypakowana informacjami, natomiast widać, że potrzebne jest wideo, żeby po prostu posłuchać jak Aleksander o tym opowiada. i dopiero na kanwie tego wyciągnąć jakieś konkretne wnioski, co ja zrobię w przyszłości, jak tylko wideo zostanie udostępnione, a raczej zostanie udostępnione, bo Offensive.com udostępnia swoje wideo, więc czekam na to wideo, ale to co mi gdzieś tam zapaliło lampkę, To po pierwsze to, że krakowanie haseł wcale nie jest takie proste jak mogłoby się wydawać od strony takiej implementacji. Jak zaimplementować rozwiązanie takie jak John the Ripper czy Hashcat pod kątem tego, żeby sprawnie łamać hasła, więc to nie jest tak, że po prostu próbujemy odkryć całą przestrzeń dostępnych haseł. Jest wiele różnych trików, heurystyk, które możemy użyć po to, żeby ułatwić sobie krakowanie hasła, a przez ułatwienie mam na myśli, żeby zużyć mniej energii, żeby wykonać mniej obliczeń, czyli żeby ogólnie zmniejszyć przestrzeń opcji, którą musimy eksplorować, po to, żeby znaleźć hasło, którego szukamy, żeby złamać hasz.
Krzysztof: Czyli Andrzej, mówiąc to dla naszych słuchaczy troszeczkę prostszymi słowami, to nie jest taki tempy, a tak brute force, w którym próbujemy każdą kombinację aż do skutku.
Andrzej: Nie, tak to wygląda na samym początku, wiele, wiele lat temu, w zasadzie dekad. Tak to wygląda na samym początku, natomiast potem idąc w las, było wprowadzanych wiele różnych heurystyk do narzędzi, które się pojawiały, m.in. do Johna de Rippera, po to, żeby właśnie sobie ukrócić, żeby zmniejszyć ten cały zbiór ewentualnych haseł, które musimy przetestować, żeby nie trzeba było eksplorować całej przestrzeni możliwości. I jest to tutaj właśnie opisywane, tutaj Aleksander robi świetną robotę przechodząc przez historię tego wszystkiego, historię łamania haseł na komputerach. Bardzo fajnie to robi, tylko tak jak widać widzicie na ekranie pewnie te slajdy są dość dość upakowane wiedzą i widać, że po prostu potrzebna jest ta narracja od Aleksandra, który po prostu opisuje, co konkretnie widzimy, na przykład na tym slajdzie, który teraz pokazuje. Trudno jest tutaj wyłapać, o co konkretnie chodzi. Potrzebujemy tą narrację od autora, ale jest wiele różnych danych, które możemy wyciągnąć i przykładowo taką jedną daną, którą wyciągnąłem i która mnie zaskoczyła, to to, że serwis Have I Been Pwned od Troya Hunta w zasadzie dysponuje. dysponuje bazą prawie miliarda, miliarda haseł. Złamanych, złamanych haseł. Więc to jest bardzo dużo. Z różnych, z różnych wycieków danych na przestrzeni lat. Have I Been Pwned jest nie od wczoraj, chyba już ponad dekadę, a przynajmniej blisko dekady jest dostępne. Więc na przestrzeni lat zbierają i oczywiście też łamią te hasła, robiąc wiele różnych feature’ów, które można wykorzystywać po to, żeby bronić naszych użytkowników. Natomiast ta liczba trochę mnie przyprawiła o zdumienie, że to jest prawie miliard, bodajże około 900 milionów, więc bardzo dużo. I to mi tak zostało w głowie. Jeszcze jedna rzecz, jeszcze jeden fakt. Tutaj zapalił mi lampkę, ale na ten moment nie mogę go sobie przypomnieć. Jak na złość wypadł mi z głowy. Natomiast samych slajdów nie polecam wchodzić i czytać, dlatego że są po prostu trudne w zrozumieniu. Jeśli ktoś będzie chciał po prostu z czystego zainteresowania posłuchać o tym, jak się łamie hasła, to polecam zaczekać na tą prezentację, a jeśli nie, to po prostu odcinek naszego podcastu, w którym jak tylko ta prezentacja się pojawi, to ja bardzo chętnie odsłucham i wtedy sobie spiszę już konkretne notatki z tego, co Aleksander mówi, a nie tego, co jest tylko na slajdach, bo slajdy są po prostu upakowane tekstem i trudno wyciągnąć z nich kontekst. odnośnie tego, co zostało powiedziane. Więc za slajdy Aleksander dostaje trzy z plusem, max, ale jestem pewien, że za prezentację już na żywo za wideo dostanie piątkę, bo Aleksander swoje wie. No i tyle odnośnie mojej wrzutki. To chyba wpadło mi na skrzynkę wczoraj albo przedwczoraj, więc też dość świeży kąsek. Ja mam jeszcze jedną rzecz, o której mogę wspomnieć, ale najpierw oddaję mikrofon w Twoje ręce Krzysiek i wskakujemy w Twoją.
Krzysztof: Dobrze, w takim razie chciałem opowiedzieć bardzo krótko o tym, czym zajmuje się DataDog. DataDog możecie kojarzyć, bo jest to dosyć popularne narzędzie do monitoringu, teraz również opakowane pewnymi funkcjami dotyczącymi bezpieczeństwa. Datadog już od dwóch
Andrzej: lat
Krzysztof: aktywnie skanuje dwa rejestry paczek NPM-a i PyPI-a przy użyciu swojego autorskiego narzędzia, które nazywa się GuardDoc, i skanuje w poszukiwaniu złośliwych paczek, niepodatnych paczek, czyli takich, których błąd został popełniony nieumyślnie i wynikła tam z tego błędu jakaś podatność, tylko specjalnie, intencjonalnie złyśliwych paczek, które podczas instalacji, przeważnie podczas instalacji mają na celu zainfekować czy to maszynę dewelopera, czy to środowisko CI, w których ta paczka będzie wykorzystywana podczas budowania całej aplikacji. Więc w zasadzie od końca 2022 roku oni przeskanowali, znaleźli blisko 1500 złośliwych paczek zarówno łącznie w NPM-ie i PIPI-u. Ciekawy jest fakt, że jeden taki skan takiej paczuszki zajmuje im trochę ponad 17 sekund. Jak on jest relatywnie niedużo, chociaż biorąc pod uwagę całą skalę np. NPM-a, to naprawdę ten ich skan musi chodzić dzień i noc. To, co tutaj Datadog opisuje w swoim artykule, to przykład paczki, która nazywała się Really Do Nothing, ale nie bądźcie złudni, ona naprawdę jednak coś, coś robiła i robiła coś złośliwego. To jakie heurystyki tutaj zostały wykorzystane przez Datadoga do detekcji tego, że ta paczka jest złośliwa, to to na przykład to, że Deskrypcja, opis tej paczki był pusty, co w zasadzie w normalnym świecie nie ma miejsca w przypadku paczek, które są legitne. To, że ta paczka w zasadzie posiadała tylko jeden pojedynczy plik, tutaj mówimy o Pythonie, czyli ta paczka była brana z PyPI i to też wzbudziło uwagę. To, że ta paczka nadpisuje komendę instalacyjną, czyli Kiedy robimy pip, install i nazwę naszej paczki, nadpisując komendę instalacyjną możemy po prostu na przykład sterować tym, co w tym procesie instalacji tej paczki się dzieje oraz to, że sama paczka w środku zawierała referencje do wykonania funkcji systemowych, co już dopełnia tylko tego, że coś z tą paczką raczej jest nie tak. Datadog tutaj zdradza szczegóły, że w zasadzie automatycznie detekcja takiej paczki, skan takiej paczki, triggeruje im triaż, wysyłają sobie to webhookiem na Slacka, akurat poznaje po user interfejsie, i w zasadzie dokonują właśnie takiej manualnej oceny, czy faktycznie to, co GuardDog, ten ich skaner, znalazł, jest czymś, czym warto się zainteresować. Nie wchodząc tutaj za bardzo w szczegóły i analizując kod tej paczki, chcę powiedzieć, że to, co było ciekawe w tym konkretnym przykładzie, to to, że ta paczka była stricte dedykowana infekcji systemów macOS. Jest to podyktowane tym, że Ta paczka podczas instalacji szukała bardzo konkretnej ścieżki, Library Application Support i potem już były GlobPattern, ale sam początek tam zdradza, że chodziło po prostu o systemy oparte, o systemy właśnie z rodziny Apple, o Macie. To, co się dzieje przeważnie w większości przypadków tego typu sytuacji, to jest to, że sama paczka jest pewnym medium do tego, aby w trakcie instalacji tak naprawdę zaciągnąć z zewnętrznego serwera kontrolowanego przez atakujących prawdziwy malware, który jest potem osadzany na maszynie, na której ta paczka jest instalowana, czyli Sam złyśliwy kod odpowiedzialny za to, żeby coś z tej maszyny ukraść, żeby ją zainfekować, to tak naprawdę jest testowany na serwerze atakujących. Ta binarka jest zaciągana i odpalana w ramach procesu tej instalacji, więc PyPI i ta paczka służy tutaj tylko bardziej za pewien medium, za pewien wektor ataku. I tak, polecamy w zasadzie zainteresowanie się tematem Guard Doga. To jest jedno w tym momencie z fajniejszych takich open source’owych narzędzi, które pozwala nam na ocenę, czy dana paczka zdradza jakieś heurystyki bycia złośliwą.
Andrzej: Wiesz co, Krzysztofie, ja tutaj dodam, bo też patrzyłem na ten papierek, na ten post od Tata Doga. Oczywiście również polecam zainteresowanie się tym narzędziem i przynajmniej przetestowaniem. Zobaczymy jak ono działa i czy da się je użyć w swoim zastosowaniu, w swoim kontekście. Natomiast wspomniałeś o szukaniu konkretnych rzeczy w PAF-ie po to, żeby odpalić Stage 2. Tak to się przy malwareze nazywa. Najpierw mamy dropera Stage 1, który jest tą pierwszym inicjalnym wektorem. i jeśli chcemy kontynuować atak, no to przechodzimy do Stage 2 i przykładowo ściągamy z jakiejś określonej domeny już konkretny malware, który będzie coś robił, który będzie miał nazwijmy to logikę biznesową, przykładowo będzie keylogerem. Albo po prostu da nam Remote Access Control do danego systemu, do danego boxa. Natomiast to co tutaj jest ciekawe przy tym PUFie to nie tyle, że on atakował konkretne, że on atakował macOSa, bo to niejako wynika sam przez się, bo po prostu sprawdza macOSowe PUFy. Więc niejako już wtedy wiemy, że atakuje macOS, użytkowników macOS-a, ale on, tam wspomniałeś o Globepatternach i on atakował pewien wycinek użytkowników macOS-a. i to się wiąże z tym o czym już mówiliśmy w naszym podcaście o atakach na deweloperów, na ludzi w procesie wytwórczym, generalnie na użytkowników technicznych i atakowaniu konkretnych, konkretnych, konkretnych prawdopodobnie. Tak, instancji, konkretnych organizacji, konkretnych wycinków użytkowników danego ekosystemu. I czemu mówię, że o tym wspominaliśmy? Wspominaliśmy o tym, gdy mówiliśmy o całym problemie związanym z XZ. gdzie tam też to, w jaki sposób ten bug był wprowadzony, to w jaki sposób pewne rzeczy były zapisane w logice biznesowej, jasno wskazywał, jaki też błąd, jaka podatność była wykorzystana, niejako wskazywały. że ofiarą tego ataku nie byli wszyscy, tylko była jakaś określona grupa użytkowników, która najwidoczniej miała w swoich systemach właśnie takie ustawienia. i tutaj dokładnie to samo. Ofiarą tej kampanii, tego ataku nie byli wszyscy użytkownicy, tylko był jakiś wycinek, prawdopodobnie jakaś organizacja, która w tym PAFie ma coś, ma jakieś konkretne narzędzie, które jeśli się zmatruje, no to faktycznie to będziemy musieli przejść do tego Stage 2, ale jeśli się nie zmatchuje to tego nie rób. A czemu to robimy? Po pierwsze żeby być bardziej precyzyjni, ale bardziej precyzyjni często gęsto chcemy być dlatego żeby wygenerować mniej, mniej sygnału, który może, który można wykryć i dzięki czemu nasza kampania jako jeżeli mówimy z perspektywy atakującego Nasza kampania może zostać wtedy spalona, możemy zostać spaleni, więc chcemy być jak najbardziej cicho, chcemy działać cicho po to, żebyśmy nie zostali wykryci, a jednym z sposobów na działanie cicho jest po prostu atakowanie tylko tych, maszyn, na których nam zależy. Jeśli jesteśmy w stanie wykryć jakiś taki magiczny, magiczny kawałek, z którego korzysta na przykład tylko dana organizacja, no to jesteśmy potem w stanie sprawdzać, czy ten kawałek oprogramowania jest na maszynie. Jeśli jest, to atakować, a jeśli nie, to nie atakować. Wtedy zmniejszamy prawdopodobieństwo takiego oportunistycznego wykrycia przez postronnych obserwatorów, których my tak naprawdę atakować nie chcemy. I to był taki dość duży dla mnie wniosek z tego artykułu. Właśnie to, że widzimy wzrost tego typu działań, ale widzimy wzrost tego typu działań nawet na użytkowników takich zwykłych końcowych. Ta operacja raczej nie była wykonana przez Nation State, tylko raczej przez jakąś grupę przestępczą, która chce się dostać do jakiejś organizacji. A to trochę nazwijmy to zapala lampkę, bo widzimy wzrost tego typu działań. Coś, co kiedyś działo się raczej właśnie w momencie, kiedy Nation State chciał zaatakować inny Nation State, przykładowo Stuxnet, Stuxnet. który atakował tylko konkretne komputery, które były w konkretnym miejscu i które były odpowiedzialne za konkretną funkcjonalność biznesową, tak to nazwijmy, po prostu wzbogacanie uranu. A innych nie. I innych nie atakował. Czemu? No bo była to jasno skrojona broń. To teraz po dekadzie, bo Stuxnet to był pomiędzy 2000 a 2010, Teraz już po jednej dekadzie i wchodząc w kolejną dekadę, lata dwudzieste, trzydzieste, widzimy, że ten styl atakowania się trochę, nazwijmy to, zdemokratyzował i to, co kiedyś mogliśmy jako broniący, mogliśmy po prostu zaakceptować lub zmniejszyć tego wagę, mówiliśmy, że raczej nie, u nas raczej się nie stanie. W chwili obecnej, no jak Najwidoczniej zaczyna się dziać, czyli atakujący, którzy są motywowani motywem finansowym zaczynają używać taktyk, technik, procedur, które wcześniej były zarezerwowane bardziej dla nation state, czyli po prostu się też uczą. Jedna uwaga odnośnie tej mojej wrzutki o password tracking. przypomniało mi się co miałem na myśli, więc wiedziałem, że zaraz mi się przypomni. Dwie rzeczy, mianowicie ten główny wniosek, który mi się przypomniał i który chciałem wypunktować to to, że tego typu listy, które służą do łamania haseł, tak jak wspomniałem o Hawaii Bean Pound, które ma tutaj widać prawie 900 milionów unikatowych haseł, wyciągniętych z wielu, wielu, wielu wycieków danych na przestrzeni lat. Lista Roku, która jest czystsza, ale która jest mniejsza. Ona posiada około chyba 40 milionów haseł. Należałoby zrobić dość bezpieczne założenie, że właśnie Nation State albo aktorzy, którzy generalnie mają dość duże zasoby finansowe, prawdopodobnie mają dużo, dużo większe listy, dzięki którym mogą bez problemu bez większego problemu złamać nasze hasła, o ile nasze hasła nie są albo wygenerowane w menadżerze haseł, który pozwala na generowanie przykładowo 32 znakowych losowych haseł, które bardzo trudno jest złamać, bo są losowe, albo jeśli korzystamy po prostu z uwierzytelniania dwuskładnikowego, które nawet jeśli ktoś pozna nasze hasło, to jednak zatrzyma zatrzyma atak, zatrzyma takie uwierzytelnienie, nawet jeśli ktoś pozna nasze hasło, no bo będziemy potrzebowali tego drugiego faktora. Więc co? Raczej należyłoby założyć, że takie działania gdzieś tam się dzieją i jeśli nazwijmy to white hat hakerzy, czyli bezpiecznicy, researcherzy mają dostęp do tak dużych zbiorów haseł, jak zbiór, który ma prawie 900, prawie miliard, haseł, to można założyć, że ci, którzy robią na tym pieniądze mają dwa albo trzy razy większe zbiory haseł, bo tutaj chodzi tylko o koszt. Koszt utrzymania takiej bazy, koszt potem odpytania jej, ale da się to zrobić, tylko po prostu będzie to nas kosztować, ale jeśli ktoś robi na tym biznes i ten biznes to nie są tysiące czy nawet setki tysięcy, tylko takie biznesy idą w dziesiątki czy setki milionów dolarów, no to będzie się takiej organizacji po prostu opłacało. Posiadanie dużych zbiorów haseł i aktualizacja tych zbiorów haseł na bazie coraz to nowych wycieków haseł z różnych portali. Więc to jeden taki duży niosek, który wyciągnąłem z tych slajdów, a dwa to nie wiedziałem wcześniej, że istnieje takie narzędzie też właśnie od Aleksandra, czyli od projektu OpenWall, OWL, które pozwala na sprawdzanie siły hasła i ono się nazywa, tutaj było gdzieś na slajdzie, ale już otworzyłem, PassWD Quality Control, QC. I można to robić właśnie z dużą listą z Have I Been Pwned. Można też z trochę mniejszą, oczywiście to trochę kosztuje. Jeśli chcemy kupić możemy sobie zbudować swoją listę, nie musimy korzystać z tej, ale jeśli nie chcemy budować, nie chcemy tracić czasu, to możemy skorzystać też z tej wbudowanej listy.
Krzysztof: Ok, bardzo ciekawe. W kontekście mierzenia siły haseł to przypomina mi się na myśl paczka od Dropboxa, np. mowa ZXO. Będzie w referencjach na 100%, która w bardzo prosty sposób umożliwia zwrócenie jednego z pięciu wartości, czy hasło jest silne. No i na frontendzie pokazujemy potem użytkownikowi. To fajnie uczy użytkowników, przy okazji ściąga z nas to, co w kontekście rejestracji jest bardzo istotne, czyli friction, czyli nie wymagamy nie wiadomo jak silnych haseł przy rejestracji, tylko graficznie pokazujemy, że hej, twoje hasło jest słabe, może mógłbyś coś z tym zrobić.
Andrzej: Tak dokładnie to podamy referencję albo inaczej podamy linki w referencjach i jeżeli ktoś będzie tym tematem zainteresowany to to będzie mógł przeklikać będzie mógł samemu się tymi narzędziami pobawić. Dobra co Krzysiek robimy rap up bo i tak już jest godzina dwadzieścia. to jest ewidentnie za za długo. za długo znowu się nie wyrobiliśmy. Dobrze to to to co pozwolę ci zamknąć. ja otwierałem to ty zamykasz.
Krzysztof: Tak, no to dziękujemy, że z nami jesteście. Słuchajcie, subskrybentów na kanale przybywa. Zapraszajcie znajomych. I też dziękujemy, bo nie wiem, Andrzej, wiesz, czy tobie wspominałem, ale mamy już osoby, które same nam podsyłają materiały. Pozdrawiam tutaj tą osobę i obiecuję, że to, co podsyłałeś mi na DM, to zostanie poruszone w następnym odcinku. Zapraszamy do słuchania. Mamy nadzieję, że się podobało. No i co? Do zobaczenia.
Andrzej: Do zobaczenia, do usłyszenia kolejnym razem. Trzymajcie się.
Krzysztof: Trzymajcie się, hej.