我无意中扒了一个公开的S3桶一周，发现了这些有趣的东西

掉进一个探索不安全S3存储桶并发现各种文件的兔子洞。

照片由 Tim Mossholder 拍摄，来自 Unsplash

我在忙一个小 AWS 项目时，注意到一些奇怪的事情。我只是随便把命令 aws s3 ls s3://my-bucket/ 拷贝到终端，却没有替换成我的桶名。虽然没有发生任何事情，我还是感到很惊讶。不应该出现个错误提示吗？

是的，我本应该那样做。如果你在一个不存在的或你没有访问权限的桶里运行 ls 命令，会有错误提示。挺奇怪的。所以我立刻往里面复制一个文件：

搞定了！但为什么呢？AWS 中的桶名是全球唯一的，这意味着只能有一个人拥有一个名为 my-bucket 的桶。显然，这个桶的所有者把它设置成了可读写的状态。想了一会儿后，我决定试着用浏览器打开这个桶，你可以通过这样的 URL 列出里面的东西。

这是一个链接：https://s3.amazonaws.com/my-bucket/

我的测试文件不见了。现在我更糊涂了。我再次通过终端上传文件，文件终于出现在网站上了！我当时也不知道自己在干嘛，这应该就是正常的 AWS 存储桶吧。

我立刻想到，如果我误将一个 aws s3 ls 命令复制到我的终端，那么其他人也有可能误运行一个 aws s3 cp 来将一个随机文件添加到这个存储桶，对吗？这里的 aws s3 cp 中，“cp”代表“copy”。

为了测试一下，我添加了一个简单的定时任务，每分钟列出存储桶中的项目并追加到文件中。在等待这个定时任务运行的过程中，我进一步研究了为什么会有这种通用名称的开放 S3 存储桶，以及它是如何出现的。

我在网上找了找，但没人提到过这个“my-bucket”。我还找到了S3 bucket 命名的指南，但 AWS 并没有对这种 bucket 作出规定，所以这应该不是 AWS 的 bucket。

在我看来，这也讲不通，因为让AWS拥有这个也不合理，以这种方式让人们共享文件实在不明智。即使这个桶是用来做教程的也不行。到目前为止，我确信这是某个不小心公开的个人所有。

好的，回到剧本的内容。当然，里面有一些随机文件！没什么特别吸引人的，但正如我所料，人们确实会犯这种类型的错误，而且迟早有人会在这里添加一些更有趣的内容。

    日志/j-LF8Z0DZ0A04B/节点/i-0ae04761b009b9db7/守护进程/实例状态/instance-state.log-2025-01-18-15-15.gz  
    日志/j-LF8Z0DZ0A04B/节点/i-0e1a325e470fdf19c/守护进程/实例状态/instance-state.log-2025-01-18-15-15.gz  
    日志/j-LF8Z0DZ0A04B/节点/i-0579a8a2e1f6c78a8/守护进程/实例状态/instance-state.log-2025-01-18-15-15.gz

我下载了这些文件，并‘安全’地解压了一下。简单地看了一眼，发现这些文件只是运行了一些程序的EC2机器上的普通日志。除此之外，我还把这些完整的日志输入了ChatGPT，希望能从中找到任何API密钥或公共IP地址，但是一无所获，只看到系统指标、随机日志和私有IP。

出于某种原因，有一个自动化脚本每隔几分钟就会清除存储桶中的所有文件。对于这个自动化程序，我了解不多，不清楚那是一个生命周期策略还是有人运行了一个脚本。但这意味着如果要下载这些文件，得赶紧行动，我不能拖到几个小时后再一起下载。

自动下载

我不会骗你说我写了这个很棒的脚本来从存储桶下载文件。我真的不想在这上面花太多功夫，所以我让ChatGPT帮我做了。这个脚本还有待改进，一会儿我会告诉你为什么，但它确实能搞定。

最后我得到的是这样的：

    #! /bin/bash  

    # 配置  
    BUCKET_NAME="my-bucket"  
    S3_ENDPOINT="https://${BUCKET_NAME}.s3.amazonaws.com"  
    SEEN_FILE=".seen_files"  
    LOG_FILE="logs.log"  
    DOWNLOAD_DIR="downloads"  
    MAX_DOWNLOAD_SIZE_GB=5  

    # 转换为KB以进行du比较  
    MAX_DOWNLOAD_SIZE_KB=$((MAX_DOWNLOAD_SIZE_GB * 1024 * 1024))  

    log() {  
      echo "[$(date +'%Y-%m-%d %H:%M:%S %Z')] $*" >> "${LOG_FILE}"  
    }  

    touch "${LOG_FILE}"  
    log "----- 开始S3下载检查脚本 -----"  

    CURRENT_USAGE_KB=$(du -sk "${DOWNLOAD_DIR}" 2>/dev/null | cut -f1)  
    CURRENT_USAGE_KB=${CURRENT_USAGE_KB:-0}  

    log "当前'downloads'文件夹使用量为 ${CURRENT_USAGE_KB} KB."  

    if [ "${CURRENT_USAGE_KB}" -gt "${MAX_DOWNLOAD_SIZE_KB}" ]; then  
      log "下载文件夹已超过 ${MAX_DOWNLOAD_SIZE_GB}GB (${MAX_DOWNLOAD_SIZE_KB} KB)。跳过下载步骤。"  
      log "----- 完成（跳过）-----"  
      exit 0  
    fi  

    mkdir -p "${DOWNLOAD_DIR}"  
    touch "${SEEN_FILE}"  

    log "从 '${S3_ENDPOINT}' 列出对象..."  
    LISTING=$(curl -s "${S3_ENDPOINT}")  
    if [ -z "${LISTING}" ]; then  
      log "未能获取桶列表或桶为空。"  
      log "----- 脚本执行结束 -----"  
      exit 0  
    fi  

    KEYS=$(echo "${LISTING}" | sed -n 's|.*<Key>\([^<]*\)</Key>.*|\1|p')  

    if [ -z "${KEYS}" ]; then  
      log "未找到对象或桶可能不可公开访问。"  
      log "----- 脚本执行结束 -----"  
      exit 0  
    fi  

    log "检查是否有新文件..."  
    NEW_FILES_FOUND=0  

    for KEY in ${KEYS}; do  
      if ! grep -qx "${KEY}" "${SEEN_FILE}"; then  
        NEW_FILES_FOUND=1  
        log "找到新文件: ${KEY}"  
        mkdir -p "${DOWNLOAD_DIR}/$(dirname "${KEY}")"  

        log "正在下载 ${KEY}..."  
        curl -s -o "${DOWNLOAD_DIR}/${KEY}" "${S3_ENDPOINT}/${KEY}"  
        echo "${KEY}" >> "${SEEN_FILE}"  
      fi  
    done  

    if [ "${NEW_FILES_FOUND}" -eq 0 ]; then  
      log "没有新文件可供下载。"  
    fi  

    log "----- 脚本执行结束 -----"  
    exit 0

它在这方面做得很好。它将所有内容记录到一个简单的文件中，所以我可以轻松地调试这些日志。只有当目标目录剩余空间大于5GB时，它才会下载文件。除此之外，它通过HTTP进行所有操作，而不是使用AWS CLI，因为我希望我的请求不与我的AWS账户有任何关联性。

可能根本不需要避开 AWS CLI，但我担心它可能会产生费用，因为 S3 存储桶有一些设置可以让请求者支付费用。不过这种情况只会在你使用 --request-payer 标志同意付费时发生。除此之外，我甚至不确定通过 CLI 运行命令时，我的 AWS 账户的信息是否会被记录。

脚本不处理的一个问题是文件的实际大小。它会检查我的下载目录中的文件大小是否小于5GB，但是，如果有人上传了一个巨大的5TB文件（这是S3中单个文件的最大存储容量），我的程序则会尝试去下载。

不管怎么说，不担心了，成功了！下载文件夹里开始冒出来一些文件。所以我让脚本每隔几分钟运行一次，连续盯了一个星期，看看一切是否正常，收集了一些文件来检查一下。

看看我得到啥

我把所有文件都留到最后再查看。我知道这肯定好玩得很，就像打开一个神秘礼盒一样，我那猴子一样的大脑急不可耐地想看看这些乱七八糟的文件里藏着什么惊喜。

我当时有点害怕，毕竟。有些是压缩文件，很多是媒体文件，还有一些则只是普通的文本或编程文件。为了安全起见，我决定把它们都放到我那台旧的Linux笔记本电脑上，并通过虚拟机来打开，因为你永远不知道会遇到什么情况。

这些ZIP文件可能包含[ZIP炸弹]，所以我先直接用一种‘YOLO’的心态解压了它们。解压时一切顺利。为了更保险一点，我把所有文件一股脑儿上传到了VirusTotal，但它啥也没查出来。

我发现那个单独找到的 PDF 文件实际上并不是一个真正的 PDF 文件，当我运行 cat file.pdf 时，没有输出。所有其他媒体文件都可以正常打开，不过其中一个 MP3 文件损坏了，导致中途停止。

以下是我在找到的所有文件的清单：

以下是文件路径和名称，用于技术文档中的特定文件：

logs/j-LF8Z0DZ0A04B/node/i-0ae04761b009b9db7/daemons/instance-state/instance-state.log-2025-01-18-15-15.gz
logs/j-LF8Z0DZ0A04B/node/i-0e1a325e470fdf19c/daemons/instance-state/instance-state.log-2025-01-18-15-15.gz
logs/j-LF8Z0DZ0A04B/node/i-0579a8a2e1f6c78a8/daemons/instance-state/instance-state.log-2025-01-18-15-15.gz
logs/j-LF8Z0DZ0A04B/steps/s-070560812W397VXJOFTL/syslog.gz
logs/j-LF8Z0DZ0A04B/node/i-0e1a325e470fdf19c/applications/hadoop-hdfs/hadoop-hdfs-namenode-ip-172-31-45-95.ap-east-1.compute.internal.log.gz
logs/j-LF8Z0DZ0A04B/node/i-0e1a325e470fdf19c/applications/hadoop-yarn/hadoop-yarn-timelineserver-ip-172-31-45-95.ap-east-1.compute.internal.log.gz
作业.jar
layers/dependencies.zip
Ferly_bengal_dev.png
pricing-config/test_file.csv
/case-data-with-predictions.json
tracking/done_ranges.csv
sabun_check/step2_image7/step2/systemctl.txt
139388a9-c228-401b-a909-030bc3ceb83d.mp3
test-reports/report-1737500197721.pdf
ec2-cajayon.txt
e04c7014-5e46-40de-bf4e-41f0b60cb7d7.mp3
ml/cg-v2/year=2025/month=01/day=21/候选生成_v2.parquet_0_7_2.snappy.parquet

现在终于到了你最期待的部分，我下载的所有东西里面就是这个。

`logs/` 下的文件都和我之前说的差不多，是一些EC2实例的一般日志和系统指标，没有包含任何可能保密的私有IP地址等信息。

反编译后的`.jar`文件原来是一个为Hadoop设计的小WordCount Java程序，注释是用中文写的。

`layers/dependencies.zip` 这个文件包含了运行自然语言处理(NLP)项目所需的Python包，用于Lambda函数。所有这些TXT和JSON文件都非常小，也没有任何特别的内容。

CSV和PARQUET文件都包含了训练机器学习模型所需的数据，这些数据已编码和标准化。两者都使用了假数据集。

![](https://imgapi.imooc.com/5a66ec6709c53abe14000564.jpg)

这些MP3文件我觉得挺有趣的。这两个文件都是有声书的随机章节，我觉得可能都是用的AI语音来朗读的。

其中一个肯定来自《富爸爸穷爸爸》这本书；另一个则来自一本关于重新编程思维的书。我可能做得不够好，但我试图在谷歌图书中搜索这本书的部分内容，但还是没能找到书名！也许AI在那个部分上出了错。

这些图片也相当随机。我不会直接在这里贴出它们，但我在这里给你链接到 Imgur，（两者都适合工作环境）：

* 找到了這個 AI 生成的 [賽博朋克貓，有一隻類似人類的手](https://i.imgur.com/RzFUJpX.jpeg)（更令人驚訝的是，它有五根手指）。
* 以及這個 [剛找到工作後的人的照片](https://i.imgur.com/KJPAXpI.png)。

# 当前情况

截至撰写之时，`my-bucket` 不幸的是已经不再公开了。我仍然不清楚为什么有人会把它们一直公开，但过去某个时候我注意到 `test-bucket` 也曾公开过，所以这种情况可能会时有时无。

要找到这些，你可以试试这样的脚本。我刚刚用了一些随机的桶名运行了它，发现一个叫 `shared-files` 的是开着状态。

#!/bin/bash  

buckets=(  
    "my-bucket" "test-bucket" "default-bucket" "new-bucket" "example-bucket"  
)  

# 检查每个存储桶并尝试列出其内容  
for bucket in "${buckets[@]}"; do  
    echo "正在检查存储桶：$bucket"  
    aws s3 ls "s3://$bucket" --no-sign-request 2>/dev/null  

    if [ $? -eq 0 ]; then  
        echo "[+] 存储桶可以访问: $bucket"  
    else  
        echo "[-] 存储桶无法访问: $bucket"  
    fi  
    echo "----------------------------------------"  
done

# 总的来说
# 结尾

这是一条有趣且意想不到的路。项目完成后，我检查了所有文件，然后跟同事们提起这件事，他们对在公开存储桶中找到的随机东西表现出了很大的兴趣。看来大家都有一样的好奇心，对抽奖箱之类的东西充满好奇。

显然，这样做存在一些问题。随意从互联网下载文件通常是个糟糕的主意。而且，如果有人想这么做，他们可以向这些开放的存储桶乱扔垃圾，从而给存储桶的所有者带来高昂的成本，这绝对不是我的本意。

我还是不明白为什么人们会把这些桶敞着，或者为什么它们会时不时地关上。也许它们换过主人，或者这些桶的主人其实知道自己在做什么，正在收集各种各样的文件来自人们，更糟糕的是，它们可能在像我这样的用户分发恶意文件……

如果有人了解这些通用开放桶，请告诉我。我上网查了查，但没找到任何相关信息。希望能了解更多关于这些桶的信息。

不管怎么样，希望你读得开心，也许还学到了一些关于 S3 存储桶安全的新东西。如果你觉得有用或有趣，请点个赞，或者把它分享给朋友看看。

真的非常感谢你花时间读这个。