Information Leakage at the Packet Level
Because Sendai cannot think of above-board ways to learn public companies private earnings information directly, he looks for attributes that may correlate strongly with earnings. One idea is to study the SSL traffic to e-commerce sites. The amount of encrypted traffic they generate is often proportional to the number of sales during that period. This begs the next question: How will Sendai measure a company s SSL traffic? They certainly will not tell him. Breaking into a router barely upstream of the target host would give him access to this data, but that is quite illegal and also requires substantial custom work for each target. Sendai wants a general, unobtrusive , easy, and legal way to determine this information.
Eventually, Sendai thinks of the fragmentation ID field in Internet Protocol (IP) packets. This unsigned 16-bit field is intended to provide a unique ID number to each packet sent between machines during a given time period. The primary purpose is allowing large packets, which must be fragmented during transit, to be reassembled properly by the destination host. Otherwise a host receiving hundreds of fragments from dozens of packets would not be able to match fragments to their original packets. Many OS developers implement this system in a very simple way: they keep a global counter and increment it once for each packet sent. After the counter reaches 65,535, it wraps back to zero.
The risk of this simple implementation is that it allows bad guys to remotely determine traffic levels of a host. This can be useful for many sinister purposes, including an extraordinarily stealthy port scanning technique known as Idle Scan. [1] Sendai will use it to estimate daily orders.
He decides to test whether popular public e-commerce sites are actually vulnerable to this sort of information leakage. He visits the online sites of Dell and Buy.Com, following the order placement path until reaching their secure sites. These sites are designated by the https protocol in the URL bar and a closed padlock icon on his browser. They are ecomm.dell.com and secure.buy.com. Sendai uses the open source hping2 program ( freely available from www.hping.org ) to send eight TCP SYN packets, 1 second apart, to port 443 (SSL) of the specified host.
 |
# hping2 -c 8 -S -i 1 -p 443 ecomm.dell.com HPING ecomm.dell.com (eth0 143.166.83.166): S set, 40 headers + 0 data bytes 46 bytes from 143.166.83.166: flags=SA seq=0 ttl=111 id=8984 rtt=64.6 ms 46 bytes from 143.166.83.166: flags=SA seq=1 ttl=111 id=9171 rtt=62.9 ms 46 bytes from 143.166.83.166: flags=SA seq=2 ttl=111 id=9285 rtt=63.6 ms 46 bytes from 143.166.83.166: flags=SA seq=3 ttl=111 id=9492 rtt=63.2 ms 46 bytes from 143.166.83.166: flags=SA seq=4 ttl=111 id=9712 rtt=62.8 ms 46 bytes from 143.166.83.166: flags=SA seq=5 ttl=111 id=9974 rtt=63.0 ms 46 bytes from 143.166.83.166: flags=SA seq=6 ttl=111 id=10237 rtt=64.1 ms 46 bytes from 143.166.83.166: flags=SA seq=7 ttl=111 id=10441 rtt=63.7 ms --- ecomm.dell.com hping statistic --- 8 packets transmitted, 8 packets received, 0% packet loss # hping2 -c 8 -S -i 1 -p 443 secure.buy.com HPING secure.buy.com (eth0 209.67.181.20): S set, 40 headers + 0 data bytes 46 bytes from 209.67.181.20: flags=SA seq=0 ttl=117 id=19699 rtt=11.9 ms 46 bytes from 209.67.181.20: flags=SA seq=1 ttl=117 id=19739 rtt=11.9 ms 46 bytes from 209.67.181.20: flags=SA seq=2 ttl=117 id=19782 rtt=12.4 ms 46 bytes from 209.67.181.20: flags=SA seq=3 ttl=117 id=19800 rtt=11.5 ms 46 bytes from 209.67.181.20: flags=SA seq=4 ttl=117 id=19821 rtt=11.5 ms 46 bytes from 209.67.181.20: flags=SA seq=5 ttl=117 id=19834 rtt=11.6 ms 46 bytes from 209.67.181.20: flags=SA seq=6 ttl=117 id=19857 rtt=11.9 ms 46 bytes from 209.67.181.20: flags=SA seq=7 ttl=117 id=19878 rtt=11.5 ms --- secure.buy.com hping statistic --- 8 packets transmitted, 8 packets received, 0% packet loss
| |
The IP ID fields in both cases show a pattern of steady monotonic increases , which is consistent with trivial packet counting behavior. During this test, the Dell machine sends an average of 208 packets per second (10441 minus 8984 all divided by 7) and secure.buy.com is showing 26 pps. One added complexity is that major hosts like Dell and Buy.Com have many systems behind a load balancer. That device ensures that subsequent packets from a certain IP address go to the same machine. Sendai is able to count the machines by sending probes from many different IP addresses. This step is critical, as the pps rate for a single box will naturally decrease when more machines are added to the farm or vice versa. Against a popular server farm, he may need many addresses, but huge netblocks can easily be purchased or hijacked.
Sendai begins to execute his plan. He writes a simple C program to do the probing and host counting using Dug Song s free libdnet library. It runs via cron a few dozen times a day against each of many publicly traded targets that are vulnerable to this problem. These samples allow an estimation of traffic for each day. Sendai knows better than to jump in with his money right away. Instead he will let his scripts run for a full quarter and count the cumulative traffic for each company. When each company reports results, he will divide their actual revenue for that quarter by his traffic estimate to compute revenue per packet. The second quarter will be a test. He will multiply revenue per packet by his calculated traffic to guess quarterly revenue, and then compare that revenue to the official numbers released later. Companies that prove inaccurate at this point will be discarded. With the remainder, Sendai hopes finally to make some money. He will watch them for a third quarter and again estimate their revenue. He will then compare his estimate to the First Call Consensus. If his revenue estimate is substantially higher, he will take out a major long position right before the earnings conference call. If he estimates a revenue shortfall, Sendai will go short. Obviously he still needs to research other factors such as pricing changes that could throw off his purely traffic-based revenue estimates.
[1] Further information on this technique is available at www. insecure .org/nmap/idlescan.html.
EAN: N/A
Pages: 105