Why is the d.sh provider still up?
142.44.191.122 is in the range for a hosting provider in Canada. Why has it not been taken down if it's hosting something as clearly malicious as d.sh?
If you don't cover your Docker daemon API port you'll have a hell of a time... because cryptocreeps are hunting for it
Some Docker installations are getting hammered by malware skiddies hoping to mine digital cash using other people's CPU time. Infosec outfit Aqua – no, not the Barbie Girl band – said miscreants have spotted that a decent number of Docker deployments are lazily or inadvertently exposing the daemon API port to the public …
-
-
Wednesday 8th April 2020 10:41 GMT bombastic bob
Re: Why is the d.sh provider still up?
ack on that - I haven't tried wget'ting that file, but if I were them, I'd swap it for something that shuts DOWN the virus wherever the infection exists... ok maybe that is a *bit* too 'grey hat' but "I heard a rumor" that "someone did a shutdown script" like that for code-red infected machines {me whistles with innocent look} that basically detected where the penetration attempted to come from, and back-hacked them and turned of ISS [code red sat in memory, shutting down ISS would stop the infection temporarily].
Anyway...
I was just thinking about this, having had the need to have the network guy open up a non-obvious ssh port into a client's network so I could do things remotely. I was thinking of what security things I would need to add, users and passwords to modify and/or lock out from ssh logins, to an otherwiswe normal ssh daemon, how to do it without locking myself out by accident in the process, and things of THAT nature, then I saw this and "It figures, miscreants are out there TAKING ADVANTAGE of little or no on-site staff capable of mitigating such things".
my own system only allows specific users to log in from outside the network, which have cryptic user names and even MORE cryptic passwords. So I wanted to do something like THAT. But obviously I could lock myself out of logging in at ALL if I'm not uber careful.
and, of course, if I do NOT secure it more tightly, some miscreant out there is likely to POUND ON IT with one of those dictionary-based ssh attacks and maybe not get noticed for HOURS... because I had to open it up to an outside IP address as a result of of coronavirus responses by governments.
-
-
Wednesday 8th April 2020 12:13 GMT Peter Mount
Their own fault opening the socket?
It must be a cloud thing as most Docker installations have their API sockets as a unix socket, so it appears as a file in the host's filesystem & as such isn't accessible from any network interface.
Instructions on how to expose the socket on the network is out there but even Docker's documentation states why that's a bad idea.
So for them to be exposed it's either someones done that manually or someone's provider has exposed the API socket without any appropriate Firewall rules against them
