"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.

Zo'n .desktop bestand heeft helemaal geen exec bit. Dat is ook helemaal niet nodig.
In KDE kun je een desktop bestand uitvoeren middels: kioclient exec file:/tmp/bestandsnaam.desktop

En verder helpt de noexec flag op het filesystem ook niet bij bijv. bash scripts
Met /bin/bash /tmp/script.sh wordt het script gewoon uitgevoerd, exec bit of niet.

Gewone gebruikers hebben uiteraard toegang tot hun eigen data die ook confidentieel is.
En eventueel toegang tot andere data via mounts naar NFS of SMB shares.
Misschien wel eens van ransomware gehoord ?
Veel mensen die zo hun data zijn kwijtgeraakt, waren ook gewone gebruiker.

Zoals het verhaal zegt: een .desktop file bevat een Exec veld
Een .desktop file is gewoon een tekst bestand en heeft normaalgesproken geen exec-premissies. Je desktop environment roept echter wel het commando in het exec veld aan. Dat is de start van een besmetting. Afhankelijk van de rechten van de gebruiker kan dat tot grote of minder grote schade leiden.

Gisteren was er een post, waarbij de poster zich afvroeg, hoe het zat met kennis en kunde hier.

Ik denk dat dit weer een mooi voorbeeld is, van personen die hun kennis en kunde zwaar overschatten.

Blijkbaar moeten security bedrijven waarschuwen voor aanvallen, en hier lees is, gaat mij niet gebeuren. Dit laat nu precies zien, wat er mis is met sommige Linux beheerders. Ze overschatten hun eigen kennis en kunde.

Ik lees maar altijd dat Linux veilig is en windows altijd waardeloos is, maar blijkbaar zijn security bedrijven het daar toch niet mee eens.

User data is eigenlijk ook het meest belangrijkste. Het systeem is een leuke toevoeging voor later.

Users hebben cookies bijvoorbeeld, die toegang geven tot systemen. Wachtwoord files, maar toegang tot bedrijfsdata.

En wat ik lees, is dat je oplossing niet werkt bij dit probleem. Nu heb ik zelf te weinig kennis en ervaring om dit te testen, maar blijkbaar lees ik dat je gebrachte oplossing niet werkt.

Maar ik zie wel dat zscaler informatie uitgewerkt heeft
https://www.zscaler.com/blogs/security-research/peek-apt36-s-updated-arsenal#brief-overview
Blijkbaar zijn de o zo veilig linux desktops, toch iets minder veilig dan ik hier lees?

Ik heb het ook niet kunnen vinden en op mijn systeem zie ik het ook niet werken. Maar het doet vermoeden dat er minstens één file manager is die domweg de applicatie waarnaar zo'n .desktop-file verwijst start, ook al staat hij op een rare plek.

Ik heb nautilus (van Gnome) geïnstalleerd, en gekeken wat die met een .desktop-file in /tmp deed als ik erop dubbelklikte. Ik kreeg een foutmelding:
Ik draai geen desktopomgeving maar i3 (een tiling window manager) en dat panel dat nautilus zocht heb ik niet. Maar nautilus probeerde dus niet de .desktop-file te openen in een tekst-editor maar toe te voegen aan het panel van een desktopomgeving. Dan is de gebruiker nog maar één handeling verwijderd van het uitvoeren van wat er in die .desktop-file staat, even aangenomen dat nautilus niet zo "behulpzaam" is om dat meteen uit te voeren.

Zo zou dit mis kunnen gaan, als ik het goed zie.

Alsof er geen hardening bestaat voor power users. Er is veel mogelijk Linux != windows.

Hallo natuurlijk kan je bij je eigen data incl netwerk drives en natuurlijk kan je via scripts van alles executeren. Dat kon je al!
Je bent immers gebruiker.
Het punt is alleen dat de malware er eerst op moet komen en in het voorbeeld wordt het gedownload en het x bitje van het bestand gezet in /tmp maar mag het niet worden uitgevoerd door noexec mount flag.

Zoals eerder gezegd ook afh van selinux policies en mount flags. Daarnaast (wordt ook gemeld in het artikel) wordt uitschakelen van .desktop-bestanden van onbetrouwbare bronnen aangeraden.

Dan lees je dat echt verkeerd. Het is altijd Linux is veiliger dan windows. Er zal altijd gepatcht moeten worden. Zelfs bij read only systemen.

Dan heb je dat verkeerd gelezen want het helpt wel. Zie info van het security bedrijf: https://www.cyfirma.com/research/apt36-targets-indian-boss-linux-systems-with-weaponized-autostart-files/

Zoals dus eigenlijk net als bij Windows, ligt het allemaal aan hoe goed is je beheerder en het beleid vanuit het bedrijf.