Transcription

Witajmy brawami Mateusza, przekazujemy głos. Proszę bardzo. Siema Lejro, ja tak zwyczajowo trochę chodzę. Jak widzicie tytuł prezentacji jest trochę inny, ale to też głównie dlatego, że ja słabo znam się na Pytonie, natomiast dowiedziałem się od organizatorów, że tu są najlepsze aftery, więc jak mogłem nie przejechać. Dzisiaj opowiem wam trochę o atakach na ekosystem Pytona. Ja jestem Mateusz i to chyba wystarczy, bo ja za wiele o Pytonie nie wiem, tak jak mówiłem. Ta preska będzie o trzech rzeczach. Pierwsza będzie związana z tym, że programiści mają trochę problemu, bo coraz bardziej programiści są atakowani w dzisiejszym świecie i to nie tylko tak, że są atakowani ze względu na to, że są programistami, ale po prostu są fajnym celem w tej całej ukadance, co pokazało SolarWinds parę lat temu, które położyło nie tylko kilka firm, ale parę też rządowych oprogramów w Stanach Zjednoczonych, co było celem ruskich tym razem. Systemy Continuous Integration, które jak się okazało są świetnym źródłem informacji, sekretów i innych rzeczy, o czym wam dzisiaj opowiem, a także ostatnie zależności, czyli Game of Thrones. A teraz tak na początek, żeby ułożyć to, o czym będziemy mówili, czy ktoś z was kiedyś korzystał z Bumblebee? O, nie kliknęło się. Ja jestem takim starym gęciarzem, także wiecie, w czasach kiedy wszyscy korzystali z normalnych komputerów, ja przekompilowałem sobie jądro, systemy i takie tam. Bumblebee służyło do tego, żeby przełączać się z budowanej grafiki na taką grafikę dyskretną. To, co się stało te parę lat temu, to pewnie ciężko jest to zauważyć z daleka, ale tutaj na początku przy tym RMFFN, rmrf.usr.jap. No i jak się domyślacie, każdy kto zna trochę Basha, ten mały bug powodował, że cały USR szedł się walić, mówiąc delikatnie. Oczywiście, no trochę przypadek, deweloper przeprosił. Takie rzeczy się zdarzają, to nie było nic celowego, ale każdy, kto zainstalował sobie tą wersję, no jego USR przestał po prostu istnieć. Ale co by było, gdyby ktoś zrobił to celowo? No więc, kto zna historię CTX-a? Pewnie każdy na tej sali. Okej, super, to będzie coś ciekawego jednak. Był atak na CTX-a i na PHPasa, ja wiem, że PHP fu i tak dalej. Ponad 3 miliony użytkowników zostało ofiarami tego ataku. Atak polegał bardzo w skrócie na tym, że wyciągał sobie z enva wszystkie informacje o zmiennych. Jeżeli tam były jakiekolwiek klucze, no to te klucze były wyciągane i wysyłane na taką fajną domenę antitheftwebherokuap i tak dalej. No bo wiadomo, że w domenie jest antitheft, no to, że to jest legitna domena i że tam nic złego się nie dzieje. No więc wszystkie klucze po prostu wylatywały, a atakujący przejmowali sobie konta zazwyczaj tam do AWS-u, do czego byli w stanie, no i monetyzowali sobie to na swój sposób. To znaczy odpalali VM-ki kopiące kryptowaluty i inne takie zabawki, więc każdy to tam w jakiś sposób wykorzystywał. No ale tak zastanawiacie się pewnie, o co tu w ogóle chodzi? No sytuacja wygląda tak, że hej, na reddicie po 7 latach update CTX-a, popularna rzecz 750 tysięcy instalacji, skąd to się wzięło? Jak ta sytuacja wygląda? No więc to jest taki krótki przepis, tu na NPM-a, ale on też działa na PyPy-a ogólnie. Jeżeli kupicie sobie domenę, która wygasła, maintainera danej paczki, wytworzycie jeszcze raz maila, to jest taki krótki skrót, to jesteście w stanie przejąć kontrolę nad paczką i oczywiście powiedzieć hej, tu jest security patch, wypuszczacie, kto to sprawdzi? Prawdziwy maintainer, tak? No i przejmujecie kontrolę nad światem. Cały ten proces rzeczywiście w ten sposób działa, ja będę też odsyłał tam do paperów, oczywiście prezentacji na dole będzie. Ten atak wyglądał dokładnie tak, że domena jednego z maintainerów wygasła, nie przedłużył jej, ktoś sobie tą domenę zarejestrował, po rejestracji założył maila, przejął domenę, no i cyk. I ataczek mały. Ten graf po prawej pokazuje jak można to zrobić, bo jak wiecie dosyć sporo projektów przeniosło się na GitHuba, więc w momencie kiedy profil nie istnieje, no to można spróbować sklejmować taką paczkę. Z drugiej strony, jeżeli to jest prywatna domena i ona nie została przedłużona, to można ją kupić, no to też możecie taką paczkę przejąć, bo informacje o tym, kto był maintainerem są związane z paczką. No dobra, no i teraz jakie były reakcje, co trzeba zrobić? No tak, ale włączcie 2FA, przecież trzeba mieć włączone 2FA, inaczej nie będzie nic działało, nie każdy miał włączone. Safety, wiadomo trzeba zapłacić, PIP audit, wszystko to oczywiście może w pewnych sytuacjach pomóc, ale to był zasadniczy flow z pytaniem o to, kto jest prawowitym właścicielem tej paczki, no i ten flow właściwie trochę trwa. Oczywiście tutaj jest lepiej, bo niektórzy to 2FA włączają, ale nie wszyscy. Typo squatting, ktoś słyszał kiedyś takie pojęcie, je, siemano, dobry, cześć. Był taki ziomek, który, to jest dawno, ja wiem, że to jest stare, ale w roku 2016 stwierdził, wygeneruję sobie trochę takich paczek, takich paczek, które nie będą prawdziwe, ale będą udawały prawdziwe paczki, których ludzie często szukają, a że ludzie są ludźmi, często się mylą. Jak piszą coś na klawiaturze, to tu im się palusze gąsknie, tu się okaże, że znają angielski tak średnio jak ja, no i potem zainstalują sobie paczkę, który będą zupełnie nie ich. No i konkluzja była taka, że ziomek dostał się tam do 17 tysięcy hostów, to miało tam odpowiadać 8 tysiącom komputerów, właśnie przez generację takich paczek, zaczął je generować po prostu jako takie typo algorytmiczne i ci ludzie, którzy te typo robili po prostu instalowali złe paczki. W efekcie macie requesta na przykład, request, request, request, request, request, request i tam ilości pobrań, polecam w ogóle, bo magisterkę na ten temat ziomek zrobił, która moim zdaniem jak na magisterkę jest całkiem fajnym dokumentem. Tak, async, async i tak dalej i to zostało pobrane. Oczywiście na gościa wpadła niezła fala hejtu po tym wszystkim, ziomuś jak mogłeś to zrobić, natomiast z mojej perspektywy to on pokazał bardzo duży problem bezpieczeństwa, tego, że no będziemy się mylić, ewentualnie niektóre osoby będą robić kopii w klej instalacji jakichś paczek, które będą pobierały tam ze stagowe flow czy czegoś, no i to dalej może się dziać, no bo jak ktoś poda taką fałszywą paczkę, no to mamy problem, bo mamy kogoś, kto nam chce zrobić coś złego. Ja wiem, użyj opcji szukaj, na elektrodzie by mnie zjedli, to jest stare, ale lubię powtarzać, bo to jest coś, co uważam, że cały czas będzie się pojawiało jeszcze tak długo, jak kodeks nas wszystkich nie zastąpi. A ktoś kojarzy jellyfisza? To jest jeszcze jeden z takich przykładów, kiedy Comic Sans może uratować wasze życie. Ja wiem jak to brzmi, ja wiem jakie to jest straszne, natomiast jak zobaczycie, pojawiła się taka paczka, która nazywała się jellyfish, no i arealem tego nie zobaczycie, nie wiem czego tam używacie w swoim terminalu, ale ta paczka, okazało się, że jest bardzo zła, bo ona kradnie sobie wszystkie klucze SSH, wszystkie klucze GPG, które macie na kompie, po prostu znajduje wszystko i wysyła sobie dalej, no i potem korzysta z tych dostępów. Więc niby mała rzecz, ale jakby ktoś zostawił to w jakimś manualu, w necie, no przecież tego się nie da normalnie zauważyć, tak? Mały disclaimer, nie zachęcam was do tego, żebyście teraz z Comic Sansa korzystali, ale po prostu z takiego fonta, gdzie I i L można łatwo rozróżnić. Pojawiło się też coś nowego i to jest efekt wojny, która jest za naszą południowo-wschodnią granicą, właściwie stąd bardziej tak trzeba powiedzieć. Pojawił się protestware, to nie będzie z ekosystemu pythonowego, natomiast to będzie Note IPC, nie wiem czy ktoś z was słyszał o tą historię. O, słyszałem. Tak, słyszałem, że po prostu goście przykrywały fonta, po prostu wykrywało, że jeśli twój adres jest w Unii Rosyjskiej albo w Białoruskiej, to próbowało coś usłyszeć. Dzięki. Tak, tak. Dokładnie tak to wyglądało, natomiast kontekst jest taki śmieszny, bo on jest trochę odwrotny do tego, co znajdziemy w większości malwareu. Chwila na reklamę. W większości malwareu to jest tak, nie wiem czy na przykład śledziliście Cerberusa, który swojego czasu atakował większość androidów. Tam jest takie proste sprawdzenie po lokalach, które mówi siema ziomek, jeżeli jesteś z, to się nazywa wspólnota zjednoczonych państw, czyli tam Kazachstan, Rosja, Białoruś i tak dalej i tak dalej, to tego celu nie atakujemy. A tutaj było odwrotnie, twórca Note IPC stwierdził, że jak on sobie zgeolokalizuje, że ktoś korzysta z tej biblioteki z terenów Rosji, no to będzie wywalał pliki. Po prostu w ramach protestu. Tam po 16 marca zaczęły się pojawiać serduszka, potem była taka sytuacja, że po prostu zostawiał wiadomość o tym, o pokoju, którego jakby chciałby, żeby był pokój na pulpicie, natomiast to był pierwszy taki przypadek, który miał taki rozgłos. No ale powiecie, gdzie tam Note IPC, ja wiem, że to nie jest dany ekosystem, nie jest aż taki wielki, no to jest tam 500 tysięcy ściągnięć w ciągu miesiąca. Oczywiście złamało to wszystkie regulaminy GitHuba, NPM-a, wywalili tą mapkę, no ale potem trzeba było przywrócić, została w starszej wersji, żeby nie było problemów, natomiast pojawił się problem z zależnościami, no bo o ile Note IPC, no to to tam tylko te 500 tysięcy instalacji, to na przykład jest coś takiego, co nazywa się Vue.js, które już ma dwie bańki ponad, więc jak to zależności, jedni załączają drugich i ten problem jest po prostu większy. Później zostało to rozwinięte do takiej paczki jak Peace Note War, zostawiam wam linka, jak będziecie ciekawi. To, że to się pojawiło w NPM-ie nie znaczy, że nie może pojawić się gdzie indziej, to znaczy życie na latest to zawsze życie na krawędzi, ale to takie. Kolejny temat to jest dependency confusion. To jest taki temat, który był strasznie nahypowany i wydaje mi się, że coraz bardziej będzie nas dotyczył. Przyszedł sobie taki ziomek i powiedział, wiecie co, włamałem się do Apple'a, Microsoft'u, Paypal'a jak się okazuje i innych takich. I to jest atak na supply chain, który on zastosował. Co zastosował ten ziomek? Zastosował nierówność. W sytuacji, kiedy macie jakieś repo i w tym repo będziecie mieli paczkę, która jest paczką prywatną. I to jest takie zachowanie, które na początku on pokazywał na NPM-ie, ale dojdziemy też do Paypal'a. Jak będziecie mieli paczkę w nowszej wersji, no to co się działo normalnie? Brało się po prostu paczkę w wyższej wersji, tak to działa. Więc tutaj ten atak, który jest akurat pokazany, bo to są wewnętrzne biblioteki w Paypal'u, wrzucił do publicznego repozytorium złośliwą wersję paczki, która miała po prostu wyższą wersję i ta paczka została zaciągnięta do build'u wewnętrznym systemie. No więc w momencie, kiedy tam można sobie pobrać taką wersję, ja wiem, że PEP 440 mówi o tym, że jak macie wewnętrzne repozytorium, to jest one precedensem. Natomiast niech pierwszy rzuci, kto nie miał z tym problemu i zawsze to działało poprawnie, w sensie tak w przypadku poprawnej konfiguracji od roku, jeżeli się nie mylę, 2019 powinno to tak działać, ale nie zawsze tak radośnie było. Więc to jest taka gwiazdka na zasadzie, hej, taki rodzaj ataku jest i on skończył się tak, że ziomek stwierdził, kurczę, trzeba teraz skeszować to wszystko. I jak już udało mu się zbudować te wszystkie apki, które miały złe biblioteki, to znaczy biblioteki postawione przez niego, bo on rzeczywiście zaczął atakować te prywatne lipki różnych operatorów, różnych firm, no to on wykonywał zapytania DNS-owe, to znaczy robił taki typowy tuneling przez DNS-a, żeby wyjść na świat z tych zainfekowanych komputerów i w ten sposób potwierdzał, że dostał się do różnych firm. Fajna rzecz, pamiętajcie, problemy z bezpieczeństwem to zawsze jest DNS. Przechodzimy do tematu CI-owego. Zakładam, że nikt z was już nie żyje bez CI w życiu. To będzie parę prostych przykładów. Show of hands, tak, czy ktoś z kodkowa korzysta? Nie, okej, kodkow. To jest w miarę stary element, 2021 rok. Ktoś dostał się do ich systemu, tam miał taki element systemu, który nazywał się bash-uploader. Okazało się, że no podmienił im tego bash-uploadera, w związku z tym wszyscy użytkownicy, którzy z tego korzystali, ich kredenszale zostały narażone. Wszystkie tokeny, wszystkie klucze i wszystko to, co było przekazywane do tego CI-runnera trzeba wymienić, no bo ktoś się do tego po prostu dostał. I dalej, wszystkie serwisy, datastory, które tam się pojawiały, git remote information, wszyscy zostali narażeni. No ale nie korzystacie, to się nie ma co przejmować, nie? W sumie to tak. Efekt jest taki, że z Kotkowa korzystało 29 tysięcy klientów, łącznie z Atlassianem, Proctor Gamble, GoDaddy i tam trochę projektów open source'owych, więc mając w głowie gdzieś to, że pojawiają się ataki na cały supply chain, to nie jest tak, że można takie sytuacje olać. Jak się pojawiają, mimo że to nie nasz CI, warto byłoby na to zwracać uwagę. I takie trzy punkty, ja będę zanudzał. Bądźcie gotowi na to, żeby wymieniać klucze, bądźcie gotowi na to, żeby zmienić rzeczy w swoim software development lifecycle chainie, no bo warto coś takiego zaadresować. I zobaczcie, które wersje są zaafektowane, tak? To taki element. Kolejny element to jest Travis, oni mieli taką fajną CV-kę, no tam było ponad 900 tysięcy open source'owych projektów zainfektowanych, bardzo podobna sytuacja, ale tych publicznych, którzy mieli swoje kredenszale. Czy ktoś z Travisa korzysta? Ok, jest trochę, dzięki, dzięki. Także podobnie, jak inkludowaliście te open source'owe rzeczy, no to jak ktoś miał czas, to pewnie to zweryfikował. No więc to takie było po prostu kolejne kabum, fajnie, święta, te sprawy. To mnie też trochę zabolało, CircleCI w tym roku, w styczniu. Bardzo podobna rzecz, czy ktoś z Circle'a korzysta? Ojej, siema. Wszystko wyciekło, jeżeli chodzi o environment variables, o tokeny, o klucze, czyli to co jest wrażliwe. Trzeba było to wymienić, przez długi czas nie było nawet wiadomo, kogo to dotyczy. No więc, nie wiem, będę się powtarzał, ale do wymiany klucze, do wymiany wszystkie sekrety, im większe macie środowisko, im większą firmę, tym dłużej to zajmuje. Natomiast przykłady tych CI'ów pokazują, że trzeba być na to tak czy inaczej gotowym, bo prędzej czy później ten dzień nadejdzie i trzeba będzie po prostu to wymieniać. I fajnie jakby wszystkie systemy nie padły przez to, żeby pokazać Wam, że jest jeszcze taki fajny zbiorek, trafiłem na taki paper, on się nazywa Backstabbers Knife Collection, a Review of Open Source Software Supply Chain Attacks. Polecam go w wolnej chwili, nie będę Was długo o nim męczył. Natomiast badacze zrobili taką fajną klasyfikację tego, co w ogóle się dzieje. No i mamy stworzenie nowej paczki, która będzie jakimś trojanem, wykorzysta typosquatting, jak w poprzednim przypadku, jak jest use after free. Mamy infekcje istniejących paczek przez dorzucenie czegoś do źródła, no bo wiecie, nie wszystkie MR'y, w sensie emergency questy zostaną zawsze poprawnie stwierdzone, sprawdzone, czasami coś przejdzie. Commedia, maintainer po przejęciu konta, ewentualnie po nakłonieniu kogoś, hej, to jest dobra rzecz, słuchajmy, tutaj naprawiłem, duża część projektów nie ma takich ongoing audytów, to wychodzi po jakimś czasie, ale nie od razu. Inject do budowania, czyli wpływanie na CI, na systemy buildowe, ewentualnie próba podrzucenia paczek, tak jak tam ten atak, który był związany z przejęciem tych paczek paypalowych, wewnętrznych, to też może nas zaboleć, jak ktoś coś takiego znajdzie. Inject w system repozytoriów, jeżeli jakieś credentiale gdzieś wyciekły, no to może się okazać, że ktoś ma takie credentiale do GitHuba, to się ładnie nazywa credential stuffing, tak, czyli jak wam coś wyciekło to sobie to na hewa i pingpong i macie to hasło gdzie indziej, warto zmienić, dodać tu fa, zawsze spoko i exploit vulnerabilities, deploy w innym repozytorium, w innym mirorze. Po co to jest zrobione? To jest tam na poziomie install scriptów, this case runtime, to jest jakby tam detal moim zdaniem, gdzie to się najczęściej pojawia, bo to już nie jest najnowsze badanie, to jest 2021, jak się nie mylę. Natomiast w PyPayu w większości przypadków to były konie trójnańskie i w większości przypadków to był typosquatting, natomiast w przypadku innych repozytoriów to są też czasami infekcje istniejących paczek albo po prostu przejęcie credentiali do jakiegoś repo. I co jest celem? W przypadku PyPaya backdory, czyli wyciągajmy sobie coś, eksfiltracja danych, weźmy sobie jakieś klucze do cloudów, do tego co tam jest dostępne, ewentualnie jakieś klucze SSH i tak dalej, dropera tutaj to 29%, 29 przypadków było droperów, dropery jak w nomenklaturze takiej związanej z bezpieczeństwem to są takie programy, które mają za zadanie ściągnąć inny malware, to znaczy twórcy droperów często robią tak, że mówią dobra słuchaj, ja wam kogoś zarażę, a potem trochę jak z reklamy na Google czy na Facebooku, kto im zapłaci więcej to jeszcze doinstaluje wam więcej malwareu, więc to jest taka furtka za pomocą której rozprzestrzenia się więcej malwareu, no i financial gain, czyli pewnie jakieś krypto, czy inne próby, żeby zaatakować jakieś cookiesy na banki i inne takie elementy. I to właściwie tak bardzo szybko, no co robić jak żyć, pamiętajcie, że Comic Sans może uratować wasze życie, wbrew pozorom, wszyscy używamy zależności, jesteśmy zależni od open source'u bardziej albo mniej, niektórzy nie lubią tego mówić wprost, jak tylko macie szansę, żeby poćwiczyć ratowanie kluczy, to moim zdaniem warto, bo prędzej czy później i tak będziecie musieli to robić, albo ze względu na problemy z technologią, albo ze względu na to, że wasz provider będzie miał z tym problemy. Kopia zapasowa jest zawsze dobrym pomysłem, no bo ransomware teraz krąży, szczególnie taki pachnący wschodem, opiekunowi PyPy'a i wszyscy fajnie jakby włączali MFA, jak macie jakąś swoją paczkę, to upewnijcie się, że na GitHub'ie wszystko jest włączone, naprawdę może wszystkim nam uratować pupy w pewnym momencie. Mieszanie zależności publicznej i prywatnej jest ryzykowne, ogólnie, ja bym tak powiedział, że lepiej byłoby tego nie robić, wiem, że są pewne specyficzne przypadki, ale upewnijcie się przynajmniej, że konfiguracja jest poprawna, a nie tak, że ktoś będzie ssał po prostu z publicznego PyPy'a za każdym razem, warto to zainforsować na poziomie swojej organizacji i jeżeli nie korzystacie nawet z oprogramowania typu open source, no to zachowajcie prywatność swoich repozytoriów i to też nie jest tak, że wiecie, jak open source zostanie gdzieś tam skompromitowane, tak jak podkazał przykład Kotkowu, Trevisa czy pewnie innych systemów, no to to będzie się działo i będzie miało wpływ na wasz ekosystem, więc warto być po prostu na bieżąco. I to tyle, bardzo dziękuję. Dziękuję bardzo. Zapraszam do zadawania pytań. Na podstawie tego, co ostatnio było, sytuacja z GitHubem, gdzie wyciekł im klucz. RSA. Czy znasz może jakieś narzędzie, które mógłbym dodać do CICD, żeby zabezpieczyć się przed tym, żeby w mojej firmie jednak to nie wyciekło? To jest fajne pytanko. Dla kontekstu historia z GitHubem wygląda tak. Ktoś im się wbił i okazało się, że klucz prywatny RSA, który był wykorzystywany do tego, żeby później klucz publiczny reprezentować po stronie GitHuba, uznali, że wyciekł. Czyli, że ktokolwiek z was, gdyby się łączył do GitHuba, gdyby łączył się do tego klucza RSA starego, no to nie mielibyście pewności, że to, co tam pushujecie, czy tam ściągacie, jest prywatne. No bo jak klucz wyciekł, no to są problemy, jeżeli chodzi o bezpieczeństwo całego krypto. Oni wymienili ten klucz, każdy, kto korzystał z EDD25519, w sensie z tego klucza, który jest związany z krzywymi eliktycznymi, nie ma problemu, więc spoko. Natomiast jak wam się pojawił taki prompt warning, klucz został zmieniony, to jesteście w nosie. I co można zrobić na poziomie CICD? Po pierwsze, jak ten warning się pojawia, że klucz się zmienił, no to robimy abort taki gruby, wszystko na czerwono, errory i tak dalej, no bo to, co oni zrobili, jak już wymienili ten klucz, ewentualnie ktoś by próbował podejść z innej strony i zrobiłby jakieś tam DNS poisoning na twoim systemie buildującym i spróbował by cię zamiast do GitHuba do jakiejś swojej domeny wrzucić, no to ten klucz też będzie inny. Więc ja bym monitorował, czy ten klucz się nie zmienia, no bo to jest taka zasada zaufania, tak na gorąco mówiąc, na podstawie której wiesz, że to jest ten GitHub, czy nie. No i pewnie w jakąś grafankę bym sobie wyrzucił, jak często ten klucz się zmienia, bo on nie powinien się zmieniać zbyt często, więc jak się zmienia, to żeby przynajmniej o tym wiedzieć. Tak na szybko. Dobra, dzięki. Cześć, super prezentacja. Ja mam taki pewien pomysł, jak rozwalić świat i pomyślałem sobie tak, mówiłeś o ludziach, którzy z błędem wpisują nazwę paczki. A co by było, gdybyśmy na przykład wszyscy dzisiaj usiedli na chat GPT i każdy z nas by zaczął pisać, że nie wiem, weźmy najbardziej jakąś popularną paczkę z Pythona, nie wiem, niech to będzie pil do obrazków i byśmy zaczęli pisać, że nie, to jest błąd, pil nie jest, nie służy do obrazków, do tego służy paczka 1, 2, 3, 4. Czy myślicie, że po dłuższym czasie, jakbyśmy się w 100 osób zebrali, to chat GPT by się przekonwertował i zaczął ludziom podpowiadać tą paczkę? To jest fajne pytanko, bo to jest pytanko o to, czy można zrobić, a tak well-poisoning na generative pre-trained modelu. Dokładnie. I problem jest taki, że GPT to jest pre-trained model i jakby nie jesteś w stanie wpłynąć na to, co on ma w tej swojej bazowej wiedzy, ale jakby czwórka teraz rozszerzyła swój zakres pamięci w tokenach, czyli tego co ma jakby w takiej swojej pamięci podręcznej do 25 tysięcy znaków, więc ty inżektując jakieś informacje mówiąc hej, to jest złe, to nie jest tak, ta paczka to jest prawdziwa, ty mi nie mów innego, wpływasz na swoją sesję, ewentualnie trzeba by to zrobić tak, bo nie wyjdziesz poza swoją sesję, w sensie wpłyniesz tylko na twoje odpowiedzi, ewentualnie zakładam, bo nie wiem jak to robi FNI, że oni będą wykorzystywali do reuczenia w jakiś sposób, tylko oni mają dosyć silne filtrowanie, labelowanie danych, które tam wchodzi, więc zakładam, że tam jest pewien ranking i jak sobie wyobrażam, tak próbując rewers inżynierować w głowie, to tak jak działa, nie wiem, page rank google'owy, który mówi dobra, jak ty jesteś na wikipedii to ty jesteś gość, ty jesteś wysoko, a jak jesteś tam 55 stroną w google'u, która mówi, że to jest inna paczka, to pewnie jesteś o wiele niżej, pewnie stack overflow jest wyżej niż reszta, więc co do teorii, atak, well poisoning jak najbardziej jest prawdopodobny, natomiast moim zdaniem przy tych obecnych modelach nie na poziomie samego prompta, no bo prompt jest twoim lokalnym kontekstem, zresztą ostatnio się dowiedzieliśmy dzięki problemom OpenAI, że mieli problemy z Reddy Spy'em i pomyliły im się off by one cache i były serwowane historie z innego cacha, więc było wesoło, więc gdzieś to tam jest przechowywane. Dzięki i zapytanie. Cześć, dzięki, fajna prezentacja. Ja pomyślałem o czymś innym, jak kolega zadał to pytanie, a mianowicie zrobić to samo tylko z copilotem, czyli tworzyć repozytoria, które będą używać nie właściwej paczki w kontekście powiedzmy sobie przetwarzania pracy i robić to masowo, robić to dużo i w tym momencie to może się gdzieś tam w pewnym momencie uznać. Nie znam na tyle dobrze tego nowego copilota, bo teraz wyszedł ten copilot X, który jest nowy i ja nie wiem na ile on się tam doucza na bieżąco tego co się dzieje, bo z tego co wiem on ma o wiele większą pojemność tokenów, która jest związana z kodem, no bo możecie tam sobie użyć swojej sałej drzewko, on może sobie to gdzieś tam zretrainować, być może coś takiego tam jest możliwe. Ja wam dam taką gwiazdeczkę, w zeszłym roku na Blechacie była bardzo fajna opowieść gości, którzy wyciągali sekrety z poprzedniego kodeksa, w sensie z poprzedniego copilota, bo okazało się, że on był trenowany nie tylko na publicznych repozytoriach githuba, ale też na prywatnych. No i jak się domyślacie były pewne szczególne przypadki, gdzie okazało się, że trochę takich prywatności można było wyciągnąć z tego. Tak, tak, tak. Więc jak się okazuje ten AWS token już był dawny na szczęście, nieważne, ale była to troszkę wpadka. Pytacie AWS token, o masz ziomek proszę. Więc to są trochę takie zagrożenia. Ciekawy pomysł, nie wiem, zachęcam do badania, ale możemy spróbować. Dzięki. O tam też są ludzie. Cześć, jesteśmy. Chciałem zapytać jak sprawnie PiPi radzi sobie z badaniem takich zagrożeń? Czy możemy liczyć na to, że będziemy kiedyś bezpieczni? Jak sprawnie co sobie radzi? PiPi. Wiesz co, z tego co wiem to oni ogólnie rzecz biorąc są dosyć otwarci, jeżeli chodzi o disclosure tego wszystkiego na końcu, bo wszystko gdzieś tam ląduje na zewnątrz. Nie wiem co jest w środku mówiąc szczerze, bo poza tym, że dowiedziałem się, że kod jest publiczny, no to oprócz samego kodu, który jest publiczny do tego jak PiPi, to się warehouse nazywa, funkcjonuje, to mamy jeszcze deployment, mamy jeszcze konfigi, nie wiemy czy tam są jakieś wafle, ECM, czy to jakieś wykrywanie anomalii, więc ciężko powiedzieć jak to działa, natomiast moim zdaniem robią świetną robotę, bo nie wierzę, że nie ma wielu aktorów, którzy bardzo chcieliby zrobić nam coś złego. Im bardziej popularna biblioteka, tym wyżej poprzeczka, tym potencjalnie więcej jesteś w stanie zyskać. SolarWindsy, które moim zdaniem zapoczątkowały w ogóle w takiej erze bezpieczeństwa ataki na supply chain, no to były grube pieniądze, za tym chyba stało, nie pamiętam czy to było rosyjskie GRU, czy FSB, bo tam jeden z tych aptów rosyjskich i dostali dostęp do wielu rzeczy. No więc trochę powiem tak, stawka jest tak wysoka, że moim zdaniem goście jak na razie robią dobrą robotę, albo nie wiemy, że zostali skompromitowani. Ewentualnie, wiecie, to pokazuje przykład tego, co się stało z Outlookiem niedawno, bo to ukraiński CERT tydzień, czy dwa tygodnie temu poinformował, że załapali atak na Outlooka, który tam próbował się łączyć na zewnętrzną sambę, tam wyciekały kredenszale przez NTLM-a do domeny, no więc można było się dostać do środka sieci. No i atrybucja to był chyba APT28, czyli rosyjskie GRU znowu, no więc jak się okazało, że to jest wykorzystywane chyba od lipca zeszłego roku, no to można sobie wyobrazić, że wszystkie jakby jednostki rządowe, czy firmy, które przez taki długi czas byli na to podatne, nie, więc no jakby tego idzie cały czas, dosyć sporo i ta wojna trwa, więc warto aktualizować paczki, aktualizować wszystko, to życie na lejtest, to życie na krawędzi. Ostatnie pytanie. To ja mam pytanie, jak sobie radzą popularne narzędzia do statycznej analizy kodu, takich jak Snixon, Arcube, które właśnie de facto można wrzucić do pipeline'a, czy one są w stanie wykryć takie, powiedzmy, zmiany złośliwe w paczkach, czy to bardziej na zasadzie zero-day'a, że zanim oni się pojawią, to już kilka paczek będzie pobranych? To jest bardzo dobre podejście. Pytanie było o Snyka, Sonara i jest trochę takich rozwiązań, nie wiem, Trivii, Opera, i to, które można sobie tam wrzucić, natomiast niektóre działają na poziomie dependencies, niektóre działają na poziomie kodu. Im więcej tego dorzucicie, tym większa szansa, natomiast zawsze w tym bezpieczeństwie jest taki problem, że wiecie, jest zero-day, ktoś coś wymyślił, poszło, potem jest detekcja i potem jest remediacja, nie, więc w momencie, kiedy coś przejdzie i nikt tego nie zauważy, no to jest problem i to jest trochę tak jak z takim wyścigiem pomiędzy ludźmi tworzącymi malware'a, antywirusami, że jest nowa metoda na ukrycie czegoś, przechodzi dalej, nie wiem, mamy taki prosty przykład Base64, gdzie nie chcemy, żeby ktoś się od razu pokumał, że tam zbieramy environment variable, tak jak tutaj było i wysyłamy, pewnie to przejdzie, ale w narzędziach takich statystycznych okaże się, hej, kurde, co to za wysoka entropia tu jest, w ogóle to jakieś takie podejrzane. No i wysoka entropia to teraz taki podstawowy współczynnik, na który gdzieś się tam patrzy i goście, z tego co wiem, ze Snyka, miałem okazję kiedyś poznać founderów, bardzo silnie rozwijają swój ML, który takie rzeczy ma łapać, oni od razu wrzucają się w to w analizę i reagują i to jest petarda, więc można powiedzieć, że jest coraz więcej takich serwisów, że płacisz za swój spokój ducha i bezpieczeństwo, bo ktoś sprawdza te dependencje, bo nie jesteś tego w stanie sam zrobić w skali, bo jest ich, kurde, tak duże, że to jest masakra. I one się potem gdzieś tam propagują, więc ja mam tak, nie mam, jakby, nie namawiam was do kupienia Snyka, ale uważam, że to jest naprawdę bardzo fajne podejście, jest coraz więcej firm, które też robi takie sasty, które bada sobie jak one funkcjonują i dzisiaj w tym świecie, gdzie jesteśmy bardzo zależni od reszty, wydaje mi się, że ciężko jest bez tego żyć, no chyba, że jesteś w stanie utrzymać team, który sam to będzie reviewował, ale to jest nie do utrzymania, więc jedyne podejście. Pewnie będą się pojawiały jakieś nowe metody, natomiast te takie typowe, które się pojawiają, wiecie, protestware ma już osobną kategorię, już tego było trochę, nie, oni bardzo fajnie o tym mówią, jak pojawiają się jakieś stealery, fajnie o tym mówią, są świetnym źródłem, ja w ogóle uważam, że firmy, które przychodzą w taki sposób, że mówią, hej, my robimy płatną usługę, ale dzielimy się tym publicznie, więc jak już wiesz, wiemy o jakimś ataku, to tak, jak widzicie, to jest petarda, bo to zmienia całą społeczność, więc taki model, z jednej strony, że to wpuszczają, a z drugiej mają serwis, mi się bardzo podoba. Ja mam jeszcze taki komentarz bardziej niż pytanie. Czy możesz polecić jakieś abecadło, jeżeli chodzi o weryfikowanie zawartości obrazów dokerowych, które nie są oficjalnymi obrazami? Przykładowo, mamy sobie organizację, która robi rzeczy AI fancy i widzimy, że jakieś środowisko badawcze, jakaś grupa programistów stworzyła rozwiązanie, zamyka to w dokerze, bardzo fajnie, super. Jak to zweryfikować, co jest w środku, czy maszyna wirtualna nie została w jakiś sposób zrefaktorowana, czy nie ma gdzieś bytecode'u ukrytego? Czy masz jakieś takie abecadło, jaką my, deweloperzy, Pythona możemy wdrożyć? Wiesz co, ja bym trochę ten problem odwrócił, bo ja tam się nie znam na Pythonie, tak jak mówiłem, ale jest teraz taki paradygmat, który nazywa się zero trust. To znaczy, ja lubię moich deweloperów, ale nie do końca im ufam. W związku z tym, jakby tylko tak się dało, jak najbardziej odizolować między sobą, nie wiem, wszystkie mikroserwisy, wszystko to, co się tam dzieje, żeby to nie miało dostępu do wszystkiego, to zaczynasz sobie od takiego podejścia, że minimalizujesz impakt potencjalny. No bo kiedyś ta wpadka będzie, prędzej czy później, w skali ta wpadka musi nastąpić. Więc jak ktoś skorzysta z jakiegoś tam doker image'u, który okaże się, że będzie miał jakieś podatności, i on nie wiedział, ale to nie zostało sprawdzone, no ale poszło. No i to się będzie zdarzać w startupach, tym bardziej, no bo była potrzeba, była presja czasu, więc poszło. Więc ja bym próbował na początku ograniczać pomiędzy sobą jakiś tam serwis meshem, ewentualnie jakimiś regułami tym, co kto może zrobić, wewnętrznym wafem, czy tu nie ma jakichś anomalii, no bo pierwsze, co robią atakujący, to patrzą do czego mają dostęp, próbują spiwotować gdzieś indziej, jak już im się doda w pierwsze miejsce. No i to jest moment, kiedy to można spróbować złapać. Natomiast jeżeli już macie trochę bardziej dojrzałą organizację, super jest mieć base image'e. Polecam golden image'e jeszcze takie, które są zhardenowane, które tam nie mają najpopularniejszych CV'ek, które tam są najbardziej krytyczne. To nie jest też tak, że wiecie, że wszystkie CV'eki, które wam się tam pojawią, common vulnerability numerator, tak CV'eki, przepraszam, ja tam strasznie w bańce swojej jestem, to warto z takich rzeczy skorzystać, bo są goście, którzy to po prostu utrzymują, one zazwyczaj nie są latest i to jest problem taki, że jak masz kogoś, kto mówi, kurde, no o lipka, o jedziemy z tą lipką, ale nie wszędzie ją znajdziecie, nie w każdym obrazku, więc obrazek trzeba sobie przebudować, trzeba go spuszować itd. I tu jeszcze taka mała gwiazdeczka, bo wiecie, to się tak też zdarza, że te obrazki gdzieś tam znikają, w sensie macie jakąś zależność, obrazki znikają, warto sobie go skaszować u siebie, no bo co by było, że ktoś tak zbudował ten obrazek jeszcze raz, ale dodał coś od siebie na odpowiednim tagu, więc to jest cały inny wszechświat problemów, ja dlatego nie znam się na tym, to nie ufam i staram się oddzielać od siebie jak tylko można. Dzięki. Dzięki bardzo. Dobrze, gdzie idzie książka? Ja, mi się bardzo podobało pytanie snykowe, także książka idzie tutaj do ziomka od snyka. To tak blisko mojego świata. Dzięki bardzo. I co, widzimy się za chwilę. Dzięki za zaproszenie. Dzięki serdeczne, ale jeszcze wiadomo, coś od nas nie ukuść tylko. Dzięki, mam nadzieję, że jeszcze nas odwiedzisz nie raz. To jest pewne. Dzięki. To ja mam pytanie, jak sobie radzą popularne narzędzia do statycznej analizy kodu, takie jak snyk, sonar, kube, które właśnie de facto można wrzucić do pipeline'a, czy one są w stanie wykryć takie, powiedzmy, zmiany złośliwe w paczkach, czy to bardziej na zasadzie zero day, że zanim oni się zorientują, to już kilka paczek będzie pobranych. To jest bardzo dobre podejście. Pytanie było o snyka, sonara. Jest trochę takich rozwiązań, nie wiem, triwiopei, do których można sobie tam wrzucić. Natomiast niektóre działają na poziomie dependencies, niektóre działają na poziomie kodu. Im więcej tego dorzucicie, tym większa szansa. Natomiast zawsze w tym bezpieczeństwie jest taki problem, że wiecie, jest zero day, ktoś coś wymyślił, poszło, potem jest detekcja i potem jest remediacja. Więc w momencie, kiedy coś przejdzie i nikt tego nie zauważy, to jest problem. To jest trochę tak jak z takim wyścigiem pomiędzy ludźmi tworzącymi malware a antywirusami, że jest nowa metoda na ukrycie czegoś, przechodzi dalej, nie wiem, mamy taki prosty przykład Base64, gdzie nie chcemy, żeby ktoś się od razu pokumał, że tam zbieramy environment variable, tak jak tutaj było i wysyłamy. Pewnie to przejdzie, ale w narzędziach takich statystycznych okaże się, że hej, kurde, co to za wysoka entropia tu jest. W ogóle to jakieś takie podejrzane. No i wysoka entropia to teraz taki podstawowy współczynnik, na który gdzieś się tam patrzy i goście, z tego co wiem ze Snyka, miałem okazję kiedyś poznać founderów, bardzo silnie rozwijają swój ML, który takie rzeczy ma łapać, oni od razu wrzucają się w to w analizę i reagują. I to jest petarda, więc można powiedzieć, że jest coraz więcej takich serwisów, że płacisz za swój spokój ducha i bezpieczeństwo, bo ktoś sprawdza te dependencje, bo nie jesteś tego w stanie sam zrobić w skali, bo jest ich, kurde, tak dużo, że to jest masakra. I one się potem gdzieś tam propagują, nie? Więc ja mam tak, nie mam, jakby, nie namawiam was do kupienia Snyka, nie? Ale uważam, że to jest naprawdę bardzo fajne podejście, jest coraz więcej firm, które też robi takie sasty, które bada sobie jak one funkcjonują i dzisiaj w tym świecie, gdzie jesteśmy bardzo zależni od reszty, wydaje mi się, że ciężko jest bez tego żyć, no chyba, że jesteś w stanie utrzymać team, który sam to będzie reviewował, ale to jest nie do utrzymania, więc jedyne podejście. Mi się bardzo podoba. Ja mam jeszcze taki komentarz bardziej niż pytanie. Czy możesz polecić jakieś abecadło, jeżeli chodzi o weryfikowanie zawartości obrazów dokerowych, które nie są oficjalnymi obrazami? Przykładowo, mamy sobie organizację, która robi rzeczy AI fancy i widzimy, że jakieś środowisko badawcze, jakaś grupa programistów stworzyła rozwiązanie, zamyka to w dokerze, bardzo fajnie, super. Jak to zweryfikować, co jest w środku, czy maszyna wirtualna nie została w jakiś sposób zrefaktorowana Pytona, czy nie ma gdzieś bytecode'u ukrytego, czy masz jakieś takie abecadło, jako my deweloperzy Pytona możemy wdrożyć? Wiesz co, ja bym trochę ten problem odwrócił, bo ja tam się nie znam na Pytonie, tak jak mówiłem, co ja tam wiem, ale jest teraz taki paradygmat, który nazywa się zero trust, to znaczy ja lubię moich deweloperów, ale nie do końca im ufam, w związku z tym jakby tylko tak się dało jak najbardziej odizolować między sobą, nie wiem, wszystkie mikroserwisy, wszystko to, co się tam dzieje, żeby to nie miało dostępu do wszystkiego, to zaczynasz sobie od takiego podejścia, że minimalizujesz impakt potencjalny, no bo kiedyś ta wpadka będzie, prędzej czy później, w skali ta wpadka musi nastąpić, więc jak ktoś skorzysta z jakiegoś tam doker imedgu, który okaże się, że będzie miał jakieś podatności, no ale on nie wiedział, ale to nie zostało sprawdzone, no ale poszło, no i to się będzie zdarzać, w startupach tym bardziej, no bo była potrzeba, była presja czasu, więc poszło, więc ja bym próbował na początku ograniczać pomiędzy sobą jakiś tam serwis meshem, ewentualnie jakimiś regułami tym, co kto może zrobić, wewnętrznym wafem, czy tu nie ma jakichś anomalii, no bo pierwsze, co robią atakujący, to patrzą do czego mają dostęp, próbują spiwotować gdzieś indziej, jak już im się doda w pierwsze miejsce, no i to jest moment, kiedy to można spróbować złapać, natomiast jeżeli już macie trochę bardziej dojrzałą organizację, super jest mieć base imidże, polecam, golden imidże jeszcze takie, które są zhardenowane, które tam nie mają najpopularniejszych cv-ek, które tam są najbardziej krytyczne, to nie jest też tak, że wiecie, że wszystkie cv-eki, które wam się tam pojawią, common vulnerability numerator, tak, cv-eki, przepraszam, ja tam strasznie w bańce swojej jestem, to warto z takich rzeczy skorzystać, bo są goście, którzy to po prostu utrzymują, one zazwyczaj nie są latest i to jest problem taki, że jak masz kogoś, kto mówi, kurde, no lipka, jedziemy z tą lipką, ale nie wszędzie ją znajdziecie, nie w każdym obrazku, więc obrazek trzeba sobie przebudować, trzeba go spuszować i tak dalej i tu jeszcze taka mała gwiazdeczka, bo wiecie, to się tak też zdarza, że te obrazki gdzieś tam znikają, w sensie macie jakąś zależność, obrazki znikają, warto sobie go skaszować u siebie, no bo co by było, jakby ktoś tak zbudował ten obrazek jeszcze raz, ale dodał coś od siebie na odpowiednim tagu, więc to jest cały inny wszechświat problemów, ja dlatego nie znam się na tym, to nie ufam i staram się oddzielać od siebie jak tylko można. Dzięki. Dzięki bardzo. Dobrze, gdzie idzie książka? Mi się bardzo podobało pytanie snykowe, także książka idzie tutaj do ziomka od snyka. To tak blisko mojego świata. Dzięki bardzo. Już tu się ogarnę. I co? Widzimy się za chwilę. Dzięki za zaproszenie. Dzięki serdeczne, ale jeszcze wiadomo, że jeszcze nas odwiedzisz nie raz. To jest pewne, to jest pewne.