看过freebuf上的两篇渗透实战文章,总结一下全过程,传送门如下:
全程带阻:记一次授权网络攻防演练(上)
全程带阻:记一次授权网络攻防演练(下)
测试过程全部过程导图:
渗透过程问题处理思路:
-
登录功能的审查点很多,比如账号是否可枚举、密码是否可暴破,但前提是没有验证码。
-
密码找回功能很容易出现逻辑错误,经验来看,至少可从七个方面攻击密码找回功能:
a. 重置凭证接收端可篡改 b. 重置凭证泄漏 c. 重置凭证未校验 d. 重置凭证可暴破 e. 用户混淆 f. 应答中存在影响后续逻辑的状态参数 g. token 可预测
-
hashcat 不仅是哈希暴破神器,也支持基于规则生成密码字典,规则库位于 hashcat/rules/: 社工字典爆破hash
-
一旦进入台后,习惯上先找三类功能:上传功能、查询功能、命令功能。上传功能,通过各种任意文件上传攻击手法,上传 webshell;查询功能,审查是否存在 SQL 注入,拿数据(如,哈希密码);
命令功能,指那些有著名工具实现的功能,比如,输入个 IP,业务功能探测该 IP 是否存活,服务端可能执行了 ping 命令,又如,上传个压缩包,页面显示压缩包内容,服务端可能执行了 unzip 命令,
这时,用命令注入或命令选项注入的手法,攻击服务端。 -
通常 token 要么用作身份凭证、要么用于防 CSRF。若是前者,就不应该与同样表示身份凭证的 cookie 同时存在,若是后者,通常为 16 位或 32 位的哈希值
-
JSON Web Token,现代 web 应用中替代 cookie 表示用户身份凭证的载体。形式类似 base64,但使用了 base64 可用字符空间之外的点字符,且无法直接解码,HTTP 报文中一旦发现 JWT,应重点关注
服务端对 JWT 实现不好,容易导致垂直越权,比如,把第二段的 user 字段值从 nana 篡改 admin。但是,JWT 的签名(也就是上面的第三部分),是对信息头和数据两部分结合密钥进行哈希而得,
服务端通过签名来确保数据的完整性和有效性, -
攻击 JWT,我常用三种手法:未校验签名、禁用哈希、暴破弱密钥。
-
JWT编码工具:
a.在线编码:https://jwt.io/#debugger 不支持alg字段为none 不支持不生成签名
b. python 的 pyjwt库
c. JWT 密钥暴破工具https://github.com/lmammino/jwt-cracker 但只支持字符序列穷举方式暴破
d.python脚本:
import jwtimport termcolor jwt_str = R’eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoibmFuYSIsImFjdGlvbiI6InVwbG9hZCJ9.56wwCrB9tIgmUnYpLPxkO8GYj1soCjuu_skTlbH_Gg8′ with open(‘/data/software/sec/wordlist/passwd/top/chinese_top10000.txt’) as f: for line in f: key_ = line.strip() try: jwt.decode(jwt_str, verify=True, key=key_) print(‘\r’, ‘\bbingo! found key –>’, termcolor.colored(key_, ‘green’), ‘<–’) break except (jwt.exceptions.ExpiredSignatureError, jwt.exceptions.InvalidAudienceError, jwt.exceptions.InvalidIssuedAtError, jwt.exceptions.InvalidIssuedAtError, jwt.exceptions.ImmatureSignatureError): print(‘\r’, ‘\bbingo! found key –>’, termcolor.colored(key_, ‘green’), ‘<–’) break except jwt.exceptions.InvalidSignatureError: print(‘\r’, ‘ ‘ * 64, ‘\r\btry’, key_, end=”, flush=True) continue else: print(‘\r’, ‘\bsorry! no key be found.’)
-
任意文件上传攻击应关注四个要素:找寻文件路径、指定文件扩展名、写入脚本代码、防 WAF 拦截.
-
不同类型的文件都有对应的文件类型签名(也叫类型幻数,简称文件头),比如,
PNG 的文件头为十六进制的 89 50 4E 47 0D 0A 1A 0A GIF 为 47 49 46 38 37 61 gif87a JPG 为 FF D8 FF E0
-
两年前,突破 WAF 我大概会用到这几种手法:分块传输、畸型请求、转义序列、偏僻编码、TLS 滥用,而如今,划时代的冰蝎问世
-
关于上传漏洞,冰蝎流量监测、白名单扩展绕过,这有两点你可以了解下:
a. 冰蝎流量能逃过所有品牌的 WAF 监测么?几乎是,唯一逃不过奇安信(原 360、原原网神)的天眼系统,冰蝎管理端与冰蝎马建立会话时需要获取动态密钥,这个过程中的请求与应答的两个报文存在特征,天眼的着力点在此; b. 任意文件上传攻击,遇到服务端扩展名白名单的场景,除了常规的解析漏洞手法外,还可能关注本地文件包含漏洞(LFI),以及 HTTP 参数污染漏洞(HPP),特别是 HPP,在突破白名单限制时,很有杀伤力。
-
反弹 shell 失败!导致失败的因素很多,经验来看,常见如下几类:反弹命令不存在、禁止出口流量、限定向外访问端口、流量审查。
14.常用的几个反弹命令:
nc/nc.openbsd/nc.traditional
bash/sh/dash
python/perl/PHP/ruby
exec
15. 提权的手法很多,比如,
利用内核栈溢出提权、搜寻配置文件中的明文密码、环境变量劫持高权限程序、不安全的服务、借助权能(POSIX capabilities)提权、sudo 误配、SUID 滥用等等。: