運営サイトの脆弱性を指摘されました

この記事は約4分で読めます。

こんにちは

昨日は、ネタ切れしてしまい。。更新をお休みしました。(^_^;
今日のネタをかけば良かったのですが、書く事自体に悩んで、また気分が乗らず良いきっかけかな?と思いお休みました。

黙ってよう(笑)かとも思いましたが、自分への戒めと情報共有の意味も含めて記事にしようと思います。

先日、このサーバをお借りしている、「さくらインターネット」さんからメールが来ました。

外部からの情報提供があり、「暗号通貨詐欺サイトへ誘導する攻撃に悪用」されているコンテンツがあるとの事です。以下はメールのスクショ。

提供していただいた情報を元に確認してみると、かなり昔から運営していた金魚関係の2つのサイトの攻撃(悪用)URLがありました。

リンクを貼るのはどうかと思うので、サイト名だけ公開します。以下の2つです。

・金魚サーチ
・金魚ランキング

攻撃コードを見ると、該当サイトのプログラムを経由して外部のページを表示すると言う物に見えます。
要するに金魚サーチ等のURLを表示すると、実際に表示されるのが全然関係ないサイトが表示される物でした。
Cookieの盗聴の可能性もありますが、この2つのサイトは盗聴される様なCookie自体の保存はないので問題ないと思います。

これはダメなヤツですね(T_T)
と言う事で、メールを頂いて、30分後には一週間を目処に対応するので!とサイトを閉鎖しました。

その後、現象と実際使っているプログラムはフリーのCGIプログラムで、かなり古い物です。うろ覚えですが、運用を開始したのが2004年と16年前で、その後10年弱?ぐらいはバージョンアップをしていましたが、最近は金魚飼育自体は殆どしていない事とアクセス数が少ない事もあり、閉鎖するか悩みましたが利用者がいる事もあり、先延ばしにしていました。これがいけなかったです。(^_^;

プログラムを見ると、どちらも「クロスサイトスクリプティング攻撃」と言われる物ですが、プログラム実装自体が性善説的な感じで、外部サイトへ渡されたパラメータを使って、リダイレクトする物でした。メイン機能の1つである事から、ちょっとした対応で直せそうではありますが、プログラム内の構造調査がかなり面倒かなと思いました。利用者数も凄く減っている事からもモチベーションが維持できず、そのまま対応せずにサービス自体を停止する事にしました。

余談ですが、もしや!?と思ってfirefoxで該当ページを表示したら赤かったです(^_^;

指摘されている情報元のインシデントを見ると(英語サイトなので、日本語に自動翻訳しました)。既に解決済みになっていて、放置すれば削除されそうな感じです。
閉鎖したので、削除されなくても別に構いませんが。。

と言う事で、運営しているサイトは責任を持って!と言う事を再認識ました。

使っている2つのCGIは別々の提供元で、1つは閉鎖、1つはライセンス形態をコピーレフトに変更して残ってました。

CGIプログラム名を書いておくと、「Yomi-Search」と、「Ranklink」です。
該当するプログラムを利用しているサイトオーナーさんは対応した方が良さそうです。

ちなみに「Yomi-Search」の方は、inランキングを使ってなければ、影響しないかも。。です。CGIがあるだけで駄目かも知れませんが。。

Yomi-Searchの方は、Vectorに残ってたので削除依頼しておこうと思います。Ranklinkの方は。。連絡先不明です。
自分のサイトも、所有者の代理設定をしていて自分の方ではなくて、サーバ提供元に方に連絡が行っていまいました。同じでした。

メアドだけ自分のに変更できれば良かたのですが、今のドメイン提供元はできないので。。ドメイン登録すると個人でも住所、電話番号、氏名等フルセットで公開される仕様ってどうにかならないんですかね。。(^_^;

 

最後に、今回の件は、情報がないのでセキュリティーホールでも「ゼロデイ攻撃」と言われる物かなと思います。

情報が漏洩するものでないだけマシでしたが。詐欺メールの中のURLに使われたかと思うと、凄く申し訳なかったと反省しています。

古いプログラムですが、稼働しているサイトはかなりあるので。。他人事ではありますが、気になります。

コメント

  1. 同様の事案で検索していたところ、こちらの記事に辿り着きました。
    Yomi-Search、有料で改変してくれる方が見つかればいいのですが
    古さには勝てないのかもしれないですね。
    参考になりました、有り難うございます!

    • pippaさん
      コメントありがとうございます。
      Yomi-Searchですが、まだまだ大量に残ってるので多分同じ様に踏み台にされると思います。(^_^;
      調べたのが大分前で、うろ覚えですが根本的(機能の実装自体)な問題で対応がかなり大変そうに見えました。

      利用者の規模や数を考えると、誰かが対応してくれる可能性も低そうかなと思います。
      サポートを続けてくれそうな、他のCGIに移行するのが無難でしょうか。

      私の所は、何時閉めようかと思ってたので、良い機会と思い閉めちゃいましたが、継続運用するのは大変ですね。

      ふと思って検索してみたら、結構残ってました。ベクターも消してないし。。
      私の所みたいに、不正な踏み台にされて地道に10年単位ぐらいで減っていくんでしょうね(^_^;

  2. こんにちは。
    Webの仕事から離れてしばらく経ちますが、以前はCGIの設定ではパーミッションの設定は相当慎重に行いました。

    費用の兼ね合いでフリーCGIを使う事も多く、その場合はパーミッションの設定が提供元の情報に頼るだけで「本当に大丈夫?」て首を傾げた事も多くありました。
    パーミッションだけでなく、ソースも脆弱性も多くあり、不正アクセスとのしのぎ合いで神経をすり減らしたものです。

    今はwordpresが一般的になり、バージョンの管理をしっかり行えばいいのかもしれませんが、いずれにしても古いバージョンは要注意ですね。

    • charikettaさん
      コメントありがとうございます。
      perlや、シェルスクリプト等の直接実行するタイプの言語はパーミッションの設定が重要でしたよね。
      当時、データファイルを実行可能にして表示できなくするとか普通にやってましたが、
      今となっては、なかなかの強行方法だなと思います(笑)
      最近はPHP等のインタープリターが多くなってきて、実行権限は必要なくなったのは良かったと思います。

      今回の件は、開発当時って脆弱性への対応認識があまりなかった時代なので、仕様自体が既に脆弱と言う物でした。(^_^;
      平和だったなぁと思います(笑)
      本来WAFで検出できたら嬉しかったのですが、少々難しそうです。

      WordPressは面倒なので、自動アップデートをONにしてます。
       セキュリティーリスク>自動アップデートでシステム停止する可能
      と思って、即アプデートしてます