Github Action进行侦察

收录于话题

20XX安全Team Author 安服人

网络安全新基建、为安服人而骄傲

背景故事

正如我在年度回顾博客文章中所写的那样，最初，当我开始进行漏洞赏金时，我主要专注于Android应用程序，但是随着时间的流逝，我意识到仅专注于android应用程序不会对我有多大帮助。因为大多数时候程序在范围内通常只有1或2个android应用程序，而这些应用程序有时仅会产生无法复制的bug。因此，在今年年初，我决定扩大搜索范围，并尝试查找Web应用程序上的错误。

现在，如果您倾向于在网站/ Web应用程序上进行漏洞赏金，那么您一定已经听说所有伟大的猎人都说过“recon is important或”之类的P1 in 1 minute just by recon话。然后，您将看到侦察中的大多数任务必须自动化，重点放在单词上，has因为侦察过程中有某些步骤，我们将尝试在所有程序/目标上执行。因此，我决定进行自己的侦察设置，因为它不是一个非常先进的东西，也不是什么大而简单的东西。

基本侦察流程

最初，我编写了一个小脚本，该脚本执行以下操作：-将范围中的所有域存储到一个名为的文件中scope.txt -运行多个子域枚举工具，例如amass，subfinder等scope.txt，合并所有输出并给出-If subdomains.txt subdomains.txt已经存在，然后将新的与旧的进行比较，如果发现任何新的子域，则生成警报。-在该文件上运行massdns和httpx。

在阅读了很多关于侦察方法的博客文章后，我想到了整个想法。几乎每个人都建议拥有VPS（这不是强制性的，但有帮助）。所以我想我可以在VPS的cronjob上设置这个小脚本，然后等待它生成警报。但是那是我想到的时候why not do this with GitHub actions

什么是Github动作？

GitHub Actions借助世界一流的CI / CD，可轻松实现所有软件工作流程的自动化。直接从GitHub构建，测试和部署代码。使代码审查，分支机构管理和问题分类工作按您想要的方式进行。

简而言之，它是的更好替代travis。如果您有GitHub项目，并且想要运行linter检查或tests对每个请求请求进行操作，以确保没有中断，则可以设置一个Github Action来执行此操作。

现在，即使Github Action是为执行更简单的操作（例如运行测试/运行程序）而制作的，它也可以做很多强大的事情，因为最终它实际上是一个虚拟机。可以通过Github Action执行可以在VM上运行的东西（甚至可以在常规设置下运行）。

Github行动进行侦察

让我们看看用一个例子，假设你想运行subfinder在一个名为scope.txt其example.com在里面。这scope.txt存在于您的Github存储库中。

on: [push] # This is a trigger https://docs.github.com/en/actions/reference/events-that-trigger-workflows

jobs:
  build:
  # The OS for which will be used.
  # You can specify the exact version if you want.
    runs-on: ubuntu-latest

    # From here we just define all the steps that we have to do.
    steps:
      - name: Checkout Repo
        uses: actions/checkout@master

      # Install golang
      - name: Setup golang
        uses: actions/setup-go@v2
        with:
          go-version: '^1.14.14'

      - name: Setup go tools
        run: |          go version
          GO111MODULE=on go get -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder          

      - name: Run Subfinder
        run: subfinder -silent -dL scope.txt -o subfinder.txt

      - name: Save domains
        run: |          git config --local user.email "myemail@example.com"
          git config --local user.name "MY USERNAME"
          git add --all
          git commit -m "Add Subdomains.txt"          

      - name: Push changes
        uses: ad-m/github-push-action@master
        with:
          github_token: ${{ secrets.TOKEN }}

我在上面的示例中写了一些评论。对我们来说重要的是，steps这些是我们要求Github Action在VM内部执行的基本操作。

下面我试图详细解释所有步骤：

检出您的存储库文件

- name: Checkout Repo
    uses: actions/checkout@master

这是预定义的操作，即action / checkout。这将基本上所有复制您的GitHub库到虚拟机的文件，这意味着如果你有称为文件scope.txt存储库中的话反而会使得一个文件名为scope.txt在/home/虚拟机的目录中（其中一个将运行我们的工作）。

设定golang

既然subfinder是写的，golang我们需要在虚拟机中安装go。

- name: Setup golang
    uses: actions/setup-go@v2
    with:
        go-version: '^1.14.14'

的安装页面subfinder显示go版本1.14+是必需的，因此我们在这里进行安装1.14.14。顺便说一句，这actions/setup-go也是一个预定义的GitHub操作，您可以在此处找到。

安装subfinder并运行它

- name: Setup go tools
  run: |    go version
    GO111MODULE=on go get -v github.com/projectdiscovery/subfinder/v2/cmd/subfinder

直到这一步，我们必须在环境中安装subfinder。因此，如果您必须从normal文件系统的角度来思考，您可以将其想像成一个虚拟机，其中有一个虚拟机，该/home目录中有一个目录，我们有一个目录名为go（假设所有go软件包都安装在其中）名为的目录go/。在此过程中，我们安装了一个名为的工具subfinder。另外，在/home目录中是一个名为scope.txt。

现在是我们跑步的时候了 subfinder

- name: Run Subfinder
  run: subfinder -silent -dL scope.txt -o subfinder.txt

这将在VM上执行命令，并生成其中包含所有子域的文件。

将文件推回仓库

现在，一旦子查找器生成了输出，您显然希望看到该输出。最好的选择就是将文件推回到您的仓库中。

- name: Save domains
    # if you don't want to push all the files back then you can also mention it like `git add subdomains.txt`
    run: |        git config --local user.email "myemail@example.com"
        git config --local user.name "MY USERNAME"
        git add --all
        git commit -m "Add Subdomains.txt"        

- name: Push changes
    uses: ad-m/github-push-action@master
    with:
        github_token: ${{ secrets.TOKEN }}

这两个步骤基本上是将所有新生成的文件（即添加subdomains.txt到GitHub存储库），然后推送该文件。这类似于add, commit, pushgit中normal的工作方式。

如果您注意到最后一行，它说secrets.TOKEN这是您可以从GitHub设置生成的秘密令牌。要了解如何生成和添加令牌，请阅读此内容。

这是如何使用Github操作运行简单命令的基础。现在，在讨论如何做复杂的事情之前，我想谈谈此设置的局限性。

局限性

由于Github Action并非用于Bug搜寻或任何大型任务，因此它有其自身的局限性。非常重要的是：

工作流程中的每个作业最多可以运行6个小时的执行时间。

赶时间限制会导致工作失败
这意味着我们无法在可能需要超过6个小时的子网中运行masscan

您可以在一小时内通过存储库中的所有操作最多执行1000个API请求

一小时内仅允许1000个API请求。
因此，如果要对子域进行Github Dorking，则需要找到一种有效的方法来在每个请求中获取更多数据。

您每个月仅获得某些分钟的Github Action。

对于GitHub专业版用户，您可以获得3000分钟（即每月50个小时的Github Action）
对于普通用户，我认为每月限制为2000分钟左右

除此之外，还有其他一些限制，您可以在此处阅读有关限制的信息。

现在，关于的最后一个限制minutes per month是唯一听起来可能有问题的东西，但实际上并非如此。我进行了一些测试，发现如果您有5个目标（网站）scope.txt并运行，amass + subfinder + findomain然后将输出传递给massdns，httpx则整个工作将在2分钟内完成（绝不超过2分钟）。

如果我们做数学，那么一个月内大约有730个小时，假设您每5个小时运行一次作业，这意味着146一个月内的运行时间。假设每项工作需要2分钟，那将总共是292几分钟。而作为普通用户，您有2000分钟的时间，因此您仍然会有〜1708分钟的Github Actions。现在，要完全耗尽限制，您可以在不同的时间间隔运行很多作业。其中一些如下：

每44分钟执行一次2分钟的工作，到月底，您的配额还剩10分钟左右。
每10个小时执行一次27分钟的工作，到月底，您的配额还剩下〜21分钟。

如果我算错了数学，请告诉我