はじめに

株式会社SHIFT DevOps推進グループの横山です。
元セキュリティエンジニアで今でもセキュリティ関係の技術書をよく読み、Flaskアプリの脆弱性を利用したAWS環境へのバックドアの作成、という面白そうな内容を見つけましたので検証しました。
「How to Hack Like a Ghost」という日本ではあまり知られていないかもしれないセキュリティの良書に記載されているシナリオの一部の再現になります。

FlaskアプリにおけるServer-Side Template Injection(SSTI)からのRCE

FlaskアプリにおけるServer-Side Template Injection(SSTI)からのRCEにつきましてはこちらに詳しく記載されていますので割愛しますが、SSTIの脆弱性があるパラメータについてあるパラメータについて{{[].__class__.__base__.__subclasses__()[<index of subprocess.Popen>] ('<command>', shell=True, stdout=-1).communicate()[0]}}とすることで任意のコマンドを実行させることができます。

以下のようにローカルのテスト環境に対して任意のコマンドを実行できることを確認しました。

S3バックドアの作成

次にS3のバックドアは以下の図のようなイメージになります(アイコンは公式から)。

攻撃者が実行したいコマンドをS3(攻撃者所有)にアップし、そのコマンドが被害端末で確認・実行され、その実行結果がS3にアップされ、攻撃者がそれを確認する、というものになります。 https://github.com/sparcflow/HackLikeAGhost/tree/master/S3Backdoor に適宜修正を加え、ローカルのテスト環境でSSTIを利用してS3のバックドアを作成しコマンドを実行できることを確認しました。

SSTIからのRCEについては自作のスクリプトを使用しました。

VPCエンドポイントを介したS3バックドアの作成

次にAWS上でVPCエンドポイントを介して同様のことを行います。 VPCエンドポイントによりインターネットを経由せずにAWSサービスにアクセスできるため外部への通信を制限しつつS3にアクセスできるようになります。 本記事ではセキュアにするため外向きの通信が制限されつつVPCエンドポイントによりS3へのアクセスは許可されている、という環境を想定しています。

公式のドキュメントにも記載がある通り、デフォルトではVPCエンドポイントのポリシーはFull accessとなっています。

そのため、デフォルトのポリシーを使用する場合、VPCエンドポイントの向き先がAWSサービスであるかどうかは考慮されますがそれがどのアカウントのものかは考慮していない、という状況になります。
大抵の場合問題とはなりませんが他の脆弱性と組み合わせることで、外部への通信を制限しているつもりであるにもかかわらず、攻撃者が所有しているS3から攻撃用のツールをダウンロードされるなどして悪用される可能性があります。

デフォルトのポリシーの場合、以下のようにSSTIからVPCエンドポイントを介したS3バックドアを作成し、コマンドを実行できることを確認できます。

次にVPCエンドポイントのポリシーを特定のアカウントに制限します。

ポリシーで指定していないアカウント所有のS3からのファイルダウンロードが失敗しバックドアの作成ができなくなります。

おわりに

本記事のように実際の攻撃は情報を集め、脆弱性を組み合わせ、より深く探索する、ということが行われるため、セキュリティについてはリストで考えるのではなくグラフで考えるということが必要になります。
攻撃者のようにグラフで考え、実践的な防御をする、ということについては「How to Hack Like a Ghost」の著者Sparc Flow氏の新作「Blitzscaling security」に詳細に記載されていますので興味がありましたらご一読ください。

お問合せはお気軽に

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら

PHOTO：UnsplashのAlexander Wende