New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a module for Magento's Shoplift RCE #6250
Conversation
This module exploits the infamous Magento's Shoplift vulnerability to create a new admininitrator account, then it creates a backdoor module on the fly, and install it to achieve code execution.
I should be able to test this. |
} | ||
}) | ||
|
||
if res.code == 200 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should check for res here before res.code
Great Job Again :) |
|
||
res = send_request_cgi({ | ||
'method' => 'POST', | ||
'uri' => normalize_uri(target_uri.path, '/admin/Cms_Wysiwyg/directive/index/'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @jvoisin, I am testing against 1.9.0.0 and the correct URL for this request is:
normalize_uri(target_uri.path, '/index.php/admin/Cms_Wysiwyg/directive/index/')
I am not sure if this path changes based on version (or a setting). Could you please check? I am all on default settings. Thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It works here with '/admin/Cms_Wysiwyg/directive/index/'
.
You can test this by using the original PoC.
I'm going to take a look at those issues this week-end :) |
hi jvoisin how to magento_rce ... donwload ? send me linke ? |
Ok thanks! |
The main improvement here is that the CSRF token is no more mandatory, since some versions of Magento doesn't have some for every operation. This module is now working on magento ce 1.9.0.0 and 1.9.1.0
Now it's tested on 1.9.1.0 and 1.9.0.0, and it works in both cases. |
@jvoisin thanks, I will try again. |
@jvoisin I tested and this is how far I got:
Some notes:
So I am a little baffled about this. Our Magento 1.9.0.0 setups are supposed to be the same, being able to create an account proves that. But for some reason, it looks like my Magento is slightly different than yours... probably just slightly, but enough to cause the exploit to fail. I wish I could give you more info, but I don't know what kind of stuff you want... for starters, I guess I'll post screenshots of the Magento version I'm on, and the filename I downloaded: From the downloader login page: The admin page footer: The file I downloaded for testing
Please let me know if you spot anything unusual on my end. Thanks. |
Try to set
|
|
I'm testing on Have you tried the poc? Does it work on your side? Also, my update should take care of the absence/presence of csrf token. |
I just tested on the exact same version than your, and it's working flawlessly :/
|
@jvoisin how come your magento is on port 8080 when magento is just a folder that you can move to /var/www/html, and install? Shouldn't it be port 80? Unless you are running an installer that's configuring for you? |
Since I don't have much space on my laptop, I'm running several magento instances on the same VM, the 1.9.0.0 on 8080, 1.9.1.0 on 8081, and the 1.9.0.0 from the same archive than your on 8888. |
@jvoisin The account creation code works from both your exploit and the public PoC when the right path is given, it's just that what happens after that doesn't. This shows that I am testing on the latest commit:
Did you enable URL rewrite? I remember that being one of the settings during installation. |
This is my nginx configuration:
For the installation, nothing funky, everything on default. |
I'm a bit discouraged to be honest, but I'll likely try to make this work on a fresh magento installation this week-end. Did you checked Apache URl rewriting in the installation process ? |
I don't think I checked that box while installing, I'm more than happy to try again. I'll let you know, thanks! |
[*] Exploit completed, but no session was created. This is because the malicious module writes the PHP file with "666" permissions and not "644" as it should, so under the most Magento installations the PHP file won't be run. |
@johnlockejrr If you change to |
@jvoisin needs to be "644" on most installations to work, that's the reason it fails on most installations I tried. Trying to find a switch in building the module (package.xml) to force writing the PHP file with "644" permissions and not "666". |
Arg, it was a typo from my side, I meant "If you change to 644, does it work?", sorry :/ |
Yes, with "644" works on any installations with PHP like "Apache2, Nginx, LightHTTPD", some PHP won't run a PHP script if is world-writable or group-writable. Any idea how can we achieve this with package installer? |
I even made the malicious module from Magento package manager and manually, checked if the PHP file is "644" in the *.tgz archive, and tried uploading like magento does as |
This is weird, since the is the way magento uses to install modules, that are executables by php. |
Yup, I tried using another directory than |
Btw, @jvoisin you should add some error check when accessing the |
Found it! You can change default file permissions in Settings: |
Great! Feel free to issue a PR on top of mine :) |
The function to set file permissions should look something like this:
|
Works flawlessly now ;) |
BTW, you should add check for this error |
Perfect then :) @wchen-r7 Can you test it on your side? |
@jvoisin The build failure is due to the usage of fail_with(Failure::NoAcces (line 151). The correct usage is Failure::NoAccess (final 's' is missing in your case). |
Sometimes, the application has no write permission, we should tell the user about that.
@jvoisin you should add the write permission check in
|
Oops sorry I was on vacation, so I didn't see your message. Yes I will try again. Thanks! |
@jvoisin I finally got back to testing this today, and here's what I got: First of all, there is a typo at line 171. Instead of After fixing the above typo, I ran the module, and got:
As far as I can tell, the exploit did create the malicious module in my /var/www/html/magento/var directory:
Some inspection of the tgz file:
When the exploit was requesting the malicious page, it got something like this though:
Let me know if you need more info. I have the same Ubuntu setup. |
@johnlockejrr : Can you reproduce ? |
Unable to get a reliable session. Please see #6250 for more info.
@jvoisin It looks like we have not been able to make any more progress on this - that's okay, I have moved this PR to the incomplete/unstable branch now. We can come back to this later. Thanks for the PR! |
This module exploits the infamous Magento's Shoplift vulnerability to create a new admininitrator account, then it creates a backdoor module on the fly, and install it to achieve code execution.
Tested on 1.9.0.0 CE and 1.9.1.0 CE.
Also, please squash this pull-request before merging it. If you're testing this PR, feel free to test this one at the same time.
Console output
How to reproduce
/var/www
use exploit/multi/http/magento_rce
, set options