November 2022 Summaries

The Snyk CLI and IDE plugins have been found to contain two medium severity vulnerabilities, CVSSv3 5.8, which can lead to arbitrary code execution on the host system. The first vulnerability, CVE-2022-24441, is related to code injection in the Snyk CLI and Snyk IDE plugins, while the second vulnerability, CVE-2022-22984, is a command injection vulnerability in the Snyk CLI. To mitigate these risks, users are advised to upgrade their plugins to versions with project trust features and follow best practice advice for scanning untrusted code. The vulnerabilities were discovered through a responsible disclosure process by Imperva and do not pose an immediate critical risk, but good hygiene is still recommended. Users can find more information on the Snyk Support portal.

Snyk has expanded its presence in Asia-Pacific with a new datacenter in Sydney, Australia, aiming to support local organizations in securing their applications while complying with regional data residency requirements. The company's developer security platform is now hosted in this new datacenter, providing customers with fast time-to-value, superior uptime and performance, and adherence to leading international standards of data security and privacy. Snyk's expansion in APAC comes as the region experiences rapid growth in cloud adoption and emerging data governance laws and regulations, making data residency a key consideration for organizations. The new deployment option supports local data residency requirements in Australia and Europe, offering customers a secure way to build software while meeting regulatory compliance needs.

Migrating to AWS requires updating traditional security practices to protect data effectively. The top ten considerations for ensuring a smooth and secure transition include approaching AppSec and CloudSec together, embedding security teams with AppDev and DevOps teams, modernizing app development with security across the SDLC, designing cloud architecture with security in mind, empowering developers and cloud engineers to build securely, using infrastructure as code right from the start and securing it, using cloud security guardrails in deployment pipelines, building cloud security on a foundation of policy as code, using identity and access management services securely, and deciding what matters and measuring continuously. By adopting these strategies, companies can successfully transition to AWS while maintaining robust security measures.

GitHub Actions environment variables allow developers to build dynamic workflows by changing the behavior of the workflow based on user-defined variables or default GitHub variables. There are three scopes available for environment variables: workflow, job, and step, which determine the scope of the variable. Environment variables can be defined at each scope using a specific syntax. Contexts are used to access environment variables across different virtual machines. Default variables and GitHub secrets are also available for use in workflows. GitHub secrets encrypt sensitive data, such as passwords and API keys, making them safe to use in workflows. By using these variables and contexts, developers can create secure and dynamic workflows that adapt to changing requirements.

The importance of unit testing in software development cannot be overstated, as it ensures that individual components of the application code behave as expected and catch defects early on. Writing unit tests for Java code can be achieved using various frameworks such as JUnit 5, which provides a comprehensive framework for writing and running unit tests. By installing JUnit 5 and adding it to the Maven project, developers can create test classes that cover different scenarios of their application's code, including edge cases like SQL injection vulnerabilities. The process involves importing required packages, defining test methods using the `@Test` annotation, and verifying the expected output or behavior of the code under testing. This practice adds a layer of defense against breaking core functionality and releasing unstable changes into production applications, making it an essential part of any developer's toolkit.

Setting up SSL/TLS for Kubernetes Ingress is crucial to secure communication between clients and servers, especially when exposing workload containers to the outside world using an HTTP-based Ingress controller. TLS certificates can be self-signed or obtained from public certificate authorities like GlobalSign, Symantec, DigiCert, or GoDaddy. A self-signed certificate is typically used for internal purposes, while public CAs provide trusted root certificates and are ideal for public-internet facing applications. Let's Encrypt offers free SSL/TLS certificates with a validity of three months. To configure TLS/SSL certificates in Kubernetes, you can use Helm to deploy an Ingress controller like NGINX, which provides a straightforward solution for load balancing and protecting cluster workloads. The configuration involves creating a self-signed certificate, linking it to a Kubernetes Secret, publishing a new sample app within the Ingress namespace, and defining an Ingress resource with SSL/TLS parameters. This setup guarantees traffic encryption between clients and servers, ensuring secure communication. The use of different Ingress providers and SSL/TLS certificates is supported by Kubernetes, and the CNCF Cert Manager tool provides a more advanced way to manage certificates and auto-create secrets.

Atlassian used Snyk to detect and remediate Log4Shell, a widespread zero-day vulnerability found within the Log4j Java library. The company built an automation that runs Snyk Open Source scans whenever there are code changes in any repository, filing Jira tickets for security issues and assigning them to developers. After launching a security investigation following the vulnerability's announcement, Atlassian used Snyk to identify vulnerable projects and rescan all of their projects to detect Log4j instances. The company was able to remediate over 1,400 vulnerabilities within 12 hours of the original announcement. Snyk's timely and accurate security intelligence helped many companies detect Log4j in their code bases, even with indirect dependencies. The incident highlights the importance of continuously scanning for vulnerabilities, like Log4Shell, long after a patch is discovered.

Kubernetes Secrets are used to store sensitive data such as OAuth tokens, SSH keys, passwords, and other confidential information, allowing for secure segregation of this data from application code. However, storing secrets in Kubernetes can pose security risks if not managed properly, including exposure through unauthorized access or malicious cyberattacks. To mitigate these risks, best practices for managing Kubernetes Secrets include enabling encryption at rest, configuring role-based access control (RBAC) rules to restrict access, and using a centralized secrets store for easy management. Additionally, leveraging third-party secrets management services such as AWS Secrets Manager, Azure Key Vault, and HashiCorp Vault can provide advanced features for secure storage and rotation of sensitive data. By following these best practices and utilizing the right tools, developers and cluster administrators can keep their Kubernetes Secrets safe and secure.

As a developer, participating in community activities such as open source software projects, presenting at conferences and local meetups, joining or leading community discussions and forums, and sharing expertise can enhance your development career by developing new skills, making contacts with new people, increasing visibility and influence, giving back to the community, and gaining confidence. By contributing to OSS projects, you can work on technologies of interest, develop new skills, make contacts, increase visibility, give back, and provide variety to your work. Presenting at conferences or local meetups allows you to educate others, share knowledge, and gain experience in public speaking, while joining or leading community discussions and forums provides a less intimidating way to get involved, requiring less engagement, time, and public presence.

The Roadrunner challenge from Snyk's 2022 Fetch the Flag competition is an escape room-style puzzle that involves exploiting an input validation vulnerability in a Go code playground. The challenge starts with access to a webpage where users can type and run Go code, which is then executed by a backend service. The goal is to read the contents of a file located at the root directory of the deployed image. The solution involves using a tainted input to exploit the vulnerability in the script sanitization step, which allows the user to capture the flag.txt file. The challenge requires knowledge of Go programming and understanding of the internal workings of the application, but it is solvable with careful construction of the input and some online research.

The challenge Logster at Fetch the Flag CTF 2022 involves exploiting a vulnerable website that uses Apache Log4j version 2, which has a known unauthenticated remote code execution (RCE) vulnerability. The attacker first scans the target website to determine its headers and identifies the programming language used, which is Java in this case. The attacker then creates an Express web server to set custom headers and creates an ngrok tunnel to run the server locally and expose it to the outside world. The attacker uses the Log4Shell vulnerability to inject a custom header with a payload that allows them to scan the website again and eventually retrieve the flag by exploiting another vulnerability in the website's LDAP server.

The Snyk 2022 Fetch the Flag CTF challenge "Pay Attention" involves simulating a case where a popular package has been hijacked and turned malicious, requiring the team to take on the role of a security researcher investigating the issue. The challenge begins with a downloadable file pytest-7.1.3.tar.gz, which seems to be an archive of the latest pytest release but actually contains a suspicious line of code that imports libraries and invokes function calls like b64decode and exec. By observing the code and using Python's built-in functions, such as __import__() and print(), the team is able to decode the base-64 string and eventually find the flag hidden among the declarations of an obfuscated script downloaded from a remote resource. The challenge demonstrates common techniques used in malicious script injections and requires the team to use reverse engineering skills to uncover the hidden flag.

This web-based challenge, `git-refs`, involved using Git commands to access a remote repository and ultimately find a flag hidden in system files. The initial approach focused on exploiting the lack of authentication and analyzing network requests, but this led to a dead end. A change in approach was then taken, where the team used Git configuration options to discover a command that opened an editor, allowing them to modify a configuration file and ultimately find the flag. Throughout the challenge, the importance of input sanitization and understanding Git commands was highlighted.

The Disposable Message challenge at Fetch the Flag 2022 was a CSS injection-based exploit that required exploiting a Content Security Policy (CSP) restriction. The challenge involved using CSS injection techniques to extract information from a web page, specifically the flag value, which was stored in a `data-flag` attribute within an HTML div element. The challenge was made difficult by a strict CSP that prevented direct use of CSS injection techniques. However, by taking advantage of the fact that disposable messages could only be viewed once and using this to check for 404 status codes, it was possible to extract the flag value character by character. The exploit code used Python and involved generating messages with specific CSS selectors that would trigger URLs when values matched certain patterns. The exploit also encoded the query string parameter in its entirety to trick the admin bot into including it in the view message URL. Once the full flag was obtained, it could be extracted and returned as the solution.

The Fetch the Flag CTF 2022 Treasure Trove challenge involved reverse engineering and exploiting a swashbuckle.js endpoint to extract a license key from a website. The challenge required teams to use browser console commands to invoke the `validate` method on the `window` object, which returned an integer that was used to verify the license key. The code used a series of checks to validate the input characters and calculate their sum, before posting it to an API endpoint if the value matched 1800. Teams were able to solve this challenge without engaging with the obfuscator codebase, using browser console commands to bypass the encryption and extract the flag.

The challenge "Not So Smart Fridge" from Fetch the Flag CTF 2022 starts with a warm welcome and a description of the Smart Fridge Ultra SFU-3000, but its actual capabilities are disappointing. The fridge's firmware is pistache/0.0.3.20220107, which has a known path traversal vulnerability. By exploiting this vulnerability, the flag can be accessed through accessing a specific folder path on the fridge's web application, which points to the currently running process, allowing the download of the pistache binary. The binary is then reverse engineered using Ghidra, and an analysis of the decompiled code reveals that the flag is hidden in a method named checkFlag, with a specific length constraint. By analyzing the method's logic and constraints, the flag can be reconstructed.

Snyk has announced the open beta of its revamped security reporting capabilities, providing development and security teams with easy, comprehensive, and granular visibility into risk across their applications. The new features aim to address the need for good visibility in a DevSecOps culture, where all teams are collectively responsible for securing an application. Snyk's revamped reporting provides comprehensive coverage across modern applications' components, enabling role-based data access and providing actionable insights. The feature also includes filtering and sorting capabilities, making it easy to analyze and share security reporting data. Additionally, the new features aim to improve Snyk's commitment to improved data services, with plans for further enhancements in the future.

<|fim_im_start|>` TLS (Transport Layer Security) is a protocol used across the globe to encrypt and secure communication over the internet. TLS and its predecessor SSL are the most commonly used cryptographic protocols for providing encryption, authenticity, and integrity, enabling end-to-end security of data sent between applications over the internet. The importance of TLS lies in protecting against man-in-the-middle attacks, providing integrity protection, authentication, and confidentiality of data exchanged between clients and servers. To implement TLS in Java, developers use the JSSE (Java Secure Socket Extension) framework, which abstracts the underlying implementation of transport layer security protocols, allowing easy implementation of secure encrypted communications between clients and servers. The client-side implementation involves creating a socket using SSLSocketFactory, while the server-side implementation uses SSLServerSocketFactory to initiate the connection.

NPM security is a crucial topic in software development, as it can impact the stability and integrity of applications built using the npm ecosystem. Supply chain attacks, such as dependency confusion attacks, spearheading malicious code backdoors in open source packages, and compromising build pipeline infrastructure, pose an imminent threat to developers. To prevent supply chain attacks, developers can apply software security controls, including preventing NPM lockfile injection, arbitrary command execution, blind NPM package upgrades, dependency confusion, and Trojan source attacks. Proactive measures such as using tools like npq and Snyk Advisor can help detect and prevent security vulnerabilities in npm packages. Additionally, developers can use Snyk's free tooling to scan and monitor for malicious packages and assess open source package health. By understanding NPM security best practices and taking proactive steps, developers can protect themselves against supply chain attacks and ensure the integrity of their applications.

The white paper "Ransomware State of Mind: How to Better Protect Your Business" by Google and Accenture outlines the current state of ransomware, its impact on businesses, and solutions to address this growing problem. Ransomware is a type of malicious software that restricts users' access to important data until a ransom is paid. The report covers various aspects such as social engineering, phishing, remote desktop/terminal protocol (RDP), and software vulnerabilities as common methods for delivering ransomware. The impact of ransomware can be significant, leading to loss of access to data, incident response and mitigation costs, litigation costs, loss of revenue, employee layoffs, brand and reputation damage, and even business closure in some cases. High-profile ransomware attacks include those on Colonial Pipeline, JBS Foods, and CD Projekt. Key learnings from the white paper emphasize that ransomware spreads in phases, making it crucial for companies to implement zero trust security measures. This involves securing trusted perimeters (STPs), using multi-factor authentication (MFA), and implementing single sign-on (SSO). Additionally, protecting in-house apps with secure code review, static application testing (SAST), and software composition analysis (SCA) is essential. Managing infrastructure as code (IaC) with GitOps can also help automate infrastructure security. Automating security policy and testing using tools like Snyk's policy as code engine enables the creation of a unified, consistent single source of truth for policies from code to cloud. Strategies such as ensuring security principles have been applied to all three security layers (PaaS overlay, platform, and foundation), shifting security left using SAST and SCA automation, leveraging a Value Stream Delivery Platform, and testing and validating source code, open source libraries and dependencies, attestations, and deployed artifacts can help minimize the threat of ransomware.

The OpenSSL team recently released an advisory detailing two high-severity vulnerabilities, CVE-2022-3602 and CVE-2022-3786. The more serious issue, CVE-2022-3602, is a remote code execution vulnerability in the ossl_punycode_decode function, which can be exploited by an attacker to write arbitrary bytes outside the bounds of a buffer. However, this bug requires specific conditions to be met and does not seem to be easily exploitable. A single line change in the code fixed the issue, indicating it is an off-by-one error. The vulnerability affects servers running OpenSSL 3, but most services typically use form-based authentication, making client-side attacks unlikely. Organizations can update to OpenSSL 3.0.7 or later by following regular patch and vulnerability management procedures. Tools like Snyk can help identify vulnerable instances of OpenSSL for patching.

A day in the life of a CISO is marked by various challenges, including software supply chain security, DevSecOps, Kubernetes, containers, deployment pipelines, secure software factory reference architecture, security tooling, and software bills of materials. Chris Hughes, CISO of Aquia, has experience with these topics and has worked with organizations like the Cloud Security Alliance and Cloud Native Computing Foundation. He discussed his journey to becoming a cybersecurity CISO, which began in the US Air Force, and emphasized the importance of workforce development, providing cybersecurity training, and empowering people to do the right thing. Hughes also touched on compliance frameworks, risk management, and risk profiling for applications, highlighting the need for organizations like the Linux Foundation and OWASP to provide secure development training. He recommended books on cloud native security and DevSecOps and emphasized the importance of communication and knowledge sharing among developers and security teams.

The OpenSSL team has announced two high-severity vulnerabilities, CVE-2022-3602 and CVE-2022-3786, related to buffer overruns in X.509 certificate verification. These vulnerabilities can be triggered by connecting to a rogue server or by a malicious client joining when the server requests client authentication. Affected versions of OpenSSL 3.0 are vulnerable, and users are advised to upgrade to version 3.0.7 immediately. The vulnerabilities pose a risk of Denial of Service and Remote Code Execution, and organizations should disable TLS client authentication until the upgrade has been applied. Snyk is helping by flagging these vulnerabilities in its Open Source projects and providing guidance on how to address them through its CLI and Container services.

Scaling security teams without hiring more personnel is crucial for companies adopting cloud technology due to a significant gap between job openings and qualified candidates in the cybersecurity industry. The pandemic has accelerated the migration of applications to the cloud, increasing the complexity of security environments. To address this challenge, implementing security process automation based on policy as code can help organizations meet their growing needs without scaling headcount. This approach enables developers to own the security of their cloud environment, sharing responsibility with security teams who serve as domain experts, empowering them to empower developers with tooling based on right policies to check security pre-deployment. Policy as code allows security teams to express security and compliance rules in a programming language that an application can use to check the correctness of configurations, automating manual intervention and ensuring consistency across the software development life cycle. By adopting policy as code, companies can harden their cloud security posture, demonstrate compliance with applicable standards, laws, and regulations, and support multiple business units without slowing them down.

A Ruby on Rails Docker setup provides a local development environment with an isolated database, making it easier to manage dependencies, test, and deploy applications. This setup allows developers to create a new project with a clean environment using Docker Compose, which configures and connects applications and services such as proxies, databases, and volume mounts in a reusable way. The setup includes a Ruby Docker image that builds the necessary layers for the application, and a Rails Docker Compose file that glues all the services together for a functional Ruby on Rails application on Docker. The Makefile is used to create an accessible interface for developers to easily interact with this local development environment for Ruby. This setup can be used for different types of projects, including side-projects or frontend client-side projects, and provides several benefits such as easy configuration, splitting logic from the environment, sharing the environment without sensitive code, and a clean host machine.