カテゴリ:
Nonセキュリティエンジニア向け
イベント参加
M-CSS(MAKENAI-Cyber Security Study)というサイバーセキュリティなコミュニティの勉強会に参加してきましたー

なんでも、
サイバー攻撃にMAKENAIためにサイバーセキュリティについてみんなで学んでいこう！
っていうコミュニティらしいです。

今回も壮絶に迷いましたよ。渋谷は鬼門すぎるｗ
回線の混雑でグーグルマップとかもまともに動かないし。

迷った挙句に道をきいた警察官の人に
「ここ、すごく遠いんですけど・・・」と申し訳なさそうに言われましたよヽ(*´∇｀)ノ

こうなるだろうと早く出たのに軽く一時間は歩いたかな。

前回にも増して激しい大遅刻っぷり。
いろいろすみませんでした。


さて、さくさくと勉強をさせていただいてきた内容をかきますよ、と。
今回は資料が公開されるみたいなので、あえて補足メインでかいてみます。

■SQLインジェクション
諸事情につきSQLインゼクションのお話の途中から参加＾＾；

防ぐ方法と、実際の攻撃手法を実際にサイトを作られていらっしゃって、
そのサイトに攻撃をしかけながら攻撃手法もご案内。

SQLインジェクションは出始めはすごく騒がれてその名前は有名になったのですが、
今では結構古い攻撃手法となってしまい、
典型的攻撃手法の一つ、とまで言われています。

古典的攻撃手法だということは
既に誰でも実行できるツールが作成されていて、
自動的に攻撃される危険性が高い状態であるとも言えるので、

「対策は必須である」ということになります。


時間制限もあるからでしょうから、
基本的なことしか触れられていませんでしたが、
補足として追加することは3点。

1)権限が無駄に強く設定されてると、DBの制御に使用するテーブルの情報を簡単に取得できるため、DB内のテーブル名とかユーザ名とかも簡単に抜かれてしまう。

初心者ほど実行IDに対して権限を強く設定しすぎるため、
漏洩事故と同時にも発覚する、案外多いミスなので、
SQLインジェクションに注意するならこれにも要注意。

2.HTTPクエリーを直渡ししてXpathインジェクションの実行で値をぬいてていらっしゃいましたが、
もっと簡単に、認証時のクエリ操作の話で
''' AND pwd = ' | ''
とかで認証回避できたりするほうが例として簡単だったかもね、と。

そもそもが受け取った値を確認せずにRDBにリクエストする構造にそもそもしてはならんのですよ。

最低限、
・文字のデータ型
・文字長
は、マップとか配列とかにべた書きでもいいから、
チェックしてから値を実行可能とする機構をつくっておくことは
紹介いただいた対策とあわせてするべき基本のことのひとつ。

他のインジェクション対策と共に
コーディングルールできちんと定めておくべきですね。

3.RDBとか他のサーバとかクラスとか、自身以外の外の何かにアクセスした時は、
必ず想定外エラーが返ってきたときにも画面にデフォルトコードが表示されないようにしよう。
エラーメッセージを考えるのが面倒臭い時はまったくの適当につくったHTMLのエラーページにリダイレクトするだけでも対策としてはよかったりするｗ


そして、質疑応答タイム
Q01.SQLインジェクションは総当たりが多いのか、どうやって見つけているのか。
　　面倒くさくないんですかね。
A01.総当たりです。攻撃者はちまちま調べるのが大好きなんです。

※私からの注釈：
ちまちま調べるのが大好きってのは激しく同意ｗ

ターゲットにするサイトを予め定めてから攻撃する穴をツールを使って探したりする以外には、
見つけた脆弱性の攻撃キーワードをグーグル検索してヒットするサイトを攻撃する、などがあります。
(対象がきまったらポートスキャンとかサーバ情報をいろいろなツールを使ってひっこ抜くのが定番
でそこはあまり変わらないです)
実は「攻撃する側も面倒臭いのでフィッシングやら感染能力のあるマルウェア使うのですよ」で腹オチしてたのではとこっそり思ってました(笑)

Q02.XPath を使ってましたけどほかのSQL言語でもおなじですか？
A02.是非ご自身で調べてみてください

※私からの注釈：
XML解釈の機構がついているRDBはすべて該当します。

MySQL、PostgreSQL、DB2、SQLServer、Oracle、などの有名RDBはその機構を持っています。
(正しくは「その機構を持っていないRDBを私が知らない」だけなので、機構がないRDBをご存知の方はこっそり教えてください)

そもそも「XPath インジェクション」という名前がついている、
SQLインジェクションと同じ原理なのですが別の脆弱性(コード・インジェクション)の話です。
上の2.に書いたとおり、受け取った値をろくに確認もせず実行値としてしまうように作ってることが原因です。

(参考)
XPath インジェクションによる危険を回避する
https://ibm.co/2tBExkq

Q03.SQLはRDBだけ？だからSQLがNonRDBとかプログラム上にはいってても関係ない？
A03.SQLが使えれば再現性があるため、関係があります。


■わんこの被り物をかぶって超早口でOWASPの2017top10の話。
1件目がすごくゆっくりだったので、すごく早く感じるw
被り物の存在を忘れるくらいに早かった。

ハードウェア側でどうにかしろよととっても激しくおっしゃってましたが
そもそも、アプリケーション層の防護とハードウェアの防護は別に考えないといけないんだよ(多層防護ってやつですね)
ハードウェア側はそれはそれで別にやることが激しくいっぱいあるから安心しろって感じw

すべての方向に喧嘩を売ってくスタイルなお方のようです。

OWASPの貢献物である一気に確認する侵入テストツールの話も。
(1つ前のカテゴリでの質問への答えでもありますね)

セキュリティの協同会議ではではよくあることなのですが、
特定の製品紹介しあいになって企業同士で揉めているの話も。

ご自身のメンツも大切なんですけど、それよりもなによりもと、
お互いのメンツを気遣え無いようでは協力しあうどころか、
小さいところから逃げ始めるし、新規参入もなくなりますよ。悪い意味で。

本当に色々な企業またはオープンソースの情報取りまとめる方向にいっていないのなら、
よくある組織が瓦解するというまえぶれを出してしまっているってことなので、
本当にしっかりしてください（＾＾；

正直、
ライトニングトークでやる内容じゃないと思う。
ちと時間配分と内容をかんがえてほしいというよりも、
ロングの普通枠で落ち着いてもう一回きちんとやってほしい感。

脇道を話すことに一生懸命すぎて、
折角の面白い題材なのに肝心の内容が本当に薄くて薄くて、
本人が何が本当に伝えたかったかとか本人の主張もよくわからずで
期待が大きかったがために残念極まりないので、
時間枠をとってもう一回やってほしい。

せっかくOWASPを皆しってるようだったのに
言いたいことを汲み取れないという意味で理解できなかったから
質疑応答タイムもまったく誰からも質問でなかったんじゃないかな、とも思う。

最先端のことを話してひとつも質問が出ないことは怯えるべきことだと、
自分のキモにも命じておくですよ。

■大討論会といいながら主催者への疑問へ参加者からお答えしましょうの会。
これはこれで面白い試み。
教科書に書いてある文章はなんとなくわかっても、
色々な企業とか業界での解釈の違いとかが分からないこともたくさんあるからねｗ

題目をかかげて自由に質問させてください、教えてください、のコーナーとして確立してもいいんじゃないかな。
各企業に本人の自覚もなく隠れたスペシャリストがきっといるはず。

Q01.パスワードをメールで別送信することについて、または暗号化について
A01.
SNSを独立して建ててメールを使わない(ウェブメッセンジャー)、またはメールがウェブのみでSNS化するってが主流になってきていて、メールでそもそも送らないようにしていっている。
厳密な意味で今までのようなメールは使われなくなっていくでしょうね。
ソフトウェアを導入するかしないかとして既に確立しているメールそのものの暗号化より、
Webの仕組みとしてかネットワークとしてのほうの暗号化のほうに触れていったほうが良いですよ。

Q02.ソフトの更新について
A02-1.
アンチウイルスソフトやOSとかソフトウエアの更新の問題は人としての行動がー自覚がー云々としかならないので、
システム上のチェックだけで終わらせてはいけなくて、
きちんとしていない人を共同のネットワークにいれてはいけないという強い決まりや、
罰則付きの契約とか規約で会社としてしばるべき。

A02-2.
SELinux設定をきちんと使いましょう
(監査ログ設定の話がなんでここでいきなり出てきたのかが最後まで本当に意味がわからず、変な反応しててすみません；
ホワイトリストとかの単語も言っていたので、安直に監査ログ設定をすべからく有効にしてすべてのサーバを常時監視できるようにすべきといいたいのか、サーバ運用を変えろと言いたいのか、それともただの例でそれ以外の領域のこともからめて総合的に何かすべきだと言いたかったのか。
そこまでは考えて無くて設定しろと本当に言いたいだけとは思えなかったんだけど上手に質問できなかった＾＾；
色々ごめんなさい。

仰っていた設定を本当に使うべきかの議論も
本職で知り得た知識や情報を公開してはいけないという規約に触れるのでここでかけないのですが 、
現場がその設定値をどうするかを決めて勝手にやると金額的にも損害を与えるという意味でかなりまずいので、設定値の変更は必ず上の人とよく相談してやってくださいね。)

Q03.生体認証について。組み合わせるべきで、安くはできないんでしょうねー
A03.
簡単に組み合わせて安価な製品も既にでてきてますよー
意外と簡単にお安くできるようになってきています。


以上。ざっくりでした。
※加筆、修正のご要望は随時承ります

前回よりは多少はマシだけど、
まだまだ時間配分はしっかりやろうぜってかんじ。

というか、
ぐだぐだでもセカセカに対しても誰一人その場できついこと言わなかったし、
かなり寛容な人が集まってるみたいなので、
セキュリティはプレゼン能力で出来る人か出来ない人なのかがはっきりと出てしまうのもあるので、
もっと現場の実績紹介とかでもいいし、基礎的な話でもいいし、
実績はあるけどプレゼンしたことない人に最初は下手でもいいからと、練習の場だとわりきって参加していただくとか、という方向性でも運営するってのはどうなんだろう？とも思うし、
(他の企業の運用方法とか実績とか聞ける機会はめったにないんで実はかなりお互い美味しい)

運営側が起きている問題にその場で気がつけてフォローすらできないなら、
登壇者が自主的にライトニングしたいと言わない限りはライトニングトーク枠を作らないほうがいいよとも思う。
谷山超えてきた歴戦の上級者と同じように企画して行動しようとしても潰れるだけなので、
出来ることからやればいいのになってところ。

前回はかなり優しくつっこんでるひとがいましたが、
出来たばかりの勉強会なのだから
まずは何分経過と教えるように動かないといけないとか、
主催者側がなんだかんだと察して動けるようなれるようになっていってね、頑張ってねという感じ。

資料の作り方がとか進め方やり方についてとかも本職でやってるはずだよね？とかも、
いずれはきちんと触れないといけないんだけど、
まだそこまでに至ってないというか・・・

まだまだこれからどんどん良くなれば良いのですよｗ


というわけで、
帰りに主催者さんたちと、
ラーメンと餃子とチャーハンセットを食べて帰宅しましたよ、と。

その時の雑談ネタですが、
辛さの単位はスコヴィル値ですねｗ
すっかり頭からすっとんでました。

主催者さんがデスソースをとっても欲しがっていたので（笑）、
次回までにみつけて買うことを忘れないようにしないと。

めもめも。