ASW #202 – Mike Benjamin

Mike Shema

1. OpenSSL issues a bugfix for the previous bugfix
   Last week we covered SynLapse, a flaw in Azure discovered by Orca Security. One of the things that stood out from the SynLapse disclosure timeline was the patch, bypass the patch, patch again cycle that it went through. Here's another example from the OpenSSL project. The OpenSSL toolkit, written in Perl (insert biggest side-eye emoji possible), had a command injection flaw due to shell metacommands. The project fixed the first flaw and, upon further code review, discovered additional attack vectors for the issue. Setting the presence of Perl aside, this practice of searching for all the variants of a reported flaw is something that should be adopted more often. It's a practice where code scanning tools like semgrep or CodeQL that can scan based on semantics of a codebase are most helpful. Check out the changeling at https://www.openssl.org/news/changelog.html#openssl-30
2. OT:ICEFALL – A Decade of Insecure-by-Design Practices in OT
   There's a game we could play called "Guess the tech stack" or "Guess the decade" where we provide a phrase from a security write-up and you have to guess its origin. But when we run into a phrase like "Insecurity by design remains very relevant", there's possibly just too many options to make the game viable... This research on OT security discusses several types of flaws that still plague these systems. It's well-organized report and has observations and recommendations that easily apply to software outside of the OT ecosystem. Unsurprisingly, it touches on supply chain security by pointing out only half of the devices reviewed had an authentication mechanism for firmware updates and barely a quarter of them used cryptographic signing for the firmware. (Check out episode 188 for one example that we've covered.) Setting up trusted builds and creating signed build artifacts falls squarely onto any appsec goal. p.s. bonus points for not putting the PDF report behind a registration wall.
3. NSA, CISA say: Don’t block PowerShell, here’s what to do instead
   Just last week John mentioned that he's used PowerShell when we talked IE11 and Windows platform security. It looks like NSA and CISA are fans of the show (who knows, just go with the joke) and decided to release guidance on why keeping PowerShell enabled is a net positive. Two appsec goals would be to automate system administration as much as possible, whether for patch management or debugging, and remove the need for human access to prod. This article touches on the trade-offs between reducing attack surface with trimmed down images, automation, and command-line access. Read the PDF information sheet at https://media.defense.gov/2022/Jun/22/2003021689/-1/-1/1/CSI_KEEPING_POWERSHELL_SECURITY_MEASURES_TO_USE_AND_EMBRACE_20220622.PDF
4. Top Threats to Cloud Computing Pandemic Eleven
   Our second PDF report of the week is also available without having to register. This is a good trend. The CSA's Threat Working Group has updated their "Top Threat to Cloud Computing" for 2022. Insufficient IAM and secrets handling has moved to the top and misconfigurations of serverless and containerized workloads has made it onto the list. The report uses a format that puts each item into context with recent examples, impact, and takeaways that map to guidance and controls for how to address each one. It's a good reference for defining and prioritizing activities as you build up a cloud security program.
5. News Privacy Technology Twitter apologizes for abusing user security information after $150 million FTC settlement
   In principle, encouraging users to adopt MFA is good. Strong MFA reduces a lot of risk of account takeovers. On the other hand, having to apologize for "using phone numbers or email addresses collected for safety or security purposes for advertising" is both a bad sign and a (maybe?) expensive one. The article indicates this mingling of data for very disparate purposes -- security and advertising -- affected 140 million users. So the settlement is basically $1 per user. It's a lesson in erosion of trust and the viability of purpose-specific data collection.
6. State of Open Source Security 2022
   Snyk has released this year's report on open source security. There are some optimistic bits in there, like an expectation that the OpenSSF investments in security practices and tools will improve open source security over 2022 and 2023. But there's also a lot of remaining headwinds, to steal a euphemism from financial reporting, that show how there's still a diffusion of responsibility (or no responsibility!) for monitoring open source security at organizations, as well as an apparent doubling of the time required to fix vulns in 2021 vs. 2018.

John Kinsella

1. Lessons learned from fuzzing 100+ open source projects
   Some interesting examples of findings resulting from adding over 100 OSS projects to oss-fuzz, along with some thoughts around how to find applicable OSS projects and add them to oss-fuzz. Question to ponder: What OSS packages are you using that you could help get into oss-fuzz? (h/t @clintgibler)
2. Stack Overflow 2022 dev survey
   We love us a good dev survey, and Stack Overflow's never disappoints! A few interesting points - those learning to code are less likely to use aws/azure until they enter the professional world. Docker's the top tool for professional developers. While Heroku is the most commonly used cloud for learning developers, it's one of the most dreaded overall.
3. Using ML to block malware by guessing what it’ll do next
   Interesting bit of research coming out of Cardiff University and Airbus - instead of using algorithms to fingerprint/recognize a file as malware, they're using ML to watch the program as it runs, and infer what it's next actions will be. This seems to be showing very fast results as what a malware does at startup is different than a "normal" program, but we'll see if malware writers start doing "normal" things at startup...
4. Only 3% of OSS bugs are attackable
   This, at least to me, makes sense - either vulnerable code in a library isn't used in your work, or requires a collection of appropriately configured items before the vulnerability can be leveraged