skip to content
Subscribe to COs Blog feed
Just another Chemistry Blogs Sites site
Updated: 1 hour 13 min ago

Amplification/Reflection attacks: Jenkins CVE-2020-2100

Fri, 01/31/2020 - 16:32
Jenkins

Jenkins (https://jenkins.io) is an open-source tool which can be used to automatically perform tasks such as automatic building and testing of software (continuous deployment/integration). Here in the Department of Chemistry we host some Jenkins instances used by some of our theoretical chemistry research groups, in support of their software engineering workflows.

Whilst debugging an issue with the configuration of one of our Jenkins servers, I stumbled across a documentation page on the Jenkins website: https://wiki.jenkins.io/display/JENKINS/Auto-discovering+Jenkins+on+the+network . One part in particular caught my eye:

Jenkins listens on UDP port 33848. You can either send an UDP broadcast packet (targeted to 255.255.255.255) to this port, or you can send an UDP multicast packet (targeted to 239.77.124.213) to this port. When a packet is received (the payload doesn’t matter), Jenkins will send an XML response to the sending UDP port as a datagram.

The purpose of that feature in Jenkins is to allow easy discovery of Jenkins instances on one’s network. However, there is a definite potential downside to having this feature enabled…

Distributed amplification/reflection Denial of Service attacks

In a Denial of Service attack (DoS), the attack attempts to overwhelm one or more targets by sending them an excessive amount of network traffic. One strategy that is often used is to perform a “reflected DoS” attack. This relies on the fact that UDP is designed to be a connectionless network protocol and so it is easy to send a network packet to the target system with a faked source IP address. This obscures the IP address of the attacker.

A reflected DoS attack becomes more powerful if it’s possible to also leverage a network service which leads to traffic amplification. This occurs when the size of the network response of the reflector is significantly larger than the size of the packet needed to trigger the reflection. One of the most well-known services that can be abused in this way is NTP (network time protocol): https://www.cvedetails.com/cve/CVE-2013-5211/ . One should generally ensure that network services that could be used for a reflected amplification attack are either disabled if not needed, or only accessible to trusted network ranges rather than exposed to the internet.

CVE-2020-2100

As mentioned earlier, Jenkins will respond with an XML payload if any UDP packet is sent to port 33848. Thus, even a UDP packet consisting solely of UDP/IP/Ethernet headers but zero-length payload can trigger a response. The exact payload size depends on factors such as the hostname of the Jenkins instance and the version of Jenkins being run, but is around 150 bytes: for example,

<hudson><version>2.215</version><url>https://jenkins.example.com/</url><server-id>37892b29a81b0d283ba29232452ae314</server-id></hudson>

A commonly-used measure of the size of the amplification is the bandwidth amplification factor (BAF), defined as the ratio of the size of the reflected payload to the size of the original network request. Given that Jenkins responds to a zero-length payload sent to UDP port 33848, the BAF is thus infinite! In practice that’s a slightly misleading characterisation given that the attacker must still send the layer 2/3/4 headers, but it’s still possible to have Jenkins reflect significantly more traffic than is sent to it.

The Shodan search engine (https://www.shodan.io) knows of about 81,000 Jenkins instances that are visible on the internet. Many of them will not respond to a packet sent to UDP port 33848, either because of firewall rules or having disabled Jenkins’ auto-discovery feature. Nonetheless, there are still thousands of Jenkins instances which do respond and could therefore be used as part of a distributed amplification/reflection DoS attack.

This behaviour also provides a possible DoS vector against a pair of Jenkins instances. An attacker can send a spoofed UDP packet to port 33848 on Jenkins instance A, with a spoofed source address of Jenkins instance B and source port also set to 33848. Jenkins instance A will thus send the ~150 XML response to UDP port 33848 of Jenkins instance B, in turn triggering a response which is sent to UDP port 33848 of Jenkins instance A. The subsequent infinite loop could in theory lead to resource exhaustion on either or both of the target Jenkins instances.

This security vulnerability is now listed in the CVE database under CVE-2020-2100.

Jenkins SECURITY-1641

The Jenkins project released a security advisory on 2020-01-29, when Jenkins 2.219 / 2.204.2LTS was released. As of those versions, Jenkins no longer listens on UDP port 33848 by default. According to the Jenkins documentation, it is also possible to explicitly disable the feature by setting the hudson.udp system property to -1.

Anyone running a Jenkins instance should check if their instance is listening on UDP 33848, and…

  • upgrade to the latest version of Jenkins
  • ensure the UDP autodiscovery feature is disabled if not needed
  • ensure that access to UDP port 33848 is only possible from trusted networks via suitable firewall rules

…all of which is generally good practice when running any network-facing service, of course!

2020 Cambridge Structural Database System

Wed, 01/08/2020 - 15:23

New release for 2020 now available. Please refer to our page https://www.ch.cam.ac.uk/computing/software/cambridge-structural-database-system

Windows 7: end-of-life on January 14th

Tue, 01/07/2020 - 13:18

After January 14th, Windows 7 will no longer receive security updates from Microsoft. We will thus be blocking general network access for Windows 7 computers after the 14th.

Users of departmentally-managed Windows 7 computers have already been contacted to arrange either an OS upgrade or to put suitable alternative arrangements in place.

If you’re still using Windows 7 on any computer connected to the Department network and don’t have a plan for what will happen after January 14th, please email support@ch.cam.ac.uk as soon as possible so we can try to help.

Can't find what you're looking for?

Then you might find our A-Z site index useful. Or, you can search the site using the box at the top of the page, or by clicking here.