Posts List

GMail XSS 漏洞分析

原文:XSS in GMail’s AMP4Email via DOM Clobbering 译者:neal1991 welcome to star my articles-translator, providing you advanced articles translation. Any suggestion, please issue or contact me LICENSE: MIT 这篇文章是我在2019年8月通过Google 漏洞奖励计划报告的 AMP4Email 中已经修复的 XSS 的文章。该 XSS 是对著名浏览器问题 DOM Clobbering 的真实利用案例。 什么是 AMP4Email AMP4Email(也称为动态邮件)是 Gmail 的一项新功能,可以让电子邮件包含动态 HTML 内容。尽管撰写包含 HTML 标签的电子邮件已经很多年了,但通常认为 HTML 仅包含静态内容,即某种格式,图像等,没有任何脚本或表单。 AMP4Email 打算更进一步,允许电子邮件中包含动态内容。 在Google 官方 G Suite 官方博客中的帖子中,对动态邮件的使用案例进行了很好的总结 通过动态邮件,你可以轻松地直接从消息本身直接操作,例如对事件进行快速回复,填写问卷,浏览目录或回复评论。 以在 Google 文档中进行评论为例。现在,你将不再在有人在评论中提及你时接收到单独的电子邮件通知,而是会在 Gmail 中看到最新的主题,你可以在邮件中直接从中轻松回复或解决评论。 该功能引发了一些明显的安全性问题。最重要的一个可能是:跨站点脚本(XSS)?如果我们允许电子邮件中包含动态内容,是否意味着我们可以轻松地注入任意 JavaScript 代码?好吧,答案是否定的;没那么容易。

Holiday -- hack the box

Introduction Target: 10.10.10.25(Linux) Kali: 10.10.16.65 Holiday is an insane box officially. It’s really difficult to get the user permission. The most difficult part should be how to pass the XSS filter. It may need a lot of time. And the root privesc is based on the exploitation of npm install which is relatively fresh. Information enumeration As usual, use nmap to detect open ports and related services: nmap -A 10.

使用浏览器作为代理从公网攻击内网

介绍 在 Forcepoint,我们不断寻求改善我们产品所提供的防护。为此,我们经常研究不寻常或潜在新颖的攻击技术。最近的一个研究课题是从公网发起的针对 localhost 和内网的攻击。 虽然不是新的攻击,但在安全研究社区之外,恶意 JavaScript 可以攻击内网并不广为人知。在关于该主题的有限文档中,大多数资源是从 inter-protol(协议间)漏洞来描述 [1] [2],而我们的重点是 intra-protol(协议内部)的漏洞。我们发现没有一站式资源从协议内部攻击的角度去描述这种攻击,并且在白皮书中收集这些技术是为了填补关于这些攻击文档的空白,以及让被低估的攻击面受到关注。 由于浏览器默认可以访问 localhost 以及本地局域网,因此这些攻击可以绕过潜在的本地基于主机的防火墙以及企业/消费者外围防火墙。 恶意攻击者了解这些攻击,但防守者也需要被告知。除了描述攻击的技术细节之外,我们还将讨论检测和防范攻击的方法。 可疑行为:公网到局域网的连接 从恶意站点加载的 JavaScript 可以在许多情况下能够连接用户本地计算机(localhost)或其他内部主机上运行的服务。现代 Web 浏览器不能完全阻止使用受害者浏览器作为代理攻击内网。事实上,我们不仅可以让受害者浏览器在内部发送请求,而且我们还可以发现内部主机,进行有限端口扫描,进行服务指纹识别,最后我们甚至可以通过恶意 JavaScript 来攻击易受攻击的服务。 如果从公网获取的网页尝试访问未路由的 IP 地址(例如 localhost 或内部网络),则应将其视为可疑行为。通过我们的遥测技术,我们还没有发现过存在于公网上的良性网页需要连接到私有 IP 地址,我们也没有发现任何有效和合理的业务用例来做这样的事情。是否有必要允许公网上的网页连接到私有 IP 地址,而不是在某些边缘情况下,这是值得怀疑的。一个边缘情况可能是在内部网络上使用公共 IP 地址的不常见设置。(但必须允许相反的方向的情况,因为许多内部页面可能出于完全正当的原因而获取外部资源。) 这种可疑行为与攻击链的各个部分一起具有某些特征,可以用于检测目的建模。我们稍后将回到更详细的关于检测的讨论,因为如果我们先了解攻击链的技术细节,检测就更有意义了。 在进行威胁建模时,开发者通常认为本地服务永远不会接收外部输入,因此通常缺乏对这些服务的安全审核。可能通过远程托管的恶意 JavaScript 攻击易受攻击的本地服务的最新示例是 Logitech Options 应用开启易受攻击的 WebSocket 服务器 [3]。通过远程跨域 JavaScript 进行的本地攻击代表了一种被低估的攻击面。 同源策略不会阻止本地攻击吗? 实际上,同源策略(SOP)[4]在很多情况下确实可以防范这种攻击,但正如我们看到的,仍然存在攻击可能成功的情况。尽管有相关文档,通常被忽略的事实是同源策略并不会阻止浏览器发出跨域请求,它只能阻止 JavaScript 读取响应。(同源策略允许嵌入跨域资源,如图像和 JavaScript,但这是另外一方面的内容。)对于攻击某些易受攻击的服务,它可能足以能够盲目地发送恶意请求以达到攻击者的目的。 Mozilla 的文档很好地描述了同源策略的功能:允许跨域嵌入和写入,但不允许读取。允许跨域写入的事实使得可能执行以下攻击: 受害者在互联网上浏览恶意页面。页面上的 JavaScript 根据同源策略向不应与之通信的内部服务器发出异步请求(XMLHttpRequest)。 然而,浏览器将发送请求(此时服务器被利用)。 浏览器收到响应但不会将其传递给 JavaScript。 那跨域资源共享呢? 我们要展示的攻击与跨域资源共享(CORS) [5] 无关,只与同源策略相关。在本白皮书中,我们可以假设不允许跨域资源共享请求,这意味着我们拥有最严格的设置,其中同源策略“阻止”所有内容。即使面对同源策略,我们也可以进行攻击。 攻击概述 我们将看一下使用受害者的浏览器作为代理,外部站点上的 JavaScript 如何攻击运行在 localhost 或内网中的易受攻击的服务的示例。作为概述,我们将看看以下步骤: