Microsoft Exchangeの拷問の庭：彼らがEOLできないものを受け入れる平静さを与えてください

コラム　触れるものすべてを腐敗させる怪物。エネルギーを吸い取り、自らがもたらす苦痛を糧に生きる吸血鬼。殺すことはできず、現れるたびに恐ろしさと恐怖が増し、新たな成長を遂げる。Microsoft Exchangeと、そのよだれを垂らす手先、Outlookだ。

まずは、最も多くの犠牲者であるエンドユーザーから始めましょう。おそらくあなたもその一人でしょう。長年の暴露で麻痺し、長年の腐食で痛覚受容体や批判的思考力が消耗しているかもしれません。私のように、仕事の要求によって定期的に触手が穴から再び侵入してくる、常習的な回避者になっているかもしれません。

最近、Web インターフェース経由でこれを使い始めましたが、未読フラグが更新されず、添付ファイルが非表示になり、ブラウザー インスタンスが増殖し、ダウンロード ディレクトリ全体に一時ファイルが残り、スレッドが絡まり、検索が失敗するなどの問題が発生します。

モンスターと戦うことで自分がモンスターになってしまうのなら、モンスターをマーケティングするとどうなるのでしょうか?

あるいは、あなたは哀れな年季奉公奴隷、Exchange Admin Tribe の一員かもしれません。仕事中はうるさくて気難しい主人だと言うのは一つのことですが、歯車が吐き出された後にその破片を拾い集めるのは全く別の話です。バロック風のメッセージのカタコンベを巻き戻して再構築するという舞踏は、気分を爽快にし、もっと何かしたいという気持ちにさせてくれるような作業ではありません。

そして、Exchangeの名目上の所有者であり管理者であるMicrosoft自身も、その創造によって損害を被っている。モンスターと戦うことで自分がモンスターになるのなら、彼らをマーケティングすることに何の意味があるというのだろうか？

2021年3月1日の週の時点で、あなたは無防備で愚かな立場に置かれています。最新のセキュリティ上の残虐行為を阻止するためのパッチを適用し、パッチ（彼らが主張するものは何でも）が正しく適用されたことを確認するために必要なスクリプトを実行するのに苦労しているにもかかわらず、世界はあなたを疑わしい目で見ています。Exchange管理では間違いが起きやすいものです。パッチ適用後には安心感ではなく、侵害の証拠の追跡が始まります。

このセキュリティホールは甚大です。パッチが急いで公開される前は、防御策がありませんでした。これは、認証前のリモートコード実行を許すゼロデイ脆弱性であり、今もなお存在しています。攻撃者はただ現れ、Webシェルを仕掛け、データを盗み出すだけです。あるExchange管理者が皮肉を込めて言ったように、「まだ一晩も眠れていないなら、明日から二晩も眠れなくなるだろう」のです。（もしあなたがこの段落で取り上げられている問題のいずれかに悩まされているなら、このRedditのスレッドは自己解決の拠点となるでしょう。）

これを「悪い」から「非常に悪い」、そして「非常に悪い」へと格上げしたのは、これがマイクロソフトの歴史上、認証前のリモートコード実行の脆弱性としては初めてではないということです。過去数年間だけでも、BlueKeepとSMBGhostの両方が、パッチ適用前の防御策なしにWindowsシステムを無防備な状態にしていました。BlueKeepの場合、この脆弱性はXPとWindows 2000の時代から存在していました。定期的なコードレビューとアクティブで進化するテスト手順という体制を乗り越えるには長い時間がかかりました。

もしかしたら、ささやきながら言うが、そのような体制はマイクロソフトの得意分野ではないのかもしれない。もちろん、同社には無限の資源があるわけではない。賢明な経営のためには、モバイル戦略の失敗や高額な買収の償却に備えて、常に数十億ドルの小口現金を残しておく必要がある。しかし、一度、顔を赤らめるほどの、まさに「A級」とも言える脆弱性を初めて発見したなら、もっと探してみる価値はあるだろう。

コードベース内で、認証前にパケットが処理される箇所をすべてチェックするチームを編成するのは、それほど費用がかかりません。確かにそのような箇所はたくさんありますが、20年以上もコードを放置しているのであれば、何度も確認する時間があります。ツールや技術は常に進化しており、脅威環境も変化しています。自社ブランドのレガシーコードを放置し、安全性を維持するための努力を怠るなら、その結果を受け入れるしかありません。

皮肉なことに、もしマイクロソフトがうまくやれば、その成果を様々な形で活用するチャンスがあったはずだ。例えば、ハッカーよりも先にテストプロトコルと認証前の脆弱性を洗い出すツールを開発し、それをオープンソース化していたとしよう。そうすれば、コミュニティ志向のセキュリティ大国として時代を先取りしているという称賛を得られるだけでなく、競合他社がこうした新しいツールを備えた世界に直面して自社のコードベースをロックダウンしようと躍起になっている間に、マイクロソフトははるかに安全なコードベースを構築できたはずだ。

しかし、Exchangeの毒腺に最後の毒が注入される。使いにくく、管理が面倒な製品は、コードベースのメンテナンスが悪夢のようになる。優れた設計は、製品のライフサイクル全体、つまり信頼性、適応性、そしてユーザーエクスペリエンスにおいて輝きを放つ。そして、その逆もまた然りだ。

ExchangeとOutlookのソースがどのようなものなのかは分かりません。もしかしたら、エンジニアリングの驚異であり、作業の喜びであり、設計者の技の典型なのかもしれません。しかし、もしそうだとしたら、その事実を隠すために何かがひどく間違っているのでしょう。悪夢のようなモンスターのようなコードベースは、テストと修正にとって悪夢のようなモンスターです。証拠として、私たちが今まさに直面しているのはまさにそれです。

MicrosoftはExchangeのサポート終了を宣言することはできない。2019年にWindows XP向けにBlueKeepパッチをリリースせざるを得なかったのと同じだ。オンプレミスのExchangeサーバーをすべて魔法のようにクラウドに移行させることもできない。このモンスターは独自の生命を持っている。Microsoftにできることは、テストシステムを進化させ、レガシーの悪影響を可​​能な限り積極的に発見し修正することで、このモンスターを可能な限り飼いならすプログラムにコミットし、それを実証することだけだ。

それが実現しない限り、特権のために金を払わなければならない私たちのような愚かな客に、これほどの苦痛を押し付けたことで、当然の非難を浴びることになるだろう。よし。®