yohgaki's blog

タグ: 脆弱性

  • Railsのリモートコード実行脆弱性、今昔

    去年、今年とStruts2、Drupalのリモートコード実行脆弱性が問題になりました。記憶に新しい方も多いと思います。Railsにもリモートコード実行脆弱性が複数レポートされており、Railsユーザーであればよくご存知だと思います。

    ざっと思い付く昔の脆弱性から最近の脆弱性まで簡単にまとめてみます。

    (さらに…)

  • PHP 5.6.38他で修正された任意コンテンツ送信脆弱性について

    PHP 5.6.38/7.0.32/7.1.22/7.2.10でApache2handler SAPIのセキュリティバグが修正されました。

    13 Sep 2018
    Apache2:

    Fixed bug #76582 (XSS due to the header Transfer-Encoding: chunked).

    http://php.net/ChangeLog-5.php#5.6.38

    攻撃者が送った出鱈目な攻撃用データがPHPプログラムに関係なくブラウザに出力されてしまう問題が修正されました。

    この脆弱性の影響が正しく伝わっていないようなので、簡単に紹介します。

    (さらに…)

  • PHPのPharを使ったコード実行

    phar（PHPプログラムを１つのアーカイブファイルにまとめて利用するファイル形式）のメタデータにserializeが使われている点は議論になったことがあるように思います。そもそも危険なpharファイルだったら意味なし、という結論だったはずです。結構前の事なので詳しくは記憶していません。

    pharモジュールはデフォルトで有効化されており、影響範囲は大きく危険度は高いです。

    BlackHat 2018でpharアーカイブを利用した攻撃方法が紹介されています。簡単に紹介します。詳しい内容は発表者のPDFを参照ください。WordPress, Type3, TCPDFへの攻撃方法が記載されています。

    (さらに…)

  • APIを過信するとおかしな事になる例 – SAML認証成り済まし

    今年の2月にSAMLライブラリの脆弱性が報告されていたことを覚えている人も居ると思います。

    この脆弱性はXMLコメント（<!– –>）の取り扱いの違いによって、本来のユーザーではない攻撃者を認証してしまう事が問題であったとしています。

    攻撃用の文字列サンプルは以下のような物です。

    <NameID>user@example.com<!—->.evil.com</NameID>

    攻撃が可能になる理由はXMLコメントの取り扱いの違いにあります。

    • あるライブラリは<!– –>までの文字列（user@example.com)までをNameIDとして取り扱う
    • 別のライブラリは<!– –>を取り除いた文字列（user@example.com.evil.com）をNameIDとして取り扱う

    これにより攻撃者が別のユーザーに成り済ませてしまう問題が発生しました。1

    (さらに…)

  • インジェクション攻撃は3種類ある

    インジェクション攻撃、とは言ってもそのインジェクション対象によって影響が異なります。インジェクション攻撃の対象によって2種類、コードとデータ、に分類できます。Webシステムの場合、リクエストのインジェクションを別のインジェクション攻撃と考えた方が解りやすいので、大まかに分類して3種類に分類できます。

    インジェクション脆弱性は絶対に避けなければならない脆弱性である、と認識されていると思います。しかし、3種類あるインジェクション攻撃のうちデータのインジェクションに対するリスク認識が極端に甘いように感じています。

    ※1 Webシステムを前提としていますが、大抵のシステムは「コード」と「データ」のインジェクションを考慮すれば十分である場合が多いです。

    ※2 そもそもコードを実行する機能そのものに”コード”を実行させるのは”正当な機能”です。eval( $_GET[‘code’] ) など、これらの機能の基礎的使い方間違いは考慮しません。ここでは本来コードではないデータを介するコードインジェクション、例えば eval( ’var = ‘. $myvar. ‘;’) など、及び、データその物で攻撃するデータインジェクションを取り上げています。

    (さらに…)

  • まだ誰も知らない脆弱性／攻撃に備える方法

    セキュリティを考えると全ての入力データはアプリケーションがバリデーションすべきで、長さ／形式は厳格にバリデーションすべきです。1

    厳格なバリデーションは開発者が意識／把握していない各種インジェクション脆弱性にも対応できること、インジェクション攻撃が持たらす被害が致命的であることが、その理由です。

    適切なバリデーションは最強のセキュリティ対策の１つ2です。強いデータ型は弱いバリデーションの一種ですが、それでもセキュリティ対策として高い評価を得ています。にも関わらず強いバリデーションである厳格なデータバリデーションはコンピューターサイエンティストのセキュリティ専門家3以外にはあまり評価されていないように感じます。

    今回は低レベルのライブラリにもコードインジェクション脆弱性のリスクがあること、その対策としてバリデーションが如何に効果的であるか紹介します。

    (さらに…)

  • Python 2.7.14から学ぶセキュリティの基本

    Python 2.7.14が2017/9/16にリリースされました。Pythonの開発はバージョン3系に移行しており、2系はセキュリティ修正のみのリリースになっています。とは言ってもモジュールの変更を見るとバグフィックスやドキュメント修正も含まれているようです。

    Python 2.7.14のリリースはソフトウェアセキュリティの基本を学ぶには良い題材になります。

    (さらに…)

  • Railsユーザーが真っ先にするべきセキュリティチェック – Brakeman

    Railsユーザーがソースコード検査やWebサイト診断を受ける前に真っ先に使った方が良いセキュリティ検査ツールがあまり使われていないように感じています。

    Brakemanはかなり良くできたツールです。私は何年も前から補助的に使っています。

    (さらに…)

  • 2017年版OWASP TOP 10

    追記： 8月現在では、OWASP TOP 10 2017はWAFのプロモーションになっている、OWASP Proactive Controlsの”全ての入力をバリデーションする”と重複している、などの点が議論になりRCはリジェクトされ11月にリリースを目指して調整中になっています。

    追記2：正式版が2017年12月にリリースされました。ここで紹介している脆弱性はA10（10番目の脆弱性）「不十分なログとモニタリング」として登録されました。WAFが必要であるかのような記載が削減されましたが、脆弱性の本質（入力検証しない＆対応しないアプリは脆弱なアプリ）は変わりありません。

     

    このテーマついては既にブログは書いています。このエントリでは追加でQ＆Aを記載しています。

    https://blog.ohgaki.net/2017-owasp-top-10-changes-web-security-rule

    元々はこのスライドは非公開にするつもりでしたが、公開可能な内容で公開することにしました。

    https://www.slideshare.net/yohgaki/2017owasp-top-10

    開発会社としてはどうすれば良いのか？と質問を頂いたので追記します。

    (さらに…)

  • 出鱈目なシグニチャのhash_hkdf関数を安全に使う方法

    ユーザーが間違った使い方をしないよう、PHP 7.1に追加されたhash_hkdf関数のシグニチャが出鱈目である件について書いておきます。使い方を間違えると脆弱な実装になるので注意してください。

    (さらに…)

  • コンピュータは数値さえ正確に扱えない

    コンピュータで数値を正確に扱うのは「実は結構難しい」です。つまり「コンピューターは数値を正確に扱えない」という事です。「コンピューターが数値を正確に扱えない？！何を言ってるんだ？！」と思った方は是非読んでみてください。

    (さらに…)

  • Struts 2の脆弱性でHTTPのContent-Typeヘッダーからリモートコード実行ができる理由

    Apache Struts2 の脆弱性対策について(CVE-2017-5638)(S2-045)は

    • HTTPプロトコルのContent-Typeヘッダーでリモートからコード実行ができる

    という問題です。どうして「Content-Typeヘッダー」でコード実行ができたのか？気になったので調べたメモです。

    コード実行ができた理由は「国際化（翻訳）用のメッセージ処理メソッドが、プログラミング言語のようにパースして実行する仕様」であったことでした。気にしていないとこのパターンでリモートコード実行ができてしまうコードも在ると思います。

     

    (さらに…)

  • PHPのmt_rand()/rand()問題

    PHPのmt_rand()とrand()には状態の初期化／再初期化に問題があります。話しを簡単にするためにrand()をmt_rand()のエイリアスにする提案

    https://wiki.php.net/rfc/rng_fixes

    が適用された状態を前提にMT rand問題として解説します。しかし、基本的には古いPHPでrand()を使う場合も同じ（かそれ以上）の問題があります。

    そもそもMT randは暗号理論的に安全な乱数生成器ではありません。安全な乱数の取得に使ってはなりませんが、MT rand以前の乱数に比べ予測が困難、ということで不適切な箇所で利用しているケースが散見されます。

    結論から言うと、MT randで生成された乱数値は安全ではなく非常に危険1、です。

    (さらに…)

  • セッションデータインジェクション

    PHP 5.6.25/7.010以降で修正されたセッションデータインジェクション

    • Fixed bug #72681 (PHP Session Data Injection Vulnerability). (CVE-2016-7125)

    の解説です。

    この脆弱性を利用するとオブジェクトインジェクションが簡単に行えます。結構深刻な問題ですが、あまり話題にはなっていないように思います。

    (さらに…)

  • ソーシャルメディアフィンガープリントとその対策

    ソーシャルメディアフィンガープリントがまた話題になっているようです。ソーシャルメディアフィンガープリントとは何か？およびその対策です。

    ソーシャルメディアに限らず、ログインをサポートしているサイトであれば、全て対象です。

    (さらに…)