Posted
by
samzenpus
on Thursday January 17, 2013 @03:03AM
from the on-to-the-next dept.

chicksdaddy writes "Researchers at RSA say that a new phishing toolkit allows attackers to put a velvet rope around scam web pages – bouncing all but the intended victims. The new toolkit, dubbed 'Bouncer,' was discovered in an analysis of attacks on financial institutions in South Africa, Australia and Malaysia in recent weeks. It allows attackers to generate a unique ID for each intended victim, then embed that in a URL that is sent to the victim. Outsiders attempting to access the phishing page are redirected to a '404 page not found' error message. Other phishing kits have used IP address blacklists to block anti malware companies from viewing their malicious pages, but this is the first known use of whitelisting, RSA said. The phishing attacks that RSA technicians discovered that used the Bouncer kit were designed to harvest login credentials from financial services firms. The whitelisting feature may well work, especially given the volume of potential phishing pages that security companies review each day. Getting a 404 message may be enough to get a forensic investigator or security researcher to move on to the next phishing site, rather than investigating."

It's a bit ambiguous and unsaid at the RSA blog page how exactly this spearfishing attack is "valdiating or checking ID"... They say:

The bouncer phishing kit targets a preset email list for each campaign. A user ID value is generated for the targeted recipients, sending them a unique URL for access to the attack. Hereâ(TM)s the interesting part â" much like a night clubâ(TM)s bouncer list â" any outsider attempting to access the phishing page is redirected to a âoe404 page not fo

This doesn't use IP addresses to verify. Using IP addresses requires you to know the IP addresses of your intended victims, severely limiting the usefulness. This can send emails automatically and still filter out the incoming requests.

I use precisely this technique for presenting discount vouchers to people who have signed up to a restaurant mailing list, identical system but for white hat purposes:

1 - send an email to the relevant contacts, including an embedded image at domain.com/voucher.php?id=xyz where "xyz" is a unique account ID.

2 - when the recipient receives the email the voucher that is displayed has their name on it, the image is generated on-the-fly using the unique ID to get the name right.

3 - (this is the important bit) - if anyone logs into domain.com/voucher.php without passing a correct ID then they simply see a voucher marked as invalid, and a link to where they can sign up. In my case it stops non-members getting a voucher, in the spammers case it stops a non-target (including investigators) from seeing the exploit being presented to a "customer", most likely someone from a list of known phishing mugs.

Whether key or ip are used here is missing the kind of whitelisting this malware is using. When the package exploits a server, it alters pages/links to redirect each unique visitor to a dynamically generated temp folder on itself which contains the phishing code, and afterwards is deleted. The phishing code could obviously get more selective, and will contain a destination either via redirect or transmission, but returning to the same url gets you nowhere. Have the link/page exploited float around as well

Interesting parts as well state infected servers can redirect to one another. Seeing this is partly a WordPress exploit, I wonder if an email link is even necessary. Visit 1 exploited in-net box and it might be able to get you where it needs.

When the package exploits a server, it alters pages/links to redirect each unique visitor to a dynamically generated temp folder on itself which contains the phishing code, and afterwards is deleted.

Fabulous... I just need to make my mail server, PING every URL in an e-mail before delivering the message, and if it's a phishing attempt, the user will get a 404 error instead of the phisher's intended page.

Another possibility is to rewrite every URL in every e-mail (except ones in a whitelist),

So which is it? Aren't they using IP addy to verify the identity of the sucker? Or is their some other source (their unique URL that they post)?

We've started seeing some of these newfangled phishing emails over the last few days. The victim's email address is used as an identifier. It is simply appended to the URL by the mailer bot, so that the link sent to the victim will look something like this:

hxxp://compromisedsite.ru/joe33/somebank/?victim@gmail.com

That URL would lead to a script hosted on a compromised site, which looks up the email address in a whitelist before serving either a credential-collecting scam page or a bogus 404 error.

But this is all very basic stuff, and it is not hindering forensic investigators in the least. The folks investigating such scams don't just stumble upon them by accident; they rely instead on vigilant users and admins who take the time to report phishing emails. Once they get a report they already have a whitelisted URL to begin with.

It looks like banks and gov departments can no longer be trusted as normal web sites. They have to be setup to be only available through SSL and must use client certificates for authentication with some way of verifing that the server certificate matches the client certificate.

Only then could the software (possibly a custom configuration of a web browser, maybe an normal one) actually be sure of defeating a phishing attack.

Of course the main reason it'd work is that with a client certificate there's no password to "phish" for.

Something tells me that the banks are too lazy to do this; every other web site will have to be SSL before they get on the bandwaggon.

As far as I can tell the OTP calculators are only issued for business accounts, normal "end user" accounts have minimal provisions. One example uses a user ID, a password (split into two entry fields) and the site displays a picture that you chose when you first activated the "web access" .

This isn't that secure and because a lot of their site is HTTP there's a good chance that "sheep" attack will work too.

This is what my bank does, actually. The challenge/response method after inserting your card into the reader and entering your PIN. Sometimes there are several challenges, based on what you're doing (multiple transactions). The response is then entered into the website to validate the payment/transfer. You can configure some recipients to not require challenge/response after you've done it the first time (utilities, cable, etc.).

Sorry for using the wrong terms. THIS is the method that US banks should be usi

Yes, same here in Switzerland at UBS. I have a SmartCard and a reader, and I have a PIN, and then there's some sort of challenge/response magic going on.

There was an article in the newspaper recently, and they compared the various authentication-mechanisms used for Swiss bank accounts, unsurprisingly, the outcome was that UBS had the most secure as well as the most user-unfriendly authentication process.

I guess online banking is where I'll always prefer security over ease-of-use.

Not at all. BankID, the dominant form of bank-authenthication in Norway issues OTP-calculators to everyone, including average private people with a perfectly ordinary account.

As an alternative, they have a solution where the SIM-card in your mobile-phone is used by an app to authenthicate you.

In both cases the same thing is true: logging in to your bank requires knowledge of your passphrase -- but *also* physical possession of a object - so a phisher would need to get both somehow, in order to be able to impresonate you.

It might not make phishing impossible, but it does make it a lot more difficult.

Going by the several replies with European (and even Asian) countries where OTPs are the norm for internet banking, it looks like you are wrong. Where I'm from (Norway), not only do I need an OTP for internet banking, but I also have to use it when I make a purchase from most Norwegian webshops. It's funny when Ebay is easier to phish than my local small-town computer part store's e-commerce solution.

As far as I can tell the OTP calculators are only issued for business accounts, normal "end user" accounts have minimal provisions.

Most, if not all, banks in Sweden have keypads that generate one-time codes - for "normal" end-users, not just business users. This has ben the case for years. Some have different methods for logging in vs signing transactions. Some require an ATM/VISA/etc card with a chip on it.

I've got a OTK generator as part of a very basic UK personal current account, they've been around for about a decade now, and are becoming more widespread. It's used instead of / as well as standard "enter characters 1, 5 and 9 of your memorable name" system.

It depends on the bank but in Germany most banks have already phased out basic things like TAN lists (plain and indexed). Username/password are required to log onto the site but they aren't sufficient to conduct any transaction. At most you'll be able to determine someone's balance.

For example, my bank allows two methods, ChipTAN and mTAN. These are fairly usual in Germany.

ChipTAN uses the user's bank card and a card reader. The reader is synchronized with the bank so that when combined with the correct

The point of the keypads is that it verifies you're in posession of the card. You need the card, the reader and your PIN to generate the response code the website is looking for. When validating transactions, you need all of that plus a challenge code that the banking website provides.

So it's more than those keychain dongles that have changing codes on them...

That's what highlighting the domain (the public suffix [publicsuffix.org] and the hostname element before it) is for. If the domain is the same as the domain printed on the back of your credit or debit card, and the organization name and address in the EV SSL certificate match those of the bank, then you're probably connecting to your bank.

It wouldn't. But a challenge/response system where you must have the card, reader, PIN and one-time code to log in and then, again, the card, reader, PIN, challenge from the website and the appropriate response code to make the transfer, would make life very hard for the phisher. The "identify" and "sign" functions are different actions, so you'd have to fool the user into signing the transaction.

Social engineering over the phone posing as bank representatives would probably be more effective than automatin

Among the top forms of card fraud are card not present, counterfeit cards and lost/stolen card fraud, but the biggest category of card fraud is "first-party" fraud, which is committed either by a thief or a legitimate cardholder who intentionally decides not to pay off a credit card balance, the report showed.

According to the first paragraph in my link there's 26,000,000 mobile bank users in the US (I'm using this, the lowest possible valid number of account holders for this, as fewer people for same fraud means more fraud/person). I got this number by assuming 200,000,000 total account holders (108,000,000 x 2 approximated, as 108,000,000 was 46%, and currently 13% use mobile banking). If we take the US total fraud (approx.5 of 7.6 billion) and the 26 million numbers, we get about $136 per a mobile account hol

It'd be interesting to see:1) how much dollar savings/account holder was saved in europe and asia (couldn't deduce it at a glance), and what the actual cost of those pads are (my friend pays $15 (10 pounds) for one, and has lost it more than once. Also, the ability to not bank if she leaves her purse at a friends for a day or two is an additional annoyance).

If fraud is costing the average account holder less than $20/year, I don't like the idea of giving the banks another way to charge fees...

The keypads are a small part, though, as I mentioned. Every point of sale would have to get a new reader to validate smart-cards and the PIN. I get funny looks in Europe when I use my US cards that have to be swiped. How quaint...

I've never bought anything online with my European cards, though, so I have no idea how that's implemented. I can't imagine every retailer is using a challenge/response system like the bank websites are... If it's just a matter of entering card information like we do in the US, the

What banking website are you using that doesn't use SSL/TLS? I think what you're suggesting is that instead of websites using a simple username and password (something you know), they should move to having user certificates for each client (something you have). The problem with that is you still have a single factor authentication, which is no more secure.

Bullshit. A good single factor is a lot more secure than a shitty single factor.

With passwords, you're still transmitting the secret token, which is what makes phishing work in the first place. With a client cert, you explicitly do not send your secret key. The phisher can't use that to impersonate you.

Certificates can be stolen by spyware. As others pointed out, you need a 2 factor authentication and proper prevention of MitM attacks on both network level (SSL/TLS) and on the user's machine. You need it on the user's machine as well to prevent malware modifying the web page, hiding a malicious transaction from view, but still submitting it to the bank. In Europe a lot of countries use the chip part of the debit card with an OTP generator to generate responses to challenges sent by the bank website. This

If World of freaking Warcraft can issue OTP devices to their players, big banks should be more than capable of providing the same. Even if it's just a smart-phone app (far less secure than a physical device, but more secure than nothing)

It looks like banks and gov departments can no longer be trusted as normal web sites.

While this statement may be true, I don't understand how you arrive at that this conclusion from TFA. This is a classic phishing attempt, as in go to a random website that is NOT the bank or gov web site.
It is the same as someone calling you up, claiming to be from the bank, and asking for account info. And then you saying the Bank's phone number can't be trusted.

1. Determine someone's mail address.
2. Associate an IP address (or ISP-specific range) with the mail address, for example by having malicious code in place in a website where the mail address is entered.
3. Store the IP/mail address combo in a database and use it to verify that the person visiting is likely to be the person the mail was supposed to reach.
4. ????
5. Profit

Sure, it's relatively much work but it's also relatively hard to get into.

Problem -- This is something you would like to avoid doing in general, because you don't want to let the spammer know that the email was sent to a mailbox that is read. With these, you can't avoid it, alas.

On the other hand, just the fact of obfuscation of this sort can be taken as evidence that the sender of the email has something to hide. Are there any non-phishy reasons for an email sender to do this? I can think of some plausible legitimate reasons that someone might think it was a good idea... but

email harvesters/spammers have been using unique strings in links to verify addresses a hell of a lot longer than 7 years.. probably longer than legitimate mass marketers have been doing it to get stats on each mailing campaign.

I expect antivirus companies, just like government agencies have registered hundreds or thousands of email addresses all over the world on different service providers and domains with the express purpose of harvesting spam. Therefore they're likely to receive legitimate links to phishing sites or be able to identify ones which are protected by per-mark unique urls. And of course the likes of Google, Microsoft, Yahoo et al who run their own webmail services could roll as many spam traps as they liked and analyse spam going to users too.

So while it might afford some protection to the phishing site, it doesn't seem very likely that it would protect them from further scrutiny.

I think a bigger benefit for phishers is they can identify users who click on these links they can focus their attention on them rather than on users who don't. Somebody dumb enough to click on these links and fill in data is obviously a more valuable target than someone who never responds.

Personally I think the best way to combat phishers would be for major mail providers to work with banks and credit institutions to poison phishing sites with bogus data and flagged cards / accounts.

I've seen ones years ago that were PHP scripts that had different behavior based on who was coming in. (one of the more clever ones actually took over the site's main index... but if the visitor was from the same domain as the server, it returned a near-duplicate of the original content and not the drug ads)

The 404 aspect does give me an idea that I think could make things trickier, but I'll be damned if I'm going to give spammers any ideas for things that they're not already using. (although, I guess it's possible that what I'm thinking of is what they're actually doing, but no security person would call a whitelist... some person who's not really familiar with the security lingo might, though)