JSON and a Regex, IoT Passwords, CAN Injection, Twitter CVE, Complexity, Tabletops – ASW #236

From the days when JSON.parse came from a library instead of the language (and therefore natively supported in browsers), comes a story of Unicode, control flow characters, and regular expressions.

The end of the article also highlights the importance of providing clear explanations about security issues -- even when you're talking with an expert on the development side. And it ends with an example of how devs are just as security-minded as appsec folks.

This article goes well with the other one about hacking the CAN bus in cars. The other article talks about attackers stealing a parked car off the street. This one talks about how an attacker might get inside a garage.

Importantly, this article shows the challenge in getting IoT makers to respond and react to security issues. So far the company, Nexx, appears to be keeping their own doors closed to any engagement with the security researcher.

Sometimes an article is sure to get the attention of both me and John. In this case, John posted his comments first, so we'll defer to him.

But I couldn't let the article's parenthetical go by without highlighting it: "(there’s a CAN bus orbiting Mars right now)" !?

Here's a notionally security-related manipulation of the recommendation algorithm that Twitter open sourced recently. We mentioned it last week in episode 235.

But is it really worthy of a CVE? It seems more like a way to game the system en masse against a targeted user -- something that's common across many social media platforms. The only difference here is some visibility into how to more efficiently coordinate a mass action.

But what's the security flaw? There's an aspect here that this could be abused and fall under a trust & safety issue. But giving it a CVE seems to dilute their purpose. And it's a different type of service and customer interaction than the tracking of vulns for Cloud Service Providers that we've covered in the past.

Here's a very long and informative article on Understanding Social Media Recommendation Algorithms.

Phil Venables covers number five of the six fundamental forces that shape infosec risk.

Appsec and dev teams alike should read it. The article goes beyond the trope of complexity is the enemy of security (or however you'd like to formulate it). Instead, it shows how to embrace complexity.

One of my favorite items is "opinionated defaults" -- ideally we'd do away with the concept of hardening guides and provide guidance on what defaults to adjust if you truly need to expand an app's attack surface.

I had two specific reasons to include this article, (1) we talked with Lina Lau about successful tabletop exercises in episode 230, and (2) it's a chance to mention role-playing games like Dungeons & Dragons.

But the takeaway from this article should be that these exercises help. They're effective for testing lines of communication, discovering ownership (or lack thereof) for services and data, and finding out if runbooks and processes are as comprehensive as they should be.

A little bit old, but worth a quick mention for the examples of fuzzing and what it found within a codebase written in Go. One example was a stack overflow, which might seem surprising in a memory-safe language. But it's a reminder that fuzzing is a useful, accurate tool for finding bugs -- if there's a crash, there's a bug. It's also a reminder that even though memory-safe languages have unsafe ways to call into other binaries, that's not the only source of memory-related issues.

Check out the report (PDF).

Time to run npm audit again. There's a critical vuln in vm2 that leads to arbitrary RCE with just a few lines of code.

This is a hands-on walkthrough of each level in flaws.cloud. Choose how you'd like to approach this vulnerable environment -- either going in and working through each level without hints, or using this resource for hints or a primer on cloud security techniques.

CVE-2014-0160 ruined the weekend of tons of DevOps and appsec teams from its announcement on April 7, 2014.

It stemmed from mishandling client-supplied lengths and reading past the bounds of a buffer, which exposed arbitrary memory that could include private keys. It also stemmed from a feature of OpenSSL that was unnecessary, at least in production environments.

Heartbleed reinvigorated a trend of branded vulns -- names, logos, and websites marketing security flaws.

It also reinvigorated the development of TLS stacks, with a few orgs diving in to improve OpenSSL and many abandoning it in favor of fresh designs.

This is a meaty but readable dive into how criminals are using a black-market device to inject CAN bus messages into a car to unlock the doors and allow starting the engine to steal the vehicle.

Not interesting enough? The injection is performed by removing a headlight to get to the wiring, since headlights are on CAN bus, nowdays.

Read on to learn a bit about CAN busses in cars, their lack of security, and some ways to block this attack.

Anybody want to bet that some car manufacturer will move to encryption and use a common key across all vehicles?

Now, this is a little click-baity, yes. Many of us would agree that a short term response to vulnerability is to block access, when other methods of access are available. How long should this block last, and when writing such software, how much thought should we put into considering how we would secure it in a similar situation?

There's a few requirements, but researchers figured out a way to use ICMP redirects to perform a MiTM attack on WiFi clients. Apparently, around 90% of WiFi routers are not inspecting packets closely enough to block these packets, due to the overhead such inspection would require.

Apparently there was some plaintext transmission going on in situations where "scan to remote storage" (my words) was used on HP LaserJets configured with IPSEC.

If you have/had IPSEC configured on your printer - do reach out. I'm very curious about the use case, here...

Thought I'd throw in a PR that mitigates CVE-2023-28710, an arbitrary file read vuln in Airflow's Spark provider