RE: [Full-Disclosure] How big is the danger of IE?
>>Outlook and Outlook Express use IE to display HTML mails, which make some of the IE bugs exploitable (I don't know if it's the case for this one). In general this isn't true for any remotely recent copy of either program. Both run HTML mail in the restricted zone which disabled all script, ActiveX and anything else dangerous ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] How big is the danger of IE?
>>...the security zone model itself (well, at least its implementation in IE, etc) _is the problem_ and can often be exploited independent of the scritping, and other active content processing, state of the zone in which some arbitrary piece of HTML is rendered. So you can do a cross-zone attack against the restricted zone, with all scripting and active content disabled? I'd like to see an example of this. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] What about M$ in the shell: race
>>However, the shell: command opens the programs when used locally in the URL bar. If by this you are referring to the preposterous scenario in which someone literally types 'shell:windows\\system32\\calc.exe' or something like it into the Address bar, I just tested it and you're incorrect. I get an Invalid Syntax error. Try again. >>I think it would have to be used with another IE vuln to really create a problem-However, the shell: command opens the programs when used locally in the URL bar. I think it would have to be used with another IE vuln to really create a problem- So because there are vulnerabilities in IE, anything and everything is exploitable? I think you'll have to do better than this. Every bit of real testing I've seen shows this is not a real vulnerability in IE. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] What about M$ in the shell: race
>>http://poc.homedns.org/execute.htm >>http://62.131.86.111/security/idiots/malware2k/installer.htm I don't think of the Shell.Application exploit as the same thing as the shell: link exploit. Am I missing something? >>shell:desktop This really doesn't impress me. I don't see this as an attack at all, unless you can find a way to overflow the folder or something like that. Can you actually run code this way, as was easy to do with Mozilla with a simple shell:folder\\foo.exe? Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] What about M$ in the shell: race
>>The shell: issue is all over Full-disclosure and slashdot but I have yet to see a public response from M$ on the issue. I don't understand the IE angle on this one. Every time I test it on XP I get an Open/Save dialog for the file. This behavior is indistinguishable from a simple href to the file. Are you seeing something different? Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] MicroSopht IE (on XPee only) launches messenger by callto:gates or outlook by outlook:calendar protocols
GO> Micro$opht IE (on XPee only) launches messenger by callto:gates or GO> outlook by outlook:calendar protocols >>Is there anything you can do to Outlook that way, or will it just open? Here's the documentation on the outlook: scheme: http://office.microsoft.com/assistance/preview.aspx?AssetID=HP052428041033&CTT=8&Origin= EC011081751033&Product=out2003 Here's a link to it that won't be broken up by your mail client: http://tinyurl.com/2m2cp I've tried this in a bunch of ways and what it does is to open up Outlook to the appropriate location. If you load it from an IFRAME the frame is empty with a syntax error. I'm also really curious how this could be exploited. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] MicroSopht IE (on XPee only) launches messenger by callto:gates or outlook by outlook:calendar protocols
>>What is this: "eWEEK.com Security Center Editor" Is someone paying you? Can I be one too? Sorry, you need to be able to write coherent english. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Re: shell:windows
>>The shell:windows code does work in IE, the only difference being that it displays a dialogue box when referenced asking if the user wishes to open or save the file. Combine that with a little social engineering and you've got a potential compromise. This behavior is indistinguishable from that of a simple href to the file itself, so there's no point in bringing in the shell: stuff. If you want to assume a little social engineering can do anything than a simple href is a vulnerability for any browser. >>>>Also, when the shell:windows reference is input into IE's address bar field, it executes the code without a a dialogue box... Gimme a break. This is not a meaningful problem. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Re: shell:windows
>>>>>Also, when the shell:windows reference is input into IE's address >>>>>bar field, it executes the code without a a dialogue box... >>>>> >>>Gimme a break. This is not a meaningful problem. >>It's as meaningful as the Mozilla issue. If your point is that that wasn't a meaningful problem either, then we can agree to disagree on the scope. I'll agree that getting this issue to run code of the choosing of the attacker is more difficult than some other unpatched IE holes, but it is not impossible. I disagree completely. The Mozilla problem, which I'll readily agree is not in the same league with most of the recent IE problems, allowed a local program to execute simply by visiting a web page that had the appropriate shell: link in a META tag. You actually think this is on the same level as requiring a user to type "shell:windows\system32\foo.exe" into the Address bar? Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] SP2 is killing me. Help?
>>Does anyone know of an alternate way to initiate a sp2 rollback? Try System Restore. I think you can get at it from booting with F8. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Scandal: IT Security firm hires the author of Sasser worm
>>If you don't really believe that the movie "Catch me if you can" was based on a true story, check out this site: http://www.abagnale.com/index2.asp I don't want to put words in anyone's mouth, but I hope we're not comparing a genius like Abagnale to vandal like Jaschan, who only ever picked low-hanging fruit. Personally I think hiring a sociopath like Jaschan diminishes a company and I wouldn't trust them. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Scandal: IT Security firm hires the author of Sasser worm
>>He wrote a worm. Big freaking deal. Yeah, very big freaking deal. He loosed an attack he had good reason to believe would do damage to innumerable people all over the world. He belongs in jail and for a long time, if only to send a message that such behavior is wrong. And anyone who trusts him with their computers is an idiot. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Denial of service in KitchenAid blenders
I've been reading about blended threats for years, but at last they've
arrived
Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blog.ziffdavis.com/seltzer
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jedi/Sector
One
Sent: Sunday, October 10, 2004 2:13 PM
To: [EMAIL PROTECTED]
Subject: [Full-Disclosure] Denial of service in KitchenAid blenders
Product : KitchenAid blenders
Date: 10/10/2004
Author : Frank Denis <[EMAIL PROTECTED]>
[ Product description
]
From the web site :
KitchenAid offers the most powerful premium blenders available.
Oversized stainless steel blades allow it to crush ice at any speed.
The most powerful premium blender available - features a strong motor
and unique blade design.
One-piece blade assembly features oversized stainless steel blades on
four different planes for optimal blending.
Durable base provides maximum stability during mixing.
The electronic sensor automatically adjusts power to maintain a
consistent speed.
40-oz. heavy-duty glass jar resists scratching and discoloration, and
all jars and lids are dishwasher safe.
Home page : http://www.kitchenaid.com/
[ Vulnerability ]
There's a race condition in KitchenAid blenders that can trigger a
denial of service.
The device will require a physical shutdown in order to work again.
[ Implications ]
The implications are numerous. Chefs can be extremely frustrated, thus
causing severe material and social damage.
[ Exploit ]
Here's a reliable way to reproduce the race:
- Hit the power button ("I"),
- Hit the "pulse" button.
- Hit a speed button,
- While keeping the speed button, push on the "pulse" button again.
The device immediately goes in a strange state. LEDs are blinking and
buttons are no more functionnal until the power is off.
[ Affected versions
]
In lab, the exploit successfully worked on a 5-speed KSB5ER mixer. Its
color was empire red and cold soup was previously inserted in the glass
jar.
Other colors are likely to be affected as well. The silver "pro" model
may be affected as well.
[ Workarounds ]
No workaround is known yet.
Never give access to the device to untrusted users.
[ Vendor status ]
Unfortunately, I wasn't able to find any contact at KitchenAid's for
security flaws in mixer firmwares.
___
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] XP Remote Desktop Remote Activation
>>By default, Remote Desktop is shipped with this service turned off and only the Administrator is allowed access to this service. It is possible, however, to modify a series of registry keys that may allow a malicious user who has already gained a command shell to activate Remote Desktop and ... Like everyone else is saying, if you already own the desktop why not use the user interface Microsoft helpfully provided for this? LJS ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Will a vote for John Kerry be counted by a Hart InterCivic eSlate3000 in Honolulu?
Guess what? In most elections the old fashioned paper absentee ballots aren't counted anyway, unless their number could make a difference in the vote total. It's always been this way. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Coombs PivX Solutions Sent: Wednesday, October 20, 2004 9:25 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [Full-Disclosure] Will a vote for John Kerry be counted by a Hart InterCivic eSlate3000 in Honolulu? I just voted for John Kerry at a walk-in absentee ballot polling place in Honolulu County using an eSlate3000 (unit serial number A05A0B) made by Hart Intercivic: http://www.hartintercivic.com I was told by the official who gave me the choice of voting on paper or voting electronically that the electronic voting machines weren't supposed to be here yet, but that since they arrived in time for the 2004 election, they were being used anyway. Will my vote be counted? That depends on a number of unknowns, such as whether or not the unit on which my vote was cast subsequently malfunctions, rendering the entire vote tabulating memory card corrupt. I did not receive a paper printout following the submission of my electronic ballot. Excluding the obvious possibility that fraud may occur, either to stuff the electronic 'ballot box' with false votes, or to intentionally destroy or fail to count votes for a particular candidate, there are risks inherent to electronic voting that do not exist in the same way with paper ballots. And although there are technical safeguards possible that seem like common sense, these safeguards continue to be ignored. Why? Will we ever see common sense safeguards added to the electronic voting process? A search for known security vulnerabilities or potential flaws in voting equipment manufactured and sold by Hart InterCivic turns up: http://www.conspiracyplanet.com/channel.cfm?channelid=31&contentid=1570 Prior to casting my vote, I provided a written 'application' to vote containing my current address and other contact information. Election officials have every bit of information necessary to inform me in the event of a memory card failure or other malfunction that causes my electronic vote not to be counted properly. We know the very equipment that I just used to cast my vote has malfunctioned in the past. There have never been any reports that any voter has ever been allowed to revote following the loss of their electronic vote database record. Why not? I find it absurd that common sense solutions to electronic voting problems are not being used. The vote I just cast could be made available for my anonymous review after it has been counted. For that matter, all votes made by all voters could be aggregated and published such that any voter could confirm that the vote that was counted was in fact the vote that they cast. Such a safeguard would ensure that no fraud could occur without timely detection by those voters who are directly affected, and no vote would go uncounted or be miscounted by mistake unless voters choose not to perform such data validation. If we're going to allow these electronic voting devices in our elections, then we the people must be empowered to become the all volunteer quality assurance army that validates the data output. Reasonable people can live with the necessity to trust election officials to be honest, and the criminal justice procedures to hold them accountable when they are not, but who are we supposed to hold accountable when equipment failures and flawed computer disaster recovery planning result in the secret exclusion of members of the public from access to their right to vote? If anyone has any further information about Hart InterCivic and the eSlate3000, please contact me directly. Sincerely, Jason Coombs [EMAIL PROTECTED] ___ 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: Windows XP explorer.exe heap overflow.
Title: Message
I can confirm the non-error on
a WMF file, but the alert referred to EMF files. I can't locate one. Would they
necessarily be the same?
Larry SeltzereWEEK.com Security Center Editorhttp://security.eweek.com/[EMAIL PROTECTED]
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Evgeny
PinchukSent: Tuesday, February 24, 2004 10:42 AMTo:
'[EMAIL PROTECTED]'; [EMAIL PROTECTED]Cc:
[EMAIL PROTECTED]Subject: [Full-Disclosure] RE:
Windows XP explorer.exe heap overflow.
Hi,
I modified a WMF file at offset 24 (0x18h) which is the header
size and could not recreate the bug. The header size
of WMF file is always 9 and modifying it results only an error message that
the file couldn't be shown.
Some info on WMF files: Format:
-Placeable Meta Header - (22
bytes) -Standard Meta
Header - (18 bytes) -Standart Metafile Record1 - ...
-Standart Metafile RecordN -
Structures: typedef struct
_PlaceableMetaHeader {
DWORD Key; /*
Magic number (always 9AC6CDD7h) */ WORD
Handle; /* Metafile HANDLE number
(always 0) */ SHORT
Left; /* Left coordinate
in metafile units */ SHORT
Top; /* Top
coordinate in metafile units */ SHORT
Right; /* Right coordinate in
metafile units */ SHORT
Bottom; /* Bottom coordinate in
metafile units */ WORD
Inch; /* Number of
metafile units per inch */ DWORD
Reserved; /* Reserved (always 0) */
WORD Checksum; /*
Checksum value for previous 10 WORDs */ }
PLACEABLEMETAHEADER;
typedef struct _WindowsMetaHeader { WORD
FileType; /* Type of metafile (0=memory,
1=disk) */ WORD
HeaderSize; /* Size of header in WORDS (always 9)
*/ WORD
Version; /* Version of Microsoft
Windows used */ DWORD
FileSize; /* Total size of the metafile in
WORDs */ WORD NumOfObjects;
/* Number of objects in the file */ DWORD
MaxRecordSize; /* The size of largest record in WORDs */
WORD NumOfParams; /* Not Used
(always 0) */ } WMFHEAD;
More information about WMF files can be found at http://www.whisqu.se/per/docs/wmf.htm
Evgeny.
> -Original Message- >
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 20, 2004 8:46 PM > To: [EMAIL PROTECTED] >
Subject: Windows XP explorer.exe heap overflow. >
> > > Vulnerability in XP explorer.exe image loading > -- > > Systems affected: > Current XP - others not tested. > > Degree: > Arbitrary code execution. >
> Summary >
--- > A malformed .emf (Enhanced Metafile, a
graphics format) file can cause an > exploitable
heap overflow in (or near) shimgvw.dll. >
> Details >
--- > The image preview code that explorer uses
has an exploitable buffer > overflow.
> > An .emf file with a "total
size" field set to less than the header size > will
causes explorer.exe to crash in the heap routines - in classic heap
> overflow style that should be exploitable a la the RPC
exploits. > > There are
two overflows here: > >
1. A buffer is allocated with the size indicated in the header (no
> validity checks), then the header is copied into it - if
the size is less > than the header size, that's one
overflow. > > 2. They
then proceed to read the rest of the file to a length of (size-
> headersize), which allows for an integer overflow
causing the rest of the > file to be appended to
the already blown buffer. > > Exploit > --- > To exploit this flaw (in explorer), simply place a malformed
(invalid > "size" field) .emf file > in any directory, open explorer to that path, and view as
Thumbnails. > Bang. In it's simplest
> form it's a DOS - it affects all explorer windows,
including File Open > dialogs for many
programs. > >
Alternatively, without viewing as a Thumbnail, open the picture preview
> window for the .emf file. (It's the default double-click
action). Using > this trigger causes a different
crash point, which may not be exploitable, > but I
wouldn't rule it out. > > Additional notes >
> It may be worth checking out
similar issues in .wmf files, as they are >
similar. > >
> - Jellytop, 2004 >
> "If a man will begin with certainties, he shall
end in doubts; but if he > will be content
to > begin with doubts he shall end in
certainties."
RE: [Full-Disclosure] Backdoor not recognized by Kaspersky
>>Attached backdoor not recognized by Kaspersky or Norton 2004?
It's Bagle/Beagle.J. The problem is that the file is password-protected, so it's not
obvious how a scanner will get it until it's opened. Notice that the e-mail includes
the
password ("65316"). In fact Norton finds it when the ZIP is opened and the extracted
file hits the file system.
Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Kristian Hermansen
Sent: Tuesday, March 02, 2004 5:34 PM
To: [EMAIL PROTECTED]
Subject: [Full-Disclosure] Backdoor not recognized by Kaspersky
Attached backdoor not recognized by Kaspersky or Norton 2004? I received this file
recently, but Kaspersky did not detect malicious code. Wondering if any of you guys
know about it or have analyzed it before? It is definitely NOT a text document. I
opened it up with WinHex and see the file "yfivyjmg.exe" in there towards the
beginning.
Looks to be a packed exe within, and first few bytes are:
504B03040A000100C07E62309FE242510C3000300C0079666976796A6D67
2E6578653A47705E116B1456E7F572AF21A99C0D52671B62085EC94DD8FDABE712E68000E55E
E8A39241
Last few bytes are:
E19F9DC6E1E9F0FAA7CD925D18C9104DCA9DF88955F8AEBD81D036BCB930889EAE0D2BA2A6EF
88A334F8B3108A414B1C9D15AA883225504B010214000A000100C07E62309FE242510C30
00300C000100200079666976796A6D672E657865504B
0506010001003A003630
I am reluctant to open the zip right now, as I fear it may be exploiting an overflow to
run the EXE file within. I may try to open it on a virtual machine later, but if you
guys do know anything about this one please let me know. It's nice and small too (12
KB)! Wonder if the guy wrote it himself. Of course, the IP address is spoofed to a
University of Chicago machine. Is it even possible to trace back? I still have the
full headers, but they looked nicely stripped to the gills. I have been receiving
elevated attacks via email over the last few days, so maybe it is some guy on this list
trying to get me ;-) One previous email stated that it was the FBI and to call a
number
listed in the email. This was most likely an attempt to get the number I was calling
from. This guy thinks he's smooth...
Kristian Hermansen
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 02, 2004 5:03 PM
To: [EMAIL PROTECTED]
Subject: E-mail account security warning.
Dear user of {blankedout}.com gateway e-mail server,
Your e-mail account has been temporary disabled because of unauthorized access.
For details see the attached file.
For security purposes the attached file is password protected. Password is
"65316".
Best wishes,
The {blankedout}.com team http://www.
{blankedout}..com
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Backdoor not recognized by Kaspersky
>>The problem is the antivirus installed in the perimeter, that does not detect those samples. Exist some antivirus that detects the ZIP infected without knowing the password: I'm sure more of these detect it by now. I suppose SOP for these scanners has been to extract files from ZIPs and scan them, but they need a more complex procedure now. Is it possible that portions of the encrypted ZIP are consistant enough regardless of the key that they can identify it? If not, for this particular case they could hack at the ZIP file and use the message body as a dictionary. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Backdoor not recognized by Kaspersky
>>I feel the need to address the problem from an ISP perspective, since the corporate and government and other institutional persective seems to give different answers. And because the ISP end user problem is still the majority of the reservoir for viruses (and spam proxy/relay/trojans). I really feel for you guys. As I've argued in another thread, I think SMTP authentication will likely cut this stuff down to a trickle compared to the current volume. As an ISP, how big a problem would you have with that. An even better question: Would you have a problem implementing SPF, Caller ID and Domain Keys (i.e. all 3)? It gets to the same issue of changing practices for your users: at some point you have to either bounce or segregate mail that doesn't authenticate. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Backdoor not recognized by Kaspersky
>>if you can read the users login credentials to his corporate mailserver you are far better off. Rather casually put. How would you do this? I've heard how Swen asks the user for their credentials, but if you know a general crack for obtaining them I'd say that's news. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ [EMAIL PROTECTED] -Original Message- From: Thor Larholm [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 6:47 PM To: Larry Seltzer; Mike Barushok; [EMAIL PROTECTED] Subject: RE: [Full-Disclosure] Backdoor not recognized by Kaspersky SMTP authentication will not do much to stop viruses from spreading. Some viruses are already moving away from just implementing their own SMTP server to reusing whatever SMTP credentials you have on your machine. Having your own SMTP engine is a nice fallback solution just in case, but if you can read the users login credentials to his corporate mailserver you are far better off. Imagine us all implementing SPF, Caller ID or Domain Keys - what would happen? We would all have to use a mail server that has implemented one of these 'solutions'. Naturally, virus writers would then just reuse your SMTP login credentials to spew their virus through that same MTA. Another quick workaround to SPF, Caller ID and Domain Keys has alredy been implemented by spammers for a year or so. The only premise behind S/C/D is that you are trusted if you have access to a DNS server. Spammers are using compromised machines not only as SMTP servers, but also web servers and DNS servers. The end result is that spammers have already completely circumvented all three solutions way before they were ever implemented. Regards Thor Larholm Senior Security Researcher PivX Solutions 24 Corporate Plaza #180 Newport Beach, CA 92660 http://www.pivx.com [EMAIL PROTECTED] Phone: +1 (949) 231-8496 PGP: 0x5A276569 6BB1 B77F CB62 0D3D 5A82 C65D E1A4 157C 5A27 6569 PivX defines "Proactive Threat Mitigation". Get a FREE Beta Version of Qwik-Fix <http://www.qwik-fix.net> -Original Message- From: Larry Seltzer [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 1:38 PM To: 'Mike Barushok'; [EMAIL PROTECTED] Subject: RE: [Full-Disclosure] Backdoor not recognized by Kaspersky >>I feel the need to address the problem from an ISP perspective, since >>the corporate and government and other institutional persective seems to give different answers. And because the ISP end user problem is still the majority of the reservoir for viruses (and spam proxy/relay/trojans). I really feel for you guys. As I've argued in another thread, I think SMTP authentication will likely cut this stuff down to a trickle compared to the current volume. As an ISP, how big a problem would you have with that. An even better question: Would you have a problem implementing SPF, Caller ID and Domain Keys (i.e. all 3)? It gets to the same issue of changing practices for your users: at some point you have to either bounce or segregate mail that doesn't authenticate. ___ 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] Backdoor not recognized by Kaspersky
>>SMTP auth does not help at all. A virus that delivers email via it's own SMTP engine completely bypasses the end users ISP server(s). And if the recipient server does not allow incoming mail from wherever it is presented from, then incoming mail will simply be broken unless there is some sort of SPF. Yeah, exactly, that's the point. SMTP AUTH plus something like SPF/CID/DK would stop all the existing worms from operating. Mail sent through their own engines would be rejected by SPF/CID/DK. >>But, SPF, caller-ID, and Domain keys all have major unsolved issues with forwards, aliases, corporate employees checking their work mail and needing to reply through their home connection ISP, but with their company 'From: ' address and several other common scenarios. Until their is universal adoption of some add on to SMTP, nobody can reject all non-conforming mail safely. It's not hard to imagine the largest ISPs and large corps accepting it, at which point it would become necessary for others to accept it or risk having their mail shut out. >>All implementations create a much greater load on DNS. Greater, yes. Much greater, I'm not so sure. Verisign doesn't think it's a substantial extra load. The DNS data could very reasonably be cached. >>The real issue is that their is no possible algorithmic solution to rejecting email reliably based on any of its source, its content, or any combination. So SPF/CID/DK don't work? They reject based on domain >>If the mail is not accepted, laws prohibit silently discarding it. I've never heard this before. What law? Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Backdoor not recognized by Kaspersky
> Another quick workaround to SPF, Caller ID and Domain Keys has alredy > been implemented by spammers for a year or so. The only premise behind > S/C/D is that you are trusted if you have access to a DNS server. > Spammers are using compromised machines not only as SMTP servers, but > also web servers and DNS servers. The end result is that spammers have > already completely circumvented all three solutions way before they > were ever implemented. I'm really not clear how this could work on a DHCP client, which the overwhelming majority of compromised systems must be. Please don't just tell me it's magic and works. What you said in another message about just cracking the storage of credentials in the registry or file system impresses me more and I'm looking into it. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Backdoor not recognized by Kaspersky
>>TCPA, the Telecommunications Communications Privacy Act. You must have this name wrong. Apart from the redundancy, I Googled it and got nothing. Do you mean the "Telemarketing and the Telephone Consumer Protection Act (TCPA)"? ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Backdoor not recognized by Kaspersky
> >>TCPA, the Telecommunications Communications Privacy Act. http://www.nyfairuse.org/action/palladium That's "Trusted Computing Platform Alliance" and totally off the point. LJS ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] XP SP2 is out
>>http://www.microsoft.com/technet/prodtechnol/winxppro/sp2preview.mspx Actually, this is just release candidate 1, and we already know there will be a release candidate 2. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Re: XP SP2 is out: 279MB
>>Have you seen the size of it? 279 MB! It's not surprising that it's large. Large parts of the core of Windows are recompiled in this SP to add stack-checking and things like that. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] E-mail virus free tags (Was: SHUT THE F**K UP)
>>The main reason an Antivirus company would spend the resources on adding code to append a message to outgoing mail is for marketing purposes. It gets their product name out there. Right, it's ironically called "viral marketing" Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Trojan Horse for Mac OS X
>> This technique wouldn't work now because Mail.app, and probably all >> modern mail client. Will not let you execute code from within the mail >> client. >Completely untrue. Mail.app will ask you if you want to open the app just like Outlook Express on Windows does. Actually, Outlook Express and Outlook will (by default) strip all executable attachments before you even get them. They've done this for some time. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Trojan Horse for Mac OS X
>>Actually this is not correct. By default they will deny you the ability to save or open the attachments, but they do not strip anything. Same difference, and in any event Outlook/OE sounds nothing like Mail.app, but very much like what the person you corrected said. >>My experience is that users almost always turn off that feature so they can save >>those questionable file types again. I hear a lot of people say this in order to diminish the feature, but I don't think it's true at all. The vast majority of people don't even know they're missing anything, and that's just as well. >>The feature on or off will still leave the attachments on the emails. Inaccessible by the user Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua Levitsky Sent: Friday, April 09, 2004 7:02 PM To: Larry Seltzer Cc: 'Thomas Vincent'; 'Full-Disclosure' Subject: Re: [Full-Disclosure] Trojan Horse for Mac OS X On Apr 9, 2004, at 6:53 PM, Larry Seltzer wrote: >>> This technique wouldn't work now because Mail.app, and probably all >>> modern mail client. Will not let you execute code from within the >>> mail client. > >> Completely untrue. Mail.app will ask you if you want to open the app >> just like Outlook > Express on Windows does. > > Actually, Outlook Express and Outlook will (by default) strip all > executable attachments before you even get them. They've done this for > some time. > Actually this is not correct. By default they will deny you the ability to save or open the attachments, but they do not strip anything. My experience is that users almost always turn off that feature so they can save those questionable file types again. The feature on or off will still leave the attachments on the emails. -Josh ___ 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] Trojan Horse for Mac OS X
You might have noticed I said "by default". How many people do you really think change that setting. Seriously. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mary Landesman Sent: Friday, April 09, 2004 7:45 PM To: Larry Seltzer; 'Joshua Levitsky'; 'Thomas Vincent' Cc: 'Full-Disclosure' Subject: Re: [Full-Disclosure] Trojan Horse for Mac OS X Check out Tools, Options, Security, Do not allow executable attachments... Uncheck it. Voila. Still there. Not removed. Just suppressed. And under complete end user control. -- Mary ----- Original Message - From: "Larry Seltzer" <[EMAIL PROTECTED]> To: "'Joshua Levitsky'" <[EMAIL PROTECTED]>; "'Thomas Vincent'" <[EMAIL PROTECTED]> Cc: "'Full-Disclosure'" <[EMAIL PROTECTED]> Sent: Friday, April 09, 2004 6:53 PM Subject: RE: [Full-Disclosure] Trojan Horse for Mac OS X >> This technique wouldn't work now because Mail.app, and probably all >> modern mail client. Will not let you execute code from within the mail >> client. >Completely untrue. Mail.app will ask you if you want to open the app just like Outlook Express on Windows does. Actually, Outlook Express and Outlook will (by default) strip all executable attachments before you even get them. They've done this for some time. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] ___ 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] Sasser author
>>Sasser violates poorly designed/implemented network infrastructures. I think we'd better be careful with all this moral equivocating. Some of it's right up there with "she was wearing provocative clothing." It's obvious who the criminal is and who the victim is. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] New therad: sasser, costs, support etc alltogether
So society is to blame I guess. This is the same brain-dead logic that concludes that we shouldn't arrest poor people who commit crimes. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Radule Soskic Sent: Friday, May 14, 2004 11:28 AM To: [EMAIL PROTECTED] Subject: [Full-Disclosure] New therad: sasser, costs, support etc alltogether I can't post this to all the threads that I would like to, so I'm opening a new one. Follow this: 1. MS is wrongdoing by releasing (and charging for use of) software that has bugs in it. Users of such software have losses in time/money by trying to keep up with applying pathches, or just by trying to keep the uptime high. 2. Admins are wrongdoing by not applying patches to the systems they maintain. There are losses tied to such misspractice, too. 3. Worm authors are wrongdoing by writing software that propagate through the networks by exploiting all of the above. Again, the losses occur in time/money spent to remove the worms from the systems affected. It is obvious that almost every legal system in the world treats #3 as crime, while #2 and #1 are broadly tolerated. Noone here is against the book of law, but it just seems to be in contrast to the natural and intuitive feeling of justice that majority of people might have regarding the issues like these. See - only one of the three wrongdoers is being punished. Is it right? Or - is it wrong? BTW, I have a funny feeling that damages/losses caused by #3 might very often be far less than the ones caused by #2 and #1. Am I alone? cikasole ___ 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] Agobot author is a pacifist?
There's more evidence from this story that he's a "coward" than a "pacifist" Do they draft 21 year-olds in Germany? Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Feher Tamas Sent: Tuesday, May 18, 2004 4:45 AM To: [EMAIL PROTECTED] Subject: [Full-Disclosure] Agobot author is a pacifist? http://www.theregister.co.uk/2004/05/17/phatbot_suspect_bailed/ Phatbot suspect released on bail By John Leyden, The Register, 17 May 2004 The suspected author of the Phatbot Trojan was released on bail last Friday after spending a week in custody. German authorities arrested the 21-year-old coder - named only as Alex G. in local reports - from Waldshut in southern Germany on 7 May at the same time as the author of the Sasser worm, 18 year-old Sven Jaschan. Police said the two operations were co-ordinated but unrelated. Emails from the suspect showed he wanted to leave Germany to avoid military service. This, combined with the seriousness of computer sabotage charges he faced, led police to initially oppose bail. Police have now relented after the suspect agreed to surrender his identity papers and report regularly to police. Phatbot is a variant of Agobot, a big family of IRC bots, which can be used to steal personal information or seize control of infected machines. Since debuting in October 2002, source code for the Agobot has been distributed on the Internet and hundreds of versions have been created. ___ 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] Agobot author is a pacifist?
I think we found what to do with this guy. You always need another hand to dig latrines and clean them out. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Internet explorer 6 execution of arbitrary code (An analysis of the 180 Solutions Trojan)
>>Finally I also attached the source files to this message My McAfee-based gateway scanner blocks the attachment and labels it as "VBS/Psyme", which has this description (http://us.mcafee.com/virusInfo/default.asp?id=description&virus_k=100749): "This trojan exploits an unpatched (at the time of this writing) vulnerability in Internet Explorer. The vulnerability allows for the writing, and overwriting, of local files by exploiting the ADODB.Stream object. There are several variants of this trojan. Therefore this description is design to give an overview of how the trojan works. The trojan exists as VBScript. This script contains instructions to download a remote executable, save it to a specified location on the local disk, and then execute it." Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[sb] RE: [Full-Disclosure] Internet explorer 6 execution of arbitrary code (An analysis of the 180 Solutions Trojan)
>>Finally I also attached the source files to this message My McAfee-based gateway scanner blocks the attachment and labels it as "VBS/Psyme", which has this description (http://us.mcafee.com/virusInfo/default.asp?id=description&virus_k=100749): "This trojan exploits an unpatched (at the time of this writing) vulnerability in Internet Explorer. The vulnerability allows for the writing, and overwriting, of local files by exploiting the ADODB.Stream object. There are several variants of this trojan. Therefore this description is design to give an overview of how the trojan works. The trojan exists as VBScript. This script contains instructions to download a remote executable, save it to a specified location on the local disk, and then execute it." Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] -- Sie haben den Sicherheitsboten abonniert. http://sicherheitsbote.net ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] COELACANTH: Phreak Phishing Expedition
>>http://www.malware.com/golly.html I see no pattern at all, but this works on some systems for me and not on others. On some I get to Microsoft, some to e-gold.com. And WTF is it with www.e-gold.com? Nothing else seems to work at all. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
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? >>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 [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Spam Solution
>>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 [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Spam Solution
>>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 [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] RE: Spam Solution
>>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/[EMAIL PROTECTED] 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 [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] IE exploit runs code from graphics?
>From http://www.eweek.com/article2/0,,1617045,00.asp: "Analysts at NetSec Inc., a managed security services provider, began seeing indications of the compromises early Thursday morning and have since seen a large number of identical attacks on their customers' networks. The attack uses a novel vector: embedded code hidden in graphics on Web pages... NetSec officials said the attack seems to exploit a vulnerability in Internet Explorer." ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] IE exploit runs code from graphics?
>>Without having access to any of the information as to what web pages NetSec thinks is involved, >>but having seen many recent posts about the so-called "RFI - Russian IIS Hacks" I'd suggest >>that both reports are referring to one and the same, or at least, very closely related, things. >>... >>That is hardly the same thing as "embedded code hidden in graphics on Web pages"... Yup, once I saw the SANS writeups I came to the same conclusion. So there's nothing really new in the client-side exploit and what's happening on the server hasn't been figured out yet, right? And it sounds like if you're up to date on patches and antivirus you're probably protected against the client-side exploit. Larry Seltzer ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Your account at Wells Fargo has been suspended (Phishing Scam)
>>There are no products to protect against phishing other than user education and vigilance along with refining the current model for mail. Sender ID would have blocked this because of the fraudulent From: header, even assuming it wasn't blocked because of envelope problems. This is yet another reason we need an SNTP authentication scheme in place, and not one just based on envelope data. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Babak Pasdar Sent: Wednesday, July 07, 2004 7:10 AM To: [EMAIL PROTECTED] Subject: [Full-Disclosure] Your account at Wells Fargo has been suspended (Phishing Scam) ATTENTION, We have uncovered a phishing scam. This is a perfect example of a phishing scam. All indicators (that the recipient sees) show a valid and legitimate e-mail from Wells Fargo. This e-mail tells the user their account has been frozen due to fraudulent activity and gives them a link to go to. However when you click on the link it takes you to a site in Korea and not Wells Fargo: http://online <http://online> _wellsfargo_com_account.rndsystems.co.kr:7301/wells.htm If you clink on the link an exact model of the Wells Fargo web site replicated. This is the exact type of issue we had success with in working with the FBI which led to an arrest of an unsavory Russian character. There are no products to protect against phishing other than user education and vigilance along with refining the current model for mail. Babak Here is a quick assessment that confirms the e-mail is fraudulent. In the header notice the source sending it to igxglobal is not identifiable via reverse DNS: Received: from dns (unknown [211.238.157.101]) by imgxs43.goimaginex.net (Postfix) with SMTP id 15105B0016 for <[EMAIL PROTECTED]>; Tue, 6 Jul 2004 15:08:21 -0400 (EDT) Further research shows that the contact for the network IP in question is Kanghyun Lee out of Seoul, South Korea: person: KANGHYUN LEE descr:BUSYKOREA descr:, Guro 5(o)-dong , Guro-gu descr:SEOUL descr:152-055 country: KR phone:+82-2-862-1780 e-mail: [EMAIL PROTECTED] nic-hdl: KL512-KR mnt-by: MNT-KRNIC-AP Further investigation on the web site shows the following owner: Domain Name : rndsystems.co.kr Registrant: R&D SYSTEMS Registrant Address: Pusan Venture Bldg.#305 651-1 Eomgung-dong, Sasang-gu, Busan, Republic of Korea Registrant Zip Code : 617831 Administrative Contact(AC): Kang Young Gyun AC E-Mail: [EMAIL PROTECTED] AC Phone Number : 0513261777 Registered Date : 2002. 05. 17. Last updated Date : 2003. 04. 24. Expiration Date : 2005. 05. 17. Publishes : Y Authorized Agency : I-NAMES(the "I" stands for "Internet") Corporation (http://www.i-names.co.kr <http://www.i-names.co.kr> ) Primary Name Server Host Name : www.rndsystems.co.kr <http://www.rndsystems.co.kr> IP Address : 211.33.221.36 - KRNIC Whois Service - Return-Path: <[EMAIL PROTECTED]> Received: from groupware.igxglobal.com ([unix socket]) by groupware (Cyrus v2.1.16) with LMTP; Tue, 06 Jul 2004 15:08:31 -0400 Received: from dns (unknown [211.238.157.101]) by imgxs43.goimaginex.net (Postfix) with SMTP id 15105B0016 for <[EMAIL PROTECTED]>; Tue, 6 Jul 2004 15:08:21 -0400 (EDT) From: Wells Fargo National Association <[EMAIL PROTECTED]> To: Bpasdar <[EMAIL PROTECTED]> Subject: Your account at Wells Fargo has been suspended Date: Wed, 7 Jul 2004 03:59:20 +0900 Reply-To: Wells Fargo National Association <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal X-Mailer: EM: 4.52.0.790 Content-Type: multipart/alternative; boundary="_PartID_337380760025388" X-Virus-Scanned: IGX Global Secure Mail Relay X-Evolution-Source: imap://[EMAIL PROTECTED]:993/ -Forwarded Message- From: Wells Fargo National Association <[EMAIL PROTECTED]> To: Bpasdar <[EMAIL PROTECTED]> Subject: Your account at Wells Fargo has been suspended Date: Wed, 07 Jul 2004 03:59:20 +0900 Dear Wells Fargo account holder, We regret to inform you, that we had to block your Wells Fargo account because we have been notified that your account may have been compromised by outside parties. Our terms and conditions you agreed to state that your account must always be under your control or those you designate at all times. We have noticed some activity related to your account that indicates that other parties may have access and or control of your information in your account. These parties have in the past been involved with money laund
RE: [Full-Disclosure] Re: Evidence Mounts that the Vote Was Hacked
Why would anyone place any credibility in exit polls? They were wildly inaccurate in 2000 as well, and they didn't have a great reputation before that. In blue states too. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Kramer Sent: Wednesday, November 10, 2004 8:47 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Full-Disclosure] Re: Evidence Mounts that the Vote Was Hacked Tom Le <[EMAIL PROTECTED]> may have written:- >In fact, Repubs leaked their exit poll numbers early for Florida and >Ohio before the counts had come in and they were extremely accurate. > It seems to me that whats being postulated is that somehow the Republicans rigged the result in Florida and that the evidence for this are discrepencies between exit polls and the final result. But you are saying the Republicans exit polls matched the final result. I wonder what William of Occam would make of this? :) ___ 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: Evidence Mounts that the Vote Was Hacked
>>Look at the difference between exit polling and actual results. The election results and exit polls differ, therefore you assume the election results are wrong? This is really dumb. There are endless reasons to believe that exit polls are inaccurate. For one thing, they're self-sampling: they ask you whether you want to participate. Of all the bad arguments made to claim the election was hacked this is the easiest to dismiss. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] I thought Microsoft were releasing new securitypatches today (11 Jan 2005)?
Tuesday, 1PM eastern ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] FW: New Security Patches from Microsoft
>>No IE patch, it would seem. No, but... > MS05-001 (Critical)Vulnerability in the Indexing Service Could Allow > Remote Code Execution (871250) Vulnerability in HTML Help Could Allow > Code Execution (890175) > http://www.microsoft.com/technet/security/Bulletin/MS05-001.mspx > > MS05-002 (Critical) > Vulnerability in Cursor and Icon Format Handling Could Allow Remote > Code Execution (891711) > http://www.microsoft.com/technet/security/Bulletin/MS05-002.mspx > Both of these address problems that have been exploited through IE. These are the ones that have gotten so much recent publicity. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Re: Terminal Server vulnerabilities
>>> [MS] claim there are no >>> unfixed vulnerabilities to Terminal Server on Windows Server 2000 >>> Service Pack 4. >>> >>> I find that hard to believe and I know you guys will know if they are >>> full of it, or they are correct. Please let me know ASAP of any >>> CURRENT vulnerabilities int Terminal Server. >>Try here for starters: >>http://www.google.com/search?q=%22windows+terminal+server%22+exploit&s ourceid=mozilla&start=0&start=0&ie=utf-8&oe=utf-8 >>(2,310 results) Just as I figured. Based only on the first 25 or so, all of the real exploits discussed are patched and the vast majority of them apply to Windows NT 4.0 Terminal Server. The original poster asked about "CURRENT" vulnerabilities. The one remaining issue I remembered is on this page (http://www.saintcorporation.com/cgi-bin/demo_tut.pl?tutorial_name=Micro soft_Terminal_Server.html&fact_color=doc&tag=), which is also a good collection of vulnerabilities in general. It is a man-in-the-middle attack that could allow an attacker, using a collection of techniques including IP spoofing, to recover the original plaintext session. RDP, the Terminal Server protocol, is encrypted by default. The worst thing you have to do to work around this is to use a VPN, but considering what they would recover is RDP data (mouse moves, key clicks, GDI elements, etc.) I consider this a relatively high-overhead attack. Your Windows Terminal Server is much more likely to be vulnernerable to a problem in Windows than one specifically in Terminal Server, which has a very good security history. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Re: Terminal Server vulnerabilities
Yeah, fine, so if this bothers you use a VPN. I still it's something very few people need to worry about. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Senior Sent: Tuesday, January 25, 2005 12:00 PM To: full-disclosure@lists.netsys.com Subject: RE: [Full-Disclosure] Re: Terminal Server vulnerabilities Terminal Server encrypts its traffic, yes, but it doesn't do any verification of what server it's connecting to. This is equivalent to SSL with anonymous DH key agreement - you know no eavesdroppers can listen in, but you have no idea who you're talking to. So a MiTM attack is possible, there is no difficulty decrypting the traffic - you just make the entire session terminate at the attacking end, and make a new session to the real server. Yes, most of the keypresses would be uninteresting information, but there are a few right at the start, typically between a TAB and an ENTER, that might be of some interest... The annoying thing is, the server does actually have a persistent key, which the client could verify from one connection to the next - it just doesn't; it throws the key away after the connection is established. It's not unfixable; fixing it wouldn't even break the existing protocol. The client would just have to behave like an ssh client, and check its known keys. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Larry Seltzer Sent: January 25, 2005 04:27 To: 'Daniel H. Renner'; full-disclosure@lists.netsys.com Subject: RE: [Full-Disclosure] Re: Terminal Server vulnerabilities >>> [MS] claim there are no >>> unfixed vulnerabilities to Terminal Server on Windows Server 2000 >>> Service Pack 4. >>> >>> I find that hard to believe and I know you guys will know if they are >>> full of it, or they are correct. Please let me know ASAP of any >>> CURRENT vulnerabilities int Terminal Server. >>Try here for starters: >>http://www.google.com/search?q=%22windows+terminal+server%22+exploit&s ourceid=mozilla&start=0&start=0&ie=utf-8&oe=utf-8 >>(2,310 results) Just as I figured. Based only on the first 25 or so, all of the real exploits discussed are patched and the vast majority of them apply to Windows NT 4.0 Terminal Server. The original poster asked about "CURRENT" vulnerabilities. The one remaining issue I remembered is on this page (http://www.saintcorporation.com/cgi-bin/demo_tut.pl?tutorial_name=Micro soft_Terminal_Server.html&fact_color=doc&tag=), which is also a good collection of vulnerabilities in general. It is a man-in-the-middle attack that could allow an attacker, using a collection of techniques including IP spoofing, to recover the original plaintext session. RDP, the Terminal Server protocol, is encrypted by default. The worst thing you have to do to work around this is to use a VPN, but considering what they would recover is RDP data (mouse moves, key clicks, GDI elements, etc.) I consider this a relatively high-overhead attack. Your Windows Terminal Server is much more likely to be vulnernerable to a problem in Windows than one specifically in Terminal Server, which has a very good security history. Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. ___ 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] Is there a 0day vuln in this phisher's site?
>>Yep, this is a straight copy of my example posted here: >>http://www.doxdesk.com/personal/posts/bugtraq/20030713-ie >>I have seen a few other phish in the wild using this exploit too. So have I. Not to diminish the importance of the attack, but this assumes the default placement of Address Bar if I'm not mistaken, so if the user changes their toolbar layout the popup will give itself away, correct? Larry Seltzer eWEEK.com Security Center Editor http://security.eweek.com/ http://blog.ziffdavis.com/seltzer [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
