Update to "DNSChanger - Cleaning Up 4 Million Infected Hosts"

The Fbi's "Operation Ghost Click" announcement in Nov 2011, involving the Rove Digital botnet delayed cleanup efforts that we previously discussed, continues to haunt both the internet networks and the mass media. A Forbes article and a Times article yesterday brought the apparition back to the front, with some claiming that the site offered by the DNSChanger Working Group is a new one, which it is not. The 2011 Operation being described, and the temporarily outsourced DNS server replacements and delayed cleanup, is the same. This phantom is nothing supernatural, so why all the discussion? The federal judge's extension allowing the Fbi to run these replacement DNS servers still cuts off access in early July. When those replacement servers are removed in early July, the infected systems resolving DNS queries at these previously-owned Rove Digital servers will simply not be able to resolve DNS requests. July 9th will arrive soon, and notifications continue to go out related to the hundreds of thousands of systems in the US alone that are still infected.

In the simplest terms, connectivity will not be severed for DNSChanger-infected systems, but internet communications will not function for infected systems that have not been cleaned up. In the US, government agencies, home users, and other organizations still infected with the malware will have systems that effectively can't get online, can't send email, etc. It will look like they are connected to their network, but they just won't communicate with anything.

At the same time, there seems to be issues with some existing identification efforts. Yesterday, I infected a system with DNSChanger and visited dns-ok.us. Results here:

Regarding the dns-ok site visit, my ISP's support team isn't aware of any "DNS redirections" that would cause the test to fail, and I will update this post with any update from our network admin that they are redirecting my system's dns queries. But that piece is highly doubtful. My point here is that infected system owners may be confused by this check. And the ip address was within the Fbi-provided ranges run by Rove Digital - perhaps a reader knows differently?
UPDATE (1:40 p.m. MST) - I received some details from my local ISP network admin. They are not redirecting any related DNS queries. However, one of their large upstream providers is redirecting DNS requests to another DNS server of their own. The other upstream link to the net does not seem to be re-routing DNS requests. So my infected client's traffic must be favoring routes through the larger upstream provider, and poof, the green/clean response banner appears. Any way you look at it, the response from the site can be inconsistent - sometimes red, sometimes green. Unfortunately, this sort of situation is going to confuse cleanup efforts. So, here we are again. To the potentially millions of folks running DNSChanger infected systems and are listening to the cacophony of incident responder consultants tossing out cheap cynicism that "AV is dead!", go ahead and download an "AV product" to scan your system. Of course, I like recommending our scanners (just visit http://www.kaspersky.com) because I have cleaned up DNSChanger infected systems with it (and the products have fully functional trial periods), along with our TDSSKiller rootkit removal tool to clean up especially complex DNSChanger infections.

Addressing the Issue Around the Windows Remote Desktop Protocol Server Flaw (MS012-020)

We’ve gotten a number of questions from customers who are concerned about the Remote Desktop Protocol (RDP) vulnerability addressed by Microsoft on Tuesday with their security bulletin MS012-020. We wanted to take a moment to update you on this.

This bulletin addresses a critical, remote execution vulnerability affecting Microsoft Windows systems that have RDP enabled. While this is not enabled by default on Windows systems, RDP provides remote access functionality that many environments utilize, thus potentially putting them at risk. This vulnerability is highly critical because it can be exploited even by unauthenticated users. Another fact that’s special about this vulnerability is that it affects all versions of Windows. Hence, it’s important to take mitigating steps.

Trend Micro customers who run Deep Security or the Intrusion Defense Firewall (IDF) who have applied the latest updates have protections against attempts to exploit this vulnerability; specifically Deep Security update DSRU12-006 with the rule name 1004949 – Remote Desktop Protocol Vulnerability (CVE-2012-0002) and IDF update 12007) . These updates were released on Tuesday March 13 and Wednesday March 14 , respectively. As a member of the Microsoft Active Protections Program (MAPP), Trend Micro received information from Microsoft as part of their regular security update release process to provide these protections to Trend Micro customers.

As part of their regular security update process, Trend Micro customers should regularly update these products to get the latest protections against exploits for these vulnerabilities.

In accordance with Microsoft’s guidance, Trend Micro customers are encouraged to test and deploy the Microsoft security updates as soon as possible. More detailed information about the vulnerabilities addressed in this security update is available from Microsoft at their Security Research and Defense blog.

Update as of March 16, 2012, 11:58 p.m. (PST)

We wanted to update to make customers aware of reports that there is now Proof-of-Concept code available for MS012-020. Once again we urge customers to test and deploy this update as soon as possible.

We also wanted customers to know that Trend Micro Threat Management Services helps provide protections against attempts to exploit this vulnerability using following TDA patterns:

• Network Content Inspection Pattern (NCIP) 1.11595
• Network Content Correlation Pattern (NCCP) 1.11579

Finally, as an additional protection, customers may want to evaluate blocking access RDP (TCP port 3389) or watching for traffic scans and abnormalities on that port.

Update to this Month's Patch Tuesday Post on MS12-020/CVE-2012-0002

The twitter infosec sphere last night and the blogosphere this morning is in a bit of a frenzy about the public leak of a DoS PoC targeting CVE-2012-0002, the RDP pre-auth remote. This vulnerability was highlighted at our previous Securelist post on this month's patch Tuesday "Patch Tuesday March 2012 - Remote Desktop Pre-Auth Ring0 Use-After-Free RCE!". First off, patch now. Now. If you can't, use the mitigation tool that Microsoft is offering - the tradeoff between requiring network authentication and the fairly high risk of RCE in the next couple of weeks is worth it. You can see the list of related links on the side of this page, one was included for MS12-020.

Some interesting additional information has surfaced about the vulnerability, including the fact that the bug was generated in May of 2011 and "reported to Microsoft by ZDI/TippingPoint in August 2011". The researcher, Luigi Ariemma, discusses that this work wasn't disclosed by him (often, he fully discloses his work). After some careful investigation of the poorly coded "rdpclient.exe" posted online in Chinese forums, he found that it was a cheap replica of the unique code he provided to ZDI and in turn, Microsoft, when privately reporting the bug. This is bad. And already, researchers with connections to Metasploit open source exploit dev like Joshua Drake are tightening up the code, developing and sharing improved PoC. As Microsoft pointed out, confidence in the development of a reliable public exploit within 30 days is very high.

Regardless, the implications of a leak in the highly valuable MAPP program could hinder strong and important security efforts that have been built on years of large financial investment, integrity, and maturing operational and development processes. Thoughts and opinions on the leak itself can be found over at Zero Day. At the same time, I think that this event may turn out to be nothing more than a ding in the MAPP program's reputation, but it's important that this one is identified and handled properly. With the expansion of the program, an event like this one is something that certainly should have been planned for.

RDP+RCE=Bad News (MS12-020)

The March Security Bulletin release from Microsoft was relatively light in volume. Out of the six bulletins released, only one was rated as Critical.

And for good reason. MS12-020 includes CVE-2012-0002. This flaw is specific to the Remote Desktop Protocol (RDP) present on most current versions of Microsoft Windows. The RDP service, by default, listens on TCP port 3389. And because it’s so darn convenient, lots of people like to open their firewalls/ingress points to the traffic.

This is a bad/dangerous/insecure thing. (Choose your own favorite term.) I hope this issue (and many others before it) will influence anyone’s decision-making process when it comes to network hardening, external access, etc.

This is certainly not the first flaw in RDP. It is quite significant in that it does not require authentication to exploit the flaw–just a firing of some specially crafted packets. From that point the world (or the world that the compromised host lives in) is the attacker’s oyster. This is especially bad because the RDP service runs in kernel mode, under the System account (in most cases).

Keep in mind that it is very easy and takes little time to find targets. You see this type of situation all too often:

It's Open!

This situation very quick leads to an intruder’s trying to login via brute force, or trying something new (like the flaw described in MS12-020) !

It Actually Works!!!!!

So, what can you do to protect your environment?

McAfee, Microsoft, and others firmly recommend that you prioritize the deployment of the MS12-020 update.

Other steps:

• RDP is typically disabled by default. If there is any doubt, investigate and confirm in your environment whether and where it running.
• In Windows Vista or later, enable Network Level Authentication (NLM)
• Even if you have NLM enabled, the flaw can be exploited if the attacker can gain authentication. This means you should verify strong (nondefault, sufficiently complex) user/password combinations.

Resources

• CVE-2012-0002: A closer look at MS12-020′s critical issue
• Microsoft Security Bulletin MS12-020
• McAfee Vulnerability Manager

McAfee Coverage Data

Coverage exists in:

• McAfee Vulnerability Manager (FSL release): 3/13/2012
• McAfee Network Security Platform (Sig release): 3/13/2012
• McAfee Remediation Manager (V-Flash): 3/13/2012

CVSS: (AV:N/AC:M/Au:N/C:C/I:C/A:C)(E:POC/RL:OF/RC:C)

Why We Rated the MS12-020 Issue with RDP "Patch Now"

Microsoft's March 2012 "Black Tuesday" announcementincluded the MS12-020 patch, which fixes a vulnerability in Microsoft's implementation of RDP. This vulnerability (CVE-2012-0002) could allow a remote unauthenticated attacker to execute arbitrary code on the affected system. Microsoft labeled this issue "Critical" and we assigned itour highest severity label "Patch Now" for servers. Here's why:

• The CVE-2012-0002 vulnerability applies to most flavors of Microsoft Windows.
• It can be exploited over the network.
• Companies often make RDP accessible on the standard TCP port 3389 from the Internet for remote access to servers and sometimes workstations.

These factors make it very attractive for attackers to attempt reverse-engineering Microsoft's MS12-020 patch to, understand the details of the bug and craft an exploit. This will likely happen sooner than 30 days. The universal applicability of the exploit and its targetability over the Internet and internal networks might motivate the creation auto-propagating worms to capture systems quickly and efficiently.

For these reasons, we recommend applying the MS12-020 patch as quickly as practical in your environment. Until you install the patch, consider moving your RDP listeners to non-standard ports. You should also explore the applicability of Microsoft's advice to enable Remote Desktop’s Network Level Authentication (NLA). This will mitigate the problem: "On systems with NLA enabled, the vulnerable code is still present and could potentially be exploited for code execution. However, NLA would require an attacker to first authenticate to the server before attempting to exploit the vulnerability."

Patch Tuesday March 2012 - Remote Desktop Pre-Auth Ring0 Use-After-Free RCE!

Patch Tuesday March 2012 fixes a set of vulnerabilities in Microsoft technologies. Interesting fixes rolled out will patch a particularly problematic pre-authentication ring0 use-after-free in Remote Desktop and a DoS flaw, a DoS flaw in Microsoft DNS Server, and several less critical local EoP vulnerabilities.

It seems to me that every time a small and medium sized organization runs a network, the employees or members expect remote access. In turn, this Remote Desktop service is frequently exposed to public networks with lazy, no-VPN or restricted communications at these sized organizations. RDP best practices should be followed requiring strong authentication credentials and compartmentalized, restricted network access.

Some enterprises and other large organizations continue to maintain a "walled castle" and leave RDP accessible for support. The problem is that RDP-enabled mobile laptops and devices will make their way to coffee shops or other public wifi networks, where a user may configure a weak connection policy, exposing the laptop to attack risk. Once infected, they bring back the laptop within the walled castle and infect large volumes of other connected systems from within. To help enterprises that may have patch rollout delays, Microsoft is providing a fix-it that adds network layer authentication to the connection, protecting against exploit of the vulnerability.

This past fall, we observed the RDP worm Morto attacking publicly exposed Remote Desktop services across businesses of all sizes with brute force password guessing. It was spreading mainly because of extremely weak and poor password selection for administrative accounts! The Morto worm incident brought attention to poorly secured RDP services. Accordingly, this Remote Desktop vulnerability must be patched immediately. The fact that it's a ring0 use-after-free may complicate the matter, but Microsoft's team is rating its severity a "1" - most likely these characteristics will not delay the development of malicious code for this one. Do not delay patch rollout for CVE-2012-0002.

Also, Microsoft's DNS servers maintain DoS vulnerabilities. With hacktivist activity hugely increasing over the past year, enterprises and providers running this software should quickly move to patch their DNS servers. Indications of attack include your standard UDP request flood.