1 有一个登录框你会怎么测试?
1.1 弱口令/密码爆破
1.2 Sql注入
sqlmap
1.3 密码找回功能
- 用户名枚举
- 账号相关敏感信息泄漏
- 逻辑漏洞
- 重置凭证泄漏
- 用户混淆
- 重置凭证未校验
1.4 注册功能
1.5 未授权登录、认证绕过
1.6 目录扫描/目录遍历
1.7 禁用JS 分析F12的源代码
1.8 验证码相关
- 验证码可修改接收者
- 登录验证码可绕过
- 验证码可爆破
- 验证码回显前端
- 验证码不刷新
- 验证码识别
1.9 JWT垂直越权
1.10 短信轰炸/邮箱轰炸
1.11 框架漏洞shiro、log4j
1.12 XSS
2 sql注入有哪些类型?
2.1 盲注
- 基于布尔
- 基于时间
有一个时间盲注的点,怎么不通过工具脚本快速得到数据?
- 二分法
- dnslog
2.2 报错注入
常用函数
- extractvalue()
- updatexml()
- floor()
2.3 联合注入
union
2.4 堆叠注入
堆叠可以查询多条命令,并且可以执行sql命令
2.5 宽字节注入
GBK
3 shiro反序列化分为哪几种,区别是什么?
- shiro 550
- shiro 721
3.1 利用过程相同
Apache Shiro框架进行登录,服务端在接收cookie时,会经过下面的流程:
- 检索RememberMe Cookie的值
- Base64解码
- AES解密(加密密钥硬编码)
- 进行反序列化操作(未过滤处理)
- 攻击者可以使用Shiro的默认密钥构造恶意序列化对象进行编码来伪造用户的Cookie,服务端反序列化时触发漏洞,从而执行命令
3.2 主要区别
- 这两个漏洞主要区别在于Shiro550使用已知密钥碰撞,只要有足够密钥库(条件较低),不需要Remember Cookie。
- Shiro721的ase加密的key基本猜不到,系统随机生成,可使用登录后rememberMe去爆破正确的key值,即利用有效的RememberMe Cookie作为Padding Oracle Attack的前缀,然后精心构造 RememberMe Cookie 值来实现反序列化漏洞攻击,难度高。
3.3 版本问题
- Shiro框架1.2.4版本之前的登录时默认是先验证"rememberMe" Cookie的值,而不是先进行身份验证,这也是Shiro550漏洞能够利用的原因之一,攻击者可以利用该漏洞通过伪造"rememberMe" Cookie的值来绕过Shiro框架的身份认证机制,从而实现未授权访问。
- Shiro框架1.2.4版本之后的登录时先进行身份验证,而不是先验证"rememberMe" Cookie的值,所以攻击者需要知道受害者已经通过登录验证,并且Shiro框架已经为受害者创建了一个有效的会话,以便攻击者可以利用该会话ID进行身份伪造并绕过Shiro框架的权限控制机制。
- 同时,Shiro框架的登录流程也是可以自定义的。
4 mysql提权
4.0 MySQL提权的必要条件:
- 具有MySQL的root权限,且MySQL以system权限运行。
- 具有执行SQL语句的权限。
4.1 UDF提权
UDF(user-defined function)是MySQL的一个拓展接口,也可称之为用户自定义函数,它是用来拓展MySQL的技术手段,可以说是数据库功能的一种扩展。
通过在udf文件中定义新函数,对MYSQL的功能进行扩充,可以执行系统任意命令,将MYSQL账号root转化为系统system权限。
4.2 MOF提权
托管对象格式(MOF)文件是创建和注册提供程序,事件类别和事件的简便方法。
MOF文件每隔五秒就会监控进程的创建和死亡,若MySQL是以管理员身份启动,并且可以往MOF的文件路径“c:/windows/system32/wbem/mof”中写入文件,便可以通过上传MOF进行提权
5 常见端口
- 21端口:FTP文件传输协议
- 22端口:SSH远程登录协议
- 23端口:Telnet协议
- 25端口:SMTP服务器开放端口,用于发送邮件
- 53端口:DNS域名服务器
- 80端口:HTTP
- 443端口:https
- 1433端口:SQL Server
- 1521端口:Oracle
- 3306端口:MySQL
- 3389端口:远程桌面连接
- 6379端口:Redis数据库
- 7001端口:Weblogic
- 8080端口:WWW代理
- 27017端口:mongoDB数据库默认端口
6 edr和传统杀毒软件有什么区别?
edr能与其他设备联动,可以在其他设备上看到告警信息。
7 weblogic常见漏洞
- 弱口令漏洞
- 任意文件上传CVE-2018-2894漏洞
- SSRF漏洞(CVE-2014-4210)漏洞
- XMLDecoder反序列化(CVE-2017-10271)漏洞
- 未认证远程命令执行(CVE-2020-14882、CVE-2020-14883)漏洞
- Java反序列化漏洞(CVE-2018-2628)漏洞
8 java内存马类型
- Filter 型
- Listener 型
- Servlet 型
- Interceptors 型
- Agent 型
- 其他
9 已经删除webshell了,过一段时间设备上仍有告警信息,需要排除什么?
- 自启动
- 计划任务
- 注册表
- 服务
10 内存马排查思路
内存马排查思路如下:
- 服务器web日志:先查看检查服务器web日志,查看是否有可疑的web访问日志,比如说filter或者listener类型的内存马,会有大量url请求路径相同参数不同的,或者页面不存在但是返回200的请求。
- 中间件报错日志: 如在web日志中并未发现异常,可以排查是否为中间件漏洞导致代码执行注入内存马,排查中间件的error.log日志查看是否有可疑的报错,根据注入时间和方法根据业务使用的组件排查是否可能存在java代码执行漏洞以及是否存在过webshell,排查框架漏洞,反序列化漏洞。
- 流量特征:查看是否有类似哥斯拉、冰蝎特征的url请求,哥斯拉和冰蝎的内存马注入流量特征与普通webshell的流量特征基本吻合。
- 200状态码:通过查找返回200的url路径对比web目录下是否真实存在文件,如不存在大概率为内存马。
内存马特征:
- 内存马的Filter是动态注册的,所以在web.xml中肯定没有配置,这也是个可以的特征。但servlet 3.0引入了@WebFilter标签方便开发这动态注册Filter。这种情况也存在没有在web.xml中显式声明,这个特征可以作为较强的特征。
- 内存马就是代码驻留内存中,本地无对应的class文件。所以我们只要检测Filter对应的ClassLoader目录下是否存在class文件。