Hacking your kids

Lets talk about hacking your kids! Yes those small carbon based units that crawl around on the floor, drool, and terrorize the neighbors are actually a data security risk. And its not just a risk to your reputation because little Timmy ran around all day yesterday telling the neighbors about the fight you had with mommy. There are other issues much deeper and far more damaging to your privacy.

Here are the security threats I found relevant recently.
Scenario 1 (Your kids are the back door)
Recently while conducting a pen test of a web application we were able to escalate our privileges and gain access to the entire database though a SQL injection vulnerability. My colleague says "hey this username looks really familiar. I think I know this guy." So we query his password as part of the evidence we need to make our case that SQL injection really is bad. (Upper management does not always agree unless you can give them shock and awe). Once the password is revealed, all is made clear how my colleague knows this user. His wife happens to be involved in a social event where this user's kid also belongs. This particular password is a maneuver the kid performs in a sport he is interested in. It was the combination of the sport plus a significant date in the users life. To make matters worse it was also his kids myspace page screen name!!!! Just knowing a little information about this user would make it relatively easy to gain access to this account. Kids are your life and you can't help talking about them and their interests. This is also why they don't make good passwords!

Scenario 2 (Babies are bugging my house!)
I know quite alot of people with babies right now. Its my age bracket for sure. They are everywhere! Crawling, drooling, spitting up, and listening for bad habits to pick up on. But one thing that is also common about all people that have babies is baby monitors. And some people never think to turn the base off! Who needs the patriot act when you have wireless communications bleeding into the neighborhood voluntarily. This is the incident that inspired me to write this article. We where listening in on the conversation with the baby monitor and it becomes apparent that this user is talking to his credit card company about a dispute. We are given the cvv, the full number, SSN and his address which should not be hard to find since you know its within a one or 2 house radius. And lets say you don't know the address and you want to find it. Here are the clues.... look for parents with babies, toys in the yard, or pretend to be a Jehovah's Witness and walk door to door. Your friend sitting in the car with the baby monitor will hear the knock on the door and then you will know.

Conclusion
I know i'm prolly speaking to the choir for anyone actually reading this but here is my advice. Be careful about the information you use to protect your self. Use strong passwords letters numbers and special characters if you can. I like passphrases. They are much harder to guess or brute-force and it makes it easier to remember a 30 character password this way. (i.e. IL1k32B10ggAb0tP3nT3st1n9 ). Try not to use anything as a password that is really important to you. More than likely you talk about it alot and your kid is blogging about it. A little reconnaissance and you are pwnd! Be careful what you say around the baby monitor base. This should be obvious. Anyone within at least a 2 house radius can hear you if they want to.

Slashdot It!

Pen Testing Web Applications 101

There are several tools that should be in every web application pen testers tool kit. I will spend a little time talking about each of these and what functions they perform. I cannot hope to cover all the topics of Web App Pen Testing in one blog post. This is my essential list of tools that is use. If anyone has any ideas or thinks i may missed anything then please add it to the comments. Id love to know what other people use and think is relevant. If you are new to pen testing web apps then this post should get you started.

FireFox
My main tool to start pen testing a web application is FireFox, loaded down with a ton of extensions. You have to interact with the application as a user and not just turn your favorite scanner loose on it. I have never found anything with a scanner that i would not have found by manually testing the application. I have, however, found many more vulnerabilities that the scanners could never dream of. My list of extensions follows:

1. TamperData - Its a quick and dirty local proxy that allows you to intercept requests and modify them before submitting them to the server.
   
2. WebDeveloper Tool Bar - Essential. Allows you quick access to view page source, see form details, display and modify hidden fields, etc.
   
3. Add N Edit Cookies - Great for cookie poisoning... it allows you to edit cookies. Nuff said.
4. ShowIP- Displays the ip address of the server you are connected to as well as hot links to tools on dnsStuff.com.
   
5. FoxyProxy - Allows you to switch proxies on the fly or by pattern. I don't know what i would do with out this. I use it to switch between my corp proxy at work and home, WebScarab or Burp, create patterns so that the site i'm testing always goes though WebScarab but any other site goes direct.

Proxies
A local proxy is essential for testing any web application. These allow you to perform a Man In the Middle attack on your own browser session. This is useful in bypassing client side validations like limiting the number of characters in an inputbox or javasctipt that checks for numeric only characters. These also allow you to poison cookies, change GET to POST, tamper with the Headers, add POST parameters, modify hidden fields, any part of the http request can be modified before submitting it to the server. Below is a list of proxies i prefer.

1. WebScarab - allows importing of WSDL's for fuzzing web services, spider functionality , manual requests, and session id analysis, encoding/decoding features.
   
2. Burp Suite - spider functionality, replay requests, fuzzing features.
   
3. TamperData - more limited of the 3 but has some great features. Do not have to change your proxy setting to use it, has XSS and SQL injection presets, encoding/decoding features. Does not have functionality to modify raw http requests.
   

Other OpenSource Tools

1. Nikto - Looks for vulnerabilities in web servers.
   
2. w3af - Web Attack and Auditing Framework. Im still testing this out at the moment. It provides checks for common web application vulnerabilities like SQL injection, XSS, url guessing, etc and generates an html report on the findings.
   
3. netcat - a networking utility to read and write data to network connections.
   

Gray Matter
This is the most important tool. Really understand how the application is built and what technologies it employs. Understand the authorization model, what type of data does the application handle, how is it stored, who has access to the data, what are all the possible entry points into the application (i.e. flat files, external databases, JMS...), what is the password policy, how many failed login attempts before lockout, are there audit and logging mechanizes. You have to understand the box to think outside of it.

Fuzzing
Error messages are your friend. Try using all the tools above to inject data into the application that it is not expecting and see how it reacts. If you have source code then you can see what will work and what will not. Try to forcefully browse to urls that are either outside your role or without even logging in. I have been granted access to all the admin features of many applications just because the developers didn't think that people can guess URLs and did not validate the sessions before performing updates.
Look for urls that update data. Try injecting SQL characters link a tick mark into the POST parameters of these and observe how the application reacts. Always try logging in with pwnd' OR 1=1 -- or a variation like pwnd' OR '1'='1' and rownum=1 -- .
Study how the application is using cookies and sessions. How much data is stored server side vs client side(i.e. browser). Anything sent to the client can be modified before resubmitting it to the server.


I hope this in informative to some people. This is what seems to work well for me. Again i would love to hear about what other people use so please feel free to leave comments.

Slashdot It!

Cross Site Tracing

Overview
When i first discovered XST I thought this seems really bad. TRACE is a method accepted by the web server like GET, POST, etc but TRACE basically echoes back the htttp data that you throw at it. Its usually used for debugging and should not be enabled on your production environment after it has been loaded. Since it echoes back the request, it is highly susceptible to Cross Site Scripting. The Goal here is to collect the users session cookie.

The problem is that I cannot think of a way that a user could be mis-lead into executing a XST vulnerability that would be advantagous to the attacker. There are a couple of ways to execute XST... Java sockets, Microsoft.XMLHTTP activeX object, and Flash. The problem with Java sockets is that they will create their own connections separate from the browser and therefore not transmit cookies or sessions. It seems possible with the other two but all three seem to need an existing XSS vulnerability. The only thing that XST gets you is the possibility to steal httpOnly cookies. HttpOnly cookies are not accessible with javascript. To me the real vulnerability would be the XSS and not the XST.


How to test if your server is vulnerable to XST.
To test if your server is vulnerable I will use Burp Suite. Open Burp and choose repeater. Change the request to something similar to :
TRACE / HTTP/1.0
Header1: <script>alert(document.cookie);</script>

The reply should look like this if TRACE is enabled:

HTTP/1.1 200 OK
Date: Sun, 23 Sep 2007 02:48:05 GMT
Server: Apache/1.3.34 (Ubuntu) mod_perl/1.29
Connection: close
Content-Type: message/http

TRACE / HTTP/1.0
Header1: <script>alert(document.cookie);</script>






If you use WebScarab as your proxy then select Manual Request and perform the same steps.

Defenses
Prevention of this vulnerability is really simple. If your using apache then you need to install the mod_rewrite engine. Add the following lines to your httpd.conf file.

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]

If your using IIS then you need to filter out everything but GET, POST, and HEAD with urlScan

References
http://msdn2.microsoft.com/en-us/library/ms533046.aspx
http://jeremiahgrossman.blogspot.com/2007/04/xst-lives-bypassing-httponly.html
http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html
http://www.microsoft.com/technet/security/tools/urlscan.mspx

Slashdot It!