Dive into the Cloud: Unveiling the (Ab)Usage of Serverless Cloud Function in the Wildのメモ

• paper
• #論文
• #Cloud
• #Serverless
• #Network
• #IMC

Dive into the Cloud: Unveiling the (Ab)Usage of Serverless Cloud Function in the Wild

Liu, Yijing and Liu, Mingxuan and Zhang, Yiming and Liu, Baojun and Zhang, Jia and Hong, Geng and Duan, Haixin and Yang, Min

ACM IMC2025

2025

どんなもの？

近年急速に拡大しているServerless Functionの利用の中で、悪意のある利用方法が存在する。 しかし、実際にどのように利用されているのかの分析は行なわれていない。 データセットの作成を行いServerless Functionの分析を行う。 Serverless Functionの中で4.89%が悪意のある利用が行なわれている事を確認した。

先行研究と比べてどこがすごい？

DNSのQuery Dataを利用してServerless functionが攻撃者によってどのように利用されているのか調査した。

悪用の方法

C&C

16台のC2Cサーバーを特定し、それらが273,291件のリクエストを生成していることを確認した。 攻撃の指令に利用されている事を確認した。

Hosting Malicious Websites

206件の悪意あるウェブサイトを特定した。 これらは多岐にわたる脅威を含み、合計で3万7000件を超えるリクエストが確認した。

悪意のあるページだがCloud Providerの共用のIPなのでBlockもされずらい。

違法サービス

隠された違法サービスを拡散するために利用されているらしい。 ユーザーを不正なウェブサイトへリダイレクトさせたり、応答に宣伝情報を含めたりしている。 267 cloud functionsがアクティブで、123,086 件のリクエストがあった。

このようなサービスは平均で152.26dayも稼動しており、違法サイト自体の場所がころころ変るのに対して、Cloud Providerにホストされリダイレクトされるだけのサービスは比較的安定して違法サービスのポインタとして機能しているらしい。

Egress Nodes Abuse

Cloud ProviderのFunctionの共用のEgressを利用して、Proxyを構築している物。 攻撃者が管理しなくても、勝手にEgressをころころ切り替えてくれるので便利らしい。

GitHubやOpenAIなどのGFWでアクセス出来ない宛先にアクセスするためのProxyとかもあるらしい。 また、違法Downloadのための口など、Cloud Providerの出口なのでBlockされにく事を悪用している手口も多いらしい、

技術や手法のキモ

中国国内のDNS Providerからデータセットを作成しDNSのデータセットを作成。 そのデータセットからServerless Functionで利用されるドメインの構造を用いてFunctionのEndpointを抽出した。 その結果、531,089件のServerless Functionをドメインを抽出しその分析を行なった。

データには以下の制限がある

• メジャーなCloud Providerのみ収集
• DNSから分かる物のみで、API-Gatewayなどを利用している物は不明
• 中国国内で収集されたデータである事
• 分析対象に出来ているのがドメイン名のみなのでHTTPのリクエストパスなどは分からない事

どうやって有効だと検証した？

手法そのものなのでSkip

議論はある？

Serverless FunctionをBlockするのは難しい。 分析されたコンテンツの4.89%は悪用されている事が判明している。 動的なEgress IPやデプロイの容易さや、コストの安さ、Cloud ProviderとしてのBlockのされにくさなど悪用されやすい理由が多数ある。

著者らの提言

1. Cloud Providerはもっと監視を強化するべき。
   • 中国国内ではランダムな監査が中国政府の要請に基づき行なわれている
   • AliyuやTentcentは実施している
   • ただ悪用も多い - そもそも、Abuseしやすいのでもっとデプロイに監査をするべきだ
2. FunctionoのCNAMEなどを自動的に削除されるようにするべき
3. 認証認可のないインターネット公開の難易度や警告をもっと上げるべき

とはいう物の、Serverless Functionが流行っているのはこれらが簡単なのもあるので微妙な所だなぁと思う。

次に読むべき論文

• Abusing CDNs for fun and profit: Security issues in CDNs’ origin validation
  • CDNに対する同様の分析
• How does it function? characterizing long-term trends in production serverless workloads
  • ServerlessのProductionでのworkloadの分析

感想

単純にServerless Functionとして使われているサービスのトレンドが面白かった。 無料期間がおわるとガタっと使われなくなるというのは分かっていたが、それでも半分くらいは残るというのはキャンペーンやる意味があるなぁと思った。

各社がどのようなイングレス設計なのかも面白かった。

• 基本的にCNAMEを使っている事が多い。ただ、GoogleくんはなんかAレコードらしい
• Google Functionの古いendpointは1 IP addressでIngressをすべて受けていたらしい。
  • Google Frontend的な1つのIPでGlobal Scale出来るインフラがあるのかな?
• 中国国内だったので、hina TelecomやChina Mobileなどの事業者を使っている所も多いっぽい
• IBMはCloudflareをIngressに使っているらしい
• AWSはap-northeast-1（東京）に2,082個のIPv4および2,579個のIPv6イングレスノードがあり、eu-west-1（アイルランド）やus-east-1（バージニア）といった他の主要リージョンでも、イングレスノード数は1,000ある

Serverless FunctionのLifespanはやっぱり短かい。 分析期間(730days)の間にずっとActiveだったのは0.32%のみで、83.94%が5日程度、平均すると21.44日がFuncitonの1つのEndpointのLifespanになっている。

Serverless Functionで認証認可が設定されている物が少なく、情報漏洩の危険性があるのではないか?という事。 Endpointにリクエストすた時に401を返したのは0.13%で、ほぼほぼ認証認可がないように見えるらしい。 Webページのホスティングなどでは必要ないため、これは問題ないかもしれない。 また、API-Gatewayを集計出来てないので、ちゃんとサービングしてる人はAPI-Gatewayを使ってないのでこれは集計方法の問題かなぁと思う。

全体の応答としてJsonが36.98%、HTMLが31.54%、Plantxtが30.34%らしい。 JSONはAPIとして、HTMLが30%を超えているという事は、FunctionそのままでWebページをホスティングさせているのがそれなりにあるんだなぁと思った。