December 1, 2021

„Apple“ įsilaužėme 3 mėnesius: štai ką radome

Read Time:8 Minute, 1 Second

Nuo liepos 6 iki spalio 6 dienos aš pats Brettas Buerhausas, Benas Sadeghipouras, Samuelis Erbas ir Tanneras Barnesas dirbo kartu ir įsilaužė į „Apple bug bounty“ programą.

Užsiėmimo metu radome įvairių pažeidžiamumų pagrindinėse jų infrastruktūros dalyse, kurios būtų leidusios užpuolikui visiškai pažeisti tiek klientų, tiek darbuotojų programas, paleisti kirminą, galintį automatiškai perimti aukos „iCloud“ paskyrą, gauti vidinio kodo šaltinį. „Apple“ projektai visiškai pažeidžia „Apple“ naudojamą pramoninės kontrolės sandėlio programinę įrangą ir perima „Apple“ darbuotojų sesijas, turėdami galimybę pasiekti valdymo įrankius ir neskelbtinus išteklius.

Iš viso buvo aptikta 55 pažeidžiamumų su 11 kritinio sunkumo, 29 didelio sunkumo, 13 vidutinio sunkumo ir 2 mažo sunkumo ataskaitomis. Šiuos sunkumus įvertinome apibendrinimo tikslais ir jie priklauso nuo CVSS derinio ir mūsų supratimo apie su verslu susijusį poveikį.

Nuo 2020 m. Spalio 6 d. Didžioji šių išvadų dalis buvo patvirtinta ir įskaityta. Paprastai jos buvo ištaisytos per 1–2 darbo dienas (kai kurios buvo sutvarkytos per 4–6 valandas).

Įvadas

Kažkada apie liepos mėnesį slinkdamas „Twitter“ pastebėjau dalijamą tinklaraščio įrašą, kuriame tyrėjui iš „Apple“ buvo paskirta 100 000 USD už tai, kad jis atrado autentifikavimo apėjimą, kuris leido jiems savavališkai pasiekti bet kurią „Apple“ klientų sąskaitą. Tai nustebino mane, nes anksčiau supratau, kad „Apple“ klaidų programa suteikė tik saugos spragas, turinčias įtakos jų fiziniams produktams, ir neišmokėjo už problemas, turinčias įtakos jų žiniatinklio turtui.

Baigęs straipsnį, greitai atlikau „Google“ paiešką ir radau jų programos puslapį, kuriame išsamiai aprašyta, kad „Apple“ buvo pasirengusi mokėti už pažeidžiamumus, „turinčius didelę įtaką vartotojams“, neatsižvelgiant į tai, ar turtas buvo aiškiai įtrauktas į taikymo sritį.

Tai patraukė mano dėmesį kaip įdomią galimybę ištirti naują programą, kuri, atrodo, buvo plataus masto ir įdomi. Tuo metu aš niekada nedirbau „Apple bug bounty“ programoje, todėl neturėjau jokio supratimo, ko tikėtis, bet nusprendžiau, kodėl nepabandžius laimės ir pamatius, ką galėčiau rasti.

Siekdamas, kad projektas būtų įdomesnis, išsiunčiau keletą pranešimų įsilaužėliams, su kuriais dirbau anksčiau, ir paklausiau, ar jie norėtų dirbti kartu su programa. Nors nebuvo jokių garantijų dėl išmokėjimų ar supratimo apie programos veikimą, visi atsakė taip, ir mes pradėjome įsilaužti į „Apple“.

Žvalgas

Pirmasis „Apple“ įsilaužimo žingsnis buvo išsiaiškinti, į ką iš tikrųjų nukreipti. Tiek Benas, tiek Tanneris čia buvo ekspertai, todėl jie pradėjo aiškintis, kas yra visa „Apple“ nuosavybė, kuri mums prieinama. Visi jų nuskaitymo rezultatai buvo indeksuoti prietaisų skydelyje, kuriame buvo HTTP būsenos kodas, antraštės, atsakymo tekstas ir prieinamų žiniatinklio serverių ekrano kopija įvairiuose „Apple“ priklausančiuose domenuose, į kuriuos turėtume kreiptis per įtraukimą.

Trumpai tariant: „Apple“ infrastruktūra yra didžiulė.

Jiems priklauso visas 17.0.0.0/8 IP diapazonas, apimantis 25 000 žiniatinklio serverių, iš kurių 10 000 yra „Apple.com“, dar 7000 unikalių domenų, o visa tai papildo savo TLD (taškinis obuolys). Mūsų laikas pirmiausia buvo praleistas 17.0.0.0/8 IP diapazone, .apple.com ir .icloud.com, nes būtent ten pasirodė įdomi funkcija.

Surašę visus žiniatinklio serverius, mes pradėjome vykdyti brutalų katalogų prievartą įdomesniems.

Kai kurios neatidėliotinos automatinio nuskaitymo išvados buvo …

  • VPN serveriai, paveikti „Cisco CVE-2020-3452“ vietinio failo skaitymo 1 diena (x22)
  • Nutekėjusio puslapio klaidos pranešime nutekėjo „Spotify“ prieigos raktas

Šių procesų metu gauta informacija buvo naudinga norint suprasti, kaip „Apple“ veikia autorizavimas / autentifikavimas, kokios egzistuoja klientų / darbuotojų programos, kokios integravimo / kūrimo priemonės buvo naudojamos, ir įvairios pastebimos elgsenos, pavyzdžiui, žiniatinklio serveriai, vartojantys tam tikrus slapukus arba nukreipiantys į tam tikras programas.

Baigę visus nuskaitymus ir pajutę, kad apskritai supratome „Apple“ infrastruktūrą, pradėjome taikyti pagal atskirus interneto serverius, kurie instinktyviai jautėsi labiau linkę būti pažeidžiami nei kiti.

Tai prasidėjo išvadų serija, kuri tęsėsi visą mūsų veiklą ir palaipsniui didino supratimą apie „Apple“ programą.

Aptikta pažeidžiamumų

Pažeidžiamumo perrašymai

Negalime rašyti apie visus atrastus pažeidžiamumus, tačiau pateikiame keletą įdomesnių pažeidžiamumų.

  1. Visiškas „Apple Distinguished Educators“ programos kompromisas per autentifikavimą ir autorizaciją
  2. Visiškas „DELMIA Apriso“ programos kompromisas per autentifikavimo aplinkkelį
  3. „Wormable“ saugomi kelių svetainių scenarijų pažeidžiamumai leidžia „Attacker“ pavogti „iCloud“ duomenis modifikuotu el. Pašto adresu
  4. Komandos įpurškimas autoriaus „ePublisher“
  5. Viso atsako SSRF „iCloud“ leidžia „Attacker“ nuskaityti „Apple“ šaltinio kodą
  6. „Nova Admin“ derinimo skydelio prieiga per „REST Error Leak“
  7. AWS slapti raktai per „PhantomJS iTune“ reklamjuostes ir knygos pavadinimą XSS
  8. „Apple eSign“ kaupimasis leidžia „Attacker“ pažeisti įvairius išorinius darbuotojų valdymo įrankius
  9. XML išorinio subjekto apdorojimas aklinam SSRF naudojant „Java Management API“
  10. „GBI Vertica SQL Injection“ ir „Exposed GSF API“
  11. Įvairūs IDOR pažeidžiamumai
  12. Įvairūs „Blind XSS“ pažeidžiamumai

Visiškas „Apple Distinguished Educators“ programos kompromisas per autentifikavimą ir autorizaciją

Viena iš pirmųjų paslaugų, kurias praleidome įsilauždami, buvo „Apple Distinguished Educators“ svetainė. Tai buvo tik kvietimų turintis „Jive“ forumas, kuriame vartotojai galėjo patvirtinti savo „Apple“ paskyrą. Kažkas įdomaus šiame forume buvo tas, kad kai kurios pagrindinės „Jive“ funkcijos, skirtos užsiregistruoti programoje, buvo perkeltos per „Apple“ sukurtą pasirinktinį tarpinės programinės įrangos puslapį, kad būtų galima prijungti jų autentifikavimo sistemą (IDMSA) prie pagrindinio „Jive“ forumo, kuriame paprastai buvo naudojamas vartotojo vardas / slaptažodis .

Tai buvo sukurta tam, kad vartotojai galėtų lengvai naudoti jau turimą „Apple“ paskyrą, kad taptų autentiški forume, ir nereikėtų susidurti su papildoma vartotojo paskyra. Jūs paprasčiausiai naudosite „Prisijungti naudodami„ Apple “ir būsite prisijungę prie forumo.

Nukreipimo puslapis vartotojams, kuriems nebuvo leista prisijungti prie forumo, buvo programų portalas, kuriame pateikėte informaciją apie save, kurią forumo moderatoriai įvertino patvirtinti.

Kai pateikėte paraišką naudotis forumu, pateikėte beveik visas savo paskyros vertes, tarsi įprastai registruotumėtės „Jive“ forume. Tai leistų „Jive“ forumui sužinoti, kas jūs buvote pagal savo IDMSA slapuką, nes jis susiejo jūsų „Apple“ paskyrai priklausantį el. Pašto adresą su forumu.

Viena iš reikšmių, kuri buvo paslėpta programos puslapyje norint užsiregistruoti naudoti forumą, buvo laukas „slaptažodis“ su reikšme „### NETEISINGA #%! 3“. Kai pateikėte paraišką, kurioje buvo jūsų vartotojo vardas, vardas ir pavardė, el. Pašto adresas ir darbdavys, jūs taip pat pateikėte „slaptažodžio“ vertę, kuri tada buvo slapta susieta su jūsų paskyra, gaunama iš paslėpto puslapio įvesties lauko.

<div class="j-form-row">
<input id="password" type="hidden" value="###INvALID#%!3">
<div id="jive-pw-strength">
...

Stebėdami paslėptą numatytojo slaptažodžio lauką, mes nedelsdami sugalvojome rasti būdą, kaip rankiniu būdu autentifikuotis programoje ir pasiekti patvirtintą forumo paskyrą, užuot bandžius prisijungti naudojant „Sign In With Apple“ sistemą. Mes tai ištyrėme, nes slaptažodžiai buvo vienodi kiekvienam iš mūsų atskirose registracijose.

Jei kas nors būtų naudojęsis šia sistema ir egzistuotų funkcionalumas, kurį galėtumėte neautomatiškai patvirtinti, galite tiesiog prisijungti prie jo paskyros naudodami numatytąjį slaptažodį ir visiškai apeiti „Prisijungti naudojant„ Apple “prisijungimą.

Iš greito žvilgsnio neatrodė, kad jūs galėtumėte autentifikuoti rankiniu būdu, tačiau po kelių „Google“ paieškų mes nustatėme „cs_login“ galinį tašką, skirtą prisijungti prie „Jive“ programų vartotojo vardo ir slaptažodžio. Kai rankiniu būdu suformavome bandomąją HTTP užklausą autentifikuoti „Apple Distinguished Developers“ programoje, mes nustatėme, kad ji bandė mus autentifikuoti pateikdama neteisingą slaptažodžio klaidą. Kai naudojome savo sąskaitas, su kuriomis anksčiau kreipėmės, paraiška suklydo ir neleido mums patvirtinti tapatybės, nes dar nebuvo patvirtinti. Jei norėtume patvirtinti, turėtume rasti jau patvirtinto nario vartotojo vardą.

Šiuo metu mes įkėlėme HTTP užklausą į „Burp Suite“ įsibrovėlį ir bandėme sugadinti vartotojo vardus nuo 1 iki 3 simbolių per prisijungimo ir numatytąjį slaptažodį.

Maždaug po dviejų minučių gavome 302 atsakymą, nurodantį sėkmingą prisijungimą prie vartotojo su 3 simbolių vartotojo vardu, naudojant anksčiau nustatytą numatytąjį slaptažodį. Mes buvome! Nuo šio momento mūsų kitas tikslas buvo patvirtinti tapatybę kaip turintiems padidintus leidimus. Mes padarėme keletą prieigos ekrano kopijų ir spustelėjome sąrašą „Vartotojai“, kad pamatytumėte, kurie vartotojai yra administratoriai. Mes prisijungėme prie pirmosios paskyros, kurią pamatėme sąraše, bandydami įrodyti, kad galime pasiekti nuotolinį kodo vykdymą naudodamiesi administravimo funkcijomis, tačiau vis tiek laukė kelios kliūtys.

Bandant naršyti „/ admin /“ („Jive“ administratoriaus pultas) kaip administratoriaus paskyrą, programa nukreipė prisijungti taip, tarsi mes dar nebūtų patvirtinti. Tai buvo keista, nes tai buvo įprastas „Jive“ programos elgesys, ir niekas iš mūsų to anksčiau nepastebėjo. Spėjome, kad „Apple“ apribojo administravimo pultą pagal IP adresą, kad įsitikintų, jog niekada nebuvo visiškai pažeista programa.

Vienas iš pirmųjų dalykų, kuriuos išbandėme, buvo antraštės „X-Forwarded-For“ panaudojimas norint apeiti hipotetinį apribojimą, tačiau, deja, tai nepavyko. Kitas dalykas, kurį mes bandėme, buvo įkelti kitą „/ admin /“ formą, jei programa turėjo tam tikrus kelio juoduosius sąrašus, kad galėtų pasiekti administratoriaus konsolę.

Po vos kelių HTTP užklausų supratome, kad „GET / admin; /“ leis užpuolikui pasiekti administravimo pultą. Mes automatizavome šį apėjimą nustatydami „Burp Suite“ taisyklę, kuri mūsų HTTP užklausose automatiškai pakeitė „GET / POST / admin /“ į „GET / POST / admin; /“.

Kai pagaliau naršėme ir įkėlėme administravimo pultą, iškart buvo aišku, kad kažkas ne taip. Mes neturėjome prieigos prie įprastos funkcijos, kuri parodytų nuotolinį kodo vykdymą (nebuvo nei šablonų, nei įskiepių įkėlimo, nei standartinės administravimo derinimo funkcijos).

Šiuo metu mes nustojome galvoti apie savo buvimo vietą ir supratome, kad paskyra, kurią patvirtinome, gali būti ne „pagrindinis“ programos administratorius. Mes atėjome ir patvirtinome dar 2-3 paskyras, kol galiausiai autentifikavome kaip pagrindinį administratorių ir pamatėme funkciją, kuri leistų nuotoliniu būdu vykdyti kodą.

Užpuolikas galėjo (1) apeiti autentifikavimą rankiniu būdu autentifikuodamas naudodamas paslėptą numatytąją prisijungimo funkciją, tada (2) prieiti prie administravimo pulto siųsdamas modifikuotą HTTP kelią užklausoje ir galiausiai (3) visiškai sugadinti programą naudodamas vieną iš daugelio „keptų RCE“ funkcijų, tokių kaip įskiepių įkėlimas, šablonai ar failų valdymas.

Apskritai tai būtų leidę užpuolikui …

  • Vykdykite savavališkas komandas ade.apple.com žiniatinklio serveryje
  • Pasiekite vidinę LDAP paslaugą, kad galėtumėte valdyti vartotojo abonementus
  • Pasiekite daugumą „Apple“ vidinio tinklo

Šiuo metu mes baigėme ataskaitą ir viską pateikėme.

Visiškas „DELMIA Apriso“ programos kompromisas per autentifikavimo aplinkkelį

Apie tai, apie ką daug galvojome įsilauždami „Apple“, buvo tai, ar jie turi kokių nors prieinamų paslaugų, susijusių su savo produktų gamyba ir platinimu. Kaip paaiškėjo, buvo programa, vadinama „DELMIA Apriso“, kuri buvo trečiosios šalies „Global Manufacturing Suite“, teikianti įvairius sandėlio sprendimus.

Deja, neatrodė, kad technologijai yra daug prieinamos sąveikos, nes „prisijungti“ ir „iš naujo nustatyti slaptažodį“ galite tik iš galimų sąsajų.

Bandžiusi rasti pažeidžiamumą ribotame puslapių skaičiuje, kažkas …

Happy
Happy
0 %
Sad
Sad
0 %
Excited
Excited
0 %
Sleepy
Sleepy
0 %
Angry
Angry
0 %
Surprise
Surprise
0 %

Average Rating

5 Star
0%
4 Star
0%
3 Star
0%
2 Star
0%
1 Star
0%

Parašykite komentarą

El. pašto adresas nebus skelbiamas. Būtini laukeliai pažymėti *

Previous post Kas yra ir kas nėra biofilinis dizainas?
Next post „Google Lens“ leis išmaniųjų telefonų kameroms suprasti, ką jie mato, ir imtis veiksmų – „TechCrunch“