e看牙逻辑缺陷可导致用户密码泄露/员工信息泄露/整套源代码泄露

  • https://lc.lctest.cn:9001/api/v1/PersonAccount/UserCredential/{tenantId}/{userId}
  • 测试工具
    burpsuite
  • 漏洞类型
    业务逻辑缺陷密码安全问题未授权访问敏感信息泄漏

危害描述

业务逻辑错误漏洞是指由于程序逻辑不严或逻辑太复杂,导致一些逻辑分支不能够正常处理或处理错误,具体来说本漏洞会导致如下信息泄漏:

  • 用户明文密码
  • 网站源代码
  • 公司人员组织
  • 架构信息
  • 内部开发文档等信息泄露

测试过程

业务介绍

e看牙是一款专为口腔医生量身打造的移动办公应用,是医生的“移动诊室”。帮助医生完成工作日程管理、患者管理、诊后随访、医患交流、病历维护等,支持与诊所前台、诊所老板、诊所其他医生等角色协作办公,并且移动端数据与PC端诊所云管理系统实时同步。

产生原因

  • 重要API后台对外开放,接口未经认证可获取用户明文账号密码
  • 员工安全意识淡薄,企业各系统存在大量的弱口令
  • jira系统对外开放,导致企业开发文档,人员信息,源代码等泄露

测试过程

安全是一个整体,一个点被突破都可能导致不可想象的后果!此次测试的结果可以导致包括用户明文密码,网站源代码,公司人员组织架构信息,内部开发文档等信息泄露。一切还得从一个逻辑漏洞说起,

0x01 刺探

测试目标为lc.lctest.cn 首先通过nmap扫描端口

开放的端口特别多,这是特别危险的,使攻击者减少了攻击成本,而且现在服务器也没以前贵了 筛选发现9001端口运行着厂商api管理后台

0x02 起点

猜测这个后台跟主站lc.lctest.cn使用的是同样的账号密码,使用厂商提供的测试账号进行登录,登录成功 这个后台里面有e看牙系统所有接口详细信息,包括参数,请求方法等测试了许久,发现大部分接口还是需要认证才能请求数据。 但是其中有个接口并不需要验证。 看接口命名应该是跟账户有关

接口如下: https://lc.lctest.cn:9001/api/v1/PersonAccount/UserCredential/{tenantId}/{userId} 接口有需要两个参数:tenantid 以及 userid,userid很好理解,tenant字面上是租用者的意思,猜测应该是门诊独有的一个id号

0x03 寻找tenantid及userid

想起厂商本身有提供主站管理后台,后台的请求里面应该是有这个门诊ID的。 登录门诊管理系 开启burpsuite代理抓取所有经过的数据包,看看能不能抓到tenantid,设置burpsuite,history只显示拥有tenantid的数据包。 设置好后在后台菜单,把一级二级菜单都点了一遍,发现了tenantid。 发现诊所的tenanid为e8a5b2d4-4ff9-4bad-b0fe-dbfca2d95deb的确是唯一的,验证了我之前的猜测,同样的方法在数据包里面发现了userid。 userid只有三位数字,应该是递增生成的id号,登录的账号id为266   将获取到的参数拼接成完整的接口url: https://lc.lctest.cn:9001/api/v1/PersonAccount/UserCredential/e8a5b2d4-4ff9-4bad-b0fe-dbfca2d95deb/266

0x04 持续撕裂

访问url后,居然是查询用户的账号密码等敏感信息的接口,最重要的一点是密码居然是明文,太疏忽了。 使用工具进行自动化遍历userid 可以获取到tenanid为e8a5b2d4-4ff9-4bad-b0fe-dbfca2d95deb下的所有用户账号密码,这里获取到的用户密码大部分都是弱口令,根本没有安全可言。只要知道tenanid就能知道这个诊所下面的所有明文账号密码 危害是非常大,这样的接口存在的意义是什么?

0x05 会心一击

进展到这里,只要知道tenanid就能知道诊所管理员明文的账号密码,到这里就要结束? No!! 个人认为安全测试者在测试的时候应该把漏洞的价值尽可能的最大化,因为在整个测试过程中,有利于发现更多的厂商安全风险。       在前面的信息收集中,厂商正式环境的域名为saas.linkedcare.cn;测试环境域名为lc.lctest.cn 对其进行子域名收集。 得到厂商的jira地址http://jira.linkedcare.cn ;经过端口扫描后发现,jira运行在8000端口。 利用接口获取到的管理员账户密码尝试登陆此jira系统,均提示用户密码错误,说明测试环境的账号密码还是跟员工平时使用的不是一样的,对正式环境saas.linkedcare.cn使用同样的漏洞,使用同样的tenantid 进行测试,一样能获取到账号密码。 tenantid是固定的,公司代码同样是lc,猜测tenantid生成算法应该是跟公司代码这一类唯一字符有关, 这里获取到了管理员的账号:LinkedCare,密码:@[email protected]@,登录后台,查看所有管理员的账号。 逐一比对通过漏洞获取到的账号密码,并尝试登陆jira,发现zhaowei这个管理员的账号密码能登录jira

登录 jira集成了很多软件

confluence里面拥有开发文档 可以获取公司人员信息 fisheye源代码管理软件里面放着整套的源代码

0x05 End

至此,整个测试可以结束

  1. 本次发现的安全问题有以下:
  2. 重要API后台对外开放,接口未经认证可获取用户明文账号密码
  3. 员工安全意识淡薄,企业各系统存在大量的弱口令
  4. jira系统对外开放,导致企业开发文档,人员信息,源代码等泄露

修复建议

* 不对外开放重要后台 * 避免过多的服务(端口)对外开放,或对访问进行限制 * 对用户密码进行加密,使用强加密算法 * 报告中的接口不管出于什么用途,都不应该存在 * 对于弱口令,可采取以下方案: 1. 口令长度不小于8个字符。口令应该为以下四类字符的组合,大写字母 (A-Z)、小写字母(a-z)、数字(0-9)和特殊字符。每类字符至少包含一个。 2. 周期性修改密码 3. 多个账户使用不同的密码 4. 避免跟公司有关的口令(如带lc,linked,linkedcrae等字符)
from https://pockr.org/guest?no=EKY201612000017