Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 37 reacties

Een groot aantal populaire apps voor iPhones en iPads bevat een kwetsbaarheid in de implementatie van https. Hierdoor zou het eenvoudig zijn ssl-verkeer af te tappen op onveilige netwerken. De apps zijn kwetsbaar door gebruik van een oude versie van AFNetworking.

Het bedrijf SourceDNA vond een manier om het gebruik van AFNetworking bij iOS-apps te monitoren en constateerde dat 1000 apps kwetsbaar waren, waaronder apps van Yahoo, Microsoft, Uber en Citrix. Het bedrijf heeft een zoekmachine online gezet waarmee gebruikers kunnen controleren welke apps kwetsbaar zijn.

AFNetworking is een opensource-codebibliotheek die veel ontwikkelaars gebruiken voor netwerkfunctionaliteit van hun apps. Versie 2.5.1 van de library, die 12 februari uitkwam, kampte met een bug waardoor er geen validatie van ssl-certificaten plaatsvond. In versie 2.5.2 werd het probleem verholpen maar in de tussentijd waren veel apps bijgewerkt en lang niet alle apps voerden vervolgens de versie door waar de bug niet in zat.

SourceDNA maakte vingerafdrukken van de versies van AFNetworking van voor, tijdens en na de kwetsbaarheid. Het bedrijf matchte deze met de binary code van 20.000 iOS-apps die gedurende de periode dat AFNetworking kwetsbaar was, uitgebracht werden of een update kregen. De resultaten waren dat 55 procent nog de oude, veilige 2.5.0-code bevatte, 40 procent niet over de kwetsbare ssl-api beschikte en 5 procent wel kwetsbaar was.

Als mensen met een iPhone of iPad kwetsbare apps gebruiken op een netwerk dat door een kwaadwillende wordt beheerd, is verkeer dat versleuteld zou moeten zijn te onderscheppen, waarmee mogelijk logins en wachtwoorden in verkeerde handen kunnen komen. "Het verbaast ons dat een opensource-codebibliotheek die zes weken met een beveiligingslek kampte, miljoenen mensen blootstelde aan aanvallen", meldt SourceDNA.

Moderatie-faq Wijzig weergave

Reacties (37)

Spijtig dat je niet een lijst kunt inzien om als gebruiker te zien welke apps (nog steeds) niet 'veilig' zijn.
Nu moet je voor iedere app / developer naam intikken om te achterhalen of hun app(s) deze kwetsbaarheid (nog) hebben.

Vanuit het oogpunt echter van de mensen die hier misbruiken van maken is er voor deze werkwijze van sourceDNA van opzoeken ook weer wat te zeggen.
Misschien moeten app developers de set-and-forget mentaliteit wat meer afleren ;-) Het is niet alsof als je je applicatie afgeleverd hebt de rest van de wereld stil staat en je nooit meer onderhoud hoeft te plegen.
Makkelijk om te zeggen, maar soms heb je gewoon niet de resources om dingen op te lossen of is het financiele voordeel te laag/niet aanwezig. Dan kan je je het niet veroorloven.

Als het een app is die gewoon goed draaide en je bent druk bezig met andere dingen, dan kan het zijn dat je geen tijd hebt om de andere app te onderhouden...

Voor iemand zegt 'ja, dan had je het niet moeten maken' of zo, ik heb ook een eigen app waar ik helaas wat weinig tijd voor heb momenteel. Ik heb klanten waar ik producten voor af moet maken, de app draait goed maar mag wel een remake / onderhoud gebruiken. Maar hij levert gewoon veeel te weinig op om dat nu te kunnen verantwoorden om hier tijd aan te besteden...
De imagoschade die een onveilige applicatie oplevert is vele malen groter dan het geld wat je verdient aan lopende projecten.

Natuurlijk is het altijd een ROI overweging maar zolang de R alleen in geld uitgedrukt wordt ga je het niet redden....
OK, ik ben het met je eens dat in geval van veiligheid je inderdaad de klanten dit niet aan kan doen en je zsm een fix moet doet, en dat zou ik ook doen.
Maar ik reageer op johnkeates omdat het lijkt alsof hij het als 'algemeen' statement zegt, niet alleen voor veiligheid
Maar stel dat die bewuste app wel bij klanten lag ...
Dan is het toch weer een andere zaak....
Dan zal je er toch tijd in moeten steken om "het op te lossen"
nee, inderdaad, daar heb je weer gelijk in...

problemen zijn ook altijd in iedere situatie anders...
Precies, een business model noem je dat h :P
Ik vind het niet meer dan logisch dat software niet tot het oneindige onderhouden blijft. Zo is dat met alles.
Dan moet je als gebruiker beslissen wanneer de software ontwikkeling van het door jou gebruikte product lijkt stil te staan misschien een ander product gaan proberen.
Hoe jammer het ook is, software ontwikkelen kost gewoon veel geld.
Zolang het werkt, zullen weinig developers hun tijd steken in technisch onderhoud (waar de gebruikers niet voor betalen) terwijl ze functionaliteit kunnen maken waar ze wel aan verdienen. Het is eerder aan de stores om hierop te sturen; zodra issues als dit bekend worden de developers die er gebruik van maken informeren en aangeven wanneer ze overgestapt moeten zijn op een versie van de library / plugin die veilig is.
Het is eerder aan de stores om hierop te sturen; zodra issues als dit bekend worden de developers die er gebruik van maken informeren en aangeven wanneer ze overgestapt moeten zijn op een versie van de library / plugin die veilig is.
In dat geval dan ook: Apps die na x dagen nog steeds de kwetsbare library bevatten uit de store schoppen en evt actief bij gebruikers blokkeren met opgave van reden.
Ik zou voor zijn. Natuurlijk krijg je een enorme berg gezeur hiermee (gebruikers hebben betaald voor app -> *poof* app weg), maar goed, voor niks gaat de zon op.
Dat hoeft helemaal niet. Je kan ook de app van een label voorzien dat deze onveilig is en het aan de discretie van de gebruiker overlaat deze al dan niet te installeren c.q. te verwijderen.
Uhh nee dus, laat dat blokkeren maar aan de gebruiker zelf over, hooguit waarschuwen..
1,2 miljoen apps in de App Store en 1000 daarvan zijn kwetsbaar.
Nee. 20k is een meer dan groot genoeg sample size om te kunnen zeggen dat het ook 5% is voor 1.2mil apps. Mag je zelf nachecken als je wilt: http://www.surveysystem.com/sscalc.htm

[Reactie gewijzigd door Chester op 21 april 2015 16:55]

Als ik het goed begrijp zijn die 20,000 lle apps die na de datum waarop de kwetsbaarheid geintroduceerd is zijn geupdate. Er kunnen dus niet meer apps zijn die kwetsbaar zijn en niet onder de sample vallen.
5% van 20.000 is 1.000 apps die recent zijn aangepast naar versie 2.5.1.
Het sample was 20.000... voor 1.5Miljoen is het resultaat dus potentieel: 75.000 kwetsbare apps!
Dat klopt niet. Jij gaat er vanuit dat iedere iOS app die te koop is deze kwetsbare library gebruikt. Ten eerste is het gebruik van deze third-party library niet vanzelfsprekend. Ten tweede zijn alleen die apps die een specifieke versie gebruiken kwetsbaar.
Ik denk dat het uiteindelijke percentage veel lager is. Ik durf zo te beweren dat minimaal de helft van de apps in de App Store voor het laatst gepdatet is vr deze kwetsbare versie van AFNetworking uit kwam.

Ik mag tenminste hopen dat ze zo slim zijn geweest om dat in de selectiecriteria van de sample mee te nemen ;)

[Reactie gewijzigd door mees op 22 april 2015 00:11]

nee, volg de opzet van de sample en extrapoleer dat naar het totaal.
De sample werd als representatief gezien dus dat is een redelijke aanname zonder extra voorwaarden of uitbreidingen.
De resultaten waren dat 55 procent nog de oude, veilige 2.5.0-code bevatte, 40 procent niet over de kwetsbare ssl-api beschikte en 5 procent wel kwetsbaar was.
Dus als ik het goed lees, slechts 5% heeft 2.5.1?

[Reactie gewijzigd door ADQ op 21 april 2015 14:54]

Nee dat staat er niet. Sterker het is waarschijnlijk slecht overgenomen. Het laat namelijk volledig in het midden welke library die overige 40% apps gebruiken. Er staat slechts dat die niet 1 specifieke api van die library gebruiken. Het kan dus zijn dat ze 2.5.0, 2.5.1 of wellicht een oudere versie hebben.
Dat was dus mijn gedachte ook. Of de developers waren up tot date, of liepen juist achter waardoor hun klanten juist veilig waren.
Of het stond niet goed...
5% van 20.000 is nog steeds 1.000 apps die minder dan een maand zijn aangepast met/door versie 2.5.1.

Hiermee onderstrepen we maar weer eens de afhankelijkheid die developers hebben ten opzichte van 1 of 2 leveranciers van een SDK / library / dependency.

Verder is ook niet onderzocht (of bekendgemaakt) hoeveel downloads er in dit tijd zijn geweest van de betreffende apps en hoeveel downloads er na 2.5.2 zijn geweest; alleen op basis hiervan kan je beoordelen of er 1 of 1.000.000 devices met een onveilige app rondlopen.
5% is een minder leuke headline dan "Groot aantal" ;)
5% IS een groot aantal met de markt die Apple bezit.
Wat ik me afvraag is waarom dergelijke populaire (en ook belangrijke) libraries niet gewoon als shared library beschikbaar zijn op het platform. Op die manier hoeven niet alle developers hun apps steeds bij te werken.

TLS-functionaliteit zou gewoon vanuit het OS geleverd moeten worden imho. Dat is niet de taak van een app-developer.
Ik kan me voorstellen dat de genoemde library onder water wel gebruik maakt van de platform API features en deze omvat in een wat meer high level / standaard gebruik, maar dat simpelweg niet goed deed. De readme blurb op github doet in ieder geval zoiets vermoeden.
Het citaat in het artikel:
Het verbaast ons dat een opensource-codebibliotheek die zes weken met een beveiligingslek kampte, miljoenen mensen blootstelde aan aanvallen
komt op mij nogal bizar over. Is dit ongelukkig vertaald of weet die vent niet waar hij het over heeft? Een populair library heeft zes weken lang een beveiligingsprobleem, lijkt mij dan niet meer dan logisch dat miljoenen mensen daar potentieel problemen van ondervinden.
Nee hoor, libraries op, bijvoorbeeld, mijn Linux-servers moet ik niet upgraden. Sterker nog, apt-get update draai ik misschien eens in de paar maanden.

Dus tussen versie onbetrouwbaar en versie betrouwbaar kan best een korte/lange tijd zitten, zowel voor developers als eindgebruikers.
Nee hoor, libraries op, bijvoorbeeld, mijn Linux-servers moet ik niet upgraden. Sterker nog, apt-get update draai ik misschien eens in de paar maanden.
Niks *moet* inderdaad, maar aan te raden is het wel. Gebruik dan ook apt-get upgrade trouwens anders doet 'ie nog niks.

Debian heeft een zeer actief security team wat dit allemaal voor je regelt overigens.
OpenSource kost geen drol.Al doneren terecht heel wat tevreden mensen.
En tot zover de zever dat een gesloten app store veiliger is....
Ja want een random kwetsbaarheid in https betekend ook meteen dat de App store vol staat met malware apps, of apps waar mensen niet zeker van zijn of ze nu wel of niet ''legit'' zijn zoals in de Play Store.
Apps worden nog steeds eerst via Apple geleid voor ze op de store komen, bij Google heb je dit niet... Dus tot de dag komt dat je opeens hoort dat de App Store vol met malware staat is een gesloten app store veiliger dan een open ( redelijk logisch ook )

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True