 Witamy na polskie tłumaczeniu, wykładu praktyczne ataki na cash przez sieć i słuchary o kotach, wprowadzonego przez Majka La Kurta. Na żywo z 36. ok. jest Communication Congress w Lipsku. Wszystkie wykłady są tłumaczone na żywo pomiędzy językiem angielskim i niemieckim oraz na jeden dodatkowy język. Więcej informacji oraz instrukcji, jak uzyskać dostęp do tłumaczenia, znajdziecie na c3lingo.org. Będziemy wdzięczni za informację zwrotną. Przecieżśmy użycie hashtaga c3t. Dzisiaj tłumaczą Paweł i Jila. Witam wszystkich i dziękuję za przyjście. Nazywam się Majka i chciałbym Wam pokazać jakie badania zrobiłem podczas mojej pracy magisterskiej. Robiłem magisterkę na Politechnice Federalnej w Cureku i pisałem pracę w Amsterdamie. Teraz jestem analitykiem bezpieczeństwa. To są ludzie, dzięki którym to wszystko było możliwe. To jest mój opiekun naukowej, moi koledzy, którzy mnie wspierali i pomogli mi przy tej pracy naukowej. Zacznijmy od ataków na Kesh. Wcześniej na ataki na Kesh były znane jako ataki lokalne wykonania kodu. Na przykład po lewej stronie mamy dwie maszyny wirtualne, które mają współdzielony sprzęt. Także używają tego samego procesora i Keshu, dlatego jeżeli atakujący kontroluje drugą maszynę, to może zaatakować maszynę pierwszą poprzez atak na Kesh. Podobnie z Javascriptem. Jeżeli atakujący wykonuje jakieś Javascript na naszej przeglądorce i współdzieli zasoby z innymi programami, to może zaatakować inny proces. Javascript przywodzi nam jakiś atak zdalny, ale ciągle musi być wykonany na naszej maszynie. Chcieliśmy to pociągnąć trochę dalej i mieć prawdziwy atak na Kesh poprzez sieć. Wyobraźmy sobie układ, kiedy klient loguje się na serwer przez SSH i mamy trzecią maszynę, którą kontroluje atakujący. Tak jak widzieliśmy wcześniej dzisiaj, możemy w jakiś sposób dobrać się do tego połączenia. Nie możemy dobrać się bez wykonania żadnego kodu na kliencie, ani na serwerze. Oprócz tego procesor na serwerze nie jest w żaden sposób zamieszany w ten atak. Przyjrzyjmy się bliżej. Mamy takiego kota, który woguje się przez SSH. I za każdym razem, kiedy kot naciska przejście, wysyłamy jeden pakiet. To zawsze działa, jeżeli sesja jest interaktywna. Zobaczmy, co dzieje się na serwerze. Widzimy, że te pakiety trafiają do last level cache, czyli cache ostatniego poziomu. W tym czasie atakujący może również przypuścić jakiś atak przez wysyłanie pakietów przez sieć. W ten sposób możemy zbadać, jakie są czasy przychodzenia po innych pakietach. Możecie się zastanawiać, w jaki sposób to pomoże nam złamać połówność. To dlatego, że ludzie, kiedy piszą na klawiaturze, to robią to w określonych wzorcach. Np. tutaj ma użytkownika, który pisze słowo Bikos. Widzimy, że napisanie E po B jest trochę szybsze niż nacięcie C po E. No i możemy to uogólnić. Możemy zrobić analizę statystyczną. Jeżeli w tych pomarańczowych kropkach możemy dokonać tej rekonstrukcji, jeżeli możemy zrekonstruować dokładne czasy, to wtedy możemy zrobić analizę statystyczną i zrobić analizę statystyczną. No i dzięki temu możemy dostać się do tego, kto napisał w swojej całkowicie prywatnej sesji. No i to brzmi ich bardzo futurystycznie, ale zaraz pokażę, na czym to polega. Muszę tu tutaj powiedzieć jednej rzeczy. Tradycyjnie nasz szartek musi dostać nazwa. No i jeżeli pracowiecie z bezpiecznością, to wiecie, o czym mówimy, dlatego, że nazwałem swój artykuł netcat. No i oczywiście to był żart, dlatego, że netcat oznacza network cash attack. No, ale tak jak to bywa z humorem, może się nie udać. No i nam się bardzo nie udało. No i wywołało to małą burzę na Twitterze tego września. No i mamy tutaj na przykład tweet od J.K. No i tak, to na to wygląda, że to ja jestem tym idiotą. No to naprawmy to. Intel przyjął nasze zgłoszenie i przyznał nam nagrodę i dał nam numer CVE. Więc możemy po prostu użyć tego numeru. Podczas tej dramy na Twitterze dostaliśmy również alternatywną nazwę od kogoś. Niokat. No w każdy razie nauczyliśmy się czegoś na temat tej nazwy, więc przejdźmy dalej. No więc wróćmy do tej najbardziej interesującej rzeczy naszego badania. Najpierw będę mówił o głównie o atakach na cash i DDIO i RDMAT, które są głównymi technologiami. Potem powiem o samym ataku i w jakiś sposób zaatakowaliśmy DDIO. Będzie też pokazana mała demonstracja. Ataki na cash polegają na obejrzeniu stanu micro-architektuły, które normalnie powinien być ukryte. I robimy to w ten sposób, że używamy współdzielonych zasobów, żeby dostać się do jakiejś informacji. Trochę przypomina to włamywanie się do sejfu z użyciem status copu. Tak jak z użyciem status copu możemy odsłuchać dźwięków, tak samo tutaj z komputerami. Tutaj patrzymy na cash. Cash rozwiązuje problem, że zwykle kiedy problem opóźnienia dostępu do pamięci. Cash wykorzystują to, że dane są lokalnie rozmieszczone w przestrzeni. Zwykle procesory mają trzy poziomy cashów. Jest poziom pierwszy, oddzielne cash na dane i instrukcje, potem L2 i potem L3, które jest używane przez wszystkie rdlenie. Jeżeli dane, których używasz w cash to je po prostu bierzemy. Jeżeli nie, to muszą być wyciągnięte z pamięci i nazywamy je to hybieniem. Skąd wiemy, że mamy trafienie albo hybienie? Nie możemy po prostu przeczytać danych z casha. Możemy użyć techniki jej zwanej prime pro, czyli rozruch i sonda. Co dokładnie się dzieje? Pierwszy krok to jest, że staramy się, żeby cash był w jakimś znanym stanie. Znaczy dokonujemy takiego rozdruku tego cashu, wypełniamy go naszymi danymi. Potem czekamy, aż ofiara użyje casha. No i na końcu sądujemy. Czyli znowu robimy rozruch, ale tym razem mierzymy dostęp. Szybki dostęp oznacza, że mamy trafienie w cashu, albo że nie używ casha. A hybienie oznacza, że ofiara używa jednej z dzienników casha pomiędzy rozruchem asonu. Co możemy zrobić z tymi trafiniami i hybieniami? Możemy je analizować. Te informacje na temat czasu oznaczają, że wiemy coś o zachowaniu programów i rzutkowników. Patrząc tylko na to, możemy wydostać klucze do szyfrowania, sprawdzić na jakie strony ktoś wszedł, albo zobaczyć, co było w pamięci, to jest spektryzm Meltdown. Zobaczam więc, w jaki sposób możemy wykonać taki atak przez sieć. Najpierw chcę opowiedzieć o DMA. Direct Memory Access jest atakiem umożliwiającym bezpośredni dostęp do pamięci. Kiedy dostaniemy pakiet, możemy po prostu pojawiać się w naszej głównej pamięci i możemy go wyciągnąć w tej pamięci. DDIO, czyli Data Direct Aerotechnology, mamy trochę inaczej, dlaczego urządzenie PC i może po prostu bezpośrednio dać nam informacje. Dzięki temu aplikacja nie musi przechodzić przez główną pamięć i może bezpośrednio wyciągnąć dane z kasza ostatniego poziomu. DDIO oznacza Data Direct Aerotechnology, czyli bezpośredni dostęp do danych i działa na wszystkich procesorach Intel'a od 2012, działa w sposób przezroczysty dla sterowników i dla systemu operacyjnego. Więc większość osób nie, nawet nie zauważa, że coś się zmieniło, ale zmienia się dość drastycznie. Po co nam to jest, dlaczego nam to jest potrzebne? Skodzi o wydajność. Tutaj mamy ładny wykaz z Intel'a, który pokazuje, jaka jest różnica w dostępach. Patrzymy tutaj na 2,4,6 urządzeń i widzimy, że bez DDIO nie potrafimy skalować dalej roku, ale na jasno niebiesko widzimy, że dalej możemy skalować, kiedy dodamy do więcej urządzeń sieciowych. Więc DDIO służy do skalowania aplikacji sieciowych. Druga technologia, której nadużyjemy to RDMA, czyli zdalny DMA, zdalny bezpośredni dostęp do pamięci, możemy za jego pomocą ominąć skarnę i przenieść łatwę transportu do krzemu. To znaczy, że możemy dostać się do pamięci na zalej maszynie bez użycia przerwań. Tak wygląda te użycie. Na lewej mamy serwy hensujące, a po prawej mamy docelowe. Na początku alokujmy pamięć, no i aplikacja może przenieść dane bez użycia całego czerwego stosu kernela. Czasem serwy hensujący może dostać się w dowolne miejsce tej pamięci. Cytując jedno z firm, dane z pamięci nie będą więcej pojawiać się w kaszach, no ale z DDIO to nie jest prawda i to właśnie wykorzystamy. No możecie się pytać, gdzie używamy tego RDMA? No i to jest jedna z technologii, o których zwykle się nie słyszę. Ale używa się zwykle w wielkich centrum danych i w chmurach. Możemy to znaleźć na wielkich chmurach jak Azure i małych jak Huawei, czy Alibaba, no i różnie w protokołach takich jak SMB albo NFS. Inne wykorzystania to jest high performance computing, big data, machine learning i takie różne. No ale przyjrzyjmy się naszym badaniom. Mamy współdzielone zasoby widoczne przez sieć, DDIO i możemy czytać i pisać prymityczne wartości przez sieć. Czy możemy rozpracować jak działa DDIO? Czy możemy rozróżnić odczyty z pamięci, z odczytami z kaszu i czy możemy dostać się do pełnej zawartości niskopoziomowego kaszu? Właściwe pytanie brzmi. Czy możemy tak naprawdę dostać się do samego niskopoziomowego kaszu? Możemy odpowiedzieć na pierwsze pytanie o odczytach z pamięci lub kasza, patrząc na opóźnienie obu odczytów. Jak widać, robiąc to wiele, wiele razy, można wyraźnie zobaczyć, że rozkład obu obu później się różni. Pomorańczowy wykres przedstawia odczyty z kasza a niebieski z pamięci. Można także zobaczyć efekt zdalnego dostępu przez sieć. Niektóre pakiety zostały przesłane znacznie wolniej wpływając na opóźnienia w obu przypadkach. Ale musimy zawsze odpowiednio rozpoznać to, ponieważ bezpośrednim DMA zapisy nigdy nie pojawiają się. Czy możemy mieć dostęp do pełnej zawartości niskopoziomowego kasza? Niestety nie. DDIO ma dodatkowe ograniczenie dostępu do kasza. W ten sposób mamy dostęp tylko do 10% aktywności w kaszu na ostatnim poziomie. Do naszego pierwszego atakowania to jest to, że nie jest to, to jest to, że nie jest to, to jest to, że nie jest to, to jest to, że nie jest to, to jest to, że nie jest to, że nie jest to, do naszego pierwszego ataku to nie zadziała być dobrze, ale doprawiedliwość jest taka, że inne urządzenia PCIe będą używać tych samych, tych samych dwóch linii w kaszu no i na to mamy 100% widoczność. Możemy patrzeć na inne urządzenia poprzez kasz. No, zobaczymy jak wygląda atak kompleksowy. Tak jak powiedziała wcześniej, mamy taki układ, w którym jest klient i serwer i mamy maszynę, którą kontroli atakujący. Klient wysyła pakiet przez zwykłą kartę sieciową i serwer ma drugą kartę sieciową i przez tę kartę atakujący może wykonywać operacje. No i wiemy, że pakiety to są kolejne nacisnięcia klawisze, które wykonuje klient no i to aktywuje niskopoziomowy kacz. Ale w jakiś sposób możemy się dostać do tych dokładnych czasów dostania pakietów. Popatrzmy trochę bliżej, w jakiś sposób to działa. Więc Stos ma bufor pieścieniowy, który pozwala na komunikację asynchroniczną pomiędzy kartą sieciową i procesorem. Tak że jeżeli pakiet przejdzie, no to alokujemy go na pierwszej pozycji bufora. Tutaj widziemy, co widzi atakujący. No i widzimy tylko, że linia na pierwszej pozycji jest użyta. Nie wiemy, które linie się łaktywnią, no ale możemy zobaczyć, co się dzieje z drugim pakietem. No i tym razem uaktywnisz się innia linia Kessha. I jeżeli powtórzymy to dla trzeciego i czwartego pakietu, widzimy, że mamy taki schodkowy wzorek. Mamy teraz przewidywalny wzorzec, który pozwala nam dostać informacje, kiedy dostaliśmy pakietę. To jest przez to, że taki bufor jest zaalokowany w taki sposób, że nie wyrzuca innych części siebie z Kessha, nie wyrzuca siebie z Kessha. To jest dobry również dla atakującego, dlatego że można łatwo to przeanalizować. No popatrzmy na prawdziwy przekład. To jest aktywność Kessha, kiedy serwer cały czas dostaje pakiety. No i widzimy tutaj bardzo ładne schodki. Widzimy też, że bufor używa miejsc w pamięci, jako właśnie takie koło. Nie mamy dostępu do samej treści, tylko do miejsc w pamięci. Niestety, kiedy użytkownik pisze rzeczy przez Kessha, to wzorzec nie wygląda tak ładnie, no bo wtedy już nasza praca byłby skończona. Będzie mieli więcej opóźnienia pomiędzy pakietami, no i nie wiemy, kiedy użytkownik coś nacistnie. Musimy analizować cały czas, żeby wiedzieć, co się dzieje. Mamy dwa etapy. Najpierw podczas ataku patrzymy na linie Kessha, na który możemy patrzeć przez cały czas. Kiedy widzimy, że odpowiednie linie były aktywowane, to wtedy przesuwamy nasze okno na następne pozycje w pamięci, gdzie sądzimy, że będzie aktywowana. Do tego, że musimy to robić bardzo szybko, znacznie szybciej niż przyjdą następne pakiety. Nalewo widzimy, w jaki sposób ta część działa, czyli widzimy to okno na czerwono, i jeżeli przyjedzicie się z bliska, to zobaczycie, że w środku rozświetla się to murka, która odpowiada odpowiedniom pakietowi z pamięci. No, widzimy to, że jest dużo szumów tych danych. Nie możemy po prostu dostać tego czasu. Do tego potrzebujemy drugiego etapu, czyli ekstraakcji danych. Ekstraaktor będzie znajdował najbardziej prawdopodobny czas przesłania pakietu. Używamy to, wykorzystyjemy informacje z pierwszego etapu i dane na temat tego, jak mogą wyglądać różne słowa. No więc znowu mamy czas do stanie pakietów, ale nie mamy jeszcze słów, a potrzebujemy słów, żeby złamać prywatność naszego połączenia. Ale tak jak powiedziałem wcześniej, ludzie zwykle mają przewidywalne wzorce, jeżeli chodzi o pisania. Wykorzystując to, dokonaliśmy ataku statystycznego. Użyliśmy uczenia masznowego, wykorzystującego zachowanie użytkowników i odpowiedni słowa. No i możemy dzięki temu odzyskać rzeczy, które zostały napisane w sesji SSH. 20 osób pisało w dowolny sposób i spisywaliśmy ich tekst. Użyto w sumie 4 574 słowa i użyliśmy do tego algorytmu do klastrowania, KNN, czyli K najbliższych sąsiadów. Powodem, dla którego użyliśmy tak prostego algorytmu było dowiedzenie, że sygnał, jaki dostajemy z opóźnień, jest rzeczywiście istotny i można go wykorzystać, żeby móc mapować te opóźnienia na to, co użytkownik pisze. W lewej stronie widzicie wyniki naszego klasyfikatora na surowych danych. Jest to oparte na opóźnieniach, które pojawiły się przy pisaniu lokalnie na klawiaturze. Widzimy, że to już jest dostatecznie trudne. Dokładność sięga 85%. Z dokładnością 58% jesteśmy w stanie zrobić to zdalnie dla najczęściej używanych 10 słów. Zdalnie jest oczywiście mniej dokładnie ze względu na hałas wprowadzony przez transport, przez sieć i oznacza tego wynikające. Ponieważ użyliśmy bardzo prostego algorytmu uczenia, jesteśmy, przypuszczamy, że możemy używać bardzo prostego algorytmu uczenia, że możemy uzyskać dokładniejsze wyniki bardziej zaawansowaną metodą, żeby przeprowadzić taki atak. Teraz widzimy, że może to zadziałać. Nie chcę ryzykować robienia demo na żywo, dlatego pokażę przygotowane wideo. Po lewej stronie widzimy terminal ofiary. Ofiara wkrótce rozpocznie SSH, a po prawej stronie widzimy atakującego. Teraz ofiarę zaczyna pisać. Atakujący w tej chwili uruchamia atak wyciągając informacje o pakietach ze zdalnego cashu. Ponieważ przetworzenie danych zajmuje chwilę, zobaczymy, że słowa pojawiają się z opóźnieniem. Miejmy nadzieję właściwej kolejności. Jak widzicie, jesteśmy w stanie poprawnie odgadnąć słowa przez sieć, jedynie przesyłając pakiety do tego samego serwera, do którego loguje się ofiara. Jedynie na podstawie opóźnień, z jakim te pakiety przybywały. Możecie się teraz pytać, w jaki sposób chronimy się przed atakami? Wystarczy, że zrobimy to na serwerze, ale z naszego punktu widzenia jedyna prawdziwa ochrona to jest wyłączenie DDI-u, albo nie używanie RDMA. Oba te sposoby wpływają na naszą wydajność, więc DDI-u oznacza, że będziemy mieli ponad 10% mniejszą wydajność zależnie od aplikacji, a jeżeli nie będziemy używać RDMA, to będziemy musieli przepisać naszą całą aplikację. Intel podczas ogłoszenia podatności powiedział coś innego. Powiedział, że wystarczy ograniczyć dostęp z niezaufanych sieci, ale to jest trochę dyskusyjna. Jestem bardzo dumny, że zostaliśmy zaakceptowani na sympałzium Security and Privacy 2020. Intel również uznał we wrześniu naszą znacisko i przyznał nam nagrodę. Intel był muszony umieścić swój niskopoziomowy karcz na szybciej ścieżce, i to eksponowało więcej komponentów mikroachlitektury i miało bezpośrednie wpływ na bezpieczeństwo. To jest pierwsza poddatność na DDI-u, ale pamiętajcie, że jest podłączonych więcej urządzeń, na przykład dyski. Możemy na przykład patrzeć poprzez kasz na dyski i na urządzenie przechowujące dana. Myślę, że tutaj możemy odkryć znacznie więcej, także czekajcie na to. Pozostaje mi tylko podziękować wam wszystkim i oczywiście wszystkim chodnikom tutaj na konferencji. Dziękuję bardzo. Mają czas na pytania. Dziękuję za wykład. Mam pytanie na temat, kiedy używam masz ten zdolnie, zwykle nie piszczę zwykłych słów, tylko jakieś dziwne kreski i inne polecenia szedlowa. Chcieliśmy pokazać, że możemy wydostać hasła, bo wtedy możemy użyć na przykład sudo. Hasła mają swoją dynamikę. Zwykle wpisuje się hasła trochę inaczej, niż zwykłe słowa kluczowe. Jeżeli chcemy spadać w jakiś sposób, użytkowicę wpisują hasła, no to albo pytamy o właściwe hasła i to nie jest takie etyczne, ale możemy też poprosić o inne hasła no i wtedy mogą je pisać trochę w inny sposób, niż wpisyliby swoje zwykłe hasła. Tak samo zlinie o koment, że po prostu nie mieliśmy korpusu, żeby wykonać taki atak. Dzień dobry, dziękuję. Chciałbym zapytać, czy to są ataków na SSH? Tak, to są ataków na SSH, od 2001 roku. Dlaczego nie ma jakiejś dodatkowej uchrony z takimi atakami? Dlaczego nic się dzieje w tym kierunku? Czy jest jakiś powód techniczny? My także zbaliśmy się, że od 2001 dodano jakieś opóźnienie albo grupowanie. No ale może to by przeskodziło z interaktywnością, nie wiem jaki jest prawdziwy powód. Czasami jest trudno dodać takie sztuczne pakiety pomiędzy zwykłymi, dlatego, że kiedy nie są losowe, no to możemy je po prostu odfiltrować. Poza tym nie wiem dlaczego nie zaadaptowano się przeciwko takim atakom. Jak bardzo musimy polegać na umiejętnościach piszącego? Jeżeli użytkownik musi szukać każdej litery na klawiaturze albo jest rozkojarzony, wtedy nie będzie miał prawdziwego wzorca pisania. Bardzo polegamy na tym wzorce, dlatego, że używamy bardzo prostego algorytmu, może już nie ma szytnowego. Patrzymy na odległość pomiędzy słowami, więc jeżeli to będzie inne, no to będziemy mieli znacznie mniejszą precyzję. To oznacza, że musielibyśmy wykonać ten atak przeciwko konkretnej osobie. Naszym celem nie było nie było opracowanie najlepszego algorytmu szytnowego. Użyliśmy informacje, które wpisywają użytkownik, żeby przygotować ten atak, ale być może można to umogulnić. Inne badanie mówią, że można kategoryzować użytkowników na różne rodzaje piszących. Jeśli dobrze pamiętam, to jest mniej więcej siedem różnych kategorii piszących. Wiem, że różne programy tego typu potrafią użyć twojego sposobu pisania, żeby zidentyfikować się ponownie. Na przykład, żeby pokazać ci reklamę, ale nie szliśmy tak głęboko w poprawianie stanu tego rozpoznawania. Czy spróbowaliście to na sieci, która ma dużo płównienia jak internet? Próbowaliśmy patrzeć ze stałym opóźnieniem. ARDMA zwykle jest w centrum danych, dlatego używaliśmy masznę z podobną topologią. W takim steneru, jak internet, musielibyśmy powtarzać pewnie atak wiele razy, co przeszkadza, dlatego, że wiele razy musielibyśmy zaprosić użytkownika, żeby wpisał dane kilka razy, więc odpowiedź w imienie. Jeżeli wklejamy coś, no to wszystko jest wysyłane na roz, tak, że nie możemy wykonać takiego ataku. Atakujące idzie dobrze rozumie, może tylko zobaczyć, że przyszły jakieś pakiety, więc jeżeli jednocześnie działa druga sesja, to czy to może przeszkodzić w tym ataku? Nawet odróżnienie tych pakietów sesji od innych pakietów sieciowych jest zawodne i wymaga pewnej skala styki. SSH zawsze wykonuje dwa pakiety jeden po drugim, ale pominęłem to, żeby uprościć ten wykład, no ale używamy takich heurystyk po to, żeby w ogóle odfiltrować pakiety SSH, dlatego gdybyśmy mieli drugą sesję, to nie moglibyśmy odróżnić, z której w sesji pochodzą pakiety. Powiedzieli, że używamy dwóch pakiet sieciowych, czy to muszą być różne karty sieciowe, czy może być ta sama? Używaliśmy jednej karty, która umie używać ARDMA, a druga, to było zwykłe połączenie eternetowe. Czy to mogły być dwie takie same karty? Infini Band nie używa pufora pierścieniowego, dlatego musielibyśmy śledzić te pakiety w inny sposób i to mogłoby skomplikować sprawę, dlatego że omijamy karty w ten sposób, ale gdyby był jakiś przewidualny zorzec, to też można by to wykorzystać. Czy możesz ocenić praktyczność tego ataku? Czy mogłby się zdarzać w realistycznym scenariuszu? I jaki jest chwili stan i czy możesz ocenić ryzyko takiego ataku? Chodzi o atak na pisanie. Pierwsze badania były z 2001 i od tego czasu wielu badaczy pokazało, że da się w różnych scenariuszach używać takich ataków na pisanie, na przykład w JavaScript, zawsze to jest trudno ocenić, dlatego że różni badaczy używają różnych zestawów danych, ale użyliśmy dość dużego kroku słów i to nadal działało, być może niezbyt procesyjnie, ale działało nadal. Gdybyśmy chcieli mieć realistyczny scenariusz z dużą procesją, to na pewno potrzebowaliśmy więcej danych i lepsze algorytmy i uczenia maszynowego, ale wszystkie mają swojej wady izolaty. Dziękujemy za uwagę. To było polskie tłumaczenie, wykładu praktycznego.