Add post-exploitation module to get FW filtering rules #4187
Conversation
| end | ||
|
|
||
| output = cmd_exec("netsh"," advfirewall firewall add rule name=\"All ICMP v4\" dir=in action=allow protocol=icmpv4:any,any") | ||
| print_status("ICMP firewall IN rule established: #{output}") |
There was a problem hiding this comment.
Perhaps make this an on-by default option so that you can try without needing to muck with the firewall? Or is there some reason why the ICMP responses would not otherwise be seen?
There was a problem hiding this comment.
Hi @jhart-r7 . By default the TTL ICMP responses are not seen if you don't enable the above rule. Maybe I should check first if the firewall allows ICMP IN traffic and if not, enable it. I thought about this at first, but It takes some time to check the rules with "netsh advfirewall firewall show ...." that's why I always enable it by default. Anyway any suggestions are welcome :)
|
How can I solve the Travis error? |
|
The error isn't related to your PR. The app team just resolved the issue and I'm restarting all the ones that failed. |
|
weird, i thought travis would do that for me. Juan's pr turned green though.............. |
|
ok, thanks for the clarification. I'll wait for more review then |
|
@todb-r7 Mine turned green without me merging anything: https://travis-ci.org/rapid7/metasploit-framework/builds/40812592 |
|
Giving a chance, working on it! |
|
@BorjaMerino I'm trying to run on it on a Windows 7 SP1 32 bits unsuccessfully: It's an admin session :? Are these failure expected? |
|
@BorjaMerino, super minor cosmetic changes in https://github.com/BorjaMerino/metasploit-framework/pull/6 |
Do minor cosmetic cleanup for post-exploitation module to get FW filtering rules
|
@jvazquez-r7 umm not expected. Let me take a look at that error ... |
|
Sure, thanks @BorjaMerino, let me know if there is any test I could do to help. Thanks! |
|
@jvazquez-r7 The VM you are using is in NAT or bridge mode ? In case of using NAT change it to bridge and let me know the result. Thanks |
|
@BorjaMerino ooom sure, checking! |
|
@BorjaMerino same result in bridge mode: |
|
@jvazquez-r7 thanks for the test. I'm trying to reproduce your error without success. I have made some changes. I realized that session.tunnel_peer gives you the NAT'd IP, not the local private address so I have changed it for session.session_host. I have tried it in Windows 7 32 and 64 bits with no error. Not sure if the changes will solve your 10047 error. According to this: http://support.ipswitch.com/kb/WSK-19980701-EM05.htm It could be a problem to the sockaddr in the bind function. If it still doesn't work print the value of sockaddr in hex way, something like: |
|
@BorjaMerino sure, retrying! |
|
@BorjaMerino. Same result in both NAT and bridge mode after the changes: Should it work in any system out of Windows XP? EDIT: Nevermind, figured out which doesn't work on 2003 hehe :P I'm going to try on others VM just in case. |
|
Same error on Windows 2008 SP2 |
|
@jvazquez-r7 jummmm ¬¬ Need to do more research about that error. Please could you print the sockaddr struct in hex format. Something like this is ok: sockaddr = Rex::Socket.to_sockaddr(session.session_host, 0) |
|
ooo yes sorry, forgot, doing it. |
|
Same here. Really weird. NAT should not be a problem while forwarding icmp replies |
|
I'm sorry, it caught mine :(. Let me please ping @OJ in case he experienced something like that in the past. @OJ, no compromise, just a summary: We're experiencing odd crashes on Virtual Interfaces on NAT mode when testing this module. The crashes only occurs when the meterpreter stager is executed from an EXE. Is there any related bug I'm forgetting? Also ping @todb-r7, do you mind to make a fast review. Landing a post module which could crash sessions isn't funny. But at this point doesn't look like a module problem. Not sure even if a meterpreter/railgun problem. How do you feel about landing after creating an issue? Or better mark as delayed and crete and issue? I can try to debug what is going on, but not today :\ Cause of it marking as delayed. Sorry @BorjaMerino! I don't think it's your fault. But landing a post module which could kill a session is risky :\ Even when at this moment I'm pretty sure it's an odd condition. Please let me listen other voices, or give me some time to debug harder what is going on! |
|
Issue created here: rapid7/meterpreter#103 marking as delayed, please, let me listen if there is any feedback before going ahead. |
|
@jvazquez-r7 np. First, find the problem. Let me know if you want me to try/modify something |
|
Sorry I missed this conversation! I just noticed @jvazquez-r7 mentioned the new bug in the Meterpreter repo. I'm happy to dive into this problem. Please leave it with me. Thanks guys! |
|
Thanks @OJ, appreciated, I'm kinda busy these days, so otherwise it would need to wait! :) Thanks for looking into it! |
|
I can get this module to crash Meterpreter just by running it twice. I can't help but think something screwy is going on with the railgun calls. Please see rapid7/meterpreter#103 (comment) for a command regarding this module. |
|
Since @OJ cannot help here, and the proposed action by him is to move this to the |
|
@OJ @jvazquez-r7 @todb-r7 Since the module is not intrusive (I mean It's like a TCP traceroute after all) not sure if It fits in the lanattack extension very well. It is just a suggestion. What do you think? |
|
The heap bug is likely caused by lack of memory allocation for the railgun calls. If @BorjaMerino can fix these up to stop mangling the heap, we can take this as a module versus pushing it off to lanattacks. |
|
This code is not allocating the receive buffer. Changing this to the following may solve this issue: |
|
Sorry for the lack of action. I'm actually on a family holiday for the +1 to HD's comments. Ultimately I think this would be good as part of an extension. It'd be way |
|
@OJ stop working 😄 We can always move this to an extension later if it proves useful, but I don't mind a slightly slower approach here as a proof of concept (provided it doesn't crash the session). |
|
@hmoore-r7 thank you so much :) @jvazquez-r7 could you check it in your lab again? thank you |
|
neat! thanks @BorjaMerino @OJ and @hmoore-r7 No crashes on NAT mode anymore, even when I get an odd message: I get the On the other hand, on bridge mode, I miss the final print_good message: Shouldn't it be reaching the message |
|
Looks like a Timeout::Error (which subclasses ::Interrupt) being raised. Sounds like missing error handling or another issue with the code's handling of timeout conditions. |
|
@hmoore-r7 @jvazquez-r7 Did you set the STOP option to true?. Only when STOP is true you will get the message: "Public IP reached. The port #{dport} is not filtered". When STOP is false (value by default) the module just behaves like a TCP traceroute with no message. This output is from Windows 7 in bridge mode: Here another example with some hops not answering with ICMP replies (in this case the previous error does not come up thanks to the HDM fix it): So @jvazquez-r7 check that STOP option and tell me if you get the same. Regarding the message "Post module execution completed" I fail to reproduce the same error. @hmoore-r7 did you get that too? Maybe I have to handle the "rescue ::Timeout::Error" condition in another way ?¿ What I've noticed is that sometimes I have to run the module a second time because of the way I use ws2_32 API. |
|
@BorjaMerino yeah, set STOP to true is the thing, thought I had it set to true. Doesn't worth to always print this message :? I feel like otherwise the output isn't very informative about the module conclusions/results. |
|
@jvazquez-r7 I set STOP to true by default and I changed some logic to show the message always at the end of each port scanned. |
|
Sorry @BorjaMerino, have been really busy last days and forgot about this pull request! Did super minor cleanup by myself, see result here: 4928cd3 And landed! Thanks for your effort and keep following the pull request! Final test: |
|
@jvazquez-r7 read you now, thank you so much :) |
This module makes some kind of TCP traceroute to get outbound-filtering rules. It will try to make a TCP connection to a certain public IP address (this IP does not need to be under your control) using different TTL incremental values. This way if you get an ICMP "time exceeded" from a public device you can deduce that the port is not filtered. Example:
msf post(outbound_ports) > exploit
[*] ICMP firewall IN rule established: Aceptar
[] Testing port 4444...
[+] 1 192.168.144.1
[-] 2 *
[+] 3 81.46.0.157
[+] 4 94.142.103.157
[+] 5 213.140.38.113
[+] 6 213.140.38.114
[+] 7 84.16.15.250
[+] 8 213.140.38.221
[+] 9 84.16.15.81
[+] 10 94.142.122.253
[] Testing port 8080...
[+] 1 192.168.144.1
[-] 2 *
[+] 3 81.46.0.157
[+] 4 94.142.103.157
[+] 5 213.140.38.113
[+] 6 213.140.38.114
[+] 7 84.16.15.250
[+] 8 213.140.38.157
[+] 9 94.142.124.58
[+] 10 94.142.123.1
[*] Post module execution completed
If you set the STOP option to true when a public IP responds with an ICMP packet, the script will not continue launching more connections (generating minimum noise).
msf post(outbound_ports) > set stop true
stop => true
msf post(outbound_ports) > exploit
[*] ICMP firewall IN rule established: Aceptar
[] Testing port 4444...
[+] 1 192.168.144.1
[-] 2 *
[+] 3 81.46.0.157
[+] Public IP reached. The port 4444 is not filtered
[] Testing port 8080...
[+] 1 192.168.144.1
[+] 2 81.46.0.157
[+] Public IP reached. The port 8080 is not filtered
[*] Post module execution completed