Threat Level: green Handler on Duty: Rob VandenBrink

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

IE7 to hit the streets -- Reloaded

Published: 2006-10-10
Last Updated: 2006-10-10 23:49:45 UTC
by Joel Esler (Version: 10)
0 comment(s)
I have pulled the article in it's original form because of feedback.

Thanks to one of our readers that wrote in to tell us that IE7,  will be released this month via Automatic Update according to Microsoft's "IEBlog".  Take a risk assessment of your organization to decide if you should globally deploy the browser, taking into account the pros and the cons of the software.

If you can take this moment to try and move your organization to a different browsing platform for normal daily browsing, that may be something you want to look into.  We've said it before, and we'll say it again, diversity is good. 

Reader Dan writes in to tell us:
"You may also want to note that Firefox even has a plug-in available to open certain links in IE. This makes it even easier to follow your advice of only using IE when you absolutely must." -- https://addons.mozilla.org/firefox/35/

Reader "Vision Jinx" writes in to tell us:
"I notice that IE View just opens the page in IE as a POP up type feature. IE Tabs (https://addons.mozilla.org/firefox/1419/) actually will load a FF Tab that uses IE therefore no need for all them extra Windows, as it just uses a tab in Firefox."

Joel Esler
Keywords:
0 comment(s)

SANS Network Security 2006 -- Vegas

Published: 2006-10-09
Last Updated: 2006-10-09 16:55:43 UTC
by Joel Esler (Version: 2)
0 comment(s)
Well, having freshly returned from SANS NS 2006 in Las Vegas, NV.  I thought I would add a few thoughts.

First off, Vegas is a great city, it appeals to some, and others hate it.  I personally, love Las Vegas.  It's fun, my wife quotes it to be an adult Disneyland.  I think that's an appropriate description.

I did several things while there.  First off, on Sunday night, we had our Incident Handlers dinner.  Mike Poor, Lorna Hutcheson, Marc Sachs, Johannes Ullrich, Brian Granier, Ed Skoudis, me, and a couple others were there (If I forgot exactly who was sitting around the table, don't beat me fellow handlers!  Please remind me).  We had a good time sitting around swapping stories about Microsoft.

We each had our own respective classes to teach last week.  (Some are still out there teaching!), I taught the Snort: Building and Operating and Snort Rules classes, and in the meantime ran over and hung out/spoke in Mike Poor's Intrusion Detection in-Depth Class.

I attended a couple talks while I was there, notably Marty Roesch's (Creator of Snort, and founder of Sourcefire) "Snort: Past, Present, and Future" talk on Thursday night, and his "One Click Compliance" talk on Friday at lunch.  I didn't get a chance to attend Brian's Spam/Anti-Spam talk, nor did I get a chance to see Lorna's Malware talk.  Both of which I wanted to attend but had conflicting events.  I did attend a roundtable discussion Sunday night with Marc Sachs, Johannes Ullrich, Ed Skoudis, Stephen Northcutt, and Eric Cole on "Future threats".  It was an excellent discussion.

All in all, I met a lot of the readers, I hung out with a lot of the handlers, and was able to spend a lot of time with all my friends.

Maybe today will be a slow day for the Internet, and you, the reader, can write in and share your experience with us at Vegas.  Please use our contact link above, by clicking on the Handler of the Day's name.  Also -- my fellow handlers -- feel free to edit this article and add your own thoughts and experiences!

Reader entry:
"the conference I went to last week was NS2006 (Ed Skoudis' hacker/incident class and it was great)!"
Keywords:
0 comment(s)

Microsoft patch tuesday - October 2006 STATUS

Published: 2006-10-10
Last Updated: 2006-10-12 13:02:19 UTC
by John Bambenek (Version: 2)
0 comment(s)

Overview of the October 2006 Microsoft patches and their status.


IMPORTANT NOTE: There will be no more support for Windows XP Service Pack 1, after this month no patches will be released in support of that version.

Additional note: The reason for distinguishing between private and public disclosure is that potentially the "bad guys" have had more time to work on the vulnerabilities when the disclosure was public. In theory, and I realize that this is potential, private disclosure means the clock starts now for the "bad guys" to develop exploits. It has some impact on the severity of the problem in my opinion.

# Affected Known Problems Known Exploits Microsoft rating ISC rating(*)
clients servers
MS06-056 ASP.NET cross-site scripting

CVE-2006-3436
Information Disclosure

KB 922770
No known exploits, privately reported to MS
Moderate Less Urgent
Important
MS06-057 WebFolderView ActiveX (setSlice)

CVE-2006-3730
Remote code execution

KB 923191
Exploits available, publicly reported
Critical PATCH NOW
Important
MS06-058 4 remote code execution problems in PowerPoint

CVE-2006-3435
CVE-2006-3876
CVE-2006-3877
CVE-2006-4694
Replaces MS06-028

KB 924163
Actively being exploited, privately reported to MS
Critical Critical Less Urgent
MS06-059 4 remote code execution problems in Excel

CVE-2006-2387
CVE-2006-3431
CVE-2006-3867
CVE-2006-3875
Replaces MS06-037

KB 924164
Proof of concept available, no exploits yet, publicly disclosed
Important Important Less Urgent
MS06-060 4 remote code execution problems in Word

CVE-2006-3651
CVE-2006-3647
CVE-2006-4534
CVE-2006-4693
Replaces MS06-027

KB 924554
Proof of concept available, no exploits yet, publicly disclosed Important Important Less Urgent
MS06-061 Remote code execution in XSLT (MSXML)

CVE-2006-4685
CVE-2006-4686
Replaces MS02-008

KB 924191
No known exploits, privately reported to MS
Critical Critical Less Urgent
MS06-062 3 remote code execution problems in Office & Publisher

CVE-2006-3434
CVE-2006-3650
CVE-2006-3864
CVE-2006-3868
Replaces MS06-048

KB 922581
No known exploits, privately reported to MS
Important (new versions) / Critical (old versions)
Important Less Urgent
MS06-063 Buffer overflow / Denial of service in Server Service

CVE-2006-4696
CVE-2006-3942
Replaces MS06-035

KB 923414
Proof of concept available, no exploits yet, publicly disclosed
Important Important
Important
MS06-064 Denial of service attacks in IPv6

CVE-2004-0230
CVE-2004-0790
CVE-2005-0688
Denial of Service in IPv6

KB 922819
Proof of concept available, no exploits yet, publicly disclosed
Low Less Urgent **
Less Urgent **
MS06-065 Remote code execution in Object Packager

CVE-2006-4692
Remote code execution

KB 924496
No known exploits, privately reported to MS
Moderate Important Less Urgent

We will update issues on this page as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY

(*): ISC rating
  • We use 4 levels:
    • PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
    • Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
    • Important: Things where more testing and other measures can help.
    • Less urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
  • The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leaisure work.
  • The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-caserole.
  • Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
  • All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them.
(**): If you are running an IPv6 network, this probably is more important to you.

--
John Bambenek , bambenek/at/gmail/dot/com
with the help of: Johannes Ullrich, Joel Esler, Pedro Bueno, Kyle Haugsness

0 comment(s)

Spam Backscatter

Published: 2006-10-09
Last Updated: 2006-10-09 01:28:14 UTC
by Swa Frantzen (Version: 2)
0 comment(s)

Over the weekend I dealt with the rather massive after effects of a spam campaign spoofing a domainname in the From: address.

In a few minutes about 10,000 messages arrived on a "catch-all" email address. Those messages consisted of:

  • Non-Delivery Reports (NDR)
  • Delivery Status Notifications (DSN)
  • Out of Office messages
  • Automated responses indicating the target does not work anymore where (s)he was working
  • Questions to confirm the message is genuine
  • Automated reports informing it was considered spam
  • Automated reports informing it contained a virus
  • Automated reports informing it contained bad links
  • ...

These messages come in at an incredible rate. When they contain the original headers you can see they are spammed from all over the address space (so it's likely to be a botnet sending it out). The error messages are in at least half a dozen languages, some of which I don't speak at all.

The spams were spoofed to come from random names at a domain and all those responses from the victims only create more victims. Actually that victim is hit much harder than any of the other victims.

So in order to keep the Internet a place where we all can survive it is critical:

  • Your email servers know which messages can be accepted or not and refuse the message if it needs to bounce before letting the sender move on and eventually resulting in a NDR or DSN to be sent to another victim.
    • You do this by NOT having fallback MX records where these messages are dumped and then generate all the bounces. The fallback MX mechanism is only useful if you have a very unreliable link and actually use something like ETRN to fetch your email. But if you can surf the Internet reliably, the MTAs will work perfectly without a fallback MX. And should your server be down: the orginating MTA will store it till the next queue run. You won't loose any email due to not having a fallback MTA on today's Internet.
    • You do this by scanning for active mailboxes before accepting the email.
    • You do this by scanning for unwanted content before accepting the email.
  • Kill all vacation, out of office messages, does not work here anymore, .... automated replies: it's a risk as such of leaking information. And if you are on the receiving end of a few thousand of them while you didn't send those people anything, it's a real pain.
  • Stop trying to limit incoming spam by demanding an acknowledgement of the apparent sender: this is really the cheap egoistic solution. It is protecting yourself a bit while putting the burden on the rest of us, even those of us who don't even want to have anything to do with you in the first place.
  • Automated scanning; if you do need to send somebody something that a unwanted message got filtered: send it to the recipient. If (s)he wanted the message, it can be gotten out of quarantine, but don't bother others with it, you're sending it toward the wrong people. And those that did send it to you: they know they are sending you unwanted stuff. It's their business model.

How do you survive this onslaught? You stop accepting the catch-all email. You refuse all those incoming messages and/or -for those addresses you need to accept email- you start to drop all of those unwanted messages in a filter. Dropping MX records only works if you have no A record, but it might be an option. And no: you don't reply to any of them, there have been enough victims.

Next comes that you might not be able to send much email anymore as there will be enough people who are misguided in assuming you or your domain in fact did send that message (the header forgery was not that bad, so some might even believe you relayed the messages).

If you do think you absolutely need fallback MX records, need DSN, ... well I'm sure you might sing a slightly different tune when are the victim of 10K messages in the first few minutes, and still going strong after many hours.

Personally I feel it's long overdue to really start implementing a usable alternative to the current email system. One of the requirements would be sender authentication and inability to create just a new identity after you got blacklisted.

UPDATE: Vance stated: "A very valuable purpose for fallback records is to establish a point of attraction for SPAM and malicious message transmissions (a honeypot of sort)." While that is true if you're dealing with spam, it's not so true for the victims of the backscatter it creates in most real cases. That backscatter is many times worse than normal spam as the victim gets all (read many thousands) answers vs. the normal spam victims just getting a couple each. To solve it: make sure the fallback MX is refusing messages destined to nonexistant mailboxes, messages that it will consider spam etc. before accepting the email (and causing a bounce later)

--
Swa Frantzen -- Section 66
Keywords: spam
0 comment(s)
Diary Archives