In a wireless network, when two parties are communicating with each other over plain text protocols, it is easy for a third party to intercept the traffic, extract useful information, or manipulate the communication. To reduce the possibility of an attacker sniffing on the wireless network, network-based encryption mechanisms, such as WPA or WPA2, are used. If the attacker has been able to derive the wireless network password, as demonstrated in previous chapters, they can still extract the data exchanged between two endpoints.
As a secondary form of security, many applications use additional encryption protocols, such as SSL or TLS. When using TLS, two clients set up an encrypted tunnel and securely pass the data through the tunnel rather than passing the data unencrypted. This does not prevent the attacker from sniffing the network, but capturing encrypted traffic without knowing the encryption key is generally pointless. The private encryption key resides on endpoints and is not transferred over the wire (or a wireless network). In this section, we will perform some basic attack on SSL and attempt to harvest credentials from the victim. SSLstrip does not break the underlying SSL/TLS encryption, nor does it try to take advantage of vulnerabilities in the protocol, such as Heartbleed. When configured on the local machine, it simply listens on an interface and starts degrading the use of HTTPS. Whenever the victim tries to set up an HTTPS connection, SSLstrip will attempt to get in the middle of this conversation and present the data to and from the client in HTTP, which is unencrypted, while handling the encryption with the destination server.
In this section, use our position as the MITM to provide Internet connectivity to clients connecting through our evil twin access point. All the web traffic from clients will be redirected to port 10000 on the local machine, where SSLstrip will be running; SSLstrip will accept this web traffic from clients and degrade HTTPS connections back to HTTP. Since HTTP is sent in clear text, the attacker is able to see the data flowing to and from the client and extract the useful information that should otherwise be sent over an encrypted tunnel.
Before we proceed further, we will need to modify the configuration of iptables on our local machine to forward the traffic from port 80 to 10000. SSLstrip will be configured to listen on port 10000, where it will be waiting for web traffic sent from clients to traverse our AP. It will automatically handle the traffic manipulation, presenting the data to our attacker's machine in the clear text.
Follow these steps to set up SSLstrip prior to executing the attack:
- Forward all traffic from port
80to port10000using the followingiptablescommand:#iptables –t nat –A PREROUTING –p tcp --destination-port 80 –j REDIRECT --to port 10000
- Move to the directory where SSLstrip is located. On Kali, SSLstrip resides in the
/usr/share/sslstrip/directory by default. - Run
sslstrip.pywith the–woption. The–woption specifies the log file:#python sslstrip.py –w /root/Desktop/ssllogfileWhen the victim attempts to access http://google.com, the initial connection is seen by the MITM. The HTTP connection on port
80is then redirected to port10000where SSLstrip is listening. All the web communication is now controlled by SSLstrip tool, where it listens for and strips the HTTPS connection data and falls back to HTTP when communicating with the client. The victim will get a response from the web server but observe that it is not encrypted. The reply is sent back using HTTP, which is a plain text protocol. Now, when the victim clicks on any other links that would normally utilize HTTPS, such as Gmail, the connections will be established without encryption instead.
SSLstrip disables the HTTPS connection data and forces the communication to be done over HTTP. This attack can be very effective even against fully patched victim machines. The attacker can also capture the data traffic passively and extract useful information that can further the efforts of the penetration test.
In the preceding example, the user is able to access Gmail and is prompted to log in as they normally would; however, they would do that over HTTP. If they were not looking to ensure that the connection was encrypted, they would readily provide their username and password. This would enable the attacker to capture these credentials for this session or any other session that would normally be encrypted. This is a very dangerous attack, where the chance of detection are very low.
- In the attacker machine, open the log file created in the previous step and check whether the user credentials are stored in clear plain text.
