Results 1 to 5 of 5
  1. #1
    Thailand Expat
    Mid's Avatar
    Join Date
    Aug 2007
    Last Online
    @
    Posts
    1,411

    HTTPS has been hacked

    Red alert: HTTPS has been hacked
    Roger A. Grimes
    September 26, 2011

    There's now a tool that exploits a flaw in SSL and TLS. Will the industry respond fast enough?



    Only a handful of exploits per decade reveal a vulnerability that is truly significant. Thai Duong and Juliano Rizzo's BEAST (Browser Exploit Against SSL/TLS) attack will rank among them because it compromises the SSL and TLS browser connections hundreds of millions of people rely on every day.

    BEAST cannot break the latest version of TLS -- the current standard based on SSL -- but most browsers and nearly all websites that support secure connections rely on earlier versions of the SSL and TLS protocols, which are vulnerable to BEAST attack. Browser vendors and websites that host secure connections are already scrambling to upgrade to TLS 1.1 or 1.2. How quickly that occurs depends on how many attacks occur in the wild.

    The BEAST tool, presented last Friday at the 2011 Ekoparty Security Conference in Argentina, made real a theoretical SSL/TLS vulnerability first documented 10 years ago. It allows an attacker with previous MitM (man-the-middle) access to compromise a user's SSL/TLS-protected HTTPS cookie. This would allow an attacker to hijack the victim's active HTTPS-protected session or listen in on the previously cryptographically protected network stream. (Download Duong and Rizzo's paper on the BEAST attack [pdf].)

    MitM attacks are fairly easy to do when the attacker and victim are located on the same local network (such as wireless networks, VPNs, or corporate LANs). Some hacking tools, such as Cain & Abel, make MitM attacks and network packet sniffing truly a click of a button.

    An old flaw turns critical

    BEAST takes advantage of the fact that versions of TLS and SSL prior to TLS 1.1 (often referred to as SSL 3.2) do not use an implicit random IV (initialization vector) with each subsequent data stream initiated in an HTTPS connection. This particular SSL/TLS flaw was first discussed at an OpenSSL development forum in 2002. It's similar to the cryptographic weakness found in the WEP protocol, which significantly weakened the protection of wireless networks.

    The flaw isn't new, but many defenders counted on the fact that creating the conditions necessary to exploit it were "nontrivial," a term that in cryptography circles means nearly impossible to accomplish. Duong and Rizzo, two accomplished vulnerability experts, figured it out.

    The BEAST tool works by creating additional "known" plaintext data blocks that are encrypted using known IVs. In cases of TLS 1.0/SSL 3.1 and earlier, RFC 2246 dictates that the IV of one packet or data stream is the last ciphertext block from the previous packet or data stream. This is inherently weak, because many of today's cryptographically protected data streams use cipher-block chaining, or CBC mode, for speed. In CBC mode, each block of plaintext is encrypted with information from the previous encrypted block. What makes each subsequent enciphered block unique (and uncrackable) from the previous block is a randomly generated IV. At least that's what is supposed to happen, but sometimes, as early versions of SSL and TLS (and WEP), it doesn't.

    BEAST uses JavaScript running in a victim's Web browser to initiate many different encrypted data blocks, each time knowing the IV and the plaintext that is being encrypted (in an appropriately designed encryption system, neither of these conditions should be possible as it gives the attacker far too much known information to crib from). This is known as a "block-wise adaptive chosen plaintext attack." This attack was first theorized against SSL/TLS in 2006 by Gregory V. Bard. It led to the formation of TLS 1.1 and is implemented in OpenSSL 0.9.6d and later.

    Unfortunately, TLS 1.1 and 1.2 versions are not enforced anywhere by default -- and to be effective, all other previous HTTPS protocols must be disallowed by at least one side of the connection. Most HTTPS-protected websites will probably not upgrade to TLS 1.1 or 1.2 for some time; if you upgrade your browser to TLS 1.1 and disallow any other type of connection, you will not be able to establish connections to most HTTPS hosts.

    TLS 1.1 browser support

    Only some of today's popular browsers currently support TLS 1.1, and even then, it may not be enabled by default. The latest versions of Microsoft Internet Explorer, Opera, and Windows versions of Safari support TLS 1.1 or 1.2. Google Chrome should have a fix out soon. For more detail, see Thierry Zoller's TLS/SSL Hardening & Compatibility Report 2011 (PDF).

    Most observers expect all current capable browsers will enable TLS 1.1 and 1.2 by default soon. Microsoft offers built-in cipher support through its Schannel mechanism as an inherent part of Microsoft Windows. Both Microsoft Internet Explorer (5 and later) and Apple Safari (running on Windows) use Schannel. Schannel currently only offers support for TLS 1.1 and 1.2 on Microsoft Windows 7/Windows Server 2008 R2 (and later). It is unknown what Microsoft plans to do regarding earlier versions of Windows.

    In current versions of IE, TLS 1.1 and 1.2 are available, but are not enabled by default. All readers with Internet Explorer should enable TLS 1.1 and 1.2 now. To enable in IE, from the menu choose Tools, Internet Options, and then the Advanced tab. Go to the bottom of the Settings options and enable TLS 1.1 and 1.2. Opera 10.x and later supports TLS 1.1 and 1.2.

    Unfortunately, you really aren't fully protected unless you disable all other HTTPS protocols prior to TLS 1.1 and 1.2. Although you can do this in IE and Opera, you'll quickly find out that most websites don't yet support the newer protocols. Some early website surveys are reporting less than 1 percent of HTTPS websites support TLS 1.1 or 1.2.

    Google Chrome, Mozilla Firefox, and Safari running on Mac OS X use their own custom cipher engines. Chrome and Firefox use the NSS (Network Security Services) for SSL/TLS support. NSS does not currently support TLS 1.1 or 1.2, so neither Chrome nor Firefox currently support them without an upgrade or fix. Google Chrome will have a custom fix out soon that defangs the BEAST attack by inserting more randomness into TLS 1.0. Mozilla has had bug requests asking for newer TLS support for Firefox going back to March 2008, but so far has not publicly announced its intentions to combat the BEAST attack. Safari on Mac OS X only supports TLS 1.0. For the time being, some users are reverting to IE or Opera for HTTPS-protected websites.

    It's another question about whether your mobile device or smartphone supports TLS 1.1 or 1.2. WebKit, which is used by Safari and other browsers, was updated in November 2010 to support the latest versions, but you'll have to test to see if your mobile device has that version.

    The BEAST attack is a serious threat against browsers. The MitM requirement will probably slow down the attack's spread in the wild -- which will give websites and browser vendors a window of opportunity to roll over to TLS 1.1 or TLS 1.2 with all deliberate speed. We've known about this vulnerability for at least 10 years. It's a shame that it has taken a real-world attack tool to spur us to abandon protocols that are at least half a decade old.

    BEAST is not likely to impact millions of users immediately, but it has serious implications for the unlucky victims. If we're lucky, the BEAST attack will be recorded in history as a wake-up call rather than a wholesale security disaster.

    This story, "Red alert: HTTPS has been hacked," was originally published at InfoWorld.com.

    infoworld.com
    Last edited by Mid; 27-09-2011 at 07:13 PM. Reason: formatting

  2. #2
    Thailand Expat harrybarracuda's Avatar
    Join Date
    Sep 2009
    Last Online
    @
    Posts
    102,993
    Oh goody, more work.


  3. #3
    Thailand Expat
    Mid's Avatar
    Join Date
    Aug 2007
    Last Online
    @
    Posts
    1,411
    yep , chicken and egg ........................

  4. #4
    Thailand Expat harrybarracuda's Avatar
    Join Date
    Sep 2009
    Last Online
    @
    Posts
    102,993
    Yes, there's a conundrum:

    If you upgrade your browser to TLS 1.1 and disallow any other type of connection, you will not be able to establish connections to most HTTPS hosts.

  5. #5
    Thailand Expat
    Mid's Avatar
    Join Date
    Aug 2007
    Last Online
    @
    Posts
    1,411
    Mozilla thinks of blocking Java to mitigate BEAST attack
    Lucian Constantin
    Thu Sep 29 2011

    Needs to stop same origin policy bypass

    FIREFOX DEVELOPERS are considering blocking the Java plug-in in order to prevent a dangerous same origin policy bypass from working. The bug was exploited by security researchers Thai Duong and Juliano Rizzo in their recently disclosed attack against SSL/TLS.

    The Browser Exploit Against SSL/TLS (BEAST) leverages a decade-old vulnerability in SSL and TLS 1.0 to decrypt and steal protected session cookies.

    In order for BEAST to work, the attackers need to gain a man-in-the-middle position that allows them to control the victim's network connection. This is also necessary for injecting a crucial piece of rogue Javascript code into a non-encrypted page the user visits.

    Then, in order for this code to interfere with the targeted HTTPS web site, restrictions enforced by the browser's same origin policy (SOP) need to be bypassed. Duong and Rizzo achieved this by exploiting a vulnerability in Oracle's Java plug-in.

    "I recommend that we blocklist all versions of the Java Plugin," Firefox developer Brian Smith proposed on Mozilla's bug tracking platform. "My understanding is that Oracle may or may not be aware of the details of the same-origin exploit. As of now, we have no ETA for a fix for the Java plugin," he added.

    Firefox's blocklisting mechanism can be used to quickly block dangerous add-ons if the need arises, but Mozilla also has a less drastic solution for disabling plug-ins or extensions that allows users to re-enable them on a click-to-play basis. However, Smith believes that such soft-blocking is not suitable in this case because attackers can easily overcome it.

    The development team is still undecided because disabling Java, even if temporarily, would cause all sorts of user experience problems. Java is not commonly used on regular web sites anymore, but it is still widespread in corporate environments where business-type web-based applications need it.

    "This is a hard call. Killing Java means disabling user functionality like facebook video chat, as well as various java-based corporate apps (I feel like Citrix uses Java, for instance?)," said Mozilla's director of Firefox engineering, Johnathan Nightingale, who seems to favor a click-to-play approach for now.

    "Whatever decision we make here, I really hope Oracle gets an update of their own out - it's the only way to keep their users affirmatively safe," he concluded.

    If the team decides to go ahead with this solution it won't be the first time Mozilla has blocked an important plug-in. Back in November 2009, the browser maker disabled Microsoft's .NET Framework Assistant and Windows Presentation Foundation add-ons because of unresolved security issues.

    theinquirer.net

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •