Everything changes, that’s obvious. The same rule applies to DDoS (Distributed Denial of Service) attacks. At the beginning, it was a simple flood which main purpose was to overwhelm destination machine’s resources or saturate the capacity of network link. Let me present how situation has changed over several last years.
JavaScript DDoS - scary monster from China…
At the end of March last year, news about big DDoS attack against Github hit the media. Many security researchers started analysing, what type of attack generated such amount of traffic directed to github.com. After few days Netresec released a blog post describing what exactly has happened.
Long story short:
- An innocent user opens a website that uses Baidu analytics.
- After visiting the website, the browser loads/requests Baidu Analytics JavaScript code (which serves similar purpose as Google Analytics).
- The web browser’s request for the Baidu JavaScript is intercepted by the Great Cannon.
- A fake response is injected by Great Cannon (using China Unicom infrastructure confirmed by Robert Graham) instead of the actual Baidu Analytics script. This fake response is a malicious JavaScript that tells the user’s browser to continuously reload two specific pages on GitHub.com.
The important thing to note is that not all requests were answered by the Great Cannon. As reported by Google number of requests varied between 6% at the beginning of the attack with maximum spikes reaching 17,5% of traffic destined to baidu.com. That was a huge number taking into account how many Asian websites are using Baidu Analytics. The whole campaign was well planned and executed.
Above situation with Great Firewall of China was a good example of JavaScript-based DDoS triggered by man-in-the-middle attack. Take a look at below drawing showing that method.
Volumes of such attacks are related to popularity of the domain. The more requests intercepted the larger DDOS attack would be generated. Another variation might be achieved by injecting malicious JavaScript in HTTP responses intercepted by open proxies.
Prevention (encryption -> HTTP is over)
To prevent this kind of injection you can block JavaScript in your web browser using popular add-on NoScript. That’s protection from client point of view, but what administrators could do for their users ? They SHOULD start using SSL ;).
You may remember our rant about Confidence 2015 conference and how we were a little bit disappointed with the talks. Guess what, there was one shining star! It was presentation done by Jim Manico. Not exactly a rocket science but I exactly remember his main motto: HTTP is over! Time to switch to HTTPS!
I fully agree with Jim. There is no excuse to serve HTTP content which could be easily intercepted and modified. If you want to be regarded as a trusted and safe partner on the market, you need to launch HTTPS. For many small business new chance is just around the corner - Let’s Encrypt project is approaching a final phase. It’s a great opportunity to make the Web a safer place. No more excuse regarding performance which is briefly explained here, dispelling few myths. In short, TLS features plus new version of HTTP standard, HTTP/2, should resolve all your concerns in this matter.
Other types of JavaScript DDoS
Unfortunately, encrypting traffic will not resolve other types of JavaScript-based DDoS attack. There are two scenarios, I would like to mention here.
First situation is when the user requests a valid JavaScript file, but in response receives malicious JavaScript, which was replaced on the compromised server. It’s a tough case, because from user point of view, he/she cannot expect that valid source will serve malicious content.
Secondly, nowadays many web developers would like to speed up the development process by using third party libraries instead of writing own code. Of course, this solution has many advantages (i.e. saves time and money), but it also adds additional code that is outside of control.
In September 2014, RiskIQ reported that jQuery.com’s website was compromised. jQuery is one of the most popular JavaScript library (around 30% of all websites using some version of it as of 2014). As a part of this attack it could have easily been replaced with a malicious one and infect millions of webpages using that lib. This kind of attack is no longer theoretical but a real danger.
So in both cases described above, simply by navigating to a legitimate web page your computer can become a part of DDoS attack. I recommend blocking JavaScript execution in your web browser by default. It’s better to have full control on what executes on your computer ;)
P.S. It was not a first incident where Great Firewall of China was involved and I’m sure that it was not last.
XOR DDoS - malware not only knocks out the “window”…
Late summer last year, you could read few notes (1,2) or thread advisory regarding Linux trojan named Xor.DDoS, using infected machines in different DDoS campaigns. It was researched by MalwareMustDie team two years ago. The name stems from the heavy usage of XOR encryption in both malware and network communication to the C&Cs.
Infection:
Attackers use the following vectors to infect machines:
- one-liner shell script being injected via ssh connection (Shellshock in use)
- brute force weak root password
- exploit a vulnerable service running on victim machine
Brief analysis:
Malware copies itself to the following files:
/boot/<10 random alphanumeric chars>/lib/udev
The malware sets the following permissions on the created files:
1 2 3 | |
To ensure persistence, the malware executes processes to determine if the main process is still running. If not, it creates and executes a new copy in /boot. The process is hidden using common techniques like masking itself using the name of a common Linux tool like top etc.
1 2 | |
That’s only a small piece of all actions done by this malware - MMD team has a very detailed analysis on their blog.
Moreover, in the middle of last year the same team discovered that XoR.DDoS used an iptabLes|x strategy in their infection process - take a look at paragraph “Linux/killfile” ELF (downloader, kills processes & runs etc malware).
For persistence the malware creates an init.d script with random name. Run the following command to check for the presence of the script:
1 2 3 4 5 6 | |
File itself is a non-stripped ELF, written in C language. It is a nice example of well-written executable malware to infect multi-platform Linux environments with multiple persistence mechanisms. It is not as typical DDoS bot written in a high-level scripting language like Perl or PHP with really straightforward operations.
The IP addresses it would communicate with were encoded into binary. When it called into action then affected server start flooding victim IP.
Attack scenarios
One of them (using brute force campaign as an initial step) was described by FireEye in blog post at the beginning of last year.
In short, whole campaign was focused on gaining access to servers around the world. Part of the attack was targeted at FireEye’s global threat research network (honeynet). It’s worth to mention that it was really extensive campaign - in three months each server (from FireEye network) logged nearly ONE million login attempts!
If root access was obtained then attackers IPs (103.41.124.0/24) would log out and stop any further activity. In the next 24 hours another IP accessed the server and would run a SSH remote command (openSSH feature - multiple shell commands, separated by semi-colons). The malware extracted kernel headers and version strings from victim server and prepared customized malware on a separate build server. Whole process worked against hash signature-based mechanism. If there was a problem with building proper version then it used pre-build solution.
Main purpose of this campaign was to infect as much servers as possible with the XoR.DDoS malware and use it in DDoS attacks. Few of them were observed by Akamai SIRT and presented in their threat advisory. Attack generated by XoR.DDoS botnet ranged from a few Gbps to 150+ Gbps mostly in gaming business. To imagine how huge volume was generated compare it to North Korea’s total bandwidth. Incapsula’s security researcher, Ofer Gayer, estimated at the end of 2014 that at around 2.5 Gbps, so the attack generated by XoR.DDoS was 60 times or more bigger than total country traffic!
Conclusion
The material presented above, shows how much DDoS business has changed. Attackers are looking for new different methods to generate high volume distributed attacks like:
- sophisticated malware
- trusted infrastructure as a carrier of command for innocent users
- new protocol where reflection attack is possible.
You could say that developing itself is nothing new and that’s true, but the scale of this phenomenon is much greater and people who work on it are much more advanced and well prepared (at various levels - skills, organization, marketing). It gives the conviction that a group of people responsible for DDOS attacks and their capability grows rapidly.
The above thesis is confirmed by reports of two leading companies dealing with mitigation of DDoS attacks. Akamai Technologies report outlines following characteristics:
- DDoS lower bandwidth raising - 25% attack more than 425Mbps, 125Mbps more than Q3 2014
- Number of DDoS attacks growing rapidly - figure 2.11
- Reflection attack coming very popular attack method which is presented on figure 2.13
Similar trends are described in Imperva report.
- 100+ Gbps attacks became more commonplace (1 per 48h)
- average 129 DDoS attacks every day
At the end of the day what haven’t change about DDOS attacks is the purpose that remains the same. Politics and money. Example of ProtonMail shows that even if you pay to criminals, it doesn’t guarantee that attack will not take place. In some cases, it actually gives you the opposite effect, because attackers knows that the one who will pay once will probably pay next time. Which is sad… if you don’t pay they will perform DDoS attack for sure …, so be prepared and invest in proactive measures to protect your infrastructure against DDoS attacks!