Tag: Security

In the movies, a hero can always tell he’s being followed because the goons tasked with following him never blend in. In real life, figuring out if someone is tailing you is much trickier, and can be a matter of life and death. At the Black Hat security conference, a speaker demonstrated a low-cost device that looks for the tell-tale wireless signature of bad guys on your tail.

Watch Your Back

Matt Edmondson, who works with the US Department of Homeland Security, was approached by a friend from a government agency and declined to name onstage at Black Hat. This friend worked with confidential sources, and one in particular had links to a terrorist organization. Edmondson’s friend was concerned that if they were followed after meeting with the confidential source, his friend’s government connections could be discovered and the source put in danger.

The traditional spycraft method of surveillance detection, Edmondson explained, is to change your route and see who does the same—such as exiting the highway and then getting back on again. “It’s really obvious the [Washington, D.C.] Beltway was designed as a surveillance-detection route,” quipped Edmondson, perhaps joking, perhaps not.

Edmondson said his friend asked if he could revisit an idea he had discussed years ago: Using network-detection technology to scan for devices that were following you.

Even if you’re being tailed by a nation-state-backed surveillance team, “isn’t there still a really good chance they have a phone in their pocket?” asked Edmondson.

Tattletale Devices

This works because so many of our devices are constantly trying to communicate with other devices and various wireless networks. Many mobile devices, for example, are constantly seeking familiar wireless networks to connect to. Other devices, such as AirPods, Bluetooth speakers, laptops, and so on, can be similarly chatty.

All those wireless conversations can be easily detected. If the same devices are in your vicinity repeatedly, Edmondson reasoned, it’s likely you’re being followed.

At PCMag, we’ve looked at similar devices before. The PwnPro was a multi-thousand-dollar device with sophisticated backend software that could monitor devices within 1,000 feet. It, too, could identify specific devices and usage patterns, but was far from affordable or portable.

SimpleComponents

To build a device that could scan for wireless communications and alert you when such a device stayed in your vicinity, Edmondson set out to use low-cost materials, and settled on the Raspberry Pi single-board computer. “How many of us have multiple Raspberry Pis sitting in your closet doing absolutely nothing?” Edmondson joked.

Add to that a low-cost touch screen purchased off Amazon, a portable power bank, and a USB wireless adapter (Alfa AWUS036ACM), and Edmondson was off and running.

Scanning duties on the device would be handled by Kismet, a free and open-source wireless monitoring tool. Kismet scans the airwaves and records its findings in an SQLite database. “Everything else is shoddy python code,” said Edmondson.

Users interact with Edmondson’s device via the touch screen and a custom interface Edmondson described as “literally the worst user interface you’ve ever seen.” It consists of several large, gray buttons, which are intended to be easily pressed while driving. For this task, Edmondson explained, “you don’t want a nice interface designed by Apple, you want something designed by Fisher-Price.”

Once activated, Edmondson’s device compiled data on the surrounding devices into lists broken down by time. If the device detects something that already appears in the list from 5-10 minutes ago, or 15-20 minutes ago, that’s a sign someone might be on your tail.

A Few Challenges

There were still some challenges with the device, however. First, Edmondson needed to build in a mechanism where detected devices could be added to an ignore list. That way, trusted devices wouldn’t trigger an alert.

During a field test in the Arizona desert, Edmondson discovered another problem: MAC address randomization. This is a security feature of many modern devices, where wireless requests are sent with a random, spoofed MAC address.

Edmondson’s solution was to also look at what Wi-Fi networks devices were asking for. If the same Wi-Fi network request appears again and again, that probably means a single device is nearby. Edmondson said that this could possibly be expanded upon, since tracing the location of the requested Wi-Fi networks could tell you where the device had been previously. Even the requested Wi-Fi network name could contain clues. Edmondson said he also wanted to add a GPS component, so it was possible to see where a potential follower first appeared.

In his talk, Edmondson didn’t reveal whether the device was ever practically put to the test, or what became of his friend’s informant. He did, however, bemoan the lack of similar detection technology. “There’s so much technology out there to stalk on people and invade their privacy and very little to protect yourself,” he said.

Keep reading PCMag for the latest from BlackHatBlackHat.

I picture a scene from a heist movie. The bank boasts of its new, ultimate security force inside the locks, walls, and lasers. And the heist crew looks for ways to subvert that system. Can we slip one of our people into the defense force? Use bribes or threats to compromise a guard? Maybe just find a guard who’s sloppy?

While it’s a lot more technical, finding a technique to subvert the Early Launch Antimalware (ELAM) system in Windows, as described by Red Canary’s principal threat researcher Matt Graeber in his Black Hat briefing, it is similar to that scenario.

Graeber explained that an ELAM driver is secured against tampering, and it runs so early in the boot process that it can evaluate other boot-time drivers, with the potential to block any that are malicious. “To create this driver, you don’t have to implement any early launch code,” Graeber explained. “The only thing you need is a binary resource with rules that say which signers are allowed to run as Antimalware Light services. And you have to be a member of the rather exclusive Microsoft Virus Initiative program.”

“I had to investigate how the rules are implemented,” said Graeber. He then described just how he analyzed Microsoft Defender’s WdBoot.sys to determine the expected structure for these rules. In effect, each rule says that any program signed with a specific digital certificate is allowed to run as an Antimalware Light service, which affords it serious protections.

It’s not possible to swap in an unapproved driver, since each must be Microsoft-approved. And anti-tampering constraints mean it’s equally impossible to subvert an existing driver. “ELAM is an allowlist for Antimalware Light services,” Graber mused. “What if it’s overly permissive? Does there exist an ELAM driver that may be overly permissive?”

A Grueling Search

Graeber relied on many resources in his search for a lax driver, among them VirusTotal Intelligence. You may be familiar with VirusTotal’s free malware check, which lets you submit a file or a hash and have it checked by around 70 antivirus engines. VirusTotal Intelligence provides much broader access to detailed information about just about every file and program in existence.

“Hunting for ELAM drivers, I got 886 results from VirusTotal,” said Graeber. “I filtered the list to validate results and got it to 766. I identified many vendors with ELAM drivers, some of them odd.” Here, Graeber showed a list that included one blank vendor name and several that looked incomplete. “If some of the vendors are odd, maybe there’s one rule set that’s odd.”

In the end, he discovered five certificates from four security companies that, as he hoped, provided a way to subvert ELAM. Without going into detail about certificate chains, I have determined that any program with one of these in its certificate chain could run in the protected Antimalware Light mode. All he had to do was cross a list of such programs with VirusTotal’s list of malware to get a rogue’s gallery of malicious programs with the potential to run protected.

How to Weaponize This Weakness?

At this point, the talk stepped off the technical deep end. Graeber described searching the LOLbins for an abuseable executable, coming up with a suitable version of Microsoft Build, and getting past various obstacles to let him run arbitrary code. I’m sure the bright programmers in the audience were nodding along in admiration.

After a live demo, Graeber noted the possibility of various payloads. “Your own malware is protected, and you can kill other protected processes,” he said. “We effectively killed the Microsoft Defender engine in the demo.” The code is public, though Graeber mentioned that “I had to change some filenames to protect innocent vendors.”

How to Detect and Mitigate This Attack?

“This is abusing the features of ELAM, not a vulnerability,” said Graeber. “I can’t begin to speculate why any of those certificates would be allowed. Shame on Microsoft! Let’s hope for a robust fix in the future. Vendors, I’m not shaming any of you here. I don’t even blame vendors for the overly permissive drivers, since Microsoft allowed them. I encourage any vendor to audit the rule sets of your signed ELAM drivers. You wouldn’t want to be the one who ruined the entire ecosystem.”

Graeber does hold out hope for a fix. “I reported this to Microsoft in December of 2021,” he said. “They acknowledged the issue, and the Defender team really owned this. They’ve taken it very seriously and sent notification to Microsoft Virus Initiative members. If you’re a member, you already know.”

He concluded by offering resources for other researchers to duplicate his work. That might sound like he’s putting weapons in the hands of malware coders, but fear not. Graeber supplied the framework for further investigation, but anyone trying to use it will have to duplicate his search for a permissive driver and an abuseable payload.

Still, the picture of malicious software taking over the secure bunker that ELAM provides and killing off the defending programs is alarming. Let’s hope the security community, Microsoft in particular, comes up with a defense quickly.

Meta is testing additional end-to-end encryption (E2EE) features in Facebook Messenger—and not just because it has been roundly criticized for not enabling these protections by default.

“We’re working hard to protect your personal messages and calls with end-to-end encryption by default on Messenger and Instagram,” Meta says. “Today, we’re announcing our plans to test a new secure storage feature for backups of your end-to-end encrypted chats on Messenger, and more updates and tests to deliver the best experience on Messenger and Instagram.”

The marquee change is the introduction of encrypted backups. Messenger currently stores E2EE messages on a single device; there is no way to access them on another device. (At least in theory.) This can be inconvenient for people who lose their primary device, but if the company had backed up the messages without encrypting them, Messenger users would be at risk.

That isn’t a theoretical problem. Apple uses E2EE for iMessage, but many people choose to back up their message histories via iCloud. That backup isn’t encrypted, so even though the messages rely on E2EE in transit, someone can access those messages via iCloud. Meta avoids that problem with Messenger by restricting E2EE messages to a single device.

Now the company is testing what it calls Secure Storage. This encrypted backup will allow people to recover their messages using the method of their choice—supplying a PIN or entering a generated code—if they lose access to their device. Meta says it will also let Messenger users back up their E2EE messages to “third-party cloud services,” if they prefer.

“For example, for iOS devices you can use iCloud to store a secret key that allows access to your backups,” Meta says. “While this method of protecting your key is secure, it is not protected by Messenger’s end-to-end encryption.” (Which is effectively the company’s way of saying that it’s not responsible if otherwise-secure Messenger chats are accessed via iCloud.)

Meta will start testing Secure Storage on Android and iOS this week. The feature isn’t available via Messenger’s website, desktop apps, or for “chats that aren’t end-to-end encrypted,” though.

The company says it will also “begin testing the ability to unsend messages, reply to Facebook Stories, and offer other ways to access your end-to-end encrypted messages and calls”; test an extension dubbed Code Verify that “automatically verifies the authenticity of the code” on Messenger’s website; and make E2EE messages available to more Instagram users.

But perhaps the most important test will be making E2EE the default for some Messenger users rather than requiring people to enable these protections on a chat-by-chat basis. Meta says:

“This week, we’ll begin testing default end-to-end encrypted chats between some people. If you’re in the test group, some of your most frequent chats may be automatically end-to-end encrypted, which means you won ‘t have to opt in to the feature. You’ll still have access to your message history, but any new messages or calls with that person will be end-to-end encrypted. You can still report messages to us if you think they violate our policies, and we’ll review them and take action as necessary.”

Making the most secure option the default is the best way to encourage people to protect themselves. This has become even more important in a post-gnaws Roe country where law enforcement can—and have—use message histories to build cases against people who’ve had or have sought abortions. (Meta tells wiredwired this rollout wasn’t prompted by those concerns.)

Meta says it “will continue to provide updates as we make progress toward the global rollout of default end-to-end encryption for personal messages and calls in 2023.”

At Black Hat 2022, security researchers showed off a new attack that goes after tracking systems built on ultra-wideband (UWB) radio technology. They were able to stalk these tracking devices without their target’s knowledge, and even make targets appear to move at their attackers’ will.

A key use of UWB is real-time locating systems (RTLS), where a series of transceiver stations called anchors track the location of small, wearable devices called tags in a specific area, in real-time. This has a number of applications, from simple tasks like tracking personal items to high-stakes scenarios like infectious disease contact-tracing and factory safety mechanisms.

“Security flaws in this technology, especially in industrial environments, can be deadly,” says Nozomi Networks Security Research Evangelist Roya Gordon.

You may not be familiar with UWB, but it’s familiar with you. Apple has integrated it into mobile devices starting with the iPhone 11, as well as modern Apple Watches, HomePods, and AirTags. It’s also being used in large-scale infrastructure projects, like the effort to drag the New York City Subway signaling system into the 21st century.

Although Apple AirTags use UWB, the systems the team looked at were markedly different.

Standard Loopholes

What’s the problem with UWB RTLS? Although there is an IEEE standard for RTLS, it doesn’t cover the synchronization or exchange of data, the research team explains. Lacking a required standard, it’s up to individual vendors to figure out those issues, which creates opportunities for exploitation.

In its work, the team procured two off-the-shelf UWB RTLS systems: the Sewio Indoor Tracking RTLS UWB Wi-Fi Kit, and the Avalue Renity Artemis Enterprise Kit. Instead of focusing on tag-to-anchor communication, the Nozomi Networks team looked at communications between the anchors and the server where all the computation happens.

The team’s goal was to intercept and manipulate the location data, but to do that, they first needed to know the precise location of each anchor. That’s easy if you can see the anchors, but much harder if they’re hidden or you don’t have physical access to the space. But Andrea Palanca, Security Researcher at Nozomi Networks, found a way.

The anchors could be detected by measuring the power output of their signals, and the precise center of the space found by watching for when all the anchors detect identical signal data for a single tag. Since RTLS systems require the anchors to be arranged to form a square or rectangle, some simple geometry can pinpoint the anchors.

But an attacker wouldn’t even need pinpoint precision; anchor positions can be off by 10% and still function, Lever says.

Attacking RTLS

With all the pieces in place, the team showed off their location-spoofing attacks in a series of demos. First, they showed how to track targets using existing RTLS systems. We’ve already seen mounting concern over malicious uses of AirTags, where a bad guy tracks a person by hiding an AirTag on them. In this attack, the team didn’t need to hide a device, they simply tracked the tag that their target already used.

They also demonstrated how spoofing a tag’s movements in a COVID-19 contact-tracing scenario could create a false exposure alert, or prevent the system from detecting an exposure.

Another demo used a manufacturing facility mockup, where RTLS data was used to shut down machines so a worker could enter safely. By messing with the data, the team was able to stop production at the faux factory by tricking the system into thinking a worker was nearby. The opposite could be more dire. By making it seem as if the worker had left the area when they were actually still there, the machine could be reactivated and potentially injure the worker.

Practical Complications

The good news for owners of these systems is that these attacks aren’t easy. To pull it off, Luca Cremona, a Security Researcher at Nozomi Networks, first had to compromise a computer inside the target network, or add a rogue device to the network by hacking the Wi-Fi. If a bad guy can get that kind of access, you’ve got a lot of problems already.

Unfortunately, the team didn’t have any easy answers for securing RTLS in general. They kludged data encryption onto an RTLS system, but found that it created so much latency as to make the system unusable for real-time tracking.

The best solution the team presented was for the IEEE standard to be revised to cover the synchronization and exchange of data, requiring manufacturers to meet standards that could prevent RTLS attacks like this.

“We can’t afford to have those loopholes in standards,” Gordon says.

Keep reading PCMag for the latest from BlackHatBlackHat.

Microsoft has warned its customers that a vulnerability known as DogWalk, which affects every recent version of Windows and Windows Server, is being actively exploited by attackers.

DogWalk (CVE-2022-34713) is a high severity vulnerability in the Microsoft Windows Support Diagnostic Tool (MSDT) that can be exploited to enable remote code execution on vulnerable devices, the company says in a Microsoft Security Response Center (MSRC) update.

There are many such devices; DogWalk affects Windows 7, 8.1, 10, and 11 as well as several versions of Windows Server, Microsoft says in the MSRC update. More than 1.4 billion devices currently run Windows 10 or 11 alone, the company says on its website.

Microsoft does reassure Windows users that “exploitation of the vulnerability requires that a user open a specially crafted file,” which means attackers can’t just force their way onto a vulnerable system, but it’s not particularly hard to get someone to open a malicious file .

“In an email attack scenario,” Microsoft says, “an attacker could exploit the vulnerability by sending the specially crafted file to the user and convincing the user to open the file.” Or they could upload the malicious file to a website and just wait for someone to download it.

This update has prompted the US Cybersecurity and Infrastructure Security Agency (CISA) to add CVE-2022-34713 to its Known Exploited Vulnerabilities catalogue. That means federal agencies have until Aug. 30 to patch their systems against the vulnerability.

That might not seem like a long time, especially since Microsoft released the Windows and Windows Servers patches related to DogWalk on Aug. 9 as part of Patch Tuesday. But attackers have known about this flaw in MSDT for at least 2.5 years at this point.

BleepingComputer reports that DogWalk was initially disclosed by a security researcher named Imre Rad in January 2020. Microsoft initially dismissed the report, Rad says, but now it’s finally released a fix and confirmed that attackers have exploited the flaw.