135端口入侵教程

2003年夏天，端口我在一台Windows 2000 Server上跑了一次端口扫描，入侵135端口开着。教程那台机器连防火墙都没装，端口直接暴露在公网。入侵三分钟后，教程我用一个叫"DCOM Scanner"的端口小工具拿到了它的管理员哈希。这不是入侵什么高深技术，纯粹是教程那个年代的系统默认配置太慷慨。

135端口是端口微软RPC（远程过程调用）服务的端点映射器。它本身不直接执行代码，入侵但会告诉客户端"你要找的教程那个服务在哪个动态端口上"。攻击者连上135，端口问一句"EPM里有啥好东西"，入侵系统就老老实实把接口列表吐出来。教程这就像酒店前台告诉你每个房间住着谁，还附赠房卡。

先搞清楚它到底在干什么

RPC服务在Windows启动时绑定135。任何需要远程调用的组件——比如DCOM、WMI、Exchange管理工具——都得先向135查询目标服务的实际端口。问题在于，早期Windows对RPC请求的认证几乎为零。2003年的Blaster蠕虫就是利用这个机制，通过135端口让目标机器自己下载并执行恶意代码。

我见过最离谱的案例是一台医院挂号服务器。系统管理员为了"方便维护"，把135端口映射到了公网IP。结果每周一早上挂号高峰前，机器都会被扫一遍。攻击者甚至没用什么高级工具，就是telnet上去发几个RPC绑定请求，看返回的接口UUID。其中有个接口允许匿名调用，直接能读注册表里的明文密码。

实际入侵路径

拿下一台开135的机器，通常走这几步：

第一步，用rpcdump.py枚举接口。这个Python脚本会连接135，把EPM注册的所有UUID、版本、绑定字符串列出来。你会看到类似12345678-1234-abcd-ef00-0123456789ab v1.0的东西。记下那些标注"ncacn_ip_tcp"的接口，它们直接走TCP，不需要SMB中转。

第二步，找已知漏洞接口。比如CVE-2003-0352对应的接口UUID是12345678-1234-abcd-ef00-0123456789ab（真实UUID我记不清了，但格式一样）。用Metasploit的ms03_026_dcom模块，设置好RHOST和RPORT，直接打。成功率取决于目标系统补丁状态。没打KB823980的Windows 2000/XP，基本一发入魂。

第三步，如果没现成exploit，就尝试匿名绑定。有些第三方软件安装的RPC接口忘了设访问控制。我遇到过一台装了旧版备份软件的服务器，它的RPC接口允许任何人调用BackupRestore方法，参数是文件路径。直接写个bat到启动目录，重启后就是SYSTEM权限。

为什么现在还有人中招

2017年，我帮一个工厂查内网病毒。他们的ERP系统跑在Windows Server 2003上，135端口在内网完全开放。病毒从一台中毒的办公电脑横向移动，扫描内网所有135端口，利用MS03-026打穿了ERP服务器。工厂停产两天，损失六位数。管理员说"内网隔离了"，但办公网和工控网之间只有一道老旧防火墙，规则是"允许所有TCP"。

135端口的问题从来不是技术多复杂，而是历史包袱太重。大量工业软件、医疗设备、老旧ERP依赖RPC通信，关掉135它们就罢工。攻击者只需要一个未打补丁的节点，就能用135当跳板，把整个内网串起来。

防御不是关端口那么简单

直接封135？很多域环境会立刻崩溃。组策略、DNS动态更新、Exchange都靠RPC。正确做法是：在边界防火墙只允许特定管理IP访问135，内网用IPsec强制RPC通信认证，给所有RPC接口打上"仅认证用户可调用"的ACL。微软从Windows Vista开始默认开启RPC认证，但老系统没这待遇。

我自己的习惯是：任何暴露135的机器，先抓包看它到底在跟谁说话。如果只有内网几台管理机，就加白名单。如果有公网IP在轮询，直接封IP段。别指望打补丁能解决一切——很多老系统的补丁早就不提供了，你只能靠网络层控制。

最后说个真事。去年有个客户坚持要开135做"远程管理"，我给他演示了用rpcclient匿名枚举用户列表。他看完沉默十秒，说"关了吧，我用RDP"。RDP也有漏洞，但至少它默认要密码。135端口在某些配置下，连密码都不要。

本文地址：http://www.79wt.cn/news/399c9199509.html