Slashdot Mirror
A Database of Thousands of Credit Cards Was Left Exposed on the Open Internet (zdnet.com)
A US online pet store has exposed the details of more than 110,400 credit cards used to make purchases through its website, researchers have found. From a report on ZDNet: In a stunning show of poor security, the Austin, TX-based company FuturePets.com exposed its entire customer database, including names, postal and email addresses, phone numbers, credit card information, and plain-text passwords. Several customers that we reached out to confirmed some of their information when it was provided by ZDNet, but did not want to be named. The database was exposed because of the company's own insecure server and use of "rsync," a common protocol used for synchronizing copies of files between two different computers, which wasn't protected with a username or password.
Most of us use rsync over SSH with key auth, which means something like RSA-2048 or 4096, or ED25519 (elliptic curve crypto, about the same security as AES-128). It is not even password-based.
So, no, it was not rsync use that left things open. It was just incompetence.
sounds very PCI-compliant. Who was their auditor? Mr Magoo?
Why don't you think the backups aren't corrupt? With this level of incompetence they probably never tested a recovery....
love is just extroverted narcissism
ssh-copy-id wide open to the outside???
I can see some inside account using something like that to sync to an other system but that account should not be open unless they hacked in and got some passwords from an config file. Lot's of software needs DB login info in plain text there.
MacKeeper broke this story late November 2016 - https://mackeeper.com/blog/pos...
I've never heard of rsync mangling data in transit. Are you sure it's not a case of corruption when trying to back up a file while it is being written to? That could happen if you don't create a snapshot of live data, but it's not a problem specific to rsync.
Even storing credit card data at all (instead of processor authorization tokens) is a huge red flag unless they want a mountain worth of additional compliance work.
And then they store it unencrytped....
Aren't there laws that require companies to protect customer data? There certainly should be.
I guess they've never heard of one-way syncing and assume it would change the source data.
Using ssh transport instead of the native rsync protocol, which is unencrypted, is the *right* way to do remote rsync with sensitive data. Much like tunneling http over tls is the right way to do http for sensitive data.
You can also do the rsync network protocol bare, using a rsync:// url. That's the wrong way for sensitive data, and the way this developer chose to do it.
It's happened so many times, lost count. How many times have credit cards been exposed to this kind of peril?
Unlike most protocols, rsync has a built-in checksum, actually many, many checksums, so it's much more reliable than just about any other protocol. It checksums every few kilobytes.
We backup many terabytes every day and we periodically verify the backups with Sha-2 hashes. I've never found corruption due to rsync. On the other hand, rsync *is* very flexible and there are many options. It's certainly possible to use a set of options that doesn't give you what you want.
Also, if you're backing up live systems, especially databases, using any method, you have to take care that the data doesn't change while your backing it up. That applies to any method of backup. For mysql, see man mysqldump, then back up the dumped files.
Well, thank goodness that's gone.
Have gnu, will travel.
It's also an incredibly insecure protocol unless you use a SSH tunnel. Most people don't seem to bother with tunneling rsync via SSH either.
No need for an shh tunnel (e.g. ssh -L:port:target:port)
Just tell rsync to use ssh like this:
RSYNC_RSH='ssh -x -l root '
export RSYNC_RSH
then
rsync -a host:/targetdir .
about mangling the data: you obviously must be doing something wrong. I never had such problems...
Everything I write is lies, read between the lines.
> Aren't there laws that require companies to protect customer data?
Yes, and there are laws requiring everyone to drive under 65 MPH. It seems that making a law doesn't actually mean people will do anything differently.
You're probably getting corruption because your copying files that are simultaneously being modified by other programs.
This isn't a problem with rsync. If that's your criteria, then it follows that cp is notorious for corrupting files. rsync, scp, attic, borg, they'll all give you garbage if you tell them to do this.
If you want to backup a live filesystem, you need to create a snapshot and then backup the snapshot. That's the only way to make sure your backup is crash consistent.
You allow remote root login? Doh.
Set up a nopasswd sudo rule for rsync and add this to your rsync command: `--rsync-path="sudo rsync".` Then connect as a regular user.