Aug 14 2018

Microsoft Cortana Allows Browser Navigation Without Login: CVE-2018-8253

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.

Aug 11 2018

80 to 0 in Under 5 Seconds: Falsifying a Medical Patient’s Vitals

The author thanks Shaun Nordeck, MD, for his assistance with this report.

With the explosion of growth in technology and its influence on our lives, we have become increasingly dependent on it. The medical field is no exception: Medical professionals trust technology to provide them with accurate information and base life-changing decisions on this data. McAfee’s Advanced Threat Research team is exploring these devices to increase awareness about their security.

Some medical devices, such as pacemakers and insulin pumps, have already been examined for security concerns. To help select an appropriate target for our research, we spoke with a doctor. In our conversations we learned just how important the accuracy of a patient’s vital signs is to medical professionals. “Vital signs are integral to clinical decision making” explained Dr. Shaun Nordeck. Bedside patient monitors and related systems are key components that provide medical professionals with the vital signs they need to make decisions; these systems are now the focal point of this research.

Exploring the attack surface

Most patient monitoring systems comprise at minimum of two basic components: a bedside monitor and a central monitoring station. These devices are wired or wirelessly networked over TCP/IP. The central monitoring station collects vitals from multiple bedside monitors so that a single medical professional can observe multiple patients.

With the help of eBay, we purchased both a patient monitor and a compatible central monitoring station at a reasonable cost. The patient monitor monitored heartbeat, oxygen level, and blood pressure. It has both wired and wireless networking and appeared to store patient information. The central monitoring station ran Windows XP Embedded, with two Ethernet ports, and ran in a limited kiosk mode at start-up. Both units were produced around 2004; several local hospitals confirmed that these models are still in use.

The two devices offer a range of potential attack surfaces. The central monitoring station operates fundamentally like a desktop computer running Windows XP, which has been extensively researched by the security community. The application running on the central monitoring station is old; if we found a vulnerability, it would likely be tied to the legacy operating system. The patient monitor’s firmware could be evaluated for vulnerabilities; however, this would affect only one of the two devices in the system and is the hardest vector to exploit. This leaves the communication between the two devices as the most interesting attack vector since if the communication could be compromised, an attack could possibly be device independent, affecting both devices by a remote attack. Given this possibility, we chose networking as the first target for this research. Dr. Nordeck confirmed that if the information passing to the central monitoring system could be modified in real time, this would be a meaningful and valid concern to medical professionals. Thus the primary question of our research became “Is it possible in real time to modify a patient’s vitals being transmitted over the network?”

Setup

When performing a vulnerability assessment of any device, it is best to first operate the device as originally designed. Tracking vital signs is the essence of the patient monitor, so we looked for a way to accurately simulate those signs for testing. Many hardware simulators are on the market and vary drastically in cost. The cheapest and easiest vital sign to simulate turned out to be a heartbeat. For less than $100 we purchased an electrocardiogram (ECG) simulator on eBay. The following image illustrates our test network:

In our test bed, the patient monitor (left), central monitoring station (right), and a research computer (top) were attached to a standard switch. The research computer was configured on a monitor port of the switch to sniff the traffic between the central monitoring device and the patient monitor. The ECG simulator was attached to the patient monitor.

Reconnaissance

With the network configured, we turned to Wireshark to watch the devices in action. The first test was to boot only the central monitor station and observe any network traffic.

In the preceding screenshot a few basic observations stand out. First, we can see that the central station is sending User Datagram Protocol (UDP) broadcast packets every 10 seconds with a source and destination port of 7000. We can also see clear-text ASCII in the payload, which provides the device name. After collecting and observing these packets for several minutes, we can assume this is standard behavior. Because the central station is running on a Window XP embedded machine, we can attempt to verify this information by doing some quick reverse engineering of the binaries used by the application. After putting several libraries into Interactive Disassembler Pro, it is apparent that the symbols and debugging information has been left behind. With a little cleanup and work from the decompilers, we see the following code:

This loop calls a function that broadcasts Rwhat, a protocol used by some medical devices. We also can see a function called to get the amount of time to wait between packets, with the result plugged into the Windows sleep function. This code block confirms what we saw with Wireshark and gives us confidence the communication is consistent.

Having gained basic knowledge of the central monitoring station, the next step was to perform the same test on the patient monitor. With the central station powered down, we booted the patient monitor and watched the network traffic using Wireshark.

We can make similar observations about the patient monitor’s broadcast packets, including the 10-second time delay and patient data in plaintext. In these packets we see that the source port is incrementing but the destination port, 7000, is the same as the central monitoring station’s.  After reviewing many of these packets, we find that offset 0x34 of the payload has a counter that increments by 0xA, or 10, with each packet. Without potentially damaging the patient monitor, there is no good way to extract the firmware to review its code. However, the central monitoring station must have code to receive these packets. With a bit of digging through the central station’s binaries, we found the section parsing the broadcast packets from the patient monitor.

The first line of code parses the payload of the packet plus 12 bytes. If we count in 12 bytes from the payload on the Wireshark capture, we can see the start of the patient data in clear text. The next function called is parse_logical_name, whose second parameter is an upper limit for the string being passed. This field has a maximum length of 0x20, or 32, bytes. The subsequent code handles whether this information is empty and stores the data in the format logical_name. This review again helps confirm what we see in real time with Wireshark.

Now that we understand the devices’ separate network traffic, we can look at how they interact. Using our network setup and starting the ECG simulator we can see the central monitor station and the patient monitor come to life.

With everything working, we again use Wireshark to examine the traffic. We find a new set of packets.

In the preceding screen capture we see the patient monitor at IP address 126.4.153.150 is sending the same-size data packets to the central monitoring station at address 126.1.1.1. The source port does not change.

Through these basic tests we learn a great deal:

  • The two devices are speaking over unencrypted UDP
  • The payload contains counters and patient information
  • The broadcast address does not require the devices to know each other’s address beforehand
  • When the data is sent distinct packets contain the waveform

Attacking the protocol

Our reconnaissance tells us we may have the right conditions for a replay attack. Such an attack would not satisfy our goal of modifying data in real time across the network; however, it would provide more insight about the requirements and may prove useful in reaching our goal.

After capturing the packets from the simulated heartbeat, we attempted to replay the captures using Python’s Scapy library. We did this with the patient monitor turned off and the central monitoring station listening for information. After several attempts, this test was unsuccessful. This failure shows the system expects more than just a device sending data packets to a specific IP address.

We examined more closely the packets that are sent before the data packets. We learned that even though the packets are sent with UDP, some sort of handshake is performed between the two devices. The next diagram describes this handshake. 

 

In this fanciful dialog, CMS is the central monitoring system; PM is the patient monitor.

To understand what is happening during the handshake, we can relate each phase of this handshake to that of a TCP three-way handshake. (This is only an analogy; the device is not actually performing a TCP three-way handshake.)

The central monitoring station first sends a packet to port 2000 to the patient monitor. This can be considered the “SYN” packet. The patient monitor responds to the central station; notice it responds to the source port of the initial request. This can be considered the “SYN,ACK.” The central station sends the final “ACK,” essentially completing a three-way (or three-step) handshake. Directly following this step, the patient monitor sends another packet to the initial port of the “SYN” packet. The central monitor responds to the patient monitor on port 2000 with a new source port. Immediately following, we see the data packets being sent to the new source port, 3627, named in the previous exchange.

This exam provides insight into why the replay attack did not work. The central station defines for each connection which ports will be open for the incoming data; we need to consider this when attempting a replay attack. Modifying our previous Scapy scripts to account for the handshake, we retested the replay attack. With the new handshake code in place, the test still failed. Taking another look at the “SYN,ACK” packets provides a potential reason for the failure.

At offset 0x3D is a counter that needs to be incremented each time one of these packets is sent. In this case the patient monitor’s source IP address is embedded in the payload at offsets 0x2A and 0x30. This embedded IP address is not as important for this attack because during the replay our scripts can become the patient monitor’s IP; however, this will become more important later. The newly discovered counter needs to be accounted for and incremented.

Emulating a patient monitor

By taking these new findings into account our replay attack becomes successful. If we can observe a certain ECG pattern, we can play it back to the central monitoring station without the patient monitor on the network. Thus we can emulate the function of the patient monitor with any device. The following video demonstrates this emulation using a Raspberry Pi. We set our Scapy scripts to load after booting the Pi, which mimics the idle function of the patient monitor. When the central monitor requests information about the patient’s vitals, the Pi provides the station with an 80-beats-per-minute wave form. This also works with the other vital signs.

Impact of emulation

Although we have not yet reached our goal of real-time modification, we must consider the implications of this type of attack. If someone were to unplug the monitor of a stable patient and replace it with a device that continued to report the same stable vitals, would that cause any harm? Probably not immediately. But what if the stable patient suddenly became unstable? The central station would normally sound an alarm to alert medical personal, who could take appropriate action. However, if the monitor had been replaced, would anyone know help was needed? The patient monitor also normally sounds alarms that might be heard in and outside of the patient’s room, yet if the monitor was replaced, those alarms would be absent.

In hospitals, nurses and other personal generally make periodic checks even of stable patients. So any deception might not last long, but it might not need to. What if someone were trying to kidnap a patient? A kidnapper would alert fewer people than would be expected.

Switching from a real patient monitor to an emulator would cause a short loss in communication from the patient’s room to the central monitoring station. Is this enough to make the scenario unrealistic or not a threat? We asked Dr. Nordeck if a short loss in connection could be part of a reasonable scenario. “A momentary disconnection of the ECG would likely go unnoticed as this happens often due to patient movement or changing clothes and, as long as it is reconnected, will be unlikely to cause an alert,” he said.

Modifying vitals in real time

Although emulating the patient monitor is interesting, it did not accomplish our goal of making real-time modifications. Using what we learned while testing emulation, could we perform real-time injection? To answer this question, we must first understand the difference between emulation and real-time injection.

Emulation requires a deeper understanding of how the initial connection, the handshake, between the two devices occurred. When considering real-time modification, this handshake has already taken place. But an attacker would not know which port the data packets are being sent too, nor any of the other ports used in the data stream. Plus, because the real patient monitor is still online, it will constantly send data to the central monitoring station.

One way to account for these factors is to use Address Resolution Protocol (ARP) spoofing. If the patient monitor is ARP spoofed, then the attacker, instead of the central monitoring station, would receive the data packets. This step would allow the attacker to determine which ports are in use and stop the patient monitor’s data from getting to the central monitoring station. Because we have already shown that emulation works, the attacker simply has to send replacement data to the central station while appearing as the patient monitor.

For example, consider the following original packet coming from the patient monitor:

The patient monitor sends a packet with the patient’s heartbeat stored at offset 0x71 in the payload. The patient monitor in this screen capture is at IP address 126.4.153.150. An attacker can ARP spoof the patient monitor with a Kali virtual machine.

The ARP packets indicate that the central station, IP address 126.1.1.1, is at MAC address 00:0c:29:a1:6e:bf, which is actually the Kali virtual machine. Wireshark recognizes two MACs with the same IP address assigned and highlights them, showing the ARP spoof.

Next the attacker from the virtual machine at address 126.4.153.153 sends false information to the central monitoring station, still at address 126.1.1.1. In this example, offset 0x71 has been changed to 0x78, or 120. (The attacker could choose any value; the following demo videos use the heartbeat value 180 because it is more alarming.) Also notice the IP address stored in the payload, which we discovered during the reconnaissance phase. It still indicates this data is coming from the original patient monitor address, which is different from the IP address on the packet’s IP header. Due to this implementation, there is no need for the attacker to spoof their IP address for the attack to be successful.

Two videos show this modification happening in real time:

 

Impact of real-time modification

Although the monitor in the patient’s room is not directly affected, real-time modification is impactful because medical professionals use these central stations to make critical decisions on a large number of patients—instead of visiting each room individually. As long as the changes are believable, they will not always be verified.

Dr. Nordeck explains the impact of this attack: “Fictitious cardiac rhythms, even intermittent, could lead to extended hospitalization, additional testing, and side effects from medications prescribed to control heart rhythm and/or prevent clots. The hospital could also suffer resource consumption.” Dr. Nordeck explained that short changes to a heartbeat would generally trigger the nurse or technician monitoring the central station to page a doctor. The doctor would typically ask for a printout from the central station to review the rhythm. The doctor might also order an additional test, such as an EKG, to verify the rhythm. An EKG, however, would not likely capture an abnormal rhythm if it is intermittent, but the test might reveal an underlying cause for intermittent arrythmia. Should the rhythm recur intermittently throughout the day, the doctor might make treatment decisions based on this erroneous printout.

The American Heart Association and American College of Cardiology publish guidelines that hospitals are to follow, including for “intermittent cardiac rhythms,” seen in this chart:

A decision tree for treating an intermittent heart rate. Source: American Heart Association.

The first decision point in this tree asks if the patient is hemodynamically stable (whether the blood pressure is normal). This attack does not affect the bedside monitor. A nurse might retake the patient’s blood pressure, which would be normal. The next decision point following the “Yes” path is a diagnosis of focal atrial tachycardia. Regardless of the medical terms and answers, the patient is issued medication. In the case of a network attack, this is medication the patient does not need and could cause harm.

Conclusion

This research from McAfee’s Advanced Threat Research team shows it is possible to emulate and modify a patient’s vital signs in real time on a medical network using a patient monitor and central monitoring station. For this attack to be viable, an attacker would need to be on the same network as the devices and have knowledge of the networking protocol. Any modifications made to patient data would need to be believable to medical professionals for there to be any impact.

During our research we did not modify the patient monitor, which always showed the true data; but we have proven the impact of an attack can be meaningful. Such an attack could result in patients receiving the wrong medications, additional testing, and extended hospital stays—any of which could incur unnecessary expenses.

Both product vendors and medical facilities can take measures to drastically reduce the threat of this type of attack. Vendors can encrypt network traffic between the devices and add authentication. These two steps would drastically increase the difficulty of this type of attack. Vendors also typically recommend that medical equipment is run on a completely isolated network with very strict network-access controls. If medical facilities follow these recommendations, attackers would require physical access to the network, greatly helping to reduce the attack surface.

One goal of the McAfee Advanced Threat Research team is to identify and illuminate a broad spectrum of threats in today’s complex and constantly evolving landscape. Through responsible disclosure we aim to assist and encourage the industry toward a more comprehensive security posture. As part of our policy, we reported this research to the vendor whose products we tested and will continue to work with other vendors to help secure their products.

The post 80 to 0 in Under 5 Seconds: Falsifying a Medical Patient’s Vitals appeared first on McAfee Blogs.

Jun 14 2018

Unintended Clipboard Paste Function in Windows 10 Leads to Information Leak in RS1

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.

Jun 12 2018

Want to Break Into a Locked Windows 10 Device? Ask Cortana (CVE-2018-8140)

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 Principle 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.

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