W tym wakacyjnym, skróconym odcinku zagłębiamy się w techniczne detale związane z wyciekami sekretów i podatnościami w oprogramowaniu. Zaczynamy od regresyjnego błędu w OpenSSH (CVE-2024-6387), znalezionego przez zespół Qualys, który umożliwił zdalne wykonanie kodu. Analizujemy, dlaczego SSH uchodzi za bardzo bezpieczne oprogramowanie i jak trudno wyeksploatować tę podatność na systemach 64-bitowych — a także dlaczego fragmentacja ekosystemu Linux działa na korzyść obrońców, utrudniając pisanie uniwersalnych exploitów. Po drodze sporo miejsca poświęcamy szumowi medialnemu wokół podatności i potrzebie kontekstowej oceny ryzyka zamiast ulegania panice.

Drugim kluczowym wątkiem są „Sekrety Widmo” — research Aqua Security pokazujący, że narzędzia do wykrywania sekretów (jak TruffleHog czy GitLeaks) mogą przeoczyć dane, jeśli repozytorium jest klonowane bez przełącznika --mirror. Badacze odkryli, że klonowanie lustrzane pozwala znaleźć o około 18% więcej sekretów, m.in. w projektach takich jak Firefox czy Mercari. Omawiamy też problem cachowania widoków commitów przez platformy SCM (GitHub i Bitbucket), który pozwala znaleźć sekrety po zaledwie czterech początkowych znakach hasha commita. Na koniec poruszamy kontrowersje wokół proponowanej cenzury wiadomości w Unii Europejskiej, grożącej naruszeniem szyfrowania end-to-end w imię bezpieczeństwa dzieci.

Transkrypcja

Pełna transkrypcja odcinka

KrzysztofWitamy was bardzo serdecznie w tym pierwszym wakacyjnym odcinku Bezpieczny Kod Podcast. Dzisiaj chyba Andrzej w ekspresowym tempie, bo skracamy i mamy cztery rzeczy, którymi chcemy się z wami podzielić. Zaczynaliśmy bodajże od dziesięciu. Było po pięć na głowę w pierwszym odcinku i te odcinki trwały po dwie godziny. Nie żeby były mniej wartościowe, ale szanujemy Was czas i wiemy też, że szczególnie w okresie wakacyjnym macie na głowie inne rzeczy. Cześć Andrzej, no i chyba nie przedłużając, no to wskakujmy w pierwsze znalezisko.

AndrzejJasne, Krzysiek. jeszcze dodam, że te pierwsze odcinki to były też co miesiąc, więc łatwiej było mówić tyle rzeczy. Teraz tę kadencję mamy trochę krótszą, co dwa tygodnie. No i wiadomo, w cyber czy ogólnie w techu dzieje się w zasadzie tyle rzeczy, że spokojnie byśmy znaleźli nawet po 10 na głowę, ale nie chodzi o to, żeby rozciągać, tylko żeby wybrać to, co było ciekawsze w feedach, które obserwujemy. I tutaj myślę, że bez problemu się ze mną zgodzisz. Jedną z najciekawszych rzeczy, przynajmniej ostatnich kilku dni, jest podatność w OpenSSH regression bug, to znaczy CVE-2024-6387. które zostało znalezione przez członków zespołu deweloperskiego Qualys. I poprawnie jeśli się mylę, wydaje mi się, że w pierwszym odcinku naszego podcastu mówiliśmy również, zahaczaliśmy przynajmniej, o właśnie członka zespołu Exploit Developments z Qualys. W pierwszym czy w drugim?

KrzysztofWydaje mi się, że w pierwszym. Nie wiem, czy mówimy o tej samej osobie, ale pamiętam, że mówiłeś, że jest turbo kozakiem, jeżeli chodzi o te tematy. nie jest tak szerzej znanym, nie obnosi się ze swoim skillsetem, że tak powiem.

AndrzejTak, to na pewno jest to sama osoba, bo to widać po prostu po stylu pisania advisory i wydaje mi się, tak jak chyba wtedy to ująłem, że zespół X-Play Development Qualis N równa się 1, w zasadzie ten gość. I to widać potem jak pisane są te advisory, ale widać też po targetach, które są wybierane. Te targety zawsze oscylują wokół pakietów, które są szeroko używane, ale w ekosystemie linuxowym, włącznie z jądrem linuxa i raczej jest zero wychodzenia poza tą działkę, czyli ktoś musi świetnie umieć czytać i rozumieć język C. I ktoś musi mieć czas, żeby go poświęcić na czytanie programów, które często gęsto są pisane właśnie w C, jeśli mówimy o przykładowo SSH, czy innych aplikacjach, które są bardzo szeroko używane w ekosystemie Linuxa, takich systemowych aplikacjach. Ale wracając do tej podatności regression, tutaj jest tak naprawdę kilka ciekawych wątków. Pierwszy to już niejako wynika z samej nazwy, czyli ta podatność powstała w wyniku regresji. I to jest ciekawe. dlatego, że często że jest to częsty przypadek, przynajmniej w takim normalnym software development, jeżeli mówimy o cyklu wytwarzania oprogramowania. Czemu? Dlatego, że jeśli mamy podatności, to one często nie są traktowane tak jak bugi, o czym zresztą mówiliśmy z Maćkiem Markiewiczem, obecnie z Ignita, gdzie właśnie podatności nie są traktowane jak bugi, przez co nie ma np. pisanych testów regresyjnych, żeby uniknąć wprowadzania tych samych problemów do kodu. Jeśli nie ma takich testów, to bardzo łatwo jest podatność wyprowadzić, a potem ją znowu wprowadzić, co oczywiście dałoby się rozwiązać w momencie, gdybyśmy korzystali z analizy statycznej i dla każdego takiego case’u, który wyprowadzamy, pisali sobie od razu test, ale wtedy oczywiście narzędzie. do analizy statycznej musi nam to pozwalać robić w, nazwijmy to, prosty sposób. No bo jeśli mocno to utrudnia albo w ogóle uniemożliwia, no to nikt tego robić nie będzie. I takim narzędziem… Jakie narzędzie byś tutaj zaproponował, Krzysiek?

KrzysztofPomyślmy… Wydaje mi się, że Semgrep.

AndrzejDokładnie, nasz ukochany Semgrep. Semgrep pozwala na takie coś i jest to łatwe, bo oferuje swojego DSL-a. Można byłoby to zaimplementować w tym konkretnym przypadku, chociaż w tym konkretnym przypadku niekoniecznie miałoby to sens albo rację bytu, dlatego że SSH samo z siebie jest bardzo, bardzo bezpieczny. To jest jeden z najbezpieczniej napisanych kodów w C. Tam jest bardzo mało podatności na przestrzeni lat i jeśli ktoś nie tylko znajdzie podatność, ale jeszcze ta podatność będzie eksploitowalna, no to w zasadzie w takim dość wąskim kręgu badaczy, którzy zajmują się bezpieczeństwem niskopoziomowym i eksploitacją, no ma spore uznanie w tym kręgu, bo naprawdę jest trudno znaleźć nie tylko eksploitowalną podatność, ale jeszcze ją aktywnie wyeksploitować, co w tym przypadku się udało, ale do tego zaraz jeszcze przejdę. Dlatego, że to o czym powiedziałem przed chwilą, że SSH jest dość bezpiecznie napisany, jest naprawdę świetnym przykładem bezpiecznie napisanego kodu w C, co dla niektórych, nawet dla mnie, brzmi trochę jak oksymoron. Bezpieczny kod i C, jakoś to ze sobą nie idzie w parze. Ale to na bok, bo autor z zespołu Qualysa też to wypunktował na samym początku tego advisory, że kod OpenSSH jest naprawdę, jest naprawdę superbezpieczny i znalezienie czegoś tam to jest bardzo, bardzo, bardzo rzadko się takie coś udaje. i jeszcze żeby się udało to potem wyeksploitować, no to muszą się, kurczę, wszystkie gwiazdy na niebie ułożyć. No i tak się stało w tym przypadku, ale ale z dość dużą gwiazdką. Natomiast zanim przejdę do tej gwiazdki, jeszcze wspomnę, że ta regresja tej podatności weszła tak, że była względem innej podatności, która została załatana w 2006 roku. A czemu o tym wspominam? Bo tamta podatność, to były złote lata exploit development i vulnerability researchu, wszystko było łatwe. Została znaleziona przez Marka Douda. Mark Doud to jest taka jedna z legend Vulnerability Developmentu. On jest jednym z współautorów i jednym z głównych autorów Taosy, czyli Biblii dla Bezpieczeństwa Aplikacji. The Art of Software Security Assessment. Taka bardzo, bardzo gruba książka, Gdzieś tam za mną leży świetna książka. On jest jednym ze współautorów i w 2006 roku zgłosił jedną podatność do OpenSSH. O ile dobrze kojarzę, to w tym konkretnym advisory z Qualisa autor jasno wspomina, że wtedy nie udało się jej wyeksploitować i nie było żadnego przynajmniej publicznego kodu. który pozwalałby ją wyeksploatować, ona też tam nie prowadziła do Remote Code Execution, natomiast tutaj prowadzi do Remote Code Execution, ale w dalszym ciągu jest ją trudno wyeksploatować, natomiast udało się to autorowi Qualys, ale i tutaj przychodzę do tej gwiazdki, o której przed chwilą wspominałem, Ale, z dość dużym ale, bo nie udało się tego zrobić na systemie 64-bitowym, tylko na systemie 32-bitowym. To jest duże ułatwienie, bo autor przeszedł, autor miał pewną strategię na pokazanie, że ten problem da się faktycznie wykorzystać. Czyli da się nie tylko strigerować samopodatność, ale da się ją wyeksploatować w ten sposób, żeby wykonać zdalnie kod. No a jeżeli możemy wykonać zdalnie kod w OpenSSH, które z założenia ma słuchać na porcję. tak, ma nas usłuchiwać na porcie i ma być otwarte dla odbiorców z zewnątrz, no to jesteśmy w stanie wejść do systemu, no a potem to już nasza wyobraźnia i no może też trochę skilla, czy uda nam się podnieść nasze uprawnienia, ale jeśli by się udało, no to oczywiście kończymy narucie i możemy lecieć do dalszych systemów w danej, z tego konkretnego hosta. Natomiast autor przyjął tutaj pewną taktykę, strategię eksploatacji i nie zaczął, a czemu musiał przyjąć taką strategię? W ogóle jakąkolwiek, dlatego że obecnie systemy operacyjne i aplikacje, które w nich działają, nie da się ich tak łatwo wyeksploatować. Mamy kilka różnych, w chwili obecnej są nawet kilkanaście mechanizmów, które zabezpieczają aplikacje, ale też kod systemowy przed przed wyeksploatowaniem. Jednymi z głównych mechanizmów jest tutaj ASLR i NX bit. NX czyli non-executable bit, w Windowsach to się nazywa DEP, Data Execution Prevention. nie pozwala na wykonywanie, albo inaczej, pewne obszary pamięci, a aplikacja system jest w stanie oznaczyć na niewykonywalne. Czyli nawet jeśli uda nam się napisać adres powrotny, to nie jesteśmy w stanie trafić w nasz shellcode, dlatego że będzie on w obszarze pamięci, którego procesor nie będzie w stanie wykonać. Będzie w stanie przyczytać, ale nie będzie w stanie wykonać. Więc kawałki pamięci mogą mieć read, write i execute. By the way, tak jak pliki w systemie Unixowym. Ale ASLR z kolei randomizuje pamięć, czyli za każdym razem musielibyśmy podać inny adres dynamicznie, w który mamy się wstrzelić. I oczywiście jeden i drugi mechanizm. ma swoje problemy, da się go obejść, ale znowu podwyższa to poprzeczkę, bo nie jest to tak łatwe jak kiedyś, gdzie nie było tych mechanizmów. To było lata, lata, lata temu. I autor tutaj tego advisory wziął taką taktykę, żeby pokonać te mechanizmy. Najpierw, najpierw postanowił wyeksploitować bardzo stare, bardzo stare OpenSSH z Debiana tam chyba wiele, wiele wersji temu. OpenSSH było w wersji 3.4, więc to było naprawdę dawno temu, to było nawet jeszcze przed tą wersją poprawioną już z 2006 roku, więc to były prawie 20 lat temu. Wziął ją i udało mu się wyeksploatować, natomiast to co jest tutaj ważne, że potrzebował około 10 tysięcy prób, żeby to wyeksploatować, co końcem końców, przy takim defaultowym założeniu, że mamy 10 connections z OpenSSH, na bodajże 10 minut, no to wyeksploatowanie zajęło mu tydzień. To całkiem sporo czasu. Nie tylko sporo czasu, ale jeszcze jest to dość głośne, bo cały czas z jakiegoś jednego hosta nam leci ruch. Byłoby to dość głośne. Następnie podwyższył sobie poprzeczkę i przeszedł do trochę nowszej wersji OpenSSH, ale dalej na systemie 32-bitowym. I tutaj potrzebował już od 1 do 2 dni on average, więc to są średnie, na wyeksploatowanie z sukcesem tej podatności. I w końcu oczywiście po drodze uczył się. uczył się, czyli niejako eksploitując, obserwował pewne zachowania, które potem mógł wykorzystać w exploicie, żeby dla przykładu skrócić czas. Więc jest to dość sprytna taktyka, żeby nie od razu rzucać się na najnowszy target, ale przejść do starych. i w dobie działania, w dobie pisania takiego exploita będziemy się uczyć nowych lekcji i te lekcje pozwolą nam poprawiać ten exploit, dzięki czemu możemy rozwiązać problemy, z którymi byśmy sobie nie poradzili, gdybyśmy od razu się rzucili na głęboką wodę. I w tym kolejnym przykładzie już eksploitował nowe SSH, to było już w wersji 9.2, więc całkiem nowe. I tutaj potrzebował coś około 6-8 godzin on average, żeby dostać remote shell, czyli poniżej jednego dnia roboczego, dość szybko. ale w dalszym ciągu, w dalszym ciągu mówimy o systemach 32-bitowych, więc nasi odbiorcy raczej zdają sobie sprawę, że w chwili obecnej serwery raczej nie są 32-bitowe, raczej są 64-bitowe, a w przypadku systemów 64-bitowych ta przestrzeń adresów, którą musimy zgadnąć w momencie, gdy chcemy pokonać ASLR, czyli address space layout randomization, No, się zwiększa. I to się nie zwiększa dwukrotnie, jak mogłoby sugerować przejście z 32 na 64, tylko zwiększa się wykładniczo, bo mówimy tutaj o potęgach. Oczywiście, tutaj jest dość duża gwiazdka, dlatego że systemy 64-bitowe i tak nie korzystają z Pełnej przestrzeni adresów pamięci. to było za dużo natomiast ona jest i tak względnie dużo dużo dużo większa niż w systemie 32 bitowym. i tutaj autorowi nie udało się wyeksploatować tej podatności sukcesem. ale, a przynajmniej pisze, że mu się nie udało, natomiast napisał, że strzela, że prawdopodobnie gdyby dalej to ciągnął, plus do tego zauważył pewne dodatkowe prymitywy, to być może udałoby mu się to zrobić pomiędzy jednym dniem roboczym, a tym jednym tygodniem, czyli pomiędzy jeden a siedem dni. Natomiast w końcu jasno nie stwierdził, że udało mu się to zrobić, więc nie ma powodów, żeby twierdzić, że że jest takie coś możliwe. ale bo tutaj wymieniam to wszystko bo to jest prowadzę do jednego ważnego wniosku. jako dodatkowy side note autor dodał że Ubuntu 24.04 czyli nowym long term release systemu buntowego w ogóle jest to nie eksploatowany dlatego że Ubuntu tam korzysta z. z trochę innego sygnału, który puszcza do SSH, przez co ten sygnał nie triggeruje tego kawałka kodu w SSH i końcem końców nie jest to eksploatowane, czyli w najnowszym Ubuntu LTS jest to nieeksploatowane. Ogólny wniosek jaki należałoby z tą wyciągnąć to to, że tego typu podatności w systemie linuxowym, który jest jednak dość mocno pofragmentowany, on nie jest taki tak jednorodny jak system powiedzmy Windowsa czy macOSa, które są dość jednorodne. Tutaj macOS wiedzie Prym. Natomiast w Linuxie jest wiele różnych dystrybucji, jest wiele różnych króczków, smaczków małych, które się różnią pomiędzy tymi dystrybucjami, więc napisanie jakiegoś pojedynczego exploita na tą podatność, potrafiłby poradzić sobie z wszystkimi głównymi nawet dystrybucjami, które są używane i jeszcze z wszystkimi wariacjami OpenSSH, które mogą być wykorzystywane w tych dystrybucjach, byłoby po prostu dużym problemem i zająłby dużo czasu, więc niejako ta fragmentacja ekosystemu niejako gra na naszą korzyść, jeśli zajmujemy się zabezpieczaniem, dlatego że nie jest tak łatwo napisać jednego exploita, który weksplorowałby wszystkie konfiguracje, w jakich może istnieć dana usługa, dany serwis, dany demon. Więc tutaj fragmentacja gra na naszą korzyść, a na niekorzyść atakujących. Natomiast wracamy do jednego wątku, o którym wspominałem w poprzednich odcinkach podcastu. Krzysiek, jak ty na to patrzysz? Nie chodzi mi nawet o samą tę podatność, ale na fut, który był wokół niej. Zaobserwowałeś wzmożoną aktywność ludzi na LinkedInie, krzyczących o tej podatności, czy nie?

KrzysztofO dziwo nie. Nie widziałem, żeby to był temat, który gdzieś tam podniósł wrzawę i na moim feedzie na social mediach pokazywał się w topce. Wydaje mi się, że głównie z racji niezrozumienia tego tematu i tego, jak duży nakład pracy relatywnie trzeba poświęcić, aby to przeczytać i aby faktycznie to zrozumieć i chcieć się tym pochwalić. Jednak to, o czym mówiliśmy poprzednio, było dosyć łatwym kąskiem dla osób, które chcą krzyczeć, a nie chcą do końca rozumieć, o czym mówią. Natomiast to co mi się podoba z tej historii, to o czym wspomniałeś i jej dłojakość, bo z jednej strony czego nas uczy ta historia, nas jako deweloperów, jako osoby które zajmują się wytwarzaniem oprogramowania, To jest to, że faktycznie piszemy testy regresji do aspektów funkcjonalnych naszej aplikacji. Chcemy za każdym razem sprawdzić, czy jesteśmy w stanie przywrócić hasło w aplikacji, czy jesteśmy w stanie wykonać jakąś funkcjonalną operację. Jeżeli mówimy o takich niefunkcjonalnych aspektach, to ta regresja gdzieś jest dalsza. Trend pisania testów egresyjnych w bezpieczeństwie to jest coś, co dopiero raczkuje, a w naszym poletku praktycznie nie istnieje.

AndrzejTotalnie, totalnie nie istnieje. Co jest jeszcze bardziej przykre, w ogóle nie istnieje nawet konceptu. Ja o tym mówię już od długiego czasu, to się nazywa Variant Analysis i do tej pory nie spotkałem ani jednej osoby, która by w ogóle rozumiała, co mówię. Mówię o bezpiecznikach, bo oczywiście jak powiem to programiście czy testerowi, to łapią bardzo szybko. Oczywiście, że powinniśmy takie coś robić. To nie jest rocket science. Każdy, kto rozumie i korzystał z test-driven development TDD, to od razu załapie, że w zasadzie mógłbym robić, i od razu połączy kropki, że w zasadzie mógłbym robić to samo dla security, test-driven security. Dlaczego? Dlaczego tego nie robimy? w procesie wytwórczym i trzeba wiedzieć jak się piszą aplikacje, z jakie są różne techniki, jak można je wykorzystywać na swoją korzyść. No a niestety tego trochę brakuje.

KrzysztofDokładnie. Nawet wydaje mi się, że nie trzeba tego nazywać jakąś osobną praktyką test-driven security, bo dla programistów czy dla testerów QA to jest naturalne. I to bezpieczeństwo po prostu powinno być czymś, co przychodzi i nie jest nazywane osobnym silosem. A druga strona o tym, o czym mówiłeś, to jest fakt tego, w jaki sposób top-researcherzy podchodzą do swojej pracy. I to jest kolejny przykład świetnego researchu, w którym ktoś sięga head-to-head w przeszłość, aby kopać i uczyć się i znajdować problemy, które dotykają nas w teraźniejszości. I już mówiliśmy to w poprzednich odcinkach, tak to robi topka właśnie.

AndrzejTak, topowi researcherzy znają przeszłość swojego pola i jak wchodzą w jakiś target, to nie tylko skupiają się na tym, co jest dzisiaj w tym kodzie, ale skupiają się oczywiście też na tym, co było kiedyś, jakie podatności były kiedyś, na czym one polegały, bo im lepiej zrozumiem przeszłe błędy, i stan, z jakiego po prostu przychodziła aplikacja, jak się rozwijała, tym lepiej zrozumiem pewne decyzje, które były podejmowane i końcem końców tym lepiej zrozumiem stan teraźniejszy. Więc to powiedzenie, że jak ktoś nie zna swojej historii, to jest skazane na jej powtórzenie, aplikuje się nie tylko do ogólnej historii ludzkości, tylko nawet w takich lokalnych kawałkach, gdzie po prostu poznanie historii, Ułatwia zrozumienie danego kawałka, tutaj mówimy konkretnie o aplikacji. Ja podam jeszcze dwa małe komentarze, bo w mojej bańce informacyjnej jednak było trochę krzyczenia o tej podatności. być może followuje nieodpowiednich ludzi na LinkedIn, albo za dużo razy dałem im like, więc teraz algorytm mi podrzuca ich content. Nie mam z tym problemu, spokojnie przeżyję, nie jest to żaden cyberbullying, jak coś to dam unfollow, poradzę sobie. Natomiast to co mi się spodobało jednak w tej bańce to to, może nie spodobała, ale tak, z jednej strony widziałem trochę krzyczenia na LinkedInie, a z drugiej strony jak wszedłem na Facebooka, to dostałem tam jakieś powiadomienie z jednej z grup, w której jestem, i też oczywiście o tej podatności, i też oczywiście w takim wydaniu, że rzucajcie wszystko, idźcie patchować. Ale były też tam takie komentarze po prostu od profesjonalistów IT, jestem pewien, że nie bezpieczników, a raczej sysopsów, czy devopsów, czy administratorów, gdzie bez problemu stwierdzili, że po pierwsze jest to raczej bicie pijany, bo raczej nikt nie ma SSH na publicu, jeśli mówimy o dużych organizacjach. Oczywiście mają SSH, ale ono jest w sieci wewnętrznej. Trzeba być w sieci wewnętrznej, żeby się dobić do tego SSH. Więc to nie jest tak, że świat się wali i da się dostać teraz na każdy server, do każdej organizacji. A dwa, też co najmniej jedna osoba zwróciła uwagę na to, o czym mówiłem, że nie jest tak łatwo wyeksploatować tą podatność. Więc pomimo tego, że owszem, problem jest dość duży i przez to w jakim punkcie systemu jest, że jest Open SSH, ale nie jest tak łatwo wyeksploitować tą podatność i nie jest to po prostu trywialne. A przez trywialne, no oczywiście mamy na myśli, że nie jest to tanie, a skoro nie jest to tanie, to nie jest tak, że ktoś teraz poświęci czas na napisanie exploita i zacznie eksploitować pierwszy lepszy serwer w internecie. To są pieniądze. Jeszcze żeby napisać exploity, który będzie reliable, to to są prawdopodobnie tygodnie, miesiące pracy pojedynczej osoby i to jest raczej koszt liczony w dziesiątkach, setkach, może nawet milionach dolarów. Więc jak sobie zrobimy takie capability, stworzymy sobie taką cyber weapon, no to nie będziemy chcieli jej spalić na pierwszy lepszy serwerek SSH. Więc to też należałoby brać gdzieś tam pod uwagę w naszym profilu ryzyka. ta podatność została wyprowadzana przed ogłoszeniem tego advisory, więc też w momencie, gdy to advisory było już upublicznione, to każdy, kto trzyma swoje systemy aktualne, kto ma jakiś proces patch managmentu zwykłego, najzwyklejszego patch managmentu, już dawno tego problemu nie ma, więc to nie jest tak, że trzeba rzucać wszystko i biec patchować serwery, bo one już dawno powinny być spatchowane w zwykłym procesie patch managmentu. Ostatnia uwaga, malutka, bo myślę, że bardzo mało osób zwróciło na nią uwagę, szczególnie w Polsce, bo po prostu środowisko jest bardzo małe. Na samym końcu jest dedykacja. Dedykacja jest dla Sophie de Antoin. Nie wiem, czy tak to się poprawnie czyta i nazwisko. To chyba francuskie. SOFIA była znaną badaczką bezpieczeństwa, działała właśnie w niskopoziomowym bezpieczeństwie, pisała exploit, robiła vulnerability research, od wielu lat zaczęła być aktywna, przynajmniej tak bardziej publicznie, w poprzedniej dekadzie pomiędzy 2010 a 2020. Dedykacja wynika z tego, że Sofia miała w tym roku, na początku roku wypadek, zderzyła się z pojazdem będąc na rowerze, no i niestety, ale nie przeżyła tego wypadku. Bardzo mi się podoba takie, pomimo tego, że jednak hakerzy są raczej indywidualistami, to istnieje taki, nazwijmy to, hacker spirit, gdzie community, które jest w zasadzie dość małe, nawet jeśli weźmiemy pod uwagę cały świat, mało osób się zajmuje niskopoziomową eksploatacją, a jeszcze, żeby o tym głośno mówili, to jeszcze mniej, no to spodobały mi się takie Taki ukłon w stronę ogólnie community i przypomniało mi to coś podobnego, co my mieliśmy okazję też w naszej polskiej community trochę otrzymać od autorów fraka. W odcinku 66 z 2009 też jest taka dedykacja, a może nawet nie dedykacja, ale pozdrowienie dla Cliffa. Cliff też miał wypadek, ale miał wypadek z samolotem, z którego też nie wyszedł. Cało Cliff to był taki znany polski researcher właśnie w niskopoziomowej eksploitacji kernela Linuxa. Więc niejako to co mi się tutaj podoba to to, że pomimo tego, jest to globalne community, pomimo tego, że często ludzie wcale się nie znają nawet osobiście, po prostu znają się przez jakieś IRCE, czy przez pocztę, czy po prostu znamy ich z jakichś adwizory, które wypuścili, to jednak jest ten, nazwijmy to, fellow spirit pomiędzy ludźmi, którzy mają podobne, dziwne dla niektórych zainteresowania. Dobra, Krzysiek, to co? Wskakujemy w twój, bo tutaj się trochę rozgadałem na ten temat.

KrzysztofTak, wskakujemy w mój. Słuchajcie, ja znalazłem bardzo ciekawy artykuł. On jest króciutki. Ale ciekawe z racji tego, kto się z nim zajmuje. Artykuł od osoby, która współpracuje, albo pracuje, albo w jakiś sposób miała dostęp do bazy danych programu Social Cyber. Social Cyber to jest program amerykańskiej agencji zaawansowanych projektów badawczych DARPA. Tak, działającej w strukturze Departamentu Obrony Stanów Zjednoczonych, więc u spiskowe teorie. Andrzej, twoja ulubiona spiskowa teoria związana z DARPA?

AndrzejNie mam, ale ja o tej osobie, która to napisała powiem więcej niż w dwa słowa.

KrzysztofOk, typowa odpowiedź człowieka, który ma coś za uszami. Ten program, o którym mówię, czyli Social Cyber, ma na celu zbadać, bo on dalej trwa, anatomię ataków na łańcuchy dostaw, w szczególności ataków na Open Source’a poprzez między innymi analizę kodu źródłowego i co ciekawe artefaktów komunikacyjnych związanych z rozwojem Open Source’a, czyli pewnie skrapują feedy twitterowe, fora dyskusyjne i tak dalej i tak dalej. Wszystko to, co może mieć jakiś związek z tym, w jaki sposób pewne projekty Open Source’owe są rozwijane. No i nie będzie tutaj chyba zaskoczeniem, że pełen fokus idzie na te projekty open source’owe, które są wykorzystywane gdzieś w łańcuchu dostaw właśnie Departamentu Obrony Stanów Zjednoczonych, bo to jest w ich zainteresowaniu, aby właśnie przed takimi atakami się chronić. Artykuł był zainspirowany wydarzeniami w kontekście ataku na XE, o którym mówiliśmy kilka odcinków wcześniej. i autor zadał sobie trud, aby sprawdzić, jak dużo w ekosystemie PyPI, bo on tam pisze konkretnie ten artykuł po odniesieniu właśnie do ekosystemu Pythonowego, zadał sobie trud, aby sprawdzić, ile jest podobnych kontrybutorów do tego GIA-TAN i wykorzystał do tego bazę grafową projektów, z którym współpracuje. to prawdopodobieństwo scharakteryzował następującymi heurystykami. Kontrybutor ma Coint Access, ma chiński timezone i e-mail spełnia bardzo proste wyrażenie regularne, czyli posiada literki i cyferki i jest w domenie gmail.com. I tutaj, co zauważył, to to, że ta baza grafowa zwróciła mu 310 wyników. W tym jednym z takich kontrybutorów jest miaumiaukat, który jednocześnie jest kontrybutorem do PIPA, czyli po prostu instalatora paczek pythonowych, więc to już rodzi pewne pytanie, kim ta osoba jest, bo mail, bądźmy szczerze, sam w sobie nie wygląda zbyt poważnie.

AndrzejCzemu? Czemu miał? miał kat1211maupatchmail.com? Kontrybutor do pipa? Nie no, ekstra, spoko. Dla mnie, wiecie, w internecie nikt nie wie, że jesteście psem albo kotem.

KrzysztofNo dokładnie. Potem poszedł za ciosem i sprawdził ile ownerów paczek z top 5000 pasuje do tego wzorca, o którym mówiłem chwilkę wcześniej. No i okazało się, że aż tak dużo tego nie ma, bo jest niecałe 100 takich wyników. zwróciło takie zapytanie, ale za to jakich wyników, bo zwróćmy uwagę, jakich mamy tutaj graczy na tym polu. Faker, popularna biblioteka do testów, Django, Outlip, więc same grube ryby. To, co chcę tutaj podkreślić, idąc dalej w związku z tym artykułem, że poszedł dalej za ciosem, postanowił sprawdzić ile z tych ownerów również ma maila w domenie qq.com. To jest bodajże jakiś chiński serwis. Ja się z tym już przewinąłem kilka razy, ale do końca nie wiem czy to jest coś z chińskiego internetu. Tak? Dobrze mówię?

AndrzejTak. To jest chiński serwis, dość popularny, to jest Tencenta.

KrzysztofOkej, okej, okej, okej. Więc wziął top 5000 paczek z ekosystemu Pythonowego, zarówno gdzie kontrybutor ma maila w gmailu, czy ma maila w qq.com i potem posertował te paczki według Google’owego page ranka. No i co się okazało? Okazało się, że tak naprawdę w topce takiego wyszukiwania na przykład znalazł się Unseable, czyli bardzo popularne narzędzie do zarządzania i automatyzacji zadań na infrastrukturze. I tutaj nawet autor wskazuje, że w zasadzie może nie uruchamiajcie Unseable. w takim razie, skoro ten mój research idzie w tym kierunku. czyli tutaj w pewnej konwencji, w pewnej konwencji zartu. I na koniec tego artykułu bardzo ciekawe rozważania autora, że w zasadzie to jest ten jego research, to jest wstęp, to jest wierzchołek pewnej góry, góry lodowej tego problemu związanego z atakami na łańcuchy dostaw. Moglibyśmy teraz wziąć te wszystkie maile kontrybutorów z PyPI i np. odpytać bazę HeavyBimpont, żeby sprawdzić ile z tych maili tych kontrybutorów. znajduje się w bazach wycieków, które agreguje serwis Have I Been Pwned. Można by było również dokonać analizy częstotliwości komitowania, można by było sprawdzić co się dzieje w obrębie samych nazw komitów w poszukiwaniu jakichś słuszliwych wzorców. Z tego co kojarzę i o ile przeczytałem abstrakt tego projektu, który jest dostępny na stronie DARPA, to oni robią to od 2021 roku. Zaprzęgli tam oczywiście analityczną, sztuczną inteligencję, aby ten ogromny zbiór danych analizować i korelować pewne artefakty i punkty między sobą i na tej podstawie wyciągać wnioski. Definitywnie warto jest spojrzeć na ten artykuł, zwłaszcza że on jest króciutki i daje do myślenia o problemie, przed jakim stoimy.

AndrzejDefinitywnie Dave’a należałoby obserwować. To jest jedna z legend cyberbezpieczeństwa z wielu powodów, ale chyba głównym powodem jest to, że jest na każdej warstwie cyberbezpieczeństwa od regulacji, i ma o tym jakieś pojęcie, aż po niskopoziomową eksploitację. Dave Eitel to twórca firmy Immunity. Firma Immunity jest bardzo szeroko znana w kręgach niskopoziomowej eksploitacji. W ogóle po prostu w exploit development i ofensywnych operacjach jest bardzo znana. Oni stworzyli pierwszą, nie pierwszą, chyba drugą instancje protoplasty metasploita, czyli frameworku do szybkiego pisania eksploitów, gdzie nie tylko stworzyli sobie framework, a potem pisali eksploity i one też były w pakiecie, więc kupowało się subskrypcje na ich oprogramowanie. Wydaje mi się, że ono się nazywało Canvas. i dostawało się w pakiecie exploity, więc utrzymywało się capability i to było w latach 2000-2010, więc wydaje mi się, że pierwsi byli chyba Brazylijczycy z Core. Oni chyba stworzyli pierwszy taki framework, albo równolegle, a potem był Canvas z Immunity. Immunity w poprzedniej dekadzie, o ile dobrze kojarzę, został sprzedany. Dave końcem końców sprzedał firmę, po prostu zexitował się i zaczął inne włojarze, m.in. większą współpracę z DARPA i wiele innych rzeczy, bo to jest bardzo interesująca postać, więc wiele też takich charytatywnych działań. Bardzo ogarnięty gość, ogólnie allround, ale jeśli mówimy o technicznych, to też w dalszym ciągu widać, że lubi to co robi i gdzieś tam nie poszedł leżeć na plaży, tylko dalej jest aktywny, nawet od takiej dość technicznej strony. Więc tak Dave, Dave mega mega mega ogarnięty gość, polecam każdemu fascynatowi cyberbezpieczeństwa. Przeczytaj sobie ten post. ale może potraktować to jako punkt startowy i jak widać po prawej stronie trochę tych postów na przestrzeni lat jest. Znajdzie się tu wiele smakowitych kąsków dla ludzi zainteresowanych. cyberbezpieczeństwem trochę szerzej jako ogólną dziedziną, bo Dave potrafi, tak jak powiedziałem na samym początku, mówić i szeroko i głęboko i często skacze pomiędzy szerokością i głębokością spojrzenia. Ja chciałbym przejść teraz na szybko do jednej rzeczy, naprawdę skrótowo, dlatego że w zasadzie nie ma się co tutaj rozwodzić, bo końcem końców głosowanie za cenzurą aplikacji do wiadomości, messaging applications, ale nie tylko, bo oczywiście za tym poszłyby dalsze platformy. Instagram czy TikTok na koniec dnia też jest aplikacją do wysyłania DM-ek. Wiadomo, tam się wrzuca zdjęcia etc., ale dm tam są, więc te aplikacje oczywiście też by tutaj wchodziły. Chodzi mi o cenzurę, która miała być poddana pod głosowanie 20 czerwca. Głosowanie zostało przesunięte, więc na chwilę, przynajmniej na chwilę obecną, trochę przesunęliśmy walkę o wolność. Przypomnę, że Polska i tak się opowiadała, o ile dobrze kojarzę, przeciw. Miała jasne stanowisko, Niemcy też, ale było kilka krajów, które nie miały jasnej doktryny, czy są za, czy przeciw. No i one by przeważyły, m.in. np. Włochy czy Grecja. One by przeważały tutaj szalę, czy miałaby być ta cenzura, czy nie. Przypomnę, cenzura ma generalnie polegać na tym, że wiadomo, bezpieczeństwo dzieci, więc bezpieczeństwo dzieci. Będziemy skanować wszystkie twoje wiadomości, które wysyłasz na swoim urządzeniu pod kątem tego, czy przypadkiem nie robisz czegoś złego. Rząd będzie sprawdzał, czy ty przypadkiem nie robisz czegoś złego. No bo wiadomo, jak nie masz co ukryć, to możesz robić wszystko z otwartymi oknami, prawda? No bo nie masz nic do ukrycia, nie robisz nic złego, No to chyba nie masz problemu, żeby urzędnik przeczytał Twoją komunikację i jak sobie flirtujesz ze swoją żoną, dziewczyną czy nawet i kochanką. Nie ma to znaczenia. Rząd ma do tego prawność, bo w końcu nic złego nie robisz. Oczywiście brzmi to absurdalnie, bo to, że ja nie robię nic złego, to nie oznacza, że ktoś ma mi czytać moją prywatną korespondencję i ma wyłapywać, co tam jest napisane. psuć, burzyć, usuwać podwaliny bezpieczeństwa, czyli szyfrowanie end-to-end. I tutaj mam nadzieję, że to nie przejdzie, ale widać, w którym kierunku to idzie. Oczywiście tutaj jest multum różnych problemów, które by się otworzyły. Otworzyłaby się wręcz Puszka Pandory, dlatego że No i co by zrobiło Apple? Czy Apple dostosowywałby teraz cały swój ekosystem po to, żeby zadowolić Europejczyków, czy może jednak by tego nie zrobiło i powiedziało, wiecie co, to nie możecie po prostu kupić iPhona. Co zrobiłby Whatsapp? Whatsapp tutaj jest nawet lepszym przykładem. Dlatego, że Whatsapp jest bardzo szeroko używany na świecie, ale świat nie kończy się na Europie. I last time I checked to Azjatów było trochę więcej, więc być może po prostu zrezygnują z rynku europejskiego. Po co mają się w to bawić? po prostu nie będzie WhatsAppa i będą zadowoleni z Emerging Markets takich jak India czy Afryka. Oczywiście to jest z mojej strony gdybanie co by się stało, natomiast to są pewne ścieżki, które na pewno zostałyby rozważone z punktu widzenia biznesowego przez te firmy. No i należałoby się po prostu być świadomym, co może nadejść, trzymać tutaj rękę na pulsie, bo zmiany mogą pójść w złym kierunku, a potem bardzo trudno jest się cofnąć. I zawsze na początku zawsze jest dobrze. Na początku te powody zawsze są dobre, ale potem to już… Bardzo łatwo przejść od A do B, a od B do C, a od C do Z i nagle kończymy, że w zasadzie to rząd może czytać wszystko. Bo czemu nie? Jak nie masz nic do ukrycia, to przecież możesz wszystko mówić. Niestety, ale świat i życie tak nie działa. Jeśli ktoś gra na naszą niekorzyść, a to jest clearly na naszą niekorzyść, to ma w tym swój jakiś interes i na pewno nie zależy mu na naszym interesie. Tutaj mam nadzieję, że nie tylko zostało to odłożone, to akurat się stało, ale mam nadzieję też, że końcem końców to nie przejdzie. Byłoby to bardzo duży cios w wolność wszystkich obywateli krajów, które są członkami Unii Europejskiej.

KrzysztofNo tak, jak to się mówi, dobrymi chęciami piekło jest wybrukowane.

AndrzejJa tutaj zrobię jeszcze gwiazdkę, bo sądzę, że to powiedzenie się tutaj nie stosuje, bo ja odwrócę sytuację. i ja nie sądzę, że jakikolwiek urzędnik na jakimkolwiek poziomie, czy państwowym, czy europejskim, motywuje się tutaj i że całe to prawo jest motywacją z dobrych chęci. Śmiem w to wątpić, wręcz przeciwnie uważam, że ono od początku jest pisane pod konkretny cel i ten cel wcale nie jest dobry, jest tylko po prostu nakładka i użycie mechanizmu plausible deniability, gdzie jestem w stanie zaprzeczyć. Natomiast jest mi trudno uwierzyć, że ktokolwiek na wysokim stanowisku W polityce sam kupuje bajkę o dobrych chęciach. To są złe chęci od samego początku. Może na poziomie obywatela gdzieś byłyby dobre chęci, ale na poziomie polityki i na tak wysokim poziomie od razu możemy wykluczyć te dobre chęci. To jest evil.

KrzysztofJa dałem od siebie tę gwiazdkę. Nie uważam osobiście, żeby faktycznie motywacją do przepchnięcia tego było to, aby pan urzędnik z Brukseli siedział i czytał nasze wiadomości, które wymieniamy, tak jak powiedziałeś, z żoną, kochanką czy dziewczyną. ale tworzy to pewną pokusę, która może zostać wykorzystana w przyszłości.

AndrzejKrzysiek, ja Ci powiem, to, że mam paranoję, to wcale nie oznacza, że mnie nie śledzą. To są dwa osobne fakty, więc należałoby się nad tym zastanowić. Ale tutaj też widzicie, że nie ze wszystkim zawsze się w stu procentach zgadzamy. Z Krzyśkiem ja mam dość… Raczej w takich sytuacjach skłaniam się ku temu mroczniejszemu spojrzeniu na rzeczywistość. Czyli tak naprawdę neguję. Byłoby mi bardzo trudno kupić argumentację. Musiała być super tight, żebym kupił argumentację, że jest to z jakiegoś dobrego powodu. To, co jest wylistowane na tej stronie, która będzie w referencjach, można sobie przeczytać. Żaden z tych argumentów przedstawianych w całym tym prawie, który miał wejść, nie przekonywa mnie do tego, że działałby to na czyjąkolwiek korzyść, natomiast widziałem tylko na czyją niekorzyść by to działało. Między innymi mnie, pomimo tego, że nie mam za bardzo nic do ukrycia, ale kto wie, może kiedyś będę miał. Więc już dbając o Andrzeja z przyszłości, chciałbym, żebym mógł się jednak komunikować w bezpieczny sposób, A od tego są organy ścigania i różne inne, żeby radziły sobie bez takich haków na poziomie technologii.

KrzysztofZnaczy, oni i tak już są w stanie…

AndrzejNo, that’s the point. Na obecnym poziomie technologii oczywiście, że da się wiele różnych problemów rozwiązywać. Dziwne trafienie są rozwiązane. Ha, ciekawe. Nie wiem, nie wiem, ale się domyślam. Chodzi mi raczej o to, że tutaj nie skłaniam się ku temu, że problemy są nierozwiązane, bo ktoś nie chce ich rozwiązać tak na złość. Raczej chodzi mi o to, że nie są rozwiązane, bo Bo system jest nieefektywny. Ale możliwości techniczne jak najbardziej są. I teraz przykładowo, tutaj bardzo szybka dygresja. Krzysiek wie. W kwietniu ukradli mi auto. Spod bloku. Dowiedziałem się wtedy, że tu gdzie mieszkam, w tej dzielnicy Warszawy, w której mieszkam, w zasadzie dość dużo się kradnie samochodów. I faktycznie na stronie facebookowej widać, co jakiś czas widać post, że ktoś ukradł auto. I teraz pytanie, czy od strony technicznej nie jesteśmy w stanie znaleźć tych złodziei aut? No ja kurcze poddaję to pod wątpliwość. Wydaje mi się, że gdybyśmy chcieli ich znaleźć, to byśmy ich znaleźli. Że da się to zrobić. Nie musimy mieć chińskiej inwigilacji, żeby dał się to zrobić. Tylko najwidoczniej system jest w tym zakresie nieoptymalny. I nie ma znaczenia czemu jest nieoptymalny i czemu nie jest optymalizowany. To już pomijam. Chodzi mi tylko o to, że technicznie jesteśmy w stanie to zrobić, przynajmniej dla większości, zdecydowanej większości przypadków, a resztę zostawić jako edge case’y, ale nie jest to zrobione. Więc nie jest to zrobione i tak samo tutaj. Nie jest to zrobione pomimo tego, że technicznie byłoby to możliwe. Więc nie ma sensu dodawać dodatkowych mechanizmów, które tylko będą działać na szkodę ogólnych obywateli. Nie ma sensu tego dodawać, bo i tak nie zostanie to wykorzystane. Bo gdyby miało być to wykorzystane, gdyby ktoś chciał rozwiązać problem, to ten problem już dawno byłby rozwiązany. Technologia pozwala na rozwiązywanie dużej ilości problemów, które dziwnym trafem dalej są problemami. No właśnie, tu trzeba byłoby podziałać nad poprawianiem efektywności i optymalizacji systemów, które już działają. na poziomie kraju, na poziomie organizacji, a nie dokładać sobie kolejne ułatwienia, które i tak za bardzo nic nie zmienią, a oczywiście będą użyte w może nie do końca dobry sposób z perspektywy odbiorcy. Ale dobrze, nie przedłużajmy. Krzysiek, wskakuj w swój ulubiony temat. Ja myślę, że niektórzy z naszych słuchaczy już będą wiedzieć, o czym będzie teraz mówił Krzysiek. Scena twoja.

KrzysztofDziękuję, dziękuję. Ten research posłał mi Andrzej, także jak coś, to jest na niego wszystko. Ja nie chciałem o tym mówić, ale to Andrzej mi to wysłał. SMS-kiem był pierwszy. Chodzi o sekrety Widmo. Research napisany przez Aqua Security. To jest firma, którą część z Was może kojarzyć, bo mają cały biznes dookoła cyber security, w szczególności różnych systemów klasy CSPM, ASPM i tak dalej. W ogóle taka dygresja. Ostatnio toczy się dyskusja na temat tego, na co jeszcze wpadnie świat związany z biznesem cybersecurity. Jaką klasę narzędzi jeszcze będą w stanie wymyślić, która magicznie rozwiązuje jakiś problem, który tak naprawdę jest już rozwiązany, ale musimy to opakować w jakieś nowe pudełko. Więc te wszystkie CSPM-y, ASPM-y, CNAP-y itd. to jest m.in. Aqua Security, ale mają też bardzo fajny open source’owy Skaner Trivi, który bardzo fajnie działa z kontenerami dokerowymi, ale to jest taka dygresja, czym się zajmuje ta firma. Oni też mają cały dział researchu i właśnie o tym dziale researchu, a konkretnie o ich publikacji będziemy mówić. Sekrety Widmo. I tak, autorzy researchu wskazują, że pomimo używania narzędzi do detekcji sekretów takich jak Truffle Hog czy Gitlix, więc tutaj to było takie miękkie uderzenie trochę w stronę Truffle Hoga, tak przynajmniej odczytuję to z tego artykułu, sekrety mogą dalej pozostać niewykryte i znajdować się gdzieś tam w odmętach historii repozytoriów. No i możecie się zastanowić, jak to jest w ogóle do cholery możliwe. Przecież klonując repozytorium myślę, że zdecydowanie większość z Was i przynajmniej ja też tak myślałem, bo po tym artykule już wiem, że tak nie jest. Robiąc to przez git klona po prostu klonujemy repozytorium. No i koniec sprawy. Okazuje się, że istnieje przełącznik mirror. który pozwala na pobranie lustrzanej kopii z dalnego repozytorium wraz ze wszystkimi referencjami, które znajdują się na remote’cie, ze wszystkimi branczami, ze wszystkimi tagami i tak dalej. To nawet było kiedyś opisywane jako podatność Git Lead, która gdzieś tam w dużym skrycie mówiła o tym, że nawet jak usuniecie brancza, no to potem zostają na remote’cie jakieś referencje do niego. To nie jest jasno opisane w samej dokumentacji Gita, przez co może być mylące dla użytkowników samego Gita, po czym zespół Gita powiedział, że nie, że to tak ma właśnie działać i tak dalej, że my to jednak dobrze opisaliśmy, tylko trzeba zrozumieć w jaki sposób właśnie działa Git. Co jak myślę większość tutaj z nas przyzna się tak z ręką na sercu. Większość z nas tak naprawdę nie korzysta z Gitę jako taki power user. Nie oszukujmy się. Znamy kilka tych podstawowych rzeczy, które musimy znać i które nam są potrzebne w codziennej pracy i tak naprawdę nie potrzebujemy ogarnąć całego Git’a, aby dobrze wykonywać swoją pracę. Więc tutaj w kontekście tego Git Lead’a i tego, co zespół Git’a wtedy odpisał. Okazuje się, że właśnie klonując to z tym przełącznikiem Mirror otrzymujemy dużo więcej referencji i researcherzy z Aqua Security, właśnie z Aquasec, wzięli to na tapet, przeskanowali 100 największych organizacji na GitHubie pod kątem rankingu opartego na tej liczbie gwiazd, którą możecie tam dawać na repozytoriach. Okazało się, że łącznie zeskrapowali 52 268 różnych repozytoriów. Najpierw przeskanowali te wszystkie repozytoria za pomocą Gitlixa. właśnie używając git-clona, a potem przeskanowali je ponownie używając git-clone-mirror. No i policzyli ile sekretów udało im się znaleźć w tej wersji ze zwykłym sklonowaniem i z tym klonowaniem, które dawało im tą wersję lustrzanego odbicia. No i okazało się, że Różnica to jest około 18% potencjalnych sekretów, które mogą jeszcze znajdować się w tych sklonowanych repozytoriach, w tych lustrzanych kopiach. Tutaj wpadły m.in. takie duże projekty jak Firefox w kontekście ich projektu stricte Mozilla Fuzz Manager API. Znaczy znaleziono API token w Fuzzmanagerze.

AndrzejA to była dla mnie wisienka na torcie ten Fuzzmanager. W zasadzie można było ściągać sobie wyniki ich hazera. Piękne, po prostu takiego czegoś oczekiwałem.

KrzysztofTo jest na tyle poważne, że mając wyniki z tego fazera, potencjalni atakujący mogli być o krok przed wypuszczeniem jakiegoś advisory, jakiegoś patcha, tak? I nas pisać szybciej exploita niż powstanie patch czy fix.

AndrzejDokładnie tak. Jedyny plus jest taki, że w zasadzie nikt nie korzysta z Firefoxa. Snap!

KrzysztofA jeżeli ktoś korzysta, to dajcie znać w komentarzach. Podyskutujemy.

AndrzejŁączymy się w bólu. Z dużą gwiazdką, jak prowadzę szkolenia z ofensywnego testowania web aplikacji, To przeglądarką, którą używamy jest Firefox, dlatego że Firefox ma kilka ciekawych udogodnień, ale tym głównym jest to, że ma mechanizm proxy oddzielony od systemu operacyjnego i nawet pomiędzy instacjami, więc jeśli mamy Firefoxa for devs i zwykłego, to ustawienia proxy też są osobne pomiędzy tymi Firefoxami. Więc jest to po prostu przydatne jak testujemy bezpieczeństwo i musimy się przepinać pomiędzy proxy. Nie musimy robić tego na poziomie systemu operacyjnego, co też się wiąże z tym, że nie musimy importować certyfikatu z Burpa czy z Zappa do chaina systemowego, tylko do chaina samego Firefoxa, więc też jest to bezpieczniejsze rozwiązanie.

KrzysztofTak, dokładnie. Nie będę tutaj wymieniać wszystkich firm czy organizacji, które zostały zhakowane. Dwa razy znaleziono coś w ekosystemie Firefoxa, za drugim razem był to jakiś personal API token pracownika wypuszczowany w jakimś apozytorium. Mercai również padło ofiarą tego researchu i jedna z dużych film czy usług healthcare’owych. Tutaj nie podano dokładnie o kogo chodzić, pewnie ze względu na krytyczność i wrażliwość tej sytuacji. GitKlon, GitKlon Mirror, okazuje się, że klonując sobie lustrzaną kopię na swój dysk jesteśmy w stanie znaleźć więcej sekretów. Cały mechanizm w jaki sposób to działa i czym różni się GitKlon od GitKlon Mirror jest opisany świetnie w tym researchu. Ja myślę, że mówiąc o tym pewnie popełniłbym ze 100 błędów. Tak bardzo jest to zagmatwane, jeżeli codziennie nie robicie tego i nie znacie gita tak naprawdę głęboko. Ale jest jeszcze jedna wisienka na torcie w tym researchu, która spodobała mi się niezwykle mocno. Okazuje się, że wszystkie platformy, które zdalnie przytrzymują nasze repozytorium, cashują widoki tego interfejsu, który wyświetla nam treść na przykład jakiegoś komita. I teraz autorzy tego researchu wskazują, że jeżeli cashują, to cashują na zawsze. I komity dostępne za pomocą tych witoków z pamięci podręcznej jesteśmy w stanie znajdować tylko po pierwszych czterech znakach komita. Szczególnie dotyczy to dwóch platform, GitHuba i Bitbucketa. Bitbucketa to w ogóle mnie nie dziwi. Dlaczego tak tam się dzieje? Bo tam się dużo różnych dziwnych rzeczy dzieje. Oczywiście pół żartem, pół serio, bo wiem, że wiele poważnych organizacji korzysta z Bitbucketa.

AndrzejTo jak z JIRA. i w zasadzie nie bez powodu tutaj mówię o JIRA, bo Bitbucket z tej samej firmy Atleasian i raczej wynika to z takiej decyzji biznesowej, a nie z decyzji inżynierów na dole, którzy najchętniej korzystaliby z GitHub’a albo z GitLab’a.

KrzysztofDokładnie. Dokładnie tak. W kontekście tych dwóch platform okazuje się, że jeżeli mamy jakiś widok, przez GUI możemy wyświetlić jakiś komit i oczywiście na końcu w ścieżce jest cały sza tego komita, to wystarczy, że podamy tylko pierwsze cztery znaki tego sza. i zostaniemy przekierowani do tego komita, do tego widoku. I tak to się dzieje właśnie na GitHubie i na Bitbuckecie, więc ECS stwierdzili, że w zasadzie przestrzeń do przeskanowania jest relatywnie mała.

AndrzejJest bardzo mała, bo to są same znaki w zasadzie 26 plus 10, 36 do czwartej. Więc to jest mało.

KrzysztofDokładnie tak. I więc tutaj w kontekście GitHuba i Bitbucketa można robić takie rzeczy. No i tak, faktycznie komity, które nie są widoczne w historii na pierwszy rzut oka, możemy również znajdować po prostu Brutforsując te widoki skeszowane w platformach SCM-owych takich jak GitHub czy Bitbucket.

AndrzejTutaj wejdę Ci słowo, to półtora miliona. 36 do czwartej to półtora miliona. To dość mało.

KrzysztofPewnie tutaj też autorzy wskazywali, z tego co pamiętam, że do tego trzeba by było podejść troszeczkę szerzej, bo po pierwsze łamie to term z GitHuba i Bitbucketa, żeby taki scraping dokonywać. A tym się nikt nie przyjmuje. Ale tym się nikt nie przejmuje, bo papier przyjmie wszystko. A druga kwestia jest taka, że tam jest jakiś Rating Meeting i nawet gdybyśmy chcieli to robić przez widok front-endowy, czy chcielibyśmy nawet to robić przez API powiedzmy GitHuba, no to odbijemy się w pewnym momencie od rate limitingu, więc to nie jest tak, że teraz możecie usiąść na swojej maszynce i bezkosztowo odpalić taki skan bruteforcując na jakimś repozytorium wszystkie sza, pierwsze cztery znaki sza commitów i odkrywać committy, które nie są widoczne na pierwszy rzut oka. Tak, na Gitlebie potrzeba 7 znaków, więc już znacznie, znacznie, znacznie więcej. Na ażurze i na CodeComicie AWS-owym nie da się tego triku zrobić, ale szczerze powiedziawszy, to ja nie znam słownie ani jednej osoby, która by skorzystała z tego do zarządzania kodem.

AndrzejTeż nie. Ani jednej osoby, ani jednej organizacji. No ale spoko, jak jest, to być może ktoś korzysta.

KrzysztofTak, i w kontekście sekretów, taki mój drobny komentarz na sam koniec, znowu odkrywamy kolejną kartę w tej niekończącej się historii, gdzie sekrety się mogą tak naprawdę jeszcze znaleźć i jak duża jest ta powierzchnia ataku. i tak jak Andrzej kiedyś powiedziałeś, ten problem jest simple to fix, but not easy.

AndrzejDokładnie.

KrzysztofCały artykuł jest świetnie napisany i znowu otwiera mi pewne drzwi w głowie na temat tego, w jaki sposób powinniśmy na niego patrzeć. Byliśmy ostatnio na gali Stukomitów. Pozdrawiamy w ogóle chłopaków z Death Mentors.

AndrzejPozdrawiamy.

KrzysztofI Krzysiek i Andrzej. I na koniec naszej prelekcji, która dotyczyła czegoś innego, bo dotyczyła złośliwych paczek w ekosystemach open source’owych, padło pytanie dotyczące sekretów, bo jeden tam slajd był poświęcony pewnej historii, w której sekret grał jakąś rolę. I padło pytanie od programisty, Czy ja mogę przetrzymywać sekrety w prywatnym repozytorium? I nie chodzi teraz o to, żeby kogoś linczować, żeby mówić, że zobaczcie, jacy oni są niewykształceni, niedoedukowani. Chodzi o to, jaki jest ogólny stan wiedzy na ten temat i higieny obchodzenia się z sekretami. I patrząc na to, ile researchów powstaje w ostatnim czasie, Myślę, że jeszcze jest dużo pracy przed nami wszystkimi, aby doprowadzić do takiego stanu, w którym te sekrety będą raczej pewną egzotyką niż czymś, co znajdujemy w różnych miejscach w naszym ekosystemie dewelopmentu.

AndrzejDokładnie tak. To po prostu pokazuje, że w dalszym ciągu i pewnie przez długi jeszcze czas nie jest to tzw. standard operating procedure. I kontrastując to z przykładowo używaniem repozytorium, niech będzie, zostawmy przy Gicie, repozytorium Gita. Żaden programista w 2024, kiedy nagrywamy ten odcinek, nie zadałby pytania, czy powinienem korzystać z jakiegoś SCM, Source Code Managera. Nikt by nie zadał takiego pytania, to niejako wynika samo z siebie, że tak, powinieneś korzystać z jakiegoś SCM-a, najprawdopodobniej w większości przypadków powinieneś korzystać z Git-a. Nikt nie zadał pytania dlatego, że jest to standard operating procedure pisania kodu. Musimy sobie kod jakoś wersjonować, a jak piszemy go razem, to musimy mieć jakiś sposób na współpracę na tym kodzie w większym zespole niż jedna osoba. Więc jest to Standard Operating Procedure, a różne praktyki związane z bezpieczeństwem, między innymi właśnie te sekrety, one nie są. Developerzy i inne osoby w inne role w procesie wytwórczym nie mają wyrobionych Standard Operating Procedures co do tych różnych praktyk i to oczywiście będzie się zmieniać. z czasem i trochę też tutaj ułatwiają nam to te różne platformy takie właśnie jak GitHub czy GitLab, ale nie jest to jeszcze, nie jesteśmy w tym punkcie, w którym chcielibyśmy być. Idealnie nigdy nie będzie, ale na pewno jesteśmy w stanie poprawić sytuację z tego stanu w jakim jesteśmy do stanu, który będzie lepszy. Ideału może nie, może nie osiągniemy, ale na pewno będzie lepiej.

KrzysztofDokładnie tak, Andrzeju. Odsyłamy do tego artykułu, też podeślamy go na pewno w opisie i w szczególności do tej sekcji, w której opisują jaka jest różnica między klonowaniem repozytorium w normalnym trybie, a jaka jest różnica pomiędzy tym, kiedy robimy to z przełącznikiem mirror.

AndrzejTak, ewidentnie odsyłamy do tego artykuł. Tym bardziej, że ten artykuł będzie przydatny nie tylko dla bezpieczników, a może nawet dla bezpieczników w trochę mniejszym wydaniu. Na pewno będzie bardzo ciekawy dla zwykłych po prostu inżynierów. Każdy inżynier, który korzysta dzisiaj w podniu z Gita, skorzysta na tym, jak lepiej zrozumie, w jaki sposób działa Git, narzędzie, z którego po prostu codziennie korzysta. Dobra, Krzysiek, to co? Przebiliśmy trochę godzinę, nie udało się z timeboxować poniżej godziny, ale nie będziemy przedłużać, nie będziemy wskakiwać na godzinę 15. Jakieś ostatnie słowa? Nie zabierajmy im wakacji.

KrzysztofNie zabierajmy naszym słuchaczom wakacji. Więc tak, jeżeli jesteście jeszcze przed wakacjami, to życzymy wam donego wypoczynku, a jeżeli jesteście już po, to mamy nadzieję, że wróciliście do pracy w pełni naładowani.

AndrzejDokładnie tak. To co? No to usłyszymy się za dwa tygodnie.

KrzysztofDo usłyszenia. Do usłyszenia. Trzymajcie się.

AndrzejHej.

Newsletter

Damy Ci znać, gdy opublikujemy coś nowego.

Artykuł albo odcinek podcastu. Bez spamu. W każdej chwili możesz się wypisać.

Zapisując się, akceptujesz politykę prywatności.

Referencje i wzmianki: OpenSSH, CVE-2024-6387 (RegreSSHion) — advisory Qualys; podatność z 2006 r. (Mark Dowd); The Art of Software Security Assessment; ASLR, NX bit / DEP; Ubuntu 24.04 LTS; Semgrep, variant analysis; DARPA Social Cyber; Dave Aitel, Immunity, Canvas; PyPI; Aqua Security („Ghost Secrets”), Trivy; TruffleHog, GitLeaks; git clone --mirror; GitHub, Bitbucket, GitLab; EU Chat Control.