Wi-Fi networks: penetration and protection. 3) WPA. OpenCL / CUDA. Pick statistics
In the previous part, we examined in detail the “cheat” methods of circumventing “protection” (hiding SSID, MAC filtering) and protection (WPS) of wireless networks. And although it works in half the cases, and sometimes more often, once the games end and you have to take on heavy artillery. It is here between your personal life and the hacker that’s the weakest link: the password from the WPA network.
')
The article will show the interception of the client-access handshake, the search of passwords using both the CPU and the GP, and in addition, summary statistics on speeds on ordinary single systems, EC2 clusters and data on various types of modern GPUs. Almost all of them are supported by my own experiences.
By the end of the article, you will understand why a lazy 20-digit password from az letters is more resistant to a pair of suns than a furious 8-digit, even using all 256 range values .
Table of contents:
1) materiel
2) Kali. Hiding SSID. MAC filtering. WPS
3) WPA. OpenCL / CUDA. Pick statistics
PMK, PTK, RPG
As always, let's start with the theory. Strictly speaking, we do not need it to pick up passwords, and who are too lazy - they can skip this section to practice . However, in my opinion, knowing how client authentication and data encryption occur is very useful and will explain all the difficulties that we, as an attacker, experience when trying to hack this protocol. A more detailed description in plain English with analysis of the formats of all authorization packages can be found here .
WPA and WPA2 (the first is based on the IEEE draft, the second on the final version, but in our case, both can be considered synonymous) use a rather clever key exchange scheme. Rather, their nemena . As we remember in the first part , the weakest point in any protection is the transfer of keys, even encrypted ones - after all, a hacker can intercept these values and try to select the initial key using them in offline mode, that is, in no way communicating with the access point or client. . WPA developers have eliminated any exchange of encrypted and open passwords. How it all works will be described below.
Let's start from the end. Suppose we want to send an encrypted data packet. To do this, we need the data itself and the key, according to which an algorithm like AES (namely, it is used in the CCMP) transforms it into
The easiest way is to use the password from the wireless network as a key. However, this is fraught with serious problems:
- Too fast calculations - if we know the initial bytes of the original data (and almost always it is, because at the beginning there is some standard header), then we can try to decrypt the intercepted packet, replacing different passwords and looking at the output - if it contains a similar header, then most likely we have found the original password.
- Guarantee for life - if somehow we know the password, we can decipher everything that was transmitted earlier and will be transmitted later, until the administrator changes the network key. And as practice shows, even when changing a router, people usually put an old password on it, so hoping for their prudence is not, um , prudent.
- Lack of protection from a curious neighbor - if we can log in to the network, then nothing will prevent us from reading the packets of other clients and even arbitrarily replacing them, since the
slippers are one for all thepassword used to encrypt our data is used for all other clients within this network
It is as if there were many, many doors between us and the end goal, each of which leads inwards. The doors are the clients of the network, the “inside” is the network itself. If the same key fits all the doors, we can go through the next door and see what is happening there.
The second and third problems are easily eliminated by adding a random value to the key, which changes every time a secure connection is launched and even during its operation. The first is a very long key. But then the question arises:
There are two standard solutions for this: either imposing restrictions on the number of login attempts, or multiple encryption to slow down the process of obtaining the final string. The first option is not suitable, as it is suitable for online attacks (usually on the login form on websites) and is useless when the hash itself is already “leaked”. But the second - just our case.
However, there is a problem here: if we simply run a certain algorithm 10,000 times on our source line with a password, then the option is possible when the hacker creates a dictionary, having previously run the same algorithm on all possible combinations of passwords, and then all that remains is grab a handshake and see the hash in it on the table, which he has already managed to calculate. If there is such a hash in the table, it means that there is also the source row from which it was calculated, and it is known to it. And then the same table can be used to decrypt other data. Such a table is called a rainbow table. The technique gained particular popularity when selecting passwords in the stolen databases of old forum and other PHP engines.
This is solved by adding a "salt" - a random or more or less unique string, which, even if the passwords themselves coincide, will make the calculated hashes be different.
Let's see how the authors of the WPA standard have coped with these tasks:
The diagram above reflects the processes occurring in parallel on both sides (the client and the access point), and not what is transmitted over the radio channel - this is important and more on that below. Even before the start of the calculations, both the client and the TD already have the following data:
- The network password , as specified by the administrator, is on scheme 12345678 (
ay-ay-ay, what an irresponsible administrator) - Network name (SSID) - similarly specified by the administrator - on the mynet scheme
- The client's MAC address is on the FF: EE: DD: ...
- The MAC address of the access point (BSSID) is on the map 11:22:33: ...
It all starts with the fact that the “short password” (from the user) is converted into a longer key with the addition of the
The string obtained above is called PMK (Pairwise Master Key). It is static, that is, we should not encrypt data with its help, because it, like the password, does not change if the network name does not change - which means there is no difference in encryption for PMK and the password itself (this was mentioned in the problem the beginning). Accordingly, in the same way as with a password, we should not “shine” and PMK.
Therefore, then we need to get a temporary, very long and very unique key that we would use specifically for this data session. That is a temporary key. That is, PTK (Pairwise Transient Key - short-term pair key). For this, the same PBKDF algorithm is used, but 5 values are passed to its input:
- PMK - already calculated based on password and network name
- A-Nonce is just a random string sent by the access point to the client's request for connection (the very first packet during authorization)
- S-Nonce is another random string, but transmitted by the client to the TD in the next packet.
- Access Point BSSID (MAC Address)
- Client MAC address
So, having connected 5 values in line and having driven them 4096 times through SHA-1 we received 256-bit PTK. It will be used to encrypt all data from the client to the TD and vice versa.
The last step is to check that the client actually has the correct password to the network, because of which everything is started. You did not forget that the described manipulations occur on both sides independently and without interaction with each other, except for sending two nonce? In this case, having different source data, the parties will receive different PTKs, and if, say, the client encrypts its traffic and sends it to the access point, it will not be able to decrypt it because its PTK is different from the key that the client has encrypted . Different “initial data” here is, of course, first of all a password from the network, as it comes from an unstable element - a person, whereas MAC-addresses, a network name, etc. comes from “hardware”, which is usually negotiated without problems.
To check the transmitted data packet, a MIC is added to it - the Message Integrity Code, or the message integrity code. In WPA, HMAC-MD5 (a kind of well-known MD5) is used to calculate it. By the way, everyone is familiar with CRC32 - this is another algorithm for such purposes, it is often used to check files in the archive. The resulting code is also called the hash sum .
The idea is that by submitting a hash function (MD5, CRC, SHA and others) to the input of any data stream of arbitrary length, we get a certain output line that will be unique to this data stream. Naturally, 100% uniqueness is impossible - if the output string is 4 bytes, then, with all the desire, it will not be able to accommodate all possible input combinations. However, the algorithm is designed in such a way that we can’t find out what other lines can produce exactly the same hash (in fact, for weak algorithms like CRC this isn’t so; they are used to check data for accidental damage, and not intentional fabrication ).
Accordingly, let us imagine that we need to send line
12345 and at the same time allow the receiving party to check that the line has not changed during the transfer. To do this, we add its own hash to it: input = 1 2 3 4 5 sha1(1 2 3 4 5) = 8cb2237d0679ca88db6464eac60da96345513964 output = 1 2 3 4 5 | 8c b2 23 7d 06 79 ca 88 db 64 64 ea c6 0d a9 63 45 51 39 64 When receiving the device cuts off the hash from the received message (after the "|"), calculates the hash sum for what was left, and compares both parts. We agreed - it means that no clever pens to the data did not touch.
... But, of course, it's not that simple. It is easy to see that knowing the algorithm for calculating the hash sum, an attacker can change the message, calculate its new amount and replace the old one with a new one. What to do?
Let's look at this scheme again, this time we are interested in the last line. The MIC is composed of PTK and the byte stream of the message itself. PTK is our “salt” (as we remember, PTK is used to encrypt the stream itself, and now also to calculate its hash sum, that is, MIC ). Stream and PTK are transmitted to HMAC-MD5 and the resulting hash is called MIC . It is transmitted along with the message to the receiving side, which decodes the packet, calculates its MIC and if this MIC is different from the one found in the packet itself - it considers that someone got into the transmission process or simply was not flying weather, and discards this package.
And now attention: how can we understand that the client has the correct password to the network and, as a result, has calculated the correct PTK, without transferring this PTK itself? Simple: try to encrypt the first message on one side and see if it can be decrypted on the other. If identical PTKs were used, then the received MIC will coincide with the transmitted when decrypting. If different - MIC does not converge, as a result, PTK were different, as a result, PMK were different, and, as a result, the initial passwords were also different.
Finally, to consolidate - a simplified scheme of what, in fact, is transmitted in open form over the radio channel during a handshake.
As you can see, of all the more or less private data, the tricky guys in IEEE have managed to transfer one MIC, which is also transmitted already encrypted using PTK.
( Original art .)
What to do, Semyonitch?
I hope my brief review has shed some light on what black magic tools like aircrack-ng and hashcat use when trying to determine the password in a handshake. As we now know, they need to unwind the whole chain, having only the hash sum of one of the packages (MIC) in their hands. Namely, do the following:
- The first step is to calculate the network master key - PMK . To do this, take the password and network name. The last one is taken from the intercepted packets of a handshake (see below), and the first one can be taken from the dictionary one by one or go through all the available key space “head on”,
but only if you are a Jedi and have special street magic in the form of a pair of GPUs. - Next, the PTK is calculated - the hash sum from the received PMK (above), the client's MAC addresses and APs, and random nonce strings from them (taken from the intercepted packets).
- Finally, for a packet transmitted from the MIC, the MIC is calculated based on the PTK received above, the transmitted MIC is ignored (since it depends on the entire message, including the MIC itself, this field is set to 0 before the calculations, otherwise it is impossible to calculate amount, without knowing the MIC, to calculate which you need to know this amount).
- Both MICs are compared - if they match - the password is found (PTK is correct> PMK is correct> the password is correct), if not, go to line 1
Thus, each iteration requires at least 8192 calculations of SHA-1, which is 3 times slower than MD5. This is a very costly process. And what do we get in the end?
But in the end - only the original password and PTK of that hapless client, whose authentication we intercepted. This means that we will not be able to read the flows of other clients - they have different PTKs. We will not be able to read the data that this client transmitted before it connected - it also had another PTK. We will not even be able to read what he will transmit after the next time he connects - the PTK will change again!
This is a very important conclusion, which in the fourth article of the cycle will be very useful for us when intercepting packets in Wireshark. There, we will have to not only get the password from the network, as described in this article, but also intercept the handshakes of all the clients we want to listen to (or use ARP spoofing, but this is an attack on another level). That is still a job.
By the way, the experience with PTK is the son of difficult errors in WEP, where the same key has always been used to encrypt all client flows.
To arms!
With theory everything, I promise. Now only practice - from here to lunch.
So, once again: our task is to intercept the first 4 packets exchanged between the client and the access point (2 on each side) when establishing a connection. In sum, they are called handshake. After them, an already encrypted data transfer begins, from which nothing can be pulled out of us. By the way, these packets are part of the EAP protocol (or EAPOL), and under this name they appear in Wireshark (see the next article in the series).
Having intercepted them, we can save them to ourselves and then conduct a offline attack — that is, try to pick up the original password to the network, alternately trying different passwords to generate PMK> PTK> MIC and comparing the latter with the one that was actually transmitted has been described above.
Interception is done using airodump-ng , with which we are already familiar with the second part. You can play with the parameters, it was written about them there, but in general, the call looks like this:
airodump-ng mon0 -c 5 --bssid AP_BSSID -w caps Before that, you need to transfer your card to the “hacker mode” (monitor mode) and do all other manipulations (changing the MAC, txpower, etc. - see the second part ).
In the command above, we use the interface under the identifier
mon0 to collect packets of the attacked network on channel 5, which has the MAC specified after --bssid , saving the packets to the caps-NN.cap (by default, the standard libpcap format is used, which is supported by very many libraries on all OS, including Wireshark). NN will be replaced with a unique number, so when you restart airodump-ng with the same parameters, the old files will not be overwritten, but will have names like cap-01.cap and on.Assume that the network attacked by us has a BSSID
4F:B1:A4:05:5C:21 and is on channel 11. Then we do this: airodump-ng mon0 -c 11 --bssid 4F:B1:A4:05:5C:21 -w caps After launch, the familiar console window with two tables will open. Let's leave it hanging until someone connects to our network ...
But we can speed up this process! The reader remembers the fact that we can disable existing clients and force them to re-send authentication data - very useful for uncomplicated hackers like us. Already familiar aireplay-ng will be happy to help us:
aireplay-ng mon0 -0 5 -a 4F:B1:A4:05:5C:21 -c 5B:23:15:00:C8:57 5B:23:15:00:C8:57 - the MAC address of the client, which we learned from the table previously run airodump-ng .If everything is done correctly, aireplay-ng will display 5 lines of the form
Sending directed deauth , and in the window with airodump-ng we should observe a rapidly increasing number of “lost” packets (in the Lost column). It can go to thousands.After that, our dear client, if he was within range of our transmitter and if it was active (sometimes the device remains connected to the network, but does not use it, and disconnecting does not force it to reconnect), will immediately start authorization again and we will catch these packets , in the upper right corner, airodump-ng will triumphantly say
[ WPA handshake: 4F:B1:A4:05:5C:21 ] (the MAC address of the network whose handshake was intercepted).If that happens - the attack is successful, airodump-ng can be closed, copy the resulting
caps-01.cap to a USB flash drive Encrypted.
Password selection
The first part with the interception of a handshake is usually the easiest, especially in networks with many active clients. We received packages with MIC and other authorization data. Now we need to find out which of our keys will fit this lock?
Selection requires large computing power and for their sake you can rent an EC2 cluster or even build your ATI farm. And you can simply drive the packages through the dictionary of the most common passwords on a regular CPU with the hope that the GSSB user. The latter, by the way, may very well be - on the 11 networks I tested, one used the password "12345678", the second one - "123456789", and five others - passwords of 8 digits, which are cracked per day on the average system. At the same time, of the remaining 4, three were hacked for another two days via WPS (see the second part ).
Do not repeat such mistakes.
Another common option is a phone number (digits only). Especially important for networks of companies, shops, cafes. Typically, such a "password" hangs right at the entrance to the institution. Generate all numbers, if the code is known, it is possible through
crunch 10 10 -t 063%%%%%%% ( RaSta ).aircrack-ng
The easiest way to search. aircrack-ng uses only the CPU, but perfectly supports multithreading. She enumerates dictionary values for WPA networks (she also knows how to hack WEP).
Kali comes with a set of dictionaries in
/usr/share/wordlists/ , but if you wish, you can easily find them on the Internet of any size - from megabytes to tens of gigabytes. Pretty good compilation - WPA-PSK Wordlist 3 Final , as well as a generated dictionary of all combinations of 8-digit numeric passwords, which is obtained with the help of crunch 8 8 1234567890 aircrack-ng -w /usr/share/wordlists/fasttrack.txt caps-01.cap /usr/share/wordlists/fasttrack.txt (included with Kali) - the path to the dictionary file with passwords, one password per line. Lines shorter than 8 characters will be ignored, as this is the minimum length for WPA.On my i7 3840QM 4x3.8 GHz aircrack-ng squeezes ~ 4700 passwords per second. Thus, we can calculate how much time is required to complete a search of all possible combinations of 8 digits:
(10^8) / (4700 * 3600) = 5,91 Check the speed of selection without proper selection (benchmark), you can:
aircrack-ng -S # 4713 k/s And so you can see how many nuclei will be used in the selection:
aircrack-ng -u # No CPU detected: 8 (SSE2 available) In total, in 6 hours you can sort out 10 million passwords on a high-end mobile CPU. A digital password of such length should not be considered as a serious protection, and not even so - using GP (GPU), which gives tens and hundreds of times greater speed, such a password will break in minutes. About this below.
If the attack is successful, that is, aircrack-ng has found the password, then it will finish its work and the joyful
KEY FOUND! [ ... ] will be displayed on the screen KEY FOUND! [ ... ] KEY FOUND! [ ... ] - write it down and use it to enter the network. You can also write the found password to the file via -l pass.txt , which is useful when running a search in the background as aircrack-ng ... -l pass.txt &Explanation of the formula above:
- 10 ^ 8 - 10 to the power of 8, the number of possible combinations; computed as
__ ^ _. For example, for a 6-digit password from lowercase Latin characters would be 26 6 = 308 915 776 combinations. By the way, this clearly shows that the password length is much more important than the possible number of characters in it: remembering "this weirdo voodoo" is much simpler than "0.o@&z%_" - whereas the combinations of the first 10 25 more (ten and 24 zero). - 4700 - number of password comparisons per second (brute force)
- 3600 - bringing the result of division from passwords per second to passwords per hour (60 seconds * 60 minutes)
More calculations to compare:
(26^8) / (4700 * 3600 * 24) = 514 8- az (10^10) / (4700 * 3600 * 24) = 24,6 10- (26^10) / (4700 * 3600 * 24 * 365) = 952 10- az (10^12) / (4700 * 3600 * 24 * 365) = 6,7 12- (10^14) / (4700 * 3600 * 24 * 365) = 674,6 14- Statistics for longer lines it makes no sense to calculate, if we are talking only about the CPU. But before drawing conclusions, wait until we get acquainted with ATI goliaths.
The world went crazy or GPGPU - "GP of general purpose"
The times when the games were warm and tube-based, and the graphics processors
Graphics chips are fundamentally different in their design features from the CPU architecture. If we are talking about 4, 8, 16 cores with the CPU (we don’t take a server), then in the case of a GP we are talking about thousands of independent cores. When processing graphics, you need to quickly perform operations on large arrays - matrices. And it is precisely such operations that are needed in cryptography. Therefore, GP can be used to calculate hashes - or the production of cryptocurrencies.
GP can be assembled together within one system, and systems into clusters, creating “farms”. With a huge performance gap from conventional CPUs, it is much more efficient to build a farm of 10 systems with 4 GPs than of 10 systems with 4 CPUs.
Only ASIC and FPGAs — special devices that can be programmed to perform certain calculations — can give greater performance, but you need to mess with and write separate software, and the GP and SDK for them have been around for a long time and start writing for them relatively easily. ATI-shny cards look especially attractive, which, due to their architecture, are an order of magnitude superior to nVidia cards specifically for these tasks, and at the same time much cheaper.
In the context of our task, the selection of passwords using GPs can be done by two wonderful programs: hashcat and pyrit .
hashcat is a closed, free utility for lightning-fast computation of hashes of various forms, using various algorithms (MD5, SHA, WPA and a couple more dozen), applying rules to vocabulary words and even adding salt. In my opinion this is the best that exists today. A little upsetting the closeness of the project, but the author can be understood - this is a big job.
hashcat consists of three programs: hashcat (it doesn’t use GP and is comparable in speed to my tests with pyrit and a little slower than aircrack-ng , which is generally the fastest on the CPU); oclhashcat for OpenCL (SDK from ATI) and cudaHashcat (nVidia). The last two are identical in capabilities, but must match the manufacturer of your GP. Before their work, you need to install the driver and the SDK, since without them the GPU cores will not be recognized.pyrit is an open source tool for picking WPA keys in Python. In general, a pleasant program, fits perfectly for its purposes. It also has versions for the CPU and both GPU manufacturers, however it only works with WPA. Unlike oclhashcat, pyrit uses both the CPU and the GP, while oclhashcat uses only the GP. The author of the latter explains this by the fact that the gain is minimal and there are a lot of programming costs.
Driver installation
So, let's see how we use this toolkit. The mechanism described below was discovered after many hours of dealing with Kali, CUDA and the Pyrit source codes, so I hope that it will save this time for you. Everything was successfully tested on
Kali 1.0.7 x64 version Kali 1.0.7 x64 and versions cuda_6.0.37_linux_64 and NVIDIA-Linux-x86_64-331.67 . The laptop uses Optimus (technology from nVidia to switch between the integrated GP from Intel). The Kali documentation has a page about installing nVidia drivers - it can also come in handy.Initially, Kali does not have software installed for working with GP, as today there are two competing standards (OpenCL from AMD and CUDA from nVidia), and in addition, CUDA uses closed drivers, not standard nouveau . So you have to install everything yourself.
First, let's install the Linux kernel source headers:
apt-get install linux-headers-`uname -r` Next, download the drivers for nVidia and SDK for CUDA. Take links to RUN-files from the nVidia website and from the CUDA section .
wget http://.../NVIDIA-Linux-x86_64-331.67.run wget http://.../cuda_6.0.37_linux_64.run Next we need to exit the window manager (X).In fact, this mysterious phrase (in the manuals - shutdown the X server / session ) literally means the following:
shutdown 0 This will transfer the system to maintenance / single user mode. Kali will ask for a root password or press Ctrl + D - the latter will restart GNOME, which we do not need at all. Enter the password, which is the default toor , and get into the console. There we perform:
modprobe -r nouveau chmod +x *.run ./NVIDIA-Linux-x86_64-331.67.run ./cuda_6.0.37_linux_64.run In this case, when installing drivers (the penultimate command):
- We select No when the installer tells us that we should be in runlevel 3 ( I did not manage to go to it through telinit 3 , as he was still cursing, but it didn’t affect further normal operation)
- No 32- ( 64- )
- nVidia ( nouveau ) — X , No
For the CUDA installer, we answer n when he wants to install the nVidia driver (the second question after accepting the license) - I don’t understand this moment, but installing the driver through it always ends with installation
Installation failed, while putting the same drivers through the previously downloaded The first installer succeeds.All other questions of the CUDA installer are answered with y . Samples can be set, you can not (occupy about 230 MB).
To check the performance of the delivered CUDA, you can run nvcc (located in
/usr/local/cuda/bin) - if it passed without errors, then everything works.If during the installation the wired network interface is disconnected (sometimes) - it can be raised like this:
ifconfig eth0 up dhclient eth0 Finally, if something is wrong with the installation and you want to return the old driver to reopen GNOME, first load nouveau back and then press Ctrl + D .:
modprobe nouveau I recommend carrying out all the driver manipulations after loading the OS into read only (see the second part), since damaging the driver is very easy and then losing the normal desktop and you have to get by with the console in search of a problem.
Installing cpyrit_cuda and oclhashcat
Now you can install the actual utilities themselves. hashcat is put through
apt-get install -y oclhashcat(for both versions of OpenCL / CUDA), and pyrit is built from source (note: use the latest version in trunk, since there is a bug in the current stable version that may fail to compile on some nVidia, as it was with my card).Install pyrit (if you have OpenCL - see the documentation on the project site ):
apt-get install -y libpcap-dev python-scapy svn checkout http://pyrit.googlecode.com/svn/trunk/ psrc cd psrc/pyrit sudo python setup.py build sudo python setup.py install cd ../cpyrit_cuda sudo python setup.py build sudo python setup.py install The build is complete. See if pyrit found our cards:
pyrit list_cores If successful, it will be displayed
#0 GPU ...- one line for each core, plus one line for each CPU core (though, on my system, one processor core was “eaten up” by the GPU — perhaps pyrit does not support more than 8 threads).Then we can run the test and in 10-20 seconds find out the approximate speed of the search using the capabilities of the GP:
pyrit benchmark On my system, both pyrit and hashcat give out 10,500 (GP) + 4,000 (CPU) passwords per second, which once again confirms the unsuitability of nVidia for such calculations (I have a GeForce GTX 675MX ). A similar mobile card from ATI issues about 40,000 p / s.
So, let's run brute force on pyrit :
pyrit -r caps-01.cap -e MYNET -i /usr/share/wordlist/fasttrack.txt attack_passthrough Parameters are similar to aircrack-ng . When the match is found, pyrit will exit and the key will be visible on the screen.
If at start of pyrit and hashcat warnings about ACPI appear - they can be ignored if calculations go normally. I have them for 10-15 pieces.
If we want to go through all the digital passwords of a certain length - this can be done in two ways: on the fly or by generating a dictionary on the disk. Kali has several utilities for generating dictionaries, one of them is crunch :
crunch 8 10 0123456789 | pyrit -r caps.cap -e MYNET -i - attack_passthrough -i - says pyrit to read passwords from stdin , and 8 10 - the minimum and maximum lengths of the generated crunch words, consisting of characters 0123456789 . It does not make sense to generate a dictionary with saving to disk, since the file will be 112 GB and can be saved, since the generation will not affect the speed of the search on the fly.
Running hashcat
Since hashcat is a more universal utility, the syntax of its parameters is more complicated, and besides, it takes as input not a standard libpcap file (which we previously saved via airodump-ng ), but our own *.hccap.The process of converting from .cap to .hccap is described in the official wiki . This is done simply: first, we remove all packages from the file except handshakes, and then convert the remaining ones to .hccap: The site also has an online converter that accepts files up to 5 MB in size - if you are not very concerned about privacy, you can use and them (he does the same thing as described below).
wpaclean clean.cap caps-01.cap aircrack-ng clean.cap -J hashcat hashcat.hccap hashcat , oclhashcat cudahashcat . , wpaclean ( Kali) , . , ( , aircrack , hashcat , pyrit . , , ).hashcat
oclhashcat -h . — .( -m2500indicates the selection of the key in the WPA handshake, -a3 sets the selection mode for the mask, and ? d ... - the mask for generating words (
?ddenotes characters 0-9, and eight ?din a row denote 8 digits one by one): oclhashcat -m2500 -a3 caps.hccap ?d?d?d?d?d?d?d?d Similarly, but brute force by dictionary ( -a0 can be omitted):
oclhashcat -m2500 -a0 caps.hccap /usr/share/wordlists/fasttrack.txt And so we run a simple search in a row ( -a3 ) passwords for hashes in the file
~/hashes.txt, calculated by the algorithm sha1(+)( -m110 ), and the six-digit passwords are in the form [AZ] [A-Z0-9] [A-Z0-9] [A-Z0-9] [A-Z0-9] [0-9]: oclhashcat -m110 -a3 -1?d?l ~/hashes.txt ?u?1?1?1?1?d Finally, you can run a speed test this way:
oclhashcat -b Found passwords will be displayed on the screen, as well as recorded in a file
/usr/share/hashcat/hashcat.pot, or for GP versions - c /usr/share/oclhashcat/hashcat.pot.While the utility is working, in the terminal you can press Enter to display the current status (speed, remaining% and others). If you click on q , the program will stop, save the state, and continue from the same place using the same command line with the added -s 1234 , where the number indicates the session number (it is displayed at the moment of exit from the utility).
Amazon EC2
For interest, I drove the selection of WPA-keys on the two most powerful AWS clusters: cc2.8xlarge (32 CPU cores) and g2.2xlarge (1 nVidia Tesla and 8 CPU cores): g2.2xlarge = 22000 k/s [pyrit+cuda] cc2.8xlarge = 14000 k/s [aircrack-ng] 13500 k/s [pyrit] As you can see, even the ultra-expensive card from nVidia does not cope with the task of calculating hashes in the same way as the average GPs from ATI. In fact, Tesla gives even lower speed than regular GTX. It is understandable - it has a completely different purpose. And that is why ATI fit so well in this business - an interesting question ...
And, of course, 32 server cores are not able to contend even with Tesla.
Why AMD is so superior to similar solutions nVidia? The point is more stream processors (cores), as a result, faster operations on integer values (not floating-point numbers that are not needed in cryptography) and in particular - thanks to special instructions that can be used for encryption (
BIT_SELECTand BFI_INT).Who wants to try it yourself is installedaircrack-ng on EC2 with Debian or Ubuntu like this:
sudo yum install gcc libnl-devel openssl-devel wget http://download.aircrack-ng.org/aircrack-ng-1.2-beta3.tar.gz tar xf aircrack-ng-1.2-beta3.tar.gz cd aircrack-ng-1.2-beta3 sudo make install Statistics
Now, looking at how the CPU and the GP cope with the brute force of passwords, you can draw conclusions. Below are statistics on some modern video cards for today (June 2014). The data was obtained for several of my systems, from comrade chem_ua and open sources ( golubev.com , pages oclhashcat and forum ). You can compare the capabilities of different cards relative to each other on the extensive table on the Litecoin wiki and similar ones in Bitcoin .
The numbers are approximate, depending on the system configuration, OS, temperature / cooling and overclocking. If you have your data - share in the comments or in person , I will add them to the table. kh / s - the number of calculations and comparisons of passwords per second in thousands (10 kh / s = 10 000 passwords per second).
nVidia 670 24 kh/s nVidia 675MX 11 kh/s nVidia 780M 42 kh/s nVidia 580 47 kh/s nVidia Tesla K20 85 kh/s nVidia 750 Ti 55 kh/s nVidia Titan Black 108 kh/s AMD 280X 160 kh/s AMD 290X 190 kh/s AMD 295X*2 203*2 kh/s AMD 5870 101 kh/s AMD 5870 153 kh/s AMD 6870 72 kh/s AMD 6990 181 kh/s AMD 7970 128 kh/s AMD 7990 220 kh/s Attention: although the numbers go off-scale even when comparing a low-cost GP (for example, 5870 for $ 90) with the results of the CPU, remember that, unlike the latter, graphics processors, and especially from AMD, consume ten times more electricity (for example, have a power supply of 0.75-1 kW for only two 290X). So, before buying such a “generator”, first calculate how much a monthly electricity bill will cost you, especially if you plan to overclock them. Or look at the 750 Ti , for which you need only 300 watts.
Dry residue
Familiarity with calculating hashes using GP allows us to understand
Thus, the above-mentioned time-over figures for WPA look like this:
(26^8) / (1500000 * 3600) = 38,7 8- az ( 514 ) (10^10) / (1500000 * 3600) = 2 10- ( 25 ) (26^10) / (1500000 * 3600 * 24 * 365) = 3 10- az ( 952 ) (10^12) / (1500000 * 3600 * 24) = 7,7 12- ( 7 ) (10^14) / (1500000 * 3600 * 24 * 365) = 2,1 14- ( 674 ) As you can see, the numbers have changed dramatically. Moreover, if we look at the strength of passwords with MD5 (which is calculated 61,000 times faster, and this is without rainbow-tables, which, however, are useless for long passwords because of their size):
(26^8) / (94000000000) = 2 8- az (10^10) / (94000000000) = 100 10- (26^10) / (94000000000 * 60) = 25 10- az (10^12) / (94000000000) = 10,6 12- (10^14) / (94000000000 * 60) = 17,7 14- MD5 and SHA1 (which is only three times slower than the first) are still used by many sites to hash users' passwords, often without adding salt, although they do not change the situation too much. Since we cannot vouch for the reliability of all sites where we register (especially with an example of a large website, Adobe), using digital passwords with a length of less than 20 characters (see below) or letters with a length of less than 14 is at least reckless. And it's not even about adding parentheses and periods (which some sites are generally prohibited in passwords for some reason) - as you can see, the difference between 10-digit numeric and alphabetic passwords will extend the last of the latter for about half an hour.
So what to do?
As they say, saving the father of Russian democracy is the work of democracy itself. Let's see what happens if we add 4 characters to the password length:
(26^10) / (1500000 * 3600 * 24 * 365) = 3 10- az (26^12) / (1500000 * 3600 * 24 * 365) = 2 017 12- az (10^16) / (1500000 * 3600 * 24 * 365) = 211 16- (10^18) / (1500000 * 3600 * 24 * 365) = 21 140 18- And for MD5:
(26^12) / (94000000000 * 3600 * 24) = 11,6 12- az (10^16) / (94000000000 * 3600 * 24) = 1 16- (10^18) / (94000000000 * 3600 * 24) = 123 18- (26^16) / (94000000000 * 3600 * 24 * 365) = 14 710 16- az (26^14) / (94000000000 * 3600 * 24 * 365) = 21,7 14- az (26^16) / (94000000000 * 3600 * 24 * 365) = 14 710 16- az (10^20) / (94000000000 * 3600 * 24 * 365) = 34 20- (10^22) / (94000000000 * 3600 * 24 * 365) = 3 373 22- As you can see, even “fast” MD5 with a length of 16 alphabetic characters does not make sense to break anymore. Especially in the absence of "vocabulary" words of such length - if only we do not speak about
qwertyuiopasdfghjk.This idea - the importance of the length of the password, and not its content - is not new. Three years ago, XKCD drew its historical strip :
(“After 20 years of constant effort, we finally succeeded in teaching people to invent difficult-to-remember passwords that are easily matched by a computer.”)
And in April, Stanford published new requirements for passwords that come down to the fact that passwords are From 20, there are no requirements for the alphabet (it is not necessary to have numbers, letters in upper case, and so on).
With all this, the requirements of such organizations as Alfa-Bank look sad, where the password length is limited to 16 characters without allowing most of the special characters to appear.
To summarize : in order not to leave the attacker a chance to pick a password for WPA, it is worthwhile to come up with a 12-character alphabetic password and if in the coming years a quantum computer will not be accessible to the masses, there is nothing to fear. Well, 16 characters are enough for passwords for websites and if they do not store them in clear text - whatever you think of, it will remain a secret. Until the next coming of computers.
(A notable and unexpected example of a site that stores passwords in clear text is the ixbt.ru forum : “Please keep in mind that your password will not be encrypted and can be viewed by the conference administrator. "- so be vigilant!)
On this the excursion into the jungle of calculations is over. The next, probably the last article in the series is about listening to wireless network traffic after you entered it.
Did you like the article? Was the handshake process clearly understood? Were there any errors / inaccuracies in the description (for experts)? Have something to share? Waiting for your comments, which also speed up the writing of the next part!
Table of contents:
1) materiel
2) Kali. Hiding SSID. MAC filtering. WPS
3) WPA. OpenCL / CUDA. Pick statistics
Source: https://habr.com/ru/post/226431/
All Articles