SSTエンジニアブログ

SSTのエンジニアによるWebセキュリティの技術を中心としたエンジニアブログです。

SST式サーバレスハニーポット始動!

はじめに

こんにちは、宇田川です。
SSTは1月に期が変わり、私は今期から研究開発部に注力することになりました。
より『クラウド×セキュリティ』の内容にフォーカスし、SST独自の情報を発信していきます。

その第1弾として、弊社で運用を開始したサーバレスハニーポットについてご紹介します。

構成

構成はこちら。
f:id:woodykedner:20190314114318p:plain

関連要素で色分けしています。
青・・・ ハニーポットWeb
橙・・・ AWS WAFログ保存分析
黄・・・ ハニーポットログ保存分析
赤・・・分析基盤(QuickSight)
緑・・・terraform管理範囲

特徴① 低対話型ハニーポット

ハニーポットは、特定の攻撃が来たらマッチするレスポンスを返す低対話型になってます。 何の攻撃に当てはまらなくても、レスポンスコード200でtestみたいな何らかの文字列は返すようにしています。

現在、OWASPのcheat sheetや他のハニーポットやCTFの問題、実際に発生した脆弱性のPoC等を参考にし、攻撃に対するレスポンスパターンは増やしています。
これだけでもかなり勉強になりますね。

特徴② サーバレス

ハニーポットはLamba上にpythonで構築されています。構成の通り、EC2やdockerも無いため、OSやミドルウェア、キャパシティ、スケール等々の管理保守から解放されました。 通信量は通信料がかかるので監視は入れていますが、さほど負担になっていません。
ハニーポットのレスポンスパターンの追加と攻撃リクエストの分析に集中できています。

特徴③ infrastructure as code

構成はterraformによりテンプレート化し、管理しています。QuickSightのダッシュボードの作成はterraformが対応していないので手作業ですが、その他の部分は、環境の構築もコマンド一発で、何かあればコマンド一発で環境を削除することができます。

ちなみにCloudFormationも触っていますが構築も削除も遅いんですよね… なので、私はterraformを重宝して使っています。

www.terraform.io

特徴④ AWS WAF試験場

CloudFrontとALBがあるので、それぞれにAWS WAFのwebACLをアタッチし、マネージドルールを1つずつ設定しています。 AWS WAFはアクションをBLOCKとするとリクエストボディが取れないため、「Override to count」で設定しています。
ハニーポットまで来るとリクエストボディが取れるため、kinesis firehose経由でS3に保存しています。 ALBから Lambdaに送られるリクエストの内容は下記の通りになります。保存するときはAthenaで分析するため改行を無くして、1リクエスト1行としています。

{
    "requestContext": {
        "elb": {
            "targetGroupArn": "arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/lambda-279XGJDqGZ5rsrHC2Fjr/49e9d65c45c6791a"
        }
    },
    "httpMethod": "GET",
    "path": "/lambda",
    "queryStringParameters": {
        "query": "1234ABCD"
    },
    "headers": {
        "accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8",
        "accept-encoding": "gzip",
        "accept-language": "en-US,en;q=0.9",
        "connection": "keep-alive",
        "host": "lambda-alb-123578498.us-east-2.elb.amazonaws.com",
        "upgrade-insecure-requests": "1",
        "user-agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36",
        "x-amzn-trace-id": "Root=1-5c536348-3d683b8b04734faae651f476",
        "x-forwarded-for": "72.12.164.125",
        "x-forwarded-port": "80",
        "x-forwarded-proto": "http",
        "x-imforwards": "20"
    },
    "body": "",
    "isBase64Encoded": false
}

Using AWS Lambda with an Application Load Balancer - AWS Lambda

実際に取得した攻撃リクエストとAWS WAFの各ルールの検知精度は、レスポンスパターンの追加とWAFサービスに活かします。

ハニーポットの中身を一部紹介

パストラバーサルによるcredentialsファイルの参照

パストラバーサルでは、「/etc/passwd」でサーバ内部のユーザ情報の取得を試みることが一般的ではあります。 しかし、AWS環境だと「~/.aws/credentails」にAWSへの認証情報を置くことがあり、こちらを狙われることがあるのではないかと思い、設定してみました。 URL、header、Bodyに「.aws/credentails」が入っていると上記のレスポンスが返るようにしてあります。

f:id:woodykedner:20190304114537p:plain

表示されているAccessKeyIdとSecretAccessKeyは適当に数字とアルファベットにして並べたものなので、credentialsとしては使用できません。
なのですがAccessKeyIdとSecretAccessKeyをそのまま表示するのは自分的に気持ち悪かったので隠させてもらいました。

SSRFによるIAMロールの取得

SSRFについては、徳丸さんのブログ記事を読んでいただくのが分かりやすいと思います。

blog.tokumaru.org

紹介されている中で、「SSRF攻撃の例1」を参考に実装してみました。

まず、パラメータに「url=http://169.254.169.254/latest/meta-data/iam/security-credentials/」で
IAMロール名(admin-role)を取得します。

f:id:woodykedner:20190304114554p:plain

で次に「url=http://169.254.169.254/latest/meta-data/iam/security-credentials/admin-role」で
IAMロールの内容を参照

f:id:woodykedner:20190304114607p:plain

こちらのAccessKeyIdとSecretAccessKeyも適当なものですが、隠させてもらいます。

じゃ、どんな攻撃が来ているか?

気になるところですが、運用を開始したばかりのため、ブログで取り上げるような情報は取れてないです…
ということで、面白い攻撃リクエストが来ましたら、取り上げていきたいと思いますので、ご期待ください。

ではでは。