A Server-Side Request Forgery issue in the OpenID Connect Issuer in LemonLDAP::NG before 2.17.1 allows authenticated remote attackers to send GET requests to arbitrary URLs through the request_uri authorization parameter. This is similar to CVE-2020-10770.

This is the _fourth_ post of a series on Single Sign-On and OpenID Connect 1.0 security. In this post, SSRF vulnerabilities that were discovered in popular OIDC implementations (Keycloak (_CVE-2020-10770_) and Amazon Cognito) are explained in detail.

The series consists of following posts:

1.  \[Overview\] Common Issue Patterns and Derived Security Considerations
2.  \[Implementation\] Login Confusion
3.  \[Implementation\] Injection of CRLF sequences
4.  \[Implementation\] **SSRF issues in real-life OIDC implementations**
5.  \[Specification\] Redirect URI Schemes
6.  \[Specification\] Reusable State parameter
7.  \[Responsible Disclosure\] Lessons learned during Responsible Disclosure of OIDC/OAuth related issues

As you can see, we structure this series in an _\[Overview\]_, attacks with concrete examples categorized in _\[Implementation\]_ and _\[Specification\]_, and finally lessons learned during the _\[Responsible Disclosure\]_. Note that this post gives detailed insights into SSRF vulnerabilities that were encountered in real-life OpenID Connect implementations, namely Keycloak and Amazon Cognito.

> **Acknowledgment**
> 
> We made the observations within this advisory during the execution of my master’s thesis on “_Single Sign-On Security: Security Analysis of real-life OpenID Connect Implementations_”. The thesis was written at the chair for network and data security of Ruhr University Bochum.
> 
> The advisors of my thesis are Dr.-Ing. Christian Mainka (@CheariX), Dr.-Ing. Vladislav Mladenov (@v\_mladenov) and Prof. Dr. Jörg Schwenk (@JoergSchwenk). Huge “Thank you” for your continuous support! 🙂

**Introduction**

Server-Side-Request-Forgery (SSRF) is a web application vulnerability. If a malicious entity exploits such a vulnerability, “the attacker can abuse functionality on the server to read or update internal resources”, according to OWASP \[1\].

In the context of OpenID Connect, there are multiple known and previously discussed pitfalls that could enable SSRF vulnerabilities, e.g.:

1.  **request\_uri parameter**: Fett et al. outlined in 2017 that the request_uri allows unauthenticated SSRF \[3, Section III; A. 8)\]. If this parameter is implemented, the Identity Provider is supposed to fetch a resource to obtain the _Request Object_. As a result, if the Identity Provider implements the request_uri parameter, an unauthenticated attacker can launch a SSRF attack against the victim Identity Provider.
    
2.  **Backchannel Communication/Malicious Endpoints**: In an OIDC scenario there is direct Server-to-Server communication. If the OpenID Connect Discovery is used, an Identity Provider can specify its endpoints that are used as the target of requests within genuine OpenID Connect flows. Therefore, a malicious Identity Provider could specify malicious endpoints as its OIDC endpoints during discovery, tricking a benign Service Provider into sending requests to unintended destinations. As pointed out by Mladenov and Mainka in \[2\], if there are no restrictions regarding the internal infrastructure or localhost, such a SSRF vulnerability can be used to “\[…\] (1.) gather information about the Intranet infrastructure of the Client, and (2.) disseminate attack vectors” \[2\].
    

**Example 1: Unauthenticated SSRF in Keycloak (CVE-2020-10770)**

Keycloak is an open-source Identity and Access Management Software (IAM) maintained by Red Hat. In addition, Keycloak is used as a base for Red Hat’s Red Hat Single Sign-On.

**Attacker Model**

The attacker model applied for the following attack is an unauthenticated web attacker model introduced by Barth et al. in 2008 \[4\]. In the following, the malicious entity targets a benign Identity Provider. The attacker’s objective is to gain access to internal hosts that are situated within the internal network; direct access to these hosts is restricted using a firewall.

**Description**

The request_uri is an optional parameter within the OpenID Connect _Authentication Request_ that allows specifying an external URI where the _Request Object_ can be found. Fett et al. discovered in 2017 \[3, Section III; A. 8)\] that, as the Identity Provider is supposed to request the external _Request Object_, this parameter can easily launch an SSRF attack against the Identity Provider.

The OpenID Connect Core specification defines the request_uri as an _Authentication Request_ parameter that “\[…\] enables OpenID Connect requests to be passed by reference, rather than by value” \[3, Section 6\]. If a Service Provider uses this parameter, the Identity Provider retrieves the _Request Object_ “\[…\] from the resource at the specified URL” \[5, Section 6.2\].

The Identity Provider could restrict allowed URLs by allowing the Service Provider to specify the request_uris parameter that is an “\[…\] array of request_uri values \[…\]”, within OpenID Connect Dynamic Client Registration \[6, Section 2\]. If the OpenID Connect Dynamic Client Registration is used, the Identity Provider can require the Service Provider to “\[…\] pre-register request_uri values using the request_uris parameter \[…\]” \[5, Section 6.2\]. Thus, only if OpenID Connect is implemented with the Registration Extension, there is a mitigation hint given by the specification.

Keycloak supports using a _Request Object_ that is referenced externally. The “Fine Grained OpenID Connect Configuration” for a specific client allows specifying the following values for the option “Request Object Required”:

*   Not required (default)
*   request or request_uri
*   request only
*   request_uri only

As one can observe, if an OpenID Connect Client is set-up with default settings, the default value for this option is “Not required”. There is no option to do not support a _Request Object_ at all, as “not required” means submitting the request object is optional, but if you submit one, it is used by Keycloak. Additionally, there is no option to manually define the request_uris parameter during manual client registration. Finally, using the default configuration, Keycloak does not require a _Request Object_, but supports passing the request_uri parameter with an _Authentication Request_. As a result, Keycloak is in its default configuration for Clients vulnerable to the SSRF attack Fett et al. described in 2017 \[3, Section III; A. 8)\].

**Proof-of-Concept**

A straight forward PoC to trigger the SSRF issue is given with the following URL (_Authentication Response_): https://keycloak.local/auth/realms/master/protocol/openid-connect/auth?scope=openid&response\_type=code&redirect\_uri=\[Valid-RedirectURI\]&state=aaaa&nonce=bbbb&client\_id=\[Valid-ClientID\]&request\_uri=http://127.0.0.1:1234

Thus, to launch the SSRF in a real-life scenario, an attacker would obtain an _Authentication Request_ (to get the valid client_id and redirect_uri).

If the attacker then sends the _Authentication Response_ GET request including valid client_id and redirect_uri, Keycloak sends a GET request to 127.0.0.1:1234 to fetch the _Request Object_ resulting in **blind SSRF**.

By measuring the response time, a malicious actor may additionally perform a **port scan** of _localhost_ or internally accessible hosts. The following ports are open on localhost:

*   8080: Open, Keycloak, 1087 Bytes as default response
*   8081: Open, Mailslurper, 4086 Bytes as default response
*   5555: Closed
*   5556: Closed

**Demo**: An example using the Timeinator Burp Plugin \[7\] is presented below: 

Keycloak responds significantly faster if the port is closed in our test. Thus, the Blind SSRF enables an attacker to learn about the internal network structure.

**Recommendation**

To mitigate the described issue, the request_uri should be disabled in Keycloak’s default Client configuration. Furthermore, localhost and private IPs should be forbidden as request_uri, unless explicitly enabled by an administrative user with high privileges. Finally, the request_uris whitelist should also be available and enforced during manual configuration to restrict the request_uri parameter.

**Responsible Disclosure**

*   **2020-04-29**: Initial Report to Red Hat via https://issues.redhat.com/projects/KEYCLOAK/.
*   **2020-06-05**: Red Hat triages the submitted report.
*   **2020-06-11**: CVE-2020-10770 is assigned.
*   **2020-10-16**: Red Hat is informed that this post is scheduled for 2020-11-10.
*   **2020-10-19**: Red Hat approves to disclose this post on the described vulnerability:

> Thank you for informing about this. Since this is a Moderate impact flaw, we have 365 calendar days to publish the fix after the issue has been made public so should not be a problem publishing it on 2020-11-10.
> 
> \- _Internal Comment by Red Hat Employee_

According to the internal ticket status, Red Hat plans to resolve this issue with the upcoming major version v12 of Keycloak.

**Example 2: SSRF in Amazon Cognito (AWS)**

Similar to Keycloak, Amazon Cognito implements Identity and Access Management (IAM). But in contrast Amazon Cognito is a hosted service as part of the AWS family instead of a self-hosted software.

**The following vulnerability was resolved by the Amazon Cognito team in August 2020. Detailed information on the Responsible Disclosure and Remediation Process will be discussed in the following.**

**Attacker Model**

The attacker model that is applied in the following is a malicious administrative user. The impact of attacks under this attacker model is highly conditional, but in this case, as Amazon Cognito is a hosted service, administrative users only have access to the configuration interface. The underlying infrastructure in Amazon’s hosted environment should not be accessible to external users.

Alternatively, a malicious Identity Provider could be considered as the attacker model. The actual configuration is fetched using OpenID Connect Discovery from the Identity Provider’s _Configuration Endpoint_ so that the endpoints are controlled by the Identity Provider.

**Description**

Amazon Cognito allows specifying custom OpenID Connect Identity Providers for user pools. Within the configuration of an Identity Provider, an administrative user could choose to “Run discovery”, triggering an OpenID Connect Discovery that requests the _Configuration Endpoint_ of the Identity Provider. Amazon Cognito did not restrict the endpoints observed using OpenID Connect Discovery regarding internal IP addresses or localhost so that SSRF to the local network and localhost was possible.

A malicious actor could utilize this to perform port scans or send nearly arbitrary HTTP requests to hosts that are intentionally not exposed to the internet. An example _Configuration Response_ is presented in the following:

    {
        "issuer":"https://example.com/",
        "authorization_endpoint":"https://example.com/auth",
        "token_endpoint":"http://127.0.0.1:22",
        "userinfo_endpoint":"http://127.0.0.1:22",
        "jwks_uri":"https://example.com/jwks",
        "registration_endpoint":"https://example.com/register",
        "response_types_supported":["code","token id_token"],
        "subject_types_supported":["public","pairwise"],
        "id_token_signing_alg_values_supported":["RS256"]
    }
    

**Portscan**

The following error messages could be used to determine which ports are internally open on localhost, as the error message sent to the redirect_uri (https://a.com/cb?error\_description=\[ERROR\]&error=invalid\_request) differed depending on the underlying Transmission Control Protocol (TCP) connection. If the connection could not be established or Amazon Cognito received an HTTP error code in response to the _Token Request_, the following error messages were sent to the Identity Provider:

*   If the _Token Endpoint_ was specified as “http://localhost:22”, the error message was “Connection reset”, so that we could assume Port 22 to be open.
*   If the _Token Endpoint_ was specified as “http://localhost:20”, the error message was “Connect to 127.0.0.1:20 \[/127.0.0.1\] failed: Connection refused”, so that we could assume Port 20 to be closed.
*   If the _Token Endpoint_ was specified as “http://test123.ngrok.io”, the error message was “test Error – 502 error getting token”, so that we could assume that there was an HTTP request to the specified target, but the web server responded with HTTP Error Code 502.

**Arbitrary HTTP requests**

Besides the feedback an attacker received that enabled him to determine the connection’s status, there was no information on the actual response to the HTTP request. Thus, this gadget could be considered as **blind SSRF** to the local network. The attacker had no direct feedback but could still control a GET request (_UserInfo Request_) and a POST request (_Token Request_) regarding scheme (_http_ or _https_), host (potentially localhost or internal IP), path and query parameters.

Combining port scan and blind SSRF, a malicious administrative user or malicious Identity Provider could:

1.  **Gather information**: Which ports are open on localhost? Are there other hosts accessible? If HTTP error codes are reflected, which web service is running at this destination (fingerprinting)?
2.  **If a service could be identified**: Use blind SSRF to target an internally accessible service directly.

**Recommendation**

A blacklist is never perfect. Nevertheless, Amazon Cognito should introduce a restriction for internal IPs and localhost as OpenID Connect endpoints, as there is no legitimate use-case in the context of a hosted service.

The fix that was applied in late August 2020 mitigates the above described vulnerability.

**Responsible Disclosure**

Mitigations for the described issues were introduced by AWS / Amazon Cognito soon after we reported the issue on 2020-08-12.

*   **2020-08-12**: Initial report to aws-security@amazon.com.
*   **2020-08-19**: Call with AWS Security Team and Amazon Cognito Developers.
*   **2020-08-??**: A fix is applied at the end of August 2020. As Amazon Cognito is a hosted service, we could not determine the exact date.
*   **2020-10-21**: AWS Security Team acknowledges that the blog post is scheduled for 2020-11-10 and offers feedback for the draft prior to publication:

> Thanks again for bringing your security concern to our attention. We greatly appreciate and encourage reports from the security community.
> 
> I understand you wish to do a write up on this - would you be interested in sharing your draft with us before publishing so we may provide any assistance and feedback?

*   **2020-11-05**: After providing an initial draft, the AWS Security team would like to explicitly outline that the described vulnerability was mitigated shortly after we reported it responsibly. Thank you for your feedback!

**References**

\[1\] https://owasp.org/www-community/attacks/Server\_Side\_Request\_Forgery  
\[2\] https://www.nds.ruhr-uni-bochum.de/media/ei/veroeffentlichungen/2017/01/13/OIDCSecurity\_1.pdf  
\[3\] https://dl.acm.org/doi/10.1145/2976749.2978385  
\[4\] https://www.adambarth.com/papers/2008/barth-jackson-mitchell.pdf  
\[5\] https://openid.net/specs/openid-connect-core-1\_0.html  
\[6\] https://openid.net/specs/openid-connect-registration-1\_0.html  
\[7\] https://github.com/FSecureLABS/timeinator

Thank you for reading this post! If you have any feedback, Feel free to reach out via Mastodon, Twitter or LinkedIn. 👨‍💻

You can directly tweet about this post using this link. 🤓

Special thanks to Dr.-Ing. Christian Mainka (@CheariX), Dr.-Ing. Vladislav Mladenov (@v\_mladenov), Louis Jannett (@iphoneintosh) and the AWS Security / Amazon Cognito Development Team for your feedback on this post prior to publication! 🙂

*   OpenID Connect
*   Keycloak
*   AWS
*   Amazon Cognito

CVE-2023-44469: Real-life OIDC Security (IV): Server-Side-Request-Forgery

Red Hat Security Advisory 2023-5379-01 - Network Observability 1.4.0. Issues addressed include a denial of service vulnerability.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

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

Synopsis:          Important: Network Observability 1.4.0 for OpenShift  
Advisory ID:       RHSA-2023:5379-01  
Product:           Network Observability  
Advisory URL:      https://access.redhat.com/errata/RHSA-2023:5379  
Issue date:        2023-09-28  
CVE Names:         CVE-2022-25883 CVE-2023-2602 CVE-2023-2603   
                   CVE-2023-26115 CVE-2023-28321 CVE-2023-28322   
                   CVE-2023-28484 CVE-2023-29469   
=====================================================================

1. Summary:

Network Observability is an OpenShift operator that deploys a monitoring  
pipeline to collect and enrich network flows that are produced by the  
Network Observability eBPF agent.

The operator provides dashboards, metrics, and keeps flows accessible in a  
queryable log store, Grafana Loki. When a FlowCollector is deployed, new  
dashboards are available in the Console.

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.

2. Description:

Network Observability 1.4.0

Security Fix(es):

* word-wrap: Regular Expression Denial of Service (CVE-2023-26115)

* nodejs-semver: Regular expression denial of service (CVE-2022-25883)

3. Solution:

Before applying this update, make sure all previously released errata  
relevant to your system have been applied.

For details on how to apply this update, refer to:

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

4. Bugs fixed (https://bugzilla.redhat.com/):

2216475 - CVE-2022-25883 nodejs-semver: Regular expression denial of service  
2216827 - CVE-2023-26115 word-wrap: ReDoS

5. JIRA issues fixed (https://issues.redhat.com/):

NETOBSERV-1009 - Export Netflows without Loki  
NETOBSERV-1034 - Remove 1.0.x channel  
NETOBSERV-1107 - Improve ebpf agent memory usage  
NETOBSERV-1131 - Metrics do not ignore duplicates  
NETOBSERV-1137 - UI Enhancements 1.4  
NETOBSERV-1182 - add cluster name to flp configuration  
NETOBSERV-1196 - Extend platform coverage for Network Observability  
NETOBSERV-1224 - Flowcollector does not report status != Ready in OCP Console  
NETOBSERV-1242 - Console plugin build infos  
NETOBSERV-1283 - Not able to monitor Multus/SRIOV traffic on Network Observability Operator  
NETOBSERV-139 - Flow dashboards enhancements (flow-based metrics)  
NETOBSERV-962 - Add IPFIX exporter  
NETOBSERV-975 - Flows dropped due to Loki stream limit during large traffic spikes

6. References:

https://access.redhat.com/security/cve/CVE-2022-25883  
https://access.redhat.com/security/cve/CVE-2023-2602  
https://access.redhat.com/security/cve/CVE-2023-2603  
https://access.redhat.com/security/cve/CVE-2023-26115  
https://access.redhat.com/security/cve/CVE-2023-28321  
https://access.redhat.com/security/cve/CVE-2023-28322  
https://access.redhat.com/security/cve/CVE-2023-28484  
https://access.redhat.com/security/cve/CVE-2023-29469  
https://access.redhat.com/security/updates/classification/#important

7. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2023 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIcBAEBCAAGBQJlFPJvAAoJENzjgjWX9erE6ocQAIq2UqNWebhHVR6RWz5DNPKV  
vN3p9UFDDV6218CnhSJ8utdpDfuf/QbiM4SD5oLjgwqkcT55CvHMG3FsDrBSoun7  
ihpibVNkK9SD5gyUAtBWYO9jlxuMeDn1FqJqHo4bzVllq1oVQYtZp6FLp+zxrUX0  
X7b0NbYsuR2cqec4d01eZvnfEGouvSMS0UnUJzCNZ5837SxND11jbwdYMXeJDZNL  
vftwDdcVaDXycy4bzK7iuw4ckoZLm30rmuKONbDrwID+tTqQXi2T7cqz3F+OxO6+  
N9vLDY6xkOkzVUQtKvC7GYc4lHYZaJycm9KViYhgAF2US9L+vv4sbuyyVM6zpN3t  
B5+6I0tKX9kJyKpY7hDU9OTtIO2t8mZiTlkhNKv8oBE4AyfMWwbqS/4AGWBea1yN  
RQlRsMDKnv/qVgT380ckkkD7ksPEnxEy9ZMAvZ0ElQLrtKNPkwXQFhgCu/3QphWJ  
epieCp3IQiXZaHJeX31E26v3PcwCoeder/FsyRfgNINpLe+WLLSqkbDWvVQHsKHM  
mfbh/089ps5grHOD8aAv+w25OwbQGQZ1x65nxn4AAfFKtn1+JcRTpuvqZILXAn+f  
Nst3KqcTO0EDxMO/H7Gi2pTTHvDWzdgvRpkz3RXVyK7IjmqM0tqRXBGvRh45QNfx  
pKJwnAnKS+8ITelhsQGZ  
=mX3+  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2023-5379-01

A File upload vulnerability in CMSmadesimple v.2.2.18 allows a local attacker to upload a pdf file with hidden Cross Site Scripting (XSS).

**CMSmadesimple File Upload - XSS v2.2.18****Author: (Sergio)**

**Description:** File upload vulnerability in CMSmadesimple v.2.2.18 allows a local attacker to upload a pdf file with hidden XSS.

**Attack Vectors:** A vulnerability in File Manager file upload sanitation allows you to upload a PDF file with hidden XSS.

**POC:**

When logging into the panel, we will go to the "Content- File Manager." section off General Menu.

We upload the PDF file with the hidden XSS and we see that we can execute it and the Reflected XSS appears.

  
**Additional Information:**

http://www.cmsmadesimple.org/

https://cheatsheetseries.owasp.org/cheatsheets/File\_Upload\_Cheat\_Sheet.html

CVE-2023-43872: GitHub - sromanhu/CMSmadesimple-File-Upload--XSS---File-Manager: CMSmadesimple 2.2.18 is affected by File Upload - XSS vulnerability that allows attackers to upload a PDF file with a hidden XSS that w

A File upload vulnerability in WBCE v.1.6.1 allows a local attacker to upload a pdf file with hidden Cross Site Scripting (XSS).

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

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

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

Sign up

CVE-2023-43871: WBCE-Arbitrary-File-Upload--XSS---Media/README.md at main · sromanhu/WBCE-Arbitrary-File-Upload--XSS---Media

A stored cross-site scripting (XSS) vulnerability in the cms/content/edit component of YZNCMS v1.3.0 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the title parameter.

CVE-2023-43233: mycve/YZNCMS 1.3.0 XSS.pdf at main · yux1azhengye/mycve

SeaCMS V12.9 was discovered to contain an arbitrary file write vulnerability via the component admin_notify.php.

CVE-2023-44169: vulnerabilities/SeaCMS V12.9 Arbitrary file write vulnerability.pdf at main · H3ppo/vulnerabilities

Auth. (admin+) Stored Cross-Site Scripting (XSS) vulnerability in Pdfcrowd Save as Image plugin by Pdfcrowd plugin <= 2.16.0 versions.

**Solution**

 Fixed

Update the WordPress Save as Image plugin by Pdfcrowd plugin to the latest available version (at least 2.16.1).

Mahesh Nagabhairava discovered and reported this Cross Site Scripting (XSS) vulnerability in WordPress Save as Image plugin by Pdfcrowd Plugin. This could allow a malicious actor to inject malicious scripts, such as redirects, advertisements, and other HTML payloads into your website which will be executed when guests visit your site. This vulnerability has been fixed in version 2.16.1.

**No other known vulnerabilities for this plugin**Report

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-40665: WordPress Save as Image plugin by Pdfcrowd plugin <= 2.16.0 - Cross Site Scripting (XSS) vulnerability - Patchstack

Auth. (admin+) Stored Cross-Site Scripting (XSS) vulnerability in Pdfcrowd Save as PDF plugin by Pdfcrowd plugin <= 2.16.0 versions.

**Solution**

 Fixed

Update the WordPress Save as PDF plugin by Pdfcrowd plugin to the latest available version (at least 2.16.1).

Mahesh Nagabhairava discovered and reported this Cross Site Scripting (XSS) vulnerability in WordPress Save as PDF plugin by Pdfcrowd Plugin. This could allow a malicious actor to inject malicious scripts, such as redirects, advertisements, and other HTML payloads into your website which will be executed when guests visit your site. This vulnerability has been fixed in version 2.16.1.

**No other known vulnerabilities for this plugin**Report

**WordPress plugin developer?**

Start a free security program for your WordPress plugins or request an audit.

Apply for MVDP

**Security researcher?**

Report to Patchstack Alliance bounty platform and earn monthly cash prizes.

Learn more

CVE-2023-40668: WordPress Save as PDF plugin by Pdfcrowd plugin <= 2.16.0 - Cross Site Scripting (XSS) vulnerability - Patchstack

Debian Linux Security Advisory 5505-1 - Matteo Memelli reported an out-of-bounds read flaw when parsing CDP addresses in lldpd, an implementation of the IEEE 802.1ab (LLDP) protocol. A remote attacker can take advantage of this flaw to cause a denial of service via a specially crafted CDP PDU packet.

    -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA512- -------------------------------------------------------------------------Debian Security Advisory DSA-5505-1                   security@debian.orghttps://www.debian.org/security/                     Salvatore BonaccorsoSeptember 25, 2023                    https://www.debian.org/security/faq- -------------------------------------------------------------------------Package        : lldpdCVE ID         : CVE-2023-41910Matteo Memelli reported an out-of-bounds read flaw when parsing CDPaddresses in lldpd, an implementation of the IEEE 802.1ab (LLDP)protocol. A remote attacker can take advantage of this flaw to cause adenial of service via a specially crafted CDP PDU packet.For the oldstable distribution (bullseye), this problem has been fixedin version 1.0.11-1+deb11u2.For the stable distribution (bookworm), this problem has been fixed inversion 1.0.16-1+deb12u1.We recommend that you upgrade your lldpd packages.For the detailed security status of lldpd please refer to its securitytracker page at:https://security-tracker.debian.org/tracker/lldpdFurther information about Debian Security Advisories, how to applythese updates to your system and frequently asked questions can befound at: https://www.debian.org/security/Mailing list: debian-security-announce@lists.debian.org-----BEGIN PGP SIGNATURE-----iQKSBAEBCgB9FiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmUR7DtfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQACgkQBUy48xNDz0Sdnw/3WH0qPypSyEnjG7l5EcQp6jvNLgiS5jElWJK6nlp1hDjDSWXMtCqaUn63fnZND9xDGRIymeJP+xF7Id52nxLsnz3Xwc+eJzxjfGsXQG7Cserxdw3IlGkxfOg/WFGObUQt5BsioT5CvZU4irwUzCU2dPbOFnRKgw2KJHQnHvENfDpF/Q5iXMKrnpjm2RnTZ4QQDBxBy18AESKbOhwQf42RVKq32MZXrmxjJNB9oiLKn+rcMdSHwHIa065k6iQnUBZM/kyKXdvy4nHhyAUcP1fRlEs2OMlKm1ZHAdLMZZUkpH+lfrWQxvldTnfAR87XMC56O28KsXOKOlNoAMKrQhBW40MwyXaTHrp5DmBaA8ttscSqUjlaCc/dkVvtll9xAHZpuXwwrqN3eXKG18WnNu0JDdEoHjnF2a/J+KHC3ZM3YCz2e6zLF9sreqRJVF+aIbTwC40IKrfru9Dk7UZyUzHDsTTC1y6M8QjUEe5ruLNdFr4pxKyAf3sfswU49rmqpFP20jBKbCXWzoHyp1cI+Dapfh9rWPYl+FZ177TRIQY2+3wJ1qCYST70cSxNVTQn7P45EHekJ31JCgGohGc9oWRlzr0K1j1cT7nx+kxkqzI9exCj2AKczft7ukNPj3sKllJqdn2j1dPmhYyIggCQiKq/Tj3shTPkdV8PgPzfzigh0w===Hds+-----END PGP SIGNATURE-----

Debian Security Advisory 5505-1

Categories: News
Categories: Scams
Tags: booking.com

Tags:  obfuscated

Tags:  hospitality

Tags:  anti-sandboxing

A very clever and complex phishing campaign uses organizations in the hospitality industry to get customers' credit card information.



(Read more...)




The post Credit card thieves target Booking.com customers appeared first on Malwarebytes Labs.

Staff in the hospitality industry are trained to accommodate their guests, and when they have a few years of experience under their belt you can be sure they'll have received some extraordinary requests.

Which is something that clever cybercriminals are taking advantage of. Researchers at Perception Point recently documented a sophisticated phishing campaign targeting hotels and travel agencies.

The campaign raised alarm because of the clever scheme deployed to trick staff into installing an information stealer. This part of the campaign is made up out of highly targeted attacks.

The first stage of the attack typically sees the attackers send a query about a booking or make a reservation. The bookings will always have low or no cancellation costs so the attackers can minimize their investment.

Once the attackers receive a response, they'll come up with a persuasive reason for the hotel staff to print or study something ahead of their arrival. Examples include medical records for a child or an important map they would like to print out for their elderly parents.

To add a touch of legitimacy and to evade detection, they even provide the hotel representative with a password to unlock these so-called “important files.”

_Image courtesy of Perception Point_

In reality, the document contains malware hosted on a file sharing platform, such as Google Drive. The file is encrypted but is decrypted when the victim enters the password. The main executable file often has a misleading icon, such as one that makes it look like a pdf. Once the victim double-clicks on the file, the information stealer (or InfoStealer) is then unleashed.

The second step in this attack targets the customers, and was discovered by Akamai researchers. 

After the InfoStealer is executed on the original target’s (hotel/travel agent's) systems, the attacker then begins messaging legitimate customers. The message used in this campaign contains a link to what it says is an additional card verification step. In reality, the link triggers an executable on the victim’s machine which gathers information about the browser and presents the recipient with several security validation questions.

Once the victim passes the tests, they are forwarded to a credit card phishing site masquerading as a Booking.com payment page. 

**Tips for hospitality organizations**

Besides having adequate up-to-date real-time protection on your systems, there are some general tips that can keep you out of trouble.

*   Always confirm the identity of anyone requesting sensitive information or access to internal systems.
*   Educate your team so they know how to recognize phishing attempts and where to report potential threats.
*   Invest in an email security solution which makes it harder for phishing emails and unknown malware to reach the intended target.
*   Never click on unsolicited links. 
*   Be cautious of messages that create a sense of urgency or threaten negative consequences if you don't take immediate action.

**Tips for consumers**

These phishing schemes are exceptionally well thought out and tailored so victims are more likely to click. Still, there are some red flags that can help you prevent falling victim.

*   Double check unexpected communications which ask for additional payments or payment details. There is no harm in asking for clarification or confirmation.
*   Inspect links before you click on them to see whether they lead to where you expect.
*   Do not send information that the booked accommodation should already have or shouldn't need at all.
*   Be suspicious of urgent or threatening messages asking for immediate action.

**Identity theft victims**

If you suspect you are a victim of credit card identity theft, the FTC recommends you contact your bank or credit card company to cancel your card and request a new one. If you get a new card, don’t forget to update any automatic payments with your new card number.

To find out if you are a victim:

*   Review your transactions regularly to make sure no one has misused your card, and consider credit monitoring.
*   If you find fraudulent charges, call your bank's fraud department to alert them.
*   Check your own credit report at annualcreditreport.com.
*   Consider freezing your credit report. This stops new creditors and potential thieves from accessing your credit report.

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

Tag

#pdf