Clever Geek Handbook

黑客如何窃取密钥和密码？

我正在寻找各种安全系统中的漏洞。在某种程度上，对我来说很清楚，我的客户对“黑客”的基本技术还不够熟悉（甚至根本不熟悉）。 API密钥，密码，SSH密钥，证书都是很好的安全机制。但这是只要他们被保密。对于那些不应该访问这些数据的人来说，事实证明，密码的复杂性和哈希算法的先进性不再重要。在这篇文章中，我想谈一谈安全研究人员用来查找机密信息的概念，方法和工具。此类数据用于破解系统。我还将在这里分享一些简单的工作流程，这些工作流程可以帮助降低成功遭受黑客攻击的风险。







重要的是要注意，由黑客和计算机系统所有者玩的攻击与防御“游戏”是不诚实的游戏。攻击者足以侵入系统，仅赢一次。而那些捍卫者只能通过永远获胜来获胜。这里的主要困难是要知道您需要注意什么。但是在防御者知道黑客可以进入其系统的虚拟“门”之后，可以使用相当简单的机制来保护这些“门”。我认为这些机制的简单性有时会降低其重要性，这是许多计算机系统防御者忽略这些机制的原因。



这里是我将在本文中公开的保护系统的基本规则。它们很简单，但这并不意味着您可以不受惩罚地忘记它们：



  • (multi-factor authentication, MFA) , . Google GitHub, , VPN-. MFA — .
  • , .
  • , . .
  • . , .


在防止分类信息泄漏和防止安全系统中出现“漏洞”的问题上，帕累托原理起作用，据此，20％的努力产生了80％的结果。



黑客找到密码和秘密密钥时如何工作？他们使用什么工具？



黑客在JavaScript文件中发现秘密数据



API密钥分散在整个Internet上。任何人都可以使用它们。这是事实。通常，没有公开公开密钥的特定原因。开发人员只是到处忘记它们。例如，出于以下原因，键进入了代码：



  • 用于调试目的。
  • 为了当地发展的目的。
  • 以评论的形式提供给以后支持该项目的人。


在Internet上经常可以找到类似于以下内容的代码块： 



// DEBUG ONLY
// TODO: remove -->
API_KEY=t0psecr3tkey00237948


尽管许多黑客自己读取JavaScript文件，但他们大多使用诸如meg之类的工具搜索此类文件，然后检查所找到的文件是否匹配模式。



他们是怎么做到的呢？使用扫描仪后，meg他们似乎在找到的文件中查找与各种模式匹配的字符串。创建的人meg编写了另一个出色的程序，专门用于此目的。它称为gf，是改进版本grep。在这种情况下，在启动时使用该gf选项，truffleHog或者在其编写的另一种形式中trufflehog，允许该工具查找作为API关键的高熵字符串。字符串搜索也是如此API_KEY...这样的字符串的搜索结果通常（经常）成功。



通常，出于完全正常的原因，密钥会出现在代码中，但是这种密钥不受外部人员的保护。让我举一个例子。与我合作的一位客户使用了外部地图信息服务。这在许多项目中都是完成的。为了下载和使用地图信息，必须使用密钥来调用相应的API。但是我的客户忘记了配置他正在使用的服务，以限制该服务可以使用该特定密钥接收请求的来源。不难想象有一种简单的攻击，其中包括通过向地图服务发送许多请求来耗尽地图服务的资源使用配额。这会使这种服务的用户花费很多钱。要么，即使是“更好”（从攻击者的角度来看），这种攻击也可能导致这样一个事实，即客户项目中与卡片相关的部分只是“掉下”。



黑客使用JS文件不仅仅是寻找秘密数据。毕竟，这些文件是您的应用程序的代码，对此代码感兴趣的任何人都可以看到。优秀的黑客在仔细阅读代码后，可以了解其中使用的实体命名方法，找到指向API的路径，并可以找到有价值的注释。这些发现的格式设置为传递给自动扫描仪的单词列表。这就是所谓的“智能自动扫描”，黑客将自动工具和他们收集的有关特定项目的信息结合在一起。



这是一个项目主页上的真实评论，它以纯文本的形式讲述了任何人都可以从中获取数据的不安全API： 



/* Debug ->
domain.com/api/v3 not yet in production 
and therefore not using auth guards yet 
use only for debugging purposes until approved */


to怎么办？



  • . . , , .
  • API. , . , .
  • , , . , , , , , , . , .
  • , . . , . grep gf . . , , .
  • -. , - . 100% . - — .


, -



Internet存档（也称为“ Wayback Machine”）存储网站的定期快照。该项目使您可以看到很多年前的互联网。存档数据对于需要收集有关某个项目信息的黑客非常感兴趣。您可以使用诸如waybackurls（基于waybackurls.py）之类的工具扫描文件以查找网站的旧版本。这意味着，即使您在站点代码中找到了一个密钥并将其从其中删除，但没有旋转密钥，黑客仍可以在旧版本的站点中找到该密钥，然后使用此密钥来入侵系统。



如果找到不应该存在的键，请执行以下操作：



  1. 创建旨在替换受损密钥的密钥。
  2. 释放使用新密钥的代码的新版本。应该重写此代码，以便其中没有任何行可以轻松识别密钥。
  3. 删除或停用旧密钥。


Archive Internet存档不是唯一找到密钥的地方



旧代码为攻击者提供了各种各样的有用信息。



  • API秘密路径。我们正在谈论开发人员认为永远不会共享的不安全API端点。尽管黑客发现的路径可能对他们没有用，但这些路径可以帮助您理解项目的API及其API约定的设计。站点代码投入生产后，开发人员无法隐藏此代码。记住这一点非常重要。
  • -. , API, . , . , , . , -. , , . , , . , s https.


GitHub



GitHub是黑客的金矿。如果您知道在哪里看，可以使用简单的搜索工具找到很多有趣的东西。如果您组织的GitHub帐户不受多因素身份验证的保护，那么该组织的所有员工无一例外都会遇到安全漏洞。有些员工很可能在各处使用相同的密码，并且该密码已经通过其他系统从他们那里窃取。对某个组织感兴趣的黑客可以轻松地自动搜索受到破坏的密码，但是我可以说，他可以手动找到这种密码。



可以使用开源情报（OSINT）技术创建组织的员工花名册。 LinkedIn或来自GitHub的公司员工的公开列表可以帮助攻击者实现这一点。



例如，如果有人决定入侵特斯拉，那么他很可能会从此页面开始研究公司： 



https://api.github.com/orgs/teslamotors/members


即使公司没有将GitHub用作git平台，在GitHub上仍然可以找到一些有价值的东西。该平台至少被公司的一名员工使用，例如用于家庭项目就足够了。如果关于公司的秘密出现在该项目的代码（或git历史记录）中，这将足以渗透该公司的系统。



跟踪每个项目所做更改的完整历史记录是git的本质。鉴于安全问题，这一事实起着巨大的作用。换句话说，任何有权访问组织的任何系统的人对代码进行的每一次更改都会使该组织面临风险。



▍为什么会这样？



  • 公司不检查其系统的漏洞。
  • , , .
  • , , ( , , 1%), ( — git, , , ).
  • , . .


▍ GitHub



有一个“笨蛋”之类的东西-特殊的搜索查询，它们使用搜索引擎的不同功能来查找与某些数据相关的内容。这是exploit-db.com对Google进行的类似搜索的有趣列表。



如果您想更深入地研究这个主题，并且我建议您这样做，那么在为您提供用于在GitHub上查找密钥和密码的字符串的简短列表之前，我建议您阅读这份由有才华的系统安全研究人员撰写的有价值的材料。他讨论了如何在GitHub上搜索，搜索内容和位置以及在何处搜索，如何使用dorks，并详细概述了查找秘密数据的手动过程。



GitHub上使用的道路并不像Google上使用的道路那么复杂。关键是，GitHub根本无法为用户提供与Google相同的高级搜索功能。无论如何，对GitHub存储库进行适当的搜索都会产生奇迹。尝试在您感兴趣的存储库中搜索以下行： 



password
dbpassword
dbuser
access_key
secret_access_key
bucket_password
redis_password
root_password


而且，如果您尝试使用诸如filename:.npmrc _auth或的查询来搜索特定文件filename:.htpasswd，则可以按数据泄漏的类型过滤搜索结果。这是关于该主题的另一篇好文章。



to与GitHub相关的风险缓解措施



  • 在CI流程中，扫描代码中的漏洞。出色的GitRob工具可以帮助您解决这一问题。
  • . GitRob . , no-expand-orgs.
  • . GitRob, , 500 , , -commit-depth <#number>.
  • GitHub !
  • , , , , . G Suite Active Directory. , .


该材料出版后，一些读者对密码的复杂性，密码的轮换以及对信息的硬件保护的使用提出了宝贵的意见。



这是@ codemouse92的评论：



在使用密码登录的任何地方，请使用复杂且唯一的密码。但是请记住，复杂的密码不一定是由字母，数字和特殊字符组成的神秘杂物。现在最好的策略是使用长短语作为密码。我想对密码管理器做一说明。虽然绝对值得使用这样的程序，但最好还是使用密码，密码是用户记住并可以自行输入的短语。


这是用户@corymcdonald说的：



在我工作的地方，每个人都获得了多重身份验证硬件。每个都有2个YubiKey设备。此外，每个团队都使用1Password密码管理器，每个团队都有自己的密码库。当员工离开公司时，支持团队会轮换员工可以访问的每个保管库中的密码。例如，就我个人而言，我通过在GitHub上发布访问AWS的密钥犯了一个不可原谅的错误。建议您在提交之前使用git-secrets检查材料。这将防止共享看起来像机密信息的内容。


黑客使用Google



现在，我们已经对傻瓜有了基本的了解，现在我们可以讨论Google上特定搜索查询的使用。在他们的帮助下，您可以找到难以置信的东西。 Google是一个功能强大的搜索引擎，可让您构建查询，以描述所要查找的数据中应该存在和不应出现的字符串。 Google可以让您搜索带有某些扩展名的文件，可以通过URL搜索指定的域。看一下以下搜索字符串： 



"MySQL_ROOT_PASSWORD:" "docker-compose" ext:yml


此字符串旨在搜索扩展名为的文件yml，而且这些文件应该是docker-compose开发人员经常在其中存储密码的文件。不是特别独特的密码。尝试运行Google搜索此字符串。您会为发现的东西感到惊讶。



其他有趣的搜索字符串可能正在寻找RSA密钥或AWS凭证。这是另一个例子： 



"-----BEGIN RSA PRIVATE KEY-----" ext:key


在这里，无限的可能性在我们面前打开。搜索的质量仅取决于研究人员的创造力水平以及他对各种系统的熟悉程度。如果您想尝试，这里有很多Google Dorks。



黑客审查他们感兴趣的系统



当安全研究人员（或积极的黑客）对某个系统非常感兴趣时，他便开始深入研究该系统。他很了解她。他对API端点，实体的命名约定，系统内部部分的交互的特殊性，如果同时使用不同版本的系统的访问权限的可用性感兴趣。



保护API的一种不太好的方法是使访问它们的路径复杂化，并使用诸如随机字符生成器之类的东西将其隐藏。这不能替代真实的安全机制。安全研究人员正试图使用​​“模糊”搜索漏洞的工具来查找系统，API端点的不安全访问路径。此类工具使用单词列表，从单词列表中构建路径，并通过分析尝试访问它们时收到的响应来验证这些路径。这样的扫描器将找不到端点，该端点的路径由完全随机的字符集表示。但是，此类工具非常适合识别模式所有者和找到系统所有者忘记或从未知道的端点。



请记住，“通过模糊性提供安全性”并不是保护系统的最佳方法（尽管您不应完全忽略它）。



这就是我们上面所讨论的GitHub怪癖向网络犯罪分子提供帮助的地方。知道在构造到系统端点的路径时使用什么规则（例如-之类的东西api.mydomain.com/v1/payments/...）可能对黑客有很大帮助。在公司的GitHub存储库（及其员工存储库）中搜索与API相关的字符串，通常会找到包含随机字符的路径。



但是，“随机字符串”仍然在系统中占有一席之地。它们的使用总是比使用序列从资源标识符，字符串比如更好的users和在路径的API orders。



这是很棒的SecLists存储库，其中包含在命名实体时使用的许多字符串。数据保护行业中几乎每个人都使用它。通常，针对特定系统修改这些材料。FFuf是用Go编写的一种非常快速的模糊逻辑程序，可以用来查找“加密”路径。



结果



安全问题在初创公司中经常被忽略。程序员和管理人员通常会优先考虑产品发布的开发速度和频率，从而牺牲质量和安全性。在这里，我们看到进入存储库的代码中包含秘密信息，在系统的不同位置使用相同的密钥，在其他地方可以使用访问密钥。有时候，类似的事情似乎可以使您加快项目的工作，但是随着时间的流逝，可能会导致非常糟糕的后果。



在这篇博文中，我试图向您展示了似乎通过存储在私有存储库中而受到保护的字符串如何可以轻松地公开。由好心的员工制作的存储库的副本也是如此，它的目的不是为了撬开眼睛，而是证明是公开的。但是，您可以通过使用安全的密码共享工具，使用集中的机密信息库，配置密码安全策略和多因素身份验证来为安全操作奠定基础。在不忽略安全性的情况下，这将不会减慢项目的工作速度。



当涉及到保护信息时，速度是最重要的想法在这里并不奏效。



了解黑客如何工作通常是了解什么是信息安全的非常好的第一步。这是确保系统安全的第一步。在保护系统安全时，请考虑以上渗透这些系统的方法，以及黑客使用相当有限的此类方法这一事实。从安全性的角度出发，建议绝对考虑以某种方式与某个系统相关的所有事物，而不管它是外部机制还是内部机制。



有时可以将系统安全性视为不是很重要，但是却很耗时且忙碌。但是请放心，为保护系统而采取的简单步骤可以为您省去很多麻烦。



您如何保护系统？









More articles:


All Articles