Cybersecurity challenge - WEP
I found this challenge somewhere on the web, and I find it interesting because it requires brute forcing a WEP cipher. WEP is very insecure, and there are numerous programs capable of running a statistical attack against it in a short time. This does require a certain amount of captured traffic. For example, lets work on the following package capture from https://github.com/aircrack-ng/aircrack-ng/blob/master/test/wep_64_ptw.cap and pass it to aircrack-ng:
aircrack-ng Downloads/wep_64_ptw.cap Opening Downloads/wep_64_ptw.capRead 65282 packets. # BSSID ESSID Encryption 1 00:12:BF:12:32:29 Appart WEP (0 IVs)Choosing first network as target.Opening Downloads/wep_64_ptw.capRead 65282 packets.1 potential targetsAttack will be restarted every 5000 captured ivs.Starting PTW attack with 30566 ivs. Aircrack-ng 1.4 [00:00:01] Tested 1514 keys (got 30566 IVs) KB depth byte(vote) 0 0/ 9 1F(39680) 4E(38400) 14(37376) 5C(37376) 9D(37376) 1 7/ 9 64(36608) 3E(36352) 34(36096) 46(36096) BA(36096) 2 0/ 1 1F(46592) 6E(38400) 81(37376) 79(36864) AD(36864) 3 0/ 3 1F(40960) 15(38656) 7B(38400) BB(37888) 5C(37632) 4 0/ 7 1F(39168) 23(38144) 97(37120) 59(36608) 13(36352) KEY FOUND! [ 1F:1F:1F:1F:1F ] Decrypted correctly: 100%This only takes seconds, and so this is normally not an interesting exercise. If the number of IVs is too small, one can usually just capture for longer and/or force the generation of more. This challenge however provides a capture file with just a few IVs:
Read 103572 packets. # BSSID ESSID Encryption 1 00:0F:B5:56:E0:9E GreHack2012 WEP (0 IVs)Choosing first network as target.Opening Downloads/ch10.capit...Read 103572 packets.1 potential targetsAttack will be restarted every 5000 captured ivs.Starting PTW attack with 1268 ivs. Aircrack-ng 1.4 [00:00:03] Tested 171361 keys (got 1268 IVs) KB depth byte(vote) 0 29/ 30 FC(2048) 07(1792) 0B(1792) 10(1792) 11(1792) 1 1/ 8 A2(2816) 07(2560) 11(2560) 27(2560) 8A(2560) 2 17/ 2 F8(2304) 13(2048) 37(2048) 62(2048) 6A(2048) 3 9/ 11 A0(2560) 10(2304) 3F(2304) 4E(2304) 55(2304) 4 14/ 4 D2(2304) 03(2048) 12(2048) 18(2048) 38(2048) Failed. Next try with 5000 IVs.And it stays there because no new data is forthcoming. This makes it necessary to brute force the key and it makes me curious: how long will it take in 2019 to brute force a 40 WEP key? weplab is an alternative to aircrack-ng and is a good program to brute force because you can specify the number of threads to use and it also has some sort of optimized key generation routine. Anyway, lets run this on an HP Envy 17 laptop with a Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz
weplab - Wep Key Cracker Wep Key Cracker (v0.1.5).Jose Ignacio Sanchez Martin - Topo[LB] <topolb@users.sourceforge.net>Not BSSID specified. Detected one packet with BSSID: [00:0F:B5:56:E0:9E] Total valid packets read: 45174Total packets read: 103572Bruteforce started! Please hit enter to get statistics.Process number: 0 ===> 731683 keys tested [731683 c/s] >>> Key: 22:2a:0b:00:00Process number: 0 ===> 4725630 keys tested [525070 c/s] >>> Key: 7d:1b:48:00:00Process number: 0 ===> 8168050 keys tested [544536 c/s] >>> Key: 71:a2:7c:00:00Process number: 0 ===> 11791854 keys tested [561516 c/s] >>> Key: ed:ed:b3:00:00sooo..... about 500000 checks per second. 2^40 combinations -> about 1e20 keys to check -> about 2200000 seconds -> about 24 days.
Certainly doable, but weplab has a multithreading option:
weplab -b -m 2 ../../ch.cap weplab - Wep Key Cracker Wep Key Cracker (v0.1.5).Jose Ignacio Sanchez Martin - Topo[LB] <topolb@users.sourceforge.net>Not BSSID specified. Detected one packet with BSSID: [00:0F:B5:56:E0:9E] Total valid packets read: 45174Total packets read: 103572Bruteforce started! Please hit enter to get statistics.Process number: 0 ===> 6899925 keys tested [313632 c/s] >>> Key: a8:91:d2:00:00Process number: 0 ===> 6899925 keys tested [313632 c/s] >>> Key: a8:91:d2:00:00Process number: 0 ===> 6899925 keys tested [313632 c/s] >>> Key: a8:91:d2:00:00Process number: 0 ===> 6899925 keys tested [313632 c/s] >>> Key: a8:91:d2:00:00Process number: 0 ===> 6899925 keys tested [313632 c/s] >>> Key: a8:91:d2:00:00Process number: 0 ===> 6899925 keys tested [313632 c/s] >>> Key: a8:91:d2:00:00Process number: 0 ===> 6899925 keys tested [313632 c/s] >>> Key: a8:91:d2:00:00Process number: 0 ===> 6899925 keys tested [313632 c/s] >>> Key: a8:91:d2:00:00Process number: 0 ===> 6899925 keys tested [313632 c/s] >>> Key: a8:91:d2:00:00Process number: 0 ===> 6899925 keys tested [313632 c/s] >>> Key: a8:91:d2:00:00Process number: 0 ===> 6899925 keys tested [313632 c/s] >>> Key: a8:91:d2:00:00Process number: 0 ===> 6899925 keys tested [313632 c/s] >>> Key: a8:91:d2:00:00Process number: 0 ===> 6899925 keys tested [313632 c/s] >>> Key: a8:91:d2:00:00Process number: 0 ===> 6899925 keys tested [313632 c/s] >>> Key: a8:91:d2:00:00Process number: 0 ===> 6899925 keys tested [313632 c/s] >>> Key: a8:91:d2:00:00and it's stuck there forever. Clearly the standard weplab obtained via sudo apt install weplab is broken for multithreaded brute force, and nobody has noticed because it's not really in use any more. In fact, the sourceforge repository for the source seems to be down too.https://sourceforge.net/projects/weplab/ gives back an 'oops' message. Luckily, there is a debian repository available here http://cdn-fastly.deb.debian.org/debian/pool/main/w/weplab/ There are some patches made by debian, but the thing will still not compile under my ubuntu 18.10
makegcc -g -O2 -Wall -pipe -o weplab main.o analpfile.o bruteforce.o capture.o debug.o dictionary.o globals.o heuristics.o md5.o wep.o attack.o -lpcap /usr/bin/ld: analpfile.o: in function `AnalyzePcapFile':/home/jan/Downloads/weplab_0.1.5.orig/weplab-0.1.5/analpfile.c:85: undefined reference to `debug'/usr/bin/ld: /home/jan/Downloads/weplab_0.1.5.orig/weplab-0.1.5/analpfile.c:88: undefined reference to `debug'/usr/bin/ld: /home/jan/Downloads/weplab_0.1.5.orig/weplab-0.1.5/analpfile.c:160: undefined reference to `debug'/usr/bin/ld: /home/jan/Downloads/weplab_0.1.5.orig/weplab-0.1.5/analpfile.c:161: undefined reference to `debug'/usr/bin/ld: /home/jan/Downloads/weplab_0.1.5.orig/weplab-0.1.5/analpfile.c:163: undefined reference to `debug'/usr/bin/ld: analpfile.o:/home/jan/Downloads/weplab_0.1.5.orig/weplab-0.1.5/analpfile.c:164: more undefined references to `debug' followcollect2: error: ld returned 1 exit statusmake: *** [Makefile:173: weplab] Error 1The solution is here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778167 ; the compiler flag -std=gnu89 fixes the issue.
This lets the source compile, but does not solve the multithreading issue. Interestingly, it turned out to be an initialization error, where pid_t mpid; caused fork() to behave in unexpected ways. pid_t mpid=1; fixes the source and allows for multithreaded operation.
Further, I started an Amazon compute optimized instance, c5.9xlarge which provides 36 cpu cores to run the program on.
./weplab -b -m 36 ./ch.cap weplab - Wep Key Cracker Wep Key Cracker (v0.1.5).Jose Ignacio Sanchez Martin - Topo[LB] <topolb@users.sourceforge.net>Not BSSID specified. Detected one packet with BSSID: [00:0F:B5:56:E0:9E] Total valid packets read: 45174Total packets read: 103572Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Bruteforce started! Please hit enter to get statistics.Process number: 1 ===> 1094383 keys tested [547191 c/s] >>> Key: d9:5d:16:02:00Process number: 20 ===> 1092964 keys tested [546482 c/s] >>> Key: a4:e9:61:02:00Process number: 23 ===> 1093842 keys tested [546921 c/s] >>> Key: 17:67:62:02:00Process number: 2 ===> 1094419 keys tested [547209 c/s] >>> Key: 4a:62:16:02:00Process number: 21 ===> 1093365 keys tested [546682 c/s] >>> Key: ed:22:62:02:00Process number: 24 ===> 1093733 keys tested [546866 c/s] >>> Key: 84:57:62:02:00Process number: 25 ===> 1093706 keys tested [546853 c/s] >>> Key: a9:53:62:02:00Process number: 3 ===> 1094406 keys tested [547203 c/s] >>> Key: b7:60:16:02:00Process number: 22 ===> 1093851 keys tested [546925 c/s] >>> Key: 5e:68:62:02:00Process number: 26 ===> 1093570 keys tested [546785 c/s] >>> Key: 3e:40:62:02:00Process number: 4 ===> 1094193 keys tested [547096 c/s] >>> Key: 28:99:62:02:00Process number: 27 ===> 1093737 keys tested [546868 c/s] >>> Key: 1b:58:62:02:00Process number: 28 ===> 1093671 keys tested [546835 c/s] >>> Key: ac:4e:62:02:00Process number: 29 ===> 1093677 keys tested [546838 c/s] >>> Key: 89:4f:62:02:00Process number: 5 ===> 1094226 keys tested [547113 c/s] >>> Key: dd:9d:62:02:00Process number: 30 ===> 1093685 keys tested [546842 c/s] >>> Key: ae:50:62:02:00Process number: 31 ===> 1093496 keys tested [546748 c/s] >>> Key: af:35:62:02:00Process number: 32 ===> 1093559 keys tested [546779 c/s] >>> Key: b0:3e:62:02:00Process number: 6 ===> 1094163 keys tested [547081 c/s] >>> Key: de:94:62:02:00Process number: 33 ===> 1093589 keys tested [546794 c/s] >>> Key: f9:42:62:02:00Process number: 34 ===> 1093537 keys tested [546768 c/s] >>> Key: 8e:3b:62:02:00Process number: 7 ===> 1094135 keys tested [547067 c/s] >>> Key: df:90:62:02:00Process number: 35 ===> 1093439 keys tested [546719 c/s] >>> Key: 8f:2d:62:02:00Process number: 8 ===> 1094095 keys tested [547047 c/s] >>> Key: 2c:8b:62:02:00Process number: 0 ===> 1090325 keys tested [545162 c/s] >>> Key: 90:62:14:02:00Process number: 9 ===> 1094100 keys tested [547050 c/s] >>> Key: e1:8b:62:02:00Process number: 10 ===> 1094032 keys tested [547016 c/s] >>> Key: 2e:82:62:02:00Process number: 11 ===> 1094025 keys tested [547012 c/s] >>> Key: 2f:81:62:02:00Process number: 12 ===> 1093979 keys tested [546989 c/s] >>> Key: 9c:7a:62:02:00Process number: 13 ===> 1093912 keys tested [546956 c/s] >>> Key: 0d:71:62:02:00Process number: 14 ===> 1093987 keys tested [546993 c/s] >>> Key: c2:7b:62:02:00Process number: 15 ===> 1093916 keys tested [546958 c/s] >>> Key: 9f:71:62:02:00Process number: 16 ===> 1093892 keys tested [546946 c/s] >>> Key: 34:6e:62:02:00Process number: 17 ===> 1093866 keys tested [546933 c/s] >>> Key: 7d:6a:62:02:00Process number: 19 ===> 1093855 keys tested [546927 c/s] >>> Key: eb:68:62:02:00Process number: 18 ===> 1093883 keys tested [546941 c/s] >>> Key: ea:6c:62:02:00Interestingly, still about 500k checks per second on each CPU core, but now there are 36 of them, so the expected run time for a full range key check is about 24/36 = 2/3 days. In this particular case it took a bit over 4 hours:
Process number: 1 ===> 5086469218 keys tested [451448 c/s] >>> Key: 25:8c:ab:e5:25Process number: 6 ===> 5085945416 keys tested [451401 c/s] >>> Key: ba:2e:7b:4e:2bProcess number: 7 ===> 5085975230 keys tested [451404 c/s] >>> Key: df:d1:8b:4e:2bProcess number: 2 ===> 5086445115 keys tested [451446 c/s] >>> Key: 4a:c7:9f:e5:25Process number: 8 ===> 5085852114 keys tested [451393 c/s] >>> Key: e0:1d:47:4e:2bProcess number: 9 ===> 5085957242 keys tested [451402 c/s] >>> Key: 2d:c8:81:4e:2bProcess number: 10 ===> 5085880016 keys tested [451396 c/s] >>> Key: e2:af:56:4e:2bProcess number: 11 ===> 5085813781 keys tested [451390 c/s] >>> Key: bf:b9:31:4e:2bProcess number: 12 ===> 5085793803 keys tested [451388 c/s] >>> Key: c0:93:26:4e:2bProcess number: 13 ===> 5085814240 keys tested [451390 c/s] >>> Key: 55:fb:31:4e:2bProcess number: 22 ===> 5086025300 keys tested [451409 c/s] >>> Key: ca:c2:a7:4e:2bProcess number: 14 ===> 5086118215 keys tested [451417 c/s] >>> Key: 56:9c:db:4e:2bProcess number: 15 ===> 5085583668 keys tested [451369 c/s] >>> Key: 7b:50:b1:4d:2bProcess number: 16 ===> 5085796755 keys tested [451388 c/s] >>> Key: 7c:39:28:4e:2bProcess number: 17 ===> 5085918643 keys tested [451399 c/s] >>> Key: 11:3e:6c:4e:2bProcess number: 18 ===> 5085882155 keys tested [451396 c/s] >>> Key: 7e:e1:57:4e:2bProcess number: 19 ===> 5085887643 keys tested [451396 c/s] >>> Key: 7f:f1:5a:4e:2bProcess number: 20 ===> 5081826434 keys tested [451036 c/s] >>> Key: c8:a4:80:45:2bProcess number: 21 ===> 5085101455 keys tested [451327 c/s] >>> Key: ed:38:a4:4c:2bProcess number: 23 ===> 5085909997 keys tested [451398 c/s] >>> Key: ef:6a:67:4e:2bProcess number: 24 ===> 5085946488 keys tested [451402 c/s] >>> Key: f0:c7:7b:4e:2bProcess number: 25 ===> 5085976371 keys tested [451404 c/s] >>> Key: f1:74:8c:4e:2bProcess number: 26 ===> 5085347814 keys tested [451348 c/s] >>> Key: 1a:b3:2d:4d:2bProcess number: 27 ===> 5085913689 keys tested [451399 c/s] >>> Key: 63:7a:69:4e:2bProcess number: 28 ===> 5085771853 keys tested [451386 c/s] >>> Key: 1c:54:1a:4e:2bProcess number: 29 ===> 5085816725 keys tested [451390 c/s] >>> Key: 65:5e:33:4e:2bProcess number: 30 ===> 5085931053 keys tested [451400 c/s] >>> Key: f6:2a:73:4e:2bProcess number: 31 ===> 5085120918 keys tested [451328 c/s] >>> Key: 67:15:af:4c:2bProcess number: 32 ===> 5085815446 keys tested [451390 c/s] >>> Key: b0:a7:32:4e:2bProcess number: 33 ===> 5085839801 keys tested [451392 c/s] >>> Key: f9:3e:40:4e:2bProcess number: 0 ===> 5086503048 keys tested [451451 c/s] >>> Key: fc:10:bc:e5:25Process number: 34 ===> 5085943143 keys tested [451401 c/s] >>> Key: 22:ea:79:4e:2bProcess number: 35 ===> 5085961709 keys tested [451403 c/s] >>> Key: 6b:46:84:4e:2bProcess number: 3 ===> 5086554189 keys tested [451455 c/s] >>> Key: 93:09:d5:e5:25Process number: 5 ===> 5085985911 keys tested [451405 c/s] >>> Key: b9:c7:91:4e:2bProcess number: 4 ===> 5085905124 keys tested [451398 c/s] >>> Key: b8:b2:64:4e:2bIt seems that the first control data packet verifies the key! Let's test it with others....Right KEY found!!$ uptime 11:22:41 up 4:24, 1 user, load average: 35.01, 35.41, 35.74Even without statistical attacks WEP is completely insecure nowadays. I put the fixed code base up on github, in case you want to experiment with this too.