asw185

Application Security Weekly Episode #185 – February 18, 2022

Subscribe to all of our shows and mailing list by visiting: https://securityweekly.com/subscribe

1. The DIY AppSec Lab – 01:00 PM-01:30 PM

Announcements

  • Do you have a specific guest or topic that you want us to cover on one of the shows? Submit your suggestions for guests by visiting https://securityweekly.com/guests and completing the form! We review suggestions monthly and will reach out to you once reviewed!

  • We have a couple webcasts coming up soon. First, join us March 2nd to learn five things you can do to catch more bad guys! Live attendees will have the chance to win a $100 gift card to Hacker Warehouse. Then join us March 10th for an intro to KQL queries! To register for these webcasts visit https://securityweekly.com/webcasts. Don’t forget to check out our library of on-demand webcasts & technical trainings at https://securityweekly.com/ondemand.

Description

Lots of web hacking can be done directly from the browser. Throw in a proxy like Burp plus the browser’s developer tools window and you’ve got a nearly complete toolkit.

But nearly complete means there’s still room for improvement. We’ll talk about the tools to keep on hand, setting up practice targets, participating in bug bounties, and more resources to help you learn along the way.

For tips on labs beyond just appsec, be sure to check out the Security Weekly webcast on “Do It Yourself: Building a Security Lab At Home” at https://securityweekly.com/webcasts/do-it-yourself-building-a-security-lab-at-home/

Segment resources:
https://www.darkreading.com/careers-and-people/want-to-be-an-ethical-hacker-here-s-where-to-begin
https://github.com/AdminTurnedDevOps/DevOps-The-Hard-Way-AWS
https://owasp.org/www-project-juice-shop/
https://owasp.org/www-project-vulnerable-web-applications-directory/
https://portswigger.net/web-security
https://azeria-labs.com/writing-arm-assembly-part-1/
https://twitter.com/0xAs1F/status/1480604655952433155

Hosts

JohnKinsella

John Kinsella

@johnlkinsella

Co-founder & CTO at Cysense

MikeShema

Mike Shema

@Codexatron

Security Partner at Square

2. Cassandra RCE, Pixelation Is Poor Redaction, Rust’s Useful Errors, & Hardening Edge – 01:30 PM-02:00 PM

Announcements

  • Don’t miss any of your favorite Security Weekly content! Visit https://securityweekly.com/subscribe to subscribe to any of our podcast feeds and have all new episodes downloaded right to your phone! You can also join our mailing list, Discord server, and follow us on social media & our streaming platforms!

Description

This week in the Application Security News: RCE in Cassandra, why pixelization isn’t good redaction, Rust’s compiler is friendly, Edge adds arbitrary code guard to its WASM interpreter, & the difference between secure code and a secure product (as demonstrated by a DAO)

Hosts

JohnKinsella

John Kinsella

@johnlkinsella

Co-founder & CTO at Cysense

  1. DIY home systems vulnerable to hacking
  2. NIST releases software, IoT, and consumer cybersecurity labeling guidance
  3. Intel’s plan to license x86 cores for chips with Arm, RISC-V and more inside
MikeShema

Mike Shema

@Codexatron

Security Partner at Square

  1. CVE-2021-44521 – Exploiting Apache Cassandra User-Defined Functions for Remote Code Execution – 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…).

  2. Never, Ever, Ever Use Pixelation for Redacting Text – 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

  3. AWS’s AI code reviewer now spots Log4Shell-like bugs in Java and Python code – 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.
  4. Rust Survey 2021 Results – 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.

  5. Tweet thread on a “hostile governance takeover” of a DAO – 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.
  6. Introducing Enhanced Security for Microsoft Edge – 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

  7. Missouri will not prosecute ‘hacker’ reporter for daring to view state website HTML – 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.