Deep inside CHARGEN flood attacks
The CHARGEN protocol, also known as the Character Generator Protocol, is a network service defined in 1983. Its specifications are laid out in RFC 864. CHARGEN was developed to simplify testing, troubleshooting and evaluating networks and applications. The Character Generator Protocol is based on the simple idea of providing a service that can be accessed both by TCP and UDP protocol (via port 19). If the service is accessed, it will use that connection to send a random number of random characters (data).
Unfortunately, the implementation of the protocol carries several security risks. The service is used relatively infrequently nowadays but is often still available, for example on older Windows servers, Windows desktop PCs, printers and home routers.
CHARGEN flood attacks exploit these remaining CHARGEN protocol points of contact. The most common type of these attacks uses CHARGEN as an amplifier for UDP-based attacks using IP spoofing. The attack itself is rather simple: the attacker has their botnet send tens of thousands of CHARGEN requests to one or more publicly accessible systems offering the CHARGEN service. The requests use the UDP protocol and the bots use the target’s IP address as sender IP so that the CHARGEN service’s replies are sent to the target instead of the attacker. That way, tens of thousands of replies are submitted to the target of the attack.
This is what the communication structure looks like (the example has just one bot attacking):
The attacker usually makes use of another feature of the CHARGEN protocol described in the following excerpt from RFC 864:
UDP Based Character Generator Service
Another character generator service is defined as a datagram based application on UDP. A server listens for UDP datagrams on UDP port 19. When a datagram is received, an answering datagram is sent containing a random number (between 0 and 512) of characters (the data in the received datagram is ignored).
There is no history or state information associated with the UDP version of this service, so there is no continuity of data from one answering datagram to another.
The service only send one datagram in response to each received datagram, so there is no concern about the service sending data faster than the user can process it.
The content of the requests to the CHARGEN service are ignored, and replies of random length are sent – the default for replies is between 0 and 512 characters (bytes). However, replies containing 1024 bytes are possible as well. That way, a request with a content of 1 byte may result in a reply of 512 bytes or more. This is referred to as an amplification by a factor of 512 in terms of payload. This means that an attacker need only send a small fraction of the data volume that will actually hit the target. Simply put, a bot with a bandwidth of 10 Mbps can perform an attack at over 5 Gbps – and an entire botnet can generate attacks ranging in the hundreds of Gbps.
The following CHARGEN request with a corresponding reply should demonstrate the principle of amplification very well (no layer-2 and layer-3 header shown):
- Reply from DNS resolver CHARGEN service (IP Q.W.E.R) to client (IP A.B.C.D), packet size of 508 bytes (©Link11)
In terms of payload, this means an amplification factor of 1024. The request is made up of 1 byte of data but the reply of 1024 bytes. Looking at the packet, a request packet of 60 bytes results in a reply packet of 1066 bytes, an amplification factor of 17-18.
This is what the botnet communication looks like including amplification:
The target faces several threats:
- Internet connection overload
- Overload of the components processing the packets
The worst possible outcome of this type of attack is complete failure of the target’s internet connection.
Stay updated on current DDoS reports, warnings, and news about IT security, cybercrime and DDoS protection.
Follow Link11 on Twitter
RT @MarcWilczek: 2,200 execs polled globally: Only 58% have a formal security policy, but a mere 28% of those say their employees have broa…
5 Retweets 0
RT @MarcWilczek: U.S. Critical Infrastructure Needs Greater Cyber Resilience Any intrusion, downtime or damage could have a debilitating e…
9 Retweets 0