GHOSTWORKER: slēpts UniFi vārtejas implants, kas slepus sazinās caur Google DNS

§ 01. Kas mūs sagaidīja

Autentifikācijas apiešanai pietika ar vienu neautentificētu pieprasījumu, uz kuru atbildē saņēmām pilnu kontrollera lietotāju kontu sarakstu. Tajā bija divi nesankcionēti administratora konti, kas imitēja Ubiquiti tehniskā atbalsta kontus. Pēc root līmeņa piekļuves iegūšanas ierīcei mēs identificējām papildu kompromitācijas pierādījumus: nezināmu bināro failu direktorijā /bin, kas nepiederēja nevienai instalētajai pakotnei. Tas bija konfigurēts automātiskai palaišanai pēc pārstartēšanas, maskējās par kodola pavedienu un uzturēja ārēju saziņu, izmantojot DNS-over-HTTPS (DoH). Šo implantu visā ziņojumā saucam par GHOSTWORKER.

Mūsu izmeklēšana apstiprināja trīs atsevišķus konstatējumus, kas šajā ziņojumā apzināti aplūkoti nošķirti. Pirmkārt, ierīce ir ievainojama pret maksimāla kritiskuma autentifikācijas apiešanu, ko CISA norāda kā aktīvi izmantotu; ievainojamību mēs pārbaudījām ar nedestruktīvu testu. Otrkārt, vārteja jau bija kompromitēta, pirms mēs sākām novērtējumu. Paša kontrollera datubāzēs ir pierādījumi par nesankcionētiem administratora kontiem un operatora aktivitāti jau kopš 2026. gada jūnija vidus. Treškārt, ierīcē atradās īpaši izstrādāts implants ar noturības pēc pārstartēšanas un procesa slēpšanas mehānismiem.

Mēs neesam konstatējuši, ka autentifikācijas apiešanas ekspluatāciju un GHOSTWORKER izvietošanu veica viens un tas uzbrucējs. Gadījumos, kad pieejamie pierādījumi pamato tikai analītisku secinājumu, nevis apstiprinātu konstatējumu, šī atšķirība ir skaidri norādīta.

§ 02. Kā apiešana darbojas

UniFi OS aizsargā iekšējos servisus ar autentifikācijas vārteju, vienlaikus ļaujot piekļūt dažiem publiskiem maršrutiem bez autentifikācijas. Vārteja nosaka, vai maršruts ir publisks, pēc nedekodēta pieprasījuma URL, savukārt aiz tās esošais nginx maršrutē pieprasījumu pēc dekodēta URL. Šīs atšķirīgās interpretācijas rada iespēju apiet autentifikāciju. URL, kas sākas ar publisko prefiksu /api/auth/validate-sso/, bet satur kodētas ../ sekvences, vārtejā tiek atzīts par publisku, bet pēc dekodēšanas pārvēršas par aizsargātu /proxy/<serviss>/… ceļu un sasniedz iekšējo servisu (backend) bez autentifikācijas. Šī neatbilstība ir pamatā ievainojamību pārim CVE-2026-34908 (nepilnīga piekļuves kontrole) un CVE-2026-34909 (direktoriju šķērsošana). Ubiquiti to apraksta paziņojumā SAB-064, bet Bishop Fox – savā tehniskajā analīzē.

Darbības principu ilustrē divi pieprasījumi, kas nosūtīti tieši caur TLS savienojuma ligzdu (socket), lai saglabātu ..%2f secību un nepieļautu tās normalizēšanu HTTP klientā.

Izmantojot apiešanu, ieguvām septiņus lokālo lietotāju ierakstus – lietotājvārdus, e-pasta adreses un lauku nosaukumus api_keys, nfc_token un password_revision. Apiešana ļauj ar administratora tiesībām piekļūt arī datu izmaiņu galapunktiem. PUT pieprasījums īpašnieka kontam mainīja profila lauka vērtību, un izmaiņa tika saglabāta; pēc pārbaudes atjaunojām sākotnējo vērtību. Ar PUT pieprasījumu iestatījām superadministratora lauku x_password un pēc tam pieteicāmies ierastajā veidā. Tā ieguvām autentificētu sesiju un pilnu kontroli pār konsoles SSH iestatījumiem.

§ 03. Kļūstot par daļu no botu tīkla

Ubiquiti 2026. gada 21. maijā publicēja drošības paziņojumu SAB-064 par CVE-2026-34908, CVE-2026-34909 un CVE-2026-34910. Katrai ievainojamībai piešķirts CVSS novērtējums 10.0, un, sasaistot tās ķēdē, neautentificēts attālināts uzbrucējs varēja iegūt root līmeņa piekļuvi skartajām UniFi sistēmām.

Bishop Fox pēc tam demonstrēja pilnu ekspluatācijas ķēdi pret UniFi OS Server 5.0.6. Ubiquiti novērsa ievainojamības UniFi OS Server 5.0.8 versijā, tostarp unifi-core 5.0.153. Ubiquiti publicētajā skarto produktu sarakstā ir UDM, UDM-Pro, UDM-SE un UDM-Pro-Max, tostarp klienta vidē izvietotais modelis.

2026. gada 23. jūnijā CISA pievienoja visas trīs ievainojamības savam zināmo ekspluatēto ievainojamību (KEV) katalogam, apstiprinot, ka ekspluatācija novērota reālos uzbrukumos. Tā laika ziņojumi daļu agrīnās ekspluatācijas saistīja ar Mirai/Gafgyt saimes botu tīklu aktivitāti un aprakstīja uzbrucējus, kas kompromitētajās UniFi ierīcēs veido nesankcionētus administratora kontus.

Šī aktivitāte ir būtiska šai izmeklēšanai, jo mēs neatkarīgi identificējām nesankcionētus administratora kontus skartajā vārtejā. Šī sakritība atbilst publiski ziņotajai pēcekspluatācijas uzvedībai; tomēr tā pati par sevi nepierāda, ka par šo kompromitāciju atbildīga tā pati kampaņa vai uzbrucējs.

§ 04. Binārais fails, kas nepieder nevienai pakotnei

Izmantojot autentifikācijas apiešanu, iestatījām SSH paroli. Pēc ar klientu saskaņotas ierīces pārstartēšanas izdevās izveidot SSH savienojumu ar root tiesībām.

uid=0(root) gid=0(root) groups=0(root)
Linux UDM-Pro 4.19.152-ui-alpine … aarch64 GNU/Linux
eth8  UP  <wan-ip>/28 (WAN)   br0  192.168.1.1/24 (LAN)   uptime: up 2 min

Vispirms uzmanību piesaistīja fails direktorijā /bin:

# dpkg -S /bin/unifi_updater
dpkg-query: no path found matching pattern /bin/unifi_updater

Visi leģitīmie UniFi binārie faili pieder kādai pakotnei, taču šis fails nepiederēja nevienai. Tā izmērs bija 4 097 312 baiti, īpašnieks – root. Ieraksts root lietotāja crontab nodrošināja faila palaišanu pēc katras pārstartēšanas:

# /var/spool/cron/crontabs/root  (izveidots sestdien, 2026. gada 27. jūnijā, 20:50:49)
@reboot sleep 60 && /bin/unifi_updater

§ 05. Analīzes kavēšana ar vienu baitu

Sākotnējā formā fails traucē ierasto analīzes rīku darbību – file, readelf, capa un standarta YARA to identificē kā "ELF 64-bit MSB, unknown arch 0xffffb700." To izraisa viens baits. EI_DATA lauks ELF galvenē ar nobīdi 5 nosaka baitu secību. Tā vērtība ir 0x02 (big-endian), lai gan faila lauki faktiski izmanto little-endian secību. Rīki paļaujas uz šo vērtību, interpretē mašīnas tipa baitus b7 00 pretējā secībā un iegūst neeksistējošas arhitektūras identifikatoru. ARM64 kodols EI_DATA ignorē, tāpēc fails joprojām darbojas. Nomainot šo vērtību uz 0x01, rīki failu nolasa korekti.

§ 06. GHOSTWORKER statiskā analīze

GHOSTWORKER binārā faila statiskā analīze atklāja funkcionalitāti, kas atbilst noturīgai vārtejas kompromitācijai, C2, piekļuves datu vākšanai, resursdatora izlūkošanai un papildu ļaunatūras komponentu piegādei.

Kopumā šīs spējas ir īpaši nozīmīgas tāpēc, ka implants tika izvietots tīkla vārtejā. Ierīce ieņem priviliģētu pozīciju, caur kuru iet ievērojama tīkla datplūsma, savukārt GHOSTWORKER satur funkcionalitāti šīs pozīcijas izmantošanai: tas var izveidot ārēju C2 kanālu, lejupielādēt papildu ļaunatūras komponentus, mainīt ugunsmūra darbību, profilēt lokālo vidi un vākt datplūsmā atklātā veidā pieejamus piekļuves datus.

Procesa maskēšanās un tās atklāšana

Procesa maskēšanās rada noderīgu atklāšanas pazīmi. Leģitīmi kworker procesi ir kodola pavedieni un tāpēc netiek palaisti no parasta izpildāma faila diskā. GHOSTWORKER imitē kodola pavedienu, taču patiesībā darbojas kā lietotāja telpas process, kas palaists no izpildāma faila.

Tāpēc process ar nosaukumu [kworker/*] jāuzskata par aizdomīgu, ja:

• /proc/<pid>/exe norāda uz izpildāmu failu;
• /proc/<pid>/maps rāda parastu lietotāja telpas izpildāmā faila kartējumu;
• process uztur ārējus tīkla savienojumus;
• procesam ir parasta komandrinda vai izpildāmā faila indeksmezgls (inode), kas neatbilst kodola pavedienam.

§ 07. Vadība un kontrole (C2), izmantojot DoH

Implants nesūta periodiskos saziņas ziņojumus tieši uz C2 servera IP adresi. Tā vietā tas izmanto DNS-over-HTTPS un Google publisko DNS serveri: sūta POST /dns-query pieprasījumus ar galveni Host: dns.google uz 8.8.8.8:443. Dati tiek iekodēti DNS nosaukumos operatora kontrolētā domēnā, izmantojot to pašu %s%c%08lx.%s%d formātu. Tīkla līmenī šī saziņa izskatās kā kārtējais HTTPS savienojums ar Google: nav nešifrētu DNS pieprasījumu, ko reģistrēt žurnālos, un galamērķis neizskatās neparasts. Katrā pieprasījumā ir viltota Chrome darbvirsmas versijas User-Agent virkne (…rv:129.0… Chrome/129.0.0.0).

Kriptogrāfijas risinājums liecina, ka implants nav gatavs, plaši pieejams rīks. Binārajā failā ir iegulti trīs PEM bloki:

• pašparakstīts CA sertifikāts, CN=linfosyshosting.nl, derīgs no 2020-07-17 līdz 2030-07-15;
• tam atbilstoša privātā atslēga – atbilstību pārbaudījām, salīdzinot RSA moduļus;
• atsevišķa 3072 bitu RSA publiskā atslēga komandu verifikācijai un izejošo datu šifrēšanai.

Servera privātās atslēgas klātbūtni implantā interpretējam kā norādi uz kanāla piesaisti konkrētai atslēgai un savstarpēju autentifikāciju: implants sazinās tikai ar atbilstošās atslēgas turētāju. Tas aizsargā operatora saziņu un vienlaikus sniedz aizsardzības komandām precīzu meklēšanas pazīmi.

§ 08. Linfosys infrastruktūra

Ar GHOSTWORKER saistītais TLS sertifikāts norāda resursdatora nosaukumu linfosyshosting.nl. Domēnu izpētījām tikai pasīvos avotos, neveidojot savienojumu ar aizdomīgo C2 infrastruktūru. Pasīvie DNS dati saistīja resursdatora nosaukumu ar 185.206.140.190.

RIPE reģistrācijas un maršrutēšanas dati rāda konsekventu saikni starp resursdatora nosaukumu, mitināšanas tīklu un implanta izmantoto DNS infrastruktūru.

Vairākos infrastruktūras elementos atkārtojas viens nosaukums. Gan sertifikātā norādītais resursdatora nosaukums, gan DNS tuneļa vārdu serveri, gan tīkla reģistrācijas ieraksts satur Linfosys identifikatoru. Pieejamie dati arī liecina, ka sertifikāta identitāte un attiecīgā tīkla reģistrācija datējamas ar aptuveni 2020. gadu – vairākus gadus pirms šā incidenta.

Operatora piekļuves infrastruktūra

UniFi kontrollera admin_activity_log kompromitācijas periodā reģistrēja administratīvu piekļuvi no vairākām ārējām mitināšanas pakalpojumu sniedzēju adresēm:

Attiecināšanas ierobežojumi

Mēs neattiecinām šo aktivitāti uz kādu konkrētu personu vai uz Linfosys BV.

Tas, ka RIPE reģistrē C2 adrešu telpu ar Linfosys nosaukumu, apstiprina tikai reģistrācijas un maršrutēšanas saikni. Tas nenosaka, kurš darbināja GHOSTWORKER infrastruktūru. Ticami skaidrojumi ietver klientu, kas izmanto šo tīklu, tālākpārdevēju vai pakārtotu operatoru, kompromitētu infrastruktūru vai infrastruktūru, kas apzināti izvēlēta tāpēc, ka tās nosaukums un reģistrācija izskatītos leģitīmi.

Arī pats sertifikāts satur identitātes informāciju, kas šķiet neuzticama. Tā organizācijas lauks norāda "Piratpartiet", savukārt citi subjekta atribūti apvieno ģeogrāfisku informāciju no vairākām savstarpēji nesaistītām jurisdikcijām. Tāpēc mēs vērtējam sertifikāta identitātes laukus kā, visticamāk, izdomātus vai apzināti maldinošus un nepiešķiram tiem attiecināšanas nozīmi.

Nozīmīgākais infrastruktūras analīzes konstatējums ir atkārtoti novērotā tehniskā saikne starp resursdatora nosaukumu ar Linfosys identifikatoru, autoritatīvo DNS infrastruktūru un autonomo sistēmu, kurā mitināts aizdomīgais C2 serveris.

§ 09. Kāds jau bija iekšā

Kontrollera datubāzes rāda ielaušanos, kas sākās pirms mūsu testa. Divi superadministratora konti tika pievienoti, apejot ierasto kontu izveides procesu – unifi_support (2026. gada 17. jūnijā) un supports_unifi_system (9. jūlijā). Abi imitēja Ubiquiti atbalsta kontu nosaukumus, izmantojot to pašu maskēšanās paņēmienu kā implanta faila nosaukumā. Neviens no tiem nav atrodams tabulā unique_logins, kurā reģistrēts tikai viens leģitīms lietotājs, kas jebkad pieteicies sistēmā. Konti tika pievienoti tieši datubāzē; šajā tabulā to pieteikšanās nav reģistrēta.

Vienu sakritību ir grūti uzskatīt par nejaušību. supports_unifi_system tika izveidots 9. jūlijā 19:56:12 UTC, un pieteikšanās no 185.44.78.8 reģistrēta 19:56:18 – sešas sekundes vēlāk. Implanta crontab tika ierakstīts 61 sekundi pēc tās pašas adreses pēdējās administratora paneļa darbības 27. jūnijā. Konstatējumus un secinājumus iedalām pēc pārliecības pakāpes:

• Apstiprināts. Ierīce ir ievainojama pret apiešanu, un mēs to izmantojām. Divi superadministratora konti, kas imitē atbalsta dienestu, tika pievienoti tieši datubāzē, un to aktivitāte ir saistīta ar ārējām IP adresēm. Vārtejā atradās AArch64 implants ar modificētu ELF galveni, automātisku palaišanu ar @reboot, maskēšanos par [kworker], DoH C2 kanālu, kā arī iegultu sertifikātu un tam atbilstošu privāto atslēgu. Sertifikātu, saistītos vārdu serverus un mitināšanas tīklu vieno Linfosys nosaukums; tie datējami ar 2020. gadu.
• Ticami. Darbības veicis viens uzbrucējs: viena un tā pati galvenā IP adrese ir saistīta gan ar implanta instalēšanu, gan administratoru pieteikšanos, un nosaukumos izmantots vienots maskēšanās paņēmiens. Izmantotie risinājumi liecina par tehnisku kompetenci – DoH tunelēšana, sertifikāta piesaiste, maskēšanās par kodola pavedienu un galvenes modificēšana ir sarežģītāki paņēmieni nekā tipiskos botu tīklu rīkos. Ticamākais scenārijs ir pieredzējis operators, kas izmantojis nesen publiskotu, aktīvi ekspluatētu ievainojamību internetā sasniedzamā ierīcē.
• Nepierādīts. Mēs to nevaram sasaistīt ar Linfosys kā uzņēmumu. Mēs neredzējām sākotnējo ielaušanos. Tāpat nenoskaidrojām periodiskās saziņas intervālu un komandu kopu, jo tam būtu nepieciešams palaist paraugu. To nedarījām, lai nepieļautu saziņu ar C2 infrastruktūru.

§ 10. Kompromitācijas indikatori

Tālāk apkopoti novērtējuma laikā novērotie indikatori, kas norādītajās vietās papildināti ar publisku reģistru datiem. Klienta spēkā esošie slepenie dati un abas privātās atslēgas netiek publicētas.

§ 11. Ko meklēt

Autentifikācijas apiešanu var pārbaudīt ar vienkāršu testu, un implants atstāj skaidri identificējamas pēdas. UniFi un citās Linux tīkla perimetra ierīcēs veiciet šādas pārbaudes:

• Pārbaudiet autentifikācijas apiešanu. Ja GET /proxy/users/api/v2/users atgriež 401, bet tas pats ceļš aiz /api/auth/validate-sso/..%2f..%2f..%2f atgriež 200, jūsu ierīce ir ievainojama. Uzstādiet drošības atjauninājumus un ierobežojiet pārvaldības saskarnes pieejamību no publiskā interneta.
• Ar drošības atjauninājumu uzstādīšanu vien nepietiek. Pēc atjauninājumu uzstādīšanas pārbaudiet lokālo administratoru kontus. Meklējiet kontus, kas pievienoti, apejot ierasto izveides procesu, un nav atrodami tabulā unique_logins, īpaši tos, kas imitē atbalsta kontus. Salīdziniet admin_activity_log avota IP ar leģitīmo administratoru izmantotajām adresēm.
• Meklējiet bināros failus, kas nepieder nevienai pakotnei. Padziļināti pārbaudiet failus direktorijās /bin un /sbin, kuru piederību pakotnei nevar noteikt ar dpkg -S, kā arī @reboot cron ierakstus, kas tos palaiž.
• Meklējiet maskēšanos. Process ar nosaukumu [kworker/*], kura /proc/<pid>/exe norāda uz īstu failu, nav kodola pavediens. Pārbaudiet arī /var/tmp/a.tmp un ELF failus ar EI_DATA=0x02, kas joprojām darbojas.
• Uzraugiet tīkla ierīču izejošo DoH datplūsmu. Vārteja, kas sūta application/dns-message uz publisku DNS serveri, ir anomālija. Bloķējiet vai uzraugiet linfosyshosting.nl, *.linfosys.{nl,eu,com}, 185.206.140.190 un AS61351.
• Ja konstatējat šīs pazīmes, uzskatiet ierīci par pilnībā kompromitētu. Izolējiet to, saglabājiet bināro failu un žurnālus, atjaunojiet ierīci ar tīru programmaparatūru un nomainiet visus tajā glabātos slepenos datus. Ar faila dzēšanu nepietiek.

§ 12. Kāpēc tas ir svarīgi

Tīkla perimetra vārtejas nereti paliek bez pienācīgas uzmanības. Tās ir pieejamas no interneta, atjauninājumus bieži saņem pēdējās, un iekšējā tīkla sistēmas tām uzticas. Ja vārteja darbina plašu programmatūras steku, kompromitācija ar root tiesībām var atklāt Wi-Fi atslēgas, RADIUS koplietojamos noslēpumus, kontrollera datubāzes un videonovērošanas sistēmas, kā arī dot iespēju pārraudzīt caur vārteju plūstošo datplūsmu.

Šis gadījums ilustrē pazīstamu risku: no interneta bija sasniedzama konsole ar novecojušu programmatūru un publiski zināmu, aktīvi ekspluatētu UniFi ievainojamību ar maksimālo kritiskuma novērtējumu. Līdz plānotā testa sākumam uzbrucējs tajā jau bija izveidojis administratora kontus un izvietojis implantu ar root tiesībām. Izšķirošs ir reaģēšanas ātrums: internetā sasniedzamu ierīci var kompromitēt jau dažu nedēļu laikā pēc ievainojamības publiskošanas. Lēmums atlikt atjauninājumus līdz nākamajam apkopes ciklam rada risku, ka ielaušanās notiks vēl pirms tā.

Izmeklēšanu veicām autorizēta ielaušanās testa ietvaros. Uzbrucēja indikatorus publicējam pilnībā, lai arī citi varētu savā vidē meklēt šā operatora darbības pēdas. Ja pārvaldāt internetā sasniedzamu UniFi vārteju, sāciet ar iepriekš aprakstīto divu pieprasījumu testu un pēc tam pārbaudiet, vai kāds [kworker] process nav palaists no izpildāma faila diskā.