关于搜狐员工被“钓鱼”事件的反思，钓鱼邮件防范方法讨论，安全如何推动漏洞修复以及企业网络安全工...

语言: CN / TW / HK

时间 2022-06-05 19:20:59 君哥的体历

主题: 安全漏洞网络安全

0x1 本周话题TOP3

话题1 ：搜狐钓鱼的附件，为什么扫码后怎么就一步步转账成功了？给一个付款码链接，直接扫码付款么？谁有样本可以看下？

A1: 就是让提供信用卡或者什么卡的 cvv2 码，可以远程小额盗刷，这有个存活的钓鱼网站： http://rexraspdtz.ikok123.xyz/?time=1653397859344 。

最近这种链接好多，通过短信发送的，域名基本 1 2 天就失效了 , 钓鱼网站都是一两天失效，可以根据指纹特征进行监测。

A2:填写了卡号、CVN、身份证、姓名、手机、支付密码、短信验证码导致钱被转走的。如果是公司的邮箱，那么就不能完全怪员工了,一般找cncert吧。

A3:.xyz域名就很可疑，xyz大部分都是不太好的,打开就是收集信息。

Q:为啥不在检测上下功夫？钓鱼检测不可能做到99%召回率+99%准确率，能做到80%召回率+30%准确率就可以运营了。

A4:找不到一个靠谱的运营人员，10%的召回率，一个万人公司，一天公司内部邮件得10万封，多少条告警。

A5:如果多种检测策略叠加，召回率达到70~80%基本可以实现，几万人的公司每天外对内邮件也差不多10w封，策略叠加检测告警工单控制在100~200个之间，准确率30+%。内对内钓鱼属于突破边界了，主要靠邮箱登录双因素otp、发送邮件组限制、频次限制等治理手段了

A6:主要是公共邮箱的管理问题吧。一般个人邮箱都有otp，公共邮箱大多没有二次认证，多个人同时掌握密码。

A7：邮件做内容检测成本太高了，还不如做好基础安全策略。至少不会造成所谓的全员收到邮件大部分中招的情况，就目前的安全形势，整个邮件网关还是非常有必要的。比如这次sohu的事情，如果是伪造，为啥防护没有到位，如果是从内部邮箱发出，那邮箱怎么被拿下的，这些都涉及基础安全。先关键字搜索一波。

A8: 邮件网关是有必要的，但有一定局限性，比如一般邮件网关基于nlp、贝叶斯、频次的反垃圾邮件能力尚可，但是对钓鱼链接识别就差点意思（一般基于威胁情报库，不做动态渲染页面），附加沙箱检测能力就更弱了。邮件网关不同企业配置也不太一样，有的可能只配置外对内过邮件网关，内对内不过邮件网关。

Q: 目前来看，邮件网关邮件沙箱对二维码检测是无效的。邮箱密码双因素，提升员工安全意识比较靠谱。像话术类的，有人研究过吗，如何防？

A9: 社工的攻击方式很难做到完美防御，内容上交给专业厂商去做，自己做好基础安全和安全意识培训就行了，先杜绝掉大面积被钓鱼的情况。真要做到精确防御，看 AI 技术成熟后行不行。

A10: 普通员工再怎么培训检验提升意识，都不可能抵抗高级社工。 钓鱼防护要基于一定有人中招来考虑检测防御方案 。基于有人中招来防护，没问题。又回到基础安全之一，终端安全，端上的对抗来了。

A11: 搜狐这件事主要还是邮箱安全管理没做好。至于员工，除了意识薄弱轻易相信扫码方式收集个人银行卡信息，别的没什么可说的。是的，网络隔离、访问控制、零信任都是比较好的降低影响的方案。定期做钓鱼演练就知道安全意识惨不忍睹，如果演练中招率低，说明钓鱼邮件伪造的逼真度还不够。

A12: 看起来跟前段时间 b 站员工被诈骗一样手法。都属于 bec 商业欺骗。沙盒对于钓鱼链接的防护没那么好。有的链接就是一个普通的登录页面。在安全意识培养过程中，一定要培养员工一个习惯，看到异常的东西向安全部门汇报。这样即便有人中招，但是也有很大概率会被人举报上来，这样可以及时发内部通知，及时止损。

A13 : sohu 这个事件也可能是因为某个员工泄露了邮箱账号，之前钓鱼邮件属溯源就发现很多受害者提供的邮箱，很多都是真实的。就看这个发件人账号有没有归属了。

A14: 一定有归属的，总有申请人或者管理员吧。现在钓鱼邮件的模板基本都差不多，希望这方面的威胁情报大家能够共享出来。现在见最多的就是包含工资、补贴、系统、升级、改密之类的关键字。

A15: 从攻击者看，投入太小了，一台服务器，一个域名，换个前端关键字，就可以去诈骗不同的公司。一般三种攻击方法： 1. 窃取邮件账号密码或者获取办公终端权限，再登录邮箱投递邮件； 2. 伪造发件人现在企业有 spf dkim 能防绝大部分，但也有绕过方法； 3. 邮箱系统被攻破。

A16: 这个价值可能有限，因为一般都会定点去钓鱼，临时域名，临时 IP ，用完就抛，防止被溯源。 so，搜狐的问题在于，这家公司在当下可以完美契合鱼叉的所有状态，疫情居家，多地办公，没有自身 Im, 严重依赖邮件，邮件组在网上一堆一堆可以搜到，公共邮箱也数不胜数。内部安全意识培训要跟上，二维码案例属于绕过常规的url检测。

A17: 团伙应该对主流域名做了监控，对他们来说只是一个广撒网的诈骗。企业出现漏洞，信任关系被利用来攻击员工了，和钓鱼攻击企业还不是一个场景。目标专一的还是少，大部分是骗到邮箱账号密码之后再发内部件。

A18 :银行的转账支付渠道是不是可以控制，邮箱其实就不应该在外网能被登录和访问，如果一定需要的话，要有otp。最好的防护就是一旦遇到扫码要输入密码的就不要再继续操作，做好核实后再处理。

A20: 第一种是大概率，邮箱弱密码满天飞，很难收敛。实践中一般都是盗号后向外发垃圾邮件。邮件系统被攻破一般比较难，内网也快沦陷了，可能就直接上勒索病毒了。

A21:spf dmark dkim 我们再加 offer 365 策略，还没碰到能绕过的，最多的到垃圾箱，也有外部邮件不常接受提示

Q: 商业邮箱系统开放到公网的，还是有可能，之前不是爆出很多 xxxmail 的漏洞么？

A22: 之前在完美我们是把 owa 放在内网了，同时加了 OTP 上去，如果要访问走去访问。手机邮箱开了证书 + 密码的双因素对外暴露，方便及时收到邮件。对于领导而言，都是用手机访问，因为有证书 + 密码到双因素，所以用户只有在首次登陆时导入证书麻烦点，使用过程无感。

Q:Owa 还有 ews 之类的接口，某些 ota 都可以绕过。抛一个问题，一些 saas 化的企业邮箱，如何能知晓其操作日志？比如员工登录，员工修改密码，邮件发送时的 peer 。

A23: 不被控的接口不允许对外。其实也可以实现，就是不直接暴露到公网，通过 VPN 或者零信任。邮箱在外网的入口真的要双因素，只有一个密码太容易被搞了，然后就是一波钓鱼

只不过在后续落实里，很多落位有问题，邮箱这块不在安全管，大多都是企业的ero或者 it 部门。

A24: 现在的钓鱼团伙，感觉也有分工，先用钓鱼手段获取邮箱账号密码，再使用这些账号去内部钓鱼。第一步通常不涉及银行卡之类的，更容易中招。移动端和网页端都好加 otp ， pc 端太头疼。

Q: 那如果是企业微信场景呢？通过企业微信需要跳转访问邮箱，请问如何实现安全加固？

A25: 远程办公场景下，用零信任网关收敛邮箱，网关侧上 2FA 。这个是有 mfa 和 otp 的，但是在 exchange 场景里，有个地方是没办法加 token 的，所以只能用网络边界去收。

A26:公共邮箱指定负责人，用的时候麻烦点而已 ,所以ews, pop, imap这些都要收口，然后看实施成本 。http://mail.sohu-inc.com/ews/ ews接口在的，otp可能就可以绕了。 exchange除了ews还有几个接口都要注意收：aspnet_client/ Autodiscover/ exchange/ ecp/ EWS/ Microsoft-Server-ActiveSync/ OAB/ PowerShell/ Rpc/

A27:这一整套感觉其实方案不难，但是确实很多公司都用不了，反推的话，原因和场景会很复杂。

A 28 : 手机企业微信要对接接收邮件场景如何实现呢？所以问题点不在于邮箱如何如何，要骗也不一定邮箱骗。之前还有诈骗通过 im 软件混进公司群或者伪造成公司群的。最终还是心智管理。

Q:saas 邮箱呢？大家公司邮箱几个人维护呢。与其花功夫在邮件网关上的双因素，不如让 vpn 或者零信任收敛掉邮箱

A29:公司没这个场景。单独做了个app+emm收敛的。

A30:这不是内网通信吗，邮箱imap和登录用的smtp都需要收敛掉，否则爆破密码太方便，公网其实留一个收信的邮件网关就可以了,只开放投递的smtp,再加上邮件网关，应该能解决大部分

A31:不一定哈，很多企业，企业微信非私有化部署。一般都是在企业im集成邮件客户端了，配置邮件服务器信任策略，客户端还可以增加些水印之类的防护功能。

A32:那源是固定的吗，发起端是企业微信的应用网关而不是手机吧。这是小程序而不是h5。是一个事么？另外就是公网服务，双因素必须有，公共账号还可以加登录来源、拒收外信

上一个出事的b站没过几个月呢？这种钓鱼邮件样例我们都拿来内部考试过，确实最近很猖獗。根据同个指纹随手找的一个模版一样的工资补贴类钓鱼网站;这套钓鱼模版近两年一直很活跃，域名基本一两天一换。

提高普通员工的安全意识很重要，特别是新入职员工基本上防钓鱼意识都普遍差。

话题2: 【漏洞通告】Fastjson反序列化远程代码执行漏洞 ，这次fastjson漏洞利用的是哪个依赖里的利用链，有大佬知道了吗？不清楚不好排查真实影响呀。

A1:粗暴一点，替换jar包。目前看到有的厂已经连夜搞升级了，漏洞不严重的话，也不好叫研发起来搞，线上还要考虑兼容性。

A2:我有个不成熟的论点，程序有bug，是概率学问题 7/1000 ，无关乎技术牛与否。安全漏洞是 bug 的一个分支，因此漏洞是客观存在的。

A3:他就是不改，能开了人家吗？离开了安全，业务还能转，但离开了开发，业务可能就停摆了，上升到cio又怎么样？情商高的 cio 反过来会甩出一句话，你们两个商量拿个方案。人家就是这么牛逼，虽然安全道义占优，但人家是经济基础，资本主义说了算。

A4:你说的这个场景仅限于莫须有的风险，fastjson这种实打实的试试？

A5:如果 CIO是安全最高负责人，他不推，那么就是他的决策。哪怕是企业也是，比如银行也是分管技术的副行长做安全责任人。最重要的是谁负责，最后有决定权，而且安全事故都是双罚制，影响政治前途和个人行业发展。cio还是科技产出第一负责人，有多少老大是安全不合格干掉的？又有多少老大是因为科技业务不达标被干掉的？老大心里也会算账的。

A6:看在监管报备的人是谁。通常是两个人企业法人代表和安全直接责任人。这个就是他决策、他担责，是没问题的。出事别甩锅给安全就行。别都和大银行比，银行也是这几年才起来的。安全的同学如果遇到那种遇事不推，出事甩锅给安全的领导，还是趁早走人。

A7:只要CIO能拍板决定，他自己平衡业务和安全，出事能扛。没啥问题。还是看在监管部门的报备。比如在网安和通管局，银保监写了谁的名字为准。其他人还真没资格扛把子。安全事业技能：徒手排雷肉身堵枪眼人形避雷针。

A 8 :参见这条，CIO对决策后果负责，达成一致就行。

A9:要有实际的处罚案例才行，否则都是一纸空文。既没有落实党委责任制，又不是关基，纠结下安全or利润，还是很普遍的，以利润为目标的话，还是讲 ROI 。不论是处罚还是损失都有很多啊，一大把。

A10:因为信息安全过失或履责不到位，把公司老大罚了的案例有吗？别和一大堆处罚原因中加一条。

A 11 : 我们以前有个组员专门负责收集安全事件案例，真的太阳底下无新鲜事，太多了，一直都有泄露，处罚，损失。后来关基了，就不需要了。想找的话，很多很多。每周都停不下来。银保监会1号处罚来了！案由竟然是...

A12:仔细研究这些案例原因，纯信息安全领域的原因，都是捎带脚的，附属的，信息泄露处罚都是小打小闹。这个是有逻辑关系的，而不是说，做内审发现你有事情没报，捎带脚检测下漏洞，你要是故事都不愿意讲，那给再多案例也没用。老大们都不傻，有自己的朋友圈，具体什么原因他们都门清，故事永远是故事，要事故才行。

A13:那不可能，谁都有漏洞，问题在于你能不能应急处置，别发生网络安全事件，漏洞30day都不修，尽责吗？漏洞不修，你能虚拟补丁防住，能应急处置不受影响，能业务收敛暴露面，那也行啊。要是兜不了底，那还是乖乖修漏洞。

话题3：SCA-五大数据源-联防联控&SCA-运营策略

#SCA-五大数据源-联防联控

[安全漏洞-数据源-代码仓库] 扫描Gitlab代码仓库pom.xml，周期监控代码是否使用高危jar包依赖
[安全漏洞-数据源(容器镜像)-云原生] 对接k8s服务，监控云原生服务的容器镜像是否使用高危jar包
[安全漏洞-数据源(HIDS)-主机运行时] 托底检测：HIDS的jar包采集数据，一日一检，监控主机进程是否加载高危jar包
[安全告警-数据源(构建平台)] 业务构建时对接产出物扫描
[安全告警-数据源MAVEN仓库-对接的maven下载日志]业务在本地开发时，下载高危jar包，直接邮件告警

# SCA-运营策略

[三区分级差异化防控] 外网漏洞(封控区)1天修复期限，核心业务(管控区)3天修复期限, 边缘业务(防范区)5天修复期限
[动态清零-拒绝假修复]坚持SCA高危漏洞动态清零，应修尽修，风险有限(修复成本高的）进行加白(如rockemq中间件等)

A1:有时会碰到较真的Java架构师，拍胸脯讲在他主持二次开发的框架下，不存在被利用的可能性，高危函数也不会被用到，所以依赖包不用升级，不用发新版本。这时，还需要源码解析和并支持结构化查询。升级或不升级情况都发生过。

A2: 这个是复旦大学陈碧欢的演讲，从23:15开始看。大致能做到分析 CVE 哪些地方出问题，影响了哪些函数，要不要负责任地报警，还是静默。 http://www.bilibili.com/video/BV1ST4y1f7Z7?spm_id_from=333.880.my_history.page.click

A3:这种分析在实战中可以用于定修复的优先顺序，但不能替代漏洞修复，因为后继的代码变动，大部分企业根本没有资源跟进保障。

A4:这是一种数字化的沟通协作，安全要被别人尊重，也要讲开发的语言，闭环才能更快第迭代。

A5:今年有些CVE，我们就没升级，因为利用起来确实很困难，排查也没发现，就暂时不升版本。

A6: 核心是决策担风险的人，能对决策负责，也为决策负责。一个说不用升级，老板说一定要升级。安全就退后一步，中立地拿出数据。

A7:在这个场合，架构师来做决策，是角色错位。我们没少见过架构师抵死不愿意升级，然后过几个月就被打穿的情况

A8:陈教授的方法，越来越难，因为CVE公布的信息会越来越少，打补丁的部分分析起来也费劲，能讲清楚 CVE 和补丁人越来越少。如果架构师能讲清楚机制机理，知道补丁做了什么，到了那个程度，还是应该得到尊重。

A9: 安全尊重架构师的建议是安全侧的选择，这个没问题。但决策者不应该是非安全线的架构师，架构师应该尊重安全的决策。很多资深架构师对安全的理解也是有偏差的，毕竟术业有专攻。特别是程序员编写代码，对于编程规范的遵从性是很不可靠的，特别喜欢各种奇技淫巧，复杂代码几乎就是墨菲定律必然发挥威力的地方。

A10:曾经遇到过系统研发人员说我承认有漏洞，也成任可能会被利用，但是我没时间改我要完成开发任务，完不成开发任务我就要被开了，如果安全出了问题这个风险我担了。

A11: 这种情况关键是要及时上升，让风险暴露到合适的决策层，不要卡在执行侧。如果真正能代表公司和业务的决策层愿意先承受风险，大家达成一致就行。但公司安全品牌的损失不能让局部业务来判断。

A12:对，这个时候一般只有刷脸沟通加说明后续操作，实在不行就风险上升。想起来以前一个牛逼架构师设计开发了一个能管控几十万服务服务器的运维系统，宣讲材料写的的非常牛逼， 99.99% 的安全，甚至推演了出要攻破只能绑架他们员工才行的结论然后团队有大神逆向分析了 c/s 通讯协议找到漏洞，自己实现了一个控制端可以绕过认证直接连上所有服务器且是 root 。技术牛逼也真是牛逼，但是能力有差异。

A13:其实数据支持决策很重要。我们有过安全说log4j排查没事，没用到，但是排查出有很多问题，要马上改，发版本。也有过安全说有问题，但是最后同意不用发版本。能不能在组件级别再下钻，到代码组成级别，也是一种数据能力，数据就在那，决策的人都知道意味着什么，调子也不用高，不用低。数据支撑比命令或杠在那或忍了都强，大家的信任和协作才能越来越快，越来越顺。

A14:我也遇到过安全评审时有的架构师上来的第一句话就是这里没有安全问题不用讨论了，每每遇到这种情况我就会仔细看看然后总能发现安全问题，屡试不爽。最好能出个类似于永动机的公理，这样大家就不用在这种事情上面浪费时间了。

A15: 拿捏不准的时候，要找业务风险核心干系人，有时一线执行或技术负责人，无法代表业务做出风险偏好决策。所以说不是自己知识领域的问题还是多听少说比较好，不能轻易拿自己领域的知识去判断别人领域的事情，安全其实也一样，搞安全也许稍微了解深一点但是对高并发高分布式处理、工程化还是要多听听研发架构师的意见不能瞎指挥，毕竟隔行如隔山，保持敬畏心太重要了。