Project Zero and Microsoft


If you are involved in IT and not monitoring Google’s Project Zero, you should be (so should Microsoft).

While still in its infancy – this is a great idea, and one that should force software (and hardware) companies to actually place some attention towards Security. 


Google posts Windows 8.1 vulnerability before Microsoft can patch it

Google’s Project Zero tracks vulnerabilities in software systems and reports them to vendors “in as close to real-time as possible” — a noble cause, no? But what happens if said vendor then fails to push a fix within the 90-day window? Microsoft just found out: Google will go ahead and publish the bug anyway, complete with code that can be used to exploit it. A researcher found a Windows 8.1 security hole that allows lower-level users to become administrators, giving them access to sensitive server functions they’d normally have no right to. Though it remains unpatched by Microsoft, the Zero team published it several days ago — right on schedule.

Microsoft was quick to point out that attackers would “need to have valid logon credentials and be able to log on locally to a targeted machine.” While that should limit the damage, it doesn’t mean the flaw is harmless — a disgruntled mid-level employee with some programming skills could wreak serious harm, for instance. Mountain View told us “just to make this absolutely clear, the (bug) was reported to Microsoft on September 30 (along with) the 90-day disclosure deadline statement… which in this instance has passed.”

Still, some observers have raised questions about whether Project Zero does more harm than good if Google isn’t flexible with its publishing deadline. Others argued that Microsoft had plenty of time to fix the bug, and Google was firm about its policy. “Project Zero’s disclosure deadline… allows software vendors a fair and reasonable length of time to exercise their vulnerability management process, while also respecting the rights of users to learn and understand the risks they face.” But it also added that “we’re going to be monitoring the affects (sic) of this policy very closely.”

Meanwhile, Microsoft said that it’s currently “working to release a security update to address an Elevation of Privilege issue.” For full statements from both companies, see below.


We are working to release a security update to address an Elevation of Privilege issue. It is important to note that for a would-be attacker to potentially exploit a system, they would first need to have valid logon credentials and be able to log on locally to a targeted machine. We encourage customers to keep their anti-virus software up to date, install all available Security Updates and enable the firewall on their computer.


There was some confusion yesterday about whether we had contacted Msft about this issue, so we posted an update (below).

Firstly, just to make this absolutely clear, the ahcache.sys/NtApphelpCacheControl issue was reported to Microsoft on September 30. You can see this in the “Reported” label on the left hand panel of this bug. This initial report also included the 90-day disclosure deadline statement that you can see above, which in this instance has passed.

Project Zero’s disclosure deadline policy has been in place since the formation of our team earlier in 2014. It’s the result of many years of careful consideration and industry-wide discussions about vulnerability remediation. Security researchers have been using roughly the same disclosure principles for the past 13 years (since the introduction of “Responsible Disclosure” in 2001), and we think that our disclosure principles need to evolve with the changing infosec ecosystem. In other words, as threats change, so should our disclosure policy.

On balance, Project Zero believes that disclosure deadlines are currently the optimal approach for user security – it allows software vendors a fair and reasonable length of time to exercise their vulnerability management process, while also respecting the rights of users to learn and understand the risks they face. By removing the ability of a vendor to withhold the details of security issues indefinitely, we give users the opportunity to react to vulnerabilities in a timely manner, and to exercise their power as a customer to request an expedited vendor response.

With that said, we’re going to be monitoring the affects of this policy very closely – we want our decisions here to be data driven, and we’re constantly seeking improvements that will benefit user security. We’re happy to say that initial results have shown that the majority of the bugs that we have reported under the disclosure deadline get fixed under deadline, which is a testament to the hard work of the vendors.


Trust your VPN? Not if the NSA is Involved


This is a pretty interesting article, not just from the technical aspect, but also the humor factor when the NSA is using Star Trek Terms.

So – do you trust your VPN to protect you from NSAs prying eyes?

NSA has VPNs in Vulcan death grip—no, really, that’s what they call it


The National Security Agency’s Office of Target Pursuit (OTP) maintains a team of engineers dedicated to cracking the encrypted traffic of virtual private networks (VPNs) and has developed tools that could potentially uncloak the traffic in the majority of VPNs used to secure traffic passing over the Internet today, according to documents published this week by the German news magazine Der Speigel. A slide deck from a presentation by a member of OTP’s VPN Exploitation Team, dated September 13, 2010, details the process the NSA used at that time to attack VPNs—including tools with names drawn from Star Trek and other bits of popular culture.

OTP’s VPN exploit team had members assigned to branches focused on specific regional teams, as well as a “Cross-Target Support Branch” and a custom development team for building specialized VPN exploits. At the regional level, the VPN team representatives acted as liaisons to analysts, providing information on new VPN attacks and gathering requirements for specific targets to be used in developing new ones.

While some VPN technologies—specifically, those based on the Point-to-Point Protocol (PPTP)—have previously been identified as being vulnerable because of the way they exchange keys at the beginning of a VPN session, others have generally been assumed to be safer from scrutiny. But in 2010, the NSA had already developed tools to attack the most commonly used VPN encryption schemes: Secure Shell (SSH), Internet Protocol Security (IPSec), and Secure Socket Layer (SSL) encryption.

The NSA has a specific repository for capturing VPN metadata called TOYGRIPPE. The repository stores information on VPN sessions between systems of interest, including their “fingerprints” for specific machines and which VPN services they’ve connected to, their key exchanges, and other connection data. VPN “fingerprints” can also be extracted from XKEYSCORE, the NSA’s distributed “big data” store of all recently captured Internet traffic, to be used in identifying targets and developing an attack. Because XKEYSCORE includes data from “untasked” sources—people and systems not designated as under surveillance—the OTP VPN Exploitation Team’s presentation requested, “Try to avoid relying on (XKEYSCORE) workflows due to legal and logistical issues.” But XKEYSCORE, it was noted, is best for attacks on SSH traffic.

Analysis of TOYGRIPPE and XKEYSCORE data, as well as from “daily VPN exploits,” is fed into BLEAKINQUIRY—a metadata database of “potentially exploitable” VPNs. This database can be searched by NSA analysts for addresses matching targeted individuals or systems and to generate requests for the VPN Exploit crew to convert the “potentially” into an actuality.

When an IPSec VPN is identified and “tasked” by NSA analysts, according to the presentation, a “full take” of its traffic is stored in VULCANDEATHGRIP, a VPN data repository. There are similar, separate repositories for PPTP and SSL VPN traffic dubbed FOURSCORE and VULCANMINDMELD, respectively.

The data is then replayed from the repositories through a set of attack scripts, which use sets of preshared keys (PSKs) harvested from sources such as exploited routers and stored in a key database called CORALREEF. Other attack methods are used to attempt to recover the PSK for each VPN session. If the traffic is of interest, successfully cracked VPNs are then processed by a system called TURTLEPOWER and sorted into the NSA’s XKEYSCORE full-traffic database, and extracted content is pushed to the PINWALE “digital network intelligence” content database.

But for those that aren’t successfully cracked, the VPN Exploit Team’s presentation noted, the team works to “turn that frown upside down” by doing more data collection—trying to capture IPSec Internet Key Exchange (IKE) and Encapsulating Security Payload (ESP) traffic during VPN handshakes to help build better attacks. In cases where the keys just can’t be recovered, the VPN Exploit Team will “contact our friends for help”— gathering more information on the systems of interest from other data collection sites or doing an end-run by calling on Tailored Access Operations to “create access points” through exploits of one of the endpoints of the VPN connection.