
FritzFrog: A New Generation of Peer-to-Peer Botnets - DamnInteresting
https://www.guardicore.com/2020/08/fritzfrog-p2p-botnet-infects-ssh-servers/
======
gnabgib
The source of the wired piece was posted 6 days ago here[0] along with the
bleeping computer analysis (better than wired's, IMO)[1]. It was also posted
again 3 days ago [2], when I also posted it until I noticed it was a dupe (the
dupe detector doesn't seem to work on the guardicore URL).

I've been watching this specific botnet since April, almost 6k attempts/server
so far.. it's slow and wide (rarely repeat IPs, max rate was 2/minute, but
it's more like 8-20/day now) so most detection approaches won't work (search
your logs of sshd for "Received disconnect from", "Did not receive
identification string from" and "Connection closed by"). It's also
everywhere.. a lot of digital ocean, but also AWS, google, Azure. Government
IPs, consumer IPs, IPs reported as part of backbones

[0]:
[https://news.ycombinator.com/item?id=24217592](https://news.ycombinator.com/item?id=24217592)

[1]:
[https://news.ycombinator.com/item?id=24208873](https://news.ycombinator.com/item?id=24208873)

[2]:
[https://news.ycombinator.com/item?id=24245824](https://news.ycombinator.com/item?id=24245824)

~~~
dang
Looks like none of those submissions got much discussion, so we'll keep this
one but change the URL to the original source, from
[https://www.wired.com/story/a-new-botnet-is-covertly-
targeti...](https://www.wired.com/story/a-new-botnet-is-covertly-targeting-
millions-of-servers/). Thanks!

~~~
elorant
Ars Technica were the ones who reported the story first:

[https://arstechnica.com/information-
technology/2020/08/new-p...](https://arstechnica.com/information-
technology/2020/08/new-p2p-botnet-infects-ssh-servers-all-over-the-world/)

~~~
gnabgib
Are you sure? Bleeping Computer (BC) has a publish time of
2020-08-19T06:00:00-04:00, while Ars Technica has a publish time of
2020-08-19T13:00:16Z.. looks like a 3 hour lead.

Interestingly Guardicore reports 2020-08-19T09:50:36+00:00 suggesting BC (a)
can produce a quality article in <9 minutes, (b) there was a prior article (c)
BC got a heads-up

------
xorcist
Lots of suggestions to place SSH behind other protocols or obfuscate the port
number here. Let's be clear about one thing, OpenSSH is the least insecure
service you are running. A lot of talented people have audited that code many
times over. It may show its age but it is an order of magnitude simpler than
SSL. Every pre-auth process is sandboxed.

Most breaches are caused by bad passwords. Use keys, or enforce good
passwords, before doing anything else. That VPN might well be less secure, and
port knocking is just an unusual authentication with a really short password.

~~~
wlll
Running SSH on a non-standard port alone isn't worth much, but it's defense in
depth. You don't have to not do all the other things if you run SSH on a non-
standard port.

~~~
mercer
One really valuable thing for me about running SSH on a non-standard port is
that it dramatically decreases the noise in my logs. That's not irrelevant!

------
indigodaddy
This is why you should do one or more of the following at the very least.

\- Always use keys and disable password based login

\- Do not have ssh publicly exposed, or at the very least only via a bastion
server, but if that bastion server is publicly available, then you are still
quite vulnerable (perhaps even more so if someone gets into your bastion and
is able to ssh to all the things if you are using key-based logins from the
bastion)

\- Always use a passphrase for your keys (helps with the “if someone breaks
into your bastion scenario”)... but the best thing you can do is just don’t
expose ssh to the public network

~~~
dgellow
If you do expose your SSH port, one option is to setup a firewall rule to
allow your own public IP for connections to the SSH port and drop all the
rest.

If you're using Digital Ocean, you can set a firewall rule via the droplet web
interface, that's quick to do. Otherwise just a simple iptables does the
trick.

Edit: if you have a static public IP, of course

~~~
gnabgib
As long as you have a static IP that could never change, otherwise you'll deny
yourself access after, for example a power outage where your router gets a new
IP (or a random period of time where your ISP decides to change your IP, or
you move, or you want to connect from another server).

Using an alternative connection to activate the protocol is probably the only
reasonable defense:

* An https service that can enable a port for connections from an IP for a limited time (which has some security implications too since it would need root access, or to trigger something with root access)

* Something built into KLO hardware, or software provided by your provider (including something simple like turn on the firewall a few minutes after boot, and using the reboot trigger and connecting in that brief window.. as long as you don't mind your server down - probably ok as an emergency recovery strategy)

* Some form of port knocking

~~~
framecowbird
I’m not sure I trust myself to set up my own bastion securely. Are there any
companies that offer secure bastions as a service?

What I’m envisaging is: I pay somebody, make an account on their site and add
2FA, and then they give me a server with a static IP and handle the auth. Then
all I have to do is to whitelist that static IP.

Ideally it would function as both an HTTP proxy and an SSH proxy; like a
‘secure web portal’

~~~
alexchamberlain
How much would you pay for that?

~~~
whatshisface
$30/month

------
pengaru

      echo "PasswordAuthentication no" >> /etc/ssh/sshd_config

------
ur-whale
How can I check if my server has been pwned?

This link is a little more informative:

[https://www.securityweek.com/fritzfrog-botnet-uses-
proprieta...](https://www.securityweek.com/fritzfrog-botnet-uses-
proprietary-p2p-protocol)

~~~
gnabgib
Guardicore has a shell script (detect_fritzfrog.sh) which you can run on your
machine [0], it's short (28 lines) and sweet - you can read the source and see
what it's up to.

[0]:
[https://github.com/guardicore/labs_campaigns/tree/master/Fri...](https://github.com/guardicore/labs_campaigns/tree/master/FritzFrog)

------
Chickenosaurus
It seems to me this bot could be disabled.

Every bot has a list of peers and their SSH credentials. This way, peers can
reinfect machines that were restarted, thus allowing the bot to be volatile on
the infected machine.

The article says the researchers can join the peer-to-peer network. The
researchers should be able to get a list of all infected machines including
SSH credentials. These credentials could be used to remove the backdoor SSH
key, kill the bot & netcat processes and maybe change the SSH password on all
infected machines at the same time.

Am I missing something?

~~~
net4all
That it is likely to be illegal in many (most?) countries.

~~~
Chickenosaurus
Yes, you are surely right. I was mostly wondering if the bot net is actually
secure.

------
baybal2
Big question: "where does their monster dictionary comes from?" I find it very
unlikely they get root passwords from simply scooping public leaks.

~~~
gerdesj
Run a honeypot in a VM for a few weeks.
[https://www.honeynet.org/projects/](https://www.honeynet.org/projects/)

You leave a small enticing ssh listener which is actually a Python or similar
daemon process that fakes its output and logs usernames and password attempts.
Obviously that thing is on its own DMZ with no outbound access.

You can harvest the latest crop of usernames and passwords that the baddies
are using with a little bit of effort, but not much! You can also slow them
down a bit with a sprinkle of tarpitting. Take that list and use it as a
password blacklist for your own systems. You might allow the list to decay by
say six months after the last sighting to avoid it getting too big. Actually
you could allow decay with a normally distributed six month spread, centred
over one year to avoid predictability. That may be going too far - once a
password is on the list, I suggest you keep it.

Usernames that are not simply given names is a very good idea. Service
accounts should not be able to login interactively if they don't need it (set
your RDP groups up properly, PLEASE!) Give service accounts odd names and
sha1sum style passwords. Administrator, Administrateur, Administrador etc
should not be able to login at all to anything and nor should root. Those four
names come up in my logs so often, it isn't funny. If you've got an account
called sql or ldap or mail or similar, then get rid of it. Please.

~~~
baybal2
> sha1sum style passwords

The question is more of how they got those high quality, completely bruteforce
safe passwords. Were they targeting sysadmins of major Co's?

~~~
gerdesj
Wot?

------
password4321
Is it possible for OpenSSH to block connections based on SSH client version?

I've basically shut down brute force attempts immediately on connection by
blocking out 'libssh' and 'SSH-2.0-Go' using Bitvise SSH Server (for Windows,
which is free for personal use).

