Thursday, October 30, 2008

Fuzzing 101 - Introduction to Fuzzing

I've spent most of today running Security Brigade's Proprietary Fuzzing Application under a variety of situations and conditions to find some very interesting vulnerabilities in a wide-range of products.

Some of the products I've run it against yet are: Rediff's Toolbar for Internet Explorer, Microsoft Outlook 2007 and Mozilla Thunderbird; All of which have some very interesting vulnerabilities ranging from Denial-of-service to Buffer Overflows.

I will not be going into detail about these vulnerabilities in this posts as I will wait for vendor responses and patch releases before I do so. However, I do want to talk about Fuzzing in general.

What is a Fuzzer?
A Security fuzzer is a tool used by security professionals to test the parameters of an application. Typical fuzzers test an application for buffer overflows, format string vulnerabilities, and error handling. More advanced fuzzers incorporate functionality to test for directory traversal attacks, command execution vulnerabilities, SQL Injection and Cross Site Scripting vulnerabilities.

Common Fuzzing Tools
There are many publicly available and open-source fuzzing applications that are designed for various purposes. Some of these are:

antiparser -Written in Python, simple and limited fuzzing framework.
Autodafe - Can be perceived as a more powerful version of SPIKE. It’s main contribution is the introduction of a UNIX-based debugging agent capable of weighting the possibility of a crash on any given fuzz input.
AxMan - A web-based ActiveX fuzzing engine written by HD Moore.
bugger - A Linux in-process fuzzer written by Michal Zalewski.
COMRaider - A Windows GUI fuzzer written by David Zimmer, designed to fuzz COM Object Interfaces.
Dfuz -sWritten in C, exposes a custom and easy to use scripting language for fuzzer development.
DOM-Hanoi - Written by H D Moore and Aviv Raff, it is designed to identify common DHTML implementation flaws by adding/removing DOM elements
eFuzz - A generic TCP/IP protocol fuzzer. Easy to use, but maybe not as full featured as some others on this list.
Evolutionary Fuzzing System (EFS) -A fuzzer which attempts to dynamically learn a protocol using code coverage and other feedback mechanisms.
FileH-A haskell-based file fuzzer that generates mutated files from a list of source files and feeds them to an external program in batches.
FileFuzz - A file format fuzzer for PE (Windows) binaries from iDefense.
FileP-A python-based file fuzzer that generates mutated files from a list of source files and feeds them to an external program in batches.
Fuzzled -A Perl based generic fuzzing framework.
Fuzz - The ORIGINAL fuzzer developed by Dr. Barton Miller.
General Purpose Fuzzer (GPF) - Written in C, GPF has a number of modes ranging from simple pure random fuzzing to more complex protocol tokenization.
hamachi -Written by H D Moore and Aviv Raff, Hamachi will look for common DHTML implementation flaws by specifying common “bad” values for method arguments and property values.
(L)ibrary (E)xploit API - lxapi - A collection of python scripts for fuzzing.
mangleme -An automated broken HTML generator and browser tester, originally used to find dozens of security and reliability problems in all major Web browsers.
notSPIKFile - A ELF fuzzer closely related to FileFuzz, instead of using SPIKE as a starting point.
Peach -Written in Python, an advanced and robust fuzzing framework which successfully separates and abstracts relevant concepts. Learning curve is a bit overwhelming.
Protocol Informatics - Slides, whitepaper and code from the last publicly seen snapshot from Marshall Beddoe’s work.
PROTOS WAP - A fuzzer from the PROTOS project for fuzzing WAP.
PROTOS HTTP-reply - Another fuzzer from the PROTOS dudes for attack HTTP responses, useful for broswer vulns.
PROTOS LDAP - For fuzzing LDAP, not as successful as the others from the PROTOS project
PROTOS SNMP - Classic SNMP fuzzer, found a vuln in almost every networking gear available at the time (2002).
PROTOS SIP - For fuzzing all those new VOIP SIP devices you see everywhere.
PROTOS ISAKMP - For attacking IPSec implementations
RIOT & faultmon - For attacking plain text protocols (Telnet, HTTP, SMTP). Used by Riley Hassell when he worked at eEye to discover the IIS .printer overflow and included in The Shellcoder's Handbook.
QueFuzz - Small fuzzer that uses libnetfilter queue to take in packets from iptables. It’s fuzzing engine either randomly fuzzes binary or ASCII protocols or uses a basic fuzzing template to search and replace packet data.
Schemer - XML driven generic file and protocol fuzzer.
Screaming Cobra - Name makes the fuzzer sound better than it really is, but is good for finding CGI bugs. Also, its a perl scrpt so easy to modify or extend.
SMUDGE - Pure Python network protocol fuzzer from nd@felincemenace.
SPIKE - Written in C, exposes a custom API for fuzzer development.
SPIKEFile - Another file format fuzzer for attacking ELF (Linux) binaries from iDefense.
Tag Brute Forcer - Awesome fuzzer from Drew Copley at eEye for attacking all of those custom ActiveX applications.
TAOF (The Art of Fuzzing) - Written in Python, a cross-platform GUI driven network protocol fuzzing environment for both UNIX and Windows systems.
WebFuzzer - A fuzzer for web application vulnerabilities.

My personal favourite Fuzzing utilities are SPIKE, Axman and Peach.

Thursday, October 16, 2008

Hackers Compromise the World Bank - Reflections on Indian IT Security

According to this article from the USA Today, Hackers broke into 18 Servers at the World Bank and had access to and possibly stole sensitive information from at-least 5 of the servers. Indian Banks have been relatively lucky, facing a majority of phishing/scam attacks rather then out-right "Hack" attempts from skilled organized criminals such as these.

Throughout my time as a Security Professional whenever discussing Financial Fraud, Phishing and other attacks faced by Banks & Financial Institutions, I have always been of the opinion that they will soon face much more devastating attacks that will make the current attempts pale in comparison.

Why the pessimistic view? Well its simple.

Attackers have always been "creative" coming up with new and complicated schemes in-order to get access to Credit-Card details and Banking Information. The reason they have the time and ability to do so is: Economics. Bottom-line is that most of these attackers are walking away with fistfuls of money at the expense of Banks and their Customers.

If we consider a typical phishing scam, an attacker would send out a million e-mails (approximation) with a success rate at best of 1% (a very generous number considering that a good percent would be picked up by Anti-Spam, Anti-phishing, Mistargeted Users, Smart Users etc) they will walk away with 10000 working banking details.

Instead if the attacker starts targeting servers belonging to Banks, systems belonging to Bank Employees and more importantly any of the thousands of Indian Shopping web-sites with Exposed Customer Information, SQL Injection vulnerabilities etc they could walk away with 100K - 200K Credit-Card details or Banking Information.

As a matter of fact, last week, a colleague of mine ordered for a product from one of the most popular Indian Shopping Portals. When the product was delivered; the label was a print-out invoice at the bottom of which was the URL: http://shopping-website/ecommerce/admin/vieworders.php. After typing this into the browser we were shown WITHOUT AUTHENTICATION plain-text Credit Card details, Order Information, Banking Details etc.

This for sure is one reason, why I do-not personally carry out Online Banking or Shopping besides for maybe on or my Bank Account with Free Fraud Insurance.

Wednesday, October 8, 2008

ClickJacking Explained

What is ClickJacking?
ClickJacking is a relatively old vulnerabilitiy that has been around since 2003-2004, however it has been recently brought back to life by Robert Hansen and Jeremiah Grossman. ClickJacking is a little bit difficult to explain however try to imagine any button that you see in your browser from the Wire Transfer Button on your Bank, Post Blog button on your blog, Add user button on your web-site etc. ClickJacking gives the attacker to ability to invisibly float these buttons on-top of other innocent looking objects in your browser. So when you try to click on the innocent object, you are actually clicking on the malicious button that is floating on top invisibly.

So while you are simply trying to close the javascript pop-up on your screen, play a flash game or interact with some ajax web-site -- you might really be clicking on the button to wire-transfer money to a russian bank account.

A slightly more technical description would be: A malicious page in domain A may create an IFRAME pointing to an application in domain B, to which the user is currently authenticated with cookies. The top-level page may then cover portions of the IFRAME with other visual elements to seamlessly hide everything but a single UI button in domain B, such as 'delete all items,' 'click to add Bob as a admin,' etc. It may then provide its own, misleading UI that implies that the button serves a different purpose and is a part of site A, inviting the user to click it.

In other words, the hacker would dupe users into visiting a malicious page -- through the usual methods -- but then hide the nasty bits under what appears to be the real-deal content from a legitimate site.

How Serious is ClickJacking?
On its own ClickJacking doesn't sound to be a very serious vulnerability, since user interaction is required. However as I have always said, in the world of vulnerabilities 1+1 does not always equal to 2, and might just equal to 10^2. By this I simply mean, that ClickJacking in combination with other vulnerabilities could become a very serious issue.

Example - ClickJacking can Spy on your Webcam and Microphone
Just as I wrote this blogpost a new use for ClickJacking has been disclosed where it can be used to spy on your Microphone and Webcam. This is based on a new vulnerability discovered in Adobe's Flash Software and published about on, Rsnake's Blog and Jerremiah Grossman's Blog.

A particular vulnerability exists in Adobe's Flash Software, which allows the malicious attacker to use ClickJacking to gain access to the user's web-cam and microphone.

The vulnerability works as follows:
1) You visit a web-page with a flash application/game embedded in it.
2) You click on the flash button.
3) Your click is "click-jacked" into allowing the server to access your web-cam and microphone.

Whatis really happening:
1) You visit the web-page, in the back the target application (in this case Adobe's Settings Panel) is loaded and made invisible. The Allow button is made to float invisibly.
2) While you click on the flash button, the invisible Allow button is floating on top of the flash button and actually receives your click.
3) The Flash application now has full permission to access your web-cam, microphone etc and even have it stream to a server where it is recorded for future viewing.

You can see a video of this in action at: Youtube and Vimeo.