What are Distributed Denial of Service (DDoS) attacks?

Distributed Denial of Service (DDoS) attacks typically target websites in an attempt to bring down or ‘crash’ the site. It is a common tactic for activists and groups looking to suppress information. Some attackers use DDoS as a form of extortion; demanding money from the victim to cease to attack.

When sustained for long periods, a DDoS attack can cost the site owner lost revenue either by preventing potential customer’s access and/or reducing ad views. Furthering the problem, protection for such attacks can be expensive and most professional hosting companies offer only limited protection.

Hackers have also used DDoS attacks as a smokescreen. The additional traffic and generated logs can overwhelm intrusion detection systems and security teams allowing the attacker to execute their true intention.

How does a DDoS attack work?

DDoS attacks work by flooding the target with large amounts of data, or requests for data, that consume a server’s resources. With a small attack, legitimate visitors to the site may experience a slow connection, but large attacks can bring down a website.

One of the most common attack methods for generating a lot of traffic with a smaller number of devices is called DNS Reflection or DNS Amplification. This type of attack takes advantage of one of the most fundamental principles of the internet. When you type into a browser a URL (like www.tycosecurityproducts.com), a request happens in the background to find the IP address for that site; this is called a Domain Name System (DNS) request.

The request is only 64 bytes, but the response can be up to 512 bytes. This is an 8:1 amplification ratio, but other features of DNS can allow the amplification to be as high as 70:1. An attacker will exploit this fundamental feature by creating DNS requests. However, before the request is sent, it is modified to replace the sender’s IP address with that of the victim. This causes the DNS server to send the DNS information to the victim instead.

What is a botnet?

To maximize the number of requests, attackers will use a ‘botnet’, or a network of devices, infected with malware that allows the attacker to control the device remotely. Because the malware does not affect the devices normal operation, the device owner will not know it has been compromised.

A botnet controller could have access to hundreds of thousands of devices. The controller makes the botnet send DNS requests with spoofed sender addresses (DNS Reflection); they can generate enough traffic targeting the victim to create a DDoS attack.

Because DNS requests are essential and the packet size is so small, most network monitoring systems will not detect a compromised device on their network. Further, attackers know how to limit and distribute their bots to avoid detection.

Figure 1 DNS Amplification/Reflector Attack (Source: https://www.publicsafety.gc.ca/cnt/rsrcs/cybr-ctr/2013/tr13-002-eng.aspx) 

Update: The type of attack being used by the large IOT botnets today are not using amplification nor are they spoofing their IP address. Some DDoS protection methods employ blocking traffic from an IP address if it has too many requests. By having so many infected products, an attack can be successful just through normal web requests from so many unique IP addresses. Also, attackers are not worried if a device is detected and blocked, because there are still plenty of vulnerables devices available.

How do they create a Botnet?

To create botnet, an attacker has to identify vulnerable devices and infect them with their control software. There are two well established pieces of malware active in creating botnets in IOT products: BASHLITE and Marai. The source code for BASHLITE was made public last year and there is many variations, but they all essentially operate the same way. The Marai source code was made public the first time last week and the Cyber Protection Team acquired a copy of Marai for investigation.

A malicious server will scan the internet for devices with open telnet ports. Telnet is a protocol that allows for remote access to a device. It is employed typically in security products (such as cameras, DVRs and control panels) to allow remote management of the device or to assist support and setup.

Telnet has been deprecated based on security concerns including lack of encryption. Modern devices will employ SSH which offers encryption and other security features.

When the scanner identifies a possible target, it uses a list of default and common credentials (admin/admin, admin/12345, support/support, etc.) to try to authenticate to the device. When successful, it will try to inject malware unto the device that will allow the botnet owner to control it from a central command and control program.

What types of products are vulnerable

This infection process is only possible if access the device's underlying operating system as accessible; typically through telnet or SSH. If these ports are not open, the scanner will not detect the device.

Telnet and SSH are common among physical security products. While many device manufacturers have disabled these protocols by default, some still allow them to be enabled through the user interface. Devices with the protocols enabled will be detected by the scanner.

The telnet or SSH credentials for many products are the same as the web login credentials. This could allow a more dedicated attacker to find the device through its web interface looking for its web interface and then brute force those credentials. Once they have access to the web page, they could enable telnet or SSH and then compromise the device.

What if my device isn’t connected to the Internet?

While only internet connected devices can be detected by the scanner, this does not take into account the reality of most security product installations. Many of these devices, especially cameras and recorders, are installed to be accessible remotely for monitoring purposes.  End-user and installers can also mistakenly connect a device to the internet. Manufacturers are even including and promoting features to support this such as Universal Plug and Play (UPnP) and cloud streaming.

What can installers and end-users do?

A firmware update may not be required

Updating the firmware to the latest version is the typical ‘go-to’ response for device manufacturers when a security issue arises, but the practicality of performing updates should be considered as well. Firmware updates may be part of the service agreement between installers and the end users, but often this service is only performed once or twice a year may also have fees associated for the end user for such a service call.

If the botnet scanners were seeking a particular flaw in the device, then a firmware update would be mandated. However, all indicators at this point suggest that the scanners are simply exploiting default and weak credentials in telnet and SSH. To ensure a device is not part of a zombie network, simply follow the steps listed below.

Inventory all devices

Check the inventory of all devices and if remote access protocols have been enabled. This can usually be done through the device’s web interface, but a port scanner can detect open ports on multiple devices quickly.

The Cyber Protection Team has discovered devices with telnet or other remote access protocols enabled without the indication to the end user or installer. If the device does not notify through its user interface that such a protocol is running, then only a port scanner will be able to detect it. Easy to use scanners such as nmap or zenmap are freely available on the web to detect open ports. If the protocol is detected by a port scanner and cannot be disabled through the user interface, a firmware update might be required.

If the remote access to the device is not critical, disable it. Besides becoming a member of a botnet, a malicious user gaining remote access to the device’s operating system can cause serious problems. The device can be compromised to perform other malicious activities including spreading malware on your network.

Reset the device

If the device did have a remote access protocol enabled, reset the device. The firmware image for these devices includes the operating system files. Resetting the device will return the system to its default state removing any malware in the process.

Change the password

If you have not done it yet, change the password to a complex password. The scanners are looking for default and easy to guess credentials. For example, the original Marai malware will try several password combinations composed primarily of common default credentials. Avoid other easy to guess often used credentials such as ‘security’ as well.

Botnet scanners are looking for as many devices as possible and will not spend too much time trying to ‘crack’ into any one device. However, if your device does have telnet or SSH enabled with the default or weak credentials (i.e. security/security) it will eventually be detected and added to a botnet or worse.

What about Tyco products?

Illustra Cameras – Not Affected

Illustra cameras were designed to prevent user access to the camera’s operating system. As a result, no Illustra camera supports telnet.

There are Illustra Pro cameras that support SSH for remote technical support. However, they will be immune from these scans:

- SSH is not enabled by default

- The SSH credentials are not the same as the web credentials

- The SSH credentials are complex and unique for every camera

If the camera was left with default credentials, or if a botnet scanner was able to brute force the camera’s web credentials, the attacker would still not be able to access the camera’s operating system from the web interface to inject the malware.

VideoEdge NVR – Not Affected but be cautious

The VideoEdge NVR will not be affected by the known botnet scanners. These scanners are seeking particular versions of Linux to infect and SUSE is not among them. Additional features within the VideoEdge architecture also prevent malicious files from being imported.

However, to support installation, VideoEdge does come with SSH enabled by default. While the default credentials are not listed in the released credentials list, it is still best to either disable the service if not used, or change the passwords from default.

iSTAR Controllers – Not Affected

iSTAR controllers do not support any remote access protocol and will not be detected by these scanners.

C•CURE 9000 and victor – Not Affected

These Windows applications are not affected and do not require telnet, SSH, or other remote access protocols. The host machine may employ remote access mechanisms and could be infected by other malware, so always take precautions to protect it such as employing malware detection and applying Windows updates regularly.

Where can I find additional information?

http://securityaffairs.co/wordpress/51640/cyber-crime/tbps-ddos-attack.html

http://securityaffairs.co/wordpress/50824/malware/bashlite-botnets.html

http://blog.level3.com/security/attack-of-things/

https://krebsonsecurity.com/2016/09/krebsonsecurity-hit-with-record-ddos/

https://krebsonsecurity.com/2016/10/who-makes-the-iot-things-under-attack/

This article was originally posted on LinkedIn.