Steve Povolny – McAfee Blogs https://securingtomorrow.mcafee.com Securing Tomorrow. Today. Wed, 04 Sep 2019 20:21:28 +0000 en-US hourly 1 https://securingtomorrow.mcafee.com/wp-content/uploads/2018/11/cropped-favicon-32x32.png Steve Povolny – McAfee Blogs https://securingtomorrow.mcafee.com 32 32 Apple iOS Attack Underscores Importance of Threat Research https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/apple-ios-attack-underscores-importance-of-threat-research/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/apple-ios-attack-underscores-importance-of-threat-research/#respond Wed, 04 Sep 2019 20:21:28 +0000 https://securingtomorrow.mcafee.com/?p=96594

The recent discovery of exploit chains targeting Apple iOS is the latest example of how cybercriminals can successfully operate malicious campaigns, undetected, through the use of zero-day vulnerabilities. In this scenario, a threat actor or actors operated multiple compromised websites, using at least one or more zero-day vulnerabilities and numerous unique exploit chains and known vulnerabilities to […]

The post Apple iOS Attack Underscores Importance of Threat Research appeared first on McAfee Blogs.

]]>

The recent discovery of exploit chains targeting Apple iOS is the latest example of how cybercriminals can successfully operate malicious campaigns, undetected, through the use of zero-day vulnerabilities.

In this scenario, a threat actor or actors operated multiple compromised websites, using at least one or more zero-day vulnerabilities and numerous unique exploit chains and known vulnerabilities to compromise iPhones, even the latest versions of the operating system, for more than two years. It takes remarkable talent and resources to operate this kind of infrastructure without being detected, as potentially thousands of users were compromised without the campaign being identified.

Every villain necessitates a hero, and this campaign underscores the importance of threat research and responsible vulnerability disclosure. Cybercriminals are getting faster, smarter, and more dangerous with each day that passes. The collective power of a global community of researchers working together to identify and disclose critical vulnerabilities, such as those used in this attack, is an important way to make meaningful progress towards eliminating these types of malicious campaigns. Equally as important is dissecting attacks in their aftermath to expose unique and interesting characteristics and empower defenders and developers to mitigate these threats in the future. With that said, let’s take a look.

An Attack Hiding in Plain Sight

This attack is unique in that the implant was not operating stealthily and was uploading information without encryption. This means a user monitoring their network traffic would notice activity as their information was being uploaded to the attacker’s server in cleartext.

Further, there appears to be debug messages left in the code, so a user connecting their phone to their computer and reviewing console logs, would notice activity as well.

However, given the “closed” operating system on the iPhone, a user would need to take the extra step of connecting their phone to their computer in order to notice these attack indicators. Given this, even a power user would be likely to remain unaware of an infection.

The Value of iOS Exploits

Finding iOS exploits in general is challenging due to the proprietary codebase and modern security mitigations. However, the type of exploits that require no user interaction and result in full remote code execution are the most rare, valuable, and difficult to uncover.

Adding further complexity to the attack, many mobile device exploits today require more than a single vulnerability to be successful; in many cases, 3-4 bugs are required to achieve elevated remote code execution on a target system. This is typically due to mitigations such as sandboxes/containers, restrictions on code execution, and reduced user privileges, making a chain of vulnerabilities necessary. This complexity reduces the success rate of an attack based on the likelihood of one or more of the bugs being discovered and “burned,” or patched out by the vendor.

Apple is a strong player in the responsible disclosure arena, recently expanding its offering of up to $1 million USD for certain vulnerabilities. Vulnerability brokers, who resell vulnerabilities, will reportedly pay up to 3 million USD for zero-interaction remote code execution vulnerabilities on iOS. It’s easy to understand the value of bugs that don’t require interaction from the victim and result in full remote code execution. With the popularity of Apple’s operating systems across mobile devices and laptops, even these prices may be not be enough to encourage threat actors to choose to responsibly disclose their findings over more nefarious purposes.

The Power of Vulnerability Disclosure

Two of the most significant questions this discovery raises are how was this adversary able to operate for so long, primarily using known exploits, and what kind of impact were they able to achieve?

These questions bring us full circle to the value of vulnerability disclosure. Through hardware and software analysis and responsible disclosure, meaningful progress can be made towards exposing these types of vulnerabilities before they can be leveraged by bad actors for nefarious purposes.

The post Apple iOS Attack Underscores Importance of Threat Research appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/apple-ios-attack-underscores-importance-of-threat-research/feed/ 0
In NTDLL I Trust – Process Reimaging and Endpoint Security Solution Bypass https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/in-ntdll-i-trust-process-reimaging-and-endpoint-security-solution-bypass/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/in-ntdll-i-trust-process-reimaging-and-endpoint-security-solution-bypass/#respond Thu, 20 Jun 2019 16:00:14 +0000 https://securingtomorrow.mcafee.com/?p=95608

Process Reimaging Overview The Windows Operating System has inconsistencies in how it determines process image FILE_OBJECT locations, which impacts non-EDR (Endpoint Detection and Response) Endpoint Security Solution’s (such as Microsoft Defender Realtime Protection), ability to detect the correct binaries loaded in malicious processes. This inconsistency has led McAfee’s Advanced Threat Research to develop a new […]

The post In NTDLL I Trust – Process Reimaging and Endpoint Security Solution Bypass appeared first on McAfee Blogs.

]]>

Process Reimaging Overview

The Windows Operating System has inconsistencies in how it determines process image FILE_OBJECT locations, which impacts non-EDR (Endpoint Detection and Response) Endpoint Security Solution’s (such as Microsoft Defender Realtime Protection), ability to detect the correct binaries loaded in malicious processes. This inconsistency has led McAfee’s Advanced Threat Research to develop a new post-exploitation evasion technique we call “Process Reimaging”. This technique is equivalent in impact to Process Hollowing or Process Doppelganging within the Mitre Attack Defense Evasion Category; however, it is , much easier to execute as it requires no code injection. While this bypass has been successfully tested against current versions of Microsoft Windows and Defender, it is highly likely that the bypass will work on any endpoint security vendor or product implementing the APIs discussed below.

The Windows Kernel, ntoskrnl.exe, exposes functionality through NTDLL.dll APIs to support User-mode components such as Endpoint Security Solution (ESS) services and processes. One such API is K32GetProcessImageFileName, which allows ESSs to verify a process attribute to determine whether it contains malicious binaries and whether it can be trusted to call into its infrastructure. The Windows Kernel APIs return stale and inconsistent FILE_OBJECT paths, which enable an adversary to bypass Windows operating system process attribute verification. We have developed a proof-of-concept which exploits this FILE_OBJECT location inconsistency by hiding the physical location of a process EXE.

The PoC allowed us to persist a malicious process (post exploitation) which does not get detected by Windows Defender.

The Process Reimaging technique cannot be detected by Windows Defender until it has a signature for the malicious file and blocks it on disk before process creation or performs a full scan on suspect machine post compromise to detect file on disk. In addition to Process Reimaging Weaponization and Protection recommendations, this blog includes a technical deep dive on reversing the Windows Kernel APIs for process attribute verification and Process Reimaging attack vectors. We use the SynAck Ransomware as a case study to illustrate Process Reimaging impact relative to Process Hollowing and Doppelganging; this illustration does not relate to Windows Defender ability to detect Process Hollowing or Doppelganging but the subverting of trust for process attribute verification.

Antivirus Scanner Detection Points

When an Antivirus scanner is active on a system, it will protect against infection by detecting running code which contains malicious content, and by detecting a malicious file at write time or load time.

The actual sequence for loading an image is as follows:

  • FileCreate – the file is opened to be able to be mapped into memory.
  • Section Create – the file is mapped into memory.
  • Cleanup – the file handle is closed, leaving a kernel object which is used for PAGING_IO.
  • ImageLoad – the file is loaded.
  • CloseFile – the file is closed.

If the Antivirus scanner is active at the point of load, it can use any one of the above steps (1,2 and 4) to protect the operating system against malicious code. If the virus scanner is not active when the image is loaded, or it does not contain definitions for the loaded file, it can query the operating system for information about which files make up the process and scan those files. Process Reimaging is a mechanism which circumvents virus scanning at step 4, or when the virus scanner either misses the launch of a process or has inadequate virus definitions at the point of loading.

There is currently no documented method to securely identify the underlying file associated with a running process on windows.

This is due to Windows’ inability to retrieve the correct image filepath from the NTDLL APIs.  This can be shown to evade Defender (MpMsEng.exe/MpEngine.dll) where the file being executed is a “Potentially Unwanted Program” such as mimikatz.exe. If Defender is enabled during the launch of mimikatz, it detects at phase 1 or 2 correctly.  If Defender is not enabled, or if the launched program is not recognized by its current signature files, then the file is allowed to launch. Once Defender is enabled, or the signatures are updated to include detection, then Defender uses K32GetProcessImageFileName to identify the underlying file. If the process has been created using our Process Reimaging technique, then the running malware is no longer detected. Therefore, any security service auditing running programs will fail to identify the files associated with the running process.

Subverting Trust

The Mitre ATT&CK model specifies post-exploitation tactics and techniques used by adversaries, based on real-world observations for Windows, Linux and macOS Endpoints per figure 1 below.

Figure 1 – Mitre Enterprise ATT&CK

Once an adversary gains code execution on an endpoint, before lateral movement, they will seek to gain persistence, privilege escalation and defense evasion capabilities. They can achieve defense evasion using process manipulation techniques to get code executing in a trusted process. Process manipulation techniques have existed for a long time and evolved from Process Injection to Hollowing and Doppelganging with the objective of impersonating trusted processes. There are other Process manipulation techniques as documented by Mitre ATT&CK and Unprotect Project,  but we will focus on Process Hollowing and Process Doppelganging. Process manipulation techniques exploit legitimate features of the Windows Operating System to impersonate trusted process executable binaries and generally require code injection.

ESSs place inherent trust in the Windows Operating System for capabilities such as digital signature validation and process attribute verification. As demonstrated by Specter Ops, ESSs’ trust in the Windows Operating system could be subverted for digital signature validation.

Similarly, Process Reimaging subverts an ESSs’ trust in the Windows Operating System for process attribute verification.

When a process is trusted by an ESS, it is perceived to contain no malicious code and may also be trusted to call into the ESS trusted infrastructure.

McAfee ATR uses the Mitre ATT&CK framework to map adversarial techniques, such as defense evasion, with associated campaigns. This insight helps organizations understand adversaries’ behavior and evolution so that they can assess their security posture and respond appropriately to contain and eradicate attacks. McAfee ATR creates and shares Yara rules based on threat analysis to be consumed for protect and detect capabilities.

Process Manipulation Techniques (SynAck Ransomware)

McAfee Advanced Threat Research analyzed SynAck ransomware in 2018 and discovered it used Process Doppelganging with Process Hollowing as its fallback defense evasion technique. We use this malware to explain the Process Hollowing and Process Doppelganging techniques, so that they can be compared to Process Reimaging based on a real-world observation.

Process Manipulation defense evasion techniques continue to evolve. Process Doppelganging was publicly announced in 2017, requiring advancements in ESSs for protection and detection capabilities. Because process manipulation techniques generally exploit legitimate features of the Windows Operating system they can be difficult to defend against if the Antivirus scanner does not block prior to process launch.

Process Hollowing

Process hollowing occurs when a process is created in a suspended state then its memory is unmapped and replaced with malicious code. Execution of the malicious code is masked under a legitimate process and may evade defenses and detection analysis” (see figure 2 below)

Figure 2 – SynAck Ransomware Defense Evasion with Process Hollowing

Process Doppelganging

Process Doppelgänging involves replacing the memory of a legitimate process, enabling the veiled execution of malicious code that may evade defenses and detection. Process Doppelgänging’s use of Windows Transactional NTFS (TxF) also avoids the use of highly-monitored API functions such as NtUnmapViewOfSection, VirtualProtectEx, and SetThreadContext” (see figure 3 below)

Figure 3 – SynAck Ransomware Defense Evasion with Doppleganging

Process Reimaging Weaponization

The Windows Kernel APIs return stale and inconsistent FILE_OBJECT paths which enable an adversary to bypass windows operating system process attribute verification. This allows an adversary to persist a malicious process (post exploitation) by hiding the physical location of a process EXE (see figure 4 below).

Figure 4 – SynAck Ransomware Defense Evasion with Process Reimaging

Process Reimaging Technical Deep Dive

NtQueryInformationProcess retrieves all process information from EPROCESS structure fields in the kernel and NtQueryVirtualMemory retrieves information from the Virtual Address Descriptors (VADs) field in EPROCESS structure.

The EPROCESS structure contains filename and path information at the following fields/offsets (see figure 5 below):

  • +0x3b8 SectionObject (filename and path)
  • +0x448 ImageFilePointer* (filename and path)
  • +0x450 ImageFileName (filename)
  • +0x468 SeAuditProcessCreationInfo (filename and path)

* this field is only present in Windows 10

Figure 5 – Code Complexity IDA Graph Displaying NtQueryInformationProcess Filename APIs within NTDLL

Kernel API NtQueryInformationProcess is consumed by following the kernelbase/NTDLL APIs:

  • K32GetModuleFileNameEx
  • K32GetProcessImageFileName
  • QueryFullProcessImageImageFileName

The VADs hold a pointer to FILE_OBJECT for all mapped images in the process, which contains the filename and filepath (see figure 6 below).

Kernel API NtQueryVirtualMemory is consumed by following the kernelbase/NTDLL API:

  • GetMappedFileName

Figure 6 – Code Complexity IDA Graph Displaying NtQueryVirtualMemory Filename API within NTDLL

Windows fails to update any of the above kernel structure fields when a FILE_OBJECT filepath is modified post-process creation. Windows does update FILE_OBJECT filename changes, for some of the above fields.

The VADs reflect any filename change for a loaded image after process creation, but they don’t reflect any rename of the filepath.

The EPROCESS fields also fail to reflect any renaming of the process filepath and only the ImageFilePointer field reflects a filename change.

As a result, the APIs exported by NtQueryInformationProcess and NtQueryVirtualMemory return incorrect process image file information when called by ESSs or other Applications (see Table 1 below).

Table 1 OS/Kernel version and API Matrix

Prerequisites for all Attack Vectors

Process Reimaging targets the post-exploitation phase, whereby a threat actor has already gained access to the target system. This is the same prerequisite of Process Hollowing or Doppelganging techniques within the Defense Evasion category of the Mitre ATT&CK framework.

Process Reimaging Attack Vectors
FILE_OBJECT Filepath Changes

Simply renaming the filepath of an executing process results in Windows OS returning the incorrect image location information for all APIs (See figure 7 below).  This impacts all Windows OS versions at the time of testing.

Figure 7 FILE_OBJECT Filepath Changes – Filepath Changes Impact all Windows OS versions

FILE_OBJECT Filename Changes

Filename Change >= Windows 10

Simply renaming the filename of an executing process results in Windows OS returning the incorrect image information for K32GetProcessImageFileName API (See figure 8.1.1 below). This has been confirmed to impact Windows 10 only.

Figure 8.1.1 FILE_OBJECT Filename Changes – Filename Changes impact Windows >= Windows 10

Per figure 8.1.2 below, GetModuleFileNameEx and QueryFullProcessImageImageFileName will get the correct filename changes due to a new EPROCESS field ImageFilePointer at offset 448.  The instruction there (mov r12, [rbx+448h]) references the ImageFilePointer from offset 448 into the EPROCESS structure.

Figure 8.1.2 NtQueryInformationProcess (Windows 10) – Windows 10 RS1 x64 ntoskrnl version 10.0.14393.0

Filename Change < Windows 10

Simply renaming the filename of an executing process results in Windows OS returning the incorrect image information for K32GetProcessImageFileName, GetModuleFileNameEx and QueryFullProcessImageImageFileName APIs (See figure 8.2.1 below). This has been confirmed to impact Windows 7 and Windows 8.

Figure 8.2.1 FILE_OBJECT Filename Changes – Filename Changes Impact Windows < Windows 10

Per Figure8.2.2 below, GetModuleFileNameEx and QueryFullProcessImageImageFileName will get the incorrect filename (PsReferenceProcessFilePointer references EPROCESS offset 0x3b8 SectionObject).

Figure 8.2.2 NtQueryInformationProcess (Windows 7 and 8) – Windows 7 SP1 x64 ntoskrnl version 6.1.7601.17514

LoadLibrary FILE_OBJECT reuse

LoadLibrary FILE_OBJECT reuse leverages the fact that when a LoadLibrary or CreateProcess is called after a LoadLibrary and FreeLibrary on an EXE or DLL, the process reuses the existing image FILE_OBJECT in memory from the prior LoadLibrary.

Exact Sequence is:

  1. LoadLibrary (path\filename)
  2. FreeLibrary (path\filename)
  3. LoadLibrary (renamed path\filename) or CreateProcess (renamed path\filename)

This results in Windows creating a VAD entry in the process at step 3 above, which reuses the same FILE_OBJECT still in process memory, created from step 1 above. The VAD now has incorrect filepath information for the file on disk and therefore the GetMappedFileName API will return the incorrect location on disk for the image in question.

The following prerequisites are required to evade detection successfully:

  • The LoadLibrary or CreateProcess must use the exact same file on disk as the initial LoadLibrary
  • Filepath must be renamed (dropping the same file into a newly created path will not work)

The Process Reimaging technique can be used in two ways with LoadLibrary FILE_OBJECT reuse attack vector:

  1. LoadLibrary (see figure 9 below)
    1. When an ESS or Application calls the GetMappedFileName API to retrieve a memory-mapped image file, Process Reimaging will cause Windows OS to return the incorrect path. This impacts all Windows OS versions at the time of testing.

Figure 9 LoadLibrary FILE_OBJECT Reuse (LoadLibrary) – Process Reimaging Technique Using LoadLibrary Impacts all Windows OS Versions

2. CreateProcess (See figure 10 below)

    1. When an ESS or Application calls the GetMappedFileName API to retrieve the process image file, Process Reimaging will cause Windows OS to return the incorrect path. This impacts all Windows OS versions at the time of testing.

Figure 10 LoadLibrary FILE_OBJECT Reuse (CreateProcess) – Process Reimaging Technique using CreateProcess Impacts all Windows OS Versions

Process Manipulation Techniques Comparison

Windows Defender Process Reimaging Filepath Bypass Demo

This video simulates a zero-day malware being dropped (Mimikatz PUP sample) to disk and executed as the malicious process “phase1.exe”. Using the Process Reimaging Filepath attack vector we demonstrate that even if Defender is updated with a signature for the malware on disk it will not detect the running malicious process. Therefore, for non-EDR ESSs such as Defender Real-time Protection (used by Consumers and also Enterprises) the malicious process can dwell on a windows machine until a reboot or the machine receives a full scan post signature update.

CVSS and Protection Recommendations

CVSS

If a product uses any of the APIs listed in table 1 for the following use cases, then it is likely vulnerable:

  1. Process reputation of a remote process – any product using the APIs to determine if executing code is from a malicious file on disk

CVSS score 5.0 (Medium)  https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:N (same score as Doppelganging)

  1. Trust verification of a remote process – any product using the APIs to verify trust of a calling process

CVSS score will be higher than 5.0; scoring specific to Endpoint Security Solution architecture

Protection Recommendations

McAfee Advanced Threat Research submitted Process Reimaging technique to Microsoft on June 5th, 2018. Microsoft released a partial mitigation to Defender in the June 2019 Cumulative update for the Process Reimaging FILE_OBJECT filename changes attack vector only. This update was only for Windows 10 and does not address the vulnerable APIs in Table 1 at the OS level; therefore, ESSs are still vulnerable to Process Reimaging. Defender also remains vulnerable to the FILE_OBJECT filepath changes attack vector executed in the bypass demo video, and this attack vector affects all Windows OS versions.

New and existing Process Manipulation techniques which abuse legitimate Operating System features for defense evasion are difficult to prevent dynamically by monitoring specific API calls as it can lead to false positives such as preventing legitimate processes from executing.

A process which has been manipulated by Process Reimaging will be trusted by the ESS unless it has been traced by EDR or a memory scan which may provide deeper insight.

Mitigations recommended to Microsoft
  1. File System Synchronization (EPROCESS structures out of sync with the filesystem or File Control Block structure (FCB)
    1. Allow the EPROCESS structure fields to reflect filepath changes as is currently implemented for the filename in the VADs and EPROCESS ImageFilePointer fields.
    2. There are other EPROCESS fields which do not reflect changes to filenames and need to be updated, such as K32GetModuleFileNameEx on Windows 10 through the ImageFilePointer.
  2. API Usage (most returning file info for process creation time)
    1. Defender (MpEngine.dll) currently uses K32GetProcessImageFileName to get process image filename and path when it should be using K32GetModuleFileNameEx.
    2. Consolidate the duplicate APIs being exposed from NtQueryInformationProcess to provide easier management and guidance to consumers that require retrieving process filename information. For example, clearly state GetMappedFileName should only be used for DLLs and not EXE backing process).
    3. Differentiate in API description whether the API is only limited to retrieving the filename and path at process creation or real-time at time of request.
  3. Filepath Locking
    1. Lock filepath and name similar to lock file modification when a process is executing to prevent modification.
    2. Standard user at a minimum should not be able to rename binary paths for its associated executing process.
  4. Reuse of existing FILE_OBJECT with LoadLibrary API (Prevent Process Reimaging)
    1. LoadLibrary should verify any existing FILE_OBJECT it reuses, has the most up to date Filepath at load time.
  5. Short term mitigation is that Defender should at least flag that it found malicious process activity but couldn’t find associated malicious file on disk (right now it fails open, providing no notification as to any potential threats found in memory or disk).
Mitigation recommended to Endpoint Security Vendors

The FILE_OBJECT ID must be tracked from FileCreate as the process closes its handle for the filename by the time the image is loaded at ImageLoad.

This ID must be managed by the Endpoint Security Vendor so that it can be leveraged to determine if a process has been reimaged when performing process attribute verification.

The post In NTDLL I Trust – Process Reimaging and Endpoint Security Solution Bypass appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/in-ntdll-i-trust-process-reimaging-and-endpoint-security-solution-bypass/feed/ 0
RDP Stands for “Really DO Patch!” – Understanding the Wormable RDP Vulnerability CVE-2019-0708 https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rdp-stands-for-really-do-patch-understanding-the-wormable-rdp-vulnerability-cve-2019-0708/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rdp-stands-for-really-do-patch-understanding-the-wormable-rdp-vulnerability-cve-2019-0708/#respond Tue, 21 May 2019 21:09:35 +0000 https://securingtomorrow.mcafee.com/?p=95306

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 […]

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

]]>

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.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rdp-stands-for-really-do-patch-understanding-the-wormable-rdp-vulnerability-cve-2019-0708/feed/ 0
IoT Zero-Days – Is Belkin WeMo Smart Plug the Next Malware Target? https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/iot-zero-days-is-belkin-wemo-smart-plug-the-next-malware-target/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/iot-zero-days-is-belkin-wemo-smart-plug-the-next-malware-target/#respond Thu, 18 Apr 2019 20:14:20 +0000 https://securingtomorrow.mcafee.com/?p=94932

Effective malware is typically developed with intention, targeting specific victims using either known or unknown vulnerabilities to achieve its primary functions. In this blog, we will explore a vulnerability submitted by McAfee Advanced Threat Research (ATR) and investigate a piece of malware that recently incorporated similar vulnerabilities. The takeaway from this blog is the increasing […]

The post IoT Zero-Days – Is Belkin WeMo Smart Plug the Next Malware Target? appeared first on McAfee Blogs.

]]>

Effective malware is typically developed with intention, targeting specific victims using either known or unknown vulnerabilities to achieve its primary functions. In this blog, we will explore a vulnerability submitted by McAfee Advanced Threat Research (ATR) and investigate a piece of malware that recently incorporated similar vulnerabilities. The takeaway from this blog is the increasing movement towards IoT-specific malware and the likelihood of this unique vulnerability being incorporated into future malware.

We are rapidly approaching the one-year mark for the date McAfee ATR disclosed to Belkin (a consumer electronics company) a critical, remote code execution vulnerability in the Belkin WeMo Insight smart plug.  The date was May 21st, 2018, and the disclosure included extensive details on the vulnerability (a buffer overflow), proof-of-concept, exploit code and even a video demo showing the impact, dropping into a root shell opened on the target device. We further blogged about how this device, once compromised, can be used to pivot to other devices inside the network, including smart TVs, surveillance cameras, and even fully patched non-IoT devices such as PCs. Initially, the vendor assured us they had a patch ready to go and would be rolling it out prior to our planned public disclosure. In January of 2019, Belkin patched a vulnerability in the Mr. Coffee Coffee Maker w/ WeMo, which McAfee ATR reported to Belkin on November 16th, 2018, and released publicly at Mobile World Congress in late February. We commend Belkin for an effective patch within the disclosure window, though we were somewhat surprised that this was the prioritized patch given the Mr. Coffee product with WeMo no longer appears to be produced or sold.

The Insight smart plug firmware update never materialized and, after attempts to try to communicate further, three months later, in accordance with our vulnerability disclosure policy, McAfee ATR disclosed the issue publicly on August 21st. Our hope is that vulnerability disclosures will encourage vendors to patch vulnerabilities, educate the security community on a vulnerable product to drive development of defenses and, ultimately, encourage developers to recognize the impact that insecure code development can have.

Fast forward nearly a year and, to the best of our knowledge this vulnerability, classified as CVE-2018-6692, is still a zero-day vulnerability.  As of April 10th, 2019, we have heard of plans for a patch towards the end of the month and are standing by to confirm. We intentionally did not release exploit code to the public, as we believe it tips the balance in favor of cyber criminals, but exploitation of this vulnerability, while challenging in some regards, is certainly straightforward for a determined attacker.

IoT-Specific Malware

Let’s focus now on why this vulnerability is enticing for malicious actors.  Recently, Trend Micro released a blog observing occasional in-the-wild detections for a malware known as Bashlite. This specific malware was recently updated to include IoT devices in its arsenal, specifically using a Metasploit module for a known vulnerability in the WeMo UPnP protocol. The vulnerability appears to be tied to a 2015 bug which was patched by Belkin and was used to fingerprint and exploit WeMo devices using the “SetSmartDevInfo” action and corresponding “SmartDevURL” argument.

We can say for certain that this Metasploit module is not targeting the same vulnerability submitted by McAfee ATR, which resides in the <EnergyPerUnitCostVersion> XML field, within the libUPnPHndlr.so library.

Analysis of Bashlite and IOT Device Targets

After briefly analyzing a few samples of the malware (file hashes from the aforementioned blog), the device appears to check for default credentials and known vulnerabilities in multiple IoT devices. For example, I came across a tweet after finding reference to a password in the binary of “oelinux123”.

This IoT device is an Alcatel Mobile Wifi, which has a number of known/default passwords. Notice the top username/password combination of “root:oelinux123.” When we analyze the actual malware, we can observe the steps used to enumerate and scan for vulnerable devices.

Here is a reference from the popular binary disassembly tool IDA Pro showing the password “OELINUX123” used to access a mobile WiFi device.

The next image is a large “jump table” used to scan through and identify a range of devices or targets using known passwords or vulnerabilities.

Next is some output from the “Echobot” scanner employed by the malware used to report possible vulnerabilities in target devices from the above jump table.

The final screenshot shows a list of some of the hardcoded credentials used by the malware.

The “huigu309” password appears to be associated with Zhone and Alcatel Lucent routers. Both routers have had several known vulnerabilities, backdoors and hardcoded passwords built into the firmware.

There is no need to continue the analysis further as the point of this is not to analyze the Bashlite malware in depth, but I did think it was worth expanding on some of the capabilities briefly, to show this malware is programmed to target multiple IoT devices.

Now to the point! The simple fact that generic WeMo Metasploit modules were added to this indicates that Belkin WeMo makes an interesting enough target that an unpatched vulnerability would be compelling to add to the malware’s capabilities. Hence, we believe it is possible, perhaps even likely, that malware authors already have or are currently working on incorporating the unpatched WeMo Insight vulnerability into IoT malware. We will be closely following threats related to this zero-day and will update or add to this blog if malware embedding this vulnerability surfaces. If the vendor does produce an effective patch, it will be a step in the right direction to reduce the overall threat and likelihood of weaponizing the vulnerability in malware.

How to Protect Your Devices

As this vulnerability requires network access to exploit the device, we highly recommend users of IoT devices such as the WeMo Insight implement strong WIFI passwords, and further isolate IoT devices from critical devices using VLANs or network segmentation. McAfee Secure Home Platform users can enable whitelisting or blacklisting features for protection from malicious botnets attempting to exploit this vulnerability.

Call to Action for Vendors, Consumers and Enterprise

It should be plain to see there is some low-hanging fruit in the industry of securing IoT devices. While some of the obvious simple issues such as hardcoded credentials are unexplainable, we understand that true software vulnerabilities cannot always be avoided. However, we issue a call-to action for IoT vendors; these issues must be fixed, and quickly too. Threat actors are constantly tracking flaws which they can weaponize, and we see a prime example of this in the Bashlite malware, updated for IoT devices including Belkin WeMo. By listening to consumer’s asks for security, partnering with researchers closely to identify flaws, and having a fast and flexible response model, vendors have a unique opportunity to close the holes in the products the world is increasingly relying on. Consumers can take away the importance of basic security hygiene; applying security updates when available, practicing complex password policy for home networks and devices, and isolating critical devices or networks from IoT.  Enterprise readers should be aware that just because this is an IoT consumer device typically, does not mean corporate assets cannot be compromised.  Once a home network has been infiltrated, all devices on that same network should be considered at risk, including corporate laptops.  This is a common method for cyber criminals to cross the boundary between home and enterprise.

The post IoT Zero-Days – Is Belkin WeMo Smart Plug the Next Malware Target? appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/iot-zero-days-is-belkin-wemo-smart-plug-the-next-malware-target/feed/ 0
When the Digital Impacts the Physical https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/when-the-digital-impacts-the-physical/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/when-the-digital-impacts-the-physical/#respond Tue, 09 Oct 2018 15:00:18 +0000 https://securingtomorrow.mcafee.com/?p=91835 Cyberattacks have always been, well, cyber. Their immediate effects were on our data, our digital information, and our devices…until they weren’t. The interconnected nature of the world and the way it’s built in 2018 has brought us exciting and revolutionary innovations, but it has also been leveraged by hackers to extend the impact of a […]

The post When the Digital Impacts the Physical appeared first on McAfee Blogs.

]]>
Cyberattacks have always been, well, cyber. Their immediate effects were on our data, our digital information, and our devices…until they weren’t. The interconnected nature of the world and the way it’s built in 2018 has brought us exciting and revolutionary innovations, but it has also been leveraged by hackers to extend the impact of a cyberattack beyond the digital sphere into the physical. Pacemakers can be hacked, shocks can be sent to patients remotely. Critical infrastructure can be taken down, rendering cities powerless. Large corporations we trust with our data are violating that trust by collecting our data unknowingly, and even tracking our locations without consent. Cybercrime is no longer just cyber, and it can compromise a lot more than just data.

When you think of one’s well-being, physical health often comes to mind. Hospitals, health care, and medical tools and devices have evolved to become members of an interconnected ecosystem. Many health care systems connect to the internet to operate, the same holds true with numerous medical devices such as pacemakers. But that makes the latter part of the ”Internet of Things,” a growing collection of connected devices which are potentially vulnerable to cyberattack. In fact, there have already been reports of threats to these medical devices. Just last year, the FBI recalled half a million pacemakers, as a crucial flaw was discovered that could expose users to an attack. Additionally, security researchers recently revealed a chain of vulnerabilities in a particular pacemaker brand that an attacker could exploit to control implanted pacemakers remotely and cause physical harm to patients.

Cybercriminals have also set their sights on larger targets when it comes to hacking health care devices and institutions. We’ve seen a handful of hospitals taken offline in recent ransomware attacks, all due to the use of outdated or vulnerable systems. Some of these attacks locked patient data and made proper care unachievable for hours on end.

Hospitals are also not the only type of critical infrastructure that’s been on the victim’s end of a cyberattack. In fact, cybercriminals have recently begun hitting critical infrastructure hard and fast, with dramatic results emerging from their efforts. They’ve infamously put an entire city in the Ukraine out of power for about an hour. Then there was the Schneider Electric hack, in which cybercriminals leveraged a zero-day vulnerability within an industrial plant’s safety system for a cyberattack.

There are also cyber issues that impact our physical safety that don’t even come in the form of an attack. Lately, news has been circulating about big-name companies tracking users’ locations or data, even when certain settings are off or when the user is unaware of the action. Specifically, it was discovered that even if a user disables Location History, Google still tracks users in particular instances — whenever they open up the Maps app, scan the internet for certain things, or receive automatic weather notifications. Even smartwatches have been used recently to record and track kids’ physical location.

Ramifications such as these have changed the nature of privacy, as well as digital and physical safety as we know it. But as the threat landscape is evolving, so is the industry determined to protect innocent users everywhere.

We at McAfee are working together with our entire industry to stop these types of attacks. We’re sharing threat intelligence, resources, and research findings to ensure we put up a united front against these threats. By learning from these attacks, we’re better preparing for those to come.

We believe that together is power. And though these attacks are advanced, we know that acting together to stop them will be even more powerful.

To learn more about McAfee’s approach to protecting against advanced cyberattacks and more, be sure to check us out at @McAfee and @McAfee_Labs.

 

The post When the Digital Impacts the Physical appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/when-the-digital-impacts-the-physical/feed/ 0
McAfee Opens State-of-the-Art Security Research Lab in Oregon https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-opens-state-of-the-art-security-research-lab-in-oregon/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-opens-state-of-the-art-security-research-lab-in-oregon/#respond Wed, 22 Aug 2018 17:00:56 +0000 https://securingtomorrow.mcafee.com/?p=90950 Today we are pleased to announce the grand opening of our dedicated research lab in the Hillsboro, Oregon, office near Portland.

The post McAfee Opens State-of-the-Art Security Research Lab in Oregon appeared first on McAfee Blogs.

]]>
McAfee’s Advanced Threat Research team has operated from several locations around the world for many years. Today we are pleased to announce the grand opening of our dedicated research lab in the Hillsboro, Oregon, office near Portland. Although we have smaller labs in other locations, the new McAfee Advanced Threat Research Lab was created to serve two purposes. First, it gives our talented researchers an appropriate work space with access to high-end hardware and electronics for discovery, analysis, automation, and exploitation of vulnerabilities in software, firmware, and hardware. Second, the lab will serve as a demo facility, where the Advanced Threat Research team can showcase current research and live demos to customers or potential customers, law enforcement partners, academia, and even vendors.

The lab has been a labor of love for the past year, with many of the team members directly contributing to the final product. Visitors will have the unique opportunity to experience live and recorded demos in key industry research areas, including medical devices, autonomous and connected vehicles, software-defined radio, home and business IoT, blockchain attacks, and even lock picking! Our goal is to make vulnerability research a tangible and relatable concept, and to shed light on the many security issues that plague nearly every industry in the world.

Much of the research highlighted in the lab has been disclosed by McAfee. Links to recent disclosures from the Advanced Threat Research team:

Articles

Podcasts

Security researcher Douglas McKee prepares his demo of hacking a medical patient’s vitals. 

Onsite visitors will have the opportunity to solve a unique, multipart cryptographic challenge, painted on our custom mural wall in the lab. Those who are successful will receive an Advanced Threat Research team challenge coin! We will soon have an official video from the lab’s opening event online.

The post McAfee Opens State-of-the-Art Security Research Lab in Oregon appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-opens-state-of-the-art-security-research-lab-in-oregon/feed/ 0
Microsoft Cortana Allows Browser Navigation Without Login: CVE-2018-8253 https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/microsoft-cortana-allows-browser-navigation-without-login-cve-2018-8253/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/microsoft-cortana-allows-browser-navigation-without-login-cve-2018-8253/#respond Tue, 14 Aug 2018 17:31:48 +0000 https://securingtomorrow.mcafee.com/?p=90900 A locked Windows 10 device with Cortana enabled on the lock screen allows an attacker with physical access to the device to do two kinds of unauthorized browsing.

The post Microsoft Cortana Allows Browser Navigation Without Login: CVE-2018-8253 appeared first on McAfee Blogs.

]]>
A locked Windows 10 device with Cortana enabled on the lock screen allows an attacker with physical access to the device to do two kinds of unauthorized browsing. In the first case, the attacker can force Microsoft Edge to navigate to an attacker-controlled URL; in the second, the attacker can use a limited version of Internet Explorer 11 using the saved credentials of the victim.

In June we published our analysis of a full login bypass mechanism for all Windows 10 devices for which Cortana is enabled on the lock screen. (This is still the default option.) The discovery of the full login bypass was part of a wider research effort into what access the digital assistant Cortana might offer to an adversary when the device is locked. This post details these two additional issues; we reported them to Microsoft at the same time we reported the login bypass. The two new flaws have now been addressed as part of Microsoft’s August update. Some of the issues are also partially mitigated by modifying the answer obtained from a Bing search query.

In the first scenario, a Cortana privilege escalation leads to forced navigation on a lock screen. The vulnerability does not allow an attacker to unlock the device, but it does allow someone with physical access to force Edge to navigate to a page of the attacker’s choosing while the device is still locked. This is not a case of BadUSB, man in the middle, or rogue Wi-Fi, just simple voice commands and interacting with the device’s touchscreen or mouse.

Several months ago, researchers from Israel demonstrated a similar attack using a BadUSB device, masquerading as a network interface card to inject content into trusted HTTP sites while using Cortana to force navigation. Microsoft has since removed this ability to navigate directly to a domain and instead now opens a search in Bing over HTTPS to the domain in question. Some of our findings could also be combined with a BadUSB approach.

We explored whether one could still force navigation to an attacker-controlled page. In short, yes, one can, but it does take some extra effort.

Cortana is very helpful when it comes to defining terms, or looking up corporations, movies, artists, or athletes. She can even do math. However, Cortana’s behavior and the answers she gives are affected by the way you ask a question. For example, if you were to ask the colloquial question “Hey Cortana, what is McAfee?” you would get a quick answer directly from a Bing search. If, however, you asked only “Hey Cortana, McAfee,” you would receive a more detailed response, including links to various trusted sites. These include Wikipedia, Twitter, Facebook, LinkedIn, and the “official website” (more later on this important link).

Cortana’s answers to similar but not identical queries about “McAfee.”

It is surprising that links are offered and clickable when the device is locked. If you start your favorite network sniffer or man-in-the-middle proxy, you will see that the links are visited as soon as the user clicks on them, irrespective of the device’s locked status.

This means we can force navigation to a website (though not yet the one we want) when the device is locked. However, we have seen that Cortana can be picky in how she offers results. Bing must already know these results, and most links are known trusted sites.

That leaves us with the official website. You might recognize this terminology: It is a common link presented by Wikipedia. If you look at the bottom of a Wikipedia article, you will often find a link to an official website.

Could Cortana just use Wikipedia as a trusted source? After a few delightful conversations with her, we can confirm that the official website for items she refers from Wikipedia is indeed the same as the Official Website link on Wikipedia. There is no one-to-one correlation on Wikipedia’s official website for Cortana to display the corresponding link. We assume there is some possible weighting of the domain name or logic in the Bing output that influences Cortana’s displayed links.

We can leverage this information to craft a fake Wikipedia entry, add enough content to get the review to succeed, add an official website link, and see what Cortana presents. Wikipedia reviewers do a pretty good job of vetting content, but we also need Bing to become aware of the entry so that Cortana could offer the answer and the link. Because of the time-dependent factor of the approach (and the ethical aspect of tampering with Wikipedia content in a malicious way), we decided to take a different path—although others could use this attack vector.

Instead of creating an entry in Wikipedia, making sure that Bing indexes it and that Cortana provides the official website link, we opted for an alternative. We can instead hunt Wikipedia for unmaintained or dead official website links. Fortunately for us, Wikipedia maintains a list of “dead links” and “permanent dead links.” A search for “Xbox Linux” looks like this:

To aid in our hunt, Wikipedia has a fairly robust search engine that accepts regular expressions.

With just a little bit of tinkering we come up with the following search:

insource:/\{official (website)?\|https?\:\/\/[^}]+\.com\/[^}]\}\}\{\{dead link/

This is neither an exhaustive list, nor the most efficient regular expression, but it does find some candidates without triggering the Wikipedia query timeout.

The next step is to write a script to parse the output, grab a list of domains, and check whether they are actually vacant. Many of them are still registered but do not serve any content; others are live despite the “dead link” tag. We end up with a list of domains, some more expensive than others, that are vacant.

What will Cortana display for each of these Wikipedia entries? One after another, we ask. Retrospectively, writing a text-to-speech script would have been faster. Cortana answers surprisingly well to other digital speech synthesizers.

Many of the entries do not provide the official website link, but some do. It is annoying that the way you ask the question interferes with the results. Not only is the phrasing of the question important; the decision of whether to dictate a word or spell it out may change the answer. To obtain the answer you want from Cortana, you may have to combine both approaches.

For example, we asked “Hey Cortana, what is Miss Aruba?” We saw, while the device was locked, the following answer:

The official website link points to “hxxp://www.missaruba.aw.” A quick search shows the domain is still available.

In conclusion, we now have Wikipedia articles for which Cortana will display an official website link, and for which the domain is available for purchase. After spending $11.99 for a cheaper domain, we own one.

Although it took some regular-expression authoring, some scripting, and buying a domain, this method was faster and more satisfying than waiting for Bing to publish and index a new Wikipedia entry.

After this setup, what can we accomplish? We can ask Cortana (either via the interactive icon or vocal command “Hey Cortana”) to conduct a search while the device is locked. When she replies, we can click on the official website link and observe as Edge retrieves the content while the device remains locked.  To put a malicious spin on this unauthorized access, we have at least one straightforward option. We could install the latest exploit kit on our newly acquired domain and infect any locked Windows 10 PC with Cortana enabled without ever logging in. This attack could occur at a coffee shop, retailer, bank, or against targeted individuals. This configuration is the default on Windows, and our research has shown that many users never disable Cortana from the lock screen.

Digital voice assistants can be useful, but they must also be considered an attack vector. Although some may think this is a “noisy” vector, not applicable when stealth is required, you can employ techniques such as the DolphinAttack, which uses inaudible voice commands to close an air gap. Or if you have physical access to the device, a $5 3.5mm-jack cable will do as well.

An inexpensive 3.5mm-jack cable for silent interaction.

How can we protect against this attack vector? You can disable Cortana on your lock screen. Microsoft should not allow navigation to untrusted websites until it receives permission from the authenticated user, confirming on login that the user wants to visit a site.

Self-service Internet Explorer from the Windows lock screen

When we investigate a technology, we sometimes find that our initial findings are less substantial than what we learn after further investigation. Our research into Cortana and this attack surface was no different. What if one could surf the web freely with a full-fledged browser such as Internet Explorer 11, with access to cached credentials and autocomplete on a locked Windows 10 device? All thanks to Cortana? That could be much more impactful than browsing to just one URL.

That is possible with Cortana’s skills. It makes sense that Cortana offers skills similar to those of Amazon’s Alexa or Google Assistant. But it does not make sense to offer these skills directly from the lock screen when they are not yet configured.

One example is the “Real Estate Search” skill. While conversing with Cortana to analyze the capabilities she could offer an attacker, we found that she occasionally offered to try skills, including Real Estate Search.

One easy trigger is to ask “Hey Cortana, I want to sell my house.” This leads to the following screen:

If we click “Real Estate Search,” we get a login screen. Instead of logging in, let’s look at the other links offered by the interface. In the current case, the “Privacy Policy” link seems interesting:

Cortana’s skill login screen with a link to Privacy Policy.

Opening the link, we see a lengthy policy. If we scroll to the bottom of the page, we discover a few social media icons:

Privacy policy screen with links to social media sites.

These icons are indeed links, allowing us to reach Facebook or YouTube, and from there the rest of the Internet:

Reaching Facebook from the lock screen of a Windows 10 system.

Let’s summarize. You left for lunch with your new Windows Surface Book locked on your desk. Cortana is on by default on your lock screen. Your disk is encrypted. What could go wrong?

Anybody who has physical access to your locked device can start browsing the web. What if someone were to navigate to a work-unfriendly website from your device, or post inflammatory comments in a public forum that could be attributed to your device’s IP address?

A device-specific attribution would be bad, but could you use the same method to post or access something from a real person’s name or account? We next investigated which browser is being used? Is it a Cortana custom browser? Is it a sandboxed Microsoft Edge? It is actually a customized Internet Explorer 11 restricted engine running in the context of AuthHost.exe. (We will publish another analysis on this limited “browser” because its properties and lack of security mechanisms could become handy for red teams.)

This is the Internet Explorer engine and not the full browser, though both JavaScript and cookies are enabled. Worse, this incarnation shares the autocomplete and credentials saved in the context of the current user’s Internet Explorer session.

Thus in addition to posting a comment on a public forum from another user’s device while the device is locked, you can also impersonate the user thanks to its cached credentials.

One potential attack scenario arises if a corporation offers a mechanism to reset Windows credentials via a web server but does not require users to reenter the old password. One could simply navigate to the reset link, input a new password, exit the limited navigator, and unlock the device with the newly set password, all from a locked computer.

We have explored a couple of attack scenarios and security issues in this post, and we will continue our investigation into Cortana and other digital assistants as an attack vector. Your best mitigation at this point is to turn off Cortana on the lock screen. Here is a good tutorial on how to do so.

 

The post Microsoft Cortana Allows Browser Navigation Without Login: CVE-2018-8253 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/microsoft-cortana-allows-browser-navigation-without-login-cve-2018-8253/feed/ 0
Unintended Clipboard Paste Function in Windows 10 Leads to Information Leak in RS1 https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/unintended-clipboard-paste-function-in-windows-10-leads-to-information-leak-in-rs1/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/unintended-clipboard-paste-function-in-windows-10-leads-to-information-leak-in-rs1/#respond Thu, 14 Jun 2018 21:34:15 +0000 https://securingtomorrow.mcafee.com/?p=89683 The McAfee Labs Advanced Threat Research team has been investigating the Windows 10 platform. We have submitted several vulnerabilities already and have disclosed our research to Microsoft. Please refer to our vulnerability disclosure policy for further details or the post from earlier this week on Windows 10 Cortana vulnerabilities. Early last year, a trivial “information leak” […]

The post Unintended Clipboard Paste Function in Windows 10 Leads to Information Leak in RS1 appeared first on McAfee Blogs.

]]>
The McAfee Labs Advanced Threat Research team has been investigating the Windows 10 platform. We have submitted several vulnerabilities already and have disclosed our research to Microsoft. Please refer to our vulnerability disclosure policy for further details or the post from earlier this week on Windows 10 Cortana vulnerabilities.

Early last year, a trivial “information leak” was reported in Windows 10. This technique no longer works on most current builds of Windows 10, but a variation of this simple method works quite well on some versions of Windows 10, specifically RS1 (RedStone 1).

The issue is simple to describe and execute. For a local attack, you can use a physical keyboard; if there is a network vector that would allow one to remotely reach the Windows login screen (such as RDP), you can use the software-based keyboard accessible from the lock screen. On all versions of Windows 10, the “paste” function appears to be intentionally forbidden from the Windows lock screen, including the “Hey Cortana” function. The original finding demonstrated CTRL+V could be used to paste clipboard contents. This is now disabled, even on RS1. However, we have found a way to bypass this restriction using the keyboard shortcut CTRL + SHIFT + INSERT, allowing us to access in plain text the clipboard contents, whatever they may be. While we are continuing to explore this technique to force-copy functions (and access arbitrary content), for now we can access whatever happens to be copied. In the demo this is a password allowing login.


The post Unintended Clipboard Paste Function in Windows 10 Leads to Information Leak in RS1 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/unintended-clipboard-paste-function-in-windows-10-leads-to-information-leak-in-rs1/feed/ 0
Want to Break Into a Locked Windows 10 Device? Ask Cortana (CVE-2018-8140) https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/want-to-break-into-a-locked-windows-10-device-ask-cortana-cve-2018-8140/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/want-to-break-into-a-locked-windows-10-device-ask-cortana-cve-2018-8140/#respond Tue, 12 Jun 2018 17:15:28 +0000 https://securingtomorrow.mcafee.com/?p=89585 June’s “Patch Tuesday” (June 12) is here, but it is likely many Windows 10 users have not yet applied these updates.

The post Want to Break Into a Locked Windows 10 Device? Ask Cortana (CVE-2018-8140) appeared first on McAfee Blogs.

]]>
June’s “Patch Tuesday” (June 12) is here, but it is likely many Windows 10 users have not yet applied these updates. If you have not, just be sure not to leave your laptop lying around! The patches in this cycle fix a code execution vulnerability using the default settings for Windows 10 and the “Cortana” voice assistant. We’ll detail how this vulnerability can be used to execute code from the locked screen of a fully patched Windows 10 machine (RS3 at the time of our original submission, and confirmed on RS4 prior to this patch cycle). The vulnerability was submitted to Microsoft as part of the McAfee Labs Advanced Threat Research team’s responsible disclosure policy, on April 23. Attribution for this vulnerability submission goes to Cedric Cochin, Cyber Security Architect and Senior Principal Engineer.

In this post, we will address three vectors of research that have been combined by Microsoft and together represent CVE-2018-8140. The first of these is an information leak, but we’ll culminate with a demo showing full code execution to log in to a locked Windows device!

Using “Hey Cortana!” to Retrieve Confidential Information

Personal digital assistants such as Siri, Alexa, Google Assistant, and Cortana have become commodities in many technologically inclined houses. From telling jokes, to helping with the grocery list, to turning on the kitchen lights, these robotic voices are beginning to feel oddly more and more personal as they expand their roles in our daily lives. However, we should consider the increased risk of built-in digital personal assistants when looking at new attack vectors for laptops, tablets, and smartphones. Our research on Microsoft’s Cortana voice assistant began after reading about the “BadUSB” attacks demonstrated by industry researchers. We decided to take this a step further and ended up finding and reporting to Microsoft several issues related to Cortana.

If you have spoken with Cortana, you may have noticed that “she” is very helpful for a number of simple tasks: providing definitions, or looking up corporations, movies, artists, or athletes. She can even do math! In Windows 10, on the most recent build at the time of submission, we observed that the default settings enable “Hey Cortana” from the lock screen, allowing anyone to interact with the voice-based assistant. This led to some interesting behavior and ultimately vulnerabilities allowing arbitrary code execution.

We begin this analysis with a quick look into Windows indexing. If you have ever opened the advanced view of the Windows Indexing control panel, and navigated to the File Types tab, you will see a long list of file extensions. For each of them you will find details about the associated filter used by the indexing process. Essentially you have the “file properties filter” and several other filters that could all be summarized as “file properties and file content filter.”

This means the index process will crack open the files and index their content, including some strings present in these documents. Let’s keep that in mind for later as we continue.

Using this knowledge, we wanted to try to access the same menu that you would see when using a Cortana search on an unlocked device.

This will come as a surprise and lies at the core of all the issues we found, but simply typing while Cortana starts to listen to a query on a locked device will bring up a Windows contextual menu, as shown below:

On top: the result of typing “pas” in the Cortana search field on an unlocked computer.
Above: the result of asking “Hey Cortana, P A S” and using a whitespace keyboard sequence.

In the preceding example, we queried Cortana for the term pas, no preamble to the question, just speaking the three letters, P. A. S. Why not “pass”? Because Cortana can be quite picky with verbal statements and there is no dictionary definition for “pass,” leading to Cortana inviting us to continue in Edge after unlocking the device. Alternatively, instead of issuing a verbal statement, we could click on the “tap and say” button and just start typing this text, for example.

We now have a contextual menu, displayed on a locked Windows 10 device. What could go wrong?

Remember that all the results presented by Cortana come from indexed files and applications, and that for some applications the content of the file is also indexed. Now we can simply hover over any of the relevant matches. If the match is driven by filename matching, then you will be presented with the full path of the file. If the match is driven by the file content matching, then you may be presented with the content of the file itself.

Keep in mind that the entire user folder structure is indexed, which includes the default location for most documents but also for mappings like OneDrive.

Example of data leakage using voice command with Cortana and the whitespace keyboard sequence.

Armed with this knowledge, you can use your imagination to come up with specific keywords that could be used to start harvesting confidential information from the locked device.

Code Execution from the Windows Lock Screen (User Interaction May be Required)

Next, we asked the question: Could we go a step further and get code execution in the context of the authenticated user? Remember we are using only a combination of voice commands and mouse/touchpad/touchscreen to gain access to the contextual menu at this point. We observed that just by hovering over a file, the full path or content of the file would be displayed. What happens if we were to click on it? That depends on the target. If the file being opened is an application or an executable (such as notepad or calc.exe), the file will run and be accessible only after the user properly logs in. If it is a document, script, or text file, it will be opened by an editor instead of being executed. At this point we can execute various preloaded Windows utilities such as calculator, but we cannot pass any parameters to the command line. We can open scripts including PowerShell, but instead of being executed, they will be opened in a text editor (notepad). The lack of parameters is a limitation for a “live off the land” attack, which uses current tools and content to achieve a malicious purpose; however, there are plenty of malicious activities that could be performed even with these restrictions. For example, many uninstallers will happily remove software without any need for parameters.

Let’s return to our goal: code execution from the lock screen. The only requirement for something to show up in the contextual menu is for it to be indexed.

Public folders indexed by default.

There are multiple ways for an unauthenticated attacker to get results to show up in the index of an authenticated user. One method relies on OneDrive. As the root of the OneDrive directory structure is in the user folder, all the OneDrive content is indexed by default. Basically, if you ever share a folder or file with “edit” rights, the person you share it with, as well as any other recipients of a forwarded link, can now drop a file that will be indexed. With the file indexed we have multiple options to proceed.

Option 1: Drop an Executable File

This method assumes you can write an executable file to the disk; it does not require you to have executed it. Via a phishing attack or another vulnerability, an attacker could drop a backdoor (for example, Cobalt Strike Beacon or Meterpreter) and be in business. If you need to execute the payload as an administrator, you can simply right-click (for a touchscreen this is a longer-hold screen press) and select “Run as administrator.”

When running applications that do not have the Auto-Elevate Privilege, you will trigger a user account control (UAC) prompt and nothing will execute. This could still result in a valid attack because users rarely check the content of the prompt and often proceed through the warning dialog box. The attacker would have to execute the program, and then wait for the authenticated user to log in and finish the job. If the application has auto-elevate privileges, there will be no UAC prompt and the application will execute at high integrity.

This is interesting behavior, but on its own not a very likely attack scenario, so let’s continue to explore our options. Why not simply use a USB key to drop the payload because we have physical access? The content of the USB key is not indexed, so it would not be presented as a result of the search query (although there are other ways to use a USB device; see below).

Option 2: Drop a non-PE Payload

Portable executable (PE) backdoors are great, but can we gain execution with a non-PE payload, for example, a PowerShell script?  We can use the same right-click capability to assist, but with a small twist. The right-click menu is not always the same, even for a given file type.

When you ask Cortana about “PS1,” you will be presented with your indexed PowerShell scripts. A right click will allow you to “open file location” or “copy full path,” but with no means of execution.

If you click on the file as we already mentioned, the file will open in edit mode. Curiously, it will not open the default editor (PowerShell ISE) for PowerShell scripts; instead, it will open the script in notepad. We assume this was intended as a security measure because notepad cannot execute scripts, unlike PowerShell ISE.

The default right-click menu for PS1 files.

Remember we mentioned that Cortana changes results based on your input query? When properly logged in, if you ask Cortana about “txt” using the query “Hey Cortana” followed by the letters “T,” “X,” “T,” she will present you with text documents, Notepad, and the most recent documents open by Notepad. Yet the right-click menu for items in the Recent category is different than the right-click menu for the same item in the Documents category.

At top:the context menu for a Recent item; above: the context menu for a Document item.

We follow a three-step process:

  • Land a PowerShell script in a location that will be indexed
    • Public folder, public share, or OneDrive
  • Execute a search query that will show the document and click on it
    • “Hey Cortana, PS1”
    • Select the PowerShell script you just indexed and left click
    • The PowerShell script opens in Notepad
  • Execute a search query that will show the recent documents, right click, and…
    • Using Cortana, type or search in the contextual menu for “txt”
    • Right click on the PowerShell script in the Recent category under the Apps tab at the top (not Documents)
    • Click “Run with PowerShell”

“Run with PowerShell” right-click menu option for Recent items.

We now have local code execution with the payload of our choosing, without any exploit, even if the device is encrypted, on an up-to-date locked Windows 10 device.

This technique helps us understand some of the differences between apps, documents, extensions, and the way Windows handles them from a locked or unlocked screen. Yet it probably does not represent much of a real-world attack vector. Then again, we are not finished.

Logging into a Locked Device with no User Interaction

Finally, we have local code execution, but with some real limitations. We need to get our payload indexed but we cannot pass command-line parameters. This could be a limiting factor for our PowerShell attack vector because the execution policy may prevent its execution, and without command-line parameters we cannot pass an “-ExecutionPolicy Bypass” (or any other flavor). We would also have to find a way to land a PS1 script on the victim’s box, and have remote access to the physical machine or the login screen.

The techniques we have described so far are far too complicated compared with the simplicity and effectiveness of what comes next.

You recall the use of the keyboard-timing sequence to trigger the contextual search menu from a locked screen while querying Cortana. Any keystroke can trigger the menu from the time when Cortana begins to listen to when the answer is displayed. Press any key at this point; we like to use the spacebar because you cannot backspace and Windows will nicely ignore or trim out the space in its text results anyways. Invoke keyboard input too early or before Cortana is listening and you will be prompted to enter your password; invoke too late and Cortana goes back to sleep or returns normal results without a context menu.

It is not very intuitive to use the keyboard in addition of voice commands, but you can type your search the same way you do on an unlocked device, assuming that you triggered Cortana to listen.

The following screenshot demonstrates this behavior:

  • Trigger Cortana via “Tap and Say” or “Hey Cortana”
  • Ask a question (this is more reliable) such as “What time is it?”
  • Press the space bar, and the context menu appears
  • Press esc, and the menu disappears
  • Press the space bar again, and the contextual menu appears, but this time the search query is empty
  • Start typing (you cannot use backspace). If you make a mistake, press esc and start again.
  • When done (carefully) typing your command, click on the entry in the Command category. (This category will appear only after the input is recognized as a command.)
  • You can always right click and select “Run as Administrator” (but remember the user would have to log in to clear the UAC)

You can use the following example of a simple PowerShell command to test. Enjoy the soothing beeps that demonstrate code execution from a locked device.

What can we do at this point? You name it. Our demo shows a password reset and login on a Windows 10 build, using only this simple technique.

The easiest mitigation technique, in the absence of patching the device (which we strongly recommend), is to turn off Cortana on the lock screen. This week’s Patch Tuesday from Microsoft contains fixes for these issues under CVE-2018-8140.

This concludes our examination of Cortana (at least for now). The McAfee Advanced Threat Research team has a fundamental goal of eliminating critical threats to the hardware and software we use; this month’s patch is a clear step toward furthering that goal. The attack surface created by vocal commands and personal digital assistants requires much more investigation; we are just scratching the surface of the amount of research that should be conducted in this critical area.

A team of several independent researchers also discovered and disclosed this vulnerability around the time of our submission. Additional credit for this discovery goes to: Ron Marcovich, Yuval Ron, Amichai Shulman and Tal Be’ery. Their names are also on the Microsoft disclosure page.

The post Want to Break Into a Locked Windows 10 Device? Ask Cortana (CVE-2018-8140) appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/want-to-break-into-a-locked-windows-10-device-ask-cortana-cve-2018-8140/feed/ 0
Syn/Ack Unique Proactive Protection Technique https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/syn-ack-unique-proactive-protection-technique/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/syn-ack-unique-proactive-protection-technique/#respond Fri, 11 May 2018 20:00:10 +0000 https://securingtomorrow.mcafee.com/?p=88828 McAfee’s Advanced Threat Research team has performed analysis on samples of Syn/Ack ransomware implementing Process Doppelgänging.  For those who are concerned about the potential impact of this ransomware but are currently unable to implement McAfee product protections, we have found a simple but interesting alternative method.  Prior to encryption and ransom, the malware first checks […]

The post Syn/Ack Unique Proactive Protection Technique appeared first on McAfee Blogs.

]]>
McAfee’s Advanced Threat Research team has performed analysis on samples of Syn/Ack ransomware implementing Process Doppelgänging.  For those who are concerned about the potential impact of this ransomware but are currently unable to implement McAfee product protections, we have found a simple but interesting alternative method.  Prior to encryption and ransom, the malware first checks if one of several hardcoded keyboards or languages is installed on the target machine.  If found, the malicious code will terminate, effectively resulting in an extremely simple “patch” of sorts. We have tested the following steps to be effective on several versions of Windows 7 and theoretically on Windows 10 – preventing the malware from encryption and ransom.  These steps can be taken proactively.  Due to limited scope of testing at this time, this technique may not work on all systems, release versions, and configurations.

Windows 7 – Adding Keyboard Layout:

Control Panel > Clock, Language, and Region > Region and Language > Keyboards and Languages

Click the “Change Keyboards” tab

In the Installed Services section click “add”

Select Keyboard – For example: Russian (Russia) > Keyboard > Russian

Click “Ok”

Click “Apply”

Click “Ok”

Here is the list of keyboards layouts you can add – any will suffice:

  • Armenian
  • Azeri, (Cyrillic, Azerbaijan)
  • Belarusian
  • Georgian
  • Kazakh
  • Ukrainian
  • Uzbek (Cryillic, Uzbekistan)
  • Uzbek (Latin,Uzbekistan)
  • Russian
  • Tajik

Windows 10 – Adding Language Support:

Control Panel > Language > Add a language

  • Armenian
  • Azeri, (Cyrillic, Azerbaijan)
  • Belarusian
  • Georgian
  • Kazakh
  • Ukrainian
  • Uzbek (Cryillic, Uzbekistan)
  • Uzbek (Latin,Uzbekistan)
  • Russian
  • Tajik

That’s all it takes!  Please note – this should not be considered a fully effective or long-term strategy.  It is highly likely the malware will change based on this finding; thus, we recommend the McAfee product protections referenced above for best effect.

The post Syn/Ack Unique Proactive Protection Technique appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/syn-ack-unique-proactive-protection-technique/feed/ 0
Inside the Capabilities and Detection of UDPoS Malware https://securingtomorrow.mcafee.com/business/inside-capabilities-detection-udpos-malware/ https://securingtomorrow.mcafee.com/business/inside-capabilities-detection-udpos-malware/#respond Sat, 17 Feb 2018 00:18:40 +0000 https://securingtomorrow.mcafee.com/?p=84569 Imagine a job that changes every day of your life, where you get to do something new each week – that’s what it’s like working in the cybersecurity industry. For me, this is ideal—smarter adversaries, new challenges, and the constant struggle to predict and prepare for the future of security in information technology makes this feel […]

The post Inside the Capabilities and Detection of UDPoS Malware appeared first on McAfee Blogs.

]]>
Imagine a job that changes every day of your life, where you get to do something new each week – that’s what it’s like working in the cybersecurity industry. For me, this is ideal—smarter adversaries, new challenges, and the constant struggle to predict and prepare for the future of security in information technology makes this feel a lot less like work. However, it’s important to remember that we do this only because people are getting hurt, often literally. And that’s a sobering and humbling perspective. In many scenarios, a successful campaign can have drastic effects on the victims’ lifestyles and finances. In today’s example, the victims, point-of-sale systems, are being attacked by a POS malware and are being targeted for identity and financial theft.

This particular attack leveraged a POS malware dubbed UDPoS, aptly named for its somewhat uncommon data exfiltration method over UDP, specifically via DNS queries. Although this malware is definitely not the first of its kind (see Multigrain POS malware, DNSMessenger), it certainly is an uncommon technique, and intelligent in that many organizations deprioritize DNS traffic for inspection as compared to HTTP and FTP. Coupled with the fact that UDPoS allegedly leverages a popular remote desktop service known as LogMeIn, and you have a malware campaign that could have a broad reach of victims (in this case unpatched or dated POS systems), and a unique ability to avoid detection for data exfiltration.

Although uncommon, and perhaps somewhat covert in its ability to transmit data over DNS, this malware does offer an upside for defenders — attackers will continue to use protocols which do not employ encryption. The move to SSL or other encryption methods for data exfiltration has been surprisingly inconsistent, meaning detection is relatively simple. This makes the need for communication and visibility of these kinds of techniques essential.

As defenders, McAfee’s Advanced Threat Research team actively monitors the threat landscape and tracks both new and current techniques for every stage of malware—from reconnaissance to infection, lateral movement, persistence, command and control, and exfiltration. We will stay closely tuned to determine if this technique grows in popularity or evolves in capabilities.

We are constantly playing a game of cat and mouse with the adversaries. As we adapt, protect, and attempt to predict new methods of malicious activity, we can be certain the same efforts are being made to evade and outsmart us. Our challenge as a security community is to work together, learn from each other, and apply these learnings toward recognizing and mitigating new threats, such as the DNS exfiltration method employed by UDPoS.

To learn more about UDPoS malware and others like it, be sure to follow @McAfee and @McAfee_Labs on Twitter.

The post Inside the Capabilities and Detection of UDPoS Malware appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/inside-capabilities-detection-udpos-malware/feed/ 0
Trivial Software Flaws Continue to Plague Networked Devices https://securingtomorrow.mcafee.com/business/trivial-software-flaws-continue-plague-networked-devices/ https://securingtomorrow.mcafee.com/business/trivial-software-flaws-continue-plague-networked-devices/#respond Thu, 11 Jan 2018 01:46:08 +0000 https://securingtomorrow.mcafee.com/?p=83674 Western Digital My Cloud NAS Devices Contain Multiple Vulnerabilities It’s 2018, but it feels like 2008.  I often reflect on how relatively simplistic the attack surface of nearly everything was just 10 years ago, and how much we’ve evolved since then.  I remember writing exploits for trivial buffer overflows without having to deal with exception […]

The post Trivial Software Flaws Continue to Plague Networked Devices appeared first on McAfee Blogs.

]]>
Western Digital My Cloud NAS Devices Contain Multiple Vulnerabilities

It’s 2018, but it feels like 2008.  I often reflect on how relatively simplistic the attack surface of nearly everything was just 10 years ago, and how much we’ve evolved since then.  I remember writing exploits for trivial buffer overflows without having to deal with exception handling, address randomization, stack and heap execution protections, and many other significant enhancements to operating systems, browsers and software in general.  As the years passed, we started to see software vendors making tangible progress in the areas of secure coding and vulnerability mitigations.  The most popular exploits tended to be in the browser space, and as such we saw an increasingly rapid response from browser vendors over the years as they struggled to gain or maintain market share in an aggressively contested market.  With the evolution of sandboxing and containerization, popular browsers such as Internet Explorer and Chrome began to raise the bar on what it took to execute malicious code.  Bypass mitigations, such as MemGC in the Microsoft Edge browser were implemented to reduce the number of trivial use-after-free vulnerabilities.  Operating systems have been hardened with new features such as VBS in Windows 10 (no not Visual Basic Scripting) to provide virtualization-based security for protection of critical systems and data.  It would be great if I could just end this discussion here, and we could all go home feeling great about the future of information security.  Unfortunately, not everyone is aboard this train.  Specifically, device manufacturers continue to deprioritize the necessity of secure code in order to get faster, larger and more feature-rich products to market quickly.

Western Digital is by no means any worse an offender in this area than others, but after reading the latest vulnerability disclosures in its ubiquitous network storage device known as My Cloud, I felt it was necessary to provide some basic insight to the industry about the implications and effects of insecure software development.  The principal problem is not that these devices contain vulnerabilities; even software vendors such as Apple, which pours millions of dollars and dedicated security teams into securing its operating system, have been bitten (pun intended) by asinine security flaws.  The High Sierra empty password root authentication bypass is a good example of this.

No, the problem lies in the complete lack of interest in developing secure code.  Even someone with zero software development experience could probably look at the following code and see the issue; spoiler alert, it’s a classic backdoor:

It leads me to ask the simple question – how are hardcoded backdoors still a thing?  Even if you can get past the myriad of early-millennium-style vulnerabilities reported in this disclosure, why won’t device manufacturers make the relatively small investment to review the code of the products they are selling worldwide?  Automated tools exist for this, and even a junior-level security practitioner could likely uncover some of these flaws.  Every year brings another collection of similar disclosures, yet the bar stays the same.  Simple format string abuse, rudimentary authentication bypasses, command injections and buffer overflows just to name a few.  Of equal importance, beyond simple coding errors, is that the basic concept of designing in a backdoor or adding one to an existing design is a well-known mistake. Resources such as IEEE’s Center For Secure Design’s “Avoiding the Top 10 Security Design Flaws” have been readily available for years.

I think a big part of the problem is the sheer noise.  You’d be hard pressed to find a software or device manufacturer out there who hasn’t been exposed to some negative press based on vulnerabilities reported in its products.  After enough exposure, consumers subconsciously begin to tune this noise out and it becomes the de facto standard for the products they buy; a “tax”, if you will, where they carry much of the risk, in this case the potential theft of personal data and privacy.

It begs the question of what can be done to improve this process and move the industry as a whole towards better security practices.  We’d like to challenge vendors to invest in secure development, code review and patching and mitigation strategies.  At McAfee, we try our best to practice what we preach.  We’ve made our own mistakes, and we’ve adapted from those experiences in an ongoing effort to fundamentally improve the way we build products.  It’s also time that consumers demand more from vendors; ultimately, the consumer carries the most significant tool of all, your decision about which products you buy and your mandate for security accountability.  Within McAfee’s Advanced Threat Research team, we firmly believe in the process of responsible disclosure and the openness of the research community in finding and reporting similar issues.  Whenever possible, we will continue to work directly with vendors who answer this call, in order to find and effectively eliminate vulnerabilities through the disclosure process.

Devices such as Western Digital’s My Cloud may fall under the purview of a consumer economy that pushes for cheaper technology with an abstract expectation of “security”. Still, software security is at the point where the “rubber meets the road”, where theory turns into practice which in turn is delivered in the devices that we use and hope we can trust.  Only with increased visibility and a shared set of priorities can we make hardcoded backdoors and other trivial security flaws truly, a thing of the past.

The post Trivial Software Flaws Continue to Plague Networked Devices appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/trivial-software-flaws-continue-plague-networked-devices/feed/ 0