PrestaShopがハッキングされた?症状・原因・対策を徹底解説
PrestaShopがハッキングされた?症状・原因・対策を徹底解説
PrestaShopはオープンソースのECサイト構築ソフトウェアです。当初は学校のプロジェクトとして開発されましたが、その後オープンソースコミュニティの手によって急速に発展しました。PHPとMySQLを利用してデータベースを管理しており、コードが公開されているため、誰でも脆弱性(バグ)を発見できる可能性があります。
近年、PrestaShopでは重大なセキュリティ脆弱性が多数報告されています。SQLインジェクションから、不具合のあるCookie暗号化まで、これらがあなたのサイトへの侵入原因となっているかもしれません。ECサイトのセキュリティは売上の即時損失に直結するため、極めて重要です。PrestaShopの普及拡大に伴い「PrestaShopハッキング」も増加傾向にあり、ユーザーはセキュリティ対策により多くの時間と費用を投資すべきです。
ハッキングされた場合に起こりうる被害
- サイト上に偽ページを作成される
- 顧客を他のサイトへ強制リダイレクトされる
- ログイン情報、銀行パスワード、クレジットカード情報などの機密情報を盗まれる
- 日本語キーワードハックやファーマハック(Pharma Hack)などのSEOスパムを仕込まれる
- ホスティング会社によってサイトを停止される
- 検索エンジンのブラックリストに掲載される
- スパム送信の踏み台にされる
- サイトが極端に遅くなり、エラーメッセージが頻発する
- 広告やポップアップが勝手に表示される
- ユーザーの信頼を失う
- 収益の損失
- その他、多大な二次被害!
PrestaShopがハッキングされる主な原因
1) SQLインジェクション
SQLインジェクションはPrestaShopにおける最も一般的な脆弱性の一つです。データベースに直接関わるため非常に深刻です。不正な入力を与えると、DBMSがその入力を含むクエリを実行してしまい、機密情報の漏洩につながります。最悪の場合、システム全体の乗っ取りに至ることもあります。
PrestaShopのSQLインジェクションは2014年に初めて報告されました。PrestaShop 1.6.0およびその他のバージョンが脆弱とされており、問題はid_manufacturerパラメータにありました。
https://example.com/ajax/getSimilarManufacturer.php?id_manufacturer=3[SQL-injection]
パラメータ以降に不正な入力を注入されると、攻撃者はデータベースを読み取ることができます。さらに、SqlmapやSqlninjaなどの自動化ツールを使って悪用されるケースも少なくありません。
近年、別のSQLインジェクションも発見されました。PrestaShop(1.5.5.0〜1.7.2.5)が影響を受け、CVE-2018-8824として登録されています。原因は「Responsive Mega Menu (Horizontal + Vertical + Dropdown) Pro」というモジュールです。このモジュールを利用している場合は、今すぐアップデートしてください。
GET: https://site/modules/bamegamenu/ajax_phpcode.php?code=p(Db::getInstance()->ExecuteS("show tables"));
このコードは、脆弱なパラメータ経由のAjaxリクエストでデータを抽出し、データベース内のテーブル一覧を表示します。「show tables」を任意のSQL文に置き換えるだけで、自由にデータベース操作が可能になります。攻撃者は機密テーブルからログイン認証情報を取得でき、管理ダッシュボードが完全に開かれた状態になってしまうのです。
2) 権限昇格
権限昇格は、低い権限を持つユーザーがより高い管理者権限を不正に取得してしまう深刻な問題です。2011年に初めて報告され、2018年にも新たな欠陥(CVE-2018-13784)が発見されました。1.6.1.19以前のバージョンが影響を受けます。
原因はユーザーCookieの暗号化処理のバグです。PrestaShopはopenssl_encrypt()経由でBlowfish/ECDまたはAES暗号化を使用していますが、これがOracle攻撃に対して脆弱でした。その結果、攻撃者はPrestaShopのCookie内容を読み書きでき、本来アクセスできないはずのCookieにも触れるようになります。具体的には以下の被害が考えられます:
- 任意のユーザーセッションへのアクセス
- クレジットカード情報などの機密データの窃取
- サイト管理者になりすまし、システムを自由に操作
Cookieの発行処理は./classes/Cookie.phpで行われており、この脆弱性を悪用するスクリプトはすでにwww.exploit-db.comで公開されています。これにより、世界中でハッキングが加速しました。
3) 互換性の問題
互換性の問題も頻繁に発生します。典型例は、WordPress環境でPrestaShopを運用しているケースです。WordPressは自動で最新版へ更新されますが、問題は更新プロセスの失敗にあります。

表面上は正常に見えても、実際には異常が起きています。WordPressの更新に失敗すると、wp-config.phpのコピーが.txtファイルとして作成されることがあります。その結果、PrestaShopデータベースの機密情報がサーバー上に平文テキストとして露出します。こうしたファイルを探す専用スキャナーは数多く存在し、攻撃者はそれを利用してサイトを攻略できます。すべては不適切なWordPressのインストールが引き金となるのです。
4) リモートコード実行(RCE)
バグのあるコーディングが原因で、攻撃者がリモートからコードを実行できる状態になる脆弱性です。サーバー全体が完全に侵害される恐れがあります。CVE-2018-8823として知られるこの脆弱性は、Responsive Mega Menu Proモジュールで発見されました。1.0.32までのバージョンが該当し、modules/bamegamenu/ajax_phpcode.php内の未知の関数が原因です。パラメータを改変するだけでリモートコード実行が可能で、しかも認証は一切不要でした。
5) 脆弱なパスワードと管理画面の露出
「admin」のような単純なパスワードひとつで、大企業ですら危険にさらされ得ます。デフォルト設定のまま放置されるケースが非常に多いのが実情です。すべてのアカウントでデフォルトパスワードが使われていないか必ず確認し、管理画面がインターネットから直接アクセスできないようにしてください。機密性の高いインストールファイルの漏洩につながる可能性があります。
6) 任意のファイルアップロード
チェック機構が適切に実装されていないと、細工されたファイルのアップロードを許してしまいます。これはサイト全体の侵害につながる重大な問題で、マルウェア設置の入口にもなり得ます。Google Dorksを使えば、脆弱なサーバーを一括で検索することさえ可能です。例:
inurl:"/modules/columnadverts2/"
または
inurl:"/modules/columnadverts/"
これらのキーワードでGoogle検索するだけで、脆弱なPrestaShopサーバーが見つかってしまいます。原因は必ずしもコーディングの欠陥だけではなく、管理者自身が設定した不適切なファイル権限である場合もある点に注意が必要です。
7) XSSおよびゼロデイエクスプロイト
クロスサイトスクリプティング(XSS)は最も一般的な脆弱性の一つです。XSSの悪用に成功すると、以下の被害が発生します:
- 管理者アカウントの乗っ取り
- 管理用Cookieへのアクセス
- コメント欄に仕込まれたCookie窃取コードの実行
- 訪問者の端末へのマルウェアダウンロード
- 機密ファイルや個人情報への不正アクセス
さらに、ゼロデイエクスプロイトによってサイトが侵害されている可能性もあります。ゼロデイとは未報告の脆弱性のことで、パッチが存在しないため防御が困難です。最善策はAstraのようなPrestaShop対応WAF(ファイアウォール)を導入し、攻撃を遅延・阻止することです。
日本語キーワードハックとファーマハック(SEOスパム)
これはブラックハットSEO手法の一つで、サイトの検索エンジン表示結果が乗っ取られます。GoogleやBingのクローラーは、あなたのサイトが日本語コンテンツや医薬品関連サイトであるかのように認識します。以下のクエリをGoogleで検索することで感染を検出できます。なお、日本語SEOスパムを中国語の文字と混同する人も少なくありません。
site:example.com または site:example.com 日本語 または site:example.com viagra


PrestaShopにおける日本語SEOスパムとPharma Hackの詳細な修正方法については、専門の解説ガイドを参照してください。

ハッキングされた後の復旧手順(クリーンアップ)
1) アクセスをブロックする
まず、機密フォルダへのアクセスを遮断しましょう。対象ディレクトリ内に.htaccessファイルを作成し、以下を記述します:
Order Deny,Allow
Deny from all
Allow from 22.33.44.55
この記述はファイル/フォルダへのアクセスを拒否し、最終行で許可するIPアドレスを指定します。IPレンジ単位での指定も可能です。あわせて、改ざんされていないか既存の.htaccessファイルも確認し、不正な記述があれば真っ先に削除してください。
2) ファイル権限を確認する
次に、ファイル権限が適切かどうかを確認します。ディレクトリは755(rwxr-xr-x)、ファイルは644(rw-r--r--)が基本です。過剰な権限はファイルアクセスの悪用を招くため、正しく設定しましょう。
3) 怪しいモジュールを排除する
脆弱なプラグインが原因でPrestaShopがハッキングされた事例は後を絶ちません。バグを抱えたモジュールや長期間更新されていないモジュールには注意し、アップデートするか安全な代替品に置き換えてください。
4) データを暗号化する
管理テーブル内のログイン情報は暗号化しましょう。データベースが漏洩した場合の第二の防御壁になります。また、同一サーバー上の他のWebアプリケーションとは、必ず別のデータベースを使用してください。
5) パスワードを強化する
FTPおよび管理画面の認証情報には強固なパスワードを使用してください。辞書にあるような一般的な単語やフレーズは絶対に避けましょう。
6) 隠された不正コードを見つける
攻撃者は、人間の目で読めない形式でコードを難読化して隠します。base64エンコードされた怪しいコードを探す必要がありますが、手動では干し草の山から針を探すようなものです。次のコマンド一つで効率的に検出できます:
find . -name "*.php" -exec grep "base64" {} \; -print &> weirdcode.txt
このコマンドはbase64エンコードされたコードを検索し、weirdcode.txtに保存します。その内容を分析し、以下のようなリダイレクト先ドメインが含まれていないか確認してください:
<li><a href="weird-domain.com">Something1</a></li>
7) 更新とバックアップを徹底する
まだなら、今すぐ全ファイルをバックアップしましょう。以降は定期的にバックアップを取得し、ソフトウェアは公式サイトから入手した最新版をインストールします。公式ブログなどで最新のセキュリティパッチ情報をフォローすることも忘れずに。
8) WAF(ファイアウォール)を導入する
将来のハッキングを防ぐために、ファイアウォールの導入を検討してください。WAFは不正なアクセスをシステムに入る前にブロックします。無料のものから月額コーヒー一杯程度の価格帯まで、さまざまな製品があり、プラグイン形式で手軽に導入できるものもあります。
まとめ
PrestaShopへのハッキングは、ビジネスを完全に破滅させるほどの深刻な事態になり得ます。ECサイトのセキュリティは極めて繊細な問題であり、一度被害に遭えば復旧には膨大な時間と労力がかかります。「予防は治療に勝る」の言葉通り、WAFなどのセキュリティソリューションを活用してハッカーを寄せ付けない体制を整えましょう。加えて、ソフトウェアを常に最新の状態に保ち、不審なアクティビティを継続的に監視することが大切です。鎖の強さは、最も弱い輪によって決まる——この原則を決して忘れないでください。
-
PHPサイトがハッキングされた?考えられる原因となるPHPの脆弱性13選
PHPは現在、ほぼすべての人気CMSの背骨とも言える存在です。シンプルさとライセンスフリーという特性により、PHPは動的なWebサイト開発において最も選ばれている言語です。しかし一方で、コーディング規範の甘さが原因で、PHPサイトへの不正侵入は比較的容易になってしまいました。インターネット上には「カスタムPHPサイトがハッキングされた」「PHPサイトがリダイレクトハッキングに遭った」といったユーザーの相談スレッドがあふれています。これがPHP自体の悪評につながっていますが、実はPHP自身には何の落ち度もありません。 では、PHPに責任がないとすれば、PHPサイトがリダイレクトハッキングされる原
-
Site Web Codeigniter または Laravel pirate? Codeigniter と Laravel の修正コードの脆弱性
Laravel と Codeigniter は、フレームワークとして PHP を使用し、Web サイトの作成者として使用します。自然界のオープン ソース デ ドゥ フレームワークが人気を博しています。 Cependant, les utilisateurs doivent comprendre que le déploiement de sites utilisant ces frameworks ne les rend pasûrs. Ce sont les pratiques de développement sécurisées qui comptent. L’injection SQL