理研のLMSへの不正アクセスの原因はなんだったのか？

# はじめに
2021年11月に理化学研究所から[学習管理システムへの不正アクセスについてのお知らせ](https://www.riken.jp/pr/news/2021/20211105_1/index.html)が公開されました。
「既知の脆弱性が突かれた」、「改善を要求していた（が未対応だった）」など、お約束の文言が並んでいますが、攻撃の詳細は明らかにされていません。

[セキュリティ系ニュースサイトの取材](https://www.security-next.com/131349/2)に対しても、
> 問題の脆弱性についても、一般向けシステムで同様の脆弱性を持つサイトが存在し、二次被害の可能性があるとして、具体的な内容についてはコメントを避けた。

とあり、詳細は不明です。
そもそも攻撃者側と攻撃される側で情報の非対称性があることが問題であり、むしろ積極的に脆弱性に関する情報を公開することでセキュリティ対策になると考えます。そこで、本件で利用された脆弱性について推測してみることにします。

# 学習管理システム(LMS)
まず「学習管理システム」が何なのか不明の状態だと話にならないので、ここから確認することにします。すると「[理研の情報セキュリティ](https://i.riken.jp/elearning/)」というeラーニングサイトが見つかりました。

現時点では組織の外部ネットワークからはアクセスできないよう制限されているようですが、Internet Archiveで確認すると、以前は外部ネットワークからもアクセスできたようです。また、マニュアルを見るとMoodleを利用しているようです。
とりあえず「セルフサインアップは不可」、「Shibboleth認証に対応」のようです。

前述のニュースサイトにも
> 同研究所によれば、不正アクセスを受けた学習管理システムは、一般的なソフトウェアを用いて構築されたもの

とあるので、LMSはMoodleだったのだと推測します。

# 攻撃の詳細
9月24日に不正アクセスが発覚と記載されているので、それ以前に知られていた脆弱性を確認します。実はMoodleのサイト管理者として登録していると、Moodle公式から重大な脆弱性の情報がメール通知される無償のサービスがあります。7月12日に送られたメールで「SQLインジェクション」、「リモート実行」が、9月13日には「セッションハイジャック」、「認証回避」といった脆弱性が報告されています。この情報は1週間ほど遅れてMoodleの[Security announcementsフォーラム](https://moodle.org/mod/forum/view.php?id=7128)で公表されます。

ファイル改ざんと何らかの命令の実行が行われたというところから、任意コード実行の脆弱性を突かれたと疑ってみます。

# 任意コード実行の脆弱性 (CVE-2021-36394)
[問題となる任意コード実行の脆弱性](https://moodle.org/mod/forum/discuss.php?d=424799)は「Shibboleth認証を有効にし、セッションハンドラにFileを利用している場合、ログアウト処理時に問題があり任意コード実行が可能」というものです。
[修正部分](https://git.moodle.org/gw?p=moodle.git;a=commitdiff;h=5bc561ee7ad31b769815821280f8a3f5bd69c31b)を確認すると、信頼できないデータのunserialize()が原因のようです。実はこの脆弱性の公開時に、深刻度合いを確認するためにコードを見ていたのですが、「なんとかして$_SESSIONに不正なオブジェクトを挿入する必要がある」ため、悪用は難しいと思っていました。

[この脆弱性の報告者のブログ](https://haxolot.com/posts/2021/moodle_pre_auth_shibboleth_rce_part1/)に脆弱性の解説がありますが、パッチを見ればわかる程度の内容であり、攻撃を成立させるために必要な「なんとかして$_SESSIONに不正なオブジェクトを挿入」させる方法について記述がありません。
[別のブログ](https://0xd0ff9.wordpress.com/2021/08/28/cve-2021-36394-hack-truong-sua-diem-cac-kieu/)を見ると、「評定表」ツールを使って問題を解決しているようです。
ブログ記事では省略されていますが、$_SESSIONに値を入れる前に ``require_login($course);`` を通る必要があります。ただ、``require_capability();``より前なので、コース参加者の権限を持つユーザであれば悪用は可能のようです。

しかし、「セルフサインアップは不可」の設定なため、攻撃者がアカウントを取得して攻撃というのは無理そうです。「すでにアカウントを持っている利用者による悪用」としてここで終わってもよいのですが、続きを考えてみます。

# セッションハイジャックの脆弱性 (CVE-2021-40691)
ほかに「認証回避の脆弱性(CVE-2021-40693)」もありますが、「外部DBを利用してること」という条件があり、「セッションハイジャックの脆弱性」に注目します。
これは「Shibboleth認証を有効にし、セッションハンドラにDBを利用している場合、未認証のユーザがログアウトURLにアクセスすると、ランダムでログインユーザのセッションを乗っ取ることが可能になる」というものです。
この脆弱性も先の任意コード実行の脆弱性と同じ報告者で、[ブログ記事](https://haxolot.com/posts/2022/moodle_pre_auth_shibboleth_rce_part2/)によると、この脆弱性を利用することで、未認証のユーザが（運がよければ）管理者権限を手に入れることが可能とされています。管理者権限があれば、セッションハンドラをDBからFileに変更し、任意コード実行の脆弱性につなげることができるという訳です。そもそも、管理者権限が手に入ればサイト設定で防いでいなければ、不正なプラグインを導入することも可能ですし、サイト内のあらゆる情報を閲覧することが可能です。
理研のお知らせがはっきりしない書き方だったのも管理者権限を奪取されていたからかもしれません。

# まとめ
2021年の7月から9月にかけて報告されたMoodleのShibbolethまわりの脆弱性を利用されたとみて間違いないと思います。ただし記載した2つの脆弱性のどちらか片方だけ利用された可能性もあります。
セッションハイジャックの脆弱性は、公知になってから被害発覚まで10日程度しか経過しておらず、この脆弱性が利用されていたとすれば、Moodleサイト管理者はアップデート公開後、脆弱性が自システムへ及ぼすの影響の評価およびパッチ適用を速やかに行う必要があるという事実の裏付けとなるでしょう。

なお、この脆弱性はShibboleth IdPに起因するものではなく、Moodleの処理に問題があるのがすべての原因のため、実際にShibboleth認証を利用していなくても（Shibboleth SPを設定していなくても）、Shibboleth認証プラグインを有効にしているだけで利用されるものです。