Weidmueller Patches Critical Vulnerabilities in Industrial Switches
Germany-based industrial connectivity solutions provider Weidmueller has released firmware updates for many of its managed industrial Ethernet switches to address critical vulnerabilities.
Weidmueller has six manufacturing plants and a presence in 60 locations around the world. According to the DHS’s Cybersecurity and Infrastructure Security Agency (CISA), the impacted products are used worldwide, particularly in the critical manufacturing and IT sectors.
Advisories published recently by CISA, Germany’s [email protected] and Weidmuller show that 40 IE-SW series switches are impacted by five types of vulnerabilities.
The most serious flaws, based on their CVSS score, are related to the lack of brute-force protection for the authentication mechanism, the transmission of credentials in clear text, and the use of predictable authentication information in a cookie. All of these issues are considered critical, with a CVSS score of 9.8.
The industrial switches are also affected by a high-severity flaw related to the storage of passwords in clear text. This weakness allows anyone with access to the device to obtain the passwords.
Finally, Weidmueller discovered a medium-severity issue that allows a remote, authenticated attacker to crash the device using specially crafted packets.
Weidmueller has released firmware updates for each of the impacted switches. Users have also been informed that they can configure their devices to only use encrypted connections, which can prevent some types of attacks. Some weaknesses are related to the use of an unencrypted search service, which should be disabled — an encrypted search service is available.
The vendor has provided detailed instructions on how mitigations can be applied.
Eduard Kovacs (@EduardKovacs) is a contributing editor at SecurityWeek. He worked as a high school IT teacher for two years before starting a career in journalism as Softpedia’s security news reporter. Eduard holds a bachelor’s degree in industrial informatics and a master’s degree in computer techniques applied in electrical engineering.
VMware Patches ESXi Vulnerability That Earned Hacker $200,000
VMware on Thursday informed customers that it has released patches for a critical remote code execution vulnerability in ESXi that was disclosed recently at the Tianfu Cup hacking competition in China.
According to organizers of the Tianfu Cup, a member of the 360Vulcan team demonstrated a virtual machine escape and took control of the host operating system. The exploit only took 24 seconds to execute and earned the hacker $200,000, the highest single payout at the event.
VMware representatives were present at the competition so they were provided the details of the exploit immediately after the demonstration on November 17.
The company’s investigation revealed that the vulnerability exploited at the event affects ESXi versions 6.0, 6.5 and 6.7 running on any platform, and the Horizon cloud desktop-as-a-service (DaaS) platform version 8.x.
Patches have been released for ESXi, but VMware is still working on a fix for Horizon DaaS. The vulnerability is tracked as CVE-2019-5544 and it has been assigned a CVSS score of 9.8, which makes it a critical issue.
VMware says the flaw is a heap overwrite issue related to the OpenSLP open source implementation of the Service Location Protocol (SLP), which is designed for locating resources on a network.
“A malicious actor with network access to port 427 on an ESXi host or on any Horizon DaaS management appliance may be able to overwrite the heap of the OpenSLP service resulting in remote code execution,” VMware said in its advisory.
This year it took VMware more than two weeks to address the vulnerability disclosed at the Tianfu Cup contest, but in 2018 it took the company less than a week to patch a Workstation vulnerability that earned a researcher $100,000 at the hacking event.
At this year’s Tianfu Cup, white hat hackers earned $545,000 for demonstrating exploits against products from VMware, Microsoft, Google, Apple, D-Link, and Adobe.
Eduard Kovacs (@EduardKovacs) is a contributing editor at SecurityWeek. He worked as a high school IT teacher for two years before starting a career in journalism as Softpedia’s security news reporter. Eduard holds a bachelor’s degree in industrial informatics and a master’s degree in computer techniques applied in electrical engineering.
VPN Connection Hijacking Vulnerability Affects Linux, Unix Systems
A vulnerability that can be exploited to determine if a user is connected to a VPN and hijack active TCP connections in a VPN tunnel has been found to affect various Linux and Unix operating systems.
The vulnerability, tracked as CVE-2019-14899, was discovered recently by a team of researchers from the University of New Mexico. They privately reported their findings to the developers of the affected operating systems some time ago, and they have now made their findings public on the SecLists.Org and Openwall security mailing lists.
According to the experts, the flaw impacts Linux distributions — including Ubuntu, Fedora and Debian — FreeBSD, OpenBSD, macOS, iOS and Android. They have tested the attack against OpenVPN, WireGuard, and IKEv2/IPSec VPNs, but pointed out that the type of VPN technology used does not seem to make a difference.
The attack works against both IPv4 and IPv6 connections. However, the researchers say it does not work against the Tor anonymity network.
The vulnerability allows an attacker who is on the same network as the targeted user to determine if they are using a VPN, obtain the virtual IP address assigned by the VPN server, determine if the target is currently accessing a specified website, and even inject data into the TCP stream. This can allow the attacker to hijack active connections within the VPN tunnel.
The attack can also be launched using a malicious access point, the researchers said.
While the same attack method might work against the affected Linux distributions, there are variations for each of the other impacted operating systems.
Colm MacCárthaigh, who works for AWS and helps develop Amazon Linux and the company’s VPN products, says they are not impacted by the vulnerability. However, he has described the attack method as “very impressive” and has warned that it can pose an even more serious threat if combined with DNS spoofing.
“Encrypted DNS queries and replies can be profiled by traffic analysis, and the reply ‘paused’, making it easier to ensure that a DNS spoofing attempt will succeed,” MacCárthaigh explained. “This is a good reminder that cryptographic protections are best done end to end; DNSSEC does not help with this attack, because it does not protect traffic between the stub resolver and the resolver. It’s also a good reminder that traffic analysis is still the most effective threat against network encryption.”
Eduard Kovacs (@EduardKovacs) is a contributing editor at SecurityWeek. He worked as a high school IT teacher for two years before starting a career in journalism as Softpedia’s security news reporter. Eduard holds a bachelor’s degree in industrial informatics and a master’s degree in computer techniques applied in electrical engineering.
Microsoft Warns of Persistent Windows Hello for Business Orphaned Keys
Microsoft this week issued guidance regarding Windows Hello for Business (WHfB) public keys that persist even after the devices they are tied to are removed from Active Directory.
These WHfB public keys, the tech company explains, are written to the on-premises Active Directory after the user sets up WHfB. Tied to the user and the device added to Azure AD, these keys are considered orphaned when the device is removed.
The issue, however, is that orphaned keys are not deleted from AD even when the devices they were created on are no longer present.
While authentication to Azure AD using orphaned WHfB keys is rejected, some of these keys could lead to a series of security issues in Active Directory 2016 or 2019, Microsoft explains. The problems could appear in either hybrid or on-premises environments.
“An authenticated attacker could obtain orphaned keys created on TPMs that were affected by CVE-2017-15361 (ROCA), discussed in Microsoft Security Advisory ADV170012 to compute their WHfB private key from the orphaned public keys,” Microsoft says.
Using a stolen private key, an attacker could pose as the user and authenticate within the domain using Public Key Cryptography for Initial Authentication (PKINIT).
The attack can be performed even if the TPMs (Trusted Platform Modules) affected by CVE-2017-15361 have received firmware and software updates, due to the fact that the corresponding public keys might still exist in Active Directory.
The issue, Microsoft explains, can be present when WHfB is deployed on Active Directory 2016 or 2019, either in hybrid mode or on-premises only, and has or had WHfB keys generated on TPMs that were affected by CVE-2017-15361.
Azure AD and Active Directory Federation Services (AD FS), the company reveals, are not impacted.
Steps to mitigate the issue include patching TPMs affected by the vulnerability and then installing the WHfBTools Windows PowerShell module in order to employ WHfBTools PowerShell scripts to identify orphaned WHfB keys and keys affected by ROCA.
Next, AD customers can remove orphaned keys, keys affected by the security flaw, or both types of keys.
“If you haven’t updated your TPM first, simply deleting these keys from the directory is not sufficient to mitigate the issue. Setting up WHfB again will re-create keys that are affected by CVE-2017-15361,” Microsoft underlines.
The company also explains that keys deleted in Azure AD are automatically removed in Active Directory as part of the synchronization process. In hybrid environments, however, keys deleted only from Active Directory are rewritten from Azure AD as part of the synchronization process.
Unpatched Linux bug may open devices to serious attacks over Wi-Fi
A potentially serious vulnerability in Linux may make it possible for nearby devices to use Wi-Fi signals to crash or fully compromise vulnerable machines, a security researcher said.
The flaw is located in the RTLWIFI driver, which is used to support Realtek Wi-Fi chips in Linux devices. The vulnerability triggers a buffer overflow in the Linux kernel when a machine with a Realtek Wi-Fi chip is within radio range of a malicious device. At a minimum, exploits would cause an operating-system crash and could possibly allow a hacker to gain complete control of the computer. The flaw dates back to version 3.10.1 of the Linux kernel released in 2013.
“The bug is serious,” Nico Waisman, who is a principal security engineer at Github, told Ars. “It’s a vulnerability that triggers an overflow remotely through Wi-Fi on the Linux kernel, as long as you’re using the Realtek (RTLWIFI) driver.”
The vulnerability is tracked as CVE-2019-17666. Linux developers proposed a fix on Wednesday that will likely be incorporated into the OS kernel in the coming days or weeks. Only after that will the fix make its way into various Linux distributions.
Waisman said he has not yet devised a proof-of-concept attack that exploits the vulnerability in a way that can execute malicious code on a vulnerable machine.
“I’m still working on exploitation, and it will definitely… take some time (of course, it might not be possible),” he wrote in a direct message. “On paper, [this] is an overflow that should be exploitable. Worst-case scenario, [this] is a denial of service; best scenario, you get a shell.”
After the vulnerability became public, the researcher discussed the flaw on Twitter.
Notice of Absence
The driver flaw can be triggered when an affected device is within radio range of a malicious device. As long as the Wi-Fi is turned on, it requires no interaction on the part of the end user. The malicious device exploits the vulnerability by using a power-saving feature known as a Notice of Absence that’s built into Wi-Fi Direct, a standard that allows two devices to connect over Wi-Fi without the need of an access point. The attack would work by adding vendor-specific information elements to Wi-Fi beacons that, when received by a vulnerable device, trigger the buffer overflow in the Linux kernel.
The vulnerability only affects Linux devices that use a Realtek chip when Wi-Fi is turned on. The flaw can’t be triggered if Wi-Fi is turned off or if the device uses a Wi-Fi chip from a different manufacturer. Based on links here and here, it appears that Android devices with Realtek Wi-Fi chips may also be affected.
Representatives of both Realtek and Google didn’t immediately comment on this story.
While it’s still not clear how severely this vulnerability can be exploited, the prospect of code-execution attacks that can be staged wirelessly by devices within radio range is serious. This post will be updated if new information becomes available.
https://arstechnica.com/?p=1587437
Activists’ phones targeted by one of the world’s most advanced spyware apps
Mobile phones of two prominent human rights activists were repeatedly targeted with Pegasus, the highly advanced spyware made by Israel-based NSO, researchers from Amnesty International reported this week.
The Moroccan human rights defenders received SMS text messages containing links to malicious sites. If clicked, the sites would attempt to install Pegasus, which as reported here and here, is one of the most advanced and full-featured pieces of spyware ever to come to light. One of the activists was also repeatedly subjected to attacks that redirected visits intended for Yahoo to malicious sites. Amnesty International identified the targets as activist Maâti Monjib and human rights lawyer Abdessadak El Bouchattaoui.
Serial pwner
It’s not the first time NSO spyware has been used to surveil activists or dissidents. In 2016, United Arab Emirates dissident Ahmed Mansoor received text messages that tried to lure him to a site that would install Pegasus on his fully patched iPhone. The site relied on three separate zeroday vulnerabilities in iOS. According to previous reports from Univision, Amnesty International, and University of Toronto-based Citizen Lab, NSO spyware has also targeted:
150 people, including US citizens and opposition critics chosen by an ex-president of Panama
22 journalists and activists researching corruption in the Mexican government
Two people—one an Amnesty International researcher and the other a dissident—in Saudi Arabia
This week’s report said that the targeting of the two Morrocan human rights defenders began no later than November 2017 and likely lasted until at least July of this year. In 2017 and 2018, the men received text messages that contained links to sites including stopsms[.]biz and infospress[.]com, which Amnesty International previously said was part of NSO’s exploit infrastructure. Other domains included revolution-news[.]co (which Citizen Lab has identified as tied to NSO) and the previously unknown hmizat[.]co (which appears to impersonate Moroccan ecommerce company Hmizate).
Suspicious redirects
Then, starting this year, Monjib’s iPhone started being suspiciously redirected to malicious sites. An analysis of logs Safari stores of each visited link and the origin and destination of each visit showed the redirects happened after Monjib entered “yahoo.fr” in the address bar of his Safari browser. Under normal conditions, Safari would quickly be redirected to the encrypted link https://fr.yahoo.com/. But on at least four occasions, from March of this year to July, the activist was instead diverted to links including
These redirections were possible only because the initial connection to Yahoo wasn’t protected by an encrypted HTTPS connection. In the redirection from July, Monjib again tried to access Yahoo, but instead of typing an address in the browser, he searched for “yahoo.fr mail” on Google. When he clicked the result, he landed on the correct site. Authors of this week’s report wrote:
We believe this is a symptom of a network injection attack generally called “man-in-the-middle” attack. Through this, an attacker with privileged access to a target’s network connection can monitor and opportunistically hijack traffic, such as Web requests. This allows them to change the behavior of a targeted device and, such as in this case, to re-route it to malicious downloads or exploit pages without requiring any extra interaction from the victim.
Such a network vantage point could be any network hop as close as possible to the targeted device. In this case, because the targeted device is an iPhone, connecting through a mobile line only, a potential vantage point could be a rogue cellular tower placed in the proximity of the target or other core network infrastructure the mobile operator might have been requested to reconfigure to enable this type of attack.
Because this attack is executed “invisibly” through the network instead of with malicious SMS messages and social engineering, it has the advantages of avoiding any user interaction and leaving virtually no trace visible to the victim.
We believe this is what happened with Maâti Monjib’s phone. As he visited yahoo.fr, his phone was being monitored and hijacked, and Safari was automatically directed to an exploitation server which then attempted to silently install spyware.
Amnesty International
Amnesty International researchers said they believe at least one of the injections “was successful and resulted in the compromise of Maâti Monjib’s iPhone.” The researchers continued:
Whenever an application crashes, iPhones store a log file keeping traces of what precisely caused the crash. These crash logs are stored on the phone indefinitely, at least until the phone is synced with iTunes. They can be found in Settings > Privacy > Analytics > Analytics Data. Our analysis of Maâti Monjib’s phone showed that, on one occasion, all these crash files were wiped a few seconds after one of these Safari redirections happened. We believe it was a deliberate clean-up executed by the spyware in order to remove traces that could lead to the identification of the vulnerabilities actively exploited. This was followed by the execution of a suspicious process and by a forced reboot of the phone.
A preponderance of evidence
The researchers said they can’t prove the redirections were the work of NSO products or services, but they say evidence strongly suggests a link. The evidence includes similarities between the known NSO URLs contained in the SMS messages—such as
. Both are composed of generic domain names followed by a pseudorandom alphanumeric string of seven to nine characters.
The researchers also found a similar network injection capability described in a document titled Pegasus—Product Description that was found in the 2015 hack of NSO competitor Hacking Team. The NSO document calls the redirect capability a “Tactical Network Element” and describes how a rogue cell tower could be used to identify a targeted phone and remotely inject and install Pegasus.
Amid growing criticism, NSO Group—which earlier this year was valued at $1 billion in a leveraged buyout by UK-based private equity firm Novalpina Capital—promised in September to follow a human rights policy based on these guiding principles. A key aspect of the policy was to “investigate whenever the company becomes aware of alleged unlawful digital surveillance and communication interception of NSO products.”
In a response to this week’s report, NSO officials wrote:
As per our policy, we investigate reports of alleged misuse of our products. If an investigation identifies actual or potential adverse impacts on human rights, we are proactive and quick to take the appropriate action to address them. This may include suspending or immediately terminating a customer’s use of the product, as we have done in the past.
While there are significant legal and contractual constraints concerning our ability to comment on whether a particular government agency has licensed our products, we are taking these allegations seriously and will investigate this matter in keeping with our policy. Our products are developed to help the intelligence and law enforcement community save lives. They are not tools to surveil dissidents or human rights activists. That’s why contracts with all of our customers enable the use of our products solely for the legitimate purposes of preventing and investigating crime and terrorism. If we ever discover that our products were misused in breach of such a contract, we will take appropriate action.
In an email, an NSO representative said appropriate action could include shutting down a customer’s access to the NSO system, which the company has done three times in the past.
Amnesty International, for its part, remains skeptical.
“In the absence of adequate transparency on investigations of misuse by NSO Group and due diligence mechanisms, Amnesty International has long found these claims spurious,” this week’s report said. “With the revelations detailed in this report, it has become increasingly obvious that NSO Group’s claims and its human rights policy are an attempt to whitewash rights violations caused by the use of its products.”
https://arstechnica.com/?p=1584181
Attackers exploit an iTunes zeroday to install ransomware
Attackers exploited a zeroday vulnerability in Apple’s iTunes and iCloud programs to infect Windows computers with ransomware without triggering antivirus protections, researchers from Morphisec reported on Thursday. Apple patched the vulnerability earlier this week.
The vulnerability resided in the Bonjour component that both iTunes and iCloud for Windows relies on, according to a blog post. The bug is known as an unquoted service path, which as its name suggests, happens when a developer forgets to surround a file path with quotation marks. When the bug is in a trusted program—such as one digitally signed by a well-known developer like Apple—attackers can exploit the flaw to make the program execute code that AV protection might otherwise flag as suspicious.
Morphisec CTO Michael Gorelik explained it this way:
As many detection solutions are based on behavior monitoring, the chain of process execution (parent-child) plays a major role in alert fidelity. If a legitimate process signed by a known vendor executes a new malicious child process, an associated alert will have a lower confidence score than it would if the parent was not signed by a known vendor. Since Bonjour is signed and known, the adversary uses this to their advantage. Furthermore, security vendors try to minimize unnecessary conflicts with known software applications, so they will not prevent this behaviorally for fear of disrupting operations.
In August, Morphisec found attackers were exploiting the vulnerability to install ransomware called BitPaymer on the computers of an unidentified company in the automotive industry. The exploit allowed the attackers to execute a malicious file called “Program,” which presumably was already on the target’s network.
Gorelik continued:
Additionally, the malicious “Program” file doesn’t come with an extension such as “.exe”. This means it is likely that AV products will not scan the file since these products tend to scan only specific file extensions to limit the performance impact on the machine. In this scenario, Bonjour was trying to run from the “Program Files” folder, but because of the unquoted path, it instead ran the BitPaymer ransomware since it was named “Program”. This is how the zero-day was able to evade detection and bypass AV.
Gorelik said that Morphisec “immediately” notified Apple of the active exploit upon finding it in August. On Monday, Apple patched the vulnerability in both iTunes 12.10.1 for Windows and iCloud for Windows 7.14. Windows users who have either application installed should ensure the automatic updates worked as they’re supposed to. In an email, Gorelik said his company has reported additional vulnerabilities that Apple has yet to patch. Apple representatives didn’t respond to an email seeking comment for this post.
What’s more, anyone who has ever installed and later uninstalled iTunes should inspect their PCs to ensure Bonjour was also removed. That’s because the iTunes uninstaller doesn’t automatically remove Bonjour.
“We were surprised by the results of an investigation that showed the Bonjour updater is installed on a large number of computers across different enterprises,” Gorelik wrote. “Many of the computers uninstalled iTunes years ago while the Bonjour component remains silently, un-updated, and still working in the background.”
An aside: Gorelik described Bonjour as “a mechanism that Apple uses to deliver future updates.” Apple and many other resources, meanwhile, say it’s a service Apple applications use to find shared music libraries and other resources on a local network. In an email, Gorelik said Bonjour serves both functions.
“Moreover in the specific attack, Bonjour was executing the SoftwareUpdate executable that is located under C:\\Program Files (x86)\\Apple Software Update\\SoftwareUpdate.exe, but instead they executed C:\\Program with the rest as parameters -> “C:\\Program ‘Files’ ‘(x86)\\Apple’ ‘Software’ ‘Update\\SoftwareUpdate.exe,'” he wrote. He went on to say that Apple developers “haven’t fixed all the vulnerabilities reported by us, only the one that was abused by the attackers.”
https://arstechnica.com/?p=1583285
Attackers exploit 0day vulnerability that gives full control of Android phones
Attackers are exploiting a zeroday vulnerability in Google’s Android mobile operating system that can give them full control of at least 18 different phone models, including four different Pixel models, a member of Google’s Project Zero research group said on Thursday night.
There’s evidence the vulnerability is being actively exploited, either by exploit developer NSO Group or one of its customers, Project Zero member Maddie Stone said in a post. Exploits require little or no customization to fully root vulnerable phones. The vulnerability can be exploited two ways: (1) when a target installs an untrusted app or (2) for online attacks, by combining the exploit with a second exploit targeting a vulnerability in code the Chrome browser uses to render content.
“The bug is a local privilege escalation vulnerability that allows for a full compromise of a vulnerable device,” Stone wrote. “If the exploit is delivered via the Web, it only needs to be paired with a renderer exploit, as this vulnerability is accessible through the sandbox.”
A “non-exhaustive list” of vulnerable phones include:
Pixel 1
Pixel 1 XL
Pixel 2
Pixel 2 XL
Huawei P20
Xiaomi Redmi 5A
Xiaomi Redmi Note 5
Xiaomi A1
Oppo A3
Moto Z3
Oreo LG phones
Samsung S7
Samsung S8
Samsung S9
High severity
A member of Google’s Android team said in the same Project Zero thread that the vulnerability would be patched—in Pixel devices, anyway—in the October Android security update, which is likely to become available in the next few days. The schedule for other devices to be patched wasn’t immediately clear. Pixel 3 and Pixel 3a devices aren’t affected.
“This issue is rated as high severity on Android and by itself requires installation of a malicious application for potential exploitation,” Tim Willis, another Project Zero member, wrote, citing Android team members. “Any other vectors, such as via web browser, require chaining with an additional exploit.”
Google representatives wrote in email: “Pixel 3 and 3a devices are not vulnerable to this issue, and Pixel 1 and 2 devices will be protected with the October Security Release, which will be delivered in the coming days. Additionally, a patch has been made available to partners in order to ensure the Android ecosystem is protected against this issue.”
The use after free vulnerability originally appeared in the Linux kernel and was patched in early 2018 in version 4.14, without the benefit of a tracking CVE. That fix was incorporated into versions 3.18, 4.4, and 4.9 of the Android kernel. For reasons that weren’t explained in the post, the patches never made their way into Android security updates. That would explain why earlier Pixel models are vulnerable and later ones are not. The flaw is now tracked as CVE-2019-2215.
Remember NSO?
Stone said that information she received from Google’s Threat Analysis Group indicated the exploit was “allegedly being used or sold by the NSO Group,” a developer of exploits it sells to various government entities. Israel-based NSO gained widespread attention with the discoveries in 2016 and 2017 of an advanced piece of mobile spyware it developed called Pegasus. It jailbreaks or roots both iOS and Android phones so it can trawl through private messages, activate the microphone and camera, and collect all kinds of other sensitive information. Researchers from University of Toronto-based Citizen Lab determined that the iOS version of Pegasus targeted a political dissident located in the United Arab Emirates.
“As an NSO customer, I’d worry that NSO’s notoriety has attracted the kind of heavy scrutiny from security teams and researchers that could lead to my most sensitive espionage operations being disrupted, and exposed,” John Scott-Railton, a senior researcher at Citizen Lab, told Ars.
Representatives of NSO didn’t immediately respond to an email seeking comment for this post.
Project Zero gives developers 90 days to issue a fix before publishing vulnerability reports except in cases of active exploits. The Android vulnerability in this case was published seven days after it was privately reported to the Android team.
While the vulnerability reported on Thursday is serious, vulnerable Android users shouldn’t panic. The chances of being exploited by attacks as expensive and targeted as the one described by Project Zero are extremely slim. Just the same, it may make sense to hold off installing non-essential apps and to use a non-Chrome browser until after the patch is installed.
https://arstechnica.com/?p=1579777
Webkit zero-day exploit besieges Mac and iOS users with malvertising redirects
Enlarge/ Artist’s impression of a malicious hacker coding up a BlueKeep-based exploit.
Attackers have bombarded the Internet with more than 1 billion malicious ads in less than two months. The attackers targeted iOS and macOS users with what were zero-day vulnerabilities in Chrome and Safari browsers that were recently patched, researchers said on Monday.
More than 1 billion malicious ads served in the past six weeks contained exploit code that redirected vulnerable users to malicious sites, according to a post published by security firm Confiant. The surge of malicious ads exploited a Safari vulnerability in both iOS and macOS, as well as a Chrome vulnerability in iOS.
“Staggering volume”
“If we take a snapshot of eGobbler activity from August 1 to September 23, 2019, then we see a staggering volume of impacted programmatic impressions,” Confiant researcher and engineer Eliya Stein wrote. “By our estimates, we believe up to 1.16 billion impressions have been affected.”
To generate successful redirects, eGobbler was exploiting what had been a zero-day vulnerability in Webkit, the browser engine used in Safari and that shares code with Blink, the Webkit fork used for Chrome. The vulnerability existed in a JavaScript function (known as the onkeydown event,) which occurs each time a user presses a key on the keyboard. Tracked as CVE-2019-8771, the vulnerability allowed ads linked in HTML tags known as iframes to break out of security sandbox protections that prevent a user from being redirected without explicitly initiating it.
Enlarge/ One of the malvertisements eGobbler served in the recent campaign.
“The nature of the bug is that a cross-origin nested iframe is able to ‘autofocus’ which bypasses the ‘allow-top-navigation-by-user-activation’ sandbox directive on the parent frame,” Stein wrote. “With the inner frame automatically focused, the keydown event becomes a user-activated navigation event, which renders the ad sandboxing entirely useless as a measure for forced redirect mitigation.”
Confiant privately reported a vulnerability to both the Google and Apple security teams on August 7. The vulnerability was fixed in Chrome with the September 19 release of iOS 13. The Safari patch landed five days later with the release of Safari 13.0.1. This Webkit bugtracker entry shows that the flaw has been fixed in the underlying browser engine on August 9.
The blast of malicious ads comes five months after a similar eGobbler campaign served an estimated 500 million malicious ads. That blitz also relied on a then-unpatched vulnerability in the iOS version of Chrome. Tracked as CVE-2019–5840, that flaw was fixed in June with the release of Chrome 75.
The latest campaign concentrated on phishing pages, including the one shown above and to the right, that served spoofed custom messaging based on the target’s mobile provider. Countries in Europe were heavily targeted in this recent wave, which is why the images are not in English.
https://arstechnica.com/?p=1577215
Developer of Checkm8 explains why iDevice jailbreak exploit is a game changer
Enlarge/ The bootrom of an Apple Watch Series 3, as shown through a hex viewer. Yep, Apple Watches series 1, 2, and 3 are also vulnerable to Checkm8.
Often, when new iOS jailbreaks become public, the event is bittersweet. The exploit allowing people to bypass restrictions Apple puts into the mobile operating system allows hobbyists and researchers to customize their devices and gain valuable insights that may be peeking under the covers. That benefit is countered by the threat that the same jailbreak will give hackers a new way to install malware or unlock iPhones that are lost, stolen, or confiscated by unscrupulous authorities.
Friday saw the release of Checkm8. Unlike just about every jailbreak exploit released in the past nine years, it targets the iOS bootrom, which contains the very first code that’s executed when an iDevice is turned on. Because the bootrom is contained in read-only memory inside a chip, jailbreak vulnerabilities that reside there can’t be patched.
Checkm8 was developed by a hacker who uses the handle axi0mX. He’s the developer of another jailbreak-enabling exploit called alloc8 that was released in 2017. Because it was the first known iOS bootrom exploit in seven years, it was of intense interest to researchers, but it worked only on the iPhone 3GS, which was seven years old by the time alloc8 went public. The limitation gave the exploit little practical application.
Checkm8 is different. It works on 11 generations of iPhones, from the 4S to the X. While it doesn’t work on newer devices, Checkm8 can jailbreak hundreds of millions of devices in use today. And because the bootrom can’t be updated after the device is manufactured, Checkm8 will be able to jailbreak in perpetuity.
I wanted to learn how Checkm8 will shape the iPhone experience—particularly as it relates to security—so I spoke at length with axi0mX on Friday. Thomas Reed, director of Mac offerings at security firm Malwarebytes, joined me. The takeaways from the long-ranging interview are:
Checkm8 requires physical access to the phone. It can’t be remotely executed, even if combined with other exploits
The exploit allows only tethered jailbreaks, meaning it lacks persistence. The exploit must be run each time an iDevice boots.
All of the above means people will be able to use Checkm8 to install malware only under very limited circumstances. The above also means that Checkm8 is unlikely to make it easier for people who find, steal or confiscate a vulnerable iPhone, but don’t have the unlock PIN, to access the data stored on it.
Checkm8 is going to benefit researchers, hobbyists, and hackers by providing a way not seen in almost a decade to access the lowest levels of iDevices.
Read on to find out, in axi0mX’s own words, why he believes this is the case:
Dan Goodin: Can we start with the broad details? Can you describe at a high level what Checkm8 is, or what it is not?
axi0mX: It is an exploit, and that means it can get around the protection that Apple built into the bootrom of most recent iPhones and iPads. It can compromise it so that you can execute any code at the bootrom level that you want. That is something that used to be common years ago, during the days of the first iPhone and iPhone 3G and iPhone 4. There were bootrom exploits [then] so that people could jailbreak their phone through the bootrom and that later would not be possible.
The last bootrom exploit that was released was for iPhone 4 back in 2010, I believe by Geohot. After that, it was not possible to exploit an iPhone at this level. All the jailbreaks [that] were done later on [happened] once the operating system boots. The reason that bootrom is special is it’s part of the chip that Apple made for the phone. So whatever code is put there in the factory is going to be there for the rest of its life. So if there is any vulnerability inside the bootrom, it cannot be patched.
Persistence and Secure Enclave
DG: When we talk about things that aren’t patchable, we’re talking about the bug. What about the change to the device itself? Is that permanent, or once the phone is rebooted, does it go back to its original state?
A: This exploit works only in memory, so it doesn’t have anything that persists after reboot. Once you reboot the phone… then your phone is back to an unexploited state. That doesn’t mean that you can’t do other things because you have full control of the device that would modify things. But the exploit itself does not actually perform any changes. It’s all until you reboot the device.
DG: In a scenario where either police or a thief obtains a vulnerable phone but doesn’t have an unlock PIN, are they going to be helped in any way by this exploit? Does this exploit allow them to access parts of this phone or do things with this phone that they couldn’t otherwise do?
A: The answer is “It depends.” Before Apple introduced the Secure Enclave and Touch ID in 2013, you didn’t have advanced security protections. So, for example, the [San Bernardino gun man’s] phone that was famously unlocked [by the FBI]—the iPhone 5c— that didn’t have Secure Enclave. So in that case, this vulnerability would allow you to very quickly get the PIN and get access to all the data. But for pretty much all current phones, from iPhone 6 to iPhone 8, there is a Secure Enclave that protects your data if you don’t have the PIN.
My exploit does not affect the Secure Enclave at all. It only allows you to get code execution on the device. It doesn’t help you boot towards the PIN because that is protected by a separate system. But for older devices, which have been deprecated for a while now, for those devices like the iPhone 5, there is not a separate system, so in that case you could be able to quickly [without an unlock PIN].
DG: So this exploit isn’t going to be of much benefit to a person who has that device [with Secure Enclave] but does not have the PIN, right?
A: If by benefit you mean accessing your data, then yes, that is correct. But it’s still possible they might have other goals than accessing your data, and in that case, it’s possible they would get some benefit.
DG: Are you talking about creating some sort of backdoor that once the owner puts in a PIN it would get sent to the attacker, or a scenario like that?
A: If, say, for example, you leave your phone in a hotel room, it’s possible that someone did something to your phone that causes it to send all of the information to some bad actor’s computer.
DG: And that would happen after the legitimate owner returned and entered their PIN?
A: Yes, but that’s not really a scenario that I would worry much about, because attackers at that level… would be more likely to get you to go to a bad webpage or connect to a bad Wi-Fi hotspot in a remote exploit scenario. Attackers don’t like to be close. They want to be in the distance and hidden.
In this case [involving Checkm8], they would have to physically hold your device in their hand and would have to connect a cable to it. It requires access that most attackers would like to avoid.
Tags:
Tags:
Tags:
Tags:
