The DIY Lab – ASW #185

We've covered a handful of articles from the JFrog’s Security Research team by now. While Cassandra might not be a datastore du jour (it's been a long time since I've come across it), this is a nice write up that offers up some chances to go on a tangent or two. Part of the article covers some well-known insecure configurations and capabilities. The article even notes, "These options are documented to be insecure...” and adds extra caution about them so they're not deployed in a "publicly accessible network". It's good that the default isn't insecure -- you have to go out of your way to enable these features. So, at least we're seeing a world of default (sort of?) secure without the need for a hundred-page hardening guide. The admonition about a publicly accessible network is a good one -- but is it enough? We keep running into supply chain stories every month and there's added focus on hardening CI/CD pipelines, so it's probably a good idea to further refine that caution to only deploy such systems where it must be accessed with strong authentication and authorization (or, really, not at all for known insecure capabilities...).

This is the kind of topic that we highlight more for the fun topic and to exercise threat-minded thinking. A DevOps team might run into the need for redacting sensitive info from log files (think of session cookies, passwords, personal information), but they won't be pixelating it. Here's a grab bag of links related to redaction: - http://www.cse.lehigh.edu/~lopresti/Publications/2004/hdp04a.pdf - https://hovav.net/ucsd/dist/redaction.pdf - https://www.science.org/doi/10.1126/sciadv.abg4266 - https://cdn.nationalarchives.gov.uk/documents/information-management/redaction_toolkit.pdf

This gets notice this week not because of log4j, but because just last episode we covered a different use of AI for analyzing the security of protocols. It's nice to see more examples of AI that aren't just fancy regexes.

We've been talking more and more about languages like Go and Rust in the last few weeks, primarily because they can avoid whole classes of memory safety issues that have plagued C and C++. This article is a pretty quick summary of a survey of Rust developers. What caught my eye was where the overwhelming positive feedback landed -- "...compiler error messages received the most praise, with 90% approval of their current state." Compiler warnings are one of the best tools for maintaining code quality and, incidentally, avoiding common security mistakes. But they can also be inscrutable or written more from the perspective of communicating compiler internals rather than best serving developers with clear, concise messages. As someone who has done a fair bit of template programming (plus lots of boost::spirit), I've seen plenty of degenerate cases of pages-long errors. This focus by the Rust community is great to see.

Just a tweet thread for this one -- no companion blog or other writeup. But it's a great story told simply and briefly, with lessons on product security that encompasses technical, process, and monitoring issues. It's a reminder that not only do you need code that's secure from injection-style attacks, but code whose workflows are well understood and have considered a broad set of threat scenarios. Then on top of that you need systems whose alerting mechanisms work when you most need them, especially in the face of malicious actors.

We'll try not to mention "Super Duper Secure Mode" when talking about this article, but this is another step in Microsoft's efforts to make Edge more secure. In this case, they've hardened the WASM interpreter to protect against memory from being marked as executable and consequently used as part of an exploit chain. This is a great step towards keeping the WASM sandbox a more secure sandbox and addressing a technique often used by exploit developers. Check out the doc that describes DrumBrake at https://docs.google.com/document/d/1OIJ4Sv2XfTlI5NmTS1QI8v8wPL0LUT5s1W2D9OlJmMc/preview#heading=h.2hff7nffvheq Find out more about the arbitrary code guard at https://docs.microsoft.com/en-us/microsoft-365/security/defender-endpoint/exploit-protection-reference?view=o365-worldwide#arbitrary-code-guard

A quick -- and welcome -- update on a situation we talked about when it first came up. A journalist essentially clicked "view source" for a state website, saw that the personal info (like SSNs) redacted on the page were available in full within the source, reported it to the site to fix, and promptly received threats of prosecution. It's like a throwback to website hacking situations from the 90s and not something anyone, let alone a journalist, should have to experience in the modern era of bug bounties and coordinated vulnerability disclosure.