刚才提到的这些应用之所以采用Basic认证进行身份验证,原因是在应用配置、Tomcat配置等文件中进行了如下配置:
- 认证的方式(BASIC、DIGEST、FORM、SSL等)
- 通过
security-constraint
配置需要鉴权的访问路径
- 用户的身份信息(账户、密码)、权限(角色)
- 默认的域(Realm)配置,Tomcat的
server.xml
中默认配置UserDatabaseRealm
,它从配置的全局资源conf/tomcat-users.xml
中提取用户信息,在Tomcat 7.0及以上版本中,还提供了LockOutRealm
的组合域,用来阻止短时间内多次登录失败的情况。
在经过了如上配置后,再访问这些管理后台将需要进行Basic认证。
弱口令
虽然Tomcat没有提供默认用户,但是在配置文件中含有注释了的配置样例,其中包括的用户名密码:
tomcat:tomcat
both:tomcat
role1:tomcat
有的管理员可能会取消注释直接使用这些默认配置的账户密码,因此可以将其当做Tomcat的默认口令
除此之外,还有的管理员习惯于使用常用的用户名及密码,如:
admin:admin
admin:123456
root:root
manager:manager:
admin:admin888
...
以上仅仅是列出一小部分作为示例,实际上还有很多种类的弱口令。一旦弱口令被攻击者猜解到,攻击者能够轻易的获取一些用户的权限,大大降低了攻击成本。
暴破
Basic认证是一种较为简单的HTTP认证方式,客户端通过明文(Base64编码格式)传输用户名和密码到服务端进行认证。
客户端携带数据格式为:
Authorization: Basic dG9tY2F0OjEyMzEyMw==
服务端会根据用户是否登陆成功返回 200 或 401 等不同的状态码,攻击者可以自行组织字典进行暴力破解攻击。
暴力破解携带的账户密码可能是弱口令,也可能是撞库攻击,还可能是根据站点、管理员自身信息生成的字典等,具有更高的成功率。
如下,使用 Burpsuite的 Intruder 模块对 Tomcat 6.0 的 /manager/html
路径的基础认证进行爆破:
限制
刚才提到了,在Tomcat 7以上配置文件默认添加了LockOutRealm
,首先我们看一下 LockOutRealm
的逻辑,代码位于org.apache.catalina.realm.LockOutRealm
。类里的字段很明了,无需解释。
在 authenticate
方法中进行身份验证,如果用户登陆失败,将调用 registerAuthFailure
方法标记用户的登录失败状态
这段代码我贴一下:
private void registerAuthFailure(String username) {
LockOutRealm.LockRecord lockRecord = null;
synchronized(this) {
if (!this.failedUsers.containsKey(username)) {
lockRecord = new LockOutRealm.LockRecord();
this.failedUsers.put(username, lockRecord);
} else {
lockRecord = (LockOutRealm.LockRecord)this.failedUsers.get(username);
if (lockRecord.getFailures() >= this.failureCount && (System.currentTimeMillis() - lockRecord.getLastFailureTime()) / 1000L > (long)this.lockOutTime) {
lockRecord.setFailures(0);
}
}
}
lockRecord.registerFailure();
}
重点的判断逻辑是:
如果用户的登录失败次数>=5次,并且,(当前时间-上次登录失败的时间)>300s,将会将用户登录失败的次数重新设置为0。
函数最后一行是内部类的方法,将 failures += 1,并将 lastFailureTime置为当前时间:
由此可知,在5分钟之内同一账户登陆失败5次以上,LockOutRealm
将会封锁用户,在未来5分钟之内没有新的登陆失败的情况,会从0开始重新计数,因此这种方式是能够一定程度缓解系统受到的暴力破解攻击的。