builderscon tokyo 2019 Aug 31

builderscon tokyo 2019 3日目(8/31)の参加レポート(メモ書き)です。
2日目の参加レポートは以下
https://msmsny.hatenablog.com/entry/2019/08/30/234920

builderscon tokyo 2019

builderscon.io

参加したセッション

※スライド資料はまだ公開されていないものもあります

クレジットカードの通信プロトコル ISO8583 と戦う

speakerdeck.com

メモ

Kanmuという会社にいる
アプリでカードがすぐ作れる

クレジットカード業界のエコシステム
アクワイアラ: カードを使う場所を増やす
イシュア: カードを使う人を増やす
これらの間にカードブランド(Visaとか)がある

仮売上(与信・オーソリ)、実売上(クリアリング・確定)の2フェーズ
Kanmuはイシュアに属する
ブランドにつなぐ部分を自前で実装することになった、これにあたってISO8583を使う

ISO8583
githubを調べると(雑な)パーサーが出てくるがそのまま使うことはできない
パーサーを自作(Go、お手伝いしてもらった)
16進表記、一見読めないが登壇者の人は読める!
→解読しないとだめなようだ…

基本構造
→フォーマットがすべて決まっている
MesageType
Bitmap
→ビットが立っているところにデータが現れることを示している

パーサー
バイト文字を先頭から順番に読んでいく
→Goの実装を紹介、普段あまり見ないコードだ…

Data Elementのパターンがたくさんあって複雑…

業界特有の慣習がある
→英数字を許可されているけど通例で数字だけを使う、とか

質疑

  • プロトコルの仕様が追加/変更はあるか
    プロトコル自体にはない、ブランドからの連絡が半年に1回くらいあり、この項目が変わる、ということはある、連絡は事前にある
  • エラーハンドリングは難しくないか、通信が途中で途切れたり
    →特に二重処理しないようにチェックはしている
    →レスポンスを返したつもりでも、同じリクエストがきたとき
    →不正なフォーマットがきたときはどうか
    →よくある(!)、普通にはじく、HTTPでいう400的な、しかし買い物して返品したときにエラーが起きたときに困る、お客さんに返金ができない、そのときは仕方ないので受け入れる
  • テストはどうしているか
    →どんなテストケースが重要な項目かはカード会社側にゆだねられている、エラーケースはカード会社側次第、変なものがきた場合は都度対応
  • ISO8583にチェックサムはないか
    →電文自体にはない、長さは決まっているのでそこでひとまず判断する、くらい
  • 内製のものに切り替えたときにどうやったか、段階的?
    →事情があり段階的にできなかった、長時間(10時間くらい)メンテをしてデータを移し、1回で切り替えてやった
  • テスト環境はどういうものがあるか
    →ソフトウェアの種類はコンプラ上言えない、テスト用のカード番号を入力してテスト用のレスポンスが返ってくる、これでテストをする
  • メインフレーム臭がしますが・・データはunicodeにして変換している?
    unicodeにしてDBに保存している

Protocol Buffersのスキーマを利用した開発

speakerdeck.com

メモ

Protocol Buffers
→シリアライザーションツールであるとともにスキーマでもある
Protocol BuffersとgRPCは独立している、どちらも個別に使える
JSONスキーマの代替としても使える
→proto.Unmarshal(), proto.Marshal()
→JSONならjsonpb
実装すると重複するところがあるので自動生成したくなる

.protoのパースをする
1. protoc pluginを作る
→正攻法
→問題点:protocのパースした結果が少し使いにくい
2. pluginではなく独自のツールを作る
pbparserというのを作った
→問題点:pluginのときと実行方法が異なるだけ、やはりパースした結果が扱いづらい
→pluginのような特別な機構はない
3. protocを使わずにサードパーティのライブラリを使う、独自のツールを作る
jhump/protoreflect
→inType, outTypeが文字列でなくMessageDescriptorという構造体になっている、扱いやすい
このライブラリは使うべきか
→protobufのGo実装はv2の開発が進んでいる、これはprotoreflectととても似ている
→v2はgithubのパスが違う、protobuf-go

google.api.HttpRule
→gRPCからHTTPへの変換ルール、grpc-gatewayもこれに従っている
→前述の独自ツールはこれに従っていない、ちゃんとやるならこれに従うべきだけど手間はかかる・・
protoのオプション
→additional_bindingsとかもある、こんなのにも対応する必要がある、未対応の仕様はドキュメントに書こう

パースした段階でJSONから構造体に変換はまだできない
→パースした段階ではGoのコードがまだ生成されていない
→しかしこれはprotoreflectのdynamicパッケージで解決できる

ツール類
・grpc-gateway
→ちゃんとした仕様、仕様どおりにパースしたい人はこちらを読み込むといい(たくさんある)
・evans
→この作者がprotoreflectを教えてくれた
・protoc-gen-gohttp

まとめ
jhump/protoreflectがおすすめ

質疑

なし

JPQRによって変わる日本のQRコード決済

(スライド資料不明)

メモ

キャッシュレス
QRコード決済
→MPM/CPM(読み取り型、読み取られ型)、静的/動的
増えるQRコード決済、多様化する仕様
JPQR
→コード決済における統一仕様
→8/1に実証実験開始
→ここでは静的QRコードについてはなす
一括で複数事業者に加盟ができたりする

統一QRコード仕様
→バーコード、QRコード、EMV MPM、JPQR独自仕様
QRコードの仕様の解説
→本来は自動車工場で使われる想定だった、汚れていても読めるようになっている(誤り訂正レベル)
→ファインダパターン、アライメントパターン、クワイエットゾーン(余白、これ必要)
JPQRの仕様
→基本EMV MPMの仕様にのっとっている
→契約店情報に独自仕様がある(統一店舗識別コード)
JPQRの不正対策
→セキュリティ対策方針を例示しているだけ、具体的にはのっていない、各事業者にまかせる形
1. 本人認証
→利用時認証、タイミング: アプリ立ち上げ時、決済時
2. 静的QRコードの管理
→かなり難しい、システマティックにやるためにはコストがかかりそう
3. 取引の管理
→QRコードそのもののチェック、決済完了画面の表示、アニメーション、タイムスタンプ、決済音などで対応
→加盟店側で確認できる手段を提供する、利用者への通知、事後の検知
JPQRで統一されるもの
→QRコードのデータフォーマット、統一店舗識別コード(加盟店データの一元化)

質疑

なし(時間がなかった)

スーパーカミオカンデの開発と運用

http://www-sk.icrr.u-tokyo.ac.jp/~hayato_s/20190831_Super-Kamiokande.pdf

メモ

Geek向けの内容を用意した
素粒子(elementary particles)の研究
陽子は重い、電子の数十倍重い、重いものは壊れやすい、でも陽子は壊れにくい、だからいまがある(こうでないと光だけになってしまう)

ニュートリノは電子の中で電気をもたない、見つけにくい

カミオカンデ(〜1996)
10^32の陽子にあたる水(160トン)を用意して陽子が壊れる様子を観測しようとした
→しかしうまくいかず
→検出器は地下に作る必要があった
→神岡は炭鉱ではなく金属鉱山、岩が硬い
→炭鉱だとやわらかすぎてだめ、逆に硬すぎてもだめ、適度に水がないとだめ

下からくるニュートリノが変化することがわかった、変化するということは重さがある、
→ニュートリノに重さがある?
→これがノーベル賞になった

ニュートリノはどこにでもある、宇宙、太陽、大気中、人工的な加速器でもできる
→地球の中心(地熱)からも作らていることがわかっている

Supernova(1987年)
→ニュートリノが観測できてわかった、カミオカンデで観測

スーパーカミオカンデ(1996〜)

水中の場合光は真空より遅い、このときに光より速く動く粒子がある→チェレンコフ光になる、青い光、よく通る

太陽からくるニュートリノの観測は簡単
→ニュートリノがきた元の方向が太陽なら太陽からきたと推測できる

チェレンコフ光
→短い。200ナノ秒

Supernova
→超新星爆発、星がなくなる前に中心が鉄だけになる、重くなる、重力で支えられなくなりつぶれる

ベテルギウスがsupernovaになったときに100Mのイベントが起きる
→これを観測できるようにする必要がある(たいへん、普段20-30イベントくらいなのに)

GPSは時間をはかるためにつかう
→いつイベントが起きたかを正確にはかりたい

光電子増倍管
→ガラスの部分は機械的に作れない、人が作る
→壊れたときになおすのが大変

CPUなしでTCP/IPを実装済みのボードを作った(すごい)

super-kamiokande data acquisition system
→Readout computersの部分はたいてい不要、software trigger computersで選ぶ
→temporaty storage data serverに全部送ってしまってあとで選別する

data acquisition systemは普通のネットワークと逆向き
→最終的に1台に集める必要がある

switch
→QoSで勝手にパケットを捨てられると困る、QoSを無効にできるやつを使う
→P社のは勝手に捨てる、最終的にciscoのものになった、これはなかなか壊れない

ニュートリノを作る
→東海村から神岡まで200数十km離れている
→叩いて陽子を作る、燃えないようにカーボンを使った棒
→1回で700度まであがる、冷ます
→ヘリウムの空冷、水だとだめ
→ニュートリノがきた瞬間のデータだけ残す、GPCで時間を予測する
→時間をあわせるためにGPSの特殊なレシーバーがあってそれを使う

スーパーカミオカンデのソフトウェア
→Fortranで書いてある、いまはCで書く、バージョン管理はsubversion

スーパーカミオカンデ一般公開
11/2にやる、9/2に申込方法発表
→しかしタンクのなかは見れない

質疑

  • ベテルギウス、近々supernovaということだけどいつか?
    →500光年なのでもう壊れている可能性はある
    天文学屋さんの話なので数千年オーダー
  • たまったデータを一般で使えることはできないか、オープン化はないか
    →やっていない、使うためにはデータのタイミング、精度を揃える必要がある、これをどうするか
    アメリカではそういう動きもある、が3PBもあるのにどう出すか?
    →ファイバーを県をまたいで出せない
  • ニュートリノが地球に届くタイミングと光が届くタイミングのラグはどれくらいか
    →数時間ほど違う、光が届いたら検出器をすぐそちらに向ける
    →解析は5分ほどでできる(光が届く→解析する→検出器を向ける→観測、という流れと思われる)
  • パケットロスに困っている、安いスイッチでいいやつはないか
    →安いのは全滅、ciscoは大丈夫だった、それ以外探していない
  • 散乱断面積?の変数は何か(ここ質問がよく聞き取れず・・)
    →大雑把にエネルギーに依存する
    →水の代わりに液体アルゴンを使った実験も計画されている

Peddle the Pedal to the Metal

http://highlandsun.com/hyc/20190831-BuildersCon-Metal.pdf

メモ

OpenLDAP
コードを書くことについて
Donald Knuthの話
最適化をする話
→3%だけ最適化すればいいということだった
→私の経験的には99%のコードは最適化が必要だった
あらかじめ考えておく必要性
→適切な意思決定が必要
限界点が出てくる、トレードオフがある
→しかし既存のコードではまだまだ改善の余地がある、トレードオフなしに
ストレートなアプローチがベストになることが多い
→いろいろやるとかえって複雑になる、それならストレートにやったほうがいい
正しいコードからはじめる、その後速くしていくといい
→戻ってなおすという機会がないかもしれないため

コードのプロファイリング、ツール
→Linuxならperf、コードを変えずにそのまま使える
→valgrind, callgrindもある、細かい解析ができる、しかし遅い
プロファイリングは全体像をつかむために必要
Don't Repeat Yourself
→ランタイムにもこのコンセプトはあてはまる

stringを分けてもとに戻す作業が主
→stringを使っている場合はポインタに書き換えていった
→strcatはCライブラリの中で最悪なものかもしれない・・
→だんだん時間がかかっていく、我々のプロジェクトではカスタム関数に置き換えた
→文字の連結を速くするため
→現代ではstrcpy()に置き換わっている
stringのまとめ
→Cのライブラリを使うときは標準のものではなくすでに長さが入った構造体を使っていくといい

malloc
→mallocも置き換えたくなる、しかし10-20%程度しか改善されない
→mallocを使わないでいく
→C++スタイルの構造体を使わない
→reallocは使わないほうがいい、strcatと同じ問題がある、使うほど遅くなっていく
→サイズ全体をまずはかる、1回だけアロケーションするのがいい
→パースするときに不要なallocが行われている
→OpenLDAPではアリーナを使う、ヒープの代わりに
→incoming requestが多いときはpreallocationするといい
→メモリーリークしたときはhyc/mleakのツールを使うといい

ここまででコールグラフで明らかなピークがなくなった、しかしもう少し深い分析をしていく
目立たないプロファイルを探す
スレッドのstartup, teardownのコストがかかっている(Threading Cost)

デバッグ関数がコードの中でばらばらにあった
→関数呼び出しにコストがかかることもあった
→DEBUG() macroでラッパーにした

10パラメータがあるときは、何かおかしいことをしているだろう
→Alan Perlis(1982)
→C++ではよくあること

10のパラメータを毎回渡すのではなく構造体にした

マルチスレッドのプログラム
→当時はシングルプロセスのマシンしかなかった
→マルチプロセスのマシンにしたときに問題が出てきた、"False sharing"が起きた
→ここでのアプローチは順番に注意する、不必要なpadding byteを避ける
→しかしキャッシュの観点ではpaddingは必要
→整合性が取れるようにpaddingしていく
→メモリサイズを自分でなおさなければならない

これらの作業は反復的である
隠れたボトルネックが出てくる
20年以上このコードベースに関わっている
いつまでもやらなければいけない・・
measurementをして記録していくのが重要

行った変更が十分でないということも出てくる
→残りの問題があれば、0からまたスタートするのもあり、ただこれは通常はよいアイデアではない
BerkeleyDBを15年ほど使っていた、しかしこれはネイティブのバックエンドとしては遅い
→DBの前にキャッシュをおいて解決する方法もある、しかしキャッシュレイヤーも複雑になる
DBがあまりに遅いときは根本的な解決をしていくことも必要だった
BerkeleyDBにキャッシュがあるけど自前のキャッシュも用意した
→filesystemキャッシュ, BerkeleyDBキャッシュ, OpenLDAPのキャッシュがある状態になった、これは複雑、無駄である
→デッドロックに当たることもある
→自前のDBレイヤーに手を入れていった
→MVCCを使った

まとめ
コードははじめに正しいものにするべき、あとでパフォーマンスをあげていく
1ステップで完全なgainを得ることはない
効率をあげたいとき、自分が必要としているものだけを改善していくといい

質疑

  • C++が嫌いと言われていたが、普段自分はC++を書いているのだがどうしたらよいか(会場笑)、C++で同様のことをするにはどうしたらよいか
    →クラスの複雑性を認識する、メソッドを作る場合パラメータリストはなるべく少なくする、私見だがconstructor, destructorはなるべく使わないほうがいい
  • スレッドプール、DRY、リソースの再利用をしてより効率的にしていくといい、ということだが問題になるのがリソースの状態が複数パターンで共有されることでデバッグが難しくなることがあるが、この問題への対処はどうしたらよいか
    →モジュールの中で境界を定義する、デザインプロセスの中で常に重要、ゴールの1つとしてデータをプロセスするところで近いところにおいておく、シェアするときにどこまで共有すべきか、スレッドプールではいろいろなところで使われるインターフェースをなるべくシンプルに、シングルエントリポイントにする、concurrent pointを置く
  • OpenLDAPでの十分な性能が達成される日はくるか
    →パフォーマンスについてはほぼ到達できている、ネットワークのdelay timeより少しだけ遅いレベル(0.4msec)をゴールにした、そこに到達はしている
    OpenLDAP 2.5リリースではまだ改善をしていく、大規模展開向けの対応、2015年には1秒あたり100万クエリを処理する、これはできた、大規模マシンではまだ課題がでてきている、それの対応
  • BerkeleyDBから実装を変えた、他にもある組み込みのDBを使わなかった理由はあるか
    →いろいろ探したがあまりいい選択肢がなかった(2008年当時)、トランザクションサポートがなかった、当時はBerkeleyDBしかこのサポートがなかった
  • 1つのマシンで動かすときの最適化だったと思うが、複数サーバが連携して実現するシステムのときに、全体で最適化したいときはどんなアプローチがあるか
    →チャレンジングな状況になる、フロントになにかあり、クラスタにワークロードを分散させている、中央のものがボトルネックになる、LB、LDができることを最小限する、コピーも最小限にとどめる
    →独自のLBを機能として提供する予定、サードパーティのLBでは不十分だったため
  • LMDBを使っている、これを作るにあたって何かブレイクスルーがあったか、地道にやっていったのか、どちらか
    →2009年から考え始めた、2011年にリリースした、じっくり考えて設計も行った。時間はかけている、設計をしているときに本当にパフォーマンスがあがるかわからなかった。予想よりもよいパフォーマンスになっておどろいた。
  • LMDBに関連して、新しいデータ構造とアルゴリズムに基づいて新しいものが出てきている感があるが、そういったものを追いかけているか、プロジェクトとして
    →データ構造についてのリサーチは常に目を光らせている、LMDBではB+ツリーの方式をとっている(?)、この方式は古いけど他よりも速い
  • LMDBの開発のときにDBの人材を集めるのはどうやってきたか
    →集めなかった(!)

もしもハッカーの「サイバー攻撃日誌」が読めたら

(スライド資料不明、公開されない?)

メモ

Red Teamサービスについて
→脅威ベースのペネトレーションテスト、金融庁が出しているものと同じ
会社にとって最悪な状態をゴールに設定する
組織全体のセキュリティをみていく

ケーススタディ
攻撃の期間は3ヶ月くらい
マルウェア
exeをbase64変換してtxtに置く、その後windows標準のcertutilでtxtからexeに戻す
端末をシャットダウンしても起動するように自動起動設定をする
管理者権限がほしい→権限昇格
フルコントロールのexeを置き換えて再起動すると管理者権限が取れる
mimikatz
windowsは(バージョンにもよるが)メモリ上のパスワードを平文でもっている、これをとる
2要素認証
→これがあるとめっちゃいい、攻撃側はこれがあると大変、作戦会議をする、ニセのログイン画面を作る、中間者攻撃をする、など
→2要素認証したあとのユーザーのセッションをとる、業務端末経由の攻撃。remote desk topで入る
→ユーザーが離席するのを待つ、お昼の離席時間を待つ

攻撃成功の要因
→フィッシングメール、これは数打つと誰かが開いてしまう
ほかもいろいろあった(スライド参照)
技術的な防御策だけでは不十分

サイバー攻撃日誌が報告書になる

Hardening Project
→まもる技術(楽しそう)
→攻撃側として登壇者の人も参加している

攻撃側フレームワーク
→サイバーキルチェイン
ATT&CK
→攻撃で利用される技術の分類

おわりに
ケビンなんとかさんの格言
「わざわざそこまでやるやつはいないだろう」とシステム開発者が思うようなことを、「わざわざそこまでやる」

質疑

  • linuxssh-agentを使っていたりするとき、毎回パスフレーズは入れるべきか
    →環境などに依存するので一律には言えない、攻撃側としてはキーロガーを入れたりすることもできる
  • 社内イントラの状況、スタートアップの場合ほとんどない、ADくらいであとはクラウドのアカウントくらい、どちらが攻撃しやすいか
    →感覚値として規模が小さいほうがやりやすい
    →そのときに小規模な会社はどのような対策をとればよいか
    →リソースがあるのならセキュリティチームをとる、インシデントのときの外部との契約をしておく
  • マルウェアをインストールするとアンチウイルスソフトで検知されないか
    →ものによる、セキュリティソフトにもよる、マクロからファイルを吐くものに反応するソフトもある
    →今回のケースではtxtにしてからexeにしているので、この場合は反応しない、こういう細かくよけていっている
    アンチウイルスソフトが反応することはあるか
    →ある。見つかったときにどう対応しているか、消しに来ているか、再起動で済ませるか、も見る
  • 今回のケース(2要素認証)で中間者攻撃は難しいか
    →不可能ではないが面倒、オレオレ証明書で中間者攻撃してもつながらない可能性がある、つながらなかったらちょっとあきらめる(証明書インストールが必要になるため)
  • 事前に攻撃者に与えられる情報はどういうレベルで与えられるか
    →聞いたとしてもシステム構成図くらいなもの、基本何も聞かないもよう
  • 検知が重要、クラウドを使っているとき検知はどうやったらよいか、通信はいろいろされているが
    →管理者権限でAWSを使ったときに反応するものもある、そういうものを使うのもいい
  • 資料は公開しない
  • HTTP経由でTCPセッションをはる、OpenVPNではまさにそれをやっている、それを狙うことはあるか
    →技術的には可能、そこで検知すべき、しかし通信量だけで検知されることはあまりない
  • リモートワークできるときは侵入しやすさが変わる?
    →セキュリティの確保は確かに難しい
  • macのときはどういう攻撃手法になるか
    →やったことはある、AD連携もできる、集中管理のソフトを使っているときもあるのでそこを使っていく
    windowsよりは大変、疎結合、1個侵入できてもとなりにいけない
  • 今回のケースでは理想的に進んだが、成功率はどれくらいか
    →発表は30分程度なのでわかりやすいシナリオを選んだ、ゴールの達成にはこだわる必要はないと思う
    →成功率でいうと経験上はほぼ達成できている
    →例外が2つある、1つは手順を飛ばしてしまい戻れなくなったパターン、あとは期間を決めて防御側に周知してしまったケース
  • 攻撃の入り口はメールアドレスだった、他にもSNS経由もある、攻撃される口を塞ぐような知見はあるか
    SNS禁止をするのも難しいところ
    →メールで攻撃する場合、実在するかのチェックはするか
    →linkedinなどはメールアドレスが見える
  • 日々の脆弱性についての勉強方法、いい方法はあるか
    →ない、カンファレンス、ツイッター、ブログで情報収集、また海外のほうが情報が早い
    →特定の脆弱性を狙うことはあるか
    →black hat?で任意のユーザーのパスワードをリセットできたり、とかいいよねという話
  • ゼロデイを利用することはあるか
    →実績はある、入れなかったのでゼロデイで入ったことはある、しかしほとんどの場合は正規のアカウントで入っていくことが多い
  • 攻撃者からみてやりづらいところはあったか
    →2要素認証、これは攻撃に時間がかかる →注意喚起が早いところ、情報共有、初動がはやいところ
  • 期間は3ヶ月、期間設定はなぜそうしたか
    →攻撃にかかるのがそれくらいの期間
  • 知識ベースでも2つになるのはいやか(秘密の質問など)
    →そういうケースもある、しかしたいていのばあいはドキュメントの中にころがっている・・
  • 攻撃をやっていい範囲、犯罪にならないか
    →一般的なペネトレーションテストと同じで、このスコープの中でやっていく、というのを必ず守る

LT

感想少し

純粋に楽しかった、また3日目も勉強になりました。
まさに「知らなかった、を聞く」ができた気がします。

セッションピックアップ

  • スーパーカミオカンデの開発と運用
    少し物理の勉強あり、しかしスライドのイラストがかわいい感じのわかりやすいものだったので説明に工夫がされているのだなと思ったり
    そして機材や検証方法のスケールの違いに驚き、普段あまり触れることのない面白い話が聞けて楽しかった。
  • もしもハッカーの「サイバー攻撃日誌」が読めたら
    攻撃者の侵入方法が体系化されていて感心させられました。いろいろやるのね・・
    あとは2要素認証があると攻撃が面倒というのがなるほどと思いました。
    昨日のWebAuthn/FIDOのセッションでは2要素認証も突破される可能性はあるのでWebAuthn/FIDOだ、ということを言われていましたが2要素認証がまったくだめというわけではないと(フィッシング耐性のあり/なしの違いはある)