Open Web Analytics (OWA) is an open-source alternative to Google Analytics. OWA is written in PHP and can be hosted on an own server. Version 1.7.3 suffers from two vulnerabilities, which can be exploited by an unauthenticated attacker to gain RCE, when chained together.
The cause of the first vulnerability (CVE-2022-24637) is a single quote / double quote confusion, which leads to an information disclosure. The header of an automatically generated PHP cache file containing sensitive information is defined as '<?php\n…' instead of "<?php\n…". This leads to a literal backslash and n character being written instead of a newline character resulting in a broken PHP tag. Because of this the file is not interpreted as PHP code, but delivered in plain leaking sensitive cache information. This information can be leveraged to set a new password for the admin user.
The second vulnerability is a PHP file write, which requires admin privileges. The internal settings for the logfile path as well as the log level can be changed by manually crafting a POST request. This way the logfile can be set to a PHP file. By also increasing the log level and generating an event with attacker controlled data, PHP code can be injected into this logfile. This results in the possibility to execute arbitrary PHP code.
I would like to thank Peter Adams, the creator and maintainer of OWA who released a patch for the issue only one day after my initial notification. I was really amazed by the quick and professional reaction. There are security issues in each and every software, but the difference is how these are dealt with.
The mpv media player provides a custom protocol handler (mf://) in order to merge multiple images to a video. An undocumented feature within this protocol handler allows the usage of a format specifier in the provided URL, which is evaluated using sprintf. This results in both, a format string vulnerability as well as a heap overflow (CVE-2021-30145).
After disclosing the vulnerability to the mpv team on the 3rd April 2021 I got an immediate response. The mpv team took the issue very seriously and immediately started to work on a patch with me. This was the first time I disclosed a vulnerability to an open source project and I was really impressed about the professional reaction and the passionate commitment. The patch was released only two days after my report on the 5th April 2021 (commit). Thanks a lot to avih, sfan5 and jeeb.
The impact of the format string vulnerability is limited on Linux, because the binary is compiled with FORTIFY_SOURCE by default. Though the heap overflow can be used to gain arbitrary code execution by overflowing into an adjacent heap chunk and setting a function pointer to an attacker controlled value. Nevertheless I estimate the probability of exploitation in real life as quite low, because a victim has to be tricked into opening a malicious playlist (e.g. via a URL like http://10.0.0.1/evil.m3u) and the attacker has to have detailed information about the victim’s system to fine-tune the exploit.
Within this article I describe the vulnerability itself as well as the development of a proof of concept exploit for Ubuntu 20.04.2 LTS with ASLR disabled. At the end of the article I outline a few thoughts on how ASLR can be bypassed and what changes if we develop an exploit for Windows. The article is divided into the following sections:
One of my goals for this year is to spend a little bit more of my spare time on real world applications. Doing so I took a look at the remote desktop application AnyDesk, which seems to quickly raise in popularity not only because of COVID-19. AnyDesk is available for a variety of operating systems including Windows, Linux, Android and iOS. By reversing and fuzzing the Linux version 5.5.2 of the application I was able to find a format string vulnerability, which can be used to gain Remote Code Execution (RCE) by sending a single UDP packet to the target machine. AnyDesk took the issue very seriously. They released a patch only three days after my notification (5.5.3) and paid me a bounty of 5.000 EUR. The vulnerability is tracked as CVE-2020-13160. Within this article I want to share all steps, which were involved in finding the vulnerability, understanding the bug and developing the RCE exploit. The article is divided into the following sections:
The goal of this article is to explain in detail how an off-by-one vulnerability on the heap also known as poison null byte can be exploited. Although this technique does not work with the latest libc, I think it can be used very good in order to demonstrate how exploits based on heap-metadata corruption work (also check out shellphish’s how2heap).
In order to do this I created a vulnerable program, which we will use as an example to create such an exploit. If you like to, you can start by analyzing and exploiting the program on your own (at least check out Environment):