Атака на Apple. Разбираем подробности крупномасштабного взлома и примененные техники - «Новости»

В предыдущей серии

В пре­дыду­щей статье мы рас­ска­зали о том, как про­ходи­ла под­готов­ка к ата­ке, как был взло­ман сайт пре­пода­вате­лей Apple, получен дос­туп к лич­ным дан­ным поль­зовате­лей iCloud и к исходни­кам iOS. Изу­чив сай­ты и веб-при­ложе­ния Apple, коман­да в сос­таве Сэ­ма Кар­ри (Sam Curry), Брет­та Бюр­хауса (Brett Buerhaus), Бе­на Садеги­пура (Ben Sadeghipour), Сэ­мюэля Эрба (Samuel Erb) и Тан­нера Бар­нса (Tanner Barnes) наш­ла 11 кри­тичес­ких уяз­вимос­тей, 29 — с высокой сте­пенью потен­циаль­ной опас­ности, 13 — сред­ней кри­тич­ности и 2 — нек­ритич­ных.

За под­робный баг-репорт взлом­щики получи­ли от Apple воз­награж­дение в раз­мере 288 500 дол­ларов США.

Взлом DELMIA Apriso

Про­щупы­вая свя­зан­ные с Apple домены, которых, к сло­ву, боль­ше семи тысяч, хакеры нат­кну­лись на веб-при­ложе­ние DELMIA Apriso, раз­личные вер­сии которо­го пред­назна­чены для управле­ния про­изводс­твен­ными про­цес­сами и скла­дом готовой про­дук­ции. Это при­ложе­ние не при­над­лежит Apple, но исполь­зует­ся для дис­три­буции изде­лий «яблочной» кор­порации.

Ис­сле­дова­тели нем­ного поковы­ряли фор­му аутен­тифика­ции и механизм сбро­са пароля поль­зовате­ля DELMIA Apriso и в какой-то момент с удив­лени­ем обна­ружи­ли, что они авто­ризо­ваны в сис­теме с име­нем Apple No Password User.

Вдум­чивое изу­чение это­го ано­маль­ного явле­ния показа­ло, что в инфраструк­туре DELMIA Apriso для исполь­зования фун­кций на опре­делен­ных веб-стра­ницах поль­зователь дол­жен быть обя­затель­но авто­ризо­ван в сис­теме, и сброс пароля — одна из таких фун­кций. Пос­коль­ку сама задача вос­ста­новить забытый пароль логичес­ки про­тиво­речит воз­можнос­ти авто­риза­ции, раз­работ­чики соору­дили кос­тыль в виде обще­дос­тупной учет­ки «поль­зовате­ля Apple без пароля», который вро­де и залоги­нен в сис­теме, а вро­де и нет. К сожале­нию, эта «псев­доучет­ка» никаких при­виле­гий юзе­ру не давала.

Ха­керы отпра­вили HTTP-зап­рос на эндпой­нт OAuth, что­бы сге­нери­ровать токен Bearer для изу­чения API веб-при­ложе­ния. И это неожи­дан­но сра­бота­ло! Тех­ничес­кая учет­ная запись, все раз­решения которой дол­жны были сво­дить­ся к воз­можнос­ти сбро­сить пароль, смог­ла сге­нери­ровать Bearer c дос­тупом к вер­сии API веб-при­ложе­ния. Оста­лось толь­ко нагуг­лить докумен­тацию к это­му самому API.

Ку­рение ману­алов поз­волило Кар­ри и ком­пании обна­ружить более 5000 вызовов API, для которых не тре­бова­лась допол­нитель­ная авто­риза­ция за исклю­чени­ем уже получен­ного токена. Мно­гие из этих вызовов были для взлом­щиков бес­полез­ны, но некото­рые давали воз­можность, нап­ример, менять даты зар­плат сот­рудни­ков, соз­давать и отме­нять отправ­ку товаров со скла­да, редак­тировать информа­цию об инвента­риза­ции и выпол­нять сот­ни дру­гих склад­ских опе­раций.

Нап­ример, одна из фун­кций API име­ет крас­норечи­вое наз­вание APL_CreateEmployee_SO. Мож­но отпра­вить при­ложе­нию GET-зап­рос на выпол­нение опе­рации:

И получить от него HTTP-отклик в сле­дующем фор­мате: