« April 2008 | Main

May 10, 2008

Red Carpet Club WiFi

Danny McPherson posts about his experience with the free WiFi in the Unied Red Carpet Club:
More interesting is perhaps the access model they employ. To login, all you need is the United Mileage Plus number of the primary Red Carpet Club account holder. Now, having long questioned the wisdom of a luggage tag that displays these numbers, be it a "hole-punched" Mileage Plus membership card, or a more obvious oval-shaped Red Carpet Club tag, I'm even more wary now. But if you're in bind and need your airport wireless fix, odds are you won't have to walk far to find one available for the taking. As a matter of fact, I see two from where I'm sitting right now.

I've yet to explore how difficult it would be to exhaustive search for valid numbers, or if multiple logins are permitted at a given time, or how far outside of the Red Carpet Club these numbers are valid, or... I also wonder how long it'll be until some poor schmuck is arrested for allegedly downloading child porn from an airport wireless network...

If this were a wired network this wouldn't be a security problem. After all, if you're inside the RCC, presumably you're an RCC member (unless you bought a day pass), in which case you should be entitled to use the network. But as Danny indicates, the wireless AP is probably accessible from outside the RCC, so if you sit outside the club, you should be able to get on the network, making it just a matter of having a valid mileage plus number, which you can get off of someone's luggage tag.

As far as exhaustive search goes, MP numbers are 11 digits long, but the first digit seems to always be zero, so this is a 10 digit space. I don't know how many RCC members there are, but Wikipedia claims that there are about 750,000 Premier and Premier Executive members, so let's say there are on the order of 200,000 RCC members, or 2*10^{-5} of the space. If the numbers are randomly distributed, you'd need to search about 100,000 numbers in order to find one. This could take quite some time (over a day at one per second). You might be able to get some leverage because the distribution isn't random. They seem to be issued in some kind of increasing sequence, though there seem to be too many numbers for it to be strictly sequential. If there's a check digit like in credit card numbers this would make the space a lot easier to search. (If someone knows the actual algorithm, please write in.) Of course, you only need to know a few valid numbers, so this might not be a totally prohibitive attack if reading it off someone's tag weren't so easy.

Three more thoughts:

1 See draft-rescorla-stateless-tokens for a description of some techniques for avoiding the need for a centralized cookie database.

Posted by ekr at 8:56 PM | Comments (2)

May 9, 2008

Notes on P2P Blocking and Evasion

In preparation for the IETF P2P Infrastructure Workshop, I've revised and expanded this post into a "position paper submission.

Introduction

In mid-2007 it was revealed [4] that Comcast was blocking peer-to-peer traffic (most famously BitTorrent) on their network by injecting RST packets to terminate TCP [7] connections. The BitTorrent community almost immediately discovered carrying BitTorrent over an encrypted tunnel (VPN or SSH) was not subject to blocking, thus completing another cycle of the ongoing arms race between peer-to-peer implementors and network operators. This paper explores some predictable next moves in the game and their consequences for the network.

This isn't intended to be comprehensive, because the request was for short papers, but I think it hits the high points. You can find the full note here.

Posted by ekr at 10:19 AM | Comments (0)

May 8, 2008

MS Word wants to open a port on your machine... wait what?

Even the most diehard TeXhead has moments when he needs to read some Word document. Tonight was such a night and I have Office 2004 on my machine for just such an eventuality (Please don't write in to tell me that I should run Pages. As I said, I don't want to run either of them, but I also don't want to deal with Pages/Word incompatibility.) Anyway, I boot up Word and the Leopard firewall asks me if I'd like to let Word listen for network connections. I go to click no and either manage to click it or raise some other window or something. The dialog disappears and when I check the firewall it sure does say to block MS Word. So, that's OK, I guess.

And then I get to thinking, "Why is Word opening up TCP listening ports anyway?" So, I run netstat -a | grep LISTEN and get: 

[49] /usr/sbin/netstat -a | grep LISTEN
tcp4       0      0  *.3369                 *.*                    LISTEN
...

Hmmm. What's 3369? Google doesn't know, so that's not good. I close Word and the port goes away and lsof confirms it's Word: 

[52] /usr/sbin/lsof -i TCP:3369

COMMAND  PID USER   FD   TYPE    DEVICE SIZE/OFF NODE NAME
Word    8198  ekr   16u  IPv4 0x6c4d66c      0t0  TCP *:3369 (LISTEN)

I shut down Word and my WiFi and restart it, but it's not listening now. Maybe I need the network on. Sure enough, I bring the WiFi back up and restart Word and now it's listening, but on a different port: 3828 this time. Stranger and stranger. Now ordinarily this would only be about a 4.0 freakout on a scale of 1 to 10, but it turns out that I only recently installed Office on this machine and was unaware of the following delightful property of MS AutoUpdate: it only installs one update at a time, no matter how many updates are pending. So, when you have 10-20 updates to install, and you're just letting update run itself, it takes forever to get uprev. The consequence of this is that I was loading random people's documents with some two year old (and vulnerable) version of Word. Who knows what malware I've had the joy of installing. This jacks things up to a freakout factor of about 6.2.

Next step: compare to another machine. It shows up on my other Mac, which is a little comforting, but of course that machine could be infected too. I double check with Hovav, who is about as paranoid as I am, and his copy of Office is is listening, but on some other random port. That's sort of comforting. This is starting to look a lot less like malware and a lot more like a feature of Word. A little more digging tells us the process name that is actually doing the listening. It's Word (as I knew) but with some wacky argument starting with -psn_0_.... Searching on this, we find out that I'm not the only person who has had this question.

If you close UDP 2222, then no other computers will know which TCP port your copy of word has chosen to listen to (in the 3000-3999 range), because that info is broadcasted in the UDP packets. The protocol is thus: Your copy of word spews it's serial number (encoded) and the TCP port it is listening on in a packed on UDP 2222. Other copies of word on the network get this packet and then respond the your copy of word on the specified TCP port if they have the same serial. Then one copy shuts down.

I guess it was malware after all. Outstanding!

Posted by ekr at 9:54 PM | Comments (7)

May 2, 2008

Yes, many TCP connections end in RSTs

George Ou made this argument at the FCC En Banc hearing at Stanford on 4/25 (A/V here).
It's actually quite common throughout the world that TCP RSTs are used.

...

Speaking of the 1:45 AM resets, ISPs all over the world, they've found that up to 12% of sessions get reset, all over the world. It's almost like there's this 12% of background noise of TCP resets that are happening that may not be coming from comcast but could be coming from any device on the Internet, all routers, all firewalls support that feature and we don't really know where it's coming from.

Here's ATT's response to Vuze's claim that they use RSTs for "network management purposes" (i.e., terminating connections they don't like):

In response to your specific question about AT&T's network management practices, AT&T does not use "false reset messages" to manage its network. We agree with Vuze that the use of the Vuze Plug-In to measure network traffic has numerous limitations and deficiencies, and does not demonstrate whether any particular network providers or their customers are using TCP Reset messages for network management purposes. Given that Vuze itself has recognized these problems with the measurements generated by its Plug-In, we believe that Vuze should not have published these misleading measurements, nor filed them with the FCC. Moreover, as Vuze and others have acknowledged, TCP resets are generated for many reasons wholly unrelated to the network management practices of broadband network providers, which explains why resets may appear on networks of companies such as AT&T who do not use TCP resets for network management (see, e.g., An Analysis ofTCP Reset Behaviour on the Internet, University of Calgary (2004)).

I've reviewed the paper by Arlitt and Williamson to which AT&T is referring (Ou didn't cite his sources), and while it's interesting work, I don't think it really speaks to Ou's argument. The RSTs that Arlitt and Williamson are talking about are primarily ungraceful terminations of TCP connections that would be ending anyway. The authors suggest a number of cases here:

In all of these cases but the last, though, the Web transactions are actually over, so while there may be some negative effects from not going through the correct TCP finish handshake (cf. RFC 1337), neither side perceives this as failed transactions. And in the final case, the server explicitly is rejecting the connection, so this seems appropriate as well. It's also fairly straightforward to distinguish these cases as a passive observer (as the authors have done) with the appropriate tools.

What Comcast has done, however, is something different: they were (are?) using RSTs to abort other people's transactions. The base rate of normal RSTs isn't really that useful for assessing the appropriateness of third party RSTs as a network traffic management technique. As a hypothetical, imagine that Comcast were forging FINs instead of RSTs. One could expand Ou's argument to say "FINs are a natural feature of the Internet", but it doesn't really follow that it's desirable to have third parties forging FINs on your connections.

It does bear, on the other hand, on what we can infer from Vuze's data. Vuze hasn't really published that many details of their methodology, but they claim to be measuring the total number of RSTs, not just those of Azureus/Bittorrent connections (Incidentally, I'm not sure how I'd feel as a user about installing some app that sniffed all the traffic on my network and sent statistics to Vuze)[-- see update below; EKR]:

The Vuze Plug\u2010In constantly monitors the rate of network interruptions occurring from RST ("reset") packets by measuring the total number of attempted network connections and the total number of network connections that were interrupted by a reset message. By comparing these two values, one can calculate the ratio of network connections interrupted by reset messages. We have chosen to reflect the median ratio in order to reduce variability in the data given the sample size.

The Plug\u2010In collects data for all Internet connections, not just connections occurring due to use of the Vuze application, and logs it every ten minutes Then, at the top of the hour, the Plug\u2010In aggregates the data into one\u2010hour blocks and transmits it to Vuze, Inc.. By definition, each source of data had the Vuze application installed and launched in order connections.

But if you're measuring all RSTs and not attempting to determine which ones are "normal" and which ones represent connection failure, then it's not clear how representative your data is. It is sort of interesting how much variation (about an order of magnitude from 2.5% to 24%) there is in terms the rate of RSTs, but as Iljitsch van Beijnum observes, this could be the result of caching proxies and the like in the network. You may not particularly want your ISP interposing a proxy, but that's a different question than whether they're actually blocking your P2P traffic.

This isn't the only possible reason, either. For instance, users might just have different software profiles. Given that Vuze claims to have 8000 users on 1200 ASs (with the data being reported for ASs with greater than 20 users, there could well just be a lot of statistical variation. Some evidence of this is that the results from Comcast alone span from 14% to 24%). In order to really make sense of data like Vuze's we'd need to try to distinguish normal RSTs from those injected in the network, which requires more forensics (TTL inspection, IP ID, etc.) than Vuze's paper describes.

UPDATE (8:49 AM): I was wrong about this needing to be a packet sniffer. I just read the source (here; thanks to Danny McPherson for pointing out that I could download it.) They're just using netstat to read the network statistics and grabbing the reset counter out of the results. On the other hand, this means that they're not even in principle able to differentiate between RSTs generated on Azureus connections and those on other connections or between those generated by some man in the middle or by endpoints. While the variation in reported RSTs remains interesting, you'd need a significantly more advanced tool than this to really diagnose what's going on.

Posted by ekr at 7:36 AM | Comments (1)

May 1, 2008

Natural resistance to testosterone testing

In the NYT, Gina Kolata reports on a study that found that a substantial number of athletes show negative results on urine tests for testosterone, even when they're doping:
The 55 men in a drug doping study in Sweden were normal and healthy. And all agreed, for the sake of science, to be injected with testosterone and then undergo the standard urine test to screen for doping with the hormone.

The results were unambiguous: the test worked for most of the men, showing that they had taken the drug. But 17 of the men tested negative. Their urine seemed fine, with no excess testosterone even though the men clearly had taken the drug.

It was, researchers say, a striking demonstration of a genetic discovery. Those 17 men can build muscles with testosterone, they respond normally to the hormone, but they are missing both copies of a gene used to convert the testosterone into a form that dissolves in urine. The result is that they may be able to take testosterone with impunity.

...

Men with the gene deletion still metabolize testosterone, Dr. Schulze says. But, she adds, she does not know where the hormone goes. "We have no idea," she said. "That's what we're trying to find out."

If you've got this gene deletion, you've potentially got an enormous advantage in terms of being able to dope without getting caught. Even for those who don't have the gene deletion, I wonder whether there's some chemistry you could use to force testosterone metabolism down whatever alternate pathway is involved here (or alternately to disable the standard pathway), producing a masking effect for even those with normal genetic profiles.

Posted by ekr at 9:14 PM | Comments (1)