Holly Graceful of Graceful Security created a vulnerable vm showcasing common security issues with web applications.  It is called Seattle and is an example of a home brew php web app for a record store.

First things first, lets scan the server with nmap:

Pretty new version of Apache, a quick check of CVEs reveals nothing:

While I fire up nikto, I’ll do a complete port scan to see if there is anything interesting hiding in there.

It looks like there are a couple of minor security issues here.  First off, there is an admin section of the website that is simply under /admin/.  This looks like a dead end for now.  At /info.php we get the phpinfo page.  This gives a lot of information about the version of php installed as well as server information.  Lets take a look through the browser with OWASP running.

The blog shows posts by the admin and when I click on their name I get their full email address, that’s half the information needed for a brute force login attempt.  To be honest I probably won’t be doing that considering I have no other information to trim down the password list.



I continued to look around before loading up any tools to get a lay of the land. There are three links that let you change the currency of the prices, I manipulated the query string to see what would happen and it threw an error. Now we know that errors messages are not suppressed.


The log in page has a revealing error message when testing credentials.  It gives you feedback if the username does not exists.  With information like this you can enumerate usernames.



Also, there is a download page with a local file inclusion vulnerability.


First step, lets spider with OWASP-ZAP and see what I didn’t find on the first recon.




Next, we’ll run an active scan looking for typical vulnerabilities.




OWASP-ZAP tells me that the login page may be vulnerable to sql injection so I’m going to take the http request and data to form my sqlmap attack.


Right off the bat I find out some information on the sql database:

I’ll run the command with –dbs to get a listing of databases.

Now lets look at the tables.

There’s the loot, we need to dump tblMembers table.

Oh no, the password isn’t even hashed.

user: admin@seattlesounds.net
password: Assasin1

We’re in!


Looking the the brochure now, there are a few other intentional vulnerabilities we could have played with.

  • Directory browsing in the themes folder
  • Cross site scripting to steal cookies
  • Poor cookie generation

Although we reached the goal with the vulnerable VM that Holly Graceful made I wanted to explore a little more.  I wasn’t able to get remote code execution but I wanted to enumerate database users and look for their passwords.  Sometimes this will give you access to the server if they are reusing passwords and not segregating db users and system users.

Looks like they are using the root account to admin the db.

There you have it, root:PASSWORD, unfortunately iptables is blocking SSH connections because I tested the creds at the log in prompt of the vm and I was able to log in.  If ssh was allowed and root was allowed to log in remotely we could have remotely popped the box.

I tried to get a php remote shell but I wasn’t able to pull it off.  If you can figure it out, let me know.

Seattle v0.3 Walkthrough on Vulnhub by Graceful Security
Tagged on:                 

One thought on “Seattle v0.3 Walkthrough on Vulnhub by Graceful Security

  • August 11, 2016 at 11:03 pm

    You can get root in 2 ways:
    1)via lfi at cookie[lang]
    we can upload our code at /tmp using phpinfo. just google phpinfo lfi. and then use sudo.
    2)just use ipv6 address to login ssh. ping6 ff02::1 to get address.


Leave a Reply