4 ms·
Here are some ways to modify traffic on typical networks, most have command-line or GUI point-and-click attack tools available. Some of these are documented to
by marshray 15y ago
Here are some ways to modify traffic on typical networks, most have command-line or GUI point-and-click attack tools available. Some of these are documented to have been conducted on wide blocks of internet traffic.
The attacker broadcasts a SSID of 'Free Public Wifi', or one similar to what you normally use, then DoSes all other access points when you try to use them.
The attacker is on the same ethernet broadcast domain and replies to your DHCP query quicker than the legitimate DHCP server does.
The attacker poisons the router's ARP cache and impersonates your MAC.
The attacker leverages the unauthenticated nature of Spanning Tree Protocol STP.
The attacker pwns your home wifi router through a default password on its admin page or any number of other bugs.
The attacker messes with your DNS name resolution for sites of interest. Remember that time DNS resolution for some S. American (and a few US) ISPs got routed through the great firewall of China?
The attacker advertises a more-specific route for your IP address or that of a target site. Remember when that little ISP in Pakistan took YouTube offline?
The attacker could be your ISP working under order of some government. Yours, that of a country you're visiting, or of some territory the packets pass through along the way.
Or you could be using a hotel, airplane, library, mobile, etc. internet connection where transparent intercepting MitM proxies are standard fare. How good do you think the hotel staff are at securing that internet billing appliance they bought?
And of course, the attacker could always cut a cable somewhere and install a tap.
- lawnchair_larry 15y agoThe BGP examples are a little far fetched. Few adversaries have that capability, and when someone fucks with BGP, the world knows about it.
- tptacek 15y agoWow is that ever far from true.
- bonzoesc 15y agoThat was DEF CON 17 when somebody BGP'd the whole LAN through their datacenter in NYC, right?
- marshray 15y agoJust about every ISP in the world, from the backbone providers to small ISPs in Pakistan, has the capability. More often than not, it happens by 'accident'. http://www.renesys.com/blog/2008/02/pakistan_hijacks_youtube_1.shtml http://www.renesys.com/blog/2008/02/pakistan_hijacks_youtube... If you were very selective about it, and pulled it off without any disruption, you could get away without anyone noticing. Or, do it from a third-world ISP, and say "It was an accident whaduyagonnadoaboutit".
- amalcon 15y agoIf there are big BGP changes, the world notices. If the BGP for the specific netblock your site is hosted on changes, the world probably does not notice. Your users will see slightly degraded performance (actually, in some cases it will improve), and (presumably) a number in the NSA will be <1% higher for a few minutes, but that's about it. I've worked on software that literally (intentionally) publishes BGP updates every ~10 seconds. It didn't bother anyone, because it wasn't playing with many addresses.
- tptacek 15y agoNow to understand why I like HTTPS/TLS so much: Do all of these things. You still can't break my secure HTTPS channel to Amazon.com.
- marshray 15y agoWell, at least not after they patched for CVE-2009-3555.
- tptacek 15y agoWas Amazon ever vulnerable to session resumption attacks? How? Either way: every vulnerability we've found in SSL/TLS (the protocol) makes me more confident in it. Those findings are the product of millions of dollars of attention. Why would we think that any alternative to TLS wouldn't have the same flaws, or worse ones?
- marshray 15y agoWas Amazon ever vulnerable to session resumption attacks? I have no direct knowledge. I was personally extremely careful to never test any actual sites. But unless they were running MS IIS or certain brands of SSL offload devices on every accessible host with the cert on it, they were likely willing to conduct client-initiated renegotiation. I know they use client certs for EC2 stuff, that likely involves a server-initiated renegotiation opportunity as well. Just checked, they still haven't patched for the actual protocol fix, RFC 5746 How? Frank Heidt came up with an awesome little exploit that isn't affected by anti-CSRF mitigations. Just find one single URL under HTTPS which redirects to HTTP. (E.g., https://www.amazon.com/ https://www.amazon.com/) Inject a request to that and now you have a plain HTTP request to play with. You could enter an sslstrip scenario, replace the cert with a legitimate cert to a phishing site at a point the user isn't expecting the URL to change. How many users stop browsing after receiving a mixed content warning I wonder? Other researchers showed you could replace the EV cert with a simple DV cert at that stage and the browser would still show the green bar. Either way: every vulnerability we've found in SSL/TLS (the protocol) makes me more confident in it. Those findings are the product of millions of dollars of attention. Why would we think that any alternative to TLS wouldn't have the same flaws, or worse ones? Absolutely. Those who criticize TLS need to understand why it is the way it is and either propose improvements (the IETF [TLS] mailing list is open) or propose a replacement that really does a better job delivering on all the security properties, not just one or two.
- amalcon 15y agoI should clarify: those are the three scenarios I could come up with that allow snooping but not MitM.