Information Security News
In a severe rebuke of one of the biggest suppliers of HTTPS credentials, Google Chrome developers announced plans to drastically restrict transport layer security certificates sold by Symantec-owned issuers following the discovery they have issued more than 30,000 certificates.
Effective immediately, Chrome plans to stop recognizing the extended validation status of all certificates issued by Symantec-owned certificate authorities, Ryan Sleevi, a software engineer on the Google Chrome team, said Thursday in an online forum. Extended validation certificates are supposed to provide enhanced assurances of a site's authenticity by showing the name of the validated domain name holder in the address bar. Under the move announced by Sleevi, Chrome will immediately stop displaying that information for a period of at least a year. In effect, the certificates will be downgraded to less-secure domain-validated certificates.
More gradually, Google plans to update Chrome to effectively nullify all currently valid certificates issued by Symantec-owned CAs. With Symantec certificate representing more than 30 percent of the Internet's valid certificates by volume in 2015, the move has the potential to prevent millions of Chrome users from being able to access large numbers of sites. What's more, Sleevi cited Firefox data that showed Symantec-issued certificates are responsible for 42 percent of all certificate validations. To minimize the chances of disruption, Chrome will stagger the mass nullification in a way that requires they be replaced over time. To do this, Chrome will gradually decrease the "maximum age" of Symantec-issued certificates over a series of releases. Chrome 59 will limit the expiration to no more than 33 months after they were issued. By Chrome 64, validity would be limited to nine months.
WikiLeaks today dumped a smaller subset of documents from its "Vault 7" collection of files from a CIA software developer server. Yet again, these documents are more important from the perspective of WikiLeaks having them than for showing any revelatory content. The exploits detailed in these new files are for vulnerabilities that have largely been independently discovered and patched in the past. The files also reveal that the CIA likely built one of these tools after seeing a presentation on the exploits of Apple's EFI boot firmware at Black Hat in 2012.
The latest batch of files, dramatically named "DarkMatter" (after one of the tools described in the dump), consists of user manuals and other documentation for exploits targeting Apple MacBooks—including malware that leveraged a vulnerability in Apple's Thunderbolt interface uncovered by a researcher two years ago. Named "Sonic Screwdriver" after the ever-useful tool carried by the fictional Doctor of Dr. Who, the malware was stored on an ordinary Thunderbolt Ethernet adapter. It exploited the Thunderbolt interface to allow anyone with physical access to a MacBook to bypass password protection on firmware and install one of a series of Apple-specific CIA "implants."
The first (and only documented) version of Sonic Screwdriver was released in 2012. It worked only on MacBooks built between late 2011 and mid-2012, and the tool used a vulnerability in the firmware of those computers that allowed commands to be sent via the Thunderbolt adapter to change the "boot path" (the location of the files used to boot the computer). The change would allow a local attacker to boot the targeted MacBook from an external device to install malware that eavesdropped on the computer during normal use. Those implants included "DarkMatter," the predecessor to "QuarkMatter." (QuarkMatter is malware that was revealed in the previous WikiLeaks dump, and it infected the EFI partition of a MacBook's storage device.)
In early 2015, architects of Google's Android mobile operating system introduced a new feature that was intended to curtail the real-time tracking of smartphones as their users traversed retail stores, city streets, and just about anywhere else. A recently published research paper found that the measure remains missing on the vast majority of Android phones and is easily defeated on the relatively small number of devices that do support it.
Like all Wi-Fi-enabled devices, smartphones are constantly scanning their surroundings for available access points, and with each probe, they send a MAC—short for media access control—address associated with the handset. Throughout most of the history of Wi-Fi, the free exchange of MAC addresses didn't pose much threat to privacy. That all changed with the advent of mobile computing. Suddenly MAC addresses left a never-ending series of digital footprints that revealed a dizzying array of information about our comings and goings, including what time we left the bar last night, how many times we were there in the past month, the time we leave for work each day, and the route we take to get there.
Eventually, engineers at Apple and Google realized the potential for abuse and took action. Their solution was to rotate through a sequence of regularly changing pseudo-random addresses when casually probing near-by access points. That way, Wi-Fi devices that logged MAC addresses wouldn't be able to correlate probes to a unique device. Only when a phone actually connected to a Wi-Fi network would it reveal the unique MAC address it was tied to. Apple introduced MAC address randomization in June 2014, with the release of iOS 8. A few months later, Google's Android operating system added experimental support for the measure. Full implementation went live in March 2015 and is currently available in version 5.0 through the current 7.1; those versions account for about two-thirds of the Android user base.