Over 170K Mikrotik routers geinfecteerd met cryptojackers

[Loeri]

Bron: https://www.trustwave.com/Resources/Spi ... he-World-/

Kort samengevat: CVE-2018-14847 zorgt er voor dat hackers zonder enige authenticatie de login credentials kunnen bemachtigen. En zo kunnen ze dus inloggen op je mikrotik device, proxy aanzetten en een coinhive mining script injecteren.

Als je wil testen of je Mikrotik router vulnerable is, kan je deze PoC uitproberen: https://github.com/BasuCert/WinboxPoC

Patchen die handel!

[ubremoved_539]

Niet echt slim van je Winbox bereikbaar te hebben op je WAN poort

[boran_blok]

gelijk wat over je wan poort feitelijk.

Als ik remote aan mijn router settings moet tunnel ik over ssh, hoe minder open poorten hoe beter.

[yaris]

gelijk wat over je wan poort feitelijk.

Als ik remote aan mijn router settings moet tunnel ik over ssh, hoe minder open poorten hoe beter.

Je hebt poort 22 of andere openstaan ?

Heb zelf mikrotik en patch geregeld dus aan een ramp ontkomen precies

[ITnetadmin]

Compromissen he.
Soms moet je remote ergens in kunnen en is een vpn opzetten teveel koppijn.
Gewoon proberen om een custom port te gebruiken.

[boran_blok]

Concreet,

ik ga over ssh naar mijn server op poort 22222, authenticatie dmv private/pubkey paar, en dan via tunnels zet ik een bepaalde poort op naar het IP van de router.

In putty ziet het er dan zo uit:


dan kan ik localhost:12345 doen voor naar de pfsense login te gaan.

[ubremoved_539]

Compromissen he.
Soms moet je remote ergens in kunnen en is een vpn opzetten teveel koppijn.

Compromissen, teveel koppijn en security gaan NIET samen

Ik gebruik trouwens SSTP (zit standaard in Windows en gaat gewoon over https) als VPN naar thuis.

[ITnetadmin]

R2504, ik ga volledig akkoord.
Dat is nu eenmaal het compromis.
Als het een tijdelijke opstelling is, weeg je soms af wat je acceptabel vindt.
Bv ik stel een router in op een remote locatie, en tijdens de initial setup, die deels remote verloopt, is de webui bereikbaar vanop de wan.
Kwestie va de vpn setup makkelijker te kunnen debuggen.

Also: port 222, 2222, en 22222, zijn al even obvious voor ssh als port 22.

[ubremoved_539]

Bv ik stel een router in op een remote locatie, en tijdens de initial setup, die deels remote verloopt, is de webui bereikbaar vanop de wan.

Het zijn zo'n beetje de klassieke excuses (die niet beperkt blijven tot die initiele setup)... iemand die ernstig is met security denkt daar niet aan.

Als je zo'n dingen regelmatig moet installeren heb je gewoon een script en staat het op 1 minuut dicht (en niet de komende 5 jaar).

[boran_blok]

22222 is gewoon gebruikt voor het meerendeel van de automatische scripts tegen te houden.

Geen root of wachtwoord logins toestaan helpt ook al. Veel meer dan dat kan je ssh niet dicht timmeren.

Op een gegeven punt moet je wel vertrouwen op één protocol dat zijn werk goed doet en correct beveiligd is. Anders moet je gewoon gaan airgappen en geen enkele poort open laten.

Als er een issue is met de security van ssh zelf denk ik dat dit wel redelijk snel de ronde zou doen, nog sneller dan de CVE's van mikrotik routers.

Het enige wat nog beter zou kunnen aan mijn setup is een IP range filter en fail2ban automatische blocking bij mislukte pogingen. Maar een certificaat brute forcen duurt toch wel even.

Stap één bij gelijk welke server/device die ik heb is alles behalve die ssh dicht zetten over dat stuk kan je hoe dan ook aan al de rest.

[ITnetadmin]

Het zijn zo'n beetje de klassieke excuses (die niet beperkt blijven tot die initiele setup)... iemand die ernstig is met security denkt daar niet aan.
Als je zo'n dingen regelmatig moet installeren heb je gewoon een script en staat het op 1 minuut dicht (en niet de komende 5 jaar).

Dit is dezelfde discussie die ik ook voer telkens ik een remote reconfig doe op een systeem dat enkel openstaat via SSH.
Mijn manier om accidental lockout te vermijden is nl... effe telnet aanzetten.
"Jama je kan ook deze anti lockout line in de ssh server toevoegen"
Jaja, tot ik effe iets over het hoofd zie of 2 sec niet oplet of de ssh server crasht of niet goed reboot, zeker.

Scripts waar meer tijd inkruipt om ze te maken dan om het effe manueel te doen.
Mss leuk als het altijd om dezelfde modellen, of zelfs merken van toestellen, zou gaan.

Security is ook opportunity.
Een niet default user/pwd combinatie op een custom port, die tijdens een initial config of remote reconfig aangezet wordt, is een acceptable risk.
We spreken hier niet over multinationals of bedrijven met een 24/7 production cycle hoor.

[ubremoved_539]

Een niet default user/pwd combinatie op een custom port, die tijdens een initial config of remote reconfig aangezet wordt, is een acceptable risk.

Zolang dit enorm beperkt is in tijd... en je de discipline hebt om het uit te zetten kan het een acceptable risk zijn. Ik doe het in ieder geval niet, ik heb totaal geen zin later verantwoording te gaan afleggen bij m'n klanten (en ze zouden het niet aanvaarden ook niet) waarom het grondig is fout gegaan.

We spreken hier niet over multinationals of bedrijven met een 24/7 production cycle hoor.

Dergelijke malware of dingen zoals ransonware maken ook geen onderscheid tussen een consument of een multinational. De schade bij kleine bedrijfjes is trouwens vaak nog groter omdat ze backups en dergelijke meestal ook niet echt op orde hebben.

[ITnetadmin]

Ja, je moet idd wel die discipline hebben.

Ransomware lijkt me eerder binnen te komen via users die op dubieuze email attachments of links klikken dan geinjecteerd via een firewall die effe een open poort had.
Zoiezo is een van de grote gevaren naar ransomware toe slechte backups.
Waaronder ik versta "backups van dewelke alle shares accessible en writable zijn ook wanneer de backup niet genomen wordt".
Een goeie backup in een kleine omgeving heeft minstens 1 copy die offline is, of die op zn minst zelf de share accessed en ook direct terug unmount als ie gebackupped heeft (maw pull vanuit de backup ipv push vanop de file server).