Analiza Backdoora XZ Utils
Ten odcinek podcastu zagłębia się w świat cyberbezpieczeństwa, koncentrując się na niedawnym, głośnym przypadku backdoora XZ Utils, który wstrząsnął społecznością IT. Analiza obejmuje przebieg ataku, od subtelnego wdrożenia złośliwego kodu na przestrzeni lat, po wyrafinowane techniki utrzymywania się w ukryciu i specyfikę celowania w konkretne dystrybucje Linuksa. Rozmowa podkreśla również, jak zaskakujące okoliczności doprowadziły do odkrycia backdoora, rzucając światło na luki w tradycyjnych metodach audytu kodu i sugerując potencjalną rolę sztucznej inteligencji w przyszłym wykrywaniu tego typu zagrożeń.
Wycieki Sekretów i Nowości w Branży
Dodatkowo, odcinek porusza problem wycieków sekretów w publicznych repozytoriach, przedstawiając najnowsze statystyki i korelacje z rozwojem sztucznej inteligencji, co bezpośrednio wpływa na ryzyko skompromitowania poświadczeń. Omówione zostają również bieżące wyzwania i nowości w branży, takie jak inicjatywa Security Champions, mająca na celu zwiększenie świadomości bezpieczeństwa wśród deweloperów, oraz ewolucja systemów oceny podatności, wykraczająca poza klasyczne miary, takie jak CVSS.
Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.
Transkrypcja
Andrzej: Dzień dobry. Dzień dobry. Dzień dobry wszystkim. Cześć Krzysztofie. Widzimy się po raz kolejny.
Krzysztof: Cześć Andrzeju. To już trzeci raz.
Andrzej: Trzeci raz i za każdym razem jest lepiej niż poprzednio.
Krzysztof: Tak, jesteśmy w nowym anturażu.
Andrzej: I wiesz, to tak po informatycznemu, iterate upon success. Każda kolejna iteracja i jest lepiej. Więc my się powitaliśmy, witamy też naszych widzów i słuchaczy. Też myślę, że zauważą, że jest trochę inaczej. Tu, na chwilę obecną, nie będziemy jeszcze zdradzać wszystkich sekretów, które mamy w zanadrzu i które będziemy wyciągać powoli z naszych rękawów w nadchodzących tygodniach. I bez dalszego owiania i odkrywania tych sekretów przejdźmy do dzisiejszego odcinka naszego podcastu i o czym będziemy dzisiaj mówić. Mamy kilka tematów, natomiast myślę, że każdy kto działa w IT, słyszał o jednym temacie takim przodownikom pracy poprzednich tygodni, można powiedzieć prezencie świątecznym na zajączka, czyli o backdoorze XZ w bibliotece XZ w LIB ZMA. Na chwilę obecną, ja jeszcze nie będę w to wskakiwał. Krzysiek, powiedz mi, co ty o tym słyszałeś, bo tak naprawdę to ja ci powiem, kiedy ja o tym usłyszałem. Ja nie usłyszałem o tym z jakiegoś serwisu czy z jakiejś maili. Ja siedziałem w pewnym miejscu w swoim domu, każdy w nim siedzi raz na jakiś czas i napisałeś do mnie. i patrzę, o, Krzysiek coś napisał, jakaś gruba impreza. Patrzę, tak się zaczytałem, że się zasiedziałem w tym miejscu. I potem można powiedzieć, że święta trochę popsute, bo już cały czas o tym czytałem. Ale Krzysiek, co ty wiesz o tym XZ Backdoorze?
Krzysztof: Andrzej, ja tutaj zrobię z wstępu, że połknąłeś tą króliczą norę, a prezent był na króliczka, na zajączka. Jak znalazł? Jeżeli chodzi o XZ, to ścina z nóg, urywa głowy. Prawdziwa bomba. Czegoś takiego nie było od dawna w świecie IT, w świecie bezpieczeństwa. Myślę Andrzej, że odbiję tutaj piłeczkę do ciebie jeżeli chodzi o XZ, a ja na pewno będę miał pewne komentarze i przemyślenia do tego co powiesz, więc przejmij pałeczkę.
Andrzej: Ja bym rozwinął, może nawet trochę wyolbrzymił to co powiedziałeś, bo nie tylko dawno nie mieliśmy, co chyba w ogóle nawet nie mieliśmy, takiego przypadku jak XZ Backdoor. Jedyne co mi się przywołuje na myśl pod kątem samej operacji i potem rozwinę i połączę te fakty. dlaczego to jest podobne, to przypadek event streama chyba bodajże z 2017 roku, który był podobny pod kątem, pod pewnym kątem operacyjnym. Natomiast czegoś tak zaawansowanego, bo tutaj nie chodzi tylko o samą operację, czyli taki nazwijmy to Operation Security, Human Intelligence, nie tylko to tutaj chodzi, tutaj chodzi o Wszystkie te klocki, które składają się na całą tą sprawę, one wszystkie stały na najwyższym poziomie. I żeby teraz wprowadzić słuchaczy, co się tak naprawdę wydarzyło. to tutaj można by pójść taką ścieżką timeline’ową i po prostu zacząć opisywać wszystko od samego początku do końca. Nie jestem pewien czy to ma tutaj aż taki sens. Ja bardziej zrobię TLDR, dlatego że sporo z tych kawałków, konkretnych punktów na tej ścieżce nie jest super ważna jako pojedyncze kroki. dla przeciętnego słuchacza, ale raczej ten kontekst, który się rysuje z poszczególnych kroków. I wszystko zaczęło się w 2021, kiedy pojawił się ciekawy, mysterious, jakiś tajemniczy użytkownik, Gia T75. Jakiś użytkownik, brzmi chińsko, ale tutaj jeszcze nie hold your horses, nie wybiegajmy z atrybucją, to mogli być Chińczycy, nie musieli, ktoś mógł się za nich podawać, tego nie wiemy, natomiast brzmi chińsko. I pojawił się taki użytkownik i ten użytkownik zaczął robić ciekawą rzecz. Mianowicie wszedł do projektu XZ Utils i zaczął faktycznie pomagać w jego rozwoju. Czyli tak naprawdę stał się, a może jeszcze się nie stał, ale zaczął dopisywać patche do projektu, które potem chciał, żeby weszły do samego oprogramowania, ale robił to tak, można powiedzieć, jak taki dobry Samarytanin. Czyli macie tutaj problemy, patrzcie, chcecie zrobić ten feature, to ja przyjdę, ja go tam zrobię i będzie fajnie, tylko go zmerżujcie.
Krzysztof: Kontrybuował z dobroci serca.
Andrzej: ewidentnie z dobroci serca. I to było w 2021 roku. I to się działo przez kilka kolejnych miesięcy, więc tych patchy było coraz więcej, więc ta dobroć serca była dość duża, no bo ten Gia T-75 to on tak naprawdę poświęcał swój wolny czas na kontrybuowanie do tego projektu, więc tak naprawdę robił to przez x miesięcy. Bardzo, można powiedzieć, powolnie, metodycznie, trzymając się na wodzy, kontrubował do projektu z poprawnym, normalnym kodzikiem, który był legit, z którym nie było żadnego problemu. Natomiast jest jeden ciekawy case, który już teraz, tak naprawdę od samego początku, bo od roku 2022 zaczął się dziać. Czyli przypadek, w którym ten oryginalny developer, ja teraz nie pamiętam jego imienia, nazwiska, ale nie jest to tak naprawdę ważne, ten oryginalny maintainer, autor tego narzędzia, pisząc je, developując, miał pewne gdzieś tam problemy natury, przynajmniej tak pisał, natury jakiejś zdrowotnej, personalnej, więc nie był bardzo responsive, to znaczy zabierało mu trochę czasu, merżowanie tych wszystkich patchy od Gia i też innych użytkowników. Generalnie nie mógł się poświęcić temu na full time. I to jest zrozumiałe, jeżeli ktoś tam kiedyś miał okazję kontrybuować albo prowadzić projekt open source to zdaje sobie tego sprawę, że to nie jest takie proste, to zjada bardzo dużo czasu i energii. I można zrozumieć tą drugą stronę jeśli ma problemy z ogarnięciem czegoś takiego, co więcej jeśli projekt jest faktycznie dość duży i ma sporo tych kontrybutorów. Ale To jest, nazwijmy, background do tego, że ten Gia zaczął dodawać te swoje patche, ale one nie były merżowane dostatecznie szybko. I teraz gracza, pojawia się na scenie kolejny gracz, który zaczyna popychać głównego maintainera i mówić mu, kurczę, no tak trochę, no może byś już zmerge’ował to, czekamy już miesiąc, czemu tego jeszcze nie zmerge’owałeś, nie. Potem pojawia się kolejny i też mówi, ale proszę cię główny maintainerze, czemu nie chcesz tego zmerge’ować, no zmerge’uj to już, nie. Taki można powiedzieć passive aggressive, ale żeby go tam trochę popnąć w tą… w tym kierunku.
Krzysztof: Andrzej byli szczerze zainteresowani tym, żeby te zmiany zostały zmergeowane.
Andrzej: Byli bardzo zainteresowani tym, żeby te zmiany zostały zmergeowane. Natomiast trzeba sobie zdać sprawę, że te wszystkie zmiany, bo dalej jesteśmy w roku 2022, one są legit, one są. to są faktycznie dobry kodzik, więc jakby tak popatrzeć z boku, to w zasadzie wszystkim zależy na dobrze projektu. Wszyscy chcemy popchać ten projekt do przodu, chcemy żeby ten projekt się rozwijał, więc chcemy żeby było dobrze, ale gdzieś tam te naciski się zaczęły pojawiać. I to jest ważne, dlatego że z perspektywy tego dewelopera to wyglądało jako jak coś, co jest realnym, realnym popchnięciem go, ale takim z dobroci serca, żeby faktycznie zmerżować ten kod, a nie że ja chcę, bo coś tam w tym kodzie jest złego. Tak zakładam, że ten maintainer tutaj nie widział tej jakiejś złowrogości, bo ona nie tyle była łatwa do zauważenia, właśnie była trudna, bo wszystko na ten moment jeszcze wyglądało legit. No i zaczęły być merżowane te zmiany, ale dalej działo się to dość powiedzmy powoli, więc zaczęły być merżowane zmiany, działo się to powoli. Gia w dalszym ciągu pisał kolejne patche, co więcej nawet wchodził, bo tam widać na liście mailowej, że główny maintainer zaczął się wypowiadać, że Gia zaczął z nim współpracować poza oficjalnym repozytorium, więc gdzieś tam nasza współpraca się zaciśnia z Gią, Gia jest fajny i być może, być może Gia kiedyś przejmie ten projekt, czyli tak naprawdę dostanie prawa do merge’owania do głównej gałęzi, a jak dostanie te prawa, to nie będzie musiał czekać na maintainera, żeby mu zmerge’ował. A wiadomo, będzie miał tak naprawdę główne klucze do systemu, bo będzie mógł zmerge’ować każdą zmianę, którą sobie zażyczy. No i można tutaj zrobić, już możemy przeskoczyć, zrobić ten fast forward, gdzie ja końcem końców otrzymał te prawa, pełne prawa merżowania, stał się już maintainerem projektu, ale to znowu trwało kolejnych x miesięcy, więc Wszystko zaczęło się w 2021. Już mamy x miesięcy do pierwszych meczy, potem mamy x miesięcy do uzyskania praw maintainera, więc tak naprawdę cała sprawa to są miesiące, w zasadzie można powiedzieć, że już rok plus. Więc wszystko trwa całkiem sporo czasu, bo gdzieś tam schodzimy pomiędzy 2022 a 2023, więc dalej jeszcze jesteśmy całkiem daleko od 2024. I w miarę rośnięcia zaufania Gia zaczął robić ciekawe rzeczy. Mianowicie Gia zaczął dodawać pewne pojedyncze komity, które oczywiście same w sobie jeszcze nie były malicious, no bo jak chłop jest ogarnięty to nie walnie Bagdora w pierwszym jednym komicie, jednym takim atomicznym, no bo to byłoby dość łatwe do zauważenia przez każdego. Więc poszedł do tego sprytnie i podobnie właśnie podchodzili w ataku na event streama. Hakerzy, którzy hakowali event streama, oni też po pierwsze zyskali zaufanie maintainerów i najpierw zyskali możliwość dopisania do głównego reprezentatora event streama. Następnie przez x miesięcy mając już te prawa w dalszym ciągu dodawali poprawny kodzik, czyli byli normalnymi deweloperami i dopiero w pewnym momencie dodali jedną zależność do event streama, I dopiero po czasie w tej zależności dodali złośliwy kod, czyli tak naprawdę nie dodali złośliwego kodu do event streama tylko do biblioteki, która była dołączona do event streama i wszystko też trwało x miesięcy. To tak samo tutaj w przypadku xz to się nie wydarzyło naraz, tylko działo się przez x miesięcy, tam bodajże poniżej roku. Natomiast tam tym końcowym celem było po prostu kopanie kryptowalut, o ile dobrze pamiętam, więc tam ten cel był taki można powiedzieć XD. Nie XZ, ale XD. Natomiast w naszym przypadku XZ cel był trochę trudno powiedzieć, możemy się tylko domyślać jaki był cel, ale domyślamy się, że cel był trochę inny, ponieważ końcem końców to, co zostało dołączone, to została dołączona możliwość, w cyber security nazywamy to capability, zostało dołączone capability do zależności X, Z, które umożliwiało zdalne wykonanie kodu w serwerze SSH, Open SSH, czyli daemonie SSHD, które korzystało z zależności właśnie z libzma i potem przejściowo z xz. Co jest ciekawe, a to jest bardzo ciekawe i w zasadzie to jest tak ciekawe, że dla mnie ciekawe jest dlaczego wszyscy o tym nie piszą, bo to jest chyba jeden z najciekawszych kątów patrzenia na tą sprawę, to to, że to nie dotyczyło, ten atak na to OpenSSH poprzez złośliwą zależność, która była dołączona do OpenSSH, on nie dotyczył wszystkich OpenSSH-ów. On dotyczył wybranego podzbioru OpenSSH dla dystrybucji Linuxa, które zrobiły pewną zmianę i ta zmiana korzystała z tych zależności po to, żeby te demony SSHD mogły działać w tych dystrybucjach i korzystać z system D. więc nie będę tutaj mówił o jakie dystrybucje chodzi, ale na pewno nie chodzi o takie dystrybucje jak np. Gentu czy Arch, ale znowu myślę, że słuchacze wiedzą, nikt na serwerach nie ma Archa czy Gentu, na serwerach raczej jest Ubuntu czy Fedora, no a niestety właśnie Ubuntu czy Fedora korzystają z system D. I ciekawe tutaj jest nie tylko to, że to musiała być odpowiednia paczka OpenSSH, ale raczej to, jeśli zrobimy taki myk i odwrócimy i się zapytamy Zadałem pytanie, ale czemu akurat te paczki? Czemu akurat to? No właśnie, czemu akurat to? A być może było tak, że ktokolwiek sponsorował ten atak, pomyślał sobie, Kurczę, mam takie i takie systemy, dobra i w takich i takich systemach korzystamy z takich i takich paczek, między innymi z OpenSSH, które w każdych systemach są wystawione, żeby móc nimi administrować, wykonywać administracyjne akcje zdalnie. To teraz zobaczmy z jakiej zależności korzystają te paczki OpenSSH, ale ale nie korzysta z nich ten oryginalny pakiet OpenSSH, bo ja nie muszę łamać samego OpenSSH jako projektu, który może być bezpieczny, ale jeśli chce się dostać do serwera Ubuntu czy Fedora, bo to są serwery, które wykorzystuje mój przeciwnik, no to tak naprawdę nie interesują mnie zależności samego OpenSSH, ale interesują mnie zależności, które są wykorzystywane w obrębie tego ekosystemu, który chcę zaatakować. I tu był ten dokładnie ten edge case w postaci właśnie tej biblioteki, co było mega ciekawe samo w sobie, czyli tak naprawdę ktoś bardzo mocno odrobił lekcję, bo to nie było tak, że ktoś na to wpadł przez przypadek. To musiało być poprzedzone dość głęboką i szeroką analizą systemów, do których chcemy się dostać w przyszłości. Następnie, co jest punktem rozłącznym od wszystkich systemów i jest tylko w tych systemach, do których chcemy się dostać. I jak możemy to zaatakować? No i oni znaleźli między innymi to, pewnie jest więcej takich edge case’ów, no i to zaatakowali. A czemu mówię, że była to jakaś taka szersza operacja? No bo jeżeli kogoś stać na przeprowadzanie operacji, która trwa dwa, co najmniej dwa lata, a praktycznie cztery, bo tak naprawdę GIA Samego Bagdora dodał w 2024, czyli 3 lata po tym jak dostał prawa do pisania. Więc samego Bagdora wykryliśmy dość szybko. To jak go wykryliśmy to jeszcze zaraz powiem, ale samego Bagdora jako jako community wykryliśmy dość szybko, bo został wprowadzony w 2024. w marcu, a wykryliśmy go na początku kwietnia. Przy czym oficjalnie został wykryty w kwietniu, a tak naprawdę osoba, która go wykryła kontaktowała się i prowadziła, nazwijmy to, śledztwo już oczywiście w marcu, więc został wykryty dość szybko. Co oczywiście pewnie nie cieszy pewnych osób czy pewnych agencji trzyliterowych na świecie. Natomiast jeszcze to, w jaki sposób zostało wykryte, to też jest mega ciekawe. Ja do tego zaraz wrócę, ale powiedz mi Krzysiek, jakie masz myśli na ten na ten moment odnośnie całości.
Krzysztof: Andrzej zapadał mi w pamięć teraz to co powiedziałaś na temat tego maintainera, tego oryginalnego maintainera tego pakietu, że została wykorzystana jego sytuacja życiowa. Chciałbym tutaj nawiązać przy okazji do tego, że takie sytuacje dzieją się też np. w świecie NPM-a, gdzie targetowani są maintainerzy, którzy na talerz wezmą sobie za dużo paczek. Więc tak, tutaj widać to powiązanie i ten rekonesans w kierunku tego, żeby tak jak powiedziałaś, po pierwsze startować odpowiedni pakiet, ale też umieć wykorzystać pewną lukę, która wynikała z samej sytuacji życiowej tego człowieka, więc bardzo przebiegłe. I jeszcze jedna rzecz, do której chciałbym nawiązać. Mówiłeś o sytuacji, w której te komity, które zawierały już złośliwy kod, były dodawane krok po kroku, małymi batchami. Nie były tak oczywiste, to nie był taki backdoor, który został wrzucony jednym komitem. I na myśl przypomina mi się nasza rozmowa na temat backdoora, który tak naprawdę nie był backdoorem umieszczonego w jednej z wersji PHP. I pamiętam, że wtedy wspomniałeś mi o tym terminie wiarygodnego zaprzeczenia. Dlaczego wtedy to nie można było tego w PHP nazwać prawdziwym backdoorem, bo prawdziwy backdoor powinien spełniać tę cechę tego zaprzeczenia. Nie byliśmy tam w stanie, byliśmy w stanie bezpośrednio wskazać, że to ta zmiana tego człowieka konkretnie w tym punkcie czasu wprowadziła. A tutaj gdyby wszystko nie wyszło tak naprawdę na jaw w taki sposób, jaki o tym zaraz opowiesz, no to moglibyśmy żyć długo w nieświadomości. Samo podejście jest po prostu niebywałe do tego całego ataku i jest mi ciężko uwierzyć, że nie zostało to wykorzystane przez aktorów, którzy są wspierani przez duże agencje wywiadowcze.
Andrzej: Na pewno. 99,99% że to jest nation state. Natomiast ja jeszcze wrócę do tej właściwości, możliwości zaprzeczenia. W angielsku to jest plausible deniability. I chodzi o to tutaj, że jeżeli wprowadzamy backdora do czegokolwiek, to może być software, to może być hardware, ale nie tylko. Nawet na poziomie takiego mówienia czegoś, no bo to też możemy na poziomie umowy z kimś wprowadzać backdora. to chcemy zostawić sobie możliwość na zaprzeczenie, że nie, to nie był backdoor, ja nie chciałem, to była tylko pomyłka. Oczywiście wiemy, że ta druga strona robi nas w konia, ale nie jesteśmy w stanie udowodnić tego, że robi nas w konia. Takim świetnym przykładem właśnie backdoora gdzie nie da się jasno udowodnić czy to był bug, czy to była zwykła pomyłka jest goto fail vulnerability w notabene w OpenSSLu z Apple, bodajże w 2014 roku się pojawiło. I tam błąd polegał na tym, że jeśli ktoś programował w C, C++ to wie, że ma taką konstrukcję jak goto. GOTO, GOTO raczej nie jest używane, raczej nie jest używane w programowaniu, tylko staramy się tego unikać. Natomiast jeśli mamy switch case, to na samym końcu, jeśli zapomnimy dodać pewnej rzeczy, to kompilator Ja teraz szczegółów nie pamiętam dokładnie, czy tam było to goto, czy go nie było. Natomiast bardzo trudno jest, patrząc na kod i na komitę oczywiście i nawet człowiekowi na ręce, powiedzieć, że popełnił ten błąd świadomie, bo ten błąd bardzo łatwo można popełnić nieświadomie, czyli można po prostu zapomnieć o dodaniu jednej klauzuli, ale kompilator zrozumie to opacznie i przestanie walidować wszystkie certyfikaty w całym switch case. Więc tak naprawdę dowolny certyfikat będzie zaakceptowany, bo na końcu mieliśmy nieodpowiednią jedną linijkę kodu, która mogła być błędem, która wygląda, Jezus Maria, po prostu jak zwykły błąd. i tam mamy tą właściwość plausible deniability, więc to jest świetny przykład Backdora. Tutaj też mamy świetny przykład właśnie Backdora, gdzie każda z tych pojedynczych, trudno by było powiedzieć, że ktoś faktycznie coś chciał zrobić w pojedynczym komicie. Tym bardziej, że one były takie sensowne. Tam był nawet jeden taki komit, gdzie wyłączał jedną funkcję, funkcjonalność całą z testów fuzzinga, z fuzzingu, które są przeprowadzane dla tej biblioteki w ramach open source Google’a. To jest OSS Fuzzer, więc są tam pewne projekty, które są fuzowane w trybie ciągłym. I maintainer, no ten Gene Yang z Silicon Valley. Więc ten nasz Gene wyłączył tą jedną funkcjonalność mówiąc, że no ja muszę ją wyłączyć, ponieważ mi się tam coś wywala, a to w zasadzie ta funkcjonalność tam jest nieważna, to weźmy jej, nie fazujmy. I okej, dobra, przestali ją fazować. A gdyby ona była fazowana, to Fazer pewnie by szybciej wywrócił tą aplikację i ktoś by po prostu na to spojrzał. Więc tam było kilka takich pomniejszych, mocno wytargetowanych kroków, które zostały wykonane przez tego fretaktora. które pozwoliły mu końcem końców doprowadzić do tego stanu finalnego, gdzie wprowadził już samego gotowego Bagdara już na samym końcu, ale wszystko to, co zrobił wcześniej pozwoliło mu na realizację tego ostatecznego celu. I ja powiem więcej, nie wiem, ale się domyślam. z mojej perspektywy, gdybym ja miał przeprowadzać takie operacje, to wydaje mi się, że jest to logiczne, gdzie mamy tak drogocenny cel, że jesteśmy w stanie spalić całą tą pracę, którą wykonaliśmy przez dwa lata, tylko po to, żeby w tym punkcie czasu dostać się do tej maszyny, do której chcieliśmy się dostać. I potem już mnie nie interesuje, czy ktoś to za tydzień wykryje, czy nie, bo ja już w tym momencie spisuję to na straty, bo dla mnie ten cel jego wartość przerasta wartość całej inwestycji, którą wcześniej wykonałem. I nie wiem, ale się domyślam, że ta agencja, która ten backdoor wprowadziła, najwidoczniej na początku marca miała taki cel, który chciała zaatakować. To mógł to mógł być zestaw celów, ale doszli do wniosku, że okej, to w tym momencie spalą sobie tą broń po to, żeby osiągnąć cel operacyjny najpewniej jakiś wywiadowczy lub militarny. My to maluczcy pewnie się nie dowiemy co to był za cel. Też nie musimy. Natomiast zakładam, że tak było. Jedyne co warto tutaj uwypuklić to w jaki sposób zostało to znalezione, bo nie zostało to znalezione, nie wiem czy ktokolwiek będzie zdziwiony, ale pomimo tego że Linus Torvalds kiedyś ukłół takie prawo, że wszystkie błędy są płytkie, jeśli jest wystarczająco dużo oczu, który na nie patrzy. No, parafrazuję, bo oczywiście po angielsku Linus mówi, all bugs are too shallow with enough eyeballs watching. Natomiast Najwidoczniej nie. Najwidoczniej nie, bo nikt nie odkrył tego patrząc na komity, nikt nie odkrył tego patrząc na kod, nikt nie odkrył tego testując bezpieczeństwo tego kodu. W zasadzie to nawet nie odkrył tego żaden bezpiecznik, tylko odkrył to programista, który zobaczył jakąś anomalię w swoim systemie i zaczął ją debagować. A anomalia wyglądała w ten sposób, że SSHD, demon, zabiera zbyt dużo zasobów w komputerku, na serwerze. No i to gdzieś tam zaciekawiło tego inżyniera. Myślał, no dobra, coś tutaj jest nie tak. Czemu zabiera mi tyle zasobów, jeśli ktoś się do mnie łączy z trefnym loginem hasła? No przecież to powinien się tylko odpytać, rozłączyć i tyle. A czemu tutaj są zasoby? Potem poszedł trochę dalej i zobaczył, o kurczę, Te zasoby to są konkretnie w jednej zależności, bo używał perf do debugowania i to było w lib ZMA. A potem poszedł jeszcze dalej i zobaczył, kurczę, no ciekawe, wykonuje się jakiś kodzik, ale perf nie potrafi przypisać symbolu do funkcji, która się wykonuje. Dla niewtajemniczonych, dla osób, które nie programowały w CC++ i niskopoziomowo, systemowo, Symbole funkcji służą do debagowania. Większość binarek posiada symbole po to, żeby jeżeli coś się wywróci na serwerze produkcyjnym, to żebyśmy mogli zobaczyć w którym punkcie się wywróciło, w jakiej funkcji i żebyśmy mogli po prostu zacząć sobie debagować i sprawdzać co się tam działo. Więc symbole funkcji są nawet w binarce, która się wykonuje w pamięci. I jest naprawdę bardzo ciekawe, jeśli debagujemy binarkę i wykonuje się kod w binarce, która posiada symbole, bo nie musi posiadać, ale jeśli posiada, to jest bardzo dziwne, jeśli wykonuje się kod, którego nie możemy przypisać do żadnego symbolu. Można powiedzieć, że jest to niemożliwe, chyba że ktoś wykonuje kod, jakiś shellcode, który nam wrzucił do pamięci. No to wtedy jest to możliwe, ale wtedy to już mamy, konkretnie jesteśmy schakowani. Więc Więc tutaj była taka sytuacja, no i ten inżynier to odkrył, zaczął grzebać głębiej, ale to co ja chciałbym tu wypuklić, że jednak to nie byli bezpiecznicy, jednak byli to inżynierzy, byli to programiści, bo najwidoczniej takie bezpieczeństwo oparte, no wystarczy przeczytać kod, najwidoczniej nie do końca działa, bo po prostu kodu jest więcej niż ludzi, którzy czytają ten kod. Nigdy nie będzie tych tysięcy oczu, które patrzą na każdą aplikację, po prostu kodu jest dużo więcej niż ludzi. I tutaj taka ciekawa notka, że być może AI może nam w tym pomóc. Już nawet niekoniecznie chodzi mi o audyt kodu, który wchodzi, bo w dalszym ciągu musielibyśmy w jakiś sposób przeprowadzić jakąś analizę tego, co jest komitowane, a to nie jest takie łatwe. Ten problem jest tym większy, im więcej kodu mamy i nie rośnie liniowo, chyba mi się tak wydaje, ale tutaj ręki sobie nie dam uciąć, bo potem bym skończył bez ręki. Natomiast ważne jest to, że AI może nam pomóc od trochę innej strony i Daniel Miesler, którego obaj lubimy, Daniel Miesler opisał w taki ciekawy sposób, że w zasadzie AI mogłoby pomóc w wykonaniu Open Source Intelligence OSINTu dla maintainera, który dołącza do naszego projektu, no bo ten Gene Yang, to on wcześniej nigdy do niczego innego nie kontrybuował, tego adresu nigdzie w internecie nie było. I wiadomo, że dla każdego projektu nie jesteśmy w stanie my ręcznie wykonywać takiej analizy. No ale gdybyśmy mieli takiego agenta, takiego LLM-a, który potrafi odpytać sieć, potrafi zebrać te informacje, potrafi je zagregować, w jakiś sposób zrozumieć i zamodelować i przedstawić nam wynik, no to jest to wartościowe dla bezpieczeństwa nie tylko open source’a, ale generalnie, generalnie software’u. Być może nie robimy tego dla tego kodu, który wykonujemy, ale robimy to dla osoby, która potem ma ten kod pisać, co też jest wartościowe.
Krzysztof: Tak, zwłaszcza dla ludzi, którzy kontrybuują do Open Source’a i tak naprawdę nie mają z tego pieniążków. Świetnie, Andrzej, opowiedziane. Myślę, że dla dewelopera, który znalazł podatność, przynajmniej pokojowa nagroda Nobla. No chyba, że był kolejną częścią tej wielkiej układanki i zaraz będziemy mieli plot twist, że był po prostu i półpracownikiem jednej z tych agencji. Co byłoby już grubym plot twistem. Co prawda, co prawda, co prawda. Co do XZ, to będzie już chyba na tyle.
Andrzej: Oczywiście w Xecie moglibyśmy wchodzić jeszcze w to jak skomplikowany był sam backdoor. Oni tam wykorzystywali sygnatury żeby było żeby aplikować taką taką metodykę która się nazywa Nobus czyli no one but us. Więc żeby nie było tak że ktokolwiek jest w stanie się włamać i wykonywać komendy ale tylko my tylko my kreatorzy tego backdora. Natomiast prawda jest taka że dla dla naszych słuchaczy. myślę że nie jest to aż tak ważne bo to są mocno niskopoziomowe rzeczy które nie mają znaczenia, że oni tam używali jakiegoś tam szyfrowania i sobie mieli sygnatury dla kodu, który przesyłają etc. To jest takie, no fajnie, no mieli, ale czy to jest tak naprawdę, co z tego możemy się nauczyć. My możemy się nauczyć, że jeśli utrzymujecie kod, to być może należałoby się zastanawiać jakie, jakie zależności dołączamy do tego kodu i jakie nasze zależności dołączają dalsze zależności. Bo tutaj jednym z tych głównych problemów było to, że nikt nie podjął świadomej decyzji o załączaniu tych zależności. Po prostu deweloperzy tych dystrybucji pomyśleli, dobra chcemy to spiąć z system D, no to użyjmy tej biblioteki i okej. Ta decyzja nie była świadoma. Jeśli byłaby świadoma, to może udałoby się tego uniknąć, więc jedną z głównych lekcji jest tutaj świadomie dołączajmy zależności do naszych projektów i nie patrzmy tylko na tą pierwszą linię, ale też drugą, trzecią, czwartą. Podchodzimy do tego z należytym due diligence, na tyle oczywiście na ile możemy, bo zdaję sobie sprawę, że to zawsze są po prostu koszty.
Krzysztof: Tak zwłaszcza że to co Andrzej powtarzasz już od wielu lat zaufanie jako relacja przechodnia. dołączając paczkę dołączamy kolejną paczkę a podstawą zaufania jest kontrola.
Andrzej: Ufaj ale kontroluj.
Krzysztof: Dokładnie. Przechodzimy do kolejnego tematu. Teraz będzie troszkę mniej ezoterycznie i mistycznie. I powiem o czymś, o czym mówię tak już naprawdę od dwóch lat.
Andrzej: Od dawna.
Krzysztof: Od dawna. A w kontekście naszych spotkań i naszych rozmów od dwóch odcinków. Teraz jest trzeci i znowu poruszam temat sekretów. Ale nie mogę, Andrzej, nie mogę, bo ciągle się coś dzieje.
Andrzej: Krzysiek, to jest twój temat.
Krzysztof: A teraz dzieje się to, że GitGuardian, firma, która w ogóle buduje biznes na tym, że zajmuje się detekcją sekretów i wspiera, rozwiązuje ten problem, wypuściła swój coroczny raport The State of Secrets Sprawl i mam go przed sobą. Chciałbym go stresić tutaj dla naszych słuchaczy, bo wnioski są ciekawe, liczby są ciekawe, bo Tak naprawdę ten raport opisuje okres za ubiegły rok, więc w zeszłym roku GitGuardian w publicznych repozytoriach na GitHubie znalazł 12 milionów 800 tysięcy sekretów. co, uwaga, stanowi wzrost o 28%. Czyli rok do roku w tych raportach obserwujemy tendencję wzrostową problemu, który wydaje się błahy, wydaje się dziecinnie prosty do rozwiązania, a tak naprawdę jest coraz gorzej. Patrząc na to z trochę innej perspektywy, żonglując cyframi, żonglując liczbami, no to blisko 5% wszystkich publicznych repozytoriów na GitHub’ie, biorąc pod uwagę ten cały research, opublikowało przez przypadek albo nie przez przypadek jakiś sekret. Więc biorąc pod uwagę skalę całego GitHub’a, 5% to jest naprawdę ogromna liczba. To się też fajnie bardzo pokrywa Andrzej z raportem, który bardzo często przytaczasz od dużego… bodajże amerykańskiego telekomu, jeżeli się nie mylę, Verizona. Mówimy tutaj o Data Bridge and Investigations, który też jasno wskazuje, że główną przyczyną ataków są po prostu skompromitowane poświadczenia. To jaka przez poświadczenia mamy na myśli między innymi nasze kluczyki, API tokeny i tak dalej. GitGuardian wskazuje w swoim raporcie Andrzej, że 90% wszystkich sekretów, które znaleźli było aktywnych od momentu znalezienia przez pięć dni, kiedy się do nich znowu dobili, znowu były aktywne. I to mam takie do ciebie pytanie, czy robiąc ten swój eksperyment, jak szybko wtedy, może pamiętasz, jak szybko te sekrety były odpytywane, kiedy upubliczniałeś te kluczyki w ramach swojego badania?
Andrzej: Ja zrobiłem takie pytanie w 2020 roku, to było pod koniec i dla GitHuba pierwsze odpytanie miałem trzy albo cztery minuty po upublicznieniu sekretu, czyli sekret do instancji AWS. wpadł tam powiedzmy o 16.07. A o 16.11 miałem pierwsze zapytanie wykorzystujące ten sekret, które już chciało się dobić do mojej instancji AWS. Czyli cztery minuty, po czterech minutach było już odpytanie. to w przypadku GitHub’a, w przypadku GitLab’a to było coś koło godziny, więc dość szybko.
Krzysztof: Czyli mają rozmach, są szybcy.
Andrzej: Na pewno robią to w wydaniu ciągłym.
Krzysztof: Ale tutaj też taka lekcja, taka lekcja, mini lekcja dla naszych słuchaczy, że te publiczne repozytoria, one są cały czas pod ostrzałem.
Andrzej: Cały czas, cały czas.
Krzysztof: tam ktoś siedzi i ora przez API publiczne, które jest dostępne i naokrągło wszystko co jest wrzucane jest przeglądane. To co jeszcze mnie zaskoczyło w tym, może nie zaskoczyło, co chciałbym podkreślić w tym raporcie to oczywiście to, że Widzimy pewną korelację związaną z tym, że boom na sztuczną inteligencję, mówię tutaj o dużych modelach językowych, spowodował oczywiście to, że wykorzystujemy, łączymy się do API tych usług, czy to mówimy o OpenAI, czy mówimy tutaj o modelu od Antromorphic, tych firm jest sporo. myślę, że każdy z Was jest w stanie wymienić kilka takich serwisów, które świadczą takie usługi. A tutaj Grid Guardian zwraca uwagę, że w związku z poprzednim raportem oni tutaj obserwują wzrost wycieków tych kluczyków związanych z takimi serwisami, które które dotykają generatywnej sztucznej inteligencji o 1200 razy. I to się też fajnie zaczyna łączyć z tym, o czym mówiliśmy w naszym poprzednim odcinku. Dlaczego np. PyPI przejmuje pałeczkę, jeżeli chodzi o umieszczany malware w zależnościach. Dlaczego akurat teraz? Zawsze MPM był tą wiodącą platformą. Chodzi o to, że po prostu są tam ludzie, są tam ludzie, którzy korzystają z ekosystemu Pythona do tego, żeby zachodzić coś właśnie w kontekście tego boomu na AI. I tutaj też to obserwujemy, że pewne wydarzenia korelują z tym, jak wypływają pewne problemy bezpieczeństwa. I ciekawostka Andrzej dla ciebie albo pytanie ciekawostka. Jak myślisz jakie rozszerzenie pliku zdradzało najwięcej sekretów w środku?
Andrzej: Ja myślę, że to tylko jedno mogło. Dotenf.
Krzysztof: Dokładnie. Autorzy raportu szacowali, że miałeś 54 procent szans, że jak wejdziesz w jakiegoś .enwa na GitHubie, to znajdziesz tam jakiś sekret.
Andrzej: Bo ja myślę, że każdy kto nas słucha doskonale sobie zdaje sprawę. Każdy kto pisze aplikacje, w .envach po prostu się wsadza sekrety i to jest takie normalne. A potem bardzo łatwo nie mieć .envu w git.ignore i po prostu go tam dołączyć jako plik. Co więcej, ja tutaj dodam jedną ciekawostkę, bo ktoś mógłby powiedzieć, no dobra, spoko, to dodajmy do Git Ignora, a do Tenva wysyłamy na Slacku. Problem jest taki, że oczywiście moglibyśmy wysłać na Slacku, jeżeli działamy w jakimś tam powiedzmy startupie i nie mamy nic super krytycznego. to okej, nie bijmy się z koniem, ale jest pełno miejsc, w których takie coś po prostu nie przejdzie i jak najbardziej są miejsca, firmy, organizacje, w których nie tylko należy, ale w których się po prostu skanuje całą infrastrukturę, czyli nie tylko repozytorium kodu, ale też całego Slacka. cały potok CICD, wszystkie narzędzia wokół właśnie w poszukiwaniu sekretów, bo mają tak wyślubowane wymagania odnośnie security i compliance’u. I ostatnio miałem właśnie taką rozmowę na jednym Discordzie, gdzie jeden inżynier pracujący w, no to nie tyle inżynier, bo to już jest taki można powiedzieć principal architect, w dość poważnym biznesie fintechowym w Londynie. Właśnie opisywał, że u nich to skanują wszystko, wszystko. Na Slacku to od razu zacznie… Od razu wyłapią, że ktoś… Będzie krzyczało. Tak, będzie krzyczało, będą problemy, bo nie można sobie takiego docenta wrzucić na Slacka, a przynajmniej nie powinno się. Więc problem nie jest tak łatwy do rozwiązania, że dobra, to uniknę repozytorium, ale prześlę, prześlę mailem. To nie o to chodzi. Chodzi o to, żeby mieć przykładowo jakąś usługę w infrastrukturze, która zajmuje się dystrybuowaniem sekretów jakiegoś Volta. Co oczywiście ja też wiem, że to nie jest takie łatwe jest powiedzieć, trudniej jest zrobić.
Krzysztof: Zacznijmy od prewencji i tych sekretów tam po prostu nie umieszczajmy. Myślę, że tutaj się zgodzimy. Myślisz Andrzej, że problem z sekretów jest problemem, który jesteśmy w stanie łatwo rozwiązać, czy on jest na tyle z jednej strony banalny, a z drugiej ciężki do rozwiązania, że nie mamy tutaj… Ciężko tutaj znaleźć jakiś złoty środek.
Andrzej: Ten problem to jest simple to fix, but not easy. Więc nie, nie jest łatwy. A jeśli ktoś uważa, że jest łatwy, to po prostu ma za mało doświadczenia takiego komercyjnego, bo to samo można by powiedzieć o XSS czy o Stack Based Buffer Overflow. To też jest łatwe do rozwiązania, tylko nie do końca. Jeżeli jest łatwe to dlaczego od 30 lat dalej mamy te same podatności.
Krzysztof: Patrząc na to ile mamy tej powierzchni ataku, bo my mówimy tylko o repozytoriach, powiedziałaś o Slacku, mówimy też o kubełkach na S3, na GCP, na Azure. Tych miejsc gdzie ten sekret może się jakoś wysilizgnąć spod naszej kontroli jest całkiem sporo. Na szczęście mamy metody, mamy narzędzia, które nam na to pozwalają, więc detekcja sekretów obowiązkowo must have przynajmniej w CI. Dobrze by było.
Andrzej: Tak, tak, tak. Tutaj po prostu trzeba działać na tyle na ile możemy i na tyle na ile nam oczywiście pozwala organizacja lub I to jeżeli mamy idealną organizację, no to będziemy mieć idealne procesy i tak jak mówiłem u tego znajomego, u nich to naprawdę jest dobrze zrobione, ale to wynika po prostu z compliance’u zewnętrznego i z wrażliwości danych, które przetwarzają. więc niejako muszą podchodzić naprawdę porządnie do tego bezpieczeństwa i to robią. Nie zawsze jest to w pełni uzasadnione, ale dążyć należy do ideału, a nie do najniżej wiszącej poprzeczki.
Krzysztof: Tak. No i tutaj chyba w kontekście sekretów postawimy kropkę. i ja obiecuję i biję się w pierś, że w następnym odcinku postaram się nic już o sekretach nie mówić. No chyba, że nie wiem co się wydarzy, naprawdę nie wiem.
Andrzej: Trzymam cię za słowo. Ale rozumiem, że tutaj masz na myśli tylko przyszły odcinek. o przyszłych odcinkach, to nie jesteś w stanie tego wykluczyć. Przyszły odcinek, okej, dobra. Spróbujemy to pominąć.
Krzysztof: Spróbujcie nie komitować sekretów do repozytorium, przynajmniej przez dwa tygodnie do następnego odcinka, prosimy.
Andrzej: Dobra, teraz przejdźmy do czegoś, co wyszło tak naprawdę już w kwietniu, bo na początku kwietnia, ale skoro nagrywamy to, który dzisiaj jest piąty, skoro nagrywamy to piątego, to Trzeba wspomnieć o czymś, co każdy zna, ale z perspektywy naszej bezpiecznikowej, czyli Tech Radarze od ThoughtWorks. Wyszedł kilka dni temu, kurczę, nawet nie wiem, czy kilka dni temu, czy nie dzisiaj wyszedł, ale wyszedł chwilę temu. Ja już na niego rzuciłem okiem. Oczywiście Control F, Security i tylko Next, Next, Next, Next. Wybrałem wszystko, to nie wszystko, ale te najciekawsze rzeczy, które tam zahaczają security i pierwszą z nich jest coś, co jest w woreczku trial i co się nazywa continuous compliance, czyli żeby zapewniać compliance w takim trybie ciągłym. I ja z tym mam taki problem, znaczy ja się oczywiście z tym zgadzam, ale problem mam taki, że oni trochę ten compliance to tak szeroko ujęli, typu no na przykład I to jest taki, no tak, Sasta trzeba mieć, ale to nie do końca jest compliance. Oczywiście używa się Sasta, żeby wymuszać compliance, ale te dwa zbiory to nie jest jeden zbiór. To dalej są dwa osobne zbiory, które mają części wspólne. Więc ten opis tego Continuous Compliance to mi niezbyt podszedł w tym Fotworksie, to jak oni to widzą. Natomiast co do zasady oczywiście się zgadzam i to podejście już od lat można zobaczyć. Compliance as Code, czyli przykładowo jeżeli mamy infrastrukturę w plikach deklaratywnych no to chcemy mieć narzucone jakieś zasady w naszym silniku analizy statycznej, które nam walidują te pliki. i oczywiście to samo możemy robić dla kodu, czyli może nie tyle chcemy wykryć jakieś paterny podatności, ale na przykład chcemy mieć pewność, że nie możemy dodać funkcjonalności eval w tam javascriptie. dokładnie tak jak to robił Microsoft lata temu, gdy wprowadzał SDL-a, gdzie tak naprawdę oni już mieli ten continuous compliance, gdzie nie pozwalali dodawać pewnych funkcji albo po prostu w ogóle je podmieniali. pod spodem, czyli przykładowo programista wpisywał string copy strcpy i korzystał z tej funkcji, ale pod spodem, jeśli ktoś wszedłby, zrewersował, to tak naprawdę to nie było string.copy, tylko było string.n.copy i argumenty były dynamicznie obliczane na tyle, na ile się dało, a jeśli się nie dało, no to po prostu krzyczał kompilator i mówił, nie możesz użyć tej funkcji, nie chcemy jej. No i to był Continuous Compliance, coś o czym pisze TechRadar w 2024 roku, czyli 22 lata później.
Krzysztof: Odgrzewany kotlet. Trochę. Ale może Andrzej, może na kanwie tych wszystkich wymagań, które gdzieś tam się w ostatnich latach przewijają. Mówię o Nisie dwójce, mówię o CERA, mówię o egzekutywach prezydenckich prezydenta Stanów Zjednoczonych. Może to jest gdzieś ten punkt, dlaczego to wypływa znowu, tylko pod innym brandem, że tak to ujmę.
Andrzej: Może tak, wiesz, ten radar jest stworzony w ten sposób, o ile dobrze pamiętam, na podstawie tego, co oni sami w zespołach ThoughtWorks po prostu utylizują i mogli sobie obrandować, że to się teraz nazwiemy sobie Continuous Compliance. Natomiast sama ta technika, jeżeli sobie przeczytamy po prostu opis tego, no to myślę, że każdy bezpiecznik czy nawet inżynier na MIT czy senior będzie kojarzył z własnej pracy, że takie coś generalnie jest i to nie trzeba trialować. Kolejna rzecz, która jest na tryalu to inicjatywa Security Champions. I Security Champions to akurat mnie pozytywnie zaskoczyło, że się pojawiło. Ja nie pamiętam czy były w poprzednich, ale to, że jest i to, że jest opisane i to, że jest zwracana na to uwaga to tylko mnie cieszy. A cieszy mnie dlatego, że z doświadczenia wiem, że w zasadzie jakakolwiek inicjatywa związana z budowaniem bezpieczeństwa w procesie wytwórczym powinna zacząć się od zbudowania zespołu Security Championów, co ma swoje plusy, minusy i ma swoje problemy z tym związane. Natomiast rozwiązuje nam bardzo duży problem, który dość szybko blokuje jakiekolwiek działanie, mianowicie rozmiar jednostki APSEC, która zawsze jest za mała. Jeżeli mamy dwóch, trzech inżynierów od APSEC to już jest dobrze. Developerów mamy często więcej, więc jeśli mamy przykładowo 200 developerów na jednego inżyniera APSEC to To nie będzie działać. Nie ma prawa. Więc chcemy w jakiś sposób zbudować pewną barierę, pierwszą linię frontu i taki security champion. to jest osoba w zespole wytwórczym, która jest mianowana na tą osobę, która powinna zwracać większą uwagę na bezpieczeństwo. Oczywiście taka osoba przychodzi odpowiednie treningi, jakieś szkolenia. Jest wykonana jakaś inwestycja w jej kierunku, żeby nabyła te umiejętności. też powinna wykazywać jakieś zainteresowanie tematem bezpieczeństwa, ale jej głównym zadaniem jest właśnie zwracanie uwagi na tematy bezpieczeństwa w projekcie, w swoim zespole. I takim świetnym przykładem jest na przykład praktyka modelowania zagrożeń, gdzie Klasycznie fasylitatorem takiej sesji powinien być właśnie Security Champion. Nie powinna być osoba z APSECU. Może być, ale to raczej powinny być wyjątki. Standard Operating Procedure. taką osobą powinny być właśnie Security Champion. A czemu? Bo jeżeli wyznaczymy pojedyncze osoby w zespołach wytwórczych no to jeśli mamy 30 zespołów wytwórczych no to będziemy mieć 30 Security Championów i każdy zespół będzie miał tą jedną osobę, która jest tą pierwszą linią frontu. w tematach bezpieczeństwa. A jeśli ta osoba będzie miała jakąś rosterkę, no to może pójść już dalej, może popchnąć to do abseku, ale gdzieś ta praca nam się rozmywa, może nie tyle rozmywa, co po prostu rozlewa pomiędzy osobami i jest łatwiej to wszystko po prostu tym zarządzić. Jakie ty masz spojrzenie na… No właśnie na security championów, na to, że są wpisani.
Krzysztof: Żaden program apsekowy tak naprawdę nie może się obejść bez tego elementu. To co Andrzej powiedział to jest absolutnie podstawa. i tak po prostu działa biznes. Bezpieczników jest mniej, deweloperów jest więcej, deweloperzy muszą dowozić, na koniec dnia liczy się feature, a nie znaleziona podatność. Niestety. Albo istety, nie wiem. Nimi oceniać. Ale jeżeli chodzi o praktykę security championów to może się wydawać żłódna, bo te programy buduje się dosyć mozolnie. ale efekty, które one przynoszą w dłuższej perspektywie czasu są naprawdę fajne i wymiarne. Ja tutaj ze swojej perspektywy powiem, że bardzo fajnie rezonuje Security Champion, który jest QAem. który nie jest tak mocno obłożony tą pracą deweloperską i też lgnie niejako do zdobywania troszeczkę innych, niefunkcjonalnych aspektów z testowania, a takim jest właśnie bezpieczeństwo. Więc jeżeli chodzi o tech radar i tutaj ten blip, który zaznaczyli na tym swoim radarze jako Security Champions to jak najbardziej na tak. i odbijam piłeczkę do Ciebie. Andrzej, czy widziałeś naprawdę fajnie zbudowany program, w którym Security Champions grali rolę? Jeżeli tak, to byś mógł streścić, jak taki program wyglądał.
Andrzej: Widziałem, widziałem nawet dwa i chyba podstawą obu była realna inwestycja biznesu, organizacji w tych ludzi. Więc realny jakiś zakup szkoleń. To już nawet nie chodzi o zakup szkoleń, o w ogóle zbudowanie jakiejś ścieżki edukacyjnej. Podejście do tego nie tak, że no dobra to dzisiaj się tym zajmujesz, dodaję ci obowiązków, a nie daję ci… Zamiast zrzucać koło ratunkowe to rzucam ci sztangę. Więc tak to na pewno nie będzie działać. Więc w tych programach, które widziałem, a widziałem dwa takie dość dobrze. od środka, no to to działało, ale sądzę, że głównym elementem było to, że faktycznie organizacja inwestowała w tych ludzi, żeby nabyli te umiejętności. Widziałem też takie programy, w których to słabo funkcjonowało. i tam odwrotnie, tam organizacja nie inwestowała w tych ludzi, raczej byli po prostu wyznaczeni I tyle.
Krzysztof: I biznesowo też się to na koniec dnia spina, bo taniej jest wyszkolić sobie fajnego security championa niż zatrudnić pięciu inżynierów od APSECU.
Andrzej: Tak. Jest tylko jedno ale. Tworzą się pewne problemy. jak sobie wyszkolimy. Security championów. Ale tych problemów tak naprawdę nigdy od nich nie uciekniemy. i jest przecież to może nie tyle powiedzenie, ale myślę, że każdy słyszał o tej rozmowie, gdzie przychodzi HR do szefa, do CEO i mówi, że No kurczę, chcielibyśmy wyszkolić naszą kadrę. No nie, nie mamy pieniążków. No to… Spaliłem, spaliłem ten żart. Ale generalnie chodzi o to, że jeśli ich wyszkolimy, to fajnie, bo otwieramy im opcję. większą, no bo mają większą wartość, no i teraz musimy ich zachęcić, żeby z nami zostali. Ale jeśli ich nie wyszkolimy, to czy tak naprawdę działamy na swoją korzyść? No nie. No bo na koniec dnia chcemy, żeby ludzie, z którymi współpracujemy się rozwijali, a nie stawali w jakimś punkcie i już stali. No chyba, że są tak wysoko. Ale zakładając, że zakładając zwykłych śmiertelników, no to chcemy, żeby po prostu człowiek szedł do przodu, a też takie zwykłe pójście do przodu. Ja sobie nie wyobrażam stać cały czas w miejscu. Myślę, że większość osób w IT jednak chce powiększać swoje umiejętności, czy poszerzać, czy pogłębiać, ale jednak chcą się rozwijać. Jest to taka naturalna chęć ludzi, którzy pracują w IT. Rzadko spotykam się z kimś, kto jest taki mocno toporny i on to najchętniej by już nic nie robił. Tylko już sobie pisał kodzik w tym jednym, ja już nic nie. Nie, raczej ludzie, których spotykam, to chcą się rozwijać. I jeśli im nie umożliwimy takiego rozwoju, to będzie miało to jakieś implikacje typu niezadowolenie z pracy etc. Więc Security Championii i w ogóle zbudowanie takiej jednostki może nam umożliwić fajną ścieżkę jakąś progresji dla przykładowo właśnie dla inżynierów QA. Krzysiek sam byłeś inżynierem QA i twoja organizacja w QA zainwestowała i teraz tak naprawdę czerpie z tego profity. I to są takie długoterminowe profity, bo twoja organizacja zainwestowała w ciebie już kilka lat temu i dość szybko wykazałeś się w swojej nowej roli i od wtedy organizacja czerpie mocne profity, bo na pewno wydałaby dużo więcej pieniążków, jeśli musiałaby kogoś rekrutować z zewnątrz, na pewno kilka rekrutacji byłoby nieprzychylnych, więc gdzieś to zwiększa ogólny koszt. lepiej, lepiej tak naprawdę zainwestować i pomóc ludziom się rozwinąć, szczególnie biorąc pod uwagę, że takie inicjatywy raczej są budowane z ludzi, którzy mają zainteresowanie w tym temacie, więc się nie buduje ich z jakichś randomów. Zdecydowanie,
Krzysztof: a jeżeli słuchacze są zainwestowani budowaniem programów Security Champions to myślę, że w referencjach do tego odcinka podeślemy przynajmniej jeden playbook, który fajnie opisuje jak zacząć, jak wystartować z takim programem i też umożliwia ocenę i to, w jaki sposób podchodzi do progresowania na kolejne poziomy, jeżeli chodzi właśnie o tą praktykę.
Andrzej: I ja w zasadzie wypisałem sobie jeszcze trzy blipy. Pominę dwa, ale jednego nie mogę pominąć. O jednym muszę wspomnieć. Te dwa, o które pominę, one nie są takie stricte security, więc można je pominąć, ale ten jeden nie tylko jest security, ale też po prostu niesie ze sobą jakąś taką nazwijmy to meta lekcję. Mianowicie w TechRadarze można znaleźć coś takiego jak VIS, Vulnerability Impact Scoring System od Zuma. Jest w bakecie ASSESS, czyli żeby ocenić, żeby wykonać jakiś assessment. tego podejścia. WIS jest takim kontrkandydatem dla CVSS i dla EPSS. I nie chodzi mi o samo to, żeby wchodzić teraz i opisywać o na czym polega Vulnerability Impact Scoring System od Zuma, bo nie ma to tak naprawdę znaczenia. Jeżeli kogoś to interesuje to sobie sam przeczyta i zrozumie, bo to nie jest rocket science. Natomiast raczej chodzi mi o to, żeby uwypuklić ten kontekst, że Zauważcie, że nie ma idealnego systemu do oceny podatności, bo skoro organizacje takie jak Zuma, to jest dość duża organizacja, wytwarzają swoje systemy do oceniania podatności, to znaczy, że nie są zadowolone CVSSA. czy z EPSS, bo gdyby były to po prostu użyłyby tego narzędzia. To nie jest tak, że ktoś sobie coś tworzy, bo chce sobie potracić czas. Nie, najczęściej tworzy się jakieś systemy po to, bo nie mogę znaleźć narzędzia, które rozwiązuje mi ten problem na rynku, czy komercyjnie, czy open source’owo. I CVSS i EPSS mają swoje problemy. WIS to jest kolejny kandydat. Żadne z tych narzędzi nie jest idealne. Natomiast dobrze zobaczyć że po prostu nie ma jakiejś jednej fajnej idealnej odpowiedzi do oceniania podatności które się znajduje w naszych systemach i dobrze jest zrobić jakiś research tego co jest dostępne na rynku i wybrać sobie coś co pasuje do nas na tyle na ile się da lub tak jak w przypadku Zuma może nawet stworzyć coś swojego jeśli mamy na to zasoby. Ale nie należy patrzeć na CVSS jako coś, co zostało nam… Dogmat. Tak, jako dogmat. A często gęsto CVSS jest patrzony jako dogmat i jest używany tam, gdzie w zasadzie nie ma za bardzo zasadności użycia CVSS-a.
Krzysztof: Dokładnie. I ta dyskusja na temat zasadności CBSS-a ostatnio nabiera na rozpędzie i tutaj stąd też nowe dziecko od Zooma, czyli Wis. I bardzo fajnie. i polecamy zajrzeć, bo CBSS stał się w pewnym sensie czymś oklepanym i nawet w pewnych dyskusjach i w wątkach, które często czytam jest, aha, okej, znowu dziesiątka, znowu critical.
Andrzej: Właśnie. Coś jest… Something is rotten in the state of Denmark. jeśli wszystkie podatności są na dziesiątkę. Albo jeżeli mamy ich dużo. Bo nie może być tak, że mamy 10 krytików. To w takim wypadku nasza skala jest jakaś dziwna. Tak z prawdopodobieństwa. Jeśli nam wychodzi co tydzień jakiś krytyk to coś tu jest nie tak. Bo nie może być tak, że wszystkie są krytyczne. Krytyczne to krytyczna. Lock4J był krytyczny. No to jeśli porównam jakąś podatność, nawet tą co ostatnio listowaliśmy w poprzednich odcinkach i porównam ją do LOK4J to jest takie no kurczę, no nie, LOK4J to była dziesiątka, to faktycznie był critic, a sporo podatności, które z CVSS-a wychodzą na krytyczne wcale krytyczne nie są.
Krzysztof: Tak.
Andrzej: Może są w odosobnieniu jako tylko ona, ale w szerszym ekosystemie one nie są krytyczne, a LOK4J był krytyczny w szerszym ekosystemie.
Krzysztof: Dokładnie, dokładnie tak.
Andrzej: Krzysiek, przechodzimy do kolejnego.
Krzysztof: GitHub. zmaga się od kilku miesięcy z powodzą, z zalewem potężnym, potopem repozytoriów, które są złośliwe. Atakujący klonują, forkują legitne repozytoria ciszące się dosyć dużą popularnością, między innymi te dotyczące Discorda czy innych kanałów, narzędzi takich dyskusyjnych. znaczy narzędzi, które orbitują gdzieś dookoła tych produktów takich do dyskusji. Forkują te repozytoria, dodają złośliwy kod, oczywiście go obfuskując. Cały proces mają zautomatyzowany, więc są w stanie w krótkiej jednostce czasu, bo tutaj mówimy o dosłownie kilku miesiącach, stworzyć tych nowych repozytoriów dosyć bardzo dużo. i te repozytoria po prostu pushują pod własnymi kontami na GitHub’y z dokładnie taką samą nazwą, więc tutaj nawet nie wchodzimy w jakieś sztuczki związane z typoscootingiem czy tego typu praktykami. GitHub oczywiście stara się na bieżąco i dąży do tego, żeby usuwać te repozytoria, które podszywają się pod te legitne. I teraz ten atak, o którym mówimy, jego wolumen oscyluje w granicach 100 tysięcy takich repozytoriów, które zostały wypuszczowane do GitHuba, Jest to absolutnie, jeżeli chodzi o skalę, bezprecedensowa kampania przeprowadzana na GitHubie. I tutaj fajny taki efekt, który… Ja lubię takie smaczki w tych kampaniach i lubię się z nich czegoś nauczyć, bo sama technika, o której tutaj mówię, że klonujemy repozytorium, jakieś legitne repozytorium, dodajemy do niego złośliwy kod i potem znowu pushujemy go pod tą samą nazwą, bądź nazwą delikatnie zmienioną używając typoscodingu, nie jest niczym nowym, znamy to, ale to co tutaj zostało fajnie wykorzystane, to taki efekt social proof, w którym ci złośliwi gracze gwiazdkowali sobie te repozytoria i gwiazdkowali je do takich poziomów, że wchodząc na te fałszywe repozytorium, miałeś wrażenie, że tutaj wszystko gra. To było wszystko ładnie posprzątane, naprawdę wypolerowane te repozytorium na cacy, nic tylko pobierać. I poprzednio w takich atakach stosowano również takie myki, że dołączano w tych repozytoriach zależności, które były złośliwe. Tutaj wystarczyła sama obfuskacja, same zależności były okej. No i to, co powtórzę jeszcze raz, to co robi wrażenie, to na pewno ta skala nie 100 tysięcy repozytoriów, które zostały wypuszczone do GitHuba. Promocja tych repozytoriów to był po prostu głównie fora internetowa, a jeżeli chodzi o Discorda to same kanały Discordowe, więc tak to się odbywało, jeżeli chodzi o dystrybucję tych repozytoriów wśród ich potencjalnych użytkowników.
Andrzej: Mi się od razu tutaj narzuca pytanie, zdecydowanie dwa. Pierwsze, czy narzędzia takie jak OpenSSF Scorecard dla projektu, bo on potrafi ocenić projekt pod kątem kilku różnych kilku, kilkunastu markerów, takich jak właśnie mniej więcej jakieś gwiazdki na GitHubie, etc. Czy takie narzędzie byłoby w stanie wykryć, że to repository jest malicious? Jak myślisz?
Krzysztof: Pewnie mówiąc o tej heurystyce związanej z gwiazdkami, gdzie tam robisz sobie ten starbombing czy stargazing, jak zwał tak zwał, to pewnie nie, ale OpenSSF ma kilkanaście pewnych markerów, tak jak wspomniałeś, które mogą wskazywać na to, że coś z tym repozytorium nie gra i między innymi jednym z takich markerów, jeżeli się nie mylę, jest to ile to repozytorium żyje. Więc to krótkie żyjące repozytoria, czas życia tego repozytorium może wskazywać na to, że coś tu jednak nie gra.
Andrzej: A teraz drugie pytanie, ono już się łączy z tym pierwszym, natomiast jak już mówiłem przy XZ o tym, o czym wspomniał Daniel Miesler, czyli o AI-u, to tutaj też automatycznie się nasuwa, czy AI byłby w stanie wykryć, że to repozytorium jest złośliwe. Czyli już nawet nie używając OpenSSF z Call Card, tylko po prostu powiedzieć GPT, patrz tu masz link do tego repo, Weź mi tam ocen, czy ono jest złośliwe czy nie. I czy byłby w stanie wykryć jakieś markery i ocenić to.
Krzysztof: Bardzo ciekawe. Ja myślę, że z pewnością. To jest dla dużego modelu językowego, wydaje mi się, że to powinno być proste zadanie.
Andrzej: Też mi się tak wydaje. Chciałbym zobaczyć taki test.
Krzysztof: Szczególnie bazując na tych heurystykach, które widzimy w OpenSSF-ie, tylko z wykorzystaniem LLM-a.
Andrzej: Tak mi się właśnie też wszedł w kierunku, że raczej powinien sobie z tym poradzić i już Może właśnie nie tyle sam taki goły GPT z linkiem, że patrz weź tu coś mi powiedz, wywróć z fusów, ale jeśli byśmy połączyli OpenSSF z Scorecard plus LLM albo gdybyśmy mieli LLM, który potrafi korzystać ze Scorecarda, przeanalizować jego wynik, to myślę, że skuteczność wykrywania byłaby dość duża, ale chętnie, chętnie zobaczyłbym to na jakichś konkretnych danych. Pomysł na research dla naszych słuchaczy.
Krzysztof: Dokładnie.
Andrzej: Taki research, który można opublicznić nawet po angielsku i będą was pisali. Więc zachęcam. Ale też wspomniałeś o, znaczy raz o całym tym ataku. nie wiem czy nazwać to atakiem na GitHuba, ale operacją.
Krzysztof: Taką kampanią. Taka kampania.
Andrzej: No to i tam też wspomniałeś o typosquatingu. Ja też mam taki jeden case dokładnie związany z typosquatingiem. Ostatnio na Pi PI-u.
Krzysztof: Bardzo ładnie.
Andrzej: Tak, nie na Pi-Pi tylko Pi-PI. Na Pi-PI była tak właśnie typosquatting, taka kampania. Typosquatting dla przypomnienia dla naszych słuchaczy. to jest sytuacja, w której mamy nazwę pakietu, która imituje jakiś legitny pakiet. Przykładowo dodając jakąś dodatkową literkę albo na przykład jest zapisany inaczej wyraz. przykładowo mamy kolor po amerykańsku jest bez u a po brytyjsku jest z u. więc tworząc taką takie typo, możemy bazować, że pewien podzbiór programistów wpisze to, popełni ten błąd, no i dociągnie nie ten pakiet, który ma. Ten atak jest wzorowany na czymś, co kiedyś było utylizowane w atakach na zwykłych użytkowników domain squatting, czyli na przykład gogle, ale z trzema o, zamiast dwóch. I była taka kampania właśnie na IPI ostatnio pod koniec marca i to co mnie tam tak naprawdę zainteresowało to nie jest skala, bo tam było tam kilkaset tych pakietów, więc to może nie jest jakoś super duże, ale to co mnie zainteresowało, że to było na tyle dużo czyli skala była na tyle duża, że w zasadzie PyPI musiał chwilowo zablokować możliwość tworzenia nowych projektów. Więc w ogóle to zablokowali, no i oczywiście poradzili sobie z problemem, rozwiązali, ale to, że musieli powziąć taką decyzję, że musieli to zrobić, no to już jest ciekawe. Czyli nie mają jakichś tych mechanizmów, które nie wiem, automatycznie coś z tym robią, więc to jest ciekawe. No i….
Krzysztof: Dla jasności Andrzej, nie można było dodawać nowych pakietów, ale sama usługa działała.
Andrzej: O ile kojarzę, sama usługa działała, czyli ja jako developer mogłem sobie ściągnąć pakiety, które już istniały, ale nie mogłem stworzyć sobie nowego pakietu. na PyPI.
Krzysztof: To by miało sens, bo byśmy wszyscy o tym strzeli, gdyby nie dało się.
Andrzej: Tak, tak, dokładnie. Też mi się tak wydaje, że byśmy coś tam usłyszeli.
Krzysztof: Jakieś pipelines by zapłakały trochę.
Andrzej: Natomiast jeszcze odniosę się do tego, o czym już właśnie dzisiaj wspomniałeś tak mimochodem. Dlaczego te kampanie na PyPI się dzieją? Dlaczego te ataki na PyPI się dzieją? Wraz ze wzrostem AI ekosystem Pythonowy, no nie chciałbym powiedzieć, że przeżywa boom, bo Python w zasadzie jest dość popularny od zawsze, ale na pewno jest wzmożona aktywność od tych dwóch lat, odkąd mamy boom na AI i LLM-y. No i oczywiście tam, gdzie jest krew, tam się zlatują rekiny, czyli nasi hakerzy, no i tam są przeprowadzane akcje i ci ludzie są atakowani. No czemu? bo mamy większe prawdopodobieństwo, że ktoś po prostu, ktoś będzie naszą ofiarą. Im większe prawdopodobieństwo, tym mniejszy koszt, a im mniejszy koszt, tym lepiej, bo na koniec dnia to jest po prostu biznes. Dobra Krzychu, przechodzimy do Twojego ostatniego, a potem przejdziemy do mojego. Okej.
Krzysztof: Ja mam też taką perełkę, o której nie było głośno, ale…
Andrzej: Ja o niej nie słyszałem.
Krzysztof: Nie słyszałeś, okej. To fajnie. To mogę się tutaj czymś wykazać. Słuchajcie, atak, który został nazwany jako denial of wallet, nie nazwany akurat w tym konkretnym przypadku, o tym denial of wallet już od pewnego czasu jest może nie głośno, ale mówi się głównie w kontekście środowisk cloudowych, denial of wallet, czyli nabijanie po prostu dosyć wysokich rachunków, a jak wiemy dostawcy usług chmurowych liczą za swoje usługi jak za zboże. powiedzmy to, dajmy sobie grudek. I w tym przypadku chodziło o S3. S3 kojarzymy storage na dane, na pliki. I tutaj badacze wykorzystali pewną ciekawą właściwość, ponieważ Kalkulując koszty utrzymania takiej S3 tam jest kilka co najmniej czynników, które trzeba wziąć pod uwagę, ale jednym z tych czynników jest transfer wychodzący. I okazało się, że jeżeli ja będę serwować na swojej S3 dosyć duże pliki, powiedzmy takie, które mają 2, 3, 5, 10 GB, i ktoś zacznie je pobierać, ale przerwie to pobieranie po otrzymaniu powiedzmy dwóch gigabajtów danych, to jeżeli ten plik ważył te pięć gigabajtów pierwotnie, znaczy tak naprawdę ważył te pięć gigabajtów, ale przerwaliśmy pobieranie po dwóch, no to Amazon szczodrzyje nas za pięć.
Andrzej: A kto by się spodziewał?
Krzysztof: I tak jak już myślisz Andrzej, tutaj zaczęły się te myśli i badania naszych researcherów intensyfikować i udało im się wycisnąć z 3 terabajtów koszt taki, jakby faktycznie pobrali 130 terabajtów, więc z 300 dolarów zrobiło się 13 tysięcy dolarów. Więc przelicznik, przelicznik naprawdę, naprawdę dobry. Dobra wiadomość jest taka dla naszych słuchaczy, którzy się martwią i mają bakety na S3, że tak naprawdę dotyczy to większości plików, które są duże, czyli plików, które mają jeden bądź dwa gigabajty i w górę. Ale tutaj badacze wskazują, że jest cały szereg publicznych bakietów, które odnoszą się do jednostek organizacji publicznych takich jak szpitale czy takie jednostki badawcze z zakresu bioinformatyki, gdzie te dane, które są tam przytrzymywane, ważą naprawdę sporo, a te bakety są publiczne z racji jakby tego naukowego podejścia i udostępniania tej wiedzy szerzej. Więc tutaj wskazuję, że tego typu jednostki mogą być po prostu atakowane. tak naprawdę dla fanu, Gdzie jest tutaj, gdzie jest tutaj haczyk, bo o ile mówimy np. o denial of wallet, który jest konsekwencją tego, że ktoś ci odpalił bardzo dużą EC2 i kopie na niej krypto zarabiając na tym, że te krypto wykopał, no to gdzieś tam efekt ma sens. To jest gdzieś tam. efekt jest pośredni z tym denial of wallet. To nie był jego cel. Ale tutaj, jak myślisz? Czysta,
Andrzej: czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta, czysta,
Krzysztof: czysta, czysta. Ciekawe jest to, że Amazon w swojej dokumentacji bezpośrednio sam się nie chwali tym zachowaniem, dlaczego w taki sposób nabija ten transfer.
Andrzej: Nie wiem, choć się domyślam.
Krzysztof: I mówi po prostu w kontekście bezpieczeństwa baketu, że w zasadzie to większość powinna być prywatna, tak już bardzo to streszczając, a jeżeli chcecie, żeby była publiczna, no to na waszą wyłączną odpowiedzialność. Musicie wiedzieć, co robicie.
Andrzej: No i niczego innego Atamazona się nie spodziewałem. Dokładnie takie odpowiedzi. No i teraz ja mam ostatnią już taką wisienkę na torcie. Tu dość szybko, bo Gdzieś tam wiesz na jakichś socialach jednych czy drugich. wpadło mi ostatnio na takie jakieś opisy tej podatności GoFetchFail. To jest podatność, która dotyczy procesorów aplowskich tych M1, M2. Generalnie architektury ARM, ale tej, która egzystuje w chipach. Apple. I to, co mnie uderzyło w tym opisywaniu, w tym robieniu hype’u tej podatności, Boże, Jezus Maria, co tu się dzieje, to to, że tak naprawdę nic się nie dzieje, że jest to typowy food sianie paniki, budowanie hype’u, a tak naprawdę żaden problem to nie jest. Wiadomo, że lepiej byłoby nie mieć tej podatności niż ją mieć, to jak ze wszystkim, ale porównywanie albo mówienie, w ogóle zestawianie tego gdzieś z Meltdownem i Spectre, które dotyczyły innej architektury i przede wszystkim dotyczyły procesorów, które są wykorzystywane w środowiska serwerowych. I przede wszystkim do wirtualizacji, no to gdzieś jest po prostu nie na miejscu, bo to są porównywanie jabłek i pomarańczy, bo ja sobie mogę mieć tą podatność na swoim PC i nawet jeżeli ktoś się wyeksploituje, no to co, to mnie wyeksploituje i tyle. To będzie atak ukierunkowany, on musi wydać odpowiednie pieniądze etc. a zupełnie inaczej, jeśli ja mogę po prostu wykupić sobie instancję na właśnie AWS powiedzmy, EC2 i zacząć dobijać się do gości, którzy są ze mną na tej instancji, tylko w jakimś innym, w tym samym hypervisorze, ale w innej VN-ce. I tam był tak naprawdę w tym problem, nie w tym, że mieliśmy te podatności w procesorach, tylko gdzie te procesory były wykorzystywane, w środowiskach serwerowych. Na chwilę obecną, o ile dobrze kojarzę, to jeszcze nie ma farm serwerowych stawianych na M1, M2 ani nawet M3. Być może w przyszłości będą. Kto wie, może w Apple są, ale na pewno nie są ogólnozastępne, więc całość jest po prostu dużo, dużo mniejszym problemem. Jest to typowy hype, taki bezpiecznikowy typu Stand hacking, tak to się ładnie nazywa. Mnie zawsze to trochę kłuje w serduszko, gotuje się jak coś takiego, czy tam w sumie jestem jak na tym memie. Dokładnie tak, jak czytam albo słucham o tego typu programach.
Krzysztof: I to się też fajnie roluje z naszym pierwszym tematem, gdzie był wykorzystywany XZ i te wszystkie rzeczy. Mówimy tutaj o systemach głównie stosowanych w serwerach, a nie na komputerach personalnych.
Andrzej: Pięknie to klamrą zamknąłeś. Dokładnie tak, bo w tym pierwszym problemie, który dzisiaj opisywaliśmy w XZ sedno nie leży w samej tej podatności, która została wprowadzona. Nawet nie w tym backdoorze, który był można powiedzieć bardzo ładny, elegancki. Sedno problemu leży w tym, gdzie to jest wykorzystywane. To jest sedno problemu i tak samo tutaj. Sedno problemu jest to, gdzie to jest wykorzystywane, co czyni ten problem tak naprawdę znikomym, a w przypadku XZ bardzo dużym. Więc kontekst ma znaczenie. Dobra Krzychu, no to chyba na dzisiaj koniec.
Krzysztof: Tak i chyba małe ogłoszenie, że teraz będziemy się spotykać częściej.
Andrzej: Tak, będziemy się spotykać częściej.
Krzysztof: Więc odcinki będą może krótsze.
Andrzej: Może będą krótsze. Dzisiaj się spotkaliśmy na miejscu, więc nie mogliśmy sobie odmówić pogadanki, ale kolejne odcinki będziemy już robić zapewne zdalnie. Będą częściej i jakość produkcji chyba będzie lepsza.
Krzysztof: Niech ocenią sami.
Andrzej: Właśnie, niech słuchacze ocenią. Dajcie znać i w tym, i w kolejnych odcinkach, jak wam się podobało. No i czy macie też jakieś konkretne pytania do tego, o czym mówiliśmy. Nie muszą być pytania, mogą być uwagi. Chętnie się do tego odniesiemy. Uderzajcie osobiście albo uderzajcie pod postami. Będziemy się odnosić, będziemy wyjaśniać, będziemy się kłócić.
Krzysztof: Dokładnie. A wszystkim, o czym dzisiaj rozmawialiśmy, oczywiście zostawimy do tego referencję. No i w tym momencie pozostaje nam tylko się pożegnać i powiedzieć do zobaczenia. Więc z mojej strony do zobaczenia. Dzięki wielkie za spędzenie z nami czasu. Dzięki Andrzej.
Andrzej: Dzięki Krzychu. Do zobaczenia.