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、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約するダウンロード始めるためのリソース
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
OpenText アプリケーションセキュリティのパワー + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
セキュアコード・トレーニングのトピックと内容
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
始めるためのリソース
.png)
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.