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.

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.