Awaria CrowdStrike i Bezpieczeństwo EDR
W tym odcinku podcastu analizujemy głośną awarię CrowdStrike, która sparaliżowała globalne systemy IT. Wyjaśniamy, czym jest Falcon Sensor (system klasy EDR) i dlaczego działa w trybie jądra systemu operacyjnego, co sprawia, że błędy na tym poziomie mogą prowadzić do tzw. „niebieskiego ekranu śmierci” (BSOD) i pętli restartów. Omawiamy, dlaczego problem nie leżał w samym kodzie sensora, lecz w błędnej sygnaturze zagrożeń, która wywołała błąd w oprogramowaniu. Dyskutujemy, jak doszło do tego incydentu w procesie wytwórczym CrowdStrike, mimo zaawansowanych procedur QA.
Bezpieczeństwo Systemów Operacyjnych i Wycieki Sekretów
Odcinek porusza również szerszy kontekst bezpieczeństwa systemów operacyjnych, obalając mit o inherentnym bezpieczeństwie macOS i Linux w porównaniu do Windows. Przedstawiamy analogię domu Billa Gatesa i zwykłego mieszkania, aby pokazać, dlaczego Windows jest częstszym celem ataków, pomimo swoich zaawansowanych mechanizmów bezpieczeństwa. Wspominamy o historii Patch Guard w Windows Vista i roli Unii Europejskiej w zablokowaniu tego mechanizmu. Na koniec analizujemy drugi, powiązany incydent: znalezienie Personal Access Token GitHub w obrazie Dockerowym Python Foundation, co podkreśla problem wycieków sekretów w łańcuchu dostaw oprogramowania i potrzebę skanowania obrazów. Ten odcinek jest kluczowy dla inżynierów IT, specjalistów ds. cyberbezpieczeństwa oraz menedżerów, którzy chcą zrozumieć złożoność bezpieczeństwa EDR i zarządzania ryzykiem.
Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.
Transkrypcja
Andrzej: Dzień dobry.
Krzysztof: Dzisiaj mamy dwa tematy, więc schodzimy znowu z objętości po to, żebyście zachowali więcej czasu w wakacje, ale za to jakie tematy? Pewnie wszyscy słyszeliście o aferze z CrowdStrikem. Drugi troszeczkę mniej popularny, ale równie ciekawy, bo mógłby doprowadzić do podobnej sytuacji jak z CrowdStrikem. Andrzej powiedz co robiłeś tydzień temu w piątek rano.
Andrzej: Dobre pytanie. Akurat odpoczywałem, miałem, nie nazwałbym tego urlopem, ale miałem chwilę przerwy spowodowanej osobistymi sprawami, ale w piątek rano, jeśli mówimy konkretnie o poranku i o piątku, to biegłem życiówkę pięć kilometrów, udało się, dwadzieścia tam chyba pięć albo sześć minut. Jak ktoś mnie followuje na Strawie może popatrzeć. Ja wiem, że to nie jest jakiś exceptionally good time, ale dla mnie, ja zacząłem dopiero niedawno biegać i dalej tego nie do końca lubię, no to jest znaczna poprawa, więc akurat biegłem piątkę i zrobiłem PR. A o innych rzeczach dowiedziałem się już po fakcie.
Krzysztof: Czyli jak słyszycie, Andrzej nie był za to odpowiedzialny, bo szukają winnego. Internet szuka winnych. Andrzej ma, Andrzej ma alibi. Ja dowiedziałem się od mojej żony o tej, o tej całej akcji, bo powiedziała, że po prostu coś nie działa jej w pracy. Więc tak to było u mnie. No dobrze Andrzej, to wskakujemy. Myślę, że tutaj jeżeli chodzi o CrowdStrike, to zlidujesz ten temat, bo przygotowałeś się z tego co słyszałem, więc możesz powoli rozpocząć ten roast albo obronę.
Andrzej: Właśnie, tutaj będzie trochę roastu, trochę obrony, bo jak zwykle mam, nazwijmy to, Zawsze staram się stawiać w opozycji do tego, co ktoś mówi po to, żeby po prostu znaleźć drogę i ewentualne usprawiedliwienie i końcem końców dojść do jakiejś prawdy i do jakiegoś rozwiązania. Zarówno z jednej i z drugiej strony można znaleźć takie, nazwijmy to, argumenty obronne, a te argumenty obronne pomagają nam, jak powiedziałem wcześniej, dochodzić do, nazwijmy to, korzenia rzeczy, tak się ładnie mówi w filozofii, na angielsku po prostu root cause, i jesteśmy w stanie poprawiać różnego rodzaju procesy, czy to w organizacjach, czy w naszym własnym życiu. I tak było też tutaj, dlatego że sprawa z CrowdStrike’iem, a konkretnie z sensorem Falcon jest wielowymiarowa, jest wielowymiarowa. Oczywiście dla użytkownika końcowego ona jest jednowymiarowa, po prostu system się nie uruchamia, a jak się nie uruchamia system, nie uruchamia się komputer, no to nie mogę z niego skorzystać, a dla odbiorców końcowych tych systemów, czyli przykładowo klientów różnych instytucji, no oni nie mogą często gęsto realizować swoich procesów zakupowych, no bo nie jestem w stanie kupić, albo zrealizować tego zakupu, więc oczywiście dla odbiorcy czy dla pracownika sprawa jest jednowymiarowa, ale dla nas ludzi w IT i nie tylko bezpieczników, ale mówię tutaj ogólnie o ludziach, którzy są odpowiedzialni za tworzenie i utrzymywanie systemów IT, no sprawa ma tutaj więcej wymiarów niż niż jeden. Ale tutaj trochę się rozbiegłem i zacznijmy od tego, co w ogóle się wydarzyło. Tak jak powiedziałaś Krzysiek, mam tutaj, trochę się przygotowałem na tyle, że musiałem sobie pospisywać notatki, bo tutaj jest takie, jest sporo do opowiedzenia. Natomiast jeśli wystartujemy od początku, to czym jest Falcon Sensor? Czym jest Falcon Sensor z firmy CrowdStrike? Falcon Sensor to jest system klasy EDR, czyli Endpoint Detection and Recovery i takie systemy umożliwiają monitorowanie końcówek. Przez końcówki mam na myśli komputery używane przez użytkowników w dużych sieciach korporacyjnych, czyli nie serwery. ale przykładowo laptopa, którego dostajemy od organizacji. To jest taka końcówka. No i w jaki sposób IT, ale też slash bezpieczeństwo musi obserwować, co się na tych komputerach, co się na tych maszynach dzieje, po to oczywiście, żeby je bronić. No i żeby obserwować to, co się dzieje na takiej maszynie, no to systemy klasy EDR, to całe oprogramowanie, w tym właśnie Falcon Sensor, ale nie tylko Falcon Sensor. inni vendorzy, oprogramowanie innych vendorów oczywiście musi robić to samo, a mam tu na myśli, że musi działać w kontekście jądra systemu, czyli tak zwanym kernel mode, a nie user mode. I to jest bardzo ważne, dlatego że jeśli mamy aplikację, tutaj konkretnie jest to sterownik, i sterowniki zwyczajowo działają w trybie jądra. Muszą tak działać, bo muszą mieć dostęp do pewnej warstwy sprzętowej, do której zwykła aplikacja nie ma dostępu, bo właśnie system operacyjny jej zabrania. No ale właśnie biorąc pod uwagę, że takie aplikacje działają na poziomie jądra systemu, to jakikolwiek błąd, jakikolwiek błąd programistyczny, który się wydarzy na tym poziomie, często gęsto prowadzi do wywrócenia całego systemu operacyjnego. System operacyjny nie jest w stanie sobie poradzić z błędem na tym poziomie. Co innego, co innego oczywiście następuje, jeśli mamy aplikację w trybie użytkownika, user mode, czyli ring 3, ring 3. Przykładowo przeglądarka. Jeśli przeglądarka nam się wywali, to oczywiście nie jesteśmy zadowoleni, bo możemy stracić nawet zakładki, ale sam system operacyjny się tym za bardzo nie przejmie. System operacyjny dalej będzie działał. ale jeśli mamy właśnie kawałek oprogramowania, które siedzi trochę niżej, siedzi na poziomie systemu operacyjnego, no to każdy błąd często gęsto właśnie prowadzi do wywrotki całego systemu operacyjnego. I właśnie takie coś tutaj miało miejsce, chociaż nie do końca.
Krzysztof: Czyli podsumowując Andrzej, żeby to naszych słuchaczy było jasne, bo wiem, że też w rozmowie z osobami, które usłyszały o tym incydencie, nie było do końca zrozumiałe, dlaczego nie wywróciła się po prostu tylko aplikacja. a wywrócił się cały system. Dlaczego wyświetlił się ten niebieski ekran śmierci? Chodzi o tryb, w jakim działa sensor od Falcona.
Andrzej: Dokładnie. I to nie jest, to nie jest tutaj coś, co jest natywne tylko dla sensorów Ad Falcona. Generalnie tego typu oprogramowanie od każdego vendora będzie musiało działać w trybie jądra i jakikolwiek błąd u wszystkich tych vendorów najprawdopodobniej w większości przypadków prowadziłby do tego samego, czyli do niebieskiego ekranu śmierci, blue screen of death. I dokładnie dlatego tak się działo, bo aplikacja działa na poziomie systemu operacyjnego. Ale tutaj jest jeszcze jeden dość ważny szczegół, bo jeśli byłoby tylko tak, że ten sterownik działałby na poziomie systemu operacyjnego, no to technicznie moglibyśmy zrestartować komputer i dopóki ten sterownik by się nie załadował, no to nie byłoby problemu i moglibyśmy nawet próbować go wyłączyć. W taki bardzo manualny sposób, ale szybko próbując ubić ten proces. Nazwijmy to Race Condition. Natomiast tutaj było to nie do końca wykonalne, dlatego że tego typu oprogramowanie, EDR, antywirusy, one korzystają z czegoś takiego jak Early Launch Anti Malware i one muszą się ładować. Te kawałki oprogramowania muszą się ładować jeszcze przed załadowaniem wszystkich innych sterowników, oczywiście poza tymi Microsoftowymi, ale jeśli mamy jakiekolwiek inne sterowniki, które się ładują, przykładowo wgraliśmy sobie sterownik do karty muzycznej, nie wiem czy w chwili obecnej się takie coś robi, ale kiedyś się robiło, to taki sterownik wystartowałby później. Natomiast ten kawałek odpowiedzialny za bezpieczeństwo wystartowałby zaraz po tych wszystkich sterownikach od samego Microsoftu, czyli najpierw zbudowałby się Microsoft i te kawałki Microsoftowe, następnie uruchomiłoby się ten kawałek odpowiedzialny za bezpieczeństwo, w tym przypadku Falcon Sensor, a dopiero potem załadowałby się inne sterowniki. No oczywiście pewnie widzisz dlaczego, no bo jeśli mielibyśmy przypadek, w którym na komputerze mielibyśmy rootkita, który też najczęściej jest to sterownik, no to musimy go w jakiś sposób zauważyć. A jeśli musimy go zauważyć, no to musimy mieć jakiś sposób, żeby to co obserwuje wystartowało przed załadowaniem tego rootkita. Oczywiście mocno upraszczam, bo nic nie stoi na przeszkodzie, żeby rootkit był tak zaawansowany i eksploitował jakieś podatności, że nie dałoby się go zauważyć. Takim może dość głośnym przypadkiem był Stuxnet. I nie chodzi mi tutaj konkretnie o sam rootkit, ale o to, o poziom zaawansowania, czyli nie jest tak, że nie dałoby się tego zrobić, ale to jest gra prawdopodobieństwa. I jeśli korzysta, jeśli Falcon Sensor korzysta z tego mechanizmu early launch anti-malware, no to z dużym prawdopodobieństwem wykryje jakiekolwiek zagrożenia, które załadują się później. i o to chodzi. Bo w bezpieczeństwie nigdy nie jesteśmy w 100% bezpieczni, możemy tylko dążyć do tego, żeby być w większości przypadków bezpiecznymi. Ale ten kluczowy fakt, że ten sensor ładował się w trakcie bootowania, doprowadził do tego, że po zrestartowaniu niejako komputer wpadał w taką pętlę śmierci, no bo próbował się zrestartować, próbował się zbootować po restarcie, ładował Falcon Sensor, w Falcon Sensorze następował błąd, I następnie system znowu się restartował, bo miał blue screen of death. I tak w kółko, i tak w kółko, i tak w kółko. Z tego co słyszałem i czytałem na Twitterach czy na Reddicie, można próbować ingerować w ten proces budowania, można nawet próbować restartować po kilka, kilkanaście razy z nadzieją, że Falcon Sensor pobierze nową aktualizację, już nie błędny plik po aktualizacji tej feralnej, ale już z poprawkami od CrowdStrika i system się w końcu uruchomi. Ale to jest taka trochę gra szczęścia, trochę prawdopodobieństwa. Może nam się udać za piętnastym razem, a może będziemy musieli restartować pięćdziesiąt razy. No i teraz pytanie, czy się nam chce restartować ten komputer pięćdziesiąt czy jeszcze więcej ile razy, ale ponoć ludziom się udawało taki sposób wyprowadzenia tego problemu. I teraz, Czysiak, czy na chwilę obecną masz jakiś komentarz albo pytania? Bo ja, to takie duże pytanie, które mi się od razu w głowie zapaliło, w ogóle jak pierwszy raz usłyszałem o tej sprawie, bo na razie to jest tylko wstęp, dlaczego ten błąd mógł się wydarzyć? Ale pierwsze moje pytanie, które wpadło mi do głowy, to jak to się stało? Ale nie jak to się stało na poziomie systemu czy końcówki, tylko jak się stało na poziomie procesu wytwórczego w firmie CrowdStrike, że takie coś, w ogóle było możliwe.
Krzysztof: Dokładnie tak, bo to jest pytanie, które rodzi się chyba każdemu. W jaki sposób w firmie pokroju CrowdStrika nie zostało to zauważone w procesie testowania, w procesie QA, w procesie ciągłej integracji, gdzie to nie jest błąd, który występował w bardzo specyficznych warunkach, na bardzo specyficznych maszynach, tylko występował dla całej rodziny systemów Windowsowych, więc to nie jest tak, że to mogło przejść niezauważone, bo to był jakiś edge case, który spowodował, że na jednym z światowych lotnisk po prostu przestały działać maszyny, które pracują pod danym systemem operacyjnym.
Andrzej: Dokładnie tak. Dokładnie to mi się urodziło, od razu patrząc na tą sprawę, takie pytanie. No i mam swoją jakąś, znaczy od razu sobie wyrobiłem jakąś hipotezę, która potem przynajmniej przez to, co twierdzi Krauss-Reich w swoim incident response raporcie, Krzysiek, masz go pod ręką, to możesz tam zaraz zjechać do początku, tam jest wstęp i opisuje najpierw sam kawałek Falcon Sensory jako programowanie, a potem opisuje system templatek. I ja miałem dość podobną hipotezę, że raczej to nie było przez sam kawałek oprogramowania, bo to kurcze nie ma opcji, żeby CloudStrike nie miał procesu QA. Musi mieć proces QA dla oprogramowania, czyli coś innego musiało się wydarzyć. Po tym całym opisie od CrowdStrika ta hipoteza raz, że się umocniła, a dwa, gdzieś tam rozjaśniła, czemu tak wyszło. I nie wiem, czy widziałeś albo doszedłeś do tego, bo na przykład mogłeś czytać, ale czy doszedłeś do tego, co tam końcem końców poszło. nie tak, czy nie?
Krzysztof: Szczerze powiedziawszy, w tym całym szumie informacji już na samym końcu ostatnimi dniach czytałem tylko nagłówki, także nie doszedłem.
Andrzej: Okej, to ja przeczytałem więcej różnych zasobów, no bo to pytanie, ale jak to się stało właśnie w procesie wytwórczym, no jest dla mnie dość ważne, bo tak naprawdę tylko w ten sposób analizując, co poszło nie tak, można potem w przyszłości poprawić proces tak, żeby było okej. I w tym konkretnym przypadku okazuje się, przynajmniej według tych informacji, które są dostępne oficjalnie w internecie, okazuje się, że problem nie był, może i był, zależy jak na to popatrzeć, ale problem nie był w samym kodzie falconsensora. A przynajmniej to nie była bezpośrednia przyczyna tego, że po tej konkretnej aktualizacji system się zaczął wywracać i nie potrafił stać na nogi. Bezpośrednią przyczyną tego, że system zaczął się wywracać był plik. Który plik z sygnaturami, templatka, natomiast to nie był kod, to był plik, który Falcon Sensor czyta i na podstawie tego pliku wykonuje jakieś akcje. Po prostu baza wirusów została zaktualizowana, tak w dużym uproszczeniu.
Krzysztof: Mówiąc w dużym uproszczeniu, plik z sygnaturami, bodajże oni to nazywają jako Channel Update, czy coś w ten design. Tak, to mi się obiło faktycznie o uszy. I co więcej, obiło mi się o uszy w jednym wątku na reddicie, gdzie zostało pytanie, Jak to jest w ogóle możliwe, skoro przecież Falcon sensor, Falcon CrowdStrike udostępnia w ogóle politykę tego w jaki sposób możesz podchodzić do update’ów i zawsze możesz być minus jeden albo minus dwa za najnowszą wersją. No i właśnie to co mówisz Andrzej, problem nie leżał w samym sensorze, problem leżał w tych update’ach i tego się nie dało ustawić, bo to jest zaciągane kilka, kilkanaście razy w ciągu, w ciągu dnia.
Andrzej: Dokładnie, dokładnie tak. A czemu jest zaciągane kilka, kilkanaście razy w ciągu dnia? Dlatego, że architektura tego rozwiązania działa w ten sposób, że jeśli chcemy bronić te końcówki i to wychodzi z samego EDR-a, to musimy być w stanie reagować bardzo szybko, bo zagrożenia w sieci są dynamiczne, można powiedzieć, sprawa wygląda dynamicznie. Więc musimy mieć jakiś sposób na bardzo szybką aktualizację tej bazy zagrożeń, żeby ten EDR był skuteczny. żebyśmy po prostu byli skuteczni. I tam nie ma za bardzo czasu na to, żeby pozwalać, właśnie żeby pozwalać administratorom na mówienie, a dobra, to ja nie chcę najnowszej wersji, to ja na przykład chcę być n-1 albo n-3. Bo my tutaj znowu nie mówimy o oprogramowaniu Falcon Sensor. Mówimy o templatce, o znowu w cudzysłowiu bazie wirusów, bazie zagrożeń, z której Falcon Sensor korzysta. I ta baza, to jest aktualizowane kilka razy na dzień. I to jest tak naprawdę tutaj cały kruczek problemu, bo to oczywiście znowu zależy jak na to popatrzymy. Jeśli popatrzę takim programistycznym okiem, to problemem było jednak to, że Falcon Sensor czytając niepoprawny plik, czyli przyjmując dane na wejściu, się wywracał. Tam ze stack traces, z tego co widziałem, to wyglądało jak null pointer dereference, czyli po prostu odniesienie się do jakiegoś kawałka pamięci, który nie istnieje, a można było to zobaczyć dlatego, że mieliśmy 0x000000 i tam 9c, no i te 9c to wyglądało po prostu jak offset w tablicy, co myślę, że każdy programista CC++ będzie kojarzył. Tutaj miałeś pytanie?
Krzysztof: No właśnie, bo ja chyba wiem nawet o którym twicie mówisz. Był tweet, który tłumaczył właśnie z tym nullpointerem, ale on został zdementowany. Jakoby wcale to nie było przyczyną tego. Społeczność tam wyjaśniła. Przynajmniej próbowała wyjaśnić.
Andrzej: On został zdementowany, dlatego że CrowdStrike końcem końców w swoim technicznym raporcie udostępnił, że nie, nie, nie, to nie chodziło o plik, to chodziło o pajpy i dlatego się wywróciło. Natomiast na koniec dnia, czy ja będę czytał plik, czy ja będę czytał pajp, czy ja będę czytał cokolwiek, no na pewno możemy się zgodzić z tym, że na koniec dnia, a to widać na stacktrace, była nieodpowiednia dereferencja pamięci, która po prostu nie istniała. I to spowodowało wywrócenie aplikacji. A skoro ta dereferencja nastąpiła po aktualizacji plików, który posiada sygnatury zagrożeń i który był czytany przez Falcon Sensora, no to możemy mniemać z dużym prawdopodobieństwem, że po prostu aplikacja robiła pewne założenia czytając ten plik, I końcem końców te założenia nie były spełnione, czyli błąd, który bardzo często występuje w aplikacjach CC++, gdzie mamy problem związany z Memory Corruption. Więc możemy to ująć szerzej i po prostu powiedzieć, że to był Memory Corruption, a nie konkretnie Null Pointer Dereference i nie ma to tak naprawdę większego znaczenia, co było tam w samym kodzie. i pewnie tego tutaj nie poznamy, ale to co ma znaczenie to to, że po update’cie tej templatki aplikacja zaczęła czytać ten plik i najwidoczniej plik posiadał złe dane, których aplikacja nie potrafiła obsłużyć. I przez to się wywracała. Gdyby aplikacja była napisana w bezpieczny sposób, to potrafiłaby obsłużyć jakiekolwiek wejście. W zasadzie to jest definicja bezpieczeństwa. Jeśli aplikacja przyjmuje dane wejściowe, to jest bezpieczna, jeśli potrafi zinterpretować dowolne dane wejściowe. Oczywiście to jest w takiej teorii, bo w praktyce bardzo trudno jest przyjmować dowolne dane wejściowe i być bezpiecznym. że nie zależy nam na użyteczności aplikacji, no to wtedy jest bezpiecznie, ale znowu aplikacja nie będzie robić nic ciekawego. Więc tutaj ten fakt jest dość ważny, że to nie chodzi o to, że aktualizacja Falcon Sensora Poszła, bo ona wcale nie poszła. Poszła aktualizacja sygnatury, a następnie Falcon Sensor posiadający już ten bug, czyli zauważmy to, że akurat to ryzyko zmaterializowało się w piątek w zeszłym tygodniu, ale to ryzyko i tak zmaterializowałoby się prędzej czy później. z dużym prawdopodobieństwem. Czemu? Dlatego, że ten błąd po prostu był w Falcon Sensorze. Był, był pewien stan aplikacji, który był osiągalny przez pewne wejście, przez konkretny plik wejściowy, który, nieważne czy w zeszły piątek, czy dzisiaj, czy za dwa miesiące, jeśli taki plik wejściowy by się pojawił, to aplikacja osiągnęłaby ten stan i nie potrafiłaby z niego wyjść i przez to skraszowałaby cały system, więc z jednej strony można popatrzeć na to, że ten błąd był konkretnie w Falcon Sensorze, no bo był, bo to on nie potrafił obsłużyć tego pliku, ale z drugiej strony, czyli to jest pośredni problem, ale bezpośrednio to, co spowodowało konkretnie te krasze w zeszły piątek, To nie był sam Falcon Sensor, ale była aktualizacja, znowu w cudzysłowach baz wirusów, pozdro dla kumatych, która spowodowała wystąpienie tego błędu, materializację tego błędu, który mógł w tym oprogramowaniu być długo, dużo, dużo, dużo dłużej. On tam mógł siedzieć lata. a po prostu zmaterializował się teraz, bo teraz wyszła taka, a nie inna tęplantka, która miała takie, a nie inne pole, które po zinterpretowaniu przez aplikację spowodowało wywrócenie się aplikacji. Widzę, że masz pytanie.
Krzysztof: Tak, mam pytanie, Andrzej. To powiedz w takim razie dla takiego niskopoziomowego laika, jakim ja jestem, gdzie rozumiem bardziej wysokopoziomowe koncepty niż faktycznie cokolwiek w tym robiłem. Czy Falcon Sensor nie był fazowany?
Andrzej: To jest świetne pytanie.
Krzysztof: Bo jeżeli mówisz, że przyjmuje input w postaci bazy tego pliku, który zawiera znane zagrożenia, sygnatury, jest ładowany do sensora, no to aż mi się ciśnie na język, żeby powiedzieć o phasingu.
Andrzej: Masz rację. Nie wiem, ale się domyślam, zakładam, że nie był fazowany, dlatego że tego typu błędy wychodzą dość szybko podczas fazowania. I jak najbardziej da się fazować aplikacje, nieważne czy one są w user mode, czy one są w kernel mode, da się to robić. I jeśli mamy tak prosty schemat aplikacji, że aplikacja po prostu szczytuje jakiś plik, to najprostsze wydanie fuzzingu, czyli no niejako analizy dynamicznej, pozwala na znajdowanie takich błędów, no bo po prostu bierzemy wejście, mutujemy je w jakiś sposób, czyli na przykład losowo podmieniamy 256 bajtów w danym pliku, a potem próbujemy go szczytać przez Falcon Sensora i obserwujemy Falcon Sensora pod debagerem. Jeśli wystąpi jakiś problem to zapisujemy sobie taki crash, a jeśli nie wystąpi to przechodzimy do kolejnego i do kolejnej iteracji w takiej pętli. Czyli tak naprawdę bardzo prosta pętla, podobna do web aplikacji, gdzie wysyłamy dane do web aplikacji i obserwujemy czy dostaliśmy 500 czy nie. Jeśli dostaliśmy to zapisujemy, jeśli nie to przechodzimy do kolejnego case’u, więc logicznie bardzo podobne case’y. i wracając do odpowiedzi, nie wiem, ale się domyślam, czy był fuzzowany, no najprawdopodobniej nie, bo takie coś wyszłoby dość szybko podczas fuzzingu, ale tutaj na obronę CrowdStrika powiem, że po pierwsze nie byłoby to łatwe do implementacji na poziomie Kernela, da się, ale byłoby to trudniejsze, to raz. Chociaż można byłoby cały ten mechanizm parsowania wyciągnąć, z tego kawałka kernelowego i po prostu wpasować w user mode. Dokładnie. Jak najbardziej dałoby się to zrobić. Nawet można byłoby wyciągnąć cały, mieć osobną bibliotekę odpowiedzialną za parsowanie i w Falconie dołączać ją pod kernel mode. a podczas fazowania dołączać tą samą bibliotekę, ale w user mode, żeby nam łatwiej było fazować. Czyli dałoby się to zrobić, ale zakładam, że nie było to zrobione, bo gdyby było to zrobione, to na pewno coś takiego zostałoby dość szybko wyłapane. Tym bardziej, że w chwili obecnej istnieją całe kawałki oprogramowania, które mocno ułatwiają fuzzing od dużych firm, między innymi takie jak Google. i te firmy fuzzują i swoje oprogramowanie i oprogramowanie open source w dużej, naprawdę w dużej skali i fuzzing jest skutecznym skuteczną praktyką do eliminacji bagów i oczywiście bagów, które mają implikacje związane z bezpieczeństwem, czyli podatności. Więc tak, sądzę, że nie było tutaj fuzzingu, ale jeszcze wrócę do tego, Czemu nie do końca można wieszać psy, znaczy można wszystko, ale co działa na usprawiedliwienie krautstrajka, przynajmniej jeśli mówimy o tym procesie wytwórczym. Na pewno na usprawiedliwienie krautstrajka działa to, faktycznie inny będzie mieć proces QA dla kawałka oprogramowania, Falcon Sensor, a inny będzie mieć proces QA dla templatki, która jest tylko zasileniem Intelligence Feed dla naszego kodu. No bo w jednym przypadku obcujemy z kodem, więc mamy pewne procesy i tam być może fuzzing jest nawet w jakimś uproszczeniu, nie wiem. Natomiast w tym drugim procesie nie będzie żadnego fuzzingu, Zresztą w ogóle myślę, że jest bardzo lekki i tam za bardzo nic nie będzie, tylko po prostu jeśli ta platka się zgadza, to pushujemy ją do, do klientów i tyle. Z tego co czytałem w tym, w tym raporcie z CrowdStrika, nie jest to do końca w ten sposób robione, że pushujemy YOLO, YOLOSEC, push, push do wszystkich klientów i spadamy na obiad, chłopaki.
Krzysztof: Push, push z Forcem piątek i idź na wakacje.
Andrzej: Dokładnie. Nie do końca tak to jest, więc oni tam mają Early Adopters ETC, natomiast najwidoczniej takie coś w tym całym procesie się nie spisało. Jestem pewien, że CrowdStrike poprawi swoje procesy wewnętrzne, bo to chodzi o proces. Natomiast to, co ja też chciałbym tutaj uwypuklić, to I to nie jest tak, że tutaj CrowdStrike jest tutaj tym bad guy, tym złym, złą stroną. Oczywiście fajnie by było, gdyby oprogramowanie nie posiadało błędów, ale każde aplikacja, każdy kawałek softuł posiada błędy. I jeśli działamy na tym poziomie, czyli poziomie kernel mode, na poziomie jądra systemu operacyjnego, a musimy tutaj działać, to te błędy po prostu będą się zdarzać i powinniśmy się do tego niejako jako organizacja przygotować i mieć to w naszej analizie ryzyka. Nie możemy sobie założyć, że takie coś się nie wydarzy. Oczywiście, że się wydarzy. Tu się wydarzyło raz i w analizie ryzyka powinniśmy mieć, że takie coś może się wydarzyć. Oczywiście prawdopodobieństwo nie jest duże i jak tutaj widać, to się nie dzieje co tydzień, to się nie dzieje co miesiąc, to się nie dzieje co rok. To się dzieje rzadko, ale się dzieje i jak najbardziej ma prawo wystąpić. Więc też ja tutaj nie jestem po takiej stronie, że należy teraz wieszać psy na CrowdStrike, bo to mogło się wydarzyć każdemu. No, a akurat wydarzyło się crowdstrike.
Krzysztof: Wiesz co Andrzej, aż mi się przypomina historia, kiedy spłonęła część infrastruktury OVH i ludzie na Twitterze jeszcze wtedy, czy już wtedy na Excel nie pamiętam, pisali, co mam zrobić, co mam zrobić, a OVH odpisywało, proszę uruchomić swoje procedury związane z disaster recovery. No właśnie to mieliśmy teraz przykład również i w piątek, że świat pokazał, że nie jest gotowy na tego typu incydenty. i czytałem też jeden fajny tweet, w którym, już nie pamiętam kto, mniejsza z tym, ale stwierdził, wszyscy rozmawiają o resilience, o budowaniu odporności, a tak naprawdę wszyscy pokazali, że nie są resilience.
Andrzej: Dokładnie tak. Jest dużo rozmów o bezpieczeństwie, o anti-fragility, co jest czymś innym niż being resilient. A jak potem dzieje się coś takiego, to okazuje się, że nie do końca są resilient, bo nie działa. I w dużej części naprawdę spowodowało to przełączenie na zupełnie inne procesy biznesowe. Przykładowo, jak popatrzymy na kogo problem dotknął, to dotknął duże instytucje finansowe czy ubezpieczeniowe. Znaczy generalnie i tak dotknął większych graczy, większej organizacji. Czemu? CrowdStrike nie jest rozwiązaniem, które kupuje sobie ktoś do małej firmy, to jest poważny biznes, oni tam się nawet w jakieś takie małe zamówienia to by nie bawili, bo dla nich większym kosztem byłoby przeprocesowanie twojego zakupu niż to, co na tym zarobią, więc oni sprzedają do dużych podmiotów. Przykładowo u nas w Polsce słyszeliśmy, że dotknęło to lotniska Chopina, czy podotykało to kilku banków, czyli typowych miejsc, gdzie można byłoby oczekiwać, że Falcon Sensor będzie, albo będzie coś podobnego do Falcon Sensora, no i tutaj konkretnie był Falcon Sensor, więc ryzyko się zmaterializowało. Jest jeszcze kilka wątków, które chciałbym poruszyć. Jeden z nich na szybko. Jeden z nich to wątek macOSa i innych systemów operacyjnych. Ten wątek chcę poruszyć dlatego, że widziałem kilka komentarzy, w zasadzie nawet nie kilka, bardzo dużo komentarzy i w polskim internecie i w zagranicznym internecie mówiących, stawiających tezę, macOS-a by to nie dotknęło, albo Linux-a by to nie dotknęło. Oczywiście, że może to dotknąć i macOS-a i Linux-a i w zasadzie każdego systemu operacyjnego. Jeśli mówimy o kawałku oprogramowania, które działa na poziomie system jądra, to jakikolwiek błąd w tym kawałku oprogramowania spowoduje wywrotkę systemu w większości przypadków. I oczywiście macOS ma pewne rozwiązanie, które stara się przed tym ratować, nie pozwala od tak ładować rozszerzeń jądra do jądra, bodajże od tej wersji albo jeszcze poprzedniej, czyli wyłączyli taką możliwość. Ale to nie jest tak, że nie da się jej włączyć, jak najbardziej da się ją włączyć i są kawałki oprogramowania przydatne, przydatne aplikacje, które jeśli chcemy zainstalować, to musimy wyłączyć ten system protection po to, żeby zainstalować sterownik i wtedy jak najbardziej mamy sterowniki w wiądrze obce i one mogą spowodować tego typu problem. Więc jak najbardziej może problem dotknąć macOS-a, po prostu w mniejszej ilości przypadków. Linux-a też, do Linux-a zaraz wrócę, natomiast o macOS do nami jeszcze jedną rzecz. Bo często gęsto, albo inaczej, ta analogia macOSa Windowsa wychodzi stąd, że jak ktoś używa macOSa, no bo macOS jest bezpieczniejszy. Z jednej strony tak, z drugiej nie. iOS na pewno jest bezpieczniejszy, to być może jest najbezpieczniejszy system operacyjny jaki istnieje, ale też jest dość zamknięty. Natomiast czy macOS jest bezpieczniejszy niż Windows? Nie. Windows przez ostatnich 20 lat naprawdę pod kątem bezpieczeństwa jest topowym systemem operacyjnym, a jeśli mówimy o desktopy to jest najbezpieczniejszy. Ma tyle mechanizmów, które pozwalają na walkę z oprogramowaniem złośliwym, z eksploitami, że żaden system operacyjny oprócz może iOS-a nie posiada. i Androida na chwilę obecną nie posiada tego typu mechanizmów, natomiast Windows jest też najbardziej najszerzej używanym systemem operacyjnym na świecie, więc to nie jest tak, że macOS jest bezpieczny, tylko po prostu nikt nie atakuje macOS-a, bo Cyberprzestępczość to jest biznes, na którym się dbi pieniądze i nikomu się nie opłaca atakować pięciu czy dwóch procent użytkowników komputerów, bo lepiej zaatakować te 95 procent, które leci na Windowsie. Dokładnie, czysty biznesowy pragmatyzm, gdzie to tak samo, nawet sobie taką analogię na szybko stworzyłem, że to tak jakbyśmy mówili, że moje mieszkanie, mój dom jest bezpieczniejszy niż dom Billa Gatesa. No jest bezpieczniejsze, dlatego że mało osób będzie się próbowało włamać do mojego mieszkania, bo za bardzo nic tam nie mam. Nawet telewizora nie mam. A do Bill Gatesa więcej osób może się o to pokusić, więc moje mieszkanie nie jest bezpieczniejsze dlatego, że ja mam więcej mechanizmów bezpieczeństwa, tylko dlatego, że jest mniej interesujące. Bo na kartce i na schemacie technicznym to dom Billa Gates’a na pewno jest bezpieczniejszy niż mój. Tylko że po prostu nikt nie będzie albo mała ilość będzie chciała atakować mój dom, bo po prostu nic tutaj nie mam. I ta analogia jest trafna, bo dokładnie tak samo jest z Windowsem. Windows jest bezpieczniejszy na papierze pod kątem feature’u związanych z ubezpieczeństwem. No ale co z tego, jeśli po prostu jest głównym targetem cyberprzestępców, którzy robią na tym miliardy dolarów rocznie. No to nie ma znaczenia, czy jesteś bezpieczniejszy, bo i tak każdy będzie ciebie chciał atakować. To raz, a dwa oczywiście pewna fragmentacja systemu, ekosystemu całego, gdzie Windows musi obsługiwać miliardy, no może nie miliardy, ale miliony różnych urządzeń, a macOS tak naprawdę jest zamkniętą architekturą i na poziomie OS-a, i na poziomie, i na poziomie software’u, i na poziomie hardware’u, więc tak naprawdę mają dużo większą kontrolę nad tym, co, co może się dziać w systemie, dlatego że mają też dużo większą kontrolę nad urządzeniami, które są na poziomie hardware’u. Więc nie muszą po prostu, nie muszą robić dużej ilości założeń, bo oni wiedzą, co będzie w komputerze i wiedzą, że nie będzie nic innego, nie? Więc to raz. Natomiast powiedziałem, że wrócę jeszcze do Linuxa, bo tutaj też, o Linux, Linux bezpieczniejszy. Chciałbym punktować. I tutaj zabawna sprawa. Chciałbym wypunktować, że niedawno, bo kilka tygodni temu, w RedHacie był dokładnie, może nie dokładnie ten sam błąd, ale błąd spowodowany dokładnie przez ten sam kawałek oprogramowania, czyli przez Falcon Sensora. Krzysiek, tam podesłałem Ci linka, nie wiem czy go wyświetlasz, ale… Na RedHata, tak. Tak, dokładnie. Jest od RedHata. wpis w Knowledge Base, że Falcon Sensor crashuje i co należy zrobić w takim przypadku. Więc czy sam system tutaj pod kątem, jeśli mówimy o Linuxie, jest bezpieczniejszy? No nie. I to mamy jasno, czarno na białym pokazane, że nie jest. bezpieczniejsze jeśli mówimy o oprogramowaniu, które ma dostęp do jądra systemu.
Krzysztof: Żaden system operacyjny nie będzie bezpieczny. Też bodajże wyszło, że dwa albo trzy miesiące temu podobny przypadek był dla Debiana i dla Rocky Linuxa, które działały gdzieś tam, będąc zabezpieczone właśnie przez Falcon Sensor. Tylko nikt o tym nie mówił, bo skala była zupełnie inna.
Andrzej: Dokładnie tak. I oczywiście też procesy, recovery, rozwiązywania tych problemów są zupełnie inne na poziomie dużych organizacji, bo jeśli zacznie się crushować jakiś serwer, no to kto będzie za to odpowiedzialny? Będzie odpowiedzialny za to administrator, osoba, która zna się na rzeczy. Mamy backupy, mamy multum narzędzi, które pozwalają nam na szybkie wyprowadzenie tego problemu. Natomiast tutaj nie mamy. tutaj nie mamy, w dużej mierze będzie trzeba robić pewne rzeczy manualnie i dlatego jest to tak głośny i tak duży problem związany właśnie tutaj z Windowsem, a nie dlatego, że to jest natywne dla Windowsa, raczej chodzi o to, kto używa tego Windowsa, a kto używa Linuxa i gdzie używa się Linuxa, a gdzie używa się Windowsa, to o to tutaj chodzi. a nie o samą wojnę pomiędzy, który system operacyjny jest lepszy albo bezpieczniejszy. System operacyjny to tylko narzędzie, komputer to tylko narzędzie. Korzystajmy z tych narzędzi, które pozwalają nam na realizowanie naszej pracy, a nie przejmujmy się tak mocno o tym, czy to jest Windows, czy to jest Linux, czy to jest macOS, bo na koniec dnia to po prostu nie ma znaczenia. Jeśli pozwala mi zrealizować to, co chcę zrealizować narzędzie, to jest dobre, a jeśli nie, to nie jest dobre. Tak jakbym mówił, który młotek jest lepszy. Jak mam wbić gwoździa, to większość młotków się nada. I tak samo tutaj. Natomiast na zakończenie chciałbym donać jeszcze jeden komentarz, jeszcze jeden smaczek. Mianowicie, Tutaj już reasumując całość, pojawiło się wiele głosów związanych właśnie z tym Windowsem, że dlaczego Windows pozwala na takie coś. I tak jak wspomniałem macOS ma pewne mechanizmy, które domyślnie nie pozwoliłyby działać w zewnętrznej apce na poziomie jądra systemu. Musimy wyłączyć ten mechanizm. I teraz. Okazuje się, że Microsoft też chciał taki mechanizm wprowadzić i to już wprowadzając na rynek system Windows Vista, więc dla osób, które nie kojarzą, to były lata 2000-2010, a konkretnie, o ile dobrze pamiętam, około Siódmego.
Krzysztof: Szóstego.
Andrzej: Tak, szósty, siódmy. Więc Microsoft chciał wprowadzić rozwiązanie tego problemu i ten mechanizm się nazywał Patch Guard, czyli chciał zabronić zewnętrznym vendorom na ładowanie sterowników do jądra systemu. Chciał zrobić jakieś rozwiązanie pośrednie, które np. w macOSie w chwili obecnej jest zaimplementowane. Ale co się stało? Stało się to, że firmy antywirusowe, przodownicy pracy na tamten moment, to był Symantec i McAfee, stwierdzili, że nie, nie, nie, nie, nie, tutaj chcesz nam ukrócić biznes, a my tutaj robimy dobre pieniążki, poszli się poskarżyć do Komisji Unii Europejskiej. Powiedzieli, że o, tutaj oni chcą nam zabronić, to jest monopoly i w ogóle utną nam revenue, więc zróbcie coś z tym. A że Unia Europejska może nie jest skuteczna w innowacji albo w technologii, ale za to jest skuteczna w regulowaniu wszystkiego. Pozdro dla kumatych. No i tutaj też była skuteczna i zabroniła Microsoftowi zrobienie, implementację tego rozwiązania PatchGuard. na poziomie systemu operacyjnego i Microsoft po prostu od niego odstąpił. Czyli Microsoft chciał wprowadzić rozwiązanie, które nie dopuściłoby do tego, co mieliśmy w zeszły piątek, ale tym blokerem Okazała się Unia Europejska, więc znowu nie wieszajmy tak mocno psów na Microsoftcie w całym tym kejsie, bo nie on tutaj jest problemem. Microsoft wykonał naprawdę kawał świetnej roboty przez ostatnie 20 lat pod kątem bezpieczeństwa, w zasadzie byli innowatorami. To oni pierwsi implementowali procesy związane z Bezpiecznym Wytwórcą Programowania, SDL, Secure Development Lifecycle, on powstał w Microsoftcie. Różne praktyki takie jak fuzzing, jak modelowanie zagrożeń, jak analiza statyczna, jak wycinanie niebezpiecznych API na poziomie kompilatora, to wszystko wprowadza Microsoft. I wprowadzał to w latach 2003, 2004, 2005. To jest 20 lat temu. Więc Microsoft naprawdę zaczął dbać mocno o bezpieczeństwo. Oczywiście nie robi tego z dobroci serca tylko po to, żeby się z revenue zgadzało i żeby robić pieniądze, ale końcem końców to robi. I gdyby historia potoczyła się trochę inaczej, to może nie doszłoby do tego, do czego doszło w piątek. A to, do czego doszło w piątek, no końcem końców nie wynika bezpośrednio z winy tutaj Microsoftu, No tylko po prostu z vendora i tego jak rozwiązania klasy EDR działają. Reasum… Ups. Wow. Prawie strasznie mikrofon. Reasumując. Sytuacja dość duża. Czy jakoś super poważna? No na pewno ludzie w helpdeskach i w supportzie się niezbyt cieszą, bo naprawdę dołożyło im to dużo pracy. Na pewno spowodowało całościowo, globalnie pewne straty finansowe albo raczej niezrealizowane zyski. Coś stracić to coś musi być, a potem musi zniknąć. Niefajne, ale mam nadzieję, że nie tylko CrowdStrike, ale też inni vendorzy tego typu oprogramowania wyciągną wnioski i że materializacja tego typu ryzyka w przyszłości będzie miała jeszcze mniejsze prawdopodobieństwo niż miało to miejsce, no niestety, ale jeszcze dwa tygodnie temu.
Krzysztof: Dokładnie tak. Ja chciałem tylko dodać, Andrzej, że gdzieś obiło mi się o uszy, że jeżeli chodzi o ten driver, który ma działać w trybie jądra, to Microsoft udostępnia całą ścieżkę certyfikacyjną. To nie jest tak, że ty możesz sobie po prostu tak robić, tylko musisz przejść jakąś ścieżkę. Microsoft nadaje ci glejt na to, że możesz tak robić. Dlatego potem część ludzi ma jednak też, przynajmniej w ostatnich dniach, ma też jakiś taki uraz do Microsoftu, że w jaki sposób Wy to testujecie, w jaki sposób Wy testujecie tych vendorów, którzy ten Glade, ten patch dostają, że mogą to robić.
Andrzej: Rozumiem. Wiesz co, z tego co pamiętam, to oni jakoś super mocno tego nie testują. Nawet kiedyś, to było dawno, dawno temu, chyba rok 2008 albo 2009, znany polski badacz, a nie, chwilka, znana polska badaczka bezpieczeństwa Joanna Rutkowska, pozdro dla kumatych, Joanna nawet opisywała na blogu, wydaje mi się, że ten blog i ten wpis już nie jest dostępny, bo to było dawno, dawno temu na blogerze, ale opisywała to, w jaki sposób po prostu dostać taką certyfikację, tam wystarczyło po prostu zapłacić te 150 czy 200 dolarów i cyk. I to załatwia sprawę. Tak, tak. Dostajesz od nich certyfikat i możesz podpisywać swoje oprogramowanie ich certyfikatem i oczywiście już wtedy jest, wiesz, jest wszystko okej. Oczywiście ten mechanizm pewnie przeszedł jakiejś iteracji, więc w chwili obecnej prawdopodobnie wygląda to troszkę inaczej, ale czy dużo inaczej? Nie wiem, choć się domyślam.
Krzysztof: Dobrze, że przyszło nam o tym porozmawiać też kilka dni później, kiedy już powoli świat ochłonął po tej katastrofie.
Andrzej: Jeszcze właśnie, bo teraz zobaczyłem, co pojawiło się na ekranie. Tutaj dla wyjaśnienia, jeśli ktoś ogląda na YouTube, a jeśli nie, to zachęcamy i subskrypcja, dzwoneczek, ale jeśli ktoś ogląda na YouTubie, to będzie widział wizualizację lotów w Stanach Zjednoczonych przed całą sytuacją z crowdstrikiem i po całej sytuacji z crowdstrikiem. No i na tej wizualizacji widać, że Ruch powietrzny w US of A zmalał dość znacząco. Więc był ten impact na nazwijmy to taką infrastrukturę fizyczną, a nawet po prostu krytyczną, bo lotniska to część infrastruktury krytycznej. Był impact w dużej mierze w Stanach Zjednoczonych. Oczywiście poza tym, tak jak wspominałem, w Polsce też były większe lub mniejsze problemy. W Stanach chyba były największe, ale też chyba dlatego, że po prostu Stany, tam się dużo lata.
Krzysztof: Tak, u nas nawet minister cyfryzacji wspomniał, że Polska nie została jakoś tak super mocno dotknięta i że będzie dążył do dywersyfikacji źródeł oprogramowania i wspomniał coś o open source’ie, więc nie wiem co będzie lepsze, biorąc pod uwagę to, co się ostatnio dzieje w świecie open source’a, oczywiście nie wieszając psów na oprogramowaniu otwarto-śródłowym. Ale tam są problemy, które mogą być dużo, dużo, dużo gorsze niż to, co widzieliśmy w CrowdStrike’u.
Andrzej: Ale chwila, bo Krzysiek, tu przychodzę zrobić również taki segway i przychodzę do twojego case’u, no to on dotyczy trochę Open Source’a i twojego ulubionego tematu. Nie wiem, czy ulubionego, ale tematu, który jest na pewno jednym z twoich koników.
Krzysztof: Tak, słuchajcie. Firma, która zajmuje się pewnymi toolami związanymi z cyberbezpieczeństwem, m.in. JFrog Artifactory i skanerami, które dotykają naszego kodu. Ich dział bezpieczeństwa znalazł Personal Access Token od GitHuba. znalazł w obrazie dockerowym, który należał do fundacji Pythona. I ten token to był ten token z tego rodzaju klasycznych, czyli nie ten nowy token patowy, githubowy, który umożliwia ograniczenie pewnych dostępów do pewnych repozytoriów, tylko ten, który po prostu daje dostęp do wszystkich repozytorów, do których dostęp ma dany użytkownik. Więc nie był to byle jaki token, to był taki troszeczkę god mode, jeżeli chodzi o tokeny w GitHubie. I token został znaleziony w skompilowanym pliku Pythona w folderze PyCache, który omyłkowo w procesie budowania obrazu dockerowego po prostu został dołączony do tegoż obrazu. i został dołączony przez osobę, która tak naprawdę jest dosyć światłym programistą, bo jest to jeden z liderów projektu PyPI przez pana Darbina. Ja byłem świadomy tego, że nie powinienem tego tokenu dodawać do mojego kodu. A czemu on dodał w pierwszej kolejności do kodu ten token? bo odbijał się od tego, że w procesie anonimowego dostępu do GitHub-owego API łapał go rate limit i dewelopował jakiś tam projekt na potrzeby właśnie PyPI-a. i on sam stwierdza potem w takim blog postcie na blogu PyPI, że z czystego lenistwa dodałem ten token tylko na potrzeby chwili, żeby nie łapał mnie ten rate limit, zbudowałem obraz, usunąłem token z kodu źródłowego, wypuszczowałem to do repozytorium, ale obraz z tokenem był już w zdalnym rejestrze obrazów. Tak jak sam się przyznaję, było to jego czyste lenistwo. On doskonale wiedział, że tego typu sytuacja nie powinna się wydarzyć, bo w zasadzie przed zakomitowaniem tego tokenu już nie było, ale był po prostu w obrazie. On też tłumaczy się, że okej, my tam mieliśmy plik docker.ignore, czyli tak naprawdę ten cały folder pycache, on przeważnie w takich boilerplate’owych projektach pythonowych, on jest wykluczany. żeby nie był łapany, czy to przez Git’a, czy to właśnie przez Dockera. I on pokazuje, jak wyglądał jego Docker Ignore. Jego Docker Ignore wyglądał w taki sposób. Więc jak on tam w tym blogpostcie stwierdza, no tym razem nasz Docker Ignore, bardzo minimalny, po prostu nie wyłapał tego problemu. Badacze z J.J. Froga zgłosili to do PiPiA. i tutaj brawa dla PiPiA, bo PiPiA rozwiązał ten problem w 17 minut. 17 minut od zgłoszenia. Kiedy zgłoszono to token został unieważniony, przeprowadzono całą analizę, czy udało się to wykorzystać, no bo właśnie zastanówmy się co można by było, mając taki token do kilkudziesięciu repozytoriów związanych właśnie z fundacją, z fundacją Pythona, osiągnąć. Tutaj badacze JFroga wydaje mi się, że troszkę nad wyraz mówią, że można by było wprowadzić Bugdora, a może się mylę, bo nie chce mi się wierzyć, że mając ten token, a może tak to jest ustawione u nich po ich stronie, dałoby się bezpośrednio pisać np. do mastera. Wszystkie ustawienia związane z Branch Protection raczej zabraniają tego typu praktyk. Ale biorąc może pod uwagę to, że mieli token o tak szerokim zakresie też nie można wykluczyć, że taka sytuacja nie byłaby możliwa. To jest bardziej taka wodza fantazji puszczona przez researcherów z JFroga, no bo tam oni podają sytuacje, w których byłoby na przykład możliwe zaszycie pewnego backdoora w samym PyPI. który następnie do każdej paczki, która jest hostowana na PyPI dołączałby po prostu złośliwy kod, więc pomyślcie sobie ile projektów działa w oparciu o paczki związane z PyPI. Ja tutaj tylko rzucę to, że sam boom na ELM i generatywną sztuczną inteligencję spowodował z powodu po prostu to, że adopcja PyPI i Pythona wzrosła niesamowicie. Zresztą to jest i tak bardzo popularny ekosystem język i technologia. Więc oni pokazują tutaj, że jedna to jest kwestia tego, że moglibyśmy się wstrzelić gdzieś w PyPI i zbudować jakiegoś backdoora, a druga kwestia, że moglibyśmy się wstrzelić po prostu w samą jakąś podstawową funkcję związaną z z Pythonem np. w imporcie zaszyć słyszliwy kod, który po prostu potem przy każdym wywołaniu w naszym projekcie ładowałby coś, czego nie chcemy. Więc tak, a administrator PyPI Stwierdził, że ten obraz oczywiście został bardzo szybko usunięty. On nie będzie już, przynajmniej w ramach tego projektu, nie będzie przytrzymywany w zdalnym rejestrze na Docker Hubie. No i jak mówi, ma niemałą nauczkę od researcherów.
Andrzej: No tak, jakby pan Durbin dołączył do naszego szkolenia APCD w SecOps, to tam by się nauczył, jak wykrywać takie sekrety jeszcze przed zakomitowaniem i przed pushnięciem.
Krzysztof: Dokładnie tak, Andrzej, bo tu problem jest wielowarstwowy. Może chciałem powiedzieć czyste lenistwo, ale niech pierwszy kamieniem rzuci ten, który czegoś takiego nie zrobił.
Andrzej: Dokładnie, dokładnie. To jest łatwo jest oceniać jak się faktycznie nie wykonywało jakiejś pracy. Jak się ją zaczyna wykonywać to potem się okazuje a dobra są edge case’y, są edge case’y.
Krzysztof: Tak, tylko inną kwestią jest to, że faktycznie skanujemy nasz kod, ale tych miejsc, w których nasze sekrety mogą się rozprzestrzenić jest dużo więcej. Jak widzimy, gdyby przed tym pushem do zdalnego rejestru przeskanować jeszcze raz ten cały obraz, to w tym bytecodzie Pythonowym znaleźlibyśmy ten sekret. I bylibyśmy w stanie powiedzieć, OK, on nie jest w moim kodzie, w moim repozytorium, ale przez folder PyCache został gdzieś tam spakowany w tym bytecodzie Pythonowym i jest w obrazie. I o tym między innymi mówimy w naszym szkoleniu ABCD.
Andrzej: Dokładnie, dokładnie tak. Nie bez powodu o tym wspominamy, nawet poświęcamy dość spory kawałek całego szkolenia, no bo problem sekretu jest, był, jest i jeszcze z nami jakiś czas zostanie. Jak widać dotyka nawet ludzi, którzy mają lata, lata, lata doświadczenia w tym, co robią, piastują wysokie funkcje w danym ekosystemie i to jest coś, co może dotknąć każdego, bo to po prostu jest edge case. Nikt tego nie robi po to, żeby faktycznie upublicznić sekret, tylko tam się zawsze nawarstwia kilka różnych rzeczy, no a w efekcie mamy co mamy. Dobra, Krzysiek, to co? Na dzisiaj kończymy. W zasadzie tylko dwa, dwa, dwa newsy, ale za to, za to jakie? No CrowdStrike to, to wiadomo, news miesiąca, półrocza albo i nawet roku. Zobaczymy.
Krzysztof: Zobaczymy jak się, jak się z CrowdStrike’iem sytuacja rozwinie, bo z tego co można się dowiedzieć albo przynajmniej co się słyszy, no to pewnie batalie sądowe zostaną wytoczone.
Andrzej: Tak, no a zobaczymy, kto tam będzie końców wygrywał, ale tak, do sądu raczej to pójdzie, bo przeproszenie od pana CEO to jednak to za mało. Tutaj I’m sorry, I’m sorry, I’m really sorry. I od razu ta scena słow parka, nie?
Krzysztof: Tak, i nie wiem czy słyszałeś, pan George, bo tak ma CEO CrowdStrike’a, tak, o ile się nie mylę.
Andrzej: Tak, George Kurtz. Ja jeszcze powiem, że pamiętam jak to była moja pierwsza książka hakerska, którą czytałem. Hakerzy, cała prawda. W 2001 roku pożyczyłem ją od brata mojej koleżanki. No i patrzcie, zostałem hakerem. Natomiast on był tam współautorem.
Krzysztof: No to internauci wykopali, że pan George Kurtz był w 2010 CTO w McAfee i podobna sytuacja przydarzyła się w 2010.
Andrzej: Tak, tak, tak, tak, więc przypadek.
Krzysztof: Historia zatacza koło. Nie sądzę. Ok, no to kończymy. Życzymy Wam miłych wakacji. My jesteśmy już w połówce, więc albo jesteście przed, albo jesteście po, albo w trakcie. Miło, że z nami jesteście. Łapka w górę, dzwoneczek. Nawet dwie.
Andrzej: Łapka w górę, dzwoneczek i riszer.
Krzysztof: Ok, dzięki Andrzej za dzisiaj. Dziękujemy słuchaczom.
Andrzej: Do kolejnego.
Krzysztof: Trzymajcie się. Trzymajcie się, hej.