The beauty of old-school backdoors | Hacker News Reader

The beauty of old-school backdoors

blog.ioactive.com

38 pointswgx8 comments

Heh, I guess I'll share the one backdoor that was left in some the NVG510 (AT&T UVerse modem that you have no choice but to use) modem firmware. Now, you did have to solder on the board to get a serial console, but once you got that, you could quite easily get to a root shell. (by default, it was this "user" shell that was exposed in some non-US configurations on the network by telnet)

All you had to do was type "magic", and then once magic mode was enabled, type "!" and you got dropped at the root shell.

A shame they patched the firmware to remove magic mode and really locked things down after I published an app to root the modem via the web interface to fix various bugs in the firmware.. App eventually got pulled for ToS violation from the Play store, and just so happens a few weeks later AT&T pushed a firmware update that fixed all the exploits I knew of

Did the update fix any of the bugs?

Making a backdoor that relies on raw packets may net you benefits in terms of avoiding detection of network connections/syscalls by system tools (netstat and the like). Writing your own micro tcp/ip stack will also avoid having to throw libpcap into your backdoor. Of course, raw packet access is usually only reserved for root, so you'll have to fall back on the OS's network stack & calls to get this type of tool in, but eventually it makes for a more stealthy rootkit.

If you get really fancy you can fuck with network protocols in general and avoid getting caught by network detection & analysis. One good example is finding some traffic like DNS or ICMP that gets overlooked easily in graphs of network traffic and is already connectionless, so it's more difficult to catch someone constantly connected via backdoor.

Once I saw a backdoor use ICMP to do basic communication with a CNC, and when it got the correct reply it'd use another protocol (and host) to pass data. Only even realized that was happening after another compromise was found. And of course it was totally valid traffic so it didn't get picked up by any network sensors.

And of course it was totally valid traffic so it didn't get picked up by any network sensors.

That's the part of a lot of the backdoors and hacks that makes my head spin. No one can tell programmatically if certain traffic is "good" or "bad" - you have to go through it and devine it's intent.

Given that, is it even worth anyone's time to try to secure systems, or should we all just adopt some zen-like acceptance of the futility of all action?

That's why you practice "defense in depth" - multiple layers of security measures. This means not only security countermeasures at multiple points in your network, but multiple tactics to look for a compromise.

Yes, of course you should continue to secure your systems. But remember that the word 'security' means 'the state of being free of danger or threat'. Your systems are never completely free of that danger. That's the zen-like acceptance; I will never be secure, but I will work towards being secure. Enlightenment is when you realize security is not having a system at all.

IMO looking at existing, evolved, biological systems is a great hint at the eventual future. Even if some of it was trial-end-error, it comprises millions of years of secrecy, analysis, and combat between hideously complex systems.

My favorite was from a pen test that I heard of back in the 1990s. Most people don't realize that Postscript is a full-featured programming language, and high end printer/fax machines used an operating system written in Postscript. To "print" a document you actually executed a program that resulted in a printed document.

Well, "print" the wrong document and your printer/fax machine just turned into a router for anyone who knows how to call up and send the right message...

There used to be a rather negligent backdoor in some 3COM products - you could log in with username 'debug' and password 'synnet' to get a full admin shell with extra debugging commands. IIRC it wasn't printed in the user manuals, but was fairly obvious from poking around in the firmware updates. Fortunately the password could be changed, so it wasn't a completely irreparable security hole.

Reply on news.ycombinator.com