Here is my previous blog post about reporting Dialog security vulnerability.

Finally Dialog fixed their login vulnerability. So it is time to explain in deep what was it.

Note: Vulnerability is already fixed. So you won't be able to try it by yourself. This blog post is for education purposes.

First of all go to Dialog.lk

By Clicking Log in - mobile connect button with any Dialog mobile number or clicking Log in button without any User Name, Password

You can go to Dialog Mobile phone authentication page.

This is where all fun begins. You can enter any Dialog number you want & Dialog will send a notification to accept. Because it will take few seconds for a user to accept notification, frontend check notification status with backend every few seconds using an API endpoint.

This is the API response looks like for not accepted notification.

If you look carefully there is a id return from this API, that is where Dialog got it wrong. So what is this id? If you try again with the same mobile number for two factor authentication, you will see id is not same. So it is not an id related to the mobile number. If you look little bit closer you will see 2nd attempt request id is slightly higher than the first attempt request id. For example 2nd attempt request id can be something like 8030728. So it is clear that API response id is incremental & every time when a user try to log in to Dialog a new id generated by backend & frontend use that id to check notification status.

Then the next question is, if I know my request id & it is incremental, can I check other users two factor authentication status if I can replicate this API call? The answer is yes. You can do it as a Curl command or using Postman or what ever way you like.

So you can continue checking other users two factor authentication status.

Still not that bad because I can see status: "3" which is not approved notification with some other data. But once the user you are checking accept the notification, things get ugly. Like this ugly.

Dialog is returning a SSO url to frontend, so frontend can redirect user to this SSO url & user will be automatically logged in. Using this url now you can log into that user’s account.

And then there are so many things you can do. Check his personal information, his payment history, bill history, activate deactivate packages & so on.

Most hilarious part was that SSO url could be reused multiple times. Invalidate SSO url once it is used should be very basic level of security.

So within 9 hours after I publish the previous blog post, Dialog fixed the issue. Now they return a GUID instead of incremental id as the request id. Hope they fixed SSO url not expiring after 1st use issue also.

Here is a screen recording of the above steps I explained.

Cheers,
DilumN