The toasts, triumphs, and biggest security wins of the year

The toasts, triumphs, and biggest security wins of the year

  

As 2022 draws to a close, The Daily Swig is revisiting some of the year’s most notable web security wins and egregious infosec fails.

Yesterday we showcased the year’s biggest fails – the security disasters, industry calamities, and the emergence of vulnerabilities so stupid they’ll make your eyes roll.

Today, we’re celebrating the times that organizations, governments, and the infosec community have shown laudable skill, judgement, and commitment to better securing the cyber sphere in 2022.

**CCFA changes**

This year saw major progress made in protecting ethical hacking from unfair legal consequences. Current laws worldwide often enable prosecution of security researchers motivated to protect rather than harm users, creating risks for ethical hackers in the course of doing their job.

In the US, the Department of Justice (DoJ) announced it will no longer prosecute security researchers who act in “good faith” under a landmark revision to its policy regarding computer crime laws.

The amendment, announced back in May, laid out changes to prosecution criteria under the Computer Fraud and Abuse Act (CFAA).

Good faith in this case refers to an individual accessing a computer solely for purposes of good-faith testing, investigation, or correction of a security flaw or vulnerability.

RELATED Stupid security 2022 – this year’s infosec fails

**Decriminalizing UK ethical hackers**

Across the pond, UK legislators proposed an amendment to the Product Security and Telecommunications Infrastructure (PSTI) bill back in June that would give cybersecurity professionals a legal defence for their activities under the Computer Misuse Act (CMA).

Critics argue that the law, which came into effect in 1990, is outdated and unduly prosecutes security researchers, ethical hackers, and pen testers who responsibly hunt for or report vulnerabilities.

Campaigners continue to call for legal clarification of legitimate hacking activities, which they argue include responsible vulnerability research and disclosure, proportionate threat intelligence, best practice internet scanning, enumeration, use of open directory listings, and honeypots.

The UK government continues to hold talks on the proposed law changes. A call for information was closed in September.

**Making disclosure smoother**

Progress was also made in helping security researchers to make the vulnerability disclosure process smoother.

HackerOne encouraged customers to adopt its new standard policy, released in November, that goes further to protect hackers from legal problems.

The Gold Standard Safe Harbour agreement “is a short, broad, easily-understood safe harbor statement that’s simple for customers to adopt”, said HackerOne.

“This standardization also reduces the burden on hackers for parsing numerous different program statements.”

Catch up on the latest bug bounty news

Meanwhile, the maintainers of open source repositories can now receive private vulnerability reports, remediate them, and issue CVEs via GitHub, the Microsoft-owned software development platform announced at the GitHub Universe conference in November.

The news went down well with at least one infosec pro, with vulnerability researcher and The Daily Swig interviewee Alex Chapman calling it an “amazing feature”.

**In defence of Ukraine**

The Russian invasion of Ukraine dominated headlines this year, and as individuals across the world stepped up to help, so did the hacking community.

In March, Hackers Without Borders (HWB) a Geneva-based non-governmental organization (NGO), was launched to offer emergency infosec assistance to other NGOs and providers of critical services affected by conflicts around the world.

Staffed by volunteer hackers and infosec experts, the organization helps individuals or organizations handle the fallout of cyber-attacks, protect them from further assaults, and bolster their cyber-resilience – free of charge.

In an interview with The Daily Swig, co-founder Florent Curtet said: “We are here to be like firefighters for people, companies, institutions that don’t have the money, skills, or information to protect themselves from today’s digital threats.”

Also speaking in defence of Ukraine, WithSecure’s Mikko Hyppönen told the cybersecurity company’s first ever conference attendees this year that “Russia is trying, but it is largely failing”, in its efforts to ignite cyberwarfare.

Speaking at Sphere 2022 in neighbouring Finland, Hyppönen said: “Taking a stand here is really simple, it’s really obvious. I think we all choose to stand with Ukraine. We choose to stand with democracy, and we choose to stand against evil.”

**Back to Hacker Summer Camp**

This year saw the return of in-person conferences, in particular Black Hat, which was held online in previous years due to the coronavirus pandemic.

In May, Black Hat Asia attendees in Singapore heard keynote speaker Samir Aran warn that “if democracy is to survive, technology will have to be tamed”.

At Black Hat USA, held in Las Vegas in August, former CISA director Chris Krebs also spoke out about geopolitical tensions, urging organizations worldwide to bolster their online infrastructure amid Taiwan tensions.

And at Black Hat Europe, held in London in November, renowned security researcher Daniel Cuthbert told attendees that a defendable internet is possible – “but only with industry makeover”.

The conferences also saw the release of various hacking tools built by the community for the community.

**Securing the open source ecosystem**

Finally, efforts to secure the open source supply chain were ramped up for 2022, with a number of new initiatives launched.

The Secure Open Source Rewards (SOS.dev) scheme was set up to reward developers and security researchers who make improvements to critical infrastructure based on open source technology.

The program will “harden critical open source projects” and help protect against application and software supply chain attacks by encouraging researchers and developers to suggest security improvements.

Rewards range from $505 for small improvements up to $10,000 or more for “complicated, high-impact and lasting improvements that almost certainly prevent major vulnerabilities”.

The Open Source Security Foundation (OpenSSF) also launched a project to improve the security of the open source software ecosystem, backed by a $5 million investment from Microsoft and Google.

And a summit held at the White House resulted in a plan to better secure the government’s software supply chain, in the wake of the Log4j incident back in 2021.

DON’T MISS Lean, green coding machine: How sustainable computing drive can reduce attack surfaces

Security done right – infosec wins of 2022

Epic web security fails and salutary lessons from another inevitably eventful year in infosec

Epic web security fails and salutary lessons from another inevitably eventful year in infosec

  

As 2022 draws to a close, The Daily Swig is revisiting some of the year’s most notable web security wins and egregious infosec fails.

Tomorrow we’ll publish some examples of the year’s cybersecurity successes, but today we’re kicking off with some amusing vulnerabilities, security disasters, and ‘must do better’ scorecards.

**Reddit NSFW bypass**

Reddit’s ‘Not safe for work’ restrictions could have been subverted via a cross-site request forgery (CSRF) vulnerability addressed by the social media platform in February.

The security bug enabled attackers to trick users into enabling the ‘I am over eighteen years old’ option and express a willingness to view adult content.

This medium severity issue earned the security researcher who found the flaw a $500 bug bounty.

**QWACkers proposal**

Mozilla, The Electronic Frontier Foundation, and dozens of computer science experts this year pleaded with EU lawmakers to abandon plans to force web browsers to recognize the validity of contentious web certificates created by the bloc.

A proposed amendment to the eIDAS – or electronic Identification, Authentication, and Trust Services – regulation would oblige browsers to accept Qualified Website Authentication Certificates (QWACs).

RECOMMENDED Finding the next Log4j – OpenSSF’s Brian Behlendorf on pivoting to a ‘risk-centred view’ of open source development

The EU created QWACs in 2014 to validate a website’s professed identity and therefore, supposedly, protect users from fraud, malware, and surveillance. Mozilla argues that QWACs are inferior to, and would circumvent, the more effective and longstanding web authentication ecosystem already in place.

Some 38 security experts signed an open letter criticizing the plans that was addressed to the European Parliament in March.

**  
Cyber fraud executive turned cyber fraudster**

A US entrepreneur who pocketed millions of dollars after falsifying bank statements to generate investment for his cyber fraud prevention firm was sentenced to five years for securities fraud in November.

In a classic case of nefarious activities belying the noble or socially important role they are ostensibly playing (‘effective altruist’ Sam Bankman-Fried is accused of similar), Adam Rogas was convicted in relation to using fraudulent financial data to secure more than $123 million in financing for NS8, the company he co-founded.

This figure includes around $17.5 million that he apparently “personally obtained”, as The Daily Swig reported in March.

US attorney Damian Williams said: “Adam Rogas took the ‘fake-it-till-you-make-it’ saying to a criminal extreme. While claiming to be in the fraud prevention business, Rogas himself faked nearly all of his company’s customers, revenue, and assets.”

**Patching process needs remediation**

There have been some improvements when it comes to developing and applying patches but there remain causes for concern.

Not least the bug of 2021 – and perhaps the century – ‘Log4Shell’ did not provoke a universal rush to patch, with a third of Log4j downloads still pulling vulnerable versions nearly a year after its emergence.

Other causes for concern on this front include Apache Software Foundation (ASF) expressing alarm at the numbers of organizations running end-of-life versions of Apache software, while a North Carolina State University study warned of unacceptable delays to open source patches being rolled out.

**AI still no substitute for human bug hunters**

ChatGPT represents a great leap forward for AI, but proved no surrogate for homo erectus when it comes to finding and disclosing software security vulnerabilities.

The game-changing large language model (LLM) from OpenAI has already being used to write ransomware and craft phishing campaigns and offers potential utility for defenders too.

However, it’s shortcomings as a bug bounty hunter were exposed this month when a OUSD stablecoin maintainer suspected his interlocutor was a chatbot.

Daniel Von Fange reported “inconstancy between emails – each email seemed to pretend we were discussing a different bug, and each was a bug based on nonsensical premises, and each set of code sent along to prove the issues was valueless”.

The ‘researcher’ who submitted the flaw ultimately admitted ChatGPT had detailed the bug’s impact, exploitability, and possible remedies, but still had the audacity to ask for a bounty.

Von Fange told The Daily Swig that “current LLMs are good at finding plausible reasons why code might have a vulnerability”, but a bigger breakthrough would come when AI can automatically write and run code to verify exploitability.

**LastPass existential crisis**

Another year, another drip-drip of data breaches great and small, and few – if any – have sparked as much alarm as the recent compromise at password management platform LastPass.

Infosec Twitter’s horror centers on the potential impact – 33 million customers entrust their passwords to the password management market leader – and the fact the breach appeared to become more severe with every fresh update from the beleaguered company.

LastPass first revealed its servers had been hacked in August, but said it had found “no evidence” that attackers had accessed “customer data or encrypted password vaults”.

However, this changed over the festive period when LastPass admitted that hackers had stolen an employee’s cloud storage keys and pilfered customers’ encrypted password vaults.

The company nevertheless now says that, so long as customers use the recommended default settings, “it would take millions of years to guess your master password using generally-available password-cracking technology”.

RELATED Password theft bug chain patched in Passwordstate credential manager

Stupid security 2022 – this year’s infosec fails

A variety of initiatives — such as memory-safe languages and software bills of materials — promise more secure applications, but sustained improvements will require that vendors do much better, researchers agree.

Can we build a defensible Internet? To improve the security of the Internet and the cloud applications it supports in 2023, we need to do better, experts say. Much better.

At the beginning of 2022, companies famously scrambled to hunt down and mitigate a critical vulnerability in a widespread component of many applications: the Log4j library. The following 12 months of Log4Shell woes highlighted that most companies do not know all the software components that make up their Internet-facing applications, do not have processes to regularly check configurations, and fail to find ways to integrate and incentivize security among their developers. 

The result? With the post-pandemic increase in remote work, many companies have lost their ability to lock down applications and remote workers and consumers are more vulnerable to cyberattacks from every corner, says Brian Fox, chief technology officer for Sonatype, a software security firm.

"Perimeter defense and legacy behavior worked when you had physical perimeter security — basically everyone was going into an office — but how do you maintain that when you have a workforce that increasingly works from home or a coffee shop?" he says. "You've stripped away those protections and defenses."

As 2022 nears its close, companies continue to struggle against insecure applications, vulnerable software components, and the large attack surface area posed by cloud services.

**The Software Supply Chain's Gaping Holes Persist

Even though software supply chain attacks grew 633% in 2021, companies still do not have the processes in place to do even simple security checks, such as weeding out known vulnerable dependencies. In March, for example, Sonatype found that 41% of downloaded Log4jcomponents were vulnerable versions.

Meanwhile, companies are increasingly moving infrastructure to the cloud and adopting more Web applications, tripling their use of APIs, with the average company using 15,600 APIs, and traffic to APIs quadrupling in the last year.

This increasingly cloudy infrastructure makes users' human fallibility the natural attack vector into enterprise infrastructure, says Tony Lauro, director of security technology and strategy at Akamai.

"The unfortunate truth is that no matter what is happening in the enterprise and how well you lock it down and secure it, there is opportunity to attack the users," he says. "With ransomware and malware, phishing and scams, even if the back end is secure, they can take advantage of the user."

****Cyberthreats Against Applications Only Loom Larger**

To see an example of how little progress cybersecurity has made in the past three decades, companies do not have to look further than phishing. The social engineering technique has been around for almost as long as email, yet the vast majority of companies (83%) have suffered a successful email-based phishing attack in 2022. Phishing easily leads to credential harvesting and then to compromises of Web applications and cloud infrastructure.

The simple technique can bypass multiple layers of application security and give attackers access to sensitive data, systems, and networks, Daniel Cuthbert, global head of cyber security research at Banco Santander, said at this month's Black Hat Europe security conference.

"You should be able to click on something and not have it push a reverse shell out to somebody else," he lamented. "Is it that hard to ask?"

Attackers are also focusing on targeting applications in ways that get by many of the security controls that are operating at the edge of the network.

At the Black Hat Asia conference in May, researchers outlined ways to sneak attacks past web application firewalls (WAFs) to deliver malicious payloads to otherwise-protected applications and their databases. In December, cybersecurity firm Claroty demonstrated more general attacks using JSON to bypass five major WAFs, including those of Amazon Web Services and Cloudflare. In the same month, a pair of researchers used a vulnerable version of Spring Boot to bypass Akamai's WAF.

Companies have to be more tactical about how they rely on WAFs, says Akamai's Lauro. So-called "virtual patching" — when the WAF is used to block the exploit of vulnerabilities that are not yet, or cannot yet be, patched — is an important capability. Yet, too many companies use WAFs to protect poorly designed applications, he says.

"You need to identify how that vulnerability could be attacked from the Internet, and virtual patches helps there, but once you are inside the network, the first thing I'm going to do as an attacker is look for some of these zero-days and use them to move laterally," he says.

**Future AppSec Requires Innovation**

Efforts to protect the fundamental components of software by securing the software supply chain will be a key source of innovation in the near future. These advances take time to implement and are not silver bullets, but they can result in far more robust software development and end product, experts say.

Providing developers more information about the components they import into their own software through systems like Scorecard, for example, has significant security benefits. Scorecard checks a variety of software project attributes, such as whether there are binary code included in the software, have dangerous development workflows, or has signed releases. Just that information can determine whether a project is vulnerable with 78% accuracy, according to the Open Software Security Foundation (OpenSSF).

Sigstore, which allows each software component to be signed, is another technology that will help developers understand and secure their supply chains, says John Speed Meyers, principal security scientist at Chainguard, a software security firm.

"A key building block for preventing software supply chain compromises is the widespread use of digital signatures," he says. "This helps reduce the chance of software supply chain compromises and reduce the blast radius when they do happen."

**Companies Can Make Cyber-Secure Application Choices**

While those advances in the software development process can result in more secure software, the choice of language can make a significant difference as well. Memory-safe languages can all but eliminate pernicious classes of software flaws, such as buffer overflows and use-after-free vulnerabilities. 

Google, for example, found that the use of memory-safe languages, such as Java and Rust, rather than C and C++ resulted in lowering the number of vulnerabilities from 223 to 85 over three years.

Companies need to give developers more support and leeway in selecting secure tools and frameworks, not just focus on productivity and features, says Sonatype's Fox.

"There is a new reality that companies need to wake up to and deal with, and that is that the developers at the end of the day are the ones that have to make these changes, and the organizations need to recognize their problems and support them," he says. "Developers are finding their own tools, and they know that's a problem, but they are not getting the support from the company, so even in a world where developers want to do the right thing, their companies are holding them back."

At the executive level, companies also need to be using their buying power to focus on holding their vendors accountable for security of their products, Banco Santander's Cuthbert said during his Black Hat Europe keynote.

"When we look at buying product, and we look at buying software, the reality is that we have zero input to make sure that those vendors, those products are secure," he said. "We just don't have that power and we don't have meaningful influence."

Internet AppSec Remains Abysmal & Requires Sustained Action in 2023

Apache pioneer says ‘use at your own risk’ model no longer tenable as OpenSSF ramps up end user engagement

Apache pioneer says ‘use at your own risk’ model no longer tenable as OpenSSF ramps up end user engagement

The Open Source Security Foundation (OpenSSF) recently adopted Microsoft’s Secure Supply Chain Chain Consumption Framework (S2C2F) to help reduce vulnerabilities in open source software – a once unthinkable partnership given Redmond’s former animosity to open source.

Owner of GitHub since 2016 and a major Linux contributor, Microsoft developed S2C2F in 2019.

The threat-based risk-reduction framework lists supply chain threats to open source software, and provides organizations with guides for assessing their maturity and implementing the framework’s requirements.

The move is just one step OpenSSF is taking to tackle a surge in open source vulnerabilities and sevenfold rise in attacks against the ecosystem.

**Varying degrees of rigor**

For OpenSSF general manager Brian Behlendorf, adopting S2C2F is one highlight of his first year in the post, during which OpenSSF has surpassed 100 members.

Behlendorf is a co-creator of Apache HTTP Server, former CTO of the World Economic Forum, and member of Linux Foundation – which runs the OpenSSF project – since 2014.

“The OpenSSF is a collection of initiatives that aim to make open source software more secure, to more quickly find vulnerabilities, to find ways to get those vulnerabilities fixed more quickly… but also to really address the emerging weaknesses in the global software supply chain,” Behlendorf tells The Daily Swig.

“Frankly, with 70 to 90% of software in any given commercial package being pre-existing open source code, there is no distinction anymore between the world of open source and the world of commercial software,” he suggests.

MUST READ ‘We don’t teach developers how to write secure software’ – Linux Foundation’s David A Wheeler on reversing the CVE surge

Behlendorf also points to the proliferation of open source code through environments such as Kubernetes, and the way this is exposing software components that might not all have been built “to the same degree of rigor.

“Open source software tends to have a pretty decent reputation for security thanks to marquee projects like Linux, where the amount of investment into hardening and into testing and verifying and all that kind of stuff is pretty high,” he says.

“And many other projects have a high degree of diligence when it comes to the integrity and security of code. But not all projects achieve that. And a lot of software, especially the smaller modules, are built frankly by people on the way to doing something else.”

He continues: “They put it up on GitHub, or they throw a package on NPM. They wake up one day and thousands or millions of people are using their package without really thinking about it, or having any way to measure whether one package is more rigorously built and inspected and reviewed than another.”

**Lessons of Log4j**

Part of the OpenSSF’s mission, then, is to improve security practices among developers. This goes hand in hand with helping organizations that use open source code to assess security risks.

“The focus is towards objective measures of risk and ways to programmatically help consumers be smarter about their choices of software, and \[for\] developers realizing that there’s more that they can do to protect their end users,” says Behlendorf.

This has become all the more important since Log4j. “What we've found over the last year is, especially in the wake of Log4j, is a whole lot of folks want to understand better how to systematically reduce risk in the global supply chains. How do we do reduce the chances of the next Log4j?”

This has to be done, he says, to reduce the impact of a vulnerability on the millions of businesses globally that rely on open source software. New processes for software development, more scrutiny of code and software components, better use of software bills of materials (SBOMs), and developer education will all help.

“We can’t say what the next Log4j will be, but we can say which are the 200 packages that have a 1% chance of being the next Log4j,” he says.

RELATED Third of Log4j downloads still pull vulnerable version despite threat of supply chain attacks

Much of the code in use now – both commercial and open source – was not designed to resist today’s threats. The challenge is identifying those vulnerable components, and fixing or mitigating any vulnerabilities. A relatively small increase in investment in security research could, Behlendorf argues, save “billions of dollars of potential impact.

“We’ve been very poor at applying risk to software development,” he says. “It’s all been caveat emptor and good luck. Hopefully we are part of the pivot towards taking a more risk-centered view of how to build critical digital infrastructure.”

**Hesitancy over security updates**

One way of doing this is through the OpenSSF scorecard, which developers can use to check for vulnerabilities affecting source code, build, dependencies, testing, and project maintenance. It’s not foolproof, Behlendorf concedes, but enables developers to take security seriously.

But the industry, and especially developers in end user businesses, face other hurdles. Behlendorf highlights hesitancy around deploying fixes, even when patching known vulnerabilities. The fear is of disrupting a critical system.

Industry needs to convince CIOs “that they can make that update without it having cascading effects on the rest of their infrastructure,” he says. “Many organizations have been burned by doing frequent updates and discovering that that APIs change and old stuff doesn't work.” To address this, developers need to make their code more forward-compatible, as well as automating the process of updates.

Nor do organizations have effective ways of measuring technical debt, and quantifying the security risks posed by outdated code. “Not just open source software, but all commercial software, has always been ‘use at your own risk’,” he explains. And that “no liability” model has been essential for open source ecosystem to grow.

**Partnering with Microsoft**

As a result, software distributors and end users need better tools to identify and reduce risk. This is why OpenSSF has worked with Microsoft to use the S2C2F, despite the acrimonious past between Richmond and open source community.

“That was a long time ago,” says Behlendorf. “Today Microsoft is a major contributor to the Linux kernel. They are heavy spenders on improvements to lots of different open source packages.”

S2C2F will, OpenSSF believes, put more rigor into software development, and should supplement other initiatives such as the SLSA framework. 

The S2C2F will now have its own Special Initiative Group at OpenSSF that, Behlendorf says, will open it up to other vendors and stakeholders.

“Now it's an OpenSSF project, we expect to see participation from other companies,” both vendors and end user firms, he says. The OpenSSF launched an end users working group earlier this year.

End users “build a lot of this kind of internal tooling, and they’re very eager to modernize and update, and align with where industry is heading,” notes Behlendorf.

**Protecting the internet’s dark matter**

The OpenSSF is also working on memory-safe architectures through Prossimo initiative, which works with Rust and the Linux kernel, and recodes resources such as DNS libraries and even network time in a memory-safe way.

“This is like the dark matter what keeps the internet working. And if that stuff goes out, we’re all in really bad, bad shape,” Behlendorf warns.

OpenSSF will also continue to promote SBOMs as a way to increase supply chain transparency. Behlendorf wants SBOMs to be as universal as readme files within software releases, but concedes this must be done without overburdening upstream developers.

He is also realistic about the prospects for improving open source security, envisaging a future not without vulnerabilities, but where only the “incredibly niche” bugs remain.

“There’s no such thing is defect-free code,” he says. “One of my favorite sayings is that the last bug is fixed when the last user is dead!

“We'll never get to a point where there’s zero CVEs, but we should get to the point where getting them fixed is a routine part of IT infrastructure upkeep, and is non-disruptive, particularly for critical infrastructure.

“There is that that phrase: ‘with enough eyeballs all bugs are shallow’. There just aren’t enough eyeballs per line of code out there,” Behlendorf concludes.

RECOMMENDED ‘Security teams often fight against developers taking control’ of AppSec: Tanya Janca on the drive to DevSecOps adoption

Finding&nbsp;the next Log4j –&nbsp;OpenSSF’s Brian Behlendorf on pivoting to a ‘risk-centred view’ of open source development

Security leaders must maintain an effective cybersecurity strategy to help filter some of the noise on new vulnerabilities.

The security industry collectively loses its mind when new vulnerabilities are discovered in software. OpenSSL is no exception, and two new vulnerabilities overwhelmed news feeds in late October and early November 2022. Discovery and disclosure are only the beginnings of this never-ending vulnerability cycle. Affected organizations are faced with remediation, which is especially painful for those on the front lines of IT. Security leaders must maintain an effective cybersecurity strategy to help filter some of the noise on new vulnerabilities, recognize impacts to supply chains, and secure their assets accordingly.

**Supply Chain Attacks Aren't Going Away**

In roughly a year's time, we've suffered through severe vulnerabilities in componentry including Log4j, Spring Framework, and OpenSSL. Exploitation of older vulnerabilities also never ceases from implementations that are misconfigured or that use known vulnerable dependencies. In November 2022, the public learned of an attack campaign against the Federal Civilian Executive Branch (FCEB), attributable to a state-sponsored Iranian threat. This US federal entity was running VMware Horizon infrastructure that contained the Log4Shell vulnerability, which served as the initial attack vector. FCEB was hit with a complex attack chain that included lateral movement, credential compromise, system compromise, network persistence, endpoint protection bypass, and cryptojacking.

Organizations may ask "why consume OSS at all?" after security incidents from vulnerable packages like OpenSSL or Log4j. Supply chain attacks continue trending upward because componentry reuse makes “good business sense” for partners and suppliers. We engineer systems by repurposing existing code rather than building from scratch. This is to reduce engineering effort, scale operationally, and deliver quickly. Open source software (OSS) is generally considered trustworthy by virtue of the public scrutiny it receives. However, software is ever-changing, and issues arise through coding mistakes or linked dependencies. New issues are also uncovered through evolution of testing and exploitation techniques.

**Tackling Supply Chain Vulnerabilities**

Organizations need appropriate tooling and process to secure modern designs. Traditional approaches such as vulnerability management or point-in-time assessments alone can't keep up. Regulations may still allow for these approaches, which perpetuates the divide between "secure" and "compliant." Most organizations aspire to obtain some level of DevOps maturity. "Continuous" and "automated" are common traits of DevOps practices. Security processes shouldn't differ. Security leaders must maintain focus throughout build, delivery, and runtime phases as part of their security strategy:

*   **Continuously scan in CI/CD:** Aim to secure build pipelines (i.e., shift-left) but acknowledge that you won't be able to scan all code and nested code. Success with shift-left approaches is limited by scanner efficacy, correlation of scanner output, automation of release decisions, and scanner completion within release windows. Tooling should help prioritize risk of findings. Not all findings are actionable, and vulnerabilities may not be exploitable in your architecture.

*   **Continuously scan during delivery:** Component compromise and environment drift happen. Applications, infrastructure, and workloads should be scanned while being delivered in case something was compromised in the digital supply chain when being sourced from registries or repositories and bootstrapped.

*   **Continuously scan in runtime:** Runtime security is the starting point of many security programs, and security monitoring underpins most cybersecurity efforts. You need mechanisms that can collect and correlate telemetry in all types of environments, though, including cloud, container, and Kubernetes environments. Insights gathered in runtime should feed back to earlier build and delivery stages. Identity and service interactions

*   **Prioritize vulnerabilities exposed in runtime:** All organizations struggle with having enough time and resources to scan and fix everything. Risk-based prioritization is fundamental to security program work. Internet exposure is just one factor. Another is vulnerability severity, and organizations often focus on high and critical severity issues since they're deemed to have the most impact. This approach can still waste cycles of engineering and security teams because they may be chasing vulnerabilities that never get loaded at runtime and that aren't exploitable. Use runtime intelligence to verify what packages actually get loaded in running applications and infrastructure to know the actual security risk to your organization.

We've created product-specific guidance to steer customers through the recent OpenSSL madness.

The latest OpenSSL vulnerability and Log4Shell remind us of the need for cybersecurity preparedness and effective security strategy. We must remember that CVE-IDs are just those known issues in public software or hardware. Many vulnerabilities go unreported, particularly weaknesses in homegrown code or environmental misconfigurations. Your cybersecurity strategy must account for distributed and diverse technology of modern designs. You need a modernized vulnerability management program that uses runtime insights to prioritize remediation work for engineering teams. You also need threat detection and response capabilities that correlate signals across environments to avoid surprises.

**About the Author**

    

Michael Isbitski, Director of Cybersecurity Strategy at Sysdig, has researched and advised on cybersecurity for over five years. He's versed in cloud security, container security, Kubernetes security, API security, security testing, mobile security, application protection, and secure continuous delivery. He's guided countless organizations globally in their security initiatives and supporting their business.

Prior to his research and advisory experience, Mike learned many hard lessons on the front lines of IT with over 20 years of practitioner and leadership experience focused on application security, vulnerability management, enterprise architecture, and systems engineering.

Supply Chain Risks Got You Down? Keep Calm and Get Strategic!

Categories: Exploits and vulnerabilities
Categories: News
Tags: wormable

Tags:  zero-day

Tags:  spring4shell

Tags:  cve-2022-34718

Tags:  log4j

Tags:  openssl

Tags:  cve-2022-36934

Tags:  cve-2022-27492

Tags:  cve-2022-22965

Tags:  cve-2022-22963

What does it take to make the discussion of vulnerabilities useful? And where did this go wrong in 2022?



(Read more...)




The post 4 over-hyped security vulnerabilities of 2022 appeared first on Malwarebytes Labs.

A critical vulnerability can send countless organizations into chaos, as security teams read up on the vulnerability, try to figure out whether it applies to their systems, download any potential patches, and deploy those fixes to affected machines. But a lot can go wrong when a vulnerability is discovered, disclosed, and addressed—an inflated severity rating, a premature disclosure, even a mixup in names.

In these instances, when the security community is readying itself for a major sea change, what it instead gets is a ripple. Here are some of the last year's biggest miscommunications and errors in security vulnerabilities. 

**1\. "Wormable"**

There are some qualifications for vulnerabilities that send shivers up the spine of the security community as a whole. A “wormable”  vulnerability is used when the possibility exists that an infected system can contribute as an active source to infect other systems. This makes the growth potential of an infection exponential. You'll often see the phrase “WannaCry like proportions” used as a warning about how bad it could get.

Which brings us to our first example: CVE-2022-34718, a Windows TCP/IP Remote Code Execution (RCE) vulnerability with a CVSS rating of 9.8. The vulnerability could have allowed an unauthenticated attacker to execute code with elevated privileges on affected systems without user interaction, which makes it "wormable," but in the end, it turned out to be not so bad since it only affected systems with IPv6 and IPSec enabled and it was patched before an in-depth analysis of the vulnerability was publicly disclosed.

**2\. Essential building blocks**

Something we've learned the hard way is that there are very popular libraries maintained by volunteers, that many other applications rely on. A library is a set of resources that can be shared among processes. Often these resources are specific functions aimed at a certain goal which can be called upon when needed so they do not have to be included in the code of the software. A prime example of such a library that caused quite some havoc was Log4j.

So, when OpenSSL announced a fix for a critical issue in OpenSSL, everybody remembered that the last time OpenSSl fixed a critical vulnerability, that vulnerability was known as Heartbleed. The Heartbleed vulnerability was discovered and patched in 2014, but infected systems kept popping up for years.

However, when the patch came out for the more recent OpenSSL issue, it turned out the bug had been downgraded in severity. That was good news all around: The patch for the two vulnerabilities is available, and the announced vulnerability wasn’t as severe as we expected. And there is no known exploit for the vulnerabilities doing the rounds.

**3\. Zero-day**

The different interpretations for the term zero-day tend to be confusing as well.

The most accepted definition is:

> “A zero-day is a flaw in software, hardware or firmware that is unknown to the party or parties responsible for patching or otherwise fixing the flaw.”

But you will almost as often see something called a zero-day because the patch is not available yet, even though the party or parties responsible for patching or otherwise fixing the flaw are aware of the vulnerability. For example, Microsoft uses this definition:

> “A zero-day vulnerability is a flaw in software for which no official patch or security update has been released. A software vendor may or may not be aware of the vulnerability, and no public information about this risk is available.”

The difference is significant. The fact that a vulnerability exists is true for almost any complex platform or software. Someone has to find such a vulnerability before it becomes a risk. Then it depends on the researcher finding the flaw whether it becomes a threat. If the researcher follows the rules of responsible disclosure, the vendor will be made aware of the existence of the flaw before anyone else, and the vendor will have a chance to find and publish a fix for the bug before any malicious actors find out about it.

So, for a vulnerability to be alarming, I would argue it has to be used in the wild or a public Proof-of-Concept has to be available _before_ the patch has been released.

As an example of where this went wrong, a set of critical RCE vulnerabilities in WhatsApp got designated as a zero-day by several outlets, including some that should know better. As it turned out, the vulnerabilities listed as CVE-2022-36934 and CVE-2022-27492 were found by the WhatsApp internal security team and silently fixed, so they never posed any actual risk to any user. Yes, the consequences would have been disastrous if threat actors had found the vulnerabilities before the WhatsApp team did, but there never were any indications that these vulnerabilities had been exploited.

**4\. Spring4Shell**

Publicly disclosed computer security flaws are listed in the Common Vulnerabilities and Exposures (CVE) database as an individual number. CVE numbers are very helpful because they are unique and used in many reliable sources, so they make it easy to find a lot of information about a particular vulnerability. But they are hard to remember (for me at least). Coming up with fancy names and logos for vulnerabilities names, such as Log4Shell, Heartbleed, and Meltdown/Spectre helps us to tell them apart.

But when security experts themselves start to confuse different vulnerabilities in the same framework and researchers disclose details about an unpatched vulnerability because they think the information is out anyway, serious problems can arise.

In March, two RCE vulnerabilities were being discussed on the internet. Most of the people talking about them believed they were talking about “Spring4Shell” (CVE-2022-22965), but in reality they were discussing CVE-2022-22963. To add to the stress, a Chinese researcher prematurely spilled details about the vulnerability before the developer of the vulnerable Spring Framework could come up with a patch. This may have been due to the confusion about the two vulnerabilities.

In the end, Spring4Shell fizzled, working only for certain configurations and not for an out-of-the-box install.

**Public service or not?**

So, are we doing the public a service by writing about vulnerabilities? We feel we are, because it is good to raise awareness about the existence of vulnerabilities. But, to be effective, we need to meet certain criteria.

*   First of all, it needs to be made clear who is affected and who needs to do something about it. And what you can do to protect yourself.
*   While it is not always easy to make an assessment about the threat level, since we often don’t have the exact details of a vulnerability, it is desirable to not exaggerate the impact.
*   Make it very clear whether or not a threat is being used in the wild if you have that information.

In a recent assessment, security researcher Amélie Koran said on Mastodon that the economic costs of Heartbleed were mostly due to vulnerability assessment and patching and not necessarily lost or stolen data. Not that it wouldn’t have backfired if the patch hadn’t been deployed, but it is something to keep in mind. A panic situation can do more harm than the actual threat.

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

4 over-hyped security vulnerabilities of 2022

Your fortnightly rundown of AppSec vulnerabilities, new hacking techniques, and other cybersecurity news

John Leyden 16 December 2022 at 17:43 UTC

Your fortnightly rundown of AppSec vulnerabilities, new hacking techniques, and other cybersecurity news

Our second web security roundup begins with news that a brace of network security flaws in products from Fortinet and Citrix have each come under active attack.

These attacks were respectively enabled by memory corruption vulnerabilities in the FortiOS SSL-VPN as well as a critical arbitrary code execution risk in Citrix ADC and Citrix Gateway (CVE-2022-27518). It’s unclear whether these assaults are linked, but their occurrence can still be said to underline the importance of patching SSL VPN devices, which have previously been vectors for pushing ransomware onto enterprise networks, among other attacks.

Uber this week suffered a data breach as a result of a cybersecurity incident at a third-party vendor, resulting in the exposure of employees’ personal information. The incident represents only the latest security breach to impact the ride-hailing app firm, which was previously faulted for the delayed disclosure of a 2016 breach that exposed the account records of customers and drivers. More recently, back in September, Uber’s internal IT systems were breached by a social engineering attack.

Over at Black Hat Europe, security researcher Nitesh Dhanjani discussed the impact of floor prices of non-fungible token (NFT) collections and how attacks focused on business dynamics have the potential to wreak havoc on marketplaces. Dhanjani also spoke about off-chain and on-chain sync algorithms, and how the disparities between the two blockchain-related environments can be abused.

I also attended the event for The Daily Swig, reporting on a keynote in which security researcher Daniel Cuthbert said the industry’s fixation on zero-day vulnerabilities was only a partial solution to making the internet fundamentally secure. We also covered some of the top hacking tools from the event.

Among other stories on The Daily Swig in recent days was an Akamai WAF bypass via Spring Boot, SQL injection payloads being smuggled past WAFs, and a crypto maintainer rejecting a bogus cryptocurrency ‘vulnerability’ submitted with the help of ChatGPT.

Here are some other web security stories and other cybersecurity news that caught our attention in the last fortnight:

**Web vulnerabilities**

*   Apache CXF / Critical / SSRF (server-side request forgery) vulnerability in parsing the href attribute of XOP / Disclosed with patch, December 13
*   Grails Spring Security Core plugin / CVE-2022-41923 / Critical / “Vulnerability allows an attacker access to one endpoint (i.e. the targeted endpoint) using the authorization requirements of a different endpoint” / Disclosed with patch, November 22
*   Microsoft .NET / CVE-2022-41089 / Critical / “Malicious actor could cause a user to run arbitrary code as a result of parsing maliciously crafted xps files” / Disclosed with a patch, December 13
*   Ping / CVE-2022-23093 / Memory-handling vulnerability involving networking protocol implementation by FreeBSD prompted its developers to test their own software, which unearthed a flaw in OpenBSD’s implementation of Ping that dates back to software changes introduced 24 years ago
*   Planet eStream / Critical / Vulnerabilities in video platform geared towards online learning enable attackers to take over user accounts with administrative privileges and execute arbitrary JavaScript code, among other attacks / Vendor has released software updates

**Research and attack techniques**

*   A researcher documented how it’s possible to exploit misconfigurations in cross-origin resource sharing (CORS) – a mechanism to control access to restricted website resources from external domains – to run various attacks. CORS misconfiguration issues have historically been downplayed but can seemingly be exploited to bypass CSRF protections or run cross-site tracking (XST) attacks.
*   Lightspin uncovered a serious flaw in an AWS-hosted service that allows software developers to find and share public container images. Attackers could potentially delete all images in the AWS Elastic Container Registry (ECR) Public Gallery or update image contents to inject malicious code, prompting AWS to resolve the problem within a day of its disclosure.
*   A series of flaws in three popular applications that allows an Android device to be used as a remote keyboard and mouse were exposed by Synopsys Cybersecurity Research Center (CyRC) The authentication, authorization, and insecure communication flaws potentially opened up attacks including keystroke sniffing.
*   Supposedly ‘air-gapped’ networks without direct access to the internet often require DNS services in order to resolve a company’s internal DNS records – a weakness potential hackers might be able to exploit, as a blog post by Pentera explains.
*   SALT Labs used a LEGO\-run site as a testbed to illustrate the general risk posed by API security issues. Researchers uncovered a variety of API-related security issues in LEGO’s Brick Lane, including a potential vector to internal production data and systems or manipulating users into surrendering control of their accounts.

LEGO reportedly fixed a number of API security issues found by SALT Labs

**Bug bounty / vulnerability disclosure**

*   HackerOne revealed that cloud-based vulnerabilities account for a growing proportion of vulnerabilities reported by bug bounty hunters, now totalling 65,000 in 2022, a year-on-year rise of 21%.
*   A security researcher who discovered a means to achieve unauthorized access to resumes stored on LinkedIn may have been left underwhelmed by the $5,000 bounty he received for his find, given the potential impact of the issue on users of the Microsoft-owned business-focused social network. An Insecure Direct Object Reference (IDOR) security vulnerability, inadvertently introduced in October 2022, could have allowed recruiters and perhaps more unsavoury parties to download resumes without permission.
*   Swedish video surveillance giant Axis Communications has launched a private bug bounty program with Bugcrowd.

**New open source infosec/hacking tools**

*   Node Security Shield – a defensive tool that takes an allow-listing approach to protecting zero-day protection for NodeJS applications. The tool was inspired by the infamous Log4Shell vulnerability, a zero-day vulnerability in Log4j, a popular Java logging framework.
*   Invoke-DNSteal – allows pen testers to perform file transfers using the DNS protocol as a covert communications channel.
*   Kubeshark – API Traffic Viewer for Kubernetes, providing “deep visibility and monitoring of all API traffic and payloads going in, out and across containers and pods inside a Kubernetes cluster”

**For devs**

*   Google has announced a free-of-charge scanner that allows open source developers to check their software projects for vulnerable dependencies. The tool – called OSV-Scanner – builds on Google’s work in developing an open source vulnerability database.
*   OWASP, best known for its ‘Top 10 Web Application Security Risks’ framework, is backing the creation of a similar scheme to index classes of security risks in the world of AppSec and DevSecOps. The Top 10 CI/CD Security Risks taxonomy aims to catalogue risks in the CI/CD pipeline. “Insufficient Flow Control Mechanisms” topped the nascent list.
*   The SHA-1 cryptographic algorithm, in use since 1995, has reached the end of its useful life, announced the National Institute of Standards and Technology (NIST), which says the federal government should phase out its use by 2030.
*   Research from Endor Labs found that the vast majority (95%) of all vulnerabilities are “found in transitive dependencies – open source code packages that are not selected by developers, but indirectly pulled into projects”.

**For fun**

ChatGPT – the artificial intelligence chat tool from OpenAI – is the hottest thing in infosec-focused social media circles just now. Rather than suggesting possible vulnerabilities in code we wondered what ChatGPT could conjure when asked to write lyrics for a song about SQL injection in the style of the late David Bowie.

The results were more than satisfactory:

In the realm of computers, where data flows like a stream  
There are those that seek to exploit and cause us all to scream  
They are the hackers, the codebreakers, the malicious ones  
And among their favorite trick is the art of SQL injection

Chorus:

SQL injection, SQL injection  
A dangerous game, a digital infection  
SQL injection, SQL injection  
Beware of the hackers and their devious invention

To paraphrase the great man himself, I still don’t know what I was waiting for... but it definitely wasn’t this.

RECOMMENDED Black Hat Europe 2022: A defendable internet is possible, but only with industry makeover

Deserialized web security roundup – Fortinet, Citrix bugs; another Uber breach; hacking NFTs at Black Hat 

We expect this data-driven story will shed some insight into Cisco’s and the security community’s most notable successes and remaining challenges. As these Year in Review reports continue in the future, we aim to help explain how the threat landscape changes from one year to the next.

Wednesday, December 14, 2022 08:12

This report represents an unprecedented effort within Cisco to tell a comprehensive story of our work in the past year, relying on a wide variety of data and expertise.

As a large security organization with global reach, the data we use as the basis for our research presents us with both a gift and a curse. The gift lies in the diversity of inputs, ranging from endpoint detections, incident response engagements, network traffic, email corpus, data from our sandboxes and honeypots, and much, much more from customers all over the world. The curse is that with the multitude of telemetry we have access to and the urgency of some of the work we do, it can be difficult to take a step back and look at the bigger picture, like trying to make sense of a Monet with your nose up against the frame.

This is what inspired us to create the Cisco Talos Year in Review. We wanted to get insight from dozens of subject matter experts all throughout Cisco, including our reverse engineers, detection specialists, data scientists, linguists, managed hunt providers, incident responders, and threat intelligence analysts. To this diverse group, we posed a few key questions:

1.  What were the major security events Cisco responded to in 2022 and what is their current status and impact?
2.  What are the major trends in the threat landscape and what do we think may change?
3.  What are the top threats we observed in 2022 and what is their current state?

This report tells a story based on responses to these questions from our experts and their year-long data. Through the upcoming weeks, we will be highlighting different aspects of this story, including our efforts in Ukraine, the disastrous Log4j vulnerabilities, adversaries’ use of offensive frameworks and software native to the victim’s machine, shifts in the ransomware landscape, the ever-present threat of commodity loaders/trojans, as well as an overview of some of the advanced persistent threats (APTs) we are most concerned with. Throughout the story, one key theme is clear: adversaries are adapting to shifts in the geopolitical landscape, actions from law enforcement, and the efforts of defenders. Defenders will need to track and address these shifts in behavior in order to maintain resilience.

We expect this data-driven story will shed some insight into Cisco’s and the security community’s most notable successes and remaining challenges. In addition, as these Year in Review reports continue in the future, we aim to provide data and narratives that help explain how the threat landscape changes from one year to the next. We hope you find this report as elucidating to read as it was to research and write, and that it arms the security community with the information and context needed to continue fighting the good fight.

Talos Year in Review 2022

Google on Tuesday announced the open source availability of OSV-Scanner, a scanner that aims to offer easy access to vulnerability information about various projects.
The Go-based tool, powered by the Open Source Vulnerabilities (OSV) database, is designed to connect "a project's list of dependencies with the vulnerabilities that affect them," Google software engineer Rex Pan in a post shared

Open Source / Vulnerability Database

Google on Tuesday announced the open source availability of **OSV-Scanner**, a scanner that aims to offer easy access to vulnerability information about various projects.

The Go-based tool, powered by the Open Source Vulnerabilities (OSV) database, is designed to connect "a project's list of dependencies with the vulnerabilities that affect them," Google software engineer Rex Pan in a post shared with The Hacker News.

"The OSV-Scanner generates reliable, high-quality vulnerability information that closes the gap between a developer's list of packages and the information in vulnerability databases," Pan added.

The idea is to identify all the transitive dependencies of a project and highlight relevant vulnerabilities using data pulled from OSV.dev database.

Google further stated that the open source platform supports 16 ecosystems, counting all major languages, Linux distributions (Debian and Alpine), as well as Android, Linux Kernel, and OSS-Fuzz.

The result of this expansion is that OSV.dev is a repository to more than 38,000 advisories, up from 15,000 security alerts a year ago, with Linux (27.4%), Debian (23.2%), PyPI (9.5%), Alpine (7.9%), and npm (7.1%) taking up the top five slots.

As for the next steps, the internet giant noted it's working to incorporate support for C/C++ flaws by building a "high quality database" that involves adding "precise commit level metadata to CVEs."

\\

OSV-Scanner arrives nearly two months after Google launched GUAC – short for Graph for Understanding Artifact Composition – to complement Supply chain Levels for Software Artifacts (SLSA or "salsa") as part of its efforts to harden software supply chain security.

Last week, Google also published a new "Perspectives on Security" report calling on organizations to develop and deploy a common SLSA framework to prevent tampering, improve integrity, and secure packages against potential threats.

Other recommendations laid out by the company include taking on additional open source security responsibilities and adopting a more holistic approach to addressing risks such as those presented by the Log4j vulnerability and the SolarWinds incident in recent years.

"Software supply chain attacks typically require strong technical aptitude and long-term commitment to pull off," the company said. "Sophisticated actors are more likely to have both the intent and capability to conduct these types of attacks."

"Most organizations are vulnerable to software supply chain attacks because attackers take the time to target third-party providers with trusted connections to their customers' networks. They then use that trust to burrow deeper into the networks of their ultimate targets."

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Google Launches Largest Distributed Database of Open Source Vulnerabilities

Aids and techniques demonstrated at this year’s arsenal track

Aids and techniques demonstrated at this year’s arsenal track

  

Tools to enable the work of security researchers, pen testers, and bug bounty hunters were demonstrated at this year’s Black Hat Europe conference, held at London’s Excel Centre this week.

The annual security conference saw hackers from across the world gather to share research and other insights.

One of the conference’s regular features is the arsenal track, where attendees can witness live demos of various hacking tools.

**Node Security Shield**

One of the tools showcased this year, Node Security Shield, “provides zero-day protection for NodeJS applications”, Lavakumar Kuppan of Domsdog Security, which created the tool, told The Daily Swig.

“It is a defensive tool designed to be used by developers as well as security engineers,” they said.

“Existing defensive systems like WA \[web application firewall\], RASP or any of the supply chain attack protection systems all take a similar approach. They look for known bad patterns. This approach is fine for blocking well known attacks, but it is ineffective against zero-days.

“Node Security Shield takes the opposite approach. Application owners typically know and can define the expected behavior of their application. Node Security Shield ensures that only the defined good behavior is allowed, and any deviations are either blocked or trigger an alert.”

Node Security Shield supports a ‘Resource Access Policy’, inspired by Content Security Policy, a simple JavaScript object where the application owner defines the expected behavior of their app.

Read more of the latest news about hacking tools

“This enables us to block or provide exploitation mitigation against zero-day attacks. Also this approach is extremely fast compared to the other systems that have to compare every incoming request against an ever increasing list of attack patterns.

“With systems like WAF and RASP (runtime application self-protection) there is a risk of legitimate functionality being affected because it is unclear what those products will block and allow. That risk is significantly less with this approach since the application owners have a very clear understanding of what this tool will allow and what it will block.”

The tool was inspired by the Log4Shell vulnerability, a zero-day vulnerability in Log4j, a popular Java logging framework, which could lead to arbitrary code execution. Many application that relied on Log4j became vulnerable as a result of the problem.

“The fact that an application can just randomly make a network connection to a server that the developer’s never intended it to, bothered us a lot.

“So \[we\] set out to build a system where the application owners can define who their application can talk to and enforce it, thereby blocking the exploitation of zero-days like Log4Shell.”

The tool was developed as an internal project at Domdog Security to protect their own NodeJS applications, however the team said they are “aware of at least two other companies that are experimenting with it now”.

Kuppan added: “We are looking to add the ability to control file system access in the next release. Most user feedback has pointed towards wanting the ability to update the Resource Access Policy dynamically without requiring app restart. So that is also in the roadmap.”

**JavaScript obfuscation**

Also presenting at the show was Or Katz, who showed a tool designed to be able to detect JavaScript code as being obfuscated, detecting obfuscation by using structure-based signatures.

It detects JavaScript code before being rendered by the browser “which is more challenging as the obfuscation tool will create different variations of the same malicious JavaScript each time \[it is\] being obfuscated”, Katz told The Daily Swig ahead of his presentation JavaScript Obfuscation – It’s All About the P-a-c-k-e-r-s.

“Using this static code detection approach has \[meant it has\] better performance compared to techniques that require rendering of the page.

The tool also exposes a set of features collected from JavaScript code that enables more detection and classification capabilities.

Katz added: “We have future thoughts on adding more capabilities for more coverage on obfuscation tools, using collecting features for training of machine learning modules that will enable classification of malicious versus benign code.”

**Invoke-DNSteal**

A third tool, Invoke-DNSteal, allows users to perform file transfers using the DNS protocol as a covert communications channel, its creator Joel Gamez told The Daily Swig.

Although it has been designed primarily for pen testers, bug bounty hunters could also use it in “very restricted environments, in order to exfiltrate information from a compromised computer”, Gamez noted.

“Unlike other DNS data exfiltration tools, Invoke-DNSteal stands out for two main features:

The first, is that it does not use any type of library nor does it depend on third parties to work.

“For the server side, it only uses Python and sockets, so any device (however limited) that can run Python can run the server.

“For the victim (or client, if you prefer) side, native PowerShell queries will be used to send information via DNS, thus bypassing many anti-virus and EDR solutions.”

Also unlike other tools, says Gamez, Invoke-DNSteal focuses on the resolver and not the DNS domain.

“All DNS exfiltration tools need a domain to send information to. To do so, they will need to resolve that request using any DNS resolver.

“In the case of Invoke-DNSteal, we focus on using a resolver (or a list of them) controlled by the attacker, which will resolve any domain, even if it does not exist.

“In this way, it is possible to send information to random domains that do not exist, thus circumventing most DNS anti-spoofing solutions on the market.”

Users are also able to control the size and sending time of the payloads, which will also help them to evade protections.

“I decided to create this tool because I did not find any that solved this problem, or that used this technique of using random domains that do not exist to perform these bypasses,” Gamez said.

“In the next versions we will add a sequence control (remember that UDP \[User Datagram Protocol\] does not exist by default), payload encryption by default, a client for Linux and some improvements in payload compression, among many other things.”

YOU MAY ALSO LIKE Black Hat Europe 2022: A defendable internet is possible, but only with industry makeover

Tag

#log4j