Rapid7 Blog

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

POST STATS:

SHARE

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.

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.

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:

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=allTrackerswith a the target's userID number to the API. An example of this shown below in Figure 4:

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.

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 athttp://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:

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

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.