Skidata RFID Freemotion.Gate Remote Command Execution

2013-11-19T00:00:00
ID PACKETSTORM:124079
Type packetstorm
Reporter Dennis Kelly
Modified 2013-11-19T00:00:00

Description

                                        
                                            `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 <dennis.kelly@gmail.com>  
  
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  
`