the latest on credit card frauds

Recently I worked with Acme (the name has been changed to protect their identify), a retail company that had been contacted by their bank. (Let’s call the company Acme.) During an investigation of some credit card frauds, the bank discovered that many of the fraudulent transactions appeared to have one location in common, Acme.

The analysis works like this. Let’s assume that Joe Smith and Mary Jones used their credit cards at Acme on March 1st. Then, on March 20th, both Joe’s and Mary’s credit cards were involved in fraudulent transactions. Once a credit card is involved in a fraudulent transaction, the banks look to see if this transaction is part of a larger fraud. So, they check the historical transactions of Joe and Mary, looking for the business that they both have in common. The theory is simple, if Joe and Mary visited a company with a security breach, it will be seen in the historical analysis.

This type of fraud analysis is useful for detecting when many credit cards are compromised at a business. If the bank can identify the location where credit card numbers were compromised, it can prevent future fraud from that compromise. In order to do that, the bank will need to cancel all credit cards that were used at the business where the compromised occurred and re-issue new ones.

Back to Acme. So, based upon fraud analysis, the bank had strong reason to believe that somehow Acme was leaking credit card numbers. In fact, the bank suspected that over 70 fraudulent transactions resulted from a problem with Acme. Our review of Acme showed that their network was Payment Card Industry (PCI) compliant. The credit card numbers were protected in Acme’s network. So, the card numbers were not leaking out because a network hacker.

This left only two options. The first is that an employee or employees were stealing the credit card numbers through the use of a skimmer, or that Acme’s card processor was hacked. Based upon the fact that only certain transactions at Acme were reported as compromised, this meant that the skimmer possibility was much more likely.

While there has been a lot of work on securing credit card data over the network, the physical credit card is still vulnerable to the skimming attack.

In order to protect yourself, do not let you credit card out of your sight when you use it. Because when it is out of your sight, it is possible that the person that took your credit card also took a copy of your credit card.




Top 10 usernames hackers try

The basics: we use usernames to identity a person to a computer system. A password is commonly required in order to ensure that only the proper person is using the username. Hackers know that at least some passwords for most systems are usually weak or easily guessed, and they will often attempt to access computers using password guessing programs. These attacks are often attempted to my systems on the Internet, which are accessible via ssh. Ssh allows for command line access to a remote system over the network, and is a very useful tool to administer systems remotely. Ssh allows an administrator to copy files up to a remote server and down from a remote server too.

Access to ssh is usually authenticated through a username and password, as is the case with most system access. (While authentication based upon a username and password is not great, it is the most scalable option available today.) Ssh, a widely available tool, is recommended for use since it  encrypts traffic, which reduces the ability for hackers to sniff account passwords. (Password sniffing is a problem with http, ftp and telnet communications.)

As ssh has grown in popularity, hackers have needed to devise new methods for breaking into ssh protected systems. One class of ssh hacking tool is SSHater, a tool that will try to guess valid usernames and passwords via ssh. Back to my systems on the Internet. I have configured my ssh server to log all invalid username/password attempts to the audit log, along with the IP address where the attempt originated. Here is a sample from my audit log.

type=USER_LOGIN msg=audit(1291694386.586:32619): user pid=17683 uid=0 auid=4294967295 ses=4294967295 msg=’op=login acct=”root” exe=”/usr/sbin/sshd” hostname=? addr= terminal=sshd res=failed’

I have gone through my last year’s worth of audit logs to summarize the most oftenly guessed usernames and sources of hacking attempts.  The most commonly guessed usernames are:  

  1. root
  2. test
  3. oracle
  4. admin
  5. user
  6. postgres
  7. guest
  8. nagios
  9. mysql
  10. tomcat

Runner-ups were; student, cyrus, mythtv, administrator, temp and apache.

And, here are the top IP addresses that have been trying to get in:

  1. (, a dns name with no website!)
  2. (korea)
  3. (china)
  4. (korea)
  5. (turkey)
  6. (korea)
  7. (pakistan)
  8. (ohio, USA)
  9. (korea)
  10. (turkey)
  11. (china)
  12. (mexico?)
  13. (korea)

What can we learn from this? First, notice that the username “root” is one of the most popular usernames guessed. That is because many UNIX systems are configured with a “root” account, and that account usually has full privileges. It is the account a hacker would most like to obtain for a system. To protect against this, make sure that root logins are disabled via the Internet. It is preferable to have a system administrator log in with their own userid, then “su” to a root level account.

Three of the top 10 are accounts (oracle, postgres and mysql) are database accounts. So, if you have these databases and they need to be admininistered from the Internet, be sure that you have secured your database usernames.

Accounts such as admin and guest are typically generic accounts shared by many people. These accounts usually have weak passwords and should be avoided.

In summary, remember to:

  • disable root level logins via ssh.
  • change default passwords for any and all default accounts.
  • review the audit log for login successes from unknown IP addresses.
  • review the audit log for login failures to keep an eye on the latest accounts that are being guessed against your system.

private peek into public lives…

The NY Times published an article on September 1st detailing how tabloid reporters in the UK gained access to celebrity voicemails. Using this access, the reporter were able to peek into the very private lives of public figures. (The articles can be found here).

Basically, the tabloid reporters built a list of celebrities’ cell phone numbers by working with private investigators. The reporters then went further and directly or indirectly gained access to the cell phone voicemail.

There were two different, very low-tech techniques that were used to get to the voicemails. The first one involved guess the 4-digit PIN associated with the voicemail. Often, this one succeeded when the default voicemail pin was used, since many people don’t seem to change their voicemail PIN.

The second method was a little more scary. The reporter would call the phone company and convince them to either reset the PIN or tell them the PIN for the voicemail. Either way, once they had the PIN, they could listen to voicemail messages on the cell phones.

Once the reporters started listening to the voicemails of the royal family, the police got involved. During their investigation, the police discovered a list of 91 cell phone numbers and associated voicemail PINs during a search of Glenn Mulcaire’s residence. (This search happened in 2006). Mulcaire was a private investigator working with Clive Goodman, a reporter at the “News of the World”.

Now the police were in tough position. They had a list of compromised voicemails. Should they notify all of the people on the list that their voicemails were potentially compromised? It appears from this article, the answer in the UK is no. The government was under no obligation to notify the individuals that their voicemails were compromised.

Would the laws in the US be different? After all, many states in the US have passed laws where private companies are obligated to notify affected parties when their security has been breached. By extension, would the police in the US be bound to notify people if their cellphone numbers and PINs were found on a list seized in the residence of a hacker? It appears from my discussions with those in the field that the answer is “no” here too.

This article points out a couple of very important issues:

  First, voicemail security is weak while the contents of voicemail are interesting. It seems likely that the contents of voicemails might be interesting in a civil court proceeding or business negotiation. At a minimum, make sure that you have a PIN that is the not the default PIN. It probably makes sense to change it periodically as well.

Second, if the police have discovered that your voicemail was hacked as part of a broader investigation, keep in mind that it appears in the US that they are not under any obligation to notify you. Basically, it comes down to the fact that you alone are ultimately responsible for the security of your voicemail.

MD5? SHA1? – Some facts and mis-conceptions about the checksum value

A checksum is mathematically calculated value that is used to detect data integrity. There are a few well known checksum algorithms in common use, Cyclic Redundancy Check (CRC), Message Digest 5 (MD5), and Secure Hash Algorithm 1 (SHA-1). While there are more than these three checksum algorithms, let’s just focus on these three for the moment.

Checksum algorithms take digital data and spit out a number. For example, let’s calculate the checksum value for the work “Hello” using the CRC algorithm. Using a simple Linux system, we can generate a checksum of the word “Hello” using the following command.

$ echo “Hello” | sum
36978 1

(In the above, the 36978 is the checksum value, and the “1” is the size of the input in blocks. We can ignore the trailing one.) If we change the capital H to a lowercase h and recalculate the checksum value, we will get a different result.

$ echo “hello” | sum
36979 1

Let’s add a space to the end of the input.

$ echo “Hello ” | sum
18510 1

This is what makes the checksum valuable. The output value is different when the input is different. A good checksum algorithm will produce the same value on the same input, and different values on different input. And, it will produce the same value on the same input on any computer.

The table below shows the checksum values for the three different variations of the word hello calculated with the three different algorithms.

Sample checksum values for CRC, MD5 and SHA1

“Hello” “hello” “Hello “ (with space)
CRC 36978 36979 18510
MD5 09f7e02f1290be211da707a266f153b3 b1946ac92492d2347c6235b4d2611184 adb3f07f896745a101145fc3c1c7b2ea
SHA1 1d229271928d3f9e2bb0375bd6ce5db6c6d348d9 f572d396fae9206628714fb2ce00f72e94f2258f a83f9352aa642ceec0a03b126e453a5984cf68ab

Notice that the checksum values for the same word are different when using a different algorithm. CRC does not produce the same value on the same input as MD5. And, MD5 produces a different value than SHA1. This means that you cannot use MD5 to verify a checksum value calculated with SHA1.

Myth – Knowing the checksum value, I can regenerate the input.

Checksum values are not easily reversible because the checksum algorithm throws away information during the calculation. Because of this, the checksum value of “36978” can’t be converted back into “Hello”, because Hello is one of many different possible inputs that could create that value. This leads to another myth…

Myth- A good checksum algorithm prevents collision.

A checksum collision happens is when two different values return the same checksum value. For example, the CRC checksum value for “Hello” is 36978, as is the CRC checksum value for “Jdll0”. (With the CRC algorithm, a collision can be easily generated by lowering the first letter of the word by one character while raising the second letter by one character.) A checksum collision is always possible no matter how good the checksum algorithm is. This is because a checksum has to take a file of some arbitrary size and reduce it to a number. A good checksum algorithm will just make it difficult to predictable manipulate the input to create a known hash value. MD5 and SHA1, since they are cryptographic hash functions, make it more difficult to manipulate input to produce a predictable checksum value.

Myth – A checksum value can be used to prove that data has been read correctly.

Since checksums can be used to detect alterations in digital input, they can be very useful in computer forensics. Checksum values can help to establish a very low probability of alteration of digital evidence once it has been captured. A checksum is extremely effective when it is declared after the acquisition of electronic evidence. The declaration of the checksum should be printed or otherwise stored to prevent potential alteration or tampering. Should the checksum of the evidence later be found to not match the declared checksum, there is a possibility that the evidence or evidence container has been altered. (Note carefully that it is possible, not definite.) Factors such as disk errors and errors in the checksum implementation can also result in a checksum mismatch.
What a checksum cannot do is prove that the correct digital evidence was acquired. Here is an example to consider. My company makes forensic imagers, and forensic imagers undergo validation testing by neutral third parties. Basically, these third parties are checking that the product does not alter the data that it was copying and that it copies all of the data.

During a couple of the different validations by different groups, we were contacted by the testers. The testers had told us that they had noticed that the checksum values that we produced were occasionally different than the ones that they produced using their equipment. Follow-up up investigation revealed that the checksums were indeed different, and in all cases it was because our system was capturing more disk data than their test system was. Well, that is good news for us, but why were they different? It turns out that when you capture more data, you need to run the additional data into the checksum algorithm. That, in turn, changed the checksum value and led to the difference.

This highlights that the checksum algorithm cannot be used to determine if the original disk drive was read correctly. As happened here, the validation team’s checksum values had matched when they did not read all of the data. The checksum value was very useful to determine that the source disk was not modified, but was not useful in determining that the source disk was read completely.

what is a good password?

Passwords are a secret used to prove your identity to a computer. We have come to rely on passwords to protect access to important things such as email accounts and bank accounts. The most commonly used type of password is a “static” password, a password that does not change when used. An example of a static password is the PIN that you use to access your ATM or the password that you use to access facebook. Static passwords are oftened used because they are cheap to implement and are well understood by the general public.

An improvement to static passwords is the one-time passwords. Most one-time password systems require the uses of hardware or specialized software, so they are much more costly to implement versus a static password. They are usually harder to support as well. (These factors are part of the reason why online banking is not protected with one-time password.)

When it comes right down to it, static passwords are really not a great way to prove identity. Password programs such as brutus, cain and abel, and thc-hydra are examples of programs that make password guess very easy.

While the above programs make password guessing simple, they are not the only threat to static passwords. Phishing attacks are designed to steal passwords by simulating a real web site that traditionally asks for your password. These attacks have been stealing passwords from ebay accounts, banking accounts and even facebook accounts. Phishing attacks usually start as an email message that comes from ebay or your bank asking you to confirm your account by logging into a website. More sphisticated ones will usually say that there is a fraudulent charge that has been posted to your account and you need to login in if you wish to dispute it or some other trouble with your account.

So, with these issues, what is a good password? Since we are currently stuck with passwords, they need to be complex enough to not be easily guessed. Might sound easy, but people publish lists of passwords. For examples of easily guessed passwords, check out this blog posting. Another good example is the openwall project’s list.

While passwords need to be complex, they also need to be simple enough to be easily remembered.  An article by Mark Pothier in the Boston Globe discusses Microsoft researcher Cormac Herley’s estimates on the costs associated with password resets and makes a case that complex, hard to remember passwords are not often worth the expense.

So, what is a good password? I still vote for a complex password that is regularly changed. Why? Well, in most of the network penetration tests that I perform, I have often found that a weak password exists and allows unauthenticated access to critical resources. Until a better method of user authentication exists, we are stuck with having to better manage our weak passwords. And remember, it needs to be changed regularly to limit the potential for misuse if it is captured, but not too often that you forget it.