码农发现大通UR点数漏洞,上报被杀全家

看到一篇关于2016年 UR 点数漏洞,因为作者怕被大通报复才在今天发布细节。大概就是卡之间互相转分,在网络不稳定的状况下导致系统双倍积分转移。就这样来回一直转,达到一张卡数百万 UR 点数,另一张卡负百万点数。按照大通玩法,关卡后点数都直接清零,作者猜测负分也会如此。之后更是尝试兑换现金到支票账户,直接入账。

经过一系列骚操作,作者想联系大通却找不到任何漏洞举报途径。最后通过Twitter上报然后被大通杀全家。

https://chadscira.com/post/5fa269d46142ac544e013d6e/DISCLOSURE-Unlimited-Chase-Ultimate-Rewards-Points

1赞

从这个人自己的描述看,JPMC似乎有些不厚道;但是另一方面,他确确实实把UR提现了-对chase来说是不是可以认为你是赚了chase的大便宜然后还来“要挟”chase呢?
我猜想po主隐藏了一部分内容,比如说chase是不是跟他商量过把UR点数还有兑现的cash还回来?如果真的如他所说的这么不仁不义,那他应该去投诉chase而不是在网上诉苦。

Chase的IT居然也有这种级别的漏洞:joy:

1赞

最后提现是漏洞的最终证实部分,如果不能提现成功,则漏洞的实际影响较小。
从OP的叙事看,chase没有沟通过是否把UR兑回去,甚至OP主动找到了chase之后,chase仍然没有合理回应。

1赞

数据写入都不再次握手确认的吗?ATM这样玩大家都发财了。

好想 试试,可惜实力不允许啊

1赞

从数据库的角度,transaction的atomicity没有问题,是上层应用的retry逻辑不对,也是典型的数据库应用的bug之一了 233

允许点数为负?数据库设计没问题?

我的也变成负的过。转点之后有退货。

好奇如果最后漏洞没补上一直cash out把七万块全都cashout出来了会怎么算

点数为负必须得有啊,要不然怎么claw back?没有设计负数才是重大bug才对。

怎不把七萬分次領完再通報呢

老金融vampire了chase,走过路过甚至帮过chase的都要被chase吸一口

2赞

感觉跟我薅另外某司有点类似,当然收益跟这个没法比。。。顶天几个小钱
不过我就是没那么好心去告诉人家了。。

这个人是白帽黑客,如果愿意汇报bug给厂家的话肯定都保证了自己不出格的,要不然太危险了,如果自己的操作有瑕疵的话我感觉是不会去说的。文章也提到了他一定要等到chase给他permission之后他才真的开始实验(虽然最后没有honor)

白帽黑客本来就是很吃力不讨好的,就是因为有太多像chase这样不负责任的厂商了。在国内的话他甚至有坐牢的风险。

3赞

为什么退货会弄成负点数?

这个只有connection不好才会发生,说明retry是从client来的,而retry的时候没有用新的balance来检测。看来检测balance够不够的逻辑是写在了client上?那岂不是改个limit可以转无限多的点了。。。

首先这个bug现在chase肯定已经fix了…从文中看来,还不能说明balance检测逻辑一定在client上,有可能是一次性的检测balance之后得到一个token,但是retry可以重复使用这个token之类。如果是这样的话,发起的时候还是只能用点数上限。不过也没差啦,按文中的搞法,控制好自己的网络,随便翻几番

退货前点数已经全转出去了,退货会扣回点数。

谢谢指教!感觉干这个还真的是有点吃力不讨好。。。