Androidversie Skype stond gebruiker toe om vergrendeling os te omzeilen

Door een combinatie van "slecht ontwerp en een bug", aldus de ontdekker van het probleem, kon een kwaadwillende het lockscreen van Android omzeilen door een Skype-oproep te beantwoorden en vanaf daar naar andere delen van het Android-systeem navigeren.

Een 19-jarige Kosovaarse bug hunter ontdekte het probleem in Skype in 2018 en meldde het in oktober bij Microsoft, die rond de kerst een fix verwerkte in een update voor de app. Versienummer 8.15.0.416 en hoger hebben de fix in huis. Aangezien het om een white hat gaat, wordt de kwetsbaarheid nu pas aan de grote klok gehangen. Dat schrijft The Register. Hoe lang de kwetsbaarheid in totaal in de app heeft gezeten, wordt niet vermeld.

Nadat een Skype-oproep wordt beantwoord, kan vanaf dat scherm toegang verkregen worden tot contactpersonen, foto's, de browser en via de browser andere apps op het systeem. De browser is toegankelijk door simpelweg een link in een Skype-chat te typen en daar vervolgens zelf op te klikken. Vanaf de browser kunnen verschillende apps geopend worden, aangezien bepaalde adressen gekoppeld kunnen zijn aan apps.

Reacties (97)

[StefanJanssen]

Deze beveiliging zit dus in de apps? Dit zou toch eigenlijk binnen het besturingssysteem moeten zitten? Als je niet ingelogd bent en de app vraagt om media (of andere bestanden te zien) dan zou het OS toch moeten zeggen "dat mag niet"

[Cebby]

Ja en nee. De keyguard (lockscreen) zit in Android geïmplementeerd en is de eigenlijke beveiliging die de controle uitvoert van je fingerprint of code. Android biedt echter APIs die het mogelijk maken om een app window voor te laten gaan op de key guard. Deze worden volgens mij vooral gebruikt door telefoonapps zoals Skype. In dit geval is het de verantwoordelijkheid van Skype om ervoor te zorgen dat de omzeiling van de keyguard geen toegang verschaft tot windows van andere apps. In principe krijgt alleen jouw app namelijk voorrang op de keyguard, maar door de werking van intents binnen Android en het gebruik van interne code voor toegang tot foto's is het in dit geval mogelijk meer te openen dan enkel Skype.

Nu zou je kunnen zeggen dat je je telefoon gelockt wilt houden voordat je kunt opnemen, maar het lijkt me niet gek dat er mogelijke situaties kunnen zijn waar je zo snel mogelijk wilt kunnen antwoorden. Zelf heb ik deze functionaliteit ooit ingebouwd in een BHV app waar je bij het binnenkomen van een melding op deze methode meteen kon antwoorden. We hadden het op een andere manier kunnen doen maar uiteindelijk was dit de manier om mensen snel te kunnen laten reageren. Iets wat dan wel van levensbelang kon zijn.

Hoewel de meerderheid hier dus roept dat dit wel een bug in Android moet zijn is het dus eigenlijk een feature waar de ontwikkelaar op de juiste manier mee om moet gaan.

Zie ook https://developer.android...ams#FLAG_SHOW_WHEN_LOCKED

edit: typos

[Reactie gewijzigd door Cebby op 22 juli 2024 16:29]

[GekkePrutser]

Kijk, iemand die duidelijk aangeeft hoe het echt zit. Top!

En zelfs ook een duidelijke reden dat deze functionaliteit uberhaupt in het OS zit (onmiddelijk moeten kunnen reageren). Al is het wel jammer dat het door Android zo is geimplementeerd dat je afhankelijk bent van de app bouwer.

Dat een app andere apps aan kan roepen is trouwens ook moeilijk te voorkomen: Als je bijvoorbeeld in whatsapp een file will attachen dan krijg je ook op elk toestel een andere dialoogbox. Hij opent gewoon de file browser die op dat toestel aanwezig is.

[Cebby]

Ik weet niet heel zeker wat er gebeurt als er een app wordt geopend via een intent waarbij die app dan buiten jouw app window valt. Het kan heel goed dat dat helemaal niet werkt.

De browser die wordt geopend lijkt ook een Chrome Custom Tab (https://developer.chrome.com/multidevice/android/customtabs) te zijn. Die vallen binnen de window van de app. Ik weet dan ook niet zeker of 'Vanaf de browser kunnen verschillende apps geopend worden, aangezien bepaalde adressen gekoppeld kunnen zijn aan apps.' echt helemaal waar is als de manier die ik beschrijf (en ik weet geen andere) gebruikt is. Dan zouden apps die worden geopend via een deeplink gewoon onder de keyguard vallen en dus niet geopend kunnen worden.

[Reactie gewijzigd door Cebby op 22 juli 2024 16:29]

[Wasrek]

Dank voor de duidelijke toelichting, maar het klinkt mij toch nog steeds als een bug in Android. Wat jij beschrijft (opnemen zonder te unlocken) vereist enkel dat een specifieke app voorrang krijgt op de keyguard. In het geval van Skype bleek het mogelijk dat een app die voorrang heeft, ook andere apps kon aanroepen zodat deze ook voorrang krijgt op de keyguard. Dat laatste is echt nergens voor nodig en voor iets dergelijks wil je niet afhankelijk zijn van de appbouwer om dit tegen te gaan.

Er zijn vast use cases te bedenken waarbij het wel handig lijkt, maar weegt dit op tegen het veiligheidsrisico dat hiermee geïntroduceerd wordt in Android?

[supersnathan94]

Ik vraag mij ook af of dit echter wel correct is. Ik snap dat MS alle mogelijkheden die skype bied tijdens een gesprek (zoals chat en fotos sturen) beschikbaar wil maken, maar het beschikbaar stellen van andere apps kan ook MS niet doen als de app ouwer van die andere app gewoon achter keyguard wil zitten.

Ik vraag me dan ook af of het openen van andere apps dan ook geverifieerd is of dat het redactionele suggestie is van “hee dit kan dan in theorie ook” terwijl er gewoon niet bij stilgestaan is dat het om een custom Chrome tab gaat (soort iframe binnen de app zelf) waardoor het alsnog niet kan.

[monojack]

"Een feature waar de ontwikkelaar op de juiste manier mee om moet gaan" Ja hallo, dat noem ik geen feature maar een bug. Het is echt wel een brug te ver als je je veiligheid en privacy in handen legt van third party dev's. Hat grootste deel zal je wel kunnen vertrouwen maar zoals we al hebben kunnen zien zijn er ook een pak niet te vertrouwen.

Dus deze bug een feature noemen is gewoon onzin. Dat is een feature als je een ontwikkelaar bent, dat is een bug als je een gebruiker bent. Wat nogmaals aantoont dat Android niet geschreven is met de gebruiker als main focus.

In iOS heet dit gewoon een bug waarom zou het dan in Android dan een feature heten?

[Sfynx]

Deze beveiliging zit dus in de apps? Dit zou toch eigenlijk binnen het besturingssysteem moeten zitten? Als je niet ingelogd bent en de app vraagt om media (of andere bestanden te zien) dan zou het OS toch moeten zeggen "dat mag niet"

Zou in sommige gevallen ook de werking van de app in de weg kunnen zitten, bijvoorbeeld de juiste naam bij een nummer zoeken zodra je vanuit gelockte toestand gebeld wordt, hoe los je dat dan op...

[BikkelZ]

Door verplicht te unlocken op het moment dat je verder gaat graven in het systeem. Zo werkt dat op iOS.

[supersnathan94]

Maar ook nummer herkenning werkt gewoon als je toestel locked is. Ook op iOS heb je meerdere typen.

Nummerherkenning werkt bijvoorbeeld niet na een reboot als je de code nog niet hebt ingevoerd. Daarna is contact info altijd beschikbaar vanaf het lockscreen. Anders kan Siri bijvoorbeeld zijn ding niet doen.

Er zijn ook op android meerdere lagen om dit soort issues op te lossen. Dit betekent echter wel dat deze systemen gevoelig zijn voor bugs. Op iOS is het dus al meermaals voorgekomen dat een nieuwe feature ervoor zorgde dat je via contacten dus het toestel basically normaal kon gebruiken. Alleen wel pas nadat je hem een keer had ontgrendeld met de code na een reboot

[BikkelZ]

Zo gauw je veiligheid aan derde programmeurs over laat is de kans bij miljoenen apps 100% dat minstens één app het verprutst of er misbruik van maakt.

[supersnathan94]

Ik denk alleen dat het artikel hierboven er iets meer sensatie uit wil halen dan er daadwerkelijk is. Het stukje versleuteling en ontgrendelen is ook op android ongeveer hetzelfde geregeld.

[mjz2cool]

En ook bij iOS heb je dit soort bugs bij heel veel versies.

[BikkelZ]

Bij iOS zijn het bugs bij Android features.

[Dnomyar96]

Je toestel unlocken als je gebeld wordt zodat je kan zien wie het is? Kost misschien een paar seconden tijd (maximaal. Met een vingerafdruk nog geen seconde). Het lijkt me toch dat beveiliging voor gemak moet gaan...

[mjz2cool]

Dat gaat nooit positief ontvangen worden. Je wilt toch "at a glance" kunnen zien wie er belt? Ze kunnen ook gewoon zorgen dat je helemaal niet bij o.a. de contactpersonen kunt komen door een bug in een app. Ik kan me geen reden voorstellen waarom je je contacten zou willen kunnen zien zonder unlocken, maar het is best logisch om te kunnen zien wie er belt.

[Helium-3]

Zowel Android en iOS hebben deze problemen veelvoudig, en inderdaad, zou niet mogelijk moeten zijn.
Maar ook bijvoorbeeld, mijn broertje installeerde ooit een custom lock screen app voor Android. Wat bleek? App werkte prima, maar bij het booten van het toestel startte de lockscreen app 20 seconde nadat de telefoon gestart was, en in die 20 seconden was het hele toestel te benaderen zonder code vereist!
Dat is fundamenteel een vreemd concept, dat dat mogelijk is...

[Verwijderd]

iOS is toch een stuk veiliger op dat vlak: de problemen die er waren, zijn altijd met foto's of contacten geweest, en dat heeft te maken met het feit dat foto's nemen en bellen mogelijk is vanaf het lockscreen.

Bij Android, zoals dit artikel illustreert, en dat illustreer je in je post ook nog eens met een simpel voorbeeld, staat de deur blijkbaar open tot de volledige telefoon, als het mis gaat.

[fapkonijntje]

Op iOS bestaat deze ellende ook. Dit is namelijk precies de manier waarop je bij verschillende iOS versies je lockscreen kunt omzeilen. Namelijk het activeren van Siri en via Siri andere apps openen. Precies wat hier met Skype ook gebeurt. Hier zijn gaandeweg beperkingen en fixes vanuit Apple aan toegevoegd, maar ook nu kun je er nog behoorlijk veel mee. En ja je kunt het omzeilen door Siri uit te zetten, zo kun je dit ook uitzetten op Android voor Skype.

Er zijn inderdaad gaten in iOS geweest die alleen foto's en contacten vrijgaven, maar er zijn er ook geweest die je berichten (imessage e.a.), e-mail en andere apps vrijgaven. Het verschil hier tussen iOS en Android zit 'm erin dat je op Android dus een app kunt maken die zoals Siri op iOS werkt (dus op het lockscreen) omdat het een open platform is. Dat kun je op iOS niet. Daar moet je Apple spullen gebruiken. Jammergenoeg maakt Apple redelijk grove fouten, waar bij Android het bewuste features zijn. Dat maakt beide dus even 'lek'.

[faim]

De dingen die jij noemt (met uitzondering van de bugs dan), zijn features in iOS. Ja, je kan ontzettend veel met Siri vanaf het homescreen, maar je kan het ook helemaal beperken, zelfs op app niveau. Dus dat is helemaal aan de gebruiker zelf om de afweging te maken voor bepaalde zaken, tussen handige functionaliteit en beveiliging.

[Verwijderd]

Je kan met Siri inderdaad vanaf het lockscreen bellen en berichten en e-mail sturen. Dat is gewoon een instelbare optie. Andere apps openen, contacten bekijken enz.. kan nooit.

Het probleem bij Android is dat het OS hier de security laat afhangen van de applicatie. Een app met slechte bedoelingen is dus voldoende om het OS te compromitteren. Het is uiteraard veel veiliger als het OS dit regelt.

[mjz2cool]

Eerder kon je het stock lockscreen toch niet eens uitschakelen? Ik weet nog wel dat je die wel kon omzeilen met zo'n 3rd party lockscreen, maar als die nog niet gestart was had je gewoon het stock lockscreen. Tegenwoordig kan het volgens mij wel uitgeschakeld worden, maar dan heb je dus ook geen fingerprint authenticatie meer.

[sjongenelen]

Eens. Ik vind het ook raar. Android staat het toe een eigen lockscreen te hebben, mogelijk dat het daar mee te maken heeft

[Cerberus_tm]

Tja, bij IOS zie je dit soort bugs heel vaak voorbijkomen op Tweakers, dus ik denk dat dit misschien een fundamenteel probleem is met de manier waarop de huidige lock screens werken. En dan hebben we het niet alleen over via Siri.

[KingFox]

Juist helemaal niet. Je raakt op iOS nergens voorbij het lockscreen, en als dat het geval is, is dat door een bug in iOS. De verantwoordelijkheid voor deze beveiliging zit 'm bij iOS in het OS en niet in de app.

[Loggedinasroot]

Apple heeft de laatste paar jaar toch echt heel veel beveiligings blunders gemaakt hoor.

iOS 12.1 lockscreen bypass

iOS12.0 Lockscreen Bypass

iOS10 Lockscreen Bypass

En dan heb je nog de macOS verhalen waar het wachtwoord niet gehashed wordt opgeslagen. Of waar je zo met root in kan loggen.

Uiteraard kan je je afvragen of een app dit moet kunnen op Android, maar met kdeconnect unlock ik mijn laptop ook wat toch wel handig is.

[Verwijderd]

Met lockscreen waren er inderdaad in een paar versies van iOS zeer tijdelijk wat problemen waardoor - via toch vrij ingewikkelde (maar reproduceerbare) manipulaties - foto's en of contacten toegankelijk waren vanaf een gelockte iPhone. Dat heeft te maken met het feit dat die data in bepaalde situaties (gedeeltelijk) toegankelijk zijn vanaf het lockscreen (bvb bij het nemen van foto's of bij het bellen, beide mogelijk zonder de telefoon te unlocken).
Dat is nog iets anders dan volledige toegang tot alle applicaties zoals hier het geval leek.

Wat MacOS betreft, citeer je niet correct. Het was bijvoorbeeld niet mogelijk "zo met root in te loggen". Het was in 10.13.0 mogelijk om - indien je reeds ingelogd was - in te loggen als root zonder paswoord. Dat is weliswaar een ernstig beveiligingsprobleem, maar in de praktijk kon een onbevoegde dus nog altijd niet in een Mac komen als die gelocked was met een paswoord...

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:29]

[fapkonijntje]

Je bent de blunders van Apple wel aan het downplayen door te zeggen; 'zeer tijdelijk wat problemen'. Het waren gewoon lompe fouten die er in sommige gevallen jaren in hebben gezeten. Deze Skype bug is ook binnen een korte periode opgelost dus hier zou je ook gewoon 'zeer tijdelijk wat problemen' van kunnen maken. Je moet en zou van een bedrijf dat zo arrogant en stoer doet met privacy en security hogere verwachtingen mogen hebben. Fouten als het openlijk neerplempen van een encryptiesleutel in een logfile is iets dat by design niet mogelijk zou moeten zijn, maar Apple krijgt dat soort idioterie meerdere keren voor elkaar.

Je hebt iets teveel de neiging om alles wat Apple doet met de mantel der liefde te bedekken. Het is maar een bedrijf en met het succes dat ze hebben en de miljarden in kas, hebben ze jouw verdediging echt niet nodig. Je zou juist kritischer moeten zijn tegen een bedrijf dat als enig doel heeft geld aan jou te verdienen. Net als dat je tegen Google, Microsoft en wie dan ook kritisch moet blijven. Vanwege de arrogantie is Apple een eng bedrijf, maar de fans die alles met de mantel der liefde bedekken als ze ter sprake komen en bij een nieuwsbericht zoals dit gelijk beginnen te vertellen dat iOS zoveel beter is, vind ik nog veel enger.

[Verwijderd]

Nee, het probleem met Skype is niet na drie maanden gefixed, andere apps kunnen gelijkaardige problemen hebben, er is een structureel probleem.

Het leidt geen twijfel dat bij iOS security beter geregeld is. Android speelt al jaren catch-up. Hoe lang heeft Android al app-level settings? En op hoeveel procent van de telefoons draaien die versies?

Nee Apple’s producten zijn niet vrij van bugs of security issues, maar bvb iOS zit structureel een stuk beter in elkaar als het over security gaat. En Apple is in geval van problemen in staat de dingen veel sneller te fixen.

Het is algemeen geweten dat veiligheidsdiensten geen probleem hebben om een Android telefoon te hacken. Met iPhones blijkt het meestal heel wat moeilijker en dikwijls zelfs onmogelijk.

[supersnathan94]

Het is kinderlijk eenvoudig om op een mac zonder filevault en efi password in te loggen met root. Dat heet single user mode.

[Progadgets]

Deze van Android is toch wel 10 maal erger. Bij iOS heb ik in het lockscreen toch alles uitgeschakeld.. Behalve de zaklamp en camera kan er niks geopend worden voordat m'n gezicht er voor zit. Dit valt dus ook totaal niet te verdedigen. Kan dus nu heel simpel een app in de store uitbrengen met een backdoor, redelijk ernstig..

[Loggedinasroot]

Ik denk dat dat een andere kijk is.
Je zegt zelf dat je alles hebt moeten uitschakelen van het OS om een veilig lockscreen te hebben. Dit terwijl de Skype app op hoeveel toestellen geinstalleerd staat?

Nu snap ik dat elke app dit dus kan doen. Ik neem aan(hoop ik) dat hier een permissie voor is.
Als je een wekker app installeerd op ios en hij gaat af, krijg je dan alleen een notificatie? Of is het ook mogelijk om eerst een rekensom te moeten oplossen of iets dergelijks?

[FreshMaker]

Ik denk dat dat een andere kijk is.
Je zegt zelf dat je alles hebt moeten uitschakelen van het OS om een veilig lockscreen te hebben. Dit terwijl de Skype app op hoeveel toestellen geinstalleerd staat?

Nu snap ik dat elke app dit dus kan doen. Ik neem aan(hoop ik) dat hier een permissie voor is.
Als je een wekker app installeerd op ios en hij gaat af, krijg je dan alleen een notificatie? Of is het ook mogelijk om eerst een rekensom te moeten oplossen of iets dergelijks?

Dit is de essentie van de bug / het probleem
Apps met (te) veel toestemmingen kunnen dan worden gebruikt om dieper in het systeem te raken.
Als je al privacyminded gebruiker al zoveel mogelijk oplet hoe en wat je toestaat, is het in één klap om zeep geholpen doordat een ( in dit geval ) skype, voor allerlei dingen toestemming nodig heeft.
Foto's, sms, contacten, camera, microfoon en zelfs locatie.

Dan heb je overal de boel dichtgetimmerd, en is er een ontwikkelaar die het allemaal voor niets heeft laten zijn.
Lockscreen moet juist DAT zijn, een slot.
Zonder credentials niet verder ...

Klok is dan misschien nog prima, maar dan moet je als gebruiker maar het ongenoegen nemen, en EERST ontgrendelen, voor je het gesprek kan aannemen, of dat ene berichtje kan lezen.

[Progadgets]

Het maakt niks uit dat ik dat allemaal uitschakel, want met face-id is dat voor mij alleen ,gelijk ontgrendeld😉Maar verdedig het allemaal maar😂

Wekker app, rekensom? Wtf

[mjz2cool]

Die instellingen helpen niet voor de bugs die er geweest zijn in iOS.

[shadow1967]

De iOS lockscreen heeft al meerdere keren onder vuur gelegen door ontwerpfouten die toelieten om toegang te krijgen tot apps en data. Lijkt dat sommigen jeugddementie tekenen vertonen. Voor een gesloten OS design zoals iOS waar alle componenten van dezelfde fabrikant komen zou ik me iets bescheidener opstellen en 2x nadenken. Iets minder tendentieus commentaar geven zou al een stap vooruit zijn. Apple maakt mooie producten op basis van een gesloten standaard. Je kan hun 'vereenvoudige' technische context niet vergelijken met het versnipperd 'open' Android, waar gescheiden (hardware) fabrikanten hun eigen ding mee doen. Google werkt net daarom aan een nieuw mobiel OS, waarbij het betere controle krijgt op de bescherming/afscherming van core functionaliteiten binnen het OS.

[KingFox]

Zoals ik dus ook zeg:

...en als dat het geval is, is dat door een bug in iOS.

En die zin zet ik erbij, met een reden. Het was inderdaad mogelijk om vanuit de camera, Siri en VoiceOver toegang te krijgen tot andere apps. En dat zijn inderdaad flows die getest hadden moeten worden. Ik vind het echter een belangrijke nuance dat die bugs in het OS genesteld zitten, waar Apple controle over heeft en snel een update kan pushen en het probleem oplost. Leg je de verantwoordelijkheid voor zulke problemen/mogelijkheden bij individuele developers, kan het voorkomen dat het probleem nooit opgelost raakt.

Android heeft een open karakter, maar is op een aantal vlakken hierop gelukkig aan het terugkomen. Zo beschikt de SDK met API-level < 28 nog over een manier om in-app de user te authenticeren op basis van fingerprint zonder een dialog te tonen dat er een vingerafdruk gevraagd wordt. Op zich geen security issue, maar dan leg je bij elke app developer de verantwoordelijkheid om een eigen dialog te maken, wat voor inconsistentie zorgt bij de gebruiker (bij de ene app ziet het er anders uit dan bij de andere app) en je kan moeilijk vertrouwen op de legitimiteit van zo'n dialog. Vanaf SDK 28 biedt Android een native dialog aan, hoogstwaarschijnlijk aanpasbaar via styling, maar wel consistent. Ter vergelijking, iOS heeft nooit iets anders aangeboden dan een native dialog die er in elke app hetzelfde uitziet. Minder aanpasbaar, wel transparant, herkenbaar en gebruiksvriendelijk.

Voorgaande paragraaf is wat offtopic, maar toont wel aan dat ze bij Android aan het werk zijn om toch wat van de goeie zaken over te nemen. Wat mij betreft hoeft er geen lockscreen van een derde partij toegelaten te worden en mag het OS dit dichttimmeren, samen met bijhorende acties vanop het lockscreen. Immers kan je nooit vertrouwen dat een lockscreen je security pattern zou doorsturen. Bugs zoals beschreven in het artikel vallen op die manier steeds beter te elemineren.

[unreal0]

Wat mij betreft hoeft er geen lockscreen van een derde partij toegelaten te worden en mag het OS dit dichttimmeren, samen met bijhorende acties vanop het lockscreen

Een van de redenen dat ik bij Apple ben weggegaan is het niet kunnen kiezen van een eigen lockscreen. Dit met Skype is natuurlijk een ernstige bug, maar als je een lockscreen van een derde partij gaat instellen weet je toch wel waar je mee bezig bent? Ik vind het heerlijk dat ik op Android lekker zelf mag bepalen welk lockscreen ik gebruik in plaats van dat Apple dit me oplegt. Nu heb ik een lockscreen met ingebouwde Sonos en Spotify controls, eigen tijd/datum notatie, en snelle shortcuts voor data, wifi, zaklamp, camera etc. (Zonder dat ik daar eerst nog een andere handeling voor moet nemen). Ook kan ik de notificaties lekker weergeven zoals ik zelf wil. Minder veilig? Waarschijnlijk wel. Maar Apple heeft de afgelopen Jaren zoveel security flaws gemaakt met het lockscreen (iOS, maar ook macOS) dat ik ze daar niet mee vertrouw. Met een custom lockscreen kan ik met de app permisions tenminste zelf bepalen wie en waar toegang tot wat heeft.

[KingFox]

Wow, weggaan puur omwille van één feature? Beetje gekke beslissing me dunkt... De functies die je opnoemt en wil hebben op een lockscreen, staan standaard ook op een iOS lockscreen.

Mooi dat je zegt "heerlijk dat ik zelf mag bepalen wel lockscreen ik gebruik", vooral omdat je vertrouwt puur op "app permissions" en bij het afwijzen van iOS lockscreen afgaat op de security flaws die gevonden worden in een OS-lockscreen dat door miljoenen mensen wordt gebruikt. Android is de laksheid zelve als het gaat op controle van permissies en opgeleverde apps. Mijn APK voor Android is op 1-2-3 geüpload in de Play Store. Bij Apple ligt mijn IPA momenteel voor de 3e keer bij een reviewer, waarbij ze eerst werd afgekeurd door een issue met een gebruikt framework, de tweede keer voor een probleem met screenshots

Als mobile developer zijnde (met ervaring voor zowel iOS als Android), kan ik je meedelen dat de kans op security flaws in een third party lockscreen (met misschien tienduizenden gebruikers) groter is, want veel gebruikers gaan enkel the happy path doorlopen en niet actief zoeken naar manieren om de lock screen te omzeilen. Issues zullen dan ook minder snel aan het licht komen en doorgegeven worden aan de developer. Gaat de developer aan de slag met die issues? Geen idee. Door de zwakke controle op de Play Store heb je, ondanks de toggles voor permissies, echt geen idee wat je app allemaal in de achtergrond nog allemaal doet. Misschien wordt nu wel elke notificatie die je krijgt wel doorgestuurd naar een backend? Of je loginpatroon? Wie zal het zeggen... In ieder geval, ik vind het lockscreen core functionaliteit van het OS die je - naar mijn mening - niet zomaar aan eender wie mag/kan toevertrouwen, gezien de belangrijke functie die het vervult.

[mjz2cool]

Je vertrouwt niet apple met het lockscreen die best wel een paar keer een bug heeft gehad die ook snel is opgelost, maar vertrouwt wel 3rd party apps, als een bug in bijvoorbeeld skype er al voor kan zorgen dat je toegang tot bepaalde delen van het os hebt?

[Reactie gewijzigd door mjz2cool op 22 juli 2024 16:29]

[latka]

Wellicht kun je daar een deel mee afvangen, maar het deel wat in de app zit mag de app zelf afvangen.

[Christoxz]

Wat een raar artikel eigenlijk. Er zit namelijk helemaal geen bug in Skype, de bug zit overduidelijk in Android zelf.
Skype heeft niks te maken met opstarten van andere apps via de browsers, fotos die staan opgeslagen etc. Dat hoort het OS tegen te houden.

Skype zou bevoegd mogen zijn om een link te openen via de standaard browser van het OS, maar op dat moment moet het OS voorkomen dat de browser apps kan openen. Dat valt buiten de verantwoordelijkheid van Skype.

Skype heeft (waarschijnlijk) per ongeluk gebruikt gemaakt van een bug in Android.
Vind het maar raar dat deze bug op deze manier in de media staat.

[Reactie gewijzigd door Christoxz op 22 juli 2024 16:29]

[latka]

Wat een rare gedachte: als jij gebeld wordt wil je toch ook dat Skype je de naam laat zien van de beller? Dan moet Skype dus in de contacten database. Als het OS dat niet toe zou laten dan ben je ook verdrietig. Waar trek je dan de grens? Als een app een RSS feed bewaakt en een alert geeft op het lockscherm over een veranderde web pagina dan wil je toch ook die link kunnen openen of moet het OS gewoon alles tegenhouden? Dan moet een lockscreen gewoon doen waar het voor gemaakt is en ALLES tegenhouden.

[Christoxz]

Dan zijn hele andere functies dan waar het probleem nu ligt.

Door de bug kon je als gebruiker (Dus niet als Skype) de contacten inzien, inclusief alle telefoonnummers. Dat is dus niet alleen de naam wie er op dat moment belt.

Browser openen vanuit een notificatie is ook zeker geen probleem, wel dat deze browser app dan weer andere apps kan openen terwijl je telefoon nog vergrendeld is.

De gebruiker kon ook al mijn foto's inzien, dat is natuurlijk niet de bedoeling?

Dan moet een lockscreen gewoon doen waar het voor gemaakt is en ALLES tegenhouden.

Een lockscreen moet inderdaad al mijn gevoelige gegevens tegenhouden totdat ik hem heb geunlocked

[latka]

Dus de telefoon opnemen (of in dit geval skype) mag niet vanuit het lockscherm. Helder en mee eens.

[WhatsappHack]

Eigenlijk is het min of meer een bug in beiden, maar dat het met Android blijkbaar kan is wel het meest serieuze probleem. Immers betekend dat dat elke app potentie heeft om je telefoon in te komen. Dat kan niet kloppen en leg je wel bizar veel vertrouwen in appdevs... Ook die vanuit onbekende bronnen.

[Christoxz]

Ligt er aan hoe je het ziet, ik vind persoonlijk van niet want Skype zou zich niet bezig moeten houden in welke status je telefoon is en bepalen of het wel of niet mag.

Ik vind dat Skype al helemaal niet hoeft te weten of mijn telefoon gelocked is en of er uberhaupt een wachtwoord op zit. Skype moet natuurlijk ook weer mee om gaan wanneer je geen beveiligingen hebt, dat het wel toegestaan is.

Skype moet puur luisteren wat wel of niet mag, en het OS moet bepalen wanneer iets wel of niet mag. Nu geeft het OS toegang tot iets wat eigenlijk niet zou mogen. OS zou dit moeten aangeven, en Skype runt een fallback voor friendly foutmelding.

Als de bug in beide zou zitten, betekent dat er functionaliteit dubbel word geschreven.
Skype check of je gelocked bent en houd iets tegen, en het OS checkt of je gelocked bent en blokkeert de actie.

Dan is het beter dat Skype te horen krijgt of hij geen of wel toegang heeft, en laat dan een error zien.

[Reactie gewijzigd door Christoxz op 22 juli 2024 16:29]

[densoN]

Het vreemde aan dit verhaal is het feit dat de bug in de app zit en niet in het OS. In theorie kan dus iedere app bouwer een backdoor inbouwen om het lockscreen te omzeilen.

[Christoxz]

Dus feitelijk zit de bug juist in het OS en niet in de app.

[Reactie gewijzigd door Christoxz op 22 juli 2024 16:29]

[svenk91]

Het zou logischer zijn als apps geen andere apps kunnen openen zolang de telefoon nog niet unlocked is idd. In dit geval zorgt MS zelf dat dit niet meer kan vanuit de skype app, maar het lijkt mij beter als dit op OS niveau wordt opgelost.

Of het een bug valt te noemen is maar de vraag, het is niet persé een fout in de software (app of OS), maar wel een security risk.

[Christoxz]

Er is geen twijfel aan mogelijk of dit een bug is of niet. Het is overduidelijk dat het een bug is in het OS.
Het OS hoort te controleren of de interactie bevoegd is om uitgevoerd te mogen worden.
Het OS hoort er voor te zorgen dat het systeem beveiligd is voor onbevoegden.

Skype zou niet bevoegd mogen zijn om deze interacties(Toegang tot fotos bijv) uit te voeren wanneer het toestel nog geblokkeerd is. Deze zou dan wel de standaardbrowser mogen openen van het systeem, echter zou die browser op dat moment niet bevoegd mogen zijn om andere apps te openen, dit zou buiten Skype hun verantwoordelijkheid moeten vallen, dit hoort het OS te beveiligen.

Zoals @densoN al vermelde:

In theorie kan dus iedere app bouwer een backdoor inbouwen om het lockscreen te omzeilen.

Overduidelijk dus een bug in het OS.

[Reactie gewijzigd door Christoxz op 22 juli 2024 16:29]

[FreshMaker]

Maar dat is nu juist het probleem.

Het OS controleert of Skype geopend mag worden van het lockscreen -> check - dat mag
Maar het probleem is dieper, omdat Skype mag, mogen ook alle permissies die skype heeft gekregen -> kan je dieper in het systeem komen

Zou het aan het OS liggen, zou er een schakeling moeten zijn (simplistisch ) If skype open - lockscreen -> no acces to media
Maar dan moet dus zowel het OS als Skype doorhebben HOE het geopend is, is het vanuit de beslotenheid van het lockscreen, of vanuit de veilig geopende app-drawer

* FreshMaker is geen programmeur ... maar dat is al wel duidelijk

[Christoxz]

Het OS controleert of Skype geopend mag worden van het lockscreen -> check - dat mag
Maar het probleem is dieper, omdat Skype mag, mogen ook alle permissies die skype heeft gekregen -> kan je dieper in het systeem komen

Dus ligt de fout aan het OS. Het OS moet tegen houden dat alle overige permissies ineens toegestaan zijn.
Hou er ook rekening mee dat de standaardbrowser (Die Skype heeft opgestart maar kan bijvoorbeeld gewoon Chrome/Opera zijn) de andere apps opstart. Dat hoort ook het OS tegen te houden. Dat ligt al helemaal niet aan Skype meer.

Maar dan moet dus zowel het OS als Skype doorhebben HOE het geopend is

Nee, alleen het OS moet doorhebben hoe het geopend is.
Skype moet van het OS horen of het nog in locked status is of niet, zodat Skype een friendly fout melding kan geven.
Stel deze check zit er bij Skype niet in, zou het OS het alsnog tegen moeten houden.

Skype moet puur luisteren wat wel of niet mag, en het OS moet bepalen wanneer iets wel of niet mag

[Reactie gewijzigd door Christoxz op 22 juli 2024 16:29]

[latka]

Wat jij voorstelt is een security model wat je vrijwel nergens vind (iig. niet op mobiele devices). Ook windows & unix werken niet zo. Maar werk het uit, patenteer het en loop binnen.

[GekkePrutser]

Precies, dit zou zo'n grondige verbouwing van android zijn dat het een heleboel bestaande dingen stuk zou maken.

Wellicht dat we zoiets wel gaan zien met Fuchsia, dat wordt helemaal vanaf de grond opgebouwd. Android is immers gebouwd in de tijd dat men snel mee moest kunnen omdat de smartphone razendsnel aan het innoveren was. Een maand later implementeren betekende achterblijven en marktaandeel verliezen. Dat heeft geleid tot een rommelige basis waar je niet zomaar vanaf kan stappen.

Nu met Fuchsia is die druk er niet en kunnen ze zich richten op veiligheid en hopelijk zelfs wat privacy (er schijnt al flinke discussie te zijn tussen de Fuchsia privacy voorstanders binnen google en de advertentie afdelingen).

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 16:29]

[latka]

Wat @chriistiix voorsteld is om rechten toe te kennen aan de tuppel (gebruiker, applicatie) ipv. alleen gebruiker of alleen applicatie. Dat kan (en daar zijn wel voorbeelden van in ultra secure omgevingen) maar ik ken geen 'normaal' os wat dit doet (SELinux komt in de buurt, maar dat is een drama qua onderhoud). Leg maar uit aan een gebruik: je mag bestand X alleen met applicatie Y openen (en dan alleen vanuit locatie Z als je het echt goed wilt doen). Als Fuchsia dit model omarmt denk ik dat het snel voorbij is.

[GekkePrutser]

Android gebruikt juist al SELinux Wordt onder meer gebruikt voor de sandboxing. Dus dat is al iets waar rekening mee wordt gehouden.

[latka]

Kijk, zo leer ik wat ;-) Helden: meeste beheerders die ik ken zetten SELinux op warnen ipv. blokken omdat het zo'n reeks warnings oplevert. Moet ik me even in de android SELinux policy inlezen ;-)

[Verwijderd]

Volgens mij is dit wèl wat iOS doet: "All third-party apps are “sandboxed,” so they are restricted from accessing files stored by other apps or from making changes to the device. This prevents apps from gathering or modifying information stored by other apps. Each app has a unique home directory for its files, which is randomly assigned when the app is installed. If a third-party app needs to access information other than its own, it does so only by using services explicitly provided by iOS.
System files and resources are also shielded from the user’s apps. The majority of iOS runs as the non-privileged user “mobile,” as do all third- party apps. The entire OS partition is mounted as read-only. Unnecessary tools, such as remote login services, aren’t included in the system software, and APIs don’t allow apps to escalate their own privileges to modify other apps or iOS itself."

[latka]

Iets dergelijks doet Android onder water ook (unix user per applicatie). Maar dat is een alles of niets filter. Maar het is lastig voor het OS om onscheid te maken als het verzoek uit Skype komt voor iets dat het de ene keer wel en de andere keer niet mag. Kan wel met een globale vlag (screenlock staat aan) maar wat mag de app dan niet? Je contacten openen? Maar dat is nodig voor het tonen van de details van de beller. Dus de contacten DB ligt zowiezo bij de appbouwer. Browser had gekund maar in mijn eerdere voorbeeld (RSS notifier) wil je juist wel dat er een webview geopend kan worden (maar dan bijvoobeeld alleen naar die pagina, maar dan moet JS ook uitstaan anders krijg je met een redirect gewoon alsnog de verkeerde site voor je snufferd). Het is dus een lastig probleem zonder algemene oplossing (van het OS moet het maar regelen). Dit is echt aan de appbouwer: als die de mogelijkheid gebruikt vanaf het lockscreen iets te tonen dan is de app ook verantwoordelijk hier goed mee om te gaan. Meer dan 3 maanden nodig hebben voor een bugfix hiervan toont alleen maar aan dat mensen en Microsoft dit helemaal niet boeit.

[Verwijderd]

Bij iOS hangt het niet af van de appbouwer. Android is hier gewoon te lax/slordig. Dat wordt ooit wel gefixed:qua security heeft Android al veel inhaalslagen gemaakt.

[mjz2cool]

In ieder geval wel bij iOS.

[Verwijderd]

Volgens mij is dat geen bug in het OS maar een missing feature? Jij beschrijft hoe het zou moeten werken, maar blijkbaar is het zo niet ontworpen?

[Christoxz]

Dus vind ik het een bug, want het OS zou sowieso mijn gevoelige gegevens moeten beschermen. Dat is in dit geval mislukt.

[mjz2cool]

Gewoon simpelweg: is de telefoon locked? Dan mag je opnemen als je gebeld wordt (skype, whatsapp, of normale telefoon, etc), of eventueel chatten (al kan dat prima achter slot en grendel), maar verder mag je niks, in welke app dan ook.

[Verwijderd]

Het zou logischer zijn als apps geen andere apps kunnen openen zolang de telefoon nog niet unlocked is idd.

Maar dan kan je ook niet meer zien wie er belt.... Dat zou een limitatie zijn waar de meeste gebruikers niet mee zouden kunnen leven.

[mjz2cool]

Nee dat is dus een feature die dan misbruikt wordt. Het is "working as intended". Al vraag ik me af waarom dat moet kunnen.

[RobinJ1995]

Nee. Ontwikkelaars krijgen APIs ter beschikking gesteld, en worden zelf verwacht enige competentie te hebben en hier dus rekening mee te houden.

[latka]

Dat is niet zo vreemd. Dat kan ik ook op een desktop PC met een eigen .scr screensaver.

[Rabbithole]

Microsoft heeft het nu opgelost, maar zit het probleem niet dieper, bij het Android OS? Het besturingssysteem had m.i. nooit toegang mogen geven tot deze functies zolang de code niet is ingevoerd.

Edit: zoals hierboven ook aangegeven door medetweaker StefanJanssen

[Reactie gewijzigd door Rabbithole op 22 juli 2024 16:29]

[DigitalExorcist]

Op ongeveer dezelfde manier kun je om de Android Factory Reset Protection heen. Vanuit dat scherm (“log in met het ID van de eigenaar van deze telefoon” voordat je een Factory Reset kan doen) kun je naar de WiFi-settings, daar vandaan naar de Instellingen, daar vandaan een backup maken en restore aanzetten en weg is je FRP. Tenminste, op een oude(re) LG G4 is me dat gelukt.

Maar ja. Misschien is dat inmiddels wel aangepast.. dat soort omzeilingen kom je nog verrassend vaak tegen...

[djwice]

Bij mij kun je skype alleen openen met vingerafdruk en vanuit skype naar browser weer, ik gebruik hier een apparte app van Microsoft voor die de Office 365 apps extra beschermd; Microsoft Authenticator.

[Reactie gewijzigd door djwice op 22 juli 2024 16:29]

[Luchtbakker]

Dat krijg je dus als je de lockscreen alleen aan software over laat en niet laat combineren met een beveiligingchip.

[Eagle_Erwin]

Volgens mij is (was) dit wel degelijk een bug in Skype. De mogelijkheden die genoemd worden, zijn (bijna) allemaal mogelijk BINNEN de app:

- Contacten zien
- Foto's bekijken
- Browser openen (ingebouwde browser in Skype)

De enige optie die daar niet onder valt, is het openen van andere apps via de browser. En laat dat nu net de optie zijn die niet in de video getoond wordt (daar kun je alleen andere apps zien binnen de browser, wat eventueel al als een privacy-lek gezien kan worden).

Zolang alle problemen zich binnen de app afspelen, is het gewoon een probleem in Skype en heeft Android daar geen invloed op. Ik neem aan dat bij het kiezen van een andere app binnen de browser alsnog een blokkade wordt gegeven.

[latka]

Ongeveer 90 dagen nodig voor een triviale bug. Dat belooft wat bij de volgende serieuze bug.

[SinergyX]

Er is helemaal niets opgelost aan de bug, buiten dat de app dit 'trucje' niet meer kan, blijft de bug gewoon in het OS zitten. Een elk kan met soortgelijk systeem in een andere app dit nabouwen en misbruiken, omdat er geen fix is van het OS, enkel een app.

In this case, the Skype app allows users to access the photo and contact features without first checking if the person using the device was authenticated

Een OS hoort dit af te roepen op een app, niet een app op het OS.

[latka]

Flauwekul: als jij gebeld wordt met het scherm gelocked, wil je dan de naam van de beller zien? Ja: dan moet het OS het niet tegenhouden. Als je niet wilt zien wie je belt dan moet het lockscreen gewoon het lockscreen blijven. Je kunt niet van 2 walletjes eten. Als je als app door het lockscreen heen iets wilt dan heb je als appbouwer de verplichting dit goed te doen, ipv. brodelwerk. Zie ook de hele reeks aan iOS lockscreen bugs. Noem mij 1 platform waar het anders werkt?

[Verwijderd]

De iOS lockscreen bugs (toch die van de laatste jaren, we hebben het niet over de begindagen van iOS) zijn altijd problemen geweest waarbij bepaalde acties/data die kunnen via het lockscreen, maar met beperkingen, zonder bepaalde van die beperkingen konden worden uitgevoerd. Het ging dus om de telefoonfuncties (en de contacten) en de camerafuncties (met de foto's). Het ging nooit om andere applicaties en om andere data. Net omdat iOS de beveiliging niet overlaat aan een appbouwer, en het OS dus niet zal toelaten dat een app het lockscreen compromitteert.

Als de beveiliging van een compleet systeem afhangt van of een appbouwer iets goed doet, dan zit er toch iets fout in de opzet van het OS.

[latka]

Sorry, maar die laatste opmerking is raar: iedere browser bug (gemaakt door die verdomde appbouwers) had door het OS geblocked moeten worden. Je voelt dat dat niet gaat werken. Het enige OS wat aan jouw eis voldoet is een OS wat geen applicaties toestaat. Prima.

[Verwijderd]

Ik denk dat je vanalles door elkaar haalt: een bug van een applicatie zal bij een goed gebouwd OS nooit een andere applicatie of de data daarvan compromitteren, noch het systeem zelf.

[latka]

Ik denk het niet. Als je applicatie een bug heeft (een goed voorbeeld is de browser) dan kan je van alles doen. Het OS kan hier weinig aan doen. Browser beschermen de gebruiker door een sandbox aan te leggen en te hopen dat je hier niet uit kunt breken. Doet het OS niet zoveel voor.

[Verwijderd]

Een sandbox is een functionaliteit van het OS. Als een applicatie ( ook een browser) correct gesandboxed is (dus door het OS), dan kan de applicatie niets wat het OS niet toelaat.
Er valt niets te “hopen”.
Ook bij Android hoort dit zo te werken: toegang tot systeemfuncties die security gevoelig zijn en tot andere data dan die van de app zelf, horen alleen te kunnen via app permissies.

[latka]

Lees even hoe Chromium het doet: https://chromium.googleso...er/docs/design/sandbox.md dan zie je dat het OS onvoldoende bied: slechts een paar primitieven om het te regelen de rest is echt voor de appbouwer.

[Verwijderd]

In Chromium is de browser het OS. Dus de browser - als hij goed is ontworpen - verzorgt de security. Ik zie echt niet waar “de appbouwer het moet regelen”. Dat zou natuurlijk waardeloos zijn!

[latka]

Zucht. De browser het OS. Sure.

[Verwijderd]

Chrome OS is een minimale Linux-distributie met de Chrome-browser als enige applicatie. Dus de browser is de facto een onderdeel van het OS. Bij andere OSen is een browser een applicatie als een ander.

[svenk91]

Maar dan beperk je apps heel erg in hun mogelijke functionaliteit. Apps als Skype en Whatsapp kunnen dan niet meer bij je contactenlijst (immers zou een 'bug' er voor kunnen zorgen dat die 'perongeluk' naar de app bouwer zijn/haar server wordt verstuurd) en namen kunnen tonen van met wie je chat/belt zonder een eigen losstaande contactenlijst te onderhouden. Of snapchat mag geen foto doorgestuurd krijgen van een camera app, en mag google maps nog wel bij de service die gps coördinaten doorgeeft?

Dan kom je weer redelijk in de buurt van het iPhone OS 2 (een voorloper van iOS, toen APIs tussen applicaties nog niet echt een ding was) waar je nog niet kon copy-pasten tussen apps. Ook zaken als toegang tot de Maps APIs kwamen pas met iPhone OS 3. iPhone OS 1 kon geeneens 3rd party apps aan, en zonder jailbreak waren de eerste iPhones gewoon feature phones voor de release van de app store.

[mjz2cool]

Dat kan heel makkelijk: de app stuurt een request, en het os geeft een naam en andere gegevens terug. Het lockscreen kan prima alles nog tegenhouden.

[tonkie_67]

Dit hoeft helemaal geen bug te zijn, maar "working as desinged" (wad) en functionaliteit opzettelijk aan de apps overlaten. Je kan dan wel zeggen dat het design flawed is (vind ik ook, idiote gedachte om dit niet door het os te laten regelen) naar t is dan geen bug...

[Fjutrackx]

Hmm.. Ik ken persoonlijk een andere unlockmethode die werkt NA een factory reset bij onderandere een Huawei P20 Pro. Niet zo kritisch omdat ik niet aan de data kan, maar ik kan hiermee wel iemands telefoon "lenen voor onbepaalde duur". Ik heb die methode nog niet getest op andere toestellen. Gezien het een tijdje geleden is dat ik hiermee gespeeld heb is de bug mogelijk al gepatcht, maar gezien het vrij specifiek was lijkt de kans klein. Ik ken de details niet meer helemaal, maar ik maakte gebruik van de preloaded Huawei software.