Author: Thomas Chauchefoin

As part of our continuous effort to improve our Clean Code technology and the security of the open-source ecosystem, our R&D team is always on the lookout for new 0-day security vulnerabilities in prominent software.

We recently uncovered two critical code vulnerabilities in a personal cloud solution named CasaOS. CasaOS can be installed on any machine thanks to Docker and comes with end-user NAS devices like the ZimaBoard or the X86Pi. Users deploy CasaOS to store their personal data on devices they trust and access it from anywhere.

Developers were told to use ORMs and prepared statements to avoid SQL injections for a long time now. By doing so, they effectively separate instructions (the semantics of the SQL query) from the data. Modern languages and frameworks often also abstract away the need to write raw queries, offering high-level interfaces around our database models. Unfortunately, that's not enough to thwart away SQL injections once and for all, as these APIs can still present subtle bugs or nuances in their design.

In this blog post, I show you how the misuse of a Golang ORM API introduced several SQL injections in Soko, a service deployed on the Gentoo Linux infrastructure. Then, I look further into assessing the impact of this vulnerability by using a PostgreSQL feature to execute arbitrary commands on the server.

As a web developer, do you really know what content types are? Sure, something like text/html should ring a bell, but are you also aware that getting them wrong can lead to security vulnerabilities in your application? 

In this article, I will first give you a recap of what content types are and what they are used for. I will then show how important it is to get them right in your code by explaining how a small mistake led to a Cross-Site Scripting vulnerability in Odoo, a popular open-source business suite written in Python. Odoo has features for many business-critical areas, such as e-commerce, billing, or CRM, making it an interesting target for threat actors.

SmartStoreNET is the leading open-source e-commerce platform for .NET, which makes it suitable for companies running Windows Server. Next to the operation of an online business, it offers advanced features, such as CRM tools, a blog, and a forum. As a result, a SmartStoreNET instance handles highly sensitive data such as credit card, financial, and personally identifiable information that have to be protected from attackers. 

During recent security research, my team and I discovered two vulnerabilities that could allow attackers to gain control of the server where SmartStoreNET is installed by sending one malicious message to the instance's administrator. In this article, I present the root cause analysis of two Cross-Site Scripting bugs and then describe how they could be exploited by attackers. Finally, I will describe the patches applied by the maintainers and the limitations of those patches.

GoCD is a popular Java CI/CD solution with a large range of users, from NGOs to Fortune 500 companies, with billions of dollars in revenue. Naturally, this makes it a critical piece of infrastructure and an extremely attractive target for attackers. In a previous article, Agent 007: Pre-Auth Takeover of Build Pipelines in GoCD, the SonarSource R&D team demonstrated how unauthenticated attackers could impersonate build agents and access features that were previously protected by authentication mechanisms (CVE-2021-43287), leading to the disclosure of credentials and sensitive tokens for third-party services. 

In this follow-up article, I describe three additional vulnerabilities discovered and responsibly disclosed by the SonarSource R&D team in GoCD 21.2.0 and below. First, a vulnerability that can be used by attackers impersonating build agents to force administrators to perform security-sensitive actions without their knowledge (CVE-2021-43288). Then, two additional vulnerabilities could be chained, with the first one fully compromising the targeted instance by executing arbitrary commands (CVE-2021-43286, CVE-2021-43289) on the server hosting GoCD. These findings are already addressed by the latest release of GoCD: this article aims to share the root cause analysis and insights on how they could be exploited. 

Status pages are now an essential service offered by all Software-as-a-Service companies. To help their adoption, startups quickly conceived status pages as-a-service, and open-source self-hosted alternatives were made available. Cachet, also sometimes referred to as CachetHQ, is a broadly adopted status page system written in PHP and has many community forks such as fiveai/Cachet. 

Compromising Cachet instances is rewarding for attackers, as they store secrets for various services such as caches, databases, email servers, etc. This initial foothold in the infrastructure is helpful for them to pivot into the internal network of the affected company and to perform further attacks. In this article, I present the technical analysis of three security bugs my team and I discovered in Cachet 2.4. They can enable attackers to compromise the server. 

WordPress is the world’s most popular content management system, used by over 40% of all websites. This wide adoption makes it a top target for threat actors and security researchers that get paid for reporting security issues through their public bug bounty program. 

Vulnerability brokers are also very interested in acquiring unpatched vulnerabilities enabling them to take over WordPress instances, sometimes offering up to $300,000 for critical ones. As such, WordPress has a heavily reviewed code base in which researchers are not expected to find low-hanging fruits anymore. My previous research on this target required extensive expertise and effort to uncover security issues. 

During my team's security research on an authentication module for Apache2, my team and I identified an issue introduced by how the HTTP server Apache2 and modern web browsers parse URLs differently. Although the general problem of differential URL parsing has been documented publicly, I think it did not get the attention it deserved. It can impact a broad range of software and introduce vulnerabilities in critical features like authentication flows and requests to internal services.

In this blog post, I detail how differential URL parsing bugs can occur and what URL parser libraries are affected. I'll use a recent bug that we discovered in mod_auth_openidc, a popular Apache2 module, to give you a real-life example of this pattern and then show you how to detect similar bugs in your application through differential testing easily. With this, I hope to raise awareness about these subtle bugs and add a new item to your toolbox!