ACM – Defensive Attack

Tonight ACM hosted their first, and hopefully not last, security event called D-FENSE (Offensive Security Competition). The goal of the event was to write our team name in a file that was on one of several machines placed on a local network. The catch was that the file was owned by root, which means we needed to get root access to modify it. The event officially started when we were given the SSID and password for the router and the two IP addresses for the sandboxed servers.

Our play started by checking the machines’ web servers. Typing the IP address of a machine into the web browser routes requests to that machine. A default Apache server takes these incoming requests and routes them to port 80. This brought us to a web page. At first we weren’t sure exactly what we were looking for but after clicking a few links we stumbled upon a Drupal installation.

Drupal is a content management system that allows you to easily create a website and content. The admin can also create new users to help with the content creation. This installation of Drupal did not hide the user login prompt. After searching recent blogs on the page, we were able to find who they belonged to. These owners are the usernames in the Drupal database.
We stumbled across patrick who must have been a lazy boy because he never changed his default password.

After logging in with username: patrick password: password, we were given the permission to create content for the site. The format for this content was html, as well as php. By uploading Php code, we were given a way to run code on the server’s side. The first piece of Php code we ran was to get a directory listing. This allowed us to see the file hierarchy.

=====================

Team awesome is comprised of Michael Mitchel, Sarah Diesburg, and Chris Meyers.  We divided the work into: service scanning and discovery, manual web assessment, and vulnerability research.  Manual web assessment proved fruitful.

Modifation of the FINISH_LINE.txt file was achieved through (1) guessing the drupal password as ‘password’ which gave access to (2) execution arbitrary php code through a blogging type web posting and, finally, (3) compilation and execution of a < linux 2.6.24.1 vulnerability.

(1)
Trivial

(2)

<?php
 
exec(‘ls -al /, $array);
 
for ($i=0; $i < sizeof($array); $i++) {
 
    echo $array[$i] +<br>;
 
}
 
?>

The above php code, basically, provided us with a shell interface, albeit a bit tedious.  The ‘ls -al /’ command revealed the FINISH_LINE.txt file, owned on writable only by root. The competition goal was to write our group name to FINISH_LINE.txt and we had just achieved a milestone of obtaining a user level shell we concentrated our efforts on privilege escalation to root.

(3)
‘uname -a’ revealed that the server was running linux kernel 2.6.24.1.  A quick web search revealed that this version, and all previous, were susceptible to a local vmsplice privilege escalation vulnerability.  We copied the c exploit from the search result and compiled it on our local computer, commented out a missing #include error, added a #define PAGE_SIZE 4096, and compiled it for the last time, successfully.  We started a local apache2 server to facilitate a remote wget of our locally modified C code, using our aforementioned php arbitrary command execution.  Once the payload was on the server we compiled and executed it, again using the php arbitrary command execution.  The output from the compiled code execution led us to believe that it had worked and that, in fact, we had obtained root!  There was just one problem, we couldn’t send subsequent commands to the processes that had obtained root privilege escalation.  We tried echo piping into the binary and standard input redirection with no luck.  It was now about time to graduate from being a Script Kiddie and take a look at the vulnerability code.  At this point we were questioning whether the vulnerability was working.  To test it we needed to get some rooty command running inside of the elevated processes.  But where in the code could we insert a system() or exec() after it had obtained root privileges?

if (getuid() != 0)

    die(“wtf”, 0);

Immediately after the above set of statements we inserted the below, and recompiled.

system(“echo \”awesome\” > /FINISH_LINE.txt”);

After executing the exploit one last time we then issued a ‘ls -al /’ and found that the size of FINISH_LINE.txt had changed.

– All your base are belong to us