OpenAM Security Advisory

IAMに脆弱性があるとやばくない？

脆弱性がないソフトウェアってないんですけどねぇ。それでも極力、IAMに脆弱性は見つかってほしくないものです。仮に見つかったとしても、すぐにシューティングしたいです。

そのあたりの不安をフォローするために、OpenAMでは定期的に脆弱性情報を公表しています。なので、インターネットに公開しているようなOpenAMはここで公開される脆弱性にいち早く対応する必要があったりします。

• https://backstage.forgerock.com/knowledge/kb

OpenAM Security Advisory #201604

どのようなレベルの脆弱性がでているのかを、2016年4月に公開された脆弱性情報をもとに見ていきましょう。

このとき発見された複数の脆弱性は非常に多くのバージョンに影響するものだったようです。SeverityがMedium以上のものが6つ公開されました。

• Issue #201604-01: User Impersonation via OAuth2 access tokens
• Issue #201604-02: Open Redirect
• Issue #201604-03: Cross Site Scripting
• Issue #201604-04: Insufficient Authorization
• Issue #201604-05: Information Leakage via Account Lockout
• Issue #201604-06: Information Leakage

なんだか、タイトルからヤバさが伝わってくるものもありますね。Criticalのものだけ見てみましょうか。

User Impersonation via OAuth2 access tokens

SeverityがCriticalと定義されています。

A specific type of request to the /openam/oauth2/access_token endpoint can result in obtaining OAuth2 access token on behalf of any user in the current realm.

任意のユーザーに代わって、access tokenを取得できる脆弱性とのことです。結構、やばいやつですね。ただ、ワークアラウンドに証明書の検証を実行するであるとか、期限切れ証明書がキーストアに含まれていないようにするとあります。よくわからない場合は、当該エンドポイントをアクセスできなくすると挙げられています。

OAuthのエンドポイントの話なのに、SAMLというキーワードが出ているので、Assertionを使ってaccess tokenを取得するgrant typeに脆弱性があったって感じなんですかね～？

Exploitみたいなものは公表されていませんね。あと、この脆弱性に紐づけられたIssue番号は8596とありますが、Issue管理されているサイト上ではサインインが必要なようになっています。

• https://bugster.forgerock.org/jira/browse/OPENAM-8596

Open Redirect

これもSeverityがCriticalとなっています。

OpenAMには当該脆弱性に似たものが、昔から多く発見されているみたいです。先日の記事でValidation Serviceについて、軽く触れましたが、Validationかけることができないエンドポイントが未だありましたテヘペロみたいなお話です。

The following endpoint does not correctly validate redirect URLs allowing an attacker to redirect an end-user to a site they control:

このエンドポイントというのは、OpenAM上のプロフィール情報画面にあたりますが、ワークアラウンドには、当該エンドポイントをブロックしろとあります。ひどい(´；ω；｀)ｳｯ…

どうやってこれらのアナウンスに対応していくのか？

結論から言うと、パッチをあてるなどの対処方法は無いので、自分でがんばる！となります。
OpenAMはOSSという定義ではありますが、サブスクリプションが必要なバージョンも存在しているため、パッチ提供はこれらのバージョンが優先されます。

逆に言うと、OpenAMの開発元にお金払ったら脆弱性の対応もしっかりできるってことです。

「IAM製品って高いんですよねー。だからOSSのOpenAMにしたのにー。」って思う方もいらっしゃると思います。けど、OSS使う以上はこういった対応とも上手く付き合っていくもんなんだと、私は割り切っています。嫌ならお金を払いましょう。価値には正当な対価が必要ですよね。

インプット

まぁ、現状はさておき、対応方法のお話です。まず、インプットですが、

1. security advisory
2. issue noでgoogle検索
3. ソースのリポジトリ

となります。これらのインプットからワークアラウンドを編み出せるものは編み出す、または、security advisoryに記載のワークアラウンドを実行することとなります。

ソースのリポジトリを横線で引いていますが、対応の一番確実な方法として、ソースからビルドして、脆弱性が修正されたOpenAMをデプロイするという対応方法が挙げられます。しかし、2016年11月下旬ごろより、OpenAMのTrunkは非公開となりました。（このあたりの話は最終日にとりあげます。）なので、ソースからビルドして、脆弱性が修正されたOpenAMをデプロイするという対応方法もできません。

ワークアラウンド

security advisoryに記載のワークアラウンドは大きく3つの対応方法が挙げられます。

1. 〇〇っていう設定を変える
2. △△っていうエンドポイントやリクエストをブロックする
3. パッチを適用する

1.であれば、そのとおり実施しましょう。ただ、2.については、運用している環境には適用しづらいものがあったりします。
そういう場合、わたしのとこでは、Apacheの設定で何とかする方針でいこうとしています(´◉◞౪◟◉)。例えば、特定のN/Wからのアクセスがある程度想定されているのであれば、mod_rewriteで対応する。特定のExploit Requestをブロックしたいのであれば、mod_securityで対応する。といった感じです。

• mod_rewrite
  • リダイレクトやURLの書き換えを行う
  • Conditionの定義ができるので、特定のリクエストにルールを適用できる
  • URLを操作するためのスイス製のアーミーナイフ
• mod_security
  • ApacheにバンドルできるWAF
  • 学習コストがそれなりにあるので、お金があるなら製品で対応してもいいかも

そして、OSS版で公開されたバージョンが出た段階で、バージョンアップするという運用です。これで結構何とかなるでしょう。（なんとかなれ～）

〆

本日のまとめです。

• OpenAMにも脆弱性はある（仕方ないね）
• 脆弱性は大きくアナウンスされる、結構な頻度でアナウンスされる
• ワークアラウンドも提示されるが、パッチの提供はないので、自分たちで何とかする

こうやって挙げると、なんだか使いたくなくなったりすると思いますが、そこはOSSなので仕方ないでしょう。

明日は最終日ですね～。総括的なまとめをすると思いますので、ポエムになります。

ばい！