Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Webmail and Online Banks Targeted By Phishing Proxies

timothy posted about a year and a half ago | from the my-credit-union-won't-even-work-with-mint.com dept.

Security 50

An anonymous reader writes "Netcraft confirms a recent increase in the number of malicious proxy auto-config (PAC) scripts being used to sneakily route webmail and online banking traffic through rogue proxy servers. The scripts are designed to only proxy traffic destined for certain websites, while all other traffic is allowed to go direct. If the proxy can force the user to keep using HTTP instead of HTTPS, the fraudsters running these attacks can steal usernames, passwords, session cookies and other sensitive information from online banking sessions."

cancel ×

50 comments

Sorry! There are no comments related to the filter you selected.

Why HTTP? (4, Insightful)

AK Marc (707885) | about a year and a half ago | (#42925133)

Why bother with HTTP? Plenty of malware gets signed certs. If you are messing with malware, change the root certs on the machine (assuming your malware installing the proxy has root), and use HTTPS to www.citibank.com. The user won't know the difference. It'll show up as a valid cert to the right domain, and the proxy can re-encrypt it and use the unencrypted username and password submitted to it. Plenty of corporates do this and have the ability to sniff 100% of employee traffic, even encrypted, because it's all signed and trusted certs, there will be no warnings, though you can inspect the cert for trusted sites, and you'd have to verify DNS or certs for every secure site, which breaks all the usability models. If it takes root to get the malware on in the first place, the hackers screwed up big if they didn't make it work for HTTPS.

Re:Why HTTP? (4, Insightful)

karnal (22275) | about a year and a half ago | (#42925237)

Path of least resistance at this point. What's easier, getting a malicious PAC script installed, or getting the same PAC script installed as well as having a user sign off on an invalid certificate?

Admittedly, getting someone to blindly click "yes" to accept the bad certificate isn't difficult, but if it doesn't pop at all - all the better for the malicious person on the other end.

Re:Why HTTP? (1)

AK Marc (707885) | about a year and a half ago | (#42925737)

If you've got root, would they have to have the user click again to install the cert?

Re:Why HTTP? (1)

DarwinSurvivor (1752106) | about a year and a half ago | (#42926487)

If you've got root, would you bother with HTTP interception at the network level?

Re:Why HTTP? (1)

AK Marc (707885) | about a year and a half ago | (#42933045)

If you want to intercept data and get it off the computer with no possibility of detection for transmitting it back home, it's great. If your detection software is aimed at blocking unauthorized transmissions, then it's a great attack vector.

Re:Why HTTP? (2, Insightful)

Anonymous Coward | about a year and a half ago | (#42925407)

Why redirect the traffic at all? Why not just use a key logger and grab credentials that way? Most banks and webmail don't use two factor authentication.

Re:Why HTTP? (2)

AK Marc (707885) | about a year and a half ago | (#42925753)

Well, my bank (Bank of America) makes me click on a photo. So a keylogger would see that I clicked at 40,140 or whatever, but not know what I clicked on. The proxy would be able to capture the submit response, and use that to determine the full login credentials.

Re:Why HTTP? (1)

DarwinSurvivor (1752106) | about a year and a half ago | (#42926505)

If it's tailored to bank-credential stealing, taking screenshots on each mouse click isn't exactly out of the question.

Re:Why HTTP? (1)

AmiMoJo (196126) | about a year and a half ago | (#42928853)

Couldn't it just capture the screen when you click? That's how the old technique of making you pick from drop-down menus was circumvented.

Re:Why HTTP? (1)

AK Marc (707885) | about a year and a half ago | (#42932997)

I've never seen any capture that works well for typing "ass" click at the front "P" [end] "word". And there's also the one that counts the cadence. I type my password with a particular rhythm. But a logger could map the cadence and replay it, but none do, so far as I've seen, so the ones that track not just what you type, but how, are safe for the moment.

Re:Why HTTP? (2)

Mojo66 (1131579) | about a year and a half ago | (#42926967)

Why redirect the traffic at all? Why not just use a key logger and grab credentials that way?

Because a keylogger would alert anti-virus Software, while a PAC script wouldn't.

Re:Why HTTP? (1)

allo (1728082) | about a year and a half ago | (#42927121)

password + TAN isn't two-factor?

Re:Why HTTP? (3, Insightful)

manu0601 (2221348) | about a year and a half ago | (#42925513)

Why bother with HTTP? Plenty of malware gets signed certs.

The attack described here does not involve malware. On WPAD requests seen on DHCP or DNS, just inject a WPAD reply with a malicious PAC script and you are done.

Netcraft confirms it?! (1)

Anonymous Coward | about a year and a half ago | (#42925147)

Oh my God. This is serious.

Re:Netcraft confirms it?! (-1)

Anonymous Coward | about a year and a half ago | (#42926305)

It is now official. Dr. House has confirmed: Netcraft is dying from a terminal SBD.
One more crippling bombshell hit the already beleaguered Netcraft community when IDC confirmed that breakfast burrito ingredient quality has dropped yet again, now down to less than a fraction of 1 percent of a portion. Coming on the heels of a recent (and pornographic) survey which plainly states that an extreme SBD was released, this news serves to reinforce what we've known all along. SBDs are being released every second, as fittingly exemplified by by Netcraft falling dead [samag.com] at the recent Sys Admin fast food party.
You don't need to be the Amazing Kreskin [amazingkreskin.com] to predict the SBD's future. The handwriting is on the stall: SBDs faces a terrible future. In fact there won't be any future at all for nostrils because of deadly SBDs. Things are looking very bad for Netcraft. As many of us are already aware, SBDs continue to waft ever widers. Brown ink flows like a river of blood.
Americans is the most endangered of them all, having lost 93% of its core flatulence isolation. The sudden and unpleasant departures of long SBD moans, layed waste to Jordan Hubbard and Mike Smith, only serving to underscore the calamity. There can no longer be any doubt: Whoever smelt it, should go to a hospital.
Let's keep to the facts and look at the numbers.
SBD leader Theo states that there are 7000 different compounds in the average SBD. How many users SBDs are there? Let's see. The number of SBDs versus non-disgusting posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 SBDs. LBD posts on Usenet are about half of the volume of SBD posts. Therefore there are about 700 LBDs per hour. A recent article put SBDs at about 80 percent of the maximum capacity of the human olfactory glans. Therefore there are (7000+1400+700)*4 = 36400 SBD compounds possible. This is consistent with the number of SBD Usenet posts.
Due to the troubles of Shit Creek, abysmal odours and so on, SBDs went out of their chasms and were taken over by the winds who carry another troubled wiff. Now Netcraft is also dead, its corpse turned over to yet another charnel house of malodorous waste.
All major surveys show that SBDs have steadily expanded to fill the volume of their containers. Breakfast burrito eaters and other releasers of SBDs are very sick and their long term survival prospects are very dim. If we is to survive at all it will be among the cave dwellers or perhaps in space. As ingredients continue to decay, nothing short of a miracle could us at this point in time. For all practical purposes, SBDs are everywhere.

My problem with session cookies... (1, Insightful)

bogaboga (793279) | about a year and a half ago | (#42925179)

I have an issue with the so called, "session cookies."

While they are a part of online the presence, non of their behavior would be stomached in actual day-to-day life.
So the issue is that we've got two set's of paradigms. An online one where you can be tracked by default and a real life
one where you have to be explicitly informed if one is to monitor your every activity.

Sad, indeed.

Re:My problem with session cookies... (4, Informative)

fostware (551290) | about a year and a half ago | (#42925485)

A session cookie is just like a case number, it may be used to speed up communication between departments or sections of your website. Whenever I'm in a queue, there's always a ticket I hold to identify where I am in the queue, what my wait time is, possibly referenced by their third party SLA/QA company, and it could be tied to my Account Number when I get to the counter. It's stomached in real life, because it brings order to what could be chaos, and makes our lives that little bit simpler.

Secondly you must be rather naive to think permission is required to monitor your *every* activity. Through various laws, mutual sharing agreements, and straight greed, there's a wealth of information for people to gather and misuse. While they limit "personally identifiable" information, they gather everything they can and assign it their own ID. It then only takes a little homework to link the ID and your real ID together, and its just this last step which is prohibited in these privacy clauses.

Re:My problem with session cookies... (1)

Runaway1956 (1322357) | about a year and a half ago | (#42927539)

" Whenever I'm in a queue, there's always a ticket I hold to identify where I am in the queue, "

In the US, we don't get into queues. Instead, we just stand in line. No numbers, please. We depend on our ferocious looks plus the possibility that we might be carrying a concealed weapon to hold our place in line. In some cases, people depend on their super great looks, plus the possibility that they might be carrying a concealed weapon. No other identification is needed, thank you.

As for tracking a person in real life, the proper term is "stalking". Again, the possibility that the subject of the stalker might be carrying a concealed weapon tends to discourage that conduct.

Re:My problem with session cookies... (1)

chronokitsune3233 (2170390) | about a year and a half ago | (#42925539)

Sure. Let's just get tracked in real life too. Or maybe we should avoid the tracking and do away with session cookies, thereby logging you out every time you want to make a forum post on the Web. Neither one sounds good, and HTTP needs to be scrapped anyway. It's good at what it does, and that includes the issue with sessions, which is why sessions are so useful to those with malicious intent.

Re:My problem with session cookies... (1)

ArsenneLupin (766289) | about a year and a half ago | (#42926817)

thereby logging you out every time you want to make a forum post on the Web.

Why would that be? If you are logged in, you stay logged in, cookies or not. But then, if you are logged in you can already be tracked by your user credentials, so all this becomes moot...

Re:My problem with session cookies... (1)

chronokitsune3233 (2170390) | about a year and a half ago | (#42928579)

In order to make a post, you need to be logged in, assuming anonymous/guest posts aren't allowed. How does the server keep track of the fact that you're logged in and who you are? Your time spent on that site is called a session, and the server sets a session cookie to say, "Okay, you've already logged in, so I'll save you the trouble of doing it again." Some sites use that information to reveal things like user preferences, which wouldn't ordinarily be available to a guest user.

The only alternative I can think of is the server responding to your log-in action with "Okay, I got your IP address, so I'll just make a note in my database that you logged in from IP address [IPaddr]. This way I can save your information and know who you are." The problem is that means you need to log out when you're done to protect your information if you're on a shared computer, or if you're using a shared Internet connection such as that in a café, people visiting that site for the first time would be already logged in--using your credentials (e.g. if they went to Facebook, they'd be logged in as you). Another issue with that is the fact that IP addresses change.

Sessions have their problems, but ultimately you are the one who says, "Keep track of me," whether that's an implicit request by just logging in or an explicit request by checking a box that says "Remember me" when logging in. The implicit request is considered a convenience to users while the explicit request allows users to control things themselves.

Re:My problem with session cookies... (1)

ArsenneLupin (766289) | about a year and a half ago | (#42929121)

How does the server keep track of the fact that you're logged in and who you are?

By your user name and password.

Your time spent on that site is called a session, and the server sets a session cookie to say, "Okay, you've already logged in,

If you are logged in, the server sees your username and password, then why does it need anything else?

so I'll save you the trouble of doing it again."

Most (all?) browsers only prompt for a username/password a single time, and then keep in in memory for further requests from the same site and realm.

The only alternative I can think of is the server responding to your log-in action with "Okay, I got your IP address, so I'll just make a note in my database that you logged in from IP address [IPaddr].

Why not simply use your login and password?

Re:My problem with session cookies... (1)

chronokitsune3233 (2170390) | about a year and a half ago | (#42932669)

I agree that's perfectly fine, aside from the whole bit about security of saving a password (store it in a secure manner and each time check it against the secure form stored in the user database). How does it save that information in a persistent way that uniquely identifies the computer you're using? That's the role sessions fill. Without the data persistence, refreshing the page would just show you the page as if you weren't logged in. Without the unique identifier (e.g. a session cookie), how does the server know that you're logged in or out in the first place in order to show you something like user preferences instead of a log-in page or error page when you try to visit the user preferences page? An entry in a database perhaps? Sure. Let's go with that. So which computer are you at, and how are you uniquely identified to keep someone on the same connection or even halfway around the world from being served YOUR user preferences page? Sessions fill this role, and to do this, a "cookie" gets created. The cookie acts as a liaison between the server and your computer for the duration of the session that basically identifies your computer in a unique way to prevent the server from serving you or anybody else someone else's user preferences and such.

If this is coming from an "I can SSH to a box and stay logged in just fine" perspective, you're only doing two things in that case: logging in, which spawns a shell or other process presumably, and logging out. With a Web page, you're logging in, but there's no shell or other process that keeps your session alive, so you'd automatically get logged out if it wasn't for something like session cookies.

Re:My problem with session cookies... (1)

ArsenneLupin (766289) | about a year and a half ago | (#42932931)

I agree that's perfectly fine, aside from the whole bit about security of saving a password (store it in a secure manner and each time check it against the secure form stored in the user database). How does it save that information in a persistent way that uniquely identifies the computer you're using?

I guess, in a hash table keyed by hostname and realm? Probably the first browser did it that way in any case, although nowadays it's probably in a more evolved data structure...

Without the data persistence, refreshing the page would just show you the page as if you weren't logged in.

That's why pages are sent with a Vary: Http-Authorization tag. This tell caches, including the one in the browser itself, that they should include authorization in the cache key for the page. This is to avoid that a cached unauthenticated page (or worse: authenticated for a different user...) would show up after the user has been authenticated.

So which computer are you at

Why would the server even care about this at all? As you pointed out in an earlier message, relying on this is fraught with security issues.

With a Web page, you're logging in, but there's no shell or other process that keeps your session alive, so you'd automatically get logged out if it wasn't for something like session cookies.

Wrong. The browser caches the user credentials until you exit the browser, or otherwise log out.

Re:My problem with session cookies... (1)

fatphil (181876) | about a year and a half ago | (#42926839)

A session cookie is little different from a train ticket.
You use it to prove you're someone who's performed some kind of transaction in the past, and it's only valid for a short period of time.

I have a bigger problem with non-session cookies, and third-party cookies. Those you have to carry around for ever, and you have to accept them from and show them to who-the-hell-knows-whom.

Re:My problem with session cookies... (1)

Runaway1956 (1322357) | about a year and a half ago | (#42927579)

Which cookies do you "have to accept"? And, which ones must you keep forever?

I accept few cookies, almost none of those infamous ever-cookies, and they are almost universally deleted when I close my browser.

https://addons.mozilla.org/en-US/firefox/addon/betterprivacy/ [mozilla.org] One among several tools that are useful when preventing trackers from tracking you.

Re:My problem with session cookies... (1)

fatphil (181876) | about a year and a half ago | (#42929091)

My "accept" was from the viewpoint of the very lowest layers of the HTTP communication. You can't stop them being sent to you (except by not loading the payload they're in the headers for). You might chose to bin them and never return them to their sender, which is what I do. But the " Set-Cookie:" line still polutes the HTTP headers, and there's nothing you can do to stop that. If you're accepting the headers and the payload, which you are, then, as by accepting the whole you've accepted all parts, you've accepted the cookie too. It's been sent to you - you read it, you parsed it, you then decided what to to with it. Reword "accept" as "receive" if my terminology perturbs you.

My point is that third-party cookies get flung at you from a seemingly infinite, continually churning, set of domains. I presently have cookies from 12 hosts, but I have a set of "always bin the cookie" rules that's probably a thousand domains long. (My AdBlock and NoScript rules have prevented thousands of other domains from even being able to fling cookies at me, of course.)

Netcraft confirms it! (1)

Anonymous Coward | about a year and a half ago | (#42925251)

With the introduction of LUA, Netcraft confirms that NETBSD is dead because it allows proxy auto-config scripts in the kernal!

Re:Netcraft confirms it! (1)

Anonymous Coward | about a year and a half ago | (#42925295)

I have poured hot grits down my pants. Thank you.

Re:Netcraft confirms it! (2)

Zontar The Mindless (9002) | about a year and a half ago | (#42925807)

Get back to us when you've learnt how to spell "kernel".

Re:Netcraft confirms it! (0)

Anonymous Coward | about a year and a half ago | (#42925947)

KFC's Kernal Sanders is dead, BSD lives.

Re:Netcraft confirms it! (1)

Runaway1956 (1322357) | about a year and a half ago | (#42927607)

Maybe you meant Colonel Sanders? I've little idea what a kernal is, and prior to the advent of computers, the only kernels I ever messed with was the corn on my plate at dinner. I guess there were other kernels back then, but I just didn't have much to do with any of them. Kernel of truth, maybe?

Warhol Billionaires (4, Insightful)

retroworks (652802) | about a year and a half ago | (#42925287)

In the future, everyone will be a billionaire for 15 minutes, until their ill-gained 15 minute life savings is phished by the next billionaire. The bank account hijack will rotate around and around, shared by everyone in the world, boosting all our credit ratings... momentarily.

Re:Warhol Billionaires (0)

Anonymous Coward | about a year and a half ago | (#42925601)

Fuck that noise. I'd have eyeballs on that shit to transfer it elsewhere or withdraw cash sums. I could live til death on 5-10 million. Damn easy to score out of a multi-billion figure.

Re:Warhol Billionaires (1)

Zontar The Mindless (9002) | about a year and a half ago | (#42925811)

Thanks for posting that here, where some unscrupulous writer might want to grab the idea to use for a novel. :)

Re:Warhol Billionaires (1)

hairyfish (1653411) | about a year and a half ago | (#42926703)

Not sure how your bank works, but with mine (multiple banks in different countries), the password only gets you in to view info and some other minor stuff. If you actually want to move money it's a one time only two factor authentication system. Auto proxies aren't much use against this, so I guess I'll be hanging onto my billion dollars a bit longer.

DNSSEC would be nice (4, Interesting)

Anonymous Coward | about a year and a half ago | (#42925313)

It'd be nice if one could bypass the various CA's and enforce HTTP Strict Transport Security (HSTS) as well. I could then have an unlimited number of certificates for my domain and sub-domains. I would see that owning the .com or whatever domain would go up in price though since Verisign and others still want their money somehow and someone still signs the root somewhere.

It'd just be nice to be my own CA for my own domain anyway.

so what should i do? (2)

jehan60188 (2535020) | about a year and a half ago | (#42925345)

avoid banking at work? i always figured that was more secure than at my own home (shared wifi with two room mates- neither seem tech savvy, but you never know.; WPA2 but short password)
it sounds like if my room mates computers are compromised, i can get phished with the method?

Re:so what should i do? (0)

Anonymous Coward | about a year and a half ago | (#42925525)

Verify SHA1 fingerprints. Google the SHA1 fingerprints of the certs in the chain of authority if you don't trust the cert the site seems to present now.

Re:so what should i do? (1)

allo (1728082) | about a year and a half ago | (#42927127)

> Google the SHA1 fingerprints of the certs
next step of the malware: intercept google.

Re:so what should i do? (2)

corychristison (951993) | about a year and a half ago | (#42925677)

If you use Firefox or Chrome, install the HTTPS Everywhere addon by the EFF.
  https://www.eff.org/https-everywhere [eff.org]

Re:so what should i do? (1)

DarwinSurvivor (1752106) | about a year and a half ago | (#42926581)

If your bank even ALLOWS you to log in without https, change banks NOW.

Re:so what should i do? (1)

cffrost (885375) | about a year and a half ago | (#42927515)

If you use Firefox or Chrome, install the HTTPS Everywhere addon by the EFF.

  https://www.eff.org/https-everywhere [eff.org]

I also recommend HTTPS Finder, [google.com] which detects HTTPS-compatible sites and adds them to HTTPS Everywhere's rule-set.

Re:so what should i do? (1)

Runaway1956 (1322357) | about a year and a half ago | (#42927637)

I'd rather have the room mate's compromised computer on the same network, than to use my workplace network. The "IT" guy is clueless. But, he's a relative of one of the bosses, and as a result, he can only move up - not out. Nepotism is alive and well in the business world.

Netcraft (0)

stormpunk (515019) | about a year and a half ago | (#42925563)

I think the bigger story here is that netcraft is still around. I haven't heard "netcraft confirms" in too long.

This why SSL was invented (2)

pcjunky (517872) | about a year and a half ago | (#42925649)

SSL will, if correctly setup, will prevent this. Unless you click through all the warnings your browser shows regarding the sites certificate.

Re:This why SSL was invented (2)

Zontar The Mindless (9002) | about a year and a half ago | (#42925829)

SSL will, if correctly setup, will prevent this. Unless you click through all the warnings your browser shows regarding the sites certificate.

You are aware, I'm sure, that your first sentence is handily negated by the second one?

Re:This why SSL was invented (1)

Anonymous Coward | about a year and a half ago | (#42925859)

As long as one of the hundreds of CAs your browser trusts doesn't make a mistake, sure. But we've seen that some CAs will sign anything. I expect inside jobs at CAs will also become more popular over time.

PGP.... duh (1)

stratigix (1322753) | about a year and a half ago | (#42937419)

One word: PGP

All this talk of SSL and signed certs. Band aids. If every person and corp used PGP none of this would even be a problem would it?
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>