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

Vendors and operators attempt to balance power and security, but right now, power is the highest goal.

SUPERCOMPUTING 2022 — How do you keep the bad guys out of some of the world's fastest computers that store some of the most sensitive data?

That was a growing concern at last month's Supercomputing 2022 conference. Achieving the fastest system performance was a hot topic, like it is every year. But the pursuit of speed has come at the cost of securing some of these systems, which run critical workloads in science, weather modeling, economic forecasting, and national security.

Implementing security in the form of hardware or software typically involves a performance penalty, which slows down overall system performance and the output of computations. The push for more horsepower in supercomputing has made security an afterthought.

"For the most part, it's about high-performance computing. And sometimes some of these security mechanisms will reduce your performance because you are doing some checks and balances," says Jeff McVeigh, vice president and general manager of Super Compute Group at Intel.

"There's also a 'I want to make sure I'm getting the best possible performance, and if I can put in other mechanisms to control how this is being securely executed, I'll do that,'" McVeigh says.

**Security Needs Incentivizing**

Performance and data security is a constant tussle between the vendors selling the high-performance systems and the operators who are running the installation.

"Many vendors are reluctant to make these changes if the change negatively impacts the system performance," said Yang Guo, a computer scientist at the National Institutes for Standards and Technology (NIST), during a panel session at Supercomputing 2022.

The lack of enthusiasm for securing high-performance computing systems has prompted the US government to step in, with the NIST creating a working group to address the issue. Guo is leading the NIST HPC Working Group, which focuses on developing guidelines, blueprints, and safeguards for system and data security.

The HPC Working Group was created in January 2016 based on then-President Barack Obama's Executive Order 13702, which launched the National Strategic Computing Initiative. The group's activity picked up after a spate of attacks on supercomputers in Europe, some of which were involved in COVID-19 research.

**HPC Security Is Complicated**

Security in high-performance computing is not as simple as installing antivirus and scanning emails, Guo said.

High-performance computers are shared resources, with researchers booking time and connecting into systems to conduct calculations and simulations. Security requirements will vary based on HPC architectures, some of which may prioritize access control, or hardware like storage, faster CPUs, or more memory for calculations. The top focus is on securing the container and sanitizing computing nodes that pertain to projects on HPC, Guo said.

Government agencies dealing in top-secret data take a Fort Knox-style approach to secure systems by cutting off regular network or wireless access. The "air-gapped" approach helps ensure that malware does not invade the system, and that only authorized users with clearance have access to such systems.

Universities also host supercomputers, which are accessible to students and academics conducting scientific research. Administrators of these systems in many cases have limited control over security, which is managed by system vendors who want bragging rights for building the world's fastest computers.

When you place management of the systems in the hand of vendors, they will prioritize guaranteeing certain performance capabilities, said Rickey Gregg, cybersecurity program manager at the US Department of Defense's High Performance Computing Modernization Program, during the panel.

"One of the things that I was educated on many years ago was that the more money we spend on security, the less money we have for performance. We are trying to make sure that we have this balance," Gregg said.

During a question-and answer session following the panel, some system administrators expressed frustration at vendor contracts that prioritize performance in the system and deprioritize security. The system administrators said that implementing homegrown security technologies would amount to breach of contract with the vendor. That kept their system exposed.

Some panelists said that contracts could be tweaked with language in which vendors hand over security to on-site staff after a certain period of time.

**Different Approaches to Security**

The SC show floor hosted government agencies, universities, and vendors talking about supercomputing. The conversations about security were mostly behind closed doors, but the nature of supercomputing installations provided a birds-eye view of the various approaches to securing systems.

At the booth of the University of Texas at Austin's Texas Advanced Computing Center (TACC), which hosts multiple supercomputers in the Top500 list of the world's fastest supercomputers, the focus was on performance and software. TACC supercomputers get scanned regularly, and the center has tools in place to prevent invasions and two-factor authentication to authorize legit users, representatives said.

The Department of Defense has more of a "walled garden" approach, with users, workloads, and supercomputing resources segmented into a DMZ-stye border area with heavy protections and monitoring of all communications.

The Massachusetts Institute of Technology (MIT) is taking a zero-trust approach to system security by getting rid of root access. Instead it uses a command line entry called sudo to provide root privilege to HPC engineers. The sudo command provides a trail of activities HPC engineers undertake on the system, said Albert Reuther, senior staff member in the MIT Lincoln Laboratory Supercomputing Center, during the panel discussion.

"What we're really after is that auditing of who is at the keyboard, who was that person," Reuther said.

**Improving Security at the Vendor Level**

The general approach to high-performance computing has not changed in decades, with a heavy reliance on giant on-site installations with interconnected racks. That is in sharp contrast to the commercial computing market, which is moving offsite and to the cloud. Participants at the show expressed concerns about data security once it leaves on-premises systems.

AWS is trying to modernize HPC by bringing it to the cloud, which can scale up performance on demand while maintaining a higher level of security. In November, the company introduced HPC7g, a set of cloud instances for high-performance computing on Elastic Compute Cloud (EC2). EC2 employs a special controller called Nitro V5 that provides a confidential computing layer to protect data as it is stored, processed, or in transit.

"We use various hardware additions to typical platforms to manage things like security, access controls, network encapsulation, and encryption," said Lowell Wofford, AWS principal specialist solution architect for high performance computing, during the panel. He added that hardware techniques provide both the security and bare-metal performance in virtual machines.

Intel is building confidential computing features like Software Guard Extensions (SGX), a locked enclave for program execution, into its fastest server chips. According to Intel's McVeigh, a lackadaisical approach by operators is prompting the chip maker to jump ahead in securing high-performance systems.

"I remember when security wasn't important in Windows. And then they realized 'If we make this exposed and every time anyone does anything, they're going to worry about their credit card information being stolen,'" McVeigh said. "So there is a lot of effort there. I think the same things need to apply \[in HPC\]."

Security Is a Second-Class Citizen in High-Performance Computing

Less is often more when it comes to both infosec and eco-friendly computing practices

Adam Bannister 22 December 2022 at 15:35 UTC  
Updated: 22 December 2022 at 15:42 UTC

Less is often more when it comes to both infosec and eco-friendly computing practices

Reducing the carbon footprint of computing architecture could play a role not just in tackling climate change but another growing, borderless threat too – cyber-attacks.

That’s according to co-authors of a white paper that highlights how best practices for making cloud infrastructure secure and sustainable sometimes happily overlap with the common pursuit of efficiencies.

“The lowest hanging fruit for sustainability is to do less and save less data, which should also reduce attack surfaces,” Anne Currie, co-author of draft paper ‘The State of Green Cloud Software Practices’ and community chair at Green Software Foundation, told The Daily Swig.

Read more of the latest news about secure development

Fellow co-author Paul Johnston, founder of UK tech consultancy Roundabout Labs and former senior developer advocate for serverless at Amazon Web Services (AWS), echoes these sentiments.

“My take is that generally, greener means fewer lines of code and that means smaller attack surface,” he told The Daily Swig. Johnston said this also means “better use of managed services which, again, generally means that your attack surface is reduced (services tend to be better for infosec)”.

Shutting down defunct applications and services has the same effect. “Unmaintained, zombie, workloads are bad for the environment as well as being a security risk,” reads the white paper, which also has contributors from Red Hat, Microsoft, and the Green Web Foundation.

**Memory-safe languages**

Developers are urged to “rewrite code to use a more lightweight framework or language. Moving from Python to Rust could result in a 10-fold cut in CPU requirements, for example,” says the white paper. This could have security benefits insofar as Rust is, unlike Python, memory safe by default.

The white paper also endorses Golang as “an efficient language and easier than the classic HPC options of C or C++”.

Again, there is some positive correlation here with security best practices given the US National Security Agency (NSA) recently urged (PDF) organizations to abandon languages lacking “inherent memory protection, such as C/C++”, in favor of memory-safe alternatives like Golang, C#, Java, Ruby, and Swift.

Indeed, C and C++ have been blamed for the fact 70% of Microsoft and Google Chrome flaws are memory safety vulnerabilities.

Rust is seen as considerably more energy-efficient than Python

**Security and C, C++**

However, it’s perhaps reductive to conclude that ‘lightweight’ languages – generally defined in terms of syntax, memory footprint, and implementation complexity – are inherently more secure or sustainable in every context.

After all, it’s perfectly possible to write a super-efficient, ‘green’ program in C++, but this is obviously contingent on the developer’s aptitude.

“Vulnerabilities are less likely if the language constructs make it so the easy or obvious way either can’t or is unlikely to be a vulnerability,” David A Wheeler, director of open source supply chain security at the Linux Foundation, told The Daily Swig.

DON’T MISS ‘We don’t teach developers how to write secure software’: David A Wheeler on reversing CVE surge

“C is a relatively simple programming language in the sense that it has relatively few constructs; in that view, it’s lightweight. However, many operations in C (array deference, pointer assignment, or dereference, etc) provide no automatic protections, so any mistake can quickly lead to a vulnerability.

“In contrast, C++ is a much larger and more complex language than C,” continued Wheeler. “In at least some measures it wouldn’t be considered lightweight. However, its lack of many safety mechanisms by default leads to the same problems.”

**Managed cloud services**

Managed cloud services are also endorsed by the sustainable computing white paper because, among other things, they offer high compute density and autoscaling via serverless services.

Yet some enterprises are still nervous about moving data security into shared environments. Ann Currie, a software engineer as well as sci-fi author, considers these fears completely unjustified.

“The cloud puts way more effort into infosec than companies,” says Currie. “It’s a classic area where specialists kick the butt of the (usually) generalists in enterprises.”

Nevertheless, Paul Johnston warns that delegating security functions does create risks.

Catch up with the latest articles about security best practices

“The benefits of a ‘greener’ approach (even if unintentional) are very positive from an infosec view,” he explains.

“However, there is a possible downside in that the security side that you resolve by using managed services or by reducing code can then lead to an element of complacency about the elements that are often a little more complicated.”

The white paper also recommends “moving more work to the client or edge”, which generates security challenges, albeit solvable ones, by extending the attack surface beyond the data center.

Another sustainability goal is surely an unequivocal plus for security. Currie, Johnston, and their fellow co-authors envisage a future where firmware remains backwards-compatible with devices that are at least 10 years old – keeping users protected by security patches for longer.

**Eco incentives**

Compliance and shareholder pressures plus lower running costs surely persuaded tech giants like Microsoft to set ambitious targets for becoming fully carbon neutral or even carbon negative.

Nevertheless, Currie suspects the potentially dire reputational and financial costs of neglecting cybersecurity are an even stronger incentive for change.

“Getting sustainability to the top of the priority list is harder than getting security there,” she says. “The good news is cloud managed services are usually fairly sustainable and secure.”

In other words: anyone trying to persuade organizations to make their computing practices greener would be wise to flag any incidental security benefits when doing so.

RECOMMENDED Deserialized WebSec roundup – Fortinet, Citrix bugs; another Uber breach; hacking NFTs

Lean, green coding machine: How sustainable computing drive can reduce attack surfaces

A successful attacker could use the SSRF vulnerability to collect metadata from WordPress sites hosted on an AWS server, and potentially log in to a cloud instance to run commands.

A vulnerability in the Google Web Stories plug-in for WordPress could be exploited via a server-side request forgery (SSRF) vulnerability to steal Amazon Web Services (AWS) metadata from sites hosted on the AWS server. That metadata can include sensitive information such as the AccessKeyId, SecretAccessKey, and Token.

An SSRF vulnerability gives attackers a way to elevate privileges on a compromised system using a modified URL, thereby gaining access to internal resources.

The Web Stories plug-in is an open visual storytelling format for the Web, consisting of animations and other interactive graphics, which can be shared and embedded across sites and apps. There are more than 100,000 active installations of the plug-in.

A Wordfence research team discovered the plug-in was vulnerable to the SSRF bug (CVE-2022-3708) in versions through 1.24.0, due to insufficient validation of URLs supplied via the "url" parameter found via the /v1/hotlink/proxy REST API Endpoint.

"Exploiting this vulnerability, an authenticated user could make web requests to arbitrary locations originating from the web application," Wordfence Threat Intelligence team member Topher Tebow wrote in a Dec. 21 blog post.

He added that, in testing, the team was able to uncover specific metadata used to enable features like EC2 Instance Connect; stolen metadata could then be used to log in to the virtual server and run commands through the terminal.

The researcher noted that this is the tip of the iceberg: "There are many metadata categories provided by AWS that each have specific uses and varying degrees of severity if misused."

The team found the flaw in October, and by the end of November, two blocks of code were updated to fully patch the vulnerability in the plug-in.

"With the patch applied within version 1.25.0 and newer, attempts to obtain AWS metadata will fail," Tebow explained.

He added that the attack can succeed for users logged in with an account that has minimal permissions, such as a subscriber, so the issue particularly threatens sites with open registration.

"The authenticated user does not need high level privileges to exploit this vulnerability," Tebow continued.

**Using Zero Trust to Limit SSRF Vulnerabilities**

"Understanding the impact of vulnerabilities such as SSRF vulnerabilities is critical for developers," Tebow wrote. "Keeping code secure can be difficult to ensure during the development phase, which is why the code must be tested for vulnerabilities during and after it has been written."

Developers were advised to pay close to attention to their coding practices as they relate to the vulnerabilities inherent in each programming language, ensure any inputs are validated, and to adopt a posture of zero trust authentication.

"SSRF vulnerabilities are possible because the internal and external resources may be configured to assume that requests sent from an internal location are inherently trustworthy," Tebow noted. "By requiring validation and authorization for every action, this default trust is removed, and requests must be validated properly before being considered trusted."

Constant code reviews and updates of WordPress plug-ins and themes are among the other steps that developers can take to limit exploits of WordPress-built websites.

**WordPress Sites Face a Raft of Security Issues**

Malicious actors have been targeting WordPress sites at a rapid clip — mainly through vulnerable plug-ins — since the beginning of the year: In February, a report found tens of thousands of websites powered by WordPress were vulnerable to attack via a remote code execution (RCE) bug in a widely used plug-in called Essential Addons for Elementor.

In May, there was a widespread attack launched to exploit known RCE flaw in the Tatsu Builder WordPress plug-in, and two months later, researchers discovered a phishing kit that injects malware into legitimate WordPress sites and uses a fake PayPal-branded social engineering scam.

More recently, a threat group called SolarMarker exploited a vulnerable WordPress-run website to encourage victims to download fake Chrome browser updates, while another group of attackers were actively exploiting a critical vulnerability in BackupBuddy, a WordPress plug-in that an estimated 140,000 websites are using to back up their installations.

Google WordPress Plug-in Bug Allows AWS Metadata Theft

Organizations can start by integrating functions like detection, prioritization, and remediation on to a single platform.

Cloud transformation often occurs simultaneously across siloed organizational units and groups, each potentially using a different cloud for their applications and workloads. However, taking inventory of all their cloud resources and building a compliant, secure, simple, and unified strategy has become a common challenge.

It wouldn’t be surprising to see an organization with most of its workloads in AWS using Microsoft 365 and Azure Active Directory while also heavily using Google Cloud GKE and Big Query. On top of that, Oracle Cloud may also be in the mix with some autonomous database offerings. As cloud adoption matures in an organization, and as smaller cloud providers gain traction, the mix of services and cloud platforms becomes incredibly diverse and complex. In light of these challenges, organizations must still find ways to govern and secure their entire cloud infrastructure.

The answer? A framework that works across all clouds to unify detection, prioritization, and remediation of the most impactful risks facing the organization.

****Identities and Authentication Keys****

Diving into a use case around cloud identity authentication keys for access, let’s see how you can protect your organization’s crown jewels in your multicloud environment. In the cloud world, identity is perhaps the most critical cloud object to govern, monitor, detect, and remediate. Compromising a cloud identity has the largest blast radius since, frankly, the public cloud is just a bunch of public APIs that respond to authenticated requests.

Authentication keys are cryptographic entities attached to an identity that allow you to issue authenticated API requests from the Internet. Hence, these keys call for the undivided attention of any governance and security strategy. However, each cloud provider defines identity in a different way, with a completely new set of capabilities and risks.

    

The idea here is to think of an organization that wants to enforce the following policy: “Authentication keys should be rotated every 90 days, and every 30 days if they enable personally identifying information access.” This seemingly simple policy would need to take four different implementations, depending on which cloud it’s using. Additionally, the security admin would need to tailor specific policies, such as limiting the number of concurrent keys (not relevant to AWS) or enforcing expiration dates upon key creation (not relevant for secrets).

The same concept applies when an organization tries to enforce “do not allow public access to storage objects” or “only build workloads from images that are up to date.”

****Building, Securing, and Governing the Cloud****

While each cloud is unique, foundationally, they are not so different. They all have a concept of a computer instance, object and file storage, and both human and nonhuman identities, each of which can be assigned permissions. As a result, the multicloud infrastructure calls for unification between building, securing, and governing the cloud.

When building cloud deployments, organizations rely on infrastructure as code (IaC) languages like HashiCorp’s Terraform to create a unified approach to address cloud objects. Think of IaC as a higher-level language over the lower-level cloud-specific API calls.

The parallel higher-level language for securing and governing the cloud is the cloud-native application protection platform (CNAPP). CNAPP converges tools like cloud security posture management, cloud infrastructure entitlement management, cloud workload protection platform, configuration management database, and others, providing complete security for your cloud, spanning the cloud development lifecycle from build time to run time. CNAPP provides a single pane of glass for all your cloud environments.

These solutions provide a complete inventory of your cloud assets, as well as visibility into potential security gaps and risks, correlating across a broad range of signals including misconfigurations, vulnerabilities, Internet exposure, excessive permissions, and more.

Through a CNAPP, teams can enable unified detection, investigation, and enforcement of common cloud objects, as well as pitfalls such as exposed storage, unpatched compute instances, and more. Ideally, a single UI workflow allows you to enforce multicloud organization policies such as “block public access for cloud storage” or “isolate compute instances that accept traffic from the Internet and expose a service with critical vulnerabilities.”

Here are additional best practices and recommendations for securing your cloud footprint:

*   Decide whether to measure against a security framework like NIST or CIS, or your own internally developed policies. Implement these policies across the development lifecycle, with explicit definition of where to enforce action-blocking guardrails. A CNAPP can help you accomplish this.
*   Ensure your security team is diversified in terms of multicloud knowledge, e.g., AWS, Azure, and GCP.
*   Implement identity best practices, such as single sign-on and multifactor authentication, via your organization’s existing IAM provider, whenever possible. Avoid the use of cloud-specific local identities to access the cloud from the Internet.
*   Define the unified view as a prerequisite for procurement of cloud security tools. Ideally, choose tools that enable a unified approach of enforcing organizational policies across clouds.

Cloud transformation has become a vital initiative for many organizations. As you go through the cloud transformation journey, remember that your approach to security (and the tools you use) must transform as well. Whether you’re unifying siloed tools, security and DevOps teams, different cloud vendors, management, or policies and languages, bringing tools together and enforcing commonalities will benefit your organization in the long run.

Read more _Partner Perspectives_ from Zscaler.

Best Practices for Securing and Governing Your Multicloud Deployment

A vulnerability in the label-based access control of Grafana Labs Grafana Enterprise Metrics allows an attacker more access than intended. If an access policy which has label selector restrictions also has been granted access to all tenants in the system, the label selector restrictions will not be applied when using this policy with the affected versions of the software. This issue affects: Grafana Labs Grafana Enterprise Metrics GEM 1.X versions prior to 1.7.1 on AMD64; GEM 2.X versions prior to 2.3.1 on AMD64.

CVE-2022-44643: Downloads |  Grafana Enterprise Metrics documentation

Threat actors can take over victims' cloud accounts to steal data, or use them for command-and-control for phishing attacks, denial of service, or other cyberattacks.

Attackers can compromise a new feature in Amazon Web Services (AWS) to hijack cloud accounts' static public IP addresses and abuse them for various malicious purposes, researchers have found.

Threat actors can use the Amazon Virtual Private Cloud (VPC) Elastic IP (EIP) transfer feature to steal someone else's EIP and use it as their own command-and-control (C2), or to launch phishing campaigns that impersonate the victim, researchers from cloud incident response firm Mitiga revealed in a blog post on Dec. 20.

Attackers also can use the stolen EIP to attack a victim's own firewall-protected endpoints, or to serve as the original victim’s network endpoint to extend opportunities for data theft, the researchers said.

"The potential damage to the victim by hijacking an EIP and using it for malicious purposes can mean using the victim’s name, jeopardizing the victim’s other resources in other cloud providers/on-premises, and \[stealing the\] victim’s customers' information," Or Aspir, software engineer at Mitiga, wrote in the post.

Threat actors must already have permissions on an organization's AWS account to leverage the new attack vector, which the researchers call "a post-initial-compromise attack."

However, because the attack was not possible before the feature was added and is not yet listed in the MITRE ATT&CK Framework, organizations may be unaware that they are vulnerable to it, as it's not likely to be picked up by existing security protections, the researchers said.

"With the right permissions on the victim’s AWS account, a malicious actor using a single API call can transfer the victim’s used EIP to their own AWS account, thus practically gaining control over it," Aspir wrote. "In many cases it allows greatly increasing the impact of the attack and gaining access to even more assets."

**How Elastic IP Transfer Works**

AWS introduced EIP in October as a legitimate feature to allow transfer of Elastic IP addresses from one AWS account to another. An Elastic IP (EIP) address is a public and static IPv4 address that can be reached from the Internet and can be allocated to an Elastic Compute Cloud (EC2) instance for Web-facing activities, such as website hosting or communicating with network endpoints under a firewall.

AWS introduced the feature to make it easier to move Elastic IP addresses during AWS account restructuring by transferring the EIP to any AWS account — even AWS accounts that are not owned by someone or his or her organization, the researchers said.

With the feature, the transfer is a mere "two-step handshake between AWS accounts — the source account (either a standard AWS account or an AWS Organizations account) and the transfer account," Aspir explained.

**Abuse of Elastic IP Transfer**

The ease with which EIPs can now be transferred creates an unintentional issue, however — while it certainly facilitates the process of transferring IP for legitimate account owners, it also makes it easier for malicious actors as well, the researchers said.

Researchers described a basic scenario to illustrate how attackers can take advantage of EIP transfer, assuming that attackers already have permissions that allow them to "see" existing EIPs and their status, or whether or not they are associated with other computer resources.

Typically, EIPs are associated, but sometimes an organization keeps dissociated EIP for later use, or as a result of an unmanaged environment that keeps unused resources, the researchers said. "Either way, the attacker only needs to enable the EIP transfer, and the IP address is theirs," Aspir wrote.

Attackers can do this in two ways with the correct permissions: either transfer a dissociated EIP or remove the association of an associated EIP and then transfer it, the researchers said.

For the former, an adversary must have the following action in its attached Identity and Access Management (IAM) policy on AWS: "ec2:DisassociateAddress" action on the elastic IP addresses and the network interfaces that the IP addresses are attached to.

To transfer an EIP, a threat actor must have the following actions in its attached IAM policy: "ec2:DescribeAddresses" on all the IP addresses and "ec2:EnableAddressTransfer" on the EIP address that the attacker wants to transfer, the researchers said.

**Leveraging a Stolen EIP**

There are a wide range of attack scenarios that a threat actor can engage in after successfully transferring someone else's EIP to their own control.

In external firewalls used by the victim, for example, an attacker can communicate with the network endpoints behind the firewalls if there is an allow rule on the specific IP address, the researchers said.

Moreover, in cases in which a victim uses DNS providers such as a Route53 service, there could be DNS records of an "A" type in which the target is the transferred IP address. In this case, an attacker can abuse the address for hosting a malicious Web server under a legitimate victim’s domain, then launch other malicious actions, such as phishing attacks, the researchers said.

Attackers also can use the stolen IP address as C2, using it for malware campaigns that appear legitimate and thus fly under the radar of security defensives. A threat actor can even cause denial of service (DoS) to a victim's public services if they dissociate an EIP from a running endpoint and transfer it, the researchers said.

**Who's at Risk and How to Mitigate It**

Anyone using EIP resources in an AWS account is at risk, and thus must treat the EIP resources like other resources in AWS that are in danger of exfiltration, the researchers advised.

To protect themselves from an EIP transfer attack, Mitiga recommends that enterprises use the principle of least privilege on AWS accounts and even disable the ability to transfer EIP entirely if it's not a necessary feature on their environment.

To do this, an organization can use native AWS IAM features such as service control policies (SCPs), which offer central control over the maximum available permissions for all accounts in an organization, the researchers said, providing an example in their post of how this works.

AWS Elastic IP Transfer Feature Gives Cyberattackers Free Range

Definitive solution is ‘non-trivial’ since behavior arises from customers processing non-RFC compliant requests

Definitive solution is ‘non-trivial’ since behavior arises from customers processing non-RFC compliant requests

A vulnerability in how Akamai retrieves Amazon Web Services (AWS) S3 resources could allow attackers to stage web cache poisoning attacks against websites.

Web cache poisoning involves malicious clients forcing content delivery networks (CDN) or web servers to cache malicious content and later serve it to other clients requesting the same resource.

**Double misconfiguration**

Akamai can map various HTTP requests to their corresponding S3 bucket and cache them for later retrieval. Security researcher Tarunkant Gupta discovered that he could trick the Akamai server into caching files from malicious buckets.

“A few months back I encountered a non-exploitable AWS S3 misconfiguration and I was just revisiting it to check if that still exists or not, but this time I wanted to explore all attack possibilities,” he told The Daily Swig. After trying different attack vectors, Gupta ran into a misconfiguration in Akamai’s cache servers that could be leveraged to exploit the S3 bug.

RELATED Akamai WAF bypassed via Spring Boot to trigger RCE

Akamai said creating “a blanket ‘patch’” was “not trivial, as that may have a big negative impact on legitimate internet traffic”, according to a technical writeup from Gupta. In the meantime, Gupta said users can protect themselves by not accepting any headers containing Unicode characters at the Akamai level. 

**Tampering header commands**

To exploit the vulnerability, an attacker must send a web request for a benign file, but modify the header directives to add a header preceded by a hex value (e.g. ) and followed by the malicious S3 address.

If the request results in a cache hit, then the Akamai server will prioritize the header with the Unicode value over the original header and cache the malicious file to serve it to future users who request the same path.

“Because of the S3 misconfiguration, it prioritizes the first header over the target origin and Akamai’s incorrect parsing on the inclusion of Unicode character let me pass exactly what I wanted to the S3 buckets, a malicious host on the first occurrence of the header,” Gupta explained.

**Attacking at scale**

The attack will only work if benign and malign files are stored in S3 buckets located in the same region. The attacker can create S3 buckets in all available regions and upload the malicious file to all of them.

Exploiting the bug would then be a matter of brute-forcing the web cache poisoning attack on the target web resource to see which bucket works.

Gupta tested the attack with an SVG file, which is usually a cached file type and can contain JavaScript code – making it especially dangerous. But the attack can also work with any other file type cached by the server.

Gupta also developed a pair of Python scripts that can find targets stored in S3 buckets and cached by Akamai.

“This issue is very easy to exploit, and one simple cURL can create a malicious cache,” Gupta said. “An automation script was created to exploit at scale. This issue can result in various types of attacks such as XSS, JavaScript injection, open redirection, DoS, spoofing, etc.”

**RFC non-compliance**

Akamai told Gupta that the configuration issue “results from certain customers’ needs to process non-RFC compliant requests for their applications to function correctly, and therefore cloud vendors offering features to support such traffic unless explicitly instructed not to do so.”

Kaan Onarlioglu, senior infosec architect at Akamai, told The Daily Swig: “By default, Akamai edge servers allow certain invalid HTTP headers to pass through, treating them as custom headers.”

Catch up with the latest hacking techniques news and analysis

This feature is necessary to support large volumes of legitimate traffic flows and origin applications that rely on invalid headers to function correctly, he said. However, it could sometimes lead to unexpected interactions between Akamai and origin servers, depending on the origin’s request processing behavior.

“Akamai provides a strict header parsing configuration option to block traffic containing invalid headers, and we strongly urge our customers to utilize it unless that interferes with their operations,” Onarlioglu continued.

According to Onarlioglu, Akamai is currently working on making strict header parsing a default behavior instead of offering an opt-out mechanism for customers. The work is expected to be finalized early in 2023.

Gupta advised web developers to always follow RFC and its recommendations. “Many companies don’t follow them and also don't put any countermeasures around it, which sometimes becomes a serious issue,” he said.

RECOMMENDED Researcher discovers 70 web cache poisoning vulnerabilities, nets $40k in bug bounty rewards

Akamai wrestles with AWS S3 web cache poisoning bug 

Large vendors are commoditizing capabilities that claim to provide absolute security guarantees backed up by formal verification. How significant are these promises?

There is no software without bugs, right? While this is a common sentiment, we make assumptions that rely on the premise that software has no bugs in our day-to-day digital life. We trust identity providers (IDPs) to get authentication right, operating systems to perfectly comply with their specs, and financial transactions to always perform as intended. Even more vividly, we trust software with our physical safety by going on planes, driving a car that actively corrects our adherence to traffic lanes or our distance from the car in front of us, or undergoing certain surgeries. What makes this possible? Or to put it another way, why aren't planes falling out of the sky due to bad software?

Software quality assurance borrows from scientific and engineering tools. One way to ensure and improve software quality is to publicize it and give as many people as possible an incentive to try to break it.

Another is using design patterns or well-architecture frameworks rooted in engineering. For example, while not every software project can be put under the same level of scrutiny as the Linux kernel, which has been under scrutiny for decades, software projects can open source code to invite scrutiny or submit code for audits in hopes to gain some of the security guarantees.

And of course, there's testing. Whether static, dynamic, or real-time, done by the developer or by a dedicated team, testing is a major part of software development. With critical software, testing is usually an entirely separate project handled by a separate team with specific expertise.

Testing is good, but it doesn't claim to be comprehensive. There are no guarantees we found all the bugs because we don't know which bugs we don't know about. Did we already find 99% of Linux kernel bugs out there? 50%? 10%?

**The 'Absolute' Claim**

The research field of formal methods is looking at ways to assure you that there are no bugs in a certain piece of software, such as your stockbroker or certificate authority. The basic idea is to translate software into math, where everything is well-defined, and then create an actual proof that the software works with no bugs. That way, you can be sure that your software is bug-free in the same way you can be sure that every number can be decomposed to a multiplication of prime numbers. (Note that I don't define what a bug is. This will prove to be a problem, as we will later see.)

Formal method techniques have long been used for critical software, but they were extremely compute- and effort-intensive and so applied only to small pieces of software, such as a limited part of chip firmware or an authentication protocol. In recent years, advanced theorem provers like Z3 and Coq have made it possible to apply this technology in a larger context. There are now formally verified programming languages, operating systems, and compilers that are 100% guaranteed to work according to their specifications. Applying these technologies still requires both advanced expertise and a ton of computing power, which make them prohibitively expensive to most organizations.

Major cloud providers are performing formal verification of their fundamental stacks to reach high levels of security assurance. Amazon and Microsoft have dedicated research groups that work with engineering teams to incorporate formal verification methods into critical infrastructure, such as storage or networking. Examples include AWS S3 and EBS and Azure Blockchain. But the really interesting fact is that in the past few years, cloud providers have been trying to commoditize formal verification to sell to their customers.

**Decisively Solving Misconfiguration?**

Last year, AWS released two features that leverage formal verification to address issues that have long plagued their customers, namely network and identity and access management (IAM) misconfigurations. Network access and IAM configurations are complex, even for a single account, and that complexity grows drastically in a large organization with distributed decision-making and governance. AWS addresses it by giving its customers simple controls — such as "S3 buckets should not be exposed to the Internet" or "Internet traffic to EC2 instances must go through a firewall" — and guaranteeing to apply them in every possible configuration scenario.

AWS is not the first to address the misconfiguration problem, even for AWS-specific issues such as open S3 buckets. Cloud security posture management (CSPM) vendors have been addressing this issue for a while now, analyzing virtual port channel (VPC) configuration and IAM roles and identifying cases where privileges are too lax, security features are not properly used, and data can be exposed to the Internet. So what's new?

Well, this is where the absolute guarantee comes in. A CSPM solution works by creating a known-bad or known-good list of misconfigurations, sometimes adding context from your environment, and producing results accordingly. Network and IAM analyzers work by examining every potential IAM or network request and guaranteeing that they will not result in unwanted access according to your specification (such as "no Internet access"). The difference is in the guarantees about false negatives.

While AWS claims that there is no way it has missed anything, CSPM vendors say they are always on the lookout for new misconfigurations to catalog and detect, which is an admission that they did not detect these misconfigurations previously.

**Some Flaws of Formal Verification**

Formal verification is great for finding well-defined issues, such as memory security issues. However, things become difficult when trying to find logical bugs because those require specifying what the code is actually supposed to do, which is exactly what the code itself does.

For one thing, formal verification requires specifying well-defined goals. While some goals, like preventing access to the Internet, seem simple enough, in reality they are not. The AWS IAM analyzer documentation has an entire section defining what "public" means, and it's full of caveats. The guarantees it provides are only as good as the mathematical claims that it has coded.

There's also the question of coverage. AWS analyzers cover only a few major AWS services. If you route traffic into your network through an outbound connection channel, the analyzer wouldn't know. If some service has access to two IAM roles and can combine them to read from a confidential public bucket and write to a public one, the analyzer wouldn't know. Nevertheless, on some well-defined subset of the misconfiguration problem, formal verification provides stronger guarantees than ever before.

Getting back to the relative advantage question posed above, the difference is that the IAM and network analyzer claims that its list of issues detected is comprehensive, while CSPM claims that its list covers every misconfiguration known today. Here's the key question: Should you care?

**Should We Care About Absolute Guarantees?**

Consider the following scenario. You own a CSPM and look at the AWS network and IAM analyzer. Comparing the results of the two, you realize that they've identified the exact same problems. After some effort, you fix every single problem on that list. Relying only on your CSPM, you would feel you are in a good place now and could dedicate security resources elsewhere. By adding AWS analyzers to the mix, you now know — with an AWS guarantee — that you are in a good place. Are these the same results?

Even if we neglect the caveat of formal verification and assume that it catches 100% of issues, measuring the benefits over detection-based services like CSPM would be an exercise for every individual organization with its own security risk appetite. Some would find these absolute guarantees groundbreaking, while others would probably stick to existing controls.

These questions are not unique to CSPM. The same comparisons could be made for SAST/DAST/IAST web application security testing tools and formally verified software, to name one example.

Regardless of individual organization choices, one exciting side effect of this new technology would be an independent way to start measuring security solutions' false negative rates, pushing vendors to be better and providing them with clear evidence where they need to improve. This in and of itself is a tremendous contribution to the cybersecurity industry.

Are 100% Security Guarantees Possible?

Softr v2.0 was discovered to be vulnerable to HTML injection via the Name field of the Account page.

**Build custom apps for your business, as easy as lego**

|

Turn your Airtable or Google Sheets into client portals, partner apps or internal tools.

**Trusted by 80,000+ teams worldwide**

**Create apps powered by your data**

**Client Portals**

Create client or employee portals with self-service account creation and secure access to content.

**Internal Tools**

Enable your team to create internal apps like employee directories, CRM, and company wikis, in minutes.

**Marketplaces**

Create two sided marketplaces like Airbnb, Upwork and the like. Sell services, goods, pay securely with Stripe and run your entire business from one tool.

**Online Communities**

Supercharge your community and bring them together in one platform, with memberships, free and premium content. Share resources, sell courses, connect with each other and more.

**Resource Directories**

Curate resources of any kind and let users search, filter, and explore. Launch online courses, company wikis or upvoting sites directly from Airtable.

**Websites**

Quickly create multi-page marketing sites or high-converting landing pages. Add your custom domain for free.

**Softr is the easiest, fastest way to build a professional web app on Airtable. Zero learning curve.**

**80,000+ companies and creators use Softr**

I had already tried other tools, so when I started using Softr, it was clear immediately that the capabilities were beyond what I found elsewhere.

**Yohei Nakajima**

General Partner, Untapped Capital

Softr helps you take action on your ideas quickly by allowing you to leverage your Airtable data and build powerful websites and web apps. I was blown away by how user-friendly and well-documented the entire product was! I was able to create an app within hours without any external help.

**Karthik Puvvada (KP)**

Program Director, On Deck No-Code Fellowship

Softr’s ease and speed of use is it’s standout characteristic. No tool is faster to create with. Although there is limited design customizability, this should be viewed as a strength of Softr as it acts as a positive restraint to help you ship things more quickly than you ordinarily would.

**Max Haining**

Founder, 100DaysOfNoCode

They say that if you can’t explain it in a simple way, you don’t understand it well enough. I say the same thing about any software. If you can’t figure it out in the first 10 min by yourself without any tutorial, it’s probably not for you. Since the first moment we discovered Softr, we started the work.

**Akiki Rachid**

COO, Bookzdoctr Inc

It took me one day to build the product, learn the integrations, and see how the customer service acts. I was completely flashed that it is so easy, and that everything is working really well. So, I quickly decided 3 weeks later to set up our main page and transferred it to Softr.

**Sabine Wildemann**

Co-Founder, KidsCircle

I have been impressed with the flexibility of Softr. The ability to pull data from different Airtable bases into different blocks and display them on one page was one of the main reasons I chose Softr.

**Dan Smith**

Director, DS Automotive

As a small business, we needed to use a tool that could grow with us, and we feel that this is what Softr offers us. After wasting time and money trying every web builder under the sun, Softr came to save the day. We cannot recommend this platform enough – it's perfect, easy to use even for a non-technical person like me.

**Lucia Borraccino**

Founder, Nanny Network

I like the diversity of templates that are available and the thoughtfulness that has been taken in making the building process as simple as possible for non-coders.

**Kwaku Dapaah-Danquah**

Entrepreneurship Manager, YSYS

I used Softr to build the MVP for my company www.tallsize.com.When I discovered how easy it was to use Softr to create a frontend interface for our users, my mind was blown!!! It was so easy to set up that I literally launched my site in a single weekend. Their support team was incredible throughout this journey and the ability to customize everything the way I wanted was very intuitive and easy to accomplish.

**Nicole Murphy**

Founder, Tall Size

I have been using Softr for a few months now, and the list of new features & improvements is PHENOMENAL. A no-brainer pick for now and a really good bet for the future!

**Nic Touron**

Founder, ToolMeUp

With Softr, I’m able to create beautifully intuitive and responsive front-ends that integrate directly with Airtable and Stripe. Softr allows me to create and iterate at least twice as fast as traditional web platforms.

**Connor Gustafson**

Founder, LendingApp

Softr is THE no-code website builder to use. From SEO and site responsiveness to database backends and customer support, Softr is the deal of the century!

**Patrick Ford**

Founder, Adastacks

**Simple, yet powerful**

**As simple as building lego**

Start from a template or from 100+ pre-built blocks and customize any element on the page. No design or coding skills needed.

**Build platforms, not just sites**

Turn your Airtable data into a full-stack web-app with out-of-the-box memberships, payments and business logic, all in one place.

**Turn into a mobile app, with one click**

Immediately made available on both Apple and Android devices, without the extra effort.

**Start now, go live today**

Don't spend hours learning new tools. Softr is the quickest way to put a product in the hands of your customers. Changing things later is easy and instant.

**This website is built on Softr**

Join 80,000+ companies already using Softr.

**Powerful pre-built functionality out of the box**

Softr does the heavy lifting of all technical work for you, so you can focus on your business.

**Secure user accounts**

Keep yours and your customers' data safe with server-side password protection.

**Free custom domain**

Our free tier includes hosting on custom domains. No credit card required.

**Team Collaboration**

Invite your teammates to manage the application and set granular permissions

**Easy online payments**

Enable one-off purchases or subscriptions in seconds.

**Optimized for SEO**

Pages built with Softr are automatically indexed by search engines.

**Performant, safe, and scalable**

Enjoy Amazon AWS-powered security and performance.

**Integrate with the tools you love**

Seamlessly integrate your Softr app with the modern and trusted tools of your workflow like Zapier, Google Analytics, Stripe, Hotjar, Mailchimp and more.

**Run your business on Softr + Airtable**

**For Companies**

Explore how SMBs and startups use Softr to manage and grow their business.

LEARN MORE

**For Creators**

Learn how entrepreneurs of all sizes are starting new ventures in days with Softr.

LEARN MORE

**For Non-Profits**

Organizations of all kinds can run their operations online, saving time and money.

**Learn about companies and creators using Softr**

Tag

#aws