Summary: Bri's old Sparc 5 running Linux proved to be a poor choice for a Honeypot, but an excellent lesson in architecture diversity.

At the end of May, I left my claustrophobic apartment in Silicon Valley for our grand move to Seattle. No, I'm not going there to work for Microsoft, thank you (Good Linux/Unix suggestions welcome, however...). It was a sad day. No, I wasn't sad to be leaving the horrible heat, the strip-mall-ville skyline, or the land of a thousand midriffs. Good riddance, I say. I was mourning the moment when I would power off my machines and put them in boxes for the big move.

Four machines, each with uptimes of a year or more. Sure, I had to reboot for a kernel upgrade now- and-then just like the next guy, but that's it in the Linux and Unix world. Take that, Bill. (Whoops, I guess he's a neighbor now.) My machines had performed flawlessly, through blackouts and earthquakes [1]. However, one machine that had been running the most smoothly was the one that was failing to do its function.

I'd set up a honeypot on one of the systems. It was running a two year old intentionally-outdated Linux distro full of bugs and instant-root holes. In the year it'd been running, no one had gotten in.

I had an IDS set up to watch the network and, with extensive host logging enabled, I could see that tons of attempts to break in had occurred. Most of the daemons were running with holes -- old Wu-FTPd, POP and IMAP bugs -- pretty much everything but Apache had some problem that should have been exploitable to grant you shell access. Quite a few brute-force password cracking attempts were made, but I did have strong or locked passwords on all accounts, so I didn't expect those to succeed.

So what was keeping all these buggy programs from being exploited? The machine was running Linux, but not on a PC. Instead, I'd installed it on the only spare machine I had: an old Sparc 5.

All the entry points were buffer overflows and format string bugs. Most of the attacks were simple automated exploit scripts built from exploits or proof-of-concepts that were released to BugTraq and other full disclosure locations. Most of the code released to these venues tries to prove a vulnerability can be exploited, but only concentrates on the most popular Linux computer architecture: the x86 CPU.

Sun Sparcs use a completely different CPU architecture. A compiled binary on a PC won't run whatsoever on a Sparc; same goes for any other foreign machine like Alpha, MIPS, etc.... The attackers who had grabbed the public exploits were all trying to use PC shellcodes, which could crash the affected servers but wouldn't ever compromise them. So, because the CPU couldn't run the code supplied by the attackers, it stayed relatively safe in spite of the fact that it was horribly out of date.

Now, I'm not suggesting that you put Linux on machines with non-x86 CPUs and consider your security process completed. Different CPUs make the cracker's job harder [2], but had any of the crackers wanted to get into this machine, it should have been trivial. They wanted to break into any machine, not this one in particular. Since their scripts didn't crack it, they didn't try to get into it manually. They'd doubtless have better luck somewhere else anyway.

So my Sparc honeypot experience left me with one conclusion: Invest in more floor space and put up a PC if I wanted to watch the bad guys in action.

Or I could install Windows....

NOTES

[1] The only earthquake we noticed during our three year sentence in California was a 5.2 about 30 miles away. Had we left a few weeks earlier, we wouldn't even have had that one.

[2] I'll even argue with this comment myself. It's not harder to create Sparc shell code, per se, it's just that more folks write their exploits assuming an x86 processor. Thus the attacker must write/borrow Sparc shell code to use instead. It's this extra level of effort that most newbie crackers don't have, or don't bother investing. Had they been determined, it would have taken another half hour of research and testing to adjust their scripts to account for alternate CPU types. The problem is that many attacks result in only two possible outcomes: The attack is successful and they get access, or the affected daemon crashes and they don't have a second chance to try a different exploit.

Bri Hatch is Chief Hacker at Onsight, Inc, and author of Hacking Linux Exposed and Building Linux VPNs. He moved up to Seattle to get away form the sun, and instead it seems to have followed him. Go figure. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2002.

This article was first published here in ITworld.com Inc., 118 Turnpike Rd., Southborough, MA 01772  on 11-Jun-2002.