In late 2021, the Apache Software Foundation disclosed a vulnerability that set off a panic across the global tech industry. The bug, known as Log4Shell, was found in the ubiquitous open-source logging library Log4j, and it exposed a huge swath of applications and services.
Nearly anything from popular consumer and enterprise platforms to critical infrastructure and IoT devices was exposed. Over 35,000 Java packages were impacted by Log4j vulnerabilities. That’s over 8% of the Maven Central repository, the world’s largest Java package repository.
When Log4j was discovered, CISA Director Jen Easterly said, “This vulnerability is one of the most serious that I’ve seen in my entire career, if not the most serious.”
Since Log4j surfaced, how has the security community responded? What lessons have we learned (or not learned)?
Log4Shell is no longer a massive, widespread danger. Still, researchers warn that the vulnerability is still present in far too many systems. And actors will continue to exploit it for years to come.
Log4Shell was unusual because it was so easy to exploit wherever it was present. Developers use logging utilities to record operations in applications. To exploit Log4Shell, all an attacker has to do is get the system to log a special string of code. From there, they can take control of their victim to install malware or launch other attacks.
“Logging is fundamental to essentially any computer software or hardware operation. Whether it’s a phlebotomy machine or an application server, logging is going to be present,” said David Nalley, president of the nonprofit Apache Software Foundation, in an interview with Wired. “We knew Log4j was widely deployed, we saw the download numbers, but it’s hard to fully grasp since in open source you’re not selling a product and tracking contracts. I don’t think you fully appreciate it until you have a full accounting of where software is, everything it’s doing and who’s using it. And I think the fact that it was so incredibly ubiquitous was a factor in everyone reacting so immediately. It’s a little humbling, frankly.”
According to Nalley, they had software fixes out within two weeks. Alarmingly, Apache still sees up to 25% of downloads involving non-patched versions of Log4j.
Threat actors continue to exploit the Log4j vulnerability to this day. CISA has released alerts regarding Iranian and Chinese actors using the exploit. From Iran, cyber threat actors took advantage of the Log4Shell vulnerability in an unpatched VMware Horizon server, installed crypto mining software, moved laterally to the domain controller, compromised credentials and implanted reverse proxies on several hosts to maintain persistence. Meanwhile, the top Common Vulnerabilities and Exposures (CVEs) most used by Chinese state-sponsored cyber actors since 2020 is Log4j.
Given the danger and ongoing threat, why do so many vulnerable versions of Log4j still persist? Could it be that some IT pros don’t really know what’s in their software?
The problem isn’t software vulnerability alone. It’s also not knowing if you have vulnerable code hiding your applications. Surprisingly, many security and IT professionals have no idea whether Log4j is part of their software supply chain. Or even worse, they choose to ignore the danger.
Part of the challenge is due to the rise of open-source software (OSS). Coders leverage OSS to accelerate development, cut costs and reduce time to market. Easy access to open-source frameworks and libraries takes the place of writing custom code or buying proprietary software. And while many applications get built quickly, the exact contents might not be known.
In a Linux Foundation SBOM and Cybersecurity Readiness report, 98% of organizations surveyed use open-source software. Due to the explosion of OSS use, it’s clear that supply chain cybersecurity may be impossible to gauge for any given application. If you don’t know what’s in your supply chain, how can you possibly know it’s secure?
The threat of vulnerabilities (both known and zero-day) combined with the unknown contents of software packages has led security regulators and decision-makers to push for the development of software bills of materials.
According to CISA:
A “software bill of materials” (SBOM) has emerged as a key building block in software security and software supply chain risk management. An SBOM is a nested inventory, a list of ingredients that make up software components.
If you have a detailed list of individual software components, you can assess risk exposure more accurately. Also, with a well-developed SBOM, you can match your list against CISA’s Known Exploited Vulnerabilities Catalog. Or, if you hear about an emerging mass exploit like Log4j, you can quickly confirm if your stack is at risk. If you don’t have an SBOM, you’re in the dark until you are notified by your vendor or until you get hacked.
If you were to scan your systems for software vulnerabilities, you might discover hundreds of thousands of weaknesses. Also, if you merged with another company recently, you inherit their risk burden as well. For larger enterprises, detected vulnerabilities can number in the millions.
Trying to patch everything at once would be impossible. Instead, proper triage is essential. For example, vulnerabilities nearest to mission-critical systems should be prioritized. Also, an organization should audit, monitor and test its software vulnerability profile often. And since IT teams might add applications at any moment, an up-to-date network inventory and scheduled vulnerability scanning are critical. Automated software vulnerability management programs can be a great help here.
Many companies don’t have the time or qualified resources to identify, prioritize and remediate vulnerabilities. The process can be overwhelming. Given the high risk involved, some organizations opt to hire expert vulnerability mitigation services.
While Log4j sent some into a frenzy, others didn’t even seem to notice. This gives rise to the debate about cyber responsibility. If my partner hasn’t patched a vulnerability, and it affects my operations, should my partner be held responsible?
In one survey, 87% of respondents said that given the level of cyber risk posed by Log4j, government regulatory agencies (such as the U.S. Federal Trade Commission) should take legal action against organizations that fail to patch the flaw.
Only time will tell how far the security community will take responsibility for vulnerabilities — whether by being proactive or by force.
The post Log4j Forever Changed What (Some) Cyber Pros Think About OSS appeared first on Security Intelligence.
Log4Shell is a critical vulnerability with the highest possible CVSSv3 score of 10.0 that affects thousands of products running Apache Log4j and leaves millions of targets potentially vulnerable. CVE-2021-44228 affects log4j versions 2.0-beta9 to 2.14.1. Log4j is an incredibly popular logging library used in many different products and various Apache frameworks like Struts2, Kafka, and [...]
The post Log4Shell VMware vCenter Server (CVE-2021-44228) appeared first on Hacking Tutorials.
With the anniversary of Log4j looming, it is a good time to reflect on the wider significance of the vulnerability that had security teams scrambling in December 2021. What can the response to the flaw in a widely used Apache Software Foundation logging tool tell us about the state of global IT security? Most importantly, how should we respond to similar vulnerabilities that are bound to emerge in the future?
The reason for the heightened concern surrounding Log4j stemmed not only from the scale of the exposure, but also the difficulty in quantifying that exposure. People knew or suspected they were using Log4j but did not necessarily know to what extent and on which devices. It’s like a fire alarm going off: You suddenly know you may have a problem, but you don’t know exactly how big a problem or where in the house it might be.
Log4j also speaks to the well-documented challenge of relying on open source software. We cannot live without it, but in doing so we introduce dependency and risk in ways we had not always anticipated or prepared for. Events like Log4j won’t deter organizations from using open source software. The cost and pain of building tech stacks from scratch is simply too great for the vast majority of organizations.
Much of the media coverage of Log4j highlighted the panicked response. Security teams reacted swiftly and decisively as they sought to contain the risk, with much of the work happening over the festive holiday period to the chagrin of those affected.
That was the right course of action, but it is unsustainable to react in crisis mode all the time. This will burn out your hard-working security team, not least the experts on your networks and systems—key people you don’t want to lose. Vulnerabilities like Log4j are a fact of life, so a different pattern of response is needed. One that allows business operations to continue and risk to be continuously managed.
That calls for first understanding the information security risks you are trying to manage. It sounds obvious, but can you articulate this for your organization? Does your leadership fully understand? Is this something you review with your board periodically? Your security response should flow from a set of priorities articulated by your experts and endorsed by your leadership, or else you are destined for infosec busywork rather than purposeful risk management.
It follows closely that you also need to understand your assets. What data, information and systems do you have? How do you rely on them and what happens if they go away?
With these foundations in place, you can start to build what you need to take all sorts of security challenges in stride, including the next Log4j, whatever that may be.
Training is a key aspect of a measured response. Your whole organization should be trained on the basics of cybersecurity and how to improve cyber hygiene. The security, engineering and infrastructure teams need a plan of action to manage your organization’s response to a new, major vulnerability. Plan your incident response and consider simulating how you would respond as part of a table-top exercise. Revisit this plan from time to time—don’t let it gather dust in a ring-binder in an office no one goes to any more!
These suggestions aren’t easy to implement, but they’re an investment in the longevity of your organization and your security teams. Synack can help augment your security team’s efforts by leading one-off missions to assess assets, going through security checklists or performing continuous pentesting on your entire organization. Contact us to learn more.
The post Battling the Next Log4j: How to Prepare Your Security Team While Avoiding Burnout appeared first on Synack.
When the Log4j vulnerability emerged in December 2021, Synack and our clients’ security teams immediately sensed its urgency. The Synack Red Team began testing within hours of the initial discovery for our customer base.
Almost a year later, Log4j continues to show up in our pentesting results. Here are some quick stats from our findings:
The Cyber Safety Review Board (CSRB) called Log4j (CVE-2021-44228) an “endemic” vulnerability in the board’s first published report. The group of public and private sector cybersecurity leaders stated that the vulnerability is expected to continue to be a prominent threat for “a decade or longer.”
The CSRB’s consideration of Log4j as a persistent threat points to the critical nature of such zero days. They are not something to be solved in the week they appear, with security teams “working through the weekend” and then moving on. They highlight the larger need for readily available talent and emergency response processes across a longer span of time.
Luckily, there have been no successful Log4j-based attacks to critical infrastructure, according to the CSRB. However, the board urges organizations to continue to mitigate risk related to Log4j and prepare for future zero day vulnerabilities of similar criticality.
Nearly two in three organizations say they are understaffed in cybersecurity. But even for those that report having enough cyber talent on hand, the surge demand needed to respond to a vulnerability like Log4j can still be taxing. The CSRB report states:
“Perhaps most significantly, the force exerted on the urgent response and the challenges in managing risk also contributed to professional “burnout” among defenders that may, compounded with the generally intense pace of many cybersecurity jobs, have a long-term impact on the availability of cybersecurity talent.”
Chris Hallenbeck writes for VentureBeat about lessons learned in the face of Log4j, including the fact that the “skills shortage is an existential threat.” If organizations are to effectively prepare for future CVEs and zero days, they must consider their hiring strategies in the face of the cyber talent shortage, while also considering how to deal with potential burnout and stress from surge demand in the face of emergency.
The CSRB issued recommendations to mitigate zero day risks, including the documentation of a vulnerability management and response program, and consideration of “cultural shifts” that are “necessary to solve for the nation’s digital security.”
Synack believes that the most effective way to test for a zero day vulnerability is with human expertise. Scanners are not able to detect zero day vulnerabilities until they are updated with a signature for the vulnerability.
In the face of the cybersecurity talent gap, testing with humans to meet the surge demand of a zero day can be challenging. That’s why on-demand access to a community of researchers is paramount. Synack provides access to such a community, the Synack Red Team, through a SaaS platform, for on-demand zero day response. This talent augmentation can be a key cultural shift for companies struggling to hire or retain cyber talent, and can help prevent an in-house team from experiencing the severe burnout alluded to above.
Within the Synack Platform is a catalog of CVEs that can be tested on-demand by skilled SRT researchers. When Log4j first emerged, it was added to the catalog within hours, and top researchers began testing and collaborating on methodologies.
After only a few days, Synack had checked over half a million IP addresses confirming the status of thousands of CVE-2021-44228 checks and providing detailed reports containing proof of work and methodologies.
Contact us today for a conversation about how we can help you mitigate Log4j risk or prepare for future zero days.
The post Preparing for the Next Log4j in the Face of the Cyber Talent Gap appeared first on Synack.
Wade Lance is the Field CISO for Synack.
Picture this: You’re seated at a dinner table surrounded by a dozen security leaders. Appetizers are on the way, and the conversation starts to pick up. Your neighbor says something about the Russia-Ukraine conflict, while across the table, a few CISOs engage in a lively discussion about something they read in the Wall Street Journal.
As field CISO for Synack, I’ve attended many such dinners with executives from a range of industries. The events offer a venue to speak frankly about security wins and challenges. Each CISO I’ve met on the road has brought unique perspectives on their most pressing cybersecurity concerns. Without naming any names, here are four themes I picked up on:
Disaster readiness is urgently needed. To say Log4j was a wakeup call would be an understatement. Many CISOs were left scrambling to find on-demand expertise needed to respond to the open source vulnerability that seemed to be everywhere when it first appeared in the news last December. They lacked surge capacity to meet their cybersecurity needs at a critical time, as nation-state threats started exploiting Log4j before their own overworked teams could find and fix it. One idea is to have a relationship with a Pentesting as a Service (PTaaS) partner so that surge capacity is immediately available in the same model that most organizations have with Incident Response partners.
Continuous penetration testing is great (on paper). Wouldn’t it be nice to have someone watching your back, ready to spring into action and find vulnerabilities at the drop of a hat? Sure, but is continuous pentesting really possible, let alone affordable? Getting to a place where top security researchers are constantly assessing their networks can seem like a mirage for organizations struggling to find cyber talent to fill 9-to-5 roles. But continuous development requires a new approach to security testing, so security leaders are looking at their options.
Auditors can be as motivating as malicious hackers. In 2022, it’s a truism that compliance does not equal security. CISOs understand that divide, but that doesn’t make it any easier to navigate. They need to keep auditors happy and keep hackers at bay if they want to stay off the front page of the Wall Street Journal as the next victim of a major hack. That means scaling security teams to juggle both shifting regulatory requirements and constantly evolving cyberthreats. Easier said than done.
Ditch the swag. OK, I’ll admit this one hurt a bit to hear. I love a YETI tumbler as much as the next security pro. But I also understand why CISOs–who know what’s at stake in our cyberthreat landscape–aren’t itching to wear branded socks or apply a Synack patch to their suits. This is a serious business!
…
By the time I steer the conversation back to Synack, I’ve heard fascinating and sometimes provocative viewpoints from the people on the front lines of security leadership. (At one dinner, I was flabbergasted when I heard an executive claim, “We’ve never had any breaches and don’t really consider ourselves a target.”)
Here’s what Synack brings to the table:
To find out more, you can contact us to schedule a demo here. Or maybe I’ll catch you around the dinner table on my next trip!
The post Overheard at the CISO Table: 4 Takeaways From Dinner Discussions appeared first on Synack.
Since Friday, December 10, 2021, researchers from the Synack Red Team (SRT) have been solving customer needs related to CVE-2021-44228—the CVE that details a critical log4j vulnerability with wide-reaching implications across industries.
Responding to the Critical Vulnerability with Synack Testing
By 8 A.M. PST, when its magnitude and implications became clear to Synack operations, a new CVE entry was created in the Synack Platform to address CVE-2021-44228. Log4j immediately became available for customers to launch, long before most of the world read about the vulnerability in headlines and social feeds.
Synack CVE Checks connect an organization to SRT researchers capable of accomplishing specific security tasks. In this case, organizations can select CVE-2021-44228 within the Synack Platform and have a researcher check for the vulnerability on-demand.
Testing with the Best Researchers on the Planet
Over 30 SRT members assembled to cultivate ideas and improve the entire community’s efficiency and effectiveness. Together, they are bringing a diverse spectrum of perspectives from different backgrounds, ranging from military and government to academia and tech. This collaboration of top researchers allows Synack to improve the quality of testing for all customers with better processes, tools, and payloads.
The SRT often shares best practices within the community to help each other level up and make the entire internet safer. Compared to traditional testers or automated scanning tools, the SRT brings these sorts of advantages: human collaboration, diversity and creativity.
The Landscape of CVE-2021-44228 Across Industries
Since Friday morning, Synack has checked over half a million IP addresses across our customer base, confirming the status of thousands of CVE-2021-44228 checks and providing detailed reports containing proof of work and methodologies. With a combination of human intelligence and automated tools, Synack is addressing the vulnerability at an unprecedented scale and pace.
Vulnerable instances span across countries and industries and exist both in the government and private sectors. The urgency of the vulnerability has not been overstated by news outlets and social media – Synack recommends that customers activate the CVE check as soon as possible.
Checking for CVE 2021-44228 On-Demand—The Advantages of Synack Campaigns
Since the weekend that followed the CVE’s publication, Synack customers have utilized the Synack Platform to activate hundreds of checks from researchers around the world.
Synack beats other models to the punch. Scanners do not yet have the vulnerability’s signature, traditional pentesting engagements take significant time to spin up, and other bug bounty models do not provide the immediacy or certainty of a vulnerability as this one requires. The model provides on-demand services relevant to CVEs today and prepares organizations for the next 0day like CVE-2021-44228. Reach out to a Synack representative today to explore existing CVE checks, as well as other offerings available in the Synack Catalog.
The CVE-2021-44228 testing provided by Synack provides immediate results and reporting. The researcher will provide a clear yes/no answer on an asset’s vulnerability status, as well as details about their methodology, screenshots, and general proof of work.
Activate the Synack CVE-2021-44228 Test Today
Reach out to your Synack representative to activate the CVE-2021-44228 test today. If you’re new to the Synack Platform, reach out to us here and learn how to get started with Synack’s on-demand security platform and pentesting.
Update: Synack was asked whether our systems are vulnerable to Log4j. Synack does not use Log4j and has determined that we are not vulnerable to exploitation. In response to increased attack traffic attempting to exploit the vulnerability, we have taken additional steps to block the malicious traffic accordingly.
The post Providing On-Demand Testing for CVE-2021-44228 (Log4j) with Synack Testing appeared first on Synack.
Login