Watch video on-line: http://blip.tv/g0tmi1k/hackademic-rtb1-5866864
Download video: http://www.mediafire.com/?9d45sfd7j8m531t
Hackademic is the first in a collection of "boot-to-root" operating systems which has purposely designed weakness(es) built into it. The user's end goal is to interact with it and get the highest user privilege they can.
- Scanned network for the target [NetDiscover]
- Port scanned the target [UnicornScan]
- Banner grabbed the services running on the open port(s) [NMap]
- Interacted with the web server & enumerated the web application [Firefox & WPScan]
- Discovered & exploit an SQL injection vulnerably and download the configuration files [Exploit-DB & SQLMap]
- Brute Force the user credentials for the web application [John The Ripper]
- Hijacked a plugin for the the web application with a web shell backdoor [Pentestmonkey's Php-Reverse-Shell]
- Escalated privileges via a vulnerable kernel version [RDS Protocol exploit]
- Accessed the 'flag' [Text file]
- Discovered other 'interesting files' [Forensics analysis?]
What do I need?
- Hackademic.RTB1.zip (MD5: C972E899A8B5A745963BEF78FBCAEC6F).
- A virtual machine (Example: VMware Player or Virtual Box).
- NetDiscover – (Can be found in BackTrack 5).
- UnicornScan – (Can be found in BackTrack 5's repository).
- NMap – (Can be found in BackTrack 5).
- Firefox – (Can be found in BackTrack 5).
- WPScan – (Can be found in BackTrack 5's repository).
- SQLMap – (Can be found in BackTrack 5).
- John The Ripper – (Can be found in BackTrack 5).
- php-reverse-shell – (Can be found in BackTrack 5).
- NetCat – (Can be found in BackTrack 5).
- RDS Protocol – (Found on exploit-db.com & Can be found in BackTrack 5).
To start the attack, the target needs to be located. By using "NetDiscover" it is able to quickly list all IP's, Media Access Control (MAC) addresses and known vendors in the same subnet. As the attacker knows that the target is using VMware and the target hasn't spoofed their MAC address, they notice only one VMware vendor therefore they can successfully identify the target.
The attacker now concentrates on the target's single IP address by port scanning every TCP and UDP port. "UnicornScan" reported one open port, TCP 80 (HTTP), which the attacker then verifies by using "nmap". During the port scan the attacker uses nmap's scripting engine to detect the service on the port (which is a web server) and banner grab (which possible enumerates software and it's version). Depending on the outcome of the scan, nmap then executes other scripts. In this instance the http methods were detected (which shows what options are supported by an HTTP server) along with the page's title. Nmap also tries to fingerprint the operating system (Linux 2.6.22-2.6.36).
By inspecting the web service the attacker is able to see if any web application is running and if they are able to interact with it. The web server responds when the attacker views the contents using "firefox". They are then presented with a page that has a message from the target's author forwarding them along to another page. Upon following the link, the attacker then views the blog. By viewing the page source code the attacker notices a possible web product that could be used to power the blog along with its version.
To confirm their findings the attacker installs and runs "wpscan", which is a vulnerability scanner specifically designed for the blogging software, wordpress. This program will automate the process of identifying known vulnerabilities using various different techniques. WPScan confirms its wordpress and its version along with a known vulnerability.
The attacker searches a public exploit database, "exploit-db", to see if they are able to find the exploit which was mentioned in wpscan. The database returned six exploits for wordpress. The attacker views the content of the first exploit code to discover how it functions. Editor's note: When executing the exploit and targeting the target, the exploit didn't work, same with the exploit reported by wpscan.
The attacker moves back to firefox and using the exploit code, manually tests for the same SQL injection vulnerability. Upon requesting the malformed URL with the injection code present, the attacker notices an SQL error message on the side, therefore confirming that the web application is vulnerable. The attacker then starts the process of SQL injection. To start off with the attacker needs to know the number of columns within the query that is to be injected into, which is done by increasing the value tested by 1 until they reach an error. Once the amount is known, they need to be able to locate the output of the SQL query on the page. Once this is done the attacker is able to start enumerating the back end database, by finding out the version, current user and current database in use. They are also able to read files locally (as long as the database service has permission to do so) on the server too, by encoding the filename into base64.
To speed up the SQL injection process, the attacker switches to "SQLMap" which automates a lot of the work. The attacker repeats what was done before manually now with sqlmap automatically to demonstrate how simpler the process now is. At the same time they collect hashed passwords to the database. The attacker continues by trying to view the web server configuration file(s). They start off by locating their local file, to see if it matches the targets and attempts to access it - which fails. They keep trying to access other possible default locations (source) until they are successful. After viewing the file the attacker now knows the local path of the root folder for the web server. From here the attacker wants to download the configuration file which is used for the blog software. As the blog needs to store the credentials to the database to be able to access it, the attacker tries the default filename for wordpress that contains the configuration. After sqlmap downloads the file, the attacker now has the credentials in plain-text to the MySQL database.
The attacker then uses the hash which was collected by SQLMap to validate the configuration file by using "John The Ripper" (which has to have the 'jumbo' patch (aka community - enhanced version) applied to support the MySQL hash format).
Now the attacker sets out to obtain the user credentials to the blog via the SQL injection. By viewing the wordpress documents, they are able to understand the Database Description. They discover there are 6 users registered and the fields used to store all their values. The attacker creates a simple loop to request each user's username and password (which is stored in a hash format). Editor's note: This could have been automated using SQLMap.
After the user's password hashes have been saved the attacker starts to brute force their passwords using a wordlist. After all the values have been tested against the hashes the attacker now has five user's passwords in plain-text. The attacker then checks the database to see each user's permission in relation to the blog. However they soon discover the one password which wasn't cracked is the administration password to the blog. They search the computer for another wordlist and attempt to see if that would crack the password - which it did. Editor's note: If the attacker wasn't able to crack the password, they could attempt to either alter another user to become an admin or create another admin account.