标签: GitHub

GitHub 撤下被泄露的 Snapchat 源码 黑客扬言重新上传

Snapchat 是一款主打“阅后即焚”功能的消息应用,不过近日,这款 app 的源码也在代码托管网上上玩了一回“阅后即焚”。事情的起因是,一位据说来自巴基斯坦东南部 Sindh 省 Tando Bago 村的“the handle i5xx”,在 GitHub 上创建了一个名叫“Source-Snapchat”的资源库。 尽管发稿时,该资源已经被 Snap 公司依据《数字千年版权法案》(DMCA)提出的版权撤除请求而被 GitHub 移除,但事件还是引起了很大的反响。 据悉,该资源库自称为‘SnapChat 源代码’,并通过苹果的 Objective-C 语言编写,所以曝光的应该是 iOS 版 Snapchat 应用的全部或部分内容。 不过当前,我们还无法确定它属于其中服务的一个小组件,还是该公司的一个单独项目。 至于发布者‘i5xx’的身份,其账号信息关联的是‘Khaled Alshehri’,但很可能是个假名。外媒 TNW 指出,其姓氏在巴基斯坦并不常见。 此外,账号简介链接到了一个位于沙特的在线服务,其提供从安全扫描、iCloud 删除,到软件开发和 iTunes 礼品卡销售在内的各种技术服务。 四天前,GitHub 发布了一份来自 Snap Inc. 的 DMCA 版权撤除请求,不过它可能是在更早之前提交的(在线时间或超过 2 个月)。 需要指出的是,Snap Inc. 在 DMCA 请求中使用的语气(多段纯大写字母组成的句子),传达出了一种切实的恐慌感(甚至措辞来不及做得更加严谨)。 Snapchat 源代码被泄露,有人将它放到了这个 GitHub 资源库中。我司无法给出确切的 URL 指向,也不会公开发布它。 显然,这从侧面反映了此前上传的资源库内容的重要性。 然而有知情者指出,本次泄露并非出于恶意,只是某位研究人员无法将他的某些发现传达给该公司。在 GitHub 根据 DMCA 请求撤除之后,他还威胁再次上传源代码,直到该公司正式作出回应。 不过事实是,Snap Inc. 在 HackerOne 上有一个活跃的账户和 bug 赏金计划,且响应速度极快 —— 安全研究人员是很容易与该公司取得联系的。 根据 HackerOne 的官方统计数据,其在 12 小时内回复了初步报告,并已支付超过 22 万美元的奖金。外媒 TNW 已经联系 Snap 发表评论,感兴趣的朋友可以留意我们的后续报道。         稿源:cnBeta.COM,编译自:TNW,封面源自网络;

GitHub 推出 Python 安全警告,识别依赖包的安全漏洞

GitHub 宣布了 Python 安全警告,使 Python 用户可以访问依赖图,并在他们的库所依赖的包存在安全漏洞时收到警告。 安全警告首次发布是在 2017 年 10 月,为了跟踪 Ruby 和 JavaScript 程序包中的安全漏洞。据 GitHub 介绍,从那时起,数以百万计的漏洞被发现,推动了许多补丁的发布。 GitHub 会根据 MITRE 的公共漏洞列表(CVE)来跟踪 Ruby gems、NPM 和Python 程序包中的公共安全漏洞。CVE 是一个条目列表;每个条目都包含一个标识号、一段描述以及至少一项公共参考。这非常有助于促使管理员快速响应、通过移除易受攻击的依赖或迁移到安全版本来修复漏洞。 当 GitHub 收到新发布的漏洞通知,它就会扫描公共库(已经选择加入的私有库也会被扫描)。当发现漏洞时,就会向受影响的库的所有者和有管理员权限的用户发送安全警告。在默认情况下,用户每周都会收到一封邮件,其中包含多达 10 个库的安全警告。用户也可以自己选择通过电子邮件、每日摘要电子邮件、Web 通知或 GitHub 用户界面来接收安全警告。用户可以在通知设置页面调整通知频率。 在某些情况下,对于发现的每个漏洞,GitHub 会尝试使用机器学习提供修复建议。针对易受攻击的依赖的安全警告包含一个安全级别和一个指向项目受影响文件的链接,如果有的话,它还会提供 CVE 记录的链接和修复建议。通用漏洞评分系统(CVSS)定义了四种可能的等级,分别是低、中、高和严重。 据 GitHub 介绍,开始的时候,安全警告只会涵盖最新的漏洞,并在接下来的数周内添加更多 Python 历史漏洞。此外,GitHub 永远不会公开披露任何库中发现的漏洞。 依赖图列出了项目的所有依赖,用户可以从中看出安全警告影响的项目。要查看依赖图,在项目中点击 Insights,然后点击 Dependency graph。 要在 Python 项目中使用依赖图,需要在 requirements.txt 或 pipfile.lock 文件中定义项目依赖。GitHub 强烈建议用户在 requirements.txt 文件中定义依赖。 要了解更多信息,请查看 GitHub文档。   稿源:开源中国社区,封面源自网络;

密码的锅,Gentoo 发布 GitHub 仓库被入侵事件报告

之前我们曾报道过“Gentoo Linux 的 GitHub 仓库被入侵,意图删除所有文件”的消息,Gentoo Linux 的 Github 仓库在6月28日晚上受到黑客攻击,并成功取得了组织的控制权。攻击者篡改了存储库的内容以及页面,并用恶意 ebuild 文件替换了 portage 和 musl-dev trees 中的文件,意图删除储存库上的所有文件。Gentoo 的开发者在发现问题后,发出预警邮件,Gentoo GitHub 组织权限被冻结。 之后,Gentoo 在官网发布多条公告说明事件的处理进度,直到 5 天后的7月3日,Gentoo 才正式将事件标记为已解决,恶意提交和被污染的文件已处理,Gentoo GitHub 组织被重新解锁。Gentoo 还在其官网上发布了一篇关于整个事件的详细报告,并表示收集的相关证据表明事件的根本原因是他们使用的密码方案过于简单,在某个站点上的披露使得攻击者很容易猜出在其他不相关网页的密码,致使攻击者获得了组织管理员的密码和访问权限。 稿源:开源中国,封面源自网络;

GitHub 在其内部日志中记录了明文密码

近期,有一定数量的用户认为,GitHub 密码重置功能中存在 Bug,公司内部日志内的明文格式记录了用户的密码。该公司表示,明文密码只向少数可以访问这些日志的 GitHub 员工公开,没有其他 GitHub 用户看到用户的明文密码。 GitHub 说,通常情况下,密码是安全的,因为它们是用 bcrypt 算法散列的。该公司指责其内部日志中存在明文密码的错误。只有最近重置密码的用户才受到影响,受影响的用户数量预计很低。数十名用户分享了他们今天早些时候在 Twitter 上收到的 GitHub 电子邮件的图片。最初,用户认为这是一个大规模的网络钓鱼攻击。GitHub 表示,它在例行审计中发现了它的错误,并明确表示它的服务器没有被黑客入侵。 稿源:freebuf,封面源自网络;

GitHub 安全警告计划已检测出 400 多万个漏洞

Github 去年推出的安全警告,极大减少了开发人员消除 Ruby 和 JavaScript 项目漏洞的时间。GitHub 安全警告服务,可以搜索依赖寻找已知漏洞然后通过开发者,以便帮助开发者尽可能快的打上补丁修复漏洞,消除有漏洞的依赖或者转到安全版本。 根据 Github 的说法,目前安全警告已经报告了 50 多万个库中的 400 多万个漏洞。在所有显示的警告中,有将近一半的在一周之内得到了响应,前7天的漏洞解决率大约为 30%。实际上,情况可能更好,因为当把统计限制在最近有贡献的库时,也就是说过去 90 天中有贡献的库,98% 的库在 7 天之内打上了补丁。 这个安全警报服务会扫描所有公共库,对于私有库,只扫描依赖图。每当发现有漏洞,库管理员都可以收到消息提示,其中还有漏洞级别及解决步骤提供。 安全警告服务现在只支持 Ruby 和 JavaScript,不过 Github 表示 2018 年计划支持 Python。 稿源:cnBeta、开源中国,封面源自网络;

开发者噩梦:欧盟希望过滤上传到互联网的所有代码

欧盟的一项提案要求托管内容的所有平台检查所有上传的内容有无侵犯版权,这可能会使软件的成本更高昂。欧盟考虑的一项版权提案旨在让盗版者更难共享内容和媒体,但是这张网撒得太广了,可能无意中阻碍程序员。 欧盟考虑的一项版权提案要求托管由用户上传的大量内容的任何平台扫描所有内容,以确保没有侵犯版权。 该提案旨在防止媒体盗版,但可能会给使用代码仓库 GitHub 等服务的广大开发者带来严重影响,按照新法律 GitHub 将被迫过滤代码。 正如 GitHub 指出的那样,自动过滤代码对于独立程序员和大企业程序员来说都是毁灭性的。面临的问题可能包括:误报/漏报、丢失依赖项、许可证混淆以及不必要的负担阻碍创新。 版权提案仍在讨论中,已经有人开始竭力阻止实施。 提案有什么样的内容?为何让码农们深为担忧? 该提案的第 13 条专门涉及自动内容过滤器的实施,这也是让 GitHub 及其他欧洲程序员们深为担忧的部分。 第 13 条规定:“ 如果提供商存储用户上传的大量作品或其他主题,并允许公众访问这些内容 ”,须与版权所有者合作,实施措施以防止内容被非法共享。 “那些措施(比如使用有效的内容识别技术)应该是适当的、相称的,”该提案表示。第 13 条进一步提到了内容识别技术是发现版权侵犯行为的最佳实践的一部分,因此过滤器很可能是通过的任何新版权法的最终条文的一部分。 然而,哪些类型的内容要过滤却没有明确规定。撒一张这么大的网让 GitHub 和 Save Code Share 的成员们深为担忧,自由软件基金会欧洲分会和开放论坛欧洲共同发起了 Save Code Share,这场请愿活动旨在阻止第 13 条实施,呼吁欧盟的政策制定者重新考虑或摈弃第 13 条。他们认为,对于处理代码、文档、音频和视频的开发者来说,版权合规检查完全实现自动化是不可行的。 如果真是那样子,代码共享平台就需要招聘众多的人员帮助做好版权合规工作,Facebook 和 YouTube 等社交媒体平台之前就是这么做的。 不管怎样,通过使用 Git 及其他软件工具而共享的大量内容需要 GitHub 等面向开发的平台公司实施自动化过滤机制,确定什么内容可以共享、什么不可以共享。 GitHub 的政策经理艾阿•沃尔默(Abby Vollmer)在发给 IT 外媒 The Register 的电子邮件中表示,如果美国开发者/开发商在欧洲开展工作/业务,需要遵守同样的这些规定。 GitHub 认为,对于软件开发者而言,由于应用程序常常牵涉许多不同的贡献者和不同层的代码(这些代码也许采用不同的许可证),可能出现误报或漏报这个问题显得尤为突出。 此外,要求代码共享平台删除没有许可证的代码 “ 审查机器 ”是否来自欧盟? 欧洲议会议员朱莉娅•里达(Julia Reda)细述了版权提案中另外一些令人担忧的条文,它们适用于编程平台及其他内容共享网站,这些平台和网站都将受到该提案的影响: 平台需要为它们托管的所有版权保护的内容获得许可证,她认为这几乎是不可能的,对于代码共享平台而言尤为如此。 平台需要阻止版权保护的内容被上传,她认为这就要求使用内容过滤器。 因为上传/阻止的内容将被去除标识符,内容过滤器无法处理任何个人数据,她表示因而不可能对针对过度过滤的纠错进行归档。 扫描的文件将针对所有上传的内容予以检查,里达认为此举违反了欧盟在一般监视方面的禁令。 过滤不适用于在线市场(如 eBay)、互联网服务提供商(ISP)、研究资料库或云存储服务。里达指出,这些服务并非被免除许可证要求,因令人混淆的语言而容易面临诉讼。 围绕版权提案的争论从未停过,所以现在判断它的一些更广义、更苛刻或不一致的部分条文是否会成为法律还为时尚早。 这项合理的提案其初衷是确保表演者、创作者和出版者获得作品的报酬,但未必很适合其他社区;谁想发表意见,欢迎联络欧洲议会议员、理事会成员和欧盟委员,确保其心声被听到。 稿源:cnBeta、云头条,封面源自网络;

Memcached DDoS 反射攻击创下 1.7Tbps 流量峰值纪录

外媒 3 月 6 日消息,继 Github 在上周遭受了流量速度为 1.3Tbps 的分布式拒绝服务(DDoS)攻击后,网络安全监控公司 Arbor Networks 证实美国一家服务提供商也面临着流量峰值高达 1.7Tbps 的反射/放大攻击。 虽然此次 1.7Tbps 事件与上周 GitHub 发生的 DDoS 攻击类似,但其带宽因使用了英特网上数千台暴露以及错误配置的 Memcached 服务器而被放大了 51,000 多倍。 据悉,在 GitHub 事件发生之后,其客户收到了敲诈邮件,威胁他们购买 50 枚价值超过 15,000 美元的 XMR( Monero )。目前 thehackernews 的文章中并未写明此次事件是否会有勒索赎金的情况出现。 Arbor Networks 表示,虽然反射/放大攻击并不新鲜,然而,最新的攻击媒介已经演变成了数千个错误配置的 Memcached 服务器,其中许多服务器目前仍然暴露在互联网上,可能会被利用来针对其他目标发起大规模的攻击。 Arbor Networks 预计未来几天会出现更多此类攻击事件。因此,为了防止 Memcached 服务器被滥用为反射器,Arbor Networks 敦促用户安装防火墙,并限制只能从本地网络访问 memcached 服务器。此外,管理员还应该考虑避免外部流量通过 memcached 使用的端口(例如默认使用的 11211 端口), 并及时阻止或限制 UDP ,如果非必要的话,最好能够完全禁用 UDP 支持。 消息来源:thehackernews,编译:榆榆,校审:FOX; 本文由 HackerNews.cc 编译整理,封面来源于网络; 转载请注明“ 转自 HackerNews.cc ” 并附上原文链接。

应苹果要求 GitHub 已清除被泄露的 iOS 源代码

昨天,我们报道了“有人已将疑似 iOS 9 中的 iBoot 源码泄露到 GitHub”的消息。虽然这件事情可以追溯到几个月前的 Reddit 爆料,但苹果显然已经坐不住了。据外媒报道,事情曝光后不久,苹果便与 GitHub 取得了联系,要求该代码托管平台立即清理掉被公布的源代码。我们在测试后发现,原先的这个链接(https://github.com/king4q/iBoot)已经不再可用。 GitHub 网页截图 – iBoot 源码页已基于《数字千年版权法案》的请求而撤除 据悉,本次泄露的 iBoot 代码可能会被黑客利用,发现 iOS 系统中的漏洞、甚至更轻松地越狱。然而 r/jailbreak 指出: 遗憾的是,即便 GitHub 已经撤除,但互联网上仍存有许多的副本。 曾编写 iOS 与 macOS 系统编程图书的 Jonathan Levin 在接受 Motherboard 采访时亦表示: 鉴于苹果一直小心翼翼地确保自家安全,本次源码曝光或是该公司有史以来最严重的一起泄露事件。 iBoot 是保障 iOS 软件受信任启动操作的重要一环,律师将本次泄露事件描述为“对苹果 iBoot 源码的复制”。该公司在撤除请求中写到: 这份 iBoot 源码表明其有着专有权利,其中包含了苹果的版权声明,因而并不是开源的。 尽管这份源码来自 iOS 9,但它很有可能在 iOS 11 中被继续使用。 稿源:cnBeta,原文编译自 TheVerge,封面源自网络

Electron 框架现严重 RCE 漏洞影响 Windows 多个应用程序

外媒 1 月 24 日报道,流行软件构建框架 Electron 中存在一个严重的远程代码执行( RCE )漏洞(CVE-2018-1000006),可能会影响大量热门桌面应用程序,比如 Skype,Signal,Slack,GitHub Desktop,Twitch 和 WordPress.com 等。 Electron  表示目前只有 Windows 的应用程序会受到漏洞影响。 Electron 由 GitHub 团队开发,是一个基于 Node.js 和 Chromium 引擎的开源框架,允许应用程序开发人员使用 JavaScript、HTML 和 CSS 等 Web 技术为 Windows,MacOS 和 Linux 等构建跨平台的本地桌面应用程序。目前至少有 460 个跨平台桌面应用程序使用了 Electron 框架。 本周一,Electron 团队称其已在 Electron 框架中修补了该远程代码执行漏洞,并表示该漏洞只影响 Windows 应用程序, Mac 和 Linux 的应用不在影响范围内 。 据 Electron 团队介绍, 该远程代码执行漏洞影响使用自定义协议处理程序的电子应用程序。若这些基于 Electron 的应用程序将自身注册为处理自定义协议框架(如 myapp ://),并且无论协议是怎么注册的,都很可能会受到漏洞影响。( 例如使用本地代码、Windows注册表、Electron 框架的app.setAsDefaultProtocolClient API 等方式注册) 目前 Electron 开发者已经发布了两个新的框架版本来解决这个严重的漏洞,即 1.8.2-beta.4,1.7.11 和 1.6.16。如果由于某种原因导致无法升级 Electron 版本,那么可在调用 app.setAsDefaultProtocolClient 时将其作为最后一个参数追加,因为这样一来,可以有效防止 Chromium 解析更多的选项。 消息来源:Security Affairs,编译:榆榆,校审:FOX; 本文由 HackerNews.cc 编译整理,封面来源于网络; 转载请注明“ 转自 HackerNews.cc ” 并附上原文链接。

Github 上出现 PS4 4.05 固件的内核利用,越狱指日可待

圣诞节已经过了,但圣诞老人没闲着,他为全体 PlayStation 用户带来了一份特殊的礼物。开发者 SpecterDev 今天终于发布了 PlayStation 4(固件 4.05 )的内核漏洞。两个月前,Team Fail0verflow 公布了技术细节。 这个内核的 exp 大家可以在 GitHub 上找到,名叫 “ namedobj ” ,这个 exp 能让用户在游戏控制台上运行任意代码,从而越狱或者进行内核级的修改。 尽管 PS4 内核漏洞利用不包括越狱代码,但其他开发者可以在此基础上开发一个完整的越狱工具。 通过越狱,用户可以运行自定义代码,或者安装 mods,作弊插件、第三方程序和游戏,这些东西由于索尼 PlayStation 的反盗版机制原来都是不可能的。 SpecterDev 说:“不过这个版本并没有绕过反盗版机制或运行自制软件相关的任何代码。这个漏洞的确包括一个 payload,用于监听 9020 端口的有效载荷,并接收命令。” 不过 exp 的稳定性值得注意。 “ 在我的测试中,这个漏洞的成功率实际上稳定在 95% 左右,WebKit 很少崩溃,内核也是如此,我创建的补丁程序只会让内核漏洞在系统上运行一次。“ SpecterDev 警告说。 运行固件版本低于 4.05 的 PS4 游戏玩家可以使用相关的 exp 。 稿源:FreeBuf早餐铺,封面源自网络;编辑:榆榆