In the wake of the serious Jenkins vulnerability impacting at least 12,000 Jenkins servers, we dedicate February’s Nexus Intelligence Insights to helping you solve it.

This vulnerability is clever; it opens up two potential lines of attack. One is through amplification and reflection; the other kickstarts an infinity loop. Both malicious possibilities are described below.

But first, how was CVE-2020-2100 discovered, who and what does it affect, and how can it be fixed?

/ Network Amplification, leading to Denial of Service (DoS)



CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:L

Discovered by University of Cambridge’s Dr. Adam Thorn and known as CVE-2020-2100, the flaw takes advantage of the fact that, by default, both UDP multicast/broadcast and DNS multicast traffic is enabled on Jenkins. Additionally, Jenkins does not properly verify incoming traffic requests. This proves to be problematic because it can essentially compromise the availability of a Jenkins instance. The instance can then be manipulated by an attacker to cause Distributed Denial of Service (DDoS) attacks against the attacker’s choice of target(s).

Image credit: https://en.wikipedia.org/wiki/File:Ddos-attack-ex.png

Jenkins is an open source automation tool used extensively by the developer community. Organisations use Jenkins to take care of menial tasks, such as running builds and routine scripts, and performing unit tests after every change, or as configured by a developer. You can see the reason behind Jenkins’ popularity - it’s appealing to devs when it comes to saving time and “automating away” the same, monotonous tasks which are an integral part of the software development workflow.

According to Shodan, upwards of 260,000 devices are currently running public-facing Jenkins server instances. Unless sysadmins behind them are super-diligent beings who have upgraded their Jenkins, a vast majority of these instances would still be exploitable, thanks to this recently discovered vulnerability.

Why does it matter?

UDP is the backbone protocol that powers essential services including DNS, NTP, NetBIOS and LDAP which make the internet possible. However, its lightweight design blatantly favours speed of delivery (of packets) from source to destination, with virtually no regard to reliability and security of data in transit. As such, additional security checks and mechanisms built into protocols like TCP and Google’s QUIC, are absent from UDP.

Amplification attacks, especially those impacting UDP-based protocols, work gracefully because an attacker needs to only send a small-sized crafted request, as tiny as a single byte, which tricks a vulnerable system into returning a response which is, say a 100x or so larger. As stated in the Jenkins advisory:

“a single byte request to this service would respond with more than 100 bytes of Jenkins metadata which could be used in a DDoS attack on a Jenkins master. Within the same network, spoofed UDP packets could also be sent to make two Jenkins masters go into an infinite loop of replies to one another, thus causing a denial of service.”

You can see the potential for damage arising from this kind of an attack, given some 260,000+ Jenkins instances are internet-facing and can be crashed by an attacker, unless patched.

How can an attacker exploit this/attack mechanics:

There’s two ways this attack can be carried out:

UDP Amplification & Reflection

In this scenario, an attacker simply crafts a UDP request with the “source IP” listed in it as that of the victim (target machine). This falsely gives off the impression that the request is originating from the victim’s machine. The “destination IP” is listed as that of an exposed Jenkins server along with UDP port 33848. A vulnerable Jenkins server, upon receiving this request, under the impression it originated from the spoofed source IP returns large amounts of data (therefore the name “amplification reflection attack”) to the victim’s machine. This process repeated multiple times by an attacker, especially concurrently, can crash the victim’s machine.



DNS Infinite Reply Loop

The second part of this exploit is rather simpler but much more clever. It leverages the how Jenkins implements its discovery protocol over UDP. To facilitate auto-discovering of Jenkins instances on a network, the service does not discriminate between incoming requests and would respond to any and every request without care for its contents.



An attacker can “spoof” DNS requests between two exposed vulnerable Jenkins servers. Within the request, the “source” and “destination” IPs can be listed as those of these two very servers, thereby causing them to enter into an “infinity reply loop”, eventually crashing each other, by sending too many requests and replies.

Users of Nexus IQ and Sonatype products benefit from the following information

Sonatype’s Explanation:

jenkins-core

DNSMultiCast.class

hudson.DNSMultiCast.disabled

false

UDPBroadcastThread

UDPBroadcastThread.class

hudson.udp

33848

Thepackage is vulnerable due to Insufficient Control of Network Message Volume. The DNSMultiCast method inenables DNS multicast by settingtoby default. Themethod inenables UDP multicast/broadcast by settingto portby default. A remote attacker can exploit these services by sending a few bytes to a Jenkins endpoint that would generate much larger responses, or by sending spoofed UDP packets to cause two Jenkins masters to go into an infinite loop of replies. This would eventually lead to a Denial of Service (DoS) situation.

Vulnerable Components:

You are vulnerable if you are running any of the following components with a version within the specified range:

Jenkins

org.jenkins-ci.main:jenkins-core:



For Jenkins 2.205.x: [2.205, 2.219)

For Jenkins LTS 2.204.x and below: ( , 2.204.2)

io.provis:provisio-jenkins-runtime: all versions are vulnerable

Eclipse Hudson (legacy Jenkins)

org.eclipse.hudson:hudson-core: all versions are vulnerable

org.eclipse.hudson.main:hudson-core: all versions are vulnerable

org.jvnet.hudson.main:hudson-core: [1.282 , )

Remediation and Recommendation:

To resolve the flaw, the fix implemented by the Jenkins team simply disables the DNSMultiCast property and “closes up” port 33848 as a way to prevent these attacks.

Users running Jenkins Core component, `org.jenkins-ci.main:jenkins-core`, should upgrade to version 2.219 which contains a resolution to this vulnerability. For users running Jenkins LTS, versions 2.204.x and below, a fixed version 2.204.2 exists.

Note: If this component is included as a bundled/transitive dependency of another component, there may not be an upgrade path. In this instance, we recommend contacting the maintainers who included the vulnerable package. Alternatively, we recommend investigating alternative components or a potential mitigating control.

For users of the dated Eclipse Hudson project, support for which has been terminated, please investigate an alternative technology. The most similar technology would likely be Jenkins, having originally been developed as Hudson, however another project may better suit your needs now.

DevOps-native organizations with the ability to continuously deploy software releases have an automation advantage that allows them to stay one step ahead of the hackers. Customers of Sonatype Nexus were notified of CVE-2020-2100 within hours of the discovery. Their development teams automatically received instructions on how to remediate the risk.

If you're not a Sonatype customer and want to find out if your code is vulnerable, you can use Sonatype's free Nexus Vulnerability Scanner to quickly find out.

Visit the Nexus Intelligence Insights page for a deep dive into other vulnerabilities like this one or subscribe to automatically receive Nexus Intelligence Insights hot off the press.

...

UPDATE: Please note while Jenkins advisory mentions the 100x response size that applies to the payload only. The average amplification factor with regards to the actual frame size is 3.00, according to credible sources.