Dailydave mailing list archives
Re: "So now we have two large organizations using what I like to call a 'two time pad'"
From: H D Moore <hdm-daily-dave () digitaloffense net>
Date: Tue, 3 Aug 2004 02:11:15 -0500
Dropping my $0.02 (inline). On Monday 02 August 2004 18:29, dave wrote:
Advanced Return Address Discovery using Context-Aware Machine Code I only caught the tail end of this talk, enough to ask my question (see previous messages on this list). I'll freely admit to not understanding the answer. I heard the talk was good though.
The demo gods unleashed their wrath on this talk as well; apparently the demonstration of the context/tracing engine broke at the last minute. It would be interesting to see what the practical benefit is to this technique when compared against smart opcode-scanning (ala msfpescan). The example given was a return address which ran through 91 instructions before returning back to the desired register. I guess it depends on the exploit and what you have to work with, I haven't seen a case where this level of complexity was required. It would be nice to be proved wrong on this point though; return
Metasploit If you were in this talk (and it was PACKED) then you'll know that the demos didn't work out so well.
Actually almost all of the demos went just fine, the three issues were the broken MacOS VNC client, a weird interaction between alphanum encoder (seh getpc) and lsass, and the samba 'doh' issue dave pointed out. Due to time constraints on the BH talk, we only went through a few other demos (MacOS X remotes, etc). Everything went *much* smoother during the Defcon talk and we actually had time to do the interesting demonstrations and rant about why the tech behind it was important. The demos were just a minor part of this talk. The real goal was to explain how a simple exploit framework can result in advanced exploitation and post-exploitation systems. Materials for both of these talks are online (including pre-release of 2.2), you can find them at: http://metasploit.com/bh/ The DC slides are a bit spiffier and have a little more information that the BH stack. We were accepted to BH at the very last minute and we had to ignore sleep and stomach flu (just me) to get anything ready in time.
Restarting smbd got the Metasploit exploit to work, as I expected. They didn't realize it was me at the time.
We knew it was you about thirty seconds after you said it, otherwise spoonm would not have hurled a plastic ninja at high velocity across the conference room in your direction. Hopefully nobody will sue :)
I wasn't overly surprised at anything I saw there - if I had been that would mean I wasn't doing my competitive analysis correctly.
Haha. Competitive analysis. We have no interest in competing against anyone. Writing an exploit framework is fun and we add exploits/payloads as free time permits. This is obvious if you look at the type and timeline of the exploits we release; we will often spend weeks working on old exploits simply because finding better ways to exploit old bugs is more fun than beating our heads against some annoying new one. You (and anyone else) are welcome to sign up for beta releases, borrow ideas from the project, or use exploit vectors and return addresses. The metasploit project has always been about sharing information with the rest of the community. If anyone has any questions about what we are doing or where we are going (or just wants to kick in help), just email us. We are not trying to take customers away from Immunity or Core. We wish the best for both of them, its a nasty political climate for anyone distributing exploit code, especially as a commercial entity.
They got their VNC demo to work, which was cool, if a bit cheesy.
Believe it or not, it can actually be useful :) Once we finish integrating it as a Meterpreter extension, its real purpose will be a bit more obvious (supplement, but not replace normal access methods, pull snapshots of desktop, etc). It actually has a few advantages over standard VNC, since it works just fine on read-only desktops. The source code for the injection system and the hacked up VNC server is in the 2.2-vegas tarball.
A Comparison Buffer Overflow Prevention Implementations & Weaknesses This talk was pretty weak. What's the point in discussing overflow techniques without code examples? It was a bit like a high school science fair presentation, and not a good one.
IIRC, legal threats from one of the vendors curbed a good chunk of their content a few weeks before the presentation. Not sure why code wasnt released for the actual blue-screen bugs, however they did promise to release the benchmark suite sometime soon. At the least, this talk was a good example of why most developers shouldn't be writing ring-0 code in the first place, even security people (no validation of user-space pointers).
Overall I can say this: This was the largest blackhat I've been to, but not one of the most technical. The talks were good without being great.
That seems to be the trend; the extremely technical talks don't do well because only %2 of the attendees can follow and the high-level talks annoy the shit out of the technical folks. Our talks have been intentionally middle-ground for that reason; there are much better forums for ripping up the details.
The Microsoft party was out in the desert, which was cool.
Heh. Convincing security people to meet at a bus stop and enter a vehicle where even the driver doesn't know where they are going doesnt exactly promote trust :) And no, I am not bitter because we showed up too late and missed the party (strip traffic was hell)... <rant mode>
I think the era of free vulnerability information is definately waning.
Commercialization will do that, fight back with what you can. Help the OSVDB project, release implementations of cool concepts, don't horde warez when its just going to be obsolete in two weeks anyways. This isn't directed at anyone in particular, but anyone can be a doomsayer if they are weighting the outcome. It seems like we have entered an age of diminishing returns on vulnerability research. Enter a world where the low hanging fruit are covered in flies and the only guys with ladders prefer wine over fruit salad. New trees get stripped the second enough people see them and the tall ones will always have a few fruit nobody can quite reach. Most vulnerability research is about shaking more fruit loose; some people build FruitBinDiffThresher2000's and others simply put in the hours to pick them by hand. The last couple years have been almost void of new types of trees; everyone is working so hard on pillaging the current orchard that the greater challenge has been put on the side. <subrant> Very few new exploit vectors have been publicized over the last few years. Shatter attacks are still ridiculously easy, the win32 internals are nasty and hanging wide open (LRPC ports for instance). The area that actually matters; the development community, is still being inadequately addressed or monitored. Head to your nearest book store, pick up a handful of the "new releases" under programming and start flipping through. These books are providing the blueprints for the people who design and implement the applications we break. Check out some online forums for the language of your choice; get an idea for what functions people are calling and how these functions handle nasty input. These become the building blocks for tomorrow's exploit vectors. As boring as it is, auditing development components can expose classes of problems that require architecture changes to solve. A great example is the ASP language; the COM components used to access the file system will parse unicode paths, however the language itself provides no way to normalize file system path names in this form. The result is a thousand ASP scripts which are vulnerable to trivial directory traversal attacks. Simply passing %c0%ae to a FileSystemObject instead of period is enough to bypass most traversal checking code. This issue has not gone away with the introduction of ASP.net, since the .NET Framework still ends up passing paths down to the native DLLs. The same approach applies to perl, java, C++ objects, and a dozen other development systems; yet the focus of most vulnerability research remains grounded in strcpy and XSS... </subrant>
Few conference speakers are giving away really new knowledge.
Eh, it depends on who you are and what you know. Quite a few talks this year covered either new ideas, new techniques, or simply assessments of current products/technology. Even the lame talks were informative in the sense that they were accepted in the first place. You can learn alot just by watching the attendees during a talk.
The last phrack was one of the weakest in recent history. These days, to get good new information, you have to purchase it, and this is making costs rise across the industry.
Phrack is developed by the community, for the community. If the community prefers to get a free flight to Vegas instead of a published article; this is going to reflect in the content of the magazine :) </rant mode>
It'll be interesting to see how that works out.
Definitely. -HD _______________________________________________ Dailydave mailing list Dailydave () lists immunitysec com http://www.immunitysec.com/mailman/listinfo/dailydave
Current thread:
- "So now we have two large organizations using what I like to call a 'two time pad'" dave (Aug 02)
- Re: "So now we have two large organizations using what I like to call a 'two time pad'" Halvar Flake (Aug 02)
- Re: "So now we have two large organizations using what I like to call a 'two time pad'" H D Moore (Aug 03)