time to bleed by Joe Damato

technical ramblings from a wanna-be unix dinosaur

WARNING: American Express fails miserably at basic security.

View Comments


If you enjoy this article, subscribe (via RSS or e-mail) and follow me on twitter.

As of 3:35pm PST on 5/25/2010 it seems to be fixed. wireshark shows only TLS traffic now, nothing in the clear. Pretty quick fix, since this was published at 11:54am. Good deal.

This article is going to reveal a pretty serious error in a web form on the American Express Network website. I would strongly recommend NOT filling out the web form described below.

Daily Wish from the American Express Network

Daily wish from the American Express Network sent me an email this morning trying to get me to sign up for their deal of the day service where they offer a very limited quantity of products for a low price.

Sounds simple enough, right?

Well, the time of the sale is not released until the day the sale occurs, unless you are an American Express cardholder. If you are a card holder, you get a special landing page on their website telling you that if you sign up, you can get the sale times before the sale date.

The white arrow below points to the tab that only appears if you clicked through from an email from American Express. The red arrow below points to the sign up button. Take a look:

Sign up page

After clicking the sign up button (red arrow above), a lightbox appears asking for:

  • First and last name
  • American Express credit card number
  • Security code
  • Expiration date
  • Billing zip

Quite a bit of personal information, much of it sensitive. [sarcarsm]Don’t worry the page is secure[/sarcasm], see the form and the white arrow below:

The code from the form

This form looked very suspicious to me, so I decided to take a look at the code to see if the action for this sign up form was over HTTPS. Check it:

<form name="form1" method="post" action="preid2.aspx?ct=7" onsubmit="javascript:return WebForm_OnSubmit();" id="form1">

So the action is to a handler at http://dailywish.amexnetwork.com/preid2.aspx?ct=7. The lack of https doesn’t make me feel very good.

Maybe the WebForm_OnSubmit() function is doing something that might make this secure? Let’s take a look:

<script type="text/javascript">
//<![CDATA[
function WebForm_OnSubmit() {
if (typeof(ValidatorOnSubmit) == "function" && ValidatorOnSubmit() == false) return false;
return true;
}
//]]>
</script>


So it looks like that function is just a validator. It is really starting to feel like this form is insecure.

Let’s bring out wireshark and see what it has to say.

Wireshark packet sniff

So I filled out the form with fake information and sniffed the POST to the server.

The Daily Wish sign up form from the American Express Network is sending credit card numbers, expiration dates, and all the other personal information on the sign up form in the clear back to their server.

Holy. Fuck.

Conclusion

  • Do NOT fill out the form until American Express fixes this issue.

Thanks for reading and don’t forget to subscribe (via RSS or e-mail) and follow me on twitter.

Written by Joe Damato

May 25th, 2010 at 11:54 am

Posted in security

Tagged with , ,

  • Florin Andrei
    That explains the otherwise unexplainable "event" last year, when we had our AmEx card hijacked during a trip to Eastern Europe. All they needed was one attempt to login to the AmEx site.
  • Wow... that's amazing! What a screw up, somebody is getting fired...
  • skhan
    This is the cost of outsourcing...I could care less what they say!
  • given that AMEX and other credit card companies (usury companies) steal your money as fast as they can, why should they care if other people steal it too? They still make their cut when someone steals your money.
  • Brad
    Can you post the URL from the email? There is no proof anywhere in this that it loads over HTTP.

    From looking at the URL it looks like its built to load inside an IFRAME on the page.
    If the IFRAME is loaded under HTTPS there wouldn't be a problem except for if someone is in your network and forces you to load the HTTP version.
  • wireshark output is proof that the post went back over cleartext.
  • George
    That's not their only problem. Go to that site and use Wireshark to watch what's loaded by that page. The AMEX site loads a bunch of markup & JavaScript from other domains including sharethis.com, googleadservices.com, google-analytics.com, and doubleclick.net.

    They've basically reduced their page security to the lowest common denominator. If any of those sites or DNS entries are compromised the AMEX site is compromised. Doesn't the PCI DSS also say something about reviewing custom code? I wonder if they've reviewed all that code they load from others? It's hard to belive a card brand rolled a site with so many issues.
  • I agree this is a huge issue.

    Say for example someone loads a plugin for doubleclick that captures all the inputs on a page and logs them for tracking purposes. All those form fields are sent plain text to a seperate server, where it could potentially be seen by countless people - both at amex and doubleclick. A bean counter at amex could update the tracking without anyone knowing and grab everyone's credit card info easy as pie!

    EDIT: Looks like they updated the page to load the form in https (same domain) inside an iframe. Fortunately, that means scripts in the parent window can't access the form. Glad they updated, but great to make an example of this for other devs to learn from!
  • George
    The unfortunate thing is that iframe jails do very little to secure anything & the fact that the form now submits via HTTPS means nothing so long as the page loaded via HTTP. How would my mom for instance know it's safe to provide her card information since there's no https: and lock for her to check? Should she fire up Wireshark and do a test transaction? LOL!

    It gets worse. In the "old days" of http based MitM it took a skilled person to do anything more than sniff the connection. Now days there are plenty of freely available packages, including some "point and click" ones that allow attackers to insert their own markup and scripts into a an HTTP delivered page to then deliver whatever they'd like.

    The only way for AMEX to fix this is to turn the entire site to HTTPS & stop loading third-party JavaScript which they have zero control over.
  • Great point, seems like just a temporary "technical" fix rather than a comprehensive solution.

    If I don't see that lock up there and special treatment of the url box, I'm not putting in my CC info. Even then, I'm fairly certain that if they have the page and the iframe on HTTPS, those 3rd party scripts can then access all the data in the iframe. Ironic that adding HTTPS to the parent page reduces security!
  • The account management interface makes me rage every time as well. If I recall correctly, I believe the client side validation differs from the server side one. And if I change my password, the rules and validation is different from entering it for the first time!

    Awful.
  • Grrr
    Crappy Indian coding done by a company run by an Indian, outsourcing jobs everyday!
  • Mike
    Speaking of basic security problems, I wandered over to homerun.com as you suggested. I tried to sign up, but entered something incorrectly and was returned to the sign-up form. To my surprise, my password was pre-filled for me - embedded in the HTML source of the page. Also, sent over HTTP.

    It's not a credit card number, it's a basic throwaway web password, but still. Basic Security.
  • Word. repeat password was pre-filled. that is a bug. fixing it now, thanks.

    it's sent over http but encrypted on the client before being sent.
  • Remington Winters
    Encrypted on the client? That sounds suspiciously like javascript. Client-side security is not security.
  • WOW!!! Credit card number is sent via plain socket! Evil guy "only" needs to stand between you and American Express server to know your card number and your name.

    It's far easier to get that info when you pay for something in the supermarket or in the bar.

    Yes, they suck at security. Yes, page lies saying that form is secure. But that's not an issue. Someone must be really paranoid to be concerned about that (and it seems you are). And if one is so paranoid, then he, probably, should take tons of active precautions about sending any of his data over internet anyway. So you're picking on a really little thing.
  • Yes, by all means, let's forget about people who are not browsing from home. I mean, come on, who browses from an Internet café these days or from their office or a place like that? And even if they did, I'm pretty sure all of the places they browse from are trustworthy and have good security, so nobody can sniff on your data.

    Oh, and I guess that there's no way someone is going to duplicate that form and try to use it for phishing. And if they did, the usefulness of the SSL certificate for preventing phishing is exaggerated, right?

    Wake up, Sergey. There's a reason why HTTPS is important.
  • Brad
    I hope all your personal information gets stolen when you go to your credit card and bank websites from a public location. I also hope you go shopping online too without using saved credit card information and companies that don't use email verification for when shipping address is different than billing.

    Btw, I agree SSL is important. The PCI certification I got pass at my company is at level 3 or 1.. whatever the highest level is. The HTTPS should definitely have been enforced on the submitting page... not the calling page.
  • You're all heart, Brad. Let's see, your contribution was to flame me and then add nothing useful to what I said.

    I'm not going to discuss my personal shopping and banking habits with you, or the security precautions I might take under either normal or exceptional circumstances. I will, however, point out why your reply was a completely useless flame: if a public location is not safe due to factors that have to do with the customer or the location itself, it's not an excuse for a bank or a merchant to fail at their end of the security. That's what we were all criticizing here, in case you forgot.
  • Troll? I'm just saying, using SSL is pretty easy. Why not use SSL and not worry about it?
  • Sure, SSL is easy and why not. Probably, it's just much less important for me than for you. My intent was rather sarcastic, not trolling actually.
  • I wish I could say that this surprises me, but given their god-awful website and their shoddy password restrictions, I am not surprised in the least.
  • Jeff
    Given proper handling of authentication (e.g. timeouts, banning suspect IPs), complex passwords aren't necessary.
  • As if the lack of special characters in passwords on their min site wasn't bad enough...
  • wagerlabs
  • Dhruv
    No.
blog comments powered by Disqus