基于STRIDE威胁建模的安全通信问题

基于STRIDE威胁建模的安全通信问题

本文是以美创安全实验室在深度了解STRIDE威胁建模的基础上，结合当今普遍关注的安全通信的痛点，对HTTPS这一安全通信的解决方案进行深度剖析集成而来。

0x00 前言

STRIDE是微软开发的用于威胁建模的工具，在介绍威胁建模之前，我们需要先行了解两个重要的概念：安全属性与安全设计原则。充分理解后我们将结合安全通信的具体解决方案HTTPS协议，从威胁建模的角度进行具体分析。

0x01 安全属性与安全设计原则

说到安全属性，脑海中不约而同的蹦出三个字母 “CIA” ，这里的CIA指代的是Confidentiality （机密性）, Integrity （完整性）, 和 Availability （可用性）三个英文单词的首字母。
• 机密性：保证机密信息不被窃取，窃听者不能了解信息的真实含义。
• 完整性：保证数据的一致性，防止数据被非法用户窜改。
• 可用性：保证合法用户对信息资源的使用不会被不正当的拒绝，如DOS攻击。
再说安全设计原则，虽然市面上目前并没有统一的标准，但我们仍列出以下通认的十点。

• 最小攻击面
• 默认安全
• 权限最小化
• 纵深防御
• 失败安全
• 不信任第三方系统
• 业务隔离
• 公开设计
• 简化系统设计
• 使用白名单

1.最小攻击面
我们在一些web安全防护建议中经常会提到“关闭不必要对外开放的端口”，这就是最小攻击面的一项措施。在网络攻击的生命周期中一个重要环节就是信息收集，这个环节往往也是黑客耗费时间精力最大的一个环节，对最终黑客的攻击成果起了至关重要的影响，越是有经验的黑客，会花更多的时间和精力在信息收集上面，这步做的好，后面就能一击命中。当我们最小化攻击面这个安全原则做的好，就会大大影响黑客信息收集的成果，最终挫败黑客的攻击。

2.默认安全
系统的默认配置会带来安全问题，比如一些硬件设备或软件是存在默认密码的，如果没有及时修改，将有很大可能被暴力破解。

3.权限最小化
当我们做产品维护的时候，为了寻求方便总是一个root账号搞定所有的系统，虽然维护方便了，但当黑客攻破了任一系统的时候就直接获取了最高权限

4.纵深防御
所谓治标不治本，不要把所有的精力只用在一点的防御上，一点防御的再强，也可能会出现0day漏洞，无法保证100%的安全。 层层设防，多样化，多层次、纵深的防御措施。攻破一层或一类防护后，无法破坏整个信息基础设施或应用系统。

5.失败安全
当异常发生时，异常处理代码处理不当，可以导致意想不到的问题，比如权限提升、信息泄露等。这也是不懂安全的开发人员经常忽视的，而在黑客攻击kill chain的信息收集阶段，又是被黑客经常利用的，黑客对攻击目标故意输错url参数或者路径、构造异常post数据，导致服务器出错，如果开发人员对这里的错误处理不当，就会导致敏感甚至重要的信息被泄露，为黑客的下一步攻击提供重要的线索和思路。

6.不信任第三方系统
现在每一个产品的开发总是存在大量的合作商，很多系统越来越复杂，很多都是模块化、组件化的，需要引入第三方的模块或者和第三方的业务系统对接并使用其提供的数据，我们无法掌控第三方系统的安全性，如果其存在漏洞被攻击，需要保证我们自己的系统不会因此而受到影响。

7.业务隔离
简单一句话就是不要把所有鸡蛋都放在一个篮子里，不至于一个系统被攻破就让黑客拿到了一把“万能钥匙”，可以操作所有的业务功能。

8.公开设计
类似于加密算法，像DES,AES,RSA等算法至今还被主流使用的依据就在于开放性，将加密过程公开经过无数人的千锤百炼最终成为所有人都认可的算法。其主要的思想在于要从设计上就让黑客无懈可击，是一种思想上的转变。

9.简化系统设计
随着信息技术、互联网技术的高速发展，系统功能变得强大的同时，系统也变得越来越复杂。越复杂的系统就越容易出现漏洞，特别像是逻辑漏洞这种，漏洞没有固定的模式、固定的特征，很难通过安全设备来防御。复杂度的提高通常也会导致攻击面变大。所以我们尽量简化系统设计，当有多种系统设计方案时，应该尽量选择最简单的那种方案。

10.使用白名单
与白名单相对的就是黑名单，白名单机制可能导致“误杀”，而黑名单机制可能导致“误放”。在平衡“误杀”与“误放”时，通常更倾向于“误杀”，因为一旦“误放”我们系统就被黑客攻破，而“误杀”带来的其他问题可以设计诸如手动添加白名单等机制来解决，同时白名单机制还有可能能够防御各种未发现的安全隐患。

0x02 什么是威胁建模？何时做威胁模型？

威胁建模是一种结构化方法，用来识别、量化并应对威胁，利用抽象的方法来帮助思考风险。威胁建模允许系统安全人员传达安全漏洞的破坏力，然后定义防范或减轻系统威胁的对策，并按轻重缓急实施补救措施。

不像诸如渗透测试等是在已经完成的系统上进行，威胁建模是在设计阶段就开展。 只有在设计阶段，才有最大的弹性空间可进行威胁消除更改。最理想的结果就是通过设计来消除潜在威胁。这样做比添加安全防护功能、进行测试更加容易。 因为消除不是随时想做就能做到。当产品日益成熟，消除威胁将更加困难，相比于开发早期采用的威胁建模，这需要更多投入与更高难度的取舍。

0x03 STRIDE威胁建模

STRIDE威胁模型的流程大致是：应用程序建模、枚举威胁、缓解威胁、验证缓解措施。

STRIDE把威胁分成如下6个维度来考察：
• Spoofing（伪装）
• Tampering（篡改）
• Repudiation（抵赖）
• Information Disclosure（信息泄露）
• Denial of Service（拒绝服务）
• Elevation of Privilege（提升权限）

STRIDE威胁模型几乎可以涵盖目前绝大部分安全问题。并且有着详细的流程和方法。每一个维度都对应的一个安全属性，也就是相应的安全诉求。

0x04 通信安全的安全诉求

将威胁模型对应到安全数据通信上，前四个对我们来说更具有研究意义，总结一下，安全通信的诉求包括：

1. 完整性：通信的内容信息必须要完整，不可被篡改掉或者存在数据丢失。
2. 机密性：通信的内容必须要得到有效的隐藏和保护，避免被泄露到第三方。
3. 认证性：包括实体认证和消息认证，其中实体认证是指通信的发送方和接收方是可信的未被假冒的，而消息认证是指消息是由认证的实体用户发出的，不是被仿冒者发出的。
4. 不可抵赖性：通信的数据携带有实体特质、不可被模仿复制的信息，确保通信数据是可确认的实体发出的。

0x05 常见的加密算法

为了实现上面列出的4点安全诉求，我们需要引用一些通信加密算法。之后我们会使用这些算法实现安全通信的方案。
加密算法大体上可以分为三类：对称加密，非对称加密以及信息摘要

对称加密：

对称加密双方的通信密钥是统一的，特点是加解密效率高，而安全性就稍微弱一些。常见的算法例如AES，DES

非对称加密：

特点是它拥有两个密钥，任意一个密钥都可以对信息进行加密处理，但是解密就需要用到另外一个密钥才能解析出正确的明文，安全性较高，但是效率低一些。常见的算法例如RSA，DSA。

信息摘要：

数据摘要算法是密码学算法中非常重要的一个分支，它通过对所有数据提取指纹信息以实现数据签名、数据完整性校验等功能，由于其不可逆性，有时候会被用做敏感信息的加密。特点是唯一性，不可逆，常见的算法例如MD5，SHA1。

0x06 HTTPS安全通信设计方案

至此我们已经了解了足够的相关知识，下面我们根据上述的安全诉求来拆解HTTPS协议。

完整性
完整性是靠信息摘要来保证的，将算出的摘要附到明文后，万一明文被修改，只要使用同样的算法得出明文摘要和原始摘要进行对比，不一样就证明被篡改。

“通信消息+信息摘要+对称加密=数据验证码“的做法，就是通信中常见的MAC（Message Authorization Code，消息认证码）的实现 。

机密性
机密性在于通信的数据是否被加密，一般频繁的数据加解密，我们采用的是对称加密算法，对于服务器的消耗是很低的，这里的对称密钥我们称之为会话密钥(Session Key)。为什么称作会话密钥? 是因为每次建立通信连接都是随机生成一个对称密钥。会话通信既然是对称加密，那它的安全性是主要在于两点：

1. 使用的对称加密算法是否安全，会不会被破解
2. 对称密钥的交换过程是否安全，会不会被窃取

至于第一点，我们暂不考虑。第二点对称密钥交换的安全是通信的关键，密钥要是在传输的过程中被窃取，那他能起到的安全作用微乎其微。所以为了保证密钥交换的安全，我们采用了公私钥交换体系，下面是SSL/TLS协议握手建立连接的交换密钥简化过程。

在上面的第四步，通过随机数x，y，z生成了会话密钥，但是我们发现在前两步，x和y在传输过程中都是暴露的，因此会话密钥的安全性在于第三步的z的交换。

B使用了非对称加密算法，生成了一对公私钥，公钥交给了A，自己持有私钥。在密钥交换的过程中，A生成随机数z，通过B的公钥进行加密，B接收到数据，使用私钥进行解密得到z，从而保证了z的安全性，最终保证了会话密钥的安全性，防止在通信过程中被窃取。

不可抵赖性
在经过完整性和机密性的加持后，通信数据是否就真的安全了？还是有风险。在机密性讲解过程中，我们知道会话密钥是通过公私钥的方式进行交换的，其中A用到了B的公钥，漏洞就在这：A获得了B公钥的过程是安全的吗？这存在被劫持的可能性（例如DNS劫持），A获得的公钥不一定是B的，A可能会被伪造的B所欺骗。下图是利用这个漏洞进行的中间人攻击图：

通过劫持的方式，我们将随机数z在中途获取了，之后的加密通信基本上就是公开了，数据可以被随便修改，这就是http容易被DNS劫持的原因。
这个问题的本质是A无法验证消息的来源是B，这就涉及不可抵赖性。不可抵赖性的一般做法是使用数字签名，保证A获取的是B公钥，需要对B的公钥进行数字签名。

认证性
对应到上面的中间人攻击，虽然我们提出了数字签名的解决方案，但仔细一想，假如使用数字签名的话，那么B需要用自己的私钥对自己公钥进行签名，然后将签名附到公钥后面一起发给A。类似如下图：

由于公私钥可以互相加解密，中间人完全可以同时替换公钥和数字签名完成伪装。为什么会出现这种问题呢，数字签名用来识别消息篡改，伪装以及防止抵赖，但是我们又必须从没有被伪装的发送者得到没有被篡改的公钥才行，所以解决这个问题，就一句话：

在公钥传输不可信的情况下，数字签名这种证明身份的事情，不能让消息的双方来做。

所以，对于数字签名，我们需要找一个可信的第三方，这就涉及了认证性。

CA证书
认证性和不可抵赖性，他们相互依存，都处在HTTPS协议中的同一组件：CA证书
CA (数字证书认证机构)：负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。

其中数字签名是由CA机构的私钥对证书上的信息(包括公钥)进行加密生成的

证书主要包括5个部分：

1. 签发者信息CA
2. 使用者信息B
3. B的密钥信息
4. B的公钥
5. 数字签名

0x07 证书签发与证书链

如果我们有一个网站需要使用https，则需要申请证书，以B为例，申请证书需要两步：

1. 生成请求信息：

2. 生成签名合成证书：

通过以上的过程就生成了一个合法的证书，但是真实的情况下，CA不可能随便给每个用户签名的，因为CA的私钥是非常机密，随便签发增加泄露的可能性。既然自己干不了，那就找 “代理商”，进行分级签发证书。

证书链
CA为了减轻自己的工作，同时也是保护私钥的机密，打算招两级代理 A与B（也可以多招几级），A是一级代理，B是二级代理。这个时候C需要生成合法的证书，直接找B即可，每一级的签发流程如下：

反向校验
在上图中，C找到B生成了证书，之前我们知道要验证证书中公钥的合法性，需要去找证书的签发者进行解密校验，同样道理，证书链也是这个流程，只不过是找了多级，C找B，B找A，A找CA。

证书链位置
SSL/TLS协议
证书链的存在就是为了解决B的公钥传输的可信问题，B其实就是我们的网站（服务端），A是使用的浏览器（客户端）。证书链的位置如下：

以百度网站的证书为例，点击地址栏上的锁，可以看到证书及证书链

潜在的风险
通过上面的方式，完成了数据通信间的各种安全诉求，整个总体的方案成为了HTTPS协议的基础，虽然整个方案已经接近完美，但是依然存在风险。而这风险恰恰出现在“人”身上，具体来说就是证书链上存在问题。

1. 证书链中CA机构的保密性最高，但是他的代理不一定了，只要黑客渗透到他的代理商里，窃取私钥进行签发证书，就可以骗过证书链的检测。
2. 供应链攻击：比如浏览器被黑客内置了一些自签名的根证书，用户下载恶意的浏览器，通信都是不安全的。