W tym odcinku podcastu omawiamy głośne ataki i najnowsze raporty ze świata cyberbezpieczeństwa. Analizujemy zaskakujący atak na Microsoft, gdzie literówka w projekcie open source doprowadziła do zhakowania runnera GitHub Actions. Ten przypadek pokazuje hakowanie CI/CD w prostej formie – jak drobne błędy i zaniedbania w środowiskach CI/CD mogą prowadzić do poważnych naruszeń, podkreślając znaczenie prawidłowej konfiguracji i świadomości deweloperów w obszarze DevSecOps.
Cyberzagrożenia w Polsce i nowe regulacje
Dodatkowo, omawiamy raport Orange dotyczący cyberzagrożeń w Polsce, zwracając uwagę na wzrost ataków phishingowych oraz dominację stilerów i botnetów IoT, takich jak Mirai. Podkreślamy znaczenie nowych regulacji, jak Cyber Resilience Act (CRA), w poprawie bezpieczeństwa urządzeń IoT. Poruszamy także kontrowersje związane z porównywaniem bezpieczeństwa systemów mobilnych Android i iOS, argumentując, że iOS nadal przoduje w ochronie danych. Odcinek oferuje praktyczne wnioski dla specjalistów IT/security, menedżerów technicznych i wszystkich zainteresowanych bieżącymi wyzwaniami w cyberbezpieczeństwie.
Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.
Transkrypcja
Andrzej: Dzień dobry, cześć. Witamy w kolejnym odcinku naszego podcastu. Tym razem przychodzimy z kolejną porcją ciekawych rzeczy, które wpadły nam na talerz w ostatnich dwóch tygodniach. Nie będę tutaj owijał bawełny. Chcemy polecieć szybciej, jednak dzisiaj chcielibyśmy się z nami boksować i zejść przynajmniej poniżej godziny. Trzymajcie kciuki, żeby nam wyszło. Mamy odpowiednią ilość ciekawostek, więc tutaj wydaje mi się, że się uda. No i nie będę już tutaj wskakiwał ja. Dzisiaj zacznie Krzysiek ze swoim pierwszym kąskiem.
Krzysztof: Tak, cześć, witajcie. Dzisiaj dla odmiany nic o sekretach, a może coś tam się znajdzie, taki malutki, tajny bajt na samym końcu. Andrzej, nie wiem czy pamiętasz w jednym z pierwszych odcinków naszego podcastu powiedziałeś, że byłeś kontrybutorem w kilku projektach open source’owych, ale Twoja kontrybucja często Zmierzała do tego, że była to jakiś fix jakiegoś typu, jakiejś literówki, czy jakaś drobna poprawka?
Andrzej: Nie byłem, tylko dalej jestem.
Krzysztof: Dobrze. Wyobraź sobie, że można było schakować Microsoft, komputer, który był wpięty w domenę Redmond, w domenę w Active Directory, jedną z starszych tego typu domen, za pomocą runnera na GitHubie. właśnie za pomocą literówki. A pozwól, że teraz opowiem Ci w skrócie, jak do tego doszło.
Andrzej: Ja od razu Ci pozwolę, bo ja czytałem o tym case’ie, a może nie czytałem, inaczej. Ten case wpadł mi gdzieś w feed’ie. Ja zrobiłem jakiś taki TLDR skan, być może to było na Twitterze, ale nie wchodziłem głębiej i sam się ucieszyłem, jak zobaczyłem, że będziesz chciał dzisiaj o tym opowiedzieć, bo po prostu nie miałem czasu, żeby wejść głębiej, no to ja sam posłucham.
Krzysztof: Tak, historia jest ciekawa, historia jest też krótka i obrazuje nam problem z jakim mierzymy się w kontekście środowisk CI. Tutaj autorzy postanowili przyjrzeć się bibliotece głębokiego uczenia maszynowego od Microsoftu, to biblioteka Deep Speed, która jest hostowana oczywiście jako open source na GitHubie, która notabene o zgrozo należy do Microsoftu. No i markę. Microsoft będący właścicielem GitHub’a pozwala na dołączenie do GitHub Actions, czyli mechanizmu CI, CD w GitHub’ie własnych self-hostowanych runnerów. Czyli możesz podpiąć swoją maszynę, uruchomić na niej runner i na tym będzie śmigał cały proces CI w kontekście repozytorium hostowanego na GitHub’ie. No i teraz tak, GitHub w kontekście tych self-hostowanych runnerów wyraźnie podkreśla w swoich docsach Andrzej, że publiczne hostowane repozytoria, które mają dołączone te self-hostowane runnery na maszynach, muszą spełniać szereg wymagań dotyczących bezpieczeństwa. Między innymi te runnery muszą działać w możliwie jak najniższych uprawnieniach, żeby z tego runnera nie wyskoczyć. Dobrze by było, żeby te runnery były efemeryczne, krótko żyjące. i tam wymienia jeszcze kilka innych rzeczy, które warto by było po mniejszych spełnić w samym jakby GitHubie, żeby się przed tym ustrzec, co może powodować taki self-hostowany runner na publicznym repozytorium. I teraz tak, owner DeepSpeeda, maintainer tej biblioteki, pracownik zresztą Microsoftu, ma dosłownie wszystkie z tych zaleceń, które Microsoft wypisuje we własnych dosach na GitHubie.
Andrzej: Ale to już jest ciekawy aspekt, że nawet pracownik danej organizacji, która rzuca jakimiś wymaganiami, może często je zignorować i to nie takie pojedyncze czy podwójne, tylko po prostu całość. I nawet w takiej organizacji właśnie jak Microsoft, czy oczywiście to też spotyka Google, czy pracowników innych dużych firm, to nie jest coś co dotyka tylko maluczkich na samym dole. Nie, oczywiście to dotyka dużych organizacji, które często są stawiane za wzór w ten sam sposób, dotyka tych mniejszych.
Krzysztof: Dokładnie. Więc możemy mieć taką złudne takie myślenie, że ci wszyscy pracownicy są świetnie przeszkoleni i znają te wymagania na wylot, a tak naprawdę wychodzi, że no jeżeli jednak rzeczywistość pokazuje, że jest inaczej. I teraz tak. Maszyna, na której hostowany był ten runner, to był prywatny komputer pracownika Microsoftu.
Andrzej: Prywatny komputer. Pierwsza czerwona lampka.
Krzysztof: Dokładnie, przepraszam. Komputer tego pracownika wpięty w tą domenę. Jego służbowy komputer, żeby tutaj uściślić. O to mi chodziło. I teraz tak, w domyślej konfiguracji takie self-hostowane runnery, można na nich uruchamiać każde workflow, które jest w takim repozytorium zdefiniowane. Jednym z takich workflows to jest takie typowe, które pewnie kojarzą nasi słuchacze, czyli takie workflow, które odpala się po założeniu pull request, gdzie ten nowy kod, który ma zamiar być dołączony do gałęzi, do której chcemy kontrybuować, musi zostać przetestowany przez szereg czeków.
Andrzej: Tu mam pytanie, czyli to w tym punkcie, takie trochę notabene, ale to w tym punkcie, gdybyśmy chcieli uruchamiać jakieś narzędzia security, przykładowo jakieś, nie wiem, skanowanie sekretów etc., to to by było w tym punkcie się by odbyło?
Krzysztof: Między innymi tak. OK. Dokładnie. I teraz tak. W domyślej konfiguracji tych self-hostowanych runnerów odpala Ci może każdy kontrybutor. A według GitHuba kontrybutor to jest każda osoba, która dodała do danego repozytorium jakiś kod. I tam nie ma rozróżnienia na to, czy ty dodajesz jakąś wzmiankę w jakichś docsach w Markdownie, czy ty dodajesz faktycznie i kontrybujesz do tego repozytorium aktywnie przez jakiś czas. Nie. Dodajesz kod, jesteś, dodajesz cokolwiek, jesteś kontrybutorem. I researcherzy, znając ten mechanizm, w jaki sposób można zostać kontrybutorem w danym repozytorium, przeskanowali to repozytorium w poszukiwaniu po prostu plików zapisanych w markdownie doxów i pomyśleli, że w sumie warto by było poprawiać literówki w jednym z tych doxów. To był dox dotyczący security. Takie doxy dotyczące security to jest jedna z dobrych praktyk, między innymi wymieniona przez CIS Software Supply Chain, żeby każdy repozytorium zawierało taki plik właśnie opisujący do kogo się zgłosić, jeżeli chodzi o kwestie bezpieczeństwa i tak dalej, ale to tak na…
Andrzej: Coś jak standard security.txt.
Krzysztof: Dokładnie, dokładnie tak. Ale to tak na marginesie. No i poprawili tam jakąś literówkę, to już mniejsza o to, czego ta literówka dotyczyła. I po dwóch tygodniach Microsoft, ten właściciel tego reprezentowania Microsoftu, smerżował tą zmianę.
Andrzej: Po prostu poprawili literówkę, to było takie daceficzer notabene.
Krzysztof: Tak, dokładnie. No i w tym momencie zostali już, ta osoba, ten researcher zostali już aktywnymi kontrybutorami w tym projekcie, w tym repozytorium. No i jak się domyślasz, bardzo szybko to repozytorium zostało. Zostały utworzone nowe workflowy, które mogły się już uruchamiać na tym selfhostowanym runnerze po stronie Microsoftu, a ten workflow to było nic innego jak proste uruchomienie kilku, kilku podstawowych komend takich jak who am I, host name i tak dalej. Stąd też dowiedzieli się, że jest to komputer w domenie Redmond. Dalej nie próbowali eskalować swoich działań, pewnie z racji pobudek po prostu czysto etycznych. Oni już wiedzieli wtedy, że jest grubo, bo są w domenie, więc nie próbowali eskalować i wychodzić poza, poza to.
Andrzej: Próba w koncept zrobiona.
Krzysztof: Dokładnie. I ja mam tutaj Andrzej do Ciebie pytanie. Jak oceniasz tą powierzchnię ataku? Jak oceniasz skalę zagrożeń ze względu na tą powierzchnię ataku w CICD?
Andrzej: To tutaj nie ma innej opcji niż odpowiedź duża i rosnąca. Czyli i to widać z różnego…
Krzysztof: I też świadomość nie rośnie tak szybko jak chętnie korzystamy z tych rzeczy.
Andrzej: Tak, tak. Oczywiście, dokładnie. Ta świadomość w dalszym ciągu jest dość niska. Przy czym ja chciałbym mocno zaznaczyć, bo jak o tym opowiadałeś, to od razu przyszło mi do głowy, że w zasadzie wszystko tutaj jest by design. Więc to nie jest tak, że to był jakiś błąd. No nie. Chcemy umożliwić kontrybutorom projektu możliwość uruchamiania, uruchamiania jobów, jakichś runów. runnerów po to, żeby wykonać jakąś akcję. Stąd było moje pytanie, że to w tym punkcie np. podpiąłbym sobie jakiś skaner, który coś by mi zrobił z, przeskanował przykładowo pod kątem sekretów, dajmy na to. I ma to sens, żeby taka funkcjonalność była i ma sens, żeby każdy kontrybutor mógł to zrobić, no bo jeśli kontrybuje do projektu, to moje komity powinny przejść takie skany i ja powinienem być w stanie to uruchomić. No ale widzimy te unintended consequences, czyli brak, no można powiedzieć zakładam, nie wiem, ale się domyślam, że osoby projektujące ten feature nie przewidziały takiego rozwoju wypadków, czyli być może wykonały modelowanie zagrożeń, być może nie. Z tego co wiem, to Microsoft wykonuje modelowanie zagrożeń. GitHub również, czyli GitHub pracując nad tym featurem, ogólnie GitHub Actions, prawdopodobnie wykona modelowanie zagrożeń, ale albo im to nie wyszło, albo po prostu zaakceptowali to, albo nie było czasu się tym zająć. Bardzo fajny przykład na pokazanie tego, że pomimo tego, że coś jest featurem i w zasadzie to tak powinno działać. No tak, powinno to tak działać, ale jak widać da się to wykorzystać, a więc bardziej to zależy od tej kreatywności tego atakującego niż od samego feature’a, bo feature przez bardzo długi czas nie był uznawany za podatny. Nagle pojawia się ktoś i mówi, a jak połączę to i to i zrobię to i to, będę w stanie jakoś to obrócić na swoją korzyść.
Krzysztof: Tak i tutaj też Fitcher był pewnym medium w tym ataku, bo zobacz, że gdyby ten runner był faktycznie mocno odizolowany, uruchomiony na maszynie, która nie jest komputerem pracownika Microsoftu wpiętym w domenę, to skutki tego ataku byłyby Relatywnie niewielkie.
Andrzej: Oczywiście, gdyby pracownik się zastosował do wszystkiego, do czego powinien się zastosować, to nie byłoby problemu. Ale jak widzimy, często gęsto jest tak, że napisać sobie możemy, co chcemy. Natomiast security powinno działać by default tak, że nie pozwala nam na popełnienie czegoś, czego nie chcemy. Znowu idziemy bardziej w kierunku safety niż security, tak jak przykładowo działają inne poważne działy inżynierii i nie pozwalają na zrobienie czegoś, czego nie chcemy, żeby użytkownik zrobił, a nie tylko mówią mu, no nasi użytkownicy są wyedukowani, więc tego nie zrobią. Jeżeli tak to robimy, to będziemy mieć jakiś podzbiór przypadków, które jednak się do tej naszej idealnej wizji rzeczywistości nie dostosują.
Krzysztof: I zanim skończymy ten temat, to zasieję takie ziarno niepewności. i pomysł na research. Weźmy 100 największych organizacji na GitHubie, przeskanujmy im dużym modelem językowym literówki w ich open source’owych projektach i sprawdźmy, w których tych projektach są wykorzystywane self-hostowane runnery.
Andrzej: Świetny pomysł na research. Zachęcamy, bo tutaj w każdym odcinku rzucamy jakiś pomysł na research.
Krzysztof: A sami ich nie robimy.
Andrzej: To jest crowdsourcing. Pamiętajcie, jeżeli ktoś będzie chciał wykorzystać nasze pomysły, to go ahead, tylko dodajcie nas w kreditsach.
Krzysztof: Dokładnie. Skakujemy do twojego raportu.
Andrzej: Nie mój raport, raport od Orange, ale coś bardzo świeżego, bo w zasadzie pojawiło się chwilę przed nagrywaniem tego naszego odcinka. Ja nie mam jakoś super dużo ciekawych rzeczy, które wyciągnąłem z tego raportu, to oczywiście nie oznacza, że tam ich nie ma, natomiast z racji tego czym ja się zajmuję w bezpieczeństwie, czyli bezpieczeństwem aplikacji, a samym raportem Orange, który raczej skupia się na zagrożeniach dotyczących sieci i to szczególnie chodzi o kawałek sieci polskiego internetu, czyli pewien podzbiór wszystkich adresów IP, wszystkich adresów IP w wersji czwartej jest 4 miliardy, oczywiście z hakiem, no to pewien podzbiór należy do Polski i można powiedzieć, że jest to polska cyberprzestrzeń. No i Orange od dziesięciu lat, bo to jest dziesiąta edycja tego raportu, wypuszcza co roku raport analizujący poprzedni rok, czyli w 2024. wyszedł raport, który ma wnioski z roku 2023 i możemy dzięki temu obserwować pewne zmiany w zagrożeniach, które pojawiają się w naszej cyberprzestrzeni. Być może nasi słuchacze wiedzą, być może nie, ale Orange jest tutaj chyba największym dostawcą usług telekomunikacyjnych w Polsce, stąd wnioski, ale przede wszystkim to jakie mają wizybility, to na co patrzą, to co widzą, no z racji tego do czego mają dostęp i że są największym operatorem.
Krzysztof: Rzutuje na stan tego, jak to jest widziane, jak to działa w Polsce.
Andrzej: Dokładnie tak. Jest tutaj bardzo dużo sygnału i mało szumu. Po prostu mają fajne dane. I jednym z takich rzeczy, która przykuła moją uwagę jest to, że w zasadzie widzimy Widzimy bardzo dużo różnych wzrostów, ale widzimy wzrosty użytkowników, którzy się złapali na ataki wścigowe i widzimy ich wzrost w zasadzie z roku na rok. I to jest tak, tutaj widzę konkretnie przed sobą wykres z 2019 do roku 2023. No i niestety, ale jest to, wygląda dość stromo. ten wzrost. Nie będę tutaj podawał liczb, bo nie ma to sensu, natomiast jest tendencja mocno wzrostowa i dla zablokowanych domen, co niejako daje nam rzut na ilość ataków, no bo jeśli jest coraz więcej domen wykorzystywanych do ataków, to samych ataków jest pewnie więcej lub jeśli ich nie jest więcej, to przynajmniej operacji są większe, no bo nawet jeżeli mam 10 operacji dzisiaj i 10 operacji za rok, ale tych 10 operacjach w tym roku wykorzystuje 100 domen, a za rok wykorzystuje 1000, no to mam większe operacje. Więc niejako targetuje większą ilość użytkowników i tutaj widzimy niestety, ale też bardzo, bardzo duży wzrost. Dość podobny do tego poprzedniego, jeżeli mówimy o skali wzrostu. Więc to nie jest fajne, czyli jest coraz więcej ataków i coraz więcej użytkowników się łapie na te ataki. Taki jest wniosek z tego grafu. Niestety jest tutaj tego dużo. Kolejnym ciekawym grafem, który przykuł moją uwagę, są rodzaje zagrożeń i rozkład procentowy dla nich. Tutaj jest konkretnie kilka rodzajów zagrożeń, natomiast to, co było dla mnie ciekawe, to to, że Zajmują praktycznie połowę, to jest 44% versus kolejne zagrożenie botnety IOT, czyli Internet of Things, które zajmują 20% i raty, czyli tak naprawdę po prostu narzędzia, które pozwalają zdalnie administrować komputerem, a jak mamy taki dostęp to jesteśmy w stanie wykonać wiele akcji za użytkownika i to jest kolejne 18 więc tak naprawdę 44 18 20 więc już mamy to to jest 80% czyli stilery botnety IOT i raty. raty i stilery możemy zakwalifikować jako w zasadzie 1. logiczny zbiór, bo targetuje to konkretnych użytkowników, pewien typ użytkownika. Natomiast botnety IOT możemy trochę wyciągnąć, bo jest to trochę co innego. Przy czym te botnety IOT były też dla mnie dość ciekawe, bo tam jeżeli wejdziemy głębiej, to tam parę razy się pojawia z rozbiciem kwartalnym Mirai. Amirai to jest botent, który jest dość stary, więc jeżeli on się tak mocno objawia i tam był na pierwszych miejscach chyba przez trzy kwartały. No to to jest ciekawe. Ciekawe, że do tej pory, albo inaczej, to pokazuje, że w dalszym ciągu mamy pełno różnych urządzeń IOT w polskiej sieci internet, które są podatne na botnet Mirai. Coś ciekawe samo w sobie, ale nawet to dla mnie nie jest super ciekawe. Nie dlatego o tym mówię. Ale mówię o tym dlatego, że zbliża się coś takie jak CERA Cyber Resilience Act, który dotyczy właśnie IoT. To jest rozporządzenie na chwilę obecną, to jest jeszcze rozporządzenie na poziomie Unii Europejskiej, ale oczywiście zacznie to schodzić na państwa członkowskie. I to jest ciekawe, bo mnie ciekawi jak CERA w czasie poprawi bezpieczeństwo, czyli przykładowo jak będzie wyglądał ten raport za pięć lat. To mnie ciekawi. Chciałbym, żeby wyglądał lepiej, żeby to Internet of Things był bezpieczniejszy. Ale czy wyjdzie? Nie wiem. We’ll see. Ale mam nadzieję, że tak. GDPR, RODO, nie wiem, ale stawiam, że netto jednak podniosło trochę poziom bezpieczeństwa. I tutaj myślę, że to CERA też trochę podniesie. I mam nadzieję, że idąc z czasem tych zagrożeń związanych z botnetami IoT będzie coraz mniej. Mam taką nadzieję. Co ty sądzisz o tym Krzysztofie?
Krzysztof: Nawiązując do bezpieczeństwa IoT, wiele raportów mówi, że to co wychodzi z fabryki, jeżeli chodzi o IoT, jest już kilka lat do tyłu. To może być jeden z problemów. Urządzenia są tak łatwo po prostu infekowalne, tak? A drugim takim tutaj elementem jest tego, że często są wpinane na równi w tej samej sieci co nasze urządzenia, z których korzystamy na co dzień, takich jak komputer, telefon. i tak dalej. Nie segregujemy tego, nie segmentujemy.
Andrzej: Tak, tak, tak. Krzysiek zwraca uwagę na to, że raczej najczęstszym sposobem działania jest wrzucenie routera, który dostajemy go od ISP, naszego dostawcy internetu i wszystko jest po prostu w jednej sieci lokalnej. Co nie jest idealne, oczywiście lepiej byłoby mieć segmentowaną sieć. Natomiast dostawcy internetu nie zawsze nam to ułatwiają, bo często gęsto dostęp do panelu administracyjnego nie jest łatwy, a nawet jak jest łatwy, to oprogramowanie jest specjalnie uproszczone, żeby nie dało się segmentować sieci. I żeby faktycznie to zrobić, to często potrzebujemy jakiś dodatkowy klocek w tej układance, jakiś dedykowany router, który nam to umożliwi. Co oczywiście zwiększa poziom zaawansowania potrzebny do skonfigurowania tego, no a to efektywnie zmniejsza ilość użytkowników, którzy są w stanie coś takiego zrobić.
Krzysztof: Dokładnie. I jeszcze drobny komentarz do tego, że stealery wiodą prym w tym całościowym jakby obrazie tego, jakie rodzaje zagrożeń w składzie procentowym, więc nie ilościowym, procentowym tutaj Orange tam prezentuje. To samo przewija się w dedykowanych raportach np. dotyczących bezpieczeństwa supply chainu. Mój typ, dlaczego tak jest, dlaczego stealery, po prostu przestępcy chcą wpaść, ukraść i wypaść. Persystencja w systemach jest po prostu ciężka.
Andrzej: Zgadza się, a na koniec dnia to jest biznes, więc cyberprzestępcy kierują się zyskiem. Jeżeli będzie mnie coś końcem końców taniej kosztować i ja więcej na tym zarobię, to to jest no brainer, że będę to robił.
Krzysztof: To nie jest Andrzej Nation State, który czeka 4 lata. ukrywając się gdzieś w kanałach, żeby zaatakować punktowo.
Andrzej: Maintainera biblioteki XR. To nie jest ten przypadek. To są faktycznie biznesmeni. To są biznesy, które są nastawione na robienie pieniędzy. Jest jeszcze jedna statystyka, która z tego raportu Orange mnie zaciekawiła. A może nie tyle statystyka, co podejście i kawałek metodyki. I tutaj Ja nie chcę być już czypliwy, ale rzuciło mi się w oczy, że przy kawałku odnośnie złośliwego oprogramowania w sieci mobilnej jest, i tutaj zacytuję, bo nawet sobie wybrałem, jest taki tekst. Coraz częściej odkrywane i publikowane są też nowe podatności w systemach Android i iOS. które stwarzają nową powierzchnię do ataku dla operujących w przestrzeni urządzeń mobilnych aktorów zagrożeń. To ważne przypomnienie, że większość urządzeń mobilnych wciąż jest niewystarczająco chroniona pomimo przechowywanych w nich wrażliwych danych osobistych i służbowych. I następnie mamy rozbicie tych różnych zagrożeń, które dotykają tego kawałka sieci mobilnych. Natomiast to, co mnie zabolało, to wrzucanie Androida i iOSa do jednego worka. Ja jestem daleki od bycia fanbojem Apple’a. Oczywiście korzystam ze sprzętu Apple’a i nie zamierzam się przenosić. Dobrze mi się z niego korzysta i jak już raz ktoś wejdzie w tą króliczą norę, to często już zostaje. Ja tak miałem parę, parę, no już prawie dekadę temu. Ale wrzucanie Androida i iOSa do tego samego worka pod kątem zagrożeń na urządzenia mobilne jest nie na miejscu. Jest nie na miejscu, bo jeżeli potem przechodzimy do faktycznych danych odnośnie zagrożeń i wszystkie te zagrożenia tak naprawdę dotyczą tylko Androida, to jest to nie fair wobec iOSa. Każdy, kto ma pojęcie o bezpieczeństwie, doskonale wie, że iOS jest tutaj lata świetlne, może nie lata świetlne, ale wjedzie prym w bezpieczeństwie. i nawet jeżeli będziemy mówić o tak niskopoziomowym bezpieczeństwie jak właśnie Nation State, który atakuje, targetuje konkretnych ludzi, to być może Android i iOS nie ma znaczenia, bo Nation State, NSA skakuje i iOS, i Androida. To 8200 nie będzie miał z tym problemów. rozwalą i jedno i drugie. Ale jeśli mówimy o typowych zagrożeniach, typowych cyberprzestępcach, którzy atakują zwykłych ludzi, to Android względem iOS-a nie ma podjazdu. Te dwa ekosystemy nie stoją nawet obok siebie. Po prostu jeżeli mamy przykładowo naszego rodzica i chcemy żeby był bezpieczniejszy, I możemy sobie na to pozwolić, to na pewno najbezpieczniejszy będzie na iOSie. I to bez dwóch zdań. Bo iOS jest bardzo restrykcyjny pod kątem tego, co dopuszcza do swojego App Store’a. Ma to swoje plusy, ma to swoje minusy. Krzysiek?
Krzysztof: Dokładnie tak jak Andrzej powiedziałeś. Mimo, że Google wykonuje tytaniczną pracę, jeżeli chodzi o podnoszenie progu wejścia na swój sklep i to, jakie wymagania trzeba spełnić. to multum urządzeń, które musi wspierać i multum vendorów, którzy produkują te urządzenia, no niejako implikuje to, że te problemy będą się pojawiały, co w przypadku iOS-a nie ma miejsca, przynajmniej ja nie słyszałem o takich sytuacjach, w których ta skala problemu byłaby Tak gigantycznie duża jak w Google Play Store.
Andrzej: Oczywiście i ja tutaj chciałbym jasno zaznaczyć, że to nie chodzi o to, że Android jest gorszy, bo jeden i drugi system jest spoko, natomiast jeżeli rozpatrujemy to pod kątem bezpieczeństwa.
Krzysztof: I też typowego Kowalskiego.
Andrzej: Typowego Kowalskiego to Android jest mniej bezpieczny i to nie troszkę tylko rząd albo nawet dwa albo nawet więcej rzędu wielkości, przy czym Tak jak powiedziałeś, Android i cały ekosystem jest mniej bezpieczny, ale dlatego, że jest bardziej skomplikowany. Support dla tak dużej ilości telefonów, dla tak dużej ilości vendorów, to nie jest taki piece of cake. Apple jest w stanie zapewnić bezpieczeństwo, jakie jest w stanie zapewnić, tylko dlatego, że wytwarza I hardware, i software. Tylko dlatego. I jest bardzo zamknięte. To zamknięcie ma swoje plusy, ale ma też minusy. Przykładowo teraz w Stanach jest proces z Apple’em właśnie o zamknięciu ich ekosystemu. I to zamknięcie ma swoje minusy, właśnie takie jak przykładowo brak dostępu innych, monopod, zwykły monopod, brak dostępu innych vendorów do App Store’a, bo muszą przejść przez oficjalny App Store. To jest minus, ale plusem jest to, że zyskujemy bezpieczeństwo, jest coś za coś, ale tutaj w tym raporcie po prostu bali mnie to, że w metodyce jest wskazanie jako by iOS miał podobne zagrożenia jak Android. Natomiast to co jest przedstawione jasno wskazuje, że nie, nie ma podobnych i jeśli ktoś ma iOS-a, to nie musi w zasadzie się tymi zagrożeniami przejmować, które są tutaj wylistowane. A jeżeli ktoś ma Androida, no to już zależy, bo jeśli ktoś ma najnowszego Androida z flagowym telefonem, nie jest zrootowany, to prawdopodobnie też się nie musi tym przejmować.
Krzysztof: Oczywiście, dokładnie.
Andrzej: A tutaj jeszcze mała uwaga, bo cały raport generalnie polecam przeczytać, jest fajny, znowu z mojej perspektywy jest mniej przydatny, bo ja nie siedzę konkretnie w tym wertykalu, ale zawsze dobrze trzymać rękę na pulsie i zobaczyć co się pojawia w oficjalnych raportach, szczególnie jeśli są po prostu od nas z kraju, no bo te dane są dla nas wtedy lokalne, mają większą wartość. Na samym końcu tego raportu są dwie ostatnie strony, które prezentują taki glosariusz różnych terminów, które są wykorzystywane w tym raporcie. Polecam, szczególnie początkującym. Jest to taki dobry zestaw definicji, który nie został wypuszczony jako książka, ale można za darmo dostać go w tym PDF-ie.
Krzysztof: Można, można. I można by było nawet zmonetyzować, parafrazując.
Andrzej: Opisy są tak dobre, że można by je zmonetyzować, a przynajmniej zrobić z niego takiego freebie, żeby zbierać maile.
Krzysztof: O, dokładnie.
Andrzej: Przy czym Orange tego nie zrobił. Raport jest dostępny bez podawania maila. Jest normalnie link do PDF-a. Szapoba!
Krzysztof: Okej Andrzej, przeskakujemy do kolejnego tematu. Mówiliśmy o Nation State i o IGZ-cie, a teraz powiem w jaki sposób OpenSSF radzi, jak zabezpieczać się konkretnie na kanwie tego ataku związanego z całej tej akcji związanej z IGZ-tem. My w ogóle polecamy przesłuchać nasz poprzedni odcinek, gdzie razem z Andrzejem tłumaczyliśmy jak w ogóle przebiegał cały atak i na czym on polegał. Tutaj Open Source Software Foundation, fundacja założona w ramach Linux Foundation, przedstawia kilka swoich zaleceń po tej całej akcji. Te zalecenia są też spójne z tym, co wydała Agencja ds. Cyberbezpieczeństwa i Bezpieczeństwa Infrastruktury, amerykańska CISA. I tak, OpenSSF i CISA wspólnie wymienia pewne specyficzne paterny, wzorce w atakach socjotechnicznych na deweloperów i ludzi, którzy utrzymują paczki opensource’owe. I pewnie będziesz się uśmiechał, bo to wszystko co oni piszą jest stricte wzięte z tego jak wyglądał ten atak w kontekście XZ. Przyjazne, ale agresywne i konsekwentne dążenie osoby utrzymującej projekt do ich hostowane jednostki przez stosunkowo nieznane osoby ze społeczności. Tak to się właśnie działo w przypadku XZ, gdzie ten Jim Young, czy jakkolwiek ten gościu się, czy gościuła się nazywała.
Andrzej: Tak, nie wiemy. Nie wiemy. I pewnie się nie dowiemy.
Krzysztof: Nie możemy. w sposób bardzo grzeczny, ale jednocześnie taki pushy, próbował się dostać do tego, żeby kontrybuować do tego repozytorium w sposób aktywny. Żądanie podniesienia do statusu osoby utrzymującej projekt. Tak, to historia, w której maintainer XZ tak naprawdę nie miał czasu przez swoją sytuację życiową zajmować się tym projektem i to wtedy zostało wykorzystane w XZ. Ta sytuacja, w której przychodzi dobra dusza i mówi, wiesz co, jeżeli ty nie masz czasu, a tu jest taki fajny projekt, to ci ja mogę pomóc. Dobra ci serca oczywiście.
Andrzej: Za free.
Krzysztof: I kolejne zalecenie, poparcie pochodzące od innych nieznanych członków społeczności. I tam był ten element Andrzej, w którym nagle w pewnym momencie pojawia się tłum sztucznie wygenerowany i mówi, ej, weź już, dołącz tą zmianę, którą ten Gene Young tam nam przygotował. My ją chcemy w tych naszych dystrybucjach. My chcemy, żeby ta zmiana wyszła.
Andrzej: Czemu to tak długo siedzi w Code Review? Już, już, mecz, mecz.
Krzysztof: I zalecenie, o którym może nie wspominałeś, ale mówiłeś na temat tych wyłączonych testów. i tutaj OpenSSF też to wskazuje, że wszystkie odstępstwa od typowych praktyk, kompilacji, budowania, wdrażania, testowania mogą wskazywać na to w tego typu operacjach, że coś jest nie tak i powinna nam się zapalić czerwona lampka.
Andrzej: Ale to w zasadzie wszystko to co powiedziałeś. to jest dokładnie na kanwie przypadku XZ. To jest tak jakby ktoś siadł, przeanalizował cały łańcuch ataku na XZ i po prostu wyciągnął dobre praktyki, co powinniśmy zrobić, żeby takiego kolejnego case’u nie było. Z mojej perspektywy jest to takie suche gadanie, w zasadzie nic nowego to nie wnosi, bo o ile oczywiście ja mogę przeprowadzić sobie sam taką analizę i wyciągnąć takie wnioski, no to co z tego. Jeśli to się nie będzie albo działa automatycznie, albo jeżeli nie zaprzęgnę tego, o czym mówiliśmy ostatnio, czyli np. LLM-a do pewnej analizy jakichś składowych, takich akcji. Takiej obsekowej, tak. Dokładnie, takiej obsekowej analizy przykładowo takiego potencjalnego kontrybutora. No to jeżeli ja po prostu sobie to wypiszę, to jest takie, jaką to ma wartość, nie jestem pewien, bo dla mnie to jest takie puste gadanie, nie? Ej, wiecie, jak w tym memie, nie? Nie ktoś.
Krzysztof: Zróbcie coś, błagam.
Andrzej: Dokładnie, no to fajnie. Spisaliście, ale nic z tego nie wynika. No ale okej, może, bo ja nie wykluczam, może po prostu to popnie kogoś, to zrobi mnie czegoś. Co będzie miało większą wartość.
Krzysztof: Takiego security awarenessu w kontekście właśnie maintainerów, deweloperów, którzy kontrybuują do open source, ale nie tylko. Ogólnie też w dużych organizacjach, gdzie te ataki na deweloperów też mają miejsce i ich wektor, ich kształt jest całkiem podobny w niektórych przypadkach.
Andrzej: W bardzo dużej ilości przypadku. Więc tak, to może być takim punktem zapalnym, ale samo w sobie ja tutaj widzę dość małą wartość merytoryczną płynącą konkretnie z tego artefaktu. Ale we’ll see. Maybe po prostu to poprowadzi do czegoś większego. We’ll see. Tak, kolejne jest moje. Dobrze, kolejne jest moje. Biorę to na klatę. Nie każdy widział. w zasadzie, myślę, że dość mało osób to widziało, bo to jest taki dość zaawansowany case raczej dla wąskiej ilości osób. Juru, nasza jedna ze światełych perełek, czyli Mateusz Jurczyk, który pracuje w Google w projekcie Zero. już od wielu lat, od samego początku Projektu Zero, 2014, a Juro w Google jeszcze dłużej pracuje, chyba 2011, więc trochę lat tam już jest. Natomiast wypuścił ostatnio kolejny, nowy swój research, którym przez, jak pisze, przez ostatnich bodajże 18 miesięcy, ponad półtora roku siedział i analizował rejestr Windowsa, Windows Registry pod kątem podatności i udało mu się znaleźć Na samym początku chyba 42 podatności, nie, 44, a potem jeszcze w dobie dalszych prac kolejne 6, czyli łącznie zakończył ten swój backhand z równą liczbą 50 podatności, które prowadzą do m.in. podniesienia uprawnień w Windowsie. Czyli przykładowo ja jestem zwykłym użytkownikiem Windowsa, robię, wykorzystuję jakąś podatność, którą znalazł Juru, mam na nią exploital, sobie piszę albo biorę od kogoś kto mi napisał i podnoszę swoje uprawnienia do administratora. Takich podatności było 39 z tej całej 50, więc całkiem sporo. Natomiast nie do końca ciekawe jest samo to. Bardzo duże propse dla Juru. To jest kolejny jego research światowej klasy. To jest najwyższa topka topki. Tym bardziej Juru bardzo systematycznie i dobrze podchodzi do projektowania metodyki, jaką wykorzystuje w backhuntingu, do opisywania tej metodyki. Przechodząc przez jego opisy, a takich opisów ma i na swoim prywatnym blogu i na blogu Project Zero przez lata uzbieranych całkiem sporo. Jednym z nich jest na przykład całe badanie odnośnie bezpieczeństwa parserów czcionek w Windowsie, które robił bardzo ciekawe rzeczy wokół tego. Natomiast to jak podchodzi ten opis metodyki, on jest w zasadzie nawet bardziej wartościowy niż to co dla obserwatorów postronnych jest bardziej wartościowy niż to, co faktycznie Juru znalazł, no bo to co znalazł to fajnie, dla Microsoftu to ma wartość, ale dla mnie osoby postronnej nie do końca, ale to, że Juru idzie ten krok dalej, nie tylko rzuca te całe informacje do vendora, żeby ten vendor to poprawił, ale również przykłada bardzo ważną uwagę do tego, jak to opisuje, żeby to było dobrze, zwięźle, metodycznie opisane, no to dla osób postronnych, które chciałyby zajmować się bezpieczeństwem niskopoziomowym, no to to są perełki, bo czytając jego jeden, drugi, trzeci, czwarty, czytając całą jego twórczość, można się bardzo dużo nauczyć i można wyrobić poniekąd swoją własną metodykę szukania podatności właśnie w różnego rodzaju aplikacjach, ale tutaj jury skupia się na tych pisanych w językach niskopoziomowych.
Krzysztof: Prawdziwy rzemieślnik.
Andrzej: Tak, tak, tak. Juru jest tutaj prawdziwym rzemieślnikiem, już na poziomie raczej mastera, ale jest prawdziwym rzemieślnikiem i podchodzi naprawdę kompleksowo do tego, co robi. Widać, że przywiązuje uwagę do detali. Polecam każdemu. Kto chciałby robić podobne rzeczy? Niekoniecznie jest niskopoziomowym softwarem, ale sama metodyka tego jak podchodzi do badania bezpieczeństwa całych powierzchni ataku jest mega wartościowa dla każdego backhuntera wannabe. W zasadzie o tym temacie to tyle. Dokładnie chciałem uwypuklić właśnie ten aspekt podchodzenia metodyki, bo to często jest pomijane. Często jest tak, że osoby szczególnie, może nie tyle początkujące, ale nawet na poziomie intermediate, wpadają do takiego write upu, rzucają na niego okiem i same sobie mówią, a dobra nie dam rady. Nie dam rady tego przeczytać i zrozumieć. Nie. To jak pisze Juru da się zrozumieć. Oczywiście nie zawsze będzie łatwo zrozumieć techniczne aspekty konkretnych podatności, ale to jak opisuje metodykę, to wystarczy. myślę, że każda osoba powyżej stanowiska juniora pełniąca rolę czy security ingeniera, czy security testera. Czytając to na pewno wyniesie coś dla siebie. Po prostu przenosząc pewne taktyki, techniki, procedury na swoją pracę, nieważne czy testuje aplikacje desktopowe, czy aplikacje webowe.
Krzysztof: Tak, mi się tylko podoba, krótko mówiąc, że tutaj został wzięty na cel rejestr Windowsa i tutaj się też fajnie roluje z tym, co robią chłopacy, chłopacy i panie z Portswigera. Ci też sięgają do takich mniej sexy feature’ków z technologii, które nie są najświeższe. i rebrandują je, odświeżają we własnym stylu, szukając nowych podatności, tak jak ma na przykład miejsce z HTP Request smugglingiem i jego pochodnymi, które teraz wychodzą, tak? Tak
Andrzej: i to nawet ja bym to rozszerzył i powiedział, że głównie chodzi o to, że ludzie na odpowiednio wysokim poziomie backhuntingu przestają myśleć o szukaniu konkretnych instancji podatności, czyli przykładowo moim celem nie jest znalezienie kolejnego XSS-a w jakiejś końcówce, w jakimś endpointzie, czy w jakimś kawałku aplikacji, tylko moim celem jest znalezienie pewnych globalnych patternów w jakiejś powierzchni ataku, w jakiejś zestawie funkcjonalności po to, żeby potem odkryć wiele instancji tego patternu. A nie tylko jakiejś pojedynczej, jakiegoś pojedynczego stack based buffer flow, a w jakiejś pojedynczej funkcji. To jest mnie interesujące i właśnie tak podchodzi do tego Juru i to widać potem jak to opisuje, ale też oczywiście tak podchodzą właśnie m.in. Albino Wax z Sport Triggera. Bardziej zależy mu na pewnych sposobach ataków, które może potem wyłapywać instancje tych sposobów, które są nowe, ale z takim spinem, bo opierają się na tym, co było kiedyś. Podobnie tutaj, wzięcie jakiejś powierzchni ataku, w której wiadomo, że były w przeszłości błędy, ale nikt nie siadł i nie zbadał całej powierzchni ataku, tylko one były znajdowane punktowo.
Krzysztof: Mhm, mhm, dokładnie. To co, wskakujemy dalej?
Andrzej: Wskakujemy, wskakujemy, to już ostatnie Twoje.
Krzysztof: Datadog wypuścił raport. Ja w zeszłym roku z tym raportem się nie miałem okazji spotkać, więc nie wiem czy to jest jego pierwsza edycja, czy też nie.
Andrzej: Mnie się wydaje, że go widziałem, ale ręki sobie nie dam uciąć, bo skończyłbym bez ręki.
Krzysztof: Raport nosi nazwę State of DevSecOps i zawiera siedem faktów na temat szerzej pojętego DevSecOps. Ja wyciągnąłem Andrzej trzy z nich, bo w mojej szczerej opinii nie wszystkie te fakty stricte dotyczą naprawdę DevSecOps. Popłynęli dosyć szeroko, więc od razu wskoczę w pierwszy fakt. Jeżeli chodzi o ekosystem Java i Mavena, No to tutaj autorzy tego raportu wskazują, że znaleźli, jesteśmy tam w stanie procentowo, mamy największe szanse na to, że znajdziemy tam najwięcej podatności na poziomie high i critical. 90% wszystkich aplikacji, które są oparte o Java według tego raportu posiada od jednej w górę podatności, które są właśnie na tym poziomie, czyli Critical albo High Severity, co wcale mnie nie dziwi, patrząc na to, jak przyjął się Lock for Shell czy Spring for Shell i tego typu podatności, które męczyły nas wszystkich przez ostatnie 3-4 lata. Autorzy wskazują też tutaj na fakt tego, że 63% wszystkich podatności jeżeli chodzi o ekosystem Java wynikały z zależności pośrednich Andrzej. To jest to, o czym często wspominamy w naszych rozmowach, że ta struktura drzewa rozrasta się do naprawdę kolosalnych kolosalnych rozmiarów, szczególnie w ekosystemie np. javascriptowym, gdzie npm tej wiedzie prym, zaciągając jedną paczkę, nagle robi nam się 250 tysięcy innych pod spodem. Więc to visibility, które musimy mieć korzystając z open source’a w obecnej chwili w 2024 roku jest po prostu must have. Skakując w drugi fakt, ale tak naprawdę fakt trzeci, który jest opisany w tym raporcie, to coś o czym też wspominaliśmy ostatnio, że nie wszystko co wynika z CVSS, a wynika z niego, podatności są high albo critical. Oczywiście ta skala jest szersza, ale gdybyśmy przejrzeli sobie i zrobili taką analizę wszystkich rzeczy, które zostały zgłoszone w 2023, no to tutaj autorzy tego raportu mówią nam o tym, że tak naprawdę zgłoszono 4000 podatności, które były na poziomie high i 1000 podatności na poziomie critical. I mówiliśmy już o tym, że jeżeli mamy tak bardzo przesuniętą tą skalę, że wszystko jest wysokie albo krytyczne, to tak naprawdę przestajemy zwracać w ogóle uwagę na to, co mówią nam te katalogi agregujące podatności. i autorzy tego raportu wskazują tutaj Andrzej na to, że odpowiedzią na ten problem właśnie vulnerability managementu i tego w jaki sposób sobie w ogóle poradzić z wyprowadzaniem tych podatności w sposób, który jest przyjazny dla biznesu, który się opłaca biznesowi, jest na przykład wykorzystanie Exploit Prediction Scoring System, tak? EPSS. A z mojej strony i myślę, że z twojej również, to taki zdrowy rozsądek i może gdzieś droga w kierunku robienia tego, tak jak Zoom, który ostatnio pochwalił się tym, że wypuszcza własny scoring, bo nie jest w stanie działać w oparciu o CVSS.
Andrzej: Ale jak to? Chcesz mi powiedzieć, że oparcie swojego całego programu w WNM o CVSS jest jakieś nieakuratne? Nie daje efektów? Ale jak to? Pierwsze słyszę.
Krzysztof: Przecież tam siedzą jacyś fachowcy i to wszystko liczą, tak?
Andrzej: Tak, no i jak mam 10 podatności, które wszystkie CVSS 10, Wszystko jest okej. It’s fine. It’s fine. I wszystko się pali. Bardzo podoba mi się właśnie ta uwaga o EPSS i to co ostatnio mówiliśmy. Nie ma jakiegoś idealnego narzędzia. Natomiast jedno jest pewne. CVSS ma swoje problemy. I być może należyłoby pomyśleć nad albo ukróceniem, albo sprofilowaniem tego jak się używa we własnej organizacji CBSS-a, albo poszukaniem innego narzędzia. Bo taki stokowy CBSS jednak prowadza, często, gęsto prowadza więcej chaosu niż struktury do naszego procesu wyprowadzania podatności.
Krzysztof: Na pewno polecałbym zainteresowanie się tym, w jaki sposób można z tego kalkulatora, który jest opublikowany na stronie organizacji FIRST bodajże, jeżeli się nie mylę, która stworzyła CBSSA, tego scoringu, który można dołożyć w oparciu o kontekst, w którym ta podatność występuje. opierając się na samym baseline nie powinniśmy na pewno budować naszego vulnerability managementu.
Andrzej: To jest pewne.
Krzysztof: Dokładnie. I wskakujemy w ostatni fakt, fakt siódmy, tutaj na naszej liście w tym podcaście trzeci, czyli to, że używanie krótko żyjących poświadczeń w środowiskach CI, CD, w pipelines jest ciągle niski, czyli Dla przykładu poświadczenia do AWS, długo żyjące klucze, które na przykład potem przez przypadek są w jakiś sposób zdradzane w logach z wykonania takiego pipeline’u. Często jest gęsto tak, że ilość tych narzędzi, które wpinamy w CI, powoduje, że ten sekret przez przodek może zostać wyprintowany w logach. I nawet jeżeli zostanie wyprintowany, a jest krótko żyjącym sekretem, to tak naprawdę to mleko nie rozleje się nam aż tak bardzo.
Andrzej: Prawdopodobieństwo jest mniejsze. Więc, żeby tu jeszcze raz to wypuklić, rekomendacja jest używanie krótko żyjących sekretów, a nie długo żyjących. Problemem jest to, że w dalszym ciągu większość sekretów jest z tej drugiej kategorii, czyli sekretami są długo żyjącymi. Jeśli taki sekret zostanie upubliczniony, to czasami nawet po latach, W dalszym ciągu można go użyć.
Krzysztof: Robiąc tak zwany dumpster diving, kopiąc gdzieś tam w śmieciach, tak naprawdę szukając w tych logach, a to nie jest ciężkie. Łatwo sobie jest wyobrazić, że przez API GitHub’a czy GitLab’a, biorąc tutaj z brzegu tych pierwszych dwóch gigantów, dobijamy się, jeżeli mamy dostęp, ściągamy logi z jaja i po prostu jakimś automatem szukamy w kontekście właśnie sekretów.
Andrzej: Dokładnie.
Krzysztof: Tak, tak to oni robią.
Andrzej: Tak, tak. Wszystko jest automatyzowane. Nikt tego nie robi ręcznie i to nie jest żaden rocket science, żeby sobie taką automatyzację zrobić. A wiadomo, jak już mamy, jak raz ją zrobimy, to potem możemy przypuszczać każdy CI, do którego się włamiemy. Więc cyberprzestępcy też budują sobie własne infrastruktury do badania, do wyciągania rzeczy. To, tak jak powiedzieliśmy wcześniej, to jest biznes. Na tym się robi pieniądze. A jeżeli robi się na czymś pieniądze, to jak każdy biznes ma jakiś budżet na R&D. I oni też mają, oni też mają. Dobra, Krzychu, to co, na dzisiaj kończymy.
Krzysztof: Tak, kończymy. Dziękujemy bardzo, że jesteście z nami i zapraszamy na następny odcinek.
Andrzej: Zapraszamy na kolejny. Do zobaczenia.