TOR Network DOS Attack

November 21, 2024 General, Network Tools, Technology, Threat Hunting

Let’s say I decide that I don’t like the service www.ferretexercise.com (*) or the people that run it. I decide to make their lives miserable and get security tools to block access to that website. How could I do that?

 

Background

In this example, the IP address of that web server is 192.0.2.12 (*). I’m going to try to convince the people that run Threat Intel lists (formerly known as blacklists) to list that IP address as malicious. The overall approach is to send out connection requests to thousands of servers like this:

my.ip.add.ress -> server1, port 22
my.ip.add.ress -> server2, port 22
my.ip.add.ress -> server3, port 22
my.ip.add.ress -> server4, port 22
...

This looks like I’m trying to connect to the SSH port on all of those servers, called “scanning”. While this might not be deliberately malicious, it’s considered poor etiquette. As I do this, Threat Intel list operators will start to detect this and add “my.ip.add.ress” to their lists of people that scan the Internet – which can be considered malicious. That’ll have the effect of blocking myself from making legitimate future connections.

Wait a minute, that wasn’t the goal. ☹️

Let’s modify that attack. Instead of sending packets from my IP address, I’m going to send these packets with 192.0.2.12 as the source IP address (the address of the web server I want banned):

192.0.2.12 -> server1, port 22
192.0.2.12 -> server2, port 22
192.0.2.12 -> server3, port 22
192.0.2.12 -> server4, port 22
...

By changing the source address of these packets, the Threat Intel list maintainers now list 192.0.2.12 as a malicious scanning host and my evil plan is complete – 192.0.2.12 will now start to have problems holding legitimate conversations with other machines on the Internet because it shows up on Threat Intel lists.

The above is called IP spoofing – creating packets with someone else’s IP address as the source. I’ve only touched on the surface of IP spoofing – please see the first entry in References below for details about how this is used in this attack and the second entry for more general information about spoofing.

 

TOR

The attack mentioned in the “weird trick” post (see References) isn’t against a website dedicated to the health of fluffy pets, but instead it targets machines in the TOR network. These are computers that have normal IP addresses like other servers on the Internet, but also carry encrypted, hidden, and anonymized traffic. As an Internet user, I can start up a TOR-enabled web browser and access a web site in a way that hides much of my identity and my IP address. This privacy and the encryption used can be valuable to users in countries where one’s privacy is not easily available.

Unfortunately, those same characteristics make it a target by the groups that don’t want others to have privacy or anonymity. Unlike my fictional example at the beginning of this post, these groups want to actively attack TOR in an attempt to shut it down. The IP spoofing attack is just one of many methods used.

 

Should Tor Nodes Be Placed on Threat Intel Lists?

The attack requires Threat Intel list maintainers to add the TOR service IP addresses to their lists on the logic that the scanning that appears to be coming from them is malicious at some level. But here’s the interesting question: Can the list maintainers identify when these attacks use a spoofed source IP address?

They can, but it takes a little work. Let’s take a closer look at that network traffic, and to simplify this I’m only going to look at the traffic going to “server1”. We originally wrote this as:

192.0.2.12 -> server1, port 22

 

That’s only part of the conversation; here’s the full story:

192.0.2.12 -> server1, port 22

(opening SYN packet, created by the attacker. Note that the real machine with IP address 192.0.2.12 neither created nor ever sees this packet.)

server1, port 22 -> 192.0.2.12

(SYN/ACK packet means server is ready to talk, sent back to 192.0.2.12)

192.0.2.12 -> server1, port 22

(RST packet created by the actual 192.0.2.12. The RST means this computer has no idea why it received a SYN/ACK because it never sent the original SYN and therefore can only shut down the conversation with a reset.)

 

For comparison, here’s how a legitimate – i.e. not spoofed – conversation would look:

203.0.113.55 -> server1, port 22

(opening SYN packet, created by a legitimate SSH client)

server1, port 22 -> 203.0.113.55

(SYN/ACK packet means server is ready to talk, sent back to 203.0.113.55)

203.0.113.55 -> server1, port 22

(ACK packet that completes the handshake, and now SSH can continue.)

 

The yellow highlight shows the difference between the two; spoofed connections end in an “RST”, while non-spoofed connections have an “ACK” packet. So why can’t every Threat Intel list maintainer tell the difference?

  1. The list maintainer may only be passed IP addresses that one of their sources claim is being malicious without any ability to look deeper.
  2. The list maintainer may only get the opening SYN packets sent to them. As we see above, the opening SYN packets are effectively identical between both the spoofed and non-spoofed handshakes.
  3. Even in circumstances where the list maintainer does get all the opening packets (the 3 for spoofed connections or the 3 for non-spoofed connections), it takes a substantial amount of processing time and memory to match these up to make a final decision about whether these are legitimate or not. This becomes especially difficult when monitoring high bandwidth Internet links.

 

Long-Term Effect

The real shame is that the list maintainers are put in a difficult situation. The goals are good: identify sources of malicious traffic that other people can use to decide what traffic should be allowed into their network. The practical side of creating these lists is that there will always be IP addresses that should be on the list but are not, as well as IP addresses that should not be in the lists but are. This hammers home that 1) lists of addresses really aren’t the best way to enforce security on the Internet, and 2) the care taken in building these lists needs to be taken into account when deciding on which lists to use.

For those hoping there’s a better way, there is – sort of. The Internet community published a document called Best Current Practices (BCP) 38 that essentially says, “If an ISP assigns a particular address range to a client, the ISP should only accept those addresses coming from that client’s network.” If all ISPs did this, it would be far more difficult to do spoofing. Unfortunately though, BCP38 came out in 1998 and we’re still fighting this battle 26 years later.

 

References

* The domain and IP address used in this blog are not legitimate – they’re examples to demonstrate how this would be done.

 

 

 

 

Interested in threat hunting tools? Check out AC-Hunter

Active Countermeasures is passionate about providing quality, educational content for the Infosec and Threat Hunting community. We appreciate your feedback so we can keep providing the type of content the community wants to see. Please feel free to Email Us with your ideas!

Share this:
Tags:
AC-Hunter Datasheet
GET THE PDF
AC-Hunter Personal Demo
SCHEDULE HERE
What We’re up To

SUBSCRIBE

Recent Posts
Categories
Archives