Windows without updates, comodo and Avast

Discussion in 'other anti-malware software' started by Jean_Charles, Nov 1, 2016.

  1. Jean_Charles

    Jean_Charles Registered Member

    Joined:
    Nov 1, 2016
    Posts:
    5
    Location:
    Switzerland
    Hi.

    If windows is not updated, will comodo (hips and firewall), and avast (just AV module) protect the computer?


    Thanks and have a nice day
     
  2. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    11,692
    Location:
    The Netherlands
    It depends on your own know how. I have managed to stay safe on an old Win XP PC without any updates for years. But it's not recommended because security tools can not defend against kernel exploits in general.
     
  3. Jean_Charles

    Jean_Charles Registered Member

    Joined:
    Nov 1, 2016
    Posts:
    5
    Location:
    Switzerland
    Thanks for your answer.

    Hips of comodo doesn't protect the kernel exploits?

    Thanks
     
  4. MisterB

    MisterB Registered Member

    Joined:
    May 31, 2013
    Posts:
    1,216
    Location:
    Southern Rocky Mountains USA
    A lot of kernel exploits require local access with administrative privilege. If you use a limited user account and don't install or run software from untrusted sources, you are fairly safe from kernel exploits on an unpatched system. Flash and browser exploits that are not kernel exploits are far more common. Using a script blocker and only allowing javascript on trusted sites will deal with a lot of those as will setting Flash and other plugins to click to play.
     
  5. Jean_Charles

    Jean_Charles Registered Member

    Joined:
    Nov 1, 2016
    Posts:
    5
    Location:
    Switzerland
    Thanks

    Leaving UAC activated is sufficient if you use an unlimited user account?
     
  6. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    11,692
    Location:
    The Netherlands
    It depends a bit on what type of kernel exploits are being used. The most serious ones will bypass LUA and security tools with "direct code execution" by abusing system processes. But there are also "privilege elevation" exploits that can only be used if for example the browser is exploited. LUA will also not help in this case. So blocking code execution via anti-exploit/executable (AE) is very important.
     
  7. MisterB

    MisterB Registered Member

    Joined:
    May 31, 2013
    Posts:
    1,216
    Location:
    Southern Rocky Mountains USA
    Depends on how the LUA is setup. The default MS LUA is weak but ACLs can be tightened quite a bit. On the Xp system I'm writing this on "system" has pretty much the same privilege level as "user". Elevating privilege to "system" will not give an unauthorized process the ability to alter system files. Microsoft has actually done something similar in the ACL structure of newer versions of Windows and "system" is no longer a super root user as in Xp. There is no reason that system processes should be exempt from the general rule that a process should have only the privilege level it needs to perform its function.

    In another forum someone referred to the list of exploitable kernel vulnerabilities for Xp and all of them required a local user to execute software on the local machine to work. None of them could be directly triggered by a flash or browser exploit. In a well set up system that is securely locked down, exploiting the kernel is not trivial, even in Xp. The usual practice of running Windows as an administrator makes it fairly easy.
     
  8. Yuki2718

    Yuki2718 Registered Member

    Joined:
    Aug 15, 2014
    Posts:
    1,643
    I agree w/ many parts of what Rasheed & MisterB said here, but pls don't mind my getting in.
    Possibly you confuse kernel priv w/ system priv, or may be just responded to 'priv escallation' part of Rasheed's comment. If attacker get full kernel priv, ACLs won't help much. Linux has stronger access restriction w/ LSM or other, known as SELinux, AppArmor etc. which can forcebly restrict admin/root (known as MAC). But when kernel exploit is done, he can bypass those restriction. Just deeply search for past kernel vuln like CVE-2013-2094. No doubt same goes for Windows. Although when we hear about kernel vuln most articles talk only about code execution as root, actually that is just an (usually most useful) option for him. He may even infect your CPU (even from within VM), considering many XP machine run on CPUs before SandyBridge, as those older CPUs have almost-non-cureble vuln which is reported in BlackHat. The resercher demonstrated it only on Intel CPUs but said AMD will also be affected in theory.

    Still, I agree tightened ACLs is right way and at least will stop hasty criminals who don't actually want to attack 'you' but just want to infect as many ppl as he can. But when it comes to persistent attacker, complete compromise is just a matter of time after kernel exploit. It's even true to simple priv escalation w/out full kernel compromise. Unfortunately whatever effort we made, we can't truly restrict Admin or SYSTEM on Windows, as those accounts can always get ownership of objects and then change ACLs. This is why Windows' access control is called DAC, not MAC, and true to latest Win 10 too. Also protecting system files and registry is not a complete cure, because if attacker gained priveledged process he can still do many nasties w/out changing those files/registries.

    Also if there's a bug in kernel or driver, ACLs or other restriction may not work as expected, this is why so-called 'nulling-out ACLs', one of the well known technique (along w/ token theft) for priv escalation is used.

    If he meant vuln found after end of support, maybe he is right. But if meant all XP kernel vuln, it's wrong. There're remotely exploitable kernel vuln on XP such as TTF vuln. TTF vuln is terrible as it does not require many user interaction, and it's not just once, but there's been 2 or more TTF vulns. Thus, I recommend to block web font. On 10 there's registry hack, but on older OS blocking font download in Internet Setting might help, but anyway use IE on XP is bad. Chrome also dropped support for XP so maybe only Firefox left? You can block web font on Firefox too.

    All in all, XP can be well secured, and security is relative matter so even latest OS has risks of kernel exploit too. But it's undeniable that securing XP has severe limitation depending on your threat model, as XP (actually 7 too) don't offer effective measure to reduce kernel attack surface.
     
  9. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    11,692
    Location:
    The Netherlands
    Didn't know about this, but I still believe it depends on the type of kernel exploit. The most serious ones won't have any problem owning the system. Luckily there aren't that many of them used in wide-scale attacks. But I also believe that it's indeed not always that easy to successfully exploit a kernel bug, otherwise we would see a lot more of them.

    Thanks for your insight, and yes I agree.
     
  10. ance

    ance formerly: fmon

    Joined:
    May 5, 2013
    Posts:
    1,289
    No.
     
  11. Infected

    Infected Registered Member

    Joined:
    Feb 9, 2015
    Posts:
    964
    Sure it could...:rolleyes::rolleyes:
     
  12. ance

    ance formerly: fmon

    Joined:
    May 5, 2013
    Posts:
    1,289
    Yes, if the computer is offline forever. :D
     
  13. MisterB

    MisterB Registered Member

    Joined:
    May 31, 2013
    Posts:
    1,216
    Location:
    Southern Rocky Mountains USA
    In Windows, kernel processes are run as system. They are subject to ACLs just like any other running process. Taking ownership and altering ACLs is not that easy. Not impossible but beyond the scope of most automated attacks. One more barrier to overcome and one more security layer. There is no one approach or mechanism that is going to secure a system. A layered approach with many different layers is what works. A tight LUA is a good barrier but works best when layered with other mechanisms.
     
  14. Yuki2718

    Yuki2718 Registered Member

    Joined:
    Aug 15, 2014
    Posts:
    1,643
    Tho I'm not familiar w/ Windows internals, kernel don't run as processes. System process is just a virtual process. They are under the hood, and remember what enforces those ACL restriction is kernel itself.
    Kernel mode is about low level architecture, they're totally different from System or Admin or User things which work upon OS and this is why I said you might confuse kernel priv w/ system priv. You can't restrict kernel mode code from OS, you need low level restricion. These links might help
    http://stackoverflow.com/questions/25107767/windows-kernel-mode-aka-system-privilege
    http://unix.stackexchange.com/quest...nel-mode-then-the-process-will-have-root-priv
    ACLs for SYSTEM can only restrict user mode programs run as SYSTEM.

    But I agree to rest of your comment, well, tho I still feel altering ACLs is not difficult, as it just requires time and not sophisticated techniques. Surely that should prevent hasty attacker or in your words automated attacks, and relying solely on ACL is obviously not good idea, we need to combine multiple defences.
     
  15. Jean_Charles

    Jean_Charles Registered Member

    Joined:
    Nov 1, 2016
    Posts:
    5
    Location:
    Switzerland
    However with avast and comodo, they analyse network and HIPS will block any unknown executable. Are they totally useless on a kernel attack (by network or executable)?

    Thanks
     
  16. new2security

    new2security Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    517
    Also security software suites themselves pose a considerable security risk because they introduce an easy pathway for malware to access the kernel.
     
  17. MisterB

    MisterB Registered Member

    Joined:
    May 31, 2013
    Posts:
    1,216
    Location:
    Southern Rocky Mountains USA
    Most kernel exploits require an executable to be downloaded and run, usually with administrative privilege. Blocking execution of unknown executable files would stop such an exploit before it started. It will also stop a lot of other malware.

    Not patching a system will increase the probability of a system being exploited and the longer it is unpatched, the more statistical probability there will be that it can be exploited. It is still probability, not certainty. Adding anything that mitigates or prevents exploits will make an unpatched system more secure but nothing will make it as secure as a fully patched system. Personally, I would both patch the system and use some sort of security software. I have only tested Commodo and I didn't have any problems with it other than finding it a bit bloated. It did have some nice features including a virtualized desktop--ie sandbox. If it blocks unknown executables, it should help prevent kernel exploits as well as the far more common user space exploits and malware.
     
  18. Jean_Charles

    Jean_Charles Registered Member

    Joined:
    Nov 1, 2016
    Posts:
    5
    Location:
    Switzerland
    Thanks for this answer
     
  19. safeguy

    safeguy Registered Member

    Joined:
    Jun 14, 2010
    Posts:
    1,787
    Strengthen the foundation first before thinking about adding layers.
     
  20. Yuki2718

    Yuki2718 Registered Member

    Joined:
    Aug 15, 2014
    Posts:
    1,643
    I expect Network Shield to have NIPS component. NIPS is feasible to prevent kernel exploit provided it is delivered through network. Ofc it has its own limitation, e.g. can only prevent known exploit (not for unknown 0day) and even when it's known still attacker may bypass it by obfuscation. Efficiency of NIPS range widely among products, and I'm not sure about Avast because I haven't seen NIPS-like detection name from Avast, it seems it blocks most exploits in script level which should come after network layer, but I'm not much familiar w/ Avast.

    HIPS OTOH, can prevent automated attack after kernel exploit. It should be noted that after successful kernel exploit, he can forcibly disable or uninstall HIPS if he is aware of it. However, Comodo implemented Enhanced Protection Mode which run HIPS from hypervisor. I'm not sure if its full capability is available on XP even when CPU support virtulization, but theoretically it will be able to resist even kernel exploit as it's outside of OS.

    However, I personally put much more concern on what new2security brought about. This is often disregarded, but w/ many examples of AVs having been made very silly bugs repeatedly I finally came to believe exploiting AVs will be easier than (at least modern) OS kernel. Firewalls should not be much different, as TCP/IP layer have been one of the sources of kernel bugs. Even worse, Comodo have been notorious for their own products' security. They keep very low adoption rate of DEP & ASLR among AVs (see AV-TEST's self protection reports, both of 2014 & 2015 tho their testing methodology had minor problem), and when Superfish fuss extended to their PrivDog, I felt their response was not sincere but defensive. They built Dragon as a 'securer Chrome' but it turns out that it's disabled Chrome's protection so actually less secure, introduced new vuln. It's hard for me to trust security of their product, considering even more reputable vendor have made incredible mistakes (I mean, not just a serious bug but worse than that).

    I guess Avast is not bad, as they're the first to adopt bug bounty (it still haven't eliminated bugs) but firewall on XP is hard to choose for me.
     
  21. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    11,692
    Location:
    The Netherlands
  22. Nebulus

    Nebulus Registered Member

    Joined:
    Jan 20, 2007
    Posts:
    1,596
    Location:
    European Union
    I'm not exactly the average user, but for me they did a pretty good job in protecting an un-patched Windows.
     
Loading...
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.