分类 企业安全 下的文章

大力出奇迹:Web架构中的安全问题一例

前言

在一次对线上业务的测试中,遇到过一个奇怪的问题,经排查和LVS以及后台应用服务的同步有关,现在分享如下;并对web架构的基础知识和个人经验认为可能存在的问题做简单的总结。

现象

  1. 爆破接口本来是做了防护的,即当某IP的请次数超过一定的阀值后返回403(正常请求返回的是200),但是大量的多线程请求中出现了某些请求仍然正常的情况。如图:

burp.png

  1. 在某次对另一个业务的测试中,也发现了类似的问题。某登录接口,多次尝试后开始要求图形验证码确认,但当用户多次点击按钮请求,图形验证码要求却消失了。

原因

经过运维的排查,发现根本原因是后端多台服务器配置不一致导致的,比如有三台服务器的代码是最新的,有防护策略,而有一台服务器的代码没有得到更新,没有防护策略,当多次请求的时候,LVS将流量指向了没有启用防护策略的服务器,响应包也就没有要求图形验证或响应正常,从而导致了多个请求中存在了无需验证的数据包。

测试方法和利用

多线程、高并发请求;这些大量异常包中的正常请求也是有可能被利用的,比如,如果LVS是轮询算法,即每N次就有一次可利用的请求。

总结

现在的web应用早已不是单台服务器的时代了,往往都有一个庞大的web架构来支撑一个应用。个人学习了一下相关基础知识,并根据经验罗列了一下这些架构中可能存在的问题。

习惯了通过思维导图来记录知识,高清大图请点击或者右键查看:

xmind.png

Xmind源文件请访问Github获取。

互联网企业安全高级指南读书笔记

前言

春节前花了几天时间,终于把这本书完整读完了。受益匪浅!

这是市面上第一本从总览的视角陈述甲方企业安全建设思路与框架,描绘企业内部信息安全全貌的书。

除了“战略”层面的全局观,这本书还难能可贵的深入了一些技术细节,在“战术”层面也不乏很多干货。

为了帮助记忆和理解,我基本上每章都用思维导图的方式整理了笔记。

这些笔记并非对全书的完整总结,亦非斗胆点评,仅作为个人理解和梳理思路的笔记之用。

第三章 甲方安全建设方法论

第三章.png

第四章 业界的模糊地带

第四章.png

第五章 防御架构原则

第五章.png

第六章 基础设施安全

第六章.png

第七章 网络安全

第七章.png

第八章 入侵感知体系

第八章.png

第九章 漏洞扫描

第九章.png

总结

总得来说,互联网企业和传统行业企业在安全建设的思路上,殊途同归。

不同点

  • 扩展性

互联网企业的业态具有大流量、高实时性、海量用户、海量数据的显著特征。由于流量太大,所以“两个海量”的特征与传统企业非常不一样。同时,互联网企业的线上业务就是钱,这样就决定了高实时性是必保的点。传统企业的线上业务即便是挂了,在一定时间内也不会直接影响生产力。

为了应对一大一高两个海量,传统安全企业的解决方案存在先天不足:无法无缝横向扩展。这就导致了互联网企业更多的选择自研防护手段。

互联网企业对安全防护手段的要求是,低维护成本+高扩展性。而传统企业呢,更看重的是易配置+防护全面。

  • 自研能力

这一点非常容易理解。互联网企业拥有足够的薪资吸引高端人才,所以才能支撑自研的需求。而传统企业除了保护线上业务外,还需要应对合规、内部防泄密等安全外延业务诉求。自身也不具备自研的能力。

相同点

  • 分层防御+威胁感知

无论是线上业务防攻击,还是内部治理防泄密,都必须依赖分层设计的多重防御措施交互实现立体化、深层次的防御能力。应对瞬息万变的攻击特征,必须具备第一时间感知威胁发生的能力。所以,无论是威胁情报,还是大数据分析,这些技术在不同业态的甲方企业内都会有持续的生命力和价值点。综上,虽然业态不同,但核心思想还是相通的。

另外,作者赵老师在书中提到,传统企业迫于提高生产力、提高效率的压力,业态向互联网转化的速度会越来越快。所以,互联网企业在线上业务安全防御方面的经验,领先传统企业十年,此言不虚。安全的本质始终没有变,就看在不同环境下怎么玩的踏实,怎么玩出精彩。

与君共勉。

企业常见服务漏洞检测&修复整理

前言

12月份要要给公司同学做安全技术分享,有一块是讲常见服务的漏洞,网上的漏洞检测和修复方案写都比较散,在这里一起做一个整合,整理部分常见服务最近的漏洞和使用上的安全隐患方便有需要的朋友查看。如文章有笔误的地方请与我联系WeChat:atiger77

目录

1.内核级别漏洞

Dirty COW

2.应用程序漏洞

Nginx
Tomcat
Glassfish
Gitlab
Mysql
Struts2
ImageMagick
...

3.应用安全隐患

SSH
Redis
Jenkins
Zookeeper
Zabbix 
Elasticsearch
Docker
...

4.总结

漏洞检测&修复方法

1.内核级别漏洞

Dirty COW脏牛漏洞,Linux 内核内存子系统的 COW 机制在处理内存写入时存在竞争,导致只读内存页可能被篡改。

影响范围:Linux kernel >= 2.6.22

漏洞影响:低权限用户可以利用该漏洞写入对自身只读的内存页(包括可写文件系统上对该用户只读的文件)并提权至 root

PoC参考:

漏洞详情&修复参考:

这个漏洞对于使用linux系统的公司来说是一定要修复的,拿web服务举例,我们使用一个低权限用户开放web服务当web被攻击者挂了shell就可以使用exp直接提权到root用户。目前某些云厂商已经在基础镜像中修复了这个问题但是对于之前已创建的主机需要手动修复,具体修复方案可以参考长亭的文章。

2.应用程序漏洞

Nginx

Nginx是企业中出现频率最高的服务之一,常用于web或者反代功能。11月15日,国外安全研究员Dawid Golunski公开了一个新的Nginx漏洞(CVE-2016-1247),能够影响基于Debian系列的发行版。

影响范围:

  • Debian: Nginx1.6.2-5+deb8u3
  • Ubuntu 16.04: Nginx1.10.0-0ubuntu0.16.04.3
  • Ubuntu 14.04: Nginx1.4.6-1ubuntu3.6
  • Ubuntu 16.10: Nginx1.10.1-0ubuntu1.1

漏洞详情&修复参考:

这个漏洞需要获取主机操作权限,攻击者可通过软链接任意文件来替换日志文件,从而实现提权以获取服务器的root权限。对于企业来说如果nginx部署在Ubuntu或者Debian上需要查看发行版本是否存在问题即使打上补丁即可,对于RedHat类的发行版则不需要任何修复。

Tomcat

Tomcat于10月1日曝出本地提权漏洞CVE-2016-1240。仅需Tomcat用户低权限,攻击者就能利用该漏洞获取到系统的ROOT权限。

影响范围: Tomcat 8 <= 8.0.36-2 Tomcat 7 <= 7.0.70-2 Tomcat 6 <= 6.0.45+dfsg-1~deb8u1

受影响的系统包括Debian、Ubuntu,其他使用相应deb包的系统也可能受到影响

漏洞详情&修复参考:

CVE-2016-4438这一漏洞其问题出在Tomcat的deb包中,使 deb包安装的Tomcat程序会自动为管理员安装一个启动脚本:/etc/init.d/tocat* 利用该脚本,可导致攻击者通过低权限的Tomcat用户获得系统root权限。

实现这个漏洞必须要重启tomcat服务,作为企业做好服务器登录的权限控制,升级有风险的服务可避免问题。

当然在企业中存在不少部署问题而导致了Tomcat存在安全隐患,运维部署完环境后交付给开发同学,如果没有删除Tomcat默认的文件夹就开放到了公网,攻击者可以通过部署WAR包的方式来获取机器权限。

Glassfish

Glassfish是用于构建 Java EE 5应用服务器的开源开发项目的名称。它基于 Sun Microsystems 提供的 Sun Java System Application Server PE 9 的源代码以及 Oracle 贡献的 TopLink 持久性代码。低版本存在任何文件读取漏洞。

影响范围:Glassfish4.0至4.1

修复参考:升级至4.11或以上版本

PoC参考:

http://1.2.3.4:4848/theme/META-INF/%c0.%c0./%c0.%c0./%c0.%c0./%c0.%c0./%c0.%c0./domains/
domain1/config/admin-keyfile

因为公司有用到Glassfish服务,当时在乌云上看到PoC也测试了下4.0的确存在任何文件读取问题,修复方法也是升级到4.11及以上版本。

Gitlab

Gitlab是一个用于仓库管理系统的开源项目。含义使用Git作为代码管理工具,越来越多的公司从SVN逐步移到Gitlab上来,由于存放着公司代码,数据安全也变得格外重要。

影响范围:

  • 任意文件读取漏洞(CVE-2016-9086): GitLab CE/EEversions 8.9, 8.10, 8.11, 8.12,
    and 8.13
  • 任意用户authentication_token泄露漏洞: Gitlab CE/EE versions 8.10.3-8.10.5

漏洞详情&修复参考:

http://blog.knownsec.com/2016/11/gitlab-file-read-vulnerability-cve-2016-9086-and-access-all-user-authentication-token/

互联网上有不少公司的代码仓库公网可直接访问,有些是历史原因有些是没有考虑到安全隐患,对于已经部署在公网的情况,可以让Gitlab强制开启二次认证防止暴力破解这里建议使用Google的身份验证,修改默认访问端口,做好acl只允许指定IP进行访问。

Mysql

Mysql是常见的关系型数据库之一,翻了下最新的漏洞情况有CVE-2016-6662和一个Mysql代码执行漏洞。由于这两个漏洞实现均需要获取到服务器权限,这里就不展开介绍漏洞有兴趣的可以看下相关文章,主要讲一下Mysql安全加固。

漏洞详情&修复参考:

在互联网企业中Mysql是很常见的服务,我这边提几点Mysql的安全加固,首先对于某些高级别的后台比如运营,用户等能涉及到用户信息的可以做蜜罐表。在项目申请资源的时候就要做好权限的划分,我们是运维同学保留最高权限,给开发一个只读用户和一个开发权限的用户进行使用,密码一律32位,同时指定机器登录数据库,删除默认数据库和数据库用户。

找了一篇还不错的加固文章提供参考:http://www.it165.net/database/html/201210/3132.html

Struts2

Struts2是一个优雅的,可扩展的框架,用于创建企业准备的Java Web应用程序。出现的漏洞也着实的多每爆一个各大漏洞平台上就会被刷屏。

漏洞详情&修复参考:

在线检测平台: http://0day.websaas.com.cn/

记得有一段时间Struts2的漏洞连续被爆出,自动化的工具也越来越多S2-032,S2-033,S2-037,乌云首页上都是Struts2的漏洞,有国企行业的有证券公司的使用者都分分中招,如果有使用的话还是建议升级到最新稳定版。

ImageMagick

ImageMagick是一个图象处理软件。它可以编辑、显示包括JPEG、TIFF、PNM、PNG、GIF和Photo CD在内的绝大多数当今最流行的图象格式。

影响范围:

  • ImageMagick 6.5.7-8 2012-08-17
  • ImageMagick 6.7.7-10 2014-03-06 低版本至6.9.3-9released 2016-04-30

漏洞详情&修复参考:

这个漏洞爆出来时也是被刷屏的,各大互联网公司都纷纷中招,利用一张构造的图片使用管道服符让其执行反弹shell拿到服务器权限,产生原因是因为字符过滤不严谨所导致的执行代码.对于文件名传递给后端的命令过滤不足,导致允许多种文件格式转换过程中远程执行代码。

3.应用安全隐患

为了不加长篇幅长度,加固具体步骤可以自行搜索。

SSH

之前有人做过实验把一台刚初始化好的机器放公网上看多久会遭受到攻击,结果半个小时就有IP开始爆破SSH的密码,网上通过SSH弱密码进服务器的案列也比比皆是。

安全隐患:

  • 弱密码

加固建议:

  • 禁止使用密码登录,更改为使用KEY登录
  • 禁止root用户登录,通过普通权限通过连接后sudo到root用户
  • 修改默认端口(默认端口为22)

Redis

Redis默认是没有密码的,在不需要密码访问的情况下是非常危险的一件事,攻击者在未授权访问 Redis 的情况下可以利用 Redis 的相关方法,可以成功在 Redis 服务器上写入公钥,进而可以使用对应私钥直接登录目标服务器。

安全隐患:

  • 未认证访问
  • 开放公网访问

加固建议:

  • 禁止把Redis直接暴露在公网
  • 添加认证,访问服务必须使用密码

Jenkins

Jenkins在公司中出现的频率也特别频繁,从集成测试到自动部署都可以使用Jenkins来完成,默认情况下Jenkins面板中用户可以选择执行脚本界面来操作一些系统层命令,攻击者通过暴力破解用户密码进脚本执行界面从而获取服务器权限。

安全隐患:

  • 登录未设置密码或密码过于简单
  • 开放公网访问

加固建议:

  • 禁止把Jenkins直接暴露在公网
  • 添加认证,建议使用用户矩阵或者与JIRA打通,JIRA设置密码复杂度

Zookeeper

分布式的,开放源码的分布式应用程序协调服务;提供功能包括:配置维护、域名服务、分布式同步、组服务等。Zookeeper默认也是未授权就可以访问了,特别对于公网开放的Zookeeper来说,这也导致了信息泄露的存在。

安全隐患:

  • 开放公网访问
  • 未认证访问

加固建议:

  • 禁止把Zookeeper直接暴露在公网
  • 添加访问控制,根据情况选择对应方式(认证用户,用户名密码,指定IP)

Zabbix

Zabbix为运维使用的监控系统,可以对服务器各项指标做出监控报警,默认有一个不需要密码访问的用户(Guest)。可以通过手工SQL注入获取管理员用户名和密码甚至拿到session,一旦攻击者获取Zabbix登录权限,那么后果不堪设想。

安全隐患:

  • 开放公网访问
  • 未删除默认用户
  • 弱密码

加固建议:

  • 禁止把Zabbix直接暴露在公网
  • 删除默认用户
  • 加强密码复杂度

Elasticsearch

Elasticsearch是一个基于Lucene的搜索服务器。越来越多的公司使用ELK作为日志分析,Elasticsearch在低版本中存在漏洞可命令执行,通常安装后大家都会安装elasticsearch-head方便管理索引,由于默认是没有访问控制导致会出现安全隐患。

安全隐患:

  • 开放公网访问
  • 未认证访问
  • 低版本漏洞

加固建议:

  • 禁止把Zabbix直接暴露在公网
  • 删除默认用户
  • 升级至最新稳定版
  • 安装Shield安全插件

Docker

容器服务在互联网公司中出现的频率呈直线上升,越来越多的公司使用容器去代替原先的虚拟化技术,之前专门做过Docker安全的分析,从 Docker自身安全, DockerImages安全和Docker使用安全隐患进行展开,链接:https://toutiao.io/posts/2y9xx8/preview

之前看到一个外国哥们使用脏牛漏洞在容器中运行EXP跳出容器的视频,具体我还没有复现,如果有复现出来的大家一起交流下~

安全隐患:

  • Base镜像漏洞
  • 部署配置不当

加固建议:

  • 手动升级Base镜像打上对应补丁
  • 配置Swarm要当心

4.总结

当公司没有负责安全的同学,做到以下几点可以在一定程度上做到防护:

  1. 关注最新漏洞情况,选择性的进行修复;
  2. 梳理内部开放服务,了解哪些对外开放能内网访问的绝不开放公网;
  3. 开放公网的服务必须做好访问控制;
  4. 避免弱密码;避免弱密码;避免弱密码;

以上内容只是理想状态,实际情况即使有安全部门以上内容也不一定能全部做到,业务的快速迭代,开发安全意识的各不相同,跨部门沟通上出现问题等等都会导致出现问题,这篇文章只罗列了部分服务,还有很多服务也有同样的问题,我有空会不断的更新。WeChat:atiger77

从甲方的角度谈谈WAF测试方法--part2

继Part1之后,停了将近半个月才动笔写第二部分,不是因为懒,实在是最近几个项目事情多。顺手还准备了几个面试,耽搁到了现在。

今天把这篇给自己的总结写完吧。

0X05 Webshell防御

webshell拦截

文件上传防御难免百密一疏,普通的webshell上传后,攻击者必然要通过与webshell通信,开展后续渗透。WAF必须有能力识别通信内容,并及时阻断。很多webshell的通信内容是经过base64编码的,WAF必须具备解码后准确分析的能力。

测试方法很简单,在服务器上放好测试的webshell,客户端通过WAF后访问webshell,执行重要的操作,如:dir、ls、net user等系统命令;连接操作数据库;上传下载文件等。

这项测试需要收集大量常用webshell,用于覆盖常见webshell的识别。Github上有一个项目收集了各种格式的webshell,妈妈再也不担心我找不到shell啦。

Github webshell collect

一句话拦截

如果服务器安装有杀毒软件,常见webshell是可以被查杀的。大马能拦住,小马当然也不能放过。一句话木马可是杀软无力识别的。

防御一句话,其实防御的是菜刀以及各种版本的菜刀与一句话的通信。

这里要重点说两款工具:

  • cknife:项目地址,这把刀可以自定义各种通信方式和php执行函数用于绕过waf检测。实际测试下来,的确很多家waf的默认策略对自定义模式拦截无力。
  • antSword:项目地址,修改版的菜刀,也很好用。

0X06 暴力破解及其他杂项

暴力破解

WAF必须具备识别工具自动爆破密码的能力,其实判断的原理不难,分析请求某个文件的某几个参数的频率即可。用BurpSuite测一测就知道。在WAF上需要手工配置防爆破的策略,指明请求的URI、用户需要输入的参数名、访问阈值条件。

F5 ASM在判断暴力破解行为时,会判断会话有效性,造成这里有个bug,使用burpsuite爆密码时ASM根本拦不住。开了售前ticket查了半天,联系研发才闹明白是判断机制设计所致,自然也就无法修改了。

机器访问

为了防止薅羊毛,WAF必须具备能力,根据用户自定义的URI、参数名、源IP/目的IP、目的URL等条件,拦截超出正常频率的机器访问行为。

这项测试非常考验设备的自定义程度,而Imperva在自定义策略的灵活性上,遥遥领先其他友商,无愧于Gartner第一象限的位置。自定义程度越高,策略越灵活,防御效果越好,对甲方工程师的技术要求也就越高。很多传统行业的甲方工程师由于不熟悉攻防,对HTTP没研究那么深,自定义策略反而成了工作的负担。在和Imperva工程师交流时多次看到其他同行发来的邮件,询问某某场景下实现某功能,应该如何配置。我觉得如果不懂HTTP,WAF干脆就不要玩了,纯粹是给自己找负担。从白帽子的角度来说,目标网站有WAF不可怕,渗透还是要坚持的,万一对方不懂HTTP呢。

指定参数拦截

在post表单中,安全基线要求代码必须判断用户输入内容是否合理。比如,手机号一项,必须提交13/15/17/18开头的11位纯数字。如果编码时实现该需求,一行正则匹配就搞定。但是你不能保证每个程序猿都是勤奋的。所以,用WAF帮助站点实现该需求是必备功能要求。

WAF必须具备识别制定URI的指定参数,提交的数据格式。这一项也是将各厂家区分开的重要指标。

命令注入

WAF还必须具备识别命令注入攻击的能力,这一项DVWA是提供了测试功能的。之所以重点拿出来说,是因为Imperva、F5 ASM在这里都存在明显的疏漏。常见系统命令,这两家的WAF都不能在默认策略下准确识别。这一点我很奇怪,明明特征库里是有这一类特征的,可为何检出率如此低?

0X07 设备自身安全

WAF除了要保护目标网站的安全性之外,自身的安全性也不可或缺。别不信,FortiWeb的5.5.3版本就存在CSRF漏洞。国产主流的漏洞扫描产品,除了绿盟也都存在CSRF漏洞。

另外,要使用NMAP等各种工具扫描设备开放的端口,看看有没有什么服务存在已知漏洞。

第三,设备登录入口必须支持连续登录失败X次后拦截登录请求的功能,防止被爆破。

第四,设备web端会使用类似jQuery等库,而第三方库是有各种已知漏洞的,查到CVE后逐个验证下漏洞是否存在。

第四,开个WVS扫一扫页面吧,看看有没有什么明显的漏洞。

0X08 自学习

商业WAF相比自研WAF,最大的优势在于自学习功能。商业WAF拥有多项专利技术,可以根据web应用的访问行为和流量,自动学习用户正常访问行为特征,据此建立防御策略。Imperva在这方面技术领先很多,专利也最多。如果用好了自学习功能,WAF的漏过能够很大程度上的改善。

但是,凡事没有绝对。WAF的自学习功能最大的困扰是误报。Web应用的功能非常复杂,请求方式千奇百怪,机器学习算法再精妙,也不可能百分百还原所有用户正常行为。一旦误判,大量的误报拦截会让管理员叫苦不迭。

实际测试下来,个人感觉自学习功能更多时候是厂商拿来做宣传的噱头和控标的一个指标项,但是实际在生产环境中使用它,最好还是慎之又慎,就连厂商工程师都不建议使用,你敢给领导打保票背这个雷吗?

但是自学习功能并非是聋子的耳朵–摆设。自学习最大的用处其实是分析用户行为的工具。用这个功能连续监控一个月之后,哪个URL被访问次数最多,用户的请求方法与行为是什么,可以通过自动报告一览无余。有了这个报告,后续在做Web应用调优、访客行为分析、判断误报等方面还是很有用的。

0X09 第三方测试工具

除了上述各种手工测试项目,还可以使用第三方开源工具测试WAF的拦截能力。这里推荐两个工具。

第一:碳基体的测试工具:项目地址

这款工具是用perl写的,在t文件夹下已经写好了很多测试脚本,这些脚本可以把攻击payload放在http协议的各个字段提交,用于测试WAF在不同http参数的识别能力。具体用法不多说了,碳基体写的非常清楚。

这里想说两点:

  1. X-Forwared-For是很多WAF会漏过的点。
  2. 没有哪家WAF可以百分百拦截所有测试脚本。换句话说,测出来漏过的地方,需要WAF上手工配置策略,白帽子们也可以在渗透时自由发挥了。

第二:Ironbee项目:项目地址

Ironbee是一款开源waf,这个项目是测试拦截率的攻击,也是用perl写的。同样的,baseline-detection目录下的脚本,也不是默认策略可以百分百识别的。

0X10 管理与维护

WAF除了要满足低误报低漏报,还必须人性化易管理。下面的几个功能点,是从管理员角度出发测试的内容。

  • 设备操作日志:WAF的所有管理员操作必须留存日志备查。
  • 管理员权限分割:管理员必须不能删除和操作设备日志,管理与审计权限必须分立。
  • 误报后的快速例外:WAF会出现超过50%的误报,出现误报后,设备必须支持快速且简便的例外策略生成。
  • 日志包含完整http的request和response,高亮显示违规内容。
  • 日志可导出:WAF的日志必须支持以标准syslog格式导出,既可以与SIEM联动,也可以让管理员手工分析。
  • 多种形式的报表展现:包括但不限于自定义源地址、目的地址、攻击手法、规则、日期时间等条件的自由组合生成报表。
  • 流量可视化展现:统计每个站点流量、统计指定源的流量、统计点击次数,可视化展现。

0X11 写在最后

写这篇文章的初衷,绝非为某个品牌站台,或者贬损某个品牌。我在写作的过程中尽量避免带有个人感情色彩,尽量保持对品牌的中立性。任何WAF都是众多开发人员的辛苦结晶,每家都有自己独到的地方,也难免存在疏漏。希望通过甲方安全人员的和厂商研发人员的共同努力,把WAF完善的更好更易用。

受限于自己技术能力,测试方法和测试内容难免有遗漏或错误,希望读者反馈指正。

全文首发于安全客,地址请戳 很感谢360团队对我的认可。