Fuzzing for RPC vulnerabilities

So Dave Aitel said there are no more RPC vulnerabilities because his fuzzer couldn’t find any new ones. Well, I thought it was just a matter of trying more combinations and I was right.

The point, though, is not who has a longer fuzzer, but that when it comes to security always bet against the person who says something is impossible.

In fact, I made that mistake myself back in the 1990s, claiming Windows can’t be reliably exploited (I can’t find the link to the old ntbugtraq archives – thank god for that). Little did I know how easy writing Windows exploits would become. Now if I can only get a message to my younger self to avoid this embarrassment. And if I do get to talk to my young self I’ll be sure to tell me to skip the 2nd and 3rd matrix movies.

RFC 4475 is not enough

When beSTORM is used to test VoIP products, it’s usually the standard SIP, SDP and RTP fuzzing. But we were recently asked about opinion on RFC 4475, which was an interesting case study. RFC 4475 for those who do not know is an IETF standard whose goal is to give[s] examples of Session Initiation Protocol (SIP) test messages designed to exercise and “torture” a SIP implementation. This is great but as the RFC states, these are just a few examples – to be more specific 49 discrete examples.

These 49 examples claim to check a broad range of problems that a SIP parser may come across, and that it should either ignore, reject it or handle it correctly.These examples try to test more than one malformed, incorrect or problematic field at a time – opening the possibility that one problematic field is preventing others from being processed.

My problem with these 49 cases is that they seem to be very tailored, testing for specific stuff, without testing all the possible variables of that same example. Lets take the Content-Length header. One example checks the resilience to a negative value, another to a large positive, another yet to the value of zero (0).Did you notice what is missing, for example where is the off-by one underflows/overflows?

Another example is the use of IP addresses inside the sample data, a carelessness or a small oversight by the tester might make the whole example invalid and not parser-able by the test subject. It might be discarded by the product making the entire test worthless, but the tester happy for ‘passing’ the test. It’s like passing a final exam by not showing up!
In conclusion, running those 49 examples is not straight forward, in addition once you ran them and passed, can you say you are ok? From experience I can tell you that in many cases, both our customers and open source products we have tested with beSTORM failed the complete fuzzing test while they passed the RFC 4475 – beSTORM simply discovered one or more vulnerabilities in them that simply didn’t fit any of the 49 examples provided inside the RFC 4475 torture examples.

My recommendation? Testing for those 49 examples only tells you that you are compliant with RFC 4475. Only a serious fuzzer will tell you if your product is secure against SIP, SDP or RTP based attacks.

From description to exploit

Every once in awhile I get an opportunity to work on a “known” vulnerability, but with very little or even no available technical details. These known vulnerabilities tend to be “known” just to their finder and to the vendor that fixed the vulnerability. We know they exist because an advisory is published, but not much more than that.
From the point where the vulnerability got fixed, no one (researcher or vendor) has any interest in disclosing the vulnerability details – as it is no longer interesting – leaving security researchers with insufficient information to confirm whether this vulnerability affects anyone else beside the specific vendor – and specific vendor version.

This is the point I reached today, where our team wanted to update a test of our vulnerability scanner to check for the exploitability of a certain vulnerability on a new platform. The version indicated it was vulnerable to the problem but there was no way to confirm it as the vulnerability’s technical description was inadequate, and checking only the version is a sure way for multitude of false positives.
With the little information available:
The get_server_hello function in the SSLv2 client code in OpenSSL 0.9.7 before 0.9.7l, 0.9.8 before 0.9.8d, and earlier versions allows remote servers to cause a denial of service (client crash) via unknown vectors that trigger a null pointer dereference.

I was determined to discover what was the “unknown vector” and see whether the product I tested was in fact vulnerable or not.

First step was to understand what the SSLv2 exactly is, and how I can get it – well simple enough here, “openssl s_client” is just what I needed – it was a sample SSL client that utilizes the get_server_hello() function.

Then I needed to create an SSLv2 session, this proved to be a bit more difficult as SSLv2 is now considered insecure and most SSL installations disable it – further Firefox no longer allows connecting to those sites that support it… but apparently Apache 2 haven’t given up on it, and you can turn SSLv2 support quite easily through the SSLProtocol definition.

Once that was available, I launched beSTORM’s auto-learn mechanism and made it capture the SSLv2 traffic – a complete session can be quite extensive but I only needed the first packets as they were the one get_server_hello() function looks into – once this was ready I used the pcap export capabilities to load the captured data into Wireshark – and use Wireshark’s existing dissection to mark which fields where what – who was the length of what, what was a flag, etc.

Then I told beSTORM to start listening on incoming traffic and play around with the values, I mainly concentrated on the following ServerHello parameters:

  • Packet Length (total length)
  • Session ID Hit (valid value is either set to 0x01 or set to 0x00)
  • Certificate Type (it is an enumeration of three possible values)
  • Certificate Length
  • Certificate Value
  • Cipher Spec Length
  • Cipher Spec Value
  • Connection ID Length
  • Connection ID Value

After a few thousands of combinations – taking about 50 minutes – with beSTORM modifying the Session ID Hit (set to 0x00), Certificate Type set to NULL (0x00), Certificate Length equal to 0, Certificate Value set to none, Cipher Spec Length equal to 0, Cipher Spec Value set to none and the default captured values of Connection ID – the openssl client crashed:

Program received signal SIGSEGV, Segmentation fault.
0x0808638d in get_server_hello (s=0x81aed90) at s2_clnt.c:542
542 if (s->session->peer != s->session->sess_cert->peer_key->x509)

Now all I needed was to instruct beSTORM to build a module from it – job done.

From a very vague description to an exploit in about an hour :-)

An exploit can be found at:  OpenSSL SSLv2 Client Crash (NULL Reference)

PCM 0day (Divide by Zero)

The debate about the term “zero days” is not directly related to this PCM vulnerability I am about to reveal, but as this vulnerability is not publicly documented, as far as I know, I will call it a 0day.

The vulnerability allows you to crash the mplay32.exe – that for some reason is still shipped with Windows up to version 2003, maybe also Vista, can someone confirm? – this low-quality and feature-lacking (software-wise) player contains a problem where a malformed PCM file can cause it to crash as it tries to divide one number by zero.
00000000 52 49 46 46 24 00 00 1a 57 41 56 45 66 6d 74 20
|RIFF$…WAVEfmt |
00000010 10 00 00 00 01 00 02 00 44 ac 00 00 88 58 01 00
00000020 00 00 10 00 64 61 74 61 00 00 00 1a 00 00 24 17
00000030 1e f3 3c 13 3c 14 16 f9 18 f9 34 e7 23 a6 3c f2
|..< .<.....4.#.<.| 00000040 24 f2 11 ce 1a 0d |$.....| Is this vulnerability interesting? not really - mplay32.exe is no longer the default player - unless you are still in the stone-age (i.e. have never upgraded your system or Internet Explorer) - and it allows you to do nothing but crash the player. If someone can find out more about this issue, I will be happy to hear. BTW: This PCM vulnerability was discovered by beSTORM’s PCM (WAV) fuzzing module – which was launched against mplay32.exe

Flayer is Google’s step to Web application security testing

Google has introduced the tool recently via its Online Security Blog.

The tool is released under GNU General Public License v2.

The home of the new project is here: code.google.com/p/flayer/

The visitors of WOOT ‘07 conference are aware already.

Vulnerable test application: Simple Web Server (SWS)

every once in a while (last time a few months ago) someone emails one of the mailing lists about searching for an example binary, mostly for:

– reverse engineering for vulnerabilities, as a study tool.
– testing fuzzers

some of these exist, but i asked my employer, beyond security, to release our test application, specific for testing fuzzing (built for the bestorm fuzzer). they agreed to release the http version, following their agreement to release our ani xml specification.

the gui allows you to choose what port your want to run it on, as well as which vulnerabilities should be “active”.

it is called simple web server or sws, and has the following vulnerabilities:

1. off-by-one in content-length (integer overflow/malloc issue)
2. overflow in user-agent
3. overflow in method
4. overflow in uri
5. overflow in host
6. overflow in version
7. overflow in complete packet
8. off by one in receive function (linefeed/carriage return issue)
9. overflow in authorization type
10. overflow in base64 decoded
11. overflow in username of authorization
12. overflow in password of authorization
13. overflow in body
14. cross site scripting

it can be found on beyond security’s website, here:

gadi evron,

Windows screensaver lock and lecturing

i was giving a lecture at nps yesterday, and while i was unlocking my laptop (xp), suddently, before unlocked, a file open window pops up. i could browse, and more importantly, open files. the first choice of the system was .hlp.

can someone say pwnage? anyone up to doing some monkey fuzzing on that interface?

gadi evron,

Mozilla’s JavaScript fuzzer – Opera’s best friend

Window Snyder, the head of security strategy at Mozilla Corporation wrote this week about the Opera’s way to use Mozilla’s fuzzer for JavaScript. Mrs. Snyder is pointing to the post of Claudio Santambrogio from Opera Software:

While running the tool, we found four crashers – one of which might have some security implications.

When we are reading news like this from Microsoft and Apple?