#ssrf

### Summary The reverse port forwarding in sliver teamserver allows the implant to open a reverse tunnel on the sliver teamserver without verifying if the operator instructed the implant to do so ### Reproduction steps Run server ``` wget https://github.com/BishopFox/sliver/releases/download/v1.5.42/sliver-server_linux chmod +x sliver-server_linux ./sliver-server_linux ``` Generate binary ``` generate --mtls 127.0.0.1:8443 ``` Run it on windows, then `Task manager -> find process -> Create memory dump file` Install RogueSliver and get the certs ``` git clone https://github.com/ACE-Responder/RogueSliver.git pip3 install -r requirements.txt --break-system-packages python3 ExtractCerts.py implant.dmp ``` Start callback listener. Teamserver will connect when POC is run and send "ssrf poc" to nc ``` nc -nvlp 1111 ``` Run the poc (pasted at bottom of this file) ``` python3 poc.py <SLIVER IP> <MTLS PORT> <CALLBACK IP> <CALLBACK PORT> python3 poc.py 192.168.1.33 8443 44.221.186.72 1111...

## Description Label Studio's S3 storage integration feature contains a Server-Side Request Forgery (SSRF) vulnerability in its endpoint configuration. When creating an S3 storage connection, the application allows users to specify a custom S3 endpoint URL via the s3_endpoint parameter. This endpoint URL is passed directly to the boto3 AWS SDK without proper validation or restrictions on the protocol or destination. The vulnerability allows an attacker to make the application send HTTP requests to arbitrary internal services by specifying them as the S3 endpoint. When the storage sync operation is triggered, the application attempts to make S3 API calls to the specified endpoint, effectively making HTTP requests to the target service and returning the response in error messages. This SSRF vulnerability enables attackers to bypass network segmentation and access internal services that should not be accessible from the external network. The vulnerability is particularly severe because ...

As of January 10, 2023, CISA will no longer be updating ICS security advisories for Siemens product vulnerabilities beyond the initial advisory. For the most up-to-date information on vulnerabilities in this advisory, please see Siemens' ProductCERT Security Advisories (CERT Services | Services | Siemens Global). View CSAF 1. EXECUTIVE SUMMARY CVSS v4 9.4 ATTENTION: Exploitable remotely/low attack complexity Vendor: Siemens Equipment: Opcenter Intelligence Vulnerabilities: Improper Authentication, Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), Deserialization of Untrusted Data, Insertion of Sensitive Information into Log File, Server-Side Request Forgery (SSRF) 2. RISK EVALUATION Successful exploitation of these vulnerabilities could enable an attacker to execute remote code or allow a malicious site administrator to change passwords for users. 3. TECHNICAL DETAILS 3.1 AFFECTED PRODUCTS Siemens reports that the following products are affected: Siemens O...

Microsoft’s February Patch Tuesday addresses 63 security vulnerabilities, including two actively exploited zero-days. Update your systems now to…

Microsoft has released its monthly security update for January of 2025 which includes 58 vulnerabilities, including 3 that Microsoft marked as “critical” and one marked as "moderate". The remaining vulnerabilities listed are classified as “important.”

Versions of the package hackney from 0.0.0 are vulnerable to Server-side Request Forgery (SSRF) due to improper parsing of URLs by URI built-in module and hackey. Given the URL http://[email protected]/, the URI function will parse and see the host as 127.0.0.1 (which is correct), and hackney will refer the host as 127.2.2.2/. This vulnerability can be exploited when users rely on the URL function for host checking.

### Summary This vulnerability allows a user to bypass any predefined hardcoded URL path or security anti-Localhost mechanism and perform an arbitrary GET request to any Host, Port and URL using a Webfinger Request. ### Details The Webfinger endpoint takes a remote domain for checking accounts as a feature, however, as per the ActivityPub spec (https://www.w3.org/TR/activitypub/#security-considerations), on the security considerations section at B.3, access to Localhost services should be prevented while running in production. The library attempts to prevent Localhost access using the following mechanism (/src/config.rs): ```rust pub(crate) async fn verify_url_valid(&self, url: &Url) -> Result<(), Error> { match url.scheme() { "https" => {} "http" => { if !self.allow_http_urls { return Err(Error::UrlVerificationError( "Http urls are only allowed in debug mode", )); ...

Zimbra has released software updates to address critical security flaws in its Collaboration software that, if successfully exploited, could result in information disclosure under certain conditions. The vulnerability, tracked as CVE-2025-25064, carries a CVSS score of 9.8 out of a maximum of 10.0. It has been described as an SQL injection bug in the ZimbraSync Service SOAP endpoint affecting

### Impact In mitmweb 11.1.0 and below, a malicious client can use mitmweb's proxy server (bound to `*:8080` by default) to access mitmweb's internal API (bound to `127.0.0.1:8081` by default). In other words, while the client cannot access the API directly (good), they can access the API through the proxy (bad). An attacker may be able to escalate this [SSRF](https://en.wikipedia.org/wiki/Server-side_request_forgery)-style access to remote code execution. The mitmproxy and mitmdump tools are unaffected. Only mitmweb is affected. The `block_global` option, which is enabled by default, blocks connections originating from publicly-routable IP addresses in the proxy. The attacker needs to be in the same local network. ### Patches The vulnerability has been fixed in mitmproxy 11.1.2 and above. ### Acknowledgements We thank Stefan Grönke (@gronke) for reporting this vulnerability as part of a security audit by [Radically Open Security](https://www.radicallyopensecurity.com/). This audi...

### Summary Imgproxy does not block the `0.0.0.0` address, even with `IMGPROXY_ALLOW_LOOPBACK_SOURCE_ADDRESSES` set to false. This can expose services on the local host. ### Details imgproxy protects against SSRF against a loopback address with the following check ([source](https://github.com/imgproxy/imgproxy/blob/0f37d62fd8326a32c213b30dd52e2319770885d8/security/source.go#L43C1-L47C1)): ``` if !config.AllowLoopbackSourceAddresses && ip.IsLoopback() { return ErrSourceAddressNotAllowed } ``` This check is insufficient to prevent accessing services on the local host, as services may receive traffic on `0.0.0.0`. Go's `IsLoopback` ([source](https://github.com/golang/go/blob/40b3c0e58a0ae8dec4684a009bf3806769e0fc41/src/net/ip.go#L126-L131)) strictly follows the definition of loopback IPs beginning with `127`. `0.0.0.0` is not blocked.