This Week in Security

238 Articles

This Week In Security: DNSSEC Temporarily Lost Their Keys, FIDO, And One Weird Windows Trick

February 21, 2020 by 12 Comments

DNSSEC is the system that allows for cryptographically secure DNS. It’s all based on a root cryptographic key, maintained by the Internet Assigned Numbers Authority (IANA). Ever wondered where the root Key Signing Key is stored, and how it’s accessed? Four times a year, a ceremony is held where the root key is pulled out of a physical safe, and maintenance tasks are performed in front of a group of witnesses.

Such an event was scheduled for February 12th, but a teensy problem was discovered. One of the safes that holds the key media had a broken lock, and the root key signing key was inaccessible for a few days while repairs were effected. The open nature of IANA means that much of their operations are publicly reported, and you can even watch the key signing ceremony, which was finally held on February 16th.

Continue reading “This Week In Security: DNSSEC Temporarily Lost Their Keys, FIDO, And One Weird Windows Trick” →

This Week In Security: Robinhood, Apple Mail, ASLR, And More Windows 7

February 14, 2020 by 10 Comments

First off this week, a ransomware named Robinhood has a novel trick up its sleeve. The trick? Loading an old known-vulnerable signed driver, and then using a vulnerability in that driver to get a malicious kernel driver loaded.

A Gigabyte driver unintentionally exposed an interface that allows unfettered kernel level read and write access. Because it’s properly signed, Windows will happily load the driver. The ransomware code uses that interface to turn off the bit that enforces the loading of signed drivers only. From there, loading a malicious driver is trivial. Robinhood uses it’s kernel-level access to disable anti-virus applications before launching the data encryption.

This is a striking example of the weakness of binary signing without a mechanism to revoke those signatures. In an ideal world, once the vulnerability was found and an update released, the older, vulnerable driver would have its signature revoked.

The last Windows 7 Update For Real This Time, Maybe

More news in the ongoing saga of Windows 7/Server 2008 reaching end-of-life. KB4539602 was released this patch Tuesday, fixing the black background problem introduced in the last “final” round of updates. Surely that’s the last we’ll hear of this saga, right?

Not so fast. Apparently that patch has led to multiple Windows Server 2008 machines failing to boot after install. According to Microsoft, the problem is a missing previous patch that updates SHA-2 support. Continue reading “This Week In Security: Robinhood, Apple Mail, ASLR, And More Windows 7” →

This Week In Security: Google Photos, Whatsapp, And Doom On Deskphones

February 7, 2020 by 12 Comments

Google Photos is handy. You take pictures and videos on your cell phone, and they automatically upload to the cloud. If you’re anything like me, however, every snap comes with a self-reminder that “the cloud” is a fancy name for someone else’s server. What could possibly go wrong? How about some of your videos randomly included in another user’s downloads?

Confirmed by Google themselves, this bug hit those using Google Takeout, the service that allows you to download all your data from a Google application, as a single archive. Google Photos archives downloaded between November 21 and November 25 may contain videos from other users, according to a notice sent to the users who downloaded said archives. It’s notable that those notices haven’t been sent to users who’s videos were exposed.
Continue reading “This Week In Security: Google Photos, Whatsapp, And Doom On Deskphones” →

This Week In Security: Chrome Speech Bug, UDP Fragmentation, And The Big Citrix Vulnerability

January 24, 2020 by 5 Comments

A critical security bug was fixed in Chrome recently, CVE-2020-6378. The CVE report is still marked private, as well as the bug report. All we have is “Use-after-free in speech recognizer”. Are we out of luck, trying to learn more about this vulnerability? If you look closely at the private bug report, you’ll notice it’s in the Chromium bug tracker. Chrome is based primarily on the Chromium project, with a few proprietary features added. Since Chromium is open source, we can go find the code change that fixed this bug, and possibly learn more about it.

Off to the Chromium source, mirrored on Github. We could look at every commit, and eventually find the one we’re looking for, but Chromium commit messages usually include a reference to the bug that is fixed by that commit. So, we can use Github’s search function to find a commit that mentions 1018677. Just like that, we’ve found a single commit and more information.

The shutdown mentioned in the commit message is possibly referring to the browser being closed, but could also refer to the tab doing the speech recognizing, or even the speech system itself. Because multiple parts are being unloaded in parallel, there is a race condition between calling the abort object, and that object being unloaded from memory. This race can result in a classic use-after-free, jumping code execution to a memory location that’s already been freed.

All interesting, but how does this warrant a Critical rating? Enter the Web Speech API. I’m speculating just a bit, but it’s likely that this API uses the speech recognizer code in question. It may even be interacting with the security prompt that triggers the crash. Imagine that an attacking page attempts to use the speech API, and then releases the API object before the user can respond to the prompt. That *might* be the scenario that was discovered, though we’re deep into speculation, now. Continue reading “This Week In Security: Chrome Speech Bug, UDP Fragmentation, And The Big Citrix Vulnerability” →

This Week In Security: Windows 10 Apocalypse, Paypal Problems, And Cablehaunt

January 17, 2020 by 18 Comments

Nicely timed to drop on the final day of Windows 7 support, Windows 10 received a fix to an extremely serious flaw in crypt32.dll. This flaw was reported by the good guys at the NSA. (We know it was the good guys, because they reported it rather than used it to spy on us.) It’s really bad. If you’re running Windows 10, go grab the update now. OK, you’re updated? Good, let’s talk about it now.

The flaw applies to X.509 keys that use elliptic curve cryptography. We’ve discussed ECC in the past, but let’s review. Public key encryption is based on the idea that some calculations are very easy to perform and verify, but extremely difficult to calculate the reverse operation.

The historic calculation is multiplying large primes, as it’s unreasonably difficult to factorize that result by a conventional computer. A true quantum computer with enough qubits will theoretically be able to factorize those numbers much quicker than a classical computer, so the crypto community has been searching for a replacement for years. The elliptic curve is the solution that has become the most popular. An agreed-upon curve and initial vector are all that is needed to perform the ECC calculation.

There are potential weaknesses in ECC. One such weakness is that not all curves are created equal. A well constructed curve results in good cryptography, but there are weak curves that result in breakable encryption.

With that foundation laid, the flaw itself is relatively easy to understand. An X.509 certificate can define its own curve. The Windows 10 implementation doesn’t properly check the curve that is specified. A malicious curve is specified that is similar to the expected curve — similar enough that the checks in crypt32 don’t catch it. Continue reading “This Week In Security: Windows 10 Apocalypse, Paypal Problems, And Cablehaunt” →

This Week In Security: Camera Feeds, Python 2, FPGAs

January 10, 2020 by 6 Comments

Networked cameras keep making the news, and not in the best of ways. First it was compromised Ring accounts used for creepy pranks, and now it’s Xiaomi’s stale cache sending camera images to strangers! It’s not hard to imagine how such a flaw could happen: Xiaomi does some video feed transcoding in order to integrate with Google’s Hub service. When a transcoding slot is re-purposed from one camera to another, the old data stays in the buffer until it is replaced by the new camera’s feed. The root cause is probably the same as the random images shown when starting some 3D games.

Python is Dead, Long Live Python

Python 2 has finally reached End of Life. While there are many repercussions to this change, the security considerations are important too. The Python 2 environment will no longer receive updates, even if a severe security vulnerability is found. How often is a security vulnerability found in a language? Perhaps not very often, but the impact can be far-reaching. Let’s take, for instance, this 2016 bug in zipimport. It failed to sanitize the header of a ZIP file being processed, causing all the problems one would expect.

It is quite possible that because of the continued popularity and usage of Python2, a third party will step in and take over maintenance of the language, essentially forking Python. Unless such an event happens, it’s definitely time to migrate away from Python2.
Continue reading “This Week In Security: Camera Feeds, Python 2, FPGAs” →

This Week In Security: ToTok, Edgium, Chrome Checks Your Passwords, And More

January 3, 2020 by 11 Comments

Merry Christmas and happy New Year! After a week off, we have quite a few stories to cover, starting with an unexpected Christmas gift from Apple. Apple has run an invitation-only bug bounty program for years, but it only covered iOS, and the maximum payout topped out at $200K. The new program is open to the public, covers the entire Apple product lineup, and has a maximum payout of $1.5 million. Go forth and find vulnerabilities, and make sure to let us know what you find.

ToTok

The United Arab Emirates had an odd policy regarding VoIP communications. At least on mobile networks, it seems that all VoIP calls are blocked — unless you’re using a particular app: ToTok. Does that sound odd? Is your “Security Spider Sense” tingling? It probably should. The New York Times covered ToTok, claiming it was actually a tool for spying on citizens.

While that coverage is interesting, more meat can be found in [Patrick Wardle]’s research on the app. What’s most notable, however, is the distinct lack of evidence found in the app itself. Sure, ToTok can read your files, uploads your contact book to a centralized server, and tries to send the device’s GPS coordinates. This really isn’t too far removed from what other apps already do, all in the name of convenience.

It seems that ToTok lacks end-to-end encryption, which means that calls could be easily decrypted by whoever is behind the app. The lack of malicious code in the app itself makes it difficult to emphatically call it a spy tool, but it’s hard to imagine a better way to capture VoIP calls. Since those articles ran, ToTok has been removed from both the Apple and Google’s app stores.

SMS Keys to the Kingdom

Have you noticed how many services treat your mobile number as a positive form of authentication? Need a password reset? Just type in the six-digit code sent in a text. Prove it’s you? We sent you a text. [Joakim Bech] discovered a weakness that takes this a step further: all he needs is access to a single SMS message, and he can control your burglar alarm from anywhere. Well, at least if you have a security system from Alert Alarm in Sweden.

The control messages are sent over SMS, making them fairly accessible to an attacker. AES encryption is used for encryption, but a series of errors seriously reduces the effectiveness of that encryption. The first being the key. To build the 128-bit encryption key, the app takes the user’s four-digit PIN, and pads it with zeros, so it’s essentially a 13 bit encryption key. Even worse, there is no message authentication built in to the system at all. An attacker with a single captured SMS message can brute force the user’s PIN, modify the message, and easily send spoofed commands that are treated as valid.

Microsoft Chrome

You may have seen the news, Microsoft is giving up on their Edge browser code, and will soon begin shipping a Chromium based Edge. While that has been a source of entertainment all on its own, some have already begun taking advantage of the new bug bounty program for Chromium Edge (Edgium?). It’s an odd bounty program, in that Microsoft has no interest in paying for bugs found in Google’s code. As a result, only bugs in the Edge-exclusive features qualify for payout from Microsoft.

As [Abdulrahman Al-Qabandi] puts it, that’s a very small attack surface. Even so, he managed to find a vulnerability that qualified, and it’s unique. One of the additions Microsoft has made to Edgium is a custom new tab page. Similar to other browsers, that new tab page shows the user their most visited websites. The problem is that the site’s title is shown on that page, but without any sanity checking. If your site’s title field happens to include Javascript, that too is injected into the new tab page.

The full exploit has a few extra steps, but the essence is that once a website makes it to the new tab page, it can take over that page, and maybe even escape the browser sandbox.

Chrome Password Checkup

This story is a bit older, but really grabbed my attention. Google has rolled a feature out in Chrome that automatically compares your saved passwords to past data breaches. How does that work without being a security nightmare? It’s clever. A three-byte hash of each username is sent to Google, and compared to the hashes of the compromised accounts. A encrypted database of potential matches is sent to your machine. Your saved passwords, already encrypted with your key, is encrypted a second time with a Google key, and sent back along with the database of possible matches, also encrypted with the same Google key. The clever bit is that once your machine decrypts your database, it now has two sets of credentials, both encrypted with the same Google key. Since this encryption is deterministic, the encrypted data can be compared without decryption. In the end, your passwords aren’t exposed to Google, and Google hasn’t given away their data set either.

The Password Queue

Password changes are a pain, but not usually this much of a pain. A university in Germany suffered a severe malware infection, and took the precaution of resetting the passwords for every student’s account. Their solution for bootstrapping those password changes? The students had to come to the office in person with a valid ID to receive their new passwords. The school cited German legal requirements as a primary cause of the odd solution. Still, you can’t beat that for a secure delivery method.