This idea popped in my head a while back and is still on my todo list (note: my todo list never shrinks). The following context/problem applies.
Suppose you want to steal information but the server you want to backdoor has got all ports ip restricted on an application level. Like a IIS instance which restricts users based on their ip address. How could this be bypassed without adjusting the IIS configuration or using a complicated rootkit. I thought of the following (note: this can also be implemented in ring0):
– hook the function responsible for sending/receiving data
– use Layered Service Provider http://www.microsoft.com/msj/0599/LayeredService/LayeredService.aspx
Either of those should do. Now the trick is to abuse the response packages which indicate that the user with the incorrect ip address is not allowed to connect to the server. Those packages are always sent and thus not suspicious. It also means that if you modify those packages you do not have a extra outgoing connection, so there is no connection which could be killed by the firewall.
The hard part is to maintain some kind of session or stack to allow connection with multiple ip address. This prevents log analyses to determine that a certain ip address has requested the forbidden page like 4000 times. The beauty I think is that because the data is smuggled in already existing packages you defeat most firewalls. This is purely hypothetical because I haven’t had time to implement this yet. A rough sketch would look like this:
client: sends normal packet trying to access the server but including a password for example and a unique id
server: rejects it cause the ip addresss is incorrect BUT our backdoor sniffs the packet and detects the password, it then builds a session using the supplied unique id. It modifies the outgoing reject packet injecting for example: ok:unique_id+1
After that the client can just keep sending packets including commands to do whatever it feels like from different ip addresses as long as it keeps the unique id and password. Our backdoor should then be able to run the received commands and use the rejection packets as transportation to get the response to the client.
Well this is just a thought and who knows maybe it’s usefull maybe it’s not…I won’t know until it’s implemented and tested.