BUG BOUNTY

REPORT
Submission Date:08-October-2024

Submitted by
Abhiram T
Aiswarya D
Hazeena Khalid
 CONTENTS

1)Blind SSRF in app.pumble.com........................................................................ 2

2)Blind SSRF in sksc.somaiya.edu ....................................................................... 6
3)Blind SSRF in shop.naturessunshine.com ........................................................ 9
4)SSRF Exploiting File Paths in ravagedband.com ............................................ 12
5)SSRF via File Parameter in otc-jbg.com ......................................................... 16
6)Blind SSRF via HTTP Referer Header and DNS Lookup in ginandjuice.shop .. 20
7)SSRF via File Parameter in testphp.vulnweb.com ......................................... 24
8)SSRF via File Parameter in iobm.edu.pk ........................................................ 27

1
 1) Blind SSRF in app.pumble.com
Summary Title:
Blind Server-Side Request Forgery (SSRF) in Direct Messaging Feature

Target:
app.pumble.com

Technical Severity:
Server Security Misconfiguration > ServerSide Request Forgery (SSRF) > External Low impact

Vulnerability Details:
URL/Location of Vulnerability:
app.pumble.com/workspace/<workspace_id>/profile/<profile_id>
Description:
A Blind ServerSide Request Forgery (SSRF) vulnerability was discovered within the "Direct
Message" feature of the application. By sending a Burp Collaborator payload in a direct
message to oneself, DNS lookups and HTTP requests were triggered, confirming that the
server makes unauthorized external requests.
This vulnerability can be exploited to target internal systems or unauthorized external
services, which may lead to sensitive information disclosure or further exploitation of internal
network services.

Walkthrough & Steps to Reproduce:

Step 1: Log in to the web application as a regular user.
Step 2: Navigate to the "Direct Message" feature.
Step 3: Send a direct message to yourself with the following payload:
http://<yourcollaboratorurl>.com

Step 4: Monitor your Burp Collaborator instance for DNS and HTTP requests.
Step 5: Observe that the server makes outgoing requests to your Collaborator URL, confirming
the SSRF vulnerability.

2
PoC Evidence:

Screenshot 1

Screenshot 2

Screenshot 3

3
Demonstrated Impact:
The SSRF vulnerability allows attackers to manipulate the server into making unauthorized
HTTP and DNS requests to external or internal networks. While in this instance the
exploitation was limited to external requests, the issue can lead to significant impact if
exploited against internal resources, such as metadata services, databases, or internal admin
panels.

Potential Impacts:
• Unauthorized access to internal network services.
• Data exfiltration from internal systems.
• Opportunity for an attacker to pivot deeper into the network.
• Possible exposure of sensitive internal information, depending on where the
requests are directed.

CVSS Score Calculation:

CVSS Score: 5.4 (Medium)

Remediation:
1. Implement Strict Input Validation and Sanitization:
Ensure that URLs provided by users in messages are strictly validated and sanitized to
prevent serverside request forgery.

2. Use Domain Whitelisting:

4
Only allow the server to make HTTP/DNS requests to a predefined set of trusted domains.
Requests to unknown or disallowed domains should be blocked.

3. Monitor and Audit:

Regularly monitor the application logs and DNS requests for unusual or suspicious traffic
patterns, particularly those indicating SSRF attacks.

4. Use Network Segmentation:

Prevent externalfacing servers from communicating directly with internal services unless
explicitly necessary.

5
 2) Blind SSRF in sksc.somaiya.edu
Summary Title:
SSRF via File Parameter leading to /etc/passwd exposure in sksc.somaiya.edu

Target:
sksc.somaiya.edu

Technical Severity:
Server Security Misconfiguration > ServerSide Request Forgery (SSRF) > External Low impact

Vulnerability Details:
URL/Location of Vulnerability:
http://sksc.somaiya.edu/download.php?pdf_path=

Description:
A ServerSide Request Forgery (SSRF) vulnerability was discovered in the pdf_path parameter
of download.php. By using file URIs such as file:///etc/passwd, I successfully retrieved
sensitive files from the server. The SSRF also enables external requests, which was
confirmed through Burp Collaborator callbacks.

Walkthrough & Steps to Reproduce:

SSRF Exploiting File Parameter:
Step 1: Insert the following payload into the pdf_path parameter to retrieve system files:
http://sksc.somaiya.edu/download.php?pdf_path=file:///etc/passwd
Step 2: Successfully retrieve the content of /etc/passwd.
SSRF with External Callbacks :
Step 1: Insert a Burp Collaborator URL in the pdf_path parameter:
http://sksc.somaiya.edu/download.php?pdf_path=http://yourcollaboratorurl.com
Step 2: Monitor Burp Collaborator for DNS and HTTP callbacks to confirm SSRF.

6
PoC Evidence:

Screenshot 1: /etc/passwd content

Screenshot 2: Inserting Burp Collaborator URL in the pdf_path parameter

7
 Screenshot 3: Burp Collaborator callbacks (for SSRF)
Demonstrated Impact:
1. SSRF Exploiting File Paths:
Exposure of sensitive system files such as /etc/passwd and /etc/shadow, potentially leading
to privilege escalation or compromise of server credentials.
2. SSRF with External Callbacks:
The server makes unauthorized external HTTP and DNS requests, which can be leveraged to
target internal services.

Potential Impacts:
• Unauthorized access to sensitive internal files and potential system compromise.
• External HTTP/DNS requests allowing attackers to manipulate internal or external
services.

Remediation:
1. Sanitize File Path Inputs:
Ensure the pdf_path parameter only accepts valid, trusted paths and blocks filebased inputs.
2. Restrict SSRF with Domain Whitelisting:
Ensure that the application only makes external requests to trusted domains.
3. Audit Server Requests:
Monitor file access and external requests to detect unauthorized activity.
4. Implement Strict File Access Controls:
Restrict access to sensitive files like /etc/passwd to prevent disclosure.

8
 3) Blind SSRF in shop.naturessunshine.com

Summary Title:
Blind Server-Side Request Forgery (SSRF) in Image Loading Feature of
shop.naturessunshine.com

Target:
shop.naturessunshine.com

Technical Severity:
Server Security Misconfiguration > ServerSide Request Forgery (SSRF) > External Low impact

Vulnerability Details:
URL/Location of Vulnerability:
https://shop.naturessunshine.com/_next//image?w=16&q=10&url=

Description:
A Blind SSRF vulnerability was identified in the image loading functionality. The url
parameter allows the attacker to append an external URL, resulting in the server making
unauthorized HTTP and DNS requests, confirmed via Burp Collaborator callbacks.

Walkthrough & Steps to Reproduce:

Step 1: Append the Burp Collaborator URL to the url parameter:
https://shop.naturessunshine.com/_next//image?w=16&q=10&url=https://yourcollaborato
rurl.com
Step 2: Observe DNS and HTTP callbacks in Burp Collaborator.

9
PoC Evidence:

Screenshot 1: Burp Collaborator URL to the url parameter

Screenshot 2: DNS and HTTP callbacks in Burp Collaborator

10
 Screenshot 3: DNS and HTTP callbacks in Burp Collaborator

Demonstrated Impact:
The SSRF vulnerability allows attackers to manipulate the server into making unauthorized
HTTP and DNS requests to external or internal networks.

Potential Impacts:
• Unauthorized access to internal network services.
• Data exfiltration or information disclosure.
• Possible targeting of internal systems.

Remediation:
1. Validate and Sanitize URLs: Ensure the url parameter only accepts trusted and valid URLs.
2. Use Domain Whitelisting: Only allow external requests to trusted domains.
3. Monitor and Audit Requests: Continuously monitor for abnormal external requests.

11
 4) SSRF Exploiting File Paths in ravagedband.com

Summary Title:
SSRF via File Parameter leading to /etc/passwd exposure in ravagedband.com

Target:
ravagedband.com

Technical Severity:
Server Security Misconfiguration > ServerSide Request Forgery (SSRF) > External Low impact

Vulnerability Details:
URL/Location of Vulnerability:
https://ravagedband.com/index.php?page=home.php

Description:
A ServerSide Request Forgery (SSRF) vulnerability exists in the page parameter of the
website. By injecting file URIs such as file:///etc/passwd into the page parameter, I was able
to access sensitive server files like /etc/passwd and /etc/shadow. The server erroneously
processes the file paths and returns the contents, leading to exposure of sensitive system
information.

Walkthrough & Steps to Reproduce:

SSRF Exploiting File Parameter:
Step 1: Modify the page parameter in the URL to include a local file path:
https://ravagedband.com/index.php?page=file:///etc/passwd
Step 2: Successfully retrieve the contents of /etc/passwd.
Step 3: Tried accessing more sensitive files:
https://ravagedband.com/index.php?page=file:///etc/shadow
https://ravagedband.com/index.php?page=file:///etc/hosts

12
Step 4: Successfully retrieve the contents of /etc/shadow and /etc/hosts.

PoC Evidence:

Screenshot 1: /etc/passwd content

Screenshot 2: /etc/passwd content reflected on Home Page

Screenshot 3: /etc/shadow content

Screenshot 4: /etc/shadow content reflecting on Home Page

13
 Screenshot 5: /etc/hosts content

Screenshot 6: Result showing /etc/passwd enumeration using SSRFmap tool

Demonstrated Impact:
1. SSRF Exploiting File Paths (Critical Impact):
Direct access to sensitive system files like /etc/passwd and /etc/shadow, /etc/hosts
exposing system credentials and potentially leading to privilege escalation.

Potential Impacts:
• Exposure of critical system files and credentials, which can facilitate further attacks.
• Unauthorized access to internal network resources through SSRF.
• Potential full server compromise through the exploitation of systemlevel credentials.

14
Remediation:
1. Sanitize and Restrict File Path Inputs:
Ensure that the page parameter strictly limits input to valid, trusted paths and does not
accept file URIs like file:///etc/passwd.

2. Prevent SSRF by Validating URLs:

Implement URL validation and ensure that external requests are only allowed to trusted
domains or networks.

3. Audit Server Requests:

Continuously monitor server requests, especially those involving file paths and external
URLs, to detect any unauthorized access attempts.

4. Restrict File Access Permissions:

Enforce strict access policies to prevent system files like /etc/passwd and /etc/shadow from
being exposed to untrusted inputs.

15
 5) SSRF via File Parameter in otc-jbg.com

Summary Title:
SSRF via File Parameter in otcjbg.com leading to exposure of sensitive system files

Target:
otc-jbg.com

Technical Severity:
Server Security Misconfiguration > ServerSide Request Forgery (SSRF) > External Low impact

Vulnerability Details:
URL/Location of Vulnerability:
https://otc-jbg.com/index.php?page=accueil.html

Description:
A Server-Side Request Forgery (SSRF) vulnerability exists in the page parameter of the
website. By modifying the page parameter, I was able to force the server to process file paths
like file:///etc/group and file:///proc/self/environ, leading to exposure of sensitive server
information. Additionally, unauthorized external DNS and HTTP requests were triggered,
confirmed via Burp Collaborator callbacks.

Walkthrough & Steps to Reproduce:

SSRF Exploiting File Parameter:
Step 1: Modify the page parameter to include sensitive file paths(Burp Suite):
https://otc-jbg.com/index.php?page=file:///etc/passwd
https://otc-jbg.com/index.php?page=file:///etc/group
https://otc-jbg.com/index.php?page=file:///proc/version
https://otc-jbg.com/index.php?page=file:///proc/self/environ
Step 2: Successfully retrieve the content of each file, exposing sensitive server details.

16
SSRF with External Callbacks:
Step 1: Modify the page parameter to an external URL:
https://otc-jbg.com/index.php?page=https://yourcollaboratorurl.com
Step 2: Observe DNS and HTTP callbacks on Burp Collaborator, confirming the SSRF.

PoC Evidence:

Screenshot 1: /etc/passwd content

Screenshot 2: /etc/group content

17
 Screenshot 3: /proc/version content

Screenshot 4: /proc/self/environ content

Screenshot 5: Inserting Burp Collaborator URL

Screenshot 6: Burp Collaborator callbacks

18
Demonstrated Impact:
1. SSRF Exploiting File Paths:
Access to sensitive system files, including /etc/group and /proc/self/environ, potentially
exposing critical information about the server environment and system users.
2. SSRF with External Callbacks:
The server makes unauthorized external HTTP and DNS requests, which could be leveraged
to target internal or external services.

Potential Impacts:
• Exposure of sensitive system information and server configuration.
• Unauthorized access to internal resources through SSRF.
• Data exfiltration through file exposure or external requests.
Remediation:
1. Sanitize File Path Inputs:
Ensure that the page parameter strictly limits input to trusted values and does not accept
file URIs like file:///proc/self/environ.
2. Prevent SSRF by Validating URLs:
Implement strict URL validation and ensure that external requests are only made to
whitelisted, trusted domains.
3. Audit Server Requests:
Regularly monitor server activity, particularly file access requests and external URL requests,
to detect unauthorized actions.
4. Implement File Access Controls:
Limit the server's ability to access sensitive system files by restricting file permissions and
blocking access to critical directories like /proc.

19
 6) Blind SSRF via HTTP Referer Header and DNS Lookup in
ginandjuice.shop

Summary Title:
SSRF via HTTP Referer Header and DNS Lookup in ginandjuice.shop

Target:
ginandjuice.shop

Technical Severity:
Server Security Misconfiguration > Server-Side Request Forgery (SSRF) > External - Low
impact

Vulnerability Details:

URL/Location of Vulnerability:
https://ginandjuice.shop/

Description:
It is possible to induce the application to perform server-side HTTP requests and DNS lookups
to arbitrary domains by modifying the HTTP Referer header. A Burp Collaborator payload
(xxxxxxx.oastify.com) was submitted in the HTTP Referer header, and the application
performed an HTTP request and DNS lookup to the specified domain.

This SSRF vulnerability arises from the application accepting and processing external domains
provided in user-controlled headers, such as the HTTP Referer. The issue could potentially
allow attackers to perform external service interactions and use the vulnerable server as a
proxy to attack other systems, both public and internal.

Walkthrough & Steps to Reproduce:

SSRF Exploiting HTTP Referer Header:

• Step 1: Modify the HTTP Referer header to include a Burp Collaborator URL:

20
Referrer: http://xxxxxxx.oastify.com

• Step 2: Send the request and monitor Burp Collaborator for the HTTP request and
DNS lookup.

• Step 3: Confirm that the application made an external HTTP request to the provided
domain and resolved the DNS of the domain.

PoC Evidence:

Screenshot 1: Add referrer header with collaborator payload

Screenshot 2: Burp Collaborator logs showing HTTP request callback.

Screenshot 3: Burp Collaborator logs showing DNS lookup callback.

Demonstrated Impact:

The SSRF vulnerability in ginandjuice.shop can allow attackers to:

21
 • Trigger HTTP requests to arbitrary domains using the vulnerable application server,
which could act as a proxy for further attacks.

• Perform DNS lookups on arbitrary domains, which can be used to exfiltrate

information or probe internal networks.

• Potentially interact with highly sensitive internal services that are not exposed to
external networks, by exploiting the server’s internal connections.

Potential Impacts:

• External Service Interaction:

Attackers could use the vulnerable server to attack third-party systems, perform
data exfiltration, or interact with internal services.

• Internal Network Exposure:

Depending on the network architecture, the SSRF vulnerability could expose
internal services that are typically inaccessible to external attackers, such as
databases, cloud metadata services, or internal admin panels.

• Abuse of Local Loopback Services:

The SSRF could be used to interact with services available only on the local
loopback adapter, further increasing the attack surface and allowing attackers to
probe for other vulnerabilities.

Issue Background:

External service interaction arises when it is possible to induce an application to interact

with an arbitrary external service, such as a web server or mail server. While this might be
intended behavior in some cases, it often suggests a more serious underlying vulnerability. In
this case, SSRF allows the application to be used as an attack proxy.

22
Remediation:

1. Validate and Sanitize HTTP Headers:

Ensure that user-controlled headers, such as the HTTP Referer, are validated and
sanitized. Do not allow untrusted input to control where the server sends HTTP
requests or performs DNS lookups.

2. Use a Whitelist of Allowed Domains:

Implement a whitelist of trusted domains to restrict which external services the
application can interact with. If interaction with external services is not intended,
block all external interactions by default.

3. Block Unnecessary Outbound Traffic:

Restrict network access from the application server to internal services and block
unnecessary outbound traffic, especially to sensitive internal resources.

4. Harden the Application Server:

Secure the server itself by removing any unnecessary services, especially those on
the local loopback adapter, to prevent attackers from interacting with internal
processes.

5. Out-of-Band Application Security Testing (OAST):

OAST techniques can help identify high-risk features in the application that enable
SSRF attacks. Given that external service interactions may be happening across
multiple endpoints, testing all input points with OAST payloads can reveal other

23
 7) SSRF via File Parameter in testphp.vulnweb.com

Summary Title:
SSRF via File Parameter leading to /etc/passwd exposure in testphp.vulnweb.com

Target:
http://testphp.vulnweb.com

Technical Severity:
Server Security Misconfiguration > Server-Side Request Forgery (SSRF) > External - Low impact

Vulnerability Details:
URL/Location of Vulnerability:
http://testphp.vulnweb.com/showimage.php?filename=./pictures1.jpg

Description:
A Server-Side Request Forgery (SSRF) vulnerability was identified on http://testphp.vulnweb.com
within the filename parameter of the showimage.php page. By modifying the filename parameter to
access sensitive system files such as /etc/passwd, an attacker can force the server to perform
unauthorized file retrievals and potentially make external HTTP requests. This vulnerability stems from
improper input validation, allowing the server to process file-based payloads.

Walkthrough & Steps to Reproduce:

SSRF Exploiting File Parameter:
Step 1: Navigate to the following URL:
http://testphp.vulnweb.com/showimage.php?filename=./pictures1.jpg
Step 2: Modify the filename parameter to reference the /etc/passwd file using this payload:
http://testphp.vulnweb.com/showimage.php?filename=../../etc/passwd
Step 3: Submit the modified request using Burp Suite or a web browser.
Step 4: The server responds with the contents of the /etc/passwd file, confirming the vulnerability.

24
PoC Evidence:

Screenshot 1

Demonstrated Impact:
1. SSRF Exploiting File Paths:
o Access to sensitive system files, such as /etc/passwd, can provide valuable
information about user accounts, leading to further attacks like privilege escalation.
This level of access can compromise the server's security significantly.
2. SSRF with External Callbacks:
o The vulnerability also enables the server to make unauthorized external HTTP and
DNS requests. This could be leveraged to probe internal services or attack external
systems.

Potential Impacts:
• Unauthorized access to critical system files such as /etc/passwd.
• Information disclosure about system users, which could lead to privilege escalation or
further exploitation.
• External service interactions that may be used to attack internal or third-party systems.

Remediation:
1. Sanitize and Restrict File Path Inputs:
Ensure that the filename parameter only accepts trusted and valid file paths, and block any
file-based SSRF attacks.
2. Prevent SSRF with URL Validation:
Enforce strict URL validation to ensure that external requests are made only to whitelisted
and trusted domains.

25
3. Audit and Monitor:
Regularly monitor the server’s file access requests and external requests to detect
unauthorized activities.
4. Enforce File Access Controls:
Implement strict file access controls to prevent exposure of sensitive system files like
/etc/passwd and /etc/shadow.

26
 8) Bug Bounty Report: SSRF via File Parameter in iobm.edu.pk
Summary Title:
SSRF via File Parameter leading to External URL Access in iobm.edu.pk
Target:
http://iobm.edu.pk
Technical Severity:
Server Security Misconfiguration > Server-Side Request Forgery (SSRF) > External - Low Impact
Vulnerability Details:
URL/Location of Vulnerability:
http://iobm.edu.pk
Description:
A potential Server-Side Request Forgery (SSRF) vulnerability was identified on http://iobm.edu.pk
within the file parameter of a specific page. By manipulating the file parameter, it was possible to
redirect requests to external URLs, including Colab URLs. This vulnerability stems from improper
input validation, allowing the server to process external payloads. However, while the server could
access the Colab URL,
It did not support HTTP callbacks or DNS resolution for other external addresses.
Walkthrough & Steps to Reproduce:
1. Navigate to the following URL:
http://iobm.edu.pk?URL=
2. Modify the file parameter to reference an external URL:
http://iobm.edu.pk?URL=https://colab_url.com
3. Submit the modified request using a browser or a tool like Burp Suite.
4. Observe the server's response:
The server successfully processed the request, confirming access to the external Colab URL.
PoC Evidence:

27
Screenshot 1

Screenshot 2

28
 Screenshot 3
• Screenshot 1: HTTP request sent with the file parameter referencing the external Colab URL.
• Screenshot 2: Server response showing access to the external Colab URL.
Demonstrated Impact:
• Unauthorized External URL Access:
The vulnerability may allow an attacker to make the server perform unauthorized requests
to external services, potentially exposing sensitive information or enabling further attacks.
However, HTTP callbacks or DNS resolutions to other external addresses were not
supported.
Potential Impacts:
• Exposure to sensitive information through external service interactions.
• Risk of probing internal services by redirecting requests to internal IPs.
• Limited external interaction capabilities, as only specific URLs (like Colab) were accessible.
Remediation:
1. Sanitize and Restrict File Path Inputs:
Ensure that file parameters only accept trusted and valid paths or URLs, blocking any file-
based SSRF attacks.
2. Implement URL Whitelisting:
Enforce strict validation for external URLs to ensure that requests are only made to
whitelisted and trusted domains.
3. Audit and Monitor:
Regularly monitor server access logs for unauthorized activities related to file and external
requests.

29
4. Educate Developers:
Ensure that development teams are aware of SSRF vulnerabilities and best practices for
mitigating them.

30