W tym odcinku analizujemy problem wycieków sekretów w Postmanie — narzędziu do testowania API — i wskazujemy na rolę nieintuicyjnego interfejsu (UI/UX) w niezamierzonym upublicznianiu wrażliwych danych. Punktem wyjścia jest research firmy Truffle Security, której zespół przeskanował 40 tysięcy publicznych workspace'ów i znalazł w nich 1700 sekretów reprezentujących 183 różne usługi.

Dalej omawiamy najnowszy raport Verizon Data Breach Investigations Report (DBIR): motyw finansowy stojący za większością incydentów, phishing, w którym mediana czasu do kliknięcia w złośliwy link wynosi mniej niż 60 sekund, oraz klucze sprzętowe jako najskuteczniejszą obronę. Na koniec wracamy do ataku dependency confusion w zarządzaniu pakietami oraz analizujemy „dramę" Slacka wokół wykorzystania danych użytkowników do trenowania modeli AI — i znaczenie transparentnej komunikacji.

Transkrypcja

Pełna transkrypcja odcinka

KrzysztofCześć, witamy Was bardzo serdecznie w kolejnym odcinku naszego podcastu. Witam Ciebie Andrzej i chciałbym od razu zaznaczyć, że szopa rośnie.

AndrzejSzopa rośnie. Da się zauważyć, wchodzicie na YouTuby. No ja jestem obecnie w tym najgorszym punkcie zapuszczania włosów, czyli są jeszcze nie na tyle długie, żeby je zaczesać do tyłu. ale już na tyle długie, że nie chcą się ułożyć tak klasycznie, więc jestem pomiędzy, w takim limbo, no i nie mam jak nimi zarządzić. Niestety to jest moja codzienna fryzura, dlatego często noszę czapki, ale podcasty jednak będę nagrywał bez czapki.

KrzysztofNawet ostatnio miałeś bardzo ciekawą czapkę, więc zachęcamy do odwiedzenia na profilu Andrzeja i żeby zobaczyć jak ta czapka wyglądała. Była bardzo, bardzo tematyczna na bardzo tematycznym meetupie.

AndrzejKontekstowa. Tak, tak. Tutaj się wpasowałem kontekst w stu procentach z czapką, ale to można zobaczyć na moim Linkedinie. Krzysiek, przychodzimy w kolejnym odcinku. Mamy kolejną porcję ciekawych rzeczy, które przykuły naszą uwagę. Natomiast moją uwagę przykuło to, że co prawda w poprzednim odcinku udało ci się nie wspominać o sekretach, no ale ta pasa nie trwała za długo, bo widzę, że tutaj znowu sekrety.

KrzysztofTak, znowu są sekrety. Tym razem są sekrety w Postmanie. Postmana możecie kojarzyć. Myślę Andrzej, że ty Postmana kojarzysz i nasi słuchacze też. W dużym skrócie narzędzie, które służy do testowania API. Bardzo proste narzędzie, szeroko wykorzystywane szczególnie przez deweloperów czy QA, którzy testują wysyłając requesty.

AndrzejA tutaj właśnie chciałbym dodać, że ostatnio na szkoleniu jeden z QA zauważył duże podobieństwo pomiędzy Zapem a Postmanem. Zap, czyli Z-Attack Proxy, narzędzie używane przy testowaniu bezpieczeństwa, również może być używane przez QA i przez devów, ale często jest używane przez bezpieczników. I tak popatrzył, coś przeklikał i powiedział, kurczę, podobne do Postmana. No, no, jest to podobieństwo.

KrzysztofW pewnym, w pewnym przybliżeniu można, można tak to, tak to ująć. Oczywiście POSMAN wspiera jeszcze inne protokoły, nie tylko HTTP, bo tam mamy również do dyspozycji WebSockety, gRPC i kilka jeszcze bardziej egzotycznych protokołów, ale głównie CORE. to jest właśnie testowanie API poprzez requesty HTTP. No i teraz tak, nie udało mi się dzisiaj nie wspomnieć o sekretach w Postmanie, no bo Truffle Security, czyli firma, która jest odpowiedzialna za Truffle Hoga, jeden z fajniejszych skanerów w kontekście detekcji sekretów w naszych repozytoriach, ale nie tylko. Wypuścił artykuł, cały research dotyczący tego, ile tych sekretów znajduje się w publicznych workspacach, w takich galeriach tych workspaców, który Postman udostępnia na swojej stronie internetowej. Ja tutaj powiem tylko, że na ostatniej konferencji, ostatniej, zeszłorocznej konferencji The Hack Summit, pozdrawiamy w ogóle Michała z The Hack Summit. Pozdrawiamy. Tak. Żegnałem się z widownią takimi słowami, że pomyślcie sobie ile tych sekretów jeszcze jest na kanwie tego, że mamy je w paketach, mamy je w komentarzach, czasami nawet można znaleźć je w comment message’ach. I to było rzucone, był taki obrazek góry lodowej, że tak naprawdę my odkryliśmy tylko ten wierzchołek. No i te sekrety w Postmanie to jest tak naprawdę potwierdzenie tego, co mówiłem, że odkrywamy kolejną powierzchnię, w której te sekrety mogą się znajdować. Tutaj researcherzy z Truffle Security przeskanowali 40 tysięcy publicznych workspaców i znaleźli w nich 1700 sekretów. które łącznie reprezentowały 183 różne usługi, do których można było się dobić. Między innymi popularny w ostatnim czasie OpenAI, to też mówimy od kilku odcinków naszego podcastu, że tak naprawdę boom na LLM-y widać również w kontekście wypływających problemów bezpieczeństwa, szczególnie np. jeżeli chodzi o sekrety. Wykorzystywanie dużych modeli językowych, GPT-4, wiąże się z tym, że czasami musimy się połączyć przez jakiś kluczyk, a higiena korzystania z tych kluczyków tutaj też nie zawsze stoi na najwyższym poziomie. Więc tak, wyciekło 183 różnych typów sekretów, łącznie znaleziono 1700 sekretów. i teraz tak, To 40 tysięcy workspaców, które przeskanowano. to stanowi niecałe 20% wszystkich publicznych workspacu, bo tak naprawdę Postman nie podaje dokładnie ile tych publicznych workspaców jest w tej galerii. Mówią, że jest ich po prostu 200 tysięcy plus. Ile dokładnie nie wiadomo. Z racji tego, że nie da się wylistować w łatwy sposób, to jest niemożliwe, tak? Postman nie udostępnia by default takiej funkcjonalności w swoim API, żeby wylistować wszystkie publiczne workspacy, które są tak zwanym kontenerem na pewne foldery, które agregują zestawy requestów. Więc można sobie w ramach swojego workspace’a tworzyć jeszcze kolejne foldery. I w ramach tych folderów grupować requesty, które uderzają do jakichś tam naszych zdefiniowanych API. No i tak researcher tutaj podkreślają, że maksymalnie jeżeli chciał się szukać przez API jakiejś frazy, powiedzmy OpenAI, no to taki wynik zwracał maksymalnie 200 wyników. Stąd wynika ta liczba, ta próbka 40 tysięcy, ponieważ po prostu nie byli w stanie się dobić do większej ilości. Dlaczego sekrety tak naprawdę w Postmanie wyciekają?

AndrzejTu mam jeszcze pytanie, czy ja dobrze rozumiem, że to jest po prostu taka podłoga, tych sekretów mogło być więcej, natomiast oni byli ograniczeni w szukaniu, więc problem tak naprawdę może być jeszcze większy, ale tą przestrzeń, którą mogli przeszukiwać, ona była już pomniejszona przez kapability, jakie mieli.

KrzysztofDokładnie, dokładnie tak jak mówisz Andrzej. Tutaj bardzo fajnym pytaniem, które zadali sobie researcherzy było to, że o co chodzi z tym Postmanem? Dlaczego tak naprawdę te sekrety tam wyciekają? I w trakcie testów doszli do wniosku, że sam Postman w kontekście zarządzania sekretami jest bardzo nieintuicyjny. W sensie UI tej aplikacji jest na tyle nieintuicyjne, że wprowadza w pewien sposób w błąd, Definiując sobie zmienne środowiskowe dla takiego workspace’a mamy dwie wartości, initial value i current value. I initial value w zasadzie można rozumieć dwojako, bo można rozumieć jako taki placeholder dla tego sekretu, który chcemy podać w tym requestie. A tak naprawdę jest pierwszym polem od lewej strony patrząc, które można uzupełnić, więc tak naprawdę mało kto zwraca uwagę na to, że jest jeszcze to pole current value. które tak naprawdę powinno przyjąć ten prawidłowy sekret. W momencie upublicznienia takiego Rockspace’a ten QLend value nie jest upubliczniany, jest upubliczniany tylko initial value, który ma nam znać po prostu o jakimś takim placeholderze, że tutaj umieścić klucz w takim powiedzmy formacie, tak jak jest AWS, no to powiedzmy AKA i ciąg znaków. Dodatkowo jest tam taka opcja przekreślonego oczka, którą nazwali jako secret value, co tak naprawdę nie ma nic wspólnego z bezpieczeństwem, bo to przekreślone oczko i to pole, które nazywa się secret value, to tak naprawdę chodzi o maskowanie tej wartości, czyli zagwiazdkowanie jej po stronie UI-u. i to też to nazewnictwo, ta semantyka wprowadza użytkowników Postmana w błąd. I to co jest, to co jest takim, taką wisienką na torcie to jest to, że te publiczne kolekcje, te workspace, workspacy w Postmanie można forkować. I forkując je domyślnie ten fork też jest publiczny. Więc na przykład jeżeli mieliśmy workspace na Postmanie, który prezentował możliwości API OpenAI, Ja sobie taki workspace sforkowałem, następnie podałem tam swoje kluczyki, no to on już z domysłu ten fork był, z automatu był też publiczny. Jeszcze jedna taka rzecz w kontekście Postmana to jest to, że Postman ogranicza ilość osób, które mogą w ramach prywatnego workspace’a jakby współdzielić projekt, więc ludzie, którzy nie chcą płacić po prostu idą na łatwiznę i korzystając z tej darmowej opcji upublicznienia nie będą tak naprawdę świadomym, że gdzieś tam w środku, w tym workspace przekazali jakieś sekrety i polegają tylko tak naprawdę na tym, że jedynym ich zabezpieczeniem jest to, że współdzielą jakiś link do takiego workspace, a tak naprawdę nie wiedzą, że on został przy okazji policzniony. Tutaj w zasadzie bym postawił kropkę, jeżeli chodzi z mojej strony o Postmana. A w zasadzie, tylko jeszcze dodając, ponieważ twórcy Truffle Hogga z firmy Truffle Security wbili troszeczkę szpilkę, No postawa Postmana jest w tym momencie co najmniej dziwna, bo to jest firma wyceniana na 5,6 miliarda dolarów przy ostatniej ewaluacji w 2021 roku.

AndrzejTo jeszcze przed ZIRP-em. W czasach ZIRP-u, bo właśnie.

KrzysztofI oni oczywiście skontaktowali się z Head of Information Security w Postmanie i Postman stwierdził, że oni są świadomi tego problemu. Przy czym nie było to dla nich top priority na backlogu, żeby zająć się tym problemem. No teraz tutaj Truffle Security nagłaszając tą całą akcję i tworząc w ogóle cały feature w swoim produkcie dotyczącym skanowania tych workspaców. jakby niejako troszeczkę ich naciska i mówi, zajmijcie się tym, bo to jest realny problem i skala tego jest na pewno dużo większa niż tylko to, co udało im się znaleźć. Oni to bardzo wyraźnie podkreślają.

AndrzejNo właśnie, czyli znowu niejako dopiero po wykryciu, po tym jak mleko się rozleje, to organizacja, w której mleko się rozlewa, zaczyna podchodzić do tego poważnie. Bo zakładam, że Postman na pewno wbije ten issue, który wcześniej był akceptowany, no trochę wyżej na swoim dashboardzie, w jakimś kanbanie czy w dzizze. Nagle to będzie większy problem. Ale tylko dlatego, że ludzie zaczęli o tym gadać, czyli technicznie dopiero wtedy, kiedy jakaś część tego ryzyka, które wcześniej zakładam sobie jakoś wyliczyli, się zmaterializowała. Jak sam CISO określił, byli świadomi, ale nic z tym nie zrobili. To co mi się podobało, w tym researchu i to też to co powiedziałeś odnośnie UI i UX. Bo to jest bardzo ważny kawałek, który taki trochę Seagway też jest trochę poruszany, no może nie poruszany, Bezpośrednio, ale pośrednio jest poruszany w moim kawałku, o którym będę mówił, Databridge Investigations Report, debirze, gdzie jednak to UI, UX realnie wpływa na bezpieczeństwo użytkowników końcowych. Myślę, że każdy z naszych słuchaczy, może nie każdy, ale duża część z naszych słuchaczy będzie kojarzyła coś takiego jak PGP, GPG. oprogramowanie, które służy do szyfrowania poczty e-mail, do maili, które wysyłamy. To jest świetny przykład dlaczego UI-UX, jeśli nie jest dobrze skrojony pod użytkowników, pod to jak ludzie korzystają z jakiegoś narzędzia, no po prostu będzie, zablokuje adaptację nawet rozwiązania, które faktycznie jest Ma wagę i ma wagę coraz większą w ostatnich dekadach, czyli szyfrowanie naszych wiadomości e-mail, które by default nie są szyfrowane. Było rozwiązane już w latach dziewięćdziesiątych właśnie poprzez PGP-GPG, ale każdy, każdy wie, każdy kto uczestniczył kiedykolwiek w konwersacji wykorzystanie PGP-GPG wie, że prędzej czy później jakaś osoba odpisze, dołączając cały thread, ale nie zaszyfruje te wiadomości, więc automatycznie wszystko idzie w piach. Ale to jest właśnie powód złego UI-UX. Powodem tutaj jest zły UI-UX narzędzia, a nie czynnik ludzki. Problem nie jest człowiek, Jak bezpiecznicy często chcieliby powiedzieć, nie. Problemem jest to, że narzędzie jest toporne w użytkowaniu i narzędzie nie może być toporne, bo jeśli będzie toporne, to ludzie nie będą z niego korzystać. Więc nieważne jak bardzo przydatne jest, po prostu ludzie nie będą z niego korzystać.

KrzysztofTak, dokładnie. Ja też często powtarzam, czy w swoich wypowiedziach, czy postach, że bezpieczeństwo po prostu powinno być proste, jeżeli chcemy, żeby miało właściwą adopcję. i wydaje mi się, że tutaj po prostu tego zabrakło spojrzenia właśnie w kontekście takiego całego user experience, korzystania z tego w kontekście zabezpieczania danych klientów, klientów postmada.

AndrzejDobrze, teraz wskakujemy do mojego kawałka, DEBIR, więc Data Breach Investigations Report. Czym jest? Dwa słowa o samym raporcie. DEBIR to jest raport, który jest tworzony przez Verizona od wielu lat. Ręki sobie nie dam uciąć, bo nie zamontowałem w swoich notatkach, ale wydaje mi się, że jest to 17 wydanie, więc Debir wychodzi co roku, no to jeżeli to jest 17 wydanie, no to już wychodzi 17 lat. Wychodzi w okolicach właśnie maja, czerwca i omawia wycieki danych z zeszłego roku. Próbuje agregować, zbierać te dane i wyciągać z nich wspólne wnioski. I robi to takim naukowym podejściem, wiadomo, na tyle na ile się da. Natomiast są tam faktycznie ludzie od statystyki i od data science. I teraz. Po pierwsze sam dokument, ja polecam każdemu, komu zdolności językowe, tutaj mam na myśli angielski, pozwala, to polecam każdemu poczytanie tego, dlatego że jest pisany bardzo zabawnym językiem, bardzo przyjemnie się to czyta. Przynajmniej ja mam takie poczucie humoru, że można powiedzieć, że się turlam po podłodze jak czytam The Beer co roku, więc są tam niezłe śmieszki w tym Verizonie. Natomiast poza śmieszkami, poza tym jak jest pisany, to jednak dostarcza jako jeden z niewielu raportów, które wychodzą rok co roku i w ogóle jako jeden z niewielu referencji, których można używać, dostarcza faktyczne dane na temat wycieków danych i faktyczne informacje, których możemy używać jako argumentów, do managementu wyższego szczebla, nawet do C-level executives po to, żeby wnioskować o jakiś budżet na security. Pozwala nam pracować na prawdziwych liczbach, a nie tylko na takim. wydaje mi się, że, a to jest bardzo ważne, żeby działać na liczbach. Przykładowo już na samym początku praktycznie rok w rok i ten rok nie jest tutaj niczym wyjątkowym. Jasno autorzy stwierdzają na początku raportu, że większość wycieków danych było powodowane motywem finansowym. Większość tych aktorów, tych atakujących, którzy atakowali sukcesem organizację po to, żeby wyciągnąć dane, robili to po to, żeby zrobić na tym biznes. Traktują to jako biznes, a nie jako coś, co robię for fun. Ale nie tylko to jest ciekawe. Przykładowo dodatkowym ciekawym takim faktem z tych bardzo ogólnych danych statystycznych już na początku, które są rzucane w raporcie jest kawałek odnośnie szpiegostwa. Czemu to mi się rzuca w oczy? zawsze, praktycznie co roku? Dlatego, że prowadząc szkolenia z modelowania zagrożeń, bardzo często spotykam się z takimi odjechanymi modelami zagrożeń. To znaczy ludzie często biorą pod uwagę jakiś fret aktorów atakujących, którzy są totalnie wyssani z palca. Przykładowo rozpatrujemy, że NSA nam się włamie tam na serwer i będzie coś chciało zrobić. NSA nie będzie się włamywała na nasze serwery.

KrzysztofNSA jest na naszych serwerach.

AndrzejDokładnie. Jeśli NSA będzie chciało to zrobić, to i tak to zrobi. Więc możemy to ryzyko kupić. Raczej nas interesują script kiddies, a nie NSA. I w tym raporcie W tym raporcie są wyciągnięte dane na temat ile z tych wycieków danych, do których już doszło, czyli skutecznych, nie incydentów, ale incydentów, które kończyły się wyciekiem danych, ile z nich było powodowane szpiegostem, espionażem. I co prawda jest wzrost z zeszłego roku z 5 do 7, ale w dalszym ciągu jest to tylko 7%, przy czym, przy czym i to jest key factor, bo zaraz coś powinno o 7% całkiem sporo. I taki nie, dlatego że w tych 7% mamy zarówno prawdziwe agencje wywiadowcze, które robią Robią realne ataki, ale mamy też sprzedawców, którzy po prostu wynoszą naszą bazę klientów.

KrzysztofCzyli takie szpiegostwo przemysłowe.

AndrzejJest, w dalszym ciągu jest to szpiegostwo. Jeżeli ja pracuję w firmie X i ja wychodząc z tej firmy, zwalniając się, wezmę sobie roster klientów. no to technicznie jest to szpiegostwo przemysłowe i wpadnie tutaj pod espionaż. Natomiast, no na pewno nie jest to nic z filmu szpiegowskiego. Pomimo tego, że mamy ten keyword espionaż, no to kurczę, jest to takie po prostu dość zwykłe, zwyczajne i myślę, że każdy z nas zdaje sobie sprawę, że są tacy pracownicy, którzy takie rzeczy próbują robić. mniej udolnie, bardziej udolnie, ale generalnie są tacy pracownicy, którzy próbują to robić i myślę, że to jest takie proste do zrozumienia. Natomiast tych szpiegów, którzy atakują firmy, ich jest zdecydowanie mniej i przed nimi się najpewniej i tak nie obronimy. Niejako to jest ich praca, żeby być w tym dobrym. To jest jedna z takich kluczowych metryk, którą wyciągnąłem z tej najnowszej edycji DeBeer. Kolejna, która mnie tak mocno uderzyła, to ile osób klika w maile phishingowe. Tutaj sam DeBeer stwierdza, że w zasadzie Mediana czasu dla użytkownika, żeby stać się ofiarą, po otrzymaniu, po otrzymaniu maila phishingowego, żeby stać się ofiarą, czyli faktycznie kliknąć tego linka i tam wpisać swój login i hasło, to jest mniej niż 60 sekund. Mniej niż minuta.

KrzysztofOd zobaczenia maila, tak?

AndrzejTak, od zobaczenia maila. Czyli dostajesz maila, mniej niż minuta jest kliknięcie i na to jest prowadzenie swoich danych. Ale, i to już jest jakaś moja opinia, czy naprawdę to jest takie straszne? Pytanie, czy to jest takie straszne, że użytkownik, którego praca często gęsto polega na otwieraniu maili, na klikaniu w linki? to czy jest takie straszne, że 60 sekund mija od kliknięcia i że on w ogóle w to kliknie? Bo ja bym argumentował, że nie. To jest w zasadzie często gęsta jego praca. Czytanie maili i klikanie w linki w tych mailach. Ja bym argumentował, że w tych narzędziach mamy zły UI, UX. To jest problem. Nie to, że użytkownik ma poświęcać X czasu na przebadanie, czy ten e-mail jest faktycznie e-mailem phishingowym, bo to jest po prostu nieskuteczne. Jeśli weźmiemy 1000 użytkowników, będzie pewna grupa, która nigdy się tego nie nauczy i zawsze kliknie. Więc zawsze wejdą do tej firmy. I to po prostu wiemy po czasie. Kilka lat temu było dość dobre opracowanie z Google, które jasno powiedziało, że to co zatrzymało phishing w Google to wprowadzenie kluczyków sprzętowych. Nic innego wcześniej nie zatrzymało phishingu. Tylko kluczyki sprzętowe zatrzymały phishing. I tyle. Więc jeśli chcemy skutecznie rozwiązać sprawę phishingu, wprowadźmy kluczyki sprzętowe. A jeśli nie chcemy, to oczywiście ja w dalszym ciągu jestem za budowaniem tej świadomości użytkownika końcowego. Chcemy to robić, natomiast to nie stoi w kontrze z tym, że nie powinniśmy polegać na niej jako bramce, jako elementowi, który ma aktywnie nas bronić przed atakiem phishingowym. Od tego jest bezpieczeństwo, żeby nas broniło. Od tego jest bezpieczeństwo, żeby wyłapał tego maila. A nie od tego, żeby przerzucać winę na użytkownika, że użytkownik kliknął w linka na maszynie, na której czyta się wiadomości i klika w linki. Po to korzystam z komputera, żeby czytać wiadomości i klikać w linki. Więc trudno mnie winić za to, że czytam te wiadomości i klikam w linki. To jest kolejny, kolejny, kolejny wniosek i to właśnie łączy się z tym UI i UX. Tutaj, tutaj powinniśmy to rozwiązywać, a nie polegać na tym, że nasz użytkownik końcowy to będzie jakąś wiedzę, zrozumienie i teraz będzie poświęcał dodatkowy czas, przy czym jeśli chcielibyśmy faktycznie wejść w to tak metodycznie, no to podajmy ile czasu będzie musiał poświęcić na czytanie tych maili w cyklu rocznym. No bo jeśli czytam maila i mam jakąś średnią, ile czytam każdego maila, otrzymuję powiedzmy 100 maili. Każdego maila czytam przez ileś sekund. To ile czasu muszę dołożyć, żeby ocenić czy ten mail jest mailem phishingowym, który próbuje mnie zaatakować, czy normalnym? I teraz zobaczmy, czy ten końcowy koszt ja jako organizacja jestem w stanie zaakceptować. Bo jeśli dona to przykładowo dla moich pracowników dodatkowe x godzin w cyklu tygodniowym, a w cyklu rocznym x set godzin, to pytanie, czy akceptuje ten koszt, czy nie. Pytanie też, jakie będą tzw. unintended consequences, no bo ci użytkownicy też będą zmęczeni czytaniem tych maili. I to są ważne pytania, które należy postawić i się nad nimi zastanowić, a nie tylko ślepo rzucać radami typu, użytkownicy klikają w maile, trzeba zrobić im szkolenie, a jak po szkoleniu kliknie w maila, to najwidoczniej trzeba go jeszcze raz przeszkolić, bo się nie chce nauczyć, ten skurczybyk. Nie tędy droga.

KrzysztofDokładnie. Sprawdźmy, czy dadzą się złapać. Podstawmy im fałszywą domenę.

AndrzejDokładnie.

KrzysztofNie zobaczył. Ah, znowu.

AndrzejAlbo typowa akcja phishingowa. Mamy na przykład grudzień. Każdy wie jak grudzień wygląda w dużych organizacjach. Grudzień nie jest pełnym miesiącem. Często, gęsto zamyka się budżety. Są święta. Ludzie żyją już często, gęsto świętami już na początku grudnia. I wtedy wpada mail o podwyżkach albo premiach związanych z końcem roku. Bardzo łatwo jest się nabrać na takiego maila. Znowu, według mnie nie jest wina po stronie użytkowników, tylko po pierwsze od tego mam bezpieczeństwo, żeby mnie od tego broniło. Od tego są. A dwa, końcem końców, jeśli faktycznie chcielibyśmy rozwiązać ten problem, to kluczyki sprzętowe. Kluczyki sprzętowe, tak jak Google. Google, organizacja, która ma, można powiedzieć, nieskończony budżet, ma dość ogarniętych ludzi, nie potrafiła rozwiązać tego problemu przez wszystkie lata, przez które próbowała. Rozwiązała go dopiero wprowadzając kluczyki sprzętowe. Co, coś nam powinno powiedzieć. Kolejna, kolejna, kolejny wniosek odnośnie, odnośnie Generative AI, wszystkim znanym LLM-ów, o LLM-ach, o generowaniu obrazków i innych tego typu cuda, które na przestrzeni ostatnich dwóch lat powstały i cały czas się rozwijały w zasadzie z tygodnia na tydzień, z miesiąca na miesiąc. Debir też, autorzy Debira też tutaj przyjrzeli się temu wątkowi i zaobserwowali, że na różnych porach w darknecie wcale tak dużo o tym generative AI nie ma. Więc pomimo tego, że można słyszeć takie opinie ekspertów od cyberbezpieczeństwa, że o, o la boga, teraz to będzie. Tak, teraz to cyberprzestępcy już będą generować obrazki, będą pisać maile phishingowe w GPT. W ogóle koszt operacji im spadnie praktycznie do zera. Boże, będzie jeszcze ujemny. Generalnie będzie im płacił za to. Nie. Cyberprzestępcy generalnie, wracamy do punktu pierwszego, są traiowani przez pieniądze, traktują to jako biznes i bezpiecznicy może też powinni patrzeć przez ten pryzmat, czyli przez koszty i przez pieniądze, bo gdyby wzięli przykład cyberprzestępców, to wiedzieliby, że na koniec dnia koszt musi mi się spinać. I jeśli mam rozwiązanie, które działa, przykładowo w tej chwili puszczam kampanie phishingowe, które po prostu już sobie napisałem i one mają stopę zwrotu na zadowalającym poziomie, to ja nie będę szukał innych sposobów, co ja musiałbym teraz zrobić, żeby ta kampania była jeszcze lepsza i zwróciła mi na przykład zwrot o 1% lepszy albo o 2% lepszy. Nie ma to sensu. A koniec dnia liczy się dla mnie kasa? I jeśli kasa się spina, to ja nie będę nic robił, co jest racjonalnym działaniem ekonomicznym każdego człowieka. I cyberprzestępcy też są ludźmi i nie korzystają z tych narzędzi generatyw AI. Na tych forach darknetowych generatyw AI generalnie nie jest tematem, który jest za często poruszany, w zasadzie w ogóle. A tam gdzie jest poruszany, to najczęściej jest poruszany w kontekście tego, że ktoś wykradł loginy i hasła do tych serwisów, takich jak właśnie chat GPT, czy cloud, czy perplexity, czy generalnie innych tego typu rozwiązań. I w tym kontekście jest wspomniany Generative AI, a nie w kontekście jak możemy użyć tych narzędzi po to, żeby nasze kampanie phishingowe miały ładniejsze obrazki. to się po prostu nie spina pod kątem tego, co chcemy osiągnąć. A znowu, na koniec dnia cyberprzestępcy chcą osiągnąć stopę zwrotu. Traktują to jako biznes. Liczy się dla nich pieniądz. Wkładam tyle, wyciągam… Wkładam X, wyciągam Y i jeśli jestem zadowolony z Y, to w zasadzie wolę siedzieć sobie na swoim jachcie z modelkami, pić szampana i wygrzewać się na słońcu, a nie myśleć, jak mogę zwiększyć stopę zwrotu o jakieś Z. a przynajmniej to Z to musiało być bardzo, bardzo dużo większe po to, żebym ja się pofatygował. I ostatnią ze statystyk, którą wyciągnąłem, raport oczywiście zawiera dużo więcej statystyk, jedną z takich statystyk, która jest warta rzucenia okiem, szczególnie już tak mocno kontekstowo, więc ja jej nie będę omawiał, natomiast debir, Omawia też liczby i statystyki per konkretne wertykale, więc przykładowo jeśli działamy w finansach i ubezpieczeniach, to możemy zobaczyć jak wyglądały wycieki danych dla tego rynku, dla tego wertykalu. I tych wertykali jest więcej, więc można wyciągać te dane, budować sobie jakiś obraz jak to wygląda, ale na podstawie konkretnych, konkretnych branż. A tą statystyką, którą ja, o której ja chcę pobieżnie jeszcze powiedzieć, to statystyka, która mówi co jest obecnie najczęściej hakowane. i najczęściej hakowane. tym pierwszym wektorem wejścia najczęściej jest w dalszym ciągu web aplikacja. Więc web aplikacje najczęściej są hakowane, tak atakujący się dostają, przy czym w samych web aplikacjach najczęściej w dalszym ciągu jest wykorzystywany Credential Stuffing. Atak Credential Stuffing, który bardzo często jak się testuje to jest, można go przeprowadzić dla większości aplikacji, bo jest trudny do obrony. Natomiast tym key takeaway dla mnie z tej sekcji było to, że w dalszym ciągu te web aplikacje są mocno na górze. W zasadzie nic innego nie podchodzi. Tam jest kilka innych dodatkowych wejść, takie jak np. atakowanie aplikacji, które służą do administracji, do remote screen sharing, czy atakowanie VPN-ów, ale web aplikacje tutaj wiodą Prym i myślę, że nikogo w security ani może szczerze nawet w IT to nie dziwi. No jednak świat web aplikacjami stoi.

KrzysztofTak, tak. Ja powiem tylko ze swojego doświadczenia, że jeżeli chodzi o Credential Staffing, jako osobę, która broni aktywnie w dosyć dużym projekcie aplikację, Uwierzcie mi, bądź nie, to jest najczęstszy atak, który jest przeprowadzany po prostu na aplikację, którą się zajmuje. nie SQL injection, nie próby wstrzykiwania czegokolwiek, tylko bardzo duże wolumeny requestów na endpoint odlogowania. I obrona przed tym jest cholernie ciężka. Trzeba zacząć od podstaw i edukacji użytkowników w takim bardzo aktywnym działaniu, gdzie faktycznie pokazujemy im, jednocześnie ograniczając tarcie na przykład na rejestracji. W jaki sposób ułożyć fajne hasło, które będzie na tyle unikalne, że zabezpieczy ich przed tym Credential Stuffingiem.

AndrzejTutaj chciałbym jeszcze dodać, że z doświadczenia również wiem, że zespoły, które testują, które walidują ofensywnie web-aplikacje, bardzo rzadko testują web-aplikacje pod kątem ataku credential staffing. Więc tutaj już mamy dość duży mismatch pomiędzy tym, jakie dane możemy wyciągnąć z realnych ataków, które prowadzą do incydentów danych. Czyli coś, co powinno być fundamentem rozmowy i dyskusji o bezpieczeństwie i obronie organizacji, jaki to jest mismatch pomiędzy tym, co potem jest na rynku realnie weryfikowane.

KrzysztofOczywiście, oczywiście, oczywiście. Tak, Debil oczywiście polecamy, podlinkujemy w opisie. Ja bym chciał tylko dodać, co tutaj nie padło, że Debil jest podzielony na różne kategorie w kontekście vertikali, w jakich pracujecie, więc tam jest i Healthcare, jest bodajże e-commerce, są usługi IT, więc dla tych konkretnych dziedzin gospodarki można sobie przejrzeć jak wyglądają te zagrożenia. Jest też oczywiście zestawienie całościowe, o którym Padło, padło.

AndrzejWtedy mówiłem o tym wertykalu finansowym i na przykład ubezpieczeniach. Ale dobrze, że to wytłumaczyłeś, bo to jest naprawdę ważna uwaga odnośnie De Beera, że nie tylko możemy popatrzeć na ten ogólny obraz, ale jeszcze pracując w jakimś konkretnym obszarze rynku możemy zrobić zoom in, double click. I możemy zobaczyć jak to wygląda dla konkretnie np. naszej branży. To jest mega wartościowe. Szczególnie jeśli z punktu widzenia bezpieczeństwa np. menadżera bezpieczeństwa albo nawet dyrektora mamy rozmawiać z kimś wyższego szczebla operacyjnych organizacji. To jest mega ważne żebyśmy mieli coś na czym możemy oprzeć naszą dyskusję.

KrzysztofDokładnie, dokładnie. Okej, no to wskakujemy w kolejny temat. tym Razem chciałem Wam przedstawić, razem z Andrzejem, problem dependency confusion. To jest problem, który tak naprawdę nie wypływa dopiero teraz. Sam atak dependency confusion został szeroko opisany w 2021 roku i researcher, który opisywał atak dependency confusion zgarnął na tym niemałą kwotę, bo w zasadzie odkrył ten problem w kilku dużych organizacjach takich jak Microsoft, Stripe, Paypal, Slack. Tam można by było jeszcze wymienić kilka dużych brandów, które były zaafektowane tym problemem. I opisał to bardzo dobrze. I to pamiętam wtedy, że to było takie wow, bo prostota tego, o czym zaraz powiem, pewnie samych słuchaczy zaskoczy. O Dependency & Confusion przypomniałem sobie niejako poprzez artykuł, który czytałem, że ktoś postanowił sprawdzić jak ten stan tak naprawdę wygląda obecnie. I w dużym skrócie na czym polega Dependency & Confusion. Myślę, że wszyscy, którzy aktywnie uczestniczą w procesie developmentu wiedzą, że nie da się tak naprawdę zbudować, bo bardzo ciężko jest zbudować aplikację bez wykorzystania open source’owych bibliotek, paczek i tak dalej. Jednym z takich repozytoriów jest, weźmy tutaj mojego ulubionego NPM-a. I jeżeli chcemy sobie jakąś paczkę korzystając właśnie w ekosystemie javascriptowym w Node’zie zainstalować, no to robimy, jeżeli naszym klientem do instalacji paczek jest NPM, no to robimy NPM install i podajemy nazwę paczki, chyba, że korzystamy z Jarna, no to dodajemy nazwę, nazwę paczki. I teraz tak, mamy dwa rodzaje rejestrów paczek, publiczne i prywatne. No publiczne chyba każdy zna, no bo to jest tam, gdzie najczęściej szukamy paczki, która ma rozwiązać nasz jakiś dany problem, żebyśmy nie musieli tego pisać na nowo. No ale są też prywatne rejestry takich paczek, już często, gęsto używane w dużych organizacjach, które rozwiązują jakieś kawałki problemów u siebie i nie chcą się dzielić taką paczką na zewnątrz, więc utrzymają takie prywatne rejestry po swojej stronie. I atak dependency confusion polega na tym, że Dzieje się dziwna kwestia w takiej materii, kiedy pojawia się w publicznym rejestrze taka sama paczka, jak w prywatnym rejestrze. Czyli powiedzmy mamy paczkę w prywatnym rejestrze, która nazywa się PU. I teraz założymy takim sam pakiet powiedzmy w NPM, który też się będzie nazywał Fu. I teraz jak zachowa się klient NPM, który będzie taką paczkę instalował. I otóż okazuje się, że jeżeli w publicznym rejestrze zgodnie z wersjonowaniem semantycznym, który jest definiowany akurat jeżeli chodzi o JavaScript w package.json, pojawi się nowsza paczka w publicznym rejestrze, no to zostanie ona zaciągnięta z publicznego rejestru. I właśnie w taki sposób researcherzy wpadli na to, że ej, Może zaczniemy skrapować publiczne repozytoria tych dużych, dużych firm i sprawdźmy jakie oni tam paczki tak naprawdę sobie listują w tych swoich, swoich zależnościach. I jeżeli się okaże, że te paczki tak naprawdę nie są w publicznych, w publicznych rejestrach dostępne, to znaczy, że muszą być dostępne w tych prywatnych rejestrach. Więc atakujący zaczęli wypuszczać paczki pod takimi samymi nazwami do publicznych rejestrów. I tak naprawdę tutaj jeżeli chodzi o całą akcję tego hakowania to tam za wiele się nie działo, bo na potrzeby Proof of Concept te paczki jedyne co robiły to w trakcie instalacji wysyłały informacje kurlem, że udało się odpalić na takim hoście z takiego użytkownika i jakaś tam taka bardzo minimalna wiedza na temat tego kontekstu w jakim się udało to uruchomić. A ten artykuł, o którym tutaj mówiłem, który przypomniał mi taką dependency confusion, wykorzystał jeszcze jedną bardzo fajną, jedną bardzo fajną, taki trick odkrywania asetów poprzez Wayback Machine, czyli można było cofnąć się w historii internetu o kilka lat i zobaczyć jak dana, dana strona internetowa i jej asety wyglądały, wyglądały wstercz. Więc nawet jeżeli ktoś po ataku, po tym researchu z 2021 roku po prostu usunął swoje asety, bo np. przez przypadek udostępnił pakiet JSON na swojej stronie, no to można było się przez Wayback Machine cofnąć w czasie, pobrać sobie ten pakiet JSON, i sprawdzić czy organizacje rozwiązały ten problem, a rozwiązanie tego problemu jest tak naprawdę banalnie proste, bo można zrobić teraz tak na szybko myśląc dwie rzeczy. Jeżeli jesteście organizacją, która korzysta z prywatnych rejestrów, no to po prostu zarejestrujcie w publicznych rejestrach paczki o takiej samej nazwie i problem solved. Nawet te paczki To paczki mogą być puste, mogą nic nie robić, chodzi tylko o zajęcie nazwy. Albo jeżeli jesteście dużą, poważną organizacją, no to po prostu zarejestrujcie sobie namespace i wtedy wasze paczki będą nazywały się na przykład w taki sposób, małpa.paypal.com.pl i nikt kto nie jest w naszym waszym namespace nie będzie mógł pchać od wasz namespace po prostu nowe paczki do publicznych repozytorii.

AndrzejAle w tym przypadku podoba mi się coś, bo zauważ, że to jest pewne nawiązanie do czegoś, co już kilka razy podkreślaliśmy w tym podcaście, czyli do tego, że często w security, ja to znam z doświadczenia, jest tak, że nie trzeba mieć jakichś super oryginalnych pomysłów na research. Wystarczy po prostu popatrzeć wstecz. i albo pomyśleć i odtworzyć jakąś wariację jakiegoś researchu i po prostu na podstawie tego co już kiedyś było w jakiejś technologii spróbować danego ataku w jakiejś innej technologii albo tak jak tutaj po prostu sprawdzić czy w dalszym ciągu ten problem istnieje. Nazwijmy to toćka w toćkę. Oczywiście tutaj doszedł ten nowy motyw odnośnie szukania w Wayback Machine. Ale te nazwy moglibyśmy tak naprawdę próbować przewidywać. Na koniec dnia była to rewalidacja tego stanu, tej podatności w tych organizacjach i to się zmieniło pomiędzy stanem z 2021 i ze stanem, który mamy obecnie, czyli 2024. I tutaj mała prywatna historia, ja też miałem takie przypadki, gdzie i to było więcej niż jeden takich przypadków, gdzie poprzez sprawdzanie starszych plików, które reprodukowały pewne podatności w przeglądarkach, w momencie jak kiedyś, dawno temu szukałem podatności w przeglądarkach, to biorąc pliki, które reprodukują, w dalszym ciągu reprodukowały, albo reprodukowały się na innej platformie. Nie reprodukowały się na przykład na Safari pod Windowsem, ale reprodukowały się na Safari pod macOSem. Lub na odwrót. Pod macOSem się nie reprodukowały, a na tej wersji Windowsowej, teraz to już chyba nawet nie ma, ale lata temu jak to robiłem, to była, to się reprodukowały. Albo na przykład to jest jeden przypadek, gdzie pewnie nie wyprowadzili tego problemu dla jednej platformy, a wyprowadzili dla drugiej. A miałem też takie przypadki, gdzie clearly po prostu testy regresyjne zawiodły i dana podatność była raz jeszcze wprowadzona do danego kawałka oprogramowania. Czyli można było wziąć coś, co reprodukuje, co faktycznie było realną podatnością i co można było wyeksploatować, ale niestety ta podatność była wyprowadzona, potem znowu wprowadzona, a maintainerzy tego projektu tego nie wyłapali. Więc nawet w takich mocno… Nawet w takich sytuacjach, gdzie technicznie można byłoby założyć, że są jakieś automaty, które to weryfikują, jeżeli mówimy o testach regresyjnych, albo że vendor raczej jest tak duży, że poprawił to systemowo, a nie tylko dla jednego kawałka aplikacji, można odkryć tego typu problemy, więc jeśli nie mamy jakiegoś pomysłu, nie wiemy co zrobić, to cofnijmy się kilka lat, zróbmy sobie listę takich researchy i po prostu przejdźmy przez każdy z nich i zobaczmy, jak sytuacja wygląda w tym punkcie czasu względem tego, co było i opiszmy to na blogu, nawet jeśli nic nie znajdziemy. I tak będzie to i dla nas wartość, i dla innych wartość. Jest bardzo dużo wartości w takiej pracy, nawet jeśli nie do końca otrzymamy efekty, które chcieliśmy.

KrzysztofTak, tutaj jeszcze w podsumowaniu bardzo ciekawa historia. Ta osoba, która opisywała to Dependency Confusion w takim nowym świetle, oświeżonym, mówi, że ostatnio była na jednej z dużych konferencji, nie wiem czy to było RSA czy coś. Pewnie RSA. Tak i mówi, że na jednym ze stanowisk pewien pan oferował mu nawet swoją usługę, która rozwiązywała ten problem, swój produkt, który rozwiązuje problem Dependency Confusion, na czym on skwitował go chłopie, ale Co ty mi tutaj chcesz sprzedać? Wystarczy zarejestrować paczkę pod tą samą nazwą w publicznym rejestrze. Tak samo jak robią te atakujące. O co tu chodzi?

AndrzejJa nie wiem, ale się domyślam z jakiego kraju mógłbyś ten sprzedawca. Z dwóch. Mam dwa typy, ale nie będę tutaj ich wymieniał. Natomiast biznes trzeba umieć robić.

KrzysztofDokładnie.

AndrzejWięc da się zrobić biznes i startupy nawet wokół tak tak trywialnych do rozwiązania problemów jak jak DPNS i Confusion. Krzysiek, czas nam się kończy. Ja wskoczę szybko w ten jeden item, który mi został. Twój pominiemy. Zostanie na przyszłość, jeśli nie wpadnie nic ciekawszego. Natomiast naprawdę bardzo szybko chciałbym przelecieć przez dramę, która ostatnio była w Slacku. Głównie dlatego, żeby tutaj zwrócić uwagę na pewne, na pewien główny takeaway, który powinien zostać z niej wyniesiony. Mianowicie, ostatnio w Slacku Pojawiła się, może nie w Slacku, to na Twitterze, przepraszam, na X, pojawiła się dyskusja, gdzie taki znany inżynier Jergelly Orosz, który prowadzi również bardzo znany i dobry newsletter dla inżynierów, poruszył kwestię prywatności związanej z AI w Slacku, mianowicie rzekomo Slack tak zmienił swoje terms of services, że dane użytkowników, przez dane użytkowników mam tu na myśli wiadomości, ale nie tylko wiadomości prywatne na czatach, ale też DM-ki, generalnie wszystko co tam wlatuje do Slacka mogłoby być używane do trenowania LLM-ów wewnątrz Slacka. To już samo z siebie jest ciekawe. Natomiast na koniec dnia, jak trochę się wgłębiłem w tą sprawę, to wyszło, że to trochę taki pizz na wodę, no montaż, taka, może nie false flag, ale…

KrzysztofBicie pijany?

AndrzejBicie pijany, fałszywy alarm. Nie do końca, nie do końca, nie do końca wynikało to, co rzekomo miało wynikać z tego, co było tak naprawdę napisane na stronie Slacka. Ale to co jest tutaj ważne i to co należałoby wynieść to to, że niepoprawne komunikaty i w takiej oficjalnej komunikacji, czyli w jakichś politykach prywatności i innych, które publikujemy jako organizacja, ale też w materiach marketingowych powinny być pisane w ten sposób, żeby użytkownik końcowy je dobrze rozumiał i żeby nie było za dużego pola na dyskusję. I jest to szczególnie ważne, jest to szczególnie ważne właśnie teraz w dobie AI, gdzie firmy prześcigają się z implementacją tych wszystkich feature związanych z AI, z LLM-ami, No bo jak widać może z tego wyniknąć bardzo duża drama, bo ta drama była naprawdę bardzo duża w internecie, oczywiście tam relatywnie co do świata. Natomiast w świadku IT, szczególnie w tej amerykańskiej części, sprawa była dość głośna, a wynikała z tego, że po prostu komunikacja była niejasna ze strony Slacka. i mogłaby być jaśniejsza lub pozostawiać mniej pola do dyskusji. I to jest tym głównym wątkiem. Jeśli wasze organizacje myślą nad wdrażaniem rozwiązań opartych o lmy, o uczenie się na danych użytkowników, to ta komunikacja musi być super, super, super transparentna i nie powinna pozostawiać cienia wątpliwości, co zostanie robione, jak zostanie to robione, kiedy, generalnie nie powinna pozostawiać cienia wątpliwości odnośnie tego, co faktycznie robimy z tymi danymi.

KrzysztofTak, ja to też obserwuję u swoich klientów, z którymi współpracuję, że z kolei ich klienci wykazują dosyć duże zainteresowanie tym, co potem z tymi danymi, które oni udostępniają tym projektom, z którymi współpracują, co z tymi danymi się dzieje. To jest bardzo często taka obawa, którą można właśnie fajnie rozwiązać jasnym, czystym komunikatem. Dużo dzisiaj w tym odcinku, Andrzej, było o takich niejasnościach. niejasności w postmanie, niejasności związane z zależnościami, niejasności związane z tym, w jaki sposób Slack komunikuje swoje termsy.

AndrzejNiejasność z UI, UX. Tak, było faktycznie, to jest ciekawa uwaga i to też jest takim dobrym Momentem, żeby powiedzieć, że jednak komunikacja jest ważna i w momencie, kiedy mamy pewne niejasności, to te problemy związane z bezpieczeństwem często gęsto wynikają z niejasności. z tego, że coś się dzieje, a nie powinno się wydarzyć, albo w sumie ktoś nie pomyślał, co powinno się wydarzyć, więc mamy jakiś unintended effect, na przykład problemy z pamięcią, z obsługą pamięci w językach niskopoziomowych. C jest od tego pełne. CC++ aplikacje, gdzie kompilator pozostawia wiele Wiele rzeczy do interpretacji jest pozostawianych względem dla kompilatora. Czyli język nie mówi, nie ma zdefiniowanego, co ma się zrobić, to kompilator sobie definiuje. I te niejasności są super ważne. Jeśli żylibyśmy w idealnym świecie, to tych niejasności by nie było i wtedy na pewno nie mielibyśmy tak dużo problemów z bezpieczeństwem. Pewnie jakieś by były, ale byłoby ich dużo mniej.

KrzysztofZdecydowanie. A jeżeli dla Was było coś niejasne w tym odcinku, to zapraszamy do komentarzy. Bardzo chętnie służymy naszą odpowiedzią. No i pozostaje nam się pożegnać. Dziękujemy Was za Wasz czas spędzony z nami. Dzięki Andrzej.

AndrzejDzięki Krzysiek i dzięki do wszystkich słuchaczy.

KrzysztofTrzymajcie się. Do zobaczenia. Hej!

Newsletter

Damy Ci znać, gdy opublikujemy coś nowego.

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

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

Referencje i wzmianki: Postman; Truffle Security i TruffleHog; OpenAI; OWASP ZAP; The Hack Summit; Verizon Data Breach Investigations Report (DBIR); klucze sprzętowe (badania Google nad phishingiem); credential stuffing; dependency confusion; npm, Yarn, package.json, semantyczne wersjonowanie; Wayback Machine; PGP/GPG; Slack a trenowanie modeli AI. Rozmowa nagrana w ramach podcastu Bezpieczny Kod.