todb

R7-2016-28: Multiple Eview EV-07S GPS Tracker Vulnerabilities

Blog Post created by todb Employee on Mar 27, 2017

Seven issues were identified with the Eview EV-07S GPS tracker, which can allow an unauthenticated attacker to identify deployed devices, remotely reset devices, learn GPS location data, and modify GPS data. Those issues are briefly summarized on the table below.

 

These issues were discovered by Deral Heiland of Rapid7, Inc., and this advisory was prepared in accordance with Rapid7's disclosure policy.

 

Vulnerability DescriptionR7 IDCVEExploit Vector
Unauthenticated remote factory resetR7-2016-28.1CVE-2017-5237Phone number
Remote device identificationR7-2016-28.2

None

(identification)

Phone number range
Lack of configuration bounds checksR7-2016-28.3CVE-2017-5238Phone number
Unauthenticated access to user dataR7-2016-28.4

None

(server-side issue)

Web application
Authenticated user access to other users' dataR7-2016-28.5

None

(server-side issue)

Web application user account
Sensitive information transmitted in cleartextR7-2016-28.6CVE-2017-5239Man-in-the-Middle (MitM) Network
Web application data poisoningR7-2016-28.7

None

(server-side issue)

Web application

 

Product Description

The EV-07S is a personal GPS tracker device used for personal safety and security, described at the vendor's website as being primarily intended for tracking elderly family members; disabled and patient care; child protection; employee management; and pet and animal tracking. Test devices were acquired from Eview directly, and an example is shown below in Figure 1.

f1.png

Figure 1: The EV-07S personal GPS tracker device

 

R7-2016-28.1: Unauthenticated remote factory reset

Given knowledge of the EV-07S's registered phone number, the EV-07S device can be reset to factory level setting by sending "RESET!" as a command in an SMS message to the device. Only the phone number is required; no password or physical access is required to accomplish this task. After a factory reset, the device can then be reconfigured remotely via SMS messages without need of password. The product manual states this functionality, so it appears to be a fundamental design flaw with regard to secure configuration.

 

Mitigation for R7-2016-28.1

A vendor-supplied patch should prevent the device from allowing unauthenticated factory reset without having physical access to the device.

 

Absent a patch, users should regularly check their device to ensure the configuration has not be deleted or altered.

 

R7-2016-28.2: Remote device identification

The EV-07S device, once set up with a password, should not respond to any SMS queries sent to the device's phone number. According to the user manual, no password is needed to send "reboot" and "RESET!" commands to the device. Testing showed, in spite of user manual statement, that the "reboot" command required a password if device is set up for authentication. Further manual fuzzing test via SMS reveled that the command "REBOOT!" will cause the device to respond with the message "Format error!".

 

Due to providing this negative response, a malicious actor could use this command to enumerate all devices by trying all likely phone numbers, commonly known as a war dialing operation, using SMS messages containing the "REBOOT!" command.

 

f2.png

Figure 2: SMS command response on password protected device

 

Mitigation for R7-2016-28.2

A vendor-supplied patch should disable the response from the "REBOOT!" command when password protection is enabled.

 

R7-2016-28.3: Lack of configuration bounds checks

Several input configuration fields were discovered to not be performing proper bounds checks on incoming SMS messages. If a device's phone number is known to an attacker, this lack of bounds checking allows the overly long input of one configuration setting to overwrite data of another setting. An example of this is shown in Figure 3, where the "Authorized Number" setting A1 is used to overwrite setting B1:

 

f3.png

Figure 3: Configuration Setting Overflow Via SMS Message

 

Mitigation for R7-2016-28.3

A vendor-supplied patch should implement bounds checks and input sanitization on all entered configuration data.

 

Absent a vendor-supplied patch, users should be mindful of entering any values of excessive length. In the case with Authorized Number setting anything over 20 characters will overwrite the next setting in line.

 

R7-2016-28.4: Unauthenticated access to user data

A malicious actor can gain access to user data including account name, TrackerID and device IMEI id. This is done by posting userId=5XXXX&trackerName=&type=allTrackers with a the target's userID number to the API  at http://www.smart-tracking.com/web/searchTrackerList.do .  An example of this shown below in Figure 4:

 

f4.png

Figure 4: HTTP post to gain access to user data

 

Given the small keyspace involved with guessing valid user IDs of 5 digits, it appears trivial to determine all valid user IDs.

 

Mitigation for R7-2016-28.4

A vendor-supplied patch on the vendor web application should prevent unauthenticated access to individual user data.

 

Absent a vendor-supplied patch, users should be careful when trusting the realtime tracking services with their device.

 

R7-2016-28.5: Authenticated access to other users' data

An authenticated user can gain access to others users configuration and device GPS data if they know or guess a valid userId, device IMEI or TrackerID. The following three examples (Figures 5 through 7) show this level of access from one authenticated account being able to access another account's data.

 

f5.png

Figure 5: Access to another user's configuration data

 

f6.png

Figure 6: Access to Another users Device GPS Data

 

f7.png

Figure 7: Access to Another Users GPS Tracker Configuration

 

Mitigation for R7-2016-28.5

A vendor-supplied patch should prevent access to other users data.

 

Absent a vendor-supplied patch, users should be careful when trusting the realtime tracking services with their device.

 

R7-2016-28.6:  Sensitive information transmitted in cleartext

The web application used for realtime tracking web application, hosted at http://www.smart-tracking.com , does not utilize SSL/TLS encryption for HTTP services. Also the EV-07S device passes IMEI and GPS data to this website over the Internet on TCP port 5050 without any encryption. An example of this captured unencrypted data is show below in Figure 8:

 

f8.png

Figure 8: Unencrypted Transfer of Information From Device Over Port 5050

 

Mitigation for R7-2016-28.6

A vendor-supplied patch on both the server and the client should enable encrypted transfer of data to website, as well as an update of the website to enable HTTPS service and serve these pages only over HTTPS.

 

Absent a vendor-supplied patch, users should be careful when trusting the realtime tracking services with their device.

 

R7-2016-28.7:  Data poisoning

An unauthenticated attacker can poison the realtime tracking data by injecting device data similar to the data structure shown above in Figure 8 to the server at www.smart-tracking.com over TCP port 5050. The attacker can do this only if they know a device's IMEI number, but that data is learnable through mechanisms described above.

 

An example of this is shown in Figure 9, where the device's realtime tracking data was poisoned to make the device appear to be Moscow, Russia (it was not).

 

f9.png

Figure 9: Real time tracking data poisoned

 

Mitigation for R7-2016-28.7

A vendor-supplied patch should enable authentication before allowing device data to be posted to the site on TCP port 5050.

 

Absent a vendor-supplied patch, users should be careful when trusting the realtime tracking services with their device.

 

Disclosure Timeline

  • Mon, Dec 12, 2016: Initial contact made to the vendor.
  • Tue, Dec 20, 2016: Vendor responded and details provided to info@eviewltd.com.
  • Tue, Dec 27, 2016: Disclosure to CERT/CC, VU#375851 assigned.
  • Wed, Mar 08, 2017: CVEs assigned in conjunction with CERT/CC.
  • Mon, Mar 27, 2017: Vulnerability disclosure published.

Outcomes