W najnowszym odcinku podcastu zagłębiamy się w bieżące wyzwania i trendy w świecie cyberbezpieczeństwa. Analizujemy głośne incydenty, takie jak krytyczna podatność w GitLabie (CVSS 10.0), dyskutując, dlaczego ocena CVSS nie zawsze odzwierciedla rzeczywiste ryzyko dla organizacji, oraz podkreślając kluczową rolę uwierzytelniania dwuskładnikowego (2FA) i odpowiedniej konfiguracji środowisk. Przyglądamy się również dynamicznemu wzrostowi liczby zgłaszanych podatności (CVE) i wyzwaniom związanym z zarządzaniem ryzykiem w złożonych ekosystemach IT.

W tym odcinku szczególną uwagę poświęcamy:

Inicjatywom proaktywnego bezpieczeństwa infrastruktury: Przedstawiamy polskie narzędzie open source NASK Artemis, które rewolucjonizuje automatyczne skanowanie powierzchni ataku organizacji, oferując wykrywanie podatności i błędnych konfiguracji dla firm o różnej skali.
Eskalacji ataków na łańcuch dostaw oprogramowania: Dowiadujemy się o drastycznym wzroście (1300%) złośliwych pakietów, zwłaszcza w ekosystemach takich jak NPM i PyPI, co stawia nowe wyzwania przed deweloperami i zespołami DevSecOps.
Praktycznym aspektom zarządzania podatnościami: Omawiamy, jak narzędzia do skanowania generują fałszywe alarmy (false positives) oraz jak wskaźniki takie jak EPSS (Exploit Prediction Scoring System) pomagają w ocenie realnego prawdopodobieństwa eksploitacji luk bezpieczeństwa.

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

Transkrypcja

Andrzej: Dzień dobry, zaczynamy, zaczynamy.

Krzysiek: Dzień dobry.

Andrzej: Krzysiek, spotykamy się, żeby porozmawiać o ciekawych rzeczach, które wystąpiły w branży Cyber Security w zeszłym miesiącu. To jest taki motyw przewodni analizy dynamicznej projektu, który chcemy wypróbować z Krzyśkiem w kolejnych miesiącach, zobaczyć jak będzie działał, czy będzie się ludziom podobało, czy nie. No i Krzysiek. Oddaję Ci głos, startuj ze swoim pierwszym znaleziskiem i podziel się z nami swoim komentarzem, a ja podzielę się potem swoim, bo ja mam komentarz.

Krzysiek: No to słuchajcie, Andrzej pewnie wiesz, mam nadzieję, że słuchacze też co nieco już na ten temat słyszeli, a na pewno obiło się o uszy, bo w 2024 wyszliśmy na grubo. 11 stycznia GitLab publikuje notkę, w której ujawnia, że możliwe jest przejęcie konta osoby, która ma konto w GitLabie, poprzez funkcjonalność resetu hasła. No i w chwili, kiedy GitLab informuje użytkowników, no to oczywiście ta wersja SaaSowa, wersja GitLab.com jest już spatchowana, no ale GitLab ma jeszcze dwa swoje produkty: Community Edition i Enterprise Edition, czyli te wersje, które instalujemy sobie na środowiskach on-premowych. Podatność wyceniona w CVSS-ie na dziesiątkę, maksymalnie na ile się oczywiście w CVSS-ie podatność wycenić da. No i słuchajcie, podatność bardzo prosta, wręcz taka, kary. Bardzo prosta, do bólu prosta, taka jaką możecie spotkać w labach dotyczących… dotyczących bezpieczeństwa web aplikacji. Tutaj chodziło o to, że po prostu w parametrze przekazywaliśmy kolejny adres e-mail, adres e-mail atakującego i link do resetu leciał tak naprawdę na dwie skrzynki mailowe: na skrzynkę mailową konta, które było atakowane, no i na skrzynkę mailową atakującego, który w tym momencie po otrzymaniu takiego maila przechwytywał po prostu ten adres URL z tokenem do resetu hasła. Słucham, Andrzej.

Andrzej: Mam pytanie. O kurczę, ale balony poleciały. Mam pytanie, bo ja nie wchodziłem tak mocno w tą podatność, czytałem o niej z grubsza. Wiem, że chodzi o reset hasła, ale czy tamten e-mail szedł w jednym parametrze? To znaczy, dało się po prostu do niego dodać przecinek plus kolejny e-mail i aplikacja po prostu wciągała listę i wysyłała na wszystkie, czy to były dwa osobne parametry?

Krzysiek: To była tablica. Drugi element tej tablicy to był po prostu adres e-mail osoby, która atakowała. Więc podatność bardzo prosta, skutki katastrofalne i co ciekawe… Osoba, która ją zgłosiła, zgłosiła ją w ramach oficjalnego programu Bug Bounty GitLaba na platformie Bug Bounty HackerOne. Otrzymała maksymalne bounty, które w tym momencie GitLab wycenia na 35 tysięcy dolarów. I osoba, która to zgłosiła, nie ma żadnych innych zgłoszeń na HackerOne poza tą jedną, więc tutaj robi się ciekawie. Nie wskazuję, żeby to był jakiś rasowy bug hunter z wysoką pozycją na HackerOne. Ale tutaj, Andrzej, chciałbym się odnieść do troszeczkę innej rzeczy, bo o ile sama podatność jest prosta i faktycznie robi wrażenie, jeżeli chodzi o scoring w CVSS-ie, no to… Sama podatność jakby nie bypassowała tego, że mogłeś mieć 2FA na koncie i przez ostatnie 2-3 lata wyszło co najmniej kilka dokumentów, które mówią o tym, w jaki sposób hardeningować swoje środowiska związane z Gitem. Czy masz tutaj może jakieś namyśli?

Andrzej: Mam, mam, mam. Ja dokładnie chciałem pójść w tym kierunku, a w zasadzie w dwóch kierunkach, bo to jest jedna odnoga takiego kierunku. O drugiej zaraz wspomnę, ale jeszcze wrócę o jeden krok i powiem dlaczego. Z mojej perspektywy ta podatność może w CVSS faktycznie wychodzi na dziesiątkę, ale to jest też dobry przykład, który pokazuje, że CVSS-owi nie należy tak bardzo ufać, bo to, że ta podatność może faktycznie jako sama podatność jest dziesiątką, to w większości zastosowań, gdzie GitLab jest używany, technicznie nie powinno wnosić ryzyka na poziomie 10 czy na poziomie krytyka. Teraz czemu? Bo o ile w wersji tej SaaS-owej jestem w stanie kupić ten argument, no bo z definicji taka wersja oprogramowania powinna być dostępna dla wszystkich z internetu, to już w wersji tej Community albo już po prostu komercyjnej ten rodzaj oprogramowania w ogóle nie powinien być dostępny dla wszystkich. Powinien być albo za VPN-em, więc wtedy tak naprawdę ta krytyczność mocno spada, no bo spoko, jesteś w stanie zresetować, ale i tak musisz być pracownikiem, no albo musiałeś wcześniej się włamać do naszego VPN-a, to raz, a dwa i trochę niezależnie. I tak powinno być włączone to, o czym powiedziałeś, czyli uwierzytelnianie dwuskładnikowe, które tak naprawdę zablokuje ten atak, bo pomimo tego, że zresetuję hasło, to w dalszym ciągu będę potrzebował ten drugi faktor. A najczęściej i tak to powinno być. I jedno i drugie, czyli taka instancja tak krytycznego oprogramowania jak repozytorium kodu, a kod jest własnością intelektualną organizacji, powinna być w VPN-ie i jeszcze mieć uwierzytelnianie dwuskładnikowe. Więc w takim wydaniu… Pomimo tego, że krytyczność z samej podatności może być dziesiątką, to czy ryzyko jest na poziomie critical? No i ja tutaj się z tym nie zgodzę. Zaraz chętnie wysłucham twojej oceny, ale jeszcze dodam… Czemu o tym w ogóle wspominam? Wspominam o tym dlatego, że w bezpieczeństwie bardzo często mamy takie krzyczenie: „o Boże, o Jezus Maria, pali się, mamy dziesiątkę, już teraz wrzucaj wszystko, idź patchować serwery!”. No i to jest, według mnie, to jest jedna z instancji właśnie takiej histerii, bo ja widziałem masę, masę śmieszków i masę tego typu ogłoszeń różnych ludzi na LinkedInie czy na innych social mediach, które zupełnie pomijają, że w typowym wydaniu, jak się korzysta z GitLaba, to jednak ta podatność nie jest tak mocna, jak brzmi na pierwszy rzut ucha. I jednak nie należałoby rzucać wszystkiego. A tutaj dobrą kontrą jest podatność Log4J, która faktycznie była krytyczna i faktycznie należało rzucić wszystko. Więc jeżeli zostawilibyśmy te dwie podatności ze sobą, to przy jednej faktycznie należy rzucić wszystko i… zacząć jakąś akcję patchowania, a przy tej drugiej, GitLabowej w większości przypadków komercyjnych niekoniecznie jest to prawdą. I chętnie posłucham, jak ty na to popatrzysz.

Krzysiek: Tak, ja tutaj Andrzej się zgadzam z tobą. W sensie to ryzyko zawsze rozpatrujemy w kontekście organizacji i tutaj ten krzyk podniesiony gdzieś… wśród osób trudniących się hackingiem, czy ogólnie szerzej cyber security, często nie był aż tak usprawiedliwiony. Jakbyśmy pewnie gdzieś sobie to przebadali, ile takich instancji GitLaba, CE czy EE było wystawionych przez jakieś popularne agregaty takie jak Shodan, to wtedy moglibyśmy faktycznie gdzieś wyciągnąć jakieś szersze wnioski. Tutaj odnosząc się jeszcze do 2FA, myślę, że faktycznie to, co powiedziałeś, ma sens i jest prawdą, że… tego typu instancje o takiej wrażliwości, przytrzymujących takie dane jak nasz kod, no jednak muszą być chronione w tym 2FA. Te konta, które służą do tego, żeby w tym oprogramowaniu się poruszać, powinny być zabezpieczone uwierzytelnianiem dwuskładnikowym. Tutaj fajny dokument, który o tym mówi, dosyć rozległy, ale bardzo ciekawy, CIS Supply Software. Supply Chain Security Guide, mówiący o tym, w jaki sposób hardeningować cały swój supply chain, ale jednym z etapów w tym dokumencie, jeden z takich podrozdziałów jest właśnie poświęcony temu, w jaki sposób hardeningować swoje instancje repozytoriów kodu i 2FA jest tam po prostu krokiem absolutnie obowiązkowym.

Andrzej: I ja jeszcze dodam, że po pierwsze, wszystkie referencje, do których się odnosimy, będą poniżej, w linkach, więc nie trzeba teraz googlować, ale jeszcze wracając do GitLaba, to mam trzy, nie wiem, może jedno pytanie, a dwie uwagi. Pierwsza uwaga to to, że wracając jeszcze do tego uwierzytelniania dwuskładnikowego, to należy też popatrzeć przez kontekst userów, których mamy. Co innego wdrażać 2FA dla użytkowników zwykłych, gdzie jednak trzeba ich wytrenować, będziemy mieć więcej błędów związanych z uwierzytelnianiem dwuskładnikowym, błędów takich jak, że ktoś coś zgubi i tym podobne, to jednak z GitLaba korzystają programiści. I myślę, że można ich nazwać spokojnie power userami, więc nie muszę ich trenować od… odnośnie 2FA, bo prawdopodobnie go używają już w innych serwisach gdzieś tam prywatnie. Więc już samo to gdzieś tam też ma wpływ po prostu na ryzyko, że tym bardziej 2FA powinien być zaimplementowany, jeżeli wcześniej nie był, a jeżeli jest zaimplementowany, no to wiadomo, tutaj praktycznie nie ma problemu, albo inaczej. Problem dalej jest, należy go wyprowadzić, ale prawdopodobieństwo faktycznego jakiegoś impaktu i prawdopodobieństwo zhakowania plus impact jest zupełnie inny niż można by sądzić z publicznych wypowiedzi. Przy czym można też instancję wyciąć z internetu czasowo, bo teraz popraw mnie, jeśli się mylę, ale o ile dobrze kojarzę, to to było w samym GitLabie, nie w Gicie. Czyli w dalszym ciągu ja byłbym w stanie jako inżynier pracować i pushować swoje zmiany. Nie byłbym w stanie tylko skorzystać z samej instancji GitLaba, czyli nie byłbym w stanie się do niego zalogować i tam, powiedzmy, zrobić pull requesta czy merge requesta, albo obsłużyć jakiegoś istniejącego, co jest akceptowalne przynajmniej przez jeden, dwa, trzy dni, nawet w dużych organizacjach pod kątem kosztów. Więc też nie jest to takie tragiczne, ale ja mam też jedno pytanie, na które nie znalazłem odpowiedzi, jak gdzieś tam szukałem, szukałem tutaj podatności informacji, może ty, może tobie się obiło o uszy. Mianowicie, od kiedy ta podatność istniała, no bo ona kiedyś musiała wejść, GitLab jest oprogramowaniem otwartym, zakładam, że ten kawałek też jest otwarty, więc można zobaczyć zmiany. Mnie interesuje, od kiedy ta podatność weszła, czyli jak długo żyła od momentu, kiedy weszła, do momentu, kiedy została znaleziona. To raz. Tak czysto inżynieryjnego spojrzenia, a dwa, dlaczego nie została wykryta podczas testów. Bo scenariusz, o którym mówisz, czyli po prostu wysyłam więcej argumentów, raz, że tego samego rodzaju, a dwa, różnego rodzaju, do jednego parametru, no to jest klasyczny przykład fuzzingu i to nie jakiegoś super zaawansowanego. Więc nie wiem, ale się domyślam, że powinno to zostać wykryte w testach. No i moje pytanie jest, czemu nie zostało wykryte w testach, zarówno tych dynamicznych, ale również statycznych, bo to też jest problem, który w analizie statycznej powinien zostać odkryty, bo to jest typ danych, jaki przyjmuję. Jeżeli przyjmuję do tablicy coś, co nie powinno być ewidentnie tablicą, tylko powinno być stringiem, to dlaczego? Raz, że mogę sobie napisać test jednostkowy pod tą logikę, a dwa, że mogę w sumie, czy analizę statyczną taką regułkę mógłbym napisać. Pewnie regresyjnie tak, ale w przyszłość nie jestem pewien. Musiałbym nad tym głębiej pomyśleć, ale na pewno jestem w stanie napisać test jednostkowy, w którym po prostu sprawdzę, że ten parametr, który przychodzi, nie powinien być tablicą. I dlaczego to nie zostało zrobione? Czy widziałeś jakieś takie opracowanie, omówienie, nawet w formie jakiegoś krótszego komentarza, ale pod tym kątem tej podatności? Czy nie? Ja nie widziałem. Nawet na Twitterze.

Krzysiek: Ja generalnie cenię notki od GitLaba za transparentność. Wiele z ich incydentów było dosyć fajnie opisanych, a tutaj akurat nie tłumaczyli się zbyt szeroko, w jaki sposób doszło do tego, że zmiana w kodzie spowodowała pojawienie się tej podatności. Co do samego fixa, pewnie łatwo by było znaleźć po prostu w repozytorium GitLaba, kiedy… kiedy to zostało naprawione, więc można by było spokojnie założyć, od jakiego czasu była z nami ta podatność. Tutaj GitLab w swojej notce głównie skupił się na tym, w jaki sposób właściciele self-hostowanych instancji GitLaba mogą sprawdzić, czy ktoś tą podatność próbował wyeksploitować, czyli po prostu przejrzyjcie logi i standardowe… punkty związane z tym, żeby zabezpieczyć swoje konta uwierzytelnianiem dwuskładnikowym.

Andrzej: Okej, czyli jakiegoś takiego szerszego komentarza nie ma. Ciekawy case. Ciekawy case. Warto byłoby go prześledzić. Na pewno byłby dobrym materiałem. No może niekoniecznie na cały osobny artykuł, ale na jakiś Twitter storm czy jakąś wrzutę na sociale. Myślę, że się tutaj nadaje. Natomiast ja mam kolejną sprawę, która się trochę łączy z tą, o której ty powiedziałeś, bo przejdę dalej. Przemyślałem trochę tego GitHuba. GitLaba. GitHub jest wolny od błędów. A przynajmniej takich. Nie, oczywiście, że też atakami. GitHub też miał swoje krytyczne błędy na przestrzeni lat. I też całkiem fajnie to opisuje. Mają taką podstronę GitHub Security, gdzie nie tylko opisują inne incydenty, ale też takie właśnie związane z GitHubem. Trochę się wypłacili za to, bo też dość fajne sumy tam za to płacili. Chyba nawet mieli, też mieli takie wypadki, że płacili po ileś dziesiąt, nawet nie jestem pewien, czy nie tylko tam setka tysięcy dolarów. Bardzo możliwe. Tak, bo oni tam, oni się tam jeszcze pali, ale to też były podatności tego właśnie typu. Z tego co pamiętam, one były trochę bardziej złożone, ale tego typu, że… totalnie umożliwiały kompromitację całej instancji GitLaba, w tym oczywiście GitLaba oficjalnego w wersji SaaS-owej. Więc żadne oprogramowanie nie jest wolne od błędów. To myślę, że każdy, kto nas zna, to już o tym słyszał od nas nieraz. Ale w tym samym temacie przejdę do materiału, który znalazłem, jak się przygotowałem do naszego spotkania na przestrzeni ostatniego miesiąca, który podsumowuje CVE, czyli numerki dla podatności, identyfikatory podatności, które są wypuszczane w cyklu rocznym. Taka podatność, którą ktoś znajdzie, ona nie musi mieć numerka CVE, bo taki numerek trzeba zawnioskować i można zrobić to albo samemu, albo organizacja czy aplikacja, do której po prostu zgłosimy taką podatność, ona może też o to zakwestionować. Może też totalny third party o to poprosić, ale końcem końców ktoś musi o to wystąpić. Samo z siebie się nie pojawi, więc można na to popatrzeć trochę tak, że nie mamy pełnego obrazu. Ale mamy dość dobry obraz i to, co wychodzi z tego artykułu, który ja znalazłem, on jest oczywiście oparty na konkretnych twardych danych, więc to nie jest opinia autora, tylko konkretne twarde dane. Wychodzi na to, że w zasadzie w zeszłym roku, w 2023, wyszło prawie 30 tysięcy CVE, konkretnie 28 902, co oznacza, że mamy wzrost względem poprzedniego roku, czyli 2022, o 15%, co jest dość dużym wzrostem i nie tylko. To jest może ciekawe, tylko to, że taki wzrost z roku na rok w zasadzie obserwujemy od kilku lat i konkretnie… w tym artykule, bo to jest jakiś autor, bada tą ilość CVE i od kilku lat ma otwarty projekt, link do tego projektu będzie, natomiast wywnioskował, że mamy w zasadzie od 2017 mamy cały czas wzrost procentowy i ten wzrost jest powyżej 10% w skali roku względem poprzedniego, więc tak naprawdę te CVE cały czas rosną. Czyli ilość podatności w oprogramowaniu cały czas rośnie. No i jest to… Chciałem użyć słowa przykre, ale dla nas bezpieczników może i to nie jest przykre, bo może powinniśmy się cieszyć, bo mamy więcej pracy. Ale pokazuje to pewien smutny obraz, że bezpieczeństwo się może nie polepsza tak szybko, jakbym ja sam osobiście chciał, a do tego jeszcze dorzucę, że… Z tych dodatkowych danych, które autor wyłowił, jest informacja o tym, że przeciętny, nieprzeciętno, średni wynik CVSS dla podatności, które były zgłaszane w zeszłym roku, wyniósł 7,12, czyli możemy założyć, że 7, więc całkiem poważna podatność, z czego 36 podatności z prawie 30 tysięcy. Można powiedzieć, że niedużo, ale 36 z nich miało wynik perfekcyjny, czyli dziesiątkę, tak jak GitLab. Czy to było zasłużone, to nie wiem, bo nie przyjrzałem wszystkich tych podatności, które miały tą dziesiątkę, ale 36 podatności z dziesiątką, no to tak naprawdę w skali roku, to nam daje 3 podatności na miesiąc średnio, które mają dziesiątkę. No to jeżeli każda z takich podatności zajmie nam około tygodnia wyprowadzanie jej w dużej organizacji, bo trzeba coś tam zastopować, etc. No to tak naprawdę mamy miesiąc pracy dla pojedynczego człowieka full-time, full-time employee, który wyprowadza cały czas pojedyncze CVE w naszej organizacji. I powiedz mi, Krzysiek, jak to wygląda z Twojej perspektywy, bo ja wiem, że pracujesz w firmie produktowej, gdzieś tam masz styk z tymi podatnościami, z różnych skanów etc., więc niejako nie tylko patrzysz na te dane, ale też dotykają cię te CVE. Czy zauważasz na przykład wzrost problemów i wzrost z wyprowadzaniem CVE?

Krzysiek: projektu siebie.

Andrzej: Tak, głównie z racji tego, że drzewa zależności robi się coraz to większe. Te poziomy są coraz głębsze. NPM tutaj chyba jest w ogóle absolutnie liderem, jeżeli chodzi o ilość zaciąganych zależności przechodnich przy okazji zaciągania jakiejś paczki. Tutaj z głowy rzucę, że sam Express, czyli jeden z popularniejszych frameworków do budowania API w Node.js zaciąga bezpośrednio 30 zależności, a każda z tych zależności dociąga kolejne zależności, więc… Mówiąc w kontekście firmy produktowej, która część swojego produktu oczywiście opiera na warstwie frontendowej, gdzie nie jest tajemnicą, że tak jak cały świat są tam wykorzystywane zależności z NPM-a, to widać, że ilość tych podatności rośnie, co nie oznacza, że wszystkie z nich są możliwe do eksploitacji. Często jest tak, że to CVSS, Common Vulnerability Scoring System, faktycznie nie bierze pod, bardzo często, w ogóle prawie wcale nie bierze pod uwagę kontekstu organizacji, w jaki sposób miałoby… czy aplikacji, bo w jaki sposób miałoby to robić. Więc tutaj gros pracy polega na tym, żeby odpowiednio te podatności z tych między innymi paczek po prostu filtrować.

Andrzej: To mam tutaj pytanie i jeszcze jedno. Zaraz możemy przejść do twojego kolejnego wniosku, do twojego kolejnego znaleziska, które się dość dobrze łączy z tym, o czym przed chwilą właśnie powiedziałeś. Ale tutaj mam jeszcze jedno pytanie, bo wspomniałeś o tym, że oczywiście nie wszystkie te podatności mają taką krytyczność, jaka wynika z CVSS. Wspomniałeś o przechodnich podatnościach i też potem powiedziałeś, czym one są, czyli jeżeli mamy A, B, C, no to B jest podatnością dla A, a C jest podatnością dla B, no to ta C jest przechodnią podatnością dla… zależnością dla tego pakietu A, bo jest dalej w łańcuchu, ale dalej to A musi mu zaufać. Tylko ja mam tutaj pytanie, bo nie tylko CVSS jest tutaj nie do końca pomocny, ale też samo CVE w tym kontekście, że jak często się spotykasz z false positive? I czemu o to pytam? Dlatego, że ja przy tym materiale o CVE statystycznym dodałem sobie też inny materiał, gdzie ostatnio, gdzie autor zauważył, że kilka tygodni temu BleepingComputer, dość popularny serwis, opublikował informację, że ponad 150 tysięcy stron jest podatne na jakąś tam podatność, która była w pluginie do WordPressa. Więc rozumowanie autora było takie, że skoro mam WordPressa, a ten WordPress ma ten plugin i ja wiem, że tych WordPressów z tym pluginem jest 150 tysięcy, no to wszystkie z nich są podatne. Tylko potem, jak się trochę głębiej, głębiej w tym zakopało, to dochodzi się do wniosku, że no nie do końca jest tak, bo podatność została wprowadzona w pewnej wersji tego pluginu, a wcześniej jej nie było. Czyli podobny przypadek, o którym przed chwilą mówiliśmy w GitLabie, gdzie pytanie, to nie jest tak, że GitLab jest… był podatny na ten reset hasła od zarania dziejów, tylko on w jakimś momencie został podatny. I teraz pytanie, ile wynosił ten czas. A tutaj mamy podobne pytanie, czyli ten plugin wprowadził tą podatność, programista wprowadził podatność do tego pluginu w którejś wersji, więc jeżeli moja strona, co oczywiście może nie jest dobrą praktyką, ale jeżeli moja strona nie aktualizuje się samodzielnie, a mi się zapomniało przez kilka wersji zaktualizować… moją stronę, moje pluginy, mojego WordPressa, to trochę absurdalnie, ale jestem ja bezpieczny, a ci, którzy aktualizują, są niebezpieczni, bo oni mają już najnowszą wersję, a ta najnowsza wersja była podatna, bo podatność istniała w wersji od 2.7.0 do wersji najnowszej, ale poniżej 2.7.0 jej nie było. I teraz wracając do mojego pytania, właśnie o takie false positive. Czy jak to wygląda tutaj? Czy zdarzają się takie przypadki? Albo czy kojarzysz nawet po prostu ręcznie, czy gdzieś tam weryfikowałeś, że nagle się okazuje, że podatności żadnej tutaj faktycznie nie ma, a NPM mi krzyczy, że jest. NPM to nie powinien, bo on sprawdzi wersję, ale ktoś mi tam krzyczy, że jest.

Krzysiek: False positive trochę jest. Część z nich ma stricte powiązanie ze środowiskiem, w którym występuje, czyli okej, mamy podatność w jakiejś paczce, ale jest możliwa do eksploitacji tylko w konkretnej wersji Node.js czy w jakichś innych okolicznościach, więc no… Tu jest dużo niestety manualnej roboty, ponieważ bardzo jest to ciężko powiązać z tym, jak wygląda nasze środowisko i zmeczować to jeden do jednego do tej podatności, więc tak naprawdę nasze skanery wypluwają. Nasze, mówię ogólnie, skanery całego świata Cyber Security wypluwają masę numerków CVE w swoich raportach, a potem musimy tymi przysłowiowymi łopatami to wywalać za okno, nie?

Andrzej: Mam odpowiedni obrazek do tego, kleję go.

Krzysiek: Ale pytanie tutaj do ciebie, Andrzej, króciutkie, a z punktu widzenia konsultanta, bo ja mam taką perspektywę głównie jednego produktu, jednego projektu, w którym obecnie współpracuję, no ale ty tych perspektyw masz jednak troszeczkę więcej.

Andrzej: Z mojej perspektywy i mojego doświadczenia problem jest bardzo duży. W zasadzie to jest jeden z większych problemów, jakie istnieje w organizacjach, bo z racji tego, że konsultuję, to raczej konsultuję większych niż mniejszych, bo to już nawet nie chodzi o fundusze, tylko po prostu mniejszym graczom. Często nie są jeszcze na tym poziomie, żeby potrzebować bezpieczeństwa, bo bezpieczeństwo jest pewnym… może nie luksusem, ale z jakimś dodatkiem. Najpierw trzeba mieć biznes, który działa, a potem można się zastanawiać, żeby działał dobrze. I jednym z tych dobrze jest bezpiecznie. A dopiero wtedy to wchodzi. Więc u tych większych jest to główny problem w ogóle związany z cyberbezpieczeństwem. To definitywnie jest właśnie problem z podatnościami, ze znanymi podatnościami. Tutaj właśnie mam na myśli o tych, które mają swoje numerki CVE, które wypluwają nam się do różnych dashboardów przez różne skanery bezpieczeństwa i które potem trzeba po prostu obsługiwać. A problem jest taki, że dokładnie to, co powiedziałeś, tych false positive jest całkiem sporo. I u ciebie może jest akceptowalna ilość dlatego, że po prostu jest jeden produkt, więc powiedzmy zakres, granice są twardsze, łatwiej wokół nich się obracać. Natomiast łatwo sobie wyobrazić, że jeżeli miałbyś takich projektów na przykład 50, no to już by był problem niejako tragiczny. A tak to wygląda u dużych graczy, bo mają wiele różnych produktów, te produkty mają, to są całe systemy, te systemy mają podsystemy, to są bardzo duże, bardzo skomplikowane systemy IT, które może na poziomie pojedynczych aplikacji, nie są jakieś super skomplikowane, ale na poziomie systemu, czyli tych wszystkich aplikacji, które ze sobą rozmawiają, no to complexity jest duże. No i problem z podatnościami, nawet właśnie z takimi prostymi ze skanów, jest dość duży, a to… że nie można w 100% zaufać skanerowi, że nie można w 100% zaufać takiemu kalkulatorowi CVSS, czy tym danym, które przychodzą mi z różnych źródeł danych o podatnościach, no to tylko pogarsza ten problem, bo gdybym ja mógł zaufać takiemu skanerowi, no to byłoby lepiej. Tutaj napomknę, że przykładowo, ja kiedyś pracowałem w takiej firmie Sekunia, i w Sekunii zajmowaliśmy się weryfikacją tego, że jeżeli mamy jakiś raport podatności, to ten raport jest faktycznie rzetelny. I za to nam płacili nasi klienci. Mieli osobny vulnerability intelligence feed, który leciał do nich i oni wtedy wiedzieli, że to muszę na pewno patchować, bo to jest zweryfikowane, ta podatność faktycznie istnieje w tej i w tej wersji, a tego nie muszę. Czyli przykładowo, tak jak powiedziałem o tym pluginie do WordPressa, no to moja praca wyglądała tak, że przychodziłem codziennie, miałem powiedzmy takich 20 podatności do weryfikacji, no to miałem środowisko, miałem to wszystko poautomatyzowane, odpalałem sobie instancję VM-ki, instalowałem tego plugina i po prostu go hakowałem, sprawdzałem, w której wersji faktycznie to będzie, w której potem powstało, jeżeli miałem dostęp do Gita i takie pełne informacje, dorzucałem do raportu i klient potem mógł podjąć lepszą decyzję, świadomą decyzję. W chwili obecnej nie jestem pewien, czy takie feedy istnieją, a przynajmniej u nas na rynku nie widziałem, żeby firmy z czegoś takiego korzystały. Raczej to są feedy typowe, że NVD wypuściło nowe CVE i trzeba o krytyczności 10, więc trzeba pójść i to rozwiązać. Więc sytuacja jest… jest trudna, jest trudna do rozwiązania.

Krzysiek: To ja się tylko odniosę do tematu tych feedów i zaraz przechodzimy do kolejnego tematu. Myślę, że taką próbą odpowiedzi, albo przynajmniej pomocy tutaj w tej sytuacji jest feed, który udostępnia amerykańska CISA, czyli KEV, o ile dobrze pamiętam, Known Exploited Vulnerabilities Catalog.

Andrzej: Już sprawdziłem. Known Exploited Vulnerabilities Catalog. Kontynuuj.

Krzysiek: Dokładnie, tak. I nowy wskaźnik stworzony bodajże przez tą samą organizację, która stoi za CVSS-em. FIRST, tak się nazywa chyba ta organizacja, jest nowy wskaźnik EPSS.

Andrzej: Wyjaśnij, wyjaśnij, bo ja wiem, o co chodzi, a to jest faktycznie bardzo ważny wskaźnik. On jest nowo powstały, ale jest mocno przydatny.

Krzysiek: Tak, który pokazuje nam szansę w ujęciu procentowym na to, że taka typowa statystyczna aplikacja przeciętna zostanie, jeżeli jest podatna na dane CVE, to faktycznie atakującym uda się to CVE wykorzystać i bodajże… Kilka tygodni temu czytałem bardzo fajną analizę dla Log4J w kontekście właśnie tego wskaźnika EPSS, który faktycznie tam wystrzeliwał gdzieś ponad progi 90 paru procent, jeżeli mówimy o prawdopodobieństwie, że zostaniesz przez tą podatność po prostu wykorzystana, że ta podatność zostanie wykorzystana.

Andrzej: Jeszcze dla pełności EPSS oznacza Exploit Prediction Scoring System. Więc po prostu sposób na punktowanie i przewidywanie tego, czy dana podatność zostanie wykorzystana. Dokładnie to, o czym powiedział Krzysiek. Dobra, przejdźmy do twojego kolejnego wątku. Ja już nie mogę doczekać, bo też widziałem, że się pojawił. Nie miałem czasu rzucić okiem, ale widziałem, że dodałeś do tabelki, gdzie sobie zbieramy te materiały, więc pomyślałem, dobra, Krzysiek, kogo nie.

Ataki na Łańcuchy Dostaw

Krzysiek: Tak, bardzo ciekawy raport, może nie stojący w kontrze, tylko bliźniaczo podobny do tego, co od kilku edycji wydaje Sonatype. Tym razem raport nie od Sonatype, tylko od ReversingLabs, The State of Software Supply Chain Security. Bardzo fajny, zgrabny raport prezentujący stan ataków na łańcuchy dostaw w kontekście tej konkretnej zależności, no bo gdybyśmy spojrzeli na łańcuch dostaw, to oczywiście nie są tylko nasze zależności znane z repozytoriów paczek takich jak NPM, NuGet czy PyPI. No i tutaj autorzy z Reversing Labs podają, że w okresie od 2020 do 2023 ilość złośliwych paczek, czyli takich, w których złośliwy kod został dodany intencjonalnie, nie mówimy tutaj o paczkach, które zawierają podatności wynikające z ludzkiego błędu, tylko o paczkach, które faktycznie zostały… albo zostały stworzone intencjonalnie, aby być złośliwe, no to ilość tych złośliwych paczek w tym okresie czasu, o którym mówiłem, wzrosła o 1300%, więc notujemy tutaj gigantyczny wzrost. Jakby rozwijając to na konkretne repozytoria, oczywiście króluje NPM. I wcale nikogo tutaj to, Andrzej, nie powinno dziwić, no bo NPM swoją skalą po prostu obejmuje, że tak powiem, kilka albo nawet kilkanaście innych repozytoriów paczek. Spokojnie moglibyśmy tam pomieścić NuGet-a, PyPI, Gemsy, repozytorium pakietów z PHP-a, Packages i jeszcze by się znalazło troszeczkę miejsca, więc ta skala tutaj jest po prostu reprezentatywna. Tego malwareu było tam zdecydowanie najwięcej, ale ciekawostka jest taka, która wynika z tego raportu, że coraz więcej malwareu pojawia się w PyPI-u. I autorzy wiążą to z boomem, który ostatnio, przez ostatni rok, dwa, widzimy w kontekście świata uczenia maszynowego oraz szeroko rozumianej sztucznej inteligencji. I teraz takim clou tego raportu jest to, że o ile organizacje obyły się już, może nie obyły się, ale przynajmniej są świadome tego, że to, co zaciągamy, może być podatne, bo ktoś popełnił błąd i znajduje się tam podatność, to statystycznie ta wiedza na temat tego, że paczki mogą być intencjonalnie infekowane jest po prostu niska, a skutki są fatalne, bo przeważnie tego typu ataki, ataki na łańcuchy dostawcze w kontekście repozytoriów paczek, prowadzą do tego, że zainfekowana maszyna dewelopera jest po prostu całkowicie skompromitowana. Tutaj mówimy o zainfekowanej maszynie dewelopera, ale te paczki idą dalej i kompromitują również całe środowiska CI. No i tutaj, Andrzej, komentarz twój do tego. Bo widzę, że tutaj machasz głową i chciałbyś coś powiedzieć.

Andrzej: Tak, jak tylko mam możliwość, ja lubię gadać o bezpieczeństwie, to mogę gadać nawet sam u siebie. Chociaż to może wtedy nie wygląda najzdrowiej. Ale jak mam założone słuchawki, to tak jakbym z kimś rozmawiał, więc z boku, postronny obserwator dalej myśli, że wszystko jest okej. Pierwszy komentarz. Jeszcze raz zaznaczę to, co powiedziałeś w zasadzie dwa razy, żeby dobitnie, dobitnie nasz słuchacz zrozumiał tą różnicę, albo żeby po prostu jeszcze raz mu się wbiła do głowy. Ta różnica pomiędzy atakiem na łańcuch dostawczy a podatnością w zależności. To są dwa zupełnie różne problemy, pomimo tego, że bardzo często i nawet bezpiecznicy je mieszają. Czyli mamy bezpieczników, ale nie tylko bezpieczników, ogólnie inżynierów, natomiast od bezpieczników wymagałbym, żeby tego nie mieszali. Następuje mieszanie jednego z drugim i kategoryzowanie tego jako jeden rodzaj błędu, a tu nie jest jeden rodzaj błędu, to są zupełnie dwa różne problemy. Owszem, można je rozwiązywać w podobnym punkcie procesu wytwórczego, DevSecOps, Secure SDLC, nawet można rozwiązywać je tym samym narzędziem, jeżeli mamy repozytorium, jeżeli mamy repozytorium artefaktów w naszym pipeline, przykładowo wcześniej wspomniałeś o Sonatype, no to Sonatype jest takim repozytorium, ale niektórzy mogą znać też JFrog, Artifactory, które u nas na rynku jest dość popularne, natomiast jeżeli mamy takie repozytorium, to rozwiązanie problemów podatnych bibliotek, podatnych zależności, ale też złośliwych, bibliotek złośliwych zależności, działoby się w tym jednym punkcie. Mogłoby też gdzieś w innym, to byłoby bardziej oportunistyczne, ale ten jeden punkt jest takim wzorcowym rozwiązaniem tego problemu. Natomiast tych dwóch problemów, natomiast to są dwa osobne problemy, dlatego że podatności, tak jak wspomniałeś, w bibliotekach wynikają z błędu ludzkiego. Ktoś popełnił błąd, tylko że nie w naszym kodzie, nie nasz programista, a jakiś zewnętrzny programista, z którego my kodu korzystamy. Czy bierzemy jego bibliotekę, on popełnił błąd, tam jest jakaś podatność, przez to nasza aplikacja może jest podatna, może nie jest podatna, to zależy, czy utylizuje daną funkcjonalność. I to jest przykład Log4J. I to nie była podatność związana z łańcuchem dostaw, nie było tam nic o łańcuchu dostaw, to była po prostu podatna biblioteka. Natomiast zagrożenia ataki na łańcuchy dostaw, na łańcuch dostawczy, no z samej nawet nazwy wynika, że musi się coś dziać w momencie, kiedy coś dostarczam, skądś biorę. I to coś dzieje się albo w dwóch scenariuszach, albo atakuje sposób, w jaki ja to pobieram, albo atakuje to miejsce, z którego ja pobieram, albo jeszcze wcześniej po prostu w jakiś inny sposób infekuje to, co dostaje się do tego miejsca, czyli na przykład do repozytorium NPM-a. Natomiast to wszystko to są akcje świadome atakującego. Dlatego mówimy tutaj o tej złośliwości, że ta paczka została świadomie zainfekowana, tam została dodana jakaś logika, która robi coś złego, a nie jest to błąd, nie jest to pomyłka. I to są dwa różne problemy, które należy jasno sobie w głowie rozgraniczyć, bo o ile problem z podatnymi zależnościami jest powiedzmy trochę prostszy do rozwiązania, no to ten problem ze złośliwymi podatnościami to jest ten faktyczny problem, który od kilku lat bardzo mocno wzrasta na znaczeniu, tak jak powiedziałeś, 1300%. To jest całkiem sporo, więc to jest ten problem z tymi złośliwymi pakietami. I tam jest kilka, może nawet kilkanaście sposobów, jak można… przeprowadzać takie ataki, ale wszystko sprowadza się do tej złośliwości i do tej umyślności akcji osoby, która nas, albo nas, albo oportunistycznie wiele organizacji chce zaatakować. To, co mi się podoba w tym raporcie, tak jak powiedziałem, ja w niego nie wchodziłem, nie czytałem, ale to, co mi się w nim podoba, to taki recap, spis, guidelineów od różnych instytucji i europejskich i tych z US, więc mamy coś o dyrektywie NIS2, o której też nasi słuchacze pewnie słyszą. Mamy oczywiście Secure by Design i Secure by Default, no to wiadomo, te keywordy muszą być. Mamy o regulacjach ze Stanów Zjednoczonych, które wchodziły na przestrzeni ostatnich dwóch, trzech lat, zostało wydanych kilka rozporządzeń. Co mnie trochę zdziwiło, to to, że nie ma tam żadnego odniesienia i to sobie sprawdziłem do Cyber Resilience Act, CRA, o którym w zasadzie może porozmawiamy w kolejnym odcinku albo nagramy cały dedykowany odcinek, dlatego że to jest coś, co nadchodzi i coś, co może trochę namieszać na rynku wytwarzania oprogramowania, całym rynku wytwarzania oprogramowania, przynajmniej w Unii Europejskiej, ale to sobie zaparkujemy, natomiast tutaj w tym raporcie podoba mi się to podsumowanie, bo mamy po prostu jeden kawałek, w którym możemy sobie zobaczyć, że a, dobra, no to faktycznie w tym temacie się coś dzieje na poziomie regulacji i to, co się dzieje, to a, tu jest link do tego dokumentu, tu jest link do tego dokumentu, a tu jest link do tego dokumentu, więc to jest przydatne, szczególnie jeżeli ktoś wcześniej nie słyszał o tych wszystkich rozporządzeniach i jest w tym temacie na świeżo i jeszcze po prostu nie jest rozeznany. Więc to jest coś fajnego. To, co ty wspomniałeś o tym AI związanym z, albo może nie związanym, ale jako powód tego, że ataki wzrastają w ekosystemie Pythonowym PyPI, to jest bardzo ciekawy wniosek, albo inaczej. Ja tutaj mam taką, myślę, że ciekawą uwagę, że to też fajnie pokazuje, że atakujący w tej chwili nikt nie hakuje for fun. Ja to bardzo często mówię na swoich szkoleniach, nikt nie hakuje for fun. To jest biznes atakujący, po prostu cyberprzestępcy, takich nazwijmy, nie robią tego dla zabawy, tylko robią to, żeby mieć pieniądze. Więc będą szli tam, gdzie mogą zmaksymalizować stopę zwrotu. To jest normalny biznes. Tam ludzie siedzą w Excelach i obliczają jaką będą stopę zwrotu z linii biznesowych i idą w tą linię biznesową, która zapewni im największą stopę zwrotu. To jest najzwyklejszy biznes. Nikt tego nie robi for fun. I to jest świetny przykład na to, że aha, czyli AI zyskuje na popularności, w związku z AI zyskuje system PyPI, no to w związku z tym atakujący przenoszą się na ten system, bo widzą, że jest coraz więcej przykładowo pobrań, które służą do działania w AI-u, w LLM-ach, w ekosystemie PyPI-owym i próbują po prostu zaatakować tę organizację, zaatakować tych ludzi. Co jest wyrównane właśnie z tym spojrzeniem, że nikt tego nie robi for fun, tylko po prostu robi się to dla pieniędzy, co ma swój plus, ma też ma swój minus. Plus ma taki, że my ze strony defenderów jesteśmy w stanie lepiej szacować prawdopodobieństwo ataku, bo jesteśmy w stanie do tego dorzucić pewne spojrzenie ekonomiczne. Czyli nie tylko, że technicznie coś można zrobić, tylko czy komuś się będzie opłacało to zrobić. To jest ważne pytanie. Czy komuś będzie opłacało to zrobić, a nie tylko, czy jest w stanie to zrobić. Bez tego spojrzenia zaczyna się trochę takie wróżenie z fusów, które często prowadzi do, nie kojarzę polskiego odpowiednika, ale po angielsku byłoby to misallocation of resources. Czyli po prostu zasoby wrzucamy nie tam, gdzie chcemy, nie tam, gdzie faktycznie pozwolą nam na lepszą stopę zwrotu jako biznesowi, który tworzy jakiś produkt. Wrzucamy je w jakiś kawałek bezpieczeństwa, który końcem końców może impact byłby duży, ale prawdopodobieństwo jakiegoś haku jest małe, bo po prostu z czysto ekonomicznego punktu widzenia się po prostu nie opłaca tego robić nikomu. Natomiast takie podejście, takie nałożenie tych okularów ekonomicznych jest przydatne. Więc w zasadzie odnośnie tego raportu to z mojej strony tyle.

Krzysiek: Chciałem tutaj dodać jedno pytanie do ciebie, Andrzej. Pytanie-zagadkę. Coś, co będzie, myślę, całkiem ciekawe też dla słuchaczy. Jak myślisz statystycznie, jaki kraj najbardziej trudni się tego typu atakami? Jaki kraj na świecie odpowiada?

Andrzej: Jaki kraj na świecie odpowiada w największym stopniu za ataki na supply chain w kontekście software’u? Nie wiem, choć się domyślam. A domyślam się, że Rosja.

Krzysiek: No i tutaj cię zdziwię, Rosja jest w topce, ale na miejscu pierwszym jest Korea Północna. I tutaj dookoła tego tematu, robiąc research, zdobyłem informację, że faktycznie działania Korei Północnej bardzo mocno się intensyfikują. W kontekście repozytoriów pakietów. Ciekawe jest to, że grupy, które są sponsorowane oczywiście przez agencje wywiadowcze, tutaj z Korei Północnej, podchodzą do tego typu ataków w taki sposób, że po prostu udają agencje rekrutacyjne, zapraszają deweloperów do udziału w zadaniu rekrutacyjnym. I już w tym zadaniu rekrutacyjnym, w tym projekcie umieszczone są złośliwe zależności, więc jak deweloper klonuje takie repozytorium i chcąc odpalić ten projekt po raz pierwszy raz wpisuje yarn install czy npm install, no to w tym momencie już te złośliwe paczki trafiają na jego komputer, no i przeważnie przez pre-install zaciągany jest malware. Także tutaj taka ciekawostka dla słuchaczy, w jaki sposób można wpaść.

Andrzej: Czyli wszystko sprowadza się do klasycznego powiedzenia, że najsłabszym ogniwem jest człowiek. Gdyby tylko nie ludzie, to te komputery byłyby bezpieczne. Oczywiście, oczywiście trochę śmiechem, ale trochę serio, ale bardziej śmiechem niż serio, bo na koniec dnia zadaniem bezpieczników jest to, żeby systemy były bezpieczne niezależnie od moich użytkowników, bo jeżeli ja mam zrzucić winę na użytkowników, to w zasadzie co ja mam tam robić? To od czego ja jestem? No przecież gdyby użytkownicy wiedzieli i nie popełniali błędów, to ja nie byłbym potrzebny w całej układance. Więc może nie do końca są tutaj wyrównane incentywy, żeby działać nad bezpieczeństwem, ale to temat na zupełnie osobny odcinek, bardziej na rant. Taki w amerykańskim „get off my lawn”, jak taki stary człowiek. „Damn kids”. Dobra, ja tutaj przejdę trochę sprawnie do czegoś podobnego, a można powiedzieć może nie podobnego, ale do tematu zahaczającego o łańcuch dostaw, bo łańcuch dostawczy, przynajmniej w momencie, jeżeli mówimy o budowaniu software’u, budowaniu oprogramowania, w dużej mierze polega na, może nie w dużej mierze polega na, ale opiera się, polega na potoku CI/CD. Więc… Jeżeli faktycznie chcemy mieć taką fabrykę, która nam buduje software, więc piszemy sobie na lokalnej maszynie, potem dajemy git push, coś tam się robi na repozytorium, potem zaczyna się wszystko samo triggerować i wchodzi nam na produkcję i mamy tych 15 release’ów dziennie, no to musimy mieć sprawny potok CI/CD, bo bez tego się po prostu to nie uda. Ja już pomijam o szerszym, o istnieniu szerszego procesu DevOps, czy DevSecOps, czy SecodevOps, nie ma znaczenia, ale pomijam całe to, chodzi mi teraz, że ten potok CI/CD, no, gdzieś tam będzie musiał być, no i oczywiście to hakowanie potoku CI/CD, potoków, też się odbywa, i to na pewno zdajesz sobie z tego sprawę. Tak, tak. I ja padłem na taką ciekawą podatność, podatność, a tak. Zależy, jak na to popatrzeć. Ja bym powiedział cały atak, dlatego że tam była po prostu jakaś jedna podatność, która doprowadziła do innego problemu, który prowadzi do kolejnego etc. Więc upraszczając, jest to po prostu cały atak na właśnie pipeline CI/CD, ale związany z GitHubem. Więc wcześniej mówiliśmy o GitLabie. A teraz trochę przeskoczę do GitHuba i pokażę, że faktycznie te błędy są wszędzie. Czasami się zdarzają w GitLabie, czasami się zdarzają w GitHubie, a czasami zdarzają się w obu naraz. A o BitBuckecie nie będę wspomniał, bo kto tam jest z BitBucketa. Nie, oczywiście żarty żartami. Znam organizacje, które korzystają z BitBucketa, ale nie znam organizacji, które są zadowolone z BitBucketa, więc…

Krzysiek: Oto prawda.

Andrzej: To taki mały, uszczypliwy komentarz w kierunku produktu Atlassian. Tak, Atlassian. Zgadza się. Atlassian. Ale nie tylko z BitBucketem ludzie mają problem. Tam kilka innych produktów i też ludzie ich nie lubią. Ale wracając do meritum. O ten atak, który mi chodzi, to jest coś, co wyszło w zasadzie na początku stycznia. I on jest trochę pisany wstecz, więc on jest takim postmortem, gdy wszystko zostało już zgłoszone do firmy, więc większość tego, co jest wypisane w tym ataku, działo się w zeszłym roku na przestrzeni kilku miesięcy. Ale sam atak polegał na tym, że badacz zauważył ciekawą rzecz. Mianowicie, jeżeli jestem użytkownikiem GitHuba, to GitHub od kilku lat zaczął pracę nad tym, żebyśmy mogli też wykonywać pewne akcje, już konkretnie na GitHubie. Przez akcje mam na myśli na przykład budowanie paczek. I żeby to robić, no to wprowadzili taki mechanizm GitHub Actions. I oczywiście to nie tylko GitHub robił, GitLab też chciałby być taką platformą, która wszystko unifikuje, więc są to tacy kompetitorzy, ale w GitHubie… ten badacz zauważył ciekawą jedną rzecz, że jeżeli ja zostanę kontrybutorem do jakiegoś projektu, nieważne na jakim poziomie kontrybutorem, to znaczy ja mogę poprawić jakąś jedną literówkę, ale jeżeli poprawię tą literówkę, otworzę pull requesta, właściciel tego projektu, albo ktoś, kto ma prawa akceptowania, zaakceptuje tego pull requesta, on zostanie zmerdżowany do mastera, to ja staję się kontrybutorem projektu. Ja przykładowo sam na GitHubie jestem kontrybutorem do kilku jakichś projektów, gdzie tak naprawdę moja kontrybucja to był, no można podsumować ją w dwóch literkach, XD, no ale jestem kontrybutorem, no bo faktycznie coś tam się, coś tam zmieniłem. Ale zostając kontrybutorem danego projektu, ten badacz zaobserwował, że dostał prawo uruchamiania runnerów. I to już było dość ciekawe, bo w zależności od tego, jaki runner jest na tym GitHubie, no to może być taki, który jest efemeryczny, czyli gdzieś tam pojawia się i znika. Jest też taki, który nie jest efemeryczny. Ale i w jednym, i w drugim przypadku pozwala to na wykonanie jakiegoś kodu w obrębie tego runnera. Temu badaczowi udało się, udało się faktycznie budować pewne, dorzucać pewne zmiany na poziomie, na poziomie runnera do paczki, do akcji, które były wykonywane przez tego runnera. Co jest dość ciekawe, bo… O ile w jakichś takich typowych projektach może to nie jest ważne, ale on poszedł trochę dalej. Teraz nie jestem pewien, czy to było tylko jedna osoba, czy on tam działał z kimś, ale wydaje mi się, że chyba z kimś. Ale poszedł trochę dalej i zaczął skanować różne projekty w ten sposób, żeby jak najmocniej udowodnić nie tylko szerokość problemu, czyli jak mi się uda, do jakich dużych projektów uda mi się na przykład coś dodać, ale dwa, też jak już znalazł taki projekt, który byłby fajny, ładnie by wyglądał, ładnie by brzmiał, to też faktycznie starał się udokumentować, unaocznić ten impact, czyli nie tylko pokazać, że no patrzcie, tam jestem w stanie coś wykonać na tym runnerze, bo to z perspektywy maintainera może wyglądać jako nic nieznaczącego, ale jeżeli ja już na przykład coś… do builda, no to to już zaczyna być problem. No bo tak jak wcześniej mówiliśmy, tu otwiera się ta puszka Pandory związana z atakiem na supply chain. I to jest jeden z odłamów, dokładnie to jest jeden z odłamów ataków supply chain, gdzie kod, gdzie paczka jest infekowana, ale nie na poziomie kodu źródłowego w repozytorium, ale na poziomie potoku CI/CD, gdzie kod jest budowany, a potem jest dystrybuowany na przykład do repozytoriów zewnętrznych pakietów, takich jak NPM. I to jest jeden z odłamów tych ataków na supply chain, które oczywiście miały jakieś realne przypadki w przeszłości, więc można sobie case study różnych tego typu faktycznych case’ów przeczytać, ale tutaj to jest świetny przykład, no dość nowy, świeży, nie nowy, ale dość świeży, który to opisuje. I teraz też nie pamiętam, ile oni za to dostali, ale trochę pieniędzy za to wyciągnęli. Natomiast też komentarz na reddicie autora tego artykułu jest taki, że jeżeli uczestniczysz w Bug Bounty, tak jak wcześniej wspomniałeś na przykład w GitLabie, no to musisz niejako pokazać impact. Jeżeli nie pokażesz impactu, to albo odbiorca może w ogóle nie zrozumieć, o co ci chodzi, albo może obniżyć ci wypłatę, no bo też końcem końców nie zrozumiał, o co chodzi. Ale jeżeli pokażesz ten impact, tak jak tutaj pokazał ten impact, no to faktycznie da się na tym zarobić ciekawe pieniądze, szczególnie jeżeli tych projektów jest wiele, no bo nie chcę mówić, ale powiedzmy 1000 dolarów czy 2000 to nie są jakieś pieniądze, które zmieniają życie. No ale jeżeli znajdziemy 20 takich projektów i od każdego dostaniemy po 2000 dolarów, to zaczyna się już zbierać całkiem nieźle. A końcem końców to jest tylko jeden problem. No i to był ten problem o hakowaniu CI/CD. W zasadzie można powiedzieć trochę taki atak mnie zaciekawił, bo często przez tych odbiorców, maintainerów był taki, nazwijmy to, bagatelizowany. Typu: „a tam, co możesz mi najlepszego zrobić?”. No, mogę ci, kurczę, sporo zrobić, tylko po prostu daj mi trochę czasu, to ci pokażę.

Krzysiek: Tutaj w kontekście GitHub Actions przypomina mi się, nie mogę sobie przypomnieć konkretnie, gdzie to widziałem, chyba na Defconie albo na Blackhacie, prezentację, w której ktoś pokazywał, jak poprzez… właśnie infekowanie, wstrzykiwanie kodu w te runnery od GitHub Actions. Było możliwe wyciąganie sekretów, które były wstrzykiwane w ramach tego potoku, nie. Czyli jeżeli ktoś jako sekret przejmował jako zmienną środowiskową i ona nie była odpowiednio zabezpieczona, bo GitHub ma na to swój mechanizm, te sekrety są pakowane, specjalny obiekt i tak dalej, dostęp do nich jest zastrzeżony. To nie jest też temat na dzisiaj akurat, ale na przykład wykorzystywał po prostu łatwe i przyjemne zmienne środowiskowe, no to impact był oczywisty, tak. Plaintekstowo wyciągano sekret, który był po prostu infiltrowany, eksfiltrowany na zewnątrz do serwera kontrolowanego przez atakującego, więc tutaj tak to, co mówisz, przede wszystkim impact, nie.

Andrzej: Dokładnie tak. I fajnie, że wspomniałeś o sekretach, bo też chciałem dodać, ale już dodałeś. I to jest takie smooth. Przejście do swojego kolejnego tematu.

Wyciek Sekretów

Krzysiek: Tak, tutaj temat, który myślę, Andrzej, że już poruszałeś. Pamiętam, pisałeś o nim. Takich researchów już trochę było, bo pisałeś, pamiętam, o researchu, który dotyczył przeskanowania stron z listy Alexa Top One Million. Ale myślę, że warto poruszyć, bo jak widać, problem jest wciąż żywy i palący i nic nie zanosi się na to, żeby miało się to w najbliższej przyszłości skończyć. I tym razem ci ludzie z tego badania, o którym mówię, wzięli listę Majestic Million, czyli milion domen, które otrzymują najwięcej tak zwanych backlinków. Czyli jeżeli jakaś strona linkuje do twojej strony, no to to jest backlink. I oni wzięli po prostu milion takich stron, które tych backlinków mają najwięcej. No i z tych miliona domen… zeskrapowali zawartość tych stron. Oczywiście udało im się odkryć dużo więcej ścieżek, bo z tego miliona nagle zrobiło im się 189 milionów adresów URL, w tym również oczywiście plików javascriptowych, które są zaciągane przez te strony. Gdzie, jak się pewnie Andrzej domyślasz, tych sekretów kryło się najwięcej. No i tak, odfiltrowano z tych wyników stringi o wysokiej entropii, ponieważ badacze stwierdzili, że jeżeli nie jesteśmy w stanie dopasować wzorca, to znaczy, że te sekrety są albo nie są istotne, bo nie są sekretami. Fajny przykład tutaj to na przykład pliki SVG, gdzie krzywe opisywane przez te pliki, one mają dosyć wysoką entropię. I jakbyście zapuścili słuchacze, gdyby zapuścili taki skaner, który opiera się właśnie o entropii, opiera się na entropii, no to w dużej mierze, jeżeli gdzieś tam w projekcie pojawiają się pliki SVG, to one by były zwracane jako sekret. Więc tutaj w tym badaniu… Badacze odrzucają tak naprawdę te stringi o wysokiej entropii i skupiają się na sekretach, które są opisane przez jakieś konkretne wzorce. Jeżeli mamy AWS-a, to wiadomo, że będzie zaczynał się access key od jakiegoś prefiksu. I tutaj ciekawostka, bo ich fokus tutaj poszedł w stronę Stripe’a, czyli bramki płatności dosyć dużej. Bramki płatności i znaleźli tych sekretów całkiem sporo do Stripe’a, kontaktując się z zainteresowanymi, którzy byli właścicielami tych tokenów, udało im się oszacować, że wartość, jaką udałoby się uzyskać wykorzystując te tokeny do Stripe’a, ta ilość pieniędzy można szacować na około 20 milionów dolarów. Więc całkiem grubo, biorąc pod uwagę, że mamy tutaj do czynienia z publicznymi assetami. To nie mówimy tutaj w tym momencie o skanowaniu publicznych repozytoriów, tylko o stronach internetowych i o assetach, które tam są.

Andrzej: Ja spojrzałem tylko na to badanie mimochodem. Nie zgłębiałem się konkretnie w to, bo tak jak powiedziałeś, problem się powtarza już od lat. Można powiedzieć, można być już nim znudzonym, bo ile razy można pisać o tych sekretach. Uderzyło mnie właśnie to, o czym powiedziałeś, to 20 milionów ze Stripe’a. Znowu się nam trochę roluje to, co wcześniej zostało już wspomniane, czyli po prostu kasa, kasa, kasa. Jeżeli coś się opłaca, to znajdą się ludzie, którzy to robią, a jeżeli się coś nie opłaca, to amatorów w tej chwili, takich prawdziwych amatorów, co robią, bo coś kochają, czyli oryginalne słowo z francuskiego, no to takich jest po prostu mniej. Raczej każdy patrzy na to w chwili obecnej jako biznes. Czy dobrze, czy źle, nie będę oceniał, ale warto, może nie warto, ale tutaj zaznaczę, że kiedyś przeprowadzałem taki eksperyment, gdzie upubliczniałem kluczyk w repozytorium GitHuba. I ja wiem, że ty wiesz, Krzysiek, natomiast słuchaczom powiem, że w zasadzie te repozytoria są skanowane cały czas i mój kluczyk był, pierwsza próba użycia kluczyka nastąpiła po trzech minutach, po trzech, czterech minutach, bardzo szybko na GitHubie. Na GitHubie zajęło to trochę więcej, bo godzinę, ale generalnie te takie publiczne miejsca, w których sekrety mogą wypłynąć, które atakujący są w stanie przewidzieć, są skanowane cały czas. Takie całe dumpy jakichś URL-i z Aleksy czy innego typu, to o czym wspomniałeś z tego researchu, pewnie są trochę rzadziej.

Krzysiek: ale.

Andrzej: Jestem pewien, że jak ktoś już sobie zbuduje infrastrukturę do szukania takich sekretów, tak jak widziałem, że właśnie w tym dokumencie jest opis tej infrastruktury, bo to też nie jest takie łatwe, żeby przeskanować tam powiedzmy milion stron. Kilka problemów takich czysto inżynieryjnych trzeba tam po prostu rozwiązać, żeby zbudować bazę z danymi, ale nie duplikować pewnych rzeczy, żeby po prostu mieć tą bazę jakoś ułożoną w sensowny sposób, a nie mieć w niej bałaganu, to trochę tych problemów inżynieryjnych tam wyskakuje i trzeba je rozwiązać, ale jak już sobie zrobimy taką infrastrukturę, no to potem nic nie stanie na przeszkodzie, żeby po prostu sobie dodawać kolejne całe zbiory do przeszukiwania w trybie ciągłym, żeby to się po prostu działo cały czas. I jak tylko nam wykryje nowy sekret, no to już wtedy automatycznie coś z tym robimy. Na przestrzeni ostatnich lat było popularne wykorzystywanie takich sekretów, szczególnie na przykład do AWS-a czy Azure-a, żeby uruchomić instancje i zacząć kopać kryptowaluty. Wiadomo, jak sobie tam uruchomię jedną instancję, to tam co ja tam kopię, nie? No ale jak już będę tego uruchamiał tysiące dziennie, no to już, kurczę, może coś tam faktycznie uda mi się zrobić. A nawet jeżeli nie, to mogę je wykorzystać jako botnety. Nie na mój rachunek, tylko na rachunek organizacji. Więc do tego tematu nie mam za dużo do dodania. Jeżeli masz komentarz, to zaraz Ci jeszcze oddam mikrofon, a jeżeli… A ja dodam tylko, że to się… całość łączy z tym tematem, o którym ja chcę zaraz porozmawiać, czyli właśnie o, można powiedzieć, szerokim skanowaniu pewnych klas adresowych na różnych podstawach.

Krzysiek: Okej, to tutaj jeszcze taki… mój komentarz do tego tematu z sekretami i tego konkretnego researchu. Oczywiście my tam podlinkujemy z Andrzejem ten research, więc słuchacze będą mieli możliwość zaznajomienia się z tym, jak wyglądała ta infrastruktura. Tutaj nie będę teraz zanudzał szczegółami technicznymi, ale ciekawostka jest taka, że na sam koniec badacze podają, że… koszt tego całego przedsięwzięcia, tego całego researchu, uruchomienia tej infrastruktury w chmurze, to było około 100 dolarów. Więc biorąc pod uwagę, że nie są to atakujący, a mogliby być, to zwrot kosztów z inwestycji byłby całkiem niezły. 100 dolarów versus potencjalnie 20 milionów do wyciągnięcia ze Stripe’a.

Andrzej: Tak, więc zwrot inwestycji 200 tysięcy. Całkiem ok. I’m in. Shut up and take my money. Jeszcze wspomnę, że dla technicznych słuchaczy infrastruktura była oparta na Kubernetesie. Więc była skalowana. Ale teraz przejdę zgrabnie do tego kolejnego wątku, o którym ja chciałbym chwilę porozmawiać. Przede wszystkim, żeby go trochę wyciągnąć na wierzch i żeby trochę więcej osób o tym usłyszało. Nasza polska agencja NASK udostępniła niedawno, właśnie w zeszłym miesiącu, w styczniu, projekt open source o nazwie Artemis. Projekt można uruchomić samemu i projekt umożliwia skanowanie zakresów infrastruktury pod kątem różnych takich markerów związanych z bezpieczeństwem, czyli automatyzuje skanowanie portów, w momencie, gdy przerobi skanowanie portów, to odpali jakieś skany bezpieczeństwa, takie bardzo podstawowe, które po prostu spróbują zidentyfikować wersję, a następnie na podstawie wersji spróbują znaleźć znane podatności, te CVE na tą konkretną wersję. I po prostu wylistują nam to w tabelce, ale nie tylko. Jest tam kilka innych dodatkowych skanerów, które również się striggerują i uruchomią. Takie skanery jak jakieś WP-skany, czyli jeżeli mamy jakąś instancję WordPressa, to puści nam się skan na tego WordPressa. Będą skany TLS-a, SSL, czyli jakie mamy certyfikaty, jakie zestawy szyfrów, generalnie stan naszych certyfikatów, puszczą się skany SPF i DMARC na serwery pocztowe. Generalnie uruchomi się multum różnych skanerów, więc jest to taki orkiestrator, który uruchomi multum różnych skanerów na jakiś zakres infrastruktury, który mu podamy. I teraz, żeby ułatwić zrozumienie, co mam na myśli przez ten zakres infrastruktury. Takim zakresem infrastruktury, z punktu widzenia przykładowo… administratora, może być sieć publiczna mojej organizacji. Tą siecią publiczną może być na przykład wszystko, co żyje pod moją domeną, ale nie tylko moją główną domeną, ale również pod wszystkimi subdomenami, które są związane z moją główną domeną. Oczywiście to samo aplikuje się do wielu domen, czyli jeżeli mam różne domeny, no to te różne domeny mogą mieć swoje subdomen. Więc jestem w stanie wyliczyć subdomeny dla wszystkich domen i to narzędzie mi będzie robiło, czyli będzie mi odkrywało powierzchnię ataku, a jak ją już odkryję, to na podstawie tego zacznie uruchamiać te skanery na wszystkie te asety, czyli serwery, które udało mu się znaleźć. Więc niejako automatyzuje dość nieprzyjemny kawałek do automatyzacji związany z wyszukiwaniem powierzchni ataku, a potem skanowaniem tej powierzchni ataku przez różnego rodzaju skanery, ale tak, żeby to faktycznie działało. Bo ja rozwiązywałem kiedyś podobny problem w takim MVP projektu, który końcem końców nie wyszedł, ale miał za zadanie robienie czegoś podobnego. Takie projekty też istnieją za granicą, jednym z nich jest Shodan, ale jest też Censys, jest taki… Kurczę, teraz sobie nie przypomnę, ale innym projektem jest AssetNote. Generalnie takich projektów, które odkrywają powierzchnię ataków organizacji na podstawie pewnych markerów, takich jak zakresy IP czy domeny, jest sporo i one są przydatne i one działają jako biznesy, bo jest to duża wartość dla organizacji. No to teraz, jeżeli jestem takim administratorem i nie stać mnie na licencję AssetNote, nie stać mnie na licencję Censysa dla mojej organizacji, no to mogę tanim kosztem wziąć Artemisa i po prostu zacząć uruchamiać na swoje asety i mieć skanowanie bezpieczeństwa, takie bardzo podstawowe, ale jednak skanowanie bezpieczeństwa i odkrywanie też powierzchni ataku dla mojej organizacji w trybie ciągłym i nie muszę rozwiązywać różnego rodzaju problemów inżynieryjnych, polegających na skalowaniu tego rozwiązania, czy na bawieniu się ze strukturą danych, które te skany wypluwają, bo to też jest duży problem. Różne skanery wypluwają różne dane, trzeba je potem normalizować, trzeba się z nimi bawić. Jest to sporo zabawy i nie bez powodu te różne projekty, takie właśnie jak AssetNote, biorą za to pieniądze, bo może sama idea nie jest jakaś, Bóg wie, jaka rewolucyjna, ale dobre rozwiązanie tego problemu, na którym można polegać, które potrafi wykryć false positive etc. swoje kosztuje, bo po prostu trzeba to utrzymywać. A ten projekt, który miałem na myśli, to BitDiscovery. BitDiscovery też to jest projekt, który działa od wielu lat. Oni od wielu lat robią snapshoty całego internetu. Tutaj jeszcze nadmienię, że taki snapshot internetu jest bardzo łatwo zrobić, bo przynajmniej w wersji IPv4, czyli czwartej wersji protokołu IP, no bo z protokołem w wersji szóstej byłby mały problem, bo tam jest za duża przestrzeń wszystkich dostępnych adresów, ale w przestrzeni opartej na IP w wersji czwartej tych adresów jest tylko 4 miliardy, więc jeżeli ja mam szybki komputer i szybkie łącze, to jestem w stanie przeskanować cały internet w mniej niż 5 minut odpowiednim skanerem. Więc jest to dość szybkie, więc jestem w stanie zrobić taki podstawowy snapshot w 5 minut. No i oczywiście pewne pule adresowe są przypisywane do różnych organizacji, więc jeżeli działamy w bardzo dużej organizacji, przykładowo w banku, to bank często gęsto ma swojego ASN-a, ma swoją przestrzeń adresową i tą przestrzeń adresową również możemy wbić do takiego skanera powierzchni ataku i również będą nam się te skany odbywać. Tutaj jedyna uwaga jest taka, że te skany mogą być aktywne, nie tylko pasywne, a skoro są aktywne, to znaczy, że będą coś wysyłać do tych usług i… prawdopodobieństwo jest małe, ale jednak istnieje, że taka usługa może się po prostu wywrócić, więc to trzeba mieć na uwadze, że takich testów raczej nie powinniśmy uruchamiać nieautoryzowani, ale w kontrze do tego, oczywiście powiem, że atakujący i tak je uruchamiają cały czas, więc jeżeli nasze usługi się wywalają, bo przyszły do nich skany, to mamy większy problem niż to, że ktoś w dobrej wierze uruchomił skaner i chce bronić naszą infrastrukturę. Bo takie skany z Chin czy z Korei, ale tej złej Północnej, to są nagminne, to są w cyklu dziennym, tego są tysiące. I ostatnia rzecz, którą chcę jeszcze tutaj dodać, to to, że NASK nie tylko udostępnił to narzędzie w wersji darmowej, że można sobie pobrać, uruchomić i zacząć działać we własnym zakresie, na własnych projektach, to też jako instytucja publiczna NASK skanuje polski internet, bo kraje, tak samo jako organizacje, duże kraje, też mają swoje pule adresowe. Polska pula adresowa to jest też około 20 milionów IP. Wiem, bo ja kiedyś pracowałem nad tym projektem, to skanowałem polski internet, więc to było coś koło 20 milionów IP i oczywiście te dane są ogólnie dostępne, to nie jest nic ukrytego, można sobie wpisać ASN Polska i znaleźć te wszystkie pule adresowe. Natomiast NASK skanuje polską przestrzeń i co udało mu się znaleźć w poprzednim roku, bo jest garść statystyk w tym poście, który upublicznił ten projekt. Mianowicie w poprzednim roku znaleźli około 184 tysięcy podatności lub niepoprawnych konfiguracji jakichś usług, więc załóżmy, że to po prostu jest podatność slash misconfiguration. Takie misconfiguration nie musi być podatnością, ale dla uproszczenia załóżmy, że jedno i drugie to jest po prostu problem, więc znalazł w przybliżeniu 185 tysięcy problemów, z czego około 12 tysięcy było o stopniu wysokim, krytyczności wysokiej i około 66 tysięcy domen, subdomen miało co najmniej jeden problem. Czyli w zasadzie jedna trzecia miała co najmniej jeden… No bo skanowali 185 tysięcy, a 66 miało problem. To jest coś około jednej trzeciej, która ma problemy. Z czego: znaleźli 78 tysięcy przestarzałych Joomli, WordPressów, pluginów do WordPressa, 44 tysiące niebezpiecznych implementacji SSL-a, TLS-a, czyli przykładowo TLS-a, który obsługuje wersję 1.0, 27 tysięcy źle skonfigurowanych serwerów pocztowych, czyli tak, właśnie SPF i DMARC. Więc tak naprawdę było bardzo dużo ciekawych znalezisk, no i oczywiście NASK zgłasza te znaleziska do instytucji, które znajduje. Więc to nie jest tak, że tam po prostu sobie szukają, ale nie. Jak znajdą, to to zgłaszają. Więc działają takim… Są instytucją pożytku publicznego i faktycznie działają tutaj w imieniu tego, żeby podnieść ten stan. I bardzo fajnie. Po pierwsze, że takie narzędzie powstało. Po drugie, bardzo fajnie, że je udostępnili i z tego, co patrzyłem, to jest… faktycznie działa, te problemy inżynieryjne były rozwiązywane, bo nawet je po prostu wymienili, z jakimi problemami musieli się zmierzyć, jak je rozwiązało. No i trzy, fajnie, że nie tylko je stworzyli, nie tylko je udostępnili, ale też aktywnie sami z niego korzystają na polską przestrzeń, że nawet w przypadku, jeżeli znajdą to na naszych serwerach, no to na koszt… nas wszystkich, bo podatników, ale jednak to też jest wspólne dobro na nasz koszt, zgłaszają to do odpowiednich instytucji, te podatności mają okazję być wyprowadzone i to jest fajne. To mi się bardzo podobało.

Krzysiek: Tak, ja bym tutaj chciał dodać do tego, co powiedziałeś, Andrzej, że bardzo mi się podoba, że w końcu mamy… takie narzędzie, na którym możemy polegać, które zostało stworzone przez osoby, które faktycznie się znają i możemy mu po prostu ufać, bo tego typu takich agregatów, które, z tego co rozumiem Artemis działa tak, że łączy w sobie wiele open source’owych narzędzi, takich jak pewnie Nuclei, Amass i tak dalej. W końcu ktoś wziął to, zebrał w całość, fajnie opakował i rozwiązał przy okazji tego problemy, które często leżą na styku tych integracji pomiędzy tymi różnymi narzędziami. Bo nie ukrywajmy tego typu… może tego typu skanery, tego typu zlepki narzędzi często były tworzone przez bug hunterów, którzy w ten sposób bardzo często automatyzowali sobie swoją pracę, ale do końca nie było to coś, na czym można polegać produkcyjnie, jeżeli prowadzisz jakąś firmę. Po prostu ktoś naklepał to na kolanie, połączył 3-4 narzędzia i stworzył swój własny external mapping attack surface i wypuszczał na GitHuba. To, co mi się tutaj podoba i jaką szansę widzę w Artemisie, to to, że jeżeli jesteś administratorem w małej firmie, jeżeli korzystacie z jakiegoś WordPressa, Joomli, nic nie stoi na przeszkodzie, żeby wziąć Artemisa, narzędzie, które zostało już teraz sprawdzone w boju przez CERT Orange Polska, jego twórcę, i uruchamiać to u siebie. Duży asset, szczególnie w kontekście takich miejsc, gdzie tych pieniędzy po prostu nie ma. Mówię tutaj, nie wiem, o jakiejś Polsce powiatowej, Polsce gminnej, gdzie administratorzy są zawaleni robotą, bezpieczeństwo leży i kwiczy, nie. Fajnie, że udało się coś takiego na naszym polskim poletku tutaj zrobić.

Andrzej: Dokładnie. Dokładnie to, co mówisz. Takie narzędzia to nic nowego, ale nowe jest to, że w końcu wyszło porządne narzędzie, które zlepia te wszystkie narzędzia, które rozwiązuje problemy inżynieryjne, które powstają przy zlepianiu tego typu narzędzi. I ono po prostu działa i można je szybko uruchomić i w zasadzie nie zerowym kosztem, no bo ktoś to musi zrobić, to już jest jakiś koszt, musi to gdzieś uruchomić, ale bardzo niskim kosztem, bo jednak jest to niski koszt w porównaniu do przykładowo kupienia licencji Asset Note czy Bit Discovery na rok, czy na dłużej. Tym bardziej, że to są wszystko firmy zagraniczne, więc wiadomo, ono kupuje się w dolarach, a nie w złotówkach. Więc jest to po prostu jeszcze droższe, a tutaj tak naprawdę potrzebna jest tylko chęć, czas człowieka, który nie jest tak duży do zapotrzebowania. No i oczywiście jakiś kawałek infrastruktury, no bo trzeba to gdzieś uruchomić, gdzieś to musi po prostu działać. Ale jest to nieporównywalnie mniejszy koszt niż to, co było wcześniej i fajnie, że takie coś powstało, a tym dodatkowym takim akcentem miłym jest to, że po prostu powstało w Polsce, że jest to coś polskiego. Dobrze, mamy jeszcze dwa artefakty, które chcielibyśmy omówić. Krzysiek. Wskakuj ze swoim. Mój będzie króciutki, więc tam na końcu o nim wspomnę i myślę, że zaburzenia jego komentarza nie będzie, ale ten twój to rzuciłem na niego okiem, ale nie wchodziłem głębiej, a w ogóle mi się wcześniej nie obiło o uszy, więc oddaję głos w swoją stronę.

Krzysiek: Dobra, to teraz użytkownicy Javy, trzymajcie się, nowa aferka.

Andrzej: Javy w wersji Script czy bez?

Krzysiek: Bez.

Andrzej: Okej.

Krzysiek: Mówimy tutaj o ekosystemie Mavena. Więc tak, Javowcy trzymajcie się, jest nowa aferka nazwana jako Mavengate. Tak w dużym skrócie, myślę, że osoby, które pracują na co dzień z Javą i Mavenem nie będą mieli tutaj problemu, ale zależności w Mavenie definiowane są w takim dosyć specyficznym formacie. Od lewej strony group ID, dwukropek ID artefaktu, dwukropek wersja, więc na przykład będziemy mieli com.google.code.json, dwukropek json i potem wersja. No i żeby potwierdzić to swoje group ID, no to musisz dodać rekord tekstowy w DNS-ie ze specjalną wartością. No i wtedy Maven potwierdza, że ty faktycznie możesz posługiwać się tym group ID i pod tym group ID publikować w Mavenie swoje paczki. No więc… Coś, co nie jest nowe, jeżeli chodzi o tego typu researche. Badacze stwierdzili, że okej, zaczniemy sobie scrapować duże repozytoria wykorzystujące Javę i zaciągające zależności z Mavena i będziemy szukali odniesień do zależności, które zostały już porzucone, a następnie będziemy sprawdzać, czy te domeny są możliwe do wykupienia. Bardzo podobna rzecz, Andrzej, i wiem, że tutaj kiwasz głową i na pewno już kojarzysz, była robiona w NPM-ie, tylko że tam sprawdzano, czy da się przejąć po prostu w ten sposób konto maintainera, rejestrując własną domenę i zakładając na niej skrzynkę pocztową. Tutaj w tym przypadku po prostu można było pushować do Mavena nowe paczki i w efekcie tego całego badania znaleziono 26 tysięcy takich domen, z czego… 3700, około 14% było podatnych. Można było przejąć te domeny, a następnie pod tym group ID publikować te paczki. Także Mavengate tutaj w takim ekspresowym skrócie. Coś, co faktycznie, czytając jednego tweeta dotyczącego… tej sprawy. Kto to pisał? Świetny sposób na robienie researchów. Bierzesz ekosystem po ekosystemie i robisz to samo właśnie w kontekście przejmowania tych domen, nie?

Andrzej: Dokładnie tak.

Krzysiek: To chyba nawet, że ci przerwa, Andrzej, to chyba nawet pisał Clint z TLDR Security, że jeżeli chcecie zrobić fajny research, to… podążajcie tymi krokami, tylko bierzcie na warsztat nowe repozytoria pakietów.

Andrzej: Dokładnie tak. I to jest niewyczerpujące, jak to się mówi, bo jeżeli znamy historię, poznamy przypadki sprzed lat, to bardzo często… albo jest tak, że można wziąć dosłownie to, co już było w przeszłości, tylko po prostu zastosować to w jakiejś nowej technologii albo właśnie nowym ekosystemie. Albo wymaga to nieznacznych zmian i otwiera to drogę do zupełnie nowego odłamu jakiejś klasy podatności. Tutaj można powiedzieć, wypunktować, że James Kettle z Portswiggera, bardzo znany badacz bezpieczeństwa, na pewno kojarzysz. James bardzo często robi tego typu badania, czyli tak naprawdę bierze jakieś pomysły z przeszłości, a następnie próbuje je w nowym wydaniu. W nowym wydaniu, oczywiście to nie jest, teraz brzmi łatwo, jak się o tym mówi, tak, no, weź jakiś pomysł z przeszłości i po prostu go tam połącz w czymś nowym. Ja wiem, ja wiem, to brzmi trochę prościej jak się mówi, a trudniej w akcji. Natomiast końcem końców bardzo często patrząc wstecz tak to wygląda, więc wiedząc, że często w ten sposób to wygląda, no to można ekstrapolować to na przyszłość i przynajmniej warto znać te błędy z przeszłości, bo to zwiększa prawdopodobieństwo, że robiąc coś, pracując jako bezpiecznik, coś nam w głowie zaświta w momencie, kiedy coś zobaczymy. Czyli zwiększamy prawdopodobieństwo tego, że nam się zetkną odpowiednie odpowiednie neurony w głowie. Natomiast jeżeli nie znamy tych wszystkich, może wszystkich to się nie da znać, ale jeżeli nie znamy przeszłości danej domeny, danego ataku, danej klasy ataków, no to nie ma co się po prostu tam zderzyć. Te punkty się nie zderzą, bo jest tylko ta jedna, ta obserwacja w danym punkcie czasu, a nie ma tych obserwacji z poprzednich przykładów. Dlatego ja jestem takim orędownikiem, że dobrze jest znać przeszłość dziedziny, w której się pracuje i to jak najszerzej, czyli przykładowo jak my działamy w IT, to dobrze jest znać nie tylko tam przeszłość cyberbezpieczeństwa, ale też ogólnie szerszego IT, różnych błędów związanych z programowaniem. Takich błędów, już nawet nie chodzi mi o podatności. I jak poznajemy takie rzeczy, to raz, że świat się staje bardziej dla nas, bardziej kolorowy, bo widzimy ciekawe niuanse, a dwa, że zwiększamy prawdopodobieństwo, że coś tam kiedyś ciekawego w głowie naszej urodzi. O tym Mavengate totalnie nie słyszałem, więc w ogóle mi się nie obiło o uszy. A teraz wiem, to sobie doczytam, bo mam tutaj linka i kto wie, może mi samemu się coś w przyszłości pozderza w głowie. Natomiast trochę zamykając nasze dzisiejsze spotkanie, ja chciałbym opowiedzieć o jednym małym problemie, który wystąpił niedawno. Wystąpił albo inaczej. Został upubliczniony niedawno, bo on wystąpił jeszcze w poprzednim roku. Nawet jego CVE wskazuje na poprzedni rok, bo to jest CVE 2023-6246, więc tak naprawdę został zgłoszony już jakiś czas temu. Widać to po tym, że to jest 6246, czyli to jest tylko sześciotysięczna podatność, a tak naprawdę w chwili obecnej te CVE pod koniec roku dochodzą już do liczb pięciocyfrowych. No tutaj dalej mamy czterocyfrową, więc wiadomo, że jest to raczej nie z końcówki roku, tylko wcześniej zostało zgłoszone, chociaż niekoniecznie, bo mógł to też sam vendor, do którego było zgłoszone, udostępnić z własnej, zarezerwowanej wcześniej puli. Ale abstrahując od tego, błąd polega na tym, że mamy błąd obsługi pamięci, to jest konkretnie heap-based buffer overflow w glibc. I teraz nie będę jakoś mocno wchodził w to, czym jest heap-based buffer overflow, wystarczy powiedzieć, że coś się nieodpowiednio układa w pamięci i to pozwala wykonać twój kod na maszynie, na której jesteś. Czyli musisz mieć lokalny dostęp w tym konkretnym przypadku do powiedzmy serwera, ale jak już masz do niego lokalny dostęp, to jesteś w stanie wykorzystać tą podatność w glibc. I tutaj rozszerzę, jeżeli ktoś nie wie, czym jest glibc, to jest standardowa biblioteka C w środowiskach unixowych, tutaj konkretnie mówimy najczęściej o Linuksie, i jest to dość duży, można powiedzieć, big deal, dlatego że ta biblioteka jest używana przez wszystko, co jest w systemie operacyjnym, bo ona dostarcza podstawowe funkcjonalności, które są wykorzystywane w innych aplikacjach. Przykładowo, jeżeli korzystamy z printf, no to printf tak naprawdę jest zaimplementowany w bibliotece standardowej w C, czyli właśnie w glibc. I jeżeli uda nam się znaleźć podatność, która jest w glibc, to tak jakbyśmy znaleźli podatność w czymś, co jest używane przez bardzo dużą ilość software’u. Przykładowo właśnie Log4j, który wcześniej został wspomniany. Można po prostu porównać na poziomie logicznym, że to jest coś bardzo podobnego, chociaż… ten konkretny przypadek jest bardziej krytyczny w tym swoim zamkniętym kontekście, czyli może ryzyko dla całego systemu komputerów jest mniejsze, no bo jednak trzeba mieć dostęp do maszyny, to jeżeli weźmiemy, tak popatrzymy lokalnie, no to jest trochę głębszy, bo dotyczy wszystkich systemów, na których jest ta wersja glibc, a jednak dla postronnych słuchaczy, którzy może nie kojarzą, Unix, Linux generalnie jest napisany w C. Jest napisany w C, więc tam wszystko na pewnym poziomie korzysta z C, więc jeżeli mamy problem podatność w bibliotece standardowej C, a tutaj konkretnie była w funkcjonalności, która była jeszcze poniżej funkcji syslog, która była wykorzystana w funkcji syslog, ale sama była jeszcze niżej, no to jeżeli dostajemy dostęp do takiego serwera, to jesteśmy w stanie podnieść swoje uprawnienia do root-a, czyli najwyższe, czyli jestem użytkownikiem, mogę napisać prostą aplikację, która skompilowana i uruchomiona na tym systemie zwróci mi root shell. Tak, tak, dokładnie. Game over. I to jest… I tutaj nawet mi nie chodzi o to, że ta podatność jest, o kurczę, super ciekawa. No dla mnie jest ciekawa, bo ja się zajmowałem bardzo długo niskopoziomowym bezpieczeństwem i właśnie szukałem takich podatności i eksploatowałem dla różnych firm i ludzi. Natomiast to, co mnie tutaj zaciekawiło, to to, że tak naprawdę nie było o niej za bardzo słychać. To jest tutaj dla mnie ten case, że było słychać o tym CVSS, dziesiątce dla GitLaba, Jezus Maria, serwisy o tym pisały, znane osobistości ze świata IT polskiego i zagranicznego o tym pisały, Jezus Maria, świat się wali, GitLab, dziesiątka. Natomiast o tym w zasadzie nikt nie pisał, a to jest problem, który jest dużo większy niż ten problem GitLabowy. To jest dużo większy problem. Tylko, że ten problem… Wymaga też, można powiedzieć, głębszego zrozumienia tego, jak działają komputery i dlaczego ten problem jest problemem. Natomiast o GitLabie można po prostu powiedzieć, no to dało się zresetować hasło, każdy to rozumie, więc można napisać i zrobić z tego trochę taki fut. Dla mnie, no ja po prostu lubię trzymać się faktów i być taki trochę down to earth. Ten problem był dużo większy. Więc ten jeden fakt to jest to, że tak naprawdę obił się bez szerszego echa, pomimo tego, że naprawdę jest krytyczny. A dwa, był znaleziony przez Qualys Security Advisory i teraz zrobię mały taki wstęp i w zasadzie będę kończył, chyba, że będziesz miał coś do dodania, Krzysiek. Wstęp, czym jest Qualys Security Advisory. Qualys to jest firma, która ma skaner bezpieczeństwa, to myślę, że bezpiecznicy kojarzą, ale pewnie też kojarzą coś takiego jak Project Zero z Google’a. I w pewnym momencie Qualys też pomyślał, kurczę, fajnie było mieć taki projekt, coś a la Project Zero. I ja nie jestem pewien, ale się domyślam, nie jestem pewien, natomiast wydaje mi się, że w tym projekcie jest tylko jeden człowiek. Ale ten człowiek jest takim kotem, jest takim kotem, że on na przestrzeni ostatnich kilku lat wypuszcza właśnie takie podatności, szczególnie, że te podatności widać po sposobie ich opisywania, że one są pisane przez jedną osobę. Bo to jest pewien bardzo wybiórczy styl pisania, bardzo to the point, bez rozchodzenia, taki bardzo trochę jak robot. I te podatności, które ta osoba znajduje, one też są często gęsto bardzo skomplikowane. Takie, że są pomiędzy interakcją wielu różnych plików w dużych aplikacjach, które są niskopoziomowo napisane w C. I nagle jak się to czyta, to jezus Maria, ten gość musi nieźle to ogarniać. Sporo czasu musiał na to poświęcić, nie tylko na znalezienie, ale potem na eksploatację. Więc Qualys ma taki mały, bardzo mały zespół, który imituje Project Zero i tam jest jeden człowiek, który jest mega ogarnięty i właśnie znajduje tego typu podatności w różnych ciekawych aplikacjach, ale zawsze targetuje coś, co jest krytyczne. Pamiętam, że kiedyś znalazł coś w sudo. To jest teraz inna dyskusja. Czy się mówi sudo, czy się mówi sudu. Ale to w zasadzie możesz się zaraz odnieść. Czy się mówi sudu, czy sudo. To jest zagadka dla ciebie. Jak się zastanów się. Ty mi dałeś zagadkę, przegrałem, to teraz mam nadzieję, że ty przegrasz. Pójdę tą drugą opcją.

Krzysiek: Mówi się sudu.

Andrzej: Damn.

Krzysiek: To było zbyt proste.

Andrzej: Ale to tutaj mała gwiazdka. Zgadza się, według autora mówi się su do i bierze się to stąd, o ile dobrze pamiętam, że to jest po prostu super user do, czyli super użytkownik niech wykona. Ale, dość duże. Ale, jeżeli ktoś słucha angielskich wykładów z jakichś konferencji etc., to raczej częściej się słyszy tą pierwszą wymowę, czyli sudo, od pseudo. sudo. Bo technicznie to jest taka gra słów, nie? Że sudu albo sudo, bo ja jestem pseudo, jakiś użytkownik, który wykonuje zamiast w jego imieniu jakąś akcję. Więc jest to taka gra słów i ja kiedyś się zdziwiłem, że się mówi sudo, albo inaczej. Zdziwiłem się, jak to usłyszałem. Na początku nie wiedziałem, o co chodzi, a potem a, a, chodzi o sudo. No, ale ostatnio… na jednym z Discordów była taka krótka dyskusja, czy się mówi sudo, czy su-du i zostałem wyprostowany, że się jednak mówi su-du i nie dało się wykłócić mojej wersji z prostej przyczyny, bo został mi dostarczony film autora su-du, który jasno mówi, że się mówi su-du. Dobra, dobra, dobra, przegrałem, idę spać.

Krzysiek: Ja się tak krótko odniosę do tych lingwistycznych potyczek. Ja kiedyś zostałem, można powiedzieć, upomniany przez osobę, która była bardzo oburzona, że mówię pi pi zamiast py pi. No i był to… był to deweloper Pythona i nawet widziałem, że są. Jest kilka filmików na YouTubie, które tłumaczą, w jaki sposób po prostu powinno się wymawiać nazwę tego repozytorium paczek. Także jest jakiś problem.

Andrzej: To ja się dopytam, to jak się wymawia? PyPy czy PyPI?

Krzysiek: PyPI.

Andrzej: PyPI, okej, to widzisz. To Today I Learned, bo też wypowiadam jej PyPy, PyPI. Kurczę, no na to nie wpadłem, ale dobra, faktycznie, jak już to powiedziałeś, to lepiej brzmi, lepiej brzmi PyPI. Dobra, dobra.

Krzysiek: I jeszcze do glibc, takie pytanie do dzisiaj, Andrzej, ja oczywiście się tam nie trudniłem, oczywiście, nie trudniłem się w eksploatacji niskopoziomowej, ale co nieco musiałem odbębnić, wchodząc do półświatka CyberSec. I teraz kojarzę taką stronę, Ty ją, Andrzej, na pewno kojarzysz. GTFO Bins. Tam jest spis binarek linuksowych i proste write-upy, w jaki sposób można je wykorzystać do tego, aby eskalować swoje uprawnienia do root-a. I teraz mając chwilkę, wpisałem tam glibc i nie widzę, więc moje pytanie jest takie, czy ten opis tej podatności, on już zawiera taki full… full exploit, jest przejście takie od początku do końca, w jaki sposób to glibc eskalować do root-a za pomocą glibc?

Andrzej: Dobrze, to będę musiał trochę wyprostować swoje rozumowanie, bo następuje tutaj pewien błąd rozumowania. Po pierwsze, ten gościu, który znajduje te podatności, bardzo rzadko, chyba nawet nigdy nie udostępnia pewnych eksploitów, więc je opisuje, ale opisuje je na tyle, że jeżeli ktoś ma umiejętności, to sobie poradzi z napisaniem swojego exploita. Ale jeżeli nie ma umiejętności, to go nie napisze, a on go nie udostępnia. Przynajmniej, przynajmniej z tego, co pamiętam, to nawet jeżeli udostępnia eksploity, to robi to z dość dużym buforem już po upublicznieniu w ogóle swojego advisory. Czyli nie dość, że znajdzie to powiedzmy dzisiaj, advisory wyjdzie za pół roku, to exploit wyjdzie za kolejny rok. Wtedy, kiedy już był dość duży bufor czasu na załatanie w systemach tej podatności do po prostu podniesienia wersji. Więc to jest taki dość rozważny człowiek. Też mnie dziwiło, że jak kiedyś go wystalkowałem na Twitterze, to miał tam, nie wiem, chyba jakąś setkę obserwujących, jakoś bardzo mało, biorąc pod uwagę skillset, bo to jest… To widać po prostu, jak się czyta ten write-up i luki, które znajduje, że to jest gościu z najwyższej ligi. To jest osoba, która jak niektórzy znają polskich graczy, takich jak Gynvael czy Jurek, no to to jest osoba na takim poziomie. Spokojnie. Więc gościu jest mega ogarnięty. Albo kobieta, ja w sensie nie wiem, czy to jest mężczyzna, czy kobieta. Wydaje mi się, że z imienia chyba wychodziło, że to jest mężczyzna, ale ręki sobie nie dam uciąć, bo to nie było europejskie imię. A tak mocno w to nie wchodziłem. Natomiast ten błąd logiczny, albo rozumowania, bo to nie logiczne, ale rozumowania, które popełniasz tutaj, jest to, że ta strona, którą podałeś, GTFO Bins, ona listuje binarki, czyli konkretne aplikacje, które są w systemie i które możesz wykorzystać do podniesienia uprawnień. Czyli raczej chodzi o to, że nie wykorzystujesz tam podatności, bo sama aplikacja jest podatna, tylko jeżeli jest jakaś nieodpowiednia konfiguracja na systemie, to ta aplikacja może zostać wykorzystana do podniesienia swoich uprawnień w takim i takim przypadku. W innych nie ma, w innych nie możesz, ale jeżeli akurat się zrobi taki, wiesz, misconfiguration i będą takie warunki, to się da to zrobić. Często, gęsto na egzaminie z OSWE musisz właśnie wykorzystać jakąś z wariacji aplikacji, które są dostępne w systemie, żeby podnieść swoje uprawnienia. Oczywiście, jeżeli miałbyś tam exploita na kernela, to mógłbyś też… którego sam znalazłeś, to możesz nawet tego użyć, nie? Ale maszynka jest zrobiona w ten sposób, że jest tam jakaś binarka, która jest tak skonfigurowana, albo jakiś plik na systemie plików, który ma takie uprawnienia, że da się go wykorzystać do podniesienia swoich uprawnień. I ta strona listuje ten przypadek. Natomiast to, o czym ja mówiłem w kontekście tej podatności w glibc, to jest coś, co to jest faktyczna podatna funkcja w bibliotece, która jest dołączana do każdej aplikacji, którą skompilujesz w tym systemie operacyjnym. Więc jeżeli ja mam dostęp do kompilatora C, to ja sobie mogę sam napisać aplikację, która skorzysta z tej funkcji, która skorzysta z glibc, no bo jest napisana w C, więc będzie musiała z niej korzystać, bo sobie ją inkluduję. Następnie wykorzystując funkcję syslog, mogę w ten sposób pomasować dane, że… funkcja syslog, wykorzystując jeszcze niższą funkcję, striggeruje mi podatność, a potem, jeżeli odpowiednio wszystko pomasowałem w środowisku, zwróci mi root-a. Więc tak naprawdę glibc na tej stronie, o której mówisz…

Krzysiek: Nie ma prawa zaistnieć.

Andrzej: Nie ma prawa zaistnieć, bo samo z siebie nie pozwoliłoby ci na podniesieniu prawa. To, że pozwala, to jest po prostu konkretna podatność: heap-based buffer overflow, która istnieje w tej implementacji, w tej konkretnej wersji glibc i ona też nie istnieje od zarania dziejów, tylko tam od, nie wiem, chyba roku czy dwóch, więc nie była też aktywna jakoś super długo. Przez jakiś po prostu kawałek, no i autor, który znalazł tę podatność, też napisał, że udało mu się, że potwierdził istnienie tej podatności, czyli udało mu się podnieść uprawnienia ze zwykłego użytkownika do root-a na Debianie 12, 13, na Ubuntu 23.04, 23.10, Fedorze 37 i 39. Więc w zasadzie na wielu systemach i nic by nie stało na przeszkodzie, żeby jako autor pojechał przykładowo na Pwn2Own i tam zhakował Ubuntu i po prostu wygrał w tej jednej kategorii. Natomiast mam nadzieję, że udało mi się sprostować ten mały mismatch, który… mismatch z tym podnoszeniem uprawnień, bo to jest coś podobnego, ale jednak to, o czym mówisz, wynika z miskonfiguracji. To, o czym mówię ja, to jest konkretna luka w implementacji, którą można wykorzystać, jeżeli mamy dostęp do kompilatora.

Krzysiek: Okej. Wszystko jasne. No to tak jak Andrzej, jak mylimy zainfekowane paczki z podatnymi paczkami. Błąd tej kategorii.

Andrzej: Dokładnie. Plus bezpieczeństwo niskopoziomowe. Jak mam być szczery, to wrzuciłeś ostatnio na Discorda ten obrazek, ten binary exploitation od Live Overflow, a podrzucimy link, zresztą go ukradłem i wrzuciłem na social o 19, więc już będzie leżał na LinkedInie, bardzo mnie rozbawił, ale dokładnie tak to wygląda, że binary exploitation, to bezpieczeństwo niskopoziomowe jest… ten punkt wejścia leży bardzo wysoko, więc trzeba naprawdę wspinać się jak w Grze o Tron na ścianę, na ścianę lodowca, żeby tam wejść, a powiem szczerze, że jak już na tym stoisz, to jakoś nie czujesz jakiejś super satysfakcji, jeżeli mam być szczery, więc no, a przynajmniej wiesz, jak komputery działają, to jest duży, to jest duży plus, że… znam asemblera i umiem zasemblować jakieś binarki. Znaczy umiałem, bo to już robiłem lata temu. Więcej zapomniałem niż pamiętam. Dobra, to tym pozytywnym akcentem będziemy kończyć. Ja bardzo dziękuję za udział w dzisiejszym odcinku i będziemy się widzieć za cztery tygodnie jakieś, no bo luty to ma 29 dni w tym roku, jest przestępny.

Krzysiek: Tak, dzięki wielkie, dzięki Andrzej, dzięki dla słuchaczy, za spędzenie z nami czasu, no i do zobaczenia za miesiąc.

Sprawdź pozostałe odcinki →

Krytyczna podatność w GitLab, Stan supply-chain oraz Hakowanie CI/CD

W tym odcinku szczególną uwagę poświęcamy:

Transkrypcja

Ataki na Łańcuchy Dostaw

Wyciek Sekretów

Obszary

Tagi

Zobacz naszą ofertę