Send Dailydave mailing list submissions to
dailydave@lists.immunitysec.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.immunitysec.com/mailman/listinfo/dailydave
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Dailydave digest..."
Today's Topics:
1. Re: DNS Speculation ([EMAIL PROTECTED])
2. Re: Blog spam, obfuscated javascript and more! (val smith)
3. Re: Tool release: [evilgrade] - A question about Mac Updates
(Francisco Amato)
4. SecTor 2008 Call for Speakers - Second Round (Brian Bourne)
5. DNS and other fun. (Dave Aitel)
6. Re: DNS and other fun. (H D Moore)
----------------------------------------------------------------------
Message: 1
Date: Mon, 28 Jul 2008 09:45:33 -0700
From: [EMAIL PROTECTED]
Subject: Re: [Dailydave] DNS Speculation
To: Philippe Biondi <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="US-ASCII"
Philippe Biondi <[EMAIL PROTECTED]> wrote on 07/26/2008 01:00:57 PM:
>
> Did you do something like:
>
> for i in range(500):
> send(pkt)
> or
> while True:
> send(pkt)
>
> In this case the "optimised" way to do it would be (resp.) :
>
> send(pkt*500)
Passing a list of packets to send() was the first optimization I tried.
But it was still too slow.
> At last resort, you have the sendpfast() function which Bryan
> spoke about.
I didn't try sendpfast(), but, yes, according to Bryan this seems to
be the solution.
> Or did the problem was that the time between creating the packet and
> having it hit the wire is too big because most of the initialisation
> done by send() could have been done before ?
>
> In this case, the way to do it would be to avoid send()'
> high-levelness and directly use scapy layer 3 socket:
>
> s = conf.L3socket()
> while True:
> ** do stuff, create pkt **
> s.send(pkt)
This is the 2nd optimization I tried, and the fastest scapy exploit I
could come up with. But even when stracing it, I could see extra system
calls being called between the sendto(). IIRC this 2nd optimization
allowed me to send packets at a rate about 2 or 3 times faster than my
first Python version, but it was still about twice as slow as my C
implementation.
> In any cases, I'm interested by feedback on improvements this could
> provide.
I think sendpfast() is a good solution for this case.
-marc
------------------------------
Message: 2
Date: Mon, 28 Jul 2008 11:44:37 -0600
From: "val smith" <[EMAIL PROTECTED]>
Subject: Re: [Dailydave] Blog spam, obfuscated javascript and more!
To: dailydave <dailydave@lists.immunitysec.com>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1
The thing that I would say is that everyone should know when you go to
my site you will be encountering live malware. I'm sort of a "full
disclosure for malware" type of person. I don't censor anything,
unlike many other analysis organizations. I respect their position on
censoring things like links, etc. but I believe in a different way.
I have a big warning on my site, but just to re-iterate: Offensive
Computing has live, malicious samples of evil software. We will also
post direct links to bad guys and sites hosting malware. This is so
competent analysts can find the samples, know what they are dealing
with and so we are all on equal footing. I don't want to be the only
one holding the information and everyone else has to guess about it.
The malware disclosure debate is decades old and won't ever be
resolved, (definitely not by me) but I will keep on doing what I
think is right.
Therefore you should always use best safety practices at all times,
such as sandboxes, virtual machines, safe browsers, safe document
viewers, etc. I don't even surf the web from a non-virtualized host
anymore.
V.
On Mon, Jul 28, 2008 at 9:22 AM, Petja van der Lek <[EMAIL PROTECTED]> wrote:
> A word of warning might be in order: the PDF is filled with hyperlinks to
> (presumably) live malware sites. Navigating the document is therefore not
> unlike playing Minesweeper. Red flags are not powerups but mean "danger".
> Mis-click to get pwned. Stuff like that. You might want to use a reader that
> at least asks for confirmation before it serves up the site in your browser
> (a quick test shows that Adobe Reader 7 as a Firefox plugin happily opens a
> link without asking anything, for instance).
>
> That said, it's an excellent read!
>
> Cheers,
> Lek.
>
> val smith wrote:
>>
>> Don't know how many of you care about malware stuff but just in case,
>> we released a paper on OC:
>>
>> http://www.offensivecomputing.net/papers/valsmith_colin_blog_spam.pdf
>>
>> Its pretty rough and disorganized but covers some reversing, analyzing
>> obfuscated javascript, and the potential home IP of one of the
>> "attackers".
>>
>> V.
>>
>>
>
--
******************************************
* Val Smith
* CTO Offensive Computing, LLC
* http://www.offensivecomputing.net
*******************************************
------------------------------
Message: 3
Date: Tue, 29 Jul 2008 10:31:22 -0300
From: "Francisco Amato" <[EMAIL PROTECTED]>
Subject: Re: [Dailydave] Tool release: [evilgrade] - A question about
Mac Updates
To: "Joanna Rutkowska" <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1
Hello Joanna,
The module osx.pm exploit the vulnerability CVE 2007-5863, discoverer
by Moritz Jodeit.
This module allows for arbitrary command execution through "cmd" variable.
Regards,
--
Francisco Amato
[ISR] - Infobyte Security Research
Chile 1441 - Segundo Cuerpo - Primer Piso
[C1098ABC] Buenos Aires - Argentina
Tel: 43837000
http://www.infobyte.com.ar
On Tue, Jul 29, 2008 at 5:05 AM, Joanna Rutkowska
<[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> [ISR] - Infobyte Security Research wrote:
> |
> | Implemented modules:
> | ---------------------------------
> | - Java plugin
> | - Winzip
> | - Winamp
> | - MacOS
> | - OpenOffices
> | - iTunes
> | - Linkedin Toolbar
> | - DAP [Download Accelerator]
> | - notepad++
> | - speedbit
> |
>
> So, Mac OSX's Software Update doesn't verify signatures of the update
> packages it downloads? Given then Leopard's so much advertised code
> signing feature, I would expect that all the updates are signed. Can you
> please comment on this?
>
> For example most of the Apple-provided App packages are indeed signed --
> you can verify this using e.g. this command:
>
> find /Applications -name "*.app" -exec codesign -v {} \;
>
> Some interesting exceptions though:
>
> /Applications/iWork '08/Keynote.app: code object is not signed
> /Applications/iWork '08/Numbers.app: code object is not signed
> /Applications/iWork '08/Pages.app: code object is not signed
>
> :)
>
> Unfortunately verifying e.g. /System/Library/Extensions is even worse,
> i.e. even more unsigned packages.
>
> But still, I would expect that maybe Apple doesn't sign every single
> executable (BTW, MS is doing that since Windows 2000), but at least signs
> the update packages? No?!
>
> Thanks,
> joanna.
>
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkiOzz4ACgkQORdkotfEW87J8wCeK5GUh5OlsWdoDEGPRaAOHt27
> joEAoL+XFo1xCBCkSaUmPVinKLNwO++P
> =ZShx
> -----END PGP SIGNATURE-----
>
------------------------------
Message: 4
Date: Tue, 29 Jul 2008 10:49:45 -0400
From: Brian Bourne <[EMAIL PROTECTED]>
Subject: [Dailydave] SecTor 2008 Call for Speakers - Second Round
To: "dailydave@lists.immunitysec.com"
<dailydave@lists.immunitysec.com>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
SecTor 2008 is currently open to speaking proposals. Visit
http://www.sector.ca/ to learn more about the event.
SecTor is all about the meat -- The content that matters to Canadian IT
Security Professionals today. Of course we'll have fun and celebrate having
the world's best in Toronto, but the key to SecTor's success, and thus the
primary objective of the Management Committee and Advisory Committee, is
quality content and presentation for attendees.
This is a call for speakers/papers. If we haven't approached you, but you
believe you have a significant discovery or new research that the security
community would value, or enjoy hearing about, we invite you to submit your
presentation topic for serious consideration. Selected speakers will have
travel costs covered.
This is now the second and final round of speaker selection, please make your
proposal submissions before August 31st, 2008. Selections will be announced
early in September. You will not be contacted until that time. To allow for
late breaking research to be presented, submissions after the deadline will be
accepted on an exception basis only.
SecTor attendees are a mix of security professionals and vendors, programmers,
students, network administrators and IT executives. Preference will be given to
speakers who can present new and innovative technical content to a broad
audience. Of course, all presentations are expected to challenge the brightest
and quickest of attendees - we wouldn't have it any other way.
SecTor is not a vendor fair. Consequently, there will be very little tolerance
for commercial content within presentations. Attendees will be encouraged to
quell any shameless marketing that is not immediately backed up with rationale
for its inclusion.
Proposals should consist of the following information:
1. Presenter and contact info (country of origin and residence-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.
Please forward the above information to [EMAIL PROTECTED]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.immunitysec.com/pipermail/dailydave/attachments/20080729/5159b6fd/attachment-0001.htm
------------------------------
Message: 5
Date: Tue, 29 Jul 2008 16:59:51 -0400
From: Dave Aitel <[EMAIL PROTECTED]>
Subject: [Dailydave] DNS and other fun.
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
If you're mucking with Marc Bevand's exploit in order to do some speed
comparisons you may want to fix this line:
(sizeof(buf) is 4 since buf is a pointer, of course).
~ dns_response(buf + IP_HDR_LEN + UDP_HDR_LEN,
~ (unsigned)(IP_LEN_MAX - (IP_HDR_LEN + UDP_HDR_LEN)), <--fixed.
We're not using Scapy here, but in Python (and Ruby, I assume?) you
don't want to do your creation of packets along-side your sending of
packets. You probably want to do something like this:
buffers=create_all_data_buffers()
for buffer in buffers:
~ raw_sock_send(buffer)
I'm not sure how having tcpreplay helps since all your packets are
different (via TXID incrementing, which of course means you have to do
your UDP checksum over). Is packet-loss the big problem you're seeing?
Importing psyco should make your Python code faster as well, although
still REALLY slow compared to C (so far in my testing). People say that
the public exploits don't work with Bind9 (even unpatched). Go Vixie and
Co! :>
And in Vegas news:
It is true, hackers do get the girls. Just like in the movies. Even more
so really, now that the economy is crappier so being able to afford your
house payment is uber-sexy...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Immunity is bringing the test, Edgeos <http://www.edgeos.com/> is
bringing the Sexy Hacking girls <http://sexyhacking.com>. Rumor has it
that certified NOP's might receive invitations to the exclusive and
still-secret Sexy Hacking party at Defcon. More details soon!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
- -dave
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIj4TFtehAhL0gheoRAoi/AJ42lTry1I1XVmnVp29EQkPf7mHtTwCffOrE
Azq4oLsFxjRMJjJqV7kGgXM=
=D6uJ
-----END PGP SIGNATURE-----
------------------------------
Message: 6
Date: Tue, 29 Jul 2008 16:58:39 -0500
From: H D Moore <[EMAIL PROTECTED]>
Subject: Re: [Dailydave] DNS and other fun.
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="utf-8"
I still don't understand why speed *matters* -- the existing metasploit
modules nail every BIND 9 server I have tested within a minute or two (as
long as they have a static source port). I imagine speed would be more of
a concern for more-random source ports, but this craze over 10 seconds vs
two minutes seems ridiculous. I don't mind waiting a couple minutes to
poison an entire TLD.
The one major optimization we added to the metasploit modules was the
ability to determine the race window for a particular cache server and
target domain. This prevents us from sending packets after the real one
has already arrived and resulted in a 3-4 x speedup. Even still,
poisoning a TLD with 13 nameservers just isn't that long of a wait.
My 0.02,
-HD
On Tuesday 29 July 2008, Dave Aitel wrote:
> We're not using Scapy here, but in Python (and Ruby, I assume?) you
> don't want to do your creation of packets along-side your sending of
> packets. You probably want to do something like this:
------------------------------
_______________________________________________
Dailydave mailing list
Dailydave@lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave
End of Dailydave Digest, Vol 36, Issue 19
*****************************************
