SQL Injection cartoon and walkthrough
Image courtesy: xkcd.com
See how simple it can be? Now try other examples on your application under test
JavaScript MD5
Over the weekend I had a need to hack into a site to make some changes and do some testing. (It was all on the up and up, the client was aware.) At one point, I ran into a spot where I needed to work with the MD5 secure hash algorithm. I found the informaiton, resources, and the tool provided by JavaScript MD5 to be very helpful in figuring out what I needed to do.
MiniFuzz
Found a new free fuzzing tool by Microsoft called MiniFuzz. From the site:
MiniFuzz is a very simple fuzzer designed to ease adoption of fuzz testing by non-security people who are unfamiliar with file fuzzing tools or have never used them in their current software development processes.
While it's focused specifically on file-handling, it's relatively easy to get setup and use. I don't use Visual Studio, but apparently, you can also use it as a VS add-on.
Try XSS to break out of a rut
I'm again stealing a tip from David Christiansen (he's on a roll lately). Checkout his post on using cross-site scripting to get out of a testing rut. From the post:
<script>alert("f")</script>Paste it in every field.
If an alert pops up OR the field gets saved and then gets rendered without the script tags, you’ve found a cross-site scripting vulnerability.
As a side note, in a very funny turn of events, when I originally wrote this blog post I was rewarded with the following...
Looking for sensitive information
It's fairly common for applications to pass sensitive information. When testing, it's our job to make sure that sensitive information, wherever it gets passed to, is stored in a way that's (at least relatively) secured. The first thing I look for is plaintext storage of information. Some common places to look include:
- file or disk (cookies, configuration files, temp files, etc...)
- the registry
- memory
- databases
- the GUI (urls, field properties, hidden fields, etc...)
- executables (I've never reverse engineered a binary, but I know testers who do - and they find license keys, passwords, and other key pieces of information)
- or even just information going across the wire
Checking for plaintext information for the list above is trivial for everything except memory and executables - and for those you can probably setup and learn the tools in a day or two. I find I don't check those two as often, but I do check the others.
Drop the ’s’ from HTTPS
Many websites have the requirement that transactions be SSL encrypted. When this is the case, you see HTTPS instead of HTTP in the address bar, and down at the bottom of your browser, you likely see a little padlock icon that you can click to pull up information on the security certificate being used. However, for whatever reason, sometimes websites choose to implement both secure and non-secure versions of their site. Other times, the web server can be misconfigured allowing HTTP transport when it should all be HTTPS.
A quick test you can do to see if both are available is to just try dropping the 's' from HTTPS in your address bar. For an example, check out https://www.getafreelancer.com/ - the site works under both HTTP and HTTPS. (I assume that's by design, but I'm using it as an example because there aren't many sites that support HTTPS and also support HTTP at the same time.) If you can access both HTTP and HTTPS, you might want to double check your security requirements for the site and/or your web server configurations. Also, some sites have portions of the site that are HTTP while others are HTTPS. In those cases you might want to come up with some listings of what should be only HTTPS and just check those areas of the site.
Security testing tools
Foundstone (a division of McAfee) hosts a bunch of free tools on their website. These include tools that you can use to learn and practice security testing (like Hacme Bank). If you're new to security testing, consider spending some time with these tools and learning utilities.
Get user names from Word documents
When doing penetration testing, if you need user id's, you can often find them posted on public websites. Many times all you have to do is download documents (.doc, .xls, etc...) from the website and look at the properties for the document.
To find a document on a website, try something like this in Google:
site:http://www.owasp.org filetype:doc
That should return Word documents on the OWASP website. At the time of this posting, the second result from that search was "Threat modelling of pharming" by Cheong Kai Wee. If you open that document at look at the properties, you'll see the following:
There are a couple of things that can be learned from these properties:
First, it's likely the logged in user on the windows machine where this was created was "kiwi." You can see that under the template directory. So if you found this document on a companies website (instead of OWASP, which I figured would be a safe test case), you would likely have a user id for that network.
In addition, you can see that the author's name is listed as "kiwijuice." Many times this is also the user id, but sometimes I've also found that it contains good password fodder. For example, one time in the past I did this on a penetration test and found enough information to get both a username and password on the first guess.
Think about what wasn’t developed by the pros
A few years ago I was testing an e-commerce system that had just been rewritten by an outsourced vendor. I was asked to identify possible security errors in their implementation. As part of that testing, I looked at the HTML, tried some basic SQL injection, and did some URL manipulation. All the basic tests I could think of were failing. Before moving on to the big guns - setting up tools and writing some custom scripts to try different things - I decided to step back and ask some simple questions.
This site had been rewritten by a company that specialized in secure web development. Looking at the code, you could tell these guys knew there stuff. I could spend days or even weeks testing this site before I found anything. I knew that. Instead of attacking the site to get what I wanted, I asked what this outsourced team likely didn't develop. What would the company be too cheap to outsource? What would they feel like they could do themselves?
Within minutes I had a show stopper issue. I could access every item I wasn't suppose to.
The company had not outsourced the development of the search function on the site. It had been a guess. Everyone thinks they can develop a good search feature - even though few actually can. When I searched for an item to purchase, all the results came back referenced using their primary key in the database. I knew that because of the creative variable naming of "pk=". Armed with this information, I was able to do some pattern matching and noticed that the key was used in the URL in certain places. From there, I could access whatever I wanted.
Interception proxies and tampering with HTTP requests
The following tip comes from OWASP, it's a small collection of tools for interception proxies and tampering with HTTP requests. This list comes from the OWASP Testing Guide 3.0. Each tool description has been taken from it's respective website.
WebScarab: WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. It is written in Java, and is thus portable to many platforms.
Burp Proxy: Burp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications. It operates as a man-in-the-middle between the end browser and the target web server, and allows the user to intercept, inspect and modify the raw traffic passing in both directions.
Paros Proxy: Through Paros's proxy, all HTTP and HTTPS data between server and client, including cookies and form fields, can be intercepted and modified.
TamperIE: TamperIE is a useful tool for security testing your web applications, in order to ensure you don't make foolish assumptions about the data sent by client browsers. Since the tool exposes and allows tampering with otherwise inconvenient input, many user-input security flaws immediately become apparent.
Tamper Data: Use tamperdata to view and modify HTTP/HTTPS headers and post parameters. Trace and time http response/requests. Security test web applications by modifying POST parameters.
The only one I've used (and I highly recommend) is WebScarab. While writing this, I did play around a bit with Tamper Data, and I suspect I'll find a use for that tool as well in future testing efforts.
