海の向こうの“セキュリティ”
脆弱なまま運用されている「memcached」、Ciscoが調べてサーバー管理者にメールしてみた ほか
2017年8月4日 06:00
元従業員のアカウントはいつまで残っているか? OneLoginが米国で実態調査
元従業員が、機密情報を盗み出すなどの犯罪に、退職後も残されたままになっているアカウントを使うケースは珍しくなく、退職者のアカウントを速やかに削除するというのはセキュリティ対策の基本の1つです。その一方で、同様の犯罪が今もなお後を絶たないということは、実際に退職者のアカウントが残されたまま放置されているケースは少なくないと考えられます。
このような中、ID管理サービスで知られるOneLoginは、米国の企業や組織のIT部門における意思決定者(decision maker)500人に対して、元従業員のアカウント削除に関する実態調査を行った結果を発表しました。
調査によると、元従業員のアカウントを残していたことが自組織のデータ侵害の一因となったことがあると回答した割合は20%となっています。また、回答者の48%は、元従業員が退職後も組織のアプリケーションにアクセスしていることに気付いているそうです。
一方、退職後にアカウントが残されている期間が1日以上と回答したのは50%、1週間以上が25%、分からないとの回答は25%ありました。
さらに、元従業員のアカウントを完全に削除できているとの確信が持てないとする回答者は44%に及んでいます。
元従業員によるアカウントの不正使用による事件がなくならない現実を鑑みれば「さもありなん」とも言える結果ですが、それにしても、アカウントが残されたままになっている期間が分からないとする回答が4分の1もあるのは残念でなりません。
これらの結果を踏まえてOneLoginは、従業員のアプリ使用状況の監視に「SIEM(security information and event management)」を使うことを推奨していますが、これはいかにもセキュリティ関連企業らしい物言いで飛躍しすぎでしょう。アカウント管理に不安がある企業や組織は、SIEMの前に、まず誰がどのようなアカウント(アクセス権)を持っているかを整理してまとめるといった基本に立ち返って検討することを強くお勧めします。
URL
- OneLogin(2017年7月13日付プレスリリース)
New Research from OneLogin Finds over 50% of Ex-Employees Still Have Access to Corporate Applications - https://www.onelogin.com/company/press/press-releases/new-research-from-onelogin-finds-over-50-of-ex-employees-still-have-access-to-corporate-applications
- Naked Security(2017年7月18日付記事)
Access all areas - but for how long after you’ve left the company - https://nakedsecurity.sophos.com/2017/07/18/access-all-areas-but-for-how-long-after-youve-left-the-company/
- @IT(2017年7月27日付記事)
「対策済み」と回答した企業のうち、万全だったのはたった2%:世界中の企業が、自社のGDPR(EU一般データ保護規則)対策を「勘違い」している――Veritas調査 - http://www.atmarkit.co.jp/ait/articles/1707/27/news052.html
脆弱なまま運用されている「memcached」、Ciscoが調べてサーバー管理者にメールしてみた
キャッシュサーバーとして広く使われている「memcached」の、2016年10月に公開された3つの脆弱性について、それらを発見・報告したCiscoのセキュリティリサーチチーム「Talos」が、その後、どれくらいのmemcachedが修正(更新)されたのかを調査した結果をブログで発表しました。
これらの脆弱性はいずれも最悪の場合に遠隔からコードを実行できてしまうもので比較的深刻度の高い脆弱性です。
- JVNDB-2016-006637(CVE-2016-8704)
Memcached の process_bin_append_prepend 関数における整数オーバーフローの脆弱性
http://jvndb.jvn.jp/ja/contents/2016/JVNDB-2016-006637.html - JVNDB-2016-006638(CVE-2016-8705)
Memcached の process_bin_update 関数における整数オーバーフローの脆弱性
http://jvndb.jvn.jp/ja/contents/2016/JVNDB-2016-006638.html - JVNDB-2016-006639(CVE-2016-8706)
Memcached の process_bin_sasl_auth 関数における整数オーバーフローの脆弱性
http://jvndb.jvn.jp/ja/contents/2016/JVNDB-2016-006639.html
Talosが詳細な情報を公表した時点で開発元からは修正版がリリースされており、また、主要なLinuxディストリビューションでもすぐに対応済みのパッケージが公開されています。しかし(概ね予想通りではありますが)8割近くのmemcachedが脆弱な状態のままであることが分かりました。
今回の調査は、インターネットからアクセス可能なmemcachedに対して、あるパケットを送りつけ、その反応から脆弱な状態か否かを調べています。memcachedのバージョンを調べるのではなく、このような方法をとった理由としてTalosは、Linuxディストリビューションの中には古いバージョンにパッチをバックポートして適用することで対応しているケースがあるため、バージョン情報だけでは脆弱か否かを判断できないからとしています。
なお、Talosの今回の調査は顧客に限定しておらず、インターネットからアクセス可能なmemcachedに対して「勝手に」行っています。そのため、このようなパケットを送りつけて脆弱か否かを判断する行為に(違法性があるかどうかはパケットの具体的な中身や法律によりますが)倫理的な問題はないのか気になります。
調査した項目は以下の4点です。
- インターネットから直接アクセス可能なサーバーの数
- それらのうち脆弱なままの数
- 認証を使用している数
- 認証を有効にしているサーバーのうち脆弱なままの数
調査は脆弱性情報公開の約4カ月後である今年の2月下旬から3月上旬にかけて行われ、その結果は以下のようになりました。
正当(valid)な反応があったサーバー数 | 10万7786 |
脆弱なままのサーバー数 | 8万5121(79%) |
脆弱でないサーバー数 | 2万2665(21%) |
認証を要求するサーバー数 | 2万3907(全体の22%) |
認証を要求するサーバーのうち脆弱な数 | 2万3707(上記の99%) |
インターネットから直接アクセスできるサーバーが10万以上もあり、その8割近くが脆弱なままであるというのは残念としか言いようがないのですが、それ以上に注目すべきは、認証設定が有効になっているものが全体の22%しかなく、しかも、そのほとんどすべてが脆弱なままであるという点です。今回の脆弱性のうちの1つ「CVE-2016-8706」は認証の仕組みにおける脆弱性で、認証設定を有効にしていても脆弱なのですが、今回の結果は、その事実がほとんど認知されておらず、「認証設定を有効にしているので大丈夫」と誤解されていることを示していると言えるでしょう。
なお、調査対象となったサーバーの国や地域別の内訳は以下の通り。
全サーバー(インターネットからアクセス可能なmemcachedの数) | |
1. 米国 | 3万6937 |
2. 中国 | 1万8878 |
3. 英国 | 5452 |
4. フランス | 5314 |
5. ロシア | 3901 |
6. ドイツ | 3698 |
7. 日本 | 3607 |
8. インド | 3464 |
9. オランダ | 3287 |
10. カナダ | 2443 |
脆弱なサーバー(カッコ内は上記のサーバー数に対する割合) | |
1. 米国 | 2万9660(80%) |
2. 中国 | 1万6917(90%) |
3. 英国 | 4713(86%) |
4. フランス | 3209(60%) |
5. ドイツ | 3047(82%) |
6. 日本 | 3003(83%) |
7. オランダ | 2556(78%) |
8. インド | 2460(71%) |
9. ロシア | 2266(58%) |
10. 香港 | 1820(――) |
ロシアとフランスの割合の低さ(≒更新率の高さ)が目を引きます。また、日本の83%という数字は世界全体の79%よりも高く、更新率は低い方になります。
この結果を踏まえてTalosは、脆弱なmemcachedを稼働させているサーバーのIPアドレスを所有している(管理責任のある)組織に対して以下の通知をメールで送付したそうです。
その後、Talosはこの通知にどの程度の効果があったかも調べています。なお、Talosは「6カ月後(six months later)」としていますが、最初の調査は今年の2月下旬から3月上旬にかけて行われたので、今回のブログでの発表時期から考えると、実際には4カ月後くらいではないかと思われます。
2回目の調査結果は以下の通り。
正当(valid)な反応があったサーバー数 | 10万6001 |
脆弱なままのサーバー数 | 7万3403(69%) |
脆弱でないサーバー数 | 3万2598 (31%) |
認証を要求するサーバー数 | 1万8173(全体の17%) |
認証を要求するサーバーのうち脆弱な数 | 1万8012(上記の99%) |
前回の調査に比べて脆弱なままのサーバー数の割合は79%から69%に減っていますが、その減少分は10%に過ぎず、相変わらず多くのmemcachedが脆弱なまま運用されています。また、前回の調査で脆弱な状態にあった8万5121のサーバーに絞ってまとめた結果は以下の通りです。
脆弱なまま | 5万3621(63%) |
脆弱でない | 2958 (3%) |
オフライン | 2万8542(34%) |
修正されたことが確認できたのはわずか3%に過ぎず、また、3分の1以上がオフラインになっています。このオフラインとなったものは、前回の調査対象10万7786の約26%を占めており、その一方で、インターネットからアクセス可能なmemcachedの数自体は10万強のままで大きく変わっていません。この結果に対してTalosは、単にIPアドレスを変えただけで何も修正していないものや脆弱なバージョンのmemcachedで新規に運用を開始したシステムが多いのではないかとしています。
memcachedは広く使われており、今回の調査対象となった脆弱性は比較的深刻度の高い部類に入りますが、それでも、昨年の情報公開時点でメディアの取り上げ方は大きくありませんでした。日本では「JVN(Japan Vulnerability Notes)」には掲載されているものの、JPCERT/CCなどから特に注意喚起は出ていません。それゆえ、更新されていないものが多かったり、認証設定を有効にしているから大丈夫との誤解があったりするのも致し方ないのかもしれません。また、Talosの調査の仕方に不快感を覚えたり、Talosからの通知を一種の「恐喝」のようなものに感じたりした企業や組織も少なくないと思います。
今回のTalosの調査は、注意喚起や問題の指摘のあり方を含め、脆弱性情報の取り扱いの難しさを改めて示すものと言えるかもしれません。
URL
- Cisco's Talos Intelligence Group Blog(2017年7月17日付記事)
Memcached - A Story of Failed Patching & Vulnerable Servers - http://blog.talosintelligence.com/2017/07/memcached-patch-failure.html
- Cisco Japan Blog(2017年7月24日付記事)
Memcached - 不適切なパッチ適用と脆弱なサーバについての事例 - https://gblogs.cisco.com/jp/2017/07/memcached-patch-failure/