I spent the weekend in Berlin attending a conference called PH-Neutral, run primarily by the Phenoelit crew. This was the first European security conference I’ve attended and I found it quite different from any North American security gathering I’ve been to, such as BlackHat, CanSecWest, SOURCE Boston, BlueHat, or RSA. Everything was far more casual and laid back, which is something I had heard about European conferences but hadn’t experienced until now (even EUSecWest is held in a club whereas CanSecWest is in a Marriott).

The event was held at Die Insel, on a tiny island a few kilometers outside of Berlin’s city center, near Treptower Park. The venue is mostly used for live music so basically it feels like a dark, somewhat dingy club (certainly the bathrooms are reminiscent of a club). The presentations were on the 3rd floor in a room that probably held about 60 people in close quarters; to handle overflow, a closed-circuit feed was being simulcast on the 4th floor, which was a bit less crowded and, more importantly, opened out onto a rooftop deck which meant better ventilation. The bottom floor led out to a Biergarten with tables, beach chairs, and a stage which was used for DJing. The layout was actually pretty efficient for allowing around 200 people to mill about and socialize/network while not having to stray too far from where the talks were presented.

As far as the event itself, when I said “laid back” earlier, don’t interpret that to mean disorganized or watered down in any way. It was run with stereotypical German efficiency, from badging to presentations to the after-hours parties. The presentations were just as technical and relevant as any of the more “corporate” conferences. Unfortunately for me, I don’t know that many people in European security circles, and most of the ones I do know weren’t in attendance. Those I did meet, however, were impressively smart and well-versed. Nobody was trying to conduct business transactions or slip away for meetings, which is inevitably what happens when only technical folks are present!

For me, a few talks stood out. Fukami and BeF’s talk on SWF and the Malware Tragedy discussed methods for automated static detection of malware in Flash movies. Much of it centered on heuristics related to inconsistencies in the file format or tag structure, abnormal concentrations of strings in the constant pool, or the existence of various obfuscation techniques. Ultimately, there are false positive issues to be addressed but that is just a fact of life with static analysis, and it will be an iterative process to refine those heuristics as the attack vectors evolve. I thought this talk was particularly timely given the increasing prevalence of Flash as a conduit for exploits/malware, such as the most recent Flash 0day that made the news (granted, this was an exploit against Flash itself, not just using Flash as a delivery mechanism, but close enough).

I also enjoyed pierre’s talk on counterintelligence, basically a mélange of wiretapping and other bugging devices discovered in the wild. War stories are always interesting, particularly when it comes to the realm of physical security. One of the x-ray images he showed of a bugged pen was identical to a pen that I own (minus the bugging device of course… I hope). The feel of the talk reminded me a bit of James Atkinson’s talk at SOURCE, “Telephone Defenses Against the Dark Arts” (video: Part 1 and Part 2), which also got rave reviews.

Mike Eddington’s presentation on the Peach 2 fuzzing framework was also quite interesting. Peach 2 was released several months back but I haven’t really been paying much attention to it or any other fuzzing tool for some time. In fact the last time I really had to implement a protocol fuzzer, I was using SPIKE 2.9, so that gives you some indication of how long it’s been. Peach 2 includes some powerful built-in capabilities such as node relationships (e.g. field 1 represents the length of field 2; field 10 is a CRC-32 of fields 1 through 9), data transforms (those with battle scars from ASN.1 will be happy), state machines (packets 1 and 2 have to be normal in order to fuzz packet 3), monitoring agents (detecting when a crash happens and under what conditions), and much more. I am itching to go fuzz something now just so I can tinker with Peach.

All in all, it was a good trip and I enjoyed the opportunity to see how things are done across the pond, and to do a little sightseeing in a historic and beautiful city.

Yesterday, Dave Lewis over at LiquidMatrix Security Digest cried foul at Core Security for releasing too much detail about a recent DoS vulnerability they had discovered. His specific gripe was that they provided an IDA Pro excerpt that showed where the vulnerability was triggered. The excerpt is short, so I’ll even copy/paste it here:

.text:00405C1B mov  esi, [ebp+dwLen]  ; Our value from packet
...
.text:00405C20 push edi
.text:00405C21 test esi, esi          ; Check value != 0
...
.text:00405C31 push esi               ; Alloc with our length
.text:00405C32 mov  [ebp+var_4], 0
.text:00405C39 call operator new(uint); Big values return NULL
.text:00405C3E mov  ecx, esi          ; Memcpy with our length
.text:00405C40 mov  esi, [ebp+pDestionationAddr]
.text:00405C43 mov  [ebx+4], eax      ; new result is used as dest
.text:00405C46 mov  edi, eax          ; address without checks.
.text:00405C48 mov  eax, ecx
.text:00405C4A add  esp, 4
.text:00405C4D shr  ecx, 2
.text:00405C50 rep  movsd             ; AV due to invalid
.text:00405C52 mov  ecx, eax          ; destination pointer.
.text:00405C54 and  ecx, 3

Dave asserts that publishing 16 commented assembly instructions makes this disclosure irresponsible. But look at the code — it’s completely generic, just a textbook example of what it looks like when you forget to check a return value after calling operator new. Sure, Core gives you the exact offsets into the executable, but so what? If I have the binary, then it’s not going to be too hard to find the vulnerability anyway. It’s not like Core is giving away a proof-of-concept exploit that generates the malformed registration packet required to trigger the DoS. What’s more, they provide a detailed timeline going back to January 30th of this year describing exactly how the disclosure process with the vendor transpired. This looks extremely responsible to me; I just can’t understand what is “not cool” here.

There’s another interesting angle to this, completely unrelated to Core’s disclosure process. The vulnerability itself is described in the advisory as follows:

Un-authenticated client programs connecting to the service can send a malformed packet that causes a memory allocation operation (a call to new() operator) to fail returning a NULL pointer. Due to a lack of error-checking for the result of the memory allocation operation, the program later tries to use the pointer as a destination for memory copy operation, triggering an access violation error and terminating the service.

This may bring to mind some recent discussions on whether callers of memory allocation functions should check the return value prior to use. To summarize, one camp says “caller should check”, the other camp says “callee should exit on allocation failure.” This is a gross oversimplification and if you want more detailed arguments, read the other blog posts that I linked to. In this case, if the “exit on failure” approach were taken, the DoS scenario might still happen, whereas if the caller were checking, the error could be handled more gracefully. More fuel for the debate!

I was checking out the “new and improved” Dilbert website a few minutes ago, checking out some of the new features and lamenting the overzealous use of Flash. One new feature is called “Mashups.” Naturally, you’d assume that this was some fancy Web 2.0 API that one might use to create a “killer app” combining Google Maps, Twitter, traffic delays, police reports, and Dilbert comics, all neatly packaged up as a privacy-invading Facebook plugin. Sorry, no such luck. “Mashups” turns out to be a way for readers to unleash their inner comedian and create customized punch lines for the daily comic, which can then be voted on by others. For example, here are the mashups from the May 3rd comic.

Below is a screenshot of some of the user-generated comics that can be viewed. I’ve magnified the last pane of one of the strips using Flash’s “Zoom In” feature. Notice anything interesting?

Yep, it’s our old friend URL encoding, commonly used by web browsers to include non-alphanumeric characters into an HTTP request. Just interpret the %XX as a hex number, so %20 is the space character (decimal 32), %21 is an exclamation point (decimal 33) and so on. But why is it showing up in a Dilbert mashups?

My first thought was that someone must be poking around the Dilbert site looking for security holes. But then I noticed that it wasn’t just the one strip; a lot of them had the same problem. And it seemed unlikely that there were that many security-minded people messing with the site relative to the rest of the cubicle dwellers trying to come up with funny things for Dilbert to say.

My next thought was just that some developer just forgot to call urlDecode() — or whatever the Flash equivalent is — on the user-supplied punch line. Except that’s an oversimplication because: 1) it doesn’t happen on every strip, 2) the web server usually strips off the first layer of URL encoding so the backend wouldn’t see it unless it was double encoded (e.g. %2520), and 3) if you click on one of the thumbnail comics with the URL encoding anomaly, the full-size rendered version of the comic looks fine:

So clearly the “preview” code and the “full-size render” code are doing slightly different things with the same data, which may or may not have been properly decoded prior to being inserted into the database.

Any thoughts, readers? The pen tester in me wants to get to the bottom of this, but unlike some of the web app security people out there, I tend to be more conservative about hacking at stuff without a signed contract. Also, I don’t think I can stand to read any more un-funny punch lines. But my gut tells me there is something fairly interesting going on behind the scenes here. Exploitable? Probably not. But it’s a great example of how easy it is to misinterpret data.

Oh finally, here’s a tip from Scott Adams himself on avoiding the Flash navigation and viewing the daily comic as a plain ol’ GIF.