Hotel Wi-Fi router security hole: will this be the Ultimate Pwnie Award Winning Bug for 2015?

You’ve probably heard of the Pwnie awards.

Every year, alongside the BlackHat convention in Las Vegas, the Pwnie ceremony “celebrat[es] the achievements and failures of security researchers and the security community.”

We’ve written about some of the winners before.

The TLS bug known as Heartbleed, for example, scooped a Pwnie.

So did the data breach implosion at the Mt Gox Bitcoin exchange, which saw more than half a billion dollars worth of BTC vanish in a puff of…well, a puff of nothing, apparently.

IBM was once short-listed for the remarkable, if amusing, blunder of giving away USB keys infected with not one but two two strains of malware – at a security conference.

The bug that trumps them all

But the bug we’re about to describe surely trumps them all.

If you’re a bookmaker who offers bets on the Pwnies, we reckon this is a wager you should open at the comedy odds of $1.01. (That’s an out-there 100-to-one on in fractional odds.)

The flaw is designated CVE-2015-0932, and documented by cert.org as Vulnerability Note VU#930956.

The headline says most of what you need to know:

Multiple ANTlabs InnGate models allow unauthenticated read/write to filesystem.

Simply put, some versions of a popular hotel internet access server – those portals you interact with to get Wi-Fi access while you’re at a conference centre or staying in a hotel – can be completely drained of data, and then reprogrammed arbitrarily, via the outside (internet-facing) interface.

Without any authentication.

You connect to TCP port 873 using rsync, and you can read and write any file you like.

Just like that.

Why we’re betting on this one

And that’s why this is, surely, not just a bug, but a $1.01-class Pwnie-winning bug.

To explain, we should probably give a very brief overview of rsync, which was born in Canberra, Australia, in the 1990s.

Andrew Tridgell, a splendid fellow who is probably better known for Samba, the open source reimplementation of Microsoft’s SMB (Server Message Block) file sharing system, actually wrote up rsync as his PhD thesis in 1999.

So the protocol has an academic as well as an intensely practical history.

Basically, rsync does remote synchronisation, so that a source and a destination server can compare two filesystems (or directory trees) across the network, and automatically make their contents match.

Obviously, you can do that simply by coping the whole directory tree from the source to a new folder on the destination every time, and then deleting the old tree off the destination server, but that’s not very efficient.

Rsync works out the differences between the two sides “on the fly,” and automatically copies across a close-to-minimal set of changes, compressing them as it goes.

Files that are missing from the destination are copied in full.

Files that have been deleted from the source are automatically removed from the destination as well.

Files that have been changed are updated by working out in real time a compact set of “diffs”, or differences, that can be applied to the destination to make it match the corresponding source file.

Best of all, neither side needs any advance knowledge about what’s at the other end: the diffs are cleverly negotiated as part of the protocol.

For example, imagine you have a 1000-line configuration file, but all you want to do is sneak in a line in the middle saying:

 dangerous_unauthenticated_remote_login = true
 

With rsync, you don’t have to copy the whole 1000-line file; the protocol will work out that it needs to tell the destination server something along the lines of, “go forwards 45,755 bytes in the file you already have, and insert this line, then you’re done.”

In other words, rsync gives you a completely general-purpose way to do both full and incremental backups, and it is super-efficient about doing it.

So if you were actually setting out to create an insecure, remotely-updatable router, unauthenticated rsync would be a truly efficient and hacker-friendly way to do it.

If you had a hammer…

Imagine you were an attacker.

You could start off by rsyncing the whole router outwards to your own computer, starting with an empty directory tree.

In that case, rsync would work out you have nothing at all, and send you the entire filesystem, neatly compressed to save bandwidth.

At your leisure, after you’d milked the stolen files for anything private, like usernames, passwords, email addresses, user registration data and so on, you could then decide which configuration files you wished to tweak.

For example, you might decide to add your own secret access points; to enable HTTP interception; to turn on remote root login; to change the root password; and even to add a comedy login message to the Wi-Fi portal.

You could also Trojanise some of the software on the router, such as the DNS server (to run DNS hijacks), the web filtering proxy (to do HTTPS man-in-middle attacks), or the POP3 relay (to read email passing by).

If software you wanted to abuse wasn’t there already, you could just add it in on your side.

Once you’d made the changes to your local copy of the router’s filesystem, you could use rsync again in the other direction to put your changes into place.

Your hacking would not only be easy, but also quick and efficient, thanks to rsync's automatic smarts in difference detection.

If you were a cracker, and you could write your own specifications for a remote unauthorised read/write hole, this is probably what you’d ask for.

And that’s why the InnGate bug is on our extra-super-short-list for a 2015 Pwnie Award, even though there are still several months to go before the results will be decided.

What to do?

• If you run a affected InnGate router, patch it right now: there is a fix available.

This flaw was responsibly disclosed so that a patch was ready well before the bug was made publicised.

• Don’t be afraid to ask at the hotel or conference centre what Wi-Fi access portal they use, and whether they’re patched.

If no-one can tell you, see the next suggestion.

• Consider using your own 3G/4G mobile connection whenever you can.

If you travel a lot, you will find that many countries make it easy for overseas visitors to buy pre-paid SIM cards with a reasonable data allowance.

Just swap your home SIM for the overseas one and you won’t get stung by roaming charges.

• Consider setting up a Virtual Private Network (VPN).

You can do this at home, or urge your IT guys at work to do so if they haven’t already, so you never have to (and, indeed, can’t by accident) send unencrypted traffic through Wi-Fi hotspots.

A VPN encrypts all the network traffic from your laptop or mobile device, even traffic such as HTTPS that is already encrypted, back to head office or your home, where it emerges onto the open internet.

That means you are no less secure on the road than you would be on your own network, which can cut a lot of security uncertainty out of the equation.

• If you are a router vendor, ask yourself, “Could a hole of this sort get past my quality assurance (QA) and testing?”

By rights, this sort of bug ought to be out of the question.

Even the most cursory port scan would show the listening port, and the most cursory cross-check of the software running on the router would reveal which program had that port open.

Remember, if you are selling network products, there are some QA questions you simply can’t afford not to answer.

“What on earth is that network service, and should it be listening at all?” is one of them.