From a security point of view, application logs are two-sided. On the one hand, it is really important to have good observability, to find out what is happening and what has happened. On the other hand, we don’t want to leak sensitive information. In this post I am going to look at the kinds of things you might find in your logs. The juicy bits are Personal Identifying Information (PII) or security credentials.

Let me tell you a story about Application Security (AppSec). It contains heroes and villains, and I’m not necessarily thinking about the defenders and attackers here. It contains lots of interesting technology that is often overemphasised. We’ve got whole industries that work on letting us know how scary it is out there, vulnerabilities that are marketed like rock stars and terminology that makes you quiver in your boots: who would want to fall victim to an Advanced Persistent Threat (APT)?

There’s a metaphor about the fight between attackers and defenders in the Denial of Service cybersecurity game. It’s an “arms race” between ever bigger attacks throwing huge amounts of traffic at ever more sophisticated defenses (e.g. AWS shield). Incidentally, I’ve just demonstrated an easy mistake: I’m not describing a Denial of Service (DoS) attack, it’s a Distributed Denial of Service (DDoS) attack. The aim is to overwhelm the infrastructure, either the networking infrastructure or the application by sending more requests than can be handled.

In this post, I am going to look at an increasingly important part of securing applications: Your supply chain. This includes every library, tool or service that you are using to build, run and monitor your service. When the log4shell vulnerability hit, it wasn’t just a matter of looking at the dependencies that your source code pulls in, but also at the infrastructure you’re using and the build pipeline. Have you had a look at the vulnerability reports of your dependencies lately?

First of all I need the preface this article on how much I abhor the Russian invasion of Ukraine and I wholeheartedly support the sanctions. However, I think the conflict has spilled over into areas of software development that have got some unintended consequences attached. As part of this post, I’m going to look at the decision by MongoDB to cut off services in Russia the destructive change in a node library that deleted files on Russian IPs a change in code/licence in a community terraform module to assert that Putin is a dickhead MongoDB cutting off Russian customers MongoDB is a company and in order to comply with sanctions they have decided to cut off Russian customers.

Pwnkit is a vulnerability that uses a bug in polkit to elevate permissions to root. This write-up shows how to reproduce it using Ubuntu and what to do to check whether a system is vulnerable. What went wrong? Quoting from the original researchers: This vulnerability is an attacker’s dream come true: pkexec is installed by default on all major Linux distributions; pkexec is vulnerable since its creation, in May 2009; any unprivileged local user can exploit this vulnerability to obtain full root privileges; although this vulnerability is technically a memory corruption, it is exploitable instantly, reliably, in an architecture-independent way; and it is exploitable even if the polkit daemon itself is not running.

In this blog post, I would like to explore how missing input validation even in a trivial service can leave parts of server infrastructure crumbling. In my opinion, this why securing applications (AppSec) is very difficult. Put supply chain attacks, unpatched systems and misconfiguring services to one side for a minute and consider that a lot of software is written by developers who do not necessarily consider all the edge cases or implications of what can go wrong even in the simplest of pieces of code (or just copy/paste from Stackoverflow).

More and more I’m thinking that XML is evil! This is the third part of my series on why, as a software engineer, it is very useful to think about the potentially dangerous combination of outdated libraries and XML. I recently carried out a review of the dependency scanning results CVE-2012-0881: Apache Xerces2 Java allows remote attackers to cause a denial of service (CPU consumption) via a crafted message to an XML service, which triggers hash table collisions.

Security specialists. Arghhh! They’re all sitting in their ‘ivory tower’ without anything better to do than to take a baseball bat to your hard work and tell you how you’ve not considered some obscure vulnerability CVE-142341231/4234 in a library that you didn’t even know existed. Not only that, there is definitely no way that you can deploy now, even when the product owner is breathing down your neck saying that nobody is going home until we’ve fixed this!

Recently I tried to poke holes in a service. I found myself laughing out loud. This was a vulnerability whereby modifying a SAML authentication while being rePOSTed via the browser allowed me to inject a malicious payload (see XML External Entity (XXE) Processing and XML External Entity (XXE) Prevention Cheat Sheet) that could be used to use up a service’s memory and CPU. Health checks and automatic service restarts would have healed the service but it still would have allowed an attacker to mount a Denial of Service attack without needing a lot of requests.

Background I had found a vulnerability that made it is possible to insert maliciously crafted XML into the SAML payload that a reauthentication application returned to perform a Denial of Service (DoS) attack. The vulnerability came about due to the use of a out-of-date but still widely used library. The service could have been made to consume a lot of CPU and memory causing it respond very slowly if at all.