Youth Adda

Exploring Information

Monday, October 20, 2014

Cisco LAN Switching - Configuring SNMP

Switches should be configured so that management stations can gather information via the Simple Network Management Protocol (SNMP). SNMP is used to gather statistics, counters, and tables in the Management Information Base (MIB) of a device.
The SNMP framework consists of three parts:
  • SNMP manager
  • SNMP agent
  • MIB
The SNMP manager is a host that monitors the activities of network devices using SNMP. The SNMP manager is typically referred to as the Network Management Station (NMS). The SNMP agent is software running on the device being monitored by the SNMP manager. A MIB is a virtual storage area for network management information consisting of collections of managed objects. MIBs are written in the SNMP MIB module language as defined in RFCs 2578, 2579, and 2580. SNMP agents can be configured to allow read-only or read-write access to the device. Management stations like CiscoWorks use the read-only functions of the agent to monitor the device, and can use the read-write functions of the agent to make changes to the device configuration. SNMP uses passwords called community strings to grant access to the SNMP agent. Access to the agents can be further limited via SNMP access lists.

 SNMP MIB information for each Cisco device can be found on

You should configure SNMP on each Cisco device to be monitored by NMS. A sample SNMP configuration is shown on SW1 in Example
Example:  Sample SNMP Configuration on SW1
SW1#config t

Enter configuration commands, one per line.  End with CNTL/Z.

SW1(config)#access-list 10 permit

SW1(config)#snmp enable

SW1(config)#snmp-server community alpha ro 10

SW1(config)#snmp-server community beta rw 10

SW1(config)#snmp-server contact John Smith (555)789-2653

SW1(config)#snmp-server location Denver Data Center

SW1(config)#snmp enable traps

SW1(config)#snmp trap-source lo0

After SNMP is configured on SW1, the statistics can be viewed using the show snmp command, as shown in as
Example :Output of show snmp Command on SW1
SW1#show snmp

Chassis: SAD050814BH

Contact: John Smith (555)789-2653

Location: Denver Data Center

0 SNMP packets input

    0 Bad SNMP version errors

    0 Unknown community name

    0 Illegal operation for community name supplied

    0 Encoding errors

    0 Number of requested variables

    0 Number of altered variables

    0 Get-request PDUs

    0 Get-next PDUs

    0 Set-request PDUs

0 SNMP packets output

    0 Too big errors (Maximum packet size 1500)

    0 No such name errors

    0 Bad values errors

    0 General errors

    0 Response PDUs

    0 Trap PDUs

SNMP logging: disabled
Happy Reading!! 

Labels: , , ,

Monday, September 15, 2014

Wireless Hack - Scan and Exploit Vulnerable Hosts on WLAN

This is an active phase of your attack. When the fourth step is reached, you should have gathered a large amount of helpful data that makes penetrating wireless peers, gateways, and sniffable wired-side hosts an easy task. Perhaps no penetration is needed, because you have already collected or cracked user passwords flowing across the network. Using the data gathered, you can select the most suitable hosts for a further attack aimed at obtaining administrator or root privileges on these hosts. At this stage you can perform active OS fingerprinting, port scanning, and banner grabbing to determine vulnerable services for further exploitation. Remember the golden rule of fingerprinting: Use several available techniques and analyze the results. The options include the following:
  • nmap -O
  • thcrut discover (uses improved nmap fingerprinting methodology)
  • Ettercap (press f/F over a host)
  • xprobe
  • xprobe2 (yes, this is a different tool)
  • (ARP-based OS fingerprinting)
  • sing (basic ICMP fingerprinting)
  • sprint and sprint-lite
  • tools that do fingerprinting via specific services if present (ldistfp, lpdfp telnetfp)
  • other tools available in the vast scope of the Internet
As to port scanning itself, nmap is everyone's all-time favorite. What kind of "hacking book" does not describe how to run nmap? Without going into the port scanning depths, here are our recommendations:
  • First try the zombie/idle scan with -sI. It might not work.
  • Check out the protocol scan (-sO). Try to do fingerprinting with -sO.
  • Proceed with -sN (null). Many firewalls and IDSs would not detect it (e.g., ipchains logging).
  • You can follow with -sF to be sure, but avoid Xmas (-sX).
  • If you haven't captured any useful data from these scans, the host is likely to be some form of Microsoft Windows. Use the half-connect scan (-sS).
Because we are on (W)LAN, there is another tool to consider: the Ghost Port Scan. Ghost Port Scan uses ARP poisoning to spoof both IP and MAC addresses of the scanning host on the LAN. The scanner is able to find IP addresses not in use on the LAN the attacker's host is connected to. Such a feature is used when no source IPs have been specified. The aim of this function is to avoid a potential DoS that could be caused by ARP poisoning. The scanner is quite flexible:

arhontus:~# ./gps

Ghost Port Scan version 0.9.0 by


Usage: ./gps -d target [-s host1[,host2/host3..]] [-t scan_type]

     [-v] [-r scan_speed] [-p first_port-last_port] [-k 0 | 1]

     [-e ping_port]  [-f t | o] [-i interface] [-S mac | ip]

     [-w window_size]

 -d target             :target host's IP/name

 -s host1[,host2/host3]:list of hosts we pretend to be

                      (use '/' to specify IP ranges)

 -t scan_type        :stealth scan mode (default: syn)

           (syn | xmas | null | fin | ack | rand | fwrd)

 -r scan_speed       :packet rate (default: insane)

           (insane | aggressive | normal | polite |


 -p first-last ports :port range to scan (default: 1-1024)

 -k 0 | 1            :scan well-known ports (default: 1)

 -e ping_port          :target port for a TCP ping (default: 80)

 -v                  :verbose (use twice for more verbose)

 -f t | o              :fragment IP datagrams (default: no frag)

           (t: tiny frags | o: frag overlapping)

 -i interface        :network interface to use

 -S mac | ip         :spoofing level (IP or ethernet/MAC;

           default: mac)

 -w window_size        :size of the emission window (default: 256


To grab banners the old-fashioned way, you can use telnet or netcat. However, your time (important on wireless) and effort can be saved if you use the following:
  • nmap+V (nmap patched by Saurik; try the -sVVV flag) or the latest version of nmap with novel banner fingerprinting -sV or -A flags
  • amap
  • THCrut
  • arb-scan
  • banshee (features command execution against the IP addresses scanned)
  • grabbb (very fast)
  • A variety of banner grabbers from the Men in Grey (MIG) group (very fast, but not necessarily accurate)
  • "Script kiddie" banner grabbers for the "hole of the month" (usually fast; probably started from banner grabbers for wu-ftpd versions)
As a security consultant, you can always use automated multipurpose security evaluation tools such as Nessus, but a real Black Hat is unlikely to employ these tools for stealth preservation reasons. Choose the tools you like for time-saving and personal reasons. Keep a large collection of exploit code and a long list of default passwords and dictionaries on your penetration testing laptop to save more time by avoiding browsing SecurityFocus, Packetstorm, and similar sites from the WLAN. Use Hydra and similar tools for remote password dictionary attacks and brute-forcing.

Happy Coding!!

Labels: , , ,

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:


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

    S[i] = i

  j = 0


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

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

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

The PRNG works as:


  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:


    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 and then process the IVFile.log file with

Labels: , , ,