Lucene search

K
attackerkbAttackerKBAKB:A29F033F-47F8-4658-B470-4A3F541E9175
HistoryMay 03, 2019 - 12:00 a.m.

Cisco Nexus 9000 Series Fabric Switches Application Centric Infrastructure Mode Default SSH Key Vulnerability

2019-05-0300:00:00
attackerkb.com
39

0.003 Low

EPSS

Percentile

71.7%

A vulnerability in the SSH key management for the Cisco Nexus 9000 Series Application Centric Infrastructure (ACI) Mode Switch Software could allow an unauthenticated, remote attacker to connect to the affected system with the privileges of the root user. The vulnerability is due to the presence of a default SSH key pair that is present in all devices. An attacker could exploit this vulnerability by opening an SSH connection via IPv6 to a targeted device using the extracted key materials. An exploit could allow the attacker to access the system with the privileges of the root user. This vulnerability is only exploitable over IPv6; IPv4 is not vulnerable.

Recent assessments:

bcook-r7 at May 09, 2019 5:57pm UTC reported:

This requires IPv6 and particular settings to be enabled

Waiting for machine to boot. This may take a few minutes…

default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key



It seems you have to configure the virtual switch with a virtual serial port.

## VM Contents:

There are only a few EXT3 filesystems that have useful data in the VMDK image. I think the most interesting bits are going to be inside of nxos.9.2.2.bin which is perhaps decoded or interpreted by the kernel or bootloader.  The boot screen in the VM looks like it uses a modified version of GRUB and the Linux kernel, though my current environment has insufficient memory to make it actually boot.

> <fs> add-ro ## Vulnerable targets:

It’s not clear if the 9000v virtual switch is vulnerable but that is the easiest to target for now, since it does not need special hardware.

The setup is here: <https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/nx-osv/configuration/guide/b_Cisco_Nexus_9000v/b_Cisco_Nexus_9000v_chapter_011.html&gt;

NXOSV VM download

Downloading the ‘Vagrant’ image and running it with a basic Vagrantfile showed this output, which hung forever:

Bringing machine 'default' up with 'virtualbox' provider...
==&gt; default: Clearing any previously set forwarded ports...
==&gt; default: Clearing any previously set network interfaces...
==&gt; default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==&gt; default: Forwarding ports...
    default: 22 (guest) =&gt; 2222 (host) (adapter 1)
==&gt; default: Booting VM...
==&gt; default: box-disk1.vmdk
&gt;&lt;fs&gt; run
&gt;&lt;fs&gt; list-filesystems
/dev/sda1: vfat
/dev/sda2: ext3
/dev/sda3: ext3
/dev/sda4: ext3
/dev/sda5: ext3
/dev/sda6: e
boot
cfglabel.sysmgr
debug
dme
licenses
linux
log
lost+foundxt3
/dev/sda7: ext3
&gt;&lt;fs&gt; mount /dev/sda3 /
&gt;&lt;fs&gt; ls /
lost+found
&gt;&lt;fs&gt; mount /dev/sda1 /
&gt;&lt;fs&gt; ls /
EFI
&gt;&lt;fs&gt; mount /dev/sda2 /
&gt;&lt;fs&gt; ls /
lost+found
&gt;&lt;fs&gt; mount /dev/sda3 /
&gt;&lt;fs&gt; ls /
lost+found
&gt;&lt;fs&gt; mount /dev/sda4 /
&gt;&lt;fs&gt; ls /
nxos.9.2.2.bin
&gt;&lt;fs&gt; mount /dev/sda5 /
&gt;&lt;fs&gt; ls /
lost+found
&gt;&lt;fs&gt; mount /dev/sda6 /
&gt;&lt;fs&gt; ls /
ascii
bin
no-erase
&gt;&lt;fs&gt; mount /dev/sda7 /
&gt;&lt;fs&gt; ls /
lost+found

I copied out the .bin file, which appears to be another filesystem.

&gt;&lt;fs&gt; mount /dev/sda4 /
&gt;&lt;fs&gt; copy-out /nxos.9.2.2.bin .

$ file nxos.9.2.2.bin
nxos.9.2.2.bin: DOS/MBR boot sector



binwalk ./nxos.9.2.2.bin
--------------------------------------------------------------------------------
0             0x0             Netboot image, mode 2
1024          0x400           Microsoft executable, portable (PE)
17844         0x45B4          gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)
2010881       0x1EAF01        MySQL ISAM index file Version 7
6283776       0x5FE200        gzip compressed data, maximum compression, from Unix, last modified: 2018-11-05 06:20:17

asoto-r7 at July 24, 2019 8:37pm UTC reported:

This requires IPv6 and particular settings to be enabled

Waiting for machine to boot. This may take a few minutes…

default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key



It seems you have to configure the virtual switch with a virtual serial port.

## VM Contents:

There are only a few EXT3 filesystems that have useful data in the VMDK image. I think the most interesting bits are going to be inside of nxos.9.2.2.bin which is perhaps decoded or interpreted by the kernel or bootloader.  The boot screen in the VM looks like it uses a modified version of GRUB and the Linux kernel, though my current environment has insufficient memory to make it actually boot.

> &lt;fs&gt; add-ro ## Vulnerable targets:

It’s not clear if the 9000v virtual switch is vulnerable but that is the easiest to target for now, since it does not need special hardware.

The setup is here: <https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/7-x/nx-osv/configuration/guide/b_Cisco_Nexus_9000v/b_Cisco_Nexus_9000v_chapter_011.html&gt;

NXOSV VM download

Downloading the ‘Vagrant’ image and running it with a basic Vagrantfile showed this output, which hung forever:

Bringing machine 'default' up with 'virtualbox' provider...
==&gt; default: Clearing any previously set forwarded ports...
==&gt; default: Clearing any previously set network interfaces...
==&gt; default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==&gt; default: Forwarding ports...
    default: 22 (guest) =&gt; 2222 (host) (adapter 1)
==&gt; default: Booting VM...
==&gt; default: box-disk1.vmdk
&gt;&lt;fs&gt; run
&gt;&lt;fs&gt; list-filesystems
/dev/sda1: vfat
/dev/sda2: ext3
/dev/sda3: ext3
/dev/sda4: ext3
/dev/sda5: ext3
/dev/sda6: e
boot
cfglabel.sysmgr
debug
dme
licenses
linux
log
lost+foundxt3
/dev/sda7: ext3
&gt;&lt;fs&gt; mount /dev/sda3 /
&gt;&lt;fs&gt; ls /
lost+found
&gt;&lt;fs&gt; mount /dev/sda1 /
&gt;&lt;fs&gt; ls /
EFI
&gt;&lt;fs&gt; mount /dev/sda2 /
&gt;&lt;fs&gt; ls /
lost+found
&gt;&lt;fs&gt; mount /dev/sda3 /
&gt;&lt;fs&gt; ls /
lost+found
&gt;&lt;fs&gt; mount /dev/sda4 /
&gt;&lt;fs&gt; ls /
nxos.9.2.2.bin
&gt;&lt;fs&gt; mount /dev/sda5 /
&gt;&lt;fs&gt; ls /
lost+found
&gt;&lt;fs&gt; mount /dev/sda6 /
&gt;&lt;fs&gt; ls /
ascii
bin
no-erase
&gt;&lt;fs&gt; mount /dev/sda7 /
&gt;&lt;fs&gt; ls /
lost+found

I copied out the .bin file, which appears to be another filesystem.

&gt;&lt;fs&gt; mount /dev/sda4 /
&gt;&lt;fs&gt; copy-out /nxos.9.2.2.bin .

$ file nxos.9.2.2.bin
nxos.9.2.2.bin: DOS/MBR boot sector



binwalk ./nxos.9.2.2.bin
--------------------------------------------------------------------------------
0             0x0             Netboot image, mode 2
1024          0x400           Microsoft executable, portable (PE)
17844         0x45B4          gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)
2010881       0x1EAF01        MySQL ISAM index file Version 7
6283776       0x5FE200        gzip compressed data, maximum compression, from Unix, last modified: 2018-11-05 06:20:17

Assessed Attacker Value: 5
Assessed Attacker Value: 5Assessed Attacker Value: 1

0.003 Low

EPSS

Percentile

71.7%

Related for AKB:A29F033F-47F8-4658-B470-4A3F541E9175