View Full Version : Malware attack vectors - approaches and setups to block these?
ssj100
September 6th, 2009, 02:39 AM
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.
mark.eleven
September 6th, 2009, 03:45 AM
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.
Windchild
September 6th, 2009, 04:36 AM
A quick comment:
-{ Quote: "
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).
" }-
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.
Rmus
September 6th, 2009, 11:59 AM
-{ Quote: "So what are the potential malware attack vectors? " }-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
-{ Quote: "So what is the best approach and security setup to block these attack vectors? " }-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
noone_particular
September 6th, 2009, 01:01 PM
-{ Quote: "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." }-
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.
-{ Quote: "From my point of view, the more comprehensive and thought-out the Policies and Procedures, the fewer security products required." }-
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.
Rmus
September 6th, 2009, 02:58 PM
-{ Quote: "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)? " }-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:
http://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
noone_particular
September 6th, 2009, 08:58 PM
-{ Quote: "-{ Quote: "
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)? " }-I intended to be broad, for each user will have to determine how and where specific scenarios fit into the scheme." }-
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.
-{ Quote: "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." }-
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.
Tarnak
September 6th, 2009, 11:41 PM
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.
wat0114
September 7th, 2009, 12:12 AM
-{ Quote: "4. Others? People might want to fill me in here, as I can't think of any other attack vectors for now. " }-
Email: opening infected attachments, especially when augmented with social engineering tactics.
-{ Quote: "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 agree. No harm in this at all.
-{ Quote: "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." }-
Count me in on this as being how I also most benefited from using HIPS :thumb:
-{ Quote: "Security Setup:
2. Running in administrator mode with SRP enabled" }-
Too bad you can't/don't want to run as limited.
-{ Quote: "5. VirtualBox on-demand
a) Run sandboxed when testing newly introduced files (before executing on real system), known malware, and operating systems." }-
VBox does not need to be sandboxed.
SammyJack
September 7th, 2009, 01:06 AM
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.)
Sully
September 7th, 2009, 01:17 AM
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.
SammyJack
September 7th, 2009, 02:01 AM
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.
wat0114
September 7th, 2009, 02:17 AM
-{ Quote: "Yes, that would come under "Internet", since e-mail comes from the internet...unless you're talking about "Intranet", and I'm fairly sure most home users don't have to worry about anything like that." }-
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.
noone_particular
September 7th, 2009, 02:45 AM
-{ Quote: "I think we should also aim to keep things simple and thus minimise any chance of "user error". Personally, this is one of the main reasons why I no longer use a classical HIPS - if I didn't mind dealing with a lot of pop-ups, then it would be fine...however, if I configured the classical HIPS so its "pop-up-free", there is a lot of potential for "user error" here, as there is a lot of digging into the HIPS and manually switching in and out of configurations. Just my opinion though (because I'm no classical HIPS expert, and I dislike all the "house-keeping" that goes with it when updating trusted applications in particular)." }-
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.
SammyJack
September 7th, 2009, 03:38 AM
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.
Sully
September 7th, 2009, 05:05 AM
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.
Windchild
September 7th, 2009, 06:14 AM
-{ Quote: "So the question is whether there is a simple method of preventing write access to C:\Programs files and C:\Windows while running as admin? If this can be achieved, then my setup above would indeed be bullet-proof, all while running as admin.
I'm currently not at home, but I have thought of a couple of possible solutions:
A) Simply use Windows XP folder rules to deny write access to the folders C:\Program Files and C:\Windows. The following are some issues I can see with doing this though:
1. Are there files that need to be written to C:\Windows for normal computer functioning (eg. Prefetching).
2. Increased inconvenience when wanting to update trusted applications or install new trusted applications - you would first need to change your SRP default rule to "Unrestricted", and then you would further need to disable the write access deny rule to C:\Windows and C:\Program files." }-
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.
-{ Quote: "B) Add AE 2.3 to the security setup to deny all executions not on the white-list.
The only disadvantage here is simply that the security setup requires the addition of another program - AE 2.3." }-
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?
Dregg Heda
September 7th, 2009, 06:28 AM
Windchild:
Would SuRun prevent privilege escalation exploits?
Windchild
September 7th, 2009, 06:38 AM
-{ Quote: "Thanks for the suggestion and it sounds like a viable option. However, I am simply trying to avoid having different accounts like this. Why not just run as administrator and have full power and access (and thus excellent convenience) while also having bullet-proof security?" }-
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.
-{ Quote: "I'm trying to simplify here (believe it or not), and not create more complications. The hard work is of course getting to the ideal setup for yourself. I'm rather enjoying this hard work though, as I've learned quite a lot about my system and how I want it setup.
" }-
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.
Windchild
September 7th, 2009, 06:39 AM
-{ Quote: "Would SuRun prevent privilege escalation exploits?" }-
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.
Windchild
September 7th, 2009, 07:27 AM
-{ Quote: "Yes, you make extremely good points about LUA, and I have tried to make it work before. I know the power of LUA, and I will try it again soon to see if I can do what I want in it.
I am concerned about using VirtualBox in LUA with guest additions - I'm not sure if it would function correctly and smoothly - last time I tried, it did not. Perhaps things have been updated to run more smoothly in LUA now.
You seem to have a very grandiose tone to your posts lately, which is fine by me though. You definitely know what you're talking about. However, please don't belittle me (I know you probably don't mean to) at working hard with my software and my Windows OS - this process has led me to understand my system much better.
Anyway, I'll update this thread as I discover what works best for me!" }-
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. :)
pbw3
September 7th, 2009, 07:58 AM
-{ Quote: "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." }-
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
Windchild
September 7th, 2009, 09:25 AM
-{ Quote: "Indeed, but sometimes you need to trial and error to work out what's best for you. Get answers without testing? Wrong, people learn in different ways, and some people like to try things out to see what works best for them. That is a good thing." }-
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.
-{ Quote: "Have you actually tried running as administrator with the setup I proposed which includes Sandboxie? It actually works really well, and is highly convenient. It's strange how you criticise people for not trying things out, when you do the same thing.
" }-
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
Rmus
September 7th, 2009, 11:14 AM
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
sun88
September 7th, 2009, 12:09 PM
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?
Sully
September 7th, 2009, 12:11 PM
-{ Quote: "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" }-
You know I don't ever attempt to raise problems. I have questions. Is your 'method' then to only allow certain sites any scripting or content privelages in the browser? And I already know you use the shall we say 'obscure' browser Opera to do this with.
Once you have, I presume, allowed a website to gain your 'trust' by adding it to the list of allowed to run scripts, what provisions do you have in place for 'IF' that website were to ever be compromised?
What do you do about emails? I open them as plain text always, but there are times I admit when I must follow a link or allow rich context.
I currently use SRP to reduce my applications that interact online to Basic User.
So I am wondering, as there are always holes, how you plug them?
Thanks for any insight you care to share.
Sul.
Sully
September 7th, 2009, 12:23 PM
@Windchild
I think more and more about LUA, about how I use my computer, and how LUA is more of a hinderance to me. I understand, I am doing much to my computer rather than just using it like an average novice. For me then, LUA really does pose problems, as 75% of what I do requires admin. But, the more I deal with issues of the day with family and friends, the more I see one very clear fact. In XP, which many still have, the most common complaint is 'I can't install this program'. Using RunAs or SuRun then, I see this problem developing, where this average user who only knows how to surf and save pictures from thier camera, they need to install something. So whether SuRun or RunAs, they basically give the OK to do so. I suspect from my limited support of Vista/7, that UAC is basically 'Allowed' in the same manner.
So, while I can agree more and more, especially for the novice, that LUA poses a good solution, I still see the downfall of LUA/UAC where the novice just assumes they need to install something so they know the admin credentials and fling it around as they please. They don't have the aptitude or the desire really to check into what they are doing, they just want to do it.
Here is my question, not just limited to you though :) . What is considered protection, when the user themselves elevate anything they desire to admin when needed? What is the backup? If they elevate, root is acquired and the game is over. I struggle with this, and no, I don't believe the time is anywhere near to when the user will decide they must invest the time to gain knowledge.
Put it this way, with the current state of the economy, I know more and more who are doing things online now. Banking, paying bills, buying, etc. More than ever, my family and friends who only used to surf and such, are turning to more modern means of using the internet. Which of course is only just starting to show itself to me as various problems the more they use it. LUA is a great option for them, but still there exists the last straw. When they do elevate, what is left.
So I pose this puzzle. And perhaps it is not a puzzle at all, but I have a hard time seeing the solution if it is present, for them. For those Wilder-ites that are into this stuff, it is a different matter completely.
Sul.
StevieO
September 7th, 2009, 12:47 PM
The number 1 way i see peoples PC's getting infected, is through P2P filesharing. This is mainly kids/teenagers, but not exclusively, downloading dreadful pirated mp3's etc and, video files.
Often they get what they want, but not always what the're looking for lol. A lot of them are running with ActiveX/Scripting/Java etc etc running freely. Even if ActiveX isn't, the other stuff nearly always is.
Whenever i've tried to show them, and their parents, how to configure things better, most find it all very confusing. Plus they just want to surf etc without any restrictions, even though they now know why they shouldn't !
I gave up a while back trying to show people how to work with HIPS etc. It was too much for them, and i was just wasting my time.
Returnil however was received quite well with some people. But due to various serious unresolved problems with it, unfortunately i can't recommend it right now.
For most people out there in www land, i don't see an immediate solution i'm afraid.
Rmus
September 7th, 2009, 12:51 PM
-{ Quote: "Is your 'method' then to only allow certain sites any scripting or content privelages in the browser? And I already know you use the shall we say 'obscure' browser Opera to do this with. " }-Yes, this 'obscure' browser permits per-site configuration for cookies, content, scripting, etc:
211966
-{ Quote: "Once you have, I presume, allowed a website to gain your 'trust' by adding it to the list of allowed to run scripts, what provisions do you have in place for 'IF' that website were to ever be compromised?" }-Well, I've only five sites configured for scripting (Wilders being one) and I'm not too worried about these being compromised.
For that type of exploit you refer to: I've tested this scenario in other threads, where, using a compromised site with an injected script to install a rogue security product, I let the script run which connects out to the malware site which uses a script to download the fake scanner. The script on that site will not run because it hasn't been given prior permisson to run scripts.
-{ Quote: "What do you do about emails? I open them as plain text always, but there are times I admit when I must follow a link or allow rich context." }-My email/newsreader is Forte Agent which is text-based.
The following-a-link exploit in an email to a bad site with a script would be the same as following a compromised link in a Google search (very common exploit these days): any script on that link just wouldn't run. For an example of what can happen:
http://www.dslreports.com/forum/r22983647-Antivirus-Pro-2010
-{ Quote: "was searching on a older laptop with avg 8.5 and somehow got infected with antivirus pro 2010 on google? All I did was search for Office 2007, then my pc restared and the rogue a/v was running!!
......
It was probably installed through a script on a compromised site you visited. That's where using FireFox with the NoScript add-on can help." }--{ Quote: "So I am wondering, as there are always holes, how you plug them?" }-I look at current exploits in the wild and see if I'm covered (holes plugged). That's about it.
----
rich
wat0114
September 7th, 2009, 03:59 PM
-{ Quote: "
Anyway, wat0114 seems to use VirtualBox in LUA effectively, so he could be the man to help you with that if problems turn up. " }-
Exactly what I'm doing completely problem free. I run an XP VBox limited account on a host Vista limited account, and it runs smooth as butter :thumb:
As for those complaining there are too many restrictions running admin, well, if the majority use their machines like I use mine, they are surfing, opening emails, playing tunes on their media player, watching youtube vids, working with text editors or spreadsheet programs. Very typical stuff. All this is easily done in limited mode, so bs to those saying it's difficult or too restrictive. It wasn't long ago I argued against limited, thinking the same thing as some others that it would be too restrictive (I ran Power user for years), but I was proven wrong; for my needs then and now I can easily function as limited. For someone like Sully and perhaps Rmus who require admin privs most of the time, then sure, it is understandable they run admin, but I'm convinced the majority of home users can run limited. if a program doesn't work properly in limited, then it is the program's issue; poor coding the developer should fix. It's that simple.
Sorry for the rant but but there is no way it is that much hassle to take a few seconds to switch to admin or use Run as.. for the few times admin access is needed. The trade-off for a few extra minutes out of the day for far better security than full-time admin use is well worth it.
-{ Quote: "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." }-
Sorry sun88, I don't buy this one iota. Download software from the trusted site - the developers - and it is 99.999997% guaranteed safe. If there is any doubt, run it sandboxed or in a virtual machine to look at its initial behaviour.
Windchild
September 7th, 2009, 05:28 PM
-{ Quote: "
How many software companies can you truly trust?" }-
Yes, this is a valid point. But there's a problem. Most people will have to trust someone. You're likely to trust the tools you use to monitor what other software does on your system. You're likely to trust the OS (or if you don't, then you're already owned by my definition of the word, because everything you run in the system is running on an untrusted base, the OS - the untrusted OS). You're likely to trust quite a few pieces of software. And most certainly no-one in this forum, not even the people who make security software for a living, have completely reverse-engineered every single piece of software they're running and gone through every single line of code to make sure there aren't any malicious surprises in there, waiting for them. If someone has compiled their own OS, have they checked the compiler? Have they checked the compiler that was used to compile that compiler? ;D
Before I get any more tedious, my point is obviously that while we shouldn't carelessly trust everyone, we have to trust quite a lot of sources. For Joe User, meticulously monitoring and analyzing software for possibly suspicious behaviour is absolutely impossible. Joe User has neither the skills nor the time resources to even attempt that. Therefore Joe User just has to trust a lot of folks. Joe User just has to find the right folks to trust, and that isn't as hard as one might think, even for someone with no real skill in computer security, as long as they're capable of logical thinking.
-{ Quote: "But, the more I deal with issues of the day with family and friends, the more I see one very clear fact. In XP, which many still have, the most common complaint is 'I can't install this program'. Using RunAs or SuRun then, I see this problem developing, where this average user who only knows how to surf and save pictures from thier camera, they need to install something. So whether SuRun or RunAs, they basically give the OK to do so. I suspect from my limited support of Vista/7, that UAC is basically 'Allowed' in the same manner.
So, while I can agree more and more, especially for the novice, that LUA poses a good solution, I still see the downfall of LUA/UAC where the novice just assumes they need to install something so they know the admin credentials and fling it around as they please. They don't have the aptitude or the desire really to check into what they are doing, they just want to do it.
Here is my question, not just limited to you though :) . What is considered protection, when the user themselves elevate anything they desire to admin when needed? What is the backup? If they elevate, root is acquired and the game is over. I struggle with this, and no, I don't believe the time is anywhere near to when the user will decide they must invest the time to gain knowledge.
Put it this way, with the current state of the economy, I know more and more who are doing things online now. Banking, paying bills, buying, etc. More than ever, my family and friends who only used to surf and such, are turning to more modern means of using the internet. Which of course is only just starting to show itself to me as various problems the more they use it. LUA is a great option for them, but still there exists the last straw. When they do elevate, what is left.
" }-
First, I'd like to state the obvious again. ;) Guys like you and Rmus don't need to run as LUA. I don't need to run as LUA. Many other guys in the forum don't need to run as LUA. Most likely none of us are going to get owned even if we don't run as LUA. In any decent security forums, there are many people who can be reasonably safe without LUA, or without any security software at all. But, many of these people could still benefit from LUA, like I do. Some, of course, really can't do it, due to the things they do to the system all the time. For someone who spends all day tweaking stuff in HKLM and loading drivers and installing software, LUA is a very bad option indeed and it isn't even meant for that sort of use. Admin accounts exist for a reason, after all. In any case running LUA sets a good example to Joe User, who needs LUA a whole big lot more than some wacky forumites such as myself do! Therefore, I will recommend LUA, and I will run LUA, even though I can personally survive without it, and have.
Now, to your question: "What is considered protection, when the user themselves elevate anything they desire to admin when needed?"
Sadly, we all know the answer, don't we. If we assume the user is terminally ignorant about security (ignorance is "okay" - I'm ignorant about some things, someone else is ignorant about some other things) and our assumption happens to be correct, then nothing except blacklisting software is left and even that is only a very weak partial solution. HIPS, anti-executables and other similarly advanced security products will not work, because if the user really wants to install something, they bloody well will install it no matter how many warnings or prompts they are given, and if nothing else works, they will turn off the annoying security software. The problem is, the users are used to seeing these products warn about every install, even the known good ones. So, in these cases, either a blacklisting software detects the malicious file and forcefully deletes it before the user can run it and keeps on warning the user about the file being a VIRUS!!!11!! or the blacklisting software doesn't detect it and they get owned. Sometimes the user may actually believe the blacklisting software, because usually the blacklisting software doesn't warn them about every single install, although if the user has seen many false positives, that may be too much to hope and the user will just turn off the AV as well.
So, yeah, blacklisting is the only thing that's left. It may not be the most fashionable idea in the world, but it's better than nothing. In those cases where I can convince a "I will install anything without a moment's thought" type of user into running LUA, I'll also convince them to run an AV and use a browser that has at least some form of phish/malware site warnings for well-known bad sites.
Ultimately, we must accept reality. If the user is seriously ignorant, then he is, and nothing can really protect the system. Except not giving him the option to trust new things: don't give him the admin password, don't let him disable security software, and so on, which is typically not an option when it's their computer. Blacklisting, like a decent AV, can sometimes warn the user when they've decided to install something that is actually bad, and sometimes it may save the day, but not always. LUA, HIPS products, anti-executables, whitelisting - these can rather effectively protect the user from the silent, remote code execution type attacks that don't use social engineering, so they are not useless even when the user is ignorant.
Unfortunate fact of life it is, then, that the user can be the weakest link and frequently is. Security measures like LUA can help protect the user from some things, but can't defeat the full power of human ignorance unleashed.
Joeythedude
September 7th, 2009, 06:15 PM
Whats needed is an attitude of dis-trust towards the internet.
That means being suspicious of a pop-ups when browsing
That means being suspicious of applications they download from the internet.
Most people on wilders have that, while the typical PC user does not.
This would be say 50% of security right there.
However drive-by-downloads & phishing cause fear because it seems that they are outside a users control.
They are not , you just need to learn a bit about how they work and work against them.
But they are like the very smart car-thief or scam artist , you just need to put a bit of effort into understanding and combating them.
And its an inconvenience to combat them.
I think a lot of the discussion here is focusing on making the second 50% less of an inconvenience to us wilders folk - Which is exactly what I like :)
But that first 50% would be a great first step even if people didn't bother with the rest of it.
trjam
September 7th, 2009, 07:20 PM
you folks know about computers. Me, I know also what it takes to not get infected. And it isnt the Bill of Rights.;)
Oh, and I am Admin on all machines.
Rmus
September 7th, 2009, 07:26 PM
Thanks, Windchild, for putting into simple, readable, non-technobabble language what I and I think many others, would like to have said!
Several comments within the framework of my two "categories" of malware attack vectors:
1) Remote Code Execution
-{ Quote: "LUA, HIPS products, anti-executables, whitelisting - these can rather effectively protect the user from the silent, remote code execution type attacks that don't use social engineering, so they are not useless even when the user is ignorant. " }-(my emphasis)
2) User chooses to install
-{ Quote: "Most people will have to trust someone...nothing except blacklisting software is left and even that is only a very weak partial solution. " }-You are saying the user has two choices:
trust the source
trust the scanner (blacklist)
(Or use both)
This in a nutshell is the whole of computer security boiled down to two broad areas. From this point forward, each user takes specific scenarios and decides how to deal with them. Many have already been suggested in this thread.
As I and noone_particular and others have suggested, policies and procedures are a great first step: dealing with email and attachments; using only vendor sites to update; and so forth. It gets the brain in sync with what the day-to-day actions are. Then, security products specific to the situation can be applied, and we've seen enough examples of this already.
The big hurdle is "Joe User," as you've stated. Everyone who has contributed to this thread is capable of passing good security information on to less informed people we come in contact with, and that's really all we can do.
One other comment: we love to give advice in these forums. The most difficult poster to deal with is one who writes, "Rate My Security." How can anyone do that without knowing specifically what the poster's day-to-day computing habits are?
My favorite example: Earlier this year in another forum, this type of post came, and after much back and forth, with most respondents using the opportunity to list their favorite AV and other stuff, the poster revealed that he had a LAN. Did he have a router? Yes, he had recently purchased one. Had he changed the default password? No. How did he control file sharing? Hadn't given that any thought. It turns out that those ports were open. How were the other workstations on his LAN set up security-wise? And so forth. A can of worms was opened!
Speaking of worms: the Conficker worm would have a great party with him. Susan Bradly, MVP, was the first (I think) to warn in a Windows Secrets newsletter earler this year that having a router/firewall didn't automatically protect against Conficker where ports were open for file sharing. Conficker also had a built-in dictionary attack used to install itself along a network by guessing weak passwords by brute force. Hence, the hundreds/thousands of computers on local and corporate networks that became members in the Conficker botnet.
(This was before the USB version of conficker emerged. Also of note is that the Remote Procedure Call (RPC) vulnerability in Windows that Conficker had exploited had been patched by Microsoft for two months before Conficker emerged on the scene. What part does patching play in one's security strategy?)
That's why, as I've stated before, I no longer think it is useful (in most cases) to recommend specific products without knowing details of the user's computing habits.
ssj100 and Peter2150 have demonstrated the robustness of the Sandbox. Is that solution the best for everyone?
Setting up LUAs on a multi-user computer may be an ideal solution in that situation. For single-users, maybe so, maybe not. But who can know from a distance? And who can judge?
-{ Quote: "If you read the original post of this thread, I was trying to be more specific with how we can protect ourselves from malware attack vectors. Now, perhaps the indirect message or goal of this thread was to open some people's eyes up as to what they are actually protecting against when they install security software X. Will software security X protect you in the important and common situations of malware attack? Or do you also need to have awareness and a good "security approach"?
Hopefully this thread has provided some "detailed" answers to those questions, and with good justification too." }-I think it has - thanks for starting it!
----
rich
sun88
September 7th, 2009, 08:04 PM
-{ Quote: "Hi, an interesting perspective. How do you think people should "continually monitor" their system?" }-With say real-time pkgs like, Avira, WinPatrol, DefenseWall, Mamutu, Prevx Edge, etc.
Occasionally run Malwarebytes, SuperAntiVirus, RootRepeal, etc.
My point is that you shouldn't just set up a defensive system using SandBoxie. and a firewall, and pretend that you are safe.
Furthermore, you failed to note that you are most vulnerable to being infected by malware, when you are installing software, not when you are casually surfing the web.
SammyJack
September 8th, 2009, 12:50 AM
-{ Quote: "
Furthermore, you failed to note that you are most vulnerable to being infected by malware, when you are installing software, not when you are casually surfing the web." }-
Au Contraire, I thank that point has been made.
Speaking for myself that is one of my smallest concerns,as nothing but trusted
(gotta trust someone!!) programs ever make it on to my real system.
Anything "if-ie" is installed in Returnil and if possible Sandboxie within Returnil,allowed to do its thing,and document conversions etc made by the software are scanned by any of a number of ondemands,saved to the real disc,and the Sandbox emptied,and Returnil booted out of.
During the time the program is active in the Sandbox its calling out can be easily blocked with restrict Internet access.
If the program will not install in Sandboxie,it is still in Returnil,and its
on-line ambitions can be thwarted by any two way firewall.
The program exes are of course scanned for anything a black lister can detect.
Sully
September 8th, 2009, 02:28 AM
-{ Quote: "Please note that I don't think it's fair to say that Sandboxie could go rogue and start infecting my computer with malware." }-
SBIE should be treated the same as SRP or vmWare. They are effective and safe, and to be honest they can be trusted. However, there always exists the exploit. SBIEs popularity sets it as a larger target than the more obscure SRP. But, any tool used to provide security, as it grows in popularity, I would assume it is also thought that breaking it provides some kind of payload for criminals etc.
So yes ssj100, I think we can trust SBIE, but I have no doubt it is not foolproof. It is only whether tzuk stays on top of any exploits found, and how widespread an exploit could become in a short time. Yet one more reason to applaud those tools that offer lifetime upgrades. This one small thing can make such a great difference. And as active as tzuk is, as popular as SBIE, as many advanced users there are, it would make sense that even when an exploit surfaces, the reaction time to mend the hole will be fast. Thus ensuring further trust of SBIE. If SRP ever finally becomes exploited on any scale, it will depend on M$ to patch the exploit. Those relying on SRP will have to wait for big brother, which may not be too swift.
Of course, first there has to be an exploit found before anything can happen ;)
Sul.
Windchild
September 8th, 2009, 05:30 AM
-{ Quote: "
I suppose the inconvenience of using LUA can easily be accepted - switching to admin only takes about 10-15 seconds when you want to update programs or install new applications or defragment your system or use CCleaner and other similar programs. It's also a very "clean" way of doing things. Also, perhaps it'll promote less time wasting with doing "house-keeping" on my computer and instead use it more for entertainment haha." }-
I agree with that, certainly. ;D The inconvenience to the vast majority of people is very small indeed. Most people that I know don't have any reason to install software daily. They'll spend their time in tasks like writing, email, browsing, media playback and such. They rarely need to switch to admin, and when they do, it only takes a couple of seconds to do. Certainly not too bad - perhaps easier than having to put on seatbelts every time they get in the car which they're perfectly capable of doing.
And also: LUA can help users find the right mindset. When they're in LUA, it's pretty much like they're driving to work at 50 mph in nice clear weather and with their seatbelts firmly on. They'll keep their eyes open of course, but they shouldn't be too worried. But when they log in as admin, now they've taken off the seatbelts and are driving in pretty poor weather at high speed, and they know this. Nothing to be panicking about if you know how to drive, but you should be very careful and understand the risks. So, there's a very clear distinction between doing everyday tasks and doing administrative tasks that need to be done right or things will go very badly. A distinction that is not there when the user is always admin, because he won't have to do anything to get into "admin-mode", he's already in it.
Some people that I know (mostly women, perhaps they're just naturally more careful) have even developed a genuine dislike of logging in as admin. ;D They find it uncomfortable that when they are admin, any program they run or even their own accidental mouse click could delete important system files or their favourite programs. So what they do is they log in as admin to install something important, and when that's done, they immediately log out and feel better when they're back in LUA. That's not exactly how I would feel, but at least these people are regular, normal users that aren't too sophisticated but still have realized that it's not good to be root all the time and it really is a lot more powerful than you need to be most of the time. :)
What Rmus said about passing on information to people we come to contact with is certainly good to remember. Ultimately, we can't do much more than that. (Of course, we can also try to pressure software vendors into fixing their vulnerabilities and poor default configurations and such, and help blacklisting companies keep up with the loads of new malware being churned out, like many people in this forum do.) I find it always easier to help someone face-to-face, where you can really see the full details of their computer/network setup and can immediately understand the risks better. Online, you have to depend on what they're saying, and they may not know enough to tell you the right things. Online, you can give general recommendations easily, but anything more specific gets tricky (but not impossible).
Rmus
September 9th, 2009, 12:46 AM
-{ Quote: "And also: LUA can help users find the right mindset... So, there's a very clear distinction between doing everyday tasks and doing administrative tasks that need to be done right or things will go very badly. A distinction that is not there when the user is always admin, because he won't have to do anything to get into "admin-mode", he's already in it. " }-For those who started computing with WinXP, you may not know that Win2K had "Users" and "Groups." Those I associated with emphasized the benefits of Users versus Administrators as laid out in the Win2K Help File:
-{ Quote: "Users and groups are important in Windows 2000 security because you can limit the ability of users and groups to perform certain actions by assigning them rights and permissions. A right authorizes a user to perform certain actions on a computer, such as backing up files and folders or shutting down a computer. A permission is a rule associated with an object (usually a file, folder, or printer), and it regulates which users can have access to the object and in what manner." }-This was certainly useful where several people used the same computer.
As far as security from malware, again from the Help File:
-{ Quote: "Running Windows 2000 as an administrator makes the system vulnerable to Trojan horses and other security risks. The simple act of visiting an Internet site can be extremely damaging to the system. An unfamiliar Internet site may have Trojan horse code that can be downloaded to the system and executed. If you are logged on with administrator privileges, a Trojan horse could do things like reformat your hard drive, delete all your files, create a new user account with administrative access, and so on." }-Downloading here, of course, refers to remote code execution, for if someone intended to download/install, the user would to so as Administrator. This applies to those who are tricked into installing rogue security products.
Interestingly, those I associated with at the time didn't think of Users as being a protective measure from malware, since we already had the remote code execution attack vectors taken care of:
Drive-by download -- web based attack
Floppy Drive/Zip DRive/USB -- autorun.inf
Office Documents -- macro virus, etc...
It was an almost accepted principle that one's security would block malware from sneaking in like that!
However, in view of the lack of security awareness on the part of so many home users today, running as LUA is certainly to be recommended to protect against the inadvertant mistake or the drive-by download that succeeds because of lack of proper security.
----
rich
Kees1958
September 9th, 2009, 06:47 AM
-{ Quote: "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." }-.
Ahaa now I understand why we some times do not understand each other.
Threat Gates = sources of possible malware
- USB stick
- Web browser
- Shared disk
Attack vectors = intrusion techniques used by malware.
- Using uncommen but existing software techniques,
like direct disk access, Injecting DLL, hooking, etc
- Using services or build in features for other purpose than intended
like gaining access through guest account/admin share, remote admin services,
wan side pings, spoofing MAC addresses
- Using exploits (is unintended access to code/data/rights through untested/unknown entry/return/error conditions of usually existing OS, services, third party add-ons/services or threat gate related software.
- and non technical attaks like using default passwords of management console apps (f.i. of your hardware router) or more complicated social engineering see for fun http://www.dummies.com/WileyCDA/DummiesTitle/productCd-047005235X,page-1.html
Cheers Kees
Kees1958
September 10th, 2009, 10:44 AM
-{ Quote: "Yes, threat gates is a much better way of putting it. If you can block all the threat gates, you're pretty much set." }-
And that my friend is exactly what Sandboxie/SafeSpace and DefenseWall/GeSWall do :thumb:
Why bother with system wide protection when you have covered the threatgates? So a FireWall (network level threatgate) with a Sandbox HIPS (application level threatgate) plus an AV (system wide blacklisting) is the best defense approach in terms of pop-ups/user interaction versus solid protection.
vBulletin® Copyright ©2000-2012, Jelsoft Enterprises Ltd.
Copyright ©2002 - 2012, Wilders Security Forums