Megaporażka? Hakerzy przyglądają się bliżej zabezpieczeniom cyberschowka Mega

Megaporażka? Hakerzy przyglądają się bliżej zabezpieczeniom cyberschowka Mega

23.01.2013 20:25

Nie ma chyba bardziej gorącego tematu w pop-IT niż nowachmurowa usługa przechowywania danych w wydaniu słynnego KimaDotcoma. Wygląda to tak, jakby setki milionów internautów nieinteresowały się niczym innym, jak tylko przechowywaniem wcyfrowych schowkach gigabajtów nieobrobionego wideo z imienin ucioci (bo przecież nie treści naruszających licencje właścicieli,nie mówiąc już o treściach nielegalnych). W pierwszej godziniedziałania chmury Mega, zarejestrowanych miało być podobno 100tysięcy kont. Przyciągnąć ich miała rozproszona architekturasystemu, gwarantująca odporność na ataki ze strony sił prawa iporządku, jak również całkiem atrakcyjne ceny. W tym pospiechumało kto się zastanowił nad kluczową kwestią: bezpieczeństwaprzechowywanych w Mega danych. Publice najwyraźniej wystarczyłyzapewnienia Dotcoma o szyfrowaniu tego i owego. Ciekawscy hakerzyzaczęli jednak z czasem przyglądać się Mega bliżej, a ichodkrycia nie brzmią zachęcająco.Zrekapitulujmy to, co wiemy do tej pory: kluczowym aspektem nowegoschowka Dotcoma miało być szyfrowanie danych lokalnie, za pomocąmechanizmów działających w przeglądarce. Jak to dokładnie działa– to słodka tajemnica Kima. Z dokumentacjidla deweloperów można wywnioskować jednak, że każdy plik wMega jest szyfrowany za pomocą oddzielnego klucza AES. Klucze teprzechowywane są u użytkownika, zaś szyfrowanie i deszyfrowanieprzeprowadzane przez kod działający w przeglądarce (dzięki czemuMega nie może być pozwane za treści umieszczone w chmurze przezużytkownika). Klucze te są osadzane w segmencie kotwicy (anchor)unikatowego adresu URL zasobu (czyli po znaku # adresu). Wiadomo teżże odpowiedzialny za szyfrowanie kod usługi Mega pobierany jest zsieci dystrybucji treści (CDN) i sprawdzana jest jego poprawność.Zwykle odbywałoby się to za pomocą funkcji skrótu, np. SHA,jednak Mega wykorzystuje zupełnie inny system uwierzytelnienia –kryptosystem CBC-MAC, co niepokojące, ze stałym kluczem.Nie jest też tajemnicą, że dane przechowywane w Mega mogąpodlegać deduplikacji – serwer przechowuje listękryptograficznych skrótów dla obecnych w systemie bloków danych.Jeśli użytkownik próbuje wgrać do usługi plik o skrócieidentycznym ze skrótem pliku wgranego wcześniej, zostaje onzastąpiony łączem do wcześniej wgranego pliku. Dzięki temu Meganie musi przechowywać wielokrotnych kopii tego samego pliku.Powyższe fakty mówią same za siebie: Mega może techniczniezagrać przeciwko swoim użytkownikom, a oni mają jedynie obietnicęKima Dotcoma, że tak się nie stanie. Po pierwsze, możliwe jestprzejęcie kontroli nad serwerem CDN, tak by zaserwować użytkownikomkod umożliwiający zdeszyfrowanie ich plików przez napastnika (np.służby policyjne), poprzez przesłanie klucza na serwer. Po drugie,wykorzystanie deduplikacji pozwala napastnikowi na ustalenie, żedany użytkownik posiada na swoim koncie naruszającą prawo bądźlicencje treść. Załóżmy oto, że Bob policjant wgrywa do Megaplik o nazwie windoze8h4cked.iso, ale w zamian dostaje od razu linkdo wgranego wcześniej przez innego użytkownika pliku o tym samymskrócie. Jeśli Bob zdoła ustalić na podstawie linku, że wgranyon został przez Alicję (a to możliwe jest sądowym nakazempowiązania identyfikatorów kont z nazwiskami użytkowników),sytuacja dla Alicji może wyglądać nieciekawie. [img=crypto]Te zagrożenia są ewidentne. Jednak na blogufail0verflow pojawił się dziś wpis, który znacznie dokładniejanalizuje zabezpieczenia samej witryny Mega. Streścmy najważniejszespostrzeżenia jego autora, marcana (znanego szczególnie zupokarzania działów bezpieczeństwa Nintendo i Sony): W wypadku korzystania z webowego interfejsu Mega, skazani jesteśmy na ufanie Dotcomowi i dostarczanemu przez niego kodowi w JavaScripcie. Zwykle w takich sytuacjach stosuje się silne szyfrowanie SSL, mające zagwarantować, że kod pochodzi od dostawcy usług, a nie od kogoś, kto się pod niego podszył. W wypadku Mega sytuacja wygląda tak, że owszem, SSL jest stosowane, ale nie do końca w zgodzie z dobrymi praktykami. Większość witryny serwowana jest w sposób niebezpieczny. Główny plik witryny spoczywa na serwerze korzystającym z 2048-bitowego klucza RSA. Cała reszta jest jednak pobierana z CDN-u, stosującego tylko 1024-bitowy SSL z autentykacją MD5. CDN nie należy do Mega, tylko do firm trzecich, które mogą, ale nie muszą być odporne na działania napastników. Ufając Kimowi, ufamy też jego partnerom i ufamy w to, że nikt nie złamał 1024-bitowego SSL. Abyśmy nie musieli tak bardzo ufać, Mega w pliku indeksu przechowuje połączony skrót do tych dodatkowych treści, tworząc „łańcuch zaufania”. Każdy zasób jest dynamicznie pobierany ajaksowymi metodami, wyliczany jest jego skrót, a następnie ładowany do aplikacji. marcan nie zostawia suchej nitki na stosowanej metodzie – wspomniany wcześniej kryptosystem CBC-MAC ma wiele wad, o których można poczytać nawet w Wikipedii. W szczególności bardzo słabo nadaje się do wykorzystania jako funkcja skrótu – każdy, kto zna klucz, może sfałszować wiadomość tak, by wartość jej skrótu była taka sama. Nie są to czcze zarzuty – na blogu znajdziecie kod w JavaScripcie pozwalający na sfałszowanie skrótu dowolnego pliku. W praktyce oznacza to, że każdy partner Kima Dotcoma może wprowadzić na Wasze komputery to, co mu się żywnie podoba, a zabezpieczenia Mega niczego nie wykryją. O tej wadzie haker pisze dosadnie: Kim Dotcom zrobił Nintendo Wii. Mega zostało ciekawie pomyślane, ale implementacja okazała się marna, przeprowadzona przez osoby wyraźnie nie znające się na podstawowej kryptografii. Zamiast zastosować sprawdzanie danych przez SHA1 (a chociażby słabsze MD5), wykorzystano nie nadający się zupełnie do tego mechanizm, chyba tylko po to, by trzymać się konstrukcji zbudowanej wokół kryptosystemu AES.To nie jedyne problemy z Mega.marcan podejrzewa występowanie w usłudze subtelnego błęduzwiązanego z obsługą Unicode, pozwalającego na tworzenieexploitów, nawet gdyby zamieniono CBC-MAC na coś lepszego. Z koleiNadim Kobeissi, autor szyfrowanego komunikatora Cryptocat, zarzucaDotcomowi wykorzystanie funkcji JavaScriptu math.random jako generatora liczb pseudolosowych. To mierny generator (trudno sięspodziewać dobrych liczb pseudolosowych z komputera), więc podobnowykorzystana jest dodatkowe entropia z ruchów myszy i naciśnięćklawiszy. Sęk w tym, że komunikat w tej kwestii dezinformuje –podczas generowania pary kluczy nie wiadomo, czy trzeba machaćmyszą, czy też już w tej kwestii nic nie zostało do zrobienia.Oddajmy Dotcomowi jednaksprawiedliwość: na niektóre z tych zarzutów odpowiedział tak szybko, jak to tylko możliwe. Mega będzie w najbliższym czasieulepszane, a bezpieczeństwo usługi wzrośnie. Czy jednak na tyle,by uczynić z usługi nowy raj dla internetowego piractwa(przepraszamy, przechowalnię filmów z imienin cioci) – tego niewiemy. Trochę dziegciu do beczki z miodem Kima Dotcoma już siędostało, a początkowy entuzjazm internautów jakby wygasł.

Źródło artykułu:www.dobreprogramy.pl
Oceń jakość naszego artykułuTwoja opinia pozwala nam tworzyć lepsze treści.
Wybrane dla Ciebie
Komentarze (32)