Slashdot Mirror

← Back to Stories (view on slashdot.org)

Crack.LinuxPPC.org Cracked

Posted by CmdrTaco on from the that-took-awhile dept.

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."

29 of 125 comments (clear)

  1. Re:/incoming == security breach??? by elixir · · Score: 2

    he exploited a buffer overflow in proftd. since the machine was a ppc, no one could use the pre-written expliots... the winner rewrote the exploit in ppc assembly.

    --
    -- The intelligence on this planet is a constant, but the population is growing. --
  2. Re:/incoming == security breach??? by bmetzler · · Score: 2
    That doesn't make sense to me. I mean, I assume that the ftpd does a chroot() to the top-level ftp directory. This, by itself, does not explain how someone got root on the machine.

    Yes, it'd be nice if it was explained how the hack worked, like the PC Week hack was documented.

    -Brent
  3. Re:/incoming == security breach??? by Emphyrio · · Score: 2

    a world writable ftp directory exposes a remote root vulnerability in this version of proftpd.
    Check your standard script kiddie sites (i.e. rootshell, securityfocus et al.)..

    Emphyrio

  4. I'm a little surprised... by jd · · Score: 4
    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.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  5. Re:/incoming == security breach??? by elixir · · Score: 2

    See the following article.

    --
    -- The intelligence on this planet is a constant, but the population is growing. --
  6. why it took so long by jnazario · · Score: 4
    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.

    --
    jose nazario jose@biocserver.cwru.edu
  7. software problem, not writable "/incoming" by jetson123 · · Score: 2
    Being able to write information (through ftp or otherwise) on a public server in some form or another is often an essential part of its function, and the rule "don't have publically writable directories" simply doesn't make sense.

    In this case, it appears that the ftp daemon was buggy, and in this particular case did the wrong thing with a writable /incoming directory. The solution is to run a different FTP daemon or to fix the bug.

    In part, the responsibility for this lies with the ubiquitous use of C for Linux system programming. Guarding against buffer overflows in C is a lot of work, and it is humanly impossible to catch all the possible problems in a large program. C++ helps a lot with its string class. Writing servers in Java, Perl, Python, Eiffel, Ada, SML, or many of the other languages with runtime checking is even better.

    1. Re:software problem, not writable "/incoming" by WNight · · Score: 2

      Not true.

      And I'm not a bullshit OOP bigot. I do 90% of my 'real' code in C.

      In C, if you read a string of characters, you need to have space allocated for it. You can either read a set ammount and truncate, or read a variable ammount and auto-allocate.

      But, whatever you do, you need to do it yourself. You can't simply say "string data; data stdin;" and get the whole string, to the limit of available memory.

      You can code a routine to do this, anyone who writes anything which accepts user input has probably written a reusable 'safe input' module. But, you still have to do it yourself.

      And you have to do it EVERYWHERE you look at data. You can't make any assumptions. If 999 of 1000 expected comma seperated integers are integers, the 1000th might be something else entirely, consisting of non-numeric characters. You need to check for nor just the correct inputs, but ALL forms of incorrect input. And then, you need to attach basic error handling to all of these.

      If a fucking pain. A good half, at least, of anything I write is spent in input checking, even when the actual input it done in a couple of lines, and could be scanned with a few scanf()s (albeit badly.)

      It's not a good reason to switch to what might be a more crippled language, just because that language keeps you from making errors, but you need to recognize the weaknesses of your tools or you can't work past them.

  8. Re:_incoming_ ? by heh2k · · Score: 2

    it wasn't an "easy" hole, it took them several weeks (iirc) to write the ppc asm shell code.

    i believe that the point of the contest was to see how long an UNMODIFIED box would stay up. that is, w/o upgrading anything.

    personally, i think it's a pointless. it's only a matter of time before a system is broken; there's always bugs.

  9. attrition.org page by little_blaine · · Score: 4

    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.

  10. One of these days dist maintainers will wake up by Greyfox · · Score: 3
    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.

    --

    I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

  11. Dan's Crack by mhatle · · Score: 5

    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..)

    1. Re:Dan's Crack by Anonymous Coward · · Score: 3
      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.
  12. Flooded by MrPlab · · Score: 2

    Hmm, seems their machine is being flooded.

    Straight from the website:
    We had a sudden influx of script kiddies. Page temporarily offline until the machine is fixed.
    This machine resecured courtesy of drow.

    Interesting.. maybe it wasn't truely cracked after all. Hehe, that would be neat.

    With karma issues,
    Matthew
    _____________________________________

    --
    sortakinda.ca | canadian paraphrasing.
  13. Packages need some way to validate security by Christopher+B.+Brown · · Score: 2
    What "the world needs" is for there to be some automated tools to help search for configuration problems of this sort.

    Something like cfengine would be usable to this end; make install should generate a cfengine script that validates the system configuration, with the option of either warning of problems or of fixing them.

    If not cfengine, then something else may be usable.

    The critical point here is for the tool used to not merely be "a shell script," as those may get diverse in style to the point of unreadability. The validation needs to be in more of a descriptive style so that it doesn't get unreadable.

    --
    If you're not part of the solution, you're part of the precipitate.
  14. Re:HTML Generator vs. "wrote exploit" by evilpenguin · · Score: 2

    If I read the lead article correctly, the defaced web page was done by someone else after a back-door had been installed by someone who wrote a PPC exploit of the proftp hole. In other words, FrontPage boy had to be let in by someone who knew how to do something... Mind you, I'm just interpreting the lead story -- I do not have firsthand knowledge.

  15. Script Kiddie Bait. by GodHead · · Score: 3


    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.

    --
    Just wait till some crappy band steals your nic.
  16. Re:HTML Generator vs. "wrote exploit" by dillon_rinker · · Score: 2

    Several others in this thread have already made comments amounting to "a tool is a tool", so I'll chime in with this. I have a friend who is fluent in 486 assembler (he does embedded control work). He also knows C. I ask you, why would someone who knows assembler use a compiler to create binaries?

    I know how to use a screwdriver to turn screws by hand. I prefer a variable-speed drill with a screwdriver bit. A $39.95 Black & Decker works as well as a DeWalt.

  17. linuxppc already awake by mcc · · Score: 4

    > 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..

    --
    Irritable, left-wing and possibly humorous bumper stickers and t-shirts
  18. UNIX security is hopeless. by Animats · · Score: 4
    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.

    1. Re:UNIX security is hopeless. by WNight · · Score: 2

      Congrats on a well written explanation of how it's possible to have a more secure system...

      But, how is this possible without trusted binaries and all?

      I mean, eventually there's an account which can do disk maintenance. This account has to be able to read the HD, and thus can read all information and write it to files another user has access to.

      How do you allow ultimate access without creating what is essentially a root login with a restricted shell?

      What seems to me to be the best idea is to modify most everything so that only the barest cores of the OS run as root, everything else would run as a user. Thus TCP stack exploits could crash the TCP stack, and take the machine off the net, but they couldn't give access to anything, etc.

    2. Re:UNIX security is hopeless. by Kaufmann · · Score: 4

      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. :])

      --
      To the editors: your English is as bad as your Perl. Please go back to grade school.
  19. Whoa whoa whoa by FascDot+Killed+My+Pr · · Score: 2

    And please, no "Why doesn't every vendor do this." posts.

    Let's be careful with our non-sequiters, there, pardner.

    I agree that "cracking contests" like this do NOT prove you have unbreakable security. But that doesn't mean that crack attempts are useless.

    For instance, all security experts recommend that you should try to crack your own boxes to test them. How is this different?
    ---

    --
    Linux MAPI Server!
    http://www.openone.com/software/MailOne/
    (Exchange Migration HOWTO coming soon)
  20. Re:HTML Generator vs. "wrote exploit" by w3woody · · Score: 2

    You're not missing anything; HTML and PowerPC assembly are two different languages. Hell, it would like me sniffing my nose at you because you couldn't code in Cobol or something else equivalently useless to you where you work...

  21. Re:They don't seem too happy about it... by WNight · · Score: 3

    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.

  22. Moderate Cramer's post UP dammit! by jabbo · · Score: 2

    Languages, while not totally irrelevant, are often a bandaid for poor architectural, system, and policy decisions. Writing servers in Python (which is written in C) or in Java (whose JVM is written in C, and whose Java-to-native frontend for GCC is written in C) or in SML, or in Middle Welsh, or in Urdu, will not overcome all the problems of human stupidity, arrogance, and inexperience. The OpenBSD people did the Right and Boring and Horribly Painstaking thing and just audited everything in sight, which is why I'm setting up OpenBSD for my firewall and NAT box. Still, somebody else's empty promises won't keep me from getting 0WN3D, and my own auditing and hardening might not either.

    Neither will StackGuard or MultiStack or DDD or assiduous use of MemProf, Checker, Electric Fence, and GDB. People make mistakes, not only in programs to handle incoming packets, but also in automated test harnesses, in compilers, in networking code, in firmware for NICs, in (f00f) CPUs...

    I disagree with the "if you think about what you're doing" line of argument (if you think about it hard enough, your system will be infinitely secure cause you'll never write a line of code), but the "just choose a better language" schtick is even worse.

    The determined Real Programmer can write Fortran in any language. I personally stick to what I'm reasonably good at (secure distributed transaction processing) and ask other people to audit the shit out of it, then tell the users how to flog me if it breaks. If you're writing daemons for more than just fun and education (i.e. if you think you suck less than I do) I certainly hope you have similar standards... hell, I'm a systems administrator, not even a developer, but I see some real circus acts billing themselves as "developers" these days...


    As an aside, my personal take on the Kill-Microsoft bent is that people resent a company whose foundation is "We Know Best" and whose track record indicates "Actually, We Don't, But Pay Us Anyways".


    --
    Remember that what's inside of you doesn't matter because nobody can see it.
  23. Security Statistics by Anonymous Coward · · Score: 2

    This site is very interesting: If you look at "http://www.attrition.org/mirror/attrition" and check the statistics, you will find that almost 65% of all the hacked servers are running NT/IIS. However, if you check "www.netcraft.com", you will see that NT/IIS are only being used on 23.5% of all the Internet servers. This makes me wonder: How can MS claim that nobody did ever make any proof that NT/IIS is less secure than UNIX/Apache ? This is the real world proof that NT is very very insecure !

  24. Still can get to other pages at crack.linuxppc.org by vrmlguy · · Score: 2

    If you want to see the original page, circa November, google still has it cached here. And, it looks like the links on that page still work, so you can go to the credits page and see both the number of successful cracks: 1 in the info box and the additional credit to And Daniel Jacobowitz, because good security isn't always good enough. near the end of the listing.

    --
    Nothing for 6-digit uids?
  25. ProFTPD by MacGyver · · Score: 4

    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.