This Week in Security

283 Articles

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.

This Week In Security: Unicode, Truecrypt, And NPM Vulnerabilities

December 20, 2019 by 22 Comments

Unicode, the wonderful extension to to ASCII that gives us gems like “✈”, “⌨”, and “☕”, has had some unexpected security ramifications. The most common problems with Unicode are visual security issues, like character confusion between letters. For example, the English “M” (U+004D) is indistinguishable from the Cyrillic “М” (U+041C). Can you tell the difference between IBM.com and IBМ.com?

This bug, discovered by [John Gracey] turns the common problem on its head. Properly referred to as a case mapping collision, it’s the story of different Unicode characters getting mapped to the same upper or lowercase equivalent.

'ß'.toLowerCase() === 'SS'.toLowerCase() // true
// Note the Turkish dotless i
'John@Gıthub.com'.toUpperCase() === 'John@Github.com'.toUpperCase()

GitHub stores all email addresses in their lowercase form. When a user sends a password reset, GitHub’s logic worked like this: Take the email address that requested a password reset, convert to lower case, and look up the account that uses the converted email address. That by itself wouldn’t be a problem, but the reset is then sent to the email address that was requested, not the one on file. In retrospect, this is an obvious flaw, but without the presence of Unicode and the possibility of a case mapping collision, would be a perfectly safe practice.

This flaw seems to have been fixed quite some time ago, but was only recently disclosed. It’s also a novel problem affecting Unicode that we haven’t covered. Interestingly, my research has turned up an almost identical problem at Spotify, back in 2013.
Continue reading “This Week In Security: Unicode, Truecrypt, And NPM Vulnerabilities” →

This Week In Security: Tegra Bootjacking, Leaking SSH, And StrandHogg

December 6, 2019 by 9 Comments

CVE-2019-5700 is a vulnerability in the Nvidia Tegra bootloader, discovered by [Ryan Grachek], and breaking first here at Hackaday. To understand the vulnerability, one first has to understand a bit about the Tegra boot process. When the device is powered on, a irom firmware loads the next stage of the boot process from the device’s flash memory, and validates the signature on that binary. As an aside, we’ve covered a similar vulnerability in that irom code called selfblow.

On Tegra T4 devices, irom loads a single bootloader.bin, which in turn boots the system image. The K1 boot stack uses an additional bootloader stage, nvtboot, which loads the secure OS kernel before handing control to bootloader.bin. Later devices add additional stages, but that isn’t important for understanding this. The vulnerability uses an Android boot image, and the magic happens in the header. Part of this boot image is an optional second stage bootloader, which is very rarely used in practice. The header of this boot image specifies the size in bytes of each element, as well as what memory location to load that element to. What [Ryan] realized is that while it’s usually ignored, the information about the second stage bootloader is honored by the official Nvidia bootloader.bin, but neither the size nor memory location are sanity checked. The images are copied to their final position before the cryptographic verification happens. As a result, an Android image can overwrite the running bootloader code. Continue reading “This Week In Security: Tegra Bootjacking, Leaking SSH, And StrandHogg” →

This Week In Security:Malicious Previews, VNC Vulnerabilities, Powerwall, And The 5th Amendment

November 30, 2019 by 29 Comments

Malware embedded in office documents has been a popular attack for years. Many of those attacks have been fixed, and essentially all the current attacks are unworkable when a document is opened in protected view. There are ways around this, like putting a notice at the top of a document, requesting that the user turn off protected view. [Curtis Brazzell] has been researching phishing, and how attacks can work around mitigations like protected view. He noticed that one of his booby-trapped documents phoned home before it was opened. How exactly? The preview pane.

The Windows Explorer interface has a built-in preview pane, and it helpfully supports Microsoft Office formats. The problem is that the preview isn’t generated using protected view, at least when previewing Word documents. Generating the preview is enough to trigger loading of remote content, and could feasibly be used to trigger other vulnerabilities. [Curtis] notified Microsoft about the issue, and the response was slightly disappointing. His discovery is officially considered a bug, but not a vulnerability.

VNC Vulnerabilities

Researchers at Kaspersky took a hard look at several VNC implementations, and uncovered a total of 37 CVEs so far. It seems that several VNC projects share a rather old code-base, and it contains a plethora of potential bugs. VNC should be treated similarly to RDP — don’t expose it to the internet, and don’t connect to unknown servers. The protocol wasn’t written with security in mind, and none of the implementations have been sufficiently security hardened.

Examples of flaws include: Checking that a message doesn’t overflow the buffer after having copied it into said buffer. Another code snippet reads a variable length message into a fixed length buffer without any length checks. That particular function was originally written at AT&T labs back in the late 90s, and has been copied into multiple projects since then.

There is a potential downside to open source that is highlighted here. Open source allows poorly written code to spread. This isn’t a knock against open source, but rather a warning to the reader. Just because code or a project uses an OSS license doesn’t mean it’s secure or high quality code. There are more vulnerabilities still in the process of being fixed, so watch out for the rest of this story. Continue reading “This Week In Security:Malicious Previews, VNC Vulnerabilities, Powerwall, And The 5th Amendment” →

This Week In Security: More WhatsApp, Nextcry, Hover To Crash, And Android Permissions Bypass

November 22, 2019 by 7 Comments

There is another WhatsApp flaw, but instead of malicious GIFs, this time it’s malicious mp4 files. Facebook announced the vulnerability late last week. An update has been released, so first go make sure WhatsApp is updated. Facebook’s advisory is a bit light on the details, simply saying that a “stack-based buffer overflow” was possible as a result of “parsing the elementary stream metadata of an mp4 file”.

Shortly after the bug was announced, a GitHub repository popped up, with a claimed proof-of-concept mp4 file for CVE-2019-11931. (Thanks to [justtransit] on Reddit for the link.) I can’t easily test the PoC file, but we can take a look at it to see what the vulnerability is. What tools do we need to take a look? A hex editor is a good start. I’m using GHex, simply because it was available and easily installed on Fedora. Continue reading “This Week In Security: More WhatsApp, Nextcry, Hover To Crash, And Android Permissions Bypass” →