#cloudworm CANDIDATE - MS12-020 PROOF OF CONCEPT (POC) #### # executive.summary This is a review of MS12-020 in the current cloud landscape. Which is more a review of the security in the current cloud landscape and the failings of Amazon Web Services and Rackspace. However, the same is probably applicable with many IaaS services. AWS and Rackspace are highlighted as they are major IaaS service providers. #### # overview.and.history In May 2011 Luigi Auriemma (@luigi_auriemma) discovered an exploit in the Microsoft RDP protocol. He submitted this to the Zero Day Initiative (@thezdi) and they reported it to Microsoft in August 2011. Thereafter, the shenanigans began and it was unsurprisely leaked. Luigi has written his point of view (worth a read), http://aluigi.org/adv/ms12-020_leak.txt This bugslap comic sums it up with some humor: http://bugslap.com/comics/0x00000007.png And, so it was that MS12-020 raised it head above the horizon. That evening proved to be a long one, patching machines and thinking about the implications and it seemed obvious, cloudworm. @hdmoore promptly tweeted about a WHOPPING bounty: "The bounty for a reliable CVE-2012-0002 Metasploit module was just upped by $1337 ($1387 so far): http://t.co/0cC7VFZn (cc @GUNdotIO)" https://twitter.com/#!/hdmoore/status/180032751037186048 20120328 @ea_foundation - Aleksandar Nikolic releases working non-BSoD nmap nse script, rdp-ms12-020.nse (Windows 7 running Kaspersky being an exception to the non-BSoD nature of rdp-ms12-020.nse - @twirrim) #### # cloudworm.vectors What makes MS12-020 a prime cloudworm candidate? Well the clouds themselves, specifically the nature of cloud computing, it's marketing and ease of use. The clouds allow people to just spin up machines and run them on public IP infrastructure. Many of those people are not techincally astute enough to run public internet infrastructure, some are technically astute and just forgot that the started up that server in the cloud for testing something on. Because we are human and we err. This makes MS12-020 the ideal "underground" stealth cloudworm, a bit like an STD, you get it before you know you have it, on boot, before you even logon, you are compromised. Or could be once MS12-020 is exploited, if it is not already being exploited, r51shell comes to mind. #### # cloud.security.landscape @bernardgolden at enstratus and others often debate on the responsibilities of the service providers versus customers concerning VM security, this is an ongoing debate and probably shall be for the foreseeable future. Unless the playing field changes, which with MS12-020 it may have just done so. There is a cloudworm coming, it may not be MS12-020 but it will be something and where there are clouds, there can be storms and even hurricanes. #### # the.more.technical.stuff Lets have a look at MS12-020 and the current cloud landscape - 2012.03.13 to 20120329. The following review has been conducted against AWS EC2 and Rackspace UK. #### # hypothesis Shitloads of running (and as yet to have been started) cloud VMs are vulnerable to MS12-020. #### # method.of.testing @nmap 5.51 https://github.com/drkjam/netaddr @ea_foundation's 20120328 version of rdp-ms12-020.nse - http://bit.ly/HnNDl5 All the tests were carried out from separate accounts and to other accounts which are not linked in anyway but belong to the same account holder. All public research was conducted in a responsible manner and the interrogation of potential candidates was non-intrusive. With the report of rdp-ms12-020.nse causing a BSoD under certain circumstances, it cannot be classed as "safe" in the nmap context. #### # methodology netaddr was used to select a random IP address from a random cloud range, which was selected randomly from AWS EC2 public CIDRs, Rackspace UK public CIDRs and Rackspace UK "servicenet" CIDRs. The random target was then checked with nmap 5.51 to determine whether port 3389 was open. If so the target was then checked with nmap to see if port 80 was open. In all cases where port 3389 was found open, a record of the following metadata was recorded: ip_address,cidr,service_indentifier,cloud_indentifer,http_open,datetime rdp-ms12-020.nse was tested against specifically created VMs running various versions of the Windows Server OS on AWS and Rackspace. These were tested to determine the effectiveness of rdp-ms12-020.nse on the different versions and its use in the cloud landscape. #### # considerations.and.findings Divided into AWS EC2 and Rackspace UK. #### # aws #### # aws.ec2.vectors.of.trasmission # AWS Management Console - vulnerable by default When launching a Windows instance via the AWS Management Console, the "Configure Firewall" step is insecure and vulnerable to MS12-020 BY DEFAULT. The AWS Management Console automatically adds a default rule: PERMISSION ALLOWS tcp 3389 3389 FROM CIDR 0.0.0.0/0 ingress http://www.snyping.com/misc/cloudworm/aws.management.console.win.instance.start.vulnerable.by.default.gif In the current landscape this is unexpectable and arguably the service provider has a responsibility to implement best practices. Implementing a global allow RDP could not be described as best practice in today's MS12-020 landscape, could it? The new user and non technical user of AWS would probably err on the side of caution and NOT delete AWS's default rules, naturally. Unfortunately in this case it is at their peril, as their service provider is acting irresponsibly and presents them with a firewall rule that AWS have added by default, which the less technically experienced person would probably read, "that's the default recommended configuration... better leave that alone" and the non technical person probably would not notice. AWS does the same with ssh on Linux instances as well in their Management Console "Launch instances" walk-thru. http://www.snyping.com/misc/cloudworm/aws.management.console.linux.instance.start.insecure.by.default.gif AMAZON -10 #### # aws.mitigations AWS can see the implications of MS12-020. On 2012.03.13 AWS released an entire new batch of Window AMIs in ALL regions, below we just the eu-west-1 is highlighted. [root@zpf-controller-dev-1-10g-ruk ~]# zpf list.images aeuw1 | grep -i "win" | grep "2012.03.13" | grep "name=amazon" , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , [root@zpf-controller-dev-1-10g-ruk ~]# Those were responsible steps to take and the new AMI's are effective and not vulnerable to MS12-020 on boot. #### # test.new.ami Testing new AWS AMI with rdp-ms12-020.nse = OK. ####### # START - Test - ami-937941e7 # # Launched ami-937941e7 # ec2-public-windows-image-eu/Windows_Server-2003-R2_SP2-English-32Bit-Base-2012.03.13.manifest.xml /usr/local/snype/melollam/melollam.rdp-ms12-020.nse.sh ec2-123-124-125-126.eu-west-1.compute.amazonaws.com [root@melollam tmp]# /usr/local/snype/melollam/melollam.rdp-ms12-020.nse.sh ec2-123-124-125-126.eu-west-1.compute.amazonaws.com Starting Nmap 5.51 ( http://nmap.org ) at 2012-03-29 04:12 UTC --------------- Timing report --------------- hostgroups: min 1, max 100000 rtt-timeouts: init 1000, min 100, max 10000 max-scan-delay: TCP 1000, UDP 1000, SCTP 1000 parallelism: min 0, max 0 max-retries: 10, host-timeout: 0 min-rate: 0, max-rate: 0 --------------------------------------------- NSE: Loaded 9 scripts for scanning. NSE: Starting runlevel 1 (of 1) scan. mass_rdns: Using DNS server 123.124.125.127 mass_rdns: Using DNS server 123.124.125.128 Initiating Parallel DNS resolution of 1 host. at 10:12 mass_rdns: 0.04s 0/1 [#: 2, OK: 0, NX: 0, DR: 0, SF: 0, TR: 1] Completed Parallel DNS resolution of 1 host. at 10:12, 0.04s elapsed DNS resolution of 1 IPs took 0.04s. Mode: Async [#: 2, OK: 1, NX: 0, DR: 0, SF: 0, TR: 1, CN: 0] Initiating SYN Stealth Scan at 10:12 Scanning ec2-123-124-125-126.eu-west-1.compute.amazonaws.com (123.124.125.126) [1 port] Packet capture filter (device eth0): dst host 123.124.125.121 and (icmp or ((tcp or udp or sctp) and (src host 123.124.125.126))) Completed SYN Stealth Scan at 10:12, 2.02s elapsed (1 total ports) Overall sending rates: 0.99 packets / s, 43.54 bytes / s. Initiating Service scan at 10:12 NSE: Starting runlevel 1 (of 1) scan. Nmap scan report for ec2-123-124-125-126.eu-west-1.compute.amazonaws.com (123.124.125.126) Host is up, received user-set. Scanned at 2012-03-29 10:12:31 UTC for 2s PORT STATE SERVICE REASON VERSION 3389/tcp filtered ms-term-serv no-response NSE: Starting runlevel 1 (of 1) scan. Read from /usr/local/share/nmap: nmap-payloads nmap-service-probes nmap-services. Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 2.37 seconds Raw packets sent: 2 (88B) | Rcvd: 0 (0B) [root@melollam tmp]# # END - Test - ami-937941e7 ####### AMAZON +5 But... Really for the default rules you present your customers. AMAZON -7 NOTE: These scores an not technical, they are tongue in cheek. #### # vulnerable.amis Consider ALL existing AWS AMI and EBS images pre 2012.03.13 as vulnerable. How many vulnerable images does AWS have? And how many will be started with the AWS Management Console, "vulnerable_by_default" security group permission? Just looking at Europe and the US W and E, lots (maybe a few after 2012.03.13 but the point remains), lots. [root@zpf-controller-dev-1-10g-ruk ~]# zpf list.images aeuw1 | grep -i "win" | grep -v "2012.03.13\|name=amazon" | grep -c "NodeImage" 215 [root@zpf-controller-dev-1-10g-ruk ~]# zpf list.images ausw1 | grep -i "win" | grep -v "2012.03.13\|name=amazon" | grep -c "NodeImage" 161 [root@zpf-controller-dev-1-10g-ruk ~]# zpf list.images ause1 | grep -i "win" | grep -v "2012.03.13\|name=amazon" | grep -c "NodeImage" 299 [root@zpf-controller-dev-1-10g-ruk ~]# Now how many of those will be booted up? They have a VERY high risk window to MS12-020 between boot, update and restart. #### # aws.patched.existing.AMIs? No. Any Windows AMI that has been bundled prior to 20120313 is unpatched and vulnerable at instance startup, until the instance is updated and rebooted. #### # test.user.bundled.pre.2012.03.13.ami [root@melollam ~]# nmap --debug -sC -sV -Pn -p3389 --script /usr/local/share/nmap/scripts/rdp-ms12-020.nse --script-trace ec2-123-124-125-126.eu-west-1.compute.amazonaws.com Starting Nmap 5.51 ( http://nmap.org ) at 2012-03-28 23:02 UTC --------------- Timing report --------------- hostgroups: min 1, max 100000 rtt-timeouts: init 1000, min 100, max 10000 max-scan-delay: TCP 1000, UDP 1000, SCTP 1000 parallelism: min 0, max 0 max-retries: 10, host-timeout: 0 min-rate: 0, max-rate: 0 --------------------------------------------- NSE: Loaded 9 scripts for scanning. NSE: Starting runlevel 1 (of 1) scan. mass_rdns: Using DNS server 123.124.125.127 mass_rdns: Using DNS server 123.124.125.128 Initiating Parallel DNS resolution of 1 host. at 23:02 mass_rdns: 0.01s 0/1 [#: 2, OK: 0, NX: 0, DR: 0, SF: 0, TR: 1] Completed Parallel DNS resolution of 1 host. at 23:02, 0.01s elapsed DNS resolution of 1 IPs took 0.01s. Mode: Async [#: 2, OK: 1, NX: 0, DR: 0, SF: 0, TR: 1, CN: 0] Initiating SYN Stealth Scan at 23:02 Scanning ec2-123-124-125-126.eu-west-1.compute.amazonaws.com (123.124.125.126) [1 port] Packet capture filter (device eth0): dst host 123.124.125.121 and (icmp or ((tcp or udp or sctp) and (src host 123.124.125.126))) Discovered open port 3389/tcp on 123.124.125.126 Completed SYN Stealth Scan at 23:02, 0.03s elapsed (1 total ports) Overall sending rates: 32.86 packets / s, 1445.75 bytes / s. Initiating Service scan at 23:02 Scanning 1 service on ec2-123-124-125-126.eu-west-1.compute.amazonaws.com (123.124.125.126) Completed Service scan at 23:02, 6.03s elapsed (1 service on 1 host) Starting RPC scan against ec2-123-124-125-126.eu-west-1.compute.amazonaws.com (123.124.125.126) NSE: Starting runlevel 1 (of 1) scan. NSE: Starting rdp-ms12-020 against 123.124.125.126:3389. NSE: Script scanning 123.124.125.126. Initiating NSE at 23:02 NSOCK (6.2530s) TCP connection requested to 123.124.125.126:3389 (IOD #1) EID 8 NSOCK (6.2660s) Callback: CONNECT SUCCESS for EID 8 [123.124.125.126:3389] NSE: TCP 123.124.125.121:54716 > 123.124.125.126:3389 | CONNECT NSE: TCP 123.124.125.121:54716 > 123.124.125.126:3389 | 00000000: 03 00 00 0b 06 e0 00 00 00 00 00 NSOCK (6.2660s) Write request for 11 bytes to IOD #1 EID 19 [123.124.125.126:3389]: ........... NSOCK (6.2660s) Callback: WRITE SUCCESS for EID 19 [123.124.125.126:3389] NSE: TCP 123.124.125.121:54716 > 123.124.125.126:3389 | SEND NSOCK (6.2660s) Read request for 0 bytes from IOD #1 [123.124.125.126:3389] EID 26 NSOCK (6.2790s) Callback: READ SUCCESS for EID 26 [123.124.125.126:3389] (11 bytes): .........4. NSE: TCP 123.124.125.121:54716 < 123.124.125.126:3389 | 00000000: 03 00 00 0b 06 d0 00 00 12 34 00 4 NSE: TCP 123.124.125.121:54716 > 123.124.125.126:3389 | 00000000: 03 00 00 65 02 f0 80 7f 65 5b 04 01 01 04 01 01 e e[ 00000010: 01 01 ff 30 19 02 01 22 02 01 20 02 01 00 02 01 0 " 00000020: 01 02 01 00 02 01 01 02 02 ff ff 02 01 02 30 18 0 00000030: 02 01 01 02 01 01 02 01 01 02 01 01 02 01 00 02 00000040: 01 01 02 01 ff 02 01 02 30 19 02 01 ff 02 01 ff 0 00000050: 02 01 ff 02 01 01 02 01 00 02 01 01 02 02 ff ff 00000060: 02 01 02 04 00 NSOCK (6.2790s) Write request for 101 bytes to IOD #1 EID 35 [123.124.125.126:3389] NSOCK (6.2790s) Callback: WRITE SUCCESS for EID 35 [123.124.125.126:3389] NSE: TCP 123.124.125.121:54716 > 123.124.125.126:3389 | SEND NSE: TCP 123.124.125.121:54716 > 123.124.125.126:3389 | 00000000: 03 00 00 08 02 f0 80 28 ( NSOCK (6.2790s) Write request for 8 bytes to IOD #1 EID 43 [123.124.125.126:3389]: .......( NSOCK (6.2790s) Callback: WRITE SUCCESS for EID 43 [123.124.125.126:3389] NSE: TCP 123.124.125.121:54716 > 123.124.125.126:3389 | SEND NSOCK (6.2790s) Read request for 0 bytes from IOD #1 [123.124.125.126:3389] EID 50 NSOCK (6.4880s) Callback: READ SUCCESS for EID 50 [123.124.125.126:3389] (11 bytes): ........... NSE: TCP 123.124.125.121:54716 < 123.124.125.126:3389 | 00000000: 03 00 00 0b 02 f0 80 2e 00 00 01 . NSE: TCP 123.124.125.121:54716 > 123.124.125.126:3389 | 00000000: 03 00 00 08 02 f0 80 28 ( NSOCK (6.4880s) Write request for 8 bytes to IOD #1 EID 59 [123.124.125.126:3389]: .......( NSOCK (6.4880s) Callback: WRITE SUCCESS for EID 59 [123.124.125.126:3389] NSE: TCP 123.124.125.121:54716 > 123.124.125.126:3389 | SEND NSOCK (6.4880s) Read request for 0 bytes from IOD #1 [123.124.125.126:3389] EID 66 NSOCK (6.5010s) Callback: READ SUCCESS for EID 66 [123.124.125.126:3389] (11 bytes): ........... NSE: TCP 123.124.125.121:54716 < 123.124.125.126:3389 | 00000000: 03 00 00 0b 02 f0 80 2e 00 00 02 . NSE: TCP 123.124.125.121:54716 > 123.124.125.126:3389 | 00000000: 03 00 00 0c 02 f0 80 38 00 01 03 eb 8 NSOCK (6.5010s) Write request for 12 bytes to IOD #1 EID 75 [123.124.125.126:3389]: .......8.... NSOCK (6.5010s) Callback: WRITE SUCCESS for EID 75 [123.124.125.126:3389] NSE: TCP 123.124.125.121:54716 > 123.124.125.126:3389 | SEND NSOCK (6.5010s) Read request for 0 bytes from IOD #1 [123.124.125.126:3389] EID 82 NSOCK (6.5130s) Callback: READ SUCCESS for EID 82 [123.124.125.126:3389] (15 bytes): .......>....... NSE: TCP 123.124.125.121:54716 < 123.124.125.126:3389 | 00000000: 03 00 00 0f 02 f0 80 3e 00 00 01 03 eb 03 eb > NSE: TCP 123.124.125.121:54716 > 123.124.125.126:3389 | 00000000: 03 00 00 0c 02 f0 80 38 00 02 03 eb 8 NSOCK (6.5130s) Write request for 12 bytes to IOD #1 EID 91 [123.124.125.126:3389]: .......8.... NSOCK (6.5140s) Callback: WRITE SUCCESS for EID 91 [123.124.125.126:3389] NSE: TCP 123.124.125.121:54716 > 123.124.125.126:3389 | SEND NSOCK (6.5140s) Read request for 0 bytes from IOD #1 [123.124.125.126:3389] EID 98 NSOCK (6.5260s) Callback: READ SUCCESS for EID 98 [123.124.125.126:3389] (15 bytes): .......>....... NSE: TCP 123.124.125.121:54716 < 123.124.125.126:3389 | 00000000: 03 00 00 0f 02 f0 80 3e 00 00 02 03 eb 03 eb > NSE: TCP 123.124.125.121:54716 > 123.124.125.126:3389 | CLOSE NSE: Finished rdp-ms12-020 against 123.124.125.126:3389. Completed NSE at 23:02, 0.27s elapsed Nmap scan report for ec2-123-124-125-126.eu-west-1.compute.amazonaws.com (123.124.125.126) Host is up, received user-set (0.014s latency). Scanned at 2012-03-28 23:02:16 UTC for 6s PORT STATE SERVICE REASON VERSION 3389/tcp open microsoft-rdp syn-ack Microsoft Terminal Service | rdp-ms12-020: | VULNERABLE: | MS12-020 Remote Desktop Protocol Denial Of Service Vulnerability | State: VULNERABLE | IDs: CVE:CVE-2012-0152 | Risk factor: Medium CVSSv2: 4.3 (MEDIUM) (AV:N/AC:M/Au:N/C:N/I:N/A:P) | Description: | Remote Desktop Protocol vulnerability that could allow remote attackers to cause Denial Of Service agains on the targeted system. | | Disclosure date: 2012-03-13 | References: | http://technet.microsoft.com/en-us/security/bulletin/ms12-020 | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0152 | | MS12-020 Remote Desktop Protocol Remote Code Execution Vulnerability | State: VULNERABLE | IDs: CVE:CVE-2012-0002 | Risk factor: High CVSSv2: 9.3 (HIGH) (AV:N/AC:M/Au:N/C:C/I:C/A:C) | Description: | Remote Desktop Protocol vulnerability that could allow remote attackers to execute arbitrary code on the targeted system. | | Disclosure date: 2012-03-13 | References: | http://technet.microsoft.com/en-us/security/bulletin/ms12-020 |_ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0002 Service Info: OS: Windows Final times for host: srtt: 13522 rttvar: 13522 to: 100000 NSE: Starting runlevel 1 (of 1) scan. Read from /usr/local/share/nmap: nmap-payloads nmap-rpc nmap-service-probes nmap-services. Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 6.53 seconds Raw packets sent: 1 (44B) | Rcvd: 1 (44B) [root@melollam ~]# There you go. Vulnerable and to be expected. Expecting AWS to patch ALL bundled AMIs is an unreasonable exception, would it even be possible? #### # aws.further.mitigations.needed Seeing as AWS cannot reasonable patch ALL AMIs, Amazon should consider further mitigations. 1. Advise all customers with a 0.0.0.0/0 RDP permission that this permission is going to be revoked with immediate effect and they can log on to the AWS Management Console and added trusted IP/CIDRs to the relevant security groups and then immediately revoke the global permissions. 2. Immediately change the default rules in the AWS Management Console "Launch instance" context so that administrative ports are not opened globally by default. 3. Advise all customers with a 0.0.0.0/0 ssh permission that this permission is going to be revoked with immediate effect and they can log on to the AWS Management Console and added trusted IP/CIDRs to the relevant security groups and then immediately revoke the global permissions. #### # rackspace.uk (.. the US is the same, possibly other implementations of openstack as well, I have not had an opportunity to have a look at @hpcloud services yet) This is going to take a while. Where AWS have the stupid default security group rules, Rackspace have the stupid "servicenet". Now back to @bernardgolden's domain, cloud service provider's SHOULD have a responsibility to present their customers with the best practices BY DEFAULT, when it comes to the question of the responsibility of the cloud_provider vs customer. Fullstop. And both AWS and Rackspace fail at this completely!! #### # rackspace.servicenet So "servicenet" they tell me, it is a "feature", yip it is a "feature" alright! So what is "servicenet"? Simple, unfirewalled LAN for ALL Rackspace cloud servers in a region. Yes basically... -A INPUT -i eth1 -j ACCEPT or maybe ALLOW tcp -p 1-65535 -i eth1 -s 10.177.128.0/18 ALLOW udp -p 1-65535 -i eth1 -s 10.177.128.0/18 or Let all Rackspace cloud servers in the UK connect to any other Rackspace UK cloud server arbitarily on any port on the eth1 interface, ...so long and thanks for all the fish. or Maybe something different, who knows? We do know that in the process of commodifying cloud services (specifically IaaS) and abstracting their differences is a pain in the arse. I am sure that @libcloud and @geemus would agree. Not only at the level of the unique services they all offer but all their unique API calls as well. But I digress... back to the point MS12-020 and Rackspace UK. As I said AWS and Rackspace they as bad as each other. #### # rackspace.images Now lets take a look at Rackspace's images, they are bad by default. Already old and unpatched when you start them and they ALL get worse every day. All flavours and they know this. So the Rackspace images - VULNERABLE # Check rackspace default Windows Server 2008 SP2 x86 # # # Created lamb1 # password: lamb1NKO216xej # Now on boot and at login KB2621440 is installed, but requires a reboot to take effect. #Security Update for Windows Server 2008 (KB2621440) # #Installation date: ‎3/‎29/‎2012 5:39 AM # #Installation status: Pending # #Error details: Code 80242014 # #Update type: Important # #A security issue has been identified that could allow an unauthenticated remote attacker to compromise your system and gain control over it. You can help protect your system by installing this update from Microsoft. After you install this update, you may have to restart your system. # #More information: #http://go.microsoft.com/fwlink/?LinkId=232664 # #Help and Support: #http://support.microsoft.com And before that reboot the cloud server is vulnerable publicly and on the servicenet interface. PORT STATE SERVICE REASON VERSION 3389/tcp open microsoft-rdp syn-ack Microsoft Terminal Service | rdp-ms12-020: | VULNERABLE: | MS12-020 Remote Desktop Protocol Denial Of Service Vulnerability | State: VULNERABLE | IDs: CVE:CVE-2012-0152 | Risk factor: Medium CVSSv2: 4.3 (MEDIUM) (AV:N/AC:M/Au:N/C:N/I:N/A:P) | Description: | Remote Desktop Protocol vulnerability that could allow remote attackers to cause Denial Of Service agains on the targeted system. | | Disclosure date: 2012-03-13 | References: | http://technet.microsoft.com/en-us/security/bulletin/ms12-020 | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0152 | | MS12-020 Remote Desktop Protocol Remote Code Execution Vulnerability | State: VULNERABLE | IDs: CVE:CVE-2012-0002 | Risk factor: High CVSSv2: 9.3 (HIGH) (AV:N/AC:M/Au:N/C:C/I:C/A:C) | Description: | Remote Desktop Protocol vulnerability that could allow remote attackers to execute arbitrary code on the targeted system. | | Disclosure date: 2012-03-13 | References: | http://technet.microsoft.com/en-us/security/bulletin/ms12-020 |_ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0002 Service Info: OS: Windows The same is true for ALL Rackspace UK Windows cloud server images. #### # ruk.migitations The application of the KB2621440 update on boot is a migitation, albiet a fairly ineffective one, as it requires the user the actually reboot the server and the server does not automatically reboot on it's own. When the user logons on they are advised by Automatic Updates that a reboot is required, the user has the option to postpone that reboot for minutes or hours. If the cloud server is not logged onto, it does not reboot on its own and stays in that vulnerable state, until it is logged onto and rebooted. #### # rackspace.further.migitations 1. Lock down servicenet, its not a feature. 2. Implement firewalls on cloud servers with sensible defaults, on the public and servicenet interfaces. 3. Update your cloud server images. #### # ms12-020.in.the.cloud Here is the meat of it. How many VMs are running in the cloud right now that ARE not patched and have RDP open. Well thanks to AWS's default RDP rule and Rackspace's servicenet, thousands. A sample taken to discover possible candidates. A likely cadidate would have ports 3389 and 80 open, with a default IIS 7 or IIS 6 page or IIS 6 404. Those would be prime candidates, however if you were really looking in an automated "bot" finder fashion, you would probe every cloud VM that you found with port 3389 open. That is not the point of this exercise, this exercise is specifically to highlight the cloud providers failing in their design, implementation and duty of care to their customers, which will provide a cloudworm with ideal transmission vectors. #### # sample [root@melollam ~]# #### [root@melollam ~]# # random.cloud.ips.tested [root@melollam ~]# # These were simple random IPs selected at random from one of [root@melollam ~]# # the target ranges: aws_public, ruk_public or ruk_servicenet [root@melollam ~]# cat /var/log/snype/scripts/melollam.sh/2012/03/20120329*.melollam.sh.log | grep -c "Random IP" 2252 [root@melollam ~]# # It is important to note that these IPs were not necessary [root@melollam ~]# # attached to any cloud VMs, meaning not in use or maybe they [root@melollam ~]# # were and were running a Linux VM, this just checked to see [root@melollam ~]# # if port 3389 was open. [root@melollam ~]# [root@melollam ~]# [root@melollam ~]# # VMs discovered with port 3389 open [root@melollam ~]# cat /var/log/snype/scripts/melollam.sh/2012/03/20120329*.melollam.sh.log | grep -c "CANDIDATE" 94 [root@melollam ~]# [root@melollam ~]# #### [root@melollam ~]# # random.ip.distrubution [root@melollam ~]# [root@melollam ~]# # aws_public [root@melollam ~]# cat /var/log/snype/scripts/melollam.sh/2012/03/20120329*.melollam.sh.log | grep -c "aws_public" 807 [root@melollam ~]# # ruk_public [root@melollam ~]# cat /var/log/snype/scripts/melollam.sh/2012/03/20120329*.melollam.sh.log | grep -c "ruk_public" 866 [root@melollam ~]# # ruk_servicenet [root@melollam ~]# cat /var/log/snype/scripts/melollam.sh/2012/03/20120329*.melollam.sh.log | grep -c "ruk_servicenet" 751 [root@melollam ~]# [root@melollam ~]# #### [root@melollam ~]# # ms12-020.candidates [root@melollam ~]# # [root@melollam ~]# # Note the initial parsing of the metadata was flawed and the [root@melollam ~]# # cloud provider was not captured, hence the results per [root@melollam ~]# # cloud CIDR do not tally with the total [root@melollam ~]# # [root@melollam ~]# # total.candidates [root@melollam ~]# cat /var/log/snype/scripts/melollam.sh/2012/03/20120329*.csv | grep -c 'ms' 94 [root@melollam ~]# [root@melollam ~]# # aws_public.candidates [root@melollam ~]# cat /var/log/snype/scripts/melollam.sh/2012/03/20120329*.csv | grep -c 'aws_public' 17 [root@melollam ~]# # ruk_public.candidates [root@melollam ~]# cat /var/log/snype/scripts/melollam.sh/2012/03/20120329*.csv | grep -c 'ruk_public' 52 [root@melollam ~]# # ruk_servicenet.candidates [root@melollam ~]# cat /var/log/snype/scripts/melollam.sh/2012/03/*.csv | grep -c 'ruk_servicenet' 19 [root@melollam ~]# POC #### # in.closing It is clear to see that the implications of not restricting administrative ports and ports in general on all network segments, leaves GAPPING holes in the cloud infrastructure. The most vulnerable customers are the least technical ones, they trust the expert IaaS companies to help them run "virtually" and guide them down that path. It is here where the cloud providers fail. The IaaS companies throw up their hands and say the user is responsible for ensuring security or it is a shared responsibility. However, I have never seen any type of validation from any IaaS provider, other than a phone call to verify what exactly? That the user can be reached on a phone number. The IaaS providers make absolutely no attempts to ensure that users are running their VMs with a "sensible" setup and communicate possible improvements. Apart for S3 which will send you an email if some objects have "everyone" read access, but other than that, nothing. In the cloud that does not necessarily only affect the vulnerable users, it can have knock on effects to the astute users as well, users which share the same host. All of sudden your VM seems sluggish, CPU steal is increasing and affecting your services. Or other "trusted" cloud servers are probing you, perhaps even the astute user did not realise that Rackspace has the servicenet "feature" and only implemented the their iptables rules on eth0. Looking at the bigger picture, we should assume that all machines run in the clouds have user data and/or customer data on them and all parties involved in handling that data should have a responsibility to ensure that data is kept safe, by default. MS12-020 may not be a cloudworm, but one will arrive one day and in the current cloud landscape there are definitely vectors that will "assist" it. MS12-020 is a blatant-in-your-face candidate. However, the first cloudworm may not use a single vulnerability, it may come from "blended" vulnerabilities. Perhaps from a default public Rackspace Windows cloud server configuration: PORT STATE SERVICE VERSION 80/tcp open http Microsoft IIS httpd 7.5 135/tcp open msrpc Microsoft Windows RPC 445/tcp open netbios-ssn 3389/tcp open microsoft-rdp Microsoft Terminal Service 49154/tcp open msrpc Microsoft Windows RPC The cloud providers have a LOT to answer for. And if they do not now, they will have if they do not start to think about taking a more proactive role in assisting their customers and providing services with best practices implemented by default. #### # note.to.aws.and.rackspace AWS and Rackspace, you lord over your customers and tell them they should use best practices and implement firewalls and iptables and keep up to date with the latest patches, etc and YOU yourselves, do not even do it on the platforms that you provider your services on!!!! DON'T make stupid default rules and run stupid open network configurations!!!!!! Maybe I should speak to @jeffbarr and @rackspace Jeff does not reply to me anymore and @rackspace ignore me and tell me things are features. Rant over, no one listens anyway.