CSA and File Uploads

[joseph.hamilton]

I posted a message about this before, but the nature of my problem has changed a bit...

Whenever a user will go to upload a file, they click on the "Browse..." button to pick the file. This opens an "Open File" dialog window that shows the files in the current directory.

At this point, usually beginning when the user clicks on a file in the window, the user qill be queried, saying that the web browser is attempting to read the document and will they allow it. Shortly after, the web browser will then start reading files randomly from that directory, even if the user doesn't click on them.

In the end, it becomes a big mess of user queries. I'm worried that users will either get annoyed or confused and start clicking Deny. If they click Deny on the CORRECT file they want to upload, the response is temporarily cached and the file will be blocked from uploading until the user clears cached responses.

I want to limit the queries from users without risking the integrity of the document security. Anyone have ideas or have had this issue occur?

[thomas.chen]

Check if other applications are working fine with IE.If it is working if you have some firewalls disable them.Then try to uninstall and reinstall CSA.

[RichardSW]

Can you define here what rule you have that is triggering on the file browsing?

My guess, is that rule is monitoring file Reads, and when you open a directory, the act of listing those files is "reading" each one.

[joseph.hamilton]

I've cloned the rule, but at it's base, it's a File Access Control rule in the Document Security Module Rule Module.

And from what I can tell, it doesn't always trigger for every file. The last simulation I ran, it attempted to read the file I clicked on, then tried to read two random files, then stopped. I know it's likely a Windows behavior, but I don't understand it and I don't know how to get around it.

[RichardSW]

Can you paste the values of your cloned rule here? When Windows displays a directory listing, it has to "read" every one of those files to get the file names, or pull those values from the Indexing service if its turned on.

[RichardSW]

Okay, the best way I can answer your original question, is to change your custom query so "Enable Don't ask again option" is CHECKED. I believe by default this option to the user is unchecked. So unless the user intentionally checks it, it should not be cached.

This sounds more like a bug you encountered, because if you have the option to remember the answer disabled, why would it be caching it as a default? Unless I'm misunderstanding this particular functionality in CSA.

Why do you think there is a security risk with IE accessing Word documents? Web browsers are sandboxed, and require either user intervention or some kind of code injection to break out of the sandbox. If the former, you're still reading the document locally (but using an IE plugin) and its still cached locally, which is no more risk than running Word. If the latter, you can easily prevent this by ensuring you have a System API Control rule for every System Modification Check.

[joseph.hamilton]

I guess I was thinking that someone could attack as IEXPLORE.EXE and gain access to read someone's personal files. Unfortunatley, I'm still relativley fresh to the IT Security world, so I don't know a lot of these things about applications. It just sounds like you wouldn't want to grant access universally to allow any application to read all documents.

Also, right now the "Dont Ask Me Again" option is UNCHECKED, but even then, the Agent stores the response locally for about 60 minutes. Therefore, if the user accidentally clicks no, either the Agent will have to be reset or the user will have to wait an hour before uploading. If this was a small environment with only a few users, I would just reset if that were the case, but we have over 1,000 users and I want CSA to remain as automated as possible.

[RichardSW]

Its okay if you're fresh, nothing wrong with jumping into security with both feet running. :)

If your concern is restricting documents to only the applications that are supposed to open them, you could create a File Access Control rule as follows (using Office as the example):

- Take the following action: Deny

- when Applications in any of the following selected classes:

- But not in any of the following selected classes: MS Office applications, MS Office descendents, Virus scanner applications, Backup applications

- Attempt the following operations: Read File, Write File

- On any of these files: $MS Office data files

Anyhow, I decided to test a rule of my own to see how IE behaves when a file path is put in the address bar. My File Access Control rule was:

- Take the following action: Monitor

- when Applications in any of the following selected classes: Web broswer applications

- But not in any of the following selected classes:

- Attempt the following operations: Read

- On any of these files: $MS Office data files

I opened a test doc through IE, and the event I got was:

The process 'C:\Program Files\Internet Explorer\IEXPLORE.EXE' (as user STATION1\RichardSW) attempted to access 'C:\Documents and Settings\RichardSW\My Documents\test.doc'. The attempted access was a read (operation = OPEN/READ). The operation was allowed by a rule (rule defaults).

The reason this happens is because IE is loading the file path, but the file itself is not interpreted by IE, instead WordPad opens it up.

Next, I tested this rule against several http-based file upload demos. None of them tripped an alert.

I'll keep looking into this...

[RichardSW]

Okay, to watch if Internet Explorer is attempting to run a script that could potentially gain access to the file system, create the following COM component access control:

- Whatever action you want to take

- when Applications in any of the following selected classes: Web browser applications

- But not in any of the following selected classes:

- Attempt to access a COM component Matching any of the following component sets: $MS File System Objects

This will trigger when Internet Explorer (or Netscape, Opera, etc.) attempts to use the "Scripting.FileSystemObject" system object. That combined with the other API rules should satisfy your concern about IE accessing non-web documents, while keeping user intervention to a minimum.

Unfortunately I don't know if Sharepoint will still trigger on it.

[joseph.hamilton]

ok, I think I may try this, but one question (this goes for all readers)...

Let's just say I deny access for any other applications other than Web browsers and MS Office programs to read .doc files. Can you see any way an attacker could use IEXPLORE.EXE to gain access to files then to either steal information or use the information in an attack?

[RichardSW]

In the past there have been announcements of critical exploits in IE that allowed a web script/applet/control gain access to any document on the machine that the local User also had access to. These exploits have been found in these engines:

- Windows Scripting Host (WSH/VBScript/Jscript)

- ActiveX

- Java Runtime

- Javascript

Keep in mind that in all of these cases, for the exploit to work the User has to open IE and go to the website with the malicious script. One example is an old exploit that didn't properly localize IFRAME, and a script could jump outside of the sandbox and read any file on the hard drive.

I think the problem you want to solve is best headed by good patch management, a web proxy, and restricted user accounts. Also, the COM control I noted before would take care of scripting engines trying to access the file system. I still need to come up with a good rule that keeps an eye on the Java Runtime and WSH (which doesn't require IE at all).

It would be good to hear from other windows admins though - maybe you have the right idea about blocking IE altogether - one less thing to worry about in the future. But if your users have the option to click Yes and allow the connection... then you haven't really stopped anything.

[tsteger1]

Defense in depth is the best security. If you have Patch Management, AV (including Spyware, Adware, Grayware, etc..), CSA and perimiter security, the chances of any one thing getting through all layers are quite slim.

Even if it does (by a user clicking yes when they should click no), you've only allowed the vector for a payload to execute. Then the payload must also pass through the security gauntlet. And even then it will probably be isolated to that one machine.

You've got to balance security with the user's ability to do their jobs. If the security you have in place constantly bugs them they'll either find ways around it or complain to management.

My goal has always been to make security as transparent to users as possible. I chose not to use all of CSA's capabilites because I know I have backup with the other tools we use.

Tom S

[joseph.hamilton]

ok, my concerns are laid to rest then.

I created the COM access rule, and that actually solves my problem. It only triggers for that first read, so the user isn't inaundated with queries, and it still makes sure that some other user is taking IEXPLORE.EXE and hijacking files.

I'll just need to see where else it triggers. Thanks!