r   e   k   l   a   m   a
r   e   k   l   a   m   a

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

Strona główna Aktualności

Nie ma chyba bardziej gorącego tematu w pop-IT niż nowa chmurowa usługa przechowywania danych w wydaniu słynnego Kima Dotcoma. Wygląda to tak, jakby setki milionów internautów nie interesowały się niczym innym, jak tylko przechowywaniem w cyfrowych schowkach gigabajtów nieobrobionego wideo z imienin u cioci (bo przecież nie treści naruszających licencje właścicieli, nie mówiąc już o treściach nielegalnych). W pierwszej godzinie działania chmury Mega, zarejestrowanych miało być podobno 100 tysięcy kont. Przyciągnąć ich miała rozproszona architektura systemu, gwarantująca odporność na ataki ze strony sił prawa i porządku, jak również całkiem atrakcyjne ceny. W tym pospiechu mało kto się zastanowił nad kluczową kwestią: bezpieczeństwa przechowywanych w Mega danych. Publice najwyraźniej wystarczyły zapewnienia Dotcoma o szyfrowaniu tego i owego. Ciekawscy hakerzy zaczęli jednak z czasem przyglądać się Mega bliżej, a ich odkrycia nie brzmią zachęcająco.

Zrekapitulujmy to, co wiemy do tej pory: kluczowym aspektem nowego schowka 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 dokumentacji dla deweloperów można wywnioskować jednak, że każdy plik w Mega jest szyfrowany za pomocą oddzielnego klucza AES. Klucze te przechowywane są u użytkownika, zaś szyfrowanie i deszyfrowanie przeprowadzane przez kod działający w przeglądarce (dzięki czemu Mega nie może być pozwane za treści umieszczone w chmurze przez uż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 z sieci 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ócie identycznym ze skrótem pliku wgranego wcześniej, zostaje on zastąpiony łączem do wcześniej wgranego pliku. Dzięki temu Mega nie musi przechowywać wielokrotnych kopii tego samego pliku.

Powyższe fakty mówią same za siebie: Mega może technicznie zagrać przeciwko swoim użytkownikom, a oni mają jedynie obietnicę Kima Dotcoma, że tak się nie stanie. Po pierwsze, możliwe jest przejęcie kontroli nad serwerem CDN, tak by zaserwować użytkownikom kod 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, że dany użytkownik posiada na swoim koncie naruszającą prawo bądź licencje treść. Załóżmy oto, że Bob policjant wgrywa do Mega plik o nazwie windoze8h4cked.iso, ale w zamian dostaje od razu link do wgranego wcześniej przez innego użytkownika pliku o tym samym skrócie. Jeśli Bob zdoła ustalić na podstawie linku, że wgrany on został przez Alicję (a to możliwe jest sądowym nakazem powiązania identyfikatorów kont z nazwiskami użytkowników), sytuacja dla Alicji może wyglądać nieciekawie.

Te zagrożenia są ewidentne. Jednak na blogu fail0verflow pojawił się dziś wpis, który znacznie dokładniej analizuje zabezpieczenia samej witryny Mega. Streścmy najważniejsze spostrzeżenia jego autora, marcana (znanego szczególnie z upokarzania 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łędu związanego z obsługą Unicode, pozwalającego na tworzenie exploitów, nawet gdyby zamieniono CBC-MAC na coś lepszego. Z kolei Nadim Kobeissi, autor szyfrowanego komunikatora Cryptocat, zarzuca Dotcomowi wykorzystanie funkcji JavaScriptu math.random jako generatora liczb pseudolosowych. To mierny generator (trudno się spodziewać dobrych liczb pseudolosowych z komputera), więc podobno wykorzystana 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 jednak sprawiedliwość: na niektóre z tych zarzutów odpowiedział tak szybko, jak to tylko możliwe. Mega będzie w najbliższym czasie ulepszane, 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 nie wiemy. Trochę dziegciu do beczki z miodem Kima Dotcoma już się dostało, a początkowy entuzjazm internautów jakby wygasł.

r   e   k   l   a   m   a
© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.