There’s a problem with Opera. No, not that kind of opera. The Oracle kind. Oracle OPERA is a Property Management Solution (PMS) that is in use in a bunch of big-name hotels around the world. The PMS is the system that handles reservations and check-ins, talks to the phone system to put room extensions in the proper state, and generally runs the back-end of the property. It’s old code, and handles a bunch of tasks. And researchers at Assetnote found a serious vulnerability. CVE-2023-21932 is an arbitrary file upload issue, and rates at least a 7.2 CVSS.

It’s a tricky one, where the code does all the right things, but gets the steps out of order. Two parameters, jndiname and username are encrypted for transport, and the sanitization step happens before decryption. The username parameter receives no further sanitization, and is vulnerable to path traversal injection. There are two restrictions to exploitation. The string encryption has to be valid, and the request has to include a valid Java Naming and Directory Interface (JNDI) name. It looks like these are the issues leading Oracle to consider this flaw “difficult to exploit vulnerability allows high privileged attacker…”.

The only problem is that the encryption key is global and static. It was pretty straightforward to reverse engineer the encryption routine. And JDNI strings can be fetched anonymously from a trio of endpoints. This lead Assetnote to conclude that Oracle’s understanding of the flaw is faulty, and a much higher CVSS score is appropriate. Particularly with this Proof of Concept code, it is relatively straightforward to upload a web shell to an Opera system.

The one caveat there is that an attacker has to get network access to that install. These aren’t systems intended to be exposed to the internet, and my experience is that they are always on a dedicated network connection, not connected to the rest of the office network. Even the interconnect between the PMS and phone system is done via a serial connection, making this network flaw particularly hard to get to.

Passkeys Are Here

In case you missed the hype, passwords are dead, apparently. The replacement is the Passkey, a public/private keypair that is managed by the security processor on the user’s device. What’s new this week is yet another big service rolling out support for Passkeys for everyone. Google in this case, now offers Passkey logins for all personal Google accounts.

For all the hype, it’s worth pointing out that passkeys are just passwords, with all the best-practice options mandated. It’s a string of data that isn’t based on dictionary words, is stored securely by a credential manager, is never re-used across sites, never expires, and is only used in secure cryptographic proofs. Oh, and Chrome on MacOS and on some Windows 10 and 11 installs can handle passkeys. But sadly there’s no love for Linux users yet.

Location Tracker RFC

Apple’s AirTags have found some unexpected uses by clever folks. From tracking mail routes to recovering stolen scooters. But unfortunately, there’s been some less-than-ethical uses, too. Stalking is a crime, and it’s a bad look for Apple’s gadgets to trivially enable it. So, engineers from Apple and Google put their heads together, and came up with an RFC on detecting unwanted location trackers.

The basic requirements of the RFC are that trackers use Bluetooth Low Energy (BLE) to communicate, and support talking to non-owners over BLE. This connection allows a non-owner to identify when a device is following along. The device needs to have some way to make noise, so the trackee can physically locate the device, and most importantly, have a built-in method to disable the tracker. Essentially, there has to be a button to turn the tracking off. It seems like this will effectively prevent the use of AirTags as a malicious tracker. Unfortunately, it also seems like it will put an end to the biggest legitimate use of AirTags — theft prevention. It’s really not obvious how to prevent digital stalking, and still enable the tracking of stolen physical goods.

Cloud Smishing

This particular story is full of surprises, like discovering that Amazon AWS has a text message service, Amazon Simple Notification Service (SNS). And furthermore, text-based phishing is common enough, it has a fancy, dedicated name: Smishing. And the last realization is that it’s one more thing to abuse when an attacker manages to access an AWS account.

The theory is that legitimate users may have already been getting text messages from the service, so sending a smishing message through the same service might be more likely to succeed. So now we know, there’s one more thing to watch out for.

Bits and Bytes

So you’re doing a network capture, have a data stream in the clear, and capture a binary blob going over the wire. What is it? An encrypted file? Something Protobuf encoded? [Ron] at SkullSecurity had exactly this situation, and after trying multiple dead-ends, he finally turned to the humble file command. That’s an ancient Unix command, that reads the magic bytes at the beginning of a file and attempts to determine the file type. It worked with the mystery stream, too. Turns out it was zlib compressed data. Neat!

Ever wondered what exactly those various malicious NPM packages do? [Gaby Dobocan] at Sandworm has us covered, reviewing 5 malicious NPM packages going all the way back to 2018. Some packages just run a remote script, while others leaked environment variables inside a remote HTTP request. The most fun is alicov, which finishes running remote code, and then informs the user that they’ve been had.

It’s another week, and so we have another trio of exploited flaws on CISA. This time it’s a pre-auth Remote Code Execution problem in TP-Link’s Archer AX21 routers. Oracle’s WebLogic patched a RCE problem in January, and while that one just made the list, it seems to already be back off the radar of active exploitation. The last one is another problem in Log4j, a sister-vulnerability to the notorious Log4Shell issue. It seems to be less widespread, but is also an RCE. And that’s it for this week. Stay safe cruising the hyperwebs!