forked from crowell/Security-Lab
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathwalkthrough.html
1 lines (1 loc) · 21.1 KB
/
walkthrough.html
1
<html><head><title>Cybersecurity Lab</title><style type="text/css">@import url('https://themes.googleusercontent.com/fonts/css?kit=pYEwJuzr3ZMDX2Y1syVbvyys90xk6yC7BGUgJrNTTF0');ol{margin:0;padding:0}.c8{color:#666666;font-size:10pt;background-color:#00ff00}.c11{max-width:468pt;background-color:#ffffff;padding:72pt 72pt 72pt 72pt}.c5{font-size:30pt;font-family:"Consolas"}.c2{color:#999999;font-family:"Ubuntu"}.c7{color:#1155cc;text-decoration:underline}.c1{color:inherit;text-decoration:inherit}.c10{color:#ff0000}.c0{direction:ltr}.c3{font-weight:bold}.c9{text-align:center}.c6{font-family:"Consolas"}.c4{height:11pt}.title{padding-top:24pt;line-height:1.15;text-align:left;color:#000000;font-size:36pt;font-family:"Arial";font-weight:bold;padding-bottom:6pt}.subtitle{padding-top:18pt;line-height:1.15;text-align:left;color:#666666;font-style:italic;font-size:24pt;font-family:"Georgia";padding-bottom:4pt}li{color:#000000;font-size:11pt;font-family:"Arial"}p{color:#000000;font-size:11pt;margin:0;font-family:"Arial"}h1{padding-top:24pt;line-height:1.15;text-align:left;color:#000000;font-size:18pt;font-family:"Arial";font-weight:bold;padding-bottom:6pt}h2{padding-top:18pt;line-height:1.15;text-align:left;color:#000000;font-size:14pt;font-family:"Arial";font-weight:bold;padding-bottom:4pt}h3{padding-top:14pt;line-height:1.15;text-align:left;color:#666666;font-size:12pt;font-family:"Arial";font-weight:bold;padding-bottom:4pt}h4{padding-top:12pt;line-height:1.15;text-align:left;color:#666666;font-style:italic;font-size:11pt;font-family:"Arial";padding-bottom:2pt}h5{padding-top:11pt;line-height:1.15;text-align:left;color:#666666;font-size:10pt;background-color:#00ff00;font-family:"Consolas";font-weight:bold;padding-bottom:2pt}h6{padding-top:10pt;line-height:1.15;text-align:left;color:#999999;font-style:italic;font-size:10pt;font-family:"Ubuntu";padding-bottom:2pt}</style></head><body class="c11"><p class="c0 c9 title"><a name="h.d024v6f1968t"></a><span class="c5">Recon & Exploit With W3AF</span></p><h3 class="c0 c9"><a name="h.d3796dyf3n28"></a><span>A primer on W3AF, SQLi, XSS and more!</span></h3><h6 class="c0 c9"><a name="h.mnceho29al7x"></a><span>[bduong, crowell, richtia, samahmed, soptnrs]@bu.edu</span></h6><p class="c0 subtitle"><a name="h.cbiq0gm0f8g9"></a><span>Warning!</span></p><p class="c0"><span>Never ever point W3AF, sqlmap, or similar tools at databases which you do not have explicit permissions to do so. These tools can cause a lot of damage! You </span><span class="c3">can </span><span>be backtraced, and the cyber police</span><span class="c3"> will</span><span> find you!</span></p><p class="c0 subtitle"><a name="h.1q2762xqgs5w"></a><span>Key Terms: </span></p><p class="c0"><span class="c3">W3AF </span><span>- Web Application Audit and Attack Framework (</span><span class="c7"><a class="c1" href="http://w3af.sourceforge.net/">http://w3af.sourceforge.net/</a></span><span>), the main tool to be used in this lab</span></p><p class="c0"><span class="c3">SQLi </span><span>- SQL Injection. The process of “injecting” your own queries into SQL queries done by the page. See OWASP’s page for more detailed information! (</span><span class="c7"><a class="c1" href="https://www.owasp.org/index.php/SQL_Injection">https://www.owasp.org/index.php/SQL_Injection</a></span><span>)</span></p><p class="c0"><span class="c3">XSS </span><span>- Cross Site Scripting, another injection vulnerability, the process of injecting your own own javascript code into the DOM of a HTML document. See OWASP’s page for more details. (</span><span class="c7"><a class="c1" href="https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)">https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)</a></span><span>)</span></p><p class="c0 subtitle"><a name="h.uwudl3ecbnrg"></a><span>Style of this lab</span></p><p class="c0"><span>Commands to put into your shell (your local shell) will look like this </span></p><h5 class="c0"><a name="h.tsgwyz7xi54v"></a><span>vim leethax.cpp </span></h5><p class="c0"><span>As at the time of the lab it is unknown where the website will be able to be hosted, we’ll assume the host of the site is </span></p><p class="c0"><span class="c7"><a class="c1" href="http://vulnerable/">http://vulnerable/</a></span><span> </span></p><p class="c0"><span>We’ll assume that you’re using the backtrack VM in the lab, and therefore are using firefox. The plugins referenced will be firefox plugins, there probably exist similar ones for Chrome, but please don’t ever use IE or Safari.</span></p><p class="c0"><span>Comments and tips will be in this format, to let you know that there is more to research.</span></p><h6 class="c0"><a name="h.6nkqj6yt24gt"></a><span>Wow! Look at all those Bomb Flowers! Is there any way you can set them all off at once?</span></h6><p class="c0 subtitle"><a name="h.ic829jwsifgf"></a><span>Getting Started - Mapping the Site</span></p><p class="c0"><span>First things first, in finding vulnerabilities in web applications, you must know where to look. W3AF is a very powerful tool, but you don’t know where to point it or or you wouldn’t be taking this class! Good thing for us that W3AF contains a set of </span><span class="c3">discovery</span><span> plugins. Discovery plugins in W3AF are varied, some use Bing or Google spiders, which is great for live sites, and can find pages not linked from the root (but slow), and others spider the site themselves. Because the web application that we will be attacking today is not spidered by Bing or Google, we’ll use the </span><span class="c3">webSpider</span><span> plugin. </span></p><p class="c0"><span>First, fire up W3AF, from your Backtrack Linux terminal</span></p><h5 class="c0"><a name="h.r91xcir1frek"></a><span>/pentest/web/w3af/w3af_gui</span></h5><p class="c0"><span>Point “Target URL” to </span><span class="c7"><a class="c1" href="http://vulnerable/,">http://vulnerable/</a></span><span class="c3"> </span><span>and select from the </span><span class="c3">discovery</span><span> plugins, the </span><span class="c3">webSpider </span><span>plugin. Hit </span><span class="c3">Start</span><span> and let W3AF discover pages on the site. </span></p><p class="c0"><span>Go to </span><span class="c3">Results > URLs </span><span> to see the map of the website that the </span><span class="c3">webSpider</span><span> made.</span><span class="c3"> </span><span> Notice that page names, file names, and links between them are shown. Try visiting some of the pages found, login.php, members.php, register.php, and more! </span></p><h6 class="c0"><a name="h.ht2l5ipac3bg"></a><span>Sometimes there are pages that administrators don’t want spiders to visit. They keep these in a “robots.txt” file. The plugin called </span><span class="c3">robotsReader</span><span> will crawl those pages! We will not need that plugin for this lab though.</span></h6><p class="c0"><span>This site looks very cool! Let’s try to register! </span></p><p class="c0"><span>It didn’t work, signups are closed? That’s too bad, well, let’s get in by force then.</span></p><p class="c0 subtitle"><a name="h.hthfy8502nsh"></a><span>Scanning For Vulns - Audit</span></p><p class="c0"><span>If all W3AF could do was spider and find all pages of a website, it wouldn’t be of much use, would it? The framework contains plugins for all types of exploit discovery plugins, called </span><span class="c3">audit</span><span> plugins. We really want to get access to this site, and it uses PHP and some sort of database to manage login/password combinations. You could just select all of the </span><span class="c3">audit</span><span> plugins, but in this case, I’ll be nice and tell you that we’re looking for a </span><span class="c3">sqli</span><span> and </span><span class="c3">blind sqli</span><span> vulnerability. Blind sqli and sqli are the same thing, except with blind sqli, you can’t tell what’s going on! See OWASP’s page on blind sqli for more help!</span></p><p class="c0"><span>Rerun the after adding </span><span class="c3">audit > sqli</span><span> and </span><span class="c3">audit > blindsqli </span><span>plugins to your list, point W3AF at </span><span class="c7"><a class="c1" href="http://vulnerable.">http://vulnerable</a></span><span><a class="c1" href="http://vulnerable."> again. This time watch the log for </a></span><span class="c10"><a class="c1" href="http://vulnerable.">RED</a></span><span><a class="c1" href="http://vulnerable."> text. This indicates a possible vulnerability that W3AF has spotted. In this case, the </a></span><span class="c3"><a class="c1" href="http://vulnerable.">login.php</a></span><span><a class="c1" href="http://vulnerable."> page seems to be vulnerable to SQL injection. The log will be nice enough to tell you what the request type and fields were used to discover the vulnerability. In this case the type is </a></span><span class="c3"><a class="c1" href="http://vulnerable.">POST</a></span><span><a class="c1" href="http://vulnerable."> and the field appears to be </a></span><span class="c3"><a class="c1" href="http://vulnerable.">username</a></span><span><a class="c1" href="http://vulnerable.">. You can use your browser or a web proxy to issue the same request to see what happens. It is easiest in this case to just replay the post with Firefox or curl.</a></span></p><h6 class="c0"><a name="h.lgjzu3fbagt4"></a><span>The two most popular web proxies are Fiddler2 and BURP Suite. I personally like fiddler, but it is for windows only, if you’d like to try replaying the POST requests, you can try either. Burp should be built into your Backtrack VM.</span></h6><p class="c0"><span>Did you try replaying the query? Did it do anything? No? Well, it let you know that “You have an error in your SQL syntax; check the manual <snip>” That’s helpful, but doesn’t get you access...</span></p><p class="c0 subtitle"><a name="h.ibc5ocouj05g"></a><span>Exploiting the Database - Attack!</span></p><p class="c0"><span>So, W3AF said that it found some exploits, eh? That’s good, but not only does it tell you that it found some exploits, but it can actually automatically perform them! Very cool, no? Go over to the </span><span class="c3">Exploit</span><span> tab to check out what it found. Looks like </span><span class="c3">sqlmap </span><span>and </span><span class="c3">sql_webshell </span><span>exploits were found. Which one should you use? Well, W3AF also happens to have the neat feature called </span><span class="c3">Exploit All Vulns</span><span>, which is the icon with the 3 gears on it. This will exploit everything that it found. Click that, and W3AF will go through and exploit everything. After a minute or so, you should notice an entry under the </span><span class="c3">Shells</span><span> pane. Double-click your shell to get access to the sql webshell. A new window with a command prompt should spawn. You can use this shell to interact with the database. Typing </span></p><h5 class="c0"><a name="h.67k9pc5xmcrt"></a><span class="c3">help</span><span> </span></h5><p class="c0"><span>will bring up your options</span></p><p class="c0"><span class="c6">fingerprint perform an exaustive database fingerprint</span></p><p class="c0"><span class="c6">banner get database banner</span></p><p class="c0"><span class="c6">current-user get current database user</span></p><p class="c0"><span class="c6">current-db get current database name</span></p><p class="c0"><span class="c6">users get database users</span></p><p class="c0"><span class="c6">dbs get available databases</span></p><p class="c0"><span class="c6">tables [db] get available databases tables (optional: database)</span></p><p class="c0"><span class="c6">columns <table> [db] get table columns (required: table optional: database)</span></p><p class="c0"><span class="c6">dump <table> [db] dump a database table (required: -T optional: -D)</span></p><p class="c0"><span class="c6">file <FILENAME> read a specific file content</span></p><p class="c0"><span class="c6">expression <EXPRESSION> expression to evaluate</span></p><p class="c0"><span class="c6">union-check check for UNION sql injection</span></p><p class="c0"><span>The options we’ll want to use are </span><span class="c3">dbs</span><span>, to find the names of the database, </span><span class="c3">tables [db]</span><span>, to find the tables within the database, and </span><span class="c3">dump <table> [db]</span><span>, to actually dump all of the information in the database. Once we’ve dumped all of the information of the users on the database, we’ll see something like this table, just with different entries.</span></p><p class="c0 c4"><span></span></p><p class="c0"><span class="c6">Database: securelab</span></p><p class="c0 c4"><span class="c6"></span></p><p class="c0"><span class="c6">Table: users</span></p><p class="c0 c4"><span class="c6"></span></p><p class="c0"><span class="c6">[1 entry]</span></p><p class="c0 c4"><span class="c6"></span></p><p class="c0"><span class="c6">+---------------+----------------------------------+----+</span></p><p class="c0 c4"><span class="c6"></span></p><p class="c0"><span class="c6">| username | password | ID |</span></p><p class="c0 c4"><span class="c6"></span></p><p class="c0"><span class="c6">+---------------+----------------------------------+----+</span></p><p class="c0 c4"><span class="c6"></span></p><p class="c0"><span class="c6">| jeff | 166ee015c0e0934a8781e0c86a197c6e | 1 |</span></p><p class="c0 c4"><span class="c6"></span></p><p class="c0"><span class="c6">+---------------+----------------------------------+----+</span></p><p class="c0 c4"><span class="c6"></span></p><p class="c0"><span>So, we’ve got full information on the usernames and passwords in the database! This is going to be quite useful!</span></p><p class="c0"><span>It looks like these passwords are </span><span class="c3">MD5 </span><span>hashes. If they’re not </span><span class="c3">salted</span><span> then it might be easy to look them back up (hint: they’re not!). Unfortunately W3AF has no means of cracking MD5 hashes, it can’t do everything, although so far it has appeared that it can. Tools that you have seen such as </span><span class="c3">john the ripper</span><span> can when given a word list. Personally, I love the service provided by </span><span class="c7"><a class="c1" href="http://crackstation.net/">http://crackstation.net/</a></span><span> for this, as they’ve got a huge MD5 database for fast lookups. Use john, or use crackstation at your own risk.</span></p><p class="c0"><span>By now, you’ve noticed that some, but not all, of the passwords have been found. The password for </span><span class="c3">admin</span><span> doesn’t seem to have been found, which isn’t so great, but at least we’ve got some of them, maybe our new permissions will allow us to do some more, and perhaps do more. Try loggin in with one of your new passwords, you should be taken to the members page! Congratulations, you now have access to the site!</span></p><h6 class="c0"><a name="h.fopzoz7r8eaz"></a><span>That should be enough for a gentle introduction to W3AF’s sql takeover tools. Continue on for more information and to get more experience with W3AF’s tools. The next few sections will have significantly less handholding, so get ready!</span></h6><p class="c0 subtitle"><a name="h.7n4xrw15kyr1"></a><span>Session Jacking - Using the “Cookie Jar”</span></p><p class="c0"><span>Log in with one of your new found user account/password combinations, and take a look at what cookie was set by the website. Open up the </span><span class="c3">Web Developer Console</span><span> by pressing </span><span class="c3">Ctrl+Shift+K</span><span> from Firefox. Type </span></p><h5 class="c0"><a name="h.9t99lwpn6xb7"></a><span>document.cookie</span></h5><p class="c0"><span>To see what was set. You’ll see the cookie details. If we could just find a way to steal </span><span class="c3">admin</span><span>’s cookie, and set it as our own, we would be accepted as being </span><span class="c3">admin</span><span>. Wouldn’t that be nice? Well, in the next few minutes, I’m going to show you how you can do just that. </span></p><p class="c0"><span>When you logged in, surely you noticed the </span><span class="c3">shoutbox</span><span>, no? If you didn’t, then check it out! It looks like you can just type things and everyone can see it. Rumor has it that </span><span class="c3">admin</span><span> checks this page quite often. Maybe we can use that to our advantage.</span></p><h6 class="c0"><a name="h.iia5w341y6p2"></a><span>In the case that the </span><span class="c3">shoutbox</span><span> page requires login in order to visit, W3AF can use a </span><span class="c3">cookie jar</span><span> file. In this case, it won’t be required, but you can use a Firefox plugin called Cookie Export/Import to help W3AF use your cookies. We’ve made it so that you won’t need it in this lab due to time constraints.</span></h6><p class="c0"><span>Check out the </span><span class="c3">shoutbox</span><span> page. You can try posting a message. This seems fun, but how can </span><span>you possibly exploit it? Let’s go back to W3AF to see if it can figure anything out.</span></p><h6 class="c0"><a name="h.icl4j7sxlos9"></a><span>You can try to make an xss attack without using W3AF, and this case has a simple filter. W3AF can try many things to evade the filter much faster than you can.</span></h6><p class="c0"><span>Now, you can point W3AF at the page </span><span class="c7"><a class="c1" href="http://vulnerable/shout.php">http://vulnerable/shout.php</a></span><span> and turn off any </span><span class="c3">discovery </span><span>plugins. For </span><span> </span><span class="c3">audit </span><span>plugins, this time, we are going to want to use the </span><span class="c3">xss</span><span> plugin, to find </span><span class="c3">cross-site scripting</span><span> vulnerabilities. W3AF should have found a few strings that cause cross site scripting. You can play around with the parameters that it found to do different things. Keep in mind you want to steal the </span><span class="c3">cookies</span><span> of the </span><span class="c3">admin</span><span> user. There are a few ways of accomplishing that, the simplest is getting him to post his cookie back into the shoutbox. This can be accomplished by injecting the javascript code to post cookies back to the shoutbox into your </span><span class="c3">xss</span><span> string. I’ll leave that code up to you.</span></p><h6 class="c0"><a name="h.2z2u02kncx9c"></a><span>You can search for </span><span class="c3">javascript post form</span><span> for some examples of how to do this. It is quite simple code! There are other ways, such as getting the victim to submit a post request to a web page that the attacker has prepared. This would require a bit more setup, and we’re already running short on time!</span></h6><p class="c0 c4"><span></span></p><p class="c0 subtitle"><a name="h.1yce73tnjr4s"></a><span>Load Cookie - Impersonate Admin</span></p><p class="c0"><span>So, you’ve got admin’s cookie. Great, but what can you do with it? W3AF can run more scans using that as the </span><span class="c3">cookie jar</span><span> file, but in this particular site, it won’t give you any more information, I promise. Just log in to the members page using the cookie to get the satisfaction of breaking into the admin’s account! You can search for </span><span class="c3">Edit Cookies Firefox</span><span> to search for the cookie editing plugin to firefox. Chrome has a similar plugin called </span><span class="c3">Edit This Cookie</span><span> which will do the same thing. You’re now </span><span class="c3">admin. </span><span>Congratulations, and I hope you’ve gotten something out of this lab.</span></p><p class="c0 c4"><span></span></p></body></html>