Lazarus-hackers richten zich op IT'ers met Linux-malware verhuld als vacature

Lazarus-hackers gelieerd aan Noord-Korea richten zich met specifieke Linux-malware op IT'ers door middel van een nepvacature. Softwaremakers werden bijvoorbeeld via LinkedIn benaderd met een baanaanbod, waarna er een geïnfecteerd bestand werd opgestuurd.

Slachtoffers kregen deze nepvacature te zien. Afbeelding via ESET

De hackers opereren volgens cyberbeveiligingsexperts van ESET onder de noemer Operation DreamJob en gebruiken een ogenschijnlijk .pdf-bestand om malware op het Linux-systeem van slachtoffers te installeren. Het ogenschijnlijke .pdf-bestand, een 64-bit Intel-Linux-binary met de naam HSBC job offer․pdf, is daarentegen eigenlijk een executable. Hoewel er na het openen een nepvacature op het scherm verschijnt zou er op de achtergrond een payload gedownload worden vanaf OpenDrive. Hiermee wordt vervolgens een SimplexTea-backdoor geïnstalleerd.

Dezelfde beveiligingsonderzoekers concluderen 'met een hoge mate van zekerheid' op basis van de bovenstaande ondervindingen dat de recentelijke cyberaanval op 3CX door dezelfde organisatie werd uitgevoerd. Na een supplychainaanval verspreidde de desktopclient van de voip-dienst malware; Lazarus zou ook hierachter hebben gezeten. De twee voorbeelden onderstrepen volgens ESET hoe gewiekst de Noord-Koreaanse hackers te werk kunnen gaan op verschillende platformen.

Reacties (138)

[Freeaqingme]

Wat mij betreft stopt dit artikel precies daar waar het interessant wordt. Immers, wat doet die backdoor vervolgens? Op deze website vond ik nog wat meer info: https://www.bleepingcompu...ware-via-fake-job-offers/

Inside the archive hides a Go-written Linux binary that uses a Unicode character on its name to make it appear like a PDF.

"Interestingly, the file extension is not .pdf. This is because the apparent dot character in the filename is a leader dot represented by the U+2024 Unicode character," explains ESET.

"The use of the leader dot in the filename was probably an attempt to trick the file manager into treating the file as an executable instead of a PDF."

"This could cause the file to run when double-clicked instead of opening it with a PDF viewer."

When the recipient double-clicks on the file to launch it, the malware, known as "OdicLoader," displays a decoy PDF while simultaneously downloading a second-stage malware payload from a private repository hosted on the OpenDrive cloud service.

The second-stage payload is a C++ backdoor called "SimplexTea," which is dropped at "~/.config/guiconfigd. SimplexTea."

OdicLoader also modifies the user's ~/.bash_profile to ensure that SimplexTea is launched with Bash and its output is muted whenever the user starts a new shell session.

The second-stage payload is a C++ backdoor called "SimplexTea," which is dropped at "~/.config/guiconfigd. SimplexTea."

OdicLoader also modifies the user's ~/.bash_profile to ensure that SimplexTea is launched with Bash and its output is muted whenever the user starts a new shell session.

[mekkieboek]

Hoewel ze genoeg rottigheid kunnen uithalen met de rechten vd ingelogde gebruiker (en via diens .bash_profile), krijgen ze niet zomaar hetzelfde voor elkaar met superuser privileges. Een sudo shell leest niet de .bash_profile van de oorspronkelijke gebruiker.

Dat gezegd hebbende, ik zie dat op mijn systeem bijvoorbeeld device /dev/nvidia0 ook wagenwijd open staat voor schrijven (crw-rw-rw-)

[Freeaqingme]

Sure, ik kan niet echt direct vinden met welke intentie ze dit doen. Maar ze kunnen bijv. wel gewoon bij je .ssh private keys of ssh-agent. Daarmee kunnen ze dan weer inloggen op alle servers waar die gebruiker bij kan.

[rbr320]

Vandaar dat het een goed idee is om je ssh keys te beveiligen met een passphrase.

[jurroen]

Te encrypten met een passphrase*

Het gebruik van encrypted private keys is iets wat ik wel kan aanraden, zéker als je te maken hebt met een verhoogd risico of toegang hebt tot systemen met gevoelige informatie.

Het is echter niet meer dan een beveiligingslaag, waar geavanceerde malware omheen kan werken. Bijvoorbeeld door het gebruik van een keylogger. Dat kan door via een andere exploit de privileges te verhogen, of bijvoorbeeld via een transparante overlay op het scherm.

Als je meent meer risico te lopen zou je kunnen kiezen om je systeem meer dicht te timmeren en bijvoorbeeld documenten die je krijgt toegestuurd te openen met iets als Dangerzone.

[rbr320]

Als je meent meer risico te lopen zou je kunnen kiezen om je systeem meer dicht te timmeren en bijvoorbeeld documenten die je krijgt toegestuurd te openen met iets als Dangerzone.

Interessante tool, deze kende ik nog niet maar die gaat zeker in mijn toolbox. Overigens vind ik het wel bijzonder dat bij de installatieinstructies voor Debian/Ubuntu je als eerste stap een bash script vanaf een URL direct een root shell in piped. Dit is een grote security no-no.

[Aldy]

Ter info: https://dangerzone.rocks/ is er niet alleen voor Linux, maar ook voor MacOS en Windows.

[svane]

Dit is een grote security no-no.

Ik heb dat nooit zo goed begrepen eigenlijk. Wat is realistisch gezien het grote verschil tussen het pipen van url, en het uitvoeren van een binary? Als de makers van Dangezone echt kwaad willen, waarom zou dat niet via een .msi of een .dmg bestand (en de installatie die hierop volgt) kunnen? Het shell script kan je tenminste nog zelf doorlezen. Binaries zijn een stuk lastiger. Zijn er voorbeelden bekend waar een malafide website een applicatie host die zelf prima is, maar kwaadaardige code verstopt heeft in het shell-script wat gepiped wordt?

Ik snap het argument dat het problematisch is als de verbinding halverwege wegvalt, en dat bijv. het commando `rm -rf ~/.Dangerzone/config` afgekapt wordt tot `rm -rf ~/`, dat zou niet fijn zijn. In dit script zie ik echter dat ze eerst functies definiëren, en pas op de laatste regel uitvoeren, dus dit is ook geen probleem.

Op basis hiervan zou ik het pipen van een URL op z'n hoogst 'niet best best practise' noemen, in plaats van 'grote security no-no'.

Maar toch lees ik dit vaak, dus ik ben benieuwd wat ik hier mis

[Reactie gewijzigd door svane op 22 juli 2024 19:10]

[Sysosmaster]

Het probleem is dat je niet meer kan weten wat het script heeft gedaan. Er is al malware delivery agents die andere data geven als je het via een pipe opent dan als je het via een direct retrieval opent. (Deze gebruiken subtiele quirks van curl om dat te detecteren).

Ook kun je bij direct execution geen audit of hash check doen.

Welke beide als “good security practice” worden gezien.

Het gaat dus niet over of een dmg of executable meer of minder veilig is. (Overigens kun je deze beide niet zomaar starten via een pipe).

[svane]

Bedankt voor de info! interessant. Ik begrijp het echter nog steeds niet volledig.

Als https://dangerzone.rocks/ een legitieme website is, dan lijkt het mij dat er geen gevaar is voor de aanval die je in je eerste alinea beschrijft.

Als de website malafide is..... wat is dan het verschil tussen de uitspraken:

1. Overigens vind ik het wel bijzonder dat bij de installatieinstructies voor Debian/Ubuntu je als eerste stap een bash script vanaf een URL direct een root shell in piped. Dit is een grote security no-no.
2. Overigens vind ik het wel bijzonder dat bij de installatieinstructies voor Debian/Ubuntu je als eerste stap een binary opent. Dit is een grote security no-no.

Ik zie echt niet wat het verschil is, al geloof ik best dat je gelijk hebt.....

- Hoe 'audit' je een binary? Dit lijkt me voor 99.9% van de bevolking niet haalbaar, en zelfs voor de 0.1% niet waterdicht.
- Wat voegt een hash-check toe, als de hash op dezelfde malafide website gehost wordt?

Mijn directe vraag is eigenlijk:

"Als https://dangerzone.rocks/ echt kwaad wil, maakt het dan uit of je hun bash script piped? of dat je hun binary runt? Het lijkt me beide even gevaarlijk eerlijk gezegd...."

[Sysosmaster]

Als https://dangerzone.rocks/ een legitieme website is, dan lijkt het mij dat er geen gevaar is voor de aanval die je in je eerste alinea beschrijft.

Ook in legitieme bron kan gekaapt worden. (en dit is ook al wel eens gedaan)

verigens vind ik het wel bijzonder dat bij de installatieinstructies voor Debian/Ubuntu je als eerste stap een binary opent. Dit is een grote security no-no.

Normaliter gebruik je een signed .deb (via apt / PPA) om installatie te doen op een Ubuntu / Debian systeem.

je verificatie doe je dan op 'persoons' niveau (Signer), welke niet aan te passen is door simpel de hash waardes op de website aan te passen.

Verder kan een virus scanner een niet runnende executable beter inspecteren (voor known malware, voor heuristisch werkt het draaien van de code beter)

en een binary audit je op dezelfde manier als ieder andere file, met tools voor dat doel, Internet staat er vol mee....

[svane]

Wederom bedankt voor je uitleg. Weer wat geleerd.

Misschien dan weer interessant voor jou: Ik lees trouwens net dat PPA's ook weer niet de meest ideale methode is:

Packages in PPAs do not undergo the same process of validation as packages in the main repositories. PPAs are a low-security alternative to the main repositories, so the user will be installing software at their own risk.

https://ubuntuforums.org/archive/index.php/t-2464740.html

A malicious PPA maintainer or an intruder who hacked the PPA and now has it under his control could introduce a package that has the same name as a real package that exists elsewhere and give it an artificially high version number. Your OS would now see that manipulated package as "Update" and install that malicious package over the real package....

Als ik het goed begrijp geef je dan eigenlijk de controle over al je packages over aan de eigenaar van de PPA. Zeker iets om in het achterhoofd te houden!

Als de softwareontwikkelaar kwaadaardig is of gecompromitteerd is en de controle over zijn domeinnaam/github/ppa verloren heeft, dan vrees ik dat je als 'downloader van software' linksom of rechtsom de sjaak bent.

Dat gezegd hebben, kan 't nooit kwaad om voorzichtig te zijn. Dus in het geval van dangerzone zou je dan eerder deze instructies volgen (en dan wel overtypen, en niet kopiëren )

[Sysosmaster]

Nee, jij blijft controle houden over waar pakketten vandaan komen (wel is het verstandig om de GPG sleutels gescheiden te houden met de `Signed-by` flag).

het vereist wel dat je of, zelf configureerd wie prio heeft bij gelijke pakketten.
of dat je zelf bepaald bij installatie / update uit welke bron je installeert (aptitude maakt dit proces makkelijker)

De instructies van Package cloud zijn daarom ook valide.

en er is geen 'beste' oplossing. je blijft altijd met een trust probleem.

ik vertrouw ondertekende apps gewoon altijd meer dan niet `signed` apps.

dit is overigens niet anders dan op Windows of Mac Os X. beide hebben een gelijke vorm van security policy.

Als je PPA's gebruikt om software die al in de standaard repo's zit te installeren.. dan klopt de statement dat een PPA een `lower security` optie is... voor software niet in de repo. is dit niet waar.

[blinchik]

En daarenboven, is het ook niet zomaar een goed idee om een commando te copy-pasten, zie bv.

https://www.wizer-training.com/blog/copy-paste

[Argantonis]

> Te encrypten met een passphrase*

Waarom corrigeer je dat zo? Dat is al wat hij zegt, beveiligen met een passphrase betekent al dat de ssh key encrypted wordt met een sleutel die afgeleid wordt van de passphrase.

[skaars]

interessante tool, alleen de eerste PDF die ik erdoor heen haal, degradeert aanzienlijk in kwaliteit. Goede tool, maar als kwaliteit van PDF een eis is dan is deze app niet geschikt.

[Reactie gewijzigd door skaars op 22 juli 2024 19:10]

[jurroen]

Hmm, dat is wel een goede. Ik zal er eens induiken, een PR hiervoor maken is niet zo heel veel moeite.

[Freeaqingme]

vast. Maar je ssh-agent houdt die dan weer in unencrypted vorm vast. De echte oplossing is mijns inziens daarom 2Fa te gebruiken; bijvoorbeeld ed25519-sk, waarbij je een webauthn device nodig hebt om nieuwe sessies te signen.

[FireDrunk]

Alleen kan je niet zomaar de private key uit een agent halen. Daar moet je op een speciale manier mee praten.

[Palm_freemium]

Op het moment dat je de key in ssh-agent inlaad is deze uit te lezen dmv een socket onder /tmp/. Even kijkend naar mijn eigen laptop, dan is ssh-agent eigenlijk altijd actief en zijn mijn keys altijd ingeladen.

En als je agent forwarding hebt aanstaan en je logt in op een server, dan word daar hetzelfde socket aangemaakt in /tmp Ik geloof dat de rechten worden beperkt tot de gebruiker waarmee je inlotg).

[rbr320]

Het is niet mogelijk om een ssh private key te bemachtigen uit een draaiende ssh-agent, behalve door een geheugendump te maken en daar heb je onder Linux root rechten voor nodig. Daarom wordt het afgeraden om je ssh-agent te forwarden naar machines waarvan je niet zelf de beheerder bent of de beheerder niet vertrouwd, maar de ssh-agent op je eigen machine is prima veilig ten aanzien van de andere gebruikers op het systeem.

[Palm_freemium]

> ... maar de ssh-agent op je eigen machine is prima veilig ten aanzien van de andere gebruikers op het systeem.

Dus als je een stuk malware start onder dezelfde gebruiker kan deze zonder problemen je ssh-agent uitlezen

[rbr320]

Dat hangt er vanaf wat je bedoelt met "uitlezen" in deze context. Processen die onder dezelfde gebruiker draaien, of dat nu malware is of gewoon een shell, kunnen inderdaad gebruik maken van de keys in de ssh-agent van die gebruiker om in te loggen op een remote server. Ook kunnen ze de ssh-agent aanspreken om van alle identiteiten in de agent de fingerprint op te vragen of zelfs de public key. Maar het is niet mogelijk om op deze manier de private key te achterhalen, wat ik in eerste instantie dacht dat je bedoelde. Om dat te doen moet je een geheugendump maken waar je root rechten voor nodig hebt.

[Reactie gewijzigd door rbr320 op 22 juli 2024 19:10]

[Gamebuster]

kan je niet gewoon een binary genaamd `apt` toevoegen ergens in je home directory, die map toevoegen aan je `PATH` en dan wachten tot het slachtoffer `sudo apt ...` intypt?

[mekkieboek]

Als ik me niet vergis, krijgt een shell van sudo een vers PATH mee, of van het systeem of van een target user. En dan wordt die apt niet zomaar gevonden. Tenzij :.: in het systempad staat want dat is zo handig

[Olaf van der Spek]

Dan vervang je sudo zelf in plaats van apt..

[mekkieboek]

Maar die heeft een s bit nodig om van effective user te kunnen veranderen:

ls -l `which sudo`
-rwsr-xr-x 1 root root 248464 mrt 7 22:27 /usr/bin/sudo

En om het s bit te zetten heb je eerst superuser rechten nodig.

Ik denk dat de beveiliging van UNIX/Linux goed is dichtgetimmerd is ontworpen.
Tegelijk zijn hackers soms griezelig inventief.
En doen eindgebruikers (waaronder ikzelf) soms domme dingen

[Reactie gewijzigd door mekkieboek op 22 juli 2024 19:10]

[Olaf van der Spek]

Maar die heeft een s bit nodig om van effective user te kunnen veranderen:

De fake sudo vraagt de gebruiker om zijn wachtwoord, game over..

[Gamebuster]

Dit werkt inderdaad.

chmod +x sudo
which sudo
# /home/XXX/Projects/gittools/bin/sudo
cat sudo
# #!/usr/bin/env bash
# echo "Please enter your password, i'm totally really sudo"
sudo
# Please enter your password, i'm totally really sudo

[Reactie gewijzigd door Gamebuster op 22 juli 2024 19:10]

[linext]

Hoe kun je je het beste tegen deze fake apt en sudo beschermen?
Elke keer dat je een terminal opent: 'which sudo' uitvoeren?

Ik heb wel eens pdfs en andere documenten vanuit een zip geopend. Nooit zo bij stil gestaan dat dit executables konden zijn..

[Olaf van der Spek]

Hoe kun je je het beste tegen deze fake apt en sudo beschermen?

Het beste is natuurlijk om te zorgen dat de malware überhaupt niet uitgevoerd wordt. Als malware wel draait, ben je afhankelijk van anti virus software.

[PageFault]

Maar veel mensen hebben geen anti virus software op Linux (of macOS), omdat ze zich veilig wanten "want het is geen Windows". Ook hier zie je dat het uiteindelijk een gebruikershandeling is die dan tot trammalant leidt, maar dat dat lastig is te voorkomen.

[fastedje]

Altijd absolute paths gebruiken:
/usr/bin/sudo, of inderdaad which sudo, dan weet je ook meteen of je PATH variable gehacked is.

Ik zie ook wel eens dat mensen de directory '.' toevoegen aan de PATH variable, dit lijkt mij om dezelfde reden een slecht idee.

[Gamebuster]

Ik verzin ook maar dingen o.b.v. de comments hier; zeker dat ik hier niet eerder aan heb gedacht, hah. Ik zou niet weten hoe je jezelf kan beschermen tegen dit soort zaken behalve geen bestanden van buitenaf openen zonder ze eerst te checken.

Maar ja, succes daarmee: check jij ook al je dependencies die je grootschalig van github, npm, whatever haalt? Alle dependencies die je uitcheckt hebben vaak een vorm van uitvoerrechten, dus als er 1tje is met malware hang je al.

[Reactie gewijzigd door Gamebuster op 22 juli 2024 19:10]

[MrWillow]

Goed punt.
Dat is precies waarom ik (als oude developer) hoofdschuddend kijk naar de moderne Javascript werkwijze.
Met een paar 'handige' npm commando's is de hele softwarestack weer up-to-date!
Als je vraagt wat er allemaal is aangepast, hebben ze natuurlijk geen idee.

Zolang het allemaal clientside code betreft (browser), dan zal de schade wel meevallen (tenzij je nog IE gebruikt), maar nodejs is ook waanzinnig populair, en daar zie je dezelfde mentaliteit bij veel developers.

Begrijp me niet verkeerd, ik ben gek op de open mentaliteit en hergebruik van (goede) code, maar er hoeft maar 1 rotte appel in het mandje te zitten.
Nu ik dit schrijf vraag ik me meteen af of ikzelf eigenlijk wel weet wat er allemaal binnenkomt als ik sudo apt upgrade intik....
Eerlijk gezegd niet.
Zijn we niet te goed van vertrouwen geworden met zijn allen?

[Gamebuster]

Zolang het allemaal clientside code betreft (browser), dan zal de schade wel meevallen (tenzij je nog IE gebruikt)

Je kan in je client-side package gewoon een `postinstall`-script meegeven die vrolijk code uitvoert op de machine van de developer

Nu ik dit schrijf vraag ik me meteen af of ikzelf eigenlijk wel weet wat er allemaal binnenkomt als ik sudo apt upgrade intik....
Eerlijk gezegd niet.
Zijn we niet te goed van vertrouwen geworden met zijn allen?

Waarschijnlijk ja. Vooral NPM / JS ecosysteem is gevaarlijk omdat de updates heel frequent zijn en het gaat om 1000en dependencies. Die kan je onmogelijk allemaal volgen.

[Reactie gewijzigd door Gamebuster op 22 juli 2024 19:10]

[nout77]

Mogelijke bescherming kan zijn het gebruik van een sandbox zoals firejail. Staat op GitHub en is op bekende distro's ook direct beschikbaar.
Je kunt internet blokkeren binnen de sandbox, beperkte rechten tot directory structuren of helemaal geen lees/schrijf toegang, behalve binnen een fake home folder.

Daarbinnen uitpakken en openen zou veilig moeten zijn voor dit soort malware en hack pogingen.

[FireDrunk]

Je zou je bash profile (waarin je path zit) alleen beschrijfbaar kunnen maken voor root. Dan moet je hem zelf met sudo wijzigen.

[mekkieboek]

Maar je moet ook ownership vd zelfgemaakte sudo naar superuser/root wijzigen.
Anders krijg je als effective user alleen de rechten die al had en geen nieuwe rechten.

En chown root mag alleen als root, met of zonder s of x bit.
$ chown root ./sudo
chown: changing ownership of './sudo': Operation not permitted

[Gamebuster]

Maar je moet ook ownership vd zelfgemaakte sudo naar superuser/root wijzigen.

Je vraagt om sudo password via de fake sudo, vult dit in bij echte sudo.

[hcQd]

Dat gezegd hebbende, ik zie dat op mijn systeem bijvoorbeeld device /dev/nvidia0 ook wagenwijd open staat voor schrijven (crw-rw-rw-)

Zit dat niet nog een acl op (crw-rw-rw-+)?

[mekkieboek]

Als ik het goed lees, zet de nvidia module de permissies zelf open, tenzij geconfigureerd in /etc/modprobe.d/nvidia.conf.
Er zit wel meer scheef op mijn systeem, zo gegroeid door de jaren. Rolling distributie corrigeert / signaleert niet alles. Ik zal binnenkort een verse distro install doen, met sane settings.

[MrHaas]

Ik ken ook genoeg developers die zichzelf aan de docker usergroup toevoegen, wat resulteert dat die user alles als root kan doen.

[karma4]

Erg handig al die rechten die via dat beperkte accont naar vele anderen inclusief sudo root open staan.
Handig voor jouw en voor de hacker

[d3burt]

Zodra de boefjes voor elkaar hebben dat je op de PC van het slachtoffer commando's kunt uitvoeren kunnen ze op hun gemak een gaatje zoeken om root te worden. Maar root worden op jouw PC is niet het doel. Ze hopen op jouw VPN mee te kunnen liften om het netwerk van je baas binnen te kunnen dringen. Daarom zijn IT'ers zo'n belangrijk doelwit voor groepen als Lazarus.

[The Zep Man]

Interessant. Maar hoe zou deze starten met een dubbelklik? Gedownloade bestanden krijgen geen executable permission bit (in ieder geval niet met Firefox). Daardoor zou ik verwachten dat het bestand simpelweg niet gestart zou worden als executable.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 19:10]

[Larry4]

Volgens mij is het een zip bestand waarin de executable bit gezet is, als die wordt uitgepakt dan is die bit dus aanwezig.

[The Zep Man]

Volgens mij is het een zip bestand waarin de executable bit gezet is, als die wordt uitgepakt dan is die bit dus aanwezig.

Ah, dat verklaart het. Het is dus niet direct een 'PDF' uitvoeren, maar eerst openen vanuit een ZIP. Dat is al automatisch een nope voor mij.

[batjes]

In het bedrijfsleven is dat helaas heel normaal en vaak zelfs de norm omdat je er makkelijk een wachtwoord op kan zetten.

[kuurtjes]

Waarom zou je in hemelsnaam een wachtwoord op een archief zetten? Wat is de kans dat het wachtwoord gewoon mee in de mail gaat?

Wachtwoorden worden door malware juist gebruikt omdat het dan niet gescant kan worden door een antivirus tot als het uitgepakt wordt met het juiste wachtwoord.

[jcbvm]

Vaak wordt het wachtwoord dan via sms gestuurd

[The Zep Man]

In het bedrijfsleven is dat helaas heel normaal en vaak zelfs de norm omdat je er makkelijk een wachtwoord op kan zetten.

Waarom zou je een wachtwoord op een vacature zetten? En zelfs al zou het nodig zijn om een wachtwoord te configureren, dan zou je de ingebouwde ondersteuning van wachtwoorden voor PDF's kunnen gebruiken. ZIP heeft geen toegevoegde waarde.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 19:10]

[Gamebuster]

dat moet je ook maar weten, ik zou daar niet bij nadenken hoor

[theduke1989]

Klopt, als ik job offers voorbij zie komen als in pdf formaat Verwijder ik ze meteen.

Daarnaast lees ik het altijd direct op de site. Als dat er niet is verdoe ik geen moeite en zoek een andere offer.

Is toch belachelijk dat je een job offer via zip file moet openen. Maar een ITer moet dit toch veel eerder onderschatten dan een non ITer?

[ro1]

Er zijn verschillende manieren. Xframe's Cross-site scripting etc....

[cricque]

En dan nog dan is het alleen het user profiel. Vind het wel interessant, want als je iets uitvoert (althans hier op mijn mint) dan krijg ik een waarschuwing, en niet allen dat, maar dan heeft het nog geen root rechten. Dus veel kan het niet infecteren.
Nu je kan altijd een monitor maken (of zetten) op je .bashrc of .bash_profile om je te waarschuwen als er iets wijzigt.

Nuja langs de andere kant, van iemand die ik niet ken, linux of niet, open ik geen bestanden. Ook geen job offers. Dan ga je mij toch eerst aan de telefoon moeten krijgen voor ik het ook maar zou bekijken. Ok met bijna 25 jaar ervaring is dat een luxeprobleem. Maar zeer interessant dat ze zicht specifiek op linux richten. Ok de kans is groter dat je iemand treft met een linux os, maar dan nog dat is toch nog altijd echt de grote minderheid

[Anoniem: 718943]

Mjah, met toegang tot de bash_profile kun je sowieso wel iets kwijt in je PATH wat sudo wrapt. Dus het hoeft niet gelijk iets te doen, maar na de eerste de beste keer dat je iets via sudo uitvoert kan het als root zijn gang gaan.
Dus waan je niet gelijk veilig omdat je niet standaard root rechten heb.

[Nowhereman]

Iets met klok en klepel?
Zodra sudo wordt aangeroepen moet je jouw wachtwoord opgeven, instand red flag.

[Anoniem: 718943]

Niks klok en klepel.

Als ik een executable scriptje (chmod +x ~/tmp/sudo) maak met de naam '~/tmp/sudo' en de inhoud:

#!/bin/sh
/usr/bin/sudo /bin/sh -c "echo Hallo $(whoami) ; $@"

En ik plaats deze op een locatie waar ik schrijf rechten toe heb, en zorg dat deze aan het begin van mijn PATH komt.

export PATH=~/tmp:$PATH

Vanaf dat moment, elke keer als je iets met "sudo" uitvoert dan zal dit script de daadwerkelijke sudo aanroep prefixen met extra payload, in dit geval "Hello $(whoami)" en dat uitvoeren als root.

Test maar uit. (Voor een default install, en dat is de meerderheid, werkt dit.)

[Reactie gewijzigd door Anoniem: 718943 op 22 juli 2024 19:10]

[dragoon2000]

Dit klopt. En ik zie zelf zo even niet niet dat dit in een 'non-default' install anders zal kunnen.
Ik denk dat je het zo moet zien; alle commando's die je op de CLI handmatig kunt invoeren kun je tevens opnemen in een script. Andersom kun je een script desgewenst regel voor regel overtikken op de command line.

Alle commando's die je kunt gebruiken als gebruiker (zie: 'compgen -c' als Bash je shell is) kun je dus opnemen in een script, ook sudo. Als sudo aldus is opgenomen in een of ander fopscript en jij bent opgenomen in /etc/sudoers dan kun je in beginsel inderdaad gefopt worden door een wrapper script dat sudo aanroept en vervolgens vooraf aanvullende instructies uitvoert nadat jij je wachtwoord hebt ingegeven.

Dat wrapper script kan overal worden verborgen onder /home/<gebruikersnaam> en/of andere plekken waar je +x rechten hebt en er kan naar worden verwezen in een shell alias (weliswaar officieel 'obsolete' volgens de Bash manpage maar nog altijd veel gebruikt) of shellfunctie in bijvoorbeeld .bashrc


Hoe dan ook, er is wel een heel eenvoudige oplossing voor lijkt mij, en dat is gewoon het volledige pad gebruiken van sudo bij aanroep, dus $ /usr/bin/sudo <commando> in plaats van $ sudo <commando>.

'which sudo' zal dan wellicht tonen dat er eerst wordt verwezen naar het verborgen script uit de shellfunctie of het alias in .bashrc (bijv: '~/.local/bin/sudo.sh'), maar '/usr/bin/sudo' blijft altijd de echte sudo binary.

[kimborntobewild]

Hoe dan ook, er is wel een heel eenvoudige oplossing voor lijkt mij, en dat is gewoon het volledige pad gebruiken van sudo bij aanroep, dus $ /usr/bin/sudo <commando> in plaats van $ sudo <commando>.

Dat lijkt mij allesbehalve een eenvoudige oplossing: je moet immers elke keer een hoop extra karakters intypen. En wie doet dat in de praktijk? Zo goed als niemand.
Een betere oplossing lijkt het me dat je (per default vanuit de distributies) een sudo nodig hebt om PATH te kunnen aanpassen.

[dragoon2000]

Het probleem zit hem niet in het aanpassen van de PATH variabele. PATH is bovendien niets anders dan een 'duizend-in-een-dozijn'-omgevingsvariabele: met andere woorden, elke gebruiker kan voor zijn account PATH instellen voor directories waar hij/zij rechten voor heeft.

Alle XDG Base Directory Specification mappen, zoals ~/.local/bin/ zullen normaliter standaard deel uit maken van $PATH (dit is overigens de directory waar je als gebruiker je zelfgeschreven scripts op hoort te slaan zodat je een netjes 'XDG-conform' geordende home directory behoudt.). Hoe veel gebruikers kijken er nou in de praktijk in een verborgen script directory als ~/.local/bin? Daar kun je een dergelijk script ook makkelijk verbergen.

Voorts zijn er wel andere manieren om een non-privileged gebruiker ongemerkt dingen te laten draaien, zoals bijvoorbeeld door het aanpassen van ~/.bash_profile, ~/.bashrc (als Bash je shell is tenminste, wat bij de meeste distributies wel de standaard is, maarr je kunt het zekerheidshalve als malware ontwikkelaar voor elke shell rc-file doen).

Dit gebeurt overigens ook in de praktijk en dat is wat deze malware doet: verbergen in ~/.config/guid/ (een XDG spec directory) en uitvoeren via ~/.bash_profile.

[Reactie gewijzigd door dragoon2000 op 22 juli 2024 19:10]

[nout77]

Na invoer van sudo is op de meeste distro's het zo ingesteld dat je bij de volgende sudo opdrachten gedurende 5 minuten niet opnieuw om het sudo wachtwoord wordt gevraagd. 5 minuten window of opportunity voor dit script, daar kan een hoop in gebeuren op de achtergrond..

Edit: Dit is natuurlijk speculatief maar mogelijk dat dit kan met sudo wrapping?

[Reactie gewijzigd door nout77 op 22 juli 2024 19:10]

[RobjeDopje]

Dat is volgensmij alleen zo in de huidige sessie, niet globaal.

[Gamebuster]

Je snapt zijn comment niet:

De malware kan met reguliere user-rechten bepaalde commandos aanpassen door PATH te wijzigen, bijv. een malware binary genaamd `apt` toevoegen in je PATH.

Vervolgens wil jij updates installeren en voer je `sudo apt update` uit, en bam: malware met root rechten Bonuspunten als de malware stiekem zijn gang gaat en alsnog apt uitvoert in de voorgrond, zodat je het niet eens doorhebt.

Edit: iemand gaf aan dat sudo een eigen path heeft, dus je moet even je eigen sudo alternatief in de PATH van de user aanmaken die vraagt naar password van user. Zie Gamebuster in 'Lazarus-hackers richten zich op IT'ers met Linux-malware verhuld als vacature'

[Reactie gewijzigd door Gamebuster op 22 juli 2024 19:10]

[Nowhereman]

Nee, dat werkt zo dus niet. Sudo gebruikt de secure_path variabele uit de /etc/sudoers file. Die file is enkel door root aan te passen. Dus jouw 'workaround' gaat niet op.

Daarenboven dient /home sowieso met de noexec optie gemount te zijn. Daar komt bij dat het bestand standaard geen executable rechten heeft dus hoe ga je dat überhaupt uitvoeren? En als op de 1 of andere manier de executable bit wel is gezet dan zet je daar als Linux gebruiker vraagtekens bij, want hoezo heeft een non-binary bestand execute rechten... Die vlieger gaat zeker op bij een bestand dat je ontvangt van iemand die je niet kent.

[Reactie gewijzigd door Nowhereman op 22 juli 2024 19:10]

[Gamebuster]

De malware heeft execute rechten omdat de executable is uitgepakt (met +x) uit een zip. Die executable maakt een sudo-executable aan en voegt die to aan PATH van de huidige user.

De user doet sudo apt-get update o.i.d. en voert zijn wachtwoord in. De fake sudo stuurt dit door naar de echte sudo, voert origineel commando uit om niet op te vallen, en draait op de achtergrond andere shit.

[Mijzelf]

hoezo heeft een non-binary bestand execute rechten...

Nou, daar is wel iets voor te zeggen. De helft van de executables op mijn systeem zijn scripts. En de helft van de data files zijn binair.

[batjes]

Zelf gebruik ik nog lekker ouderwets root met eigen ww als ik eens packages moet installeren of een service config moet aanpassen. Als de login van je account lekt, staat sudo ook meteen open.

Net als dat je in Windows omgevingen ook gewoon met een aparte user en admin account werkt en niet vertrouwt op UAC.

[Reactie gewijzigd door batjes op 22 juli 2024 19:10]

[ninjazx9r98]

Dat kun je uitzetten en wordt (helaas) in de praktijk ook best veel gedaan.
Nowhereman ALL=(ALL) NOPASSWD:ALL
Of
%sudo ALL=(ALL:ALL) NOPASSWD:ALL

[ejabberd]

Maar zeer interessant dat ze zicht specifiek op linux richten. Ok de kans is groter dat je iemand treft met een linux os, maar dan nog dat is toch nog altijd echt de grote minderheid

Gezien de aard van de aanval lijkt me dat niet zo verwonderlijk. Waarschijnlijk doen ze zich voor als headhunters die eerst via LinkedIn op zoek gaan naar geschikte slachtoffers en die dan benaderen tijdens de werkuren met een droomjob waar snel op gereageerd moet worden.

Als ze via LinkedIn bijvoorbeeld iemand vinden die bij IBM softwareontwikkeling doet op de afdeling Red Hat...de kans is dan wel zeer groot dat die Linux gebruikt.

[Olaf van der Spek]

En dan nog dan is het alleen het user profiel.

Wat is daar "dan nog" aan?
De malware heeft toegang tot al je gegevens, maar kan geen drivers / software updaten..?

[The Zep Man]

Er zijn verschillende manieren. Xframe's Cross-site scripting etc....

We spreken over een 'file manager'. De implicatie is dat een bestand gedownload en uitgevoerd wordt. Een browser zou niets kunnen met het bestand, behalve het te downloaden (omdat het een binary executable betreft).

[Anoniem: 718943]

Maar ja, als je in linux een bestand download, dan heeft dit bestand standaard geen executable bit gezet. Het filetype of extensie bepaalt niet of een bestand uitvoerbaar is, dat bepaalt het filesystem.

Wat ik wel begrijp uit het bleepingcomputer artikel, is dat het bestand intieel aangeboden wordt in een zip archief, en daar kunnen, volgens mij, ook permissies in opgeslagen worden, dus het kan best zijn dat er een bestand in zit met execute permissies.

Tenslotte is het bestand zo opgezet dat de punt geen echte punt is, dus de extensie onderdeel van de naam. Het is dus een bestand zonder extensie. Een bestand zonder extensie zal dan waarschijnlijk volgens de hashbang in het bestand uitgevoerd worden.

[Guru Evi]

In de meeste distro's staat /home toch op noexec.

Aparte partitie voor /home via LVM is standaard op Ubuntu en RHEL. Lazarus heeft ook een executable voor Mac, maar het doet "by default" ook niets, je moet echt al WILLEN de malware draaien.

[Reactie gewijzigd door Guru Evi op 22 juli 2024 19:10]

[rbr320]

In de meeste distro's staat /home toch op noexec.

Zeker niet, in ieder geval weet ik zeker dat het op Red Hat niet zo is en op Ubuntu en Debian ook niet, dus ik ga er vanuit dat dit op verwante distro's (Fedora, Alma, Rocky, Mint, Elementary om er maar een paar te noemen) ook niet het geval is. De reden daarvoor is dat een ~/bin of ~/.local/bin directory waardeloos is als de home partitie is gemount met "noexec", maar het gebruik van deze directories voor persoonlijke software of scripts is behoorlijk gemeengoed.

edit: andere bewoording, aangezien Fedora inderdaad geen afgeleide is van Red Hat maar andersom, bedankt voor de correctie @devices

[Reactie gewijzigd door rbr320 op 22 juli 2024 19:10]

[devices]

Red Hat is een afgeleide van Fedora en niet andersom, maar ik snap wat je bedoelt.

[Anoniem: 718943]

Mint, Kali en Arch hebben ook gewoon een exec /home. Net geverifieerd.

[Guru Evi]

RHEL (de betaalde versie) heeft “security profiles”, waar je admin kan kiezen voor oa CIS, STIG en een hoop andere beveiligingsmaatregelen. Ik dacht dat Ubuntu dit ook “uit de doos” deed, maar het is inderdaad een gelijkaardig security profile bij Ubuntu Pro die dit regelt.

Bij de meeste beveiligingsmaatregelen is noexec op oa tmp en home een minimum, in Fedora had je (vroeger toch) een standaard SELinux regel waar je exec binnen home moest expliciet toelaten.

Binaries van/voor “gebruikers” horen in /usr/local/bin nog nooit ~/bin gezien als een “standaard”

[Reactie gewijzigd door Guru Evi op 22 juli 2024 19:10]

[rbr320]

Binaries van/voor “gebruikers” horen in /usr/local/bin nog nooit ~/bin gezien als een “standaard”

Ik werk toch alweer 15 met Linux en daarvoor met Solaris en heb altijd een bin directory gehad in mijn home directory om persoonlijke scripts in op te slaan en uit te voeren. Gewone gebruikers hebben helemaal geen schrijfrechten tot /usr/local/bin dus beweren dat ze daar hun eigen scripts en binaries moeten plaatsen lijkt me onzin.

Ik gebruik Fedora niet dus daar kan ik niets over zeggen, maar ik weet zeker dat Red Hat niet standaard het uitvoeren van scripts en binaries vanuit de home directory tegen houdt door middel van SELinux. Dat zou namelijk om te beginnen al meteen het inrichten van een nieuwe host door middel van Ansible verhinderen, aangezien dit zijn Python code vanuit de home directory uitvoert. Daarnaast worden heel veel gebruikers er niet blij van.

[Reactie gewijzigd door rbr320 op 22 juli 2024 19:10]

[orvintax]

Wat ik wel begrijp uit het bleepingcomputer artikel, is dat het bestand intieel aangeboden wordt in een zip archief, en daar kunnen, volgens mij, ook permissies in opgeslagen worden, dus het kan best zijn dat er een bestand in zit met execute permissies.

Maar die permissies worden toch niet behouden? Als ik scripts of executables download moet ik hem altijd eerst marken met een "chmod +x foo.bar".

[Anoniem: 718943]

De permissies in het zip bestand blijven bewaard zoals ze erin gestopt zijn (net geverifieerd), immers kan de zip best een backup van een dir zijn, en daarvan wil je dat bij het terugzetten alles was zoals je het erin had gestopt.

Dus executable erin is executable eruit.

[s0ulmaster]

Als je een bestand unzipt dan blijven de permissies volgens mij wel behouden. Een "executable" downloaden herft idd geen +x rechten.

[cricque]

Correct een bestand in een "package" zal zijn bits/flags behouden, dus als iets executeable was, dan zal dit ook zo zijn na het uitpakken.

[rob12424]

Hmmmm vangt een IDS dit dan niet af?

Lijkt mij dat een programma niet alles zomaar kan doen met een goede IDS? Er zijn er zelfs die je erger kan instellen als UAC ooit was in het begin onder Windows....

[goarilla]

Sinds wanneer heeft een gedownload bestand ... ongeacht unicode/ASCII shenanigans uitvoerbare rechten ? Zijn dit de file managers die de rechten uit gebruiksgebak omzeilen met bv. "/lib64/ld-linux-****.so.* ./pdf-file" ?

[--Andre--]

Een ding begrijp ik niet echt.
Zelfs als de file manager het bestand als uitvoerbaar probeert op te starten, heeft dit bestand, geen +x rechten, dus dit zal falen.

[GekkePrutser]

Linux heeft sowieso niet zo veel op met extensies. Het gebruikt inspectie van de eerste paar bytes van een bestand om te kijken wat voor type het is. Dus als je op Linux zit, hou daar rekening mee. Je kan je executables gewoon .pdf noemen en ze draaien dan gewoon. Dan moet er wel een execute vlag op staan, die downloads niet zomaar krijgen, overigens. Maar ook als het om bijvoorbeeld plaatjes gaat: Je kan een .jpg gewoon renamen naar .txt en hij blijft gewoon een plaatje zijn.

Het is ook niet fout ofzo, het is gewoon een heel ander concept dan op windows, dat daar deels van CP/M en deels van VMS (met name het NT gedeelte) kwam. Op Linux zie je ook wel dat dit concept een beetje verwaterd, niet alle GUI software gaat hier goed mee om en sommigen kijken wel naar de extensie.

Een grotere vraag is: Hoe komt een gedownloade "PDF" opeens aan een execute vlag in het filesystem??

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 19:10]

[nout77]

Ik lees in eerdere reacties dat het bestand uit een zip komt waar de executable bit al op aan was gezet binnen deze zip directory (ik was me eerlijk gezegd ook niet bewust van dat dit mogelijk is).

Linux gaat inderdaad anders om met extensies maar wanneer je een extensie-loos bestand met executable rights dubbel klikt, wordt het gewoon uitgevoerd.

De .pdf extensie wordt gefaked met een speciaal Unicode karakter. Maar eigenlijk heeft het bestand geen extensie. Deze U+2024 zouden ze in bestandsnamen eigenlijk moeten verbieden als je het mij vraagt. Want wat zou nou een legitieme reden kunnen zijn om dit karakter er in te houden? Alleen voor misbruik zoals voor hackers is dit heel erg nuttig!

[GekkePrutser]

Linux gaat inderdaad anders om met extensies maar wanneer je een extensie-loos bestand met executable rights dubbel klikt, wordt het gewoon uitgevoerd.

Ja maar zelfs als er een extensie op zit, maakt deze niet uit. Het is meer cosmetisch. Een executable kan gewoon .pdf heten.

[nout77]

Ik doe het nu even uit mijn hoofd maar volgens mij wanneer er geen x bit actief is, is de extensie voor de meeste file managers (zoals Nautilus) wel doorslaggevend voor welk programma vervolgens gestart wordt.

[latka]

Zover ik weet ook. Het zou vele malen beter en veiliger zijn als gewoon de 'file' utility gebruikt wordt die met een database aan scans e.d. werkt om te bepalen wat iets is (met file-extensie als last-resort). Dat zou voor linux op de desktop een hoop mogelijk aanvalsvectoren schelen t.o.v. Windows.

[batjes]

?Of je nou dmv een extentie of de eerste paar bytes in een bestand een OS verteld wat het er mee moet doen... Maakt weinig uit en beide methodes geven hun eigen aanvalsvectoren. Het één is niet beter dan het ander.

[latka]

Tot op zekere hoogte klopt dat. Maar het helpt als je niet hoeft te vertrouwen op een stuk meta-data (de filenaam) om het juiste icoon te tonen. M.a.w.. de hele UI en visualisatie is gericht op gebruikers informeren (extensie, icon, actie) op basis van het bestandstype, maar als de allemaal losstaan van de content omdat alleen de file-extensie gebruikt wordt is foppen een stuk eenvoudiger. Vandaar mijn punt: file-extensies moeten dood.

[batjes]

Naar mijn idee zou een OS zich helemaal niet bezig hoeven houden met wat een bestand precies is, kan of doet. Enkel doorverwijzen naar de (default) applicatie. Die bepaald verder maar wat er met het bestand dient te gebeuren. Terwijl je met fileheaders (een deel van) de informatie laat bepalen door het OS.

Op Windows wordt meestal gewoon beide gebruikt, bijna alles heeft ook fileheaders die het programma vertellen wat het (zoal) moet doen met dat bestand. Maar die bepaald de software mooi zelf.

Geeft juist meer vrijheid aan ontwikkelaars.

Gevoelmatig is dat een mentaliteit die juist meer bij Linux past

[latka]

Als we het OS splitsen in Desktop en kernel dan klopt dat ook: de kernel kijkt naar x-bitjes en hashbangs en niet naar filenames. Dat wij daar naar kijken en blind op vertrouwen is precies het probleem. Zeker als de desktop tools dat ook doen. De kernel aanpassen om file extensies te gaan gebruiken zie ik niet gebeuren. De desktop aanpassen is een minder groot probleem (behalve de performance als een gebruiker weer 20.000 files in een directory heeft gezet die allemaal geopend moeten worden om het juiste icoontje te bepalen)

[HollowGamer]

Nee hoor, als ik een Bestand.txt heb aangemaakt met VSCode en ik verander dat erna in Nautilus naar Bestand.jpg, dan blijft hij dit openen met VSCode.

Linux kijkt niet zo naar de extensie, zelfde als bij MacOS.

[nout77]

Dat is toch wel uitzonderlijk vermoed ik.

Heb het zojuist ook maar even geprobeerd in Ubuntu. Een .txt bestand in Nautilus verandert naar .jpg en het wordt nu niet langer door gedit geopend maar door image viewer, die vervolgens een 'could not load..' error geeft.

[Magic Power]

Ik heb hier ook gereageerd, maar zoals ik het zag wordt (op de desktop) standaard naar extensie gekeken, en als die er niet is naar mimetype.

[GekkePrutser]

Die volgen dan niet de juiste procedure, want op de commandline is het wel zo dat alles via 'file' gaat zoals @latka noemt.

Op de desktop het ene en op de GUI de andere is natuurlijk niet bepaald handig of veilig.

[devices]

Vanuit GNOME werkt dat tenminste niet en ik neem aan dat je de pdf opent via de file manager i.p.v. de terminal.

[jurroen]

Dat is niet inherent aan GNOME of Nautilus. En had het hernoemde bestand waarmee je het getest hebt ook de executable bit? Dat laatste maakt een gigantisch verschil.

[devices]

Ja tuurlijk, anders had de test natuurlijk geen zin. Ik heb gewoon een executables extensie verandert naar .pdf. Ik gebruik Fedora, maar nam aan dat het aan GNOME/Nautilus lag.

[Reactie gewijzigd door devices op 22 juli 2024 19:10]

[latka]

zipfile. Helaas standaard worden de permissies meegenomen. Voor tar snap ik het (als in: dat is voor backups nodig). Welk helder zicht verzonnen heeft dat permissies meemoeten bij het uitpakken van een zip..

[GekkePrutser]

Aha slim.. Nu snap ik het. Dat is ook lastig aan te pakken inderdaad want de browser is de enige die weet dat het een gedownload bestand is, maar is niet de app die het uitpakken afhandelt.

Apple heeft hier een vlaggetje voor in de metadata van elk bestand, als je een bestand opent dat gedownload is geweest dan krijg je een waarschuwing. Wel een die zo vaak voorkomt dat mensen er gewend aan raken, maar het is een begin.

Maar dan nog snap ik het neppe puntteken in de ".pdf" niet helemaal. Dat was op Linux helemaal niet nodig geweest. Maak het executable en een binary gerenamed als ".pdf" (met een echte punt) zal gewoon draaien. Extensies hebben niet echt een betekenis in Unix/Linux, het is meer een suggestie.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 19:10]

[RoestVrijStaal]

Apple heeft hier een vlaggetje voor in de metadata van elk bestand, als je een bestand opent dat gedownload is geweest dan krijg je een waarschuwing. Wel een die zo vaak voorkomt dat mensen er gewend aan raken, maar het is een begin.

Op Windows bestaat er ook zoiets dat er erg veel op lijkt, namelijk de ZoneId alternative NTFS file stream.

[latka]

Ja, maar dat helpt niet bij een zipfile: de alternate datastream met dat vlaggetje zit op de zipfile. Dan moet de unzipper die ook meenemen bij het uitpakken. Geen idee of dat gebeurt.

[Magic Power]

Ik heb een tijd terug eens liggen zoeken naar hoe Linux omgaat met bestandsnaam extensies. Zover ik het kon zien, gebruikt Linux standaard bij een bestand met een extensie, het programma dat is gekoppeld aan die extensie. Pas als je een bestand zonder extensie dubbelklikt, bekijkt hij de header van het bestand om te bepalen wat de mimetype is van het bestand, om dan de app van het gekoppelde mimetype te gebruiken.

Of, kort gezegd: Bij een bestand met extensie telt de extensie, bij een bestand zonder extensie telt de mimetype.

[GekkePrutser]

In een GUI file manager misschien, maar zo hoort het niet. Ze lopen daar Windows na te bootsen.

[Anoniem: 58485]

Poh, mischien gewoon weer terug naar plain text ofzo. Scheelt in het aantal kwaadaardige bijlages, ransomware of backdoors die stukjes software ophalen.

[Accretion]

Het idee is dat je een executable de extensie .txt geeft en in een zip verpakt om hem de execute bit te behouden.

[goarilla]

Is die zip execute bit een ... poging van de linux zip tools om het executable DOS attribuut te emuleren of is er in zip een ware faciliteit voor unix rechten, owner/group/world zoals bij tar/gzip/bzip ... ?

Dat is dus 1 van de redenen dat ik altijd unzip -l of tar -tvf doe voor ik een tarball of zip explode en dan nog eerst liever in zijn eigen "explode" folder want er zijn gerust nog andere vieze dingen mogelijk: tarballs zonder containing folder of erger met absolute paden in de root (/etc/myconfig ipv ./etc/myconfig).

[MrMonkE]

Lekker.. gaat MrMonkE een keer over op Linux.. Komen de hackers

Poh, mischien gewoon weer terug naar plain text ofzo. Scheelt in het aantal kwaadaardige bijlages, ransomware of backdoors die stukjes software ophalen.

Ik mis het.
Ook geen mensen die 10 uur bezig zijn een mailtje aan het opmaken met grafische-headers.

[Anoniem: 392841]

Wordt het niet een keertje tijd dat downloadbare bestanden (ook als ze in een container verpakt zitten) geen .pdf/.doc/etc (eigenlijk alle bekendere bestandstypen) kunnen gebruiken in hun bestandsnaam om gebruikers te misleiden, tenzij de geimpliceerde extensie ook de file record matched?

Laatst (in Windows) ook al Linux Tech Tips welke te grazen werd genomen door een vermomd bestandstype, en zij zijn niet de enigen die in dat soort dingen trappen.

[linext]

Nog beter: wat mij betreft zou het beter zijn om in Linux (terminal, file manager, etc) de speciale Unicode U+2024 niet langer weer te geven als een gewone punt maar als een sterretje: *pdf (of dit unicode teken überhaupt niet weer te geven in de bestandsnaam).
Dan zijn daar geen misverstanden meer over!

Verder zou het fijn zijn wanneer de file manager net als de terminal een kleur geeft aan bestanden die uitvoerbaar zijn (x bit aan staat).

[Slurpgeit]

De extensie is technisch gezien niet .pdf:

Interestingly, the file extension is not .pdf. This is because the apparent dot character in the filename is a leader dot represented by the U+2024 Unicode character. The use of the leader dot in the filename was probably an attempt to trick the file manager into treating the file as an executable instead of a PDF.

[Anoniem: 58485]

Standaard staat in windows file explorer, aan dat "bekende bestandsextensies" worden verborgen. Dus jij ziet wellicht "Sollicitatie" met een PDF icoon terwijl de werkelijke extensie sollicitatie.pdf.exe is. Ik heb die meuk standaard uitstaan. Ik wil gewoon zien welke extensie er meekomt. Hoevaak executables verborgen als .scr werden meegestuurd etc.

Maar een mailserver met daarop een goede antivirus (clamAV) met een anti-spam controller (Rspamd) en gezond verstand brengt het al een heel eind.

[Slurpgeit]

Ik denk dat je de uitleg nog een keer moet lezen . Er staat geen punt in de bestandsnaam, alleen een Unicode karakter wat eruit ziet als een punt.

[novasurp]

Wat erg, ik dacht dat het permissiesysteem dit voorkwam, maar je hoeft je malware dus alleen maar in een ZIP te stoppen om dit te omzeilen. Op MacOS kan dit niet. Hij zegt standaard “Dit programma komt van een onbekende ontwikkelaar en kan niet worden geopend”, je moet dan rechtermuisklikken en aangeven dat je het écht wilt uitvoeren, en dan weet je dat het geen PDF is.

[Grimm]

Wat ik niet begrijp is hoe ze het voor elkaar krijgen om bij een gedownload bestand het execute bit te zetten.
Browsers enzo zetten nooit het execute bit wanneer een bestand binnengehaald wordt.
Zonder dat bit zal een Linux systeem nooit dat bestand uitvoeren.

edit: ok, ik snap het, ze gebruiken een zip bestand.

Wel, iedere Linux gebruiker die niet wantrouwig wordt wanneer een zip bestand gebruikt wordt
om een pdf bestand te versturen is volgens mij een <censuur> en ik zal er niet wakker van liggen.

[Reactie gewijzigd door Grimm op 22 juli 2024 19:10]

[Bitzer]

Als het niet anders kan open je het op een live Linux waar geen harde schijven of zo aan zijn verbonden. Einde sessie is einde malware toch?

[PredCaliber2]

Tot zover de 25 jarige pleidooien van die hard Linux gebruikers die tot vervelends toe van letterlijk iedereen elke dag als usp iedereen vertelde dat “Linux nooit virussen zou krijgen”

[Slaiter]

Dat pleidooi zal een die hard Linux gebruiker nooit gebruiken. Er zijn virussen voor ieder systeem, dus ook voor Linux. Alleen is het aantal voor Linux gewoon kleiner, dit is om de redenen kleinere gebruikerspool en het niet standaard met admin rechten inloggen.

[Reactie gewijzigd door Slaiter op 22 juli 2024 19:10]

[hackerhater]

Virussen (geen user-interactie vereist) zijn er nog steeds niet voor een moderne (up to date) Linux machine.
De verzamelnaam malware, waar een trojan horse zoals deze onder valt, dat zeker wel.

[Reactie gewijzigd door hackerhater op 22 juli 2024 19:10]

[nout77]

Volgens mij haal je wormen en virussen door elkaar. Een worm vereist geen interactie van de gebruiker, virussen wel.
Er zijn wel degelijk wormen en virussen voor Linux systemen: Heartbleed, Log4j, XorDDos en Mozi. Om maar een aantal recente te noemen.

[hackerhater]

Nee, jij maakt de fouten.
Een virus heeft geen user-interactie nodig (de welbekende drive-by), deze zijn dan compleet afhankelijk van software fouten. Een worm is inderdaad nog erger, die gaat zelf op zoek naar een slachtoffer (voorbeeld Blaster)

Een trojan horse moet de gebruiker zelf binnen halen en/of uitvoeren. Geen enkel OS is hier bestand tegen.
Heartbleed & Log4j waren geen malware, het waren (serieuze) software bugs. Dat er malware was gemaakt die o.a. van Log4j misbruik maakte, dat is een 2e.

XorDDos was een trojan, Mozi oké ik geef je die, al is het me niet duidelijk of dit nu een virus of een worm is. Het is wel een mooi voorbeeld waarom updates zo belangrijk zijn. IoT is een beveiligings-ramp.

De reden waarom Linux een stuk minder vatbaar is voor alle malware behalve trojan horses is dat er geen homogene opbouw is gecombineerd met dat bugs (doorsnee) snel opgelost worden.
Het is niet onmogelijk, zeker niet. Maar als like 95% gepatched is voor je uberhaupt je malware hebt kunnen schrijven is er nauwelijks een return of investment voor een algemene aanval.
En desktops en servers hebben doorsnee meerdere lagen van beveiliging, o.a. SE Linux die een aanval in de kiem kan smoren, zelfs als de 1e laag doorbroken wordt.
Dit vereist natuurlijk wel dat de beheerder geen idioot is die het uit zet.

Echter zie je dan direct ook dat wanneer patches niet geïnstalleerd worden of zelfs niet beschikbaar (Android & IoT) dat het direct een stuk slechter wordt.
Je ziet dan ook dat 99,9% van de aanvallen zich richten op of het brute-forcen van credentials of machines die niet bij zijn met de patches.

Dit alles gecombineerd zorgt ervoor dat je op Linux, mits je bij bent met de patches, je alleen iets te duchten hebt van trojan horses (zoals in dit artikel) op dit moment. Dit kan natuurlijk veranderen in de toekomst.

[Reactie gewijzigd door hackerhater op 22 juli 2024 19:10]

[nout77]

Mogelijk zit ik er naast met de definities maar deze link geeft wel een duidelijke uitleg:
https://www.avg.com/en/signal/computer-worm-vs-virus
Daar staat deze opsomming:
Virus:
- Requires a host
- Triggered by human interaction
- Often arrives through an infected file or program
- (file-infector)
Worm:
- Spreads independently
- Doesn’t require human interaction
- Often arrives through a software vulnerability

Een drive by download lijkt mij dus meer worm gedrag dan virus gedrag. Maar ik vermoed wel wat overlap in deze twee malware categorieën.

Wat betreft het ontdekken en patchen van gevonden kwetsbaarheden:
Je geeft aan dat Linux daar zo snel mee is (inclusief de gebruikers die hun systemen vervolgens updaten) dat een exploit er voor schrijven weinig winst oplevert. Maar is dat bij Windows de laatste jaren dan zoveel trager qua patching? Of zijn dan het aantal gebruikers die te laat patchen de doorslag om daar met een exploit wel winst uit te kunnen halen?
Toch denk ik dat een schatting van 95% van de Linux userbase die vrijwel direct update te optimistisch is ingeschat. Mogelijk dat dit bij cloud systemen wel het geval is (hoop ik). Maar niet op de workstations.

Nog even je quote waar ik op doelde:
"Je ziet dan ook dat 99,9% van de aanvallen zich richten op of het brute-forcen van credentials of machines die niet bij zijn met de patches." - maar dit geldt natuurlijk ook voor alle Windows malware.

HeartBleed en Log4j zijn snel gepatcht inderdaad maar het duurde jaren voordat deze kwetsbaarheid überhaupt ontdekt was.

Je hebt wel gelijk en ben het volledig eens dat Linux vanaf de grond beter ontworpen is met beveiliging als prioriteit. Daarom gebruik ik het ook graag. Ondanks dat er gelukkig weinig worms/virussen gemaakt worden voor Linux, zijn Trojan horses helaas alleen al reden genoeg om voorzichtig te blijven.

Maar toch nog een voorbeeld:
Ook docker containers die met poort 2375 benaderbaar zijn worden door XorDDos en Kaiji geïnfecteerd:
"This is one of the two ports of the Docker API and it’s used for unauthenticated and unencrypted communications."
https://www.securityweek....ts-target-docker-servers/

[hackerhater]

Human interaction is iets anders dan moet door een human uitgevoerd worden
Bij een drive-by moet je zelf nog de webpagina openen, de email openen, etc. Maar voor de rest gebeurd alles automatisch door software lekken.
Bijvoorbeeld in de tijd van de Flash advertenties: een webpagina openen met een besmette advertentie erop en poef raak. Nu gebeurd dit nog steeds veel via advertenties, maar dan via JavaScript.

Terwijl een worm zelfstandig andere machines gaat scannen, ze aanvallen, etc. 0 gebruikersinteractie.
Blaster was een mooi voorbeeld. Gewoon verbonden zijn met Windows XP op het internet zonder firewall (pre SP II) was genoeg. Binnen een uur was je het zakje ook als de machine compleet idle was.

Een trojan vereist dat je de waarschuwingen negeert, zelf het beheerders-wachtwoord op geeft.
In dit geval zelf de zip uitpakken, het openen en zeer waarschijnlijk de executie-waarschuwing negeren.
Dat is ook de reden waarom geen enkel OS er tegen bestand is. De gebruiker geeft de malware toestemming zijn werk te doen.

Microsoft is inderdaad een stuk trager met patchen dan BSD en Linux. En omdat Windows patches nogal de reputatie hebben om dingen kapot te maken stellen veel mensen/bedrijven het patchen ook nog dagen of weken uit. Of ze updaten uberhaupt niet.
Ik kan alleen voor mezelf praten, maar ik durf mijn Linux machines blind te updaten op dag 1. De boel blijft 99,999% van de gevallen gewoon werken zonder gedoe en (tenzij kernel update) zonder verplichte reboot.
Bij een oud werkgever had ik de debian print-servers op auto-patch gezet toen ik weg ging.
2,5 jaar later deden ze nog braaf hun ding, helemaal up to date. Terwijl niemand er heen gekeken had in 2,5 jaar.

En wat bij Windows ook niet helpt: Geen centrale updater voor alle software. Gecombineerd met de eeuwige backwards compatiblity waardoor ze ontwerpfouten niet echt op kunnen lossen.
Dan kan je OS wel up to date zijn, maar als bijvoorbeeld je browser dat niet is ga je alsnog nat. Bij Linux wordt (bijna) alle software bijgewerkt door de package-manager. Wat direct er ook voor zorgt dat je die software geen beheerders-rechten en/of toegang door de firewall hoeft te geven.

Betreffende die Docker aanvallen: Waarom hebben ze die poorten uberhaupt van buiten bereikbaar gemaakt? Default instelling is host-only.
Windows is default behoorlijk onveilig, maar kan (redelijk) veilig gemaakt worden door een competente admin.
Linux is default strikt en veilig ingesteld (met weinig spul draaiend), maar kan onveilig gemaakt worden door een incompetente admin (geen brute force beveiliging, docker poorten naar buiten toe, etc)
Wat zou de betere instelling zijn voor thuisgebruikers en klein-bedrijf?

[Reactie gewijzigd door hackerhater op 22 juli 2024 19:10]

[Frame164]

Maar het zijn toch alleen digibeten die Windows of Mac gebruiken die hier in trappen? Linux gebruikers zijn toch veel beter dan die mensen en houden hun systeem ook altijd perfect up to date en veilig.....