Ceh: Attack Phases: Understand penetration testing and the various methodologies used

The Testing Process

There are many reasons an organization might order a test. If compliance with a standard is mandated, they will perform yearly audits that involve vulnerability assessments. In other cases, threat levels need to be tested because something in their risk management process raised a concern.

Tests are conducted both internally and externally. They can be outsourced to a third party or management by an in-house team separated from the administrators. There is no one test that is better than the other, it is always a matter of cost versus value. Clients that order the test must have a clear reason for why they are doing a test and must select the best product for the task.

In all cases, a formal project management process must be followed for both complex tests and simple tests. It is critical to avoid “scope creep.” It is also critical to have the proper tracking of everything that happens. The risk is worse than just wasting time and money; incomplete penetration tests can leave behind exposures that no one will think to go back and fix.

For the CEH, know this basic outline of the testing lifecycle. Rather than memorize it, make sure you can visualize the steps until you are comfortable with the order.

1. Determine the type of test required

2. Charter a project using formal project management methods

3. Draft all required legal documents

4. Approve the testing outline and strategy (in writing of course)

5. Test the communication channel, and make sure that if something goes wrong the test can be paused and the problem can be reported

6. Conduct the test

7. When the test completes, create a report

8. Securely deliver the report and archive or destroy all original copies according to client agreements

9. Schedule a follow-up test if appropriate

10. Review the entire process and look for opportunities to improve the next one

Types of Tests

For the CEH exam it is important to know the various testing types and under what circumstances they might be ordered.

Black Box tests are ordered when the client wants the most realistic type of test possible. Only the sponsor of the test knows it is taking place and often times will only have contact with the testing team through a liaison.

No information is given to the team prior to the test. All they really know are the rules of engagement. For example, social engineering and physical security testing might be permitted, but no Denial of Service is allowed.

This test can be very risky and great care must be taken on the part of both the client and the consultant to protect each other and themselves. There are legal concerns as well as a great risk in something going wrong during the test. A clear communication plan and rollback procedure must be clearly established.

White Box tests are perhaps the most common and least invasive. Often times only the scanning phase is conducted and commercial vulnerability assessment tools are used to obtain a baseline of the present condition of the network. Many compliance standards require regular White Box tests as a routine part of yearly or quarterly audits.

Grey Box tests are specialized for a specific objective. The client might want to order a test for a particular vulnerability that was discovered during a White Box test that needs to be confirmed. Other times a particular aspect of the present security policy might be tested to see if users are compliant.

Rather than attempting strange names, odd IP address schemes or layers of NAT behind overlapping networks, it is a better practice to have proper change control, detection, incident response, and access controls in place. It is difficult to prevent a person from attempting a network footprint, but what they find can be discouraging to them.

All chat systems at this point include features for file downloads, interactive games and even voice calls. The user must be careful about accepting these exchanges and social engineering techniques leverage these products.

These extensions can contain malicious code that modifies page content, blocks or replaces advertisements, records keystrokes, or redirects requests for content to other servers. Since they are accepted by the victim as legitimate applications the security context can be of a high privilege and anti-virus scanners might not look for it.

When a client logs into a web based application, a “token” or string of random characters is given to their browser and then presented again on each request for a new page in the domain. If a third party can obtain this token, either by capturing it as it is exchanged on the network or as it rests on the client’s hard drive in the form of an unencrypted cookie, the attacker can replace this token and assume the identity of the target user.

Proper implementation of SSL and Cookie encryption can prevent this attack, but not all web applications follow the best practices.

Session hijacking is about compromising the trust of two hosts, services, or accounts. Countermeasures are put in place to counteract the effects of eavesdropping (sniffing) login credentials. If the attacker can wait until trust is established and then impersonate one of the parties, the blind system would have no idea it is giving or receiving data whose integrity has been breached.

The Differences Between Spoofing, MiTM, and Hijacking

Spoofing, a technique that is useful in social engineering is the basic act of pretending to be something else. People are not always the essential parties. The problem with some authentication controls is they are based on hardware or protocol constructs and have nothing to do with user accounts or actual identities.

The inherent problem with spoofing is that the receiving host will reply to the party that seemed to have sent the data. Either the masquerading party has to become that party, or she must eavesdrop in. An additional problem could occur if the receiving host doesn’t get the reply it expects after sending the data; it may try to send more data assuming an error has occurred. If the masqueraded victim receives these messages, he might get confused and create additional confusion through asking more questions.

Although spoofing has its place, it is often more of a component in an attack rather than the only technique.

An MiTM attack also involves social engineering. The attacker is able to transparently accept and send traffic to the true endpoints of communication. Much like sending important documents via a courier, the data is handed off, stored, and forwarded to the receiver. The transparent part is the trick. If the client sending the data knows it is using a proxy service, it is agreeing to this type of exchange. If not, the middle man must exploit a service at a lower level of the OSI model.

Application services, such as surfing the web, usually involve client/server interactions. If the client knows about a proxy server, it sends the data there and gets the response back from the proxy without worry. In this case, the client must be “proxified” in that it is fully aware of the man in the middle transaction. The human being user, however, might not be. Clients can be pointed to proxies without their user knowing or caring in the slightest, and this is the best MiTM attack vector. These proxies can be anywhere on the Internet, and this is a common technique of the malware exploits discussed in previous chapters.

If the attacker has to utilize lower layers of the network model, meaning that protocols must be manipulated to hijack traffic, greater skill and positioning is required. Earlier we discussed the ARP poison attack as an example of this. The victim is totally unaware of the attack, and therefore the attacker is considered transparent.

Pure session hijacking is the ultimate example of combining techniques to completely take over an established session after the authentication phase has completed.

We can illustrate this by using a TCP session hijack as an example and following the sequence of events takes place:

1. Tracking the connection

2. Desynchronizing the connection

3. Injecting the attacker’s packet

Tracking the connection

The attackers must identify the targets and observe the characteristics of their connections. Predicting sequence numbers and windows sizes will allow the attacker to construct packets in advance of the attack. These packets will be injected at exactly the right time.

If a server is presently communicating with an authenticated client, it is the client that needs to be knocked offline (assuming the attacker wants to impersonate the client). If this step does not happen correctly, the server will see echoes, traffic from both the real client and the attacker. The server will get confused and possibly drop the connection.

The client must be convinced it is no longer speaking to the server while leaving the server still expecting data. This can be accomplished using a variety of means.

Sending NULL data to the server spoofing the client’s IP address as the source will cause it to expect traffic the real client is not prepared to send. Other techniques involving SYN/ACK and FIN fags can be used. The idea is to make the server think it is at a different place in the conversation, a place the attacker knows but the client doesn’t.

The client is the DoS’d (Denial of Serviced) to keep it from attempting to recover. The attacker is spoofing the client address, so he needs to be able to sniff the traffic that comes from the server, since he is not really the destination of the traffic.

Injecting the attacker’s packet

Packets can be injected at this point onto the network in the form of disruptive data that will be trusted or commands that continue the conversation.

Types of Session Hijacking

The official CEH courseware lists several types of hijacking, though some of them are arguably completely different forms of attack. This is one of those points where the precision of the terms is less important than the point behind them. Be very familiar with the vocabulary, however:

TCP hijacking

UDP hijacking

RST hijacking

Session tokens

This form of attack involves having an accurate understanding of the current state of synchronization between two hosts. The handshake must be observed, and sequence numbers must be set in the injected packets to be accepted inside of the current window.

Since this form of attack was discovered, RFC 1948 was written to suggest that ISN (Initial Sequence Numbers) are not incremented every four microseconds as suggested by RFC 792, but should instead involve a PRNG (Pseudo Random Number Generator). The quality of the randomness of the ISN greatly impacts the difficulty of predicting the number.

RST hijacking

This is a form of DoS attack. Packets are injected into an established TCP stream that convinces one side that the other is confused and wants to call it quits. All it takes is to set the RST flag, set the ACK number so it is in the window and, and spoof one side of the conversation. Ettercap is a tool that makes this easy as long as the initial synchronization was observed.

The UDP protocol does not involve the complexity of TCP. There are no flags or SEQ/ACK numbers to keep track of sessions. MiTM attacks and DoS attacks are much easier. The UDP protocol does not require the receiving host to respond at all, or acknowledge that there is even a source port to which a response can be given. All communication is handled at the application layer.

Whether or not an application uses the UDP or the TCP protocol, if the application layer requires an authentication or session token, it may be possible for the attacker to capture this token from the network or from a MiTM attack and replay the token to the server.

In stateless environments such as HTTP, session hijacking based on HTTP session tokens and CSRF (Cross-site Request Forgery Attacks) are examples of hijacking. The applications try to create a sense of “state” using unique strings that will be volleyed back and forth. Trust is established and then abused either by replaying a challenge or issuing commands that are trusted. The attacker can capture this information through a proxy server, or cookie stealing.

Countermeasures to Session Hijacking

Since the advent of the session hijacking attack, the TCP protocol specification has been modified to make sequence number prediction extremely difficult. Since it is a 32 bit field, there are about 4.3 billion possible values that can be chosen for the ISN. The attacker would have to sniff enough connections from a host to predict what an ISN would be in the future, even a PRNG (Pseudo-Random Number Generator) is sufficient to make this extremely challenging.

Circuit level gateway firewalls take this a step further by translating the ISN at the same time the network address and ports are translated when a host initiates an outbound connection. This in effect makes it a Layer 4 proxy server; the circuit level gateway is a man-in-the-middle but does not interfere with Layer 7 data.

IPSec (Internet Protocol Security) incorporates an integrity check that will not accept forged packets. Between all of these countermeasures, session hijacking threats are well mitigated, but the presence of the idea is important both from an academic standpoint, and to illustrate the importance of maintaining such countermeasures.

Other forms of session hijacking are more difficult to prevent. Session hijacks based on http session IDs must not be sniffed, guessed or predicted. This involves the proper use of SSL and random number generation for the token. Wireless evil-twin attacks are best prevented with the use of WPA-Enterprise or just plain physical situational awareness.

A Web server is essentially a file server. It receives requests from a client application for a file and returns the result. Sometimes the file on the server contains active code that must be processed first and the result is a text file that is sent back to the client. The text file contains the markup language for content structure, and may also include scripting and style instructions the client must also interpret in order to render the page. This request-response nature of HTTP is important to understand as well as the role of both the client and the server.

When users contact a Web server, they usually log in as anonymous users. In Windows this account is IUSR_ and in Linux it is usually the account “Nobody.” In both cases the password is blank, and the user account should have extremely restricted access to the system as a whole.

The request a client makes is in the form of a URL (Uniform Resource Locator) and a series of header messages.

The HTTP Protocol

The Web server provides the HTTP service between the client and server. HyperText Transfer Protocol is essentially a “request/response” transaction that facilitates the simple exchange of a set of data. As previously mentioned, this data is in the form of a text file.

The fact that this file contains HTML is not important to HTTP. The data is passed to the client and the client must know what to do with it. This allows for multiple media types to be involved in a typical Web page viewing. The specific type of media MIME type (Multi-Part Internet Media Extensions) is listed in the HTTP header. This allows the client browser to know what BHO (Browser Helper Object), or “plug-in” to open to receive the file and process it.

When a client makes a GET request, the server is required to respond. The protocol header contains a code that indicates the nature of the response. The following is a sample of these responses:

HTTP defines several methods the client can invoke. Some are considered safe, while others might have more powerful effects. The safe methods include:

HEAD

GET

TRACE

POST

DELETE

We do not have to get into them all right know, but notice that GET and POST show up in different lists. These are the two principal ways in which forms that appear on Web pages are submitted. From the names of the other methods it is clear that HTTP supports multiple tasks. Downloading Web pages is only the part of what it can do. The CONNECT method for example can also be used to create HTTP tunnels that evade firewalls and montitoring systems.

Understanding Requests

When an HTML form is calling the GET method, the names of the form elements are paired up with the input data (what you fill out) and appended to the URL in the form of a query string. It follows the question mark. Examine the following example string and the labels within:

http://host.domain.tld/resource/path/page.ext?form_item1 = string1&formitem2 = string2

The name value pairs passed from the client to the next page (the action attribute of the form) are separated by ampersands. The string to the left of the equal sign is the form element name, and the value to the right is what the user provided before clicking the submit button.

Hidden form field elements (not visible in the browser but can be seen in the source code) can carry name value pairs, too. For instance, a form that is tracking the number of login attempts made into a page might look like this:

http://host.domain.tld/resource/path/page.ext?attempts = 2

Modifying either the URL or the source code of the page, then reloading and submitting, could possibly overcome the limitation imposed by the application. This is one of the most important characteristics of the GET method. Also notice that if credentials are included in the URL they would be visible in the browser address bar.

Credentials are not just usernames and passwords. They can also be token strings, often implemented as “SessionID = asfdjwqjherj2hj2h34jqsd7343rq” or something similar. This token is generated on the server and passed back and forth between the client and server in order to establish “state.”

HTTP 1.0 did not support “state.” HTTP 1.1 added the feature. It is important for some Web applications to understand unique users and the time they spend on the website. A random string of characters can be used to make this easy. If attackers can sniff or otherwise capture this token they can become “you.” They simply replace the token in their own request.

Knowing that IP addresses might change during the session and considering the original intent of the Internet to be stateless, it was a design choice not to consider additional elements outside of this token to establish a stateful connection. The URL is not protected by SSL (Secure Sockets Layer).

The POST method, on the other hand, places the name value pairs in the HTTP header and can be protected by an SSL connection. Proxy servers can still be used to perform man in the middle attacks if the login occurs before the SSL tunnel is established. It is important when sensitive data is exchanged in the header that the SSL (Secure Sockets Layer) connection be established first.

URL Encoding Schemes

The specification for URLs says that certain special characters are either forbidden from use or must be encoded because they already have special meanings. The space character, for instance, can not be used in a URL and can be substituted for with a plus sign. The ampersand, question mark, and equal signs are all parts of a query string (sometimes also referred to as a parameter string).

The most common way to encode characters is by using “percent encoding” which is a percent sign followed by a two digit hexadecimal representation of the original character. The following are just a few examples:

http://www.example.dom/cgi-bin/search+page.pl?search=CEH+Certification

This URL could become the following URL if certain characters were encoded:

http://www.example.dom/cgi-bin%2Fsearch%20page.pl?search=Intense%20School

There are other ways to encode URLs as well as to represent the address of the website itself. Some characters can be double encoded, and in certain cases triple encoding may work.

Since the client browser plays a role in this process along with the HTTP server, some attacks are better conducted directly through Telnet connections to port 80 on the Web server.