Еве како работи дупката во набавките во апликации
Вака работи дупката при набавки во апликации (в) IDG/Apple
Руски хакер најде дупка во App Store пред неколку недели, а платените функции во апликацијата можеа да се преземат бесплатно.
Рускиот хакер Алексиј Бородин стави сопствен сервер преку Интернет со услуга за купување во апликација. Корисниците требаше само да ги преземат обезбедените сертификати и да ги инсталираат на iPhone и патот до бесплатната продавница беше отворен. Apple реагираше изненадувачки брзо на ранливоста и објави алатка за програмерите и ажурирање за iOS 6 по неколку дена. Производителот на iPhone тврди дека јазот ќе биде трајно затворен од iOS 6.
Хакерот повторно проговори пред неколку дена и објави чекор-по-чекор инструкции за хакерот, вклучувајќи го и кодот за серверот. Информациите сега се безопасни бидејќи хакерот повеќе не работи, но нуди неколку интересни сознанија за комуникацијата помеѓу серверите на Apple, оние на развивачот и iPhone.
За купување во апликација, iPhone комуницира неколку пати со серверите на Apple. Со помош на барање до дополнителниот сервер iTunes (buy.itunes.apple.com), iPhone испраќа информации од апликацијата, како што се ID на апликацијата, број на верзија, производител и GUID/UUID на iPhone (Глобално уникатен идентификатор или универзално уникатен идентификатор) . Одговорот е добро позната потврда за набавка „Дали сакате да ја купите апликацијата X за Y евра?“ Она што изгледа како прашање со две копчиња на екранот на iPhone има значително повеќе параметри во посочена форма. На пример, единствениот iTunes Adam ID - осум или девет цифрен идентификациски број за сите апликации во iTunes - како и цената, бројот на верзијата, производителот и слично. Бородин известува дека во неговите тестови, повеќето апликации успеале да го игнорираат ID-то на iTunes. Со други зборови, барањето за потврда за купување од iTunes ги содржи скоро истите информации што iPhone веќе ги испратил до серверот. Новите информации како ID на Адам едноставно се игнорираат.
Следниот чекор во процесот на купување: корисникот ја испраќа потврдата до iTunes со потчукнување на копчето "Купи". App Store бара овластување секој пат кога ќе се преземе апликација. За време на ова овластување, според Бородин, од iPhone-от биле испратени доверливи податоци како што се Apple ID и лозинка во некриптирана plist-датотека. Теоретски, тука се отвора уште еден безбедносен јаз: Бидејќи преносот на податоци помеѓу iPhone и App Store претежно работи безжично, за криминалците е прилично лесно да ги добијат чувствителните податоци за пристап во одредено време.
сметкаИнфо
јаболкоАплеид
дете на сметка 0
адреса
име Име
презиме Презиме
лозинка Токен за лозинка (важи 15 минути)
чист токен токен (важи 15 мин
dsPersonId Вашата лична карта
кредитен приказ
кредитен биланс 1311811 (кредит на iTunes)
бесплатен SongBalance 1311811 (веројатно број на песни за iTunes Match)
Сертификат за валидност на ранливост
Во следните неколку чекори, App Store ќе провери набавка и дали апликацијата пристигнала на iPhone. За да го направите ова, тој испраќа дигитална потврда за купување со општи информации за апликацијата, како и дополнителни информации за датумот на купување, бројот на трансакцијата и потврда за потврда за набавката. Во сертификатот за валидација, Бородин ја најде клучната ранливост што ја користеше за хакерот. Во претходната верзија, App Store го испорача целиот пакет датотеки, т.е. сертификатот заедно со клучот. Изгледот на сертификатот изгледа вака:
ВЕРЗИЈА ЗА РЕЦЕПТ | ПОТПИС | Големина на сертификат | СЕРТИФИКАТ
1 бајт 128 4 бајти ...
Со вообичаените методи за криптирање, како што се е-поштата, испраќачот ги испраќа електронските писма со издадениот сертификат. Примачот има приватен клуч за дешифрирање. Ако сертификатот и клучот се совпаѓаат, примачот ги прима податоците во читлива форма. Тешко е за криминалците да ги декодираат податоците без важечкиот клуч, дури и ако успеале да дојдат до необработените податоци.
Бородин ја искористи оваа логична грешка од страна на Apple: Поставките за DNS за iPhone што ги направи достапни не беа пренасочени кон App Store, туку на друг сервер. Прокси-серверот ги издаде фалсификуваните сертификати за App Store со иста структура како и оригиналниот сертификат. Бидејќи клучевите на iPhone исто така доаѓаа од хакерот, сертификатот и клучот природно се совпаѓаа и App Store сметаше дека набавката е валидна.
Хакерот дава и препораки за тоа како развивачите на апликации можат да избегнат вакви упади во иднина. Од една страна, Apple го снабдува она што е познато како Контролор за верификација - дополнителна линија во кодот за потврда за купување. Покрај тоа, Бородин препорачува да се проверат сите информации во потврдата за купување, вклучувајќи го и iTunes ID. Апликациите, чие купување беше проверено и на серверот за надворешен развивач со свои сертификати и клучеви, не беа под влијание на хакирањето. Ова е исто така ефикасна заштита од вакви провали.