DNS Misbehaving
[see the update below - the problem is with Rogers Cable]
A reader reported some difficulties resolving www.zonelabs.com from Canada. We checked our circuits and two different sites (one in Belgium, one in the USA) showed this:
From Belgium:
$ dig www.zonelabs.com a
; <<>> DiG 9.2.2 <<>> www.zonelabs.com a
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49741
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;www.zonelabs.com. IN A
;; ANSWER SECTION:
www.zonelabs.com. 86400 IN A 209.87.209.44
;; AUTHORITY SECTION:
zonelabs.com. 86400 IN NS dns1.zonelabs.com.
zonelabs.com. 86400 IN NS dns2.zonelabs.com.
From the USA:
~> dig www.zonelabs.com
; <<>> DiG 9.2.3 <<>> www.zonelabs.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61680
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0
;; QUESTION SECTION:
;www.zonelabs.com. IN A
;; ANSWER SECTION:
www.zonelabs.com. 86245 IN A 209.87.209.44
;; AUTHORITY SECTION:
zonelabs.com. 86245 IN NS ns8.checkpoint.com.
zonelabs.com. 86245 IN NS dns1.zonelabs.com.
zonelabs.com. 86245 IN NS dns2.zonelabs.com.
zonelabs.com. 86245 IN NS ns6.checkpoint.com.
We asked our Canadian friend to run a dig query and here was his output:
dig www.zonelabs.com a
; <<>> DiG 9.3.1 <<>> www.zonelabs.com a
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46367
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;www.zonelabs.com. IN A
;; ANSWER SECTION:
www.zonelabs.com. 3600 IN A 127.0.0.1
;; AUTHORITY SECTION:
zonelabs.com. 86400 IN NS 127.0.0.1.
I removed the DNS server IP addresses for privacy purposes, but you can clearly see what the problem is. His ISP's DNS server returns an address of 127.0.0.1 as an answer. This could be a local cache problem with his ISP or an indicator of a much larger attack.
We need your help - run a dig query against your local DNS servers for www.zonelabs.com and let us know if you see 127.0.0.1 as the reply. No need to let us know if the queries come out OK, just if you see 127.0.0.1. Please use our contact page for submissions.
Thanks!
Marcus H. Sachs
Director, SANS Internet Storm Center
UPDATE
Numerous readers have written in to let us know that the problem appears to be solely with Rogers Cable DNS servers. There is no indication at this point that there is anything malicious afoot, although anytime a security software update site resolves incorrectly we need to dig into it.
There have been discussions in other forums about Rogers DNS problems, although we cannot determine if those are related to the zonelabs.com problem.
For the time being, Rogers customers may wish to change your DNS server settings to use one of the free public servers listed at http://www.opennic.unrated.net/public_servers.html or http://www.opendns.com/.
Thanks to everyone who responded!
g
A reader reported some difficulties resolving www.zonelabs.com from Canada. We checked our circuits and two different sites (one in Belgium, one in the USA) showed this:
From Belgium:
$ dig www.zonelabs.com a
; <<>> DiG 9.2.2 <<>> www.zonelabs.com a
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49741
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;www.zonelabs.com. IN A
;; ANSWER SECTION:
www.zonelabs.com. 86400 IN A 209.87.209.44
;; AUTHORITY SECTION:
zonelabs.com. 86400 IN NS dns1.zonelabs.com.
zonelabs.com. 86400 IN NS dns2.zonelabs.com.
From the USA:
~> dig www.zonelabs.com
; <<>> DiG 9.2.3 <<>> www.zonelabs.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61680
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0
;; QUESTION SECTION:
;www.zonelabs.com. IN A
;; ANSWER SECTION:
www.zonelabs.com. 86245 IN A 209.87.209.44
;; AUTHORITY SECTION:
zonelabs.com. 86245 IN NS ns8.checkpoint.com.
zonelabs.com. 86245 IN NS dns1.zonelabs.com.
zonelabs.com. 86245 IN NS dns2.zonelabs.com.
zonelabs.com. 86245 IN NS ns6.checkpoint.com.
We asked our Canadian friend to run a dig query and here was his output:
dig www.zonelabs.com a
; <<>> DiG 9.3.1 <<>> www.zonelabs.com a
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46367
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;www.zonelabs.com. IN A
;; ANSWER SECTION:
www.zonelabs.com. 3600 IN A 127.0.0.1
;; AUTHORITY SECTION:
zonelabs.com. 86400 IN NS 127.0.0.1.
I removed the DNS server IP addresses for privacy purposes, but you can clearly see what the problem is. His ISP's DNS server returns an address of 127.0.0.1 as an answer. This could be a local cache problem with his ISP or an indicator of a much larger attack.
We need your help - run a dig query against your local DNS servers for www.zonelabs.com and let us know if you see 127.0.0.1 as the reply. No need to let us know if the queries come out OK, just if you see 127.0.0.1. Please use our contact page for submissions.
Thanks!
Marcus H. Sachs
Director, SANS Internet Storm Center
UPDATE
Numerous readers have written in to let us know that the problem appears to be solely with Rogers Cable DNS servers. There is no indication at this point that there is anything malicious afoot, although anytime a security software update site resolves incorrectly we need to dig into it.
There have been discussions in other forums about Rogers DNS problems, although we cannot determine if those are related to the zonelabs.com problem.
For the time being, Rogers customers may wish to change your DNS server settings to use one of the free public servers listed at http://www.opennic.unrated.net/public_servers.html or http://www.opendns.com/.
Thanks to everyone who responded!
g
Keywords:
0 comment(s)
The missing Microsoft patches
Vulnerabilities that are widely known and/or actively exploited are of great interest to our readers, here we try to keep an overview of them
Affected | Known Exploits | Impact | Known since |
ISC rating(*) | |
---|---|---|---|---|---|
clients | servers | ||||
Microsoft DNS CVE-2007-1748 |
Exploit used in the wild Exploit code public |
Remote code execution with SYSTEM privileges |
April 4th, 2007 |
Less Urgent | Critical |
Microsoft DNS offers RPC for remote management that is vulnerable to a stack overflow. See SA935964 for more mitigating information, KB935964 and VU#555920 and MSRC blog. |
|||||
MSIE CVE-2007-1692 |
Exploit publicly discussed. | Malicious proxy insertion by insiders | Mar 25th, 2007 | Less Urgent | Less Urgent |
Some mitigating steps are in KB934864: Setup wpad TXT records in all DNS domains and have the "wpad" and "wpad." names reserved on all WINS servers |
|||||
Windows Vista - Windows Mail CVE-2007-1658 |
Exploit publicly available. | Execute programs through crafted URL | Mar 23th, 2007 | Less Urgent | Less Urgent |
IE 7 CVE-2007-1499 |
Exploit publicly available. | XSS against local resource |
Mar 14th, 2007 | Less Urgent | Less Urgent |
OLE object can crash windows explorer CVE-2007-1347 US-CERT VU#194944 |
Exploit publicly available. |
DoS (Memory corruption might lead to more) |
Mar 6th, 2007 |
Less Urgent |
Less Urgent |
IE7 browser entrapment using onUnload() CVE-2007-1091 |
PoC publicly discussed. |
onUnload() and transitions can be used to fake a user backing out of a bad website while still interacting with it |
Feb 23th, 2007 variation of onUnload() trouble from Aug 2005 |
Less Urgent |
Less Urgent |
IE7 browser involuntary file upload |
PoC publicly discussed. |
Focus can still be captured using javascript to capture keystrokes and use them to upload a file to a malicious website. |
Feb 12th, 2007 Variant of exploits dating back to Jun 2006. |
Important |
Less Urgent |
Word 2000/XP unspecified problems CVE-2007-0870 |
Used in targeted attacks. |
Remote code execution, (originally only DoS) |
Feb 9th, 2007 |
Critical |
Important |
Internet Explorer msxml3 concurrency problems CVE-2007-0099 |
Publicly posted exploit | DoS / code execution considered too difficult to control |
Jan 4th, 2007 |
Less Urgent |
Less Urgent |
Patch unlikely, expect a fix in a SP or next version | |||||
Workstation Service NetrWkstaUserEnum() memory allocation exhaustion in XP and 2000 CVE-2006-6723 |
Publicly posted exploit | DoS |
Dec 25th, 2006 |
Less Urgent |
Less Urgent |
Patch unlikely, expect a fix in a SP Likely related to CVE-2006-6296 and CVE-2006-3644 see below |
|||||
Microsoft Windows NAT Helper Components CVE-2006-5614 |
Publicly available exploit. |
DoS |
Oct 28th, 2006 |
Less Urgent |
Important |
Patch unlikely, expect a fix in a SP | |||||
PowerPoint 2003 CVE-2006-5296 |
MSRC blog #1 MSRC blog #2 Publicly available exploit. |
DoS |
Oct 20th, 2006 |
Less Urgent |
Less Urgent |
Patch unlikely, Microsoft doesn't consider it a security problem anymore | |||||
RPC memory allocation exhaustion in Windows 2000 SP4 via UPnP, SPOOLSS CVE-2006-6296 CVE-2006-3644 |
Multiple publicly available exploits. |
DoS |
Nov 16th, 2005 |
Less Urgent |
Important |
Patch unlikely, expect a fix in a SP (if any) |
(*): 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 leisure 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-case role.
- 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.
--
Swa Frantzen -- Section 66
Ghost of Christmas Botnets?
One of our handlers said that he saw a significant spike in botnet activity to known CCs yesterday. That would make sense, considering the millions of new computers that joined the Internet soup on Christmas day, right out of the box, and likely a few months behind on patches. However, when we looked at our favorite botnet tracking site, ShadowServer, we see that there was just the opposite - a bit DROP in botnets on Christmas Eve and very little rise on Christmas Day. Very odd.
So, what are your sensors seeing? A rise in botnet activity or a drop? Send us your observations via our contact page.
Marcus H. Sachs
Director, SANS Internet Storm Center
So, what are your sensors seeing? A rise in botnet activity or a drop? Send us your observations via our contact page.
Marcus H. Sachs
Director, SANS Internet Storm Center
Keywords:
0 comment(s)
Vista: better security [Y/N] ?
I went to a talk about Microsoft's Vista a little while ago and from what I remember of the presentation, some highlights of the security impact of Vista:
They also left out some easy to achieve things that would make the world a lot safer. E.g. IE7 doesn't make it any harder to see a https site with a bad ssl certificate. Just pressing next still accepts the bad cert and shuts up about it. This makes man in the middle attacks way too easy.
I'm worried about the confidence they have this will be enough to change the tide. And most of all, I'm worried about the added complexity, as complexity creates more (security) bugs in my experience.
So: make up your own mind and let us know in the poll.
--
Swa Frantzen -- Section 66
0 comment(s)
- Vista has what's called "defense in depth" by Microsoft. Most of us think of something with multiple devices creating layers, but Microsoft uses the term for a way they use inside a machine to give processes and resources a level of trust. Low level processes cannot access higher classified assets.
- IE has been given a low trust level. After asking questions it was still unclear if outlook would be low as well. It seemed the answer pointed to the attachments being low but outlook and the emails themselves not. But I might have misunderstood.
- User processes are at a medium trust level.
- Service processes are at a high level.
- System is still the highest trust level.
- Even when logged on with local admin rights, processes are not started by default with those rights. The demo was rather convincing with notepad refusing to save a file in c:\windows\ even though the user had admin rights. To start the application the local admin needs to right click and start notepad with additional rights.
- There is a "secure desktop" used for switching users, logging in and being prompted for allowing additional rights needed by processes. The normal desktop is grayed out during such prompts making them rather hard to ignore. Note: the default is not accept but cancel. This secure desktop should somehow (unspecified how) make it more secure to do these prompts.
- Signed application can voluntary say in their profile what they are expected to do and not to do. Vista will enforce that profile and terminate processes stepping outside of their profile. Eg.:
An MTA could have a profile that it's only going to listen to port tcp/25. Suppose the process gets exploited and starts to listen on another port to open up a backdoor: Vista could terminate the process right there.
Since the thing is voluntary I'm wondering where the incentive will be for developers to use the belt and suspenders approach. - Virtualization: Once you tried once to get your users to give up local admin rights, you know it's a pain. For the least bit they need help and additional permissions. And just about any application you need won't play nice without a 10 round fight. Vista addresses this by virtualizing the filesystem for older "legacy" applications. If the application wants to drop an .ini file in c:\windows\, it's not given an error, but the file is dropped in an user owned directory instead. Reading obviously matches this to cheat the misbehaving application into working without having write access to critical directories.
- The well publicized locking of kernel mode additions on 64bit kernels only (32bit would break drivers apparently, there are no to very few 64bit drivers that would break according to the presenter. Not in the presentation obviously, but there' the entire fight between Microsoft and the antivirus industry over this as well.
They also left out some easy to achieve things that would make the world a lot safer. E.g. IE7 doesn't make it any harder to see a https site with a bad ssl certificate. Just pressing next still accepts the bad cert and shuts up about it. This makes man in the middle attacks way too easy.
I'm worried about the confidence they have this will be enough to change the tide. And most of all, I'm worried about the added complexity, as complexity creates more (security) bugs in my experience.
So: make up your own mind and let us know in the poll.
--
Swa Frantzen -- Section 66
×
Diary Archives
Comments