[et_pb_section fb_built= »1″ _builder_version= »4.21.0″ _module_preset= »default » global_colors_info= »{} »][et_pb_row _builder_version= »4.21.0″ _module_preset= »default » width= »86.2% » min_height= »2656.4px » custom_margin= »|127px||2px|| » custom_padding= »5px|0px||0px|| » global_colors_info= »{} »][et_pb_column type= »4_4″ _builder_version= »4.21.0″ _module_preset= »default » global_colors_info= »{} »][et_pb_text content_last_edited= »off|desktop » _builder_version= »4.21.0″ _module_preset= »default » header_2_font_size= »16px » header_3_font_size= »18px » header_4_font= »|||||||| » width= »99.8% » custom_margin= »|-246px||-8px|| » custom_padding= »|0px||5px|| » global_colors_info= »{} » content__hover_enabled= »off|desktop »]

For the 20th anniversary of SSTIC, Intrinsec was present to attend this edition of 34 presentations and 22 rumps in Rennes, from June 7 to 9, 2023.

First and foremost, a huge thank you to the organizing and programming committees for the high quality of this event in every respect.

The conferences offered at this cybersecurity-focused event covered a wide range of topics. From discovering vulnerabilities on Steam to those in Tesla cars, from Windows protocols to developing source code analysis tools, from a PIN recovery method to using artificial intelligence for cybersecurity, there was something for everyone. I'll share my experience of SSTIC 2023 from a penetration tester's perspective in two parts: first, by reviewing the presentations directly related to penetration testing, the subject of this first article, and then by highlighting three of my favorites, available [here/online]. here.

The presentations are available on video at the SSTIC website, as well as the collection of articles.

Introductions and the job of a pentester

Among the various presentations, and although the fields of cybersecurity all overlap, some topics presented have a closer link to the profession of pentester than others.

Discovery and exploitation of chained vulnerabilities

This is particularly the case with the conference presented by Kevin Gervot on the exploitation of an attack Client-Side Desync (CSD) leading here to an XSS. CSD are a variant of the attacks of request smuggling These vulnerabilities, which came to the forefront last year, exploit client-server desynchronization, allowing attackers to arbitrarily modify the next request sent to the server and retrieve its response. In this case, it all stemmed from a "parsing bug.".

The author was developing a Flask application and using the Web Server Gateway Interface (WSGI) from Werkzeug development, a solution that allowed him to set up an HTTP server. During its testing phases, he encountered the following bug: the Flask application was not retrieving POST parameters:

Figure 1 – Parsing bug (Excerpt from the SSTIC presentation – slide 2/27)

The client communicates with Werkzeug which acts as an intermediary and processes the connection queue according to Flask's definition, i.e., without considering the POST parameters, before sending the request to the server. The POST parameters are then stored in the connection queue and subsequently sent to the server as a prefix for the next request. This behavior is also explained by the connection management of newer versions of Werkzeug, which enforce "keep-alive" mode (when the "threaded" and "processes" options are enabled in the configuration). This mode instructs the server to maintain the same connection queue for all subsequent requests. This leads to a CSD vulnerability, which can be exploited as follows:

Figure 2 – Operation of a CSD (Extract from the SSTIC presentation – slide 12/27)

The question then arises of how to leverage this initial vulnerability to increase the severity of an attack scenario on this environment. By researching a previously patched, free redirection vulnerability affecting Werkzeug, the author circumvented the patch by starting the network location portion of the URL with double slashes; this portion would be recorded as the host of the next request. The resulting redirection is a 308, "permanent redirect," which caches the new location information in the browser.

By combining the CSD attack and free redirection, an attacker is able to forge a form that performs the following actions when submitted by a victim:

• An initial request is sent to the vulnerable application. It is constructed to modify the next request received by the server (CSD exploitation); ;
• Modifying the next request results in a free redirection to a resource controlled by the attacker;
• When a script file called on the application page is loaded, the malicious redirection will be effective and cached in the browser;
• The request made to retrieve a script file will then retrieve the attacker's malicious resource, which will be executed by the browser: the attack results in an XSS.

This discovery led to CVE-2022-29361, the proof of concept in video set format available here. There remediation results in the correction of Werkzeug's "keep-alive" connection management, by cutting off the connection when an HTTP request is issued and then its response is sent.

Code analysis tools

Code analysis tools are an essential part of a penetration tester's daily work, particularly for code audits or white-box penetration testing. This topic was addressed in two presentations on automated vulnerability scanning tools, and in a third on JavaScript dumping during user browsing.

Automated vulnerability scanning via Semgrep

A first source code analysis tool, Semgrep, Claudio Merloni presented it as a tool for vulnerability research. Various analytical approaches are possible to identify security, configuration, or syntax flaws, for example, and these involve applying rules to find defined patterns. These rules are declared as YAML files. The tool's very active community allows it to support a wide range of languages and to have a rich library of dedicated rules.

Initially, the tool parses the source code files using tree sitter in order to represent the code as a tree diagram (AST) so that it can then be analyzed. Different analysis modes are available: search, stain, extract Or join. The main mode, search, It proposes analyzing files one by one for speed, and performing an "intra-procedural" analysis; it can be improved using the mode stain. This mode allows you to track an unreliable variable (from user input, for example) throughout its execution chain. extract, This, on the other hand, corresponds to the analysis of code included in another language, taking into account multiple files (for example, to analyze all the JavaScript in HTML files). Finally, the mode join allows us to link the results found using different rules and to highlight the potential link that exists, which can be likened to inter-procedural analysis.

The use of semgrep and its different modes makes it possible to highlight vulnerabilities present in source code, as illustrated during the presentation with the detection of SSRF and SQLi.

Automatic vulnerability scanning via Weggli

There presentation which followed, in turn, answered the question: Do automated code analysis tools work in real life? In response to this issue, the author, Kevin Denis (@0xMitsurugi), gave himself a week to use one of these tools, Weggli, which takes up the philosophy of Semgrep, that is to say the search for patterns in code.

The first step was therefore to find patterns. To do this, one approach was initially pursued: writing vulnerabilities and then generating rules to detect them. However, this process lacked realism, significantly reducing the chances of finding vulnerabilities in production environments using the defined patterns.

Ultimately, another approach proved more fruitful: working upstream on the patterns that could be the source of defects and refining them to detect targeted vulnerabilities, by focusing, for example, on the use of sensitive functions such as strcpy And strncpy. The author has divided his rules, available on github, in 3 categories:

• • Dangerous functions
  • Stack management
  • The different types of malloc

The main challenge was finding a balance between the precision of the patterns used to identify defects and the number of false positives. Indeed, the less precise the patterns, the higher the number of results reported, which in turn increases both the number of actual defects and false positives, making analysis more difficult.

To illustrate his answer to the initial problem, the author applied his rules to Qemu, Samba, and VLC, and found flaws in Samba and VLC. The vulnerability identified in VLC led to the CVE 2022-41325, the exploitation of which is relatively simple in the absence of ASLR, but can lead to VLC crashing or arbitrary code execution under certain conditions.

This presentation therefore highlighted that code analysis tools, with the help of a security researcher (or pentester), can indeed make it possible to discover real vulnerabilities.

JavaScript Analysis

Furthermore, JavaScript analysis of a user's activity on their browser has been presented by Erwan Abgrall, via the tool ChromeDump. This tool allows you to retrieve the JavaScript code executed during browsing in Chrome using the Chrome DevTools protocols and WebSockets. Although its primary use case is the defensive analysis of a compromised web application, which was the subject of the presentation, the tool also appears to be quite useful for penetration testing. Indeed, the tool offers the ability to retrieve the browsing profile, JavaScript activity, retain URLs, resources, requests and responses exchanged, and capture screenshots of the various actions performed. Furthermore, a feature of’unpacking A tool for deobfuscating the first layers of JavaScript is available. These results could lead to a better understanding of certain client-side application behaviors.

Enriching its recommendations

Other presentations may also be of interest from a penetration testing perspective to improve recommendations offered to clients, such as the one on the tool Mercator allowing the mapping of an information system, or even on the tools gmsad And OpenWec developed by the CEA to extend certain Windows concepts to Linux environments.

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]