dslreports logo
 
    All Forums Hot Topics Gallery
spc
view:
topics flat nest 
Comments on news posted 2011-08-05 12:23:25: Earlier this year, ICSI researcher Nicholas Weaver told me he and other Berkeley researchers had discovered some strange ISP shenanigans related to search traffic hijacking that went well beyond the traditional DNS Redirection ad services we've talke.. ..

page: 1 · 2 · 3 · next

SkellBasher
Yes Sorto, I'll take my Prozac
join:2000-10-22
Niagara Falls, NY

SkellBasher to openbox9

Member

to openbox9

Re: Paxfire is shady

That's how they're setup, yes, inline with the DNS servers.

It's a terrible solution, and one that I objected to mightily. However, I was overruled by people who sign my checks.
openbox9
Premium Member
join:2004-01-26
71144

openbox9

Premium Member

I can't believe any knowledgeable network security officer would go for something like that.
InfinityDev
join:2005-06-30
USA

InfinityDev to firephoto

Member

to firephoto

side note: Profile your DNS servers

On a side note: profile your DNS servers you plan to use. I use opendns for the extra features like anti-phishing help, but choosing ones that perform better than your ISP's will help.

This utility from SecurityNow podcaster Steve Gibson can help:
»www.grc.com/dns/benchmark.htm
InfinityDev

InfinityDev to kaila

Member

to kaila

Re: Simple solution

Yes, if ISPs are inserted into the SSL certificate chain. Most ISPs don't do this but censored countries and many corporate networks, for example, do this. When in the certificate chain they can proxy SSL traffic silently and eavesdrop on the traffic going through the connection.

"Steve explains why and how world governments are able to legally compel their national SSL Certificate Authorities to issue Intermediate CA certificates which allow agencies of those governments to surreptitiously intercept, decrypt, and monitor secured SSL connections of any and all kinds."

»www.grc.com/sn/sn-243.htm

SkellBasher
Yes Sorto, I'll take my Prozac
join:2000-10-22
Niagara Falls, NY

SkellBasher to openbox9

Member

to openbox9

Re: Paxfire is shady

I laid out the (significant) risks. The owner overruled me, and said to do it anyways. My only option to not put this in place was to quit, and that wasn't an option.

I made significant network changes because of this to ensure that the remainder of the network was protected, and the only things they could reach were walled off from everything else. I also have things setup in such a way that if they do anything I don't like, I can disconnect their equipment within seconds, and move us back to 'clean' DNS infrastructure. I've done this a few times, and Paxfire starts screaming instantly because revenues stop.

It sucks, but unless the bank lets me skip a few mortgage payments, it's what I have to do.

Matt3
All noise, no signal.
Premium Member
join:2003-07-20
Jamestown, NC

Matt3 to DataRiker

Premium Member

to DataRiker

Re: Simple solution

said by DataRiker:

»encrypted.google.com/

I also recommend firefox users try HTTPS-Everywhere

This is done at the DNS layer, SSL doesn't matter.
Matt3

Matt3 to firephoto

Premium Member

to firephoto

Re: Don't use ISP DNS

said by firephoto:

Use a public DNS server and don't fall for the tricks from the ISP that make you think you need to use their DNS.

Excellent suggestion for stopping this type of hijacking.
zefie
join:2007-07-18
Hudson, NY

1 edit

zefie to DataRiker

Member

to DataRiker

Re: Simple solution

Just installed it. Irony is this site fails it. At least for me.

secure.dslreports.com uses an invalid security certificate.

The certificate is not trusted because no issuer chain was provided.

(Error code: sec_error_unknown_issuer)

Edit: Oddly only Firefox (v5.0.1, fresh install) is doing it.

thedragonmas
Premium Member
join:2007-12-28
Albany, GA

thedragonmas to birdfeedr

Premium Member

to birdfeedr

Re: Questions answered in this thread...

is this what mediacom has been doing?
»Mediacom redirect service-opted out, still hijacks searches..
rahvin112
join:2002-05-24
Sandy, UT

rahvin112 to InfinityDev

Member

to InfinityDev

Re: Simple solution

There is a solution though. It's called TOR and it allows encrypted traffic to proxy servers through which you can browse the regular internet. I'm not aware of any exploit against TOR at this time that would allow man-in-the middle as it doesn't use the SSL chain of trust. Though there is speculation that if a government provided a proxy node they could potentially identify some users. The probability is extremely low that this would succeed due to the onion routing, though it is technically possible. The only issue to deal with is that TOR is slow (because of the onion routing). TOR has been a documented resource in allowing people in oppressive totalitarian regimes to bypass the censorship regimes and provide real information flow.

The beauty of TOR over generalized proxy's is that the traffic is routed through multiple proxies before source and destination, thus shielding both sides from oppressive government (or ISP in this case) action.
nweaver
join:2010-01-13
Napa, CA

nweaver to thedragonmas

Member

to thedragonmas

Re: Questions answered in this thread...

No.

Mediacom is/was doing in-path HTTP 404 rewriting using a deep-packet-inspection device, where the device detects that the response was a 404 and replaces the response with a JavaScript redirect to an Infospace search page. We detect this behavior and generate an alert when we see it.

They also were apparently changing results when searches were generated by the search bar. We don't detect this behavior (yet).
rahvin112
join:2002-05-24
Sandy, UT

rahvin112 to zefie

Member

to zefie

Re: Simple solution

Firefox 5 invalidated a certain SSL certificate provider that is known to issue certificates without validating domain ownership. That's likely the issue here as my own certificate was bitten by this. The issuer in question is the lowest price issuer of SSL certificates (probably because they don't do any validation). You can issue individual exceptions for these certificates but I would verify that the certificate in question is for the actual site (verify the IP and DNS records) before doing so.
rahvin112

rahvin112 to nweaver

Member

to nweaver

Re: Questions answered in this thread...

According to the article the issue in this case is that the providers are using deep packet inspection to reroute search results on certain search providers to paid results. The only way to avoid this is encryption and only if they don't MITM (man in the middle) the SSL connection and have free access to your encrypted connections.

This is EXACTLY this issue that created the net-neutrality debate that so many people don't understand. The ISP has free reign over your connection and people don't even realize how badly they could interfere without your knowledge.
zefie
join:2007-07-18
Hudson, NY

zefie to rahvin112

Member

to rahvin112

Re: Simple solution

Or maybe Verizon was doing something shady.. because oddly after reading your post I re-enabled this site in the extension, ready to manually except it, but to my surprise, it is not throwing the error anymore. Hmm.
waynemr
join:2002-01-28
Madison, WI

waynemr to nweaver

Member

to nweaver

Re: Questions answered in this thread...

How about going on the offensive to poison the data being gathered?

Perhaps some sort of plugin for common browsers that takes your search queries, mangles them, then submits them to a central clearinghouse of crapped-up search queries. That clearinghouse - through some sort of random submission process over multiple addresses would submit the garbage data to addresses known to submit data to Paxfire.

If Paxfire's data is compromised - other companies won't trust it and will stop using it. Likewise, if data indicated a company submitting data to Paxfire was gaming the system (for example to inflate ad-view numbers/payments) then Paxfire might drop them.

Outside of some kind of software system to poison the data, a viral, social-network campaign to monkey with query data would work too. For example, get 10,000 people on a particular network to all submit the same exact query 5 times over a 24 hour period, causing a weird data-spike for Paxfire.

Come to think of it, large bot-net owners could rent their bot-nets to shape query results for or against products - or artificially inflate ad-views for an ISP subscribing to Paxfire's services.

funchords
Hello
MVM
join:2001-03-11
Yarmouth Port, MA

funchords

MVM

Congrats to Nick and Team

Congrats and thanks to nweaver and the rest of the folks involved in uncovering this!

cdru
Go Colts
MVM
join:2003-05-14
Fort Wayne, IN

cdru to Matt3

MVM

to Matt3

Re: Simple solution

said by Matt3:

This is done at the DNS layer, SSL doesn't matter.

With SSL though, the ISP isn't going to know what the user is searching for to proxy the results. It's also encrypted by google so they can't alter/inject their own results back. And if they redirect all traffic going to https google to their spoofed proxy site that looks like https google, the real certs won't be valid.

Matt3
All noise, no signal.
Premium Member
join:2003-07-20
Jamestown, NC

Matt3 to rahvin112

Premium Member

to rahvin112
said by rahvin112:

There is a solution though. It's called TOR and it allows encrypted traffic to proxy servers through which you can browse the regular internet. I'm not aware of any exploit against TOR at this time that would allow man-in-the middle as it doesn't use the SSL chain of trust.

Tor is no solution, asshat torrenters and child pornographers have ruined the network.

As far as exploits, why, a simple Google search shows there is in fact an easy way to perform a man-in-the-middle attack, even of SSL encrypted traffic.
said by article :
He then mentioned all the passwords, and credit card numbers that SSLstrip was able to pull from Tor users and save in plain text (You don’t shop using Tor do you?).


»www.google.com/search?rl ··· e-middle

Sabre
Di relung hatiku bernyanyi bidadari
join:2005-05-17

Sabre to SkellBasher

Member

to SkellBasher

Re: Paxfire is shady

Wish I could offer you a fallback job so you could take them down and quit. At least you're out there doing the best you can. Good job trying to keep them (semi)honest.

Matt3
All noise, no signal.
Premium Member
join:2003-07-20
Jamestown, NC

Matt3 to cdru

Premium Member

to cdru

Re: Simple solution

said by cdru:

said by Matt3:

This is done at the DNS layer, SSL doesn't matter.

With SSL though, the ISP isn't going to know what the user is searching for to proxy the results. It's also encrypted by google so they can't alter/inject their own results back. And if they redirect all traffic going to https google to their spoofed proxy site that looks like https google, the real certs won't be valid.

They can easily act as a man-in-the-middle SSL proxy and your browser would be none the wiser. You have to go much lower on the OSI model to prevent this type of hijacking, think network or transport layer, not the session or application layer.

NetFixer
From My Cold Dead Hands
Premium Member
join:2004-06-24
The Boro
Netgear CM500
Pace 5268AC
TRENDnet TEW-829DRU

NetFixer to rahvin112

Premium Member

to rahvin112

Re: Questions answered in this thread...

said by rahvin112:

According to the article the issue in this case is that the providers are using deep packet inspection to reroute search results on certain search providers to paid results. The only way to avoid this is encryption and only if they don't MITM (man in the middle) the SSL connection and have free access to your encrypted connections.

This is EXACTLY this issue that created the net-neutrality debate that so many people don't understand. The ISP has free reign over your connection and people don't even realize how badly they could interfere without your knowledge.

That was also my intrepretation of the article, but since nweaver See Profile is supposed to know exactly what is being tested and/or intercepted, perhaps the article is in error?

cdru
Go Colts
MVM
join:2003-05-14
Fort Wayne, IN

cdru to Matt3

MVM

to Matt3

Re: Simple solution

said by Matt3:

They can easily act as a man-in-the-middle SSL proxy and your browser would be none the wiser. You have to go much lower on the OSI model to prevent this type of hijacking, think network or transport layer, not the session or application layer.

Can you please elaborate? I won't say that you're wrong, but I don't think your right.

Taking google for instance, presuming that google has a properly installed certificate, the certificate is signed by a trusted CA, and you are actually visiting the correct URL (and haven't been redirected to g00g1e.com, I don't see how a MITM attack would be possible. The presentation of any spoofed certificates would not be signed by a CA and/or match up to the host name, all up to date modern browsers would alert you to this immediately.

If this was possible, it would mean the break down of the entire eCommerce infrastructure due to the insecurity of the transactions.

gme
@ada5ab81.net

gme

Anon

Google may have a very valid SSL certificate (from VeriSign even), but the way an SSL MiTM attack works is that the SSL proxy intercepts your HTTPS request, breaks it, and then forwards it on to Google (for example).

What the proxy sends to YOU (and your browser) is a completely separate encrypted SSL page, and your little lock still shows, because the SSL proxy is using a certificate that is trusted in your certificate store.

Countries like Saudi Arabia, Iran, and China, can do this because their country-level CAs are in everyone's browser (bring up certmgr.msc if you're on Windows).

Since the root is universally trusted, the root CAs can issue bogus intermediate certs via their own CAs, forging the legitimate certs to your browser.

You mention the breakdown of eCommerce as we know it, and you're absolutely correct.

SSL has been the worst thing to happen to the Internet.

Not because of the technology, but because of the false sense of security it provides.

Steve
I know your IP address

join:2001-03-10
Tustin, CA

1 recommendation

Steve to Matt3

to Matt3
said by Matt3:

They can easily act as a man-in-the-middle SSL proxy and your browser would be none the wiser.

SSL cannot be proxied in this way without setting off alarm bells in the browser due to cert name mismatches.

MxxCon
join:1999-11-19
Brooklyn, NY
ARRIS TM822
Actiontec MI424WR Rev. I

MxxCon to rahvin112

Member

to rahvin112
Tor is not a solution, it's a workaround. Using Tor you'd bypass your ISPs hijacking, but you have no idea if the exit node you picked has a similar hijacking ISP.
The only way to protect against this kind of hijacking is https or perhaps IP-level authentication that I think IPv6 can provide.
rahvin112
join:2002-05-24
Sandy, UT

rahvin112 to NetFixer

Member

to NetFixer

Re: Questions answered in this thread...

Ah, I see that now. I'm curious, if it's deep packet inspection how does changing DNS server avoid it? Unless the appliance in question only responds to DNS requests that is, but then I don't see how it could alter search results because a DNS request isn't going to include search form submissions unless the providers network is broken.

Matt3
All noise, no signal.
Premium Member
join:2003-07-20
Jamestown, NC

Matt3 to Steve

Premium Member

to Steve

Re: Simple solution

said by Steve:

said by Matt3:

They can easily act as a man-in-the-middle SSL proxy and your browser would be none the wiser.

SSL cannot be proxied in this way without setting off alarm bells in the browser due to cert name mismatches.

Cert name mismatches are easy to overcome, you simply spoof the name of the URL with a fake cert. It's the chain to the intermediate and/or root certificate that is stored in the browser or local computer's certificate store that I'm not quite sure how they'd work around ... without compromising and delivering an intermediate cert to the browser or OS trust store.

Bruce Schneier has a good summation from April of 2010 of one way to do this, readily built into an appliance. The comments are worth reading as well.

»www.schneier.com/blog/ar ··· d_2.html
quote:
Although current browsers don't ordinarily detect unusual or suspiciously changed certificates, there's no fundamental reason they couldn't (and the Soghoian/Stamm paper proposes a Firefox plugin to do just that). In any case, there's no reliable way for the wiretapper to know in advance whether the target will be alerted by a browser that scrutinizes new certificates.
Matt3

Matt3 to gme

Premium Member

to gme
said by gme :

Google may have a very valid SSL certificate (from VeriSign even), but the way an SSL MiTM attack works is that the SSL proxy intercepts your HTTPS request, breaks it, and then forwards it on to Google (for example).

What the proxy sends to YOU (and your browser) is a completely separate encrypted SSL page, and your little lock still shows, because the SSL proxy is using a certificate that is trusted in your certificate store.

Countries like Saudi Arabia, Iran, and China, can do this because their country-level CAs are in everyone's browser (bring up certmgr.msc if you're on Windows).

Since the root is universally trusted, the root CAs can issue bogus intermediate certs via their own CAs, forging the legitimate certs to your browser.

You mention the breakdown of eCommerce as we know it, and you're absolutely correct.

SSL has been the worst thing to happen to the Internet.

Not because of the technology, but because of the false sense of security it provides.

This is a very good explanation and is inline with what I have read about SSL man-in-the-middle attacks. The crux seems to be that in most modern certificate stores (be it Firefox's internal or the one in Windows) there are simply too many trusted root/intermediate certificates that are valid for 10+ years.

All it takes is one relatively common cert to be exploited and you could build a spying business off it ... while working on the next one to compromise to extend your business another 10 years.
Matt3

Matt3 to zefie

Premium Member

to zefie
said by zefie:

Or maybe Verizon was doing something shady.. because oddly after reading your post I re-enabled this site in the extension, ready to manually except it, but to my surprise, it is not throwing the error anymore. Hmm.

I get random cert errors from this site when I log in from different devices. Seems to be browser based.
Matt3

Matt3 to rahvin112

Premium Member

to rahvin112

Re: Questions answered in this thread...

said by rahvin112:

Ah, I see that now. I'm curious, if it's deep packet inspection how does changing DNS server avoid it? Unless the appliance in question only responds to DNS requests that is, but then I don't see how it could alter search results because a DNS request isn't going to include search form submissions unless the providers network is broken.

As the article mentions, that's where specific "keywords" and URLs come into play.

nweaver See Profile, please correct me if I am wrong, but I would think if the Paxfire appliance or software knows you are sending a DNS request to Google, they simply return an IP they own, pointing to a web server they control, read your form submission, then alter the traffic as they see fit ... exactly like OpenDNS currently does for all Google searches?
page: 1 · 2 · 3 · next