Let's explore China’s 0-day vulnerability research capabilities.
I’ve long been intrigued by the prolific nature of Chinese teams in discovering vulnerabilities. Over the past months, I’ve gathered some data and analyzed reported vulnerabilities to gain a deeper understanding.🧵
Since September 2021, the Chinese government has mandated that any Chinese researchers, businesses, or even foreign companies operating in China who discover 0-day vulnerabilities must report the details to the Chinese Ministry of Industry and Information Technology (MIIT)
The policy in question was formalized through the "Provisions on the Management of Network Product Security Vulnerabilities" issued by MIIT, which obliges entities to report vulnerabilities within within two days (48 hours) of their discovery. chinalawtranslate.com/en/product-sec…
Companies are incentivized to drive cybersecurity research in China. Key labs like Qihoo 360, Tencent’s Xuanwu Lab, NSFOCUS, Ant Security Labs, Venus Tech, and Cyberkunlun have been at the forefront of vulnerability discovery and expertise.
While companies are encouraged to report findings to the vendor, under China's National Security (2015) and Cybersecurity (2017) Laws, vulnerabilities with national security implications may be classified as sensitive, restricting any form of public discussion or disclosure.
On the other hand, entities like China National Information Technology Security Evaluation Center (CNITSEC) conducts security evaluations and reviews of foreign technology products to assess potential risks to national security.
CNITSEC has been identified by cybersecurity companies as a front for the 13th Bureau of China’s Ministry of State Security, allegedly involved in cyber espionage and supporting Chinese APT groups. Their influence on global cybersecurity remains a significant concern.
While anecdotal evidence hints at China's extensive 0-day research, I'm looking for concrete data to assess its true scale. Considering the ubiquity of Microsoft Windows and the wealth of historical data from Microsoft, I turned to it for clearer insights.
To that effect, I collected all published vulnerabilities for Windows 10 x64 (Jan 2021 - Aug 2024) via the Microsoft CVRF API. After cleanup, the dataset reviewed contained 1,474 CVEs. github.com/microsoft/MSRC…
I cross-checked each vulnerability’s acknowledgements for Chinese nationals or companies operating from China. This painstaking process used sources like X, GitHub, and blogs to try and ensure the most accurate tagging. Some entries where there were doubts were excluded.
The findings were striking: 598 out of 1,474 analyzed CVEs were reported by Chinese nationals or companies, making up an impressive 40.5% of all published vulnerabilities for Windows x64.
While disclosure embargoes on vulnerabilities affecting national security, potential reporting delays, and ongoing reviews may obscure the true numbers, we can still analyze trends to identify where the focus has been concentrated over time.
Reported CVEs from China have grown by 10-15% year-on-year, despite bugs becoming harder to find. This likely reflects increased efforts by researchers to dig into more components or a heightened focus on thorough reviews yielding more bugs.
Examining the top reported vulnerabilities by component, 2021 saw a striking 35 CVEs in RPC Runtime alone, all reported by Yuki Chen—arguably the most prolific Windows researcher. The remaining CVEs with most reports were privilege escalations in several services.
In 2022, the spotlight seems to have turned to remotely accessible services like LDAP, PPTP, and ODBC/OLE for SQL, rising to prominence. This focus on targeting remote components has only grown stronger since.
By 2023, the focus shifted to kernel driver vulnerabilities, likely due to the increasing exploit mitigations by Microsoft. The surge in CVEs per component again highlights the effort towards highly detailed and thorough audits.
These in-depth, systematic audits are rarely seen by Western researchers, aside from Google Project Zero. They not only uncover subtle bugs but also build a knowledge base for future bug hunting by diffing the meticulously audited code with new releases.
Building on Yuki Chen's 2023 Blackhat presentation for Cyber Kunlun, we could already foresee this year's key focus areas. As expected, we been observing a strong emphasis on network protocols and drivers.
By August, we've already seen 23 CVEs tied to Secure Boot bypass and multiple network protocol bugs, including two high-profile vulnerabilities I've previously analyzed: CVE-2024-38063 (tcpip) and CVE-2024-30078 (wifi).
This is just a small sample, and future research should likely expand to other OSs like Linux, macOS, key browsers, and mobile platforms. However, I believe it clearly illustrates the focus, investment, and strategic alignment between the Chinese government and tech companies.
The work produced by Chinese researchers is nothing short of exceptional, highlighting the gap where Western governments and enterprises are falling behind. Meanwhile, Western researchers often work independently, with zero-day research closely tied to gray markets.
This is largely driven by strong incentives from the Chinese government and companies, in stark contrast to the lack of similar support from Western counterparts. This difference in approach significantly impacts the scale and focus of cybersecurity research.
On the flip side, Western companies often handle vulnerability triaging and disclosure poorly, leading to confusion and misjudgment of high-profile bugs' importance. Meanwhile, the Chinese government likely has full details, amplifying the concern.
Investing in research capabilities is crucial, and Western governments should offer better incentives to counter China's strategic edge. Greater collaboration among researchers, rather than focusing solely on individual gains, could further enhance progress.
If you found this thread insightful, consider giving a follow and sharing the first post. Your support keeps this kind of content coming!
End 🧵
• • •
Missing some Tweet in this thread? You can try to
force a refresh
It's time to take a closer look at CVE-2024-38063 (Windows TCPIP RCE).
I usually don't post partial analysis but since most available info is unreliable I'll do my best to try and shed some light.
This time I'll focus on my workflow and thought process as we go. 🧵
MSFT advisory pretty much tells us where to look.
Our target is the tcpip.sys kernel driver which got an update during last patch tuesday.
For the analysis I picked binaries for Windows 11 23H2, builds 3958 (pre-fix) and 4036 (post).
Diffing shows a single function has changed.
In fact, this is the best you could hope for on binary diffing.
Further inspecting the differences on Ipv6pProcessOptions() it comes down to a single change at the end.
A call to IppSendErrorList() has been replaced by IppSendError(). Couldn't get simpler than this right? 😅
Some final notes on CVE-2024-30078 (wifi RCE) exploitability.
If you haven't already done so, I recommend you first take a look at my previous thread on the subject.
🧵
As previously noted, the native driver does not account for 4 extra bytes when the ether type is 0x8100 (Vlan tagged net).
Since the packet is rewritten on the original buffer, it will do so 4 bytes ahead of what is was supposed to because of the dot1q header that should exist.
This will not only corrupt the translated packet (which will be later discarded as invalid) but also overwrite up to 2 bytes outside the MDL buffer that holds the packet. [overflowed bytes marked in red]
But is the exploitability feasible?
MSFT released a patch for CVE-2024-30078 (Wi-Fi Driver RCE) on June cumulative update, however details on the advisory have been very limited.
I'm leaving some quick notes from a quick reverse engineering of the patch that hopefully will shed a little more light on the issue. 🧵
I am not an expert on wireless network protocols so feel free to correct me or add up on the provided info in the comments or through a DM.
The patch targets Dot11Translate80211ToEthernetNdisPacket() of the native wifi driver (nwifi.sys).
The patch expands on a previous check at the beginning of the function which is described in the pseudocode below:
Inspired by @osxreverser analysis of NSA BPF port-knocking implant, I decided to take a 2nd look at #ShadowBrokers leak of windows implants. Lo and behold, a couple of hardly mentioned kernel drivers (#DoormanGauze and #FlewAvenue) caught my attention. (1/11)
Information publicly available on these drivers is scarce and for the most part flat out wrong. Instead of going for the usual deep-dive blog post, lets try a light-speed tweeter thread analysis. In this thread we'll take a brief look at #DoormanGauze. (2/11)
So, what is #DoormanGauze... In a nutshell, its a plugin for #DanderSpritz / #ExpandingPulley implants implementing an in-kernel mailslot server, allowing for stealthy inter-process communication. This can replace the usual named pipes/windows sockets IPC. (3/11)