This Week in Security

238 Articles

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

May 1, 2020 by 8 Comments

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

April 24, 2020 by 8 Comments

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

This Week In Security: Git, Patch Tuesday, Anti-Cheat, And Vulnerable Documentation

April 17, 2020 by 8 Comments

Git released an update on Tuesday, fixing an issue that could result in leaking credentials. The vulnerability was in how Git handles an HTTP URL containing a newline. Looking at the commits in 2.26.1, we can find an example of an attack:
url = "https://one.example.com?%0ahost=two.example.com/foo.git"

So doing a git pull against this repository will connect your git instance to an attacker’s server, but using the credentials from an arbitrary server. It seems like this could potentially be used to steal Github credentials, for instance. So go make sure you have an updated Git client.
Continue reading “This Week In Security: Git, Patch Tuesday, Anti-Cheat, And Vulnerable Documentation” →

This Week In Security: Zoom (Really This Time), Fingerprints, And Bloatware

April 10, 2020 by 9 Comments

You were promised Zoom news last week, but due to a late night of writing, that story was delayed to this week. So what’s the deal with Zoom? Google, SpaceX, and even the government of Taiwan and the US Senate have banned Zoom. You may remember our coverage of Zoom from nearly a year ago, when Apple forcibly removed the Zoom service from countless machines. The realities of COVID-19 have brought about an explosion of popularity for Zoom, but also a renewed critical eye on the platform’s security.

“Zoombombing”, joining a Zoom meeting uninvited, made national headlines as a result of a few high profile incidents. The US DOJ even released a statement about it. Those incidents seem to have been a result of Zoom default settings: no meeting passwords, no “waiting room”, and meeting IDs that persist indefinitely. A troll could simply search google for Zoom links, and try connecting to them until finding an active meeting. Ars ran a great article on how to avoid getting zoombombed (thanks to Sheldon for pointing this out last week).

There is another wrinkle to the Zoom story. Zoom is technically an American company, but its Chinese roots put it in a precarious situation. Recently it’s been reported that encryption keying is routed through infrastructure in China, even though the calling parties are elsewhere. In some cases, call data itself goes through Chinese infrastructure, though that was labeled as a temporary bug. Zoom was also advertising its meetings as having end-to-end encryption. That claim was investigated, and discovered to be false. All meetings get decrypted at Zoom servers, and could theoretically be viewed by Zoom staff. Continue reading “This Week In Security: Zoom (Really This Time), Fingerprints, And Bloatware” →

This Week In Security: 0-Days, Pwn2Own, IOS And Tesla

March 27, 2020 by 4 Comments

LILIN DVRs and cameras are being actively exploited by a surprisingly sophisticated botnet campaign. There are three separate 0-day vulnerabilities being exploited in an ongoing campaigns. If you have a device built by LILIN, go check for firmware updates, and if your device is exposed to the internet, entertain the possibility that it was compromised.

The vulnerabilities include a hardcoded username/password, command injection in the FTP and NTP server fields, and an arbitrary file read vulnerability. Just the first vulnerability is enough to convince me to avoid black-box DVRs, and keep my IP cameras segregated from the wider internet.

Continue reading “This Week In Security: 0-Days, Pwn2Own, IOS And Tesla” →

This Week In Security: Let’s Encrypt Revocation, Ghostcat, And The RIDLer

March 6, 2020 by 7 Comments

Let’s Encrypt recently celebrated their one billionth certificate. That’s over 190 million websites currently secured, and thirteen full-time staff. The annual budget for Lets Encrypt is an eye-watering $3.3+ million, covered by sponsors like Mozilla, Google, Facebook, and the EFF.

A cynic might ask if we need to rewind the counter by the three million certificates Let’s Encrypt recently announced they are revoking as a result of a temporary security bug. That bug was in the handling of the Certificate Authority Authorization (CAA) security extension. CAA is a recent addition to the X.509 standard. A domain owner opts in by setting a CAA field in their DNS records, specifying a particular CA that is authorized to issue certificates for their domain. It’s absolutely required that when a CA issues a new certificate, it checks for a CAA record, and must refuse to issue the certificate if a different authority is listed in the CAA record.

The CAA specification specifies eight hours as the maximum time to cache the CAA check. Let’s Encrypt uses a similar automated process to determine domain ownership, and considers those results to be valid for 30 days. There is a corner case where the Let’s Encrypt validation is still valid, but the CAA check needs to be re-performed. For certificates that cover multiple domains, that check would need to be performed for each domain before the certificate can be issued. Rather validating each domain’s CAA record, the Let’s Encrypt validation system was checking one of those domain names multiple times. The problem was caught and fixed on the 28th.

The original announcement gave administrators 36 hours to manually renew their affected certificates. While just over half of the three million target certificates have been revoked, an additional grace period has been extended for the over a million certs that are still in use. Just to be clear, there aren’t over a million bad certificates in the wild, and in fact, only 445 certificates were minted that should have been prevented by a proper CAA check.

Ghostcat

Apache Tomcat, the open source Java-based HTTP server, has had a vulnerability for something like 13 years. AJP, the Apache JServ Protocol, is a binary protocol designed for server-to-server communication. An example use case would be an Apache HTTP server running on the same host as Tomcat. Apache would serve static files, and use AJP to proxy dynamic requests to the Tomcat server.

Ghostcat, CVE-2020-1938, is essentially a default configuration issue. AJP was never designed to be exposed to untrusted clients, but the default Tomcat configuration enables the AJP connector and binds it to all interfaces. An attacker can craft an AJP request that allows them to read the raw contents of webapp files. This means database credentials, configuration files, and more. If the application is configured to allow file uploads, and that upload location is in the folder accessible to the attacker, the result is a full remote code execution exploit chain for any attacker.

The official recommendation is to disable AJP if you’re not using it, or bind it to localhost if you must use it. At this point, it’s negligence to leave ports exposed to the internet that aren’t being used.

Have I Been P0wned

You may remember our coverage of [Troy Hunt] over at haveibeenpwned.com. He had made the decision to sell HIBP, as a result of the strain of running the project solo for years. In a recent blog post, [Troy] reveals the one thing more exhausting that running HIBP: trying to sell it. After a potential buyer was chosen, and the deal was nearly sealed, the potential buyer went through a restructuring. At the end of the day, the purchase no longer made sense for either party, and they both walked away, leaving HIBP independent. It sounds like the process was stressful enough that HIBP will remain a independent entity for the foreseeable future.

You Were Warned

Remember the Microsoft Exchange vulnerability from last week? Attack tools have been written, and the internet-wide scans have begun.

Ridl Me This, Chrome

We’ve seen an abundance of speculative execution vulnerabilities over the last couple of years. While these problems are technically interesting, there has been a bit of a shortage of real-world attacks that leverage those vulnerabilities. Well, thanks to a post over at Google’s Project Zero, that dearth has come to an end. This attack is a sandbox escape, meaning it requires a vulnerability in the Chrome JS engine to be able to pull it off.

To understand how Ridl plays into this picture, we have to talk about how the Chrome sandbox works. Each renderer thread runs with essentially zero system privileges, and sends requests through Mojo, an inter-process communication system. Mojo uses a 128 bit numbering system to both identify and secure those IPC endpoints.

Once an attacker has taken over the unprivileged sandbox process, the next step is to figure out the port name of an un-sandboxed Mojo port. The trick is to get that privileged process to access its Mojo port name repeatedly, and then capture an access using Ridl. Once the port is known, the attacker has essentially escaped the sandbox.

The whole read is interesting, and serves as a great example of the sorts of attacks enabled by speculative execution leaks.

This Week In Security: Chrome Bugs And Non-bugs, Kr00k, And Letsencrypt

February 28, 2020 by 20 Comments

Google Chrome minted a new release to fix a trio of bugs on Monday, with exploit code already in the wild for one of them. The first two bugs don’t have much information published yet. They are an integer-overflow problem in Unicode internationalization, and a memory access issue in streams. The third issue, type confusion in V8, was also fixed quietly, but a team at Exodus Intel took the time to look at the patches and figure out what the problem was.

The actual vulnerability dives into some exotic Javascript techniques, but to put it simply, it’s possible to change a data-type without V8 noticing. This allows malicious code to write into the header area of the attacked variable. The stack, now corrupted, can be manipulated to the point of arbitrary code execution. The researchers make the point that even with Google’s fast-paced release schedule, a determined attacker could have several days of virtual zero-day exploitation of a bug mined from code changes. Story via The Register.

The Chrome Problem that Wasn’t

A second Chrome story came across my desk this week: Chrome 80 introduces a new feature, ScrollToTextFragment. This useful new feature allows you to embed a string of text in a URL, and when loading that address, Chrome will scroll the page to make that text visible. For certain use cases, this is an invaluable feature. Need to highlight a specific bit of text in a big document online?

The following bookmarklet code by [Paul Kinlan] is the easy way to start using this feature. Paste this code into the URL of a bookmark, put it on the bookmark bar, highlight some text in a webpage, and then run the bookmarklet. It should open a new tab with the new URL, ready to use or send to someone.

javascript:(function()%7Bconst%20selectedText%20%3D%20getSelection().toString()%3Bconst%20newUrl%20%3D%20new%20URL(location)%3BnewUrl.hash%20%3D%20%60%3A~%3Atext%3D%24%7BencodeURIComponent(selectedText)%7D%60%3Bwindow.open(newUrl)%7D)()

Since we’re talking about it in the security column, there must be more to the story. A privacy guru at Brave, [Peter Snyder], raised concerns about privacy implications of the feature. His argument has been repeated and misrepresented in a few places. What argument was he making? Simply put, that it’s not normal user behavior to immediately scroll to an exact position on the page. Because modern web pages and browsers do things like deferred loading of images, it could be possible to infer where in the page the link was pointing. He gives the example of a corporate network where DNS is monitored. This isn’t suggesting that the entire URL is leaked over DNS, but rather that DNS can indicate when individual components of a page are loaded, particularly when they are embedded images from other sites.

While this concern isn’t nonsensical, it seems to me to be a very weak argument that is being over-hyped in the press.

Whatsapp Groups Searchable on Google

It’s not new for search engines to index things that weren’t intended to be public. There is a bit of mystery surrounding how Google finds URLs to index, and StackExchange is full of plenty of examples of webadmins scratching their heads at their non-public folders showing up in a Google search.

That said, a story made the rounds in the last few days, that WhatsApp and Telegram group invites are being indexed by Google. So far, the official word is that all the indexed links must have been shared publicly, and Google simply picked them up from where they were publicly posted.

It appears that WhatsApp has begun marking chat invitation links as “noindex”, which is a polite way to ask search engines to ignore the link.

If it’s shown that links are getting indexed without being posted publicly online, then we have a much bigger story. Otherwise, everything is working as expected.

Letsencrypt Makes Attacks Harder

Letsencrypt has rolled out an invisible change to their validation process that makes a traffic redirection attack much harder. The new feature, Multi-Perspective Validation, means that when you verify your domain ownership, Letsencrypt will test that verification from multiple geographic regions. It might be possible to spoof ownership of a domain through a BGP attack, but that attack would be much harder to pull off against traffic originating from another country, or multiple countries simultaneously. Letsencrypt is currently using different regions of a single cloud, but plans to further diversify and use multiple cloud providers for even stronger validation.

Kr00k

Brought to us by the researchers at Eset, Krook (PDF) is a simple flaw in certain wireless chips. So far, the flaw seems to be limited to WPA2 traffic sent by Broadcom and Cypress chips. They discovered Kr00k while doing some followup research on KRACK.

Let’s talk about WPA2 for a moment. WPA2 has a 4-way handshake process that securely confirms that both parties have the shared key, and then establishes a shared Temporal Key, also known as a session key. This key is private between the two devices that performed the handshake, meaning that other devices on the same wireless network can’t sniff traffic sent by other devices.

When a device disconnects, or disassociates, that session key is reset to all 0s, and no packets should be sent until another handshake is performed. Here’s the bug: The packets already in the output buffer are still sent, but are encrypted with the zeroed key, making them trivially decrypted. As it’s simple to trigger deauthentication events, an attacker can get a sampling of in-the-clear packets. The ubiquity of TLS is a saving grace here, but any unencrypted traffic is vulnerable. Eset informed vendors about the flaw in 2019, and at least some devices have been patched.

Exchange

Microsoft Exchange got a security patch this past Tuesday that addressed a pair of bugs that together resulted in a remote code execution vulnerability. The first bug was an encryption key that is generated on Exchange server installation. That generation seemed to lack a good source of entropy, as apparently every Exchange install uses the the exact same key.

The second half of this bug is a de-serialization problem, where an encrypted payload can contain a command to run. Because the encryption key is known, any user can access the vulnerable endpoint. The process of exploitation is so trivial, be sure to patch your server right away.

TODO: Remove Vulnerabilities

This one is just humorous. An Intel virtualization feature appears to have been pushed into the Linux kernel before it was finished. Know what unfinished code tends to contain? Bugs and vulnerabilities. CVE-2020-2732, in this case. It’s unclear how exactly an exploit would work, but the essence is that a virtual guest is allowed to manipulate system state in unintended ways.