セキュリティLT会に参加してLTしてきた
これ
https://weeyble-security.connpass.com/event/110746/
「クリプトジャッキングについて」
ytakahashi1228さん
初っ端の登壇者(運営メンバー)の方が熱く映画のことを語っていた。 この方は必ず自分の自己紹介で最近見た映画ベスト3を紹介してくれる。結構楽しみ 最近は「ジャンパー」がベスト1らしい、あれは確かに爽快感があって私も好き
◼️クリプトジャッキングについて
クリプトジャッキングの危険性について説明されていた。
2016年からのランサムウェアの減少傾向↓に代わり、クリプトジャッキングという手法が台頭してきた経緯もあるそうな。
最近だとテスラ社の事例とか。
結局のところ仮想通貨を不正に取得することに応用されたりするんだけど
仮想通貨関連は本当に良くも悪くもいろんな技術があるよなぁ(小並) 仮想通貨、AI、IoTとかの話題になってきた技術は本当にセキュリティ考えさせられる。 大体、先駆けで導入したところはセキュリティをスルーして攻撃されて、世間に「仮想通貨は危険!」としらしめる...。日本の取引所は世界に迷惑かけすぎだぞ本当に。
「Eyes on Your Browsing History - あなたの"履歴"を狙う攻撃たち」
lmt_swallowさん
この人技術が振り切ってた。SECCONの上位入賞者でもあったりするとか。 学生さんなのに...すげえ。 ChromeにIssueをあげているとか...すげぇ 難読化javascript....これは結構好き
ブラウザ履歴の重要性
個人を表すデータソースとして重要ですよなという話をされていた
紹介されてた手法
- Visited-link Attack
- Cache-based Attack
visited擬似クラスでリンクを知る攻撃...
そういえばこの前のSECCONのcssインジェクションに影響を受けたのでこれ記事にしても良いなあと感じていた。
ブラウザが描画する60フレームを考えて攻撃とかすごいこと考えている...。
jsのイベントアクションの時間遅延の際を狙う攻撃とか。興味深いなぁ
こういった技術を時間のある学生のうちにもっとやっておけば良かったなと、勢いある若者をみると思わされる。 結局企業さんでセキュリティの話をするとき向こうが心配していることって、「自社に不利益があるかどうか」だし。こういうことはあまり重要視されないんだよなぁ。悔しいぜ。
「Hardening II SecurEach 参加してきました!」
sec-chick さん
SOC系の活動 ハニーポッター 趣味
- MITRE ATT&CKがアツい
- SIEM(しーむ)
・LTの内容
ハードニングプロジェクト
「衛る」技術の競技会
競技会の参加の話とか何聞いても面白いのずるい。
僕も今度レアな競技会参加してLTしよっと。
MRサービスの選定、 検知だけより、防御もしてほしい
WAF/IPS EDR リソースがほしい 検出内容とかも調査、展開してくれる、面白いなぁ。
セキュリティ対策の優先順位を学べるのは良いことだなぁ。
「タイムラインから読み解くマルウェア感染」
massu-tochimasu さん
システム運用・保守担当
COBOL...
タイムラインって?
アプリケーションの移動イベントとかのログ
マルウェアとかの感染時間がわかるよってやつ
「リダイレクトにご用心」
haruki1992
私の発表。 リダイレクトの3つの注意点をLTした
- オープンリダイレクト
- リダイレクトで情報の漏洩
- DDoS
特に3はまだ外で話していないのでこれを聞いてくれた方がCVEとか取ってくれればと思う。
「qrコードについて」
nachos さん
QRコードの紹介
QRコードのフォーマットってよくできているよなぁ。向きは気にならないし、チェックサムあるし。
話題のpaypayの話もされてた、資料つくるのはえぇ
QRコードのメリット、店舗が導入した際にクレカに比べてコストが安い。機材の導入もいらない
paypay
プリント型 店舗のバーコード読み取りしたりする
QRコード生成 お客さんに読み取ってもらう
ビックカメラでも店舗ごとで導入レベルが違うみたい。
QRコードの脆弱性...というよりは読み取るアプリ側の問題。
「徳丸さんの『間違ったCSRF対策』問題に挑戦してみた」
kmrr さん
CSRF対策の問題の展開をされていた
「目でgrepしろ」には笑った
・感じたこと NULLチェックシヨウネ。。。。
strcmp(arg, arg2)
argが配列だとNULLが返る....
「公開されてるバックドアを使ってみた」
tokoroten さん
CISMの◼資格◼️持ち、日本ではまだ取得者があまりいないそう。 最近お子さんが生まれたらしい、おめでたい!
b374k shell3.2
めちゃ親切なバックドア。gitに落ちてるらしい。
所感
どのLTも凄まじく面白かった。新しい技術も知れたし、お友達になりたい方もたくさん見つかったし。やはり情報発信することは大事であると再確認したLT会であった。ただ全然初学者向けじゃねーじゃん!!とも感じた。また参加しよう。
「脆弱性診断ええんやで」を聴講してきた
「脆弱性診断ええんやで」を聴講してきた
かの有名なEGセキュアソリューションズの松本さん
OWASP Japanプロモーションチームとしても活動されているとか。
OWASP Japanってもう○年目らしい。そんな長いの。。。
講義の内容
今回のテーマは脆弱性診断の仕組み 何故「思ってたのと違う」見積額が提示されるのかです。
ということでした。
私自身も普段、Webアプリケーション診断の見積もりを作成することがあるのですが、他の診断会社さんはどのような方式を用いているのだろう..?
気になったので参加してきました。
使用したツール
OWASP ZAP:
・世界中のセキュリティエンジニアに使用されているプロキシ
・ZAP Zed Attack Proxy
注意事項
ここからはOWASP ZAPを起動する場合の注意事項です。
OWASP ZAPはプロテクトモードで動かす。
なぜなら、管理外のサイトへの診断を実行する危険性が高い。
診断に使用するツールということは攻撃も可能なわけで...
ZAPは優秀なのでWebアプリケーションに使われているサードパーティAPIなんかも自動診断でフォローしてくれるんですね。
けれどこれは管理外のドメインに攻撃する危険性も孕んでいるのでしっかりと設定してから行うべし。
OWASPの設定 ツール > オプション > ローカルプロキシ
何故「思ってたのと違う」見積額が提示されるのか
見積額が想定外になる原因
対象画面数を基準に考察
発注者⇆受注者で対象画面の箇所が異なる
サイト調査とは
・クローリング(手動)
・診断対象選定
クローリングには補助的にツールを使うこともあるそう。
これも業務で思いますけど見積もりが自動化できたら最高ですよね。
もう取り入れてる診断会社さんとかあるのかな...?
診断すべき画面
パラメータを伴うリクエストにより動的に生成された画面 パラメータを措定して動的に生成
パラメータの例: 1. 検索文字列 2. ログイン時のIDとパスワード 3. 商品購入時の商品ID 4. セッションID, CSRF対策TOKEN....などなど
OWASP bricks https://sechow.com/bricks/index.html
クエリ文字列の例:
a. http://example.com/index.php?page=info.php&user=test&pswd=test
b. http://example.com/index.php?next=info.php&user=test&pswd=test
パラメータ名が同一なら値が異なっても同一のページとしてカウントする。(例外もある)
Cookieヘッダ
- ログイン処理が存在する。 一般に、Cookieにセッション情報を管理するための文字列が含まれるため診断対象となる。
- ログイン処理が存在しない。 Cookieが発行されていても、アプリケーションの内部で考慮しない、利用されない場合は診断対象外となる場合もある。
User-Agentヘッダ
UAを識別してレイアウト、メニュー構成を変化させる場合は診断対象外となる。 1. PC 2. スマホ 3. フィーチャーフォン(ガラケー)
POSTメソッド
- ボディ部分にパラメータを格納していることが多い
URLの一部がパラメータ
- 例1
http://example.com/user/123456/detail/
「123456」がユーザID - 例2
http://example.com/user/123456/detail/
http://example.com/user/123456/edit/
この二者は別々RailsなどのフレームワークやAPIが普及した背景もありURLの構造でルーティングするケースは増えた。
非同期通信
Ajaxなどで非同期に接続...JSONなどを取得するパターン
・自動入力フォーム(郵便番号を検索する)
・サジェスト機能など
ただし、完全な外部APIなどは管理外のためカウントしない
例外として
js,cssなどの静的コンテンツについている_v=12345のようなキャッシュ防止パラメータは診断対象としない。(動的な画面生成をしないため)
総括
やはり他の診断会社さんも同様の手法を用いて見積もりを作成しているのだなと安心した。 私は普段Burp Suiteに見積もり用の拡張機能を用いて手動でせっせと見積もりを行なっているけど、それでも見積もりの工数って馬鹿にならないといつも感じていた。。。
見積もりって気を遣ったり、工数がかかったりで大変なので診断を依頼する会社の担当者の目にこの記事が止まってくれれば良いと思う。。。。
所感
それとは別にもう一つ得た物があった。
講師の方とお話をするべく、講義が終わった後の懇親会にも参加した。
このIT業界で働いている方と話をすると皆さん共通の悩みを抱えていたりする。そんな中でもストレスとのうまい付き合い方(逃げ方)や、自分のロードマップ の考え方などをセキュリティエンジニアの大先輩の考えを聞けたのはかなり得をしたと思う。
せっかく勉強会に参加しても忘れてしまっては意味がないので久々に文字に起こしてみた。
次回はOWASPのLT会にも積極的に参加してみたいと思う。
Docker for Windows で no matching manifest for unknown in the manifest list entries っていうエラーが出ちゃったとき
最近、検証環境でもDockerをよく使うようになってきて
Docker熱が上がってきました。
さて今回、Windows10でDockerを立ち上げたときにLinuxマシンのようにすんなり起動してくれなかったのでメモ
環境
Windows10 Pro
Powershell / Docker for windows
解決方法
タスクバーのDockerのクジラさんを右クリックして
[setting]をクリック
すると以下の画面が立ち上がるので
experimental featuresにチェックを入れる
BasicをAdvanceにスライドするとexperimentalがtrueになっていることが確認できる。
終わったらApply
するとDockerが再起動するのでrunningになったらdocker pullすると実行できる
ヘッダから見るTomcatの推測
20210528: X-XSS-Protectionについて追記
. .はじめに
どうもみなさん、私です。
せっかく技術ブログ初めてみたのだから何か良いネタないかなぁと考えていたところ
ありましたありました。本日業務中に思ったこと、書き連ねていきます。
掲題の通りになりますが、今回サーバーアプリケーションを特定(推測)するという内容になります。
あくまで推測、しかも今回はTomcat限定です。
.何が推測できるのか
「僕はいまTomcatから応答を受け取ったかもしれない」...ということが推測できます。
.何を見るべきか
HTTPのレスポンスヘッダには以下のセキュリティヘッダを付与することができます。
主なセキュリティヘッダ
X-Content-Type-Options:
=> ブラウザにContent-Typeを明示できる。
X-Frame-Options:
=> HTMLのフレームの動作を制限できる。クリックジャッキングの対策に。
X-XSS-Protection:
=> XSSフィルタに関するヘッダ、無効にしたい時に活躍する。
※詳細なオプションについては割愛。
これらのセキュリティヘッダは普通ページ単位で設定するのではなく、公開されているサービス全体でヘッダに出力するべきです。
さて、ならば公開されているサービスのどこにアクセスしても共通の設定をするのであればTomcatの場合はWeb.xmlに以下の様に追記をすると思います。
<filter> <filter-name>HeaderSecurityFilter</filter-name> <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class> </filter> <filter-mapping><!--ここから--> <filter-name>HeaderSecurityFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping><!--このあたり-->
上記をweb.xmlへ追記してTomcatを再起動してアクセスすればどのページにアクセスしても
HTTPのレスポンスヘッダに以下のヘッダが出力されます。
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
ヘッダのオプションについては以下を参照ください。
Apache Tomcat 8 Configuration Reference (8.5.66) - Container Provided Filters
org.apache.catalina.filters.HttpHeaderSecurityFilterクラスを利用すれば
メジャーな脆弱性に対してはフォローされるわけですね。
.このヘッダが実は
上でweb.xmlに追記したxmlですが、
各ヘッダを出力させたくない場合は以下の様にします。
<filter> <filter-name>httpHeaderSecurity</filter-name> <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class> <init-param><!--ここから--> <param-name>xssProtectionEnabled</param-name> <param-value>false</param-value> </init-param><!--ここに設定を追記--> </filter> <filter-mapping> <filter-name>httpHeaderSecurity</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
この場合はセキュリティヘッダを出力する設定を施してからxssProtectionEnabledを打ち消す設定を記述しているということです。
X-Frame-OptionはSAME-ORIGINで運用されているサービスはまだ多く見かけますが、
わざわざX-XSS-Protection:を打ち消すような設定を行うというのは公開されているサービスでは考えにくいのでweb.xmlでセキュリティヘッダを設定していればほぼデフォルトのままorg.apache.catalina.filters.HttpHeaderSecurityFilterクラスの出力を利用するかと思います。
※20210528追記
X-XSS-Protectionはモダンブラウザで非推奨になり、代わりにCSPでの制御が推奨値になる。あえて打ち消し設定を導入しているサービスもあるかもしれません。
Hello World!
エンジニアのみなさん、そうでない方もこんにちは。
どうも、私です。
最近IT界隈のセミナーに参加することが増えて、もっと色んな技術者の方とお話できればなと考える様になりました。
なにやら最近エンジニアの先輩方は隙間時間に技術ブログを書いてスキルをアピールしているみたいなので自分も真似して書いて見ることにします。
日々の業務で見つけたことをつらつらと書き溜めていけたらよいなぁ。備忘録も兼ねて。