6.4.10 日志注入

如果应用日志在输入到达日志之前未作净化和校验,开发人员就必须考虑读写应用日志的风险了。容易遭受注入的日志可能已经被恶意用户侵入,用误导性的项目覆盖成功攻击的痕迹。这也被称做抵赖攻击(repudiation attack)。不能安全地记录用户操作的应用可能遇到用户否认操作的情况。想象一下以如下格式记录请求的应用:


Date, Time, Username, ID, Source IP, Request

这些参数直接来自请求,没有输入校验:


Cookie: PHPSESSID=pltmp1obqfig09bs9gfeersju3; username=sdr; id=Justin

攻击者可以修改id参数,用错误的项目填充日志:


Cookie: PHPSESSID=pltmp1obqfig09bs9gfeersju3; username=sdr; id=\r\n
[FAKE ENTRY]

在某些平台上,如果日志不能正确地避开空(Null)字节,应该记录下来的字符串剩余部分可能没有记录。例如:


Cookie: PHPSESSID=pltmp1obqfig09bs9gfeersju3; username=sdr; id=%00

可能造成记录项目在id域上停止:


Date, Time, Username, ...

日志注入的一个实例发生在流行的SSHD监控工具DenyHosts上。DenyHosts监控SSH日志,动态地阻止产生太多验证错误的连接的源IP。版本2.6容易遭受一种日志注入攻击,这种攻击能够导致SSH拒绝服务。因为允许用户指定记录的用户名,攻击者可以在控制SSH访问的/etc/hosts.deny文件中指定任何用户。通过指定所有用户,攻击者在机器上完全锁定SSH服务,阻止所有外部连接。关于这种日志注入漏洞的更多信息可以在http://www.ossec.net/main/attacking-log-analysis-tools上找到。

所有日志和监控系统都需要严格的校验,避免截断日志项目导致信息丢失的攻击。最严重的日志注入攻击能够侵入用于监控日志的系统,由于没有完成何种类型攻击的证据,事故响应特别困难。