January 31, 2014 at 10:30 am #8643
I am doing an internal pen test for the company I work at and having a few issues with an exploit. I have identified a vulnerable PHP service running and launched the correct exploit and set all the payload options. The exploit failed so I thought I would check the firewall to see what was happening.
The firewall recognised the exploit and dropped all packets. I sent the exploit over port 80 which the service was running over. I have heard of encrypting the exploit so the firewall does not recognise the signature but do not know where to start. What is best practice in a situation like this?
Thanks guys for any help
January 31, 2014 at 5:25 pm #53753dynamikParticipant
Which exploit are you using? Where did it come from?
Is the service also running over 443? SSL would probably prevent the firewall from seeing the traffic.
February 1, 2014 at 1:10 am #53754
Port 443 is not open but I thought there was a way of encapsulating the exploit to bypass firewall heuristic detection? I am attempting to exploit PHP 5.2 service with the 0P5 license.php remote command execution and the PHP CGI argument injection
February 1, 2014 at 4:44 pm #53755dynamikParticipant
I believe you’re thinking of encoding payloads. It really depends on what the firewall is identifying as malicious.
I assume you’re using Metasploit for this. If it’s identifying the generic HTTP request that Metasploit uses to trigger the exploit, you’re probably going to have to copy that module and make modifications to it in order to make it unique. For example, this is the data used for executing your payload in the OP5 module: data = ‘timestamp=1317050333`’ + payload.encoded + ‘`&action=install&install=Install’;
The firewall check may simply be looking for timestamp=1317050333 since it would be quite unusual for legitimate users to have that timestamp, but it will always be present when using the MSF module (that value was also used in the original PoC: http://www.ekelow.se/file_uploads/Advisories/ekelow-aid-2012-01.pdf). You may be able to get around this by simply modifying that value or making other minor changes to the exploit template.
When you’ve selected the module, you can also issue a “show encoders” command to see what your options are for encoding the payload. You unfortunately have very few options in these two cases since you’re primarily working with text and not actual shellcode. Therefore, you’re not going to be able to use encoders like shikata_ga_nai.
You can also try setting EnableContextEncoding to true. Additionally, the argument injection module provides advanced payload options for EnableStageEncoding and StageEncoder, which might be useful if you’re using a staged payload and the firewall is actually catching the stage and not the exploit itself.
February 1, 2014 at 8:03 pm #53756
Excellent. Very informative post and I appreciate that. I’ll take the advice you have given and read up on it and hopefully I’ll get somewhere with my issue 🙂
February 2, 2014 at 9:46 pm #53757
Just a quick one –
I can’t find the timestamp value that needs changing in the exploit code. Is metasploit adding that timestamp to it and therefore I am looking in the wrong place? I was looking in the op5_welcome source code. I have looked online and where the timestamp should be, I have this….
data = ‘do=do=Login&password=” + payload.encoded + ‘`&action=install&install=Install’;
How does metasploit insert the timestamp of 1317050333 into the above??
February 3, 2014 at 11:37 am #53758ccpik1Participant
Please delete above post mods if possible. I have found what I was looking for. Apologies
- You must be logged in to reply to this topic.