In recent years, we’ve witnessed a constant increase in the number of malicious packages showing up in various ecosystems. Generally speaking, the vast majority of these packages are benign, as in, they collect information, but don’t do harm to the infected machine. Once in a while, however, we do encounter a truly malicious package that has a purpose, means, and is production-ready — this is a story about one of them.

In cybersecurity, a vulnerability is a weakness that can be exploited by cybercriminals to gain unauthorized access to a computer system. After exploiting a vulnerability, a cyberattack can run malicious code, install malware and even steal sensitive data. Vulnerabilities can be exploited by a variety of methods including SQL injection, buffer overflows, cross-site scripting (XSS) and open-source exploit kits that look for known vulnerabilities and security weaknesses in web applications.

While most developers — myself included — primarily write in higher-level languages like Python or JavaScript, sometimes you need to add in native elements to improve performance or other project aspects. Since these native extension invocations are typically written in C or C++, suddenly a project primarily using JavaScript or Python must also account for potential C/C++ transient dependencies.

Vulnerability assessments define, identify, classify, and prioritize flaws and vulnerabilities in applications, devices, and networks that can expose organizations, their products, services, code, and applications, to attack. Security vulnerabilities allow malicious actors to exploit an organization’s applications and systems, so it is essential to identify and respond to them before attackers can exploit them.

As the digital world continues to rebuild after the Log4j hurricane, the threat landscape is once again disturbed by the rumbling of an approaching zero-day storm. After barely recovering from a zero-day dubbed as the worst hack ever encountered, concerns are understandably heightened, and as a result, there are many misconceptions about the severity of Spring4Shell.

A few days ago, security researcher Neil Madden published a blog post, in which he provided details about a newly disclosed vulnerability in Java, CVE-2022-21449 or “Psychic Signatures”. This security vulnerability originates in an improper implementation of the ECDSA signature verification algorithm, introduced in Java 15.

This month, Microsoft announced two vulnerabilities in portmap, which is part of ONC RPC, on Windows systems. This blog will discuss Zeek detection packages for CVE-2022-24491 and CVE-2022-24497 developed by Corelight Labs.

Vulnerabilities are software bugs or weaknesses that could be used by an attacker. They could be present in the operating system, application code, and third-party code dependencies, such as libraries, frameworks, programming scripts, and so on. By taking a secure DevOps approach and identifying vulnerabilities early in development, you avoid frustrating developers with delays when an application is ready for production.

You probably know the story of “the boy who cried ‘Wolf!’” In the ancient fable, villagers tire of a shepherd’s false alarms, and stop paying attention to them. That’s a lesson for software security teams, not just schoolchildren. Raising concerns about threats that turn out to be flimsy or false erodes the trust that binds your department, and even the faith your customers have in you.

The U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Agency (CISA) has been quite busy this year. It recently issued a “Shields Up” advisory, highlighting that “Russia’s invasion of Ukraine could impact organizations both within and beyond the region,” including the threat of malicious activity against U.S. interests and companies.

By now, you’re probably all aware of the recent Log4j and Spring Framework vulnerabilities. As a recap, the Log4j vulnerability – made public on December 10, 2021 – was the result of an exploitable logging feature that, if successfully exploited, could allow attackers to perform an RCE (Remote Code Execution) and compromise the affected server.

Snyk Code separates itself from the majority of static code analysis tools by generating and maintaining rule sets for its users — helping them combat common and newly discovered threats. A recent Hub article described a new Javascript vulnerability called prototype pollution, which allows attackers to modify, or “pollute”, a Javascript object prototype and execute a variety of malicious actions.

The migration of assets to the Cloud has been the common denominator in company business strategies over the last two years, coupled with the rising number of incidents involving the theft of sensitive information and user passwords on Cloud platforms. According to the Verizon Data Breach Report 2021, in 2020 29,207 real-time security incidents were detected, out of which 5,258 were confirmed data breaches.

Is your team drowning in container vulnerability noise? Are you spending a lot of time figuring out where to focus resources on and still missing dangerous vulnerabilities? Know that you are not alone. Container environments revolutionized app development by enabling unprecedented velocity, but not without a price. The use of readily available container images of third-party and open-source code enabled much faster cycles, but also facilitated the introduction of vulnerabilities in the application.

Vulnerabilities are everywhere. Vetting, mitigating, and remediating them at scale is exhausting for security practitioners. Let’s keep in mind that no organization has the capacity to find and fix all vulnerabilities. The key is to understand what a vulnerability is, interpret the meanings of the CVSS score, and prioritize and effectively use resources within constrained time limits or delivery windows. Since 2016, new vulnerabilities reported each year have nearly tripled.

A few days ago it was reported that the new Go versions 1.18.1 and 1.17.9 contain fixes for a stack overflow vulnerability in the encoding/pem builtin package, in the Decode function. Given the high popularity of Go among our customers and in the industry at large, this update led us to investigate the vulnerability in previous versions.

As Synk announces its support of unmanaged dependencies (mostly C/C++ libraries), we thought it would be beneficial to introduce our non-C community to some common, high-risk dangers that lurk in the C world (get it?). Think of this as a “beginners guide” to C and C++ vulnerabilities, how they look, what problems they may cause, and how to fix them.

When I look at IT security I can clearly see how it has changed, being today much more mature now than it’s ever been. Governments are working on policies and legislation forcing companies to prioritize IT security. As a result, the entire bug bounty community has bloomed in a way that I could never imagine, security researchers are now working together with companies to identify and mitigate vulnerabilities in a way that we have never done before.

This is the second installment in Trustwave’s in-depth tour of our Security Colony platform. For a broad overview of what Security Colony offers please read 5 Ways CISOs Can Leverage the Power of Trustwave Security Colony. Self-evaluation in any area, much less cybersecurity, can be challenging. Is my performance at work strong and consistent? Am I being friendly to my neighbors?

Over the past week, the WhiteSource security team has found several instances of packages that use unusual techniques to disguise malicious intent. These techniques differ from what we have usually seen in the past, such as base64 and JS obfuscation. This time, we are seeing a malicious actor use hex encoding to hide the malicious behavior of the package.

As a cybersecurity organization, Netskope has a responsibility to be transparent about security issues reported in Netskope products and services which might have an impact on Netskope customers or partners. To fulfill this responsibility, Netskope has a smooth, transparent, and industry-standard process under our Product Security Incident Response Team (PSIRT) to disclose the security issues publicly which are reported in Netskope products from various sources.

A vulnerability scan is an automated process that identifies vulnerabilities (security holes) in any software, operating system, or network that bad actors can exploit. In essence, it’s an integral component of vulnerability management focused on protecting businesses from breaches and the exposure of sensitive data.

In the past, the attack surface was defined and protected by the boundaries of the organization’s physical network (aka the LAN). Using physical security methods, firewalls, and careful monitoring, organizations kept their data, endpoints, and networks secure. The entire attack surface was internal, within a well-defined and fortified perimeter.

Last week, we announced the discovery of Spring4Shell — a remote code execution (RCE) vulnerability in older versions of the spring-beans package. In our blog post Spring4Shell: The zero-day RCE in the Spring Framework explained, we showed how an old Tomcat exploit for CVE-2010-1622 became relevant again. Due to the nature of the problem, we expected that additional payloads could be created beyond this known Tomcat exploit.

Several vulnerabilities for Java Spring framework have been disclosed in the last hours and classified as similar as the vulnerability that caused the Log4Shell incident at the end of 2021. However, as of the publishing of this report, the still ongoing disclosures and events on these vulnerabilities suggest they are not as severe as their predecessor.

Application Programming Interface (API) attacks are set to become one of the most prevalent cyberattacks with a broad target range. By nature, APIs expose application logic and sensitive data such as personally identifiable information (PII), causing APIs to become a target for attackers. In 2019, Gartner predicted that API hacks would become the most common form of cyberattacks in 2022. So how can teams stay ahead of API attacks?

At the end of March 2022, two critical vulnerabilities (CVE-2022-22963 and CVE-2022-22965) were discovered in different components of VMware Spring. Spring is a popular framework focused on facilitating the development of Java applications, including cloud-based apps, eliminating the need for additional code or concerns related to server requirements.

With more than 38 percent of our customers impacted by the recently discovered Spring4 Shell zero-day vulnerability and more than 33 percent of impacted organizations having already remediated (removed) some or all their vulnerable libraries, I have been involved in many conversations over this incident.

Directory traversal vulnerabilities (also known as path traversal vulnerabilities) allow bad actors to gain access to folders that they shouldn’t have access to. In this post, we are going to take a look how directory traversal vulnerabilities work on web servers written on C/C++, as well as how to prevent them.

On March 29, 2022, a critical vulnerability targeting the Spring Java framework was disclosed. This vulnerability was initially confused with a vulnerability in Spring Cloud, CVE-2022-22963. However, it was later identified as a separate vulnerability inside Spring Core, now tracked as CVE-2022-22965 and canonically named Spring4Shell.

“Never click unexpected links!” Ever hear someone yell this? Virtually every person in tech has a healthy suspicion of random links; it is for a good reason. Every now and then there are huge leaks from industry leaders as a result of a targeted campaign. One of the most reliable ways to “phish” someone, or exfiltrate their credentials, is to abuse an open redirect vulnerability in a safe-looking website and redirect the victims to a malicious one.

On Thursday, March 31st a patch for a widely used Java framework called the Spring Framework was given the designation CVE-2022-22965 with a CVSS Score of 9.8. That’s bad news for a lot of companies that make use of this framework for delivery of their web applications, services and APIs. This is a remote code execution (RCE) vulnerability and the ease of exploitation is partly why it has earned a 9.8 out of 10 on the CVSS Score.

On March 29, 2022, details of a zero-day vulnerability in Spring Framework (CVE-2022-22965) were leaked. For many, this is reminiscent of the zero-day vulnerability in Log4j (CVE-2021-44228) back in December 2021.

A critical remote code execution (RCE) vulnerability was identified March 30th, 2022 for the Spring Framework. Spring core, used by millions of systems to develop Java web applications quickly, is one of the Java world’s most popular open source Java frameworks. The RCE vulnerability, if successfully exploited could potentially allow an attacker to take control of a vulnerable system.

Our security researchers, engineers, and our Crowdsource community are actively working on understanding the vulnerabilities and developing tests. We have received a dozen POCs already and anticipate more over the coming days. While the situation is rapidly developing, here is what we know so far. The Spring Cloud Function vulnerability (CVE-2022-22963) was disclosed and patched earlier this week.

On Wednesday 30th March 2022, news was disclosed online about an unauthenticated RCE zero-day vulnerability in Spring Core, a framework for building modern Java-based enterprise applications.