一切新事物都是被遗忘的旧事物（或者更好的是，被遗忘的旧事物）。 当然，监视新漏洞是正确的，但您不应忘记旧漏洞。 特别是当制造商允许自己“忘记”它们时。 一定要记住。 否则，我们将一次又一次踩在同一耙上。
本文将重点讨论一个古老的问题，但事实证明，迄今为止从未失去其与UPnP漏洞的相关性。
PS我不会打电话给提供商，他对此没有罪，但是另一方面，对安全策略有明确的监督，再加上网络体系结构，就可以利用此漏洞。 与往常一样，星星会聚。 供应商在其网络上将路由器安装到具有必要芯片的客户端，并将其与外部IP地址连接。 是的，大多数端口均已过滤，但出于某种原因未过滤52869。
PPS所有事件均于2018年底发生。 英雄是虚构的，与真实人物的巧合是随机的。
简短的教育计划：有一些用于开发的libupnp库，“用于数千种设备上，称为UPnP设备的Intel SDK或UPnP设备的便携式SDK”。
用英语：
“用于UPnP设备的便携式SDK（libupnp）为开发人员提供了API和开放源代码，用于构建与通用即插即用设备体系结构规范1.0版兼容的控制点，设备和桥，并支持多种操作系统，例如Linux ，* BSD，Solaris等。”
第一次提到该漏洞是在2014年：
tyk尝试与制造商联系并没有带来太大的成功，该漏洞已被发布。 唯一的对策建议是：
“……限制与服务的交互……只有具有合法程序关系的客户端和服务器才应该能够与之通信。”
miniigd SOAP服务中存在一个缺陷。 由于无法在进行系统调用之前清除用户数据，因此问题正在处理NewInternalClient请求。 攻击者可以利用此漏洞以root特权执行代码。
即 在具有UPnP 1.0版的所有路由器上，您可以执行任意远程代码。
未经授权。 从根开始。 太好了吧？
任何人都可以在github上找到现成的用于metasplit的插件，该插件的性能已经由我们值班工程师的精疲力尽的椅子进行了测试。
这是出乎意料的，一点也不有趣。
当天事件的简要时间表：
14:00在技术支持下，订户开始收到功能不佳的Internet的呼叫。
- 客户端的症状： “它运行缓慢，重新启动后可以正常工作一会儿，然后再缓慢运行。”
- 设备方面的症状：流量的小幅增长和CPU负载被冲销到客户端产生的负载上。
注册了一个应用程序，以检查该行的管理员或安装者的离开。 没有通用的操作模板。 不清楚。
15:00申请
的数量开始超过医院的平均温度，并且单个申请开始按“事故”的类型雕刻为更多的申请。 将应用程序提交给高级管理员以验证网段。
15:20管理员关闭了大规模崩溃，因为 网络上没有问题，来自不同连接点的所有客户请求都是单个的。 （例如：交换机中有许多活动的订户，但是对于一个交换机来说效果不好）。 此时此刻，上诉下降，一切都平静下来。 有人注意到（最后）所有工作不佳的应用程序都使用相同的路由器模型，每个人都装作一切都很好。
15:30再次有来自订户的申请涌入，再次有大规模事故的登记并转移给管理员。 这时，很明显，有些事情
确实是错误的，需要完成一些事情（与客户服务部门合作的人会理解有时候这样做有多困难。客户
总是撒谎，有时第一线在于进一步扩大任务） 。
15:35值班
的工程师收到客户服务问题的请求。 获取所有客户端，它们的连接类型和设备型号的列表。 然后一点魔法开始了。
扰流板顺便说一句，这没有用，然后主要的魔术师被解雇了（但他们说不是这样做的）。
15:40工程师通过所有诊断来运行客户端列表，并根据所有标准度量标准检查了每个路由器，...一无所获。 路由器就像路由器。 是的，CPU有所增加，但指标并不重要，但它会将流量倾倒在某处，这意味着它可以正常工作。
是的，UPnP服务正在端口52869上旋转。 是的，仍然有许多开放的端口，开放意味着它们是必需的（铁逻辑），并且总是转过来，没有任何问题（铁逻辑的另一个论点）。 不能直接将ssh直接用于此路由器模型（坦率地说，这是可能的，但是在精简的忙碌箱和公司策略内部，不建议在客户端设备周围四处走动）。 一切又站起来了。
16:00直到现在我们才发现存在一些问题。 值班工程师向其主管报告，主管就有关52869端口的猜测给我们打了电话，并寻求帮助。
16:05然后一切都很快发生了。 测试台上包含相同的路由器型号，IP地址来自问题客户端，并挂在测试台上。 导线架已打开。 这是为了捕获对设备的请求。
为了捕获来自路由器的请求（当时尚不清楚交互方式的一般方案），客户端被隔离在测试段中，并且其所有流量都被镜像到最近的测试机器，在该机器上引发了另一个wireshark。
我们再等等，我们看屏幕。
黑客已经以这种方式被捕获-非常有效，因此决定不改变习惯。
16:10当细沙沙沙沙沙作响时，在Google中存在一个漏洞CVE-2014-8361，该漏洞已报告给工程师。 工程师无需聆听就可以做出决定（并且原则上是合乎逻辑的）-该端口在边界上的过滤器。 言归正传。
16:25有人告诉我们，
所有翻拍的狗屎Misha都不起作用。 而且我们已经知道这行不通。 到那时，他们已经敲响了测试路由器，将反向上升到
另一个端口上，并通过另一个漏洞开始将其用于DDOS-a至1900（！）端口。
主啊，有什么漏水的垃圾可以仍在教育的程序在DDoS攻击中使用
在2014年，他们意外地发现SSDP被用于DDoS攻击，例如“ SSDP反射放大攻击”。 许多设备（包括家用路由器）的UPnP软件都有缺陷，攻击者可以利用该缺陷将响应从端口1900发送到Internet上的任意地址。 在使用来自成千上万个此类设备的僵尸网络的情况下，攻击者可能会创建大量数据包流，足以占用带宽并饱和受攻击站点的数据通道，从而导致普通用户无法获得服务。
最有趣的是，设备上的防火墙规则已更改，nmap现在不显示来自外部的开放端口。 仅在流量转储中才可以检测到这些端口上的请求。 即 黑客攻击后的攻击者阻止了对其余设备的访问。 这不是高科技方法，但无论如何，还是很赞的。
16:30会议召开时提出了“谁应该受到指责和该怎么做”的问题。 禁止使用1900和52869端口，并试图在被入侵的设备上修复某些问题。 重新启动-没有帮助，重新刷新的想法立即被拒绝。 是的，它具有这样的功能，可以通过TR069使用所有设备上的一个按钮远程重新排列软件。 但是因为 该设备并不是头等大事，但客户数量很大-一定比例的实体设备会造成问题。
16:40总结：设备被黑客入侵，至少参加ddos并在加密通道上的某处传输内容。 （全部在
不同的端口上）。 无法进入内部，供应商拒绝通过ssh对设备进行完全访问，并查看无法到达那里。 控制台受密码保护。
在接近17:00的某个位置，决定缝制设备是最快的方法。 闪烁并重新启动后，一切恢复正常。
代替总数
不幸的是，我们不能完全解决这个问题。
“决定”是指获得完整的黑客信息并更新我们的政策以应对将来的情况。 是的，并非所有任务都能成功解决，而且我们也希望如此。 这很正常。 虽然侮辱。
如果在shodan上搜索很好，
你会发现自己的东西
用于实验：
一种方式或另一种
但我没有告诉你