このブログでは、開発者が組織内にセキュアなインフラを導入する際に、まったく新しいレベルのセキュリティ意識を身につけることができます。

ところで、前回のブログで紹介した「セキュリティの設定ミス」はどうだったでしょうか？もし、今すぐにでも、機能レベルのアクセスコントロールの脆弱性の行方に取り組みたいという方は、プラットフォームにお越しください。

(上のリンクからKubernetesのチャレンジにアクセスできますが、プラットフォームにアクセスしたら、ドロップダウンを使ってAnsible、CloudFormation、Terraform、Dockerからも選択できます。お好みでどうぞ)

現在配備されているほとんどのアプリケーションは、何らかのアクセス制御メカニズムを持っており、要求された機能を実行する権限がユーザーにあるかどうかをチェックしています。これは、アプリケーションを作成する際に、機能性と同様に、優れたセキュリティの基礎となるものです。実際、すべてのWebアプリケーションには、異なる権限を持つユーザーがプログラムを使用できるようにするためのアクセス制御が必要です。

しかし、アクセスコントロールのための同じ検証機能が、インフラレベルで行われていなかったり、誤って設定されていたりすると、問題が発生します。インフラレベルのアクセスコントロールが完璧に行われていないと、企業全体がハッカーに開放されてしまい、ハッカーはその脆弱性をゲートウェイとして、不正なスヌーピングや完全な攻撃を行うことができます。

実は、機能の欠落や設定ミスによるアクセス制御の脆弱性を利用することは非常に簡単です。攻撃者は、過度な技術を必要としません。アプリケーションをサポートしているフレームワークの中で、どのようなコマンドが機能を実行するかを知っていればよいのです。もし知っていれば、あとは試行錯誤するだけです。攻撃者は、許可されていないはずのリクエストを継続的に送信することができ、1つでも成功すれば、対象となるWebサイト、アプリケーション、サーバー、さらにはネットワーク全体が公開されることになります。

Missing Function Level Access Control Exploitsの仕組みとは？

機能レベルのアクセス制御が組織に入り込んでしまう方法はいくつかあります。例えば、機能レベルのアクセスをアプリケーションに任せて、基盤となるインフラで検証しないことがあります。また、インフラストラクチャレベルのアクセス制御が誤って設定されることもあります。管理者は、上位のユーザだけが見ることができるはずのインフラストラクチャリソースへのアクセス方法を、権限のないユーザは知らないだろうと想定し、「Security by Obscurity」モデルを使用する場合がありますが、これはほとんど機能しません。

Security by Obscurityの例としては、以下のURLが攻撃を受けやすいと考えられます。

http://companywebsite.com/app/NormalUserHomepage

認証されたユーザーがForced URL Browsingと呼ばれる技術を使用すると、管理者にしか表示されないページに到達しようとする可能性があります。例えば、以下のような例が考えられます。

http://companywebsite.com/app/AdminPages

サーバー側の検証がない場合、攻撃者は単に管理ページを表示し（その名前がリクエストと一致する場合）、新しいページから管理者が行うあらゆる追加機能にアクセスできるようになります。サーバが攻撃者に「ページが見つかりません」というエラーを返した場合、攻撃者は管理ページの名前が何であれ、それが分かるまで単に試し続けることができます。

攻撃者にとって、不足している機能レベルのアクセス制御を悪用することも同様のプロセスです。不正なページを閲覧しようとするのではなく、機能リクエストを送信します。例えば、管理者権限を持つ新しいユーザーを作成しようとする場合です。その場合のリクエストは、フレームワークにもよりますが、以下のようなものになります。

POST/action/createuser name=hacker&pw=password&role=admin

機能レベルのアクセス制御が存在しない場合は、上記の例が成功し、新しい管理者アカウントが作成されます。攻撃者が新しい管理者として再ログインすると、そのネットワークやサーバの他の管理者と同じアクセス権と権限を持つことになります。

機能レベルのアクセスコントロールができない場合の対処法

機能レベルのアクセス制御の脆弱性を悪用することは、攻撃者にとって非常に容易であるため、これらの脆弱性を発見し、修正し、防止することが非常に重要です。ありがたいことに、いくつかのノウハウと基本的なInfrastructure asCodeのセキュリティトレーニングがあれば、これはそれほど難しいことではありません。

主な保護策は、インフラレベルでのロールベースの認証を実装することです。この機能をアプリケーションに任せてはいけません。仮にアプリケーションが処理したとしても、インフラ側で認証を行うことで、見落としがないようにすることができます。理想的には、認証は集中管理された場所（例えば、AWS IAM、Azure IAMなど）から行われ、組織のルーチンに組み込まれ、すべての新しいアプリケーションに適用されるべきです。これらの認証プロセスは、フレームワーク自体から来ることもあれば、使いやすい外部モジュールから来ることもあります。

最後に、組織は最小特権の概念を受け入れるべきです。すべての行動や機能はデフォルトでは拒否され、認証プロセスによって有効なユーザに必要な権限が与えられるべきです。必要な機能を実行するのに十分な権限を、必要な期間だけ与えるべきです。

機能レベルのアクセス制御ができなくなると、壊滅的なダメージを受けます。しかし、幸いなことに、インフラレベルの適切な認証方法を組織に組み込むことで、この問題を簡単に防ぐことができます。

アクセス制御のバグを発見する準備ができたと思いますか？これらのDockerのコードスニペットを比較してみてください。

ヴァルネラブル。

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER root
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

確保。

FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
   tar -xvf $FILENAME.tar.gz && \
   mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER nobody
EXPOSE 9104
ENTRYPOINT  [ "sh", "~/entrypoint.sh" ]
CMD  [ "/bin/mysqld_exporter" ]

より多くのことを学び、自分自身に挑戦する

をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥や脆弱性の被害から組織やお客様を守るための方法を紹介しています。

また、先ほど見逃してしまった方は、Secure Code Warrior プラットフォーム上で、IaCのゲーム化されたセキュリティチャレンジに挑戦し、あらゆるサイバーセキュリティのスキルを磨いて最新の状態に保つことができます。

次の章をお楽しみに