This Week In Security: Find My Keylogger, Zephyr, And Active Exploitation

Keyloggers. Such a simple concept — you secretly record all the characters typed on a keyboard, and sort through it later for interesting data. That keyboard sniffer could be done in software, but a really sneaky approach is to implement the keylogger in hardware. Hardware keyloggers present a unique problem. How do you get the data back to whoever’s listening? One creative solution is to use Apple’s “Find My” tracking system. And if that link won’t let you read the story, a creative solution for that issue is to load the page with javascript disabled.

This is based on earlier work from [Fabian Bräunlein], dubbed “Send My”. As an aside, this is the worst naming paradigm, and Apple should feel bad for it. At the heart of this cleverness is the fact that Apple used the standard Bluetooth Low Energy (BLE) radio protocol, and any BLE device can act like an Apple AirTag. Bits can be encoded into the reported public key of the fake AirTag, and the receiving side can do a lookup for the possible keys.

A fake AirTag keylogger manages to transfer 26 characters per second over the “Find My” system, enough to keep up with even the fastest of typists, given that no keyboard is in use all the time. Apple has rolled out anti-tracking protections, and the rolling key used to transmit data also happens to completely defeat those protections. Continue reading “This Week In Security: Find My Keylogger, Zephyr, And Active Exploitation”

Perfect Dark: Recompiled

There’s an interesting renaissance of Nintendo 64 gaming, powered by the ability to decompile N64 ROMs back into C code using Ghidra. There are projects around multiple classic games, taking the Ghidra output and renaming the generic function and variable names. There are two approaches to these projects, sometimes happening in parallel. The first is to perfectly recreate the original work, and get a bit-perfect binary that matches the original ROM. The other approach is to fix bugs, optimize the code, and add new features, often porting to new platforms in the process. Right now, we’re seeing the latter happen with 2000’s Perfect Dark.

There is a project by [Ryan Dwyer] to produce a matching C codebase, and that project is functionally complete with an over 99% bit-perfect output. But as impressive as that is, we’re interested in making code even better, and that’s what [fgsfdsfgs] has accomplished with the Perfect Dark port.

The game now runs on Windows or Linux, has mouse support, and runs at a solid 60 frames per second (FPS) at multiple screen resolutions. Want an ultra-widescreen Perfect Dark experience? The upgraded rendering engine handles it wonderfully. Mods? No problem. In the future, the developer is also looking to support high-definition textures.

To play, you do have to provide your own legally sourced copy of the original Perfect Dark game. That is the only way this project is remotely legal, and we suspect that even then it’s in a somewhat grey zone, as a derivative work of a copyrighted game. Big N hasn’t shut the project down, but the Mario 64 port was killed for attempting the same thing. We’ll hope for the best, and enjoy the nostalgia trip in the meanwhile!

Saving Apollo By Decoding Core Rope

One of our favorite retro hardware enthusiasts, [CuriousMarc], is back with the outstanding tale of preserving Apollo Program software, and building a core rope reader from scratch to do it. We’ve talked about [Marc]’s previous efforts to get real Apollo hardware working again, and one of the by-products of this effort was recovering the contents of the read-only core rope memory modules that were part of that hardware.

The time finally came to hand the now-working Apollo guidance computer back to its owner, which left the team without any hardware to read core rope modules. But the archive of software from the program was still incomplete, and there were more modules to try to recover. So, the wizardly [Mike Stewart] just decided to roll up his sleeves and build his own reader. Which didn’t actually work as expected the first time.

And this leads us into one of [Marc]’s elevator music explainers, where he gives a beautiful rundown on how core rope works. And if you are thinking of core memory based on ferrite cores, get ready for a brain stretch, as core rope is quite a bit different, and is even more complicated to read. Which brings us to the bug in [Mike]’s reader, which is actually a bug in the block II design of the core rope modules.

Reading a byte off the module requires setting multiple inhibit wires to select an individual core. An innovation in block II allowed those inhibit wires to run at half current, but it turns out that didn’t actually work as intended, and partially selected multiple cores on the other half of the module. And [Mike] forget to re-implement that bug — the reader needs to literally be bug-for-bug compatible. A quick recompile of the FPGA code makes everything work again. And the conservation effort can continue. Stay tuned for more in the Apollo story!

Continue reading “Saving Apollo By Decoding Core Rope”

This Week In Security: CVSS 4, OAuth, And ActiveMQ

We’ve talked a few times here about the issues with the CVSS system. We’ve seen CVE farming, where a moderate issue, or even a non-issue, gets assigned a ridiculously high CVSS score. There are times a minor problem in a library is a major problem in certain use cases, and not an issue at all in others. And with some of those issues in mind, let’s take a look at the fourth version of the Common Vulnerability Scoring System.

One of the first tweaks to cover is the de-emphasis of the base score. Version 3.1 did have optional metrics that were intended to temper the base score, but this revision has beefed that idea up with Threat Metrics, Environmental Metrics, and Supplemental Metrics. These are an attempt to measure how likely it is that an exploit will actually be used. The various combinations have been given names. Where CVSS-B is just the base metric, CVSS-BT is the base and threat scores together. CVSS-BE is the mix of base and environmental metrics, and CVSS-BTE is the combination of all three.

Another new feature is multiple scores for a given vulnerability. A problem in a library is first considered in a worst-case scenario, and the initial base score is published with those caveats made clear. And then for each downstream program that uses that library, a new base score should be calculated to reflect the reality of that case. Continue reading “This Week In Security: CVSS 4, OAuth, And ActiveMQ”

This Week In Security: 1Password, Polyglots, And Roundcube

This week we got news of a security incident at 1Password, and we’re certain we aren’t the only ones hoping it’s not a repeat of what happened at LastPass. 1Password has released a PDF report on the incident, and while there are a few potentially worrying details, put into context it doesn’t look too bad.

The first sign that something might be amiss was an email from Okta on September 29th — a report of the current list of account administrators. Okta provides authentication and Single Sign-On (SSO) capabilities, and 1Password uses those services to manage user accounts and authentication. The fact that this report was generated without anyone from 1Password requesting it was a sign of potential problems.

And here’s the point where a 1Password employee was paying attention and saved the day, by alerting the security team to the unrequested report. That employee had been working with Okta support, and sent a browser session snapshot for Okta to troubleshoot. That data includes session cookies, and it was determined that someone unauthorized managed to access the snapshot and hijack the session, Firesheep style.

Okta logs seemed to indicate that the snapshot hadn’t been accessed, and there weren’t any records of other Okta customers being breached in this way. This pointed at the employee laptop. The report states that it has been taken offline, which is good. Any time you suspect malicious action on a company machine, the right answer is power it off right away, and start the investigation.

And here’s the one part of the story that gives some pause. Someone from 1Password responded to the possible incident by scanning the laptop with the free edition of Malwarebytes. Now don’t get us wrong, Malwarebytes is a great product for finding and cleaning the sort of garden-variety malware we tend to find on family members’ computers. The on-demand scanning of Malwarebytes free just isn’t designed for detecting bespoke malicious tools like a password management company should expect to be faced with.

But that turns out to be a bit of a moot point, as the real root cause was a compromised account in the Okta customer support system, as revealed on the 20th. The Okta report talks about stolen credentials, which raises a real question about why Okta support accounts aren’t all using two-factor authentication.

Continue reading “This Week In Security: 1Password, Polyglots, And Roundcube”

This Week In Security: Browser Exploits, Play Protect, And Turn ON Your Firewall!

Google Chrome has done a lot of work on JavaScript performance, pushing the V8 engine to more and more impressive feats. Recently, that optimization has one more piece, the Maglev compiler, which sits between Sparkplug and TurboFan, as a mid-tier optimization step. With a Just In Time (JIT) system, the time saving of code optimization steps has to be carefully weighed against the time costs, and Maglev is another tool in that endless hunt for speed. And with anything this complicated, there’s the occasional flaw found in the system. And of course, because we’re talking about it here, it’s a security vulnerability that results in Remote Code Execution (RCE).

The trick is to use Maglev’s optimization against it. Set up a pair of classes, such that B extends A. Calling new B() results in an attempt to use the constructor from A. Which works, because the compiler checks to make sure that the constructors match before doing so. There’s another way to call a constructor in JS, something like Reflect.construct(B, [], Array);. This calls the B constructor, but indicates that the constructor should return an Array object. You may notice, there’s no array in the A class below. Tricking the compiler into using the parent class constructor in this fashion results in the array being uninitialized, and whatever happens to be in memory will set the length of the array. Continue reading “This Week In Security: Browser Exploits, Play Protect, And Turn ON Your Firewall!”

This Week In Security: Curl Reveal, Rapid Reset DDoS, And Libcue

Curl gave us all a big warning that a severe security problem had been found in that code-base. Given the staggering number of Curl installs around the world, we held our collective breath and waited for the bombshell to drop this Wednesday. It turns out, it’s not quite as bad as feared — so long as you don’t have a SOCKS proxy.

In hindsight, shipping a heap overflow in code installed in over twenty billion instances is not an experience I would recommend. — Daniel Stenberg

The trouble started when the SOCKS5 proxy support was converted to a non-blocking implementation. It’s a win for libcurl to work on requests asynchronously, but refactoring code and new features always runs a bit of risk. SOCKS5 proxying has some quirks, like allowing DNS resolution to happen locally or at the proxy. The new async code starts out with:

bool socks5_resolve_local =
(proxytype == CURLPROXY_SOCKS5) ? TRUE : FALSE;

First off, unnecessary ternary is unnecessary. But note that this local variable gets set by the proxytype. If that’s CURLPROXY_SOCKS5_HOSTNAME, then it uses remote resolution. But inherited from old code is a check for a hostname that is too long for a SOCKS request (255 bytes). This code converts back to local resolution in this case.

The important detail here is that this function is now a state machine, that potentially runs multiple times for a single request, to achieve that asynchronous execution. The check for a too-long hostname only happens during the initialization state. Copying the hostname into the buffer happens in a different state. If setting up the connection takes enough time, the function will return and be executed again when something has changed. The ternary check runs again, but not the hostname-too-long. So if set to do remote resolution with a long enough host name, execution slips through this edge case, and the long hostname is copied into a too-small buffer.

It’s safe to assume that this heap overflow can result in arbitrary code execution. The fix has landed in 8.4.0, after being present for 1,315 days. [Daniel] goes ahead and gets ahead of the inevitable suggestion that Curl should be written in rust or another memory-safe language. Curl was started before those alternatives existed, and there is a very slow effort to move portions of the project to memory-safe languages. And you’re welcome to help out. Continue reading “This Week In Security: Curl Reveal, Rapid Reset DDoS, And Libcue”