lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2d6724810909230915w8b0ed98p8c8b74587c8fb988@mail.gmail.com>
Date: Wed, 23 Sep 2009 12:15:11 -0400
From: T Biehn <tbiehn@...il.com>
To: Anıl Kurmuş <akurmus@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Chargebacks and credit card frauds

Prepaids can be had in the US and Canada sans ID. Fake IDs cheap, easy to get.

DIDs are cheap, usually free.

How many of those nett'd households have VoIP phone service? Hijack
inbounds for re-routing to your own (free) SIP server provider?

Implementing some sort of automated call verification service is expensive, CBA?

Credit cards are insecure, you're playing cat and mouse games until
your checks become too invasive for end consumers. Perhaps you insist
on a verifying payment gateway and flag all other transactions for
manual processing in addition to adding new lists for IP checks.

Glorious,

-Travis

On Wed, Sep 23, 2009 at 11:47 AM, Anıl Kurmuş <akurmus@...il.com> wrote:
> As others have mentioned, you have to assume the machines are
> compromised. This means you should use another channel for
> authorization of each transaction (depending on the use of your
> website,  only authenticating the user through this channel could be
> enough but this is more risky and vulnerable).
>
> I would say the most cost effective one is probably to use SMS/cell
> phones.  You would send an SMS with the transaction details and a
> verification code to be entered on the website for finalizing the
> transaction. If the state/country given by the phone number doesn't
> match the billing address, you throw a red flag as you did before.
>
> So if an adversary wanted to cheat, he would need to enter a cell
> phone from the same region/country. Assuming he can find infested
> machines in the same country, this is not really difficult, still it's
> new and makes it harder. Of course, the main advantage is that in many
> countries, it's not easy nowadays to get a prepaid cell phone without
> giving any IDs for instance, so this might act as a deterrent. A
> better (but more expensive and slower) solution though would be to
> authenticate the cell phone number through postal mail at setup
> time/when changing the cell number.
>
>
> Anıl Kurmuş
> ---------------
> GPG Key :
> http://perso.telecom-paristech.fr/~kurmus/key
>
>
>
> On Tue, Sep 22, 2009 at 06:26, Steven Anders <anderstev@...il.com> wrote:
>> Hi everyone,
>>
>>   I work as an engineer at an online company that sells online subscription
>> service for online tool. We accept orders online using credit cards numbers
>> and we use Authorize.net to process credit card payments.
>>
>> Our standard operating procedure for online orders are: normal checks are
>> check for billing address and IP address ,  - we make sure the billing
>> address is a match and the IP address geo location is good (meaning, it is
>> pretty close to the billing city or state). We use a service called MaxMind
>> and we check to make sure that the IP address geo location is in proximity
>> to the billing address. From our experience, another big red flag is if the
>> IP is from a proxy server, or from web hosting company (could be SSH
>> tunnelling), or outside USA ( Russia, Estonia, China, etc )
>>
>>  If these checks throw a red flag, we will call the person to confirm the
>> order. With this process, we pretty much has very low fraud rate.
>>
>>   Lately, in past couple months, we've been receiving a lot of orders that
>> bypass all these checks without any glitch. The AVS (Address verification
>> service pass) checks for the billing addresses and the IP addresses are good
>> (in proximity to the billing address). The IP addresses are near the billing
>> addresses (for example: billing address is Chicago, IL and the IP address is
>> Evanston, IL - a couple miles from Chicago).
>>
>> Only a few weeks later, we have an influx of chargebacks and phone calls
>> from the original owners of the credit cards, since these people never
>> ordered it - and they are all fraudulent orders.  The only similar patterns
>> in all these orders is that:
>>   1)  they use free email accounts (from Yahoo , Hotmail, etc) .
>>   2) All the IPs are from ISPs such as Sbcglobal, Comcast, Cox
>> Communications, etc .
>>
>>   My big question is: I know there are all kinds of ways people could obtain
>> stolen credit card numbers, and their billing addresses, and so forth.
>>
>>  But. I was wondering:
>>
>> 1. how do they place the orders using all the legit IPs - since all the IPs
>> are from Sbcglobal  , Cox communications,  and all the other major ISPs near
>> the billing addresses.  Could it be that they actually took control of the
>> PCs and then steal the credit card, and then place the order remotely from
>> the controlled PC?
>>
>> 2. Any insights on how these fraudsters obtain the stolen credit card
>> numbers?
>>
>> I am now tasked with improving our backend checks to make sure we don't have
>> any more fraudulent order, and would appreciate any pointer or insights into
>> this matter. Any theories, insights, or information would be very useful.
>>
>> Thank you all for your time in advance.
>> steve
>>
>>
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/



-- 
FD1D E574 6CAB 2FAF 2921  F22E B8B7 9D0D 99FF A73C
http://pgp.mit.edu:11371/pks/lookup?search=tbiehn&op=index&fingerprint=on
http://pastebin.com/f6fd606da

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ