Aggregator

Leaderboard Race May Be More Marketing Than Merit
Artificial intelligence model makers routinely publish benchmark scores of their performance, but the leaderboard race may be more of an exercise in marketing than an accurate reflection of the models' abilities. Understanding model failures can be more valuable than celebrating high scores.

Use Other Than for Police Purposes Can Invoke Fine Up to 20 Million Euros
The Italian Data Protection Authority warned against unlawful use of Graphite spyware following reports of mass hacking campaigns using the tool. The Italian privacy regulator published a warning targeting commercial spyware developed by Israeli firm Paragon Solutions.

Разработчикам придётся адаптировать свои приложения к изменениям в API.

HackerNews 编译，转载请注明出处： 社交媒体平台 X（原 Twitter）现已开始屏蔽指向 “Signal.me” 的链接，该链接是 Signal 加密消息应用用于分享用户账户信息的一种方式。 据 BleepingComputer 测试和其他用户的报告，尝试通过公开帖子、私信或个人简介发布 Signal.me 链接时，会收到错误提示，称存在垃圾邮件或恶意软件风险。 当用户尝试发送 Signal.me 链接时，会看到如下错误提示：“此请求看起来可能是自动化的。为了保护我们的用户免受垃圾邮件和其他恶意活动的侵害，我们目前无法完成此操作。请稍后再试。” 我们的测试显示，只有包含 “signal.me” URL 的消息才会被屏蔽。 记者 Matt Binder 首次报道了这一问题，他表示目前尚不清楚这一行为是从何时开始的。 “目前尚不清楚 X 从何时开始在平台上屏蔽 ‘Signal.me’ 链接，”Binder 在其报道中解释道。“然而，这似乎是一个相当新的变化，因为用户之前可以在公开帖子和他们的个人简介中包含 ‘Signal.me’ 链接。其他 Signal 链接，如 Signal.org，似乎并未被屏蔽。” 其他与 Signal 相关的 URL，如 Signal.link 和 Signal.group 链接，似乎并未受到屏蔽影响。此外，第三方消息服务（如 Telegram）的联系人链接仍可在 X 平台上正常分享。 与此同时，在屏蔽措施实施之前已发布在 X 上的 Signal.me 链接仍然可以点击，但用户在点击链接时会看到一条警告，提示该链接可能不安全。 研究员 Tommy Mysk 是本周末最早发现这一问题的人之一，他告诉 BleepingComputer，目前尚不清楚这一行动背后的原因。 “我是偶然发现的。我不能推测，但这一行为看起来与他们屏蔽 Mastodon 链接时的情况非常相似，”Mysk 表示。 2023 年，埃隆·马斯克收购 Twitter 后，该社交平台开始屏蔽指向竞争对手平台的链接，如 Facebook、Instagram 和 Mastodon。在用户抗议后，这一政策很快被撤销。 最近，马斯克因他领导的美国政府部门——政府效率部（DOGE）——获取多个美国政府机构的数据而受到批评。 据报道，Signal 这款流行的端到端加密通信应用被联邦雇员广泛用于向记者报告 DOGE 的违规行为。 因此，有人猜测 X 上对 Signal.me 链接的屏蔽可能是出于政治动机。然而，X 尚未对屏蔽一事发表任何声明，也未回应置评请求。   消息来源：Bleeping Computer；  本文由 HackerNews.cc 翻译整理，封面来源于网络；   转载请注明“转自 HackerNews.cc”并附上原文

网络犯罪分子利用HTML图片标签中的Onerror事件窃取电商网站支付信息，通过隐蔽代码植入Magento平台，攻击客户结账页面，严重威胁用户敏感数据安全。

HackerNews 编译，转载请注明出处： 谷歌在 Android 16 Beta 2 中推出了一项新的安全功能，旨在防止用户在通话期间更改敏感设置，以应对日益复杂的电话诈骗。 电话诈骗手段日益复杂，诈骗者常利用心理操纵技巧诱使受害者授予权限，从而安装恶意软件。常见手法包括引导受害者在通话中启用侧载或无障碍权限，使恶意应用能够绕过安全防护并控制设备。鉴于此，谷歌在 Android 16 中引入了“通话中防诈骗保护”功能。 阻止通话期间启用侧载权限：侧载允许应用安装其他应用，通常默认禁用以确保安全。Android 16 现在防止用户在通话期间启用此权限，进一步增强了安全性。 限制通话期间的无障碍权限：无障碍权限允许应用读取屏幕内容并代表用户执行操作，这常被恶意软件利用。Android 16 在通话期间阻止授予这些权限，进一步降低了未经授权控制的风险。 警告提示：用户在尝试绕过这些限制时，会收到关于潜在诈骗的明确警告，鼓励他们验证来电者的身份。 增强的确认模式：此功能扩展了 Android 15 中引入的保护措施，增加了更严格的防护，防止未经授权访问敏感设置。 这项新安全功能是谷歌在应对电话导向攻击交付（TOAD）诈骗等日益增长的威胁中，持续提升用户安全性的努力的一部分。通过将这些保护措施集成到 Android 16 Beta 2 中，谷歌旨在显著减少诈骗案件。 虽然诈骗者可能仍会指示受害者挂断电话后启用权限，但这一额外步骤足以扰乱其诈骗手段。此外，Android 16 还包括更广泛的安全增强功能，如防止意图重定向攻击和改进大屏设备的应用兼容性。 目前，防诈骗保护功能已在 Android 16 Beta 2 中上线，适用于 Pixel 设备（Pixel 6 及更新型号）。Android 16 的最终版本预计将于 2025 年第二季度晚些时候发布。随着这些功能的公开推出，用户可以期待一个更安全的移动体验，优先保护隐私和防止诈骗。 随着诈骗手段因人工智能的进步而变得更加复杂，谷歌的新方法标志着在降低风险和为用户提供强大防御网络威胁方面迈出了重要一步。   消息来源：Cybersecurity News；  本文由 HackerNews.cc 翻译整理，封面来源于网络；   转载请注明“转自 HackerNews.cc”并附上原文

DeepSeek的私有化部署真的安全吗？让我们随腾讯安全应急响应中心一起来看看~

DeepSeek的私有化部署真的安全吗？让我们随腾讯安全应急响应中心一起来看看~

DeepSeek的私有化部署真的安全吗？让我们随腾讯安全应急响应中心一起来看看~

DeepSeek的私有化部署真的安全吗？让我们随腾讯安全应急响应中心一起来看看~

DeepSeek的私有化部署真的安全吗？让我们随腾讯安全应急响应中心一起来看看~

DeepSeek的私有化部署真的安全吗？让我们随腾讯安全应急响应中心一起来看看~

DeepSeek的私有化部署真的安全吗？让我们随腾讯安全应急响应中心一起来看看~

HackerNews 编译，转载请注明出处： 近日，ExHub 被发现存在一个关键的不安全直接对象引用（IDOR）漏洞，该漏洞允许攻击者在未经授权的情况下修改任何项目的网页托管配置，对受影响系统构成重大风险。 ExHub 是一个基于云的平台，提供网页托管、项目协作和部署功能。用户可以配置其项目的网页托管设置，这些设置决定了项目如何部署和被访问。理想情况下，只有授权用户才能修改这些设置。然而，由于访问控制的不当实现，未授权用户可以通过知道项目的唯一标识符来利用系统。 该漏洞存在于 ExHub 的项目部署配置 API 中。具体来说，该 API 缺乏 robust 的授权检查，使得任何用户（无论其角色或认证状态）都可以发送精心构造的请求来修改托管设置。 漏洞利用过程技术复杂度较低： 获取项目 ID：攻击者需要获取一个有效的项目 ID，这可以通过枚举或其他间接手段获得。 构造未授权的 API 请求：通过向漏洞端点 /api/v1/projects/deployment_configuration/<projectid>发送 POST 请求，攻击者可以修改关键的托管参数。 执行请求：使用工具如 Burp Suite 或 Postman 就足以执行攻击并实时观察更改。 验证更改：攻击者可以通过 ExHub 的用户界面确认修改。 该漏洞实际上允许未授权用户执行诸如更改机器类型、端口和 DNS 配置等管理操作，这些操作本应仅限于高权限角色。 漏洞影响 该 IDOR 漏洞的后果严重，攻击者可以操纵部署配置，可能获得对敏感资源的未经授权访问。配置错误可能导致服务中断或无法访问。此外，被利用的配置可能使攻击者能够提升权限或链式攻击以进行进一步利用。 漏洞修复 ExHub 采取了以下措施来解决此漏洞： 在所有 API 端点引入严格的授权检查。 通过实施随机化技术使项目 ID 更难以预测。 重构用户角色以强制执行最小权限原则。 教训 此次事件为开发者和组织提供了几个关键教训： 授权检查至关重要：每个 API 端点都必须严格验证用户权限。 避免可预测的标识符：使用容易猜测的 ID 会增加被利用的风险。 最小权限原则：根据用户角色限制其操作，以最小化配置错误可能造成的损害。 全面测试：安全测试应包括后端 API，以发现诸如 IDOR 之类的隐藏漏洞。 通过实施严格的访问控制并采用安全设计原则，公司可以保护其平台免受利用，并建立用户信任。   消息来源：Cybersecurity News；  本文由 HackerNews.cc 翻译整理，封面来源于网络；   转载请注明“转自 HackerNews.cc”并附上原文