2021/01/23

サイバー攻撃に対抗するには多様な視点やコラボレーションが重要--英サイバー防衛担当幹部 / What's the key to tackling cyberattacks? Building a diverse team to think smarter(転載)

サイバー攻撃に対抗するには多様な視点やコラボレーションが重要--英サイバー防衛担当幹部:

 サイバーセキュリティチームが企業や政府、その他の組織や人々をサイバー攻撃から守るためには多様な考え方が必要だ。そして、サイバー犯罪との戦いで、異なる視点を持つ人々が協力できるようにするには、コラボレーションが重要になる。

 英内閣府のサイバー防衛担当副ディレクターPete Cooper氏は、困難に立ち向かい、社会のサイバーリスクを減らすためには、この種の協力を重んじる姿勢が必要になると語った。

 英空軍のジェット機パイロットからサイバー作戦アドバイザーに転身したCooper氏は、英国で初めて分野横断的なサイバー戦略コンテストを創設した人物でもある。同氏は、国際的なサイバーセキュリティの問題に取り組むためには優れたコラボレーションと多様性が重要だと考えている。

 Cooper氏は、「Black Hat Europe 2020」の基調講演で、「私たちは、自分たち課題について多様な視点を持っており、それぞれが違った視野を持っている。コラボレーションの本当の価値は、世界を多様な視点から見ることにある」と述べた。

 「それによって共通の視点を生み出すことができ、共同で視野を広げることでさらに遠くまで見渡せるようになると同時に、あらゆることに対して共通の理解を深めていくことができる」

 同氏は、異なる視点を混在させることで、リソースの使い方や取れるアクションが大きく変わる可能性があると説明した。さらに既知のシナリオや、これまでは知られていなかったシナリオへの新しい対処法さえ見つかるかもしれないという。

 「そのことがほかにはないコラボレーションを生み出し、これまでは見えなかった障害や、チャンスや、アイデアを見つけることができるだろう。それがコラボレーションを行う本当の意味だ」とCooper氏は語った。

 「多様なチーム間でのコラボレーションで最善のソリューションはこれらの共同でのソリューションであり、それを実行するにはそのようなコラボレーションが必要になる」

 サイバー攻撃やデータ侵害の防止やそれらのインシデントへの対応はサイバーセキュリティの重要な要素だが、それは仕事のごく一部にすぎない。業界の文化や、組織内の情報セキュリティチームの文化にもそのことを反映させる必要がある。

 「インシデントは全体の一部が見えているにすぎない。水面下の状況を見て何が問題かを理解したり、発生した事象が何を意味しており、それらを把握するためにはどんなアイデアがあり得るかを理解するには、積極的で優れた文化が必要だ」とCooper氏は説明した。

 また同氏は、異なる視点を持ち寄るには時間と手間がかかるが、サイバーセキュリティが達成しようとしているあらゆることに対して、コラボレーションと多様性は役に立つと指摘した。

 「それができれば、私たちは共通の視点を共有し、視野を広げるようになる」

 「協力し合って共通の視野から多くのことを学ぶほど、今後重要なリスクに取り組もうとする際に、誰にとってもよりよい結果になる」と同氏は付け加えた。

2021/01/22

2020年のクラウドネイティブの脅威 / Cloud-Native Threats in 2020(転載)~クラウドサービス(オンラインストレージ)を悪用した脅威が増加か!?~

CNT2020.png?fit=1200%2C675&ssl=1


2020年に私が行った様々なことの中で、キルチェーンの中でクラウドサービスを悪用した主なサイバー攻撃を集めたものがあります。私は公開されている情報を使って、個人的な(明らかに不完全な)リストを構築しました。完全な年表は記事の最後に掲載していますが、いくつかの統計は以下のチャートにまとめています...

クラウドサービスは、信頼性が高く回復力のあるホスティングインフラストラクチャを提供し、従来のセキュリティ管理を迂回することができ、最後に、ユーザーから暗黙のうちに信頼されているため、脅威行為者に悪用されるケースが増えています。これは、GuLoaderやBazaarLoader(最近の壊滅的な攻撃の波でRyukランサムウェアを配信するために配備された)のようなドロッパーの採用が増えていることを説明しています。

前述したように、これはクラウドネイティブの脅威の状況を部分的に示しているに過ぎませんが、いずれにしても、悪意のある目的でクラウドサービスを悪用することがどれだけ頻繁になっているかを示す有用な指標になることを期待しています。








国土交通省北海道開発局の癒し系ツイート(転載)


 「国道40号ばばばばばえおうぃおい~」 国交省北海道の謎ツイート、原因は「サーバ更新時のエラー」


 「国道40号ばばばばばえおうぃおい~べべべべべべべべべえべえええべえべべべえ(9.9km)で通行止を実施しています」――道路情報を伝える国土交通省北海道開発局のTwitterアカウントが1月19日、このような謎のツイートを投稿し、Twitter上で話題を呼んでいる。同局によれば、サーバ更新作業中のエラーが原因だという。

 同アカウントは、通行止め情報をまとめているWebサイト「北海道地区道路情報」の更新に合わせて自動で情報を発信している。話題のツイートは19日午後3時ごろに自動投稿された。実際にはツイートに記載されていた国道40号の通行止めは行われておらず、同アカウントは後にツイートを削除。午後5時ごろには誤作動があったとしてアカウントを一時停止した。

 投稿直後から、Twitterでは「面白い」「癒やされた」と話題になり、ツイートを読み上げた動画やオリジナル曲が作られるなどネット特有の盛り上がりを見せた。一方「文章を変換すると『こちらにこい』になる」など、内容について考察するユーザーもいる。

 謎のツイートが投稿された理由について、国土交通省北海道開発局は「北海道地区道路情報のWebサイトを管理しているサーバの更新作業中にエラーが発生し、通常なら表に出ないテスト用のデータがツイートされた。内容に意味はない」と説明した。外部から不正アクセスや攻撃を受けた痕跡はないとしている。

 同局はサーバを点検し、午後7時ごろにツイートを再開。「ご迷惑をおかけして申し訳ありませんでした」と謝罪した。

2021/01/21

英AnyVan、410万人分のユーザー情報が漏洩し、ダークウェブに晒される。 / AnyVan 4.1 Million Users Comprised with Data-Breach(転載)


AnyVanは、ロンドンのハマースミス(英国)に本社を置く、輸送パートナーのチェーンネットワークから委託、輸送、撤去サービスにアクセスするためのヨーロッパのオンラインプラットフォームです。それはヨーロッパの移動のみに焦点を当てています。また、パトロンの配送経路と輸送サービスプロバイダーの配送経路を簡単に比較し、それらを関連付けることで、保管スペースや運搬量を最適化することでコストを削減し、CO2排出量を削減することができるため、引越しサービスの面ではヨーロッパのフロントランナーの一つとなっています。しかし、最近AnyVanは、不正なデータ侵入とハッカーによるパトロンの個人情報の横領について、そのユーザーを肯定した。

同社は、同社が被害者となったデータ漏洩に関する通知をパトロンに送付することで、パトロンに通知したという。AnyVanはその後、2020年12月31日にこの事件を発見したことを明らかにしており、その理由についても "なぜこんなに遅くに通知されているのか?"と言及しています。

AnyVanは、上記の事件について、「このデータ漏洩が当社の注意を引いたのは12月31日でしたが、事件自体は9月末に発生したと理解しています。事件が発生してからすぐに、当社の専門ITチームが調査し、以下の改善措置を講じました。

同社が発表した通知と声明によると、パトロンの名前、電子メール、パスワードの暗号ハッシュがアクセスされ、おそらく役者によってダークウェブ上に表示されたという。どうやら、他の機密情報は侵害されていないようだ。さらに、彼らは事件の調査が続いていることを追加しました。しかし、これはすべて、アクターがユーザーのデータや情報を悪用するのに十分な時間を持っていた後にのみ来た。推定では約410万人のユーザーがこのデータ侵害の影響を受けているという。AnyVanはICO (Information Commissioner's Office)に連絡しなかったが、これはユーザーの機密データが漏洩したことを示す重要な一歩であった。

予防策として、同社は利用者に対し、AnyVanで使用するアカウントのパスワードやその他の個人情報を更新するよう助言した。また、同社は、利用者が知らず知らずのうちに他の情報や個人情報を誰かと共有しないように注意を促した。また、同社は、ユーザーが被った個人情報のこのデータ侵害について謝罪し、彼らは非常に迷惑をかけて申し訳ありませんと述べた。

SolarWinds事件(SunBurst)のフォレンジック調査(転載)~自社だけでセキュリティ対策を頑張っても、オンラインでくるアップデートモジュールが汚染されてしまうと手も足も出ない。。。~


SolarWinds事件(SunBurst)のフォレンジック調査
 

エグゼクティブサマリー

  • Orion ソフトウェアのビルドとコード署名のインフラストラクチャが侵害されたことの決定的な詳細を示しています。
  • Orion のソースコードが悪意のあるバックドアを含むように直接変更されたことを確認するコンパイル結果を開示しています。
  • バックドアされたOrionのソフトウェアパッチが、既存のソフトウェアリリース管理システムを介して配信されたことを確認する、ソフトウェア配信の成果物を開示しています。
  • 将来のソフトウェアサプライチェーン攻撃を検出して防止するための新しいアプローチを提案しています。

概要

IT監視・管理ソリューションを製造するSolarWinds社が、巧妙なサプライチェーン攻撃の最新の標的となっています。2020年3月から6月にかけてリリースされた複数のSolarWinds Orionソフトウェアアップデートには、攻撃者が影響を受けたシステムに対して監視や任意のコマンドの実行を可能にするバックドアコードが含まれていることが判明しています。

ReversingLabsのこのサプライチェーン攻撃の解剖調査により、Orionソフトウェアのビルドおよびコード署名インフラストラクチャが侵害されていることを示す決定的な詳細が明らかになりました。影響を受けたライブラリのソースコードは、悪意のあるバックドアコードを含むように直接変更され、既存のソフトウェアパッチリリース管理システムを通じてコンパイル、署名、配信されました。

ソフトウェアのサプライチェーンに対するこの種の攻撃は決して目新しいものではありませんが、今回と異なるのは、可能な限り長く検出されないようにするために攻撃者が使用したステルスのレベルです。攻撃者は、影響を受けたコードベースに溶け込み、ソフトウェア開発者のコーディングスタイルや命名基準を模倣しました。これは、Orion ソフトウェアを使用するあらゆる組織のバックドアにするために追加されたかなりの数の機能によって一貫して実証されました。

ソフトウェア開発者からの隠蔽

事件の外部からストーリーをまとめることは困難です。しかし、残されたパンくずの痕跡から、攻撃者が Orion ソフトウェアのリリースプロセスを侵害するために使用した方法について、ある程度の洞察を得るには十分です。

このような調査は通常、既知のものから始めます。この場合、バックドアードされたソフトウェアライブラリのリストです。OrionプラットフォームソフトウェアパッケージのアップデートSolarWinds-Core-v2019.4.5220-Hotfix5.msp内のSolarWinds.Orion.Core.BusinessLayer.dllというファイルが、悪意のあるバックドアコードを含むことが知られている最初のバージョンです。このライブラリは、FireEyeの技術ブログで徹底的に分析されており、バックドアの動作について非常によく説明されています。

しかし、メタデータの分析から、攻撃者の忍耐力、巧妙さ、Orion ソフトウェアビルドシステムの状態について、さらなる結論を導き出すことができます。

FireEyeブログで概説されているように、悪意のあるバックドアコードを含む最初のバージョンは2019.4.5200.9083でしたが、攻撃者によって改ざんされた以前のバージョンがありました:2019年10月のバージョン2019.4.5200.8890で、このバージョンはわずかに修正されただけでした。悪意のあるバックドアコードは含まれていませんが、将来的にそれをホストする.NETクラスが含まれています。

この最初のコード修正は、明らかにコンセプトの証明に過ぎませんでした。彼らの三段階の行動計画 ビルドシステムを破壊し、独自のコードを注入し、署名されたパッケージが期待通りにクライアント側に表示されることを確認する。これらの目的が達成され、サプライチェーンが侵害される可能性があることが攻撃者自身に証明されると、攻撃者は実際の攻撃ペイロードの計画を開始しました。

クラスの名前である OrionImprovementBusinessLayer は、意図的に選ばれたものです。残りのコードに紛れ込むためだけでなく、ソフトウェア開発者やバイナリを監査する人を騙すためです。このクラスと、それが使用するメソッドの多くは、他のOrionソフトウェアライブラリにも含まれており、それらのライブラリ内のコードとテーマ的に一致していることさえあります。これは、ステルス性を保つ意図だけでなく、攻撃者がコードベースに精通していたことを暗示しています。

例えば、UserID を計算する関数を比較してみてください。Orion Client のコードでは、この関数はレジストリから以前に計算された値を読み込もうとしたり、ユーザの新しい GUID を作成したりします。

これを模倣して、攻撃者はこれらの関数の独自の実装を作成してUserIDも計算し、同じように名前を付けました。彼らの関数は、後に ID 型に同じ GUID 形式を使用していることさえあります。

正確ではありませんが、このコードはオリジナルと同じような機能を果たしています。クラス、メンバー、変数を適切に命名するパターンは、バックドアされたコードの至る所に見られます。

実際に、Orionクライアントライブラリのコードで使用されるCollectSystemDescriptionとUploadSystemDescriptionというメソッドがあります。IOrionImprovementBusinessLayer インターフェースがあったように、攻撃者はバックドアコードを配置したクラスの名前を模倣しました。

しかし、ライブラリに追加されたコードは、魔法のようにそれ自体が実行されるわけではありません。攻撃者は何らかの方法でそれを呼び出す必要があります。そして、それが行われた方法は、ビルドシステム自体が危険にさらされたことを物語っています。


赤くハイライトされたコードは、攻撃者が入れた追加機能です。この小さなコードブロックは、Orion ソフトウェアがバックグラウンドのインベントリチェックを実行している間に、バックドアを実行する新しいスレッドを作成します。このような場所は、この種のコードを追加するのに最適な場所です。つまり、攻撃者が注入した残りのコードと同様に、このコードも溶け込んでしまうのです。

.NET コードを逆コンパイルして新しいものを注入し、その後にコードを再コンパイルする方法もありますが、今回はそうではありませんでした。InventoryManagerクラスはソースコードレベルで修正され、最終的には通常のOrionソフトウェアのビルドシステムでビルドされました。

これは、バックドアされたバイナリのタイムスタンプ、同じパッケージ内の他のライブラリ、およびそれらを配信するパッチファイルを見ることで確認できます。

PE ファイルヘッダと CodeViews のタイムスタンプは完全に一致しています。これは、リビジョン番号が 1 に設定されているということは、 そのファイルが一度だけコンパイルされたか、あるいはクリーンビルドされたかを意味します。ファイルは署名され、タイムスタンプのために交差署名されているので、ヘッダ内のタイムスタンプを確実に検証することができます。クロスサインのタイムスタンプは、ビルド環境の外にあるリモートサーバによって制御され、改ざんされることはありません。

署名はライブラリのコンパイルから1分以内に発生しています。これでは、攻撃者がビルドシステムを監視し、バイナリを置き換え、これに完全に一致するようにメタデータを変更することができる時間がありません。これらのタイムスタンプを完全に一致させる最も簡単な方法は、攻撃者のコードをソースに直接注入し、既存のビルドシステムと署名システムに、Orionソフトウェア開発者によって定義されたコンパイルとリリースのプロセスを実行させることです。

最後に、MSP のパッチファイルには CAB アーカイブが含まれており、ライブラリのローカルの最終更新時刻を保持しています。これは、ビルドシステムがGMT+1タイムゾーンで動作していると仮定して、署名中にファイルが最終更新されたことを確認するものです。

同じ名前空間に属するバックドアされたライブラリの周囲のファイルも同時にコンパイルされています。これらのファイルは互いに依存していないので、ビルドシステムが完全なビルドを実行していない限り、同時にビルドされることはありません。

MSP のパッチファイルは署名されており、その署名時間はパッケージの内容と一致しているので、パッチファイルが残りのビルドと同じマシン上で作成されたことを確認できます。

大きな疑問は、ソースコントロールが侵害されたのか、攻撃者のコードがビルドマシンに置かれただけなのかということです。

残念ながら、それはメタデータでは明らかにできません。ソフトウェアのコンパイル中に保存されるような成果物はありません。しかし、攻撃者はコードがコードベースの中にあるように見えるようにするために、多くのトラブルを経験しました。これは確かに、ソフトウェア開発者による監査からコードを隠すために行われました。

確実なのは、ビルドインフラが侵害されたということです。さらに、デジタル署名システムは、信頼できないコードに署名することを余儀なくされた。現時点では、SolarWindsの証明書が他の悪意のあるコードの署名に使用されたという証拠はありませんが、その可能性は排除されるべきではありません。そして、予防措置として、そのビルドシステムで使用されたすべての証明書と鍵を失効させる必要があります。

セキュリティアナリストに隠れて

このような環境でオリオンのソフトウェアを実行している顧客のタイプを考えてみましょう。このようなソフトウェアのサプライチェーン攻撃を成功させるためには、攻撃者はレーダーを潜り抜け、何百万ドルものセキュリティ投資を回避する必要があります。攻撃者は、高度に専門化された検出ソフトウェアと、脅威を検出するためにそれを実行している人々を騙して、数ヶ月間、このソフトウェアを使用して積極的に異常を探し出す必要があります。このトリックを成功させるためには、攻撃者は隠れたままでいることと目的を達成することの間で適切なバランスを取る必要があります。

大規模なセキュリティ予算には、かなり多くの特典が付いています。内部脅威の調査ができることは、確かにその1つです。そして、脅威ハンターがデータの異常ほど探したがるものはありません。YARAルールは、ただ横たわっている奇妙なものを見つけるための一つの方法に過ぎない。

文字列 "Select * From Win32_SystemDriver "は、おそらくかなりの数の中に見られる。そのため、攻撃者は圧縮とBase64エンコーディングを組み合わせて、このようなノイズの多い文字列をすべて隠すことにしたのです。前述の文字列のBase64変種を探すハンティングルールがかなりの数存在するため、このような2段階のアプローチが必要でした。

これらのステップを逆にすることで、上で見つかったC07NSU0uUdBScCvKz1UIz8wzNooPriwuSc11KcosSy0CAA==は "Select * From Win32_SystemDriver "になります。そして、すべての脅威狩りのルールは、賢くないままです。

このような文字列難読化はコード全体で繰り返されます。これが、ソフトウェア開発者のレビューで目立つことと、セキュリティシステムを騙すことの間のバランスであり、攻撃者にとっては、この賭けが実を結んだことになります。

サプライチェーン攻撃の防止
ソフトウェアのサプライチェーンの安全性確保に重点を置いているセキュリティ企業はほとんどありません。ほとんどのセキュリティ企業にとって、この種の攻撃がもたらすリスクを減らすことについて話すことは、遠い未来の話です。多くの点で、私たちはまだ問題意識の段階にあります。このような事件は、ソフトウェアを出荷する側と消費する側にも同様に影響を与える多面的な問題であることに注意を喚起するのに役立ちます。

ReversingLabs の研究開発チームは、このような大きな問題が広く懸念される前に考えることに誇りを持っています。そのために、私たちはこのような問題に対処するための製品やソリューションのプロトタイプを数多く作ってきました。

ソフトウェアのサプライチェーンの保護は、解決が待たれている大きな問題です。そして社内では、開発者とユーザーの双方を保護するための製品戦略を定義しました。

私たちは、「ゴールド」ソフトウェアのリリースイメージをリリースや消費の前にスキャンできるシステムを想定しています。このシステムは、ソフトウェアの改ざん、デジタル署名、およびビルド品質の問題を探すために意図的に構築されています。このシステムは、継続的なソフトウェア開発とリリースサイクルに組み込まれており、これらの問題を表面化させ、それらを排除するためのガイダンスを提供することを目的としています。

このようなシステムの重要な側面の1つは、コンパイルされたソフトウェアのバージョン間の動作の違いをピンポイントで特定する能力です。静的挙動指標と呼ばれるこの記述は、基本となるコードの動作を、それを実行するマシンに与える可能性のある影響に変換します。

追加された(緑)コードと削除された(赤)コードの違いとしてレイアウトすると、ソフトウェアの動作の変化の影響が明らかになります。バックドアされたSolarWindsバイナリでは、これにより、このサプライチェーン攻撃をより早くキャッチすることが可能になったであろう多くのセキュリティアラームが発生します。

以下のリストでは、最初に改ざんされたバージョンと、悪意のあるバックドアコードを含むバージョンとの間の重要な静的コードの動作の変化を強調しています。

1. 1つ以上の実行中のプロセスに関する情報を読み取る
アプリケーションが突然、環境で実行中の他のプロセスを認識するようになることは、非常に珍しいことです。成熟したコードベースでは、この機能は通常メジャーリリースで追加されます。通常、この種のコードの背後には大きな機能が計画されています。そして、通常、追加するにはそれなりの理由があります: ある種のプロセス間通信や、実行中のプロセスを制御したいという願望です。他のシナリオでは、このような無計画な追加は懸念の原因となります。

2. MD5/SHA1 アルゴリズムの .NET Framework クラスへの参照が含まれています。
珍しいものではありませんが、MD5 や SHA1 のようなハッシュ化アルゴリズムは、特定の問題を解決するために実装されるのが一般的です。それは、ある種のコンテンツの検証、認証、または一意性のチェックのいずれかです。これらのそれぞれは通常、高レベルの要件にマッピングされ、機能変更のリクエストや同様の開発タスクまで追跡することができます。

3. kernel32.dll / advapi32.dllネイティブWindows APIへの参照が含まれています。
.NET ライブラリから突然 Windows ネイティブ API を参照するというのは非常に珍しいことです。システムと相互作用する基礎となるコードは、管理されたアプリケーションであっても必要ですが、より良い方法があります。例えば、提供されている言語ランタイムは、ほとんどの開発者がネイティブ関数に求めるものと同じ効果を、型の不確実性に対処することなく、一般的に達成することができます。サプライチェーン攻撃のコンテキストに関係なく、これ自体が開発者がコードの匂いと呼んでいるものです。

4. WMIを使用してシステム情報を列挙する
Windows Management Instrumentation (WMI) は、アプリケーションがローカルおよびリモートコンピュータシステムの状態に関する情報を取得することを可能にするシステム機能のセットです。IT管理者は、これらの機能を使用してコンピュータシステムをリモートで管理しています。なぜこのような機能が突然追加されるのかを理解することは非常に重要です。アプリケーションの範囲が劇的に変化して、リモート・コンピュータ・システム間の相互作用がその重要なタスクの一部になったということは考えられません。そして、ローカルシステムから何かを取得することが目的であれば、すでにその情報を持つコードがあるかもしれません。

5. ユーザー/アカウントの権限を列挙しています。
ユーザーやアカウントの権限を調べることは、通常、権限を昇格させるための最初のステップです。上昇した権限でコードを実行するのは、制限されたフォルダにファイルをコピーしたり、実行中のプロセスを操作したり、システムの設定を変更したりなど、限定されたアクションを実行するために行われます。これらのアクションはすべて、その背後にしっかりとした理由がなければならないものであり、成熟したコードベースに追加することは、少なくとも疑問の余地があります。開発者は、この種のことを認識し、サインオフしなければなりません。

6. システムのシャットダウンを妨害する
アプリケーションの不必要な特権というテーマに固執して、最後に大きな赤旗を掲げています。コンピュータをシャットダウンしたり再起動したりすることは、予期せずコードに追加されたものではありません。これは、複数のコードコンポーネント間の調整を必要とする機能であり、通常はアプリケーション内の単一の場所で実装されます。それが他の場所に現れることは、間違いなく懸念の原因となります。

ソフトウェアの展開プロセスのどの側にいるかに関わらず、ソフトウェアコードの変更の影響に関するレポートは、非常に貴重な情報です。ソフトウェア開発者にとっては、基礎となるコードの動作についての情報に基づいた意思決定を行うことができます。また、ソフトウェアの消費者にとっては、異常なコードの追加を確実に検出することができます。いずれにしても、このようなシステムの影響は、ソフトウェアのデプロイメントプロセスに大きな変化をもたらします。このようなソフトウェアサプライチェーン攻撃が再発しにくくなる検証バリアとしての役割を果たします。

新しい制御機構の必要性

SUNBURSTは、アクセス、洗練された技術、忍耐力を武器とした次世代の危殆化対策を紹介しています。貴重なビジネスを運営している企業や、顧客にとって重要なソフトウェアを製造している企業にとって、ソフトウェアを検査し、改ざんの兆候がないか、悪意のあるものや不要なものが追加されていないか、アップデートを監視することは、リスク管理プロセスの一部でなければなりません。この種の改ざんは、従来のセキュリティソフトウェアスタックで信頼されているソフトウェアディストリビューションを悪用するもので、既知の悪意のあるインプラントと比較しても特異なものです。ディストリビューションは、たとえ境界制御によっても、容易に検査することはできませんでした。世界的に知られたソフトウェアブランドや、信頼されたビジネスクリティカルなプロセスの背後に隠れていることで、フィッシング・キャンペーンでは夢のようなアクセスが可能になります。

NIST CSFなどのサイバーセキュリティフレームワークの多くは、継続的なリスク管理とデータとソフトウェアの検査の必要性を文書化しています。これには、社内外を問わず、すべてのサードパーティ製およびオープンソースのソフトウェアを継続的に検査し、改ざん、悪意のあるコンテンツ、または組織の許容ポリシーに抵触する望ましくない特性がないかどうかを確認する必要性も含まれています。

クラウドを利用する際の設定ミスにより第三者に迷惑をかける場合(転載)~PayPay、楽天、Salesforce、etc~



クラウドを利用する際の設定ミスにより第三者に迷惑をかける場合:

クラウドサービス等を利用する際にも当然に、誰が、何に対してどういうアクションができるのか?という設定が必要となってきます。アクセス方針について適切に決めていたとしても、設定を誤ると期待した効果が生じません。なので、適切に設定されていることは、クラウドサービスを利用する際にユーザが当然に確認すべき事項となります。この設定ミスにより第三者に迷惑をかけた場合は、ユーザの責任となるでしょうね。。。

ただ、設定が非常に複雑であったり、システムの理解が浅い利用者を想定している場合は、それ相応の対応(つまり、想定利用者の能力に応じて簡単に安全な設定ができるようにする機能や、説明ページ、場合によっては担当営業やカスタマーセンターによる対応)等を準備することはサービス提供者には必要となるでしょうね。。。この辺りの法律的な話は弁護士等の法律家の方がうまく説明してくれると助かりますね。。。

と、色々と最近の事件をみて思いました・・・

● PayPay


● 楽天


● Salesforce


【バックアップ】

2021/01/20

PCでディスプレイの揺らぎが気になる際の対処法~Chromeのハードウェアアクセラレーションが原因か?~


12月に新たにパソコンを購入したのだが、 どうも調子がおかしい。

事象的にパターン化できないのが心苦しいところなのだが、分かっている範囲で整理すると、

・ディスプレイでリサイズしている感じの歪みが発生

・たまーにディスプレイが真っ暗になり、30秒くらいすると復帰

・上記の事象はバッテリーモードで使用中に発生

・Chromeを使用中に発生

上記のような感じである。

新しいPCだし、放っておけば直るかとも思ったのだが、たまーに発生するディスプレイが30秒真っ暗になる事象は、たまーにでも不安を掻き立てられ、メーカーサポートに問い合わせてみた。

その際の対処法が下記。

----------------------

【1】Windows を完全にシャットダウンし、放電を行います。

【2】BIOS 設定値の初期化を行います。

【3】Windows Update にて最新の状態にする。

【4】グラフィックスドライバーを更新する。

【5】Google Chrome の設定を変更する。
   →ハードウェアアクセラレーションの無効化

--------------------------------------------------

5番目に気になる方法があり、まずは5番からやってみることにした。

というか、PC自体は購入後1か月も経っていないのと、事象から察するにChromeのアクセラレーションが一番の原因の気がする。。。

とりあえずChromeのアクセラレーションを無効化して様子を見てみよう。

むかしDELLのパソコンを使っていたが、サポートに電話すると二言目には「OS再インストールしてください」と言われ、閉口したことがある。

VAIOのサポートはとても親身な気がする。


2021/01/19

Google ChromeでURLバーにドメインしか表示されない問題を解消する方法

 

普段ブラウザはGoogle Chromeを使っているのだが、どこかのタイミングからか、URLバーに表示されるはずのURLがドメインだけに短縮され、マウスカーソルを当てないとすべて表示されないという、個人的にイヤな事象が発生していた。

調べてみると、Google Chromeにおけるフィッシングによる被害を防ぐための新たな取り組みとのことなのだが、アクセスしているURLが一部隠されてしまうのは、個人的には迷惑である。

そこで、元に戻す方法を調べてみた。

当初Chromeの設定で元に戻せるのかと思っていたが、どうも拡張機能を入れて全体を表示させることで解消させるアプローチ委となるようだ。

で、そのツールが下記。

Suspicious Site Reporter

Google謹製なので、おそらく安心していいと思う。

実際入れてみたところ、たちどころにURLが勝手に省略される事象が直った。

メデタシメデタシ

【参考】

アドレスバーの省略 URL を全表示する Chrome拡張機能

U.S. GAO 国防省の15のシステム開発を監査してみて(転載)~米国の国防予算に占めるIT予算化比率は5.1%~



U.S. GAO 国防省の15のシステム開発を監査してみて・・・開発手法やセキュリティについてコメント付けてます:

U.S. GAO 国防省の15のシステム開発を監査した結果を公表しています。。。参考になりますね。。。報告書は63ページあります・・・ 

It requested about $36.1 billion for IT for fiscal year 2020. 

とありますから、国防省はIT予算として361億ドル、約4兆円の予算を要求しているんですね。。。日本の防衛予算は約5兆円ちょっと(2020.12.21 我が国の防衛と予算(案)-令和3年度予算の概要- )ですから、すごい金額ですね。。。まぁ、国防省の予算が7,000億ドル弱(77兆円)のようですから。。。(ちなみに、人件費・福利厚生費が40%弱を占めるみたいです)

Cost estimates decreased for 11 programs (ranging from .03% to 33.8%) and 10 programs experienced schedule delays (ranging from 1 month to 5 years).

とありますから、15のプログラムのうち11で開発コストが下がっているんですね。でも10のプログラムで遅延が発生していると・・・

10 of the 15 programs reported using commercial off-the-shelf software, which is consistent with DOD guidance to use this software to the extent practicable. Such software can help reduce software development time, allow for faster delivery, and lower life-cycle costs.

とあるので、10/15が市販ソフトを活用しているようですね。。。これはDODの方針にあっていると・・・

In addition, 14 of the 15 programs reported using an iterative software development approach which, according to leading practices, may help reduce cost growth and deliver better results to the customer. However, programs also reported using an older approach to software development, known as waterfall, which could introduce risk for program cost growth because of its linear and sequential phases of development that may be implemented over a longer period of time. Specifically, two programs reported using a waterfall approach in conjunction with an iterative approach, while one was solely using a waterfall approach.

ということは、ウォータフォールの開発手法だけではダメで、うまくアジャイルと組み合わせなさいという感じですかね。。。

In contrast, only eight of the 15 programs reported conducting cybersecurity vulnerability assessments—systematic examinations of an information system or product intended to, among other things, determine the adequacy of security measures and identify security deficiencies. These eight programs experienced fewer increases in planned program costs and fewer schedule delays relative to the programs that did not report using cybersecurity vulnerability assessments.

脆弱性のテストをしているプロジェクトが8/15あって、脆弱性テストをしているプロジェクトの方が、開発遅延やコスト増が少ない感じみたいですね。。。

GAOのこの強力な監査能力が結果的に政府の力を強めているのかもしれないと思うようになってきました。。。

2021/01/18

2021年のサイバー脅威、「Nデイ脆弱性」とは!?(転載)


2021年のサイバー脅威、「テレワークの一般化」と「既知の脆弱性」がカギに:

トレンドマイクロは12月22日、脅威動向を予測したレポート「2021年セキュリティ脅威予測」を公開しました。あわせて公式ブログ記事も公開しています。

2020年は、新型コロナウイルス感染症(COVID-19)の拡大により、業務形態、流通網、生活様式など、世界中で幅広い変化が発生しました。サイバーセキュリティにおける脅威も、そうした変化で発生した隙をつくように、さらに巧妙さと危険度が増しています。

こうした背景から「2021年セキュリティ脅威予測」では、まず「自宅のテレワーク環境がサイバー攻撃の弱点になる」「テレワーク用企業向けソフトウェアやクラウドアプリケーションの深刻な脆弱性が狙われる」といった可能性を指摘しており、脆弱なホームネットワークから従業員の自宅のコンピュータを乗っ取って組織ネットワークへ侵入する事例などが予想されています。他方で、既にインターネット上では、脆弱性の影響を受ける特定のVPN機器のリストも公開されており、該当する組織での早急な対応が求められています。

また「新型コロナウイルスに便乗する攻撃キャンペーンの継続」「医療機関が直面するセキュリティリスク」も予測されています。2020年に日本国内では、マスク不足に便乗した偽の通販サイトや偽の給付金の申請サイトなどが確認されました。今後も、感染状況やワクチン関連の情報に偽装した不正サイトや不正メールが横行すると考えられます。一方で、医療機関やワクチン開発関連組織への諜報活動が懸念されます。

そして、サイバー攻撃に悪用される脆弱性(セキュリティ上の欠陥)において、ベンダからの修正プログラム(パッチ)提供などの対応策がない「ゼロデイ脆弱性」だけでなく、修正プログラムが提供されているものの、公開されたばかりでパッチが適用されていない可能性がある既知の脆弱性「Nデイ脆弱性」がより一層問題になると予測されています。

「2021年セキュリティ脅威予測」では、その他にも以下のようなトピックを解説しています。

・攻撃者はホームオフィスを新たな犯罪拠点に

・テレワークの導入によって企業はハイブリッド環境と持続困難なセキュリティアーキテクチャに直面

・外部からアクセス可能なAPIが企業の情報漏えいの攻撃経路に

・パンデミックで進む個人情報の収集と共有に注目するサイバー犯罪者

・セキュリティ強化の推進

「2021年セキュリティ脅威予測」(PDFファイル)は、トレンドマイクロの公式サイトから無償でダウンロード可能です。

バックアップ(非公開)

2021/01/17

「Origami Pay」システム停止までを説明したブログエントリが貴重な記録だと評判(転載)~貴重な”しんがり”ネタ~


「Origami Pay」システム停止までを説明したブログエントリが貴重な記録だと評判【やじうまWatch】:


2020年はメルペイEngineeringチームとして業務しながら、一方で年初からOrigami PayというQRコード決済サービスの提供終了に伴うシステム停止業務を計画・実行してきました。サービスの終わらせ方について詳しく説明されることは中々ないと思ったので、本投稿では決済という外部影響が大きい種類のサービスを終了するにあたり、どのような検討がなされたのかを事例としてお伝えできればと思います。

取り組んだこと

 
決済サービスはお支払いを行う一般のお客さま・お支払いを受け付ける加盟店様・システム連携している金融機関様やパートナー様など多くのステークホルダーが存在します。また店頭でのお支払い方法をご提供するという性質上、突然のサービス終了は関係する方々のビジネスに直接的・間接的に大きく影響する可能性もあり、慎重にすすめる必要があります。

今回システム停止を計画するにあたり、下記の要件が存在しました。

  • お客さま・加盟店様・その他パートナー様への影響を出来る限り小さくするために、十分な事前告知と準備期間を経てサービス終了を行うこと。
  • 障害・不正利用等のシステムリスクを出来るだけ小さくすること。
  • サービス終了までのシステム維持コストを出来るだけ小さくすること。
当初から少なくとも半年以上はかかるプロジェクトとなることが見込まれていたため、複数フェーズに分けて段階的に機能を停止していく基本方針を置きました。 対外アナウンスや機能停止は一度行ってしまうと後戻りできないため、下記のように事前計画を入念に行いました。以下ではそれぞれの項目について紹介していきます(便宜上ステップのように順番に記載していますが、実際は途中段階で新しい事実が発覚して前段階に巻き戻ったりといったことを繰り返しながら計画を作っていきました)。

  1. 外部へ影響を与える機能・業務の特定
  2. 法務・コンプライアンス要件の特定
  3. サービス終了計画の作成
  4. システム停止計画の作成
  5. 計画に沿ったシステム停止と影響確認

1. 外部へ影響を与える機能・業務の特定 

サービスを段階的に停止していくにあたり、外部への影響度・内包されるシステムリスク・維持コストなどの観点から機能や業務を分解していきます。

今回Origami Payサービス終了を計画するにあたり洗い出した機能・業務の一例は以下のようなものです。

  • バーコード提示型のインタフェースによるお支払い
  • QRコード読み込み型のインタフェースによるお支払い
  • クレジットカードを利用したお支払い
  • 金融機関口座連携を利用したお支払い
  • ウォレット機能を利用したお支払い
  • 加盟店様による返金・金額変更
  • 加盟店様によるお支払い履歴確認
  • 加盟店様への売上金振込
  • 一般のお客さまからのお問い合わせ対応
  • 加盟店様からのお問い合わせ対応
機能・業務をどこまで細かく分解するかは、「停止タイミングが異なるか」を軸として行いました。例えばOrigami Payではクレジットカードを使ったお支払い方法と、金融機関口座を紐付けたお支払い方法が提供されていましたが、両者では不正利用リスクが異なるために「加盟店でのお支払い」と一括りにするのではなく個別に停止スケジュールを検討することとしました。

2. 法務・コンプライアンス要件の特定

サービスの特性によっては法務・コンプライアンス観点からサービス終了の進め方に要件が存在する可能性があります。

Origami社では資金移動業・第三者型前払式支払手段発行者・電子決済等代行業・クレジットカード番号等取扱契約締結事業者といった各種業法への登録や、PCI-DSSへの準拠を行っていました。 各事業廃止にあたり、リスク管理体制の維持や消費者保護の観点等から法務・コンプライアンスチームと連携して1で特定した機能・業務に抜け漏れがないか、またそれぞれを停止するにあたり注意を要する点がないか密に連携しながら要件を洗い出しました。 例えば資金移動業を廃業するにあたってはお預かりしている残高をお客さまに確実にお返しするために、メール連絡・ウェブサイト告知や官報掲載などのコミュニケーション計画が求められます。

3. サービス終了計画の作成

1で特定した機能・業務それぞれについて停止日・事前告知日等を定めていきます。

法務・コンプライアンス要件を満たすことは当然ですが、外部ステークホルダーの皆様との調整観点で営業・事業開発チームと、社内業務との調整観点でオペレーションチームやコーポレートチームと協力しながら計画していった結果、下図のような9ヶ月にわたるスケジュールが出来上がりました。


細かく全スケジュールに触れていくことは難しいので、システム停止に影響が大きいマイルストーンだけ下記にまとめます。

2020/2 ウォレット機能によるお客さま間送金の停止
2020/3 ウォレット機能によるお支払い停止
2020/4 クレジットカードによるお支払い停止・バーコード提示型のお支払い停止
2020/6 一般のお客さま向けサービスの停止・お客さま向けアプリの配信停止
2020/9 加盟店様向けサービスの停止・加盟店様向けアプリの配信停止

支払い手段ごとに細かく停止時期が異なっていますが、前記のようにシステムリスクや不正利用リスクを早期に小さくしていくことと、外部影響を鑑みて早期に機能を閉じられるかといった現実性をあわせて検討した結果、このように支払手段ごとに段階的な停止を行うこととしました。また、一般のお客さまによる利用が終わった後も返品等による返金・金額変更等が発生する可能性を考慮し、新規のお支払い停止から90日間のバッファ期間を経て加盟店様向けサービスの停止を行うこととしました。

機能の停止とその告知以外にも考慮すべきことはこのタイミングで洗い出します、一例として、広くサービス終了告知を行う際にはそれに便乗したフィッシング詐欺等が発生するリスクもあり、その対策として不正ログイン・不正取引の自動検知・監視体制強化も計画していきました。

4. システム停止計画の作成


サービス停止計画から各フェーズで停止できるサブシステムを特定し、システム停止作業のスケジュール・内容を計画します。

Origami PayはAWS上に構築されたバックエンドシステムとiOS, Android向けに提供されているお客さま向け・加盟店様向けモバイルアプリで構成されていました。バックエンドシステムはウェブアプリケーションの改修でリアルタイムに機能停止を行えますが、モバイルアプリは新しいバージョンをアプリストアに登録しても大多数のお客さまが最新バージョンにアップデートいただくまでにタイムラグがあります。今回はバックエンド側のフラグに合わせて各停止フェーズ向けの画面・挙動に切り替えられる仕掛けを内包したバージョンを事前にアプリストア上で配布し始めておくことで、実際の機能停止タイミングで表示をスムーズに変更する下準備を行いました。

AWS上に存在する内製システムを停止していくことに加えて、システムと接続されている外部サービスや、業務で利用しているクラウドサービスについて利用停止・契約解除タイミングも計画します。 各フェーズで停止する機能から不要となる関連サービスを特定していくのですが、それに加えて最終的にはすべての外部サービス利用が漏れなく終了している必要があります。年次の外部サービス棚卸しが終わった直後だったこともあり、外部サービス台帳を出発点として、各サービスの停止計画を作りました(参考までに下図がOrigamiで作成していた台帳のサンプルになります)。


内部システムと外部サービスの停止計画が決まったら、それをもとにサービス終了までのシステムコストの大まかな見積もりを行います。 AWS環境については構成変更によるコスト推移を完全に予想することが難しいのですが、Billing and Cost Managementを使うことで過去の請求実績の細かい内訳(サービス別・サイズ別・リージョン別など)が分析できるため、そこから各フェーズにおけるシステム停止後のコストを見積もりました。

5. 計画に沿ったシステム停止と影響確認


4のスケジュールにそって機能停止を行います。完全なサービス停止以前では一部機能のみを停止することになるため、予期せぬ影響がでた場合に備えて作業手順を細分化し、切り戻し手順を用意して実施します。数人でダブルチェックを行いながら作業をすすめる必要がありましたが、結果的に関係者が自発的に多く集まったこともあり盤石な体制で多くの作業を進められました。

停止作業・インフラ整理を行った後は数日間AWSコストの監視を行います。システム停止計画で事前に想定していた水準まで日次コストが下がっているかを確認し、想定したコスト減が達成されていない場合は要因を調査・解消します。 Cost Explorerを用いると日次コストのサービス内訳が確認できるので原因分析をしやすくなります。ECS・EC2・RDSなどのComputing / Database系コストは予測しやすいですが、Networking / Governance系等はコスト予想が難しく、目標コストを達成するためにフェーズごとの追加調整なども行いました。

下図が実際にサービスを運用していたAWSアカウントのコスト推移です。全機能の提供を終了したのは9月、そのインフラ整理を行ったのが10月なので11月にコストが大きく下がっていますが、その途中経過でもほぼ事前計画どおりの水準までコストを削減できました。事前にコスト計画を定めて進めたことで金銭的なコストを抑えられたことも勿論ですが、管理すべきリソースが減り、結果的にシステムリスク低減・人的な運用負荷の軽減にもつながりました。


6. (おまけ) Twitterをエゴサしてエモい気持ちになる

まったく余談ですが、事前告知でお支払い機能が停止される日時までお伝えしていたこともあり、停止前後はTwitter検索すると感想や思い出を投稿してくださった方もいらっしゃいました。中には、サービスが止まる直前を狙って記念決済をしてくださっているツイートなどもあり気持ちが温まるタイムラインを眺めながらシステム停止を行っていたりしました。

さいごに


これだけ慎重に時間をかけてサービスを終了していくという経験は初めてだった為、計画段階も実施段階も途中過程でいろいろな学びがありました。しかしそれでも運営してきたサービスを終了するというのは決して楽しい話ではなく、最後まで一緒にがんばってくれた関係者の方々には感謝してもしきれません。 サービス終了なんて頻繁に立ち会うことではないかもしれませんが、本投稿が将来そんなタイミングを担当される方の参考になれば幸いです。

私自身も含め、今回サービス終了を一緒に進めてくれたメンバーも参画してメルペイでは日々サービス開発を進めています。ミッション・バリューに共感できるエンジニアリングマネージャー・エンジニアを募集していますので、一緒に働ける仲間をお待ちしております。

【参考】

2021/01/16

ZOZO、全社にパスワード管理ツール「1Password」導入(転載)~1Passwordの企業への導入事例は珍しいかも~


パスワード管理ツール1Passwordの全社導入から運用まで - ZOZO Technologies TECH BLOG:


 パスワード管理ツールの必要性


パスワード管理の基本は、強固なパスワードを作成し使いまわしせず、なるべく漏洩しないようにすることが挙げられると思います。ありがちなものとしては、以下のような方法があります。

  • 付箋や紙に書いて管理
  • PCのメモ帳で管理
  • Excelで管理
  • ブラウザに保存

ですがセキュリティや管理・運用のしやすさを考えると、上記の方法よりも専門ツールであるパスワード管理ツールを利用する方が優れています。

「パスワードなんてブラウザに保存できるからそれで事足りる」と思う方もいらっしゃると思います。しかし会社としてパスワード管理の基盤がないと、チームごとに管理方法が違ったりパスワードの共有に平文が用いられてしまったり様々なリスクが生じます。

パスワード管理ツールは、便利なだけではなくそういった問題を解決できるので、利用者側、管理者側ともに非常に有益なものと言えます。


パスワード管理ツールの選定


パスワード管理ツールは色々あります。

  • 1Password
  • LastPass
  • パスワードマネージャー
  • Keeper
  • True Key
  • Dashlane
  • Bitwarden

ざっと調査しただけで、上記が挙げられます。

上記の全てを比較したわけではありませんが、どれも基本的な機能としては大差ありません。例えば下記のような機能があります。

  • 複雑なパスワードの自動生成
  • ID・パスワードの自動入力
  • パスワードの強度や使い回しのチェック
  • 多要素認証
  • ID・パスワードの共有

強度の高いパスワードを生成でき、利用者は自身のマスタパスワードだけを覚えれば他のパスワードを覚える必要がなく、保存された情報は暗号化され安全に共有できます。もちろんパスワード以外のセンシティブな情報も保存できます。パスワード管理ツールはそのような機能を備えたツールです。


1Passwordの優位性


弊社では主に以下の点で、1Passwordを採用するに至りました。


Secret Keyの仕組みがある


1Passwordにはマスタパスワードに加えてSecret Keyがあり、たとえマスタパスワードが漏洩したとしても、Secret Keyを知らなければアクセスできません。マスタパスワードはデバイス上のデータを保護し、Secret Keyはデバイスからデータを保護してくれるとのことで、この二段構えの構成は安心できます。


グループ単位で管理できる


ビジネスプラン以上ではユーザグループを作成できます。グループにユーザを追加し、グループを保管庫(Vault)に紐付けることで権限付与が可能です。


CLI(コマンドライン)ツールがある


1Passwordにはコマンドラインツールがあります。コマンドラインツールに対応していることは、運用の自動化を考慮する上で重要な要素と捉えています。

例えば以下のようなことができます。

# ユーザ招待
op create user <メールアドレス> <氏名>
# ユーザの停止と再開
op (suspend | reactivate) <user>
# ユーザ削除
op delete user <user>
# 一覧取得
op list (users | groups | vaults | items | documents | templates) [--vault <vault> | --group <group>]


レポーティング(パスワード漏洩チェック)機能がある


1Passwordにはドメイン侵害レポートがあります。自社が管理するドメインを登録しておくと、漏洩に巻き込まれたアドレスを見つけることができます。このレポートを元にしてパスワードの変更をユーザへ促すことができます。


導入にあたっての課題


課題は大きく3つありました。

  • プランの検討
  • SSO(シングルサインオン)が可能か
  • プロビジョニングが可能か

プランの検討


1Passwordのビジネス向けプランは3つあります。
  • Teams
  • Business
  • Enteprise
結論から言うと弊社はBusinessプランを選択しました。

Teamsプランでは、詳細な権限管理ができないため、全社的に導入するとなると機能不足でした。

Businessプランでは、より詳細な権限管理からログ管理やレポート閲覧まで豊富な機能を備えているため、SaaS製品としての機能が十分であると判断しました。また、Azure Active Directory、Okta、OneLoginと連携できるのもこのプラン以上になっています。弊社としては、グループで管理できることが運用上大きなメリットでした。ユーザ単位で権限管理をするのは運用が煩雑になると思います。

Entepriseプランでは、上記の機能に加えて専用窓口を設けてくれたり、導入にあたりトレーニングを受けられるなどのメリットがあるそうです。ですが弊社ではそこまでのサポートは必要なく、Businessプランで利用できる機能さえあれば十分でした。

SSO(シングルサインオン)が可能か


弊社のシステム選定基準では、基本的にSSOが利用できるシステムを選定しています。しかし、1Passwordの仕様上SSOは不可でした。SSOできないことは利用者目線に立つとある程度の不便さはあります。ですが1Passwordの認証の堅牢性の土台となっているSecret Keyの有用性とのバランスを考慮して、SSO不可であることを許容しました。

プロビジョニングが可能か


プロビジョニングを行うためには1Password SCIM bridgeを構成する必要があります。
  • Google Cloud Platform Marketplace
  • Docker, Kubernetes or Terraformで構築
SCIM bridgeサーバを構築するために、主要なクラウドサービスにおいて試算を行いました。しかし、現状ではコストメリットが無さそうだったためプロビジョニングの導入は一旦見送りました。会社の規模拡大に合わせ、再度検討したいと思っています。プロビジョニングの代わりに、前述のコマンドラインツールを活用し運用することにしました。

実際の運用


全社導入前に一部の部署で1Passwordを先行利用していたのですが、その時はグループを利用しておらずユーザを保管庫に直接割り当てる運用をしていました。しかしこれでは統一性もなく管理が煩雑だったため、グループベースで管理するように運用を変更しました。ユーザからの利用申請も、kintoneを用いたワークフローで管理し、保管庫とグループの一覧はスプレッドシートにて管理することにしました。

スプレッドシートで管理した理由は2つあります。

1つはグループや保管庫、グループ内メンバーの一覧と、グループがどの保管庫と紐付いているかをユーザが確認できるようにするためです。ワークフロー申請時にどのグループの権限を変更するかなどを記載してもらう際に必要な情報だからです。

もう1つは各保管庫の運用管理者を把握し、ワークフローにおける承認ルートにその保管庫の運用管理者を入れるためです。1Passwordの管理者からでは、各保管庫が実際にどういった使われ方をしているのか分かりません。そのためメンバー追加などの依頼時に各保管庫の運用管理者の承認を確実に得た状態で、管理作業を行っています。

導入効果


パスワード管理の理想的な運用基盤を構築できたことが大きな効果でした。人に依存した運用ルールで安全にパスワードを管理することは限界があります。パスワード管理ツールを用いることで、半強制的にガイドラインに沿った運用へ切り替えることができました。また冒頭で記載した通り、パスワードを平文で保存することはセキュリティリスクになります。そのためパスワードを暗号化できるパスワード管理ツールは、セキュリティの監査に対する解決策の1つとしても有効です。

分かりやすい効果としては以下のようなものがありました。

共有アカウントのパスワードを安全に共有できる


様々なパスワードを覚える必要がなくなり、パスワードジェネレータによって強力なパスワードの生成が容易になりました。例えば自分が共有しているパスワードを変更したとしても、1Password上のパスワードさえ更新されていれば、他の人に新しいパスワードを都度共有し直す必要はありません。利用者は自分のマスタパスワードだけを覚えていればよく、パスワードが変更されたことを知らずともログインできるからです。

また、セキュアにID・パスワードの共有が可能になり、閲覧権限の範囲をコントロールし易くなりました。例えば範囲がチームをまたぐような場合でも、専用のグループを作って該当者を入れてそのグループに保管庫の閲覧権限を割り当ててあげればよいわけです。

多要素認証のワンタイムパスワードの代替


さらに便利だと思ったのは、多要素認証で使用するワンタイムパスワードを1Password上に保存できることです。Authenticator系のアプリと同じように秘密鍵を1Passwordに保存することで、1Password上にワンタイムパスワードが表示されるようになります。


通常、多要素認証ではSMS(ショートメッセージサービス)やAuthenticator系のアプリでワンタイムパスワード(認証コード)を得るため必ずモバイル端末が必要になってしまいます。多要素認証を1Password上に保存すれば端末に縛られない運用が可能になります。

具体的な手順を解説します。

  1. まずは設定したいシステムの設定画面で、多要素認証の追加(もしくは変更)を実行し、その手順の中で秘密鍵を取得

    Authenticator系のアプリで読み取るためのQRコードが発行される画面などで、秘密鍵を表示できる箇所があると思いますので調べてみてください。※各システムによって異なります

  2. 秘密鍵を入手したら1Passwordのアイテム編集に移動

  3. 1Passwordのアイテム編集画面でラベルの欄にある…(三点リーダー)アイコンを選択


  4. ワンタイムパスワードを選択


  5. ワンタイムパスワードの欄に、先程入手した秘密鍵を貼り付けて保存

以上の手順でワンタイムパスワードが表示されるようになりました。元の秘密鍵を入手した画面(手順1)に戻り、6で表示されているワンタイムパスワードを入力して認証し作業は完了です。

まとめ・残課題


実際に導入してみて、パスワード管理ツールに慣れていないユーザからはいまいちよく分からないツールだと思われてしまう印象がありました。そのためマニュアルとは別に使い方を解説する動画を制作し、ユーザがより理解しやすいように工夫しました。

パスワード管理ツールは入れて終わるツールではありません。例えばパスワードをブラウザへ保存してるユーザに対して1Passwordへの移行を促す必要があります。また、ドメイン侵害レポートをチェックし、漏洩したパスワードを使用しているユーザにパスワードの変更を呼びかけることも重要です。活用方法や正しいパスワードの管理方法などは都度啓蒙していく必要があると感じています。

2021/01/15

telnetは暗号化できる!?


 telnetは認証情報含めて平文で通信されるため、今ではケシカラン行為の代名詞的なものになっている、、、はずだった。

ところが、最近、telnetが暗号化に対応しているらしい。

詳しくは下記の動画(35:00周辺)参照。


当然普通に使っただけでは暗号化されるわけはなく、オプションを使う。

例えば、Ubuntuにはtelnet-sslという実装があるようで、こういったパッケージを使う。

【普通のtelnetのキャプチャ】


【暗号化されたtelnetのキャプチャ】


今でもたまに「telnet使いたいんですけど」っていう問い合わせがまれにある。

今後は下記のような対応を心掛けたい

×:telnetは問答無用でダメです

〇:telnet-ssl等で通信が暗号化されるならOKです。


【参考】

telnetは通信を暗号化できる…らしい

現代のTelnetは暗号化できる



2021/01/14

FireEye Red Team のツールに対する不正アクセスに関して~CommandoVMとは~



概要

国家支援を受ける高度な技術を持つ攻撃者が、FireEyeがRed Teamに用いるツールを窃取しました。攻撃者はこれらのツールを所有していると考えており、また攻撃者が盗んだツール自体を使用したり公開したりするかどうかは不明であるため、FireEyeはこのブログをもって数百もの対策を公開し、多くのセキュリティコミュニティがそれらのツールから自らを保護できるようにしました。私たちはFireEye製品にもその対策を反映させ、パートナーである政府機関とこれらの対策を共有し、攻撃者がRed Teamツールを悪用する可能性を大幅に制限しています。

これらの対策のリストは、FireEyeのGitHubリポジトリにて公開されています。

Red Teamのツールとテクニック

Red Teamとは、可能性のある攻撃者による攻撃や情報窃取を模倣して企業のセキュリティ体制を評価する、セキュリティ専門家からなる組織化されたグループです。当社のRed Teamの目的は、攻撃が成功した場合の影響を実証し、防御体制 (Blue Teamなど) が運用環境でそれらに対抗する方法を示すことによって、企業のサイバーセキュリティを向上させることです。当社は、世界中のお客様に対して15年間にわたりRed Teamアセスメントを実施してきました。その間、私たちはお客様のセキュリティ体制改善に役立つスクリプト、ツール、スキャナ、テクニックを開発してきました。残念ながら、今回これらのツールが攻撃者の窃取の対象となりました。

盗まれたツールには、探査の自動化に使用される単純なスクリプトから、CobaltStrikeやMetasploitなどの一般的に利用可能な技術のようなフレームワーク全体に至るまでさまざまです。Red Teamツールの多くはすでにコミュニティにリリースされており、オープンソースの仮想マシンであるCommandoVMで配布されています。

一部のツールは、基本的なセキュリティ検知メカニズムを回避するために修正された公開ツールです。その他のツールやフレームワークは、Red Team用に社内で開発されたものです。

ゼロデイ攻撃や未確認技術は含まれず

窃取の対象となったRed Teamツールには、ゼロデイ攻撃ツールは含まれていませんでした。対象となったツールは、世界中の他のRed Teamも使用している、既知かつ文書化された手法を適用したものです。これらの盗まれたツールが攻撃者の総合的な攻撃能力の進歩に大きく寄与するとは考えていませんが、FireEyeは万が一の自体に備えて、できうることをすべて行っています。

FireEyeは、攻撃者によるこれらのツールの拡散や利用を確認しておりません。また、セキュリティ・パートナーとともに、今後も活動を監視し続けます。

検知技術の提供でコミュニティを支援

組織的にこれらのツールを検知していくための支援として、ツールが実際に使用された場合、それを見分けるために役立つ対策を公開しています。今回のRed Teamツールの窃取の対応として、OpenIOC、Yara、Snort、ClamAVなど、一般に利用可能な技術に対する数百の対策をリリースしています。

FireEye GitHubリポジトリにてその一覧を公開しています。新たな検知技術や、すでにリリースされている検知技術の改善が行われるごとに、公共レポジトリにおけるホスト、ネットワーク、ファイルベースのインジケータなどの対抗策をアップデートし続けます。さらに、GitHubページでRed Teamツールの効果を制限するために対処する必要があるCVEのリストを公開しています。

FireEye製品による顧客保護

FireEyeは、チーム一丸となって、お客様と広範なコミュニティを保護するための対策の構築に取り組んできました。これらの対策を製品に取り入れ、国土安全保障省などのパートナーと共有し、製品に対策を取り入れ、広くコミュニティに対応しています。

利用可能な検知シグネチャの詳細については、GitHubリポジトリを参照してください。

バックアップ(CommandoVM)

2021/01/13

実企業におけるサイバーセキュリティというのは、アドホックに臨機応変に構築するのが難しく、決められたプロセスに従って時間をかけてちょっとずつ改善と変化を積み重ねていくしかない(転載)


ポーランドのエキスパートに聞く「社員のスキル向上に投資したら、学ぶだけ学んで転職してしまうではないか」 (1/2) - ITmedia エグゼクティブ:

 この連載では、海外のサイバーセキュリティ分野の友人にインタビューする形で、サイバーセキュリティのエキスパートがどのように育ってきたのか、サイバーセキュリティはなぜ難しい課題なのか、企業がサイバーセキュリティと向き合う上でどういったことが重要なのかなどさまざまな考え方を紹介しています。

海外エキスパートインタビューシリーズ第3回は、ポーランドの友人パウエル・ヤツェヴィッチ(Pawel Jacewicz)の話を紹介します。

 海外のサイバーセキュリティ友達の中でも、ポーランド人は何名かいるのですが、「ポーランドにはサイバーセキュリティの専門家が育ちやすい事情があるのではないか」と個人的には考えています。

 パウエルに会ったのは、ポーランドの首都ワルシャワに訪れた際、国立研究所のリサーチプロジェクトの紹介を彼がしてくれたときのことでした。彼は話をするのが大好きなので、プロジェクトの説明を延々としてくれて、いつまでたっても話が終わらないので、彼の上司に中断されていたのが印象に残っています。それ以来、ポーランドに行ったときや、彼が来日したときには一緒に食事をしています。

では、内容に入ります。(元のやりとりは英語で行われていますが日本語に意訳しています)

筆者 パウエル(以下P)、今日はありがとう。まずは簡単に自己紹介をお願いします。

P 私の名前はパウエル・ヤツェヴィッチです。現在はスタンダードチャータード銀行のグローバル・サイバーセキュリティ・センターで働いています。サイバー脅威のハンティングを主な仕事にしており、銀行のサイバーセキュリティの中でも、サイバー攻撃の予兆などをプロアクティブに発見する仕事を主にしています。他にもいろいろな仕事はしていまして、人材育成や、内部むけのコンサルティング、自分の能力開発、新たなITの学習なども行っています。

筆者 ありがとうございます。これまでに、どのようにITやサイバーセキュリティを学んできたか教えてください。

P 自分は小さい頃から、モノがどのように作られているのか、どのように動くのかといったことに興味を持っていました。このスタンスは自分の職業人生のなかでも非常に重要な意味を持っていると思います。

 私がサイバー空間で冒険を始めたのは、1990年代後半に初めてPCを手にして、56kのモデム(筆者注:その昔、電話回線を利用してインターネットに接続するときに利用していたデバイスのことです)でインターネットに接続するようになってからです。インターネットに触れはじめて、書籍や友人達からは得られないほど膨大な知識を得られるようになったことに驚きました。

 時間をかければかけるだけ急速にいろいろなことを学びました。特に力を入れたのは、コンピュータやネットワークがどのような仕組みで動いているのかということですが、そのなかでもLinuxを使い始めてからDebianに恋に落ちました(筆者注:DebianとはLinuxディストリビューションの一つで、どちらかというと玄人に好まれる傾向があるように思います)。

 サイバーセキュリティに関わるようになったのは2009年からで、その年からポーランドのナショナルサートであるCERT.PL(筆者注:日本におけるJPCERT/CCのポーランド版です)働き始め、結局8年間そこで勤めました。サイバーセキュリティの仕事に深く関わることで、ネットワークセキュリティやサイバー攻撃の検知などかなり詳しく学ぶことになります。

 その間、世界中のセキュリティカンファレンスに参加し、サイバーセキュリティ業界で最も輝いている人たちに会うことができました。そういった経験が、自分の今の専門性を維持したり継続的に学び続けたりする姿勢を作り上げてくれました。

 CERT.PLの次は、ポーランド最大手の銀行のインシデントレスポンスチームで働き始めました。そこでは、企業におけるセキュリティ対策はどのようなものか、金融業界がサイバー攻撃の脅威とどのように向き合っているかを学ぶことになります。

 リアルタイムで起きている攻撃がどのようなものかを知りましたし、また実企業におけるサイバーセキュリティというのは、アドホックに臨機応変に構築するのが難しく、決められたプロセスに従って時間をかけてちょっとずつ改善と変化を積み重ねていくしかないということも学びました。

 銀行を辞めた後、いわゆるBig4と呼ばれる大手コンサルティング会社のインシデントレスポンスチームに加わりました。そこでは、大企業も中小企業もそれぞれの悩みをもってサイバーセキュリティの対策に取り組んでいることを知りました。

 大企業は既に構築されたサイバーセキュリティの取り組みを改善する方法を模索していますし、中小企業はごくごくわずかなリソースでサイバーセキュリティという強大な敵にたちむかうにはどうしたらよいのかということに悩んでいました。そこでの経験で、ポーランドにおけるサイバーセキュリティの課題は何かを深く学ぶことができました。

 今のスタンダードチャータード銀行に転職したのは2019年のことです。非常に優秀なサイバーセキュリティチームのメンバーたちと共に働くことができて大いに満足しています。

筆者 サイバーセキュリティをよりよいものにするためには何が重要でしょうか?

P 一昔前のサイバーセキュリティは誰にも注目されず、いわば会社の地下で何をやっているのか誰も知らないような仕事でした。誰にも邪魔されず自分たちの好きなことをやっていられたのです。

 けれども、今は社長をはじめ役員もサイバーセキュリティに意識を向けるようになり、ウイルスとはなにか、サイバー攻撃とはどういうものか、ランサムウェアとは何か、データが漏えいしたらどのような影響があるのか、といったことを日々聞いてくるようになりました。

 今日、サイバーセキュリティは望むとも望まずとも、全ての人の生活に深く浸透しています。サイバーセキュリティの課題を長期的に無視していれば、深刻な問題を引き起こすことは間違いありません。これは国という単位でも、企業や個人という単位でも同じ事です。現代の戦争はサイバー空間で発生しています。これは、われわれサイバーセキュリティの専門家が何年も言い続けていることです。

 これから来るであろう攻撃に備えて、企業はサイバーセキュリティに投資しなければなりません。特に重要なのは、「自社のネットワークやシステムで何が起きているのか」を知ることです。

 何か攻撃が起きていることを見つけた場合、企業は積極的に攻撃に関するデータを他社と共有すべきです。これがいわゆるインテリジェンスといわれているものです。これによって、同じ攻撃が大規模に成功することを防ぐことができますし、被害の範囲を最小化することができます。データの共有は非常に重要なのですが、法律や規制などが原因で難しい場合もあります。法律や規制は刻一刻と変化する脅威に適合し続けることが難しいのです。

 企業では、インシデント対応とモニタリングを所管するブルーチームの運営が一般的になってきました。そこに、脅威ハンティングのチームを加え、サイバー攻撃の予兆を早期に発見するようになり、さらに企業の防御システムを実際に攻撃することによってテストするレッドチームも加わってきています。

 最近ではパープルチームとしてブルーチームとレッドチームのせめぎ合いを調整する取り組みも見られます。このような取り組みはとても効果的ですが、中小企業が自力でやるにはコストがかかりすぎます。

 中小企業でサイバーセキュリティの専門スタッフを抱えられるところはごく限られています。現実的には、そういったところは外部のコンサルタントに依頼して、セキュリティサービスを購入しています。

 しかし私見を述べると、それは長期的な観点で効果的とはいえません。なぜならば、内部のスタッフが能力を身につけて、自社内でできるようになったほうが費用対効果の観点で効果が高いからです。もちろん短期的に問題を解決したい場合は外部のコンサルタントは非常に有効ですが、長期的な視点で捉えたときには違うと考えています。

 私が最初の銀行に勤めていたとき、常に外部のコンサルタントを活用していました。しかし、コンサルタントが何をしているのかを学び、その能力を時間をかけて身に付けることで、内製で実施できるようになり、結果的に外注コストが大幅に下がったという経験があります。

 私が推奨したいのは、業界ごとに固まって、監督官庁が主導する形で企業間の実務的な演習を企画、実施する方法です。そうすることで中小企業でもスタッフの教育を効果的に行うことができるでしょう。

 世の中では机上演習がよく行われています。机上演習は組織の意思決定の訓練にはなりますが、実際に手を動かして作業する人たちの訓練にはなりません。具体的にどんな作業をどのようにするのか、どういった環境や機材が必要なのかということを知る機会が必要です。 

 また、本番では絶対にできない「実験的に試す」といったことができるのも演習の良いところです。もちろん、机上演習は経営層など組織上層部むけの意思決定の訓練にはとても有効ですので、机上演習と実務的な演習を組み合わせて行うことが効果的でしょう。

筆者 サイバーセキュリティの仕事をしてきた中で特に印象に残っている出来事を教えてください。

P 私がポーランドの銀行業界で働くようになってからすぐに、業界全体を巻き込む歴史的なサイバー攻撃が発生したことによって業界全体が大混乱に陥る様子を目の当たりにし、業界横断的な協力関係の構築が不可欠だと実感しました。

 それは2017年の始め頃に発生した攻撃です。ポーランドの金融規制当局のWebサイトが改ざんされ、いわゆる水飲み場攻撃によって、ポーランド国内の多くの銀行の社内ネットワークでのマルウェア感染につながったものです。これは、現在に至るまでポーランドの銀行業界にとって最も深刻なものです。この攻撃が明らかになったのは、とある銀行の社内ネットワークでマルウェアの活動が発見されたことがきっかけでした。

 当初は誰も金融規制当局が関係していることなど考えもしなかったのです。そして何週間も気付かないまま攻撃は進展していきました。私は自分が勤めていた銀行の社内ネットワークを監視していて、不審な兆候を発見しました。

 社内にはネットワークやシステムのセキュリティ監視システムがしっかりと入っていたので、挙動をトレースすることで原因を突き止めることができました。社内ネットワークでマルウェア感染が明らかになり、それが金融規制当局のWebサイトからもたらされたものであることが判明したときは本当に驚きました。

 銀行というのは通常巨大な組織であり、こういった攻撃の分析を1人で行うのは不可能で、チームで仕事をする必要がありますし、社内外に多くのステークホルダーがいる状況です。分析には膨大な時間がかかるため、外部のリソースから協力を得る必要もあります。組織を越えて協力し合うことの大切さ、観測できたデータを共有することの大切さ、それがあって初めてインシデント対応は成功するということを、この事案対処の経験を通じて学びました。

 繰り返しになりますが、助け合うことやチームワークは非常に重要で、他の何にも代えがたい価値があります。ポーランドの金融業界のサイバーセキュリティコミュニティーでは、この攻撃は歴史上最悪なものだったけれども、業界として協力し合うことの必要性を気付かせてくれた最も価値のある事案でもあったと、現在でも話題になります。この事案を繰り返さないようにという思いで、われわれはサイバーセキュリティ能力の向上、サイバーレジリエンスの強化に取り組んでいます。

筆者 企業の役員はサイバーセキュリティについて、どの程度、どのようなことを理解しておくべきだと思いますか?

P サイバーセキュリティは投資であるという認識を持つべきです。企業活動は利益を上げることがメインです。そんなことは誰でも分かっています。企業の役員は、サイバーセキュリティチームは企業の目的や目標を達成するために必要不可欠な支援をしてくれていると考えるべきです。

 企業でサイバーセキュリティの仕事をする人たちの知識や能力は、どんなセキュリティ製品でも、サービスでも、監査でも得ることのできない貴重なものです。その企業のネットワークやシステムのことを隅々まで知り尽くしている人は社外にはいません。サイバーセキュリティの仕事をする人たちの能力に投資することは、企業がサイバー攻撃の被害を受ける可能性を低減することへの投資です。

 ある企業の役員が「社員のスキル向上に投資したら、学ぶだけ学んで転職してしまうではないか」と言ったことがありました。それに対して私は「人材のスキルに投資しなければ、何も学ばない人たちがずっと社内にい続ける、ということではないでしょうか?」と答えました。

 企業における一般社員はいわゆる一線の防御を担う役割がありますが、実際には彼らがもっとも狙われやすいポイントでもあります。一般社員がサイバー攻撃の最新の脅威のことを考えてくれなければ、到底企業全体を守り続けることは不可能です。世の中には無料で得られるサイバーセキュリティの情報ソースがたくさんあります。一般社員にも分かりやすいように解説されている記事もあります。そういった情報を共有するなど小さなことから始められる取り組みもあり、その積み重ねが未来の自社を守ることに繋つながるのです。

 従業員の一人がうかつにメールの添付ファイルをクリックしてランサムウェアに感染して、何億円もの身代金を払う事を考えたら抜群のROIだ、というのが私の意見です。

※筆者注:金融業界でよく使われる考え方にThree Lines of Defenseという三線防御でリスクコントロールするというコンセプトがあります。一線で一般社員が業務執行部門としてリスクオーナーとして対処する、二線でサイバーセキュリティを含むリスク管理の専門部署がリスクに対処する、三線は監査の観点でリスクに対処するという考え方です。

筆者 これからサイバーセキュリティを学ぼうと思っている人たちにアドバイスはありますか?

P 伝えたいことが3つありますが、その前にサイバーセキュリティはとてつもなく巨大なフィールドです。サイバーセキュリティの分野では、誰もが自分に向いている仕事を見つけることができるでしょう。

 それを踏まえた上で、1つ目に大事なのは何にでも興味を持つことです。そうすることで自分に適した仕事がどれなのかを発見することができます。

 2つ目に大切なのは壊してしまうことを恐れない。何かを深く知りたいと思ったら、それを分解して元に戻すということは仕組みを学ぶ上でとても大切です。誰かがやった記事を読んだりするだけではなく、自分の手でやらなければ理解することはできません。そのようなスタンスで学び続けることを楽しんで、同じような考え方をしてくれる仲間を見つけることも大切です。自分でやってみることで、他の人の経験からも理解することができます。

 3つ目に大切なのは、夢中になれることをやっている間は、体中の血液の巡りがよくなってずっと起きていられます。それは要するにあなたに向いている仕事だということです。

 今回はポーランドの友人、パウエルの話を紹介しました。公的な立場のセキュリティ専門機関から銀行へ転職し、そのあとコンサルタントへ転職、その後銀行に再び転職という経緯をへた彼ですが、実はいつか日本で働きたいという思いを持っています。

 来日したときに国内企業との面談をアレンジしたこともあるのですが、うまく折り合わず彼の希望は実現していません。今回の彼の話では、私もよく質問を受けるセキュリティの内製化に関して一つの考え方を提示してくれていると思います。

 また、セキュリティが好きでセキュリティの仕事をしている人たちがどういったメンタリティなのかということについてもその一つの姿を提示してくれています。

2021/01/11

不動産ブツ上げ業者の営業電話撃退法

最近どこかから個人情報が漏れたらしく、不動産営業の電話が会社にかかってくるようになった。

営業電話撃退法を調べていたらいろいろ勉強になったので、ちょっとメモ。

■一般的な営業電話撃退法

まず、「不在」とかでその場をやり過ごすのはNGらしい。

正しい撃退法法は、

1.定番ワード「恐れ入りますが、どのようなご用件でしょうか?」を言う。

営業電話なので、当然営業の話になる。

2.下記のいずれかを言う。

① 「申し訳ありませんが、一切お断りするようにと言われておりますので・・・」
② 「弊社は、新規のお取引を控えさせて頂いております。」
③ 「必要な場合はこちらからお電話しますので、今後のご連絡は不要です。」

終わり。

営業マンは「かしこまりました、失礼いたします。」で終わるらしい。

なるほど。

■不動産投資営業撃退法

不動産投資営業の場合、宅地建物取引業法が絡んでくる。この法律では、宅地建物取引業者(不動産業者)に対し、契約の締結の勧誘をするに際しての「電話による長時間の勧誘その他の私生活または業務の平穏を害するような方法によりその者を困惑させる」行為を禁止しています。

つまり、これをネタに逆に「電話してくるな」と営業にお灸をすえることができる。

ただ、いきなりお灸をすえるのはかわいそうなので、順を追って進めていくこととなる。

【STEP1.注意】

下記2点を伝えます。

1.全く興味がない

2.もう二度と勧誘電話を掛けてこないでほしい

【STEP2.警告】

下記3点を実施します。

3.会社名、代表者名、担当者名、会社の所在地、電話番号、勧誘があった日時をメモ、(勧誘)内容の確認。

 ※偽名名乗っている可能性もあるので、一度折り返しにしたほうが良いかも!

4.宅地建物取引業法違反に当たる勧誘行為であることを指摘する

5.自分に対する勧誘行為を止めないと監督官庁に相談する

【STEP3.タレコミ】

下記2点を実施します。

6.会社名、代表者名、担当者名、会社の所在地、電話番号、勧誘があった日時をメモ、(勧誘)内容の確認。

 ※偽名名乗っている可能性もあるので、一度折り返しにしたほうが良いかも!

7.宅地建物取引業者(不動産業者)が東京都知事免許業者であれば東京都(住宅政策本部)へ連絡。

【2021年1月11日追記】
昨年STEP1を終えてしばらく静かになったので安心していたら、2021年1月8日にまた。掛かってきた。

前回は「売却の意思はない」と明確に伝えたので、今回は「次掛けてきたら監督官庁に報告する」と告げた。(STEP2の実施)

次掛かってきたらSTEP3の実施となるが、折り返しにしないといけなかったり、代表番号にしないといけなかったり結構面倒くさい。。。


国別の人気度やカテゴリー別の検索に焦点を当てた、ソーシャルメディアプラットフォームの検索に焦点を当てた新しいOSINTツール / [#OSINT Tool] We're excited to release a new FREE tool to the community that focuses on searching across global social media platforms based on popularity by country, or by category (using @WebBreacher WhatsMyName list) for non-mainstream platforms(転載)

Eo1vxKZVQAAYZhd.jpg:large
technisette retweeted: [#OSINT Tool] We're excited to release a new FREE tool to the community that focuses on searching across global social media platforms based on popularity by country, or by category (using @WebBreacher WhatsMyName list) for non-mainstream platforms osintcombine.com/world-social-m…:
technisette retweeted:
[#OSINT Tool] We're excited to release a new FREE tool to the community that focuses on searching across global social media platforms based on popularity by country, or by category (using @WebBreacher WhatsMyName list) for non-mainstream platforms

osintcombine.com/world-social-m…


2021/01/10

管理者用初期化URLを踏んでWebサービスのデータをふっとばした話~rmコマンドで削除しても復旧することは可能かも_φ(。。;)メモメモ~


管理者用初期化URLを踏んでWebサービスのデータをふっとばした話 - Qiita:

背景

私の(当時所属していた)部署では、毎年、数週間かけて前年の各人の業務実績をとりまとめて一つの冊子(PDF)にするという仕事があり、この作業を少しでも自動化するため、Webサービスが内製されました。当初は単純に各ユーザが自分の業務実績一覧をテキストで用意してアップロードするというものでしたが、秘伝のタレのように毎年少しずつ改良されたり、大幅に作り直されて別システムから業務データを取り込んでからブラウザ上で編集できるようになったりしつつ、なんやかんやあって私が引き継ぎます。他にやりたい人もなく、ひとり鯖管です。OSはCentOS6でした。

このシステムでは、毎年新しいデータを編集するため、その作業開始時にデータを初期化する必要があります。この作業も自動化し、管理者権限でログインして管理者ページ(ここでは https://hoge.example.com/kanri としましょう)から起動できます。危険な作業なので、初期化しようとすれば警告が表示される仕様です。

そもそもWebサービスに初期化などという機能なんてと思われるかもしれませんが、そこは内製のシステム。前年の編集データはほんとうにまったく不要なので、単純に初期化する実装になっています。さらに後述しますが、問題の本質は初期化とは無関係です。

事故

何をした(つもり)か

各ユーザに依頼していた数週間の編集作業の第1回目の期限が過ぎ、アクセスも落ち付いたころ、管理者ページに一気に行きたかった私は、ブラウザのアドレスバーに kanri と打ち込み、閲覧履歴から目的のURL https://hoge.example.com/kanri を探してちゃちゃっと開きました。

何をやらかしたか

すると、管理者ページを開いただけのはずなのに、期待に反して、初期化が完了したことを表すページが表示されました。

まさかと思いつつ、アドレスバーを確認すると https://hoge.example.com/kanri/init のURLがありました。閲覧履歴にあった管理者ページではなく、その隣の初期化ページを開いてしまっていました。ユーザに編集作業を依頼する前に初期化をしていたので、それが閲覧履歴にあったわけです。出てほしい警告は一切出ませんでした。

やらかしたと悟りました。ユーザは200人弱、みなさん極めて多忙、そんな中で時間を割いて集中的にやってもらった作業をすべてパーにしたというわけです。大規模な商用サービスに比べれば微々たるものですが、ユーザのみなさんに同じ作業をまたやってもらわなければいけないかもというプレッシャーで胃が痛みます。

何が消えたのか

このWebサービスではDBは使用せず、データはすべて特定のディレクトリにあるユーザごとのサブディレクトリに、複数のファイルに分けて置かれていました。このデータ用ディレクトリを確認しましたが、初期化したのですから当然もぬけの空です。その当時は内部の初期化コードまで承知していませんでしたが、ようはrmで大量のファイルとディレクトリを削除したということです。

応急処置

あわてない

あわててはいけません。まずは落ち付きます。今なら「全集中、鯖の呼吸」とつぶやくべきところです。たぶんサーバと一体化し、最善の一手となるキーに一筋の光が見えます……(知らんけど)

閑話休題。削除してしまったファイルを回復させるための最善策を考えます。

ユーザによる編集作業はほぼ一段落していて数日前のバックアップはあるにはありましたが、戻してしまうと、その間に誰が編集したかつきとめて個別に依頼していく手間と精神的負担がかかります。バックアップを戻すのは最後の手段とします。

ですが、最後の手段はある。これは気分として重要です。

データ保全

初期化がrmであったことは幸いです。truncateなどしていればどうなっていたことか。UNIX系は昔から使っているし、i-nodeを中心としたファイルシステムの概略も把握しているし、rmしてもファイルがすぐには消えないことも知っていますが、ほっておくと消えていくので時間との戦いです。このへんはどんなOSでも同じでしょう。とはいえ、リモートサーバなので下手にシングルユーザモードなどにしてネットワークアクセスができなくなると困ります。幸いこのサーバは他の用途で使っていないので、httpdを含む不要そうなサービスをすばやく止め、ディスクアクセスを最小限にします。

次に、ファイルシステムをこのままいじっていくわけにいかないので、どこかにファイルシステムのイメージを置いてゆっくり作業したいところです。このサーバにはメインのファイルシステムが一つしかないので、イメージを一時的にも同じサーバ内には置けません。sshできる方向はローカルからサーバのみ。ddはroot権限がいる。最短時間で。ということで、sshdのPermitRootLoginをyesにし、rootのパスワードはさすがに使いたくなかったので気休めですがuid=0の別アカウントを急遽用意して、このアカウントでローカルからddしました。今にして思えば、デバイスのアクセス許可を自分に出すだけでもよかったですね。

local# ssh uid0@hoge.example.com dd if=/dev/hogeroot ibs=1M >hoge.img

これも幸いですが、このファイルシステムは16GBほどしかなく、25分ほどでイメージの転送が完了しました。やらかして、45分後です。

さらに、このファイルは原本として死守する必要があるので、別の作業用ファイルにコピーしておきます。

local# cp hoge.img hoge.wrk

ファイル回復

ここからは腰を据えて作業できます。

まずは、ext4のファイルシステムでrmしてしまったファイルをどう回復すればよいか、ググります。出てきた https://www.no-title.com/linux/extundelete で、extundelete というコマンドがあることを知り、インストールします。指定したファイルシステムから指定したパスのファイルを回復するようです。

local# apt install extundelete

次に、ddしたファイルシステムイメージに対してどうすればファイルシステムとしてアクセスできるか、ググります。出てきた http://ng3rdstmadgke.hatenablog.com/entry/2016/10/06/064434 によれば、ファイルをループデバイスとして設定してやればマウントもできるようです。loop14 は適当です。他のが使われていたようなので、使われていない最小の番号にしました。マウントは作業には不要ですが、ファイルシステムが認識されているかの確認用です。

local# losetup /dev/loop14 hoge.wrk
local# mount -o ro /dev/loop14 /mnt

これら、参考にした平易な記事を書いてくださっているみなさんには感謝です。

さて、準備はできました。extundeleteは動くでしょうか。とりあえずパスのすぐわかる出力先PDFを指定して試します。

local# extundelete --restore-file /var/www/hoge/data/20xx/hoge.pdf /dev/loop14
...
Unable to restore inode 915251 (var/www/hoge/data/20xx/hoge.pdf): Space has been reallocated.
...

Unable...、だめなのか。reallocated...、もう上書きされたのか。遅かったのか。

他のファイルも試します。多数ありますが、パスは機械的に生成されるので、その一覧を生成して一気に与えました。

local# extundelete --restore-files /tmp/filelist.txt /dev/loop14
...
Successfully restored file /var/www/hoge/data/20xx/....
Successfully restored file /var/www/hoge/data/20xx/....
Successfully restored file /var/www/hoge/data/20xx/....
Successfully restored file /var/www/hoge/data/20xx/....
...

すごい。Successfully!! じゃんじゃん回復して RECOVERED_FILES というディレクトリに作成されていきました。ごく一部に回復できなかったファイルが報告されましたが、これも幸いなことに、手動で回復できるものでした。

復旧

実際には、ほかにいくつもリストからもれたファイルやリンクなどがあったのですが、それらも手作業で回復できました。あとから落ち付いてマニュアルを読むと --restore-directory というオプションがあり、こちらの方が断然楽ができたみたい。

最後にファイルをサーバにコピーし、祈りながら各サービスを復帰させたところ、件のWebサービスがやらかし前のまま無事に動作していることが確認できました。安堵しました。

例のURLを踏んでから復旧完了まで約6時間で済み、最初の編集作業が終わった時期だったのでサーバの停止に気づいたユーザはごく少数です。ましてや、裏でこんなことがあったと知っている人はいません。

原因と対策

何が問題だったか

そもそも、初期化のページに行くには警告が出るはずでした。しかしそれが出ず、閲覧履歴から開くだけで初期化されてしまったのが問題です。

なぜそんなことが起きたか、みなさんはもう想像がついていることでしょう。

それは、初期化ページのURLをGETメソッドで叩くだけで、初期化が行われる仕様だったせいです。管理者ページからそのリンクをクリックしたときだけ、 onclick で confirm() を呼んで警告を出すしくみでした。閲覧履歴からそのページを開けば、 confirm() など実行するはずもなく、GETメソッドでいきなり叩いてしまい、初期化が実行されてしまったわけです。

再発しないための対策

あたりまえですが、Webサービスの内部状態を変化させる処理は、GETメソッドで起動してはいけません。Webサービスの初期化も当然内部状態を変化させます。例のリンクが、formのボタンにもなっていないただのリンクであるところで気付いて修正しておくべきでした。ボタンでもGETを使っていれば同じですが。

対策としては、POSTメソッドでアクセスしたときだけ初期化するように変更しました。初期化した結果は常に同じで羃等性があるので、DELETEを使うという手もあったかもしれません。

CSRFに関する追記(2020/12/9)

この記事に直接だけでなく、はてなブックマークやTwitterでも多数のコメントをいただき、ありがとうございます。その中で特にCSRFに関して強く言及いただきました。CSRFについては無対策であったため、本記事をそのままなぞって、GETをPOST等に修正しさえすればOKとされてしまわないよう、追記します。

GETの場合はCSRF以前の話で、自分ひとりで勝手にやらかしてしまいます。POST等にすればいわゆる自爆はなくなるのですが、URLを知っている攻撃者がPOST等のリクエストを生成するリンクやボタンを設置し、被害者がログイン状態でそれを踏むと、そのリクエストを実行してしまうというCSRF攻撃が成立してしまいます。重要な処理(商品購入や送金、メールアドレス変更、Webサービス初期化:sweat_smile:、等)の最終確定時にCSRF対策が必要です。

本件のような内部利用システムでは、CSRF対策はRefererチェックという簡便な方法ですむことも多いと思われます。不特定多数が利用する商用システムでのCSRF対策には、きちんとセッションを管理し、最終確定前のページでセッションIDなどのトークンを埋め込んで、最終確定ページでトークンを確認してから処理を実行するのが一般的です。セッション管理にはノウハウが多数あるようで、独自実装よりもフレームワーク利用がよいかもしれません。これらの詳細は徳丸本などをご参照ください。

結論

やらかしてしまったものの、次のような幸運が重なり、最小限の影響だけで復旧できました。

  • アクセスのほとんどない期間だった。
  • rmによるファイルの単純な削除だった。
  • サーバが他の用途に使用されていなかった。
  • ファイルシステムが小さく短時間でイメージが転送できた。
  • SSDではなくHDDだった。

大事なことなのでもう一度言います。Webサービスの内部状態を変化させる処理は、GETメソッドで起動してはいけません。

現在の自分はわかっていても、過去の自分も含めてみんながそう実装している保証はありません。「GET POST 使い分け」みたいなキーワードで検索して上位に出てくる解説Webページでも、このことにちゃんと触れているものはかなり少ないようです。特に、完全な「初期化」は普通のWebサービスにはなかなか存在しない処理ですし、パラメータも必要ないので、GETで実装してしまうというミスがあっても不思議ではありません。管理者用の機能の実装は手を抜きがちですが、前任者のコードも自分の過去コードでさえも信用せず確認する習慣を忘れずに。