Virtualization question.

Depends. If it doesn't check mimetypes, and if it whitelists rundll32.exe or cmd.exe by default, then everything's game.

Though I personally doubt that.

 

Someone recently took me to task over my choice and recommending ScriptSentry, but right there and possibly most of all is been the perfect launching/spreading method of viruses for a long time on Windows systems.

Vbs files, batch, and other files that use $M's scripting host have been responsible for plenty of malicious and damaging actions carried out either remotely or from an email link ETC. and they still can be used exactly the same as an .exe. I use them all the time to automate different purposes on my machine since you can even set a schedule when their due to activate.

ScriptSentry always worked just like a HIPS in that it associates itself "FIRST!" with those executable file extensions and stops them cold before they can take off and do any damage.

 

SandboxIE, you set it to block read of important folders. Those folders will not be read by anything sandboxed. Rootkits will not be installed. Only the lightweight keyloggers (Tzuk has a name for those, "Windows Message Key-Loggers"; "Typically this key-logger will be a secret Web browser plugin").

Put it this way: i'm pretty sure malware doesn't do anything. With VM's, it's even more extreme, since whatever malware exists in VM, already thinks it's riding a computer, not two.

 

Well, I still have my reboot that replaces my system partition completely with a new one, because I don't trust any of my security softwares.

 

Correction... "ALL security softwares can be compromised without exception and it has been proven."

How can you be 100% sure the software you use for your off-line snap is 100% good... do you always buy CDs, and never download from the Internet?

To me, there is no such thing as "security software", the software is either good or bad/flawed. "Security software" gives a false sense of real security.

Mike

 

I'm never sure about anything in life, but I like to get close to the best solution, I can get. Everybody has downloaded software, I'm no exception.
I prefer to use whitelists, rather than blacklists to keep my computer clean, which is alot better and more reassuring, than the scanner message "Congrats, no malware found."
Keep your scanners, I have something much better.

 

Hello Erik and Easter,

Unfortunately, programs like ScriptSentry must read the file from disk, and are no protection against scripts on a web site that are interpreted by the browser - javascript being the main culprit.

This is true of XSS attacks which use javascript, where even in a virtualized environment, info can indeed be sent to the thief over the internet.

The problem is that most secure sites require javascript to be enabled.

See here for an example, and feel free to suggest preventative measures.

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

I guess malware is also XSS atacks, they are scripts, sorry for not including a current threat.

 

Worth pointing out and of course true.

From that viewpoint, I'm not sure if an argument for Opera or Mozilla etc. would be of any real benefit but it's little consolation for the massses who depend solely on IE browser now is it?

 

What does a script do to your system partition ?

 

If your script-blocking software supports it, NOTHING AT ALL.

 

That wasn't my question.

 

Sorry i don't know Dutch, i didn't completely understand what answer you're looking for.

 

That's why I usually run with Javascript turned off if I can get away with it. However, what about the code that can flash your bios? Does it need a reboot to do so? What about updating firmware with code? For those things that may be stuck on my computer during a reboot I have AVAST Antivirus for that as it has a preboot AV scanner that scans the whole system the way I tell it to to block code from infecting during a boot up. Avast also has a built in anti-executable feature that you can program with many various types of extensions. Comodo has a feature on it's firewall to prevent outgoing signals during a bootup process as well. That is my main concern is the booting process so I want my nasties GONE before I have to boot. That is why I chose powershadow. FDISR 's frozen snapshot ends up trying to erase something AFTER the boot. You can't erase a bios flash.

 

What a script does on the HD is of no consequence if you have a reboot-to-restore solution.

But the point I was making referred to your question about sending info out during the session. These kinds of attacks are not interested in changing anything on your partition, rather, stealing data during the session, prior to your reboot.

This is in answer to the topic of your thread:

If you consider an XSS attack as an "infection" - temporary for sure, then the answer is Yes.

Whether or not you are in a virtualized environment doesn't matter, as long as the browser has free access in<--->out on the internet.

@ Easter: It doesn't matter which browser. If javascript is enabled because the site needs it, the script gets interpreted.

To understand how this works, see the XSS threads in the 'Other Security Topics' forum.

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

Thanks for those details and explainations. I think every $M O/S should have some form of script-blocking security in place for the just-in-case scenario.
BTW, just speculating with this but i think the term scripting here has to do with that ALL scripts are basic TEXT files incognito. Correct me if this is not accurate, i tend to not enjoy putting my foot in my mouth to often where it concerns $M style of different coding techniques. LoL

 

I suggest you to read Rmus' analysis of Anti-Executable. Yes, AE whitelists rundll32.exe and cmd.exe and I see this as a possible hole. But, I'm not smart enough to figure a way to pass commands to those files without running another executable which isn't allowed by AE.

A script can do whatever it wants (i.e., wipe your hard disk). However, scripts are treated as executable by Anti-Executable, so they aren't a problem for you.

Answering your original question: Virtualization/sandboxes doesn't protect against keyloggers/password stealers. But, there are solutions to this issue:
- Encrypt your critical/sensitive information/files.
- Make a rule in the sandbox (GeSWall, Sandboxie and Defensewall all support confidential folders) to prevent disclosure of files/folders containing sensitive information.
- Harden the security of the browser (NoScript, whitelist cookies, control of referers, firewall rule for HTTPS traffic, etc) to prevent in-browser threats (XSS, spoofing, etc)

 

Thank you guys. It seems to me that AE isn't such a bad choice after all.
My main goal is stopping the execution of infections, which is the worst part of any infection.
DefenseWall treats Firefox and MSIE as untrusted applications, which means they can't do much either.
Emails aren't a problem, I ignore and delete them without opening them.

 

Just add scriptsentry or scriptdefender. Next add the one of your choice to the untrusted programs within DefenseWall. Now all scripts are marked untrusted and limited in rights. Maybe this helps you to gain trust (at least in your rock solid defense combo) and get connected (for instance by e-mail) in the digital world.

Regards K

 

Untrusted means that a file downloaded/created by FF/MSIE can't modify system settings, write to the registry, install drivers/hooks/services, read/write from/to physical memory, etc.
You're still exposed to browser-based scripting attacks. Anti-Executable only protects you against WSH-based scripts.
As a general rule, when you're going to do bank transactions/online shopping, start a new/fresh browser session.

 

When using a policy right virtualization program like GeSwall or Defense Wall, just quit all untrusted processes first before starting sensitive internet sessions (like Lucas1985 advised).

This is more or less a work around not a direct conunter measure

Regards K

 

Even when Java and JavaScript is disabled in Firefox ?

 

After reading that article, I actually think I'm already halfway to bypassing AE. Unless something I suspect and the article doesn't describe is false.

 

This, of course, is an immense problem: in the case of web-embedded javascript - that is, code in the HTML source code of the web page - how do you determine good from bad? Anti-virus solutions for recognizing "bad code" in the case of that used in cross site scripting (XSS) have not proven reliable, since the code can be easily modified.

Yes, for example, as soon as the HTML page for any web site caches to your HD, it essentially is a text (non-formatted) file. When you go to View|Source in your browser, you are opening the web page in a text editor and you will see that it is a plain text file.

Do this experiment: clear your browser cache, then go to a web site and observe what caches. I'll do this now using IE to cache Wilders (IE is nice because it retains the original file names) - see screenshot

If these files weren't cached, you could not see anything on your monitor.

Now, why didn't your ScriptSentry keep those .js files from running? Because the browser interprets them: they are not "executed" on the HD like a normal file would be.

You can configure the browser to not run them, of course, but the problem is some sites (including Wilders) require javascript for certain functions to run. We trust Wilders not to run malicious scripts, so we don't worry about it.

Now, double-click-to-run one of the .js files and your ScriptSentry will intercept it because Windows, rather than the browser, interprets the .js file extension and sends it to ScriptSentry according to the HKCR command in the Registry for the .js filetype:

Code:

[HKEY_CLASSES_ROOT\JSFile\Shell\Open\Command]
@="C:\\Program Files\\Script Sentry\\ScriptSentry.exe \"%1\" %*"

Understanding the difference in how file extensions are interpreted - whether by the browser or the OS - is imperative in order to understand what secutity solutions are necessary in each case. For example, you may not want a .pdf file on the web to open in the browser; so, you can configure the browser to pass the .pdf file extension directly to the OS to open in your default Reader program, thus preventing the appended-URL exploit from a while back. You can configure the browser to pass web-based *.doc files to a text editor, rather than to MSWord, for obvious reasons.

Now, open-to-edit the .js file in a text editor and you will see that it is a plain text file.

As an aside, one of the most innovative programs I've ever seen is WormGuard. Rather than associate all script extensions to block, as is the method with ScriptSentry and similar, it analyzes the scripts with several different types of "engines" and alerts when it recognizes malicous code in the script.

This approach eventually may be a solution that can be used to analyze (scan) web-based scripts.

regards,

-rich

________________________________________________________________
"Talking About Security Can Lead To Anxiety, Panic, And Dread...
Or Cool Assessments, Common Sense And Practical Planning..."

--Bruce Schneier​

 

Completely disabled or using a whitelist like NoScript?

Please, share with us your findings/thoughts.

Does WormGuard analyze browser-based scripts? I've learned something new. However, WG's solution is behavioral/heuristic based, so it may fail (unlike whitelists).