CODE BLUE 2018 レポ #codeblue_jp

CODE BLUE 2018 というセキュリティに関するカンファレンスに行ってきたのでレポート

codeblue.jp

 

1階でブース出展してて、ブース内で説明員しつつ

人員がだぶついてきたら、たまに公演を聴きに行くというスタイル

 

日本のカンファレンスだけども、講演者は英語なことが多め。

ただ同時通訳者がいて、ラジオみたいな機械のイヤホンで聞くことができる。

 

以下、聴いた講演のざっくりまとめ

 

基調講演:Cyber Arms Race

セキュリティエンジニアがこれからどういう役割を担っていくのかって話

 

お金を盗むならたくさんお金あるとこがいいが、銀行はセキュリティがかなり万全になってきた。
というわけで最近の標的は仮想通貨や新興fintec。銀行より楽で額は同じ。

北朝鮮とかは国単位でお金盗もうとしてるよね。

 

スパイ活動はオンラインに移ったのではない、オンラインに広がったのだ(エモい)

 

水陸空に加えてオンラインが加わったということ。
例えばロシア対ウクライナでサイバー兵器が使われてる。
効果的で安いし、誰が使ったかわからないのがサイバー兵器の素晴らしい点

 

一度攻撃が成功すると、森林火災のように感染が広がって4000台が一瞬で死ぬ
リモート接続できないので、サーバのあるとこに行かないといけなくなる 

時間はかかるわ人員確保できないわで大変。

ウクライナの企業だけでなく、ウクライナと取引をしてた企業にまで被害
ウクライナでビジネスをするとサイバー攻撃されるぞ、という攻撃者からのメッセージ。攻撃が大成功してますよね。 

 

企業がハッキングされたことの気づくのに平均200日かかる。

最近の狙いはIoT機器。

冷蔵庫がハッキングされても別に問題ないわ、と思ってる人も多そうだが、攻撃者は別に冷蔵庫の中身に興味があるわけではなく、そこからネットワーク全体への攻撃起点として使う。

給湯器に組み込まれたコンピュータをDDos攻撃のメンバーに加えたりする。

ALL COMPANIES ARE SOFTWARE COMPANES だ

 

そんなエモエモな感じの講演。Twitter見てる感じ、刺さったセキュリティエンジニアのひと多めだった気がする。

 

 

Windowsの不正ログインを発見する

JPCERTの人による講演

年間2万のインシデント報告を受けているが、いろんなサーバとかに感染がひろがってるので原因究明が大変

Active Directoryのイベントログを分析して、侵入されたホストを特定していこう。

 

で、いざ調査となったときに
・Pass the Ticketではwinにログオンのログが残らない
・イベントビューアでインシデント調査は大変
・イベントログのデータサイズ多いので検証大変
・SIEMでは統計は見やすいが不正なログは見つけにくい


不正なwinのログオンを見つけるには
1ホスト1アカウントなら複数ホストへのアクセスがあったときに、視覚化しているとすぐわかる。
でも、実際やってみると可視化もごっちゃごちゃしてる。
可視化はサポートにはなるが、完璧なソリューションではない。


疑わしいものを自動でリストアップする仕組み→自動分析させたい。
Lateral Movementの共通点は2つ。
・コマンドを使う。ドメイン管理者をつかう
・同じアカウントでログオンを繰り返す
共通点を自動分析に適用してみよう


たくさんのホストにログインしている→あやしい→ネットワーク理論の中心性を使えば抽出できるのでは
Windowsログオンは3つの状態を持つので、隠れマルコフモデルをつかって状態遷移のエラーを把握する


そうしてできたのがLogonTracer。使ってみてね。

github.com

 

 

GLitch: WebGLを使って携帯電話を攻撃する

WebGlでメモリアクセスしまくってビット反転をできないかという内容

JavaScriptはモバイルで動く。

WebGLならGPUを動かせるので、新たなAttackVectorになりうるぞ!という注意喚起の講演。

 

契約に関わるセキュリティの罪の十戒

契約書にセキュリティの条項がないと、後々つらいよって話。


セキュリティには開発の時から考えておく。
セキュリティはITビジネスの本質に関わってくる。


多くの契約書には〝カスタマーのセキュリティ方針に準拠する〟と書いてるが、実際の運用は適当。

セキュリティポリシーのバージョンや該当する箇所が収められている場所も特定されていないことがほとんど。

なんなら、相手のポリシーをだれも読んでないことすら多々ある。

 

そして、セキュリティポリシーを更新したときどうするのかを前もって決めておく。

でないとポリシーがかわるたびに説明・交渉しにいかないといけない。ほんと大変。

説明や交渉、アップデートしたときにかかるコストが誰にかかるのかを考えないといけない。

GDPR PCI-DSS とか に準拠する、と書いてるときも多々あるが、こういった基準が適用するスコープ・範囲を定義しておく必要があるのと、基準が更新されたときにどうするのか、更新にかかる労力も誰が負担するのか考えておかないといけない。


盛り込まないでほしい言葉 → ベスト・プラクティス


誰が・どうやって・どのくらいの頻度で、ということを侵入テストや監査に対して決めて置いて、きちんと境界線を決めておかないといけない。

監査の頻度や作業量、超過時間のコストをだれが負担するのか。
本番に対して侵入テストしてもいいのか、devに対してだけなのか。
侵入テストでやっていいことやってはダメなこと。


例えば、本番に侵入テストをしてはいけないが侵入テストをしてしまったみたいなケースが過去あって、
で、脆弱性を衝いて侵入できてしまった。こういうときどうなるのか。


必ず問題は起きる。

どうせエスカレーションのときに関わることになるんだし、契約書作成の段階から関わろう。契約書のテンプレートを作る段階から関わっていこう。

いい契約書はデリバリする人が関わって作られた契約書。

 

サイバー防御に活用できるOSINTの手法と実践

公開情報を見て脆弱性対策するにはどうすれば?という講演

OSINT = 公開情報をもとに作られる読み手に合わせたインテリジェンス

広く浅く情報を収集して、(ソースが公開情報なので)コミュニティに反映できるのがOSINT

 

なんてFaxだ?!

Fax機能付き複合機の脆弱性をついて、つながってるWindowsの「電卓」アプリをリモートから起動するまでのデモ。

CVE-2018-5924、CVE-2018-5925 についての詳細な説明。

 

Microsoftのコンタクトページやトランプ大統領のページにもFax番号書いてる。

なんで2018年にもなって、みんなFax使ってるの?


Faxを使わないなら電話回線から外しておく。
そして、Faxは独立したネットワークに置いておく。

 

感想

f:id:alfe1025:20181101120827j:plain

今回 CODE BLUE初参加だったんですが、やばい人がやばいほどいる、みたいな語彙力皆無な感想しか出てきませんでした。

コードをバイナリから読んで、バイナリ見るだけでファイルの拡張子把握できて、メモリ領域に何が入ってるか把握してて、GPUやIoTといった発展途中のものからFaxみたいな枯れ切った技術にまで脆弱性を見つけてエクスプロイトする。そんなひとがごろごろいるわけですよ。なにそれこわい。

冗談抜きで、参加していたエンジニアが力を合わせたら一国のインフラ滅ぶと思う

 

WebGLすらThreejs経由な、アセンブリも大学でちょっと勉強しただけ、というアマチュアエンジニアなので、もうすこし低レイヤーについても学んでおかないとなぁって思いました。まる。

 
blog.alfebelow.com