This Week In Security: Good Faith, Easy Forgery, And I18N

There’s a danger in security research that we’ve discussed a few times before. If you discover a security vulnerability on a production system, and there’s no bug bounty, you’ve likely broken a handful of computer laws. Turn over the flaw you’ve found, and you’re most likely to get a “thank you”, but there’s a tiny chance that you’ll get charged for a computer crime instead. Security research in the US is just a little safer now, as the US Department of Justice has issued a new policy stating that “good-faith security research should not be charged.”

While this is a welcome infection of good sense, it would be even better for such a protection to be codified into law. The other caveat is that this policy only applies to federal cases in the US. Other nations, or even individual states, are free to bring charges. So while this is good news, continue to be careful. There are also some caveats about what counts as good-faith — If a researcher uses a flaw discovery to extort, it’s not good-faith.

Digital ID

In New South Wales, Australia, citizens can use digital driver’s licenses. This is done via the Service NSW app, available on Android and iOS. What could possibly go wrong? There is a glaring problem with this, it’s a terrible idea to voluntarily hand your phone to a law enforcement officer. That aside, the app generates the ID image on-the-fly from data stored on the device. On a jailboken phone, this is trivial to modify, but on any other iPhone, one can manipulate the app’s data using a backup and restore. ServiceNSW encrypts this data… using a 4 digit numeric code. It’s trivial to manipulate the data stored on the phone, and therefore the ID presented. Bizarrely, after the initial pull, the app never verifies its data store against the official database. The app even includes a pull-to-refresh function that claims to update the ID data. This function updates the date, time, and QR code, but not the potentially spoofed data.

The ability to modify an ID, as well as spoof someone else’s, means that the app makes identity theft painfully easy. The QR code does pull up-to-date information when scanned, but only the name and under-18 status. The picture isn’t part of that data. Steal an ID, slap your picture on it, and the QR code will check out. Service NSW has responded, issuing a statement that clearly indicates they don’t understand the problem:

This issue is known and does not pose a risk to customer information. The blogger has manipulated their own Digital Driver Licence (DDL) information on their local device. No other customer data or data source has been compromised. It also does not pose any risk in regard to unauthorised access or changes to backend systems such as Drives. Importantly, if the tampered licence was scanned by police, the real time check used by NSW Police (scanning mobipol) would show the correct personal information as it calls on DRIVES. Upon scanning the licence it would be clear to law enforcement that it has been tampered with. Altering the DDL is against the law. The DDL has been independently assessed by cyber specialists and is more secure than the plastic card.

Just Here For the i18ntranslation

Bonita is a business automation platform, mainly designed to let businesses put together workflows with minimal code. It’s a Java application, typically running on Tomcat, and distributed as a docker image among other channels. That Docker image, with it’s over five million downloads, had a big problem. The web.xml file contains filter stanzas used for controlling how requests are handled. A pair of those filters were intended to match i18n (internationalization) files, and deliver those endpoints without any authorization checks. This makes sense, as it allows a user to change the interface language on the login page. It’s a naive filter, literally matching any url containing i18ntranslation. So, any endpoint can be appended with ;i18ntranslation, and an unauthorized user has access. Whoops! The Docker image and other releases have been updated to fix the issue.

Zoom Fixed, Update!

First, if you have zoom installed, go check the version. If you’re older than 5.10.4, go trigger an update. And if you run Zoom on Linux, you’ll probably have to go download the installer again manually to update, though that makes things a bit safer in this case.

With that out of the way, let’s talk about the series of issues that could have allowed Remote Code Execution (RCE). Zoom does XMPP messaging, which is massages messages over XML. Zoom also sends control messages over this XML stream. The trick is that the server uses one library to validate those XML messages, and the client uses a different one, with different quirks. Sound familiar? Classic request smuggling material. One of the fun tricks is to send a clusterswitch message, pointing a client to a different server, potentially controlled by an attacker.

If a MitM attack wasn’t bad enough, an attacker can then send an “update” on Windows, consisting of a .exe installer, and a .cab file to install. The running Zoom client checks the exe to confirm that it’s signed, then executes. A modern Zoom installer also confirms the cab file signature, but a downgrade attack is possible. Send an older version, like 4.4, and a malicious .cab file. The exe is signed, so Zoom runs it, and this one doesn’t check the .cab, leading to easy RCE. The request smuggling was fixed server-side in February, but the client fixes didn’t land til April in 5.10.4.

Quick Tip

This week, I was helping a friend think through how to configure a Google account for some unorthodox utility usage. He was forced to turn on two factor authentication, but found that to be quite the pain, as he re-installs Android often for development and testing. If only, we mused, you could install Google Authenticator on a Linux machine, and back up the key yourself. And thus this tip, as you can indeed do this. Google Authenticator is just a TOTP, Time-based One Time Password. It takes a secret key and current time, and runs them though an algorithm to produce a (in this case) 6-digit code.

So how do you get that secret key out of your device? On a rooted phone it’s easy enough to extract from the sqlite database. Thankfully, the authenticator app can export a saved key as a QR code. Capture the data contained in the QR code, and then use this handy Python script to convert it back to the raw secret. (In many cases, you can even get the secret key directly by saying that the QR code didn’t work.) From there it’s an easy command: oathtool --totp -b secret_key

If you want to see how TOTP works under the hood, we wrote about that a while back.