Correct me if Im wrong but it would seem this member is participating in DNS hijacking.

Today I was logging into online banking via our community internet WIFI (shared by 30+ houses) and my browser presented me with https certificate warnings saying the certificate presented belong to www.polycache.com (which has the SSL cert) and www.gate-logic.com (alised) both of which resolve to the address shown. Thinking logically I believe only way this could happen is if he/she has locally (at our DSL modem) routed the IP to their linode?

The whois information on both domains is protected. Both sites show empty content.

li277-248.members.linode.com

Can any of the gurus offer any paths of research or explanation? A router blip?

Polycache seems to have different geographical resolves. Changed IP when resolved via Google DNS.

ping www.polycache.com
PING www.polycache.com (66.228.34.162) 56(84) bytes of data.
64 bytes from li284-162.members.linode.com (66.228.34.162): icmp_req=1 ttl=38 time=370 ms
64 bytes from li284-162.members.linode.com (66.228.34.162): icmp_req=2 ttl=38 time=359 ms

Is this a legitmate caching network? Still dont understand how it was able to intercept my SSL communication with the bank, thankfully browser warning prevent any man in the middle of https but who knows for http

Without knowing the host name of the online banking site involved, there's not much checking we can do to assist, nor to determine if the erroneous information is just local to you. Certainly the key question is to try to determine where you are receiving the (presumably wrong) addresses back from those host names.

How is DNS handled in your community Wifi environment? Is there a shared cache that could have accidentally gotten polluted or been misconfigured? The issue could certainly be malicious, but its also at least possible its an innocent error (including, for example, a typo in a DNS update by the banking site itself). It's even possible that the polycache host is intended to be legitimately involved in the service you are using, and the certificate error is the current mistake. Probably not, but not enough data to say for sure.

I would certainly do some testing with a tool such as dig to see if you could determine who is returning the address for your banking host name. Do you get the different (ala proper) addresses if you bypass any local shared cache or intermediate servers.

-- David

PS: The polycache/gate-logic hostnames appear to be served in DNS by dynect, which I believe is DynDNS' enterprise DNS platform which includes a lot of dynamic features, so not surprising that they may adjust either dynamically or over time.

Further digging.

It would seem our community wifi is using an OpenWRT router on the edge which is vunerable to DNS rebinding attack. I nmaped it remotely and it exposes a web and telnet interface wan side which is never a good sign. The staff here dont speak English so trying to explain something to them will be difficult, once they explain, trying to get them to accept something is wrong will be even more difficult (cultural face).

It would seem our router has been targeted along with millions of others, probably automagically by a bot.

Im taking a punt, that polycache and gate-logic (multiple linodes) etc.. are the intercepting nodes, they have multiple Linodes at different geographical locations all presenting same cert.



The issue isnt who serves their DNS as their DNS servers would not of been contacted. Whats happening (not sure exactly the means yet) is they are hijacking our tcp session but due to https cert name mismatch FF4 blocked it thankfully.

Ive flushed my DNS cache and tunneling everything via VPS for now.

Im not sure what more evidence I can gather as I tried it just now non tunneling and it seems back to normal. But Im willing to wager these nodes will be shutdown pretty soon once someone presents some more evidence. Any linode staff watching I know this isnt enough to challenge under the abuse policy but just a heads up. li277-248.members.linode.com - maybe you can contact them to clarify their Linode use or at least ask them for some ID

Thinking about it they are being quite clever using polycache.com (a domain registered a few weeks ago and using domain privacy whois), some people will think its a transparent caching service used by the ISP etc..

I reported it to abuse as this has got scam written all over it to monitor, this a filmsy report, but it wont be the last..

This part doesn't really make sense if it's a DNS attack. There's no need to do anything at the TCP level - as long as they give you their replacement IP address in response to a DNS lookup, all routing past that point is perfectly normal.

Unless you're referring to the DNS lookup itself, though that typically uses UDP.

It would still help if you'd indicate what host you are contacting, since then others could check DNS results elsewhere. If it's an online banking site, I can't imagine the host name is a secret or anything.

-- David

Okay lets start a fresh, DNS hijacking probably isnt the correct term, but Im not trying to resolve polycache or the other one so Im not contacting their DNS server.

I visited the landing page of:
https://www.mybank.alliance-leicester.c ... krhnlogin&

I doubt my bank or its DNS has been compromised, I highly suspect our shared router has in some form and this where polycache are attempting to steal information.

With regards to the bank, the first page loaded correctly, padlock in place, all green.

When I went to submit my login ID it forwards to another page on same hostname/protocol (supposedly). This is where Firefox4 prompt that the certificate presented was www.polycache.com and would I like to proceed with submitting the information. Obviously I didn't.

I went investigating polycache.com and found they have multiple Linode nodes depending on where you resolve their domain from, that what their DNS provider is providing - geographical resolution - no problem with that, dont care if thats faultly/malicious/perfect as Im not attempting to resolve their domain. Each Linode they own presents the same cert. This purely just info.

What I suspect is happening is they probing any vunerable OpenWRT router, our condo has shared wifi and I see our public WAN ip is listening on port IP with an OpenWRT page. I believe they are compromising vunerable OpenWRT routers and doing something malicious.

At first I though dns spoofing, but because the first page loaded correctly and IP resolves correctly via nslookup/dig I dont think its that simple. The attacks I've read about are to let the first page on https site load and on that page inject some javascript to violate cross domain policy stuff on older browsers (doesnt make sense yet to me). Alternatively they selectively hijack certain sessions, e.g. on next request we'll nag that session (and obviously have to present their own SSL). Something isn't right.

I dont have access to router to give more info. I live in Thailand so trying to get the condo management to do anything is impossible, trying to get them to accept they are wrong in any form is even more impossible.

Well, best I can tell it appears to be happening at the source, so independent of anything else, I'd definitely let your bank know. I don't think it's your local router, as I see a reference to polycache at that URL too, and I'm coming from NY.

That URL returns a page that has an inline script that injects a script reference to (a) which when it runs in turn injects a reference to (b). That's where the polycache.com name gets involved, with a regular DNS lookup - no routing trickery. And yes, that javascript file definitely looks odd (even minimized) as it has a bunch of bank names embedded.

Now, my browser doesn't even load the papi Javascript (it does load splash.js as that site uses a self-signed certificate) during the page load. I haven't tried to expand the javascript, but one guess would be it lays a transparent frame over the actual page so when you click you're taken to (or through) the other site. It's at that point that your browser complains about the certificate.

Since the original DNS lookup for your bank's host appears to return an address from the right block, and since retrieving the URL at that location (over an SSL link secured by what appears to be a legitimate certificate) from that server includes the various javascript references, I suspect something was breached on the server side. Either that or it's intentional behavior with a bad certificate in place. Given how the scripts inject the javascript references I have a hard time believing its intentional, but who knows.

But aside from the original data from the bank web server, I think your browser, and the routers, are just working properly and contacting whom they've been told to.

Definitely time to talk to the bank :-) And if they determine this isn't just an actual bank "tracking" scheme that suddenly became visible due to a bad certificate, definitely pass this along to Linode too.

You might be able to get past this by disabling Javascript first. If the bank site won't work without it, at least you might be able to log in and then re-enable before performing operations.

-- David

(a) https://www.advanced-web-analytics.com/18557/splash.js
(b) https://www.polycache.com/18557/papi.js

BTW, one important point about the above. The green padlock (or any SSL indication) only says that your browser trusts the authority who signed the certificate that is in use at the host you contacted.

It says nothing about the validity of the actual data you've just received over that connection, so bad data will come across just as well over an SSL connection as a non-SSL connection if the data is corrupt at the source.

Nor, in fact, does it even assure you that you are talking to who you think you are. In the presence of an actual DNS hijack, an SSL connection can easily be subject to a man-in-the-middle attack. In fact i've used this fact to help manage an email transition recently where I wanted to monitor people using the old server, though in that case since I owned the DNS it wasn't properly a hijack. But I inserted my own server in the middle of an SSL connection to a third party email provider without it being apparent to employees.

-- David

Well it turns out it is malicious.

http://stackoverflow.com/questions/5711 ... sed-closed

A&L / Santander has been hacked.

Ignore the references to dns hijacking and man in the middle and openwrt, that was a dead trail.

I would forward that post and this thread to abuse@linode.com just in case staff aren't reading this thread. Looks like a pretty clear case of malicious linode user.

Also contact your bank, because they gotta fix this and the more people complaining, the better.

-- from finextra.com, Santander denies online banking hack, 19 April 2011


"This is currently being investigated further. However, Santander can confirm that neither its website nor the A&L website have been hacked and customer data has not been compromised."

So they say a third party had the problem. So freaking what, it's still your fault whether you got hacked or your contracted party got hacked, you chose a crappy third party and put your customers at risk.

All,

I think we should perhaps take a step back here, not that I believe a bank (and who would), but there were 2 issues that began all of this and are answers seem to have been disconnected from the issue;

1. An invalid cert
2. A URL which was unrecognized

The cert issue is fairly commonplace and looking at it at the time, it seemed a reasonably simple domain cert miss-match.

The URL has then also been confirmed as genuine by A&L.

Given the banks confirmation of the URL, I find it highly unlikely that someone has used a analytics function to exploit an online service. For a start, why make it that obvious, you can infect a users machine so easily, you need not be so bold and you can guarantee security details are not being sent by the bank to a 3rd party in the clear.

As you can probably guess by my tone, I am yet to see anything that confirms a hack of any type and certainly nothing that displays an exposure of customers to compromise.
The Stack Overflow reactions / answers showed a lack of knowledge and tendency to overreact. Don't want to see this thread go the same way.