Wachtwoorden iTunes-gebruikers blijken relatief eenvoudig te onderscheppen

De wachtwoorden van iTunes-gebruikers zijn simpel te onderscheppen, ontdekte een Nederlandse beveiligingsonderzoeker. Apple hasht de wachtwoorden niet voordat ze naar de server worden verzonden, en de ssl-verbinding is kwetsbaar voor een man in the middle-aanval.

De wachtwoorden worden onder meer onversleuteld meegezonden bij het kopen van muziek op iTunes, maar ook bij het activeren van nieuwe iOS-apparaten op iTunes. Dat ontdekte beveiligingsonderzoeker Mark Loman van het Nederlandse beveiligingsbedrijf Surfright. Windows-gebruikers zijn kwetsbaar; onder OS X krijgen gebruikers wel een waarschuwing dat het certificaat niet klopt. Apple was niet bereikbaar voor commentaar.

Normaliter zou het niet direct gevolgen moeten hebben dat een wachtwoord onversleuteld wordt verzonden, als de verbinding die wordt gebruikt maar versleuteld is. Een bijkomende kwetsbaarheid is echter dat iTunes de authenticiteit van servercertificaten niet verifieert. Daardoor kan iedereen zich tegenover iTunes voordoen als een server van Apple.

"Dit is een beginnersfout, of met opzet", aldus Loman. "Inlichtingendiensten als de NSA kunnen hierdoor eenvoudig alle communicatie met iCloud onderscheppen." Om de kwetsbaarheid te misbruiken, moet een aanvaller wel de communicatie van een slachtoffer kunnen onderscheppen, bijvoorbeeld met een vervalst wifi-toegangspunt, of de dns-tabel van het slachtoffer kunnen manipuleren.

Verder blijkt het mogelijk om het activatieproces van iOS-apparaten te omzeilen. Dat kan onder meer worden gebruikt om apparaten die wegens diefstal zijn geblokkeerd, toch te activeren. Er bestaat zelfs een dienst die van deze kwetsbaarheid gebruikmaakt om geblokkeerde iOS-apparaten toch te laten activeren. Die dienst maakt eveneens gebruik van het feit dat iTunes servercertificaten niet verifieert.

Beveiligingsonderzoeker Loman vermoedt bovendien dat precies dezelfde kwetsbaarheid tot voor kort in iOS zat; Apple dichtte toen een lek waarvan de beschrijving ongeveer gelijk is aan het probleem dat Loman heeft ontdekt. Apparaten met iOS die niet zijn bijgewerkt, zijn nog steeds kwetsbaar, waarschuwt Loman. Apparaten als de iPad 1 en de iPhone 3G en 3GS, die niet kunnen worden bijgewerkt naar de nieuwste iOS-versie, zijn zelfs voor altijd kwetsbaar.

Reacties (104)

[Phoenix_the_II]

Apple hasht de wachtwoorden niet voordat ze naar de server worden verzonden

Hashen van wachtwoorden voordat ze naar de server verstuurd heeft ook geen zin. Hierdoor wordt de hash het wachtwoord....

Beter dat je gewoon goede beveiligde verbinding opzet alvorens identificatie te versturen.

[Reactie gewijzigd door Phoenix_the_II op 24 juli 2024 01:02]

[Verwijderd]

Hashen heeft inderdaad geen zin, dit heb ik al meerdere malen aan proberen te kaarten bij mijn vorige werkgever maar die geloofden er heilig in dat dit veiliger was.

[watercoolertje]

Nou ja ergens wel, want je wachtwoord op de server (de hash) is dan wel bekend, maar niet het wachtwoord in de hash wat 9/10 doorsnee gebruikers op andere websites ook gebruikt

Dus ja voor je eigen site maakt het niet uit, maar voor de gebruikers (algemene, niet tweakers) wel degelijk!

[Armin]

Client hashen heeft geen zin!

Dat mensen dat denken komt voort uit een verkeerd begrip van de veiligheid (of onveiligheid) van hashen.

1) Een enkelvoudige hash zonder (of zelfs niet unieke) client-side salt zoals voorgesteld is geen beveiliging. Makkelijk te kraken zonder zelfs super computers

2) Servers gebruiken een meervoudige (1000 rounds minimaal) van hashen mét - als ze een beetje nadenken - unieke salt.

Er zijn helaas teveel programeurs die de klep en klepen gehoord hebben en denken dat hashen genoeg is. Dat is het niet.

• Wie ooit zelf een password database moet ontwikkelen, moet NOOIT zelf hashen. Nooit!

Meer moeite voor iets wat waarschijnlijk nog geen paar uur stand houd tegen de gemiddelde Chinese hacker met standaard downloadable tools. Ik zeg meer moeite omdat er prachtge simpele te gebruiken bibliotheken beschikbaar zijn. PBKDF2 is bijvoorbeeld beschikbaar voor Java en C#, en vereist een paar regels code. Minder dan zelf gaan hashen.

C++:
http://msdn.microsoft.com...op/dd433795(v=vs.85).aspx

C#:
http://msdn.microsoft.com...erivebytes(v=vs.110).aspx

Voor C# heeft Microsoft zelfs een volledig gratis sample geschreven:

http://aspnetwebstack.cod...tem.Web.Helpers/Crypto.cs

Alternatieven zoals bcrypt of scrypt zin ook goed mocht je dat liever willen.
Maar ga absoluut NOOIT zelf hobbieen. Zo ontstaan namelijk al die password hacks die je dagelijks leest.

Als je SSL goed geimplementeerd is, is het doorsturen van een password verder geen enkel probleem.

[Verwijderd]

Ergens heeft het wel zin, maar indien die hash onderschept wordt kan er nog steeds mee ingelogd worden.

Dat het wachtwoord niet direct bekend is is inderdaad een goede zaak

[Verwijderd]

Precies!

[arjankoole]

Hashen heeft inderdaad geen zin, dit heb ik al meerdere malen aan proberen te kaarten bij mijn vorige werkgever maar die geloofden er heilig in dat dit veiliger was.

Ik had er een keer eentje die weigerde te geloven dat base64 twee kanten op kan. Leuk een wachtwoorden database met base64 encoded wachtwoorden.

[Macshack]

Sterker nog, het geeft je informatie over hoe eventuele andere hash procedures verlopen binnen een bepaald bedrijf. Want als ik mijn hash kan zien en mijn wachtwoord een aantal keren aanpas om te zien wat voor een hashes er gegenereerd worden weet ik pontentieel meer dan alleen iemands wachtwoord.

Begrip > Kennis.

[watercoolertje]

Je kan ook nog serverside hashen op een compleet andere manier om dat af te vangen...

[Macshack]

Tuurlijk kan dat. Maar het geeft je wel informatie over een hash procedure. Op basis daarvan kun je weer aannames doen en testen. Als hij niet gehashed is kun je helemaal geen aanames doen obv het wachtwoord.

[Verwijderd]

Het heeft dus wel zin, het oorspronkelijk ingevoerde wachtwoord is nu niet meer leesbaar, enkel de hash voor deze functie.

[Armin]

Aangezien het om een non-salted of in ieder geval niet-unieke versie gaat, is het een kwestie van eenmalig een iTunes-hash database genereren (igv salt) of standard SHA/MD5/etc hash lijst gebruiken.

Daarna is het kraken van zo'n iTunes wachtwoord een paar miliseconden ...

[__fred__]

Hashen van wachtwoorden voordat ze naar de server verstuurd heeft ook geen zin. Hierdoor wordt de hash het wachtwoord....

Beter dat je gewoon goede beveiligde verbinding opzet alvorens identificatie te versturen.

Eens met de goede beveiligde verbinding. Maar een hash oversturen helpt in ieder geval tegen een geslaagde MITM en een gebruiker die zijn apple wachtwoord bij elke andere site op internet heeft ingevuld.

[WarriorXK]

Ik vermoed niet dat dit opzettelijk is, maar het is wel slordig eigenlijk, ik had wel meer kennis van dit soort dingen verwacht van Apple.

[Reactie gewijzigd door WarriorXK op 24 juli 2024 01:02]

[3x3]

Idem, ze hebben een aardige reputatie met hun diensten, en veiligheid op afstand.

[Fluxpuck]

Idem, ze hebben een aardige reputatie met hun diensten, en veiligheid op afstand.

Het is ook niet zomaar te onderscheppen op afstand:

Om de kwetsbaarheid te misbruiken, moet een aanvaller wel de communicatie van een slachtoffer kunnen onderscheppen, bijvoorbeeld met een vervalst wifi-toegangspunt, of de dns-tabel van het slachtoffer kunnen manipuleren.

Maar desondanks is het een slordige fout.
Het zou netjes zijn als Apple zijn fout simpelweg erkent en het z.s.m. verhelpt.

Edit: Typfout

[Reactie gewijzigd door Fluxpuck op 24 juli 2024 01:02]

[Maarten21]

En dat is dus nogal makkelijk:

https://decorrespondent.n...werk/63289273905-181fc051

Doen alsof je een gratis openbaar wifinetwerk bent en klaar. Veel laptops en telefoons connecten automatisch en beginnen te syncen.

[Fluxpuck]

https://decorrespondent.n...werk/63289273905-181fc051
Hierin wordt uitgelegd hoe je iemand hackt door je voor te doen als een "bekent" netwerk van de gebruiker.

Dit betekend dat je bij iemand in de buurt moet zijn, om zijn wifi te klonen en zo te hacken. Ik bedoelde dat het niet mogelijk was iemand op relatief grote afstand te hacken, om zo aan de aangegeven gegevens te komen.

Edit: link

[Reactie gewijzigd door Fluxpuck op 24 juli 2024 01:02]

[Nibbz]

Niemand gaat toch ook ergens naar toe om iemand te hacken (als in , stiekem achter in de auto, met een laptop wifi netwerken imiteren).. dat kost veelste veel tijd.. zijn veel makkelijkere manieren .

[himlims_]

wel om 1 gebruiker, 1 account te bemachtigen wat je toegang geeft tot meeeer

[To_Tall]

Nu UPC en Ziggo netjes open netwerken hebben. en natuurlijk ook KPN hotspots..

Kan je gewoon lekker op schiphol of andere publieke ruimte gaan zitten. SSID van de ruimte clonen. En wachten tot de eerste mensen zich aanmelden op jouw hotspot

wat heb je nodig: een laptop, een WIFI voor het voor doen als SSID kpn_gast. en een eigen internet verbinding al dan niet via 3G of 4G

Terwijl jij achter je laptop beetje zit te surfen op Tweakers onder het genot van een kopje koffie. wacht je totdat de eerste persoon zijn gmail of outlook.com mail gaat controleren. Dan kom je al vrij snel achter tot welke diensten een gebruiker is aangemeld.. Je kan zo met een suffer tool alle data opslaan op je eigen computer. of de usernames en wachtwoorden

Veel tijd nee...
Makkelijk Jaa als je weet wat je moet doen.. en er zijn genoeg tutorials te vinden op het internet hoe dat kan.. Als probeer projectje thuis keer geprobeerd. totdat iemand perongeluk dus op mijn KPN SSID inlogde.. en ik al vrij snel zijn outlook.com username zag.. Wachtwoord was iets lastiger..

[Woy]

Zolang de verbindingen over https gaat, wat met outlook.com als het goed is ook het geval is, ben je er nog niet met een fake access point.

Je zult dan een MITM attack uit moeten voeren, en dat is voor websites niet eenvoudig.

Het grote probleem hier is dan ook vooral dat iTunes blijkbaar niet eens controleert wat voor certificaat hij voorgeschoteld krijgt.

[To_Tall]

je kan je eigen reverse proxy opzetten..
Makkelijker gezegd dan gedaan. maar!!!!

Als ik TMG installeer als voorbeeld..
Ik zet daar packet inspection aan en Certificaat Check zet ik aan. Dan kan ik het Certificaat van de website vervangen voor een eigen vervangen tot einde van de proxy server die daar netjes weer het juiste certificaat gebruikt.

Dit is wel een stukje ingewikkelde techniek maar niet onmogelijk.. waarbij die TMG server zelfs in een data center kan hebben staan

[Woy]

Ja maar daar heb je alleen wat aan als je daadwerkelijk een certificaat kan fabriceren die voor die host geldig is, en ook nog gesigned is door een TTP die door de client vertrouwd wordt.

Dus tenzij je een trusted root CA gehacked hebt kun je er nog steeds niks mee. ( Of je moet de client pc ook gehacked hebben, waardoor je extra trusted root's toe kunt voegen, maar dan nog is het niet zo eenvoudig als alleen een fake wifi access point opzetten )

[Reactie gewijzigd door Woy op 24 juli 2024 01:02]

[To_Tall]

Ach hoevaak zie jij mensen domweg op iets klikken
Zeker bij een melding of je een Certificaat wil vertrouwen of niet. ik weet zeker dat 8 van de 10 mensen die niets met IT hebben gewoon netjes op ja klikken.. Met de gedachten.. Natuurlijk vertrouw ik mijn bank!!

voor verkeer dat niet over https gaat is het natuurlijk appletje eitje

[Gomez12]

Je denkt te technisch, je hangt er gewoon een self-signed certificate aanvast wat automatisch gegenereerd wordt op basis van de host-name, zodat iedereen een melding krijgt maar als ze op details klikken zien ze hun bank-naam etc.
Dan drukt al 90% op ja (de bank zal wel een tijdelijke storing hebben)

En de 10% die niet op ja drukt, daarvan gaat misschien 1% een telefoontje naar de bank doen maar tegen de tijd dat het uitgelegd is aan de bank, en dat die weer naar waar je zit kan bellen om de beveiliging een rondje te laten maken naar mensen met laptops ben jij al lang weer weg.

Juist bij dit soort dingen hoef je geen 100% te hebben, dat kost veels te veel moeite, 30% is al ruim voldoende want de mensen klikken wel door.

[Veda88]

Of koop een wifi pineapple. Dat ding kan zich voordoen als een wifi verbinding die je apparaat als trusted heeft staan (bijvoorbeeld je thuis wifi). Zonder dat je het door hebt verbind je mobiel dan automatisch met de hotspot en sommige apps gaan die verbinding dan gelijk gebruiken.
Ga hiermee maar eens een paar uur op een groot station staan. Je hebt zo traffic voor duizenden apparaten.

[Reactie gewijzigd door Veda88 op 24 juli 2024 01:02]

[_Pussycat_]

bekend netwerk
Dit betekent

[Menesis]

oi, ik dacht dat alle httpS diensten bestendig waren tegen zulke trucs

[Conzales]

Nou dat is de laatste tijd wel gebleken: gnutls lek, openssl protocol lek, apple's ssl lek. Heel veilig allemaal. Blijkt dat je maar beter niet teveel vertrouwen in veiligheid meer kunt hebben, zeker niet op internet. Het enige dat overblijft is zelf code schrijven en vervolgens gebruiken, zoals het OpenBSD project doet.

Als 'simpele' gebruiker ben je tegenwoordig behoorlijk afhankelijk geworden en is vertrouwen nogal belangrijk. Maarja,.. wie kan je vertrouwen als de grote providers het al af laten weten.

Apple laat hiermee duidelijk zien dat veiligheid toch niet zo belangrijk meer is voor hen, een andere verklaring is er gewoon niet voor. Ik twijfelde nog of de 'goto-fail' bug opzettelijk was of niet,.. maar nu is mijn vermoeden bevestigd.

[Intrepidity]

Je denkt dat als je zelf code schrijft dat dan dan veiliger is dan dat 500 man aan een opensource project werkt? Dacht het niet..

[Dorank]

Lees de critiek van OpenBSD devs die bezig zijn met LibreSSL op het OpenSSL project maar eens (volgens dit slashdot artikel).

[Conzales]

Meer ontwikkelaars betekent niet dat de code altijd beter is. Het OpenSSL team is meerdere keren op fouten/lekken gewezen, maar was gewoon te lui om daar wat aan te doen. Dat kan je inderdaad lezen via de OpenBSD mailing lijsten.

[Armin]

dacht dat alle httpS diensten bestendig waren tegen zulke trucs

Zijn ze ook, tenzij er een bug in de implementatie zat.

Een maandje of twee werd er zo'n fout gevonden in iOS, en zoals dit artikel stelt lijkt het er op dat dit gewoon of dezelfde fout is, of een vrijwel identieke.

Normaal wordt het certificaat namelijk gecontroleerd. iTunes client-software doet dat niet, en dat is de bug.

Zou men de standard Microsoft SChannel bibliotheek gebruikt hebben - zoals op elke Windows PC aanwezig - ipv eigen SSL bibliotheek had het ook opgelost.

[Verwijderd]

En dat is tegenwoordig met de WiFi-hotspots van UPC en Ziggo wel heel erg makkelijk zonder dat iemand je doorheeft.

[mloman]

Volgens mij komt de ernst niet echt over. Met de juiste spullen kan iedere slimme gast bij de McDonalds en Starbucks accounts van nietsvermoedende klanten overnemen. Blijkbaar weet Apple niet dat SSL (https) gemaakt is voor twee doelen:

1. het verifiëren van de serveridentiteit, zodat je weet dat jouw persoonlijke gegevens naar de bedoelde vertrouwde server gaan

2. het voorkomen dat derden de communicatie kunnen afluisteren en manipuleren

Dit is de basis van het internet en elke ontwikkelaar hoort dat te weten. Ik kan me niet voorstellen dat niemand bij Apple dit weet en ik ben verbaasd dat dit niet eerder is ontdekt. Tot vorige maand waren zelfs alle iPhones en iPads hier nog vatbaar voor.

[Reactie gewijzigd door mloman op 24 juli 2024 01:02]

[Fluxpuck]

Ik bedoel dat je niet van thuis iemand zijn itunes account kan hacken.

Tevens is het toch wel opvallend dat dit probleem zich voordoet bij itunes voor windows:

Windows-gebruikers zijn kwetsbaar; onder OS X krijgen gebruikers wel een waarschuwing dat het certificaat niet klopt.

[Dorank]

Dat kan dus wel indien je DNS op het device kan beinvloeden (met bv malware).

[Armin]

Mits er geen certificate pinning toegepast wordt.

Maar dat wordt helaas vaak niet gedaan.

[Armin]

MacOS had waarschijnlijk ook die bug, maar MacOS X kreeg vorige maand een OS-update.

iTunes gebruikt een eigen SSL bibliotheek ipv de standard Windows ingebouwde van Microsoft, en kennelijk zat daar ook de Apple bug in, maar is die daar niet gefixt.

[Verwijderd]

Ik weet niet waar jullie dat ongefundeerde vertrouwen in Apple vandaan halen, maar qua security doet Apple het al jaren heel slecht en hebben ze het eigenlijk nooit goed gedaan. Er is geen (semi-populair) platform naast iOS waar meer gaten in gevonden worden en berichten zoals dit zijn ook schering en inslag. Je moet wel heel zacht in je bolletje zijn wil je denken dat Apple en veiligheid goed samen gaan.

Apple heeft onder bekwame IT'ers een reputatie van belabberde beveiliging en weinig mogelijkheden om deze te verbeteren. Alleen onder digibeten geloofd men nog in de praatjes van Apple, dat ze 'veilig' zijn.

Ik had van bezoekers van tweakers.net wel een iets realistischer beeld van Apple verwacht eigenlijk.

[Conzales]

Je verhaal klopt dat Apple het niet altijd zo nauw neemt, vooral met het uitbrengen van patches. Maar er moet wel onderscheid gemaakt worden tussen protocollen en het besturingsysteem iOS/OSX. De protocollen van o.a. Apple hebben het de laatste tijd zwaar te verduren. Het OS X-systeem, dat wel als een van de weinige zich echt UNIX mag noemen, is behoorlijk veilig als je de accountsrechten goed instelt (net als bij windows). Helaas werken veel te veel gebuikers nog steeds met admin-rechten terwijl ze die helemaal niet nodig hebben de hele dag lang. Dus door minimaal 2 accounts te gebruiken is het grootste beveiligingsprobleem al opgelost. Iets dat Microsoft sinds Windows Vista ook heeft begrepen. Daarnaast is OS X net als alle andere besturingssystemen gewoon kwetsbaar voor allerlei plugins. Daar is weinig aan te doen als je er geen controle over hebt. Als klant heb je daar al helemaal geen controle meer over. "Oh,.. wacht, moet flash nog ff installeren!" "Java(RE), iemand..?"

[Fluxpuck]

Mee eens. Tevens bij gebruik van OS X en itunes is er geen probleem, aangezien je dan wel een melding krijgt dat het certificaat niet klopt. Het probleem doet zich voornamelijk voor bij itunes voor windows

Windows-gebruikers zijn kwetsbaar; onder OS X krijgen gebruikers wel een waarschuwing dat het certificaat niet klopt.

[Shark.Bait]

Dat geeft te denken dat de iTunes programmeurs ervanuit gaan dat het OS de beveiliging regelt...

[Bierfustje]

Onjuist; zie ook eerdere reaktie van Armin.

Indien je de verbinding niet door Windows laat lopen, is het de applicatie die afdwingt wel/niet de diverse checks te doen. Blijkbaar hebben ze het zelf willen proberen en hebben ze (apple) dit niet goed geïmplementeerd in hun iTunes applicatie voor Windows.

[iAR]

Dat is ook nogal een (tegen)stelling die je neerlegt. Waaruit blijkt dat allemaal uit?
Enne semi-populair? Seriously?

[Shark.Bait]

je vergeet dat windows phone dezelfde status geniet als OS X: te weinig gebruikt en daardoor niet of nauwelijks interessant voor kwaadwillenden of onderzoekers. Hoge bomen vangen veel wind, en dat zijn Android en IOS.

[Armin]

Eerlijk is eerlijk, op het gebied van HTTPS/SSL is Microsoft vaak een pionier met een van de beste experts in de industrie. Niet voor niets wordt Microsoft altijd gevraagd in dat soort standaardisatie commites.

En het was bijvoorbeeld Microsoft die als eerste de befaamde NSA-RSA infiltratie in het random-algorithme ontdekte (voor het geval iemand denkt dat die twee onder een hoedje spelen )

Ook liepen/lopen zij doorgaans voor op gebied van implementaties Eerste met ECDHE, eerste met TLS 1.1, eerste met TLS 1.2, eerste met RC4-deprecation, etc.

Micosoft mag dan veel lekken hebben in andere producten , maar hun SChannel bibliotheek is een van de, en zo niet de beste SSL bibliotheek.

[Verwijderd]

"Ter vergelijking, in Windows Phone 8(.1) is nog nooit een lek gevonden."

Vorig jaar heb ik wel een powerpoint-presentatie gezien (via een tweakers-link?) waaruit naar voren kwam dat naast Android en IOS ook WP8 te kraken was. Helaas kan ik deze niet meer terug vinden.

Tenslotte zijn er contractors die claimen dat het kraken van WP8 tot hun portfolio behoort (wpcentral.com, 21-1-2014).

[Verwijderd]

Claimen. Daar zeg je het zelf.

Ik snap dat je het liever niet wilt zien of horen. Maar MS heeft het gewoon goed gedaan met veiligheid op WP8, terwijl iOS hier veel moeite mee heeft. Neemt de overige voor en nadelen niet weg, maar laten we er wel realistisch naar kijken. Het gaat er in dit bericht toch om veiligheid he.

Wat ik wel frappant vind is dat steeds meer mensen dingen geloven over producten en diensten. Het zijn maar telefoons, waarom moet daar nou gelijk zo'n rare religieuze sfeer omheen waarbij het niet meer om de prestaties van een apparaat gaat, maar om wat men geloofd dat het doet? Kijk dan hoeveel mensen er helemaal wild worden als er een negatief feit geplaatst wordt over een product?! Dat is echt ongezond en nog gevaarlijk ook. Zo werken nu verschillende bedrijven met software waarvan ze geloven dat ie veilig is, maar dat in de praktijk helemaal niet is.

[batjes]

Zie niet waarom je gemint word, je hebt wel een punt.
En MS levert tot over 100k USD uit voor gevonden hacks in WP8.1.
Als er hacks/exploits zijn, vind vanzelf iemand die maar al te graag de 100k in ruil er voor wilt hebben.
Ja je zou miljoenen met exploits kunnen verdienen als de WP markt zo groot als die van Android was. Maar ik gok dat het prijzengeld ook gewoon omhoog gaat.
Dusver zijn alle lekken op WP8(.1) op 1 hand te tellen. Kijk in diezelfde tijd naar iOS en Android.
Windows RT doet het ook goed, alleen te jailbreaken met software die MS zelf levert en kan stopzetten. IE11 is dus ver sinds zijn launch ongekraakt (Let wel, met Protection mode en/of EMET)...

Ja nee Apple is veilig, Microsoft niet schijnbaar.

[mr.paaJ]

Maar, als ik jou was zou ik lekker mijn koppie in 't zand houden en op je knietjes naar de Grote Apple bidden en vooral niet zelf nadenken, net als de rest van je Applekudde.

... Moet dat nou?

[Verwijderd]

Ik weet niet waar jullie dat ongefundeerde vertrouwen in Apple vandaan halen

uhm dude, je eigen bericht is net zo ongefundeerd... referenties?

[Verwijderd]

meer "doorgewinterde programmeurs" denken dat hun implementatie van SSL en de veiligheid van SSL voldoende is
daardoor encrypten ze de data niet zelf ook nog eens voordat het verzonden word
komt meer voor dan de meesten denken blijkt maar weer

[Armin]

Er is geheel niets mis met het versturen van een wachtwoord over de kabel met enkel een SSL-laag. Ze werkt o.a. elke email client op aarde. Als de SSL laag goed geimplementeerd is dat 100% veilig.

Het probleem is hier enkel dat Apple geen certificaat check doet. Dat is gewoon een grote beginners-bug van Apple.

Het idee dat je een password moet hashen voor versturen is onzinnig, want het gaat voorbij aan hoe password geverifieerd wordt op de server. Immers de server kan dan niet zomaar het aantal hash-rounds wijzigen zonder rekening te houden met de salt-less (!) pre-hash. Op servers worden namelijk meervoudige hash rounds gebruikt mét salt. (Tenzij het van die noobs zijn die hun eigen password hash algorithme ontwikkelen )

Plus dat enkelvoudig hashen zonder salt toch geen echte beveiliging is...

[Orion84]

Natuurlijk kan je wel op de server het aantal hash-rounds wijzigen. Alleen moet je dan ook je client (bij webapplicaties dus simpelweg de javascript code die geserveerd wordt door de server zelf) aanpassen indien dat aan elkaar gekoppeld zou zijn.

Check bijvoorbeeld eens de js code op de tweakers.net login pagina. Daar gebeurt heel wat meer dan enkel plaintext het wachtwoord richting de server schieten. Onzinnig? Dacht het niet. SSL is zo veilig als de client en/of de user die het certificaat controleert.

Daarop vertrouwen kan als je zelf de fat-client ontwikkelt en daar niet de fout in maakt die Apple nu maakte, maar op het gebied van webapplicaties betekent dat vertrouwen in de user en dat lijkt me niet verstandig.

Een goed opgezet challenge response mechanisme voorkomt zelfs bij een gecompromitteerde SSL verbinding dat de aanvaller het plaintext wachtwoord niet te weten komt en ook het versleutelde / gehashte wachtwoord niet kan hergebruiken voor een latere login poging.

Beveiliging in meerdere lagen aanbrengen is vele malen beter dan blind vertrouwen op (juiste implementatie) van 1 laag.

[Woy]

Mja, het heeft zeker enig nut. Maar als je de SSL laag niet vertrouwt, dan heeft client-side hashing ook weinig nut. Immers kan de attacker dan hoogstwaarschijnlijk ook gewoon de pagina zelf aanpassen, en dat betekend dat de hashing er net zo goed uitgesloopt kan worden.

[Orion84]

Hmm, zeker waar. Al vereist dat wel een wat actievere aanval dan simpelweg mitm spelen en luisteren of je toevallig wachtwoorden en gebruikersnamen langs ziet komen. Maar dat is inderdaad wel een risico ja.

[Armin]

Natuurlijk kan je wel op de server het aantal hash-rounds wijzigen. Alleen moet je dan ook je client (bij webapplicaties dus simpelweg de javascript code die geserveerd wordt door de server zelf) aanpassen indien dat aan elkaar gekoppeld zou zijn

Nee, juist niet! Dat is het mooie.

Ik zal het uitleggen. Jij stuurt je nieuwe password over een TLS/SSL verbinding. De server hashed dat (samen in de eerste round met een unieke salt) 1000 keer en slaat dat op samen met die salt. Bij de volgende login wordt opnieuw je password gestuurd, de server hashed (na de salt te lezen) 1000 keer en vergelijkt met de opgeslagen waarde.

Nu morgen wil de system-admin, or een extern bureau dat je 5000 hashes doet. De server-software wordt aangepast en alle bestaande databases worden 4000 keer extra gehashed. Klaar!

Dat is het mooie van password bibliotkeken als PBKDF2.

Je ziet nu ook gelijk dat hashen voor het sturen onzinnig is. In dit system is er nihil client-specifieks, en kun je naar hartelust de client-software aanpassen. Ook kan de server onafhankelijk van de client de security versterken om mee te gaan met de brute-force mogelijkheden van hackers.

Vandaar ook dat een ontwikkelaar die geen security expert is NOOIT zelf moet gaan hashen of slimme dingen bedenken. Het is meer werk en vrijwel altijd zwakker. En een expert in security weet dit, en doet het niet en gebruikt al PBKDF2 of bcrypt of zo

Beveiliging in meerdere lagen aanbrengen is vele malen beter dan blind vertrouwen op (juiste implementatie) van 1 laag.

Klopt, maar dat spreek ik ook niet tegen. De verschillende lagen moeten wel complimentair zijn. Twee keer encryptie is onzinnig en vaak zwakker dan een laag zwaardere encryptie (Wikipedia tip: 'meet in the middle aanval'

Wat jij beschrijft is autenticatie, en inderdaad een essentieel onderdeel van bijvoorbeeld SSL. En exact wat het artikel beschijft wat bij iTunes nu en de vorige iOS SSL bug fout ging.

[Reactie gewijzigd door Armin op 24 juli 2024 01:02]

[Feanathiel]

Slordig is nogal een ruim begrip. Je ziet hier een venster uit Fiddler. Dat je een request eventueel niet versleuteld/hashed omdat het https is is nog daaraan toe. Wat je in het screenshot ziet is dat de server een response met een wachtwoord erin terug stuurt. Nogal een verschil. Zoiets moet je ontwerpen.

[Reactie gewijzigd door Feanathiel op 24 juli 2024 01:02]

[Xieoxer]

Elke programmeur kan een fout maken, dit zal vast een onbewuste fout zijn geweest. Wel netjes dat het beveiligingsbedrijf er een melding van gemaakt heeft. Apple kende zal het vast snel oppakken en het oplossen. Ieder geval op een Mac hoef je geen zorgen te maken, want daar krijg je duidelijk een waarschuwing te zien als de certificaat niet klopt.

[Reactie gewijzigd door Xieoxer op 24 juli 2024 01:02]

[roger128]

"Dit is een beginnersfout, of met opzet", aldus Loman. "Inlichtingendiensten als de NSA kunnen hierdoor eenvoudig alle communicatie met iCloud onderscheppen."

Ik neem aan dat de programmeurs bij Apple (in ieder geval de programmeurs die ze op de beveiliging zetten) geen beginners zijn, dus dat zou dan opzet kunnen zijn.
Ik vertrouw het in ieder geval niet!

[Conzales]

...nog gewoon vooral op verschillende opensource tools draaien en dat die geen van allen door Apple ontwikkeld worden. - Veel meer dan Itunes e.d. ontwikkelen ze niet.

Helaas,.. ff iets meer onderzoek doen nog:
http://chimera.labs.oreil...s/1234000001814/ch01.html
Apple schrijft bijna alles zelf van het besturingsysteem (API's/UI), behalve sommige standaard communicatieprotocollen natuurlijk. De kern is voor een deel van het originele BSD afkomstig. Een klein deel kom van FreeBSD.
http://upload.wikimedia.o...7/Unix_history-simple.svg

[Reactie gewijzigd door Conzales op 24 juli 2024 01:02]

[borft]

Volgens mij weet jij niet echt waar je over praat. Ik ben niet echt een Apple fan, maar OSX lijkt absoluut niet op een Linux distro, anders dan dat ze ook POSIX compliant zijn.
Verder doet Apple best veel ontwikkelwerk; namelijk:
- OSX + IOS (zowel OS niveau, als applicaties erop)
- iTunes
- redelijk wat van de productivity suites op OSX
- ontwikkel tools voor IOS (XCode anyone?)
- ooit gehoord van Mail + Calendar, en het bijbehorende Caldav protocol? De opensource calendar server, is door Apple ontwikkeld.
- het meest gebruikte printer subsystem op linux, CUPS, is door Apple ontwikkeld
- Wat dacht je van een van de meest gebruikte browser-render engines, zoals die in Safari zit?

Ik ben geen fan van Apple, maar ze doen wel degelijk redellijk wat ontwikkelwerk. Het niet verfieren van certificaten is mi. een ontzettende beginnersfout, maar getuigt ook van een amateuristisch ontwikkelproces. Immer ook alle code reviewers hebben het niet gezien, en blijkbaar zijn er dus ook geen tests of audits geweest!

[Maurits van Baerle]

Tja, Sleep0rz zit een beetje te trollen. Je kunt er ook nog populaire applicaties zoals iPhoto en iMovie, de hele iWorks suite en professionele pakketten als Final Cut Pro, Motion, Logic Studio (o.a. Logic Pro, Mainstage, Soundtrack Pro, WaveBurner) en Aperture aan toevoegen. Verder hebben ze natuurlijk een hele reeks cloud diensten die ook niet vanzelf ontstaan.

Apple is niet voor niets bezig om een nieuwe campus te bouwen waar ruim 13,000 mensen moeten worden ondergebracht. En dat is alleen voor de developers in Cupertino, in Austin zitten ook nog een hele zooi developers.

[Reactie gewijzigd door Maurits van Baerle op 24 juli 2024 01:02]

[jarrin]

Weet je wat ik alleen niet snap? Waarom ben jij niet veel succesvoller als zo'n "flut" bedrijfje als Apple?

Immers, jij kan dit allemaal zo ff op je "zolderkamer" fixen. Ik zou zeggen, met zo enorm veel kennis als jij hebt, grijp je kans!

[WarriorXK]

Als het een onbewuste fout is waarom reageert Apple hier dan niet op? Zoals je zegt, een ongelukje kan gebeuren, maar waarom het stilhouden rondom de fout? laat je gebruikers in ieder geval weten dat ze risico lopen.

[ongewoongewoon]

Ik heb niet het idee dat Apple überhaupt vaak reageert (in de pers) op dit soort kwetsbaarheden. Grote kans dat er inmiddels wel mensen werken aan een oplossing

[Verwijderd]

Inderdaad, Apple hanteert een bepaalde PR methode waarbij je simpelweg niets zegt, tenzij er druk is op de koers, of je eigen producten er juist beter door kan laten lijken.

Neem bijv. het probleem met het ontvangen van een SMSje waarin de 'reply to' zeg maar anders is dan die van de afzender. In de iMessage app zie je dan nog steeds de 'from', en niet de 'reply to', dus kan een antwoord op een tekstje naar een ander nummer gaan dan je denkt; niet wat je wil als iemand probeert te phishen als zijnde een bank, bijvoorbeeld. Het antwoord van Apple daarop? Dat SMSen niet zo veilig is als een iMessage bericht waarbij de verzender altijd gecontroleerd wordt, dus mensen zouden vooral iMessage moeten gebruiken.

En, laten we eerlijk zijn, het werkt. Elke keer dat je daadwerkelijk ergens op reageerd en zegt dat het interdaad ernstig is en dat er aan een fiks gewerkt wordt, krijg je alleen maar de pers over je heen, die vervolgens elke 24 uur gaat herhalen dat er 'nog steeds geen fiks' is, etc. Doodzwijgen, in een updateje rollen, verder niet al teveel over zeggen - veel betere optie.

[arjankoole]

Inderdaad, Apple hanteert een bepaalde PR methode waarbij je simpelweg niets zegt, tenzij er druk is op de koers, of je eigen producten er juist beter door kan laten lijken.

Euh, nee. Ze zeggen domweg nooit wat tot ze het geverifieerd hebben en een oplossing hebben die door en door getest is. Zo doen ze het al sinds het allereerste begin.

[Verwijderd]

Ach ja, vandaar ook dat het bericht "Apple erkent problemen met iMessage" toevallig vlak na een rechtszaak pas naarboven komt, ondanks dat die problemen al jaren spelen

En vandaar ook de korte statement "We recently fixed a server-side iMessage bug which was causing an issue for some users, and we have an additional bug fix in a future software update".
Welke issue? Toekomstige fix - wanneer? Oh, right, dat zeggen ze pas als ze "een oplossing hebben die door en door getest is". En dan 'zeggen' ze dat a la "improved iMessage services" in een update beschrijvinkje

Men kan het draaien zoals men wil, het komt hier op neer: Apple hanteert een bepaalde PR methode waarbij je simpelweg niets zegt, tenzij er druk is op de koers, of je eigen producten er juist beter door kan laten lijken.
Die PR methode hanteren wel meer bedrijven. Het is dan ook geen kritiek, maar een observatie.

[Verwijderd]

gratis reclame

[jarrin]

Ja, mijn inziens is dit niet echt een fout, maar eerder een complete functionaliteit die ontbreekt (Het controleren op echtheid/gerechtigheid van certificaten). Dus ik voermoed eerder opzet, dan een foutje.

[Reactie gewijzigd door jarrin op 24 juli 2024 01:02]

[roger128]

Slechte zaak!

Betekend dit ook dat mensen met andermans account apps kunnen aanschaffen? (als een gebruiker een credit card gekoppeld heeft)

I am rich anyone?

[Reactie gewijzigd door roger128 op 24 juli 2024 01:02]

[TheJoe]

ja, maar die zijn dan wel gekoppeld aan andermans account.

[watercoolertje]

Als ik met jouw account mijn apps koop maakt dat echt niet uit

[Krilo_89]

Wel als je daarna wilt updaten, dan updaten die apps niet, tenzij je het juiste wachtwoord invult. Maar mocht je dat niet erg vinden, is dat een optie ja.

[watercoolertje]

Je snapt het hele punt niet, of je wel of niet update maakt niet uit, als ik met jouw account een app van mij koop, verdien ik toch gewoon geld? Alsof het een dief (wat ik op dat moment zou zijn) kan schelen of jij die app daadwerkelijk wilt of kan updaten, dat is wel het laatste waar iemand die geld over jouw rug heen verdient zich zorgen gaat maken...

[Reactie gewijzigd door watercoolertje op 24 juli 2024 01:02]

[Henk Poley]

Je begrijpt het niet.

* Maak simpele app
* Stop in app store voor €1000
* Koop app met andermans iTunes account
* €700 naar jouw bankrekening

[roger128]

Apple pakt 30%, 70% is voor de hacker

Hacker maakt een I am rich clone, koopt hem een paar keer met wat gehackte accounts en klaar is kees

[DeEchteKwartel]

Als het goed is moet dit dus via een trojan ook al te onderscheppen zijn. Al zijn keyloggers dan ook al een optie.

[roger128]

Ja maar dat geld voor zo´n beetje iedere vorm van encryptie...

[DeEchteKwartel]

Ja, maar dit bedoel ik in combinatie met de mtm attack.

[GerritGekke]

Als iTunes de certificaten niet verifieerd, betekend het dan dat ik 7.0.6 via een gedownloade IPSW op mijn iDevices kan installeren? Of zelfs downgraden via iTunes!!

[jarrin]

"Apparaten als de iPad 1 en de iPhone 3G en 3GS, die niet kunnen worden bijgewerkt naar de nieuwste iOS-versie, zijn zelfs voor altijd kwetsbaar."
Daarom wel het melden waard, Watson

[Dylan93]

"Apparaten als de iPad 1 en de iPhone 3G en 3GS, die niet kunnen worden bijgewerkt naar de nieuwste iOS-versie, zijn zelfs voor altijd kwetsbaar."
Daarom wel het melden waard, Watson

Apple released beveiligingsupdates voor oudere iOS versies wanneer nodig, zie iOS 6.1.6, de iPhone 3GS is dus nog gewoon te updaten, eveneens alle apparaten op iOS 6.

Echt oude versies worden niet meer ondersteund, deze hardware wordt dan ook al tijden niet meer verkocht (iPhone 3G).

[Reactie gewijzigd door Dylan93 op 24 juli 2024 01:02]

[SED]

de 3G was tot 2010 gewoon leverbaar... 4 jaar is niet bijzonder lang voor hardware..

[arjankoole]

de 3G was tot 2010 gewoon leverbaar... 4 jaar is niet bijzonder lang voor hardware..

Voor mobiele telefoons wel, die worden - als ik even rond kijk - na een jaar al vervangen door veel mensen. (Die mij voor gek verslijten dat ik er 3 jaar mee doe)

[SED]

Het gaat mij er meer om dat de support snel stopt. Los van de gebruiksduur. M

[arjankoole]

Het gaat mij er meer om dat de support snel stopt. Los van de gebruiksduur. M

De support loopt nog best lang bij Apple, als je het vergelijkt met Android. Als je kijkt hoe snel samsung en sony vaak al stoppen met support.... dan is wat apple doet heel erg netjes.

[Verwijderd]

apple is dat veilig

[Verwijderd]

Oorlog is ook nog. (met dank aan de super spellingcontrole van SwiftKey)

[huntedjohan]

En dus moeten we dit soort fouten of opzettelijke misstappen maar gewoon accepteren?

[Verwijderd]

Nee, zeker niet. Maar we moeten niet denken dat hier echt een oplossing voor komt. Vandaag bedacht, morgen achterhaald.