Nagios and Abandoned Projects, Hacking Trains (to Fix Them), OAuth Threats, 5Ghoul – ASW #267

I don't dismiss programming languages out of hand (except for Perl), but I do make distinctions between design patterns in legacy code and how a language encourages modern design principles.

I also hadn't heard about Nagios in a while, so this article caught my attention for a few reasons. Probably the biggest one was seeing NCC Group share an example username that leads to command execution: research name: "{{ lookup("pipe", "tar -czf - $HOME/.ssh/ 2>/dev/null | base64 -w0 ") }}". A vuln like that looks straight out of the early 2000s. Codebases should evolve over time in ways that make such ancient exploit techniques go extinct.

And, reminiscent of an article we covered last week that included a reference to the abandoned TinyXML project, here's another choice quote from NCC Group's report about the web shell used in Nagios, which is, “...a large and complex application written in ... C [that] …has not been updated in 4 years, and a release has not been made since 2016.”

Sigh...

DRM, right to repair, and copyright all in one. This is the kind of appsec I love to read about in terms of hackers fighting for the owners of hardware -- it just so happens to be rather large hardware.

This also means we've finally covered planes, trains, and automobiles this year.

There's a mix of abuses here, many of which could disappear (or at least be significantly reduced) by strong MFA. (I'd love to see passkey adoption as well!)

We've talked a lot about OAuth this year. I wanted to highlight this article to reinforce that goal of adoption OAuth plus MFA, while also keeping in mind how the attack surface and threat model shifts slightly when doing so. With OAuth it's important to be able to invalidate sessions, audit connected apps, and determine when it's appropriate to just change a password vs. change a password and reset OAuth connections.

The end of the article gets into more marketing, but at least the mitigations note that most of the recommended controls are available to all users. Some of the features require paid subscriptions. I don't know specifics of which ones, but it makes me hope we aren't see the rise of a different sort of sso.tax.

I love anything that's security plus protocols. It's a longer read and cool tech, so listen to the episode to find out how much I was able to read and explain between writing this blurb and the time we record.

I'd love to see appsec as an explicit discipline disappear, to be replaced by secure designs in frameworks, secure defaults for new installations, and development tools that provide security feedback.

Deleting code is one of the best secure coding techniques -- it reduces attack surface, it can reduce complexity in an elegant refactor, it can avoid legacy vulns in areas developers are less familiar with.

But it can also be hard to have certainty that a code path is in fact unreachable, so see first-class support for such analysis is encouraging.

We just did a "six months later" segment in episode 265 and now I have a new article to check back in on six months from now.

We'll track what the Cloud Security Alliance is doing on the AI security front and how it might influence orgs building or integrating it.

This is the second article this week that will have to go into another "six months later" category. MITRE won't have a draft until early 2024. They're also getting a little too cute with the constant l33tspeak project names, but our podcast is literally just "Application Security Weekly" so we don't have much of a leg to stand on.

Do we need another scoring system? How much granularity do we need for severity or impact? What's wrong with current scoring systems that this is trying to accomplish? Under what circumstances or use cases are scoring systems even useful?

I have questions. Let's see how many answers we come up with on this episode.

BSidesSF is the local BSides event for me. Their CFP deadline is coming soon -- January 8th.

Check out securitybsides.com to find your local BSides chapter.

Some miscreants managed to phish a former (?) employee of Ledger, maker of USB hardware crypto wallets. Once they had access, they then managed to upload a modified version of their npm library, which when used would "drain" an end user's wallet.

pfsense, an open source firewall powering several popular commercial firewalls, was discovered to have some XSS and a command injection flaw in it's PHP code by Sonar.

From the post...it doesn't sound like much was done besides pointing Sonar's static scanner at the source, so I'm curious why this wasn't found sooner...

Not so much security-focused, but Cling is a interactive interpreter for C++. There has to be some use for this thing...