This one is a bit of a cross-user attack on the same machine, as git when executed in a directory that doesn’t have a .git folder, will traverse upward looking for the .git/ of the repo. The problem is if one accidentally invokes git while not in a repository it’ll look in some potentially untrusted locations as it traverses by defualt all the way to the root of the storage. This does require an attacker be able to create a directory in a parent directory so there is a bit of an ask there.

Once a malicious .git/ is created, some configuration options can cause arbitrary commands ot be executed allowing an attacker to execute commands as the victim user.

Great oversight spotted by the Light Spin team in Amazon Relational Database Service’s (RDS) PostGre service allowing for arbitrary file reading and ultimately disclosure of internal service credentials.

Effectively with RDS you can spin up one of several different database systems and have Amazon worry about scaling and all that. With that you get access to the database system but access to the underlying host system is restricted.

There is some limited extension support, for effectively only the extensions that Amazon trusts. The Light Spin team found the log_fdw extension was allowed. This extension allows access to log files through a SQL interface, exposing the log through a table and its columns.

There was a bit of security around this though, as Amazon does provide a custom foreign data wrapper for accessing the log files. These wrappers have two components the mandatory handler which handles actually fetching the foreign data, and the validator which just validates the options, the validator is optional as such validation could also just happen in the handler. What they found was that the handler did no validation on its own however, so by altering the foreign data wrapper to disable the validator they could import arbitrary files and read them through the log_fdw extension.

With the ability to read arbitrary files, they found their way through some configuration layers to /tmp/csd-grover-credentials.json which contained the credentials for an internal AWS service account.

Two issues, one being a race condition between validating a configuration is safe and using the configuration, the second an information disclosure where a user’s Net-NTLMv2 hash could be disclosed.

The race condition was pretty straight forward, the service first validates a VPN configuration file and then starts OpenVPN with it. The problem is that the configuration can be modified during the brief period between being validated and OpenVPN reading the file. Using the log directive in the configuration can result in writing semi-controlled content to any location as SYSTEM.

The second issue was that the auth-user-pass and ca directives will accept file paths. Providing a UNC path here (\\server\file for example) will result in a File.Open call on the path, which will send the users Net-NTLMv2 hash to an external server.

Copying and pasting an HTML element with a script within it can result in an XSS in vditor text editor. This does feel like a bit of a stretch for an attack scenario, pasting in malicious content to an editor, but not really a thread situation I’ve thought much about either.

They also call out a neat tool for converting some HTML to the actual DOM entities to copy: https://cdn.sekurak.pl/copy-paste/playground.html