From dendler at tippingpoint.com  Fri Dec  1 08:14:44 2006
From: dendler at tippingpoint.com (David Endler)
Date: Fri, 1 Dec 2006 07:14:44 -0600
Subject: [Dailydave] A really bad month for Novell
Message-ID: <16D356ABF229D64FA57E1CF02363F7C2087B6156@exchange.unity.local>

> from: http://www.zerodayinitiative.com/advisories/ZDI-06-043.html
> 2005.07.07      -       Digital Vaccine released to TippingPoint
customers
> 2006.10.02      -       Vulnerability reported to vendor


I can understand the confusion. TippingPoint already protected its
customers against this vulnerability with a preexisting security filter
released in 2005.  This particular Zero Day Initiative vulnerability was
purchased by us shortly before we disclosed it to the vendor in 2006.
Unfortunately the purchase/acquisition dates are not included the
disclosure timelines, which led to the confusion here. On average, it
may take the ZDI team several days or sometimes a couple of weeks to
validate a vulnerability depending on how much work the security
researcher has done up front, if other vulnerabilities shake loose as a
result of the particular find, and how many other issues are in their
queue.  

-dave

p.s. To quell the conspiracy theorists, we didn't actually launch the
Zero Day Initiative until August 2005. http://zdi.3com.com/faq.html


From dave at immunityinc.com  Fri Dec  1 15:30:38 2006
From: dave at immunityinc.com (Dave Aitel)
Date: Fri, 01 Dec 2006 15:30:38 -0500
Subject: [Dailydave] Book Review: The Art of Software Security Assessment
Message-ID: <457090EE.6010008@immunityinc.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Book Review: The Art of Software Security Assessment
written by Mark Dowd, John McDonald, Justin Schuh
http://www.amazon.com/Art-Software-Security-Assessment-Vulnerabilities/dp/0321444426/ref=pd_bxgy_b_text_b/103-1902494-7928635
Pages: 1200

The temptation with a massive book, such as this one, is to use it as
a reference. While no doubt valuable as a quick reference for people
looking to know the exact problems with any given C API ("snprintf
does what differently on Windows and Unix?"), this book is best read
page by page. There are surprises sprinkled throughout.  Vulnerable
example code is taken from real software applications, such as OpenBSD
3.6, Netscape, and OpenSSH. Of course, more than just a collection of
code with mistakes highlighted, this book has a powerful methodology,
complete with "Desk-checking", "Scorecards" and other useful tricks.
This book is not about binary analysis; assembly language is used only
to demonstrate tricky C code.

Unlike many books with multiple authors, this is an extremely well put
together book that flows naturally from chapter to chapter. The
chapters on C auditing are amazing. The chapters on web assessment,
while not the most in-depth chapters in the book, still contain a lot
of information that is covered nowhere else (servlet race conditions,
for example).

In fact, almost everything in this book is, if not new, covered more
expertly than anywhere I've seen. For anyone doing software security
assessment, this book is required reading. All 1200 pages of it.

Score: 5/5

- -dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFFcJDoB8JNm+PA+iURAiq7AJ49uq2jA+1CKtjuGS+iSJOYhZ8bXQCgkHKO
+93PGEQ3HWXUw8GKy5s458M=
=O+2X
-----END PGP SIGNATURE-----


From halvar at gmx.de  Sat Dec  2 10:31:28 2006
From: halvar at gmx.de (Halvar Flake)
Date: Sat, 2 Dec 2006 16:31:28 +0100
Subject: [Dailydave] Book Review: The Art of Software Security Assessment
References: <457090EE.6010008@immunityinc.com>
Message-ID: <001901c71626$f06eccb0$c7b2a8c0@D1NQ6Z1J>

Hey all,

I agree with Dave's assessment, but then again I might
be somewhat biased ! :)

Cheers,
Halvar
----- Original Message ----- 
From: "Dave Aitel" <dave at immunityinc.com>
To: "dailydave" <dailydave at lists.immunitysec.com>
Sent: Friday, December 01, 2006 9:30 PM
Subject: [Dailydave] Book Review: The Art of Software Security Assessment


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Book Review: The Art of Software Security Assessment
> written by Mark Dowd, John McDonald, Justin Schuh
> http://www.amazon.com/Art-Software-Security-Assessment-Vulnerabilities/dp/0321444426/ref=pd_bxgy_b_text_b/103-1902494-7928635
> Pages: 1200
>
> The temptation with a massive book, such as this one, is to use it as
> a reference. While no doubt valuable as a quick reference for people
> looking to know the exact problems with any given C API ("snprintf
> does what differently on Windows and Unix?"), this book is best read
> page by page. There are surprises sprinkled throughout.  Vulnerable
> example code is taken from real software applications, such as OpenBSD
> 3.6, Netscape, and OpenSSH. Of course, more than just a collection of
> code with mistakes highlighted, this book has a powerful methodology,
> complete with "Desk-checking", "Scorecards" and other useful tricks.
> This book is not about binary analysis; assembly language is used only
> to demonstrate tricky C code.
>
> Unlike many books with multiple authors, this is an extremely well put
> together book that flows naturally from chapter to chapter. The
> chapters on C auditing are amazing. The chapters on web assessment,
> while not the most in-depth chapters in the book, still contain a lot
> of information that is covered nowhere else (servlet race conditions,
> for example).
>
> In fact, almost everything in this book is, if not new, covered more
> expertly than anywhere I've seen. For anyone doing software security
> assessment, this book is required reading. All 1200 pages of it.
>
> Score: 5/5
>
> - -dave
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQFFcJDoB8JNm+PA+iURAiq7AJ49uq2jA+1CKtjuGS+iSJOYhZ8bXQCgkHKO
> +93PGEQ3HWXUw8GKy5s458M=
> =O+2X
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave 


From dave.aitel at gmail.com  Sat Dec  2 21:04:32 2006
From: dave.aitel at gmail.com (Dave Aitel)
Date: Sat, 2 Dec 2006 21:04:32 -0500
Subject: [Dailydave] Advanced Exercises for Hackers: Understanding your
	resources
Message-ID: <b581b3220612021804r779c45bbhcc39d3d81370f0a0@mail.gmail.com>

Give up all your Solaris RPC remotes. All your Tru64 tricks, all your
Microsoft client-sides. The bug classes no one has seen yet, forgotten. The
kernel trojans you use daily, gone. All your shells. The ISPs, the wacky
personal servers of the developers everyone else reveres. Your
ex-girlfriend's laptop. Every exploit and click-script. Lose everything you
know.

Give it all up, and never look back. If you are a Unix hacker, switch to
Microsoft. If Win32, install Linux and never call a Windows API ever again.

Now try again.

-dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20061202/4130907f/attachment.htm 

From anton at chuvakin.org  Sun Dec  3 00:49:01 2006
From: anton at chuvakin.org (Anton Chuvakin)
Date: Sat, 2 Dec 2006 21:49:01 -0800
Subject: [Dailydave] Advanced Exercises for Hackers: Understanding your
	resources
In-Reply-To: <b581b3220612021804r779c45bbhcc39d3d81370f0a0@mail.gmail.com>
References: <b581b3220612021804r779c45bbhcc39d3d81370f0a0@mail.gmail.com>
Message-ID: <b2591e2e0612022149l5d2026c3l87fbad12657019ed@mail.gmail.com>

> Now try again.

Somehow, this sounded really cool :-) Like, really, really super-cool!

-- 
Anton Chuvakin, Ph.D., GCIA, GCIH, GCFA
      http://www.chuvakin.org
  http://chuvakin.blogspot.com
    http://www.info-secure.org

From dave at immunityinc.com  Wed Dec  6 11:24:25 2006
From: dave at immunityinc.com (Dave Aitel)
Date: Wed, 06 Dec 2006 11:24:25 -0500
Subject: [Dailydave] Remote language detection
Message-ID: <4576EEB9.2080109@immunityinc.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In the podcast this week on eweek.com[2] I talk a tiny bit about the
changes going through penetration testing. I think there ARE major
changes. A penetration tester used to be the guy able to download
things from packetstorm.com and compile them and run them against your
servers. It was a database of knowledge of what worked and how to use
it that was in your head that was valuable. But the Googlization of
the world has rendered all sorts of head-databases less valuable.

When Immunity hires a penetration tester now, we hire someone who can
download that third party ISAPI filter, install it in a VM, find a
vulnerability in it, and then write the overflow to bypass your
unknown HIDS in two days or less.

There's been a commoditization of known vulnerabilities. I don't think
it will be that long from now where a penetration testing service that
does not offer 0day testing will be completely devalued. Essentially
this is where penetration testing is already, since most of what you
do in a test is web-based which is essentially 0day testing.

It's possible to get a remote shell against web applications too, it's
just not as easy as owning with bind-nxt and seeing a #. CANVAS has a
javaNode because during a penetration test we needed to abstract away
the idea that we could execute arbitrary Java on a WebLogic server.

One of the other things we've been doing lately is remote language
detection. Today we've released a small whitepaper about some of our
research which is available here[1]. Ask your questions about it here,
if you want, and I'll release a version 2.0 that answers them. :>

- -dave
[1]
http://www.immunityinc.com/resources-papers.shtml

[2]
http://www.eweek.com/article2/0,1895,2067349,00.asp

Defense by Offensive Hacking

December 4, 2006

*In this *OnSecurity* podcast: Immunity vulnerability researcher Dave
Aitel talks with eWEEK's Ryan Naraine about simulated hacking attacks,
new penetration testing tools and techniques, the resiliency of Vista,
and his unique take on the vulnerability disclosure debate.*

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFFdu63B8JNm+PA+iURAoMNAJ9HwEc8pwPcyi6l5T0oa2ZdnrlxGwCg7CW+
J80xuzAsnGqYM9weSNdQO+E=
=v3lb
-----END PGP SIGNATURE-----


From julien.tinnes at francetelecom.com  Thu Dec  7 13:48:00 2006
From: julien.tinnes at francetelecom.com (TINNES Julien RD-MAPS-ISS)
Date: Thu, 07 Dec 2006 19:48:00 +0100
Subject: [Dailydave] Madwifi SIOCSIWSCAN vulnerability (CVE-2006-6332)
Message-ID: <457861E0.9000700@francetelecom.com>

There is a kernel stack buffer overflow in Madwifi SIOCSIWSCAN ioctl
which is used to list scanned AP.

All version prior to 0.9.2.1 are probably vulnerable.

Users listing nearby access points (such as with "iwlist ath0 scan")
manually are at risk. As a lot of distributions are performing automatic
access point listings, this can put passive users at risk as well.

We wrote a remote DoS as well as a reliable local privilege escalation
exploit (which needs to be triggered by the remote DoS).
As the impact is not very critical (you have to be able to execute code
on the host AND to send a wireless packet), they will be released soon
as proof of concept.

A real remote exploit is very likely to be possible, against iwlist or
any other process using this ioctl (being in process context helps!),
however we've not investigated it further for now.

PS: Dave, will we have Wifi support in Canvas ?

-- 
Julien TINNES - & france telecom - R&D Division/MAPS/NSS
Research Engineer - Internet/Intranet Security
GPG: C050 EF1A 2919 FD87 57C4 DEDD E778 A9F0 14B9 C7D6
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 2006-12-07-madwifi-siocgiwscan.txt
Url: http://lists.immunitysec.com/pipermail/dailydave/attachments/20061207/cdf6237f/attachment-0001.txt 

From apconole at yahoo.com  Thu Dec  7 16:31:22 2006
From: apconole at yahoo.com (Aaron)
Date: Thu, 7 Dec 2006 13:31:22 -0800 (PST)
Subject: [Dailydave] [enumeration vulnerability] Mobile IP,
	dynamics mip implementation, and you
Message-ID: <120030.98422.qm@web60420.mail.yahoo.com>

This is my first real security related mailing, so I
hope it's acceptable. A search on the web revealed
that no one has yet pointed out this flaw, so I figure
I will.

In the MIP rfc 2002 and 3220 specs, neither talk about
authentication failures, or when it is acceptable NOT
to include the authentication extension. In fact,
these specs go as far as to include error cases when
we have failed authentications, and mandate that an
authentication extension be returned.

Since the signaling messages are sent in "clear text,"
meaning that any schmuck with ethereal or some other
sniffing tool can read the packets, and the
information within, it's not unforseeable that a
potential evil user can send messages to the MIP
foreign, or home agent and listen for the registration
reply with whatever error code. Based on that, he can
use a brute force tool, or even some rainbow crack
lookups and potentially extract the users secret key.
In the even that such a thing happened, the evil user
can hijack legitimate users packet data sessions.

I'll be writing a case study using the Dynamics Mobile
IP implementation, as well as releasing a patch to
dynamics so that it will simply drop any messages that
could potentially be used for enumeration against
Mobile IP agents.

Just figured I'd release this information out there.
-Aaron


 
____________________________________________________________________________________
Have a burning question?  
Go to www.Answers.yahoo.com and get answers from real people who know.

From coley at mitre.org  Thu Dec  7 17:23:12 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 7 Dec 2006 17:23:12 -0500 (EST)
Subject: [Dailydave] A really bad month for Novell
Message-ID: <200612072223.kB7MNCG1008709@faron.mitre.org>


"Anton Chuvakin" <anton at chuvakin.org> said:

>Wow, did something happen in the world and I totally missed it? Is
>this what they call a "best practice" (yak!) now...? 1 year and 3
>months to report a vuln to a vendor...

You sometimes see these kinds of tidbits in iDEFENSE advisories, too.
I'm not sure of the reason for it, although maybe there's a delay
while they verify if the issue is real, and/or figure out who to
notify at the vendor.  Which I know many researchers can relate to :)

- Steve

From coley at mitre.org  Thu Dec  7 17:27:51 2006
From: coley at mitre.org (Steven M. Christey)
Date: Thu, 7 Dec 2006 17:27:51 -0500 (EST)
Subject: [Dailydave] Remote language detection
Message-ID: <200612072227.kB7MRpv7008741@faron.mitre.org>


>There's been a commoditization of known vulnerabilities. I don't think
>it will be that long from now where a penetration testing service that
>does not offer 0day testing will be completely devalued. Essentially
>this is where penetration testing is already, since most of what you
>do in a test is web-based which is essentially 0day testing.

If so, then this could be a worrisome trend if professionals keep
off-the-shelf 0days for a competitive advantage instead of notifying
the vendors and working on a fix.  Obviously location-specific custom
software does not apply here.

I think something similar to that happened in the early days of
vulnerability scanners.

- Steve

From ge at linuxbox.org  Thu Dec  7 18:28:38 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Thu, 7 Dec 2006 17:28:38 -0600 (CST)
Subject: [Dailydave] [enumeration vulnerability] Mobile IP,
 dynamics mip implementation, and you
In-Reply-To: <120030.98422.qm@web60420.mail.yahoo.com>
Message-ID: <Pine.LNX.4.21.0612071727530.1965-100000@linuxbox.org>

On Thu, 7 Dec 2006, Aaron wrote:
> This is my first real security related mailing, so I
> hope it's acceptable. A search on the web revealed
> that no one has yet pointed out this flaw, so I figure
> I will.

It's cool. Thanks for sharing. :)

However, part of the community is also peer review. A friend just noted:

"As for the specific issues raised below -- it's far too long since I've
read those RFCs, so I can't comment in detail; I will note that both
are listed as Obsolete in the RFC index.  RFC 3344 is the current MIP
document, and any criticisms should be probably be based on it."


> 
> In the MIP rfc 2002 and 3220 specs, neither talk about
> authentication failures, or when it is acceptable NOT
> to include the authentication extension. In fact,
> these specs go as far as to include error cases when
> we have failed authentications, and mandate that an
> authentication extension be returned.
> 
> Since the signaling messages are sent in "clear text,"
> meaning that any schmuck with ethereal or some other
> sniffing tool can read the packets, and the
> information within, it's not unforseeable that a
> potential evil user can send messages to the MIP
> foreign, or home agent and listen for the registration
> reply with whatever error code. Based on that, he can
> use a brute force tool, or even some rainbow crack
> lookups and potentially extract the users secret key.
> In the even that such a thing happened, the evil user
> can hijack legitimate users packet data sessions.
> 
> I'll be writing a case study using the Dynamics Mobile
> IP implementation, as well as releasing a patch to
> dynamics so that it will simply drop any messages that
> could potentially be used for enumeration against
> Mobile IP agents.
> 
> Just figured I'd release this information out there.
> -Aaron
> 
> 
>  
> ____________________________________________________________________________________
> Have a burning question?  
> Go to www.Answers.yahoo.com and get answers from real people who know.
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
> 


From apconole at yahoo.com  Thu Dec  7 20:33:29 2006
From: apconole at yahoo.com (Aaron)
Date: Thu, 7 Dec 2006 17:33:29 -0800 (PST)
Subject: [Dailydave] [enumeration vulnerability] Mobile IP,
	dynamics mip implementation, and you
In-Reply-To: <Pine.LNX.4.21.0612071727530.1965-100000@linuxbox.org>
Message-ID: <20061208013329.67379.qmail@web60415.mail.yahoo.com>

>It's cool. Thanks for sharing. :)
>
>However, part of the community is also peer review. A friend just noted:
>
>"As for the specific issues raised below -- it's far too long since I've
>read those RFCs, so I can't comment in detail; I will note that both
>are listed as Obsolete in the RFC index.  RFC 3344 is the current MIP
>document, and any criticisms should be probably be based on it."

RFC 3344 also has the same issue. It specifies that the reg-reply should contain an authentication extension, and specifies a reply code for authentication failures by mobile node, and home agent.

The issue isn't just the RFC though, as I noted in my original post. It's also with specific implementations of the mobile IP standard. The implementation in question is the Dynamics implementation, however, I know of at least one other Mobile IP-like protocol (A11 interface in 1xEV-DO networks) which have this enumeration problem.

-Aaron


Gadi Evron <ge at linuxbox.org> wrote: On Thu, 7 Dec 2006, Aaron wrote:
> This is my first real security related mailing, so I
> hope it's acceptable. A search on the web revealed
> that no one has yet pointed out this flaw, so I figure
> I will.

It's cool. Thanks for sharing. :)

However, part of the community is also peer review. A friend just noted:

"As for the specific issues raised below -- it's far too long since I've
read those RFCs, so I can't comment in detail; I will note that both
are listed as Obsolete in the RFC index.  RFC 3344 is the current MIP
document, and any criticisms should be probably be based on it."


> 
> In the MIP rfc 2002 and 3220 specs, neither talk about
> authentication failures, or when it is acceptable NOT
> to include the authentication extension. In fact,
> these specs go as far as to include error cases when
> we have failed authentications, and mandate that an
> authentication extension be returned.
> 
> Since the signaling messages are sent in "clear text,"
> meaning that any schmuck with ethereal or some other
> sniffing tool can read the packets, and the
> information within, it's not unforseeable that a
> potential evil user can send messages to the MIP
> foreign, or home agent and listen for the registration
> reply with whatever error code. Based on that, he can
> use a brute force tool, or even some rainbow crack
> lookups and potentially extract the users secret key.
> In the even that such a thing happened, the evil user
> can hijack legitimate users packet data sessions.
> 
> I'll be writing a case study using the Dynamics Mobile
> IP implementation, as well as releasing a patch to
> dynamics so that it will simply drop any messages that
> could potentially be used for enumeration against
> Mobile IP agents.
> 
> Just figured I'd release this information out there.
> -Aaron
> 
> 
>  
> ____________________________________________________________________________________
> Have a burning question?  
> Go to www.Answers.yahoo.com and get answers from real people who know.
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
> 



 
---------------------------------
Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20061207/42ee8a99/attachment-0001.htm 

From apconole at yahoo.com  Thu Dec  7 20:44:23 2006
From: apconole at yahoo.com (Aaron)
Date: Thu, 7 Dec 2006 17:44:23 -0800 (PST)
Subject: [Dailydave] [enumeration vulnerability] Mobile IP,
	dynamics mip implementation, and you
In-Reply-To: <Pine.LNX.4.21.0612071727530.1965-100000@linuxbox.org>
Message-ID: <121626.37126.qm@web60418.mail.yahoo.com>

Actually, after a further review of 3344, it seems as though section 3.2.7.1 does address this issue now.

"If no Mobile-Foreign Authentication Extension is found, or if more than one Mobile-Foreign
Authentication Extension is found, or if the Authenticator is
invalid, the foreign agent MUST silently discard the Request and
SHOULD log the event as a security exception"

Thank you for pointing this out.

Gadi Evron <ge at linuxbox.org> wrote: On Thu, 7 Dec 2006, Aaron wrote:
> This is my first real security related mailing, so I
> hope it's acceptable. A search on the web revealed
> that no one has yet pointed out this flaw, so I figure
> I will.

It's cool. Thanks for sharing. :)

However, part of the community is also peer review. A friend just noted:

"As for the specific issues raised below -- it's far too long since I've
read those RFCs, so I can't comment in detail; I will note that both
are listed as Obsolete in the RFC index.  RFC 3344 is the current MIP
document, and any criticisms should be probably be based on it."


> 
> In the MIP rfc 2002 and 3220 specs, neither talk about
> authentication failures, or when it is acceptable NOT
> to include the authentication extension. In fact,
> these specs go as far as to include error cases when
> we have failed authentications, and mandate that an
> authentication extension be returned.
> 
> Since the signaling messages are sent in "clear text,"
> meaning that any schmuck with ethereal or some other
> sniffing tool can read the packets, and the
> information within, it's not unforseeable that a
> potential evil user can send messages to the MIP
> foreign, or home agent and listen for the registration
> reply with whatever error code. Based on that, he can
> use a brute force tool, or even some rainbow crack
> lookups and potentially extract the users secret key.
> In the even that such a thing happened, the evil user
> can hijack legitimate users packet data sessions.
> 
> I'll be writing a case study using the Dynamics Mobile
> IP implementation, as well as releasing a patch to
> dynamics so that it will simply drop any messages that
> could potentially be used for enumeration against
> Mobile IP agents.
> 
> Just figured I'd release this information out there.
> -Aaron
> 
> 
>  
> ____________________________________________________________________________________
> Have a burning question?  
> Go to www.Answers.yahoo.com and get answers from real people who know.
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
> 



 
---------------------------------
Want to start your own business? Learn how on Yahoo! Small Business.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20061207/624fddcf/attachment-0001.htm 

From julien.tinnes at francetelecom.com  Fri Dec  8 05:44:56 2006
From: julien.tinnes at francetelecom.com (TINNES Julien RD-MAPS-ISS)
Date: Fri, 08 Dec 2006 11:44:56 +0100
Subject: [Dailydave] Madwifi SIOCSIWSCAN vulnerability (CVE-2006-6332)
In-Reply-To: <457861E0.9000700@francetelecom.com>
References: <457861E0.9000700@francetelecom.com>
Message-ID: <45794228.7090309@francetelecom.com>

Here it is, metasploit 3 DoS module and a very simple and raw local
exploit (which needs to be triggered by the DoS module).

A full remote exploit is possible, which would be triggered by "iwlist
ath0 scan".
You can inject code into the process' address space by using some
information elements.

-- 
Julien TINNES - & france telecom - R&D Division/MAPS/NSS
Research Engineer - Internet/Intranet Security
GPG: C050 EF1A 2919 FD87 57C4 DEDD E778 A9F0 14B9 C7D6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: madexploit.c
Type: text/x-csrc
Size: 12384 bytes
Desc: not available
Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20061208/94f538dd/attachment-0001.c 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: madwifi_giwscan_cb.rb
Type: application/x-ruby
Size: 4278 bytes
Desc: not available
Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20061208/94f538dd/attachment-0001.bin 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 2006-12-07-madwifi-siocgiwscan.txt
Url: http://lists.immunitysec.com/pipermail/dailydave/attachments/20061208/94f538dd/attachment-0001.txt 

From danett18 at yahoo.com.br  Fri Dec  8 22:43:53 2006
From: danett18 at yahoo.com.br (Danett song)
Date: Sat, 9 Dec 2006 00:43:53 -0300 (ART)
Subject: [Dailydave] Local Binary Fuzzer In Perl?
Message-ID: <506517.90107.qm@web54302.mail.yahoo.com>

       Hi guys,
  
  I'm looking for a local binary fuzzer similar to bfbtester  (http://bfbtester.sourceforge.net/), however wrotten in perl (cause I  need to use it in other computers/arch without gcc and impossible to install  it in a compiler).
  
  Anyone can give me a light? :)
  
  Thank you,
  
  Regards.
  
 		
---------------------------------
 Yahoo! Search
 M?sica para ver e ouvir: You're Beautiful, do James Blunt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20061209/901a5cc0/attachment.htm 

From dan at geer.org  Mon Dec 11 14:55:32 2006
From: dan at geer.org (dan at geer.org)
Date: Mon, 11 Dec 2006 14:55:32 -0500
Subject: [Dailydave] NSRL status check
Message-ID: <20061211195532.4E67C1BF924@absinthe.tinho.net>


The National Software Reference Library has or had a listing of the
hash values for known good software, known good in the sense of
what is on installation media or what otherwise still has its
integrity intact.

I say "has or had" as on first glance it appears that this listing
is stationary since sometime in 2004.  Would someone here know the
history and fate of this list?  On the face of it such a list seems
useful in forensic situations at least.

--dan


From ge at linuxbox.org  Mon Dec 11 16:07:01 2006
From: ge at linuxbox.org (Gadi Evron)
Date: Mon, 11 Dec 2006 15:07:01 -0600 (CST)
Subject: [Dailydave] NSRL status check
In-Reply-To: <20061211195532.4E67C1BF924@absinthe.tinho.net>
Message-ID: <Pine.LNX.4.21.0612111505180.20142-100000@linuxbox.org>

On Mon, 11 Dec 2006 dan at geer.org wrote:
> 
> The National Software Reference Library has or had a listing of the
> hash values for known good software, known good in the sense of
> what is on installation media or what otherwise still has its
> integrity intact.
> 
> I say "has or had" as on first glance it appears that this listing
> is stationary since sometime in 2004.  Would someone here know the
> history and fate of this list?  On the face of it such a list seems
> useful in forensic situations at least.

Zone Labs (now CheckPoint) has their own listing. They whitelist known
programs. "X per cent of our users believe this program is good". That way
people can make more educated decisions on programs which want to connect
to the Internet. Blacklisting bad files is not practical, or it would be
yet another almost useless anti virus.

Naturally, this has a lot of applications.

	Gadi.

> --dan
> 
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
> 


From hso at nosneros.net  Mon Dec 11 16:07:35 2006
From: hso at nosneros.net (Holt Sorenson)
Date: Mon, 11 Dec 2006 21:07:35 +0000
Subject: [Dailydave] NSRL status check
Message-ID: <20061211210734.GB17475@tellme.com>

On Mon, Dec 11, 2006 at 02:55:32PM -0500, dan at geer.org wrote:
 > 
 > The National Software Reference Library has or had a listing of the
 > hash values for known good software, known good in the sense of
 > what is on installation media or what otherwise still has its
 > integrity intact.
 > 
 > I say "has or had" as on first glance it appears that this listing
 > is stationary since sometime in 2004.  Would someone here know the
 > history and fate of this list? 

The way I read it, the most recent release was made October 2006:
http://www.nsrl.nist.gov/Downloads.htm#isos

 > On the face of it such a list seems useful in forensic situations
 > at least.

Indeed. Most commercial forensic software comes with instructions on
how to use NSRL RDS with the software.

-Holt


From joanna at invisiblethings.org  Tue Dec 12 07:37:40 2006
From: joanna at invisiblethings.org (Joanna Rutkowska)
Date: Tue, 12 Dec 2006 13:37:40 +0100
Subject: [Dailydave] NSRL status check
In-Reply-To: <20061211195532.4E67C1BF924@absinthe.tinho.net>
References: <20061211195532.4E67C1BF924@absinthe.tinho.net>
Message-ID: <457EA294.5070802@invisiblethings.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

dan at geer.org wrote:
> The National Software Reference Library has or had a listing of the
> hash values for known good software, known good in the sense of
> what is on installation media or what otherwise still has its
> integrity intact.
> 
> I say "has or had" as on first glance it appears that this listing
> is stationary since sometime in 2004.  Would someone here know the
> history and fate of this list?  On the face of it such a list seems
> useful in forensic situations at least.
> 

Instead of white-listing all the good executables (which is of course
much better then listing all the bad ones, but scales very poor as well)
it would be much better, IMO, to require that all vendors sign their
executables with a certificate. That could be even a self-signed
certificate - the point is that we could then list all the certificates
that we trust. In other words we would have a list of all the software
vendors we trust together with fingerprints for the certificates they
use for signing their programs.

Yes, I know that all the paranoid people would say: "software vendors
can not be trusted!". But that's actually what it is - a paranoia ;) And
it's better to trust software vendors that your A/V vendors ;) Sorry to
all A/V vendors - it's nothing personal - I just don't believe in
blacklisting :/

joanna.
-----BEGIN PGP SIGNATURE-----

iD8DBQFFfqKTORdkotfEW84RAlnyAKD6Dxdz2Sgq3lnFmWtOoYsFr9lA3gCgif7B
LWE1Rt4y+oU/ciS/Oky1fdw=
=E3pZ
-----END PGP SIGNATURE-----

From lance at honeynet.org  Tue Dec 12 09:58:35 2006
From: lance at honeynet.org (Lance Spitzner)
Date: Tue, 12 Dec 2006 08:58:35 -0600
Subject: [Dailydave] NSRL status check
In-Reply-To: <20061211210734.GB17475@tellme.com>
References: <20061211210734.GB17475@tellme.com>
Message-ID: <439C2B7D-3B8E-4DD0-9AF3-75DA7486800C@honeynet.org>

> The way I read it, the most recent release was made October 2006:
> http://www.nsrl.nist.gov/Downloads.htm#isos
>
>> On the face of it such a list seems useful in forensic situations
>> at least.
>
> Indeed. Most commercial forensic software comes with instructions on
> how to use NSRL RDS with the software.

When I used to work for Sun on incident response, Sun maintained a  
MD5 repository (and they may still do so today), of all the known  
binaries released by Sun. The idea was, you could do an automated  
check on a system, looking for Sun binaries that did not match any  
known signatures.  Based on this model, an easy way to create a  
backdoor would be to simply replace a current binary/file with  
another known/valid file, but one that is much older and with known  
vulnerabilities.

lance

From leviticus at gmail.com  Tue Dec 12 16:49:22 2006
From: leviticus at gmail.com (Kevin Stadmeyer)
Date: Tue, 12 Dec 2006 16:49:22 -0500
Subject: [Dailydave] NSRL status check
In-Reply-To: <457EA294.5070802@invisiblethings.org>
References: <20061211195532.4E67C1BF924@absinthe.tinho.net>
	<457EA294.5070802@invisiblethings.org>
Message-ID: <bcc2b3310612121349k56515868kb5d92bf6ad7d8d89@mail.gmail.com>

I think the best way would be a combination of both techniques. I don't look
at it as a question of not trusting software vendors but rather a question
of degrees of comfort regarding privacy related information. It is a good
thing to verify that whoever says they wrote the software actually wrote it,
but you also need to be sure that its doing what its supposed to be doing
and nothing more (i.e., sending back personally identifiable information
when they say its anonymous) which is where the user generated white list
would come in. The A/V software can pop up a box similar to SSL certs saying
"Yes it was written by X Company, but only 25% of users trust it to connect
to the internet"

I dont think that's paranoia, its just common sense.

On 12/12/06, Joanna Rutkowska <joanna at invisiblethings.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> dan at geer.org wrote:
> > The National Software Reference Library has or had a listing of the
> > hash values for known good software, known good in the sense of
> > what is on installation media or what otherwise still has its
> > integrity intact.
> >
> > I say "has or had" as on first glance it appears that this listing
> > is stationary since sometime in 2004.  Would someone here know the
> > history and fate of this list?  On the face of it such a list seems
> > useful in forensic situations at least.
> >
>
> Instead of white-listing all the good executables (which is of course
> much better then listing all the bad ones, but scales very poor as well)
> it would be much better, IMO, to require that all vendors sign their
> executables with a certificate. That could be even a self-signed
> certificate - the point is that we could then list all the certificates
> that we trust. In other words we would have a list of all the software
> vendors we trust together with fingerprints for the certificates they
> use for signing their programs.
>
> Yes, I know that all the paranoid people would say: "software vendors
> can not be trusted!". But that's actually what it is - a paranoia ;) And
> it's better to trust software vendors that your A/V vendors ;) Sorry to
> all A/V vendors - it's nothing personal - I just don't believe in
> blacklisting :/
>
> joanna.
> -----BEGIN PGP SIGNATURE-----
>
> iD8DBQFFfqKTORdkotfEW84RAlnyAKD6Dxdz2Sgq3lnFmWtOoYsFr9lA3gCgif7B
> LWE1Rt4y+oU/ciS/Oky1fdw=
> =E3pZ
> -----END PGP SIGNATURE-----
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20061212/42f9d8dc/attachment.htm 

From joanna at invisiblethings.org  Tue Dec 12 19:25:50 2006
From: joanna at invisiblethings.org (Joanna Rutkowska)
Date: Wed, 13 Dec 2006 01:25:50 +0100
Subject: [Dailydave] NSRL status check
In-Reply-To: <Pine.LNX.4.21.0612121617100.11151-100000@linuxbox.org>
References: <Pine.LNX.4.21.0612121617100.11151-100000@linuxbox.org>
Message-ID: <457F488E.8040002@invisiblethings.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gadi Evron wrote:
> Yes, I know that all the paranoid people would say: "software vendors
> can not be trusted!". But that's actually what it is - a paranoia ;) And
> it's better to trust software vendors that your A/V vendors ;) Sorry to
> all A/V vendors - it's nothing personal - I just don't believe in
> blacklisting :/
> 
>> Many of them already do. And it's often the AV vendors who sign their
>> binaires.
> 

How can they do that if most of the applications are not signed today?
Also, I'm not talking about prevention, I'm talking about verification.
Please do note the difference.

joanna.
-----BEGIN PGP SIGNATURE-----

iD8DBQFFf0iNORdkotfEW84RAlAPAJ45M204/eg9yDjFitNvkRwa2nhchQCfU38h
hQrzidKFH9ZbAuafUDa0yRw=
=S6+d
-----END PGP SIGNATURE-----

From dr at kyx.net  Wed Dec 13 18:57:33 2006
From: dr at kyx.net (Dragos Ruiu)
Date: Wed, 13 Dec 2006 15:57:33 -0800
Subject: [Dailydave] CanSecWest 2007 (April 18-20) Call For Papers (Deadline
	January 7th)
Message-ID: <200612131557.33236.dr@kyx.net>

CanSecWest 2007 CALL FOR PAPERS

VANCOUVER, Canada -- The eighth annual CanSecWest applied technical security 
conference - where the eminent figures in the international security industry 
will get together share best practices and technology - will be held in 
downtown Vancouver at the the Mariott Renaissance Harbourside on April 18-20, 
2007. The most significant new discoveries about computer network hack 
attacks and defenses, commercial security solutions, and pragmatic real world 
security experience will be presented in a series of informative tutorials. 

The CanSecWest 2007 meeting provides international researchers a relaxed, 
comfortable environment to learn from informative tutorials on key 
developments in security technology, and collaborate and socialize with their 
peers in one of the world's most scenic cities - a short drive away from one 
of North America's top skiing areas. 

The CanSecWest 2007 conference will also feature the availability of the 
Security Masters Dojo expert network security sensei instructors, and their 
advanced, and intermediate, hands-on training courses - featuring small class 
sizes and practical application excercises to maximize information transfer. 

We would like to announce the opportunity to submit papers, and/or lightning 
talk proposals, for selection by the CanSecWest technical review committee. 
Please make your paper proposal submissions before January 7th, 2007. Slides 
for the papers must be submitted by March 15th, 2007. 

Some invited papers have been confirmed, but a limited number of speaking 
slots are still available. The conference is responsible for travel and 
accomodations for the speakers. If you have a proposal for a tutorial session 
then please email a synopsis of the material and your biography, papers and, 
speaking background to secwes07 at cansecwest.com. Only slides will be needed 
for the March paper deadline, full text does not have to be submitted - but 
will be accepted if available. 

The CanSecWest 2007 conference consists of tutorials on technical details 
about current issues, innovative techniques and best practices in the 
information security realm. The audiences are a multi-national mix of 
professionals involved on a daily basis with security work: security product 
vendors, programmers, security officers, and network administrators. We give 
preference to technical details and new education for a technical audience. 

The conference itself is a single track series of presentations in a lecture 
theater environment. The presentations offer speakers the opportunity to 
showcase on-going research and collaborate with peers while educating and 
highlighting advancements in security products and techniques. The focus is 
on innovation, tutorials, and education instead of product pitches. Some 
commercial content is tolerated, but it needs to be backed up by a technical 
presenter - either giving a valuable tutorial and best practices instruction 
or detailing significant new technology in the products. 

Paper proposals should consist of the following information: 

1) Presenter, and geographical location (country of origin/passport) and 
contact info (e-mail, postal address, phone, fax). 
2) Employer and/or affiliations. 
3) Brief biography, list of publications and papers. 
4) Any significant presentation and educational experience/background. 
5) Topic synopsis, Proposed paper title, and a one paragraph description. 
6) Reason why this material is innovative or significant or an important 
tutorial. 
7) Optionally, any samples of prepared material or outlines ready. 
8) Will you have full text available or only slides? 
9) Please list any other publications or conferences where this material has 
been or will be published/submitted. 

Please include the plain text version of this information in your email as 
well as any file, pdf, sxw, ppt, or html attachments. (Some reviewers only
look at .txt info.) Multiple submissions are acceptable.

Please forward the above information to be considered for placement on the 
speaker roster, or have your short lightning talk scheduled. Send all 
conference related correspondence to secwes07 at cansecwest.com.

thanks,
--dr

-- 
World Security Pros. Cutting Edge Training, Tools, and Techniques
London, U.K.    Feb 28 / Mar 1 - 2007    http://eusecwest.com
pgpkey http://dragos.com/ kyxpgp

From kyle.c.quest at gmail.com  Tue Dec 19 18:51:09 2006
From: kyle.c.quest at gmail.com (C Q)
Date: Tue, 19 Dec 2006 18:51:09 -0500
Subject: [Dailydave] Invitation (was: The Assimilation of Sysinternals)
Message-ID: <ba5afa010612191551i1d56a5aaq98b30c39c00220ef@mail.gmail.com>

Sorry if I upset somebody by the post...

Speaking of programming cool system utilities and playing
with windows internals. If somebody likes doing things
like that for a living and lives here on the east coast
I have something you might be interested in...
Contact me off list and we'll talk details...

Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20061219/b78e5a40/attachment.htm 

From dave at immunityinc.com  Thu Dec 21 22:43:05 2006
From: dave at immunityinc.com (Dave Aitel)
Date: Thu, 21 Dec 2006 22:43:05 -0500
Subject: [Dailydave] From int $13 to distributed object clouds
Message-ID: <458B5449.5000809@immunityinc.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The question you have to ask yourself when dealing with, as Sinan
would call it, "NP Complete Stuff" (aka, anything academic and wanky)
is "How is this going to help me hack something". Lately I've been, in
the back of my head, obsessed with distributed object languages. But
how can I explain that having your language abstract not just memory
management, but also parallelism, is going to help you break into more
computers faster and better?

The problem set is easy to understand: scanning a range of IP
addresses for exploitable vulnerabilities and then exploiting them.
People look at that and say "Easy to parallelize. Just split it up
based on IP range.". They'd be wrong - IP addresses are connected to
each other in many ways. They need to be grouped intelligently, and
deep down, we're breaking into machines, not IP addresses. Some IP
addresses are the same machine, and we need to know that 10.0.1.1 and
10.0.2.1 are the same machine even if they've been split up across
scanning processes which reside on different computing clouds. We also
need to use information gained from hacking 10.0.1.1 against 10.0.2.1.

Something in my right brain is telling me parallelism is the next big
step for something like CANVAS. Not simple "split it up into bite size
pieces", but intelligent parallelism handled by a language that is as
much like Python as possible, but time abstract. Possibly the easier
next step is built-in data-mining and CRM. When we do open source data
collection on a target, I need somewhere to enter that in that can
reuse that information automatically. And when I own 10,000 machines,
I need to be able to mine that cloud for the information I'm
interested in, covertly.

Of course, in the meantime it's shellcode shellcode shellcode. No
hacker ever truly gets away from that. Even here in Aotearoa there's
an int $13 waiting...
 
- -dave

P.S. Congrats to NFR :>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFi1RJtehAhL0gheoRAn0DAJ4tgAliqNiHVufan4NRUaS3GhxhuACeNEcQ
Yb78CC9ktq3EmY34FWj4vCU=
=6K+Q
-----END PGP SIGNATURE-----


From brian at gfi.com  Fri Dec 22 04:06:37 2006
From: brian at gfi.com (Brian Azzopardi)
Date: Fri, 22 Dec 2006 10:06:37 +0100
Subject: [Dailydave] From int $13 to distributed object clouds
Message-ID: <42B56C6A683EBA4581C01CB49A914CA70A24476E@MAILFAXSRV.gfimalta.com>


> They need to be grouped intelligently

Can't you group IPs intelligently and then farm out the groups to be
handled in parallel?


> Some IP addresses are the same machine, and we need to know that
10.0.1.1 and 10.0.2.1 are the same machine

You can do that as a post-process (assuming you don't do the intelligent
grouping first).


>  intelligent parallelism handled by a language

What do you understand by intelligent parallelism? Is Occam intelligent
enough? Do you prefer implicit parallelism?

Just for the record, I am working (slowly) on an new language that has
parallelism as fundamental part of the language, rather than tacked on
to it via threads like Python/C++/etc.


Brian



-----Original Message-----
From: dailydave-bounces at lists.immunitysec.com
[mailto:dailydave-bounces at lists.immunitysec.com] On Behalf Of Dave Aitel
Sent: Friday, December 22, 2006 4:43 AM
To: dailydave at lists.immunitysec.com
Subject: [Dailydave] From int $13 to distributed object clouds

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The question you have to ask yourself when dealing with, as Sinan would
call it, "NP Complete Stuff" (aka, anything academic and wanky) is "How
is this going to help me hack something". Lately I've been, in the back
of my head, obsessed with distributed object languages. But how can I
explain that having your language abstract not just memory management,
but also parallelism, is going to help you break into more computers
faster and better?

The problem set is easy to understand: scanning a range of IP addresses
for exploitable vulnerabilities and then exploiting them.
People look at that and say "Easy to parallelize. Just split it up based
on IP range.". They'd be wrong - IP addresses are connected to each
other in many ways. They need to be grouped intelligently, and deep
down, we're breaking into machines, not IP addresses. Some IP addresses
are the same machine, and we need to know that 10.0.1.1 and
10.0.2.1 are the same machine even if they've been split up across
scanning processes which reside on different computing clouds. We also
need to use information gained from hacking 10.0.1.1 against 10.0.2.1.

Something in my right brain is telling me parallelism is the next big
step for something like CANVAS. Not simple "split it up into bite size
pieces", but intelligent parallelism handled by a language that is as
much like Python as possible, but time abstract. Possibly the easier
next step is built-in data-mining and CRM. When we do open source data
collection on a target, I need somewhere to enter that in that can reuse
that information automatically. And when I own 10,000 machines, I need
to be able to mine that cloud for the information I'm interested in,
covertly.

Of course, in the meantime it's shellcode shellcode shellcode. No hacker
ever truly gets away from that. Even here in Aotearoa there's an int $13
waiting...
 
- -dave

P.S. Congrats to NFR :>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFi1RJtehAhL0gheoRAn0DAJ4tgAliqNiHVufan4NRUaS3GhxhuACeNEcQ
Yb78CC9ktq3EmY34FWj4vCU=
=6K+Q
-----END PGP SIGNATURE-----

_______________________________________________
Dailydave mailing list
Dailydave at lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave

DISCLAIMER
The information contained in this electronic mail may be confidential or
legally privileged. It is for the intended recipient(s) only. Should you
receive this message in error, please notify the sender by replying to
this mail. Unless expressly stated, opinions in this message are those
of the individual sender and not of GFI. Unauthorized use of the
contents is strictly prohibited. While all care has been taken, GFI is
not responsible for the integrity of the contents of this electronic
mail and any attachments included within.  

This mail was checked for viruses by GFI MailSecurity. 
GFI also develops anti-spam software (GFI MailEssentials), a fax server (GFI FAXmaker), and network security and management software (GFI LANguard) - www.gfi.com 



From jon.passki at hursk.com  Fri Dec 22 14:15:28 2006
From: jon.passki at hursk.com (Jon Passki)
Date: Fri, 22 Dec 2006 13:15:28 -0600
Subject: [Dailydave] From int $13 to distributed object clouds
In-Reply-To: <42B56C6A683EBA4581C01CB49A914CA70A24476E@MAILFAXSRV.gfimalta.com>
References: <42B56C6A683EBA4581C01CB49A914CA70A24476E@MAILFAXSRV.gfimalta.com>
Message-ID: <100A25A5-3A8C-4AC4-9D12-6ACB48B4C51A@hursk.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Dec 22, 2006, at 03:06 , Brian Azzopardi wrote:

>
>> They need to be grouped intelligently
>
> Can't you group IPs intelligently and then farm out the groups to be
> handled in parallel?
>

If I'm not hitting on the hookah too hard and understand what Dave's  
talking about , partitioning the universe of our hosts will occur  
more than once.  This is different than parallelism with one-time  
partitioning, ran until completion on a host.  The parallelism,  
methinks, would have to be dynamic and flexible (perhaps  
intelligent :-).  For example, assuming a zero-knowledge beginning,  
there's no way to start grouping IP's/targets/assets until something  
is learned, besides the asset identifier.  If you group as soon as  
something is known, such as subnet location of externally-facing IP  
addresses, and then want to regroup later on, such as subnet location  
of internally-facing IP addresses, all the hosts performing the  
parallelism potentially need to reshuffle their groups.


>
>> Some IP addresses are the same machine, and we need to know that
> 10.0.1.1 and 10.0.2.1 are the same machine
>
> You can do that as a post-process (assuming you don't do the  
> intelligent
> grouping first).

What's the point of messing with 1.1 if you already have it under the  
identity of 2.1?  If the goal is to perform as little action as  
possible (e.g. to be covert, to quickly gather data, and/or to reduce  
data analysis and post-grouping), then this is a wasted action. It  
just becomes a balance between the cost of reaching this goal and the  
cost of violating this goal.  Going w/ the concept above of  
regrouping and reshuffling the parallelism, one would want to perform  
the least amount of overlapping tests across all assets or groups of  
assets.  Since, if you reshuffle later, it would be ideal to combine  
disjointed sets versus identical sets.  Again, there's a cost in  
doing this...

>
>
>>  intelligent parallelism handled by a language
>
> What do you understand by intelligent parallelism? Is Occam  
> intelligent
> enough? Do you prefer implicit parallelism?
>
> Just for the record, I am working (slowly) on an new language that has
> parallelism as fundamental part of the language, rather than tacked on
> to it via threads like Python/C++/etc.
>
>
> Brian
>
>
>
> -----Original Message-----
> From: dailydave-bounces at lists.immunitysec.com
> [mailto:dailydave-bounces at lists.immunitysec.com] On Behalf Of Dave  
> Aitel
> Sent: Friday, December 22, 2006 4:43 AM
> To: dailydave at lists.immunitysec.com
> Subject: [Dailydave] From int $13 to distributed object clouds
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The question you have to ask yourself when dealing with, as Sinan  
> would
> call it, "NP Complete Stuff" (aka, anything academic and wanky) is  
> "How
> is this going to help me hack something". Lately I've been, in the  
> back
> of my head, obsessed with distributed object languages. But how can I
> explain that having your language abstract not just memory management,
> but also parallelism, is going to help you break into more computers
> faster and better?
>
> The problem set is easy to understand: scanning a range of IP  
> addresses
> for exploitable vulnerabilities and then exploiting them.
> People look at that and say "Easy to parallelize. Just split it up  
> based
> on IP range.". They'd be wrong - IP addresses are connected to each
> other in many ways. They need to be grouped intelligently, and deep
> down, we're breaking into machines, not IP addresses. Some IP  
> addresses
> are the same machine, and we need to know that 10.0.1.1 and
> 10.0.2.1 are the same machine even if they've been split up across
> scanning processes which reside on different computing clouds. We also
> need to use information gained from hacking 10.0.1.1 against 10.0.2.1.
>
> Something in my right brain is telling me parallelism is the next big
> step for something like CANVAS. Not simple "split it up into bite size
> pieces", but intelligent parallelism handled by a language that is as
> much like Python as possible, but time abstract. Possibly the easier
> next step is built-in data-mining and CRM. When we do open source data
> collection on a target, I need somewhere to enter that in that can  
> reuse
> that information automatically. And when I own 10,000 machines, I need
> to be able to mine that cloud for the information I'm interested in,
> covertly.
>
> Of course, in the meantime it's shellcode shellcode shellcode. No  
> hacker
> ever truly gets away from that. Even here in Aotearoa there's an  
> int $13
> waiting...
>
> - -dave
>
> P.S. Congrats to NFR :>

[snip]

Jon

Obvia conspicimus, nubem pellente Mathesi.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFFjC7QZpJsLIS+QSIRAo4cAJ9OWSwExWSsZZoQSu/9Du9ylEuZBwCfbTDS
lPOWj/3zxuetRm8AAbNX5eo=
=OiTY
-----END PGP SIGNATURE-----

From liquidfish at gmail.com  Fri Dec 22 21:04:42 2006
From: liquidfish at gmail.com (liquidfish)
Date: Fri, 22 Dec 2006 18:04:42 -0800
Subject: [Dailydave] From int $13 to distributed object clouds
In-Reply-To: <100A25A5-3A8C-4AC4-9D12-6ACB48B4C51A@hursk.com>
References: <42B56C6A683EBA4581C01CB49A914CA70A24476E@MAILFAXSRV.gfimalta.com>
	<100A25A5-3A8C-4AC4-9D12-6ACB48B4C51A@hursk.com>
Message-ID: <d0c1e6850612221804q2605754fid1be4c891d6e9401@mail.gmail.com>

>
> What's the point of messing with 1.1 if you already have it under the
> identity of 2.1?  If the goal is to perform as little action as
> possible (e.g. to be covert, to quickly gather data, and/or to reduce
> data analysis and post-grouping), then this is a wasted action.


The results may differ for various reasons. Perhaps the routes go through
different firewalls with different ACL's, so you might be able to access the
HTTP server on the 1.1 interface and not the 2.1 interface. You want the
full picture of what is available on what interfaces and from what sources.
Scanning a single interface does not always give you the full picture for a
host, so intentionally neglecting to scan additional intrfaces, once you
have learned they belong to an already scanned asset would be a mistake.
Additionally, many network daemons may be configured to only listen on a
particular interface. Perhaps the SSH and HTTPS daemons are only accessible
on a management interface. Assets should be identified, list the interfaces
they have, list what is accessible from all interfaces, and then list
anything else that is only accessible from specific interfaces.


-p
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20061222/86053f2e/attachment.htm 

From dave at immunityinc.com  Fri Dec 22 20:49:25 2006
From: dave at immunityinc.com (Dave Aitel)
Date: Fri, 22 Dec 2006 20:49:25 -0500
Subject: [Dailydave] Subtle
Message-ID: <458C8B25.9080301@immunityinc.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I dunno if this is hacking, but it's funny. Which reminds me, did
anyone ever find out how UCLA got owned? They called it "subtle" in
the news articles, which probably means unpatched IIS .printer exploit? :>

http://www.attrition.org/postal/z/033/0871.html

Here in NZ, there's this bird called a "Pukeko" which torments the
little ducklings in the pond until they die. A couple days ago there
were 4, and now there are 2. Kinda reminds me of Jericho and this poor
congresscritter.

- -dave
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFjIsktehAhL0gheoRArpNAJ4yxTbbgNJFTdYvCIF76CInf7bKWACfRYXp
fnKy+3LxBFC7Lk5aMgEWCt8=
=vNMG
-----END PGP SIGNATURE-----


From dailydave at bobcats.info  Sat Dec 23 03:22:51 2006
From: dailydave at bobcats.info (BobCat)
Date: Sat, 23 Dec 2006 03:22:51 -0500
Subject: [Dailydave] Subtle
In-Reply-To: <458C8B25.9080301@immunityinc.com>
References: <458C8B25.9080301@immunityinc.com>
Message-ID: <22e7ce6d0612230022m53d14ac0j9e9874667b7d6530@mail.gmail.com>

On 12/22/06, Dave Aitel <dave at immunityinc.com> wrote:

> http://www.attrition.org/postal/z/033/0871.html

I didn't mean to get the guy fired when I posted that on reddit a few
days ago, but I don't feel too bad about it. I looked him up a few
hours later and only then realized who he was. I was very surprised no
one else had previously put it on any social networking site or blog.
Consider it accidental revenge: If I had a dollar for every time some
fool asked if I could hack grades/girlfriend's email/satellites I
could buy a clue adjusting tool.

Jericho and Lyger did very nice work, as usual. I bet there are
reporters combing 'Going Postal' and Googling furiously at this very
moment. (I should have warned attrition they'd be getting the extra
traffic, but I figured they could handle it :)

-- 
Mandelbrot Set you're a Rorschach Test on fire
You're a day-glo pterodactyl
You're a heart-shaped box of springs and wire
You're one badass fucking fractal

From brian at gfi.com  Thu Dec 28 11:13:02 2006
From: brian at gfi.com (Brian Azzopardi)
Date: Thu, 28 Dec 2006 17:13:02 +0100
Subject: [Dailydave] From int $13 to distributed object clouds
Message-ID: <42B56C6A683EBA4581C01CB49A914CA70A2A28CA@MAILFAXSRV.gfimalta.com>


If you are starting with zero knowledge and doing the grouping as more
data is becomes known is problematic:
- communicating the result of the tests. If the scanning software is
client-server (a peer network would be more complex to sync) then all
the agents need to send the data back to the server after each test
which does the grouping. Maybe not a big problem, but you need to sync
with the clients, slowing you down.
- you still have to do the all tests anyway. Sure, it might allow you to
early-out the rest of the tests, but you can only do this if you accept
only one group. Once you want to do regrouping later on as more data
comes in you need to do all the tests for all the ips.

You could first do a parallelized scanning run to get only the data
which you need for grouping, do the grouping on the master, and then
farm out the groups for parallel vuln checking.

As another poster mentioned, the interfaces a machine may be exposing
could make a difference. IMO, its better to just scan the IP range and
then do clustering as a post-process. The data that comes back might
hint at groupings you did not foresee. Post-processing is usually
cheaper/faster then the scanning itself - which is why Dave wanted to do
the scanning in parallel in the first place.

Considered the case where a machine might belong to multiple groups?

Languages with inbuilt parallelization (Occam, Erlang, etc) usually have
a steeper learning curve then Python/C with their easily understood
(hacked-on) threading models. Implicit parallelization is cool - but
doing it in practice for general-purpose tasks is nigh on impossible.


Brian


-----Original Message-----
From: Jon Passki [mailto:jon.passki at hursk.com] 
Sent: Friday, December 22, 2006 8:15 PM
To: Brian Azzopardi
Cc: Dave Aitel; dailydave at lists.immunitysec.com
Subject: Re: [Dailydave] From int $13 to distributed object clouds

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Dec 22, 2006, at 03:06 , Brian Azzopardi wrote:

>
>> They need to be grouped intelligently
>
> Can't you group IPs intelligently and then farm out the groups to be 
> handled in parallel?
>

If I'm not hitting on the hookah too hard and understand what Dave's
talking about , partitioning the universe of our hosts will occur more
than once.  This is different than parallelism with one-time
partitioning, ran until completion on a host.  The parallelism,
methinks, would have to be dynamic and flexible (perhaps intelligent
:-).  For example, assuming a zero-knowledge beginning, there's no way
to start grouping IP's/targets/assets until something is learned,
besides the asset identifier.  If you group as soon as something is
known, such as subnet location of externally-facing IP addresses, and
then want to regroup later on, such as subnet location of
internally-facing IP addresses, all the hosts performing the parallelism
potentially need to reshuffle their groups.


>
>> Some IP addresses are the same machine, and we need to know that
> 10.0.1.1 and 10.0.2.1 are the same machine
>
> You can do that as a post-process (assuming you don't do the 
> intelligent grouping first).

What's the point of messing with 1.1 if you already have it under the
identity of 2.1?  If the goal is to perform as little action as possible
(e.g. to be covert, to quickly gather data, and/or to reduce data
analysis and post-grouping), then this is a wasted action. It just
becomes a balance between the cost of reaching this goal and the cost of
violating this goal.  Going w/ the concept above of regrouping and
reshuffling the parallelism, one would want to perform the least amount
of overlapping tests across all assets or groups of assets.  Since, if
you reshuffle later, it would be ideal to combine disjointed sets versus
identical sets.  Again, there's a cost in doing this...

>
>
>>  intelligent parallelism handled by a language
>
> What do you understand by intelligent parallelism? Is Occam 
> intelligent enough? Do you prefer implicit parallelism?
>
> Just for the record, I am working (slowly) on an new language that has

> parallelism as fundamental part of the language, rather than tacked on

> to it via threads like Python/C++/etc.
>
>
> Brian
>
>
>
> -----Original Message-----
> From: dailydave-bounces at lists.immunitysec.com
> [mailto:dailydave-bounces at lists.immunitysec.com] On Behalf Of Dave 
> Aitel
> Sent: Friday, December 22, 2006 4:43 AM
> To: dailydave at lists.immunitysec.com
> Subject: [Dailydave] From int $13 to distributed object clouds
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> The question you have to ask yourself when dealing with, as Sinan 
> would call it, "NP Complete Stuff" (aka, anything academic and wanky) 
> is "How is this going to help me hack something". Lately I've been, in

> the back of my head, obsessed with distributed object languages. But 
> how can I explain that having your language abstract not just memory 
> management, but also parallelism, is going to help you break into more

> computers faster and better?
>
> The problem set is easy to understand: scanning a range of IP 
> addresses for exploitable vulnerabilities and then exploiting them.
> People look at that and say "Easy to parallelize. Just split it up 
> based on IP range.". They'd be wrong - IP addresses are connected to 
> each other in many ways. They need to be grouped intelligently, and 
> deep down, we're breaking into machines, not IP addresses. Some IP 
> addresses are the same machine, and we need to know that 10.0.1.1 and
> 10.0.2.1 are the same machine even if they've been split up across 
> scanning processes which reside on different computing clouds. We also

> need to use information gained from hacking 10.0.1.1 against 10.0.2.1.
>
> Something in my right brain is telling me parallelism is the next big 
> step for something like CANVAS. Not simple "split it up into bite size

> pieces", but intelligent parallelism handled by a language that is as 
> much like Python as possible, but time abstract. Possibly the easier 
> next step is built-in data-mining and CRM. When we do open source data

> collection on a target, I need somewhere to enter that in that can 
> reuse that information automatically. And when I own 10,000 machines, 
> I need to be able to mine that cloud for the information I'm 
> interested in, covertly.
>
> Of course, in the meantime it's shellcode shellcode shellcode. No 
> hacker ever truly gets away from that. Even here in Aotearoa there's 
> an int $13 waiting...
>
> - -dave
>
> P.S. Congrats to NFR :>

[snip]

Jon

Obvia conspicimus, nubem pellente Mathesi.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFFjC7QZpJsLIS+QSIRAo4cAJ9OWSwExWSsZZoQSu/9Du9ylEuZBwCfbTDS
lPOWj/3zxuetRm8AAbNX5eo=
=OiTY
-----END PGP SIGNATURE-----

DISCLAIMER
The information contained in this electronic mail may be confidential or
legally privileged. It is for the intended recipient(s) only. Should you
receive this message in error, please notify the sender by replying to
this mail. Unless expressly stated, opinions in this message are those
of the individual sender and not of GFI. Unauthorized use of the
contents is strictly prohibited. While all care has been taken, GFI is
not responsible for the integrity of the contents of this electronic
mail and any attachments included within.  

This mail was checked for viruses by GFI MailSecurity. 
GFI also develops anti-spam software (GFI MailEssentials), a fax server (GFI FAXmaker), and network security and management software (GFI LANguard) - www.gfi.com 



From liquidfish at gmail.com  Thu Dec 28 17:54:35 2006
From: liquidfish at gmail.com (liquidfish)
Date: Thu, 28 Dec 2006 14:54:35 -0800
Subject: [Dailydave] From int $13 to distributed object clouds
In-Reply-To: <42B56C6A683EBA4581C01CB49A914CA70A2A28CA@MAILFAXSRV.gfimalta.com>
References: <42B56C6A683EBA4581C01CB49A914CA70A2A28CA@MAILFAXSRV.gfimalta.com>
Message-ID: <d0c1e6850612281454r79957f33qdb90e739e9f3f423@mail.gmail.com>

You would also want to accomodate for the occurence of VIPs (which are by no
means rare) when grouping. Such as when a load balancer forwards port 21 to
HostA, port 22 to HostB, port 80 to HostC, etc. You want to map these VIPs
and understand that results for scanning a VIP may differ from scanning the
real IP of a server (if you can get to the real IP as well) due to any
filtering or other manipulative processes that may occur on the device
performing the NAT/PAT operation. A single IP may have unique ports
belonging to different assets when grouping
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20061228/c6c4c4ee/attachment.htm 

From dave at immunityinc.com  Sat Dec 30 13:57:29 2006
From: dave at immunityinc.com (Dave Aitel)
Date: Sat, 30 Dec 2006 13:57:29 -0500
Subject: [Dailydave] Just a few new years day thoughts.
Message-ID: <4596B699.7080605@immunityinc.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

CANVAS release day is coming up, and as I often do, I checked out the
published reports of IDS coverage for the various vulnerabilities
we're releasing to see what's up. Some companies have really good
internal research teams, and some companies have good relationships
with other vendors and get the information straight from them. But the
companies that don't have either of those have to wait until someone
publishes a proof of concept to write their signatures.

Kostya did a bang up job on the HEROES exploit and now it's
cross-service pack and cross-language. The funny thing with HEROES is
that it's extremely difficult to reverse engineer back from the patch.
There's not, to my knowledge, a good source of information about
HEROES in the outside world (other than Immunity Partners). So it's a
good way to tell who's doing their research (or getting info from MS)
and who's writing sigs from CANVAS exploits.


http://www.snort.org/vrt/advisories/vrt-rules-2006-12-12.html

"""
*Microsoft Security Bulletin MS06-074:*
A vulnerability in the Microsoft SNMP service may allow a remote
attacker to execute code of their choosing on a vulnerable system by
supplying a malformed SNMP request to the service.

Rules to detect attacks targeting this vulnerable service were
previously released and are identified as SIDs 1411 through 1414.

"""

That's misleading since there are lots of rules that say "SNMP traffic
detected" which is something highly different from MS06-074. Perhaps
I'm not up to date on my Snort. I'm sure someone will correct me.
Unless I'm wrong, Snort doesn't protect you from this attack at all.
It just alerts to random SNMP traffic?

NAI says this http://vil.nai.com/vil/Content/v_vul27222.htm :
"""
McAfee Intrushield

This signature provides coverage for this vulnerability. McAfee Avert
Labs will continue to update our coverage, as needed, as new exploit
vectors are discovered and as new threats emerge.

Signature:
    SNMPV2: MicrosoftV2Bulk ValuePair
Signature identifier:
    0x40A03800
Release date:
    12/12/2006

"""

Sounds like it might work. For an IPS to find HEROES in the wild, I'd
expect it to store state. It's a tough bug to find just by looking at
bytes. You can write a signature on our particular exploit, but that's
going to be a losing battle in the medium and long terms. Like all
signature detection, I guess.

I don't see anything here from NFR. Maybe they're busy being bought.
http://nfr.com/solutions/signatures.php

ISS says (http://xforce.iss.net/xforce/bulletins/microsoft/MS06-074):
This bulletin covers an integer underflow vulnerability in Windows SNMP.
They say they released a sig on Dec 13th.

Another thing that popped into my head is that 2006 is closing without
any public remote anonymous exploits against Windows XP SP2. If
Microsoft had decided to separate client-side and true remotes in
their naming system, they'd be able to use that in their advertising!

People get very interested in naming each and every vulnerability, but
exploits are just as interesting. You can name and classify exploits
by which vulnerabilities they use, and by which program features and
protocols they use or abuse. If you want a real picture of your risk,
you need to know the real capabilities of your tools. CVE number is
really just one tiny part of that.

- -dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFlraWtehAhL0gheoRAh8UAJ0Zuej5ZDp/ybDwVnywX/y6xTVrXQCdHZlV
5VNE3JlnhRHvSTLlUMhECgY=
=5CCI
-----END PGP SIGNATURE-----


From docbook.xml at gmail.com  Sat Dec 30 22:09:24 2006
From: docbook.xml at gmail.com (Saqib Ali)
Date: Sat, 30 Dec 2006 22:09:24 -0500
Subject: [Dailydave] U.S. Gov't to use Full Disk Encryption on All Computers
Message-ID: <addede3b0612301909j64f74d09j9d32dfd590db848c@mail.gmail.com>

To address the issue of data leaks from stolen or missing laptops, US
Government is planning to use Full Disk Encryption (FDE) on all of the
Government owned computers. On June 23, 2006 a Presidential Mandate
was put in place requiring all agency laptops to fully encrypt data on
the HDD. The US Government is currently conducting the largest single
side-by-side comparison and competition for the selection of a Full
Disk Encryption product. The evaluation will come to a end in 90 days.
The selected product will be deployed on Millions of computers in the
US federal government space.  This implementation will end up being
the largest single implementation ever, and all of the information
regarding the competition is in the public domain.

...... Read complete text at:
http://www.full-disk-encryption.net/fde_govt.html