This week we start with a Remote Code Execution (RCE) vulnerability that has potential to be a real pain for sysadmins. Cacti, the system monitoring and graphing solution, has a pair of bugs that chain together to allow an attacker with unauthenticated access to the HTTP/S port to trivially execute bash commands. The first half of this attack is an authentication bypass, and it’s embarrassingly trivial. The Cacti authentication code trusts the Forwarded-For: header in the request. Set it to the server’s IP, and the authentication code treats it like a localhoast request, bypassing any real authentication process.
The second half is found in the remote_agent.php endpoint, where the poller_id is set by the user and treated as a string. Then, if the right host_id and local_data_id item is triggered, that string is concatenated into a proc_open() function call. The string isn’t sanitized, so it’s trivial enough to include a second command to run, dropping a webshell, for instance.
Version 1.2.23 of Cacti contains the fix, and released on the 2nd. This one is likely to be exploited, and if automated exploitation hasn’t started already, it likely will soon. So if you have a Cacti install, go double-check that the interface isn’t exposed to the world.
JSON Web Token
Researchers at Unit 42 found an exploit that can be used to achieve an RCE in the JsonWebToken project. The issue is this library’s verify() function, which takes arguments of the token to check, the key to use, and options. If there aren’t any algorithms specified in the options object, then the key is processed as a PEM string. The toString() method of that key is called during the actual check, and the assumption is that it’s either a string or buffer. But what if the key passed in to the verify() function was actually a complex object, bringing it’s own toString() method along to play. At that point, we have arbitrary code execution. And if this code is running on the server-side under node.js, that means a popped server.
But wait, it’s not that simple, right? It’s not like a valid JWT can contain an arbitrary object — that would be a problem all on its own. So CVE-2022-23529 is a stepping-stone. It’s insecure code, but the rest of the application has to have another vulnerability for this one to be reachable.
SCOTUS Weighs In on NSO
We’re taking a rare look at a political story, as the Supreme Court of the United States has made a decisive statement — by declining to make a statement. WhatsApp is pushing forward with a lawsuit against NSO Group, and NSO has made the argument that all of their actions have been taken as agents for legitimate governments, which should grant immunity against lawsuit. The 9th circuit ruled that this defense was ridiculous, so NSO naturally appealed to the Supreme court. In declining to hear the case, the highest court sends a statement that the lower court’s judgement should stand, which means the lawsuit proceeds. There should be some interesting details come to light during the course of this suit, as well as the other suits that are inevitable, like the Apple suit that has already been filed.
SBOMs and VEX
Software Bill of Materials (SBOMs) is a popular buzzword these days, and we haven’t really look at the idea yet, here on this column. The idea has been around for a while, based on the tradition Bill of Materials that might come with a hardware build. A SBOM is simply the list of libraries and binaries that are part of a software solution. The ideal is that a business would have SBOMs for all their software and appliance solutions, and can automatically check whether they have any exposure to published CVEs.
It sounds great, but unfortunately it’s not quite as simple as it sounds. The article from Chainguard above is primarily about Vulnerability Exploitability eXchange (VEX) documents, a standardized format for declaring a product immune to a vulnerability. So let’s take the JWT vulnerability above. A given solution may ship with a vulnerable JWT library, but a software engineer looks at the issue, and how the library is used, and certifies that the solution isn’t actually vulnerable. A VEX document is created, added to the SBOM database, and the automated vulnerability scanning solution knows to ignore that vulnerability for that solution.
TikTok VMs In Your Browser
JavaScript is all Open Source, right? It’s an interpreted language that runs on the consumer’s browser, so by definition it’s at least source available. Except many sites go far out of their way to obfuscate JS code into something totally unreadable. And the current champion of obfuscation has to be TikTok. [Ibiyemi Abiodun] spent some time working on reverse-engineering that code, based on an earlier effort by [Veritas].
And it’s deep magic. After working through a couple steps of deobfuscation using babel, it becomes apparent that it’s bytecode being fed into JS virtual machine. This blog entry ends with some pseudo-assembly that needs a dedicated decompiler to further understand. We’ll hope for a part three, maybe from yet another researcher.
SugarCRM Under Fire
A 0-day for SugarCRM was posted on seclists.org back in December, and a hotfix was quickly developed. The exploit is a pair of trivial flaws. The first is the authentication bypass, where a request is sent with both username and password set to 1, which works to generate a valid authentication cookie. The second is an unrestricted file upload to the images directory. Upload a PHP script, then access the url for instant profit.
Unfortunately, this one is getting exploited in the wild, and something like 12% of the accessible SugarCRM deployments already being cracked. The exploit was disclosed with several search strings that would return potentially vulnerable deployments, so it’s not surprising that machines were exploited. If you have a SugarCRM box on the internet, it’s probably time to go check it out for compromise.
Bits and Bytes
VScode is really something. An Open Source Microsoft project that has quickly become the favorite of quite a few programmers. It’s a great IDE, and has a wide library of extensions. And that could be a problem. VSCode extensions run without a sandbox, and have essentially all the same privileges of the user account running VSCode. Yet another place to watch out for typosquatting and similar tricks.
Amazon has announced that they’re rolling out server-side encryption by default for new S3 objects. I have questions about how useful this actually is, as it doesn’t do anything to protect against the most common problems we find with S3 storage — auth token leaks. At the least, this would be helpful to prevent physical attacks, but that seems unlikely already.
And speaking of keys, [Tom Forbes] has written the mother of all regex strings, in an effort to find AWS keys unintentionally published in packages and repos. (('|\")((?:ASIA|AKIA|AROA|AIDA)([A-Z0-7]{16}))('|\").*?(\n^.*?){0,4}(('|\")[a-zA-Z0-9+/]{40}('|\"))+|('|\")[a-zA-Z0-9+/]{40}('|\").*?(\n^.*?){0,3}('|\")((?:ASIA|AKIA|AROA|AIDA)([A-Z0-7]{16}))('|\"))+ is something of a mouthful, but he’s found 57 live AWS keys just on PyPi. Impressive.
0 Commentaires