9 ms·

FritzFrog: A New Generation of Peer-to-Peer Botnets

indigodaddy 6y ago
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
- 29athrowaway 6y ago
  Using ssh in an obscure port helps a little bit. PAM modules also help.
  - gnabgib 6y ago
    This particular malware doesn't seem to grok when you're using certs or keys, so while it'll never be successful it keeps trying (effectively a resource DOS). Obscure port does nothing.. it eventually finds it and then you'll see tons of servers try that port (unless you constantly move it). I'm not sure how you imagine Pluggable Authentication Modules would help? Fail2Ban or some sort of active IPS helps, but because the IPs are very varied (and presumably ever increasing) and infrequently re-attempt it doesn't help much. Note anyone running exposed SSH without keys or certs, should run the detection script[0] (which is just shell and you should read first before installing) provided by Guardicore [0]: https://github.com/guardicore/labs_campaigns/tree/master/FritzFrog https://github.com/guardicore/labs_campaigns/tree/master/Fri...
    - LinuxBender 6y ago
      For my hobby servers, I listen on a non standard port. Not once in 20+ years has anything hit that port. Even when I've had domains / sites that ruffled feathers, no hits. It most certainly cuts out noise in logs and stops all the bots.
      - AndyMcConachie 6y ago
        I've also used a port other than 22 for sshd. And I can confirm that the past month I've been getting hit with lots of failed login attempts on ssh. My basic look at the logs shows it trying random dictionary words for usernames. And every connection attempt comes from a different IP.
        linker3000 6y ago
        Yes, I'm seeing the same to my non-standard port and the connection attempts are from a large number of different addresses (and only usually 1 or 2 attempts from each) that Fail2Ban does not trigger.
      - Caligatio 6y ago
        A few months ago I started noticing failed login attempts on my non standard SSH port (> port 1024) so I moved it up a few port numbers. About 2-3 weeks ago, I noticed that it was getting hit again by failed login attempts. I then changed the port to the original and immediately started getting login attempts again... it kind of spooked me. I thought about using fail2ban but every login is a different IP (using my eyeballs, I didn't parse the logs).
        LinuxBender 6y ago
        I take a different approach than fail2ban. My sftp servers use a standard port 22 and any time people try to log in, I create an account for them automatically via a cron job in the sftp-only group and a null password. The bots will spend years trying to log in repeatedly every few minutes. I have yet to see them upload anything interesting. Many years ago, bots would upload malware, then try to browse to it on port 80. But no more... These bots just want to get a shell and install malware / c&c tools. Some of them try port forwarding, but I have that restricted for the sftp users.
- manishsharan 6y ago
  Could you comment on my way of accessing my servers on AWS: My server are on VPC and no public ssh is allowed (nothing is open besides 443). When I want to login to my server , I run a script to modify security. (I have disabled ssh password logins and ssh is running on non standard port). And when I am done with task, I plug the hole in security group with another batch code. I am worried that I may be not exposing my servers with my practices.
  - chewmieser 6y ago
    No op, but your practice is probably fine. More ideally, SSH would be locked down to your public IP address only. If you're already scripting this, you could just do a curl request to one of the many "what is my ip" services and set that instead of 0.0.0.0/0 as the security group IP address. We also use bastion hosts. They're whitelisted for key-based SSH only access for our public IP addresses. We can jump around to other servers once we login to that one, but our externally facing servers never advertise anything other their base service (:443 or whatever is running on them). I also use them with my personal servers and just leave them shut off when I'm not actively using them. This keeps costs down, but more importantly it permanently blocks off SSH access unless I'm specifically in need of it.
  - ajawee 6y ago
    Did you try port knocking https://wiki.archlinux.org/index.php/Port_knocking https://wiki.archlinux.org/index.php/Port_knocking
- dgellow 6y ago
  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 6y ago
    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 6y ago
      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 6y ago
        How much would you pay for that?
- qeternity 6y ago
  I’m curious why people say not to have ssh exposed if you only have key auth enabled. It seems to me that every single other password + some other number of protections is inherently weaker than simple old public key auth.
ur-whale 6y ago
How can I check if my server has been pwned? This link is a little more informative: https://www.securityweek.com/fritzfrog-botnet-uses-proprietary-p2p-protocol https://www.securityweek.com/fritzfrog-botnet-uses-proprieta...
- gnabgib 6y ago
  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/FritzFrog https://github.com/guardicore/labs_campaigns/tree/master/Fri...
- 0xdeadbeefbabe 6y ago
  I bet other botnets have been pwned.
gnabgib 6y ago
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 6y ago
  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-targeting-millions-of-servers/ https://www.wired.com/story/a-new-botnet-is-covertly-targeti.... Thanks!
  - elorant 6y ago
    Ars Technica were the ones who reported the story first: https://arstechnica.com/information-technology/2020/08/new-p2p-botnet-infects-ssh-servers-all-over-the-world/ https://arstechnica.com/information-technology/2020/08/new-p...
    - gnabgib 6y ago
      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
pengaru 6y ago
echo "PasswordAuthentication no" >> /etc/ssh/sshd_config
xorcist 6y ago
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 6y ago
  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 6y ago
    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!
- orev 6y ago
  Port knocking is not really “just a bad password”, as long as you are using it in conjunction with another secure service like SSH. However, you can get the same effect as port knocking with none of the drawbacks using single packet authorization like fwknop if you don’t want to go full VPN.
baybal2 6y ago
Big question: "where does their monster dictionary comes from?" I find it very unlikely they get root passwords from simply scooping public leaks.
- gerdesj 6y ago
  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 6y ago
    > 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 6y ago
      Wot?
password4321 6y ago
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).
Chickenosaurus 6y ago
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 6y ago
  That it is likely to be illegal in many (most?) countries.
  - Chickenosaurus 6y ago
    Yes, you are surely right. I was mostly wondering if the bot net is actually secure.

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

29athrowaway 6y ago
Using ssh in an obscure port helps a little bit. PAM modules also help.
- gnabgib 6y ago
  This particular malware doesn't seem to grok when you're using certs or keys, so while it'll never be successful it keeps trying (effectively a resource DOS). Obscure port does nothing.. it eventually finds it and then you'll see tons of servers try that port (unless you constantly move it). I'm not sure how you imagine Pluggable Authentication Modules would help? Fail2Ban or some sort of active IPS helps, but because the IPs are very varied (and presumably ever increasing) and infrequently re-attempt it doesn't help much. Note anyone running exposed SSH without keys or certs, should run the detection script[0] (which is just shell and you should read first before installing) provided by Guardicore [0]: https://github.com/guardicore/labs_campaigns/tree/master/FritzFrog https://github.com/guardicore/labs_campaigns/tree/master/Fri...
  - LinuxBender 6y ago
    For my hobby servers, I listen on a non standard port. Not once in 20+ years has anything hit that port. Even when I've had domains / sites that ruffled feathers, no hits. It most certainly cuts out noise in logs and stops all the bots.
    - AndyMcConachie 6y ago
      I've also used a port other than 22 for sshd. And I can confirm that the past month I've been getting hit with lots of failed login attempts on ssh. My basic look at the logs shows it trying random dictionary words for usernames. And every connection attempt comes from a different IP.
      - linker3000 6y ago
        Yes, I'm seeing the same to my non-standard port and the connection attempts are from a large number of different addresses (and only usually 1 or 2 attempts from each) that Fail2Ban does not trigger.
    - Caligatio 6y ago
      A few months ago I started noticing failed login attempts on my non standard SSH port (> port 1024) so I moved it up a few port numbers. About 2-3 weeks ago, I noticed that it was getting hit again by failed login attempts. I then changed the port to the original and immediately started getting login attempts again... it kind of spooked me. I thought about using fail2ban but every login is a different IP (using my eyeballs, I didn't parse the logs).
      - LinuxBender 6y ago
        I take a different approach than fail2ban. My sftp servers use a standard port 22 and any time people try to log in, I create an account for them automatically via a cron job in the sftp-only group and a null password. The bots will spend years trying to log in repeatedly every few minutes. I have yet to see them upload anything interesting. Many years ago, bots would upload malware, then try to browse to it on port 80. But no more... These bots just want to get a shell and install malware / c&c tools. Some of them try port forwarding, but I have that restricted for the sftp users.
manishsharan 6y ago
Could you comment on my way of accessing my servers on AWS: My server are on VPC and no public ssh is allowed (nothing is open besides 443). When I want to login to my server , I run a script to modify security. (I have disabled ssh password logins and ssh is running on non standard port). And when I am done with task, I plug the hole in security group with another batch code. I am worried that I may be not exposing my servers with my practices.
- chewmieser 6y ago
  No op, but your practice is probably fine. More ideally, SSH would be locked down to your public IP address only. If you're already scripting this, you could just do a curl request to one of the many "what is my ip" services and set that instead of 0.0.0.0/0 as the security group IP address. We also use bastion hosts. They're whitelisted for key-based SSH only access for our public IP addresses. We can jump around to other servers once we login to that one, but our externally facing servers never advertise anything other their base service (:443 or whatever is running on them). I also use them with my personal servers and just leave them shut off when I'm not actively using them. This keeps costs down, but more importantly it permanently blocks off SSH access unless I'm specifically in need of it.
- ajawee 6y ago
  Did you try port knocking https://wiki.archlinux.org/index.php/Port_knocking https://wiki.archlinux.org/index.php/Port_knocking
dgellow 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      How much would you pay for that?
qeternity 6y ago
I’m curious why people say not to have ssh exposed if you only have key auth enabled. It seems to me that every single other password + some other number of protections is inherently weaker than simple old public key auth.

ur-whale 6y ago

How can I check if my server has been pwned? This link is a little more informative: https://www.securityweek.com/fritzfrog-botnet-uses-proprietary-p2p-protocol https://www.securityweek.com/fritzfrog-botnet-uses-proprieta...

gnabgib 6y ago
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/FritzFrog https://github.com/guardicore/labs_campaigns/tree/master/Fri...
0xdeadbeefbabe 6y ago
I bet other botnets have been pwned.

gnabgib 6y ago

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 6y ago
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-targeting-millions-of-servers/ https://www.wired.com/story/a-new-botnet-is-covertly-targeti.... Thanks!
- elorant 6y ago
  Ars Technica were the ones who reported the story first: https://arstechnica.com/information-technology/2020/08/new-p2p-botnet-infects-ssh-servers-all-over-the-world/ https://arstechnica.com/information-technology/2020/08/new-p...
  - gnabgib 6y ago
    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

pengaru 6y ago

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

xorcist 6y ago

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 6y ago
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 6y ago
  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!
orev 6y ago
Port knocking is not really “just a bad password”, as long as you are using it in conjunction with another secure service like SSH. However, you can get the same effect as port knocking with none of the drawbacks using single packet authorization like fwknop if you don’t want to go full VPN.

baybal2 6y ago

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

gerdesj 6y ago
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 6y ago
  > 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 6y ago
    Wot?

password4321 6y ago

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).

Chickenosaurus 6y ago

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 6y ago
That it is likely to be illegal in many (most?) countries.
- Chickenosaurus 6y ago
  Yes, you are surely right. I was mostly wondering if the bot net is actually secure.