OT Security – Huxley Barbee – ASW #259

I'm always intrigued by protocol flaws. It's always educational to see where implementations differ due to ambiguity in a protocol spec. It's also interesting to see how the state machine of a protocol can be abused.

This article from Cloudflare has a bit of marketing mixed into it, but it's a good walkthrough of how HTTP/2's streams were abused as a traffic amplifier for a DDoS attack. These types of amplification attacks, where a single packet can trigger multiple response packets, are always favorites of DDoS techniques.

Google also provided their own write-up, which also briefly talks about whether HTTP/3 has similar capabilities for potential abuse.

Daniel Stenberg walks through the code changes that led to the recent high severity flaw in Curl. It has some nice insights for C coders or those working on state machines. It also has a good observation on what he considers a poor design choice at the time -- the library's behavior shouldn't have changed from a remote to local name resolution; it should have failed. That does sound like better behavior to fail when what the user attempted to do doesn't work.

He also comments on why Curl will remain written in C for a long time to come. I'll add that Curl has a relatively solid history of security. Rewriting it for the sake of memory safety sounds good if all you consider is the C language aspect, but taking into consideration risk, engineering choices, and the opportunity cost of focusing on Curl vs. other projects makes this project look like a lower priority for a complete rewrite.

He also links to the original bug bounty report if you're interested in more technical details of the exploit scenario.

This is pretty cool news from OWASP. They're working with Ecma International to make CycloneDX a standard.

On the technical side, this would normalize how a lot of SBOMs are represented (along with SaaSBOMs, describing known vulns, and a few other types of manifests).

But it's also appealing on the development side since there's no cost to obtaining the spec or participating in its direction, which is very different from an ISO style approach.

Let's just hope there's no top 10 list of standardization risks that emerge from this.

Evolution is a good metaphor in this article. Biological evolution often requires many generations and many evolutions to manifest large changes. For Windows, getting rid of NTLM seems closer and inevitable, but the date for doing so remains unclear.

NTLM has long been a source of insecurity, especially because of its susceptibility to replay attacks like Pass The Hash -- a technique dating back to the late 90s. But the larger lesson of this article is probably how long it takes to deprecate and replace a protocol, even when it has a poor history of security.

Kerberos will be an improvement, but remember to keep in mind the Golden Ticket attacks against that protocol. In other words, prevent attackers from gaining access to your domain controls and protect your secrets.

With NTLM on a near-term deprecation path, Microsoft is cleaning out more cruft that it's accumulated over the years. VBScript is on its way out (with Python moving into places like Excel).

From an appsec perspective, it's not likely that the loss of VBScript will be much noticed. Its modern use seems to have been a favorite of malware authors and that's about it. In that article, it was also nice to see that TLS 1.0 and 1.1 will be disabled by default. Browsers have already moved to TLS 1.2 by default. An even better step will be getting all apps off those older protocols altogether.

I like this bounty program mostly because it separates a domain of AI-related flaws from the typical appsec flaws that might get conflated or misunderstood as associated with AI. Bonus points for not referencing any top 10 lists in the examples.

Full details here. Make sure to check out the types of flaws they're actually looking for, it's a lot more specific than just tricking a prompt to use foul language in a response to you.

I grabbed this article to emphasize its points about migrating to a new language. Android's motivation here was to rewrite what's essentially a bootloader in a memory-safe language and with a design that's more resilient to attacks. (They link to 42 security flaws found in the U-Boot predecessor.)

However, the challenges section is where to pay attention. For one, devs need to be trained on a new language. For this bare metal use case, there are still edge cases where Rust needs to dip into unsafe memory handling and raw pointers.

It's been 20 years since the first Patch Tuesday from Microsoft in October 2003. As we note in this episode, NTLM and VBScript are just finally being deprecated and TLS 1.0 and 1.1 will be disabled by default.

Two decades of development have produced a lot of patches. Let's see how Microsoft's recent forays into Rust will impact the next two decades.

Find out more about the history of Microsoft's push for security here.

The OpenSSF have released version 1.0 of the Security Insights Specification. In a nutshell, this codifies a machine-readable format for security contacts and processes for open source projects (I guess closed source projects could use it too, but why?).

This is where you find me when I get sucked into YouTube late at night...

This is a neat video where some folks reveal, explain, and peruse a tractor paper (remember that?) printout of the assembly code for Apollo 12. Besides the "OMG 6 inches of code printout" aspect, and the "OMG that's all assembly" moments, it's neat to see how readable the codebase is. They even walk through how a bug is patched, including a walkthrough of the bug that was partially the result of hardware having direct access to the CPU.

Also - 40,000 punchcards...

I know - bear with me. It's readable - for assembly.

Macworld is running a user perspective on how Apple's growing number of permissions prompts is taking a bite out of the fun of computing.

I sorta understand - as a longtime MacOS/IOS user, I've answered these prompts slowly over time as they've been added, so it's not a huge deal to me. I can imagine the experience of starting anew with a modern security- and privacy-conscious OS can be quite grating.

Just something to think about as we design software.

The range of things that a .sln (solution) file can instruct a modern IDE to perform is quite wide. As a result, most IDEs now have some level of protection against opening untrusted solution files.

Visual Studio has such functionality, but over that functionality's ~2 years of existence, it still hasn't been enabled by default. On top of that, while many apps/OSes nowdays have protection based on MOTW (mark of the web, for downloaded files), it looks like Visual Studio is ignoring this.

Apparently Microsoft's playing the "this is not a vulnerability" game. Hopefully that'll change sooner rather than later...

Squid proxy has long been a popular caching http proxy for ISPs and enterprises, albeit a often complex system to setup and configure. As web attacks have become more common, many orgs have looked to http proxies to help secure their enterprises.

With that said, a researcher did some research and found 50 vulnerabilities in Squid, the list of which reads like a jumbled mix of all of the top-10 lists out there...

I always like seeing hackers come up with creative ways to "improve" their attacks. In this case, some folks have figured out a new way to combine blockchain and wordpress.

In a nutshell - they have vulnerable module in wordpress which allows them to render content to the screen, and then they load that content from a binance contract. What this allows them to do is to control when the exploit is active by just updating the blockchain.