Application and server security

[ACDC]

This problem clearly exists from outside the network.

kklosson
sorry to sound obnoxious but have you in fact tested from outside the network, because your reply sounds like you have made the assumption. Localhost will let you traverse across directories because you have rights to them. So I am still not so sure how serious this is

[kklosson]

I have in fact tested this. I can demonstrate how easily an authorized user can view the contents of BASServer.props. Nothing to it.

[ACDC]

thanks for the confirmation, this is something really to be concerned about

[kklosson]

For those who are interested... a video demonstration...
https://vimeo.com/123499693

[customaware]

Very interesting demonstration Kingsley.

I know virtually nothing about all this type of stuff and
it makes my head hurt thinking about it.

However, at the risk of confirming my ignorance rather than
just letting perception remain....

You exposed the flaw by finding where an export document had been
output to and then looking up and down the folder paths to find basserver.props.

If the export document was output to a place above the Tomcat folder then
would that avoid nefarious traversing of the folder tree?

[himanshu]

That's a very useful work and information share by KK.

As security is always be a prime question by any client who will going to use apps build on AwareIM. Will hope to get solution in near future.

[hpl123]

Worrisome!
Thanks Kklosson for the video / illuminating this issue and I also hope we can work out a solution for this problem ASAP.

The Basserver.props file is a very problematic thing with DB credentials etc. in it. What are the other files in the Aware IM directory that directly pose a security risk? Having the Aware IM folder fully restricted from outside localhost, is, of course, the only viable solution for this problem but just wondering as of right now, what else is exposed?

[kklosson]

Two things right off: if you are using a folder for files that have to be called from a URL, then that file store would have to be in the webapps folder tree somewhere as far as I know. So those files would be viewable and retrievable. Secondly, the location and password of the keystore file for the site cert. A lot can be done by implementing the Tomcat security, which in my view is difficult, but that's what it is there for. Security implementation is generally via the catalina.policy configuration file. Also, my team is considering using an Apache or IIS server as a proxy to the whole site. So that all server requests and responses go through a proxy server.

[aware_support]

Please note that your first post refers to a file download operation in Aware IM. If the problem only applies to this operation it should be quite easy for us to remove this security vulnerability in the next build. Or is there something else?

If there is, please indicate exactly how an intruder can access the server, just like you did with the file download operation.

[kklosson]

It is the file download operation that causes the greatest concern. My penetration tester said he went right to that function because he knew it would expose the path on the server, then attempted to see how far he traverse within the directory structure. If this can be resolved with changes in a build, I'm very excited to know it. Using the same technique, an authorized user could seemingly view the contents of any text file in the system. So the primary issue is directory traversal based on the exposure of the URL.

[hpl123]

I don´t know fully how this problem works but here are some of my thoughts. You are talking about the file download operation because that is what the "hacker" used to find the url he used in the repeater? I found out the url by doing several other things like "Display in printer-friendly format", or even by just running a query? In the example screenshot below I ran a query in the CRM sample application and then looked at the Chrome developer tools "Network" tab to see what happened and I saw this:


kklosson, can you verify this is the same URL and one that theoretically (if you don´t feel like testing it) could be used to do the same exact thing the "hacker" did?

Support, isn´t it possible to change the permission of certain files or folders as part of the Aware IM installation like for example Basserver.props and other risky files? The best thing would again, of course, be to fully restrict all access outside of localhost to all files if that is possible?

Another related thing, currently both DB credentials and SSL information (possible other important information) are written in plain txt files open for anyone to see. The issue we are discussing in this post is trying to limit access to various files BUT actually not having these unprotected on the server is also something that would make me sleep better at night. Another thing here is the MySQL encryption keys which we have to place in a txt file so Aware IM can use those files and this is a MySQL implementation i.e. having the keys open/unprotected in txt files on a server BUT the Aware IM implementation of encryption COULD implement a better / more secure solution like having the encryption keys etc. in the configuration tool BSV settings followed by some kind of encryption inside Aware IM to protect this data.

[kklosson]

What you need to understand is that using the tool and methods I described in the video, many things are possible. For example, I can intercept a query having a where clause, remove the where clause and forward to the server; receiving back more records than the query was designed to provide. So if your application relies on restrictive queries alone to limit access to information, this can be easily usurped. This is where access level and Protect Rules come into play because if an authorized user modifies the query in this way, the protection rules will restrict the return to only those records allowed by access level and protection rules.

What I see in your message is not a URL, but I could easily modify the query to retrieve all records unless access levels and protection rules prevent it. My tester knew that any function that downloads a file requires a URL that points to some path and from then there performed directory traversal - a common technique to conduct various forms of mischief and discovery.

[BobK]

The only thing I know about computer security is that it is needed, so hopefully this question will not sound too ignorant.

If I am using SSL, wouldn't that stop a hacker from modifying the query and getting more and/or different records than intended?

[kklosson]

No.

[BenHayat]

What you need to understand is that using the tool and methods I described in the video, many things are possible. For example, I can intercept a query having a where clause, remove the where clause and forward to the server; receiving back more records than the query was designed to provide. So if your application relies on restrictive queries alone to limit access to information, this can be easily usurped. This is where access level and Protect Rules come into play because if an authorized user modifies the query in this way, the protection rules will restrict the return to only those records allowed by access level and protection rules.

What I see in your message is not a URL, but I could easily modify the query to retrieve all records unless access levels and protection rules prevent it. My tester knew that any function that downloads a file requires a URL that points to some path and from then there performed directory traversal - a common technique to conduct various forms of mischief and discovery.

I fully agree with you using Access Level and Protection Rules as first step. But I had to give up using any Access Level on any objects, because once we introduced any access level on any object, user lost the Delete function on that object, which causes problems not being able to delete unwanted records. I bring this up, because as much as I want to use Access Level, it has some bad side effects. There was other things too, but I don't remember.