Anyone who’s been around the DNMs these past few years will know the frustration of the constant ups and downs experienced for various reasons. Some have closed due to LEA intervention, exit scamming and even other less dramatic reasons. We know that LEA intervention will always be a part of the markets and well so will exit scamming as long as human beings are human beings; but one obnoxious and unnecessary cause for downtime and even closure has been Distributed Denial of Service. DDoS attacks have been inflicted on the markets for numerous reasons: vigilantism, captivity and some hackers have even become ‘guns for hire’ being hired by smaller less successful markets to attack the bigger ones. According to his DeepdDotWeb Interview the admin of the Mr. Nice Guy Market offered to pay the ‘DDos Mafia’ to keep on attacking the bigger markets after being attacked himself.
DDoS (Distributed Denial of Service) is a supped up version of a very old Network Layer attack known simply as DoS (Denial of Service). DoS attacks have been around as long as the internet and do not take any real amount of skill to execute. In earlier days DoS attacks would most often target the network layer in one of two ways:
- A ‘Poison Packet’ is a malformed packet that will be received and processed by the reciving network device and a result hang or crash the device as a result of it having trouble processing the packet
- A continuous stream of packets were sent to a recipient network at a rate that would fill up the buffer and eventually overwhelm the device causing in a crash
Depending on the attack, the downtime could be limited to the amount of time it took for the crashed device to simply reboot, load its operating system from NVRAM and then apply the configuration file (if neither ended up corrupted). Another variation on number might be concerned with the packet size rather than the number of packets sent. One of the classic rudimentary DoS attacks was known as the ‘Ping of Death’; and as its name indicated, it simply perpetrated the attack using icmp packets which exceeded the maximum ICMP packet size of 65,535 bytes (FIGURE A). Another more sinister and detrimental DoS attacks is the ‘TCP SYN Flood’ attack which sends packets to a destination router or server using a forged source IP address. When a SYN message is received on a server, an ACK message is sent back to the sender and it awaits a response, thus keeping the session open. Since the attack is coming from a false or forged source IP address, the response is never received back, so if an attacker opens enough TCP SYN Flood attacks they can quickly tie up all system resources and leave it in an unreachable state for legitimate traffic (FIGURE B).
FIGURE A – Ping of Death
FIGURE B – TCP SYN Flood
Through the years Denial of Service attacks were dealt with in different ways – and most can be mitigated if you throw enough money at them. For larger networks, public-facing servers are often load-balanced, and even hosted by companies that spread access across various changing IP addresses. These days decent firewalls and IPS (Intrusion prevention Systems) sensors can easily detect and mitigate against IP spoofing and simple DoS by sniffing out spoofed IPs and limiting consecutive connections from the same IP addresses. Features like DHCP snooping, ARP Inspection and ACLs (Access Control Lists) can detect and protect against DoS in real-time.
So what about DDoS? Well, Distributed Denial of Service can be a bit trickier as it doesn’t need to rely on spoofed IPs and it doesn’t need to come from the same source address – in fact it is quite the opposite. The whole point of DDoS is leveraging tens, hundreds or thousands of computers that are either hijacked or belong to willing participants (FIGURE C). If each new TCP SYN message is coming from a different IP, then it’s safe to assume the requests are legitimate right?
FIGURE C – Distributed DoS
DDoS attacks can still be a problem, even for large corporate networks with large bank accounts. It takes a combination of planning, software, hardware and constant monitoring to defend against DDoS. Again, stateful firewalls and IPS devices are crucial; as well as working with ISPs to prevent such attacks. QoS (Quality of Service) is normally leveraged to guarantee bandwidth and throughput availability for higher data services like video and voice, but it can also be used to limit overall bandwidth usage to certain servers, systems, etc. Big vendors like Cisco, Juniper, Palo Alto and Checkpoint are working every day finding ways to mitigate against DDoS attacks, but for the individual or DNM admin, this could prove much more difficult. Where original DoS and DDoS attacks operated at Network and Transport layers, Layer 7 (Application) DDoS attacks are becoming more prevalent and tricky to protect against. However, one would think that TOR could provide some protection against DDoS attacks since it acts as an intermediary between client and server, but as we all know many of the top markets underwent a lengthy and crippling barrage of DDoS attacks and downtime in the Spring of 2015. Some of the markets managed to stay up and running most of the time, but what sets them apart from the others?
The TOR Project Abuse FAQ explains that DDoS is not actually a concern at the network level over TOR because most Network Layer DDoS Attacks rely on UDP packets, where TOR only ‘supports’ properly formed TCP packets:
“Distributed denial of service (DDoS) attacks typically rely on having a group of thousands of computers all sending floods of traffic to a victim. Since the goal is to overpower the bandwidth of the victim, they typically send UDP packets since those don’t require handshakes or coordination.
But because Tor only transports correctly formed TCP streams, not all IP packets, you cannot send UDP packets over Tor. (You can’t do specialized forms of this attack like SYN flooding either.) So ordinary DDoS attacks are not possible over Tor. Tor also doesn’t allow bandwidth amplification attacks against external sites: you need to send in a byte for every byte that the Tor network will send to your destination. So in general, attackers who control enough bandwidth to launch an effective DDoS attack can do it just fine without Tor.”
For those who don’t know the fundamental difference between TCP and UDP packets: In a nutshell, TCP ensures proper payload delivery using hashes to ensure that all packets are received and re-assembled in order. If they are not, the session is usually re-established and the process starts all over again. UDP packets don’t care if the entire payload makes it or makes it in order, so this makes them a favorite for many DoS and DDoS Attacks. So if TOR isn’t providing easy pickings for DDoS attacks then how did all of those markets go down for hours and days at a time during the Spring of 2015?
Not being familiar with the popular market software platforms, Hidden Service config files or a SQL expert I can’t go into extensive detail (after all ,my thing is networking not application and databases). Remember we mentioned Layer 7 DDoS attacks? Well, from what I could put together from forums, Reddit and comments from market admins themselves, the DDoS attacks were being perpetrated at the Session or Application Layers. Rather than perpetrating a DDoS on the IP hosting the market, the hackers were executing the DDoS on the Web Server, database or market software itself. It would seem that the flaw was either in HTTP/HTTPs or the market platforms. Just as we mentioned how a TCP SYN Flood attack is executed, something similar could be executed with HTTP or application sessions I suspect.
Although it is just a short Public Service Announcement , a March 2015 post on DeepDotWeb indicated the vulnerability was with the TOR and Hidden Service application itself, not a database or HTTP. TOR Ticket 15463 from 13 months ago is entitled “Tor deals poorly with a very large number of incoming connection requests” and goes on to indicate that each new request uses a different rendezvous points. This sounds a bit like Network Layer DDoS (although one might say it’s technically Application Layer since TOR itself is responsible and crashing. A list of suggested short-term fixes included a very familiar idea for regular DoS and DDoS mitigation: load balancing (among others).
The word is out that there has been constant work to mitigate DDoS with each new TOR version released and that a lot of it comes down to the code and application settings. Unfortunately, this goes a bit beyond my grasp of programming but from what we have been able to piece together the story of DoS and DDoS attacks on TOR read much like the same issues on the regular internet. The main difference with TOR is that the problems are being solved by TOR programmers, volunteers and even DNM admins. As mentioned one or two specific markets managed to keep going with limited downtime. Some speculated that they were the ones behind the entire attack, but I like to think it was clever administration, good old fashioned load balancing and maybe a simple firewall in front of the Hidden Service. The thing is we never know the full story about these markets because the admins are generally secretive and don’t speak to the public much or at all. You can see that the more experienced and secretive the admins are the better their markets seem to function. The last thing an admin wants to do is divulge a security breach or shortcoming on their server. As Agora has demonstrated time and time again, the best approach is to shut your mouth, take the downtime and fix the issue quietly.