by ·挖洞经验 | ServiceNow错误配置管理实例导致的信息泄露漏洞已关闭评论
本文讲述了作者通过云服务管理公司ServiceNow产品，发现很多ServiceNow企业客户未对其中的知识库服务端设置必要的权限和身份验证措施（Misconfiguration），导致内网信息泄露。作者通过该漏洞收获了将近$30,000的奖励。

背景介绍

ServiceNow是美国一家云计算平台公司，提供软件即服务 (Software as a service)，帮助企业运营管理数字化工作流程。ServiceNow专注于信息技术服务管理 (IT service management)、信息技术运营管理（IT operations management）和信息技术商务管理（IT business management）的服务研究，为企业客户通过各种应用和插件管理项目、团队和客户互动关系。

ServiceNow产品基于根本原因（Root Cause）识别模型提供服务，以帮助用户确定问题，并帮助用户通过自助服务纠正问题。该服务模型ServiceNow产品中显示为具体的任务（tasks）、活动（activities）和流程（processes），各种应用服务由不同的云服务实现分离。

例如，你公司的ServiceNow服务管理实例可由以下链接访问到：

https://yourcompanyname.service-now.com

漏洞所在

首先，我研究的一个模块是ServiceNow的知识库 (Knowledge Base，KB)，ServiceNow的知识管理（Knowledge Management，KM) 应用程序具备知识库的信息共享，其知识库中包含了指导用户进行问题排查和自助任务解决的操作说明书。
用户可以自行创建知识库（KB）以便进行保存分享，创建好一个知识库后，ServiceNow会为其分配一个唯一识别号，如以下界面中的KB00110XX：

当用户打开每个知识库对应的文件时，会执行以下请求调用：

https://company.service-now.com/kb_view_customer.do?sysparm_article=KB00xxxx

漏洞利用

经测试发现，很多部署了ServiceNow的公司企业虽然对ServiceNow服务管理实例设置了Okta或onelogin的身份验证措施，但对上述知识库（KB）服务端根本未设置有必要的权限和身份验证手段。

因此，我结合ServiceNow产品的管理实例，以.service-now为域名枚举对象，针对一些大型企业和组织机构做了探测发现。一旦其中有ServiceNow知识库实例，我就用burp intruder对其知识库唯一识别号（KB001XXXX）后四位进行枚举，再结合burp Grep/Match功能对其中响应的关键字进行匹配，如password, internal, credentials, confidential等。

发现结果

大多数公司泄露的知识库用途超出预期，总体来说比较严重，主要是以下几方面数据信息的泄露：

公司内部流程、标准作业程序SOP、图表、开发计划；
密码、登录内部网站的用户令牌；
包含IP地址的用户请求附件内容；
公司雇员交流过程中泄露的一些客户个人身份信息（PII）。

当然，也有一些公司觉得这不算什么太大的安全风险，但我还是鼓励他们进行修复处理。

漏洞奖励 – $30,000

ServiceNow是一家排名前五的云服务管理提供商，很多大公司都采用了其云管理体系。我花了两天时间，经由H1 & bugcrowd平台和朋友关系对存在上述漏洞的多家公司进行了通报，目前为止已经收获了将近$30,000的奖励，还有一些漏洞报告正在分类中。

这是ServiceNow公司的产品漏洞吗？

不。这只是部署了ServiceNow产品的企业未对其中的知识库服务端设置恰当的访问控制权限，导致一些涉及公司内部的知识库文件曝露在互联网上，究其原因就是企业客户自身的错误配置漏洞。

*参考来源：medium，clouds 编译整理，转载请注明来自 FreeBuf.COM

by ·挖洞经验 | 利用泄露的NPM_TOKEN访问项目私有仓库已关闭评论
本文讲述了作者在目标站点的JS脚本中发现了NPM_TOKEN和私有仓库链接，然后利用该NPM_TOKEN，结合.npmrc格式请求，访问到了目标站点相关的NPM项目私有仓库。漏洞获得了厂商$8000的奖励。

发现过程

最近，我选择了一个处理效率和支付奖励相对较高的漏洞测试项目，寄希望于能从其中发现一些高危漏洞。我先是在目标站点中尝试了模板注入（template injection），之后又测了一遍IDOR，都一无所获。于是，我就下载目标站点中的JS文件看看能否发现一些信息泄露问题。
首先，我用BURP Suite pro来把目标站点的JS文件提取下载为一个文件，这样的方式不算太直观友好，然后我又用以下脚本来把它们分隔成单独文件：
cat urls.txt | xargs -I{} wget "{}"
# Assuming urls are clean i.e. they don't have any extra parameters in the end
# if the url is like this : https://storage.googleapis.com/workbox-cdn/releases/5.1.2/workbox-cacheable-response.prod.js?v=123122
# Then you need to cut the part after '?' like the following
cat urls.txt | cut -d"?" -f1 | xargs -I{} wget "{}"
Tomnomnom的代码模式转化工具gf在此就派上用场了，使用gf加文件路径的方式，我从上述JS脚本中发现了一个泄露IP地址：http://172.x.x.x，在其上下文信息中我又找到了一个NPM_TOKEN值，但这个NPM_TOKEN怎么来利用呢？我有点不懂。平时很少用到NMP，只知道它是Node package manager。
经过一番研究，我对NPM_TOKEN值有了以下了解：
1、在一些持续集成的开发系统（Continuous Integration systems）中，如Jenkins pipelines或Travis CI等，会在自动化模式的Web应用开发部署中用到NPM_TOKEN值，用NPM_TOKEN可以访问到项目的一些NPM私有仓库（Npm private repository）；
2、不同类型的NPM_TOKEN具备不同的权限，如有仅限读+发布的Read and publish only、只读的Readonly以及指定特定IP范围的CIDR白名单化等等；
3、用以下.npmrc格式来使用NPM_TOKEN：
registry=https://registry_link_here
//registry_link_here/:_authToken=auth_token_here​
于是，我就尝试用以下 .npmrc格式来测试：

registry=https://registry.npmjs.org
//registry.npmjs.org/:_authToken=auth_token_here​
测试第一天-在该利用方式中，如果NPM_TOKEN有效的话，执行npm whoami命令，会收到响应。但很可惜，没有任何响应。另外，有一些文章说 .npmrc格式中的NPM_TOKEN是加密串。
测试第二天-工作到家将近晚上8点了，我又继续测试这个NPM_TOKEN。我想到在年初我读了一些跨站WebSocket劫持(CSWH)的文章，Cross Site Websocket Hijacking，所以我结合其进行了一些分析。CSWH利用的条件是，websocket只使用cookie进行通信交流，这有点像跨站请求伪造（CSRF）攻击。在BURP练习中对CSWH也有所涉及：
接着，我想看看能不能在前述获得的JS脚本中发现一些websocket信息，但一无所获。之后，我从中发现了客户端请求时，服务端产生分配的一个nonce值，经测试发现可以用它实现CSRF攻击，就这样在寻找CSWH漏洞的过程中发现了CSRF漏洞。于是我进行了上报，在另外的博文中我会作讲解。
测试第三天-经过两小时的分析，我发现其中一个JS脚本文件有点意思，可以用以下三步操作使其代码规则化。Firefox下的代码规则化：
Chrome下的代码规则化：
该文件将近有17k数量的行数，大多是webpack类代码，经过仔细分析，在其中又发现了一个NPM_TOKEN值：
并且，在其附近还存在一个私有注册链接（private registry link）：

我就想，那这个注册链接会不会是其私有仓库的链接呢，于是，我就加入了发现的NPM_TOKEN值，用下.npmrc方法进行了请求：
registry=https://private_registry_link_here
//private_registry_link_here/:_authToken=auth_token_here
执行npm whoami命令，竟然有了成功响应：srv-npm-registry-ci。
然后，我想列出它的所有NPM包信息，不行。于是，我在其JS文件中的打包信息中发现了一些私有仓库的线索，如以下这个：
因此，我用下述命令对其私有仓库进行了请求：
npm view private_repo
npm get private_repo
响应如下：
使用这种方法，我可以下载一些目标项目的私有仓库，从中发现了一些配置类JS脚本和大量的源代码。开发者在项目中明显未做权限设置。没有做深入测试，我就把漏洞上报了。漏洞在当天就被分类处理了，7天之后，我收到了$8000的奖励。

总结

1、可以从一些JS脚本文件中发现隐藏信息；
2、要学会使用浏览器的开发者工具，它们的功能超乎想像；
3、保持测试工具更新；
4、坚持不懈是关键。

*参考来源：medium，clouds 编译整理，转载请注明来自 FreeBuf.COM 

 

by ·挖洞经验 | 利用泄露的NPM_TOKEN访问项目私有仓库已关闭评论
本文讲述了作者在目标站点的JS脚本中发现了NPM_TOKEN和私有仓库链接，然后利用该NPM_TOKEN，结合.npmrc格式请求，访问到了目标站点相关的NPM项目私有仓库。漏洞获得了厂商$8000的奖励。

发现过程

最近，我选择了一个处理效率和支付奖励相对较高的漏洞测试项目，寄希望于能从其中发现一些高危漏洞。我先是在目标站点中尝试了模板注入（template injection），之后又测了一遍IDOR，都一无所获。于是，我就下载目标站点中的JS文件看看能否发现一些信息泄露问题。
首先，我用BURP Suite pro来把目标站点的JS文件提取下载为一个文件，这样的方式不算太直观友好，然后我又用以下脚本来把它们分隔成单独文件：
cat urls.txt | xargs -I{} wget "{}"
# Assuming urls are clean i.e. they don't have any extra parameters in the end
# if the url is like this : https://storage.googleapis.com/workbox-cdn/releases/5.1.2/workbox-cacheable-response.prod.js?v=123122
# Then you need to cut the part after '?' like the following
cat urls.txt | cut -d"?" -f1 | xargs -I{} wget "{}"
Tomnomnom的代码模式转化工具gf在此就派上用场了，使用gf加文件路径的方式，我从上述JS脚本中发现了一个泄露IP地址：http://172.x.x.x，在其上下文信息中我又找到了一个NPM_TOKEN值，但这个NPM_TOKEN怎么来利用呢？我有点不懂。平时很少用到NMP，只知道它是Node package manager。
经过一番研究，我对NPM_TOKEN值有了以下了解：
1、在一些持续集成的开发系统（Continuous Integration systems）中，如Jenkins pipelines或Travis CI等，会在自动化模式的Web应用开发部署中用到NPM_TOKEN值，用NPM_TOKEN可以访问到项目的一些NPM私有仓库（Npm private repository）；
2、不同类型的NPM_TOKEN具备不同的权限，如有仅限读+发布的Read and publish only、只读的Readonly以及指定特定IP范围的CIDR白名单化等等；
3、用以下.npmrc格式来使用NPM_TOKEN：
registry=https://registry_link_here
//registry_link_here/:_authToken=auth_token_here​
于是，我就尝试用以下 .npmrc格式来测试：

registry=https://registry.npmjs.org
//registry.npmjs.org/:_authToken=auth_token_here​
测试第一天-在该利用方式中，如果NPM_TOKEN有效的话，执行npm whoami命令，会收到响应。但很可惜，没有任何响应。另外，有一些文章说 .npmrc格式中的NPM_TOKEN是加密串。
测试第二天-工作到家将近晚上8点了，我又继续测试这个NPM_TOKEN。我想到在年初我读了一些跨站WebSocket劫持(CSWH)的文章，Cross Site Websocket Hijacking，所以我结合其进行了一些分析。CSWH利用的条件是，websocket只使用cookie进行通信交流，这有点像跨站请求伪造（CSRF）攻击。在BURP练习中对CSWH也有所涉及：
接着，我想看看能不能在前述获得的JS脚本中发现一些websocket信息，但一无所获。之后，我从中发现了客户端请求时，服务端产生分配的一个nonce值，经测试发现可以用它实现CSRF攻击，就这样在寻找CSWH漏洞的过程中发现了CSRF漏洞。于是我进行了上报，在另外的博文中我会作讲解。
测试第三天-经过两小时的分析，我发现其中一个JS脚本文件有点意思，可以用以下三步操作使其代码规则化。Firefox下的代码规则化：
Chrome下的代码规则化：
该文件将近有17k数量的行数，大多是webpack类代码，经过仔细分析，在其中又发现了一个NPM_TOKEN值：
并且，在其附近还存在一个私有注册链接（private registry link）：

我就想，那这个注册链接会不会是其私有仓库的链接呢，于是，我就加入了发现的NPM_TOKEN值，用下.npmrc方法进行了请求：
registry=https://private_registry_link_here
//private_registry_link_here/:_authToken=auth_token_here
执行npm whoami命令，竟然有了成功响应：srv-npm-registry-ci。
然后，我想列出它的所有NPM包信息，不行。于是，我在其JS文件中的打包信息中发现了一些私有仓库的线索，如以下这个：
因此，我用下述命令对其私有仓库进行了请求：
npm view private_repo
npm get private_repo
响应如下：
使用这种方法，我可以下载一些目标项目的私有仓库，从中发现了一些配置类JS脚本和大量的源代码。开发者在项目中明显未做权限设置。没有做深入测试，我就把漏洞上报了。漏洞在当天就被分类处理了，7天之后，我收到了$8000的奖励。

总结

1、可以从一些JS脚本文件中发现隐藏信息；
2、要学会使用浏览器的开发者工具，它们的功能超乎想像；
3、保持测试工具更新；
4、坚持不懈是关键。

*参考来源：medium，clouds 编译整理，转载请注明来自 FreeBuf.COM 

 

by ·挖洞经验 | ServiceNow错误配置管理实例导致的信息泄露漏洞已关闭评论
本文讲述了作者通过云服务管理公司ServiceNow产品，发现很多ServiceNow企业客户未对其中的知识库服务端设置必要的权限和身份验证措施（Misconfiguration），导致内网信息泄露。作者通过该漏洞收获了将近$30,000的奖励。

背景介绍

ServiceNow是美国一家云计算平台公司，提供软件即服务 (Software as a service)，帮助企业运营管理数字化工作流程。ServiceNow专注于信息技术服务管理 (IT service management)、信息技术运营管理（IT operations management）和信息技术商务管理（IT business management）的服务研究，为企业客户通过各种应用和插件管理项目、团队和客户互动关系。

ServiceNow产品基于根本原因（Root Cause）识别模型提供服务，以帮助用户确定问题，并帮助用户通过自助服务纠正问题。该服务模型ServiceNow产品中显示为具体的任务（tasks）、活动（activities）和流程（processes），各种应用服务由不同的云服务实现分离。

例如，你公司的ServiceNow服务管理实例可由以下链接访问到：

https://yourcompanyname.service-now.com

漏洞所在

首先，我研究的一个模块是ServiceNow的知识库 (Knowledge Base，KB)，ServiceNow的知识管理（Knowledge Management，KM) 应用程序具备知识库的信息共享，其知识库中包含了指导用户进行问题排查和自助任务解决的操作说明书。
用户可以自行创建知识库（KB）以便进行保存分享，创建好一个知识库后，ServiceNow会为其分配一个唯一识别号，如以下界面中的KB00110XX：

当用户打开每个知识库对应的文件时，会执行以下请求调用：

https://company.service-now.com/kb_view_customer.do?sysparm_article=KB00xxxx

漏洞利用

经测试发现，很多部署了ServiceNow的公司企业虽然对ServiceNow服务管理实例设置了Okta或onelogin的身份验证措施，但对上述知识库（KB）服务端根本未设置有必要的权限和身份验证手段。

因此，我结合ServiceNow产品的管理实例，以.service-now为域名枚举对象，针对一些大型企业和组织机构做了探测发现。一旦其中有ServiceNow知识库实例，我就用burp intruder对其知识库唯一识别号（KB001XXXX）后四位进行枚举，再结合burp Grep/Match功能对其中响应的关键字进行匹配，如password, internal, credentials, confidential等。

发现结果

大多数公司泄露的知识库用途超出预期，总体来说比较严重，主要是以下几方面数据信息的泄露：

公司内部流程、标准作业程序SOP、图表、开发计划；
密码、登录内部网站的用户令牌；
包含IP地址的用户请求附件内容；
公司雇员交流过程中泄露的一些客户个人身份信息（PII）。

当然，也有一些公司觉得这不算什么太大的安全风险，但我还是鼓励他们进行修复处理。

漏洞奖励 – $30,000

ServiceNow是一家排名前五的云服务管理提供商，很多大公司都采用了其云管理体系。我花了两天时间，经由H1 & bugcrowd平台和朋友关系对存在上述漏洞的多家公司进行了通报，目前为止已经收获了将近$30,000的奖励，还有一些漏洞报告正在分类中。

这是ServiceNow公司的产品漏洞吗？

不。这只是部署了ServiceNow产品的企业未对其中的知识库服务端设置恰当的访问控制权限，导致一些涉及公司内部的知识库文件曝露在互联网上，究其原因就是企业客户自身的错误配置漏洞。

*参考来源：medium，clouds 编译整理，转载请注明来自 FreeBuf.COM

by ·挖洞经验 | Gsuite邮件发送功能中的SMTP注入漏洞分析已关闭评论
本文讲述了作者通过Gsuite邮件发送功能，可构造后缀为@google.com的任意发件人身份，实现SMTP注入，漏洞获得了谷歌$3133.7的奖励。
Gsuite是谷歌旗下的一款整合协同办公软件，它可以用来管理组织机构内部账户，允许管理员对内部账户进行权限划分、应用程序访问控制、通讯录查看以及邮件头应用等操作。
其中，Gsuite的邮件头应用功能引起了我的兴趣，如今的电子邮件头中包含了一些可以“利用”的SMTP协议信息，它算是一种古老的通信协议了，几乎每个接触互联网的人都会使用到它。这里的“利用”指的是我们可以从中发现一些有用信息，从而做一些尝试性的欺骗测试。谷歌这种大厂其实也难免犯错，这不，我就发现了Gsuite的邮件配置存在漏洞，攻击者可以利用该漏洞伪造谷歌服务器的发送邮件。

SMTP协议背景

本质上来说，如果可以建立连接到某个SMTP服务器的接口，就能按相应步骤向任意邮件地址发送电子邮件了，这里更重要的是，可以以任意发件人身份进行邮件发送。所以，这种情况下会引发一系列的混乱问题，因为作为收件人来说，他邮件内的发件人身份完全是不可信的。
通常，我们可以从以下几条简单的SMTP命令来了解SMTP协议：
1、‘MAIL FROM’: 发件人身份（发件人邮箱地址），再强调一下, 这里可以是任意地址，如[email protected]；
2、‘RCPT TO’: 收件人邮箱地址；
3、‘DATA’: 邮件内容。
就这些，没有cc（转发），没有bcc（私密发送）和subject（主题）等头信息，它们都是后续的内容了。那现在如何来利用呢？我们可以把一些额外的头信息放到上述的邮件内容字段（DATA）里，比如，在DATA的开头部分中加入任意的头信息，只要发件人和收件人可以解析理解都行，按RFC定义来讲，每个头信息都新占一行，头名（header）和值之间以冒号分隔。如以下简单的例子：
SMTP FROM:
[email protected]
SMTP TO:
[email protected]
DATA:
bcc: [email protected]

Send me all your money!!

.

伪造发件人身份

显然，如果上述问题得不到解决，且随着时间的推移，基于SMTP的身份和内容验证措施推出，那么电子邮件就不会是一个很好的交流工具了。在此，我们不展开讨论其安全机制。但是，我们要记住的是，在如今的邮件协议中，验证发件人身份的就仅只是“自称是谁就是谁”的DNS域名验证(DNS domain validation)。所以，如果我拥有‘google.com’网站，就可以设置一个域名服务记录，配置所有的SMTP服务器发自‘google.com’的邮件为安全可信邮件，其它发件都是垃圾邮件。也就是说，如果可以伪造（Spoof）谷歌服务器的发件，那么其可信度也就非常之高了。
 

回到Gsuite

有了上述思路，我们就来测试一下Gsuite的邮件功能。如果你登录admin.google.com，转到Apps -> G Suite -> Settings for Gmail->Advanced settings->Routing下，就能在其中添加进出邮件的“邮件路由设置”规则，其中一个可选项就是为所有邮件配置一条“自定义头”:

基于上述的测试构想，我们可以假设其所谓的“自定义头”是添加到SMTP协议的‘DATA’内容中去的，所以，如果能在其中添加进任意头信息，那么也就能操控邮件内容了。

然而，实际情况并非如此，Gsuite中的自定义头有一个“X-”前导，因此貌似我们不能完全控制头名称，但是，等等！前面我们说过，按照RFC规则惯例，每个头信息都是新占一行的。如果我们可以插入一个新行作为头名称的下一个部份呢？那么下一行到底是新的头，还是我们可以控制的呢？
然而，经测试证明，这种方法不可行。谷歌不允许在头信息中包含换行符。但是，我又注意到一个地方，那就是在“自定义头”的下方存在一个选项：Prepend custom subject，即为每封邮件添加“自定义主题”的选项。前述我们说过，SMTP中并不包含‘subject’ 这一项，它只是‘DATA’内容中的一个头信息。
为此，来看看这个“自定义主题”能否作为利用点。发送邮件时，打开代理工具，往其中的‘subject’中插入新行 (‘\r\n’)，抓包看流量：
请求出去后，没返回任何错误提示！我立即向我的其它Gmail发送了一封测试邮件，然后从中收到的内容如下：
惊到我了！也就是说我们构造的Payload成功了，其中插入的Payload字符：we\r\nnewlinew\r\nnewlinell，被谷歌邮件服务端解析成了多行了！由于每一个头信息占一行，所以subject之后的Payload：we\r\nnewlinew\r\nnewlinell被推到了后续显示，成为了这里的邮件内容（email body）。这就是一种典型的SMTP注入啊！
接下来，我构造了一个更有意思的Payload，再次对其中的subject设置做了手脚，这一次，我包含进行了邮件发件人的from头信息，即：
再一次成功了！Gmail把它解析成了发件人为[email protected]的邮件：
就这样，我可以伪造任意后缀为@google.com的发件人身份！

漏洞上报和处理进程

2020.1.5    附带Payload报送谷歌
2020.1.13  谷歌接受漏洞
2020.1.15  我发送包含[email protected]的有效POC详细技术信息给谷歌
2020.2.11  谷歌发放赏金$3133.7
 
*参考来源：ehpus，clouds 编译整理，转载请注明来自 FreeBuf.COM

by ·挖洞经验 | Gsuite邮件发送功能中的SMTP注入漏洞分析已关闭评论
本文讲述了作者通过Gsuite邮件发送功能，可构造后缀为@google.com的任意发件人身份，实现SMTP注入，漏洞获得了谷歌$3133.7的奖励。
Gsuite是谷歌旗下的一款整合协同办公软件，它可以用来管理组织机构内部账户，允许管理员对内部账户进行权限划分、应用程序访问控制、通讯录查看以及邮件头应用等操作。
其中，Gsuite的邮件头应用功能引起了我的兴趣，如今的电子邮件头中包含了一些可以“利用”的SMTP协议信息，它算是一种古老的通信协议了，几乎每个接触互联网的人都会使用到它。这里的“利用”指的是我们可以从中发现一些有用信息，从而做一些尝试性的欺骗测试。谷歌这种大厂其实也难免犯错，这不，我就发现了Gsuite的邮件配置存在漏洞，攻击者可以利用该漏洞伪造谷歌服务器的发送邮件。

SMTP协议背景

本质上来说，如果可以建立连接到某个SMTP服务器的接口，就能按相应步骤向任意邮件地址发送电子邮件了，这里更重要的是，可以以任意发件人身份进行邮件发送。所以，这种情况下会引发一系列的混乱问题，因为作为收件人来说，他邮件内的发件人身份完全是不可信的。
通常，我们可以从以下几条简单的SMTP命令来了解SMTP协议：
1、‘MAIL FROM’: 发件人身份（发件人邮箱地址），再强调一下, 这里可以是任意地址，如[email protected]；
2、‘RCPT TO’: 收件人邮箱地址；
3、‘DATA’: 邮件内容。
就这些，没有cc（转发），没有bcc（私密发送）和subject（主题）等头信息，它们都是后续的内容了。那现在如何来利用呢？我们可以把一些额外的头信息放到上述的邮件内容字段（DATA）里，比如，在DATA的开头部分中加入任意的头信息，只要发件人和收件人可以解析理解都行，按RFC定义来讲，每个头信息都新占一行，头名（header）和值之间以冒号分隔。如以下简单的例子：
SMTP FROM:
[email protected]
SMTP TO:
[email protected]
DATA:
bcc: [email protected]

Send me all your money!!

.

伪造发件人身份

显然，如果上述问题得不到解决，且随着时间的推移，基于SMTP的身份和内容验证措施推出，那么电子邮件就不会是一个很好的交流工具了。在此，我们不展开讨论其安全机制。但是，我们要记住的是，在如今的邮件协议中，验证发件人身份的就仅只是“自称是谁就是谁”的DNS域名验证(DNS domain validation)。所以，如果我拥有‘google.com’网站，就可以设置一个域名服务记录，配置所有的SMTP服务器发自‘google.com’的邮件为安全可信邮件，其它发件都是垃圾邮件。也就是说，如果可以伪造（Spoof）谷歌服务器的发件，那么其可信度也就非常之高了。
 

回到Gsuite

有了上述思路，我们就来测试一下Gsuite的邮件功能。如果你登录admin.google.com，转到Apps -> G Suite -> Settings for Gmail->Advanced settings->Routing下，就能在其中添加进出邮件的“邮件路由设置”规则，其中一个可选项就是为所有邮件配置一条“自定义头”:

基于上述的测试构想，我们可以假设其所谓的“自定义头”是添加到SMTP协议的‘DATA’内容中去的，所以，如果能在其中添加进任意头信息，那么也就能操控邮件内容了。

然而，实际情况并非如此，Gsuite中的自定义头有一个“X-”前导，因此貌似我们不能完全控制头名称，但是，等等！前面我们说过，按照RFC规则惯例，每个头信息都是新占一行的。如果我们可以插入一个新行作为头名称的下一个部份呢？那么下一行到底是新的头，还是我们可以控制的呢？
然而，经测试证明，这种方法不可行。谷歌不允许在头信息中包含换行符。但是，我又注意到一个地方，那就是在“自定义头”的下方存在一个选项：Prepend custom subject，即为每封邮件添加“自定义主题”的选项。前述我们说过，SMTP中并不包含‘subject’ 这一项，它只是‘DATA’内容中的一个头信息。
为此，来看看这个“自定义主题”能否作为利用点。发送邮件时，打开代理工具，往其中的‘subject’中插入新行 (‘\r\n’)，抓包看流量：
请求出去后，没返回任何错误提示！我立即向我的其它Gmail发送了一封测试邮件，然后从中收到的内容如下：
惊到我了！也就是说我们构造的Payload成功了，其中插入的Payload字符：we\r\nnewlinew\r\nnewlinell，被谷歌邮件服务端解析成了多行了！由于每一个头信息占一行，所以subject之后的Payload：we\r\nnewlinew\r\nnewlinell被推到了后续显示，成为了这里的邮件内容（email body）。这就是一种典型的SMTP注入啊！
接下来，我构造了一个更有意思的Payload，再次对其中的subject设置做了手脚，这一次，我包含进行了邮件发件人的from头信息，即：
再一次成功了！Gmail把它解析成了发件人为[email protected]的邮件：
就这样，我可以伪造任意后缀为@google.com的发件人身份！

漏洞上报和处理进程

2020.1.5    附带Payload报送谷歌
2020.1.13  谷歌接受漏洞
2020.1.15  我发送包含[email protected]的有效POC详细技术信息给谷歌
2020.2.11  谷歌发放赏金$3133.7
 
*参考来源：ehpus，clouds 编译整理，转载请注明来自 FreeBuf.COM

by ·挖洞经验 | Gsuite邮件发送功能中的SMTP注入漏洞已关闭评论
本文讲述了作者通过Gsuite邮件发送功能，可构造后缀为@google.com的任意发件人身份，实现SMTP注入，漏洞获得了谷歌$3133.7的奖励。
Gsuite是谷歌旗下的一款整合协同办公软件，它可以用来管理组织机构内部账户，允许管理员对内部账户进行权限划分、应用程序访问控制、通讯录查看以及邮件头应用等操作。
其中，Gsuite的邮件头应用功能引起了我的兴趣，如今的电子邮件头中包含了一些可以“利用”的SMTP协议信息，它算是一种古老的通信协议了，几乎每个接触互联网的人都会使用到它。这里的“利用”指的是我们可以从中发现一些有用信息，从而做一些尝试性的欺骗测试。谷歌这种大厂其实也难免犯错，这不，我就发现了Gsuite的邮件配置存在漏洞，攻击者可以利用该漏洞伪造谷歌服务器的发送邮件。

SMTP协议背景

本质上来说，如果可以建立连接到某个SMTP服务器的接口，就能按相应步骤向任意邮件地址发送电子邮件了，这里更重要的是，可以以任意发件人身份进行邮件发送。所以，这种情况下会引发一系列的混乱问题，因为作为收件人来说，他邮件内的发件人身份完全是不可信的。
通常，我们可以从以下几条简单的SMTP命令来了解SMTP协议：
1、‘MAIL FROM’: 发件人身份（发件人邮箱地址），再强调一下, 这里可以是任意地址，如[email protected]；
2、‘RCPT TO’: 收件人邮箱地址；
3、‘DATA’: 邮件内容。
就这些，没有cc（转发），没有bcc（私密发送）和subject（主题）等头信息，它们都是后续的内容了。那现在如何来利用呢？我们可以把一些额外的头信息放到上述的邮件内容字段（DATA）里，比如，在DATA的开头部分中加入任意的头信息，只要发件人和收件人可以解析理解都行，按RFC定义来讲，每个头信息都新占一行，头名（header）和值之间以冒号分隔。如以下简单的例子：
SMTP FROM:
[email protected]
SMTP TO:
[email protected]om
DATA:
bcc: [email protected]

Send me all your money!!

.

伪造发件人身份

显然，如果上述问题得不到解决，且随着时间的推移，基于SMTP的身份和内容验证措施推出，那么电子邮件就不会是一个很好的交流工具了。在此，我们不展开讨论其安全机制。但是，我们要记住的是，在如今的邮件协议中，验证发件人身份的就仅只是“自称是谁就是谁”的DNS域名验证(DNS domain validation)。所以，如果我拥有‘google.com’网站，就可以设置一个域名服务记录，配置所有的SMTP服务器发自‘google.com’的邮件为安全可信邮件，其它发件都是垃圾邮件。也就是说，如果可以伪造（Spoof）谷歌服务器的发件，那么其可信度也就非常之高了。
 

回到Gsuite

有了上述思路，我们就来测试一下Gsuite的邮件功能。如果你登录admin.google.com，转到Apps -> G Suite -> Settings for Gmail->Advanced settings->Routing下，就能在其中添加进出邮件的“邮件路由设置”规则，其中一个可选项就是为所有邮件配置一条“自定义头”:

基于上述的测试构想，我们可以假设其所谓的“自定义头”是添加到SMTP协议的‘DATA’内容中去的，所以，如果能在其中添加进任意头信息，那么也就能操控邮件内容了。

然而，实际情况并非如此，Gsuite中的自定义头有一个“X-”前导，因此貌似我们不能完全控制头名称，但是，等等！前面我们说过，按照RFC规则惯例，每个头信息都是新占一行的。如果我们可以插入一个新行作为头名称的下一个部份呢？那么下一行到底是新的头，还是我们可以控制的呢？
然而，经测试证明，这种方法不可行。谷歌不允许在头信息中包含换行符。但是，我又注意到一个地方，那就是在“自定义头”的下方存在一个选项：Prepend custom subject，即为每封邮件添加“自定义主题”的选项。前述我们说过，SMTP中并不包含‘subject’ 这一项，它只是‘DATA’内容中的一个头信息。
为此，来看看这个“自定义主题”能否作为利用点。发送邮件时，打开代理工具，往其中的‘subject’中插入新行 (‘\r\n’)，抓包看流量：
请求出去后，没返回任何错误提示！我立即向我的其它Gmail发送了一封测试邮件，然后从中收到的内容如下：
惊到我了！也就是说我们构造的Payload成功了，其中插入的Payload字符：we\r\nnewlinew\r\nnewlinell，被谷歌邮件服务端解析成了多行了！由于每一个头信息占一行，所以subject之后的Payload：we\r\nnewlinew\r\nnewlinell被推到了后续显示，成为了这里的邮件内容（email body）。这就是一种典型的SMTP注入啊！
接下来，我构造了一个更有意思的Payload，再次对其中的subject设置做了手脚，这一次，我包含进行了邮件发件人的from头信息，即：
再一次成功了！Gmail把它解析成了发件人为[email protected]的邮件：
就这样，我可以伪造任意后缀为@google.com的发件人身份！

漏洞上报和处理进程

2020.1.5    附带Payload报送谷歌
2020.1.13  谷歌接受漏洞
2020.1.15  我发送包含[email protected]的有效POC详细技术信息给谷歌
2020.2.11  谷歌发放赏金$3133.7
 
*参考来源：ehpus，clouds 编译整理，转载请注明来自 FreeBuf.COM

by ·挖洞经验 | Gsuite邮件发送功能中的SMTP注入漏洞已关闭评论
本文讲述了作者通过Gsuite邮件发送功能，可构造后缀为@google.com的任意发件人身份，实现SMTP注入，漏洞获得了谷歌$3133.7的奖励。
Gsuite是谷歌旗下的一款整合协同办公软件，它可以用来管理组织机构内部账户，允许管理员对内部账户进行权限划分、应用程序访问控制、通讯录查看以及邮件头应用等操作。
其中，Gsuite的邮件头应用功能引起了我的兴趣，如今的电子邮件头中包含了一些可以“利用”的SMTP协议信息，它算是一种古老的通信协议了，几乎每个接触互联网的人都会使用到它。这里的“利用”指的是我们可以从中发现一些有用信息，从而做一些尝试性的欺骗测试。谷歌这种大厂其实也难免犯错，这不，我就发现了Gsuite的邮件配置存在漏洞，攻击者可以利用该漏洞伪造谷歌服务器的发送邮件。

SMTP协议背景

本质上来说，如果可以建立连接到某个SMTP服务器的接口，就能按相应步骤向任意邮件地址发送电子邮件了，这里更重要的是，可以以任意发件人身份进行邮件发送。所以，这种情况下会引发一系列的混乱问题，因为作为收件人来说，他邮件内的发件人身份完全是不可信的。
通常，我们可以从以下几条简单的SMTP命令来了解SMTP协议：
1、‘MAIL FROM’: 发件人身份（发件人邮箱地址），再强调一下, 这里可以是任意地址，如[email protected]；
2、‘RCPT TO’: 收件人邮箱地址；
3、‘DATA’: 邮件内容。
就这些，没有cc（转发），没有bcc（私密发送）和subject（主题）等头信息，它们都是后续的内容了。那现在如何来利用呢？我们可以把一些额外的头信息放到上述的邮件内容字段（DATA）里，比如，在DATA的开头部分中加入任意的头信息，只要发件人和收件人可以解析理解都行，按RFC定义来讲，每个头信息都新占一行，头名（header）和值之间以冒号分隔。如以下简单的例子：
SMTP FROM:
[email protected]
SMTP TO:
[email protected]
DATA:
bcc: [email protected]

Send me all your money!!

.

伪造发件人身份

显然，如果上述问题得不到解决，且随着时间的推移，基于SMTP的身份和内容验证措施推出，那么电子邮件就不会是一个很好的交流工具了。在此，我们不展开讨论其安全机制。但是，我们要记住的是，在如今的邮件协议中，验证发件人身份的就仅只是“自称是谁就是谁”的DNS域名验证(DNS domain validation)。所以，如果我拥有‘google.com’网站，就可以设置一个域名服务记录，配置所有的SMTP服务器发自‘google.com’的邮件为安全可信邮件，其它发件都是垃圾邮件。也就是说，如果可以伪造（Spoof）谷歌服务器的发件，那么其可信度也就非常之高了。
 

回到Gsuite

有了上述思路，我们就来测试一下Gsuite的邮件功能。如果你登录admin.google.com，转到Apps -> G Suite -> Settings for Gmail->Advanced settings->Routing下，就能在其中添加进出邮件的“邮件路由设置”规则，其中一个可选项就是为所有邮件配置一条“自定义头”:

基于上述的测试构想，我们可以假设其所谓的“自定义头”是添加到SMTP协议的‘DATA’内容中去的，所以，如果能在其中添加进任意头信息，那么也就能操控邮件内容了。

然而，实际情况并非如此，Gsuite中的自定义头有一个“X-”前导，因此貌似我们不能完全控制头名称，但是，等等！前面我们说过，按照RFC规则惯例，每个头信息都是新占一行的。如果我们可以插入一个新行作为头名称的下一个部份呢？那么下一行到底是新的头，还是我们可以控制的呢？
然而，经测试证明，这种方法不可行。谷歌不允许在头信息中包含换行符。但是，我又注意到一个地方，那就是在“自定义头”的下方存在一个选项：Prepend custom subject，即为每封邮件添加“自定义主题”的选项。前述我们说过，SMTP中并不包含‘subject’ 这一项，它只是‘DATA’内容中的一个头信息。
为此，来看看这个“自定义主题”能否作为利用点。发送邮件时，打开代理工具，往其中的‘subject’中插入新行 (‘\r\n’)，抓包看流量：
请求出去后，没返回任何错误提示！我立即向我的其它Gmail发送了一封测试邮件，然后从中收到的内容如下：
惊到我了！也就是说我们构造的Payload成功了，其中插入的Payload字符：we\r\nnewlinew\r\nnewlinell，被谷歌邮件服务端解析成了多行了！由于每一个头信息占一行，所以subject之后的Payload：we\r\nnewlinew\r\nnewlinell被推到了后续显示，成为了这里的邮件内容（email body）。这就是一种典型的SMTP注入啊！
接下来，我构造了一个更有意思的Payload，再次对其中的subject设置做了手脚，这一次，我包含进行了邮件发件人的from头信息，即：
再一次成功了！Gmail把它解析成了发件人为[email protected]的邮件：
就这样，我可以伪造任意后缀为@google.com的发件人身份！

漏洞上报和处理进程

2020.1.5    附带Payload报送谷歌
2020.1.13  谷歌接受漏洞
2020.1.15  我发送包含[email protected]的有效POC详细技术信息给谷歌
2020.2.11  谷歌发放赏金$3133.7
 
*参考来源：ehpus，clouds 编译整理，转载请注明来自 FreeBuf.COM

by ·挖洞经验 | 篡改密码重置的加密参数实现账号劫持已关闭评论

Account_Takeover_Knowledge_base.jpg

想必大家都对参数篡改攻击有所了解，今天作者分享的是对RSA加密参数的篡改从而实现账号劫持的简单测试，漏洞原因在于Web应用在客户端缺乏安全的防护机制。一起来看看。

出于保密，目标Web应用暂且叫它为target.com，在接触该目标时，经测试发现，其上所有的参数操作都是加密传输的，在Burp的抓包配合下，可见其大概的加密形式如下：

userName=8cfe39943d6e08e505531ddfd90c66f47c2f55ce140e5770fef58d3bec826f52490a089d1942aaed74a9f6ed0fd8890cef6c36e31220c9859a3ab423062wxbeea480d94850d95374ab3a7a47de3e9f89b3250a58397044817069c6a17109cc27408b0c53f94q34a5878270ff6random8c96b916bb9594af648e6dc6851685a9d41cdb868761c4d36d49389150840af05a277530dd191464befc79a46d418a4e4f12b2dec0c5cc01097efed4b2a6608c2c2f076a27fe0ce62a70a4fe2f02b558abae6f4a4757fb34a593ccd04f2356c2c521758b0e59c017087121d63c1b002fc794953e690290489f8af87d17359ba0fc59b832f972d80293fe8d2aafcb4faca

接下来，我把关注点放到了其“忘记密码”功能上，其大概流程如下：

1、访问target.com/signin页面，输入需要重置密码的邮箱号；

2、Web服务端会向邮箱发送一个6位数授权码；

3、访问target.com/forgotPasswd，输入需要重置密码的邮箱号、授权码和重置后的密码，提交即可完成密码重置操作。

现在，我以邮箱“[email protected]”向Web服务端发起密码重置请求，在收到授权码之后，访问target.com/forgotPasswd，重复上述密码重置操作，该过程用Burp抓包的数据如下：

1_1asM7G226C3noJURinTROg.png

从上图中可以看到，其中包含4个参数：Email, Username, Encrypted Password 和 Code，但是所有这些参数都是加密的。我尝试着把参数数值替换成明文数值，如用“[email protected]” 或“[email protected]”替换掉其中的邮箱，但提交的请求却不成功。

接着，我用另外的浏览器访问target.com/forgotpasswd，以“[email protected]”身份发起密码重置请求，抓包，复制其中的email 和 username加密数值，到之前的浏览器请求包中，提交，但请求还是无效。

因此，总结来看，忘记密码的请求格式如下：

email=encryptedattackeremail&userName=encryptedattackerusername&passwd=encryptedattackerpasswd&code=encryptedcode

我度过把其中的encryptedattackeremail替换为encryptedvictimemail，encryptedattackerusername替换为encryptedvictimusername，但都不可行。

我依然没有气馁。经过一番分析，根据加密长度，我发现其加密方式为RSA。同时，我对目标Web应用的源代码分析后发现，其中多个js脚本中包含了rsa方法名称，因此，我确信其为RSA加密无疑了。

后来我意识到Burp抓包时参数值已经被加密了，这是一种客户端加密，所以我尝试把浏览器中调用的js脚本执行关闭，看看加密功能是否还可行，但之后，密码重置请求就完全不起效。

我又考虑到，由于这是客户端加密，RSA函数肯定是在某个js脚本中被定义，且被浏览器调用的，于是我点击Chrome浏览器的Inspect Element按钮，来到了其Console一栏下，输入“rsa” ，让我吃惊的是其中匹配出了“rsaEncrypt”方法函数名。

1_okgC2FhWjYJYu5bILd0JCQ.png

经过测试发现，只要为该方法函数提供一个参数名，其就能生成相应的加密数值，因此，我以参数s定义了数值“[email protected]”，即s=“[email protected]“，执行rsaEncrypt，它即生成了如下相应的加密串：

1_5TBd_uTCrBcYCB_8_R2fjQ.png

需要注意的是，可能是其与会话参数相关，所以在端点/forgotpasswd上每次刷新页面，上述的加密串都会发生变化。

按照前述的密码重置操作，我以“[email protected]”身份发起密码重置请求，提交授权码和新密码，并进行Burp抓包，其相应界面如下：

1_OROqZKQ6EE08-KTHfqpq7Q.png

在Burp的请求包中，除了 把其中的“username”替换成浏览器端rsaEncrypt方法生成的“rsaencryptedvictimemail”加密串之外，其它的都无需更改，也即：

email=encryptedattackeremail&username=rsaencryptedvictimemail&passwd=encryptedattackerpasswd&code=encryptedcode

请求提交后，奇迹发生了，[email protected]对应的账号密码被成功更改，实现了账户劫持！

参考来源

medium

*本文作者：clouds ，转载请注明来自 FreeBuf.COM

by ·挖洞经验 | 利用系列视频创建功能删除任意Facebook平台图片（$10,000）已关闭评论

近期，作者注意到了Facebook的创作工作室（Facebook Creator Studio）中添加了系列视频创建功能（Series Feature），出于对漏洞测试的敏感性，作者及时对该功能进行了测试，最终发现该功能中存在任意Facebook图片删除漏洞，漏洞获得了Facebook官方$10,000的奖励。

漏洞发现过程

Facebook的创作工作室（Facebook Creator Studio）汇集了用户所需的各种工具，让用户能够跨所有 Facebook 主页和 Instagram 帐户发布内容、实现变现、衡量表现并与粉丝互动。系列视频创建是在 Facebook 内容分享中比较吸引人的方式，用户可以从个人上传内容中通过视频组合形成专辑影片，发布后供朋友圈和其他用户观看。

如下系列视频创建过程：

在创建系列视频的过程中，要求上传图片作为其宣传海报（”Poster Art”）和影片封面（”Cover Image” ），如下：

在上传图片的请求中，我发现其中包含了图片的id号（fbid），意思是只要是Facebook平台中任何具备id号（fbid）的图片都能把它填写于此作为封面图片，如下选择其他用户账户下的任一fbid图片（2467651590213206）作为封面：

图片上传请求中原来的图片id（2903739103044967）：

替换为新的图片id（2467651590213206）作为封面：

替换成功后，我再选择删除该系列视频集的操作，如下：

删除成功：

此时，原来作为封面的其他用户账户下的图片（2467651590213206）也即被删除，不可访问：

及时上报给Facebook后，Facebook安全团队及时给出了反馈：

漏洞上报和处理进程

2020.5.2 09:10 – 漏洞初报

2020.5.2 10:39 – 漏洞分类

2020.5.2 22:46 – 漏洞修复

2020.6.2 – $10,000赏金发放

*参考来源：darabi，clouds 编译整理，转载请注明来自 FreeBuf.COM