Grandstream IDOR

Vangelis Stykas 20 Aug 2018

Grandstream are a provider of IP and voice comms equipment. We were having a look at the GWN cloud management platform, used for remote device and wireless network management.

It connects around 5 million devices in total. That’s a LOT of devices in businesses all around the world.

Hosted in AWS, it must be secure, because it uses “Bank-grade TLS encryption from end-to-end”

But we don’t think they were counting on our resident API Destroyer, @evstykas is a free service with straightforward username/password authentication. No MFA, but hey.

After creating our own accounts for our own equipment, Vangelis noticed an issue with one of the API requests:

<screenshots and IDOR>


We reported the issue to Grandstream support, in the absence of a vulnerability reporting contact. In fairness, they were pretty good at receiving it and responding:

Ticket 20200807155357 was created and responded to the following day, confirming the vulnerability and that a fix had already been implemented.

A shame about the trivial IDOR in their cloud service, but great that they responded so promptly.

We have no idea if the service had been compromised using this vulnerability previously.


Insecure Direct Object References are hugely common in APIs. We still aren’t sure why IDOR/BOLA isn’t number 1 in the OWASP Top Ten, but it’s critical to authorise ALL requests properly.

Common areas that request authorisation is overlooked include:

Authorising a change to the email address to which password reset emails are sent

Authorising adding of a user to a group

Authorising modification of a user’s permissions

Any one of the above totally compromise user accounts and/or the wider system

If you don’t check that the requestor is the correct user, then your authorisation is shot to pieces: any authenticated user can make the request