Windows Vista/Windows 7 + Sandboxie + Integrity Levels

A couple weeks ago I did some experiment on Windows 7, with Sandboxie and Integrity Levels.

I did this experiment, because I have a relative who does home banking. I want to provide the best security possible, considering a scenario where an infection may occur as a standard/limited user.

You can find more about Windows Vista/7 Integrity Levels by googling for "msdn+integrity+levels". I couldn't post links.

As an example, you probably heard of Internet Explorer Protected Mode. Well, basically it means that IE is running with a Low integrity level.

Anyway, proceeding.

So, first thing first. A lower integrity level object cannot write to higher integrity level containers (folders) and objects (files, processes, etc). But, by design a low integrity level object can READ from a higher integrity level. What does this mean? Well, it means that if, for example, you've got a folder in your Desktop with sensitive information, which would be running by default (by inheritance) a medium/high integrity level object, depending on whether we're talking about a standard user or administrator account (uac disabled), a lower integrity level object could READ/GRAB that information and send it back to the attacker.

Sure, one could encrypt the folder, but it's just to show what I'm trying to explain.

Now, imagine that instead of a folder, we're talking about a web browser. If for some reason, your system becomes infected, but only with user privileges, well... the attacker/the keylogger could still READ/GRAB from the browser's process... and that means your bank account credentials.

So, assuming that the system may become infected in user-space, it's still possible to prevent it from READING the browser's process and that way prevent it to get the bank account credentials.

All one has got to do, is to explicitely run the browser with a higher integrity level than the user account. So, if you're using a standard user account or an administrator account with UAC, then we can simply apply a High integrity level to the browser's process and apply the flags NW, NR, NX.

With these 3 flags, nothing will be able to write, READ and execute to the browser's process.

I have made my relative run Chromium. I dislike Firefox. I don't like Google Chrome and we're better off not messing with Internet Explorer's own Protected Mode.

I have used this tool, named CHML. Search Google for "minasi+chml". I placed the tool at C:\System32, so that I can use it from any location at the Windows command line. It's a safe tool.

Just to clarify, there's more than one Chromium install in my relative's system. One being dedicated to home banking. All Chromium installs are placed in Program Files, so that they are protected against user-space malware. Just in case. By having more than one install, one has been applied a Low integrity level, which is used for general web browsing.

To apply a High integrity level to the Chromium - Home Banking process, I opened Windows command line, and wrote the following:

chml path_to_Chromium_Home_Banking_folder\chrome.exe -i:h -nw -nr -nx

This command will apply an explicit High integrity level to chrome.exe with the flags NoWriteUp, NoReadUp and NoExecuteUp.

To actually be able to run this Chromium install with a High integrity level, it's needed to run with Administrative rights, by running it as an Administrator. As you would normally elevate any application.

I'm forcing this Chromium install dedicated to home banking to run in a sandbox, where only chrome.exe can run and access the Internet. I'm also restricting communications to the bank's IPs in the firewall.

I don't know if Google Chrome or newest Chromium builds still have it or if it has been reintroduced back already in Google Chrome, but there's a flag called --host-rules, that you can use to MAP every communication to 127.0.0.1 (localhost), except the bank's domains.

Example:

"%PROGRAMFILES%\Chromium\Chromium - Home Banking\chrome.exe" --host-rules="MAP * 127.0.0.1, EXCLUDE *.bankdomain.com"

I've tested this High integrity level approach against Spyshelter's keylogger test, and the simulator was unable to READ the information entered in Gmail (the URL I used to test it).

Prevx SafeOnline failed to protect what the High integrity level protected - credentials.

Now, please, be aware that the integrity levels won't protect against screenloggers. Unfortunately. But, it does provide a relatively safer experience, in my honest opinion.

So, I've applied:

1) High integrity level with the flags NoWriteUp, NoReadUp and NoExecuteUp;
2) Forced to run in Sandboxie, and only chrome.exe has access to the sandbox and to the Internet;
3) Restricted chrome.exe communications to the bank IPs only in the firewall;
4) Using the flag --host-rules to only allow communications to bank's own domains.

One may ask: Isn't this dangerous? Well, I don't think so... Otherwise, it would only mean that your bank servers have been hacked already, anyway. Would it be really needed to hack your own system, when they already had access to the bank? Besides, I would no longer trust such a bank.

But, this got me to think that I'd like for Sandboxie to have the option to allow us to create a "special" home banking sandbox, by making use of a Secure Desktop, just as where you enter your UAC credentials. And, it's something that could be achieved for Windows XP, for example. Would it be a good idea? I think it would. It's my opinion, of course.

KeePass password manager has an option that allows to enter the master key in a secure desktop, and it's quite effective.

Anyway, I just thought of sharing this. Don't be too harsh on me now. lol

-edit-

As long as any keylogger is running in user-space, or in other words with a lower integrityt level (medium or low), it can't read the credentials entered in the browser.

Isn't it easier and just as secure to use Sandboxie or even bank from a live Linux environment?

m00nbl00d wrote:All one has got to do, is to explicitely run the browser with a higher integrity level than the user account. So, if you're using a standard user account or an administrator account with UAC, then we can simply apply a High integrity level to the browser's process and apply the flags NW, NR, NX.

With these 3 flags, nothing will be able to write, READ and execute to the browser's process.

Firstly, thanks for a great (and informative) post - I don't use Vista or 7 myself, so all this is fairly new to me. Interesting stuff - I'll make some comments and you can clarify/respond as you like.

m00nbl00d wrote:This command will apply an explicit High integrity level to chrome.exe with the flags NoWriteUp, NoReadUp and NoExecuteUp.

To actually be able to run this Chromium install with a High integrity level, it's needed to run with Administrative rights, by running it as an Administrator. As you would normally elevate any application.

Sounds good, except the risk-benefit ratio has suddenly shifted a bit (in the negative direction). Running a web-browser (arguably the most dangerous malware threat-gate) as Administrator is not something I would routinely recommend.

Furthermore, are there any (related) potential security issues running the web-browser with a High integrity level?

m00nbl00d wrote:I'm forcing this Chromium install dedicated to home banking to run in a sandbox, where only chrome.exe can run and access the Internet. I'm also restricting communications to the bank's IPs in the firewall.

Sounds good, and this shifts the risk-benefit ratio considerably in the positive direction.

m00nbl00d wrote:Prevx SafeOnline failed to protect what the High integrity level protected - credentials.

Was this because of (the known) conflict with Sandboxie? I'm surprised Prevx SafeOnline failed known (old) tests.

m00nbl00d wrote:Now, please, be aware that the integrity levels won't protect against screenloggers. Unfortunately.

I guess you can't have everything! Would it protect routinely against clipboard/sound/web-cam logging?

m00nbl00d wrote:But, this got me to think that I'd like for Sandboxie to have the option to allow us to create a "special" home banking sandbox, by making use of a Secure Desktop, just as where you enter your UAC credentials. And, it's something that could be achieved for Windows XP, for example. Would it be a good idea? I think it would. It's my opinion, of course.

I think it would be a good idea, but I'm not sure if tzuk will find it possible to do, or more importantly, if he's willing to do it - I think many users out there appreciate Sandboxie for what it is and don't want it to be "bloated" etc. What do you think? I'm not sure what programming exactly is required to achieve a "Secure Desktop" environment with Sandboxie, but I suspect it is well outside the realms of the "Sandboxie concept".

m00nbl00d wrote:KeePass password manager has an option that allows to enter the master key in a secure desktop, and it's quite effective.

Quite effective against known tests?

wat0114 wrote:Isn't it easier and just as secure to use Sandboxie or even bank from a live Linux environment?

I think the concern is if malware is running outside the sandbox - in my opinion, if this is the case, all bets are off anyway, as I emphasised here (sorry, I was purposefully harsh on anti-logging software!):
http://www.sandboxie.com/phpbb/viewtopic.php?p=71880#71880

At the end of the day, it's all about peace of mind. I think m00nbl00d has made some rather excellent points in this thread, but I personally don't think we'll see such anti-logging mechanisms being added into Sandboxie. Furthermore, if you know how to use Sandboxie to its (full) potential, such mechanisms don't offer any significant advantages, in my opinion.

ssj100 wrote:

At the end of the day, it's all about peace of mind. I think m00nbl00d has made some rather excellent points in this thread, but I personally don't think we'll see such anti-logging mechanisms being added into Sandboxie. Furthermore, if you know how to use Sandboxie to its (full) potential, such mechanisms don't offer any significant advantages, in my opinion.

I agree I think m00nbl00d's points are indeed excellent and would work. He has tremendous knowledge in this area. It's just that for the average user, it's probably easier to implement a sandbox or Linux live environment approach. With the latter, malware on the system won't affect the live environment, anyway. As you alluded to, if Sandboxie is configured properly, it's pretty darn robust against malware exploits. If malware is running outside the sandbox, then something went wrong somewhere and there would be no point in progressing further until it's removed and the security approach is re-thought and re-tooled

wat0114 wrote:Isn't it easier and just as secure to use Sandboxie or even bank from a live Linux environment?

Easier and secure/safer is very relative. Is it secure to run the browser for home banking inside Sandboxie? It depends. If we're talking about a system that we know, without any doubts, that it's clean, then yes. Just restrict Start/Run Access and Internet Access to the browser's own process.

Is a Linux live CD/Pen the solution for everyone? Unfortunately, it isn't.

As an example, my relative is using a laptop that was bought from another relative. This laptop has 3 USB ports. One of them is broken, and one other is placed on the front side of the laptop, and my relative had bad experiences by placing USB devices there; they broke. It's quite easy to disconnect the device when using the keyboard. Not sure why an USB port would be placed in such a place.

The third USB port is used to connect the 3G USB device.

The CD/DVD player only reads original CDs/DVDs, but not copies. Bummer. So, no chance to use a live CD.

My relative is aware that, at no cost, besides upgrading the installed apps, no other crap should be installed, because one truly needs to be sure something is clean. This only leaves place to user-space malware.

I've made my relative use separate user accounts, as well. One standard account is used for general web browsing, and the browser in this account is running with an explicit Low integrity level.

A separate account is used for home banking. My only "concern" is that I want to cover any possibility that my relative my open some file in the account used for home banking, and happens to be malware infected. And, it doesn't matter whether or not the file is open inside Sandboxie, the file will still be able to READ the browser's process. It could be some doc file that my relative created while in the home banking user account, and then placed in a USB flash drive and then insert it in the laptop, while in the general browsing user account or some relative's computer, and got infected.

But, most folks simply use just one account for everything. This is specially concerning, IMHO.

So, some isolation is needed. It's useless to have the browser with an explicit medium integrity level. User-space malware would be still be able to read from it.

The alternative is to apply an explicit High integrity level with the flags NW NR and NX. As long as any keylogger is running with LOWER integrity level, it can't steal the credentials/other sensitive information.

@ ssj100

Sounds good, except the risk-benefit ratio has suddenly shifted a bit (in the negative direction). Running a web-browser (arguably the most dangerous malware threat-gate) as Administrator is not something I would routinely recommend.

Furthermore, are there any (related) potential security issues running the web-browser with a High integrity level?

You're free to explain if and what bad things you predict that could happen? Personally, I don't see any danger. We're not blindly applying a High integrity level to a general web browsing browser or a browser without restrictions.

As I mentioned, the browser is:

1) Restricted to connect to the bank IPs only, in the firewall. Bank IPs are unique, as in, not shared. The IPs belong to the bank and no one else.

So, the question is: Do you trust your bank? If you don't, then why having an account with them, in the first place?

Do you fear that bank's server will get hacked/are hacked? If they are or if they will, don't hackers have already access to what they want? All the clients would need to do is login into their accounts, and then be directed to bogus bank website. Sort of like MITM attack, except that in this case, the bank's servers are the ones compromised.

I want to believe that banks monitor their servers very closely?

2) Sandboxie. Just for the comfort of using the erasing feature of Sandboxie, with Eraser. Not really for security against malware, in real-time. Just to be sure the leftovers are all gone.

3) I forgot to mention, but javascript, etc is globally disabled, and only allowed for the bank's domains. No extensions, etc.

The thing to remember is, the browser can only communicate with the bank IPs. It can't communicate with nothing else.

Was this because of (the known) conflict with Sandboxie? I'm surprised Prevx SafeOnline failed known (old) tests.

No, I didn't test the browser inside Sandboxie. I tested it outside, so there should be no issues with Prevx SafeOnline. The only thing I ran inside Sandboxie was the Spyshelter's test, running with a default medium integrity level, inherited from the standard user account.

Only afterwards I ran both the browser, with an explicit High integrity level, and Spyshelter's test inside Sandboxie. Spyshelter's keylogger simulator couldn't retrieve the credentials.

I also tested SafeOnline with Internet Explorer 9, and it also failed. So, not a problem with Chromium (lack of official support). IE9 is officially supported.

Quite effective against known tests?

I tested it against Spyshelter's test. The simulator failed to read the credentials. I'll test more over time, when I get time. But, I'm predicting the same results.

At the end of the day, it's all about peace of mind. I think m00nbl00d has made some rather excellent points in this thread, but I personally don't think we'll see such anti-logging mechanisms being added into Sandboxie. Furthermore, if you know how to use Sandboxie to its (full) potential, such mechanisms don't offer any significant advantages, in my opinion.

You're right... If we know our ways with Sandboxie, we can be very secure. The problem is not with Sandboxie, though. The problem lies outside of Sandboxie.

So, having the world outside Sandboxie as factor, we need to mitigate this factor to most possible.

Unless the bank's servers get hacked, which would be way too bad for the bank... I don't think banks are this lazy, are they? lol I never heard of any news pointing that banks servers got hacked and clients loosing money?

So... I think that the High IL approach with the flags NW, NR and NX do have a role in security... AS LONG AS... the browser is only allowed to communicate with the bank servers.

Anyway, this has just been a test. I personally see no danger in this approach, if having the measures I've applied, but the reason that made me post it, was to know what others think and what dangers you can see that could possibly happen.

Please, feel free to expose any possible dangerous situation... besides a bank being owned by hackers... lol

-edit-

I think it would be a good idea, but I'm not sure if tzuk will find it possible to do, or more importantly, if he's willing to do it - I think many users out there appreciate Sandboxie for what it is and don't want it to be "bloated" etc. What do you think? I'm not sure what programming exactly is required to achieve a "Secure Desktop" environment with Sandboxie, but I suspect it is well outside the realms of the "Sandboxie concept".

Indeed, Tzuk would need to be willing to do it. lol

But, I don't think it would be bloated. Anyway, wouldn't we all love Sandboxie to have this "special" sandbox? That way, nothing inside or outside of the sandbox would be able to steal credentials. The best of both worlds.

Not sure about what would be needed to achieve the Secure Desktop. But, KeePass is open sourced, so Tzuk could always take a look at it.

wat0114 wrote:[...]
I agree I think m00nbl00d's points are indeed excellent and would work. He has tremendous knowledge in this area. It's just that for the average user, it's probably easier to implement a sandbox or Linux live environment approach. With the latter, malware on the system won't affect the live environment, anyway. As you alluded to, if Sandboxie is configured properly, it's pretty darn robust against malware exploits. If malware is running outside the sandbox, then something went wrong somewhere and there would be no point in progressing further until it's removed and the security approach is re-thought and re-tooled

Good point... but, one needs to know that our security failed, correct? We only know that, if and when something bad happens.

Could there be a chance that something gets admin. privileges by escalating privileges? Yes. But, here... nothing is that helpful and let's face it, a Linux live CD won't be the answer for many people, either due to lack of resources or stubborness.

Could there be a chance that an infection may only happen in user-space? Yes. And, this situation, it makes all sense to isolate the browser used for home banking, in the way I did. It's one less headache. lol

m00nbl00d wrote:Is a Linux live CD/Pen the solution for everyone? Unfortunately, it isn't.

As an example, my relative is using a laptop that was bought from another relative. This laptop has 3 USB ports. One of them is broken, and one other is placed on the front side of the laptop, and my relative had bad experiences by placing USB devices there; they broke. It's quite easy to disconnect the device when using the keyboard. Not sure why an USB port would be placed in such a place.

The third USB port is used to connect the 3G USB device.

The CD/DVD player only reads original CDs/DVDs, but not copies. Bummer. So, no chance to use a live CD.

I think you'd have to admit that this scenario is incredibly uncommon (even unlucky - almost feels like a "comedy of errors to me" haha)? For sure, in this unlikely scenario, I suppose one may consider employing your setup/approach. Otherwise, a Linux live CD/Pen would be much simpler (and probably more secure and relatively more convenient) for the vast majority of people out there.

m00nbl00d wrote:You're free to explain if and what bad things you predict that could happen? Personally, I don't see any danger. We're not blindly applying a High integrity level to a general web browsing browser or a browser without restrictions..

I was actually asking you about the High integrity part - I don't really know much about this. As for running as Administrator, I think we all know about the potential dangers of this. Of course, you've minimised the risk considerably by using Sandboxie's retrictions etc. However, with Admin privileges, malware can really wreck havoc - for example, if you're using Windows Firewall, this could be disabled. Again, the chances of this occurring are probably zero, but this chance is probably even less if your browser did not run with Admin privileges. That's my understanding anyway.

m00nbl00d wrote:No, I didn't test the browser inside Sandboxie. I tested it outside, so there should be no issues with Prevx SafeOnline. The only thing I ran inside Sandboxie was the Spyshelter's test, running with a default medium integrity level, inherited from the standard user account.

Only afterwards I ran both the browser, with an explicit High integrity level, and Spyshelter's test inside Sandboxie. Spyshelter's keylogger simulator couldn't retrieve the credentials.

I also tested SafeOnline with Internet Explorer 9, and it also failed. So, not a problem with Chromium (lack of official support). IE9 is officially supported.

Sounds like something someone (who cares) should report to Prevx?

m00nbl00d wrote:I tested it against Spyshelter's test. The simulator failed to read the credentials. I'll test more over time, when I get time. But, I'm predicting the same results.

Perhaps this could be an alternative strategy for your relative then?

m00nbl00d wrote:You're right... If we know our ways with Sandboxie, we can be very secure. The problem is not with Sandboxie, though. The problem lies outside of Sandboxie.

So, having the world outside Sandboxie as factor, we need to mitigate this factor to most possible.

That's why one needs to apply (forced) sandboxing (with Sandboxie) to all malware threat-gates (including USB and CD/DVD drives). In this way, all avenues are covered and you are essentially guaranteeing that the system outside Sandboxie is clean. Files that you want to recover outside of the sandbox should be screened accordingly before recovering. If still uncertain, one can still recover the files and run/open them sandboxed.

m00nbl00d wrote:Anyway, this has just been a test. I personally see no danger in this approach, if having the measures I've applied, but the reason that made me post it, was to know what others think and what dangers you can see that could possibly happen.

I also agree that this approach is much more secure than it is dangerous.

m00nbl00d wrote:But, I don't think it would be bloated. Anyway, wouldn't we all love Sandboxie to have this "special" sandbox? That way, nothing inside or outside of the sandbox would be able to steal credentials. The best of both worlds.

Not sure about what would be needed to achieve the Secure Desktop. But, KeePass is open sourced, so Tzuk could always take a look at it.

Again, I doubt tzuk would be willing to implement this (and I don't really blame him). If he's not willing to implement tools like Buster Sandbox Analyser, how likely is he to implement a "Secure Desktop" feature? I think it's a good idea for sure, but well outside the scope of Sandboxie - if you're interested enough, you can ask him (I'm not going to haha).

ssj100 wrote:
I think you'd have to admit that this scenario is incredibly uncommon (even unlucky - almost feels like a "comedy of errors to me" haha)? For sure, in this unlikely scenario, I suppose one may consider employing your setup/approach. Otherwise, a Linux live CD/Pen would be much simpler (and probably more secure and relatively more convenient) for the vast majority of people out there.

I agree that it's not that common... but it happens. lol

The same way there's still people in dial-up connections. I doubt they will download an ISO.

There could be various factors playing a role.

ssj100 wrote:
I was actually asking you about the High integrity part - I don't really know much about this. As for running as Administrator, I think we all know about the potential dangers of this. Of course, you've minimised the risk considerably by using Sandboxie's retrictions etc. However, with Admin privileges, malware can really wreck havoc - for example, if you're using Windows Firewall, this could be disabled. Again, the chances of this occurring are probably zero, but this chance is probably even less if your browser did not run with Admin privileges. That's my understanding anyway.

OK. Once we apply the High integrity level, we can't simply execute a process. We actually need to elevate it. High integrity level containers and objects are bound to administrator accounts (full administrator accounts, without UAC).
So, if we're in a standard user account or admin. account with UAC, then we must elevate the application.

Now, the dangers. I understand the concern you're raising. It would be 100% stupid and 100% dangerous to run a browser with administrator privileges and consequently with a High integrity level. Now, it would be stupid and dangerous for a general web browsing browser, to check e-mails, etc. For that stuff, yes 100% dangerous and to be avoided, at all costs.

The main key factor in my approach/in my test is: The browser cannot communicate with any servers/IPs other than the bank's own IPs.

What does this mean? It means there's no chance you'll be redirected to some other website, etc. The browser is forbidden to have any other type of communication.

So, from the Internet to your computer, I don't see what possible danger there is. Is your bank going to attack you?

From your computer to the Internet. Is there any danger? Again, the browser can only communicate with the bank; no other communication is allowed.

Do you fear something messing with your browser's process, in your system? Well, it would need administrator privileges to access to Program Files dir.

The way I see it, I'd be way more scared doing home banking with Google Chrome, because it installs to user-space, and any malware running with the same privileges as the user, can mess with Google Chrome's process, etc. Now, this would be way too dangerous. lol

It's possible to install Google Chrome to Program Files, though. There's an installer that does that, or simply install using Windows cmd line with the parameter -systemlevel. This used to work.

Chromium browser is already saved in Program Files. My relative knows it's there that it should be and not in user-space. This is the mistake of the century, IMHO.

That's why one needs to apply (forced) sandboxing (with Sandboxie) to all malware threat-gates (including USB and CD/DVD drives). In this way, all avenues are covered and you are essentially guaranteeing that the system outside Sandboxie is clean. Files that you want to recover outside of the sandbox should be screened accordingly before recovering. If still uncertain, one can still recover the files and run/open them sandboxed.

But, is everyone really up to that? I mean, I am. You are. Others are. But, we are "one of a kind". Others, they don't install Sandboxie, at all. They don't know it. My relative uses it, because I installed it. I didn't restrict it that much, though. Code is dynamic, and, at some point in time, due to something new in a program, things may break. I've set Sandboxie in way that still gives a few convenience to my relative, otherwise I'd be asked to remove it, that's for sure.

There's also one thing that I never really bothered with. If one forces a USB flash drive, by forcing its letter... At some point in time, Windows will no longer remember what letter it gave to xyz USB flash drives.

There are some things that average users will never feel like learning. For that, they have people like us. But, even then, we can't force them to a whole new world at once. It takes time.

Heck, it took me more than 2 years to make my relative switch from IE to Chromium. lol

Again, I doubt tzuk would be willing to implement this (and I don't really blame him). If he's not willing to implement tools like Buster Sandbox Analyser, how likely is he to implement a "Secure Desktop" feature? I think it's a good idea for sure, but well outside the scope of Sandboxie - if you're interested enough, you can ask him (I'm not going to haha).

Well, BSA isn't something that most average people would like to have or use, or even know how. But, running their browser, to access their bank account or shopping, in a Secure Desktop would probably be something welcome, perhaps.

I might suggest it... might... I don't wish to upset Tzuk... lol

m00nbl00d wrote:I agree that it's not that common...

I'd say that's an under-statement. I've never even heard of CD/DVD players only reading original CDs/DVDs - is that a fairly normal thing nowadays? And most computers nowadays have ample USB ports - for example, my nearly 5 year old system has two USB ports at the front of the box, eight USB ports behind, and another two USB ports in the monitor.

Anyway, I suppose that's besides the point of this thread. I just can't believe how "unlucky" your relative is haha.

m00nbl00d wrote:Do you fear something messing with your browser's process, in your system? Well, it would need administrator privileges to access to Program Files dir.

But isn't your browser running with Admin privileges to start with (or am I missing something here)? Regardless, I agree, with your firewall rules in place (by the way, are you using Windows Firewall or a third party firewall? I feel this is potentially important if you're giving Admin privileges to your browser), there shouldn't be any realistic dangers whatsoever. The only thing I can think of is if an unknown entity somehow hijacks your browser process, perhaps via a privilege escalation exploit, and therefore runs with Admin privileges too. It then has code to disable Windows firewall and spontaneously download further code which logs your keystrokes. Or pehaps a logging entity that only exists in RAM (I had good fun with an Excel macro POC which resulted in a command/registry process only existing in memory). I think the advantage of a Linux Live CD here would be that (apparently) no relevant real-world malware exists on Linux (if you want to debate this, go post your arguments at the relevant Linux sub-forums around the web!), so this scenario wouldn't happen?

m00nbl00d wrote:But, is everyone really up to that? I mean, I am. You are. Others are. But, we are "one of a kind". Others, they don't install Sandboxie, at all. They don't know it. My relative uses it, because I installed it. I didn't restrict it that much, though. Code is dynamic, and, at some point in time, due to something new in a program, things may break. I've set Sandboxie in way that still gives a few convenience to my relative, otherwise I'd be asked to remove it, that's for sure.

Some people aren't up to even turning on the computer. But in my opinion, if one is going to the trouble of using separate accounts to separate their normal web-browsing/banking, and getting someone to apply High integrity levels, specific firewall restriction rules, and install Sandboxie and configure relevant restrictions, one should have no trouble finding motivation learning how to use Sandboxie optimally. And ultimately, in my opinion, this is what's going to make them safe, because with this knowledge/motivation, user error is minimised. The user error I'm talking about is as simple as mistakenly forgetting to switch accounts while doing banking, downloading applications (for upgrade) from unknown sources, (mistakenly) installing unknown applications from unknown sources (without verifying their integrity) as Administrator etc. The chances of all this occurring are much more likely for the "average user" than coming across spontaneous logging malware in-the-wild and/or on-the-fly and/or a document somehow getting corrupted/infected with logging malware - I've never even heard of the last one happening in computer history.

But yes, at the end of the day, if your relative (or anyone out there) is happy with your setup/approach, then that's great!

m00nbl00d wrote:There's also one thing that I never really bothered with. If one forces a USB flash drive, by forcing its letter... At some point in time, Windows will no longer remember what letter it gave to xyz USB flash drives.

I've never had a problem with this. Worse case is simply forcing all possible drive letters (eg. from A to Z) to open/run sandboxed. In my setup, my "CD/DVD sandbox" has the relevant drive letters forced, and my "USB sandbox" has the next three letters forced - I never have more than three USB storage devices connected. Never had a problem with Windows no longer remembering what letter it gave etc. And as I already said, if you want to be sure, you can just force all drive letters.

I suppose this is probably not necessary in the grand scheme of things, especially if auto-run is disabled etc. I tend to open USB drives manually by right clicking the drive letter and left clicking "Run Sandboxed" anyway.

m00nbl00d wrote:There are some things that average users will never feel like learning. For that, they have people like us. But, even then, we can't force them to a whole new world at once. It takes time.

Heck, it took me more than 2 years to make my relative switch from IE to Chromium. lol

In my experience, no "average user" will go to the trouble of switching accounts to do banking, or even install Sandboxie. But it sounds like you're doing good work on your relative haha.

m00nbl00d wrote:Well, BSA isn't something that most average people would like to have or use, or even know how. But, running their browser, to access their bank account or shopping, in a Secure Desktop would probably be something welcome, perhaps.

I might suggest it... might... I don't wish to upset Tzuk... lol

BSA was just an example. There are many (apparently) simple tools that tzuk has not been keen to implement, probably because of a combination of potential for programming/application conflict and time/effort required.

I don't think tzuk would be upset if you simply asked him haha. I'll tell you now that the answer will almost certainly be negative though. Anyway, sounds like there are other tools you can use to achieve something similar? You've already mentioned KeePass or what not.

ssj100 wrote:
I'd say that's an under-statement. I've never even heard of CD/DVD players only reading original CDs/DVDs - is that a fairly normal thing nowadays? And most computers nowadays have ample USB ports - for example, my nearly 5 year old system has two USB ports at the front of the box, eight USB ports behind, and another two USB ports in the monitor.

Anyway, I suppose that's besides the point of this thread. I just can't believe how "unlucky" your relative is haha.

Unfortunately, the damn CD/DVD player only reads original ones. lol Not really sure why. Perhaps some firmware issue. It's also a laptop older than 5 years, I believe. And, it's really a stupid design to have USB ports on the laptop's front. All a person has to do is move the arms, while writing, and the USB device may disconnect and over time even break or the person loosing whatever may be in the flash drive. I don't think laptops have that many USB ports? Anyway, this is way off-topic. lol

But, as I mentioned, there are people who are still dial-up, or even low-speed Internet connections. Right on, I'm on 128 kbps connection. No way I would ever download a Linux ISO file. I'm not that crazy. lol

ssj100 wrote:
But isn't your browser running with Admin privileges to start with (or am I missing something here)? Regardless, I agree, with your firewall rules in place (by the way, are you using Windows Firewall or a third party firewall? I feel this is potentially important if you're giving Admin privileges to your browser), there shouldn't be any realistic dangers whatsoever. The only thing I can think of is if an unknown entity somehow hijacks your browser process, perhaps via a privilege escalation exploit, and therefore runs with Admin privileges too. It then has code to disable Windows firewall and spontaneously download further code which logs your keystrokes. Or pehaps a logging entity that only exists in RAM (I had good fun with an Excel macro POC which resulted in a command/registry process only existing in memory). I think the advantage of a Linux Live CD here would be that (apparently) no relevant real-world malware exists on Linux (if you want to debate this, go post your arguments at the relevant Linux sub-forums around the web!), so this scenario wouldn't happen?

Yes, the browser would be running with Administrator privileges. But, for something to mess with the browser's process, and for now I'll be excluding privilege escalation, this something would need to 1) Be executed, somehow. (Remember, the browser can't download anything other then documents from the bank's website.), 2 Get access to Program Files dir, which is off-limits to users. Only admins can access it. If something accesses it, then it's already running with Administrator privileges.

For this unknown entity to hijack the browser process, the user needs to, somehow, execute it. No unknown entity will be executed via the web browser. Unless the bank itself is going to attack you.
So, this unknown/malicious entity is coming from outside the browser. Is it a flash drive? Is it an mp3? Is it some random PDF file? Is it something the user downloads, from somewhere else, using another browser, and installs it?

Whatever the attack vector is, it means one thing: The user is being careless.

As a principle, and while most people don't do it, because they lack the knowledge, I always create separate standard user accounts for my relatives. This is a practice that should be followed. Such approach already provides some isolation, because if an infection happens in the standard user account user for general web browsing, as long as the infection happens in user-space, it won't spread to other user accounts, and the user account used for banking is safe and sound.

Now, let's bring in privilege escalation.

Supposing that I'm on my general web browsing user account, and somehow something manages to get administrator privileges, then it won't matter whether or not the browser used for banking will be run with administrative rights. Something already got administrative rights and can make the changes it wants. It can hijack any process and bypass any firewall rules. It doesn't need to disable Windows firewall, at all, IMHO.

Let's keep the system clean for now, shall we?

We are on the user account that's used for banking. As long as the user doesn't open anything that shouldn't be opened, then no unknown entity will be given a chance to try and have privilege escalation.
I say this because, as I mentioned, the browser can't possibly download anything malicious from the web, due to drive-by downloads, because the browser can only connect to the bank IPs.
This means that any unknown entity needs to come from somewhere else. It won't come from browser, and it won't come from the user account, unless the user stupidily introduces something he/she shouldn't introduce to the user account.

Of course, the user could innocently open a doc file and infect one user account, and this would use privilege escalation and massively infect the system, etc. From this point on, game over. It doesn't really matter whether you're running something as administrator or not.

I gave an example. Google Chrome installs to user space. Malware running in user space can mess with Google Chrome without any sort of problems. It can even completely kill Google Chrome's sandbox by applying an explicit medium integrity level. An object running with a medium integrity level can raise another object's integrity level to its own integrity level just fine. Nothing* would stop malicious code from messing with Chrome's chrome.exe integrity level.

* But, things don't have to be this way.

One can apply SRP, AppLocker or some other sort of executables restriction. Something quiet that the average user can deal with, once set up.

So, let's assume I've also set up AppLocker. My relative opens something in one user account. This something happens to be an infective doc file. AppLocker should stop it. Word would open, but not the malicious code.

I'm familiar with those flags that allow bypassing AppLocker, but not a concern for home users, anyway.

So on...

Couldn't I simply ask: Can't something get privilege escalation through Sandboxie's process SbieSvc.exe? It runs with a System integrity level. System integrity level is above High integrity level. You can go from High to System, though. I mean, something that gets a High integrity level, can go to System without problems.

I can even terminate Sandboxie's service just fine with Process Explorer. Sandboxie doesn't protect itself.

What we're talking about are a few scenarios, and this one with Sandboxie's service process could be one. Couldn't it?

ssj100 wrote:
Some people aren't up to even turning on the computer. But in my opinion, if one is going to the trouble of using separate accounts to separate their normal web-browsing/banking, and getting someone to apply High integrity levels, specific firewall restriction rules, and install Sandboxie and configure relevant restrictions, one should have no trouble finding motivation learning how to use Sandboxie optimally. And ultimately, in my opinion, this is what's going to make them safe, because with this knowledge/motivation, user error is minimised. The user error I'm talking about is as simple as mistakenly forgetting to switch accounts while doing banking, downloading applications (for upgrade) from unknown sources, (mistakenly) installing unknown applications from unknown sources (without verifying their integrity) as Administrator etc. The chances of all this occurring are much more likely for the "average user" than coming across spontaneous logging malware in-the-wild and/or on-the-fly and/or a document somehow getting corrupted/infected with logging malware - I've never even heard of the last one happening in computer history.

The thing is, even if most average users don't know what an administrator account is or what a standard user account is, we can still create such accounts, and tell them to use the two user accounts. One standard user account for the general web browsing, IM, etc., and the other one for banking only. It's a concept easy to understand. The user only has to know that he/she can still browse, etc in the standard user account.

I don't think there's even a chance not to know which account to open. Example of names: User.general, User.bank. There's no mistake.

The same could be said about Sandboxie free version, for example. Users need to manually start something in sandbox. They need to remember it. Or, they also need to remember to add their flash drives, etc. Or, to force Explorer. I've read a thread at Sandboxie forum that sometimes things may not always run Sandboxed. The user would need to open, say, Explorer sandboxed and then open from there.

Most folks won't know how to create shortcuts either, etc.

How many sandboxes? What to restrict? What happens when the user tries to open a zip file in the browser sandbox, but the application isn't allowed and the user gets those error messages? I tried this approach with a relative of mine in the past, but I had to uninstall Sandboxie because of stuff like this "Oh, I can't open a pdf file in my e-mail client sandbox. Why not?". My answer: "Damn, I forgot to allow it.". Then it would be the browser that wouldn't run in the e-mail client sandbox either, because I never considered that scenario. This relative of mine enjoyed/enjoys to open links directly from the e-mail client. Then it would be the media player... and some error message appearing. Or, if I chose to disable error messages, but same hell.

I keep it simple with Sandboxie now. For example, in the general web browsing account, my relative uses Chromium with an explicit low integrity level and a few other restrictions. But, it's not forced to run in Sandboxie. PDF reader is, though. Etc.

There are always so many variables for this or that not to work or to work.

ssj100 wrote:
In my experience, no "average user" will go to the trouble of switching accounts to do banking, or even install Sandboxie.

I agree in part. I agree with not installing Sandboxie. But, if they care about their money, they will listen those who know what they're talking about and accept the fact that two users account, being one from banking, creates isolation. It's easy and fast to switch accounts.

The same easiness is not found in Sandboxie, unfortunately.

In reality there are many ways to bank on-line securely; m00nbl00d's method will probably work fine, but there are numerous other ways as well.

wat0114 wrote:In reality there are many ways to bank on-line securely; m00nbl00d's method will probably work fine, but there are numerous other ways as well.

And, that's the beauty of it.

Heck, I could even couple the test I suggested/that I've done with Prevx SafeOnline/Trusteer Rapport/Etc. In this case I coupled it with Sandboxie.

There's so much users could deploy, for a general and relatively safer experience, if they can't use live cds for whatever reason, of if some word other than Windows scares them.

Anyway, what I mentioned was just a test that I've done in my relative's system. I'm still investigating more stuff, but I just thought of sharing the integrity levels approach. It works against keyloggers damn well. And, unless I'm mistaken, but I will investigate, it would also work against malicious code in process's memory. Say we apply a low integrity level to a media player. Anything initiated by it will inherit its low integrity level as well, and I don't think malicious code would be any different. But, I'll test it out with some PoC whenever I can.

I think wat0114 sums it up well, and I will reference my previous comment too:

But yes, at the end of the day, if your relative (or anyone out there) is happy with your setup/approach, then that's great!

As I've said already, I think this approach is rather excellent, and in fact, the two best parts of it (that make it rather "bullet-proof") are the following:
1. Firewall restrictions
2. Integrity levels

I don't think Sandboxie really plays a significant role to secure online banking/transactions with your relative's setup.

Unfortunately though (and as you've alluded to), I believe at the end of the day, the user is the most important safety factor - user carelessness (and lack of awareness) must surely be (one of) the most important factors contributing to the likelihood of malware infection and malicious logging. This is why I'm so "meticulous" (as Scoobs put it!) with my setup/approach - in some ways, it's forcing me to be careful. It's also about reaching that happy medium of security and convenience.

By the way, a little off topic but still related to safe online banking etc (I may move posts as required, but I don't really care unless other members care), what do you know about (Firefox) NoScript and protection against DNS hijacking and fraudulent SSL certificates?

ssj100 wrote:I think wat0114 sums it up well, and I will reference my previous comment too:

But yes, at the end of the day, if your relative (or anyone out there) is happy with your setup/approach, then that's great!

As I've said already, I think this approach is rather excellent, and in fact, the two best parts of it (that make it rather "bullet-proof") are the following:
1. Firewall restrictions
2. Integrity levels

I don't think Sandboxie really plays a significant role to secure online banking/transactions with your relative's setup.

Yes, you're right. Sandboxie doesn't play a significant role, except for two "simple" tasks: contain browser files in the sandbox and then securely erase with Eraser.

Unfortunately though (and as you've alluded to), I believe at the end of the day, the user is the most important safety factor - user carelessness (and lack of awareness) must surely be (one of) the most important factors contributing to the likelihood of malware infection and malicious logging. This is why I'm so "meticulous" (as Scoobs put it!) with my setup/approach - in some ways, it's forcing me to be careful. It's also about reaching that happy medium of security and convenience.

Yes, (un)fortunately, the user does play a role. If the user isn't careful, at the end of the day, it won't really matter if he/she even uses a Linux live cd. What happens if the user ends up using the same browser to browse the web, while access the bank account?

By the way, a little off topic but still related to safe online banking etc (I may move posts as required, but I don't really care unless other members care), what do you know about (Firefox) NoScript and protection against DNS hijacking and fraudulent SSL certificates?

I'm not a Firefox user, and therefore not a NoScript user, but I took a look at the website, and judging by the features won't do anything against fraudulent SSL certificates.

It does help against XSS attacks, which is helpful. I thought Firefox protected their users against it?

Anyway, NoScript won't do nothing against fradulent SSL certificates. Something like Prevx SafeOnline or Trusteer Rapport would be useful, because they will verify the server's IP(s). So, if the IP doesn't match with the real IP, then for sure they should alert the user.

m00nbl00d wrote:
Yes, (un)fortunately, the user does play a role. If the user isn't careful, at the end of the day, it won't really matter if he/she even uses a Linux live cd. What happens if the user ends up using the same browser to browse the web, while access the bank account?

Odds are pretty good nothing at all will happen. Browsing the web while banking on-line, especially in a live Linux environment, doesn't automatically guarantee infection. A somewhat careless user in the hands of a security-enhanced machine banking on-line probably stands a decent chance of coming out of it unscathed.

m00nbl00d wrote:I'm not a Firefox user, and therefore not a NoScript user, but I took a look at the website, and judging by the features won't do anything against fraudulent SSL certificates.

It does help against XSS attacks, which is helpful. I thought Firefox protected their users against it?

Anyway, NoScript won't do nothing against fradulent SSL certificates. Something like Prevx SafeOnline or Trusteer Rapport would be useful, because they will verify the server's IP(s). So, if the IP doesn't match with the real IP, then for sure they should alert the user.

I'm having a very similar exchange on the Sandboxie forums, but never mind haha.

NoScript can enforce specific sites (eg. banking sites) to only load if HTTPS is available. Therefore, the only issue here would be with an "attack" which uses fraudulent SSL certificates with DNS hijacking? But since the issue here can be addressed by using IP address verification, couldn't this be achieved with relevant firewall restrictions (much like what you've been discussing) or manual checking/verification of the IP address when one visits their eg. bank site? I think I'd rather do this than rely on yet another "third-party" vendor (with administrative rights) with this kind of sensitive digital information.

ssj100 wrote:
I'm having a very similar exchange on the Sandboxie forums, but never mind haha.

I'll head over there, maybe tomorrow and give a read to that discussion. Maybe I'll learn something else.

NoScript can enforce specific sites (eg. banking sites) to only load if HTTPS is available. Therefore, the only issue here would be with an "attack" which uses fraudulent SSL certificates with DNS hijacking?

This is taken from NoScript website:

Anti-XSS protection

Cross-Site Scripting (XSS) vulnerabilities are usually programming errors made by web developers, which allow an attacker to inject his own malicious code from a certain site into a different site. They can be used, for instance, to steal your authentication credentials and, more in general, to impersonate you on the victim site (e.g. your online banking or your web mail).

If one restricts the browser to connect only to the bank IP, which is unique, then such type of attack would never happen. But, for the general crowd, who don't even whitelist JavaScript, etc., I suppose NoScript would be useful.

The question is: To what point would people want to trust NoScript (the author)? Years have, probably, shown him as a credible person... still... But, I suppose the same could be said about security software. Or, are we relatively safer with known and estabilished security companies to help protect our credentials/money? Tough question, perhaps.

Anyway, NoScript would also be useful for that. By the way, does Firefox protect against XSS attacks? Is it really needed to use NoScript for that? IE and Chrome do it, by the way. So, I'd use one of these to access the bank account.

But since the issue here can be addressed by using IP address verification, couldn't this be achieved with relevant firewall restrictions (much like what you've been discussing) or manual checking/verification of the IP address when one visits their eg. bank site? I think I'd rather do this than rely on yet another "third-party" vendor (with administrative rights) with this kind of sensitive digital information.

Yes, firewall restriction would be enough. The only thing a stolen SSL certificate does it make people believe they're using the real service. It would make the fake service look the legit one. Well.. it has been certified... right?

Nonetheless... a fake page. Not in the same IP. It can't... unless the attacker hacks the bank's servers...

Page is fake... IP is not the same... But, for most people the SSL would make it look like the real deal. The danger would rely more in other type of services, with shared IPs and IPs that may not always be the same. In my opinion, of course. Unless I'm missing some other relevant information... I'm only human, after all. lol

Cross-Site Scripting and HTTPS enforcement are 2 different things (among many others) that NoScript offers.

HTTPS enforcement (from NoScript web-site):

HTTPS stands for "Hypertext Transfer Protocol over Secure Socket Layer", and you can figure it as HTTP (the protocol you usually retrieve web pages with) over a secure encrypted connection. It is meant to protect you from eavesdroppers and man-in-the-middle attacks. An important feature of HTTPS is that if a web site has a valid digital certificate for its identity, as verified automatically by your browser, you can be reasonably sure it is the one it says to be. You can recognize HTTPS web sites by looking at their addresses, always beginning with "https://". Firefox hilights sites having a valid certificate turning part of the location bar to blue or green. Since NoScript security is largely based on domain names, a malicious party capable of spoofing a trusted site might work-around your whitelist. This kind of spoofing may happen through a DNS Hijacking attack or because you're using an untrusted proxy server, like many anonymizers including Tor. The former risk can be mitigated by configuring a static secure DNS, e.g. OpenDNS, and forcing its usage even if you're roaming with your laptop. Untrusted proxies or connectivity providers are harder to tame, because a man-in-the-middle could inject arbitrary content in any non-secure (non-HTTPS) page. In order to mitigate these issues, NoScript can be configured to honor your whitelist only if the current page is served through HTTPS, and therefore cannot be spoofed. Additionally, NoScript can help you forcing your most sensitive sites to always use HTTPS, and mitigating cookie hijacking.

Q: How can I tell NoScript to allow only the sites of my whitelist which are served through HTTPS?
A: Open NoScript Options|Advanced|HTTPS|Behavior, click under Forbid active web content unless it comes from a secure (HTTPS) connection and choose one among:

Never - every site matching your whitelist gets allowed to run active content.
When using a proxy (recommended with Tor) - only whitelisted sites which are being served through HTTPS are allowed when coming through a proxy. This way, even if an evil node in your proxy chain manages to spoof a site in your whitelist, it won't be allowed to run active content anyway.
Always - no page loaded by a plain HTTP or FTP connection is allowed.

Q: Can NoScript force some sites to always use HTTPS?
A: Yes, just open NoScript Options|Advanced|HTTPS|Behavior, entering the sites you want to force in the topmost box, and those you want to always leave alone in the bottom one.
You can use space-separated simple strings, which will be matched as "starts with...", glob patterns like *.noscript.net and full-fledged regular expressions. If, for instance, you want HTTPS to be forced on every Google application excluding Search and iGoogle, you can put

*.google.com

in the "Force" box and

www.google.com/search www.google.com/ig

in the "Never" box (the latter can be of course rewritten as a

^https?://www\.google\.com/(?:search|ig)\b.*

regular expression).
Notice that NoScript provides also a mechanism for web site to declare they want SSL forced on their connections.

So I suppose a "banking browser" would have the "Always" option selected (meaning no web content loaded by plain HTTP or FTP connections is allowed) and also have the specific banking domain to only load HTTPS content.

m00nbl00d wrote:The question is: To what point would people want to trust NoScript (the author)? Years have, probably, shown him as a credible person... still... But, I suppose the same could be said about security software. Or, are we relatively safer with known and estabilished security companies to help protect our credentials/money? Tough question, perhaps.

Very tough question. I guess it's all about whether the software has proven itself over the years. For example, Sandboxie is only run by one man, and yet I "trust" Sandboxie to protect me more than any other apparently "established security company".

m00nbl00d wrote:By the way, does Firefox protect against XSS attacks? Is it really needed to use NoScript for that? IE and Chrome do it, by the way. So, I'd use one of these to access the bank account.

I don't know. I'd bet it protects against some XSS attacks, but not all. I would also bet that is also true for IE and Chrome. Unfortunately I don't have much knowledge in XSS attacks to comment further.

By the way, feel free to continue discussion (as you deem relevant) here:
https://ssj100.forumotion.com/t428-methods-for-improving-security-when-performing-online-transactions#3587

ssj100 wrote:
Cross-Site Scripting and HTTPS enforcement are 2 different things (among many others) that NoScript offers.

Yes, I know. I ended up mixing replies.

Part of my first reply If one restricts the browser to connect only to the bank IP, which is unique, then such type of attack would never happen. was meant has an answer for:

ssj100 wrote:
NoScript can enforce specific sites (eg. banking sites) to only load if HTTPS is available. Therefore, the only issue here would be with an "attack" which uses fraudulent SSL certificates with DNS hijacking? But since the issue here can be addressed by using IP address verification, couldn't this be achieved with relevant firewall restrictions (much like what you've been discussing) or manual checking/verification of the IP address when one visits their eg. bank site?

But, then I mentioned the NoScript feature Anti-XSS, which is also a useful feature, in various credential scenarios.

Sorry for the confusion.

m00nbl00d, when you say you use a firewall to restrict access to only the bank IP address, how exactly do you achieve this? You'd have to allow a range of IP addresses right (that's quite a few I think)? Also, wouldn't you also have to allow the relevant IP address range that provide your browser with information on the SSL certificate?

Or are you not worried about the SSL certificate, since you're confident with your IP address restrictions?

Would be nice if you could share what your "banking firewall setup" looked like, or at least give a guide.