In the previous chapter, we learned about a very important network protocol, the DNS protocol. We looked into its in-depth architecture, how it works, various loopholes and misconfigurations, and how an attacker use those loopholes to exploit and compromise the important assets of any organization. So, in this chapter, we will look into more advanced attacks against some of the very important assets of any organization: web applications, email services, and servers.
Web applications and email services are the most important components of any organization because any attacker, at first, will only attack the web applications and try to compromise the internal machines by sending phishing emails or exploiting various email gateway misconfigurations, such as open relays. We will see these attacks in practice in the latter part of this chapter.
This chapter starts with an in-depth explanation of a web protocol’s behavior and analysis, web and email gateway loopholes, and the countermeasures and defenses against those attacks.
In this chapter, we will cover the following main topics:
In this section, we talk about various web protocols, such as HTTP and HTTP2, what the difference is between HTTP and HTTP2, the architecture, and various functional and security issues in both protocols.
HTTP or HyperText Transfer Protocol is used to exchange data between a client and a server in the form of HyperText Markup language (HTML) documents. These documents include images, text, video files, and flash files. HTTP works on the top of all the network layers and is known as the Application Layer, and it is used to transfer all data between the connecting networking devices.
HTTP was introduced back in the late 1980s and early 1990s, but with modifications, the final version of HTTP/1.1 was submitted in 1997, which is still the standardized version of the HTTP protocol. To learn more about the history and developments of HTTP, there is an interesting blog written by the Mozilla team; please follow this link to learn more: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP.
The typical HTTP client-server architecture protocol resembles the following diagram:
Figure 14.1 depicts the following client-server architecture along with various components:
We have introduced the term proxy server; let’s learn about it.
Proxy servers are defined as one of the key components in handling many functions and are present between a client and web servers. These proxy servers can be one computer or many computers and machines that are relaying HTTP messages from one end to the other. The various functions performed by the proxies are listed as follows:
Now that we have learned about HTTP client-server architecture, let’s look at what an HTTP request consists of.
Each HTTP request passed across the internet carries a huge chunk of encoded data that typically contains the following:
So, let’s understand this whole HTTP request in real time:
As shown in Figure 14.2, the website is called and is loaded on the browser. But what happened in the backend is not known. So, let’s understand and analyze this.
Important Note
Now, to analyze this HTTP request-response handshake, we need an interceptor to intercept the request and the response. This can be solved with multiple tools, such as OWASP ZAP and Burp Suite. For this course, we will be using Burp Suite.
Let’s analyze the intercepted HTTP request and response shown in Figure 14.3 in the following table:
HTTP parameters |
Request |
Response |
HTTP method |
GET |
200 OK |
HTTP version |
HTTP/1.1 |
HTTP/1.1 |
HTTP header |
From line no. 1 to line no. 11 is a complete request header. |
From line no. 1 to line no.13 is a complete response header. |
HTTP body |
From line no. 16 to the end is the complete response body. |
Now from the preceding table, there is a new value introduced, 200 OK. This is an HTTP response code. So, let’s understand and look at some other HTTP standard response codes:
For more information on HTTP status codes, please follow this link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status.
For a complete list of HTTP methods, please follow this link: https://www.iana.org/assignments/http-methods/http-methods.xhtml.
So, now that we have learned about HTTP in depth, let’s understand the basic difference between the various HTTP versions.
Several decades ago, HTTP/1.1 was discovered to be one of the most prominent technologies to interact with web pages. But with time, technologies evolved and web pages became very complex, with the addition of automated scripts, flash files, images, videos, GIFs, and so on. This meant a huge volume of data transmission on the HTTP channel, increasing the complexity and overhead of HTTP/1.1.
Hence, in the early 2010s, Google came up with a solution by introducing a new protocol, SPDY (pronounced as Speedy). The main goal of this protocol was to solve the problem of duplicate data transmission, decreasing the time a server took to respond by handling heavy traffic loads and Round-Trip Time (RTT). So, this emerging protocol set the benchmark for the evolution of HTTP/2.
So, let’s understand how HTTP/2 is different from HTTP/1.1:
These are the major implementations introduced in the HTTP/2 protocol to solve the problem of heavy traffic load on servers and slow data transmission over slow TCP connections. To learn more on HTTP/2, please follow this link: https://datatracker.ietf.org/doc/html/rfc7540.
Now we have learned about HTTP, and also understand how HTTP/2 evolved and differs from HTTP/1.1, let’s move on to another class of HTTP – HTTPS.
Now, the major problem with the HTTP protocol is that the data transmission is completely unencrypted, which means an attacker can steal, alter, or view the ongoing traffic between the client and the server. To capture, there are many tools available, such as Wireshark, Fiddler, HTTPView, and Network Analyzer. But for the best view, Wireshark is much more compatible and user-friendly to use, so we will also be using that for our testing. Let’s demonstrate HTTP’s weakness using Wireshark:
As shown in Figure 14.4, Wireshark captured the unencrypted login request transmitted via an unsecured HTTP channel.
To prevent this, another layer of security was added by introducing the Transport Layer Security (TLS), formerly known as the Secure Socket Layer (SSL). So, let’s understand this with a practical demonstration:
Now, as shown in Figure 14.5, TLS security is enabled, and immediately, the URL changes from HTTP to HTTPS. So, let’s analyze the request and response pattern, as shown in the following screenshot:
Now, as shown in Figure 14.6, all the requests and responses are transmitted via an encrypted HTTPS channel, implemented over TLSv1.2. But what exactly is happening at the backend? How is this data getting encrypted? How is the handshake done? Let’s understand this step by step.
HTTPS is an encrypted form of the HTTP protocol that prohibits websites from transmitting data in an unencrypted format. Hence, it protects data from being viewed, stolen, or altered by an eavesdropper, especially in public networks, such as open and free Wi-Fi at Starbucks or airports. It works like this:
HTTPS contains a secure certificate known as an SSL or TLS certificate that indicates that a website is legitimate and secure to visit. This certificate provides an extra layer of security by encrypting sensitive and confidential data such as credit/debit card numbers, passwords, PINs, and OTPs. TLS certificates encrypt communication by using the public-private key infrastructure, which uses the following two different types of keys for encrypting and decrypting the communication between client and server:
So, now we understand the basics of HTTPS formation, let’s now understand how certificates get exchanged between client and server. This is shown in the following screenshot:
As shown in Figure 14.8, the following are a series of requests and responses negotiated between client and server to secure communication, but we will only focus on certificate exchange secure message packets:
After receiving the public key, the client will first verify the key and the certificate against the list of the trusted Certification Authorities (CAs). Once the public key is verified, the client will store the public key and use it to encrypt the data.
So, now we understand the HTTPS handshake, let’s demonstrate with a practical demonstration using Wireshark to exchange communication from a client’s browser and Google’s server, as shown in the following screenshot:
So, as shown in Figure 14.9, after exchanging all the messages, and agreeing on the protocol version and ChangeCipherSpec, the encrypted data is exchanged over the HTTPS channel. Here, we expect you to open every message from Wireshark and look into the in-depth packet analysis.
Now that we have learned about TLS protocol behavior and practical analysis in depth, let’s build our penetration testing lab to exploit web vulnerabilities.
TTP stands for Tactics, Techniques, and Procedures that analyze the behavior of a target, prepare a plan to identify the weaknesses and loopholes in an application, and secure against those attacks.
There are numerous tools and scripts available to perform vulnerability testing. Some of these tools you have to pay for, but most of them are free to use. Paid tools also have some features available to use for free. Let’s look at some of the tools:
As you can see, there are numerous tools available out there on the internet, and it would be difficult for us to demonstrate each tool. So, throughout this chapter, we will be using the tools and scanners that are important and should be present in the toolkit.
So, let’s take Burp Suite as an example to learn its important features and demonstrate vulnerability scanning, while we will begin penetration testing on the Mutillidae platform. But please feel free to use other scripts and scanners available on the internet as well:
As shown in Figure 14.10, let’s understand the sections of the Burp Suite intercepting screen, as follows:
So, to begin vulnerability scanning, we need to follow the following steps:
Now, as we have intercepted the target request, let’s perform vulnerability scanning.
Now, as shown in Figure 14.12, active scanning on the target login requests has been chosen and started.
As shown in Figure 14.13, many vulnerabilities have been identified, and these are categorized under the Open Web Application Security Project (OWASP) top 10 vulnerabilities category. A few of the vulnerabilities we will discuss in the next section, but we expect you to learn and practice each vulnerability using Mutillidae. To learn about the complete list of OWASP categories, please follow the following link: https://owasp.org/www-project-top-ten/.
Now, similarly there are other features in Burp Suite, and it would be very difficult to go through every feature, so we expect you to take a pause here and read about the other features of Burp Suite at the following link: https://portswigger.net/burp/documentation/desktop/tutorials.
Similar to Burp Suite, there are other vulnerability scanners available free to use; please feel free to explore those as well. Throughout this chapter, we will be using Burp Suite most of the time. Now, let’s move on to another section on exploiting some of the vulnerabilities.
In the previous section, we learned how we can perform web vulnerability scanning; let’s now focus on how we exploit common vulnerabilities and compromise web servers, web applications, databases, user sessions, and so on.
SQL injection is a common and important web application vulnerability that allows an attacker to interact with a backend database through SQL queries. These SQL queries are used to retrieve user data in form of rows and columns.
So, let’s demonstrate how we can compromise a login page via SQL injection:
Now, as shown in Figure 14.14, the SQL login query is entered in the username and password field.
Now, as shown in Figure 14.15, the SQL injection query is accepted, and the attacker was able to retrieve the data. But how does this happen? What caused this query to exploit the login request to log in to the web application?
So, before jumping into the exploitation logic details, let’s first understand how login works.
Whenever a user enters a username and password, the request is submitted at the server end, and it checks the username and password (in hash format) present in the database. If the credentials are correct, the user will log in, and if the credentials are not correct, the web application will throw a logic error. This looks like this at the backend:
SELECT username, password from USERS where username = '<username>' and password = '<password>';
Let’s now insert our injection into the preceding query:
SELECT username, password from USERS where username = '1'or'1'='1' and password = '1'or'1'='1';
Now, if you closely look at the preceding query, the username field, 1, is balanced with the second quote and the second query is '1'='1' means if the username = '1' is not true then validate if '1'='1' is TRUE and 1=1 is always true. So, this means the validation at the server end is not validating the credentials properly, and hence, the attacker was able to log in and retrieve data from the database.
Now, there are different types of SQL injections such as error-based, double query, blind SQL time-based, and Boolean=based. Please make sure to go through each SQL injection from the following link and practice on freely available platforms such as Mutillidae: https://portswigger.net/web-security/sql-injection.
Now that we have learned about SQL injection, let’s look to other types of important injection-based attacks.
Remote Code Execution, or RCE for short, is one of the most dangerous vulnerabilities of all time because it allows an attacker to execute remote system commands. The impact of this attack is so drastic that an attacker can gain full control of a machine via malware execution to exfiltrate confidential data and, by doing lateral movement, compromise other machines and full domain. Let’s understand this with a simple demonstration:
As shown in Figure 14.16, the message test is echoed back to the screen. Let’s run the system commands.
As shown in Figure 14.17, the passwd file contents are displayed. Let’s move one step further to compromise the machine.
As shown in Figure 14.18, an attacker can control the remote machine. So, now that we understand some of the injection-based web application attacks, let’s look into scripting-based attacks, which are used to compromise a web application and its users as well.
XSS is a client-side attack in which an attacker injects malicious scripts into the trusted code of web applications and binds them into a malicious link. Once the victim visits that web application or clicks on that link, the malicious code gets executed in the victim’s system if proper sanitization by the web application has not been done properly.
An XSS attack usually happens when there is some message being displayed on a screen. For example, if there is a search message box and a user types in Test, the results for the test will be displayed back on the screen, but if you look closely, you will see that the Test keyword will remain stored in the source code of the application, as shown in the following screenshot:
Now, as shown in Figure 14.19, what if an attacker replaces the Test keyword with some malicious script? Let’s understand this with XSS classifications:
There are three types of XSS attacks:
Enter the <script>alert("XSS");</script> malicious script and click on the message button. Immediately, a popup will be shown on the client-side browser end, as shown in the following screenshot:
As shown in Figure 14.20, the XSS message was displayed on the screen. Let’s now understand another type of XSS, which is very dangerous and can cause a lot of damage if executed.
For example, let’s say there is a username field and no proper input validation or sanitization in place at the web application end. An attacker would inject the malicious script, and once the victim visits that page to update any value and clicks on the update or open button, immediately the malicious script would be executed on the victim’s system. This type of XSS proves to be dangerous, as they often remain hidden in the form fields. Let’s understand this with a demonstration:
As shown in Figure 14.21, there is a hidden entry on line number 2.
As shown in Figure 14.22, once any user visits the page and tries to update the fields, the hidden malicious script will be executed on the client’s machine. Finally, there is another type of XSS, known as the Document Object Model (DOM) XSS.
As shown in Figure 14.23, the Key=test value is stored and reflected on the screen. Let’s look at the JavaScript code to understand the logic behind the DOM storage.
As shown in Figure 14.24, the pMessage parameter stores the value in the Message span of the innerHTML, and innerHTML doesn’t sanitize the storage and, hence, is vulnerable to the DOM XSS.
As shown in Figure 14.25, there is a different type of XSS script that is injected into the web page unlike with the <script> tags. There are plenty of available XSS scripts on the internet to bypass various filters in code, or Web Application Firewalls (WAFs). Please feel free to use those scripts as well.
So, now that we understand the XSS, let’s now look at a very interesting attack that is not so common in web applications but is an important entry on the penetration testing checklist.
A buffer is known as temporary storage that holds data while it is being released from a store and transfers it to another location. Now, if an attacker could control that buffer space, they could easily inject malicious code to perform arbitrary command injections or crash a backend server.
Buffer overflow is known to be a very dangerous vulnerability, as it could crash a whole backend infrastructure. Hence, in real-time production environments, penetration testers avoid the buffer overflow attack.
This vulnerability generally occurs in applications, but some of the examples can also be considered for web applications. For example, in a username field where only six characters are allowed, an attacker could inject a huge number of characters, leading to the web server crashing.
Let’s understand this with the help of an example:
As shown in Figure 14.26, the this is buffer overflow test string is displayed 10 times. Now, if we were to enter a huge value of, say, 10,000,000 times, the backend server would not be able to process this much data, and hence, the server will crash if input validation and sanitization are not done properly.
As shown in Figure 14.27, the server is not able to process this many requests and, hence, crashes.
So, now that we have learned the basics of buffer overflow, let’s move to another class of web application attack that is not directly involved in compromising a backend infrastructure but compromises or hijacks end user accounts.
Session hijacking is a well-known attack in which an attacker compromises a user’s account by compromising their session. This can be achieved in multiple ways, but the prominent methods are brute force, cookie injections, network sniffing, and reverse engineering. So, let’s first understand what sessions are all about?
Now, we know that HTTP is a stateless protocol, which means once a whole end-to-end transaction finishes, the connection between a user’s machine and a server is also lost, and the user has to request another transaction again. So, to keep track of the end user’s activity, application developers came up with a new technology to keep session records so that the user doesn’t have to request multiple sessions for the same or new transactions.
These session records are known as cookies and are stored on a client’s machine. These types of cookies are called persistent-based cookies.
But with time, attacks on cookies also evolved, so developers came with up another brilliant idea from a security perspective to store cookies for a limited period, and these are called session-based cookies or non-persistent cookies. But with time, attacks on non-persistent cookies also evolved.
So, let’s understand what cookies look like. This is shown in the following screenshot:
As shown in Figure 14.28, once a user is successfully authenticated, the web server assigns a cookie for the user to traverse through the application without getting logged out.
So, now that we understand what sessions are all about, let’s look at some of the session-based attacks.
Now, we learned about XSS in the XSS section, so we will directly jump into cookie stealing:
Script - <script>alert(document.cookie);</script>
This is shown in the following screenshot:
As shown in Figure 14.29, a cookie-stealing JavaScript code is injected into the DNS search bar.
As shown in Figure 14.30, once the victim clicks on the crafted payload, the attacker will be able to compromise the victim’s cookies to authenticate their account. So, now that we have learned about session hijacking via XSS, let’s look at another session hijacking attack.
Cookie tampering is an attack in which an attacker in a response header manipulates the cookie parameter of an authenticated user to compromise higher-privileged accounts:
As shown in Figure 14.31, the test user is logged in. Let’s intercept the request using Burp Suite and understand the cookie formation.
As shown in Figure 14.32, PHPSESSID and uid=29, two parameters as cookies, are set to the test user. But it’s important to understand which cookie parameter is being set for the user to authenticate.
As shown in Figure 14.33, the uid=29 parameter is only set as a cookie. So, let’s manipulate other parameters to check whether we can authenticate as some other user or not.
As shown in Figure 14.34, the user authentication uid cookie is manipulated to 1.
As shown in Figure 14.35, we are authenticated as the admin user.
Now, although we have learned about the major session-based attacks, it would be very difficult for us to demonstrate all possible attacks here. We expect you to practice other session attacks, such as brute force and session fixation. Let’s move on to another section and learn about email service loopholes.
Email, short for electronic mail, is used to send and receive messages in electronic form. To send or receive emails, there are three main protocols:
All of these protocols are used to send and receive emails, but all of them are different from each other. So, let’s understand the key differences between these three email protocols:
So, let’s combine all three email protocols and understand how they work in real time:
As shown in Figure 14.36, all these protocols work together to send and receive emails. So, now that we understand the basics of email protocols, let’s now look at the weaknesses of email protocols.
Important Note
For this chapter, we will perform penetration testing on the SMTP protocol, but the same methodology can be performed on the other two protocols as well. We expect you to practice those in your inbuilt lab.
As time passes, security researchers always come up with new techniques almost every day to exploit Mail Exchange (MX) servers. So, let’s understand the different ways to exploit SMTP.
Using the NMAP utility, let’s perform a vulnerability scan of the remotely installed SMTP server on port 25. This is shown in the following screenshot:
As shown in Figure 14.37, from the fingerprint strings, a lot of information about the SMTP server, such as the open Oracle-TNS connection and JAVA-RMI, is available to be exploited remotely. This chapter focuses only on SMTP, but please feel free to explore these as well.
The fingerprint strings also reveal some of the commands, such as HELLO and HELP, but the SMTP server is not vulnerable to Exim exploits.
The SMTP server has default users configured as well. Also, it supports open relay, which makes it easy to attack any internal organization user by sending phishing emails from any other user with the same or an open domain.
So, let’s exploit this by sending phishing emails to a locally configured user, as shown in the following screenshot:
As shown in Figure 14.38, an attacker crafted a fake email to send it to another user. Now, what if an attacker sends a crafted reverse tcp connection payload or creates a Command and Control Center (C2C) from the victim’s outlook to their external server to read emails or compromise the victim’s machine as well? We will leave this to you to explore further.
Another major drawback of using SMTP with default configurations is that any attacker, by sniffing in an internal network, can eavesdrop on ongoing configurations, as shown in the following screenshot:
As shown in Figure 14.39, an attacker sitting inside an organization can easily sniff a cleartext SMTP ongoing conversation. So, now that we have learned some of the attacks on the SMTP protocol, let’s look at some of the attacks on email gateways during red-team operations.
Phishing is a very well-known and common attack these days. Phishing involves an attacker sending a fake email that contains malicious links that redirect to external pages, such as fake Amazon or Facebook pages, or malicious office files, such as Word, PDF, and Excel files.
Nowadays, these payloads are very common and are known to security professionals, but there is another type of malicious payload, which is crafted as HTML and used to compromise the New Technology LAN Manager (NTLM) hashes of domain users.
This phishing attack is very useful, as a victim doesn’t even have to open the email; just a single click on it is enough. When the victim closes Outlook and reopens it, the attacker would be able to compromise the NTLM hashes. This can also be achievable by crafting a payload inside an Excel, Word, or PDF file, as we will demonstrate:
As shown in Figure 14.40, an attacker crafted an HTML payload. Let’s send this HTML content to the victim.
As shown in Figure 14.41, once the victim clicks on the email, Outlook will immediately start connecting to the attacker’s server to access the requested file.
As shown in Figure 14.42, WPAD was enabled, and hence the victim’s autosaved credentials were immediately captured at the attacker’s end. This attack is very useful during red team operations, especially for compromising domain admin hashes or credentials.
Important Note
Although we have learned about various attacks on email protocols, gateways, and so on, there are more advanced attacks available that attackers usually use to compromise email gateways, such as sending malware, email exchange injections, and account takeovers, which are not covered in this chapter. However, we expect you to practice those as well.
Let’s now look at some simple steps to protect our web and email services.
To protect web applications and email services from attackers, the following countermeasures can be adopted:
In this chapter, we have learned about web application communication protocols such as HTTP and HTTP2. We also looked into the security issues caused by HTTP and resolved them by introducing the SSL/TLS certificate embedded in the HTTP, and we came up with a new secured protocol, HTTPS. We also learned about various web application attacks, such as SQL injection, XSS, session hijacking, and buffer overflow, with practical examples. Another service we looked at was email and its corresponding protocols, vulnerabilities, and gateway attacks.
In the next chapter, we will look into more advanced topics such as enterprise security protocols, including LDAP and SMB, their operations, their usage, and their corresponding attacks. We will also look into SQL server attacks, which can leverage an attacker to compromise even a domain admin.