OK, I don't have anything resembling a patent claim here, but a year ago I described a need and a potential solution for targeted phishing attacks against Credit Unions. Today, Brandimensions announced StrikePhish, a service offering in that very space.
So instead of the millions of dollars I deserve, I'll settle for StrikePhish buying me a beer at the next con I see them at. ;-)
Showing posts with label phishing. Show all posts
Showing posts with label phishing. Show all posts
Thursday, March 20, 2008
Thursday, November 8, 2007
Targeted Phishing, You Don't Say?
I hate to say it... Oh, who am I kidding? I LOVE to say, "I told you so!" This is actually pretty neat, so long as you're not salesforce.com.
(Via Schneier) Salesforce.com admitted today that one of their employees was the victim of targeted phishing. And that once his account was compromised, it was used to get lists of e-mail addresses for... wait for it... more targeted phishing attacks!
So as targeted phishing attacks pass from the realm of pen-testers-who-can't-use-debuggers to actual criminals, the anti-spam/phishing segment is going to have to catch up. And it's not going to be easy, because traditionally collecting spam and phishing e-mails has been remarkably easy. But once the attacks become targeted, it's exponentially harder to get samples before the damage is done.
Enter the custom-tailored anti-phishing service. Gonna call those VC folks back.
(Via Schneier) Salesforce.com admitted today that one of their employees was the victim of targeted phishing. And that once his account was compromised, it was used to get lists of e-mail addresses for... wait for it... more targeted phishing attacks!
So as targeted phishing attacks pass from the realm of pen-testers-who-can't-use-debuggers to actual criminals, the anti-spam/phishing segment is going to have to catch up. And it's not going to be easy, because traditionally collecting spam and phishing e-mails has been remarkably easy. But once the attacks become targeted, it's exponentially harder to get samples before the damage is done.
Enter the custom-tailored anti-phishing service. Gonna call those VC folks back.
Tuesday, October 9, 2007
Phishing Secure Email Portals
Here's a new twist on an old scam:
Lots of companies have implemented some form of "secure e-mail" solution. If you haven't seen this before, a user at Megabank or Gotham Hospital sends you a message about your personal information. Instead of arriving directly over SMTP (which is, among other things, as clear a text protocol as any), you receive a notification via SMTP that tells you to click on a link to a web site (encrypted with SSL) where you can log in and retrieve your message. This is extremely common in the health care vertical because the HIPAA Privacy Rule that went into effect in 2003 explicitly forbids sending personal information unencrypted over the Internet.
So it makes perfect sense that these portals are worth phishing - they are almost guaranteed to contain some sort of valuable data. But it got me thinking about something else. I work in the health care vertical, and we have a secure e-mail solution in place. And when we evaluated products a few years ago, we discovered some sort of session handling flaw in better than half of the products we looked at. Not to mention that a number of the vendors out there support what can only be described as a "letter-of-the-law" configuration*.
Anyway, I wonder if phishing is all that necessary for sites like these. I would bet that there are enough vulnerabilities in enough of these portals that hacking them straight up is a better bet for the criminals that want the dumps to sell on IRC. Especially since some of the third-party products out there are appliances that insist on SSL termination at the appliance. What's that mean to a hacker? A blind spot to the IDS plus permission from the firewall. Oh, and we all know how good the logging on an appliance like that is bound to be.
* In this mode, the portal sends a link that contains a hash of some kind. Send that link back with the valid hash, view the message. Well, technically, the private data's not sent unencrypted. Instead, a link to the private data is sent unencrypted. If you have deployed something like this and you feel that you can justify it, I'd love to hear from you. Obviously there was enough demand for it since most of the vendors in this space have something like it.
Lots of companies have implemented some form of "secure e-mail" solution. If you haven't seen this before, a user at Megabank or Gotham Hospital sends you a message about your personal information. Instead of arriving directly over SMTP (which is, among other things, as clear a text protocol as any), you receive a notification via SMTP that tells you to click on a link to a web site (encrypted with SSL) where you can log in and retrieve your message. This is extremely common in the health care vertical because the HIPAA Privacy Rule that went into effect in 2003 explicitly forbids sending personal information unencrypted over the Internet.
So it makes perfect sense that these portals are worth phishing - they are almost guaranteed to contain some sort of valuable data. But it got me thinking about something else. I work in the health care vertical, and we have a secure e-mail solution in place. And when we evaluated products a few years ago, we discovered some sort of session handling flaw in better than half of the products we looked at. Not to mention that a number of the vendors out there support what can only be described as a "letter-of-the-law" configuration*.
Anyway, I wonder if phishing is all that necessary for sites like these. I would bet that there are enough vulnerabilities in enough of these portals that hacking them straight up is a better bet for the criminals that want the dumps to sell on IRC. Especially since some of the third-party products out there are appliances that insist on SSL termination at the appliance. What's that mean to a hacker? A blind spot to the IDS plus permission from the firewall. Oh, and we all know how good the logging on an appliance like that is bound to be.
* In this mode, the portal sends a link that contains a hash of some kind. Send that link back with the valid hash, view the message. Well, technically, the private data's not sent unencrypted. Instead, a link to the private data is sent unencrypted. If you have deployed something like this and you feel that you can justify it, I'd love to hear from you. Obviously there was enough demand for it since most of the vendors in this space have something like it.
Tuesday, April 24, 2007
Phishing Credit Unions
You may have caught this story in the Washington Post about hacked servers and phishing attacks at Indiana U. If you haven't, I recommend that you do read it. It stars Phishing's man of the hour, Chris Soghoian. Go on. I'll wait.
OK, so the interesting thing about the phishing attack at IU is that it seems that the phishermen were targeting specific credit unions. From the standpoint of traditional bank phishing attacks, targeting small credit unions doesn't make a ton of sense. Local credit unions typically have only thousands or tens of thousands of members. Chase, BofA, and Citibank, for example, all have millions of members worldwide. That's why originally, the big banks were the primary targets of phishing. That seems to be changing, though.
Old model:
Build phishing site that looks like global bank's website & write convincing phishing e-mail. Spam e-mail to tens of millions of addresses. Wait for victims to hand over credentials. Steal info, empty accounts, sell on IRC. Site is shut down in less than a week because high volume of spam == high likelihood of landing in a spam trap or being reported to bank, ISC, CERT, etc.
New model:
Build phishing site that looks like local credit union's website & write convincing phishing e-mail. Spam e-mail to domains of companies listed on credit union's list of select employer groups. Wait for victims to hand over credentials. Steal info, empty accounts, sell on IRC. Site is up longer because the likelihood of being detected is less (no spam traps), and most credit unions outsource infosec functions and only keep a small IT staff so reaction times are typically slower.
To review, credit unions make good phishing targets because they:
1. Outsource lots of IT & infosec functions.
1a. Pay for infosec work required by NCUA and PCI, but neither requires policy/procedure for responding to active phishing attacks.
2. Publish list of companies whose employees are eligible to join, making it easy to target spam to members.
The easy solutions to CU phishing, like making the employer list private, suck because they can have a negative impact on business. So here's a crazy thought. There's a niche in phishing detection for CUs. You would need to create a phony web/email presence, put the fake company on the CU's employer group list, and then wait for hits and coordinate the response to members, antispam vendors, the ISP of the phishing site, and law enforcement. Credit unions already like outsourcing infosec, and the best way to be cost-effective at this is to service multiple credit unions.
So, uh... gotta go. Got some VC folks to call.
OK, so the interesting thing about the phishing attack at IU is that it seems that the phishermen were targeting specific credit unions. From the standpoint of traditional bank phishing attacks, targeting small credit unions doesn't make a ton of sense. Local credit unions typically have only thousands or tens of thousands of members. Chase, BofA, and Citibank, for example, all have millions of members worldwide. That's why originally, the big banks were the primary targets of phishing. That seems to be changing, though.
Old model:
Build phishing site that looks like global bank's website & write convincing phishing e-mail. Spam e-mail to tens of millions of addresses. Wait for victims to hand over credentials. Steal info, empty accounts, sell on IRC. Site is shut down in less than a week because high volume of spam == high likelihood of landing in a spam trap or being reported to bank, ISC, CERT, etc.
New model:
Build phishing site that looks like local credit union's website & write convincing phishing e-mail. Spam e-mail to domains of companies listed on credit union's list of select employer groups. Wait for victims to hand over credentials. Steal info, empty accounts, sell on IRC. Site is up longer because the likelihood of being detected is less (no spam traps), and most credit unions outsource infosec functions and only keep a small IT staff so reaction times are typically slower.
To review, credit unions make good phishing targets because they:
1. Outsource lots of IT & infosec functions.
1a. Pay for infosec work required by NCUA and PCI, but neither requires policy/procedure for responding to active phishing attacks.
2. Publish list of companies whose employees are eligible to join, making it easy to target spam to members.
The easy solutions to CU phishing, like making the employer list private, suck because they can have a negative impact on business. So here's a crazy thought. There's a niche in phishing detection for CUs. You would need to create a phony web/email presence, put the fake company on the CU's employer group list, and then wait for hits and coordinate the response to members, antispam vendors, the ISP of the phishing site, and law enforcement. Credit unions already like outsourcing infosec, and the best way to be cost-effective at this is to service multiple credit unions.
So, uh... gotta go. Got some VC folks to call.
Friday, April 13, 2007
Phish 2.0
Richard Stiennon points out a most excellent post from Christopher Soghoian's blog on phishing attacks against PassMark and similar technologies (with movies!). I teach a home computer security class through my employer's corporate training program, and this very issue (Does PassMark prevent phishing?) came up in a class I taught yesterday. Chris' work proves what I suspected - no, PassMark accounts can still be phished quite reliably.
In his post about Chris' work, Richard concludes, "Its a war of escalation and banks have to stay ahead." It is a war of escalation. Most of infosec is. However, while banks have a vested interest in making financial transactions on the web safe for customers, it's the customers that have to stay ahead. If you can trick someone into clicking a link and believing that web site is something it's not, then there's not much the bank can do. MiTM is like trump here - it even beats tokens and other 2-factor authentication mechanisms as long as the phisherman can intercept that traffic as well. That's why I also believe that the owning of public wireless networks will continue to grow in prevalence.
The real work to be done is the client software vendors. If Outlook warned you or outright prevented you from clicking sender-supplied "a href=" links, then phishing would be all but over. Similarly, if Microsoft made IE's SSL cert warning messages more dramatic, or even cached error-free certificates for later comparison, MiTM against SSL would be over as well.
I think that following links in e-mail or IM is going to have to become like leaving your car unlocked at the mall. Nobody locks the car for you, even though the technology probably could, but you know that if you don't, you could get robbed. Unfortunately, a lot of people are going to lose a lot of money in the mean time.
In his post about Chris' work, Richard concludes, "Its a war of escalation and banks have to stay ahead." It is a war of escalation. Most of infosec is. However, while banks have a vested interest in making financial transactions on the web safe for customers, it's the customers that have to stay ahead. If you can trick someone into clicking a link and believing that web site is something it's not, then there's not much the bank can do. MiTM is like trump here - it even beats tokens and other 2-factor authentication mechanisms as long as the phisherman can intercept that traffic as well. That's why I also believe that the owning of public wireless networks will continue to grow in prevalence.
The real work to be done is the client software vendors. If Outlook warned you or outright prevented you from clicking sender-supplied "a href=" links, then phishing would be all but over. Similarly, if Microsoft made IE's SSL cert warning messages more dramatic, or even cached error-free certificates for later comparison, MiTM against SSL would be over as well.
I think that following links in e-mail or IM is going to have to become like leaving your car unlocked at the mall. Nobody locks the car for you, even though the technology probably could, but you know that if you don't, you could get robbed. Unfortunately, a lot of people are going to lose a lot of money in the mean time.
Subscribe to:
Posts (Atom)