This is the second release in the "pWnOS" vulnerable machine collection, however, it has a different creator from the previous one (which explains why it has a different "feel" to it). As before, it has purposely built in "issues" allowing the machine to become compromised. This method uses a SQL injection flaw (see here for exploiting the PHP web application). As always with "boot2root" machines, the end goal is to become the super user, "root".
Watch video on-line:
Download video: http://download.g0tmi1k.com/videos_archive/pWnOS_2_(SQL).mp4
- Scanned the network to discover the target [Net Discover]
- Port scanned the target to determine the running services on the target [Unicorn Scan]
- Emulated the services by grabbing the banner/header of the running service(s) [NMap]
- Interacted with the web server, found a login form and entered a "default" injection statement(s), to identify a vulnerability [Firefox]
- Emulated the database which exposed information regarding the database itself, as well as the operating system [Burp proxy]
- Uploaded a PHP shell onto the target to gain remote command access into the system [Pentest Monkey PHP Shell & Burp proxy]
- Automated the same attack [SQLMap]
- Located hard coded plain text credentials, which had been re-used, allowing for complete system access
- pWnOS_v2.0.7z (md5: 1eb0960c0ba29335230ada1df80cd22c)
- A virtual machine (Example: VMware Player or Virtual Box)
- Net Discover - (Can be found in BackTrack 5)
- Unicorn Scan - (Can be found in BackTrack 5)
- NMap - (Can be found in BackTrack 5)
- Firefox - (Can be found in BackTrack 5)
- Burp Proxy - (Can be found in BackTrack 5)
- cURL - (Can be found in BackTrack 5)
- php-reverse-shell - (Can be found in BackTrack 5).
- Netcat - (Can be found in BackTrack 5)
- Tamper Data - (Can be found in BackTrack 5)
- SQLMap - (Can be found in BackTrack 5)
By reading "pWnOS_INFO-2_0.txt" (aka the readme file), the attacker discovers the IP range which the target is using, as well as the network configuration of the target (it's using a static IP address of 10.10.10.100/24). The attacker confirms the given information, by sweeping the network range and detecting a single node on the specified IP address, by using "net discover".
After the attacker has changed their IP address to match the target's subnet, they then set out to discover what services the target has publicly exposed. "Unicorn Scan" quickly scans every TCP and UDP port belonging to the target, to reveal TCP 22 (SSH) & TCP 80 (HTTP) open. The attacker chooses to verify unicorn scan findings by repeating to scan every TCP port using "nmap". At the same time as scanning, they opt to use nmap's scripting engine to start emulating the services. This allows for the attacker to gather more information relating to the target. Nmap also confirms the same ports are open, plus the default ports are used for the default services (for example SSH access on port 22 and a web server running on TCP 80). The SSH service is normally used to remotely execute commands, and, due to its nature, normally requires a form of authentication before the user can access the service, so the attacker focuses on the web server... for now!
The attacker interacts with the web server, by using "Firefox" to graphically render the web application on the target. Upon viewing the page, the attacker is presented with a form to fill in, to gain access to use the web application. On the right hand side, is a very small navigation menu to "home" (which asks the attacker to login), "register" (allowing them to gain access) and to "login" (same as "home" link). In the login prompt, the attacker fills in the first field (the email address), with a single quote "'" and the password as "123". The justification for this is when web applications normally interact with backend databases; the command used to query the database consists of single quotes, around the variable(s). By adding an additional single quote, the attacker is able to see if the input fields have been sanitized (escaping and filtering values), which would protect the query command from being altered. The result of adding an extra single quote has led to the query command being left "open" as it hasn't got a closing/matching quote, that means the database can't be queried which causes an error. Because of the way the web application has been created and the web server is configured, the end user is displayed as an error message (and by the looks of it a very detailed 'debug' message which is used for developing applications). Inside the error message, it displays the failed query command which was sent to the database, this makes crafting an input value, to manipulate the database how the attacker chooses, very easy.
As the attacker is going to be sending multiple requests to the target, in order to emulate the database, they use "burp proxy" to help construct the attack. The attacker starts burp to behave as a proxy, capturing all the data which will be sent through it, without modifying any requests. Afterwards the attacker then changes firefox's network settings to use burp as the proxy, meaning all the traffic, sent and received, in firefox will be monitored by burp.
In order to perform an error based SQL injection attack, due to the hardcoded commands before the injection point, the attacker needs to emulate the table structure to use "union" to 'select'/view values to alter the perform query. The first thing the attacker needs to know is the amount of columns used in the table into which they are injecting.
The attacker goes back to the input form and enters in the email field an SQL command which is used to specify a column in the database, "ORDERY BY". Inside burp, the attacker sends the requested value to burp's "intruder" feature. The attacker selects the area in the requested field, which each time will be modified. By using the "number" payload, each request will have a different numeric value. The attacker chooses to start at 1, ending at 10 and increasing in value by 1 with each request. If the returned result isn't what the attacker was expecting, they can increase the range and repeat the request. The attacker looks at the data which was produced due to each request. They look to see which column was first requested that caused an SQL error due to a column not existing. For this web application, the value was "9", therefore there are "8" columns in the database.
The attacker tries to see if they are able to view the output value of their injected command. They now test the web application to see if it displays a certain table column in the end user's display. "Repeater" is another feature of burp, which allows for complete control and makes it easy to modify each request. The attacker crafts the query to cause a unique value to be displayed from each column from the database and they then try to see if they can locate any of the values in the web application. They soon discover that, column "4" is displayed publicly; therefore all the requests the attacker makes, which they wish to see the result of, must happen here. Using this, the attacker now discovers: the database user for the web application, the version of the MySQL and the database name being used.
The attacker progresses by instead of emulating the database, targeting the operating system. They start off by trying to discover the user accounts which have access to the system, by "loading" ("load_file") the file, "/etc/passwd", which contains various pieces of information on all the users. Upon requesting the file, the returned value is empty, which indicates to the attacker their input could have been filtered. A possible method of getting around this issue is to change the format of the requested filename to hex. Using the "decoder" feature in burp, the attacker converts the value into "ASCII hex". After placing the encoded value in the request, the attacker is now shown the contents of the file. Now using this method to read files, the attacker makes various requests to other files which could help them to understand how the target's operating system works. The first file they try to access uses a wild card value, "*", which returns all the matching values, however, like before, when the attacker didn't use hex, the value returned was blank. Using their own system to match the wildcard value they attempt the request again. This time it succeeds, showing the operating system type and version. (Editor's note: see here for more possible values).
As the attacker now knows the operating system & software used and their versions, they try to read the default paths for their configuration files of the web server. By doing so, the attacker now knows the physical location of the web root folder on the operating system (as it turns out, it's also the default location).
With the information gathered, the attacker tries to write their own file to the target in the web root folder. This would be accessible via the web service. In order for this to work, the database user needs to have permission to write files, as well as the web root folder being writable to MySQL user. The attacker hasn't checked to see if they have either permissions, however, they still try to write a simple PHP file, which when executed, performs the given command and displays the output (See passthru). Upon calling the file from the web server, along with the command, to display the current user, the attacker sees the result. This allows for the attacker to now execute commands with the same privileges as the web service.
The attacker now wishes to upgrade their method of executing commands, and would like to have an interactive shell. They search to see if "netcat" is installed on the system, they discover it is. However, it is the "wrong" version for their needs. The OpenBSD version of netcat, doesn't have the "-e" argument, which allows for a program to be executed after a connection has been established, thus they are not able to create a shell using this method.
Instead, the attacker uses PHP to create a shell. Pentest Monkey's PHP reserve shell is able to connect back from the target to the attacker by using just PHP functions. The attacker makes a copy of the file, updates it so that it uses their IP address, encodes it, then writes it as a new file on the target's machine. Because it is only executed when someone visits the page, the attacker quickly creates a listener to wait for the PHP shell to connect into. After the attacker "views" the page on the target, it causes the PHP code to be executed, causing a connection back to the attacker. The result, the attacker now has a interactive shell on the target.
(Editor's note: This is optional. The method below is a repeat of the stage(s) before, but is performed in a quicker manner.) The attacker then repeats exploiting the same injection vulnerability, however using an automated tool, "sqlmap", which simplifes the process. As burp is no longer being used, the attacker removes the proxy configuration from firefox (as well as quitting burp). Before repeating to submit values into the login form again, the attacker enables the add-on, "Tamper Data" (it comes with backtrack, however, its disabled by default). This firefox add-on, allows for the attacker to easily view the header data which is sent and received from the target's web server.
By taking the value captured from tamper data, when data was submited in the login form, the attacker feeds it into SQLMap, along with which URL to use and the field which is vulnerable. As before, the attacker uses the email field as the injection point for their SQL values. This is due to the error message displayed, as the password field is being altered before its being processed by the database (the value has been hashed by a SHA1 format).
SQLMap now makes all the requests and is able to find the vulnerability, exploits it and reports back to the attacker the result, along with all the information gathered. The attacker then repeats emulating the database itself and the back end software used. The attacker makes SQLMap fully automated plus only displays the "core"/ necessarily output when requesting the "usernames" and "password" (which SQLmap tried to crack the hashes for). Afterwards the attacker requests all the database names in the MySQL server and gets sqlmap to display as much as possible to show the method in which it works. From there, the attacker then finds all the tables in the target's database, "ch16", with their field values, along with the number of entries, then the contents. After that, the attacker gains a 'SQL shell' on the target, and then reads the same user file, and lastly, ends with an 'OS shell' to gain remote command line access on the target.
Using the first interactive shell, the attacker starts to emulate the targets machine in order to escape privileges. To start with, they discover basic information relating to the operating system, such as: which user they are currently using (along with the user's group value), various information relating to the kernel (name, hostname, release, version, hardware name, processor type, hardware platform and operating system) and hostnames. They then move onto what's currently happening on the target, with network connections and running processors. Afterwards they start exploring the target's file system. After learning the current path, they check to see what files exist in the web root folder and look in "/var" (This "normally" is used for files which are "meant" to be changed when the operating system is running generally).
The attacker spots an "interesting" filename, which also happens to be duplicated in the web folder and /var folder. After viewing the contents of the file, the attacker sees the file is designed to be used for the web server to interact with the database. As a result, the file has hard coded clear text credentials in it; however, the password values differ between the files.
Due to the port scan at the start and emulating the target (its running processors and network activity), the attacker is aware the target is running an SSH service allowing for remote access into the system. The attacker views the configuration to see how the SSH service is running, and discovers that "root" login is enabled, which matches the username from the database files. At this point, the attacker tries to SSH into the box, matching the credentials in the database configuration. When they use the password from the web root folder, access is denied, however, when they use the second file from /var, they gain access into the system as the super user, root.
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 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102
- Camtasia Studio has few issues, for example; when rendering highlighted boxes, they are produced unevenly as well as inserting a few black frames in random places. There is nothing I can do about this for the moment and I will re-render it at a later date when there has been an update.
- The readme file, says this is a "pre-release" (which came out in 2011-07-04).
- The log files (*_history, /var/log/apache2/*, etc) haven't been wiped from the VM before releasing.
- "Interesting" value in the VM's CD path.
Video length: 15:53
Capture length: 59:01