Retro vulnerability of the day: cleartext passwords over the wire

While spending my Sunday looking at what people are doing with various cloud platform services I came across these 4 case studies on the Google App Engine (GAE) pricing page:

Ignoring WebFilings (who have an Amazon EC2 backend) and gigya (who have their own platform and only use GAE for their live chat applet), Best Buy caught my eye as I already caught them sending employee credentials in the clear with the Twelpforce GAE app written by Enomaly a few years ago and Giftag was also done in "partnership" with Best Buy (whatever that means): "Enomaly Launches Giftag.com for Best Buy".

I also stumbled on a cross-site request forgery vulnerability in Enomaly's own flagship SpotCloud product earlier this year, which I wrote up last week — some 6 months after the initial report: SploitCloud: exploiting cloud brokers for fun and profit.

Sure enough when you crack out Wireshark and sniff the wire you can clearly see they're sending credentials in the clear over the public Internet, both at signup:

...and for good measure, on every login:

This wouldn't be such a problem were it not for rampant password reuse — I would not be at all surprised if most of the email/password combinations captured also worked on the email account itself. That is, by sniffing Giftag signups/logins you also have a good chance of a type of privilege escalation to the email account and from there to other services like Facebook:

To their credit(!?!), the other GAE case study application (Apmasphere, a property management application by Ray White, Australia's largest real estate group) exhibits exactly the same vulnerability, both at signup:

...and at login:

The moral of the story is that it doesn't matter how trivial your app is, given enough rope users will hang themselves by re-using passwords. As developers you owe it to your employers, clients and users to protect them from themselves, in this case by requiring SSL using Google App Engine's "secure: always" configuration directive which was introduced over 3 years ago. Very soon you'll also be able to use your own domains with SSL (rather than *.appspot.com) which, due to limitations in the protocol, is technically challenging to implement for a multi-tenant service at scale.

Update: While Best Buy's Giftag IP address is owned by Google (according to whois) and runs on the Google platform (according to the Server: Google Frontend HTTP header), the IP address for Ray White's Apmasphere is owned by Primus Telecommunications (according to whois) and runs an Apache web server (according to the Server: Apache HTTP header). Does anyone know whether one of the four main GAE case studies has indeed migrated to an in-house platform and if so, when and why? More to the point, is anyone aware of anyone doing anything of any consequence on GAE? I'm still looking for decent case studies of GAE native applications.

Update: Enomaly founder, Reuven Cohen disavows the vulnerability, claiming "Interestingly, the GAE version the giftag site wasn't developed by enomaly." SFAICT the "GAE version" is the only version so in my opinion they're responsible or they're plagiarists — taking someone else's work or ideas and passing them off as one's own. I'll let you decide for yourselves:

And 6 months later:

Update: The Giftag extension for Firefox is also vulnerable:

Update: Even the bookmarklet is vulnerable... if you add this to your toolbar and click on it then it will insecurely retrieve Javascript (gift-bookmarklet-loader.js) and execute it, even within an SSL session. That is, an attacker can trivially execute trusted code that has full access to secure pages:

javascript: (function () {
    var d = document;
    var s = d.createElement('script');
    s.id = "gt_boot";
    s.setAttribute('src', 'http://www.giftag.com:80/media/js/gift-bookmarklet-loader.js');
    d.getElementsByTagName('head')[0].appendChild(s);
})();