攻击网站而不留下审计线索
最近Aetna 遭遇违规，导致其失败65,000 个 SSN。 他们始终无法找到所发生事件的审计跟踪，这可能暗示攻击利用了 XSS 或类似技术。
坏人是否反复利用特定的已知攻击来进行此类攻击？
Recently Aetna suffered a breach where it lost 65,000 SSNs. They never were able to find an audit trail of what happened which probably hints that the attack leveraged XSS or similar technique.
Are there specific known attacks that the bad guys are repeatedly leveraging for this type of attack?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
人们会犯一些常见的错误，人们也会使用一些常见的平台。 如果不打补丁，每个人都可以使用简单的脚本进行闯入。
但是，如果有人专门追求某些在有组织犯罪团伙中具有很高价值的东西（在本例中是社会安全号码），我预计有人会花更多时间弄清楚该网站的工作原理并应用自定义漏洞来获取数据。
我也不明白为什么它必须是 XSS。 如果他们的系统没有将访问日志发送到服务器之外，甚至没有记录每个入口点，那么有人可以通过多种方法来利用可利用的服务器并在事后进行清理。
There are common mistakes that people make and there are common platforms that people use. Each, if left unpatched would allow somebody to break in using a simple script.
But if somebody was going after something specifically, in this case social security numbers, that have high value in organised crime rings, I would have expected somebody to spend a little more time figuring out how the site worked and applying a custom exploit to grab the data.
I don't see why it has to be XSS either. If their systems weren't sending access logs off-server, or even logging every entry point, there are a variety of methods somebody could exploit an exploitable server and clean up afterwards.
目前还不清楚这是一次技术故障，而且考虑到不确定的取证，在我看来，这更有可能是人为故障，无论是社会工程、留在火车座位上的数据还是心怀不满的员工。
AFAIK 真正留下零审计线索的唯一方法是不编写审计。 单独记录 HTTP 流量总会为您提供一些基于 HTTP 攻击的证据。
It's not at all clear at this point that this was a technical failure, and given the inconclusive forensics it seems much more likely to me that this was a human failure, be it social engineeering, data left on a train seat, or a disgruntled employee.
AFAIK the only way to truly leave zero audit trail is for the auditing to have not been written. Logging HTTP traffic alone will always give you some evidence of an HTTP based attack.
我已经看到了一些自动攻击的结果，他们所做的第一件事就是禁用日志记录并删除所有日志。
这就是为什么将日志记录位置更改为非标准路径很常见 - 它不会对坚定的攻击者做任何事情，但在自动攻击的情况下它会为您提供更多信息。
I've seen the results of some automated attacks, and one of the first things they do is disable logging, and delete all logs.
That's why it's common to change logging locations to a non-standard path - it won't do anything against a determined attacker, but it will give you more information in the case of an automated attack.
至少可以说，缺乏审计追踪并不奇怪。 没有多少公司保留有意义的审计跟踪。 当然，通常有千兆字节的日志，但谁会浏览所有这些呢？ 大多数 IT 部门都会在其足够老化后将其转储，因此完全有可能此漏洞发生在不久前，并且他们已经转储了日志，因为从文章中看来，他们直到垃圾邮件才知道可能的漏洞 我怀疑
是糟糕的 IT，而不是某种巧妙的攻击导致缺乏审计跟踪。
The lack of an audit trail is not surprising to say the least. Not many companies out there keep meaningful audit trails. Sure, there's often gigabyte and gigabytes of logs, but who goes through all of that? Most IT places would just dump it once it ages enough, so its entirely possible that this breach happened a while ago and they've already dumped the logs since from the article it looks like they did not know about the possible breach until the spam mail started coming in.
I'd suspect poor IT instead of some clever attack that caused the lack of an audit trail.