8:58
22/7/2013

A więc jednak “podejrzana”, kilkudniowa przerwa w działaniu serwisu Apple Developer Center była spowodowana atakiem informatycznym. Apple właśnie poinformowało w mailu rozesłanym programistom, że “nie można wykluczyć, że dane osobowe programistów zostały wykradzione”. My wiemy, że na pewno zostały pobrane. Oto dowód.

Co dokładnie wyciekło?

Strona https://developer.apple.com/devcenter jest niedostępna od 18 lipca — nie można pobrać SDK i oprogramowania iOS7, nie można także korzystać z for dyskusyjnych — internauci do niedawna widzieli taki komunikat:

Apple Developer Center

Apple Developer Center

Dziś zmienił on treść na:

Apple Developer Center hacked

Apple Developer Center hacked

Nie “intruz” a “badacz bezpieczeństwa”?

Powodem jest İbrahim BALİÇ, który nazywa siebie “security researcherem” (nie ma dobrego spolszczenia tego słowa, ale intencją “researchera” jest prowadzenie, etycznymi metodami, badań w celu podniesienia bezpieczeństwa systemów/sieci/oprogramowania np. poprzez wyszukiwanie nowych technik ataku).

Takie określenie Ibrahima, w świetle tego co opublikował on na YouTube, jest jednak mocno wątpliwe. Na jego video pojawiają się bowiem dane osobowe programistów iOS (ich imiona i nazwiska, oraz adresy e-mail), a w tle widać program do masowego pobierania tych zestawów danych z serwerów Apple. Jeśli wierzyć deklaracji Ibrahima, pobrał on ponad 100 000 danych tej postaci:

Apple Developer Center hacked

Apple Developer Center hacked – opublikowany przez Ibrahima film z “ataku” (pomarańcz nasz)

Celem opublikowania nagrania było zapewne usprawiedliwienie się w oczach Apple, że Ibrahim nie czuje się intruzem i nie wykonał on ataku, a jedynie “badanie bezpieczeństwa”, z którego wynikami podzielił się z Apple (jako dowód, pokazuje screenshot ukazujący zgłoszenie błędu).

Logic fail…

Problem w tym, że “etyczny badacz bezpieczeństwa” nie opublikowałby w internecie filmu z danymi osobowymi setek programistów, a przede wszystkim swoją lukę potwierdziłby na jednym (góra kilku) testowych zestawach danych. Pisanie crawlera pobierającego masowo dane innych użytkowników z produkcyjnej bazy to dość nieodpowiedzialne przekroczenie granicy etycznego researchu

Na naszych szkoleniach z testów penetracyjnych, kiedy wyjaśniamy różnicę pomiędzy testem, audytem a włamaniem, zawsze podkreślamy, że nawet profesjonalni, zatrudnieni przez klienta pentesterzy po zidentyfikowaniu problemu np. typu SQL injection nie wykonują inwazyjnych akcji typuDROP TABLE“, a do potwierdzenia błędu polegającego na nieautoryzowanym dostępie do danych innych użytkowników, nie enumerują wszystkich użytkowników — wystarczającym dowodem dla klienta jest dostęp do jednego, najlepiej testowego konta. Takie podejście pozwala uniknąć problemów prawnych (zakres NDA, procedury firmy związane z ochroną danych osobowych) oraz etycznych (nie zawsze bowiem testy penetracyjne wykonywane są w całości na środowisku testowym, z testową bazą danych — wyciągnięcie całej produkcyjnej bazy danych niepotrzebnie może narażać pentesterów na podejrzenia, jeśli kiedyś jej fragmenty, np. pochodzące z wcześniejszego włamania, pojawią się w internecie).

Można więc zaryzykować stwierdzenie, że İbrahim BALİÇ filmikiem, którym chciał się “wybielić”, tak naprawdę strzelił sobie w stopę… Miejmy nadzieję, że teraz nie przyjdzie mu do głowy, aby sprzedać pozyskane w trakcie “badania bezpieczeństwa dane, aby pozyskać fundusze na prawników ;-)

Swoją drogą, Apple mogłoby otoworzyć Bug Bounty, jak Google, czy Microsoft…

PS. Jak myślicie, co z takimi danymi można zrobić? Ostatnio wszyscy programiści piszący aplikację na Androida otrzymali spam …z pytaniem o wersje ich aplikacji na iOS ;-)


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

12 komentarzy

Dodaj komentarz
  1. Researcher = badacz. Nie komplikujmy tego, co jest proste

    • Niestety w tym kontekście google translate się nie sprawdza. Pozdrawiam.

    • +1… http://www.researchgate.net

    • Poszukiwacz bezpieczenstwa brzmi jeszcze głupiej. ;)

  2. I was once security researcher. Then I took arrow to the knee.

    • ..so i became a hacker and suddenly, all the backdoors were open for me. ;)

  3. Z napisaniem crawlera to dobry pomysł – dzieki temu mozna oszacowac rozmiar problemu – ile danych mozna pozyskac w jakim czasie. Jednak rzeczywiscie można wykonać test na 1000 rekordów i bezproblemowo okreslic w jakim czasie jest sie w stanie pobrac 100 tys rekordów, zamiast faktycznie je wszystkie pobierać (tym bardziej ze jak bylo widac na filmiku rekord nowy to jakies 2-3 sekundy).

    Dziwne i myslę ze Apple mu nie odpusci.

  4. Jaka firma takie serwery. Jaka firma tacy testerzy bezpieczeństwa. Nie zdziwię się, jeśli on pracuje w Apple, a ten po prostu takim czymś chciał się stać nieco bardziej popularny, bo mu brakuje tego. “Patrzcie, zatamujemy potok danych! – kupujcie nasze telefony! Jesteśmy spece od bezpieczeństwa!”. Skąd ja to znam.

  5. Z filmiku wynika że cała strona stała na Google’owym GWT (swoją drogą nie widziałem [poza jednym] większych projektów spoza Google które używają tej technologii) – pewnie jakiś dev zapomniał o tym aby walidować dane po stronie serwera (no bo przecież user sam sobie w URL nie wklepie złych danych). Swoją drogą zaraz będzie że Apple nie jest winne bo:
    – używali Javy, czyli winne jest Oracle
    – używali GWT, czyli soft Google’a jest dziurawy

    • Wyczuwam kolejną rozprawę sądową w niedalekiej przyszłości ;)

    • Coś mi sie wydaję że ten serwis GWT-RPC był niepoprawnie
      zaimplementowany. Prawdopodobnie używali cookies do przesyłania
      sesji zamiast przesyłać to w ciele zapytania + brak autoryzacji
      (uwierzytalnienie było równoznaczne z autoryzacją).

  6. Jak myślicie, co z takimi danymi można zrobić?

    Podszyć się pod niego na jakimś innym serwisie, wydać aplikację taką i taką, a okaże się, że jest to zwyczajny wirus.

Odpowiadasz na komentarz Marcin

Kliknij tu, aby anulować

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: