译文翻译申明文中是翻译文章,文章内容著作人alex

译文翻译申明文中是翻译文章,文章内容著作人alex

黑客资讯hacker2020-08-27 8:08:209754A+A-

 

在找寻网络安全问题时,对不明财产和隐敝网站的收集一般 最后会令人贪小失大。

假如您对一个总体目标开展安全性测试,如同第一次对它实行安全风险评估一样细腻,完全查验全部內容,那麼相信您一定会寻找新的物品:尤其是假如要检测的编码早已不断开发设计了一段时间。

这是一个有关高风险系统漏洞的小故事,该系统漏洞会危害PayPal浏览量较大的网页页面之一:登陆表格。(最终被奖赏了$15300美元)

 

基本发觉

在访问 PayPal的关键身份认证步骤时,我注意到一个javascript文档,在其中好像包括了一个CSRF动态口令和对话ID的內容:

这马上造成了我的留意,由于在一个合理的javascript文档中出示一切种类的对话数据信息得话,一般 都给网络攻击可趁之机。

在说白了的跨网站脚本制作包括(XSSI)进攻中,故意网页页面能够 应用HTML <script>标识导进跨域脚本制作,进而使其可以浏览文档中包括的一切数据信息。

果真,我迅速就检测确定了该XSSI系统漏洞,虽然它应用了JavaScript混淆器来随机化每一个要求的用户标识符,但趣味的是,动态口令仍被置放在十分非常容易搜索的部位,一下子就被找到。

殊不知,水可载舟亦可覆舟,需看该信息内容怎样运用了。我马上下手找到_csrfh和_sessionID的准确含意,及其他们是不是能够 真实用以具体进攻中。

 

进一步发掘

我试着将PayPal服务平台上已受权要求中的基本CSRF动态口令更换为_csrf的值,历经一次次的试着后,我得到的结果是,应用此特殊动态口令没法开展經典的跨网站要求仿冒进攻。一样,_sessionID也不好。

接下去,我回到该系统漏洞脚本制作,查询该动态口令的的具体主要用途,最终对PayPal用于避免 暴力行为进攻(安全性挑戰)的一个关键维护体制开展了深入分析。尽管此体制已被普遍应用,但我将关键详细介绍此登陆表格。

这一念头非常简单:几回试着登录失败后,您必须先处理reCAPTCHA挑戰,随后才可以再试。可是,这一挑戰就很有赚头了。

它的体制是那样的:在检验到很有可能的暴力破解密码试着后,下一次身份认证试着的回应将是一个网页页面,在其中仅包括Google短信验证码。假如客户根据了短信验证码检测,会向/auth/validatecaptcha进行一个HTTP POST要求。

在要求行为主体中又看到了_csrf_sessionID了解的影子,行为主体中也有别的2个值,稍候会详细介绍。

对短信验证码要求的回应致力于将客户再次引进身份认证步骤。因此,它包括一个自身递交的表格,在其中包括客户全新登陆要求出示的全部数据信息,包含她们的电子邮箱和纯文字登陆密码。

我意识到,根据恰当的时钟频率和一些客户互动,要是了解此要求中应用的全部动态口令,就得以获得受害人的PayPal凭证。在具体进攻情景中,唯一必须的客户互动便是浏览一下网络攻击操纵的网页页面。

因而,我转过头来试着找到缺乏的主要参数。这比预估的非常容易:

  1. jse的值彻底没经认证。
  2. recaptcha是Google在处理reCAPTCHA挑戰时出示的动态口令。它仍未关联到特殊的对话中,因而一切合理的动态口令都能够被接纳(比如,来源于全自动求出服务项目的动态口令)。

 

Exploitation

总的来说,我建立了一个全部全过程的POC(除开集成化短信验证码解决方法服务项目外)。

最先,POC将运用最开始的XSSI系统漏洞来获得一组在受害人对话中合理的动态口令。随后,受害者的电脑浏览器传出含有任意凭证的一些身份认证要求,仿真模拟试着暴力破解密码,这一全过程将开启安全性挑戰步骤。

一旦受害人应用同样的浏览器登录PayPal,缓存文件的任意凭据将被客户自身的电子邮箱和登陆密码更换。最后一步是获得一个新的reCAPTCHA动态口令,自此,纯文字凭证会根据服务端的要求被发送至/auth/validatecaptcha网页页面,并显示信息在网页页面上。

被马塞克掉的便是客户的电子邮箱和弱密码

被马塞克掉的便是客户的电子邮箱和弱密码

之后我发现了,在一些没经身份认证的结账网页页面上也应用了同样的系统漏洞认证,进而容许应用同样的技术性泄露纯文字透支卡数据信息。

 

续篇

POC及其基本信息已于今年11月18日递交到PayPal的系统漏洞悬赏金方案,18天后HackerOne也根据了认证。

在paypal精英团队快速确定并明确提出一些别的难题以后,我于十二月10日得到了15300美元的奖励金。奖赏额度相匹配于bug的8.0级(高)CVSS成绩,这与我还在递交汇报时最开始提议的成绩同样。

 

修补和防止提议

/auth/validatecaptcha网页页面加上一个附加的CSRF动态口令,该动态口令没法被跨网站脚本制作包括泄漏。

虽然之上能够 恰当修补系统漏洞,但创作者觉得,依照最历史悠久、最重要的网络信息安全提议中的一项,在设计方案系统软件时就可以防止该类系统漏洞,那便是:始终不必以纯文字方式储存登陆密码。

点击这里复制本文地址 以上内容由黑资讯整理呈现,请务必在转载分享时注明本文地址!如对内容有疑问,请联系我们,谢谢!
  • 4条评论
  • 瑰颈闻呓2022-05-28 10:48:44
  • al服务平台上已受权要求中的基本CSRF动态口令更换为_csrf的值,历经一次次的试着后,我得到的结果是,应用此特殊动态口令没法开展經典的跨网站要求仿冒进攻。一样,_sessionID也不好。 接下去,我回到该
  • 弦久野の2022-05-28 16:45:42
  • recaptcha是Google在处理reCAPTCHA挑戰时出示的动态口令。它仍未关联到特殊的对话中,因而一切合理的动态口令都能够被接纳(比如,来源于全自动求出服务项目的动态口令)。
  • 边侣海夕2022-05-28 18:17:47
  • 一般 都给网络攻击可趁之机。 在说白了的跨网站脚本制作包括(XSSI)进攻中,故意网页页面能够 应用HTML <script>标识导进跨域脚本制作,进而使其可以浏览文档中包括的一切数据信息。 果真,我迅速就检测确定了该XSSI系统漏洞,虽
  • 孤鱼离祭2022-05-28 16:59:31
  • 在处理reCAPTCHA挑戰时出示的动态口令。它仍未关联到特殊的对话中,因而一切合理的动态口令都能够被接纳(比如,来源于全自动求出服务项目的动态口令)。   Exploitation

支持Ctrl+Enter提交

黑资讯 © All Rights Reserved.  
Copyright Copyright 2015-2020 黑资讯
滇ICP备19002590号-1
Powered by 黑客资讯 Themes by 如有不合适之处联系我们
网站地图| 发展历程| 留言建议| 网站管理