Message-ID: <CAJX8c4JB6zEE8mazACS59qUoRoyCzrJ390gJ3_mmuQOJyw0f9g@mail.gmail.com>
Date: Tue, 19 Nov 2013 11:31:29 -0800
From: Dennis Kelly <dennis.kelly@...il.com>
To: bugtraq@...urityfocus.com
Subject: SKIDATA RFID Freemotion.Gate Unauthenticated Web Service Aribtrary
 Remote Command Execution

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@...il.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

Powered by blists - more mailing lists