Conference:  Defcon 31

Authors: Bohan Liu Senior Security Researcher, Tencent, GuanCheng Li Senior Security Researcher at Tencent Security Xuanwu Lab, Zheng Wang Senior Security Researcher at Tencent Security Xuanwu Lab

2023-08-01

Chromium is not only the most popular browser in the world but also one of the most widely integrated supply chain components. Nowadays, a large number of popular software is built on frameworks based on Chromium, such as CEF and Electron. This means that vulnerabilities in Chromium will directly affect popular software. In addition, according to Google's vulnerability disclosure policy, most of the details of Chromium vulnerabilities will be publicly disclosed 14 weeks after being fixed, and many of these vulnerabilities are high-impact and may lead to RCE. Unfortunately, we have found that much downstream software is unable to timely fix the Chromium vulnerabilities. This creates a window of opportunity for attackers to carry out RCE attacks on popular software. The cost for attackers to exploit these vulnerabilities during this window is relatively low, as it falls between the time of the Chromium vulnerability disclosure and the completion of fixes for popular software. We refer to this window as the "RCE window period". In this topic, we will first evaluate the "RCE window period" of more than 20 popular software. In the upcoming section, we will showcase how to transform Chromium nday vulnerabilities into popular software 0day vulnerabilities in a low-cost manner within the "RCE window period". To illustrate this process, we will use over 10 RCE 0day vulnerabilities in popular software that we have discovered as examples. Some software will attempt to enable sandbox to mitigate this problem, so we will also provide examples of how to bypass the sandbox by exploiting vulnerabilities in the software itself rather than a Chromium sandbox bug. Finally, we will discuss the reasons for the existence of the RCE window period and the lessons learned from it, hoping to help software developers improve the security of their products.

Conference:  Global AppSec San Francisco 2022

Authors: Zohar Shchar, Dmitry Ryskin

2022-11-18

When doing application security for an API–centric enterprise spanning over thousands of micro services, Dynamic Application Security Testing (DAST) is almost a must-have. However, DAST products often fail to execute even the most rudimentary tests on internal endpoints that require a complex user flow. If an API call requires an ID that was obtained in the response BODY 5 HTTP calls ago, the chances a traditional DAST will be able to test your API are slim.In this talk we’ll present our approach for solving this issue, by leveraging existing headless-chrome test suites (built by the engineers as part of the R&D flow) to serve as the attack surface for our custom DAST solution, Krampus. By using Chromium interceptors, we were able to introduce appsec payloads into HTTP requests issued during the execution of normal 'user flow' test scenarios (and pick up the results) and have an effective DAST for internal API's and endpoints.It wasn't smooth sailing, though, with many challenges along the way. Particularly, we realized that replicating each API call & param with a separate test will mean that the number of our test calls grows exponentially, pushing up both cost and overhead. As many of our API’s also include dynamic params as part of the path, we had to build an API asset DB to understand if and when a specific URL was already tested (code for which we plan to release as open source).At the end of the talk the participants will have the tools to leverage similar testing suites in their own orgs to drastically improve the quality & coverage of the automatic testing in their environment.