This Week in Security: Session Puzzling, Session Keys, and Speculation

Last week we briefly mentioned a vulnerability in the Papercut software, and more details and a proof of concept have been published. The vulnerability is one known as session puzzling. That’s essentially where a session variable is used for multiple purposes, or gets incorrectly set. In Papercut, it was possible to trigger the SetupCompleted class on a server that had already finished that initial setup process. And part of SetupCompleted validated the session of the current user. In a normal first-setup case, that might make sense, but as anyone could trigger that code, it allowed anonymous users to jump straight to admin.

The other half of the exploit leverages the “print script” feature, which lets admins write code that runs on printing. A simple java.lang.Runtime.getRuntime().exec('calc.exe'); does the trick to jump from web interface to remote code execution. The indicators of compromise are reasonable generic, including User "admin" logged into the administration interface. and Admin user "admin" modified the print script on printer "".. A Shodan search turns up around 1,700 Papercut servers accessible from the Internet, which prompts the painfully obvious observation that your internal print auditing solution’s web interface definitely should not be exposed online.

Apache Superset

Superset is a nifty data visualization tool for showing charts, graphs, and all sorts of pretty data sets on a dashboard. It also has some weirdness with using web sessions for user management. The session is stored on the user side in a cookie, signed with a secret key. This works great, unless the key used is particularly weak. And guess what, the default configuration of Superset uses a pre-populated secret key. thisismysecretkey is arguably a bad key to start with, but it turns out it’s also shared by more than 70% of the accessible Superset servers.

Apparently the Superset devs realized this was an issue, as they changed the value to a new, more obvious placeholder key, CHANGE_ME_TO_A_COMPLEX_RANDOM_SECRET, and added a log message if the service was started with one of the known default keys. After a year of this behavior, the Internet’s Superset servers were checked again, and this time 67% were using one of the placeholders. Thankfully the 2.1 release of Superset now outright refuses to start if one of the placeholder keys is left in the config file. The lesson to users is to read config files for CHANGEME tags. And for developers, don’t leave any footguns in your default config files, as users will shoot themselves in their feet without fail.

Speculation Fun

Up first in speculation fun is the AMD Spectral Chicken bit. So, chicken bits are individual bits of data sent to a chip to disable features, usually for security or stability reasons. And AMD’s Zen2 processors have a bit that disables certain speculative optimizations that could turn out to have security problems. The Linux Kernel is aware of that particular chicken bit, and uses ZEN2_SPECTRAL_CHICKEN to refer to it in code.

An AMD engineer wanted to update that name to the admittedly boring ZEN2_DE_CFG2_SUPPRESS_NOBR_PRED, and the Intel engineer that wrote the code NAK’d it, saying that AMD failed to help document or support the code way back when it was written. We could consider it a chicken of shame for AMD to wear around their necks for a while. And before you get too worked up about the back and forth, this really seems to be some light-hearted fun between colleagues.

It’s not all fun and games for Intel, as it looks like there’s yet another evolution of the Meltdown flaw that’s been discovered.This time, instead of using the machine’s cache to leak information about inaccessible memory, the EFLAGS register is used. It’s quite similar otherwise, as the state of the register is primed using memory that the attacker process cannot access, and then the timing of branching instructions is measured to discern the contents of the target memory. It’s a slower and less reliable side channel, but demonstrates that we still haven’t quite defeated speculative execution attacks, and probably won’t fully for quite some time. Hat tip to [Herr Brain] for pointing this one out.

AI Helps Compete

I’ve mused that ChatGPT is sort of like the laser, in that it’s impressive technology, but at the outset is still looking for a problem to solve. Well, [Micah] managed to set GPT-4 loose on a problem, and was quite impressed with the solution. The problem was the Capture the Flag competition being held at BSides SF 2023. The first challenge of note was a QR contest, where a flag was cryptographically split into seven parts, and encoded into QR codes. The algorithm was such that it took at least five parts to solve. After finding six of the QR code elements, [Micah] sent the data to GPT-4, and asked it to figure out the solution. In response, it spat out a Python script to solve the algorithm, and it worked on the first try. Impressive.

The second and third challenges were Perl and Linux shell tricks, and in both cases, it took a bit of back-and-forth with ChatGPT to zero in on the exact answer, but did eventually do the trick. So the next time you’re up against a sticky CTF problem, maybe ask ChatGPT to help you figure it out. Is it actually better than a good old-fashioned search engine? We’re not sure, but it looks like fun to try it!

RDP Hash Capture By Design

Researchers at GoSecure put together an interesting attack against Remote Desktop Protocol users, turned it in to Microsoft, and received the dreaded response, “not a vulnerability”. Microsoft may consider this behavior working as intended, but it’s worth knowing about, as it looks like it could really bite an unware user. The problem is how the RDP protocol security handshake works, and when the user and server identify themselves.

The first time you connect to a new Remote Desktop connection, there’s the warning that it’s an untrusted connection. The user knows this is the right server, so trusts and tells Windows not to ask again for this server. If everything is working as it should be, next connection won’t show the warning, as it’s confirmed to be the same server. The problem is that a man-in-the-middle attack can intercept the connection, and the connecting client will send the NetNTLMv2 hash before the server’s credentials are checked. And losing that hash just might be enough to reverse engineer a weak or common password. The conclusion? Don’t use RDP from an untrusted network. Makes sense to us.

Bits and Bytes

Users of KeyPassXC rejoice, your favorite password management solution just passed an external code audit with mostly flying colors. The only real problem found was that the memory deallocation process could be better at scrubbing secrets from RAM in certain situations. It’s always nice to get outside, professional eyes on an important solution like a password manager.

Western Digital appears to be the latest giant to be wrestling with ransomware. Attackers claim to have exfiltrated a whopping 10 terabytes of data, and are demanding tens of millions of dollars to not publish. What’s odd is that the traditional ransomware approach — encrypting the data — was skipped this time. Perhaps large companies have gotten their act together on good backups to the point that it’s not an effective threat. Information is still a bit spotty, but it looks like something happened at WD.

And finally, ever wonder what exactly the options are for an attacker that gets admin on a local Windows machine? What comes next, in the never-ending quest to break into all the boxes? Synacktiv has us covered. There are three broad approaches. First is getting at the memory of Local Security Authority Subsystem Service (LSASS), the Windows authentication service. And then don’t forget dumping the registry and looking for secrets there. The third covered hunting ground is DPAPI, the Data Protection API. Lots of non-OS software uses this one to save credentials. And if all three of those fail, there’s always the inevitable passwords document saved somewhere on the machine.

from Blog – Hackaday https://ift.tt/4g3PuG1