Botnet infecteert Linux-servers via SSH met cryptominer
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....
Maar slim bedacht....
Door Tha Cleaner: Was een kwestie van tijd.
Maar slim bedacht....
Maar slim bedacht....
Huh slim bedacht, hoezo?
Door The FOSS:
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.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).
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:
Huh slim bedacht, hoezo?
Door Tha Cleaner: Was een kwestie van tijd.
Maar slim bedacht....
Maar slim bedacht....
Huh slim bedacht, hoezo?
Op die manier geld proberen te verdienen met cryptomining natuurlijk...
Door Anoniem:
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.....
Door The FOSS:
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.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).
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.
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.
Door Anoniem:
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.
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.
Door The FOSS:
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).
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.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.
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.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.
Neem Amazon aws bekend genoeg suc6.
De groep gebruikers heeft een leuke lekke betekenis.
Door Anoniem:
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 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.
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:
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.
Door Anoniem:
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.
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
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
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!
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.
Vergeet fail2ban ook niet.Door Anoniem:
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.
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.
"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.
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.
Door Krakatau:
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.
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.....
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!
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.
Door karma4:
Zou je dat zelfde durven doen met honderden gebruikers
Met netwerken tot duizenden hosts? Waarom niet? Beleid doorvoeren.Zou je dat zelfde durven doen met honderden gebruikers
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?Door Anoniem:
tja dat kan wel..... maar ut help nieh veel (ben immers root op systeem dat ik beheer)
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.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
