Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Let's say I let my friend "Stuart" have an account on my VPS with very limited privileges because he asked very nicely. Since Stuart isn't so bright, he accidentally posts his password in an IRC chatroom, and now everyone and his/her grandma can ssh into his account. My question is, in the hands of an experienced hacker, what kind of damage can be done to the system?
Could someone just write a simple C program to intentionally manipulate a buffer overflow in strcpy and serve up a root shell for full control of the system, or are there built-in protections against that in the OS?
There are any number of attackers an attacker with local privileges could perform including but not limited to:
Fork Bombs
Accessing services bound to 127.0.0.1
Using your server as a proxy for malicious attacks
Serving malicious files from your server
Local exploits
Information Leakage
Mail relaying
etc
The attack you describe however is not possible as the file would have to have to be owned by root and have the setuid or setgid bits set.
Once someone has access to the machine, instead of needing a remote exploit, they only need to escalate privileges to have root access.
Remote exploits require having an external publicly-accessible vulnerable service. There shouldn't be any of those running on a standard VPS, assuming that it's being well maintained.
Once a remote user can authenticate, they can execute any code that's on the machine, or bring in more. If there is a bug in the kernel, or in any program that has setuid to root, they can use that to escalate their privileges to a user who has more power - like root.
So a simple buffer overflow in a custom program written by the attacker isn't your concern - that shouldn't allow them to have any extra power. What you're concerned about is a bug in the system that the attacker now has the access, and so, the ability, to exploit.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am new to web development, and particularly for the back end, I was wondering what are the first basic precautions should be implemented to ensure cybersecurity to avoid any exploits which could leak user data or credential for example.
First of all make sure you are following the CIA model:
Confidentiality: Refers to access control of information to ensure that those who should not have access are kept out. This can be done with passwords, usernames, and other access control components.
Integrity: Ensures that the information end-users receive is accurate and unaltered by anyone other than the site owner. This is often done with encryption, such as Secure Socket Layer (SSL) certificates which ensure that data in transit is encrypted.
Availability: Ensures information can be accessed when needed.
Some other tips would be :
Use SSL certificate.
Take precautions when accepting file uploads through your site.(Incase if you have)
Use CSP (To prevent against Cross-site scripting)
Set permissions that controls who can read, write, and execute any given file or folder of your website.
Limit Login Attempts and temporarily lock out IP Addresses that make several failed attempts to get inside.
Keep scripts up-to-date.
Maintain multilayer security and keep backup.
And please take care of your Database, how you create and link it.
Lastly, show the beta version of your website to someone with good experience to look for any loopholes before your website goes live.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Reading articles like this one makes me wonder, is this a real world problem?
Say that someone (or something) wanted to crack my FTP login. The cracking software can deliver so and so many million guesses per second, but the server that is under attack can't possibly serve up that many "incorrect password" replies. In what kind of scenario do I need to worry about brute forcing?
If your database of password hashes is compromised, and they can try to crack it on their local machine
The point of these devices is to brute-force a password hash (from a leaked database).
No server is involved.
If they were trying to crack your FTP login, they wouldn't need lots of GPUs; they would simply need lots of network bandwidth.
The article says this, "Tools like Gosney’s GPU cluster aren’t suited for an “online” attack scenario against a live system. Rather, they’re used in “offline” attacks against collections of leaked or stolen passwords that were stored in encrypted form, Thorsheim said."
The article you linked already gives the answer to your question:
Tools like Gosney’s GPU cluster aren’t suited for an “online” attack scenario against a live system. Rather, they’re used in “offline” attacks against collections of leaked or stolen passwords that were stored in encrypted form, Thorsheim said. In that situation, attackers aren’t limited to a set number of password attempts – hardware and software limitations are all that matter.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I recently started looking at my auth-logs and surprisingly found bots from china trying to bruteforce their way in this (didnt try hard). I went all about changing numerous things that bots would never check, and made harder to bruteforce.
My question is:
I am trying to find a list of all users that can log in to my server via SSH. I know that /etc/passwd has a list of all users, but I don't know if any of them (except for 1) can be logged in.
My goal is to only have 1 user that can be logged in, and having that user have a real strong password.
Read man sshd_config for more details, but you can use the AllowUsers directive in /etc/ssh/sshd_config to limit the set of users who can login.
e.g.
AllowUsers boris
would mean that only the boris user could login via ssh.
Any user with a valid shell in /etc/passwd can potentially login. If you want to improve security, set up SSH with public-key authentication (there is lots of info on the web on doing this), install a public key in one user's ~/.ssh/authorized_keys file, and disable password-based authentication. This will prevent anybody except that one user from logging in, and will require that the user have in their possession the matching private key. Make sure the private key has a decent passphrase.
To prevent bots from trying to get in, run SSH on a port other than 22 (i.e. 3456). This doesn't improve security but prevents script-kiddies and bots from cluttering up your logs with failed attempts.
Any user whose login shell setting in /etc/passwd is an interactive shell can login. I don't think there's a totally reliable way to tell if a program is an interactive shell; checking whether it's in /etc/shells is probably as good as you can get.
Other users can also login, but the program they run should not allow them to get much access to the system. And users that aren't allowed to login at all should have /etc/false as their shell -- this will just log them out immediately.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm involved in the task of creating a root filesystem for Beagleebone running Linux. Usually the filesystem is generated and configured with a single root user (for example with buildroot), which is the only user of the system. Does it mean that all the commands and applications are executed with root privileges (being that the only user of the system)? Isn't this a security issue? Would it be better to create a non-root user? What is the usual practice?
In a linux system there are many system users apart from root which may be used for specific purposes. If your embedded system is some kind of autonomous system (eg. a robot) and doesn't expose any services on a network or some kind of direct physical access to users, there's not so much to worry about. If it does then you should just check if the softwares in question really require root access or not. You can always create less privileged users to run them on your behalf, if they are not really made considering all security implications.
The Raspbery Pi Debian comes with root + a pi user "pre-installed", who has sudo rights. Modern Unix systems does not enable "native root login", so extra user is a need.
If your device is somehow connected to internet, I mean, there is a chance to reach it from internet or a wider LAN, you should follow some security guide lines (e.g. no root login). But if not, say, your device has no LAN access at all, don't worry such things.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 8 years ago.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
This question does not appear to be about programming within the scope defined in the help center.
Improve this question
In teaching a web development class, I had students SFTP into a sandbox server I created for them so they could work with PHP. One of the students (adult, not traditional student age - bit of a luddite), was hesitant to use it because in their head "now we're going to connect to a remote server" equated to the possibility of someone having access to the files and information on their computer.
How would you respond to this question? It's not something I've ever thought about, but yet I didn't know enough about the FTP protocol itself to come up with a strong explanation of why.
I would point out that while there are risks from connecting to FTP servers, they do not include the ability for the FTP server to have access to your machine.
The real risks are that an attacker could sniff usernames and passwords and take, amend or delete the files on the server
This could, of course lead to a valid attack vector as follows:
Attacker gains access to FTP server
Attacker compromises a file on the server, replacing it with one including malware
You download the file, expecting it to be valid
You run the file, and your machine is compromised
And that compromise could be anything from a bot-net client, a keylogging trojan etc.
You can of course minimise the risks by:
Using SFTP - which provides for encryption, and stronger authentication
Provide hashes of the files you want downloaded, so they can be validated
Virus scan all downloaded files
Only allow execution of downloaded files in a sandbox
In order for anyone to retrieve files from a clients computer, the client must have opened the SFTP port in his/her firewall as well as allow access to his/her fiels via sftp. These settings default to "denying access" so his/her files cannot possible be compromised. When he SFTP's into a server, the server has allowed him to access files on it. So although he/she is connecting to the server and retrieving files, there really is no way for the server to access any files from his/her computer because the computer will deny access. Hope that helps!
Every time you visit a website, you are "connecting to a remote server". Every time you check your email, you are "connecting to a remote server". Skype? "Connecting to a remote server." In fact, if "connecting to a remote server" worries you then there is literally no point in having an internet connection. FTP seems to scare some people because of the transferring files part, but in truth it's not fundamentally different to any other protocol and certainly not more of a security risk. Back in the day "connecting to a remote server" was an expensive operation that was to be handled with caution but the technology world moves quickly and now it is a normal and mundane exercise.
That is what I would say to him.
Make him think of FTP as something else he may already know, for example, an USB stick.... you are compromising only the files you are putting there; in particular if you are giving it to somebody you don't trust.