Red Hat has issued patches for a bug in an open source Java virtual machine software that opens the door to drive-by localhost attacks. Patch now, as it's easy for cyberattackers to exploit.

A critical remote code execution (RCE) bug in an open source Java virtual machine (JVM) framework threatens enterprise environments by giving attackers an easy way to compromise development teams — thus gaining access to production systems.

That's according to Joseph Beeton, senior application security researcher at Contrast Security, who discovered the vulnerability in Quarkus, a Red Hat-managed, Kubernetes-native Java framework that's optimized for JVMs.

The bug is tracked as CVE-2022-4116 and has been given a rating of 9.8 on the CVSS.

The relatively new Quarkus framework is used as a platform for serverless, cloud, and Kubernetes environments — the last of which is the de facto container management platform for cloud-native environments, and has had numerous security issues of its own.

The Quarkus flaw is present in the framework's Dev UI Config Editor, making it vulnerable to drive-by localhost attacks that could lead to RCE, Beeton wrote in a blog post published Nov. 29. Moreover, "exploiting the vulnerability isn’t difficult, and can be done by a malicious actor without any privileges," he noted in the post.

Beeton discovered the vulnerability some weeks ago while preparing a talk for the recently held DeepSec conference, but says that he waited to disclose his findings until after Red Hat published details of the flaw on its customer support portal Nov. 21. Beeton also published a proof of concept exploit for CVE-2022-4116 in his post.

Patched versions of Quarkus, available now, are 2.14.2.Final and 2.13.5.Final (LTS); anyone using the framework is encouraged to update immediately.

**'Dangerous' Security Flaw**

The vulnerability affects the "quarkus\_dev\_ui" package, according to Red Hat, which means it impacts developers building services using Quarkus, not actual services running in production.

However, it's still dangerous for several reasons — for one because it's fairly easy to exploit, and for another because developers often have direct access to an enterprise's production environment, Beeton tells Dark Reading.

"Developers generally have access to production systems, and even if they don't, they do have the ability to make code changes," he says. "A compromised developer's machine could be leveraged to push malicious code changes to production.”

For example, if a developer running Quarkus locally visits a website with malicious JavaScript, that JavaScript can silently execute code on the developer’s machine, which can lead to all kinds of trouble on any network or assets attached to it.

In enterprise cloud-based environments, developers also often have to code bases, Amazon Web Services keys, server credentials, and other assets, Beeton said in his posting.

"Access to the developer's machine gives an attacker a great deal of scope to pivot to other resources on the network, as well as to modify or to flat-out steal the codebase," he wrote.

**The Bug in a Cloud-Security Context**

The flaw must be understood in the context of cloud-based footprints that have numerous hosted services running in a larger environment, Beeton explained. One misconception about this type of architecture is that "services that are only bound to localhost are not accessible from the outside world," he noted in his post.

"Because of this misplaced belief, developers, for the sake of convenience, will run services they are developing that are configured in a less secure way compared with how they would \[typically\] do it," he wrote.

There's no problem with this scenario in the case of accessing normal JavaScript in a browser and loaded from a nonmalicious domain, he said. In that case, the JavaScript would not be able to make requests to other domains, including localhost, without a preflight request that is used to check the server's Cross-Origin Resource Sharing (CORS) settings. This is a standard check to see if the server allows requests from the domain being accessed.

However, in the case of a certain type of request that does not require a preflight request — called Simple Requests — the flaw comes into play, Beeton said.

"For a Simple Request, the browser makes the request, receives the response, but that data — including the HTTP Status Code — is not returned to JavaScript," he wrote. "It is possible, however, to infer whether the request was successful based on how long it took to return. Within those constraints, it is possible to access localhost and, in certain circumstances, to trigger arbitrary code execution."

**Multiple Ways Developers Can Be Targeted**

If this is the case, threat actors can compromise websites that developers use by injecting malicious JavaScript into ads served on the sites. For an attack on the Quarkus flaw to be successful in this scenario, someone who is running Quarkus in developer mode would have to visit a website containing the malicious JavaScript, Beeton said.

In this way, attackers can access developer code via non preflighted HTTP requests to those services bound to localhost, he explained.

"It just requires that Quarkus is running in developer mode at the same point the browser tab is open," he noted. "No other interaction is required for this vulnerability to be exploited."

Attackers also can exploit the flaw by launching a phishing attack that convinces a developer to open a web browser on a compromised page. "If they happen to be running Quarkus in developer mode, compromising them would merely entail getting them to click the link; the page containing malicious JavaScript will then be loaded, and they would be compromised," Beeton explained.

Other ways the flaw can be exploited are through common misconfigurations in the Spring framework, which provides a comprehensive programming and configuration model for modern Java-based enterprise applications, he said. Alternatively, an attacker can exploit known vulnerabilities to generate an RCE on the developer's machine or on other services on their private network.  

**Potential Impact and Fix**

There are two bits of good news surrounding the status of the flaw, Beeton acknowledged. One is that Red Hat's Quarkus team, as mentioned before, already has issued a fix that requires the Dev UI to check origin headers for "origin : localhost" — which is set by the browser itself and not modifiable by JavaScript — and only accept these requests, he said.

The other reassuring aspect is that Quarkus is a young framework, having been launched in 2019, so it's not likely to be used as extensively as, say, the open-source Spring Boot framework, he said.

And while Quarkus is gaining in popularity, particularly for Kubernetes enthusiasts, "given its ease of use and significantly lighter demand on hardware resources to run and to run applications," it still is not as widely used as Kubernetes itself, Beeton said.

"Therefore, the number of developers affected by this drive-by localhost attack is probably small," he said.

**Squashing the Attack Vector**

Even with the Quarkus flaw fixed, developers using open-source frameworks still should be wary as they develop services via the localhost, as there are likely more vulnerabilities equivalent to CVE-2022-4116 that have yet to be found, Beeton warned.

A solution for the entire attack vector is on the horizon with W3C’s new Private Network Access (PNA) specification, which eventually will be integrated into browsers to squash this mode of exploit altogether, he said.

Currently, however, only the team supporting the Chromium framework — the basis for the Chrome and Edge browsers — is actively working to implement the new spec, Beeton said. In fact, the targeted mid-December release of Chrome 109 should include support for PNA.

Firefox, meanwhile, has PNA support on its backlog, but has not yet scheduled a release date, while plans to add the spec to Safari or Edge remain unclear, though the Chromium update may bode well for its upcoming addition in Edge, he added.

Critical Quarkus Flaw Threatens Cloud Developers With Easy RCE

A malicious Android SMS application found on the Google Play Store has been found to stealthily harvest text messages with the goal of creating accounts on a wide range of platforms like Facebook, Google, and WhatsApp.
The app, named Symoo (com.vanjan.sms), had over 100,000 downloads and functioned as a relay for transmitting messages to a server, which advertises an account creation service.

A malicious Android SMS application found on the Google Play Store has been found to stealthily harvest text messages with the goal of creating accounts on a wide range of platforms like Facebook, Google, and WhatsApp.

The app, named Symoo (com.vanjan.sms), had over 100,000 downloads and functioned as a relay for transmitting messages to a server, which advertises an account creation service.

This is achieved by using the phone numbers associated with the infected devices as a means to gather the one-time password that's typically sent to verify the user when setting up new accounts.

"The malware asks the phone number of the user in the first screen," security researcher Maxime Ingrao, who discovered the malware, said, while also requesting for SMS permissions.

"Then it pretends to load the application but remains all the time on this page, it is to hide the interface of the received SMS and that the user does not see the SMS of subscriptions to the various services."

Some of the major services illegally signed up using the phone numbers include Amazon, Discord, Facebook, Google, Instagram, KakaoTalk, Microsoft, Nike, Telegram, TikTok, Tinder, Viber, and WhatsApp, among others.

Additionally, the data collected by the malware is exfiltrated to a domain named "goomy\[.\]fun," which was previously used in another malicious application called Virtual Number (com.programmatics.virtualnumber) that has since been removed from the Play store.

The app's developer, Walven, has also been linked to another Android app known as ActivationPW - Virtual numbers (com.programmatics.activation) that claims to offer "virtual numbers to receive SMS verification" from more than 200 countries for less than 50 cents.

According to Ingrao, Symoo and ActivationPW represent the two ends of the fraudulent scheme, wherein the phone numbers of the hacked devices that have the former installed are employed to help users buy accounts through the latter.

Google told The Hacker News that the two apps have been removed from the Play Store and that the developer has been banned.

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

This Malicious App Abused Hacked Devices to Create Fake Accounts on Multiple Platforms

A malicious Android SMS application discovered on the Google Play Store has been found to stealthily harvest text messages with the goal of creating accounts on a wide range of platforms like Facebook, Google, and WhatsApp.

The app, named Symoo (com.vanjan.sms), had over 100,000 downloads and functioned as a relay for transmitting messages to a server, which advertises an account creation service.

This is achieved by using the phone numbers associated with the infected devices as a means to gather the one-time password that's typically sent to verify the user when setting up new accounts.

"The malware asks the phone number of the user in the first screen," security researcher Maxime Ingrao, who discovered the malware, said, while also requesting for SMS permissions.

"Then it pretends to load the application but remains all the time on this page, it is to hide the interface of the received SMS and that the user does not see the SMS of subscriptions to the various services."

Some of the major services illegally signed up using the phone numbers include Amazon, Discord, Facebook, Google, Instagram, KakaoTalk, Microsoft, Nike, Telegram, TikTok, Tinder, Viber, and WhatsApp, among others.

Additionally, the data collected by the malware is exfiltrated to a domain named "goomy\[.\]fun," which was previously used in another malicious application called Virtual Number (com.programmatics.virtualnumber) that has since been taken down from the Play Store.

The app's developer, Walven, has also been linked to another Android app known as ActivationPW - Virtual numbers (com.programmatics.activation) that claims to offer "virtual numbers to receive SMS verification" from more than 200 countries for less than 50 cents.

According to Ingrao, Symoo and ActivationPW represent the two ends of the fraudulent scheme, wherein the phone numbers of the hacked devices that have the former installed are employed to help users buy accounts through the latter.

Google told The Hacker News that the two apps have been removed from the Play Store and that the developer has been banned.

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

Expect to see attackers expand their use of current consumer-targeting tactics while exploring new ways to target Internet users — with implications for businesses.

A combination of maturing and emerging consumer-facing cyber threats could add to the many challenges that enterprise security teams will need to contend with in 2023.

Researchers at Kaspersky, looking at how the cyber threat landscape will likely evolve over the next year, expect that threat actors will expand use of many of their current tactics while exploring new avenues for attack via social media, streaming services, and online gaming platforms.

For business admins, the expansion of brands into the world of the metaverse (the theoretical universal and immersive virtual world of the Internet, facilitated by the use of virtual reality and social media) could open them up to attack. And in the era of remote work and bring-your-own-device (BYOD), any consumer threat is potentially an enterprise one, so IT security teams would do well to follow the trends in this space.

**Attacks Using Current Techniques Will Grow...**

The security vendor for example expects that cybercriminals will continue to take advantage of the post-pandemic surge in consumer interest around online streaming services to try to distribute malware, steal data, and execute other malicious activity.

Many of the attacks will target individuals looking for alternate sources for downloading a legitimate streaming app, or a particular episode of a show. Expect to see cybercriminals use widely anticipated titles and streaming service provider names such as Netflix, Hulu, and Amazon Prime Video as lures to get users to download malware or to direct them to phishing sites, according to Kaspersky.

Consumers will also face more gaming subscription fraud and scams that involve online currencies and artifacts. Attackers will primarily target games that use currencies and allow sale of in-game items and boosters because they give threat actors a way to process money obtained from other illegal activities.

In a report earlier this year, Kount, an Equifax-owned fraud protection service, also identified online currencies as offering a plethora of opportunities for adversaries to launder money and carry out payment card fraud. "For example, a fraudster creates a free account for an online multiplayer game then uses stolen credit cards to fill up the account with in-game currency and skins," Kount researchers had noted, adding, "Once the account is loaded, the fraudster sells it on a trading site," for anywhere between several hundreds to several thousands of dollars.

Kaspersky expects that attackers will also try to exploit a continuing shortage in the availability of popular gaming consoles via fake pre-sale offers as well as fraudulent giveaways and discounts from online stores purporting to sell hard-to-find consoles.

**...Even as Threat Actors Explore New Attack Avenues**

Meanwhile, the metaverse, online education platforms, and certain categories of health-related apps will all become new avenues for attack in 2023, Kaspersky said.

Privacy will emerge as a major concern in the metaverse, Kaspersky predicted. "As the metaverse experience is universal and does not obey regional data protection laws, such as GDPR, this might create complex conflicts between the requirements of the regulations regarding data breach notification," Kaspersky said.

Others have also expressed concern over the increased amount of personal information that will be collected in fully immersive environments via VR headsets and their collection of cameras, microphones, and motion trackers. Many expect the data will reveal a lot about a user's location, appearance, and other private information while also enabling attackers to carry out more sophisticated phishing and social engineering scams.

At least some of the attacks in virtual reality and augmented reality environments will involve virtual abuse and sexual assault — such as that involving cases of avatar rape, Kaspersky said.

The security vendor pointed to an incident where an avatar associated with a researcher at a nonprofit advocacy group was raped on a metaverse platform owned by Meta as one example of the kind of issues consumers can increasingly run into.

Despite efforts by technology companies to build protection mechanisms into metaverses, "virtual abuse and sexual assault will spill over into metaverses," Kaspersky said. "As there are no specific regulation or moderation rules, this scary trend is likely to follow us into 2023."

"The metaverse represents an area where consumer threats will be different from years past," says Anna Larkina, a security expert at Kaspersky. "Fake, malicious VR and AR apps, as well as privacy risks and potential abuse associated with this new frontier, will account for threats we haven't necessarily seen before," she says.

Certain kinds of apps — such as those related to meditation or those where a consumer might offer a hint of their current emotional state — could become another new attack avenue, Larkina says.

"It is easy enough to imagine a variety of applications for meditation, in which you indicate your current state/emotions, and they select the appropriate course for you," she explains. "Such data can easily be collected and stored in order to track the state of the user and offer them suitable meditation practices." An attacker that gains access to such data could execute successful spear-phishing and social engineering scams in a highly targeted manner, she notes.

Attacks targeting consumers should matter to enterprise security teams because attacks on companies quite often involve the human factor, Larkina says. "If the system is technically secure enough, then you can get inside the system by 'hacking' employees of the company."

The Metaverse Could Become a Top Avenue for Cyberattacks in 2023

The enterprise's shift to the cloud means digital forensics investigators have had to adopt new remote techniques and develop custom tools to uncover and process evidence off compromised devices.

With more organizations moving to the cloud for storage, applications, and processing, digital forensics investigators increasingly require new tools and techniques capable of conducting investigations on systems where they have no physical access.

Gone, for the most part, are the days when the forensics investigator could pop out the hard drive of an on-premises server for a forensic image and simply analyze it for clues on what happened. Hands-on evaluations of physical evidence, formerly the norm in forensic investigations, are now the exception. Today’s cloud-based network could be located almost anywhere — for European Union cloud infrastructures, servers generally have to be in the same country as where the data was created, but that’s as specific as the law gets. For the most part, investigators have no direct access to the servers.

Instead, companies need to work with their cloud providers in advance to articulate clearly what access they can have before an event occurs, says Thomas Brittain, former managing director of cyber risk at Kroll who recently joined Amazon Web Services as a security leader for cloud response.

For example, ask the cloud provider up front about any limitations during an investigation, Brittain recommends. Questions include: What logging or log sources are available from each of your cloud vendors? How do you ensure that your personnel have the training and the understanding to do an investigation in that cloud environment?

Considering that investigators will not have physical access to compromised disk drives, enterprises need to ensure ahead of time that the investigators will have the ability to obtain a forensic image of the hard disk even without having actual physical access. That may mean the provider’s staff would need to create and provide the image to the investigators, or the provider would allow the investigators virtual access to the compromised devices.

**Cloud-Ready Forensics Tools**

New digital forensics tools and techniques are necessary to uncover electronic evidence for processing into actionable intelligence for cloud-based data breaches, ransomware attacks, and other cases of malfeasance.-

Because there are no standardized tools designed to meet every cloud vendors’ network needs, many forensics teams develop custom applications. But there is still a problem. “It's insane, trying to figure out standardized training, there is no, there are no standardized tools,” Brittain says.

“We've had to adapt from more of a forensic standpoint to more of a live-by-instant-response in triage,” concurs Aaron Crawford, senior security consultant with NCC Group’s North America Incident Response. “The lines between triage and forensics have absolutely blurred with the introduction of the cloud. It's even more complicated because you have several flavors of clouds out there and providers such as Tencent, Google, Amazon, and Microsoft — the primary Big Four out there.”

Crawford also acknowledges the lack of industry-standard tools. “We've had to become our own tool smiths now. We've had to write our own tools \[and\] create our own custom solutions to address a lot of these issues to help relieve the burden for our clients,” he says. “One of the biggest things that's changed is that immediacy for information and updates is absolutely critical. And that's because the threat landscape changed. The threat landscape got significantly more malicious, and the repercussions are even greater than they were before.”

While forensics teams are creating tools for the various environments, they also need to ensure that their tools will interoperate with existing security tools. Custom tools need to be “sustainable, explainable, \[and\] repeatable. If I go to court as an expert witness, I have to make sure that those tools are repeatable, and you can understand them, and someone else other than me can use them.”

Wayne Johnson, director of Global Cyber Incident Response and leader of the forensics practice at Protiviti, also sees challenges and possibilities with custom forensic tools. “From an interoperability perspective, I think that's incumbent on those that are that are making those one-off tools, \[that\] as the different coding languages change, as the different coding capabilities increase, the digital forensics domain has to be able to move with them right and be able to understand those," he says.

“Even with traditional architectures that are that are on-prem, there are many organizations that still have their own custom code and custom applications. So be those in the cloud or on prem., the same concept applies.”

**Soliciting Board Support**

As the attack surface grows, in part due to the explosion of internet of things (IoT) devices, cybersecurity experts need a place at the table with the board of directors and general counsels, Johnson notes. Ultimately, combining the digital forensics capabilities with incident response is “an area where we've really seen the board's taking notice and realizing that there's definitely a conversation there.”

The added benefit to having a cyber-savvy board member is to help the other board members “understand and interpret what’s coming from the CISO and the CIO.” The addition of cybersecurity experts on the board, combined with a cyber-knowledgeable general counsel, will further bolster the board’s understand on what cybersecurity and forensics can do to protect corporate assets.

“I think we're seeing, we're seeing a much more sophisticated and cyber-savvy boards starting to emerge as you start looking across various industries,” Johnson says.

How the Cloud Changed Digital Forensics Investigations

The /device/acceptBind end-point for Ourphoto App version 1.4.1 does not require authentication or authorization. The user_token header is not implemented or present on this end-point. An attacker can send a request to bind their account to any users picture frame, then send a POST request to accept their own bind request, without the end-users approval or interaction.

CVE-2022-24190: Automating Unsolicited Richard Pics; Pwning 60,000 Digital Picture Frames

BYOK was envisioned to reduce the risk of using a cloud service provider processing sensitive data, yet there are several deficiencies.

Let’s start with some basics: Your data can, and should, be encrypted at rest and in motion.

Data can be encrypted on the client side or on the server side. In the security realm, we have well-known best practices, which include defense in depth (i.e., not relying on a single security protective measure), and security by obscurity, which really isn’t security.

Here's what the cloud industry is doing, along with some underlying gaps. Most cloud service providers (CSPs) offer bring your own key (BYOK) in one way or another. Amazon Web Services, for instance, supports the following key management service (KMS) options:

*   **KMS only:** Customer-managed keys (CMKs) stored in the KMS.

*   **KMS with customer key store and CMK:** Again, managed by the customer and stored in the cloud hardware security module (HSM ).

*   **KMS with third-party HSM:** Customer-provided KMS with a direct connection to the KMS.

The keys are retained in the volatile KMS memory, meaning once the data encryption keys (DEKs) are decrypted, they are accessible within the CSP environment without requiring the key encrypting key (KEK) for each decryption or encryption.

In all implementation options listed, the data encryption keys are generated by the CSP's KMS and may or may not be exportable. The DEK is used to encrypt defined scopes of data (e.g., per bucket, day, file, etc.) and these DEKs are encrypted with the KEK.

**BYOK Benefits and Risks**

BYOK is meant to provide cloud customers more control over their hosted data. In reality, when BYOK is used, it actually works more like share your own key (SYOK), since once the key is provided to the CSP, customers have no control over the key use. The only benefit of SYOK, in my view, is ensuring the key randomness if you don't trust their random number generator. Otherwise, you may as well let the CSP generate the key.

BYOK is also offered by some CSPs in another model and connects to the customer’s hardware, which stores and controls the KEK. There are several outstanding issues with this model.

The DEKs may still be accessible to the service provider, purposely or otherwise, in addition to a malicious actor capable of succeeding in breaching the CSP's protective measures technically, or via social engineering, thus gaining access to the DEKs, whether in memory, cache, log files, or a malicious codebase. Retaining the KEK in memory is a double-edged sword, since you're effectively performing SYOK for better performance. But then why not just perform SYOK, in that case?

Another issue is that the service provider may not use the customer KEK to secure the DEK. And the CSP architecture, code, and various offerings may have security lapses that allow interception points. Even if DEKs are decrypted on the fly, which isn't usually supported or recommended, a communication issue could bring your business to a grinding halt, preventing existing data from being decrypted and new DEKs from being encrypted.

Trust is also a key element when working with a CSP. Trust should stem from certifications and third-party audits. Reference customers using the CSP for their sensitive data or production may also be an important factor in strengthening this trust. You also have to decide if you trust the CSP's authentication and authorization security. Even with federated security, that doesn't mean there aren't additional authentication and privilege escalation means.

In short: BYOK does not solve the problem nor reduce the risk!

**What Else Can We Do?**

Most CSPs offer customers self-service capabilities to revoke, rotate, and otherwise control the KEK. Enhanced security may be achieved by protecting the data prior to moving or granting the CSP access to it. But this is rarely beneficial and mostly recommended for securing PII/PHI or other strongly regulated data.

The most important factor is to consider all ingress and egress routes, including APIs and file transfers, as well as various privileged access needs. This also extends to authentication and authorization that uses role- or attribute-based access control to ensure non-repudiation, data sanitation, and industry best practices like zero trust**.**

****The Bottom Line****

My goal here is to raise awareness, not to reflect negatively on CSPs. But BYOK, for the most part, is snake oil. It’s often misunderstood as a panacea to working in the cloud while not requiring trust for the CSP.

SYOK is worthless. If you assume the CSP cannot generate sufficiently random keys for the KEK, why rely on it for the DEK? It's important to ensure there’s a well-designed security architecture in place that is constantly reassessed, tested, and monitored.

Bring Your Own Key — A Placebo?

Amazon Web Services (AWS) has resolved a cross-tenant vulnerability in its platform that could be weaponized by an attacker to gain unauthorized access to resources.

The issue relates to a confused deputy problem, a type of privilege escalation where a program that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action.

The shortcoming was reported by Datadog to AWS on September 1, 2022, following which a patch was shipped on September 6.

"This attack abuses the AppSync service to assume \[identity and access management\] roles in other AWS accounts, which allows an attacker to pivot into a victim organization and access resources in those accounts," Datadog researcher Nick Frichette said in a report published last week.

In a coordinated disclosure, Amazon said that no customers were affected by the vulnerability and that no customer action is required.

It described it as a "case-sensitivity parsing issue within AWS AppSync, which could potentially be used to bypass the service's cross-account role usage validations and take action as the service across customer accounts."

AWS AppSync offers developers GraphQL APIs to retrieve or modify data from multiple data sources as well as automatically sync data between mobile and web applications and the cloud.

The service can also be used to integrate with other AWS services through specific roles designed to perform the necessary API calls with the required IAM permissions.

While AWS does have safeguards in place to prevent AppSync from assuming arbitrary roles by validating the role's unique Amazon Resource Name (ARN), the problem stems from the fact that the check could be trivially bypassed by passing the "serviceRoleArn" parameter in a lower case.

In getting around the ARN validation, the issue could be exploited to provide the identifier of a role in a different AWS account and interact with any resource.

"This vulnerability in AWS AppSync allowed attackers to cross account boundaries and execute AWS API calls in victim accounts via IAM roles that trusted the AppSync service," Frichette said.

"By using this method, attackers could breach organizations that used AppSync and gain access to resources associated with those roles."

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

Researchers Detail AppSync Cross-Tenant Vulnerability in Amazon Web Services

Amazon Web Services (AWS) has resolved a cross-tenant vulnerability in its platform that could be weaponized by an attacker to gain unauthorized access to resources.
The issue relates to a confused deputy problem, a type of privilege escalation where a program that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action.
The shortcoming was reported

Amazon Web Services (AWS) has resolved a cross-tenant vulnerability in its platform that could be weaponized by an attacker to gain unauthorized access to resources.

The issue relates to a confused deputy problem, a type of privilege escalation where a program that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action.

The shortcoming was reported by Datadog to AWS on September 1, 2022, following which a patch was shipped on September 6.

"This attack abuses the AppSync service to assume \[identity and access management\] roles in other AWS accounts, which allows an attacker to pivot into a victim organization and access resources in those accounts," Datadog researcher Nick Frichette said in a report published last week.

In a coordinated disclosure, Amazon said that no customers were affected by the vulnerability and that no customer action is required.

It described it as a "case-sensitivity parsing issue within AWS AppSync, which could potentially be used to bypass the service's cross-account role usage validations and take action as the service across customer accounts."

AWS AppSync offers developers GraphQL APIs to retrieve or modify data from multiple data sources as well as automatically sync data between mobile and web applications and the cloud.

The service can also be used to integrate with other AWS services through specific roles designed to perform the necessary API calls with the required IAM permissions.

While AWS does have safeguards in place to prevent AppSync from assuming arbitrary roles by validating the role's Amazon Resource Name (ARN), the problem stems from the fact that the check could be trivially bypassed by passing the "serviceRoleArn" parameter in a lower case.

This behavior could then be exploited to provide the identifier of a role in a different AWS account.

"This vulnerability in AWS AppSync allowed attackers to cross account boundaries and execute AWS API calls in victim accounts via IAM roles that trusted the AppSync service," Frichette said.

"By using this method, attackers could breach organizations that used AppSync and gain access to resources associated with those roles."

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

Researchers also applaud abandonment of customization feature abused by scammers

Adam Bannister 25 November 2022 at 15:00 UTC

Researchers also applaud abandonment of customization feature abused by scammers

A cross-site scripting (XSS) vulnerability in ConnectWise Control, the remote monitoring and management (RMM) platform, offered attackers a powerful attack vector for abusing remote access tools.

Now patched, the stored XSS flaw was disclosed by Guardio Labs, which in July published an analysis of tech support scams, a widespread phenomenon whereby scammers abuse RMM platforms in order to create fake technical support portals and dupe victims into inadvertently installing malware.

Once installed, a remote access tool gives attackers remote control of a victim’s desktop PC or mobile device and, said the report, “is persistent, mostly undetectable, and bypasses almost all regular forms of protection. And in a show of supreme chutzpah, these scammers even manipulate this capability to bypass 2FA protection and take full control of PayPal and bank accounts”.

Read more of the latest hacking tools news

A new technical write-up documenting the ConnectWise XSS explains how attackers could easily register for a free, anonymous email account and submit fake personal details. This would give them a corporate-grade remote access agent and support portal they could customize – with no coding skills needed – to convincingly mimic famous brands.

Scammers could then call and dupe victims by, for example, sending “them a fake invoice for some service they never registered to, urgently referring them to a \[…\] fake refund service portal to enter the ‘invoice’ code (triggering the dedicated silent \[remote access tool\] installation),” wrote Nati Tal, head of Guardio Labs.

**Full control**

The stored XSS bug arose from a lack of sanitation of the resource. “Any code we maliciously inject in between the tags with some manipulations is executed as any other code in the context of the webapp – as if was authored by the official owner of the service,” explains Tal.

“A script executing from this context gives an attacker full control over any element of the webapp, potentially altering any element of the page as well as connection to the backend servers,” contined Tal.

Scammers could also “abuse the hosting service itself – allowing misuse of ConnectWise hosting, identity, and certificate to serve malicious code or gain full access to admin pages even after the trial period is over.”

**‘Bold move’**

ConnectWise recently added a prominent advisory to its remote support service to alert visitors to this social engineering threat. However, Guardio Labs found that attackers could also execute code that removes this warning.

ConnectWise has since responded by removing the customization feature for trial accounts – “a bold move” that would prevent scammers from creating credible-looking Amazon or Microsoft support pages but at the cost of losing a useful feature and commercial differentiator, noted Tal. “They sure took this matter seriously which is very appreciated and will surely help make web browsing safer and the scammers’ life a bit harder,” he said.

“ConnectWise was very responsive and quickly fixed the issue” by adding sanitization to that neutralized Guardio’s exploit code, added the researcher.

Users are advised to update to version v22.6, released on August 8, 2022, or later.

YOU MIGHT ALSO LIKE Google Roulette: Developer console trick can trigger XSS in Chromium browsers

Tag

#amazon