【技术分享】看我如何利用他人的账号来发推文

http://p1.qhimg.com/t01f342baec76976ae7.jpg

翻译:WisFree

预估稿费:160RMB

投稿方式:发送邮件至linwei#360.cn,或登陆网页版在线投稿


写在前面的话

近期,我在对社交网络Twitter进行漏洞挖掘(遵循Twitter的漏洞奖励计划)的过程中,发现了一个允许攻击者冒充推特用户发送推文的漏洞,而且攻击者在整个过程中根本不需要访问目标用户的推特账号。

注:这个漏洞在2017年2月26日被发现,并在2017年2月28日得到修复。

漏洞报告参考资料:【点我获取

接下来,让我们一起看一看这个漏洞的技术细节。


介绍

这是推特网络中的其中一项服务,地址为https://ads.twitter.com/ 。这是一个多媒体库,用户一般会在发布推文的时候使用到这个功能。它不仅允许用户上传多媒体文件(视频、图片或GIF动态图像),而且用户还可以查看之前上传的多媒体文件。访问链接如下:

https://ads.twitter.com/accounts/*id_of_your_account*/media

现在,让我们开始分析。


技术分析

如果我们在浏览器中访问这个库,我们将能够直接看到“上传多媒体文件”这个功能:

https://p5.ssl.qhimg.com/t012724621149f3e76e.png

按下“Download media-file”按钮之后,我们要选择一个需要操作的文件,界面如下图所示:

https://p3.ssl.qhimg.com/t010e5910172db1da50.png

点击上传图片按钮之后,界面如下:

https://p2.ssl.qhimg.com/t01485356bba7d698f2.png

现在,我们将能够做到以下两件事情:

1. 我们可以发布自己的多媒体文件;

2. 我们可以与任何一位用户共享多媒体文件;

好的,那么接下来让我们好好分析一下推特提供的这个功能:

https://p0.ssl.qhimg.com/t015fb4e2874471ba4a.png

我们从中可以了解到以下几点信息:

account_id:也就是用户的账号ID

owner_id:图像所有者的ID

user_id:推文会发送给用户,这个就是该用户的ID

media_key:需要发布的多媒体文件ID

下面是我在测试过程中需要使用到的标记:

账号No1:我的第一个账号

账号No2:我的第二个账号

由于我不记得系统输出的错误语句是什么了,所以我在这里将这些错误信息称为:;《错误No1》和《错误No2》。


测试

下面给大家介绍我的漏洞测试步骤:

首先,我拦截了系统的推文发送请求,然后对参数owner_id和user_id进行了修改。这个请求原本是采用POST方法发送的,我将其修改为了GET请求,数据采用json进行封装,然后将账号No1的ID改成了账号No2的ID,但我这一次并没有得到期望的结果,而是收到了系统返回的错误No1。

接下来,我打算只修改owner_id和user_id(POST请求),而这一次我又收到了系统返回的错误No2,我所记得的错误内容大致如下:《owner_id所对应的用户并非这个多媒体文件的真实所有者,这里应该是一个media_key*id被替换*》

于是,接下来我打算做下面这件事情:

我用账号No2登录了ads.twitter.com,进入多媒体库,然后上传我们已经提前知道media_key的图片。

现在让我们一起回到账号No1:

接下来,我们拦截推文的发送请求,然后修改GET方法和POST方法中的参数owner_id和user_id,将信息修改为账号No2的相应数据以及多媒体密钥media_key,media_key是我们之前在上传图片时已经知晓的。但这一次我们得到的结果还是错误No1,这就非常不幸了。但是,当我们在此之前修改了GET和POST方法中的owner_id和user_id参数之后,系统只返回了错误No1。如果只将POST请求中的owner_id和user_id参数进行替换的话,我们就得到了错误No2。

接下来,我们只修改POST方法中的owner_id、user_id以及media_key,然后我们就可以看到系统提示我们推文发布成功了!切换到账号No2之后,我们可以看到那个之前上传于账号No2的图片已经被我们成功发布了,但我们要知道,所有的这些操作可都不是我们通过账号No2所进行的。


让来我们试试更难的

好的,现在我们已经可以伪造他人的用户身份来发布推文了,但现在的限制因素较多,而这些限制条件将会降低这个漏洞的严重性。根据上文所述,用来发布推文的用户必须提前上传一个多媒体文件,而且攻击者还必须知道这个文件所对应的media_key,但使用暴力破解这样的方法几乎是不可能获取到这个多媒体密钥的。

虽然现在有各种各样的限制,但我个人认为,这个漏洞很有可能会带来非常严重的影响。由于我们可以共享其他用户所上传的多媒体文件,因此我脑海中突然产生了一个非常有意思的想法,如果我们与其他用户共享了我们的多媒体文件,然后再利用这名用户的账号发布推文的话,那么这名用户将会被视作这个多媒体文件的拥有者,此时系统就不会返回错误No2了,而推文也可以成功发布了。

为了成功利用这个漏洞,我们需要得到多媒体文件的media_key,那么如果这个文件的拥有者是我们自己的话,那media_key就不再是我们的问题了。

攻击场景如下:

1. 上传我们自己的多媒体文件;

2. 将该文件与目标用户共享,这个账号就是我们接下来要用来发布推文的账号;

3. 拦截推文的发送请求,将POST方法中的owner_id和user_id修改为目标账号相对应的数据。

4. 收到系统返回的通知,提示推文发送成功;

5. 好好享受这个漏洞吧!

(完)