In the Protocols and Servers lesson, we covered Telnet, HTTP, POP3, and more. Let’s see how they can be attacked and defended.
Let’s scan what we can learn today in our daily #FromZeroToHacker challenge.
| Table of contents |
| Introduction |
| What I have learnt today? |
| Stats |
| Resources |
Introduction to Protocols and Servers 2
In the Protocols and Servers lesson, we covered Telnet, HTTP, POP3, and more. But these can be easily attacked with Sniffing attacks, Man-in-the-Middle attacks, etc.
This is the eighth lesson of the Network Security module:
- Passive Reconnaissance
- Active Reconnaissance
- Nmap Live Host Discovery
- Nmap Basic Port Scans
- Nmap Advanced Port Scans
- Nmap Post Port Scans
- Protocols and Servers
- Protocols and Servers 2
- Network Security Challenge
What have I learnt today?
Introduction
Servers host lots of services that are accessible via their (open) ports. This makes them open too to attacks:
- Sniffing attack (Capturing packets from their network).
- Main-in-the-Middle (MITM) attack.
- Password attack.
- Vulnerabilities.
From a security perspective, we have what it is known as the Security triad: Confidentiality, Integrity, and Availability (CIA). Confidentiality refers to keeping the contents accessible to the intended parties, Integrity means that the data sent is accurate, consistent and complete when reaches its destination, and Availability refers to being available to access when we need it.
From a defensive point, we have to keep the CIA, but as attackers, we want to cause DAD (Disclosure, Alteration, and Destruction):
Every attack affects different areas: A network packet capture violates confidentiality, leading to the disclosure of information. A successful password attack leads to disclosure. Finally, a Man-in-the-Middle attack breaks the system’s integrity, altering the communicated data.
Vulnerabilities, on the other hand, have different impacts based on the type of vulnerability.
Now, it is time to focus on how a protocol can be upgraded or replaced to protect against Disclosure and Alteration.
Sniffing attack
When a protocol communicates in cleartext, the data can be captured and read easily. A simple network packet capture tool can reveal information, such as private messages, login credentials, etc.
A sniffing attack can be conducted using an Ethernet (802.3) network card with a program that let you capture network packets:
- Tcpdump is a free open-source command-line interface (CLI) program that has been ported to work on many OS.
- Wireshark is a free open-source graphical user interface (GUI) program available for several OS.
- Tshark is a CLI alternative to Wireshark.
Consider a user checking his email messages using POP3: With Tcpdump we can capture the username and password. Run it with sudo tcpdump port 110 -A. As POP3 uses port 110, we filter all our packets using port 110. To display the captured packets in ASCII format, we add -A.
If you read the packets, the first one displays USER frank, while the last one reveals the password: PASS D2xc9CgD.
We could also have used Wireshark to achieve the same results:
![[day_048_wireshark.png]]
No matter what tool we use: Any protocol using cleartext communication is susceptible to this attack. To get this information, we just need to have access to a system between two communicating systems.
We can fix this problem by adding an encryption layer on top of any network protocol. TLS (Transport Layer Security) has been added to HTTP, FTP, SMTP, POP3, IMAP and others. For remote access, Telnet has been replaced by a better version: SSH.
Man in the middle (MITM) attack
A Man-in-the-Middle (MITM) attack occurs when a victim (A) believes that they are communicating with a legitimate destination (B) but in reality, is communicating with an attacker (E).
This attack is simple to carry out if both parties don’t confirm the authenticity and integrity of each message.
Any time you browse over HTTP, you are susceptible to a MITM attack. MITM can also affect other cleartext protocols such as FTP, SMTP, and POP3.
We can mitigate this with proper authentication and encryption or signing of the exchanged messages. With the help of PKI (Public Key Infrastructure) and trusted root certificates, Transport Layer Security (TLS) protects from MITM attacks.
Transport Layer Security (TLS)
TLS is a standard solution to protect the confidentiality and integrity of the exchanged packets.
Introduced in 1994 and improved to its 3.0 version in 1996, SSL (Secure Sockets Layer) started along with the widespread of the Internet. But when more security was needed, TLS was born in 1999. Let’s explain how they fit the networking model.
The protocols we saw in yesterday’s lesson Protocols and Servers use cleartext, making it possible (and easy…) to capture the exchanged messages.
In the OSI model, we add encryption to our protocols in the presentation (6) layer. The data, then, will be presented in an encrypted format instead of cleartext.
Nowadays, TLS has replaced SSL. SSL is still used, and a lot, but modern servers favour TLS instead of SSL.
An existing protocol using cleartext can be upgraded to use encryption via SSL or TLS. We can upgrade HTTP, FTP, SMTP, POP3, IMAP, and more.
Basic HTTP retrieves a web page by establishing a TCP connection with the remote server, then requesting HTTP pages to the server using GET and POST requests.
HTTPS (HTTP using TLS) requires an additional step to encrypt the traffic. Between establishing a TCP connection and sending the HTTP requests, we need to establish a TLS or SSL connection:
Let’s explain this:
- The client sends a ClientHello to the server.
- The server responds with a ServerHello, indicating the selected connection parameters, and providing a certificate if server auth is required. It may also send additional information necessary to generate the master key.
- The client responds with a ClientKeyExchange, which contains additional information required to generate the master key.
- The server switches to use encryption and informs the client in the ChangeCipherSpec message.
It is more complex than this, but we only need to know that the client sends a message to the server, the server replies back providing a certificate and a way to generate a master key, the client generates and sends the master key, and the server switches to using encryption.
Once an SSL/TLS handshake has been established, HTTP requests now will be encrypted.
To be effective, SSL/TLS relies on public certificates signed by certificate authorities (third parties) trusted by our systems:
Here we can see to whom the certificate was issued, who did it and its validity period. Luckily we don’t need to do this, as our browser will do it for us for every site we visit.
Secure Shell (SSH)
Secure Shell (SSH) was created as an improved version of Telnet, to provide remote system administration in a secure way:
- You can confirm the identity of the remote server.
- Exchanged messages are encrypted and only can be decrypted by the intended recipient.
- Both sides can detect any modification in the messages.
All these three points are ensured by cryptography.
To use SSH, we need an SSH server and an SSH client. The SSH server listens on port 22 by default, while an SSH client can authenticate using:
- A username and a password.
- A private and public key.
By using the ssh <USERNAME>@<TARGET_IP>, we connect to <TARGET_IP> with the username <USERNAME>. Then, the SSH server will ask us to provide a password. Once authenticated, the users has access to the target’s server terminal:
![[day_048_ssh.png]]
The username and password are encrypted, and also all commands we execute on the remote system.
If this is the first time we connect to the system, we need to confirm the fingerprint of the SSH server’s public key to avoid a Man-in-the-Middle (MITM) attack:
We can use SSH to transfer files through SCP (Secure Copy Protocol): scp <USERNAME>@<TARGET_IP>:<FILE_NAME_WITH_ROUTE> ~. This will copy the file (for example, /home/root/myfile.txt) to ~, the root of the home directory of the user logged in.
We can also copy files in our computer to the SSH server with scp <FILENAME> <USERNAME>@<TARGET_IP>:<DIRECTORY>.
Password Attack
Many services and protocols require you to authenticate with a username and a password, to prove your identity.
But we can use attacks against passwords by:
- Password guessing: Guessing a password requires some knowledge of the target, such as their name and surname, birth year, etc.
- Dictionary attack: We use the passwords in a dictionary or wordlist.
- Brute force attack: This attack is slow and long, as we will try all the possible character combinations.
For dictionary attacks, hackers have compiled a list of leaked passwords from data breaches. One example is the Rockyou.txt, a list of the most common passwords.
THC Hydra automates the process of trying passwords and supports many protocols including POP3, IMAP, FTP, SSH, etc. Its syntax is hydra -l <USERNAME> -P <WORDLIST> <TARGET_IP> <SERVICE>.
For example, if we want to learn mark’s password on SSH: hydra -l mark -P /usr/share/wordlists/rockyou.txt 10.10.10.10 ssh.
It also supports options with extra arguments:
-s <TARGET_PORT>to specify a non-default port for a service.-Vor-vVfor verbose.-t <NUMBER>to use extra threads.-dfor debugging.
Mitigation against such attacks includes:
- Password policy: Enforces a minimum complexity and length.
- Account lockout: Locks the account after a certain number of login attempts.
- Throttling authentication attempts: You can only make a login attempt after a few (or not) seconds.
- Using CAPTCHA: Requires solving a question difficult (in theory) for machines.
- Requiring the use of a public certificate for authentication: Good for SSH.
- Two-Factor authentication.
- More sophisticated approaches like IP-based geolocation.
Summary
In this lesson we have covered various protocols, their usage, how they work under the hood and three common attacks:
- Sniffing attack
- MITM attack
- Password attack
And on each one, what steps do we have to take to mitigate them, from a defense perspective.
Stats
From 92.128th to 90.899th. Now in the top 4%!
Here is also the Skill Matrix:
Resources
Module: Network Security
TryHackMe: Protocols and Servers 2
