Last updated at Tue, 03 Sep 2024 19:12:35 GMT

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 Description R7 ID CVE Exploit Vector
Unauthenticated remote factory reset R7-2016-28.1 CVE-2017-5237 Phone number
Remote device identification R7-2016-28.2 None (identification) Phone number range
Lack of configuration bounds checks R7-2016-28.3 CVE-2017-5238 Phone number
Unauthenticated access to user data R7-2016-28.4 None (server-side issue) Web application
Authenticated user access to other users' data R7-2016-28.5 None (server-side issue) Web application user account
Sensitive information transmitted in cleartext R7-2016-28.6 CVE-2017-5239 Man-in-the-Middle (MitM) Network
Web application data poisoning R7-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.

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.

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:

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.  An example of this shown below in Figure 4:

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.

Figure 5: Access to another user's configuration data

Figure 6: Access to Another users Device GPS Data

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:

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).

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.