総務省：サイバー攻撃（標的型攻撃）対策
防御モデルの解説
soumu.go.jp/main_content/0…
【転載】総務省：サイバー攻撃（標的型攻撃）対策 防御モデルの解説
総務省：サイバー攻撃（標的型攻撃）対策
防御モデルの解説
soumu.go.jp/main_content/0…
派遣エンジニアが起こした事件が理不尽だった件（転載）～いろいろな意味で〇ソだなと思った。派遣もシステムもプロパーも会社も、、、。～
どもども。僕はしがない派遣エンジニアです。
某零細企業から、某大手企業に派遣されています。
派遣先はお堅い職場です。
コロナのご時世ですが、リモートの「リ」も聞いたことありません。
万が一、データー漏洩した場合とんでもないことになりますからね（しらんけど
そんな職場ですが、わたくしは２年ほど勤めています。
お堅い職場ゆえに息苦しさもありますが、それが心地よかったりもします。
というよりも派遣という気軽な身分が合っているのかもしれません。
さて本題に。
こんな職場へ、新しい新人さんが入ってきました。
新人といっても50代のベテランエンジニア、Ａさんです。
もちろん派遣です。
Ａさんはどうにも「優秀ではないエンジニア」のようでした。
かろうじてプログラミングはできるけど、IＤＥの使い方、フレームワーク等はほとんど経験がないご様子。
何でもかんでもプロパーさんに聞いて回るので、「そんなことくらい自分で調べて！」と怒られていました。
確かにネットで調べれば済むことです。
Ａさんはそんな感じの方です。
で、案の定。
着任して3日でドキュメント整理という名の戦力外通告をされていました。
そんな時、事件は起こりました。
会社の役員様から「こんなメールが届いたけど、どうしたらいいの？」とシステム部門に連絡があったのです。
それは決算に関わる重要なメールだけど、身に覚えがないのだそうです。
私のチームがその担当システムだったため、すぐに調査をしました。
その調査中にも、ほかの役員様から「なんだこのメールは？」と問い合わせが入ります。
チームは慌てふためきます。
時間が経つにつれ、経理部のプロパーの方々が駆けつけ、システム部長、経理部長まで駆け付け、一大事になったのは、社内事情に詳しくない僕から見ても明らかでした。
「原因はまだわからんのか！！？」
原因究明は長引きました。
というのも。
その決算プログラムは、15年前に作られたＰＨＰプログラムで、度重なる改修の結果「よくぞここまで！」というくらいのスパゲッティになっていたからです。
社内にシステムの詳細を知る人間はおらず、ドキュメントも歯抜け状態。
プログラムを追うしかない状態でした。
操作ログもほとんどないシステムだったため、難航しました。
チームの派遣３名＋プロパー1名は、徹夜で調査。
その結果、１つの仮説が導き出されました。
「あいつがバッチを起動させたのでは？」
「あいつ」というのは、例のベテラン新人エンジニアＡさんです。
翌日、出勤してきたＡさんは問い詰められました。
もちろんＡさんは否定しました。
「私はまだ着任したばかりで、そんなことできっこない」と。
確かにその通りです。
「これをクリックしただろ？」
と、プロパーさんは画面の秀丸を指さしました。
それはシステムのドキュメントでした。
その中に、１つのＵＲＬが書かれていました。
プロパーさんはそれを指さしました。
「あぁー、押したかもしれませんね・・・」
そのＵＲＬは、決算システムの年次バッチを臨時に走らせる大変恐ろしい物だったのです。
しかも2005年の。
Ａさんはプロパーに激詰され、システム部門の臨時会議で罵倒され、経理部門でも罵倒され、役員の方々への謝罪行脚に出かけていきました（プロパーさん、システム部長、経理部長を伴って
Ａさんはまだ帰ってきません。
僕はＡさんになんて声をかければいいのでしょうか？
そもそもＡさんのどこに非があったのでしょうか？
Ａさんが支給されたパソコンの秀丸は、ワンクリックでUＲＬを開くようになっていました。
問題のバッチＵＲＬは、パスワードも必要なく。
もし誰かに非があるとするならば、秀丸ではないかと思うのです。
■追記
Aさんが罵倒された緊急会議でのこと。
僕はAさんを「凄い人だ・・・」と思いました。
「なんでこんなことしたんだ！」
「どうするつもりだ！」
と、激詰めされているにも関わらず、淡々と回答していたからです。
Aさんはとてつもない強靭な精神力を持つ人でした。
想像してみてください。
コロナにも関わらず、200人以上が常駐している広いフロアの真ん中にあるミーティングスペースで、多くの人がチラ見する中で罵倒される姿を。
会議の出席者の大半が敵であり、仲間であるはずの僕たちは、火の粉が降りかかるのを恐れて何も言えず、たった一人で戦わなくてはいけない状況を。
こんな恐ろしいことはありません。
「どうするんだ！！！？」
「どうやって収めるつもりなんだ！？」
「問題のデータはすでに特定しているので、すぐに修正できるかと・・・・」
「そういうことを聞いてるんじゃない！！！」
システム部長とプロパーさんでそんなやり取りがあった後、
「ご迷惑をおかけした方々に、私が直接謝罪します」と、Aさん。
「えっ・・・、おぅ・・・、それもいいかもな・・・」と、システム部長。
緊急会議はいったん解散し、部長会議が開かれたようで。
その後、Aさんが呼ばれ、謝罪行脚に出かけたのでした。
--
↓の動画の最後のコメントがすごくイイ
ロシアで宅配便ロッカーを強制解除するサイバー攻撃が発生 / Hacker opens 2,732 PickPoint package lockers across Moscow（転載）
謎のハッカーがサイバー攻撃を利用して、モスクワ中の2,732個の宅配ロッカーのドアを強制的に開けました。
12月4日（金）午後に発生したこの攻撃は、モスクワとサンクトペテルブルク全域で8,000件以上の荷物ロッカーのネットワークを維持している地元の宅配サービス「PickPoint」のネットワークを標的にしています。
ロシア人はオンラインで商品を注文し、注文した商品を自宅の住所ではなく、PickPointのロッカーに届けることを選択できる。
荷物が届くと、ユーザーは電子メールやモバイル通知を受け取り、PickPoint アプリを使って注文を取りに行くことができる。
しかし、ユーザーがロッカーを開けて荷物を受け取ることができる同じシステムが金曜日に攻撃を受けました。
未だ特定されていないエクスプロイトを使って、謎のハッカーが PickPoint のロッカーの 3 分の 1 のドアを強制的に開け、モスクワ全域で数千個の荷物が盗難にさらされました。
攻撃の理由はまだ判明していないが、週末のプレスリリースで、ピックポイントは当局に通知したと述べた。
ロシアの同社は現在、攻撃で被害を受けたネットワークの復旧作業を行っているという。
また、ロッカーから荷物が盗まれたかどうかも不明のままだ。ソーシャルメディアの投稿によると、警備員や家主は金曜日に素早く介入し、明らかに故障しているロッカーへのアクセスを制限した。
同社が土曜日のプレスリリースで強調しているように、これは "ポストゲートウェイネットワークに対する世界初の標的型サイバー攻撃 "であるようです。
【転載】パッチマネジメント とは？方法や必要性、注意点について徹底解説
IT企業に限らず、ビジネスでは多くのコンピュータが使われています。そのコンピュータの管理にかかせないのが「セキュリティパッチの更新」です。
セキュリティパッチとはコンピュータに存在する脆弱性を解消するプログラムのことです。マルウェアの感染やセキュリティホールを悪用したサイバー攻撃を防ぐためには、適切なセキュリティパッチの適用が欠かせません。
今回はセキュリティパッチの更新を管理する「パッチマネジメント」について紹介します。
パッチマネジメントとは
パッチマネジメントとは、システムを構成しているコンピュータを管理して、脆弱性が発見されたときに適切にセキュリティパッチを適用させるための管理活動のことです。
セキュリティパッチはコンピュータに見つかった脆弱性を解消するために使用するプログラムです。ソフトウェアの中には、新しいセキュリティパッチが公開されたとき、ソフトウェアアップデート機能により自動的に更新するものもありますが、一部のコンピュータには、手動によるセキュリティパッチの適用が必要なものもあります。
しかしパッチマネジメントの導入により、セキュリティパッチの適用を効率的に漏れなく実施できます。それにより、コンピュータの脆弱性を確実に解決し、不正アクセスやマルウェアの感染のリスクを低減させられるのです。
2018.4.21
パッチマネジメントの方法
パッチマネジメントは具体的には以下の3つの流れで進めます。
検知
脆弱性情報を公開しているWebサイトから、自社のシステムに関係のありそうな脆弱性情報を集めます。脆弱性情報の情報源には、具体的には以下のようなものがあげられます。
| 業界団体 | IPA（情報処理推進機構） JPCERT/CC JVN iPedia NVD |
|---|---|
| 有識者（専門家） | Twitter ブログ その他SNS |
| ベンダ（製品メーカー） | 各ベンダのWebサイト 情報配信サービス プレスリリース メールマガジン |
情報源としては上記3つがあげられますが、これらの情報を取りまとめているニュースサイトもあります。これらの情報を全て追いかけるのは手間がかかるので、自社で使っているソフトウェアや製品に関連する情報だけでも効率良く収集するように工夫しましょう。
判断
自社に関係のある脆弱性が判明したら、そのリスクの大きさと攻撃を受ける可能性を判断して、対策の緊急度と必要性を決定します。
脆弱性の緊急性の判断には「CVSS」を基準に考えるのが一般的です。
自社においても脆弱性の深刻度を決定する基準として、CVSSのような指標を使い、あらかじめレベルごとの対応方針を決めておけば、迅速な対応が可能です。
対応
対策方法と対策時期を決めて、脆弱性を悪用したサイバー攻撃が発生する前に、脆弱性のリスクをできるだけ小さくします。しかし複数のシステムが混在している環境の場合、適切に対応されているのか把握しきれないことがあります。
そうならないためにも、複数のシステムを構築する際に、できるだけ共通の基盤を持つサービスを利用することがおすすめです。クラウドサービスの中には、パッチマネジメントの一連の手順を総合的に管理できるものも登場しています。
パッチマネジメントの必要性
包括的なパッチマネジメントを実施する必要性として、以下の2点があげられます。
脆弱性を悪用した攻撃を防ぐ
適切なパッチマネジメントにより、OSやアプリケーションソフトウェアにセキュリティパッチを適用することで、脆弱性を悪用した攻撃を防げます。
コンプライアンスを確保する
セキュリティパッチを適用しないと、コンピュータがマルウェアの感染するリスクが高まります。さらにマルウェアに感染したコンピュータから機密情報や個人情報が流出することで、社会的信用を失いことにもなりかねません。
パッチマネジメントを含めた情報セキュリティ対策は、コンプライアンスを確保する活動とも言えます。自社内のシステムの危険箇所を特定して、不正アクセスや改ざん、マルウェアの侵入を未然に防ぐことで、顧客情報や機密情報を守りことができます。パッチマネジメントは、情報保護ポリシーの実践や法令順守の活動の一環と言えるでしょう。
パッチマネジメントの注意点
パッチマネジメントの必要性はご理解いただけたかと思いますが、実際にはセキュリティパッチの適用が難しいケースもあります。特に以下のような場合は注意が必要です。
システムが多い場合注意
業務で使用しているシステムの数が多い場合、それら全てに対して適切にパッチマネジメントを行うことは困難でしょう。そもそも大規模なシステムの場合、システムで動作しているコンピュータの数ですら、把握できていないこともしばしばあります。また複数の種類の異なるコンピュータが混在している場合は、適用させるセキュリティパッチも異なるため、パッチマネジメントを効率的に行うことが難しくなります。
レガシーシステムに注意
古いソフトウェアで動作しているレガシーなシステムにも注意が必要です。レガシーシステムでは、アップデートのサポートの期限切れや、アップデートできない可能性があります。レガシーシステムといえ、現役で使われていることもあり、簡単には新しいシステムに代替できないこともあります。
パッチテストが必要
最新のセキュリティパッチでも、実際に適用させる前には十分なパッチテストが必要です。しかしそのパッチテストを実施するコンピュータの選定や、業務に影響が発生しないようにテストの時間帯などの調整も必要です。
組み込みシステムに注意
機能が限定された組み込みシステムは、全体を動作させているシステムの一部として動作していることがあります。そのような組み込みシステムは365日24時間動作させていることもあり、停止させてセキュリティパッチを適用させることが困難です。またそのような長期間動作している組み込みシステムは、古いOSが搭載されている可能性もあります。
未知の脆弱性に注意
セキュリティパッチは既知の脆弱性を解消するプログラムです。そのため未知の脆弱性を解決することはできません。未知の脆弱性が知れ渡り、その脆弱性に対するセキュリティパッチが完成するまでには時間がかかります。
まとめ
脆弱性対策にかかせないセキュリティパッチの適用を効率的に実施する、パッチマネジメントについて紹介してきました。
企業内で稼働しているコンピュータの数が多くなってくると、それらを効率的に管理するにも工夫が必要です。パッチマネジメントのために高いコストを投資して、包括的に管理できるシステムを構築できれば理想的ですが、そうは言っても予算をかけられない企業もあるでしょう。
そのような状況でも、自社にとって重要な情報やデータを把握し、システムのクリティカルな箇所から段階的にでもパッチマネジメントを進めていくことがおすすめです。ベンダが提供しているツールなどを有効に活用して、賢くパッチマネジメントを導入しましょう。
「EXILE TRIBE」の公式通販サイトでクレカ情報流出～想定損害賠償額は11億円程度か～
「EXILE」や「三代目J SOUL BROTHERS」など、LDH JAPANに所属するアーティストのグッズを扱う公式オンライン通信販売サイト「EXILE TRIBE STATION ONLINE SHOP」が不正アクセスを受けたことがわかった。
同サイトを運営するLDH JAPANによると不正アクセスにより、8月18日から10月15日までの約2カ月間、決済処理を行うプログラムが改ざんされたほか、個人情報を含むサーバに対してもアクセスを受けた形跡が見つかったもの。
同サイトではクレジットカード情報を保持していないが、期間中にクレジットカード情報を新規に登録したり、変更を行った場合、第三者に情報を窃取されたおそれがある。
4万4663人分のクレジットカード情報が外部に流出した可能性があり、名義や番号、有効期限、セキュリティコードが含まれる。さらに11月27日の時点で、このうち少なくとも209人分のクレジットカード情報が不正に利用をされた可能性があるとの報告をクレジットカード会社より受けたという。
またログファイルの調査により、クレジットカード情報以外の個人情報が格納されたサーバについても不正アクセスを受けていたことが判明した。流出件数などは特定できなかったとしている。
【転載】脆弱性探しはハッカーが頼り バグ報奨金制度、新型コロナ対応が普及後押し～日本企業ではトヨタ自動車、任天堂などが活用～
自社のソフトウェアやシステムの脆弱性を発見する手段として、社外の善玉ハッカーに頼ろうとする企業が増えている。脆弱性を見つけて報告してくれた研究者などに賞金を贈呈する「バグバウンティープログラム」の制度を導入する企業が相次ぎ、Googleなど早くからこうした制度を活用していた企業は賞金額の引き上げに動く。背景には新型コロナウイルス感染拡大の影響もあるようだ。
各国の企業と組んでこうした制度を支援してきたHackerOneがこのほどまとめた統計によると、2020年4月までの1年間でバグバウンティープログラムを通じて発見された脆弱性は20万件を超え、ハッカーに支払われた賞金の総額は、上位10種類の脆弱性の合計で2350万ドル（約24億円）に上った。
脆弱性の種類別に見ると、支払われた賞金の総額が最も多かったのは、前年に続いてクロスサイトスクリプティング（XSS）の脆弱性だった。
XSSはWebアプリケーションを脅かす脆弱性で、悪用されればユーザーのアカウントを制御され、パスワードや銀行口座番号、クレジットカード番号などの情報が盗まれることもある。この脆弱性に対して支払われた賞金の総額は420万ドルと、前年比で26％増えた。
深刻度で分類すると、XSSは一般的に、高～中程度に分類される脆弱性。1件当たりの賞金は平均で501ドルと、最高レベルの脆弱性の3650ドルに比べてかなり安い。「つまり組織は、このよくありがちな、痛みを伴うバグを安上がりに緩和できている」（HackerOne）
こうした脆弱性の発見を外部のハッカーに頼るやり方が改めて注目されるようになったのは、新型コロナウイルスの影響でデジタルトランスフォーメーションが加速したことも一因だとHackerOneは解説する。
「自分たちのリソースを補うための手早くコスト効率が高い解決策として、ハッカーの力を借りるセキュリティ対策への関心が高まり、予算が縮小する中で結果に対して対価を支払うアプローチが正当化しやすくなった」
新型コロナウイルスの影響は、バグバウンティー制度に詳しい別の専門家も指摘している。
2012年からこうした制度を推進してきたBugcrowd創業者のケイシー・エリス氏は、threatpostのインタビューの中で、 「外の世界のセキュリティ専門家の助けを借りることに対して、企業の抵抗感が少なくなった」と語る。
同氏によると、新型コロナ対策としてテレワークを余儀なくされたことで、組織内に物理的に存在していない人物に協力してもらうやり方が、企業にとって受け入れやすくなった。外出や通勤時間が減って自由に使える時間が増えた若者などが、賞金稼ぎに時間をかける傾向も見られるという。
Zoomのようなデジタルプラットフォームに対してはセキュリティ強化圧力が強まり 相次ぐ問題が発覚したZoomは、4月にバウンティープログラムの強化を発表した。中国ByteDance傘下のTikTokは米政府との対立が深まる中で、10月にHackerOneと組んでバウンティープログラムを立ち上げた。
ただし制度を導入しても利用してもらえなければ意味はない。脆弱性情報を闇サイトで売った方が稼げるのであれば、そちらに流れるハッカーもいるかもしれない。そこで早くからバウンティープログラムを導入しているGoogleなどは、インセンティブを高める狙いで賞金の額をどんどん引き上げている。Facebookは常連ハッカーをランク付けして貢献度に応じてボーナスを上乗せする制度「Hacker Plus」を導入した。
消極的だったAppleも、2019年からバウンティープログラムを拡充してiOSやmacOSの脆弱性にも賞金を支払うようになり、賞金の金額も増額した。今年10月には、研究者グループが3カ月で55件の脆弱性を発見し、総額28万8500ドルの賞金を獲得したと発表して話題になった。
ハッカーの力を借りているのはIT企業だけにとどまらない。トヨタ自動車は今年3月、中国Tencent Keen Security Labの報告を受けてレクサス車の脆弱性を修正したと発表した。HackerOneのプラットフォームを利用している顧客は米国防総省やStarbucks、任天堂、Uberなど多岐にわたる。
HackerOneのレポートによると、バグバウンティープログラムを通じてハッカーが受け取った賞金は世界全体で前年より87％増えた。特にアジア太平洋地域は前年比で131％の大幅増だった。Tencentなどの中国勢は、GoogleやAppleといった大手の製品の脆弱性を次々に発見している常連で、この世界での存在感を増している。
■■■■HackerOneのレポート（機械翻訳）■■■■
HackerOne のレポートでは、クロスサイト・スクリプティング、不適切なアクセス制御、情報開示など、最も一般的で影響力のある脆弱性のトップ・リストが明らかになっています。
不確実性の高い時代にあって、セキュリティはこれまで以上に緊急の優先事項となっています。組織はこれまで以上にテクノロジーへの依存度を高めており、テクノロジーに依存している人は誰でもデータ漏洩ですべてを失う可能性があります。しかし、最近の脆弱性の中には、攻撃者のように考えることができる友好的なハッカーによって発見、発見、報告されたという共通点があります。
"今年は、世界中の企業が製品やサービスのデジタル化を余儀なくされました」とHackerOneの製品管理担当シニアディレクターであるMiju Han氏は述べています。"企業は新たな収益源を求めて、ライフスタイルが劇的に変化した顧客のためにデジタル製品を開発しました。何千万人もの労働者が、準備ができているかどうかに関わらず、リモートワークを始めました。このようなデジタルトランスフォーメーションの加速化に伴い、CISO は既存システムのセキュリティを確保しつつ、新たなニーズに迅速に対応しなければなりませんでした。このような障害に直面したセキュリティリーダーは、自社のリソースを増強し、厳しい予算の下でより正当化できる成果報酬型のアプローチを提供するために、軽快で拡張性があり、コスト効率の高いソリューションとして、ハッカーを活用したセキュリティを新たに評価するようになりました。
HackerOneは、業界で最も信頼性の高い脆弱性のデータベースを維持しています。ハッカーが発見した有効な脆弱性は20万件を超え、HackerOneはこのデータを調査して、最も影響力があり、報酬が得られる脆弱性のトップ10のタイプから洞察を導き出しました。
HackerOneが発表した2020年の最も影響力があり、報われる脆弱性の種類トップ10は、降順に以下の通りです。
1. Cross-site Scripting (XSS)
2. Improper Access Control
3. Information Disclosure
4. Server-Side Request Forgery (SSRF)
5. Insecure Direct Object Reference (IDOR)
6. Privilege Escalation
7. SQL Injection
8. Improper Authentication
9. Code Injection
10. Cross-Site Request Forgery (CSRF)
2019年の脆弱性トップ10と比較して今年のトップ10を詳しく見てみると、主な調査結果は以下の通りです。
クロスサイトスクリプティングの脆弱性は、XSS攻撃を悪用した攻撃者がユーザーのアカウントを制御し、パスワード、銀行口座番号、クレジットカード情報、個人を特定できる情報（PII）、社会保障番号などの個人情報を盗み出す可能性があるため、ウェブアプリケーションに対する大きな脅威であり続けています。2年連続で最も表彰された脆弱性であるXSSの脆弱性は、組織の懸賞金総額が420万米ドルに達し、前年比26%増となっています。これらのバグは報告されたすべての脆弱性の18%を占めていますが、平均的な懸賞金はわずか501米ドルです。 重要な脆弱性に対する平均懸賞金が3650米ドルであることから、組織はこの一般的で痛みを伴う可能性のあるバグを安価に緩和していることになります。
不適切なアクセス制御（2019年の9位から上昇）と情報開示（依然として3位をキープ）は依然として一般的です。Improper Access Controlの受賞は前年比134%増の400万ドル強でした。情報開示は前年比63%増と、それに遠く及ばなかった。アクセス制御の設計決定は、技術ではなく人間が行わなければならず、エラーの可能性が高く、どちらのエラーも自動化されたツールを使って検出することはほぼ不可能です。
ファイアウォールの背後にある内部システムを狙って悪用される可能性があるSSRFの脆弱性は、クラウド移行のリスクを示しています。以前は、SSRFのバグはかなり良性で、内部ネットワークのスキャンや、時には内部の管理パネルへのアクセスを許可するだけだったため、7位の座を守っていました。しかし、デジタルトランスフォーメーションが急速に進むこの時代では、クラウドアーキテクチャと保護されていないメタデータエンドポイントの出現により、これらの脆弱性はますます重要になってきています。
SQLインジェクションは前年比で減少しています。OWASP などによって、ウェブアプリケーションのセキュリティに対する最悪の脅威の一つと考えられていますが、SQL インジェクション攻撃の規模は、ビジネス情報、知的財産、重要な顧客データを含む機密データが、これらの攻撃の影響を受けやすいデータベースサーバに保存されているため、壊滅的なものになる可能性があります。過去数年の間、SQLインジェクションは最も一般的な脆弱性の種類の1つでした。しかし、当社のデータによると、2019年の第5位から2020年には第7位まで、前年比で低下しています。セキュリティを左遷することで、組織はハッカーなどを活用して攻撃面を積極的に監視し、バグがコードに侵入しないようにしています。
"最も一般的な脆弱性の種類を見つけることは、安価である "とハン氏は続けた。"賞金を獲得した脆弱性の上位10種類のうち、平均賞金額が10%以上上昇したのは、不適切なアクセス制御、サーバー側リクエストフォージェリ（SSRF）、情報開示のみでした。その他は平均値が低下するか、ほぼ横ばいでした。目標が変化し、攻撃対象が拡大するにつれて、高価で煩雑になる従来のセキュリティツールや手法とは異なり、ハッカーを活用したセキュリティは、時間が経つにつれて、実際にはより費用対効果が高くなります。ハッカーがいれば、悪質な行為者が最も一般的なバグを悪用することを防ぐためのコストが低くなってきています。"
HackerOne Top 10 Most Impactful and Rewarded Vulnerability Types - 2020 Editionの詳細については、https://www.hackerone.com/top-10-vulnerabilities をご覧ください。
Fire Eye のレッドチームツールが盗まれた・・・/ Unauthorized Access of FireEye Red Team Tools（転載）
Fire Eyeのレッドチームツールが盗まれたとFire Eyeのブログで書いていますね。。。
● Fire Eye Blog - Threat Research
・2020.12.08 Unauthorized Access of FireEye Red Team Tools
簡単にまとめてみると・・・
- FBI、マイクロソフト等主要なパートナーと協力して、調査を行っている。
- 国家が資金提供した高度に洗練された攻撃者によるものである。
- 攻撃は斬新な技術が利用されている。
- 攻撃者は、当社が顧客のセキュリティテストに使用している特定のレッドチームの評価ツールを標的にしてアクセスしたことがわかった。
- これらのツールは、多くのサイバー脅威行為者の行動を模倣している。
- これらのツールには、ゼロデイ エクスプロイトが含まれていない。
- コミュニティを保護するという当社の目標に沿って、盗まれた ツールの使用を検出するための方法や手段を積極的に公開している。
- 攻撃者が盗んだツールを利用するつもりなのか、それとも公開するつもりなのかはわからない。
- Fire Eyeは、これらのツールが盗まれた場合の潜在的な影響を最小限に抑えるために、顧客やコミュニティ全体が使用できる300以上の対策を開発してきた。
- これまでのところ、攻撃者が盗んだツールを使用したという証拠はない。
- Fire Eyeは、セキュリティ・コミュニティの他の人々と同様に、盗んだツールを利用した活動がないかどうかを監視していく。
- 盗まれたツールの使用を検出したり、ブロックしたりできる対策を用意している。具体的には、
- 当社のセキュリティ製品に対策を施している。
- セキュリティ・コミュニティがセキュリティ・ツールを更新できるように、これらの対策を共有している。
- 対策は、ブログ記事「Unauthorized Access of FireEye Red Team Tools 」で公開している。
- レッドチームツールの追加的な緩和策については、今後も、公開されたものと直接セキュリティパートナーとの間で共有し、改善していく。
- 攻撃者は国家レベルでのサイバースパイ活動の一環として、主に特定の政府機関の顧客に関連する情報を求めていた。
- 攻撃者はFire Eyeの内部システムの一部にアクセスすることができたが、攻撃者がFire Eyeのインシデント対応やコンサルティング業務から得た顧客情報を保存している主要システムや、ダイナミック脅威インテリジェンスシステムで製品が収集したメタデータからデータを持ち出したという証拠はない。
- 顧客情報が持ち出されたことが判明した場合は、直接顧客に連絡する。
サイバーセキュリティの領域は、人々の生命、財産にも繋がっている問題ですので、ライバルと切磋琢磨することも重要ですが、全体の危機に際しては協力して対応することが重要ですよね。。。
ー以下ブログ原文ー
Overview
A highly sophisticated state-sponsored adversary stole FireEye Red Team tools. Because we believe that an adversary possesses these tools, and we do not know whether the attacker intends to use the stolen tools themselves or publicly disclose them, FireEye is releasing hundreds of countermeasures with this blog post to enable the broader security community to protect themselves against these tools. We have incorporated the countermeasures in our FireEye products—and shared these countermeasures with partners, government agencies—to significantly limit the ability of the bad actor to exploit the Red Team tools.
You can find a list of the countermeasures on the FireEye GitHub repository found HERE.
Red Team Tools and Techniques
A Red Team is a group of security professionals authorized and organized to mimic a potential adversary’s attack or exploitation capabilities against an enterprise’s security posture. Our Red Team’s objective is to improve enterprise cyber security by demonstrating the impacts of successful attacks and by showing the defenders (i.e., the Blue Team) how to counter them in an operational environment. We have been performing Red Team assessments for customers around the world for over 15 years. In that time, we have built up a set of scripts, tools, scanners, and techniques to help improve our clients’ security postures. Unfortunately, these tools were stolen by a highly sophisticated attacker.
The stolen tools range from simple scripts used for automating reconnaissance to entire frameworks that are similar to publicly available technologies such as CobaltStrike and Metasploit. Many of the Red Team tools have already been released to the community and are already distributed in our open-source virtual machine, CommandoVM.
Some of the tools are publicly available tools modified to evade basic security detection mechanisms. Other tools and frameworks were developed in-house for our Red Team.
No Zero-Day Exploits or Unknown Techniques
The Red Team tools stolen by the attacker did not contain zero-day exploits. The tools apply well-known and documented methods that are used by other red teams around the world. Although we do not believe that this theft will greatly advance the attacker’s overall capabilities, FireEye is doing everything it can to prevent such a scenario.
It’s important to note that FireEye has not seen these tools disseminated or used by any adversaries, and we will continue to monitor for any such activity along with our security partners.
Detections to Help the Community
To empower the community to detect these tools, we are publishing countermeasures to help organizations identify these tools if they appear in the wild. In response to the theft of our Red Team tools, we have released hundreds of countermeasures for publicly available technologies like OpenIOC, Yara, Snort, and ClamAV.
A list of the countermeasure is available on the FireEye GitHub repository found here. We are releasing detections and will continue to update the public repository with overlapping countermeasures for host, network, and file-based indicators as we develop new or refine existing detections. In addition, we are publishing a list of CVEs that need to be addressed to limit the effectiveness of the Red Team tools on the GitHub page.
FireEye Products Protect Customers Against These Tools
Teams across FireEye have worked to build the countermeasures to protect our customers and the broader community. We have incorporated these countermeasures into our products and shared these countermeasures with our partners, including the Department of Homeland Security, who have incorporated the countermeasures into their products to provide broad coverage for the community.
More information on the detection signatures available can be found in the GitHub repository.
【転載】「お金を無限に増やせるバグ」を銀行に報告したホワイトハッカーが自身の受けた仕打ちについて解説
「残高をマイナスにしてから帳消しにして無限にお金を増やせる」というバグをJPモルガン・チェース銀行に報告したセキュリティ研究者が報告後に敵対的な仕打ちを受けたとして、「銀行がセキュリティ研究者をどのように扱うのか知っておくべき」と警告を発しています。
傘下の商業銀行であるJPモルガン・チェース銀行にお金の無限増殖バグを報告したのは、セキュリティ研究者のChad Scira氏。コンピューター上で並行して行われる処理のタイミングの違いによって最終的な結果が変化してしまうという現象が生じる「」に関するバグがJPモルガン・チェース銀行のシステムに存在していると知ったScira氏は、JPモルガン・チェース銀行の許可を得た上で複数のアカウントを使って不安定なインターネット環境下でポイントの送付を繰り返すという実験を行いました。
この実験の結果、実験に使用したアカウントの間で、「ポイント残高がマイナスになるまで送付できる」という現象が確認されました。その結果、ポイント残高が512万698ポイントのアカウントと、ポイント残高がマイナス500万ポイントの口座を作成することができたとのことです。500万ポイントは現金に還元すると5000ドル(約52万円)ですが、航空券費用として使った場合には7万6810ドル(約800万円)相当とのこと。
JPモルガン・チェース銀行のアカウントには、「アカウント削除時にはポイントを全額消去する」という仕様が存在しました。この仕様について、「マイナスのポイントも全部消去されるのでは？」とにらんだScira氏が実験を行ったところ、予測通りにマイナスのポイントまで全額消去されたことが確認されました。
さらにScira氏は、丸もうけした512万698ポイントを現金に還元するという実験も敢行。512万698ポイントのうちの500万ポイントを現金化したところ、見事5000ドルに還元されたことが確認され、潜在的に「現金の無限増殖が可能」であることが立証されました。
Scira氏が一連の実験を行った2016年当時はJPモルガン・チェース銀行は脆弱性のを実施していなかったため、Scira氏はJPモルガン・チェース銀行のカスタマーサービスチームの公式Twitterアカウント()に状況を逐一報告しながら実験を進めていました。Scira氏の報告によって一連の問題は修正されたそうですが、報告からおよそ一週間後にScira氏はJPモルガン・チェース銀行から「非常に敵対的なメール」を受け取ったとのこと。
さらに、JPモルガン・チェース銀行はScira氏が同銀行に保有していたプライベートなアカウントを全て削除し、当座預金口座と普通預金口座を全て解約。「あなたのアカウントを削除しました」という手紙を送りつけました。
Scira氏によると、Scira氏だけでなく、Scira氏の家族も口座解約などの仕打ちを受けたとのこと。Scira氏は「銀行が助けてくれる人々にこのような仕打ちをしたがるというのはとても残念です。このような仕打ちを続けるということは自社の評判を傷つけるというだけでなく、バグ報告などを減らすということにつながると気がついてくれることを願っています」とコメントしています。
登録:
投稿 (Atom)
CVSS（Common Vulnerability Scoring System)とは
共通脆弱性評価システムと呼ばれ、下記3つの基準で脆弱性を評価する仕組みのことです。
システムの種類や開発者、評価者などの違いに影響を受けないような、共通の尺度で深刻度を表す指標です。