Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Looking for pointers in the right direction, have seen multiple examples of exploit code allowing shell connections on ANY 'in-use' port, while the original application on that port continues to function without issue.

I am interested from a programmatic/system level view how this is achieved.

I ask here in desperation as all I have come up with is tcpmux (which uses TCP#1 and would break existing applications on the port as a service name needs to be sent by each client before the specified application responds).

Best way I can describe it is port knocking with a fallback scenario should the knock fail to the original application listening on the port.

My google-foo seems weak on this one. Also, I've only seen this on windows hosts, would like to further my research to see if the same is possible on Linux systems.

share|improve this question
If you don't get good answers here, you might try, a beta StackExchange site that focuses on IT Security in general. – sysadmin1138 Apr 6 '11 at 14:11
Thanks for the info, will give serverfault a chance first! :) – TrXuk Apr 6 '11 at 14:20

I may be misunderstanding what you're asking here, but generally the way this works is:

  1. a vulnerable application is listening on a port
  2. your attack comes into the app, and the app uses the "accept()" call to handle it. This returns the file descriptor for the accept()'ed socket.
  3. your attack executes some shellcode within the app, which calls "dup()", with the first argument being the fd returned by the accept() call, and duplicates descriptors 0, 1, and 2 (stdin, stdout, and stderr).
  4. then your shellcode exec()'s a shell, which will have stdin, stdout, and stderr associated with the socket.

It's really just:

//figure out which fd to use (we'll call this "n")

Now, your exploit program (at your end) has a networked shell it can talk to. In a multi-process/multi-threaded application, the target app should continue to function in this scenario - new connections will be handled by accept() as normal, but you've got a shell running within the target process. An example would be an exploit against, say, apache - the child apache process that you originally connected to would become your shell, essentially, but the parent and the other children would continue to function as they normally would.

share|improve this answer
Hi Malcompdx, Thanks for a very informative answer! However, the item I have seen did the following; - Exploit occured, shellcode uploaded. - Exploit readme's said that after exploit, the attacker could connect to ANY service on the system and would receive a shell, where all services would continue to run normally for other users. This seems to suggest some kernel/IP stack involvement in the payload code, it is this kindof functionality I was looking to research more. – TrXuk Apr 6 '11 at 15:46
I'd love to see the reference, that sounds interesting. Wildly speculating, I'd say that yes, this sounds like an exploit that got the attacker root/ring0 access, which was then used to hook network stuff in the kernel. That's certainly possible, but it's beyond what I know off the top of my head. – malcolmpdx Apr 6 '11 at 15:52
I dug in a bit more to this - and essentially, your shellcode would have to modify the running kernel (which is possible if you're executing in the right context) and hook the syscall for accept(). 2.6 kernels try to prevent this by making the syscall table read-only, but I think there's ways around this. If you were able to hook accept(), you could make decisions based on whatever information you could get from the incoming connection, and spawn a shell for certain connections. – malcolmpdx Apr 7 '11 at 14:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.