Salesforceの「レッドチーム」メンバ、Defcon発表直後に解雇

Salesforce、Defconで発表したレッド・チームの人員を解雇」

www.zdnet.com

Salesforceの『レッド・チーム』メンバ、Defconでツールについて発表し、解雇される」

arstechnica.com

Salesforceのレッド・チーム(組織内で意図的に設定される敵役チーム)のトップなど2人が、Defconでの発表直後に解雇されました。

2人が発表したツールは「Meatpistol」。一見ペネトレーション・テスト用の「Metasploit」かと思いますが(実際にアナグラムになってますね)、こちらはマルウェア開発を高速化するフレームワークです。「これまで数日かかっていたマルウェア作成が数秒で済むようになった」とのこと。2人はこれをオープンソース化していくと述べていました。

Salesforceのレッドチームは、(内部で活動する限りは)ほぼ制約なしであり、実際のクラッカー同様にデータ窃取なども行ってきました。それによって社内のセキュリティシステムを改善するのが狙いです。

Defconでの発表については、事前に社内で合意されていたものの、ぎりぎりのところで管理部門が判断を転換し、発表の1時間前に2人に止めるようテキストメッセージを送ったそうです。このメッセージを発表前に2人が見たかどうかは、記事により記述が異なっています(ZDNetは「見た」、Ars Technicaは「事前に携帯を切っており見られなかった」とあります)。

Salesforceは2人の解雇とあわせてツールのオープンソース化を取りやめています。なお、解雇理由については明確にされていません。

今回の発表についてのセキュリティ関係者の間での評価は良好で、既に2人には次の職についての提案が複数来ているそうです。

Bitcoinを誤解していた「匿名化」業者、廃業を発表

「インターネット最大のBitcoinミキサー、Bitcoinが匿名でないことに気づいて閉鎖」

www.bleepingcomputer.com

BitMixerという「Bitcoinミキサー」サービスがあるのですが、先日閉鎖を発表しました。

ミキサーとは、顧客から受け取ったBitcoinを数千に分割して別々に取引をすることで「匿名化」を行うサービスのことです。

ここで「え?」と思う人もいると思います。そもそもBitcoinは全ての取引を参加者全員が共有する仕組みですから、取引の記録は(Bitcoinが続く限り)残ります。しかも全世界への公開状態で。

たとえ細かく分けたとしても、それぞれの取引を追跡していけば、最終的な行き先は分かるのです。

そのことに気づいたBitMixerは、サービス閉鎖を発表しました。ちなみに結構儲けはあったそうです。

なお、先日Bitcoin取引サービスBTC-eの所有者が、マネーロンダリングの疑いで逮捕されています。

DefConで.NETのデシリアライズの脆弱度が発表(※ライブラリにより違います)

「深刻なデシリアライズ問題、Javaだけでなく.NETにも影響」

www.bleepingcomputer.com

元の論文

https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-Json-Attacks.pdf

名前がアレですが、しばらく前にJavaで話題になったデシリアライズ(外部からのデータを取り込んで内部オブジェクトに変換する処理)の脆弱性が、.NETのライブラリでも発見されたという話です。本質的にはデシリアライズするデータは何でもいいのですが、ここでは主にJSONを扱っています。

論文冒頭付近では、リモートコード実行(RCE)を起こすライブラリの条件として次の2点を挙げています。

  • ライブラリが、ユーザ(潜在的には攻撃者)が指定可能な型のメソッドを実行できること。この「メソッド」にはデフォルト以外のコンストラクタやプロパティへのset、デシリアライズ時コールバックやデストラクタが含まれる。
  • 悪用可能なコードを探せるだけの広さをもった空間が利用可能なこと(正確に理解できていませんが、後の記述からは悪用可能なクラスにアクセスできること、といった意味と思われます)

論文では.NET標準の JavascriptSerializerDataContractJsonSerializer 、超有名ライブラリのJSON.NETなどJavaと.NETのライブラリ10個(と比較参照のためにJavaのFlexSON)を調査しています。

  • Json.NETの場合、基本的には TypeNameHandlingNone 以外にすると脆弱になりやすい
  • .NET標準の DataContractJsonSerializer の場合、型指定を任意指定できてしまうと脆弱になる(論文ではCookieから型名を取得する例を書いています)

といった感じです。中には(ネットの向こうから来るような)信頼できないデータに対して扱うべきではない、と結論されるライブラリもあるので、気になる場合は論文をチェックしてみるといいでしょう。

超音波によるスマートデバイスへの攻撃手法が発表

「まずいもの聞こえちゃったね:研究者達、『超音波銃』によるスマートデバイスへの攻撃デモを公開」

arstechnica.com

記事タイトルは「Sounds bad」をなんとかやったんですが、下手ですみません……。

Black Hat USAにおいて、アリババのセキュリティ研究者から、超音波や可聴域の音波を用いた攻撃手法のデモがありました。

これは加速度計やジャイロ、各種のMEMSセンサを用いた機器に音波をぶつけることで値を狂わせて異常動作を励起させるものです。特にターゲットの共振周波数などにあわせることで大きな影響を与えることができます。

デモでは、ライブでiPhone7とGalaxy S7、ビデオではVRヘッドセットやドローン、ホバーボード、自律的にバランスをとるおもちゃをターゲットに音波をあてて異常を起こしています。

「パスワードの定期的変更」、発案者が後悔を表明

「パスワードのベスト・プラクティス、元々の筆者の後悔の後に改訂」

www.theverge.com

「パスワードは定期的に変更しましょう」といえば「勘違いセキュリティ」として有名ですが、元々の発案者へのインタビューがWSJに掲載されていたようです(上記はそれをもとにしたThe Vergeの記事)。

かつて米NISTに勤めていたこの人物は「かつて行ったことの多くを後悔している」と述べています。ちょっとかわいそう。

代表的な後悔している項目は2つ。

  • パスワードは記号や数字を入れた複雑なものにすべし
  • パスワードは90日ごとに変更すべし

パスワードに記号や数字を入れること自体は強度を増す意味はありますが、覚えづらくなるのが問題です。定期的変更は言い尽くされてますが、そもそもセキュアにならない上に、変更を強要することで安易なパスワードに流れやすくなる問題があります。

現在ではNISTも指針を改訂していますが、考え方の改訂が広まるのには時間がかかりそうです。

ところで、記事中で引用されているxkcdの「単語の組み合わせ」も忘れやすいと思いますけどね。個人的には(環境により判断基準が異なりますが)パスワードは素直にマネージャ使うのがベストだと思います。

米民主党の委員会、内部通信をWickrに移行

「2016年のハッキング被害を受けて、米民主党の委員会は暗号化メッセンジャーに切り替え」

www.buzzfeed.com

民主党の議会活動委員会DCCCは、2016年のメール暴露の件を受けて、内部通信を全てWickrに移行しました。

WickrはPCでもスマートフォンでも使用できるもので、end-to-end暗号化通信ができます。またオプション設定によっては一定時間後にメッセージが自動削除される機能もあります。

Mandiantのセキュリティ研究者、保持するデータを暴露される

ハッカー達、Mandiantのセキュリティ研究者のデータを #LeakTheAnalyst 作戦のもとでリーク」

www.bleepingcomputer.com

31337 Hackers(31337=eleet)と名乗るハッカー集団により、Mandiantの研究者のデータがリークされました。MandiantはFireEyeの侵入調査部門です。

リークされたデータの多くはスクリーンショットで、その内容から当該研究者はマイクロソフトHotmailやOneDrive)やLinkedInのアカウントに侵入されたものと推測されています。なお、リーク側はFireEyeのネットワークに侵入したと主張しています。