Windows 0 day exploit?

News of a 0 day exploit against Windows Remote Desktop this morning has been light on details. A remote DOS is possible and has been discussed on the daily dave mailing list. Remote Desktop is not enabled by default on Windows XP SP2 systems however the terminal services service is running in support of Remote Assistance and Fast user switching. The server does not start a listener on port 3389 until a remote assistance request is sent. However if you enable Remote Desktop your system may be vulnerable.

I doubt that this is the last we are going to here of this.

Update:

There is no known *PUBLIC* exploit code in the wild for this vulnerability. The author could release POC code but has chosen not to do so at this time.

Yet another trojan

A reader sent us a packet (wahoo!) this morning containing some data from a nefarious web server. It contained some not nice vbscript which dropped a trojan on the host as C:\windows\winini32.exe. the malicous vbscript file is called hta.txt. I am not sure what mechanism is used to distribute the link to the vbscript yet but hope to find out soon. In the meantime IDS triggers for showHelp() might lead to this activity on your network.

.US DNS resolution response:

Here is the response from "NeuStar Registry Services" regarding inquiries into reported DNS resolution problems of the .us domain last week:

Here is a summary of what we were able to determine of last weeks .US
resolution incident that affected a handful of providers:

===========

- All .US (and .BIZ) sites were up and resolving queries for both BIZ
and US throughout the incident.

- Most service providers were not experiencing any difficulties. In
order to understand the incident, we are closely examining the
circumstances surrounding those providers that had difficulties.

-We did not observe any evidence of security breaches or hack/attack
attempts.

-Prior to finding a permanent fix, we cleared the problem for some
customers by instructing them to restart their upstream DNS service.

-The problem was fixed by performing a non-service-interrupting
software re-initialization of a network element at the San Jose.

-While we are monitoring this site at heightened levels, we do not
anticipate a recurrence of the issue.

-We had performed minor network maintenance in San Jose on Wednesday,
prior to, but not immediately before, the first customer call on
Wednesday night.

-We strongly suspect that the maintenance was a trigger event for the
incident and this is the primary focus area of our investigation.

-We are currently working closely with the vendor of the previously
mentioned network element to determine what led to this issue, and also
to determine why queries that hit this particular network element did
not round-robin to other DNS servers.

-There was no single point of failure in either the .BIZ or .US DNS.

How to identify when your DNS is not poisoned

One reader wrote in concerned that when he/she went to www.google.com their browser took them to www.sogo.com instead. They were rightly concerned that DNS was under attack. In this case though it was the browser trying to be helpful. For what ever reason at the moment www.google.com was not reachable so the client tried to go to www.google.com.net which take you to sogo.com. Thanks for trying to be a smarter browser.

Another update

I have been corresponding all day with a fellow who sees regular traffic at his home Internet (cable or DSL) on port 7393. A quick glance at http://isc.sans.org/port_details.php?port=7393 shows that there is some consistent traffic on this port. I have no clue what this port is for. I am guessing that it may be related to some p2p app. Google reveals nothing. The chap I am talking to can not get packet captures for me so I am at a loss. Any one have any clues on TCP port 7393? Please let us know if you do. Thanks