几个月前，我曾发过一篇博客” SNMP 最佳实践“讲述了一些基本的方法降低来自 SNMP 相关的安全隐患。我想现在大家应该都修复完了，那么是时候来从渗透测试的角度讲述如何通过收集分析数据来发现并利用暴露的 SNMP 服务。
第一个问题是我们如何发现暴露的 SNMP 服务。通常我们会使用端口扫描工具 Nmap 来扫描开放的 UDP 端口 161。鉴于我们只是想有针对性的发现并提取数据，那么使用 Python 或 Perl 小脚本反而会更加方便简单。就我个人来说，我更倾向于使用 Perl，因为我已经写好了一个这样的脚本，你可以从我的 Github页面上下载使用。如果你选择使用我的脚本，使用方法非常简单，如下图所示：
我在使用这个脚本的时候，我会将目标设置为要测试的一个子网范围。例如，如果我想要测试内网的地址范围 10.10.0.0/16，我会使用如下命令， ./snmpbw.pl 10.10.0.0/16 public 2 32。这个命令会启动 32 个进程来尝试发现 10.10.0.0/16 子网内所有暴露在 UDP 端口 161 上面的 SNMP 服务。当发现启用 SNMP 服务并且团体名(community string) 标示为 “public” 的设备时，会从 “.1″ 开始枚举所有的 MIB(管理信息库) 表，并将返回的数据保存到一个文件中以供后续的分析。
这个方法可以获取到很多帮助了解攻击目标网络环境的有用数据。 我经常会在确定目标 IP 地址范围后就献出这个脚本来收集 SNMP 数据，然后就让其慢慢在后台运行着，而我则继续进行其他一些网络侦查的工作。当脚本运行结束后，我们就要来分析得到的数据了。
分析的第一步就是从每一个文件的 MIB 表数据中提取出 sysDesc .1.3.6.1.2.1.1.1.0，以确定我们是从哪些设备中收集到的数据。这一步很简单只需要使用如下的 grep 命令即可：
grep ".1.3.6.1.2.1.1.1.0" *.snmp
使用这个 grep 命令的示例如下图所示：
现在，你获取到了所有暴露出来 SNMP 服务的数据了，那么从这些数据中你能发现什么呢？实际上，从这些 SNMP 服务数据中暴露出的信息相当惊人，而我则经常会寻找以下有用的信息：
Email 地址
SNMP 团体名
密码的哈希值
明文传输的密码
当然，想挖掘出有用的信息非常消耗时间，因为导出的 MIB 数据往往会非常大能上好几兆。所以我花了些时间研究如何减少花费在检查和识别上的时间，并准备在这里分享一些给大家。
我在处理 SNMP MIB 数据时最喜欢干的一件事就是查找其他可用的 SNMP 团体名，因为这些数据通常可以用来进一步去访问其他系统。举个例子，如果我从一家公司的 Cisco 路由器上找到其私有的团体名标识，那么我后面就可以利用这个标识来从公司其他的路由器上提取运行配置。找到这些数据最好的方法就是查找关联的 SNMP Trap 数据包。使用类似上面的 grep 命令就可以从大量的 MIB 数据中快速的找到与关键字 “trap” 相关的数据了。
grep -i "trap" *.snmp
下图的示例显示了我成功的从大量的 SNMP 数据中枚举出来与 “trap” 相关的数据。在这个示例中，我成功的找到几个 SNMP 的团体名，随后我使用这些团体名成功的获取到了整个网络中的所有 Cisco 路由器的运行配置文件。
另一个有趣的东西是日志，我发现有些设备会将日志信息也存到 MIB 表中。这些日志里面当然也会包含失败的登录尝试，想想你可能会在通过 Telnet 或 SSH 登录时无意中输入了密码当做用户名，悲剧…必须承认我经常犯这毛病，所以我也要检查 MIB 表中的日志是否也记录到这类信息。通过提取 SNMP 数据，你可能会发现一些将密码作为用户名输入的日志信息，为了检索这些信息，我通常会选择搜索关键字 “fail”、”failed” 或者 “login” 看看是否会得到一些有用的数据。
grep -i "fail" *.snmp
下图的示例显示了从 SNMP MIB 表中找到的将密码做为用户名登录的错误信息日志。最棒的事情就是日志的下一条可能就是密码对应的真实用户名。
这里特别需要注意，这些日志通常非常短，在屏幕上会快速的一闪而过，所以请确保在对设备进行暴力破解前保存一个备份。如果不这样，你可能会得到像下图一样的结果。
最后总结下，我希望以上几个小例子可以告诉你如何提取和利用 SNMP 数据。同时我还要特别指出，一定要花些时间在检查暴露出的 SNMP 数据上， 这样我们就可以为顾客更好的鉴定 SNMP 存在的安全风险并提供相应的解决方案。
本文转自d1net（转载）
