On Wednesday 23 October 2002 12:21 am, Cedric Blancher wrote: > During a pentest, we broke into a box through vulnerable PHP scripts > (one to upload files, and another one to include them and have commands > executed). At this point, we are able to execute commands and upload > binaries, but we do not have a remote shell. So, we launched a netcat > piped to a shell to connect on, because input flows were not filtered > properly. Imagine they were, but output policy was to be accept > anything. We could just get our shell in having our "piped shell" netcat > connect to the attacking box. So, output stuff would have allowed our > remote shell just like if there were not much filtering. > > This means, that with proper output filtering, we couldn't have achieve > this this easy, and must have find something else to gain our remote > shell. That would have make the intrusion far more difficult. The OUTPUT rules are always going to allow traffic to or from expected ports. 53 is a good one to guess is going to be made accessible, so you simply set up netcat to contact your external system on port 53, and you can still do what you've outlined above even with pretty good OUTPUT filters in place. The trouble is, netfilter only knows about IP addresses and TCP/UDP port numbers - it doesn't understand anything about the content of packets being sent on those ports, so it can't check that port 53 is being used only for DNS queries, port 80 is being used only for HTTP transfers etc. My point is that if you can break into a machine, you can break out of it again, so OUTPUT filters are generally either not much use, or they get in the way of your normal applications. Re the comment "--cmd-owner is your friend", I agree that this is worth adding to any OUTPUT rules you do choose to specify, but bear in mind that a compromised application or trojan is still going to be running under an expected user on the target machine, therefore --cmd-owner isn't necessarily going to see anything strange... If you're concerned about this level of security (which you should be) then you need to deal with Operating System security and things like Host Intrustion Detection - netfilter is not going to do the job effectively for you. Antony. -- Documentation is like sex: when it's good, it's very very good; when it's bad, it's still better than nothing.
