Design bugs are really difficult to fix - nobody ever takes a dependency on a buffer overflow, after all. Few things have had their design stretched as far as the web; as such, I've been starting to take a look at some interesting aspects of the "Web 2.0" craze. Here's a few things I've been looking at: Slirpie: VPN'ing into Protected Networks With Nothing But A Lured Web Browser. Part of the design of the web is that browsers are able to collect and render resources across security boundaries. This has a number of issues, but they've historically been mitigated with what's known as the Same Origin Policy, which attempts to restrict scripting and other forms of enhanced access to sites with the same name. But scripts are not acquired from names; they come from addresses. As RSnake of ha.ckers.org and Dan Boneh of Stanford University have pointed out, so-called "DNS Rebinding" attacks can break the link between the names that are trusted, and the addresses that are connected to, allowing an attacker to proxy connectivity from a client. I will demonstrate an extension of RSnake and Boneh's work, that grants full IP connectivity, by design, to any attacker who can lure a web browser to render his page. I will also discuss how the existence of attacks such as Slirpie creates special requirements for anyone intending to design or deploy Web Single Sign On technologies. Slirpie falls to some of them, but slices through the rest handily. p0wf: Passing Fingerprinting of Web Content Frameworks. Traditional OS fingerprinting has looked to identify the OS Kernel that one is communicating with, based on the idea that if one can identify the kernel, one can target daemons that tend to be associated with it. But the web has become almost an entirely separate OS layer of its own, and especially with AJAX and Web 2.0, new forms of RPC and marshalling are showing up faster than anyone can identify. p0wf intends to analyze these streams and determine just which frameworks are being exposed on what sites. LudiVu: A number of web sites have resorted to mechanisms known as CAPTCHAs, which are intended to separate humans from automated submission scripts. For accessibility reasons, these CAPTCHAs need to be both visual and auditory. They are usually combined with a significant amount of noise, so as to make OCR and speech recognition impossible. I was in the process of porting last year's dotplot similarity analysis code to audio streams for non-security related purposes, when Zane Lackey of iSec Partners proposed using this to analyze CAPTCHAs. It turns out that, indeed, Audio CAPTCHAs exhibit significant self-similarity that visualizes well in dotplot form. This will probably be the first DEFCON talk to use WinAMP as an attack tool. A number of other projects are also being worked on - I've been sending billions of packets for a reason, after all, and they haven't been coming from WinAMP :) There will be some updates on the analysis tools discussed during Black Ops 2006 as well.