当前位置:WooYun >> 漏洞信息

漏洞概要 关注数(24) 关注此漏洞

缺陷编号:wooyun-2016-0169521

漏洞标题:葛坝办公网测试(可入内网获取5W员工信息/领导通讯录等)

相关厂商:葛洲坝

漏洞作者: z_zz_zzz

提交时间:2016-01-13 10:34

修复时间:2016-02-27 11:49

公开时间:2016-02-27 11:49

漏洞类型:系统/服务运维配置不当

危害等级:高

自评Rank:20

漏洞状态:已交由第三方合作机构(cncert国家互联网应急中心)处理

漏洞来源: http://www.wooyun.org,如有疑问或需要帮助请联系 [email protected]

Tags标签:

4人收藏 收藏
分享漏洞:


漏洞详情

披露状态:

2016-01-13: 细节已通知厂商并且等待厂商处理中
2016-01-15: 厂商已经确认,细节仅向厂商公开
2016-01-25: 细节向核心白帽子及相关领域专家公开
2016-02-04: 细节向普通白帽子公开
2016-02-14: 细节向实习白帽子公开
2016-02-27: 细节向公众公开

简要描述:

由于中间件配置不当,导致可以getshell,以此为跳板控制两台服务器,获取三个应用的用户密码信息。
可以获取5W员工信息,包括姓名、身份证号、婚姻状态、工资等,以及领导和其他员工的通讯录。

详细说明:

1.门户网站
1.1漏洞发现
使用zoomeye搜索武汉地区的websphere服务器,尝试登录websphere控制台,找到一台服务器发现是葛洲坝集团的门户网站服务器,websphere控制台可以直接登录,犹豫了好久要不要挖一挖,最后还是决定看一下吧,混个乌云的白帽子。
1.2websphere控制台
websphere控制台URL为https://xx.xxx.xxx.xx9:9043/ibm/console/。

图片1.jpg


没有设置密码,在用户标识输入任意值可以直接登录。

图片2.jpg


1.3上传webshell
使用websphere的应用更新功能上传webshell到已安装的应用中,不需要通过安装新应用的方式上传webshell。
webshell在这里,自己清理吧。

图片3.jpg


图片4.jpg


1.4确定公网域名
通过百度确定公网域名为http://dxxx.xxxx.xx/。
1.5获取数据库信息
在websphere控制台中查看配置的数据源URL为jdbc:oracle:thin:@xxx.xx.x.63:1521/xxxxdb,用户名为xxx5,数据库为oracle 11g。
查看websphere的配置文件,找到上述数据源密码的密文形式,使用已知的规则对密文进行解密,获取密码,也为xxx5。
使用webshell的数据库登录功能登录数据库,登录成功。

图片5.jpg


该数据库中还有大量的数据库用户,如图。

图片6.jpg


1.6分析用户登录代码
使用websphere控制台的导出功能下载应用代码,或使用webshell下载代码。
分析用户登录对应代码,确定存储用户信息的数据库表为uxxx_user,用户名字段为ACCOUNT,密码字段为PASSWORD。

图片7.jpg


查看用户数量,总用户数量为52617,状态正常的用户数量为48698。

图片8.jpg


图片9.jpg


在登录时会使用nx.ixxx.uxxx.axxxxxxxx.Uxxxxxxxxxxx的axxxxxxxxxxxxx方法对密码加密,执行加密的类为nx.vx.fxxxxxxxx.rxx.Encode。查找到该类所在的jar包并下载。查看Encode类,发现存在decode方法,猜测可使用该方法对密码的密文进行解密。
写了一个简单的java程序,调用上面发现的疑似解密方法,从用户信息表uxxx_user找一个密码进行解密,获得该用户密码的明文。
1.7登录网站
使用已获取的一个用户的用户名与密码登录门户网站,激动人心的时刻来了!!!
登录后的门户主页:

图片10.jpg


设备物资信息网:

图片11.jpg


企业论坛:

图片12.jpg


知识管理系统:

图片13.jpg


社保系统:

图片14.jpg


人力资源系统,可以获取员工信息,包括姓名、身份证号、婚姻状态、照片等,我就看了这个人的,其他人的没有看-.-。

图片15.jpg


工资信息,我就看了这个人的,其他人的没有看-.-。

图片16.jpg


1.8获取服务器密码
服务器版本为Windows Server 2003 SP1,使用vmware虚拟机。

图片17.jpg


使用mimikatz+procdump获取密码失败,使用ReadPSW获取成功,用户名为Administrator,密码为gxxxxxxxxx1。
1.9远程桌面
通过公网可访问服务器的3389端口,不需要转发,使用获取的密码登录远程桌面。

图片18.jpg


图片19.jpg


1.10其他后门
在旧的应用中,存在其他后门,不是我放的。

图片20.jpg


1.11其他文件
qq记录文件,可以找到聊天记录文件,应该可以恢复聊天内容。

图片21.jpg


1.12其他尝试连接门户服务器3389端口的IP
有这么多IP尝试通过公网连接门户服务器的3389,在公网开放这个端口是多么的危险-_-||。

图片22.jpg


2.OA网站
2.1OA网站地址
OA网站web服务器的公网IP为xx.xxx.xxx.xx6,域名为ox.xxxx.xx,应用服务器貌似无法通过公网访问。
2.2用户密码获取
在门户服务器中发现文件“XX密码修改操作办法XX.doc”,其中有以下内容。
1.2在用户输入框输入用户账户。如果XX,XX账号和XX账号一致,否则XX账号按照“XXX”的规则生成。
1.3在密码框输入密码。如果该用户是XX系统的用户,XX初始密码为“XXX”,其它用户账号密码为XXX。
在门户系统的用户信息表中找到用户名非上述形式的用户,尝试用初始密码“XXX”,找到两个用户可以登录成功。
2.3登录
激动人心的时刻又来了!!!
OA网站登录后主页:

图片23.jpg


各种内部文件,不同用户能够查看的不一样:

图片24.jpg


图片25.jpg


更劲爆的来了,领导的电话、邮箱都出来了。

图片26.jpg


共有697个用户的通讯录:

图片27.jpg


查看当前在线的用户,admin用户也在线:

图片28.jpg


查看文件时,需要安装浏览器插件“gXX.exe”,没有研究这个插件,说不定也能找到什么漏洞。在虚拟机没有安装OFFICE,尝试打开文件时会报错:

图片29.jpg


图片30.jpg


图片31.jpg


我又懒得在虚拟机中安装office,使用fiddler抓包查看,发现文档内容其实已经下载了。

图片32.jpg


3.新OA网站
3.1新OA网站地址
新OA网站的公网IP为xx.xxx.xxx.xx3,目前未找到域名,感觉以后新OA会代替现有的OA,会使用现有OA的域名ox.xxxx.xx。
新OA的URL为http://xx.xxx.xxx.xx3/xxx/xxxxxxxx/xxx/xxxxx!xxxxx.action。
3.2struts漏洞利用
看到了大大的action,拿出struts漏洞利用工具试了一下,发现是可以利用的。

图片33.jpg


利用struts2漏洞上传小马后,访问小马仍跳转到上述url,猜测有判断登录状态,若未登录时访问jsp文件会跳转至登录页面。
尝试访问任意以.jsp结尾的url,均跳转至登录页面,但访问非.jsp结束的url不会跳转至登录页面,说明确实有有判断登录状态。因此需要先登录后才能正常访问上传的jsp文件。
3.3获取用户账号信息
既然有限制非登录不允许访问jsp,就比较麻烦了,必须找到用户密码登录以后才能访问上传的webshell。好在已经拿下了门户服务器,可以做为跳板。
已确定新OA服务器的公网IP为xx.xxx.xxx.xx3,内网IP为xx.x.x.x0,主机名为xxxxxx-xxxxxxx。
新OA网站的用户信息肯定也是保存在服务器的,会不会和门户网站使用同一个数据库呢,在门户网站的webshell中查看oracle客户端的会话信息,如下。

图片34.jpg


新OA网站果然和门户网站使用同一个数据库,用户名为xxxxS,猜测密码也为xxxxS,尝试进行登录,成功。(在最开始测试时和后来写记录时,新OA网站使用的用户名已经改变了,看来这个网站最近一直在更新)

图片35.jpg


查找该用户的全部表名,关注表名中带“USER”的表,确定XXX_XXX_USER表为用户信息表,存在USER_PASSWORD字段。

图片36.jpg


USER_PASSWORD字段内容格式与HASH值类似,但长度为40位,非MD5生成,存在很多用户的密码字段相同。

图片37.jpg


查看新OA首页可以下载到的文件“XX配置手册.doc”,有如下内容|-.-|。
配置完成后,打开安卓手机客户端,输入用户名,密码,用户名使用XXX,区分大小写,密码默认是XXX
在用户信息表中看到很多密码字段都是一样的,那些就是使用默认密码的用户信息吧。
3.4登录
随便找了一个用户使用默认密码登录,登录之后非要修改默认密码才能使用,没有办法,改了一个密码,为了防止这个用户以后不能用默认密码登录,我又找到修改密码时提交的POST请求,手工发送POST请求,把密码又改成了默认密码-.-。

图片38.jpg


登录后的界面长这个样子,看样子还没有什么东西。

图片39.jpg


图片40.jpg


图片41.jpg


图片42.jpg


3.5上传webshell
使用用户登录之后,再访问之前通过Struts漏洞上传的小马,再把大马webshell上传。
webshell在这里。

图片43.jpg


3.6获取服务器密码
服务器为Windows Server 2008 SP1,没有找到vmware进程,应该是物理机。

图片44.jpg


图片45.jpg


使用mimikatz+procdump获取密码成功,用户名为nXXX,密码为CXX4。
3.7远程桌面
下面截图中的远程桌面是通过socks代理使用内网IP登录的,所以显示的IP不是公网IP。

图片46.jpg


3.8手机客户端
android和iphone手机客户端的文件保存在新OA的服务器中,应该可以对APK进行重打包,没有进行分析,也没有去修改。

图片47.jpg


4.内网信息搜集
在内网中发现大量sanfor的服务器与vcenter服务器,可惜没有找到弱口令,其他的密码也没有和已经获取的两台Windows服务器的密码是一样的。
内网的IP与可访问端口就不列出来了,有一些公网也访问不了。
5.公网探测
以下端口是在公网可以访问的,包含sanfor VPN的登录页面,sanfor防火墙的登录页面,邮件系统、财务报表等业务系统的登录页面。
可惜都没有找到弱口令-.-。

图片48.jpg


6.更邪恶的事情
有这么多员工账号、身份证、工资等信息可以获取到,领导的手机号也可以获取,估计都可以用来诈骗了吧。
有这么多的邮箱可以获取,爆力破解出几个应该是可以的吧,登录邮箱以后可能能看到一些更敏感的东西吧,找到VPN的账户和密码应该是有可能的吧,再不行就用社工吧。有了VPN账号应该可以进生产网了吧,可能能操作葛洲坝的电力设备了吧?
但!是!我!没!有!
我又不是黑客,做了这些对我也没有好处,我还怕被请去喝茶。到此为止吧。

漏洞证明:

见上文

修复方案:

7.修复建议
7.1使用防火墙
如果9043端口无法通过公网访问,也就没有这次的测试了-.-。
将21、22、23、1433、1521、3389、9043、9060等重要的端口通过防火墙设置为不允许通过公网访问。
7.2websphere控制台设置密码
如果websphere控制台设置了密码,也就没有这次的测试了-.-。
在websphere控制台中设置密码的操作如下:

图片49.jpg


图片50.jpg


打开“用户和组”->“管理用户”,点击“搜索用户”下方的“搜索”按钮,点击下方列表中的“admin”。

图片51.jpg


输入密码并确认密码,点击确定,不需要重启was服务可以生效。
7.3升级Struts
使用新版本的Struts基础包,最新版本可能是**.**.**.**。
使用该版本的Struts后,需要进行以下改动:
web.xml中使用的filter类改变,不需要struts-clean过滤器。
struts.xml中的XML头需修改为“<!DOCTYPE struts PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 2.3//EN"
"http://**.**.**.**/dtds/struts-2.3.dtd">”。
需要以下jar包(版本可能有不同):commons-fileupload-1.3.1.jar、commons-io-2.2.jar、commons-lang-2.4.jar、commons-lang3-3.2.jar、commons-logging-1.1.3.jar、freemarker-2.3.22.jar、javassist-3.11.0.GA.jar、ognl-3.0.6.jar、struts2-core-**.**.**.**.jar、struts2-spring-plugin-**.**.**.**.jar、xwork-core-**.**.**.**.jar。
7.4用户密码存储方式
数据库中保存的用户的密码应保存HASH值,不应保存加密后的值。
7.5登录密码说明文件存储时应注意
新OA网站保存了“初始密码为XXX”内容的文件应该找个更安全的地方存储吧-.-,不要在登录的首页大家都可以看到,这样可以使用初始密码枚举用户名破解破解了,虽然有用验证码,看起来也很简单,应该可以自动识别。

版权声明:转载请注明来源 z_zz_zzz@乌云


漏洞回应

厂商回应:

危害等级:高

漏洞Rank:13

确认时间:2016-01-15 18:27

厂商回复:

CNVD确认并复现所述情况,已经转由CNCERT向能源行业信息化主管部门通报,并抄报湖北分中心协助处置,由其后续协调网站管理单位处置。

最新状态:

暂无