Linux-gebruikers doelwit van aanval met malafide vacature
Linux-gebruikers zijn het doelwit geworden van een aanval waarbij er een zip-bestand met een zogenaamde vacature wordt verstuurd. Dat stelt antivirusbedrijf ESET in een analyse. Het gaat om een spearphishing-aanval waarbij Linux-gebruikers vermoedelijk via e-mail of LinkedIn een "vacature" voor een positie bij de Britse bank HSBC ontvingen.
Het zip-bestand lijkt een pdf-bestand te bevatten, maar is in werkelijkheid geen pdf. De aanvallers hebben een unicode-karakter gebruikt om de bestandsmanager het bestand als een executable te laten behandelen in plaats van een pdf. Bij het direct openen van het bestand via een dubbelklik wordt het dan ook uitgevoerd, aldus ESET. Zodra het bestand wordt geopend zal als afleidingsmanoeuvre een pdf-document via de pdf-viewer van het systeem worden getoond, terwijl in de achtergrond een backdoor vanaf cloudopslagdienst OpenDrive wordt gedownload en uitgevoerd.
ESET stelt dat de aanval het werk is van de Lazarus-groep, die verantwoordelijk worden gehouden voor de aanval op Sony Pictures Entertainment in 2014 en de diefstal van 81 miljoen dollar van een bank in Bangladesh in 2016. Volgens de Amerikaanse autoriteiten opereert de groep vanuit Noord-Korea of wordt door het Noord-Koreaanse regime gesteund.
Reacties (29)
De aanvallers hebben een unicode-karakter gebruikt om de bestandsmanager het bestand als een executable te laten behandelen in plaats van een pdf. Bij het direct openen van het bestand via een dubbelklik wordt het dan ook uitgevoerd
Dat is wel raar, want om een bestand uit te voeren na dubbelklik moet het wel het X bit aan hebben staan, en dat is normaal niet zo met gemailde bestanden en ook niet met ge-unzipte bestanden. Dan zou je een .tar moeten sturen.Of begint de verWindowsing van Linux nu zulke vormen aan te nemen dat grafische filemanagers bestanden UITVOEREN zelfs als ze geen X bit hebben?
hahaha, linux gebruikers phishen met een Windows executable. Hmmm als ze daar in trappen....
Hmm, het is in principe dezelfde techniek als die bij windows gebruikt word:
De gebruiker ziet een andere bestandsnaam dan dat er daadwerkelijk is.
Er is dan ook een simpele oplossing: enkel [a-zA-Z0-9_\-.] toelaten in bestandsnamen.
En dan als extra limiet: de dot mag maar één keer voorkomen in de bestandsnaam. (of twee, als er een aan het begin staat)
Spaties worden natuurlijk vervangen met de underscore.
Ik denk dat dat de enige methode is waarmee je deze problemen zeker kan mitigeren.
Als je dit niet wilt, zul je heuristisch moeten gaan kijken naar vreemde tekens in bestandsnamen.
Alle controle tekens of tekens die buiten de ASCII set vallen zijn meteen een rode flag dan.
De gebruiker ziet een andere bestandsnaam dan dat er daadwerkelijk is.
Er is dan ook een simpele oplossing: enkel [a-zA-Z0-9_\-.] toelaten in bestandsnamen.
En dan als extra limiet: de dot mag maar één keer voorkomen in de bestandsnaam. (of twee, als er een aan het begin staat)
Spaties worden natuurlijk vervangen met de underscore.
Ik denk dat dat de enige methode is waarmee je deze problemen zeker kan mitigeren.
Als je dit niet wilt, zul je heuristisch moeten gaan kijken naar vreemde tekens in bestandsnamen.
Alle controle tekens of tekens die buiten de ASCII set vallen zijn meteen een rode flag dan.
Als je dit soort mails en bestanden opent is er geen enkele beveiliging tegen bestand.
De ESET onderzoekers vermoeden dat de aan Noord Korea gelieerde Lazarus groep achter 3CX supply-chain attack zit.
Ik mis alleen welke exploit er wordt gebruikt om e.e.a uit te voeren.
Door Anoniem: Als je dit soort mails en bestanden opent is er geen enkele beveiliging tegen bestand.
Jawel hoor het x bit. Het verhaal van ESET klopt niet. Linux != WindowsDoor Anoniem:
Of begint de verWindowsing van Linux nu zulke vormen aan te nemen dat grafische filemanagers bestanden UITVOEREN zelfs als ze geen X bit hebben?
Nee dat kunnen filemanagers niet. Het xbit vangt dit af. Daarnaast heb ik nog een keer mijn home gemount met noexec flag en dan is het met xbit aan ook niet mogelijk. ESET is een windows bedrijf die hebben er geen verstand van. Ze proberen het blijkbaar ook niet eens uit.De aanvallers hebben een unicode-karakter gebruikt om de bestandsmanager het bestand als een executable te laten behandelen in plaats van een pdf. Bij het direct openen van het bestand via een dubbelklik wordt het dan ook uitgevoerd
Dat is wel raar, want om een bestand uit te voeren na dubbelklik moet het wel het X bit aan hebben staan, en dat is normaal niet zo met gemailde bestanden en ook niet met ge-unzipte bestanden. Dan zou je een .tar moeten sturen.Of begint de verWindowsing van Linux nu zulke vormen aan te nemen dat grafische filemanagers bestanden UITVOEREN zelfs als ze geen X bit hebben?
Door Anoniem: Hmm, het is in principe dezelfde techniek als die bij windows gebruikt word:
De gebruiker ziet een andere bestandsnaam dan dat er daadwerkelijk is.
Er is dan ook een simpele oplossing: enkel [a-zA-Z0-9_\-.] toelaten in bestandsnamen.
De gebruiker ziet een andere bestandsnaam dan dat er daadwerkelijk is.
Er is dan ook een simpele oplossing: enkel [a-zA-Z0-9_\-.] toelaten in bestandsnamen.
Nee dat heb je verkeerd begrepen, het "rare teken" zit niet in de bestandsnaam maar in het bestand zelf.
Bestandsnamen hebben in Linux geen significantie voor het soort bestand. Het idee dat het soort bestand bepaald wordt
door (de laatste karakters van- ) de naam is een DOS principe wat in Windows is overgenomen.
Linux stamt af van Unix en daar is dit nooit gebruikelijk geweest.
Linux bepaalt het soort bestand aan de hand van de INHOUD. Meestal de eerste paar bytes. Dus ja, je kunt gewoon
een document.pdf file hebben wat in werkelijkheid een programma is, en als je dat opent in de shell of in een filemanager
dan wordt het uitgevoerd, maar alleen als het x bit aan staat voor die file.
Het verhaal wordt daarmee een beetje warrig, je kunt gewoon een binair programma met de naam document.pdf verpreiden
maar dat is dan niet met dubbelklik te starten. Dan moet de gebruiker eerst "chmod +x document.pdf" doen.
Door Anoniem: Dat is wel raar, want om een bestand uit te voeren na dubbelklik moet het wel het X bit aan hebben staan, en dat is normaal niet zo met gemailde bestanden en ook niet met ge-unzipte bestanden.
Ik ben bang dat je je in dat laatste vergist. De commandline-utilities zip en unzip nemen de execute-bit mee, en hebben geen optie om dat uit te zetten. Het gui-programma xarchiver roept onder water zip en unzip aan, dus die handhaaft de execute-bit ook.Door Anoniem: hahaha, linux gebruikers phishen met een Windows executable. Hmmm als ze daar in trappen....
Door Anoniem: Ik mis alleen welke exploit er wordt gebruikt om e.e.a uit te voeren.
Door Anoniem:
Door Anoniem: Als je dit soort mails en bestanden opent is er geen enkele beveiliging tegen bestand.
Jawel hoor het x bit. Het verhaal van ESET klopt niet. Linux != WindowsDoor Anoniem:
Door Anoniem:
Of begint de verWindowsing van Linux nu zulke vormen aan te nemen dat grafische filemanagers bestanden UITVOEREN zelfs als ze geen X bit hebben?
Nee dat kunnen filemanagers niet. Het xbit vangt dit af. Daarnaast heb ik nog een keer mijn home gemount met noexec flag en dan is het met xbit aan ook niet mogelijk. ESET is een windows bedrijf die hebben er geen verstand van. Ze proberen het blijkbaar ook niet eens uit.De aanvallers hebben een unicode-karakter gebruikt om de bestandsmanager het bestand als een executable te laten behandelen in plaats van een pdf. Bij het direct openen van het bestand via een dubbelklik wordt het dan ook uitgevoerd
Dat is wel raar, want om een bestand uit te voeren na dubbelklik moet het wel het X bit aan hebben staan, en dat is normaal niet zo met gemailde bestanden en ook niet met ge-unzipte bestanden. Dan zou je een .tar moeten sturen.Of begint de verWindowsing van Linux nu zulke vormen aan te nemen dat grafische filemanagers bestanden UITVOEREN zelfs als ze geen X bit hebben?
Zeker het gelinkte artikel niet gelezen
Door Anoniem:
Nee dat heb je verkeerd begrepen, het "rare teken" zit niet in de bestandsnaam maar in het bestand zelf.
Bestandsnamen hebben in Linux geen significantie voor het soort bestand. Het idee dat het soort bestand bepaald wordt
door (de laatste karakters van- ) de naam is een DOS principe wat in Windows is overgenomen.
Linux stamt af van Unix en daar is dit nooit gebruikelijk geweest.
Linux bepaalt het soort bestand aan de hand van de INHOUD. Meestal de eerste paar bytes. Dus ja, je kunt gewoon
een document.pdf file hebben wat in werkelijkheid een programma is, en als je dat opent in de shell of in een filemanager
dan wordt het uitgevoerd, maar alleen als het x bit aan staat voor die file.
Het verhaal wordt daarmee een beetje warrig, je kunt gewoon een binair programma met de naam document.pdf verpreiden
maar dat is dan niet met dubbelklik te starten. Dan moet de gebruiker eerst "chmod +x document.pdf" doen.
Nee dat heb je verkeerd begrepen, het "rare teken" zit niet in de bestandsnaam maar in het bestand zelf.
Bestandsnamen hebben in Linux geen significantie voor het soort bestand. Het idee dat het soort bestand bepaald wordt
door (de laatste karakters van- ) de naam is een DOS principe wat in Windows is overgenomen.
Linux stamt af van Unix en daar is dit nooit gebruikelijk geweest.
Linux bepaalt het soort bestand aan de hand van de INHOUD. Meestal de eerste paar bytes. Dus ja, je kunt gewoon
een document.pdf file hebben wat in werkelijkheid een programma is, en als je dat opent in de shell of in een filemanager
dan wordt het uitgevoerd, maar alleen als het x bit aan staat voor die file.
Het verhaal wordt daarmee een beetje warrig, je kunt gewoon een binair programma met de naam document.pdf verpreiden
maar dat is dan niet met dubbelklik te starten. Dan moet de gebruiker eerst "chmod +x document.pdf" doen.
Als ik in de console ./testme.pdf doe, dan krijg ik inderdaad "Hacked word!" terug. (simpele echo bash met +x)
Maar, als ik er op dubbel klik, dan word hij toch wel geopend met de document viewer.
Die geeft dan aan dat "application/x-shellscript" geen ondersteund bestandsformaat is.
Of als ik geen extentie heb, dan geeft de file explorer netjes aan dat het niet weet hoe hij het bestand moet openen.
Heb hetzelfde resultaat als ik een binary gebruik. (/usr/bin/xeyes)
Getest in Ubuntu 18.04.6 LTS
Door Anoniem: Nee dat heb je verkeerd begrepen, het "rare teken" zit niet in de bestandsnaam maar in het bestand zelf.
Het zit wel in de bestandsnaam, die eindigt op ".pdf", met de punt vervangen door een ander unicode-teken dat staat voor een punt met een andere functie. Een test op de extensie zal daardoor geen extensie zien, terwijl die er op het oog wel is.Waarom men dat heeft gedaan? Zoals de redactie het formuleert lijkt het alsof daarmee wordt bereikt dat het bestand als executable wordt behandeld. Het is juister om te zeggen dat men er vermoedelijk mee heeft willen voorkomen dat de executable als pdf wordt behandeld door software die toch naar de extensie kijkt. Of er file managers zijn die dat doen op Linux weet ik niet, ik ken ze echt niet allemaal, maar wie weet overzagen de boeven het dat niet helemaal en dachten ze: baat het niet dan schaadt het niet.
Door Anoniem: hahaha, linux gebruikers phishen met een Windows executable. Hmmm als ze daar in trappen....
Het is een ELF executable voor Linux.Ik ben halvewege al afgehaakt op deze webpagina waarbij men het steeds heeft over het x bit. X bit is normaal onder linux of deze bestand excutable is of niet. Maar een x bit zegt niks over de fout of een bestand toch niet uitgevoerd wordt als een zogenaamde exploit. Soms voeren programma's een bestand niet letterlijk uit (in dit geval de filemanager) maar stuikeld over een code in dat bestand waardoor een deel onder de rechten van de filemanager toch uitgevoerd kan worden. Wie heeft het dan steeds over een x bit ? In principe is alles gevaarlijk als het wat anders doet dan dat je verwacht en kwade bedoelingen heeft. Of dat nu een exutable is, een phissing mail of dergelijke. Verder mensen uit de droom helpen dat elk apparaat, computer enzo onveilig kan zijn, daarin is linux echt niet anders dan windows of apple. Het verschil zit hem alleen in wat het meest gebruikte systeem is, maar alle systemen kunnen exploits hebben en gehackt worden !
Door Anoniem:
ESET regelt ook Linux/UNIX beveiliging voor zowel consumenten als Enterprise.Door Anoniem:
Of begint de verWindowsing van Linux nu zulke vormen aan te nemen dat grafische filemanagers bestanden UITVOEREN zelfs als ze geen X bit hebben?
Nee dat kunnen filemanagers niet. Het xbit vangt dit af. Daarnaast heb ik nog een keer mijn home gemount met noexec flag en dan is het met xbit aan ook niet mogelijk. ESET is een windows bedrijf die hebben er geen verstand van. Ze proberen het blijkbaar ook niet eens uit.De aanvallers hebben een unicode-karakter gebruikt om de bestandsmanager het bestand als een executable te laten behandelen in plaats van een pdf. Bij het direct openen van het bestand via een dubbelklik wordt het dan ook uitgevoerd
Dat is wel raar, want om een bestand uit te voeren na dubbelklik moet het wel het X bit aan hebben staan, en dat is normaal niet zo met gemailde bestanden en ook niet met ge-unzipte bestanden. Dan zou je een .tar moeten sturen.Of begint de verWindowsing van Linux nu zulke vormen aan te nemen dat grafische filemanagers bestanden UITVOEREN zelfs als ze geen X bit hebben?
De default umask van je MUA directories is verschillend we weten namelijk niet welk OS je op linux kernel hebt dat maakt nogal een groot verschil of er een +x mogelijk is
Dat gezegd is Operation Dreamjob een bekende van APT-38 en zijn er genoeg middelen voor blokkeren voor de target groups.
Voor de gene die geen extra beveiliging hebben kan het raadzaam zijn het bestand te scannen via het file command
Je ziet dat meteen wat je mee te maken hebt.
https://linux.die.net/man/1/file
Door Anoniem:
Als ik in de console ./testme.pdf doe, dan krijg ik inderdaad "Hacked word!" terug. (simpele echo bash met +x)
Maar, als ik er op dubbel klik, dan word hij toch wel geopend met de document viewer.
Die geeft dan aan dat "application/x-shellscript" geen ondersteund bestandsformaat is.
Of als ik geen extentie heb, dan geeft de file explorer netjes aan dat het niet weet hoe hij het bestand moet openen.
Heb hetzelfde resultaat als ik een binary gebruik. (/usr/bin/xeyes)
Getest in Ubuntu 18.04.6 LTS
Door Anoniem:
Nee dat heb je verkeerd begrepen, het "rare teken" zit niet in de bestandsnaam maar in het bestand zelf.
Bestandsnamen hebben in Linux geen significantie voor het soort bestand. Het idee dat het soort bestand bepaald wordt
door (de laatste karakters van- ) de naam is een DOS principe wat in Windows is overgenomen.
Linux stamt af van Unix en daar is dit nooit gebruikelijk geweest.
Linux bepaalt het soort bestand aan de hand van de INHOUD. Meestal de eerste paar bytes. Dus ja, je kunt gewoon
een document.pdf file hebben wat in werkelijkheid een programma is, en als je dat opent in de shell of in een filemanager
dan wordt het uitgevoerd, maar alleen als het x bit aan staat voor die file.
Het verhaal wordt daarmee een beetje warrig, je kunt gewoon een binair programma met de naam document.pdf verpreiden
maar dat is dan niet met dubbelklik te starten. Dan moet de gebruiker eerst "chmod +x document.pdf" doen.
Nee dat heb je verkeerd begrepen, het "rare teken" zit niet in de bestandsnaam maar in het bestand zelf.
Bestandsnamen hebben in Linux geen significantie voor het soort bestand. Het idee dat het soort bestand bepaald wordt
door (de laatste karakters van- ) de naam is een DOS principe wat in Windows is overgenomen.
Linux stamt af van Unix en daar is dit nooit gebruikelijk geweest.
Linux bepaalt het soort bestand aan de hand van de INHOUD. Meestal de eerste paar bytes. Dus ja, je kunt gewoon
een document.pdf file hebben wat in werkelijkheid een programma is, en als je dat opent in de shell of in een filemanager
dan wordt het uitgevoerd, maar alleen als het x bit aan staat voor die file.
Het verhaal wordt daarmee een beetje warrig, je kunt gewoon een binair programma met de naam document.pdf verpreiden
maar dat is dan niet met dubbelklik te starten. Dan moet de gebruiker eerst "chmod +x document.pdf" doen.
Als ik in de console ./testme.pdf doe, dan krijg ik inderdaad "Hacked word!" terug. (simpele echo bash met +x)
Maar, als ik er op dubbel klik, dan word hij toch wel geopend met de document viewer.
Die geeft dan aan dat "application/x-shellscript" geen ondersteund bestandsformaat is.
Of als ik geen extentie heb, dan geeft de file explorer netjes aan dat het niet weet hoe hij het bestand moet openen.
Heb hetzelfde resultaat als ik een binary gebruik. (/usr/bin/xeyes)
Getest in Ubuntu 18.04.6 LTS
Hier op Linux Mint 21.1 met Nemo als verkenner getest:
Ik trek een copy van /usr/bin/xeyes
Plaats dat in de /home/<usr>/download map
Hernoem het bestand naar test_me.pdf (met de U+2024 als punt)
In Nemo is het bestands-type nog steeds Program (de x-bit staat nog aan)
Ook het icoontje staat nog op programma ipv tekst/pdf.
Dubbelklik ik op het bestand dan start het bestand xeyes en verschijnen de ogen.
In het rechter muis menu is er geen enkele geassocieerde applicatie zoals bv een pdf-viewer oid te zien.
Verwijder ik de x-bit, en dubbelklik ik op het bestand dan krijg ik de (fout)melding dat het een onbekend bestandstype is.
Als ik het bestand met x-bit aan compress (naar zip) en daarna weer extract, dan staat het x-bit nog steeds aan.
Dus als de x-bit meekomt bij het uitpakken van het zip-bestand, en de gebruiker let niet goed op dan kun je de code in het bestand per ongeluk uitvoeren.
Zelf heb ik de neiging om een data-bestand met de rechter muisknop te openen ipv dubbelklikken.
Zodat ik kan kiezen waar ik het mee wil open.
Door Anoniem: Ik ben halvewege al afgehaakt op deze webpagina waarbij men het steeds heeft over het x bit. X bit is normaal onder linux of deze bestand excutable is of niet. Maar een x bit zegt niks over de fout of een bestand toch niet uitgevoerd wordt als een zogenaamde exploit. Soms voeren programma's een bestand niet letterlijk uit (in dit geval de filemanager) maar stuikeld over een code in dat bestand waardoor een deel onder de rechten van de filemanager toch uitgevoerd kan worden. Wie heeft het dan steeds over een x bit ? In principe is alles gevaarlijk als het wat anders doet dan dat je verwacht en kwade bedoelingen heeft. Of dat nu een exutable is, een phissing mail of dergelijke. Verder mensen uit de droom helpen dat elk apparaat, computer enzo onveilig kan zijn, daarin is linux echt niet anders dan windows of apple. Het verschil zit hem alleen in wat het meest gebruikte systeem is, maar alle systemen kunnen exploits hebben en gehackt worden !
Blijkbaar is de wens de vader van de gedachte maar Linux is een POSIX implementatie geen Windows. Een driveby download infectie is niet mogelijk door het x bitje. Alles itt windows wat wordt gedownload is niet uitvoerbaar. Dat moet eerst nog uitvoerbaar worden gemaakt (ransomware kip en ei probleem). Daarnaast wordt het in een professionele desktop omgeving onmogelijk om in je $HOME of /tmp etc een executible uit te voeren (ook al is het x bitje gezet) dmv selinux of een mountoptie flag (noexec). Valt mij op dat er zo weing windows mensen zijn die iets van Linux weten (trouwens ook van windows zelf).Linux is momenteel de meest gebruikte kernel ter wereld en al langer doelwit van veel zaken. Het probleem van al die hackers is dat ransomware maar geen vat kan krijgen omdat ze het er niet op krijgen (de kenner weet waarom).
Het komt ook sporadisch voor dat ze via een zero day vulnarability binnen kunnen komen. Die tijd is ook kort omdat het veel sneller wordt gepatcht dan in die andere omgeving. Daarnaast heeft het meestal een link met windows (bv smb share). Daarom is het ook niet verstanding connecties met windows software te hebben en niet in te loggen met naam wachtwoord, maar alleen ssh-keys met passphrase of wat anders wat je hebt. Bewaar geen ssh private key (zoals sommigen doen) op je windows (stepping stone) servers want dan ben je vroeg of laat de cigaar.
Het komt ook sporadisch voor dat ze via een zero day vulnarability binnen kunnen komen. Die tijd is ook kort omdat het veel sneller wordt gepatcht dan in die andere omgeving. Daarnaast heeft het meestal een link met windows (bv smb share). Daarom is het ook niet verstanding connecties met windows software te hebben en niet in te loggen met naam wachtwoord, maar alleen ssh-keys met passphrase of wat anders wat je hebt. Bewaar geen ssh private key (zoals sommigen doen) op je windows (stepping stone) servers want dan ben je vroeg of laat de cigaar.
Door Anoniem:
Hier op Linux Mint 21.1 met Nemo als verkenner getest:
Ik trek een copy van /usr/bin/xeyes
Plaats dat in de /home/<usr>/download map
Hernoem het bestand naar test_me.pdf (met de U+2024 als punt)
In Nemo is het bestands-type nog steeds Program (de x-bit staat nog aan)
Ook het icoontje staat nog op programma ipv tekst/pdf.
Dubbelklik ik op het bestand dan start het bestand xeyes en verschijnen de ogen.
In het rechter muis menu is er geen enkele geassocieerde applicatie zoals bv een pdf-viewer oid te zien.
Verwijder ik de x-bit, en dubbelklik ik op het bestand dan krijg ik de (fout)melding dat het een onbekend bestandstype is.
Als ik het bestand met x-bit aan compress (naar zip) en daarna weer extract, dan staat het x-bit nog steeds aan.
Dus als de x-bit meekomt bij het uitpakken van het zip-bestand, en de gebruiker let niet goed op dan kun je de code in het bestand per ongeluk uitvoeren.
Zelf heb ik de neiging om een data-bestand met de rechter muisknop te openen ipv dubbelklikken.
Zodat ik kan kiezen waar ik het mee wil open.
om te unzippen moet malware een programma draaien en dat kan niet (kip en ei probleem)Door Anoniem:
Als ik in de console ./testme.pdf doe, dan krijg ik inderdaad "Hacked word!" terug. (simpele echo bash met +x)
Maar, als ik er op dubbel klik, dan word hij toch wel geopend met de document viewer.
Die geeft dan aan dat "application/x-shellscript" geen ondersteund bestandsformaat is.
Of als ik geen extentie heb, dan geeft de file explorer netjes aan dat het niet weet hoe hij het bestand moet openen.
Heb hetzelfde resultaat als ik een binary gebruik. (/usr/bin/xeyes)
Getest in Ubuntu 18.04.6 LTS
Door Anoniem:
Nee dat heb je verkeerd begrepen, het "rare teken" zit niet in de bestandsnaam maar in het bestand zelf.
Bestandsnamen hebben in Linux geen significantie voor het soort bestand. Het idee dat het soort bestand bepaald wordt
door (de laatste karakters van- ) de naam is een DOS principe wat in Windows is overgenomen.
Linux stamt af van Unix en daar is dit nooit gebruikelijk geweest.
Linux bepaalt het soort bestand aan de hand van de INHOUD. Meestal de eerste paar bytes. Dus ja, je kunt gewoon
een document.pdf file hebben wat in werkelijkheid een programma is, en als je dat opent in de shell of in een filemanager
dan wordt het uitgevoerd, maar alleen als het x bit aan staat voor die file.
Het verhaal wordt daarmee een beetje warrig, je kunt gewoon een binair programma met de naam document.pdf verpreiden
maar dat is dan niet met dubbelklik te starten. Dan moet de gebruiker eerst "chmod +x document.pdf" doen.
Nee dat heb je verkeerd begrepen, het "rare teken" zit niet in de bestandsnaam maar in het bestand zelf.
Bestandsnamen hebben in Linux geen significantie voor het soort bestand. Het idee dat het soort bestand bepaald wordt
door (de laatste karakters van- ) de naam is een DOS principe wat in Windows is overgenomen.
Linux stamt af van Unix en daar is dit nooit gebruikelijk geweest.
Linux bepaalt het soort bestand aan de hand van de INHOUD. Meestal de eerste paar bytes. Dus ja, je kunt gewoon
een document.pdf file hebben wat in werkelijkheid een programma is, en als je dat opent in de shell of in een filemanager
dan wordt het uitgevoerd, maar alleen als het x bit aan staat voor die file.
Het verhaal wordt daarmee een beetje warrig, je kunt gewoon een binair programma met de naam document.pdf verpreiden
maar dat is dan niet met dubbelklik te starten. Dan moet de gebruiker eerst "chmod +x document.pdf" doen.
Als ik in de console ./testme.pdf doe, dan krijg ik inderdaad "Hacked word!" terug. (simpele echo bash met +x)
Maar, als ik er op dubbel klik, dan word hij toch wel geopend met de document viewer.
Die geeft dan aan dat "application/x-shellscript" geen ondersteund bestandsformaat is.
Of als ik geen extentie heb, dan geeft de file explorer netjes aan dat het niet weet hoe hij het bestand moet openen.
Heb hetzelfde resultaat als ik een binary gebruik. (/usr/bin/xeyes)
Getest in Ubuntu 18.04.6 LTS
Hier op Linux Mint 21.1 met Nemo als verkenner getest:
Ik trek een copy van /usr/bin/xeyes
Plaats dat in de /home/<usr>/download map
Hernoem het bestand naar test_me.pdf (met de U+2024 als punt)
In Nemo is het bestands-type nog steeds Program (de x-bit staat nog aan)
Ook het icoontje staat nog op programma ipv tekst/pdf.
Dubbelklik ik op het bestand dan start het bestand xeyes en verschijnen de ogen.
In het rechter muis menu is er geen enkele geassocieerde applicatie zoals bv een pdf-viewer oid te zien.
Verwijder ik de x-bit, en dubbelklik ik op het bestand dan krijg ik de (fout)melding dat het een onbekend bestandstype is.
Als ik het bestand met x-bit aan compress (naar zip) en daarna weer extract, dan staat het x-bit nog steeds aan.
Dus als de x-bit meekomt bij het uitpakken van het zip-bestand, en de gebruiker let niet goed op dan kun je de code in het bestand per ongeluk uitvoeren.
Zelf heb ik de neiging om een data-bestand met de rechter muisknop te openen ipv dubbelklikken.
Zodat ik kan kiezen waar ik het mee wil open.
Daarnaast overweeg:
File systems used for data should always be mounted with nodev , nosuid and noexec .
Potential file system mounts to consider:
/var
/home
/dev/shm
/tmp
/boot
Wil je toch eigen scripts kunnen runnen zet ze dan in /opt met eenproject als eigenaar die niet veel mag of gebruik een CI/CD pijplijn met een ontwikkel VPS voor ontwikkelaars.
Door Anoniem: Ik ben halvewege al afgehaakt op deze webpagina waarbij men het steeds heeft over het x bit. X bit is normaal onder linux of deze bestand excutable is of niet. Maar een x bit zegt niks over de fout of een bestand toch niet uitgevoerd wordt als een zogenaamde exploit. Soms voeren programma's een bestand niet letterlijk uit (in dit geval de filemanager) maar stuikeld over een code in dat bestand waardoor een deel onder de rechten van de filemanager toch uitgevoerd kan worden. Wie heeft het dan steeds over een x bit ? In principe is alles gevaarlijk als het wat anders doet dan dat je verwacht en kwade bedoelingen heeft. Of dat nu een exutable is, een phissing mail of dergelijke. Verder mensen uit de droom helpen dat elk apparaat, computer enzo onveilig kan zijn, daarin is linux echt niet anders dan windows of apple. Het verschil zit hem alleen in wat het meest gebruikte systeem is, maar alle systemen kunnen exploits hebben en gehackt worden !
Het gaat hier om een ELF executable waarvoor bij uitpakken uit het zip-bestand de execute bit wordt aangezet zodat hij ook uitvoerbaar is. Dat er ook andere manieren zijn om code uitgevoerd de krijgen klopt, maar in dit geval speelt de execute bit wel degelijk een hoofdrol.Goed beschreven hier -
https://www.sentinelone.com/labs/cl0p-ransomware-targets-linux-systems-with-flawed-encryption-decryptor-available/ *
En clop komt van het woord voor 'bedwants' in het Russisch.
Het begon allemaal met Linux Encoder als eerste linux ransomware versie; daarna zag men RansomXX.
Voor de ELF-file op Linux: https://linux-audit.com/elf-binaries-on-linux-understanding-and-analysis/
* SentinelOne onderzoekers ontwikkelen o.m. descriptoren voor deze Linux-gerelateerde ransomware.
Maatregelen ter voorkoming van besmettingen: https://phoenixnap.com/blog/linux-ransomware
source credits go to: Borko Drljaca
luntrus
https://www.sentinelone.com/labs/cl0p-ransomware-targets-linux-systems-with-flawed-encryption-decryptor-available/ *
En clop komt van het woord voor 'bedwants' in het Russisch.
Het begon allemaal met Linux Encoder als eerste linux ransomware versie; daarna zag men RansomXX.
Voor de ELF-file op Linux: https://linux-audit.com/elf-binaries-on-linux-understanding-and-analysis/
* SentinelOne onderzoekers ontwikkelen o.m. descriptoren voor deze Linux-gerelateerde ransomware.
Maatregelen ter voorkoming van besmettingen: https://phoenixnap.com/blog/linux-ransomware
source credits go to: Borko Drljaca
luntrus
Door Anoniem:
Daarnaast overweeg:
File systems used for data should always be mounted with nodev , nosuid and noexec .
Potential file system mounts to consider:
/var
/home
/dev/shm
/tmp
/boot
Wil je toch eigen scripts kunnen runnen zet ze dan in /opt met eenproject als eigenaar die niet veel mag of gebruik een CI/CD pijplijn met een ontwikkel VPS voor ontwikkelaars.
Door Anoniem:
Hier op Linux Mint 21.1 met Nemo als verkenner getest:
Ik trek een copy van /usr/bin/xeyes
Plaats dat in de /home/<usr>/download map
Hernoem het bestand naar test_me.pdf (met de U+2024 als punt)
In Nemo is het bestands-type nog steeds Program (de x-bit staat nog aan)
Ook het icoontje staat nog op programma ipv tekst/pdf.
Dubbelklik ik op het bestand dan start het bestand xeyes en verschijnen de ogen.
In het rechter muis menu is er geen enkele geassocieerde applicatie zoals bv een pdf-viewer oid te zien.
Verwijder ik de x-bit, en dubbelklik ik op het bestand dan krijg ik de (fout)melding dat het een onbekend bestandstype is.
Als ik het bestand met x-bit aan compress (naar zip) en daarna weer extract, dan staat het x-bit nog steeds aan.
Dus als de x-bit meekomt bij het uitpakken van het zip-bestand, en de gebruiker let niet goed op dan kun je de code in het bestand per ongeluk uitvoeren.
Zelf heb ik de neiging om een data-bestand met de rechter muisknop te openen ipv dubbelklikken.
Zodat ik kan kiezen waar ik het mee wil open.
om te unzippen moet malware een programma draaien en dat kan niet (kip en ei probleem)Door Anoniem:
Als ik in de console ./testme.pdf doe, dan krijg ik inderdaad "Hacked word!" terug. (simpele echo bash met +x)
Maar, als ik er op dubbel klik, dan word hij toch wel geopend met de document viewer.
Die geeft dan aan dat "application/x-shellscript" geen ondersteund bestandsformaat is.
Of als ik geen extentie heb, dan geeft de file explorer netjes aan dat het niet weet hoe hij het bestand moet openen.
Heb hetzelfde resultaat als ik een binary gebruik. (/usr/bin/xeyes)
Getest in Ubuntu 18.04.6 LTS
Door Anoniem:
Nee dat heb je verkeerd begrepen, het "rare teken" zit niet in de bestandsnaam maar in het bestand zelf.
Bestandsnamen hebben in Linux geen significantie voor het soort bestand. Het idee dat het soort bestand bepaald wordt
door (de laatste karakters van- ) de naam is een DOS principe wat in Windows is overgenomen.
Linux stamt af van Unix en daar is dit nooit gebruikelijk geweest.
Linux bepaalt het soort bestand aan de hand van de INHOUD. Meestal de eerste paar bytes. Dus ja, je kunt gewoon
een document.pdf file hebben wat in werkelijkheid een programma is, en als je dat opent in de shell of in een filemanager
dan wordt het uitgevoerd, maar alleen als het x bit aan staat voor die file.
Het verhaal wordt daarmee een beetje warrig, je kunt gewoon een binair programma met de naam document.pdf verpreiden
maar dat is dan niet met dubbelklik te starten. Dan moet de gebruiker eerst "chmod +x document.pdf" doen.
Nee dat heb je verkeerd begrepen, het "rare teken" zit niet in de bestandsnaam maar in het bestand zelf.
Bestandsnamen hebben in Linux geen significantie voor het soort bestand. Het idee dat het soort bestand bepaald wordt
door (de laatste karakters van- ) de naam is een DOS principe wat in Windows is overgenomen.
Linux stamt af van Unix en daar is dit nooit gebruikelijk geweest.
Linux bepaalt het soort bestand aan de hand van de INHOUD. Meestal de eerste paar bytes. Dus ja, je kunt gewoon
een document.pdf file hebben wat in werkelijkheid een programma is, en als je dat opent in de shell of in een filemanager
dan wordt het uitgevoerd, maar alleen als het x bit aan staat voor die file.
Het verhaal wordt daarmee een beetje warrig, je kunt gewoon een binair programma met de naam document.pdf verpreiden
maar dat is dan niet met dubbelklik te starten. Dan moet de gebruiker eerst "chmod +x document.pdf" doen.
Als ik in de console ./testme.pdf doe, dan krijg ik inderdaad "Hacked word!" terug. (simpele echo bash met +x)
Maar, als ik er op dubbel klik, dan word hij toch wel geopend met de document viewer.
Die geeft dan aan dat "application/x-shellscript" geen ondersteund bestandsformaat is.
Of als ik geen extentie heb, dan geeft de file explorer netjes aan dat het niet weet hoe hij het bestand moet openen.
Heb hetzelfde resultaat als ik een binary gebruik. (/usr/bin/xeyes)
Getest in Ubuntu 18.04.6 LTS
Hier op Linux Mint 21.1 met Nemo als verkenner getest:
Ik trek een copy van /usr/bin/xeyes
Plaats dat in de /home/<usr>/download map
Hernoem het bestand naar test_me.pdf (met de U+2024 als punt)
In Nemo is het bestands-type nog steeds Program (de x-bit staat nog aan)
Ook het icoontje staat nog op programma ipv tekst/pdf.
Dubbelklik ik op het bestand dan start het bestand xeyes en verschijnen de ogen.
In het rechter muis menu is er geen enkele geassocieerde applicatie zoals bv een pdf-viewer oid te zien.
Verwijder ik de x-bit, en dubbelklik ik op het bestand dan krijg ik de (fout)melding dat het een onbekend bestandstype is.
Als ik het bestand met x-bit aan compress (naar zip) en daarna weer extract, dan staat het x-bit nog steeds aan.
Dus als de x-bit meekomt bij het uitpakken van het zip-bestand, en de gebruiker let niet goed op dan kun je de code in het bestand per ongeluk uitvoeren.
Zelf heb ik de neiging om een data-bestand met de rechter muisknop te openen ipv dubbelklikken.
Zodat ik kan kiezen waar ik het mee wil open.
Daarnaast overweeg:
File systems used for data should always be mounted with nodev , nosuid and noexec .
Potential file system mounts to consider:
/var
/home
/dev/shm
/tmp
/boot
Wil je toch eigen scripts kunnen runnen zet ze dan in /opt met eenproject als eigenaar die niet veel mag of gebruik een CI/CD pijplijn met een ontwikkel VPS voor ontwikkelaars.
Maar out-of-the-box reageert de Linux installatie op de manier zoals hierboven beschreven.
Het was een schone/kale VM waar ik het op getest heb zonder "tweaks".
Deze aanval doet me denken aan een soortgelijke aanval, waarbij een bestand "bestand.pdf.desktop" heette. Omdat het bestand "executable" was, werd ".desktop" verborgen door de file manager. Een demo hiervan is al enkele jaren oud: https://www.youtube.com/watch?v=SVsllZ7g7-I
Door Anoniem:
Maar out-of-the-box reageert de Linux installatie op de manier zoals hierboven beschreven.
Het was een schone/kale VM waar ik het op getest heb zonder "tweaks".
Jouw mint omgeving reageert zoals verwacht. Wat had je dan verwacht. Weet u het zeker popup?Door Anoniem:
Daarnaast overweeg:
File systems used for data should always be mounted with nodev , nosuid and noexec .
Potential file system mounts to consider:
/var
/home
/dev/shm
/tmp
/boot
Wil je toch eigen scripts kunnen runnen zet ze dan in /opt met eenproject als eigenaar die niet veel mag of gebruik een CI/CD pijplijn met een ontwikkel VPS voor ontwikkelaars.
Door Anoniem:
Hier op Linux Mint 21.1 met Nemo als verkenner getest:
Ik trek een copy van /usr/bin/xeyes
Plaats dat in de /home/<usr>/download map
Hernoem het bestand naar test_me.pdf (met de U+2024 als punt)
In Nemo is het bestands-type nog steeds Program (de x-bit staat nog aan)
Ook het icoontje staat nog op programma ipv tekst/pdf.
Dubbelklik ik op het bestand dan start het bestand xeyes en verschijnen de ogen.
In het rechter muis menu is er geen enkele geassocieerde applicatie zoals bv een pdf-viewer oid te zien.
Verwijder ik de x-bit, en dubbelklik ik op het bestand dan krijg ik de (fout)melding dat het een onbekend bestandstype is.
Als ik het bestand met x-bit aan compress (naar zip) en daarna weer extract, dan staat het x-bit nog steeds aan.
Dus als de x-bit meekomt bij het uitpakken van het zip-bestand, en de gebruiker let niet goed op dan kun je de code in het bestand per ongeluk uitvoeren.
Zelf heb ik de neiging om een data-bestand met de rechter muisknop te openen ipv dubbelklikken.
Zodat ik kan kiezen waar ik het mee wil open.
om te unzippen moet malware een programma draaien en dat kan niet (kip en ei probleem)Door Anoniem:
Als ik in de console ./testme.pdf doe, dan krijg ik inderdaad "Hacked word!" terug. (simpele echo bash met +x)
Maar, als ik er op dubbel klik, dan word hij toch wel geopend met de document viewer.
Die geeft dan aan dat "application/x-shellscript" geen ondersteund bestandsformaat is.
Of als ik geen extentie heb, dan geeft de file explorer netjes aan dat het niet weet hoe hij het bestand moet openen.
Heb hetzelfde resultaat als ik een binary gebruik. (/usr/bin/xeyes)
Getest in Ubuntu 18.04.6 LTS
Door Anoniem:
Nee dat heb je verkeerd begrepen, het "rare teken" zit niet in de bestandsnaam maar in het bestand zelf.
Bestandsnamen hebben in Linux geen significantie voor het soort bestand. Het idee dat het soort bestand bepaald wordt
door (de laatste karakters van- ) de naam is een DOS principe wat in Windows is overgenomen.
Linux stamt af van Unix en daar is dit nooit gebruikelijk geweest.
Linux bepaalt het soort bestand aan de hand van de INHOUD. Meestal de eerste paar bytes. Dus ja, je kunt gewoon
een document.pdf file hebben wat in werkelijkheid een programma is, en als je dat opent in de shell of in een filemanager
dan wordt het uitgevoerd, maar alleen als het x bit aan staat voor die file.
Het verhaal wordt daarmee een beetje warrig, je kunt gewoon een binair programma met de naam document.pdf verpreiden
maar dat is dan niet met dubbelklik te starten. Dan moet de gebruiker eerst "chmod +x document.pdf" doen.
Nee dat heb je verkeerd begrepen, het "rare teken" zit niet in de bestandsnaam maar in het bestand zelf.
Bestandsnamen hebben in Linux geen significantie voor het soort bestand. Het idee dat het soort bestand bepaald wordt
door (de laatste karakters van- ) de naam is een DOS principe wat in Windows is overgenomen.
Linux stamt af van Unix en daar is dit nooit gebruikelijk geweest.
Linux bepaalt het soort bestand aan de hand van de INHOUD. Meestal de eerste paar bytes. Dus ja, je kunt gewoon
een document.pdf file hebben wat in werkelijkheid een programma is, en als je dat opent in de shell of in een filemanager
dan wordt het uitgevoerd, maar alleen als het x bit aan staat voor die file.
Het verhaal wordt daarmee een beetje warrig, je kunt gewoon een binair programma met de naam document.pdf verpreiden
maar dat is dan niet met dubbelklik te starten. Dan moet de gebruiker eerst "chmod +x document.pdf" doen.
Als ik in de console ./testme.pdf doe, dan krijg ik inderdaad "Hacked word!" terug. (simpele echo bash met +x)
Maar, als ik er op dubbel klik, dan word hij toch wel geopend met de document viewer.
Die geeft dan aan dat "application/x-shellscript" geen ondersteund bestandsformaat is.
Of als ik geen extentie heb, dan geeft de file explorer netjes aan dat het niet weet hoe hij het bestand moet openen.
Heb hetzelfde resultaat als ik een binary gebruik. (/usr/bin/xeyes)
Getest in Ubuntu 18.04.6 LTS
Hier op Linux Mint 21.1 met Nemo als verkenner getest:
Ik trek een copy van /usr/bin/xeyes
Plaats dat in de /home/<usr>/download map
Hernoem het bestand naar test_me.pdf (met de U+2024 als punt)
In Nemo is het bestands-type nog steeds Program (de x-bit staat nog aan)
Ook het icoontje staat nog op programma ipv tekst/pdf.
Dubbelklik ik op het bestand dan start het bestand xeyes en verschijnen de ogen.
In het rechter muis menu is er geen enkele geassocieerde applicatie zoals bv een pdf-viewer oid te zien.
Verwijder ik de x-bit, en dubbelklik ik op het bestand dan krijg ik de (fout)melding dat het een onbekend bestandstype is.
Als ik het bestand met x-bit aan compress (naar zip) en daarna weer extract, dan staat het x-bit nog steeds aan.
Dus als de x-bit meekomt bij het uitpakken van het zip-bestand, en de gebruiker let niet goed op dan kun je de code in het bestand per ongeluk uitvoeren.
Zelf heb ik de neiging om een data-bestand met de rechter muisknop te openen ipv dubbelklikken.
Zodat ik kan kiezen waar ik het mee wil open.
Daarnaast overweeg:
File systems used for data should always be mounted with nodev , nosuid and noexec .
Potential file system mounts to consider:
/var
/home
/dev/shm
/tmp
/boot
Wil je toch eigen scripts kunnen runnen zet ze dan in /opt met eenproject als eigenaar die niet veel mag of gebruik een CI/CD pijplijn met een ontwikkel VPS voor ontwikkelaars.
Maar out-of-the-box reageert de Linux installatie op de manier zoals hierboven beschreven.
Het was een schone/kale VM waar ik het op getest heb zonder "tweaks".
Door Anoniem: Het was een schone/kale VM waar ik het op getest heb zonder "tweaks".
The Linux Foundation IT
Linux workstation security checklist
reviewed 2017-12-15
https://github.com/lfit/itpol/blob/master/linux-workstation-security.md
Onder de kop 'Further reading' staan verwijzingen naar Arch, Debian, Fedora en macOS handleidingen.
NCSC Device Security Guidance
Security guidance for Ubuntu LTS
reviewed 29 June 2021
https://www.ncsc.gov.uk/collection/device-security-guidance/platform-guides/ubuntu-lts
Door Anoniem:
The Linux Foundation IT
Linux workstation security checklist
reviewed 2017-12-15
https://github.com/lfit/itpol/blob/master/linux-workstation-security.md
Onder de kop 'Further reading' staan verwijzingen naar Arch, Debian, Fedora en macOS handleidingen.
NCSC Device Security Guidance
Security guidance for Ubuntu LTS
reviewed 29 June 2021
https://www.ncsc.gov.uk/collection/device-security-guidance/platform-guides/ubuntu-lts
Die guidelines zijn oud en willekeurig. Je kan beter kijken naar gestandaardiseerde security policies: https://www.open-scap.org/Door Anoniem: Het was een schone/kale VM waar ik het op getest heb zonder "tweaks".
The Linux Foundation IT
Linux workstation security checklist
reviewed 2017-12-15
https://github.com/lfit/itpol/blob/master/linux-workstation-security.md
Onder de kop 'Further reading' staan verwijzingen naar Arch, Debian, Fedora en macOS handleidingen.
NCSC Device Security Guidance
Security guidance for Ubuntu LTS
reviewed 29 June 2021
https://www.ncsc.gov.uk/collection/device-security-guidance/platform-guides/ubuntu-lts
Top bedrijven vragen hier aan te voldoen. In de credit card industrie zal je moeten voldoen aan PCI DSS (The Payment Card Industry Data Security Standard ).
Ik gebruik zelf standaard voor bv rhel8 het DISA STIG profiel http://static.open-scap.org/ssg-guides/ssg-rhel8-guide-stig.html#xccdf_org.ssgproject.content_group_permissions
Volgens dit profiel moeten (zoals hierboven voorgesteld) de home folders ge-mount moeten worden met noexec flag, want user directories should not be considered as trusted and users should not be able to execute them . Dat voorkomt heel veel ransomware ellende. ps er zijn natuurlijk meer plekken en devices waarvoor dat geldt.
FIPS moet ik nog wel eens laten schieten want niet alle applicaties zijn FIPS compliant
Het mooie van het rhel8 voorbeeld boven is dat de Ansible snippets er bij staan.
Door Anoniem: Deze aanval doet me denken aan een soortgelijke aanval, waarbij een bestand "bestand.pdf.desktop" heette. Omdat het bestand "executable" was, werd ".desktop" verborgen door de file manager.
Breaking the security model of Subgraph OS
by Micah Lee, posted April 11, 2017
https://micahflee.com/2017/04/breaking-the-security-model-of-subgraph-os
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?