Write-up to MitM #
HTTP / HTTPS Security #
Task #
A reverse proxy is to be set up that stands in front of an arbitrary external website. The security implications are then to be tested.
HTTP / HTTPS Security #
Basically, browsers nowadays report when credentials are entered on websites that have been transported via HTTP. In addition, browsers nowadays report when the SSL/TLS certificate does not match the domain or is invalid for other reasons.
There are other security measures such as Secure Cookies, HSTS and HTTP Public Key Pinning.
Possible attacks as MitM #
The first tool that could be tried is DNS spoofing. This is because the DNS cache is spoofed by the victim so that the domain points to a server controlled by MitM.
Following this, a reverse proxy still needs to be set up to return something to the victim, which is to be phished.
The question remains whether the reverse proxy should deliver HTTP or HTTPS? For this it is necessary to differentiate whether the victim is visiting the website for the first time. The reverse proxy could deliver HTTPS, but it would most likely lead to certificate errors for the victim. One advantage of HTTPS is that secure cookies are transmitted. HTTPS is also necessary if the visitor was not on the site for the first time and the original server had HSTS enabled. HTTP has the advantage that the victim does not see a certificate warning, but the page may not load because of HSTS. In addition, if a login is necessary, a warning is then displayed to the victim that he is on an insecure website. With HTTP public key pinning you have lost, but you can use a “similar” domain for a phishing attack.
Concrete attack #
- Setup of a reverse proxy that listens to HTTP / HTTPS
- Configuration of the reverse proxy with forwarding to a legitimate website
- Rewriting the response from the legitimate website during the attack
- Find victim with DNS spoofing or by mail.
SSH Security #
Assignment #
To learn what a Man in the Middle (MitM) is and how it can be prevented.
Structure of the task #
The victim connects to the MitM (on port 10022) and it in turn connects to the Openssh server (on port 22).
docker
+-------------------------------------------------------------+
| |
| |
| +-----------+ +---------------+ |
| port 10022 | | port 22 | | |
| | ssh proxy | | alpine | |
+-------------->+ +-------------+ openssh | |
| | | | server | |
| +-----------+ +---------------+ |
| |
| |
+-------------------------------------------------------------+
SSH connection #
SSH connection is basically encrypted and this is implemented in 3 steps:
- Client connects to the server
- Server gives client its public key (RSA, ECDSA etc.)
- Client negotiates a secure transport channel with the server (e.g. via AES)
Only then does the client have to authenticate itself (mutual authentication). In the exercise it was done first with a password, then with a certificate. If you want to authenticate as a client with a certificate, the server must have the client’s public key.
When connecting to the server for the first time, the user gets from his software the fingerprint of the server certificate (public key). This can be compared with the certificate stored in the server. If he does not do this, the client runs the risk of connecting to the wrong server.
Possible attacks as MitM #
Due to the asymmetric encryption, a MitM attack is not possible because the private key does not leave the client. This is because in a successful MitM attack, the MitM authenticates itself with credentials of the client. However, with password authentication, a MitM attack is possible if the client does not compare the fingerprint.
By the way, a 2FA auth would not prevent the attack either, since the MitM receives the HOTP or TOTP from the client. To understand what 2FA is for, a threat model needs to be created. To prevent a MitM attack, the server and the client must know something that the MitM does not know. So Certificates. Assuming the password is stolen, the SSH agent is forwarded, PC is not locked. How to protect against these dangers? One uses a second factor. This does not help against MitM, session hijacking or infected clients.
Bettercap #
Task #
A network is to be set up with a Windows VM, a web server and a man in the middle. Then Arp spoofing, dns spoofing and ssl splitting are to be applied with bettercap.
Arp spoofing #
Refers to sending spoofed ARP packets.
To eavesdrop on traffic between two hosts A and B, the attacker (host C) sends host A a spoofed ARP message to assign a specific IP address. This message contains MAC address is included in this message, so that in the future Host A sends packets to Host C instead of Host B. Host B. The same happens with host B. Host C now has to forward the packets from A and B, but it can but can read them. The attacker works unnoticed as a proxy, i.e. as a man-in-the-middle.
The attack takes place on Layer 2 and can be mitigated with a Layer 2 firewall. A program is for example arptables (Layer 2 version of iptables)
DNS Spoofing #
DNS is used to translate a domain to an IP address. Similar to arp Spoofing, DNS is used to translate domain name to IP address (for ARP IP address to MAC). The goal is to make the victim connect to a fake IP address.
DNS spoofing can have different starting points:
- On the client - e.g. virus manipulates host file.
- On the router - e.g. enter another DNS server in the router - routers often have default passwords.
- On the connection - e.g. in the cloud
- On the DNS server - e.g. with compromised DNS servers
SSL Splitting #
SSL/TLS is a point-to-point encryption e.g. between client and web server. Sometimes it is sometimes it makes sense to introduce proxy etc. in order to reduce the load on the application server. The client then establishes an SSL/TLS connection to the proxy and the proxy establishes a connection to the application server. Thus, one SSL connection becomes two. However, these are completely different connections with different encryption keys.
Man in the Middle attacks usually want to read the SSL/TLS traffic as well. Therefore, one inserts man in the middle and split the SSL/TLS connection. This looks like this:
Client <-SSL/TLS Verbindung 1-> Attacker <-SSL/TLS Verbindung 2-> Server
Questions #
- Why could bettercap record the ftp credentials?
- The connection is not encrypted. Therefore, a man in the middle can read the connection.
- What are caplets in bettercap?
- These are scripts that automate the inputs in the interactive session. The http-ui cap for example sets listening address/port, sets username/password and then starts the API and the web server