The way David approached the XSS vulnerability scanning cuts down on the amount of requests being made to the web application as well as the number of false positives as compared to other scanners that I’ve checked out.

Like all web application scanners when trying to detect non-persistent XSS Grendel substitutes a known parameter value for a value that includes javascript code. As mentioned in my previous posts it might change something like this:

param=123

to something like this:

param=123/><SCRIPT>alert(’XSS’);</SCRIPT>

Generally when the scanner sees the signature included in the response (/><SCRIPT>alert(’XSS’);</SCRIPT> in the above example) then they’ll flag it as a possible XSS vulnerability.

Now for the most part a web app scanner will have many, many different XSS signatures (different javascript-type parameter substitution values) that it will try on a particular parameter value. For instance, for the sake of thoroughness a web app scanner might have 40+ different XSS signatures that it will try for each and every parameter that it records going to the application to detect XSS.

Like I mentioned most scanners are extremely inefficient and noisy in the sense that they’ll continue to submit as many requests as there are XSS signatures until it flags a particular request as being vulnerable to non-persistent XSS. So if there are 53 XSS signatures a typical scanner will submit 53 requests per parameter (again, unless it flags a request within the 53 signatures that it sends as being vulnerable).

If you’re scanning an application that has a lot of parameter values (like hundreds or thousands) being sent in a request, as most applications do, this can end up being a lot of traffic being sent to the application being scanned.

If you’re scanning a staged or development environment this usually isn’t too much of a concern but if you’re scanning a production environment – this can cause concerns. One of the biggest problems with sending out all of the XSS signatures per parameter in an application (besides bandwidth and resource saturation) is form submissions that generate emails. For certain form submissions on a number of applications, such as a “Contact Us” form the submission information is emailed to a particular person or persons within the organization who is in control of the application. This generates one email per request sent to the particular form.

This means if you have a form that has 10 parameters and your app scanner has 53 XSS signatures you’ll have at around 530 emails being sent to someone – keeping in mind this is only for XSS detection. You’re likely to have a whole lot more submissions being sent and emailed to someone when you’re scanner is looking for other issues like SQL injection vulnerabilities, CRLF vulnerabilities, directory traversal vulnerabilities, etc. At the end of the scan it’s very, very possible someone will open their mailbox and have thousands of junk emails from scanning the site.

So – what does David do different when discovering XSS with Grendel? Before throwing each XSS signature at every parameter Grendel will first send a random value (a token) as a parameter value with a fixed 4 digit prefix (keep in mind that in order for an application to be vulnerable to non-persistent XSS it first has to echo back the parameter value in the response).

So it’d be something like this:

param=fds5fds34

Each response is searched for the prefix. The fixed four digit prefix (fds5) doesn’t change throughout the scan – which makes it easier to look for tokens in responses. If the prefix is found then the six characters following it are looked up (that way you don’t have to search for every token in the response).

If Grendel sees the token being returned in a response only then will it continue to send the XSS attack signatures. This cuts down on the amount of “useless” XSS attack signature requests being made to the web server. If the application doesn’t echo back a token value – then it’s not going to be vulnerable to non-persistent XSS in the first place.

Not only is this a lot better for production sites, it cuts down on scanning time because less meaningless requests are being sent to the application.

Another thing that David has done to reduce false positives with XSS is he’s implemented the Rhino javascript engine from Mozilla into his scanner. This way a XSS vulnerabilitiy is cataloged with Grendel only if the response triggers the javascript engine to fire.

This cuts down on XSS false positives tremendously. As a neat bonus he’s included a module called input/output flow that records any request that responds with a token value – just in case there is a posibilitiy of a XSS issue being present but the supplied XSS attack signatures was not able to trigger the javascript engine.

Grendel was released at DEFCON last year and becuase of his hectic work schedule he hasn’t updated it much in the last few months but I hear he (and a few others) are working on it now and should have a new release really soon.

You can find it here: http://www.grendel-scan.com/

Cheers,

ChuckB.

However, better late than never. In the last couple of days I finally installed it on a box and I’m in the process of screwing around it and trying to learn some of its really cool and useful features.

One of the things that I’d like to do with Pai Mei is integrate it (pstalker) into my fuzzing program so I can measure code coverage when fuzzing. This is really nothing new, but I think it’ll help out my fuzzing program a lot that I have going on.

While trying to learn about Pai Mei and while installing it I came across some tutorials written by Ricardo Narvaja. I came across them on woodman’s RCE forums. These are really cool because there’s not too much as far as how-to’s or tutorials on using Pai Mei. His tutorials have been really useful to me even though they are in Spanish…

So I decided to do a bit of translating on them (just using google translate) and they came out sort of decent. One that doesn’t know Spanish could pretty much follow along using a bit of common sense, the google translation, and by looking at the screenshots and examples.

I’ve posted them here.

BTW – Ricardo, you kick ass, and thanks for your contributions to the community.

Cheers,

Chuck B.

I figured it was a bold statement when I said “I mean to build a web app scanner generally isn’t rocket science,” and I thought it might ruffle the feathers of some who have vested time into a really robust web app scanner project. Now, I’m sure that Caleb didn’t get too bothered by my post – but his response included the following “…at the surface it may seem like that but there is nothing farther from the truth. It is one of the most complicated pieces of technology I have ever had to deal with. Its not as simple as parsing out HREFs and sticking single quotes in params.”

He was referring to a scanner I referenced in sentence I wrote: “There’s actually a really good how-to write your own web app scanner in the O’Reilly book “Network Security Tools, Writing, Hacking, and Modifying Security Tools.” The code for that one is available here.” Which pretty much does – just what Caleb said it does – not too much. It’s simple and limited, but the right basic theory is there for a good and solid web app scanner.

Before I break all this down and go on – let me first say that I don’t think there’s an automated solution on the market (and there likely won’t ever be) that can find every vulnerability in your web application. There are things that scanners are good at picking up, input validation problems like xss and sql injection, directory listing stuff, CRLF injection, etc. And there are things that they aren’t too good at picking up, like logic based errors which grant you some sort of privilege escalation or give you access to something you shouldn’t have – like a sensitive file (the scanner might not know that you shouldn’t have access to that file) that is specific to that custom application.

Another metric that is typically used when judging the effectiveness of an automated web app scanner besides how well it finds vulnerabilities (and how many vulnerabilities it finds) is application coverage when crawling a site. For instance, when you are looking for vulnerabilities in an application you want to make sure that you’re looking at all of the pages and/or functionality of the application. If you (or the automated crawling functionality of a scanner) miss parts of the application and those parts of the application don’t get tested – then that’s a problem. Therefore, I always like to have a two-pronged approach when blackbox testing. I like to crawl the site manually and have a good crawler hit the application and feed the requests to a scanner, that way if one method misses something – hopefully the other method will have picked it up – this way we can be sure we’re maximizing application coverage to the best of our ability.

That being said – I don’t think that testing web apps should ever be an automated or manual kind of a process, but more of an automated and manual kind of a process (that is, if you really care about the overall security posture of your application). I don’t think there’s too many experienced web app pentesters out there who would disagree with me on that one.

However, let’s focus on some things that web app scanners are good at, like finding XSS and SQL injection vulnerabilities – and talk about possible tools (scanners) that one might use to accomplish this (for free). And with a little modification to these free tools, such as incorporating some of the concepts discussed below, one could possibly garnish better/more results (XSS, SQL injection vulnerabilities being identified) than some scanners out there that cost you thousands of dollars.

So going back to what I think scanners are good at, like fuzzing parameter values to look for things like XSS and SQL injection problems.

First off, the basic and fundamental way web app scanners work – is they essentially send a request to the application, then they look at a response to see if the request the scanner made affected the application in some way and made it send something back that it shouldn’t have (in a way that could be a potential security problem or vulnerability).

I’ll talk about a few examples that are probably the two most common (and arguably the highest impact) vulnerabilities in web applications that most scanners look for, XSS and SQL injection.

Let’s talk about XSS – the basic (easy, yet effective) way most scanners look for XSS is they send a request to the web server – and they replace or add on to the original value of the parameter with some potential javascript code – then see if it gets echoed back in a response. For example, a scanner might change something like this:

param=123

to something like this:

param=123″/><SCRIPT>alert(’XSS’);</SCRIPT>

Then they simply perform a regex on the response looking for /><SCRIPT>alert(’XSS’);</SCRIPT>. If they see it – then they’ll flag it as a possible XSS vulnerability. Really not too hard.

Now there are some applications or web app firewalls that filter things like <SCRIPT>, <IMG>, etc. so what you can do is add say, RSnake’s XSS list for filter evasion (a list of signatures) to what your scanner adds or substitutes for parameter values. Simply cycle through that list of signatures until (if and when) you come across one that gets echoed back in a response. RSnake’s cheat sheet can be used as a starter for signatures. As you play with web apps more and become more acquainted with filter evasion and XSS you can just add those to your list of signatures in your scanner.

Now I do have a friend who is working on a scanner that is a bit more sophisticated in detecting XSS, in that it will eliminate false positives and cut down on the number of overall requests (like not having to cycle through the whole list of XSS signatures on every parameter being submitted to the web application). But I told him I won’t talk about it too much until after he releases it at Def Con. However, even though his technique is more efficient – the above technique is what 99% of web app scanners do when looking for XSS – and this method works quite well, even though for some reason – there’s a lot of expensive web app scanners out there that can’t even get this part right, and manage to screw this part up somehow.

SQL injections are a little more complicated to look for in a scanner, but not much – remember, this isn’t rocket science.

There’s basically two different kind of SQL injections – regular (verbose database messages) and blind SQL injections.

To check for regular or verbose SQL injections – you send a request, like using a single tick ( ‘ ) as a parameter value, or at the end of a parameter value and look for the response.

Using our example of param=123 we might substitute the original value for something like paramm=123′1

If you get some database error message like this in the response then chalk it up as a possible SQL injection:

Microsoft OLE DB Provider for ODBC Drivers error

So there could be different back end databases that they might be using so you might want to look for other error messages from different databases other than MSSQL like Oracle, IBM DB2, MS Access, PostgreSQL, MySQL, etc.

Also, we could try different encoding on our single ticks like CHAR(39), 0xbf27, amongst others.

Besides single quotes (or ticks) we can also try to sneak in things like semi-colons ( ; ) and double dashes ( — ) and their encoded equivalents to try and generate database error messages.

Blind SQL injections are a little bit different beast in that we don’t just regex a response looking for a database error message, but rather we look for a change in behavior of some sort from the application.

There are basically two different types of blind SQL injections – conditional and time delays.

We’ll cover how to test both really quick.

For the time delay blind SQL injection detection you simply add something like this to the original parameter value:

‘;WAITFOR+DELAY+’0:0:10′– (MSSQL)

This tells the SQL backend to wait for ten seconds before responding. So a way to implement this in a scanner is you make a regular (non-fuzzed) request with no “waitfor delay” manipulation in the parameter value, then you calculate the time it took to make a regular request (let’s say it takes 950ms). Then, go ahead and send the time delay fuzzed parameter value (such as param=123′;WAITFOR+DELAY+’0:0:10′–). If you get a response right away – then, mark the parameter as not vulnerable, if you get a response from the webserver that took 10 seconds or later (you can calculate in the time it takes for the request such as the 950ms) then you can mark that as being a possible time based SQL injection vulnerability.

One can also use other time based queries for different databases other than MSSQL, such as the following:

SELECT pg_sleep(10); (PostgreSQL)

BENCHMARK() function (MySql)

Also – we could try adding parenthesis and such to escape from SQL subqueries like the following:

param=123;waitfor+delay+’0:0:10′–
param=123);waitfor+delay+’0:0:10′–
param=123′;waitfor+delay+’0:0:10′–
param=123′);waitfor+delay+’0:0:10′–
param=123));waitfor+delay+’0:0:10′–
param=123′));waitfor+delay+’0:0:10′–

Also – we would want to try the encoded equivalents of semi-colons (%3B), dashes (%2D), plus signs (%2B), etc. with all of these queries.

Next, we have conditional blind SQL injection vulnerabilities to hunt for. For this type of SQL injection vulnerability identification the scanner must also look for some behavioral change from the application.

According to webappsec.org the following is how to detect blind conditional SQL injection vulnerabilities:

A common way to detect Blind SQL Injection is to put a false and true statement into the parameter value.

Executing the following request to a web site:

http://example/article.asp?ID=2+and+1=1

should return the same web page as:

http://example/article.asp?ID=2

because the SQL statement ‘and 1=1′ is always true.

Executing the following request to a web site:

http://example/article.asp?ID=2+and+1=0

would then cause the web site to return a friendly error or no page at all. This is because the SQL statement “and 1=0″ is always false.

They’re not far off, by issuing a series of true/false type queries in a request (parameter value) then we can see if there is any difference behaviorally with the application – sometimes in a “false” query you get an error page, sometimes other types of changes in the response.

Easy enough, so for a scanner we can just do something like the following:

param=123′ and ‘1′=’1

and

param=123′ and ‘1′=’2

If we get a different page for each response – then we could chalk that up as being a possible vulnerability and worthy of looking into.

We could also use different true/false queries such as:

param=123′ or ‘a’='a

param=123′ or ‘a’='b

or even better, just substitute some random string for ‘a’ and another random string for ‘b.’

There are other things – that one could look for in (and add to) a web app scanner such as command injection, directory traversal attacks, CRLF injection, CSRF, session problems like session fixation, etc. but, again – it’s all fundamentally based on the concept of making a request to the application, then checking the response to see if the request the scanner made affected the application in some way and made it send something back that it shouldn’t have (in a way that could be a potential security problem or vulnerability).

I did mention that there was something out there that one could get for free that is a really good starting point for a good scanner. Here it is: sts-scanner. It is pretty limited in it’s functionality – much like the original ExtendedScanner, as a matter of fact it’s based on the ExtendedScanner. But with a few tweaks – like adding some more XSS signatures and adding some of the SQL injection scanning logic mentioned above (it already includes some of it, plus things like column enumeration when it finds a sql injection) – I would put money on it against any of the expensive (or non-free) web app scanners out there when it came to looking for things that it was designed to look for.

Cheers,

Chuck B.

So – if one is unfamiliar with Windows Message Handling here’s a decent brush-up:

http://www.codeproject.com/KB/dialog/messagehandling3.aspx

BTW – the following is pretty much taken from toassa (like one of the best tech books ever written): http://taossa.com/

Essentially – Windows OS’s deliver messages to windows in a FIFO queue. Messages can be generated by system events like mouse movements or key presses. They can also be generated by other threads on the same desktop. Windows messages control most aspects of the UI, including clipboard operations and properties of a window.

There are 4 essential steps in creating a functional windowed application:

1. Creating a WindowProc() function to handle messages.
2. Defining a class that associates this WindowProc() to a window type.
3. Creating an instance of the Window class.
4. Creating a message-processing loop.

Anyways, any process with a handle to a window station can send messages to any other window on a desktop object within that window station (any process can send a message to any other desktop object on the same desktop). All that’s needed is a SendMessage() function.

LRESULT SendMessage (HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam);

So this brings us to shatter attacks.

The Windows API ties a lot of functionality into a simple, unprotected, messaging architecture. Every aspect of the user interface is controlled by window messages, and the design of the API provides no method of restricting or verifying a message source.

The original shatter attack from 2002 – Chris Paget’s paper titled, “Exploiting design flaws in the Win32 API for privilege escalation“) exploited window message design by sending a WM_PASTE message to a privileged process with a message pump on the same window station. The WM_PASTE message allows attackers to place a buffer of shell code in the address space of the privileged process. The attack is then completed by sending a WM_TIMER message that includes the address of the shell code buffer. The default handler for the WM_TIMER message simply accepts the address parameter as a function pointer, then runs the code that it points to. The result is a straightforward privilege escalation.

The immediate response to the shatter vulnerability was to simply filter the WM_TIMER message in any privileged process interacting with a user’s desktop. However, there are many other messages that allow manipulation of memory in a target process.

In 2004 Brett Moore had a talk at BlackHat about this:

http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-moore/bh-us-04-moore-up.ppt

For instance, according to his whitepaper: Previous shatter attacks have been based on the use of messages that accept a pointer as a parameter. This pointer deirects execution flow to data that has been supplied by the attacer, therefore allowing the attacker to have a process execute code of their choice.

Several windows message will accept a pointer to a callback function as one of the parameters to the SendMessage API. One of these is LVM_SORTITEMS…

He also mentions messages like HDM_GETITEMRECT, which accepts a pointer to a POINT or RECT structure which will be used to retrieve GDI information about windows. These pointers do not appear to be validated in any way…

Also – he has an exploit that demonstrates the use of Progress Control message shatter attacks and discusses other vulnerable messages that can come in handy to exploit.

As a matter of fact, he discovered a more recent vulnerability in a Symantec product using a Shatter Attack (Feb. 2008):

http://www.securityfocus.com/bid/27645

For someone looking at the code of the program, toassa summarizes the following steps to identify potential shatter attack exposures for a given service:

1. Check the MMC snap-in for the service to see whether it runs as the interactive user. Use MMC -> open the Properties dialog box for the service -> check the “Log On” tab to see whether the “Allow Service to Interact with Desktop” option is selected.

2. Examine the code to determine whether it manually attaches to the interactive user’s desktop.

3. If either case is true, determine whether a message pump is in operation for receiving window messages. If a message pump is in operation, you can consider the application to be at risk.

Also, according to my favorite reference – taossa, certain COM applications can create background messages windows which can be vulnerable as well.

In Brett Moore’s Blackhat 2004 preso (which I also cited earlier) he also makes references to attacking thick applications on windows using shatter attacks – which will probably hit home a lot more for people who don’t do too much testing on traditional C/C++ programs.

Now Microsoft has done certain things to try to stop shatter attacks over the years – from Wikipedia “In December 2002, Microsoft issued a patch for Windows NT 4.0, Windows 2000, and Windows XP that closed off some avenues of exploitation. This was only a partial solution, however, as the fix was limited to services included with Windows that could be exploited using this technique;”

Also – they did some stuff with Vista using User Interface Privilege Isolation (UIPI).

So most of the vulnerable programs will be third-party applications.

Really – the most devastating scenario that I can think of – and probably the most common is someone with “normal” user privileges exploits a third-party program running as system over Terminal Servers. This would effectively give a normal, segregated user (Term. Services) control over the whole system (system privileges).

Chris Paget originally had these recommendations to solve the problem:

I can see two quick and dirty methods which will break a whole lotta functionality, and one very long-winded solution which is never going to be a total solution. Let me explain.

1. Don’t allow people to enumerate windows Nasty. Multiple breakages. Theoretically possible, but I’d hate to see people trying to work around not knowing what windows are on the desktop when they need to.

2. Don’t allow messages to pass between applications with different privileges Means that you couldn’t interact with any window on your desktop that’s not running as you; means that VirusScan at the very least (probably most personal firewalls, too) would need a whole lotta redesigning.

3. Add source info to messages, and depend on applications to decide whether or not to process the messages Would need an extension to the Win32 API, and a whole lotta work for people to use it. Big job, and people would still get it wrong. Look at buffer overflows – they’ve been around for years, and they’re still fairly common.

So what would someone do if they really wanted to build a safe (not vulnerable to shatter attacks) application that had a desktop GUI?

All would probably agree that it does make sense to run the application as one of least privilege and that might be a first thought – but that’s not always possible as some applications need to communicate to things on a privileged level and make certain system level calls.

To someone that really, really cares about it – I might recommend the following as a solution to shatter attacks for an application (This is actually from Wikipedia – don’t laugh – but I think it makes sense):

…a two-process design where a process is loaded into the user’s session that interacts with the service process through inter-process communication. Additionally, when a privileged operation is required to be undertaken, an authenticated call is made that loads additional service code. Once that privileged code is finished doing what needs to be done, it is unloaded from memory so that it does not remain in memory to be a possible target for later exploitation.

So – essentially one would need to design the window interface with lower privileges and communicate through IPC to another, more higher privileged (server) process to make the calls that require higher privileges.

Brett Moore – in his 2004 whitepaper concludes with the following (after a lot of patches that Microsoft released in 2002 to protect some system applications that the OS’s shipped with):

The exploitation of shatter attacks have come a long way from when the original vulnerability was announced. As we have shown in this document, even the most obscure of messages can be used to make a process execute code that it was not intended to run.

While there have been discussions around the filtering of messages to protect interactive applications that run under a higher security context. It is becoming apparent that the only sure solution is to not have these applications running on an untrusted users desktop.

Application designers and system administrators need to be aware of the dangers associated with running higher privileged applications on a users desktop, and take steps to prevent them from been exploited. The examples included in this paper can be used against any interactive application that runs at a higher level, simply by specifying parameters such as the window title. Successful exploitation would allow a user to then execute commands under this higher-level security context.

So Brett says there’s not too much one can do either to prevent shatter attacks (but he didn’t mention the whole thing where we can split up the program into 2 different processes and have them communicate over IPC).

Of course – this is hard to do – especially when you think your application is not vulnerable because it doesn’t have any windowing GUI’s. According to his post here, he attacked an application that didn’t even have a window – well, not normally anyways:

We discovered that [Service X], that did not normally have a window, could
be enticed into generating an error that would display a window. The
service stored a pointer to a lookup table in the window memory pointed to
by GWL_USERDATA. This lookup table held the address of functions, and was
later used to retrieve an address and pass it to a CALL instruction.

By using the process mapped heap, as explained in my Blackhat presentation,
it was possible to place our shellcode into a known location. We could also
construct a new lookup table, pointing to our shellcode, in a known
location.

Then by using SetWIndowLongPtr() API we replaced the pointer to the lookup
table with the address of our new lookup table. The service would use our
lookup table and execution would therefore reach the shellcode.

We should keep in mind as well – that it could be a whole different ballgame with Vista and Server 2008. Microsoft did a couple of things to try to fix the problem of shatter attacks (that’s a whole other post).

Although – I was just thinking a little while ago, how one could gain a name really quickly and some easy PR through this kind of research. Just find some programs that have a windowed desktop and that run with system level privilege – read up a little more about shatter attack stuff, then just publish a vulnerability like this: http://www.securityfocus.com/bid/27645. I figure it’d be a good way to get one’s name in print – this particular one (also referenced above) was just released in Feb. 08.

Cheers,

Chuck B.

http://erratasec.blogspot.com/2008/06/verizon-500-breach-report.html

Basically the data came from a report/study of 500 forensic investigations that Verizon released.

http://www.verizonbusiness.com/resources/security/databreachreport.pdf

Personally – I think the security industry is chock-full of misconceptions of the what/how/why of hackers and breaches.

While this report is interesting – the biggest problem with this report is that it’s a study drawn from 500 forensic engagements handled by the Verizon Business Investigative Response Team, which means the information is gathered from breaches and forensics engagements of large organizations (people who can afford to pay for Verizon forensics services). What’s wrong with this one might ask?

Well – in my opinion – large organizations generally have a larger security budget than say small businesses and home users – which means large organizations generally have things like regular security testing (a lot of the times by law or regulation of some sort), patch-management policies, etc. and they don’t constitute the majority of “breaches.” Sure – they’re still getting hacked, otherwise there wouldn’t be a report like this – but the majority of systems that get compromised/hacked don’t belong to large organizations that have some sort of security entity (person or department) in charge of their systems, rather it’s the small businesses and home users, such as the non-tech savvy grandmas that click on cute and free animated screen saver links from emails and web sites that get compromised. These end users – the people who most likely get hacked aren’t represented here.

Much like trying to gather statistical information from the impact of Cross-Site Scripting (or any client side exploit – which is the most predominate type of exploit these days) – gathering information or statistics on the really vulnerable systems on the internet is almost impossible. These client side exploits generally affect home users, which – by the sheer number of home users it’s really hard to gather test cases. I’d even say that most of the people/systems that have been “hacked” aren’t even aware that they were compromised (like people who lend their system to a botnet).

The thing is – when end users of an organization get hacked, like in a Cross-Site Scripting or Microsoft Office exploit it is generally the lowest-hanging fruit and can have just as much impact as the organization servers getting hacked (confidential information, personal credit card data, etc. being stolen).

This is (again, imho) the way the majority of organizations/systems get compromised these days – and this report doesn’t really take this into account – again it’s very rare that forensics engagements deal with client side breaches.

This is one of the reasons I like to follow Dancho Danchev’s blog – it’s a great peek into the latest and greatest what is “really going on” in the blackhat hacker market (motives, techniques, methodologies, etc.).

Here’s are some of the misconceptions that were talked about in the Errata sec. blog:

Misconception: Hackers target their victims.
Verizon data: 85% of attacks were “opportunistic”, the hackers didn’t know who their victims were until after they broke in.

Misconception: Certified anti-virus products detect over 99% of all viruses.
Verizon data: 25% of viruses/malware were customized to their victims and undetectable with standard anti-virus.

Misconception: Hackers are smart, clever, geniuses, wizards, etc.
Verizon data: 55% where of attacks required essentially no skills, the level of “script kiddies” running automated tools. Only 17% required “advanced” skills.

Misconception: It’s the insider threat. No, wait, it’s outsiders. No, I mean, it’s the partners.
Verizon data: 73% external, 18% internal, 39% partners. However, external breaches tended to be minor, whereas internal and partner breeches were major. Their numbers show that all three are important threats and that it’s hard to measure which one is worse.

Misconception: Numbers are definitive.
Verizon data: These numbers are bit subjective. For example, they notice that “physical breaches” were rare, but that’s because Verizon wouldn’t be called in to investigate a physical breach.

Question: What are hackers after?
Verizon data: Credit Card data (84%), Personal identity (32%), Username/passwords (15%)

Question: How old are the vulnerability exploits hackers use?
Verizon data: 71% older than 1-year, another 19% older than 6 months.

(…)
Cheers,

Chuck B.

First, here’s the definition of a Pipe from msdn: http://msdn2.microsoft.com/en-us/library/aa365780(VS.85).aspx :

A pipe is a section of shared memory that processes use for communication. The process that creates a pipe is the pipe server. A process that connects to a pipe is a pipe client. One process writes information to the pipe, then the other process reads the information from the pipe. This overview describes how to create, manage, and use pipes.

And a little more here http://msdn2.microsoft.com/en-us/library/aa365137(VS.85).aspx :

There are two types of pipes: anonymous pipes and named pipes. Anonymous pipes require less overhead than named pipes, but offer limited services.

The term pipe, as used here, implies that a pipe is used as an information conduit. Conceptually, a pipe has two ends. A one-way pipe allows the process at one end to write to the pipe, and allows the process at the other end to read from the pipe. A two-way (or duplex) pipe allows a process to read and write from its end of the pipe.

So to begin with all pipes are securable objects, so they have specific access rights associated with their DACL entries (much like files).

While looking into this topic a bit a while ago I came across this paper (Discovering and Exploiting Named Pipe Security Flaws for Fun and Profit):

http://www.blakewatts.com/namedpipepaper.html

Here’s some highlights from the paper:

A named pipe is a mechanism that enables interprocess communication for applications to communicate locally or remotely. The application that creates the pipe is known as the pipe server, and the application that connects to the pipe is known as the pipe client. Similar to sockets, after the server creates the named pipe, pipe clients may connect to the server. The function CreateNamedPipe provides the means to create the pipe. Clients use the CreateFile function to connect to the server-end of the named pipe. After the client and server have established a connection, they use the ReadFile and WriteFile functions to communicate.

The way in which named pipes are created and connected to is conceptually identical to how files are created on a file system–that’s no coincidence. Internally, named pipes are implemented as a file system (more on this later). The “file location” of creating and connecting to a pipe follows a standard naming convention. This effectively ensures that the creation and connection requests of pipes are internally routed correctly. That convention is as follows: \\.\pipe\pipename. The \\.\ segment is used to route the creation and connection of the pipe to the appropriate file system. The period in the \\.\ segment may be replaced with a remote system name. This enables the associated function to be invoked remotely.

So the above is just a bit about how pipes work and all that. But we probably need this interesting background info as well before we can really talk a lot about vulnerabilities with pipes – “Named Pipe Impersonation”:

Impersonation is the process of a pipe server temporarily assuming the security context of the client of its pipe. Pipe servers impersonate their client’s security context by calling the function ImpersonateNamedPipeClient. The requirements of impersonation are that a client connects to the pipe server and writes some data to it. After the pipe server reads the data from the client, its call to ImpesonateNamedPipeClient will succeed, and it is granted an ‘impersonation’ token of the client. The requirement of reading data from the pipe can be bypassed, and is discussed in the ‘File System Vulnerabilities’ section.

Some readers may be wondering as to why in the world would impersonation exist in an interprocess communication mechanism. Impersonation and IPC, implemented properly, can actually lead to better-designed software architecture. In its conception, it was created so that privileged subsystems and services could temporally lower their own security context while processing the requests of its clients. However, if implemented improperly malicious applications can attain full control of the system.

So this is really interesting because it leaves room for client attacks:

When a client connects to the server-end of a named pipe it may unknowingly be giving the server-end of the pipe the ability to perform any task on their behalf–by impersonating their security context. Clients can control their impersonation “level” by specifying specific flags in their CreateFile call (which is used for connecting the client to the server pipe), however is seldom performed. This process is formally known as setting the security quality of service. So the question on most readers mind is, “What if the server isn’t started, or has crashed?” Well, the answer is very simple. Their security context is up for grabs. Any security context (interactive user, service, etc.) may create the pipe that the client is looking for and assume their security context. This vulnerability classification is known as Superfluous Pipe Connectivity.

This is really interesting because through named pipe impersonation one can gain the privilege level of the client (if the client didn’t specify an impersonation level in the call to CreateFile() when creating the pipe).

Of course, we’re keeping in mind that “client” doesn’t always mean “lower privileged process.”

This type of attack lead to this (system privilege level) vulnerability (it’s actually a combination of client pipe and pipe namesquating):

Service Control Manager Named Pipe Impersonation Vulnerability (http://www.microsoft.com/technet/security/Bulletin/MS00-053.mspx)

There’s also vulnerabilities that were discovered like these:

http://secunia.com/advisories/9229/ (SQL Server Named Pipe Privilege Escalation Vulnerability)
http://www.microsoft.com/technet/security/Bulletin/MS01-031.mspx (Telnet Server Named Pipe Privilege Escalation Vulnerability)

The paper also says this:

Coaxing an application or service into connecting to a pipe is usually trivial in most situations. For instance, when starting a service, the service will typically connect to another service’s named pipe. A monitoring tool, such as Security Internals’ Pipe Security Explorer, will yield all the named pipes that an application or service connects to. It is probable that some pipes will not exist. If a client application attempts to connect to a server pipe without verifying that the server is running and has created the corresponding named pipe, it’s possible that at some point in time the client’s security context may be usurped by a malicious application.

Cheers,

Chuck B.

In short it discusses a tool he wrote called AccessChk which helps identify weak permissions problems. Apparently he had received some requests from groups within Microsoft and elsewhere to extend its coverage of securable objects analyzed to include the Object Manager namespace (which stores named mutexes, semaphores and memory-mapped files), the Service Control Manager, and named pipes.

After he had revised AccessChk he ran the tool on his box to see what system-global objects the Everyone and Users groups can modify.

As he states: The ability to change those objects almost always indicates the ability for unprivileged users to compromise other accounts, elevate to system or administrative privilege, or prevent services or programs run by the system or other users from functioning. For example, if an unprivileged user can change an executable in the %programfiles% directory they might be able to cause another user to execute their code. Some applications include Windows services, so if a user could change the service executable they could obtain system privileges.

He also played with write access from the Authenticated Users and Users groups on different namespaces. According to the blog:

An output line, which looks like “RW C:\Program Files\Vendor”, reveals a probable security flaw.
To my surprise and dismay, I found security holes in several namespaces. The security settings on one application’s global synchronization and memory mapping objects, as well as on its installation directory, allow unprivileged users to effectively shut off the application, corrupt its configuration files, and replace its executables to elevate to Local System privileges. What application has such grossly insecure permissions? Ironically, that of a top-tier security vendor.
For instance, AccessChk showed output that indicated the Users group has write access to the application’s configuration directory (note that names have been changed):
RW C:\Program Files\SecurityVendor\Config\
RW C:\Program Files\ SecurityVendor\Config\scanmaster.db
RW C:\Program Files\ SecurityVendor\Config\realtimemaster.db
…
Because Malware would run in the Users group, it could modify the configuration data or create its own version and prevent the security software from changing it. It could also watch for dynamic updates to the files and reset their contents.
For the object namespace, it reported output lines like this:
RW [Section] \basenamedobjects\12345678-abcd-1234-cdef-123456789abc
RW [Mutant] \basenamedobjects\87654321-cdab-3124-efcd-6789abc12345
…
He also states:

In the wake of my discovery, I analyzed the rest of my systems, as well as trial versions of other popular security, game, ISP and consumer applications. A number of the most popular in each category had problems similar to those of the security software installed on my development system. I felt like I was shining a flashlight under a house and finding rotten beams where I had assumed there was a sturdy foundation.

Then he kind of hit the nail on the head:

The security research community has focused its efforts uncovering local elevations via buffer overflows and unverified parameters, but has completely overlooked these obvious problems – problems often caused by the software of security ISVs, or in some cases, their own.

Now, while I’m sure that the security research hasn’t “completely overlooked these obvious problems” I would bet that it’s an area that could garnish some nice results with a bit of looking into.

Through the process of reading “The Art of Software Security Assessment” I came across a few really cool problems in software similar to this. I had heard of some of these problems before, but I hadn’t gotten into too much detail concerning them.

There are chapters in the book that go into a bit of detail on issues like this that provide a really good fundamental understanding of similar problems:

Chapter 11: Windows I: Objects and the File System
Chapter 12: Windows II: Interprocess Communication

Another cool chapter / subject is Chapter 13: Synchronization and State. It talks about Reentrancy (Reentrancy refers to a function’s capacity to work correctly, even when it’s interrupted by another running thread that calls the same function), Asynchronous-Safe Code, Signals and other things.

Most pentesters know about buffer/heap overflows, integer overflows, off-by-ones, race conditions, and similar common exploitable vulnerabilities, but what about using Signals to escalate privilege or cause a double free() in code that is not asynchronous-safe?

Here is a great paper by Michael Zalewski “Delivering Signals for Fun and Profit” that talks about this:

From the paper:

Below is a sample ‘vulnerable program’ code:

— vuln.c —
#include <signal.h>
#include <syslog.h>
#include <string.h>
#include <stdlib.h>

void *global1, *global2;
char *what;

void sh(int dummy) {
syslog(LOG_NOTICE,”%s\n”,what);
free(global2);
free(global1);
sleep(10);
exit(0);
}

int main(int argc,char* argv[]) {
what=argv[1];
global1=strdup(argv[2]);
global2=malloc(340);
signal(SIGHUP,sh);
signal(SIGTERM,sh);
sleep(10);
exit(0);
}
—- EOF —-

You can exploit it, forcing free() to be called on a memory region filled with 0×41414141 (you can see this value in the registers at the time of crash – the bytes represented as 41 in hex are set by the ‘A’ input characters in the variable $LOG below). Sample command lines for a Bash shell are:

$ gcc vuln.c -o vuln
$ PAD=`perl -e ‘{print “x”x410}’`
$ LOG=`perl -e ‘{print “A”x100}’`
$ ./vuln $LOG $PAD & sleep 1; killall -HUP vuln; sleep 1; killall -TERM vuln

The result should be a segmentation fault followed by nice core dump (for Linux glibc 2.1.9x and 2.0.7).
(gdb) back

#0 chunk_free (ar_ptr=0×4013dce0, p=0×80499a0) at malloc.c:3069
#1 0×4009b334 in __libc_free (mem=0×80499a8) at malloc.c:3043
#2 0×80485b8 in sh ()
#4 0×400d5971 in __libc_nanosleep () from /lib/libc.so.6
#5 0×400d5801 in __sleep (seconds=10) at ../sysdeps/unix/sysv/linux/sleep.c:85
#6 0×80485d6 in sh ()

So, as you can see, failure was caused when signal handler was re-entered. __libf_free function was called with a parameter of 0×080499a8, which points somewhere in the middle of our AAAs:

(gdb) x/s 0×80499a8
0×80499a8: ‘A’ <repeats 94 times>, “\n”

You can find 0×41414141 in the registers, as well, showing this data is being processed. For more analysis, please refer to the paper mentioned above.

For the description, impact and fix information on Sendmail signal handling vulnerability, please refer to the RAZOR advisory at: adv_sm8120.

Obviously, that is just an example of this attack. Whenever signal handler execution is non-atomic, attacks of this kind are possible by re-entering the handler when it is in the middle of performing non-reentrant operations. Heap damage is the most obvious vector of attack, in this case, but not the only one.

Anyways, none of this stuff is new, but it’s food for thought for anyone who wasn’t really familiar with these type of vulnerabilities.

Cheers,

Chuck B.

The web app scanner market is really odd. For some reason, the market just can’t seem to get it right. I’ve worked at places that have had head-to-head comparisons of all the major web application scanners because they had built a proprietary scanner (but it wasn’t for sale – they sold a service that used the scanner) and would have these comparison tests every once in a while to see how their product stood against the competition. Now, I didn’t really run the tests myself because I was doing billable work (mostly web app testing) at that moment, but a friend at the company working right next to me was doing the comparison testing – so he’d share the results with me whenever I continually look over his shoulder and asked about them.

It was kind of a funny thing. One was always better at picking up XSS than another, Some other one was good at picking up SQL injection, while some weren’t, one was always better at code coverage when using an automatic crawl functionality, some wouldn’t work well in certain authentication scenarios, etc., etc.

I mean – web app security is a hot market these days, and rightfully so. Most (not all) organizations (for the external infrastructure) generally have firewalls up blocking most un-needed services. They’re aware of shutting down extraneous services, incorporate some sort of patching solution, etc. but almost all have a web site.

As time goes on, and security awareness goes up, rules or laws instituted making companies liable for compromises, things like finding an mssql server on port 1433 with a weak password, anonymous ftp, un-patched webservers become less and less common in an external environment.

But again, almost every company has a port 80 or 443 open with some application somewhere. Web applications provide, by far, the largest external attack surface in an organization – there’s typically hundreds of user-controlled parameters going into the application, which are all a potential threat. Plus, a lot of the time there’s all kinds of interesting things when web apps get exploited, like user names and passwords that can be used for other services throughout the organization, credit card numbers, personal identification information, and more. And luckily for people who are into (in)security, most of the time it’s custom code written by people who know nothing about security – and don’t have that much experience, as opposed to other services that they have externally facing that generally have a lot less attack surface and have been written by some well-known company or a community, tested a lot and have more-or-less stood the test of time (like most PPTP or SSH servers).

So I could never understand – with the market so hot (like – if you’re a security company and you’re not selling web application work when you are offering the service then something is seriously wrong with your sales team) why a company or open source project has never got it right.

Why not try out all the web app scanners on the market, take the features, techniques, signatures of the ones that perform certain functions the best (or better than the others) and combine them into one tool? Someone could make real decent money doing that. I’d almost be tempted myself – but I it’s just not something I’m really interested in. Look at how much money IBM/WatchFire’s AppScan and HP/SPI Dynamics WebInspect pull in for them – and their products really aren’t that great, like at all.

I mean to build a web app scanner generally isn’t rocket science (or even computer science most of the time). There’s actually a really good how-to write your own web app scanner in the O’Reilly book “Network Security Tools, Writing, Hacking, and Modifying Security Tools.” The code for that one is available here.

But for some reason I think that the developers for web app scanners think that they don’t need to check out the competition before they release something – they must think that whatever they’re doing, it must be the best way. Otherwise we wouldn’t have so many people charging a lot of money for low-quality web app scanners on the market.

So – back to NTOSpider a bit: of course, there’s no one automated scanner that’s going to be an end-all-be-all solution for webapps – (there’s just way too many business logic types of flaws in applications to have a non-intelligent scanner catch these types of things). But it does a decent job I guess for what it was meant to do – mainly fuzz parameters.

However, I do usually throw a couple different webapp scanners at an app either before or during manual analysis to catch any low-hanging fruit and to let me know where I might want to concentrate some exploit efforts on (like, for instance on a possible sql injection finding).

I know, I know – I’ve heard some pentesters say that they aren’t supposed to mention that they use automated tools like nessus or webapp scanners – they do all manual testing.

However, IMHO there is definitely a time and a place for scanners. I’m not saying they should *strictly rely* on them and only run a couple of scanners on a test and call it quits (because you *will* miss a lot of cool findings) – but I do run automated scanning tools on just about every single test I perform (like nmap).

So, again I do think that there are things that webapp scanners are really good for – fuzzing parameters (in the case of webapps, scanners are usually really good at catching XSS, sql injection points, and CRLF). When fuzzing anything it is generally done in an automated fashion – keeping in mind it usually does take a lot of manual effort to generate meaningful fuzzing data sets to get the best results possible – but once you have meaningful data sets to fuzz with it should be an automated process.

The process of fuzzing stuff is actually kind of what a computer is meant to do. The four basic functions of computing come to mind – input, processing, output and storage. The combination of these functions is exactly what we do when fuzzing!

I think scanning tools probably got a bad rap from the community when “pentesters” started using/condoning automated tools for their complete efforts of the pentest like running nessus on a network or a webapp scanner on a web application and calling it quits. Now just running automated tools on some application, system or network is not a pentest in any sense of the word, any decent pentester will tell you that – but in the same sense I feel that there is some backlash against these very same tools from others in the community. I can kind of understand – no automated tool can take the place of an experienced pentester. On the other hand I think these very same tools can definitely bring informative issues to the table when testing.

Now that I have in some sense justified (at least in my own mind) scanning tools for particular purposes I guess I’ll get to the original point of this post – which is someone else actually likes NTOSpider (even the though the both the report and the metrics that Larry Suto use are pretty wack):

Cheers,

Chuck B.

For the last little while I’ve been looking into decent ways to fuzz things like how to generate “smart” data sets to fuzz with and how to automate the fuzzing process along with decent ways to monitor and log exceptions/signals.

At this point, I pretty much have a system down. I’ve modified a few fuzzers like Autodafe and Filefuzz to get them to generate (at least what I think is) more meaningful test cases to fuzz with. So now the bulk of the time is usually spent in tearing apart binary file formats in order to perform intelligent block-based fuzzing (which isn’t usually that hard – one can usually find documentation and a breakdown of the format somewhere like wotsit.org or use templates from 010 editor or even in the docs of the program you’re fuzzing). It’s useful to do this for things like knowing where potential trouble areas would be – like a length field or generally breaking down the structures of a binary format for things like knowing when to perform a CRC32 checksum on a structure to get more code coverage in the binary when fuzzing so it doesn’t just fail a checksum and exit – things like that. A smaller portion of the time is pretty much just generating the files using some fuzzers then firing them off. Lastly – there is the fun part of looking over the results when any exceptions are logged / generated and confirming anything found (usually in a debugger).

So I’m thinking that it might be lucrative if I start looking into media format things. I’m thinking files like avi, bmp, tiff (one’s gotta have love for those iphone/safari tiff vulns. out there), pm3, jpg, png, wav, wmf, wmx, mpeg, mpa, midi, rmi, cda, ivf, divx, mov, rm, rts, qt, swf, etc. There are *tons* of different media formats out there and *tons* of different applications that open them (including media players, browsers, plug-ins, etc.).

As I’m going through the motions with this I’m thinking to myself “Self – it would be really cool if a few other cats were in on this – we could get a system going and just pump out a lot of tests, more testing = more potential bugs to be found.”

And so, finally the whole point to my post: if anyone is interested in helping out to find some 0-days it would be really cool. If anyone is interested but doesn’t have much experience with fuzzing (but is willing to learn how to do it) I will be totally down in explaining everything I know about it and where to find the material that I read to learn about it (so that whomever else is interested in learning about it can read it as well). If anyone else is interested in fuzzing stuff to find bugs and they have some experience then I’d really like to hear how they went about it – two (or more) heads are always better than one.

Like I said – I pretty much have a system down and some tools written – it would just be cool to have some extra hands and ideas in the mix.

Interested persons – just hit me up.

anautonomouszone [at] gmail [dot] com

Cheers,

Chuck B.

So in light of it being the beginning of October I decided to celebrate by spending a little time on re-writing some of the functionalities of FileFuzz.

As I had mentioned in a previous post about this topic, fuzzing typically falls into two different categories – brute force (mutation-based fuzzing) and intelligent brute force (generation-based) fuzzing. Just to recap, mutation based fuzzing is where we get some sample files of the file type and the fuzzer generator creates mutations of them. With intelligent brute force fuzzing we actually have to research the file specification. An intelligent fuzzing engine is still brute force attacking, but it relies on configuration files from the user, making the process more intelligent. Think of templates that the fuzzing engine will use that has a list of data structures, positions relative to each other, and possible values.

In the last little while, in my free time, I’ve been looking into different fuzzing generators in order to generate malformed files for different file formats. I decided to go with Autodafe for the generation based fuzzing. I have a newer release of Autodafe than the public version, (just because I emailed Martin Vuagnoux and he was cool enough to send me the newest he had at the time) – and I modified how it generates files for hex fuzzing. The stock version of Autodafe is missing the hex generator functionality. You can pick up the hex fuzzing mod that I did for it here.

I also decided to spend a little time and modify FileFuzz for the mutation-based fuzzing.

One thing I tried to keep in mind while trying to figure out how to generate the data was exactly what data to generate. I figured I’d have greater success of finding bugs if I could generate smart data sets.

So let’s talk about “smart data sets” for a minute pertaining to mutation-based fuzzing (I also like to think of mutation-based fuzzing as file bit-flipping).

Bit flipping files can be really handy for not only finding integer overflows/underflows but also for other length calculations on data.

Let’s look at an example of length calculation stuff (this is pretty much taken from Pedram’s fuzzing book – “Fuzzing – Brute Force Vulnerability Discovery”). For example, MS04-028 “Buffer Overrun in JPEG Processing (GDI+) Could Allow Code Execution.” The JPEG format allows comments to be embedded within the image itself. Comments are preceded by the 0xFFFE byte sequence, followed by a 16-bit word value indicating the total size of the comment. The size includes the two bytes used for the size and the header ends with the comment itself.

We would see something like this in the file:

FF FE 00 06 66 75 7A 7A

Breakdown:

FF FE Comment Preface

00 06 Length of comments in bytes

66 75 7A 7A ASCII value of ‘fuzz’

Now if the Length of comments in bytes was changed (flipped) from 0×0006 to 0×0000 we have an overflow in the vulnerable version of Windows Picture and Fax Viewer (shimgvw.dll).

The other big class of vulns. that typically found with bit flipping are the integer related overflow/underflow guys.

Continuing with “smart data sets” we can guess that the two extreme border cases (0 and 0xFFFFFFFF) are obvious choices to flip bits to – but let’s think of other choices as well.

For example (again from Pedram’s book) it’s not uncommon for additional space to be included with the specified size to accommodate a header, footer, or terminating NULL byte. The following code is an example:

int size = read_ccr_size(packet);

// save space for NULL termination.

buffer = (char *) malloc(size + 1);

Therefore, it might be a good idea to include near-border test cases such as 0XFFFFFFFF-1, 0XFFFFFFFF-2, 0XFFFFFFFF-3, (or even + sometimes) etc.

Then there’s also 16-bit integers (0xFFFF) and 8-bit integers to think about (0xFF).

Also there’s a host of other meaningful (“smart”) values we might want to try that could yield results:

0×100

0×1000

0×3fffffff

0×7ffffffe

0×7fffffff

0×80000000

0xfffffffe

0×10000

0×100000

0×2000

0×8000

etc…

So as I had mentioned previously I decided to work with FileFuzz to generate malformed (bit-flipped) files. The way Sutton designed FileFuzz there’s essentially two different ways to bit flip files. One is to use the “All Bytes” option which you can specify the Byte(s) to Overwrite (flip to) and the number of bytes to overwrite. It might be clearer with a small example:

Let’s say I have a file with the current values:

FF FE 00 06 66 75 7A 7A

If I specified the “All Bytes” option with the Byte(s) to Overwrite to be 0xBB and the number of bytes to be overwritten to be 2 the following would be the first file generated:

BB BB 00 06 66 75 7A 7A

The second file would be:

FF BB BB 06 66 75 7A 7A

The third file:

FF FE BB BB 66 75 7A 7A

and so on…

Using this technique one could generate a lot of files with combinations like 0×00 x 4 (to create 0×00000000 in place of our BB BB above we would overwrite 4 bytes at a time with 00 00 00 00), etc.

But we couldn’t generate different value pairs of bytes to overwrite like 0xFFFE or 0×00000001, or even 0×7FFE….

There’s also the “Depth” option in FileFuzz in which case you specify a location (bytes number) to fuzz in the file and the bytes to overwrite that location with.

Using our example hex values again:

FF FE 00 06 66 75 7A 7A

If I were to specify location 2 with the bytes to overwrite being 0×01to 0×03 the result would generate the following date in the files:

First file:

FF FE 01 06 66 75 7A 7A

Second file:

FF FE 02 06 66 75 7A 7A

Third file:

FF FE 03 06 66 75 7A 7A

So the “Depth” option just concentrates on one byte location at a time.

These options given to us by Sutton are pretty limiting. When I first used this and generated my first case of malformed zip files for fuzzing I used the “All Bytes” function to create files for 0×00 (x 1) which gave me files for 0×00, then I generated files with 0×00 (x2) which gave me 0×0000, then 0×00 (x3) which is 0×000000, and finally (x4) 0×00000000, I did the same for 0xFF, 0×01, 0×80, 0×10, 0×3F, 0X7F and a few others.

I had generated a bunch but in the end I had to enter the Byte(s) to Overwrite / flip to (0×00, 0xFF, 0×01, 0×80, 0×10, 0×3F, 0X7F, etc.) and the number of bytes to overwrite (1-4) and for each instance I had to enter the information in FileFuzz manually.

Well, luckily it came with the source code. What I did was I modified the “All Bytes” function to go ahead and produce a lot of malformed files for different cases without having to enter in the data in FileFuzz each time.

The different cases are the following at the moment:

It will generate files using “Bytes to Overwrite” with values of 0×00 and 0xFF and the number of bytes to overwrite from 1-4.

I also prepend and append the following values if the number of bytes is >= 2:

“00″, “FF”, “3F”, “7F”, “01″, “02″, “80″, “FE”, “10″, “20″, “40″, “60″

So, if the “Bytes to Overwrite” is 0×00 and the number of bytes is 1 then it will simply overwrite each byte at a time with 0×00.

If the “Bytes to Overwrite” is 0×00 and the number of bytes is 2 then it will create the following values to bit flip each bit location with:

0×0000

0xFF00

0×3F00

0×7F00

0×0100

0×0200

0×8000

0xFE00

0×1000

0×2000

0×4000

0×6000

0×00FF

0×003F

0×007F

0×0001

0×0002

0×0080

0×00FE

0×0010

0×0020

0×0040

0×0060

Then for good measure I if the number of bytes to overwrite is >= 2 then I also prepend the values with 7F and append the value with FE. In which case I’d also generate files with bits that flip to

0×7FFE

0×7FFFFE

0×7FFFFFFE

In the end, it’s a lot of test cases – which brings me to my next thought: creating the base test file which FileFuzz will use to do the mutations against.

So, at first I thought it was important to use a very simple test file (for example in my zip test base file I zipped up one text file in a directory that had like 4 bytes written in it). The goal was to keep the file simple and small – because brute force fuzzing (bit flipping) is inefficient. We want to focus on the file headers not the data itself. For example, if I was fuzzing a JPEG I’d want to create a JPEG image with like a 1 x 1 white pixel.

My base test zip file is 248 bytes, which by my modified FileFuzz I got back 36207 different files to fuzz.

If we used a meduim or large (any format type) file the amount of files we’d generate would be way too much to realistically try and fuzz – it would generate way too many test cases, and most of them would be useless because we’d be fuzzing mostly the data in the file, not the headers (the stuff we generally really care about).

Which makes total sense. However, there are some files (like, say randomly downloaded from the Internet) that have more and/or wacky extraneous stuff in the headers that seem to trip up programs much better than just some simple vanilla test file that you create yourself.

For instance, I’ve fuzzed programs with pdf files using a base test case with the same data content (the word “test” in the pdf file, highlighted, bolded, red in color, etc.) from a pdf generated from a Microsoft Word plugin and a pdf generated from a different program. One made Adobe reader crash and the other one didn’t.

So I modified another version of FileFuzz: one that has a modified Range of bytes functionality. The modifications I did to the previous version only pertained to the All bytes functionality. Now with this newer version we can modify a range of bytes in the file. This way we can concentrate on just fuzzing interesting ranges of a larger file (like the file headers).

Also – there was a bug in FileFuzz that I had to fix. It kept crapping out on me when generating certain files (generally larger ones over a certain size) and I tracked the problem down to line 78 in Read.cs:

while (brSourceFile.PeekChar() != -1)

has to be changed to this:

while (brSourceFile.BaseStream.Position != brSourceFile.BaseStream.Length)

So this thing is semi-interesting too.

So, just for the background info here’s brSourceFile being declared:

private BinaryReader brSourceFile;

instantiated like this:

brSourceFile = new BinaryReader(File.Open(sourceFile, FileMode.Open));

Then later in the code we get the while loop to read the data from our test file:

while (brSourceFile.PeekChar() != -1){

//readfile…

}

Turns out the problem is in PeekChar(). This method tries to peek at a char (with UTF8 encoding as default) and can get into an error state if it sees a byte that it can’t understand.

I guess Microsoft is “actively looking to obsolete BinaryReader.PeekChar in a future release since it has some design issues.”

Heh – I guess PeekChar() is a method in the BinaryReader class that can only handle chars (not binary as the class name suggests)

Anyways, if anyone comes up with more interesting datasets to use for brute-force fuzzing or any other thoughts on how I might improve my modified version of FileFuzz let me know…

Cheers,

Chuck B.