Likes Likes:  0
Resultaten 1 tot 5 van de 5
Geen
  1. #1
    Can we prevent IE exploits a priori?
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Can we prevent IE exploits a priori?



    We all know that yet another critical IE vulnerability (download.ject [aka SCOB, finally patched by M$ after 10 months] caused some high profile groups (http://slate.msn.com/id/2103152/, http://www.theinquirer.net/?article=16922, slashdot.org/articles/04/
    07/02/1441242.shtml?tid=103&tid=113&tid=126&tid=172&tid= 95&tid=99) to suggest that people stop using Internet Explorer. Yet a variation on SCOB (shell.application), remains unpatched, allowing our favorite Russian spam crime lords another crack people's
    boxes. Of course, I use Mozilla, but some of my clients use IE and won't give it up, so I started to look around for a permanent fix, something that could prevent these attacks a priori.

    I found this post (http://seclists.org/lists/bugtraq/2004/May/0153.html) on Bugtraq, from Thor Larholm which claims that his company (http://pivx.com/qwikfix/) has fixed all of these problems, half a year ago, with his program Qwik-fix. It apparently doe
    s this by harderning IE's "my local machine" zone (which is only visible if you hack the registry) and proactively prevent these type of attacks for good. Another program, Smartfix ((http://www.einfodaily.com/about.php#smartfix)), claims to do the same,
    so I decided to try these programs.

    I found Smartfix to be an unbearable resource hog on even a burly laptop, maxing the CPU almost every time I opened a web page in any browser, so I ripped it off my system. On the other hand, Qwik-Fix is MIA for me. Despite being supposedly available fr
    om multiple locations, in various versions (0.58 beta: http://www.majorgeeks.com/download4033.html , 0.57 beta: http://fileforum.betanews.com/detail/1068047556/1 , and 0.60 beta: http://superdownloads.ubbi.com.br/download/i24346.html), none of the downloa
    ds work right. The site doesn't list the current version, so I don't know if the 0.60 beta is even the latest version. Anyway, all of the downloads either fail, or when you get one of them and try to install it, the application attempts to download an M
    SI file that doesn't exist on the server. The Bugtraq post says you can download it from their site, but the download page (http://pivx.com/qwikfix/download.html) only allows you to email them so they can send you a copy. I
    still haven't heard from them. I don't mean to flame you Thor, as your client list is certainly impressive: (http://pivx.com/clients.html) I just can't seem to get your program from anywhere.

    So I wanted to know, has anyone tried these programs successfully? Can anyone validate their claims? Better yet, does anyone have a link to a "how to" doc, that tells smart geeks how to make the registry changes ourselves, so we don't have to rely on so
    me program to do it for us?

  2. #2
    Drew Copley
    Can we prevent IE exploits a priori?
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    RE: Can we prevent IE exploits a priori?

    I have not seen evidence that either of these applications
    prevents new exploits. If anyone is making this claim, they
    should explain what technology they are using.

    The required fix is simply setting a kill bit on the vulnerable
    activex objects. Had this been done in September, none of these
    attacks would have happened.=20

    "Workaround for Jelmer's Adodb Bug"=20
    Date: September 13, 2003
    http://seclists.org/lists/fulldisclo.../Sep/0643.html

    The easy to use, free fix for all of these issues:
    http://www.eeye.com/html/research/al...L20040610.html

    Jelmer and Http-equiv have just noted and proven that hardening
    the local zone or the "My Computer Zone" which Quick-Fix touts
    is not a solution because the "Trusted Zone" remains... and is
    required for Windows Update. [Whatever else they may do, I
    do not know, I am just noting what they tout as "the only"
    solution.]

    This said you can very easily harden your "My Computer Zone"
    for free. Just show it and make it available. That is a google
    step away.

    You also need to harden all of the IE Zones.

    You should do this as part of any system hardening effort. Simply
    use the restricted zone as an example. You must know how to
    do this and understand the settings to probably harden any Windows
    system. It is as critical as setting the password policies or
    anything else. This does require some self-education beyond using
    the Restricted Zone as reference.

    If you mess up you will make it very difficult for users to
    browse the web and they will manually change the settings and
    likely end up getting spyware running automatically on their
    systems -- or worse.

    Again, hardening all of the zones in IE should be a central
    part of any Windows hardening process. This means not just the
    Local Zone, but all of the other Zones as well.

    The only people that should not be setting the kill bit are
    administrators that wish to continue to rely on vbs or wsh despite
    the strong evidence that this will make the systems they own
    vulnerable to potential attacks.=20

    If you "really" want to ensure they will not get hit, put
    on some AV and a good IPS. Ensure that the update subscription
    is paid for.=20



    > -----Original Message-----
    > From: security-bugtraq@marketshark.net=20
    > [mailto:security-bugtraq@marketshark.net]=20
    > Sent: Wednesday, July 07, 2004 10:41 AM
    > To: bugtraq@securityfocus.com
    > Subject: Can we prevent IE exploits a priori?
    >=20
    >=20
    >=20
    > We all know that yet another critical IE vulnerability=20
    > (download.ject [aka SCOB, finally patched by M$ after 10=20
    > months] caused some high profile groups=20
    > (http://slate.msn.com/id/2103152/,=20
    > http://www.theinquirer.net/?article=3D16922,=20
    > slashdot.org/articles/04/07/02/1441242.shtml?tid=3D103&tid=3D113&t
    > id=3D126&tid=3D172&tid=3D95&tid=3D99) to suggest that people stop=20
    > using Internet Explorer. Yet a variation on SCOB=20
    > (shell.application), remains unpatched, allowing our favorite=20
    > Russian spam crime lords another crack people's boxes. Of=20
    > course, I use Mozilla, but some of my clients use IE and=20
    > won't give it up, so I started to look around for a permanent=20
    > fix, something that could prevent these attacks a priori. =20
    >=20
    >=20
    >=20
    > I found this post=20
    > (http://seclists.org/lists/bugtraq/2004/May/0153.html) on=20
    > Bugtraq, from Thor Larholm which claims that his company=20
    > (http://pivx.com/qwikfix/) has fixed all of these problems,=20
    > half a year ago, with his program Qwik-fix. It apparently=20
    > does this by harderning IE's "my local machine" zone (which=20
    > is only visible if you hack the registry) and proactively=20
    > prevent these type of attacks for good. Another program,=20
    > Smartfix ((http://www.einfodaily.com/about.php#smartfix)),=20
    > claims to do the same, so I decided to try these programs. =20
    >=20
    >=20
    >=20
    > I found Smartfix to be an unbearable resource hog on even a=20
    > burly laptop, maxing the CPU almost every time I opened a web=20
    > page in any browser, so I ripped it off my system. On the=20
    > other hand, Qwik-Fix is MIA for me. Despite being supposedly=20
    > available from multiple locations, in various versions (0.58=20
    > beta: http://www.majorgeeks.com/download4033.html , 0.57=20
    > beta: http://fileforum.betanews.com/detail/1068047556/1 , and=20
    > 0.60 beta:=20
    > http://superdownloads.ubbi.com.br/download/i24346.html), none=20
    > of the downloads work right. The site doesn't list the=20
    > current version, so I don't know if the 0.60 beta is even the=20
    > latest version. Anyway, all of the downloads either fail, or=20
    > when you get one of them and try to install it, the=20
    > application attempts to download an MSI file that doesn't=20
    > exist on the server. The Bugtraq post says you can download=20
    > it from their site, but the download page=20
    > (http://pivx.com/qwikfix/download.html) only allows you to=20
    > email them so they can send you a copy. I
    > still haven't heard from them. I don't mean to flame you=20
    > Thor, as your client list is certainly impressive:=20
    > (http://pivx.com/clients.html) I just can't seem to get your=20
    > program from anywhere. =20
    >=20
    >=20
    >=20
    > So I wanted to know, has anyone tried these programs=20
    > successfully? Can anyone validate their claims? Better yet,=20
    > does anyone have a link to a "how to" doc, that tells smart=20
    > geeks how to make the registry changes ourselves, so we don't=20
    > have to rely on some program to do it for us?=20
    >=20


  3. #3
    James C Slora Jr
    Can we prevent IE exploits a priori?
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    RE: Can we prevent IE exploits a priori?


    > So I wanted to know, has anyone tried these programs
    > successfully? Can anyone validate their claims? Better yet,
    > does anyone have a link to a "how to" doc, that tells smart
    > geeks how to make the registry changes ourselves, so we don't
    > have to rely on some program to do it for us?


    Here is some info about Zone 0 (My Computer Zone).

    Search Technet for "explorer security zones" for lots of relevant articles.
    The first one to read is:
    http://support.microsoft.com/?kbid=182569

    The lockdown of Zone 0 works as Thor claims, except when someone can spoof a
    higher-trust zone - as noted by http-equiv and Jelmer (and really by Thor
    too) on Bugtraq. Because it is now fairly easy to spoof another zone, you
    probably should killbit adodb.stream and shell.application controls and get
    rid of the HTA MIME-Type. Drew Copley posted a link to sample registry files
    for that stuff:
    http://www.eeye.com/html/research/al...L20040610.html

    Local web page development of course can have complications from locking
    down the My Computer Zone. You have to see if it breaks anything in your
    environment, and you might consider letting developers toggle the settings
    through desktop shortcuts. You might also consider loosening some of the
    lockdown - it will be your tradeoff between security and functionality.

    To protect against cross-zone attacks, you would also have to lock down the
    other Zones 1 through 4. Locking down Trusted Sites, though, defeats the
    purpose of Trusted Sites. So you might consider allowing users to unlock
    Trusted Sites when they are actually visiting one. Of course that has
    training and reliability issues that are possibly insurmountable. You might
    also lock down all the zones except Trusted Sites, and make sure that nobody
    trusts a guessable domain like microsoft.com - this would provide security
    by obscurity against mass exploits, but would not protect against a targeted
    exploit. If someone knows who you trust, they can spoof the trusted site
    pretty easily.

    My Computer Zone (Zone 0) lockdown registry entries, similar to or same as
    Qwik-Fix:
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\Internet
    Settings\Zones\0]
    "1001"=dword:00000003
    "1004"=dword:00000003
    "1201"=dword:00000003
    "1400"=dword:00000003
    "1402"=dword:00000003
    "1405"=dword:00000003
    "1406"=dword:00000003
    "1407"=dword:00000003
    "1601"=dword:00000003
    "1604"=dword:00000003
    "1606"=dword:00000003
    "1607"=dword:00000003
    "1608"=dword:00000003
    "1609"=dword:00000003
    "1800"=dword:00000003
    "1803"=dword:00000003
    "1804"=dword:00000003

    Note that these are just the values that are different from the defaults.

    The default values for this zone would normally be:
    "1001"=dword:00000000
    "1004"=dword:00000000
    "1201"=dword:00000001
    "1400"=dword:00000000
    "1402"=dword:00000000
    "1405"=dword:00000000
    "1406"=dword:00000000
    "1407"=dword:00000000
    "1601"=dword:00000000
    "1604"=dword:00000000
    "1606"=dword:00000000
    "1607"=dword:00000000
    "1608"=dword:00000000
    "1609"=dword:00000001
    "1800"=dword:00000000
    "1803"=dword:00000000
    "1804"=dword:00000000

    You can also consider implementing the changes through HKCU instead of HKLM
    so that the settings apply only to the logged on user instead of to all
    users on the machine. This does not work if you just apply it to a default
    configuration - you have to make some other changes, too. You would have to
    make sure that the settings actually applied. KB182569 has info about
    heirarchy of settings and permissions. In that case, the key would be:
    [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Curre ntVersion\Internet
    Settings\Zones\0]

    Explanation:
    Settings - 0 enables, 1 prompts, 3 prohibits (2 is not documented or
    supported)

    1001 - Download signed ActiveX controls
    1004 - Download unsigned ActiveX controls
    1200 - Run ActiveX controls and plugins
    1201 - Initialize and script ActiveX controls and plugins not marked as safe
    1400 - Active Scripting
    1402 - Scripting of Java applets
    1405 - Script ActiveX controls marked safe for scripting
    1406 - Access data sources across domains
    1407 - Allow paste operations via script
    1601 - Submit non-encrypted form data
    1604 - Font download
    1605 - Run Java
    1606 - User Data persistence
    1607 - Navigate sub-frames across different domains
    1608 - Allow META REFRESH
    1609 - Display mixed content
    1800 - Installation of desktop items
    1802 - Drag and drop or copy and paste of files
    1803 - File download
    1804 - Launching programs and files in an IFRAME

    There are other values in the Security Zones, but these are the ones that
    should be changed from their defaults and that should make a big difference.
    The rest of the values are documented in the KB article I mentioned at the
    beginning of this post.

    The Zones:
    0 - My Computer
    1 - Local Intranet Zone
    2 - Trusted sites Zone
    3 - Internet Zone
    4 - Restricted Sites Zone

    To show the My Computer Zone in the user interface:
    From http://support.microsoft.com/?kbid=315933
    The Flags value in the following registry key determines whether you can
    view the My Computer security zone on the Security tab in the Internet
    Options dialog box:
    HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Curre ntVersion\Internet
    Settings\Zones\0

    The Flags value is a DWORD value. Setting the data value of the Flags value
    to 47 (in hexadecimal) causes the My Computer security zone to be displayed.
    Setting the data value of the Flags value to 21 (in hexadecimal) causes the
    My Computer security zone to be hidden


  4. #4
    Jason Coombs
    Can we prevent IE exploits a priori?
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Can we prevent IE exploits a priori?

    Drew Copley wrote:
    > I have not seen evidence that either of these applications
    > prevents new exploits. If anyone is making this claim, they
    > should explain what technology they are using.
    >
    > The required fix is simply setting a kill bit on the vulnerable
    > activex objects.


    In response to security-bugtraq@marketshark.net
    >>I don't mean to flame you
    >>Thor, as your client list is certainly impressive:
    >>(http://pivx.com/clients.html) I just can't seem to get your
    >>program from anywhere.
    >>
    >>So I wanted to know, has anyone tried these programs
    >>successfully? Can anyone validate their claims? Better yet,
    >>does anyone have a link to a "how to" doc, that tells smart
    >>geeks how to make the registry changes ourselves, so we don't
    >>have to rely on some program to do it for us?


    Aloha, Drew and MarketShark.net.

    To answer your last question first, I wrote an article recently for Dr.
    Dobb's that you may find helpful as you figure out how to harden the IE
    My Computer/Local Machine zone yourself.

    Dr. Dobb’s Windows Security, June 18, 2004

    IE’s Local Machine Zone and the Attack of the TLAs
    http://www.ddj.com/documents/s=9207/ddj040618sec/

    As Thor Larholm pointed out to Drew Copley on July 3rd, the kill bit is
    good but preventing all scripting of controls in the My Computer Zone is
    better. This is the sort of security hardening for IE that Qwik Fix
    provides. See http://www.qwik-fix.net

    Thor Larholm wrote:
    >The prerequisite for even having privileges enough to launch the
    >Shell.Application ActiveX object inside IE is to have script running in
    >the My Computer zone. Locking down this zone will completely prevent
    >this exploit, without introduing functionality regressions in other
    >parts of Windows.


    Qwik Fix does set the kill bit on bad controls, and will set the kill
    bit on controls that are not bad but are a risk, but only when there is
    not a better technical solution available than setting kill bits.

    There can be little argument that setting the kill bit on each control
    that poses a threat when IE's zones are not properly hardened is to
    attempt to hit a moving target.

    Drew Copley wrote:
    > The easy to use, free fix for all of these issues:
    > http://www.eeye.com/html/research/al...L20040610.html


    It is not free if a paid employee of the company has to spend time doing
    it. Although the eeye registry fixer tool may be useful to some, the
    fact that registry hacks like the ones that eeye recommends often have
    to be backed out temporarily to do something that has been blocked by
    the new setting, and then re-implemented after that action is complete,
    makes it necessary to have a trusted software agent that does these
    security hardening and temporary unhardening steps for us automatically
    at runtime.

    The user knows when they are browsing the Web and when they aren't --
    therefore the user gets to decide when the protection should be present
    and when it should not be. This is a security context decision that a
    simple registry hack cannot make at runtime, and that in the end we have
    to be able to rely on the end user to understand. More importantly, we
    need the end user to be capable of exerting specific information
    security skill and knowledge with the click of a mouse in a consistent
    and manageable fashion.

    My experience has been that end users do understand the difference
    between browsing the Web and printing a file to their printer, for
    example, and there are instances where security registry hacks will
    disable printing or some other mundane, low-risk activity. That the end
    user must take action to unharden a box long enough to print is an
    unfortunate reality of poor security design in printer manufacturer's
    user interfaces, and we all just have to live with and adapt our boxes
    around these realities.

    > If you mess up you will make it very difficult for users to
    > browse the web and they will manually change the settings and
    > likely end up getting spyware running automatically on their
    > systems -- or worse.


    Again the reference to "you" as distinct from the "users" themselves
    makes it clear that you are thinking of the problem only from one
    perspective. End users will always manually change settings when not
    given an easy way to bypass barriers to getting things done. Spyware
    will do it for them without their knowledge. The "you" in the real world
    is often the end user themself, reinstallation of a Windows
    hotfix/service pack, and so forth. When "you" does refer to a system or
    network administrator, they know very well that even when they don't
    mess up, things still go wrong and settings get changed.

    A software agent like Qwik Fix that knows how to harden and unharden or
    reharden a Windows box solves the "if you mess up" problem, no matter
    who, or what, "you" it is that is responsible for messing it up (again).

    There are hundreds of thousands of Qwik Fix users to date, and the
    response to the software from other infosec peers has been very
    positive. After Scob there was an outpouring of gratitude expressed from
    people who realized that the software protected them in advance.

    This is pretty convincing proof that the product protects against new
    exploits by solving root problems that allow them to occur. I personally
    was impressed enough to join the company. (note sig below)

    Sincerely,

    Jason Coombs
    jasonc@science.org

    Director of Forensic Services
    PivX Solutions, Inc.
    http://www.pivx.com


  5. #5
    Can we prevent IE exploits a priori?
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: Can we prevent IE exploits a priori?



    > So I wanted to know, has anyone tried these programs successfully?
    > Can anyone validate their claims?
    > Better yet, does anyone have a link to a "how to" doc, that tells smart
    > geeks how to make the registry changes ourselves, so we don't have to rely
    > on some program to do it for us?


    How about this: a sandbox that you can run IE in, controling things like:
    -ShellExecute() calls such that only selected programs can be started
    by IE, say Notepad, Real Player, but not the MS-Help tool?
    -truly prevents Java Script from running (IE had bugs in the past that
    allowed running javascript-code even if it was turned of)
    -Only allow selected activeX controls to load (acrobat reader etc.)
    -Deny TCP connections to certain sites
    etc. etc.

    http://www.heise.de/ct/ftp/projekte/iecontroller/

    This software is free, sourcecode available (though not GPL!), but unfortunately
    the documentation is in German. It was build by one of the German
    computer magazines (c't). If anybody is truly bored and speaks German,
    a GPLed version of this would be incredibly useful. I also think that can do more than some registry hacks.

    -Markus

Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics