Viva's website allows you to pay your bills using credit cards like VISA or MasterCard, or the regionally accepted K-Net. In the case of VISA and MasterCard, Viva pushes the data (your phone number, email, credit card number, expiration date, cvv code) in clear text, without encryption!
In any website that takes payments or has a user authentication portal, should offer a secure channel using SSL/TLS and the user sees the link starting with "https." In addition, current browsers show part of the address bar in green when the browser is able to verify that the website is secure and it is who it claims to be.
A friend was worried as she didn't see "https" in the URL, so I checked the pages' source code to see if it was sending the data in a secure channel via javascript or some other mean, without showing it in the URL, alas, it was all in the clear text.
Here's a screenshot of a sniffed packet session from my machine to viva.com.kw (94.128.1.30), while submitting the form data.
This is some of the text from the packet (I removed my personal data):
I have contacted VIVA Telecom and Mr. Salman Al-Badran (CEO) via Twitter on Saturday Oct 1st (when I found out about the issue). Mr. Salman replied on the same day and said he'll forward it to his team. I also gave him my email address in case his team wanted to get in touch with me.
Three days later I told Mr. Salman that the problem is still there and that I'll publish my findings on my blog next Sunday (a week from reporting the issue). He replied saying it'll be fixed on Oct 6th.
[this is fixed now] I checked today (Oct 6th) and the form now redirects to a secure website (https). The address bar may not always appear in a green color; In that case, do not use the website, but instead, refresh or try again until the icon looks like this:
not like this 
. Description of these can be found here. (the two images were produced by Google.)
[this is fixed now] Also, it seems like the changes they made broke the form in the main page, which sends the @ sign of the email address in hex form (%40). Just change the %40 to @ and submit the form again and it'll work.
I'd like to thank Mr. Salman for his prompt response to the matter. I wish other enterprise corporates' CEOs were as attentive and interactive with the consumers as he is. I would also like to point the finger at the technical team and the audit team who let this one slip by! This is a trivial and pivotal requirement of any online payment system!
What kind of complications the insecure site would have?
An attacker in the same network as you are can capture clear text that is being sent from your machine/mobile to the website. That's why the data shows in clear text in the picture above. If the connection was secure, it would have been garbled.
If the address bar showed in red, it is still possible to attack a visitor from the same network, by altering the content that is being transmitted via insecure channels, which could lead to changing the form itself and the user would end up sending the data to a different script/page or a whole different website that the attacker crafted to collect the data.
In any website that takes payments or has a user authentication portal, should offer a secure channel using SSL/TLS and the user sees the link starting with "https." In addition, current browsers show part of the address bar in green when the browser is able to verify that the website is secure and it is who it claims to be.
A friend was worried as she didn't see "https" in the URL, so I checked the pages' source code to see if it was sending the data in a secure channel via javascript or some other mean, without showing it in the URL, alas, it was all in the clear text.
Here's a screenshot of a sniffed packet session from my machine to viva.com.kw (94.128.1.30), while submitting the form data.
This is some of the text from the packet (I removed my personal data):
prepRechargeCreditForm%3Aholder=Mojo+Jojo&prepRechargeCreditForm%3AcardNumber=4550xxxxxxxxxxxx&prepRechargeCreditForm%3AyearList=XY&prepRechargeCreditForm%3AmonthList=XY&prepRechargeCreditForm%3Acvv2=XYZ&autoScroll=&prepRecharg
I have contacted VIVA Telecom and Mr. Salman Al-Badran (CEO) via Twitter on Saturday Oct 1st (when I found out about the issue). Mr. Salman replied on the same day and said he'll forward it to his team. I also gave him my email address in case his team wanted to get in touch with me.
Three days later I told Mr. Salman that the problem is still there and that I'll publish my findings on my blog next Sunday (a week from reporting the issue). He replied saying it'll be fixed on Oct 6th.
[this is fixed now] I checked today (Oct 6th) and the form now redirects to a secure website (https). The address bar may not always appear in a green color; In that case, do not use the website, but instead, refresh or try again until the icon looks like this:
not like this 
. Description of these can be found here. (the two images were produced by Google.)[this is fixed now] Also, it seems like the changes they made broke the form in the main page, which sends the @ sign of the email address in hex form (%40). Just change the %40 to @ and submit the form again and it'll work.
I'd like to thank Mr. Salman for his prompt response to the matter. I wish other enterprise corporates' CEOs were as attentive and interactive with the consumers as he is. I would also like to point the finger at the technical team and the audit team who let this one slip by! This is a trivial and pivotal requirement of any online payment system!
What kind of complications the insecure site would have?
An attacker in the same network as you are can capture clear text that is being sent from your machine/mobile to the website. That's why the data shows in clear text in the picture above. If the connection was secure, it would have been garbled.
If the address bar showed in red, it is still possible to attack a visitor from the same network, by altering the content that is being transmitted via insecure channels, which could lead to changing the form itself and the user would end up sending the data to a different script/page or a whole different website that the attacker crafted to collect the data.
7 comments:
Thanks Majed for making our world a better place! (No sarcasm .. no really!)
Thank you Majed for helping VIVA. Not only our CEO but the whole organization takes comments for improvement very seriously.
Thanks once again!
Huh, quite a coincidence! I've contacted zain yesterday about their HTTP log-in page. I mentioned the risks, but I got no response. I guessed that they didn't care that much about accounts, after all nothing much can be done with them.
However, now that I've read this, I remembered that they also have an online payment page. ... Just checked it, and it turns out that they know what they're doing (partially), they're using HTTPS. I actually hoped that they were using HTTP just so that I can show them how insecure HTTP is by linking to this blog-post!
But meh, I told them I won't use their online services as long as it's sent in clear text. It's their loss.
0x00FE,
It wasn't me who found the flaw. A friend noticed the lack of "https" in the URL & I dug through the source code to see if it was sent via JavaScript.
K-Net didn't have that issue & I always paid via K-Net so I never noticed the VISA & MasterCard problem.
Anonymous,
I'm glad things were fixed quickly, but it really makes me wonder: How could anyone build an online payment system without having a secure channel in mind?
You may want to audit your security & audit departments for other violations of security and privacy.
anxiousnut,
I checked Zain's & Wataniya's online payment before writing this post, but they had things set up properly on that.
But you are right about user logins going through http only. It won't affect the user financially, but it would lead to the exposure of full communications (phone calls & SMS) for a whole year!
Sameer here, i think majed needs to re visit the www.viva.com.kw for online payment assurance as seems me https based communication for online payments.
In case of anonymous user payment online, For first step it's not getting the confidential information once secure submission will take place via HTTPS then form requires the Visa or Master Card information via SSL/TLS transportation by hidden means (try to make another attempt for security check and do recontact to Viva if any issue found). Most recommended way is to get login first and feel 100% secure in all cases.
Anonymous/Sameer,
You should re-read my post. I'm aware it redirects to https & it has been so since Oct 6th.
Anonymous 2,
I received your comment by email but for some reason it's not showing up here.
The main site doesn't take any credit card info and when you submit the form, it submits to a secure portal (https). The submission itself is secure even though you came from an unencrypted page.
Yahoo Mail used to do the same thing: main page was http & when you submit the data, it goes to https. I sniffed the packets and it was apparent that the secure communications channel is established before sending the data.
I don't see a reason why I should login to pay. What if I want to pay for someone else other than myself?
I wouldn't want them to associate every mobile I pay for with my username.
Post a Comment