Server as Client 漏洞模型
一、前言 在漏洞挖掘工作中，攻击面的选择往往是一个非常重要的环节，一些意想不到的攻击面中往往存在大量开发测试人员疏忽的点。本文就关于一种有趣的攻击面进行探讨，将其起名为SaC（Server as Client）。 二、Client Server 架构 在带有网络通信的传统软件开发过程中，往往会使用一种叫做CS（Client Server）的架构，这个架构模型大致上是由提供服务的服务端（Server）以及请求服务资源的客户端（Client）组成。 2.1 CS架构的特征 服务端通常来说，具有如下的特点： 具有高权限。为了方便的进行资源调度，权限控制等任务，大多数的服务端程序会以相当高的权限运行在机器上。 可能为分布式。服务端为了减轻请求处理的压力，有时候会将服务以微服务部署在多个服务器上，或者在多个机器上部署的同时，使用调度工具对请求进行调度。 持续监听，对请求反馈。服务端大多数为持续监听一个固定的对象，比如固定的某些端口，从而保证能够随时处理来自客户端的请求。 对请求进行校验，防护完善。由于要对请求进行鉴权，所以有着更加严格的访问控制；同时由于服务端存放大量资源，一般会有非常严格的检查 而相对于服务端，客户端往往具有如下的特点： 不一定为高权限进程。由于客户端往往只是请求某些资源，这个过程大多数情况下无需高权限访问。 每次访问只维护单个会话。客户端的每次资源请求大多数只建立一次会话，不存在同时发起多个会话的情况。 通常请求单个服务端资源。虽然客户端可能会请求多种不同类型的资源，但是每次请求基本上都有某一个固定的服务端进行响应处理。 防护相对不到位。由于客户端本质上运行在客户机器上，加之运行权限不高，一般不会有特别复杂的防护机制 Server Client 权限通常较高 权限通常不高 可能为分布式 单个端点请求资源 持续性监听 单个会话访问 安全校验严格 防护较为松散 而这类架构往往又具有如下的特点： 双方在同一网络内 请求由客户端发起，服务器端进行接受 服务端具有大量的防护机制，包括但不限于 权限控制 数据安全边界检查 软件本身代码安全标准高 三、漏洞模型分析 对于攻击者而言，大多数情况下服务端的资源为攻击目标，因此大部分的时候攻击都针对服务端发起，服务端也就在攻防对抗中逐渐加固；而客户端由于价值低，通常缺乏这类攻防事件，相对来说受到的攻击较少。那么，此时只要创建出一个场景，让服务端变为客户端，则此时服务端中存在的客户端的攻击面就会暴露出来，从而造成大量危害。 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。...