EV-SSL, SSL, And Who’s Not Using It

It seems I’ve been picking on EV-SSL lately. It’s not intentional; I just have encountered a lot of questionable marketing fluff lately and wanted to talk about it. Today is no different. Tim Callan’s recent blog post got me thinking. Basically he referenced some SSL attacks that were disclosed at BlackHat, and suggested EV-SSL certificates as the cure to SSL MitM attacks and phishing in general. On the one hand, I believe his conclusion is conveniently aligned with his employer’s sales agenda. On the other hand, I acknowledge that EV-SSL could raise the bar…if it’s adopted and deployed in widespread fashion. And therein is the crux.
I’ve previously talked about the EV-SSL adoption rate (or lack thereof) in this blog. NetCraft has reported its findings of one million valid SSL-capable sites are in use (note: sites with invalid, self-signed, or expired SSL certs are not included in that count). And while I don’t have access to their commercial SSL Survey report for January 2009, we infer from some third party mentions that the report states around 10,000 EV-SSL sites were found. That’s 3,000 more than Verisign mentioned last month, but perhaps Verisign was only reporting what they alone issued. Given their marketshare (~75%, albeit that number is a year old) against total EV-SSL cert vendors, that seems to make sense.
Only 10,000 EV-SSL sites within two years seems very low to me, especially for something which is essentially an enhanced derivative of an already understood and accepted technology. People already know what SSL is and what function SSL certs perform, so that definitely is not the hold up. There just doesn’t seem to be much of an adoption momentum, and maybe that’s because the additional value these premium EV-SSL certs provide is questionable in the eyes of site owners.
But maybe I’m looking at this wrong. Only 10,000 EV-SSL sites seems a bit low, but what if they were 10,000 sites that matter? I suppose that would paint a different picture. If 10,000 big sites that account for a notable portion of the web’s traffic used EV-SSL, I suppose that actually might not be so bad. So I entertained that theory. I manually surfed to each of the upper 50 of Alexa’s Global Top 500 Sites list, and recorded who was using EV-SSL vs. normal SSL vs. no SSL. The idea is that these sites represent the most visited sites in all of the world (according to Alexa), and as such, assumingly have a vested interest in assuring their voluminous user population that the users’ accounts and transactions are secure. If most of these sites were using EV-SSL, then that would actually provide notable EV-SSL permeation into overall web traffic.
The process I used was simple: visit each of the Alexa-listed sites (the top 50), surf around to find a ‘signin’ or ‘signup’ form or other equally-sensitive use of HTTPS, and then watch if the URL address bar in my Internet Explorer 7 browser turned green when SSL was utilized. A green bar meant EV-SSL; no green bar but still having a valid lock icon is standard SSL. I found that only two sites (ebay.com and login.live.com) were using EV-SSL. That’s it. Just two. All of the other sites were using standard SSL, with the exception of ten sites that don’t use SSL at all with their login forms (youtube.com, hi5.com, mail.ru, photobucket.com, vkontakte.ru, imageshack.us, friendster.com, skyrock.com, odnoklassniki.ru, and dailymotion.com) and two more that don’t really receive sensitive info from the user and thus don’t necessitate SSL (bbc.co.uk and cnn.com).
We might label that a bleak picture. Ten of the fifty top sites (20%) don’t even use SSL for their logins. Only two use EV-SSL. I was a bit surprised to see the online retail giant, Amazon.com, didn’t use EV-SSL. If EV-SSL was a sure-thing to lead to better customer confidence and more online retail conversions, I would have figured they would have been all over it. They would not be one to overlook a technological advantage if the ROI helped their bottom line…that is, after all, how they got started. And given that they store credit card data for quick purchasing convenience, there is a certain financial value to compromising someone’s Amazon account; I’m surprised it hasn’t been the target of more phishing attacks to date.
Also surprising was Yahoo (login.yahoo.com), AOL (my.screenname.aol.com), and Google (www.google.com) all use standard SSL for their common backend authentication sites. These vendors offer multiple different web services, but tie it all back to a single authentication mechanism, much like a Single Sign-On (SSO) platform. And aren’t some of these vendors OpenID providers? That means a successful phish of a single account could be leveraged across many sites/services, even outside the realm of just these vendors. On Microsoft’s live.com site, I found that the login form (from login.live.com, which was presented over HTTP by default but did include a link to switch to HTTPS) did go to an EV-SSL site once submitted, but the signup page (signup.live.com) was handled with a standard SSL cert. Maybe they just want to discourage new signups while assuring existing accounts it’s safe to login.
But here’s another thought: maybe these sites have invested in standard SSL certificates before EV-SSL was popular, and just are waiting for their current certs to expire before renewing with EV-SSL variants. That seems plausible, but the results are a bit mixed. Google renewed their current standard SSL cert in May 2008 and signup.live.com was renewed in November 2008. That was fairly recent, and definitely after EV-SSL was well established. Opposite that, AOL’s my.screenname.aol.com certificate was issued in March 2007 and Yahoo’s is from January 2006; it’s arguable they were issued before EV-SSL really caught on. So it’s hard to say, but the thought might hold true for some cases. Certainly not others.
But again, maybe I’m still looking at it all wrong. EV-SSL might only make the most sense to certain verticals, like online banking sites. The Alexa list doesn’t really have any bank sites in their top 50. So I did a spot-check of some big bank site URLs pulled from the top of my head. Of all the ones I tried, only BankOfAmerica’s login site (which is separate from their normal site) used EV-SSL:
 
 
 
www.bankofamerica.com: standard SSL (renewed December 2008)
sitekey.bankofamerica.com: EV-SSL
www.wellsfargo.com: standard SSL (renewed June 2008)
online.wellsfargo.com: standard SSL (renewed July 2008)
www.chase.com: standard SSL (renewed August 2008)
chaseonline.chase.com: standard SSL (renewed April 2008)
online.citibank.com: standard SSL (renewed December 2007)
www.us.hsbc.com: standard SSL (renewed July 2008)
myonlineaccounts2.abbeynational.co.uk: standard SSL (renewed February 2009**)
That last one is very interesting. Abbey National Bank has been a notable target of phishing attempts going back a year. And yet, when they renewed their SSL certificate last week (February 12, 2009), they went with a standard certificate instead of EV-SSL. Whether they didn’t know or didn’t care that EV-SSL could help assure users against phishing, I don’t know. But if a bank that’s been phished for over a year doesn’t decide to buy into EV-SSL when it has the convenient opportunity…who will? Marketing fluff aside, that is probably the absolute best-case realized application for EV-SSL ever. User accounts have access to monetary instruments. The site has been an active target of phishing attempts for over a year. They needed new SSL certs anyway. Any one of those reasons by itself is (supposed) ground for EV-SSL, and they had all three reasons. Oh well, maybe they’re reconsider EV-SSL in 2010 when their new cert expires.
Until then,
– Jeff
**Postscript: it seems Abbey National Bank’s site uses a cluster of SSL web servers that have different SSL certs installed. In some cases, I connect to a server that gives me an SSL cert that was issued on Feb 12 2009. On other occasions, I get connected to a server that gives me an SSL cert that expires on Feb 24 2009 (i.e. next week). So apparently they have currently upgraded the SSL certs on some of their servers, but not all. I just wanted to mention this in case you were poking around yourself and noticed the discrepancy. Here is a screenshot of the newer SSL cert, to prove I’m not making stuff up:
 
 
 

Link: https://www.zscaler.com/blogs/research/ev-ssl-ssl-and-whos-not-using-it

The ‘SSL Encryption Without Authentication’ Debate

Every so often I encounter a debate where an individual is making a case for the value of supporting/accepting self-signed SSL certificates in browsers. Basically their argument is “I do not care about authentication of SSL, I just want the encryption part…so why should I have to pay VeriSign or another commercial CA all that money for an SSL certificate that verifies my identity?” This question seems to be newly fueled by the fact that Firefox 3 now requires the user to go through a laborious 4-step process to allow the browser to connect to an SSL site utilizing a self-signed certificate.
The problem is: anyone who asks the above question is ignoring how SSL works and how SSL employs encryption in the first place. If you are trying to keep an evil person from learning your secrets, but you do not authenticate who you are talking to, you are basically overlooking that you may well be telling your secrets to the evil person directly! If you don’t authenticate the identity of someone, they are essentially an unidentified stranger to you. And the idea of wanting to keep your secrets from strangers (i.e. encryption) but also be willing to give your secrets to strangers (i.e. no authentication) is contradictory. If you have no idea of who you are talking to, then what value is the encryption really providing? How do you tell a complete stranger a secret in private and still expect the secret to remain safe from strangers?
Let’s look at how SSL tackles authentication via the use of certificates. A signed (i.e. authenticated) certificate is essentially a digital record that says “My name is Bob, and this big trusted company over here agrees with that statement.” The idea is that browsers trust a set of big trusted companies (Certificate Authorities such as VeriSign, Thawte, etc.), and that creates a trust chain: we trust the browser, the browser trusts the CA, the CA says this is Bob, so we trust it is Bob. On the other hand, a self-signed (i.e. non-authenticated) certificate is a digital record that says “My name is Bob, and you will just have to trust me that what I am saying is true.” It’s almost like the honor-system approach of everyone stating who they are; but how do we know if they are lying? Essentially, you don’t…because self-signed certificates can be created by anyone to say anything (that is the whole purpose of self-signed certificates). An evil attacker can trivially generate certificates that say “My name is Paypal, and you will just have to trust me,” “My name is eBay, and you will just have to trust me,” “My name is Bank of America, and you will just have to trust me,” etc. The only thing that prevents the attacker from deceiving you with these malicious self-signed certificates is your browser’s better judgment of not trusting these arbitrarily fabricated declarations of identity having no proof. Remember: security is about keeping you safe despite lies and deception; we need to ensure that a simple lie by an attacker won’t compromise the entire process. In this case, self-signed certificates offer a way for attackers to lie about their identity with impunity.
So let’s go back to the original premise of the question and look a bit more technically at what’s going on. The argument is the desire to have encryption without authentication. That means the sensitivity and secrecy of the data is still an issue/desire, otherwise, why bother with encryption? The primary threat vector mitigated by end-to-end encryption on a network is passive eavesdropping (a.k.a. network sniffing). But keep in mind that, in SSL, the encryption keys are dynamically negotiated by the two endpoints at the start of the connection (after authentication has concluded). Thus encryption by itself offers no security value if the passive eavesdropping attacker decides to switch to an active man-in-the-middle or interception attack (which is technically viable if they were already in a position to eavesdrop your network traffic to begin with); this just means you are now negotiating an encryption key with the attacker and directly sending them your data. SSL normally mitigates these attacks by the use of authentication, to ensure the endpoint you negotiate your encryption key with is indeed who they say they are. However if we allow self-signed certificates to be used and therefore overlook the authentication aspect, there is zero guarantee that the person you just negotiated an encryption tunnel with isn’t the person you were trying to secure your information from (via encryption) in the first place. True, it does require the attacker to switch from a passive attack to an active attack, but that is of little consequence if the attacker truly wants to compromise the data. And attackers are already playing very active roles in attacks today (setting up an entire phishing site and sending out phishing emails isn’t exactly a passive affair…).
I have a hunch the real motive behind petitioning for self-signed certificate support is purely economic. Web site operators want to appear to conform to user expectations of security and privacy via the use of SSL (the whole “make sure the little lock icon appears in your browser before you send sensitive info” mantra), but without having to shell out cash for a real SSL certificate (if they just paid the money for a proper CA-signed certificate, this whole debate is moot). It’s the façade of security without actually delivering on the promise. But those that are using self-signed SSL certificates for production uses, even prior to the newer crop of browsers handling them less favorably, are already doing a slight injustice to security as whole—because they are forcing a user to essentially make a “Yes I know this is insecure, please proceed anyways” decision. Accepting self-signed certificates in older browsers is usually just a semi-scary dialogue followed by a one-click override from the user….and apparently the protagonists of this debate believe this (was) acceptable for users to do. But isn’t that just exacerbating the phenomenon of users continually making bad security choices, by explicitly encouraging them to do so? We should not be encouraging users to bypass or override security protection mechanisms put there for their own good; what starts as an encouraged exception may eventually become an assumed norm (I’d like to make a Pavlov reference here, but I don’t want it seen as belittling the behavior or intelligence of users).
All of that said, I suppose there are some certain approaches that may offer a balanced compromise. If we look at SSH, we encounter the same basic problem: when the client first connects to the server, it doesn’t know if the server is actually the right server or not. So usually the client prompts the user with a small fingerprint of the server’s identity in order to verify that identity out-of-band. If the user instructs the client to proceed, the client caches the server’s identity fingerprint. From that point on, as long as the server’s identity fingerprint matches what is cached, life is good. If that identity fingerprint ever changes, then lots of security bells and whistles go off because something is afoot, such as a man-in-the-middle attack (or the server admin re-generated their identity information, which is not something done arbitrarily). Basically it reduces the “no-authentication” scenario down to only the very first, initial connection that the client makes to the server. An attacker would have one chance—and one chance only—to intercept that very first connection and supply impersonated credentials. But also keep in mind, if the attacker stops the interception ruse and allows the connections to proceed to the proper server, the client will immediately alert the user to something fishy because the server identity (as seen by the client) has changed. So an attacker can remain undetected if and only if they intercept that very first connection, and only for as long as they actively and continually intercept all future connections. That reduces the chance of successful attack to a very small window, and requires moderate effort on part of the attacker to remain undetected. Perhaps this approach could be adapted to browsers, where a self-signed certificate for a given site can be manually verified once (the first time), and then cached so that as long as the certificate doesn’t change, it can be assumed to be the same site. It is entirely a change to the client browser and how SSL certificates are validated; no SSL protocol or server-side changes are necessary.
But unless browsers were to enact such a change, the use of self-signed certificates in this day in age is a risky proposition. They are fine for testing purposes, but they should never be used in production with real users. An alternate approach to using self-signed certificates is to create your own CA (you can use the free OpenSSL suite to do so) and use your CA to sign your server certificates; then encourage your users to install your CA certificate. This at least maintains the integrity and security value of the SSL protocol, and would allow the users’ browsers to function without any security warnings requiring user interaction. However, you must then guard your CA private keys thoroughly, as you have now because a trusted entity in the browser’s eyes; if your CA keys are stolen, it would allow attackers to generate arbitrary certificates that are signed by your CA. In other words, the attacker could create the equivalent of arbitrary self-signed certificates but would actually use you as the trusted signing authority, and since the users’ browsers now trust your CA, the browsers would inherently trust all of the attacker’s certificates.
Regardless of what you do, one thing is for certain: you do not want to be the weakest link in the security chain. SSL literally has a trust chain established by the use of authentication certificates, and trying to bypass authentication (and the associated trust chain) compromises all security (including encryption) offered by SSL. No one likes being identified as the weakest link, so save your company the PR trouble and just buy that SSL certificate from a proper CA. It’s what is best for everyone involved, and your wallet will recover.
– Jeff

Link: https://www.zscaler.com/blogs/research/ssl-encryption-without-authentication-debate

outis is a custom Remote Administration Tool (RAT).

Disclaimer: Use at your own risk. Do not use without full consent of everyone involved. For educational purposes only. outis is a custom Remote Administration…

Link: http://seclist.us/outis-is-a-custom-remote-administration-tool-rat.html

Crypto-Ransomware Running Rampant

There’s no doubt that ransomware is one of the most popular malware threats of 2014. Zscaler is not alone in this opinion, as other security firms have observed up to a 700% increase in infection rates to ransom-like malicious activity on victim PCs.  It’s no wonder the attacks are so effective when for example, the delivery mechanism is designed to impersonate a legitimate service such as a harmless eFax.
 
This link is seen from a phishing e-mail.
Ransomware attacks can be monetized quickly and efficiently without the need to create a large scale botnet or expose the attacker’s affiliate ID via click-fraud schemes. We’ve seen multiple attack vectors leveraged to target end users. Some vectors we have monitored include phishing email links or a malvertising campaign which leverages exploit kit distribution. Attackers will often pose as legitimate services, such as a law enforcement agency or a mass media outlet, in order to lure the unsuspecting victim into their scheme.
We recently encountered a ransomware campaign leveraging phishing e-mails purporting to be from the Australian Postal Services. The spam campaign themes used by the attackers involve tracking services or mobile invoices containing a link to the malicious content.  Upon completion of a CAPTCHA, the user is provided a zip file which contains a malicious executable posing as a PDF document.
 
At the time of research, this particular file shows a a detection rate of 16/53 antivirus engines on Virustotal. Before the victim even has a chance to realize their mistake, they are greeted by a message informing them of just how impacted they are.
 
It’s rare for a piece of malware to name itself to the victim…
 
The goal of Cryptolocker or any other Crypto-Ransomware attack is to encrypt personal files and hold them hostage. The attacker encrypts the files using a specific key which is either obtained during the phone home request to a Command & Control (C2) server, or hard-coded within the malicious executable. In  this case, the malicious executable itself is falsely presenting itself as a valid executable for AQQ IM. 
 
AQQ is a popular IM application
Cryptolocker’s encryption has been an evolving piece of this threat, often relying on asymmetric encryption to lock the victim’s files.  In this particular version, the Cryptolocker variant targeted the following folders for encryption:
 C:\MSOCache\All Users\
 C:\Users\[Public/Username]\
The “.encrypted" files can only the key controlled by the attacker can release them.
The threat will also drop a file in the Windows directory and an associated registry key to launch the file upon boot.  This will ensure that the threat will remain persistent if the victim attempts to reboot their system.
 
The autostart value is randomly generated.
Cryptolocker will phone home to a hard-coded malicious domain via SSL. The SSL certificate is signed using the printable string ‘debian’. This transaction is the secure communication which will provide the specific key needed to encrypt the victim’s files.
 
Viewing the C:\Windows\uhjrajyj.exe in this case will reveal the hardcoded domain used to phone home.
The phone home address is hard-coded within the malicious payload.
 
Decrypted SSL traffic reveals the initial call back attempt that contains a POST request with victim’s machine name and unique ID as seen below:
 
Decrypted call back attempt
This variant was found to be using a Domain Generation Algorithm for the C2 server communication, similar to the phone home method of Zeus.GameOver.
 
DGA activity
These domains are largely returning 504 errors now as they have either not yet been registered or have already been shutdown.  A few do were still live at the time of the research.  Zscaler inspected the associated IP addresses and found them to be hosted in the Russian Federation. The two server IP addresses of note at the time of the blog are 46.161.30.20 and 46.161.30.19.  Active ransomware URLs leading to these servers include:
usygoseqowapadoh[.]com:443
usygoseqowapadoh[.]com/topic.php
octoberpics[.]ru:443
octoberpics[.]ru/topic.php
Conclusion
Administrators should be on the lookout for the above connections as they likely indicate a compromised system. Given how prevalent this threat is, the U.S. Government recently released an associated alert on the US-CERT site. 
Taking regular backups of your personal files remains a user’s best chance at mitigating the threat if they have been hit by this attack. It is also important for system administrators to enforce  strict file-type access control policies surrounding the download of archive and executable files from unknown sources.
 

Link: https://www.zscaler.comhttps://www.zscaler.com/blogs/research/crypto-ransomware-running-rampant

Mobile App Wall Of Shame: Tinychat For IPhone

Tinychat
 
Price : Free
Category : Social Networking
Updated : December 29, 2014
Version : 5.0
Size : 19.41 MB
Language : English
Vendor : Tinychat Co
Operating system : iOS
 
 
Background:
Tinychat is a group video chat application that allows users to chat online and also create their own chart rooms. Currently, this application is ranked among the top 200 apps in the Social Networking category on the iTunes app store. Tinychat claims 5 million minutes of usage per day, making it one of the largest voice and video chat communities on the Internet today.
A user must submit their email address and password in order to create an account. Alternately, a user can also use their Facebook or Twitter account to login to this application.
 
 
 Vulnerability – Clear text username/password
 
App Login page
The current Tinychat App (verified on Version 5.0) has a serious information leakage flaw whereby username & password information for the Tinychat user is sent in clear text (unencrypted) to the application server. This vulnerability woud make it possible for an attacker to easily sniff network traffic and compromise the user account.
 
 
Below is the sample capture of a Tinychat user login attempt. As seen in the request, the username & password information is sent in clear text.
 
 
 
 
 
 
Login:
Login Capture
 
 
Similarly, when a user attempts to register an account on Tinychat, the following HTTP request is generated. The username, password and email address information of the user passes in clear text as seen in the request below:
Account registration:
 
Registration Capture
An attacker can easily takeover the victim’s account by sniffing the vulnerable application’s network traffic. This can further lead to more sophisticated attacks and can often lead to the compromise of other applications/services due to password reuse.
 
 
ZAP Analysis: ZAP in action.
This flaw was identified using Zscaler Application Profiler (ZAP). ZAP is a free online tool that can be used to analyze mobile applications for vulnerabilities and privacy issues as seen in the above screenshot. We have reached out to Tinychat developers, informing them of this security flaw.
Conclusion:
This type of security flaw can be uncovered by simply analyzing the network traffic sent by the application. It is disappointing to see such applications getting uploaded to Apple iTunes store without basic security tests like checking for clear text username/passwords being conducted. This is not the first time we have seen a popular iOS application with this security flaw, but Apple continues to ignore performing a basic security check as part of their vetting process for adding new applications to the app store.
Credit: Analysis by Lakshmi.

Link: https://www.zscaler.comhttps://www.zscaler.com/blogs/research/mobile-app-wall-shame-tinychat-iphone

Mobile App Wall Of Shame: Quikr

Quikr Local Classifieds
Quikr app logo 
Price : Free
Category : Lifestyle/Shopping
Platform : iOS and Android
Updated : February 12, 2015(Android), 22 January 2015(iOS) 
Version : 7.42(Android), 2.8.2(iOS)
Size : 3.89 MB(Android),10 MB(iOS)
Language : English
Vendor : Quikr India
 
Background:
 
Quikr is India’s largest online and mobile classifieds portal. Like Craigslist, Quikr provides the users with a platform to help them buy, sell, rent and advertise across multiple categories like real estate, jobs, entertainment, education, matrimonial, etc. Quikr also has a mobile app on both the Android and iOS platforms. 
Application Chart (information retrieved from Appannie & xyo.net)
 
Android
iOS
Overall Ranking(India)
20
90
Category Ranking(India)
5 (Shopping)
8 (Lifestyle)
Total number of Downloads
12 Million
108 Thousand 
Rating 4/5
3.5/5
 
A user is required to provide an email address and password when creating an account. After creating an account, the user can the post advertisements on Quikr. The application also provides functionality wherein different users can chat with each other.
 
Vulnerability – Clear text username/password
The current version of Quikr mobile application has a serious data leakage vulnerability. It has been verified that both the current Android and iOS versions of the application are sending username and password information via the HTTP protocol in cleartext. This security vulnerability allows an attacker on the same network to capture the credentials sent by a Quikr user to the application server and thus compromise the user’s account which may lead to posting fake ads on account owner’s behalf, selling and buying products and sending spam messages via chat to other users.
 
The flaw has been confirmed on versions 7.42 (latest versions available on Feb 12, 2015) on the Android platform and version 2.8 (latest version available on Jan 22, 2015) on the iOS platform. 
 
Vulnerability in iOS version
When a user tries to register for an account in the Quikr application, an HTTP request is generated as shown below. In this request, the userid, password and mobile number of the user are sent in cleartext. 
 
Account Registration:
 
[-]  Method: POST
Url: http://services.quikr.com/api?                 method=registerUser&secCode=fd1f2276c71627c35e2a9c5f8838c09c&version=1.5
Host: services.quikr.com
User-Agent: Quikr/2.8.2 CFNetwork/711.1.16 Darwin/14.0.0
Request Body:cityId=23&userId=zscalerappscan%40zscaler.com&password=password123&mobile=9876543210&demail=969eac57dbfc4079a935fadf7ab261d6%40quikr.com
Server Response: AJBiY , N , .E]n3 , i^0%] , 1}qa , K;\OU4
 
 
Similarly, below is the traffic capture when an already existing user tries to login to their account. The userid and password are passed in cleartext.
 
Login:
[-]  Method: POST
Url: http://services.quikr.com/api?method=login&secCode=fd1f2276c71627c35e2a9c5f8838c09c&version=1.5
Host: services.quikr.com
User-Agent: Quikr/2.8.2 CFNetwork/711.1.16 Darwin/14.0.0
Request Body: [email protected]&[email protected]&password=password123
Server Response: 1`QaL , B*RD , , ,
Vulnerability in Android version
 
We will first test the Quikr application installed on a Google Nexus tablet. The Quikr application version available in the Google Play store for the tablet was v6.9. Below is the sample traffic capture when a user tries to register a new Quikr account or login to their existing Quikr account.
 
Account Registration:
 
[-]  Method: POST
Url: http://services.quikr.com/api?method=registerUser&version=1.5&secCode=zXcv80386Mdp1hs0q7o0p9uiLZV37TdF&consumerVersion=7.42&density=2.0&[email protected]
Host: services.quikr.com
User-Agent: QuikrConsumer
Request Body: –s2retfgsGSRFsERFGHfgdfgw734yhFHW567TYHSrf4yarg , Content-Disposition: form-data; name=”cityId" , , 23 , –s2retfgsGSRFsERFGHfgdfgw734yhFHW567TYHSrf4yarg , Content-Disposition: form-data; name="demail" , , [email protected] , –s2retfgsGSRFsERFGHfgdfgw734yhFHW567TYHSrf4yarg , Content-Disposition: form-data; name="mobile" , , 8234567890 , –s2retfgsGSRFsERFGHfgdfgw734yhFHW567TYHSrf4yarg , Content-Disposition: form-data; name="userId" , , [email protected] , –s2retfgsGSRFsERFGHfgdfgw734yhFHW567TYHSrf4yarg , Content-Disposition: form-data; name="opf" , , json , –s2retfgsGSRFsERFGHfgdfgw734yhFHW567TYHSrf4yarg , Content-Disposition: form-data; name="password" , , [email protected]
Server Response: {"login":{"auth":1,"code":"usercreated","message":[{"direct":"New user created"}],"email":"[email protected]","mobile":"8234567890","city":"23","name":"","UserSession":"PGR8fU59OHVzOWMhfFI+fll0Qj5mdnIjRXd0Rm57T0dZPXw\/Q0RDYCE4amJ5L3R5PHVdTGpORSY6KDhjbl40LlliaztN","emailCRC":null,"cityName":"Bangalore","cityId":"23","app_notif_status":1,"sound_preference":1,"notif_alarmtime":"08:00 PM","userClassification":null,"isSharedPB":0,"isSharedFB":0,"userType":1,"numAlerts":0,"numAds":"0"}}
 
Login:
[-]  Method: POST
Url: http://services.quikr.com/api?method=login&version=1.5&secCode=zXcv80386Mdp1hs0q7o0p9uiLZV37TdF&consumerVersion=7.42&density=2.0&[email protected]
Host: services.quikr.com
User-Agent: QuikrConsumer
Request Body: –s2retfgsGSRFsERFGHfgdfgw734yhFHW567TYHSrf4yarg , Content-Disposition: form-data; name="demail" , , [email protected] , –s2retfgsGSRFsERFGHfgdfgw734yhFHW567TYHSrf4yarg , Content-Disposition: form-data; name="userId" , , [email protected] , –s2retfgsGSRFsERFGHfgdfgw734yhFHW567TYHSrf4yarg , Content-Disposition: form-data; name="opf" , , json , –s2retfgsGSRFsERFGHfgdfgw734yhFHW567TYHSrf4yarg , Content-Disposition: form-data; name="password" , , password123
Server Response: {"login":{"auth":1,"code":"success","message":[{"direct":"You are successfully logged in"}],"email":"[email protected]","mobile":"8234567890","city":"23","name":"","UserSession":"PGR8fU59OHVzOWMhfFI+fll0Qj5mdnIjRXd0Rm57T0dZPXw\/Q0RDYCE4amJ5L3R5PHVdTGpORSY6KDhjbl40LlliaztN","emailCRC":null,"cityName":"Bangalore","cityId":"23","app_notif_status":1,"sound_preference":1,"notif_alarmtime":"08:00 PM","userClassification":"0","isSharedPB":0,"isSharedFB":0,"userType":1,"numAlerts":0,"numAds":"0"}}
 
As you can see in the above requests, all communication between the mobile app and server is in sent via cleartext, which includes sensitive user information.
 
ZAP Analysis:
ZAP in action – Android
ZAP in action – iOS
This flaw was identified using the Zscaler Application Profiler (ZAP). ZAP is a free online tool that can be used to analyze mobile applications for vulnerabilities and privacy issues as seen in the above screenshots.
Conclusion:
We continue to find new popular applications in the Apple and Google app stores that are leaking device data and sending out sensitive user information in cleartext. This is a good argument for the use of one time passwords when establishing accounts on mobile apps. As a user, you can never know with certainly if your credentials are being transmitted/stored securely. By leveraging a password manager and ensuring that passwords are unique for all apps, at least you can be assured that if your credentials are compromised due to poor app security, only that specific account will be impacted.
Credit: Lakshmi Devi.

Link: https://www.zscaler.comhttps://www.zscaler.com/blogs/research/mobile-app-wall-shame-quikr

Mobile App Wall Of Shame: Shaadi.com

Shaadi.com
Price : Free
Category : Social
Platform : iOS and Android
Updated : Mar. 9, 2015 (Android), Mar. 10 2015 (iOS)
Version : 4.2.2 (Android), 4.2.1 (iOS)
Size : 8.28 MB (Android), 17.7 MB (iOS)
Language : English
Vendor : People Interactive (I) Pvt. Ltd.
Background:
 
Shaadi.com is the world’s largest matrimonial website, active since 1995. This matrimonial site permits individuals to post their profiles and responses including horoscope, caste, language and religion. Shaadi.com provides applications designed for the two main mobile platforms – iOS and Android.
Application Chart (information retrieved from Appannie & xyo.net):
 
Android
 
iOS
Global Ranking
15
92
Category Ranking
12 (Social)
24 (Social networking)
Total number of Downloads
~1 million
 ~0.3 million
Rating
3.9/5
2.7/5
A new user is required to register by providing an email address and a password, along with basic personal details. After registering the account, the user can surf profiles created by others. The application also provides a chat facility.
Vulnerability – Cleartext username/password
 
Login screen
The current version of the Shaadi.com application has a serious security flaw. It has been verified that both the iOS and Android versions of the application transmit the username and password via HTTP in cleartext. This flaw allows an attacker to capture the credentials sent by a user to the application server and thus compromise the user’s account, which may lead to compromise of user’s personal data. The service also provides premium accounts to paid customers. 
The application was tested on both the Android and iOS platforms. The vulnerability has been confirmed on Android (v4.2.2 – latest version, updated on Mar. 9, 2015) and iOS (v4.2.1 – latest version, updated on Mar. 10, 2015).  
Vulnerability in iOS version
When a user tries to register for an account on the Shaadi.com application, an HTTP request is generated. In the request the userid, password and mobile number of the user is sent in cleartext as seen below:
Account Registration
 
[-]http://www.shaadi.com/registration/user/?regmode=app&OS=native-iphone
Method: POST 
Host: www.shaadi.com 
User-Agent: native-iphone|4.1.0 
Request Body: form_referral_url=&form_url=http%3A%2F%2Fwww.shaadi.com%2Fregistration%2Fuser%3Fregmode%3Dapp%26appver%3D4.1.0%26os%3Dnative-iphone%26deviceid%3D—%257C—&form_name=MOB_DR_SEO_REG1&frompage=From+Reg+Page&go=&olmt_home_regpage=&hid_year=&oscode=2&email=fnzscalerlnzscaler%40gmail.com&password1=p%40ssword123&postedby=Self&first_name=fnzscaler&last_name=lnzscaler&gender=Male&day=01&month=01&year=1994&community=No+Religion&mother_tongue=Konkani&countryofresidence=USA&contact_tel_number=Landline+No.
 
Similarly, when an already existing user tries to login to his account by providing his username and password, these credentials are also being sent in cleartext. Below is the traffic capture when a user tries to login to an existing account:
 
Login
 
[-]http://www.shaadi.com/native-apps2/user/[email protected]&[email protected]&appver=4.1.0&os=native-iphone&deviceid=—%7C— 
Method: GET            
Host: www.shaadi.com            
User-Agent: Shaadi/462 CFNetwork/711.1.16 Darwin/14.0.0            
Server Response: {“status":"200","data":{"sid":"7B16D793AFF0443EE1320F85EFD1B4C51425446439","abc":"0CE03847FB4B0C981EB552E34E1C96B61425446522|ZSH82845405|","premium":false,"gender":"Male","age":"21","memberstatus":"ToBeScreened","memberlogin":"ZSH82845405","photograph_status":"photo_request","update_available":false,"has_notification":"N","has_chat_notification":"N","content_settings":{"eoi":"Y","acc":"Y","msg":"Y","nf1":"N","dr":"Y"},"display_name":"SH82845405","username":"SH82845405","email":"[email protected]","use_connect":1,"upgrade_message":"UPGRADE TO PREMIUM","support_telephone":"1860-200-3456","payment_telephone":"1860-200-3456"},"expdt":"20150403002202","banner_images":{"banner_search_results":{"title":"Become a Premium Member & connect directly via","subtitle":"EMAIL, CHAT & PHONE","details":"","version":"","img":"http:\/\/img.shaadi.com\/community\/images\/app\/banner_search_results_male_free_high.png"},"banner_accepted":{"title":"Upgrade to Premium & start chatting with your Accepted Members!","subtitle":"","details":"","version":"","img":"http:\/\/img.shaadi.com\/community\/images\/app\/banner_accepted_free.png"},"banner_inbox_single":{"title":"1 Member like your profile!","subtitle":"Become a Premium member & write back to them today","details":"","version":"","img":"http:\/\/img.shaadi.com\/community\/images\/app\/banner_inbox_single_male_free_high.png"},"banner_inbox_multiple":{"title":"#count# Members like your profile!","subtitle":"Become a Premium member & write back to them today","details":"","version":"","img":"http:\/\/img.shaadi.com\/community\/images\/app\/banner_inbox_multiple_male_free_high.png"}}} 
 
Vulnerability in Android version
 
Account Registration
 
[-]http://www.shaadi.com/registration/user/?regmode=app&OS=native-android 
 
Method: POST            
 
Host: www.shaadi.com            
 
User-Agent: Mozilla/5.0 (Linux; Android 5.0.2; Nexus 7 Build/LRX22G) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/37.0.0.0 Safari/537.36            
 
Request Body: form_referral_url=&form_url=http%3A%2F%2Fwww.shaadi.com%2Fregistration%2Fuser%3Fregmode%3Dapp%26os%3Dnative-android%26deviceid%3D–%7C–%26appver%3D4.1.3&form_name=MOB_DR_SEO_REG1&frompage=From+Reg+Page&go=&olmt_home_regpage=&hid_year=&oscode=1&email=vulapps%40zscaler.com&password1=p%40ssword1234&postedby=Self&first_name=fnzscaler&last_name=lnzscaler&gender=Male&day=10&month=10&year=1985&community=Spiritual+-+not+religious&mother_tongue=Marathi&countryofresidence=USA&contact_tel_number=Landline+No. 
 
Login
 
[-]http://www.shaadi.com/registration/user/login-submit 
 
Method: POST            
 
Host: www.shaadi.com            
User-Agent: Mozilla/5.0 (Linux; Android 5.0.2; Nexus 7 Build/LRX22G) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/37.0.0.0 Safari/537.36            
Request Body: go=&email=vulapps%40zscaler.com&password=p%40ssword123&autologin=0&autologin=Y
 
ZAP analysis:
 
ZAP in action – Android
ZAP in action – iOS
Conclusion
The list of mobile applications in Google Play and the iTunes App Store that send out sensitive information in cleartext continues to grow. Therefore, it is extremely important to keep separate passwords for different applications and never use the password of your financial applications anywhere else.
Credit: Lakshmi Devi.
 

Link: https://www.zscaler.comhttps://www.zscaler.com/blogs/research/mobile-app-wall-shame-shaadicom