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.
Watch video on-line:
Download video: http://download.g0tmi1k.com/videos_archive/Hackademic-RTB1.mp4
- 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?]
- 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.
After navigating to the default location of the admin panel, the attacker is able to test out the acquired admin credentials. As a result the attacker now has full control over the blog software (as well as access to the database). The attacker notices that file uploads have been disabled. However instead of enabling them (as well as altering the allowed file types), the attacker opts to edit an un-used plugin instead. The justification of this is once the file has been edited, it's automatically removed from the plugin list so it is less obvious than altered settings which the attacker believes the admin would notice before wanting to enable the plugin again. Also the attacker believes there is a higher chance the admin will check the upload folder rather than checking the files in the plugin folder to the plugin list. The attacker chooses the plugin "textile 1" to replace. Editor's note: Instead of overwriting the file, it could be possible to amend the code at the end, leaving the existing functionality intact.
"php-reverse-shell" by pentest monkey is an interactive shell which is spawned when the PHP code is executed. The attacker copies the contents of the file and pastes it over the plugin. They then update the shell to have the attacker's IP address and a different port. Upon saving the updated plugin with the modified web shell code, when the attacker checks the list of plugins, they discover it has been removed (which also means they are unable to edit the file any more). As the nature is a reverse connection, the attacker needs to have a listener waiting on the same port to catch the request from the web shell when the PHP function is called from the target. The attacker sets up "netcat" to be the listener and then triggers their plugin. The attacker is then able to interact with the target with a command line interface running as the same permission as the web server.
The attacker now tries to escape privileges in-which to gain higher level of access into the system. One common method is by exploiting the kernel (ONLY if it is vulnerable!). The attacker finds the current kernel version out and again searches their local copy exploit-db. The attacker discovers a potential exploit that could work with the kernel version. The attacker checks that the exploit code doesn't contain any 'non-code' which would stop the file from compiling, then copies a version to their local web root folder, remove the 'non-code', gives permission to the file to make sure every user has access to the file and then starts a web server.
Controlling the target the attacker locates a folder which they have the permission to write to and execute files from. Upon entering such a path the attacker instructs the target to download the exploit code from the attacker and compile it. After executing the exploit the attacker has now got root access to the target. They then move to the root's personal home folder to locate & view the "key" file which was mentioned in the message at the start of the attack.
Upon exploring the rest of the file system, the attacker also noticed other 'sensitive' data on the target's machine. For example, bash commands which had been perversity been entered as root by another user earlier, as well as deleted files which were in the trash folder that hasn't yet been removed.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84
- When starting the VM for the first time with VMware, select "I Moved It" - otherwise it could cause issues (e.g. the target will not be visible!).
- Some mistakes in the video are more obvious.
- Instead of using "php-reverse-shell" & "netcat", "PHP Meterpreter" & "Metasploit" could of been used.
- It is worth downloading wordpress to be familiar with a default configuration.
- The target uses DHCP to obtain an IP address.
- The selection area to record was not in align when I recorded it
Video length: 14:06
Capture length: 71:19