I am developing a web application and I am wondering if someone has a full read-only access to my filesystem, can this person (assuming that he is aware of everything necessary) have a write access to the system?
For example, if you have a PHP script that outputs contents of any files on the server - will someone really be able to gain a write access to the system somehow? Like... can he rewrite the PHP script?
I'm talking about web servers... so both Windows & Linux related comments are welcome. Also, are there cases where the cracker could have a write access to most files, but not to all on the system?
I'm just curious. To sum up: "Can a PHP local file include vulnerability ever give the cracker a write access to the files?"
A malicious user could download your password file and get cracking, or perhaps read the MySQL user table and get the password for your MySQL root user. Then use that user to gain further access using a privilege escalation exploit or something similar.
Substitute password file for registry (or SAM) and MySQL for MSSQL and the same argument works on Windows. No, it won't be very easy but yes, they will succeed.
Do not give anyone full (read) access to your system, ever!
Let me rephrase. If I have a PHP application running and someone can read my PHP files through an insecure PHP script and has a read-only DB access, will he be able to crack my whole server?
Perhaps. The probability of someone being able to hack your server in that situation is non-zero, therefore you cannot afford allow such a security hole to exist. They may not be able to rewrite your PHP script, but a read-only db user can perfectly use an exploit in the database server for example.
Any accounts which have write access to a given directory have the potential of being exploited.
Security is all relative. Attackers don't follow rules and they won't necessarily pick the attack vector you've hardened against. If you're concerned, make it so that only a select group of users can write to a directory. Do not include service/daemon accounts in this group. Use limited accounts for daily use. Follow good password policies (length, complexity, change frequency, etc.). Limit your attack surface by closing unused ports, etc.
You may even go so far as to encrypt the file-system. This introduces complexity and there's a chance you'll get it wrong . If you're really concerned, you can take a pessimistic security stance and deny everyone any access except the bare minimum they need to do the job you've assigned them.
In the end, even if you're the only one with 'technical' access to a resource, you could still be tricked or blackmailed or otherwise coerced into granting access. The best you can do is make attacks difficult--not impossible.
Related
Hi security aware people,
I have recently scanned my application with a tool for static code analysis and one of the high severity findings is a hardcoded username and password for creating a connection:
dm.getConnection(databaseUrl,"server","revres");
Why does the scanner think this is a risk for the application? I can see some downsides such as not being able to change the password easily if it's compromised. Theoretically someone could reverse-engineer the binaries to learn the credentials. But I don't see the advantage of storing the credentials in a config file, where they are easy to locate and read, unless they are encrypted. And if I encrypt them, I will be solving the same problem with the encryption key...
Are there any more risks that I cannot see? Or should I use a completely different approach?
Thank you very much.
A fixed password embedded in the code will be the same for every installation, and accessible by anyone with access to the source code or binary (including the installation media).
A password read from a file can be different for each installation, and known only to those who can read the password file.
Typically, your installer will generate a unique password per site, and write that securely to the file to be read by your application. (By "securely", I mean using O_CREAT|O_EXCL to prevent symlink attacks, and with a correct selection of file location and permissions before anyone else can open it).
This is an interesting one, I can give you examples for a .Net application (as you haven't specified running environment / technologies used). Although my guess is Java? I hope this is still relevant and helps you.
My main advice would be to read this article and go from there: Protecting Connection information - MSDN
Here is a page that describes working with encrypted configuration files here
I've seen this solved both using encrypted configuration files and windows authentication. I think that running your application as a user that will be granted access to the relevant stored procedures etc (as little as possible, e.g. Principle of Least Privilege) and furthermore folder access etc is a good route.
I would recommend using both techniques because then you can give relevant local folder access to the pool for IIS and split out your user access in SQL etc. This also makes for better auditing!
This depends on your application needs though. The main reason to make this configurable via a config file or environmental user account I would say is so that when you come to publish your application to production, your developers do not need access to the production user account information and instead can just work with Local / System test / UAT credentials instead.
And of course they are not stored in plain text in your source control checkin then either, which if you host in a private distributed network like GIT could mean that this could be compromised and a hacker would gain access to the credentials.
I think it depends on how accessible / secure your source code or compiled code is. Developers usually have copies of the code on their dev boxes, which are usually not nearly as secure as production servers, and so are much more easily hacked. Generally, a test user / pw is configured on the dev box, and in production, the "real" pw is stored in much more secure config files. Yes, if someone hacked into the server they could easily get the credentials, but that is much more difficult than getting into a dev box in most cases. But like I said it depends. If there is only one dev, and they have a super secure machine they work with, and the repo for their code is also super secure, then there is no effective difference.
What I do is to ask the credentials to end user initially and then encrypt and store them in a file. This way, I don't know their connection details and passwords as a dev. The key is a hashed binary and I store it by poking ekstra bytes in between. One who wants to crack it should find out the algorithm used, key and vector lengths, their location and the start-end positions of the byte sequence keeping the values. A genius, who would also reverse engineer my code to get all this information would break into it (but it might be easier to directly crack the end user's credentials).
In UNIX, if I give a website member indirect permission to write to a file, read from the file, but through a cgi, what are the security risks?
like so:
As you can see, only the cgi has permission to read and write to the file.
It would seem that this would prevent security problems.
OR AM I FOOLING MYSELF?
Edit:
here's how it works:
1. the user enters there info in a simple <form>.
2. the user sends the <form> to the cgi.
3. the cgi writes the <form> info to the file.
I guess my main worry is the user embedding destructive exes in the file.
However they don't have DIRECT permission to r/w the file.
also...
... it is this and only this file that the user can indirectly write to
The security implications depend on what affect viewing/editing said file has. If the user is able to view /etc/shadow (which contains password hashes), then they would be able to attempt to bruteforce user passwords. If they are able to access any configuration files as well, it may expose login details and other sensitive information.
If properly implemented, this system can be secure, but it would be fighting and uphill battle, and there are many other solutions that would probably suit your needs better.
I am currently working on a java search project that will be distributed to the clients' local server, the project contains some valuable data that we hope it cannot be accessed directly on the machine, but can only be accessed from the project services/apis. The data will be updated on a daily basis and need to be avaliable for query 24/7.
I am thinking of eCryptFs, but after some test, it seems that once the encrypted data is mounted under the service user, say 'root1', as I have to keep the encrypted data in the mounted state to support query, all the other login users can access the de-crypted data without password. Is there anyway to support my scenario? Thanks.
If your users don't have root access, you can simply store the encryption key in a file and deny read access to other users.
If your users do have root access, there is nothing you can do.
EDIT:
Under most circumstances, someone with root account can do anything that the other users can do. So, even if you did get per user r/w permissions on a file but only for a certain user (which is very possible), it would be rather pointless. (Someone with sudo/root access could just run sudo su USER, where USER is the account with the r/w permissions. I think a better way to go about this is to look at options that users do not have control over.
The first thing that came to mind was compiled programs. While they are not really meant for holding secure information, you could compile a simple program to output a little bit of the information after a time delay (to prevent them from just running it continuously and then compiling all of the data they get from it.) Actually, modifying your Java program might be easier; just have it store the information as an enormous string or something. :D
These open source Java obfuscators will make it harder (but certainly not impossible) to reverse engineer your program and, along with it, the data inside.
A more secure option would be to write a C program, compile it, and have it output information (after a time delay) that the JAVA file can then manage. In order to make it harder to decompile, you could add some encryption methods to the string so if the Decompiler messes up on any part of it, it's still worthless information to them.
Final verdict: Nothing is really 100% secure when it is stored on someone else's computer(s) but, then again, neither is it 100% secure on your own server. I would suggest looking into other options, but if you have no other option and you have legal protection on the information, this might work for you.
I have been asked to secure an Access database at the highest level possible, and something tells me password protecting the file is not sufficient. We have really sensitive data and I need to protect it to the greatest extent possible. Any ideas?
This has been an issue that I have had for several years with Access 2003. We set a Database Password on the database to lock it down so users would need the password to access it. Not necessarily the best option and kind of a pain.
Since you are using MS Access 2007 you might want to check out want Microsoft says are database protection options.
First, when discussing security, we have to define the threat model.
Common threats are:
Unauthorized access of data: Someone that shouldn't be able to read data, is able to read data.
Unauthorized modification of data: Someone that shouldn't be able to modify data, is able to modify data
Unauthorized destruction/corruption of data: Someone is able to vandalize the database
Privilege escalation: Someone who should be able to read or write some of the data, is able to read or write more than intended
Data exfiltration: someone who should be able to read some data is able to copy large amounts of data and move it to an external (or less protected) system.
Malware insertion: someone is able to insert malicious code into the application
The main defense for Access, as discussed, is encrypting the database using a database password. When using an accdb file, this generally offers sufficient protection against unauthorized access and modification of the data. This is a "one privilege fits all" approach, there is one password, if you have it, you have all privileges and can read, write, and insert components at will. Also, when you have write access to the file, but not the password, you are able to damage or delete the file.
A level higher is securing the Access file: using a secure file server to only serve the file to those who should have access to it. This comes with practically all benefits of encryption, and protects against destruction too, as unauthorized users cannot access the file. This also allows us to revoke rights to that folder, assuming the user hasn't made a copy.
If we want to work with user rights, we can separate the file into a front-end file, which does not contain privileged data, and multiple backend files, and secure these files separately, by either using a different password for each file, or storing them on separately secured locations. Again, secure locations offer the additional benefit of protecting against destruction.
Since Access requires users to have write permission to the file (for placing locks) to have read access, however, we can't easily separate read and write permissions this way. One approach I've seen used is using a "shadow folder", where a virtual folder is created for read users, and upon accessing the folder, the most recent database file is placed in it, and overwritten each time. Setting this up, however, is nontrivial.
Another approach which is very common is trying to use VBA to limit which actions users can take, and allowing them only to open specific forms and take specific actions on them. This is possibly combined with tricks like disabling the bypass key, and/or creating a compiled copy (accde/mde) without the original code. However, these will only stop novice attackers, and can practically always be bypassed, either by using a non-Access program to read the data (which will ignore any restriction imposed by VBA), allowing the bypass key through COM, disabling VBA altogether on the machine, etc. A compiled database only makes it impossible to view and modify the code, not the data, and this also can be bypassed by experts by manually reconstructing the code (example commercial service that offers this). Thus, while this may look like proper security at first glance, it has severe flaws.
Compiling the code is useful when combined with signing the code, to protect against unauthorized malware insertion. Since a decompiled, modified and then recompiled copy won't have a valid signature, assuming the attacker can't access the trusted certificate used to sign the code, and systems can be configured not to open compiled databases without that signature, this can help detect malicious modification of the database.
If we want to have separate user privileges, but cannot enforce this using separately secured folders, an option is to have separately encrypted backends with different keys. For usability purposes, we can use a key encryption key to have a separate password for each user, and have that password grant access to the backends which the user is allowed to use. I've created a sample of a database that uses key encyption keys for this Q&A, but nowadays I'd make some changes, such as using a single front-end with both the KEKs and linked tables to the encrypted databases, and using the CNG API for fast encryption in VBA.
Note that some of these options add a lot of complexity, and none properly protects against data exfiltration (which is an increasing threat in the country + sector I work in). Often, it's a lot more simple, in terms of infrastructure, management, etc. to use a different back-end than Access. This can still allow you to use Access as the front end, so users might not even notice a change, but management of permissions is determined by the back end, which can either be secured by using different passwords for each users, or, in case of SQL server, by linking security to an AD domain (SSPI).
In SQL server, we can also add logging, restrict fetching large datasets by only granting rights to stored procedures and limit the amount of requests over time, to mitigate data exfiltration. However, the added complexity this brings to using Access as a client often makes choosing a different client more sensible, if you only use stored procedures linked tables are not available and Access tends to make more requests than necessary.
Note that when choosing to use a different back-end, it is still recommended to compile and sign the Access database to mitigate malware insertion, which is not dependent on the back-end used.
Bonuses:
What about user-level security? That was a technology specifically intended to offer per-user read and write rights, and separate rights for modifying the database and managing users. Unfortunately, it was insecure and there are many tools out there to remove it, and it only applies to the mdb and mde database formats, so is not of any use.
And, of course, you can also secure the user by securing the environment that Access runs in. I've seen a deployment where users are only allowed to access resources in a virtual environment that is behind a firewall disallowing all internet access, is limited to only opening this specific database, doesn't allow storage devices, and doesn't share the clipboard with the main environment. That allows you to have a secure database by using VBA, but severely limits usability of the database (especially the copy-paste limitation frustrates users, but copying and pasting could be used for data exfiltration).
I would suggest you put it on a file server and have a strict access control list.
In the database force users to log in then
add triggers to write out audit info when a record changes (with the user info,date/time).
Some users are suggesting that my (C#) program should be able to run scripts after completing it's job. This would be done through a command line to be input in my configuration dialog.
I'm no security expert, so I'm not sure if this acceptable in terms of security. Since the app runs with admin privileges (on Windows), wouldn't that be a huge security risk? Someone could just modify the config files of my application to point to a potentially dangerous script, couldn't they?
On the other hand, plenty of applications allow this, while requesting admin privileges, so I guess it must be ok, but I thought I'd better seek advice before opening wide security holes everywhere =)
Can I allow my application running with full privileges to launch user-specified scripts?
You can restrict access to your config in different ways - from obfuscating the config file to using NTFS permissions to limit access of non-admin accounts to it.
C# certainly allows you to run a user script. System.Diagnostics.Process makes that real easy. The question of security here is another problem.
Running scripts when a process completes can be an incredibly useful and can make or break your target audience's opinion of your application. Understandably, you don't want your product to be turned against your own consumers through a malicious hack like you're thinking.
The root of this problem is that your options are (I'm assuming) text based and easily editable. Your best bet is to encrypt your config file to prevent outside changes to it. Note that this doesn't prevent people from using your app to change your options to allow a malicious script, but for somebody to do that, they need access to an instance of your application instead of simply file read/write access.
This does bring to question one more aspect you should watch for. Don't use the same key for every installation of your application. If you do that, then Bob could cause Alice to run a malicious script by copying Alice's config, using his instance of your app to decrypt it and make the change and then Bob can replace Alice's config with the new malicious config.
Here is another SO question for how to encrypt strings in C#.