Second, the target network must also allow the attacker to establish a new
inbound connection to the port that the shellcode has bound to. These conditions often
exist when the target computer is not protected by a firewall, as shown in Figure 9-1.
This may not always be the case if a firewall is in use and is blocking incoming connections
to unauthorized ports. As shown in Figure 9-2, a firewall may be configured to
allow connections only to specific services such as a web or mail server, while blocking
connection attempts to any unauthorized ports.
Third, a system administrator performing analysis on the target computer may wonder
why an extra copy of the system command shell is running, why the command shell
appears to have network sockets open, or why a new listening socket exists that can??™t be
accounted for. Finally, when the shellcode is waiting for the incoming connection from
the attacker, it generally can??™t distinguish one incoming connection from another, so the
first connection to the newly opened port will be granted a shell, while subsequent connection
attempts will fail. This leaves us with several things to consider to improve the
behavior of our shellcode.
Gray Hat Hacking: The Ethical Hacker??™s Handbook
198
Figure 9-1
Network layout
that permits port
binding shellcode
Figure 9-2
Firewall
configured to
block port
binding shellcode
Reverse Shellcode
If a firewall can block our attempts to connect to the listening socket that results from
successful use of port binding shellcode, perhaps we can modify our shellcode to bypass
this restriction.
Pages:
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387