Tech Insight report co-produced by Black Hat, Dark Reading, and Omdia examines how cloud security is evolving in a rapid race to beat threat actors to the (cloud) breach.

Cloud services are facing their first real security litmus test since the pandemic's 2020 arrival accelerated cloud adoption. A new category of security flaws and risks in cloud services since has emerged, raising the stakes for providers and adopters alike.

Thankfully cyberattacks targeting the cloud remain rare so far, with mainly cryptojacking campaigns exploiting misconfigured cloud-account settings in order to siphon computing power for monetization. But with security researchers now regularly unearthing new security flaws and weak default security settings in some of the biggest cloud provider services, it's only a matter of time when the attacks become more disruptive and destructive.

Cloud-specific security tools such as cloud workload protection plat­forms (CWPP) for detection and response and cloud security posture management (CSPM) for proactive security are emerging and maturing, as are the security features and functions cloud providers such as Amazon and Microsoft now include in their services.

A newly published report co-authored by Black Hat, Dark Reading, and Omdia, called "The Promise and Reality of Cloud Security," examines the key challenges — and opportunities — for securing cloud services and accounts.

Read the full (free) report, which draws from Black Hat research, Dark Reading reporting, and Omdia research and analysis.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

New Brand of Security Threats Surface in the Cloud

An iframe that was not permitted to run scripts could do so if the user clicked on a <code>javascript:</code> link. This vulnerability affects Firefox < 102, Firefox ESR < 91.11, Thunderbird < 102, and Thunderbird < 91.11.

**Mozilla Foundation Security Advisory 2022-24**

Announced

June 28, 2022

Impact

high

Products

Firefox

Fixed in

*   Firefox 102

_Note_: While Bug 1771084 does not represent a specific vulnerability that was fixed, we recommend anyone rebasing patches to include it. 102 branch: Patch 1 and 2. 91 Branch: Patch 1 and 2 (Despite saying Parts 2 and 3, there is no Part 1)

**#CVE-2022-34479: A popup window could be resized in a way to overlay the address bar with web content**

Reporter

Irvan Kurniawan

Impact

high

**Description**

A malicious website that could create a popup could have resized the popup to overlay the address bar with its own content, resulting in potential user confusion or spoofing attacks.  
_This bug only affects Firefox for Linux. Other operating systems are unaffected._

**References**

*   Bug 1745595

**#CVE-2022-34470: Use-after-free in nsSHistory**

Reporter

Armin Ebert

Impact

high

**Description**

Session history navigations may have led to a use-after-free and potentially exploitable crash.

**References**

*   Bug 1765951

**#CVE-2022-34468: CSP sandbox header without \`allow-scripts\` can be bypassed via retargeted javascript: URI**

Reporter

Armin Ebert

Impact

high

**Description**

An iframe that was not permitted to run scripts could do so if the user clicked on a javascript: link.

**References**

*   Bug 1768537

**#CVE-2022-34482: Drag and drop of malicious image could have led to malicious executable and potential code execution**

Reporter

Attila Suszter

Impact

moderate

**Description**

An attacker who could have convinced a user to drag and drop an image to a filesystem could have manipulated the resulting filename to contain an executable extension, and by extension potentially tricked the user into executing malicious code. While very similar, this is a separate issue from CVE-2022-34483.

**References**

*   Bug 845880

**#CVE-2022-34483: Drag and drop of malicious image could have led to malicious executable and potential code execution**

Reporter

Eduardo Braun Prado

Impact

moderate

**Description**

An attacker who could have convinced a user to drag and drop an image to a filesystem could have manipulated the resulting filename to contain an executable extension, and by extension potentially tricked the user into executing malicious code. While very similar, this is a separate issue from CVE-2022-34482.

**References**

*   Bug 1335845

**#CVE-2022-34476: ASN.1 parser could have been tricked into accepting malformed ASN.1**

Reporter

Gustavo Grieco

Impact

moderate

**Description**

ASN.1 parsing of an indefinite SEQUENCE inside an indefinite GROUP could have resulted in the parser accepting malformed ASN.1.

**References**

*   Bug 1387919

**#CVE-2022-34481: Potential integer overflow in ReplaceElementsAt**

Reporter

Ronald Crane

Impact

moderate

**Description**

In the nsTArray_Impl::ReplaceElementsAt() function, an integer overflow could have occurred when the number of elements to replace was too large for the container.

**References**

*   Bug 1497246
*   Bug 1483699

**#CVE-2022-34474: Sandboxed iframes could redirect to external schemes**

Reporter

Amazon Malvertising Team

Impact

moderate

**Description**

Even when an iframe was sandboxed with allow-top-navigation-by-user-activation, if it received a redirect header to an external protocol the browser would process the redirect and prompt the user as appropriate.

**References**

*   Bug 1677138

**#CVE-2022-34469: TLS certificate errors on HSTS-protected domains could be bypassed by the user on Firefox for Android**

Reporter

Peter Gerber

Impact

moderate

**Description**

When a TLS Certificate error occurs on a domain protected by the HSTS header, the browser should not allow the user to bypass the certificate error. On Firefox for Android, the user was presented with the option to bypass the error; this could only have been done by the user explicitly.  
_This bug only affects Firefox for Android. Other operating systems are unaffected._

**References**

*   Bug 1721220

**#CVE-2022-34471: Compromised server could trick a browser into an addon downgrade**

Reporter

Rob Wu

Impact

moderate

**Description**

When downloading an update for an addon, the downloaded addon update's version was not verified to match the version selected from the manifest. If the manifest had been tampered with on the server, an attacker could trick the browser into downgrading the addon to a prior version.

**References**

*   Bug 1766047

**#CVE-2022-34472: Unavailable PAC file resulted in OCSP requests being blocked**

Reporter

Laurent Bigonville

Impact

moderate

**Description**

If there was a PAC URL set and the server that hosts the PAC was not reachable, OCSP requests would have been blocked, resulting in incorrect error pages being shown.

**References**

*   Bug 1770123

**#CVE-2022-34478: Microsoft protocols can be attacked if a user accepts a prompt**

Reporter

Gijs

Impact

moderate

**Description**

The ms-msdt, search, and search-ms protocols deliver content to Microsoft applications, bypassing the browser, when a user accepts a prompt. These applications have had known vulnerabilities, exploited in the wild (although we know of none exploited through Firefox), so in this release Firefox has blocked these protocols from prompting the user to open them.  
_This bug only affects Firefox on Windows. Other operating systems are unaffected._

**References**

*   Bug 1773717

**#CVE-2022-2200: Undesired attributes could be set as part of prototype pollution**

Reporter

Manfred Paul via Trend Micro's Zero Day Initiative

Impact

moderate

**Description**

If an object prototype was corrupted by an attacker, they would have been able to set undesired attributes on a JavaScript object, leading to privileged code execution.

**References**

*   Bug 1771381

**#CVE-2022-34480: Free of uninitialized pointer in lg\_init**

Reporter

Ronald Crane

Impact

low

**Description**

Within the lg_init() function, if several allocations succeed but then one fails, an uninitialized pointer would have been freed despite never being allocated.

**References**

*   Bug 1454072

**#CVE-2022-34477: MediaError message property leaked information on cross-origin same-site pages**

Reporter

jannis

Impact

low

**Description**

The MediaError message property should be consistent to avoid leaking information about cross-origin resources; however for a same-site cross-origin resource, the message could have leaked information enabling XS-Leaks attacks.

**References**

*   Bug 1731614

**#CVE-2022-34475: HTML Sanitizer could have been bypassed via same-origin script via use tags**

Reporter

Gareth Heyes

Impact

low

**Description**

SVG <use> tags that referenced a same-origin document could have resulted in script execution if attacker input was sanitized via the HTML Sanitizer API. This would have required the attacker to reference a same-origin JavaScript file containing the script to be executed.

**References**

*   Bug 1757210

**#CVE-2022-34473: HTML Sanitizer could have been bypassed via use tags**

Reporter

Armin Ebert

Impact

low

**Description**

The HTML Sanitizer should have sanitized the href attribute of SVG <use> tags; however it incorrectly did not sanitize xlink:href attributes.

**References**

*   Bug 1770888

**#CVE-2022-34484: Memory safety bugs fixed in Firefox 102 and Firefox ESR 91.11**

Reporter

Mozilla developers and community

Impact

high

**Description**

The Mozilla Fuzzing Team reported potential vulnerabilities present in Firefox 101 and Firefox ESR 91.10. Some of these bugs showed evidence of JavaScript prototype or memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code.

**References**

*   Memory safety bugs fixed in Firefox 102 and Firefox ESR 91.11

**#CVE-2022-34485: Memory safety bugs fixed in Firefox 102**

Reporter

Mozilla developers and community

Impact

moderate

**Description**

Mozilla developers Bryce Seager van Dyk and the Mozilla Fuzzing Team reported potential vulnerabilities present in Firefox 101. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code.

**References**

*   Memory safety bugs fixed in Firefox 102

CVE-2022-34468: Security Vulnerabilities fixed in Firefox 102

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

Categories: News
Tags: lego

Tags:  bricklink

Tags:  cross site scripting

Tags:  bug

Tags:  flaw

We take a look at how Lego's Bricklink service was potentially vulnerable to certain types of XSS attack.



(Read more...)




The post Lego's Bricklink steps on cross site scripting blocks appeared first on Malwarebytes Labs.

If you build it, they will come. In Lego’s case, they built it and certain security flaws meant someone could have taken it all apart.

PCMag reports that flaws in Lego’s Bricklink service meant that it was open to potential data leakage or even account hijacking. Those flaws, now addressed, potentially impacted users of the Bricklink portal. If you’re unfamiliar with the site, it’s the biggest official marketplace for Lego bricks in the world, with a million or so registered users. That’s a whole lot of Lego.

If there’s ever been an incredibly obscure or hard to find piece you needed for that cool Lego project you’ve been working on, there’s a good chance you’d have found what you were looking for.

What researchers found while looking at user input fields was a way to build out some cross-site scripting (XSS) issues. XSS is a type of injection attack, where vulnerable web applications are exploited in ways which allows for malicious script to be injected into the page. Shall we take a look?

**Building a path to sanitation**

According to Salt Security, the web server wasn’t sanitising user input correctly which led to code injection in the rendered web page. They were able to inject and execute JavaScript code as a result.

From here, they were able to chain the above technique to a payload which would read code on the page containing the session ID value and send it to their own server. The unprotected session ID tagged onto the XSS could result in a full account takeover, along with access to data related to the account. This would include shipping address, orders, message history, and email address.  As the researchers point out, this is a bit limiting as it requires some level of victim interaction to pull off successfully.

**When your “most wanted” is an external entity attack**

The second issue was something which would require no victim interaction to achieve. BrickLink allows users to populate a wanted list page. Desperate for that rare leg from the 1970s, or a piece of a treasure island from the 80s? No problem, upload the data as Extensible Markup Language (an XML file) and take it from there.

Once you hit the continue button, your parts magically appear in readable format, complete with an image of the desired item, and onto your wanted list it goes (think “Amazon wish list”, but for Lego).

The researchers were able to make use of an XML external entity (XXE) attack, which can interfere with regular processing of XML data. Their testing allowed them to pull up the contents of the /etc/passwd file, and could have resulted in Server Side Request Forgery attacks (SSRF). SSRF is very bad, because it can give attackers the ability to fool a server into granting access to places which would not otherwise be available. SSRF issues are unfortunately common, and need to be acted upon quickly.

**Disclosure and response**

These vulnerabilities were discovered on October 18, with technical details disclosed on October 23. Although the Lego security team confirmed the disclosure on the 25th, they went on to say that internal policy is not to comment as to whether specific issues have been fixed. For the Salt Security team’s part, they have confirmed through their own testing on November 10 that the issues appear to have been addressed.

Your bricks, for now, remain standing.

**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.

Lego's Bricklink steps on cross site scripting blocks

Feeling creative? Submit your caption and our panel of experts will reward the winner with a $25 Amazon gift card.

What secrets might be released with a quick peck under the combination lock? For that we need a cybersecurity-related caption. Here are four convenient ways to submit your ideas before the Jan. 11, 2023, deadline.

*   Email _\[email protected\]_ with the subject line "Dark Reading December Toon."
*   Via social media: Twitter, Facebook, and LinkedIn. (If you win, we'll respond to you on the same platform, requesting your email address_._)

**Last Month's Winner**

We had many excellent caption contenders for last month's "Fall Cleanup" contest. (Thanks to all who participated.) But since we had to pick a favorite (below), congratulations go to Dark Reading reader "Rita." A $25 gift card is on the way.

    

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Name That Toon: Kiss and Tell

The open source container tool is quite popular among developers — and threat actors. Here are a few ways DevOps teams can take control.

_Editor's note: For more about the kinds of vulnerabilities Kubernetes presents and how to address them, read our_ _companion article_ _in The Edge._

Since its initial release in 2014, Kubernetes (aka K8s) has become the standard open source container tool for managing software applications. Kubernetes is cost-effective, offers autoscaling, and can run on any infrastructure. Its benefits are why 85% of IT leaders consider Kubernetes "extremely important" to cloud-native strategies. On top of this, 61% of people use Kubernetes to manage their computer application deployment.

Funso Richard, information security officer at Ensemble, tells Dark Reading that "forward-thinking organizations understand the importance of leveraging containerized microservices to develop scalable and reliable applications as an essential digital transformation strategy" — and Kubernetes has become the leading tool used to achieve this strategy, he adds.

However, Kubernetes also comes with security challenges: It's susceptible to data theft, computational power theft, and denial-of-service (DoS) attacks. Kubernetes' public components (such as kubelets and API authentication) are widely exploited. And threat actors target infrastructure misconfiguration, unpatched software programs, and poor login credentials to gain unauthorized entry to Kubernetes. The vulnerabilities are also widespread. According to Red Hat's "2022 State of Kubernetes" security report, 93% of Kubernetes users experienced at least one security incident in the past 12 months.

As DevOps teams continue to grapple with rising Kubernetes security mishaps, here are a few ways to stay ahead of attackers and keep cloud-native environments secure.

**Securing Kubernetes With Tools**

Kubernetes' security vulnerability affects its efficiency. For instance, concerns over Kubernetes security caused developers to delay application rollouts in 2022, according to Red Hat. Although Kubernetes provides several benefits in application development and container orchestration, says Richard, inadequate security controls expose the open source tool to serious security concerns like misconfiguration, privilege abuse, data exfiltration, credential compromise, exploited public-facing components, and API vulnerabilities. To address these, several Kubernetes security tools have sprung up, including Kubescape, Kube-bench, Kubeaudit, Kube-hunter, and Kyverno.

Kubescape is an open source security platform from ARMO to protect Kubernetes clusters with capabilities such as risk analysis, security compliance, misconfiguration scanning, CI/CD security, RBAC visualizer, and vulnerabilities scanning. One thing that sets Kubescape apart is its library of robust capabilities that aligns with MITRE ATT&CK and NSA-CISA frameworks, says Richard.

"As I track Kubernetes security offerings — both commercial and non-commercial offerings — I haven't come across another offering with the same exact components as Kubescape," agrees Fernando Montenegro, senior principal analyst of cybersecurity infrastructure at Omdia.

Kubescape scans clusters, YAML files, and Helm charts for vulnerabilities either directly or via CI/CD integrations. The idea of scanning infrastructure-as-code (IaC) templates is well-popularized across the industry, says Montenegro. Most IaC scanning is done for cloud resources like Amazon's CloudFormation, HashiCorp's Terraform, and others, with Kubernetes scanning being a more specialized use case, he adds.

There are other offerings in the market — like Red Hat's StackRox (acquired in 2021), Tenable's Terrascan, and Palo Alto Networks' Checkov — offering similar capabilities as Kubernetes.

**Implementing Best Security Practices in Kubernetes**

Richard notes that adherence to cybersecurity fundamentals remains the bedrock of any security effort. While Kubescape is undoubtedly a powerful Kubernetes security tool, he believes developers can effectively secure their Kubernetes clusters by following the basics: implementing proper cluster configuration, pod security standards and policy enforcement, network segmentation, vulnerability scanning, periodic policy reviews, and security audits. "Containers should run with the least privileges and only necessary services, while role-based access controls should be in place to manage user access," Richard says.

While Montenegro says there are several Kubernetes best practices for DevOps and DevSecOps teams to follow, he notes that the following practices must be top on their priority list:

*   **Think about security early on:** Collaborate with your developers/architects to work through a proper threat modeling.
*   **Work with embedding security throughout the application lifecycle:** Security is an end-to-end process, from providing on-the-spot security advice and functionality for a developer working through the code in their development environment, through making sure security tests are part and parcel of the integration stages, then adding the necessary runtime protections to monitor workloads in production.
*   **Safely store Kubernetes secrets:** Implement features like proper namespace separation, use of role-based access control (RBAC).

As Kubernetes grows in adoption, IT teams can avoid security pitfalls by using tools like Kubescape and StackRox, as well as following the best security practices for securing their critical Kubernetes assets.

How to Run Kubernetes More Securely

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

Elon Musk claims plane-tracking data is a risky privacy violation. But the world loses a lot if this information disappears—and that's already happening.

I woke up Friday morning to the message I’d been expecting: “Your account, @Justin\_Ling has been locked for violating the Twitter Rules.”

Below was the offending tweet: a link to one of the few websites that provide real-time private jet flight data that “chief twit” Elon Musk, I wrote, “hasn't bullied into suppressing his flight data.”

Musk has accused these flight trackers of providing “basically assassination coordinates.” He has launched a crusade against these apps and anyone who shares them on his recently acquired social media platform. Accounts like mine were locked, while others were banned entirely—from the @ElonJet bot, which shared the location of Musk’s private plane, to reporters who picked up on his campaign. Twitter rules were rewritten on the fly to forbid publishing anyone’s “physical location.”

The chaotic few days prompted the European Union to warn Musk that silencing journalists would likely result in sanctions from EU regulators. US Representative Adam Schiff demanded that Musk reinstate the suspended accounts and explain to Congress why he decided to retaliate against the press in the first place.

As of Monday, following a poll asking users when he should lift the account suspensions, Musk reinstated some—but not all—of those accounts. 

Lost in the chaos is just how successful Musk has been at suppressing that real-time flight data on the internet. In so doing, he’s taking aim at an incredibly valuable source of information—which has helped researchers, journalists, and experts with everything from tracking Russian oligarchs to investigating the fate of missing aircraft to tracking down international hitmen. Musk isn’t the only one trying to keep this type of information out of the public’s hands. 

Both real-time and historical information on Musk’s main private jet—a 2015 Gulfstream G650ER, tail number N628TS—is conspicuously missing from the two main flight-tracking platforms: FlightAware and FlightRadar24.

FlightAware reports that its real-time data on Musk’s jet is unavailable “due to European government data rules,” while its historical data about the plane’s comings and goings was removed “per request from the owner/operator.” Looking up Musk’s jet on FlightRadar24 returns the message: “we could not find data.”

Even smaller tracking platforms, like AirportInfo—the account that led to my Twitter being locked—have taken Musk’s flight information offline.

“The ongoing hullabaloo about the location of Elon Musk’s airplane has caused us to stop displaying his plane at the moment,” says Christian Rommes, an AirportInfo administrator. “Because Musk is threatening legal action, we don’t want to take any risks.”

While Rommes says his office hasn’t heard from Musk’s legal team, they took the step as a precaution. “Don’t mess with the (former) richest man of the world,” he says.

Aircraft operators are required to report detailed information on their flight path to various national regulators, including the Federal Aviation Administration. That data is generally a matter of public record and is published to various websites popular amongst airline enthusiasts. 

Some companies, like FlightAware, augment government data with their own sources of real-time flight information. Other websites, like planespotters.net and airliners.net, allow users to submit photos taken of aircraft as they come and go around the world.

These services have proved incredibly useful for journalists and independent researchers in recent years.

When Malaysian Airlines flight 370 disappeared in 2014, these trackers provided the public with the same data investigators were puzzling over—a flight path that cut straight across Malaysia before stopping abruptly over the South China Sea. Those websites would become critical tools for independent researchers in the years that followed.

Journalists and the general public again turned to these services after Malaysia Airlines flight 17 and Ukrainian International Airlines flight 752 were shot down in 2014 and 2020, respectively. As early reports suggested disaster had struck, these websites showed clearly that the flights were interrupted in mid-air.

But the utility of real-time flight tracking goes far beyond disasters.

In more lighthearted examples, diehard soccer fans have used FlightRadar24 to figure out where prospective trades are heading ahead of a possible signing. In 2015, tens of thousands of football fanatics correctly identified star manager Jurgen Klopp’s private jet as it made its way to Liverpool, preempting the team’s announcement.

The availability of this data has made it possible to track everything from a shipment of US weapons to Ukraine to Nancy Pelosi’s tense visit to Taiwan, in defiance of Chinese warnings.

Some pilots have leaned into this new visibility. One made headlines after drawing a penis in the sky over Florida.

The websites have also contributed to embarrassment for some private jet owners. Thanks to @CelebJets, a bot account set up by 20-year-old programmer Jack Sweeney, who also created @ElonJet, scrutiny over the pace at which the rich and famous galavant around in their CO2\-intensive private planes reached a fever pitch in 2022. Marketing agency Yard calculated just how much environmental damage was caused by these private jet trips—particularly short-haul flights, where driving or taking public transit would take only marginally longer. That report led to a massive public shaming of celebrities like Taylor Swift, whose private jet addiction put 1,184 times more CO2 into the atmosphere than the average person produces in a whole year. 

A single Elon Musk flight from February burned nearly 4.5 tonnes of CO2.

Sweeney’s jet-tracking bots, which scraped that public flight data and sent it directly to Twitter, also published real-time information on Russian oligarchs. That bot helped open source investigators keep tabs on a cohort of the ultra-rich Russians mainly responsible for keeping Vladimir Putin’s regime running amid a costly war against Ukraine.

Investigative outlet Bellingcat recommends FlightRadar24 for open source investigators, and its researchers have relied on the tool to track likely Russian intelligence operatives, understand political tumult in Kazakhstan, follow the Venezuelan government’s semi-secret private jet, and keep tabs on NATO planes as they conduct operations. Other investigative outlets, like the Organized Crime and Corrupting Reporting Project, have similarly leveraged the data to hunt down shady dealings the world over.

But as Musk’s effort to suppress the information has shown, not everyone wants this data to remain public.

For starters, some planes can turn off their transponders, which relay their coordinates to flight regulators. That option is generally not available for private civilian aircraft.

More useful to someone like Musk is the FAA’s Limiting Aircraft Data Displayed list. Introduced by a 2018 act of Congress, it allows private jet owners to block their data from being disseminated by the FAA. A spokesperson for FlightRadar24 confirmed to WIRED that, as they rely primarily on the FAA’s data, they respect the block list.

Not everyone relies on the FAA, however. Planes regularly transmit basic information mid-flight, through Automatic Dependent Surveillance-Broadcast technology (ADS-B). 

ADS-Bexchange, which describes itself as the “world’s largest source of unfiltered flight data,” has continued reporting real-time information on Musk’s Gulfstream using that technology. Sweeney relies on that website for his bots—which have since moved over to Instagram and Mastodon.

“The position data shown by ADSBexchange is available to anyone who can spend $50 on Amazon and put the parts together,” reads a Q&A on its website. “It’s not secret.”

Users on the site’s Discord channel have spent recent days mocking Musk’s attempt to go after this information and have been clear that they do not intend to remove his jet from the platform. “ADSBx does no blocking or hiding for any reason,” one moderator wrote.

Anyone keeping tabs on Musk’s jet would have known that the Twitter CEO was heading to Qatar for the World Cup finale on Sunday. Doha was a key player in Musk’s Twitter takeover. While there, Musk snapped a selfie with a Russian state broadcaster. (Musk has also relied on a Dubai-based financier with ties to Russian oligarchs to finance his $44 billion purchase of the social network.)

Given how much scrutiny this type of flight data has brought on him and his business dealings, perhaps it’s no surprise that Musk has taken some desperate measures to hide this information. He reportedly offered Sweeney $5,000 to take the @ElonJet bot down. Sweeney countered, asking for $50,000—but the pair do not appear to have ever made a deal. Despite vowing to respect Sweeney’s right to publish the information, Musk banned all of his bots and his personal Twitter account earlier this month, while ADS-B’s Twitter account was similarly removed.

Steffan Watkins is a Canadian Osint researcher who has spent years tracking planes and ships using this kind of publicly available data. Last year, he worked with a United Nations panel of experts to identify planes smuggling weapons into Libya.

“Simply put, because flight data is publicly available through many different flight trackers, the public is empowered to fact-check any statement from any source, government or private,” he says. “Unsurprisingly, there are powerful people who don’t want the transparency that provides.”

Knowing more about where government planes and private jets are going to and coming from can yield surprising results. Watkins points out that the CIA’s extraordinary rendition program, which enabled the arbitrary detention and torture of suspected terrorists—many of whom were innocent—was exposed with the help of open source flight data.

“As the CIA kidnapped and flew citizens of other countries to black sites around the world for integration and torture on government-chartered bizjets, they left a trail of data in their wake that was used to unravel the routes used to ship their abductees,” Watkins told WIRED.

More recently, in 2018 researchers used ADS-B data to trace the route that a Saudi kill squad took on its way to murder _Washington Post_ journalist Jamal Khashoggi.

Earlier this year, the Saudi government submitted a proposal to the International Civil Aviation Organization to encrypt and restrict access to this data. “The uncontrolled access to detailed/accurate ADS-B data on the internet raised concerns by aircraft operators and owners on safety, security, and privacy of flights,” the Saudis wrote to the Montreal-headquartered UN body.

“Oh, the country that flies assassins around the world wants to hide aviation info from the public because of ‘security’?” Watkins says. “How quaint.”

A Saudi prince, Alwaleed bin Talal bin Abdulaziz, is the second-largest shareholder in Twitter. The site’s largest owner, Musk, is similarly relying on security concerns as he moves to ban this flight data from his platform.

In announcing the ban on real-time flight data last week, he alleged that a “crazy stalker” followed a car carrying one of his children. “Legal action is being taken against Sweeney & organizations who supported harm to my family,” he tweeted.

The Los Angeles Police Department sees no link between his private jet’s coordinates and the alleged stalking, according to _Washington Post_ reporters Drew Harwell and Taylor Lorenz—two journalists Musk banned on Twitter. A Bellingcat contributor geolocated the incident, which Musk recorded and published to Twitter (possibly in violation of his own rules), to a gas station miles away from the airport and nearly a full day after Musk’s jet had last been in the air.

Seeing how few—if any—of Musk’s critics and online tormentors have air-to-air intercept capabilities, and given that airports continue to be some of the most secure places in modern society, the Tesla owner’s security concerns appear overblown.

“Safety, security, and privacy sound like noble goals, but there isn’t a rash of violent attacks on private planes—or any planes—and no indication there will be,” Watkins says. “Musk’s gripes are almost Musk-specific; few people have a jet they themselves can call on and fly anywhere with on a whim.”

Elon Musk and the Dangers of Censoring Real-Time Flight Trackers

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

Tag

#amazon