Malware attack vectors - approaches and setups to block these?

Discussion in 'other security issues & news' started by ssj100, Sep 6, 2009.

Thread Status:
Not open for further replies.
  1. ssj100

    ssj100 Guest

    Those that have read some of my recent threads are probably familiar with what I mean by "Malware attack vectors". I'm simply talking about the different ways that malware can infest your computer.

    A). I think most people don't read or understand some of the major points I've been trying to make in the last couple of weeks. I still see a lot of people seeming to highly praise and rely on black-lister/behaviour-blocker software. Don't get me wrong, praise is a good thing, but actually relying on this type of software is completely flawed in my opinion.

    B). And then we get people who don't seem to mind that their systems could be filled with "frozen malware" and just rely on the "roll of the dice" nature of black-listers/behaviour-blockers to hopefully clean out this "frozen malware" in time, if ever.
    (I classify "frozen malware" as any malware or fragments of malware that are written on the real system, but are unable to do any harm to the system).

    I know some people will argue and attack some of the points I've made above, but those opinions of mine are just a bit of preamble more than anything else.

    So what are the potential malware attack vectors? Well, I'm hoping people can help me out here too, but I'll give it a shot:
    1. Internet - probably the biggest malware attack vector of them all. We're talking about malware infestation via the browser, via chat messenger programs, via P2P programs etc. I think the majority of people get infected via this attack vector.
    2. External device - this includes potential malware infestation via connecting a USB device or inserting a CD/DVD into your system. I think this type of attack is fairly rare, given people will tend to use USB devices and CD/DVDs from trusted sources.
    3. Network - this includes LAN connections and other networking connections. I admit here that I have very little knowledge about attacks of this nature - it simply does not apply to me, and I've done no research or reading about this potential attack vector. I think most home personal computers would not be connected to any networks anyway, and thus would not be subjected to "Network attack vectors".
    4. Others? People might want to fill me in here, as I can't think of any other attack vectors for now. I think attack vector number 1. covers a huge range already.

    So what is the best approach and security setup to block these attack vectors? Well, as we all know, the "best" will be different for different people with their different systems. However, I'd prefer not to "take into account people's computer knowledge and skill levels" here. Saying that "my Grandma would not even know how to switch on the computer" is not a relevant aspect of this discussion. As we all know, the less educated are less protected. Also, arguing that "I get complete peace of mind by just using my common sense etc etc" is not a very helpful contribution to this discussion - there needs to be some elaboration on what this "common sense" is.

    Here's my approach and setup (sorry if this is repetition for those who have read my recent posts). I feel this gives me the best balance between good usability/convenience and good security:

    Approach:
    1. Any newly introduced file on my computer (from an untrusted/unknown source) is treated as if they are "guilty until proven innocent".
    2. Any newly introduced file (from the internet) is recovered into a folder that is forced to run its contents virtualised (see below).
    3. Keep system software up to date, particularly security software.
    4. Lock-down potential malware attack vectors as below. To make things simpler for myself (and given I know very little about the "network attack vector"), I will only focus on blocking malware attack vectors 1. and 2. above.

    Security Setup:
    1. Sandboxie:
    a) Force run internet facing applications with appropriate restrictions
    b) Force run USB/external drives
    c) Force run CD/DVD drives
    d) When recovering files out of the sandboxed environments, recover them into a forced sandboxed folder.

    2. Running in administrator mode with SRP enabled
    a) SRP applied to "All software files"
    b) SRP applied to "All users"
    c) LNK file type (shortcut) excluded
    d) Default security level set to "Disallowed"
    e) Additional Rules as required to increase usability/convenience.
    When wanting to update trusted applications or install confirmed trusted new applications, simply change Default security level to "Unrestricted". Once completed, switch back to "Disallowed".

    3. Comodo Firewall (no HIPS, no Antivirus)

    4. Avira AntiVir on-demand
    a) For giving an opinion on newly introduced files (from unknown/untrusted sources) before executing in sandboxed VM etc.
    b) To prove that overall system is clean (for funsies)

    5. VirtualBox on-demand
    a) Run sandboxed when testing newly introduced files (before executing on real system), known malware, and operating systems.

    EDIT: please feel free to comment on any of the above. I hope some of the above points will give some insight to more novice users too, and open their eyes up a bit perhaps.
     
    Last edited by a moderator: Sep 6, 2009
  2. mark.eleven

    mark.eleven Registered Member

    Joined:
    Oct 27, 2006
    Posts:
    81
    Location:
    Island of Sodor
    My setup is very similar to yours, except that I don't run SRP (I don't think Vista Home Premium has SRP anyway, correct me if I'm wrong).

    I'm quite confident that I'm quite well covered with this present setup:
    - Sandboxie configured accordingly for all internet facing applications and external drives
    - all newly downloaded files are scanned with VirusTotal and TreatExpert before I take them out from sandboxed folder

    I also use Returnil when I do testing.

    So far, this setup is very light, and I like it a lot. :thumb:

    The reason for my confidence is that for the past 2 years, I've been running only Sanboxie and Avira on my system. Avira never detected a single malware, hence I believe a properly configured Sandboxie is more than sufficient, IMO.
     
  3. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    A quick comment:

    What's the problem with this? What kind of a threat is "malware on the real system" that is "unable to do any harm to the system"? I really don't see it as a problem. If it is a problem, then everyone who researches malware and collects malware samples is obviously in a world of problems, seeing how they would have tons of "frozen" malware on the system... But in any case, it's not like it's difficult to delete the inactive malware files on the system if one really wants to. In a limited user account, for example, there's only so many places where an inactive malware could be. It can't be anywhere the account can't write, and that leaves relatively few locations that are easy to search for unauthorized stuff, which you can then happily delete. Malware in browser cache, for example? Empty the cache. Malware in the user's temp folder? Delete the temp folder contents. And so on.
     
  4. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,943
    Location:
    California
    To keep things simple, I've always put malware attack vectors into two categories:

    1) Those that install by remote code execution

    • Internet

    • USB

    2) Those that install with user permission

    • user intalls non-legitimate software that is malware

    • user is tricked: flash_update; rogue security products

    Some things to consider:

    1) remote code execution exploits:

    Internet

    • A properly configured firewall takes care of internet worms: Sasser, Blaster, Conficker.A

    • A properly configured browser takes care of web-based exploits. This includes those such as PDF, Flash, that use the browser as a trigger.

    • Any HIPS-like product will block a malware executable from running by remote code execution.

    USB

    • Secure Policies/Procedures for USB nullify any attack by remote code execution (autorun.inf file) - Conficker.B for example.

    • Any HIPS-like product will block a malware executable from running by remote code execution.

    2) exploits that trick the user into running/installing files -- Solutions chosen depend on the user's confidence in dealing with unknown files. These range from:

    • purchasing/downloading software only from trusted vendors

    • to scanning each file before installing.

    • to running files in a VM

    One final thought: Policies and Procedures should form the backbone of any security approach. Two examples in addition to the USB one above:

    • The prevalence of rogue security products that many are being tricked into installing. A simple policy of not installing something that hasn't generated good reviews would solve this problem. Doing an internet search for the particular product would eliminate this threat.

    • Tricked into installing a fake update - Koobface on Facebook, for example. Users should know how their various software updates, and do so only from the vendor's site.

    From my point of view, the more comprehensive and thought-out the Policies and Procedures, the fewer security products required.

    ----
    rich
     
    Last edited: Sep 6, 2009
  5. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    The categories you use are quite broad and include most everything I can think of, depending on how you classify some potential vectors. Where would an infected office document from a co-worker fit (small office scenario)? A category like "internet" covers almost all file types and potentially every application and system component on your PCs. I found it easier (for myself) to separate the individual apps that make up the attack surface and not try to treat it as a whole. Although it doesn't apply to my home system, I also treat internet and network (LAN) as one. If all of the other PCs on a LAN aren't under your direct control, they can be just as dangerous as the internet.

    I started with applying default-deny to internet access. No open ports to system components. Unnecessary services disabled. No auto-updating. Applications only get as much internet access as they need to work. Example, the mail handler only has access to the mail/news servers that I use, nowhere else, no incoming. Inbound traffic to apps that require it is restricted to the necessary IPs. Loopback traffic is restricted with most of it routed through Proxomitron. The browsers have to connect through Proxomitron. Kerio doesn't allow them to connect out directly.

    I set up separate administrator and user modes with SSM. User mode is the default setting for all users. User mode is strictly enforced default-deny, whitelist based. In user mode, there's no access to system configuration utilities and components that can alter the registry or register new DLLs. Those are not whitelisted and can't run in user mode. The "window filter" module in SSM prevents users accessing the control panel and most configuration screens. The "window filter" monitors window captions and instantly closes anything that matches the specified list. That includes captions with
    • preferences
    • control panel
    • folder options
    • internet properties
    • password properties
    • the firewall screens
    • "open with"
    • about:config
    • most of the system folders

    This can't be disabled from user mode.
    Installing and updating software can only be done from administrator mode, which is password protected. There's no access to a command prompt. Users can't alter the system.

    This limited the attack surface to apps with internet/network access and content delivered via external devices/media (USB devices, CDs, etc). Autoplay is blocked for everything. For internet content, the formats and file types with their default handlers are dealt with individually. PDFs for instance can only be opened in Foxit and only when saved to disk. The browser can't launch Foxit. As much as possible, most web media is treated the same way, opened in separate, freestanding applications. Most of these have no internet access and very little ability to parent another process. On my 2K system, they're also sandboxed.

    Proxomitron filters all web content to the browser. Java is restricted to whitelisted sites. Javascript permissions are restricted by default and allowed by exception. FlashBlock prevents flash content from autoplaying. The browser cache is on a virtual drive that exists in RAM. Execution from this drive is blocked by SSM.
    Exactly! Most users approach this backwards. Start with formulating a complete policy, then select and configure apps with the intent of best enforcing that policy. Your policy should dictate which apps/methods are best for you.
     
  6. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,943
    Location:
    California
    I intended to be broad, for each user will have to determine how and where specific scenarios fit into the scheme.

    Your infected office document is a good example. For me, it's just another remote code execution exploit, easily handled by anti-execution protection. Here is an example:

    https://www.wilderssecurity.com/showthread.php?t=244726

    For Peter2150 in his small office with several employees, he doesn't want to lock down the systems, as he explained to me, so he uses a Sandbox which would contain any such exploit that ran. (It did with this particular exploit).

    This is a good example of identifying a specific type of exploit/attack vector and deciding what type of protection fits the individual need.

    This is also why I no longer find it useful to recommend a specific security product without knowing the user's setup, computing environment, mindset, and so forth. There are just too many variables.

    ----
    rich
     
  7. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    That statement was referring to the 4 categories listed by ssj100, primarily the first one, Internet. That can potentially include almost everything and IMO, needs to be divided into groups that can be addressed together. Your post was not yet there when I started to reply.
    Very true. Unfortunately, a lot of people here start with installing what they feel or are told is the best security app(s), then try to configure their security around them, exactly the opposite of what they need to be doing.

    There appears to be one thing we're all agreeing on. The security policy or strategy needs to set first, before security software is selected. Software that's ideal for one policy can be almost worthless with another. Sandboxie isn't designed to enforce default-deny, just as SSM isn't ideal for isolating the attack surface. The more detailed and comprehensive the coverage of that policy, the better. It's also clear that there is more than one way to approach the making of that policy. I realize that most of the threads here are about specific apps and that the "newest and greatest" are what gets discussed the most. Features, comparisons, who updates the most, and those abused leaktest comparisons tend to dominate the place. If there was one thing I'd like to see more users understand, it's the importance of laying out a security policy that covers the common usage scenarios, then selecting and configuring their security apps on that basis. At the top of that policy should be a strategy for how new software of any type is installed. I'd very much like to see more discussion about security policy (not just the built in SRP tools) and less about new apps and their bells and whistles.
     
  8. Tarnak

    Tarnak Registered Member

    Joined:
    Feb 5, 2007
    Posts:
    3,875
    While this thread is interesting, from my point of view(what is suitable for my requirements), the policy is simple....keep malware off!

    I don't mind the ins and outs of a classical HIPS, because without using one I would never have discovered/learned what I now know. So, for me using a computer is still about the learning... :)

    P.S. This computer is solely for my own use, I do not download from peer sharing sites.
     
  9. wat0114

    wat0114 Guest

    Email: opening infected attachments, especially when augmented with social engineering tactics.


    I agree. No harm in this at all.

    Count me in on this as being how I also most benefited from using HIPS :thumb:

    Too bad you can't/don't want to run as limited.

    VBox does not need to be sandboxed.
     
    Last edited by a moderator: Sep 7, 2009
  10. SammyJack

    SammyJack Registered Member

    Joined:
    Aug 19, 2009
    Posts:
    129
    SSJ100
    ref:2. Running in administrator mode with SRP enabled.

    I understand that you have a life outside of this Forum,but I wish when you find the time,
    you could provide a tutorial on how to do this,ie,set up SRP from Admin account.

    Really,if I felt I could live with a limited account,(I cant)I would feel less need for SRP.
    I would be willing to jump through a hoop or so,to get SRP without a limited account,
    If for no other reason,it is "the best Anti-Executable".
    (Free also.)
     
  11. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    Why would you go to the effort of stopping writing to those directories as the Admin, when the User group already does what you are talking of doing? I see what you mean, but you are seemingly creating more and more a Users restrictions with SRP.

    Sul.
     
  12. SammyJack

    SammyJack Registered Member

    Joined:
    Aug 19, 2009
    Posts:
    129
    OK,Here is my logic for SRP rather than limited use limited account/SRP.
    I use both Sandboxie and Returnil Premium.
    90% of the time I am surfing/running in Returnil,and 98% of the times
    in Sandboxie. I only come out to update Windows and Spywareblaster.
    I have no real time anti-virus or other programs in need of update,other than Java,and flash.
    I do make use of a number of on-demands however,Avira 9,installed without guard,Malewarbytes,SuperAntiSpyware,in addition to Dr.Web Cureit,Prevx,and HitMan Pro.
    I do not download these to my real disc,I normally either run them sandboxed in Returnil,
    in the case of Malwarebytes,And SuperAntiSpyware,and Prevx,or install them in Returnil,run a scan,reboot,and I am free of all lingering AV remains.
    I am sure a limited account would make this rather eccentric practice impossible.
    I was hoping with SRP,to be able to leave the required exes as exemptions from the policy.
    Maybe my method is madness,but there is a method.
     
    Last edited: Sep 7, 2009
  13. wat0114

    wat0114 Guest

    Sorry, just looking to sub-categorize things a bit.

    ssj, as a compromise to running admin, why not get yourself a pro version of XP or Vista, if you haven't one already, then set up your account as Power user? This will allow you to place limited-like restrictions on key directories such as C:\Windows\* or C:\Program files (Read & execute, List Folder contents, Read). You can have a balance between better security than admin without all the restrictions of limited. If you find you need a little more freedom on a certain directory, you could always give yourself Modify & Write permissions, while avoiding "Full Control", this latter permission being the most nonrestrictive, therefore most dangerous, of all. I ran this way for years no problems before I found I could run as limited nearly hassle free.
     
  14. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    Classic HIPS like SSM get quiet when the configuration is done. With a default-deny security policy preventing most payloads from executing, keeping everything up to date isn't as critical as it would be in a default-permit environment. The "housekeeping" isn't that bad. Most of the time, it's nothing more than instructing the HIPS and/or firewall to recalculate the checksum. None of this is a problem for the other users as they don't have access to any of its screens or settings. That's one of the primary reasons I chose this method, to rule out mistakes by other users.

    There's more than one way to implement a limited account or software restriction policies. It doesn't have to be done with Windows built in tools. Classic HIPS can implement a very flexible version of user and software restriction. Others might not agree with using a separate application for this, especially one that uses global hooks to intercept system calls. For me, it's been very effective, which is what matters in the end.
     
  15. SammyJack

    SammyJack Registered Member

    Joined:
    Aug 19, 2009
    Posts:
    129
    Thanks for the reply Sj100.
    Now that I have taken a look at what is required for SRP and Limited user,I much doubt I can do what I wanted to.
    I have saved the Exes for the on-demands I listed,in a folder,and run them as needed in Returnil/Sandboxie.
    Some like Avira 9,even with the Guard Element not downloaded,do not completely instal for me in Sandboxie,even a default box.
    These I just download in Returnil,run my scan,and when I reboot they are gone.
    Those like Prevx,that run well in Sandboxie are even easier to remove when their on-demand scan is done..
    That's what I meant by exempting the EXEs for these programs,(my on-demands,but also things like media players,such as GomPlayer,ect that I really do not want on my real system,but might use once in awhile)in SRP,so I could continue to follow my practice.

    One of Returnil's features is a simple anti-executable module,that I have enabled.
    It is pretty narrow, (but should suffice to protect Returnil).
    My Hope with SRP, was to be able to load the exes for my on-demands,while gaining greater Anti-Executable Protection otherwise.
    Now I thank maybe I will look more at power user for XP Pro (I Have Pro),or better yet leave well enough alone,and refine the system I have now.

    Please forgive spelling,syntax,etc. 6th can of export lager.
     
    Last edited: Sep 7, 2009
  16. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    I wonder, why does one need to be Admin? What is it that is so inconvenient about LUA? I know for myself, if I am not playing a game or posting here, I am either watching netflix or coding/playing with the OS. For me, it is easiest to drop my internet facing applications into User mode, because I don't really do much with the internet in that way. I do more as an Admin, but locally without any real fear of 'something' getting in to exploit. I have SBIE or vmWare if I really want to get serious anyway.

    But let me ask, those still using Admin, what is it that keeps you using Admin instead of LUA? Why is it that you will put great efforts into using SRP or HIPS or whatever? Is is really something you need admin for? Or if it is only convenience, what exactly is it that you do that requires admin? Is it chaning registry settings all the time? Is it changing network data? Is it installing applications?

    No really, what is so irritating about LUA? I get irritated by it. But what is your reason. My grandmother and wife get semi-irritated because they don't exactly understand what SBIE does, what recovering means, for that matter really what a directory is. They typically get frustrated when they want to install something they want to use and cannot. Thier frustrations are simple. My thoughts go towards finding ways to ease thier simplistic frustrations.

    Is it not plausible, that if you don't actually need Admin in the majority of what you do with your computer, that perhaps it would be best to define what the irritations with LUA are commonly, and find ways to alleviate the common factors?

    LUA or some form of running as something other than an Admin is, the more I think about it, the wise solution.

    Just some random thoughts I have been mulling over lately.

    Sul.
     
  17. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    I could write a really long and technical post about this topic. But that would be boring to probably everyone except me. Therefore I'll just say it in short: No, there is simply no way to prevent admins from writing anywhere they please without taking away their admin privileges and making them limited users. Further, to even think about taking away the admin's write access into system folders is just plain silly (to use a word that is nicer than some other words that would fit the situation somewhat better). If you want this kind of restriction, you must use a limited user account instead of admin. It is pointless and harmful to try to break an admin account like this, when limited user accounts already have perfectly working restrictions that don't make the system unstable and unpredictable. If you could live with an admin account that can't write into system folders, then what on earth makes it impossible for you to live with a limited user account? As Sully suggested, consider that seriously. What can you do as admin that you can't do as a limited user, that you need to do often and that will be too annoying or too difficult to do with a simple RunAs or switching users? My theory is that some people just don't want to give LUA a serious try, but are willing to spend hours and even days constantly tweaking a complex security setup while using an admin account. Honestly, if folks spent even half as much time configuring LUA as they spend musing over security software and testing random setups, LUA would be simpler than a very simple breeze. :D

    Let's take one example. If you have an admin account that can't write into Windows or Program Files, guess what? Most of those installers that fail as LUA will also fail in such an admin account, because they expect to be able to write into Program Files or even the Windows folder. So now you've got an admin account that can't install legit software. Not good. To get around this, you would have to change the permissions for those folders every time you want to install something that may not install properly in LUA. One thing should be immediately obvious at this point: changing those permissions is a lot more work than just using RunAs from a limited user account, or even just logging out of LUA and logging in to an admin account. So, a configuration like this would be far more inconvenient than using LUA. Therefore it's pointless.


    And then there's the availability problem. Where are you going to get AE 2.3? Isn't it an old version that is no longer distributed by Faronics?
     
  18. Dregg Heda

    Dregg Heda Registered Member

    Joined:
    Dec 13, 2008
    Posts:
    830
    Windchild:

    Would SuRun prevent privilege escalation exploits?
     
  19. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    Why not? Because "full power and access" and "bullet-proof security" are mutually exclusive of each other. They are polar opposites. Increasing security decreases convenience in one way or the other. That is the tradeoff of security, always. You cannot have complete control over something for "full access" and at the same time have limited control over it for "security"! :D

    What you're trying to do is on one hand have admin's full access to everything for convenience, and on the other hand try to limit and disable parts of that access for security by adding complex third party security software into the system and enabling the operating system's built-in security features like SRP that are at their most effective only when used with LUA.

    People are of course free to do as they please, but sometimes people do things that just aren't logical.


    Actually, what you're doing is the opposite of simplifying the configuration. The simple option is running as LUA and switching to admin when you need to do adminny things, like installing software for all users. The complex option is what you're doing: always being admin but adding virtualization, sandboxes, anti-executables and everything and thinking about limiting what write privileges admins have into system folders, and all this only to try to limit the inherently limitless control the admin account has over the system - ironically, the very same limitless control that you wanted to have for convenience. Think about it: if you use something like SRP or Anti-Executable to prevent a new program from being executed, then you've already given up the full access that you wanted to have, because you can't even do something as basic as executing a new program without turning off some security feature or another. That is the loss of convenience (have to disable something to run a new program) to gain some security (can't run new programs without my permission).

    Finding the ideal setup is a great goal. But I suggest people approach that less by trial and error and more by logic and policy. Plan what you need, and then research how you can do that. Instead of acting based on emotions (this feels nasty, or I don't like this HIPS product, or this feels inconvenient even though I haven't really tried it for more than a couple of days) act based on facts. Make comparisons. For example, which is more inconvenient, a simple RunAs to install software or changing permissions for system folders every time you want to install something? Ask questions, and find the facts to give you the answers.
    - What do I need done? For one, I need to limit write access to system folders.
    - What is the most effective and simple way to do that? LUA.

    Unfortunately many of the people who have some interest in Windows security have never used Unix. If they had, they'd already know it's not smart to be root (=admin) all the time.
     
    Last edited: Sep 7, 2009
  20. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    Obviously not. It might prevent some ways to gain admin privileges, such as keylogging the admin password when using RunAs, but it won't do anything against real privilege escalation vulnerabilities in the kernel or installed software, and will do nothing against poorly configured permissions for system files or services and such that can provide a way to escalate privileges.
     
  21. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    I'm not really trying to go for grandiose. I'm just making this up as I go, so to speak. :D I also certainly don't try to belittle anyone and have no desire to do that. But I do try to avoid being too vague, and if that requires me to say that something is logically impossible or that something is ineffective and pointless, I'll say it. It's a little blunt, sure, but I think it's better to be blunt than misleading when there is no other choice.

    Anyway, wat0114 seems to use VirtualBox in LUA effectively, so he could be the man to help you with that if problems turn up. In any case, it is inevitable in LUA that sooner or later you have to elevate to admin to do something, such as install a software for all users. It's the nature of the beast, and how it's supposed to be. That's how it is in all other multi-user operating systems as well. Windows users just aren't used to it, because the default has been running with admin privileges. Once you get used to it, it's really not a problem. The problems only start when you find a software that is so poorly designed it doesn't work in LUA even if it should (some programs can't work in LUA, no matter how well designed they are, due to what they do conflicting with LUA limitations). My solution to those is to use better software - I don't want to run software coded by someone who thinks we're still all running DOS! :D

    But, I digress. Understanding how the system works is certainly a good thing, and playing around with the system can be a good learning experience. Often, though, logical thinking can give us the answers we need even without testing. That can't be a bad thing. :)
     
  22. pbw3

    pbw3 Registered Member

    Joined:
    Nov 12, 2007
    Posts:
    113
    Location:
    UK
    Totally agree..

    I always use to run machines in admin mode before this laptop - this is the first time since pre Windows that I have adopted the LUA route. The more I use it, the more I realise how easy it is in its current form, and again how unnecessary always being in the Admin account is (as a "user").. However, I will add the caveat that this is running in Vista, which really does make "life in an LUA" fairly effortless (for me at least) - once you understand what it is doing and if using UAC to make it easier - and especially with fast switching and "run as"..

    SRP is actually slightly more restrictive (for me) than LUA because, in Vista, SRP seems inconsistent with where it will allow "run as" to operate from, some folder locations will be blocked by the SRP policy BEFORE the UAC elevation prompt has the chance to appear, others not - and probably for good reason that I simply haven't yet worked out.. But the additional security gained from the principle of default deny hugely outweighs any trivial inconveniences - the key is simply knowing what to expect from it..

    I used to look at security and consider that "being careful" was the key difference between avoiding malware and risking being exposed, especially when running without an AV - and a few years ago that may have been true to some extent.. Now, with a change of tack and despite there being much more malware around, I wonder how anything could get onto the machine provided that I did not enter the admin password. Ie If I did not know the admin password, could I get infected even if I was pretty careless.. and increasingly the answer "appears" (and that is ever all it can be) to be no - and whether there is an AV on the machine or not is completely irrelevant to that assessment. In that context, a key concern is ensuring that no complacency sets in.

    One other concern I might have is in fact a very selfish one.. If everyone were to use LUA / SRP, weaknesses no doubt would be found and malware exploits would abound.. As a thread concerning policy and approaches, as others have pointed out - one could suggest that obscurity can be a very worthy part of any security policy.. Therefore, may I (very mischievously) raise a glass to the wonderful convenience and simplicity of admin accounts, and to all those who sail in them..;)

    Peter
     
  23. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    Well, I would not say it's "wrong." I'd say it's simply one way to do things that works in some cases but does not work in others. Sometimes you need to test to find out something. Sometimes you can find the answer without testing. Whatever works for the situation.

    No, I have not tried it. But obviously you can largely know what some things do without trying them yourself. As for your setup with Sandboxie, your detailed posts on that subject have already told me what it does in sufficient detail for my interests, and it's obviously not something that fits my needs. That setup, after all, fails my very first criterion: I don't want to install any third party software that messes with the kernel unless I need to, and that rules out Sandboxie immediately. I don't need to try it to see that, and I'm already pleased with what I have. That's the critical difference between me and some other people as far as these discussions are concerned: I'm not looking to improve or change or test or evaluate my security setup, so I don't have any reason to try different setups, as I'm completely pleased with what I have now and will only consider changing my security policy if the threat landscape changes so radically it forces me to change it or face losing a reasonable level of security. If I was here to ask questions or seek the ideal security setup for myself, then I would suggest to myself that I need to try some things to see how they work for me and use that information to decide. But since I'm not seeking to change my setup or ask questions, I won't suggest that to myself. So, it's not really strange at all for me to refuse to try some things while I still suggest others to try some things. If others are looking for an ideal setup, they could possibly benefit from trying various things seriously. I'm not looking, so I don't have any reason to. For those people who are trying out different things in their setup, I can see a reason to encourage trying something like LUA seriously. Who knows, maybe they'll like it! If they don't, then they'll at least know why they don't like it and what's wrong with it for them, instead of just having a vague prejudice against it based more on emotion than actual user experience in the long term. For example, many people I've met have said that "LUA is impossible to use" without ever actually trying it. They just repeat that mantra because they heard someone say it once. Then, when I manage to convince them to try it, suddenly most of them realize that they were wrong and that LUA isn't impossible to use at all but is actually very convenient as long as you're running decent software made for NT. :)

    But this is getting long again, so... :D Good luck with the LUA + SRP + Sandboxie setup. And for fairness, try to be as patient with LUA as you've been with Sandboxie and all those other security products. If something in Sandboxie or another security software doesn't work as expected, you don't just immediately ditch it, do you? No, instead you post threads about it and discuss it with others who use the software. But yet some people try LUA, find one irrelevant piece of software that doesn't work perfectly in LUA because it was coded by people who haven't gotten over DOS, and then they ditch LUA and state that it sucks, all because of a third party program being coded badly! :D
     
  24. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,943
    Location:
    California
    I've always run as Administrator. It's my computer, I'm the only User and Administrator, so there!

    The only stuff I install in Program Files is that which won't permit me to put elsewhere on another partition.

    As far as security: all exploits in the Wild I've looked at are blocked either by the properly-configured firewall or the properly-configured browser. Using Anti-Executable in testing: I have to disable some configuration in the browser to watch the exploit run and then see it blocked by AE.

    So I will challenge the skeptics to show me a URL for an exploit in the wild and I'll see if the Browser can't handle it!

    ----
    rich
     
    Last edited: Sep 7, 2009
  25. sun88

    sun88 Registered Member

    Joined:
    Aug 27, 2009
    Posts:
    66
    The number one attack vector is installing downloaded software. Just for example, some people are installing the Iron browser (and I'm not suggesting there's anything wrong with it). You can't be sure it doesn't include backdoors, or spyware. So you have to (1 - monitor the installation in some way so that you feel somewhat confident that it hasn't compromised your security. And after the install process is complete, you would want to (2 - scan your system from time to time to see if any dangerous files have been dropped during the install or during execution of the program. And you would want to (3 - monitor your system memory for any active malware, and (4 - have a behavior analyzer to block and report suspicious activity on a continuing basis.

    This is why I don't agree with the OP, and I flatly reject his claims that his approach can keep you safe and confident. There are so many ways hackers can find to subvert your system that it's foolish to think you don't need to continually monitor it.

    Yes, many activities can be confined to a sandbox or a virtual machine, but there are many programs that have to be installed and executed in the traditional way. Sandboxie is itself a potential danger, for example. You have no way of knowing exactly what it does, and whether it compromises your system either intentionally or unintentionally.

    How many software companies can you truly trust?
     
Loading...
Thread Status:
Not open for further replies.