如何通过7个漏洞攻破ShareFile本地环境-安全KER

一、前言

前一段时间，我们配置了带有StorageZone控制器的一个Citrix ShareFile环境。ShareFile是面向企业的文件同步及共享解决方案，尽管有一些版本完全依赖于云端，但Citrix也提供了另一种混合版本，其中数据可以通过StorageZone控制器存储在本地（on-premise）。在本文中，我们介绍了Fox-IT如何挖掘该环境中存在的多个漏洞，利用这些漏洞，攻击者可以通过任意账户访问ShareFile中存储的任意文件。向Citrix披露这些漏洞信息后，Citrix通过云平台及时更新修复了这些缺陷。这些漏洞全部位于StorageZone控制器组件中，因此完全基于云端的部署方案不会受到影响。根据Citrix的描述，财富500强中有多家企业和组织在使用ShareFile解决方案（纯云端或者带有本地组件），这些企业和组织涉及政府、科技、医疗、银行以及关键基础设施。

二、获取访问权限

在了解应用整体情况以及工作流程后，我们决定研究上传流程以及云端与ShareFile本机端组件的连接情况。一般来说，我们可以采用两种方法将文件上传到ShareFile中：一种基于HTML5，另一种则是基于Java Applet。在接下来的例子中，我们使用的是基于Java的上传方式。我们进行了一些配置，使得Burp可以捕捉到所有请求（Burp是我们用来测试Web应用的首选工具）。当准备上传时，会有一个请求发送到ShareFile的云组件，该组件地址为name.sharefile.eu（其中name为采用该解决方案的公司名称）：

从上图中可知，该请求包含上传信息，具体包括文件名、文件大小（字节数）、上传所使用的工具（本例中为Java上传器）以及我们是否愿意执行unzip操作（后面会解释这一点）。该请求返回的响应数据如下：

在响应数据中，我们可以看到两种不同的上传URL，都包含指向本地StorageZone控制器地址的URL前缀（这里隐去了敏感信息）。因此，云组件可以生成将文件上传到本地组件所对应的URL地址。

第一种URL为ChunkUri，单个文件分块会分别上传到这些地址。当文件传输完成后，可以使用FinishUri来完成服务器上的文件上传流程。在这两种URL中，我们都可以看到其中附带了文件名、文件大小等各种信息，也可以看到用来标识上传会话的uploadid。最后还有一个h=参数，后面跟着的是经过base64编码后的哈希值。该哈希值用来确保URL中的参数没有被篡改过。

我们首先注意到的是unzip参数。如下图所示，上传器给用户提供了一个选项，支持压缩文档（如.zip文件）上传后的自动解压功能。

解压zip文档时经常会犯的错误就是没有去验证zip文件中路径的有效性。如果在zip文件中使用相对路径，攻击者可能会触及超出脚本限制范围的不同目录。这种漏洞就是著名的目录遍历或者路径遍历漏洞。

如下一段python代码可以创建名为out.zip的一个特殊zip文件，该文件中包含两个文件，其中一个使用了相对路径。

import sys, zipfile
#the name of the zip file to generate
zf = zipfile.ZipFile('out.zip', 'w')
#the name of the malicious file that will overwrite the origial file (must exist on disk)
fname = 'xxe_oob.xml'
#destination path of the file
zf.write(fname, '../../../../testbestand_fox.tmp')
#random extra file (not required)
#example: dd if=/dev/urandom of=test.file bs=1024 count=600
fname = 'test.file'
zf.write(fname, 'tfile')

当我们将这个文件上传到ShareFile后，我们可以看到如下信息：

ERROR: Unhandled exception in upload-threaded-3.aspx - 'Access to the path '\company.internaldatatestbestand_fox.tmp' is denied.'

该信息表明StorageZone控制器尝试将我们的文件解压到缺乏权限的那个目录中，但我们还是可以成功修改文件解压的目标目录。只要StorageZone控制器具备某些目录的权限，我们就可以利用这个漏洞将我们可控的文件解压到这些目录中。想象一下，默认的解压路径为c:appdatacitrixsharefiletemp，我们可以构造路径为../storage/subdirectory/filename.txt的一个文件，这样就能将这个文件解压到c:appdatacitrixsharefilestoragesubdirectory目录中。相对路径中的../表示操作系统应该跳到目录树中的上一层目录，然后在当前目录中使用相对路径中的剩余部分来进行寻址。

漏洞1：文档解压过程中的路径遍历漏洞。

三、从任意写入到任意读取

虽然将任意文件写入存储目录中的任意位置的确是个高风险漏洞，但漏洞的影响范围取决于应用如何使用磁盘上的文件，以及目标上是否会检查这些文件完整性。为了验证这种能力的影响范围，我们来看一下StorageZone控制器的具体工作原理。我们发现有三个主目录可以存储较为有趣的一些数据：

files
persistenstorage
tokens

其中，files目录用来存放与上传有关的临时数据；已上传到ShareFile中的文件存储在persistentstorage目录中；tokens目录包含与令牌相关的一些数据，这些数据用来控制文件的下载。

当新的上传任务初始化时，URL地址中包含名为uploadid的一个参数。显然，从这个名称中我们知道该参数是与上传有关的一个ID值，本例子中这个参数值为rsu-2351e6ffe2fc462492d0501414479b95。在files目录中，我们可以看到与该ID匹配的各种上传目录。

在这些目录中都包含名为info.txt的一个文件，该文件包含我们上传过程中的一些信息：

在info.txt中包含我们在前面看到过的一些参数，比如uploadid、文件名、文件大小（13个字节），还包括一些新的参数。最后我们还可以看到包含32个大写字母的的字符串，该哈希字符串用来标识数据的完整性。

我们还可以看到其他ID值，为fi591ac5-9cd0-4eb7-a5e9-e5e28a7faa90以及fo9252b1-1f49-4024-aec4-6fe0c27ce1e6，分别对应了此次上传的文件ID以及存放文件的目录ID。

经过一段时间的研究后，我们发现该服务使用MD5哈希算法来校验文件的完整性，通过info.txt文件中其他数据计算出哈希值。需要注意的是，这里数据的编码格式为UTF-16-LE，这也是Windows系统默认使用的Unicode字符串编码格式。

掌握这些知识后，我们可以写一段简单的python脚本，能够计算修改后info.txt文件的正确哈希值，并将该值写回磁盘中：

import md5
with open('info_modified.txt','r') as infile:
instr = infile.read().strip().split('|')
instr2 = u'|'.join(instr[:-1])
outhash = md5.new(instr2.encode('utf-16-le')).hexdigest().upper()
with open('info_out.txt','w') as outfile:
outfile.write('%s|%s' % (instr2, outhash))

这里我们也找出了第二个漏洞：应用并没有使用私有的密钥来校验info.txt文件的完整性，相反使用了简单的MD5哈希值来防止文件内容被破坏。这样一来，如果攻击者拥有数据存储目录的写入权限，就有可能篡改上传信息。

漏洞2：数据文件（info.txt）的完整性没有经过合适的校验。

利用前一个漏洞，我们可以将文件写入任意目录中，因此我们可以上传自己的info.txt，修改上传信息。

此外，我们发现应用在上传数据时，会使用fi591ac5-9cd0-4eb7-a5e9-e5e28a7faa90这个文件ID作为该文件的临时名称，上传后的数据会写入该文件中。当上传结束时，该文件会加入用户的ShareFile账户中。这里我们来尝试一下另一个路径遍历漏洞。使用上述脚本，我们将文件ID修改成另一个文件名，尝试提取名为secret.txt的一个测试文件（files目录中已经有一个secret.txt文件，files目录是临时文件所在目录的上一层目录）。经过修改的info.txt文件如下所示：

当我们继续使用upload-threaded-3.aspx页面来完成上传任务时，我们得到了如下错误：

显然，我们尝试获取的secret.txt文件的大小为14个字节，并非info.txt文件中指定的13个字节。我们可以上传包含正确文件大小信息的新的info.txt文件，这样secret.txt文件就可以成功上传到我们的ShareFile账户中：

因此我们挖掘出了第二个路径遍历漏洞，该漏洞位于info.txt文件中。

漏洞3：info.txt文件中存在路径遍历漏洞。

原先我们可以将任意文件写入系统中，到目前为止，我们已经可以将该漏洞变成读取任意文件的漏洞，只需要知道目标文件的文件名即可。需要注意的是，攻击者可以通过监控Web接口的流量了解到info.txt文件中包含的所有信息，因此攻击者在发起这种攻击时并不需要拥有一个info.txt文件。

四、研究文件下载过程

前面我们一直关注的是新文件上传方面的漏洞，文件的下载同样由ShareFile云组件来控制，云组件会指示StorageZone控制器来为用户请求的文件提供服务。典型的下载链接如下所示：

如上图所示，dt参数为下载中涉及的令牌信息，h参数包含URL剩余部分的HMAC信息，以便向StorageZone控制器证明我们拥有下载此文件的正确权限。

下载的令牌信息存放在tokens目录的一个XML文件中，典型的文件内容如下所示：

<!--?xml version="1.0" encoding="utf-8"?--><?xml version="1.0" encoding="utf-8"?>
<ShareFileDownloadInfo authSignature="866f075b373968fcd2ec057c3a92d4332c8f3060" authTimestamp="636343218053146994">
<DownloadTokenID>dt6bbd1e278a634e1bbde9b94ff8460b24</DownloadTokenID>
<RequestType>single</RequestType>
<BaseUrl>https://redacted.sf-api.eu/</BaseUrl>
<ErrorUrl>https://redacted.sf-api.eu//error.aspx?type=storagecenter-downloadprep</ErrorUrl>
<StorageBasePath>\s3sf-eu-1;</StorageBasePath>
<BatchID>dt6bbd1e278a634e1bbde9b94ff8460b24</BatchID>
<ZipFileName>tfile</ZipFileName>
<UserAgent>Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0</UserAgent>
<Metadata>
<Item key="operatingsystem" value="Linux" />
</Metadata>
<IrmEnabled>false</IrmEnabled>
<IrmPolicyServerUrl />
<IrmAccessId />
<IrmAccessKey />
<Items>
<File name="testfile" path="a4ea881a-a4d5-433a-fa44-41acd5ed5a5ffffi0f0f2e_3477_4647_9cdd_e89758c21c37" size="61" id="" />
</Items>
<Log>
<EventID>fif11465-ba81-8b77-7dd9-4256bc375017</EventID>
<UserID>c7add7af-91ac-4331-b48a-0aeed4a58687</UserID>
<OwnerID>c7add7af-91ac-4331-b48a-0aeed4a58687</OwnerID>
<AccountID>a4ea881a-a4d5-433a-fa44-41acd5ed5a5f</AccountID>
<UserEmailAddress>fox-it@redacted</UserEmailAddress>
<Name>tfile</Name>
<FileCount>1</FileCount>
<AdditionalInfo>fif11465-ba81-8b77-7dd9-4256bc375017</AdditionalInfo>
<FolderID>foh160ab-aa5a-4e43-96fd-e41caed36cea</FolderID>
<ParentID>foh160ab-aa5a-4e43-96fd-e41caed36cea</ParentID>
<Path>/root/a4ea881a-a4d5-433a-fa44-41acd5ed5a5f/foh160ab-aa5a-4e43-96fd-e41caed36cea</Path>
<IncrementDownloadCount>false</IncrementDownloadCount>
<ShareID />
</Log>
</ShareFileDownloadInfo>

这里有两个地方比较有趣。第一个地方为File元素的path属性，该属性指定了该令牌适用于哪一个文件。path开头为一个ID，值为a4ea881a-a4d5-433a-fa44-41acd5ed5a5f，这也是ShareFile的AccountID，每个ShareFile实例都不一样。第二个ID值为fi0f0f2e_3477_4647_9cdd_e89758c21c37，每个文件都不一样（因此使用的是fi这个前缀），这个ID开头为两个0f子目录，应该是为了避免过长的目录列表。

第二个值得注意的地方是ShareFileDownloadInfo元素中的authSignature属性。该属性表明XML文件经过签名处理，可以确保文件的真实性，避免恶意令牌被下载。

现在起我们来研究一下StorageZone控制器这个软件，这是采用.NET开发的一个程序，在IIS下运行，因此我们很容易就可以使用诸如JustDecompile之类的工具来反编译相关程序。我们从服务器端拿到了StorageZone控制器程序，但Citrix也在官网上提供了该组件的下载链接。

反编译处理后，我们很快就找到了负责验证令牌的那些函数。Citrix通过AuthenticatedXml这个函数生成XML文件的签名。我们在代码中找到了一个静态秘钥，该秘钥可以用来验证XML文件的完整性（所有StorageZone控制器上这个值都一样）：

漏洞4：XML令牌文件本身的完整性没有经过正确校验。

在研究过程中，我们尝试过在不修改签名的前提下直接编辑XML文件，结果发现攻击者并不需要计算出正确的签名值，因为如果签名不匹配，应用本身就会告诉我们正确的值：

漏洞5：调试信息泄露。

此外，当我们查看负责计算签名的代码时，我们发现应用会将秘钥附加到数据尾部，然后计算整段数据的sha1哈希值。这样一来，签名很有可能会受到哈希长度扩展攻击的影响，但目前我们没有时间去验证这一点。

即使我们没有在整个攻击链条中使用这种潜在的漏洞，我们也发现XML文件容易受到XML外部实体（XML External Entity，XXE）_Processing)注入影响：

漏洞6（此次攻击链中没有使用）：XML令牌文件存在XXE漏洞。

总之，我们发现令牌文件为我们提供了从ShareFile下载任意文件的另一条途径。此外，这些文件本身的完整性没有经过充分的验证，无法防范攻击者。与前面修改上传数据不同的是，如果ShareFile启用了加密存储功能，这种方法也可以解密经过加密的文件。

五、获取令牌及文件

到目前为止，我们可以将任意文件写入任意目录，如果知道文件路径我们还可以下载其他文件。然而，在实际环境中，文件路径包含随机的ID值，我们无法在有效时间内猜测出正确的值。因此，攻击者还需要找到另一种方法，枚举ShareFile上存储的文件以及对应的ID。

为完成这个任务，我们回过头来看看unzip功能。负责解压zip文件的部分代码如下所示。

从上图可知，代码创建了一个临时目录，将归档文件解压到该目录中，临时目录名称用到了uploadId这个参数。由于在这里我们并没有看到任何路径验证机制，因此该操作很有可能受到路径遍历攻击影响。之前我们在上传文件的URL中看到过uploadId这个参数，但这个URL同样包含HMAC值，因此貌似我们无法修改这个参数：

但先别放弃，我们来看一下具体实现。我们的请求首先会传入ValidateRequest函数，如下图所示：

该函数再将请求传递给第二个验证函数：

上述代码会从请求中提取处h参数，用来验证url中在h参数之前的所有参数。因此URL中在h之后的所有参数完全没有经过校验。

因此，如果我们在HMAC之后添加其他参数会出现什么情况？当我们将URL修改成如下形式：

我们可以得到如下信息：

{"error":true,"errorMessage":"upload-threaded-2.aspx: ID='rsu-becc299a4b9c421ca024dec2b4de7376,foxtest' Unrecognized Upload ID.","errorCode":605}

由于uploadid参数被多次指定，因此IIS会将被逗号分隔开的值拼接在一起。由于程序并没有单独处理每个参数值，而是处理整个查询字符串，并且只验证在h参数前的那部分字符串，因此只有第一个uploadid会经过HMAC的校验。这种漏洞也就是所谓的HTTP参数污染（HTTP Parameter Pollution）)漏洞。