Cyber Monday – ASW #176

For once apparently a compromise _not_ due to a WordPress flaw, but a compromise of GoDaddy's hosted WordPress credentials and SSL certs. It appears an attacker used a compromise password to gain access to a system that stored customers' SFTP credentials. Even if the credentials were hashed, plenty of customers are sure to have weak passwords and, sadly, plenty are likely to have the same password for that SFTP system as for their email. The appsec angle is a simple and obvious one: treat credentials as highly sensitive data and place significant restrictions on what services may access those credentials, even their hashed version. As an added bonus, consider alerts on access patterns to that credential store or the amount or rate of egress traffic from it. GoDaddy's breach notification is at https://aboutus.godaddy.net/newsroom/company-news/news-details/2021/GoDaddy-Announces-Security-Incident-Affecting-Managed-WordPress-Service/default.aspx

This is a technical writeup about reverse engineering firmware in a DSP present on a significant amount of Android devices. It exploits a sequence of flaws to eventually change parameters for the DSP. For example, a parameter might be update to log speech processing information -- which an attacker could then exfiltrate from the device. The "classic heap overflow" and "improper validation of array index" mentioned in the writeup is basically boilerplate appsec commentary for C code. One detail that stands out is this comment, "...generally, device manufacturers ?do not care about validating configuration files properly because they are not available to unprivileged users. But in our case, we are in control of the configuration files. The [Hardware abstraction layer] configuration becomes an attack vector." The writeup mentions that the vendor's response is to remove a capability that sets the config file for the device. That seems effective in terms of disrupting the attack. It would also be interesting to consider whether signing config files, for provenance or integrity, would be something to consider or whether that's less effective as a device (i.e., client-side) control. If you're interested in getting into lots more C code, check out https://www.freertos.org.

The name of this mode is setting itself up for plenty of jokes and snark about the viability of its superness and duperness. But naming aside, there's a lot of good application hardening going into this mode. In particular, they're disabling the JIT for JavaScript. This means performance benchmarks will suffer, but in their testing Microsoft believes the impact to user experience will be negligible. I like this approach because it's taking a larger look at performance and security in context with each other and, rather than trying to optimize for benchmarks, it's (hopefully!) showing that removing a large attack surface that's been notoriously difficult to secure will have an overwhelmingly positive benefit to users without negative impact on their perception of browser performance. This mode still needs work. It doesn't yet support WebAssembly, something we talked about just last episode at https://securityweekly.com/asw175

Here's a technical writeup of web technologies of CSP and OAuth to balance out this week's reverse engineering article and ties in with the bug bounty topics. Researchers found an implementation bug in how WebKit handles CSP violations. WebKit is the browser engine within Safari as well as used by any app from Apple's App Store that uses web browsing. They would target URLs commonly used for SSO or OAuth (i.e., they expect to redirect to different domains as part of the workflow), create a CSP directive that would trigger a violation report to that URL, then receive the redirected URL back to Safari. The POC for the exploit is only about seven lines of HTML and could be used for account takeovers. While a successful attack still needed user interaction to bypass Safari's Intelligent Tracking Prevention, there are still several steps a site can take to harden their OAuth flows. Adopting SameSite cookies would be one of the fastest and best -- presuming the site's domain structure and interactions wouldn't inhibit such adoption. The researchers brought this exploit to many bug bounty programs in order to get sites to harden their OAuth flows. In the article, they note how it took a while to educate various security teams on why this was impactful and how weaknesses in their authentication and authorization flows could be exploited. Give their article a read and check out their recorded presentation at the end.

If you like PHP or deserialization bugs, this one's for you. The writeup is a quick walkthrough with readily understandable code to demonstrate how this could turn into an arbitrary command execution. Check out the researcher's writeup at https://talosintelligence.com/vulnerability_reports/TALOS-2021-1383

This article has two great tastes that taste great together: HTTP smuggling and fuzzing. Mostly just highlighting it as an example of fuzzing HTTP endpoints since most of the time we associate fuzzing with compiled apps. Check out the paper at https://bahruz.me/papers/ccs2021treqs.pdf

Earlier this year Microsoft patched the Windows Installer, but apparently the patch didn't completely fix the issue. Unfortunately, nothing new there. What is interesting, is why the researcher published the new vulnerability: Abdelhamid Naceri was annoyed at Microsoft for their move to pay less for bug bounties, claiming that the firm now pays a bounty of $1000 for a vulnerability which they used to pay $10,000 for. Is this something companies will have to consider as we encourage them to set up and manage bug bounties? From a quick search, I don't find any announcement from Microsoft saying they were restructuring their bounties. As a note, looks like msft is paying around $13 million per year for the last few years in bounties.

This is an interesting counterpoint to the previous story. From Bugcrowd's Casey Ellis: "As tools improve and companies become better at application security, the easiest to find vulnerabilities — so-called "low-hanging fruit" — disappear and only hard-to-find issues are left. This means as the bug bounty ecosystem matures, maintaining the interest of researchers requires larger bounties" Discuss. :)

This is a long one, but makes for a good read while watching somebody else put up holiday decorations. :) The authors document several years worth of work into researching, identifying, and identifying weaknesses in the Tegra security coprocessor used in the Nintendo Switch's SoC.