Bit of an odd bug in the SecurityPoint UTM Firewall admin and user panels. During the normal login flow a user starts off with an empty sessionID value, once they authenticate successfully the server returns a filled in sessionID. The bug lies in what happens when the authentication flow fails, it seems like an uninitialized value is used so whatever data happened to be there before gets reused. So if an attacker waits for someone to login to the panel (this bug exists across both user and administrative panels) then fails a login, the recently logged in user’s sessionID will be returned.

From that point there is one major hurdle to overcome, an attacker trying to reuse the sessionID must have the same fingerprint as the original user. The fingerprint is a MD5 of the remote address and the user agent string. this fingerprint is a pretty significant hurdle, as it requires the attacker either compromise the victim’s machine already, or that the panel access be behind a NAT so all access comes from the same REMOTE_ADDR.

One attack avenue the author didn’t explore was MD5 collisions, the attacker does have complete control over the user-agent. So what really needs to match is teh md5(remote address|user-agent) and not the actual remote address and user-agent strings. Getting a collision, especially when its fairly blind as you don’t know the expected hash but I can imagine some environments where you could reasonably predict the user-agent being used and a limited IP range so the collisions could be generated offline and just tested against the live service once generated.

Multiple symlink-style issues in the WindowsContainerController and HyperVController controllers in the Docker Desktop for Windows daemon (dockerd). When looking at the WindowsContainerController, they noted the start() and stop() methods as potentially interesting, as they would take start and stop request objects which were attacker-controlled input, and contained a DaemonJSON string, which pointed to the path of the configuration file for docker.

Arbitrary file overwrite/deletion via WindowsContainerController Two fields were of interest in the config, data-root and pidfile. The data-root field is the path to the directory containing container resources. If the directory doesn’t exist, it’ll create it and write files there as SYSTEM. If it already exists, it’ll simply write the files. If an attacker creates the directory beforehand and symlinks to another sensitive directory, they can get a privileged file overwrite as SYSTEM. Similarly, pidfile would be used for writing the PID on start(), or deleting the file on stop(), which was vulnerable to the same issue and also yielded arbitrary file overwrite or deletion respectively.

Arbitrary file overwrite/deletion via HyperVController The HyperV controller had basically the same issues in its create() and destroy() methods. Both would take a diskpath path for creating and deleting a virtual hard disk (vhdk).

Privesc via arbitrary file deletion To escalate privileges from file deletion, they used a known technique documented by ZDI. By deleting the C:\Config.msi directory used for windows installer rollbacks, they could replace rollback scripts (.rbs) with their own to make arbitrary system changes.

Orca Security presents a privilege escalation method in Azure environments, its nothing to crazy, but atleast worth taking note of. the first concept to understand are Azure Storage Account keys, when you first create a storage account, by default Azure generates a couple 512-bit storage account access keys that can be used to access the account. While it is the default action, the security best practice is to disable shared key access and use Azure AD authorization instead.

So, whats the danger? Well besides the fact that it is simple a key that gives complete access, its rather easy to mistakenly allow access to reading these keys. They point out the Storage Account Contirbutor role, exists, has access to listKeys but no access to any data actions so you might believe its a sort of “read-only” access. It is not, as listKeys can list the storage account access keys, an attacker could use that key to access and data actions they want.

From there its a matter of finding a useful target, to which they point out Azure Functions will create a dedicated storage account to store their source code, so with the listKeys permissions one could modify the source code of a Function, gaining ode execution with the Function’s privileges.

It does have a few dependencies, but nothing that seems terribly unlikely if you find yourself in such a position this is a vulnerable design and not something Microsoft intends to patch.

Another file-write to code execution escalation strategy to be aware of. Similar to others we’ve covered it requires control over the file being written (duh) and partial control over the contents; the start of atleast one line is sufficient.

With control over the start of one line you can target Python’s site-specific configuration hooks. Effectively what you want to do is inject a .pth file into ` ~/.local/lib/pythonX.Y/site-packages/ where pythonX.Y is the particular python version in use. Any line that starts with import ` or import\twill be executed as python.