Hacking Team had backdoor-app in Play Store - update

Hacking Team had een app in de Play Store die zich voordeed als een nieuws-app, maar die in de praktijk kon worden gebruikt om een backdoor op een Android-apparaat te installeren. Malafide code werd pas na installatie gedownload en dus niet opgemerkt door de Play Store.

De app gebruikte de naam van een nieuwssite over BeOS die inmiddels niet meer bestaat, BeNews, om geen argwaan te wekken. Volgens Trend Micro stond de app tot vorige week dinsdag in de Play Store, en was hij tot dan toe vijftig keer gedownload. De app werd verwijderd kort nadat een aanvaller een grote hoeveelheid bestanden van Hacking Team liet uitlekken. Het is onduidelijk of Google de app heeft verwijderd, of dat Hacking Team dat zelf heeft gedaan om de schade te beperken.

De valse nieuws-app haalde zijn kwaadaardige code van internet. Dat had een groot voordeel: op het moment dat de app door de scanner van Google werd gehaald, was die code niet aanwezig, waardoor geen alarm werd geslagen.

Hacking Team gebruikte een exploit-tool die in ieder geval Android-versies 2.2 tot en met 4.4.4 kon kraken, maar het is mogelijk dat ook andere Android-versies zijn getroffen. Trend Micro denkt dat de app vervolgens een spionagetool van Hacking Team installeerde, RCSAndroid, waarmee data van het apparaat kan worden gehaald.

Vorige week werd bekend dat Hacking Team, een Italiaans bedrijf dat spionagesoftware levert aan overheden, is gehackt. De aanvaller gaf daarbij een grote hoeveelheid interne informatie vrij. Daaronder waren gevoelige interne e-mails, maar ook werkende zero day-exploits in software als Flash.

Update, 16:30: In dit artikel stond dat Google de inhoud van apps niet met de hand controleert, maar sinds begin dit jaar doet het bedrijf dat wel.

Reacties (64)

[Verwijderd]

Ik vind het bijzonder, dat Apps 'als ze hun code later zelf van internet halen' en daarmee illegale bevoegdheden verkrijgen allemaal wel gewoon door de malware scan van google heenkomen... Het maakt elke App die 'iets mag downloaden' tot een potentieel paard van Troje.

[Verwijderd]

Dat zou inderdaad vreemd zijn, maar ik neem aan dat ze nog wel eea hebben moeten omzeilen om uitvoerbare code te installeren. Misschien dat een mede tweaker die android apps ontwikkelt dit weet?

[iChaos]

Als je code wilt uitvoeren binnen een sandbox kun je het schrijven in C met de NDK en die binary downloaden. Met shell access werden zo bijvoorbeeld hele chroot-omgevingen opgestart om een CLI voor Linux-distributies te installeren op een Android-toestel. Binary code is dus vrij makkelijk in te laden en uit te voeren. Combineer dat met een privilege escalation exploit en een vulnerability, en je kunt je code alles laten doen op het toestel. En zulke bedrijven hebben zeker genoeg vulnerabilities achter de hand. Ontwikkelaars als geohot kwamen al vaak genoeg exploits tegen in libraries die Android gebruikt, waarna ze er alleen een payload voor moesten schrijven om binaries naar /system weg te schrijven. Een goede Linux-rot die ook iets weet van lk of aboot, kan programmeren in C en een vulnerability in de hand heeft draait binnen hoogstens een paar dagen een backdoor in elkaar.

[Artimunor]

Zou android M, of de Cyanogen app permissions hier tegen werken?
Als de permissions niet escaleren, zou het in principe wel dicht moeten zijn toch?

[iChaos]

Naja, het vervelende is dat privilege escalation de beveiliging van de sandbox negeert. Er wordt geen gebruik gemaakt van ingebouwde functies om uit de sandbox te komen. Exploits gebruiken meestal vulnerabilities in libraries die gebruikt worden, of een beveiligingsfout die er door de fabrikant in is gelaten. De Galaxy S3 en latere toestellen met Exynos chipsets hadden bijvoorbeeld om de een of andere reden een device node open laten staan die door iedereen aangesproken kon worden. Via /dev/exynos-mem kon je met een gewone shell met wat trucjes superuser-rechten krijgen. Zie ook:

http://blog.azimuthsecuri...s-memory-mapping-bug.html

Die exploit bleek daarna in aangepaste vorm ook te werken op andere processoren. Een developer op XDA had hem aangepast waarna hij ook op Mediateks en Snapdragons werkte.

Sowieso is Azimuth Security een hele goede bron voor informatie op dit gebied, omdat hij beveiligingslekken en payloads voor Android goed kan reverse engineeren en uitlegt hoe het werkt.

En wellicht leuk, hier trekt hij een jailbreak voor iOS uit elkaar voor wie eens wil zien hoe dat wordt gedaan:

http://blog.azimuthsecuri...c-dissecting-evasi0n.html

Kortom, de beveiligingsmaatregelen binnen Android zijn niet echt nuttig om dit soort zaken te voorkomen. In de tijd van de PSP waren er al methodes om er homebrew op te draaien door naar 'Over PSP' te gaan, te kijken welke versie van libtiff er op stond, daarna in een database te zoeken naar bekende beveiligingsproblemen en daarna een gemanipuleerd .TIFF-bestand te laden dat een payload bevat. Dat is op Android ook gedaan met - ik meen - libpng.

De enige manier om dit fatsoenlijk dicht te timmeren is het blokkeren van toegang tot een shell, omdat je vanaf daar kunt tinkeren met het interne systeem. Rooten en unlocken e.d. blijft alsnog wel mogelijk dankzij het beschikbaar zijn van de source code van kernels, dus de ramdisk kan ook nog gemanipuleerd worden om vanaf daar het systeem aan te kunnen spreken, maar dan moet een backdoor al iets hebben om het opstartproces te kunnen kapen en kunnen apps zoals deze in ieder geval geen schade meer aanrichten.

In zekere zin is een root op je toestel daarom wel veilig, want daarmee kun je tenminste alle shell access blokkeren en voorkomen dat binaries die in apps zitten mogen draaien.

[Cerberus_tm]

Met Xprivacy kun je shells en libraries blokkeren. Ik sta die niet toe voor applicaties waarvan ik de bron niet vertrouw. Denk je dat dat helpt?
https://cdn-images.xda-de...3/2014-01-24_19.26.00.png

P.S. Dat screenshot is al oud, en ik denk dat Marcel Xprivacy inmiddels nog wel beter heeft gemaakt zelfs.

[iChaos]

Ja, als je shells en libraries blokkeert kunnen er in principe geen backdoors worden geinstalleerd, omdat exploits dan niet benut kunnen worden omdat je niet met de kernel of de onderlaag van Android kunt praten. Kwaadaardige code zal dan dus alleen zijn werk kunnen doen via Java-code die al in de app zat, maar dan zal het alleen bij de bestanden kunnen komen waar de app permissies voor vroeg.

Het gevaar van apps die uit zichzelf al code hebben die kwaadaardig is (SMS sturen, contacten doorsturen, WhatsApp-gesprekken uit je SD-kaart lezen en die doormailen) voorkom je er niet mee, maar je houdt in ieder geval wel alles in de eigen sandbox, waardoor je bij het verwijderen van de applicatie ook zeker weet dat die app geen sporen kon achterlaten.

Het blokkeren van shells en libraries in combinatie met App Ops om te voorkomen dat apps via de Android API's bij je persoonlijke data kunnen komen is dus voldoende om te voorkomen dat malicious code zijn werk kan doen.

[Cerberus_tm]

OK Xprivacy laat je ook kiezen tot welke bestanden een applicatie toegang heeft. Ik geef een applicatie standaard alleen toegang tot bestanden/mappen waarvan ik redelijkerwijs denk dat hij die echt nodig heeft. Dus mijn 3rd-party Whatsapp-widget (waarmee ik berichten kon sturen zonder de app te openen en zonder dat men kon zien dat ik online was) gaf ik wel toegang tot de bestanden van Whatsapp, maar verder gaf ik die toegang aan geen enkele andere applicatie.

Verder kan Xprivacy alles wat App Opps kan, en (vermoedelijk veel) meer. Je kunt kiezen welke contacten of welke accounts een applicatie mag zien. Je kunt installen dat apps een pop-up tonen om toestemming te vragen tot elke permissie. Xprivacy laat je de toegang blokkeren tot veel meer permissies dan die welke App Opps / LBE herkennen, zo zegt de maker.

Die pop-ups maken het heel gebruiksvriendelijk, maar door zijn ingewikkeldheid is Xprivacy wel iets minder gebruiksvriendelijk dan App Ops uiteindelijk, zo vermoed ik. Verder geen reclame hoor hehe.

[Reactie gewijzigd door Cerberus_tm op 25 juli 2024 20:56]

[_Thanatos_]

Of App Ops op Android 4 en 5.

Ja. Je kunt een app daarmee de toegang tot internet ontnemen.

[Toff]

Ja. Je kunt een app daarmee de toegang tot internet ontnemen.

Ja, maar een nieuwsapp haalt by design data van internet, dus die zou ik rustig toestemming geven...

[_Thanatos_]

Het is ook een kwestie van de developer vertrouwen. Het is ook nooit anders op een desktop, waar een applicatie altijd alle rechten heeft, en je geen van die rechten kunt ontnemen/controleren.

[Toff]

Vertrouwen is belangrijk, maar daarnaast houdt mijn firewall op mijn desktops ook bij welke applicatie naar buiten wil. Dan is het aan mij om wel/geen toestemming te geven, eventueel eenmalig of permanent.

[BoomSmurf]

Typisch dat je Geohot als vorobeeld neemt, hij loopt regelmatig met de credits weg voor exploits die door anderen gevonden zijn. Door veel exploiters wordt hij niet echt serieus genomen...

[Verwijderd]

Er zijn natuurlijk wel meer Apps die 'code' laden na de originele playstore Download. Maar wat eigenlijk het ergste is, dat nadat je zo'n paard van Troje binnenhaalt dat,

• De gedownloade code niet wordt gescanned.
• Als de app z'n 'werk' gaat doen, dat die dan niet wordt opgemerkt.

Google heeft immers op alle google-android telefoons, Google play services permanent op de achtergrond draaien.
Daarin zou je toch zeggen dat de 'harmful app detection' in google services beide gedragingen scant als de app al geïnstalleerd is zou moeten oppikken.

[Verwijderd]

misschien een enigzins loze comment dit.. maar daarom heb ik dingen als malwarebytes en NOD32 op mn telefoon draaien... 3x in de week ff scannen... hoppa

[HollowGamer]

Dat doet vrij weinig:
App schraapt de gegevens bij elkaar, maakt er een (encrypted) archive van en stuurt het vervolgens naar de desbetreffende server. Met het huidige internet verkeer wordt niet alles naar buiten (meer) gescand. Daar gaat je ESET en Malwarebytes.

Het enige dat helpt is een tool als SELinux die toeziet op rechten. Maar zelfs dan is er veel mogelijk.

[Reactie gewijzigd door HollowGamer op 25 juli 2024 20:56]

[Verwijderd]

Je bedoelt SELinux wat is ontwikkeld door de NSA ? Ja, dat gaat inderdaad bijdragen aan jouw privacy als overheden je juist willen aftappen.

[Cerberus_tm]

Met Xprivacy kun je alle shell-dingetjes per applicatie blokkeren:
https://cdn-images.xda-de...3/2014-01-24_19.26.00.png
Als ik een pop-upje krijg dat een of andere applicatie waarvan ik de bron niet per se vertrouw een library wil uitvoeren, druk ik op nee.

[Verwijderd]

In de toekomst draaien we apps gewoon in een Linux lightweight container. Bv. met docker of systemd's ondersteuning ervoor. En dan geven we die containers rechten en toegang op basis van noodzaak. Schrijft een applicatie malware in zo'n container, dan bij het afsluiten van de applicatie rollen we het filesysteem terug naar de oorspronkelijke versie.

[Goldwing1973]

En dit is nou precies het voorbeeld waarom ik Android links laat liggen.
Een virusscanner en malewarescaner voor je telefoon?? Belachelijk dat dat nodig is.

[InsanelyHack]

Waarom scant google de PlayStore zelf al niet om verdachte programma's op te sporen en moet jij dat op je telefoon draaien ? Ervan uitgaand dat je je apps alleen uit de App Store haalt lijkt me een proactieve scan in de Google playstore cloud minder "belastend" dan dit op ieder android device te moeten doen. Worden Apps eigenlijk wel gecontroleerd door Google alvorens ze in de PlayStore komen zoals Apple dat doet in de AppStore ? Niet dat dit geheel waterdicht zal zijn maar er ligt toch ook een verantwoordelijkheid bij de platform verantwoordelijke die een centrale App winkel aanbiedt ?

[MGutker]

Worden Apps eigenlijk wel gecontroleerd door Google alvorens ze in de PlayStore komen zoals Apple dat doet in de AppStore ?

Als je het artikel daadwerkelijk gelezen had dan zou je dat geweten hebben

"In tegenstelling tot Apple controleert Google apps in de Play Store niet met de hand, maar apps worden wel door een malware-scanner gehaald."

[Reactie gewijzigd door MGutker op 25 juli 2024 20:56]

[InsanelyHack]

inderdaad overheen gelezen maar in mijn optiek is het pertinent fout om code extern te kunnen laden en dan ook nog eens te kunnen starten . Daar zit fundamenteel een probleem. Want in principe veranderd de code van de originele App en dus klopt het signatuur niet meer.

[Verwijderd]

Als de 'code' gewoon in een ander bestandje of dergelijke wordt opgeslagen veranderd er natuurlijk helemaal niets aan de signatuur. En zo zijn er nog 100 mogelijkheden om dat tegen te gaan.

Ook kun je extern inladen van data niet direct als fout zien. Miljoenen apps laden data in vanuit een externe bron. De fout is hier dat er code kon worden uitgevoerd die dingen deed die niet zouden moeten kunnen, niet het inladen van externe data.

[InsanelyHack]

als google zijn keurmerk geeft aan de code kan de code geencrypt worden door google waardoor de combinatie code met signature niet meer klopt als de code uit twee delen bestaat. Dat andere deel is niet gevalideerd en niet geencrypt door google en zonder signatuur zal het dus niet gestart kunnen worden. Je geeft de indruk dat er legio mogelijkheden zijn dat is dus de valkuil je moet de hoeveelheid mogelijkheden beperken om de code te starten. Dit lijkt me toch echt niet zo moeilijk. (sandbox, encryptie en signaturen) alleen is dit een trager process maar dat is dan ook de tradeoff die je moet maken.

[Verwijderd]

Je snapt wel dat wanneer er externe data wordt binnen gehaald dat dit de code zelf niet veranderd? Dus de signatuur waar jij over praat veranderd helemaal niet.

[InsanelyHack]

1) De code is in eerste instantie schoon maar haalt extern extra code op.
2) Dit kan dan op twee manieren gestart worden. a) Door de code te attachen aan de originele code of b) door de code te starten als een separaat programma.
3) in geval a) is de orignele encrypted code icm de unencrypted malafide code samen niet gesigneerd dus valt door de mand.
4) in geval b) door de apps te signeren valt de code als separaat programma door de mand het is immers niet gesigneerd en als extra beveiliging staat de sandbox policy dit al niet toe behalve vaste onderliggende OS zaken zijn aanspreekbaar maar niet uitwisselingen tussen twee Apps.

[MGutker]

Android zit zowiezo niet zo sterk in elkaar. Exploits everywhere.

[Michaelr1]

Het is inderdaad vreemd, maar het moge duidelijk zijn dat Android op dat gebied zo lek als een mandje is. Het hele permissie systeem is ook hartstikke onduidelijk (leuk dat een app toegang wil tot mijn camera, maar waarom dan? En wanneer dan?) en je weet eigenlijk niet goed waarvoor je toestemming geeft, met als resultaat dat iedereen maar gewoon toestemming geeft. Dat heeft grote gevolgen.

Apps worden dus ook niet goed nagekeken, het OS ligt open en bloot op tafel en iedereen kan alle vulnerabilitys misbruiken zonder dat daar wat van wordt gemerkt.

[TIGER79]

hoezo Android dan ?
En al helemaal dit in de berichgeving :

In tegenstelling tot Apple controleert Google apps in de Play Store niet met de hand, maar apps worden wel door een malware-scanner gehaald.

Wat wordt daarmee bedoelt ? Dat het veiliger is in de AppStore omdat daar een app met de hand getest wordt ?
Dat het met de had getest wordt is inderdaad zo, dat dit veiliger is is lariekoek !
Ik heb het zelf meermaals meegemaakt dat je gewoon de AppStore procedure te slim kunt afzijn door bepaalde funtionaliteit tijdens het testen niet te tonen en deze na de testprocedure gewoon kunt activeren... Dat kun je op afstand doen maar ook simpelweg door de datum van je toestel te gebruiken. Ik dien nu de app in, over 2 weken staat ie in de appstore en dan komt de extra funtionaliteit tot leven...
Voor zover ik weet doet Apple helemaal niet aan code-onderzoek dus dit kunnen ze niet afdekken, het enige wat ze krijgen zijn de binaries en dus niet de source code... Wat ze wel kunnen zien zijn hooks in die binaries waardoor ze weten of er bepaalde API's aangeroepen worden of niet, oftewel precies wat Google ook doet....
Ik snap de nieuws-item echt wel maar ik vraag me af of de schrijver hiervan uberhaupt kennis heeft (of anders heeft uitgezocht) over het onderwerp en al helemaal in het geval er een vergelijking gemaakt wordt deze dan ook echt klopt ?!

[gabba25]

Een beetje hetzelfde als "klik hier om de EULA te accepteren".

[breezie]

Ik neem aan dat het downloaden van de code wel samengaat met een of andere vulnerability die ze misbruiken om meer permissies te verkrijgen.

Zonder vulnerability kun je volgens mij niet opeens meer permissies verkrijgen, zelfs al wordt de code nadien gedownload. Je blijft afhankelijk van de permissies die oorspronkelijk aan de sandbox van je android app werden toegewezen.

[binair]

of de app had al default alle permissies? Het is niet zo dat de doorsnee gebruiker zich hier iets van aantrekt...

[breezie]

Is inderdaad ook perfect mogelijk...

[Iblies]

of de app had al default alle permissies? Het is niet zo dat de doorsnee gebruiker zich hier iets van aantrekt...

Daar doe je te veel mensen mee te kort.

Veel mensen hebben het besef niet dat wat de gevolgen zijn. Privacy is een issue dat altijd speelt en bij 'onderzoek' geven ze altijd een wenselijk antwoord, maar weinig die er echt inhoud aan geven.

Een bekend voorbeeld is whatsapp en dat die graag al je nummers wilt hebben. Dan slaat de twijfel toe, en als je door blijft vragen of diegene die je zijn nummer heeft gegeven het ook apprecieert, dan houd het al gauw op.

[--Andre--]

Zoals ik het begrijp word deze exploit dus gedownload. Dus executable wordt gedownload en gestart binnen originele sandbox. Deze bevat exploit en ontsnapt aan de sandbox.

[Verwijderd]

Tja, de malafide code is nog niet aanwezig, en downloaden is iets dat heel veel gebeurt in apps. Je kunt moeilijk de automatische scanner ook nog eens alles laten scannen wat gedownload kan worden, en dan nog kan die zut encrypted zijn.

Ik snap wel dat dit haast onmogelijk is om te automatiseren, en snap dus ook wel dat de QA van Apple een hogere waarde heeft omdat het mensenwerk is.

[migchiell]

Waarom is die handmatige controle dan beter dan de geautomatiseerde?

Als je niet automatisch alles wat je downloadt kunt scannen, zou dat dan handmatig wel lukken?

[totaalgeenhard]

Waarom denk je dat overheden nooit iets negatiefs over smartphone hebben geroepen?

Met een smartphone haal jezelf een paard van Troje binnen.

Niemand weet wat zijn telefoon aan het doen is terwijl hij aan het slapen is, of op zijn werk op het buro heeft liggen.

Ding kan filmen, luisteren, netwerk in kaart brengen en je wachtwoorden en informatie over jezelf doorgeven ideaal monitoring tool.

De vraag is niet zozeer dat er Apps zijn die dingen doen die je niet voorziet maar in hoeverre Google, Apple en Microsoft uit patriotisme al reeds hun besturingsystemen van achterdeur hebben voorzien.

[Artimunor]

Wat ik niet snap is dat extra code wel binnengehaald en uitgevoerd kan worden zonder dat deze code ook gescanned wordt door google (dat ze dit toestaan dus)
En dan blijkbaar ook nog eens (dezelfde als de app?) rechten heeft

[Verwijderd]

Dat zou betekenen dat je Android phone al je verkeer moet onderscheppen en analyzeren, wat dan weer nefast is voor de privacy.

En dan heb je nog geen garanties, want die malicious code kan geëncrypteerd zijn, en zo perfect door een filter passeren.

[Artimunor]

Niet al het verkeer, alleen code die gedownload wordt en met rechten uitgevoerd wordt...
Alleen de code uit de store zou uitgevoerd moeten worden extra gedownload spul zou helemaal niet op een plek terecht moeten kunnen komen waar het met rechten uitgevoerd kan worden, tenzij je die expliciet verstrekt.

[Verwijderd]

En hoe gaat zo'n scanner weten wat uitvoerbare code is? Code kan vanalles zijn: java bytecode, python bytecode, LUA bytecode, noem maar op. Het kan zels custom bytecode zijn voor een zelfgeschreven VM vanwaar de runtime al in de app zit. De gedownloade code kan ook nog eens encrypted zijn, waarvan de key zich in de app bevindt, en gewoon in het geheugen wordt gedecrypt.

De scanner die jij voorstelt moet het volgende kunnen:

- alle internet-verkeer analyzeren (want code kan van overal gedownload worden)
- elke mogelijke bytecode kunnen analyzeren (want code kan in elk formaat bestaan)
- ook nog eens de mogelijkheid hebben om te detecteren dat data encrypted is, en on-the-fly te decrypten.

Hopelijk zie je zelf in, dat zoiets niet onmiddelijk mogelijk is....

[HollowGamer]

Android staat nou niet bekend als een veilig OS.
Deze conclusie kun je nu ook weer trekken uit dit nieuwsbericht.
Waarom heeft een app zoveel mogelijkheden om te doen en laten wat hij wilt? De gebruiker heeft totaal niet de controle; behalve met bepaalde tools, die (nog) niet in gebakken zijn in het OS.
Ook de omschrijving van permissies die 'nodig' zijn, is gewoon erg onduidelijk.

Er lijkt mij hier een mooie toekomst weggelegd voor HTML-apps. Deze hoeven niet te worden geïnstalleerd, hebben van uit nature minder rechten en kunnen enkel downloaden, tenzij de gebruiker bijvoorbeeld foto's of andere info upload.

Met Tweakers als voorbeeld hoe je gewoon een goede website maakt voor de telefoon, hoeft men zich niet om een app druk te maken.

Moet wel eerlijk zeggen dat ik wat geachrokken ben van dit bericht. Moet ik mij bijvoorbeeld nu druk maken om apps/games die zonder mijn toestemming op de achtergrond bezig zijn met..?

Verder moet er een wet komen die het strafbaar maakt om 'lekken' bewust achter te houden en te misbruiken. Al denk ik niet dat de politiek zich bewust is van de gevaren allemaal.

[Verwijderd]

Is niet alleen Android, alle systeem zijn per definitie niet veilig. Zoals je wellicht in de afgelopen week hebt gelezen, zou het in de nabije toekomst ook mogelijk zijn om de software van Hacking Team op iOS te installeren; zonder dat deze gejailbreakt hoeft te zijn.

Disclaimer : ik haal nu even iOS aan om bij mobiele besturingsystemen te blijven.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 20:56]

[tweaknico]

Black Phone ed. zijn interessanter..

[Verwijderd]

Weet je het zeker?

Hacker kraakt op privacy gerichte smartphone Blackphone binnen vijf minuten
Apps op Blackphone blijken kwetsbaar voor man in the middle-aanval

[Reactie gewijzigd door Verwijderd op 25 juli 2024 20:56]

[tweaknico]

Vooral doorgaan, langzamer hand kan het beter worden.
Het model van Android zal niet snel veranderen, en het lijkt er niet op dat gebruikers de controle over hun toestel gaan krijgen.

Beter nog, een goede secure distro voor een telefoon, waarbij android apps in een sandbox kunnen draaien als ze zich gedragen. (Eentje waarbij bv. Xprivacy bv. standaard onderdeel van uitmaakt.

Zoland de telefoon modems nog binaire CS blobs bevatten blijven alle telefoons verdacht.

[SidewalkSuper]

Het zou in de toekomst ook mogelijk moeten zijn zonder een jailbreak.

Zo kunnen we alles wel verkopen als zijnde "het is per definitie niet veilig".
Die aanvalsmethode verwacht trouwens dat het slachtoffer een app installeert die buiten de App Store om op het iOS-apparaat geplaatst dient te worden. Dit vereist dus een inbraak en dan een hack van de passcode om op het apparaat in te breken of een domme gebruiker die het zelf moet installeren en een aantal keer door het apparaat erop gewezen wordt dat dit niet de normale manier van apps installeren is. Het is best een stretch om dit dan maar onveilig te noemen.

Daarnaast, zolang het nu niet gebeurt, is het gewoon veilig. Zo denken de beveiligingsonderzoekers gelukkig ook die de hacks uitpluizen.

It’s comforting to know that Hacking Team couldn’t do squat with non-jailbroken iPhones beyond social engineering.

https://twitter.com/JZdziarski/status/618686369108488192

Hacking Team's iOS malware was quite pitiful. I've written more covert non-JB software to monitor my kids' iPods. Amateurs.

https://twitter.com/JZdziarski/status/620620850514018304

[Reactie gewijzigd door SidewalkSuper op 25 juli 2024 20:56]

[Katseviool]

Maar wie installeert er überhaupt een dergelijke vage nieuws app? Ik merkte dat ik bij de eerste generaties veel apps op advies van vrienden probeerde, bij verveling door de app stores liep te struinen en nav reviews sites app installeerde. Tegenwoordig maak ik echter enkel nog gebruik van de usual suspects als FB, NOS, NU, LinkedIN etc.

[FreshMaker]

Als ik een app zoek, zonder de exacte naam te kennen, zoek ik op steekwoorden.
zodra die dan hoog eindigt bekijk ik de star-ratings ( en aantal installs )
Onder de 100.000 installs vertrouw ik het niet, of ik moet de developer kennen ( a.i andere apps )

Maar inderdaad, de laatste jaren weet je ongeveer wat je zoekt, en waar je het vandaan trekt ( als ervaren gebruiker ) en filter je bullshit er aardig tussenuit.
Maar de zooi die ik bij collega's zie, zet ik toch wel vraagtekens bij ... en dan ook nog mobiel bankieren ernaast ... nee dank je ...

[Eelco.L.]

en afgezien het feit dat dit een hulpmiddel is voor een totalitair regime..
wat is nou echt het voordeel van een backdoor in google play store?
volgens mij vang je daar geen terroristen mee....

[Verwijderd]

Ik denk dat deze app werd gebruikt als proof of concept. Zo kan Hacking Team laten zien wat ze zoal kunnen maken voor een klant. Je kan het op papier zetten, maar een malafide app actief hebben in de Play Store zegt toch net even wat meer. Ik weet ook niet of dit bedrijf nu alleen maar aan overheden zijn producten heeft verkocht of dat er ook andere organisaties tussen zitten.

[eheijnen]

Klopt helemaal.
Dat heeft idd. niets met gericht werken te maken als je een app aan de massa aanbiedt.

Dan gaat hun scope verder dan ze pretenderen en praatten we over mass-surveilance.

[gijsbertb]

Het is in principe een heel normaal struukje wat veel gebruikt word bij gameing-apps. Telkens wanneer er een nieuw level word uitgeleverd een totale update van de App te geven (lees: review-time) is teveel van het goede. Daarom achteraf wat extra code inladen die zo het nieuwe level regelt.

Dit is wel een voordeel van IOS waarbij de App in zijn eigen sandbox is geplaatst en de reviewronde ook behoorlijk veel stricter is. Als developer ben ik blij met Google omdat het vlot en zonder morren gaat. Maar als consument ben ik blij met Apple dat ze me zo goed beschermen (alhoewel dit niet altijd lukt, ze doen wel erg hun best).

De code die vervolgens word gedownload gaat rechtstreeks vanaf de server naar je mobieltje toe, waardoor Google geen inzage heeft in wat er daadwerkelijk ingeladen word en wat het doet. Het hoort vervolgens ook bij de "open" structuur van Android dat dit mogelijkheden geeft die je liever niet wilt. Het is vrijwel onmogelijk voor Google om dit gat 100% te dichten.

[FreshMaker]

Daarom begrijp ik niet waarom de sinds 5.0 geïntroduceerde scanner dit niet kan ondervangen.
Bij installatie van de eerste sideloaded apk krijg je de vraag of android moet controleren op 'kwalijke software'
Ik mag aannemen dat dit ook gebeurt met Playstore apps.

* FreshMaker gebruikt Xprivacy, met de userbase filters aangezet, al moet je daarvoor weer wel rooted zijn.

Ik hoop iig dat dit soort praktijken daar enigzins door tegengehouden kunnen worden.

[Reactie gewijzigd door FreshMaker op 25 juli 2024 20:56]

[Ex-KPN-er]

Ik mag aannemen dat dit ook gebeurt met Playstore apps.

Zoals een wijs man al eens zei:

Assumption is the mother of all f_ckups!

[FreshMaker]

Yup, vandaar Xprivacy met communityupdate's

[sebasmac]

Ze zullen niet de enige zijn die dit truukje toepassen...

[mutley69]

Als men iets wil bij-installeren dan zal men het bij-installeren - ongeacht het platform - leren mee leven, en dus gewoon zeer kieskeurig zijn op de apps die je test. Misschien gewoon een low-end smartphone gebruiken voor evaluatie-doeleinden met een eigen account? En enkel wat deugt op de goeie smartphone (deze tip geldt eveneens voor hyper-gesloten platformen uit C. en R.).

[thomas_24_7]

Gelukkig bleek uit de documenten op Wikileaks dat ze moeite hadden met Android 5. Er kwamen bijvoorbeeld regelmatig references voor naar de Chainfire root methodes en SuperSU die ze kennelijk gebruikten/misbruikten t.b.v. het (her-) infecteren van Android devices. Ik ben benieuwd wat voor informatie mensen met meer kennis hier nog over kunnen ontdekken.

iPhone telefoons die gejailbreaked waren konden makkelijk worden misbruikt, zonder jailbreak (nog) niet, maar daar werd kennelijk hard aan gewerkt.

Ik vraag mij nu hard af of ik mijn telefoon (Android) nog wel wil rooten, of dat je zoveel onveiliger bent/meer risico loopt, dat de voordelen hier niet tegen opwegen.

Ook waren er Blackphones besteld, kennelijk om te kijken of ze die ook konden kraken. In een vergelijking van privacy phones prezen ze de academische benadering van Silent Circle (maker van Blackphone).

[gumkop]

Wie de hack ook deed, mag toch echt hopen dat ze bij nog wat bedrijven dit gaan doen, wat een beerput is er weer open getrokken zeg. Ik vraag me echter wel af, die bedrijven als Hacking Team, de NSA ed. hebben uiteraard als core business om zwakheden te vinden, maar kunnen ze bij Adobe en consortium nou echt geen middelen vrijmaken om hetzelfde te doen?