Personal tools

Hackstory Twitter Hackstory Facebook


From Hack Story

Jump to: navigation, search
Staff Zap (Under Construction)black.jpg

Hace poco, el servidor web de Apache, ha sido atacado por un par de

hackers, por {} y por Hardbeat, y cambiaron el logo "powered by
Apache" por el de Microsoft BackOffice. Han tapado el agujero y han
explicado como lo han echo en la página,
Estaba empezando a traducirla, pero ya estoy cansado, asi que os la
pongo en ingles.
Por cierto, en la web también hay dos miniprocesillos interesantes
para que alguien los comente aquí como código fuente, es un sustituto
del telnetd y un sustituto del fingerd, no creo que sean muy largos
para lo que hacen.

Lokutus, asimilando la red.

Date: Thu, 4 May 2000 21:08:06 +0200
From: Peter van Dijk <petervd@VUURWERK.NL>
Subject: How we defaced

               How we defaced
                    by {} and Hardbeat

 * Before you start reading
This paper does _not_ uncover any new vulnerabilities. It points out common
(and slightly less common) configuration errors, which even the people at made. This is a general warning. Learn from it. Fix your systems,
so we won't have to :)

 * introduction
This paper describes how, over the course of a week, we succeeded in
getting root access to the machine running, and changed
the main page to show a 'Powered by Microsoft BackOffice' logo instead
of the default 'Powered by Apache' logo (the feather). No other changes
were made, except to prevent other (possibly malicious) people getting in.

Note that the problems described in this paper are not apache-related,
these were all config errors (one of 'm straight from BugZilla's README,
but the README had enough warnings so I don't blame the BugZilla developers).
People running apache httpd do not need to start worrying because of
anything uncovered herein.

We hacked because there are a lot of servers running apache
software and if got compromised, somebody could backdoor
the apache server source and end up having lots of owned boxes.

We just couldn't allow this to happen, we secured the main ftproot==wwwroot
thing. While having owned root we just couldnt stand the urge to put that
small logo on it.

 * ftproot == wwwroot
 * o+w dirs
While searching for the laters apache httpserver to diff it the with
previous version and read that diff file for any options of new buffer
overflows, we got ourselves to We found a mapping of
the on that ftp including world writable directories.

So we wrote a little wuh.php3 including

and uploaded that to one of the world writable directories.

 * Our commands executed
Unsurprisingly, 'id' got executed when called like

Next was to upload some bindshell and compile it like calling and then
executing it like calling

 * The shell
Ofcourse we used a bindshell that first requires ppl to authenticate with
a hardcoded password (:

Now we telnet to port 65533 where we binded that shell and we have local
nobody access, because cgi is running as user nobody.

 * The box
What did we find on box:
-o=rx /root
-o=rx homedirs is a freebsd 3.4 box. We didn't wanted to use any buffer
overflow or some lame exploit, goal was to reach root with only
configuration faults.

 * Mysql
After a long search we found out that mysql was
running as user root and was reachable locally. Because was
running bugzilla which requires a mysql account and has it
username/password plaintext in the bugzilla source it was easy to
get a username/passwd for the mysql database.

We downloaded nportredird and have it set up to accept connections on
port 23306 from our ips and redir them to localhost port 3306 so we could
use our own mysql clients.

 * Full mysql access
 * use it to create files
Having gained access to port 3306 coming from localhost, using the login
'bugs' (which had full access [as in "all Y's"]), our privs where
elevated substantially. This was mostly due to sloppy reading of the BugZilla
README which _does_ show a quick way to set things up (with all Y's) but
also has lots of security warnings, including "don't run mysqld as root".

Using 'SELECT ... INTO OUTFILE;' we were now able to create files
anywhere, as root. These files were mode 666, and we could not overwrite
anything. Still, this seemed useful.

But what do you do with this ability? No use writing .rhosts files - no
sane rshd will accept a world-writable .rhosts file. Besides, rshd
wasn't running on this box.

 * our /root/.tcshrc
Therefore, we decided to perform a trojan-like trick. We used database
'test' and created a one-column table with a 80char textfield. A couple
of inserts and one select later, we had ourselves a /root/.tcshrc with
contents similar to:
      cp /bin/sh /tmp/.rootsh
      chmod 4755 /tmp/.rootsh
      rm -f /root/.tcshrc

 * ROOT!!
Quite trivial. Now the wait was for somebody to su -. Luckily, with 9
people legally having root, this didn't take long. The rest is trivial
too - being root the deface was quickly done, but not until after a
short report listing the vulnerabilities and quick fixes was build.
Shortly after the deface, we sent this report to one of the admins.

 * Fix that ftproot==wwwroot
Another thing we did before the deface, was creating a file 'ftproot' in
the wwwroot (which was also ftproot), moving 'dist' to 'ftproot/dist'
and changing the ftproot to this new 'ftproot' dir, yielding the
world-writable dirs unexploitable but allowing ftp URLs to continue

 * What could have been compromised?
Remember the trojaned tcp_wrappers on last year? If we
wanted to, we could have done the same thing to Apache. Edit the source
and have people download trojaned versions. Scary, eh?

 * In short:
- ftproot==webroot, worldwritable dirs allowing us to upload and execute
  php3 scripts
- mysqld running as root, with a FULL RIGHTS login without a password.

 * Compliments for the Apache admin team
We would like to compliment the Apache admin team on their swift
response when they found out about the deface, and also on their
approach, even calling us 'white hats' (we were at the most 'grey hats'
here, if you ask us).

                                         {} and Hardbeat.

          {} ( is part of
     RooT66 -
ShellOracle -
        b0f -

    Hardbeat ( just has a lame page at


By John Leyden Posted: 31/05/2001 at 17:59 GMT

The cracker who broke into the Web servers of open source development site SourceForge has broken cover to boast of his exploits, and brag he also compromised the systems of the Apache project.

Fluffy Bunny defaced a Web site ( to list the accounts he had managed to compromise and to brag that his actions had gone unnoticed by SourceForge administrators for five months (against the week SourceForge has publicly admitted). The defacement has since been removed but can still be seen (thankfully minus confidential account information) on defacement archive here

According to the posting, Fluffy Bunny obtained passwords and user names for SourceForge accounts after successfully placing a Trojan horse program on a Secure Shell (SSH) server. Apparently this was possible because Fluffy Bunny had already compromised the servers run by an ISP.

Gaining control of this SSH server, which provides a Unix command line interface for remote administration of Web servers, allowed Fluffy Bunny (in his words) to "sniff my way onto and SourceForge Web server and leave all sorts of goodies in the code".

Brian Behlendorf, president of the Apache Software Foundation, has sent a posting to developers admitting that its servers have been compromised but also downplaying fears that source code had been modified. He makes a pretty convincing argument here that attempts to do serious damage were successfully thwarted.

What remains unclear are the motives of Fluffy Bunny (other than pure mischief) for mounting the attacks in the first place.

Fluffy Bunny signed off his defacement by saying: "I'd like to thank Valinux [which runs SourceForge], Apache, Akamai and of course Exodus. Without their poor security and refusal to make security breaches known to the public I wouldn't be sitting atop a mountain of roots and oodles of proprietary software."

This statement together with Fluffy Bunny's logo - Tux the Linux penguin (complete with rabbit ears) masturbating a disproportionately large pink penis - probably mean he is no friend of the open source community...

Retrieved from "" - La historia nunca contada del underground hacker en la Península Ibérica.