新手学做网站步骤,临淄做网站,网站开发汇报的ppt,博罗建设银行网站aHR0cHM6Ly90ZGx6LmNjYi5jb20vIy9sb2dpbg 国密混合
WEB JS逆向篇
先看报文#xff1a;请求和响应都是全加密#xff0c;这种情况就不像参数加密可以方便全文搜索定位加密代码#xff0c;但因为前端必须解密响应的密文#xff0c;因此万能的方法就是搜索拦截器#xff0c…aHR0cHM6Ly90ZGx6LmNjYi5jb20vIy9sb2dpbg 国密混合
WEB JS逆向篇
先看报文请求和响应都是全加密这种情况就不像参数加密可以方便全文搜索定位加密代码但因为前端必须解密响应的密文因此万能的方法就是搜索拦截器从第一行下断点分析以找到加密的位置。 通常vue前端会使用axios配置拦截器如下图在搜索到的api.js的134、187行下断点然后任意请求即可。 实际操作的时候断点建议打在第一个箭头函数和第二个箭头函数的第一行避免因参数差异越过需要分析的逻辑。 做一下简单审计和判断由于参数保存在config里所以重点关注对config操作的代码步入173行的函数进一步分析。 84、93行和96行看到加密方法了分别是在post和get情况下对参数加密处理的逻辑。调试时由于是post方法故步入84行函数调用。
步入该方法才实际调用加密函数本身对应的猜测29行是解密函数顺便下个断点。
该金融公司用的名为microAppSafety的js文件是个加解密库且做了如上形式的混淆本例涉及国密该公司其它站点下使用类似文件名的js加解密库或均采用了国密 混淆严重影响了源码的分析和阅读但由于目的不是了解其加密逻辑的具体实现到此该节就结束了刚才解密的断点待服务器响应后也会停住同理分析即可。 后记该站点实际于测试环境进行与生产环境的代码略有不同源码形式不同非代码实现不同起初分析的时候由于种种原因都没有找到加密的函数但在生产环境下找到反推测试环境找到的加密函数的关键字encryptData在测试环境中同文件里搜索并下断点才得以成功完成测试环境的分析。
加密/验签策略定位技巧总结
前端加解密通常涉及两个开源库CryptoJS和JSEncrypt两个库的代码分别形如
//CryptoJS
var wordArray CryptoJS.enc.Utf8.parse(ð¤¢);
var utf8 CryptoJS.enc.Utf8.stringify(wordArray);//JSEncrypt
var crypt new JSEncrypt();
crypt.setKey(__YOUR_OPENSSL_PRIVATE_OR_PUBLIC_KEY__);
var text test;
var enc crypt.encrypt(text);单个参数加密
全局搜索加密的参数名并跟踪从取值到请求过程值的变化处理 加密位置常见于:
赋值处从组件取值时
var pwd $(#pwd).val();
var pwd encrypt(pwd);拦截器处理当中和ajax之前
全报文加密
全局搜索interceptors.request.use并对其下断点单步分析调用栈分析 无法确认哪一帧调用的加密时从较早的帧开始分析传入的参数是明文还是密文并在数据为密文的第一帧的上一帧下断点基本就可以分析处加密的位置了。 2.1. 从“网络“浏览器开发者工具栏中定位某个全报文加密的XHR请求图示使用firefox,chrome中在启动器一栏中查看调用栈
2.2. 对全报文加密的请求设置XHR断点查看调用栈
加密形式判断
数字信封随机数生成对称密钥加密数据一次一密-》公钥加密对称密钥-》传输 两个值jsonData,key或一个值一个公钥加密的值包含对称密钥和数据密文单一形式的加密 仅使用对称或非对称密码进行加密复杂加密机制的通常会有密钥协商交换的过程或其他一些密钥安全的机制如每个请求前先请求getPubkey获取公钥非对称、使用两对密钥前端硬编码用于加密的公钥A和用于解密的私钥B,后端使用私钥A解密使用公钥B加密非对称因此前端如果发现PRIVATE_KEY和PUBLIC_KEY实际是两对密钥等简单加密机制通常可以直接在js中找到硬编码的key对称,利用burp插件就可以直接完成自动化加解密 2.1. 对称加密aes/des/3des/国密如常见sm4-》传输 全部参数名仅对某个值加密或全报文 2.2. 非对称密钥RSA/国密常见sm2-》传输 全部参数名仅对某个值加密或全报文
签名机制分析定位
全局搜索保存签名的字段通常包含sign
url参数签名签名参数如
parm1signmd5(parm1)参数值签名签名参数如
pwdanamebsignmd5(a|b)请求头如 x-passwd:123 x-timestamp:169 x-sign:md5(123169)
请求改造篇
基于RPC技术的自动化去加密测试。 本地替换js修改加密调用 前端拦截器里最后通过方法g()实现对参数处理的逻辑但不是加密方法本身其中实现了request method的判断和超时参数的添加方法p。 所以改造p方法来去掉加密的调用使burp接收明文。 代码如下
function p(e) {return JSON.stringify({data: Object(u[a])({}, e),dataExpireTime: 1689999999999 //使用一个较大的固定时间戳而非实时生成以绕过服务器的时间戳超时校验机制 }) }
验证码获取请求GET
请求POST GET方法和POST方法经过处理后的流量在burp里已经是明文。
编写RPC客户端通讯脚本
首先定义RPC调用的加解密对象
调试过程将加密对象设置为全局对象,第二个打印的变量是加密密钥源码硬编码值。 QA 为什么是d? 因为调试的当前页面里指向加密对象的变量是d 为什么不定义p方法或是d.encryptData方法 因为如果全局变量指向p方法会导致其运行加密方法时找不到某些定义在加解密库js文件中的方法而报undefined异常破坏了作用域链的顺序直接指向这个加密对象便于加解密时RPC使用同一个全局对象。
将RPC客户端加载到浏览器环境里注入方法如油猴插件hook,本地覆盖到页面js和运行代码段等建议在代码段里运行实测注入到页面js中ws的通讯不稳定 使用sekiro框架提供的服务端与客户端demo即可并按实际情况修改通讯代码
//省略未变动的代码将在参考链接中给出
var client new SekiroClient(ws://127.0.0.1:5612/business-demo/register?grouprpc-testclientIdguid());client.registerAction(enc,function(request, resolve, reject){resolve(secApp.encryptData(request[params],04337449135FE6BD62D0683CE30AEA1BD178B879A392162D9F87A2FF0EC819A…));
})编写中间处理脚本
编写用于处理加密调用和密文流量转发的脚本mitm.py
#rpc加密
def encrypt(params):# print(request params in enc func:::{}.format(params))api http://127.0.0.1:5612/business-demo/invoke?grouprpc-testactionencjsonData{}.format(params)res requests.get(api).json()# print(res:::{}:::{}.format(str(res),str(res[data])) ) json()转换响应为json对象便于访问data字段return json.dumps({data:res[data],responseCode:res[responseCode],responseDesc:res[responseDesc]})#修改请求
def request(flow):#获取请求方法返回字符串POST GETmethod flow.request.methodif method GET:#获取查询参数# :MultiDictView[({data:{},dataExpireTime:1689999999999}, )]:::type is::: class mitmproxy.coretypes.multidict.MultiDictView# params flow.request.query 目标对整个查询字串加密query.get(param_name)针对参数加密的情况使用params flow.request.url.split(?, 1)[1]elif method POST:#获取请求bodyparams flow.request.textelse:params None# print(request params:::{}:::type is:::{}.format(params,type(params)))encryptedData encrypt(params)print(encData:::{}.format(encryptedData) )if method GET:flow.request.url flow.request.url.split(?,1)[0] ? encryptedData# print(request url:::{}.format(flow.request.url))elif method POST:flow.request.text encryptedData
Tips这里可以利用burp的repeater模块进行脚本的测试不必在浏览器里操作站点功能。
响应改造
同理对系统解密的流程分析并编写相关的脚本。
如果请求未通过服务器将响应200以外的代码此时拦截器进入reject部分该部分的处理是没有解密过程的响应包也可看到是明文形式的因此编写中间脚本时需要判断返回码以决定是否进入RPC解密的调用。 一般情况使用GET方法便于浏览器API调用但受限于URL长度当对响应解密时响应过长会导致GET方法无法正常请求因此API调用改换POST方式。
#RPC解密
def decrypt(params):api http://127.0.0.1:5612/business-demo/invokejsonObj {group: rpc-test,action: dec,param: str(params)}res requests.post(api, jsonjsonObj).json()print(res:::{}:::.format(str(res[data])) )return json.dumps(res[data])#修改响应
def response(flow):body flow.response.content.decode(utf-8)print(response body:::{}.format(body))#判断响应是否为密文if flow.response.status_code 200:decryptedBody decrypt(body)flow.response.text decryptedBody重写本地JS时对方法f改造即“直接调用解密方法“的方法。
function f(e) {return e
}RPC client加上解密的action:
client.registerAction(dec, function(request, resolve, reject){resolve(secApp.decryptDataOneWay(request[param], DA7668FAx7));
});开启RPC(先服务端、再客户端)和mitmdump
(图示上窗运行RPC server,下窗运行mitmdump) 运行RPC client
burp进行测试中的流量
原本加密的响应数据已呈明文。
通讯图示
红色箭头发起第一个请求RPC Server和RPC Clinet之间通过websocket通讯mitmdump和RPC Server间通过http通讯API,其余箭头都是代理流量转发的过程。
注 可以联动自动化工具把流量用脚本加密代理出去。
参考文档
mitmproxy https://docs.mitmproxy.org/stable/api/mitmproxy/http.html#Request sekiroAPI: https://sekiro.iinti.cn/sekiro-doc/01_user_manual/3.restful_api.html#get%E5%92%8Cpost sekiro客户端 https://sekiro.virjar.com/sekiro-doc/assets/sekiro_web_client.js 完整通讯代码
function guid() {function S4() {return (((1 Math.random()) * 0x10000) | 0).toString(16).substring(1);}return (S4() S4() - S4() - S4() - S4() - S4() S4() S4());
}var client new SekiroClient(ws://127.0.0.1:5612/business-demo/register?grouprpc-testclientId guid());// var secApp new microAppSafety;client.registerAction(enc, function (request, resolve, reject) {resolve(secApp.encryptData(request[param],enckey));})client.registerAction(dec, function (request, resolve, reject) {resolve(secApp.decryptDataOneWay(request[param],deckey));})//站点请求一次后在控制台中执行window.secApp new microAppSafety;注册全局对象续脚本优化
import json
import requests
import urllib.parsejava_server http://127.0.0.1:5612/business-demo/invoke# RPC
def rpc(action, params, grouprpc-test):url java_serverdata {group: group,action: action,param: params}count 0 # 计数器while 1:count 1if count 10:# TODO:处理超时逻辑breakres requests.post(url, datadata).json()if data in res:return resreturn # 解密
def decrypt(params: str):res rpc(dec, params)print(dec:::res:::{}:::.format(str(res)))return json.dumps({data: res[data], responseCode: res[responseCode], responseDesc: res[responseDesc]})# 加密
def encrypt(params: str):res rpc(enc, params)return res[data]# 修改请求
def request(flow):method flow.request.methodif method GET:flow.request.url flow.request.url.split(?, 1)[0] ? encrypt(urllib.parse.unquote(flow.request.url.split(?, 1)[1]))print(GET)elif method POST:flow.request.text encrypt(flow.request.text)# 修改响应
def response(flow):body flow.response.content.decode(utf-8)if flow.response.status_code 200:flow.response.text decrypt(body)埋坑框架bug:
实际操作时会出现RPC handler undefined异常暂未探究具体原因个人解决方法是在中间脚本里轮询RPC判断是否正常调用
count 0
while 1:count 1res requests.post(api, jsonjsonObj).json()print(count)if data in res:break解密RPC的响应长这样 {‘clientId’: ‘5af6b925-aa77-7184-dae5-1bfe289b7b21’, ‘data’: {‘verifyCode’: ‘/9w/UUAf/9k’, ‘verifyId’: ‘654054282479276032’}, ‘responseCode’: ‘success’, ‘responseDesc’: ‘success’, ‘status’: 0} 这就导致起初直接拿data无法正常进入前端逻辑序列化结果与原字串存在差异嵌套json被提出来了因此中间脚本返回时需要加上后面两个字段‘responseCode’和’responseDesc’。进分析是由于客户端处理时的偏差没有把响应的数据正确的全部作为data属性的值可以修改客户端代码这里处理方法是把加解密的结果b64打包了一下
古早文档代码部分已全量改进先不放了没时间改了马上要去看电影了
