- 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.