This advisory is about multiple websites which act as the web control panel server for various GSM and GPS based location devices.

In these sites we found multiple information disclosures as well as exposed APIs which allow an unauthenticated actor to take full control of the exposed API features to control and manage the registered GPS tracking devices (to the same extend a legitimate owner of such a device can control the API).

Due to the large extend of the features exposed via the found APIs, we could only verify some of the features via proof-of-concepts (PoCs). In these PoCs we show how an actor can extract the locations as well as associated phone numbers (if set) and device model type from the user database via the exposed API on each affected website. However, the APIs also feature other functionality such as (but not limited to) sending commands to devices (including OBD commands for the websites that support OBD GPS trackers), updating firmware of the devices, etc. which can all be accessed via their designated API endpoints, which are also exposed to different degrees by each website.

Background

Possible single origin of website code/setup

The websites seem to have originated from one server which has been copied over and over, e.g. the directories at http://www.gps958.com/loginpage/, http://www.gpscar.cn/loginpage/ or http://manage.5gcity.com/loginpage/ list login pages for many of the subsequently found websites. However, the websites seem to have diverted with some deploying various fixes for some of the issues found on other websites, such as disabling directory listings, as well as removing some APIs all together.

UPDATE 2018-01-05: The software was originally developed by Thinkrace. Thinkrace has sold the software to clients a long time ago. The clients run the software on their own. Thinkrace does not do maintenance for them.

Possibly this issue is publicly known

We later found out that this issue may already be publicly known: https://www.theregister.co.uk/2015/12/11/hundreds_of_thousands_of_engine_immobilers_hackable_over_the_net/

Extend

FOR A CURRENT STATUS PLEASE SEE THE MAIN PAGE: https://0x0.li/trackmageddon/

Affected websites

We assigned each shared database a number and tried to tie it to a vendor (re-seller or site operator) full list is as follows:

WARNING: SOME OF THE SITES IN THE LIST ARE FIXED AND SOME MAY RECEIVE FIXES IN THE FUTURE! The list only reflects all sites that at one point were affected by this advisory.

Vendor  Database        IP      URL
TR_CLIENT   038 119.28.1.87 http://www.gps958.com
TR  039 120.24.58.119   http://manage.5gcity.com
TR  041 120.24.83.93    http://grapi.5gcity.com
unknown 048 120.77.77.205   http://tracker.gps688.com
unknown 049 120.77.77.205   http://www.aichache.cn
TR  052 198.11.183.28   http://kiddo-track.com
TR  052 198.11.183.28   https://www.one2trackgps.com
TR  052 198.11.183.28   http://www.amber360.com
unknown 080 58.64.155.133   http://m.999gps.net
unknown 107 213.171.165.44  http://www.techmadewatch.eu
unknown 001 101.1.16.228    http://gtrack3g.com
unknown 001 101.1.16.228    http://www.ciagps.com.tw
unknown 001 101.1.16.228    http://www.fordonsparning.se
unknown 001 101.1.16.228    http://www.gm63gps.com
unknown 005 103.224.251.105 http://yati.net
unknown 006 103.224.251.95  http://www.mytracker.my
unknown 007 103.243.183.121 http://www.istartracker.com
unknown 008 103.25.148.154  http://www.jimigps.net
unknown 008 103.25.148.161  http://www.tourrun.net
TR_CLIENT   008 113.98.255.53   http://www.9559559.com
TR_CLIENT   008 113.98.255.53   http://www.goicar.net
TR_CLIENT   008 113.98.255.53   http://www.tuqianggps.com
TR_CLIENT   008 113.98.255.56   http://www.9559559.com
unknown 010 113.10.245.151  http://www.twogps.com
unknown 016 114.119.4.247   http://www.gpsyue.com
unknown 017 114.119.4.247   http://www.xmsyhy.com
unknown 018 114.119.7.57    http://www.icaroo.com
unknown 022 114.119.8.200   http://mootrack.net
unknown 022 114.119.8.200   http://spaceeyegps.com
unknown 022 114.119.8.200   http://www.freebirdsgroup.com
unknown 022 114.119.8.200   http://www.gpsmitramandiri.com
unknown 022 114.119.8.200   http://www.nikkogps.com
unknown 022 114.119.8.200   http://www.silvertrackersgps.com
unknown 022 114.119.8.200   http://www.totalsolutionsgps.com
unknown 029 114.119.8.29    http://567gps.com
unknown 030 115.146.126.80  http://gps.tosi.vn
unknown 030 115.146.126.80  http://gps.transport-duras.com
unknown 030 115.146.126.80  http://thietbigps.net
TR_CLIENT   033 115.146.127.205 http://vitrigps.vn
TR_CLIENT   033 115.146.127.205 http://vnetgps.net
unknown 035 118.91.130.11   http://mygps.co.id
unknown 036 119.28.14.253   http://www.gpsuser.net
TR_CLIENT   037 119.28.1.87 http://www.coogps.com
TR  040 120.24.78.26    http://www.mgoogps.com
TR  042 120.24.83.93    http://love.iotts.net
TR_CLIENT   042 211.154.151.98  http://greatwill.gpspingtai.net
TR_CLIENT   042 211.154.151.98  http://kids.topwatchhk.com
TR  043 120.24.83.93    http://wagps.net
unknown 043 120.24.83.93    http://www.gpscar.cn
TR  043 120.24.83.93    http://www.wagps.net
TR_CLIENT   046 120.76.152.133  http://www.cheweibing.cn
unknown 046 120.77.77.205   http://hytwuliu.cn
unknown 046 120.77.77.205   http://www.aichache.net
TR_CLIENT   046 211.154.151.98  http://car.iotts.net
TR_CLIENT   046 211.154.151.98  http://carm.gpscar.cn
TR_CLIENT   046 211.154.151.98  http://watch.anyixun.com.cn
TR_CLIENT   046 211.154.151.98  http://www.007hwz.com
TR_CLIENT   046 211.154.151.98  http://www.thirdfang.com
TR_CLIENT   046 211.154.151.98  http://www.wnxgps.cn
unknown 051 121.201.67.244  http://www.gpsline.cn
TR_CLIENT   057 211.154.151.98  http://gps.nuoduncar.com
unknown 064 220.231.142.241 http://2.tkstargps.net
unknown 064 220.231.142.241 http://ephytrack.com
unknown 064 220.231.142.241 http://www.squantogps.com
unknown 064 220.231.142.241 http://www.tkgps.cn
unknown 068 220.162.69.241  http://vip.hustech.cn
TR_CLIENT   069 54.169.10.250   http://app.gpsyeah.com
TR_CLIENT   070 54.169.10.250   http://binding.gpsyeah.net
TR_CLIENT   070 54.169.10.250   http://chile.kunhigps.cl
TR_CLIENT   070 54.169.10.250   http://portal.dhifinder.com
TR_CLIENT   070 54.169.10.250   http://www.bizgps.net
TR_CLIENT   070 54.169.10.250   http://www.gpsmarvel.com
TR_CLIENT   070 54.169.10.250   http://www.mygps.com.my
TR_CLIENT   070 54.169.10.250   http://www.mygpslogin.net
unknown 070 54.169.10.250   http://www.packet-v.com
TR_CLIENT   072 54.169.10.250   http://login.gpscamp.com
unknown 081 58.64.155.133   http://www.999gpstracker.com
unknown 081 58.64.155.133   http://www.blowgps.com
unknown 081 58.64.155.133   http://www.carzongps.com
unknown 081 58.64.155.133   http://www.igps.com.my
unknown 081 58.64.155.133   http://www.inosiongps.com
unknown 081 58.64.155.133   http://www.response1gps.com
unknown 081 58.64.155.133   http://www.sledovanivozidel.eu
unknown 081 58.64.155.133   http://www.suntrackgps.com
unknown 081 58.64.155.133   http://www.trackerghana.com
unknown 008 113.98.254.154  http://www.tuqianggps.net
TR_CLIENT   008 113.98.254.161  http://tuqianggps.net
TR_CLIENT   008 113.98.255.56   http://tuqianggps.net
TR_CLIENT   108 47.90.39.27 http://www.dyegoo.net
unknown 109 139.199.181.162 http://www.zjtrack.com
YIWENGPS    018 114.119.7.57    http://fbgpstracker.com
YIWENGPS    018 114.119.7.57    http://gps.gpsyi.com
YIWENGPS    018 114.119.7.57    http://www.crestgps.com
YIWENGPS    018 114.119.7.57    http://www.spstrackers.com
YIWENGPS    018 61.144.222.145  http://en.gps18.com
YIWENGPS    018 61.144.222.145  http://en.gpsxitong.com
YIWENGPS    018 61.144.222.145  http://gps18.com
YIWENGPS    102 114.119.4.247   http://en2.gps18.com
YIWENGPS    102 114.119.4.247   http://ry.gps18.com
unknown 103 101.1.16.228    http://www.ulocate.se
TR_CLIENT   104 54.169.10.250   http://classic.gpsyeah.com
unknown 104 54.169.10.250   http://www.gpsyeahsupport.top
TR_CLIENT   037 119.28.1.87 http://tr.3g-elec.com

with the vendor shorthands meaning:

TR_CLIENT   Unknown (a client of Thinkrace, but Thinkrace does not do maintenance)
TR  Thinkrace (http://www.thinkrace.com/)
unknown Unknown 
YIWENGPS    Potentially Yiwen GPS (http://www.yiwengps.net/) (we guessed this from strings in the log files)

Affected devices

The model names of the devices we could access over all affected sites’ APIs were: , 007, 36test, 3G, A10, A100, A107, A11, A12, A16, A18, A19, A20, A21, A6, A9, Anywhere, Anywhere-car, AW01, AW02, BD100, BD309W, BK826, BL02, BL02+, BL08, BSJ, BW02b, BW08b, C12, C4, C6, C6_YX, CC630, CC800, CC828, CC830, CNY-2020, CT08, CY09, CY20, CY21_LBS, CY31_LBS, D1, dk691, DK699A, DK699B, DK通用, DW-003-1, DX06, DXGA, DXZD, E21, E21-6, ET100, ET100, ET110, ET130, ET150, ET200, ET210, EV10, EV10D, F0, F1, F2, F3, FK60, Followit, FY, G1, G10, G2, GK301, GK309, GM902B, GPS, GPS+, GPS08, GPS定位书包(基站), GPS定位手环, GPS定位手表-儿童, GPS定位手表-儿童(新), GPS定位手表-成人, GPS定位鞋, GRTQ, GS503, GS60W, GT02, GT02A, GT02B, GT02D, GT02N, GT03A, GT03B, GT05, GT06, GT06A, GT06C, GT06E, GT06F, GT06N, GT07, GT100, GT200, GT220, GT300, GT300+, GT300A, GT300S, GT300SW, GT400, GT410, GT500, GT500S, GT600, GT700, GT710, GT720, GT740, GT88, GV25, GW110, GX02, GX02A, GX06, GX06S, GX09, GX15, GX20, GX20S, GX801, GX902, GX902A, GX902C, GX902C+, GX905, GX906, H002, H500, HYXT, ipet, IW, JI09, JM01, JV100, JV200, K01+, K01+FN, K86, KJX-TEST01, LD501, LHGR, LIX-01, LK100, LK106, LK108, LK109, LK206, LK208, LK209, LK209B, LK209C, LK210, LK210B, LK330, LK660, LK930, LKDD, LKGR, LQ1, M1, M17LEYANG(国内), M2, M206A_HJL, M206A_OVI, M206A_RUIBU, M206C_LY, M207D_KKT, M208B_HJL, M208E_MD_FN(国外), M208E_MD_NEWPhb, M3, M38G_JMXK, M6, M7, MDMT90, MG-300, MG-X10, MG-X11, MG-X20, MG-X21, MG-X21BF, MG-X50, MG-X80, MG-X81, MG-X82, MG-X83, mini404, mini404A, MLG, MT, MT08A, MT08B, MT10, MT18, MT18C, MT58, MT60, MT600, MT66, MT90, MX561, NX9_COB, NX9_COB_FN, P168, P400, P6, PA200, PM01, PM03, PSRL85, PT06-New, PT09, PT16, PT36, PT50, PT50-OLD, PT519, PT520, PT529, PT58, PT59, PT590, pt590v, PT60, PT61, PT80, PT82, PT84, Q68, Q8, R01, R1004, R10S, R2001, R3001, R9_FN_NewPhb, RomboGPS, S001, S1, S10, S1A, S-K-O, T10, T28, T28A, T58, T8S, TA-03, TA-03A, TAX-200, TAX-803, TC-01, TD01, TG03A, TG06N, TianQin, TK103, TK103-1, TK16, TK200, TK202, TK500, TK500newtest, TK600, TQ, TR02, TR02N, TR03A, TR03B, TR03C, TR03D, TR06, TR06B, TR06N, TR06S, TR07, TR08, TR09, TR130, TR20, TR500, TU01, T-WATCH, VT01, VT08, VT100, VT200, VT202, VT202+, VT206, VT-220, VT230, VT-268, VT30, VT300, VT33, VT33B, VT33S, VT400, VT6, VT600, VT66, VT66+, VT66A, VT66B, VT66N, VT88, VT88A, VT88B, VT900, VT99S, W16, W30, W33, W38, W62, W8, W83, Watch, Watch-1, wetrack2, WT1, X11, x33, XY03D-1, Y03, Y2, YAPOM, ZF572C, ZF572CM, ZG008, 丢不了, 个人-北极星, 中国监护, 亿多宝, 天使守护001, 天琴, 天琴-个人, 天禾, 安易讯, 宏远, 宝贝-520, 巨欣, 巨欣C6, 心连心, 执法仪, 星安, 智能手表, 沙漠之星, 炫芯905, 科爱儿, 组创, 谷米特, 车福星, 遁讯 (but resellers may re-brand their devices)

Details

The details (which are very similar but still sometimes different) regarding each website are as follows:

2.tkstargps.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 1 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

The response by the API contains broken JSON which our skript could not parse, hence we did not estimate the number of affected devices nor devices models affected.

567gps.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois only lists generic abuse emails. We did not bother to email them because from experience this would be going no where as this is no abuse per se.

YuMing@YinSiBaoHu.AliYun.com (which we first thought to be a genuine contact address) is associated with over 6M domains.

app.gpsyeah.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

binding.gpsyeah.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

car.iotts.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

carm.gpscar.cn

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

chile.kunhigps.cl

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

https://www.nic.cl/registry/Whois.do?d=kunhigps.cl does not ofter contact information.

classic.gpsyeah.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

en2.gps18.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois only lists generic abuse emails. We did not bother to email them because from experience this would be going no where as this is no abuse per se.

YuMing@YinSiBaoHu.AliYun.com (which we first thought to be a genuine contact address) is associated with over 6M domains.

en.gps18.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois only lists generic abuse emails. We did not bother to email them because from experience this would be going no where as this is no abuse per se.

YuMing@YinSiBaoHu.AliYun.com (which we first thought to be a genuine contact address) is associated with over 6M domains.

en.gpsxitong.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois only lists generic abuse emails. We did not bother to email them because from experience this would be going no where as this is no abuse per se.

YuMing@YinSiBaoHu.AliYun.com (which we first thought to be a genuine contact address) is associated with over 6M domains.

ephytrack.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 1 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

The response by the API contains broken JSON which our skript could not parse, hence we did not estimate the number of affected devices nor devices models affected.

fbgpstracker.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

gps18.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois only lists generic abuse emails. We did not bother to email them because from experience this would be going no where as this is no abuse per se.

YuMing@YinSiBaoHu.AliYun.com (which we first thought to be a genuine contact address) is associated with over 6M domains.

gps.gpsyi.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

gps.nuoduncar.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 1 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

The response by the API contains broken JSON which our skript could not parse, hence we did not estimate the number of affected devices nor devices models affected.

gps.tosi.vn

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

No working whois service. The supposed service at http://www.vnnic.vn/en/domain is not working.

gps.transport-duras.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

grapi.5gcity.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

greatwill.gpspingtai.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 1 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

gtrack3g.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 1 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

hytwuliu.cn

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

kiddo-track.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

kids.topwatchhk.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 1 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

login.gpscamp.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

love.iotts.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 1 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

m.999gps.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 4 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

Domain info list contact@privacyprotect.org as contact email. We did not contact them.

manage.5gcity.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

mootrack.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois only lists generic abuse emails. We did not bother to email them because from experience this would be going no where as this is no abuse per se.

YuMing@YinSiBaoHu.AliYun.com (which we first thought to be a genuine contact address) is associated with over 6M domains.

mygps.co.id

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

portal.dhifinder.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

ry.gps18.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois only lists generic abuse emails. We did not bother to email them because from experience this would be going no where as this is no abuse per se.

YuMing@YinSiBaoHu.AliYun.com (which we first thought to be a genuine contact address) is associated with over 6M domains.

spaceeyegps.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

thietbigps.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

tr.3g-elec.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

tracker.gps688.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 1 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

The response by the API contains broken JSON which our skript could not parse, hence we did not estimate the number of affected devices nor devices models affected.

tuqianggps.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois only lists generic abuse emails. We did not bother to email them because from experience this would be going no where as this is no abuse per se.

YuMing@YinSiBaoHu.AliYun.com (which we first thought to be a genuine contact address) is associated with over 6M domains.

vip.hustech.cn

PoC

The following proof-of-concept requests using the curl program demonstrate how 1 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

The response by the API contains broken JSON which our skript could not parse, hence we did not estimate the number of affected devices nor devices models affected.

vitrigps.vn

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

No working whois service. The supposed service at http://www.vnnic.vn/en/domain is not working.

vnetgps.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

wagps.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

watch.anyixun.com.cn

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.007hwz.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.9559559.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.999gpstracker.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.aichache.cn

PoC

The following proof-of-concept requests using the curl program demonstrate how 1 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

The response by the API contains broken JSON which our skript could not parse, hence we did not estimate the number of affected devices nor devices models affected.

www.aichache.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.amber360.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.bizgps.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.blowgps.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois gives contact as contact@privacyprotect.org

www.carzongps.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.cheweibing.cn

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

We could not find contact information.

www.ciagps.com.tw

PoC

The following proof-of-concept requests using the curl program demonstrate how 1 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.coogps.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois only lists generic abuse emails. We did not bother to email them because from experience this would be going no where as this is no abuse per se.

YuMing@YinSiBaoHu.AliYun.com (which we first thought to be a genuine contact address) is associated with over 6M domains.

www.crestgps.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.dyegoo.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois only lists generic abuse emails. We did not bother to email them because from experience this would be going no where as this is no abuse per se.

YuMing@YinSiBaoHu.AliYun.com (which we first thought to be a genuine contact address) is associated with over 6M domains.

www.fordonsparning.se

PoC

The following proof-of-concept requests using the curl program demonstrate how 1 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

No contact details in whois

www.freebirdsgroup.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appedix

whois lists contact@privacyprotect.org as contact

www.gm63gps.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 1 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.goicar.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois only lists generic abuse emails. We did not bother to email them because from experience this would be going no where as this is no abuse per se.

YuMing@YinSiBaoHu.AliYun.com (which we first thought to be a genuine contact address) is associated with over 6M domains.

www.gps958.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois only lists generic abuse emails. We did not bother to email them because from experience this would be going no where as this is no abuse per se.

YuMing@YinSiBaoHu.AliYun.com (which we first thought to be a genuine contact address) is associated with over 6M domains.

www.gpscar.cn

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.gpsline.cn

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

The response by the API contains broken JSON which our skript could not parse, hence we did not estimate the number of affected devices nor devices models affected.

www.gpsmarvel.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.gpsmitramandiri.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.gpsuser.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.gpsyeahsupport.top

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.gpsyue.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 1 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.icaroo.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois only lists generic abuse emails. We did not bother to email them because from experience this would be going no where as this is no abuse per se.

YuMing@YinSiBaoHu.AliYun.com (which we first thought to be a genuine contact address) is associated with over 6M domains.

www.igps.com.my

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois does not exist

www.inosiongps.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.istartracker.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois only lists generic abuse emails. We did not bother to email them because from experience this would be going no where as this is no abuse per se.

YuMing@YinSiBaoHu.AliYun.com (which we first thought to be a genuine contact address) is associated with over 6M domains.

www.jimigps.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois only lists generic abuse emails. We did not bother to email them because from experience this would be going no where as this is no abuse per se.

YuMing@YinSiBaoHu.AliYun.com (which we first thought to be a genuine contact address) is associated with over 6M domains.

www.mgoogps.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois only lists generic abuse emails. We did not bother to email them because from experience this would be going no where as this is no abuse per se.

YuMing@YinSiBaoHu.AliYun.com (which we first thought to be a genuine contact address) is associated with over 6M domains.

www.mygps.com.my

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois does not exist

www.mygpslogin.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.mytracker.my

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois does not exist

www.nikkogps.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.one2trackgps.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

For communication with info@one2track.nl regarding coordinating with Thinkrace please see the global timeline.

Appedix

On 2017-11-27 we notified the vendor of the following issues:

As for other things we found ... from quickly taking a manual look I
found these:

Sound recordings ... presumably from clients:
REDACTED

HTTP on a different port with more directory listings and logs:
REDACTED
with e.g. Gateway logs:
REDACTED

Different HTTP port ... same thing: more dir listings with logs:
REDACTED

and Vangelis Stykas send:

Password reset for any user:
============================

There is a directly accessible non authenticated page for reseting passwords located in:
REDACTED
In the url we have to pass the v param with a DES encoded parameter with a key of REDACTED of a string with the following patter
REDACTED
so the encrypt value of REDACTED
and as a poc you can go to : REDACTED
and you will be able to change your password on one2track account


Sending commands (and acquiring info) to any device:
====================================================
You need to be authenticated with any user account.
So after the login you can browse to :

REDACTED

Which requires a password but AFTER you have provided a valid deviceid / userid combination 

REDACTED

you can browse in ALL devices and change any configuration that you might want


Uploading Firmware to all devices:
==================================
After authenticating as a user you can browse to:

REDACTED

Where you can 
1) Get all the deviceinfo
2) Get all the protocol commands 
3) Upload binary to update devices.

www.packet-v.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.response1gps.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois gives contact email as contact@privacyprotect.org

www.silvertrackersgps.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.sledovanivozidel.eu

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.spstrackers.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.squantogps.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 1 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

The response by the API contains broken JSON which our skript could not parse, hence we did not estimate the number of affected devices nor devices models affected.

www.suntrackgps.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.techmadewatch.eu

PoC

The following proof-of-concept requests using the curl program demonstrate how 1 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.thirdfang.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.tkgps.cn

PoC

The following proof-of-concept requests using the curl program demonstrate how 1 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

The response by the API contains broken JSON which our skript could not parse, hence we did not estimate the number of affected devices nor devices models affected.

www.totalsolutionsgps.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.tourrun.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

We could not find contact details

www.trackerghana.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois gives contact as contact@privacyprotect.org

www.tuqianggps.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois only lists generic abuse emails. We did not bother to email them because from experience this would be going no where as this is no abuse per se.

YuMing@YinSiBaoHu.AliYun.com (which we first thought to be a genuine contact address) is associated with over 6M domains.

www.tuqianggps.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois only lists generic abuse emails. We did not bother to email them because from experience this would be going no where as this is no abuse per se.

YuMing@YinSiBaoHu.AliYun.com (which we first thought to be a genuine contact address) is associated with over 6M domains.

www.twogps.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.ulocate.se

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois does not provide contact information for domain

www.wagps.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.wnxgps.cn

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.xmsyhy.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

www.zjtrack.com

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Appendix

whois gives contact email as whoisprotect@dnspod.com

yati.net

PoC

The following proof-of-concept requests using the curl program demonstrate how 2 of the vulnerable endpoints can be exploited. The parameters DeviceID and/or ID can be used to iterate through all devices and/or users.

POC WAS REDACTED:
Users do not need this information. Experts should be able to verify our
findings without a copy and paste curl PoC.
By providing a copy and paste curl PoC basically any person could - without
any technical knowledge - exploit the vulnerabilities subject of the PoC.

Other endpoints can also be vulnerable. However, it is possible that access to the .asmx file itself is restricted and there is no WSDL information leak on the endpoint, in which case only directly interacting with the API endpoint’s operation as demonstrated in the PoC above will reveal the vulnerability. We did not force browse through all the API endpoint’s operations because by doing so we may inadvertently change device settings and we did not have a test device for this site. We therefore advice the website operator to check all APIs and all there endpoints for public accessibility.

Mitigation

Mitigation by the user of these sites is not possible other than not using the affected devices.

We advice the vendor that simply restricting public access to the API endpoints may not be enough. An authenticated authorization bypass through user-controlled key resulting in a horizontal escalation of privilege may still be possible if user-controlled keys (in our PoC the DeviceID and ID parameters) are not validated for each query.

Timeline:

Global timeline