长亭百川云 - 文章详情

由于蜜罐这几天比较热闹,蹭热度说个故事

全闲话

55

2024-07-13

提前声明:本文不说打穿蜜罐的那些破事,哈哈哈,失望了?没有?

众所周知,搞安全的都喜欢部署蜜罐系统/钓鱼系统,一般是丢在内网玩。除非是有实力,而且是非常有一腚实力的才敢放外网,不然呢?大家都看到xxx被爆菊了吧,哈哈哈~

所以,传统安全领域里说的蜜罐,咱就不说了,讲个不太一样的用法。

这个其实是个旧事,距今大概10几年了。那时候高草还在邮箱部门搬砖,重头构建新的安全体系。说重头做,其实都是被逼的,全TMD是被逼的,原系统基本没啥架构可言,破腚百出...

当时花了好几天时间,做了个半年计划,写完了自己看着PPT总觉得缺点啥,总感觉有一个环节没打通。

当时的情况是,每天铺天盖地乱飞的垃圾、钓鱼、欺诈、木马邮件都有个特别明显的特点:量大,重复的多。缺失的一环就应该是怎么自动化把这些破烂收起来,归纳总结,用算法(当时不流行说AI、深度、神经病算法这些)分析分析。

这事苦恼了好久也不知道怎么搞,索性静下心来人肉分析样本。于是,从系统各个环节采集样本,大概有几百万的规模。等都看完,问题有答案了,办法自己就来了,你说神奇不神奇!

咱直接在前面协议交互时,从HELO开始,就把那些发送给不存在人的邮件都收下来。在正常的协议交互里,自然是会告诉你这个账户不存在或者系统错误,然后byebye断开连接。这里可以做点手脚,另外找个地方继续往下走,邮件体咱都存下来,然后内容+行为分析下不就行了!

嗯,当然为了增加点迷惑性,还得加个随机,一会账号存在,一会账号不存在。

这个做法开发量非常少,很快就能上线,内容行为归纳总结的模块基本都是现成的,怼进去就行,把发现的异常样本按照出现数量排个序,定期更新,ban就是了,都不用担心会存在误判。于是,每天80%-90%的垃圾就这样被搞定了,哈哈哈~

为了方便非邮件系统圈子内读者的理解,这里稍微解释一下。逻辑是这样的,正常的邮件系统肯定是知道准确的收件人地址,手误写错地址的情况有,但是绝对不会在数量上占优。反而限于当时的邮件地址泄漏规模的大环境,黑产灰产还是采用基于字典广度覆盖的方式比较多。所以,在系统侧会发现,每天都有数目庞大的不存在地址探测。只是,正常情况下,这部分请求走到收件人地址检查这里就会告诉你“该用户不在服务区”,然后断开了,不会往下面流程走。

咱既然是要做个蜜罐,理论上100%都采集下来也问题不大,当然大系统就不推荐这么干,浪费资源不说,你这系统咋啥地址能收到呢?对方一眼就能发现问题,所以,设置一个不大不小的概率肯定是必须的。

至于存下来后面接的东西,无论是交互行为分析,还是内容分析,都不是什么难事,直接略过。

这套蜜罐直接对外网服务,按道理是不妥的,要解析内容就会遇到很多未知风险,如果给开了shell那就更sb了不是。所以,进入到后期分析之前,还是要做一些必要的过滤处理的,该丢的先都丢掉,也就是只解析一些我们感兴趣的东西,一般只要包括文字、图片、JS就行了。但是,JS不要解析不要解析不要解析!

说到图片,必须多讲几句,图片的处理库当年还不是那么多,开源的就几个,也不是很好用,都有一些大大小小的兼容性问题,core掉还不是大问题,单是溢出开shell都已经有很多了。咋办?完全重写肯定不现实,所以高草当时做了一件几乎不被开发理解的事情:把几种主要格式的处理库都剪裁出来了,重新包装了一遍,第一层必须是对buffer做限制性复制,然后才丢给相应的解析库处理。格式也不多,干起来也不难,BMP,JPEG,GIF...也就那么几种格式,很好搞。

至于剪裁解析库这个事,其实不需要过多解释,搜一下过去几年的开源图片处理库漏洞,比如imagemagick库给人家弄出来多少远程shell,你就知道那时候我在担心啥了。反正该做的都尽量做好,剩下的就是更衣沐浴抽根烟上线。

故事讲完了,这里说的这个蜜罐系统的做法,只是想说一句蜜罐其实也可以这么玩。不必纠结,蜜罐是好东西,小心用就是了,哈哈哈~

谨以此图,献给对蜜罐又爱又恨的朋友~

相关推荐
关注或联系我们
添加百川云公众号,移动管理云安全产品
咨询热线:
4000-327-707
百川公众号
百川公众号
百川云客服
百川云客服

Copyright ©2024 北京长亭科技有限公司
icon
京ICP备 2024055124号-2