Crack.LinuxPPC.org Cracked

An anonymous reader noted that it appears that crack.linuxppc.org has been, well, cracked. There is a mirror of the defaced page at here being hosted by attrition.org. The actual box is down as of when I type this. On the upside, it sure took a long time for someone to get in there (I'm still amused that they posted the root password). Jason Haas from LinuxPPC said "The machine is going to Daniel Jacobowitz, who won it legitimately. The subsequent problems occured after Dan installed a backdoor, and have since been cleared up. The original problem was that proftpd-1.2.0pre4 was left running with a /incoming directory."

Comments

I'm a little surprised...

[jd]

Warnings about possible security risks of setting -any- anonymous account writable have been around for a while. Even SATAN, which is hardly new, used to complain viciously about that one.

On the other hand, regularly sweeing crack.linuxppc.org with security scanners, to see if there are any holes there could be construed as cheating, as it would present a moving target, which is virtually guaranteed to stay ahead of all currently-known exploits.

However, this -does- show the importance of such sweeps, for mainstream machines, and why it's important to take advisories seriously, either from a scanner, CERT, securityfocus, or the developer.

If you download a package off Freshmeat, which has a huge warning sign glued onto the announcement saying "DO NOT HAVE WRITABLE ANONYMOUS ACCOUNTS", I'd be willing to bet that the developer isn't asking for a plate of scrambled eggs, grits and toast.

why it took so long

[jnazario]

hi all,

it took so damned long not because a hack didn't exist (ProFTPd has been vulnerable for some time) but because the standard method used to crack the, a buffer overflow, probably wasn't written with PPC assembly in mind. most BO's out there are for x86, with a good number for SPARC, as well, but ony recently did some PPC shellcode (along with Alpha shell code) get put out in wide release. after the ProFTPd crack was well known, it became, unfortunately, more of an exercise of security through obscurity.

a link to a recent piece on PPC shellcode is at http://packetstorm.se curify.com/papers/unix/ppc.shellcode.txt. i just checked for proftpd exploits on packetstorm and found quite a few; the presence of a writable incoming/ directory helps a LOT.

so, it still took longer than most challenges out there, and that's why i like LinuxPPC for various servers. that and they're just damn fast.

attrition.org page

[little_blaine]

The defaced page posted by attrition.org is NOT what was done when the machine was first cracked. AFAIK, the web site wasn't defaced when Dan Jacobowitz first cracked the machine, but Dan left a back door open for script kiddies to exploit and said kiddie went and did his "look at me I'm so cool send me email via hotmail - page created with frontpage" act.

One of these days dist maintainers will wake up

[Greyfox]

I get pretty thoroughly annoyed by the assorted Linux dists that by default enable every damn server ever made. By doing so, they increase your security exposure immeasurably. New users of the OS will either never use those services or they'll open further security holes by allowing all their friends to log in. To make matters worse, most dists merrily setuid any program where the author claims it needs setuid, meaning those new users may as well be giving their friends root, because once you obtain a shell login on the machine, root becomes trivial to obtain.

A far better solution would be to not install ANY servers by default -- let the user go in and install them after the install if he wants them. For people with a legitimate need, most dists allow you to create a list of packages to install, which should work fine for any large shop that actually needs those services installed. At the same time, make it much harder to obtain a setuid bit in a standard dist. Anything that gets a setuid bit should be subjected to a source code audit to make sure that at the very least no simple buffer overflows (Such as the one that compromised this machine) exist in the software. Closed source programs should probably never be allowed an setuid bit as closed source programmers tend to be sloppier and their source isn't open to review.

Dan's Crack

[mhatle]

A lot of us were on IRC when Dan was trying to crack the box. He realized the exploit in ProFTPd, but it still took many days to come up with the shell code.

Shell code on a PPC is much more difficult to do then intel due to the multiple caches.

Dan intentionally didn't deface the page, all he did was add his name to the end of the credits and update the "cracks" to 1. :)

It was a pretty amazing crack exploiting not only the program, but how the CPU controls the cache. Especially when he could barely use GDB on his own machine to debug it. (GDB got confused with the discrepecies in the cache, and the out of order execution of the CPU.)

Congrats Dan! (FYI Dan hacked into the machine well over two weeks ago..)

Re:Dan's Crack

[Anonymous Coward]

In response to all the posts on this, I felt it would be best to give people a bit of a timeline of what happened when. Please note, I am a Fine Arts Major with hardly any low-level computer experience, so even though he talked about *how* he was doing it frequently enough, I didnt understand more than 2% of it.

Wednesday Dec 15th:

Finals are over: Dan gets started.

Friday Dec 17th:

Dan sucessfully cracks the Machine. Increments Number of Cracks, adds name to Credits, and waits to see how long it takes for someone to notice. Leaves self back door in form of open port to telnet to.

Thursday the 23rd:

I notice the change of the website to what is currently hosted here, and emailed Dan about it. (on a side note, I'm not trying to take credit for notifying him first. I'm just stating what I saw)

by Friday the 24th:

Dan resecured the site.

Signed,
Mike
The guy who lives next to Dan.

Script Kiddie Bait.

[GodHead]

So what exactly does this contest prove? Not that the box is secure. All it means is that the 31337 hax0r dudes couldn't find a script to gain root. How many people actually think that the real black hats will stop trying to transfer funds from NationsBank long enough to really try and brake this machine. And even if master hackers did get root why would they bother to boast about it with some lame "U R Ow3nd!" page? Most likley they'd use the information to hack other boxes.


So take these "security challenges" with a grain of salt. And please, no "Why doesn't every vendor do this." posts.


G.H.
I do not want what YOU haven't got.

linuxppc already awake

[mcc]

> A far better solution would be to not install ANY servers by default -- let the user go in and install them after the install if he wants them.

i have linuxppc 1999, and they actually do exactly what you suggest. Nothing, not even httpd or telnetd, is turned on by default, and to turn it on you have to go into whatever that file is and uncomment out the lines. Meaning nothing gets enabled unless the user cares..
which is why linuxppc makes such a big deal about their "out of the box" security, since you're no more likely to crack linuxppc "out of the box" than the proverbial server with no network connections buried in a concrete box.. there's nothing there to crack.

i believe that the thing with the crack.linuxppc.org box specifically is that they started out with nothing enabled, and then have been slowly adding services over time in order to make hacking easier..

UNIX security is hopeless.

[Animats]

Look. The problem is architecture. Nothing that has servers running as root is ever going to be secure. The amount of trusted software is just too large. The problem is that so many people have seen nothing but the UNIX/NT model of the world that they don't realize there are other ways to design a system.

There are alternative OS architectures. But they're rare on PCs.

• Systems with "mandatory security". This is the feature that gets you above the C level in the Orange Book standards. In the mandatory security world, there is no root login, and as you increase in privilege level, you can read less and less. If you log in as the security officer, you can only read security-officer level files and use special security-officer tools; you can't use the system normally. So viruses, etc. can't leak upwards. Conversely, programs running at high security levels can't write data to lower levels, so classified data can't leak down.
• Transaction processing OSs, the archtype of which is IBM's CICS. Think of an OS architected to run CGI-BIN programs, each in its own protected space.
• Capability-based systems, like EROS and KeyKOS. Unfortunately, the people who write these tend to be incomprehensible. And work on EROS seems to have stopped since the key people graduated. EROS is GPL'd, and someone might pick it up and bring it up to the point that it was usable. Any takers?

  We need one widely used secure OS, just so people can see what one is like.

Re:UNIX security is hopeless.

[Kaufmann]

In capability-based systems, users or user accounts do not "own" processes, per se. There are specific objects that do disk maintainance; these objects possess very specific capabilities that allow it to do manipulate storage, but little else. The user, in turn, acquires capabilities that allow him to tell these objects to do certain things.

Philosophically, capability systems are much more egalitarian than ACL-based systems; they are also much closer to the real world: you don't see "root people" going around doing anything they want to everyone else's property, do you? (Well, actually, you do: they're called the police force. We're working to fix that bug by the next release. :])

Re:They don't seem too happy about it...

[WNight]

To be precise, if you have a hacking contest where you pay $x to the winner, if the computer is not cracked, all you have proved is that the machine is not crackable in that ammount of time, by anyone who values $x more than a potential $x * n, where n is the number of potential juicy targets running this system, or by anyone who values $x more than being anonymous.

So, if you offer $10k for a two-month contest to crack into a potential bank security system, you may get a few bored people playing around with it, but the real devious people will wait till it's "proven" uncrackable, and they'll crack into the bank running it, perhaps getting away with more money.

This does produce semi-valid results, for small values of 'n', the number of potential juicy targets, or very high values of $x... If Microsoft paid $1M for 'arbitrary binary' exploits on Win9x, they'd get a lot of takers, because $1M is more than you'd probably get in any reasonable win9x attacks, because nobody uses win9x for anything important. Similarly, if you only had one system, and $x was high enough to rival any potential gains from cracking the system later, you might get people seriously trying.

But, over all, it's a publicity stunt. You aren't guaranteed to get the same people trying, or with the same motivation, so you can't expect the same results.

ProFTPD

[MacGyver]

I'm the maintainer/developer of ProFTPD. Just a couple of notes to those who've already responded here:

1) ProFTPD has very loud notices saying that anything before 1.2.0pre8 is not to be considered secure.

2) On the whole, ProFTPD has had far, far, far fewer security issues and exploits out there than any other open-source FTP server. We take security seriously, and have always responded quickly to security issues. The code has undergone a couple of audits now. No, that doesn't mean it's 100% secure, but it does mean we've taken a close look at it, and are endeavoring to make it as secure as we can.

3) ProFTPD, when properly configured, will not run as root or with root privileges except for very limited periods for specific actions. Compiling ProFTPD with capabilities support on Linux is definitely the recommended configuration.

4) The official ProFTPD web site is www.proftpd.net.

5) The latest version of ProFTPD is 1.2.0pre9. 1.2.0final will be out this week sometime.