MS12-020 RDP vulnerabilities: Patch, Mitigate, Detect

Published: 2012-03-16
Last Updated: 2012-03-17 23:46:10 UTC
by Russ McRee (Version: 1)
4 comment(s)

As a follow up to the fact the we've raised the INFOCON level to yellow for MS12-020, a step not taken lightly, it was suggested that we offer a few simple things folks can do to ensure that they're patched appropriately, as well as employ possible mitigations and detection.

Specifically, MS12-020 includes KB2671387 (Remote Code Execution - CVE-2012-0002) and KB2667402 (Denial of Service - CVE-2012-0152) or KB2621440
The reference for the update you'll see on a Windows system, when installed, depends on the version of the OS you're running. For Windows 7 you'll likely note KB2667402, whereas you should only expect KB2621440 on a Windows XP host.
Confusing, I know, but it matters. Read the full MS12-020 bulletin to confirm.
 
The simplest step to determine if you're properly updated, using Window 7 x64 as an example is: 
Start -> All Programs -> Windows Update -> View Update History and look for reference to KB2667402 as seen in Figure 1.
 
Update History
Figure 1 
 
If on a Windows XP host, using Microsoft Update, you can opt for Start -> Microsoft Update -> Review your update history and ensure KB2621440 is installed.
 
Additionally, at the command prompt, you can use Windows Management Instrumentation Command-line (WMIC) and issue:
wmic qfe | find "KB2667402" or wmic qfe | find "KB2621440"
If patched you'll note results as seen in Figure 2.
 
Figure 2
 
Mitigation
Per the bulletins, "systems that do not have RDP enabled are not at risk."
Your privileges on a given system (enterprise GPOs may prevent changes) may dictate your level of success.
Options include, aside from the obvious (PATCH):
1) Don't run RDP if you don't really need it.
Start -> Run -> services.msc -> Stop and/or disable Remote Desktop Services (Figure 3) or disable it via Control Panel
Figure 3
 
2) Use Windows Firewall (where applicable and if enabled) to prevent access to RDP (Figure 4)at the host level
Figure 4
 
3) Ensure your network security configurations don't unnecessarily allow RDP (TCP 3389) from the Internet. If you absolutely, positively must do so, restrict it to approved hosts.
 
4) Enable Network Level Authentication (NLA) on Vista and later systems. Per the SRD blog: "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."
  
Detection
Snort users can keep an eye on the likes of Emerging Threats. A rule (SID 2014384) has been included to identify a possible RDP DoS attack as described in KB2667402/CVE-2012-0152. I'm certain additional rules and detection logic are being added across the spectrum of detection options; check in with your vendor/provider accordingly.
 
Feel free to comment with methodology related to the above that works for you and thus may help others.
 
4 comment(s)

INFOCON Yellow - Microsoft RDP - MS12-020

Published: 2012-03-16
Last Updated: 2012-03-16 15:35:54 UTC
by Swa Frantzen (Version: 1)
6 comment(s)

As we feared the MS12-020 bulletin from last black Tuesday caused a race for finding an exploit.
The last few evolutions in that process cause our worries to increase significantly. In order to help raise awareness and call administrators to action, we're raising our INFOCON to YELLOW for 24 hours.

Some history:

  • Luigi Auriemma found a problem on May 16th, 2011.
  • Microsoft was warned on August 24th, 2011 working with TippingPoint's Zero Day Initiative
  • Microsoft released bulletin MS12-020 on March 13th, 2012, crediting "Luigi Auriemma, working with TippingPoint's Zero Day Initiative, for reporting an issue described in MS12-020"
  • Luigi Auriemma released his work on March 16th, 2012


Luigi wrote today: "now that my proof-of-concept is out (yeah rdpclient.exe is the poc written by Microsoft in November 2011 using the example packet I sent to ZDI) I have decided to release my original advisory and proof-of-concept packet written the 16 May 2011... full-disclosure as usual :)" and he released his analysis and exploit of the vulnerability.

This is expected to speed up the efforts of the bad guys significantly and gives those having exposed RDP services very little time to fix before it will get exploited somehow.

The clock is ticking, please consider:

  • block off RDP from all sources but those you absolutely need
  • install the Microsoft patch
     

--
Swa Frantzen -- Section 66

6 comment(s)

VMware New and Updated Security Advisories

Published: 2012-03-16
Last Updated: 2012-03-16 11:17:17 UTC
by Guy Bruneau (Version: 1)
0 comment(s)

VMware issued the following security advisories:

VMware View privilege escalation and cross-site scripting (VMSA-2012-0004) [1] and VMware vCenter Server, Orchestrator, Update Manager, vShield, vSphere Client, ESXi and ESX address several security issues (VMSA-2012-0005) [2].

[1] http://www.vmware.com/security/advisories/VMSA-2012-0004.html
[2] http://www.vmware.com/security/advisories/VMSA-2012-0005.html

The following advisory has been updated:

VMware ESXi and ESX updates to third party library and ESX Service Console address several security issues (VMSA-2012-0001.1) [3]

[3] http://www.vmware.com/security/advisories/VMSA-2012-0001.html

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

0 comment(s)
ISC StormCast for Friday, March 16th 2012 http://isc.sans.edu/podcastdetail.html?id=2401

Comments

What's this all about ..?
password reveal .
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
https://thehomestore.com.pk/
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> nearest public toilet to me</a>
<a hreaf="https://defineprogramming.com/the-public-bathroom-near-me-find-nearest-public-toilet/"> public bathroom near me</a>
https://defineprogramming.com/
https://defineprogramming.com/
Enter comment here... a fake TeamViewer page, and that page led to a different type of malware. This week's infection involved a downloaded JavaScript (.js) file that led to Microsoft Installer packages (.msi files) containing other script that used free or open source programs.
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
https://clickercounter.org/
Enter corthrthmment here...

Diary Archives