"Wanneer de gebruiker het malafide .desktop-bestand opent wordt er een bash commando dat in het Exec field staat uitgevoerd, dat in de achtergrond een payload downloadt."

Hoe werkt dit dan? Wanneer ik een desktop bestand open, dan opent het gewoon in een text editor op zijn best. Het zijn config files, die niet executable zijn, en al zouden ze executable zijn dan doen ze niets.
Of zijn het bash scripts met de desktop extensie?

Om een Linux systeem te infecteren heb je toch echt een local privilege escalation kwetsbaarheid nodig en dat is niet aan de orde. Data van "het systeem stelen" is ook niet aan de orde als gewone gebruiker. Gebruikers kunnen natuurlijk wel altijd hun eigen desktop vernachelen. Vrij dom als je een onbekende zipfile gaat uitpakken en gedownloade bestanden gaat executeren!
Het is ook vrij eenvoudig af te fakkelen door je $HOME (en /tmp) met noexec flag te mounten.

Het is al met al ook helemaal geen Linuxprobleem. Dit soort acties zijn in principe op elke systeem uit te proberen maar blijkbaar wordt de Linux desktop toch meer gebruikt dan men denkt.

Het is blijkbaar weer komkommertijd. Alleen toestaan: .desktop file in /usr/share/applications and icon file in /usr/share/icons/

Ja om een heel systeem te comprimiteren misschien maar 't ironische is dat in een desktop omgeving eigenlijk alle interessante doelwitten zich binnen de gebruikersomgeving bevinden en er daarnaast redelijk weinig te halen valt.
Ben het wel met je eens dat het gebruikers domheid is en dit verder totaal niet nieuwswaardig is.

Gebruikers zelf toestaan eigen gedownloade programma's en in een menu te configureren zou ik niet toestaan als beheerder.
Als een gebruiker er wel op staat kan hij kiezen uit $HOME schoonmaken of zelf filebackup terugzetten.

Ik heb al zoveel pogingen tot phishing en oplichting overleefd (omdat ik die voortijdig eruit had ge-phished), dus deze maakt ook geen kans bij mij. Maar in ieder geval bedankt redactie voor de waarschuwing!

Volgens mij kan dit nog steeds werken zelfs als je noexec gebruikt? Je kan gewoon een bash script injecteren en die kan dan draaien zonder executable. Het is niet alsof je persistency nodig hebt als je doelwit al binnen handbereik is of zo...

En naar mijn weten ligt juist alle interessante data in je home directory. Je browser cookies/wachtwoorden, app tokens en wallets zijn super interessant voor criminelen, en met een beetje pech is dat allemaal in je "/home/gebruiker/.config/" of iets dergelijks opgeslagen...

Juist. Artikel stelt dat ook. "Bash commando wordt uitgevoerd". Interpreter, dus noexec wordt hem (daar) niet. Echter ELF executable wordt gedownload en daar werkt noexec dan weer wel. Oude truuk, erg doorzichtbaar en breekbaar.

Recommendations and Mitigation Strategies volgens de security firm:

1. Email Security Enhancements

Deploy advanced email security solutions capable of detecting spear-phishing emails that contain .desktop, .sh, .elf, and compressed archive attachments.
Disable automatic execution of email attachments and apply sandbox-based detonation of suspicious files prior to delivery.
Enable URL filtering to block connections to newly registered or malicious domains (e.g., securestore[.]cv, modgovindia[.]space).

2. User Awareness and Training

Conduct regular cybersecurity awareness training, with emphasis on phishing indicators and high-risk Linux-specific file types.
Promote caution when handling unsolicited attachments, particularly .desktop files disguised as official documents, or unknown Google Drive links.

3. Host and Operating System Hardening

Restrict execution of files from world-writable directories, such as /tmp, using filesystem mount options (noexec, nodev).
Disable execution of .desktop files from untrusted sources and enforce strict application authorization controls.
Apply least privilege principles in BOSS Linux deployments, with stringent controls over the use of utilities, such as curl, xxd, chmod, and nohup.

4. Endpoint and Network Monitoring

Implement Linux-capable Endpoint Detection and Response (EDR) solutions to monitor for execution of unknown ELF payloads, lateral movement, and C2 beaconing activity.
Monitor DNS and outbound traffic for attempted connections to suspicious or recently registered APT36-associated domains.
Use network segmentation to contain any potential compromise and limit lateral movement within critical infrastructure.

5. Threat Intelligence Integration

Integrate CYFIRMA-provided Indicators of Compromise (IOCs) and YARA signatures into SIEM and IDS/IPS platforms to facilitate early detection.
Conduct initiative-taking threat hunting based on known APT36 tactics, techniques, and procedures (TTPs) mapped to MITRE ATT&CK (e.g., T1204, T1059, T1105).

6. Patch and Vulnerability Management

Ensure BOSS Linux systems and commonly leveraged software (e.g., curl, LibreOffice) are patched promptly to mitigate exploitation of known vulnerabilities.

7. Behavior-Based Controls

Deploy detection rules to identify suspicious command sequences (e.g., curl | xxd | chmod | nohup) executed through .desktop files or shell scripts.
Block execution of binaries downloaded via scripts unless verified and digitally signed by the organization.

bash voert alleen maar commando's uit waar je toch al toegang tot had :) In een locked down desktop zullen veel utilities zoals curl en xxd niet toegankelijk zijn en waarschijnlijk een terminal met python en bash ook niet. Er wordt ook nog veel geexperimenteerd met applicaties in eigen containers https://fedoraproject.org/coreos/

Zo'n rigide maatregel is best kut als je een bepaalde bestandsassociatie van een bestandstype voor je eigen account onklaar wil maken.
Of je moet als root met die .desktop bestanden in die mappen aanpassen. Maar dan pas je eigenlijk een bestand aan die bij een package hoort die onder beheer is van je package manager. Dat gaat die ook niet leuk vinden bij het updaten van die package. En je raakt alle accounts van het systeem ermee.

Kortom: Sta andere .desktop bestanden gewoon toe.

Jij hebt het over bestandsassociatie. Dan gaat het over mimeapps.list en niet over .desktop files
In het algemeen of de packagemanager veranderingen niet leuk gaat vinden hangt af van of er een .d directory beschikbaar is. Zie https://www.redhat.com/en/blog/etc-configuration-directories

Doe eens grep -R MimeType /usr/share/applications en probeer mij maar eens ongelijk te geven.

Ik kan je verzekeren van .desktop files die bij de package horen, dat de packagemanager dat niet leuk vindt.

Je linkt naar configuratie bestanden in /etc. Daar hebben we het helemaal niet over.

Doe eens sudo dpkg -S /usr/share/applications/*.desktop

Linux of een grafische omgeving als Gnome, KDE, Plasma, XFCE, LXDE, LXQt, Mate, Lomiri?

Dat is nogal een verschilletje namelijk..
Elke omgeving die geen desktop manager heeft zou dan al niet vatbar zijn? Als in 99% van alle servers? en dat is dan weer 99% van alle linux omgevingen...

Maar moet wel zeggen dat dit in categorie windows-probleem valt... .exe hernoemen als .pdf enzo..

Heeft niks met vatbaarheid te maken. Er wordt niks hernoemt. Stelling is dat je geen domme dingen moet doen, zoals een onbekende zip uitpakken etc, Geldt voor elk OS

Kan die jaren 80 beheerders mentaliteit " fuck de gebruiker alleen mijn systeemfiles zijn belangrijk" eens naar het sterfhuis ?

Knoop in je oren : ALLEEN data is belangrijk . Dat systeem is er voor niks anders dan die beschikbaar te houden en te verwerken .
Het "systeem" is te volledig te herstellen in minuten .


bash $HOME/nasty.sh

Maar als linux expert , DOE het eens, en kijk eens hoe bruikbaar de desktop nog is.

Het hele feit _dat_ dit een exploit is gericht op een gebruikte desktop omgeving betekent dat een functionele desktop blijkbaar nodig is voor de slachtoffers .
Voor een headless datacenter server zal deze aanval niet zinvol zijn.


Hetzelfde kunstje op Windows is altijd wel de schuld van Windows .

Inderdaad.
En de rest van de gebruikersdata zal ook wel interessant zijn.

Linux desktops zijn nogal een niche - degenen die erop werken zijn , grosso modo, allemaal "power users" op de een of andere manier. De 'thuis internet hobbyist' met een Linux desktop bestaat maar is wel heel marginaal .

Ontwikkelaars van iets - code , research . Ongeveer alles wat ze werkelijk _moeten_ doen zal toch (ook) leven of bereikbaar zijn vanuit de homedirectory . Of het nu python, R , matlab ,SQL, C of Rust is .

Dat maakt al die 'locked down' commentaren zo onmogelijk. "kiosk mode' (alleen een browser, niks persistents), iets als een tablet , of een Chromebook bestaat .
En voor degenen die genoeg hebben aan die functionaliteit is dat een uitstekende oplossing waarin ontzettend veel van dit soort risico's omzeild zijn.

Maar juist voor degenen die een 'full function' desktop _nodig_ hebben is het vrijwel onmogelijk om die "veilig" en toch "functioneel" te houden.