When looking for a new house to buy in the UK, the chances are at some point you will end up on the website of RightMove or Zoopla. With RightMove claiming they are "the UK's number one property website" and Zoopla being "one of the leading property sites in the UK", you might expect their web security to be up to scratch. As it turns out, you might not be that impressed.
Introduction
When I see big name sites that advertise on TV and proclaim to be the biggest and best in their field, I find myself wondering what their website security is like. I mean, they have all this budget to spend on TV adverts, they must have made allowances for securing their website and their user's data, right? Unfortunately after some very basic checks I generally find myself disappointed, or in some cases shocked, at just how poor the security really is.
Insecure login forms
Having recently started to browse property websites my time came to sign up for an account at both RightMove and Zoopla. I was almost immediately disappointed to see that both of these sites load their login form as a popup. The problem with loading the form in a popup is that the user has no idea if the form is secure or not. To demonstrate, try and determine which form below is loaded using https:// and which one isn't.
The point is you can't, at least not easily in most normal circumstances. If the login form was loaded as a page, then the user would be able to see whether or not the green https:// was present in the address bar and whether or not the form was loaded securely. As it turns out, the RightMove login form is loaded securely while the Zoopla login form is loaded over plain old insecure HTTP. Here you can see the links when we inspect the elements using the Chrome Developer tools.
Unfortunately, the fact that the login form is loaded securely actually doesn't really matter. The problem is that the link to the login form was loaded insecurely and that means it could have been tampered with as I have demonstrated before with a Code Injection attack. Not only that but the user is now susceptible to an SSL stripping attack like the one I showed using my WiFi Pineapple and SSLstrip. Using Transport Layer Security only on 'sensitive' pages is simply not enough. To top matters off, Zoopla are actually aware of this problem already. I know this because I noticed a little link down at the bottom of their sign in form.
If you want to, and you spotted this greyed out text down at the bottom there, you can sign in securely. As opposed to the insecure login form you're about to use which could result in your email address and password being leaked to an attacker. Why someone would decide that they needed an insecure login form with the option of security is beyond me. This should be secure from the get go. Security should not be optional.
User credentials as plain text GET parameters
Okay, so the login forms haven't been done as well as they could have and a common response we hear in the web security community is "It's OK, we POST to HTTPS". The idea here is that even though the form was loaded in an insecure fashion, it's sending user credentials to a secure page so we're all safe. Wrong again! Just like the link to the secure login page can be intercepted and modified by an attacker, so too can the action on the form (OWASP warns about this too). Once the form is being loaded over HTTP you can actually change the action to be anything you like, including your own malicious page. Referring back to my previous blog on Code Injection, I can actually direct the user away from the target site or inject my own malicious page into their site. This would result in the POST data submitted with the form being intercepted and stolen by an attacker, which is not so good. On a little closer inspection though I realised that the form wasn't even using POST and was in fact using GET. When logging in, your username and password were being appended right there on the end of the URL for the whole world to see. This prompted me to get in touch with both Zoopla and RightMove to let them know and see what could be done about it.
Click here to see full conversation@zoopla Plain text credentials as GET parameters over HTTP... This is bad security: pic.twitter.com/TFrqnXLKkl
— Scott (@Scott_Helme) August 5, 2013
Click here to see full conversation@rightmove This is not how you handle user login credentials... pic.twitter.com/3pbVVvTPt2
— Scott (@Scott_Helme) August 4, 2013
Fortunately, since contacting both Zoopla and RightMove, they have updated the login forms to use POST data instead of GET parameters. Whilst all of the issues in the sign in process haven't been resolved, that was probably the most urgent.
Why not secure the whole site?
If you do a little digging in the source code of both sign in forms you can see that there is a login page you can navigate to manually and they are both accessible using HTTPS.
Both of these forms even redirect you to the https:// URL if you manually try to navigate to a http:// version. Again, whilst this can be easily circumvented by the very malicious attacker we're trying to defend ourselves against by using TLS, the acknowledgement we need to protect these pages is there. Why don't they just use https:// across the entire site though? They have the certificates, as you can see in the images above, so why not just make the entire site https:// across the board? At that point you could even go one step further and issue a HSTS Policy to really protect your users. I know there are issues like 3rd party content needing to be accessible via https:// to prevent mixed content warnings, load balancers and content delivery networks also need to be capable of handling TLS but it can and is being done everyday on a host of websites across the Internet. Besides, do you really want to type your old and new passwords into this page?
What about those cookies?
After striking up a little conversation with Zoopla on Twitter I also noticed that their session id cookies aren't flagged as httpOnly and told them about it.
@zoopla https then back to http is pointless as session ID vulnerable to hijacking. Also cookie not http only - XSS? pic.twitter.com/zLQuwv2NC4— Scott (@Scott_Helme) August 5, 2013
Whilst the httpOnly flag won't prevent a man in the middle from accessing your cookie in transit, it does help prevent client side script from accessing it. This means if a Cross Site Scripting (XSS) flaw was found in the Zoopla site and exploited, it would be a lot harder for an attacker to get their hands in your cookie jar. You definitely don't want that happening because the attacker can then hijack your session as I've demonstrated here and here and take over your account. There are legitimate reasons to not set this flag, if your JavaScript needs to access the cookie for example, but I've never had a response so can't confirm if this is intentional or an oversight.
Your poor session id
When you login to a website you send your username and password to prove your identity. Login pages and the data they exchange are usually protected with encryption like TLS or SSL. The site will then respond with a cookie that contains a unique session id that is assigned to you. Each time you communicate with the site you send your sessiod id to prove who you are so the server can send the right information to you. The session id is your proof of identity. The problem with RightMove and Zoopla is that once you've logged in using the secure login form, you revert back to using http:// for the rest of the site. You still have to send your session id with every request but now it's being sent without protection. Once an attacker gets hold of your session id they can use it to impersonate you. The attacker is providing a valid session id to the site so the site believes that the attacker is you. At this point they are logged into your account and can do anything that you can do and see anything that you can see, including personal information on your account page. If the entire site was served using https:// then the cookie containing the session id could be marked as 'secure' which means your browser would never send it without the protection of TLS or SSL.
The trusty smartphone app
Like most large brands Zoopla and RightMove both have their own smartphone applications available on a range of platforms. Having been less than impressed with the security measures I'd seen so far on the their websites, I thought I'd dig a little deeper into their mobile applications. One of my major concerns with smartphone apps is that the user has no idea how the app is communicating in the background. There is no way to inspect links or forms to see if they're secure and there's no address bar to look for https:// before you input your username and password. The user has to completely trust the developer and hope that they've taken proper steps to secure their application and your personal data.
To have a look behind the scenes and see how the app performs when it comes to security I decided to launch a Man in The Middle (MiTM) attack against my phone just like a malicious hacker would. If I can retrieve the username and password from the app then things aren't looking good. To launch the attack I used my WiFi Pineapple as a rogue access point and forced my phone to connect using Karma. With the WiFi Pineapple sharing my computers Internet connection all traffic from the access point would pass through my network adapter and Wireshark would be able to sniff packets. All I need to do now is open the app and sign in.
As soon as the packets started filtering through Wireshark, things didn't look good. With no security in sight all the data was being sent and received by the app in plain text. It only took a few seconds of filtering through the data before I found every hackers jackpot.
If you look closely, the selected packet is a HTTP GET request to http://api.rightmove.co.uk containing my email address and password right there in the clear. Protecting user credentials whilst in transit is fundamental to creating a secure website and to send them as GET parameters is incredibly dangerous. Being sent via HTTP they are visible to every single device between my phone and the RightMove servers anyway, but, any of these devices, such as a proxy, could make a log of the request and as such will record my username and password too. Even if the request was sent using HTTPS, your own browser remembers sites that you have visited and it would still most likely end up in a log on the host server. Because the credentials form part of the URL it results in them being much more exposed. Typically POST data of the request is not stored so whilst it's not any more secure from an attacker, sending the credentials as POST data would still be better.
To add to the problem this also opens up the site/app to Cross Site Request Forgery. I could create an image on my site using the following code and log you in to the RightMove website without your knowledge. With some further digging there may be other CSRF vulnerabilities within the site, if you find any let me know in the comments below!
Finally, GET requests are supposed to be idempotent. They are not meant to have any side effects when called and multiple calls to the same request should not result in a different outcome. In this case changing the state of the session when the request is submitted violates that principle. If you're interested to see the response to the request you can just copy and paste the request into your browser and replace my credentials with your own.
http://api.rightmove.co.uk/api/userLogin?email=admin%40scotthelme.co.uk&password=Password1&apiApplication=ANDROID
Conclusion
It seems that good web security practices are hard to come by these days. Despite both RightMove and Zoopla having been made aware of these problems over 4 months ago (if they didn't know already) some of these issues have only recently been addressed. Worryingly, the only thing they have done is on the very public website and the issue has not been updated in the private internals of their application, where the user can't see.
My largest concern here is the risk these shortcomings pose to the security of an end user's account. Whilst you might not be particularly bothered if your RightMove or Zoopla accounts are compromised as a result of the problems outlined above, there are more wide reaching concerns. If someone were to gain access to your email address and password for one of these sites, where else would they allow an attacker to login? Re-using the same password is a common problem with the amount of online accounts the average user has and it can pose some considerable security risks. Could an attacker use them to login to your emails, Facebook or Twitter? If they gain access to your email accounts that's usually the skeleton key to your entire online life. They can reset passwords for many services that depend upon your email and very quickly the damages can escalate much further than a simple online account at RightMove or Zoopla.