云函数实例研究 · 新工具绝影

当云函数运行时会接收来自用户的 HTTP 请求，然后通过函数执行对应任务，创建云函数实例去执行任务，执行完毕后云函数实例销毁。并且由于云函数没有固定的公网IP，实际上是虚拟IP，每次创建的实例都可能会有不同的IP。

因此云函数就具备以下基础特征：

1. 即用即销
2. 实例随机
3. IP随机

基于这些特点，很容易想到，用云函数做代理，就能实现代理池。这就引申出云函数目前最高价值的用法：云函数代理，具体实现可见

SeaMoon：https://github.com/DVKunion/SeaMoon。

但除了代理外，我发现云函数的实例本身也是很有意思的。

控制实例的生命周期

首先我们知道，云函数实例是即用即销的，除非是短时间内连续发包，否则都会在任务结束后销毁实例。所以云函数实例的销毁时机是：函数结束，也就是当函数 return 的时候。

换言之，当函数没有执行完的时候，除非是函数超时，否则实例不会销毁。

这里只展示腾讯云函数的，腾讯云函数的超时时间最多只能是900秒。

既然函数在执行完成前不会销毁，那么我们是否可以通过让函数执行反弹shell的方式来控制实例？

事实上是可以的，因为云函数本身就是可以让我们代码执行。

是的，我把这些都武器化了，shadowabi的秘密武器：绝影。

可选择的持久化

只能 RCE 实例本身是没什么用的，因为实例里什么都没有。如果每次都现场下载自己的工具什么的，非常麻烦，更何况像腾讯云的云函数实例是 qcloud 用户，没法 yum install。

如果我们的各种黑客工具一开始就存在于实例中，就会非常方便。事实上是可以的。当我们编辑云函数的时候，cloud IDE 允许我们上传文件上去

根据官方文档，只要和 index.py 同一目录，文件就会被带到实例中，并且会集成 +x 属性。也就是说，我们可以传入二进制文件进去，直接运行。

说到这里，会不会有人想到，能带属性，我直接 chmod +s 或者 setcap 岂不是可以提权 qcloud 用户，云函数本地提权漏洞！

然而事实上并不可以，不知道是被修了还是本身就没有。反正我试过了没有。

那么现在，只需要实现准备好要用的工具，就能利用云函数部署我们的实例了。通过这个方法部署的实例，首先是方便，云函数实例的冷启动也就几秒钟，通过绝影这个工具，一行命令就进去了。相比之下，无论是用 terrafrom 还是 镜像、云服务器启动模版来部署实例，都没这个快。

镜花水月的网络

前面提到，云函数实例的 IP 是虚拟的，经过实测发现，即使是同一个实例，也拥有 2 个公网 IP，所以单一实例本身其实也有抵抗封 IP 的效果。

而虚拟 IP 本身给云函数实例带来了非常好的防御效果，首先是你不能通过云函数实例的公网 IP 去访问他，另外用云函数实例的 IP 去溯源，是无效的

这一特性，真的是天生就是适合做代理池。

快速施法

我一直在思考一个问题，云函数实例的利用，似乎怎么样都难以和做云函数代理 SeaMoon相比，直到我发现了这个方法。

代理 IP，只是 IP 变了，实际上跑一个程序还是原来的速度。但云函数实例不一样。

比如说，我要用 dirseach 去扫目标，有100个目标，这时候，如果我能批量对云函数实例下发命令，异步取回结果就能实现快速施法。

这里我并没有有云函数本身自带的异步，而是利用 go 的多线程来完成。

现在，我们放一个文件，里面有 ipinfo.io 和 ip.sb 两行，作为目标，现在我要批量执行 curl，来访问这两个目标

并且在实现上，为了防止太快达到访问速率限制，我做了轮换功能，每次发起一个请求，会依次轮换到下一个云函数厂商。我这里配置了2个云函数。

当然了，扫目录的网络流量还是有可能会触发云厂商的安全风控，总之，云函数使用时还得保持谨慎。

云函数的双刃剑

用云函数最担心的还是溯源问题。虽然云函数实例的 IP 是假的，但我们不妨假设，如果云函数被反制，被人RCE正如同我们的反弹shell控制云函数实例一样。

会有一个非常致命的问题，实例中的环境变量会直接定位到帐号

比如腾讯云，默认会有环境变量：TENCENTCLOUD_APPID 、TENCENTCLOUD_UIN 直接关联帐号。

又比如我们在利用反弹 shell 控制实例时，会存在网络连接和对应进程暴露VPS IP。

当然了，这些都是可以解决的，加入狼组 你就会看到了。

关于绝影

目前是私有状态，感兴趣可以来找我加入