协同共建|深入分析应用密钥安全治理之术

协同共建|深入分析应用密钥安全治理之术

文|应用漏洞扫描Oteam、PCG安全团队

Martinzhou


I. 背景


当前,各类开放平台、依托云原生技术模式的PaaS/SaaS服务涌现,密钥(Credentials / Secrets)成了跨服务、跨平台调用认证的关键一环。短短几十个字符,背后往往通向上万台CVM或者整个业务数据。好似露出洋面的一角冰山,稍往下深挖,底下可能就是牵动企业安全命脉的“金山银山”。


当前,针对个人用户登录密码的保护技术日臻成熟,基于短信验证码、指纹、人脸或是物理设备的多因子验证获得较为广泛的落地。但用于服务与服务间认证的密钥,往往未获得同等力度的安全保护。


协同共建|深入分析应用密钥安全治理之术


针对上述与应用密钥有关的风险,本文将从研发及数据安全视角,结合近期实践,从四方面探讨可采取的治理思路,以求抛砖引玉,也欢迎大家参与共建,共同探索。阅读本文,你将收获:


有哪些存在风险的敏感密钥?

如何检测敏感密钥泄露?

开发人员如何安全地使用密钥?

业务系统如何安全地设计密钥?


II. 密钥安全四问


2.1 有哪些存在风险的敏感密钥?


知己知彼、百战不殆。在着手扫描清查密钥风险前,可以先对业界各类常见的密钥类型做梳理。否则容易陷入疲于应对已暴露密钥,case by case添加规则。基于我们的实践,分享可参考分类思路如下:

协同共建|深入分析应用密钥安全治理之术

值得一提的是,各企业内部可能也建设了一系列PaaS、SaaS平台,可根据自身实际情况酌情梳理、纳入风险评估。


接着,就需要评估已梳理各类密钥关联的风险(如,会导致数据被匿名访问)及检测特征(如,密钥自身存在的显著特征,详参见2.2.1部分讨论)。梳理思路可以表格形式记录,参考如下:


协同共建|深入分析应用密钥安全治理之术


2.2 如何检测敏感密钥泄露?


 2.2.1 敏感密钥概况 


场景一、匹配密钥本身的特定格式


密钥本身有很强的特定格式,可以直接用正则匹配。例如,

腾讯云appid会以AKID开头,例如:AKIDxxxxGithub服务间相互调用的密钥以ghs开头,例如:ghs_tVGHE4***666222


匹配方式简单直白 —— 写正则匹配密钥本身。例如,针对在代码中硬编码腾讯云密钥的风险,使用开源静态代码检查工具semgrep,不难快速编写出扫描规则:

pattern-regex: (AKID)(?i)[a-zA-Z0-9]{32}bpattern-not-regex: q-ak.+(AKID)(?i)[a-zA-Z0-9]{32}


场景二、匹配密钥及所处的代码结构


现实场景中我们会发现,绝大部分密钥本身没有很强的特征,例如:大部分数据库的账密可以是任意ascii可见字符,但随代码硬编码却比较常见。


协同共建|深入分析应用密钥安全治理之术


以数据库账密泄露排查为例,根据经验,我们得出三类大规模匹配检索思路:


1)匹配含密钥的数据源声明链接


Go语言中的DNS链接,如:redis://:@127.0.0.1:6380/test?is_proxy=trueJava JDBC链接,如:jdbc:mysql://127.0.0.1:3306/db_xxx?user=&password=&useUnicode=true&characterEncoding=UTF8


2)与密钥关联的特性API/域名、IP+端口特征


内部以名字服务形式声明的数据库地址,如:db.foo.com:3306


3)代码结构中有明确的sink点特征,通过追踪回溯source点,可判断变量值是否是字符串或常量等硬编码形式。例如,Python声明mysql连接的方法


db = pymysql.connect(host='localhost', user='testuser', password='test123', database='TESTDB')


场景三、密钥的模糊泛匹配


除上述两类有较明显规律可循的场景外,不少硬编码密钥的代码结构更为松散,这时候还可以尝试编写一些模糊泛匹配规则,以增强清查效果。


根据前期实践经验,敏感密钥通常会分布于三类场景中:


各类源代码文件,如:go、java等

配置文件,如:yaml、toml等

其他类文件,如:markdown、csv、Dockerfile等


编写敏感密钥的规则时,同样拆分成三大部分:


键(Key),通常匹配是否包含特定关键词,如token、psw、password等;

分隔符,通常匹配不同编程语言中的分隔符,如:=>、:、=等;

值(Value),通常匹配特定的密钥字符集范围及长度


协同共建|深入分析应用密钥安全治理之术


 2.2.2 检测手段及工具 


结合上述对密钥的分析,我们将可以选用的手段及工具概括如下:

协同共建|深入分析应用密钥安全治理之术


业界可供参考的敏感密钥扫描工具分类推荐如下:


1)trufflehog

项目地址:

https://github.com/trufflesecurity/truffleHog

检测思路:取长度大于20的魔术字符串,再匹配规则

支持范围:多语言


2)whispers

项目地址:

https://github.com/Skyscanner/whispers

检测思路:正则

支持范围:多语言


3)credential-digger

项目地址:

https://github.com/SAP/credential-digger

检测思路:机器学习

支持范围:多语言


4)hardcores

项目地址:

https://github.com/s0md3v/hardcodes

检测思路:正则

支持范围:多语言


5)gitleaks

项目地址:

https://github.com/zricethezav/gitleaks

检测思路:正则

支持范围:多语言


 2.2.3 DevOps流程嵌入 


基于对历史安全事件的复盘,我们发现密钥有可能在研发流程的任一环节泄漏并产生风险。因此,比较合适采用“洋葱式”层层检查设防、运营收敛:


协同共建|深入分析应用密钥安全治理之术


密钥异常行为检测


除在软件研发生命周期的各环节匹配检测各类密钥外,还可以结合密钥的HTTP访问日志建立调用请求行为的基线特征,识别异常的密钥调用。


例如:如果发现某类云平台的密钥调用来源IP的城市分布超过特定数值,则可以推测可能被错误地硬编码在APP/小程序客户端对外发布,存在安全风险。


2.3 开发人员如何安全地使用密钥?


 2.3.1 综述 


简单来说,安全地在应用中使用密钥有两大原则:一是安全地使用密钥;二是当生产环境应用代码中涉及多个密钥时,应考虑使用KMS类方案集中托管并定期轮换。


其中,安全使用密钥遵循以下原则:

1)权限最小化,缩小关联的权限、缩短有效期、专钥专用,例如:部分云平台提供的STS密钥(Security Token Service)


2)为密钥设置IP/PMS调用白名单


3)为密钥传输启用TLS,防止中间人劫持窃取


4)密钥定期轮换并保持资产负责人准确


5)使用密钥托管平台托管系统(KMS)


下面将以腾讯业务生态下两种最常见的密钥为例,介绍相关安全开发方式。


 2.3.2 安全开发示例分析 


* 以下仅为举例说明,非真实案例。


1)微信开放平台密钥


最常见风险场景是,为了实现用户微信登录的功能,将微信开放平台的secret直接硬编码在APP、HTML5页面及小程序等源代码可被直接接触的代码环境中。


协同共建|深入分析应用密钥安全治理之术


在此场景下,安全的开发方式为:

1、客户端仅携带appid,由应用在服务器侧保存appsecret;


2、应用发起微信授权登录请求,微信用户允许授权第三方应用后,微信会拉起应用或重定向到我们自己的第三方应用,并且带上授权临时票据code参数;


3、服务器将appid + appsecret + 临时票据code发往微信开放平台,换取当前用户的access_token;


4、微信开放平台返回access_token给服务器,该凭据应由第三方应用服务器代用户保管与当前用户的登录态绑定。


协同共建|深入分析应用密钥安全治理之术


值得一提的是,如果开发者已经使用了上述不安全的编码方式,或应用下架密钥已无需使用,应及时登录微信开放平台重置并替换或注销密钥。


协同共建|深入分析应用密钥安全治理之术


* 以下仅为举例说明,非真实案例。


2)腾讯云密钥


最常见风险场景是,为了在小程序、客户端中调用云产品的功能,开发者直接将常规云密钥AK/SK硬编码在产品中。此类密钥往往绑定的不止一类云资源,甚至关联了CVM、CLB等关键资产。云场景下两类常见密钥的区别概括如下:


协同共建|深入分析应用密钥安全治理之术


其常见的风险是误将高权限的常规密钥,包含在APP、网页或小程序中,可被外部攻击者窃取。


安全的开发方式,以在前端或小程序向COS存储桶直传文件开发场景为例,可概述为:创建STS临时密钥(临时访问凭证)。其核心在于:1⃣️限制可操作的对象;2⃣️限制对存储桶允许执行的操作


// 这里改成允许的路径前缀,可以根据自己网站的用户登录态判断允许上传的具体路径// 列举几种典型的前缀授权场景:// 1、允许访问所有对象:"*"// 2、允许访问指定的对象:"a/a1.txt", "b/b1.txt"// 3、允许访问指定前缀的对象:"a*", "a/*", "b/*"// 如果填写了“*”,将允许用户访问所有资源;除非业务需要,否则请按照最小权限原则授予用户相应的访问权限范围。config.put("allowPrefixes", new String[] {        "exampleobject",        "exampleobject2"});// 密钥的权限列表。必须在这里指定本次临时密钥所需要的权限。// 简单上传、表单上传和分块上传需要以下的权限,其他权限列表请看 https://cloud.tencent.com/document/product/436/31923String[] allowActions = new String[] {            // 简单上传        "name/cos:PutObject",        // 表单上传、小程序上传        "name/cos:PostObject",        // 分块上传        "name/cos:InitiateMultipartUpload",        "name/cos:ListMultipartUploads",        "name/cos:ListParts",        "name/cos:UploadPart",        "name/cos:CompleteMultipartUpload"};config.put("allowActions", allowActions);


2.4 平台系统如何安全地设计密钥?


如果你正运营着开放平台,自身就是密钥的提供方,则需要注意以下几点:


1)密钥的appid或secret在格式上必须具备明显、可区分的特征


2)遵循“权限最小化”原则,平台应为开发者提供密钥安全加固功能。包括但不限于:允许开发者重置密钥、为密钥设置IP调用来源、允许设置密钥关联的接口权限等


3)除明文账密外,为服务端应用密钥启用引入MFA机制


 2.4.1 密钥自身的设计 


2021年Github工程团队在其技术博客中宣布重构其开放API关联的密钥结构。由于旧密钥仅为一串特定长度的字母数字组合,容易与其他哈希值混淆产生误报,增加了密钥扫描的难度。

协同共建|深入分析应用密钥安全治理之术


通过引入gh等一系列前缀,按功能从密钥本身设计区分出不同功能场景,使安全扫描排查更简单。其差异对比如下:


协同共建|深入分析应用密钥安全治理之术


 2.4.2 密钥管理功能设计 


同时,如果平台系统提供的API要带密钥,应至少具备以下安全能力,供开发者自行配置使用:


1)允许设置调用来源IP白名单

2)调用频控限制

3)禁用或重置密钥能力


协同共建|深入分析应用密钥安全治理之术


 2.4.3 提供MFA机制 


除上述围绕密钥自身安全设计、密钥安全加固功能外,也可以考虑为服务端应用密钥引入MFA机制。业界也不乏已落地机制参考,例如:MySQL企业版提供的LDAP、FIDO认证插件,参见《LDAP Pluggable Authentication》,https://dev.mysql.com/doc/refman/8.0/en/ldap-pluggable-authentication.html


协同共建|深入分析应用密钥安全治理之术


III. 总结


密钥虽不起眼,但应用背后的应用资产和数据的安全往往悬于短短几十个字符间。本文尝试从密钥使用和提供两方视角入手,探讨各环节和场景下的密钥安全综合治理。整体可概括为:


 平台系统作为密钥提供方 


1)密钥的appid或secret在格式上必须具备明显、可区分的特征

2)平台为开发者提供了密钥调用提供加固机制,包括但不限于:允许开发者重置密钥、为密钥设置IP调用来源等


 平台系统作为密钥使用方 


1)已引入安全工具对扫描代码仓库/制品/Web接口等渠道,进行密钥泄露检查

2)已遵循第三方开放平台提供的最佳安全实践在系统中使用密钥;或使用配置中心或KMS密钥托管系统,单独存储密钥并定期轮换


过程中诸多事宜乍看轻松,实践中却会有诸多考量点,应用漏洞扫描Oteam、PCG安全团队、腾讯安全朱雀实验室等团队也在持续探索密钥安全治理的落地方案,欢迎大家留言交流。



# 参考资料


[1] Access Keys Will Kill You: Before You Kill The Password, 

https://www.blackhat.com/docs/us-16/materials/us-16-Simon-Access-Keys-Will-Kill-You-Before-You-Kill-The-Password.pdf

[2] Behind GitHub’s new authentication token formats

https://github.blog/2021-04-05-behind-githubs-new-authentication-token-formats/

[3] Detecting Credential Compromise in AWS, 

https://i.blackhat.com/us-18/Wed-August-8/us-18-Bengtson-Detecting-Credential-Compromise-In-AWS.pdf


# 团队介绍


应用漏洞扫描Oteam,由公司各BG安全团队联合组成,专注于构建自动化安全系统为腾讯业务保驾护航。目前,运营有Web漏洞、高危服务、代码漏洞、客户端安全、云PaaS服务及制品相关的系列大型自动化安全系统。


PCG技术安全团队,隶属于平台与内容事业群的技术平台线,主要负责为事业群下属社交、视频、信息流服务等重点业务产品提供一对一的应用及数据安全保障,以及DevSecOps和纵深防御体系的探索实践。同时,也致力于与公司内部其他安全团队一起协同建设安全能力及系统,并将相关经验与业界交流分享。


原文始发于微信公众号(腾讯安全应急响应中心):协同共建|深入分析应用密钥安全治理之术

版权声明:admin 发表于 2022年11月11日 下午5:50。
转载请注明:协同共建|深入分析应用密钥安全治理之术 | CTF导航

相关文章

暂无评论

暂无评论...