I originally planned to write this story as a follow-up to another blog that SURGe released for CVE-2022-3602 and CVE-2022-3786 (aka SpookySSL). That blog mentions that we weren’t able to test with any malicious payloads yet, and as things go… After releasing that blog, we came across proof-of-concept exploits that weren’t detected by our searches.
Kubernetes uses secret objects, called Secrets, to store OAuth tokens, secure shell (SSH) keys, passwords, and other secret data. Kubernetes Secrets allow us to keep confidential data separate from our application code by creating it separately from pods. This segregation, along with well-formed role-based access control (RBAC) configuration, reduces the chances of the Secret being exposed — and potentially exploited — when interacting with pods, thereby increasing security.
Snyk recently launched a multi-day live hack series with AWS, where experts demonstrated exploits in real-time and explained how to defend against those vulnerabilities. This series helped viewers discover new ways to improve security across the application stack for AWS workloads. As part of the series, Micah Silverman (Director of Developer Relations, Snyk) and Chris Walz (Senior Security Engineer, Atlassian) discussed Log4Shell.
Similarly to our previous research on “Secrets Detection,” during the development and testing of JFrog Xray’s new “Contextual Analysis” feature, we wanted to test our detection in a large-scale real-world use case, both for eliminating bugs and testing the real-world viability of our current solution.
Recently, I met with Or Weis — a Snyk Ambassador — to discuss access control in the cloud. Or is an entrepreneur, based in Tel Aviv, where he founded Permit.io, a solution that empowers developers to bake in permissions and access control into any product in minutes and takes away the pain of constantly rebuilding them.
You didn’t change anything in your code, yet the scan is different this time. Here’s advice from an Application Security Consultant on why that may be. Have you ever wondered why you scan code one day and get one result, and then scan the same code a month later and get different results – even though you never changed anything?
Fortinet’s newest vulnerability, CVE-2022-40684, allowing for authentication bypass to manipulate admin SSH keys, unauthorized downloading of configuration files, and creating of super admin accounts, has put a big target on the backs of unpatched and exposed Fortinet devices.
