SSRF REPORT

1. The SSRF vulnerability is present in the url parameter of the API endpoint at
https://couriers.indrive.com/api/file-storage. This vulnerability allows an
attacker to manipulate the url parameter to make the server request any external or
internal URL. If the server fetches data from the specified URL, it can expose sensitive
information or perform unwanted actions.

2. SSRF on image renderer - The endpoint image.api.np.km.playstation.net allows users to

pass image URLs through the image parameter, which can be exploited to send Gopher
requests. By creating a Gopher redirect PHP file that contains SMTP commands, an
attacker can trigger the server to send emails through an external SMTP server. Although
the request returns a 404 error, the attacker can confirm that their server was accessed
and the email was sent. what is the vulnerabiliy name and payload

3. SSRF mitigation bypass - This vulnerability allows attacker to send arbitrary requests to
local network which hosts GitLab and read the response. This is possible due to flawed
DNS rebinding protection. If the DNS resolution fails, outgoing requests are not blocked,
enabling access to sensitive internal resources like `http://169.254.169.254`. This SSRF
vulnerability can lead to significant risks, including unauthorized data access and potential
Remote Code Execution in cloud environments.

4. SSRF in hatchful.shopify.com - An SSRF vulnerability in Shopify's logo generation

allowed users to send raw SVG data through WebSockets, which could be manipulated.
Attackers could change the SVG to include harmful links, potentially reading server files or
exploiting other vulnerabilities. This issue has been fixed by only sending safe parameters
instead of the SVG data itself.

How It Works:

1. Client-Side Editing: Users create or edit logos using a WYSIWYG (What You See Is
What You Get) editor that generates SVG content.
2. WebSocket Connection: Once the user finalizes their logo, the SVG data is sent to
the server via an established WebSocket connection.
 3. Server Processing: The server receives the SVG data and processes it, often
converting it to a different format (like PNG) for delivery.
4. SSRF in https://imgur.com/vidgif/url - Imgur's video-to-gif service has a vulnerability that
lets users submit URLs without proper checks, allowing attackers to send requests to both
external and internal networks. This means they can use different protocols like FTP and
SMTP to leak sensitive information or send spam. By creating malicious URLs, attackers
can gather software version details or even send unwanted UDP packets. They can also
overload Imgur's servers by exploiting long request timeouts, causing Denial of Service.
Overall, this vulnerability risks data leaks and resource exhaustion for Imgur.

5. SSRF By adding a custom integration on console.helium.com

• Login: Start by logging into the Helium console as an Administrator for an

organization with a connected device.
• Create Integration: Navigate to the "Integrations" section and select "Add a custom
HTTP integration."
• Configure Endpoint: Set the integration endpoint to
http://169.254.169.254/latest/meta-data and use the GET method. This
endpoint retrieves sensitive metadata from an EC2 instance.
• Label Integration: Provide a label for the integration and save it.
• Link to Device: Assign this label to the device in your organization, establishing the
connection.
• Trigger SSRF: When the device transmits a packet, the server will access the
private metadata, exposing it to the attacker through the device's uplink message.

6. Blind Server-Side Request Forgery (SSRF) allows scanning internal ports - The Blind SSRF
vulnerability on https://fleet-status.app.elstc.co allows attackers to scan internal ports by
sending crafted HTTP requests. By analyzing the responses—such as timeouts for closed
ports or unexpected HTML responses for open ports—attackers can infer the status of
internal services. Although the responses are not directly readable, the vulnerability can
still be exploited for reconnaissance and identifying open ports.

7. SSRF in Search.gov via ?url= parameter - The SSRF vulnerability is confirmed through the
ability to manipulate the URL parameter in requests to the `/help_docs` endpoint. By
inserting `%0A` (Line Feed) into the URL, attackers can test internal ports (e.g.,
`http://127.0.0.1:21`) and measure response times to determine if ports are open or
closed. Specific responses—like timeout messages for closed ports and different
response times for open ports—demonstrate the presence of SSRF. Additionally, attempts
to access internal metadata endpoints, such as `http://169.254.169.254/latest/meta-
data/`, further confirm the vulnerability's exploitation potential.

8. FULL SSRF - The SSRF issue on the Acronis Summit website lets attackers use the
`bzIframeUrl` parameter to reach internal resources. By adding URLs like
`http://169.254.169.254/latest/meta-data/`, attackers can get sensitive information about
the server. This could help them find and exploit more vulnerabilities in the system.
Overall, this makes the website and its infrastructure less secure.

9. Blind SSRF in social-plugins.line.me - LINE Social Plugins lets users share content
through LINE on the web. A security issue called Blind SSRF was found because the service
didn't check URLs properly. This could let attackers send requests to internal servers or
check which ports are open on the network, risking sensitive information.

10. Server side request forgery on image upload for lists - There is a Server-side Request
Forgery (SSRF) vulnerability on Instacart when updating list images. By sending a POST
request to change the image URL to `http://127.0.0.1:21`, the system attempts to connect
to the local SSH port. The response shows an error related to the connection, confirming
that it tried to access an internal resource. This flaw allows attackers to potentially access
internal services.

11. SSRF protection bypass - Nextcloud has a vulnerability called Server-side Request
Forgery (SSRF) that lets attackers get around its protection. By using special IP address
formats, they can access files on the server that they shouldn’t be able to. For example,
they can use a URL like `http://[0:0:0:0:0:ffff:127.0.0.1]/thefile` to read important files.
This could let them steal data from the internal network.

12. Server side request forgery (SSRF) on nextcloud implementation - Nextcloud lets
admins add trusted servers, but this can create a security problem called Server-side
Request Forgery (SSRF). An attacker can change the server URL in requests to check
internal services. For example, they might use `http://127.0.0.1:80` to see if port 80 is
open by checking for a response. If they try `http://127.0.0.1:8080` and get a "Connection
refused" error, it means that port is closed. This way, attackers can learn about open ports
in the internal network.

13. SSRF through File Replace - In version 8.2.0, there's a security flaw that lets attackers
use the "Replace" feature to check if certain ports on the server are open. They can do this
by using localhost IPs (like 127.0.0.1). The server gives different responses depending on
whether a port is open or closed. For example, an open port (like 80) might show an error
about the mime type, while a closed port (like 1) will say it can't connect. This allows
attackers to figure out which ports on the internal network can be accessed.

14. SSRF on testing endpoint - The form at https://www.apitest.io/request lets users enter
a "url" parameter that can access internal services on the server. I found several services,
like the OpenStack metadata server and a VestaCP admin panel. The metadata server
shows information about the server but doesn't seem to hold sensitive data. However,
accessing port 8081 might let someone change server settings. It looks like my IP was
blocked after these tests.

OpenStack Metadata Server: A service that provides information about cloud resources
(like virtual machines) running on OpenStack.

15. Internal Ports Scanning via Blind SSRF - I found a problem called Blind SSRF that lets
someone check which internal ports are open on a server. You can log in and send a
request to a specific URL. If the request is good, it will respond with a status code of 200
and show the website's title. I tested some local ports and found that ports 80, 81, and
6000 were open. This means internal addresses shouldn't be allowed in requests to keep
things safe.

16. Internal Ports Scanning via Blind SSRF (URL Redirection to beat filter) - This is a Blind
SSRF vulnerability that allows scanning of internal ports. I found a way to bypass the
security filter by using a URL shortener, TinyURL, to link to an internal address like
http://0:6000/. When I tested this, the server responded with a 200 OK status, revealing the
site's title. To fix this issue, the filter should follow redirects and then check the final URL to
prevent this type of access. This will help protect internal services from being scanned.

17. SSRF bypass - This talks about a security issue in Concrete5 version 8.5.2. It shows
that using a special way to write the IP address (0177.0.0.1) lets someone bypass
restrictions meant to block access to localhost services. Because of this, attackers might
reach local services that should be hidden, depending on what's available. If they can use
these services, they might do harmful things. This situation shows the need for better
checks on what users can access.

18. SSRF chained to hit internal host leading to another SSRF which allows to read internal
images - This report highlights a Server-Side Request Forgery (SSRF) vulnerability found in
the following PlayStation APIs:

1. Image API: https://image.api.np.km.playstation.net/images

 2. Dis API: https://dis.api.np.playstation.net/dis/v1/banners

These APIs allow users to fetch images, but they can also be exploited to access internal
services and images that should remain private. By crafting specific requests to these
endpoints, attackers can gain access to sensitive internal data.

19. SVG Server Side Request Forgery (SSRF) - This report shows a security problem where
an attacker can upload a fake image file named like a PNG, but it's really an SVG file. Even
if the server rejects the upload, it still sends requests to another server based on the SVG
content. This lets the attacker trick the server into contacting their server, which can reveal
internal files and details about the server's setup. The issue happens because the server
doesn’t check the file types carefully enough when files are uploaded.

20. Bypass of the SSRF protection - This report explains a security problem in Slack that
lets users trick the system into allowing certain URLs. By using "[::]" as the address,
attackers can reach internal services that should be blocked, like email servers or SSH.
When they send a special command, the server might respond, giving away information
about these internal services. The issue happens because the system's security checks
aren't strong enough. This could let attackers access sensitive information.