Ethical Hacking definitions

Application holes is a general category referring
to specific programming errors or oversights that allow hackers to
penetrate systems. (Throughout the list we separately cover holes in
specific applications that we are able to exploit frequently (such
as sendmail).) As part of a penetration test you identify
applications running on remote systems. Once identified, you can
perform a search for vulnerabilities and exploits that affect the
applications. Application identification is often performed by
capturing the application's banner, which frequently offers version
information. By searching vulnerability databases and the Web for
exploits specific to these versions, you can often find exploits
or processes that can lead to a system compromise. For example, in
one engagement we were initially unable to gain access to any of the
systems in the company's demilitarized zone (DMZ), but we did
identify several applications and versions that were running on the
systems. After performing some research, we discovered a
vulnerability in the Compaq Web management service that enabled us
to capture the backup SAM file out of the system's repair directory.
The system OS was patched and configured correctly. However, the
applications running on the system were not.

hacker tool kit is essentially a set of tools
placed on a compromised system to help escalate privileges or to
attack other systems. The hacker tool kit usually consists of a port
scanner (Nmap), Netcat (for creating listeners and back doors), and
any other tools you used during your discovery and exploitation
phase. Create a directory on the host system disguised by a name
that will not alert a general user or system administrator. The file
could also be hidden or streamed to further avoid detection. Just
remember that when the test is over you will need to remove the tool
kit, so remember where it is located.Now that you have administrator
access on the compromised host, you can run the tools from the host
remotely or just use it as a stepping stone using port redirection.
Port redirection involves taking network traffic coming into a host
on one port and directing out from the host on another. For example,
if we were able to compromise an NT Web server inside of a
packet-filtering firewall, we would use a port redirection tool such
as Fpipe
to accept connections on a specified port and resend them to a
specified port on a specified machine. On the compromised Web server
we could set up a Netcat listener on port 80. On the compromised
system we would execute:

C:\>nc –l 80 –e cmd.exe

On the testing system outside the firewall, we
could use Fpipe to make the connection to the Web server using a
different source port that is not filtered by the firewall. The
following command would establish a listener on port 25 on the test
machine and then redirect the connection to port 80 on the target
system using the source port of 25.

C:\>fpipe –l 25 –s 25 –r 80 webipaddress

By using telnet to connect to the test system on
port 25 we obtain a command prompt on the Web server inside the
firewall. The traffic travels to port 80 from port 25 and thereby is
able to bypass the filtering on the firewall. Using port redirection
such as this, you can bypass filtering rules on packet-filtering
firewalls or routers. Also, by remotely using a compromised host as
a testing platform you may be able to take advantage of trust
relationships.
Buffer
overflow attacks, also called data-driven attacks, can be run
remotely to gain access and locally to escalate privileges. Buffer
overflows in general are designed almost exclusively for UNIX
because in order to write a successful buffer overflow, knowledge of
the workings of the OS, specifically treatment of the TCP stack, or
the target application's memory/buffer-handling processes is
necessary. While there are buffer overflows for Windows and
Windows-based applications such as the IIS Web server, they are more
common on the UNIX environment. UNIX source code is generally
available, whereas source code to Microsoft operating systems is
generally not. This allows anyone interested to study and gain the
knowledge needed to create buffer
overflows for UNIX.A buffer overflow attack attempts to force
the target host to change the flow of execution and execute code the
attacker specifies. This is done by forcing the target to place so
much data into the finite-capacity target buffer that it overflows
(with data). This generally stalls or crashes the application
through which data was loaded. The point is to redirect the kernel's
pointer (which points to the next command to be executed) to a
portion of that excessive
data the hacker wants to have executed. This portion of data is
called an egg. A buffer overflow is challenging to write, in part
because it is OS and architecture specific.^[1]

^[1] For more specific information
regarding the creation of a buffer overflow, refer to the landmark
paper on this topic by Aleph1, “Smashing the Stack for Fun and
Profit” in Phrack 49, available on the Web at http://www.phrack.org/default.htm.

These buffer overflows cisa training generally only need to be
downloaded onto the target system, compiled, and executed. You do
not necessarily have to have root privileges to successfully run
them. The hard part in performing these attacks is to find a buffer
overflow that will work against your particular target. As
mentioned, these attacks are OS and architecture specific. Further,
if you are launching against a particular application or service,
the version and patch level must be taken into consideration. The
exploit code mentioned earlier that overflows the gethostbyname() buffer of
the rlogin service on Solaris 2.5.1 is not likely to work on the
HPUX OS or even more current versions of Solaris.
Buffer overflow attacks are dangerous and
effective. If you compile and launch a particular buffer overflow
attack against a susceptible target (server, service, or
application), it may need a bit of tweaking, but it will likely
work. Use such exploits only when you are fully aware of what they
are doing and all potential consequences. Further, any
experimentation should be done only on machines that are under your
own control. Buffer overflows can cause systems
to crash, leading to a denial-of-service
condition. Therefore, buffer overflows generally should not be
attempted against production systems without the written permission
of the client.