UPnP和DLNA协议

	前言 没有情情爱爱，只有技术相伴，给大家分享一下UPnP和DLNA协议； UPnP的概念 通用即插即用（英语：Universal Plug and Play，简称UPnP）是由“通用即插即用论坛”（UPnP™ Forum）推广的一套 网络协议。该协议的目标是使家庭网络（数据共享、通信和娱乐）和公司网络中的各种设备能够相互无缝连接 并简化相关 网络的实现。UPnP通过定义和发布基于开放、因特网通讯网协议标准的UPnP设备控制协议来实现这一目标。 UPnP这个 概念是从即插即用（Plug-and-play）派生而来的，即插即用是一种热拔插技术。 通俗点讲目前一般都用在路由器上面，如下截图所示； 关于UPnP协议栈 关于UPnP工作流程 1.寻址 DHCP协议 2.发现 使用的是SSDP协议，这是一个工作在UDP上的HTTP协议； 3.描述 通过扫描端口，遍历路径，可以发现路由器的UPnP服务接口；当然每家厂商有自己的固定路径后缀 也可以网上搜索； <?xml version="1.0"?> <root xmlns="urn:schemas-upnp-org:device-1-0"> <specVersion> <major>1</major> <minor>0</minor> </specVersion> <device> <deviceType>urn:schemas-upnp-org:device:InternetGatewayDevice:1</deviceType> //设备类型，格式为： “urn:schemas-upnp-org:device:deviceType:v”，这里deviceType和v是由设备定义的。 <presentationURL>http://192.168.0.1:80</presentationURL> <friendlyName>Wireless N Router MW313R</friendlyName> //一个更加友好的设备名 <manufacturer>MERCURY</manufacturer> //制造商 <manufacturerURL>http://www.mercurycom.com.cn</manufacturerURL> <modelDescription>MW313R 5.0</modelDescription> <modelName>MW313R</modelName> <modelNumber>5.0</modelNumber> <UDN>uuid:upnp-InternetGatewayDevice-4D5A5C269D27</UDN> //设备的UUID <UPC>123456789001</UPC> <serviceList> <service> <serviceType>urn:schemas-upnp-org:service:Layer3Forwarding:1</serviceType> <serviceId>urn:upnp-org:serviceId:L3Forwarding1</serviceId> <controlURL>/l3f</controlURL> //用于控制的URL <eventSubURL>/l3f</eventSubURL> //用于订阅事件的URL <SCPDURL>/l3f.xml</SCPDURL> //服务描述的URL </service> </serviceList> <deviceList> <device> <deviceType>urn:schemas-upnp-org:device:WANDevice:1</deviceType> <friendlyName>WAN Device</friendlyName> <manufacturer>MERCURY</manufacturer> <manufacturerURL>http://www.mercurycom.com.cn</manufacturerURL> <modelDescription>WAN Device</modelDescription> <modelName>WAN Device</modelName> <modelNumber>1.0</modelNumber> <modelURL></modelURL> <serialNumber>12345678900001</serialNumber> <UDN>uuid:upnp-WANDevice-4D5A5C269D27</UDN> <UPC>123456789001</UPC> <serviceList> <service> <serviceType>urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1</serviceType> <serviceId>urn:upnp-org:serviceId:WANCommonInterfaceConfig</serviceId> <controlURL>/ifc</controlURL> <eventSubURL>/ifc</eventSubURL> <SCPDURL>/ifc.xml</SCPDURL> </service> </serviceList> <deviceList> <device> <deviceType>urn:schemas-upnp-org:device:WANConnectionDevice:1</deviceType> <friendlyName>WAN Connection Device</friendlyName> <manufacturer>MERCURY</manufacturer> <manufacturerURL>http://www.mercurycom.com.cn</manufacturerURL> <modelDescription>WAN Connection Device</modelDescription> <modelName>WAN Connection Device</modelName> <modelNumber>1</modelNumber> <modelURL></modelURL> <serialNumber>12345678900001</serialNumber> <UDN>uuid:upnp-WANConnectionDevice-4D5A5C269D27</UDN> <UPC>123456789001</UPC> <serviceList> <service> <serviceType>urn:schemas-upnp-org:service:WANIPConnection:1</serviceType> <serviceId>urn:upnp-org:serviceId:WANIPConnection</serviceId> <controlURL>/ipc</controlURL> <eventSubURL>/ipc</eventSubURL> <SCPDURL>/ipc.xml</SCPDURL> </service> </serviceList> </device> </deviceList> </device> </deviceList> </device> </root> 复制代码 4.控制 使用SOAP协议来完成控制； 5.事件 通过返回xml消息，使用GENA格式； UPnP相关测试 miranda 了解到原来kali是自带这个工具，但是新版本删掉了，找到了github的源文件 可以使用；https://github.com/0x90/miranda-upnp； 没太清楚为什么新版kali删掉这个工具，但是了解下来，UPnP基本上路由器都会默认开启，虽然UPnP协议没有 任何身份验证机制，但是实际利用场景还是比较弱，如果路由器是公网ip还说可以建一条出网的通道一般来说路 由器是局域网ip，然后能开启的场景下也就已经进入内网了，其他出网的办法也很多，UPnP协议也只是建一条 转发路由，前提还得是转发的ip存在问题； 扫描模式： pcap：被动发现设备通过嗅探设备接入网络时发送的NOTIFY消息获取设备信息。 msearch:通过主动发送M-serach消息来发现设备。（一般使用msearch比较快） 测试下来我是msearch 发现不了，但是用msearch扫描了一段时间后，切pcap就可以立马出现结果； 信息获取 发现设备后可用host命令来查看详细信息。 host list：查看发现的设备列表 host get<n>：获取信息（查询summary之前需执行） host info<n>：显示查询到的信息（n为设备在列表中的编号） host summary 0 ：显示xml文件的摘要信息 利用 host info 0 deviceList //设备列表，或者说设备信息 host info 0 deviceList WANConnectionDevice services //设备服务列表 host info 0 deviceList WANConnectionDevice services WANIPConnec tion serviceStateVariables //服务状态列表 host info 0 deviceList WANConnectionDevice services WANIPConn ection actions //服务控制列表，操作功能 host send 0 WANConnectionDevice WANIPConnection AddPortMapping //规则配置 登陆后台可以看到规则已配置，并且生效了； 其他功能解析，这部分其实有些是厂商自定义的，有些是默认自带的功能； AddPortMapping : {} GetNATRSIPStatus : {} GetGenericPortMappingEntry : {} GetSpecificPortMappingEntry : {} ForceTermination : {} GetExternalIPAddress : {} GetConnectionTypeInfo : {} GetStatusInfo : {} SetConnectionType : {} DeletePortMapping : {} RequestConnection : {} 小技巧：由于发现upnp服务比较困难，掉线或者退出进程后，需要重新发现，又只能等； 找了一下，官方提供了存储和恢复的功能； upnp> save info 0 wrt54g Host info for '192.168.1.1:2869' saved to 'info_wrt54g.mir' upnp> save data wrt54g Host data saved to 'struct_wrt54g.mir' upnp> load struct_wrt54g.mir Host data restored: [0] 192.168.1.1:2869 DLNA简要概述 数字生活网络联盟（英语：Digital Living Network Alliance，简称：DLNA）是一个由消费性电子、移动电话以及电脑 厂商组成的联盟组织。该组织的目标在于创建一套可以使得各厂商的产品互相连接，互相适应的工业标准，从而为消费 者实现数字化生活。联盟成员包括飞利浦、三星电子、松下、惠普、索尼、微软、英特尔和诺基亚在内的众多业界领袖。 其实DLNA应该是一系列协议栈的组合统称，并不是一个单独的协议； NetWorking Connectivity 网络互联方式：802.3 以太网，802.11WiFi，802.15 蓝牙 NetWorking Stack 网络协议栈：IPv4、IPv6 Device Discovery&Control 设备发现和控制：UPnP，具体参考UPnP的相关文档 Media Management媒体管理：识别、管理、分发、记录； Media Transport 媒体传输：HTTP Media Formats媒体格式：各种音频图片格式：avi、rmvb、mkv。。。 Remote UI 远程用户接口：接口； 可以看到风险点主要在3、5、7， 3的分析还是参考 UPnP部分章节，5、7也就是常规的http服务由于不管是 DLNA的设计还是UPnP原协议的设计均不存在认证授权这一环节，主要是服务发现，以及请求构造；只要进 入局域网能够连接服务，均可以任意调用服务； 由于手上没有DLNA服务的设备，可以参考： https://breezetemple.github.io/2019/02/25/dlan-introduction/ 从文章中可以发现 不管是DLNA还是UPnP，都是通过soap来完成控制调用，格式也都是xml； 但是miranda-upnp 是针对upnp的 不知道是否也能发现基于UPnP的DLNA服务，即使能发现估计后续的服务发现需要调整源码的xml解析 具体参考源代码解析。 总结 不管是UPnP还是DLNA都是不存在验证授权机制，也就是说只要进入局域网就可以任意调用，如果只是UPnP一般用于 路由器上路由配置，链路转发，然后服务一般默认开启，这个利用场景相对风险较低一些，因为需要在其他设备存在问 题且路由器为公网ip的情况，才能实现公网直接访问的利用场景，其他场景的利用都是没有必要使用到这个场景的 也可能是我没有想到；DLNA服务一般用于投屏，这个就是直接可以利用的；然后还有特殊场景 视频流拉取，操作指令控制等。