-
タグ
タグ
- セキュリティ
- 人材開発・教育
- システム開発
- アプリ開発
- モバイルアプリ
- DX
- AI
- サイバー攻撃
- サイバー犯罪
- 標的型攻撃
- 脆弱性
- 働き方改革
- 企業市民活動
- 攻撃者グループ
- JSOC
- JSOC INSIGHT
- サイバー救急センター
- サイバー救急センターレポート
- LAC Security Insight
- セキュリティ診断レポート
- サイバー・グリッド・ジャパン
- CYBER GRID JOURNAL
- CYBER GRID VIEW
- ラックセキュリティアカデミー
- すごうで
- ランサムウェア
- ゼロトラスト
- ASM
- EDR
- SASE
- デジタルアイデンティティ
- インシデントレスポンス
- 情シス向け
- 対談
- CIS Controls
- Tech Crawling
- クラウド
- クラウドインテグレーション
- データベース
- アジャイル開発
- DevSecOps
- OWASP
- CTF
- FalconNest
- セキュリティ診断
- IoT
- EC
- サプライチェーンリスク
- スレットインテリジェンス
- テレワーク
- リモートデスクトップ
- アーキテクト
- プラス・セキュリティ人材
- 障がい者採用
- 官民学・業界連携
- カスタマーストーリー
- 白浜シンポジウム
- CODE BLUE
- 情報モラル
- クラブ活動
- 初心者向け
- 趣味
- カルチャー
- 子育て、生活
- 広報・マーケティング
- コーポレート
- ライター紹介
- IR
セキュリティは、システム開発や運用などで当たり前のことを当たり前にすることが大事です。
2015年11月9日頃からApache Commons Collections(以下、ACC)ライブラリの脆弱性が各メディア、ブログに取り上げられました。脆弱性の内容や影響についてはすでにご存じの方が多いと思います。これは、2015年1月にAppSecCali 2015: Marshalling Picklesで報告されていたのですが、FoxGlove Securityのブログが出るまでは、騒がれることもなく対応されることもなく放置されている状態でした。いわゆる、脆弱性を解消する手段がない状態(ゼロデイ)です。騒がれ始めた2015年11月の段階でもこの状態だったのです。
今回は、ACCライブラリの脆弱性を題材に、システム開発でどのようなことに備えておけばリスクの軽減につながるのか、運用時どのように準備すればいいのか、サービス継続はどういう点を考慮すればいいのか、「備える」を意識して考えてみたいと思います。
まずは、初めてこの脆弱性を知ったという方への簡単な脆弱性の説明から。
脆弱性の概要
「ACCライブラリを使用して、外部からシリアライズされたオブジェクトを受け取りデシリアライズする過程で、任意のコマンドを実行できる。(攻撃が可能である)」これが今回の問題です。
ACCライブラリは、Javaの世界ではよく使われている共通ライブラリですので影響を受ける対象ソフトウェアも広範囲になりました。アプリケーションサーバ(WebLogic、WebSphere、JBoss)、CIツール(Jenkins)、ネットワーク監視アプリ(OpenNMS)、スクリプト言語(Groovy)、フレームワーク(Spring)などが該当するソフトウェアです。
幸いなことにシリアライズされたオブジェクトを受け取る処理が、外部公開されているもの(インターネットに公開されているもの)が少なかったため、そこまでの大騒ぎにはなりませんでした。
参考情報:(その他詳細はこちらから)
攻撃による影響を低減する対策では防ぎきれなかった!?
通常、脆弱性を解消する手段がない状態のときの対処としてすぐに思いつくのは、攻撃による影響を低減する対策(WAFなど)だと思うのです。
ここで少し脱線。これを見ていただきたいのです。ACCライブラリを用いてオブジェクトをシリアライズしソフトウェアに送り込んだ時のデータ(Wiresharkを使って取得したTCPストリーム)です。この情報は、攻撃データなのでしょうか?それとも正常データなのでしょうか?
TCPストリーム
なにも知らないでこのデータを見ると判断は難しいのではないでしょうか。これは、ACCライブラリのExploitを使って取得した攻撃データなのです。データを取得した私自身もわかっているにもかかわらず、率直な感想は「攻撃なのか正常なのか判断することが難しいなぁ・・・」でした。
攻撃なのか正常なのか判断が難しいということは、攻撃による影響を低減する対策(WAFなど)を実施できるとは思えません。FWで遮断するという方法もありますが、サービス提供をしている経路を止めるというのは簡単ではありません。
これが、自分たちで独自開発したシステムであれば、対応することも容易なのですがオープンソースもしくは製品で発生した場合は製造元が対応するまでの間は、なすすべもないのです。
どのように備えるべきなのか
・システム開発時の「備える」
独自でシステムを構築するのであればチェック機構を正しく実装する。また、可能な限り証跡が残せるアーキテクチャーでシステム構築する。
チェックと言うと求めるデータ形式に該当するようにチェックするという考えに意識がいきがちですが、アプリケーションで認証チェック、認可チェック、入力値チェック、その他業務チェックなどを正しい順序で正しく行うことがシステムのセキュリティを強めることになります。
今回のACCの場合、認証チェックも認可のチェックも行わずにデータを受け取り、デシリアライズしているソフトウェアが見受けられました。当たり前のことを当たり前にすることが備えるということに繋がります。
・システム運用時の「備える」
運用時に使用していなポートは閉じ、不要なサービスは停止する。
使用しているライブラリ、ソフトウェアの使用の有無、バージョン、サポート期限などを把握し、定期的に脆弱性が発見されていないかどうか確認作業を実施する。
今回のようなことが起こった場合、まずシステムに使用しているか、使用していないのかの調査から開始されます。そのときに、「わからない」、「管理してない」では話になりません。
・サービス継続の「備える」
脆弱性発見時の初動が取れるように、判断できるルール・ポリシーを決めておく。
システムに与えるリスク、事業に対するリスクを分析判断し行動をとれるようにする必要がります。たとえば、ポートを止める/止めない、システムを止める/止めない、サービスを止める/止めないなど。こういった状況に見舞われたとき、どのようにシステムを維持運営するか非常に重要なことです。
脆弱性を解消する手段がない状態で脅威にさらされる状況になった際の行動を事前に検討し準備することは大切なことです。
ここで記載した備えでは不足している点もあるかもしれません。しかし、この備えすら行っていないところが多いのではないでしょうか。
最後に、Apache Commons Collectionsライブラリの今回の脆弱性対応情報
Apache Commons Collectionsライブラリについては、下記のように対応版が提供されています。参考にしていただければと思います。また各ソフトウェアの対応状況について、開発元を参考にしていただければと思います。
リリース情報:
タグ
- セキュリティ
- 人材開発・教育
- システム開発
- アプリ開発
- モバイルアプリ
- DX
- AI
- サイバー攻撃
- サイバー犯罪
- 標的型攻撃
- 脆弱性
- 働き方改革
- 企業市民活動
- 攻撃者グループ
- JSOC
- もっと見る +
- JSOC INSIGHT
- サイバー救急センター
- サイバー救急センターレポート
- LAC Security Insight
- セキュリティ診断レポート
- サイバー・グリッド・ジャパン
- CYBER GRID JOURNAL
- CYBER GRID VIEW
- ラックセキュリティアカデミー
- すごうで
- ランサムウェア
- ゼロトラスト
- ASM
- EDR
- SASE
- デジタルアイデンティティ
- インシデントレスポンス
- 情シス向け
- 対談
- CIS Controls
- Tech Crawling
- クラウド
- クラウドインテグレーション
- データベース
- アジャイル開発
- DevSecOps
- OWASP
- CTF
- FalconNest
- セキュリティ診断
- IoT
- EC
- サプライチェーンリスク
- スレットインテリジェンス
- テレワーク
- リモートデスクトップ
- アーキテクト
- プラス・セキュリティ人材
- 障がい者採用
- 官民学・業界連携
- カスタマーストーリー
- 白浜シンポジウム
- CODE BLUE
- 情報モラル
- クラブ活動
- 初心者向け
- 趣味
- カルチャー
- 子育て、生活
- 広報・マーケティング
- コーポレート
- ライター紹介
- IR