This Week in Security

316 Articles

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” →

This Week In Security: Fuzzing Fixes, Foul Fonts, TPM Timing Attacks, And More!

November 15, 2019 by 11 Comments

An issue was discovered in libarchive through Google’s ClusterFuzz project. Libarchive is a compression and decompression library, widely used in utilities. The issue here is how the library recovers from a malformed archive. Hitting an invalid header causes the memory in use to be freed. The problem is that it’s possible for file processing to continue even after that working memory has been freed, leading to all kinds of problems. So far an actual exploit hasn’t been revealed, but it’s likely that one is possible. The problem was fixed back in May, but the issue was just announced to give time for that update to percolate down to users.

Of note is the fact that this issue was found through Google’s fuzzing efforts. Google runs the oss-fuzz project, which automatically ingests nightly builds from around 200 open source projects and runs ClusterFuzz against them. This process of throwing random data at programs and functions has revealed over 14,000 bugs.
Continue reading “This Week In Security: Fuzzing Fixes, Foul Fonts, TPM Timing Attacks, And More!” →

This Week In Security: BGP Bogons, Chrome Zero Day, And Save Game Attacks

November 8, 2019 by 24 Comments

Our own [Pat Whetman] wrote about a clever technique published by the University of Michigan, where lasers can be used to trigger a home assistant device. It’s an interesting hack, and you should go read it.

Borrowing IP Addresses

We’ve lived through several IPv4 exhaustion milestones, and the lack of available addresses is really beginning to show, even for trolls and scammers. A new approach takes advantage of the weak security of the Border Gateway Protocol, and allows bad actors to temporarily take over reserved address blocks. These particular providers operate out of Russia, operating network services they advertise as “bulletproof”, or immune to takedown requests. What better way to sidestep takedowns than to use IP addresses that aren’t really yours to begin with?

BGP spoofing has been at the center of other types of attacks and incidents, like in 2018 when a misconfiguration in a Nigerian ISP’s BGP tables routed traffic intended for Google’s servers through Chinese and Russian infrastructure. In that case it appeared to be a genuine mistake, but little prevents malicious BGP table poisoning.

Chrome Zero-day

Google released an update to Chrome on the 31st that addresses two CVEs, one of which is being actively exploited. That vulnerability, CVE-2019-13720, is a race condition resulting in a potential use-after-free. Kaspersky Labs found this one being actively used on a Korean news site. The attack runs entirely from Javascript, and simply visiting a malicious site is enough for compromise, so update Chrome if it’s installed.

Anti-anti-doping

What do you do when you feel you’ve been unfairly targeted by an anti-doping investigation? Apparently hacking the investigating agency and releasing stolen information is an option. It seems like this approach is more effective when there are shenanigans revealed in the data dump. In this case, the data being released seems rather mundane.

Firefox Blocking Sideload Extensions

Mozilla made a controversial announcement on the 31st. They intend to block “sideload” browser extensions. Until this change, it was possible to install browser extensions by copying them to a particular folder on the computer. Some legitimate extensions used this installation method, but so did malware, adware, and other unwanted software. While this change will block some malicious add-ons, it does present a bit of a challenge to a user installing an extension that isn’t on the official Mozilla store or signed by Mozilla.

As you might imagine, the response has been… less than positive. While making malware harder to install is certainly welcome, this makes some use cases very difficult. An example that comes to mind is a Linux package that includes a browser extension. It remains to be seen exactly how this change will shake out.

Save Games as Attack Vector

An oddball vulnerability caught my eye, published by [Denis Andzakovic] over at Pulse Security. He discovered that a recent indy game, Untitled Goose Game, can be manipulated into running arbitrary code as a result of loading a maliciously modified save file. The vulnerability is rooted in a naive deserialization routine.

If you’re interested in a deeper dive into .net deserialization bugs, a great paper was submitted to Blackhat 2012 discussing the topic. The short version is that if a programmer isn’t careful, the deserialization routine can overwrite variables in unexpected ways, potentially leading to code execution.

At first glance, a vulnerability triggered by a malicious save file seems relatively harmless. The level of access needed to modify a save file on a hard drive is enough to compromise that computer in a multitude of better ways. Enter cloud save synchronization. Steam, for instance, will automatically sync save games across a user’s install locations. This is a very useful feature for those of us that might play the same game on a laptop and a desktop. Having the save game automatically synced to all your devices is quite useful, but if an attacker compromised your Steam account, your save games could be manipulated. This leads to the very real possibility that an attacker could use a save game vulnerability to turn a Steam account compromise into an attack on all your machines with Steam installs.