Results 1 to 6 of 6
  1. #1
    2 Star Lounger
    Join Date
    Oct 2009
    Location
    Shoreline, Washington, USA
    Posts
    147
    Thanks
    0
    Thanked 1 Time in 1 Post
    ***


    IN THE WILD

    Malware may lurk in your browser's cache


    By Robert Vamosi

    A new JavaScript exploit can enter your system via an encrypted public Wi-Fi network and either attack immediately or wait to be remotely triggered.

    As described at the Black Hat DC 2010 conference, the exploit is able to convert an encrypted https session into an unencrypted http session; and that's just for openers.

    The full text of this column is posted at WindowsSecrets.com/2010/02/11/05 (paid content, opens in a new window/tab).

    Columnists typically cannot reply to comments here, but do incorporate the best tips into future columns.
    ***
    Last edited by revia; 2011-01-20 at 15:05.

  2. #2
    Lounger
    Join Date
    Dec 2009
    Posts
    28
    Thanks
    2
    Thanked 12 Times in 5 Posts
    Thanks for bringing this to our attention . What you described concerned me a lot and also raised a lot of questions. Your article didn't link the Black Hat paper (only the summary page for the conference) , but Google found it at:

    http://www.blackhat.com/presentation...ecurity-wp.pdf

    The key point seem to be the technique for executing a Man-in-the-middle attack on a machine connecting to a public network by hijacking the TCP session. Of course once the attacker is the man in the middle it is pretty much game over for the attackee however I wanted to go over the point on converting https to http sessions that was mentioned. It seems to me that this can only happen in three circumstances:

    Either the remote site would have to permit http connections to pages normally secured by https (and if the server's administrator permits that for any application requiring security then you have to wonder what else might be broken)

    Or the attacker is exploiting the TLS protocol vulnerability, discovered last year, to decrypt the session.

    Or the attacker is proxying the https session and is generating a certificate signed by a CA trusted by the attackee - this seems unlikely for any machine the attacker doesn't directly control.


    The other key point - which you quite rightly highlighted - is the opportunity the attacker gains to drop a persistent object in the browser's cache and, by opportunistically guessing the addresses of internal servers, javascript could be executed around the content of sites on the user's remote trusted network *after* they open a VPN connection. The other scenario would be to have the browser execute some code every time the user accesses a particular site - no matter which network they are connected to.

    To mitigate the second of these is straightforward: configure the browser to empty its cache when you close it and make sure you always close the browser when changing network.

    The first is more complex but it seems a possible mitigation would be to use one browser (say Firefox with NoScript) before opening the VPN and then a second browser (say IE) after opening the VPN. Close both and empty the cache at the end of your session.

    So the major message is: any network that you don't control cannot be trusted and nobody controls a public WiFi network.

  3. #3
    New Lounger
    Join Date
    Dec 2009
    Location
    Christchurch, New Zealand
    Posts
    3
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Article Quote: "Adobe kicks off its silent Reader updates. In my Jan. 14 In the Wild column, I described Adobe's plan to update its products automatically in the background. (The Adobe updater, installed on most PCs using the company's software via an October 2009 update, was left disabled.)....."

    I would be happy for this updater to be on our systems if it lets standard users be able to update Adobe Reader. I recently updated all our local pc's (around 30) to Reader 9.3. But I had to do it all as 'administrator'. As a 'user' one still can't get the updates from Adobe for Reader. These machines hardly ever get run with administrator rights so they don't get the automatic updates. When the next Reader vulnerabilities are exposed I guess I'll be manually updating systems again, unless this new updater solves this problem. Let us know if you think they fixed this issue?

    Regards, Bryce S.

  4. #4
    Lounger
    Join Date
    Dec 2009
    Posts
    28
    Thanks
    2
    Thanked 12 Times in 5 Posts
    Bryce

    You could install Adobe Reader through Group Policy. Have a look at the Enterprise deployment stuff here:
    http://www.adobe.com/devnet/acrobat/...eployment.html

  5. #5
    New Lounger
    Join Date
    Dec 2009
    Location
    Christchurch, New Zealand
    Posts
    3
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Thanks Thomas, but we don't use Group Policy for deployments - looked at it several years ago, not in relation to Adobe products, but found it caused as many issues as it solved.
    Besides, Reader is already deployed now - I just want it to update itself when a non-admin user is logged on so I don't have to think about it ever again :-))
    Hence my wondering if the new updater had got over that hurdle like browsers and other softwares seem to have been able to do

    Regards, Bryce.

  6. #6
    Lounge VIP bobprimak's Avatar
    Join Date
    Feb 2009
    Location
    Hinsdale, IL, USA
    Posts
    2,483
    Thanks
    176
    Thanked 152 Times in 129 Posts
    If you are unsettled by auto-updaters, most can be disabled through the program's settings or options. Definitely true of Firefox and Adobe Reader -- not so much for Shockwave and Flash Player.
    -- Bob Primak --

Posting Permissions

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