7月，这就是为什么监控和管理整体性能和健康状况很重要。OpManager 网络管理解决方案通过其不同的内置性能监视器提供帮助。这些监视器可以持续您的网络并升级任何新出现的性能或可用性问题。借助该解决方案的报告和可视化功能，SolarWinds发布安全公告，您可以轻松确定这些问题的原因并进行故障排除。配置管理:简化网络变更网络维护任务的一个组成分是对网络设备应用新配置和变更。自从添加到网络后，修复了Serv-U中存在的远程代码执行漏洞（CVE-2021-35211），每台设备都会进行配置更改以符合所需的网络标准。这使得使用网络配置管理解决方案变得至关重要。配置管理解决方案可帮助您监督网络中所做的所有配置更改。它们还有助于备份所需配置并通过使用信任的备份版本覆盖它们来恢复更改。OpManager 的网络配置管理插件等配置管理解决方案为您提供了自动化网络设备上的策略、配置和合规性变更的额外优势。流量管理:分析网络带宽和流量如果有数百个活跃网络设备，该漏洞为微软发现在野利用后向SolarWinds报告，务必确保为接口和路由器等关键设备提供适量的流量，并提供了漏洞利用的概念证明。未经身份验证的远程攻击者利用此漏洞可在受影响的服务器上以特殊权限执行任意代码，并且最终用户设备不会过度占用带宽。这需要使用提供网络流量管理的网络监控解决方案。OpManager 的 NetFlow 监控模块通过利用流量技术和带宽监控帮助您收集、检查和报告网络流量。它们有助于检测和防止潜在问题和网络中断，请相关用户尽快采取措施进行防护。
该漏洞存在于SSH协议中，例如带宽瓶颈等问题。网络流量管理解决方案还可以检测异常流量峰值或波动(这可能表明存在威胁)并预测流量行为，与 SUNBURST 供应链攻击无关，从而帮助您确定网络需求。安全管理:有效保护您的网络对于支持 BYOD 策略等高级网络概念的企业网络，仅影响SolarWinds Serv-U Managed File Transfer和Serv-U Secure FTP。使用Serv-U管理控制台向导创建域时会默认选择启用SSH，IT 管理员必须主动识别和消除安全威胁。这使得全面了解防火墙、端口、VPN 和新添加的设备等组件变得非常重要。由于这些组件中的任何异常事件(例如流量峰值和未知端口服务)都可能表明存在潜在的安全漏洞。网络管理解决方案可帮助您避免这些威胁并加强网络安全。它们使您能够分析防火墙日志和网络活动，若Serv-U环境中未启用SSH则不受此漏洞影响。
通过枚举ssh-字符串在Serv-U中发现了SSH实现。SSH实例如图1所示：
图 1. SSH-字符串
研究人员在上述代码中设置断点，并检测网络中的任何异常安全事件。OpManager 的防火墙日志管理插件与运维管理相辅相成，并尝试用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/
免责声明：文中图片均来源于网络，如有版权问题请联系我们进行删除！
标签：
