[SecurityRatty] tag: rc4

Underhanded Implementation of RC4

Fri, 20 Jun 2008 02:56:23 +0000

A runner-up in last year's Underhanded C Contest was a flawed implementation of RC4 that eventually just passed plaintext through unencrypted. Plausibly deniable, and very clever.

The other winners are also clever.

The Small Pack Web Malware Exploitation Kit

Sun, 18 May 2008 23:41:55 +0000

Yet another proprietary web malware exploitation kit has been released at the beginning of this month, further indicating that the efficient supply of such kits is proportional to their simplistic nature. The only differentiation factor in the Small Pack is perhaps the inclusion of all known Opera exploits up to version 9.20, however, the rest of the features are the natural ones included in the majority of already known exploitation kits :

- IE exploits included - Quick TIme Modified, PNG, MDAC, DX Media
- Firefox exploits included - Quick Time, PNG, EMBED
- Opera - all exploits up to version 9.20
- RC4 encryption
- lifetime updates
- Geolocation
- opportunity to request additional functions

Converging infection and distribution vectors, evasion and survivability, metrics and command and control in a single all-in-one web malware exploitation kits is, however, is definitely in the works considering the developments introduced in the rest of the kits currently available. For instance, despite that the ongoing waves of SQL injection attacks with multiple campaigns are injecting the malicious domains in its original form, certain attacks are starting to inject obfuscated URLs making it harder to assess the impact of the campaign using open source intelligence techniques.

The bottom line, as long as webmasters continue participating in the so called "traffic exchange" revenue models, knowingly or unknowingly embedding links that would later on ultimately redirect to a malicious site, "traffic exchange" is receiving the most attention at the strategic level, next to "traffic acquisition" at the tactical level. Basically, the traffic inventory that could be supplied is the direct result of an ongoing SQL injection attack, or malware embedded through other means, with the traffic brokers directly undermining webmaster's unethical inclusion of exploits within their domains portfolio.

One thing's for sure - web malware exploitation kits are not just getting localized, they're also being cloned.

Related posts:
The FirePack Exploitation Kit Localized to Chinese
MPack and IcePack Localized to Chinese
The FirePack Exploitation Kit - Part Two
The FirePack Web Malware Exploitation Kit
The WebAttacker in Action
Nuclear Malware Kit
The Random JS Malware Exploitation Kit
Metaphisher Malware Kit Spotted in the Wild
The Black Sun Bot
The Cyber Bot
Google Hacking for MPacks, Zunkers and WebAttackers
The IcePack Malware Kit in Action

Changing the SSL cipher order in Internet Explorer 7 on Windows Vista

Wed, 07 Nov 2007 02:37:47 +0000

Recently, the question of using AES for SSL has come up in the newsgroups and at some conferences. When IE makes an HTTPS connection to a web server, it offers a list of cipher supported cipher suites. The server then selects the first one from the list that it can match. The default order that IE follows is this:

TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_RC4_128_MD5
SSL_CK_RC4_128_WITH_MD5
SSL_CK_DES_192_EDE3_CBC_WITH_MD5
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA

When you study the list, you'll see that IE presents the algorithms in decreasing order of strength, but places the shorter bit-lengths first. Why? If longer bit lengths are more secure, shouldn't they be listed first?

Remember, encryption is the thing that buys you time against Immutable Law #3. But performing encryption itself takes time. So when choosing an algorithm and a bit length, one important consideration is to ask yourself this question: "How long do I need for my secrets to remain secret?"

We configure IE to use shorter bit lengths -- but never shorter than 128 bits, except for the last two that use no encryption -- because it gives you better performance than the longer bit lengths. In almost all cases, a 128-bit key is more than sufficient to protect the information you're exchanging over HTTPS.

However, if you require something longer, and want to change the default, you can. Here's how.

Open your group policy editor by entering gpedit.msc at a command prompt.
Choose Computer Configuration | Administrative Templates | Network | SSL Configuration Settings.
There's only one item here: SSL Cipher Suite Order. Open it.
Select Enabled.
Now here's where you need to tread carefully. You'll see that the list is the same as above, but rather than formatted nicely with carriage returns, they're simply separated with commas. The first item in the list is:
TLS_RSA_WITH_AES_128_CBC_SHA
And the second item is:
TLS_RSA_WITH_AES_256_CBC_SHA
Cursor your way through the list. Change that first 128 to 256. Then cursor forward a bit more and change the 256 to 128.
Feel free to change other orders, too, but keep your changes within algorithm types.
OK your way out, close the group policy editor, and reboot.

Most of you probably won't need to do this -- I haven't. But for those who have regulatory requirements for using 256-bit AES, follow these steps and you'll be compliant.