Software & Secure Defaults

A long time ago somewhere in 2015 I remember hearing about a bunch of MongoDB databases were wiped with ransom notes left. At first I was so curious how an attacker did this, then I realized it was just public accessible databases with no authentication.

When you think about that - it's hardly a hack. Just a misconfiguration of a system in a highly insecure way. So what did MongoDB do? They changed the defaults to produce a more secure system by default (authentication and only binding to 127.0.0.1).

As folks installed or upgraded their system the default setup was now way more secure than prior. The little downside however if you wanted to just work locally and test - you might have to configure stuff to make that easier.

This became the term "Secure by default" which effectively means a product is resilient against popular attacks without any additional changes. A popular form of this gaining steam is a technique that a program refuses to execute if given too much permission.

If you were building an integration for AWS you might be tempted to just generate an access token for your user. Your user is presumably admin so now your system has immense permission when it probably only needed the ability to upload files into a bucket. AWS now heavily prevents you from using administrator keys putting prompt in front of prompt confirming you really want to do such a thing when generating a key. Nowadays a solution is even without keys using a form of OIDC to grant permission based on trusted systems communicating.

If we look at the popular Mac software Homebrew, it takes a different approach entirely. If you try and execute it with too many permissions - it dies out.

Error: Running Homebrew as root is extremely dangerous and no longer supported.

This is pretty amazing, because now users not security inclined cannot make the mistake. Sure there is an escape hatch of commands you can do to bypass this, but for the most part the default is very secure. This is becoming the preference of software, secure by default with escape hatches if you need to reduce security.

In the era of AI research I wonder how far that line in the sand can go. For example, on Apktool I've gotten over 10 reports now that all roughly start the same way. "Assuming filesystem access, if we do x, then apktool will do y". I close all of these because if you have access to the filesystem of course you can modify files that apktool might build into a malicious piece of software.

Apktool acts as both a disassembler and assembler taking chunks of resources (.arsc) and sources (.dex) files to produce regular .xml and .smali files to tinker with. We can assemble those back into their roughly binary form, which means you have plenty of opportunities with filesystem access to do nefarious things. Folks probably aren't passing around disassembled applications to reassemble so the vector to be able to modify a file in the disassembled state means you have the ability to change files (or filesystem access) between two steps of a process.

So as I get challenged as to whether accept a vulnerability or change functionality that has a prerequisite of file system access is quite a stretch for me to accept. Though, I started thinking about a different type of exploit that gets codenamed as "ROP chaining" which is basically an exploit that takes advantage of existing code paths for a malicious purpose.

This exists in many languages as ROP/POP chaining and it basically can break down to the rehydration of a class object. In PHP that might be unserialize() and in Java it may be like a YAML.load() call. In both those circumstances you may be able to load existing code with malicious parameters that work in a way to become malicious.

public ClassSafeConstructor() {
 this.allowableClasses.add(MetaInfo.class);
 this.allowableClasses.add(PackageInfo.class);
 this.allowableClasses.add(UsesFramework.class);
 this.allowableClasses.add(VersionInfo.class);
}

At that point if we stretch our motto of "Secure by default" we shouldn't ever enumerate classes outside of what you expect. In the terms of Apktool, we only needed tiny little scalars (strings and more) so we disabled any class parsing to nerf this type of exploit.

So maybe at times "secure by default" can be applied and other times it can't.