Question

在企业内网，除了前面讲的 AD、邮件、VPN、堡垒机外，更多的是各种各样的应用系统。由于只对内部员工开放，所以往往安全重视程度也不高，容易被别有用心的人利用，可能被人拿来当跳板，也可能被人盗取数据。

13.6.1　弱口令

在企业内网，弱口令是永远无法避开的话题。严格意义上讲，弱口令也是一种漏洞，此处单独拿出来讲只是其和常规漏洞还有一定的区别。存在弱口令的主要有三种场景：

·网络设备或终端、服务器的登录用户和密码，比如 Telnet、RDP、SSH、VNC、Radmin 的用户密码。

·各种 Web 应用的内置密码，内网大量应用的内置密码，比如网管系统、iLO、HMC、Tomcat 管理后台等。

·各种服务可能配置成弱口令，比如 FTP、MySQL、SQLServer 等。

而弱口令按密码不同来分，可以分为空口令、默认口令（比如 admin、admin888、test、password)、简单密码（比如 123456、12345678、888888）、网上泄露库的 top1000（比如 woaini1314、5201314、123456a、zxcvbnm）以及适当变化的字典库（如 Baidu123、Baidu@2018）等。

发现弱口令最有效的方式是直接扫描。X-Scan 虽然年代久远但偶尔还看到有人在使用，Medusa、Hydra、Ncrack 在支持类型上比较丰富值得推荐，在 Web 暴力破解领域 Burp Suite 也经常会被渗透测试人员使用。有条件的企业可能还针对企业内部场景定制开发自己的弱口令检查工具，比如当扫描到 Web 页面有登录、login、Management 等字样的时候会自动尝试暴力破解，发现图片验证码的时候自动调用图片识别程序等。商业产品 Nessus 也具备弱口令扫描功能，图 13-8 是其使用 Hydra 进行暴力破解扫描的插件。

图 13-8　Nessus Scan Bruteforce2 Small

如何消除弱口令，除了常态化的扫描、跟进修复外，应该从另外的角度来考虑这个问题，此处提出以下建议：

·针对网络设备，建议使用类似 ACS+Token 的解决方案，静态用户保留最高权限和只读账号，而高权限静态用户登录则需要告警，平时不允许使用，只有应急情况才可以使用。

·针对 Windows 机器，在域里统一设置安全策略，强制要求密码复杂度及过期时间；有些企业通过 LDAP 的方式来管理 Linux 机器，也可以做一些相应的设置。生产网更应该严格对待，统一要求都接入堡垒机，通过堡垒机的上收口令和自动改密码功能来管理，用户自动登录无需掌握密码，应急使用的高权限账号平时则不允许使用，有使用则进行告警及审计。

·针对 Web 应用系统，建议统一接入 SSO 系统，而 SSO 系统则可以采用双因素认证等来实现；有条件的企业更应该考虑使用不需要密码的登录，比如通过 APP 扫码登录，体验会更好，用户也不需要掌握密码。

·对于一些比较危险的服务，如 FTP、MySQL、Redis、Radmin、VNC、SVN、Git、Rsync，能不开就不开，必须要开的尽量做访问来源限制，即使存在弱口令也只在有限范围内使用。

·对于企业内网大量的应用管理后台，建议在上线前做好管控，梳理常见的问题并做出明确的要求，比如 Tomcat、phpMyAdmin、JBoss 等管理后台界面。

13.6.2　漏洞发现

根据发现方式的不同，我们把漏洞分为三类：基于主机层面的漏洞（系统漏洞），基于应用层面的常规漏洞（比如 Web 漏洞），基于应用程序内部逻辑的漏洞。

系统漏洞包括操作系统本身的安全漏洞，以及运行在操作系统上面的应用程序（例如 IIS、Apache、Ningx、Tomcat、MySQL）的安全漏洞。要发现此类漏洞，可以采用诸如 Nessus、OpenVAS 之类的扫描器。Nessus 的 Discovery 包括了主机发现、端口扫描、服务发现相关设置，Assessment 选项包括了常规设置、暴力破解、Web 应用、Windows、Malware 相关的配置，还可以提供登录相关的凭证便于做侵入式登录扫描。大量的 Plugins 便于用户自定义选择，也可以针对某些特定漏洞进行专项扫描，比如“永恒之蓝”的 MS17010 漏洞。如果扫描处在上线前的阶段，建议尽量做侵入式扫描，即登录到服务器上进行扫描。如果内网机器数量众多，需要部署多台 Nessus 服务器，采用集群模式进行扫描。扫描自动化做得好的企业，往往会做一些定制开发，比如调用 Nessus 接口定期扫描并导出结果，然后按漏洞级别分类并纳入漏洞管理系统以便统一跟进。

应用层面常规漏洞包括 SQL 注入、XSS 攻击、文件上传、文件下载、信息泄露、框架注入、XXE 注入、CSRF、SSRF、命令执行、弱口令等。一般企业会采用 AWS、IBM Appscan、HP WebInspect、Nikto 等商业或开源扫描器开展漏洞扫描工作。这些扫描器各有特色，有的还包含一些辅助工具，方便开展渗透或漏洞确认工作。由于这块内容网上有非常多的参考资料，而且白帽子也非常多，招聘安全人员很容易就能覆盖到这块能力，所以这里就不花太多篇幅进行阐述了。需要注意的是，除了主动扫描，还可以结合被动扫描的思路，比如获取真实的访问日志、获取网络流量提取 HTTP 请求内容等，再提交给扫描器进行扫描，以弥补主动扫描的不足。

相较前两种漏洞来说，应用逻辑漏洞难以直接用扫描工具发现，更多需要人工介入，结合使用 BurpSuite、Fiddler 等辅助类工具对应用系统各种内部逻辑进行测试。逻辑漏洞很容易在身份认证、业务流程、API 接口调用等过程中产生，身份认证模块就涉及口令破解、验证码、撞库、密码找回、认证时效等问题；业务流程中则依据不同的业务场景会有不同的功能，比如订单篡改、一致性校验、重放攻击、输入合法性等；API 接口调用简化了系统架构，但也容易存在不认证、不限制访问等问题。简单举个例子，某 P2P 网站提供通过手机找回密码的功能，如图 13-9 所示。

图 13-9　找回密码界面

初看没什么毛病，要手机号、短信验证码、身份证后 6 位，比一般的网站找回密码只需要短信验证码验证感觉还更安全。在应用里的逻辑一般会是这样：输入手机号的时候，先会校验你是否注册过，注册了才会发送短信验证码。通过查看网页源码可发现点击“获取验证码”会触发一个 Ajax 请求，代码逻辑如图 13-10 所示。

图 13-10　找回密码代码逻辑

可以直接在浏览器按 F12 再来操作，会发现有 POST 请求一个生成验证码的 API 接口，控制不严的情况下可以直接在浏览器地址栏构造 URL 触发 GET 请求，也能看到返回值。如果这个接口未做限制，那丢到 Burp Suite 或者写个脚本很快就能将该网站所有注册手机号遍历出来。

前两种漏洞通过扫描器能部分覆盖，而后一种漏洞则基本上需要靠人工介入，那企业需要考虑，用什么样的扫描器？扫描周期如何？人工介入的范围有哪些？表 13-2 可供参考。

表 13-2　漏洞扫描信息表

发现漏洞只是第一步，后面还有大量的沟通协调工作跟进及漏洞修复确认工作，做得不好的企业往往靠人工维护 Excel 表格跟进，做得好的企业往往漏洞管理系统直接与内部工单或 ITIL 系统对接。漏洞的修复一般有几个优先原则：

1）暴露在互联网上的漏洞，必须第一时间发现与修复，对于未及时修复的，需要进行升级处理（这里的升级是指向更高层级的人通告此漏洞，比如抄送领导）。

2）高风险特别是可以直接拿到权限的漏洞，比如 MS08067、MS17010、Struts2 各种远程执行漏洞等，也需要优先跟进并修复。

3）内部网络重要系统的漏洞，比如人力资源、OA、邮件等，也需要优先。

4）其他内部不重要的系统漏洞，按常规方法跟进处置，超过多少天的该升级到什么级别，按规章处理。

注意：

有时候扫描器报出来的高风险漏洞，漏洞管理员需要经过适当评估才能定级跟进。比如，一个内部 Apache 版本过低报出来 High 风险可能不是合适的，还有一些本地提权漏洞，即使有一些条件限制的可能也会报 High，处理不好可能会遇到运维人员的“挑战”。

13.6.3　SDL

安全开发生命周期（Security Development Lifecycle，SDL）是由微软最早提出的从安全角度指导软件开发过程的管理模式。SDL 是一个安全保证过程，其重点是软件开发，它在开发的所有阶段都引入了安全和隐私的原则。SDL 不是一个空想的理论模型，它是微软为了面对现实世界中的安全挑战，在实践中一步步发展起来的，自 2004 年起，SDL 一直都在微软全公司强制实施，其步骤包括培训、需求、设计、实施、验证、发布、响应七个环节，可以访问微软官方网站获取更多信息。相对于微软的 SDL，OWASP 推出了软件保证成熟度模型（Software Assurance Maturity Model，SAMM）。

SAMM 与 SDL 的主要区别在于：SDL 适用于软件开发商，他们以贩售软件为主要业务；SAMM 适用于自主开发软件的使用者，如银行或在线服务提供商。软件开发商的软件工程往往较为成熟，有着严格的质量控制；而自主开发软件的企业组织，则更强调高效，因此在软件工程的做法上也存在差异。

SDL 在国内企业难以落地，主要是企业面临以下诸多问题：

·缺乏安全意识教育导致的安全意识不足。

·缺少安全编码标准和规范。

·系统设计以完成功能为主导，不考虑安全问题。

·敏捷开发意味着频繁的迭代更新发版本，微软 SDL 较为厚重。

除了以上因素外，SDL 在我国还有一些水土不服的情况，比如，微软 SDL 非常强调隐私保护，而在国内企业更多在敏感数据防泄露上做文章，很难把隐私保护放到同等地位。当然，随着《网络安全法》《欧盟一般数据保护法（GDPR）》的逐步实施，会有一定的改善空间。国内推出自己的 SDL 的企业主要是互联网企业，影响范围相对有限，金融行业有自己的一些特征，也不能照搬，基本是各自摸索。推行 SDL 需要循序渐进，如果以往安全人员只是在最后上线阶段做一些上线前扫描，那现在要求一开始就介入需求设计阶段可能也不太现实，至少是推进起来难度不小。SDL 可分为需求分析与设计、开发、测试、上线、运营几个阶段，下面逐一阐述。

1.需求分析与设计阶段

这个阶段有不少沟通工作，项目经理、产品经理甚至需求方都可能会涉及，在梳理各开发条线的项目情况后，需要给出相应的建议。在这里，一份 Checklist 可能会很有帮助。美的金融科技就发布了一个金融科技 SDL 安全设计 Checklist，内容涵盖输入验证、输出编码、身份认证、异常处理、会话管理、访问控制、接口调用、权限控制、敏感信息、运行环境以及常见 Web 安全防护等方面，相对比较完善，值得推荐。其 URL 地址：

https://mp.weixin.qq.com/s/MR3SmOLj834LK4RBMcZ2pg

注意：

Checklist 并不一定能覆盖到所有场景，比如，有的项目往往会使用一些第三方的软件，可能是网上某个开源框架或库，也可能是某个商业公司的组件。所以在实际过程中，还会依靠安全工程师的经验做出判断，对这种第三方软件进行适当的评估才行。

2.开发阶段

在这个阶段，一般企业都会有一个应用安全开发标准的文档，而作为规范的配套，最好还提供一些技术类的解决方案，比如安全函数库或安全框架。最后，为了确保编写的代码符合规范，还需要进行代码审计，比如，规范里要求不允许使用什么函数或者不允许使用什么框架，通过简单的代码审计规则就能发现违规行为。

在实际工作过程中，很多开发人员甚至安全人员只会依据类似《XX 开发安全标准》《XX 开发安全规范》来干活，却不知道为什么要关注这样的风险以及对应的安全措施，久而久之习惯使然，容易变成“过度的安全设计”。因此，“知其然且知其所以然”，从风险的角度去考虑而非机械遵守，是开发人员需要具备的素质。

3.测试阶段

项目开发完了会转到测试环节，传统的测试人员会对着设计文档进行各种测试，包括白盒、黑盒、单元测试、集成测试、功能测试、性能测试等。在这个阶段，我们需要引入一个安全测试，即专门针对安全性的测试。

在开始动手测试前，业界有一些通用的威胁建模方法供我们参考，比如，源于微软的 STRIDE，它从 6 个维度来考察系统设计时存在的来自外部威胁的风险点，分别为：

·Spoofing（假冒）。

·Tampering（篡改）。

·Repudiation（否认）。

·Information Disclosure（信息泄漏）。

·Denial of Service（拒绝服务）。

·Elevation of Privilege（提升权限）。

用 STRIDE 进行威胁建模，以保证系统的几个安全属性与之对应：身份认证、完整性、不可否认性、机密性、可用性、授权，对应的解释及示例如表 13-3 所示。

表 13-3　STRIDE 威胁建模

在威胁建模的最后阶段，还要根据威胁所造成的危害对威胁进行评价，这样企业就可以排出优先级，先解决风险最大的威胁再解决其他的威胁。微软公司使用 DREAD 模型来协助这个计算过程，通过询问下列问题就可以得到给定威胁的风险评价结果：

·潜在损失（Damage Potential）。如果缺陷被利用，损失有多大？

·重现性（Reproducibility）。重复产生攻击的难度有多大？

·可利用性（Exploitability）。发起攻击的难度有多大？

·受影响的用户（Affected Users）。用粗略的百分数表示，有多少用户受到影响？

·可发现性（Discoverability）。缺陷容易发现吗？

可以利用上面的几项来评价每一种威胁，也可以自己进行扩展，然后给每一项进行打分（如 1 分为低，2 分为中，3 分为高），最后计算出总分（如结果范围为 5~15 分，设定规则为总分 12 以上为高危，8~11 分为中危，5~7 分为低危），如表 13-4 所示。

表 13-4　安全威胁评分表示例

除此之外，OWASP 组织官网上还介绍了 Trike、AS/NZS 4360、CVSS、OCTAVE 等，不再一一列举。

安全测试人员的工作，和漏洞扫描人工渗透的工作内容有一定的相似度，但不完全一样。测试人员通常掌握设计说明书、源代码、数据库表结构等内容，更容易深入理解应用的不同功能，如果能站在攻击者的视角去思考如何攻击目标，就更有优势了。优秀的安全测试人员，除了要利用已有的思路或自已积累的各种经验，还需要时刻关注外界新的攻击方式，说不定在某个节点会有新的发现。

4.上线阶段

在这个阶段，大部分安全团队的工作压力并不大，这是因为：操作系统、服务端的配置基本上都已经做了基线配置和安全加固；在这个阶段，安全团队有一个权限—对发现有问题的应用不允许上线。

5.运营阶段

在这个阶段，更多是常态化的工作，包括扫描、渗透，也包括日常的安全监控，一旦有安全事件，需要进行根因分析，并从中吸取教训，对日后的工作进行针对性的改进。

最后补充一点，不是所有应用都是同一个标准，企业要结合自身实际情况做一定的调整，比如，哪些应用是对所有互联网开放访问的，而有些应用只允许内部员工访问；哪些应用包含有大量客户资料或交易信息，而哪些没有，肯定要在以上所有阶段区别对待。