Chapter 8. Hacking Web Servers and Web Applications

This chapter covers the following exam objectives:

• Understand web server operations

• Identify web server vulnerabilities

• Describe web application attacks

• Perform web footprinting

• Understand basic Metasploit

Web Servers

It is important to understand web servers as well as web applications in order to understand the hacking and penetration methodologies used with them. Two of the most popular web servers are Microsoft's Internet Information Services (IIS), which ships with Windows (both client and server versions), and Apache. While Apache is not the only open-source web server, it is by far the most widely used. Regardless of the specific web server, there are some common elements:

• Document root: This is a folder on the server where web page documents (HTML, CSS, etc.) are stored.

• Server root: This folder stores the server's configuration files, the actual server executable, and log files.

• Virtual document tree: This is storage on a different drive or partition (perhaps even on a different machine).

• Virtual hosting: This technique involves hosting multiple domains or websites on the same server.

• Web proxy: This is a server that sits in between a web client and web server to prevent IP blocking and maintain anonymity.

Web Server Architecture

Understanding the architecture of a web server is important. Open-source web servers usually use Linux as the operating system. A basic open-source configuration is shown in Figure 8.1.

Apache is the most common web server for Linux systems. The CEH exam will emphasize Apache over others, such as Lighttpd and OpenLightSpeed. Similarly, there are multiple open-source database options, but the two most common are MySQL and PostgreSQL.

The Windows world is simpler than the open-source world, in that there is usually just Windows Internet Information Services (IIS). Yes, you can install open-source products like Apache on Windows, but typically a Windows server uses IIS. IIS provides a fairly standard architecture, as depicted in Figure 8.2.

The web server core is responsible for beginning processing of the HTTP request, authentication, authorization, cache resolution, handler mapping, handler pre-execution, release state, update cache, update log, and end request processing. The native modules are responsible for anonymous authentication, managed engine, IIS certificate mapping, static file, default document, HTTP cache, HTTP errors, and HTTP logging.

The CEH exam looks at a seven-layer model for website attacks (essentially what is being attacked). This model, shown in Figure 8.3, provides a good way to envision the attack process.

This chapter looks at level 5 and above, but you could think of Chapter 3, “System Hacking,” as having addressed stack level 3. This should help you to understand the web attack stack.

Web Server Issues

There are obviously a wide array of issues that could enable a web server to be hacked. However, there are some common issues that are both something for the attacker to focus on and something for the ethical hacker to test for. The following list should help you with these:

• Improper permissions on files and directories are a common flaw on web servers. They can lead to serious security issues.

• Unnecessary services may be enabled. Basically, on a web server, if you don't actually need something, turn it off.

• Administrative or debugging permissions may be accessible.

• Any misconfiguration or bug in the server software is a security issue.

• Problems with digital certificates can include self-signed certificates, misconfigured related settings, and similar issues.

• Default accounts, particularly when they still have default passwords, are a tremendous security risk.

• Improper authentication is problematic. Whether it is authentication to the web server or some third-party software or service, strong authentication is critical.

• Verbose error/debug messages can give away too much information. An attacker needs to learn as much as possible to try to compromise the server. Messages that provide too much information help hackers with their attacks.

• Sample script and configuration files existing on the web server can also be exploited by attackers.

A successful attack on a web server can lead to minor issues like website defacement or far more substantial issues such as compromising accounts, accessing other servers, theft of data, and more. It is important that a server itself be secure. Simply securing the applications (as discussed later in this chapter) is not enough.

Attacks on Web Servers

DoS (denial of service) attacks, as discussed in Chapter 6, “Denial of Service and Session Hacking,” can be used against web servers. These attacks won't give the attacker access to data but will render the web server inaccessible to legitimate users. In the case of e-commerce servers, this can have a tremendous negative effect on a business.

DNS server hijacking is also a common attack. This attack does not directly exploit flaws in the server. Rather, it attempts to change a DNS server's records so that customers are redirected to a fake site. Then customers log in to the fake site, believing it is the real site. The fake site harvests the customers' credentials. Attackers don't have to try and replicate all the details of the real site; they can simply put up an error message after login, indicating that there is some problem with the site, and the user should please try back later. In the meantime, the attackers then have customer login credentials and can log in to the legitimate site with them.

There are multiple types of DNS attacks. Another DNS attack, the DNS amplification attack, exploits the DNS recursive method. Public open DNS servers are usually the target. The attacker sends a DNS name lookup to the DNS server, with the source address spoofed to appear to be the target's address. When the DNS server responds, it responds to the target. The attacker will often not just request a name lookup but as much zone information as possible. The way to accomplish this is to pass an argument such as ANY, which tells the DNS server to send any available data. The attacker floods the DNS with such requests. If possible, the attacker may use a botnet, with all the nodes in the botnet flooding the attack. This sort of attack can be done on any target, not just web servers.

Directory traversal attacks are unique to web servers. With such an attack, the attacker attempts to access restricted directories. By simply trying ../, an attacker can attempt to move a directory. If the server is properly configured, this will be ignored and won't work. For example, on a Linux server, you could attempt:

https://reallybadwebsite.com/loadImage?filename=../../../etc/passwd

If the server is secure, this won't work. However, if it is not secure, you will be able to grab the passwd file. Some servers simply block certain characters to try to prevent such attacks. That is not really effective because an attacker can encode the characters. The following shows encoding for certain characters:

%2e%2e/ represents ../

%2e%2e%2f also represents ../

%2e%2e represents ..

These and other encodings take advantage of encoding schemes. UTF-8 encoding is a variable-width encoding that can represent any character in the Unicode character set. It is backward compatible with ASCII. When Microsoft added Unicode support to its IIS web server, a new way of encoding ../ was introduced into Microsoft code, causing attempts at directory traversal prevention to be circumvented. This technique can also be used to bypass web application firewalls. Multiple percent (%%) encodings translate into the / and symbols.

HTTP response splitting is a web server–specific attack. An HTTP response splitting attack involves adding header response data to the input field so that the server splits the response into two responses. The attacker can control the first response to redirect the user to a malicious website, and the web browser will discard the other responses. To quote OWASP (see https://owasp.org/www-community/attacks/HTTP_Response_Splitting), “HTTP response splitting is a means to an end, not an end in itself. At its root, the attack is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header.”

Web cache poisoning is another web server attack. The attacker swaps cached content for some URL that has infected content. That way, users of the web cache inadvertently use the infected content. The attacker may also try to force the web server's cache to flush its actual cache content and send a specially crafted request, which will be stored in the cache.

Any remote connection technology can also be exploited. For example, SSH can be attacked. If SSH is not properly configured, or if it uses weak authentication, an attacker can exploit SSH.

Other attacks that we have discussed in previous chapters can also be used to target web servers. Man-in-the-middle (MiTM) and phishing attacks can be used to steal credentials that can then be used to log in to the web server. These attacks are not web server specific.

Password cracking is another attack that is not specific to a web server. However, a web server might have multiple passwords that an attacker could attempt to exploit. The web applications, the web server itself, the underlying operating system, SSH connections, FTP servers, and anything that connects to a web server is a potential target.

Web Shells

A web shell is simply a shell (like the BASH shell in Linux or the command line in Windows) that provides access to a web server. Note that I said like the BASH shell or command line. A web shell is not really a shell; it is often programmed in a language such as PHP and may be unique to a web browser. An attacker who can access the web shell can use that to attempt to upload, download, delete, or execute files on the web server.

Sometimes an attacker will attempt to introduce a web shell into a web server that does not already have one. Techniques like SQL injection and remote file inclusion (RFI) can facilitate this process. If an attacker can successfully get a web shell on the target server, the server is quite vulnerable.

Securing the Web Server

As discussed previously in this book, your goal as an ethical hacker is to improve security. So, if you find problems with a web server, what do you do? There are some specific improvements you should recommend, including the following:

• Eliminating unneeded services: The web server should do one thing: serve up web pages. Anything else—unneeded services, games, development tools—should be uninstalled or at least disabled.

• Patch management: The web server must stay up to date on patches. That means the underlying operating system, the web server application, any third-party web components or services/programs you use—literally everything—should remain patched.

• Segmentation: Put a web server in an isolated segment. This ensures that if your web server is compromised, your entire network may not be.

• Scanning: Scan the web server for vulnerabilities on a regular basis.

• Using secure protocols: Avoid insecure protocols such as Telnet and use secure protocols like SSH instead.

You also need to be able to detect web attacks. There are various software tools that can scan your web server for changes. Some attacks are very obvious, such as defacing the landing page. Others are hard to detect, and you may not be aware of them until long after they have been perpetrated.

Web Applications

It is important that you have a working knowledge of how websites work. Much of the information in this section should be review, but if you have any gaps in your knowledge, this section should help fill them in.

Web traffic uses HTTP (Hypertext Transfer Protocol), which normally operates on port 80. If it is encrypted with SSL/TLS, it operates on port 443. The primary means of communication is via messages. Table 8.1 provides a summary of the basic HTTP messages a web page might send.

The most common HTTP commands are GET, HEAD, PUT, and POST. In fact, you might see only these four commands during most of your analysis of web traffic. You should know that the GET command is used by the server to get information, not by a user to get information from the server. So it is very much like the POST command. These are the differences between GET and POST:

• GET requests can be cached; POST requests are never cached.

• GET requests remain in the browser history; POST requests do not remain in the browser history.

• GET requests can be bookmarked; POST requests cannot be bookmarked.

• GET requests should never be used when dealing with sensitive data.

• GET requests have length restrictions; POST requests have no restrictions on data length.

You can get more details about these messages as well as how to use GET versus POST at http://www.w3schools.com/tags/ref_httpmethods.asp.

The response codes are just as important. You have probably seen the message “Error 404: File Not Found.” But you may not be aware that there are a host of messages going back and forth, most of which you don't see. The HTTP message codes are shown in Table 8.2.

These basic messages are sent from the web server to the browser. Most of them are never seen by the end user. But they do provide information about the web server.

SQL Script Injection

SQL script injection is a quite common attack on websites. In recent years, more websites have taken steps to mitigate the dangers of this type of attack; unfortunately, many websites are still susceptible. This type of attack is based on passing SQL (Structured Query Language) commands to a web application and getting the website to execute them.

Before we can discuss SQL injection further, we must talk about SQL and relational databases. This should be a review for most readers. Relational databases are based on relations between various tables. The structure includes tables, primary and foreign keys, and relations. A basic description can be summarized with the following points:

• Each row represents a single entity.

• Each column represents a single attribute.

• Each record is identified by a unique number called a primary key.

• Tables are related by foreign keys. A foreign key is a primary key in another table.

You can see these relations in Figure 8.4.

All relational databases use SQL commands such as SELECT, UPDATE, DELETE, INSERT, WHERE, and others. At least the basic queries are very easy to understand and interpret. However, SQL can be misused, and this is why SQL injection is possible.

Basic SQL Injection

The most basic SQL injection works like this: Many websites/applications have a page where users enter their username and password. That username and password will have to be checked against some database to see if they are valid. Regardless of the type of database (Oracle, SQL Server, MySQL), all databases speak SQL. SQL looks and functions a great deal like English. For example, to check a username and password, you might want to query the database and see if there is any entry in the users table that matches he username and password entered. If there is, then you have a match. The SQL statement might look something like this:

"SELECT * FROM tblUsers WHERE USERNAME = 'jdoe' AND PASSWORD = 'letmein'"

While this is valid SQL, it hardcodes the username and password. For a real website, you would have to take whatever the user entered into the username field and password field and check that. This can be easily done (regardless of what programming or scripting language the website is programmed in). It looks something like this:

String sSQL = “SELECT * FROM tblUSERS WHERE UserName ' “ + txtUserName.text + “ ' AND Password =
' “ + txtPassword.text + “ ' “

Notice the extra instances of ' that are highlighted here; these are included so that whatever the user types in for username and password will be within single quotes and contained in the larger SQL statement, which is in turn in double quotes.

If you enter the username 'jdoe' and the password 'letmein', for example, this code produces the following SQL command:

"SELECT * FROM tblUsers WHERE USERNAME = 'jdoe' AND PASSWORD = 'letmein'"

If there is a username jdoe in tblUsers, and the password for that user is letmein, then this user will be logged on. If not, an error will occur.

SQL injection works by putting into the username and password block some SQL that is always true. For example, suppose you enter 'OR '1'='1 into the username and password boxes. This may seem like a very odd thing to type in, but let's examine what it will cause. It will cause the program to create this query:

"SELECT * FROM tblUsers WHERE USERNAME = 'OR '1'='1' AND PASSWORD = 'OR '1'='1' “

Notice that we start with a single quotation mark (') before or 1='1 This is to close the open quote the attacker knows must be in the code. And if you see '', that essentially is a blank or null. So, what we are telling the database is to log us in if the username is blank, or if 1=1, and if the password is blank, or if 1 = 1. If you think about this for a second, you will see that 1 always equals 1, so this will always be true.

There is no significance to 'OR '1'='1; it is simply a statement that will always be true. An attacker can use any similar statement as long as it always evaluates to true. The following are examples:

• ' or 'z' ='z

• ' or '999' ='999

• ' or (1=1)

That is one thing that makes it so difficult to block. Rather than attempt to block the specific equivalence, a web site is defended by filtering symbols such as the single quote.

More with SQL Injection

Earlier in this book, when I first briefly mentioned SQL injection, I suggested that filtering input could prevent SQL injection. For example, a programmer creating a website should write the code to first check for any common SQL injection symbols, such as the single quote ('), percent sign (%), equal sign (=), or ampersand (&), and if those are found, stop processing and log an error.

Since SQL symbols are well known and might be blocked, a hacker needs to know ways to get around that blocking. One way to get around it is to use alternative symbols for SQL symbols. For example, inject without quotes (string = “%”):

• ' or username like char(37);

• Char(39) is the single quote.

• So instead of ' or '1' = '1 you have

• Char(39) or Char(39) 1 Char(39) =Char(39) 1

• Char(42) is the asterisk

If the attacker is successful logging in with the basic example shown previously, then he or she can begin to explore. Perhaps you have logged and sees that user has a first name of John. The next goal is to find the next user. Put this in the username box (keep password box the same)

' or '1' ='1' and firstname <> 'john

Or the attacker might try this:

' or '1' ='1' and not firstname != 'john

Obviously, firstname may not be a name of a column in that database. The attacker might have to try various permutations to get one that works. This is just the beginning. At this point, the attacker is only limited by his or her knowledge of SQL and patience.

XSS

XSS (cross-site scripting) is a relatively simple type of attack. An attacker attempts to load scripts into a text field so they will be executed when another user visits the site. For example, the attacker might go to a product review section and, instead of entering a review, enter JavaScript.

Essentially, the attacker types scripts into an area that other users interact with. Then, when other users go to that part of the site, the attacker's script runs in place of the intended web site functionality. The attacker may use such an attack to redirecting users.

Whereas XSS exploits the trust a user has for a particular site, CSRF (cross-site request forgery) exploits the trust that a site has in a user's browser. Consider the review section of an e-commerce site, like what is shown in Figure 8.5.

An attacker may write a review but, rather than typing in a review, the attacker types in JavaScript, as shown in Figure 8.6.

Now a legitimate user who visits this product page and reads the review will be redirected to some other website. The attacker might have set up a target website to look much like the real e-commerce site. It could put up a message stating “Your session has timed out, for security reasons log back in” and then capture the user's login credentials. The attacker is only limited by their knowledge of JavaScript.

Remote File Inclusion

RFI (remote file inclusion) is a vulnerability usually found in web applications that rely on runtime scripting. An application creates a path to executable code, but the attacker subverts this process to cause a different file to be executed. This leads to a remote code execution. The attacker is able to execute the code of their choice on the target server.

CSRF

CSRF (cross-site request forgery) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF is based on tricking the user of a site into sending requests that the attacker wishes to send to the target site. The attacker inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf. For some websites, browser requests automatically include any credentials associated with the site, such as the user's session cookie, IP address, Windows domain credentials, and so forth. This is the counterpart to XSS. XSS attacks a user based on their trust of the site. CSRF attacks a site based on its trust of a given user.

Forceful Browsing

A web server will send a file to a user as long as the user knows the filename and the file is not protected. An attacker may exploit this fact and “jump” directly to specific web pages within a site or to files on a server. For example, perhaps a registration page includes an HTML comment mentioning a file named _private/privatedata.txt. By typing http://www.xxx.com/_private/ privatedata.txt, an attacker can get that file.

An attacker may append ~ or .bak or .old to a cgi name to get an older version of the source code. For example, www.xxx.com/cgi-bin/admin.jsp~ returns admin.jsp source code.

There are many ways to exploit this type of weakness. Forceful browsing is an attack vector that any hacker should be familiar with. Keep in mind that, as an ethical hacker, your goal is to find the weaknesses that a malicious actor might use against a target. It is better for you to find and report an issue than for some bad actor to find and exploit it.

Parameter Tampering

Parameter tampering is an exploit that is becoming rather outdated. At one time, it was a common way to attack a website, but today few websites are still vulnerable to this type of attack. This is because fewer web programmers today still keep interesting information in the URL. Parameter tampering is a form of web-based attack in which certain parameters in a URL or web page form field entered by a user are changed.

Parameter tampering is often done to alter the behavior of a web application. The most obvious example is when values are in the URL, such as this:

• Valid transaction: http://www.victim.com/tx?acctnum=12&debitamt=100

• Malicious transaction: http://www.victim.com/tx?acctnum=12&creditamt=1000000

Parameter tampering is simple and easy to test for, so it is probably a good idea to include it as one of the items you test for in ethical hacking.

Cookie Poisoning

Most web applications use cookies to save information such as session time, user ID, or any other information the website considers relevant. For example, when a user logs in to a site, a login web script may validate his username and password and set a cookie with a numeric identifier. When the user checks his preferences later, another web script retrieves the cookie and displays the user information records of the corresponding user. Since cookies are not always encrypted, they can be modified. In fact, JavaScript can modify, write, or read a cookie.

Any change to a cookie is cookie poisoning, and cookie poisoning can be used for session hijacking, data theft, or any number of other attacks. As mentioned earlier, XSS can be used to launch a cookie poisoning attack.

The primary methods for defending against cookie poisoning are listed here:

• Encrypt the cookie.

• Always have a timeout so session cookies will time out.

• Don't put any data that is not absolutely needed in a cookie.

• Don't put highly sensitive information such as passwords in a cookie.

LDAP Injection

LDAP injection is an attack that exploits LDAP (Lightweight Directory Access Protocol), which is often described as a phone book for a network. LDAP has information regarding computers, services, and users on a network.

The Open Web Application Security Project (OWASP) described LDAP injection like this (see https://owasp.org/www-community/attacks/LDAP_Injection):

LDAP Injection is an attack used to exploit web based applications that construct LDAP statements based on user input. When an application fails to properly sanitize user input, it's possible to modify LDAP statements using a local proxy. This could result in the execution of arbitrary commands such as granting permissions to unauthorized queries, and content modification inside the LDAP tree. The same advanced exploitation techniques available in SQL Injection can be similarly applied in LDAP Injection.

The goal of LDAP injection is to go through the web application and attack the underlying network. If such an attack is successful, it can be quite devastating.

Command Injection

Command injection is a more generalized version of SQL injection in which specific commands are sent to be executed on the target system. OWASP defines command injection as follows (see https://owasp.org/www-community/attacks/Command_Injection):

Command injection is an attack in which the goal is execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell.

Web API

APIs (application programming interfaces) are commonly used in web applications. Whether an app is written in ASP.net, Java, PHP, or some other web programming language, use of web APIs is quite common. APIs present another attack surface that must be secured and tested.

Using robust authentication and authorization is the first step in securing an API. Access tokens are commonly used. A dynamic token is a token that is time based (i.e., it times out after a period), randomly generated, and used only once. The JSON web token is an example of a dynamic token.

Granular access control is another security measure. Access should not be all or nothing. Each user should be granted only the access required and no more. This is the fundamental security principle of least privileges. One way to accomplish this is to use ABAC (attribute-based access control). ABAC considers whether the username and password are correct and also examines the resource being accessed, the time of day, the location from which access is requested, and other similar features. For example, if a loan officer is accessing a loan application she is responsible for (resource) during normal business hours (time of day) from her normal office (location), then access is granted. However, if access is requested from an unknown location, during the middle of the night, to a file that is not the loan officer's, then even if the username and password are correct, access might be denied.

Webhook

An attacker can use a webhook to alter the behavior of a web page with custom callbacks. These callbacks are often maintained by third-party user/developers. Put more formally, webhooks are user-defined HTTP callbacks. If a web page uses webhooks, they must be secured. Fortunately, the security needed is similar to web API security. As with web API security, the fundamental issues with webhooks are proper authentication and authorization.

Another security measure is to use a signature in the HTTP header. The HTTP header is an essential part of any HTTP request. Using digitally signed requests can mitigate at least some webhook attacks. Another security measure is to encrypt the traffic with TLS—preferably mutually authenticated TLS.

OWASP Top 10

We have mentioned OWASP a few times in this chapter. Many of the attacks discussed in this chapter are included in the OWASP top 10. However, we have not yet simply listed the top 10. The top 10 list, directly from OWASP's website (https://owasp.org/www-project-top-ten/), is provided here. Note that the 2021 list just came out, and the CEH 11 still uses the 2017 list:

• A1:2017-Injection: Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

• A2:2017-Broken Authentication: Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users' identities temporarily or permanently.

• A3:2017-Sensitive Data Exposure: Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.

• A4:2017-XML External Entities (XXE): Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.

• A5:2017-Broken Access Control: Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users' accounts, view sensitive files, modify other users' data, change access rights, etc.

• A6:2017-Security Misconfiguration: Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.

• A7:2017-Cross-Site Scripting XSS: XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

• A8:2017-Insecure Deserialization: Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.

• A9:2017-Using Components with Known Vulnerabilities: Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

• A10:2017-Insufficient Logging & Monitoring: Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

Web Footprinting

The CEH curriculum suggests that you begin the process of attacking a web server or web application by using footprinting (also called reconnaissance). Some of the material in this section is similar to what was covered in Chapters 1, “Reconnaissance and Scanning,” and Chapter 2, “Enumeration and Vulnerability Scanning.” However, this section focuses on website footprinting.

Netcat

Netcat is a popular tool for sending and retrieving data. It can be used to try to grab HTTP information from a target web server in order to learn about that server. The basic process code looks like this:

nc -vv www.somewebsite.com 80 - press [Enter]
GET / HTTP/1.0 - Press [Enter] twice

If this command is successful, it returns information about the web server.

Netcraft

Netcraft (https://www.netcraft.com), as mentioned in Chapter 1, is a common tool for gathering information about a website. The Netcraft site previously allowed users to scan websites for free. It still has that function (it is about halfway down the first page), but now it also sells a wide range of cybersecurity services.

Banner Grabbing

Banner grabbing, as discussed in Chapter 1, is the process of attempting to grab a banner, usually from a web server, to learn about that server. Active banner grabbing techniques involve opening a TCP (or similar) connection between an origin host and a remote host. Passive banner grabbing involves trying to derive information from error messages, network traffic, web page extensions, and similar data. One simple way to try active banner grabbing is to use Telnet, like this:

Telnet 127.0.0.1 80
HEAD /HTTP/1.0 <enter><enter>

There are also several countermeasures to banner grabbing. Here are a few:

• If you are using Apache 2.x with the mod_headers module, use a directive in the httpd.conf file to change the banner information by entering Header set Server “New Server Name”.

• With Apache, change the ServerSignature line to ServerSignature Off in the httpd.conf file.

• Display false banners to mislead or deceive attackers.

• Use ServerMask (see http://www.port80software.com) tools to disable or change banner information.

• Turn off unnecessary services on the server to limit information disclosure.

Nmap

Nmap was discussed in Chapter 1. We don't describe it again here, but we do mention some web specific Nmap scans you can try, like these:

nmap -sV --script=http-enum targetIPaddress the -sV detects versions of software/services.
nmap targetIPaddress -p 80 --script = http-frontpage-login

You can save the output to a text file by using:

nmap -sV output.txt targetIPaddress

You can even do some attacks by using nmap. For example, a brute-force attack against a WordPress site could be done like this:

nmap -sV --script http-wordpress-brute --script-args 'userdb=users.txt,passdb=passwds.txt,http-
wordpress-brute.hostname=targetdomain.com, http-wordpress-brute.threads=3,brute.firstonly=true'
192.168.1.1

Default Credentials

Default credentials are a serious security vulnerability, and thus you must test for them. There are lots of websites that list default credentials. A few are listed here:

• Open Sez Me: https://open-sez.me

• Default Passwords: https://cirt.net/passwords

• xxx: https://datarecovery.com/rd/default-passwords/

Metasploit can also attempt default credentials on a website.

In addition to default credentials, default content and default functionality are also issues. For example, many website technologies install sample web pages and scripts. You can use tools like Nikto2 (https://cirt.net/Nikto2) and exploit databases like ExploitDB (https://www.exploit-db.com/) to identify default content.

Metasploit

While Metasploit has been mentioned previously in this book, the CEH exam particularly emphasizes the use of Metasploit for web servers and web applications. We therefore dive a bit more into that topic in this section.

Metasploit can basically be divided into four types of objects you will work with:

• Exploits: These are pieces of code that will attack a specific vulnerabilities. Put another way, exploits are vulnerability specific.

• Payload: This is the code you actually send to a target. It is what actually does the dirty work on that target machine after the exploit gets you in.

• Auxiliary: These modules provide some extra functionality, such as scanning.

• Encoders: Encoders embed exploits into other files, like PDF, AVI, and other files. You will learn more about encoders in Chapter 9, “Hacking Wireless.”

When you start Metasploit, you see something much like what is shown in Figure 8.7.

The process of using Metasploit really comes down to a basic five-step process:

1. Configure an active exploit.

2. Verify the exploit options.

3. Select a target.

4. Select a payload.

5. Launch the exploit.

A payload is what you deliver to a target. If it works, it establishes some communication channel between the target and your Metasploit machine. Auxiliary modules perform, as the name suggest, auxiliary functions. For example, scanning a system is done by an auxiliary module.

For example, to run an SMB scan (to find out if the target is a Windows server), you would use the following:

use scanner/smb/smb_version
set RHOSTS [targetipaddress]
set THREADS [1]
run

This is shown in Figure 8.8.

Let us say you discover that the target web server is indeed a Windows server. Then you look for Windows exploits, such as the following exploit, which is for a flaw in Windows Remote Desktop:

Use auxiliary/scanner/rdp/ms12_020_check
Set RHOSTS [YOURTARGETIP]
Set RPORT [3389]
Set THREADS [1]

If an exploit is successful, you will see something like what is shown in Figure 8.9.

Once you have a session, there are a number of things you can do with Metasploit. A few are listed here:

• sysinfo: This command shows you detailed information about the target system.

• webcam_list: This command lists all the webcams on the target machine.

• webcam_snap: This command actually takes a picture with the target's webcam.

• run post/windows/gather/enum_applications: This command enumerates all the applications on the target machine.

• run post/windows/gather/enum_logged_on_users: This command tells you who is currently logged on to the target machine.

These are just a few examples of Metasploit commands. The CEH exam does not test you in depth about Metasploit, so this book provides only an introduction.

What Next?

If you want more practice on this chapter's exam objectives before you move on, remember that you can access all of the Cram Quiz questions on the book web page. The next chapter covers hacking of wireless technologies.