Is your router taking part in DDoS attacks right under your nose?

You may have heard about BWAINs before.

A BWAIN is a Bug With An Impressive Name that has been given special marketing treatment in the hope of getting the right people to wake up and do something about it.

The more PR-savvy BWAINs even have their own logos, such as Heartbleed, HTTPoxy, Sweet32,Shellshock and ImageTragick.

Here’s this week’s one: SSHowDowN.

As BWAINs go, SSHowDowN isn’t a terribly catchy name, but it’s worth knowing about, especially if you are a vendor of IoT products that automatically set themselves up so they can be managed remotely over the internet.

The name SSHowDowN comes from Akamai, a huge player in the world of content delivery, and it got Akamai’s attention when the company started looking into recent surges in time-wasting traffic – what are usually called DDoSes, short for Distributed Denial of Service attacks.

If you want to knock someone off the internet, or at least to cramp their online style, without having to hack into their servers and break them on purpose, then generating lots and lots of purposeless traffic is an effective way to do it.

But just flooding them with network traffic from a few super-high-bandwidth locations, such as hacked servers on a modern multi-gigabit academic network, is not enough these days.

100 servers each pumping out a gigabit every second are fairly easy to identify and block, and every time you block the traffic from just one of them, you cut the severity of the attack by a whole percentage point.

What you really want are thousands, even hundreds of thousands, of modestly well-connected networks that don’t fit any obvious pattern, and that are hosted by hundreds or thousands of different ISPs in tens or hundreds of different countries.

Indeed, we recently wrote about a DDoS case involving investigative journalist Brian Krebs, in which more than 600 gigabits per second of legitimate-looking but completely purposeless data was generated from tens or hundreds of thousands of home networks, thanks to insecure “Internet of Things” devices such as cameras, routers and even printers.

The attack on Krebs was apparently driven by malicious software called Mirai that had deliberately been copied onto all those insecure devices.

No infection required

In contrast, Akamai’s SSHowDowN story doesn’t rely on infected routers: it needs only badly-configured ones.

The name SSHowDowN comes from SSH, short for Secure Shell, a well-known tool that is used ubiquitously across the internet for secure remote access.

But even though SSH is supposed to improve security, Akamai reported that SSH servers on a large number of SoHo routers – millions, it seems! – were the source of a vast quantity of DDoS traffic in Akamai’s network…

…and yet the crooks never even needed to login to the SSHowDowNable routers.

 

Simply put, the crooks figured out how to take traffic from one set of sources (this could, for example, be high-bandwidth servers on a hacked network), split it into lots of separate streams, and bounce each one off a different, innocent-looking router on an innocent-looking small network.

You can think of this as the network equivalent of money laundering on a huge scale.

By splitting your attack amongst thousands or millions of unexceptional and otherwise innocent networks around the world, you make it much harder for content delivery networks such as Akamai to block the malicious traffic cleanly and efficiently, because it’s mixed in so thoroughly with legitimate packets.

That’s why it’s called a distributed denial of service.

Improper lockdown

The SSHowDowN problem is caused by IoT devices that allow SSH connections, but don’t lock them down properly.

According to Akamai, many IoT systems have remote access via SSH enabled by default, but also have default “internal accounts” with known username/password pairs.

To stop these default accounts being abused across the internet, some vendors simply configure the system so that if you try to login with a known default password, the system immediately kicks you off.

Unfortunately, SSH isn’t only about secure shell logins, for all that it’s called “Secure Shell”.

SSH can also do what’s called traffic forwarding, for example by acting as a web proxy that accepts traffic from browser X, and transparently redirects it to site Y.

Done correctly, this sort of proxying can greatly increase security, because the traffic from X to the proxy, and from the proxy back to X is strongly encrypted, so that SSH acts as a sort of basic VPN (virtual private network).

But if you can make unauthorised use of proxies on other people’s devices, you can effectively co-opt them as partners in cybercrime, without them even being aware of it.

Unfortunately again, as Akamai points out, letting a crook authenticate first and then relying on them formally logging in immediately afterwards in order to detect they are up to no good is simply the wrong way to do security.

That would be like deliberately letting someone onto your property, but not into your house, and assuming that you’d done enough to stop them using your garden for criminal purposes.

And that’s exactly what crooks can do with a weakly-protected SSH server: there’s a well-documented way to authenticate, start up a proxy server for redirecting traffic, and then deliberately suppress the login part.

In other words, you use the dodgy password to trick the insecure router into letting you steal its identity and bandwidth as a proxy, but avoid the login part that’s needed for the router to kick you out.

The relevant SSH details, if you want to learn more about SSHowDowN, are as follows. The command sshconnects, authenticates and immediately logs in; ssh -D connects, authenticates, starts a forwarding proxy, and then logs in; but ssh -D -N connects, authenticates, starts a forwarding proxy…and then just sits there without logging in. That’s by design, and not a bug. It’s at the authentication phase that you are supposed to verify that the user is allowed to use your resources, whether that’s logging in to a remote shell, starting a proxy, or anything else. Default passwords subvert the entire authentication process. (In case you didn’t notice – it took me a while – the capitalised letters in the word SSHowDowN are a nod to ssh -D -N, where -D means to do proxy forwarDing and-N means Not to login.)

What to do?

Akamai presents various mitigations in its article, so we’ll send you there for the details.

All we’re going to say here is this, and because it’s Cybersecurity Awareness Month we are going to say it VERY, VERY LOUDLY…

DON’T WIRE DEFAULT PASSWORDS
INTO YOUR PRODUCT.

If you don’t intend to let a crook into your house, then don’t make it easy for them to get into the garden in the first place.

 

via:  sophos


Save pagePDF pageEmail pagePrint page

Leave a Reply

Your email address will not be published. Required fields are marked *