Security Advisory: Remote Code Execution on Viasat Modems (CVE-2024-6199)

Introduction

As indicated in previous posts on the subject of automated binary zero-day analysis (Remote Command Execution in Cisco Access Point WAP Products, Spotting Silent Patches in OSS, Remote Code Execution in Delta Electronics DVW Devices, Arbitrary Command Execution on TP-Link Archer C5400X), we tested this feature on our firmware corpus and reported vulnerabilities to affected vendors, creating the base of most of our 2024 advisories.

This one is a bit different, since it was identified by one of our customers the day they opted-in for binary static analysis. Enabling the feature is easy as going to "Analysis Configuration" and checking the "Enable binary zero-day analysis" checkbox.

They already had uploaded Viasat firmwares to the platform, and when the daily monitoring run results came back, a few stack buffer overflows were identified in different binaries.

Remote Command Execution

Description

The

ddns_success

ddns_success binary expects the following commands:

ddns_success -d -t [tzo|tzo-echo|dyndns] -n public_ip -T timeout

The -t parameter indicates which method should be used to obtain the public IP. The following commands are executed by the binary depending on the type parameter:

‍

The dyndns implementation differs a bit since the response is different, but the same vulnerable call to sscanf is observed:

‍

By intercepting HTTP communication between the Viasat terminal and either

echo.tzo.com

echo.tzo.com or

checkip.dyndns.org

checkip.dyndns.org, a remote unauthenticated attacker could return an HTTP response that contains more bytes than the

public_ip

public_ip buffer can hold, leading to a stack buffer overflow.
‍

By taking control of the program register through the overflow, an attacker can redirect the execution flow and execute arbitrary code. ROP chaining won't even be needed since the binary is lacking basic hardening such as non-executable stack.

One interesting bit of information about this ddns_success binary is that Viasat did not have access to the source code as it was provided as-is by a third party supplier. This clearly demonstrate that, sometimes, shifting right is necessary and doing static code analysis at the firmware level is the only way to uncover bugs in binaries you usually have no visibility into.

Key Takeaways

• A critical unauthenticated RCE vulnerability was uncovered in widely deployed satellite modems using ONEKEY’s automated firmware analysis.
• The flaw demonstrates the systemic risks of opaque firmware in devices used across sensitive infrastructures.
• Proactive firmware inspection is essential for both OEMs and integrators to identify and remediate latent threats.
• Transparency and visibility into embedded software are foundational to securing modern connected environments.

Timeline

The coordinated vulnerability disclosure process was easy to navigate even if it was a first for Viasat. They were responsive and open in their communications, indicating what their engineering team was doing and what was happening on the field. Deploying over-the-air updates to different products running in heterogeneous environment is no easy feat, that's why we agreed to a disclosure deadline extension.

During that extension, Viasat kept us up to date on the ratio of patched devices in the field.

The full timeline follows:

• 15/05/2024 - coordinated disclosure request sent to Viasat
• 15/05/2024 - answer from Viasat
• 27/05/2024 - report is sent to Viasat
• 29/05/2024 - sync meeting to discuss findings with Viasat
• 18/06/2024 - sync meeting, requesting an extension to the 90-days disclosure deadline. ONEKEY agrees to follow the whole process.
• 07/01/2025 - sync meeting
• 29/01/2025 - sync meeting, expect fixes deployed by 28/02/2025
• 26/02/2025 - sync meeting, requests disclosure for both CVEs on 28/03/2025
• 12/03/2025 - sync meeting, 28/03/2025 deadline won't be met, asking for an extension
• 02/04/2025 - sync meeting, new disclosure date set to 25/04/2025
• 23/04/2025 - sync meeting
• 25/05/2025 - coordinated public disclosure

‍