Sunday, August 5, 2012

An interesting identity verification threat, observed

A threat model I have occasionally considered for things in the past is the use of a system for identity verification.  This could be verifying full stolen identities, or in the perhaps more common case, verifying stolen credit card numbers.

However, I've never actually seen this "in the wild" until recently.  A few weeks ago, I did some log analysis for a site that was suffering a high number of invalid donations in a short period of time (after they'd blocked the offending IPs and renamed the donation form).

It was good fun - I actually was able to observe the behavior of "analyze site, write script, run script from a compromised client, get confused when 404s show up, give up."




The script also stood out in the logs - it had no referrer set.

The flow happened as followed (IPs and other information sanitized to protect the identity of the site and likely compromised systems):

Around 12:16:44, the attacker found the site.  The Google string used to redirect them (based on the referrer) was "donate now [country]" - the attacker was specifically looking for donate now pages in a certain country (presumably to test stolen CCs from that country).

The attacker nosed around the site briefly, showing normal user behavior and referrer strings (and a user agent of "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.91 Safari/534.30" for anyone keeping track.

At 12:19:46 the attacker makes the first POST to the donation form (with what appears to be the normal browser).

At 12:26:29, 12:27:43, and 12:31:03, the attacker makes 3 more donation POSTs, presumably capturing traffic to ensure they understand everything.

The attacker then appears to work for a few minutes on something.

At 12:38:52, a POST arrives from the same IP, but with different characteristics.  There is no referrer string, and the user agent is now "Mozilla/6.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3"

This script makes 3 more POSTs at 12:39:00, 12:39:37, and 12:39:45 before going silent from this IP.

However... the attacker is not done - they've just moved the script to another host.

Starting at 12:41:27, there are a series of 110 POSTs from a different IP (halfway across the globe).

Well, if you're going to perform attacks on a site, doing them when the site administrator is up probably isn't wise.  So, the page gets renamed.

At 13:09:02, the script starts getting 404s.  It appears to retry once, then go silent.

At 13:11:36, the script makes one more request, much longer since the last POST than it's normal interval of 5-10 seconds.  Attacker testing manually?

And now, we go back to the original attacker IP.

At 13:12:00, the attacker goes back to the site via it's main URL, and begins nosing around, trying to figure out what happened.

The attacker pokes around again, figures out that the donation processing page has disappeared, and at 13:12:42 gives up and leaves the site alone.

Just under an hour of fun, end to end.

Roughly 110 credit cards either confirmed as valid or determined to be invalid.

A non-profit charged roughly $30 in transaction fees for no gain (as any successful ones will likely be challenged and reversed).

What can be done against this?

Defenses against this type of attack include (in no particular order):
- Passing the IP address of the requesting client to the payment processor.  They have better anti-fruad, and will usually pick up on trouble IPs quickly.
- Requiring a minimum $5 or $10 donation.  The attacker was running transactions for random amounts between $0.01 and $1.00 - the higher price means it's more risky for the attacker, as a $10 donation is more likely to get the attention of someone than a $0.01 charge.
- Limit the number of donation requests per IP.  If someone is trying more than 4-5 times, they are probably up to no good.
- This is more the payment processor, but check that the client IP is "sane" for the address used.  If someone is submitting an address in Greece, from an IP in Canada, something is probably fishy if it is not a known VPN provider range (and even if it is, this is very unusual).

It was enjoyable to track down the actual behavior of an attack I had not seen before.

Hopefully this helps some people build good defenses!

2 comments:

  1. Just happened to me as well. I thought robust cross-site request forgery protection would help protect against script-submitted CC validation attempts, but it didn't. Apparently they scripted the submission to the actual form.

    I blocked the IP and also clarified with my payment processor how to require more stringent address checking. Apparently a verified address is just a real address, not necessarily the actual billing address, I had to add the check against the actual billing address as a second requirement.

    ReplyDelete
    Replies
    1. What I saw indicated POSTs to the actual form, so I don't think XSS protections would help at all. They simply observe the fields flying to the form, and make POSTs. I assume it's using a browser debugger type environment that is pre-SSL encrypted (or they just use a SSL proxy, but... most browsers will tell you what they sent if you ask).

      Delete