D-kriptik Blog

So, this overview paper is making the rounds.

We begin with a state-of-the-art survey of IP geolocation techniques and limitations, and examine the specific problems of (1) approximating a physical location from an IP address; and (2) approximating the physical location of an end client requesting content from a web server. In contrast to previous work, we consider also an adversarial model: a knowledgeable adversary seeking to evade geolocation. Our survey serves as the basis from which we examine tactics useful for evasion/circumvention. The adversarial model leads us to also consider the difficulty of (3) extracting the IP address of an end client visiting a server.

The packet timing portion of this paper reminded me of a bunch of papers on location in ad hoc and/or sensor networks (that I chunked through recently), which took estimates of distance or angle, based on signal strength, time of arrival, angle of arrival, etc., between nodes with a known location and the node with an unknown location and combined them, based on tri-lateration, triangulation, etc., to calculate the geographic location of the node with unknown location.

For example,

Let’s say A, B, and C are nodes of known location.
Let’s say D is a node of unknown location.
Let’s say a signal can travel between any two nodes at a speed of 10 feet per second.
Let’s say we can measure how much time it takes for a signal to travel between any two nodes in seconds.

In order to figure out the location of D, we first take time measurements of the signal traveling between A and D, B and D, and C and D. During our measurements, we discover it takes 3 seconds for that signal to travel between A and D, 4 seconds between B and D, and 6 seconds between C and D.

Since we know that a signal can travel between two nodes at a speed of 10 feet per second, we can take these time measurements and compute how far A, B, and C are from D by mutiplying the speed (feet per second) by the time (seconds). So, the distance between A and D is 3 seconds multipled by 10 feet per second = 30 feet, the distance between B and D is (4 seconds * 10 feet per second =) 40 feet, and the distance between C and D is (6 seconds * 10 feet per second =) 60 feet.

With our distance estimates done, we can now calculate the location of D using tri-lateration.

We know where A is located and we know that A is 30 feet away from D, although we do not know in which direction – so, we can draw a circle around A with a radius of 30 feet and know that D has to be located at some point on that circle. We do the same for B by drawing a circle 40 feet in radius around it and for C by drawing a circle 60 feet in radius around it.

The point where these three circles intersect is the location of D, as depicted in the following diagram (note: the diagram is just a quick sketch and not at all to scale).

Back from that tangent, I noticed the following in the paper.

While proxies complicate the task of geolocating end-users, they do not necessarily preclude this. Here we
present a new method for extracting an end-user IP address even for end-users protected by Tor/Privoxy.

Suppose a Tor user downloads a web page containing a Java applet. The applet is permitted to open a network connection back to the server which originated it,¹⁵ e.g., by the Java code:

	int tcp_port = 80;
	Socket S = new Socket(getCodeBase().getHost(), tcp_port);

This connection is administered by the JRE, which by default should inherit any proxy settings from the browser (i.e., localhost:9050). However, Internet Explorer (IE 6.0 with SP1 running onWindows XP) – and possibly other browsers (but not Firefox, in our tests) – seem unable to communicate these preferences to the JRE. With such a browser, a Tor user’s real IP address is reported to the server by the code above. While this issue of proxy settings not being passed to the JRE is not widely known, it has been noted by some Tor enthusiasts.¹⁶

¹⁵This is allowed by the Java applet security model; see http://java.sun.com/sfaq/
¹⁶For example, see http://uk.geocities.com/osin1941/exposingtor.html.

Using modern web browsers in an anonymous manner is hard when someone is trying to penetrate that anonymity. All that scripting and dynamic content makes it even harder, as this example illustrates. And, given the vulnerabilities in web browsers that keep being discovered and actively exploited, the ability of an attacker to execute rogue code on an end-user’s machine simply by browsing a malicious web site seems like a given – in other words, no need for Java when you have document.getElementById().createTextRange() [e.g., 1, 2] (recently patched).

Also, it should be noted that this means of gathering an IP address is not an attack on TOR itself. The attack exploits tools being used outside of TOR, in particular a web browser with proxy support (somewhat) and enabled Java support – the end-user is not being protected by, or using, Tor and Privoxy, as their traffic is not being routed through these proxies on its way to the outside world. (Yeah right, crypto this?)

(I wrote this post a couple of months ago, which might be of interest.)

via a post to cypherpunks

-

There is a good discussion on DailyDave about vendors’ silently patching security issues and the impacts to companies’ patch management.

The following is a excerpt from this post in that discussion.

Corporation observes that Vulnerability A is difficult to exploit and
therefore lowers their internal risk rating and simply schedules the
patch for the next available change window. Signature based protections
are updated and false sense of security sets in… Beers are drank
everywhere.

Attacker (or anyone for that matter) reverse engineers the patch,
identifies Vulnerability B and realizes that it is much more reliable to
exploit than the publicly disclosed vulnerability.

Corporation gets owned. Hung over IT guy develops an ulcer if he didn’t
have one already.

What was it over at Apex Assurance? Oh yeah, “security is a business issue, not a technical issue.”

The thread can be found in the April 2006 DailyDave archives. This post started it off.

-

I found this (registration wall) to be interesting – pennies (US coin money) cost more than a penny (USD) to make.

This week the cost of the metals in a penny rose above 0.8 cents, more than twice the value of last fall. Because the government spends at least another six-tenths of a cent – above and beyond the cost of the metal – to make each penny, it will lose nearly half a cent on each new one it mints.

Soon the raw metal of the coin may be worth more than the face value of the coin as well – then it will be time to start melting those annoying critters down.

via a post to clips

-

Personal note,

Congratulations to AK² and the newly born CK.

This entry was posted on Monday, April 24th, 2006 at 4:27 am and is filed under Anonymity & Privacy, Security. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.