eWAY: Security concern response done right

I'm absolutely blown away by how eWAY responded to my last post concerning some security issues and concerns I had with their site.  They've radically exceeded my wildest hopes for resolution of the issues, and set themselves far apart from other companies who have been in similar circumstances before.

The post with the issues initially went live Wednesday morning.

By Wednesday evening, within 12 hours of the post going live, I had received a phone call from their CEO letting me know they were on top of the issues and actively addressing them with quite a few developers.

By Thursday evening, under 36 hours after the post went live, they let me know they had resolved the "plaintext password reset email" issue with a much more secure password reset system that did not expose the developer passwords.

In under a week, they have also updated their "About the developers" page to add information about the people responsible for security (this information had been missing on the page previously), updated their fraud detection systems, and are actively pushing people away from the older, 8 digit based interface.

On top of this, they sent me a thank you package!

This is such a radical contrast to other companies who respond to security issues by, in no particular order, ignoring them, having a PR drone say something meaningless, or fixing one issue and ignoring others (and then denying that there are exploits on sale and being used for the just-patched version).

And it's absolutely awesome to see rapid response to security concerns in action.  I wish more companies responded like eWAY did.

eWAY Plaintext Passwords & Transaction Security

Updates from 4 days after this post went live, from eWAY

Dear Bit Weasil

We would just like to respond to the concerns raised in your blog post on 16 January. We appreciate the updates to your post since your discussion with our CEO on 17 January. 

eWAY takes our security extremely seriously and we invest heavily in this. We are externally audited every 12 months to ensure our security is of the highest standards.

We do appreciate feedback on how we can improve on this further and are happy to engage with those in the industry, such as you, to further enhance our security.

The concerns you have identified were known to eWAY and have or were in the process of being resolved.

Plaintext Passwords:
This issue is now resolved and related to the developer section only. This area is a resource section for developers (i.e source code and documentation). While we are confident that this does not occur for any merchant related information, we are undertaking a further audit of this to be certain.

The process involves an email with a one time URL and a unique code, requiring the user to go to the URL and enter the generated unique code. A further email is sent on the successful completion of the password reset to further verify the email address. 

Fraud Detection and Prevention
There are numerous internal systems in place to detect and prevent fraud of the nature you outline. eWAY advises that merchants should avoid processing payments directly, without a customer registration/check out process. The use of a shopping cart and the provision of a check out process can assist to minimise fraudulent activity.

eWAY has also partnered with ReD to provide Beagle Alerts which is an enterprise-level alerting system which utilises ReD’s world-leading fraud prevention engine to provide superior protection. http://www.redworldwide.com/newsroom/press-releases/eway-selects-red-to-protect-merchants-against-online-fraud

CSO Position
As you have updated – we do have a CSO and the information regarding this position is available here - http://www.eway.com.au/developers/about/meet-the-nerds

Again, eWAY is committed to and take extremely seriously the security of the information we handle and are constantly working to ensure this data is secure.

Thanks for your feedback!
The eWAY team

Updates from under 12h after this post went live

The CEO of eWAY has contacted me (under 12h after this post went live - very impressive response time), and assured me that they are rapidly addressing the issues addressed.  I've updated this post with a few more details, but from the conversation we had, they take security very seriously, and are resolving the identified problems as quickly as they can.  They were already addressing certain issues (the IP logging), are working to get people off of the old 8 digit ID system, and are actively resolving other issues (the plaintext password email).  I'm quite satisfied with their responsiveness to this (especially compared to other companies in similar situations recently who denied it for ages), and am convinced that they do take security seriously.  Please feel free to use them.  I'm leaving the content of the post for historical purposes, and will also update it with their response when they provide one.

Have you heard of eWAY?  If you don't live in one of three countries, probably not.  You have now!

According to Wikipedia,

eWAY is an online payment gateway used by 12,000+ businesses to process credit card payments. It is supported by more than 200 shopping cart platforms and 22 banks in the United Kingdom, Australia and New Zealand.

According to their own PCI DSS compliance page,

More eCommerce merchants trust eWAY with their credit card payments. With more shopping carts, level 1 PCI DSS compliance and tools to make money online, eWAY is Australia's favourite payment gateway.

And, you can even see their PCI compliance certificate.

Who uses eWAY?  In addition to what Wikipedia says (12,000+ businesses) and what eWAY themselves say ("The credit card payment gateway for 11,000+ merchants"), FinExtra says of eWAY (emphasis mine),

However, the firm is deadly serious in its intention to become the world's leading processor of online payments, and already counts major brands such as Puma, Krispy Kreme and Canon amongst its clients - not to mention almost all of Australia's major banking groups. 

Plaintext Passwords: Resolution in progress

UPDATE: They have multiple developers fixing the issue currently, are aware of the problems of plaintext passwords, and this should be resolved.  It also seems that this was only an issue in the developer corner, as opposed to the whole site.  Resolution in progress.

Sounds like a solid, secure outfit, right?  Certainly not the type of place that, when I requested a password reset for my developer account, would send me a plaintext password.  I can't imagine receiving anything like this from a PCI Level 1 certified company!

Unfortunately, I did.

Yes, that's right.  In 2013, they sent me a plaintext password for my eWAY Partner Account.  I don't know what they do for their merchant accounts, as I don't have one to test with (since I don't live in their served countries), but this is unacceptable.

If that's not enough to concern people, I'd like to bring up a few other issues which I have run into, in the course of an investigation into several hundred fraudulent transactions someone was dealing with.

API Access IP Logs (24h ought to be enough for anyone!): Resolved

UPDATE: This was related to a CDN transition recently, and they have resolved the issue, logging the proper remote system IP addresses for API access.  Resolved.

Most payment gateways have some form of API access in which you submit requests to the gateway for processing.  It's good to know where these requests are coming from, and one would typically expect that the IP address of systems making API requests would be logged as part of the request.  Apparently, this is not particularly important to eWAY.

When asking for a list of IPs (or simply verification of the subnets) making API requests to determine if one of our servers was making API requests or if a third party had obtained the access credential to perform requests on the customer's behalf, I was told by an eWAY representative, 

Our system captures the IP address of our edge servers ... We are only able to trace the original IP source for transactions that has occurred within the last 24 hours so for the possible fraudulent transactions processed via your account ... we would not be able to trace the source IP.

In other words, a few days after a fraudulent transaction, I don't know if it came from one of the systems expected to be making the transaction, or something else.  This would be less of an issue if the credentials were at all robust and could be revoked easily, but...

Customer Credential: 8 digit number: Known issue

UPDATE: eWAY is aware of this issue, and this is one of their motivations to drive people to their "Rapid 3.0" interface as soon as possible.  The Rapid 3.0 system involves a much stronger authentication token, and looks quite solid.

Unlike PayPal and Authorize.Net which have multiple high entropy API keys required to run a transaction, and which can be revoked and reset if a site compromise is suspected, eWAY has one credential: The 8 digit customer ID number.  That's it.  If you have (or can guess) a customer ID number, you can perform transactions as the customer.  If your goal as an attacker is to verify stolen credit card numbers, then a bunch of $0.01 transactions against someone else's credentials are just the ticket.  I don't know if eWAY does any dynamic IP blocking if someone is searching customer ID space or not, but with 12,000+ merchants (according to Wikipedia) in a space of 90,000,000 possible 8 digit customer IDs, at just one query per second, an attacker is likely to find a valid customer ID in slightly over 2 hours!

Unlike other ecommerce gateways, if your API credentials (Customer ID) are compromised, you have to create a brand new account with a previously unused email address.

Fraud Detection and Prevention: Improving

UPDATE: They are aware of this, and are working to improve their fraud detection systems to detect more cases of fraudulent usage and block it.

Finally, the reason I discovered all this is because I was working on dealing with an issue with several hundred fraudulent transactions, all for $0.01, all from the "same" customer name and street address.  This should ring alarm bells in any transaction processing system, but eWAY seems to only have alarms hooked up to their Beagle system.  To opt into Beagle, you simply pick the Beagle endpoint, and set up the rules you wish to enforce.  However, as far as I can tell, using Beagle doesn't prevent the use of your 8 digit customer ID against a non-Beagle endpoint, which, apparently, applies no anti-fraud rules at all, and lets someone rip through hundreds of stolen credit cards in a hurry.  Of course, this means that the customer gets charged the base transaction fee of $0.30 for each $0.01 transaction (which will likely be reversed if noticed).  Their systems don't seem to find this at all odd if it comes in on the non-Beagle gateway, which means it's perfect for an attacker to use with a brute forced customer ID.

Final Thoughts

It's 2013.  The internet is not a friendly place.  Security matters.

UPDATE: They do have a CSO position, though it's not labeled as such on the website.  They are in the process of updating the website to make this more clear.

eWAY doesn't even list a CSO position (or any position mentioning security at all) on their staff page.  They send plaintext passwords, at least to their developers.  They use a trivially brute forceable number as the only visible transaction security.  And they don't seem to notice clearly fraudulent transactions coming through their front door.

Something needs to change.

UPDATE: And it sounds like something has.  I'm quite impressed with their response.

nvcc, OS X, clang, and dumpspecs

If you are building with nvcc on OS X and get errors along the lines of "clang error: unsupported option '-dumpspecs'" - welcome to the new build world.

The best fix I've found so far is to replace the /usr/bin/cc and /usr/bin/c++ symlinks (which currently go to clang) with symlinks to llvm-gcc.

sudo rm /usr/bin/cc
sudo rm /usr/bin/c++
sudo ln /usr/bin/llvm-gcc /usr/bin/cc
sudo ln /usr/bin/llvm-g++ /usr/bin/c++

Try that out and see if it works!  Please let me know if you find a better solution as well.

Defcon 2012 Cryptohaze Cloud Cracking video

You can find it here: http://www.youtube.com/watch?v=UHk2lMF7-H4

Enjoy!

Cryptohaze now supports Lotus hashes!

New algorithm support (and what I believe is the fastest implementation out there at this point in time): Lotus Domino hashes.  Unsalted only, for now.

Performance, in a system with an AMD 6990 (43M/s total) and 2 overclocked 7970s (50M/s each):

And, for the nVidia side of the house, a comparison between a stock clocked 7970 (46M/s) and a stock GTX470 (31M/s):

I don't have a binary release yet, but it's all checked into SVN over at Sourceforge!

Cryptohaze MD5 and NTLM length 8 tables available for download!

After some work, a private tracker, and realizing that torrent clients have an upper size limit that is insanely small, I've got the MD5 and NTLM length 8 rainbow tables up as torrents.

https://cryptohaze.com/gpurainbowtables.php

Download & enjoy!

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."