What are ways an adversary can get hold of a password hash of a router remotely, that is not the default admin password using Linux?
Does the hash of the admin password reside in certain files?
Are exploits needed to gain access to the file(s) containing the password hash?
Purpose of this is to increase my knowledge, and improve security of devices in the home.
This very much depends on the router. If the router is based on Linux (which is often the case), access to the hashes is limited to the OS administrative user only (root in general). This administrative user will usually be different from the administrator account you use to connect to the router.
You therefore need to have vulnerabilities which allow you to attack services run by root or try to "elevate privileges", that is to use a vulnerability to have effective root rights going from another account.
This is to say that you should always have an up to date device. Unfortunately the vendors are not always quick in releasing patches when a vulnerability is discovered (often not in their devices, but in a library they use).
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#.
I'm interested in writing a replacement login screen for Ubuntu that would present the user with a puzzle rather than prompt for a password. I'm looking for some advice on how to go about creating this. I'm a programmer by profession with years of experience, but am not familiar enough with Linux application programming to know how to begin this particular project. Thank you!
You could probably do this as an authentication module for PAM (Linux Pluggable Authentication Modules).
PAM is configured in configuration files in /etc/pam.d. Each file in this directory defines a PAM service by specifying a set of PAM modules and how they should work together. You could write a new authentication module and replace the current authentication module in the services where you want to use the new login scheme.
The "best" way to do this may be to create a PAM module. This is how things like fingerprint identification are implemented. It will allow you to keep the same login screen with all the features such as accessibility options, etc.
The "easiest" way to do it may be to modify an existing display manager. Ubuntu uses GDM (Gnome Display Manager) by default, but it's pretty complicated. SLiM is a simple display manager that you can probably modify without much difficulty.
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.
Subversion has multiple server types:
svnserve daemon
svnserve via xinetd
svn over ssh
http-based server
direct access via file:/// URLs
Which one of these is best for a small Linux system (one to two users)?
http:
very flexible and easy for administration
no network problems (Port 80)
3rd party authentication (eg. LDAP, Active Directory)
Unix + Win native support
webdav support for editing without svn client
slow, as each action triggers a new http-action approx. 5-8 times slower than svn://
especially slow on history
no encryption of transferred data
https:
same as http
encryption of transferred data
svn:
fastest transfer
no password encryption in std. setup: pw are readable by admin
firewall problems as no std.port is used
daemon service has to be started
no encryption of transferred data
svn+ssh
nearly as fast as svn://
no windows OS comes with build in ssh components, so 3rd party tools are essentiell
no daemon service needed
encryption of passwords
encryption of transfer
1 of those options is definitely a 'worst' one: file access. Don't use it, use one of the server-based methods instead.
However, whether to use HTTP or Svnserve is entirely a matter of preference. In fact, you can use both simultaneously, the write-lock on the repo ensures that you won't corrupt anything if you use one and then use another.
My preference is simply to use apache though - http is more firewall and internet friendly, it is also easier to hook into ldap or other authentication mechanisms, and you get features like webdav too. The performance may be less than svnserve, but its not particularly noticeable (the transferring of data across the network makes up the bulk of any performance issues)
If you need security for file transfers, then svnserve+ssh, or apache over https is your choice.
Check out FLOSS Weekly Episode 28. Greg Stein is one of the inventors of the WebDAV protocol for SVN and discusses the tradeoffs. My takeaway is that SVN: is faster but the http/webdav implementation is just fine for almost all purposes.
I've always used XInetD and HTTP.
HTTP also had WebDAV going on, so I could browse the source online if I wanted (or you can require a VPN if you wanted encryption and a dark-net type thing).
It really depends on what restrictions (if any) you're under.
Is it only going to be on a LAN? Will you need access outside of your LAN?
If so, will you have a VPN?
Do you have a static IP address and are you allowed to forward ports?
If you aren't under any restriction, I would then suggest going with xinetd (if you have xientd installed, daemon if you don't) and then (if you need remote access) use http-based server if you need remote access (you can also encrypt using HTTPS if you don't want plain text un/pw sent across).
Most other options are more effort with less benefit.
It's an SVN Repo -- you can always pack your bags and change things if you don't like it.
For ease of administration and security, we use svn+ssh for anything that requires commit access. We have set up HTTP based access for anonymous (read only) access to some open-source code, and it is much faster; the problem with svn+ssh is that it has to start up an ssh connection and a whole new svnserve for each user for every operation, which can get to be pretty slow after a while.
So, I'd recommend:
http for anonymous connections
svn+ssh if you need something secure and relatively quick and easy (assuming your users already have ssh set up and your users have access to the server)
https if you need something faster, secure, and you don't mind the extra overhead of administering it (or if you don't already have ssh set up or don't want to deal with Unix permissions)
I like sliksvn runs as a service in Windows, 2mins to setup and then forget about it.
It also comes with the client tools but download tortoise as well.
If you are going to be using the server only on the local machine and understand unix permissions, using file:// urls will be fast, simple and secure. Likewise, if you understand unix permissions and ssh and need to access it remotely, ssh will work great. While I see somebody else mentions it as "worst", I'm pretty sure that's simply due to the need to understand unix permissions.
If you do not like or understand unix permissions, you need to go with svnserve or http. I would probably choose to run it in xinetd, personally.
Finally, if you have firewall or proxy issues, you may need to consider using http. It's much more complicated, and i don't think you're going to see the benefits, so I'd put it last on your list.
I would recommend the http option, since I'm currently using svn+ssh and it appears to be the red-headed stepchild of the available protocols: 3rd-party tool support is consistently worse for svn+ssh than it is for http.
I've been responsible for administering both svnserve and Apache+SVN for my development teams, and I prefer the http-based solution for its flexibility. I know next to little about system administration, I'm a software guy after all, and I liked being able to hand authentication and authorization over to Apache.
Both tines the teams were about 10~15 people and both methods worked equally well. If you're planning for any expansion in the future, you might consider the http-based solution. It's just as easy to configure as svnserve, and if you're not going to expose the server to the Internet then you don't have to worry too much about securing and administering Apache either.
As a user of SVN, I prefer the http-based integration with Apache. I like being able to browse the repository with my web browser.
I am curious why NOT FSFS?? Important information - I am managing Windows systems.
I have done many projects with SVN and almost all of them were running from FSFS. Biggest repository was around 70GB (extreme), biggest ammount of repositories was around 700.
We never had any issues, even though we hosted it on Windows, NetApp and many other storage systems. Most of the time when I asked why NOT using FSFS only problem was that people simply didn't trust it.
Advantages:
No backend required (or dedicated server)
Fast and reliable
Hook scripts are supported
NTFS permissions are used
Easy to understand, easy to support, easy to manage
Disadvantages:
Not so easy access from outside your network (VPN)
Permissions only on repository-level (Read, Read/Write)
Hook scripts are running under current user credentials (which is sometimes advantage, sometimes disadvantage)
Martin