[clug] DDos attacks using Linux hosts (mainly embedded) now "a thing": Multi-arch, multi-vuln, multi-vendor.
sjenkin at canb.auug.org.au
Wed Sep 7 02:40:19 UTC 2016
Just using Linux is no longer a protection against hackers.
There’s been an exploit kit out there in the wild since 2015.
It’s use is still building, but in the way of these things, exponential growth means they’ll saturate vulnerable m/c in months, not years.
As the skills and competency of script kiddies in using these rootkits increase, there will be more rootkits developed.
Success breeds success.
The article notes that not just embedded linux devices are being targeted & compromised.
It does NOT say that the mainstream desktop/server distros are being targeted - yet.
If anyone is teaching Uni level students a ‘security’ topic, replicating or extending these rootkits would make a good real-world assignment.
You’d need legal advise on where the limits of ‘white hat’ work tip into ‘black hat’.
Anyone intending to work with Penetration Testing or “Tiger Teams” needs to be across these legal aspects.
Even after Randall Schwartz’s conviction (1995) and expungement (2007), the line is far from clear and not internationally uniform.
The rush to connect everything to the internet is leaving millions of everyday products vulnerable and ripe for abuse.
We’ve seen internet connectivity added to appliances, athletic clothing, pill bottles and even forks.
Security, if it’s considered at all, is often an afterthought for Internet of Things (IoT) devices.
Everyone is more susceptible to attack because of this, whether they own one of these devices or not.
The security of IoT devices poses a significant threat.
Vendors of these devices must work to improve their security to combat this growing threat.
However, as a consumer of these devices, you do have options to improve your security.
If you have one of these devices, standard security best practices advice applies.
However, many IoT devices don’t allow you to configure what services are exposed,
and some use hardcoded credentials that can’t be changed,
leaving some owners with few options.
This makes researching the capabilities of these devices before purchase just as important as their operation after they are plugged in.
The use of IoT devices in botnets is not new,
but as they become more common,
we expect these types of botnets to increase in number and power.
While compromised hosts and home routers continue to be targeted,
bot herders will follow the path of least resistance.
Before spending more energy on traditional bot hosts, they’ll take advantage of the abundance of insecure IoT devices.
Until IoT device manufacturers start attending to security and device owners stop connecting them insecurely to the internet,
we can expect this trend to continue.
The source code for this malware was leaked in early 2015 and has been spun off into more than a dozen variants.
Written in C, it was designed to be easily cross-compiled for multiple architectures running the Linux operating system.
Each botnet spreads to new hosts by scanning for vulnerable devices in order to install the malware.
Two primary models for scanning exist.
The first instructs bots to port scan for telnet servers and attempts to brute force the username and password to gain access to the device.
The other model, which is becoming increasingly common,
uses external scanners to find and harvest new bots, in some cases scanning from the C2 servers themselves.
The latter model adds a wide variety of infection methods,
including brute forcing login credentials on SSH servers and exploiting known security weaknesses in other services.
We have seen a variety of implementations from different actors taking advantage of access to the leaked source code.
We expect the infection vectors, scanning methods and overall sophistication to continue to evolve.
Groups like Lizard Squad and Poodle Corp are increasingly targeting IoT devices to build botnets to conduct DDoS attacks.
They use these botnets either for their own purposes or to rent to individuals as booter or stresser services (i.e. DDoS-as-a-Service).
Security camera DVRs, used to collect video from security cameras, are among the devices currently favored by these bot herders.
These devices often come configured with telnet and web interfaces enabled,
allowing users to configure the devices and view their security footage over the internet.
Unfortunately, many are left configured with default credentials, making them low-hanging fruit for bot herders.
Most of these devices run some flavor of embedded Linux.
When combined with the bandwidth required to stream video, they provide a potent class of DDoS bots.
After the attacker has gained access to the device, their tools do not bother to identify the architecture of the device they have compromised.
Instead, they immediately execute both the “busybox wget” and “wget” commands to retrieve their DDoS bot payloads.
Then they attempt to run multiple versions of the malware compiled for different architectures (as many as 12), until one executes.
Of the bots we’ve observed participating in attacks, peaking at more than 1 million devices, a large percentage are located in Taiwan, Brazil and Colombia.
A large majority of these bots were using white-labeled DVRs generically described as “H.264 DVRs” and
DVRs manufactured by the company Dahua Technology.
We have contacted Dahua Technology to make them aware of this issue.
Our investigation shows more than one million of these two types of devices are accessible on the internet, providing a large pool of potential bots.
Of the identifiable devices participating in these botnets,
almost 96 percent were IoT devices (of which 95 percent were cameras and DVRs),
roughly 4 percent were home routers and
less than 1 percent were compromised Linux servers.
This represents a drastic shift in the composition of botnets compared to the compromised server- and home router-based DDoS botnets we’ve seen in the past.
The size of these botnets and the number of attacks they conduct varies substantially.
In the month of July, we see the median C2 communicating with only 74 bots,
with the largest observed C2 communicating with nearly 120,000 bots.
These estimates are on the conservative side, based on an incomplete view of the infrastructure,
and we expect the number of bots to actually be higher.
The number of attacks per C2 also varies.
The figure below shows the top six C2s by number of unique victims, with some C2s exceeding 100 attacks a day.
This graph demonstrates that C2 activity phases in and out.
While the median active time for a C2 is around 13 days, it is often not contiguous.
We see C2s go days, sometimes weeks, without activity before becoming active again.
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 48, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin
More information about the linux