Hack maakt in-app aankopen op iOS gratis
Een Russische hacker heeft een man-in-the-middle aanval gemaakt om de betaling van in-app aankopen na te maken. Daardoor lijkt het alsof de gebruiker betaalt, maar in feite gaat er niets van zijn iTunes-saldo af. De hack werkt zonder jailbreak.
De hack werkt niet in alle apps met in-app aankopen, constateert 9to5 Mac. Sommige apps gebruiken een validatie voor in-app aankopen, waardoor de fraude niet kan plaatsvinden. De hack, die is ontdekt door een Russische ontwikkelaar, vereist dat de gebruiker enkele profielen installeert en dns-instellingen wijzigt in de verbindingsinstellingen.
Een jailbreak is niet vereist; de ontwikkelaar toont de hack op een iPhone 4S met iOS 6, waarvoor nog geen jailbreak publiekelijk beschikbaar is. De hack zou ook moeten werken op een iPad of iPod touch, met iOS-versies 3.x tot 6.0.
De Russische ontwikkelaar heeft het proces van in-app betalingen reverse engineered om de hack mogelijk te maken. In de interface is te zien dat bij een in-app aankoop een popup verschijnt van de ontwikkelaar, waarbij op Like gedrukt moet worden om de aankoop te bevestigen.
Apple heeft nog niet gereageerd op deze kraak van zijn in-app aankoopproces. Het lijkt erop dat in-app aankopen bewaard blijven als de hack van het toestel wordt gehaald of aankopen op een ander iOS-toestel opnieuw gedownload worden. Het is niet aan te raden om de hack zelf uit te voeren: het gaat om een man-in-the-middle-proces en het is onduidelijk of de ontwikkelaar kwade bijbedoelingen heeft en op deze manier Apple ID-wachtwoorden van gebruikers kan onderscheppen.
Reacties (71)
Ja, als je als developer niet controleert of de betaling is gedaan, dan is het ook wel een beetje je eigen schuld hè.
Grote kans dat ze dit wel doen maar dus alleen vanuit i-tunes die op dat moment onetrouwbaar is geworden. Een aantal developers doen blikkbaar een eige. Controle dmv een eigen server
Via een jailbreak is dit al tijden mogelijk, de meeste ontwikkelaars hebben het nu wel in de gaten en verifiëren of de aankoop ook wel echt is binnen gekomen.
Klopt inderdaad, heb maanden geleden al eens een jailbreak geprobeerd die dit ook mogelijk maakte, maar dan zonder ingewikkelde poespas.
Het komt erop neer dat in-app aankopen voor apps die GEEN verificatie uitvoeren op een server gewoon lokaal te activeren zijn. Dit is bij schrikbarend veel apps nog steeds het geval. Een behoorlijke beveiligingsblunder als je het mij vraagt.
Het komt erop neer dat in-app aankopen voor apps die GEEN verificatie uitvoeren op een server gewoon lokaal te activeren zijn. Dit is bij schrikbarend veel apps nog steeds het geval. Een behoorlijke beveiligingsblunder als je het mij vraagt.
Daarnaast is het niet aan te raden om gebruik te maken van deze hack! Je persoonlijke gegevens, mogelijk inclusief creditcard gegevens, worden onderschept op de server van deze persoon (want zo zit de hack in elkaar), maar niemand weet wat of hij deze gegevens bijvoorbeeld opslaat (en er misbruik van maakt)!
De hack waar hij het over heeft is een andere hack en kan alleen MET jailbreak.
Ik denk dat het feit dat zo weinig devs er op checken, zelfs grote devs als konami en square-enix er meer mee te maken heeft dat het:
Ik denk dat het feit dat zo weinig devs er op checken, zelfs grote devs als konami en square-enix er meer mee te maken heeft dat het:
- Geld en moeite kost om het te implementeren.
- Pirates gonna pirate, doen ze het zo niet zoeken ze wel een andere manier.
Hij? - Er staat toch echt:De hack waar hij het over heeft is een andere hack en kan alleen MET jailbreak.
De hack werkt zonder jailbreak
Inderdaad al lange tijd mogelijk met iAP Cracker (xSellize)
Maar als developer ben je niet verantwoordelijk voor de betaling; je roept een API van Apple aan die voor de huidige gebruiker afrekent, en je app krijgt een seintje terug van Apple indien het voltooid is. Net zoals het kopen van apps zelf heb je als developer geen invloed over de betaling en de validatie daarvan.
edit: disclaimer: bovenstaand is een aanname gebaseerd op weinig ervaring en aldus mogelijk fout.
edit: disclaimer: bovenstaand is een aanname gebaseerd op weinig ervaring en aldus mogelijk fout.
[Reactie gewijzigd door YopY op vrijdag 13 juli 2012 19:00]
Het probleem is juist dat ontwikkelaars niet om dit seintje vragen, waardoor verschillende tweaks dit mogelijk maken.
Dat seintje terug komt nou juist van "the man in the middle".
Even voor de volledigheid, aangezien dit bericht al wat ouder is. Je kunt als developer nog een extra check doen of de transactie gelidg is. Deze beschrijft apple zelfs in de documentatie.
Je Stuurt de "receipt", welke in dit geval dus nep is, naar je eigen server. Jouw server stuurt deze receipt naar apple en vraagt of hij geldig is. Daarna stuurt jouw server een response terug dat de betaling geldig is.
Ik snap dat een hacker jouw server ook kan spoofen, maargoed das weer een extra stap aan werk dat ze moeten doen.
Je Stuurt de "receipt", welke in dit geval dus nep is, naar je eigen server. Jouw server stuurt deze receipt naar apple en vraagt of hij geldig is. Daarna stuurt jouw server een response terug dat de betaling geldig is.
Ik snap dat een hacker jouw server ook kan spoofen, maargoed das weer een extra stap aan werk dat ze moeten doen.
Hmm... Zou dit kunnen betekenen dat certificaten van Apple gecompromitteerd zijn? Ik neem toch aan dat de communicatie met de appstore versleuteld is...
Nee, dat is hier niet uit af te leiden.
De goedkeuring zou bijvoorbeeld onversleuteld kunnen zijn.
Daarnaast als je proxyt kan kan ook verisign certificaten naar je eigen server laten wijzen; zoals in het filmpje eigenlijk al getoond werd.
De goedkeuring zou bijvoorbeeld onversleuteld kunnen zijn.
Daarnaast als je proxyt kan kan ook verisign certificaten naar je eigen server laten wijzen; zoals in het filmpje eigenlijk al getoond werd.
Je moet inderdaad zoals Eric zegt, gemanipuleerde certificaten (waarschijnlijk neppe Root CAs) installeren, en een proxy gebruiken. Wat je dan hebt, is dat je dan een MIM attack kan uitvoeren. Dit is geen 'OEH IOS HAXX LOL!' situatie, maar gewoon een schoolvoorbeeld MIM attack.
Een systeem moet rekening houden met MIM attacks. Dus het is nog steeds gehacked. Immers zou het niet mogelijk moeten zijn bij een veilig systeem om via een nep certificaat en proxy dit te faken.
Tegen een MIM attack die je zelf opzet op je eigen computer is weinig te doen hoor als externe partij.
Wat je in feite zegt is dat je niet zelf je certificaten op je apparaat mag beheren, want dat is de enige reden dat deze MIMA werkt. Als een fabrikant dat doet krijg je weer huilende mensen die mekkeren over vrijheid en andere zelfbeheer-gerelateerde zaken. Zelfde geldt voor proxy dingen.. je kan het hele proxy verhaal trouwens ook net zo makkelijk op de complete verbinding doen, via wifi en dan AP-side bijv. zodat je op het OS alleen nog maar fake root ca's hoeft te installeren. Een hack zou betekeken dat iets anders gebruikt is dan dat het bedoeld is, maar proxies zijn bedoeld om gegevens door te geven en zelf (root-)CA's installeren is bedoeld om zelf je eigen PKI te kunnen integreren, en dat is ook wat er gedaan wordt, maar dan met malafide bedoelingen.
Nee, waar het om gaat is dat dergelijke bij dergelijke infrastructuur gekeken moet worden naar de issuer van het certificaat, en in zo'n geval alleen vertrouwde certificaten toe te laten. Je kunt best prima zelf certificaten installeren, die je dan vervolgens kan gebruiken voor eigen sites en andere doeleinden. Wat niet zou moeten kunnen is dat jouw certificaten ook bruikbaar zijn als vervanging van officiele certificaten van bekende partijen, want dat is vragen om moeilijkheden. Nu wil je zelf iets hacken, maar het zet ook de weg open naar MIM attacks opgezet door iemand anders met kwade bedoelingen, die het voor elkaar heeft gekregen om een zelfgesigned apple.com certificaat op jouw telefoon te installeren om zo je iTunes betalingen te kunnen onderscheppen.Wat je in feite zegt is dat je niet zelf je certificaten op je apparaat mag beheren, want dat is de enige reden dat deze MIMA werkt
Dat deze man dit publiekelijk beschikbaar maakt. Is hij nu niet strafbaar?
Lijkt me erg sterk.
Waarom zou dit strafbaar zijn?
Waarom zou dit strafbaar zijn?
Het is een vorm van fraude en derhalve een economisch delict, en dat is gewoon strafbaar hoor.
Het is alleen fraude als je het gebruikt, niet als je de tools ter beschikking stelt.
Ik hoop dat jij geen rechten studeert want het faciliteren van het mogelijk maken tot fraude is ook gewoon strafbaar.
Dus de overheid is strafbaar?
Alleen als ie dan dingen doet die volgens DMCA niet mogen, ik dacht dat dat over omzeilen ging op sommige vlakken. Bijv. encryptie of betalingssystemen.
dus die hele dmca is hier niet van toepassing.Een Russische hacker
Precies...zoets geld ook voor PC OS/software....
Je bent daar wettelijk verplicht om een copy van al je data en OS te maken ... ongeacht de hoeveelheid "copy-right" labels aanhangen.
Je bent daar wettelijk verplicht om een copy van al je data en OS te maken ... ongeacht de hoeveelheid "copy-right" labels aanhangen.
Update op de bron:
Update: Commenters have noted that Apple does provide a method for developers to validate receipts for in-app purchases. This is likely why the hack described above does not work with some apps and is something all devs implementing IAP should be taking advantage of.
Lijkt er op dat het dus enkel werkt bij apps die dus die 'validate receipts' niet verwerkt heeft in zijn/haar op, dus niet echt een grote fout in het App-store/betaalsysteem van Apple.
Update: Commenters have noted that Apple does provide a method for developers to validate receipts for in-app purchases. This is likely why the hack described above does not work with some apps and is something all devs implementing IAP should be taking advantage of.
Lijkt er op dat het dus enkel werkt bij apps die dus die 'validate receipts' niet verwerkt heeft in zijn/haar op, dus niet echt een grote fout in het App-store/betaalsysteem van Apple.
Iets waar apple ook nog voor waarschuwt naar developers toe om dat te implementeren. Dit is gewoon eigen schuld dikke bult, apple heeft hier niks mee te maken 
Het relevante stuk uit Apple's Developer documentatie is overigens hier te vinden:
http://developer.apple.co...rifyingStoreReceipts.html
http://developer.apple.co...rifyingStoreReceipts.html
When Store Kit returns a completed purchase to your payment queue observer, the transaction’s transactionReceipt property contains a signed receipt that records all the critical information for the transaction. Your server can post this receipt to the App Store to verify that the receipt is valid and has not been tampered with. Queries transmitted directly to the App Store are sent and received as JSON dictionaries, as defined in RFC 4627.
[Reactie gewijzigd door MacWolf op vrijdag 13 juli 2012 17:26]
Dat je achteraf nog kunt checken of de bataling gedaan is betekend niet dat het geen grote fout is in het betaalsysteem.
Ik ken de specifieke API niet maar als je een klant een aankoop laat doen en je krijgt van iOS terug dat het gelukt is mag je er toch vanuit gaan dat dat zo is zonder het nog te hoeven controleren?
Het is IMHO of een grote bug of domme ontwerpfout in de API. Ik heb zelf ook wel eens in de API van een Payment Service Provider die ik gebruikte voor een product een bug gevonden waardoor de eindgebruiker een testbetaling kon triggeren, was gewoon een fout in de API maar heb lang moeten praten voor ze dat toe wilden geven. Uiteindelijk hebben ze het met een vet lelijke hack "opgelost" omdat ze de API niet meer aan konden passen.
Ik ken de specifieke API niet maar als je een klant een aankoop laat doen en je krijgt van iOS terug dat het gelukt is mag je er toch vanuit gaan dat dat zo is zonder het nog te hoeven controleren?
Het is IMHO of een grote bug of domme ontwerpfout in de API. Ik heb zelf ook wel eens in de API van een Payment Service Provider die ik gebruikte voor een product een bug gevonden waardoor de eindgebruiker een testbetaling kon triggeren, was gewoon een fout in de API maar heb lang moeten praten voor ze dat toe wilden geven. Uiteindelijk hebben ze het met een vet lelijke hack "opgelost" omdat ze de API niet meer aan konden passen.
[Reactie gewijzigd door martijnve op vrijdag 13 juli 2012 17:28]
De Zeus trojan (een MITM attack) heeft wel aangetoond dat dat dus niet zo is.Ik ken de specifieke API niet maar als je een klant een aankoop laat doen en je krijgt van iOS terug dat het gelukt is mag je er toch vanuit gaan dat dat zo is zonder het nog te hoeven controleren?
Controle via een andere kanaal blijft nodig.
Overview of In-App PurchaseIk ken de specifieke API niet maar als je een klant een aankoop laat doen en je krijgt van iOS terug dat het gelukt is mag je er toch vanuit gaan dat dat zo is zonder het nog te hoeven controleren?
Deze methode werkt alleen als de app gebruik maakt van 'Built-in Product Model' voor in app verkopen.
Probleem is op te lossen door de aankoopbewijs te laten verifiëren via een andere/eigen server, maw volgens het 'Server Product Model'
[Reactie gewijzigd door Carbon op vrijdag 13 juli 2012 17:50]
Dit geldt overigens ook voor Paypal. Als een partij daar geen IPN verificatie doet kan je ook betalingen faken.
300 dollar voor een server en domeinnaam? Hij verwacht een hoop traffic vermoed ik.
Apple geeft ook duidelijk aan dat developers hun in-app aankopen moeten laten verifiëren. Dat is hier dan ook beschreven.
Deze truuk houdt dus de app voor de gek, en niet Apple. Het lijkt of er vanaf Apple een "aankoop is okee" bericht terugkomt, terwijl in werkelijkheid Apple er helemaal niet aan te pas is gekomen. Als een app die validatie niet uitvoert, dan denkt hij dus dat de betaling okee is, terwijl dat niet zo is.
De opmerking dat de in-app purchases op een andere telefoon opnieuw gedownload kunnen worden, zal dus ook alleen geldig zijn voor apps die zelf ergens bijhouden of er aankopen gedaan zijn. Als de app de in-app purchases bij Apple checkt, zoals normaliter de bedoeling is, zal hij niks terug krijgen en zal de aankoop dus niet ge-restored kunnen worden.
Kortom: er zijn dus apps die niet goed checken of alles echt van Apple komt. En die zijn dan vatbaar voor deze truuk.
[edit: grammatica]
De opmerking dat de in-app purchases op een andere telefoon opnieuw gedownload kunnen worden, zal dus ook alleen geldig zijn voor apps die zelf ergens bijhouden of er aankopen gedaan zijn. Als de app de in-app purchases bij Apple checkt, zoals normaliter de bedoeling is, zal hij niks terug krijgen en zal de aankoop dus niet ge-restored kunnen worden.
Kortom: er zijn dus apps die niet goed checken of alles echt van Apple komt. En die zijn dan vatbaar voor deze truuk.
[edit: grammatica]
[Reactie gewijzigd door mddd op vrijdag 13 juli 2012 17:26]
Dit is toch wel jammer, aangezien Apple altijd hele goeie bescherming biedt en weinig bugs in iOS heeft.
Het gaat hier ook niet om een bug in iOS. Het gaat erom dat deze apps niet voldoende checken of een aankoop wel echt een valide aankoop is.
Tot nu toe is elke versie gekraakt. En de bescherming komt van de app-screening. Voordat het in de store staat.
In Cydia is al een tijdje een dergelijke hack app te krijgen.
In Cydia is al een tijdje een dergelijke hack app te krijgen.
MET jailbreak is het overigens al heel lang mogelijk met behulp van de cydia app "iAP Cracker. Al zijn er steeds meer apps/games die er een beveiliging voor hebben, veel ontwikkelaars laten daar dus een steek vallen.
Ik heb het eerlijk gezegd zelf ook al eens geprobeerd op deze manier (misschien dat deze hacker het op dezelfde manier doet?):
Een VPN-server op je PC opzetten, met je iPhone met die VPN verbinden en dan via bijvoorbeeld WireShark achterhalen waar een request naartoe gaat. Dan verander je vervolgens zelf in je hosts-bestand of in je DNS-server dat verkeer dat daarheen gaat naar een lokale webpagina gaat die een statuscode o.i.d. teruggeeft dat de betaling gelukt is.
Het is mij helaas niet gelukt, maar ik denk dat het zeer zeker mogelijk is op deze manier.
Iemand interesse om het alsnog te proberen?
Een VPN-server op je PC opzetten, met je iPhone met die VPN verbinden en dan via bijvoorbeeld WireShark achterhalen waar een request naartoe gaat. Dan verander je vervolgens zelf in je hosts-bestand of in je DNS-server dat verkeer dat daarheen gaat naar een lokale webpagina gaat die een statuscode o.i.d. teruggeeft dat de betaling gelukt is.
Het is mij helaas niet gelukt, maar ik denk dat het zeer zeker mogelijk is op deze manier.
Iemand interesse om het alsnog te proberen?
Zou dat de moeite waard zijn dan? Binnen een week ofzo heeft apple toch het lek al gedicht, en moet je misschien alsnog betalen.
Het is eigenlijk niet eens nodig voor Apple om het lek te dichten, het is aan de ontwikkelaars om te controleren of de aankoop echt gebeurt is, Apple heeft dit al voorzien. Er zijn genoeg ontwikkelaars die hier al gebruik van maken en waarbij dit systeem dus niet zal werken.
edit: typo
edit: typo
[Reactie gewijzigd door MClaeys op vrijdag 13 juli 2012 18:19]
Waarom is het niet nodig dat Apple deze lek dicht maakt? Het is de software op zichzelf die hier tekort schiet. Het is een geluk voor sommige die de verificatie gebruiken echter in de basis werkt iOS blijkbaar niet correct gezien deze mogelijkheid. Ik vraag me ook af in hoeverre Apple hiervoor verantwoordelijk kan worden gehouden door ontwikkelaars die hierdoor inkomsten mislopen.
Aan de andere kant kan Apple denk ik ook hierachter komen en de dergelijke gebruikers alsnog een rekening in kaart brengen denkelijk?
---edit---
@wouter1971, ja ik lees het bericht het is enkel niet duidelijk waar deze fout in zit. Je stelt dat dit in de applicatie zit echter een betaling lijkt mij dat deze afgehandelt wordt door een bepaalde Api van.. juist Apple. Verder de confrmatie wederom lijkt me dat dit voortkomt uit een Api van.. Apple.
Nogmaals goed mogelijk dat het inderdaad in de apps zelf zit maar ik maak me sterk dat betalingen worden afgehandelt door de gebruikers met name omdat dit via de AppleStore verloopt. Dus ja ik lees de berichtgevingen echter nergens is duidelijk waar de fout zit.
Overigens is dit hetzelfde voor bv WIndows Mobile daar vinden de betalingen ook via de marketplace plaats. Dit in tegenstelling tot bijvoorbeeld seperate software platformen zoals oa van RIM uit die deze mogelijkheid bied.
Aan de andere kant kan Apple denk ik ook hierachter komen en de dergelijke gebruikers alsnog een rekening in kaart brengen denkelijk?
---edit---
@wouter1971, ja ik lees het bericht het is enkel niet duidelijk waar deze fout in zit. Je stelt dat dit in de applicatie zit echter een betaling lijkt mij dat deze afgehandelt wordt door een bepaalde Api van.. juist Apple. Verder de confrmatie wederom lijkt me dat dit voortkomt uit een Api van.. Apple.
Nogmaals goed mogelijk dat het inderdaad in de apps zelf zit maar ik maak me sterk dat betalingen worden afgehandelt door de gebruikers met name omdat dit via de AppleStore verloopt. Dus ja ik lees de berichtgevingen echter nergens is duidelijk waar de fout zit.
Overigens is dit hetzelfde voor bv WIndows Mobile daar vinden de betalingen ook via de marketplace plaats. Dit in tegenstelling tot bijvoorbeeld seperate software platformen zoals oa van RIM uit die deze mogelijkheid bied.
[Reactie gewijzigd door n4m3l355 op vrijdag 13 juli 2012 19:57]
Lees jij wel als je ergens op reageert? De fout zit in de apps en niet in iOS!
Dat is hetzelfde als een applicatie in Windows die een fout maakt en dat je zegt dat Microsoft even aan de slag moet want het zit in de "software".
---edit---
Het gaat erom of de app maker de api op de juiste manier gebruikt om verificatie van de betaling te krijgen, of dat hij deze omzeilt en de klant geloofd op zijn blauwe ogen.
Dat probleem kan je niet Apple toeschrijven maar de app makers.
Dat is hetzelfde als een applicatie in Windows die een fout maakt en dat je zegt dat Microsoft even aan de slag moet want het zit in de "software".
---edit---
Het gaat erom of de app maker de api op de juiste manier gebruikt om verificatie van de betaling te krijgen, of dat hij deze omzeilt en de klant geloofd op zijn blauwe ogen.
Dat probleem kan je niet Apple toeschrijven maar de app makers.
[Reactie gewijzigd door wouter1971 op vrijdag 13 juli 2012 20:33]
het is geen bug, dus moet er ook niks gerepareerd worden
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Prijzen
Apple iPhone 4S 16GB Zwart
- Apple iPhone 4S 16GB Zwart
- Apple iPad 2 Wi-Fi 16GB Zwart
- Apple iPhone 4 8GB Zwart
- Apple iPhone 4S 16GB Wit
- Apple iPhone 4 16GB Zwart
- Apple iPad WiFi (voorjaar 2012) 16GB Zwart
- Apple iPhone 4 8GB Wit
- Apple iPad 2 Wi-Fi 16GB Wit
- Apple iPod Touch V4 16GB Zwart
- Apple iPhone 4S 32GB Zwart
Vraag & aanbod
-
Apple iPod Touch V4 32GB Zwart
Amsterdam, € 99,-
-
Purmerend, € 270,-
-
Swalmen, € 250,-
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
