攻防无界 安全沙龙

企业红蓝对抗体系建设 by lake2

TEG下有安全平台部。另一个BG下有玄武、科恩、云鼎三个安全实验室。
把安全嵌入到开发流程中。比如build会触发代码审计，发布到测试机上会触发安全测试，等等。
快手和腾讯都有自己的红蓝军。
DDoS可以分为资源消耗型和流量阻塞型。
“泛蓝军”其实就是众测，寻求社会白帽子的智慧。一个例子是腾讯TSRC。
需要重视平台建设，将个人能力和经验沉淀为平台策略，实现自动化检验。（员工会有流动，平台不会。自动化的效率肯定更高。而且可以对外提供安全服务。）
蓝军的职能：

• 系统（渗透测试、漏洞挖掘、APT）
• 物理安全和物联网安全（复制卡，窃听窃视，智能音箱、智能楼宇（用无人机开灯开窗帘））
• 业务（薅、刷、挂，比如下面的短视频业务安全，此外也可看我另一篇博客《风控部门是做什么的》）
• 网络（DDoS、链路劫持）
• 维护和组织泛蓝军活动
• 支援（安全情报、漏洞研究、武器库研发、技术复盘）
  一般的渗透流程，外网-办公网-idc。

短视频业务安全 by 陈成

陈成是快手业务安全一把手，中科院博士。这跟我对52pojie上一些民科的印象有些不同。自动化判断黑产，需要很多创新，也有很多挑战（比如图挖掘，机器学习的应用）。安全领域对抗性极强，所以机器学习的应用更加困难。比如视频录下键盘上输入网址的过程，或者通过“妹。B。好难过。”这种很难机器分析的文本。

黑产盘点

资源类：

• 虚拟运营商，开大量sim卡（黑卡）
• 集合宽带、基站IP等动态IP（黑名单外的代理IP）
• 伪造虚假设备指纹（改机）、购买IMEI白库
• 个人身份（身份证号）和企业资质资料买卖
  服务类：
• 打码平台，比如让“兼职”大学生肉眼识别验证码
• 发卡，隐蔽交易，最经典的就是vi pi en充值
• 接码平台，代收发验证码
• 群控，提供多设备批量执行功能（比如市面上的一些安卓模拟器）
  变现类：
• 恶意引流
• 广告联盟作弊
• 网络诈骗

从肉鸡到真鸡

这一趋势来自近年被广大百姓熟知的的互联网的资本运作模式（先补贴抢占市场）。作弊者可能是“兼职”大学生，或者隔壁加了“薅羊毛群”的大爷大妈。产生了专门的网赚/兼职/羊毛APP，由真人操作真机进行作弊。
黑产如改机、分身、群控（比如，拉新用户直接给现金），
灰产如互助、众包（比如，加群互相关注点赞，互相砍一刀，真人粉丝，真人评论，真人播放）

恶意引流

新兴作弊。毕竟流量离真金白银只有一步。
黑产如垃圾内容（比如带有emoji的网址），灰产如立人设诈骗（假靳东）

风控的度很难掌握

误报：管太多可能会误杀，接到黑猫投诉，工商局投诉，或者客服挨骂。毕竟用户都是活人。为了不影响体验，可能会采取专门警告信息、延迟发放奖励等措施，需要具体分析。
漏报：“上帝，你为什么没有保护我”：拦下来的成绩没被看见，漏报一个就很难做

平台化

因为黑产的变化非常快，按传统流程排期开发的话往往来不及。应尽量提供“一键上线”。

安全情报

比如，潜入一些薅羊毛qq群、微信群、telegram群。从外部发现业务风险。

IoT平台安全体系建设

洗碗机、保险柜等产品样机很重。
技术复杂，硬件、软件、安全都要懂，招人难，只能进一步细分岗位。
需要研究各国法律，AIoT一不小心可能就要吃罚款。
产品品类太多，一样样测过来，本来该精英化的实验室变成了流水线。
老人走了，新人来了，继续做同样的事情，犯同样的错误，这是不应该的。总应该上一个台阶的。
把IoT产品的各个组成要素都拆解出来，逐项扫描。（有点360安全卫士体检的味道了，把计算机的健康从各个组成要素来评估。）
攻击是分步骤的，每一步成功都需要一些条件，如果能阻断某一步的条件，就能大大降低这种攻击的成功可能。如果不能补上系统的所有漏洞（阻断所有攻击步骤的所有条件），那应该尽可能打断所有的攻击链（阻断一次完整攻击中的部分环节条件）。
IoT的供应链问题更严重，因为依赖的东西更多。

快手应用安全演进

原来root pom禁用fastjson是因为它是漏洞之王。应当用Jackson和gson来代替。
对新代码，用静态扫描规则扫描。对老代码，先让对外业务应急处理，再让对内业务应急处理。
业务发展迅速，很多漏洞都是上线后才发现。
前期预防，培训考试，Java安全SDK，IDE插件，maven安全插件
后期检出，Java静态扫描，动态扫描，安全测试平台，API管控平台，IAST（与基于扫描的漏洞发现不同。通过插桩收集安全信息，在生产阶段发现漏洞），Docker扫描，域名管控，端口管控
一个倒逼的方法是，把漏洞告诉测试，让测试去逼研发，这样研发就不会再把安全当成负担，而是成了一种“安全绩效”，证明自己部门的代码质量。

关于老师提到的sig3:
上网一搜h5 sig3，出来的全是逆向报告。
按我了解，签名算法的安全性不依赖算法的保密性。
我深入了解了一下，这里的“签名算法”不是我想的那个签名算法。
我理解的签名算法，是MANIFEST.MF，CERT.SF，CERT.RSA，本质是摘要后，用私钥签名，作用是防止app被第三方篡改（第三方可以篡改、重新摘要，但做不到用原始私钥来给摘要签名）。
而此处的签名算法，作用是保护API接口。第三方可以抓包判断出某种请求对应的API，如何避免第三方利用这个信息随意伪造请求？比如说，获知某人的账户信息后伪造请求，获取其主页推荐内容。这种签名算法通过自己设计一个私有算法，将账户信息进行一些计算，附加在请求的最后。服务端可以校验结尾的这种信息（称之为签名信息也还算有道理），如果前后能对上，才予以响应。这样一来就能避免请求的伪造。