5 ms·

>He found one weakness: By asking the server the right question, it would reveal his own IP address . >The question was asked and the server replied. It was lo

>He found one weakness: By asking the server the right question, it would reveal his own IP address . >The question was asked and the server replied. It was located in Sydney, owned by the server Digital Pacific. What the hell does that even mean? It almost sounds like they were doing packet sniffing and looking at the IP addresses of where the packets came from. Any non-tor exit node IPs could be the server's IP. Similar strategy was used against Silk Road.

kristofferR 9y ago
They have a more technical description of the process further down in the article, in the grey box: "IP addresses and physical server locations are inherently difficult to find on the Tor network. So how did VG’s computer expert get the forum to disclose this information? 1. Profile picture upload The forum allowed users to upload a profile picture. This picture could also be fetched from a user-supplied URL. 2. The leak This is where the information leak occurs. Configured for optimal security, the forum’s software and/or server would fetch the remote profile picture via Tor. Childs Play did not – all traffic to external sites originated from the server’s real IP. 3. The IP address is exposed By telling the forum to fetch a picture from a server Stangvik controlled, he could see in his server logs that the originating IP was with a hosting provider in Sydney – Digital Pacific. Stangvik went on to confirm that outgoing DNS requests originated from the same provider, and that the forum’s software also loaded images included in forum post previews from the same IP. 4. A proxy, VPN or Tor Exit? The next question was whether the IP belonged to a Tor Exit Node, a VPN or a proxy server. An IP can hide just about anything. How could he confirm that this was the forum’s location, rather than just a node in a chain of redirects? Stangvik applied three improvised techniques: 5. Timing between the servers He rented a virtual server with Digital Pacific – the same place as where the suspected IP was located. He then updated the profile picture URL to point to this server. Upon receiving an incoming profile picture request, Stangvik’s server would respond with a redirect to another URL on the same virtual server. Repeating this redirection process several time, Stangvik was able to isolate and measure the roundtrip-time between the two servers. The measurements yielded very low times, consistent with a forum server in close vicinity of his rented server. 6. Measuring intermediate nodes Stangvik also paid attention to so-called «Time To Live» values on the incoming data packets. These provide some insight into how many intermediate parties are involved from the sender to the recipient. In this case, the values indicated that there were at most one intermediate – a typical result if the servers were located in the same room. 7. Measuring packet size The final test started to get advanced: Measuring MTU (Maximum Transmission Unit) and packet fragmentation. Each packet in a computer network has a maximum transmission size, based on which intermediates it passes through. Each encapsulating technology, such as VPNs, can result in the total packet size increasing beyond the maximum size, and local networks usually have larger maximum sizes than the “tubes” found on the internet. If the maximum size is surpassed, the packet will be broken into multiple fragments. By crafting long profile picture URLs, and setting specific packet flags, in the redirects returned by his custom web server software, he could see that the MTU was consistent with that of high-speed local area network traffic, and also ruled out VPN configurations."
- ikeboy 9y ago
  This is why any server you want hidden should be behind something like whonix where no process running on the server should know the IP.
  - gruez 9y ago
    >where no process running on the server should know the IP. that's not the issue though. Even if the server was behind NAT (and thus only knows its internal IP), it could still find out its real external ip by sending packets to some other machine on the internet and checking what the "from" address was from. preventing this leak can only be done by having a strict routing table and/or outbound firewall. having VMs/containers 7 layers deep wouldn't help if the packets could freely reach the internet unproxied.
    - ikeboy 9y ago
      if it was behind whonix, all outside traffic would be routed through tor. One of its selling points is that malware running on the VM as root cannot get the real IP (without additional exploits).
      - therein 9y ago
        Whonix is great but the fact you need two servers and how the set up is more involved than just installing Tor and setting up a Hidden Service are the most common reasons why most takes the easy but less secure route. Whonix is amazing. I recommend it to anyone who is serious about avoiding even sending a single packet over the clearnet.
        ikeboy 9y ago
        Even doing it on a single server is more secure than whatever these guys had. You can only be found if there's an actual exploit in the VM or tor or something, webserver bugs don't pwn you alone.
  - 9y ago
Eridrus 9y ago
Two things spring to mind: a debug message that spat out the IP it was listening on, or just scanning the internet and sending every server a Host header that's the Tor hostname. Sounds more like the former though.
zxcmx 9y ago
It is this bug: https://www.owasp.org/index.php/Server_Side_Request_Forgery https://www.owasp.org/index.php/Server_Side_Request_Forgery Except that with tor, hitting ANY external IP from the "real" IP of your hosting box is bad news (since your service is no longer hidden). This is a rookie mistake for an operator running a hidden service. What you are supposed to do is a) ensure you are not running crappy software and more importantly b) ensure that your server/container/service (preferably) has no network egress or (if you need that) that egress is transparently proxied at the network level through something suitably anonymous. Whatever scheme you choose should be robust against an attacker who compromises your hidden service any any way, up to having root on the host or vm. This usually means that if you are trying to run a hidden service on a single physical machine, you want multiple VMs or containers, and you really want there to be no guest-to-host escapes. There are multiple ways of skinning that cat but VMs are nicer than containers or jails because you can have actually different network stacks. The officer's methodology for determining whether the requesting IP was really that of the hidden service was quite sound from a forensics point of view and in fact did not require any "special" network access over and above that which a normal citizen would have.

kristofferR 9y ago

They have a more technical description of the process further down in the article, in the grey box: "IP addresses and physical server locations are inherently difficult to find on the Tor network. So how did VG’s computer expert get the forum to disclose this information? 1. Profile picture upload The forum allowed users to upload a profile picture. This picture could also be fetched from a user-supplied URL. 2. The leak This is where the information leak occurs. Configured for optimal security, the forum’s software and/or server would fetch the remote profile picture via Tor. Childs Play did not – all traffic to external sites originated from the server’s real IP. 3. The IP address is exposed By telling the forum to fetch a picture from a server Stangvik controlled, he could see in his server logs that the originating IP was with a hosting provider in Sydney – Digital Pacific. Stangvik went on to confirm that outgoing DNS requests originated from the same provider, and that the forum’s software also loaded images included in forum post previews from the same IP. 4. A proxy, VPN or Tor Exit? The next question was whether the IP belonged to a Tor Exit Node, a VPN or a proxy server. An IP can hide just about anything. How could he confirm that this was the forum’s location, rather than just a node in a chain of redirects? Stangvik applied three improvised techniques: 5. Timing between the servers He rented a virtual server with Digital Pacific – the same place as where the suspected IP was located. He then updated the profile picture URL to point to this server. Upon receiving an incoming profile picture request, Stangvik’s server would respond with a redirect to another URL on the same virtual server. Repeating this redirection process several time, Stangvik was able to isolate and measure the roundtrip-time between the two servers. The measurements yielded very low times, consistent with a forum server in close vicinity of his rented server. 6. Measuring intermediate nodes Stangvik also paid attention to so-called «Time To Live» values on the incoming data packets. These provide some insight into how many intermediate parties are involved from the sender to the recipient. In this case, the values indicated that there were at most one intermediate – a typical result if the servers were located in the same room. 7. Measuring packet size The final test started to get advanced: Measuring MTU (Maximum Transmission Unit) and packet fragmentation. Each packet in a computer network has a maximum transmission size, based on which intermediates it passes through. Each encapsulating technology, such as VPNs, can result in the total packet size increasing beyond the maximum size, and local networks usually have larger maximum sizes than the “tubes” found on the internet. If the maximum size is surpassed, the packet will be broken into multiple fragments. By crafting long profile picture URLs, and setting specific packet flags, in the redirects returned by his custom web server software, he could see that the MTU was consistent with that of high-speed local area network traffic, and also ruled out VPN configurations."

ikeboy 9y ago
This is why any server you want hidden should be behind something like whonix where no process running on the server should know the IP.
- gruez 9y ago
  >where no process running on the server should know the IP. that's not the issue though. Even if the server was behind NAT (and thus only knows its internal IP), it could still find out its real external ip by sending packets to some other machine on the internet and checking what the "from" address was from. preventing this leak can only be done by having a strict routing table and/or outbound firewall. having VMs/containers 7 layers deep wouldn't help if the packets could freely reach the internet unproxied.
  - ikeboy 9y ago
    if it was behind whonix, all outside traffic would be routed through tor. One of its selling points is that malware running on the VM as root cannot get the real IP (without additional exploits).
    - therein 9y ago
      Whonix is great but the fact you need two servers and how the set up is more involved than just installing Tor and setting up a Hidden Service are the most common reasons why most takes the easy but less secure route. Whonix is amazing. I recommend it to anyone who is serious about avoiding even sending a single packet over the clearnet.
      - ikeboy 9y ago
        Even doing it on a single server is more secure than whatever these guys had. You can only be found if there's an actual exploit in the VM or tor or something, webserver bugs don't pwn you alone.
- 9y ago

Eridrus 9y ago

Two things spring to mind: a debug message that spat out the IP it was listening on, or just scanning the internet and sending every server a Host header that's the Tor hostname. Sounds more like the former though.

zxcmx 9y ago

It is this bug: https://www.owasp.org/index.php/Server_Side_Request_Forgery https://www.owasp.org/index.php/Server_Side_Request_Forgery Except that with tor, hitting ANY external IP from the "real" IP of your hosting box is bad news (since your service is no longer hidden). This is a rookie mistake for an operator running a hidden service. What you are supposed to do is a) ensure you are not running crappy software and more importantly b) ensure that your server/container/service (preferably) has no network egress or (if you need that) that egress is transparently proxied at the network level through something suitably anonymous. Whatever scheme you choose should be robust against an attacker who compromises your hidden service any any way, up to having root on the host or vm. This usually means that if you are trying to run a hidden service on a single physical machine, you want multiple VMs or containers, and you really want there to be no guest-to-host escapes. There are multiple ways of skinning that cat but VMs are nicer than containers or jails because you can have actually different network stacks. The officer's methodology for determining whether the requesting IP was really that of the hidden service was quite sound from a forensics point of view and in fact did not require any "special" network access over and above that which a normal citizen would have.