W najnowszym raporcie Cloudflare „Application Security Report 2024” ujawniono, że ponad 30% globalnego ruchu generują boty, z czego ponad 90% to boty niezweryfikowane. Dodatkowo, Raport Cloudflare 2024 stwierdza, że ponad 60% ruchu sieciowego stanowi ruch API, a około 25% tego ruchu kierowane jest do nieudokumentowanych „Shadow API”.

Raport podkreśla również, że przeciętna aplikacja korporacyjna ładuje około 47 zewnętrznych skryptów, co stwarza ogromne ryzyko w łańcuchu dostaw (np. ataki na CDN). Omówiono trudności we wdrażaniu Content Security Policy (CSP) i Sub-resource Integrity (SRI).

Analizujemy, jak szybko eksploitowane są podatności Zero Day (np. JetBrains TeamCity – 22 minuty od publikacji POC). Podkreślamy potrzebę automatyzacji i centralizacji rozwiązań bezpieczeństwa przez dużych dostawców, mimo związanych z tym ryzyk systemowych.

Na koniec, zwracamy uwagę na ataki grupy Lazarus (APT28) z Korei Północnej, którzy celują w inżynierów poprzez fałszywe rekrutacje i złośliwe zależności w projektach programistycznych, co przyniosło im 4 miliardy dolarów. Zaskakujący jest też przypadek zatrudnienia północnokoreańskiego hakera w firmie KnowBe4, co uwypukla wyzwania związane z weryfikacją tożsamości w pracy zdalnej.

Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.

Transkrypcja

Andrzej: Dzień dobry. Witamy was w kolejnym odcinku podcastu Bezpiecznego Kodu. Tym razem wydanie newsowe. Zabrakło nam ostatniego wydania dwa tygodnie temu naszego newsowego. Byliśmy trochę w rozjazdach. W zasadzie to technicznie ja byłem bardziej w rozjazdach niż Krzysiek. No, ale nie udało się tego zgrać, wracamy z podwójną siłą i wypoczęci, bo akurat mój wyjazd był, no powiedzmy, wakacyjny. Wakacyjny to był na pewno, ale czy odpocząłem, to niekoniecznie. Natomiast, Krzysiek, co tam słychać u ciebie w ostatnich dwóch tygodniach? Ty już wypocząłeś czy nie? Bo wakacje zmierzają ku końcowi.

Krzysztof: Tak, cześć, witam was wszystkich, witam słuchaczy, witam ciebie Andrzej. Wypocząłem, jest całkiem nieźle, jest całkiem nieźle, chociaż dzisiaj pogoda istnieje barowa w Szczecinie, można by powiedzieć taka londyńska. Ale cóż się spodziewać, no w końcu Szczecin leży nad morzem. Kto wie, kto wie, ten wie. Żeby nie przedłużać tego wstępu, mieliśmy taką rozkminę z Andrzejem, który to jest nasz odcinek tak naprawdę już bezpiecznego kodu podcastu. Zażartowaliśmy sobie, że setny, także piwo dla tego, kto w komentarzu napisze, który to jest odcinek, bo my się nie doliczyliśmy.

Andrzej: Tak, ja próbowałem na szybko to podliczyć, nie wyszło mi. Trochę już tego jest, a tutaj taki side note i komentarz. Rafał, proszę cię, weź to podlicz. Ale dobra, to tyle wstępów. Wskakujemy w to, co gdzieś tam przykuło naszą uwagę w ostatnich kilku tygodniach. Ja od razu dodam jedną uwagę, że na pewno przykułą moją uwagę to, że odbyły się dwie największe konferencje związane z bezpieczeństwem, mianowicie Black Hat i DEF CON i tam było kilka dodatkowych wydarzeń wokół tych konferencji, które są zawsze co roku, ale nie miałem jeszcze czasu, żeby faktycznie wejść, popatrzeć, co tam ciekawego było. Oczywiście na Twitterze bardzo dużo osób się wypowiadało, no ale jeśli się nie ma czasu, żeby faktycznie wejść w jakieś szczegóły, to na chwilę obecną zaparkowałem ten temat i pewnie wrócimy do niego dopiero w kolejnym odcinku. Natomiast w tym odcinku zaczynamy od raportu, który w zasadzie wyszedł jeszcze w lipcu, natomiast ja zobaczyłem go dopiero na początku sierpnia, o nazwie Application Security Report 2024. Aktualizacja. Ten raport jest z Cloudflare. Myślę, że Cloudflare większość osób będzie kojarzyć, ale gdyby ktoś nie kojarzył, to powiem czym jest Cloudflare. To jest jeden z największych dostawców CDN-a na świecie. Przez to, że dostarczają CDN-a, mają niejako unikatowe spojrzenie na sieć, na ruch sieciowy, no bo obsługują bardzo duże organizacje na świecie i obsługują ich pod kątem sieciowym. CDN to jest Content Delivery Network. Oczywiście na chwilę obecną oferują dużo więcej usług niż tylko CDN, ale od tego startowali. I dzięki temu, że mają tą pozycję jaką mają i mogą obserwować większość ruchu w internecie, bo nawet jeśli jest ten ruch obsługiwany przez nich, to znaczy nie jest ich klientów, no to końcem końców często przechodzi albo leci do ich klientów, więc i tak go widzą, no to są w świetnej pozycji na to, żeby budować takie raporty i dawać nam insajty, co w trawie piszczy pod kątem nie tylko bezpieczeństwa, ale też ogólnej wydajności. I Krzysiek, tu mam pierwsze pytanie. Czy ty w ogóle kojarzysz Klauffler jako dostawcę? Czy miałeś z nimi kiedyś jakikolwiek styk od strony technicznej jako odbiorca? Czy po prostu gdzieś tam słyszałeś, ale nigdy nic nie dotykałeś?

Krzysztof: Ja miałem z nimi bardzo dużo do czynienia, szczególnie z X-Supportem francuskim, którego szczerze pozdrawiam za nierozwiązanie moich wszystkich pięciu etiketów, które zgłosiłem. Ale tak pół żartem, pół serio nie. Oczywiście ja w wielu projektach korzystałem z Cloudflare’a jako bezpiecznik. głównie obsługując tam i konfigurując web application firewalla i przeglądając alerty, które na web application firewallu się odbijały. Także w tym kontekście tak miałem styczność z Cloudflarem i myślę, że większość inżynierów, szczególnie tych, których pracuję w środowisku webowym, po prostu słyszało bądź też korzystało z Cloudflara. To nawet, wiesz Andrzej, przechodząc po sieci jest bardzo ciężko się nie odbić gdzieś, gdzie widzimy, że jesteśmy łapani przez capture cloudflare’ową czy przez inne mechanizmy, nawet jeżeli będziemy podglądać requesty pod spodem jakie idą, to bardzo często jakiś z nich właśnie do cloudflare’a czy przez cloudflare’a przechodzi.

Andrzej: Tak, jest dokładnie tak jak mówisz, czyli niejako sam Cloudflarem. myślę, że każdy ma do czynienia, czy świadomie, czy nieświadomie to inna kwestia, ale sam Cloudflarem każdy ma do czynienia, bo po prostu bardzo duża ilość ruchu jest przez niego obsługiwana, czy to właśnie pośrednio, czy bezpośrednio. Natomiast moje pytanie wynikało z tego, że ja prowadząc szkolenia Spotykam się czasami z sytuacją, gdzie odbiorcy nie kojarzą, może nawet nie tyle Klautlera, ale nie kojarzą CDN-ów, bo daje skrót CDN i czasami następuje pytanie, Co to jest CDN? Content Delivery Network i jednym z największych przykładów jest Cloudflare. Cloudflare już gdzieś tam tą lampkę zapala, ale sam CDN nie zawsze jest rozpoznawany. I znowu, albo może nie znowu, dla mnie ciekawe jest to, że ty miałeś z tym do czynienia, ale ty niejako pracujesz. masz dużo styku z bardziej takimi techami i startupami, nie, z takimi bardziej zwinnymi organizacjami. Natomiast ja mam sporo styku z dużymi organizacjami, które, które są z racji tego, że są duże, są trochę wolniejsze, trochę wolniej adaptują różne technologie. Często, gęsto też nie mogą adaptować jakichś zewnętrznych takich dostawców jak Cloudflare. No i wtedy te zespoły niekoniecznie po prostu miały styk z Cloudflarem, o ile nie bawią się nim gdzieś tam we własnym zakresie, w jakichś własnych projektach. Tutaj mówię o tych własnych projektach dlatego, że z Cloudflare’a można korzystać w takim wydaniu darmowym i można zabezpieczać, ale też przyspieszać, optymalizować własne strony i nic nas to nie kosztuje. Mamy wtedy taki bardzo bazowy zestaw feature’ów, które dostajemy od Cloudflare’a. By the way, ja akurat z niego korzystam i sporo, sporo ludzi z tego korzysta. Ale dobrze, przechodząc do samego raportu, jest tu kilka ciekawych insajtów, które sobie wybrałem, nawet wynotowałem sobie w komentarzu, bo trochę ich było. Po pierwsze, Primo, musimy tutaj powiedzieć, od kiedy raport i dane były zbierane, więc na podstawie jakiego wycinku czasu są wyciągane te wnioski. Wycinek czasu to jest 1 kwietnia 2023 do 31 marca 2024. Czyli tak naprawdę pełny rok, ale trzeba brać pod uwagę, że my teraz, mówiąc o tym, mamy już wakacje, mamy sierpień, czyli tak naprawdę mamy pewien offset praktycznie 3-4 miesięczne, offset pomiędzy tym, kiedy skończyli zbierać dane, a dzielą się wnioskami na podstawie tych danych. Oczywiście pewnie wewnętrznie mieli je dużo szybciej, taki wewnętrzny raport. I jedną z takich rzeczy, która od razu można powiedzieć podniosła moją brew, to to, że w zasadzie około 30% w ogóle całego ruchu, który widzi Cloudflare jest generowany automatycznie, czyli jest generowany przez boty, z czego i to też jest ważne, z czego ponad 90% ruchu tego automatycznego jest generowana przez boty, które nie są zweryfikowane przez Cloudflare’a. Więc ja tutaj nie wchodziłem głęboko, Cloudflare pewnie ma jakiś mechanizm, że jeśli jesteśmy na przykład Googlem czy Microsoftem, to możemy powiedzieć albo się przedstawić Cloudflare’owi jako taki bot, który krauluje internet i wtedy Cloudflare nas zalicza do tego ruchu automatycznego, ale zaliczy nas do tych zweryfikowanych dostawców. Natomiast ponad 90% tego ruchu jest od botów, które się albo jasno nie weryfikują, albo nawet generalnie jasno się nie weryfikują. Więc trudno powiedzieć, one mogą być złośliwe, niekoniecznie muszą być złośliwe, ale na pewno jest to ciekawy data point, że praktycznie cały, czyli z tej jednej trzeciej ruchu jest generowany przez jakieś boty i nie wiemy tak naprawdę do końca jakie. Tutaj masz jakiś komentarz.

Krzysztof: Tak, ja tutaj dodam od siebie, że faktycznie pracując z Krautlerem tamta lista zdefiniowanych znanych crawlerów i botów jest dosyć krótka, tam jest bodajże kilkadziesiąt w okolicach 30 z tego co pamiętam takich znanych crawlerów, którzy przedstawiają się jakimś user agentem i na tej podstawie są weryfikowane jako te znane crawlery. ale wydaje mi się, że takich produktów, które przeszukują internet jest dużo więcej niż te kilkadziesiąt, więc wcale bym się nie zdziwił, że 90% pochodzi od tych nieznanych. Niekoniecznie może w całości być to złośliwy ruch, a co do całego wolumenu, że 30% całego ruchu, to tak jestem w stanie to jak najbardziej uwierzyć. Sam w jednym miesiącu u jednego z klientów widziałem, że ByteDance, czyli właściciel TikToka, generuje ruch w okolicach 500 milionów requestów na danej domenie, więc jest tego sporo.

Andrzej: Do tego jeszcze wrócimy, bo tutaj będzie inny ciekawy insight, myślę, że dla nas konkretnie, dla ciebie i dla mnie i dla wszystkich słuchaczy, którzy siedzą w procesie wytwórczym i wytwarzają lub utrzymują systemy, to jest tutaj jeden bardzo ważny i ciekawy insight, ale do niego dojdziemy. On tutaj trochę zahacza właśnie o ten ruch generowany z TikToka, ale nie tylko z TikToka, z innych różnego rodzaju. Natomiast kolejnym insajtem, który tak podniósł mi trochę brew było to, że ponad 60% całego ruchu sieciowego to ruch API. Więc to mnie zaciekawiło, czyli jeśli mamy cały ruch i 60% to API, czyli tak naprawdę już ponad połowa ruchu sieciowego to API. Tu najważniejsze jest to w jaki sposób Cloudflare definiuje ruch API i Cloudflare definiuje ruch API tak, że w odpowiedzi otrzymujemy XML-a lub JSON-a i dla Cloudflare to jest Tak, i dla Klaufflera to jest ruch API, natomiast inny ważny insight jest tutaj, że z tego 60% całego ruchu, około ćwiartki, czyli około 25%, to jest ruch i tutaj pewnie to robi Klauffler na podstawie swoich klientów, ale jest to ruch do końcówek, o których klient istnieniu nie wie, czyli np. nie ma ich tam w oficjalnej dokumentacji etc., czyli są tzw. shadow IT, czyli nie widzimy tego, a to jest ważny kawałek informacji, dlatego że trudno jest bronić coś, czego nie wiemy, że w ogóle istnieje, czyli najpierw musimy wiedzieć, że w ogóle coś mamy w naszej sieci, a dopiero potem możemy zająć się bronieniem tego, no to tutaj kwadratur pokazuje, że w zasadzie całkiem spory kawałek jest niewidoczny dla organizacji. No i ćwiartka, jedna czwarta to całkiem sporo. Natomiast co do tego ruchu API, to chciałbym jeszcze zrobić taką dużą gwiazdkę. że i tutaj to w zasadzie jest takie otwarcie. mini dyskusji z tobą, Krzysiek. Jak ty na to patrzysz? Jeśli mamy API, jeśli mamy jakąś aplikację i ona ma API restowe, mamy jakiegoś klienta javascriptowego, mamy po prostu single page application, to czy ty widzisz jakąś większą różnicę pomiędzy klasyczną aplikacją, która nie jest oparta na API? Chodzi mi o, czy klasyfikowałbyś to jako coś, zgoła innego, bo dla mnie w dużej mierze to jest rozróżnienie logiczne. Czyli na poziomie architektury system wygląda inaczej, ale nie ma większego sensu rozróżniania tego, że ruch mamy generowany przez API lub ruch mamy generowany przez zwykłe systemy. Oczywiście tutaj wiem, że jest jeden duży edge case, czyli ten moment, gdzie ruch jest generowany nie przez klienta z przeglądarki, tylko przez takiego średniego klienta, ale czy ty widzisz tutaj jakieś mocne rozróżnienie, czy ono jest bardziej takie logiczne?

Krzysztof: Dla mnie to jest po prostu rozróżnienie logiczne, bo pod kątem takim stricte technicznym cały czas mówimy o tym samym typie ruchu, mówimy o HTTP, więc w zasadzie nie do końca rozumiem dlaczego tej klątwy w tym punkcie swojego raportu dokonuje takiego rozróżnienia, bo czy mówimy o Single Page Application, czyli ten front-end odpytuje API o dane i zasilanie doma, czy mówimy o aplikacji mobilnej, która też poprzez jakieś API zciąga dane do siebie, czy mówimy po prostu o API, które jest obsługiwane przez naszego własnego klienta, niekoniecznie napisanego w JS, no to w zasadzie i tak pod spodem korzystamy po prostu z HTTP.

Andrzej: Dokładnie, więc ja na to patrzę bardzo podobnie, też nie do końca tutaj rozumiem, na pewno mają swoje jakieś reasoning i być może jest właśnie nim to, że po prostu może się różnić klient i wiadomo, że ze wzrostem API zwiększa się różnorodność klientów, nie? więc co innego może rozmawiać? Tutaj właśnie dobrym przykładem są po prostu systemy IoT, które komunikują się najczęściej z jakimiś API, a nie jest to zwykły klient, czyli po tej drugiej stronie często to nie jest po prostu człowiek, tylko to jest jakiś, nie chcę używać słowa autonomiczny system, ale jest to po prostu jakiś kawałek software’u, jest to jakieś oprogramowanie. Ale dobrze, tutaj jeśli któryś ze słuchaczy będzie miał komentarz do dodania to chętnie wysłucham dodatkowych argumentów za rozróżnianiem tego versus agregowaniem tego pod jeden worek. Natomiast kolejną dla mnie ważną ważnym spostrzeżeniem, ważnym wnioskiem, w zasadzie chyba najważniejszym z tego całego raportu, który przyjął moją uwagę, a przynajmniej na równi z jeszcze innym, do którego zaraz wrócę, ale ten jest dla mnie super ważny. Mianowicie Kanał Obserwator mówi nam, że typowy użytkownik korporacyjny, czyli powiedzmy jakaś web-appka, powiedzmy strona mBanku, to byłby dla nich użytkownik, klient korporacyjny, zawiera, korzysta z ok. 47 zewnętrznych skryptów i zewnętrznych tutaj niekoniecznie, że ładuje je z zewnątrz, bo one mogą być dorzucone do aplikacji na stałe, do paczki, ale w dalszym ciągu są to skrypty, które komunikują się z jakimiś zewnętrznymi usługami, Tutaj chodzi o takie skrypty jak Google Analytics, jak Hot Jary, właśnie jak TikTok, tutaj nawet to punktują, jak jQuery, jQuery często pobiera się z jakiegoś CDN-a, więc myślę, że każdy tutaj programista nie będzie miał problemu z określeniem, o co tutaj konkretnie chodzi, natomiast tych skryptów jest całkiem Sporo. Tych skryptów jest całkiem sporo ładowanych i po pierwsze one generują dużo ruchu, ale jak już pewnie zdajesz sobie sprawę do czego zmierzam, generują też oczywiście zagrożenie pod kątem łańcucha dostawczego. bo o ile taki skrypt nie jest wbudowany w paczkę, tylko jest zaciągany dynamicznie po stronie klienta właśnie z jakiegoś CDN-a, no to oczywiście to otwiera nam drogę do tego, że jeśli na tym CDN-ie byłby podmieniony, to atakujemy wszystkich użytkowników tego CDN-a, którzy korzystają z niego do zaciągania tych zewnętrznych skryptów, a jak widzimy tych skryptów jest całkiem dużo w przeciętnej korporacyjnej aplikacji. I jakie ty masz doświadczenia z tym, Krzysiek? Czy uważasz, że to faktycznie jest gdzieś tam problem z własnego doświadczenia, czy podnosić to wbrew we własnych projektach, czy raczej uważasz, że być może tak to wygląda w większych tych, ale w mniejszych jakichś techach nie jest to aż takie straszne?

Krzysztof: Nie, w mniejszych wygląda jeszcze gorzej, w mniejszych się ładuje jeszcze więcej subskrypcji. bo nikt tego nie kontroluje, więc wchodzisz i strona się odpala po minucie, bo najpierw zaciągają się wszystkie skrypty, które mają priorytet nad załadowaniem reszty. Mówiąc tak całkiem poważnie, to moje doświadczenie z tą ilością skryptów jest podobne. i co więcej powiem, że to jest też taki fajny kontrargument dla wszystkich, którzy mówią wystarczy wdrożyć np. Content Security Policy. Pozdrawiam osobę, która wdroży Content Security Policy dla 47 średnio skryptów na dużej stronie korporacyjnej. Zarządzanie taką polityką CSP w takim wypadku jest po prostu, można powiedzieć, prawie że niemożliwe. Co więcej, jeżeli mamy 47 skryptów, które zaciągamy z jakiegoś CDN-a, to śmiem twierdzić, że wśród tych 47 znajdzie się przynajmniej jeden, który nie będzie wskazywał sub-resource integrity, bądź nie będzie to możliwe do zaimplementowania, aby sprawdzać integralność po stronie przeglądarki tego, co zostało zaciągnięte, więc ten atak Atak na łańcuch dostaw poprzez CDN-a przy takiej ilości skryptów jest czymś z czym trzeba się liczyć, dlatego jeżeli już faktycznie musimy no to warto jest może skorzystać z CDN-a, który hostujemy po swojej stronie i pierw te skrypty z tych ogólnie dostępnych CDN-ów po prostu zaciągać i może w jakiś sposób weryfikować, chociaż też zdaję sobie sprawę, że może być to trochę uciążliwe pod kątem takiego procesu, żeby coś takiego po prostu wdrożyć.

Andrzej: Dokładnie tak, świetny punkt z polityką CSP. Ja tutaj będę miał dwie anegdotki. Pierwsza anegdotka jest odnośnie tego, że bardzo często i skanery podatności, ale nie tylko, bo manualne testy bezpieczeństwa, testy penetracyjne web aplikacji, często gęsto testerzy wykrywają różnego rodzaju podatności, między innymi XSS-y albo brak właśnie nagłówka CSP, nawet po prostu sam zerowy brak nagłówka i raportują to jako podatność i mówią, że no to po prostu rekomendacja to jest wdrożenie polityki CSP. I oczywiście jest to taka rekomendacja jak rekomendacja dla XSS-ów, po prostu waliduj i sanityzuj wejście. Czyli jak to mam zrobić na poziomie kodu? Bo to nie jest coś, co mogę zrobić per przypadek, to musi być rozwiązanie systemowe. I tak samo tutaj, jeśli mówimy o implementacji CSP, to to nie jest sprawa dodania jednego na główka. W dużej organizacji, nawet w mniejszej organizacji, czyli nawet w małym, średnim przedsiębiorstwie, które jest powiedzmy średnio duże, implementacja CSP to jest cały projekt, a w dużych organizacjach to jest cała inicjatywa, która będzie zajmować prawdopodobnie miesiące. To nie jest coś, co da się zrobić ot tak. I tak samo rekomendacja po prostu wdrożenie CSP jest co najmniej zabawna, bo to jest cała inicjatywa, cały projekt, a nie coś, co można sobie ot tak wdrożyć w systemie, w dużym systemie IT, który jest produkcyjny. I to jest jeden z dużych powodów, dlaczego nie da się tego zrobić. Po prostu zaciągamy na, po pierwsze mamy dużo aplikacji, a po drugie w każdej z tych aplikacji zaciągamy dużo dodatkowych zewnętrznych skryptów, bez których no po prostu system by nie działał. Więc to jest jedna anegdotka, bo znam po prostu ją z własnego doświadczenia, a druga anegdotka to to, że u siebie prowadząc sesję modelowania zagrożeń, czy jako doradca wprowadzając ten proces, czy jako po prostu szkoleniowiec, po prostu tylko szkoląc zespół, Często spotykam się z takim zagrożeniem i ja bardzo lubię je wrzucać na tapetę w momencie, gdy analizujemy system web aplikacje. Zagrożenie właśnie związane z CDN-em i bardzo rzadko jest ktoś na sali, kto to zagrożenie wrzuci za mnie. czyli to nie ja będę musiał je wrzucać, tylko ktoś je za mnie wrzuci i poprawnie rozpozna, że w zasadzie jeśli zaciągam coś CDN-a, no to można zaatakować CDN-a i przez to przechodnio zaatakować mnie. I tutaj idąc dalej jest bardzo niska świadomość, no nawet właśnie u programistów, na temat istnienia mechanizmu sub-resource integrity, który pozwala na… na zarządzanie i na sprawdzanie integralnością skryptów, które ładujemy. Oczywiście to nie jest tak, że ten mechanizm po prostu możemy sobie dodać, tam znowu są pewne edge case’y, które trzeba obsłużyć i pewne rzeczy, które nam on przestaje umożliwiać. ale w dużej mierze broni przed problemami właśnie z zaciąganiem podmienionych zasobów na zewnętrznych zasobach. Tutaj mija się jeszcze jakiś komentarz?

Krzysztof: Tak, miałem komentarz dotyczący właśnie SRI, czyli Sub Resource Integrity, że wdrożenie tego, tak jak mówisz, wcale nie jest też takie proste. Wiadomo, jeżeli mamy Greenfieldowy projekt i dostrzegamy prostą paczkę, która jest wersjonowana, to jest bardzo istotne. Musi być wersjonowana, żebyśmy mogli się przypiąć do konkretnej wersji i ten hash podpiąć dla konkretnej wersji. Na przykład ja mam doświadczenie ze Stripe, Stripe jest znanym procesorem płatności, myślę, że większość też słuchaczy będzie kojarzyć. Stripe na przykład nie udostępnia SRI. Jest cały otwarty wątek na GitHubie ludzi, którzy płaczą, ponieważ ich dział Compliance przychodzi i mówi, hej, wy coś sobie tam zaciągacie, powinniście podać hash w atrybucie integrity, a Stripe mówi, no dobra, ale my wam tego nie damy, bo zawsze chcemy, żebyście mieli najnowszą wersję, więc nie wersjonujemy tego na poziomie CDN-a. No i jest impas.

Andrzej: To jest świetny komentarz, dokładnie tak, to jest ten największy problem w implementacji SRI w aplikacjach, no to jest problem z wersjonowaniem, że nagle to co chcesz, żeby miało atrybut integrity, żeby ta integralność była sprawdzana, musi być wersjonowane, jeśli nie jest, to po prostu nie będzie się dało tego sprawdzać. integralności, no bo jeśli nastąpi jakaś zmiana, tak jak w przypadku Stripa, to nagle zmienia się, czyli jeżeli my sobie sami obliczymy ten atrybut integrity, bo możemy to zrobić, natomiast jeżeli Stripe zmieni chociaż jeden byte w tym pliku, to nagle nasza integralność zadziała tak jak powinna przestanie ładować ten skrypt po naszej stronie, więc mamy niejako self-inflicted denial of service, czego oczywiście byśmy nie chcieli. No i tutaj to pokazuje, że czasami, a nawet bardzo często, ale to pokazuje taki realny case, gdzie bezpieczeństwo no po prostu schodzi na dalszy plan względem szybkości, szybkości update’ów. Co oczywiście ma swoje plusy i minusy, jak wiemy z ostatniego przypadku. Crowdstrike. Ale dobrze, przechodząc do jeszcze jednego wniosku, który też był dla mnie mega ważny, myślę, powiedzmy, że jest ex aequo z tym wnioskiem dla zewnętrznych komponentów, które są ładowane po stronie front-endu. to to, jak szybko są eksploitowane podatności Zero Day w web aplikacjach. Oczywiście ta szybkość, ona nie będzie zawsze taka sama, czasami jest trochę szybciej, czasami jest trochę wolniej, ale ogólny trend jest taki, że raczej jest szybko niż wolno i raczej mamy mniej czasu na spatchowanie naszych systemów niż mamy go więcej. I tutaj ciekawy stats, od Klumpler, że w 2023 97 z Zero Day było eksploitowanych w in the wild, w internecie, w szerokim i głębokim internecie. I to jest całkiem sporo. całkiem sporo, bo 97 ODEI to całkiem sporo, ale nawet gdybyśmy nie eksploatowali ODEI, to ta eksploatacja i tak jest tak szeroka, że tutaj to patchowanie jest mega ważne. Im szybciej, tym lepiej. A im szybciej, tym lepiej, to jest takie mega tutaj ważne, bo są przypadki, gdzie akurat eksploatacja udei następuje mega, mega szybko. Tutaj takim świetnym przypadkiem był JetBrains TeamCity Authentication Bypass, gdzie w zasadzie eksploatacja nastąpiła po 22 minutach od opublikowania proof of concept na stronie Rapid7. Rapid7 to znany vendor narzędzi security z bezpieczeństwa, m.in. skanera bezpieczeństwa, ale też takiego dość dużego frameworku do hakowania metasploit. Kiedyś Rapid7 ich po prostu kupił, włącznie z głównym deweloperem. Natomiast 22 minuty to bardzo mało. I to, co tutaj jest dla mnie super ważne i ten wniosek, który chciałbym przekazać słuchaczom, to nie to, że o, patrz, jest 22 minuty i następuje ta eksploatacja, tylko pewien szersze spojrzenie, gdzie to wszystko idzie. Czas reakcji wymagany w takim przypadku jest ewidentnie nie do wykonania przez człowieka. W 22 minuty nawet pojedynczy mega ogarnięty gość miałby problem, żeby obronić swoją infrastrukturę przed tego typu atakiem, a co dopiero jeśli mamy całe zespoły, musimy koordynować komunikację, etc. Jest to po prostu niewykonalne rękoma ludzi. Nie ma opcji, żeby takie coś się wydarzyło. Więc co zrobić? Płakać, że będą nas hakować i już nic nie możemy z tym, nic nie możemy na to poradzić? Nie. Według mnie i to jest coś, co powtarzam od lat, pierwszy raz chyba o tym jasno wspomniałem w 2018 roku, że widać pewną centralizację narzędzi bezpieczeństwa i ta centralizacja idzie oczywiście w kierunku dużych vendorów, takich jak np. Microsoft czy właśnie Cloudflare, który tutaj przedstawia ten raport. I ta centralizacja polega na tym, że o ile my jako mniejsze żuczki nie jesteśmy w stanie tak szybko reagować, to powiedzmy Microsoft czy Cloudflare mając tak duże wizybility, co się dzieje w sieci, może zacząć aplikować machine learning, no teraz byśmy powiedzieli AI, po to, żeby po pierwsze wykrywać anomalię, a po drugie szybko, szybko przed nimi pisać regułki do WAFA w sposób automatyczny. I w zasadzie Cloudflare już ma taki feature, nawet napisał dość obszerny artykuł na ten temat w zeszłym roku, czyli jak właśnie zapszą z EML do obrony automatycznej przed atakami Zero Day, ale Microsoft robi dokładnie to samo w swoim Azure, w usłudze Security, więc generalnie widać pewien trend, w którym kierunku to zmierza. Zmierza to w kierunku automatyzacji na podstawie statystyk, a no wiadomo, jeśli chcemy robić coś takiego w wydaniu automatycznym, chcemy aplikować machine learning, chcemy mieć AI, to musimy mieć dane i musimy mieć ich dużo. A żeby mieć dużo danych, no to sami musimy być duzi. I niejako będą mogli to robić najwięksi vendorzy. Z jednej strony jest to duży plus, Jest to duży plus, dlatego że jak to w kapitalizmie, jeśli będzie robił to duży gracz, to będzie nas to końcowo kosztowało mniej niż gdybyśmy musieli robić to my sami. Prawdopodobnie będzie to lepsze, dlatego że mają po prostu wgląd w większą ilość przypadków wszystkich swoich klientów. No ale z drugiej strony niejako dodajemy ten kawałek do jakiegoś konkretnego podmiotu i ten podmiot, no jeśli on będzie miał jakieś blind spoty, to wszyscy klienci tego podmiotu będą automatycznie podatni. będzie istniało dla nich zagrożenie idące właśnie z tej centralizacji i korzystania z jednego vendora. Więc ma to swoje plusy, ma to swoje potencjalne minusy, zobaczymy jak to się gdzieś tam rozegra, ale kierunek jest jasny. Bezpieczeństwo albo inaczej duże kawałki bezpieczeństwa idą w kierunku centralizacji, co też niejako gdzieś tam. potwierdzeniem tej hipotezy jest nasz ostatni faka, o którym mówiliśmy, czyli CrowdStrike. No, spowodował tak duży problem. Dlaczego? Dlatego, że był jednym z kilku vendorów, bo tych vendorów nie ma dużo, którzy dostarczają pewną krytyczną usługę dla dużej ilości innych organizacji. ale tych dostawców, tych vendorów wcale nie ma tak dużo, więc dzisiaj padło na CrowdStrika, a jutro może paść na jego konkurencję. Powiedzmy w dużym obrazie nie ma to takiego znaczenia. Znaczenie ma to, że centralizacja tworzy ryzyko systemowe, takie, że jeśli to, jeśli ten centralny podmiot popełni gafę, tak jak w przypadku krautstrajka, albo po prostu zostanie zaatakowany, no to wszystko, co jest scentralizowane przez ten podmiot, no niejako będzie przechodnio mieć problemy. Dobrze, Krzysiek. W zasadzie od Klautlera to jest wszystko, co mam tutaj do powiedzenia. Mam jeszcze, okej, dobra, nie wszystko. Jeszcze jeden mały komentarz. Mianowicie zdziwiło mnie to, że prawie 40% wszystkich ataków na web aplikacje to ataki DDoS. Zaciekawiło mnie to, że w zasadzie tak szeroko aplikacje są atakowane tylko pod kątem tego, żeby aplikację położyć, żeby się nie odzywała.

Krzysztof: Tak, żeby ściągnąć ich dostępność, nie?

Andrzej: Tak, więc to mnie zadziwiło, ale to powiedzmy już na marginesie, to jest takie ha, ciekawe. Czy ty masz komentarz jeszcze do tego mojego wywodu odnośnie Zero Day i centralizacji? Jak tak, to strzelaj.

Krzysztof: Komentarz dotyczący faktycznie tego, że ten czas zaczyna się coraz bardziej skracać i myślę, że nie bez przyczyny mówimy teraz o 22 minutach, a myślę, że z każdym rokiem będziemy jeszcze urywali z tych 22 minut, to co potrafią w tym momencie robić, potrafi robić generatywna sztuczna inteligencja w kontekście pisania eksploitów, może jeszcze nie urywa czterech liter, ale powiedzmy zaczyna robić małe wrażenie i nawet dla takich script kiddies wygenerowanie z bloku, fragmentu tekstu pewnego proof of concept zaczyna być coraz to prostsze.

Andrzej: Świetna uwaga, więc ten machine learning, ten AI, on działa w dwie strony. Możemy go używać od strony defensywnej po to, żeby wykrywać pewne anomalie i się przed nimi bronić w dużej skali, ale oczywiście możemy używać AI-a do tego, żeby w dużej skali produkować proof-of-concepty, czy już konkretne, złe opanizowane exploity do tego, żeby atakować drugą stronę i robić to szybciej, szybciej, szybciej. Więc tak, to jest miecz obosieczny. Dobra, Krzysiek, wskakujemy w twoje znalezisko.

Krzysztof: Tak, tak, wskakujemy w moje znalezisko. Ono nie jest tak całkiem nowe, ale w zasadzie cały czas trwa. Grupa Lazarus, znana również jako APT28, to jest grupa hakerska ściśle powiązana z Biuro 121 zajmuje się operacjami z zakresu cyberwojny, cyberatakami i wchodzi w skład północno-koreańskiego wywiadu wojskowego. Mówimy tutaj o actorach krajowych. I Lazarusa podejrzewa się o jedne z największych cyberataków, o których mogliście słyszeć, na przykład ataku na amerykańską wytwórnię filmową Sony Pictures w 2014 roku, a ten atak był spowodowany wtedy premierą firmy wywiad ze Słońcem Narodu, który był pewnego rodzaju parodią wywiadu z Kim Jong-unem. Więc Kim Jong-un niezadowolony z tego, że Amerykanie, ci źli kapitaliści, znowu chcą zbić majątek na wydaniu filmu, który będzie go ośmieszał, postanowił po prostu, że dobra, to ściągnijmy całą stronę pictures. i faktycznie tak się stało. A na marginesie powiem, że ostatnio oglądałem bardzo ciekawy dokument, może nie bardzo ciekawy, ale ciekawy dokument, taki pop dokument właśnie o tym, w jaki sposób Stany Zjednoczone atakują, ale równocześnie bronią się w takich operacjach właśnie z zakresu cyber. Dokument nazywa się Perfect Weapon i bodajże jest dostępny na HBO Max albo go już nie pamiętam, jak teraz to nazywa i tam jest fajnie właśnie to pokazane, w jaki sposób Koreańczycy zaatakowali wtedy Sondy Beach w 2014 roku, ale nie tylko, bo też jest o Stuxnessie, Stuxnecie i o Sandwormie, więc warto sobie obejrzeć.

Andrzej: Tutaj dodam, że jest książka również The Perfect Weapon i nie wiem, ale wydaje mi się, że pewnie są połączone i prawdopodobnie ta sama osoba stała za jednym i drugim.

Krzysztof: Tak, także polecamy zajrzeć. A jeżeli chodzi o ten konkretny artykuł, no to GitHub już od kilku miesięcy ostrzega, że Lazarus bierze na cel łańcuchy dostaw organizacji i atakuje poprzez złośliwe zależności szczególności duże organizacje. Wykorzystuje tutaj bardzo smrytny atak socjotechniczny, targetując inżynierów, tudzież deweloperów tychże organizacji. Cały atak polega na tym, że atakujący wykorzystują specjalnie spreparowane profile na platformach społecznościowych, mówimy tutaj głównie o Linkedinie, ale również wykorzystują Discorda, otwarte kanały na Slacku czy Telegrama. w zależności od tego kogo targetują taką platformę, taką platformę wybierają. No i tymi profilami podbijają do tych deweloperów, zachęcają ich aby. Ja czytałem o dwóch możliwych wariantach tego scenariusza. Jeden jest taki, że zapraszają Cię do wzięcia udziału w takim site, projekcie dotyczącym rozwoju jakiejś apki i obiecują słowite wynagrodzenie za to, że Ty będziesz tą aplikację, ten projekt z nimi rozwijał. No i oni się oczywiście przedstawiają jako twórcy tej aplikacji, twórcy tego projektu. A drugi, dużo częściej stosowany scenariusz, to jest scenariusz, w którym podają się za rekruterów dużych firm, w szczególności firm takich jak Facebook, Amazon, Google czy Netflix, czyli Fanga. No i podają się za tych rekruterów i również obiecują bardzo wysokie wynagrodzenie na danym stanowisku. I teraz tak, cały szkopuł tkwi w tym, że aby dostać się do takiego side projectu, czy dostać taką pracę, no to oczywiście tak jak w każdym procesie rekrutacyjnym trzeba rozwiązać jakieś zadanie. No i to zadanie jest oczywiście skierowane głównie na rozwiązanie jakiegoś tam problemu z zakresu programowania, więc trzeba sklonować repozytorium z tym zadaniem. No i żeby postawić cały projekt trzeba po prostu zaciągnąć paczki, które są wskazane czy to w jakimś tam requirements.txt czy jakimś package.json w zależności od ekosystemu, w którym ten projekt jest napisany. I w tych zależnościach, które będziemy dociągać w trakcie instalacji, znajduje się jedna zależność, która jest po prostu złośliwa. W trakcie instalowania tych zależności tego projektu, zaczynamy infekować swojego hosta, swoją maszynę. Jest jeszcze jeden ciekawszy, albo bardziej taki mroczna wersja tego ataku, że nawet nie w samych bezpośrednich zależnościach, które zaciągamy, tylko w zależnościach tamtych zależności znajduje się paczka, która jest zainfekowana. Niejako powiedzmy zaciemniamy jeszcze bardziej ten atak. Atakujący zaciemniają jeszcze bardziej ten obraz tego, co jest tak naprawdę złośliwe. No i host się infekuje, bardzo często jest to komputer organizacji, w której ci ludzie obecnie pracują, czyli to pokazuje też, że higiena często deweloperów, którzy korzystają z komputera do dwojakich zastosowań, wskazuje nam na to, że powinniśmy jednak trochę szerzej patrzeć na to, co się dzieje w naszej organizacji.

Andrzej: ale też tutaj widzę, że sama organizacja powinna brać pod uwagę zagrożenie tego typu. Czyli ja jako organizacja powinienem wziąć pod uwagę, że moi deweloperzy będą korzystać ze swoich komputerów. Powinienem założyć, że będą, że będą korzystać, jakaś część będzie korzystać z tych komputerów do własnych celów. czyli rozwijania jakichś innych projektów na komputerze organizacji i przez to przechodnio mogą zaatakować mnie, zewnętrzni aktorzy, nawet mogą konkretnie celować w mnie, czyli w organizację, ale chcą wejść od strony dewelopera. Chciałbym, żeby to po prostu tutaj jasno wybrzmiało, że atakujący oczywiście biorą to pod uwagę, Więc automatycznie organizacja też powinna uwzględniać takie zagrożenie, a nie tylko w takim typowym wydaniu, że mamy insider threat i ten insider musi być zezłoszczonym pracownikiem. To nie do końca tak. Pracownik może być jak najbardziej zadowolony, A w dalszym ciągu, szczególnie jeśli mówimy o osobach technicznych, może być tym pierwszym krokiem, tym pierwszym połączeniem w tym łańcuchu ataków, przez który atakujący będą chcieć wejść do danej organizacji.

Krzysztof: Dokładnie. Zwróć też uwagę Andrzej, że obrona przed tego typu atakami jest niezwykle ciężka, no bo co zablokujemy ruch do PIPI, czy zablokujemy ruch do całego NPM, skoro w naszym projekcie korzystamy z tego i deweloperzy korzystają z tego na co dzień, więc to jest transparentne nawet. Bardzo ciężko jest często podejrzeć, że coś dzieje się nie tak, no bo nie jesteśmy w stanie po prostu całkowicie zabrać dostępu do wszystkiego, nie będziemy w stanie wykonywać efektywnie swojej pracy. Jeżeli chodzi o te ataki, to jest cała firma, która zajmuje się w ogóle obroną przed atakami na łańcuchy dostaw w kontekście paczek. Ta firma nazywa się FYLUM. i tutaj tylko taka krótka wstawka od FYLUM, że FYLUM estimuje na podstawie różnych badań, że Korea Północna na tego typu operacjach w ostatnich latach zarobiła 4 miliardy dolarów, tym samym obchodząc międzynarodowe sankcje, które są nakładane przez duże kraje. Więc oni sobie radzą i radzą sobie całkiem nieźle poprzez te operacje, które przeprowadzają. Co więcej, film wskazuje na to, że z roku na rok i z kwartału na kwartał korea północna, te jednostki, które są wyspecjalizowane w cyberatakach, stają się coraz to bardziej sprytniejsze i są w stanie tworzyć bardzo krótko żyjące paczki, które są wypuszczane do PIPI, do NAGETA, do NPM. paczki, które żyją np. 90 sekund jako paczki publiczne i są publikowane w punkt. Dosłownie wtedy, kiedy wiedzą, że ofiara będzie w stanie tą paczkę zaciągnąć tylko po to, aby uniknąć po prostu detekcji, bo atakujący oczywiście publikują te paczki do PIPI, NPM itd. ale jest też szereg firm, które robi to samo, czyli na bieżąco zaciąga te paczki, ewaluuje je i ocenia pod kątem złośliwości i dostarcza taki threat intelligence w postaci produktów, które mają bronić organizację przed zaciąganiem. Ale nie oszukujmy się, jeżeli ktoś ma 90 sekund, to trzeba być naprawdę bardzo szybkim. Wydaje mi się, że to jest po prostu w tym momencie niemożliwe, aby tak szybko rozpowszechnić informację, że hej, tutaj znajduje się złośliwa paczka. Jeżeli mamy 90 sekund czasu życia takiej paczki, bo ona potem jest usuwana przez atakujących, żeby uniknąć detekcji. Jeżeli chodzi jeszcze o Koreę Północną, tak byśmy mógł Andrzej przeskoczyć na następną stronę. Tutaj pozostając w temacie właśnie północno-koreańskim, to historia, która niezwykle mnie rozbawiła, ale też historia, która mrozi trochę krew w żyłach, bo firma, która produkuje platformę do takich szkoleń phishingowych zatrudniła północno-koreańskiego hakera. Know Before potrzebowała do jednego ze swoich zespołów zajmujących się generatywną sztuczną inteligencją właśnie inżyniera na wysokim stanowisku, programisty. No i znalazła idealnego kandydata, który przeszedł cztery rozmowy weryfikacyjne. Te rozmowy odbywały się jako konferencje na kamerce. Przeszedł background check, który jest obowiązkowy w Stanach Zjednoczonych, o ile dobrze kojarzę. i szereg innych testów, w tym właśnie zadanie rekrutacyjne. No i gdy dostał tą pracę, no to okazało się, że bardzo szybko. Security Operations Center wykryło, że za pomocą Raspberry Pi próbował po prostu ściągnąć malware, czym wzbudził zainteresowanie zespołu bezpieczeństwa. Ciekawe jest to, że ta osoba użyła kradzionej tożsamości faktycznie obywatela Stanów Zjednoczonych, a wszystkie swoje zdjęcia w dokumentach, w aplikacji, w CV zostały przerobione po prostu za pomocą modułu AI-owego. i tam na dole tej strony jest pokazane w jaki sposób on to zrobił, jak wyglądało zdjęcie ze stoka, którego użył, A jak wyglądał ten niby północnokorańczyk, który się do tej firmy zrekrutował? I to też jest fajna, ciekawa historia, która otwiera nam oczy, że w dzisiejszych czasach powinniśmy jednak troszeczkę bardziej uważać, może bardziej do działów HR-owych, które zajmują się weryfikacją tego, kto faktycznie po drugiej stronie, szczególnie w czasach pracy zdalnej, siedzi.

Andrzej: I teraz mamy świetny Seagway do dwóch kawałków, o których ja chcę powiedzieć. A czemu świetny? Bo pasuje jak ulał. Zauważ, że to, o czym ty powiedziałeś i to, co teraz można zobaczyć, jeśli ktoś ogląda nas na YouTube, to, że wszystkie te informacje, o których mówiłeś, są opublikowane na stronie Know Before, czyli firma, która została zaatakowana. To oni są transparentni, to oni piszą, oczywiście nie dzielą się z nami detalami technicznymi, nie muszą, ich wewnętrzny raport pewnie jest ma dużo więcej ciekawych smaczków i szczegółów, natomiast dzielą się z nami głównymi kawałkami i głównymi wnioskami, nie ukrywają nic. Są transparentni w tym, co się stało. They own it.

Krzysztof: I też wiesz Andrzej, naprawdę duża brawa dla firmy, która zajmuje się tematyką phishingu, czyli de facto powinna być o krok przed takimi atakami i ona mówi otwarcie o tym, zobaczcie to się stało nawet u nas.

Andrzej: Dokładnie tak. I to niejako też buduje zaufanie, bo jeśli jesteś faktycznie w stanie się czymś takim podzielić, że no kurczę, wywróciłeś się, ale wstajesz i teraz jeszcze robisz retrospekcję i zapewne będzie rewizja kontroli, które już tam są, albo dodanie nowych, kontroli bezpieczeństwa przed czymś takim w przyszłości. Natomiast mi się podoba ta transparentność, którą tutaj mamy, ale zauważ, że też ta transparentność wydaje mi się, że w dużej mierze wynika z tego, że niejako mogą sobie na to pozwolić, bo faktycznie mają kontrolę bezpieczeństwa, które działają. W tym sensie, że ja mogę powiedzieć, że przekazałem to do mandianta, mogę powiedzieć, że mój sok to wykrył ETC, bo faktycznie to zrobił. Czyli nie muszę świecić oczami, że ja w zasadzie nic nie robię i jeszcze mnie schakowali i więc jest źle, tylko faktycznie mogę taki incydent nie tylko stworzyć, bo mam ludzi, którzy się tym zajmują, ale dwa mogę go stworzyć, dwa mogę go opublikować, bo po prostu nie będzie wstydu, że coś się stało. Stało się? Oczywiście, że każdemu się stanie, to jest tylko kwestia czasu. Bycie ofiarą ataku hakerskiego czy takiego fishingu to jest dosłownie kwestia czasu. Natomiast To, co się dzieje po, wiele mówi o organizacji, ale też można to trochę rozciągnąć o pewnym podejściu do rzeczywistości. Nie bez powodu mówię o tym podejściu do rzeczywistości, bo No Before, o ile dobrze kojarzę, jest amerykańskie, z US, a to jest dość ciekawy fakt. Natomiast przechodząc ten Seagway, robiąc do tych rzeczy, o których ja chcę powiedzieć, to na marginesie, bo ja nie będę wchodził jakoś mocno w szczegóły dwóch wycieków, o których pisał i Niebezpiecznik i Zaufana Trzecia Strona. Zaufana Trzecia Strona napisała o poważnym wycieku z Polskiej Agencji Antydopingowej. A Niebezpiecznik napisał o wycieku z Holding One właściciela takiej firmy jak Traficar, Polska Grupa Dilerów, PGD, której notabene byłem klientem, więc ciekawe. Ja nie dostałem żadnego powiadomienia o wycieku moich danych. Mam nadzieję, że nie wyciekły. Developera Megapolis i tam dziesiątek innych spółek. Już nie będę komentował, że dziesiątki innych spółek i wygląda to jak sieć pamięci. Ja nie jestem księgowym ani policją księgową, więc ja tutaj nie będę tego komentował, bo się na tym po prostu nie znam, choć się domyślam. Natomiast te poważne wycieki są o tyle ciekawe właśnie w kontraście z… tym incydentem Know Before, że dziwnym trafem ani jedna, ani druga firma nie ma przejrzystego raportu co się faktycznie wydarzyło. W zasadzie jedyne co potrafią zrobić to, a nawet tego nie potrafią zrobić rzetelnie i o szybkim czasem reakcji, ale jedyne co potrafią zrobić to może jakoś wybiórczo poinformować tych ludzi, których dane wyciekły o tym, że coś takiego się wydarzyło. Oczywiście robią to Znowu, nie wiem, choć się domyślam, tylko dlatego, że mają obostrzenie prawne w chwili obecnej z powodów RODO. Gdyby tak nie było, to nawet tego by nie zrobili. Czyli tak, mamy firmę, która jest Stanów, której RODO w zasadzie w żaden sposób nie obejmuje, w zasadzie żadna regulacja ich nie zobowiązuje do tego, żeby coś takiego udostępnić. Ja wiem, że tutaj nie było danych osobowych, natomiast nie mają zewnętrznego BATA, który ich reguluje, że muszą coś takiego, taki incydent zgłosić, muszą się tym pochwalić. Czyli technicznie można powiedzieć, że działają na swoją szkodę, bo lepiej byłoby, gdyby tego nie opublikowali. No, nie dostaliby żadnego PR hit. Natomiast tutaj mamy te wycieki. Jakieś tam informacje do pokrzywdzonych w tych sprawach poszły, ale oczywiście, tak jak powiedziałem przed chwilą, nie wiem choć się domyślam dlaczego. Ale nie mamy żadnego rozbudowanego post mortem z tych organizacji, ani z Holding One, który jest prywatną firmą, ani z tej Polskiej Agencji Antidopingowej. Ja nie wiem, czy to jest podmiot rządowy. czy nowy, czy nie, no na pewno jakieś powiązania z rządem ma. I nie chodzimy teraz z jakim rządem, chodzimy po prostu, że nie jest to w stu procentach public, tylko jest to private, tylko jest to w jakimś procencie public i przynajmniej ma z nim powiązania. I takie coś wydaje mi się, że należałoby nie tylko wymóc prawnie, a w zasadzie z mojego punktu widzenia zwykła rzetelność i integralność wymaga tego opublikowania jakiegoś postmortem, czyli konkretnego opisu przypadku, co się stało, jak do tego doszło, jakie mamy na tę chwilę tropy. Co się mogło wydarzyć, że nas zhakowali? Oczywiście, tutaj zaraz znajdzie się ktoś i powie, no ale Andrzej, ten przypadek grupy antydopingowej, to wiesz co, to nas ustalenia wskazują, że atak jest działaniem grupy wspieranej przez służby wrogiego państwa. No i oczywiście za tym można się bez problemu przykryć i powiedzieć, że nie upublicznimy takich takiego post mortem, ani publicznego raportu, no bo wiadomo, no bo to był nation state nas hakował, więc nie chcemy o tym za bardzo mówić, no bo wiecie, tam są bardzo, bardzo duże sekrety, które musimy, które musimy, no nie możemy ich udostępnić. No ja powiem tak, how convenient, how convenient, prawda? Żeby się za czymś takim zakryć, a nie jednak wyjść i jasno powiedzieć, co się faktycznie wydarzyło. Nikt nie oczekuje szczegółów. Nikt nie oczekuje szczegółowego raportu technicznego, którego Know Before też nie udostępniło szczegółowego raportu technicznego, ale jednak udostępniło pewnego rodzaju postmortem, gdzie odbiorca jest w stanie ocenić, co poszło nie tak, przy czym też oczywiście odbiorcy są w stanie się czegoś nauczyć na lekcji, której nie musieli ponosić kosztów. Tutaj jak zwykle, mamy wyciek, nikt się niczego nie nauczy, bo nikt o niczym głośno nie powie. Ja w zasadzie nie jestem pewien, czy nawet wewnątrz tej organizacji ktoś czegokolwiek się z tego wycieku nauczy, bo nie wiem, choć się domyślam, ale wewnętrznego raportu post mortem i incydentu również wydaje mi się, że nie będzie. Więc jest to trochę…

Krzysztof: Wiesz Andrzej, bo możliwe, że tam nikt z zakresu cybersecurity nie pracuje.

Andrzej: Jest to bardzo możliwe, tylko wtedy się bierze firmę z zewnątrz. Takich firm trochę w Polsce mamy i możemy skorzystać z ich usług. Lepszych, gorszych, oczywiście lepiej korzystać z tych lepszych. Ale możemy skorzystać z ich usług, ale oczywiście to się nie wydarzy. Obydwa artykuły polecam, chociaż ten z zaufanej trzeciej strony jest ciekawszy, no bo To, co wyciekło w tym wycieku jest po prostu ciekawsze, bo to są oczywiście dane zdrowotne tych różnych sportowców, którzy byli testowani pod kątem dopingu. Ich dane osobowe są takie smaczki jak hasła w Excelu czy w plikach tekstowych na desktopie. Są takie smaczki jak jakieś zdjęcia z, ja nie wiem, to jest jakiś laboratorium, wygląda trochę jak laboratorium z Breaking Bad, ale tych pierwszych sezonów, bo potem to już było lepsze. Te drzwi to jest dla mnie po prostu mega. Kontener i drzwi takie, no, jak do domu, a to jakieś urządzenie, nie wiem, jakieś pelce, żeby przeprowadzać jakiś proces chemiczny. Ja nie wiem, co oni tutaj tworzą. Wydaje mi się, że to nie jest… Wydaje mi się, że nie syntetyzują legalnych środków, ale znowu, nie wiem, co się domyśli.

Krzysztof: Andrzej, to jest Centrum Szkoleniowe Kolarzy.

Andrzej: Centrum Szkoleniowe Kolarzy. No i dwuboistów, bo dwuboiści też kilka lat temu wpadli. I żeby nie było. Tutaj możemy się trochę podśmiechywać z tych, którzy wpadli, ale wszyscy sportowcy na wysokim levelu biorą sterydy. Nie ma opcji, żeby nie brali. Z prostej przyczyny. Jeśli nie bierzesz, to wygryziecie ten, który bierze. Pytanie jest tylko, kto wpadnie i kto jest odpowiednio prowadzony. Jak ktoś wierzy w to, że sportowcy będący na olimpiadzie im biorą sterydów, to już wiem, że nigdy nie uprawiał sportu i nie mam pojęcia o czym mówi. Nie ma opcji, żeby nie brać sterydów na tym poziomie. Więc ludzie oszukują w zakładzie o 5 złotych, a to dopiero jak… mają na szali dorobek swojego życia, miliony złotych. Tak, nie biorą sterydów. Oczywiście, że biorą, tylko szkoda, że dają się złapać. To jest duży problem. I to nie tylko nasi sportowcy dają się złapać. Oczywiście z innych krajów też. Ktoś ich źle prowadził. A obydwaj z Krzyśkiem trenujemy sport, więc coś o sporcie wiemy i wiemy, jakie to jest trudne. Ale ten wyciek z agencji antydopingowej jest tutaj ciekawy. Ciekawe te zdjęcia, bo tam wypadły nie tylko same dane osobowe, ale właśnie te zdjęcia z tych różnych laboratoriów i innych rzeczy. Ten z Holding One jest trochę mniej ciekawszy, bo jest po prostu takim standardowym wyciekiem gdzieś tam danych osobowych plus klientów tych firm, więc to taki standardzik, ale meta wnioskiem i to co właśnie mnie uderzyło to to, że po raz kolejny ani jedna, ani druga organizacja nie publikuje żadnych przejrzystych informacji, a świeśnie się to łączy właśnie z tym Know Before, które coś takiego opublikowało. I ja czekam na moment, gdzie to się zmieni. Niestety, ale wydaje mi się, że zmieni się dopiero wtedy, kiedy przyjdzie regulator i zacznie za to walić pałką po głowie. W innym przypadku się to po prostu nie zmieni i jest to smutne. Z mojego punktu widzenia jest to smutne, bo bo nie jesteśmy w stanie się uczyć, zaburza to pętlę zwrotną i zamiast uczyć się na czyichś błędach, to cały czas będziemy popełniać te same błędy. Ja pomijam takie błędy jak umieszczanie hasła do zarządzania WordPressem na komputerze osoby w dokumencie Worda. 2024 i hasła w Wordzie nie jest kolorowe.

Krzysztof: Niestety, Andrzej, powtarzasz to nieraz, powtarzamy to również razem nieraz, ta kultura bezpieczeństwa ogólnie, bardzo szeroko pojętego cyberbezpieczeństwa z zachodu przyjdzie do nas za kilka lat. Dobre kilka lat. Wiele wody musi upłynąć, żebyśmy się nauczyli.

Andrzej: Tak, tutaj właśnie ten keyword, który powiedziałeś, kultura, ja też wspomniałem wcześniej, dla mnie dużą częścią jest tutaj właśnie kultura, gdzie u nas w kulturze jest raczej zakrywanie swoich niedoskonałości, zakrywanie swoich błędów, bo inni powiedzą, że jestem głupi i jeszcze mnie wyśmieją. I jest to takie bardzo krótkoterminowe patrzenie, bo długoterminowo tylko jasna ocena sytuacji i stwierdzenie, że popełniło się błąd i jasne retrospekcja na temat tego błędu, analiza i często gęsto podzielenie się tym z innymi prowadzi do unikania tego błędu w przyszłości, do niepopełniania tego błędu. Więc jeśli tego nie robimy, tylko to kryjemy, no to będziemy powielać te błędy. Będziemy powiadać, po prostu się nie możemy nauczyć. Ten cały feedback związany z uczeniem się jest wtedy zaburzony. Dobra, Krzysiek, wskakuję do swojego.

Krzysztof: Tak, do mojego, ale tak naprawdę do Twojego, bo to Ty mi to podesłałeś. Andrzej mi to podesłał i bardzo mi się to spodobało, chociaż nie ma w tym nic odkrywczego, no bo rozmawialiśmy już o tym kilkukrotnie, ale warto jest poruszyć, bo ten blog post, ten research mnie zaciekawił. Andrzej, pytanie do Ciebie. Jakie jest najgorsze miejsce do pozostawienia sekretu, kluczyka tokenu?

Andrzej: W sensie najgorsze, czyli że dla atakującego będzie najłatwiej je znaleźć?

Krzysztof: Tak.

Andrzej: Dobrze, to ja bym strzelał w repozytorium kodu, a jeśli mówimy o konkretnym artefakcie, to .env.

Krzysztof: Świetnie, świetnie. Trafiłeś. Tak, trafiłeś. Przejdziemy jeszcze do tego, dlaczego trafiłeś. Andrzej, ty w listopadzie 2020 roku przeprowadziłeś bardzo fajny eksperyment, bardzo fajny research, w którym opublikowałeś kluczyki do AWS-a w publicznych repozytoriach na GitHubie i na GitLabie. I to badanie odbiło się szerokim echem w środowisku, bo cytowało cię wiele blogów, wiele portalów, no i miałeś też wiele retweetów z tego, bo to wszystko, z tego pamiętam, opisywałeś na Twitterze w wątku.

Andrzej: Tak, dokładnie tak. Nawet się pochwalę, że GitLab zmienił funkcjonalność odnośnie wykrywania sekretów. Ona tam miesiąc czy dwa później już wyglądała inaczej, czyli nie wymagała osobnego ustawienia pipeline’u, tylko już były wykrywane.

Krzysztof: Właśnie.

Andrzej: Automatycznie.

Krzysztof: Ja odkopałem wczoraj wieczorem blog posta od Port Swigera, który się cytował na swoim blogu i oni tam wskazywali, że właśnie na podstawie twojego research’u można wywnioskować, znaczy można wywnioskować, jasno wskazujesz, Pierwsze odpytanie o te kluczyki przez atakujących na GitHubie w publicznym repozytorium nastąpiło po 11 minutach, natomiast na GitLabie po 62 minutach. I zapamiętajcie te dwie wartości, 11 minut, a na GitLabie 62 minuty. I teraz tak, ostatnio właśnie pojawił się research, który teraz widzicie na ekranie, który myślę, że spokojnie można nazwać Andrzej rozwinięciem tego, co ty zrobiłeś, bo to nie jest coś całkowicie nowego, tylko zostały dodane nowe media, w których te kluczyki zostały upublicznione.

Andrzej: Tu jeszcze Ci wejdę słowo, powiem, że ja tylko bardzo pobieżnie rzuciłem okiem na ten artykuł i po prostu Ci go podesłałem, ale z tego pobieżnego rzucenia okiem widziałem, że jest to po prostu takie mocne rozbudowanie. Podejście takie bardziej już rzetelne do całego projektu. Ten mój eksperyment był takim czymś szybkim, takim POC, a to już nazwałbym po prostu researchem, natomiast podobieństwa są gdzieś tam mocno uderzające, bo nawet skorzystał również z z kanarków od Things, od Canary Tokens.

Krzysztof: Tak, dokładnie. No i tak, w tym badaniu kluczyki do AWS, ale wygenerowane w serwisie Canary Tokens od Things. trafiły znowu do publicznych repozytoriów na GitHubie, na GitLabie, trafiły również do publicznego repozytorium na Bitbucketie, LOL, ale również do rejestru na Docker Hubie. w obrazie zaszyto te kluczyki. W pliku aws.config, który był wystawiony publicznie przez webserwer, który był osiągalny, były te kluczyki również zaszyte w paczce na PyPI oraz NPM, oraz w usługach, nazwę je usługami baketowymi, możecie to kojarzyć, takie usługi jak S3 czy GCP Cloud Storage. zostały zaszyte w notatce na Pastebinie. Myślę, że Pastebina większość z was też kojarzy. No i jakie były wyniki tego researchu? Najszybciej kluczyki znaleziono w paszce MPM-owej, bo pierwsze odpytanie tymi kluczami na AWS-ie nastąpiło już w mniej niż 60 sekund. Więc tutaj możemy wnioskować, że publiczne rejestry paczek są tak naprawdę pod ciągłą obserwacją, pod ciągłym ostrzałem. Wydaje mi się, że ciężko by było tutaj rozróżnić, czy to było odpytanie złośliwe, znaczy, że faktycznie to odpytanie nastąpiło przez atakujących, czy to było odpytanie właśnie przez wcześniej wspomniany serwis. Jeden z serwisów, jedną z usług, która na bieżąco monitoruje rejestry paczek w poszukiwaniu takich cech złośliwości, aby budować swój threat intelligence. Tutaj się tego nie dowiemy, ale jest to bardzo szybkie. Widzę Andrzej, że chcesz coś powiedzieć.

Andrzej: Tak, bo wspomniałeś o tych usługach threat intelligence’owych, natomiast oczywiście trzeba brać pod uwagę, że atakujący również cały czas skanują te NPM-y, więc robią dokładnie to samo. Tutaj atakujący i defenderzy robią identyczne, więc to, czy było to jedno, czy drugie, no nawet jeśli było jedno, to tylko byli defenderzy, to tylko dlatego, że akurat się strzelili w okienko. Zaraz po tym by odpytali atakujący. Więc to jest taka zabawa w kotka i myszkań.

Krzysztof: Dokładnie. W ekosystemie Pythonowym mniej niż 2 minuty, więc również bardzo szybko. I teraz tak, na GitHubie te kluczyki znaleziono po 127 sekundach, czyli nieco ponad 2 minuty. I można to przełożyć na to, że po czterech latach od tego twojego researchu, który Andrzej zrobiłeś, atakujący są szybsi blisko pięciokrotnie, jeżeli chodzi o to, co udostępniamy na GitHubie, więc ten wzrost szybkości jest piorunujący, jeżeli chodzi o to, jak szybko są w stanie przeszukiwać publiczne asety, publiczne repozytoria. Pastebin 50 minut, też mnie to nie dziwi. Pliki na webserwerze z kluczykami znaleziono po 47 godzinach. No tutaj trudność pewnie wynika z tego, że trzeba jednak znaleźć ten adres IP konkretnego webserwera, no i trzeba również zbrutforsować nazwę pliku, aby po prostu otrzymać to w odpowiedzi, czego szukamy. Więc to też nie jest wcale, może nie jest ciężkie, ale nie jest tak proste jak reszta tych mediów, których szukaliśmy. No i co ciekawe, Docker Hub, wydawało mi się, że Docker Hub jest również pod taką stałą obserwacją. aczkolwiek tutaj niecałe 7 dni. Dopiero po niecałych 7 dniach udało się znaleźć atakującym te kluczki w obrazie. To ciekawe też, a tutaj autor nie wskazuje, jak ten kluczyk był umieszczony. Czy on był umieszczony w wierzchniej warstwie obrazu, czyli bezpośrednio na górze tego stosu. czy był ukryty pomiędzy warstwami, a na wierzchu tego królczyka nie było widać i trzeba było ten obraz dopiero zdekomponować, żeby dobrać się do konkretnej warstwy obrazu dokarowego, ale wydaje mi się, że zakładam, że był w tej wierzchniej warstwie i wystarczyło po prostu podejrzeć, co w kontenerze się znajduje. Ciekawostka jest taka, że atakujący próbowali w większości przypadków po prostu próbowali użyć metody Invoke Model z usługi AWS Bedrock. Czyli po prostu próbowali tymi kluczykami uruchomić usługę, która miała postawić im model ML-owy, model do generatywnej sztucznej inteligencji. I też o tym wspominaliśmy w jednym z odcinków bezpiecznego kodu podcast. że w tym roku obserwuje się taką zmożoną aktywność atakujących, która polega na tym, że skradzione klucze do usług chmurowych są potem wykorzystywane do tego, aby płatnie odsprzedawać dostęp do kradzionych modeli. W taki sposób tworzą sobie takie reverse proxy, czyli kradną powiedzmy 100 kluczy, udostępniają dostęp do swojej usługi, na której możesz odpalać sobie jakieś swoje prompty. Jeżeli wyczerpie się im dostęp do jakiegoś kluczyka, no to rotują z tej puli skradzionych. Więc to w zasadzie się pokrywa z tym, o czym mówiliśmy wcześniej. Ciekawą rzeczą z tego researchu jest fakt, że w trakcie jego trwania nie odnotowano próby odpytania się kluczykami, które umieszczono zarówno na GitLabie, jak i BitBucketcie. I dlaczego na GitLabie tych kluczyków nie znaleziono, to nie wiem. Natomiast domyślam się, dlaczego tych kluczy nie znaleziono na Bitbuckecie i mam nadzieję, że kiedyś, kiedyś, mam nadzieję, że w tym roku uda mi się dokończyć i rozwinąć coś, co zacząłem, bo mam pewien trop, dlaczego taka sytuacja może się na Bitbuckecie zdarzyć i jaka jest trudność w przeszukiwaniu Bitbucketa, ale ten research będzie troszeczkę odwróceniem tego, co widzicie tutaj. Mam nadzieję, że w tym roku powstanie i będziemy w stanie się nim pochwalić. No i Andrzej, czy do tego artykułu, który mi przesłałeś i który teraz widzisz, masz jakiś komentarz?

Andrzej: Mi od razu się rzuciło w oczy to, o czym mówiłeś w tych patternach atakowania, gdzie był ten invoke model i get color identity. i tak naprawdę to jest… Te dwa to jest większość tego, co było wywoływane. I to, gdzie invoke model jest dwa razy większy niż get color identity, a łącznie to jest 80% tego, co było wołane. Więc tutaj mamy power laws, gdzie jakieś jedna, dwie rzeczy dominują całość. Tutaj jak masz Analiza IP-ków, kto się odpytywał, to też było ciekawe, skąd. Stany Zjednoczone to duży kawałek, Chile to duży kawałek, Indonezja to duży kawałek. Tutaj można byłoby się zastanawiać skąd to wynika. Stanę to pewnie po prostu z defaultu, nie? Ktoś puszcza z jakiegoś skany z defaultu, z AWS-a, no to jest w Stanach. Natomiast poza tym to, nie, tak jak mówiłem, ja tutaj tylko mocno albo mocno pobieżnie rzuciłem na to okiem. Sam research jest ciekawy jako po prostu data point, który pokazuje, że w dalszym ciągu Te różne repozytoria są przeszukiwane przez atakujących, to się dzieje i te nasze sekrety. powinniśmy o nie zadbać, żeby nie dodawać ich do swoich, czy to repozytoriów, czy innych kawałków infrastruktury, bo ten research też jasno pokazuje, że to nie jest problem tylko samego repozytorium, GitHuba, Gitlaba, Bitbucketa. ale też oczywiście Docker Huba, serwerów FTP, webserwerów, blogów, menadżerów pakietów, ale oczywiście nawet takie kawałki infrastruktury w organizacjach komunikatory jak Slack, tam też nie powinniśmy mieć różnego rodzaju sekretów, bo stamtąd też one mogą wyciec. Więc wyciec, wycieknąć? Nie wiem, trzeba sprawdzić. Dobra. I teraz przechodzimy do mojego ostatniego małego kawałka, który wpadł mi w rączki na dniach. To konkretnie wpadło mi od chłopaków z Pato Architektów. Pozdrawiamy Łukasza i Szymona. Łukasz chyba konkretnie odnosił się do tego papierka, The Open Group, niektórzy mogą kojarzyć z TOGAFA, The Open Group wypuściło Security Principles for Architecture, taki dokument, podlinkujemy go w referencjach natomiast. To nie jest nic odkrywczego, nie jest też żaden rozbudowany papierek. Natomiast jako jedna publikacja dość dobrze agreguje typowe zasady, pryncypia architekturalne, które obowiązują w bezpiecznej architekturze. Takie rzeczy jak Control Third Party Solutions, Assume Compromise, Design for Compliance, Utilize Secure by Design. Natomiast to co mnie tutaj. Czemu to można powiedzieć spiked my interest? Dlatego, że Jaja tworząc materiały do swojego kursu ofensywne testowanie web aplikacji, tworząc moduł odnośnie podatności związanych z insecure design, niebezpiecznym projektem, rozwiązania czy systemu IT, co jest jedną z klas problemów na liście OWA WSTOP TEN 2021. Miałem, mam lekcje o bezpieczeństwie na poziomie architektury i jak szukałem tam referencji to jakoś super dużo ich nie ma, a już na pewno nie właśnie coś takiego jak dokładnie ten dokument. Czyli żebym mógł rzucić PDF-a i żebym mógł mieć te kilka zasad gdzieś wylistowane i jasno opisane z jakimiś referencjami. Na tamten czas po szukaniu tego nie widziałem, nie chodzi mi o książki, żeby tutaj referować, tylko masz, proszę tutaj ten zasób, weź go przeczytaj. Przeczytaj referencję, na pewno się czegoś ciekawego dowiesz właśnie o bezpieczeństwie na poziomie architektury. No i teraz ten kawałek wyszedł z The Open Group. Ja już podlinkowałem to w odpowiedniej lekcji, więc jak ktoś jest kursantem, to może sobie wejść. A jak nie, to i tak będzie podlinkowany tutaj ten dokument w referencjach. Więc dla ludzi, którzy pracują przy projektowaniu systemów IT, ale też oczywiście utrzymaniu i budowie, ten papierek warto rzucić sobie okiem i zrobić mentalną zakładkę, że coś takiego istnieje. W sesjach modelowania zagrożeń też może się to przydać.

Krzysztof: On jest utrzymany w takim wysokopoziomowym stylu, tak?

Andrzej: Bardzo, no to jest dla architektów, więc stąd też Łukasz go gdzieś tam referował i wrzucał do ich niższego newslettera, a potem jeszcze na Discordzie zaczepił o ten papierek, no bo Łukasz też jest na poziomie architekta, więc… Więc od razu mu to gdzieś tam się to zainteresowało, to raz, a dwa, no oczywiście TOGAF to jest odnośnie architektury, to znowu każdy architekt będzie kojarzył i The Open Group. No dobra, to z mojej strony w zasadzie to wszystko, z twojej chyba Krzysiek też, chyba że chciałbyś się jeszcze z czymś nami podzielić.

Krzysztof: Nie, ja już się wystrzelałem, nie mam już niczego. I tak jesteśmy grubo po czasie. Musimy się co tydzień zwaniać.

Andrzej: Musimy, tylko wtedy będzie trzeba znaleźć na to czas. Grafiki napięte, grafiki napięte. Dobra, Krzysiek. Dzięki za kolejną rozmowę. Przeżyłeś mój rant o wyciekach danych i o tym, że organizacje nie piszą post mortems. Jak widać jestem zbulwersowany całą sytuacją. Not on my watch. Ale oczywiście to mogło brzmieć jakbym był zdenerwowany, ale to tak trochę pół żartem, pół serio. Wolałbym, żeby sytuacja wyglądała trochę inaczej, ale wygląda jak wygląda. Dobrze. Dziękuję za kolejną rozmowę. Słyszymy się za dwa tygodnie. I co? No to ja tobie życzę i wszystkim naszym słuchaczom udanej resztki wakacji, bo o ile dobrze widzę, to zostało nam już mniej. niż 10 dni.

Krzysztof: Dokładnie, życzymy wam miłych wakacji. Tak, nawet wakacje. Życzymy wam udanej końcówki wakacji, a tobie Andrzej. Miłego dnia, no i do usłyszenia. Trzymajcie się, dzięki, że jesteście, dajcie lajka, dajcie słowa, oglądajcie, sharujcie, komentujcie, kłóćcie się z nami, tylko grzecznie.

Andrzej: To tak, zachęcamy do kłócenia się, ale w cywilizowany sposób, taki sposób jak najbardziej akceptujemy i zawsze chętnie wchodzimy w dyskusję. No, to z mojej strony również to wszystko. Trzymajcie się i do usłyszenia.

---