User access & security - Security

This is a discussion on User access & security - 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 ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: User access & security

  1. 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

  2. Re: User access & security

    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

  3. Re: User access & security

    Mark :
    > 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.

  4. Re: User access & security

    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

  5. Re: User access & security

    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


  6. Re: User access & security

    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 ****ed 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, ... )

  7. Re: User access & security

    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 ****ed 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


  8. Re: User access & security

    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 ****ed 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

  9. Re: User access & security

    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

  10. Re: User access & security

    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 ****ed 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
    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

  11. Re: User access & security

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

    >Moe Trin wrote:


    >> 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 ?


    Unfortunately, no. Today is only the fifth and I've already seen a
    fscking idiot posting to another *nix newsgroup that he did a

    chmod -R 777 /

    but it didn't fix his problem, and now he can't log in. Wonder why ;-)

    >my default umask is 0077 btw


    Depends on your threat model. Who has access to the file system, and
    what have you got in there. The _traditional_ value that a lot of
    systems still use by default is 022 (recall the execute bit is never
    set by default on file _creation_ though it may be _copied_ if using
    '/bin/cp' to copy a file).

    >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


    Where is the file, and what is it being used for? I really do expect
    that files in /bin/, /sbin/, /usr/bin/, /usr/sbin/, /usr/local/bin/and
    /usr/local/sbin/ would be 755 - or why else is the file placed in those
    directories? On the other hand, files in ~/bin/ are usually 700
    though if others don't have any permissions to the directory, that
    really isn't an absolute requirement.

    >ok i forgot about login


    There are usually a number of files on a system that have to be S[GU]ID
    ranging from /bin/login, /bin/passwd on to /bin/su and possibly your
    mail server or mail downloading tool.

    find / -perm +04000 -exec ls -ld {} \; 2> /dev/null > /tmp/SUID.files
    find / -perm +02000 -exec ls -ld {} \; 2> /dev/null > /tmp/SGID.files

    >but still eg: i only allow a certain group su or sudo


    And the permissions on /usr/bin/newgrp?

    >> 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.


    >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


    Probably is a legit account, but it's _probably_ being used for purposes
    that the system administrator wasn't intending. That remains an exploit.

    Old guy

+ Reply to Thread