RocketMQ Exploit Attack Demo
Why RocketMQ is vulnerable, and how to fix it.
First, the bad news: Since May 2023, threat actors have been exploiting a vulnerability in RocketMQ to deploy vicious malware. The good news? Juniper Advanced Threat Prevention (ATP) can help stop bad actors in their tracks. Tune into this episode of Juniper Threat Labs for a hands-on demo that shows you exactly how.
Protect yourself: Watch additional security demos.
You’ll learn
How the attack chain works, and how remote attackers manipulate RocketMQ
How Juniper ATP Cloud detects this malware using machine learning based on static and behavioral analysis
Who is this for?
Transcript
0:00 welcome to the Juniper threat Labs
0:02 attack demo Series in this demo we will
0:06 be talking about Racket mq and examine
0:09 how threat actors exploit it and deploy
0:11 a Linux
0:13 malware following that we'll show you
0:16 how Juniper customers can be protected
0:18 throughout the attack
0:21 chain in May
0:23 2023 a vulnerability affecting rocket mq
0:26 servers which allows remote code
0:29 execution was publicly
0:31 disclosed shortly after that in early
0:35 June Juniper treat Labs began seeing
0:37 attacks targeting this
0:40 vulnerability the attacks installed a
0:43 malicious Linux binary file dabbed as
0:46 dream bass bot which is capable of
0:48 downloading and installing other modules
0:51 including a spreader a miner as well as
0:54 update itself it was also observed in
0:58 other news that multiple TR actors are
1:01 exploiting this vulnerability this
1:03 prompted the cyber security and
1:05 infrastructure Security Agency to
1:08 release an advisory warning regarding
1:10 this
1:11 vulnerability let's understand the
1:13 attack chain this vulnerability enables
1:17 a remote unauthenticated attacker to
1:19 manipulate the racket mq broker
1:22 configuration in order to abuse a
1:24 command injection as detailed in junor
1:26 threat lab's blog one of the threat
1:28 actors l Lage this vulnerability to
1:32 deploy the dream bass bot dream bass is
1:34 capable of updating itself as well as
1:37 installing other components such as a
1:39 spreader module and a Monero
1:42 Miner with that let's dive into the
1:45 simulation of this
1:49 attack let's assume that this C Linux is
1:52 the attacker's
1:54 [Music]
1:56 machine our Target victim has an IP
1:59 address
2:00 192.168
2:03 20637 we first run the python script
2:06 check. py to verify whether This Server
2:10 is
2:15 vulnerable after verifying that the
2:18 server is vulnerable we can now proceed
2:20 with our
2:22 attack for this demo we will be using a
2:25 payload that will download dream bassbot
2:28 via curl into the target server temp
2:32 directory we will host grebas bot in the
2:35 same Cen Linux
2:46 [Music]
2:50 machine after launching the attack
2:53 shortly we saw a get request on our coli
2:55 machine to download dream buas
2:58 bot
3:06 [Music]
3:09 we can confirm the successful
3:11 exploitation by going to our victim
3:13 machine and listing the file we can also
3:16 check in virus total that the file is
3:19 indeed
3:23 [Music]
3:28 malicious
3:33 [Music]
3:35 let's now look and see whether or not
3:38 this attack works as successfully with
3:40 the Juniper SRX firewall enhanc with
3:43 protection from Juniper's cloud-based
3:45 Advanced antimalware solution Juniper
3:48 ATP for the demo Juniper trat Labs is
3:52 using the following setup we have a vsrx
3:55 pictured in the center the vsrx is a
3:58 virtual SRX for firewall providing
4:01 network security protection its purpose
4:03 is to inspect Network traffic and with
4:05 the assistance of juniper ATP Cloud to
4:08 detect malware like dream buas but in
4:11 addition to the virtual firewall and
4:13 cloud-based protections we are using
4:15 Juniper security director which is a
4:18 centralized management system it is used
4:21 to facilitate our configuring and
4:23 monitoring of the vrx firewall and we
4:26 are using Juniper's policy enforcer as
4:28 well Juniper policy enforcer enforces
4:31 security policies on endpoints and
4:33 ensures they comply with corporate
4:35 security standards we also have several
4:38 Windows
4:39 workstations Each of which is connected
4:42 to the vsrx finally we have an abun
4:45 server acting as the malware download
4:48 server before we proceed with our
4:50 attempt to execute the attack using
4:52 Juniper connected Security Solutions
4:54 let's first examine the various policies
4:56 we've configured within our security
4:59 directory and appli to the vsrx for this
5:02 demonstration we've set up an IPS policy
5:05 to detect the exploit and a threat
5:07 prevention policy to detect and block
5:09 the payload to access the IPS policy
5:13 navigate to the configure Tab and select
5:16 IPS
5:17 policy you'll see that we have an
5:20 existing policy named racket mq policy
5:24 drop this policy is configured to
5:26 include the IPS signature the specific
5:29 Bally detecting the rocket mq exploit
5:32 and it's set to drop any Pockets
5:34 associated with the
5:36 exploit moving on to the threat
5:39 prevention policy select threat
5:41 prevention under the configure tab
5:44 you'll notice that we also have an
5:46 existing policy in
5:48 place let's further inspect the
5:50 protections being enforced by the
5:52 applied
5:54 policy for this demo our policies are
5:57 configured to block command and control
5:59 control traffic at Threat Level 8 and
6:02 above we've also set it up to block
6:05 infected hosts at Threat Level 8 and
6:08 above additionally we've configured our
6:11 policy to use ATP cloud from malware
6:14 detection and as you can see we've
6:16 elected to scan HTTP downloads and block
6:19 threats at level 7 and above this threat
6:23 prevention policy implied to the Juniper
6:25 vsrx firewall is a critical component of
6:28 our defenses
6:29 protecting our systems against malware
6:32 related attacks it not only detects and
6:35 blocks malicious traffic but also
6:37 prevents potentially infected hosts from
6:39 spreading malware across our Network
6:42 should one of our systems gets
6:44 compromised to show you that these
6:45 policies are applied to our vsrx
6:48 navigate to firewall policy and select
6:51 unified policies our SRX device labeled
6:54 as jz-
6:56 cs-40 is configured to use both the the
6:59 IPS policy and the threat prevention
7:01 policy we configured earlier with that
7:04 let's now proceed on launching the
7:05 attack with juniper connected Security
7:07 in place to start we SSH to our attacker
7:11 machine our Target server has an IP
7:14 address 10.
7:17 0.1.4 from this SSH session we initiate
7:20 the attack using a python script and a
7:23 payload to download a Dream bassbot from
7:25 our malware download server at 192.168
7:28 71 51 which is also the attackers
7:31 machine we run the script and press
7:35 [Music]
7:36 enter so what
7:39 happened Juniper SRX through its IPS
7:43 detected the attack and dropped the
7:45 pocket to confirm this we access our
7:48 security director navigate to Monitor
7:51 and select events and logs followed by
7:56 IPS there we find an IDP attack log
8:00 event clicking more and show event
8:03 details provides information about the
8:05 source IP attack name policy name
8:09 destination ipn port and the action
8:13 taken additionally on the target server
8:16 we observe no HTTP pocket confirming the
8:20 attacks
8:22 failure next we want to test whether a
8:24 threat prevention policy can detect
8:27 malware to do this we reconfigure our
8:30 IPS policy to log the attack but not
8:33 drop the
8:34 pocket we've created a new IPS policy
8:37 named rocket mq policy no
8:41 action upon inspecting this policy
8:43 you'll notice that it includes the IBS
8:46 signature to detect the rocket mq
8:48 exploit but the action is set to no
8:52 action to apply this new policy to our
8:55 vsrx return to unified policies under
8:58 fir
8:59 policy go to the rules select the IPS
9:03 policy and use bracket mq policy no
9:09 action we will still use the same threat
9:12 prevention policy we have configured
9:14 earlier click okay save the changes and
9:18 publish this updated policy to our vsrx
9:28 device
9:35 with the policy adjustments made we
9:38 relaunch the
9:41 [Music]
9:47 talk W shark captures an HTTP get
9:50 request for dream bass
9:52 bot however inspecting the TCP stream
9:55 reveals that the SRX has blocked
9:58 response
9:59 due to possible malware
10:02 detection the exploit successfully reach
10:05 a rent point but the payload to download
10:07 brabas malware was
10:12 blocked we can confirm that when we go
10:14 back to our security
10:21 director and we can see that we have an
10:23 IDP attack lag event showing that we
10:27 detected the exploit selecting ATP Cloud
10:30 shows Advanced anti- malware action
10:36 log clicking Show event details provides
10:40 information like the source IP
10:42 destination IP and Port policy name
10:46 action taken and the
10:51 URL further details about this malicious
10:54 file can be found under threat
10:56 prevention by clicking on H HTTP file
11:01 download here the file dream bus bot is
11:04 detected at Threat Level
11:07 8 clicking on the hash reveals
11:10 additional information including
11:12 behavioral analysis network activity and
11:15 behavioral
11:20 details now we click on ATP Cloud hosts
11:24 note that while the attack was
11:26 unsuccessful recall that the security
11:29 policy being enforced on the vsrx locks
11:32 the host network activity when threats
11:35 at level 8 and above are detected in our
11:38 case our host Threat Level is now
11:41 categorized as nine due to the malicious
11:43 activity detected as a result this host
11:47 is now included in the infected host
11:49 feed what this means is that this host
11:51 10.
11:53 0.140 is now isolated and disconnected
11:56 from the network temporarily
11:59 clicking at this host provides us with
12:01 more details on why it is blocked which
12:04 in this case the host attempted to
12:07 download a malicious file we can confirm
12:10 that this host is disconnected as we
12:12 cannot ping or connect via rdps
12:15 [Music]
12:26 before once the admin is sure that the
12:29 host or server is indeed free from
12:31 infection she can first select the host
12:35 and then under the investigation status
12:37 section she can select resolved fixed
12:41 which changes the status of this host to
12:44 clean after a few moments this host will
12:48 be connected back to the network again
12:51 we can verify that once again by
12:53 connecting to it via RDP and browsing
12:56 the
12:57 net
13:03 [Music]
13:10 that completes our demo of Rocket mq
13:12 exploit check out more videos from the
13:15 Juniper trat Labs attack demo series by
13:18 visiting juniper.net thanks for watching