MacOS Mojave Fixes Flaws, Yet Privacy Feature Can Be Bypassed
Apple’s new macOS Mojave (10.14) fixes eight vulnerabilities in the kernel and various other components. However, researchers have already found a way to bypass one of its new privacy features that restricts access to certain folders containing sensitive information.
The update patches an input validation vulnerability in the Bluetooth stack that potentially can allow attackers to intercept traffic, as well as two memory corruption vulnerabilities in the kernel that can lead to arbitrary code execution.
Security issues also have been fixed in the App Store and Auto Unlock that could allow malicious applications to discover users’ Apple IDs. The Application Firewall received fix for a misconfiguration that could allow a sandbox process to circumvent restrictions.
Mojave also patched a bug in Crash Reporter that could allow applications to read restricted memory and removed support for the RC4 cryptographic algorithm which has multiple known weaknesses.
The new macOS version brings new privacy enhancements. For example, it prompts users for permission when applications try to access the computer’s camera, microphone and sensitive data such as Contacts, the Mail database, Messages history or sensitive information saved in Safari.
However, the same day Mojave was released, Patrick Wardle, a macOS security expert and chief research officer at Digita Security, released a video showing that the restrictions to sensitive data such as the Address Book can be bypassed.
Wardle did not publish details about how the bug works, but researchers from security firm SentinelOne seem to have found a similar bypass. In a detailed blog post, they explain that a user who accesses the computer over SSH does not have the same restrictions as when the same user uses the Terminal app locally.
“The first reason is that there’s an oddity about the way macOS treats requests to access these areas,” the SentinelOne researchers said. “It turns out that it sometimes depends not so much on who is asking, but where the request is coming from.”
Fortunately, there is a way to block this bypass. First, log in as a user via SSH and access one of the protected folders. Then, on the local computer go to System Preferences > Security & Privacy > Privacy pane and click on Full Disk Access. The sshd-keygen-wrapper or sshd should now appear in the list of approved apps, being added by macOS automatically. The trick is to uncheck the box in front of those entries without removing them entirely.
“There’s no arguing that user data is safer in Mojave than in previous versions of macOS, but there’s a real potential for users to believe they are protected in situations when they are not, and that sense of false security is a danger in itself,” the SentinelOne researchers said. “Along with the relatively low bar for acquiring approval through dialog alerts, it seems inevitable that bad actors will continue in their efforts to abuse user privacy on macOS 10.14.”
Cloudflare Makes Push for Encrypted SNI in TLS Connections
Cloudflare has deployed support for Encrypted Server Name Indication (SNI), a new proposed extension to the TLS 1.3 protocol that the company helped develop and which prevents ISPs and network attackers from discovering which websites users visit.
HTTPS (HTTP over TLS) encrypts data exchanged between users and websites from potential snoopers on the wire. However, it does not prevent man-in-the-middle attackers from seeing which domain the user accessed, because that is communicated by the user’s browser to the server before the key exchange happens and the session is encrypted.
The domain name is communicated during the ClientHello message via an extension called the Server Name Indication (SNI). This helps in shared hosting or load balancing scenarios where a server with a single IP address serves multiple domain names. In this case, the web server needs to know which specific domain name the users wants to access, so it can return the correct certificate.
The new Encrypted SNI extension solves this problem by having the domain publish its public key directly in a DNS record. The client can then obtain the public key via a DNS query and use it to encrypt the SNI in the ClientHello message. The web server will be able to use its corresponding private key to decrypt the SNI and continue the TLS handshake with the proper certificate.
“It’s important to note that this is an extension to TLS version 1.3 and above, and doesn’t work with previous versions of the protocol,” Cloudflare said in a blog post. “The reason is very simple: one of the changes introduced by TLS 1.3 (not without problems) meant moving the Certificate message sent by the server to the encrypted portion of the TLS handshake (before 1.3, it was sent in plaintext). Without this fundamental change to the protocol, an attacker would still be able to determine the identity of the server by simply observing the plaintext certificate sent on the wire.”
For now, client-side support for Encrypted SNI is lacking. Mozilla plans to add it to the nightly release of Firefox later this week, but it will hopefully be adopted by other browsers as well in the future.
Of course, a man-in-the-middle attacker or an ISP who can also intercept DNS traffic can determine the destination domain by analyzing the user’s DNS queries. This can be prevented by using a DNS server that supports encryption, such as with DNS over TLS or DNS over HTTPS.
