潜伏二十多年漏洞曝光，几乎所有 VPN 都中招
近日，纽约大学和鲁汶大学的研究人员发现大多数VPN产品中都存在长达二十多年的多个漏洞，攻击者可利用这些漏洞读取用户流量、窃取用户信息，甚至攻击用户设备。 “我们的攻击所需的计算资源并不昂贵，这意味着任何具有适当网络访问权限的人都可以实施这些攻击，且不受VPN安全协议限制。换而言之，无论VPN使用何种安全协议，所发现的漏洞都可能被滥用。即使是声称使用“军用级加密”或使用自行开发的加密协议的VPN（包括微软和苹果操作系统的内置VPN）也可能受到攻击。”纽约大学的Nian Xu声称： “即使受害者使用了HTTPS加密，我们的攻击也会泄露用户正在访问哪些网站，这可能会带来重大的隐私风险。” 四大数据泄露漏洞危及全球VPN客户端 研究者发现的四个普遍存在的VPN漏洞的CVE编号分别是：CVE-2023-36672、CVE-2023-35838、CVE-2023-36673和CVE-2023-36671。 CVE-2023-36672：LocalNet攻击导致明文流量泄漏。参考CVSS分数为6.8。 CVE-2023-35838：LocalNet攻击导致流量阻塞。参考CVSS分数为3.1。 CVE-2023-36673：ServerIP攻击与DNS欺骗相结合，可以将流量泄漏到任意IP地址。参考CVSS分数为7.4。 CVE-2023-36671：ServerIP攻击，只有VPN服务器真实IP地址的流量才会被泄露。参考CVSS分数为3.1。 第一对漏洞可在LocalNet攻击中被利用，即当用户连接到攻击者设置的Wi-Fi或以太网时（下图）： 后一对漏洞可被攻击者或恶意互联网服务提供商(ISP)所利用，通过不受信任的Wi-Fi/以太网发动ServerIP攻击。 ServerIP攻击示意图 研究人员表示：“这两种攻击都会操纵受害者的路由表，诱骗受害者将流量发送到受保护的VPN隧道之外，从而使对手能够读取和拦截传输的流量。” 除了数据泄露，此类攻击还产生另外一个风险：VPN通常用于保护较旧或不安全的协议，VPN防护失效意味着攻击者随后可以攻击较旧或不安全的协议，例如RDP、POP、FTP、telnet等。 研究者公布了多种攻击的视频演示 （https://www.youtube.com/watch?v=vOawEz39yNY&t=52s），还发布了可用于检查VPN客户端是否易受攻击的脚本（https://github.com/vanhoefm/vpnleaks）。 研究人员补充说：“一旦足够多的VPN设备修补了有关漏洞，如果有必要和/或有益，攻击脚本也将被公开发布。” 苹果设备VPN客户端几乎“全军覆没” 在测试了许多消费者和企业级VPN解决方案后，研究人员发现苹果设备上的VPN客户端几乎全军覆没（无论是Mac电脑、iPhone或iPad），Windows和Linux设备的VPN也很容易受到上述一种或两种攻击。在Android设备上，只有四分之一左右的VPN应用程序容易受到攻击——这可能与Android“精心设计”的API有关。 如上图所示，大多数Windows、macOS和iOS的内置VPN客户端都容易受到攻击，超过三分之一的Linux上的VPN客户端也是如此。 研究人员表示，他们并不知道这些漏洞是否在野外被利用，如果有的话，也很难发现。 据悉，研究人员已经向一些VPN供应商通报了他们发现的漏洞，其中一些供应商已经修复了漏洞，但却没有在更新说明中提及（以遵守研究人员在其研究发表之前的保密要求）。 研究人员在论文的末尾提供了各种设备上经过测试的VPN应用程序的完整列表，可供用户检查自己的VPN应用/客户端是否容易受到攻击。 缓解建议 研究人员指出：“一些VPN产品已经修复漏洞，包括Mozilla VPN、Surfshark、Malwarebytes、Windscribe（可以导入OpenVPN配置文件）和Cloudflare的WARP。” 思科已确认其适用于Linux、macOS和Windows的思科安全客户端和AnyConnect安全移动客户端容易受到CVE-2023-36672的影响，但仅限于特定的非默认配置。Mulvad则表示只有其iOS应用程序容易受到LocalNet攻击。 如果用户的VPN安全更新不可用，研究人员给出的建议是通过禁用本地网络访问来缓解LocalNet攻击。用户还可以通过确保网站使用HTTPS来缓解攻击，现在大多数网站都支持HTTPS。 转自GoUpSec，原文链接:https://mp.weixin.qq.com/s/66_qEv_K-CS3psoD9EaioQ 封面来源于网络，如有侵权请联系删除
有“安全锁”的网页≠合法安全 一半钓鱼网页都用上了 HTTPS
在以往的网购指南中，往往推荐用户访问带有“安全锁”（Chrome 68开始默认不显示，所有HTTP网页标记不安全）的电商网站，可以极大地免受网络钓鱼攻击或者恶意软件陷阱。然而不幸的是，这条推荐的意义已经不大了。最新研究结果表明，一半的钓鱼欺诈行为现在都托管在以“https://”开头标记有安全锁的网页上。 根据反网络钓鱼公司PhishLabs的最新数据，2018年第3季度中有49%的网络钓鱼站点在浏览器地址栏上都显示“安全锁”图标。而去年同期占比为25%，2018年第2季度占比为35%。这组数字的增长令人担忧，因为PhishLabs在去年的调查中发现，超过80%的受访者都认为带有“安全锁”的往往是合法的、安全的。 实际上，网址启用https://（也称Secure Sockets Layer，SSL），仅仅表示你在访问该网址所来回传输的数据，以及该网站已经加密，无法被第三方读取。显示“安全锁”并不意味着该网站就是合法，也不是表明该网站是否经过安全加固以阻止黑客入侵的证据。 该公司首席技术官John LaCour说：“PhishLabs认为网络钓鱼者同样可以使用SSL证书，最重要的是SSL的存在或者缺失并不能告诉你有关网站合法性的任何信息。” 稿源：cnBeta，封面源自网络；
Chrome 70 即将发布，数千个网站或因安全证书受影响
由于使用了旧的安全证书，互联网上的数千个网站将会在谷歌发布 Chrome 70 后受到影响 —— 访问这些网站的用户将会收到浏览器提示的安全警告。这是因为 Google 已放弃对赛门铁克在2016年6月之前发布的 HTTPS 安全证书的信任。 一年多前，当谷歌发现赛门铁克不正当地颁发安全证书时，谷歌方面就警告说它将放弃对来自赛门铁克受影响的批量证书的支持。简单来说，赛门铁克在2016年6月之前发布的安全证书都将不会受到 Chrome 70 的信任。因为谷歌早已在一年前就已公布时间表，所以 Web 开发者有一年多的时间来准备此更改。 安全研究员斯科特·赫尔姆(Scott Helme)在 Alexa 排名前 100 万个网站中发现超过 1000 个网站依然使用赛门铁克旧的安全证书，这些网站可能会受到谷歌推出 Chrome 70 的影响，其中包括一些来自印度和特拉维夫的知名政府网站。 据 TechCrunch 报道，除赛门铁克证书外，在2016年6月之前使用 Thawte, VeriSign, Equifax, GeoTrust 和 RapidSSL 颁发的证书的网站也将受到 Chrome 70 的影响。 稿源：开源中国，封面源自网络；
谷歌工程总监：用户不该操心网络安全 科技巨头需付出更多努力
在周三于拉斯维加斯举行的黑帽网络安全会议上，“谷歌安全公主”Parisa Tabriz 发表了主题演讲，期间讨论了与网络安装状况有关的问题。其主旨是，在线安全不应该是用户关注的重点所在，所以科技巨头们需要作出更多的努力。人们在日常生活中，一直被网络攻击的阴霾所笼罩，比如黑客会以电子邮件、信用卡、甚至政治为目标，由此带来了许多安全顾虑。 她在周二接受采访时称：所谓安全，应该是技术巨头们可以在网络上轻松保护每个人。 其为谷歌设立的终极目标是 —— 让安全成为第二天性，而不是你必须积极考虑实现的目标 —— 显然，这取决于互联网的“建筑师”们。 这趟旅程的重点是保障人们在 Web 上创建内容，但在默认设置下，他们中的绝大多数甚至根本不需要考虑这个问题。 虽然不知道何时会发生，但我认为事情正在朝着正确的方向去发展。 显然，Parisa Tabriz 想要避免制造让用户感到疲劳的“过多警告”。因为在频繁弹出警示信息的情况下，人们会开始变得相当麻木。 在过去四年时间里，谷歌发现了这一点，并且希望努力扭转该问题。值得庆幸的是，许多与 HTTPS 相关的安全指标，最终都会化解这个问题。 我们做了很多工作，使警告信息更易于理解、并了解对用户拥有的内容。作为一个普通人，你或许已经在过去两个月中留意到了一些变化。 比如，Chrome 地址栏前会显示一个绿色的锁状图标，并在旁边标注为‘安全’，以便告诉人们当前页面上的信息是值得信赖的。 不过 Parisa Tabriz 指出，谷歌最终还是决定摆脱它，因为该公司希望让安全性成为一个默认的事情，高亮的标签反而更显突兀。 于是在 7 月份的时候，Chrome 转而瞄准了哪些未使用 HTTPS 保护的网站，并在地址栏前显示‘不安全’。 不过，为了营造一个更加完全的互联网，所有科技巨头都必须投入其中 —— 而不仅仅依赖谷歌一个人的工作。 如果只有 Facebook 和谷歌在使用 HTTPS，那显然是不行的。即便访问的是个人博客网站，也必须让网友们相信，其阅读的是真正的内容，而没有被 ISP 给篡改。 好消息是，在 Let’s Encrypt 的倡议下，谷歌与 Mozilla 这两大浏览器厂商在合力推动 HTTPS 的采用。 稿源：cnBeta，封面源自网络；
Let’s Encrypt 保驾护航的 HTTPS 网站数量已突破1亿
备受欢迎的安全证书颁发机构 Let’s Encrypt 宣布，当前它已经为超过 1 亿个网站保驾护航，而且这个数字还在持续增长。仅在上个月，使用 HTTPS 保护的站点数量就增加了 2400 万。一天前，Google 刚刚宣布 —— 从 Chrome 68 开始，该浏览器将正式向所有不安全的 HTTP 站点开炮。 在谈到 Let’s Encrypt 和最近的消息时，项目负责人、前 Mozilla 雇员 Josh Aas 表示： 在 Let’s Encrypt 项目推出之前，让每个都启用 HTTPS 是不现实的，毕竟这对财务、技术、教育等方面提出了一定的要求。 我们着力于大规模的易用性工作，这就是近年来部署 HTTPS 的惊人增长的主要推动力。 今天，Let’s Encrypt 签发的加密证书已经覆盖了超过 1 亿个网站，且有望在 2018 年底前达到 1.5 亿+。 Let’s Encrypt 的增长，对业界来说是一个很好的标志性事件。因为它有助于保护人们在登录网站时不被黑客入侵，尤其是那些鱼龙混杂的公共网络。 结合 Google Chrome 突显 HTTP 不安全警告，我们预计可以大幅促进网络上 HTTPS 的增长。 遗憾的是，仍有许多大网站没有即时跟进部署 HTTPS，比如 WhyNoHttps.com 就指出： 中国仍有许多不安全的网站，此外 t.co、wikia.com、bbc.com、foxnews.com、dailymail.co.uk、roblox.com、sberbank.ru、speedtest.net、ladbible.com、ign.com、asos.com 等也不够安全。 稿源：cnBeta，封面源自网络；
Google Chrome 将从9月开始，默认 HTTPS 页面为安全站点
据外媒 bleepingcomputer 5月17日报道，谷歌正计划停止在地址栏中标记 HTTPS 页面为“安全”站点，换句话说，在没有发现异常的情况下，所有 HTTPS 的站点都会默认为安全，此举将于今年9月份发布的Chrome 69生效。 Chrome安全产品经理Emily Schechter表示，该公司现在可以通过HTTPS实现这一举措，因为Chrome的大部分流量都是通过HTTPS实现的，因此无需再将用户的注意力吸引到“安全”指标。 相反，Chrome将专注于突出显示用户访问不安全的HTTP网站时的情况。这就是为什么Google将把所有的HTTP网站都标记为“不安全”，这项举措从Chrome 68开始，将于7月发布。 此外，Google计划在Chrome 70中改进“不安全”指标，并增加一项动画，只要用户在 HTTP 网站上的表单中输入数据，就会将“不安全”文本变为红色。 这些更新是Google“HTTPS 100％”计划的一部分，最终目的是让加载到 Chrome 中页面都通过 HTTPS 协议。 “我们希望这些变化能够继续为安全使用网页铺平道路，”Schechter说。 “HTTPS比以往更便宜，更容易，并且可以解锁强大的功能 – 所以不要等待迁移到HTTPS！” 稿源：雷锋网，编译：郭佳，封面源自网络；
苹果公司解决 WebKit 框架中的 HSTS 用户跟踪问题
苹果公司为 WebKit 框架添加了新的保护措施，以防止可能滥用 HTTP 严格传输安全（HSTS）安全标准来跟踪用户。HSTS 提供了一种机制，通过这种机制，网站只能通过安全连接和直接浏览器访问安全版本所在的位置来声明自己。 基本上，当用户尝试连接到网站的不安全版本时，HSTS 强制浏览器转到网站的 HTTPS 版本。 由于 HSTS 告诉网络浏览器在被重定向到安全位置时记住并且将来自动去那里，可以创建一个“超级 cookie”，并且它可以被跨站点跟踪器读取。攻击者可以利用用户的 HSTS 缓存在设备上存储一位信息。 通过注册大量域并强制从受控子域中加载资源，攻击者“可以创建足够大的比特向量来唯一地表示每个站点访问者。” 在 HSTS 规范中描述了这个问题：“对于那些控制一个或多个 HSTS 主机的人来说，将信息编码成他们控制的域名是可能的，并且使得这些 UA 缓存这些信息当然是在注意 HSTS 的过程中 主办。 这些信息可以由其他主机通过巧妙构建和加载的网络资源来检索，导致 UA 发送查询到（变体）编码的域名。“ 缓解这种跟踪攻击并不容易，因为它需要平衡安全和隐私目标。 但是，由于 HSTS 的隐私风险仅作为理论追踪向量呈现，但尚未提供实际恶意滥用协议的证据，因此浏览器将遵守网站提供的所有 HSTS 指令。 苹果最近意识到这种理论攻击已经开始针对 Safari 用户进行部署。 这促使这家科技巨头开创了一个既保护安全网络流量又减少跟踪的解决方案。由于 HSTS 漏洞需要创建一个初始跟踪标识符并读取它，苹果建议对攻击双方进行缓解。 一方面，苹果公司修改了网络堆栈，只允许为加载的主机名或顶级域 + 1 设置 HSTS 状态。因此，跟踪器不能再有效地在大量不同的位上设置 HSTS，但需要单独 访问跟踪标识符中具有活动位的每个域。 WebKit 还限制了可以链接在一起的重定向数量，从而限制了可以设置的位数。另一方面，当动态 HSTS 导致一个不安全的第三方子资源从被阻塞的 cookie 升级到认证连接的域中加载时，苹果还修改了 WebKit 以忽略 HSTS 升级请求（并使用原始 URL）。 在内部回归测试，公共种子和最终的公共软件发布期间收集的遥测数据表明，上述两种缓解成功地阻止了 HSTS 超级 cookie 的创建和阅读，同时又不会使第一方内容的安全目标退步。 我们相信他们符合最佳实践，并保持 HSTS 提供的重要安全保护。 稿源：东方安全，封面源自网络；
更多钓鱼网站正使用 HTTPS 加密以欺骗受害用户
虽然 HTTPS 的使用有助于保障互联网用户在浏览器和网站之间的数据安全，但越来越多的网络钓鱼方案正在利用人们对绿色小挂锁的无知。网络钓鱼防范公司 PhishLabs 近期发布了一个新的报告，显示在 HTTPS 页面上托管钓鱼网站的速度明显快于整个 HTTPS 的采用速度。 根据发布超过 1 亿个加密证书的 Let’s Encrypt 表示，上个月 FireFox 加载的网页中有 65% 使用 HTTPS，2016 年底这个数字是 45%。与此同时，24% 的钓鱼网站使用网络加密。就在一年前，这些网站中只有不到 3% 使用了 HTTPS，2015 年这个数字还不到百分之一。针对 PayPal 和 Apple 这两个主要攻击目标的 Q3 HTTPS 钓鱼攻击分析表明，近四分之三的 HTTPS 钓鱼网站托管在恶意注册的域名上，而不是建立在被黑的网站上。 钓鱼者转向 HTTPS 的主要原因是许多人认为绿色的挂锁是网站可信度的标志。证书显示数据在传输中加密，这并不意味着该网站已经采取安全措施并且合法。正如 Wired 指出的，问题之一是证书颁发机构无法检查每个站点，以确保它不包含网络钓鱼或恶意软件攻击。而且，许多要求加密证书的网站当时没有任何内容。 稿源：cnBeta，封面源自网络；
Chrome 将会对 HTTP Web 表单显示不安全警告
Chrome 和 Firefox 主要浏览器开发商正致力推动 Web 的 HTTPS，逐渐采取措施对 HTTP 网页显示不安全警告。 据悉，Chrome 从 4 月开始对输入密码或信用卡号码的 HTTP 网页显示不安全警告。从今年 10 月开始，Chrom 62 将会增加两种不安全警告的显示情况：用户在 HTTP 页面输入数据，或者在隐身模式下浏览 HTTP 网页。Google 最终计划将所有 HTTP 网页标记为不安全。 稿源：solidot奇客，封面源自网络；
新型银行恶意软件 Pinkslipbot 利用受感染设备作为 “HTTPS 控制服务器”通信
据外媒 6 月 19 日报道，McAfee Labs 安全研究人员发现一款新型银行恶意软件 Pinkslipbot（又名：QakBot / QBot）可使用复杂多级代理通过 “HTTPS 控制服务器”通信。 Pinkslipbot 最初于 2009 年被赛门铁克检测曝光，是首款利用受感染机器作为 HTTPS 控制服务器的恶意软件。此外，Pinkslipbot 还是一款具有后门功能的爬虫，可在采集登录凭证的僵尸网络中聚集受感染设备。近期，Pinkslipbot 变种新增了高级规避检测功能。 安全专家注意到，Pinkslipbot 使用通用即插即用（UPnP）功能为目标设备提供路径，以感染恶意软件 IP 地址列表中提供的 HTTPS 服务器。这些设备充当 HTTP 代理并将路径传输至另一层 HTTPS 代理，能够允许对真实的 C＆C 服务器 IP 地址进行伪装。 据悉，该恶意软件只能使用美国 IP 地址利用 Comcast Internet 测速仪检测目标设备是否连接。如果目标通过速度测试，恶意软件将点击 UPnP 端口检查可用服务。目前，研究人员尚未分析清楚攻击者如何判定“受感染设备有资格成为控制服务器代理”的确切程序。 研究人员认为，评价结果或将取决于受感染机器是否满足三个条件，即 IP 地址位于北美、高速上网以及使用 UPnP 打开 Internet 网关设备端口的能力。一旦检测到可用端口，恶意软件将感染防火墙后的目标设备并通过建立永久端口映射路由流量，旨在起到 C&C 代理的作用。 目前，受感染机器从新 Pinkslipbot 感染源接收到控制服务器请求后，立即通过使用 libcurl URL 传输库的附加代理将所有流量路由传输至真实控制服务器中。为防止设备感染该恶意软件，用户应保留本地端口传输规则，并仅在必要时打开 UPnP。 原作者：Pierluigi Paganini， 译者：青楚，译审：游弋 本文由 HackerNews.cc 翻译整理，封面来源于网络。 转载请注明“转自 HackerNews.cc ” 并附上原文链接