Forum Discussion

BT_90520's avatar
Icon for Nimbostratus rankNimbostratus
Sep 20, 2011

New web attack on SSL/TLS using BEAST

Hi there,



In the link below, the POC mentioned injecting the js thru use of an iframe ad or just loading the BEAST js into browser, thereafter comes the second stage of sniffing and decrypting https cookie to hijack the secure session. Seems like CSRF but not really since it is claimed to decrypt cookie prior to all this. Hope that I did not misunderstood the process.




It reminds of the SSL renegotiation saga which the initial response was to disable such protocol exchange since it s the protocol design issue. For this BEAST attack, before they say the crypto is flawed, I doubt we can even say to go ahead and disable use of SSL/TLS 1.0.




Hence, looking ahead (before the POC is released, if it is) will F5 ASM be using a signature detection approach or better still has an iRule to prevent its hijacking (code injection) from even happening?








8 Replies

  • TLS 1.2 does not exhibit this vulnerability. Are there any plans for BIG-IP SSL profiles to support TLS 1.2?





  • Understand that BIG-IP v11 should already support TLS 1.2 - try out "tmm --serverciphers 'DEFAULT'" to see.


    It would list out AES128-SHA256 and AES256-SHA256 in the native SSL stack used. The main difference is MAC changed from SHA to SHA256 (and it will give higher entropy for the pseudorandom function).



    I suppose the SSL profile would also have supported TLS 1.2 (best to hear out from the expert too :p)



    But the point for this vulnerability is that not many web service is using TLS1.2 and providers are not moving to higher security level as they may be losing their client who is still using the older version. See statistic of the TLS used in the link below




    Overall, best to prevent the exploit from even happening at the first place (stop the js injection into the client browser). But we do need to note that the authors claim to also be able to perform the attack on other applications using TLS (such as VPNs), not just web browsers.



    Just some quick thoughts ...



  • Mitigating the initial attack vector, which is a combination of XSS and CSRF is the best bet. BIG-IP v11 does support TLS1.2. However, I do not think that FireFox, Safari, or Chrome support TLS 1.2 yet. And on Windows, only Vista/7 with IE8+ support TLS 1.2. So, there's a very large portion of the Internet population unable to access any site that moved forward with enforcing TLS1.2-only right now.
  • Thanks Brian. Also saw that the release note of v11 has stated the support of the TLS1.2





    Also understand that TLS1.2 is not enabled by default for Win2008 R2 and IIS that ships with it. But it should be able to enable through registry setting. Even for Apache 2.0, I do not think it support TLS 1.2 yet.



    So in that case, to mitigate the attack, ASM come in to enforce client doing TLS1.2 while it handle TLS1.0 with web server. See diagram below. Of course, we are saying attacks cannot get in btw ASM and web server.



    [Client] <---TLS1.2---->[ASM]<---TLS1.0--->[Web Server]



    Does this sound feasible?
  • non-CBC ciphers are not vulnerable, so you can mitigate by updating your SSL profiles to eliminate CBC and use something like RC4-sha (widely supported).
  • Thought this link may help as it can specify which cipher to reject handshake. But in term of client connection, if ther is no common cipher suite the ssl handshake will fail meaning the client will get from bigip a tcp reset. applies to new connections. Suggest you check out v11 to captialise the tls1.2 crypto. Understand v10.2.3 also supports it.
  • @orinzo



    You can manually verify the ciphers that are being accepted by a site by using


    openssl s_client -connect -cipher AES256-SHA <-testing each cipher from openssl ciphers.....


    ...but who wants to do that when we can script it??


    and luckily, someone has built a pretty nice script already:





    It will run through the openssl ciphers and tell you which ones the server responds to in a handshake.