Table of Contents
I found a security issue on a Japanese EC shop platform called EC-Cube. It seems like developers decided to not regard as a security vulnerability for now, but they have plans to work on this issue sometime soon.
Please make sure to turn off your debug mode if you are hosting it on the internet (or VPS).
It was found out that backdoors can be installed on EC-Cube services when debug mode is enabled and facing on the internet.
**Currently, the official EC-Cube guideline does not provide any serious warnings about this matter, although developers are aware of it and mentioned in their checklist. **
Developers decided to not accept it as a vulnerability as there are too many vectors for the vulnerability when this one is regarded as a valid Remote Code Execution. It is part of their specifications, according to what the developer claimed.
RCE can be easily triggered by file upload from admin's page, but admin can be taken over when EC-Cube is on debug mode as we can utilize the Symfony Profiler to snatch admin's authentication.
Machine Translated
EC-Cubeという日本のECショッププラットフォームでセキュリティ上の問題を見つけました。 開発者は今のところセキュリティの脆弱性と見なさないことにしたようですが、近いうちにこの問題に取り組む予定です。
インターネット（またはVPS）でデバッグモードをホストしている場合は、必ずデバッグモードをオフにしてください。
EC-Cube サービスでは、デバッグ モードがイネーブルでインターネット上にある場合にバックドアをインストールできることが判明しました。
現在のところ、EC-Cubeの公式ガイドラインでは、開発者はこの問題を認識しており、チェックリストにも記載されていますが、この問題に関する重大な警告は示されていません。
これが有効なリモート コード実行と見なされると、脆弱性にはベクトルが多すぎるため、開発者は脆弱性として受け入れないことにしました。 開発者の主張によると、それは彼らの仕様の一部です。
RCE は、管理者のページからファイルをアップロードすることによって簡単にトリガーできますが、EC-Cube がデバッグ モードのときに管理者を引き継ぐことができます。これは、Symfony Profiler を使用して管理者の認証を取得できるためです。
Reference
EC-CUBE 4.0.4 and earlier is affected by Remote Code Execution (RCE). Administrator must be logged in to achieve this attack. However, administrator privilege is not required to achieve the attack on a default configuration.
Impact: RCE via Arbitrary file upload.
Attack vector is: Administrator must be logged in. Administrator does not require under the default configuration.
Components are: FileController.php
Tested EC-Cube Version : 4.0.4 (Latest)
Affected EC-Cube Version : ~4.0.4 (Latest)
Proof-of-Concept Video: https://imgur.com/a/efs8OVt
Found by @stypr from Vulnerability Research team in Flatt Security Inc.
Following versions are affected under this vulnerability.
It is due to the possibility of leaking admin's HTTP traffics from Symfony profiler, and profiler is enabled by default in normal configuration. The impact is very huge because dev environment is set by default on docker's initial installation. There are many websites facing on the internet with debug enabled, and this makes more critical in this case. Attacker can install a backdoor to development websites that are facing to the internet.
.htaccess, .php and other extensions must be bloced)You just need to follow steps from official guideline and run the exploit.
cd path/to/ec-cube
docker build -t eccube4-php-apache .
## コンテナ上のファイルを使用する場合
docker run --name ec-cube -p "8080:80" -p "4430:443" eccube4-php-apache
## ローカルディレクトリをマウントする場合
# var 以下をマウントすると強烈に遅くなるため、 src, html, app 以下のみをマウントする
docker run --name ec-cube -p "8080:80" -p "4430:443" -v "$PWD/html:/var/www/html/html:cached" -v "$PWD/src:/var/www/html/src:cached" -v "$PWD/app:/var/www/html/app:cached" eccube4-php-apache
SNIPPED
Thank you for your report. We have checked it out.
For these reasons, we don't think that your report is a vulnerability. Also, we have already taken measures to address these issues.
As you reported, there are some sites that are running with debug mode, so we will give users more warning.
For these measures, we will create an Issue on GitHub and work on improving it.
If you're okay with our thinking, we'd like to close this draft, would you like to?
One line short: This is a vulnerability and needs to be fixed immediately and disclosed publicly.
Let me clear things out first,
Regardless of the privilege, there needs to be something to block file extensions in general. This is to make sure that other vulnerabilities (i.e. XSS, etc.) should not be chained to achieve a fully working one-click RCE. File Upload feature without enough checks is considered as a vector to Remote Code Execution attacks, regardless of what privilege it requires. CMS does not mean that it is generally acceptable to allow any kinds of file uploads by an administrator.
Here are some of valid RCE vulnerabilities caused by file uploads. As you see, some of them require privileges but still are considered as a vulnerability.
As I mentioned, this debug possesses direct security issues upon installation of docker instance. Guideline and Checklists should not be always regarded as a perfect solution to address these issues.
As I clearly mentioned in the Impact section,
The impact is very huge because dev environment is set by default on docker's initial installation. There are many websites facing on the internet with debug enabled, and this makes more critical in this case. Attacker can install a backdoor to development websites that are facing to the internet.
This debug mode is considered as Insecure Configuration, and the risk should be high as default installations in ec-cube by docker keeps the dev mode by default in a first glance.
Also, it is good to note that I've just chained a debug issue to perform a remote code execution. If there are any possible unseen vectors, other attack vectors can also be chained to achieve fully working one-click code execution when file upload is open like that. Please keep in mind that this debug issue is a part of vectors that I've used to chain more reliable way to maximize the risk. it does not mean that this file upload will not work when chained with other vulnerability.
I think it is a good idea to remediate this issue as soon as possible, try to address issues directly and publish it properly. I've checked some of publicly available ec-cube websites and these websites seem to be directly exploitable on my currently submitted code. Do you want your customers to get backdoors installed in the system?
Here's the list of some of vulnerable websites applicable for this attack. There can be a lot of services on debug mode on the internet. I have not tested to attack these websites as it would be illegal to do so, but it clearly shows that the server is under the development mode (as seen in the right bottom side of the page)
These websites were initially on debug mode during development, and it was available on the internet while it was on dev mode.
There could possibly be more sites than I suggested here. There are possibilities / cases that developers opened their servers facing internet and attackers installed backdoors. The chances are low, but in security it needs to be considered.
If you want to really say that this is not vulnerable to the attack, then you should better prove me that all websites on ec-cube are potentially not vulnerable to this attack.
I've also claimed that
All latest versions are vulnerable for authenticated RCE. All services with default versions (i.e. dev environments) are vulnerable for RCE without any privilege. (=Unauthenticated RCE) If this is invalid, let me know. (I am guessing that second point's phrase may be a bit wrong, it can be fixed)
There are so many remote code executions on CMS by file upload. You can search on Google for a while and find out documents about how they're being attacked.
And also, as I mentioned in the disclosure section, I will be sharing this information to the security community publicly once the reasonable deadline (120days from 2020/Sep/08) is passed. After the period expires, whether or not ec-cube fixes this issue, I will be planning to disclose limited advisory with descriptions, impacts and proper remediations of this issue.
I think it is recommended to fix first and request for CVE, so that GitHub team can review and see whether this vulnerability is eligible or not. I think the answer from the previous message clearly gives you an idea that services on the internet are potentially vulnerable to this issue.
Also, the reason why I am trying to recommend this feature on GitHub is because you can make a private fork to fix vulnerability silently and make fixes. And also, this is one of the reasons why JVN asked me to report directly to GitHub for GitHub projects.
Developers had difficulties with me speaking in English, so I had to write additional information.
I'm a little confused that you guys can only handle it in Japanese, but please understand that my Japanese is not good.
(I thought I could respond in English because you used to answer in English well.)
Because the installation method specified is for developers only, debugging is enabled by specifications. Beginner installation (link) and packaged installation defaults to product mode. For these reasons, I don't think this is a vulnerability. Also, we are already taking measures.
Is there a reason for developers to turn on debug mode from the beginning? I think it's very strange that the debug is installed open because it depends on the developer whether you actually develop it in a local environment or install and work with the ec-cube on the vps.
I think there are a lot of sites that are actually affected, but I'm not convinced that they can't be fixed due to specification issues. Other CMS such as wordpress have fixed all these problems, but I'm a little confused when they call this a specification.
If you are really planning to close this issue and work out countermeasures, would it be alright if this content was released to the outside world for ventilation? Basically, my principle is to disclose the vulnerabilities I have discovered regardless of the company I work for.
I think it's a pretty influential problem, but I'm very confused that the developers are giving me the nuance that it is not vulnerable.
Official development guidelines do not say exactly whether debug is dangerous or not.
I hope you understand that someone else may have actually been abused and that many people may be under attack when I provide this information.
I think it's a bit strange to go too far even though you have enough potential and potential.
I would like you to decide for yourself whether or not to correct this part.
If it is closed because it is not a vulnerability, I will consider it as officially rejected and try to share this attack method and its implications, and some contents of the current dialogue will be snipped. (This project is Open-Source anyways right?)
日本語だけで対応できるなんて、ちょっと戸惑いますが、私の日本語は上手くないのでご了承ください。 (以前は英語でよくお答えになっていたので、英語で対応できると思いました。)
指摘いただいたインストール方法は開発者向けのものなので、デバッグが有効になるのは仕様です。 初心者用のインストール（リンク）とパッケージ版でのインストールではデフォルトでプロダクトモードになります。 これらの理由で今回ご報告いただいた内容は脆弱性ではないと考えます。 また、我々としてもすでに対策をしています。
私はかなり影響のある問題だと思っていますが、開発者の方々が脆弱性ではないようなニュアンスを与えていて、とても戸惑っています。
公式の開発ガイドラインにdebugが危険なのかについては、きちんと言及されていません。
私がこのような情報を提供した時点で、すでに他の誰かが実際に悪用された可能性があり、また、多くの人が攻撃を受けている可能性があることをご理解いただければ幸いです。
可能性と潜在性が十分にあるのに度が過ぎるのはちょっとおかしいと思います。
一応、この部分を修正するかどうかは自分で判断していただきたいです。
もし、脆弱性ではないためcloseされる場合、私は公式に拒否したと判断し、ある程度制限された線で攻撃方式と問題点、そして今の対話内容の一部を共有しようとしています。 (どうせオープンソースじゃないですか)
Thank you for waiting, I will report to you that the policy has been decided.
First of all, I would like to thank you again for your cooperation in improving the security of EC-CUBE, such as this matter, reporting and confirmation.
In response to your report, we have reviewed the contents of the report and reviewed the policy in various places concerned.As a result, I would like to inform you that the content you pointed out is within the specifications of the software and will no longer be treated as a vulnerability.
"·You can upload executables such as PHP by using the ""File Management"" function with administrator privileges within the specifications of EC-CUBE software." ·The fact that the initial setting is set to debug mode is not a vulnerability because it does not occur in the production version.
As mentioned above, we have officially decided not to treat it as a vulnerability, but what you have pointed out this time is an important point. Therefore, as you pointed out, there are some websites that are open to the public, so we would like to make sure that they are known again.
Furthermore, in addition to the above-mentioned information, we will proceed to implement the following measures.
Changing the default installation value for developers to prod Discuss whether to restrict files that can be uploaded using File Management on GitHub Issue This time, our responsibility is to raise awareness and create an environment in which mistakes do not occur, and we will continue to consider how to deal with this in mind.
Now, in order to avoid any inconvenience to EC-CUBE users, please do not publish the attack code directly.We would appreciate it if you could share your company's view on the issues and risks.
Now that you've pointed it out, we can rediscover the challenges and move to improve security.thank you very much
We have the same desire to improve security, so we would appreciate it if we could continue to exchange information.
Then, please check it.
「ディレクトリトラバーサルの脆弱性」に関するコメントについて
こちらは、商品管理機能で任意のファイルが削除できるという「意図しない機能」でしたので脆弱性として扱いました。 今回主題となっている「ファイル管理」の機能でPHPファイル等をアップロードできるのは意図した機能です。 「ファイル管理」を脆弱性として扱うべきかどうかは現在議論中ですので、回答はもうしばらくお待ちください。
お待たせいたしました、対応方針が決まりましたのでご報告いたします。
まず、本件、ご報告並びにご確認等、EC-CUBEのセキュリティ向上にご協力いただき改めまして、感謝申し上げます。
今回、ご報告を受けまして、JPCERTや関係各所とも内容を精査し、方針を検討いたしました。その結果、ご指摘いただいた内容はソフトウェアの仕様範囲内であり、脆弱性として扱わないことになりましたのでその旨ご報告いたします。
・管理者権限にて「ファイル管理」機能でPHPなどの実行ファイルをアップロードできるのはEC-CUBEのソフトウェアの仕様範囲内で可能なことでございます。 ・初期設定がデバッグモードになる点ついては、製品版では発生しないため脆弱性ではないという判断でございます。
上記にも記載いたしました通り、公式では脆弱性として取り扱わないという判断にはなりましたが、今回指摘いただきましたことは重要なご指摘であるととらえております。 つきましては特にデバッグモードの件は、ご指摘の通り公開されているサイトが存在しておりますので、改めて周知徹底したく考えております。
更に上記周知だけではなく、以下の対策も併せて行うよう進めてまいります。
開発者向けのインストール時のデフォルト値もprodへ変更 GitHub Issue上での「ファイル管理」でアップロード可能なファイルを制限すべきかどうかの議論 今回は、当社の責任として注意の周知、及びミスが発生しない環境作りを中心に対応し、引き続き対応も検討してまいります。
さて、今回情報公開をしていただくにあたり、特にEC-CUBEのご利用者様へご迷惑をおかけしないためにも、直接的な攻撃用コードの公開はしないでください。問題点や危険性については御社の見解をお伝えいただければと思います。
今回ご指摘いただいたことで社内でも課題を再認識でき、セキュリティ向上のために動くことができます。本当にありがとうございます。
セキュリティの向上をさせたいという思いは我々も同じでございますので、今後も情報交換等しながら進めさせていただけましたら幸いです。
それでは、ご確認のほどよろしくお願いします。