标签: GitHub

提高警惕!有人在 GitHub 上利用虚假 PoC 漏洞利用钓鱼

莱顿高级计算机科学研究所的研究人员在GitHub上发现了数以千计存在问题的存储库,这些存储库为各种漏洞提供虚假的概念验证(PoC),并借此隐藏传播恶意软件。 GitHub是最大的代码托管平台之一,研究人员用它来发布PoC漏洞,以帮助安全社区验证漏洞的修复或确定一个漏洞的影响和范围。 据莱顿高级计算机科学研究所的研究人员称,如果不包括被证实的恶作剧软件,以虚假PoC进行掩饰,实际上上恶意软件的可能性可能高达10.3%。 数据收集和分析 研究人员使用以下三种机制分析了47300多个储存库,包含2017年至2021年期间披露的漏洞: IP地址分析:将PoC的发布者IP与公共封锁名单以及VT和AbuseIPDB进行比较。 二进制分析:对提供的可执行文件及其哈希值运行VirusTotal检查。 十六进制和Base64分析:在执行二进制和IP检查之前对混淆的文件进行解码。 在提取的150734个独特的IP中,有2864个与封锁名单条目相匹配,1522个在Virus Total的反病毒扫描中被检测为恶意的,其中1069个存在于AbuseIPDB数据库中。二进制分析检查了一组6160个可执行文件,发现共有2164个恶意样本托管在1398个存储库中。 总的来说,在测试的47313个软件库中,有4893个软件库被认为是恶意的,其中大部分涉及到2020年的漏洞。报告中包含了一小部分带有虚假PoC的软件库,这些软件库正在传播恶意软件。研究人至少分享了60个案例,然而这些例子仍然是存活的,并且正在被GitHub取缔。 PoC中的恶意软件 通过仔细研究其中一些案例,研究人员发现了大量不同的恶意软件和有害脚本,从远程访问木马到Cobalt Strike。 一个有趣的案例是CVE-2019-0708的PoC,通常被称为 “BlueKeep”,它包含一个base64混淆的Python脚本,从Pastebin获取一个VBScript。该脚本是Houdini RAT,一个基于JavaScript的老式木马,支持通过Windows CMD执行远程命令。 在另一个案例中,研究人员发现了一个假的PoC,这是一个收集系统信息、IP地址和用户代理的信息窃取器。这是另一个研究人员之前创建的安全实验,所以用自动工具找到它是对研究人员的确认,他们的方法是有效的。 还有一些没有在技术报告中体现的例子,例如: PowerShell PoC包含一个用base64编码的二进制文件,在Virus Total中被标记为恶意的。 Python PoC包含一个单行代码,用于解码在Virus Total中被标记为恶意的base64编码的有效载荷。 伪造的BlueKeep漏洞包含一个被大多数反病毒引擎标记为恶意的可执行文件,并被识别为Cobalt Strike。一个隐藏在假PoC中的脚本,其中有不活跃的恶意组件,但如果其作者愿意,依旧可以造成损害。 如何保持安全 盲目相信GitHub上未经验证的仓库是不可取的,因为其内容没有经过审核,所以用户在使用前要对其进行审查。建议软件测试人员仔细检查他们下载的PoC,并在执行之前尽可能多地进行检查。 专家认为,所有测试人员都应该遵循这三个步骤。 仔细阅读你即将在你或你客户的网络上运行的代码。 如果代码太模糊,需要太多的时间来手动分析,就在一个环境中(例如一个隔离的虚拟机)进行沙盒测试,并检查你的网络是否有可疑的流量。 使用开源的情报工具,如VirusTotal来分析二进制文件。 目前,研究人员已经将他们发现的所有恶意软件库报告给GitHub,但在所有这些软件库被审查和删除之前,还需要一些时间,所以许多软件库仍然对公众开放。 转自 Freebuf,原文链接:https://www.freebuf.com/news/347905.html 封面来源于网络,如有侵权请联系删除

研究发现,攻击者利用伪造时间戳等方式在 GitHub 上传播恶意代码

当开发人员在GitHub上寻找开源项目时,会习惯对其元数据进行检查,但研究发现,这些元数据很容易被伪造,并以此用来传播恶意代码。 Checkmarx 的研究人员在一份新报告中警告说,开发人员在查看元数据时应当尽力核实背后贡献者的身份,而不应仅停留于对元素据表面的检查。 通常,开发人员在GitHub上寻找开源项目时,会倾向于选择那些活跃的、有积极维护记录的贡献者所提供的项目,Git对每一次更改分配了一个唯一的 ID,该ID记录了由谁更新、具体的更新内容以及时间戳,相对而言,拥有较多的更新反映了贡献者对这个项目的重视,项目得到了较好的维护与优化。 但根据Checkmarx的说法,攻击者可以轻松伪造这些记录。报告称,衡量 GitHub 上用户活动的一个重要指标是用户个人资料页面上的活跃热图,显示用户在一段时间内的活跃程度,而攻击者能在注册的全新账户上通过伪造带有时间戳的提交记录,使之看起来已经平台上活跃了很长时间。 利用git set更改本地两个环境变量,从而在 GitHub 上显示伪造的时间戳 类似的,攻击者还可以“借用”一些知名的、信誉度良好的贡献者身份上传包含恶意代码的项目,攻击者只需要找到这些贡献者的电子邮件地址,然后在 Git 命令行上设置用户名和电子邮件地址并提交更改。报告称,尽管 GitHub 提供了隐藏电子邮件地址的方法,但大多数人并没有使用这些功能,从而让攻击者可以相对容易地获取这些邮件地址。此外,被借用身份的贡献者也不会收到任何关于他们的账户被添加为另一个项目的贡献者的通知。 Checkmarx的供应链安全主管Tzachi Zornstain强调,开发人员在选择开源项目时,要重视这些项目贡献者的身份是否已被验证,如果一个项目包含多个贡献者提交的代码,要确保这些贡献者也是必须真实可靠。 他还建议这些项目贡献者使用GitHub的数字签名功能,对自己的代码进行签名,这样他们的贡献就会被验证。该功能包括一个 “警惕模式”,显示所有在其名下贡献的代码的状态,包括其他人可能在其名下提交的代码。GitHub指出,如果所有贡献者希望能够这样做,就需要在2023年前开启双因素认证。 转自 FreeBuf,原文链接:https://www.freebuf.com/news/339431.html 封面来源于网络,如有侵权请联系删除

GitHub 透露:攻击者利用偷来的 OAuth 令牌入侵了几十个组织

GitHub今天透露,一名攻击者正在使用偷来的OAuth用户令牌(原本发放给Heroku和Travis-CI),从私人仓库下载数据。自2022年4月12日首次发现这一活动以来,威胁者已经从几十个使用Heroku和Travis-CI维护的OAuth应用程序(包括npm)的受害组织中访问并窃取数据。 “这些集成商维护的应用程序被GitHub用户使用,包括GitHub本身,”GitHub的首席安全官(CSO)Mike Hanley今天透露。”我们不相信攻击者是通过破坏GitHub或其系统来获得这些令牌的,因为GitHub没有以原始的可用格式存储这些令牌。我们对威胁行为者的其他行为的分析表明,行为者可能正在挖掘被盗的OAuth令牌所能访问的下载的私有仓库内容,以寻找可用于渗透其他基础设施的秘密。” 根据Hanley的说法,受影响的OAuth应用程序的列表包括: Heroku Dashboard(ID:145909) Heroku Dashboard (ID: 628778) Heroku Dashboard – Preview (ID: 313468) Heroku Dashboard – Classic (ID: 363831) Travis CI (ID: 9216) GitHub安全部门在4月12日发现了对GitHub的npm生产基础设施的未经授权的访问,因为攻击者使用了一个被泄露的AWS API密钥。攻击者很可能是在使用偷来的OAuth令牌下载了多个私有npm仓库后获得了该API密钥。 “在4月13日晚上发现非GitHub或npm存储的第三方OAuth令牌被更广泛地窃取后,我们立即采取行动,通过撤销与GitHub和npm内部使用这些受损应用程序有关的令牌来保护GitHub和npm,”Hanley补充说。对npm组织的影响包括未经授权访问GitHub.com的私有存储库和”潜在访问”AWS S3存储上的npm包。 GitHub的私人存储库未受影响 虽然攻击者能够从被攻击的存储库中窃取数据,但GitHub认为,在这次事件中,没有一个软件包被修改,也没有用户账户数据或凭证被访问。 Hanley说:”npm使用与GitHub.com完全不同的基础设施;GitHub在这次原始攻击中没有受到影响。虽然调查仍在继续,但我们没有发现任何证据表明其他GitHub拥有的私有仓库被攻击者使用窃取的第三方OAuth令牌克隆。” GitHub正在努力通知所有受影响的用户和组织,因为他们被确认了更多信息。 作为GitHub的成员,您应该应该审查您和您的组织的审计日志和用户账户的安全日志,看看是否有异常的、潜在的恶意活动。 您可以在周五发布的安全警报中找到更多关于GitHub如何应对以保护其用户以及客户和组织需要知道的信息。   转自 cnBeta ,原文链接:https://www.cnbeta.com/articles/tech/1258953.htm 封面来源于网络,如有侵权请联系删除

包含敏感数据数千个 Firefox cookie 出现在 GitHub 存储库中

包含敏感数据的数千个 Firefox cookie 数据库目前出现在 GitHub 的存储库中,这些数据可能用于劫持经过身份验证的会话。这些 cookies.sqlite 数据库通常位于 Firefox 配置文件文件夹中。它们用于在浏览会话之间存储 cookie。现在可以通过使用特定查询参数搜索 GitHub 来找到它们,这就是所谓的搜索“dork”。 总部位于伦敦的铁路旅行服务公司 Trainline 的安全工程师 Aidan Marlin 在通过 HackerOne 报告了他的发现,并被 GitHub 代表告知“我们用户暴露的凭据不在范围内后,提醒 The Register 这些文件的公开可用性。我们的漏洞赏金计划”。Marlin 然后问他是否可以公开他的发现,并被告知他可以自由这样做。 在发送给 The Register 的电子邮件中,Marlin 表示:“我很沮丧 GitHub 没有认真对待用户的安全和隐私。它至少可以防止这个 GitHub dork 的结果出现。如果上传这些 cookie 数据库的人知道他们做了什么,他们会尿裤子”。 Marlin 承认,受影响的 GitHub 用户在提交代码并将其推送到公共存储库时未能阻止他们的 cookies.sqlite 数据库被包含在内,因此应该受到一些指责。 “但是这个 dork 的点击量接近 4500 次,所以我认为 GitHub 也有注意的义务”。他说,并补充说他已经通知了英国信息专员办公室,因为个人信息处于危险之中。 Marlin 推测这种疏忽是从一个人的 Linux 主目录提交代码的结果。他解释说:“我想在大多数情况下,个人不知道他们已经上传了他们的 cookie 数据库,用户这样做的一个常见原因是跨多台机器的公共环境”。 Marlin 说,GitHub dorks 并不新鲜,但它们通常只影响单一服务,例如 AWS。这种特殊的失误令人不安,因为它可能允许攻击者访问任何面向互联网的网站,在提交 cookie 文件时,GitHub 用户已通过该网站进行身份验证。他补充说,可能也可以找到其他浏览器的傻瓜。   (消息及封面来源:cnBeta)

从 Stack Overflow 复制代码导致 GitHub 项目漏洞多

现在从网上找代码直接复制到项目中的做法成为程序员的一种常规操作,Stack Overflow 更是其中主要的代码来源。但是最近有研究显示,从 Stack Overflow 上复制代码凑到项目中会使出现漏洞的概率大大增加。 研究人员分析了 1325 个 Stack Overflow 帖子,并获取了其中 72 000 多段 C++ 代码,发现了其中包含有 29 种类型的 69 个漏洞。 这些漏洞出现在 2589 个 GitHub 仓库中,研究人员通知了受影响的 GitHub 项目作者,但只有少数人选择修复已知这些危险情况。 研究人员展示了含有漏洞的代码主要是以什么方式从 Stack Overflow 进入到 GitHub 中的,包括最经常发现的输入验证不正确、异常或异常情况的不正确检查与错误编码,比如复制代码不完整。     (稿源:开源中国,封面源自网络。)

Github 收购代码分析平台公司 Semmle 致力于查找零日漏洞及其变种

已被微软纳入麾下了开源代码托管平台 Github,刚刚宣布收购了一家名叫 Semmle 的代码分析平台公司。后者致力于查找零日漏洞,并对其变体展开自动化分析。Semmle 的语义代码分析引擎,允许开发者编写查询、识别大型代码库中的编程模式、搜索漏洞及其变种。此前,Semmle 已被谷歌、Uber、微软和诸多开源项目开发者用于提升其产品和服务的安全性。 微软表示,本次收购有助于让 Semmle 吸引到更多开发者,但现有的产品和客户并不会受到任何影响。 在接下来几个月里,您可期待 Semmle 与 Github 产品线实现更深层次的整合。此外 Semmle 透露,LGTM.com 将继续免费提供公共存储库和开源软件。 据悉,安全研究人员可借助 Semmle 简单的声明性查询,快速查找到代码中的相关漏洞。然后,这些团队会与 Semmle 社区分享他们的查询,以提升代码库中其它项目的安全性。 Nat Friedman 表示:作为软件安全社区的最新努力,没有一家公司可以独自完成每一个漏洞的查找、并为背后的开源供应链提供完整的保护。 好消息是,Semmle 正好可以填补这方面的空缺,因其采用了基于社区驱动的安全漏洞识别与预防措施。   (稿源:cnBeta,封面源自网络。)

GitHub 源码被黑客洗劫和勒索事件 微软也未能幸免

Git仓库被黑客洗劫和勒索的事件,似乎微软也未能幸免。微软确认其开源开发平台昨天也被黑客攻击,他们被要求支付款项才能归还他们窃取的数百个源码。黑客擦除了微软多达392个代码存储库,并提出勒索要求。此前,黑客攻击了包含微软在内的大批受害者的Git存储库,删除了所有源代码和最近提交的内容,并留下了支持比特币支付的赎金票据。 勒索信息如下: “要恢复丢失的代码并避免泄漏:将比特币(BTC)发送到我们的比特币地址,并通过电子邮件admin@gitsbackup.com与您联系,并附上您的Git登录信息和付款证明,” “如果您不确定我们是否有您的数据,请联系我们,我们会向您发送证明。您的代码已下载并备份到我们的服务器上,“ “如果我们在未来10天内未收到您的付款,我们会将您的代码公开或以其他方式使用。” GitLab安全总监Kathy Wang发表声明回应网络攻击: “我们已确定受影响的用户帐户,并已通知所有这些用户。根据我们的调查结果,我们有充分证据表明受损帐户的帐户密码以明文形式存储在相关存储库的部署中。“ Atlassian的安全研究员杰里米·加洛韦(Jeremy Galloway)已经独立证实,大量用户受到了这种黑客行为的影响。 GitHub建议启用双因素身份验证,为帐户添加额外的安全层。   (稿源:cnBeta,封面源自网络。)  

几大 Git 平台仓库被劫,黑客欲勒索比特币

数百名开发人员的 Git 仓库被黑客删除,取而代之的是赎金要求。 攻击于5月3日开始,包括 GitHub、Bitbucket 和 GitLab在内的代码托管平台都受到了影响。 目前已知的情况是,黑客从受害者的 Git 仓库中删除了所有源代码和最近提交的 Repo,只留下了 0.1 比特币(约 ¥3850)的赎金票据。 黑客声称所有源码都已经下载并存储在他们的一台服务器上,并且给受害者十天时间支付赎金,否则,他们会公开代码。 想要恢复丢失的代码并避免泄露:请将 0.1 比特币(BTC)发送至我们的比特币地址 1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA,并将您的 Git 登录信息和付款证明发送至 admin@gitsbackup.com。如果您不确定我们是否有您的数据,请与我们联系,我们将向您发送证明,您的代码已下载并备份在我们的服务器上。如果我们在接下来的 10 天内没有收到付款,我们将公开代码或以其他方式使用。 在 GitHub 上搜索可发现已有 391 个仓库受影响,这些仓库的代码和提交信息均被一个名为 “gitbackup” 的账号删除。 尽管如此,BitcoinAbuse 平台显示,该比特币地址目前还未收到赎金。 一名用户指出 GitHub 在发现攻击后暂停帐户并进行调查:“GitHub 昨晚在他们调查时暂停了我的帐户,希望今天能听到他们的消息,我可能很幸运。” 据 ZDNet 的报道,好消息是,在深入挖掘受害者的案例后,StackExchange 安全论坛的成员发现黑客实际上没有删除,仅仅是改变了 Git 提交标头,这意味着在某些情况下可以恢复代码提交。 此页面提供了有关如何恢复损坏的 Git 仓库的说明。 最新消息,GitLab 的安全总监 Kathy Wang 告诉 BleepingComputer: 我们根据 Stefan Gabos 昨天提交的赎金票据确定了消息来源,并立即开始调查此问题。我们已确定受影响的用户帐户,并且已通知所有这些用户。根据调查结果,我们有充分证据表明,受损帐户的帐户密码以明文形式存储在相关存储库的部署中。我们强烈建议使用密码管理工具以更安全的方式存储密码,并尽可能启用双因素身份验证,这两种方法都可以防止出现此问题。 目前,平台和用户都在努力解决问题,此处正在持续讨论可能的解决方案。   (稿源:开源中国,封面源自网络。)

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文档。   稿源:开源中国社区,封面源自网络;