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

Onderzoekers: nieuwe Cerberus-trojan kan 2fa-codes op Android stelen

Beveiligingsonderzoekers van het Nederlandse bedrijf Threatfabric hebben een nieuwe variant van de Cerberus-malware ontdekt die tweestapsverificatiecodes van Google Authenticator kan stelen. De nieuwe malwarevorm lijkt nog niet op grote schaal verspreid te worden.

De nieuwe malware wordt beschreven in een rapportage met de naam 'Year of the RAT'. Dat is zowel een verwijzing naar het Chinese astrologische jaar van de rat, als naar de afkorting van remote access trojan, waar het onderzoek naar keek. De onderzoekers keken naar een aantal bekende trojans voor Android. Behalve om Cerberus ging het bijvoorbeeld ook om Hydra en Anubis, die al langer bekend zijn. Van Cerberus ontdekten de onderzoekers een nieuwe variant. Die kan verschillende soorten informatie stelen van een geïnfecteerd toestel, waaronder inloggegevens zoals de pincode.

De malware doet dat door misbruik te maken van rechten van de toegankelijkheidsopties in Android. De malware toont dan een overlay van een bepaalde app waarop gebruikers hun pin- of schermcode invoeren. Zulke overlays zijn er voor veel verschillende applicaties, waaronder die van de ABN Amro-app. Ook heeft de app de mogelijkheid een screencap te maken van authenticatie-apps mits die actief zijn. Die wordt vervolgens doorgestuurd naar een command-and-control-server. De trojan heeft daarnaast de mogelijkheid om de app TeamViewer te starten als gebruikers die hebben geïnstalleerd. Op die manier hebben de aanvallers nog meer toegang tot een geïnfecteerd toestel. De onderzoekers vermoeden dat het gaat om een nog experimentele functie die nog niet actief door de makers wordt gepromoot.

Door Tijs Hofmans

Redacteur privacy & security

27-02-2020 • 11:03

41 Linkedin

Reacties (41)

Wijzig sortering
Beetje verwarrend, gaat dit nou specifiek om malware die Cerberus heet of de commerciële Cerberus app uit de app store waarmee je je telefoon op afstand kan beheren ( Remote Acces Tool)?
https://www.cerberusapp.com/

als het het laatste is dan zou dat inhouden dus dat die commerciële app dus je 2fa steelt? :o (gebruik die app al een tijd niet meer maar toch..)
Volgens mij gaat het om twee totaal verschillende dingen. Niet alles met de naam Cerberus is hetzelfde.

Overigens kun je in Android per programma kiezen of het overlays mag gebruiken (dus noot toestaan tenzij bij betrouwbare programma's).
Gaat het nou enkel om tokens die door de Google Authenticator app worden beheerd of ook andere apps die OTP/TOTP tokens beheren?
Het is 1 van de mogelijke targets van de cerberus trojan. Ik vind dat het artikel wel daarin wat duidelijker mag worden en daarnaast de oplossing/mitigaties waar de onderzoekers het mogelijk over hebben gehad, vermelden. Verder is het wellicht handig om ook te vermelden hoe de trojan verspreid wordt: Malafide apps? Advertenties? Vage URL's? Hoe detecteer je het/Hoe kom je erachter?
hoe ik hem lees is dat er een screencapture gemaakt wordt tijdens de authenticator app. deze wordt vervolgens met een OCR manier omgezet naar cijfers welke als authenticatie gebruikt wordt. op deze manier kan het dus iedere 2FA app zijn. de trojan moet alleen wel weten dat hij op moment x of y een OCR opname moet draaien. de google authenticator is dan ook by far de bekentste. dus als die op het toestel staat en opgestart wordt, zal de OCR functie zijn werk doen. althans dit is mijn interpretatie.
als elke authenticator app het nemen van screenshots zou verbieden, is het dan niet opgelost?
Volgens mij moeten authenticators ook niet automatisch opgestart of naar voren gehaald kunnen worden anders dan door de gebruiker. Je moet eigenlijk alle automation op dat soort apps verbieden.
volgens mij moeten authenticators ook niet automatisch opgestart
als een authenticator handmatig start kan het proces ook gelezen worden en zal het probleem dan ook niet afvangen.
als elke authenticator app het nemen van screenshots zou verbieden, is het dan niet opgelost?
dat lijkt mij idd een prima oplossing.
Je zorgt ervoor dat de gebruiker de code gebruikt en dan hopelijk de aanbiedende partij zegt dat er tegelijkertijd op twee plekken wordt ingelogd.

Geen screenshots is natuurlijk goed, het is ook, ofwel zoveel mogelijk maatregels. Het handmatige is vooral bedoeld om snelle detectie van misbruik mogelijk te maken.
Andersom: programma's zouden geen schermafbeeldingen mogen maken, tenzij de gebruiker speciale toestemming geeft na gewaarschuwd te zijn. Verder zouden programma's niet bij de map schermafbeeldingen moeten kunnen tenzij met speciale toestemming.
In Enpass is het in elk geval een toggle die standaard uit staat. Maar in populaire Authenticator apps zoals Google Authenticator en Authy zijn die opties er - zover ik weet - niet.
Zover ik het begrijp wordt er geen gebruik gemaakt van screenshots, maar de Toegankelijkheidsopties van Android. Deze kunnen (blijkbaar) ook het scherm uitlezen/interpreteren.

Ik DENK dat het via dit gaat:
https://developer.android...lity/service#process-text
Deze moeten het scherm uitlezen want toegangkelijkheid vergrotende apps zijn bijvoorbeeld voor blinden. Een OCR app moet het scherm kunnen uitlezen voor TTS.
Ik mag toch hopen dat de gebruiker voor accessibility speciale toestemming moet geven per programma? In Android 4.4 (mijn telefoon) is dat in elk geval wel zo.
andOTP staat het iig default niet toe.
Van Authy kan ik ook geen screenshot maken, ik krijg een melding over security policy.
Ofwel, altijd je vingerafdruk/biometrie gebruiken ondanks dat een hoop mensen dit nog als onveilig aanmerken, deze kunnen ze immers niet 'afkijken'.

Net als betalen met de bankpas dat mensen nog steeds denken dat contactloos betalen onveiliger is, terwijl je hier veel minder kans heb om geskimmed te worden aangezien je je pas nergens in hoeft te stoppen (en dus niet gekopieerd kan worden) en je vaak ook geen PIN-code hoeft in te voeren en dus ook niet afgekeken kan worden.
Leuk, maar als een site een eenmalige code vraagt die jij in je app moet genereren gaat je vingerafdruk niet veel helpen.
Maar volledig contactloos betalen is onmogelijk, in ieder geval bij mijn bank, want ik moet 1x per week à 1x per twee weken 1 keer mijn pas in het pinapparaat stoppen uit 'veiligheidsoverwegingen' (zo noemt mijn bank het).
ik gebruik authy als MFA app. Die staat het niet toe om screenshots te maken...
"De malware doet dat door misbruik te maken van rechten van de toegankelijkheidsopties in Android"
Het gaat niet om screenshots maar om de accessibility features.
Ik weet er ook niet helemaal het fijne van, maar vermoed wel dat dit op een andere manier dan via screenshots word misbruikt. De feature werd ook vaak door wachtwoord managers (mis)bruikt om dingen te autotypen. Dus ik denk dat er geen afbeelding word verzonden van de authenticator maar de daadwerkelijke token als string, die uitgelezen word door de accessibility feature (ws kan die feature ook dingen op het scherm uitspreken enzo).

De ABN Amro app laat ook geen screenshots toe, maar toch is er dus iets vergelijkbaars mogelijk binnen die app (volgens tweakers iig). Waan je dus vooral niet veilig met Authy...

[Reactie gewijzigd door jozuf op 27 februari 2020 12:03]

Dat is security through obscurity. Een TOTP applicatie (wat Google Authenticator, Microsoft Authenticator, allemaal zijn) gebruikt een secret hash (base32 of hex) op welke basis icm de tijd een unieke code wordt gegenereerd. Die secret hash staat in geheugen, en staat ergens op de opslag. Dat kan in binaire vorm zijn, plaintext, of wat dan ook. Als malware toegang kan krijgen tot dat stukje data, dan is het prijs. Een goed capability based design staat dat niet toe, maar helaas zijn de capabilities in Android nogal limited. Zo kun je een applicatie toegang geven tot "storage" maar niet specifieke directories. Stel je voor dat SElinux of Unix rechten op die manier zouden werken: of je hebt read access tot alles, of tot niets. Belachelijk toch? Ook tijdelijk rechten geven zit niet native in Android (in 9 of 10 in ieder geval niet); dan heb je een applicatie als Bouncer nodig. Maar uiteindelijk is het probleem natuurlijk deels ook dat malware succesvol is. NOS tech op 3 podcast had het hier laatst over: een remote root vulnerability voor iOS kost slechts 1 miljoen EUR bij zo'n vulnerability boer (of hoer). En dan heb je toegang tot heel veel smartphones. Bijvoorbeeld die van Oeigoeren.
Ik dacht altijd dat de 'Storage' alleen toegang was tot het gedeelde stuk opslag (/sdcard) op je toestel. Elke app heeft ook nog een eigen stukje opslag.
Anders zou het betekenen dat elke app met de optie 'Storage' de inhoud van elke willekeurige app kan bekijken :-) (inclusief z'n cache en instellingen)
Een app toegang geven tot "Storage" geeft ook toegang tot de "Main Storage" waar veel apps hun data zetten die je dan weldegelijk kan uitlezen. Dit is echter al veel langer bekend en heeft niet rechtstreeks iets te maken met dit artikel. Als je wil zien waar eender welke app met storage toegang op heeft doe je maar eens een je bestanden op main storage open. Tip: kijk ook eens onder de folders "android", "backups", "temp", "MyING", etc... , daar staan vaak leuke dingen. :P
@Jerie heeft op zich wel gelijk. Ik weet even niet hoe het momenteel in Android geregeld is (ik focus me doorgaans meer op iOS development) maar een probleem waar ik bijvoorbeeld tegenaan liep was dat gebruikers in een Android-app graag een eigen geluid voor een notificatie wilden instellen. Die staat dan op external storage. Daar moest ik toestemming voor vragen aan het OS, waarna het OS een dialog toont aan de gebruiker dat de app toegang wil tot external storage en toegang krijgt tot foto's. Resultaat was dus dat vrijwel alle gebruikers kwaad werden dat de app toegang vroeg tot de foto's en wilden weten wat de app met hun foto's wilde doen, terwijl de permission alleen nodig was voor het lezen van een geluidsbestand ...

Nou zal het gebruik van external storage niet van toepassing zijn op deze aanval, maar ik ben het eens met de stelling dat toegang tot external storage niet specifiek genoeg kan worden toegekend.

[Reactie gewijzigd door gday op 27 februari 2020 16:49]

Is dit ook van toepassing op Microsoft's Authenticator en overige of is dit enkel voorbehouden aan de Google Authenticator app?
De malware werkt door een screenshot te maken van de app en op die manier de code die wordt weergegeven te onderscheppen. In principe kan dat dus ook met andere authenticator-apps, zolang de ontwikkelaar van de malware maar aangeeft wanneer de malware het screenshot moet maken.
Maar mijn MS Auth werkt niet met een code, maar met 'toegang verlenen' (als je bv inlogt op XBL of onedrive), er komt geen code of cijfers, maar alleen een 'goedkeuren/afkeuren' optie.
Maar je kan de app ook gebruiken met oAuth en dus wel tokens laten genereren ipv de Google app te gebruiken. En spijtig genoeg staat de MS App per default toe dat je screenshot maakt.
Die authenticatie methode wordt gebruikt door Microsoft zelf. Voor andere sites worden wel codes gegenereerd.
Ik vraag me af of dit op alle Android toestellen mogelijk is. Ik neem aan dat de Pixel 3 en ouder de Titan M chip gebruiken voor dit soort gevoelige informatie. Dan kan de malware er niet bij.
Het kan alles wat leesbaar op je scherm komt uitlezen zolang er screenshots gemaakt kunnen/mogen worden.

Dus waar die data vandaan komt maakt juist helemaal niks uit.

Daarnaast betreft het overlays over apps heen om jouw scherminput af te vangen, waar die input vervolgens heen gaat lijkt dus ook helemaal niks uit te maken.

Die chip heeft hier zoals het artikel het omschrijft dus 0 toevoeging.
Ja klopt, had het niet verder in detail gelezen :) Dat moet dan inderdaad op een ander niveau opgelost worden.
Er staat dat het via de toegankelijkheidsopties gaat. Dit staat denk ik los van het maken van een screenshot toch?

Volgens mij gaat het om:
https://developer.android...lity/service#process-text

Blijkbaar is er een toegankelijkheidsoptie die tekst op het scherm kan interpreteren?
Het lijkt dus (deels) opgelost te worden door het blokkeren van screenshots, zoals de ING app dat ook doet?
In de ABN AMRO app staat die standaard ook uit, tenzij je het zelf in de settings aanzet.
Volgens mij snap ik het niet helemaal. Maakt dit nou effectief (ge|mis)bruik van de 'weergeven voor andere apps' en/of 'Scherm in scherm' functionaliteit van Android die standaard aan staat voor apps die het ondersteunen?

Edit:
Volgens mij maakt het in elk geval ook gebruik van https://developer.android...lity/service#process-text

[Reactie gewijzigd door lenwar op 27 februari 2020 14:03]

Nee, het maakt gebruik van accessibility features waarmee apps toegang krijgen om het scherm uit te lezen tbv OCR voor text to speech. Met picture in picture of display over other apps kan niet (gemakkelijk) het scherm uitgelezen worden (ik zeg gemakkelijk omdat ik me meen te herinneren dat er een exploit techniek was om op pixel basis oid via display over other apps informatie te krijgen over de pixels er naast en zo een beeld te genereren).
Daarom gebruik ik mijn vingerafdruk :O
En dan blijven tweakers mij steeds maar zeggen dat 2FA via sms onveilig is omdat het onderschept kan worden, en dat ik daarom maar een app als Google Authenticator moet gebruiken, maar blijkbaar is dat dus ook niet waterdicht...

Op dit item kan niet meer gereageerd worden.


Apple iPhone 11 Microsoft Xbox Series X LG OLED C9 Google Pixel 4 CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True