ESET: Russische hackers combineerden Firefox- en Windows-zerodays voor backdoors

De aan Rusland gelieerde hackersgroep RomCom misbruikte twee zerodays in Firefox en Windows, meldt ESET. De twee kwetsbaarheden werden misbruikt om zeroclickbackdoors te installeren. Beide kwetsbaarheden zijn inmiddels gepatcht.

De Firefox-kwetsbaarheid, die ook in Thunderbird en de Tor-browser zat, liet criminelen code uitvoeren in de browser, schrijft ESET. Die kwetsbaarheid werd gecombineerd met een andere zeroday. Deze 'privilege elevation'-kwetsbaarheid zat in de Windows Task Scheduler. Beide kwetsbaarheden zijn inmiddels gepatcht. De Firefox-kwetsbaarheid, CVE-2024-9680, is op 9 oktober gepatcht. Voor de Windows-kwetsbaarheid, CVE-2024-49039, is op 12 november een update uitgebracht.

RomCom misbruikte beide kwetsbaarheden middels een eigen webpagina. Bij gebruikers die deze pagina openden werd RomComs backdoor geïnstalleerd. Hiervoor hoefden slachtoffers verder niks te doen: alleen het openen van de webpagina was al genoeg. RomCom doet aan targeted cyberspionage en opportunistische cybercrime, zegt ESET, en target daarbij bedrijven en overheden in onder meer de Verenigde Staten, Duitsland en Oekraïne.

ESET heeft de gebruikte webpagina gevolgd: deze is vooral geopend door gebruikers in Europa en Noord-Amerika. Het beveiligingsbedrijf meldt niet hoeveel slachtoffers er in totaal zijn, maar zegt dat het oploopt tot 250 slachtoffers per land. Hierbij gaat het overigens om mensen die de pagina hebben geopend. Gebruikers die een browser hadden die niet vatbaar was voor de kwetsbaarheid, kregen de backdoor dus niet.

Reacties (41)

[Llopigat]

Welke versie moet je dan hebben om veilig te zijn?

Edit: Ah gevonden:
- Firefox vanaf 131.0.2
- Firefox ESR vanaf 128.3.1
- Oudere Firefox ESR vanaf 115.16.1

[Reactie gewijzigd door Llopigat op 27 november 2024 21:23]

[jurroen]

Vollediger, deze versies bevatten de fixes:

• Firefox 131.0.2
• Firefox ESR 115.16.1
• Firefox ESR 128.3.1
• Tor Browser 13.5.7
• Tails 6.8.1
• Thunderbird 115.16
• Thunderbird 128.3.1
• Thunderbird 131.0.1

Zoals het nieuwsartikel correct aangeeft, een combinatie van een kwetsbaarheid in Firefox/Thunderbird/TBB én een kwetsbaarheid in Windows werden misbruikt.

Windows gebruikers van deze software moeten in het bijzonder snel patchen (en eigenlijk al gepatcht zijn, gezien de fixes medio oktober gepubliceerd zijn).

Maar ook gebruikers van andere systemen doen er goed aan om FF/TB/TBB te patchen. Hoewel het geen zero click remote exploit is dan, is het alsnog een behoorlijk lelijke kwetsbaarheid.

[Cerberus_tm]

Reden te meer om een onvertrouwde webpagina geen echte code te laten uitvoeren op je computer (Javascript). In mijn browser mogen alleen websites op een witte lijst dat.

[Ikmezelf]

Ik heb nu al een tijdje uBlock Origin alle JS laten blokkeren, en heb dan telkens wanneer een website die ik echt nodig had niet werkte, handmatig de JS aangezet en met het slot-icoontje het permanent gemaakt (anders moet ik hem elke keer aanzetten voor die website nadat ik firefox herstart).

Nu kun je een keybord-shortcut instellen in de addons pagina om de JS aan/uit te zetten, alleen is die niet permanent, waardoor ik alsnog met mijn muis de extentie en vervolgens het slot-icoontje moet aanklikken. Dit hinderde teveel, dus nu staat JS weer gewoon aan bij elke website.

Mocht er een manier zijn om sneller een site op de witte lijst te zetten, dan hoor ik het graag.

[Munchie]

Zelf gebruik ik Noscript, hierbij kan je met twee klikken per domein dat geladen wordt Javascript inschakelen wanneer wenselijk, of enkel tijdelijk inschakelen. Dat zijn dus twee klikken in plaats van drie. Voor zover ik begrijp werkt deze Firefox exploit via een CSS functie genaamd animation-timeline. Ik weet niet of uBlock deze CSS functie blokkeert wanneer je Javascript blokkeert. Vorige maand was er ook al een Firefox kwetsbaarheid die via CSS werkte: https://www.security.nl/p...+kwetsbaarheid+in+Firefox < Dat was dezelfde kwetsbaarheid.

Noscript blokkeert in ieder geval wel standaard CSS, maar bijvoorbeeld ook WebGL en fonts. In de praktijk zou dit dus betekenen dat je op een of andere manier op de kwaadwillende site terecht bent gekomen en die niet alsnog de whitelist omdat de site niet werkt en je denkt dat die veilig is.

[Reactie gewijzigd door Munchie op 27 november 2024 18:39]

[closefuture]

Noscript blokkeert in ieder geval wel standaard CSS

Ik zie nergens dat NoScript standaard CSS blokeert danwel de CSS animation-timeline property?

[Cerberus_tm]

Naar wat ik hier zie staat die functie van CSS standaard niet aan in Firefox, dus zou ik daar niet door geraakt kunnen worden: https://old.reddit.com/r/...ents/1g4gcm4/cve20249680/

Verder zag ik ergens anders dan iemand meende dat in Firefox deze kwetsbaarheid niet alleen met CSS aan te vallen was, maar dat er nog iets anders bij nodig was.

The developer who fixed the bug has said it utilised more than CSS but won't provide more details until the bug is public. — https://old.reddit.com/r/...table_in_default/lsjvc13/

Maar goed, je weet het nooit 100% zeker, niets is absoluut veilig. Dat gezegd hebbende gaat het om het verbeteren van je kansen. En Javascript alleen toestaan op sites die je vertrouwt helpt m.i. een heleboel, dan heb je de meeste kwetsbaarheden in je browser ondervangen. Blijft over vertrouwde sites die gehackt worden en kwetsbaarheden buiten Javascript.

[Reactie gewijzigd door Cerberus_tm op 28 november 2024 05:13]

[Cerberus_tm]

Het is inderdaad veel handwerk. Ik doe het vaak zelfs per individueel Javascript-bestand per site...

Je zou zoiets als Autohotkey kunnen gebruiken om het met een hotkey permanent te doen per site.

[Alfa1970]

Het is een goede aanpak, maar op zichzelf staand is dat echter niet afdoende.

Het probleem is dat vertrouwde, gerenommeerde sites gecompromitteerd kunnen worden.
Of "diensten" die zij bieden zijn gecompromitteerd. De Telegraaf is een voorbeelden van een site die over het algemeen vertrouwd wordt, maar ook gecompromitteerd werd.

Naast selectief javascript toestaan, zijn er ook diverse scan technieken noodzakelijk om relatief vrij van problemen te blijven.

Je blijft echter zitten met het feit dat hier over zero-day wordt gesproken. En er is geen scanner die je daar tegen kan beschermen. Iemand zal dus altijd een keer de pisang moeten zijn voordat er een oplossing voor komt.

[Cerberus_tm]

Dat kan inderdaad ook. Uiteindelijk ben je nooit 100% veilig.

Op Telegraaf.nl ziet mijn Ublock er zo uit:

https://i.imgur.com/ud3LbAX.jpeg

En mijn Umatrix:

https://i.imgur.com/ykX6kes.jpeg

Resultaat: Umatrix blokkeert alles van 3rd parties behalve wat ik daar handmatig per site toesta. Van 1st party laat hij alles door. Maar dan komt alles van 1st party by Ublock, en in Ublock wordt alle Javascript standaard geblokkeerd. Daar geef ik in principle alleen per JS-bestand toestemming. En alleen als de site anders niet werkt.

Dus op de site van Telegraaf draai ik sowieso geen Javascript. En als ik dat wel doe, alleen specifieke Javascript-bestanden die echt nodig zijn om de tekst te laten tonen.

Op een site die ik echt vertrouw / waar ik echt veel Javascript toesta is de kans dan het grootste dat ik gehackt word. Maar 100% veiligheid bestaat niet, het is een kwestie van risico's beperken.

In het artikel gaat het over een onbekende site. Die zou mij dus niet kunnen pakken met Javascript.

[Merik]

Dit heb ik ook even geprobeerd, en vanuit beveiligingsoogpunt is er genoeg te zeggen voor deze oplossing, maar het telkens opnieuw instellen voor elke website kost zoveel moeite...

[Alfa1970]

Dat is precies het probleem met beveiliging, wat is praktisch versus wat is veiliger.
De beste beveiliging is helemaal geen internet verbinding.
Maar dat is niet praktisch, dus sluit je een compromis.
Op zichzelf is client-side javascript volledig onnodig maar vanuit praktisch oogpunt wordt het heel veel toegepast.

[MiTr]

Waarom denk je dat cliënt-side Javascript niet nodig is?

Om 1 voorbeeld te noemen waarom het wel nodig is: voor het asynchroon laten werken van onderdelen van websites.

[Alfa1970]

Waarom worden websites opgeknipt in stukjes om door een stukje javascript te worden ingeladen dan?
Een web browser kan van zichzelf al meerdere bestanden tegelijkertijd downloaden zonder enige vorm van javascript. M.a.w. een browser werkt al asynchroon van zichzelf, zonder dat het client side scripting nodig heeft.
Daar komt bij dat de meeste "ontwikkelaars" de voorbeelden van stack overflow volgen, en daarmee de plank volledig mis slaan door overal "await" in de code te zetten. En je browser gaat dan netjes staan wachten totdat de gegevens binnen zijn, hetgeen alle voordeel van de async functie teniet doet.

[MiTr]

Ik had het ook niet zozeer over het asynchroon inladen van bestanden.
Eerder over asynchrone API calls naar de backend, websockets en state management.

Dat heb je misschien niet snel nodig bij een website, maar bij een webapplicatie al snel wel.

[Alfa1970]

State management zou server side moeten gebeuren, dat heb je client side niet nodig.
De "API" call om nieuwe data op te halen kan prima met form actie worden uitgevoerd zonder javascript of async.
De meeste code die je ziet voor een dergelijke zogenaamde async call is:
onclick="await api_call_function(data)".
Hetgeen net zo goed uitgevoerd kan worden met een submit button op een form.
Omdat await een blocking call is en niets asynchroons doet.

[MiTr]

Ik denk dat we van mening verschillen dat state management alleen server side moet gebeuren. Voor een snelle workflow in een data-gedreven applicatie is het wel fijn als je data in geheugen hebt wat op de achtergrond ververst wordt als je het weer raadpleegt.

Maar wat betreft het gebruik/misbruik van await ben ik het met je eens. Dat kan beter.

[Alfa1970]

Data die "in het geheugen staat", ook dat kan zonder javascript,
Het komt beschikbaar als je het nodig hebt, met een klik van je muis, en gaat weer weg als je het niet meer nodig hebt.
Werkt prima geen async, geen javascript, gewoon nadenken wat je nodig hebt en gebruiken wat je ter beschikking hebt. Oneindig veel sneller dan een async call met een sub par script taal.

<!DOCTYPE html>
<html>
<head>
<style>
.toggle-checkbox {
display: none;
}
.toggle-button {
display: inline-block;
padding: 10px 20px;
background-color: #f0f0f0;
cursor: pointer;
}
.hidden-content {
display: none;
}
.toggle-checkbox:checked ~ .hidden-content {
display: block;
}
</style>
</head>
<body>
<input type="checkbox" id="toggle" class="toggle-checkbox">
<label for="toggle" class="toggle-button">Toggle</label>
<div class="hidden-content">
de verborgen data
</div>
</body>
</html>

[Reactie gewijzigd door Alfa1970 op 29 november 2024 06:09]

[MiTr]

Als je een fullstack/frontend developer bent weet je dat dit geen werkbare oplossing is.

[Alfa1970]

Ik weet niet wat je van Amazon.com vindt, in mijn opinie is dat een redelijk grote site, met heel veel data.
Die site werkt ook als javascript volledig uit staat.
Dat het uit staat wil overigens niet zeggen dat de javascript niet wordt ingeladen, het kan alleen niet uitgevoerd worden door de browser.
Er zijn meer voorbeelden te vinden van (redelijk complexe) sites die volledig functioneel doordraaien als Javascript uit staat.

[Marsmillo]

Het is niet de ideale oplossing, maar ik draai mijn browsers op mijn desktop meestal in sandboxie. Het is vermoedelijk wel iets onveiliger dan in een volledige echte VM, maar werkt wel iets vlotter in dagelijks gebruik. Mijn ‘browser’ sandboxie heeft een auto wis functie, waardoor in principe na het afsluiten van de browser alles wat ik niet zelf heb bewaard wordt gewist.

Grote risico blijft wel mijn mobiele apparaten, daar heb ik nog geen VM oplossing voor gevonden die vlot werkt.

[Wouterie]

Waarom dan geen Tor? Je kunt ook 'Sandboxed Tor' gaan, maar eerlijk gezegd vind ik dat een beetje overkill. https://www.browserling.com/tor

[nullbyte]

Omdat dat zo traag is als dikke stront door een trechter en enkel nuttig is voor diegenen die meer anoniem willen zijn. Niet voor de gemiddelde tweaker comment.

[Reactie gewijzigd door nullbyte op 27 november 2024 21:45]

[Boekenkaft]

Het zou handig zijn als er bij dit artikel ook een link gegeven werd naar een methode om te zien of je besmet bent.

[Hippe Lip]

Het wordt steeds lastiger om je onbevangen op het internet te begeven. De laatste tijd lijken de artikelen over Russische en Chinese hackers steeds vaker te verschijnen. Je gaat je afvragen wanneer het écht gevaarlijk wordt om ‘zomaar’ rond te hangen op het internet…🤷‍♂️

[Wouterie]

Dit in tegenstelling tot 10 of 20 jaar geleden?

[Hippe Lip]

Alles is relatief, maar de invloed die hackers (kunnen) hebben op het functioneren van ons dagelijks leven is nu zeker véééle malen groter dan 10 of 20 jaar geleden!

[Wouterie]

Ik denk dat we het niet zo door hadden. PRISM ging in 2007 van start en rond die tijd waren er zware aanvallen vanuit Rusland op Europa, met name Estland. Zeker tijdens de Russisch-Georgische oorlog (2008) werden Rusland, Georgië en Azerbeidzjan over en weer behoorlijk op de korrel genomen. En dat heeft grote gevolgen gehad voor latere conflicten.
Of dichterbij toen Karim Baratov voor de Russen 'the Yahoo hack' (2014?) pleegde. Hij wist niet eens dat hij voor de Russen werkte...
Pas vanaf eind 2020 heeft het hier echt de publieke aandacht. Meer geld, meer aandacht, meer voorlichting. Ik denk dat je gelijk hebt dat de invloed op het dagelijks leven groter is omdat er veel meer aandacht voor is. Je kunt niet bang zijn voor wat je niet weet.

[nullbyte]

Nope, het is nu vele malen erger dan 10 jaar geleden

[Moraanl]

Ja en wie weet waar de Amerikanse hackers uithangen. Die die zitten vast ook niet stil.

[Honytawk]

Dat zou heus kunnen, maar daar gaat het artikel niet over.

[_Pussycat_]

Echt, dat staat daar in? Waar precies dan?

[Wouterie]

https://tweakers.net/nieu...-iran-en-noord-korea.html De USA hackers worden niet eens genoemd in het rapport.

[caipirinha]

Gebruikers die een browser hadden die niet vatbaar was voor de kwetsbaarheid, kregen de backdoor dus niet.

Gebruikers die de browser wel gebruikten maar geen windows gebruikten ook niet
Benieuwd wanneer de specifieke combinatie TOR broswer en Linux getarget gaat worden.

[Wouterie]

Soms, heel soms, bekruipt mij het gevoel dat dit soort artikeltjes niet bedoeld zijn voor mensen met ook maar een greintje technische kennis. Zitten we hier nu op nu.nl of op tweakers? Soms weet ik het even niet meer.

[ATS]

Is tegenwoordig van hetzelfde concern. Trek daar zelf maar een conclusie uit...

[Anoniem: 201953]

Sites zoals tweakers zijn tegenwoordig bedoeld voor een breed publiek. De echte tweakers zijn een (kleine?) minderheid geworden. Je hoeft niet aan een moederbord hebben gesoldeerd, je hoeft niet te weten wat een assembler of compiler is, je hoeft je computer niet eens open hebben geschroefd.😉

[Wouterie]

Ja... het doet weleens pijn dat we in de minderheid zijn. Ik mis de soldeerboutartikeltjes wel hoor!

[Qalo]

Deze 'privilige elevation'-kwetsbaarheid zat in de Windows Task Scheduler.

Dus Firefox onder een ander besturingssysteem dan Windows was hiervoor niet kwetsbaar? Als ik dit lees concludeer ik dat. Of zit ik nu mis?

[:murb:]

Dus Firefox onder een ander besturingssysteem dan Windows was hiervoor niet kwetsbaar? Als ik dit lees concludeer ik dat. Of zit ik nu mis?

• Firefox had de mogelijkheid om arbitraire code uit te voeren. Debian heeft hiervoor ook patches uitgebracht tot Buster Security.
• Windows stond het toe om die code bv als een administrator uit te voeren.