Could the same vulnerability happen after 3 years ? Is this acceptable ? Are companies learning from our reports or are they just blindly fixing the issue without fixing the root cause and applying proactive measures to prevent them from happenning again ?
If you are still reading this I guess you already know the answer to those questions.

Playing with George

Back when I was working in Pentest Partners in 2020 I found a typical user add to organization issue on Grand Stream cloud as you can see in here caused by an IDOR. Fast forward to 2023. I was trying to explain to George, my 7 year old son what an IDOR is and  what's the difference between authentication and authorization (yes I know too young for that, but he has a legacy to keep!) when I reused the same request :

POST /app/user/save HTTP/1.1
Host: www.gwn.cloudConnection: 
closeContent-Length: 72
Accept: application/json, text/plain, */*
Origin: https://www.gwn.cloud
Content-Type: application/json;charset=UTF-8
Referer: https://www.gwn.cloud/account/users
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: SESSION=7672dd7d-58a7-47f2-8bbc-3534108e4987
{"email":"egw@mailinator.com","roleId":2,"networkIds":[xxx],

I could add any network id on the networkIds array and it would instantly make me an admin on that network. Imagine my suprise when this request worked again!

Severity

Back in 2020 it was mostly a data leak and a potential GDPR violation on this as you could leak  ssh and WIFI psk of a lot of networks but you still needed physical proximity to get access to said networks.

This is no longer the case though. GWN new devices have VPN capabilities and router capabilities and as you can guess all of them are managed from GWN.cloud. This means that (under certain circumstances) you can access remote networks by connecting to their VPN server and having direct access to the remote network! (and all that with a simple IDOR).

Disclosure

We (me and my son) notified grandstream with a ticket on 30th of January 2023. Their response was :

Thank you for reporting this to us.

Please note that the case has been reported internally in order to be fixed. We will inform you once there is an update.
Best regards.

I chased again after 15 days and then after 45 days (today) my tickets was closed. After checking with grandstream they said:

Hi Vangelis,
Please note that the fix for this issue is included in the latest GWN Cloud version 1.1.23.44. Thanks.
Best regards,

So it was fixed but they neglected to inform me for it , which is ok as I guess.

Postmortem

How could this happen ?
The same vulnerability happenning after 3 years on the exact same product is in my humble opinion unacceptable as it means that you learn nothing from the previous vulnerability.
I believe that bugs and vulnerabilities are bound to happen and will happen to every system. Its how you react to them and the lessons you learned from them that distinct a great from a not so great company.
Grandstream answered and fixed the vulnerability in a timely manner, but I can safely assume that the next time a developer touches that code he might remove the authorization check and there will be no automated test catching that or any penetration testing done on the application.It is essential to conduct regular security testing and assessments, implement adequate security measures, and maintain vigilance to prevent vulnerabilities from persisting or resurfucing in any application.Considering that this is a company that sells networks equipment and firewalls this is not a great sign.

Plus side

I could explain the release and maintenace cycle of  software to my son and how to properly do it. As this was cloud as always no CVE was assigned.

Stalkerware (or spouseware) is a growing threat amongst modern days. A lot of reports were made of abusers that were using this kind of applications to track and monitor their spouses. This is a post expanding on the talk we are currently giving (10th of December 2022) on BSides London with Felipe Solferini.

TL:DR

We looked at some stalkerware networks (families) and found out that a lot of them were not secure. We took a deeper dive in there and identified that around 2 million devices were being monitored at some point in the past decade from 7 different families.

Quick intro

In this post you are going to read about the 5-month journey that we had on exposing multiple stalkerware family companies and what was the underlying issue that lead to full or partial data exposure of all their customer data. You are not going to find the zero-days that were used as this would be giving access to data of really vulnerable people. We also want to define what stalkerware is. Any application that could be installed and hidden from the user and transmitted data (pictures, call data etc) is considered stalkerware, even if they use the pretext of monitoring teenagers.

Toolset

The following tools greatly helped in this research:

• Burp Suite
• Jadx Decompiler
• Apklab.io
• Mullvad
• A small droplet on DigitalOcean
• Our little cancerous android phone (which ended up having installed more or less 6 different stalkerware applications at some point).

• Revolut
• Shodan.io

The procedure that was followed was try to find a demo account and see if we could find any exploitation from that (with no installation at all). The if we could download the APK we would try to decompile it and find any sensitive information. If this was not the case, APKLab would run it in its sandbox and we would parse the output to see if there was anything juicy in there (sometimes the C2 for the mobile application was different than the control panel). And finally if all else failed we installed it on our android phones and tried to live find vulnerabilities. On certain families that had no demo but were deemed interesting enough, we used Revolut temporary cards to pay and create accounts.

The results were really depressing. We were able to acquire really sensitive information on all networks. Following is a list of some of the vulnerabilities that were found:

• SQL injections
• Remote command execution
• Leaking private keys (amazon, alibaba and azure)
• Leaking S3 keys
• Insecure direct object reference
• Broken authentication

Stalkerware Families

The following list is unfortunately not a complete list of all the stalkerware that there is out there. It is probably not even a complete list of the network members of each family, as they have a variety of marketing plans and resellers networks that are just getting a cut for sellling their products and getting to the parent companies on some of the cases we made assumptions and we even failed to find the parent company. The word family in here is loosely used to define a group of sites that is sharing a common codebase and/or a database. This means that there is a reseller that is selling the "product" and many people that resell it under their own brand.

Why go after so many ?

As with previous research we like to attack (and prove security problems) on an industry as a whole. Even worse, an industry which is evil. We also got some kind of motivation from Eva's tweet.

1. TTS (The Truth Spy)

Already exploited more than once and TechCrunch had a great article on this. Probably one of the biggest resellers in the market. Their current database has approximately 230,000 users and have the following list of websites.

• https://secondclone.com
• https://thetruthspy.com
• https://fonetracker.com
• https://copy9.com
• https://mxspy.com/
• http://thespyapp.com
• https://ispyoo.com/
• https://mobilespyonline.com/
• https://exactspy.com/
• https://mobidad.app
• https://guestspy.com
• https://innoaspy.com

From their database we can also see the association of each website with a shell company but it all drains down to 1BYTE as their developer and reseller.

2. XNSPY

A big enough network (approximately 60,000 users) that seems to be actively marketed and handled Konext. Application and network seemed to be actively developed right now.

The website of the stalkerware is :

https://xnspy.com/

3. Cocospy

Trickiest of every other network to identify its originating company as the vulnerability we found did not allow us to fully dump a database. After a lot of digging and some luck we have strong indication that the company behind this network is 711.icu. The following websites are part of this network:

• https://cocospy.com
• https://spyzie.io
• https://spyic.com

4. Mobistealth

A massive network of over 125,000 devices that seems to be around for more than 10 years (Installations are going back to 2009). The company ownership are yet to be determined. The network was also compromised in 2018 as we can see here.

You can access it on the following url:

https://www.mobistealth.com/

5. Spymaster Pro

Speaking on networks that were compromised in 2018 (same article), Spymaster Pro seems to be dying down as a network. It has 8,000 devices (approximately 300 active in the past month). Company behind it is Netzens as they proudly state in their admin panel.

You can access it on the following url:

https://www.spymasterpro.com/

6. SpyTrac

This was a network that we randomly found and seemed to be really new (~1 year). Imagine our surprise when we found out that it had over 1.3 milion devices registered. When we started digging we found out that the company behind it was Support King. If that does not ring a bell to you I am happy for you as you have never looked at stalkerware before. Support King was fined via the FTC and ordered to remove everything and not work with this industry any more. Well... it seems they did not listen and rebranded everything as SpyTrac. The functionality that this panel and app have is by far the most complete of all, together with its huge userbase it's probably one of the scariest resellers of all.

You can access it on the following url:

https://spytrac.com/

7. PcTattletale

Even though it has an Android application, it is mostly known for its PC application that can be used to snoop on a spouse's computer. The application was not handling security at all, so it was possible to leak all the information about its approximately 60,000 users.

You can access it on the following url:

https://www.pctattletale.com/

Prevention

If you or someone you know needs help , reach out to you national Domestic Violence Hotline that should provide help 24/7. If you are in an emergency situation call your nation police number.The Coalition Against Stalkerware also has resources if you think your phone has been compromised by spyware.

(Not) Honorable mention:

If you do some OSINT on all the website you are going to see that most of them are behind Cloudflare. This means that their far from secure code was just protected by a really good WAF. We found ways to bypass this (mostly with Shodan finding actual IPs) but it's worth mentioning that for Cloudflare (and for Amazon, Azure and other reputable hosting providers) spouseware is within their acceptable ToS.

Thanks:

We would like to thank both Eva Galperin who greatly helps into getting more visibility into the huge stalkerware problem and Zack Whittaker who helped with OSINT searching and morally as this kind of research is really stressfull due to its nature. Last but not least we would like to help GoLang expert George Lavdanis who created a properly scalable parsing solution to make millions of requests without having to wait for years.

tl:dr: Tapplocks api endpoints had no security checks other than a valid token to access any data.This results in anyone with a valid login (easily obtained by creating an account) being able to manipulate every tapplock available!

The usual suspect…

Yesterday I read the great article by the one and only cybbergibbons about tapplock and totally pwning it and as always I wanted to do it! I cannot do a lot hardware wise (and certainly nothing more than cybergibbons did) so lets check the mobile apps.I downloaded the app and started poking around.First of all no https which is a very bad sign. Then the usual suspects: Direct access object vulnerability. Created a second user and tried accessing the first ones properties: Success!

Can I hack your lock please ?

I did not have any locks (and I am out of IoT budget for this month as my wife has -kindly- informed me), so in order to verify some stuff I reached out to the original reporter who was kind enough to share with me his email (that was all that I wanted and needed as brute forcing ALL accounts would be illegal) and his consent for me to access his details. I also believe this is the first time a twitter DM is used as a GDPR consent

After that I was able to verify that :

1. I could access all info about any lock (with an incremental id that I did not try brute forcing as I had cybergibbons id, and that would be illegal). And by all I mean ALL (key1, key2, serial and everything else). This means that everything was enumerable via simple relationships. (lock -> fingerprint -> user).
2. I could share any lock I wanted PERMANENTLY to any account and the lock owner would not be able to remove it (or at least as the original article says have the feeling that he did)
3. I could do pretty much everything that you can do with the app by changing some parameters in the http calls as no check other than the one of a valid login is being made.
4. There were some hidden API calls that could delete or change a lot of stuff but I did not verify that this data ends up in the lock, as I did not had the time and did not want to bug more cybergibbons.
5. I could access really sensitive PII (like the user exact address when he/she unlocked the lock via bluetooth (possibly home address) and email) which is probably a violation of GDPR.

Attack scenario

So after my findings, things look really bad.I could script an attack that would share any lock permanently with my account (or ANY account), then extract all the locks last unlock location, go there and unlock them via the official app! Pentest partners hack was way cooler but in the process we also got a GDPR violation + we also know location now! It feels like we are on a CTF.

Notifications

• 2018/06/14 : Notified tapplock of the findings
• 2018/06/15: Got a reply from tapplock: “We are making a plan to disable the APIs that are related to GDPR sensitive data in the next 24 hours.”
• 2018/06/15: Replied to tapplock for my disclosure procedure.
• 2018/06/16: Tapplock got the API down after pressure because it was exposing GDPR data.

Postmortem:

In here I usually write about how you should buy something from a well known company and how they should respond and some more but not this time. I really have no postmortem on this one. The lock had several flaws and to my understanding they had a great marketing team but a non existent security team. I cannot tell you to buy or not buy anything as I don’t have the authority to do so but I would not buy this lock.

tl;dr: Calamp which provides the backend for a lot of really well known car alarm systems had a misconfigured reporting server that gave direct access to most of its production databases, allowing anyone to access and modify all data.

Oh father , what have you done?

As many of my twitter followers know, I LOVE breaking IoT stuff. Not its hardware unfortunately as these skills are close to non existent for me, but monitoring its traffic and trying a lot of strange things in their cloud servers is one of my favorite things in the world. So when my father called and said he got a brand new smart car alarm I was like “are you kidding?”.I asked for the model (it was a Viper Smart Start System), called George and then started poking around their mobile app…

Dead ends everywhere

So their mobile app was extra cool.It had ssl connection and ssl pinning so I had to use my usual unpinning process to get ANYTHING.After a couple of hours of testing stuff and trying several random known tricks we always hit a wall. After that, we tried to login on their webpage and tried again any trick that came to mind. Once again everything was correctly returned or we did not have authorization to see it.

Calamp.com server

Then we noticed that the app was not connecting solely to mysmartstart.com domain but mostly to a third party domain (https://colt.calamp-ts.com/). Again with ssl pinning and all proper bells and whistles. This panel seemed to be the frontend for Calamp.com Lender Outlook service. We tried our user created from the viper app, to login and it worked! This was a different panel which seemed to be targeted to the companies that have multiple sub-accounts and a lot of vehicles so that they can manage them.We tried creating a sub-account and tried escalating to our parent account but despite the feeling that I had this was another dead end. We tried directly accessing other ids and everything else we could think of but everything was correctly secured.And then it hit us…

Reporting server

All the reports were provided by another server, dedicated for that ,running tibco jasperreports® software.None of us were familiar with that so we had to improvise. Removing all the parameters we found out that we were already logged in with a limited user that had access to A LOT of reports.We had to run all those reports for our vehicles right? Well the ids for the user was passed automatically from the frontend but now we had to provide them from the panel as an input.And…well..we could provide any number we wanted.

So we could see all the reports for all the vehicles (including location history). NOT ANOTHER TRACKMAGEDDON PLEASE! Then George saw that there were also data sources with usernames (but masked passwords and no way for us to export them , as we were a limited user). We could not create a report or an adhoc or pretty much anything else, but we could copy paste existing ones and edit them so we can do pretty much anything.We could also edit the report and add arbitrary XSS to steal information but this was not something that we (or anyone in their right lawful mind) would want to do. Then it hit us again! Inputs were raw sql queries!

Running on all their production databases (yes it was not only colt that used that report server but connect device outlook also, a database that we did not touch at any point). So we created a new input with a select * with our user whose id we already knew and we got back data. I then changed the password via the mobile app reran the query and saw another hash. We tried an update query with the old hash and yeap the account was accessible with the old password via the mobile app.Full account takeover and device manipulation. At that point we stopped as we had to report everything. But first I had to call my father. When I told him what I could do without his username/password he answered “Well you could have just asked for them”…

Reporting the vulnerability

Now this was rather tricky (and colamp.com promised that they will fix that by updating their policy so that researchers can have a direct way of reaching out to them with any vulnerabilities -now available at https://www.calamp.com/bug-report/ -).Below are the dates of communication.We were rather pushy on this as this was a full takeover of A LOT OF CARS (both directed and viper apps have each over half a million downloads on android app store and the connect database was also exposed which controls a large number of IoT devices).

• 2018–05–01: Sent support request requesting proper disclosure steps
• 2018–05–01: Asked via twitter dm on @calamp for an email to sent report
• 2018–05–02: Reached out via linkedin to a cybersecurity employee at calamp for direction on proper disclosure
• 2018–05–02: Reached out to CERT which guided us to the proper communication channel
• 2018–05–02: Calamp answered and acknowledged issue
• 2018–05–03: Calamp updated us that their are working on a fix
• 2018–05–12: Calamp notified us that it was patched and after verification we are releasing this.

Exploitation of the bug

• Well the very obvious just change the user password to a known one go to the car, unlock, start and leave.
• Get all the reports of where everyone was
• Stop the engine while someone was driving ?
• Start the engine when you shouldn’t.
• Get all the users and leak.
• As we haven’t actually seen the hardware we might be able to pass can bus messages though the app ?
• Get all the IoT devices from connect database or reset a password there and start poking around.
• Really the possibilities are endless…

Was my smartstart / vehicle / IoT vulnerable?

We honestly have no idea how many companies (or vehicles) use this backend service. It seems that all the brands that are at directed.com website were using that backend so it is somewhat safe to assume that they were vulnerable. It also seems that a lot of companies use the telematic cloud of calamp.com (both for vehicles , fleet management and IoT) so you will have to reach out to your operator and ask them as calamp stated that they coordinated directly with their customers.

Postmortem

If you are an end user try to buy only well known products that you believe will have quality in all aspects and will be updated once a vulnerability is found.This (like hakvision) is another example of things that you did to be more secure and ended up making you more vulnerable.

If you are a company, please for the love of whatever is holy create a security@ email and monitor it.Write down a proper vulnerability disclosure policy and stick with it.When creating users always have least privilege principle in mind! Reporting user could and should have only read only access. And never trust any input from the user, or think that the user will use your app in your intended way.

tl;dr: Hikvisions cloud services (hik-connect.com) rely on a cookie value to determine with what user you are logged in.Changing the user id cookie value with another users id results into you being logged in as that user.While the user id is a hashed key we found a way to find out the user id of another user just by knowing the email,phone or username they used while registering, after that you can view the live feed of the cam/DVR, manipulate the DVR, change that user’s email/phone and password and effectively lock the user out without leaving him an option to reuse that device with hik-connect even after a factory reset of the device.

What to do on a slow Friday…

After reading cybergibbons tweet about having 13 of the same camera model I remembered that I have a DVR on my home that I have never played around with and it was a REALLY SLOW Friday so I pinged my friend (and regular partner in all thing cyber) George Lavdanis and started tinkering stuff :). We are both mostly web guys so reversing the firmware was probably our last resort.
I found out that my DVR wanted to update to a new firmware and that update was introducing a new cloud service (hik-connect.com) that would help you access your camera without port forwarding on your router.As a friend says: “don’t look at the individual devices when you can look at the backend and pwn everyone”.

Identifying the bug

Creating a user on hik-connect.com and playing around none of the usual suspects (DAO or some logic flow error) stand out until we looked at the cookie. There we saw that there was a LOT OF DATA. Username , user id and more stuff. We tried changing the username (AS_Username) and after a refresh we found the new (changed) value on the page. Ok no harm there is not a chance that this is the case with the user id (just trust the cookie without actually checking the session first).

Created a new user to verify that.After creating the new user we used the first users userid as the cookie value on AS_UserID and…F**K, we can see the users devices.

So we have confirmed that we can login as any user given that we know his/her user id. User id seems to be a hash (probably a salted md5) and not a sequential number so there is a danger but not that big. We spent quite some time trying to reverse it but seems that its either an md5 with a pretty good salt, a random string or an md5 of a random string that is assigned to the user upon registration. We quit trying to reverse it as it seemed to be a dead end.

User id hunting

We then tried to find a user list or something that would give us a way to find a user id by providing some user info. Password reset could enumerate users by email, share device could also enumerate users existence by email or phone but was just returning a status code and nothing meaningful. We were pretty disappointed as we had a pretty nice bug that we couldn’t really use. At that point George found out that our existing credentials were also working on ezvizlife.com . Ezviz is a different (older?) cloud service for hikvision which is mostly active x so it needed internet explorer and windows (and no chrome or firefox tools).

So lets fire up a virtual machine and explore it! It’s mostly the same functionality BUT it also has another feature , you can mark a user as a friend with no interaction needed by the other user just by knowing the email or phone that the other user used upon registration (searching was using the endpoint queryByMobile.json and was returning the same status codes as the the search on hik-connect.com site).

After befriending the user we saw an md5 hash in the url and started celebrating but that was wrong (bummer…).

After that, we explored a couple more ways of obtaining user ids but everything was a dead end. After everything we retried queryByMobile.json and it was returning WAY more than the usual status code (WTF just happened?). Re-validating and yes we have user ids…

It seems that after you mark a user as a friend you can query him and you get a userDTO which also has the (wanted) user id! So now we can login as any user as long as we have his email, phone number or username (endpoint was also returning data for username although there was no UI for it) and impersonate him. That is highly critical so we wrote a small report and send it to Hikvision.

Exploitation of the bug

After that and while waiting for Hikvision lets see WHAT can we do from hik-connect and ezviz:

• We can (obviously) see the devices of the user, live video and playback from the device.
• We can change the user email and phone number and effectively take over his account after resetting his password (in order to do that we will need to logout and click on forget password AFTER changing email/phone and input a new password).After that even factory reseting the device will not unbound it from our account.The victim will have to contact hikvision to do that.
• If we change the password we can use the devices menu on the hik-connect android app and manage the device (update firmware and brick it or do whatever we want) without any password given.
• We could be more silent and just add a share on our own account and the user will never know that we are watching if he is not checking the sharing tab in his app regularly.
• Enumerating users with existing email, phone, user lists and then exploiting could lead to a HUGE data leak
• Enumerating users with known hikvision employees emails and then using their elevated accounts (NOT verified as this would be highly illegal).
• When sending feedback via the hik-connect iphone/android app you get assigned a WishlistResponsiblelist that seems to be a Hikvision employee.Guess what ? A userid also exists in there. (NOT verified if we can login with that user id though)

Vendor communication:

• 20/4/2018: Reached out to hikvision for guidance on proper disclosure procedure
• 21/4/2018: Hikvision responded.
• 21/4/2018: Vulnerability report sent.
• 23/4/2018: Hikvision responds that this will be fixed “by this week”.
• 24/4/2018: Hikvision released a fix on the issue at 2 p.m. and notified us.
• 24/4/2018: Verifying that Hikvision has nothing else to release before we publish this article.

Postmortem:

If you are a developer never EVER trust anything from the users. Filter, check and sanitize external input.
If you are an end user try to keep your devices updated and limit your IoT devices via network segmentation.This vulnerability is a nice example of how a service that was developed to help towards extra security (no port forwarding and no IoT exposed on internet) backfired spectacularly. We don’t know of any way to protect against these kind of attack other than use only products from well known vendors (which may also have issues of course but would have better monitoring and will respond -and not ignore everything like trackmageddon vendors-) or not use those devices at all.

Recently a very close friend asked me to do a penetration test on the company that she works for. It is a maritime company so the pen-test would be fun AND dangerous so why the heck not, I thought. I had also recently read the article from Ken Munro on OSINT from ship satcoms (https://www.pentestpartners.com/security-blog/osint-from-ship-satcoms/) and thought that the results could provide some additional slides for his presentation.

I found that vessels were connected to the internet by using Navarino Infinity (https://navarino.gr/portfolio/infinity) which is exposing a web interface. The web interface was not available directly as the root was returning a 404.I downloaded Infinity’s android app and found out that the app was connecting to an internal URL. When this URL was added as the http host header, you were presented with Infinity’s login screen over the internet. Success!

After a lot of testing and verification, 3 vulnerabilities were found (2 of them really critical). This was also quite tricky as you cannot use any tool that consumes a lot of bandwidth while a ship is at sea as it is deadly expensive so you have to keep it at a minimum.

Blind Sql injection:

I could see from the source that there was a script that was being used by the users to add more credit to their cards (or do some other stuff that I could not understand).That script was jq.php and after some quick tests I found out that it was prone to a blind sql injection attack which could be exploited to extract all data from underlying postgresql databases.

Poc:

/jq.php?action=loadtransactions&rows=5 returns in 1 second
/jq.php?action=loadtransactions&rows=5; pg_sleep(10) returns in 11 seconds

/jq.php?action=loadtransactions&rows=5; pg_sleep(15) returns in 17 seconds

Session fixation:

I also found that there was a phpsessid URL passed around as a URL parameter and this parameter was not changed after login. Thus phishing attacks become a plausible vector allowing you to login as the user or even worse chain it with the previous vulnerability to login as any user. This would also bypass 2-factor authentication that is available on certain installations of Navarino Infinity.

Improper handling of authentication / access control

As no proper pen test can be considered complete without some keyboard hitting, I randomly found out that if you change the class part in the URL to a class other than main but keep the function name as authenticate or validateAuthentication it will run that class’s main function and return some sensitive data (nothing critical) with no authentication at all. Even worse if the class does not exist it will run main class main function and show the map with the areas of interests (but NO vessels). In general any AJAX request that would be done by those pages would fail with an authentication required error.

Poc:

/index.php/logs/authenticate/
/index.php/admin/validateAuthentication/

/index.php/foo/authenticate/
/index.php/users/validateAuthentication/

After finishing the report I contacted Navarino who gave a quick response and acknowledged the vulnerabilities. They fixed everything and pushed a hotfix in less that 30 days in all installations which is impressive considering that there are over 6000 vessels (from what is stated in their website) we are talking about. That’s how security incidents should be handled by companies who have internet connected devices.

Maritime is getting into the connected era really quickly and this can cause problems to anyone who can not adapt and evolve. Ignoring reports by not answering or going black after acknowledging should not be an acceptable choice for any company let alone companies that handle satcom for vessels!