IE7 to hit the streets -- Reloaded
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
SANS Network Security 2006 -- Vegas
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)!"
Microsoft patch tuesday - October 2006 STATUS
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 appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
- 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.
--
John Bambenek , bambenek/at/gmail/dot/com
with the help of: Johannes Ullrich, Joel Esler, Pedro Bueno, Kyle Haugsness
Spam Backscatter
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 blocklisted.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
Comments