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.

DICOM Polyglot

Researchers at Shielder were running a red-team test against a customer, and discovered a vulnerable install of Orthanc, software used to handle medical imaging. So, they rolled up their sleeves, reverse engineered the patch, and developed an exploit. And in order to exploit this particular flaw, they used one of my favorite tricks — a polyglot file. That’s when a given file is valid when interpreted as multiple file types.

The flaw is an unrestricted file upload. Important to note here, the unrestricted element is the file location. The file must still be a valid DICOM image file, but once uploaded it can be written anywhere on the file system. Now, DICOM files are weird. Namely, the first 128 bytes are reserved as an “Application Profile”, and are not used as magic bytes to determine whether a file is valid DICOM. It’s like it’s a custom-made format for building a polyglot. One might go so far as to say that’s a security weakness within the DICOM file format itself.

The question becomes, what can you do with just 128 bytes? Normally I’d try to think of some way to stuff 128 bytes of shellcode in there, and write it over some binary that’s sure to be run. But that’s way too complicated, given the tools on hand. The solution Shielder went with was to put a brief JSON config in those 128 bytes, and throw in a NULL to get the JSON parser to ignore the rest of the file. That config turns on an API endpoint that executes any LUA script you send it, likely intended for debugging. Another API call reboots the server to apply the new settings, and the nut is cracked. Polyglots are fun!

Patch Your Roundcube!

The Roundcube webmail platform released a series of updates on the 14th, fixing a 0-day Cross Site Scripting (XSS) attack that was being used in the wild. The exploit used an svg tag with base64 encoded HTML to bypass the sanitization code in Roundcube. This one is nasty, in that it simply requires a user to view the email in order to run JS in the browser, with full access to the webmail interface.

To date, this exploit has been seen in the wild used against European governments and NGOs. With that said, enough details about the exploit have been released to trivially put together a Proof of Concept. And sending email is easy, so it’s probably just a matter of time until this exploit is included with all the other spam and malware in our inboxes.

Roundcube is used widely, and gets included in other solutions like iRedMail, but usually doesn’t get updated automatically. Thankfully the update process is pretty simple, though I did hit a headscratcher on one of the instances I worked to upgrade. There, the permissions on the config file were modified during the upgrade, and an unhelpful error message was accompanied by silence in the error logs. Fixing the permissions made everything work as expected.

Zenbleed from the Browser

When we covered Zenbleed, one of the worst-case scenarios was the flaw being exploitable from right in the browser. The good news is that none of the JavaScript engines that Trent and David tested ever use the vzeroupper instruction that triggers the bug. However, when paired with another exploit to escape the JS interpreter and run actual shellcode, Zenbleed does work even within the browser sandbox.

For bonus points, this attack makes the captured system memory available to the JavaScript code, and the test page just displays it as part of the web page. In a real attack, that data would silently get uploaded for later analysis. So, Zenbleed can’t run simply from JavaScript, but with a bit of work, and another exploit, it can run from within the browser. Click through to the article to see the code and Russ’s excellent notes on it.

Trusting Trust Goes Open Source

Fourty years ago, Ken Thompson published his landmark paper, “Reflections on Trusting Trust” (PDF). It turns out, the actual source code referenced in that tale was never released — until now. The demo is a compiler that compiles a password stealer into any binary it touches, including another compiler. If you’re using this compiler, even completely open source code isn’t trustable.

In response to a Keynote from Thompson earlier this year, Russ Cox sent an email asking for the legendary source, and got a copy, much to our delight. The actual code is short, and only has a few magic bits to make it work. What’s even more interesting is that the self-replicating backdoor did escape out into the wild shortly, but was squashed because of a bug, where the compiler would grow in size each time it was compiled.

Bits and Bytes

There’s a newly-discovered malware framework, Stripedfly, that has quietly been infecting Windows and Linux computers for the last six years. It was first dismissed as a simple crypto-miner, but more recent analysis has found it to be a much more comprehensive tool, probably a true Advance Persistent Threat — APT being a nice way of saying government-backed malware.

Open redirects are usually a bad idea, but they’re extra double bad when they’re in an OAuth login flow. This was a problem in the Harvest time-tracking system, particularly in the integration with Outlook Calendar. Convince a user to click on a link using that redirect, and the OAuth token is leaked.