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.

The injected command downloads an installer script that attempts to hide its infection vector, download some binaries, and then add a persistent hook into an existing system script. From there, the malware seemed to enter an observation mode, attempting to upload data about the host device to a command and control server. Sophos has stated that “we have not discovered any evidence that the data collected had been successfully exfiltrated.” What is missing from their articles on the issue is their reasoning to conclude that no customer data was stolen.

The attack was discovered as a result of a bug in the malware code. The attempt at hiding the infection was as simple as removing the malicious SQL data, but in some cases, the legitimate entry was apparently deleted instead, and the injected code was displayed on the administrator dashboard. While it’s not certain how long the attack was in the wild, the DNS names associated with this campaign seem to all have been registered in late March of this year.

The iOS Attacks that Never Happened?

Last week we talked about some particularly scary iOS mail vulnerabilities. A few days have gone by, and Apple has responded. They acknowledge that it’s a novel bug, but dispute the idea that it could be used for a device compromise, and insist that it is unlikely that these bugs were actually used in an attack.

Apple’s statement reiterates one thing the ZecOps researchers said: This bug is not enough to escape the mail system context. That in itself is certainly true. What will be interesting to see is if ZecOps researchers can find an additional vulnerability that would have allowed system compromise. So far ZecOps is holding firm to their opinion that this was an in-the-wild vulnerability. We’ll keep an eye out for more developments on this interesting saga.

Apple takes all reports of security threats seriously. We have thoroughly investigated the researcher’s report and, based on the information provided, have concluded these issues do not pose an immediate risk to our users. The researcher identified three issues in Mail, but alone they are insufficient to bypass iPhone and iPad security protections, and we have found no evidence they were used against customers. These potential issues will be addressed in a software update soon. We value our collaboration with security researchers to help keep our users safe and will be crediting the researcher for their assistance.

SMB Relay Attacks

Relay attacks against Microsoft’s NTLM authentication scheme are old news. Many years ago it was discovered that a man-in-the-middle attack against an SMB server was an effective way to get a toe-hold into an organization’s network. A user thinks they are authenticating with a known machine, but really their authentication session is bouncing through a malicious intermediary. Surely after nearly 20 years this bug has been fully put to rest, right? As is often the case, backwards compatibility gives these kind of protocol vulnerabilities a much longer than expected shelf-life.

On the 27th, researchers from SecureAuth published a new approach to making relay attacks more effective. The SMB message “STATUS_NETWORK_SESSION_EXPIRED” triggers a session re-authentication with no user interaction. Once a user has made an active connection through the MitM server, the attacker can trigger a reauth, and reflect the new authentication to a different server. It’s a clever attack, and they have even published the code to make it work, so if SMB attacks are your thing, go check it out.

GIF of Death

No, not some urban legend about watching a GIF of a girl crawling out of a well. This was a clever combination of a subdomain hijack and a way to get a user to hand over a Microsoft Teams authentication cookie.

First, subdomain hijacking. It’s not uncommon for an organization to have various subdomains that aren’t in active use. Where are those domains actually pointing? In some cases, they are pointing somewhere like GitHub pages, but without an account set up. What happens if someone else claims that account? Something like data-dev.teams.microsoft.com could suddenly be controlled by someone unrelated to Microsoft.

A teams.microsoft.com authentication cookie gets sent along with any HTTP request to teams.microsoft.com or any subdomains. So how to get someone to access the trapped subdomain? That’s where the GIF comes in. Sending a GIF link over teams automatically loads the GIF from the malicious subdomain, and sends the auth cookie along with it. It’s Firesheep all over again.

Beware of the GIF: Account Takeover Vulnerability in Microsoft Teams | CyberArk

Android Bluetooth Bug

And instead of picking on iOS further, there’s an Android bug to consider. [Jan Ruge] at the SEEMOO lab discovered an odd crash in the Android Bluetooth stack through fuzzing. Tracing the crash, they discovered that malformed Bluetooth packet fragments could cause a system call to memcpy with a negative length value. Because of the datatype, size_t, that negative value is interpreted as a very large positive value inside the memcpy call. One would expect this to write garbage to memory until it reaches the end of addressable memory, resulting in a kernel crash and reboot. Instead, due to optimizations in memcpy, some data is copied from a negative memory offset. In the case of Bluetooth ping requests, this can leak memory contents in the ping response packets.

If a previous packet happens to be in memory directly in front of the current packet, it’s possible to overwrite the actual struct header, and leak much more information as a result. So far, this bug sounds similar to Heartbleed. Because it’s triggered by a memcpy controlled by an attacker, there’s potential for much more. And in fact, researchers did find a pointer they could overwrite, and eventually jump execution into memory they control. It’s a convoluted process with less than 50% success, but a crash without compromise just crashes and restarts the Bluetooth daemon, enabling multiple attempts.

This exploit was privately disclosed to Google, and fixed in the February security update. There isn’t any evidence that this has been exploited in the wild, but now that the report is public, it’s important to make sure you’re up-to-date. If you want to know more about the tooling the SEEMOO group used to find this bug, [Jiska Classen] talked about the lab’s Bluetooth efforts in December, and she just gave a detailed talk about the Frankenstein tool that we’re still watching.