Ads

Sunday, August 31, 2014

Wireless Security Hack - Cracking WEP

WLAN control is cracking WEP. As mentioned, wireless attacks do not start and end with cracking WEP, as many security experts might tell you. However, if the attacker cannot break WEP (if present), all he or she can do is disrupt the network operations by DoS attacks on layers below the protocol WEP implementation.
From the section dealing with WEP cracking tools, you have probably gathered that there are three major ways of attacking WEP:
  • Brute-forcing and improved brute-forcing
  • FMS attack
  • Improved FMS attack
Because this book is a down-to-earth guide to wireless security and hundreds of pages have already been written on WEP weaknesses and cracking mathematics, we do not aim to provide a comprehensive guide to the mathematical internals of WEP cracking attacks. Nevertheless, we believe it is important to present some cryptological data on WEP as an act of homage to all researchers who contributed to the WEP analysis and flaw enumeration.

WEP Brute-Forcing

Pure WEP keyspace brute-forcing with tools such as wep_tools or dwepcrack brute-forcing options is realistic only against 40-bit WEP keys. Even with this limited key size, it might take about 50 days on a single average Pentium III host. Nevertheless, an efficient distributed attack against 40-bit WEP is possible and one should never underestimate the potential of dictionary attacks, which are also applicable to 128-bit and higher WEP key size. In particular, it applies to the use of the newer Wepattack tool that can run dictionary attacks against a single captured data packet encrypted using WEP.

Tim has pointed out that the algorithm accepted as the de facto standard for 40-bit WEP key generation by many wireless equipment vendors is extremely flawed. It starts from folding a password string into a 32-bit number that reduces the keyspace from 240 to 232 bits. This number is employed to seed a pseudorandom number generator (PRNG which is used to derive all four 40-bit WEP keys used on the network. Although the PRNG-generated keyspace has a cycle length of 232 bits, because of the way the values are derived from the PRNG, the actual cycle length of drawn values is only 224 bits. To be more specific, a seed x produces the same keys as a seed x + 224. To make the situation even worse, the method chosen to fold a password string into a 32-bit seed ensures that the high bit of each of the four bytes always equals zero. The effect of these weaknesses combined is that the algorithm can only generate 221 unique sets of WEP keys, corresponding to seeds between 0 and 0x1000000, which do not have bits 0x80, 0x8000, or 0x800000 set. Thus, it takes 221 operations or less to crack any set of WEP keys generated from a password processed with such an algorithm. In Newsham's observations, this corresponds roughly to 90 seconds of cracking time on a 233-MHz PII or 35 seconds on a 500-MHz PIII; this is quite a difference if compared to 50 days of brute-forcing without this flaw.

However, not all vendors used the vulnerable key generation algorithm (to our knowledge, 3Com never did), 40-bit keys aren't used much anymore, and there are tools that ensure proper 40-bit key generation. An example of such a tool is dwepkeygen, included as part of BSD-airtools. In addition, to crack WEP using wep_tools, a large (about 24 Gb) pcap-format dump file is required. Thus, although Newsham's comments are interesting and have their place in the history of wireless cryptanalysis, we do not recommend trying the attack he developed or using brute-forcing in general against 128/104-bit WEP keys used by modern wireless networks.

However if you have truly massive traffic dump files, trying a dictionary attack using wep_tools or dwepcrack could bring success. Even better, you can try your luck with a dictionary attack against a single captured data packet or limited-size traffic dumps using Wepattack.

The FMS Attack

The most common attack against WEP is Scott Fluhrer, Itsik Mantin, and Adi Shamir's (FMS) key recovery methodology discovered in 2001 (the original paper entitled "Weaknesses in the Key Scheduling Algorithm of RC4" ). As you already know, this attack was implemented first by the Wep_crack and then by AirSnort. For those interested in how the attack algorithms work, we present a brief explanation here. If you are already familiar with the FMS attack or aren't interested in the "theoretical" cryptanalysis, feel free to skip this section and move forward.

The FMS attack is based on three main principles:
  1. Some IVs set up RC4 cipher  the way it can reveal key information in its output bytes.
  2. Invariance weakness allows use of the output bytes to determine the most probable key bytes.
  3. The first output bytes are always predictable because they contain the SNAP header defined by the IEEE specification.
A WEP key can be defined as K=IV.SK where SK is the secret key. The RC4 operation in a nutshell is K=IV.SK ---> KSA(K) ---> PRNG(K) XOR data stream. The scheduling algorithm KSA(K) works in the following way:


Initialization:

  For i = 0 \x{2026} N - 1

    S[i] = i

  j = 0

Scrambling:

  For i = 0 \x{2026} N - 1

    j = j + S[i] + K[i mod l]

   Swap(S[i], S[j])


The PRNG works as:


Initialization:

  i = 0

  j = 0

Generation Loop:

  i = i + 1

  j = j + S[i]

  Swap(S[i], S[j])

  Output Z = S[S[i] + S[j]]

Some IVs initialize the PRNG the way the first byte in the stream is generated using a byte from the secret key. Because the first data byte that the PRNG output is XORed with is predictable (SNAP header), it is easy to derive the first PRNG byte. The values we can get from weak IVs are only true about 5 percent of the time; some are true about 13 percent of the time. Taking into account the key size, it takes six to eight million packets of analysis to determine the correct WEP key. The theoretical packets throughput maximum ("wire speed") on the throughput-comparable to 802.11b LAN 10Base-T shared Ethernet is 812 frames per second (frame size of 1,518 bits). If we divide 6,000,000 by 812 we will get about 7,389 seconds or just above 2 hours necessary to accumulate enough packets for efficient WEP cracking. However, as we will see, the reality is different.

The basic FMS attack comes down to searching for IVs that conform to the (A + 3, N - 1, X) rule, where A is the byte in the secret key you are cracking, N is the size of the S-box (256) and X is a random number. It is advised that the following equations are applied right after the KSA:


X = SB+3[1] < B+3

X + SB+3[X] = B+3


The main problem is that such an equation is dependent on the previous key bytes, so it must be applied to the entire packet dump for every key byte that is tested. In its classical form, the FMS attack tests only the first byte of the output because it is very reliable; we know that the first byte of the SNAP header is nearly always 0xAA.

An Improved FMS Attack

To bypass this problem and optimize the FMS attack, H1kari of Dasb0den Labs has analyzed the patterns of weak Ivs appearance and how they relate to the key bytes they rely on. As he pointed out in the "Practical Exploitation of RC4 Weaknesses in WEP Environments" article. a basic pattern present can be defined as follows:


Definitions:

    let x = iv[0]

    let y = iv[1]

    let z = iv[2]

    let a = x + y

    let b = (x + y) - z

  Byte 0:

    x = 3 and y = 255

    a = 0 or 1 and b = 2

  Byte 1:

    x = 4 and y = 255

    a = 0 or 2 and b = SK[0] + 5

  Byte 2:

    x = 5 and y = 255

    a = 0 or 3 and b = SK[0] + SK[1] + 9

    a = 1 and b = 1 or 6 + SK[0] or 5 + SK[0]

    a = 2 and b = 6

  Byte 3:

    x = 6 and y = 255

    a = 0 or 4 and b = SK[0] + SK[1] + SK[2] + 14

    a = 1 and b = 0 or SK[0] + SK[1] + 10 or SK[0] + SK[1] + 9

    a = 3 and b = 8

  Byte 4:

    x = 7 and y = 255

    a = 0 or 5 and b = SK[0] + SK[1] + SK[2] + SK[3] + 20

    a = 1 and b = 255 or SK[0] + SK[1] + SK[2] + 15 or

                  SK[0] + SK[1] + SK[2] + 14

    a = 2 and b = SK[0] + SK[1] + 11 or SK[0] + SK[1] + 9

    a = 3 and b = SK[0] + 11

    a = 4 and b = 10


The resulting distribution pattern would be similar to this:


Secret Key Byte

        0  1  2  3  4  5  6  7  8  9  a  b  c

              +     +     +     +     +     +

    0   8  16 16 16 16 16 16 16 16 16 16 16 16

    1   8     16 16 16 16 16 16 16 16 16 16 16

    2      16 8     16 16 16 16 16 16 16 16 16

  a 3         16 8  16    16 16 16 16 16 16 16

    4            16 8  16 16    16 16 16 16 16

  V 5               16 8  16 16 16    16 16 16

  a 6                  16 8  16 16 16 16    16

  l 7                     16 8  16 16 16 16 16

  u 8                        16 8  16 16 16 16

  e 9                           16 8  16 16 16

  s a                              16 8  16 16

    b                                 16 8  16

    c                                    16 8

    d                                       16

  8  - 8-bit set of weak ivs

  16 - 16-bit set of weak ivs

  +   - 2 additional x and y dependent 8-bit weak ivs


From this distribution a rough estimate of weak IVs per key byte can be derived. There are other means of deriving this value as outlined in the referenced article. However, the real catch is to find an algorithm that will allow filtering out weak IVs based on the secret key byte that they can attack. This can be done with an algorithm similar to this:


let l = the amount of elements in SK



i = 0

For B = 0 ... l - 1

  If (((0 <= a and a < B) or

   (a = B and b = (B + 1) * 2)) and

   (B % 2 ? a != (B + 1) / 2 : 1)) or

   (a = B + 1 and (B = 0 ? b = (B + 1) * 2 : 1)) or

   (x = B + 3 and y = N - 1) or

   (B != 0 and !(B % 2) ? (x = 1 and y = (B / 2) + 1) or

   (x = (B / 2) + 2 and y = (N - 1) - x) : 0)

    Then ReportWeakIV


Such methodology effectively reduces the search time for each key by at least 1/20, thus giving us the time necessary to crack WEP. Now you don't need to collect 6,000,000 packets or more; half a million packets could be sufficient! This is the improved FMS attack as implemented by BSD-airtools dwepcrack; read its source code to discover and learn more.

The practicality of WEP cracking attacks is still denied by many. There are statements that, for example, a home or SOHO WLAN will not generate enough traffic to collect a sufficient amount of weak or interesting IVs for the key compromise in a reasonable time period. You just saw a methodology that can significantly cut the necessary data collected and this methodology has been implemented in a security auditing tool since the year 2001! However, even if the most commonly used WEP cracking tool, AirSnort, is employed, the results can be less than encouraging for the few remaining WEP enthusiasts. In our experience it takes only 3,000 to 3,500 interesting IVs frames to break the WEP key for either 64-bit or 128-bit WEP keys using AirSnort. The only difference mentioned between cracking the keys of both sizes is the amount of time necessary to collect these frames. It took 10 to 20 percent more time to collect the necessary amount of interesting IVs frames to obtain a 128-bit key on a testing wireless network. Our record of breaking a 64-bit WEP with AirSnort is 1 hour 47 minutes on a point-to-point 802.11b link with one of the hosts flood pinging the other (approximately 300 packets per second). Such an attack required 107 minutes * 300 packets/second = 1,926,000 packets, much less than the 6,000,000 packets estimated theoretically. It could've been sheer luck, but would you base your network security on guesswork considering how lucky or unlucky an attacker might be?

On a large, corporate wireless network, 300 packets per second is neither unusual nor unexpected, especially with 802.11a and 802.11g standards offering higher bandwidth and network throughput. The presence of "chatty" network protocols (RIP, link-state routing protocols "hello" packets, spanning tree, HSRP, VRRP, NetBIOS, IPX RIP and SAP, AppleTalk, etc.) might dramatically decrease the time needed to crack WEP. It also generates wireless traffic even when no user activity is present. Imagine a large wireless Novell-based network running NetBIOS over IPX and using three Cisco routers with turned-on hot standby for failover resilience and enabled CDP (we have seen networks like this in the United Kingdom on several occasions). Such a network does not have to be the WLAN itself; leaking wired traffic on the wireless side is sufficient and we have frequently seen access points plugged directly into the switch or hub. Let's say there are 100 hosts on the network and no user activity present. In one hour, every host will generate approximately 1,200 NetBIOS keep-alives, 40 IPX RIPs, and 40 SAPs, and each router will send 1,200 HSRP Hello packets and 60 CDP frames if the defaults aren't changed (they rarely are), as well as the obvious 40 RIPs. Thus, the number of generated packets will be 100x(1,200+40+40) + 3x(1,200+60+40) = 131,900 packets per hour. Thus, accumulating the 2,000,000 packets necessary to crack WEP with AirSnort in our example will take approximately 15 hours. 

With dwepcrack as few as 500,000 packets might be needed, which translates into approximately 3 hours, 47 minutes, without a single user logged in! Remember that this network is both perfect and hypothetical. In reality, a Novell server might send more than one SAP in 90 seconds because a single SAP packet can advertise up to seven services and the server might run more. NLSP might be running and STP traffic could be present. We frequently find networks with system administrators completely unaware of the unnecessary and unused STP traffic on the network and some higher end switches and even wireless access points have STP enabled by default. Mind the traffic!

Finally, in some cases, old 802.11b cards use the same IV value or start counting IV numbers from 0 each time the card is initialized and increments these numbers by one. This also significantly cuts the time necessary to crack WEP.

How about cracking WEP on 802.11a networks? It is essentially the same. The only difference is that we aren't aware of decent 802.11a support on BSD and AirSnort will not work with ark_5k. However, you can save a pcap-format 802.11a traffic dump file obtained using an Atheros chipset card in the RFMON mode and tcpdump (or Kismet) and feed it to AirSnort or even dwepcrack (after booting into BSD). If you want real-time WEP cracking on an 802.11a network, use wepcrack and the power of at/crond as we have described. For example, you can pipe tcpdump output into prism-getIV.pl and then process the IVFile.log file with WEPCrack.pl.


Sunday, August 24, 2014

Google Analytics




Google Analytic is a free service. It generates detailed statistics about the visitors of a website or blog.

Why you need to Sign up to Google Analytics

  • You will be able to find and fix your broken links totally free of charge. Remember? Those pages that give you a 404 (or Not Found) error. Sites like http://www.xml-sitemaps.com will give you a free sitemap generation service, but it will require you to pay $5.00 fee to help you find out exact URLs of broken links found in your site or blog.
  • You will be able to get detailed statistics about your site's visitors
  •  Let you track the performance of your blog or website from one user-friendly interface
  • With its help you will attract more traffic and turn your visitors to your customers 
  • Helps you make site design improvement based on the analysis you get

Step By Step of joining Google Analytics

  1. Log in into Google Analytics http://google.com/analytics/.
  2. Click Create New Account
  3. If you do not have a Google account, click Sign Up to create one.
  4. If you already have a Google account, click Sign In to log in
  5. When you log in, your get three details namely, Sign Up for Analytics Site, Add Tracking Code and Learn Your Audience
  6. To start using Google analytics, click Sign up Now.
  7. Create New Account Form appears
  8. Enter these details
    • Account name, for example: myyouthcafe
    • Website's URL, for example: http://myyouthcafe.blogspot.in/
    • Time Zone
    • Industry Category
    • Data Sharing Settings
    • Tick Yes to agree to the User agreement
  9. Once you are through, just click Create Account. The account is created. The details of the account are: Property ID, Default URL, Tracking ID, Property Name, Website URL and Tracking status
  10. Once the account is created, you will be shown what you are tracking, the code to copy to your site. Highlight the code and copy it.
  11. Go to your blog and log in, Click Design. Click Template
  12. You should always backup your template before you make any changes. 
    • Click Backup/Restore
    • Click Download Full Template
    •  Click OK
  13.  Click Edit HTML
  14. Click Proceed
  15. Tick Expand Widget Templates
  16. Enter CTRL+F to find a tag
  17. Beside Find, type in
  • Paste the Google Analytic Code immediately before this tag
  • tag 
  • Click Save Template and then click Close. You have now added the Google Analytics code to your blogger blog
  • To ensure that you have successfully added the Google Analytics code to your blog goes to http://google.com/analytics/. Next to your blog's URL, it will say either Receiving Data (meaning you were successful) or Tracking Not Installed (meaning something has gone wrong). If it said Tracking Not Installed,  you can do the following:- check your reports for data, or you can use your WYSIWYG editor correctly, or you can use your browser's "View Page Source" feature to find the tracking code
  • If it said Receiving Data, then click on Edit to integrate Webmaster Tools data in Google Analytics. Choose your blog name, for example: http://myyouthcafe.blogspot.in/ and the click Save and OK.
  • Click Apply and the profile will be applied

  • You are now set to go for your precious reports!


    Friday, August 8, 2014

    Software Engineering and Computer Games Reference - The Windows keycodes

    The Windows keycodes

    It's important to know the keycodes if you want to make more sophisticated listeners. If you wanted to distinguish between the left and right versions of the Shift, Control, and Alt keys you would need to be actively checking these keys in each call to your cController::update method. You might write a cControllerLeftRight child class with an overridden update to do this.
    This is taken from the file winuser.h. The default set-up for keycodes is that for normal letters and numbers like 0 or Z, you don't use VK_0 and VK_Z, instead you use the traditional ASCII code symbols '0', 'Z', etc.
     
    /* 
    * Virtual Keys, Standard Set 
    */ 
    #define VK_LBUTTON       0x01 
    #define VK_RBUTTON       0x02 
    #define VK_CANCEL        0x03 
    #define VK_MBUTTON       0x04 
        /* NOT contiguous with L & RBUTTON */ 
    
    #define VK_BACK          0x08 
    #define VK_TAB           0x09 
    
    #define VK_CLEAR         0x0C 
    #define VK_RETURN        0x0D 
    
    #define VK_SHIFT         0x10 
    #define VK_CONTROL       0x11 
    #define VK_MENU          0x12 
    #define VK_PAUSE         0x13 
    #define VK_CAPITAL       0x14 
    
    #define VK_KANA          0x15 
    #define VK_HANGEUL       0x15  /* old name for compatibility */ 
    #define VK_HANGUL        0x15 
    #define VK_JUNJA         0x17 
    #define VK_FINAL         0x18 
    #define VK_HANJA         0x19 
    #define VK_KANJI         0x19 
    
    #define VK_ESCAPE        0x1B 
    
    #define VK_CONVERT       0x1C 
    #define VK_NONCONVERT    0x1D 
    #define VK_ACCEPT        0x1E 
    #define VK_MODECHANGE    0x1F 
    #define VK_SPACE         0x20 
    #define VK_PRIOR         0x21 
    #define VK_NEXT          0x22 
    #define VK_END           0x23 
    #define VK_HOME          0x24 
    #define VK_LEFT          0x25 
    #define VK_UP            0x26 
    #define VK_RIGHT         0x27 
    #define VK_DOWN          0x28 
    #define VK_SELECT        0x29 
    #define VK_PRINT         0x2A 
    #define VK_EXECUTE       0x2B 
    #define VK_SNAPSHOT      0x2C 
    #define VK_INSERT        0x2D 
    #define VK_DELETE        0x2E 
    #define VK_HELP          0x2F 
    
    /* VK_0 thru VK_9 should be ASCII '0' thru '9' (0x30 – 0x39) */ 
    /* VK_A thru VK_Z should be ASCII 'A' thru 'Z' (0x41 – 0x5A) */ 
    /* Unless you define them yourself, you can't use symbols VK_0, 
        VK_A, etc. in your code, and you must use '0', 'A', etc. 
        instead. To correct this, The Pop framework defines the 
        missing VK_0 through VK_9 and VK_A through VK_Z so you can in 
        fact use these symbols if you include controller.h. */ 
    
    #define VK_LWIN          0x5B 
    #define VK_RWIN          0x5C 
    #define VK_APPS          0x5D 
    
    #define VK_NUMPAD0       0x60 
    #define VK_NUMPAD1       0x61 
    #define VK_NUMPAD2       0x62 
    #define VK_NUMPAD3       0x63 
    #define VK_NUMPAD4       0x64 
    #define VK_NUMPAD5       0x65 
    #define VK_NUMPAD6       0x66 
    #define VK_NUMPAD7       0x67 
    #define VK_NUMPAD8       0x68 
    #define VK_NUMPAD9       0x69 
    #define VK_MULTIPLY      0x6A 
    #define VK_ADD           0x6B 
    #define VK_SEPARATOR     0x6C 
    #define VK_SUBTRACT      0x6D 
    #define VK_DECIMAL       0x6E 
    #define VK_DIVIDE        0x6F 
    #define VK_F1            0x70 
    #define VK_F2            0x71 
    #define VK_F3            0x72 
    #define VK_F4            0x73 
    #define VK_F5            0x74 
    #define VK_F6            0x75 
    #define VK_F7            0x76 
    #define VK_F8            0x77 
    #define VK_F9            0x78 
    #define VK_F10           0x79 
    #define VK_F11           0x7A 
    #define VK_F12           0x7B 
    #define VK_F13           0x7C 
    #define VK_F14           0x7D 
    #define VK_F15           0x7E 
    #define VK_F16           0x7F 
    #define VK_F17           0x80 
    #define VK_F18           0x81 
    #define VK_F19           0x82 
    #define VK_F20           0x83 
    #define VK_F21           0x84 
    #define VK_F22           0x85 
    #define VK_F23           0x86 
    #define VK_F24           0x87 
    
    #define VK_NUMLOCK       0x90 
    #define VK_SCROLL        0x91 
    /* 
    The following are left and right Alt, Ctrl and Shift virtual 
        keys.Used only as parameters to GetAsyncKeyState() and 
        GetKeyState(). No other API or message will distinguish left 
        and right keys in this way. 
    */ 
    #define VK_LSHIFT        0xA0 
    #define VK_RSHIFT        0xA1 
    #define VK_LCONTROL      0xA2 
    #define VK_RCONTROL      0xA3 
    #define VK_LMENU         0xA4 
    #define VK_RMENU         0xA5 
     
    Happy Coding!! 

    Thursday, August 7, 2014

    Python - Finding Codepoints

    Each Unicode character is identified by a unique codepoint. You can find information on character codepoints on official Unicode Web sites, but a quick way to look at visual forms of characters is by generating an HTML page with charts of Unicode characters. The script below does this:
    mk_unicode_chart.py
    # Create an HTML chart of Unicode characters by codepoint
    import sys
    head = 'Unicode Code Points\n' +\
           '\n' +\
           '\n

    Unicode Code Points

    ' foot = '' fp = sys.stdout fp.write(head) num_blocks = 32 # Up to 256 in theory, but IE5.5 is flaky for block in range(0,256*num_blocks,256): fp.write('\n\n

    Range %5d-%5d

    ' % (block,block+256)) start = unichr(block).encode('utf-16') fp.write('\n
         ')
        for col in range(16): fp.write(str(col).ljust(3))
        fp.write('
    ') for offset in range(0,256,16): fp.write('\n
    ')
            fp.write('+'+str(offset).rjust(3)+' ')
            line = '  '.join([unichr(n+block+offset) for n in range(16)])
            fp.write(line.encode('UTF-8'))
            fp.write('
    ') fp.write(foot) fp.close()

    Exactly what you see when looking at the generated HTML page depends on just what Web browser and OS platform the page is viewed on—as well as on installed fonts and other factors. Generally, any character that cannot be rendered on the current browser will appear as some sort of square, dot, or question mark. Anything that is rendered is generally accurate. Once a character is visually identified, further information can be generated with the unicodedata module:
     
    >>> import unicodedata
    >>> unicodedata.name(unichr(1488))
    'HEBREW LETTER ALEF'
    >>> unicodedata.category(unichr(1488))
    'Lo'
    >>> unicodedata.bidirectional(unichr(1488))
    'R'
    

    A variant here would be to include the information provided by unicodedata within a generated HTML chart, although such a listing would be far more verbose than the example above.