CharGEN cyberattacks based on the CharGEN protocol

After the preliminary study denial of service (DoS) cyberattacks alongside any of their variants set out in the article “DrDoS, characteristics and operation,“ this new article is going to address how the CharGEN protocol is used as a tool to develop a DrDoS variant of a DoS cyberattack.

CharGEN

The Character Generator Protocol (CharGEN), was designed to be used in debugging and measurement tasks, which are used check the status of network connections, whether the buffer is working properly, and possible electronic limitations. It can also be used to check the bandwidth and quality (QoS) of a network, all by sending a constant flow of bytes.

It works by following the specifications of RFC 864, using port 19, to which one may connect using the UDP and TCP transport protocols. In Unix and similar systems, the CharGEN service is integrated with the platform, and is not activated by default, like a program that provides network services in the background, making up an inetd or xinetd daemon. To check the CharGEN connections, when connecting over a TCP connection, the server sends random data without interruption until the other end closes the session and disconnects from the server. When the connection is over UDP, the server sends response UDP datagrams, which have a random number of characters (between 0 and 512), as long as it receives service requests from the other end of the CharGEN server.

- Figure 1. Diagram of how CharGEN works -

Attack vector

The UDP transport protocol makes CharGEN servers vulnerable to denial-of-service attacks or to being used as intermediate servers to cause them. The vulnerability of the CharGEN protocol, which is widely used in communication with remote printers, is well known and fairly accessible for attackers. So much so that there are some Trojans that specialise in exploiting this security breach, which is aggravated in the case of office IT machines, such as printers, since they are not a company’s priority when applying updates or patches.

The attack pattern for denial of service by CharGEN is on the same lines as the rest of the DrDoS attack variants. The attacker identifies as many servers as possible that have activated the CharGEN service and which are publicly accessible. These machines will act as intermediaries to disable the victim machine on which the attack is launched; to achieve this, the attacker will use a botnet to send them thousands of CharGEN requests with the spoofed source IP address (replaced with the victim’s IP address). When intermediate machines receive requests from the botnet, they direct their responses to the victim’s IP address, which receives packets of a size between 200 and 1,000 times larger than when they were generated in the original request. The high number of requests launched from the botnet platform, along with the increase in the size of the responses, inevitably causes the end target machine to crash due to its being impossible to absorb and process all the traffic that reaches it.

- Figure 2. Diagram of the attack on CharGEN -

Due to the operating characteristics of the CharGEN services, the use of this protocol makes it possible for the attackers to be able to redirect the inundation of traffic to any active UDP service in the victim machine, modifying the data on the requests’ source port.

Besides the harm that may be done to the victim by their attacked systems being out-of-use, the CharGEN servers involved in the attack may also be affected and crash due to the large number of inquiries received from a botnet consisting of tens, hundreds or thousands of zombie machines.

In this regard, it should be noted that the legitimate owners of the deceived CharGEN servers may face legal problems, since, for the victim, the source of the DoS attack lies in the intermediate CharGEN devices and claims could be lodged against their owners.

Prevention

Any CharGEN server with public port 19 on the Internet will be vulnerable to a DrDoS attack. To verify whether an own server is exposed on the Internet, the following two actions can be taken:

• Search in the firewall for rules that allow UDP port 19 towards the exterior.
• Run the following nmap command:

sudo nmap -sU -p19 [IP Server] -oG –

If the following line “Ports: 19/open/udp//chargen///” is included in the command’s output, the server will have port 19 open and will therefore be vulnerable.

The preventative measures recommended to prevent an own CharGEN service from participating voluntarily in a DrDoS attack against third parties are as follows:

• Update the software. This is a protocol that is in disuse and the most effective way to mitigate possible attacks through this service is to update those machines that connect by means of this protocol so that they use other connection technologies.
• Set out a protocol for action in the event of DrDoS CharGEN attacks: to provide a quick and effective response to minimise adverse effects if they arise. This procedure must be suitable for the characteristics of the organisation and set out how to identify these attacks.
• Ask your Internet service provider (ISP) for anti-spoofing filters. An ISP may reject portmap traffic with spoofed addresses, which are not accessible through the actual path of the package. This will prevent portmap itself from receiving and serving queries liable to be an amplified denial-of-service attack.
• Deploy the servers with CharGEN behind firewalls. An anti-spoofing configuration must be established in the firewall with rules to detect and filter requests sent through UDP to port 19 of the devices using CharGEN and which have spoofed source IP addresses.
• Limit the visibility of the CharGEN server on the Internet. IP address filtering would limit access to the server so that it is not “public”. This measure, like the previous recommendation, can be established using rules in the firewall.
• Deploy intrusion detection and prevention systems (IDS/IPS): it would make it possible to monitor the connections and warn that unusual traffic has been detected in the protocols associated to portmap.
• Deploy machine health monitoring systems: to monitor specific situations in which there is intensive use of the network, processor and RAM resources, as signs of overloading caused by a denial-of-service attack on the servers.
• Hosting protection measures: learn about the protection measures the Internet or hosting service provider has implemented or which can be contracted to reduce the impact of DoS attacks. Likewise, it is necessary to verify with the supplier that they are deployed and activated and to determine who is responsible for configuring and administering it.

Detection and evidence

To locate a type of signal revealing that a CharGEN device is being used for a DrDoS attack, the cache of the device giving rise to the suspicions may be reviewed, as may unusual activities related to port 19, where this service works. Likewise, a more exhaustive analysis may be undertaken on the packets that are being sent, reviewing the source IP address and the size of those packets.

If feasible, it is recommended that security information and events manager be deployed (devices such as SIEM), which monitor the machine and system logs. It will thus be possible to identify more easily and quickly the machines that may be affected. This information can also be extracted thanks to the firewall, provided that it filters port 19.

Response and recommendations

If the DrDoS attack has been detected, it is important to have a series of measures laid out in advance to help to quickly manage the attack. These measures must bear in mind the following aspects:

• Identifying the source and destination IP address, as well as the destination port. All useful information must be collected to communicate to the ISP in order that it may be blocked. This information will include the IP addresses whence the modified packets are being sent.
• Disconnect the device from the network, by disabling the network card or directly switching the device off.
• Contact the hosting or Internet provider. Once all the relevant information has been collected, it is necessary to contact the Internet provider, which will block those IP addresses and implement other additional measures.
• Blocking and filtering unwanted traffic. From within the network, it is recommended that filters be enabled to block all requests or sending of untrustworthy IP addresses through firewalls and routers. This will help mitigate spikes in bandwidth consumption.
• Obtaining technical assistance: contacting the IT technical services suppliers that have contracted or the leading public computer emergency response teams (CERT) such as INCIBE-CERT.

When the attack has ended, it is necessary to inspect the damage caused and the consequences thereof. It is recommended that an investigation be conducted into the reasons why the attack occurred (whether or not it was preventable) and whether the response to it was effective and fast enough. Once this has been done, it is recommended that further measures be taken to prevent a new attack.

Finally, attacks that occur must be reported to the relevant authorities to investigate and process any online crime. Likewise, the legal staff of the organisation must be informed of the harm that both it and third parties may suffer.