Hubs.
Oleg Petukhov, lawyer in the field of international law and personal data protection, information security specialist security, protection of information and personal data.
Telegram channel: https://t.me/protectioninformation
Telegram Group: https://t.me/informationprotection1
Website: https://legascom.ru
Email: online@legascom.ru
#informationprotection #informationsecurity
Having reviewed the theoretical foundations of the OSI model levels in previous posts, let's now move on to considering those attacks that can be implemented against devices and applications running on each of the OSI levels.
Attacks on the physical level have been known for a long time, and it would seem that everyone knows how to deal with them, but sometimes with the help of such an attack you can get confidential information.
Let's start with the simplest network devices, hubs. As you know, when a hub receives a packet on one of its ports, it forwards it to all the others.
At the same time, all machines connected to this hub receive the sent packet. When using these devices, the bandwidth of a network segment is significantly reduced and, more importantly from the point of view of information security, any user connected to the hub can easily listen to all traffic passing through this segment.
In order to test this in practice, it is enough to connect several machines to the hub and run the boot disk and the Kali distribution described in the applications or any other distribution on one of them.
Linux, which contains this utility. Hereafter, all utilities listed in the examples are included in Kali Linux, unless otherwise specified explicitly.
After downloading the Kali Linux operating system, you must select one after the other: Privilege Escalation – Sniffers - Wireshark.
Next, in the application window that opens, you need to specify the interface from which the traffic will be intercepted, and click Start.
Well, now the most interesting part. We log in from a machine connected to the same hub as to a website that transmits credentials through a web form in unencrypted form, and enter a username and password (preferably fake). We send this data to the server and receive a message about incorrect credentials.
Then we go to the Wireshark window and view the HTTP traffic that was transmitted from the local machine to the web server.
In my example, I used the web portal of a well-known social network, which a few years ago did not use encryption when transferring credentials and transmitted the login and password in unencrypted form. In my case, the login was test, and the password was p@ssw0rd. In the log, the @ character is replaced with the UTF-8 hexadecimal code.
Of course, many websites use encryption when transmitting credentials, but nevertheless, by listening to traffic, an experienced hacker can gather a lot of useful information. For example, you can try to determine the operating system installed on the computer by using the servers that the computer accesses, up to the versions of the installed updates. You can also find out about the installed applications. Such attacks are called "passive fingerprint". The information obtained in this way can later be used by an attacker to carry out more complex attacks.
The above examples are proof of the unsuitability of hubs for use in local area networks. But don't rush to throw them away. If your network uses fault-tolerant clusters (the need for fault tolerance is discussed in detail in risk posts), then you can use hubs to connect cluster nodes internally. The fact is that the cluster nodes need to constantly exchange "I'm alive" messages, these messages are transmitted by the nodes to each other. Since the hub does not create CAM tables, but sends packets directly, in the event of a failure of one of the nodes, the second node learns faster about the failure of the second. Switches make up CAM tables that have a certain lifetime, and when one of the nodes fails, the second one learns about it only after this lifetime has expired. However, we'll talk more about switches later. For critical business applications such as email, a corporate database, or a website, a downtime of a few seconds is extremely harmful, and for a career as a system administrator, it is simply dangerous. So the use of hubs in cluster systems is quite justified. In order to avoid these threats, it is necessary to use switches, which will be discussed in the following posts.
It is no longer so easy to find a hub in a corporate network. They are being replaced by switches everywhere, and this is the best way to avoid the threats described above. If there are hubs on your network and you cannot currently opt out of them, you must use software tools to block users from listening to traffic. The easiest way to do this is to deprive users of administrative privileges on their workstations. You also need to prevent the network card from operating in a mode that allows you to receive all traffic, not just the one intended for this machine.
