Like last year, this year’s GreHack edition was split into two days, one for the conference and workshops and the other for the CTF.

Once again, RandoriSec sponsored the event, and several RandoriSec consultants attended the conference.

This blog post goes over a few of our favourite talks.

CTF in a box ? The weirdest NETGEAR network switch 2021 exploit chain - Gynvael Coldwind

In this talk, Gynvael took us on the adventure of how he chained multiple vulnerabilities to gain RCE on a NETGEAR Network Switch with full-root privileges. While the vulnerabilities affected multiple NETGEAR devices, everything was tested on the NETGEAR Smart GS108Tv3.

The story started when he wanted to configure the SFP on his NETGEAR switch. He was exploring the maintenance settings on the web interface when he stumbled across a command injection bug. This bug required admin authentication. Admin users could already modify part of the firmware because it is not signed, so the bug did not have much impact on its own.

From there, he wanted to find a full-exploit chain to get RCE from minimal privileges to root. So he moved to dumping the firmware to further analyse the internals of this switch.

During the first analysis, he found some other command injection vulnerabilities as well as some buffer overflow issues. Those were reported and patched, but showed that the firmware’s quality was not great security-wise.

During a second analysis, Gynvael started looking at the authentication flow. He first observed an issue with the authentication made in two distinct HTTP requests, which allowed a race condition to steal an admin session while using the same IP address to access the switch. This was also reported and patched.

To actually gain access without any user action, he found another vulnerability in the authentication flow, giving him a file write. This happens after the password gets sent to the /cgi/set.cgi?cmd=home_loginAuth handler, which will create a session authentication file with the name /tmp/sess/guiAuth_info_<HANDLER-PID>.

This file contains 6 fields, one line each, with the second line being the input password. There was no validation on the password, which allowed for CRLF injection. One of the fields is the path to the session file, so by overwriting it using the CRLF injection, he got a somewhat arbitrary file write where he does not fully control the content of the file, as it’s always an integer indicating the connection status (2 with a wrong password).

He then tried to gain a valid session using this arbitrary write to write a session file. However, when performing an authenticated request, the session token is decrypted using RSA to get a g_sessId which is used to generate the session file path /var/tmp/sess/login_http_<g_sessId>. Due to a lack of a success check on the decryption, it’s possible to send invalid encrypted data and have the g_sessId be empty, thus using the predictable /var/tmp/sess/login_http_ as the session file.

Again, due to a lack of a success check when parsing the sessions file with only a 2, all fields of the session after the first one will be set to 0. One of the fields is a timestamp of the session to know if it expired or not, and setting it to 0 makes the session always expire. However, that timestamp represents the number of seconds since the boot of the switch, so 0 is a valid timestamp for a session early after a reboot.

To cause a reboot, he uploaded a big file to the server, making it consume all the RAM, which resulted in an OOM issue. By default, the switch does not panic on OOM, but by writing 2 using the arbitrary file write (as root) to the kernel configuration files to reconfigure OOM behaviour, he managed to trigger the reboot.

Once the device reboots, the fake admin session is valid and will let him authenticate as an admin.

Finally, he chained that with the command injection bug discussed in the beginning to get a ROOT shell!

The talk was great and informative, as it showcased a methodology for chaining vulnerabilities and a great exploit chain with a variant of vulnerability classes.

Adobe and SAP: All Your Business Documents Belongs to Us - Yvan Genuer and Fabian Hagg

This presentation was about vulnerability research on SAP.

SAP is the well-known software ecosystem used by large companies to manage their resources. The two researchers focused on the Adobe Document Service (ADS). ADS is a centralized service that is used to handle PDF documents. It was co-developed by SAP and Adobe. The goal of this service is to assist with PDF documents generation.

First, the researchers discovered that they could get access to the ADS without any authentication. ADS expects to input data to be serialized in the Adobe XFA (XML Forms Architecture) format. This format allows the execution of JavaScript code. The JavaScript code can be executed directly on the server that generates the PDF file.

They discovered that the ADS uses the IIOP protocol to exchange information between the different components of the ADS and that it exposes the IIOP server to the outside. The IIOP protocol is based on the CORBA architecture, which is used to exchange object information in a distributed system. The main ADS component that uses this protocol is named XMLForm. When that binary is executed, it takes as input an Interoperable Object Reference (IOR). The IOR provides the client with information to access a “Manager” service. This reference contains a key that allows the XMLForm binary to access it.

The key is a 12-byte sequence that is built from:

• The server ID (4 bytes)
• The object ID (1 byte)
• A timestamp (7 bytes)

They attempted to obtain a valid key for the “Manager” service.

The IIOP server restricts the access of some ADS components using an allowlist for remote access to the service. However, they found a way to bypass the allowlist. They did not find the service responsible for generating the keys; therefore, they tried to brute-force one to gain access to the “Manager” service. They obtained the server ID through a simple request to an internal service of the ADS. To obtain the object ID and timestamp, they abused the ADS organization when multiple documents are managed. In this situation, the ADS creates a new key manager. Therefore, they can predict the timestamp and the object ID since they are defined in a predictable way when a new key manager is created. Once they had access to the “Manager” service, they were able to transfer the PDF generated from the local XMLform to a remote service controlled by the attacker. With this access, they can extract private information from the different requests made to the server, as well as tamper with the data in the generated PDF files.

The ADS allows an authenticated user to store a PDF file on the server. However, the file can be written anywhere on the system. They were able to override a Bash script, which is executed each time a document is generated. They replaced it with a Polymorphic PDF, which is considered a Bash script when it is executed. This way, they gained arbitrary code execution on the server.

SAP has been notified of all the vulnerabilities and has patched them.

Smart Charger, Dumb Idea? - Aymeric Palhière

In this talk, Synacktiv gave an overview of their work on the EV charging category of Pwn2Own.

The talk went over the attack surfaces in this type of device. This includes things like USB stack being accessible through ports on the device, back-end administration connectivity, BLE command handling, or even PLC data exchange through the charging port CP line.

After going over a couple of ways to extract firmware from the device (JTAG, online access, companion apps, etc.), a few examples of bugs used for the competition were listed.

These bugs are rather basic, as they include simple command injection, basic buffer overflow leading to memory corruption, etc. The talk showed that most devices make use of cheap MCUs lacking proper memory protection features. This, coupled with a lack of basic memory corruption mitigation, made code execution fairly straightforward with this type of bug.

Some logic bugs were also discovered. Notably an issue caused by a lack of firmware downgrade protection, allowing, with some clever hardware setup, the abuse of an update feature through the charging port CP line to eventually reach code execution on the Tesla charger.

Overall, the talk made a good point in showing that this type of connected device is often designed with security as an afterthought; thus lacking very basic security mitigation, such as NX stack, stack cookies, etc. It also demonstrates that the multiplication of connectivity features heavily increases the attack surface; thus giving a lot more chances for something to go wrong.