image

Botnet infecteert Linux-servers via SSH met cryptominer

vrijdag 5 januari 2018, 10:21 door Redactie, 18 reacties

Er is een nieuw botnet ontdekt dat Linux-servers via SSH infecteert met een cryptominer, die de gehackte machine naar de cryptocurrency Monero laat minen. Dat laat netwerkbedrijf F5 Networks weten. Zodra het botnet toegang tot een Linux-server heeft wordt er een bot en de "PyCryptoMiner" geïnstalleerd.

Deze cryptominer is gebaseerd op Python, wat het volgens de onderzoekers lastig te detecteren maakt. Ook kan de gehackte server worden gebruikt om naar Linux-servers te zoeken, alsmede kwetsbare JBoss-servers die een beveiligingsupdate van augustus 2017 niet hebben geïnstalleerd. De update verhelpt een kwetsbaarheid waarmee JBoss-servers op afstand kunnen worden overgenomen. Of het botnet ook JBoss-servers met de cryptominer infecteert laat F5 Networks niet weten.

De besmette servers worden via een command & control-server aangestuurd. In het geval deze server onbereikbaar is maken de servers verbinding met een pagina op Pastebin.com, die een alternatief adres voor de command & control-server bevat. Verder controleert de bot of er geen andere malware op de server aanwezig is, door op verschillende bekende bestandsnamen van malware te zoeken. Het uiteindelijke doel van de bot is het minen van de cryptocurrency Monero. Volgens F5 Networks heeft het botnet inmiddels 158 Monero binnengehaald, wat ongeveer 49.000 euro is.

Reacties (18)
05-01-2018, 11:35 door -karma4
Zodra het botnet toegang tot een Linux-server heeft

En dat probeert die bot met credentials guessing (of tewel brute forcen van wachtwoorden). Ik wens de bot veel succes daarmee (immers kansloos bij wachtwoorden van een enigszins normale sterkte).
05-01-2018, 11:36 door Tha Cleaner
Was een kwestie van tijd.

Maar slim bedacht....
05-01-2018, 11:38 door Anoniem
Door Tha Cleaner: Was een kwestie van tijd.

Maar slim bedacht....

Huh slim bedacht, hoezo?
05-01-2018, 13:15 door Anoniem
Door The FOSS:
Zodra het botnet toegang tot een Linux-server heeft

En dat probeert die bot met credentials guessing (of tewel brute forcen van wachtwoorden). Ik wens de bot veel succes daarmee (immers kansloos bij wachtwoorden van een enigszins normale sterkte).
Blijkbaar zijn er dus voldoende Linux servers slecht geconfigureerd, waardoor er geen of slecht wachtwoordbeleid is.
Daarnaast zijn er voldoende wachtwoord lijsten beschikbaar om gewoon een dictionary attack uit te voeren. Er zijn genoeg servers en daardoor computer power om dit aan te vallen.

Anders zou dit niet rendabel zijn. Blijkbaar dus toch een succes voor de bot..... Ondanks jouw wens.....
05-01-2018, 14:30 door -karma4
Door Anoniem:
Door Tha Cleaner: Was een kwestie van tijd.

Maar slim bedacht....

Huh slim bedacht, hoezo?

Op die manier geld proberen te verdienen met cryptomining natuurlijk...

Door Anoniem:
Door The FOSS:
Zodra het botnet toegang tot een Linux-server heeft

En dat probeert die bot met credentials guessing (of tewel brute forcen van wachtwoorden). Ik wens de bot veel succes daarmee (immers kansloos bij wachtwoorden van een enigszins normale sterkte).
Blijkbaar zijn er dus voldoende Linux servers slecht geconfigureerd, waardoor er geen of slecht wachtwoordbeleid is.
Daarnaast zijn er voldoende wachtwoord lijsten beschikbaar om gewoon een dictionary attack uit te voeren. Er zijn genoeg servers en daardoor computer power om dit aan te vallen.

Anders zou dit niet rendabel zijn. Blijkbaar dus toch een succes voor de bot..... Ondanks jouw wens.....

In tegenstelling tot Windows is de kwaliteit van de software niet het probleem bij Linux, maar de kwaliteit van de gebruikers. Je moet het wel kunnen, Linux.
05-01-2018, 14:33 door Anoniem
Ik wens de bot veel succes daarmee (immers kansloos bij wachtwoorden van een enigszins normale sterkte).

Hangt er erg vanaf of je eindeloos mag blijven proberen, of dat er sprake is van een fatsoenlijke password policy, waarbij je na een aantal pogingen een account lock-out krijgt. Sterkte van het wachtwoord is niet het enige wat van belang is.
05-01-2018, 15:02 door Anoniem
Door Anoniem:
Ik wens de bot veel succes daarmee (immers kansloos bij wachtwoorden van een enigszins normale sterkte).

Hangt er erg vanaf of je eindeloos mag blijven proberen, of dat er sprake is van een fatsoenlijke password policy, waarbij je na een aantal pogingen een account lock-out krijgt. Sterkte van het wachtwoord is niet het enige wat van belang is.

En:
- Start sshd niet op default port 22. Ja ja, het is security by obscurity, maar het werkt over het algemeen best goed en zorgt ervoor dat je log een stuk rustiger is.
- Sta geen password authentication toe, maar alleen pub/priv key authentication. In mijn beleving is password authentication op publiek toegankelijke servers gewoon vragen om problemen.
05-01-2018, 15:07 door Anoniem
Door The FOSS:
Zodra het botnet toegang tot een Linux-server heeft

En dat probeert die bot met credentials guessing (of tewel brute forcen van wachtwoorden). Ik wens de bot veel succes daarmee (immers kansloos bij wachtwoorden van een enigszins normale sterkte).


lol, en de paus is een vrouw
05-01-2018, 15:18 door Tha Cleaner
Door The FOSS:
In tegenstelling tot Windows is de kwaliteit van de software niet het probleem bij Linux, maar de kwaliteit van de gebruikers. Je moet het wel kunnen, Linux.
Maar je hebt bij Windows exact hetzelfde probleem. De gebruikers..... Daar zit hem juist het probleem in bij eigenlijk alle besturingssystemen.
05-01-2018, 17:00 door karma4 - Bijgewerkt: 05-01-2018, 17:01
Door Anoniem:
En:
- Start sshd niet op default port 22. Ja ja, het is security by obscurity, maar het werkt over het algemeen best goed en zorgt ervoor dat je log een stuk rustiger is.
- Sta geen password authentication toe, maar alleen pub/priv key authentication. In mijn beleving is password authentication op publiek toegankelijke servers gewoon vragen om problemen.
Leg de voorwaarden van een cloudleverancier er eens naast.
Neem Amazon aws bekend genoeg suc6.
De groep gebruikers heeft een leuke lekke betekenis.
05-01-2018, 18:42 door Anoniem
Door Anoniem:
Ik wens de bot veel succes daarmee (immers kansloos bij wachtwoorden van een enigszins normale sterkte).

Hangt er erg vanaf of je eindeloos mag blijven proberen, of dat er sprake is van een fatsoenlijke password policy, waarbij je na een aantal pogingen een account lock-out krijgt. Sterkte van het wachtwoord is niet het enige wat van belang is.
Dan introduceer je een DOS-vector. Als aanvaller hoef je alleen iemand's accountname te hebben, right?

Ik blokkeer een IP na X aanvallen (fail2ban), mijn servers rapporteren ook centralized in een DB.
Als iemand met SSH verbind zonder gewhitelist (in hosts.[allow|deny]) geeft SSH een regel in /var/log/auth.log:
/var/log/auth.log:Jan 5 16:12:53 hostname sshd[8275]: refused connect from 10.11.12.13 (10.11.12.13)


Door Anoniem:
Door Anoniem:
Ik wens de bot veel succes daarmee (immers kansloos bij wachtwoorden van een enigszins normale sterkte).

Hangt er erg vanaf of je eindeloos mag blijven proberen, of dat er sprake is van een fatsoenlijke password policy, waarbij je na een aantal pogingen een account lock-out krijgt. Sterkte van het wachtwoord is niet het enige wat van belang is.

En:
- Start sshd niet op default port 22. Ja ja, het is security by obscurity, maar het werkt over het algemeen best goed en zorgt ervoor dat je log een stuk rustiger is.
- Sta geen password authentication toe, maar alleen pub/priv key authentication. In mijn beleving is password authentication op publiek toegankelijke servers gewoon vragen om problemen.

Dan kan je beter een /etc/hosts.allow + /etc/hosts.deny configureren (automatisch), waarmee je een whitelist kan maken. Ik whitelist de meeste ranges van NL-ISP's die mensen in mijn omgeving gebruiken. Netwerk van de NS (trein), etc.
sshd configureren als:

/etc/ssh/sshd_config
AuthorizedKeysFile /etc/ssh/authorized_keys/%u

PubkeyAuthentication no
PasswordAuthentication no

Match User youruser Address 10.11.12.13
[spatie][spatie]PubkeyAuthentication yes


Bepaalde users configureren zodat ze in een jail zitten (voor services / data distributie, b.v. websites).

Ook de authorized_keys file heeft ondersteuning voor ACL's (per key!). Alles automatisch inrichten met een CM (Ansible). Per host (of groep) user(s) te configureren. Ik zet een key+acl bij de user en het configueert de /etc/hosts.[allow|deny], sshd_config en authorized_keys correct.

Ik denk niet dat mijn SSH lekt. Totaal (met gezonde paranoia) dichtgetimmerd op alle niveaus.
Alleen de firewall accepteert SSH vanaf ieder IP. Omdat /etc/hosts.[allow|deny] en sshd_config de beveiliging regelt i.t.t. een firewall.


/etc/hosts.deny
sshd: ALL

/etc/hosts.allow
sshd: 198.18.0.0/15
sshd: 198.51.100.0/24

Nu heeft niemand meer een smoes voor slechte tuning! Gebruik key based logins i.c.m. meer (doordachte) configuratie!
05-01-2018, 22:41 door Anoniem
Door Anoniem:
Door Anoniem:
Ik wens de bot veel succes daarmee (immers kansloos bij wachtwoorden van een enigszins normale sterkte).

Hangt er erg vanaf of je eindeloos mag blijven proberen, of dat er sprake is van een fatsoenlijke password policy, waarbij je na een aantal pogingen een account lock-out krijgt. Sterkte van het wachtwoord is niet het enige wat van belang is.

En:
- Start sshd niet op default port 22. Ja ja, het is security by obscurity, maar het werkt over het algemeen best goed en zorgt ervoor dat je log een stuk rustiger is.
- Sta geen password authentication toe, maar alleen pub/priv key authentication. In mijn beleving is password authentication op publiek toegankelijke servers gewoon vragen om problemen.
Vergeet fail2ban ook niet.
06-01-2018, 10:47 door Anoniem
"Sta geen password authentication toe, maar alleen pub/priv key authentication. In mijn beleving is password authentication op publiek toegankelijke servers gewoon vragen om problemen."

als beheerder van een aantal gedeelde grote machines, heb ik hier toch wel enige kanttekeningen.

ik zie gebruikers vaak deze passwordless rsa/dh based connecties opzetten en die vergeten dan helemaal dat ik als root ook meteen die sleutels heb en dus ook meteen op al die machines van ze kan komen waar ik eigenlijk niet hoor te kunnen komen.

nu ben ik misschien wel te vertrouwen, maar als als beheerder van zo een grote gedeelde machine mag en kan ik niet beheerders van andere grote gedeelde machines vertrouwen en die kunnen dus ook via deze manier (als je niet oplet) op je systeem komen.

sta daar dus bij stil.
06-01-2018, 12:17 door Krakatau
Door Anoniem: ik zie gebruikers vaak deze passwordless rsa/dh based connecties opzetten en die vergeten dan helemaal dat ik als root ook meteen die sleutels heb en dus ook meteen op al die machines van ze kan komen waar ik eigenlijk niet hoor te kunnen komen.

Je kan toch ook een passphrase op de passwordless connection zetten? (Waarmee toegang tot de key wordt afgeschermd).

https://www.ssh.com/ssh/passphrase

Dan heb je de voordelen van een passwordless connection maar moet je nog steeds de passphrase weten om er gebruik van te kunnen maken.
06-01-2018, 13:24 door Anoniem
Door Krakatau:
Door Anoniem: ik zie gebruikers vaak deze passwordless rsa/dh based connecties opzetten en die vergeten dan helemaal dat ik als root ook meteen die sleutels heb en dus ook meteen op al die machines van ze kan komen waar ik eigenlijk niet hoor te kunnen komen.

Je kan toch ook een passphrase op de passwordless connection zetten? (Waarmee toegang tot de key wordt afgeschermd).

https://www.ssh.com/ssh/passphrase

Dan heb je de voordelen van een passwordless connection maar moet je nog steeds de passphrase weten om er gebruik van te kunnen maken.

tja dat kan wel..... maar ut help nieh veel (ben immers root op systeem dat ik beheer) en je kunt dit niet server side afdwingen (als gebruikers inloggen) en moet de gebruiker dat bewust doen en daar zit em weer een probleem. je moet dit niet te gemakkelijk afwimpelen :).
06-01-2018, 16:41 door karma4
Door Anoniem:
....
Dan introduceer je een DOS-vector. Als aanvaller hoef je alleen iemand's accountname te hebben, right?
..
Dan kan je beter een /etc/hosts.allow + /etc/hosts.deny configureren (automatisch), waarmee je een whitelist kan maken. ..
Bepaalde users configureren zodat ze in een jail zitten (voor services / data distributie, b.v. websites).
....
Ik denk niet dat mijn SSH lekt. Totaal (met gezonde paranoia) dichtgetimmerd op alle niveaus.
..
Nu heeft niemand meer een smoes voor slechte tuning! Gebruik key based logins i.c.m. meer (doordachte) configuratie!
Zeer gezonde paranoia waar ik voor pleit.
Ik worstel dan nog enkel met een extra vraag. Zou je dat zelfde durven doen met honderden gebruikers en iets wat op SSH lijkt maar het net niet is? Dat is de data analytics big data hoek.
06-01-2018, 21:32 door Anoniem
Door karma4:
Zou je dat zelfde durven doen met honderden gebruikers
Met netwerken tot duizenden hosts? Waarom niet? Beleid doorvoeren.

en iets wat op SSH lijkt maar het net niet is?
As in?? Beheer MOET i.m.h.o via SSH (CM b.v. Ansible), geen custom daemons (puppet/etc). De SSH daemon is beter getest dan de custom daemons van CM-technieken. Waarom zou je die custom techniek willen vertrouwen?

Ik ben daarom ook TEGEN Ansible Tower / Ansible AWX en andere "webbased" klik-klik dingen. Dat centraliseert je CM, i.p.v. decentraliseert. Decentralisatie is stabieler. Iedere admin in een bedrijf kan alles (of delen) beheren vanaf zijn laptop/workstation, en info delen via git.

Een telnet-only network switch beheren (met Expect) via een SSH jumphost (met toegang tot switch-mgmt vlan), dat kan gewoon met Ansible.

Dat is de data analytics big data hoek.
Euh?! Wat bedoel je?
07-01-2018, 07:00 door Krakatau - Bijgewerkt: 07-01-2018, 07:08
Door Anoniem:
Door Krakatau:...

tja dat kan wel..... maar ut help nieh veel (ben immers root op systeem dat ik beheer)

Dan heb je het mechanisme niet begrepen. Het maakt niet uit dat jij root bent en bij hun private keys kan, want die zijn cryptografisch beschermd m.b.v. passphrases.

Door Anoniem: en je kunt dit niet server side afdwingen (als gebruikers inloggen) en moet de gebruiker dat bewust doen en daar zit em weer een probleem. je moet dit niet te gemakkelijk afwimpelen :).

Gebruikers, die bij jou via een passwordless connectie inloggen, hebben alleen hun public key op jouw server staan. Niet hun private key; als er wel private keys op jouw server staan, dan zijn die voor uitgaand inloggen op andere systemen. Het is eenrichtingsverkeer private -> public key, bij die passwordless connections.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.