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. Django Google App Engine job (Dave Aitel)
   2. Re: Two thoughts for the day: (Dave Aitel)
   3. Anonymized email re: sigs (Dave Aitel)
   4. Client Side Exploitation Automation (DSquare Security)
   5. German/Afghanistan Trojan Horse Affair (Halvar Flake)
   6. Re: German/Afghanistan Trojan Horse Affair (wishi)
   7. Re: German/Afghanistan Trojan Horse Affair (Sebastian Krahmer)
   8. ShakaCon 2008 Update (Anthony Giandomenico)


----------------------------------------------------------------------

Message: 1
Date: Mon, 28 Apr 2008 11:26:00 -0400
From: Dave Aitel <[EMAIL PROTECTED]>
Subject: [Dailydave] Django Google App Engine job
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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

Immunity is looking for a Google App Engine: Django contract programmer. 
If you know one, let me know.

Description:

This project allows people suffering from food allergies to enter in 
their daily food intake (what I ate and when) and allergic reactions 
(reaction intensity and symptom) and then makes an informed guess at 
what is causing the reactions (which may be delayed by X hours, last for 
X hours, have some noise in the signal, etc).

Often foods packaging does not list all the ingredients (aka, "colorings 
and flavorings"), so this will also be useful to data-mine for brands 
that include allergens that are not specified.

Likewise, entering food ingredients is unfun and only one user should 
have to ever do this per food/brand. This is where Ajax comes into play, 
as you want to make it as easy as possibly to type in the long chemical 
names of things.

The goal is to start at "Simple and Useful" and scale from there. Anyone 
with a child with a food allergy could use this service from launch-day 
and get lots of value. It may turn out, in fact, that "Milk is not good 
food".

Doctor's give you food diaries to fill out - but these don't really work 
as anyone who's tried to use them can point out. Processed foods defeat 
simplistic methods of analysis as the ingredient list is too complex for 
people to correlate.  This project solves that problem.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIFeyItehAhL0gheoRAszXAJ9b5AlxJPJSnphOWrxxAE8rP22OlQCeMf4R
2q+/ZACUZbI/l0ybnCHh7TU=
=imaQ
-----END PGP SIGNATURE-----



------------------------------

Message: 2
Date: Mon, 28 Apr 2008 11:38:16 -0400
From: Dave Aitel <[EMAIL PROTECTED]>
Subject: Re: [Dailydave] Two thoughts for the day:
To: Joanna Rutkowska <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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

There's no paper out right now, although I am writing a generalized 
overview to all the trojans in CANVAS today. Essentially the kernel 
rootkit is very simple - it sits underneath the network layer polling 
for trigger packets (UDP) which then can contain a command to tell it to 
send a MOSDEF connection to a listening post. Also it can hide network 
connections (ioctl-based command-set).

There's a lot more to do, of course, but the innovation in the CANVAS 
trojan set is not in specialized hooking techniques or new feature sets, 
but more in how the whole package integrates. You'll want to be able to 
send messages over your internal RootkitBus via your HTTP-MOSDEF 
callback, etc. As we integrate Immunity Debugger into CANVAS you'll see 
lots of "specialized hook for X app" stuff come through. Trojans are 
important and I've always felt that penetration testing kits leave them 
a bit behind. We'll fix that. :>

You can always buy CANVAS Early Updates and test it for yourself. :>

Of course, it breaks the CANVAS license for AV vendors to write 
signatures for CANVAS, so there won't be any "CANVAS Rootkit" 
signatures, although we do get picked up by generic signatures for 
things sometimes.

- -dave



|
| Is there a technical paper about your Kernel Rootkit available somewhere?
|
| joanna.
_______________________________________________
Dailydave mailing list
Dailydave@lists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIFe9otehAhL0gheoRArJqAJ0Rmpg83GFNYhxrGPGVabR3b4M8wQCfTP4q
5NfeNg69CFxJJeP0O4/NI0g=
=lvSZ
-----END PGP SIGNATURE-----



------------------------------

Message: 3
Date: Mon, 28 Apr 2008 13:58:43 -0400
From: Dave Aitel <[EMAIL PROTECTED]>
Subject: [Dailydave] Anonymized email re: sigs
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

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

An anonymized message follows with my comments in []'s
- -dave
______________________________________________________________________

Anonymize this if you want to repost - some IPS/IDS canvas sigs:

On Monday 28 April 2008, Dave Aitel wrote:
| > Of course, it breaks the CANVAS license for AV vendors to write
| > signatures for CANVAS, so there won't be any "CANVAS Rootkit"
| > signatures, although we do get picked up by generic signatures for
| > things sometimes.
[editor comment (dave): hmmm]
TippingPoint:
    4933: Canvas: Canvas Shellcode
    5171: Canvas: Canvas Shellcode
    5172: Canvas: Canvas Shellcode

[editor comment: Some of these don't make any sense? Should BABYBOTTLE 
add rand(5) spaces to the front to avoid simple gzip sigs?]
Juniper:
    CANVAS-BABYBOTTLE
    CANVAS-BABYBOTTLE-GZIP
    CANVAS:AVGTCPSRV
    CANVAS:CANVAS-HELIUM
    CANVAS:ESERV
    CANVAS:FEDORA4
    CANVAS:INGRESS
    CANVAS:LINUXSNMP
    CANVAS:MAILENABLE
    CANVAS:NETWORKER-3
    CANVAS:NOVELL2
    CANVAS:TIVOLI3
    CANVAS:WORDMAIL3

[editor comment - these are now removed from VRT]
Snort:
    ./sid-msg.map:10506 || SHELLCODE Canvas shellcode basic encoder
    ./sid-msg.map:10507 || SHELLCODE Canvas shellcode basic encoder
    ./sid-msg.map:10508 || SHELLCODE Canvas shellcode basic encoder
    ./sid-msg.map:10509 || SHELLCODE Canvas shellcode basic encoder
    ./sid-msg.map:10510 || SHELLCODE Canvas shellcode basic encoder
    ./sid-msg.map:10511 || SHELLCODE Canvas shellcode basic encoder
    ./sid-msg.map:10512 || SHELLCODE Canvas shellcode basic encoder
    ./sid-msg.map:10513 || SHELLCODE Canvas shellcode basic encoder




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIFhBTtehAhL0gheoRAkxvAJ9+plM06s5O/l4M7v1L1dhNFQDB6QCePN2n
b8eyXFEF1qRYaJ1QCBGG1TE=
=ivQa
-----END PGP SIGNATURE-----



------------------------------

Message: 4
Date: Mon, 28 Apr 2008 13:59:19 -0500
From: DSquare Security <[EMAIL PROTECTED]>
Subject: [Dailydave] Client Side Exploitation Automation
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii

Everyone knows that client side attack is often the more efficient way
to compromise a network. D2 Client Insider was designed especially for
testing security by modeling this kind of attack.

D2 Client Insider provides about 30 client side exploits from DSquare 
Security and Immunity Inc. converted to be reliable and fully compatible 
with HTTP MOSDEF. Hackers use client-side exploit packs - MPack, IcePack, 
Neosploit and others have made the rounds. Now your penetration testing 
team can take this to the next generation with automated JavaScript 
obfuscation and HTTPS support.

Here is a demonstration of D2 Client Insider:
http://www.d2sec.com/d2clientinsider.htm

D2 Client Insider will be available in the May 2008 update of the 
D2 Exploitation Pack.

-- 
DSquare Security, LLC
http://www.d2sec.com



------------------------------

Message: 5
Date: Tue, 29 Apr 2008 16:19:18 +0200
From: Halvar Flake <[EMAIL PROTECTED]>
Subject: [Dailydave] German/Afghanistan Trojan Horse Affair
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1

There's a lot of hoopla in German media about the german SIGINT folks
having to admit that they trojanized Afghanistan's Ministry of Commerce
and Industry.
(http://www.spiegel.de/international/germany/0,1518,550212,00.html)

The entire situation is hilarious, as Mrs. Merkel criticized the chinese
for having sponsored hacking sprees into German government institutions
last year - I guess she is not overly happy about all this stuff hitting
the press now.
(http://www.timesonline.co.uk/tol/news/world/europe/article2332130.ece)

The first article is actually quite interesting. It is terribly hard to
get any information about InfoSec stuff in Europe (we'd need a Mr.
Bamford around here I fear), so the article is really amongst the only
data points to be found.

"    In 2006, Division 2 consisted of 13 specialist departments and a
management team (Department 20A), employing about 1,000 people. The
departments are known by their German acronyms, like MOFA (mobile and
operational telecommunications intelligence gathering), FAKT (cable
telecommunications intelligence gathering) and OPUS (operational support
and wiretapping technology)."

So there are people working on this sort of stuff in Germany after all.
I wonder why one never meets any at any security conferences - they
either have excellent covers or no budget to travel to any conferences.

Another amusing tidbit:

"    Perhaps it will never be fully clear why the BND chose this
particular ministry and whether other government agencies in Kabul were
also affected -- most of the files relating to the case have apparently
been destroyed."

I find the regularity with which important files regarding espionage or
KSK misbehavior are destroyed or lost a little bit ... peculiar.
(http://images.zeit.de/text/online/2007/27/Bundeswehr-Loeschaffaere)

There's a bit in the article about emails that have a .de domain ending
being automatically discarded by their surveillance tools. Hilarious.

The issue came to light because during the surveillance a German
reporter had her email read, too (she was communicating with an Afghan
official whose emails were being read). This is a violation of the
freedom of the press here in Germany, and normally, the BND should've
dealt with this by reporting their breach to the parliamentary
subcommittee for intelligence oversight, which they somehow didn't. A
whistleblower inside the BND then sent a letter to a bunch of
politicians, making the situation public.

It's always hard to make any judgements in cases as these, as the public
information is prone to being unreliable, but it is encouraging that a
whistleblower had the guts to send a letter out. I am a big fan of the
notion that everyone is personally responsible for his democracy.

The topic of intelligence and democracies is always difficult: If one
accepts the necessity of intelligence services (which, by their nature,
operate in dodgy terrain, and which, due to their requirements for
secrecy, are difficult to control democratically), then one has to make
sure that parliamentary oversight works well. This implies that the
intelligence agencies properly inform the parliamentary committee, and
it also implies that the parliamentary committee keeps the information
provided confidential.

There seem to be only two ways to construct parliamentary oversight in a
democracy: Pre-operation or post-operation. Pre-operation would have the
committee approve of any potentially problematic operation ahead of it
being performed. If things go spectacularly wrong, the fault is to be
blamed on the committee. The problem with this is secrecy: Such a
committee is big, and for operational security it seems dangerous to
disseminate any information this widely.

This appears to be the reason why most democracies seem to opt for a
"post-operation" model: The services have in-house legal experts, and
these legal experts judge on the 'legality' of a certain operation. The
the operation takes place, and the committee is notified after the fact
if something goes spectacularly wrong.

The trouble with this model appears to be that the intelligence service
doesn't have much incentive to report any problems: They can always hope
the problem goes away by itself. It is the higher-ups in the hierarchy
that have to report to the committee, and they are the ones whose heads
will roll if things go wrong.

It appears to be an organisational problem: Information is supposed to
flow upwards in the organisational hierarchy, but at the same time, the
messenger might be shot. This is almost certain to lead to a situation
where important information is withheld.

I guess it's any managers nightmare that his "subordinates" (horrible
word -- this should mean "the guys doing the work and understanding the
issues") in the organisation start feeding him misinformation.
Organisations start rotting quickly if the bottom-up flow of information
is disrupted. The way things are set up here in Germany seems to
encourage such disruptions. And if mid-level management is a failure but
blocks this information from upper management, the guys in the trenches
have not only the right, but the duty to send a letter to upper management.

I have no clue if there is any country that has these things organized
in a better way -- it seems these problems haunt most democracies.

Anyhow, if anyone happens to stumble across the particular software used
in this case, I think it would make for a terribly interesting weekend
of reverse engineering -- I am terribly nosy to what sort of stuff the
tool was capable of :)

Cheers,
Halvar


------------------------------

Message: 6
Date: Tue, 29 Apr 2008 20:15:46 +0200
From: wishi <[EMAIL PROTECTED]>
Subject: Re: [Dailydave] German/Afghanistan Trojan Horse Affair
To: dailydave@lists.immunitysec.com
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Halvar Flake schrieb:

> The entire situation is hilarious, as Mrs. Merkel criticized the chinese
> for having sponsored hacking sprees into German government institutions
> last year - I guess she is not overly happy about all this stuff hitting
> the press now.
> (http://www.timesonline.co.uk/tol/news/world/europe/article2332130.ece)


It's more than hilarious: Germany's home secretary's idea is to develop
  a "Federal Remote Trojan" to gather information for "possible
terrorists". I'm German.

Possible = everyone. A kind of crazy idea, but it's there. This
government declares officially, that there're other countries like
China, that could sell those softwares. In fact China seems to be the
home secretary's ideal idea of government.
(more information:
http://www.vorratsdatenspeicherung.de/component/option,com_frontpage/Itemid,1/lang,en/)



> 
> Anyhow, if anyone happens to stumble across the particular software used
> in this case, I think it would make for a terribly interesting weekend
> of reverse engineering -- I am terribly nosy to what sort of stuff the
> tool was capable of :)
>

http://www.era-it.ch/

I'm not sure right now. But I think that the idea of copyright protected
Malware rose because of the fact, that there're now buyers like
governments, which seek these instruments and pay.
If somebody finds such a piece of code... let me know, too.


Greetings from Germany,
wishi



------------------------------

Message: 7
Date: Wed, 30 Apr 2008 08:26:55 +0200
From: Sebastian Krahmer <[EMAIL PROTECTED]>
Subject: Re: [Dailydave] German/Afghanistan Trojan Horse Affair
To: Halvar Flake <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii


The most funny thing is that the afghan gov is apparently
using yahoo(!) for internal(!) mails*. Nuts! If this is really the case,
its also likely that terrorists read their mails.

Afghan gov should get some assistance in building a secure
and strong communication infrastructure which should be a task
for ISAF. (Might be they did and also installed additional
"important NATO extensions". Version 2.0 of course.)

But as always, the truth is probably completely different. :)

l8er,
S.


* I wonder whether yahoo permits to read mail w/o setting some flag
of the message to "already-read". Otherwise one will notice
surveillance. I am not familar with their mail-setup and whether
they maybe allow pop3 w/o deleting the messages which would
cross around the problem of flagging mails by reading them
in the web GUI.


On Tue, Apr 29, 2008 at 04:19:18PM +0200, Halvar Flake wrote:

> There's a lot of hoopla in German media about the german SIGINT folks
> having to admit that they trojanized Afghanistan's Ministry of Commerce
> and Industry.
> (http://www.spiegel.de/international/germany/0,1518,550212,00.html)
...

-- 
~
~ perl self.pl
~ $_='print"\$_=\47$_\47;eval"';eval
~ [EMAIL PROTECTED] - SuSE Security Team
~ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)



------------------------------

Message: 8
Date: Tue, 29 Apr 2008 21:01:44 -1000
From: Anthony Giandomenico <[EMAIL PROTECTED]>
Subject: [Dailydave] ShakaCon 2008 Update
To: <dailydave@lists.immunitysec.com>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"

Aloha Everyone!
 
The deadline for the Call for Papers for Shakacon 2008 has been extended to
APRIL 30, 2008. So far we?ve received a handful of interesting and exciting
papers that we?ve selected from.
 
Both technical and non-technical submissions on all aspects of security are
welcome!
 
------------------------------------------
Shakacon CALL FOR PAPERS
------------------------------------------
HONOLULU, HI ? Following the great success that we had at the first Shakacon
- the second annual Shakacon security conference - where industry,
government, academia and independent experts will get together to share
knowledge - will be held in the heart of Honolulu on June 10-11, 2008.  One
of the most beautiful places on Earth will be the backdrop for a unique
conference experience. Informative sessions will present both current
research and practical experience on a broad range of security topics.

Shakacon will offer local, national, and international participants a
casual, social learning environment designed to present a "holistic"
security view and the opportunity to network with peers and fellow
enthusiasts in a relaxed setting.
  
During the day, sessions will include: best practices, case studies,
research projects, etc. covering all different aspects of security to offer
a layered view of the security landscape.  Expect topics as wide ranging as
security training to forensic investigations.  There will be something for
everyone.  After-hours, the learning will continue with exciting events and
contests that will test skills and knowledge.
 
Papers may be submitted to the review committee by April 30th, 2008.
Slides for your papers must be submitted by May 9th, 2008.
 
There are only a limited number of speaking sessions for which the
conference organizers will provide travel and accommodations.
 
E-Mail your proposal including: brief topic summary, paper, and bio to
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> .  Your subject line should
include:
 
"Submission: <paper title>, <your name>"

The audience will be a broad mix of professional, academic, and enthusiast,
so we welcome both technical and non-technical submissions on all aspects of
security.  The key criteria are practicality and timeliness.  We want to
provide our attendees with materials they can take away and immediately gain
benefit from.  Absolutely NO SALES presentations ? our attendees don?t show
up to hear people talk about what they can sell them or why they need your
services.
Proposals should include:
1. Name, address, and contact info.
2. Employer and/or affiliations.
3. Brief biography.
4. Presentation experience.
5. Topic summary.
6. Reason this topic should be considered.
7. Other publications or conferences where this material has been or will be
published/submitted.
  
Please include plain text of all information provided in the body of your
email as well as any file attachments. The plain text information will be
reviewed first to find the most suitable candidates.

Please forward the above information to [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>  in order to be considered.
  
More information, registration and hotel details, and partner deals will be
posted to: 
http://www.shakacon.org <http://www.shakacon.org/> 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. E-mail transmission cannot be guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or contain viruses. The sender therefore 
does not accept liability for any errors or omissions in the contents of this 
message, which arise as a result of e-mail transmission. If verification is 
required please request a hard-copy version. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://lists.immunitysec.com/pipermail/dailydave/attachments/20080429/2f2ddaeb/attachment.htm
 

------------------------------

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


End of Dailydave Digest, Vol 33, Issue 9
****************************************

Reply via email to