Daily Dave

Directory traversal as a reconnaissance tool (Russ McRee)

Mon, 08 Feb 2010 23:28:57 GMT

Posted by Russ McRee on Feb 08

Directory traversal as a reconnaissance tool
http://holisticinfosec.blogspot.com/2010/02/directory-traversal-as-reconnaisance.html

Like most of you, I find malicious or fraudulent online advertisers
annoying to say the least.
My typical response, upon receipt of rogue AV pop-ups, or redirects to
clearly fraudulent sites, is to "closely scrutinize" the perpetrating
site.
This effort often bears fruit as is evident in the following...

Kernel bugs!

Fri, 05 Feb 2010 22:35:17 GMT

Posted by dave on Feb 05

So I remember when one of the major kernel remote in Windows came out,
and Nico was down in Argentina at Ekoparty with cards that had a praying
mantis on them and read "Our other bug is a kernel remote". MS asked him
if he'd known about it before hand, and the answer, of course, was no,
he just was lucky to have neat cards ready.

Nonetheless, Kernel exploitation is a skill that is not going to get old
any time soon. In light of that,...

Re: ASLR+DEP = no problem. :>

Fri, 05 Feb 2010 22:04:32 GMT

Posted by Michal Zalewski on Feb 05

I propose antivirus scanning.

With this problem solved, moving on to...

/mz

Re: ASLR+DEP = no problem. :>

Fri, 05 Feb 2010 18:20:22 GMT

Posted by Larry Seltzer on Feb 05

First, it looks like insulting others is common, if not mandatory
practice on this list. Sorry if I don't do a good enough job, I'm new
here.

My first impression on seeing this (I'm still reading Dion's paper) was
that perhaps some sort of validator or IPS-like functionality in the
JIT, analyzing the input, could be effective, looking for malformations
and suspicious behavior. It couldn't be perfect and there would be a
performance hit.

My...

Re: ASLR+DEP = no problem. :>

Fri, 05 Feb 2010 14:46:54 GMT

Posted by Berend-Jan Wever on Feb 05

The way I see it DEP+ASLR tries to take the executability of controllable
bytes (DEP) and the predictability of the locations of bytes (ASLR) away
from an attacker.

I have not seen the talk or any technical information about the attack under
discussion, but I am guessing that this JIT attack generates a large number
of functions with specific content, which cause the JIT compiler to generate
a large number of executable bytes with predictable...

Re: ASLR+DEP = no problem. :>

Fri, 05 Feb 2010 14:08:47 GMT

Posted by Nate Lawson on Feb 05

Alexander Sotirov wrote:

This is one reason why I expect the techniques of software protection to
become more widespread in general-purpose systems. Things like
obfuscation, heap randomization, integrity self-checks, linker module
encryption, etc. were once the domain of copy protection systems or the
like.

But if your JIT compiler starts generating randomized, obfuscated native
code with embedded self-checks, now it starts getting harder to...

Recon Call for Papers - July 9-11 2010

Fri, 05 Feb 2010 13:30:09 GMT

Posted by Hugo Fortier on Feb 05

/*
Architecture: x86/Linux
Author: Recon
Published: 2010-02-04

The shell code walls the following message:
+ + + +
+ + +
+ +
\ /
+ _ - _+_ - ,__
_=. .:. /=\ _|===|_...

Re: ASLR+DEP = no problem. :>

Fri, 05 Feb 2010 05:05:00 GMT

Posted by pageexec on Feb 04

it is a bug to enter a generated insn stream at a non-insn boundary.
it's also fixable (SFI/CFI et al.).

Re: ASLR+DEP = no problem. :>

Fri, 05 Feb 2010 00:37:15 GMT

Posted by Sergio 'shadown' Alvarez on Feb 04

Thierry,

Yeah, probably my capability to read your mind is lacking because I'm
not a mind reader, as well on the other hand your capability to
analyze exploitation techniques is lacking because you are not an
exploit coder (beyond XSS and SQL-Injection I mean). Unless you've
learnt something in the last year and a half, but first you should
need to read ASM which you didn't know either, that's why I've guess
on your interpretation...

Re: ASLR+DEP = no problem. :>

Thu, 04 Feb 2010 23:01:47 GMT

Posted by Alexander Sotirov on Feb 04

Are you making the claim that JIT spraying can be stopped by redesigning the
JIT? How exactly would you redesign the JIT to avoid inserting bytes controlled
by the attacker into the generated instruction stream?

Alex

Re: ASLR+DEP = no problem. :>

Thu, 04 Feb 2010 21:53:39 GMT

Posted by Matthew Wollenweber on Feb 04

I saw the talk and I'm not sure how exactly you easily fix the problem. The
speaker didn't organize the talk optimally and TSA screaming next door
didn't help either, however it seems difficult to fix being able to fix
shellcode generated by valid actionscript code. Additionally, the JIT spray
was fairly small and according to the speaker had a greater than 90%
reliability.

The most common attack vectors (IMO) appear to be PDFs and IE. Adobe...

Re: ASLR+DEP = no problem. :>

Thu, 04 Feb 2010 20:28:36 GMT

Posted by dave on Feb 04

I know I'm annoying Spender by even replying, but this sort of thing is
not dependant on Flash. It's simply a function of "Any JIT the attacker
can pass data into will break DEP/ASLR". The only "solution" is to have
every available JIT have defined entry points that the kernel enforces
(which will prevent EIP from going into the middle of a JIT'd function).

At that point you basically have "Determina" and you take a...

Re: ASLR+DEP = no problem. :>

Thu, 04 Feb 2010 19:55:18 GMT

Posted by Thierry Zoller on Feb 04

Hi,

Why refer to respect when all you write afterwards is full of despise
and arrogance ? Your capability to read my mind is still
lacking ;) , apparently you thought you know - What I read and
what I know. Sorry to inform you that you are wrong on both.

Does not compute either. By "fix" I abviously assumed "redesign/eginner"
the JIT. The point was that ASLR/DEP is not dead because of error in a
JIT.

Re: ASLR+DEP = no problem. :>

Thu, 04 Feb 2010 18:59:43 GMT

Posted by Moshe Ben Abu on Feb 04

Yep, I agree with Thierry, once the technique will be fixed - ASLR+DEP = big
problem :(

Past examples:
- Java Virtual Machine Heap Spray > Java is out of process since 1.6.0u10.
- Actionscript Heap Spray > Flash 10 got DEP and ASLR.
- .NET User Control binary > Internet Explorer 8 RTM blocks it on Internet
Zone.

In addition, latest versions of Adobe Reader, QuickTime and .NET Framework
got DEP and ASLR enabled too...

Re: ASLR+DEP = no problem. :>

Thu, 04 Feb 2010 16:56:33 GMT

Posted by Thierry Zoller on Feb 04

Hi,
This -

+

Doesn't compute. You are relying on oddities, fix
the oddities and ASLR/DEP are back again.