SkellBasherYes Sorto, I'll take my Prozac join:2000-10-22 Niagara Falls, NY |
to openbox9
Re: Paxfire is shadyThat'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
2011-Aug-5 1:16 pm
I can't believe any knowledgeable network security officer would go for something like that. |
|
|
to firephoto
side note: Profile your DNS serversOn 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 |
to kaila
Re: Simple solutionYes, 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 |
|
|
SkellBasherYes Sorto, I'll take my Prozac join:2000-10-22 Niagara Falls, NY |
to openbox9
Re: Paxfire is shadyI 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. |
|
|
Matt3All noise, no signal. Premium Member join:2003-07-20 Jamestown, NC |
to DataRiker
Re: Simple solutionThis is done at the DNS layer, SSL doesn't matter. |
|
Matt3 |
to firephoto
Re: Don't use ISP DNSsaid 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 |
to DataRiker
Re: Simple solutionJust 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. |
|
|
to birdfeedr
Re: Questions answered in this thread... |
|
|
to InfinityDev
Re: Simple solutionThere 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. |
|
|
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). |
|
|
to zefie
Re: Simple solutionFirefox 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 |
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 |
to rahvin112
Re: Simple solutionOr 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. |
|
|
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. |
|
funchordsHello MVM join:2001-03-11 Yarmouth Port, MA |
Congrats to Nick and TeamCongrats and thanks to nweaver and the rest of the folks involved in uncovering this! |
|
cdruGo Colts MVM join:2003-05-14 Fort Wayne, IN |
to Matt3
Re: Simple solutionsaid 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. |
|
Matt3All noise, no signal. Premium Member join:2003-07-20 Jamestown, NC |
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 dont shop using Tor do you?).
» www.google.com/search?rl ··· e-middle |
|
SabreDi relung hatiku bernyanyi bidadari join:2005-05-17 |
to SkellBasher
Re: Paxfire is shadyWish 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. |
|
Matt3All noise, no signal. Premium Member join:2003-07-20 Jamestown, NC |
Matt3 to cdru
Premium Member
2011-Aug-5 2:47 pm
to cdru
Re: Simple solutionsaid 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. |
|
NetFixerFrom My Cold Dead Hands Premium Member join:2004-06-24 The Boro Netgear CM500 Pace 5268AC TRENDnet TEW-829DRU
|
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 is supposed to know exactly what is being tested and/or intercepted, perhaps the article is in error? |
|
cdruGo Colts MVM join:2003-05-14 Fort Wayne, IN |
to Matt3
Re: Simple solutionsaid 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
2011-Aug-5 4:13 pm
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. |
|
SteveI know your IP address
join:2001-03-10 Tustin, CA
1 recommendation |
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
|
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. |
|
|
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. |
|
Matt3All noise, no signal. Premium Member join:2003-07-20 Jamestown, NC |
to Steve
Re: Simple solutionsaid 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.htmlquote: 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
2011-Aug-5 7:06 pm
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 |
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 |
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 , 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? |
|