Wednesday, July 18, 2012

On information leakage

Information leakage in real life

One of the things we worry about in the security biz is information leakage: information exposed during a normal process that could later be used to compromise security. Some obvious examples of information leakage include:

  • e-mail or instant messages accidentally sent to the wrong address
  • confidential phone calls or hallway conversations that are overheard
  • lost (and unencrypted) laptops or media, like USB sticks
  • web site URL arguments containing confidential information (like a username or password)
A less obvious example is the behavior of an algorithm, such as the time required to process an authentication request (known as a side-channel or timing attack). Even when the attempt to authenticate fails, if the process takes more time than was required in a known previous attempt, this might indicate that at least some of the information provided was correct, and that the algorithm had to proceed to further checking before finding the ultimate reason for the failure. Most algorithms of this sort now do the (unnecessary) work of checking all information, rather than stopping at the first mismatch so as not to give any hints about exactly what failed. Ascertaining useful information is often complicated, but sometimes information leakage is neither obvious nor complex.

I recently went to the bank to get cash from the ATM. Rather than $20, $40, or $100, as most people withdraw, I purposely withdraw an unusual amount of money from my account. This way, when I look at my statement, any withdrawal in any amount other than my normal amount(s) attracts my attention.
In an effort to "help" me with my ATM transaction, my bank displays the amount of my previous withdrawal, in case I want to withdraw the same amount again. They do this on the same screen where I am prompted for my PIN after inserting my card. I can type in my PIN and tap the button for my normal withdrawal, all in one action. But all of this information is presented before I have been authorized to access the account. So if somebody gets their hands on my ATM card, they can find out how much money I withdrew the last time I visited an ATM without entering a PIN.

As in so many cases of information leakage, this might not seem very useful by itself. But perhaps it could be used to socially engineer a victim. If a bad guy gets my card, he can look me up in the phone book because my name is on the card. He can call me claiming to be from my bank and tell me my ATM card has been returned. To "prove" he's from the bank, he tells me the last withdrawal amount on my account (and even using my unusual amounts, I may be inclined to accept this as proof). Once he convinces me he really is from my bank, he asks me to confirm my PIN "so he can be sure it's really my card." If I give him my PIN, he can then withdraw all the money from my account, all because my bank is trying to make my ATM transaction easier for me.

Designers of systems should always think about all the information they divulge and remember that information leakage can happen in seemingly innocuous places.

by King Ables

No comments:

Post a Comment

Comments are moderated with the goal of reducing spam. This means that there may be a delay before your comment shows up.