标签: CloudFlare

Cloudflare 的 ACME 漏洞允许攻击者直达源站服务器

HackerNews 编译,转载请注明出处: Cloudflare 已修复其 ACME 验证逻辑中的一项漏洞,该漏洞可能允许攻击者绕过安全检查并访问受保护的源站服务器。 Cloudflare 表示,其 ACME HTTP-01 验证流程中存在缺陷,问题出在Cloudflare 边缘节点对 /.well-known/acme-challenge/ 路径请求的处理方式上。该公司称,未发现该漏洞被恶意利用的迹象。 ACME 是一种用于让证书颁发机构验证域名所有权的协议。在 HTTP-01 验证方式下,CA 会访问一个包含一次性令牌的特定 URL;如果返回内容匹配,即可签发证书。按设计,该过程只应允许访问这一精确路径,而不能访问其他任何资源。 漏洞是如何被发现的 研究人员在测试部署在 Cloudflare 之后、且 WAF 仅允许特定来源访问的应用时发现,对/.well-known/acme-challenge/{token}的请求绕过了 WAF,并直接到达源站服务器。 在演示主机上的测试证实了这一行为: 对普通路径的访问会返回 Cloudflare 的拦截页面; 而对 ACME 路径的访问,即使没有真实的令牌,也会返回由源站生成的响应。 研究人员通过自定义主机名创建了一个稳定、处于待验证状态的 HTTP-01 令牌,从而能够在全球范围内可靠地测试 WAF 的行为。 潜在风险与影响 当 Cloudflare 的 WAF 允许 /.well-known/acme-challenge/... 路径绕过防护时,信任边界从 WAF 转移到了源站。演示应用显示了由此带来的多种风险,包括: Spring / Tomcat 端点泄露敏感的环境变量 Next.js SSR 页面暴露运行和运维细节 PHP 路由因本地文件包含漏洞暴露文件 此外,账户级 WAF 规则在该路径上被忽略,使基于请求头的攻击成为可能,例如 SSRF、SQL 注入和缓存投毒。 Cloudflare 已于 2025 年 10 月 27 日 修复该问题,恢复了对该路径的一致性 WAF 防护。 研究人员的警告 安全研究机构 FearsOff 在报告中指出: “当用于检查请求头的 WAF 规则被跳过时,许多漏洞类型就重新获得了通往源站的通道:例如遗留代码中基于请求头的 SQL 拼接、通过 X-Forwarded-Host 或 X-Original-URL 实现的 SSRF 和主机混淆、当缓存因请求头变化而产生的缓存键投毒、利用 X-HTTP-Method-Override 的方法覆盖技巧,以及通过自定义请求头触发的调试开关。显而易见的问题是——还有多少应用对请求头的信任程度超出应有范围?又有多少应用依赖 WAF 来充当这种信任与互联网之间的防线?” AI 时代下的 WAF 绕过风险 报告还强调,随着 AI 驱动攻击的发展,这类 WAF 绕过漏洞的危险性正在上升。AI 能够迅速发现并利用暴露的路径,将多个小漏洞串联成大规模攻击。与此同时,防御方也在使用 AI 进行攻击模拟和防御部署,使强健、全面的 WAF 防护变得愈发关键。 报告总结称: “在 AI 驱动攻击不断演进的背景下,这类 WAF 绕过漏洞显得尤为紧迫。由机器学习驱动的自动化工具可以快速枚举并利用诸如 /.well-known/acme-challenge/ 这样的暴露路径,在大规模环境中探测特定框架的弱点或配置错误。” 消息来源:securityaffairs; 本文由 HackerNews.cc 翻译整理,封面来源于网络; 转载请注明“转自 HackerNews.cc”并附上原文

Cloudflare遭数据泄露,涉 Salesloft Drift 供应链攻击

HackerNews 编译,转载请注明出处: Cloudflare成为近期一系列Salesloft Drift泄露事件的最新受影响公司,这些事件是上周披露的一起供应链攻击的一部分。 这家互联网巨头于周二透露,攻击者获得了其用于内部客户案例管理和客户支持的Salesforce实例的访问权限,该实例包含104个Cloudflare API令牌。 Cloudflare于8月23日收到漏洞通知,并于9月2日向受影响的客户通报了该事件。在将攻击事件告知客户之前,该公司还轮换了所有在泄露期间被窃取的104个由Cloudflare平台颁发的令牌,尽管尚未发现与这些令牌相关的任何可疑活动。 “这些信息大部分是客户联系信息和基本支持案例数据,但一些客户支持互动可能会透露客户配置信息,并可能包含访问令牌等敏感信息,”Cloudflare表示。 “鉴于Salesforce支持案例数据包含与Cloudflare的支持工单内容,客户可能通过我们的支持系统与Cloudflare共享的任何信息——包括日志、令牌或密码——都应视为已泄露,我们强烈建议您轮换可能通过此渠道与我们共享的任何凭据。” 公司的调查发现,在8月9日的初步侦察阶段之后,威胁行为者在8月12日至8月17日期间仅窃取了Salesforce案例对象中包含的文本(包括客户支持工单及其相关数据,但不包括附件)。 这些被窃取的案例对象仅包含基于文本的数据,包括: Salesforce案例的主题行 案例正文(如果客户向Cloudflare提供,可能包含密钥、机密信息等) 客户联系信息(例如,公司名称、请求者的电子邮件地址和电话号码、公司域名和公司所在国家) “我们认为这起事件并非孤立事件,而是威胁行为者意图收集凭证和客户信息以供未来攻击之用,”Cloudflare补充道。 “鉴于此次Drift漏洞事件影响了数百家组织,我们怀疑威胁行为者将利用这些信息对受影响组织的客户发起针对性攻击。” Salesforce数据泄露浪潮 今年以来,ShinyHunters勒索组织一直以 Salesforce 客户为目标进行数据窃取攻击,他们使用语音钓鱼(vishing)欺骗员工将恶意的 OAuth 应用程序与其公司的 Salesforce 实例关联起来。这种策略使攻击者能够窃取数据库,随后用于勒索受害者。 自谷歌在6月份首次报道这些攻击以来,多起数据泄露事件都与ShinyHunters的社会工程策略有关,包括针对谷歌自身、思科、澳洲航空(Qantas)、安联人寿(Allianz Life)、农夫保险(Farmers Insurance)、Workday、阿迪达斯(Adidas),以及路威酩轩(LVMH)子公司路易威登(Louis Vuitton)、迪奥(Dior)和蒂芙尼(Tiffany & Co.)的攻击。 尽管一些安全研究人员告诉BleepingComputer,Salesloft供应链攻击涉及相同的威胁行为者,但谷歌尚未找到确凿证据将它们联系起来。 其他受害企业 Palo Alto Networks也在周末确认,Salesloft Drift漏洞背后的威胁行为者窃取了一些客户提交的支持数据,包括联系信息和文本评论。 Palo Alto Networks的事件也仅限于其Salesforce CRM,正如该公司告诉BleepingComputer的那样,它没有影响任何其产品、系统或服务。 这家网络安全公司观察到攻击者搜索机密信息,包括AWS访问密钥(AKIA)、VPN和SSO登录字符串、Snowflake令牌,以及诸如“secret”、“password”或“key”之类的通用关键词,这些信息可能被用于入侵更多云平台以窃取数据,从而进行其他勒索攻击。       消息来源:bleepingcomputer; 本文由 HackerNews.cc 翻译整理,封面来源于网络; 转载请注明“转自 HackerNews.cc”并附上原文

Cloudflare 成功拦截了创纪录的 DDoS 攻击,峰值为 11.5 Tbps

HackerNews 编译,转载请注明出处: Cloudflare成功拦截了峰值达11.5 Tbps的创纪录DDoS攻击,这是一场主要源自谷歌云的UDP洪水攻击,也是持续数周的攻击浪潮的一部分。 Cloudflare在X平台上宣布,其已拦截了有史以来最大规模的DDoS攻击,峰值达到11.5 Tbps。这场主要来自谷歌云的UDP洪水攻击,是持续数周攻击浪潮的一部分。 Cloudflare表示,其在数周内已拦截了数百次大规模DDoS攻击,此次破纪录的UDP洪水攻击持续了约35秒。 “Cloudflare的防御系统一直超负荷运转。过去几周,我们的系统自动拦截了数百起超大规模DDoS攻击,其中最大攻击的峰值达到每秒51亿个数据包(5.1 Bpps)和11.5 Tbps。这场11.5 Tbps的攻击是一场主要源自谷歌云的UDP洪水攻击。” 今年6月,Cloudflare曾宣布在2025年第二季度自动拦截了已报告的最大规模DDoS攻击,峰值达到7.3 Tbps和每秒48亿个数据包(4.8 Bpps)。 该攻击规模比其之前的峰值高出12%,比知名网络安全记者布莱恩·克雷布斯(Brian Krebs)所报告的攻击峰值高出1 Tbps。 这场7.3 Tbps的DDoS攻击在短短45秒内喷射了37.4 TB的数据流量,相当于在一分钟内流畅播放9350部高清电影或下载935万首歌曲。其数据量相当于连续播放近一年的高清视频,或者压缩了4000年每日高清照片的数据总量,所有这些都塞进了不到一分钟的时间里。 Cloudflare发布的报告中写道:“37.4TB在当今的数据规模中并不惊人,但在45秒内喷射如此巨量数据堪称恐怖。” “这相当于在45秒内,向你的网络倾泻超过9350部全长高清电影的数据量,或者连续播放7480小时的高清视频(这几乎是接连不停 binge-watch 近一年的量)。” 此次攻击针对单个IP地址,平均每秒冲击21,925个端口,峰值时达到34,517个端口,源端口分布同样广泛。 这场7.3 Tbps的DDoS攻击采用多向量组合模式,其中99.996%为UDP洪水攻击,其余包括QOTD、Echo、NTP、Mirai、Portmap以及RIPv1攻击。       消息来源:securityaffairs; 本文由 HackerNews.cc 翻译整理,封面来源于网络; 转载请注明“转自 HackerNews.cc”并附上原文

Cloudflare 证实俄罗斯限制对其服务的访问

HackerNews 编译,转载请注明出处: 俄罗斯互联网服务提供商(ISP)对受Cloudflare保护的网站实施访问限制,导致该国网络流量严重中断。美国互联网基础设施公司Cloudflare证实,自6月9日起实施的限流措施使俄罗斯用户无法正常访问依赖其平台的网站和服务。该公司内部数据显示,ISP将每次请求的数据传输量限制在仅16KB,导致多数网站功能瘫痪。 Cloudflare声明:“限流行为超出我方控制范围,目前无法以合法方式为俄罗斯用户恢复稳定高性能的访问服务。”俄罗斯联邦通信监管局(Roskomnadzor)数月来持续打压Cloudflare,德国Hetzner、美国DigitalOcean及法国OVH等其他外国云服务商也遭遇类似限制。该机构呼吁用户停用这些服务,转向本土托管提供商。 技术封锁手段包括: 深度包检测:通过注入虚假数据包中断连接,或直接阻断数据引发超时。 协议层限制:影响TCP/TLS协议的HTTP/1.1/2及QUIC协议的HTTP/3。 流量整形:针对境外服务器实施无差别限流,即使连接请求发自俄罗斯境内。 2024年11月,俄方曾因Cloudflare的加密客户端问候(ECH)技术能隐藏用户访问目标网站信息,以“规避政府审查”为由封禁数千家使用该服务的网站。此次限流后,俄罗斯境内Cloudflare流量骤降30%,但当局否认存在此类干扰行为。 企业影响与应对 小型电商企业受冲击最严重,可能面临流量大幅流失。俄罗斯本土服务目前仍无法完全替代Cloudflare的DDoS防护能力,迁移过程成本高昂且技术复杂。Cloudflare建议俄罗斯站点运营商联系当地机构要求解除限制,同时指出:“若您的网站使用Cloudflare防护,当前我们无法为俄罗斯用户恢复网络连接。” 地缘技术博弈 与多数西方科技公司不同,Cloudflare在2022年俄乌冲突后未完全退出俄罗斯市场,当时声明“俄罗斯需要更多而非更少的互联网访问”。但该公司终止了受制裁实体的服务,包括金融机构和影响活动相关客户。部分俄企因Cloudflare的美国背景主动停用其服务,但更多企业仍依赖其防护能力应对日益增长的DDoS攻击浪潮。       消息来源: therecord; 本文由 HackerNews.cc 翻译整理,封面来源于网络; 转载请注明“转自 HackerNews.cc”并附上原文

峰值 7.3Tbps!Cloudflare 成功拦截史上最大 DDoS 攻击

HackerNews 编译,转载请注明出处: 网络基础设施服务商Cloudflare近日拦截了一次峰值达7.3Tbps的分布式拒绝服务(DDoS)攻击,再度刷新历史纪录。此前Cloudflare拦截的最高纪录为5.6Tbps和6.5Tbps攻击,而网络安全博主布莱恩·克雷布斯(Brian Krebs)上月报告其网站曾遭遇6.3Tbps攻击。 此次发生于5月中旬的7.3Tbps攻击仅持续45秒,目标直指某托管服务提供商。“托管服务商与关键互联网基础设施正日益成为DDoS攻击的主要目标”,Cloudflare在周四的博客中指出。此次攻击在45秒内产生37.4TB流量,相当于传输9000多部高清电影的数据总量。 攻击聚焦单一IP地址,平均每秒冲击21,925个目标端口,峰值时达34,517个端口,且源端口分布呈现类似特征。本次攻击中99%以上为UDP洪水攻击,其余1.3GB流量包含六种复合攻击:QOTD反射攻击、Echo反射攻击、NTP反射攻击、Mirai僵尸网络发起的UDP洪水攻击、Portmap洪水攻击以及RIPv1放大攻击。攻击源覆盖161个国家/地区的5,400个自治系统中的122,000余个IP地址。     消息来源: securityweek; 本文由 HackerNews.cc 翻译整理,封面来源于网络; 转载请注明“转自 HackerNews.cc”并附上原文

Cloudflare R2 服务故障由密码轮换错误引发

HackerNews 编译,转载请注明出处: Cloudflare宣布,其R2对象存储及相关服务出现了一次持续1小时7分钟的故障,导致全球100%的写入请求和35%的读取请求失败。 Cloudflare R2是一种可扩展的、与S3兼容的对象存储服务,具有免费的数据检索、多区域复制以及与Cloudflare的紧密集成等特点。 此次故障发生在UTC时间21:38至22:45之间,据称是由一次凭证轮换操作导致R2网关(API前端)失去对后端存储的认证访问权限所引发的。 具体而言,新凭证被错误地部署到了开发环境而非生产环境,而当旧凭证被删除后,生产服务便失去了有效的凭证。 问题的根源在于遗漏了一个命令行标志’–env production’,这导致新凭证被部署到了生产R2网关工作程序而非生产工作程序。 R2网关工作程序认证示意图(图片来源:Cloudflare) 由于问题的性质以及Cloudflare服务的工作方式,这一错误配置并未立即显现,导致修复工作进一步延迟。 “R2可用性指标的下降是逐渐的,并非立即显而易见,因为之前凭证删除到存储基础设施的传播存在延迟,”Cloudflare在其事件报告中解释道。 “这导致我们最初发现问题存在延迟。在更新旧凭证集后,我们不应依赖可用性指标,而应明确验证R2网关服务用于认证R2存储基础设施的令牌。” 尽管此次事件未导致客户数据丢失或损坏,但仍造成了部分或全部服务降级,影响了以下服务: R2:100%写入请求失败,35%读取请求失败(缓存对象仍可访问) 缓存储备:由于读取请求失败,源流量增加 图片和流媒体:所有上传请求失败,图片传输量降至25%,流媒体降至94% 电子邮件安全、向量化、日志交付、计费、密钥透明度审计员:不同程度的服务降级 为防止类似事件在未来再次发生,Cloudflare改进了凭证日志记录和验证,并强制使用自动化部署工具,以避免人为错误。 公司还正在更新标准操作程序(SOP),要求对凭证轮换等高影响操作进行双重验证,并计划增强健康检查,以便更快地发现根本原因。 Cloudflare的R2服务在2月也曾因人为错误导致1小时的故障。 当时,一名操作员在处理有关服务中钓鱼URL的滥用报告时,关闭了整个R2网关服务,而不是仅阻止特定端点。 由于缺乏对高影响操作的安全保障和验证检查,导致了此次故障,促使Cloudflare计划并实施额外措施,以改进账户配置、更严格的访问控制以及对高风险操作的两方批准流程。   消息来源:Bleeping Computer;  本文由 HackerNews.cc 翻译整理,封面来源于网络;   转载请注明“转自 HackerNews.cc”并附上原文

Cloudflare 现已屏蔽所有未加密的 API 端点流量

HackerNews 编译,转载请注明出处: Cloudflare宣布,已关闭所有HTTP连接,现在仅接受api.cloudflare.com的安全HTTPS连接。 此举旨在防止未加密的API请求被发送,即使是意外发送的,也会在服务器关闭HTTP连接并重定向到安全通信通道之前,消除敏感信息在明文流量中暴露的风险。 “从今天起,任何未加密的连接到api.cloudflare.com都将被完全拒绝,”Cloudflare周四的公告中写道。 “开发者不应再期望HTTP连接出现403禁止响应,因为我们将通过完全关闭HTTP接口来阻止底层连接的建立。只允许建立安全的HTTPS连接,”这家互联网服务公司补充道。 Cloudflare API帮助开发者和系统管理员自动化和管理Cloudflare服务。它用于DNS记录管理、防火墙配置、DDoS防护、缓存、SSL设置、基础设施部署、访问分析数据以及管理零信任访问和安全策略。 此前,Cloudflare系统允许通过HTTP(未加密)和HTTPS(加密)访问API,要么通过重定向,要么拒绝HTTP。 然而,正如公司所解释的,即使被拒绝的HTTP请求也可能在服务器响应之前泄露敏感数据,如API密钥或令牌。 当连接通过公共或共享Wi-Fi网络时,这种场景更加危险,因为中间人攻击更容易得逞。 通过完全禁用API访问的HTTP端口,Cloudflare在传输层屏蔽了明文连接,在任何数据交换之前强制执行HTTPS。 影响和下一步行动 这一变化立即影响了使用Cloudflare API服务的HTTP协议的任何人。依赖该协议的脚本、机器人和工具将中断。 同样适用于遗留系统和自动客户端、物联网设备以及由于配置不当而不支持或不默认使用HTTPS的低级客户端。 对于在Cloudflare上有网站的客户,公司计划在年底前推出一个免费选项,以安全的方式禁用HTTP流量。 Cloudflare数据显示,所有通过其系统的互联网流量中,仍有约2.4%是通过不安全的HTTP协议进行的。当考虑到自动化流量时,HTTP的份额跃升至近17%。 客户可以在仪表板的“分析与日志”>“通过SSL提供的流量”下跟踪HTTP与HTTPS流量,然后再选择加入,以评估这对他们环境的影响。   消息来源:Bleeping Computer;  本文由 HackerNews.cc 翻译整理,封面来源于网络;   转载请注明“转自 HackerNews.cc”并附上原文

Cloudflare 封堵网络钓鱼 URL 时操作失误引发大规模故障

HackerNews 编译,转载请注明出处: Cloudflare 在其 R2 对象存储平台中试图封堵一个网络钓鱼 URL 时出现失误,引发了一场大规模故障,导致多个服务在近一个小时内瘫痪。 Cloudflare R2 是一种类似于亚马逊 S3 的对象存储服务,旨在提供可扩展、耐用且低成本的数据存储。它提供免费的数据检索、S3 兼容性、跨多个地点的数据复制以及 Cloudflare 服务集成。 故障发生在昨天,当时一名员工响应了一起关于 Cloudflare R2 平台中网络钓鱼 URL 的滥用报告。然而,该员工并未封堵特定端点,而是错误地关闭了整个 R2 网关服务。 Cloudflare 在事后分析中解释道:“在一次常规的滥用补救过程中,由于处理投诉时的失误,意外禁用了 R2 网关服务,而非与报告相关的特定端点/存储桶。” “这是多个系统级控制(首先是)和操作员培训的失败。” 该事件持续了 59 分钟,从世界协调时 08:10 到 09:09,除了 R2 对象存储本身外,还影响了以下服务: Stream – 视频上传和流媒体传输 100% 失败。 Images – 图像上传/下载 100% 失败。 Cache Reserve – 操作 100% 失败,导致源请求增加。 Vectorize – 查询失败 75%,插入、更新和删除操作 100% 失败。 Log Delivery – 延迟和数据丢失:与 R2 相关的日志数据丢失高达 13.6%,非 R2 交付作业的数据丢失高达 4.5%。 Key Transparency Auditor – 签名发布和读取操作 100% 失败。 还有一些间接影响的服务出现了部分故障,例如 Durable Objects,由于恢复后的重新连接,其错误率增加了 0.09%;Cache Purge 错误增加了 1.8%(HTTP 5xx),延迟飙升了 10 倍;Workers & Pages 的部署失败率为 0.002%,仅影响具有 R2 绑定的项目。 Cloudflare 指出,人为错误以及缺乏诸如高影响操作的验证检查等防护措施是此次事件的关键原因。 这家互联网巨头现已实施了即时修复措施,例如在滥用审查界面中移除关闭系统的能力,以及在管理 API 中对内部账户的服务禁用进行限制。 未来还将实施的额外措施包括改进账户配置、更严格的访问控制,以及对高风险操作的双人审批流程。 2024 年 11 月,Cloudflare 曾经历另一次长达 3.5 小时的显著故障,导致服务中 55% 的日志不可逆丢失。 那次事件是由 Cloudflare 日志处理管道中的一个关键组件被错误配置引发的级联故障。   消息来源:Bleeping Computer, 编译:zhongx;  本文由 HackerNews.cc 翻译整理,封面来源于网络;   转载请注明“转自 HackerNews.cc”并附上原文

出于“对人类生命的直接威胁” Cloudflare 宣布屏蔽 Kiwi Farms

网站安全和托管服务提供商 Cloudflare 于上周六宣布,将对鹬鸵农场(Kiwi Farms,充斥大量有害内容的在线论坛)采取屏蔽措施。在官方博文中,鹬鸵农场过去两天“有针对性的威胁”有所增加,对人类生命构成了“直接威胁”。 Kiwi Farms(官方中文名“鹬鸵农场”)是一个臭名昭著的美国论坛,致力于寻找互联网上的“lolcows(指值得被取笑的人)”,他们喜欢寻找那些看起来脆弱容易内心敏感容易受伤的人当作目标,把作恶当作一场电子游戏,尽其所能地让受害者感到精神上的难以解脱,并以此为乐。被鹬鸵农场盯上的目标往往会受到有组织的持续不断的骚扰。 充斥于鹬鸵农场的网络暴力已经导致天才模拟器程序员 Near 在内的不少人抑郁、自杀。在跨性别 YouTuber 和 Twitch 主播 Clara Sorrenti (Keffals) 成为该网站用户的危险骚扰活动的目标之后,人们对 Kiwi Farms 的担忧日益增加。上个月,Kiwi Farms 用户对 Sorrenti 发起了猛烈攻击,也就是向警方提供虚假提示,表明有人计划实施暴力犯罪,导致警方蜂拥而至受害者家中。 Sorrenti 后来躲藏起来并发起了#DropKiwifarms 活动,敦促 Cloudflare 停止为 Kiwi Farms 提供服务。 Twitter 上的用户分享了这个标签,其中一些人还透露了他们在 Kiwi Farms 用户手中所经历的骚扰。 Cloudflare 最初拒绝放弃 Kiwi Farms 的呼吁,称这样做是“滥用权力”。在上周发布到其网站的更新中,Cloudflare 概述了其关于滥用内容的政策,提出了维护服务的论据,但没有明确提及 Kiwi Farms。 转自 cnBeta ,原文链接:https://www.cnbeta.com/articles/tech/1312403.htm 封面来源于网络,如有侵权请联系删除

继 Twilio 后,Cloudflare 员工也遭到了同样的钓鱼攻击

继昨日FreeBuf报道了《员工被钓鱼,云通讯巨头Twilio客户数据遭泄露》后,8月9日,知名云服务提供商Cloudflare 也表示,一些公司员工的系统账户凭证也在一次网络钓鱼短信攻击中被盗,手法和上周 Twilio批露的遭遇如出一辙。 根据Cloudflare在官方博客发布的说明,大约在 Twilio 遭到攻击的同时, Cloudflare 的员工也遭到了具有非常相似特征的攻击 ,有至少 76 名员工的个人或工作手机号码收到了钓鱼短信,一些短信也发送给了员工的家人。虽还无法确定攻击者是以何种方式收集到了员工手机号码,但得益于Cloudflare采用了符合 FIDO2 标准的安全密钥,即使攻击者拿到了员工账户,在尝试登陆时均被成功阻止。 Cloudflare也透露,钓鱼短信提供了一个域名为cloudflare-okta.com的克隆登录页面,在该页面上输入凭证后,AnyDesk 远程访问软件会自动下载到计算机上,从而允许攻击者远程控制其设备。该域名是通过 Porkbun注册,和 Twilio攻击中出现的钓鱼登录页面的域名系同一家注册商。 发送给 Cloudflare 员工的网络钓鱼短信 (Cloudflare) 在这起攻击事件中,Cloudflare采用了多种手段进行防御: 使用 Cloudflare Gateway 阻止钓鱼页面 识别所有受影响的 Cloudflare 员工账户并重置受损凭证 识别并拆除攻击者部署的基础设施 更新检测以识别任何后续攻击尝试 审核服务访问日志以获取任何其他的攻击迹象 可见,Cloudflare凭借有效的防御手段成功抵御了这次钓鱼攻击,Twilio 则未能幸免,尽管事后 Twilio 通过联系运营商和服务提供商对关闭了攻击者的URL,但攻击者也能通过更换运营商和服务提供商的方式继续他们的攻击。所以俗话说的好,打铁还需自身硬。 转自 FreeBuf,原文链接:https://www.freebuf.com/news/341481.html 封面来源于网络,如有侵权请联系删除