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 ;-)

Przeczytaj także:

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.

Twój komentarz

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

RSS dla komentarzy: