First up is some intelligent wizardry from the [Aqua Nautilus] analysis staff, who discovered a timing attack that leaks info about private npm offers. The setup is this, npm hosts each general public and non-public node.js offers. The public kinds are readily available to everybody, but the personal deals are “scoped”, this means they reside inside a non-public namespace, “@proprietor/packagename” and are inaccessible to the common community. Striving to obtain the bundle outcomes in an HTTP 404 mistake — the similar mistake as trying to pull a package that does not exist.
The intelligent bit is to maintain hoping, and really pay back notice to the responses. Use npm’s API to request data on your concentrate on bundle, five occasions in a row. If the offer title isn’t in use, all 5 requests will consider the predicted amount of money of time. That ask for lands at the service’s backend, a lookup is performed, and you get the reaction. On the flipside if your target offer does exist, but is privately scoped, the to start with ask for returns with the envisioned delay, and the other four requests return straight away. It appears that npm has front-conclusion that can cache a 404 reaction for a non-public offer. That response time discrepancy suggests you can map out the private deal names utilised by a presented firm in their personal scope.
Now this is all very interesting, but it turns into a plausible assault when mixed with typosquatting and dependency confusion challenges. People assaults are two approaches to the same objective, get a node.js deployment to operate a destructive bundle as a substitute of the reputable 1 the developer intended. 1 is dependent on typos, but dependency confusion just relies on a developer not explicitly defining the scope of a package deal.
Siemens Remaining the Keys in the Ignition
Siemens produced variation 12 of their TIA portal approximately 10 a long time back, and with this update added asymmetric cryptography involving the portal and their SIMATIC S7-1200 and S7-1500 products and solutions. To place that in basic English, their industrial controllers started making use of HTTPS to talk to the controller software package. This was a fantastic point. Regrettably, the private essential for that HTTPS connection life on the controller components, and each and every unit transported had the identical critical.
The serious exciting is how the staff at Claroty learned all this. Industrial controllers get programmed in a specific, higher-level language, that is strictly for automation logic. Ideas, memory administration, and the relaxation of our normal susceptible vectors don’t show up in this article. Individuals programs get compiled to a custom made bytecode that runs in a managed setting on the controller. So by natural means, our researchers reverse engineered the bytecode and wrote their individual compiler, to have accessibility to individuals underneath-the-hood functions. It was continue to a obstacle to defeat the safety controls developed-in to that ecosystem, but they eventually uncovered a functionality that could set a pointer to an arbitrary worth, allowing for kernel reads and writes. Together with looking through the common crucial.
And that brings us to the initially actual attack that having this mystery-but-shared essential enables. Dependent on the configuration, it’s from time to time feasible to download the configuration blob without having authentication. One of the objects contained in that dataset is the encrypted password hash, which was encrypted employing — you guessed it — that universal crucial. With the important in hand, an attacker can obtain the hash, decrypt, and then authenticate employing the hash.
And then, getting the mystery essential to an HTTPS certification permits all the usual shenanigans one would assume of: capturing website traffic and decrypting, or executing a guy-in-the-middle assault. The concerns have been fixed with the most current firmware and portal updates, and Siemens has issued an advisory possessing up to the difficulties. See the video below for the initially-hand tale of escaping The Matrix and receiving to real code execution on these machines.
(Hackaday’s father or mother enterprise, Supplyframe, is owned by Siemens.)
Valid PNG, Legitimate PHP
There is constantly a little something weirdly exciting about a file that is valid as multiple, wildly various file formats. In this situation, it is the PNG file that is also legitimate PHP. The protection angle below is that quite a few sites permit you to upload PNGs and then perspective them. If that PNG could essentially, sneakily be a PHP file much too, you have an quick webshell. Now there are probable some insecure web-sites wherever it is just as straightforward as uploading a script, but numerous uploader libraries will at least examine that the file is valid for the specified mimetype. Just, it has to be a legitimate PNGif established to picture/png. But is that more than enough?
PNG files can contain comments. What does a website server do when it serves a .php file that also consists of binary PNG knowledge? In several cases, it treats it like any other file, sending the uncooked info until finally it finds a tag, where it might just start executing PHP script. The next question is how does one create such a file that the PHP script persists through compression, resizing, and other sanitizing steps? The first approach discussed is using tEXt chunks, which are usually used for storing title, author, etc. In many cases these bits of embedded text will persist through any modifications.
The other, harder approach, is to embed text as image data directly. There is the PLTE chunk, where custom palette entries can be defined. These can have any value, but must have a multiple-of-three length, and maximum 768 characters. The even harder one is to use the actual IDAT chunks, AKA actual valid pixel data. This is deep magic indeed.
Zoneminder — It Could Have Been Worse
This one hits close to home, as it’s a trio of vulnerabilities in a project I recommend and occasionally sling code for. [Trenches of IT] contacted the project on the 30th with a trio of vulnerabilities that had the potential to be really ugly when put together. Up first is a Log Injection flaw, where a web user can push arbitrary data into the ZM logs, with no rate limiting. Need the cameras to stop recording? Fill the drive up with log messages. Both the message itself and the component that sent it can be set arbitrarily.
Up next is a CSRF bypass. Cross-Site Request Forgery is an attack where an end user’s browser takes an action the user didn’t intend, just by making an HTTP request. ZM uses CSRF tokens to protect against such issues, which is a random token, supplied by the web service, that must be included in any POST requests. The bypass in the case of ZM is that some actions, like deleting a recording, can be made as GET requests, which don’t require a token. Whoops.
The last issue has the potential to be the worst, as it’s a Cross-Site Scripting (XSS) issue. That log injection issue also enables this one, as the “file” field can contain arbitrary HTML code, including a script tag. Put the three issues together and a user with view-only privileges can inject a delete or disable command that will trigger when an admin views the logs. That’s bad, but at least it’s not a pre-auth vulnerability. It was fixed in 1.36.27, released on the 7th. If you happen to be stuck in the 1.34 series of releases, this a few other issues are outstanding and no further releases are planned for that deprecated version. Thanks to [Trenches of IT] for finding and reporting!
Microsoft’s Gift That Keeps Giving
Remember the Exchange 0-day, the one that was sort of a workaround of an older problem with the autodiscover endpoint? Well it still hasn’t been patched, and the recommended workarounds have been updated multiple times, as they’ve been trivially bypassed. It might just be time to just pull the plug on autodiscover, and just block all outside access to IIS while you’re at it.
Python and Userland Execution
Finally a red-team quick-tip. You’ve popped shell on a server, and you want to pull some tools in to start exploring the environment. Root is mounted read-only, and your temp directories are all mounted noexec. How do you get a binary on to the system and run it? If Python is installed, then you could use ulexecve. [Vincent Berg] wrote the tool and has the story. How it works is equally impressive, as it downloads and parses a given binary, manually loading it into memory and generating the jump buffer. Finally, it jumps code execution into the new binary, which never needs to be written to disk. Tricky.