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!