ESET ontdekt Linux-malware die via geïnfecteerde OpenSSH-client data steelt

Beveiligingsonderzoekers van ESET hebben een nieuwe malware gevonden die zich specifiek richt op Linux. Het gaat om gerichte malware die een achterdeur opent door inloggegevens te stelen via een geïnfecteerde OpenSSH-download.

Beveiligingsbedrijf ESET noemt de malware Kobalos. Die zou onder andere toeslaan op Linux-distro's, en op de besturingssystemen BSD en Solaris. Het bedrijf speculeert dat de malware mogelijk ook op Windows actief kan zijn, maar daar heeft het geen bewijs voor. Het bedrijf vond slachtoffers van de malware over de hele wereld. De getroffen systemen zijn supercomputers en servers in voornamelijk academische instellingen en onderzoeksinstituten, maar het is niet duidelijk waar de aanvallers naar op zoek waren.

De onderzoekers noemen de malware geavanceerd. Die zou veel opties hebben om zichzelf te verbergen op een systeem en om detectie te omzeilen. Er zouden meerdere manieren zijn om contact te leggen met de malware. Een van die manieren is om een tcp-poort te openen, waarbij er een versleutelde verbinding wordt gelegd. Daarvoor wordt lokaal een sleutel gegenereerd, wat volgens de ontdekkers opvallend is omdat de malware juist heel klein is.

Het is onduidelijk wat de malware precies probeert te bereiken. Als die eenmaal op een systeem staat wordt er een OpenSSH-client geïnstalleerd die de inloggegevens van gebruikers steelt, die de aanvallers vervolgens kunnen gebruiken om commando's op het systeem uit te voeren. Opvallend is dat de onderzoekers verwijzingen zagen naar oude code, die van toepassing was op Windows 95. Dat hoeft niet te betekenen dat de malware zo oud is; mogelijk zijn er her en der delen uit oudere malwares gebruikt.

Reacties (69)

Zo zie je dat veiligheid altijd een issue is. Geen enkel OS is heilig. Een Linux distributie of andere Unix like OS's zijn altijd vatbaar. Windows ook never te nimmer niet. Security blijft altijd een issue. Waan je vooral niet veilig omdat je denkt dat jou OS niet getroffen kan worden

Normaliter download je niet een losse openssh binary van een of andere shady website. Normaliter download linux netjes uit zn eigen package-repository (zeker dit soort executables), en worden die tegen gesigned door de distributeurs. Die signing key wordt dan weer gecheckt op de machine die de package gaat installeren, waarmee je met zekerheid zegt dat je de versie van jouw distributie hebt zonder omgevallen bits, en zonder aanpassingen door derden.

Kortom, ik gok op Human error als er een machine geinfecteerd is met deze backdoor, of natuurlijk installatie via een andere reeds bechikbare backdoor, of root-access op die machine.

Ik denk juist dat dat ook onderdeel is van het punt dat @Theo.H probeert te maken. Geen besturingssysteem is helemaal veilig omdat er mensen mee werken en het ook door mensen beheerd wordt. Waar mensen bezig zijn worden fouten gemaakt.

Dat gezegd hebbende, door zoveel mogelijk te automatiseren, regelmatig het 4-ogen principe toe te passen en gezond verstand te gebruiken kan je een hoop issues voorkomen.

Maar dat doet de malware toch voor je in dit geval? De gehackte openssh versie installeren dus.

Hoe je de malware echter binnenhengelt is mij onduidelijk..

[Reactie gewijzigd door jkommeren op 2 februari 2021 20:25]

Mijn gok is dat je de oorspronkelijke payload eerst zelf moet binnen halen en installeren.
Tegen trojans is geen enkel OS bestand.

Het eerste systeem wordt besmet door het installeren van de malware. Als de foute SSH-client daarna gebruikt wordt, jat ie de gebruikte inloggegevens en besmet de volgende server. Dit kan voorkomen worden door 2 factor authenticatie. Ik neem aan dat authenticatie met wachtwoord beveiligde certificaten ook afdoende is. Of zou ssh-agent ook gecompromitteerd zijn?

https://www.emerce.nl/wir...ie-supercomputers-aanvalt

Je zegt nu ook normaliter. Het is nu alweer +/- 15 jaar gelden dat Debian te maken had met een package manager die zijn eigen code had geïnjecteerd waarna hijzelf uit het hele Debian verhaal was gestapt. Dit was pas maanden later ontdekt.

Ik probeer hier de boel er niet onder uit te schoppen maar veiligheid blijft een natte droom. Je kan nooit waakzaam genoeg zijn!

Inderdaad zijn de pakketbronnen doorgaans veiliger en die gebruik ik dan ook het meest, maar je moet niet denken dat er daar niks mis kan gaan. Ik herinner me nog die backdoor in de Unreal IRC-server die een jaar lang onopgemerkt bleef en ook in de pakketbronnen van een paar distro's terecht was gekomen.

Vergeet je de Solarwinds hack niet.. je denkt je software van een veilige omgeving af te halen. Maar als die veilige omgeving dus niet zo veilig meer blijkt te zijn is het kwaad ook geschied..

Ik ben het daar absoluut mee eens, echter, om ESET werkend te krijgen op Linux, moet je SELinux uitschakelen. Wat de kans op dit soort infecties dus juist vergroot.
Ik ken de details van de infectie niet, maar als SELinux aan staat, mogen onbekende processen niet zomaar poorten openen. Echter, als je ESET gebruikt, mag dat dus weer wel omdat SELinux uit moet.
ESET is dus (in mijn ogen) niet geschikt voor Linux. Hiermee zeg ik niet dat je geen virusscanner op Linux moet hebben, alleen ESET niet.

SELinux support
SELinux is supported in the following distributions:

•Red Hat Enterprise Linux 6

•Red Hat Enterprise Linux 7

•Red Hat Enterprise Linux 8

•Centos 6

•Centos 7

•Centos 8


Installation of EFS SELinux module policy requires selinux-policy-devel package to be installed. To start the OS without ESET File Security for Linux SELinux module, use the eset_linux=0 kernel parameter during OS boot.

Bron: https://help.eset.com/efs...zoom_highlightsub=selinux

[Reactie gewijzigd door Slurpgeit op 3 februari 2021 10:02]

Ok, als dat zo is (wat ik wel geloof) dan is dat nog niet zo lang. En goed om te horen!
Ik ga meteen de item op onze backlog bijwerken

In de Ubuntu wereld heb je apparmor. ESET kan niet in AppArmor beveiligde applicaties kijken, maar doet het verder wel gewoon onder Ubuntu.

Ondanks alle bezwaren vind ik ESET nog wel de minst slechte Linux virusscanner.

SELinux is trouwens een beest om bruikbaar en zinvol te maken. Ik heb voor diverse tools SELinux ingeregeld voor klanten, maar het is eigenlijk alleen te doen voor servers met heel specifieke taken.

Heilig zeker niet, er zijn genoeg veiligheidsincidenten met Linux geweest. Wel is het zo dat Linux een buitengewoon goede staat van dienst op het gebied van beveiliging en dat het nog nooit iemand gelukt is om een virus te maken dat zich daadwerkelijk in het wild wist te verspreiden. Degene die beweert dat Linux absolute veiligheid biedt, kletst uit zijn nek. Degene die wijst op de hoge veiligheid van Linux, adviseert juist.

Die hoge veiligheid heeft nog wel een cultuur fix nodig. Ik kom nog regelmatig bedrijven tegen (ook de grote jongens) die VPS-en of NAS-en opleveren zonder werkzame beveiliging. Met standaard logins zoals root:toor of admin:root met alle sudo rechten en geen firewall. En in de NAS scene is het veel te makkelijk om zo'n handige repo van een of ander vaag persoon in je trust lijst te zetten, met het risico dat er ineens een system lib wordt gepatcht buiten de officiele repo om. Dan kun je nog zo'n mooi OS hebben met hoge veiligheidsmogelijkheden, maar als het openstaat voor de hele wereld schiet het niet op.

Ik snap het begin vh artikel niet: ze hebben het over aanval op specifieke Linux distros en noemen dan BSD en Solaris die geen Linux zijn. Bedoelen ze zoiets als verschillende linux distros maar ook non linus os zoals Unix varianten zoals BSD en Solaris?
Is jaren terug dat ik met FreeBSD werkte en nog lamger terug met Sun Solaris (toen ik bij een toko werkte die genoeg geld had om echte Sun workstations met Solaris te gebruiken)
Mis ik iets of is het artikel fout of incompleet?

Hackers zullen altijd geïnteresseerd zijn in een os dat populair in gebruik is. Zoals Windows maar nu ook Linux omdat het nu ook populair is.

Waar heb je het over. Dit heeft niets met Linux te maken, maar met OpenSSH. (Er is impact op Linux, dat is anders)

Plus daarbij, moet je echt zelf hebben zitten klooien met repositories etc om deze geïnfecteerde binary binnen te halen.

Dat is het zelfde als;
“Alle 3-dubbel glazen huizen zijn niet goed geïsoleerd”
Als je een raam 24/7 open hebt niet nee...

E: overigens staat er in het artikel:

Het bedrijf speculeert dat de malware mogelijk ook op Windows actief kan zijn

[Reactie gewijzigd door D0phoofd op 2 februari 2021 19:34]

BSD en Solaris zijn toch geen Linux distributies?

EDIT: Ah, ik vermoed dat er een komma mist: "Linux-distro's, BSD en Solaris".

[Reactie gewijzigd door Reddaks op 2 februari 2021 17:08]

De titel van het artikel heeft het alleen over Linux, maar inderdaad BSD en Solaris zijn geen Linux, en wat nog aparter is is dat Solaris gebaseerd is op Unix System V en niet op Berkeley Unix (zoals de oudere SunOS versies)...
Misschien komt er nog wel een update van het artikel om eea te verduidelijken...

Noem het dan POSIX?
Want al die systemen gebruiken die shell manier.

Posix is een (usa) standaard om de basis functionaliteit van een OS te waarborgen. Daarbij is het niet relevant welke tool daar een functie invult. Als het ssh protocol in de posix standaard ingevuld moet worden dan kan dat met Open SSH maar ook met elke andere ssh implementatie.

Voor de goede orde msWindows heeft ook heel lang haar best gedaan om aan de posix standaard te voldoen. Ik weet dat in ieder geval nt4 en nt5 (windows 2003) een add-on pakket had om aan de posix standaard te voldoen.

Daarmee moest ik hier aan denken: nieuws: Windows krijgt ondersteuning voor ssh

Ik kan me vergissen, maar ik denk niet dat POSIX iets zegt over SSH. Wel over system calls, minimale shell requirements en een paar basis tools, waar een SSH al zeker niet onder valt.

https://pubs.opengroup.org/onlinepubs/9699919799/nframe.html

Überhaupt schijnt deze malware code te hebben dat verwijst naar Windows 3.11 en 95 👀

The backdoor is multiplatform and capable of attacking Linux, BSD, Solaris, and possibly AIX and Windows machines, researchers said (they found strings related to Windows 3.11 and Windows 95, which are 25-year-old operating systems).

https://threatpost.com/ko...rcomputers-logins/163604/

Benieuwd of het dan MacOS ook nog raakt als BSD afgeleide....

Nope, andere UNIX afgeleiden

[Reactie gewijzigd door justinkb op 2 februari 2021 17:08]

Het zijn zelfs echte UNIX, geen afgeleide

Het is een directe afstammeling van Unix maar mag zich geen Unix noemen. Om Unix te mogen worden genoemd moet het Unix gecertificeerd worden. Gezien het nogal duur is om je besturingssysteem te laten Unix certificeren zijn ze dat niet, ze verwijzen daarom naar zichzelf als POSIX compliant.

Hier is een lijst van alles dat zich Unix mag noemen;
https://www.opengroup.org/openbrand/register/

Je hebt gelijk, de BSD's zijn inderdaad geen officiele Unix (meer).
Ik dacht dat Solaris dat wel was? Nou ja, sinds Sun door Oracle is overgenomen is het niet interessant meer.

Vreemd dat Apple steeds voor een UNIX certificaat gaat en dan de kernel 'X is Not UNIX' noemt.

Het gaat hier volgens de tekst over OpenSSH. Dat is een ssh implementatie die dus breder gebruikt wordt dan in Linux, BSD en Solaris.

Dat geeft mij dan weer de vraag: Waarschijnlijk niet in elke linux distributie. En niet op elke BSD (OpenBSD, NetBSD, MacOS...)

Hoe zit het met msWindows? Volgens dit (oude) bericht zou dat ook (open-) ssh krijgen: nieuws: Windows krijgt ondersteuning voor ssh.

[Reactie gewijzigd door beerse op 2 februari 2021 18:03]

Klopt er mist idd een komma ;

We reverse engineered this small, yet complex, malware that is portable to many operating systems including Linux, BSD, Solaris, and possibly AIX and Windows.

Ik stelde dezelfde vragen en was beetje verbaasd dat ik 0 reacties kreeg
Maar toen zag ik deze discussie die al mn vragen beantwoorde, dus er was geen reactie op mijn post nodig en dit staat verder 'naarboven' dus tegen de tijd dat mede tweakers mijn post zien zullen ze denken 'spuit 12 is traag vandaag'...
Maar wat een , kan uitmaken

Voor wat het waard is nadat je reactie downmodded is: je reactie is wellicht offtopic tov artikel maar niet echt tov de reactie(s) waarop je reageerde.
Mogelijk moet deze discussie elders gevoed worden -maar het is een relevante discussie; zeker in het huidige social media klimaat die vaak erg toxic is.
Gelukkig absoluut niet zo erg als op andere platfora; maar zelfs op tweakers zie ik steeds vaker een toxic mentaliteit: als je niet 100.000% achter iets/iemand/wat staat ben je dus 'anti' en moet je gemuilkorfd worden....
Niet gezond en we moeten ervoor waken en erover praten. Maar wellicht op een eigen lokatie, bijv via GoT??

Edit: zie dat je vooral 'omgewenst" score kreeg. Imho zouden dat hooguit 'off topic/niet relevant' moeten zijn en door het als 'ongewenst' te modden lijkt het een voorbeeld van de wij/zij toxic mentaliteit te zijn.
Gewoon downmodden en muilkorven ipv inhoudelijk reageren. Helaas kan ik geen contra score geven omdat het een reactie op mn eigen post is... ook al ben ik het niet volledig met je eens is de discussie imho wel degelijk relevant en belangrijk.

[Reactie gewijzigd door tonkie_67 op 4 februari 2021 21:16]

Het blijft altijd vaag of en zoja wanneer er een moment aanbreekt dat het nodig is een Linux antivirus/antimalware te installeren. Tot nu toe gebruik ik het niet maar soms twijfel ik wel.

Niets is niet te hacken/infecteren. Dus ook Linux of FreeBSD niet. Jaren geleden was er een Brit die het Pentagon had gehackt opzoek naar bewijs naar UFO's.

Je hebt eerder nood aan een zogenaamde rootkit detector: apt-get install chkrootkit rkhunter debsums. Dat laatste daar kan je je packaged files mee verifiëren t.o.v. wat er oorspronkelijk door de package werd afgeleverd. Volgens mij, tenzij men je apt database ook aanpaste, zou dat al voldoende moeten geweest zijn om dit te detecteren.

Ligt er ook aan of die het detecteert natuurlijk. Ik herinner me nog het gelazer met libkeyutils, dat was ook een worm die zich mede extreem snel kon verplaatsen dankzij geïnfecteerde systemen bij cPanel's support-team. Bij elke login op een server verspreidde het zich direct en nestelde zich in het OS.

... Het is dat toevallig een bekende beveiligingsonderzoeker het bestand tegenkwam op een klantserver, want voor de rest leek het weinig verdacht en werd dan ook niet gedetecteerd als bedreiging. Dan had je een antivirus scanner kunnen hebben, maar die had het waarschijnlijk niet tegengehouden.

Dat wil overigens NIET zeggen dat er geen nut is voor antivirus/malware oplossingen op Linux he, begrijp me niet verkeerd. Vooral een firewall is toch wel het minste dat je wilt inregelen. En iets is waarschijnlijk beter dan niets, maar de impact zal waarschijnlijk een stuk beperkter zijn. De afweging die de meeste mensen dan ook maken is het risico op infectie VS performance. Afhankelijk van je omgeving heb je die luxe niet, bepaalde productieservers bijvoorbeeld. Voor thuisgebruik kan ik het me ergens wel voorstellen dat je liever geen virusscanner hebt; of althans: niet real-time laat scannen. Toch zou ik het niet aanraden om helemaal niets aan beveiliging te hebben, want ransomware is een feit - en ook Linux-gebruikers worden daar steeds vaker mee aangevallen... Dus ALS je besluit om performance vs veiligheid te kiezen: zorg dan op z'n minst dat je een goede back-up hebt (niet benaderbaar door evt ransomware).

Het komt inderdaad vanzelf. Je ziet hier toch ook vaak genoeg langskomen dat er mensen zijn die zich veilig wanen omdat ze geen Windows of MacOS gebruiken, maar een open source OS. Als de andere OS-en dichtgetimmerd worden, of worden voorzien van detectiesystemen, dan wordt vanzelf een OS waarbij dat minder gebeurd het volgende doelwit.

Dat hangt er vooral van af wat je wilt voorkomen en welke tools je er voor gebruikt:
Gebruik je linux als mail server? Dan zou een mail-scanner wenselijk zijn.
Gebruik je linux als file-server? dan zou een file-scanner wenselijk zijn.
Gebruik je linux als router/gateway? dan zou een firewall wenselijk zijn.

Gebruik je linux als desktop? dan moet je geen server-services gaan draaien. Inkomende ssh (de ssh-deamon) hoef je dan niet te draaien. Scheelt een poort om te controleren.

Gebruik je linux als desktop? dan moet je geen server-services gaan draaien. Inkomende ssh (de ssh-deamon) hoef je dan niet te draaien. Scheelt een poort om te controleren.

De grote kracht van Linux zit hem er juist in dat je ook de desktop gewoon overal kunt benaderen. Met X-forwarding zelfs je grafische interface.

Dus nee, ook een Linux desktop zal vaker wel dan niet een SSH deamon hebben draaien zodat je niet overal waar je wilt werken die 12core Ryzen 9 nodig hebt maar gewoon lekker remote op je monster systeem kunt inloggen.

De grote kracht van ssh is dat je alleen maar ssh hoeft te draaien en daarna alle andere protocollen daar overheen kan draaien.

Dus elk ander protocol hoeft alleen maar aan localhost, 127.0.0.1 of ::1 te luisteren. Alleen ssh hoeft naar buiten open te staan. Dus ja: mijn eerdere opmerking hier boven is niet helemaal netjes.

De X11-forwarding, over de poorten 6000 t/m 6063, daar maakte ik in 1993 al misbruik van binnen een bedrijfsnetwerk. Routering via vnc over de poorten 5900 t/m 5963 is al iets beter beveiligd. Gebruik van de X11 faciliteiten binnen ssh of het tunnelen van het X11 protocol door ssh is een heel goede reden om ssh-service te draaien. Maar dan hoeft het X11 protocol dus alleen maar lokaal te werken.

Meh, fijne instelling. Mijn dev server moet wel services draaien wil ik iets kunnen testen. Kan best allemaal lokaal, maar toch niet heel handig als je elke dag op een andere lokatie bent en ook nog andere devs iets moeten testen, niet vol houden.

Is er ook bekend hoe je infected kan raken? Lijkt nergens genoemd te worden afgezien van "geïnfecteerde openssh download". Of is het idee echt dat mensen een random binary ergens vandaan downloaden en dan verbaasd zijn dat ze infected zijn?

Is het niet toevallig zo dat de high performance SSH networking patches misschien een security bug hebben ?

https://www.phoronix.com/...page=news_item&px=MTQ0OTQ

Want:

"supercomputers en servers in voornamelijk academische instellingen en onderzoeksinstituten"

Je client kan ook infected zijn, wat al veel eenvoudiger is voor een aanvaller. Maarja. Zoals ik eerder al opmerkte: er zijn veel opties voor een aanvaller wanneer de gebruiker met een gecompromiteerde machine een connectie maakt.

Zelfs met een geinfecteerde client: als jouw client alleen gebruikersrechten heeft kan je dit nog steeds niet doen.
Maar met sudo-rechten, laat staan root-login, ben je wel zuur ja als je client geinfecteerd is.

Dit gaat wel niet over een nieuwe heartbleed. Er moet eerst al ingebroken zijn waarna men de OpenSSH binaries aanpast.

Ik lees wel in het artikel dat het ook over de sshd gaat. Dus niet enkel d.m.v. de OpenSSH-client:

The method we’ve seen the most is where Kobalos is embedded in the OpenSSH server executable (sshd) and will trigger the backdoor code if the connection is coming from a specific TCP source port.

Leg mij dan eens uit hoe welke Linux dist. dan veilig genoemd kan worden? Ik ben nu zeg maar een package manager en compile een package. Zet daar mijn eigen aanpassingen in maar geef een hele andere source package daartegen over uit? Ik vind dit toch nogsteeds zorgwekkend

Als jij met een gecompromiteerde machine inlogged over SSH, dan heeft men veel opties om in te breken op de server waarop je inlogged. Zoals bv. de private key kopieeren, een keylogger gebruiken en zo verder.

Als jij een package manager hebt gebruikt om OpenSSH te installeren, dan werden de binaries gesigned door de uitgevers van de Linux distributie. Die signature kan je gebruiken om na te kijken of nadien je binaries niet aangepast werden (bv. met debsum kan dat op Ubuntu en Debian).

Als jij zelf binaries hebt gecompiled dan had je vlak na de compilatie dat zelf moeten doen als je nadien wil kunnen verifiëeren of je binaries niet aangepast werden. Als jij zelf een package hebt gebakken dan heb je de package-build tools een private key moeten geven waarmee hij de signature in de package stopt. Die kan daarna met je public key geverifieerd worden.

Dat is helemaal niet aan de orde hier.
Er is geen geinfecteerde package verspreid via de package-managers.

Ja, een package maintainer zou een package kunnen maken en die kunnen verspreiden via het distributiesysteem van zijn distro, maar niemand werkt in een vacuum, net zo min dat een individuele developer in een bedrijf als microsoft zomaar code kan toevoegen aan hun software en dat kan shippen.

Ongetwijfeld is het in beide situaties wel voorgekomen, maar bij open source oplossingen zijn ook de klanten instaat de source te compilen, en kunnen ook onafhankelijke third parties de code scannen, en de packages rebuilden om te zien of er niks anders in zit dan wat de packager had aangegeven.

Je bent een beetje FUD aan het verspreiden.

"Linux-distro's BSD en Solaris"? Dat zijn twee totaal andere besturingssystemen dan Linux...

Les geleerd: niet zomaar binaries vanaf het internet trekken. Gebruik de package manager of bouw de binaries zelf als je niet kunt bewijzen dat je bron trustworthy is.

Maar voordat je die binaries maakt wel de hele code goed reviewen.

Dus jij pluist alle sourcecode na?

Nee, maar een stuk malafide code is wel een stuk lastiger te implanteren op b.v. github waar continue veel controle is van maintainers en ontwikkelaars. Dus zo lang je de repo cloned en van daaruit bouwt ben je in veel gevallen toch wel safe.

Aan de reacties te zien vindt ik het een slechte titel voor het artikel. (iedereen is maar over ssh bezig)

Ja er wordt een geinfecteerde openssh client gebruikt om login gegevens en data te stelen. Maar die heeft opzich niets te maken met de eigelijke malware en hoe deze zich in het systeem nesteld.
Het zou evengoed een pam module kunnen zijn.

ESET products detect the Kobalos malware as Linux/Kobalos or Linux/Agent.IV. The SSH credential stealer is detected as Linux/SSHDoor.EV, Linux/SSHDoor.FB or Linux/SSHDoor.FC. A YARA rule is also available in ESET’s malware-ioc repository on GitHub.

Ps voor iedereen met een vpn fetisch ik denk eigelijk dat ssh even veilig is als noem eender welke vpn software mischien zelfs veiliger.
In ieder geval openssh is makkelijker om goed en veilig op te zetten dan de meeste vpn software.
De functionaliteiten van ssh met tunnels volstaan volledig om alles wat ik remote op mijn eigen netwerk wil doen te kunnen doen.

[Reactie gewijzigd door Geuze op 3 februari 2021 11:21]

Ja ik wou net zeggen, als ik dit goed lees heeft OpenSSH vrij weinig met de daadwerkelijke malwareinfectie te maken. Het systeem raakt eerst geïnfecteerd en gebruikt vervolgens OpenSSH om gegevens te gaan communiceren. Terwijl de titel doet vermoeden dat bij grote instanties mensen met de hand geinfecteerde OpenSSH executables hebben zitten downloaden, waarna de boel geinfecteerd raakte... Dat lijkt mij toch sterk

[Reactie gewijzigd door jaapzb op 4 februari 2021 11:18]

Het gaat om gerichte malware die een achterdeur opent door inloggegevens te stelen via een geïnfecteerde OpenSSH-download

Dus de hele "malware" is gewoon volle permissies als gevolg van een foute download, waarvan de locatie niet wordt vermeld.

Die zou onder andere toeslaan op Linux-distro's BSD en Solaris.

Pardon?

Linux-distro's, BSD en Solaris. (komma er tussen..)