osCommerceのアーカイブ

もし、利用しているosCommerceが2007年2月のoscommerce-2.2ms1j-R8.tar.gzより前のバージョンをいまも利用していたら、すぐに、R8と同じ対策を行うか、さもなければ、使用をやめたほうがいい。せめてアクセスログを常日頃から確認すべきだと思う。

私のお客様には説得して対策を行ったが、費用がかかるためまったく対策していないosCommerceも存在しているはずだ。
営業のためosCommerceのサイトを検索するがエラーを表示したままのサイトや打ち捨てられたようなosCommerceもある。
このようなosCommerceは格好の標的になる可能性があるのですぐに修正するか、osCommerceを削除するほうがいい。
かなり大規模なサイトで常にメンテナンスされているようなサイトもSQLインジェクションの脆弱性はそのまま放置されているところも多数有ることに驚いた。 営業のついでに古いosCommerceの危険性を知らせているが真剣に聞いてもらえるかこれまでの経験から自信が無い。

想像を越えた数のアクセスと攻撃手法を実際に見ると脆弱性が存在したままosCommerceを運営することは危険であり、顧客に対して無責任と言われても仕方ない。
メールに反応はないかもしれないが今後も危険性を知らせたいと思う。

被害にあったosCommerceのサイトのセキュリティ対策をした。
アクセスログを確認したところSQLインジェクションを利用した手法だった。
アクセスログを見れば知識がなくても異常事態が起こっていることは
すぐにわかるほど大量のアクセスがあった。

例えばこんな感じで情報漏洩を目的としたアクセスが増えて行った。
11月0件
12月に55,000件
1月に20,000件
2月に10,000件
3月に15,000件
4月に450,000件　<–このあたりで情報が漏洩
5月に28,000件
（件数は適当です。正確ではありません）

アクセスログからどのように情報が漏れたのかわかった。
まず、libwww-perlなどを利用して攻撃対象のサイトの脆弱性の有無を確認していた。
Web上を検索すると脆弱性を確認するスクリプトの作成方法を掲載しているサイトがあり
誰でも作れるようになっていた。脆弱性の確認方法も実に簡単だとわかった。
脆弱性が確認できたらアクセスするURLにSQL文が混ざりはじめる。
osCommerceのソースコードは公開されているので内部を推測する方法はこれまた簡単。
主に、ログインIDとパスワードを取得しようと試みていた。
攻撃者がヒントをつかんだところでアクセス数が大量になるようだ。

脆弱性をすべて塞ぎ、丁寧に攻撃手法を解析してIPアドレスによりアクセスを制限をしたところ、やっと安心できる状態になった。

サーバが重くなったり、ログにおかしなURLが混じりはじめたら、すぐに対応すれば問題は起きないのではないかと思う。
短い期間に200近くのサイトをアクセス拒否したが、それでも新たな攻撃用サーバが毎日アクセスしてくる。

4月8日付けでosCommerce Online Merchant v3.0.1が発表されていました。

主に、バグフィックスと機能改善がなされたようです。