Keen Lab discovered new security vulnerabilities on Tesla motors and realized full attack chain to implement arbitrary CAN BUS and ECUs remote controls on Tesla motors with latest firmware.

Several highlights for 2017 Tesla Research:

• Realized full attack chain as we did in year 2016 to implement arbitrary CAN BUS and ECUs remote controls.
• Discovered multiple 0Days in different modules. Currently, Keen Lab is working with Tesla and related manufactures on assigning CVE number of the vulnerabilities.
• Tesla implemented a new security mechanism “code signing” to do signature integrity check of system firmware that will be FOTAed to Tesla motors in Sept 2016. The code signing was bypassed by Keen Lab.
• The “Group lighting show of Model X” in our demonstration is technically arbitrary remote controls on multiple ECUs at the same time. It shows Keen Lab’s research capability on CAN BUS and ECUs.

Keen Lab has followed “responsible disclosure” process to reported all security vulnerabilities and related exploitations to Tesla. Tesla Product Security Team has verified and confirmed all the bugs in our report. Security patches have been made and updated to motors via FOTA efficiently in July. The reported issues affect multiple models of Tesla motors. Based on Tesla’s report, most of the active Tesla motors have been updated to new firmware with patches via FOTA. We appreciate Tesla Product Security Team for their quick response, quick fix and efficient patching via FOTA.

Reminder to Tesla car owners: Please check if your car is with the firmware version 8.1 (17.26.0) or later. If NOT, please upgrade to the latest firmware to ensure all the issues are fixed.

The video below demonstrates the impact of our remote attack vector. REMINDER: WHAT YOU ARE ABOUT TO SEE IN THIS VIDEO ARE PERFORMED BY PROFESSIONAL RESEARCHERS, DO NOT TRY THIS AT HOME. Appreciate Tencent Auto for the contributions on publishing this demonstration.

This blog post is about a new type of vulnerabilities in IOKit I discovered and submitted to Apple in 2016. I did a brief scan using a IDA script on MacOS and found at least four bugs with 3 CVEs assigned (CVE-2016-7620/4/5), see https://support.apple.com/kb/HT207423. I was told afterwards that there’re even more issues of this type on iOS’/OSX’s IOKit drivers and fortunately Apple fixed them also.

Read More...

A Detailed Description of CVE-2016-0176 and Its Exploitation

Essentials of a Successful Pwn of Microsoft Edge

A successful Pwn of Microsoft Edge consists of two essential parts: Browser RCE(Remote Code Execution) and browser sandbox bypass. Browser RCE is typically achieved by exploiting a Javascript vulnerability, while browser sandbox bypass can be achieved in different ways, logical sandbox escape or EoP(Escalation of Privilege) through kernel vulnerabilities.

Sandbox of Microsoft Edge is built upon the access check mechanism. In Windows operating system, resources are shared in system-wide range, for example, a file or device can be shared across different processes. Some resources contain sensitive informations, some others are critical to the whole system’s well-functioning, corruptions of those resources will crash the whole system. For those reasons, there should be strict checks when a process want to access a specific resource, this is called access check. When a resource is opened, token of the subject process will be checked against security descriptor of the object resource. Access check consists of several elementary checks in different dimensions, such as ownership and group membership check, privileges check, integrity level and trust level check, capabilities check, etc. The previous generation sandbox is based on integrity level check, where the sandboxed application runs in low integrity level, thus it can not access resources protected by medium or higher integrity level. Microsoft Edge adopts new generation sandbox based on AppContainer, where additional capabilities check will be conducted when accessing resources, besides basic integrity level check. For more details about access check mechanism, refer to my talk at ZeroNights 2015: Did You Get Your Token?

Read More...

With several months of in-depth research on Tesla Cars, we have discovered multiple security vulnerabilities and successfully implemented remote, aka none physical contact, control on Tesla Model S in both Parking and Driving Mode. It is worth to note that we used an unmodified car with latest firmware to demonstrate the attack.

Following the global industry practice on “responsible disclosure” of product security vulnerabilities, we have reported the technical details of all the vulnerabilities discovered in the research to Tesla. The vulnerabilities have been confirmed by Tesla Product Security Team.

Keen Security Lab appreciates the proactive attitude and efforts of Tesla Security Team, leading by Chris Evans, on responding our vulnerability report and taking actions to fix the issues efficiently. Keen Security Lab is coordinating with Tesla on issue fixing to ensure the driving safety of Tesla users.

As far as we know, this is the first case of remote attack which compromises CAN Bus to achieve remote controls on Tesla cars. We have verified the attack vector on multiple varieties of Tesla Model S. It is reasonable to assume that other Tesla models are affected. Keen Security Lab would like to send out this reminder to all Tesla car owners:

PLEASE DO UPDATE THE FIRMWARE OF YOUR TESLA CAR TO THE LATEST VERSION TO ENSURE THAT THE ISSUES ARE FIXED AND AVOID POTENTIAL DRIVING SAFETY RISKS.

The video below demonstrates the impact of our remote attack vector. REMINDER: WHAT YOU ARE ABOUT TO SEE IN THIS VIDEO ARE PERFORMED BY PROFESSIONAL RESEARCHERS, DO NOT TRY THIS AT HOME.

In previous blog posts Liang talked about the userspace privilege escalation vulnerability we found in WindowServer. Now in following articles I will talk about the Blitzard kernel bug we used in this year’s pwn2own to escape the Safari renderer sandbox, existing in the blit operation of graphics pipeline. From a exploiter’s prospective we took advantage of an vector out-of-bound access which under carefully prepared memory situations will lead to write-anywhere-but-value-restricted to achieve both infoleak and RIP control. In this article we will introduce the exploitation methods we played with mainly in kalloc.48 and kalloc.4096.

First we will first introduce the very function which the overflow occurs, what we can control and how these affect our following exploitation.

Read More...

From my last blog post “WindowServer: The privilege chameleon on macOS (Part 1)”, we discussed some basic concepts, the history and architecture of WindowServer, as well as the details of CVE-2016-1804 - A Use-After-Free (Or we can also call it double free) bug with very small time window. Several troubles still exist before we can write the exploit code of this bug, now let’s resolve them one by one.

Read More...

When talking about Apple Graphics, the WindowServer component should not be neglected. Rencently KeenLab has been talking about Apple graphics IOKit components at POC 2015 “OS X Kernel is As Strong as its Weakest Part“, CanSecWest 2016 “Don’t Trust Your Eye: Apple Graphics Is Compromised!“, and RECon 2016 “Shooting the OS X El Capitan Kernel Like a Sniper“, however the userland part is seldomly mentioned in public.

This week Pwnie announced bug nominations for 2016, where the windowserver bug CVE-2016-1804 is listed , it made me think of writing something. But when I started writing, I realized it is a long story. Then I realized a long story can be cut into short stories (I also realized my IQ is low recently which many of my colleagues have pointed out, due to extremely hot weather in Shanghai maybe, or not…)

So…I decided to split the whole story into 3. In part 1, I will mainly focus on the history of windowserver, basic concepts, architecture, CVE-2014-1314 (A design flaw which we used to take down OS X Mavericks at Pwn2Own 2014) and finally, details of the pwnie nomination bug: CVE-2016-1804, which we used to take down the latest OS X El Capitan remotely with a browser exploit and escalated to root privilege. However when I first discovered CVE-2016-1804 last year, it had been considered unexploitable, at least for 1 week. Part 1 then wrapped up here with questions/challenges.

Next week I will release part 2 for the partial exploitation by introducing an 0day which gave me inspiration of the successful exploitation of CVE-2016-1804. The last part: part 3, which is the most exciting part, is NOT a blog post, instead it will be discussed at Black Hat 2016 Briefings “SUBVERTING APPLE GRAPHICS: PRACTICAL APPROACHES TO REMOTELY GAINING ROOT“

Ok, now let’s start the short story:

Read More...

There was a time that every Linux kernel hacker loves Android. It comes with a kernel from stone-age with merely any exploit mitigation. Writing exploit with any N-day available was just a walk in the park.
Now a days Google, ARM and many other SoC/device vendors have put many efforts hardening the security of Android, including its kernel, which is (in most cases) the last defense against attack.

As a group of Android gurus focusing on rooting, we probably facing these defense more than researchers in other fields. In this post we are going to summarize kernel exploit mitigations appeared in the recent 2 years, and sharing our opinions on their effectiveness.

Note that we are going to focus on the implementation of mitigations in this post. We may point out its weakness, but we are not going to detail bypassing techniques for each mitigation.

Read More...

Partly estimated, until May 2016, KeenLab has totally found 152 critical vulnerabilities with CVE IDs, ranging from mainstream OS to browsers and applications

Read More...