パスワードを忘れた? アカウント作成
14206573 story
バグ

アカウント情報流出通知サービス「Have I been pwned?」、通知メール内のテキストが原因でSQLインジェクション脆弱性を意図せず突く 38

ストーリー by hylom
面白おかしい 部門より

headless曰く、

アカウント情報流出通知サービスHave I been pwned?(HIBP)からの通知メールがIT資産管理ツールGLPIのSQLインジェクション脆弱性を意図せず突き、GLPIを使用している企業のヘルプデスクに登録されていたサポートチケットをすべて上書きするトラブルが発生したそうだ(fyr.ioThe Register)。

問題の脆弱性CVE-2020-11032はSQLインジェクション文字列を含むチケットを登録し、addme_assignまたはaddme_observerボタンをクリックするとSQLインジェクションが引き起こされるというものだ。この脆弱性はGLPI 9.4.6で修正されており、問題発生時にはGitHubで既に公開されていた。しかし、この時点ではGLPIプロジェクトのダウンロードページは更新されておらず(5月29日のInternet Archiveスナップショット)、影響を受けたMatt氏の会社では脆弱性のあるGLPI 9.4.5を使用していたそうだ。現在はGLPIプロジェクトのダウンロードページでもGLPI 9.4.6が公開されているものの、あわてて差し替えたのかバージョンの下には9.4.5と同じ日付(18/12/2019)が記載されている。

HIBPからの通知メールには「';--have i been pwned?」というロゴが入っているのだが、画像ではなくテキストであり、これがSQLインジェクションを引き起こしたらしい。Matt氏の会社ではヘルプデスクのサポートアドレスを通知先としてHIBPに登録しており、このアドレスで受信した電子メールは自動でチケットに登録される仕組みになっていたという。そのため、Matt氏がチケットを自分に割り当てたところSQLインジェクションが引き起こされ、登録済み全チケットの説明フィールドの内容が消去されてHIBPロゴの一部に置き換えられてしまったとのこと。

Matt氏は実験を繰り返し、「';-- "」の6文字を入力したフィールドが影響を受けることを確認。ここまで手間をかけたうえでバグを報告しようとGitHubページを訪れたところ、1か月近く前に修正済みだったと知ることになる。チケット自体は前夜にバックアップを取っていたため、失われたデータは少なかったとのことだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 「アカウント情報流出サービス」だと意味が違ってない?(苦笑)

    • by Anonymous Coward

      あなたのスルー力が試されていたのです。

    • by Anonymous Coward

      そうだ、そうだ、「アカウントの情報上書きサービス」とすべきだ (違

    • by Anonymous Coward

      修正したようですね
      やればできるじゃない

      ダマでやるのはどうかとおもうのだが
      下部に出てるレコメンドの方は前のままだがそのうち変わるのかな

  • by Anonymous Coward on 2020年06月09日 16時33分 (#3830158)

    ここはスラドも記事名を「';--have i been pwned? というロゴが、SQLインジェクション脆弱性を意図せず突く」とかにして、スラドをRSSで参照してるサイトを皆殺しにすべきだろう(違

  • by Anonymous Coward on 2020年06月09日 16時58分 (#3830179)

    頭4文字が何を意味しているのかよく分からん。

    • Re:ロゴ (スコア:4, 参考になる)

      by Anonymous Coward on 2020年06月09日 17時31分 (#3830205)

      SQL文で
      'は文字列の終了(開始もだが)
      ;は命令の終了
      --はコメントの始まり
      になるので単純に文字列を結合して実行するようなプログラムだとSQLインジェクションが出来てしまう。
      最も基本的?なSQLインジェクションの手口なのでロゴに使用したんでしょう。

      SQLを文字列で結合して作る単純な(ダメな)例
       "UPDATE hoge_table SET fuga = '" + user_input + "' WHERE id = piyo;"
      このuser_inputに ';--have i been pwned? が入力されてくると
       UPDATE hoge_table SET fuga = '';--have i been pwned?' WHERE id = piyo
      となり、--の後はコメントになるので実際に実行されるのは
       UPDATE hoge_table SET fuga = '';
      hoge_table のfuga列が条件に関わらず全て上書きされてしまうという手口…というか脆弱性というか。

      親コメント
    • by Anonymous Coward

      SQLインジェクションによる個人情報流出を引き起こす文字列と、ウインクしてる横向きの顔文字のダブルミーニング

      • by Anonymous Coward

        最初のシングルクォートいらなくない?

        • by Anonymous Coward

          眉毛を片方剃り落としてしまったんですよ(リンクはあえてはらない)

    • by Anonymous Coward

      そろそろこの漫画も古典かな…と思っていたらまだまだ現代劇ですね。
      https://xkcd.com/327/ [xkcd.com]

  • by Anonymous Coward on 2020年06月09日 17時28分 (#3830204)

    流出アカウントのスクリーニングに使われる危険性とか考えないのかねえ

    • by Anonymous Coward

      セキュリティは妥協だよ、キミィ

    • by Anonymous Coward

      スクリーニングってこういうのを指してんだよね?
      http://www.security-next.com/094772 [security-next.com]

      どうやってスクリーニングに使うのかわからない。
      HIBPとGLPIのどっちのサービスを指してるのかもわからない。

      • by Anonymous Coward

        当該サービスに入力されたアカウントは使用されている可能性が高い(つまり悪用価値が高い)と判定できる。
        当該サービスからの返答(漏洩の有無)が正しいかは、利用者からは判別できないので、false-negative回答をしてもバレない。
        こうすれば、スクリーニング済の(付加価値が付いた)アカウントリストが作成できる。

        • by Anonymous Coward

          使う人に危険性があるというのがさっぱりわからない。運営が確認のために入力したアカウントを横流したとかを疑ってるの?

          • by Anonymous Coward

            1. サービス提供側は何らかの漏洩アカウントリストを持っていると思われる。
            2. 利用者が入力した情報そのものが悪用される恐れもあるし、漏洩アカウントリストのスクリーニングに利用される恐れもある。
            3. サービスから回答される情報が正しいかどうか利用者は判別できない。
            4. 利用者が入力した情報と漏洩アカウントリストが何に使われるか利用者はコントロールできない。

            つまり、悪用される恐れのある情報を入力すると、正しいかどうかわからない情報が得られるサービス。
            こういうサービスの利用は、メリットよりもリスクが高いと判断するのが賢明かと。

            • by Anonymous Coward

              おれが知らない悪用方法があるのかと思っちゃったけど、サービス自体が信用できないという漠然とした理由以外に危ない点はないみたいだし、取り越し苦労だったようだ。

              • by Anonymous Coward

                この手のサービスは
                ネットで見かける「マイナンバー占い」などと変わらないレベルの不審さだな

  • 自前でやるからバグが混入する
    サニタイズする関数やライブラリが主要言語に標準であればいい

    • SQLインジェクションの標準的な対策はサニタイズじゃなくてステートメント利用ですよ。

      親コメント
      • by Anonymous Coward

        20年近く前でもステートメントなんて常識に近かったのに
        未だに使ってないアホな所あるの?
        百歩譲って数十年前から稼働し続けてるとかならまだギリギリ理解できるが(それでも普通は対応する)
        レガシーASPの時ですらやってたぞ。
        今どきなら学生が作ってすら当然のように対策してるよな。

        • by Anonymous Coward

          修正コミット [github.com]見ると、パラメータがエスケープされるようにしましたみたいな感じだな。

          まあ今だったらこなれたライブラリを使うんだが、GLPIはスタートが2003とかみたいだし
          開発リソースが足りないとテコ入れ改修は難しいのかな、ライブラリは流行り廃りもあるし。

          それでも普通は対応する

          プロジェクトのお守りする立場だったら考えるけど、一開発者ならあんま振られたくないお仕事だなw

          • by Anonymous Coward

            これ、PHPのプロダクトなんですね。

            PHPは知らないので調べたみたら、PHPでDB接続するには、PDO(PHP標準)を使用する様で、このPDOが実装されたのが 5.1.0(2005年リリース)だそうです。
            なので、2003年のプロダクトだと非標準のライブラリを使ってるわけで、そのライブラリがステートメント対応してなければ、上記の対応でもしょうがないですね。

        • by Anonymous Coward

          自分はステートメント使わずにいつも文字列連結だなぁ。
          エスケープは忘れてない。

      • by Anonymous Coward

        ステートメント使ったところで信頼出来ない文字列でSQL組み立ててりゃダメだろ。

        • 少なくとも本件の原因となったSQLインジェクションは防げるわけだから十分じゃないの。

          エスケープしないとならない文字のチェックはSQLエンジンに任せるのが確実で、それを自前でやってどれだけ効果があるのか疑問だし、そもそもステートメント使ってれば、発生する事象は検索・更新できないと言う方向になるわけで、データを壊したり流出させる可能性は限りなく低いと思うのだけど。

          親コメント
    • by Anonymous Coward

      問い合わせ言語に独自文法のSQLなんて使わずにXML辺りにしときゃ良かったんじゃなかろうか。
      いろんなプロトコルがそうだけど、コンソールに人間が対話的に入力するみたいなイメージでプログラム間の通信を定義すること自体がトラブルの元だとしか思えない。

      まぁ現状なら自前でやらず信頼できるライブラリかなんか使えとしか言えないが。

      • by Anonymous Coward

        XMLでパラメータ指定するときにエスケープ忘れたら同じよ。
        HTMLだけどXSSとかさ。

    • by Anonymous Coward

      サニタイズ笑

      • by Anonymous Coward

        サニタイズ言うな!キャンペーンとか懐かしす。
        セキュリティホール以前に機能面での不具合だもんなぁ。こんなの。

        • by Anonymous Coward

          「サニタイズ」って英数字を全角に変換することでしょ?

          • by Anonymous Coward

            全角英数字と()を使うやつを許さない。
            特にファイル名に使われてるのを見るとその日は一日中不機嫌になるので注意して。

            • by Anonymous Coward

              一緒に仕事してるやつもスラド見てるのがわかってて、直接言うと角が立つからここに書き込んでるってこと?

  • by Anonymous Coward on 2020年06月09日 23時39分 (#3830418)

    徳丸先生のこれを思い出しました。

     SQL インジェクションによりクレジットカード情報を盗むデモンストレーション
     https://www.youtube.com/watch?v=Vvgmeu128ak [youtube.com]

    HIBP は誰かの Gmail アドレスを入れて、パスワードが判明したら、
    Google Dorks でその人が利用している Web サービスを調べてみて、
    ログインするためのものかと思っていましたので、こういう副作用
    があるとは意外でした。

  • by Anonymous Coward on 2020年06月10日 12時37分 (#3830626)

    「気を付ける」というのは対策とは言えない。人に依存しすぎ…

typodupeerror

にわかな奴ほど語りたがる -- あるハッカー

読み込み中...