WooYun.org

（PS：纽曼看此文前请把这个大漏洞给修了，否则这个洞修了等于没修： WooYun: 纽曼手机官网注入可致秒杀插队（或用户地址泄露） ）
===========================
问题根源：www.newman.mobi 的纠结业务体系和不当的程序结合
从www.newman.mobi 的摸底情况来看，用户订单和商品管理采用了改动过的ecshop，而秒杀项目“午市”则采取了精简过的phpcms。两者的逻辑通过某些共用的session和缓存等传递。而且还有一个大家可能都想不到的亮点，那就是用了redis作缓存器和k-v存储（其实我很惊叹传统企业敢起用nosql）。
以上架构表明，程序员还是有功底的，做过程序结合的人都深感不易（所以认真建议，不要炒人）。但问题是，过分关注架构，可能会导致程序结合不当，导致马奇诺防线问题的产生——你以为大家都会走设定好的通道，结果人家可以抄另一条路达到目的。
当然不排除做这种结合，也是因为业务体系的纠结所致——我总不能废掉旧项目啊？！所以说，程序员其实很惨的，经常面临历史遗留的情况。当然，攻击者可不管你这些，目的达到，就OK。
那么，导致这次秒杀的业务逻辑漏洞，出现了几条通道呢？答案是，两条。
===========================
问题具体分析：逻辑“生成纽曼K1订单”出现了两条截然不同的通道
通道一问题：秒杀通道逻辑过早暴露、验证码可多次使用、没有限制重试次数
纽曼K1秒杀在前几天就进行了宣传，为此，许多人跑去秒杀频道进行秒杀，不过直到2013-3-31之前，都没发现要输入验证码。其实，K1秒杀的逻辑，已经隐藏页面里面了，只不过关键逻辑注释掉了。而且注释的逻辑中出现了“qiangflow.php”，表明后面要走ecshop的通道，间接显示了和通道二的关系。

虽然这段逻辑在4.1的凌晨时分，替换成正式的版本，不过，大体逻辑没变，所以半自动秒杀脚本就在上班的公交车上，修改完毕。这个半自动秒杀脚本的作用，就是输入验证码后，重复快速提交抢位。由于验证码只要输入正确、且不刷新区域，就可多次使用，并且程序似乎没有限制重试次数，所以设想的通道一攻击逻辑是，到了11点58分00秒，就拉一次验证码，填写后等待12点整点快速重复提交。
不过这里纽曼的程序员做了一次挺奇葩、但不得不说颇为有效的防御：没在秒杀时间内，这个验证码是空白的。这个应该是防御提前进行自动化验证码破解的尝试，也导致了后面攻击的时候，由于通道一的高并发堵塞，再加上服务器配置不当，导致验证码多次502，获取得太慢了，导致攻击最终失败……想法是美好的，现实是悲惨的...
通道二问题：ecshop购买商品逻辑通道仍有效、没有限制重试次数
通道二其实是在通道一上发现的。在通道一的秒杀页面中，点击商品图片，可以跳到另外一个页面。更确切点来讲，在2013-3-31及之前的秒杀中，都是跳到通道二来完成的，通道一只是负责展现操作：
http://www.newman.mobi/default.php?m=default&c=shop&a=item&id=xx
这个页面也可以秒杀商品，提交的通道正是ecshop的购买商品通道，还没有限制重试次数，这样就华丽绕过了用精简版phpcms的秒杀程序的后端限制；并且更为重要的是，它的限制重复提交逻辑放在前端，还非常简单，攻击者最喜欢了：

所以，设想的通道二攻击手法，是到了那天的11点20分00秒，直接打开通道二页面，然后到了11点59分59秒，将cTime重置到-100000，再重复提交addToCart即可。
但是，高并发的问题，导致了这条通道也差点夭折…...
===========================
其他问题：
（1）redis端口对外暴露可访问
www.newman.mobi 和 bbs.newman.mobi 的redis端口6379，可以任意telnet进入操作管理。不过，在2013年3月31日22点50分前后，线上貌似切换到其它有auth的端口了（这就是之前说“周日接近晚上11点还进行了一次服务器维护”的猜测来由）。这是切换前进行monitor的输出：

（2）mysql端口对外暴露，并且留下一个高权限无限制连接账号
承接 WooYun: 纽曼手机官网注入可致秒杀插队（或用户地址泄露） ，进行了一些更细致的分析，发现mysql端口对外暴露，且留下一个极危险的高权限无限制连接账号：'newmantest'@'%'。虽然无法得知密码，但如果有足够的时间、或者为离职员工，也许就能够知道这个账号的密码是什么，从而在不知情的情况下对数据库产生破坏。
（3）精简版phpcms、ecshop均没有关闭错误，攻击者可借此了解系统运作情况。