Opened 9 years ago

Closed 7 years ago

#2624 closed Bug/Something is broken (fixed)

SSL Security Breach - Credit Card

Reported by: Joseph Thomas Owned by: Joseph Thomas
Priority: Urgent Component: Tech
Keywords: Cc:
Sensitive: no

Description

We have a serious breach in security with drupal/CiviCRM. Basically, someone hacked in somehow and found our transaction key, and started testing credit cards in rapid fire. Live Transactions.

This is what I am assuming happened. I had already set up an SSL certificate, and had configured Civi as per:

http://glast.pi.infn.it/mech/Joomla/Componenti/civicrm/CRMDOC/CiviContribute%20Payment%20Processor%20Configuration.html

I changed the transaction key, so we might be alright for a minute, but need to understand better what happened, and how to go about better securing the site. It seems like who ever it was went through our site to do this, as the purchaser was an actual entry in our database.

Thanks!

Attachments (1)

auth_net_altroots.ods (17.9 KB) - added by Joseph Thomas 9 years ago.
The information from the transaction on the Authorize . net site

Download all attachments as: .zip

Change History (11)

comment:1 Changed 9 years ago by Joseph Thomas

hehe. Security bReach

comment:2 Changed 9 years ago by Joseph Thomas

Summary: SSL Security Beach - Credit CardSSL Security Breach - Credit Card

changing...

comment:3 Changed 9 years ago by Joseph Thomas

Here is the conversation between myself and someone at authorize.net:

Welcome to the Authorize.net chat forum. For your security, account updates can’t be processed through chat. Please don’t send any bank, credit card, or SSN information. For further help, please visit our Knowledge Base: http://www.authorize.net/help You have been connected to Emily F. Emily F: Hello Ana! How can I help you today? Ana Willem: we were just speaking to someone and got logged off... Emily F: Sorry. Ana Willem: we are being hacked into Ana Willem: there are a number of transactions from November 6th to November 7th Ana Willem: that were generated using one of our database contects Emily F: Have you got a new transaction key and put it in your setup? Ana Willem: and i am trying to determine where the issue happened Ana Willem: is it a security issue on your end? Emily F: So they are just submitting them from your side? Ana Willem: iwhy would we need to generate a new transaction key? Ana Willem: i do not know what is happening Emily F: I hadn't seen your whole message when I said that. Ana Willem: that is what i am trying to determine Ana Willem: they are all declined Ana Willem: and use fake credit card numbers Ana Willem: so the effect is just that we are getting charged on your end for transaction fees Emily F: A new transaction key would be good if they had figured out your current key and was using it to link to your gateway. Ana Willem: which we would like to get back Ana Willem: how would they have found this out? Ana Willem: is it not secure? Emily F: It is secure with us. It depends on where you have it on your side whether it is secure or not. Ana Willem: we have it in a https Ana Willem: but do not have a security certificate Emily F: I can see that the transactions were all submitted to us via an API so it is something that is on your side. Emily F: There are a lot of people who use random sites to test card numbers for validity. Ana Willem: i am changing the key now Ana Willem: can you credit us for those transactions? Emily F: I am not able to. You can block the IP address that the transactions are coming from and you can set the Transaction IP Velocity filter to only allow 1 or 2 transactions per IP address within an hour. These both require you to have the fraud detection suite. Ana Willem: okay. so we are going to have to pay for those transactions? Ana Willem: that seems unfriendly Emily F: I am sorry.

comment:4 in reply to:  3 Changed 9 years ago by Jamie McClelland

Hi Ana,

I would suggest that you turn off or disable payment processing until we figure out what happened. I don't think we know if this is an SSL breach or a breach of another kind yet.

In your post, state that test transactions were made using your authorize.net transaction key (which were denied).

I think you know this based on the authorize.net log - is that correct? If so, can you copy and paste from the log in which you learned this? That way we can get additional information that the log might provide, such as the IP address the transactions came from and the exact date/time.

If this information says that the transactions came from our IP address, we can cross reference with your site's apache logs to determine the IP address of the web browser that made those transactions. This would suggest that your authorize.net transaction key was not compromised, but instead your civicrm installation might be compromised.

On the other hand, if authorize.net reports the transactions coming from a different IP address not under our control, it might suggest that the authorize.net transaction key was compromised.

I may not be able to get back to you before tomorrow - but if you could post this info now I will look more closely tomorrow. In the meantime I would suggest disabling all transactions.

jamie

Changed 9 years ago by Joseph Thomas

Attachment: auth_net_altroots.ods added

The information from the transaction on the Authorize . net site

comment:5 Changed 9 years ago by Joseph Thomas

Robert B: Please hold while I review your account information. Thank you.

Robert B: The IP address is 125.163.243.116

Robert B: They were submitted in ID, Indonesia

Here is the buffer. These transactions also show up in the CiviCRM change log for the person whose record this is under, but not as an activity or anything else...

I attached the spreadsheet for the transactions themselves. Thanks!

comment:6 Changed 9 years ago by Joseph Thomas

My main question is if the key was compromised on the CiviCRM side? How does this happen? I am going to make out a ticket with CiviCRM and need to know what to ask/say to avoid going back and forth too much...

comment:7 Changed 9 years ago by Joseph Thomas

any ideas about this yet?

comment:8 Changed 9 years ago by Jamie McClelland

Hi Ana,

I'm trying to fully wrap my head around what exactly happened (and I'm still a little unclear).

It seems as though, on November 5 and November 6, someone operating from the Indonesian IP address 125.163.243.116, made over 140 credit card charge attempts.

The $5,000 charges were being made from multiple credit cards (all using the name Tracy Tucker) to Alt Roots, via the Alt Roots authorize.net transaction key being used by the Alt Roots CiviCRM installation.

All attempts were declined by authorize.net, presumably because they were invalid credit card numbers.

Judging from what we know (and matching the requested pages from this IP address in the Apache web logs) I think that someone from the Indonesian IP address went to this page:

https://alternateroots.org/civicrm/contribute/transact?reset=1&id=1

And began attempting to make donations under the name Tracy Tucker. They seem to have had a collection of bad credit card numbers, so each one was rejected by authorize.net.

Perhaps they were trying to find a safe way to test a collection of stolen credit card numbers to see if any of them were valid? I'm not quite sure why else they would do that.

However - unless I'm missing a crucial piece - I'm not sure what if anything has been compromised. I also don't see any indication (with this information so far) that the Alt Roots transaction key was compromised.

I would certainly suggest that Tracy Tucker be warned of this activity - it could indicate some kind of identity theft in progress.

Let me know if I'm missing something or if there's is any other critical info about what happened.

jamie

comment:9 Changed 9 years ago by Joseph Thomas

Owner: changed from Jamie McClelland to Joseph Thomas
Status: newassigned

I think the crucial thing is wondering if that donation was made on our website from our donation page, or if it was automated, and how we would tell. My impression is that the transactions happened pretty close together...which is why i am wondering, but if it was automated, it might have been a lot closer together - like a denial of service or something.

I hadn't considered someone just testing the tool manually on our donation page... :) And how wonderful it would have been if the donations (at least some of them) went through...I'm trying to understand who Tracy Tucker is, and have contacted her on facebook, in case this is a passport stealing issue or something.

At any rate, I think the moral of the story is to purchase theft protection from your gateway? Is there a more creative way to limit the amount of purchases made from a given IP address in Civi or drupal? I'm going to start researching that.

Thanks, Jamie. If you have any other ideas, let me know!

comment:10 Changed 7 years ago by Daniel Kahn Gillmor

Resolution: fixed
Status: assignedclosed

chiming in much later as i do an old-open-ticket triage:

jamie's assessment sounds right to me. the submissions in the transaction log are spaced out about two per minute, with some occasional gaps of several minutes between events. This sounds to me like someone with a list of possible credit card numbers (or a discarded receipt that XXXX'ed out all but the last K numbers) is sitting at their computer and plugging them into the altroots donation page as a way to establish which one is correct. So they were probably trying to use the altroots website as a credit card oracle to determine the correct info (and if they'd found it, i suspect they would have immediately stopped and gone off to try the same number someplace they could profit from it directly).

I'm not sure what liability the organization/merchant accepting these credit card donations would have; as long as you're willing to return any funds that were improperly transferred due to fraud, it doesn't seem to me like there's anything to do differently. But i haven't researched the legal aspects and i'm not an accountant or financial lawyer or whatever, so i don't know.

Anyway, i think this is resolved now, though i'd be curious to hear about any followup if you learned anything else.

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.