Codeers Conquer Security Infrastructure as Codeシリーズ。ミッシングファンクションレベルのアクセスコントロール
このブログでは、開発者が組織内にセキュアなインフラを導入する際に、まったく新しいレベルのセキュリティ意識を身につけることができます。
ところで、前回のブログで紹介した「セキュリティの設定ミス」はどうだったでしょうか？もし、今すぐにでも、機能レベルのアクセスコントロールの脆弱性の行方に取り組みたいという方は、プラットフォームにお越しください。
(上のリンクから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のゲーム化されたセキュリティチャレンジに挑戦し、あらゆるサイバーセキュリティのスキルを磨いて最新の状態に保つことができます。
次の章をお楽しみに
インフラレベルのアクセスコントロールが完璧に行われていないと、企業全体が攻撃者に開放され、その脆弱性をゲートウェイとして、不正なスヌーピングや完全な攻撃を受けることになります。
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
このブログでは、開発者が組織内にセキュアなインフラを導入する際に、まったく新しいレベルのセキュリティ意識を身につけることができます。
ところで、前回のブログで紹介した「セキュリティの設定ミス」はどうだったでしょうか？もし、今すぐにでも、機能レベルのアクセスコントロールの脆弱性の行方に取り組みたいという方は、プラットフォームにお越しください。
(上のリンクから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のゲーム化されたセキュリティチャレンジに挑戦し、あらゆるサイバーセキュリティのスキルを磨いて最新の状態に保つことができます。
次の章をお楽しみに
このブログでは、開発者が組織内にセキュアなインフラを導入する際に、まったく新しいレベルのセキュリティ意識を身につけることができます。
ところで、前回のブログで紹介した「セキュリティの設定ミス」はどうだったでしょうか？もし、今すぐにでも、機能レベルのアクセスコントロールの脆弱性の行方に取り組みたいという方は、プラットフォームにお越しください。
(上のリンクから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のゲーム化されたセキュリティチャレンジに挑戦し、あらゆるサイバーセキュリティのスキルを磨いて最新の状態に保つことができます。
次の章をお楽しみに
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者・開発者です。フォーティファイ・ソフトウェア社や自身の会社（Sensei Security）などでソリューションを開発してきました。キャリアの中で、Matiasは、商用製品につながる複数のアプリケーションセキュリティ研究プロジェクトを主導し、10件以上の特許を取得しています。また、RSAカンファレンス、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどの世界的なカンファレンスで定期的に講演を行っているほか、高度なアプリケーションセキュリティトレーニング（courses ）の講師も務めています。
Matiasはゲント大学でコンピュータ工学の博士号を取得し、アプリケーションの内部構造を隠すためのプログラム難読化によるアプリケーションセキュリティを研究しました。
このブログでは、開発者が組織内にセキュアなインフラを導入する際に、まったく新しいレベルのセキュリティ意識を身につけることができます。
ところで、前回のブログで紹介した「セキュリティの設定ミス」はどうだったでしょうか？もし、今すぐにでも、機能レベルのアクセスコントロールの脆弱性の行方に取り組みたいという方は、プラットフォームにお越しください。
(上のリンクから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のゲーム化されたセキュリティチャレンジに挑戦し、あらゆるサイバーセキュリティのスキルを磨いて最新の状態に保つことができます。
次の章をお楽しみに
目次
Matias Madou, Ph.D. セキュリティ専門家、研究者、CTO兼共同設立者（Secure Code Warrior ）。Ghent大学でアプリケーションセキュリティの博士号を取得し、静的解析ソリューションに焦点を当てた。その後、米国Fortify社に入社し、開発者が安全なコードを書くことを支援せずに、コードの問題を検出するだけでは不十分であることに気づきました。開発者を支援し、セキュリティの負担を軽減し、お客様の期待を上回る製品を開発することを志すようになった。Team Awesomeの一員としてデスクワークをしていないときは、RSA Conference、BlackHat、DefConなどのカンファレンスでプレゼンテーションをするのが好きである。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約するダウンロード始めるためのリソース
セキュア・バイ・デザインベストプラクティスの定義、開発者の能力向上、予防的セキュリティ成果のベンチマーク
このリサーチペーパーでは、Secure Code Warrior 共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士、そして専門家であるクリス・イングリス（Chris Inglis）氏（元米国サイバーディレクター、現パラディン・キャピタル・グループ戦略顧問）、デヴィン・リンチ（Devin Lynch）氏（パラディン・グローバル・インスティテュート・シニアディレクター）が、CISO、アプリケーション・セキュリティ担当副社長、ソフトウェア・セキュリティの専門家など、企業のセキュリティ・リーダー20人以上への詳細なインタビューから得られた主な知見を明らかにします。
セキュリティ スキルのベンチマーク: 企業におけるセキュアな設計の合理化
セキュアバイデザイン（SBD）構想の成功に関する有意義なデータを見つけることは、非常に困難である。CISO は、セキュリティプログラム活動の投資収益率（ROI）とビジネス価値を、従業員レベルと企業レベルの両方で証明しようとすると、しばしば困難に直面します。言うまでもなく、企業にとって、現在の業界標準に対して自社の組織がどのようにベンチマークされているかを把握することは特に困難です。大統領の国家サイバーセキュリティ戦略は、関係者に「デザインによるセキュリティとレジリエンスを受け入れる」ことを求めている。セキュアバイデザインの取り組みを成功させる鍵は、開発者にセキュアなコードを保証するスキルを与えるだけでなく、規制当局にそれらのスキルが整っていることを保証することである。本プレゼンテーションでは、25万人以上の開発者から収集した社内データ、データに基づく顧客の洞察、公的研究など、複数の一次ソースから得られた無数の定性的・定量的データを紹介します。こうしたデータ・ポイントの集積を活用することで、複数の業種におけるセキュア・バイ・デザイン・イニシアチブの現状をお伝えすることを目的としています。本レポートでは、この領域が現在十分に活用されていない理由、スキルアッププログラムの成功がサイバーセキュリティのリスク軽減に与える大きな影響、コードベースから脆弱性のカテゴリーを排除できる可能性について詳述しています。
始めるためのリソース
明らかになった：サイバー業界はセキュア・バイ・デザインをどのように定義しているか
最新のホワイトペーパーでは、当社の共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士が、CISO、AppSecリーダー、セキュリティ専門家を含む20人以上の企業セキュリティリーダーと対談し、このパズルの重要なピースを見つけ出し、Secure by Design運動の背後にある現実を明らかにしました。セキュア・バイ・デザインは、セキュリティ・チーム全体で共有された野心ですが、共有されたプレイブックはありません。
