Iată cum funcționează lacuna în achizițiile în aplicație

Așa funcționează lacuna în achizițiile în aplicație (c) IDG/Apple

confirmare achiziției

Un hacker rus a găsit o gaură în App Store acum câteva săptămâni, iar funcțiile plătite în aplicație puteau fi descărcate gratuit.

Hackerul rus Alexey Borodin și-a pus propriul server online cu un serviciu de achiziție în aplicație. Utilizatorii au fost nevoiți să descarce certificatele furnizate și să le instaleze pe iPhone, iar calea către magazinul gratuit era deschisă. Apple a reacționat surprinzător de repede la vulnerabilitate și a lansat un instrument pentru dezvoltatori și o actualizare pentru iOS 6 după câteva zile. Producătorul de iPhone susține că decalajul va fi închis definitiv de la iOS 6.

Hackerul a vorbit din nou în urmă cu câteva zile și a publicat instrucțiuni pas cu pas pentru hack, inclusiv codul pentru server. Informațiile sunt acum inofensive, deoarece hack-ul nu mai funcționează, dar oferă câteva informații interesante despre comunicarea dintre serverele Apple, serverele dezvoltatorilor și iPhone.

Pentru o achiziție în aplicație, un iPhone comunică de mai multe ori cu serverele Apple. Prin intermediul unei cereri către serverul suplimentar iTunes (buy.itunes.apple.com), iPhone transmite informații din aplicație, cum ar fi ID-ul aplicației, numărul versiunii, producătorul și GUID/UUID-ul iPhone-ului (identificator unic global sau identificator unic universal) . Răspunsul este binecunoscuta confirmare a achiziției „Vrei să cumperi aplicația X cu Y euro?” Ceea ce pare a fi o întrebare cu două butoane pe ecranul iPhone are semnificativ mai mulți parametri într-o formă detaliată. De exemplu, ID-ul unic iTunes Adam - un număr de identificare din opt sau nouă cifre pentru toate aplicațiile din iTunes - precum și prețul, numărul versiunii, producătorul și altele asemenea. Borodin raportează că majoritatea aplicațiilor au reușit să ignore ID-ul iTunes în timpul testelor sale. Cu alte cuvinte, cererea de confirmare a achiziției de la iTunes conține aproape aceleași informații pe care iPhone le-a trimis deja serverului. Noile informații precum ID-ul Adam sunt pur și simplu ignorate.

Următorul pas în achiziție: utilizatorul trimite confirmarea către iTunes atingând butonul „Cumpărați”. App Store solicită autorizarea de fiecare dată când o aplicație este descărcată. Cu această autorizație, potrivit lui Borodin, datele confidențiale, cum ar fi ID-ul Apple și parola, au fost trimise de pe iPhone într-un fișier plist necriptat. Teoretic, se deschide un alt decalaj de securitate aici: Deoarece transferul de date între iPhone și App Store funcționează în cea mai mare parte fără fir, este destul de ușor pentru infractori să obțină datele sensibile de acces la un moment dat.

informatii cont

appleId apleid
copil copil 0
abordare

Nume Nume
numele de familie Nume de familie
parolaToken Jeton de parolă (valabil 15 minute)
jeton clearToken (valabil 15 minute

dsPersonId ID-ul tau
creditDisplay

creditBalance 1311811 (credit iTunes)
freeSongBalance 1311811 (probabil numărul de piese pentru iTunes Match)

Certificat de validare a vulnerabilității

În următorii pași, App Store verifică achiziția și dacă aplicația a ajuns pe iPhone. Pentru a face acest lucru, el trimite o confirmare de cumpărare digitală cu informații generale despre aplicație, precum și informații suplimentare despre data achiziției, numărul tranzacției și un certificat de validare pentru achiziție. În certificatul de validare, Borodin a descoperit vulnerabilitatea critică pe care a folosit-o pentru hack. În versiunea anterioară, App Store a livrat întregul pachet de fișiere, adică certificatul împreună cu cheia. Aspectul certificatului arată astfel:

VERSIUNEA DE PRIMITE | SEMNATURĂ | MĂRIMEA CERTIFICATULUI CERTIFICAT
1 octet 128 4 octeți ...

Cu metodele obișnuite de criptare, cum ar fi e-mailurile, expeditorul trimite scrisorile electronice cu certificatul emis. Destinatarul are o cheie privată pentru decriptare. Dacă certificatul și cheia se potrivesc, destinatarul primește datele într-o formă lizibilă. Infractorii cu greu au posibilitatea de a decoda datele fără cheia validă, chiar dacă au reușit să acceseze datele brute.

Borodin a exploatat această eroare logică de la Apple: Setările DNS pentru iPhone pe care le-a pus la dispoziție nu au fost redirecționate către App Store, ci către un alt server. Serverul proxy a emis certificatele falsificate pentru App Store cu aceeași structură ca un certificat original. Deoarece cheile de pe iPhone provin și de la hacker, certificatul și cheia se potrivesc în mod natural, iar App Store a considerat că achiziția este valabilă.

De asemenea, hackerul oferă recomandări cu privire la modul în care dezvoltatorii de aplicații pot evita astfel de intruziuni în viitor. Pe de o parte, Apple furnizează așa-numitul controler de verificare - o linie suplimentară în codul de confirmare a achiziției. În plus, Borodin recomandă verificarea tuturor informațiilor din confirmarea achiziției, inclusiv ID-ul iTunes. Aplicațiile, a căror achiziție au fost verificate și pe serverul de dezvoltator extern cu propriile certificate și chei, nu au fost afectate de hack. Aceasta este, de asemenea, o protecție eficientă împotriva acestor spargeri.