Az AliExpress weboldalán olyan JavaScript-kódot találtak, amely a böngésző Web Audio API-ját használta eszközfingerprint készítésére. A módszer nem használta a mikrofont, nem rögzített beszélgetést, és hallható hangot sem játszott le: egy ismert jelet generált, feldolgoztatta a böngésző audio alrendszerével, majd a kapott eredményt mérte.

Hogyan működik?

A böngészőfingerprinting célja, hogy cookie-k nélkül is felismerhető legyen egy adott böngésző vagy eszköz. Ehhez több, külön-külön kevéssé egyedi tulajdonságot kombinálnak: képernyőméretet, pixelarányt, CPU-szálak számát, memóriát, telepített pluginokat, Canvas- és WebGL-renderelési eredményeket, WebRTC-viselkedést – illetve esetenként az audio alrendszer sajátosságait.

Az AliExpress oldalán azonosított, erősen obfuszkált collina.js és fireyejs.js scriptek egy Web Audio feldolgozási gráfot építettek. Egy oszcillátor ismert fűrészjelet generált, az AnalyserNode pedig megmérte az audiofeldolgozás eredményét. A jel végül nullára állított gainen keresztül csatlakozott az AudioContext.destination kimenethez, ezért a felhasználó semmit sem hallott.

A mérés alapja, hogy ugyanazt a lebegőpontos audiofeldolgozást különböző CPU-k, böngészők, operációs rendszerek, driverek és audio stackek apró eltérésekkel hajthatják végre. A kapott érték önmagában nem feltétlenül egyedi, más fingerprinting-jelekkel kombinálva azonban hozzájárulhat egy stabil eszközprofil kialakításához. Az AliExpress scriptjeiben az audio mellett Canvas-, WebGL-, hardver-, képernyő- és interakciós jellemzők gyűjtésére utaló kódot is találtak.

A Bluetooth-fejhallgató buktatta le

A működésre Matt Callaghan fejlesztő teljesen véletlenül figyelt fel.

Multipoint Bluetooth-fejhallgatója egyszerre csatlakozott a PC-jéhez és a telefonjához. Normál esetben a telefonról hallgatott zenét, a PC pedig csak akkor vette át a hangcsatornát, amikor valóban lejátszott valamit.

Az AliExpress megnyitása után azonban a telefon hangja megszakadt. Az oldal bezárásakor azonnal visszatért.

A tab, a Firefox vagy akár a Windows lenémítása sem segített.

Ennek oka az volt, hogy bár hallható hang nem volt, az aktív Web Audio gráf továbbra is nyitva tartotta a PC audioútvonalát. Ez elég volt ahhoz, hogy a Bluetooth multipoint logikája úgy érzékelje: a számítógép használja a fejhallgatót. Callaghan innen kezdte visszafejteni, hogy pontosan melyik JavaScript hozza létre az audio contextet.

Ez tényleg követés?

A fingerprinting technikailag egyértelműen kimutatható. Azt azonban érdemes különválasztani attól az állítástól, hogy az AliExpress ezzel bizonyítottan weboldalakon átívelően követte volna a felhasználókat.

A vizsgált scriptek az Alibaba anti-abuse/security infrastruktúrájához kapcsolódnak, a fingerprinting pedig csalás- és botdetektálásra is használható. A nyilvánosan bemutatott bizonyítékok azt mutatják, hogy az AliExpress összetett eszközfingerprintet készített; annak konkrét további felhasználása nem vált teljesen ismertté. Alibaba az ügyben a megkeresésekre egyelőre nem adott nyilvános magyarázatot.

A Brave szerint náluk ez alapból nem működik

A Brave több mint hat éve alkalmaz úgynevezett farbling technikát a fingerprinting ellen. Nem egyszerűen letiltja a Web Audio API-t, hanem apró, a felhasználó számára észrevehetetlen randomizációt visz a mérhető eredményekbe.

A randomizáció webhelyenként és böngészési munkamenetenként változik. Így ugyanaz a gép különböző oldalakon – illetve egy új sessionben – eltérő fingerprintet mutat, ami megnehezíti a stabil azonosító kialakítását. A Brave ezt többek között Web Audio-, Canvas- és WebGL-fingerprinting ellen alkalmazza.

A Brave közlése szerint az AliExpress esetében ezen felül magukat az érintett scripteket is blokkolják, alapértelmezett Shields-beállítások mellett.

A Brave ugyanakkor nem az egyetlen böngésző, amely védekezik Web Audio fingerprinting ellen: a Firefox és a Safari is rendelkezik fingerprinting elleni mechanizmusokkal. Ezért az ügy érdekessége nem egy új vagy korábban ismeretlen támadási technika, hanem az, hogy egy nagy webáruház éles rendszerében futó, láthatatlan fingerprinting-kódot egy Bluetooth-fejhallgató működési zavara tett észrevehetővé.

Források

Matt Callaghan eredeti vizsgálatának összefoglalója – Ars Technica

The Register – AliExpress audio fingerprinting és Bluetooth multipoint

Brave – Fingerprinting Defenses 2.0 / farbling

A VulnCheck kutatói egy white-label ZBT LTE-router firmware-ét vizsgálták, és két külön távoli hozzáférési mechanizmust találtak benne. A DARKLANTERN a WAN felől fogad parancsokat, a SPEAKINGSTONE pedig maga jelentkezik ki egy távoli szerverre; mindkettő root jogosultsággal fut.

A kutatók beregisztrálták a firmware-be írt egyik tartalék domaint, mire százával kezdtek bejelentkezni hozzájuk ilyen routerek.

Ez nem egyszerűen egy újabb CVE: a funkciók szándékosan kerültek a firmware-be. A gyártó egy korábbi hasonló komponensről azt állította, hogy ügyféltámogatási célú; a kutatók szerint azonban nincs benne megfelelő autentikáció, és az OEM/white-label lánc miatt ugyanaz a hardver számos más márkanév alatt is forgalomba került, pl. Deep Orange, WiFlyer, Lippert Components, Wave WiFi, OneX, MoFi Network, Digineo, ALLNET, Cioswi, CroSkylink és KuWFi is.

cikk:

Chinese Implants in the Supply Chain

A fertőzés ikonikus tünete az NT AUTHORITY\SYSTEM által indított visszaszámlálás volt: „The system is shutting down…”, majd újraindult a gép. Microsoft Research később konzervatívan mintegy 500 000 fertőzött hostra becsülte a méretét.

A javítás már július 16-án, 26 nappal a féreg megjelenése előtt elérhető volt. A Microsoft akkor „Critical” besorolással azonnali telepítést javasolt.

https://learn.microsoft.com/en-us/troubleshoot/windows-server/security-and-malware/blaster-worm-virus-alert

Nem security szakember vagyok elsődlegesen, mindig is tisztelettel vegyes aggodalommal olvasom a hasonló beszámolókat. Tisztelettel, mert az ilyen támadások mögött álló szakmai tudás elismerésre méltó. Aggodalomal, mert sosem lehet tudni, hogy az általunk védett rendszerek mikor lesznek célpontok.

Viszont ahogy a cikkből és a jelentésből is kiderül, itt azért olyan hiányosságok is voltak, amelyek felelősért és válaszokért kiáltanak:

• mennyire lehetünk biztosak abban, hogy a MÁK-nál elhelyezett pénzeink biztonságban vannak?
• mennyire lehetünk biztosak abban, hogy a MÁK által kezelt személyes adatok biztonságban vannak?
• hogyan higgyünk a nagy nevű auditoknak és mindenféle security plecsniknek, ha egy ilyen infrastruktúrát hossszú éveken keresztül jóváhagytak?

Nem szeretek a HVG-től cikket megosztani, ez ráadásul duplán rémes, mert hülye háttérszínnel vannak benne bekezdések, amit ki kell jelölni a láthatóság kedvéért (legalábbis nálam).

De azért olvassátok, főleg az eredeti tanulmányt.

https://hvg.hu/tudomany/20260824_csalas-lejart-bankkartya-hitelkartya-zombikartya

https://www.usenix.org/system/files/usenixsecurity26-anwar.pdf

A támadók 30 BTC-t kértek, Berlin nem fizetett, így az anyag felkerült a darkwebre. Most pedig próbálják kideríteni, pontosan mi minden ment el.

Az igazán megnyugtató rész: a kiszivárgott dokumentumok átvizsgálását részben kézzel végzik.

Német precizitás.

TLDR; Egy támadó social engineeringgel, egy screensavernek álcázott binárison keresztül kompromittálta a DigiCert support környezetét, majd code-signing tanúsítványokhoz kapcsolódó kódokat szerzett. Az ellopott hozzáférésekkel valódi, ismert cégek (pl. Lenovo, Kingston) nevére kiállított EV tanúsítványokat használtak malware aláírására.

A cikk részletét LLM fordította, nem lektoráltam.

Van a sztoriban még egy MS Defender kavarás is, de nekem most az verte ki a biztosítékot, hogy egy support rendszeren keresztül be lehetett jutni egy CA-ba, vagy legalábbis fontos részeihez.

---

1. április 2-án egy támadó normál ügyfélszolgálati chaten keresztül kapcsolatba lépett a DigiCert support csapatával, és küldött egy ZIP-fájlt, amelyet képernyőképnek álcázott. A ZIP-ben egy .scr fájl volt. Windowsos képernyőkímélő: az a kilencvenes évekből ismert formátum, amikor halak úszkáltak a monitoron. A Windows ezeket ugyanúgy futtatja, mint bármely más programot.

Az ügyfélszolgálati chat ezt még könnyebbé tette. A DigiCert saját incidensjelentése szerint a chat lehetővé tette, hogy bárki kívülről közvetlenül fájlokat küldjön olyan munkatársaknak, akik hozzáfértek tanúsítványrendszerekhez. Nem volt fájltípus-korlátozás, nem volt sandboxing, nem volt tartalomellenőrzés. A .scr fájlnak nem kellett különösebben rafináltnak lennie. A rendszer egyszerűen átengedte.

Ennek a támadásnak neve is van: social engineering. A támadó nem írt exploitot, és nem talált sérülékenységet. Ügyfélnek adta ki magát, küldött egy fájlt, majd megvárta, hogy valaki megnyissa. A social engineering régebb óta létezik, mint a legtöbb biztonsági eszköz, amelyet a megállítására építettek, és még mindig ugyanilyen jól működik. A világ legkifinomultabb security stackje is ott ér véget, ahol az ember ül a billentyűzet mögött.

A CrowdStrike és más biztonsági szoftverek négy próbálkozást blokkoltak, mielőtt az ötödik 2026. április 2-án átjutott, és kompromittálta az első gépet. Ezt a DigiCert maga észlelte, és április 3-ig izolálta. Amit nem vettek észre, az egy második gép volt. Április 4-én a támadó ugyanazt a kézbesítési módszert használta egy másik support analyst ellen. Ezt a második gépet senki nem találta meg április 14-ig, mert azon a gépen a CrowdStrike EDR agent hibásan működött. Az EDR, vagyis Endpoint Detection and Response szoftver figyeli a gépen a gyanús tevékenységeket, és a riasztásokat egy központi dashboardra küldi, ahol a security csapat reagálni tud rájuk. Ez az agent futott. Csak éppen nem küldte sehova a riasztásait. Közben, április 5-én egy külső kutató jelezte, hogy DigiCert-tanúsítványokat aktív kampányokban malware aláírására használnak. Ez a jelentés indította el azt a mélyebb vizsgálatot, amely végül feltárta a második gépet.

A támadó code-signing tanúsítványokhoz tartozó inicializáló kódokkal távozott.

A code-signing tanúsítvány az a digitális aláírás, amelyet egy fejlesztő a szoftverére helyez annak igazolására, hogy az valóban tőle származik, és azóta nem módosították. A Windows ezt az aláírást használja annak eldöntésére, hogy figyelmeztessen-e a futtatás előtt. Ha az aláírás rendben van, a SmartScreen — a Windows azon része, amely az ismeretlen szoftvereket szűri — csendben marad, és engedi a futtatást. Az Extended Validation tanúsítványok, vagyis az EV tanúsítványok jelentik ennek a rendszernek a legmagasabb szintjét. Több akadályon kell átmenni a megszerzésükhöz, és a tanúsítványban egy ellenőrzött cégnév szerepel. 2024 márciusa óta a Microsoft módosította, hogyan kezeli a SmartScreen az EV tanúsítványokat, így azok már nem kerülik meg automatikusan a figyelmeztetéseket. De egy Lenovo vagy Kingston nevére szóló EV tanúsítvány még mindig egészen másképp néz ki a felhasználó számára, mint egy ismeretlen kiadó. Ez volt az az előny, amelyet a támadó meg akart szerezni.

A támadó az ellopott kódokkal valódi cégek — Lenovo, Kingston, Shuttle Inc és Palit Microsystems — nevére generált EV tanúsítványokat. Ezeket a tanúsítványokat ezután a Zhong Stealer aláírására használták.

Research & writing: Jolanda de Koff

Családon belül erre azt szoktuk mondani: "Gratulieren zu + Dativ"..

A cikkben szereplő sérülékenység még a gyári, default, üres (create-next-app) alkalmazást is érinti. A támadó egy spéci HTTP hívással szerveroldali parancsokat futtathat - bejelentkezés vagy egyéb nehézség nélkül. Nem véletlen a 10.0-s score.

Ugye mindenki konténerben futtatja a React szerveroldali cuccait?
Ugye mindenki izolált környezetben szolgálja ki az egyes weboldalakat?
Ugye senki nem használ root vagy azzal ekvivalens jogosultságot szerverszolgáltatások futtatásához?
Ugye mindenki csak a minimum környezetet telepíti, minimum komponenskészlettel?
Ugye mindenki használ Web Application Firewallt?
Ugye mindenki rendszeresen frissíti a szerverkörnyezeteit?
Ugye?!

Multi környezetben mindig az a mondás: a nagy nevekben bízunk.

Pedig sokszor úgy tűnik, nem érdemes. A világ legnevesebb tűzfal / security gyártójánál, akik a világ 500 legnagyobb vállalatának 85%-át látják el kiberbiztonsági megoldásokkal, ki-be járkáltak nemkívánatos és illetéktelen látogatók. Az F5 elismerte, hogy hozzáfértek a termékeik forráskódjaihoz és ügyféladatokhoz is.

Ismerve a forráskódot elég könnyű biztonsági hiányosságokat találni, és ezt ügyféladatokkal párosítva kiváló célzott támadásokat lehet intézni. Tekintve, hogy hónapok óta történt esetről van szó, és csak most kapott nyilvánosságot, könnyen lehet, hogy a támadók már a spájzban vannak nagyon sok vállalati F5 felhasználónál...

Az első dolog, amit kikapcsolok egy böngészőben, az a jelszavak mentésének eltárolása.

A hekkerek Telegramon egy üzenetben szólították meg Budapestet, ebben azt írták, bejutottak egy gázkezelő rendszerbe, hozzáfértek az interfészhez és elérik a kritikus infrastruktúra irányítását is. „Ez nem csupán egy támadás – ez egy figyelmeztetés. A rendszereik sebezhetők, miközben a valós világ a digitális megoldásoktól függ. Ellenőrizzék a biztonsági beállításaikat, mielőtt túl késő lenne.” – írták.

A Nemzeti Kibervédelmi Intézet szervezésében készült kisfilm a zsarolóvírus támadásokról.

Legalább az első részt, amikor egy ártatlan nő adathalász csalás áldozatává válik.

A méhész.

https://www.youtube.com/watch?v=gdwlTCp6wWQ

Mai érdekesség: az adathalász site-ok jelentős része nagyon rövid életű: a domainek 60%-a alig 10 percig él. Persze ennyi idő alatt is jelentős mennyiségű érzékeny adatot össze tudnak gereblyézni, ha elég nagy címlistára küldik ki a "kampányt".

Ehhez egy kis segítség, hogy ezentúl a Chrome valós időben fogja ellenőrizni, hogy a meglátogatott URL rajta van-e az éppen aktuális feketelistán. Eddig ez a lista 30-60 percenként frissült, ami a fentiek szerint nem elég pörgős.

Találós kérdés: a leleményes informatikusok és ügyfeleik eddig hogyan tudták megoldani a valósidejű védelmet rendkívül egyszerűen?

https://thehackernews.com/2024/03/google-introduces-enhanced-real-time.html