Firebaseの設定ミスは、フロントエンドがデータベースエントリを直接書き込もうとすることから生じることが多いけど、これらの開発者は古いスタイルのバックエンドで構造化されたオブジェクトをFirebaseに送信していたから、その問題はある程度軽減されていたみたいだね。

「sqlmapのことは聞いたことがあったけど、こんなに使えるとは思わなかった。ブログでは、今の時代には誰も自分でデータベース統合を作らないから、sqlmapがほとんど役に立たなくなったって正しく説明してるけど、あの頃は本当に複雑なウェブサービスはほぼ全てsqlインジェクションに弱かった気がする。sqlmap用の小さなラッパーを書いて、スクレイパーの結果に接続させて、サーバーに送られるデータ全てに対して一晩中走らせれば、翌日には選べるエントリーポイントがたくさんできてた。WAFにもある程度対応してたし。もう数年ITセキュリティから離れてるけど、sqlmapのコマンドライン引数は昨日のことのように覚えてるよ。」

同意するよ、こういう調査やデータ抽出がここまで抽象化されてるとは驚きだね。何年もかけて進化してきたのは驚かないけど、こんなに簡単になったとは思わなかった。

「sqlmapのことは聞いたことがあったけど、データベースにアクセスするURLを渡すだけで、ツールがSQLインジェクションの脆弱性があればデータベースの内容をダンプする方法を基本的に見つけてくれるとは思わなかった。」セキュリティについて人に伝えたい教訓が一つあるとしたら、敵を過小評価しないことだね。彼らは他の分野と同じように何十年もツールを作ってきたんだ。システムの穴を見つけて、任意の制約されたシェルコードの断片を実行できるようにする技術は、特別なものじゃなくて、オフ-the-shelfの技術なんだ。基本的なビルディングブロックだよ。実際に洗練された攻撃者はそこから積み上げていく。もし$YOUが、スクリプトキディたちがサーバーに対してWordpressの脆弱性を無差別に攻撃するのが攻撃者の洗練さの頂点だと思っているなら、$YOUは彼らに対して取り返しのつかない不利な状況にいるよ。

sqlmapはDBをダンプする方法を見つけるだけじゃなくて、SQLを解析して、インジェクションペイロードに変換してサーバーで実行する便利な「シェル」モードも提供してる。まるでmysqlやsqliteのシェルを持ってるみたい。ファイルを読み込んだり、コマンドを実行したりすることもサポートしてる（サーバーがそれをサポートしていて、DBユーザーが適切な資格情報を持っている場合）。さらに、盲目的なSQLiを悪用する方法も知っていて、そのためのトリックがいくつかある。HTTPエラーコードに基づいてクエリが成功しているか失敗しているかを判断できることが多いし、サーバーをハングさせるためにいろんなSLEEP()インジェクションを試すこともある。盲目的なSQLiの機会を見つけると、並行して大量のリクエストを行うことで、データベース全体を一ビットずつダンプすることができる。HTTPリクエストヘッダーが詰まったファイルを渡すと、自動的に潜在的なインジェクションポイントを見つけて、提供されたヘッダーと同じ形式のリクエストを送信してくれる。適切なMITMプロキシとスクリプトを使えば、SQLインジェクションテストをほぼ自動化できる。リクエストを偽装するオプションや、WAFをバイパスするためのオプション、カスタムプロトコルを使ってリクエストを送信するオプションなど、たくさんの機能がある。全体的に見ても、本当に良く設計されたツールだよ。

このアプリには詳しくないけど、読んだ感じだと、ターゲットの電話に忍び込んで「設定」ロゴのapkをインストールして、全ての権限を与えることに頼っているみたいだね（インストーラーが各権限タイプのフル権限を手動で与えたり、バッテリー最適化を無効にするプロセスを助けるんだと思う）。Androidは、そういうアプリにフル権限を手動で委譲することを許可しているんだ。

自分で悪意のプロキシや悪意のWi-Fiホットスポットを設定して、定期的にスマホを接続するのが、こういうマルウェアの検出に役立つかもしれないと思ってる。ちょっとパラノイアの境界に近づいてきたから、試してみようかなって感じ。

そうだね、この一連の行為は完全に違法で、こんなことを公然と（しかも誇らしげに）ブログに書くなんて驚きだよ。今すぐ弁護士に相談した方がいいかもね。

それはCatwatchfulにとって、自分を告発する面白いエクササイズになりそうだね。ビジネスの損失を数値化しなきゃいけないから、違法な事業の価値を認めることになるし。でも、YOLOだよね？行こうぜ！

ハッキングに関する記事の半分は、実際には起こってないことを人が主張してるだけの偽物なんだよね。誰もそれをチェックしないし、発表する頃にはその脆弱性は「修正」されてるから、自分で確認することもできない。著者が言ったことを実際にやった証拠がない限り、実際のケースにはならない。この話はちょっと信じがたいけど、ファンタジーとしては面白いね。

このデータベースが公開されてないことや、開示が出版前に下にリストされてることを考えると、これはほとんどホワイトハットの活動で、ターゲットにしてる会社を助けてるだけだよね。ますます多くの企業が、WAFを導入するなど、助けを受け入れるようになってる。確かに、こういう状況では本名を使うべきじゃないと思う。ターゲットの会社との前例がないからね。ただ、Catwatchfulはストーカーアプリのために無意味な告訴を追求する理由がないと思う。実際にサービス提供者が反応しない限り、損害はほとんどないだろうし。こういう人たちには何も起こらないし、データセンターやホスト、プロバイダーがDMCAの苦情以外に本当に気にすると思う？（著作権で保護されてない不正なコンテンツをホストプロバイダーに報告して、待ってみて…歯が抜けるまで待つことになるよ）ストーカーアプリのユーザーが、アプリが一度や二度「ハッキング」されたことを気にすると思う？アプリの開発者たちも、ユーザーの50%以上が他人のデバイスにインストールしてる可能性があるのに、こういうことが合法だって法的世界に思い出させたいと思ってるのかな？個人的には、こんな怪しいものをリリースしたら、法的な問題は避けたいけどね。

誰かが指摘したように、管轄権の問題があるよね。でも、ダイグルは責任を持つことや道徳的に正当化されることを考えたんじゃないかな。Catwatchfulアプリを使って、被害者にストーカーされてることを知らせるのは魅力的だったはず。例えば、電話番号やSNSのハンドルを取得して、SMSやDMで被害者に連絡する（アプリが録音された会話で被害者のハンドルを明らかにする場合）。または、IMEI番号を取得して、通知を行うことができるネットワーク事業者や地元の当局に渡すことも考えられる。多くの被害者を助けるかもしれないけど、場合によってはうまくいかないこともあるかもね。

ユーザーのパスワードを取得するのが彼らの目的の一部だと思うよ。だから、どこかに保存されている必要があるね。

たぶん、彼らは気にしてなかったんだろうね。

年を重ねるうちに学んだことは、才能ある開発者でもセキュリティが苦手なことがあるってこと。多くの場合、学校で教えられたり、トレーニングでカバーされたりすることじゃないから、そういうマインドセットがないんだよね。他の技術には優れていても。もし公共のインターネットにさらされるものを作るなら、「どうやって人がこれを壊したり、悪用したり、ハッキングしたりするか」を考えるプロセスを経るべきだよ。そうしないと、確実にステップを見逃してる。

マルウェア開発者は、セキュリティの衛生よりも機能性や市場投入のスピードを優先することが多いんだ。彼らは「隠れていれば安全」という誤った考えのもと、自分たちのインフラが攻撃されることはないと思っているんだよね。

どうやってその問題を診断したの？私のiPhoneは家電みたいに感じるし、ますます遅くてバグも多いんだよね！