测试默认口令凭证 (OTG-AUTHN-002)
综述
现在web应用程序通常会使用服务器上预装的流行的开源或商业软件，这些软件通常被服务器管理员以最小配置或定制状态预装在服务上。更多的，许多硬件供应商（如网络路由器和数据库服务器）提供web页面的配置接口或管理接口。
通常这些应用程序在安装后，没有正确配置，用于初次认证和配置的默认口令信息从来不改变。这些默认口令已经被渗透测试者熟知，同样不幸的，也被恶意攻击者熟知，他们能利用这些默认口令来访问不同的应用系统。
甚至在许多情况下，当一个新用户被应用创建后，会提供一个默认密码（通常很有特点）。如果这些密码是可以被预测的，用户又不在初次访问时更改他们，那么这些密码可能导致攻击者获取为授权的访问。
造成这个问题的主要原因可以被归结为以下几点：
- 没有经验的IT人员，他们没有意识到更改安装的组件的默认密码的重要性，或为了“维护方便”使用默认密码。
- 编程人员留下后门来轻易访问和测试应用程序，之后又忘了移除这些后门。
- 应用程序内建的无法移除的默认账户（包括预设用户名和密码）。
- 应用程序不强制用户在第一次登陆时修改默认口令。
如何测试
测试常见应用系统的默认口令
在黑盒测试中，测试者不了解应用程序和其支撑架构。在现实情况下，这通常不是真正情况，通常会已知一些应用程序相关信息。我们假设已经通过测试指南中的信息收集章节中描述的技巧鉴别出一个或更多的应用程序可访问的管理接口。
当我们已经鉴别出应用接口，比如Cisco路由器的web接口或Weblogic管理入口，检查使用这些设备已知的用户名和口令是否可以成功登陆系统。为了达到这个目的，我们可以查询生产商的文档，或用一种更简单的方法，我们可以通过搜索引擎查找常见口令或使用下文参考资料部分中列出的网站和工具。
当面对一些我们没有默认和常用用户列表（比如该应用没有广泛流传）的应用的情况下，我们尝试猜测合法的默认凭证信息。注意被测的应用程序可能拥有账户锁定策略，多次对已知用户名猜测密码可能引起该账户被锁定。如果管理账户被锁定，可能会麻烦系统管理员来重置他们。
许多应用可能拥有详细的错误信息来通知网站用户来验证所输入的用户名。这些信息在测试默认或可猜测的用户账户时候非常有用。这功能可能在登陆页面、密码重置页面、忘记密码页面和注册页面等等找到。一旦发现了默认的用户名，我们就可以针对这个账户进行猜测密码。
更多关于这个过程的信息可以在下面章节找到 测试用户枚举和可猜测用户账户 和 测试弱密码策略。
由于这些类型的默认凭证通常与管理员账户绑定，我们可以用如下方式进行尝试：
- 尝试下面的用户名 "admin", "administrator", "root", "system", "guest", "operator", 或 "super"。这些名字在系统管理员中非常流行，使用频率很高。此外我们还可以尝试 "qa", "test", "test1", "testing" 和类似名字。尝试将上述字段组合起来，用于用户名和密码字段。如果应用程序存在用户名枚举漏洞，那么我们可能成功通过漏洞来鉴别出上述类似用户名，用同样方式尝试获取密码。同时也尝试空密码或下面密码 "password", "pass123", "password123", "admin", 或 "guest" 等等结合任意枚举出来的账户。尝试使用上面这些例子的排列组合形式。如果这些密码都失败了，可能使用一些列表中的常用文件名和密码，并并行进行尝试。当然使用脚本能节约时间。
- 应用程序管理员用户通常以应用程序或者组织的名字来命名。这意味着如果我们正尝试测试一个叫"Obscurity"的应用，尝试使用obscurity/obscurity或其他类似用户名密码组合。
- 当为客户实施测试时候，尝试使用通讯录上获得的名字作为用户名，同时结合常用密码进行猜测。用户email地址可能揭示用户账户名和命名规则：如果职员John Doe的email地址是 [email protected]，那么我们可以试着发现在社交媒体下的系统管理员名字，并通过类似的命名机制来猜测他们的用户名。
- 对所有上述用户名尝试空密码。
- 通过代理或直接查看来审阅页面源代码和JavaScript脚本。找寻任何用户名和密码相关的引用。例如"If username='admin' then starturl=/admin.asp else /index.asp"(成功登陆与失败登陆情况）。同时，如果我们拥有一个合法账户，登录并检查每一个请求和响应，合法登录和失败的情况对比，如额外的隐藏域参数，有趣的GET请求（如login=yes）等等。
- 从源代码中的注释中找寻账户名字和密码。同时在源代码中的备份目录（或备份代码）中寻找，也有可能找到有趣的注释和代码。
测试新账户的默认密码
有时，应用系统会创建一个新账户并为其分配默认密码。这些密码可能拥有一些标准的特性，并可以预测。如果用户没有在初次使用时修改密码（通常在不要求强制更新密码时发生）或用户还没有登录过新系统情况下，攻击者可能利用这一特性获得非授权访问系统能力。
之前关于可能的密码锁定策略和详细的错误消息也同样在这里适用。
这测试这类默认密码的时候可以使用以下步骤：
- 查看用户注册页面可能能有助于确定期望的密码形式和最小最大用户名和密码长度。如果不存在用户注册页面，确定是否组织使用了标准的命名策略，如使用email地址"@"之前的名字部分作为用户名。
- 尝试推断应用程序如何产生用户名。比如，用户是否可以选择他们的用户名或者系统通过用户提供的个人资料生成用户名或者使用可预测的序列？如果应用程序确实使用可预测的序列来生成用户名，如user7811等等，尝试模糊枚举测试所有可能的账户。如果我们能通过应用系统对合法用户名和非法密码的不同响应来鉴别，那么可以尝试对合法用户名进行暴力破解（或者快速尝试参考资料部分常见的密码）。
- 尝试确定系统生成的密码是否可以预测。通过快速连续创建新用户比较密码来确定其是否可以预测。如果可以预测，尝试关联用户名或任何已经枚举出的账户，并基于此进行暴力破解攻击。
- 如果我们已经识别出正确的用户名命名规则，尝试通过一些可预测的序列（如生日）来暴力破解密码。
- 对所有上述用户名使用空密码或与用户名相同的密码进行尝试。
灰盒测试
下面的步骤依赖于完全的灰盒测试方法。如果我们只能获得其中的一部分信息，参照黑盒测试过程来填补缺少的信息。
- 与IT人员交流讨论来确定他们管理使用的密码和应用程序采取的管理机制。
- 询问IT人员是否必须修改默认密码和默认账户是否被禁用。
- 同黑盒测试章节部分描述一样检查数据库的默认密码，同时检查空密码。
- 检查代码中硬编码的用户名和密码。
- 检查保护用户名和密码的配置文件。
- 检查密码策略，以及如果应用程序为新用户生成密码，检查这个过程中使用的密码策略。
测试工具
参考资料
白皮书