在几天前发布适用于 Version 1809 的修复之后，今天微软再次发布了适用于 Windows 10 Version 2009/2004/1909/1903/1607 的安全更新，重点修复了 Kerberos 认证系统中存在的高危漏洞（编号 CVE-2020-17049）。 在更新日志中写道 修复了 CVE-2020-17049 漏洞，修复了 PerformTicketSignature 注册表子项值相关的 Kerberos 身份验证问题，该漏洞修复已经包含在11月10日发布的累积更新中。 当 PerformTicketSignature 设置为1（默认值）时，对于非Windows Kerberos客户端，Kerberos服务票证和票证授予票证（TGT）可能不会续订。 当PerformTicketSignature设置为0时，所有客户端的用户服务（S4U）方案（例如计划任务，群集和业务线应用程序服务）可能会失败。 如果不一致地更新中间域中的DC并将PerformTicketSignature设置为1，则在跨域方案中的票证引用期间S4UProxy委派失败。 下载地址 KB4594440  20H2 / 2004 Update Catalog KB4594443 1909 / 1903 Update Catalog KB4594441 1607  Update Catalog         （消息及封面来源：cnBeta）

实时自动化（RTA）499ES EtherNet/IP（ENIP）堆栈中存在一个严重漏洞，该漏洞可能会使工业控制系统受到远程攻击。 RTA的ENIP堆栈是广泛使用的工业自动化设备之一，被誉为“北美工厂I/O应用的标准”。 美国网络安全与基础设施局（CISA）在一份咨询报告中表示：“成功利用此漏洞可能造成拒绝服务，缓冲区溢出可能允许远程代码执行。” 到目前为止，尚未发现针对此漏洞的已知公开攻击。然而，“根据互联网连接设备的公共搜索引擎，目前有超过8000台与ENIP兼容的互联网设备。” 该漏洞编号为CVE-2020-25159，CVSS评分为9.8（满分10分），影响2.28之前版本的EtherNet/IP Adapter Source Code Stack。 安全公司Claroty的研究员Sharon Brizinov上个月向CISA披露了这个堆栈溢出漏洞。 RTA似乎早在2012年就从软件中删除了可攻击代码，但许多供应商可能在2012年更新之前就购买了该堆栈的易受攻击版本，并将其集成到自己的固件，从而使多台设备处于危险之中。 研究人员表示：“在六家供应商的产品中，有11种设备运行了RTA的ENIP堆栈。” 该漏洞本身涉及对通用工业协议（CIP）中使用的路径解析机制的不正确检查（CIP是一种用于组织和共享工业设备中的数据的通信协议），使得攻击者能够打开具有较大连接路径大小（大于32）的CIP请求，并导致解析器写入内存地址超出固定长度缓冲区，从而可能会导致任意代码执行。 RTA在披露中表示：“RTA设备中的旧代码试图通过限制EtherNet / IP转发打开请求中使用的特定缓冲区的大小来减少RAM的使用。” “通过限制RAM，攻击者有可能试图使缓冲区溢出，并利用它来控制设备。” Claroty的研究人员扫描了290个与ENIP兼容模块，其中来自6个不同供应商的11个设备被发现使用了RTA的ENIP堆栈。 Brizinov在分析中指出：“与先前的披露类似（例如Ripple20或Urgent / 11），这是另一个易受攻击的第三方核心库使工业控制系统供应商的产品面临风险的案例。” 我们建议用户更新到ENIP堆栈的当前版本，以减轻该漏洞带来的影响。CISA还建议用户最大程度地减少所有控制系统设备的网络暴露，确保不能从网络访问这些设备。 CISA表示： “将控制系统网络和远程设备放在防火墙后面，并将它们与业务网络隔离开。当需要远程访问时，使用安全方法，例如虚拟专用网（VPN）。但是VPN可能存在漏洞，应将其更新为可用的最新版本。”         消息来源：The Hacker News ；封面来自网络；译者：芋泥啵啵奶茶。 本文由 HackerNews.cc 翻译整理。 转载请注明“转自 HackerNews.cc ” 

伴随着新冠疫情肆虐，越来越多的员工开始通过远程办公的方式进行线上协作、视频会议。而远程办公的激增，也暴露了诸多安全性和数据保密性问题。IBM 的研究人员近日对热门应用–思科 Webex 进行了测试，发现该服务存在三个漏洞。这些漏洞能够让攻击者以“Ghost”身份加入到会议中而不被发现。 这些漏洞不仅能够让攻击者秘密地加入会议，甚至在被“驱逐”之后仍然可以作为音频参与者留在会议中。攻击者甚至可以在不进入呼叫的情况下从大厅获得有关会议与会者的详细信息。 视频链接：https://www.bilibili.com/video/BV11t4y1e7dP?zw 虽然当这些攻击者加入到会议中依然会触发蜂鸣声，但如果这次会议中有很多与会者，那么就非常容易被忽略。IBM 表示在发现该漏洞的同时，还发现可以通过特殊的 URL 地址来影响已经设定的会议和会议安排。 该漏洞可以发生在客户端和服务器之间的“握手”过程中。由于“不正确的输入验证和清理”，攻击者可以操纵通过WebSocket发送的请求（客户端与服务器之间的连接），并将特殊设计的值注入到请求中以作为虚拟主机加入。研究人员成功地测试了这些场景，并且可以参加会议且不会出现在与会人员列表中，也不会被发现。 IBM说，由于问题的严重性和紧迫性，它立即与Cisco共享了其发现的细节。这家网络公司致力于修复上述漏洞，并于今天发布了安全公告。这三个错误分别被标记为CVE-2020-3441, CVE-2020-3471, CVE-2020-3419，并已成功修复。由于此问题影响了大多数平台上的Webex客户端，因此该公司建议用户将其应用程序更新到最新版本。         （消息来源：cnBeta；封面来自网络）  

在微软披露存在于 Windows RDP 服务中的 BlueKeep 高危漏洞一年半后，目前至少仍有 245000 台 Windows 设备尚未修复该漏洞，意味着它们依然容易受到黑客的攻击。BlueKeep 于2019年5月首次发现，在对 950000 台设备的扫描中发现 25% 的设备存在该漏洞。 同样地，超过 103000 台 Windows 设备仍然容易受到 SMBGhost 的攻击，这是存在于2020年3月发布的新版 Windows 附带的服务器消息块v3（SMB）协议中的漏洞。 这两个漏洞都使攻击者可以远程控制Windows系统，并且被认为是过去几年Windows中披露的一些最严重的错误。然而，根据 SANS ISC 管理员 Jan Kopriva 在过去几周进行的研究，尽管这两个漏洞非常严重，但许多系统仍未打补丁。 根据这名来自捷克的安全研究人员的说法，目前全球仍有数百万台设备存在安全隐患，而且管理员无法修复它们，导致非常容易被恶意攻击者接管。这些系统包括 IIS 服务器、Exim 电子邮件代理，OpenSSL 客户端和 WordPress 网站等系统。 这些系统为何未打补丁的原因仍然未知，但即使是美国政府网络安全机构最近发出的警告也没有帮助。尽管有这些警告，仍然有超过 268,000 台 Exim 服务器未针对Exim错误进行修补，而超过 245,000 台针对 BlueKeep 未进行修补。         （消息来源：cnBeta；封面来自网络）

思科发布4.22版本的补丁程序后，过了一周，思科发布了多个有关Cisco Security Manager（CSM）关键漏洞的安全公告。 此前，Code White研究员Florian Hauser（frycos）公开披露了影响CSM web界面的12个安全漏洞的PoC，这些漏洞使得未经验证的攻击者有可能实现远程代码执行（RCE）攻击。 三个月前的7月13日，思科产品安全事故响应小组（PSIRT）负责任地报告了这些缺陷。 frycos在一条推文中称：“由于Cisco PSIRT变得无响应，而发布的4.22版仍然没有提到任何漏洞，”他在推特中列举了公开POC的原因。 Cisco Security Manager是一个端到端的企业解决方案，允许组织实施访问策略，管理和配置网络中的防火墙和入侵防御系统。 该公司于11月9日发布了CSM的4.22版本，其中包括对AnyConnect Web Security WSO的支持，以及不受欢迎的MD5哈希算法、DES和3DES加密算法。 这些漏洞允许攻击者在最高权限用户帐户“NT AUTHORITY\SYSTEM”的上下文中创建恶意请求、上传和下载任意文件，从而使对手能够访问特定目录中的所有文件。 思科在其公告中表示：“该漏洞是由于对受影响设备的请求中目录遍历字符序列的验证不正确所致。”“攻击者可以通过向受影响的设备发送精心编制的请求来利用此漏洞进行攻击。成功利用此漏洞可使攻击者从受影响的设备下载任意文件。” 该缺陷的CVSS评分为9.1（满分10分），等级为严重。 CSM使用的不安全的Java反序列化函数导致的另一个缺陷（CVSS分数：8.1）可能允许具有系统权限的未经验证的远程攻击者在受影响的设备上执行任意命令。 然而，思科还没有解决这个缺陷，计划中的修复程序将包括在思科安全管理器4.23版本中。 该公司还表示，它知道有关这些漏洞的公开声明，目前还没有发现任何证据表明这些漏洞是在野外被利用的。 11月16日，思科针对Cisco security Manager（CSM）中报告的漏洞发布了三份安全公告。报告的12个问题通过四个Cisco bug ID进行跟踪并解决。思科发布了免费软件更新，以解决CSM路径遍历漏洞咨询和CSM静态凭证漏洞咨询中描述的漏洞。 思科将尽快发布免费软件更新，以解决CSM Java反序列化漏洞咨询中描述的漏洞。         消息来源：The Hacker News ；封面来自网络；译者：芋泥啵啵奶茶。 本文由 HackerNews.cc 翻译整理。 转载请注明“转自 HackerNews.cc ” 

来自加利福尼亚大学和清华大学的一群学者发现了一系列严重的安全漏洞，这些漏洞可能导致DNS缓存中毒攻击死灰复燃。 这种技术被称为“SAD DNS攻击”（Side-channel AttackeD DNS的缩写），该技术使攻击者可以进行路径外攻击，将最初发往特定域的所有流量重新路由到其控制下的服务器，从而允许他们窃听和篡改通信。 研究人员表示：“这是一个重要的里程碑，这是第一个可武器化的网络侧通道攻击，具有严重的安全影响。”“这使攻击者可以将恶意DNS记录注入DNS缓存中。” 这一发现被追踪为CVE-2020-25705。该漏洞影响操作系统Linux 3.18-5.10，Windows Server 2019（版本1809）和更高版本，macOS 10.15和更高版本以及FreeBSD 12.1.0和更高版本。   DNS转发器成为新的攻击面 DNS解析器通常将对IP地址查询的响应缓存特定时间段，以提高网络中响应性能。但可以利用这种机制来毒化缓存，方法是为给定网站模拟IP地址DNS条目，并将尝试访问该网站的用户重定向到攻击者选择的其他站点。 但是，此类攻击的有效性受到了一定程度的影响，因为诸如DNSSEC（域名系统安全扩展）之类的协议通过在现有DNS记录中添加加密签名和允许DNS的基于随机化的防御来创建安全的域名系统解析程序为每个查询使用不同的源端口和事务ID（TxID）。   一种新颖的Side-Channel攻击 研究人员指出，由于“激励和兼容性”的原因，这两种缓解措施还远未得到广泛应用，因此他们设计了一种Side-Channel攻击，可以成功地用于最流行的DNS软件堆栈。所以，像Cloudflare的1.1.1.1和Google的8.8.8.8这样的公共DNS解析程序易受攻击。 SAD DNS攻击的工作原理是利用任何网络中的一台受损机器，该网络能够触发DNS转发器或解析器的请求，例如咖啡馆、购物中心或机场中由无线路由器管理的公共无线网络。 然后，它利用网络协议栈中的一个侧信道来扫描并发现哪些源端口用于启动DNS查询，随后通过暴力强制TxIDs注入大量伪造的DNS应答。 更具体地说，研究人员使用域名请求中使用的一个通道，通过向受害者服务器发送每个具有不同IP地址的伪造UDP数据包来缩小确切的源端口号，并根据收到的ICMP响应（或没有响应）来推断是否已命中正确的源端口。 这种端口扫描方法达到每秒1000个端口的扫描速度，累计需要60秒多一点的时间来枚举由65536个端口组成的整个端口范围。然后，攻击者所要做的就是插入一个恶意IP地址来重定向网站流量，并成功地完成DNS缓存中毒攻击。   减轻SAD DNS攻击 除了演示如何扩展攻击窗口（允许攻击者扫描更多端口并注入额外的恶意录来攻击DNS缓存）外，该研究还发现，互联网上超过34%的开放解析程序易受攻击，其中85%由流行的DNS服务（如Google和Cloudflare）组成。 为了应对SAD DNS，研究人员建议禁用传出的ICMP响应，并更积极地设置DNS查询的超时。 研究人员还提供了一种工具来检查容易受到此攻击的DNS服务器。此外，该小组与Linux内核安全团队合作开发了一个补丁，该补丁随机化ICMP全局速率限制，从而将噪声引入旁通道。 研究人员得出结论：“这项研究提出了一种基于全球ICMP速率限制的侧通道，所有现代操作系统都普遍采用这种限制。”“这可以有效扫描DNS查询中的UDP源端口。结合扩展攻击窗口的技术，可以导致DNS缓存中毒攻击死灰复燃。”       消息来源：The Hacker News ；封面来自网络；译者：芋泥啵啵奶茶。 本文由 HackerNews.cc 翻译整理。 转载请注明“转自 HackerNews.cc ” 

ZDNet 报道称，谷歌在过去三周时间内，修复了影响 Chrome 浏览器的五个凌日漏洞。在今日发布的 Chrome 86.0.4240.198 版本中，就包括了最新的两个。据悉，此前的三个零日漏洞，是谷歌内部安全研究人员发现的。而这次紧急修复的两个，则来自于不愿透露姓名的消息人士。 截止发稿时，谷歌尚未披露两个零日漏洞攻击的详情。但在 Chrome 86.0.4240.198 的变更日志中，该公司还是提到了两个通用漏洞披露编号。 首先是 CVE-2020-16013，其描述涉及 Chrome 组件中处理 JavaScript 代码的 V8 引擎的不当实现。 其次是 CVE-2020-16017，其描述涉及 Chrome 组件中负责隔离不同站点数据的‘释放后使用’内存泄露 bug 。 两个 CVE 的披露时间分别为周一和周三，不过遗憾的是，目前尚不清楚这两个漏洞是否需要被结合在一起使用，但是可以单独发挥一定的破坏力。 在此之前，Google 还修补了以下三个零日漏洞： ● CVE-2020-15999：Chrome 浏览器的 FreeType 字体渲染库问题，谷歌在 10 月 20 日完成了与 Windows 零日漏洞（CVE-2020-17087）的修补，但拖到了本周。 ● CVE-2020-16009：同样涉及 Chrome 的 JavaScript V8 引擎，谷歌在 11 月 2 日完成了修复。 ● CVE-2020-16010：这次主要与 Chrome for Android 有关，主要影响浏览器的用户界面（UI）组件。 目前尚不清楚上述漏洞的严重程度，但谷歌还是建议大家尽快更新至 86.0.4240.198 。不过鉴于大多数零日漏洞攻击仅会瞄向少数极具针对性的目标，普通用户其实没必要太过恐慌。       （消息来源：cnBeta；封面来自网络）

上个月，谷歌Project Zero的安全研究人员公布了Windows中一个正在被积极利用的零日漏洞的细节。黑客利用Windows内核加密驱动安全漏洞（CVE-2020-117087）在Windows 7、8、10以及Windows Server 2008和更高版本中获得高权限。作为昨晚发布的 “补丁星期二”的一部分，微软目前已经发布了该漏洞的修复程序。 被称为 “Windows Kernel Local Elevation of Privilege Vulnerability “的CVE-2020-17087早在10月22日就被微软曝光。通常情况下，Project Zero会在公开漏洞细节之前提供90天的宽限期，但由于该漏洞处于已经被利用的状态，因此将这一宽限期缩减至仅7天。 Project Zero团队解释道：Windows内核加密驱动(cng.sys)向用户模式程序暴露了一个\Device\CNG设备，并支持各种非常规输入结构的IOCTL。它构成了一个本地可访问的攻击面，可以利用它进行权限升级（甚至可被用于沙箱逃逸）。 在MSRC门户网站上，微软感谢Google Project Zero的Mateusz Jurczyk和Sergei Glazunov所做的工作，使开发团队迅速注意到了这个漏洞。 不同版本的Windows和Windows Server的修补程序链接可以在以下页面中找到： https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-17087       （消息来源：cnBeta；封面来自网络）

感谢腾讯御见威胁情报中心来稿！ 原文链接：https://mp.weixin.qq.com/s/hacyPAA82rgEBivwOYhuEg   一、概述 腾讯安全威胁情报中心在为客户提供安全巡检服务时，发现腾讯主机安全（云镜）告警SSH爆破入侵事件，遂对事件进行溯源追查，溯源到有疑似国内黑客开发的木马Kaiji通过22端口弱口令爆破入侵服务器。攻击者入侵云主机会下载二进制木马将自身安装到系统启动项进行持久化，并且可根据C2服务器返回的指令进行DDoS攻击。由于响应及时，客户未遭受损失。 腾讯威胁情报中心建议企业用户检查Linux服务器上是否存在以下文件，若存在，建议删除木马文件并将SSH的登陆口令设置为强密码。 /usr/lib/8uc_bt /usr/8uc_bt /boot/8uc_bt /root/8uc_bt.1 /root/8uc_bt /dev/8uc_bt /8uc_bt   腾讯安全系列产品针对Kaiji木马最新变种的响应清单如下： 应用 场景 安全产品 解决方案 威 胁 情 报 腾讯T-Sec 威胁情报云查服务 （SaaS） 1）Kaiji木马相关IOCs已入库。 各类安全产品可通过“威胁情报云查服务”提供的接口提升威胁识别能力。可参考:https://cloud.tencent.com/product/tics 腾讯T-Sec 高级威胁追溯系统 1）Kaiji木马相关信息和情报已支持检索。 网管可通过威胁追溯系统，分析日志，进行线索研判、追溯网络入侵源头。T-Sec高级威胁追溯系统的更多信息，可参考：https://cloud.tencent.com/product/atts 云原生 安全 防护 云防火墙 （Cloud Firewall，CFW） 基于网络流量进行威胁检测与主动拦截，已支持： 1)Kaiji木马关联的IOCs已支持识别检测； 2)检测SSH弱口令爆破攻击； 有关云防火墙的更多信息，可参考： https://cloud.tencent.com/product/cfw 腾讯T-Sec  主机安全 （Cloud Workload Protection，CWP） 1)已支持查杀kaiji木马程序； 2)支持检测SSH弱口令爆破攻击； 腾讯主机安全（云镜）提供云上终端的防毒杀毒、防入侵、漏洞管理、基线管理等。关于T-Sec主机安全的更多信息，可参考：https://cloud.tencent.com/product/cwp 腾讯T-Sec 安全运营中心 基于客户云端安全数据和腾讯安全大数据的云安全运营平台。已接入腾讯主机安全（云镜）、腾讯御知等产品数据导入，为客户提供漏洞情报、威胁发现、事件处置、基线合规、及泄漏监测、风险可视等能力。 关于腾讯T-Sec安全运营中心的更多信息，可参考：https://s.tencent.com/product/soc/index.html 非云企业安全防护 腾讯T-Sec 高级威胁检测系统 （腾讯御界） 1)已支持通过协议检测kaiji木马与服务器的网络通信； 关于T-Sec高级威胁检测系统的更多信息，可参考： https://cloud.tencent.com/product/nta 腾讯T-Sec终端安全管理系统（御点） 1）可查杀kaiji木马程序； 腾讯御点提供企业终端的防毒杀毒、防入侵、漏洞管理、基线管理等能力，关于T-Sec终端安全管理系统的更多资料，可参考：https://s.tencent.com/product/yd/index.html 二、详细分析 SSH是 Secure Shell的缩写，由IETF的网络小组（Network Working Group）所制定；SSH为建立在应用层基础上的安全协议。SSH是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议。云上服务器使用SSH服务的占比较高，而部分用户往往又未对其采取安全的配置，使得SSH监听在默认的22端口且不具备高强度密码、甚至使用空口令，导致黑客可轻易针对服务器22端口进行爆破入侵。Kaiji以root用户为目标，通过SSH暴力破解进行攻击传播。Kaiji通过根用户登陆，可以实现某些自定义网络数据包的DDoS攻击（在Linux中，自定义网络数据包仅提供给特权用户）。建立SSH连接后，会执行bash脚本，下载二进制木马文件8uc_bt并执行。 8uc_bt采用golang编写，执行后会通过修改系统初始化脚本init.d将恶意代码添加到启动项。 然后解密内置的C2服务器地址。     进入Main_doTask循环代码，从C2：a.kaiqingd.com:2323获取命令并执行。 执行的命令包括： DDoS指令； SSH暴力破解指令； 运行shell命令； 替换C2服务器； 删除自身和所有持久化任务。 其中DDoS 攻击类型包括： tcpflood udpflood getflood tapflood tcpddosag synddos 部分执行命令的函数名如下： main_runkshell：通过rc.d和Systemd服务安装持久性； main_runghost：通过/etc/profile.d（/etc/profile.d/linux.sh）安装持久化任务； main_rundingshi（汉字拼音：运行定时）：通过crontab安装持久化任务； main_runshouhu（汉字拼音：运行守护）：调用rootkit，将rootkit复制到/etc/32679并每30秒运行一次； main_Getjiechi、main_Jiechixieru、main_Jiechigo（汉字拼音：劫持写入）：通过劫持系统程序启动木马。 其中“dingshi”、“shouhu”、“jiechi”等汉语拼音字符显示该木马作者疑似来自国内。   IOC Md5 348e35db572ad76271220280c5a64190   C&C a.kaiqingd.com:2323   IP 113.200.151.118 (ZoomEye搜索结果）   参考链接： https://securityaffairs.co/wordpress/102753/malware/kaiji-linux-iot-malware.html https://www.intezer.com/blog/research/kaiji-new-chinese-linux-malware-turning-to-golang

过去几年，谷歌 Project Zero 团队已经披露过影响 Windows 10、macOS、iOS 等平台的严重安全漏洞。通常情况下，受影响的机构将有 90 天的时间来筹备修复，然后相关漏洞详情才会被公开披露。最新消息是，谷歌 Project Zero 团队刚刚披露了影响 GitHub 开源代码托管平台的一个“高度严重”的安全漏洞。 据悉，问题源于 GitHub Actions 中的工作流命令极易受到注入攻击。而所谓的 Actions，主要负责与“动作执行器”（Action Runner）之间的通信工作。 Felix Wilhelm 在审查源代码时发现了这个严重的安全隐患：“当进程解析至 STDOUT 的每一行，以寻找工作流命令时，每个 GitHub 操作都会在执行过程中打印出不受信任的内容”。 自 7 月 21 日发现该安全漏洞之后，Project Zero 团队已经及时向 GitHub 方面通报了此事，并为其提供了标准的 90 天宽限期（截止 10 月 18 日）。 最终 GitHub 决定弃用易受攻击的命令，并发出“中等严重的安全漏洞”的修补建议，通知开发者更新其工作流程。 10 月 16 日，GitHub 得到了 Project Zero 团队提供的额外 14 天宽限期，以完全禁用相关命令（新截止日期为 11 月 2 日）。 不过当 GitHub 试图再申请 48 小时的宽限期后，Project Zero 觉得一再拖延并不能解决问题，并且有违标准的漏洞披露流程，于是最终还是披露了漏洞详情和概念验证代码。     （消息来源：cnBeta；封面来自网络）