Slackのプライベートリポジトリが年末年始に不正アクセスされる

問題自体の影響は小さいとみられるが… / 2023-01-07T00:00:00.000Z

GitHubには、ソースコードなどがあるリポジトリを全ての人がアクセスできるようにするか特定のアカウントのみアクセスできるようにするかを設定できる機能が備えられています。このうち後者のものを「プライベートリポジトリ」と呼んでおり、当然ながら許可した以外の人々によるアクセスが行われるべきものではありません。

しかしながら様々な要因によってアクセスされてしまうことがあり、そういったセキュリティ問題を起こしてしまうと信頼に傷がついてしまうことすらあります。今回は年末年始にこういった問題を起こしてしまったSlackについて、その対処があまり良い印象を持たれない形となっていたのでこのことについて日本語でも記録していこうと思います。

結論

  1. 12月27日にアクセストークンが盗まれ、29日に検知
  2. 致命的なものへのアクセスは無いとみられるが、当該トークンを無効化し他の認証情報を予防的に変更
  3. このことを知らせるブログに対して検索エンジンに検知されなくなるような設定がなされている

アクセストークン

こんな記事を開いている人々の大半は理解されていると思うのですが、アクセストークンが漏れてしまうとそれを用いて許可を出していたサービスに不正にアクセスされてしまう可能性があります。通常は1人1つずつ発行されているアカウントに対してそれぞれ発行されており、様々な(本当に様々な)理由によって悪意のある人々に漏れてしまうことがあります。

2022年12月27日に従業員のアクセストークンが侵害を受けた結果プライベートリポジトリに対するアクセスが行われたことを、Slackは同年29日にこれを検知しました。Slackはこの事象に際して初めに当該アクセストークンを無効化した上で顧客に対する調査を開始し、本番環境や顧客データなどへのアクセスが無いことを確認したということを12月31日にブログの形で公開しました。

noindex

ここまでなら通常のインシデント対応であると考えられますが、これを知らせるブログ記事)へのアクセス手段が著しく制限されていることがBleeping Computer上で指摘されています。まず初めにSlackのニュース一覧において、英語版を除いて翻訳がなされておらずSlackが対応しているとしている言語で上記のようなインシデントに対する情報、しかも現在進行している事象ではないものの情報を得られないことが問題として挙げられています。これはまだ翻訳対応をしていないとみなすことは出来ます。

しかし当該ページは検索エンジンに収集されないためのnoindexが指定されています。このようにすることによってただでさえアクセス性の悪いインシデント情報へのアクセスがさらに困難になっていると言えます。過去に他社のインシデント発生報告に同様の仕掛けがなされていたことがあり、その際にはその企業の情報開示に対する姿勢に疑問がなされていたのですが同じ轍を踏んでしまっているようです。これが故意かどうかは分かりませんが、もし故意であるのだとしたら情報開示に積極的ではないサービスと見なされ、信頼性に傷がつくのは容易に想像できると言えます。

関連リンク

最後に

サービスとしてのセキュリティ的にはあまり大きな問題であるとはいえない問題ですが、それに対する対処があまり良いとはいえないタイプの問題だなと思いました。noindexを付けてみたりしているところが、むしろマイナスになることを考えなかったのかな~~と思います。

Writer

Osumi Akari