­
Magento Remote Code Execution Vulnerability! | Security Down!

Magento Remote Code Execution Vulnerability!

logo_magento

Salam, Hello, Nekhaw, Selamat Datang, Komastaka, Aregato, Ciao, Merhaba, Swadi Kup, Namaste, Kak Gatokha Bratokha 😀

Wherever you are from, Welcome to this blog post about a Remote Code Execution Vulnerability that affects the most popular shopping application on the internet –> #Magento

The case started when i found below sub-domain for Magento.com website: http://lavender.dev.magento.com/

As you can see it is a development server, after some crawling i found below directory:

http://lavender.dev.magento.com/GitHub/setup/ ( The “GitHub/” directory is the folder where they are installing Magento, And the “Setup/”  is the application installation directory )

Screen Shot 2014-11-06 at 8.19.50 AM

 

It was the installation folder for Magento application, However, After clicking Next, Next:

Screen Shot 2014-11-06 at 8.20.19 AM

 

 

 

Important Note: in the installation process, Magento allows you to name your admin login page as you like, you can name it admin or cpanel or whatever!

Anyway, I reached below URL which is used to configure a database for Magento to use: http://lavender.dev.magento.com/GitHub/setup/#/add-database

So, I submitted any bogus data as a database credentials, and i got below error:

Screenshot from 2015-10-29 17:05:04

 

As you can see, the database triggered error because it can’t connect to the bogus IP i provided in the previous step, But wait!  also the credentials i provided is reflected inside the page!

So here is the scenario to trigger the RCE:

1- I will provide a bogus ip so the database will through an error, and that error will be reflected in the “Admin” page i created.

2- Because i can rename the admin panel to whatever, so i will rename it to “zigoo.php”, now the error will be inserted into “zigoo.php” page.

3- Since the data i provided in the db username and password inputs are reflected in the “.php” page, i will inject a PHP code inside the username & password fields.

That said, i will add php code “<?phpinfo();?>” in the username & password field,  rename the admin panel to be “zigoo.php” and add bogus ip in the “Database Server Host” field as below:

Now let’s try a small test first, i will rename the admin panel to be “zigoo1.php” to see if it works or not:

Screenshot-from-2015-10-29-191606

 

Works fine as expected, now i will inject the php codes inside the other inputs as below:

Screen Shot

 

And Pingo! RCE triggered and the php code “<?phpinfo();?>” worked like a charm!

info

 

To fix this vulnerability in your website, just make sure that the installation files/drectory are DELETED or at least renamed.

Vulnerability Timeline:

This vulnerability has been reported to Magento team on: 09/Nov/2014

unnamed22

 

That time, Paypal and Magento were still the same BBP, However, I got the first response from Magento on: 11/11/2014

first-response

 

 

 

Emails going back and forth until i received an Email from the team on: Jul 2, 2015 at 9:52 AM (after 9 months) that the bug is not yet fixed as Highlighted below:

not-yet

 

 

After that time, i sent an Email in the same month and another and so on, i didn’t receive any response for over 3 months:

hell

 

 

 

Untill i fedup with this! so i decided to search for Magento security Employees on linkedIn to message them about the issue!!!!!

However, I found someone from Magento team, after i explained the issue to him, he escelated the issue, and finally on 24/10/2015 i got a response that they will handle this issue and the rest of bounty will be sent next week.

Finally i received the payment on October 27, 2015 10:27:54 PM (After around 1 Year of the report)

finally7

 

I Emailed the team back to know why this issue took 1 year to be fixed?!

Their response were:

1- The issue were fixed on 30 June 2015 (arround 8 months)

2- The reason of no responses and delay in sending the bounty is:

reason

As a conclusion for this long blog post:

1- This bug has been fixed now, but if you are using older version of Magento, don’t forget to remove the installation files/directory.

2- Emergency leaves happens to all of us all the time, but someone should be following up/Delegated on the P1(Priority one)  reports!!!

3- The reward for this vulnerability were the “Second Tier” Application RCE reward.

4- Thanks “Mark Brinton” for your prompt help to escelate this issue 🙂

 

3 Comments

  1. Another Magento Remote Code Execution VulnerabilitySecurity Affairs - October 30, 2015

    […] If you are interested about the vulnerability timeline give a look to the post published by Ebrahim Hegazy. […]

  2. Yasser Ali - October 31, 2015

    Very good job, I really liked it 😉

  3. tsar - September 11, 2016

    Incredible, keep going brother.
    But renaming the installation directory is not enough to gain security, as any attacker can get the new name of the installation directory using any kind of crawlers.
    yours
    TSAR

Leave a reply