atiger77 发布的文章

验证码安全那些事

前言

最近在研究验证码安全,本文主要分析四种流行的验证码(图形,短信,语音和滑动)进行分析,写这篇文章的出发点并非是绕过或破解验证码,而是根据自身业务情况来选择对应的验证码类型,在用户体验和安全性中找到属于自己的平衡点。

有问题可与我联系Wechat:atiger77

目录

0×01. 图形验证码  
0×02. 短信验证码
0×03. 语音验证码
0×04. 滑动验证码
0×05. 总结

备注:无论使用哪种验证码,只要开发不当都可能存在安全漏洞,为了减少文章重复内容,只在短信验证码中讲解漏洞以及对应加固方案,在语音验证码中讲解风控预防措施。

0×01 图形验证码

图形验证码是出现最早也是使用最为广泛的验证码没有之一,从最早的简单验证码到现在各种五花八门的验证码,为了防止被识别有加噪点的,有加干扰线的,有加各种背景的,有加逻辑题的…

之所以会有越来越恶心的验证码主要是防止验证码被机器识别,所设计的验证码难度也在不断上升,相比较来看下面两张图就知道为什么会这么设计了。

一般识别流程:

14917152134767.png

一般验证码加固方法:

14917152549751.png

随着验证码难度的提高识别的成本也随即提高,为了进行识别测试,我分别收集了四家不同类型互联网公司的验证码,情况如下:

某招聘网站验证码 – 字母周围有噪点,字体扭曲

20170424112448.png

某电商网站验证码 – 不同样式,字母阴影,字母粘连,背景色干扰

20170424112458.png

某社交网站验证码 – 主体干扰线,背景色干扰,背景字母干扰,字体扭曲,字母粘连

20170424112509.png

某生活类网站验证码 – 背景干扰线,背景色干扰,背景字母干扰,字体扭曲,字母粘连,字体镂空

20170424112522.png

首先针对某招聘网站的验证码进行识别,这里基于tesseract写的一个OCR程序,测试样本10张,最后准确率在50%,反溯以下发现对识别相近字时会比较吃力比如”z”和”2″,”0″和”O”等等,因为验证码做了反识别部分验证码人眼也比较难识别,如果继续优化识别率达到70%左右应该问题不大。

14917154289847.png

接着对某电商网站的验证码进行识别,最后准备率在40%,由于该网站验证码难度各不相同对于这种类型的验证码比较难做统一处理,即使使用机器学习的方法一个模型也很难去识别所有的验证码。

后面两个网站的验证码使用图像识别去做难度就很高了,为了不被识别分别做了大量的反识别工作,那么对于这类验证码一般使用的是人工打码平台,之前有文章已经介绍过了这里就不重复描述了。

这是某打码平台的价格,网上可以找到很多类似的网站。

14917154282029.png

那么对于企业来说,怎么防止验证码被人工打码呢,从安全角度来说是比较难做到防止的,为了不失去用户体验每张验证码的失效时间并不会很短,对于一个熟练的人工打码人员来说完全不在话下,那么我们从验证码本身出发去提高攻击的一个成本,举一个例子,可以使用DataURI scheme的方法把验证码图片直接写到HTML文件中去增加识别的时间和成本,当然还会有很多方法可以去增加攻击成本。

如果想从根本去除打码平台的困扰,这里可以参考支付宝和微信这两个产品的验证码机制,在某些地方所弹出的图形验证码是和使用者有关,比如选择联系人头像,选择购买过的物品,对于人工打码的人来说是完全不知道答案的,但是用了这种类型的验证码也会出现问题,比如“好友”足够了解你的情况下(个人信息泄露太多)可能会成功的进入。

现在有很多文章会用到神经网络CNN的方法用来识别验证码,相比传统的识别用机器学习有了样本的学习,识别率会更加的准确,对一些人眼可能判断错误的字母机器或许能判断准确,不过学习成本也是很高的。

0×02 短信验证码

短信验证码常见于注册,忘记密码,确认下单等阶段,特别是一些涉及到用户个人敏感行为时候,为了确认操作是用户本人执行的通常会使用短信验证码进行二次认证。同时,短信验证码也是最为常见的验证码类型之一,这里总结一些验证码逻辑漏洞。

a. 接口没设频次上限导致短信轰炸

起因:短信轰炸问题往往出现在一些小站或者子站,这几年很少看到通过GET请求发送短信验证码了,基本都是使用POST请求,使用抓包软件可以重放请求对于后端没有做限制的网站就可以达到短信轰炸的效果。

危害:对用户来说个人生活受到骚扰,对企业来说造成一定的负面影响,很多小公司因为短信接口被大量调用出现运营问题,对于公司没有安全工程师的情况下,一般都是业务方发现了数据异常向上汇报,最后和开发一起反溯才会找到这个问题,那么在这段时间中对企业所损失的钱也是无法挽回的。

预防:这里主要是针对两种攻击场景来进行防御,第一种是对单用户的短信轰炸,即重放发送请求且phonenum为一个值。第二种是对多用户发送短信骚扰的场景,即将phonenum参数设置为字典,重放短信接口。

设置发送间隔,即单一用户发送请求后,与下次发送请求时间需要间隔60秒。

设置单用户发送上限,即设置每个用户单位时间内发送短信数的上限,如果超过阈值就不允许今天再次调用短信接口(阈值根据业务情况设置)。

设置单IP发送上限,这种情况是预防第二种攻击场景的,由于IP的特殊性可能存在所处IP是大出口,一旦误杀后果会很验证,所以这个限制根据自身情况酌情考虑,对于有风控的团队来说,当发现发送IP存在异常可以对该IP增加二次认证来防止机器操作,也可以降低误杀情况。

备注:b和c两个漏洞场景一般截图说明下开发就知道问题所在了,这里修复建议的内容写的就比较少。

b. 验证码内容包含在返回包中

起因:因为开发不严谨导致通过抓包可以看到验证码在回显中显示。

14917155261248.png

危害:由于验证码直接返回,通过该漏洞可以注册任意用户,重置已注册用户密码,修改绑定信息等高危操作,对用户造成一定影响。

修复建议:不要将短信验证码在回显中显示,验证码只存于服务端中并不能通过任何api直接获取。

c. 修改返回包内容绕过验证

起因:前端校验导致下列问题。

14917155974535.png

14917155573802.png

危害:可跳过正常校验逻辑。

修复建议:服务端严格做检验,和开发谈谈心。

假设网站验证码接口没有以上说的任何漏洞,那么短信认证是否安全呢?

在用户手机没有被种木马,用户手机没被强制降频到GSM等情况下,当攻击者无法获取短信验证码则某些关键操作是无法继续的,在一定程度上起到了拦截的作用。特别针对盗号的场景,由于设备或常用地发生了变化,在用户登录时候弹出验证码进行校验防止被盗号的情况。短信验证码只对部分场景可以起到防护作用,单一的认证对于企业来说无法阻止以下的场景。

14917155587746.png

这张图在我上一篇文章中出现过,这是在某打码平台注册了一个帐号的截图,从图上就可以看出虽然用了短信验证码,但是可以通过打码平台来自动获取并完成注册流程。

针对打码平台的垃圾注册场景也可以通过一些手段去增加批量自动化的注册成本,防御手法有相同之处,在语音验证码中会简单讲解。

0×03 语音验证码

相比短信验证码,语音验证码存在以下的优势:

a.语音验证对防刷单效果更显著;
b.语音验证码到达率更高;
c.用户体验更加友好;

为什么说语音验证码对防刷单更有效,这里贴一张某打码平台的收费情况,可以看到语音验证的价格是短信的十倍。很多公司是不会对17开头的虚拟号段进行发送的,为此卡商提供的卡号基本是实名认证的且没有停机的正常号段,所以收语音验证的成本就会比短信高很多。

14917156829962.png

这家打码平台对语音识别有两种方式,一个是系统识别,另一个是自己听取,对于系统识别平台解释是由听码团队负责听取验证码后传输文字回来,自己听取则是自己下载语音验证码录音自己听候识别。

跟公司研究移动端安全的小伙伴讨论了下,根据目前的技术要做到全自动也并非不可能,这里简单画了一个流程,从触发语音认证开始到最后的填入完成验证一条龙。

14917156821814.png

首先要获取语音认证,等语音验证码说完以后自动保存录音,进行语音分析,国内有几家厂商有语音识别的服务并都提供SDK,所涉及的服务可以用来进行识别,将语音转换成文字并提取验证码部分,完成最后验证。

对于企业来说我们如何防止这种垃圾注册的场景呢,说几种通用的思路供参考,这里主要可以分事前和事后基于规则和行为做判断。

对于事前,可以借助反欺诈接口检测请求的号码是否存在风险,WEB端判断用户UserAgent是否存在异常,APP端判断用户DeviceID是否存在异常,由于事前可以拿到的信息并不多,可以围绕可以拿到的参数做规则,对触发规则的用户进行阻断操作,可以在发送短信或者语音前让其先填写一次图形验证码,多一步校验。当然,也有公司会将部分手机号进行拉黑操作,在源头上禁止某些手机号进行注册。

对于事后,服务端校验以后就可以拿到状态等信息,围绕这些信息又可以制定一些规则,这里可以举一个通用的规则,比如单位时间内单IP登录失败超过阈值的对这个IP进行某某处理,这也是最基本的频次规则。对于不同的业务有着自己不同的策略,比如金融公司的APP会索取用户通讯录的权限,根据用户的好友做用户画像,某些公司也会做二度关系画像来判断用户是否存在风险。

这里不会说太多的规则和策略,由于公司的业务都不尽相同,当日志接入以后针对目前场景存在的问题去设计不同的规则即可。

0×04 滑动验证码

现在有不少的互联网公司开始使用滑动验证码进行校验,看似一个简单的滑动操作,背后都有风控引擎和相应的规则作为保障,首先讲一下滑动验证码的整个流程。

1491715758468.png

我们说一下正常的逻辑,首先用户滑动验证码到指定位置,完成后会给服务端回传各种加密信息,为了做风控规则来判断是否异常,个人猜测其规则会包含用户IP,操作行为路径,UA,COOKIE,设备指纹等等,如果没有命中规则,就会放行校验通过,如果命中规则就会弹出二次校验,只有通过校验后才可以放行。

那么如何破解滑动验证码呢,第一种是模拟正常用户操作,并让风控不要命中风控规则。第二种是尝试破解第二阶段的验证,对于图片可以使用OCR技术进行识别(针对类ReCAPTCHA验证码)。第二种的难度比较高,网上的文章也是针对第一种来进行破解,这里简单讲一下破解方法。

我对某商业滑动验证码进行了测试,整体流程梳理如下:

14917157589764.png

全部过程可以用自动化来实现,整体成功率要分为两个部分来看,第一是验证码自身风控能发现多少问题,我所测试的接口破解成功率在76%左右。第二是企业自身的风控规则能发现和阻断多少异常情况。两者结合最后的成功率就会有所下降,虽然有接口破解但是价格昂贵,已经提高了攻击成本,如果账户不涉及到金钱也不会考虑这么高的攻击成本,其实说到底还是成本和收益的一个衡量。

这里聊一下商业化滑动验证码厂商的优势和弊端。首先说优势,滑动验证码肯定会成为一种流行趋势,对于企业来说自研的成本比较大,无非也就是几个工程师参考已有的进行模仿,先不说效果开发流程上就会耽误人力,这点钱宁愿使用商业化的,现在的产品都已经相对成熟也有专门的团队进行升级维护,安全和体验性上来说都还不错。弊端到也谈不上,这里主要说几点使用前要考虑的地方,一个是响应延迟,当大量并发过来的时候是不是撑得住,最高响应时间是否有上限,如果超过是否会降级,如何降级等等,万一碰到不可预计的问题,比如碰到光缆被挖断,服务是否能即使切换,灾备是否完善等等,在购买前这些问题最好都要进行测试并有应急方案。

0×05 总结

前面也总结了很多验证码,我认为一个好的验证码首先不能有逻辑上的漏洞能绕过,否则再复杂的验证码都是形同虚设。其次,不能为了增加破解难度而抛弃用户体验,不要把验证码做的极其复杂人眼都识别不了,这种也会失去验证码的意义(用户都没了还给谁验证…)

目前来说大部分的企业还是偏向使用图形验证码,在测试过程中只有极少数的公司会动态升级自己的图片验证码,随着输错次数的上升验证码难度也随机上升。统一验证码的设计初衷是好的,即使攻击者使用了OCR技术进行破解,一旦失败数触发到阈值即自动上升图形验证码难度,增加破解成本。

为了防止验证码被爬虫获取后专门进行分析,针对性的破解攻击,需要准备多套图形验证码定期进行替换。

统一验证码体系如果只用单纯的规则去匹配所弹出的验证码,那么这种情况会出现不少的误杀,会让某些正常用户操作频次超过设定阈值,用户在尝试输入密码的过程中验证码越来越难,最后导致用户投诉。所以我认为一个完善的统一验证码体系应该由风控来判断是否触发规则,对触发规则的请求进行相应的验证升级,而不是设定一个死的阈值,对关键操作可以用多种验证码组合的形式来进行校验,常见的组合有,滑动+图形,图形+语音等。

就我个人而言,比较喜欢点触式和滑动式的验证码,通过采集用户当前各种的参数行为(行为轨距,操作时间,当前环境等等)来判断是否为机器行为。在用户体验上,手机端不是很建议使用选字类型的验证码,对于非大屏的手机不是很友好。在安全性上,这类验证码要比其他验证码破解成本高。我相信验证码的趋势也会逐渐向这种类型的靠拢。

下面的图片引用了google的ReCAPTCHA,分别截取图片和语音验证,ReCAPTCHA在安全性和用户体验做的都很好,即使这样还是被安全研究者破解过,所以不要完全依赖一种验证码,对敏感操作可以使用多种验证码。下面是官网的DEMO:

图片类:

14917158615511.png

声音类:

14917158896397.png

无论哪种验证码都有自己的适用场景,也没有一种绝对安全的验证码,根据自身业务情况来选择对应的验证码类型,在用户体验和安全性中找到属于自己的平衡点。最后,有做业务安全的同学可以一起学习交流。

业务安全冷知识

前言

年前突然想写一篇简单易读的文章,讲一点可能会被忽略的业务安全问题,这些问题都算不上是漏洞,但可以对公司造成一定的影响,所以我这里称他们为冷知识,当中会涉及一些竞品分析的点,部分内容对中小型互联网企业都通用。有问题可与我联系wechat:atiger77

序号

  1. 前端提示内容过多;
  2. 用户ID自增隐患;
  3. 域名到期时间;
  4. 短信接口任意调用;

前端提示内容过多

所谓提示内容过多,一般常见于登录重置密码等页面。以登录页面举例,当输入的用户名和密码不正确时,返回的内容过于详细,常见的有: a.你输入的用户名不存在 b.密码必须大于等于6位 c.你输入的密码不正确 等等内容。

排除逻辑漏洞的问题,当前端返回给攻击者越多的信息,对于攻击者而言也缩短了攻击者的成本,还是拿上面的情况来说,第一种,攻击者根据提示可以测试出用户覆盖率,第二种当登录处没有验证码机制的时候,对攻击者字段选择上能节省大量时间。

  • 造成原因:开发安全意识薄弱
  • 解决方法:去除不需要的回显内容

用户ID自增隐患

国内互联网情况就是看到别人的产品不错马上就拿过来抄,除了少数一些以技术为核心驱动的公司,其他的都可以在短期内搞一个看着一样的产品出来,那么这个安全冷知识在竞品分析中可以获取一定成果。

当公司业务线多起来后,必然要上用户中心集中管理用户,一般的设计逻辑都是单表存一千万的用户并且UID自增,那么这个风险点也会随之而来。

设想一下这个情况,你的公司有一家“孪生兄弟”,你又想知道他们的运营情况,那么可以尝试这样做,今天的8点注册一个号,抓包记录UID,在明天的8点再注册一个号也记录下UID,一直重复在同一时间点注册用户并记录UID,将后一天的UID减去前一天的UID即可得出一天的注册情况,当你产品运营数据被竞品所得到的时候,是不是很可怕呢。

  • 造成原因:UID顺序自增,规律性太容易被发现
  • 解决方法:混淆UID生成规则

域名到期时间

公司域名管理其实是算在运维部下的,为什么这里要说因为一直会看到新闻说某某公司因为域名到期忘记续费,导致域名被抢注的情况。

简单一提,需要定期的查看域名到期情况,对快到期的域名做续费处理,对于公司而言,买域名的钱和买白菜一样。所以,在域名快到期的时候尽快解决把。

  • 造成原因:到期域名未即时续费
  • 解决方法:记录域名到期时间

短信接口任意调用

这个问题也很普遍,短信接口的应用场景很多,用户注册、忘记密码、重置密码等等。之前也看到新闻说一家创业公司短信接口被恶意调用,无缘无故损失了一大笔钱。

往往公司发现这个异常都是通过周的数据统计或者是月的数据统计,那么这个时候已经无法挽回之前的损失了。

那么防范的措施也不复杂,增加验证码机制,设置短信发送上限,接口请求参数GET->POST等等。

  • 造成原因:没有校验过程
  • 解决方法:风控措施

总结

暂时就想到这么多,以后想到我还要继续添加进去,有问题可以和我联系。

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

前言

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

Dionaea:基于Docker的蜜罐系统

项目主页

https://github.com/atiger77/Dionaea

简介

web_dionaea为企业内部web类蜜罐,用来捕捉APT,内鬼及被内鬼等入侵行为。项目使用Django编写,使用Docker运行方便部署。

注:项目前端部分由ID:chanyipiaomiao帮忙完成

部署方式

  1. 自定义蜜罐名称;修改/web_dionaea/templates/index.html中的对应title
  2. 制作蜜罐镜像;#docker build -t "web_dionaea" .
  3. 创建蜜罐容器;#docker run -d -p 80:80 -v /opt:/tmp --restart=always web_dionaea
  4. 添加计划任务;*/5 * * * * /bin/bash /opt/Check.sh

登录界面

web_dionaea_01.png

日志截图

web_dionaea_02.png

分析脚本执行结果

web_dionaea_03.png

注意事项

这个dockerfile我没有直接构建push到dockerhub,可以任意修改成自己想要的样子,Check.sh脚本默认是在centos7环境下执行,修改Dionaea_HostIP值可直接兼容其他环境。有问题与我联系:d2VjaGF0OmF0aWdlcjc3