Ops's profileOperational SecurityPhotosBlogListsMore  |  Tools Help |
|
|
June 03 JavaScripts, Add-ons, Active X scripts, Viruses, Trojans and Worms... What do they all have in common?JavaScripts, Add-ons, Active X Scripts, Viruses, Trojans and Worms. What do they all have in common?
JavaScripts, Add-ons, Active X Scripts, Viruses, Trojans and Worms. What do they all have in common?
As of now over 45,000 Web sites have been hacked to redirect unwitting victims to another web site that tries to infect PCs with malicious software, according to security vendor Websense. The affected sites have been hacked to host JavaScript code that directs people to fake Google Analytics web site, which provides data for web site owners on a site's usage, then to another bad site. This was from Carl Leonard, threat research manager for Websense.Those web sites have likely been hacked via a SQL injection attack, in which improperly configured web applications accept malicious data and get hacked. Another possibility is that the FTP credentials for the sites have somehow been obtained by hackers, giving them access to the inner workings of the site. It appears the hackers are using automated tools to seek out vulnerable web sites.
The latest campaign underscore the success hackers have at hosting dangerous code on poorly secured web sites Once a user has been directed to the bogus Google analytics site, it redirects again to another malicious domain. That site tests to see if the PC has software vulnerabilities in either Microsoft’s' Internet Explorer browser or Firefox that can be exploited in order to deliver malware. If it doesn't find a problem there, it will launch a fake warning saying the computer is infected with malware and tries to get the user to willingly download a program that purports to be security software but is actually a Trojan downloader. Those fake security programs are often called "scareware" and don't work as advertised. As of last Friday, only four of 39 security software programs could detect that Trojan, although that's now likely changed as vendors such as Websense swap malware samples with other companies in order to improve overall Internet Security. Its not clear what the hackers are doing with the newly compromised PC's although it's possible they can be configured to send spam, become part of a botnet or have data stolen from them. The malicious domain serving up the malware is hosted in the Ukraine, the same region where notorious Russian Business Network (RBN) operated. RBN is a gang of cyber criminals involved in phishing campaigns and other malicious activity. That web site appeared to be down as of Tuesday afternoon. The RBN is thought to be inactive now. "Whether this is a part of that group or whether it's a copycat using some of the techniques that are similar to those used by the malware group in the past we are not quite certain yet," Leonard. "its very difficult to pinpoint the exact people behind this." Since so many web sites have been hacked to deliver the attack, it's nearly impossible to contact them all. Websense said the latest attacks don't appear to be related to Gumblar, a malware campaign under way last month. Gumblar resulted in at least 3,000 web sites getting infected with malicious code that scanned users computers for vulnerabilities in Adobe Systems software.Once on a PC, Gumblar steals FTP log-in credentials, using that information to help spread to other computers. It also commandeers a person's web browser and replaces Google search results with other dangerous links.
 Knowledge Is Power... ...Don't Have It Used Against You!
March 03 Intel "Atom"SAN FRANCISCO—In an ISSCC session this morning, Intel disclosed the first microarchitectural details of its forthcoming "Silverthorne" processor for ultramobile devices. The new chip, which I'll describe in this post, is Intel's first in-order x86 processor since the original Pentium and the architecture on which the semi giant will pin its ultramobile hopes. Packaging, process, and power
As we've seen in photos comparing Silverthorne to a penny, Intel's new chip is a tiny 25mm2. At only 47 million transistors (about 40 percent of that is a 512K, 8-way set associative L2 cache), it's also quite lean. By way of comparison, the 65nm Core 2 Duo (2MB cache) has around 290 million transistors. The Intel processor that comes closest to Silverthorne in transistor count is the Pentium 4, which had 42 million transistors in its 0.18 micron, 2001 launch incarnation.
Silverthorne's package is a miniscule 14x13mm2, and Intel claims that the device has a TDP of 2 watts at 2GHz on 1.0V. At lower speeds, the device gets down to 0.5 watts, but it's not clear how far down Intel will have to ratchet the clockspeed to get there.
Architecture overview Silverthorne is a 64-bit, multithreaded processor with a 16-stage, in-order pipeline. As you can see from the diagram below, instructions flow from the 32KB L1 I-cache into a set of fetch buffers, and from there into the decode unit. The processor's decode unit features two hardware decoders and one microcode decoder, and can decode up to two instructions per cycle.
Silverthorne block diagram. Source: Intel
The processor's front end can dispatch up to two instructions per cycle—from the same thread or from two different threads—into a set of per-thread instruction queues that can presumably collapse any decode- and branch prediction-related instruction bubbles.
On the instruction flow side, the back end of Silverthorne consists of two main clusters (I'd call them "blocks," but "clusters" is what Intel's diagrams use): a floating-point/vector cluster and an integer/address cluster. The floating-point cluster contains two floating-point/SIMD pipes (FP ADD and FP + SIMD MUL/DIV/PERM), and the integer cluster contains two integer/address/branch pipes (AGU/ALU/shift and AGU/ALU/jump). On the data flow side, the memory execution cluster contains two AGU pipes and the bus cluster contains the bus interface unit and the on-die, 512KB unified L2 cache.
Silverthorne's back end
All told, Silverthorne's back end has six pipelines to which the front-end's instruction queue can dispatch instructions at a rate of two per cycle. In this section, I'll zoom in on those pipelines and discuss them one at a time.
Silverthorne's integer cluster is pretty straightforward: two basic 64-bit ALU pipes, one of which also includes a shifter, and the other of which includes the jump execution unit. Neither of these pipes, however, handles multiply or divide operations; integer MUL and DIV operations are sent to the FP/SIMD cluster.
The FP/SIMD cluster consists of two pipes, both of which are fed by a 64-bit data path. One cluster is just a basic, 64-bit scalar floating-point ALU. The second pipe is the largest, most function-heavy pipe on the entire chip—it handles scalar multiplies and divides, both 32-bit and 64-bit, and it combines with the other FP pipe to handle all 128-bit vector operations.
The end result is that Silverthorne's FP/SIMD cluster can start two 64-bit operations or one 128-bit operation per cycle. Note that it's not clear to me whether 64-bit multiplies and divides are fully pipelined, so I don't know if it's possible to issue a 64-bit MUL/DIV (either integer or floating-point) and a 64-bit floating-point add in the same cycle.
Silverthorne micrograph. Source: Intel
FEC: front-end cluster (plus L1 instruction cache)
FPC: floating point cluster
IEC: instruction execution cluster
MEC = memory execution cluster (plus L1 data cache)
BIU = bus interface unit On the data side, the memory unit's two AGUs can do two address calculations per cycle; the 24KB L1 data cache is implemented as a register file with two read and two write ports. The bus cluster contains a frontside bus interface that can do 400 MT/s or 533 MT/s, and the 512KB on-die L2 cache with in-line error correction.
Conclusions When Silverthorne debuts later this year, Intel will offer multiple SKUs at TDP points that range from 0.5W to 2W and speeds that range from 1GHz to 2GHz. The different SKUs will also support the same platform-level technologies as the mainstream desktop parts; in other words, just as is the case with Intel's desktop and mobile lines, some Silverthorne products will support all of Intel's remote management and virtualization extensions, while others will have a more stripped-down feature set. Silverthorne will need all of the x86-specific feature-oriented help that it can get, because the competition is tough. It's also the same type of RISC-based competition that Intel already faced and vanquished in the commodity desktop, workstation, and server markets. Specifically, Silverthorne will face off against in-order and out-of-order cores from ARM, specifically the company’s Cortex A8 (in-order) and A9 (out-of-order, multicore) parts. ARM has made some pretty remarkable claims for the A9 in particular, suggesting that the processors will reach speeds north of 1GHz in the same 250mw power envelope as ARM11. In order to alleviate some of the power difference between its chips and ARM's, Intel has equipped Silverthorne with a new low-power state, called C6. When Silverthorne is in C6, the only components that it leaves turned on are the SRAM that saves the existing processor state and some circuitry that can wake up the processor again when it's needed. (Getting out of C6 takes about 100 microseconds.) Intel claims that their testing indicates that Silverthorne can spend as much as 90 percent of its time in C6; if that's true, then that will bring the chip's average power dissipation far below its stated TDP. So Intel is counting on a combination of sleep-enabled lower average power and support for the full, awesome expanse of the extended x86 instruction set architecture to make Silverthorne a compelling basis on which to build a generation of mobile internet devices. Having tried a few of Intel's Silverthorne-based prototypes, I must say that I wasn't particularly impressed. I own a Nokia N800 and an iPhone, both of which are ARM-based and both of which give a nearly complete Internet experience in a smaller form factor than Silverthorne will ever fit into. Indeed, at one point during a sit-down with Intel the rep told me that the warm, bulky prototype I was holding would give me the "full Internet in your pocket." I started chuckling, pulled out my iPhone, and said, "I already have that." He gamely responded that the iPhone's browser doesn't support Flash (in my opinion that's a feature, not a bug), but my point was made. So Silverthorne is really a transitional product; it's Intel's first, slightly awkward foray into a market that it intends to eventually dominate by doing what it always does, and that's produce ever smaller, cheaper, and faster chips that support the world's most popular ISA. This recipe may ultimately work for Intel in the embedded market the way that it has worked elsewhere, but that day won't come just yet. Ultimately, Silverthorne could be compelling for the Asus Eee PC form factor, and at 2GHz there's an outside possibility that it might find a home in a MacBook Air that's relatively underpowered, but has great battery life. But the MID form factor, at least in its Silverthorne combination, is dead on arrival. So Silverthorne is just the start of something, and to ARM, MIPS, and the other established chipmakers who currently own the embedded space, it's Intel's way of saying "game on." December 30 Go Wireless without WiFi... Really...Want to network your home office or business? Your first thought is wireless, and it's definitely an option. On the other hand, if you have the courage, you can crawl under the floorboards and drag wires from room to room, or pull the cable through the ceiling. There's a third alternative: Use your electrical wiring. The idea, known as HomePlug AV, is that you use power lines to move anything you'd normally transfer through a network -- data files, movies, TV and HDTV, music -- whatever. (You can learn about networks over power lines at the HomePlug Powerline Alliance.)
Actiontec's MegaPlug AV 200 Ethernet What's Cool About HomePlug AV I tried Actiontec's recently released MegaPlug AV 200 Mbps Ethernet Adapter Kit. Each PC, notebook, or other device you're planning to network needs a single adapter. The adapter is 2.25 inches wide, 3.25 inches tall, and about 2 inches thick. You can add up to 16 devices, way more than I'd ever need at Bass World headquarters. The kit comes with two MegaPlug Ethernet adapters, two Ethernet cables, and CDs with drivers. It costs a little over $130 on PC World's Product Finder.
The adapters plug right into an electric outlet I Have a Concern The other concern I had was how the MegaPlug gear would work in my office that's loaded with uninterruptible power supplies and filtered power strips. I worried that these devices -- or any device emitting an RF signal -- would have an impact on the MegaPlug units. It turns out that nothing seemed to bother the MegaPlug device. However, according to the Actiontec engineers, it's best if the MegaPlug devices are connected to wall outlets. Nonetheless, they can be plugged into a heavy-duty extension cord that's connected to the wall outlet; essentially, they'll work everywhere except in isolated, filtered, or suppressed outlets. Overall, I was able to add two MegaPlug adapters to my existing wired network in about 20 minutes and it worked as expected. Talkback
September 20 Why use Encryption?In cryptography, encryption is the process of obscuring information to make it unreadable without special knowledge. While encryption has been used to protect communications for centuries, only organizations and individuals with an extraordinary need for secrecy had made use of it. In the mid-1970s, strong encryption emerged from the sole preserve of secretive government agencies into the public domain, and is now employed in protecting widely-used systems, such as Internet e-commerce, mobile telephone networks and bank automatic teller machines. Encryption can be used to ensure secrecy, but other techniques are still needed to make communications secure, particularly to verify the integrity and authenticity of a message; for example, a message authentication code (MAC) or digital signatures. Another consideration is protection against traffic analysis. Encryption or software code obfuscation is also used in software copy protection against reverse engineering, unauthorized application analysis, cracks and software piracy used in different encryption or obfuscating software. Ciphers A cipher is an algorithm for performing encryption (and the reverse, decryption) — a series of well-defined steps that can be followed as a procedure. An alternative term is encipherment. The original information is known as plaintext, and the encrypted form as ciphertext. The ciphertext message contains all the information of the plaintext message, but is not in a format readable by a human or computer without the proper mechanism to decrypt it; it should resemble random gibberish to those not intended to read it. The operation of a cipher usually depends on a piece of auxiliary information, called a key or, in traditional NSA parlance, a cryptovariable. The encrypting procedure is varied depending on the key, which changes the detailed operation of the algorithm. A key must be selected before using a cipher to encrypt a message. Without knowledge of the key, it should be difficult, if not impossible, to decrypt the resulting ciphertext into readable plaintext. "Cipher" is alternatively spelled "cypher"; similarly "ciphertext" and "cyphertext", and so forth. The word descends from the Arabic word for zero: cifr or صِفْر, like (the Italian) zero (which remained in use for 0, the crucial innovation in positional Arabic versus Roman numerals) but soon was used for any decimal digit, even any number. There are also etymological roots to the Middle French word cifre, and the Medieval Latin cifra, both of which are probably originated from the Arabic root. While it may have come to mean encoding because that often involved numbers, a theory says conservative Catholic opponents of the Arabic ("heathen") numerals equated it with any "dark secret." In non-technical usage, a "(secret) code" is the same thing as a cipher. Within technical discussions, however, they are distinguished into two concepts. Codes work at the level of meaning — that is, words or phrases are converted into something else and this chunking generally shortens the message. Ciphers, on the other hand, work at a lower level: the level of individual letters, small groups of letters, or, in modern schemes, individual bits. Some systems used both codes and ciphers in one system, using superencipherment to increase the security. Robert Anton Wilson mentions this distinction in his work The Illuminatus! Trilogy. Historically, cryptography was split into a dichotomy of codes and ciphers, and coding had its own terminology, analogous to that for ciphers: "encoding, codetext, decoding" and so on. However, codes have a variety of drawbacks, including susceptibility to cryptanalysis and the difficulty of managing a cumbersome codebook. Because of this, codes have fallen into disuse in modern cryptography, and ciphers are the dominant technique. Types of cipher There are a variety of different types of encryption. Algorithms used earlier in the history of cryptography are substantially different from modern methods, and modern ciphers can be classified according to how they operate and whether they use one or two keys. Historical pen and paper ciphers used in the past are sometimes known as classical ciphers. They include substitution ciphers and transposition ciphers. During the early twentieth century, more sophisticated machines for encryption were used, rotor machines, which were more complex than previous schemes. Encryption methods can be divided into symmetric key algorithms (Private-key cryptography) and asymmetric key algorithms (Public-key cryptography). In a symmetric key algorithm (e.g., DES and AES), the sender and receiver must have a shared key set up in advance and kept secret from all other parties; the sender uses this key for encryption, and the receiver uses the same key for decryption. In an asymmetric key algorithm (e.g., RSA), there are two separate keys: a public key is published and enables any sender to perform encryption, while a private key is kept secret by the receiver and enables only him to perform decryption. Symmetric key ciphers can be distinguished into two types, depending on whether they work on blocks of symbols of fixed size (block ciphers), or on a continuous stream of symbols (stream ciphers). Key size and vulnerability In a pure mathematical attack (i.e., lacking any other information to help break a cypher), three factors above all, count: Mathematical advances, that allow new attacks or weaknesses to be discovered and exploited. Computational power available, i.e. the computer power which can be brought to bear on the problem. Key size , i.e., the size of key used to encrypt a message. As the key size increases, so does the complexity of brute search to the point where it becomes infeasible to crack encryption directly.Since the desired effect is computational difficulty, in theory one would choose an algorithm and desired difficulty level, thus decide the key length accordingly. An example of this process can be found at keylength.com which uses multiple reports to suggest that a symmetric cypher with 128 bits, an asymmetric cypher with 3072 bit keys, and an elliptic curve cypher with 512 bits, all have similar difficulty at present. September 16 Is your network Secure?If you just set up a wireless network in your home without securing it, you're just asking for trouble. Neighbors or passersby can connect in seconds. Worse, Wi-Fi freeloaders may use your connection for illegal activities. When the police come knocking, it'll be on your door. Your connection could also be used to send spam. If so, your Internet service provider will likely cut you off. Then there's the data you transmit over the Internet. It's easy to intercept data on an unsecured network. Free tools let anyone hopping on your network capture every keystroke that you make. Or, how about the man-in-the-middle attack? This is a complex undertaking. A hacker configures his computer to act as the router. Your computer connects to the hacker's, which connects to the Internet. All your data passes through the hacker's computer. These are scary scenarios, but you can avoid them by securing your network. Your wireless router probably came with security disabled, so you must set it up. Consult your router's manual to learn how to access its settings. Most importantly, enable wireless encryption. You must also enable encryption on all computers that connect wirelessly. There are three flavors of encryption. First, there's WEP (wired equivalent privacy), WPA (Wi-Fi protected access) and WPA2, the second generation of WPA. It is also referred to as 802.11i. Don't confuse that with networking protocols like 802.11a/b/g. WEP is an early encryption method. It is worthless; an expert can break it in minutes. Countless people still use it, thinking they are secure. Several years ago, wireless experts recognized WEP's fatal flaws. They started work on a new standard that eventually became WPA2 (802.11i). In the meantime, equipment manufacturers used WPA, a transitional standard. This is similar to WPA2, but uses a less secure form of encryption. According to the Wi-Fi Alliance, an industry body, WPA has never been broken. However, some security pros say it can be broken. They say the trick is a password of less than 21 characters. So, if you have WPA, err on the side of caution and use a really long password. WPA2 is the way to go. It uses advanced encryption standard, or AES, which is used by the federal government. Given the power of today's computers, it is unbreakable. That is, assuming you use a good password. Your password should have upper- and lowercase letters and numbers. Also include symbols, if possible. Do not use a word, your dog's name or other obvious choices. And do not use the default password. Every crook in town knows it. What do you do with old equipment? You may be able to upgrade WEP products to WPA2. Check the manufacturer's website. If you cannot upgrade, buy new gear. WEP equipment is dangerous. A wireless router should cost $50 or less. Wireless cards are about $30. Before you buy equipment, ensure it is certified by the Wi-Fi Alliance (<http://certifications.wi-fi.org/wbcs_certified_products.php>). Pay close attention to certification details. They should say specifically that a product has WPA2. Traditionally, security-conscious people have taken other actions to protect their systems. For instance, they would disable the service set identifier (SSID) broadcasting. The SSID identifies your network to other computers. So, turning off broadcasting was intended to hide the system. However, this won't work. A knowledgeable intruder will find your network.
Knowledge is Power! Op.Sec September 13 RC4 Weaknesses in WEP Environments1. Introduction This document will give a brief background on 802.11b based WEP weaknesses and outline a few additional flaws in rc4 that stem off of the concepts outlined in "Weaknesses in the Key Scheduling Algorithm of RC4" (FMS) and "Using the Fluhrer, Mantin, and Shamir Attack to Break WEP" (SIR) and describes specific methods that will allow you to optimize key recovery. This document is provided as a conceptual supplement to dweputils, a wep auditing toolset, which is part of the bsd-airtools package provided by Dachb0den Labs. The basic goal of the article is to provide technical details on how to effectively implement the FMS attack so that it works efficiently with both a small amount of iv collection time as well as cracking and processing time and to provide details on how other pseudo random generation algorithm (prga) output bytes reveal key information. 2. Background WEP is based on RSA's rc4 stream cipher and uses a 24-bit initialization vector (iv), which is concatenated with a 40-bit or 104-bit secret shared key to create a 64-bit or 128-bit key which is used as the rc4 seed. Most cards either generate the 24-bit iv using a counter or by using some sort of pseudo random number generator (prng). The payload is then encrypted along with an appended 32-bit checksum and sent out with the iv in plaintext as illustrated: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 802.11 Header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV[0] | IV[1] | IV[2] | Key ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . . . . SNAP[0] . . . . . | . . . . . SNAP[1] . . . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . . . . SNAP[2] . . . . . | . . . . Protocol ID . . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | | . . . . . . . . . . . . . Payload . . . . . . . . . . . . . . | | . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . . . . . . . . . 32-bit Checksum . . . . . . . . . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . - denotes encrypted portion of packet After the data is sent out, the receiver simply concatenates the received iv with their secret key to decrypt the payload. If the checksum checks out, then the packet is valid. 2.1. Current Cracking Methods Essentially, most of the wep attacks out there these days are either based on brute forcing methods, often times including optimizations based on how the key is generated or by using a wordlist, or through statistical analysis of initialization vectors (ivs) and their first rc4 output byte, to setup conditions in the rc4 key scheduling algorithm (ksa) that reveal information about particular bytes in the secret key. 2.1.1. Brute Forcing Brute forcing has been proven to be an effective method of breaking wep, mainly thanks to all of the work done by Tim Newsham. This method basically consists of trying to decrypt the encrypted payload of a captured 802.11b packet using a set of keys and verifying the validity by seeing if the 32-bit checksum checks out. In most cases, if the key checks out it is important to check it with another packet to make sure the key is actually valid, since many times the packet can be decrypted with an invalid key and the checksum will be valid. This mode of attack generally only requires 2 packets. Tim Newsham's most effective cracking method stems off of the weaknesses in the password based key generation algorithm used by most 40-bit cards and access points. By taking advantage of this weakness, it reduces the 40-bit keyspace down to 21-bit, which is trivial to crack (20-40 seconds with most current-day machines). Also, wordlist attacks prove almost equally effective on both 40-bit and 104-bit 802.11b networks, provided you have a decent list of commonly used passphrases. Even without using these optimizations, you can still exhaust the entire 40-bit keyspace in roughly 45-days on a decent machine, or in a very reasonable amount of time using a distributed network of machines. Although this mode of attack can be applied to many networks out there, it fails to be able to attack a properly secured 104-bit network, since the amount of time required to brute force 104-bit is generally longer than an attacker's great-grandchildren would want to wait. 2.1.2. FMS Attack Up until now, all open source wep cracking utilities that use the FMS Attack have used an extremely limited mode of operation as described in FMS in Section 7.1 "IV Precedes the Secret Key", and is also published by Wagner in Wag95, which involves only looking for ivs that match: (A + 3, N - 1, X) This is a particular condition that works almost all of the time and is not dependent on the preceding keys. However, as described later on in FMS in Section A "Applying The Attack to WEP-like Cryptosystems", they recommend that you use the following equation on the S permutation immediately after the KSA to determine if an iv is weak: X = S{B + 3}[1] < B + 3 X + S{B + 3}[X] = B + 3 This equation uncovers many more ivs than the 256 per key that most implementations currently use. This was made obvious in SIR in Section 4.1 "Choosing IVs", but wasn't thoroughly expanded on about how to effectively use a pool of logged ivs to successfully perform this attack in a reasonable amount of time. The main dilemmas with applying this equation to all of the IVs that you collect are that you have to check all of your logged ivs at least once for every key byte that you try, and that it takes a considerable amount of resources to apply this algorithm to a set of 2,000,000 ivs. So, not only do you have to do a large amount of processing, but also for an extremely large set of possibilities. Also, all of the current implementations only attack the 1st rc4 output byte, mainly because it is the one that provides the most accurate information about the key bytes. However, by attacking the other bytes, it can also provide clues, although minute, to the static key that was used. This can sometime provide enough statistical data to derive key bytes in cases when you aren't able to collect a large amount of captured data, and have more time to spend processing. 3. Additional Flaws in the KSA The main flaw with rc4 that hasn't been thoroughly expanded, is using information provided by other bytes in the prga output stream. This attack is similar to the FMS attack, but requires additional processing because you have to also emulate portions of the pseudo random generation algorithm (prga) to determine if an iv gives out key information in byte A. However, the bytes that you can attack using this method directly depend on the bytes of the key you have already recovered and are extremely hard to predict without excessive processing. To demonstrate this, I will first provide background on the current common mode of attack which attacks the first output byte and then show how it can be expanded to other bytes. 3.1. Attacking the First Byte The first byte attack works based on the fact that you can simulate part of the ksa using the known iv and derive the values of elements in the S permutation that will only change 1 - (e ** -X) of the time, where X is the number of S elements that your attack depends on. This can be illustrated as follows when attacking the first byte in the secret key (SK): Definitions: KSA(K) Initialization: For i = 0 ... N - 1 S[i] = i j = 0 Scrambling: For i = 0 ... N - 1 j = j + S[i] + K[i mod l] Swap(S[i], S[j]) PRGA(K) 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]] - For demonstration purposes N = 16, although it is normally 256 - Also, all addition and subtraction operations are carried out modulo N and negative results are added with N so results are always 0 <= x < N. Simulation: let B = 0 - byte in K that we are attacking let IV = B + 3, f, 7 let SK = 1, 2, 3, 4, 5 let K = IV . SK let l = the amount of elements in K assume that no S elements get swapped when i > B + 3 KSA - K = 3, f, 8, 1, 2, 3, 4, 5 Known Portion: 0 1 2 3 4 5 6 7 8 9 a b c d e f j S[i] K 3 0 i = 0, j = 0 + 0 + 3 = 3 0 1 i = 1, j = 3 + 1 + f = 3 d 2 i = 2, j = 3 + 2 + 8 = d Unknown Portion: f 1 i = 3, j = d + 1 + 1 = f - Note that S[B + 3] always contains information relating to SK[B], since SK[B] is used to calculate j. PRGA - S = 3, 0, d, f, 4, 5, 6, 7, 8, 9, a, b, c, 2, e, 1 Unknown Portion: 0 1 2 3 4 5 6 7 8 9 a b c d e f j S[i] S[i] S[j] 3 0 d f 4 5 6 7 8 9 a b c 2 e 1 Unknown KSA Output 0 3 i = 1, j = 0 + 0 = 0, z = S[0 + 3] = f In this instance, f will be output as the first PRGA byte, which is in turn xor'ed with the first byte of the snap header. The first byte of the snap header is almost always 0xaa, so we can easily derive the original f by simply xor'ing the first byte in our encrypted payload with 0xaa. To reverse the f back into the first byte of the SK that was used to generate it, we just iterate through the KSA up until the point where we know the j and S[i] values that were used to derive the f as provided in the previous demonstration. Once the j and S[i] values are derived, we can easily reverse it to SK[B] as illustrated: Definitions: let S{-1}[Out] be the location of Out in the S permutation let Out be z in the first iteration of the PRGA assume values in Known Portion of KSA from where i = 2 SK[B] = S{-1}[Out] - j - S[i + 1] Application: SK[B] = S{-1}[f] - c - S[3] = f - d - 1 = 1 This method provides us with the correct key roughly e ** -3 =~ 5% of the time, and sometimes e ** -2 =~ 13% of the time in some cases when we only rely on 2 elements in the S permutation staying the same. As you can see in the ksa and prga simulation above, we only rely on elements 0, 1, and 3 not changing for the output byte to be reliable, so the probability of our output byte being f is 5%. By collecting many different SK[B] values the correct SK[B] values should become more evident as more data is collected. Additionally, once we determine the most probable value for the first byte in the secret key, we can apply the same algorithm to cracking the next byte in the secret key, and continue until we have cracked the entire secret key. In most implementations this method is combined with brute forcing so the odds don't have to be perfect in order to recover the key. 3.2. Attacking Additional Output Bytes This section will demonstrate a set of new unique ivs that provide clues to various bytes in the secret key and in some cases with greater probability than the first bytes. I will first demonstrate what happens when rc4 encounters one of these ivs, and then provide methods for detecting them. 3.2.1. RC4 Encounters a 2nd-Byte Weak IV In this demonstration, I will use a weak iv that attacks the 2nd byte and show how certain ivs setup the S permutation so that secret key information is revealed in the 2nd byte of output. This method also applies to other output bytes and can be expanded depending on which secret key byte you are attacking. Here is what happens: Simulation: let B = 0 - byte in K that we are attacking let IV = 4, c, c let SK = 1, 2, 3, 4, 5 let K = IV . SK assume that no S elements get swapped when i > B + 3 KSA - K = 4, c, c, 1, 2, 3, 4, 5 Known Portion: 0 1 2 3 4 5 6 7 8 9 a b c d e f j S[i] K 4 0 i = 0, j = 0 + 0 + 4 = 4 1 i = 1, j = 4 + 1 + c = 1 f 2 i = 2, j = 1 + 2 + c = f Unknown Portion: 3 i = 3, j = f + 3 + 1 = 3 PRGA - S = 4, 1, f, 3, 0, 5, 6, 7, 8, 9, a, b, c, d, e, 2 Unknown Portion: 0 1 2 3 4 5 6 7 8 9 a b c d e f j S[i] S[i] S[j] 4 1 f 3 0 5 6 7 8 9 a b c d e 2 Unknown KSA Output 1 i = 1, j = 0 + 1 = 1, z = S[1 + 1] = f f 4 i = 2, j = 1 + f = 0, z = S[f + 4] = 3 Then, since we also often times know that the second byte of the snap header is 0xaa, we can determine the 2nd byte of prga output and reverse it back to the original key, as demonstrated: SK[B] = S{-1}[3] - f - S[3] = 3 - f - 3 = 1 As you can see, this particular iv will setup the ksa and prga so that the second output byte provides information about the first byte of our key in almost every situation. Additionally, it relies on elements 0, 1, 2, and 3 not changing for the second byte to be accurate, so it will only be correct e ** -4 =~ 2% of the time. Additionally, in cases where the previous output bytes are derived from dependent elements, we can check to see if the actual outputted byte matches up and determine if the output we are receiving has been tampered with. In addition, if the output matches up, it greatly increases our odds since we now rely on less elements. In this particular case, if the first output byte checked out, it would increase our probability with the 2nd byte to e ** -2 =~ 13%. 3.2.2. Finding Weak IVs for Additional Output Bytes The main problem with attacking additional output bytes is determining if an iv will reveal part of the secret key in a particular output byte, and also determining if the probabilities are good enough to even consider it. How we can detect if an iv is vulnerable to this sort of attack is similar to the first byte attack, but it requires looping through the prga up until i = (A + 1) where A = the offset in the prga stream of the byte you know the value for. For each iteration of the prga loop, if there are any instances where j or i >= B + 3, we must discard the iv, since then we are relying on elements in the S permutation that will most likely change. This can be accomplished by modifying the prga algorithm so that it is similar to: PRGA(K) Initialization: For i = 0 ... N - 1 P[i] = 0 P[B + 3] = 1 i = 0 j = 0 Generation Loop: While i < A + 1 i = i + 1 j = j + S[i] If i or j >= B + 3 Then Fail Swap(S[i], S[j]) Output z = S[S[i] + S[j]] P[i] = 1 P[j] = 1 Verification: If S[i] + S[j] = B + 3 Then Success Probability Analysis: j = 0 For i = 0 ... N - 1 If P[i] > 0 Then j = j + 1 This algorithm also works almost identically to the equation for determining if an iv is vulnerable to the first byte attack and can be expanded to detecting ivs that reveal keys in any byte in the prga output. You can then weigh the probabilities and determine if it is worth considering. In tests, this method doesn't prove entirely useful, mainly due to the amount of processing that is required to determine if certain ivs have this property. Since each iv has to be checked for each previous secret key byte that you try, it would probably be most practical to manually derive a table of vulnerable ivs, so it doesn't require much work during key recovery. In most cases it'd be more practical to collect more ivs and only use the first bytes to perform key recovery, however in cases when you have a limited set of sample data, it could greatly reduce the time required for recovery. 4. Implementation This section will focus on practical methods for making use of all of the 1st byte weak ivs without hindering performance. It will also cover optimizations for applying brute forcing and fudging methods to greatly reduce cracking time. The result of the optimizations will allow you to perform key recovery with only 500,000-2,000,000 packets and < 1 minute processing time. Although, in SIR it is mentioned that they were able to crack wep with a similar number of packets, this mode of attack does not require that the wep key be ascii characters, and isn't dependent on what key generator the victim used. 4.1. Filtering Weak IVs The main problem with attacking wep using all of the first byte weak ivs, is that the equation specified in FMS has to be applied to each of the ivs for every key that you try. Since often times you'll have a total of 2,000,000 packets that you've collected and thousands of keys you need to try before you find the correct one. It has thus far been impractical to use this mode of attack, since it requires a large amount of memory as well as resources. The way I have managed to get around this dilemma is by analyzing the patterns of weak ivs and how they are related to the key bytes they rely on. This is the basic pattern that I've found. 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 This pattern can then be easily expanded into an equation that covers a range independent of what SK values you have. As a result, you have distribution pattern similar to the one shown below: 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, we can determine a rough estimate of how many total weak ivs exist for each key byte. It can also be determined using the following equation: let ? : be conditional operators let MAX(x, y) be x > y ? x : y ((B mod 2 ? MAX(B - 2, 0) + 2 : B + 1) * (2 ** 16)) + (((B mod 2 ? 0 : 2) + (B > 1 ? 1 : 0) + 1) * (2 ** 8)) However, our real objective is to determine an algorithm that allows us to filter out weak ivs based on the secret key byte that they can attack, so that we can narrow our 2,000,000 element table down to a reasonable size that's easier to search. This can be accomplished by using a simple algorithm similar to: 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 This algorithm results in catching the following distribution of ivs: Byte # of IVs Probability 0 768 0.00004578 1 131328 0.00782776 2 197376 0.01176453 3 197120 0.01174927 4 328703 0.01959223 5 328192 0.01956177 6 459520 0.02738953 7 459264 0.02737427 8 590592 0.03520203 9 590336 0.03518677 a 721664 0.04301453 b 721408 0.04299927 c 852736 0.05082703 Which should differ slightly from the previous weak iv estimation equation since some ivs in the pattern overlap. By sorting these IVs into tables, you can very easily narrow down the amount of ivs to search for each cracking operation to a maximum of 852,736 ivs, or around only 101,654 when supplied with a 2,000,000 packet capture file. This effectively reduces the search time for each key by at least 1/20. 4.2. Fudging When trying to recover keys using a capture file that doesn't statistically provide enough immediate information to determine the secret key, it is common to perform a brute force based on the most probable key bytes. Up until now the fudge, or breadth, has been implemented as a static number that specifies the range to search for each key byte. However, with > 2,000,000 samples and a large amount of weak ivs for each byte the probability that the correct key will be the most probable gets greater as you traverse through each byte. A estimate of the probabilities for this are outlined below: Byte # of IVs Probability 0 768 0.00004578 1 768 0.00004578 2 2304 0.00013732 3 1792 0.00010681 4 3072 0.00018311 5 2560 0.00015259 6 4096 0.00024414 7 3584 0.00021362 8 5120 0.00030518 9 4608 0.00027466 a 6144 0.00036621 b 5632 0.00033569 c 6656 0.00039673 Therefore, when attempting to brute force based on a 2,000,000 sample set, your IVs will most likely be near: Byte # of IVs # of Correct Keys 0 92 5 1 92 5 2 275 14 3 214 11 4 366 18 5 305 15 6 488 24 7 427 21 8 610 30 9 549 27 a 732 36 b 671 33 c 793 39 Therefore, it's most likely that once you reach byte 2, the key that seems most probable, most likely is. This means that fudging is most likely not required, or at the least should be reduced, the farther you move through the bytes. This reduces the brute forcing time required considerably, since now it is only necessary to fudge the first few bytes of the key, and the rest is no longer necessary. I have found in most cases, because of this property of weak ivs, it requires quite less packets than 2,000,000 to recover the key, and in some cases you don't even require any statistics for the first couple bytes of the secret key to perform this attack in a very reasonable amount of time. 5. Results Using the outlined modifications, I've managed to crack wep using between 500,000 and 2,000,000 packets in under a minute, this is mainly due to the time required for reading in the packets. Here is an example of a successful attack using quite less than the 60 required ivs and only ~ 500,000 packets: h1kari@balthasar ~/bsd-airtools/dweputils/dwepcrack$ ./dwepcrack -w ~/log reading in captured ivs, snap headers, and samples... done total packets: 500986 calculating ksa probabilities... 0: 22/768 keys (!) 1: 3535/131328 keys (!) 2: 5459/197376 keys (!) 3: 5424/197120 keys (!) 4: 9313/328703 keys (!) (!) insufficient ivs, must have > 60 for each key (!) (!) probability of success for each key with (!) < 0.5 (!) warming up the grinder... packet length: 44 init vector: 58:f7:26 default tx key: 0 progress: .................................... wep keys successfully cracked! 0: xx:xx:xx:xx:xx * done. 6. Conclusions The best solution for securing your wireless networks is using traditional wireless security to its fullest, but not relying on it. Manually enter in your wep keys and don't use the key generator (or use dwepkeygen ;-Q), change your wep keys frequently, use mac filtering and shared key authentication, and label your wireless network as untrusted (and no, I don't necessarily mean set your ssid to "untrusted"). Wireless networks, just like any other networks, are proportionately insecure to the stupidity of the person managing them. References [1] Fluhrer, S. Mantin, I. and Shamir A. - Weaknesses in the Key Scheduling Algorithm of RC4. [2] Stubblefield, A. Ioannidis, J. and Rubin, A. - Using the Fluhrer, Mantin, and Shamir Attack to Break WEP [3] Newsham, T. - Cracking WEP Keys. Presented at Blackhat 2001. Knowledge is Power!
Op.Sec
September 09 What is the Clipper Chip? CLIPPER CHIP TECHNOLOGY
CLIPPER is an NSA developed, hardware oriented, cryptographic device that implements a symmetric encryption/decryption algorithm and a law enforcement satisfying key escrow system. While the escrow management system design is not completely designed, the cryptographic algorithm (SKIPJACK) is completely specified (and classified SECRET). The cryptographic algorithm (called CA in this paper) has the following characteristics: 1. Symmetric, 80-bit key encryption/decryption algorithm; 2. Similar in function to DES (i.e., basically a 64-bit code book transformation that can be used in the same four modes of operation as specified for DES in FIPS 81); 3. 32 rounds of processing per single encrypt/decrypt operation; 4. Design started by NSA in 1985; evaluation completed in 1990. The CLIPPER CHIP is just one implementation of the CA. The CLIPPER CHIP designed for the AT&T commercial secure voice products has the following characteristics: 1. Functions specified by NSA; logic designed by MYKOTRONX; chip fabricated by VLSI, Inc.: manufactured chip programmed (made unique) by MYKOTRONX to security equipment manufacturers willing to follow proper security procedures for handling and storage of the programmed chip; equipment sold to customers; 2. Resistant to reverse engineering against a very sophisticated, well funded adversary; 3. 15-20 MB/S encryption/decryption constant throughout once cryptographic synchronization is established with distant CLIPPER Chip; 4. The chip programming equipment writes (one time) the following information into a special memory (called VROM or VIA-Link) on the chip: a. (unique) serial number b. (unique) unit key c. family key d. specialized control software 5. Upon generation (or entry) of a session key in the chip, the chip performs the following actions: a. Encrypts the 80-bit session key under the unit key producing an 80-bit intermediate result; b. Concatenates the 80-bit result with the 25-bit serial number and a 23-bit authentication pattern (total of 128 bits); c. Enciphers this 128 bits with family key to produce a 128-bit cipher block chain called the Law Enforcement Field (LEF); d. Transmits the LEF at least once to the intended receiving CLIPPER chip; e. The two communicating CLIPPER chips use this field together with a random IV to establish Cryptographic Synchronization. 6. Once synchronized, the CLIPPER chips use the session key to encrypt/decrypt data in both directions; 7. The chips can be programmed to not enter secure mode if the LEF field has been tampered with (e.g., modified, superencrypted, replaced); 8. CLIPPER chips will be available from a second source in the future; 9. CLIPPER chips will be modified and upgraded in the future; 10. CLIPPER chips presently cost $16.00 (unprogrammed) and $26.00 (programmed). Knowledge is Power!
Op.Sec
|
|
|
