Hackers omzeilen betaaloptie iPad-publicaties met simpele truc

Italiaanse hackers hebben een methode gepubliceerd om op een iPad kosteloos digitale kranten en tijdschriften op te halen. Voor het uitvoeren van de 'hack' zou slechts een kleine aanpassing aan een configuratiebestand nodig zijn.

Om gratis digitale iPad-publicaties binnen te halen, is een aanpassing aan een bestand met de extensie '.plist' nodig. Door het veld 'purchasable' te veranderen in 'viewable' kan een titel worden binnengehaald. Deze aanpassing is mogelijk door de iPad aan een pc te hangen en het configuratiebestand in een teksteditor te openen.

Als het aangepaste bestand wordt teruggeplaatst, verandert de knop in de 'aanschaf-app' van de desbetreffende titel van 'buy' in 'download'. Zo kunnen onder andere Wired en een aantal Amerikaanse en Italiaanse kranten zonder kosten worden opgehaald.

Adobe, fabrikant van de Digital Content Viewer die voor het ophalen van de titels wordt toegepast, laat aan The Huffington Post weten dat de truc voor 'gevorderde gebruikers' inderdaad werkt. De softwareontwikkelaar zou op 8 oktober een fix uitbrengen, maar de truc zou vooralsnog steeds werken.

Reacties (110)

[gnimmeL_kraD]

Ik noem dit niet echt een truck voor gevorderden. Volgens mij is hier een heel simpel scriptje voor te maken zodat iedereen het kan. Wel grappig hoe men er iedere keer weer achter probeerd te komen hoe bepaalde beveiligingen (niet) werken.

[damaster]

Ik zie het als positief, blijven proberen
Word alles steeds beter/meer beveiligd en worden er steeds weer van deze trucks "uitgevonden"

oftewel : heen en weer spel

[Reactie gewijzigd door damaster op 23 juli 2024 01:32]

[Brummetje]

Ben het inderdaad met je eens... er zullen altijd fouten zijn in de beveiliging en dat mensen die proberen to doorbreken is dan alleen maar goed zodat het beter kan worden gemaakt.

Maar, deze fout is best wel slordig om iets op te slaan als plain text.

[latka]

De fout die hier gemaakt is komt uit 1970... niet zozeer gebrek aan encrpytie alswel volledig vertrouwen op een client die niet gecompromiteerd is. Mag ik hieruit afleiden dat de beveiliging de komende paar jaar steeds minder goed wordt (zie ook het recente HDCP drama wat al voor de release voorspeld gebroken kon worden).

[hiostu]

ja, maar dat moet 1 enkele keer gedaan worden. Niet bij elke nieuwe implementatie weer de oude bekende problemen van andere implementaties toevoegen.

[kozue]

Ik heb juist helemaal niet het idee dat alles steeds beter beveiligd wordt. Als ik dit zo lees is het gemaakt door een of andere kluns met 0 besef van security.

[icyx]

Precies. Meer dan het volgende is er immers niet nodig:
sed -i 's/purchasable/viewable/' /mnt/iPad/etc/ereader.conf (of whatever het pad is). Voor gevorderde gebruikers noemen ze dat

[.oisyn]

Ik noem dit niet echt een truck voor gevorderden

Idd. Eerder een blunder door amateurs. Welke lapswans snapt er nou niet dat de check om te kijken of er voor iets betaald moet worden niet op de client, waar iedereen toegang toe heeft, maar op de server gedaan dient te worden!

Feitelijk heb je dus niet eens een iPad nodig om de content te kunnen downloaden. Het is een kwestie van kijken met welke server hij connect en hoe de request eruit ziet, en vervolgens kun je dat vanaf elke willekeurige machine herhalen.

[Reactie gewijzigd door .oisyn op 23 juli 2024 01:32]

[Anoniem: 153555]

Amateurs inderdaad. Hoe kun je nu een beveiliging laten afhangen van settings in een configuratiebestand op de client? Er dom.

[jacket13]

als ze de settings gewoon hadden gecodeerd was er geen probleem geweest maar nu kan iedereen het omdat ze het open bloot lieten inderdaad

achja kunnen mensen tijdje gratis nieuws lezen.

[latka]

"als ze de settings gewoon hadden gecodeerd was er geen probleem geweest"... helaas geen koelkast gewonnen. Dit kan niet werken, want.... de decryptie sleutel moet ook op de client staan anders kan de app de configfile niet lezen. Security op de client/browser whatever is per definitie onveilig als er geen server-component tegenover staat.

[varkenspester]

Dit valt gemakkelijk op te lossen door een sleutelpaar te gebruiken, bvb door er een certificaat aan te koppelen.
Natuurlijk moet de controle van het bestand+certificaat dan wel op server gebeuren.

Simpelweg ALLE controles die belangrijk zijn voor de veiligheid moéten op server gebeuren. (Anders kan het controlesysteem zelf simpelweg gekraakt worden).

[Sorcerer8472]

Hangt er vanaf wat je met 'gecodeerd' bedoelt. Met binaire switches kun je als hacker ook leuk spelen bijvoorbeeld

[YopY]

Elke codering kan gekraakt worden. Dit soort dingen moeten gewoon niet op de client draaien.

Zie ook: DRM.

[Anoniem: 36355]

Dat is opzich niet eens zo heel erg. Hoewel het natuurlijk eigenlijk op de server hoort. Maar om het dan plain text gewoon recht voor zn raap in een overduidelijk text bestandje te zetten is wel wat slordig.

[kozue]

Dat is wel erg. Een server hoort een client niet blindelings te vertrouwen. Eigenlijk met niets, maar al helemaal niet met dit soort betaaldingen. Het vertrouwen van clients in online games bv leidt tot cheaten. Je kunt het alleen beveiligen aan de serverkant, want alles wat je naar de clientkant uitbesteed is te hacken.

[Jasper Janssen]

De server heeft de betaalgegevens niet. De content wordt gedownload bij bijv Wired, maar de betalingen worden geregeld door Apple.

[CMG]

Transactie ID terug geven bij betaling, bij downloaden transactie ID meesturen, aan wired kant transactie ID valideren bij apple... klaar.

[Gepetto]

Ik noem dit niet echt een truck voor gevorderden.

Om een truck te mogen besturen heb je minstens een c-rijbewijs nodig, dus dat is wel enigszins voor gevorderden.

Om de truc van deze hackers toe te passen hoef je inderdaad niet echt gevorderd te zijn.

[Sorcerer8472]

Tuurlijk is dat wel erg! Als die client reverse-engineered wordt, of als het verkeer afgetapt wordt, dan kun je ook al achter die gegevens komen.

En reken maar dat nu dit bekend is meer mensen zich erop zullen storten om te kijken wat er nog meer lek is aan die store Dit is echt een basicprincipe, dat je zoiets niet clientside regelt... het is ook dé reden waarom allerlei technieken zoals dvd-beveiliging falen, en dat is nog wel een stuk ingewikkelder omdat het om een hele encryptietechniek gaat! Client-side beveiliging werkt gewoon niet uiteindelijk! (de gevallen waar het werkt zijn knappe staaltjes reversed-engineering-beveiliging zou je kunnen zeggen )

[mokkol]

Je kan sommige dingen best op client side oplossen als het goed gebeurt. Een pincode wordt bijvoorbeeld ook op de pas zelf goedgekeurd... De pin staat gewoon opgeslagen in de pas. Maar voor zulke dingen moet het idd server based, want het heeft weinig voordeel, op wat request tijd en rekenkracht na dan.

[Gomez12]

Afaik staat er op een bankpas al jaren geen pin meer.

Magneetstrip wordt afaik tegenwoordig gewoon serverside gecontroleerd, het chip-gedeelte bevat al helemaal geen pin-code meer, maar enkel een stukje encryptiecode waar de pin enkel een onderdeel van is.

[mokkol]

Waarom kan een rabobank internet bankier apparaat een (on)juiste pin aangeven dan?

[Jasper Janssen]

Als het goed is kan het dat ook niet, maar alleen een code die na serverside verificatie niet blijkt te kloppen.

[mokkol]

Het is toch echt dat het offline apparaatje foutieve pincode aangeeft als ik het intoets. Dit vond ik aardig zorgwekkend!

[hackerhater]

De pin staat er inderdaad niet op, wel een hash van de pincode.
Je kan dus wel valideren, maar niet de code terug halen

[mokkol]

Ja dat snap ik Maar zoals hierboven is beschreven, alles is te kraken en de beveiliging staat dus op de chip ipv op de server. Op de server wordt het vast en zeker nogmaals gevalideerd. Maar als je de hash kraak dan heb je de pin.

[Towap]

Fout, ik weet niet of het bij de pinpas het geval is, maar het is wel degelijk mogelijk om een hash te maken waaruit het onmogelijk is om de pin te achterhalen, gewoonweg omdat de noodzakelijke info er niet in vervat zit.

Hetzelfde wordt gebruikt bij encyptie technieken: vaak zijn eer meerdere vertaal keys die toelaten de boodschap te vertalen maar die onvoldoende info bevatten om zelf een andere boodschap met dezelfde code te versleutelen. De sleutel werkt dus enkel voor decryptie en niet voor encryptie. Een gelijkaardig principe wordt vermoedelijk voor pinpassen gebruikt.

[satoer]

En als je een apparaatje maakt dat de hash 9999 keer nummeriek oplopend controleerd? Dan heb je de pincode zo gevonden lijkt mij. Het blokkeren van een pas naar 3 keer foutief pincode invoeren wordt door de randomreader zelf gedaan lijkt mij. En niet door de pas.

[Kahlan]

Toch wel. De chip op de pas valideert en blokkeert zelf. Als je de controle zou kunnen uitvoeren op de magneetstrip dan heb je pas een offline-hack optie

[Towap]

Het hele pin gebeuren valt ofstaat nou eenmaal met de pincode. Uiteraard kan je die brute forcen. Vermoedelijk wordt de hash gewist bij het bereiken van de drie pogingen.

[mae-t.net]

Met de invoering van de chip is de PIN inderdaad daarin komen te staan. De PIN wordt echter niet buiten de chip gecomuniceerd, maar middels een API-call stelt het leesapparaat de vraag aan de chip of de gegeven PIN al dan niet juist is. De chip zelf accepteert die vraag maximaal 3 keer voor een onjuiste PIN, daarna kan je alleen de magneetstrip nog gebruiken.

Of en hoe de PIN in de magneetstrip verwerkt is, weet ik eigenlijk niet, maar ik neem aan dat deze er zelfs niet versleuteld in verwerkt is maar slechts op de server staat.

[Zsub]

Omdat de PIN code al versleuteld op de pas staat. Dat apparaat bevat het algoritme om de ingevoerde code te versleutelen. Komen die twee niet overeen heb je blijkbaar een foute code ingevoerd.

Ok, ik geloof dat ik spuit 11 tot een nieuwe hoogte heb verheven...

[Reactie gewijzigd door Zsub op 23 juli 2024 01:32]

[MSalters]

Omdat de chip op de pas controleert of jouw PIN correct is. Daarvoor hoeft de PIN zelf niet op de pas te staan. Zo zou er in theorie ook de MD5 hash van jouw PIN op kunnen staan.

[Anoniem: 202034]

Leuk zo'n guess sessie van techneuten.
Wat ben ik blij dat er maar 14 personen binnen Equens(Interpay) Nederland gedeeltelijk weten hoe dit stappenprotocol werkt. Het protocol is ook niet omkeerbaar (hogere wiskunde) en bevat random elementen waardoor zelfs de grondlegger van het stappenprotocol het niet kan achterhalen. Klinkt misschien raar, maar toch is dat waar. Er zit wel een kleine zwakte in, maar als je ziet wat je daarvoor moet doen, durft ik te stellen dat het zo goed als onmogelijk is.
Maar laat ik een ding verklappen, de readers zijn universeel en doen alleen controles en ja bij 3 foutpogingen locken alle lezers wereldwijd ongeacht waar ze in zijn gebouwd.
En de belangrijktste misschien , nee er zit geen pincode in de pas opgeslagen, iets wat ik zovaak hoor en als ik mensen ff prikkel zeggen ze ook nee nu je het zegt...jullie denken veel te moeilijk, waarschijnlijk kennen jullie wel de basis versleutelingstecnieken als 9-proof e.d. maar voor dit stappenprotocol gelden dan wel wat complexere formules en wat extra controles, waardoor de kans dat het gekraakt wordt relatief klein is.
Er wordt op dit moment overigens wel volop gewerkt aan een nieuw protocol, vanwege de toenemende rekenkracht e.d. Universiteit van Heidelberg heeft een paar leuke ideeen aangeleverd die wel eens spraakmakend zouden kunnen worden de komende jaren..waardoor de veiligheid van veel producten beter gewaarborgd kan worden, maar ja 10 ontwikkelaars tegen de rest van de wereld is geen gemakkelijke wedstrijd, zeker als je weet dat de andere kant vaak nog veel meer geld heeft....

[Anoniem: 34095]

zit heel android met z'n market niet op dezelfde manier in elkaar ?

[cPT.cAPSLOCK]

Nee - Hier wordt gecontroleerd of jou google account al betaald heeft voor de applicatie, op de server dus.

Stukken lastiger te kraken, if not praktisch onmogelijk.

voor de fanboystempel op deze post komt:
Zelf een WindowsMobile (DONT HURT ME) gebruiker die WP7 overweegt zodra mn abbonement afloopt, afhankelijk van het aanbod van WP7, BlackBerry en Android tegen maart / april.

[antiekeradio]

nee toch?

en pas als je hiervoor een voorbeeld kunt geven waaruit blijkt dat de beveiliging van de android market écht een zelfde soort "beveiligingsmechanisme" betreft, is de opmerking niet totaal offtopic.

[Yakotb]

Als je een custom ROM op je andriod-foon zet (waardoor alle instellingen verloren gaan) gaat Android Market vrolijk weer alle apps downloaden die voorheen op het originele OS geïnstalleerd waren.

Dus nee het wordt op de server gecheckt.

[Anoniem: 175233]

Totaal niet vergelijkbaar. Het onzichtbaar maken van een share is géén security maatregel. De security wordt immers geregeld door de share en NTFS rechten.

Die optie om de share onzichtbaar te maken is niet wezenlijk anders dan de hidden-flag op een bestand. En daar gaan we toch ook niet over kankeren? Optie om zaken (on)zichtbaar te maken zijn puur voor het meer overzichtelijk maken van je shares/folder/bestanden etc. En dat mag gerust op de client gebeuren.

[i-chat]

tja en dan vanuit linux gewoon lekker door de shares heen bladeren, trouwens wil je niet weten hoeveel systeembeheerders shares zelfs nu nog alleen verbergen en niet beveiligen.. verschrikkelijk gewoon

[olderchurch]

http://www.petri.co.il/disable_administrative_shares.htm

[jw_moonshine]

Als je tune-up utilities gebruikt, geeft die bij een computer check gelijk de waarschuwing dat die shares aan staan, en dat tuneup ze uit kan zetten.
Zo moeilijk zal het dus wel niet zijn

[.oisyn]

Leuk, al die mensen vroeger zonder wachtwoord

Als een account geen wachtwoord heeft kun je 'm ook niet gebruiken om vanaf het netwerk mee in te loggen.

[hostler]

Dus ze gaan het ook niet oplossen, binnenkort tenminste...? Dat vind ik echt een slechte zaak.

[Anoniem: 364281]

volgens de tekst moet het al opgelost zijn 8 oktober in het verleden en in het heden is het toch 12 oktober !!

[Anoniem: 315662]

"maar de truc zou vooralsnog steeds werken." even een paar woorden meer lezen?!!

[kozue]

Hangt er van af van wiens kant je het bekijkt. Vanuit de consument is het een goede zaak

[Cergorach]

Voor de consument ook niet, want dit is niet meer dan de boel 'hacken' en weet jij welke consequenties Apple daar tegen over zet? Account geblokkeerd? Of worden de betreffende publicaties op een later tijdstip alsnog in rekening gebracht? Wordt er aangifte van diefstal gedaan (of copyright schending)? Omdat je toevallig via de achterdeur naar buiten kan in een winkel, betekent nog niet dat je zonder consequenties de kassa kan ontwijken met je boek/krant/tijdschrift...

[curumir]

Hangt van je wereldbeeld af; voor de egoïstische consument wel, maar als je verder kijkt dan je neus lang is en morgen ook een tijdschrift of krant wil is een redelijke vergoeding zo gek nog niet.

[arjankoole]

dat zullen de klanten van Adobe zeker met je eens zijn.

[fuqua]

maar werkt dit ook voor de iphone en ipod dan ? of echt alleen ipad ?

[arjankoole]

maar werkt dit ook voor de iphone en ipod dan ? of echt alleen ipad ?

Apps die leunen op dit platform van adobe zijn er (voor zover ik weet) alleen voor de iPad.

[Joostdegrote]

Whahah, Ik voel iemand aankomen die het gaat uitproberen (of in iedergeval wou proberen op zijn iphone/pod)

[Fuwor]

Haha, hier geprobeerd met de Wired-app. En 't werkt inderdaad. Nu inmiddels weer instellingen teruggezet...

[Joostdegrote]

Toch goed dat je dan alsnog zo'n brave jongen bent om het terug te zetten. En was het daadwerkelijk zo makelijk als het lijkt? Ben nu wel erg nieuwsgierig

[Fuwor]

Het is inderdaad erg makkelijk.

Juiste bestand opzoeken in iPhone Explorer onder de map van de app, value van een uitgave op 'viewable' zetten (om precies te zijn de key 'state'). Hierna de uitgave van een magazine verwijderen in de app, en deze opnieuw downloaden.

Als je de values hebt veranderd is een uitgave van de Wired app al gelijk 'viewable', zonder dat je deze eigenlijk hebt gedownload. Hierom moet je dus eerst de uitgave verwijderen en deze opnieuw downloaden. Hierna werkt alles prima!

Weet niet of dit überhaupt wel besproken mag worden op T.net?

[Reactie gewijzigd door Fuwor op 23 juli 2024 01:32]

[RoelJewel]

nevermind: werkt idd perfect .

[Reactie gewijzigd door RoelJewel op 23 juli 2024 01:32]

[Jasper Janssen]

Ik kan het niet testen, want ik heb alle issues van Wired al gewoon gekocht

[Keypunchie]

Zo, dat is nogal suf. Een "plist" is niks anders dan een MacOS preferences-file. Daar is niet zoveel geavanceerds aan.

Je wilt toch iets van server-side authenticatie voordat je iets laat downloaden, dat laat je toch niet alleen aan de client-zijde gebeuren?

[MsG]

Volgens mij gebeurt dat bij Apple inderdaad niet serverside. Ik ken diverse mensen die met illegale niet-echt aangekochte apps wel reviews konden plaatsen in de AppStore.

[Anoniem: 66451]

Het gaat over een Adobe applicatie niet over Apple software.
Reviews plaatsen lijkt me overigens niet heel schadelijk voor de ontwikkelaars (i.t.t. 'illegale niet-echt aangekochte apps').

[grapefruit]

Volgens mij heb je voor het bewerken van .plist bestanden wel een jailbreak nodig en SSH toegang. Ook niet echt 'gevorderd' maar toch de moeite om het even te vermelden.

[Lauwes]

Dit is mogelijk zonder een jailbrake! Je hebt er wel een programmaatje op de pc voor nodig (bv iPhone Explorer) om de files te kunnen zien.

[Jasper Janssen]

De applicatie plists staan als het goed is niet op het stuk van de disk die zichtbaar is op de pc.

[Rickth64]

Gaat dit ook met andere in-app purchases?

[Fuwor]

Volgens mij alleen met apps die dit framework van Adobe gebruiken.

[matthijst]

Werkt niet meeer volgens mij, tenminste, niet als je Wired nu installeert?
Zie op internet dat ze v1.0.0 van de plist gebruiken, krijg 1.1.0 gedownload.

[Fuwor]

Hier werkt het gewoon. Zie ook mijn andere comment hierboven.

[edie]

Altijd handig om dergelijke controles ook aan de server kant te doen. Om het alleen client-side te doen, vraag je om problemen.

[EnigmaNL]

@hostler "De softwareontwikkelaar zou op 8 oktober een fix uitbrengen, maar de truc zou vooralsnog steeds werken."

[Anoniem: 155467]

Humor. "voor gevorderde gebruikers" Wat zijn tweakers dan? Cutting-edge Professionals? xD