Title: SKIDATA RFID Freemotion.Gate Unauthenticated Web Service Aribtrary Remote Command Execution Product: Freemotion.Gate Vendor: SKIDATA, http://www.skidata.com/en/ RTP|One, http://http://www.rtp.com/ Vulnerable Versions: 4.1.3.5 and likely all prior versions. Tested Version: 4.1.3.5 Original Advisory: http://keepingkidsonshred.com/2013/11/skidata-rfid-freemotiongate.html Credit: Dennis Kelly Introduction SKIDATA RFID gates have a long history of use in Europe, and in the past five years, have gained traction at mountain resorts in North America. The Freemotion.Gate is their mountain product with an RFID reader and turnstile for lift access control, integrating with their Point of Sale (PoS) system or RTP|One for tickets and passes. The intended method for controlling the gates with RTP|One is to load the SKIDATA Monitor module within the RTP|One client application (referred to as the Container), which requires authentication and authorization to the module. A packet analysis shows the SKIDATA Monitor connects to an instance of the RTP|One Gate Service, a web service that manages one or more gates. The Gate Service server loads guest and pass information from the RTP|One database for display in the SKIDATA Monitor and also connects to another web service running on the Freemotion.Gate to open it and control operational modes. The Freemotion.Gate controller is a Atmel AT91RM9200-DK based computer running Emlix Linux and a web service on port 7777: [SKIDATA Monitor] --- TCP port 8001 ---> [Gate Service] --- TCP port 7777 ---> [Gate] Further inspection reveals security vulnerabilities: - Traffic between the SKIDATA Monitor and Gate Service is not encrypted. - The payload sent to the Gate Service does not require authentication. It only includes the Operator ID (authenticated username) from the SKIDATA Monitor when issuing commands that control the gate. - Traffic between the Gate Service and Gate is not encrypted. - The payload sent to the Gate that opens the gate or changes its operational mode does not require authentication or require any user information. Impact Both the Gate Service and Gate are vulnerable to unauthenticated remote command execution. For the purpose of this advisory, we will focus on the SKIDATA Freemotion.Gate, as it is the most likely to not be on a separate, firewalled network, nor does it require any user information, falsified or not. Copying the XML payload for each gate command will allow an attacker to easily send a crafted message to control the gate directly. An example to manually open the gate, allowing someone through without a ticket (which at some resorts could cost close to $100): curl -X POST --header "Content-Type:text/xml" \ --data-binary @manual-release.raw \ http://[target IP]:7777/skidata/hessian/CP > /dev/null 2>&1 Where manual-release.raw is a file containing the data payload extracted from Wireshark (or your preferred network analysis tool) Other possibilities include putting gates in different modes: - Blocked and Out of Order modes, causing a denial of service to all gate users. - Open mode, where the turnstile remains down, allowing anyone to freely pass through the gate. - Free pass mode, where the turnstile remains up, but allows all gate users through without requiring a valid ticket or pass, and far more subtle to an operator. Vendor Response The RTP|One application is PCI compliant and customers should take necessary steps to segregate and secure their networks. Mitigation Make sure Gate Service servers and Gates are segmented from the rest of the network. Apply ACLs or firewall rules to prevent unauthorized hosts from accessing Gate Service and Gate web services. Timeline 2013-11-05: Vulnerability discovered 2013-11-06: Vendor contacted 2013-11-06: Vendor acknowledgement 2013-11-19: Vendor response 2013-11-19: Advisory released