December 2008

You are currently browsing the monthly archive for December 2008.

My Latest Experience With Credit Card Fraud

creditcard

Well, it has happened again.  One of my credit cards has been used to make unauthorized purchases.  I was contacted about a month ago by my issuing bank to inform me of suspicious purchases at a grocery store and restaurant in Arizona.  I presumed (incorrectly) that because I live in North Carolina and did not make any airline ticket purchases or show a pattern of purchases that would lead them to believe that I was in Arizona, the card issuing bank became suspicious and contacted me.  Once I informed them that I did not make the purchases and that the card was still in my possession, they immediately canceled the account and issued me a new card.  I was impressed with their monitoring system that was able to detect this fraud so quickly.  I discovered later that the bank was not as proactive as I had assumed.

This is not the first time this has happened to me.  A couple of years ago this same card was used to make fraudulent purchases on a web site.  In that case, I notified the bank of the fraudulent transaction after seeing it on my statement.  I never did figure out how my card information was obtained during that incident, but something interesting happened recently that I believe explains how the criminals got a hold of my card data this time.  It also explains how the bank noticed the unauthorized charges so quickly.

A few days ago I received a letter in the mail from a major hotel chain stating that they had suffered a breach and that my credit card information had been stolen. I only stayed at this particular hotel once about two and half years ago and I used this credit card to pay for the room.  According to the letter, a “sophicated hacker” had gained access to the computer systems of one of their franchises and was able to access “customer transaction files at a number of other hotels” to obtain credit and debit card data.  Aha.  Given the timing of the incidents it seems probable that the fraudulent transactions were a result of this breach.

To the hotel’s credit, they did at least have some detective controls in place that discovered the breach and appropriately alerted both the payment card companies as well as affected customers.  This is how my issuing bank detected the fraudulent charges so quickly.  They had a heads up.  However, the hotel was clearly not in compliance with the PCI DSS.  Credit card data is supposed to be encrypted when stored, which would have prevented the hacker from being able to read this sensitive information.  And if it was encrypted, then they did not properly manage the encryption keys, which again, is a violation of the PCI DSS.

One of the most important things for any company that stores sensitive information, such as credit card data, to do is implement controls to delete such data after a certain period of time.  There is no reason to store credit card data for two and half years, especially if there is not a recuring transaction.  By limiting the amount of sensitive data that is stored to the absolute minimum necessary for business purposes, a business can reduce its risk and mitigate the resulting damage in the event of a security breach.  No doubt this hotel chain is spending much more on cleaning up after this incident than it would have had it followed this advice.

Mitigating SSH Brute Force Attacks


If you manage a system connected to the Internet that allows inbound SSH traffic, and you check your system logs periodically, no doubt you have noticed the failed login attempts from rogue systems trying to brute force your machine. These brute force attempts are typically generated by systems that have been compromised themselves (bots) and are attempting to infect more systems to add to the botnet. They generally are not very tactful, generating lots of logs and setting off any IDS that may be monitoring the network. Below is an example of the logs generated by such brute force attempts on a RHL compatible system:

Dec 8 13:28:51 websrv1 sshd[14407]: Failed password for invalid user test from
port 55732 ssh2
Dec 8 13:28:54 websrv1 sshd[14409]: Failed password for invalid user anda from
port 56250 ssh2
Dec 8 13:28:58 websrv1 sshd[14411]: Failed password for invalid user jb from 20
1.47.187.138 port 56723 ssh2
Dec 8 13:29:02 websrv1 sshd[14413]: Failed password for invalid user cvsuser fr
om port 57255 ssh2
Dec 8 13:29:05 websrv1 sshd[14415]: Failed password for invalid user cvsuser1 f
rom port 57761 ssh2
Dec 8 13:29:09 websrv1 sshd[14417]: Failed password for invalid user mana from
port 58263 ssh2
Dec 8 13:29:13 websrv1 sshd[14420]: Failed password for invalid user mysql from
port 58810 ssh2
Dec 8 13:29:17 websrv1 sshd[14422]: Failed password for invalid user mysql from
port 59342 ssh2

Here you can see that the host tried to login as the user mysql, mana, cvsuser1, cvsuser, jb, anda, and test all in the space of about 26 seconds. And this was just one snippet of logs from Dec 8. This happens everyday, many times per day, and from many different attacking systems. Large networks frequently have intrusion detection/prevention systems to help block these types of attacks. But what should administrators of small networks, with few resources do to combat these brute force attempts?

First, you have to check your logs. Manual scanning of logs is fine, but there are tools that can make this task much easier. One example of such a tool is which comes as part of many Linux distributions. It will analyze your logs and send you reports of system activity which will help you spot these types of events. Second, keep the number of accounts that are allowed to login to the system via SSH to a minimum. Always use the “AllowUsers” option to specify which accounts are allowed access remotely and absolutely, do not allow root to login via SSH. This is the first account bruters attempt to crack when trying to exploit your system. Finally, take advantage of iptables to block access to those systems that are attempting to access your system illegally. You can either do this manually or write a script to block them automatically based on log entries. There are also a number of available on the Internet that provide a good starting point of hosts/networks to block even if they have not tried to brute force your machine (yet).

attempt to be more subtle in the hopes that the attackers will not be noticed by IDPS systems. However, they are still easy to spot with human analysis and the techniques mentioned above. Stay alert and keep your systems secure. We are all in this together.

Copyright © 2011 InfoSecStuff.com — All Rights Reserved