一、前言

在漏洞挖掘工作中，攻击面的选择往往是一个非常重要的环节，一些意想不到的攻击面中往往存在大量开发测试人员疏忽的点。本文就关于一种有趣的攻击面进行探讨，将其起名为SaC（Server as Client）。

二、Client Server 架构

在带有网络通信的传统软件开发过程中，往往会使用一种叫做CS（Client Server）的架构，这个架构模型大致上是由提供服务的服务端（Server）以及请求服务资源的客户端（Client）组成。

2.1 CS架构的特征

服务端通常来说，具有如下的特点：

  • 具有高权限。为了方便的进行资源调度，权限控制等任务，大多数的服务端程序会以相当高的权限运行在机器上。
  • 可能为分布式。服务端为了减轻请求处理的压力，有时候会将服务以微服务部署在多个服务器上，或者在多个机器上部署的同时，使用调度工具对请求进行调度。
  • 持续监听，对请求反馈。服务端大多数为持续监听一个固定的对象，比如固定的某些端口，从而保证能够随时处理来自客户端的请求。
  • 对请求进行校验，防护完善。由于要对请求进行鉴权，所以有着更加严格的访问控制；同时由于服务端存放大量资源，一般会有非常严格的检查

而相对于服务端，客户端往往具有如下的特点：

  • 不一定为高权限进程。由于客户端往往只是请求某些资源，这个过程大多数情况下无需高权限访问。
  • 每次访问只维护单个会话。客户端的每次资源请求大多数只建立一次会话，不存在同时发起多个会话的情况。
  • 通常请求单个服务端资源。虽然客户端可能会请求多种不同类型的资源，但是每次请求基本上都有某一个固定的服务端进行响应处理。
  • 防护相对不到位。由于客户端本质上运行在客户机器上，加之运行权限不高，一般不会有特别复杂的防护机制
ServerClient
权限通常较高权限通常不高
可能为分布式单个端点请求资源
持续性监听单个会话访问
安全校验严格防护较为松散

而这类架构往往又具有如下的特点：

  • 双方在同一网络内
  • 请求由客户端发起，服务器端进行接受
  • 服务端具有大量的防护机制，包括但不限于
    • 权限控制
    • 数据安全边界检查
    • 软件本身代码安全标准高

三、漏洞模型分析

对于攻击者而言，大多数情况下服务端的资源为攻击目标，因此大部分的时候攻击都针对服务端发起，服务端也就在攻防对抗中逐渐加固；而客户端由于价值低，通常缺乏这类攻防事件，相对来说受到的攻击较少。那么，此时只要创建出一个场景，让服务端变为客户端，则此时服务端中存在的客户端的攻击面就会暴露出来，从而造成大量危害。

3.1 Server as Client

大多数情况下，服务端程序并不会仅仅作为提供资源的一方存在。在现代模型中，单个服务器能够完成的功能有限，在特定的情境下，服务端也会作为客户端向其他的服务端进行资源请求，例如如下的场景：

  • 访问不存在本服务器的资源
  • 远程路径访问
  • RPC调用
  • 代理访问

当服务端A去向服务端B发起请求的时候，此时的服务端A本质上是作为客户端存在的，此时的服务端身份就转换成了客户端。而客户端往往是防护较为薄弱的一环，服务端上的客户端部分也是如此。

这类攻击往往需要构造如下的场景：

  • 攻击者需要具有两台机器，一台攻击机（Hacker），以及受控的另一台伪造服务端（Fake Server）；
  • 某些场景下，受控的伪造服务端要和受害主机（Victim Server）在同一个内网中。

此时，可以通过在Fake Server 上构造畸形的数据包，从而实现对受害主机的攻击。

四、实例：CVE-2021-43893

漏洞CVE-2021-43893为 Windows 上的EFSRPC服务，主要用于提供在远程服务器上进行数据的加解密。微软在修复漏洞的时候，存在疏忽，导致这个漏洞的生命周期中经历了如下两个阶段：

  • （漏洞一）最初漏洞本身通过直接窃取Net-NTML，从而实现NTML-Relay。
  • （漏洞二）微软对其进行了简单的修复后，并未完全封堵，导致该漏洞可变形为未授权用户往Windows Server上传任意文件。

接下来会对两种漏洞的成因以及利用进行分析。

4.1 漏洞一成因

首先检查函数原型:

 long EfsRpcOpenFileRaw(
   [in] handle_t binding_h,
   [out] PEXIMPORT_CONTEXT_HANDLE* hContext,
   [in, string] wchar_t* FileName,
   [in] long Flags
 );

该函数的作用为一个RPC接口，用于打开位于RPC服务端的一个文件。这里的FileName根据MSDN的定义，可以支持UncPath。

通常来说，目标服务端会指定一个目录，例如：

D:\ShareFiles

此时，这个目录会作为远程访问服务端的用户根目录，用户可以访问这个目录下的一些共享文件。

当用户访问远程服务端的时候，用户所在的客户端会使用本地的EFSRPC服务尝试调用服务器端的RPC接口，此时通过RPC，会调用服务端上的EfsRpcOpenFileRaw这类函数，这里的FileName为UNC路径，本意上为开发者想要兼容各类路径想到的，比如我们可以把FileName写成一些远程服务器上的路径，这样即使本机没有，我们也能要求服务端去访问远程文件：

\\10.1.0.1\file

然而这个远程调用没有表面看上去这么简单，假设这个10.1.0.1 IP 对应的机器为我们可控的情况下，会发现EfsRpcOpenFileRaw这个API为了能够进行认证，会尝试在发起获取远程文件的请求时，将当前服务端的 Net-NTLM 发送给10.1.0.1。而由于此时的10.1.0.1 为我们假冒的，因此我们可以轻易的截获Net-NTLM。一旦获取受害机器的Net-NTLM，我们就能够使用这个值去伪装认证，最终将自己伪装成受害机器。具体来说流程如下：

这种泄露Net-NTLM的具体利用细节可以参考这里的文章，最终效果便是能够作为受害主机的权限，在内网中进行资源访问。

4.2 漏洞二成因

微软意识到这个问题后，给 EFSRPC 服务的对应API增加了身份认证，这样当我们访问远程机器的时候，首先要进行身份认证，这就限制了使用这个问题进行远程访问的问题（虽然在此期间，微软拉扯了很多次，导致漏洞修复的比较缓慢，这就是后话了）。

但是又有新的安全人员根据这个漏洞受到启发。原先在EfsRpcOpenFileRaw这类函数使用的时候，会检查路径的权限，例如显然是不允许访问服务端的C:这个目录的，但是为了支持远程路径，在遇到\开头的路径时，一律按照远程文件访问处理，这就导致其忘记检查形如\\.\C:的路径，这种形式的写法本质上还是在访问本地磁盘，从而导致这个API可以存在一个路径穿越问题。

这个漏洞的使用范围会比上一个小很多，因为这种情况下，RPC接口会保证我们的请求是在低权限下执行，但是通过一些技巧，我们也是有机会提权的，具体可直接参考文章。

4.3 CVE-2021-43893 引发的思考

通过学习这个漏洞，我们能够收获如下的启发：

  • 软件中同样存在着类似web安全中的SSRF问题，同样有可能实现越权访问
  • 服务端程序在某些特定的请求下，会转换成客户端请求
  • 客户端部分在实现的时候，安全性往往不如服务端严格

五、实例：CVE-2022-26809

上个漏洞中提及了RPC服务，于是有很多安全人员开始进一步的研究RPC协议调用过程中会发生的问题，并且发现了其中的一些问题。

5.1 RPC简介

RPC全程为远程过程调用（Remote Procedure Call），分为Server端和Client端。其调用模式如图：

有些场景我们希望某些功能在指定的服务端实现，例如上个例子中的文件共享，此时我们会希望相关的逻辑是现在服务端上，而客户端使用API直接请求对应的数据，这个时候就能够使用RPC来完成我们的功能。

RPC有点类似现在的web服务，其也分为客户端和服务端。简单来说，这两者在RPC中主要作用如下：

服务端：

  • 将被调用的函数绑定到服务中
  • 将自己注册到RPC管理器中
  • 处理来自客户端的请求

客户端：

  • 申请使用RPC调用
  • 向服务端发起请求，并且调用对应的API

5.2 漏洞介绍

这个漏洞出现在RPC的客户端逻辑中，在函数OSF_CASSOCIATION::ProcessBindAckOrNak中存在这样的逻辑：

这里的BufferLength为我们传入的Buffer长度，根据逆向分析后可以知道，RPC结构体分为两部分: Header和Body，其中根据收到的回复类型的不同，RPC会使用不同类型的Header，一般来说分为其中两种：

  • bind_ack: 接受RPC调用，包头部长度为26字节。
  • alter_context_resp: RPC调用发生变化，重新进行握手等动作，包头部长度为26字节。存在额外数据。

根据分析可知，虽然上述的Header长度一致，但是alter_context_resp会额外包含一些数据，所以在计算body位置的时候，会多减去两个字节。而上述代码中，程序只做了如下的检查

  • 数据包长度至少为26字节（代码中未展示）
  • 接受的数据包是否为bind_ack，计算body的长度

可以看到，这里并没有确保收到的数据包一定是来自于alter_context_resp这种类型。于是当我们此时申明我们数据包来自alter_context_resp，但是长度仅为26字节的时候，即可通过上述的检查，而代码中这里就存在一个可以造成整数溢出的点。

else
{
    bodyLength = BufferLength - 28; // BufferLength可以只为26
    offset = 2i64;
}

5.3 漏洞场景

这个漏洞是在收到回复包的情况下触发，所以正常的发包是无法进入对应的逻辑中的，但是我们可以通过如下的方式诱发漏洞：

同样，此漏洞也需要通过伪造服务端来实现漏洞的诱发。

六、模型总结

上述的例子中，不但出现了狭义上的客户端，即单纯的向服务端请求数据，并且对数据进行接收的模块，还出现了广义上的客户端，也就是自己发起请求后，接受对端的回应数据包。

在漏洞挖掘过程中，广义上的客户端往往会成为人们忽略的要点。就像是RPC漏洞中，用于处理ACK数据包的模块。从直觉上理解，ACK数据包一定是来自于不受控的服务端，但是在实际攻击场景中，服务端本身也是允许伪造的，此时处理ACK数据包的处理端就能视为成客户端。

基于上述思路，我们可以列举出一些常见的场景:

  • 文件共享的时候，负责接受文件的客户端
  • 代理访问，进行代理确认的代理端
  • 加密操作时，负责接受加密数据的接收端
  • 负责接受邮件的邮件客户端

在上述场景中，大多数的场景会被我们忽略，因为常理上讲，无法对目标造成损失——毕竟这些操作通常发生在我们自己的机器上，而执行操作的进程大概率也不是高权限进程。然而，通过远程路径访问，代理转发，以及对端加密，或者以服务存在的高权限邮件对邮件进行解析等操作，是具备将这些客户端漏洞转化为高价值漏洞的。在进行软件安全性分析的时候，不妨以这些面为切入点，也能找到一些有趣的漏洞。