Fortigate

diagnose hardware smartctl

进入底层shell 。如果设置了busybox就可以用busybox来执行其他命令。

1
2
3
4
5
gzip XXX.gz -d 解压位置

# xz -d node-v8.11.1-linux-x64.tar.xz

# tar -xvf node-v8.11.1-linux-x64.tar.xz

配置IP

1
2
3
4
# config system interface
# edit port1
# set mode dhcp ;  启用dhcp模式，自动获取IP
# set allowaccess http https ssh telnet

image-20201210094100425

WEB 控制界面。

image-20201210094221300

其他命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
进入管理控制台，管理设备配置内网IP
配置新的内网接口
在prolicy&objects里
IPV4 policy 添加从LAN接口到WAN接口的转发规则，
all to all 
any to any 
开启NAT
end 返回
？
查看是否有diagnose命令
如果没有。系统过期
如果有diagnose hardware smartctl进入我们的SHELL

# show system interface
# set ip 192.168.1.99 255.255.255.0
# end 返回
# next

本地使用qemu-nbd访问qcow2文件

  • 加载nbd模块

    1
    2
    [root@centos sm]# rmmod nbd
    [root@centos sm]# modprobe nbd max_part=8

  • 映射qcow2文件到本地nbd设备上

    1
    2
    3
    4
    root@ubuntu-virtual-machine:~# qemu-nbd --connect=/dev/nbd0 /。。/data.qcow2
    root@ubuntu-virtual-machine:~# mount /dev/nbd0 ./data/
    root@ubuntu-virtual-machine:~# cd data/
    root@ubuntu-virtual-machine:~/data# ls

解压缩

https://blog.csdn.net/weixin_30628077/article/details/99160087

forigate 的包里有自己该过的 xz 压缩文件。所以，用正常的linux命令 xz -d 是解不了的。

先把 rootfs.gz 提取出来。

image-20201209155955680

接着解压rootfs.gz ，可以用 gzip ，7zip，也可以用 Binwalk ，这里我用binwalk。或者：

cat rootfs | cpio -idmv

image-20201209160154774

可以看到解完之后，里面还有xz 压缩的包。这3个文件不能用正常的xz 去解压。在 sbin 目录下，放着它解压用的文件。

image-20201209160306845

注意，这样应该使用如下命令：

1
chroot pwd sbin/xz -d bin.tar.xz

单纯的切换chroot 会出错，应它的文件系统里还没有bin/bash。

image-20201209181257208

在使用 tar -xvf bin.tar 解压出来就可以了。

数据传输

https://blog.csdn.net/mtj66/article/details/74959287

用 busybox tcpsvd 0 21 busybox ftpd -w / & 开启 ftpd 这种方法不行。因为没办法修改 foritgate 的防火墙规则。它没有 iptables ，如果有 iptables 命令，可以用 iptables -I INPUT -p all -j ACCEPT 。既然没有，换种方法，busybox 有 nc。发现nc也不行。有可能由于 nc 是 busybox 中自带的，不是完整的，测试发现能连上，但无法传输数据。这个时候想到是不是防护墙规则导致的，去到 Policy&Objects -> IPv4 Policy 下添加规则。

image-20201210171017912

添加之后，重启。进行nc测试，发现还是不行。靠。

bin/Init.so

http服务

image-20201210150057258

还是先从登陆过程开始。抓个登陆时发生的数据包，如下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
POST /logincheck HTTP/1.1
Host: 10.2.7.69
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://10.2.7.69/login
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate
If-Modified-Since: Sat, 1 Jan 2000 00:00:00 GMT
Content-Type: text/plain;charset=UTF-8
Content-Length: 34
Connection: close

ajax=1&username=admin&secretkey=

登陆成功，返回的数据如下：
HTTP/1.1 200 OK
Date: Thu, 10 Dec 2020 03:03:20 GMT
Server: xxxxxxxx-xxxxx
Set-Cookie: APSCOOKIE_10656386745237807568="Era%3D1%26Payload%3DJKYhEJVmWTmm05GfnQkMp00DGe8Ns0vHdpXdajwm02BnDOTYP+pDHWBLMDy0tLnp%0AmdiAbMbsR4w%2FT%2F6ZtwUjyAgtG7Q3aAxEr2EZR5MlJHE7qVkU+ac16sDa3q6dOKDR%0Ai2uBO9I%2Fsf0%3D%0A%26AuthHash%3DH1PR7MFewVYUw2FvHt9IOhrazpQA%0A"; path=/; HttpOnly
Set-Cookie: ccsrftoken_10656386745237807568="3BB3313F3CD9E09965F22182A9A5AD80"; path=/
Set-Cookie: ccsrftoken="3BB3313F3CD9E09965F22182A9A5AD80"; path=/
Set-cookie: rl=;expires=Thu, 01 Jan 1970 00:00:01 GMT;path=/
Set-cookie: vmeval=;expires=Thu, 01 Jan 1970 00:00:01 GMT;path=/
Connection: close
Content-Type: text/html; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
X-UA-Compatible: IE=Edge
Content-Length: 57

1document.location="/ng/prompt?viewOnly&redir=%2Fng%2F";

找一找字符串 logincheck ，只有 Init.so库中有。用IDA进行分析。找到了如下位置。

image-20201210112620462

有个ASPCOOKIE字段。结合上图，可以猜测 haystack 应该是接收回包的数据。

这里先不急于向下分析，从这个函数的开头来细看。

image-20201214170041914

开头的函数sub_9D63A0 ，进入之后发现它有 /login?redir= 字符串拼接，根据burpsuit抓包的结果，这里应该就是登陆url的开始位置。

image-20201214170226008

image-20201214170259400

经过一番分析，发现登陆数据包最简洁的情况应该是如下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
POST /logincheck HTTP/1.1
Host: 10.2.7.69
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://10.2.7.69/login
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate
If-Modified-Since: Sat, 1 Jan 2000 00:00:00 GMT
Content-Type: text/plain;charset=UTF-8
Content-Length: 42
Connection: close


ajax=1&username=admin&secretkey=testtest

不需要cookie字段都是可以的。发送之后，返回的数据包如下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
HTTP/1.1 200 OK
Date: Tue, 15 Dec 2020 02:59:04 GMT
Server: xxxxxxxx-xxxxx
Set-Cookie: APSCOOKIE_10656386745237807568="Era%3D1%26Payload%3DRxMxyWAtJknOdD+FtoJxJaEFYHdQx0haJiMHOP8aELcmCraVklTlmNrde1T5hFNO%0AR8ynncXCtpEXp7A3yjIZibjGYt6ct5QIoBDbuDu1lY7xZbuHk8AQYv4fdD4tbnHq%0ADnK23qJf5Wd3etIXVqLl6fYiaq4znmTBW32vg8waWri53l%2F3L%2FkU7+v4jHcmEn5R%0AtUQaUybYJ4RNFzWqjgzDbw%3D%3D%0A%26AuthHash%3DbMxrU1650Hucd4LtlOS8TT7ZajUA%0A"; path=/; HttpOnly
Set-Cookie: ccsrftoken_10656386745237807568="B5791B9634E71E2EA028314E3CB46BC"; path=/
Set-Cookie: ccsrftoken="B5791B9634E71E2EA028314E3CB46BC"; path=/
Set-cookie: rl=;expires=Thu, 01 Jan 1970 00:00:01 GMT;path=/
Set-cookie: vmeval=;expires=Thu, 01 Jan 1970 00:00:01 GMT;path=/
Connection: close
Content-Type: text/html; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
X-UA-Compatible: IE=Edge
Content-Length: 97


<script language="javascript">
document.location="/ng/prompt?viewOnly&redir=%2Fng%2F";
</script>

后续继续分析，发现这里登陆的逻辑有点搞不清楚。所以去找找web页面上处理登陆的js代码。

login.js

在 /migadmin/js/ 下有 login.js.gz 解开里面就是 login.js。

image-20201215155322173

可以看到，最后是通过get_xmlhttp发送数据。继续在init.so 中分析。

image-20201215175337082

在函数sub_A1CA00中看到设置 cookie的位置。这与登陆成功后返回的数据包的cookie内容一致，那么这个函数应该就是登陆成功后，设置cookie的地方。

去查看调用位置，有4处，其中最像登陆判断的函数是 sub_A1CCD0

但是我理不清楚，是怎么对密码和账户进行验证的。

image-20201216154542286

没有找到对 密码secretkey，账户username 进行验证的清晰逻辑。

这与分析 wacthguard 的 web 流程完全不一样，也没有看到另外处理 http 请求的地方。