网络安全课程论文阅读报告.doc

网络安全课程论文阅读报告Vetting SSL Usage in Applications with SSLINT通过翔实地阅读IEEE安全与隐私研讨会2015发表的Vetting SSL Usage in Applications with SSLINT 论文，对论文的相关背景、目标、创新点、实验数据、实验结论有了一定的了解，报告如下。1. 论文相关背景在2015年IEEE安全与隐私研讨会上，该篇论文得以发表。IEEE安全与隐私研讨会创办于1980年，是世界网络安全四个顶级会议中的一个，其对论文的录用率却是四个会议中最低的一个，仅为12%。本往篇论文来自于浙江大学互联网安全实验室，其主要研究包括智能手机与移动安全、基于程序语言技术的软件漏洞预测分析、软件定义网络（SDN）安全、下一代入侵检测及防御取证等。作者为何博远，在网络安全领域有较深的成就，今年还被特邀演讲嘉宾参加第四届中国互联网学术年会（ICOC2015），并作了“如何做高水平的研究和准备高水平的论文”的发言。浙江大学互联网安全实验室通过何博远博士这篇论文实现了在IEEE安全与隐私研讨会上论文发表的零突破，在大陆属第三家。论文是利用自身建立的一个SSLint对使用SSL/OPENSSL应用程序进行审查，检测出了一系列漏洞，并提出了相关建议。2. 论文主要情况介绍21论文提出的问题及解决问题的挑战主要问题：是不是有可能设计一种技术，使之可以检测到在程序中有不当使用SSL/TSL库的API。解决问题的挑战：一是如何认定正确的使用。给定一个SSL库，我们如何正确的使用模型来检测它是在被正当地使用；二是如何分析不正确的使用的技术，给出了以上正确的使用的表示方法，那又如何设计分析程序来检测不正当的使用方法；三是平台的选择。现实中有各种各样的系统，又有不同版本，包括SSL/TLS也有不同版本，如何选择最合适是个需要考虑的问题。四是如何保证精度和效率。应该设计出一个模型或者技术，必须是高效可行的，一方面不能较大影响机器本身运行，另一方面又不能很久才能出结果，这样又失去了此设计的意义。2.2 论文目标、做法、平台论文目标：保证代码质量和SSL / TLS的逻辑验证的正确性。主要做法：通过对SSL证书认证漏洞进行建模，设计并实现一个可扩展的SSLINT，使之可以自动检测SSL / TLS API错误。引入静态分析系统，使之能够在较高的效率和良好的精度下自动执行逻辑验证。平台使用了Ubuntu 12.04 官方版本。2.3论文的所做的贡献一是建立了一个基于PDG基础上，正确的使用SSL / TLS库签名模型；二是提出了图形查询匹配。 SSLINT能够为所有的SSL / TLS API执行自动化的、可扩展的图形查询，用以匹配SSL / TLS库签名，并在匹配失败时报告可能漏洞的所在。三是建立了基于SSL / TLS库的自动搜索查询程序。四是成果比较显著。从Ubuntu 12.04源代码软件包中发现了27个以前未知的SSL / TLS漏洞并进行了报告。3.相关知识综述3.1 SSL/TLS工作流程及其重要部分上图为SSL/TLS工作流程的纵览，其过程主要是：开始-全局初始化-创建SSL方法（选择协议版本）-创建证书，密钥等信息-形成完整的SSL-创建SSL接口-实行握手-验证，如果通过则进行数据交换，数据交换完成后关闭SSL并结束，验证失败则关闭SSL，并结束。SSL/TLS中最主要的两个部分为：一是主机名有效性的验证。客户端需要验证的是目标服务器发出的第一个证书。特别是客户端检查名称（CN）在X.509主题字段属性证书，其中包含证书持有人的主机名；二是证书链的有效性验证。证书链中,客户端需要验证每个证书颁发机构颁发的证书是其母证书或根证书颁发机构,和证书颁发机构证书授权问题。特别是客户端检查证书的发行人字段是否符合母公司的证书颁发机构证书或根证书颁发机构,以及是否证书颁发机构的基本属性约束的母公司证书是真实的。此外,客户端需要验证链中的每个证书是否过期,即。,检查每个证书的有效性。在一起,我们参考证书链验证和有效期的验证步骤证书验证。3.2 漏洞的产生原因及作者的一点想法当主机名和证书验证丢失时，本来是不会产生问题，但如果有攻击者使用自签名的证书代替原来的证书时，客户端就容易被欺骗并连接到攻击者。此时，如果客户机再次使用自签名证书时就会被攻击者嗅探到，但客户端运行依旧是正常的。据此，作者提出：客户端在通过认证确认服务器的主机名之前都不应该发送或接收任何应用数据，而这点在程序员设计程序时会往往会忽略，进而写出安全性较弱的软件。3.3 查找漏洞的方法作者开始提到了两种可能可行的方法。一是使用SSL / TLS库应用程序的自动化测试。此方法需要使用一种无连接的自动安装、部署以及测试用的SSL/TLS-enabled server。这看似简单，实际很难，拿邮件服务来说：如果按照此方法的话，所有的邮件客户端都要进行创建，并配置到一台特定的邮件服务器，当然，相应的服务端也要进行相应的设置。是不是换一个不同网络公司的邮箱就要重新配置。二是静态分析的办法。就是寻找应用程序是否遵循SSL/TLS软件开发规则，如果没有则可能会产生漏洞。4.论文采用的方法4.1 问题的确定设计一种可扩展的技术，使之可以检测到在程序中有不当使用SSL/TSL库的API。4.2 更高层次的检测方法前面作者有提到两种检测方法，但都不够好用，因此作者提出了一种更加高明的方法，其整体思路是:客户端软件导入一个静态的代码分析器，将软件转换为抽象表示。在使用SSL / TLS库的API时，进行指定签名,并提供签名的匹配工具,使之与软件的抽象表示签名相匹配。如果找到匹配,客户端软件认定正确, 否则,报告一个可能存在漏洞（如下图）。4.3 代码表述代码表述有很多方法，作者主要列举了以下三种：一是控制流图（CFG） 。是一个过程或程序的抽象表现。常以数据结构链的形式表示。二是数据流图（DFG）。它从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程。三是程序依赖图（PDG）。程序依赖图运用工序图示符号对程序运行的整个过程做详细的记录，并将各个API之间的依赖关系表示出来。是程序分析中最基本、最重要的分析技术，它是进行程序流程分析过程中最基本的工具。4.4 设计签名空间作者提出以下两种模型：一是利用应用程序及其中的匹配寻找来对不正确地使用SSL 的API进行建模，匹配成功的则可能就是漏洞。但本方法缺点比较明显，就是很难完整地描述一个漏洞，并且会出现因模型中漏掉了不当使用API而错过漏洞。二是对正确的地使用SSL 的API中的主机名和证书验证进行建模，再看应用代码中是不是与之相匹配，如果不匹配，则报告，即有可能就是漏洞。优点有：一是检测比较容易实现，二是即使模型不完整也不会错过漏洞，因为这样会匹配不上而报告，如果是错误报告，只需要通过分析进行修改就是。基于以上分析这，本论文就是采用了第二种方式。4.5 匹配过程（如图）图中（V1）数据（）（V2）代表一个数据依赖的节点v1to v2in一PDG。在边缘标签相匹配的直接和间接关系的可选的星号。陈述指定匹配的所有条件，包括节点和边的属性。返回谓词作为筛选器，并指定从匹配结果中返回什么。这种基于Cypher风格的抽象描述 ，使得作者提出的匹配算法可以对目标程序进行基于PDG的查询进行解释，当其没有任何值返回时，就会触发警报。4.6 匹配过程在证书验证的过程中，均会有多个API参与进来，任何一项不正确地使用这些API均有可能被攻击者利用。自动漏洞检测的第一步就是要对这类API进行建模，作者设计了一种可以将所有API类型均正确地在控制和数据依赖表中提取的签名。4.7 签名的开发在所有会话中找出其中的哪些证书是必须进行检查的，这样数据从初始化API调用（如ssl_new()）到发送/接收API调用（如ssl_write()和ssl_read()）的依赖关系就会准确地表现这些会话。如下表示，Query0为：有了以上的query0结果，就可以进行参数化查询，对图4中的所有依赖关系进行匹配。M和N是Query0的结果,插入到Query1和Query2,这样就能确保程序只会匹配到一个与特定会话相关的API调用。另外，因为OpenSSL有两个验证逻辑模式，所以它需要两个查询使之匹配 。而GnuTLS,只有一个,因此它只要一个查询。5.实施5.1 平台选择使用Ubuntu 12.04，主要考虑是：OpenSSL库被列表在如libssl2中，这样就只要对其进行一个小的手工注释，就可以搜索所有的包的属性，并自动列出依赖于OpenSSL的程序。5.2静态分析5.2.1 核心：利用CodeSurfer进行静态分析。CodeSurfer本来是一个理解C/C+的一个工具，但它也可以作为一个高级分析的平台。它可以生成一系列的程序表示呈现给用户，包括抽象语法树(AST),控制流图(CFG)和程序依赖图(PDG)，以供做进一步的分析。5.2.2 自动化：利用Ubuntu的软件包管理器生成的一个完全自动化的接口，加上apt-get -y build-dep Package Name和apt-get source Package Name -compile命令，即可解决软件库中任意包架构的依赖关系及其配置。5.2.3库建模：库对函数中的依赖特性进行建模。在CodeSurfer基本模型基础上，为SSL / TLS库函数添加自定义模型的证书和主机名验证。5.3手工审计检验SSLINT报告的漏洞，采用了动态的方法：在检验证书验证上：主要检查证书是否过期。简单地改变系统时间，使得所有证书均过期, 如果一个SSL连接还能成功，则考虑客户端容易MITM攻击。在检验主机名验证上：使用Wireshark作为一个嗅探工具来确定客户端和服务器之间 建立的SSL连接是否没错。6 结果主要是在使用OpenSSL或GnuTLS 库的软件中利用SSLint查找漏洞。总共检查到了485个软件包在使用这些库，分析了这些中超过2200万行C/C+代码，对其中的381个包创建了PDG，另外104个因为内存溢出而失败，每个匹配分析的时间在120秒以内，共发现了27个未知的漏洞，如下图：7. 论文的局限性 一是静态分析的准确性。静态分析可能会导致出现真的认成假的，假的认成真的。二是聚合变量问题当数组、结构等组成模块化时，也可能出现假阳性。三是指针分析问题。主要是因为CodeSurfer采用流不敏感，导致错报。四是重用内存问题。共享内存的多种变量之间的依赖性没有被建在一个模型中，会导致出现假阴性。五是定制OpenSSL证书问题。OpenSSL也为开发者提供了一个自定义认证验证过程的接口的回调函数，这是SSLint无法对此进行建模的。六是可伸缩性问题。由于CodeSurfer生成PDG包的时候，如果超过10万行代码时就可能导致内存溢出。七是软件的可配置性问题。有时候客户对一些SSL漏洞是不怎么在乎的，但SSLint不能进行配置。八是未定义函数问题。如果遇到未定义过的函数，也可能会出现假阴性。8.论文结论作者针对OpenSSL和GnuTLS库制作了两个签名补丁，评估了381个软件包，确定了27个未知漏洞，将结果发给开发者后，收到了14个确认，其中4个已经修复。对于没有收到确认的漏洞进行了动态审计，结果表明，这些漏洞可能导致使用人都受到来自中间人的攻击。9. 我组组员的几点思考一是指导思想重要性。本篇论文思想看似简单，但实现的成果却非常巨