7月，SolarWinds发布安全公告，修复了Serv-U中存在的远程代码执行漏洞（CVE-2021-35211），该漏洞为微软发现在野利用后向SolarWinds报告，并提供了漏洞利用的概念证明。未经身份验证的远程攻击者利用此漏洞可在受影响的服务器上以特殊权限执行任意代码，请相关用户尽快采取措施进行防护。

该漏洞存在于SSH协议中，与 SUNBURST 供应链攻击无关，仅影响SolarWinds Serv-U Managed File Transfer和Serv-U Secure FTP。使用Serv-U管理控制台向导创建域时会默认选择启用SSH，若Serv-U环境中未启用SSH则不受此漏洞影响。

通过枚举ssh-字符串在Serv-U中发现了SSH实现。SSH实例如图1所示：

图 1. SSH-字符串

研究人员在上述代码中设置断点，并尝试用SSH客户端连接到Serv-U确认这一假设：

图 2. 图1中代码中设置的断点的调用栈

此时，研究人员发现Serv-U.dll和RhinoNET.dll都禁用了ASLR支持。研究人员逆向Serv-U.dll和RhinoNET.dll中相关的代码后发现可以追踪SSH消息的路径。为处理进入的SSH连接，Serv-U.dll从RhinoNET!CRhinoSocket 类创建了CSUSSHSocket对象。CSUSSHSocket 对象的lifetime是TCP连接的长度。底层的CRhinoSocket 为socket提供了缓存的接口，因此单个TCP包可能含有许多字节。这表明单个包也可能包含任意数量的SSH消息以及部分SSH消息。CSUSSHSocket::ProcessRecvBuffer函数负责处理来自缓存socket数据的SSH消息。

CSUSSHSocket::ProcessRecvBuffer首先用ParseBanner检查SSH版本。如果ParseBanner成功从banner获得SSH版本，ProcessRecvBuffer就会循环处理ParseMessage，会从socket数据中获取当前消息的指针，并从消息中提出msg_id和length域。

图 3. CSUSSHSocket::ProcessRecvBuffer处理循环部分代码

消息数据包含在payload缓存中，其中第一个字节就是msg_id：

然后，ProcessRecvBuffer会根据msg_id来处理消息。部分消息会直接经消息处理循环，其他消息会传递给ssh_pkt_others，ssh_pkt_others会发布消息给队列为另一个线程来处理。

图 4. CSUSSHSocket::ProcessRecvBuffer中的预认证处理

如果msg_id委托给另一个线程，CSSHSession::OnSSHMessage就会负责处理。该函数主要处理需要与Serv-U管理用户简介数据和UI更新交互的消息。由于CSSHSession::OnSSHMessage需要先成功进行用户交互，所以也没有发现漏洞。

在对Serv-U进行模糊测试时，很明显应用发现一些包含异常，比如日志记录错误、系统奔溃等。这些行为可以改善文件服务器应用的运行时间，还是引发可能的内容奔溃。攻击者可以利用这一机会来发起暴力破解等攻击。

在测试过程中，研究人员发现了一些读写访问违背等异常情况，这些可以引发奔溃：

图 5. WinDbg表明模糊测试生成的SSH消息引发的奔溃

如上所述，libeay32.dll中的CRYPTO_ctr128_encrypt尝试调用无效的地址。使用的OpenSSL版本是1.0.2u，下面是相关的OpenSSL函数：

同时，下面是处理的结构：

奔溃函数是通过以下路径从OpenSSL API获得的：

EVP_EncryptUpdate -> evp_EncryptDecryptUpdate -> aes_ctr_cipher -> CRYPTO_ctr128_encrypt

进一步分析调用栈，发现Serv-U会从CSUSSHSocket::ParseMessage 调用EVP_EncryptUpdate，如下所示：

图 6. 调用OpenSSL的位置，攻击者控制的函数指针可能会被调用

此时，研究人员通过测试操作了最小化的TCP包缓存以小到触发奔溃所需的最小SSH消息。

研究人员发现该问题产生的根本原因是Serv-U创建了OpenSSL AES128-CTR代码，如下所示：

用NULL key或空IV来调用EVP_EncryptInit_ex，Serv-U这么做是因为在处理 KEXINIT 消息时创建了上下文。但AES密钥扩展在密钥设置之前不会执行，并且ctx->cipher_data数据在密钥扩展执行前仍然保持未初始化状态。因此，研究人员推测消息的序列在密钥初始化之前就会引发enc_algo_client_to_server->decrypt被调用。Serv-U KEXINIT handler在消息中的所有参数创建对象。但对应的对象在NEWKEYS消息被处理签不会被新创建的对象替换。客户端会在发布NEWKEYS消息之前在正常的SSH连接过程中完成密钥交换过程。不轮是连接状态还是密钥交换，Serv-U会处理NEWKEYS。

更多关于漏洞利用的分析参见：https://www.microsoft.com/security/blog/2021/09/02/a-deep-dive-into-the-solarwinds-serv-u-ssh-vulnerability/

本文翻译自：https://www.microsoft.com/security/blog/2021/09/02/a-deep-dive-into-the-solarwinds-serv-u-ssh-vulnerability/如若转载，请注明原文地址