Re: "So now we have two large organizations using what I like to call a 'two time pad'"

[H D Moore <hdm-daily-dave () digitaloffense net>]

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