Identity Shield question

Discussion in 'Prevx Releases' started by 3x0gR13N, Apr 27, 2012.

Thread Status:
Not open for further replies.
  1. 3x0gR13N

    3x0gR13N Registered Member

    Joined:
    May 1, 2008
    Posts:
    754
    By default WSA doesn't protect regular HTTP sessions via Identity Shield thoroughly (tampering with browsers modules/code injection is allowed, no "padlock" is present).

    Let's imagine this situation (focusing solely on Identity Shield)- malware X is present on system, it waits for the user to launch browser, when browser is loaded user navigates HTTP links (i.e (most of) Identity Shield/padlock not active), while user is on HTTP links malware x injects persistent .dll module in browser memory which has the ability to modify webpages and intercept user data (MITB basically) without any additional communication with other components of malware x (.dll is standalone).
    Within the same browser session (browser memory compromised) user enters HTTPS site, with the Identity Shield/padlock now active and protecting the browser.

    Would WSA perform a retroactive integrity check of browser memory to see if there are any unknown modules already running in such cases?

    When I tested it, it didn't seem to unload the injected 3rd party .dll, however I don't know if that .dll is known/trusted by WSA and thus not unloaded or if WSA just doesn't perform such checks...
     
  2. fax

    fax Registered Member

    Joined:
    May 30, 2005
    Posts:
    3,731
    Location:
    localhost
    It should be "jamming" the data indipendently from injections as it is designed to prevent keylogging and screengrabbing in presence of running malware.
     
  3. 3x0gR13N

    3x0gR13N Registered Member

    Joined:
    May 1, 2008
    Posts:
    754
    If so, it's commendable that WSA can isolate untrusted modules running inside the browser from getting data and not "jam" the entire browser itself in the process. :)
     
  4. fax

    fax Registered Member

    Joined:
    May 30, 2005
    Posts:
    3,731
    Location:
    localhost
    I have the feeling that what you ask is something else (i.e. different ways to protect the browser). It requires a re-design of the mechanism and its objectives. Isolation, blockage is what you commonly find in most security tools from security suites to sandbox software.

    The objective of ID is not to purely isolate or block but to feed with obfuscated data or null data anything in-between reading the screen or monitoring the keyboard. The end result is the same but the means not :)

    I think we are going too much into technical details of the protection and before I talk too much "bullsh..." PREVXHELP should chime in. :D
     
    Last edited: Apr 27, 2012
  5. PrevxHelp

    PrevxHelp Former Prevx Moderator

    Joined:
    Sep 14, 2008
    Posts:
    8,242
    Location:
    USA/UK
    If the user starts with an HTTP website and later changes to an HTTPS website, WSA's protection is still equally strong. It won't unload DLLs entirely but it will prevent them from intercepting data or stealing information, so, no matter which sequence you used to log in, you'll be protected :)
     
Thread Status:
Not open for further replies.