Important
The responsible disclosure policy has been followed when reporting this vulnerability.
Warning
The information and scripts provided here are intended for research and educational purposes only. Usage of these resources in any way that could compromise the security of a system used in production is strictly prohibited and may lead to legal consequences. The creator of these resources bears no responsibility for any misuse or harm resulting from their utilization.
CVE-2023-48050
SQL injection vulnerability in Cams Biometrics Zkteco, eSSL, Cams Biometrics Integration Module with HR Attendance (aka odoo-biometric-attendance) v. 13.0 thru 16.0.1 allows a remote attacker to execute arbitrary code and to gain privileges via the db parameter in controllers/controllers.py component.
Zkteco, eSSL, Cams Biometrics Integration Module with HR Attendance
odoo-biometric-attendance
https://apps.odoo.com/apps/modules/16.0/odoo-biometric-attendance/
SQL injection
Privilege Escalation, Information Disclosure
controllers/controllers.py:CamsAttendance::generate_attendance(**params)
controllers/controllers.py::is_db_exist(db_name)
A remote attacker of an Odoo instance with the odoo-biometric-attendance module installed on it can call the generate_attendance controller endpoint by sending an HTTP POST request to the /cams/biometric-api3.0/ route with a crafted db parameter. The db parameter is passed to the is_db_exist helper method, injecting the SQL query to the existing one that will be executed through the database cursor.
Note
A recorded demo of the PoC as well as the code for the exploit are available under this directory.
The remote attacker sends a crafted HTTP POST request with the following body:
"db": "' ; UPDATE res_users SET password='whatever' WHERE login='admin'; SELECT 0 FROM pg_database where datname='test' -- "
Since the affected controller route does not require authentication, anyone can reach the generate_attendance endpoint, triggering the attack. The db parameter is passed to the is_db_exist helper method. Since the database cursor is directly employed, no access rights checking is performed. Also, no user input validation or sanitation is performed, allowing the attacker to inject arbitrary SQL queries, with consequences ranging from information disclosure to data tampering and privilege escalation. A possible patch could make use of prepared statements.