アカウント情報流出通知サービス「Have I been pwned?」、通知メール内のテキストが原因でSQLインジェクション脆弱性を意図せず突く 38
面白おかしい 部門より
headless曰く、
アカウント情報流出通知サービスHave I been pwned?（HIBP）からの通知メールがIT資産管理ツールGLPIのSQLインジェクション脆弱性を意図せず突き、GLPIを使用している企業のヘルプデスクに登録されていたサポートチケットをすべて上書きするトラブルが発生したそうだ（fyr.io、The 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か月近く前に修正済みだったと知ることになる。チケット自体は前夜にバックアップを取っていたため、失われたデータは少なかったとのことだ。
アカウント情報流出サービス？ (スコア:2)
「アカウント情報流出サービス」だと意味が違ってない？（苦笑）
Re: (スコア:0)
あなたのスルー力が試されていたのです。
Re: (スコア:0)
そうだ、そうだ、「アカウントの情報上書きサービス」とすべきだ (違
Re: (スコア:0)
修正したようですね
やればできるじゃない
ダマでやるのはどうかとおもうのだが
下部に出てるレコメンドの方は前のままだがそのうち変わるのかな
記事名のセンスが足りない (スコア:0)
ここはスラドも記事名を「';--have i been pwned? というロゴが、SQLインジェクション脆弱性を意図せず突く」とかにして、スラドをRSSで参照してるサイトを皆殺しにすべきだろう（違
Re:記事名のセンスが足りない (スコア:1)
実際に以前、HTMLタグをタイトルにしたタレコミかなんかで、配信先の表示がおかしくなってたことがあったな…
Re: (スコア:0)
自爆の可能性も
ロゴ (スコア:0)
頭4文字が何を意味しているのかよく分からん。
Re:ロゴ (スコア:4, 参考になる)
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列が条件に関わらず全て上書きされてしまうという手口…というか脆弱性というか。
Re: (スコア:0)
SQLインジェクションによる個人情報流出を引き起こす文字列と、ウインクしてる横向きの顔文字のダブルミーニング
Re: (スコア:0)
最初のシングルクォートいらなくない？
Re: (スコア:0)
眉毛を片方剃り落としてしまったんですよ(リンクはあえてはらない)
Re: (スコア:0)
そろそろこの漫画も古典かな…と思っていたらまだまだ現代劇ですね。
https://xkcd.com/327/ [xkcd.com]
こういうサービス使う人って (スコア:0)
流出アカウントのスクリーニングに使われる危険性とか考えないのかねえ
Re: (スコア:0)
セキュリティは妥協だよ、キミィ
Re: (スコア:0)
スクリーニングってこういうのを指してんだよね？
http://www.security-next.com/094772 [security-next.com]
どうやってスクリーニングに使うのかわからない。
HIBPとGLPIのどっちのサービスを指してるのかもわからない。
Re: (スコア:0)
当該サービスに入力されたアカウントは使用されている可能性が高い（つまり悪用価値が高い）と判定できる。
当該サービスからの返答（漏洩の有無）が正しいかは、利用者からは判別できないので、false-negative回答をしてもバレない。
こうすれば、スクリーニング済の（付加価値が付いた）アカウントリストが作成できる。
Re: (スコア:0)
使う人に危険性があるというのがさっぱりわからない。運営が確認のために入力したアカウントを横流したとかを疑ってるの？
Re: (スコア:0)
1. サービス提供側は何らかの漏洩アカウントリストを持っていると思われる。
2. 利用者が入力した情報そのものが悪用される恐れもあるし、漏洩アカウントリストのスクリーニングに利用される恐れもある。
3. サービスから回答される情報が正しいかどうか利用者は判別できない。
4. 利用者が入力した情報と漏洩アカウントリストが何に使われるか利用者はコントロールできない。
つまり、悪用される恐れのある情報を入力すると、正しいかどうかわからない情報が得られるサービス。
こういうサービスの利用は、メリットよりもリスクが高いと判断するのが賢明かと。
Re: (スコア:0)
おれが知らない悪用方法があるのかと思っちゃったけど、サービス自体が信用できないという漠然とした理由以外に危ない点はないみたいだし、取り越し苦労だったようだ。
Re: (スコア:0)
この手のサービスは
ネットで見かける「マイナンバー占い」などと変わらないレベルの不審さだな
主要言語にサニタイズの関数なりライブラリつけろよ (スコア:0)
自前でやるからバグが混入する
サニタイズする関数やライブラリが主要言語に標準であればいい
Re:主要言語にサニタイズの関数なりライブラリつけろよ (スコア:2)
SQLインジェクションの標準的な対策はサニタイズじゃなくてステートメント利用ですよ。
Re: (スコア:0)
20年近く前でもステートメントなんて常識に近かったのに
未だに使ってないアホな所あるの？
百歩譲って数十年前から稼働し続けてるとかならまだギリギリ理解できるが（それでも普通は対応する）
レガシーASPの時ですらやってたぞ。
今どきなら学生が作ってすら当然のように対策してるよな。
Re: (スコア:0)
修正コミット [github.com]見ると、パラメータがエスケープされるようにしましたみたいな感じだな。
まあ今だったらこなれたライブラリを使うんだが、GLPIはスタートが2003とかみたいだし
開発リソースが足りないとテコ入れ改修は難しいのかな、ライブラリは流行り廃りもあるし。
それでも普通は対応する
プロジェクトのお守りする立場だったら考えるけど、一開発者ならあんま振られたくないお仕事だなw
Re: (スコア:0)
これ、PHPのプロダクトなんですね。
PHPは知らないので調べたみたら、PHPでDB接続するには、PDO（PHP標準）を使用する様で、このPDOが実装されたのが 5.1.0（2005年リリース）だそうです。
なので、2003年のプロダクトだと非標準のライブラリを使ってるわけで、そのライブラリがステートメント対応してなければ、上記の対応でもしょうがないですね。
Re: (スコア:0)
自分はステートメント使わずにいつも文字列連結だなぁ。
エスケープは忘れてない。
Re: (スコア:0)
ステートメント使ったところで信頼出来ない文字列でSQL組み立ててりゃダメだろ。
Re:主要言語にサニタイズの関数なりライブラリつけろよ (スコア:1)
少なくとも本件の原因となったSQLインジェクションは防げるわけだから十分じゃないの。
エスケープしないとならない文字のチェックはSQLエンジンに任せるのが確実で、それを自前でやってどれだけ効果があるのか疑問だし、そもそもステートメント使ってれば、発生する事象は検索・更新できないと言う方向になるわけで、データを壊したり流出させる可能性は限りなく低いと思うのだけど。
Re: (スコア:0)
問い合わせ言語に独自文法のSQLなんて使わずにXML辺りにしときゃ良かったんじゃなかろうか。
いろんなプロトコルがそうだけど、コンソールに人間が対話的に入力するみたいなイメージでプログラム間の通信を定義すること自体がトラブルの元だとしか思えない。
まぁ現状なら自前でやらず信頼できるライブラリかなんか使えとしか言えないが。
Re: (スコア:0)
XMLでパラメータ指定するときにエスケープ忘れたら同じよ。
HTMLだけどXSSとかさ。
Re: (スコア:0)
サニタイズ笑
Re: (スコア:0)
サニタイズ言うな！キャンペーンとか懐かしす。
セキュリティホール以前に機能面での不具合だもんなぁ。こんなの。
Re: (スコア:0)
「サニタイズ」って英数字を全角に変換することでしょ？
Re: (スコア:0)
全角英数字と（）を使うやつを許さない。
特にファイル名に使われてるのを見るとその日は一日中不機嫌になるので注意して。
Re: (スコア:0)
一緒に仕事してるやつもスラド見てるのがわかってて、直接言うと角が立つからここに書き込んでるってこと？
脆弱性スキャナーになってしまったか (スコア:0)
徳丸先生のこれを思い出しました。
SQL インジェクションによりクレジットカード情報を盗むデモンストレーション
https://www.youtube.com/watch?v=Vvgmeu128ak [youtube.com]
HIBP は誰かの Gmail アドレスを入れて、パスワードが判明したら、
Google Dorks でその人が利用している Web サービスを調べてみて、
ログインするためのものかと思っていましたので、こういう副作用
があるとは意外でした。
SQLの文法自体が脆弱に感じる (スコア:0)
「気を付ける」というのは対策とは言えない。人に依存しすぎ…