Artykuły dotyczące tematu: MEGA

dodany: 30.07.2013 | tagi: , , ,

Schemat szyfrowania serwisu Mega hakera Kima DotComa

5

Kim DotCom, znany również pod pseudonimem „Najbardziej poszukiwany człowiek w Internecie”, nadal jest jednym z najpopularniejszych tematów doniesień prasowych, mimo że od momentu wyłączenia jego serwisu do udostępniania plików Megaupload Limited minęło już półtora roku. Przedstwiamy komentarz Ruchna Nigam, security researchers w FortiGuard Labs.

Zaledwie kilka tygodniu temu DotCom opublikował film wideo z systemu kamer przemysłowych CCTV, przedstawiający nalot agentów FBI na jego willę, który został przeprowadzony w styczniu 2012 roku. Film kończy się niezbyt subtelnym nawiązaniem do filmu „Człowiek z blizną”.

Dokładnie 5 miesięcy wcześniej DotCom powrócił na scenę, oferując internautom swoją nową i udoskonaloną usługę udostępniania plików o nazwie Mega. „Dziwnym zbiegiem okoliczności” usługa ta została uruchomiona w pierwszą rocznicę wyłączenia serwisu Megaupload.

Dla wszystkich tych, którzy nie pamiętają (mimo że bardzo trudno zapomnieć obsceniczną buńczuczność tego wydarzenia), oficjalna inauguracja usługi została zorganizowana zgodnie z charakterystyczną dla Kima DotComa zasadą „wszystkie chwyty dozwolone”, a relację z tego wydarzenia opublikowano na kanale YouTube hakera, aby wyryć ją w pamięci następnych pokoleń internautów.

kim dotcom

Kim Dotcom.

Od swojej inauguracji usługa Mega była przedmiotem wielu śledztw i dochodzeń dotyczących bezpieczeństwa infrastruktury i samej koncepcji. Jednak do chwili obecnej Mega znajduje się w doskonałej kondycji i dynamicznie się rozwija. Według mnie w przyszłości dynamika tego rozwoju może się tylko nasilić, biorąc pod uwagę zwłaszcza coraz większe kontrowersje wokół poufności danych w Internecie.

Wspomnianych wątpliwości w żadnym stopniu nie rozwiewają najnowsze rewelacje Edwarda Snowdena dotyczące programu PRISM, wykorzystywanego przez rząd USA do inwigilowania działań obywateli w Internecie. Rzeczywiście, danych przesyłanych do serwisu Mega i w nim przechowywanych teoretycznie nie można szpiegować na poziomie dostawcy usług internetowych – chyba że złamany zostanie sam mechanizm szyfrowania (AES/RSA). Jednak, zgodnie ze stanem wiedzy ogólnej i specjalistycznej, nie mówimy tutaj o takich przypadkach.

Mechanizm funkcjonowania serwisu Mega postaraliśmy się podsumować na prezentowanych poniżej schematach:

Część pierwsza: TWORZENIE KONTA UŻYTKOWNIKA 

schemat

Cześć druga: LOGOWANIE UŻYTKOWNIKA

schemat2

Część trzecia: PRZESYŁANIE PLIKÓW 

schemat3

Część czwarta: UZYSKIWANIE DOSTĘPU DO PLIKÓW 

schemat4

Część piąta: UDOSTĘPNIANIE I POBIERANIE PLIKÓW 

schemat5

Przewaga usługi Mega nad innymi usługami udostępniania plików:

  1. Poufność: Wszystkie dane przechowywane na serwerach Mega są szyfrowane, w związku z czym firma Mega nigdy nie widzi zawartości danych użytkownika. Można to bardzo łatwo zweryfikować, ponieważ pełne szyfrowanie realizują skrypty tekstowe oparte na otwartym kodzie źródłowym po stronie klienta. (DotCom jest tak pewny skuteczności swojego mechanizmu szyfrowania, że ufundował nagrodę w wysokości 10 000 EUR dla osoby, która zdoła go złamać). Podsumowując, bezpieczeństwo danych zależy od osoby dysponującej kluczami, czyli od użytkownika. Jest to również zdecydowana korzyść dla dostawcy usługi, ponieważ serwis może uniknąć problemów z prawami autorskimi, które wcześniej doprowadziły do ostatecznego wyłączenia serwisu Megaupload. Jednak, parafrazując słowa Kima DotComa, jest to niewielka korzyść w porównaniu z całkowitym uniezależnieniem się od inwigilacji, jakie Mega może zaoferować swoim użytkownikom.
  2. Bezpieczne udostępnianie plików: Użytkownicy (nawet ci, którzy nie zarejestrowali się w serwisach udostępniania plików) mogą w bezpieczny sposób udostępniać pliki między sobą, ponieważ odwołania do plików w serwisie Mega opierają się na łączu do pliku oraz kluczu pliku. Z tego względu dostęp do pliku może uzyskać osoba dysponująca informacjami o obu tych elementach. Jest to dodatkowa warstwa bezpieczeństwa dostępu do przesłanych plików.

Wady/luki w zabezpieczeniach:

  1. Ataki za pośrednictwem przeglądarek: Usługa jest nadal wrażliwa na ataki ze strony klienta, na przykład ataki typu „Man in the Browser”, które mogą zastąpić algorytmy szyfrowania używane przez serwis Mega, algorytmami znanymi dla osoby przeprowadzającej atak. Atak tego typu pozwala również obejść kontrolę spójności danych po stronie klienta, realizowaną poprzez wczytanie kodu Javascript z innego serwera Mega. Podsumowując, wszystkie znane słabości wszystkich mechanizmów uwierzytelniania (włącznie z uwierzytelnianiem dwuczynnikowym) występują również w mechanizmie uwierzytelniania serwisu Mega. Jeśli więc komputer klienta padnie ofiarą ataku, użytkownik jest „ugotowany”.
  2. Protokół SSL: Złamanie zabezpieczeń protokołu SSL (lub atak typu booby trap przeprowadzony przez NSA) oznacza złamanie zabezpieczeń serwisu Mega. Jednak według mnie przypadki złamania zabezpieczeń protokołu SSL będą oznaczały o wiele większe problemy dla całego Internetu niż dla serwisu Mega.

Nie wiadomo, co czeka hakera Kima DotComa w przyszłości, ponieważ daty jego ekstradycji i przesłuchania są konsekwentnie przesuwane. Możemy jednak śmiało stwierdzić, że jego druga próba zapewnienia użytkownikom swobody udostępniania treści przetrwa znacznie dłużej.

Źródło: Fortinet

Źródło grafiki głównej: telegraph.co.uk

 

Zobacz także: MEGA-problem nowego serwisu Kima Dotcoma

 

dodany: 11.02.2013 | tagi: , ,

7 MEGA grzechów

0

Pamiętacie jak nie dawno Kim Dotcom ogłosił wyzwanie (zobacz newsa: Kim rzuca wyzwanie), które polegało na próbie złamania zabezpieczeń jego nowego serwisu? Tak jak się można było spodziewać, na efekty nie trzeba było długo czekać. Spryciarze znaleźli 7 poważnych błędów w usłudze Mega. Kim wprowadził 6-stopniową klasyfikację odnalezionych słabości, przy czym klasa VI oznacza najpoważniejszą, natomiast I najmniej istotną.

Kim po części miał rację, gdyż nikomu nie udało się znaleźć luk klasyfikujących się jako V i VI kategoria. Istnieje co prawda szansa, że po prostu nie pochwalił się tym publicznie, aczkolwiek raczej szybko Internet by to rozdmuchał.

 

Oto 7 grzechów popełnionych przy stworzeniu serwisu Mega:

IV kategoria

Błąd w aplikacji  CBC-MAC, która to zabezpiecza haszem integralność statycznej zawartości klastra ładowanej z serwerów rozproszonych. Kim bronił się, że żaden z statycznych serwerów nie znajdował się w niezaufanych centrach danych. Problem został naprawiony w kilka godzin, pomijając teoretyczną możliwość wykonania ataku typu man-in-the-middle, poprzez zastosowanie 1024-bitowego klucza SSL.

III kategoria

Tu znaleziono kilka problemów z możliwością wykonania zdalnego kodu poprzez cross-site scripting:

  • Pierwszy XSS był możliwy poprzez odpowiednio spreparowane nazwy plików. Przypomnijmy, że podobną wpadkę zaliczył ostatnio serwis Mediafire, który znacznie dłużej jest na rynku. W przeciwieństwie do konkurencji problem został naprawiony niemal natychmiast.
  • Drugi atak XSS był możliwy do wykonania na stronie pozwalającej ściągać pliki. Problem dotyczył wszystkich przeglądarek poza Chrome. Usterka ta została naprawiona w ciągu kilku godzin od zgłoszenia.
  • Trzeci XSS był spowodowany nie bezpośrednio samym serwisem Mega, a użytym komponentem Flash o nazwie ZeroClipboard.swf – problem także szybko został załatany.

II kategoria

W tym wypadku także stwierdzono dziury, które mogły posłużyć do ataków XSS – problem leżał dokładnie w API serwera, który przekazywał łańcuchy przekierowujące do strony ściągania – zastosowanie 3 różnych wektorów umożliwiało zastosowanie ataku man-in-the-middle. Błąd ten został także sprawnie usunięty.

I kategoria

Do „najlżejszej” kategorii zakwalifikowano brak nagłówka Strict Transport Security w HTTP na stronach mega.co.nz i *.api.mega.co.nz. Oprócz tego stwierdzono także luki w nagłówku X-Frame, które mogły spowodować clickjacking. Oczywiście naprawa tych drobnostek była najprostsza.

 

I to już wszystkie problemy, które zostały ujawnione. Konkurs jeszcze się nie skończył, więc jest szansa, że ktoś znajdzie poważniejsze odstępstwa. Szkoda tylko, że Kim nie pochwalił się na blogu, jakie rozdał nagrody.
Akutalizacja godz. 11:03  12-02-2013

W sieci jeden z odkrywców błędów kryjący pod nickiem Frans pochwalił się nagrodą na Twitterze, którą otrzymał od serwisu Mega:

Twitter Frans

Organizatorzy nie omieszkali poinformować, że Google za ten sam błąd płaci mniej… Nagroda ta dotyczy III kategorii, a konkretniej problemu z flashem.

dodany: 04.02.2013 | tagi: , ,

Kim rzuca wyzwanie

0

Kim Dotcom widać mocno jest przekonany o bezpieczeństwie swojego nowego serwisu, mimo że w sieci pojawiło się dużo negatywnych głosów (zobacz newsa: MEGA-problem nowego serwisu Kima Dotcoma). Zapewne dlatego zdecydował się zaoferować wygraną 10 tysięcy  euro  dla osoby, która jako pierwsza złamie zabezpieczenia serwisu.

Kim taką informację przedstawił na swoim blogu, pisząc przy okazji, że szyfrowanie zastosowane na jego serwisie jest nie do złamania. Mimo sceptycznych głosów, serwis wystartował dość gorąco, gdyż pierwszego dnia po otwarciu miał już jeden milion zarejestrowanych użytkowników. Obecnie w nowym serwisie jest przechowywanych około 50 milionów plików.

Ciekawy jest wywód Kima na temat statystyki nielegalnego oprogramowania – w regulaminie jest oczywiście zawarte, że załadowane pliki nie mogą naruszać praw autorskich. Właściciel chwali się, że zaledwie tylko jeden promil danych musiał zostać usunięty z powodu naruszenia praw autorskich. Do tego wyniku przyczyniła się blokada dostępu wyszukiwarek zewnętrznych, takich jak np. google. Oczywiście mówimy tu o blokadzie indeksowania plików, które są dostępne publicznie.

Przy kwocie nagrody jest „gwiazdka” – jest to bowiem maksymalna nagroda, którą można zdobyć w zależności od stopnia złamania zabezpieczeń. Szczegółowe wytyczne dla zainteresowanych są zawarte we wpisie w blogu. Najwyższa nagroda jest możliwa w przypadku podania klucza deszyfrującego plik z mega.co.nz. W konkursie nie są brane pod uwagę sztuczki socjotechniczne itd.

dodany: 25.01.2013 | tagi: , ,

Serwis Mega nie szyfruje Twoich danych?

1

Przez ostatnie dni sporo było wiadomości o nowym tworze Kima Dotcoma – Mega (zobacz newsa: MEGA-problem nowego serwisu Kima Dotcoma). Jest to kolejny serwis cloud, którego twórca zapewnia o jego bezpieczeństwie, ale czy możemy mu zaufać?

Usługa posiada dokumentację, której kilka stron zadedykowano programistom – poświęcono je wytłumaczeniu jak działa API. Zawiera ona także kilka szczegółów o tym, gdzie i jakich metod szyfrowania używa serwis. Niektóre z zagadnień nie są tak proste (albo tak bezpieczne), jak się może wydawać na pierwszy rzut oka.

 

Block object storage

W dokumentacji Mega użyto określenia „hierarchical file/folder paradigm”, co jest wymyślnym sposobem powiedzenia, że dane są przechowywane w postaci plików i folderów tak samo, jak na lokalnym dysku. Każdy plik oraz folder posiada identyfikator nazywany node (analogia do inode z systemów plików w Uniksach) i każdy node posiada swojego rodzica. W ten sposób paradygmat pliku/folderu jest spełniony, nawet jeśli wszystkie usługi Mega widzą same zaszyfrowane bloki. Każde konto posiada trzy kontenery, które nie mają node-rodzica – jeden to podstawowy katalog na pliki, drugi to inbox i ostatni to kosz.

Każdy node zawiera blok z atrybutami – nazwa pliku/folderu danych przypisanych do node – i bloki z danymi. W dokumentacji zaznaczono, że w przyszłości w pierwszym bloku może być przechowywanych więcej informacjitakich jak wiadomości między użytkownikami. Oba rodzaje bloków są szyfrowane za pomocą AES-128 (każdy osobno).

 

Szyfrowanie

Wszystkie operacje kryptograficzne bazują na AES-128. Szyfrowanie wykonywane jest w trybie wiązania bloków zaszyfrowanych (z ang. CBC – cipher block chaining mode) dla plików i folderów (blok atrybutów) oraz w trybie licznikowym (z ang. CTR – counter mode) dla danych samych w sobie. Każdy plik i folder używa swojego, losowo generowanego 128 bitowego klucza. Pliki używają tych samych kluczy dla danych i atrybutów oraz dodatkowo 64 bitowej losowej wartości początkowej licznika, a do weryfikacji spójności 64 bitowych danych MAC.

Pliki i foldery są zaszyfrowane symetrycznie – oznacza to, że ten sam klucz jest używany do szyfrowania i deszyfrowania danych. Jest to sposób wymagający mniejszej mocy obliczeniowej i łatwiejszy w implementacji niż szyfrowanie asymetryczne – którego Mega ma zacząć używać za jakiś czas.

AES-128 jest dobrze znanym i szeroko używanym szyfrem blokowym (z ang. block cipher). Działa poprzez transformację kawałków danych w oparciu o klucz szyfrujący. Robi to kilkunastokrotnie (w zależności od wielkości klucza – w przypadku 128 bitowego: 10 razy). Aby odszyfrować, ten sam proces jest wykonywany w odwrotnej kolejności, używając tego samego klucza. W Mega klucz szyfrujący jest generowany dla Ciebie podczas rejestracji i jest dodatkowo zaszyfrowany przy użyciu Twojego hasła.

Zanim przejdziemy dalej, zatrzymajmy się przy możliwych wnioskach. Klucz używany do szyfrowania plików i folderów w Mega jest przechowywany na ich serwerach, a nie na Twoim komputerze. Wygląda też na to, że nigdzie nie ma mechanizmu przywracania hasła na stronie logowania czy też możliwości zmiany hasła w panelu użytkownika. Ponieważ główny klucz AES-128 jest zaszyfrowany Twoim hasłem – warto je zapamiętać. Zgubienie bądź zapomnienie hasła oznacza, że nie będziesz mieć możliwości logowania w serwisie – tracisz możliwość deszyfrowania Twoich plików!

 

Poking holes

Z pozoru wszystko wygląda całkiem bezpiecznie – dane są szyfrowane za pomocą AES-128, jest osobna metoda szyfrowania wiadomości między użytkownikami. Jednak tutaj wszystko zaczyna się psuć…

Największym problemem metod Mega jest niewystarczająca ilość entropii zebranej przy generacji pary kluczy RSA. Klucze szyfrowania muszą być trudne do odgadnięcia i z reguły tworzy się je losowo poprzez odpowiedni algorytm. Komputery notorycznie są pseudolosowe i te wygenerowane przez nie „losowe” liczby, np. przez /dev/random, muszą być wspomagane przez czynnik zwany entropią. Jest to „prawdziwa” losowość zdobywana przez komputer z różnych źródeł – wciśnięcia klawiszy, ruchów myszką, dźwięków odbieranych z mikrofonu i tak dalej. Niektóre nowoczesne procesory zawierają nawet „prawdziwe generatory liczb losowych”, które jako entropii używają wibracji na poziomie atomowym w CPU.

Zasada jest prosta – im większa entropia – tym bardziej losowy klucz, a więc będzie on możliwie „niezgadywalny”. Jeżeli generujesz parę kluczy RSA w linii poleceń używając narzędzia jak openssl – masz wszystko podane na tacy, narzędzie się martwi entropią za Ciebie. Niestety dla Mega klucz RSA generowany jest za pomocą Javascript i odpowiednie ilości entropii nie zostają zbierane. Nadim Kobeissi, twórca Cryptocat, całkiem dużo tweetował na ten temat w sobotę (19 stycznia). Zaznaczył, że Mega używa math.random, jako podstawy generowania losowych liczb. Dodatkowo na wzmocnienie – pobiera trochę danych z klawiatury i myszki. Jednak wiadomość podczas generowania klucza jest myląca:

 

Zaznaczenie_002

Aby wzmocnić klucz zebraliśmy entropię z ruchów Twojej myszki i naciśnięć klawiatury.

 

Powinniśmy ruszać teraz myszką czy już jest po wszystkim? Bez dodatkowej entropii „losowe” liczby pierwsze podane przez math.random do użycia, jako klucze RSA są tylko pseudolosowe i mogą zostać odgadnięte. Koniec końców jest łatwiej niż być powinno (nie łatwo, a łatwiej) poprzez inżynierię wsteczną (z ang. reverse-engineering) poznać prywatny klucz RSA użytkownika Mega. To znaczy, że łatwiej jest poznać tożsamość użytkownika podczas wysyłania wiadomości lub plików.

 

Deduplikacja

Warto zwrócić uwagę na jeszcze jedną, niebezpieczną sprawę. Regulamin usługi zawiera następujący punkt:

Nasza usługa może automatycznie skasować część danych, którą wgrywasz (upload) albo dać komuś innemu dostęp do danych, które są dokładną kopią oryginalnych danych już dostępnych w naszej usłudze. W tym przypadku – dostaniesz dostęp do oryginalnych danych.

Brzmi to jak deduplikacja – przechowywanie każdego unikatowego kawałka danych tylko jeden raz na dysku w celu zaoszczędzenia miejsca. Wykorzystanie szyfrowania AES-128 dla bloków z danymi powinno zapewnić, że każdy zaszyfrowany blok jest inny, nawet jeśli są to te same pliki. Jeśli Mega widzi tylko zaszyfrowane dane, które z definicji są całkowicie unikatowe, w jaki sposób chce je „deduplikować”? Czy coś tu dzieje się nie tak?

Na Hacker News powstało wiele teorii, będących próbą wyjaśnienia, w jaki sposób może działać Mega – np. poprzez używanie szyfrowania zbieżnego (z ang. convergent encryption) do rozpoznawania nieunikatowych bloków. Jakikolwiek sposób by to nie był – faktem jest, że deduplikacja jest używana i pozostaje ona przeciwko postawie „see no evil” przybranej przez Mega. Globalna metoda rozpoznawania specyficznych danych niekoniecznie musi coś znaczyć. W pewien sposób obciąża to Mega – może właściciele serwisu nie mogą powiedzieć, co użytkownicy Jan czy Jaś mają na swoich kontach, jednak istnieje możliwość powiedzenia czy Jan i Jaś mają ten sam plik. Jeśli np. MPAA (z ang. Motion Picture Association of America) dowie się, że Jan ma ich film „Hobbit: Niespodziewanie długi film” i przypadkiem Jaś też go posiada – udowodnienie użytkownikom np. korzystania z nielegalnej kopii pozostaje banalnie prostym przedsięwzięciem.

 

Czym to grozi?

Wygląda na to, że wiele problemów z implementacją kryptografii w usługach Mega wynika z chęci zrobienia serwisu najlżejszego jak się da, wymagającego tylko przeglądarki obsługującej Javascript (Chrome jest preferowane, przynajmniej tak piszą na stronie). Z jednej strony oznacza to, że żadna zewnętrzna aplikacja „klient” nie jest wymagana i przeglądarka sama w sobie pełni funkcję platformy – to ułatwia testowanie i wdrażanie nowych funkcjonalności do usługi, począwszy od aktualizacji plików Javascript). Dodatkowo nie ma problemów z kompatybilnością między platformami – wszystko działa na każdym komputerze i (prawie) każdej przeglądarce. Z drugiej strony – dokumentacja i implementacja posiada niemałą liczbę słabości i potencjalnych exploitów. Generator pary kluczy RSA powinien byś ulepszony oraz powinna istnieć jakaś możliwość kopii i zmiany klucza szyfrowania.

Fakt, że zaszyfrowane dane nie są całkowitą tajemnicą dla Mega, jest największym problemem. Z jednej strony – stosowanie deduplikacji danych na poziomie bloków jest oczywiste – przestrzeń dyskowa jest tania, ale nie aż tak. Do tego zamiast trzymać tysiące kopii „Hobbita” – przechowywana będzie tylko jedna, zwalniając tym samym terabajty miejsca (ze względu na brak wiedzy o skali i zasięgu deduplikacji wyliczenia te mogą być optymistyczne). Z drugiej strony – nawet jeśli Mega nie wie, że te bloki danych to akurat „Hobbit”, Mega wciąż ma wiedzę, do kogo one należą.

Mathias Ortman, CTO Mega, podczas konferencji startowej powiedział:

Szyfrowanie jest open source. Spodziewamy się, że społeczność od bezpieczeństwa dokładnie spojrzy i skomentuje możliwe słabości.

dodany: 23.01.2013 | tagi: , , , , ,

MEGA-problem nowego serwisu Kima Dotcoma

1

Kim Dotcom, który zasłynął z założenia już nieistniejącego serwisu megauplod.com znów powrócił – założył on „bardziej” legalny serwis o nazwie Mega. Od zamknięcia poprzedniego serwisu minął rok. Start niestety nie był do końca dopracowany – dlaczego? Hasła nowo rejestrowanych użytkowników są zakodowane w linku aktywacyjnym!  Odkrył to badacz bezpieczeństwa z Steve Thomas znany też jako ScOObz.

Przykładowy link wygląda następująco:

Sc00bz zauważył, że link aktywacyjny jest zakodowany algorytem base64. Jeśli powyższy ciąg znaków skonwertujemy do kodowania heksdecymalnego, to otrzymamy zahaszowane hasło użytkownika!

Powyższy ciąg z linku po takiej konwersji wygląda następująco:

W ciągu tym możemy wydzielić 6 krótszych. Kolejne elementy tego ciągu są następujące:

1. 70491be7c3858d0698b282b993d5ed69 – to zaszfyrowany klucz master;

2. ba7fd1c38b5a5073ef73679eb9c7bd48 – hasło użytkownika zaszyfrowane algorytmem AES;

3. 63797275732e6661726976617240617273746563686e6963612e636f6d  – adres e-mail w kodowaniu heksadecymalnym;

4. 43797275732046617269766172 – zakodowana nazwa użytkownika.

 

Pozostałych dwóch ciągów Steve jeszcze nie zidentyfikował. Dane te wystarczyły jednak do stworzenia przez niego automatu łamiącego hasła z wspomnianego linka – narzędzie to możemy pobrać ze strony autora.

Program doczekał się już wydania drugiej wersji, która jest oznaczona numerem 0.2a – w porównaniu do pierwszego wydania działa szybciej i ma poprawione kilka małych błędów. Wydajność najnowszej wersji wynosi 4820 znaków/sekundę na procesorze i7-2600.

megacracek02a

Dla pikanterii autor zamieścił w samym serwisie MEGA ważącą 25MB listę wstępnie zdekodowanych haszów, a konkretnie zawierającą same hasła. Dzięki niej prędkość obliczeń wzrasta do 4.59 mega-znaków/sekundę podczas dekodowania jednego hasza.

 

Co na to właściciele serwisu?

Oczywiście Kim nie pozostawił tego faktu w ukryciu – właściciel zajął stosowne stanowisko w tej sprawie na swoim blogu.

Mało tego MegaCrackera opisał jako bardzo przydatne narzędzie do odzyskania swojego klucza, na wypadek zagubienia  z zastrzeżeniem, że narzędzie to nie spisuje się dobrze, jako „odgadywacz” haseł…

Informacja ta wynikła częściowo przez ciśnienie, które wywarł portal ArsTechnica odnośnie słabego szyfrowania, podczas gdy reklama  serwisu mówi o „megabezpieczeństwie”.

Poznając hasło do konta użytkownika, możemy zmienić master key, który jest odpowiedzialny za szyfrowanie naszych danych na serwerze. Klucz ten jest zaszyfrowany 128-bitowym algorytmem AES .

Serwis broni się tym, że nie ma możliwości odzyskania tego klucza, nawet jeśli zapomnimy nasze hasło i nie będzie można uzyskać dostępu do wcześniej zgromadzonych danych. Zapowiedział jednak, że ma to zostać zmienione, poprzez wprowadzenie możliwości zmiany hasła oraz ponownego zaszyfrowania nim głównego klucza.

Serwis odpowiedział, że reset hasła nie będzie umożliwiał wcześniej zgromadzonych danych, aczkolwiek będzie istnieć możliwość importu naszego klucza – wtedy nawet bez znajomości poprzedniego hasła, będziemy mogli je odczytać .

Zaskakującą linią obrony jest stwierdzenie właściciela:

jeśli potrafimy złamać komunikację SSL, to możemy zająć się ciekawszymi rzeczami, niż te zgromadzone w serwisie MEGA

– powiedział Dotcom.

Jednak to, co jest główną przyczyną braku zaufania w bezpieczeństwie nowej usługi, to fakt zastosowania po stronie serwera SSL szyfrowania za pomocą 1024-bitowego klucza, podczas gdy obecnie rozsądne minimum zapewnia klucz 2048-bitowy. Mało tego, serwis podaje, że mechanizm ten zastosował, tylko z tego względu, że przeglądarki nie lubią połączeń HTTP wywołanych z HTTPS!

Dłuższy klucz wykorzystuje co prawda główna domena https://mega.co.nz/, ale sama https://*.static.co.nz/ używa już krótszej wersji – Kim Dotcom broni się zbyt dużym zużyciem zasobów CPU.  Weryfikacja kluczy odbywa się przez JavaScript, które są generowane przez słabiej zabezpieczony serwer i wg twórców nie pozwala na atak człowiek-po-środku.

Wg niezależnych badaczy weryfikacja ta jest po prostu bezsensowna, bo nie chroni przed niczym.

Po tych oskarżeniach współtwórca serwisu Van der Kolk, dodał, że autoryzacja odbywa się w oparciu o dodatkowe dane, wygenerowane w oparciu o aktualne ruchy myszką i naciśnięcia klawiszy klawiatury u użytkownika serwisu.

Wygląda, że faktycznie tak jest, gdyż podczas generowania naszego klucza RSA, pasek postępu przyspiesza, gdy poruszamy kursorem myszy.

Cóż, start czegoś nowego zwykle przyciąga potencjalnych atakujących – tym bardziej, że nowa usługa w chmurze została zbudowana przed dobrze znane nazwisko… Ruch na serwisie szybko wzrósł i dognił usługę DropBox, o czym Kim nie omieszkał pochwalić się na swoim Twitterze.

traffic rank mega

 

Jedyne sensowne usprawiedliwienie autorów, to takie, że serwis jest w fazie beta.