Why phishers target low value accounts

PCWorld talks about a recent phishing scam on Twitter.  The question in the article is:

In this instance, it appears the site primarily used compromised accounts to spread the phishing links further. What, if any, broader goal was behind the effort is not yet clear.

I’ve posted about this before, but it seems prudent to talk about it again.  Phishers will try to get credentials for websites that use email addresses as usernames for one main reason: people often use the same password on all accounts. 

If a user is less worried about giving away his Twitter password – since what type of value could that have? – then, that’s the best thing the phisher can target.  The user is is less likely to be worried about giving away that password and therefore the conversion rate for the phisher is likely to be higher. 

If I was a phisher, the other thing I’d think about is that the people who use Twitter are more likely to be tech savvy and, therefore, have lots of online accounts.  Therefore, the passwords that I do steal would be more likely to be useful on other sites.

Seems like a good idea to be careful about random tweets!

Concern about web security at financial institutions

Russ McRee’s post on The need for financial web application security rung true for me.  While the bad actors are finding ways to make money through e-commerce and even social network websites, the finance sector will always be a target since that’s where the money is.

It can be super tough to harden a website against online attacks.  Russ does a great job calling out some of the things that are especially troublesome, but this dovetails nicely into the presentation Jeremiah Grossman gave yesterday (link to follow).  Jeremiah’s presentation said that cross-site scripting and cross-site request forgery are major problems, but business logic flaws are becoming more and more prevalent. 

Unfortunately, websites of all types are going to need to start defending themselves against all of these types of attacks – both the technical kind and the business logic kind.

Social Network Security – When will we reach the tipping point?

Bruce Schneier posted a link to an article on Facebook Privacy.   A couple of days earlier, Mario Sundar of LinkedIn posted an article on Security and Privacy on LinkedIn.

It’s fascinating that the security people are starting to pay attention to social networks.  Social networks have always had privacy and security risks.  In fact, they have much bigger privacy risks than typical websites where people have accounts.  E-commerce sites usually don’t show interesting information about where you work, your children’s names, the clubs you belong to, etc.

I’ve been keeping an eye on the progression of social network sites.  Having been responsible for user security on a website for three years, I understand the tradeoffs that have to be made.  Social networks are at the stage where attracting more people to join the social network is much more important than making sure that those users are safe.

I’ve definitely heard cases where marketing teams will tell the security group that protecting millions of users is not nearly as important as attracting millions more users to the website.   The e-commerce websites are starting to learn a valuable lesson, though: having a website that does not protect its users’ privacy and security will scare away users faster than it attracts them.  I’ve talked to several e-commerce companies lately that say they are ramping up their security teams to make sure that their customers have a positive experience.  It’s great to see the priority shifting from gaining new customers to keeping the current customers safe.

My question is: how long will it take for the social network sites to make the same choices?   Since internet time accelerates faster than normal time, my guess is that what took e-commerce companies 5-10 years will likely take social network sites 2-3 years.  I’ve heard rumblings of social network sites placing a priority on security, even if it means a few less registrations, but I don’t have any direct evidence.  If anyone has any anecdotes they’d be willing to share or predictions on how long it will be until we reach the tipping point, I’d be happy to hear them.

Investigating website fraud – the bad and the ugly

In my last post, I talked about the Koobface virus, how it is an example of a business logic flaw, and how difficult it can be to find business logic flaws on websites. BTW – I should know. It used to be my job to find, investigate, and fix the business logic flaws on eBay. I’m sure you’d agree that is not a trivial task.

Let’s look at the next step of addressing business logic flaws: investigation. Once the business logic flaw has been identified (usually after days of customers reporting the problem), it’s critical to determine how the attack is being carried out (and, if possible, by who).

Here’s a typical investigation technique by someone trying to determine the exact method of the perpetrators of a business logic attack:

1. Grab all of the weblogs for the website during the impacted time period

2. Sort through the weblogs to find the exact transactions that represent the attack

3. Correlate the data in the attack transactions to determine patterns

The above list may seem simple, as usual, there are hidden complexities. First, grabbing the weblogs for the website can be a daunting task. Because of load balancing, you have to get ALL of the weblogs – it’s not enough to just grab the ones where you think the data might be – a load balancer will scatter user sessions across all of the files. And the size of the logs can be massive – I know some sites that have terabytes of logs per day – compressed. Dealing with a terabyte of data is no small feat.

Next, sorting through the logs can be challenging. Again, because of the load balancers, the transactions for a session are scattered. This means that if you find one part of a session in one file, you’ll need to find the rest of the session, and it could often be in any other file. Once you have all of the transactions for the session you have to reassemble them into the correct order so that they make sense. This is even more challenging when webservers clocks are not synchronized.

Finally, you have all of the sessions for the bad behavior re-assembled, now you have to look through them to determine a fingerprint. What is it about each session that is similar to the other bad sessions, but dissimilar to good activity on the site.

Needless to say, doing all of the above by hand is an extremely time consuming task. The investigation step of addressing a business logic flaw can take DAYS by itself. And, similar to the identification phase, while the investigation is happening customers are continuing to be impacted.

Perpetrating fraud on social networks

There has been a lot of talk recently about the Koobface virus (see the article from CNET and the article from Wired).  Viruses are definitely an internet scourge at the moment, but there is another, more subtle, security risk here.

The Koobface virus propagates on social network sites like MySpace and Facebook through the mechanism that allows the users of the site to send messages to their “friends”.  This is an example of what Silver Tail calls business process abuse and similarly what Jeremiah Grossman calls business logic flaws.  Social network sites want their users to be able to send messages to each other.   Turning off the ability for users to send messages to each other would disable an important function on the social network sites.  And yet, bad guys can take advantage this function to send malicious messages. These sites need to allow users to send messages to each other while protecting the users from people abusing the same functions to perpetrate bad activities (like sending links to websites that contain viruses and other types of malware).

Unfortunately, protecting users from business logic flaws is extremely challenging.  There is a huge amount of exposure due to the time it takes to identify the issue, confirm the nature of the issue, and develop and deploy a fix.  Each of these areas is so important that it wouldn’t do them justice to discuss them all in one posting.  I’ll cover the identification of business logic flaws here and save the investigation and mitigation of those flaws for future installments.

So, how do most websites identify business logic flaws?  Since business logic flaws are not errors in the code of a website, the traditional mechanisms for finding bugs don’t apply.  This means that most of the time a bad guy finds a business logic flaw on a website, it is brought to the attention of the website from the customers that are impacted, and often days or weeks later.

Let’s walk through an example.   Say that a bad guy starts sending messages to people through a social network site and those messages contain a link to a site hosting malware.  Some number of customers receives the message.  The more savvy customers will know the message is malicious and report it back to the social network site.  The customer support team of the social network site will investigate the complaints about the messages and once they determine there is a pattern of problematic messages, they will report them to the appropriate group inside the social network site – say the group concerned with customer security – so that an action can be taken to rectify the problem (we’ll discuss rectifying the problem in an upcoming post).

Looking at all of the actions above, how long could this take? If lots of users receive the malicious message – this is already a problem since those that are not savvy will likely get infected by the virus – it’s more likely that savvy customers will report the problem quickly.  Let’s say it takes 8 hours for 50 reports to come in about the same issue.  Since customer support is reviewing cases about all sorts of concerns from the users of the social network site, it may take a day or two to get to the 50 cases that were reported.  It wouldn’t be until the end of the second day that they realize there is a trend with the same malicious message being reported by many customers.  At this point, the message has been “in the wild” for two days.  After two days, customer support escalates the issue to another group to address the problem.  Unfortunately, since there has been customer impact for a couple of days, there could be lots of users impacted by the malicious link.

To make matters worse, investigating and fixing the problem can take even longer.  But we’ll get into the details of that in a future posting. It would be great to hear from those of you who have experience responding to these types of exploits.