Daily Archives: May 21, 2019

RDP Stands for “Really DO Patch!” – Understanding the Wormable RDP Vulnerability CVE-2019-0708

During Microsoft’s May Patch Tuesday cycle, a security advisory was released for a vulnerability in the Remote Desktop Protocol (RDP). What was unique in this particular patch cycle was that Microsoft produced a fix for Windows XP and several other operating systems, which have not been supported for security updates in years. So why the urgency and what made Microsoft decide that this was a high risk and critical patch?

According to the advisory, the issue discovered was serious enough that it led to Remote Code Execution and was wormable, meaning it could spread automatically on unprotected systems. The bulletin referenced well-known network worm “WannaCry” which was heavily exploited just a couple of months after Microsoft released MS17-010 as a patch for the related vulnerability in March 2017. McAfee Advanced Threat Research has been analyzing this latest bug to help prevent a similar scenario and we are urging those with unpatched and affected systems to apply the patch for CVE-2019-0708 as soon as possible. It is extremely likely malicious actors have weaponized this bug and exploitation attempts will likely be observed in the wild in the very near future.

Vulnerable Operating Systems:

  • Windows 2003
  • Windows XP
  • Windows 7
  • Windows Server 2008
  • Windows Server 2008 R2

Worms are viruses which primarily replicate on networks. A worm will typically execute itself automatically on a remote machine without any extra help from a user. If a virus’ primary attack vector is via the network, then it should be classified as a worm.

The Remote Desktop Protocol (RDP) enables connection between a client and endpoint, defining the data communicated between them in virtual channels. Virtual channels are bidirectional data pipes which enable the extension of RDP. Windows Server 2000 defined 32 Static Virtual Channels (SVCs) with RDP 5.1, but due to limitations on the number of channels further defined Dynamic Virtual Channels (DVCs), which are contained within a dedicated SVC. SVCs are created at the start of a session and remain until session termination, unlike DVCs which are created and torn down on demand.

It’s this 32 SVC binding which CVE-2019-0708 patch fixes within the _IcaBindVirtualChannels and _IcaRebindVirtualChannels functions in the RDP driver termdd.sys. As can been seen in figure 1, the RDP Connection Sequence connections are initiated and channels setup prior to Security Commencement, which enables CVE-2019-0708 to be wormable since it can self-propagate over the network once it discovers open port 3389.

 

Figure 1: RDP Protocol Sequence

The vulnerability is due to the “MS_T120” SVC name being bound as a reference channel to the number 31 during the GCC Conference Initialization sequence of the RDP protocol. This channel name is used internally by Microsoft and there are no apparent legitimate use cases for a client to request connection over an SVC named “MS_T120.”

Figure 2 shows legitimate channel requests during the GCC Conference Initialization sequence with no MS_T120 channel.

Figure 2: Standard GCC Conference Initialization Sequence

However, during GCC Conference Initialization, the Client supplies the channel name which is not whitelisted by the server, meaning an attacker can setup another SVC named “MS_T120” on a channel other than 31. It’s the use of MS_T120 in a channel other than 31 that leads to heap memory corruption and remote code execution (RCE).

Figure 3 shows an abnormal channel request during the GCC Conference Initialization sequence with “MS_T120” channel on channel number 4.

 

Figure 3: Abnormal/Suspicious GCC Conference Initialization Sequence – MS_T120 on nonstandard channel

The components involved in the MS_T120 channel management are highlighted in figure 4. The MS_T120 reference channel is created in the rdpwsx.dll and the heap pool allocated in rdpwp.sys. The heap corruption happens in termdd.sys when the MS_T120 reference channel is processed within the context of a channel index other than 31.

Figure 4: Windows Kernel and User Components

The Microsoft patch as shown in figure 5 now adds a check for a client connection request using channel name “MS_T120” and ensures it binds to channel 31 only (1Fh) in the _IcaBindVirtualChannels and _IcaRebindVirtualChannels functions within termdd.sys.

 

Figure 5: Microsoft Patch Adding Channel Binding Check

After we investigated the patch being applied for both Windows 2003 and XP and understood how the RDP protocol was parsed before and after patch, we decided to test and create a Proof-of-Concept (PoC) that would use the vulnerability and remotely execute code on a victim’s machine to launch the calculator application, a well-known litmus test for remote code execution.

Figure 6: Screenshot of our PoC executing

For our setup, RDP was running on the machine and we confirmed we had the unpatched versions running on the test setup. The result of our exploit can be viewed in the following video:

There is a gray area to responsible disclosure. With our investigation we can confirm that the exploit is working and that it is possible to remotely execute code on a vulnerable system without authentication. Network Level Authentication should be effective to stop this exploit if enabled; however, if an attacker has credentials, they will bypass this step.

As a patch is available, we decided not to provide earlier in-depth detail about the exploit or publicly release a proof of concept. That would, in our opinion, not be responsible and may further the interests of malicious adversaries.

Recommendations:

  • We can confirm that a patched system will stop the exploit and highly recommend patching as soon as possible.
  • Disable RDP from outside of your network and limit it internally; disable entirely if not needed. The exploit is not successful when RDP is disabled.
  • Client requests with “MS_T120” on any channel other than 31 during GCC Conference Initialization sequence of the RDP protocol should be blocked unless there is evidence for legitimate use case.

 

It is important to note as well that the RDP default port can be changed in a registry field, and after a reboot will be tied the newly specified port. From a detection standpoint this is highly relevant.

Figure 7: RDP default port can be modified in the registry

Malware or administrators inside of a corporation can change this with admin rights (or with a program that bypasses UAC) and write this new port in the registry; if the system is not patched the vulnerability will still be exploitable over the unique port.

McAfee Customers:

McAfee NSP customers are protected via the following signature released on 5/21/2019:

0x47900c00 “RDP: Microsoft Remote Desktop MS_T120 Channel Bind Attempt”

If you have any questions, please contact McAfee Technical Support.

 

The post RDP Stands for “Really DO Patch!” – Understanding the Wormable RDP Vulnerability CVE-2019-0708 appeared first on McAfee Blogs.

“Hackable?” Puts Smartphones to the Test

Is the Personal Data on Your Smartphone Vulnerable? Listen to Find Out: Used for everything from banking and taking pictures, to navigating, streaming, and connecting, mobile devices are a treasure trove of sensitive personal data. On the latest episode of “Hackable?” the team investigates how secure that data really is by inviting a white-hat to try and remotely penetrate our host Geoff’s smartphone. Listen now on Apple Podcasts and learn if one errant click could expose everything, including your deleted photos.  

The post “Hackable?” Puts Smartphones to the Test appeared first on McAfee Blogs.

Endpoint’s Relevance in the World of Cloud

Businesses everywhere are looking to cloud solutions to help expedite processes and improve their data storage strategy. All anyone is talking about these days is the cloud, seemingly dwindling the conversation around individual devices and their security. However, many don’t realize these endpoint devices act as gateways to the cloud, which makes their security more pressing than ever. In fact, there is a unique relationship between endpoint security and cloud security, making it crucial for businesses to understand how this dynamic affects information security overall. Let’s explore exactly how these two are intertwined and how exactly endpoint security can move the needle when it comes to securing the cloud.

Cloudier Skies

Between public cloud, private cloud, hybrid cloud, and now multi-cloud, the cloud technology industry is massive and showing zero signs of slowing down. Adoption is rampant, with the cloud market expected to achieve a five-year compound annual growth rate (CAGR) of 22.5%, with public cloud services spending reaching $370 billion in 2022. With cloud adoption drawing so much attention from businesses, it’s as important as ever that enterprises keep security top of mind.

This need for security is only magnified by the latest trend in cloud tech – the multi-cloud strategy. With modern-day businesses having such a diverse set of needs, many have adopted either a hybrid or multi-cloud strategy in order to effectively organize and store a plethora of data – 74 percent of enterprises, as a matter of fact. This has many security vendors and personnel scrambling to adjust security architecture to meet the needs of the modern cloud strategy. And though all businesses must have an effective security plan in place that compliments their cloud architecture, these security plans should always still consider how these clouds can become compromised through individual gateways, or, endpoint devices.

The Relationship Between Endpoint and Cloud

The cloud may be a virtual warehouse for your data, but every warehouse has a door or two. Endpoint devices act as doors to the cloud, as these mobile phones, computers, and more all connect to whichever cloud architecture an organization has implemented. That means that one endpoint device, if misused or mishandled, could create a vulnerable gateway to the cloud and therefore cause it to become compromised. Mind you – endpoint devices are not only gateways to the cloud, but also the last line of defense protecting an organization’s network in general.

Endpoint is not only relevant in the world of cloud – it has a direct impact on an organization’s cloud – and overall – security. A compromised endpoint can lead to an exposed cloud, which could make for major data loss. Businesses need to therefore put processes into place that outline what assets users put where and state any need-to-knows they should have top of mind when using the cloud. Additionally, it’s equally important every business ensures they make the correct investment in cloud and endpoint security solutions that perfectly complement these processes.

Ensuring Security Strategy Is Holistic

As the device-to-cloud cybersecurity company, we at McAfee understand how important the connection is between endpoint and cloud and how vital it is businesses ensure both are secured. That’s why we’ve built out a holistic security strategy, offering both cloud security solutions and advanced endpoint products that help an organization cover all its bases.

If your business follows a holistic approach to security – covering every endpoint through to every cloud – you’ll be able to prevent data exposures from happening. From there, you can have peace of mind about endpoint threats and focus on reaping the benefits of a smart cloud strategy.

To learn more about our approach to endpoint security strategy, be sure to follow us @McAfee and @McAfee_Business, and read more in our latest paper:

 

The post Endpoint’s Relevance in the World of Cloud appeared first on McAfee Blogs.

Veracode Announces New DevOps Penetration Testing Service

DevSecOps can be challenging for many organizations when you consider all the areas of the DevOps process that require security testing. Organizations that begin to shift security “left” often find significant gaps in the security of infrastructure and operational components that are now integrated into the development process. Many of the technologies being used in DevOps are also very new to most organizations and are more recently starting to become “mainstream.” For example, we’re seeing more customers adopting microservices, utilizing cloud storage through Amazon S3, MongoDB, and Elasticsearch, deploying applications using containers, and managing those containers with newer orchestration technology like Kubernetes.

These new technologies allow faster development, but also come with the side effect of introducing a new attack surface and different types of vulnerabilities. Like any new technology, systems within a DevOps environment are often deployed insecurely and misconfigured. This makes the requirement to conduct security testing on the DevOps environment more important than ever. Moreover, what about the developers themselves from a security awareness perspective? What might they be discussing with peers on online forums, leaving in code repositories, or other areas on the Internet that may make their applications and the organization more susceptible to targeted phishing attacks, data leaks, and breaches that we hear about in the news on almost a daily basis?

What Is Veracode DevOps Penetration Testing?

Automating security testing is a key concept when building out a DevOps process and should not be overlooked. However, there is still a need for penetration testing in a DevOps environment. Penetration testing provides something that automation cannot -- the attacker’s perspective.

Building upon our strong application penetration testing service and highly skilled team, Veracode DevOps Penetration Testing provides testing above and beyond the application to include the operations and infrastructure components of applications. Technologies that can be in scope for this type of testing include, but are not limited to:

  • Containers like Docker and Kubernetes orchestration
  • Microservices and related interactions
  • CI tool environments like Hudson and Jenkins
  • Cloud infrastructure (AWS, Azure) and cloud storage databases
  • Network infrastructure related to application deployment and configuration management

The Importance of Open Source Intelligence and DevOps

Veracode DevOps Penetration Testing also provides Open Source Intelligence (OSINT) analysis as part of every DevOps Penetration Test we perform. This analysis identifies misconfigured cloud storage databases such as AWS S3 buckets, Elasticsearch, MongoDB instances, and others. If you haven’t been paying attention to the news, misconfigured cloud storage databases are some of the largest sources of data leaks and breaches we see today*. In addition, we also leverage OSINT techniques to find vulnerabilities in the infrastructure that may leave your organization and applications exposed.

As part of this process, testers will also look into the activities of the developers themselves. Our testing checks to see if developers are practicing proper security measures. For example, we will analyze GitHub repositories looking for exposed credentials, locating sensitive data related to app development, and seeing what’s being discussed about an organization’s applications within popular public developer forums like Stack Overflow.

DevOps and Security Compliance

Security compliance does not magically go away when organizations “shift left.” That’s why Veracode DevOps Penetration Testing can be used to meet compliance requirements for PCI DSS 11.3 as well as GDPR Article 32 in the European Union. This requirement is also important for those organizations that need to comply with GDPR outside of the EU. GDPR Article 32 covers “Security of processing,” which requires that the data controller and processor implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk. This includes “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing” **. Penetration testing can help meet this new compliance requirement.

Veracode Is a Complete DevOps Testing Solution

Veracode DevOps Penetration Testing combined with Veracode’s static, dynamic, SCA, and application penetration testing provides the most comprehensive testing available for a DevOps environment in the market today. Contact your Veracode Sales or Services representative for more details on how to get started with your first Veracode DevOps Penetration Testing engagement.

Learn more about Veracode DevOps Penetration Testing here.

 

* https://www.zdnet.com/article/unsecured-server-exposes-data-for-85-percent-of-all-panama-citizens/

https://www.hipaajournal.com/misconfigured-secure-cloud-storage-services/

https://www.scmagazine.com/home/opinions/data-breaches-caused-by-misconfigured-servers/

** http://www.privacy-regulation.eu/en/article-32-security-of-processing-GDPR.htm