🕒 Reading Time: 6 minutes

First and foremost, happy new year! Last year was very eventful for the cybersecurity industry, with major breaches such as the Office the Personnel Management and Anthem Blue Cross exposing potentially millions of individuals to identity theft and worse. On top of that, DDoS attacks are getting bigger, stronger and more frequent, leveling larger and larger services with less and less effort. Notable DDoS attacks include the formidable attack on Github.com and the continuing siege on Linode. We here at CARI.net saw a huge increase in DDoS attack activity, with February and December being the most active months. In February, we recorded a total of 45 DDoS attacks, with December bringing in 38 attacks in just 2 weeks. Many of the attacks we saw were targeting specific services, such as online games and VoIP providers. This is compared to the ~60 DDoS attacks that we recorded in all of 2014. Another startling shift is the change in average attack size. In 2014, the average DDoS attack size that we saw on our network was around ~5Gbps. This has increased to an average of 13 to 15Gbps, with several reaching levels in excess of 20Gbps!

Linux Malware on the Rise

Mr Black/Win32:Agent.A generator
Example 1: MrBlack and Agent.A Generator

In almost direct correlation to the increase in DDoS attack activity are the aggressive increases in vulnerability scanning and password bruteforcing of Linux-based machines. In late 2014, the internet saw the emergence of some of the most potent Linux malware to date. In late September of 2014 MalwareMustDie discovered the XoR.DDoS malware, a very well built piece of malware, constructed specifically for carrying out DDoS attacks from Linux-based machines. Shortly after this, other Linux-specific malware families began to emerge; MrBlack, Mayday, BillGates, and Elknot, to name just a few. All these new pieces of Linux malware had one thing in common – they were built specifically for executing DDoS attacks. Other non-ChinaZ malware families built around the same premise include the LizardSquad Gafgyt malware (source code was released to the public late December 2014) and a reemergence of the venerable Tsunami bot.

Mr Black/Win32:Agent.A Controller
Example 2: Controller for MrBlack with node attached
One thing that should be noted is what exactly these malware families are targeting. While there are many Linux-based servers running in data centers around the world, much of this malware is targeted at home devices such as home routers, IP cameras and NAS systems. Most, if not all, of the families previously listed have builders for a variety of architectures. The example to the right is a very simple MrBlack builder, picked up in early 2015. These builders depend on .dat files that serve as templates. All you have to do to create malware for your own use is to run the controller, put the IP in the generator box, select the desired port and click the architecture that you want the malware generated for. These panels are not difficult to obtain, and nor are they difficult to operate. Other generators have more features such as optional UPX packing, as well as other architecture options.

It should be noted that Linux malware is not new, especially that which focuses on gathering nodes for DDoS attacks. For many years, IRC-controlled bots written in perl could be found littered about the /tmp and /dev/shm directories of compromised servers. This has not changed. Last year, CARISIRT documented 21 unique IRC bot scripts in Q2 alone. It should be noted that the “uniqueness” is based on the controller, not the contents of the perl script. These IRC perl bots are oftentimes built off a template, usually pulled from pastebin or packetstormsecurity. These bots also have a relatively short lifespan and small bot count. The average lifetime of the IRC bot controllers is about 2 to 3 weeks, with the longest documented by us being 6 months. Other bots like the Kaiten DDoS botnet, which came to life in 2001, have been rewritten, added to and expanded on consistently. Even now, new variants of the original Kaiten code are discovered. The most notable Kaiten variant to date is the infamous Tsunami bot.

Easy Targets

Another contributing factor is that there is no shortage of vulnerable targets. In September of 2015, CARISIRT released a report on r0_bot (also known as pnscan.2), which showed that many Linux-based devices had simple username-password combinations (root/root, ubnt/ubnt or admin/admin). Just targeting those three credential groups, we confirmed nearly 27k devices were compromised as further illustrated in this Shodan report. Even earlier than that, our password analysis of the credentials found during our research on the Supermicro PSBlock download vulnerability showed a distressing amount of default credentials. This trend has continued, as password dumps are found everyday with valid device credentials. As time goes on the bruteforce password lists are getting better and better, while password security is not. This is evidenced by the ever-growing list of valid credentials that appear on paste sites such as pastebin and quickleak. Last year, we here at CARI.net were able to turn over nearly 40,000 unique device SSH credentials to respective authorities, many of them default passwords like operator:operator and admin:admin. While 40k may seem like a lot, this is only the tip of a very large and growing iceberg. One of the primary reasons that SSH credentials are more commonly bruteforced than RDP or other remote management tools is because of how widespread it has been deployed. Not only is SSH used by server admins all over the world, but it also is turned on by default on countless other devices, such as Ubiquiti EdgeMax and AirOS devices, devices running early versions OpenWRT, and NAS-in-a-box systems like QNAP. Other projects such as OpenWebIF even have the username ‘root’ and no password required! Compounding this problem further are the issues of notification and patching. Once a device is in the consumer’s hands, a vendor can only do so much to notify the user of vulnerabilities and/or potential problems in default configurations. In the case of the r0_bot malware, we were able to work with some ISPs in notifying their customers of the issues. This was a very time-consuming process, and, while the communication with the ISPs was more than exceptional, tracking down customers is tedious work. With the advent of IPv6 and the concept of “the internet of things”, this problem can only get worse.

In addition to poor password choices and default usernames, there are also a large number of open-source software vulnerabilities that are being exploited constantly. For instance, the Elknot malware is spread almost exclusively via CVE-2014-3120 and CVE-2015-1427 RCE vulnerabilities in Elasticsearch. While patches are often available around or on the disclosure date, many of these systems must be updated manually and may require downtime. On the flip side, malware writers are very quick to update their scanners with the latest vulnerabilities faster than system administrators can schedule a time to do an upgrade.

The Booter Age

One of the most notable trends that we’ve seen is the increased use of booter services for DDoS attacks. This is not new, and nor is it unexpected. Since the rise of stresser and booter services, many service providers have suffered a wide variety of attacks that are usually characterized by a high peak, short duration, and almost completely udp-reflection-based. The majority of the DDoS attacks that we investigated were undoubtedly the work of booter services. While online stresser services can provide great testing utilities for developers and system administrators, many hide under this guise to add “legality” to their operations. Many of these booter services guarantee attack volumes of 10Gbps or more, which is easily deliverable via NTP and DNS amplification attacks. One of the better overviews of booter services can be found on Brian Krebs’ blog.

Looking Forward

Already this year is off to a quick start with the OpenSSH vulnerability CVE-2016-0777. Though not as severe as some of the vulnerabilities we’ve seen in the past couple years, this shows that this year will be no less eventful than last. As always, we here at CARI.net look forward to delivering the best service we can, as securely as we can. To further this goal, we will continue to post more security tips, tools and research here on our blog! If there is any topic you would like to see covered, please shoot us an email at sirt@cari.net.

Thanks for reading and happy new year! Regards, Zachary Wikholm Director, Security CARI.net sirt@cari.net