Is possible that someone get infected without user intervention?

Is possible someone get infected without user intervention? Like, just visiting a web page?

 

Yes it is possible.

 

How? Just by a security hole (that can be fixed with an update)? Or there are other ways to get infected that an update cannot protect you?

 

Drive by downloads.
Can be easily avoided by running browser with DropMyRights or in a sandbox.
Read emails in plain text only.

 

Yes, in many ways.

And there are many ways to deal with that.

Examples: SRP+LUA (for Windows XP Home Edition a registry hack is necessary), keeping everything patched, remove vulnerable software like Adobe's software and Java, use a secure browser/configure it in a secure way, use a rollback system (but understand its limitations), a good AV/security suite, etc., but noting can replace a careful and knowledgable user.

 

Won´t UAC prompt in that case?

 

- A zero-day 'drive-by' vulnerability (i.e., one that allows the remote execution of code on your system), such as when Adobe Reader has a 'critical' security hole that is made public but isn't fixed by Adobe for several weeks. (Usually a good AV will create a signature to protect against these within a day or so.)​

- Or a critical security flaw that isn't yet known to the developer, and is therefore without a patch.​

One key advantage to running as a restricted or limited user is that even if any of the above security holes exist in your system, the extra layer of protection will usually sandbox the malware inside the user account and not compromise the rest of your system. Microsoft reported that 92% of critical vulnerabilities in their software in 2008 could not be exploited to compromise the OS or other user accounts, if running as a restricted user, even if the system was not patched for the vulnerability at the time.

That said, the chances of someone being able to break into a legitimate web site and at the same time there also being a critical vulnerability yet to be fixed that they can exploit from that site are probably very slim, since critical zero-day vulnerabilities are usually patched within a few days. A hacker may be able to break into a website at some point in time, but Microsoft or Adobe, etc., must also have some yet to be fixed critical vulnerability the hacker knows about and can exploit as well, both on those same few days or weeks.

If you deliberately go to a shady website (i.e., one that would host malware on purpose) when a critical vulnerability in software you use is not yet patched (and is being exploited there), then that's another story. If this is something you might do, then extra protection is probably warranted to protect your user account: HIPS, sandboxing, SRP/Applocker, VM, etc. However, if the malware also exploited an unpatched flaw in a network service or driver, MS08-067 for example, then even these approaches might not protect you. So the advice to avoid shady websites may have some merit, at least in terms of certain critical zero-day or unpatched flaws - even if you are always fully updated and run as a restricted user.

 

Yes - even just connecting to the internet with a firewall not properly configured. You may remember that the first variant of the Conficker worm, Conficker.A, exploited a vulnerability in Windows using ports 139, 445.

Microsoft's advisory mentioned blocking those ports, and an MSDN blog made reference to the Windows Firewall:

http://blogs.msdn.com/sdl/archive/2008/10/22/ms08-067.aspx

As has been mentioned, various exploits can trigger downloading of malware without user intervention. Those that I've looked at are easily prevented from running with Opera properly configured. Mrkvonic has confirmed the same with Firefox, and from what I've seen in other forums, IE8 is rather robust and quite configurable.

Some examples:

On-going PDF exploits

This code sample shows that both Javascript and Plugins must be enabled in the browser for the PDF file to load automatically:

​

While Plugins are convenient, in that the PDF file can load directly into the browser when viewing it on the web, a script can make this happen automatically with no user intervention. Best procedure is to configure the browser to prompt for a download, rather than using a plugin. Then, the user will be alerted to something that she/he didn't call for:

​

Another PDF exploit uses i-frame. Note that this does not require Javascript:

​

You might think that disabling inline frames in the browser prevents this exploit from working, however, all disabing inline frames does is to prevent the PDF file from displaying in the browser screen. The plugin function will still load the PDF file into memory and execute any malicious code.

Configuring the browser to prompt for download of all types of documents, rather than using a Plugin, will prevent this type of exploit from succeeding. While this example uses the Adobe PDF Reader, Foxit was targeted to some degree.

Rogue Antivirus Exploits

These require Javascript. Usually, the user is redirected from a web site compromised with code injection. Configuring Javascript per site in the browser prevents scripts on the redirected page from executing.

Typical code to load files with the fake scan:

Code:

script src='fileslist.js'>/script
script src='progressbar2.js?v=1.1'>/script
script src='common.js'>/script

Typical code to call for the download of the malware:

Code:

SCRIPT language=javascript
location.href="/_[B]download[/B].php?aid=77011807&dlth="+dlth;

The download attempt here succeeds only if the user is tricked into accepting the prompt. However, some rogue security products have been part of exploit packages which probe for a browser or application vulnerability. This puts this type of exploit into the category of those such as Mebroot, which has resurfaced recently.

Here, Symantec analyzed a Java (not Javascript) exploit that was part of an exploit package:

http://www.symantec.com/connect/blogs/new-wave-mebroot

You will notice that this is also a redirection exploit which depends on Javascript being enabled to execute the commands. The reference to the Adodb Stream exploit is MS06-014. Why would an exploit using a vulnerability from 2006 which has long since been patched continue to be used by malware writers in 2009? Because IE6 unpatched is still the most commonly used browser by many people.

Finally, Symantec notes this in their analysis of different stages of this exploit:

This is common to all of the web-based remote code execution exploits: get a malicious executable onto the machine, which, of course, is easily prevented.

For security-minded people, these exploits don't pose much of a problem. But the general population is not aware of what is going on behind the scenes, nor how to sucessfully protect against the exploits, which is why they are successful, and why the botnets continue to grow.

-rich

 

Thanks! But, again, in the case of an exploit, won't UAC prompt and ask the user about an action?

 

I do not know exactly how UAC works.

[I removed an example of an exploit being blocked because I realize it doesn't pertain to your question about UAC]

-rich

 

UAC is not a security boundary (LUA and Windows Firewall are examples of security boundaries). Meaning it's always possible to sneak past it, if the exploit is written to do so. According to Marc Russinovich, this isn't easy to do in a standard (limited) account, but it is possible:

(OTS=over the shoulder)

 

The short answer is "No, UAC won't necessarily do anything at all."

The longer answer, then, would be what others have already said and what is mentioned in Russinovich's articles. Basically, that
- UAC is not really a very strong security feature, it's better for forcing programmers to create software that works without admin privileges.
- You should most certainly not rely on UAC to prompt you when something possibly bad happens. If you want that, you need a HIPS software of some sort.
- Whether UAC says anything depends on what is being done. Malware doesn't have to actually try to bypass UAC in order to go unnoticed by it. UAC only warns about certain things that require admin privileges. But malware could do many things that don't require those privileges, like create its executables in a user profile folder and then throw lots of popups saying you're infected with something - pretty much what the rogue AV malware will want to do. UAC would not warn about that.