It’s been a while since my last post. Work and other commitments getting in the way unfortunately. But continuing the De-ICE series here’s my solution to gaining root for De-ICE S1.120
Here’s my solution to De-ICE S1.120.
1. Run the following command from Backtrack nmap -A 192.168.1.120
2. Enumerate and investigate services and ports
ftp – permits anonymous. Log in and examine folder structure. Folder incoming is present but there is nothing in it
http – open http service through firefox and there is a simple set of web pages to add and view products. Add in a product and then view the product through the browser. URL created by the web pages looks like a candidate for further investigation for SQL injection attacks.
mysql – telnet and net cat attempts to log onto this service are rejected. Mysql is blocking remote access to it’s database.
3. From this initial trawl, the web site looks the most promising for an attack. Add two products, go to ‘View Products’ and select on of the products from the drop-down list. Here’s the URL that is generated: http://192.168.1.120/products.php?id=1. I altered this URL to read: http://192.168.1.120/products.php?id=1 or 1=1. This returns both products I entered. Assuming for a moment that all fields are being returned from the database this URL translates into SQL is follows: SELECT * FROM table_name WHERE column_name = 1 OR 1=1. The column_name field will field the id of the product we added. However by adding the OR clause of 1=1 (which is always true), the SQL query will return true on every row in the table and therefore display all records in the table holding products table. This is proof that SQL for this application is not being validated or is running some simple in-line queries embedded in the code. Either way it’s open to an SQL injection attack.
4. I’m going to use a tool called sqlmap to carry out an automated SQL injection attack on the victim machine. To access the tool in Backtrack 5 R3 go to, cd /pentest/database/sqlmap. The first thing I’m going to do is gather as much information and data from the database as I can using sqlmap.
5. The command below will return what the database the website is using and what user it is logging into the db as:
./sqlmap.py -u “http://192.168.1.120/products.php?id=1” -b –current-db –current-user
-u, Target URL
-b, Retrieve DBMS banner
–current-db, Retrieve current database name
–current-user, Retrieve current databse user
The website is using a database called merch and is logged is the user webapp
6. The command below will return all users in the merch database, and attempt to unhash the users passwords. When prompted to perform a Dictionary Attack, type Y. When prompted on what dictionary do you want to use, accept default and hit enter. When prompted do you want to use common password suffixes, accept default N and hit enter. attack begins.
./sqlmap.py -u “http://192.168.1.120/products.php?id=1″ –string=”Surname” –users –password
-u, Target URL
–cookie, HTTP Cookie header
-string, Provide a string set that is always present after valid or invalid query.
–users, list database management system users
–password, list database management password for system users.
The end result of this attack is quiet promising. sqlmap has returned a list of users and there passwords. I save these into a file for later user.
7. As a first tilt at the ssh service I take the user aadams (the most senior sys admin from the previous challenges) and use the password from the sqlmpa sweep blahblah and try to log in. Surprisingly this fails with a permission denied.
8. I then separate the usernames and passwords from the sqlmap sweep and run these against the ssh service using hyrda with the command:
hydra -L users.txt -P passwords.txt 192.168.1.120 ssh
This is much more promising and hyrda returns a list of users and there associated passwords. I’m going to focus on the three system administrators initially. Log in through ssh as those accounts and see if I can find interesting.
9. logged in through ssh as aadams and bbanter and didn’t find anything particularly interesting. Both have normal user accounts on the victim box and neither are part of the sudo’ers list (sudo -l)
10. the user ccoffee is more interesting. ccoffee has sudo privileges. The privilege is strict and very exact but ccoffee is permitted to run a script (getlogs.sh) as the root user. What this means is that anything process kicked off from this script will run under the owning process – which in this case is root.
11. if you attempt to edit the current file getlogs.sh you will get a permission denied error. This is because this file is owned by root, and only root can edit it. To get around this rename the file, to something like getlogs.sh.root. (mv getlogs.sh getlogs.sh.root). Now create a new file getlogs.sh. Although this file is owned by ccoffee and under normal circumstances would run under his account. Because of this line in the sudo’ers list.User ccoffee may run the following commands on this host:
(root) NOPASSWD: /home/ccoffee/scripts/getlogs.sh
if you type in the exact location of the file it will run the file under the root account, and thereby gaining access to root privileges. All we need to do is to add the lines below to open a bash script. I initially typed in the following into the new file getlogs.sh:
Once again, don’t forget to give execute permissions on this file (chmod +x getlogs.sh)
12. run this file now with the exact command permitted in the sudo privileges. (sudo /home/ccoffee/scripts/getlogs.sh). I now have root access on the victim machine. The hints section for this challenge says to look for ‘internal documents’. I ran the following commands on the server
find /home -mount -iname “*”.dat
find /home -mount -iname “*”.txt
find /home -mount -iname “*”.csv
find /home -mount -iname “*”.doc
(-mount): ignore mounted drives
(-inmae): search for both upper and lower-case
(.): search from the root down
The results of the .doc and .txt return a number of interal documents. The most interesting of which seem to be /home/ktso/personnel.doc and /home/jdavenport/company_address.txt Both are related to reasonably confidential detail about and for the company.
13. With that the challenge is over