Re: [Full-Disclosure] My response to both the analysis of CIPE by Gutmann, Slashdot and the response by the CIPE list
On Thu, Sep 25, 2003 at 12:08:57PM +0200, Michal Zalewski wrote: On Thu, 25 Sep 2003, Florian Weimer wrote: Especially as some of the flaws (the replay attacks) are actually documented in the manual. And correct me if I am wrong, but it appears to me that replay attacks are not that much of a concern when encrypting TCP/IP packets? The manual mentions replay attacks on CIPE management traffic, but I'm not familiar enough with this aspect of the protocol to judge the impact. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] BugTraq Speed
Hi. Raj Mathur wrote: Uh, has anyone bothered asking DMA the reason for the delay? You may not get any reasonable explanation, but at least give the man a chance to defend himself before condemning him. From my point of view this was no attempt to condemn anyone, but was meant as getting a feeling for the situation (am I the only one who feels like this? if so, there is no need to take further steps). As it seems that there are lots of people sharing the same experience, one of them should volunteer and ask the BugTraq guys about the reasons, giving them the chance to defend themselves as you suggested. Bye, Mike PS: Just to mention that: I won't volunteer, due to two reasons: 1. Bad english 2. I'll marry this weekend and therefor will be off for some days ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] BugTraq Speed
Kristian Hermansen wrote: Dido.. Everytime I send a post I get about 20 bounce backs. 20? How? At least twice that much... even more if there is vacancy time in many countries.. summer and the like. They did kick a lot of those out of office-subscribers a few weeks ago, but it did help only for a few days. Gosh, I hate those freaks.. who cares about them being not in the office? Grr... Bye, Mike ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] The U.S. State Department needs DCOMbobulator
On Wed, Sep 24, 2003 at 12:48:01PM -0400, [EMAIL PROTECTED] wrote: On Wed, 24 Sep 2003 11:12:12 EDT, Richard M. Smith [EMAIL PROTECTED] said: For most Windows users, I bet that the only time DCOM ever gets used, if at all, is to run worms like MSBlaster and Welchia. Isn't DCOM needed for the WindowsUpdate stuff to work? Or am I misremembering? Not that I know of. -Guido ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SAM Switch - Win2k/XP password-less login
On Thu, Sep 25, 2003 at 11:34:40AM -0500, Schmehl, Paul L wrote: backdoor passwords in case of emergency, and all BIOSes can be easily reset to default passwordless configuration. Without knowing the password you couldn't put the password back correctly so it would be obvious that the BIOS had been reset. Doesn't fix the problem by any means but does perhaps leave a track. If your server reboots for no reason really you should have already noticed that and wondered what was up. -Steve ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] FreeBSD Security Advisory FreeBSD-SA-03:14.arp [REVISED]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 = FreeBSD-SA-03:14.arpSecurity Advisory The FreeBSD Project Topic: denial of service due to ARP resource starvation Category: core Module: sys Announced: 2003-09-25 Credits:Apple Product Security [EMAIL PROTECTED] Affects:All releases of FreeBSD FreeBSD 4-STABLE prior to the correction date Corrected: 2003-09-24 21:48:00 UTC (RELENG_4, 4.9-PRERELEASE) 2003-09-25 13:33:01 UTC (RELENG_5_1, 5.1-RELEASE-p8) 2003-09-25 13:33:29 UTC (RELENG_5_0, 5.0-RELEASE-p16) 2003-09-25 13:34:14 UTC (RELENG_4_8, 4.8-RELEASE-p10) 2003-09-25 13:34:31 UTC (RELENG_4_7, 4.7-RELEASE-p20) 2003-09-25 13:34:52 UTC (RELENG_4_6, 4.6-RELEASE-p23) 2003-09-25 13:35:18 UTC (RELENG_4_5, 4.5-RELEASE-p34) 2003-09-25 13:35:33 UTC (RELENG_4_4, 4.4-RELEASE-p44) 2003-09-25 13:35:48 UTC (RELENG_4_3, 4.3-RELEASE-p40) FreeBSD only: NO For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit URL:http://www.freebsd.org/security/. 0. Revision History v1.0 2003-09-23 Initial release. v1.1 2003-09-25 Initial patch was incorrect. I. Background The Address Resolution Protocol (ARP) is fundamental to the operation of IP with a variety of network technologies, such as Ethernet and WLAN. It is used to map IP addresses to MAC addresses, which enables hosts on a local network segment to communicate with each other directly. These mappings are stored in the system's ARP cache. FreeBSD's ARP cache is implemented within the kernel routing table as a set of routes for the address family in use that have the LLINFO flag set. This is most commonly often AF_INET (for IPv4). Normally, when a FreeBSD system receives an ARP request for a network address configured on one of its interfaces from a system on a local network, it adds a reciprocal ARP entry to the cache for the system from where the request originated. Expiry timers are used to purge unused entries from the ARP cache. A reference count is maintained for each ARP entry. If the reciprocal ARP entry is not in use by an upper layer protocol, the reference count will be zero. II. Problem Description Under certain circumstances, it is possible for an attacker to flood a FreeBSD system with spoofed ARP requests, causing resource starvation which eventually results in a system panic. (The critical condition is that a route exists for the apparent source of the ARP request. This is always the case if the system has a default route configured for that protocol family.) If a large number of ARP requests with different network protocol addresses are sent in a small space of time, resource starvation can result, as the arplookup() function does not delete unnecessary ARP entries cached as the result of responding to an ARP request. NOTE WELL: Other BSD-derived systems may also be affected, as the affected code dates well back to the CSRG branches. III. Impact An attacker on the local network may be able to cause the system to hang or crash. The attacker must have physical access to the shared network medium. In the case of a wireless network obtaining this access may be trivial. Networks where proxy ARP is used to direct traffic between LANs may be particularly vulnerable to the attack, as the spoofed ARP requests could be bounced through to the target via routers implementing proxy ARP. Because the attack operates at Layer 2, the use of strong encryption technologies such as IPsec cannot protect a system against the attack. IV. Workaround There is no known workaround at this time. V. Solution Do one of the following: 1) Upgrade your vulnerable system to 4-STABLE; or to the RELENG_5_1, RELENG_5_0, RELENG_4_8, or RELENG_4_7 security branch dated after the correction date. 2) To patch your present system: The following patch has been verified to apply to FreeBSD 5-CURRENT, 4.9-PRERELEASE, and 4.8 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:14/arp.patch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-03:14/arp.patch.asc b) Execute the following commands as root: # cd /usr/src # patch /path/to/patch c) Rebuild your kernel as described in URL:http://www.freebsd.org/handbook/kernelconfig.html and reboot the system. VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path -
[Full-Disclosure] DANGER: potentially broken f-prot updates
I have already contacted the vendor, but be careful about your f-prot updates today. It looks like they put an old def file from May 26th on their ftp site. The UNIX update script will happily fetch and install this. avscan2# nslookup -type=ns f-prot.com Server: resolver1.sentex.ca Address: 64.7.128.99 Non-authoritative answer: f-prot.com nameserver = ns1.linanet.is f-prot.com nameserver = skjalda.frisk-software.com f-prot.com nameserver = bukolla.frisk-software.com f-prot.com nameserver = baula.frisk-software.com Authoritative answers can be found from: ns1.linanet.is internet address = 62.145.128.2 skjalda.frisk-software.com internet address = 213.220.100.2 bukolla.frisk-software.com internet address = 213.220.100.1 baula.frisk-software.cominternet address = 213.220.100.3 avscan2# avscan2# host ftp.f-prot.com 213.220.100.2 Using domain server 213.220.100.2: ftp.f-prot.com has address 204.118.23.102 ftp.f-prot.com has address 204.118.23.103 ftp.f-prot.com has address 204.118.23.101 avscan2# fetch ftp://204.118.23.102/pub/fp-def.zip Receiving fp-def.zip (1180204 bytes): 100% 1180204 bytes transferred in 1.2 seconds (997.57 kBps) avscan2# unzip -v fp-def.zip Archive: fp-def.zip Length MethodSize Ratio Date Time CRC-32Name -- --- - -- 295 Defl:N 272 8% 09-25-03 16:57 e98c5705 SIGN.ASC 1054178 Defl:N 675410 36% 05-26-03 16:01 415522b4 SIGN.DEF 295 Defl:N 272 8% 09-25-03 16:57 c21dad71 SIGN2.ASC 733487 Defl:N 503856 31% 05-26-03 13:20 9664dc36 SIGN2.DEF --- ------ 1788255 1179810 34%4 files avscan2# md5 fp-def.zip MD5 (fp-def.zip) = ffbe865dbfbf6721f59abdad3309c8ad avscan2# It really is from the 26th.. no mimail, no swen, noteven sobig.f :-( ---Mike ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] BugTraq Speed
Dave Ahmad picked up on my post and responded privately. He doesn't have any objections to my forwarding his messages to FD, hence forwarding without prejudice. -- Raju -- Raj Mathur[EMAIL PROTECTED] http://kandalaya.org/ GPG: 78D4 FC67 367F 40E2 0DD5 0FEF C968 D0EF CC68 D17F All your domain are belong to us. It is the mind that moves [Message from Dave Ahmad] Return-Path: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From: Dave Ahmad [EMAIL PROTECTED] To: Raj Mathur [EMAIL PROTECTED] Subject: Re: [Full-Disclosure] BugTraq Speed Date: Thu, 25 Sep 2003 10:19:31 -0600 (MDT) Raj, I appreciate you being the voice of reason. I can offer you a simple explanation, off-list. Bugtraq is a moderated list, Full-Disclosure is not. Of course Full-Disclosure is going to be faster. It takes me some time read through all of the submissions to Bugtraq and decide which ones are to be on the list. Unfortunately, Bugtraq is not my only responsibility here. I have to balance trying to moderate as quickly as possible with managing my team and maintaining/supporting some of the products here which depend on the vulnerability database. Despite all of this, I believe, Bugtraq is consistently faster than the other moderated lists. There's no conspiracy to withhold messages while our customers get priority. That is absurd, all one has to do is monitor the list during regular business hours. For example, the FreeBSD advisory mentioned by Rainer: I approved it as soon as I was at my desk, before 9AM here. It hit my mail spool about 30 minutes later (50,000 users on the list means 50,000 SMTP transactions -- there's some latency in delivery, though we try to improve performance by using QMQP with concurrent outgoing servers). During the day I approve messages as they arrive. Once in a while messages slip. It happens. I have hundreds of messages in the queue. Sometimes a single message is surrounded by OOTO replies, A/V bounces, spam, virus/worm mails, etc, and I don't see it until I review the queue when I have time. Follow-up messages sometimes take a little longer because there are so many of them, many of which say the same things. To keep the noise down, I read over them all and select the best messages for approval. It takes me hours of my time both at work and outside of the office. I'm not asking that anyone take my word for it. The Bugtraq delivery times are available to anyone on the list. With all of the speculation I'm surprised nobody has actually put in the effort to try and prove we are withholding information. I assure that any such investigation would show that the pattern of message approval is not consistent with us withholding the precious zero-day of the community. There's not really any commercial advantage anyways, since there are so many lists now and much of what goes to Bugtraq is sent everywhere else as well. Most importantly, it's simply not ethical and I would have no part in doing that. But again, don't take my word for it. Thanks again. [Personal stuff snipped -- Raju] David Mirza Ahmad Symantec PGP: 0x26005712 8D 9A B1 33 82 3D B3 D0 40 EB AB F0 1E 67 C6 1A 26 00 57 12 -- The battle for the past is for the future. We must be the winners of the memory war. Uh, has anyone bothered asking DMA the reason for the delay? You may not get any reasonable explanation, but at least give the man a chance to defend himself before condemning him. - -- Raju - -- Raj Mathur[EMAIL PROTECTED] http://kandalaya.org/ GPG: 78D4 FC67 367F 40E2 0DD5 0FEF C968 D0EF CC68 D17F All your domain are belong to us. It is the mind that moves ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SAM Switch - Win2k/XP password-less login
I found that SAM file could be replaced just like PWL files in Win9x. I posted the following to Bugtraq, but in spite of posting twice it never appeared in the list... (possibly moderated) Folks, go ahead and change the boot options in your BIOS ASAP. I guess this fallacy will never go away. Changing the boot options in your BIOS will actually exactly nothing. Anyone with a modicum of computer knowledge and physical access to your box can change them back at will. Trusting the BIOS to protect you against attack is foolhardy. Its password protection is worthless. Many BIOSes have backdoor passwords in case of emergency, and all BIOSes can be easily reset to default passwordless configuration. We've always known that once an attacker has physical access to a machine it's vulnerable to a host of low-tech attacks... That doesn't mean that we collectively throw our hands up in the air and leave the root password on a note next to the keyboard. In reality, all our efforts to prevent local attacks are little more than an inconvenience, placed into effect in order to repel casual snoops and the least persistent attackers. Don't want users to have admin-level privs? Develop an appropriate security policy and implement it. Don't want them to circumvent your policy? Implement safeguards. Don't want them to side-step your safeguards? Well, how many levels deep are you prepared to go? In all but the most security-conscious orgs I think the consensus is that if the attacker is prepared to crack open a case, they're going to get root. I know that my network's security just isn't worth epoxying cases shut. :) Cheers, Cael ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] RE: Probable new MS DCOM RPC worm for Windows
The increase in volume appears to coincide with flashky's (xfocus.org) 9/20 post The Analysis of RPC Long Filename Heap Overflow AND a Way to Write Universal Heap Overflow of Windows. Coincidence? -Original Message- From: Williams Jon [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 9:01 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Probable new MS DCOM RPC worm for Windows Since I've been watching for a new worm that uses the MS03-039 vulnerability, when I saw this message, I went over to incidents.org to check out and see if they were seeing an increase, too. Lo and behold, their charts for both TCP 135 and TCP 80 show dramatic increases in traffic over the past few days. Port 135 is up from 377,000 targets on 9/20 to 1,900,000 targets on 9/23, and 80 is up from 880,000 records on 9/20 to 3,527,000 on 9/23. Despite this, I'm not seeing anything else on the lists about a new worm. Is anyone seeing anything new out there, or is this just a resurgence of Welchia? -Original Message- From: Richard Johnson [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 24, 2003 10:03 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Probable new MS DCOM RPC worm for Windows On Sat, 20 Sep 2003 14:41:39 -0600, Richard Johnson [EMAIL PROTECTED] wrote: We've noticed increased scan activity on port 135, ramping up over the past 20 hours. The scanning appears to concentrate on nearby /16s... We finally had infections occur on Tuesday evening showing the same scan behavior. Sysadmins doing cleanup report Norton and McAfee IDed the bug as W32.Welchia. I don't know whether it was a variant using one of the two new RPC holes, or just month-old Welchia. That's because the hosts hit were traditional non-compliant lab machines and non-adminned remote office or home hosts. In other words, they were still vulnerable to the original blaster worm. The US Dept. of State's CLASS was hit by this one, and it looks like they shut down for a short while to contain it: http://www.azcentral.com/news/articles/0924ComputerVirus24-ON.html Richard -- To reply via email, make sure you don't enter the whirlpool on river left. My mailbox. My property. My personal space. My rules. Deal with it. http://www.river.com/users/share/cluetrain/ --- --- = / Brian Porter / PGP Public Key: / 0xE172E7B0 ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] RE: Probable new MS DCOM RPC worm for Windows
I'm thinking that there *has* to be a variant of Nachi/Welchia in the wild. We have machines that were patched for MS03-026 (verified by scanning with multiple scanners) but not patched for MS03-039 (ditto) and they have been infected by something that triggers my Nachi rule in snort. This should *not* be possible with the original Nachi/Welchia, so my assumption is that either something new has been released or the worm has mutated somehow. Mind you, this is anecdotal and a very small incidence (only three machines so far), but it still bears watching IMHO. I've been surprised to not see any discussion on the lists about a new variant. Perhaps no one is looking? Paul Schmehl ([EMAIL PROTECTED]) We've seen the same thing over here. I've had a handful of machines (perhaps 15-20 out of 2500) here that were reported to be patched against MS03-026 yet became infected with Welchia. These machines were not patched against MS03-039. One possibility is that the systems were already infected with Welchia at the time they were patched against MS03-026. I know of at least one or two cases here where the technical support person assigned to fix a particular system didn't appropriately follow the removal procedures and left a patched, but infected, system. I have to assume this is happening without notice in other cases, since there haven't been reports of a variant, and the number of systems in this situation is rather low. So I'm betting user error, though I find it hard to believe there isn't another variant making the rounds. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] email worms, spam etc etc
Thanks ^^ Would you know any good DBSBLs? I've been looking for some good ones... But since Osiru died... I can't find a good one *cry* Also, would it be too much for the mod of this list to just cause new subscribers to be moderated until their first VALID post? Just an idea =/ - Original Message - From: Michael Evanchik [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 25, 2003 09:01 Subject: [Full-Disclosure] email worms, spam etc etc If you were as annoyed as i was with your mailboxes being bombarded I looked up native email filtering for microsoft environments. Attatched is a basic script to get u started. This works on the Microsoft SMTP service on NT4,2000, and 2003 Michael Evanchik www.high-pow-er.com ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Swen Really Sucks
On Thursday 25 September 2003 12:27 pm, Schmehl, Paul L wrote: The From or Return-Path address specified by the MAIL FROM: transaction in the SMTP session is the real email address of the infected user, or at least is what they entered on the fake MAPI dialog that Swen uses to get that information. Please tell me you don't believe this is true. If you know anything about SMTP you know that the MAIL FROM: can be anything you want it to be. And Swen certainly forges the sender, as the hundreds of bounces I get will testify. There is *nothing* in an SMTP transaction that you can rely on except the headers *if* you know how to read headers. If you don't, even those will fool you. I am speaking from direct knowledge gained by reverse-engineering Swen. It is true that anyone can forge SMTP headers, but Swen does not forge the address in the MAIL FROM: transaction. It sends the email address provided to it by the infected user. The bounces you are getting may be actual first-generation Swen messages, as a phony bounce message is one of the many formats it generates. -Joe -- Joe Stewart, GCIH Senior Security Researcher LURHQ Corporation http://www.lurhq.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] BugTraq Speed
On Thu, 25 Sep 2003, Gerhard den Hollander wrote: They are running mailman ... mailman can be horrendously slow (esp with a large volume (traffic * number_of_subscribers) . 3 hour delays with mailman mailinglists is pretty common. Who they? Hi! This is the ezmlm program. I'm managing the [EMAIL PROTECTED] mailing list. and: X-BeenThere: [EMAIL PROTECTED] X-Mailman-Version: 2.0.12 ? -- Dariusz Sznajder DSZ1-RIPE ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Swen, Virii, Spam etc etc
If you were as annoyed as i was with your mailboxes being bombarded I looked up native email filtering for microsoft environments. The link is a basic script to get u started. This works on the Microsoft SMTP service on NT4,2000, and 2003 http://software.high-pow-er.com/EvenSink.zip Michael Evanchik www.high-pow-er.com
Re: [Full-Disclosure] DANGER: potentially broken f-prot updates
f-prot fixed it as of 20:00 GMT and confirmed to me via email that the root of the problem was found and corrected! ---Mike At 03:03 PM 25/09/2003, Mike Tancsa wrote: I have already contacted the vendor, but be careful about your f-prot updates today. It looks like they put an old def file from May 26th on their ftp site. The UNIX update script will happily fetch and install this. avscan2# nslookup -type=ns f-prot.com Server: resolver1.sentex.ca Address: 64.7.128.99 Non-authoritative answer: f-prot.com nameserver = ns1.linanet.is f-prot.com nameserver = skjalda.frisk-software.com f-prot.com nameserver = bukolla.frisk-software.com f-prot.com nameserver = baula.frisk-software.com Authoritative answers can be found from: ns1.linanet.is internet address = 62.145.128.2 skjalda.frisk-software.com internet address = 213.220.100.2 bukolla.frisk-software.com internet address = 213.220.100.1 baula.frisk-software.cominternet address = 213.220.100.3 avscan2# avscan2# host ftp.f-prot.com 213.220.100.2 Using domain server 213.220.100.2: ftp.f-prot.com has address 204.118.23.102 ftp.f-prot.com has address 204.118.23.103 ftp.f-prot.com has address 204.118.23.101 avscan2# fetch ftp://204.118.23.102/pub/fp-def.zip Receiving fp-def.zip (1180204 bytes): 100% 1180204 bytes transferred in 1.2 seconds (997.57 kBps) avscan2# unzip -v fp-def.zip Archive: fp-def.zip Length MethodSize Ratio Date Time CRC-32Name -- --- - -- 295 Defl:N 272 8% 09-25-03 16:57 e98c5705 SIGN.ASC 1054178 Defl:N 675410 36% 05-26-03 16:01 415522b4 SIGN.DEF 295 Defl:N 272 8% 09-25-03 16:57 c21dad71 SIGN2.ASC 733487 Defl:N 503856 31% 05-26-03 13:20 9664dc36 SIGN2.DEF --- ------ 1788255 1179810 34%4 files avscan2# md5 fp-def.zip MD5 (fp-def.zip) = ffbe865dbfbf6721f59abdad3309c8ad avscan2# It really is from the 26th.. no mimail, no swen, noteven sobig.f :-( ---Mike ___ 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] BugTraq Speed
My advice to anyone who gets bounce backs from posting to bugtraq is to save and forward all bounces to the admin contact for the list. I usually get a thank you, they'll be promptly unsubscribed in response. Darren ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Analysis of a Spam Trojan
On Thu, 25 Sep 2003 12:04:14 -0500, Brian Eckman wrote: It is unknown how the audio.exe file got onto the computer hard drive in the first place. It is almost guaranteed to have been via the MS03-032 IE object tag vulnerability. The trojan you found is a variant of the Autoproxy trojan, which has been known to use that infection vector on a large scale. Some AV companies detect it as Coreflood because it shares a lot of the same code, likely because it is by the same author. You are correct in your analysis that it is not a DDoS bot, but instead is a spam tool. Here is an analysis I did on a recent variant that uses a different master server and contacts cnet.com instead of microsoft.com: http://www.lurhq.com/autoproxy.html Here is another Snort signature you can use to detect when an infected user attempts to contact its controlling server: alert tcp $HOME_NET any - $EXTERNAL_NET 80 (msg:Autoproxy Trojan control connection; content: |0d 0a 55 73 65 72 2d 41 67 65 6e 74 3a 20 41 75 74 6f 70 72 6f 78 79 2f|; classtype:trojan-activity; sid:128; rev:1;) It is interesting to note the connection between the DDoS trojan and the spam-proxy trojan here, in light of the recent DDoS attacks on spam blackhole lists. -Joe -- Joe Stewart, GCIH Senior Security Researcher LURHQ Corporation http://www.lurhq.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Port 6881 scans - why?
Am getting a Distributed (several diverse net blocks) and fair quantity (100 packets per min. per IP) of port 6881 hits... Any idea what this is (other than possibly BT - Snark - per google)... No I have not run / analysis with a sniffer... Currently hitting the FW... Paul ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Swen Really Sucks
Schmehl, Paul L [EMAIL PROTECTED] to Joe Stewart: The From or Return-Path address specified by the MAIL FROM: transaction in the SMTP session is the real email address of the infected user, or at least is what they entered on the fake MAPI dialog that Swen uses to get that information. Please tell me you don't believe this is true. ... I doubt Joe would have written it did he not believe it. And, FWIW, I believe it too. ... If you know anything about SMTP you know that the MAIL FROM: can be anything you want it to be. ... Yes, but we are specifically talking here about what _Swen_ wants it to be... ... And Swen certainly forges the sender, as the hundreds of bounces I get will testify. There is *nothing* in an SMTP transaction that you can rely on except the headers *if* you know how to read headers. If you don't, even those will fool you. Swen has code to locate the Default Mail Account under the Internet Account Manager registry key then to extract the SMTP Email Address value appropriately. This is then stored in a variable in the virus that is later used for the argument to the MAIL FROM: SMTP command while sending Email. (It is possible that some other part of the Swen code I have not closely analysed surreptitiously changes the contents of this variable in some circumstances, but there is no obvious code that also alters the contents of the buffer used to hold the string pulled from the registry location just described...) This is all based on disassembly and is corroborated by reports from other researchers who have watched it under debuggers, emulation, etc. -- 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] Port 6881 scans - why?
Paul Johnson wrote: Am getting a Distributed (several diverse net blocks) and fair quantity (100 packets per min. per IP) of port 6881 hits... Any idea what this is (other than possibly BT - Snark - per google)... No I have not run / analysis with a sniffer... Currently hitting the FW... TCP, I assume? It probably IS BitTorrent. If any of the users behind your firewall are trying to use BitTorrent, then that would cause outside people to try to hit port 6881 on your outside interface. Check for DST TCP 6881-6889 going from the inside to the outside, that would be your BT user, if that's what it is. BB ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] What about astalavista.net
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Purdy Sent: Friday, 26 September 2003 2:57 a.m. To: 'Jordan Wiens'; 'GARCIA Lionel' Cc: 'Full-Disclosure (E-mail)' Subject: Re: [Full-Disclosure] What about astalavista.net They are two virtual servers on the same box. Curt Purdy CISSP, GSEC, MCSE+I, CNE, CCDA Information Security Engineer DP Solutions I don't think so: [~]$ host astalavista.box.sk astalavista.box.sk has address 66.250.54.213 astalavista.box.sk has address 66.250.56.83 astalavista.box.sk has address 66.250.56.88 astalavista.box.sk has address 66.250.56.89 astalavista.box.sk has address 66.250.56.94 astalavista.box.sk has address 66.250.54.210 astalavista.box.sk has address 66.250.54.211 astalavista.box.sk has address 66.250.54.212 [~]$ host astalavista.net astalavista.net has address 195.65.88.146 First one is hosted under Cogent Communications and the second at Swisscom IP-Plus. Do a whois and traceroute them and you'll see. Bojan ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] An open question for Snort and Project Honeynet
-BEGIN PGP SIGNED MESSAGE- From: Schmehl, Paul L (pauls_at_utdallas.edu) Date: Sep 25 2003 One more in the idiot bin The fact that the best you can do is call me an idiot for having the temerity to raise deadly serious issues says a lot more about you than it does me. It might be okay to toss off a dismissive one-liner to some zittey teenager, but if you can't tell the difference based on what I've written, God help you. Of course, since it's likely you've never done any research into the detectability of these tools yourself, I see no particular reason you should find yourself qualified to respond one way or the other. Your two cents from the peanut gallery might actually mean something if it were coming from a real researcher-- sadly, not the case at all. Just get back to your administrative drudgework or whatever it is you do to kill time in Texas and stay out of it if you have nothing constructive to contribute. Anyway, I'm not pretending to be some kind of Snort expert, so if in my ignorance I failed to see that off-by-one's, integer overflows, and logic bugs is some kind of a bluff, I'm perfectly willing to own up to it. However, I certainly reserve the right to ask, especially in light of the snake-oil carnival huckster Everybody relax-it-doesn't-matter-that-we-got-owned nature of Snort's spin-doctoring response. It forces me to call into question both the honesty and the competence of the entire organization. I was already far from being impressed by the technical capablities of one of their team members I met at a conference who struck me as being far outclassed in terms of skills by the people challenging him. Which wouldn't be any big news, except that Snort really is about the best we've got. And that's sad. My lack of Snort expertise notwithstanding, I am intimately familiar with deception as applied to CND. It makes me literally sick to my stomach to hear some of you (you know who you are) cackling among your friends about how much money you were able to pry out of the government for research products which are nothing but an overhyped fraud. You've all heard it. You know when you've done it. Either you know perfectly well when, where and how your honeypot tools can be detected and are defrauding your sponsors, or you can't tell and are stupid. I suppose I've been giving you the benefit of the doubt by assuming the former. And if you know and you can't fix it, for God's sake lay off of your Mickey Mouse con job already, it's embarrassing. To the guilty: the next time I see you at a conference, I'll smile, shake your hand and make polite chit chat, like I always have. All the while wishing I could spit in your face. Like I always have. And the sheer beauty of it is you'll never know the difference. Here's to honesty, Matsu. -BEGIN PGP SIGNATURE- Version: MailVault 2.2 from Laissez Faire City http://www.mailvault.com iQA/AwUAP3NND2M5xTGTuR0REQLywwCfa1nb54htRXoHzgVI/f6UuXuO794AnjIN 5JAPiuScXcWs8WIJiN88rilX =1+Nr -END PGP SIGNATURE-
Re: [Full-Disclosure] email worms, spam etc etc
Would you know any good DBSBLs? Be _very_ careful with some of these. I know one imparticular, Osirus Relays (relays.osirusoft.com) makes it just about impossible to get off their list once you're on meaning you risk blackholing legitimate traffic. To get off this list, they require you email their scripts from the server that is blackholed...and their mail server naturally rejects the message since you're on their list which needless to say, is [CENSORED] [CENSORED] [CENSORED] stupid or [CENSORED] [CENSORED] [CENSORED] intentional. A good alternative might be content filtering (which will also fliter based on the IP information captured from the Received headers). The DSPAM project has been very successful at filtering spams, falsified emails, and worm emails (such as SoBig.F). The URL is http://www.nuclearelephant.com/projects/dspam/ ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Swen Really Sucks
-Original Message- From: Nick FitzGerald [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 5:05 PM To: [EMAIL PROTECTED] Subject: RE: [Full-Disclosure] Swen Really Sucks Swen has code to locate the Default Mail Account under the Internet Account Manager registry key then to extract the SMTP Email Address value appropriately. This is then stored in a variable in the virus that is later used for the argument to the MAIL FROM: SMTP command while sending Email. (It is possible that some other part of the Swen code I have not closely analysed surreptitiously changes the contents of this variable in some circumstances, but there is no obvious code that also alters the contents of the buffer used to hold the string pulled from the registry location just described...) This is all based on disassembly and is corroborated by reports from other researchers who have watched it under debuggers, emulation, etc. If it's as poorly written as most malware is, it most likely screws this up as well. All I can tell you is that I get tens of bounces on my personal home email account daily, and I can assure you that I am not infected. I'll take a look tonight (because I'm sure there will be at least 50 or 60 virus mails and bounces in my deleted items folder) and see what's in the headers. You can disassemble and run simulations til you're blue in the face, but things don't work perfectly in the real world, as I *know* you know. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/~pauls/ ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] RE: Probable new MS DCOM RPC worm for Windows
We have seen a number of infections of Nachi/Welchia on patched systems. Was told that the MS03-026 patch was only 60% effective, so you still had a 1 in 3 chance of being infected. Apparently the MS03-039 patch fixes the entire vulnerability and not just some of it. We re-enforced the rule for keeping the anti-virus current, which stopped Nachi/Welchia worm (in most cases, not all). Steve Carey -Original Message- From: Derek Vadala [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 2:44 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Probable new MS DCOM RPC worm for Windows I'm thinking that there *has* to be a variant of Nachi/Welchia in the wild. We have machines that were patched for MS03-026 (verified by scanning with multiple scanners) but not patched for MS03-039 (ditto) and they have been infected by something that triggers my Nachi rule in snort. This should *not* be possible with the original Nachi/Welchia, so my assumption is that either something new has been released or the worm has mutated somehow. Mind you, this is anecdotal and a very small incidence (only three machines so far), but it still bears watching IMHO. I've been surprised to not see any discussion on the lists about a new variant. Perhaps no one is looking? Paul Schmehl ([EMAIL PROTECTED]) We've seen the same thing over here. I've had a handful of machines (perhaps 15-20 out of 2500) here that were reported to be patched against MS03-026 yet became infected with Welchia. These machines were not patched against MS03-039. One possibility is that the systems were already infected with Welchia at the time they were patched against MS03-026. I know of at least one or two cases here where the technical support person assigned to fix a particular system didn't appropriately follow the removal procedures and left a patched, but infected, system. I have to assume this is happening without notice in other cases, since there haven't been reports of a variant, and the number of systems in this situation is rather low. So I'm betting user error, though I find it hard to believe there isn't another variant making the rounds. --- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Verisign Login Hijacking
Sure enough, this works under most of the browsers I've tried, and at least shows the pittfalls of not cutting your session cookies short, or at least periodically killing, at least, login cookies. Damn, even Microsoft does a better job of it. Dotster and others don't seem to have this problem with session expiration. There are obviously better ways to keep session state between machines, even under SSL. A former employer had me manage that through a Cisco/Arrowpoint CS series content switch, and it worked like a charm, and we didn't expose login sessions, plus the perl proxy code handled authorization and other session keys on the backend through a database.. simple enough idea. I wonder if this poor programming extends itself to their server for signing up and managing digital certificates... Well, if anybody gets a hold of a good spoofed URL, I'm sure we'll see the UN, CNN, NyTimes, or other sites bumped off the map (not just web traffic but entire domains) by unauthorised redirections. I'm sure with enough effort, you can pick the salt up for the session keys and start generating your own logins. I'm not notifying Verisign, I think it's up to them to come to us. Just my personal opinion... Really, didn't these guys take a class in programming for the web, even a distributed systems class would have tought them to bump down and ticketed session down to 5-10 minutes at most. Wouldn't you hash the session with an originating IP or something to make sure the session can be verified and not hijacked? Most folks would rather close the browser window than logout, thus keeping the server session active. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] Re: AIM Password theft
windows 2000 professional all patches kaboom: not only was wmplayer overwritten..with text.. but IE 6 DIED .. then launched a command window command prompt labelled 'C:\PROGRA~1\WINDOW~1\wmplayer.exe' followed quickly by ... --dialog box-- 16-bit MS-DOS Subsystem C:\PROGRA~1\WINDOW~1\wmplayer.exe the NTVDM CPU has encountered an illegal instruction. CS:0544 IP:01CC OP:63 68 65 2F 31 Choose 'Close' to terminate the application. [close] [ignore] yikes [EMAIL PROTECTED] wrote: !-- Out of curiosity I followed that link which loaded start.html (attached). -- Caution: off-site archives will and have already stored this as: text/plain attachment: start.txt Tested on neohapsis [http://archives.neohapsis.com/archives/bugtraq/2003-09/0375.html] Due to the 'never-addressed-mime-issue' of Internet Explorer reading even dog poo as html, opening start.txt will effect the exploit partialy. Namely: C:\Program Files\Windows Media Player\wmplayer.exe will be overwritten by simply viewing the attached text file. It is apparent the original intended payload .exe is no longer at the location, but the wmplayer.exe is still overwritten with a 1KB wmplayer.exe containing the following: !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN HTMLHEAD TITLE404 Not Found/TITLE /HEADBODY H1Not Found/H1 The requested URL /eg/1.exe was not found on this server.P HR ADDRESSApache/1.3.26 Server at onway.net Port 80/ADDRESS /BODY/HTML ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Verisign Login Hijacking
Don't worry, nobody's going to have that referer, except for the partners Verisign sells advertising to. ;) ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Swen Really Sucks
Schmehl, Paul L [EMAIL PROTECTED] replied to me: Swen has code to locate the Default Mail Account under the Internet Account Manager registry key then to extract the SMTP Email Address value appropriately. This is then stored in a variable in the virus that is later used for the argument to the MAIL FROM: SMTP command while sending Email. (It is possible that some other part of the Swen code I have not closely analysed surreptitiously changes the contents of this variable in some circumstances, but there is no obvious code that also alters the contents of the buffer used to hold the string pulled from the registry location just described...) This is all based on disassembly and is corroborated by reports from other researchers who have watched it under debuggers, emulation, etc. If it's as poorly written as most malware is, it most likely screws this up as well. ... 8-) You should be careful -- I get hate mail for saying stuff like that... ... All I can tell you is that I get tens of bounces on my personal home email account daily, and I can assure you that I am not infected. I'll take a look tonight (because I'm sure there will be at least 50 or 60 virus mails and bounces in my deleted items folder) and see what's in the headers. Ah -- I didn't understand what you were saying before. I am getting such bogus bounces too (about one for every ten natural samples I receive), but recall that many stupid Email gateway scanners will send bounces to addresses in the From: and/or Sender: headers (and even to addresses in Reply-To:, X-Originally-From: and other weird custom headers -- clearly these products are written by chimpanzees that cannot read RFCs...). You can disassemble and run simulations til you're blue in the face, but things don't work perfectly in the real world, as I *know* you know. Indeed I can, but when I do -- like Joe -- I tend to take quite some professional pride in the work (unlike the folk who wrote the SMTP processors that are busy sending you those bounces). -- 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] An open question for Snort and Project Honeynet
To the skilled but flawed fake at http://www.phrack.nl/phrack62/ and your mail Mr. Rueubens. Do any of you have anything to say about that? When you say look for yourself surely you don't mean to claim that Average Joe Admin has the requisite skillset and detailed knowledge necessary to spot something potentially that subtle? This introduction of deliberate weaknesses is quite easy to find when you have different releases of code to compare against. There is even a windows tool called windiff that I believe is available on any windows platform for free back to Win95 that makes it A+ friendly. And would anyone care to address the off-by-one's, integer overflows, and logic bugs m1lt0n alluded to in his or her article about Snort? It goes a little something like this Download two different versions, verify the signatures, and open them up. Point windiff at them and start reading. Any time you see a strcpy where there once was a strncpy there might be a suspect bit of code. But you should know this and the rest of the methodologies. ( unless you are just a drone in PR who gets paid to spread FUD of course ) How do you intend to counter the effects of Sneeze? /* we can't hope to generate these sorts of packets, so just skip them automatically */ I went and read a little of the snort manual on rules [0] Just as you and the author could have. How is it the author cannot hope to produce a web request with the uricontent as specified? whisker is just a good a template for that as the first sneeze is for this bit of code. If you are going to steal why not steal a lot? How is it the author cannot adjust the TTL? After they did an nmap of the target I find it hard to believe that they are concerned about noise. Do they not know how to get the number of hops? The first sneeze available from the snort project on sourceforge apears more capable than this. I don't think that a response is needed from the snort people since it has been available since Mon Aug 06 2001 - 10:39:32 CDT [1] and not caused problems yet. /* we can only handle a small subset of datasize keywords... don't worry about ranges, only worry about the '' operator, which will usually only be used to detect overflow attempts */ Cannot handle smaller bits of data? /* Exceed '' directive by x bytes */ #define GT_INC 16 Inline? Any comments on the Sebek piece? Any project based upon a flawed premises will result in products no less flawed then the premise it was based upon. How about any statement of fact based on an assumption is but an assumption. However, If an adversary knows how they are being monitored, the adversary is able to develop methods to determine if they are benign monitored But they already know they are being monitored does anything else matter? A Honeypot is designed to find this kind of information and the people with both the skills and intentions to use them. Seems that project has paid off pretty well by disclosing more wonderfully useful bits of information on what the bad people might be up to and how. Assuming an adversary knows they are being monitored, then it must be assumed that a determined adversary will study the ways that the monitoring devices operate. The determined adversary is just the one these things are designed to discover. What makes you think that the discovery is not made when these methods are employed and a forensic analysis ultimately performed? Why would you think that you would know? and my favorite statement If the discovered flaws are of such a nature where the adversary can cause arbitrary code execution, either as a result of the device or one of its supporting code libraries, then the attacker may be able to compromise the supporting systems that monitor the honeypot, and any other honeypots which trust that supporting system. There are a more what if statements in there than I care to dissect. It is a honeypot. It is disposable by nature and properly implemented offers no more risk than anything else, arguably less risk overall. But really... lets ponder for a minute... The intent is to find the attacker that is skilled and capable of doing this. I think it is pretty successful at just that. Besides, I would rather an attacker spend the time figuring out how to circumvent this monitoring than penetrating real defenses. gid=0(apache) [2] - You learn something new every day! There is not enough space to continue with this. This thing is riddled with obvious forgery. Where is that full-exposure list? Can I suggest that you use your incredible powers of deductive reasoning there first? How confident are you in people who are doing your code review, anyway? I am incredibly confident in the people doing code review. You see it is available for all to review including you and me. Not only are skilled people that do code review for a living looking at the code but so are a lot of people that do it for a hobby. I think I can have confidence in the record
Re: [Full-Disclosure] An open question for Snort and Project Honeynet
At 04:18 PM 9/25/03 -0400, Matsu Kandagawa wrote: All the while wishing I could spit in your face. For the life of me, I cannot fathom why people devote so much time and mental effort to assassinating each others' character publicly in this forum. Let's just get this out of the way once and for all: Everyone who subscribes to this list--no that's not good enough; it doesn't include future and past subscribers-- everyone on the planet Earth who owns, accesses, or has even casual contact with a computing device is a clueless moron who has no chance of comprehending even the beverage menu at Denny's, much less the details of a buffer overflow. We should all just go back to making notches on sticks. Now, assuming there's no one out there whom I've failed to offend, may we please limit ourselves to discussions directly germane to information security? If you want to call each other names, there are plenty of outlets for that. Might I suggest Jerry Springer for starters? m5x ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] FullDisclosure: Re: CyberInsecurity: The cost of Monopoly
Nah... nothing happened, for example, to Foundstone after this scandal: http://www.fortune.com/fortune/technology/articles/0,15114,457276,00.htm Two - if Geer was fired as a result of the report (and only Chris or someone equally high up at @stake knows the truth - I invite them to comment), then this will be perceived as a VERY negative act that could conceivably have repercussions for M$ and @Stake (formerly the L0pht Heavy Industries guys). M$ I can understand; their business practices have been and continue to be reprehensible. But personally I do not want to see the L0pht/@Stake crowd cast in the role of villian. That would be a very sad day indeed... ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] myServer 0.4.3 Directory Traversal Vulnerability
myServer 0.4.3 Directory Traversal Vulnerability .oO Overview Oo. myServer version 0.4.3 shows files and directories that reside outside the normal web root directory. Discovered on 2003, August, 23th Vendor: Myserver (http://myserverweb.sourceforge.net/forum/portal.php) MyServer is a free, powerful web server program designed to be easily run on a personal computer by the average computer user. It is a multithread application and supports HTTP, CGI, ISAPI, WinCGI and FastCGI protocols. It is available on Windows and Linux Operating Systems. This web server can shows file and directory content that reside outside the normal web root directory. Original text is at http://www.securiteinfo.com/attaques/hacking/myServer0_4_3.shtml .oO Details Oo. The vulnerability can be done using any browser. You just have to send a specially crafted dot-dot URL to retreive any file outside of the root directory. .oO Exploit Oo. You have to create a dot-dot URL with the same number of /./ and /../ + 1. For example, you can use : /././.. /./././../.. /././././../../.. /./././././../../../.. etc... .oO Solution Oo. The vendor has been informed and has solved the problem. Download MyServer 0.5 at http://sourceforge.net/project/showfiles.php?group_id=63119 .oO Discovered by Oo. Arnaud Jacques aka scrap [EMAIL PROTECTED] http://www.securiteinfo.com ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
[Full-Disclosure] CyberInsecurity: The cost of Monopoly
This was released yesterday just incase nobody noticed. http://www.ccianet.org/papers/cyberinsecurity.pdf Among the authors are Bruce Schnier, Dan Geer, and Charles Pfleeger. Interesting read. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] CyberInsecurity: The cost of Monopoly
They are going to need to update Dan Geers title in the report... Microsoft critic loses job over report http://www.msnbc.com/news/971914.asp?0si=- Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Jonathan A. | Zdziarski | Sent: Thursday, September 25, 2003 5:26 PM | To: [EMAIL PROTECTED]; [EMAIL PROTECTED] | Subject: [Full-Disclosure] CyberInsecurity: The cost of Monopoly | | | This was released yesterday just incase nobody noticed. | http://www.ccianet.org/papers/cyberinsecurity.pdf | | Among the authors are Bruce Schnier, Dan Geer, and Charles Pfleeger. | Interesting read. | | | | ___ | 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] CyberInsecurity: The cost of Monopoly
Oddly his leaving the company was effective on the 23rd, but the article wasn't released to the general public until the 24th (at least that's how it's dated). I wonder if he may have resigned. On Thu, 2003-09-25 at 21:45, Richard M. Smith wrote: Yep, confirmed by Internet Explorer/Google: Daniel E. Geer, Jr., Sc.D. Chief Technology Officer. http://www.atstake.com/company_info/dgeer.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] CyberInsecurity: The cost of Monopoly
Yep, confirmed by Internet Explorer/Google: Daniel E. Geer, Jr., Sc.D. Chief Technology Officer. http://www.atstake.com/company_info/dgeer.html Object not found! The requested URL was not found on this server. The link on the referring page seems to be wrong or outdated. Please inform the author of that page about the error. If you think this is a server error, please contact the webmaster Error 404 www.atstake.com Fri Sep 26 02:19:32 2003 Here's the Google cache version of the original page: http://tinyurl.com/opkx Dan's photo seems to have disappeared, Soviet-style. Yikes, don't byte that hand that feed ya's.. Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marc Maiffret Sent: Thursday, September 25, 2003 8:53 PM To: Jonathan A. Zdziarski; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Full-Disclosure] CyberInsecurity: The cost of Monopoly They are going to need to update Dan Geers title in the report... Microsoft critic loses job over report http://www.msnbc.com/news/971914.asp?0si=- Signed, Marc Maiffret Chief Hacking Officer eEye Digital Security T.949.349.9062 F.949.349.9538 http://eEye.com/Retina - Network Security Scanner http://eEye.com/Iris - Network Traffic Analyzer http://eEye.com/SecureIIS - Stop known and unknown IIS vulnerabilities # # # # # # # # # ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] CyberInsecurity: The cost of Monopoly
At 10:08 PM 9/25/2003 -0400, Jonathan A. Zdziarski wrote: Oddly his leaving the company was effective on the 23rd, but the article wasn't released to the general public until the 24th (at least that's how it's dated). I wonder if he may have resigned. Nah - I hear @stake is trying to make the firing retroactiveone would assume to protect their themselves. -- B.K. DeLong [EMAIL PROTECTED] +1.617.797.2472 http://ocw.mit.edu Work. http://www.brain-stream.com Play. http://www.the-leaky-cauldron.orgPotter. http://www.city-of-doors.com Sigil PGP Fingerprint: 38D4 D4D4 5819 8667 DFD5 A62D AF61 15FF 297D 67FE ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
