Buried inside an Immunity Inc slideset somewhere is a line “Generic heap exploitation approaches are obsolete….Application specific techniques are needed”. As usual the Immunity guys are right. They were specifically discussing that there are no more easy write4 heap overflows due to safe unlinking and other similar technologies (DEP, ASLR, SafeSEH, DEP, etc). They go on to write about some of the interesting things they’re doing to effectively exploit heap vulnerabilities. For those facing a touch heap exploit, I recommend reading their papers.
Unfortunately, they estimate that it can take 3 to 6 man-months to craft a reliable heap overflow exploit. For most assessment organizations that’s unrealistic. Most penetration test or security assessments last between 1-2 weeks. A common problem to see is that an organization recently patched all their systems right before you arrived. In fact, I’ve been asked to delay tests while they finished patching.
I’d generalize Nico’s statement to “General exploitation is obsolete” and state that “Exploitation is now specialized”. By that I mean, for most organizations creating generic exploits is too expensive or the return on investment isn’t there. The solution is to specialize multiple chained attacks into a larger attack vector particular to the target organization. I come from a Red Team background. One of the first concepts I was taught about breaking into systems is to identify two key factors:
- An adversarial model. Determine who the organization fears. Mimic their skill set and goals.
- The mission or business critical assets. Managers don’t understand technical vulnerabilities. They only know their mission/business.
My goal is to exploit that asset as their adversary would. I find this is an extremely effective approach. Foremost, you’re likely to keep your client happy if you understand both their business and their threats. But it also keeps you from going down interesting technical challenges that don’t mean all that much to them. Explaining business impact derived from a realistic methodology means far more.
Digging into the dirt what does this mean? It means there is no clear one size service. The client needs to put realistic vectors on the table and experienced testers will use the ones that make the most sense. In all but the worst organizations, there are no easy remote exploits from the Internet. Then even if you do get in, you have AV and are usually in a DMZ. The key is to chain your attacks.
A common pattern that I’ve used is a bit of customized code and targeted phishing. I’ll spend a few hours data mining the company and employees. I’ll target them with a couple options such as a signed, safe for scripting, safe for initialization ActiveX control that almost everyone clicks or a recent Office/PDF/IE exploit. The initial callback gets you into unprivileged user land. Unless their is a specific need for it, you usually don’t even need SYSTEM at this point. If you do, more than likely MS08-067 will still work somewhere. Next, I’ll look around the intranet for internal web applications or in-house software. I often find weak in-house or niche software that has no public vulnerabilities but is very obviously not security hardened. Grab a copy of the software (usually available on the local machine, a share on the target server with user credits — handily available from your logged in phishing victim, or other source). Take the software home and begin fuzzing it. The software has probably never seen a fuzzer and will break very quickly. Once you have an exploit working (probably a stack overflow without GS, DEP, SafeSEH) you can exploit the remote server — which is usually running the app as SYSTEM. At this point you have SYSTEM on a server. A domain admin will likely have some process running, inject into that and the game is over.
How is this specialized? Rather than spending 6 months developing an exploit I got what I needed in the time of my assessment by targeting users, the internal infrastructure, common vulnerabilities, and the in-house software that is unimportant outside the organization.
This approach definitely is not an attack on research exploit development. In fact, I think it’s more a testament to how well guys at places like Immunity and Core have pushed exploit development — thereby pushing Microsoft and others toward strong generic security measures. So while they do the hard work of finding new vulnerability classes and faster techniques to exploit the strong security measures, I think penetration testers and the bad guys will have to step up their game from point-click-scan-exploit to focus building customized approaches for their particular target and exploiting the low hanging fruit. This is double true since tools like Immunity Debugger are available to tackle the easy bugs. It reminds me of doing differential calculus with a TI-89.
