CVE-2020-2100: Jenkins servers can be exploited to perform DDoS attacks

A vulnerability (CVE-2020-2100), discovered by Adam Thorn from the University of Cambridge, may allows attacker to abuse internet-facing Jenkins servers to mount and amplify reflective DDoS attacks.

Using a single, spoofed UDP packet can force vulnerable Jenkins servers [1] into an infinite loop of replies that can’t be stopped unless one of the servers is rebooted or has its Jenkins service restarted.


Some technical details

According to a paper by Radware Research [2]:

Jenkins, by default, supports two network discovery services: UDP multicast/broadcast and DNS multicast. The vulnerability allows attackers to abuse Jenkins servers by reflecting UDP requests off port UDP/33848, resulting in an amplified DDoS attack containing Jenkins metadata. This is possible because Jenkins/Hudson servers do not properly monitor network traffic and are left open to discover other Jenkins/Hudson instances. Jenkins/Hudson responds to any traffic on UDP port 33848. An attacker can either send a UDP broadcast packet locally to 255.255.255.255:33848 or they could send a UDP multicast packet to JENKINS_REFLECTOR:33848. When a packet is received, regardless of the payload, Jenkins/Hudson will send an XML response of Jenkins metadata in a datagram to the requesting client, giving attackers the ability to abuse its UDP multicast/broadcast service to carry out DDoS attacks.

Carefully crafted UDP packets can also make two Jenkins servers go into an infinite loop of replies, causing a denial of service against both servers. When exposed on the internet, port UDP/33848 becomes a public threat and can be abused for DrDoS or leveraged to take out multiple Jenkins clusters.


How dangerous is this?

Many DevOps teams depend upon Jenkins to continuously deploy their applications running in cloud: Radware [4] scanned the internet for vulnerable Jenkins servers and discovered nearly 13,000 of them distributed across the globe.
Given that the average bandwidth amplification factor for the Jenkins reflective amplification is estimated at 3, an attack may creates a viable DDoS threat.


Is there a fix?

Sure! The vulnerability has been fixed in Jenkins 2.219 and LTS 2.204.2 [3] by disabling Jenkins’ network discovery services (UDP multicast/broadcast and DNS multicast) by default.


References

  1. CVE-2020-2100
  2. Jenkins Denial-of-Service Attacks
  3. Jenkins Security Advisory 2020-01-29
  4. ERT Threat Alert Jenkins Denial-of-Service Attacks

Related posts

  1. The “distroless” approach to Docker containers
  2. DevSecOps: the value of “Security Champions”
  3. Some thoughts about “Shift Left” security in DevSecOps
  4. Privileged containers in Docker? A bad idea!
  5. Cybersecurity Trends for 2020