A Server-Side Template Injection (SSTI) was discovered in Form.io 2.0.0. This leads to Remote Code Execution during deletion of the default Email template URL.

**Server-Side Template Injection in formio**

Moderate severity GitHub Reviewed Published Jun 3, 2022 • Updated Jun 3, 2022

GHSA-52vj-mr2j-f8jh: Server-Side Template Injection in formio

A CWE-20: Improper Input Validation vulnerability exists that could cause potential remote code execution when an attacker is able to intercept and modify a request on the same network or has configuration access to an ION device on the network. Affected Products: Wiser Smart, EER21000 & EER21001 (V4.5 and prior)

Schneider Electric is aware of a vulnerability in its PowerLogic ION Setup product. The PowerLogic ION Setup product is an engineering tool for configuration and maintenance of PowerLogic metering devices. Failure to apply the remediations provided below may risk remote code execution, which could result in a compromise of the engineering workstation running the ION Setup software.

Date : 06/05/2022 Type : Security and Safety Notice  

Languages : English Latest Version : 1.0

Reference : SEVD-2022-130-01

Date : 06/05/2022 Type : Security and Safety Notice Languages : English Latest Version : 1.0 Reference : SEVD-2022-130-01

CVE-2022-30232: Security Notification - PowerLogic ION Setup | Schneider Electric

Uncontrolled resource consumption in Mattermost version 6.6.0 and earlier allows an authenticated attacker to crash the server via a crafted SVG attachment on a post.

CVE-2022-1982: Security Updates

NetScout nGeniusONE 6.3.2 allows an XML External Entity (XXE) attack.

**NETSCOUT Security**

**CVE-2021-45981**

CVE

Title

Version

Severity

CVE-2021-45981

XML External Entity (XXE)

6.3.2

Base

**Summary**

NETSCOUT Systems in nGeniusONE version 6.3.2 build 904 allows XML External Entity (XXE) attacks. Attack complexity is high. Privileges required none. User interaction required and scope is unchanged.

NetScout Systems would like to acknowledge Lukasz Plonka for reporting CVE-2021-45981 to techsupport@netscout.com

   
**Fixed Software**

Customers should install patch 6.3.2 P12 to eliminate this vulnerability. The patch is available on My NETSCOUT account page or may be obtained by contacting NETSCOUT support at 1-800-708-4784. Please note all future versions include this fix.

techsupport@netscout.com

**CVE-2021-45982**

CVE

Title

Version

Severity

CVE-2021-45982

Arbitrary File Upload

6.3.2

Base

**Summary**

NETSCOUT Systems in nGeniusONE version 6.3.2 build 904 allows an Arbitrary File Upload vulnerability. Attack complexity is high. Privileges required low. User interaction required and scope is unchanged.

NetScout Systems would like to acknowledge Lukasz Plonka for reporting CVE-2021-45982 to techsupport@netscout.com

   
**Fixed Software**

Customers should install patch 6.3.2 P10  to eliminate this vulnerability. The patch is available on My NETSCOUT account page or may be obtained by contacting NETSCOUT support at 1-800-708-4784. Please note all future versions include this fix.

techsupport@netscout.com

**CVE-2021-45983**

CVE

Title

Version

Severity

CVE-2021-45983

Java RMI Remote Code Execution

6.3.2

Base

**Summary**

NETSCOUT Systems nGeniusONE version 6.3.2 build 904 allows Java RMI Code Execution attacks. Attack complexity is high. Privileges required none. User interaction required and scope is unchanged.

NetScout Systems would like to acknowledge Lukasz Plonka for reporting CVE-2021-45982 to techsupport@netscout.com

   
**Fixed Software**

Customers should install 6.3.2 P12 to eliminate this vulnerability. The patch is available on My NETSCOUT account page or may be obtained by contacting NETSCOUT support at 1-800-708-4784. Please note all future versions include this fix.

techsupport@netscout.com

**CVE-2021-35205**

CVE

Title

Severity

Published

Updated

CVE-2021-35205

Open Redirection

Medium

09/30/2021

10/04/2021

**Summary**

NETSCOUT Systems nGeniusONE version 6.3.0 build 1196 allows URL redirection in redirector. The Attack complexity is low, and the privileges required are also low. User Interaction required, and Scope is unchanged

  **Fixed Software**

Customers should request a patch 6.3.2 FCS B426 to eliminate this vulnerability. This is available on the My NETSCOUT page or may be obtained by contacting NETSCOUT support at 1-800-708-4784.  Please note that all future versions include this fix.

techsupport@netscout.com

**CVE-2021-35204**

CVE

Title

Severity

Published

Updated

CVE-2021-35204

Cross-Site Scripting (XSS)

Medium

09/30/2021

10/04/2021

**Summary**

NETSCOUT Systems nGeniusONE version 6.3.0 build 1196 allows Reflected Cross-Site Scripting (XSS) in the support endpoint. Attack Complexity required is low. Privileges required are low and User Interaction required, and Scope is unchanged. The victim has to click on the provided URL.

**Fixed Software**

Customers should request a patch 6.3.0 P6 B1413 to eliminate this vulnerability. This is available on the My NETSCOUT page or may be obtained by contacting NETSCOUT support at 1-800-708-4784.  Please note that all future versions include this fix.

techsupport@netscout.com

**CVE-2021-35203**

CVE

Title

Severity

Published

Updated

CVE-2021-35203

Incorrect Access Control

Medium

09/30/2021

10/04/2021

**Summary** 

NETSCOUT Systems nGeniusONE version 6.3.0 build 1196 allows Arbitrary File Read operations via the FDSQueryService endpoint. The attacker needs to send a specially crafted request with a parameter with the file name to read. The Attack Complexity is low, and the privileges required are low. User Interaction is required, and Scope is unchanged

**Fixed Software**

 Customers should request a patch 6.3.0 P6 B1413 to eliminate this vulnerability. This is available on the My NETSCOUT page or may be obtained by contacting NETSCOUT support at 1-800-708-4784. Please note that all future versions include this fix.

 techsupport@netscout.com

**CVE-2021-35202**

CVE

Title

Severity

Published

Updated

CVE-2021-35202

Insecure Permissions

Medium

09/30/2021

10/04/2021

**Summary**

NETSCOUT Systems nGeniusONE version 6.3.0 build 1196 allows Authorization Bypass (to access an endpoint) in FDSQueryService. Attack Complexity is Low. The attacker can reach endpoints that are restricted. User Interaction is required, and Scope is unchanged

  **Fixed Software**

Customers should request a patch 6.3.0 P6 B1413 to eliminate this vulnerability. This is available on the My NETSCOUT page or may be obtained by contacting NETSCOUT support at 1-800-708-4784.  Please note that all future versions include this fix.

techsupport@netscout.com

**CVE-2021-35201**

CVE

Title

Severity

Published

Updated

CVE-2021-35201

XML External Entity (XXE)

Medium

09/30/2021

10/04/2021

**Summary**

NETSCOUT Systems NEI in nGeniusONE version 6.3.0 build 1196 allows XML External Entity (XXE) attacks. Attack Complexity is High, Privileges Required None, User Interaction Required and Scope is unchanged.

**Fixed Software**

Customers should request a patch 6.3.0 P4 B1406 to eliminate this vulnerability. This is available on the My NETSCOUT page or may be obtained by contacting NETSCOUT support at 1-800-708-4784.  Please note that all future versions include this fix.

techsupport@netscout.com

**CVE-2021-35200**

CVE

Title

Severity

Published

Updated

CVE-2021-35200

Stored Cross-Site Scripting (XSS)

Medium

09/30/2021

10/04/2021

**Summary**

NETSCOUT Systems nGeniusONE version 6.3.0 build 1196 has stored cross-site scripting in FDSQueryService vulnerability that a high-privileged user can exploit. This would require a user with high privileges. Attack complexity is High, and the Scope is Unchanged

**Fixed Software**

Customers should request a patch 6.3.0 P5 B1411 to eliminate this vulnerability. This is available on the My NETSCOUT page or may be obtained by contacting NETSCOUT support at 1-800-708-4784.  Please note that all future versions include this fix.

techsupport@netscout.com

**CVE-2021-35199**

CVE

Title

Severity

Published

Updated

CVE-2021-35199

Stored Cross-Site Scripting (XSS) in UploadFile

Medium

09/30/2021

10/04/2021

**Summary**

NETSCOUT Systems nGeniusONE version 6.3.0 build 1196 and earlier has stored cross-site scripting in Packet Analysis module Upload File vulnerability that a normal user can exploit. This requires a little crypto knowledge to exploit. The vulnerability exists in upload functionality.

**Fixed Software**

Customers should request a patch 6.3.0 P5 B1411 to eliminate this vulnerability. This is available on the My NETSCOUT page or may be obtained by contacting NETSCOUT support at 1-800-708-4784.  Please note that all future versions include this fix.

techsupport@netscout.com

**CVE-2021-35198**

CVE

Title

Severity

Published

Updated

CVE-2021-35198

Stored Cross-Site Scripting (XSS) in the Packet Analysis module

Medium

09/30/2021

10/04/2021

**Summary**

NETSCOUT Systems nGeniusONE version 6.3.0 build 1004, and earlier has a stored cross-site scripting vulnerability that a normal user can exploit. The user would need to visit a certain functionality in the packet module for the Stored XSS to get executed.

**Fixed Software**

Customers should request a patch 6.3.0 P5 B1411 to eliminate this vulnerability. This is available on the My NETSCOUT or may be obtained by contacting NETSCOUT support at 1-800-708-4784.  Please note that all future versions include this fix

techsupport@netscout.com

**CVE-2020-28251**

CVE

Title

Severity

Published

Updated

CVE-2020-28251

Escalated Privileges Vulnerability on AirMagnet Enterprise Sensors

High

2020 December 03

2020 December 07

NETSCOUT Systems AirMagnet Enterprise version 11.1.4 build 37257 and earlier has a sensor escalated privileges vulnerability that can be exploited to provide someone with administrative access to a sensor, with credentials to invoke a command to provide root access to the operating system. The attacker must complete a straightforward password-cracking exercise.

The affected product models are:

*   SENSOR6-R1S0W1-E
*   SENSOR6-R2S1-E
*   SENSOR6-R2S1-I
*   SENSOR4-R1S1W1-E
*   SENSOR4-R2S1-E
*   SENSOR4-R2S1-I

A software upgrade to AirMagnet Enterprise version 11.1.4 build 37271 to eliminate this vulnerability is available on My NETSCOUT accounts on the AirMagnet Enterprise Downloads page or may be obtained by contacting AirMagnet support at 1-800-708-4784.

  techsupport@netscout.com

CVE-2021-45981: Security Advisories | NETSCOUT

Couchbase Server before 7.1.0 has Incorrect Access Control.

CVE-2021-33504: Alerts | Couchbase

Bonita Web 2021.2 is affected by a authentication/authorization bypass vulnerability due to an overly broad exclude pattern used in the RestAPIAuthorizationFilter. By appending ;i18ntranslation or /../i18ntranslation/ to the end of a URL, users with no privileges can access privileged API endpoints. This can lead to remote code execution by abusing the privileged API actions.

**Bonita Web****Requirements**

This project bundles the Maven Wrapper, so the mvnw script is available at the project root.

**Dependencies**

The project depends on bonita-engine artifacts so if you want to build a branch in a SNAPSHOT version, you must build the bonita-engine first (install artifacts in your local repository).

If you build a tag, you don't need to build the bonita-engine as its artifacts are available on Maven Central.

**Contribution**

I you want to contribute, ask questions about the project, report bug, see the contributing guide.

**Build the project**

At root level (same location as the parent pom.xml) :

**Execution in hosted mode**

In server module, to build and launch a tomcat hosting the app :

    ./mvnw clean verify org.codehaus.cargo:cargo-maven2-plugin:run -DskipTests
    

H2 database is created (if it does not already exist) in ${user.home}/bonita/community/database When you checkout a different branch you need to clean this directory because the database schema may have changed.

Hot reload is not supported, but when you update a class in portal/, server/ or common/ in your IDE all you need to do is to restart the tomcat with the previous command (classes will be retrieved from the projects target/classes directory)

**Structure****Parent pom.xml**

Contains the common maven configuration such as:

*   the definition of all the dependencies version, e.g., junit.version, bonita.engine.version, gwt.version, ...
*   the maven repositories

**common module**

Contains the back-end business logic, i.e., the code executed on the server side. But also contains shared code between back end and front (e.g. model) and the implement of the REST API.

**test-toolkit**

Contains integration tests utils

**server module**

Contains the server side code of portal

CVE-2022-25237: GitHub - bonitasoft/bonita-web

LinkPlay Sound Bar v1.0 allows attackers to escalate privileges via a hardcoded password for the SSL certificate.

From: Lifeng Zhao <lifeng.zhao@linkplay.com> Sent: Sunday, December 12, 2021 5:03 PM To: Hidden Subject: Re: Security Vulnerability \*\*\* The Answer \*\*\* Hi Ohana, Thank you very much for your detailed report on the security vulnerability. It's super helpful and important to us. We'll take the immediate action to fix this. Thank you again for your great support. Best, Lifeng From: Hidden Date: 2021-12-12 21:24 To: security@linkplay.com Subject: Security Vulnerability \*\*\* The vulnerability \*\*\* Bug Type: Hard-coded secret key Impact: RCE, Supply chain attack Platforms: IOS + Android applications Our lab team has reviewed your product from a security perspective and noticed a few security issues that you should be aware of (technical details provided below). It is important to note that CyberArk Labs follow the security industry standard disclosure policy. We allow 90 days for the issues to be fixed/patched/mitigated. CyberArk Labs reserves the right to publicly disclose all information about the issues after this timeframe. We would be happy to share any additional information and to cooperate with you in mitigating the issue in a timely fashion. Summary: We can access an admin user in the Artifactory JFrog system, through which you can manage all the code of the applications and change it. As a result, we can change the application code across multiple tenants, ending with full RCE over every app. It is important to note, however, that both Android and IOS applications suffer from these vulnerabilities In details: We found the API key for admin and the password of the SSL client certificate have been hardcoded and stored on the application SoundBar (com.wifiaudio.Yamaha). To exploit this, you can add the API key to each request sent to the server. 1.Within the SoundBar application, we found the password of certificate\_new\_encrypted.p12 SSL certificate file. Using this certificate, we can communicate with the Soundbar device on port 443. Besides that, we found that the file is encoded with the XOR operator with the number 2. Therefore, it is simple to overcome the encoding. As a result, we can communicate with HTTPS requests with the device. 2. Also, we found that the application sends logs to the URL https://log.linkplay.com:8081/artifactory/Android/logs with the header "X-JFrog-Art-Api, and the API key AKCp5bB…. We discovered this API key is the key of the admin user in the system. This is a major security concern because every malicious user can access the JFrog artifactory with full admin access. In other words, a malicious user can corrupt the repository and cause clients to download malicious applications. 3.Moreover, we noticed that the JFROG version (6.2.0) is not up-to-date. The latest version is (7.10.2). Thus, it is vulnerable to the following CVEs: 1. CVE-2020-7931 2. From the frog website Lastly, we found the vulnerability (the admin API key) in many applications. Below are some links to several apps: ·https://play.google.com/store/apps/details?id=com.medion.speaker ·https://play.google.com/store/apps/details?id=com.wifiaudio.Yamaha ·https://play.google.com/store/apps/details?id=com.wifiaudio.triangle ·https://play.google.com/store/apps/details?id=com.wifiaudio.cavalier ·https://play.google.com/store/apps/details?id=com.wifiaudio.jam ·https://play.google.com/store/apps/details?id=com.wifiaudio.FABRIQ ·https://play.google.com/store/apps/details?id=com.zoundindustries.marshallvoice ·https://play.google.com/store/apps/details?id=com.dpiinc.ISBWV418B ·https://play.google.com/store/apps/details?id=com.ihome.ama ·https://play.google.com/store/apps/details?id=com.wifiaudio.iHome ·https://play.google.com/store/apps/details?id=com.wifiaudio.Creative

CVE-2022-28605: hardcoded on LinkPlay app

In Afian Filerun 20220202 Changing the "search_tika_path" variable to a custom (and previously uploaded) jar file results in remote code execution in the context of the webserver user.

CVE-2022-30470: FileRun - Selfhosted File Manager with Sharing and Backup for Photos, Docs & More

Flower, a web UI for the Celery Python RPC framework, all versions as of 05-02-2022 is vulnerable to an OAuth authentication bypass. An attacker could then access the Flower API to discover and invoke arbitrary Celery RPC calls or deny service by shutting down Celery task nodes.

This post discloses two vulnerabilities in Flower, a popular open-source web application deployed along with Celery (a task queue for Python):

*   Lack of CSRF or SSRF protections in Flower, allowing remote API invocations on internally-hosted instances
*   An OAuth authentication bypass allowing anyone to login and access all Flower functionality

These issues are tracked under CVE-2022-30034.

I created a PR which fixes the OAuth bypass and disables the API unless authentication is configured. The maintainer did not respond to attempts at contact so it is unclear if this will be merged: https://github.com/mher/flower/pull/1216.

The vulnerabilities themselves are moderately interesting, but a more interesting question to ask is “what could an attacker _do_ with Flower?”:

*   Invoke arbitrary tasks registered with Celery (basically, RPC; but the tasks would be highly dependent on application context)
*   Apache Airflow is probably the most popular software which uses Celery, and registers a Celery task in a default configuration. Through Flower, an attacker could invoke airflow tasks run with arbitrary parameters, which could (dependent on configuration or other vulnerabilities) be used to achieve RCE

**Background**

Flower is a web app which allows monitoring and managing Celery, which is a task queue for Python.

*   Flower has more than 5000 stars on Github and is included in the default deployments of other extremely popular software such as Apache Airflow.
*   Flower is (or was) included but not enabled by default in some managed Airflow deployments such as Google Cloud Composer.
*   Shodan shows more than 2000 publicly-exposed instances, although most instances appear to require authentication with basic authentication, and thus would not be vulnerable.
*   There are likely many more instances which are only accessible on internal/corporate networks.

**Lack of CSRF and SSRF Protections**

Flower lacks CSRF protection, meaning that if a user with access to a Flower instance visits a malicious website, that site could run JavaScript which calls Flower’s APIs. This would primarily be used to exploit other vulnerabilities, such as through the arbitrary task invocation issue. The lack of CSRF protections apply to all web routes, APIs, and the api/task/events websocket endpoint. In particular, websocket connections can be used to solidly confirm the presence of the vulnerable listener on internal networks and also leak some minor information.

Lack of authentication by default also means that SSRF attacks would be straightforward on any instance not configured for authentication.

Flower also has a strange (i.e. broken) CORS policy, but it doesn’t appear to lead to any additional impact. _Note:_ a recent PR opened the CORS headers up with a wildcard, which would increase the exploitability of CSRF.

Overall, I think the likelihood of CSRF exploitation through Flower is relatively low, so my PR didn’t attempt to add CSRF protections, because doing so would likely require breaking all existing Flower API clients (e.g. requiring a custom HTTP header). Rather, the PR disables the API if authentication is disabled.

**OAuth Bypass Vulnerability**

Flower supports OAuth login via Google, Github, Okta, and Gitlab. When configuring OAuth according to the documentation, Flower requires the user to provide a regular expression which is checked against the user email that Flower receives after the user logs in:

    flower --auth_provider=flower.views.auth.GitLabLoginHandler --auth=.*@example.com
    

The above command line is intended to configure Flower to use Gitlab OAuth and only allow users whose emails are registered with example.com. However, the regular expression check _lacks regex anchors_, thus allowing anyone to authenticate as long as they can sign up to the OAuth identity provider with a user-controlled email.

Example scenarios:

*   For .*@example.com, a valid user might be alice@example.com, but attacker@example.com.attacker.com can also login.
*   Specifying me@gmail.com would only be intended to allow one user to login, but me@gmail.com.attacker.com also works.
*   Because the regular expression is provided on the command line, the period may not be correctly escaped. For a literal period provided in a shell command, a double backslash is generally needed to get a literal backslash in the argument. The documentation examples use either zero or one backslashes. As a result, .*@corp.example.com or .*@corp\.example\.com could be bypassed with attacker@corpZexample.com even if anchors were applied.

**Reproduction**

I demonstrated the vulnerability in a local deployment of Flower with the following configuration:

1.  Create a public Gitlab user user1@tannerprynn.com (the intended user of the application)
    *   Configure an application under this user to login to Flower
2.  Create a second public Gitlab user user1@tannerprynn.com.pry.nz
3.  Flower configuration:
    *   Command-line options --auth_provider=flower.views.auth.GitLabLoginHandler --auth=.*@tannerprynn.com
    *   Environment variables FLOWER_OAUTH2_KEY, FLOWER_OAUTH2_SECRET, FLOWER_OAUTH2_REDIRECT_URI

**Recommendations for Flower**

1.  Disable the API unless authentication is configured for Flower
2.  Implement CSRF protections (primarily relevant to the API); the most straightforward would be to require a custom non-CORS-exempt header for all API requests
3.  Fixing the OAuth bypass will likely require either a breaking change for users, or using custom logic to match the user-provided string without interpreting a single period as a wildcard character

**Post-Exploitation**

With the ability to send requests to Flower, an attacker would primarily use its APIs - in particular, POST /api/task/apply/{taskname} which allows invoking any Celery task. Assuming the attacker is not operating through blind CSRF, they can use GET /api/task/types and other APIs to list which tasks can be called and the parameters, and attempt to exploit those specific tasks. Given the expectation that these calls would only come from internal, trusted systems, it is likely that any custom-developed tasks have vulnerabilities or cause some dangerous actions. However, those vulns would be highly application/context-specific.

I was interested in one specific deployment of Flower, which is with Airflow, a very popular open-source app. Flower is deployed without authentication in the default Airflow configuration (when deployed with the recommended docker-compose configuration and Helm chart). Airflow registers a single task airflow.executors.celery_executor.execute_command which allows invoking an Airflow task via the equivalent of a command-line invocation of airflow tasks run.

    POST /api/task/apply/airflow.executors.celery_executor.execute_command HTTP/1.1
    Host: flower:5555
    Content-Type: text/plain
    Content-Length: 84
    
    {"args":[["airflow", "tasks", "run", "example_bash_operator", "runme_1", "1234"]]}
    

Initially, I was relatively confident that this would lead directly to RCE, but it doesn’t appear straightforward:

*   Although the arguments appear to specify a command-line invocation, they don’t actually pass through a shell at any point. Celery passes these arguments through a message queue (e.g. Redis) and they invoke the execute_command Python method after being picked up by an Airflow worker, which then parses the arguments using its own command-line parser.
*   The first three arguments ("airflow", "tasks", "run") are validated and cannot be changed to invoke other airflow CLI commands.
*   The last argument is execution_date_or_run_id which is used unsafely in Airflow’s example_bash_operator, but this argument appears to be validated.

That’s not to say that this is safe. An attacker can still specify arbitrary arguments after airflow tasks run, which would include parameters such as --cfg-path and --subdir. If combined with the ability to write a file somewhere on the filesystem, either of these configuration options allows picking up and running arbitrary python code. Without that ability, the impact would be limited to calling the DAGs/tasks that are already set up on the system.

**Recommendations for Airflow**

1.  If possible, strip all parameters from the arguments provided to this invocation path so that an attacker does not have the ability to change the configuration in a way which might allow unexpected code execution
2.  Although run_id seems to be validated, preventing injection in example_bash_operator, that doesn’t seem to be a documented expectation in general, so you should handle it safely in your example code
3.  If Flower isn’t a necessary component of Airflow, consider removing it from the default docker-compose/Helm setup
4.  Alternatively, set up docker-compose and Helm to use basic auth with randomly-generated passwords for Flower (even a weak static password would actually help limit CSRF/SSRF attacks)

From discussions with the Airflow maintainer, Flower is seen as a development-only tool that should not be used in any production deployment. However, given that Flower itself does not appear to be actively maintained, the Airflow maintainer decided that they would disable Flower by default in their docker-compose and Helm chart (starting in version 2.3.1).

**Disclosure Timeline**

*   05 April 2022: Initial contacts to Apache Security team
*   06 April 2022: Partial disclosure to Airflow maintainer of impact and recommendations for Airflow
*   06 April 2022: Initial attempt to contact the Flower maintainer (mher)
*   06-21 April 2022: Follow up emails to the Airflow maintainer
*   12-25 April 2022: Discussion with Airflow maintainer
*   23-26 April 2022: Attempts to reach a maintainer for Flower via the associated Celery project’s team members, but no team member was able to give me a working contact
*   26 April 2022: Opened an issue on the public Flower repo asking for a security contact
*   03 May 2022: Followed up on the public issue to state that disclosure would occur in 14 days (17 May) due to lack of response
*   16 May 2022: Airflow maintainer requested a short delay to allow a new release of Airflow which disables Flower by default
*   25 May 2022: Airflow updated to 2.3.1
*   26 May 2022: Public disclosure

CVE-2022-30034: Multiple Vulnerabilities in Flower and Downstream Attacks on Airflow

** UNSUPPORTED WHEN ASSIGNED ** An issue was discovered in WinAPRS 2.9.0. A buffer overflow in DIGI address processing for VHF KISS packets allows a remote attacker to cause a denial of service (daemon crash) via a malicious AX.25 packet over the air. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

Hackers have been breaching computer system defenses for more than half a century, and the networks they use to exploit those weaknesses have been around for far longer than that. With the internet replacing most wirelines and wavelengths, and with the rise of cybercrime sophistication from petty thieves to organized nation-states, the threat landscape has exploded over the last 20 years. Yet one of the oldest network protocols – amateur or “ham” radio – is still used to this day in emergency communications during times of war and disaster, and to this day can still be used in binary exploitation.

Ham radio evokes an image of old guys turning knobs on vintage, tube radios and talking to other hobbyists about their configurations. Nowadays, radios are getting much more complicated, and with the built-in ability to perform digital communications, the possibilities are almost limitless. You can hook them up to computers to do anything from text messaging and email to sharing images and tracking weather balloons. There’s still something magical about connecting to a device or contacting someone across the planet without being hooked up to the internet or a phone line.

I recently passed the Offensive Security Exploit Developer (OSED) exam and wanted to apply what I’d learned to real-world security problems. I’m always looking for ways to improve my threat modeling, attack simulation, and penetration testing skills, and thought that ham radio would be a fun environment to explore. Amateur radio equipment and frequency spectrums are accessible all over the world and are instructive for a blog series that shows how the vulnerabilities of older technologies can be leveraged with today’s hacking fundamentals. With ham radio as our testing and proving ground, we’ll look at reverse engineering, the creation of custom exploits, and developing skills to bypass security mitigations. We’ll also take a look at writing handmade Windows shellcode and adopting older techniques to more modern versions of Windows.

**Packet Radio**

I've been messing around with packet radio and various digital modes on and off for years and have wondered if any vulnerabilities exist that could allow an attacker to obtain remote code execution through the airwaves. I always thought it was a fun idea to be able to hack a computer that isn't even hooked up to the internet. Many ham programs are written by enthusiasts and are quite old, so it seemed likely that there would be exploitable vulnerabilities. In my research I decided to focus mainly on vulnerabilities that could lead to remote code or command execution, though if I found other vulnerabilities, I didn't ignore them. I also decided to start by focusing on Windows software, since the OSED exam focused on Windows user-mode exploitation and it's where I have the most experience. I started this project with a specific goal in mind: get a remote shell over ham radio.

As a hacker, I am most interested in the various digital modes that ham radio has to offer. There are many, and for my research I decided to focus on software that uses the AX.25 protocol.

"Packet radio" generally refers to a very specific digital mode of operation that uses the AX.25 protocol. AX.25 is a data-link layer protocol (layer 2 of the OSI model). In this mode, data is split into packets and transmitted over the air. AX.25 has support for different packet types and includes modes that are similar to Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) on Ethernet. In some cases, the protocol can do some error correcting, like TCP. Another mode will just send packets out into the air without waiting for any kind of acknowledgement, like UDP. Windows does not have any built-in way to handle AX.25 traffic, so end-user software would have to do this on its own or it must be abstracted away. The Linux kernel has built-in support for AX.25, so you can potentially set up AX.25 network interfaces that have callsigns for addresses instead of IP addresses.

AX.25 is commonly used today for Automatic Packet Reporting System (APRS), Winlink email over ham radio, Bulletin Board Systems (BBS) operations, and more. It seems it is more generally used for a ham to make a contact with a computer, as opposed to making live contacts with other hams. More information about the AX.25 protocol can be found here: http://www.ax25.net/AX25.2.2-Jul%2098-2.pdf

**Automatic Packet Reporting System (APRS)**

The most common use of AX.25 is with the Automatic Packet Reporting System (APRS). Therefore, I decided to focus first on APRS software for this research project. APRS allows hams to transmit telemetry data such as GPS coordinates, weather data, small generic messages, and more. An APRS station can send out a broadcast message, or it can send a message addressed to another specific station. Since the range on the 2m band isn’t that great, APRS stations can “digipeat” the packets out again. This means that if one station receives a packet, it will retransmit it to send it further away. There are also “IGate” systems which are bridged to the internet via the APRS Internet Service (APRS-IS) backbone (http://www.aprs-is.net). This adds extra usability to the APRS system and means you can transmit data globally using the internet if desired. In fact, you can view APRS traffic anywhere in the world at https://aprs.fi and you don’t even need a license to check it out.

How do APRS stations find each other? How does one station find an IGate to bridge to the internet? You can transmit APRS on basically any amateur frequency for which you are licensed, but around the globe each region generally has an allotted frequency where this traffic is used. In the US, that frequency is 144.390 MHz. Just about anywhere in the country you can tune a radio to this frequency and hear data being transmitted at least every minute or so.

APRS is a protocol that runs on top of AX.25, like how HTTP runs on top of TCP. APRS packets make use of the AX.25 unnumbered information (UI) frames. Since I was going to be reverse engineering APRS software, it made sense to examine APRS data frames to understand their structure. AX.25 UI frames look like this:

  
**Image from** **http://www.aprs.org/doc/APRS101.PDF**

In an AX.25 UI frame, all addresses will be ham radio callsigns with an optional SSID appended to them. If your callsign was K7HAX, your address could be something like K7HAX-14. The digipeater addresses field can contain up to eight digipeater addresses to specify the path the packet should take. A digipeater is a radio station that listens for packets and then retransmits those packets to extend the range. The information field contains user-specified data. APRS makes heavy use of this field and it’s likely to be the most interesting field to play with.

The APRS specification allows for various data types, formats, and encodings. Most of this information is stored in the information field of the AX.25 packet. A generic APRS information field structure looks like this:

  
**Image from** **http://www.aprs.org/doc/APRS101.PDF**

The data type specifies what kind of APRS data follows. Options include GPS position, direction finding, weather information, messages, and more. Here’s a real APRS message I pulled from https://aprs.fi:

:Are you working tonight?

The colon denotes that the APRS data contains a message. The rest of the data is just the plaintext message. In this case the APRS data extension and comment fields are unused. Here’s another example:

\=3319.44S/06012.46W# 144.930MHz. SNDigi

The equal sign denotes that the data contains position data without a timestamp. Immediately following that is the actual position data. Between the two coordinates is a forward slash and immediately following the data is a hash symbol. Combined, these symbols would make “/#”. This data tells the receiving station what type of station sent the message and what symbol or icon to use to display the station on a map.

APRS has two tables full of different symbols (car, truck, bicycle, balloon, etc.). The forward slash specifies which table to use. The hash tells which symbol to use in that table. After the hash symbol is some additional message data which appears to list the transmitting frequency and probably the software or device used to transmit (SNDigi). There’s so much more to APRS than just this but it gives a rough idea of how the packets look and what we can expect APRS software to be doing when decoding messages. More information about the APRS protocol can be found here: http://www.aprs.org/doc/APRS101.PDF

Since APRS is probably the most common packet protocol in use today, and there is no shortage of APRS software to choose from, I decided to start my research here. I focused on Windows-based APRS software that was written in C or C++ so I could continue honing my IDA and WinDbg reversing skills.

**Hardware for Packet Radio**

There is a huge number of combinations of hardware to get on the air with packet, but in general you’ll need three main components: a transceiver, a terminal node controller (TNC), and a computer. You use the computer to interact with the various packet radio software you want to use. The transceiver sends and receives the communications over the radio. The TNC is basically a packet radio modem that sits between the two, converting the data into sound. It works similarly to a dial-up modem, but for radio instead of telephone lines. A TNC is typically a little box that’s hooked up to the computer and the radio. A TNC will often have a built-in microcomputer with its own operating system so you can open a terminal and send and receive messages right from the TNC. My TNC has a built-in mailbox where other hams can leave messages. It can decode APRS messages with its own software and display them in a human-readable format via serial console. Here’s a photo of the hardware I’m using for my receiving station:

****

**Keep It Simple, Stupid! (KISS)**

Each TNC make and model has its own set of commands you must use to send packets, and they may display packets differently to the user. The computer software must therefore understand how to interface with each make and model, which is cumbersome. To remedy this, most TNCs support a mode called KISS (Keep It Simple, Stupid). This mode disables all the “smart” features of the TNC and turns it into a dumb modem. The TNC will simply demodulate the signals from the radio and transmit the raw data back to your PC and vice versa. To simplify things, I’ll be placing my TNC into KISS mode for testing and using it wherever possible.

The important bit to know about the KISS protocol is that the TNC will add a 0xC0 control character to the beginning and end of each packet, and it will expect those characters to be there for any outgoing transmissions. There are also a few other special control characters the TNC will watch for, which is important to be aware of when writing shellcode later. These characters would be considered “bad characters” when writing shellcode and must be avoided. A full description of the KISS protocol can be found here: http://www.ax25.net/kiss.aspx

**Choosing an APRS Program**

The aprs-is.net website has a list of some known APRS client software.

Looking over the list, I figured an older client would be the most likely to contain exploitable memory corruption vulnerabilities. Looking at the various options, I found that the WinAPRS download page said it hadn't been updated since January 14, 2013. I figured that was a good sign that the software was likely not maintained and would therefore contain vulnerabilities. I downloaded the latest version (2.9.0) and got to work.

**Next Steps**

The next post in this series will discuss the reverse engineering process using WinDbg. We’ll dive into the nitty gritty technical details of an exploitable memory corruption vulnerability in WinAPRS including how it was found and why it’s exploitable.

Tag

#rce