User access & security

This is a question related to my next post.

If there is a user with non-root access to their account, we are
dependent on their having a good password to ward off too much nasty
activity.

I am told that it is fairly easy with user access to install a rootkit
of some sort and totally compromise the system.

Now it seems to me that if this user is careless with this password,
then the whole server is at risk. How true is this? Doesn't this weaken
Linux to such an extent that any user access at all is guaranteed to
bring down the server.

If that is the case, what do ISPs do, with their thousands of ordinary
users? What does anybody do?

I ask this because I have inadvertently left an account open with a
trivial password which somebody has stumbled into. (It has since been
closed, but the question remains).

Thanks,

Mark

On Mon, 01 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
<4700eb0f$0$14825$afc38c87@news.optusnet.com.au> , Mark wrote:

>If there is a user with non-root access to their account, we are
>dependent on their having a good password to ward off too much nasty
>activity.

You are also dependent on what _network_ access you grant. I've got a
system on the table behind me that has an empty password ("") for the
three user accounts. The only ones who can access that are those who
are physically present, because the box has no network connection. I've
another system (a workstation) that has trivial account names and
passwords, but again, you can't hack into it because while it _does_
have a network connection, it's not running _any_ services. The command
'netstat -anptu' returns only the column headers, because nothing is
listening to the network.

>I am told that it is fairly easy with user access to install a rootkit
>of some sort and totally compromise the system.

No details of distribution or version. Are you keeping the thing up to
date with all applicable errata, or what?

>Now it seems to me that if this user is careless with this password,
>then the whole server is at risk. How true is this?

Depends on the access you've granted.

>Doesn't this weaken Linux to such an extent that any user access at
>all is guaranteed to bring down the server.

Running Linux (or any other operating system) does not create security.
There is no silver bullet, Security is a system - a series of moves
made by a smart administrator that limits the possibility of damage.

>If that is the case, what do ISPs do, with their thousands of ordinary
>users? What does anybody do?

For starters, they don't allow unlimited access to every service that
can be installed on a system.

>I ask this because I have inadvertently left an account open with a
>trivial password which somebody has stumbled into. (It has since been
>closed, but the question remains).

They didn't stumble onto the account - they were invited in. They needed
to first _find_ the system (as of the middle of last month, there were
2,544,183,372 IPv4 addresses in use on the Internet, 409,770,752 in the
Asia-Pacific region, 32,594,688 of those in Oz), find the port you were
offering service over (telnet? ssh? who-knows), find the account name,
only then find the right password. Then the skript kiddiez have to
figure out which package (.deb, .rpm, .tar) is suitable... get the
picture that you are stretching the odds? On the other hand, if one of
your users installed this shiny thing they found on some nifty website
to "improve their Internet experience"...

Remember, the vulnerability being exploited here is the user, not the OS.

I've seen people joke - and I must emphasize, this is a JOKE - that you
could send round an email message that says "for great sex, email this
message to everyone in your address book, then format your hard drive
and burn all your backups". Possibly a double-digit percentage of users
will follow those instructions.

Old guy

Mark <mark@comparity.not.example.net>:
> This is a question related to my next post.

Caveat: haven't read it yet.

> If there is a user with non-root access to their account, we are
> dependent on their having a good password to ward off too much nasty
> activity.
>
> I am told that it is fairly easy with user access to install a rootkit
> of some sort and totally compromise the system.

No. User access can affect User's acct., and that's all, assuming of
course that that user doesn't have access to root owned stuff.

> Now it seems to me that if this user is careless with this password,
> then the whole server is at risk. How true is this? Doesn't this weaken

IFF there are easily compromisable services running on the box, yes
mere users can do irreparrable damage. Huh. "aptitude update &&
aptitude upgrade", aka, "Install updated/fixed software". Do it often.

Better, don't run software you can't protect, or at least don't expose
it. Firewall and proxy and ... any Windows machine. Don't run stupid
services on Internet facing interfaces without considering their
capabilities, good and bad.

> If that is the case, what do ISPs do, with their thousands of ordinary
> users? What does anybody do?

Run lots of traffic monitoring software. Scrutinize output. Cross
fingers.

> I ask this because I have inadvertently left an account open with a

!@#$ happens. Clean up.

This can happen using any OS. This has nothing to do with Linux.


--
Any technology distinguishable from magic is insufficiently advanced.
(*) http://blinkynet.net/comp/uip5.html Linux Counter #80292
- - http://www.faqs.org/rfcs/rfc1855.html Please, don't Cc: me.

Mark wrote:
> This is a question related to my next post.
>
> If there is a user with non-root access to their account, we are
> dependent on their having a good password to ward off too much nasty
> activity.
>
> I am told that it is fairly easy with user access to install a rootkit
> of some sort and totally compromise the system.
>
> Now it seems to me that if this user is careless with this password,
> then the whole server is at risk. How true is this? Doesn't this weaken
> Linux to such an extent that any user access at all is guaranteed to
> bring down the server.
>
> If that is the case, what do ISPs do, with their thousands of ordinary
> users? What does anybody do?
>
> I ask this because I have inadvertently left an account open with a
> trivial password which somebody has stumbled into. (It has since been
> closed, but the question remains).
>
> Thanks,
>
> Mark

Thanks for your responses. I'll have to mull over them for a bit ...

Mark

Mark wrote:
> This is a question related to my next post.
>
> If there is a user with non-root access to their account, we are
> dependent on their having a good password to ward off too much nasty
> activity.

Ok... easy to ensure and pretty secure.

>
> I am told that it is fairly easy with user access to install a rootkit
> of some sort and totally compromise the system.

No. It is not easy.. at least it's not supposed to be easy.

>
> Now it seems to me that if this user is careless with this password,
> then the whole server is at risk. How true is this? Doesn't this weaken
> Linux to such an extent that any user access at all is guaranteed to
> bring down the server.

A user account can cause issues... especially if there are no limits
on the account... but compromise? Again, much, much more difficult.

>
> If that is the case, what do ISPs do, with their thousands of ordinary
> users? What does anybody do?

Restrict them so that they can't adversely affect the whole machine
with regards to resource consumption. Even if somebody else logs
in... it's not different than the actual user as far as the
ISP is concerned.

>
> I ask this because I have inadvertently left an account open with a
> trivial password which somebody has stumbled into. (It has since been
> closed, but the question remains).

My guess... is that unless the box was not setup well, that everything
is ok. The only damage would be to your infrastructure, files and
possibly your reputation.

>
> Thanks,
>
> Mark

Mark wrote:
> This is a question related to my next post.
>
> If there is a user with non-root access to their account, we are
> dependent on their having a good password to ward off too much nasty
> activity.
>
> I am told that it is fairly easy with user access to install a rootkit
> of some sort and totally compromise the system.
>
fairly easy ? iirc a rootkit is something that replaces valuable system
tools
like ps, lsof, top, ipconfig, ip, ...
for this to be succesfull the user has to have access to the files in
question
this can be accomplished in a number of ways i know of

a) you have fucked up your permissions and allow other to write to
binaries owned by root
b) the user account has unlimited access to or has enough access to sudo
to do the same as mentionned in a)
c) the user is rather skilled or is a script kiddie who knows where to get
good tools and uses exploits in suid programs to execute the commands
required to install rootkit (again you'll have to decide what you want
your users to be able
to do (permissions permissions permissions)). normal users have no
business using
suid or sgid programs
d) the user is extremely good so after not finding the necessary
sudo/sgid exploits
he will try to attack running services that run as root: apache, smb,
.... to get total access to the machine
lately most attacks against webservers seem to target vulnerable php,
perl script and spawn a custom script,
which is located at some anonymous or compromised server, which launches
a reverse (root) shell so ...
it's a good idea to disallow the use of download tools like wget, curl
to your users and your apache server

> Now it seems to me that if this user is careless with this password,
> then the whole server is at risk. How true is this? Doesn't this weaken
> Linux to such an extent that any user access at all is guaranteed to
> bring down the server.
>
> If that is the case, what do ISPs do, with their thousands of ordinary
> users? What does anybody do?
>
> I ask this because I have inadvertently left an account open with a
> trivial password which somebody has stumbled into. (It has since been
> closed, but the question remains).

Assume you have been compromised and start from scratch
it's better to be safe than sorry

> Thanks,
>
> Mark


This is all i can come up with for now.
I'm not a security expert but i do like to think
i have educated myself enough, and will educate myself even further, to
give some valuable advice
also remember 'security is a process not a state' and to keep up-to-date
(whether it's about installed software
or ... new attack vectors, tools, information, ... )

On Thu, 04 Oct 2007 00:57:54 +0200:

> Mark wrote:
>> This is a question related to my next post.
>>
>> If there is a user with non-root access to their account, we are
>> dependent on their having a good password to ward off too much nasty
>> activity.
>>
>> I am told that it is fairly easy with user access to install a rootkit
>> of some sort and totally compromise the system.
>>
> fairly easy ? iirc a rootkit is something that replaces valuable system
> tools
> like ps, lsof, top, ipconfig, ip, ... for this to be succesfull the user
> has to have access to the files in question
> this can be accomplished in a number of ways i know of
>
> a) you have fucked up your permissions and allow other to write to
> binaries owned by root
> b) the user account has unlimited access to or has enough access to sudo
> to do the same as mentionned in a)
> c) the user is rather skilled or is a script kiddie who knows where to
> get good tools and uses exploits in suid programs to execute the
> commands required to install rootkit (again you'll have to decide what
> you want your users to be able
> to do (permissions permissions permissions)). normal users have no
> business using
> suid or sgid programs
> d) the user is extremely good so after not finding the necessary
> sudo/sgid exploits
> he will try to attack running services that run as root: apache, smb,
> ... to get total access to the machine lately most attacks against
> webservers seem to target vulnerable php, perl script and spawn a custom
> script, which is located at some anonymous or compromised server, which
> launches a reverse (root) shell so ...
> it's a good idea to disallow the use of download tools like wget, curl
> to your users and your apache server
>
>> Now it seems to me that if this user is careless with this password,
>> then the whole server is at risk. How true is this? Doesn't this weaken
>> Linux to such an extent that any user access at all is guaranteed to
>> bring down the server.
>>
>> If that is the case, what do ISPs do, with their thousands of ordinary
>> users? What does anybody do?
>>
>> I ask this because I have inadvertently left an account open with a
>> trivial password which somebody has stumbled into. (It has since been
>> closed, but the question remains).
>
> Assume you have been compromised and start from scratch it's better to
> be safe than sorry
>
>> Thanks,
>>
>> Mark
>
>
> This is all i can come up with for now. I'm not a security expert but i
> do like to think i have educated myself enough, and will educate myself
> even further, to give some valuable advice
> also remember 'security is a process not a state' and to keep up-to-date
> (whether it's about installed software or ... new attack vectors, tools,
> information, ... )

Thanks for the insight.

I'm concerned about the "start from scratch" advice. I've experimented
with the concept of taking an otherwise good system -- and one where
everything is "just like I want it to be" and then reloaded the ubuntu
system from a DVD which I had just burned with the most current ISO from
the Deb site. In each case, the box lost just about all of the settings
I had made to it and to really make things a pain, I got the "$HOME is
being ignored ... change permissions to 644..." so that user settings
were NOT preserved. This even through the entire home/user directory was
dd moved from the backup hd.

I have also copied a dd image back and forth to test a complete system
restore and found that there is ALWAYS some glitch which prevents the
system from going back to where it was, only with a clean OS.

Sorry to carry on like this, but I have just not had good luck with full
system restores over the past 10 years of using Linux. If it is any
consolation to me, none of our shop's Windows machines (which are long
gone since we switched to only Linux) nor the two BeOS machines were any
different. There is "always" something ...

Dave



--
Posted via a free Usenet account from http://www.teranews.com

On Thu, 04 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
<47041e72$0$22321$ba620e4c@news.skynet.be>, goarilla wrote:

>Mark wrote:

>> I am told that it is fairly easy with user access to install a
>> rootkit of some sort and totally compromise the system.

>fairly easy ? iirc a rootkit is something that replaces valuable
>system tools like ps, lsof, top, ipconfig, ip, ...
>for this to be succesfull the user has to have access to the files in
>question
>this can be accomplished in a number of ways i know of

all of which require the attacker to have access to the system.

>a) you have fucked up your permissions and allow other to write to
>binaries owned by root

I'm amazed at the number of total fscking IDIOTS who think that
'chmod 777 *' is the way to fix a permission problem. Luckily, the
really dumb ones do that recursively from / and really screw up
access to their systems, give up, and go back to running windoze95
because it doesn't have these problems.

>b) the user account has unlimited access to or has enough access to
>sudo to do the same as mentionned in a)

or the root account has no password because it's to hard to type the
password all the time.

>c) the user is rather skilled or is a script kiddie who knows where
>to get good tools and uses exploits in suid programs to execute the
>commands required to install rootkit (again you'll have to decide what
>you want your users to be able to do (permissions permissions
>permissions)).

This usually occurs because the administrator doesn't maintain the
system or understand what they are doing in the first place. These are
the same people who install everything on the 7 CD (or two DVDs) set
because they think they might find it useful.

>normal users have no business using suid or sgid programs

[compton ~]$ ls -l /bin/login
-rws--x--x 1 root root 16314 Mar 13 2007 /bin/login
[compton ~]$

Yeah! ;-)

>d) the user is extremely good so after not finding the necessary
>sudo/sgid exploits he will try to attack running services that run
>as root: apache, smb, ... to get total access to the machine

Again, why does an attacker have access to vulnerable services? A
publicly visible server should be running only those services
needed to do it's job.

>lately most attacks against webservers seem to target vulnerable php,

It is possible to write PHP that is more bullet resistant. Unfortunately
most administrators merely copy some piece of crap that they found in a
garbage can, and make NO effort to understand what it's doing, and the
holes that it opens. "It works, and doesn't crash the browser or the
server - must be OK!"

>perl script and spawn a custom script, which is located at some
>anonymous or compromised server, which launches a reverse (root) shell
>so ... it's a good idea to disallow the use of download tools like
>wget, curl to your users and your apache server

You did notice that what was being exploited here was an FTP server
with a well-known username and password that was set up to allow
uploading of files.

Old guy

On 04 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
<4704dce6$0$26400$88260bb3@free.teranews.com>, CWO4 Dave Mann wrote:

>I'm concerned about the "start from scratch" advice. I've experimented
>with the concept of taking an otherwise good system -- and one where
>everything is "just like I want it to be" and then reloaded the ubuntu
>system from a DVD which I had just burned with the most current ISO from
>the Deb site. In each case, the box lost just about all of the settings
>I had made to it and to really make things a pain, I got the "$HOME is
>being ignored ... change permissions to 644..." so that user settings
>were NOT preserved.

Well, yeah - you reinstalled the system, and things are now in the
default mode. Our backups don't restore to the distribution default,
but rather to the latest company approved configuration that our admins
spent weeks setting up (and maybe years refining it to the current form).
Then we take the customized data that may have been on this system and
(after vetting it if there was a chance of compromise) restore that to
bring the system back to the known good setup.

Now, what the permissions in home look like (some default to 644, other
to 640 - I don't know what you had, and what security nanny may be
running to screw things up otherwise) what application are you running
that is ignoring permissions on a restore?

>This even through the entire home/user directory was dd moved from the
>backup hd.

Do you literally mean '/bin/dd if=/source/of/backup of=/home/user'?
That's not the way I'd be doing it.

>I have also copied a dd image back and forth to test a complete system
>restore and found that there is ALWAYS some glitch which prevents the
>system from going back to where it was, only with a clean OS.

257722 Apr 12 2006 Linux-Complete-Backup-and-Recovery-HOWTO

although this subject gets lots of coverage in popular magazines.
Obviously something isn't right, but I don't know enough about what
you may be doing to say why. Some of the problems may be due to
inappropriate tools/helpers (or let's just say stuff that isn't doing
the job the way you expect it to be done). Example, changing ownership
of files invariably removes S[UG]ID permissions - that's a security
feature.

>Sorry to carry on like this, but I have just not had good luck with full
>system restores over the past 10 years of using Linux. If it is any
>consolation to me, none of our shop's Windows machines (which are long
>gone since we switched to only Linux) nor the two BeOS machines were any
>different. There is "always" something ...

"Dave, I can't let you do that..." ;-)

Old guy

Moe Trin wrote:
> On Thu, 04 Oct 2007, in the Usenet newsgroup comp.os.linux.security, in article
> <47041e72$0$22321$ba620e4c@news.skynet.be>, goarilla wrote:
>
>> Mark wrote:
>
>>> I am told that it is fairly easy with user access to install a
>>> rootkit of some sort and totally compromise the system.
>
>> fairly easy ? iirc a rootkit is something that replaces valuable
>> system tools like ps, lsof, top, ipconfig, ip, ...
>> for this to be succesfull the user has to have access to the files in
>> question
>> this can be accomplished in a number of ways i know of
>
> all of which require the attacker to have access to the system.
>
>> a) you have fucked up your permissions and allow other to write to
>> binaries owned by root
>
> I'm amazed at the number of total fscking IDIOTS who think that
> 'chmod 777 *' is the way to fix a permission problem. Luckily, the
> really dumb ones do that recursively from / and really screw up
> access to their systems, give up, and go back to running windoze95
> because it doesn't have these problems.
>

that must be a joke right ?
my default umask is 0077 btw
but one really does see that a lot even in howto's
hosted on so called respectable OSS sites :
eg: now we make the file executable:
chmod a+x or chmod 755 are very common in this case

>> b) the user account has unlimited access to or has enough access to
>> sudo to do the same as mentionned in a)
>
> or the root account has no password because it's to hard to type the
> password all the time.
>
>> c) the user is rather skilled or is a script kiddie who knows where
>> to get good tools and uses exploits in suid programs to execute the
>> commands required to install rootkit (again you'll have to decide what
>> you want your users to be able to do (permissions permissions
>> permissions)).
>
> This usually occurs because the administrator doesn't maintain the
> system or understand what they are doing in the first place. These are
> the same people who install everything on the 7 CD (or two DVDs) set
> because they think they might find it useful.
>
>> normal users have no business using suid or sgid programs
>
> [compton ~]$ ls -l /bin/login
> -rws--x--x 1 root root 16314 Mar 13 2007 /bin/login
> [compton ~]$
>
> Yeah! ;-)
>

ok i forgot about login :D
but still eg: i only allow a certain group su or sudo

>> d) the user is extremely good so after not finding the necessary
>> sudo/sgid exploits he will try to attack running services that run
>> as root: apache, smb, ... to get total access to the machine
>
> Again, why does an attacker have access to vulnerable services? A
> publicly visible server should be running only those services
> needed to do it's job.
>
>> lately most attacks against webservers seem to target vulnerable php,
>
> It is possible to write PHP that is more bullet resistant. Unfortunately
> most administrators merely copy some piece of crap that they found in a
> garbage can, and make NO effort to understand what it's doing, and the
> holes that it opens. "It works, and doesn't crash the browser or the
> server - must be OK!"
>
>> perl script and spawn a custom script, which is located at some
>> anonymous or compromised server, which launches a reverse (root) shell
>> so ... it's a good idea to disallow the use of download tools like
>> wget, curl to your users and your apache server
>
> You did notice that what was being exploited here was an FTP server
> with a well-known username and password that was set up to allow
> uploading of files.
>
> Old guy
i was just giving a common scenario !
jeeeeez, but still i wouldn't call that exploitation
there was no indication the FTP server was compromised
it could just be a legit account

Young Guy :D