利用Laudanum攻破Tomcat：从Metasploit失败到手动部署Web Shell

在最近的一次安全测试[1]中，我发现了一个使用默认用户名和密码的Tomcat服务器。本以为可以轻松获取shell，于是启动Metasploit，选择multi/http/tomcat_mgr_deploy模块指向服务器，却意外失败。多次尝试无果后，发现是Linux x86_64系统上64位payload存在问题，即使使用通用payload也未成功。

Metasploit邮件列表的快速回复是：“该模块已损坏无法修复，将被移除”。这虽然节省了时间，但并未解决我的问题。既然已拥有管理控制台完全访问权限，我决定不放弃。

在邮件列表讨论中，有人推荐了Secure Ideas（前身为InGuardians）的Laudanum工具集。这是一组可上传至Web服务器以获取shell和其他功能的文件。

使用Laudanum攻击Tomcat相当简单：从jsp目录获取cmd.war文件，通过Web控制台上传。若应用自动部署成功，会在应用列表中显示“cmd”。但点击链接会出现“HTTP Status 404 - /cmd/”错误。检查WAR文件源码发现没有index.jsp，但有cmd.jsp。将cmd.jsp添加到URL末尾后，成功出现命令输入文本框，执行ls命令后获得目录列表，终于获取了shell。

不甘于此，我在实验室中进一步测试Tomcat，发现几个可能阻碍攻击的问题：

1. Apache 404页面：与Tomcat 404页面明显不同。出现此错误是因为Tomcat未设置为自动部署新应用，需修改后台XML文件启用该功能。若遇此错误，此攻击路径无效。

2. 500错误：在“root cause”部分显示： java.security.AccessControlException: access denied (java.io.FilePermission <<ALL FILES>> execute) 表示服务器已禁止系统命令执行，这是另一种shell获取失败。该设置从Tomcat 5.5.25版本起成为标准。

3. Windows系统：需要在命令前添加cmd.exe /c，否则会出现“command not found”等错误（因无Windows实验环境，无法提供确切消息）。

这是我首次超越标准Metasploit模块利用Tomcat，通过此过程更深入理解了Tomcat，并萌生了开发新工具的想法（是否发布取决于工作量）。

实验室实践

若想在实验室中尝试Laudanum，Turnkey提供两个预构建的Tomcat服务器：纯Tomcat和Apache上的Tomcat。当前版本均配置为阻止shell工作。基于Apache的版本不自动部署，Tomcat版本启用了命令执行保护。建议获取两者以观察不同错误，但若想成功获取shell，可下载Tomcat版本并创建文件/etc/tomcat5.5/policy.d/99hack.policy，内容如下：

1
2
3

grant {
    permission java.security.AllPermission;
};

然后重启Tomcat。

若需在基于Apache的服务器上手动部署shell，需编辑/etc/tomcat5.5/mod_jk.conf并添加：

1
2

JkMount /cmd    ajp13_worker
JkMount /cmd/*    ajp13_worker

然后重启Tomcat和Apache。

结论

这一切的意义何在？首先，若Metasploit失败，不要假设完全失败并放弃，许多shell可能因此被遗漏。若有时间，进行研究并提出问题，仍可能获取shell。其次，尝试Laudanum。其shell虽不如Meterpreter强大，但有时简单即所需，若你是编码者，可将其作为基础创建自己的超级shell。

若任何人发现本文错误，请联系我。所有内容均来自Google和实验，若有更好的方法或解决错误的技巧，我非常乐意了解。

[1] 实际测试可能发生在六个月前，本文大部分内容当时撰写，后因其他事务中断，直至最近才完成。