Professional Web Applications Themes

attack question - Sun Solaris

It seems someone attacked our sun server:   PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 26750 root 976K 784K run 0 0 1:19.46 79% dd/1   root 26750 26693 73 13:27:41 ? 79:50 dd if=/dev/zero of=./AR3 bs=1 count=   root 26750 26693 79 13:27:41 ? 80:05 dd if=/dev/zero of=./AR3 bs=1 count= root 26693 26690 0 13:27:40 ? 0:00 /bin/ksh ./sz /bin/ls bin/ls we aren't running those commands. so any idea how we can prevent that, also any idea to see what happend here. Thanks for any help. Rob...

  1. #1

    Default attack question

    It seems someone attacked our sun server:


     

    PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP

    26750 root 976K 784K run 0 0 1:19.46 79% dd/1


     

    root 26750 26693 73 13:27:41 ? 79:50 dd if=/dev/zero of=./AR3
    bs=1 count=


     

    root 26750 26693 79 13:27:41 ? 80:05 dd if=/dev/zero of=./AR3
    bs=1 count=

    root 26693 26690 0 13:27:40 ? 0:00 /bin/ksh ./sz /bin/ls bin/ls

    we aren't running those commands. so any idea how we can prevent that, also
    any idea to see what happend here.

    Thanks for any help.

    Rob








    Rob Guest

  2. #2

    Default Re: attack question

    "Rob" <com> writes:
     
    >
    > PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
    >
    > 26750 root 976K 784K run 0 0 1:19.46 79% dd/1[/ref]

    Try

    ptree 26750 # /usr/proc/bin/ptree if not in /usr/bin
    ptree pid-of-grandestparent that isn't "init"

    which should reveal all the processes in the group.
     


    Try

    pwdx 26750

    to get the working directory, then sniff around that part of the
    filesystem and try and find out when the attack started. Look at
    (parent) directory timestamps rather than files as they're generally
    less consistently forged.

    Then look through your logs for everything you can think of for what
    happened at the time of breakin. Then search the entire filesystem
    for other changes around that time.

    A quick search on google reveals (./AR3):

    www.digitaloffense.net/worms/1ion/ whitehats/lion1/lib/lib/sz

    where the script in question is helpfully padding out the new copy of
    /bin/ls to be as big as the original. If I may quote the author of
    the resizing code:

    if test $ORIGSIZE -lt $TRSIZE; then
    echo "Trojan is bigger than real file, go code better trojans, IDIOT"
    exit 0
    fi

    Sound advice.

    Then have a root around through google looking for the particular
    rootkit that you've been hit with. I saw a hint of something when
    looking for "./sz /bin/ls /bin/ls"

    Then marvel at how much effort people go to to cover their tracks:
    login, ps, netstat etc etc.

    Finally, cry and then re-install your box from CD/JumpStart taking
    note of all the good advice offered on securing your system. Trust
    absolutely nothing on the box as you don't know that the script
    kiddie hasn't extended the freely available one.

    Cheers,

    Ian
    Ian Guest

  3. #3

    Default Re: attack question


    "Ian Fitchet" <LESS-SPAM.com> wrote in message
    news:home.lunanbay.com... 
    > >
    > > PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
    > >
    > > 26750 root 976K 784K run 0 0 1:19.46 79% dd/1[/ref]
    >
    > Try
    >
    > ptree 26750 # /usr/proc/bin/ptree if not in /usr/bin
    > ptree pid-of-grandestparent that isn't "init"
    >
    > which should reveal all the processes in the group.
    > [/ref]
    of=./AR3 
    >
    >
    > Try
    >
    > pwdx 26750
    >
    > to get the working directory, then sniff around that part of the
    > filesystem and try and find out when the attack started. Look at
    > (parent) directory timestamps rather than files as they're generally
    > less consistently forged.
    >
    > Then look through your logs for everything you can think of for what
    > happened at the time of breakin. Then search the entire filesystem
    > for other changes around that time.
    >
    > A quick search on google reveals (./AR3):
    >
    > www.digitaloffense.net/worms/1ion/ whitehats/lion1/lib/lib/sz
    >
    > where the script in question is helpfully padding out the new copy of
    > /bin/ls to be as big as the original. If I may quote the author of
    > the resizing code:
    >
    > if test $ORIGSIZE -lt $TRSIZE; then
    > echo "Trojan is bigger than real file, go code better trojans, IDIOT"
    > exit 0
    > fi
    >
    > Sound advice.
    >
    > Then have a root around through google looking for the particular
    > rootkit that you've been hit with. I saw a hint of something when
    > looking for "./sz /bin/ls /bin/ls"
    >
    > Then marvel at how much effort people go to to cover their tracks:
    > login, ps, netstat etc etc.
    >
    > Finally, cry and then re-install your box from CD/JumpStart taking
    > note of all the good advice offered on securing your system. Trust
    > absolutely nothing on the box as you don't know that the script
    > kiddie hasn't extended the freely available one.
    >
    > Cheers,
    >
    > Ian[/ref]

    Thanks-But even I killed that process I still can not Telnet to this server,
    SSH works.
    Any idea?
    Rob


    Rob Guest

  4. #4

    Default Re: attack question

    Rob <com> wrote: 

    Seems like you missed the most important part of the reply you got:
     [/ref]

    mp.
    --
    Systems Administrator | Institute for Software Science | Univ. of Vienna
    Martin Guest

  5. #5

    Default Re: attack question

    "Rob" <com> writes:
     

    I should think that they've compromised your sshd and each time you
    log in they capture your password. When you su they capture root's
    password, etc. etc..

    You may think that capturing your or root's passwords is
    insignificant because they are already root on your box. The point
    is though that your password is likely to be similar if not the same
    on all your other boxes and root's is likely to be a variant on your
    other boxes.

    Now that you've given them a head start on cracking root's password
    on all your other boxes (who's names they can trivially retrieve from
    your logfiles) I suggest that not only do you start re-installing
    this box but you look very carefully at all your other boxes to see
    what else they've been up to.

    Cheers,

    Ian

    Ian Guest

  6. #6

    Default Re: attack question


    "Ian Fitchet" <LESS-SPAM.com> wrote in message
    news:home.lunanbay.com... [/ref]
    server, 
    >
    > I should think that they've compromised your sshd and each time you
    > log in they capture your password. When you su they capture root's
    > password, etc. etc..
    >
    > You may think that capturing your or root's passwords is
    > insignificant because they are already root on your box. The point
    > is though that your password is likely to be similar if not the same
    > on all your other boxes and root's is likely to be a variant on your
    > other boxes.
    >
    > Now that you've given them a head start on cracking root's password
    > on all your other boxes (who's names they can trivially retrieve from
    > your logfiles) I suggest that not only do you start re-installing
    > this box but you look very carefully at all your other boxes to see
    > what else they've been up to.
    >
    > Cheers,
    >
    > Ian
    >[/ref]

    Thanks- this is the only Unix-based machine in our environment, actually I
    was thinking about restoring from tape backup, and change root and other
    passwords.

    is there any way we can find out the exact time they got in? is there any
    tools I can use to get a report of all system config then use them in case I
    want to start from scratch.

    Rob


    Rob Guest

  7. #7

    Default Re: attack question

    "Rob" <com> writes:
     

    Don't bother restoring from backup unless you're very sure when you
    were broken into. If you were broken into last weekend and you
    restore from last night's backups. Well, ...

    Don't change root's password until you're sure you've a clean machine
    as they will have compromised passwd as well.

    As a broad rule of thumb for when you've been hacked:

    1) if you see them on your box as root,
    a) trust nothing
    b) try to find out when you were attacked for the sake of your backups
    c) re-install from CD

    2) if you see them as non-root
    a) trust nothing
    b) try to find out when you were attacked for the sake of your backups
    c) re-install from CD UNLESS YOU REALLY KNOW WHAT YOU'RE DOING


    If you've been running tripwire or some other checksum'ing process
    over your filesystem and know when you were compromised you *might*
    be able to recover the box without a re-install. If you had a spare
    box at the same patchlevel you might be able to compare it (assuming
    they haven't compromised ls, sum, find etc.). As you noticed, they'd
    compromised ls so the chances are that you won't see many of the
    changes they've made -- hence looking at directory timestamps.

    It all sounds a bit harsh but in summary you don't know what they've
    done to your box. They will have changed some programs to
    deliberately lie about their own existence. You simply can't trust
    your eyes anymore.

    If you have a particularly paranoid mind you could even believe that
    they would have compromised ftpd so that you can't even copy a new
    version of ls onto the box as they'll spot it and immediately
    substitute the hacked one for it.
     

    System config? In terms of patch levels and packages? Do you want
    to trust the output of any command on that box?

    As to the breakin time, go back to my first suggestions (ptree, pwdx)
    and see what you can. Taking it all with a pinch of salt.

    As they say, you're ed. The rest of us have all been ed in
    turn. Now's the time to accept your loss, re-install the box and
    move on.

    Cheers,

    Ian


    Ian Guest

  8. #8

    Default Re: attack question


    "Ian Fitchet" <LESS-SPAM.com> wrote in message
    news:home.lunanbay.com... [/ref]

    >
    > Don't bother restoring from backup unless you're very sure when you
    > were broken into. If you were broken into last weekend and you
    > restore from last night's backups. Well, ...
    >
    > Don't change root's password until you're sure you've a clean machine
    > as they will have compromised passwd as well.
    >
    > As a broad rule of thumb for when you've been hacked:
    >
    > 1) if you see them on your box as root,
    > a) trust nothing
    > b) try to find out when you were attacked for the sake of your backups
    > c) re-install from CD
    >
    > 2) if you see them as non-root
    > a) trust nothing
    > b) try to find out when you were attacked for the sake of your backups
    > c) re-install from CD UNLESS YOU REALLY KNOW WHAT YOU'RE DOING
    >
    >
    > If you've been running tripwire or some other checksum'ing process
    > over your filesystem and know when you were compromised you *might*
    > be able to recover the box without a re-install. If you had a spare
    > box at the same patchlevel you might be able to compare it (assuming
    > they haven't compromised ls, sum, find etc.). As you noticed, they'd
    > compromised ls so the chances are that you won't see many of the
    > changes they've made -- hence looking at directory timestamps.
    >
    > It all sounds a bit harsh but in summary you don't know what they've
    > done to your box. They will have changed some programs to
    > deliberately lie about their own existence. You simply can't trust
    > your eyes anymore.
    >
    > If you have a particularly paranoid mind you could even believe that
    > they would have compromised ftpd so that you can't even copy a new
    > version of ls onto the box as they'll spot it and immediately
    > substitute the hacked one for it.
    > [/ref]
    any [/ref]
    case I 
    >
    > System config? In terms of patch levels and packages? Do you want
    > to trust the output of any command on that box?
    >
    > As to the breakin time, go back to my first suggestions (ptree, pwdx)
    > and see what you can. Taking it all with a pinch of salt.
    >
    > As they say, you're ed. The rest of us have all been ed in
    > turn. Now's the time to accept your loss, re-install the box and
    > move on.
    >
    > Cheers,
    >
    > Ian
    >
    > Thanks a lot for datailed answer, I will start from scratch.[/ref]
    Rob


    Rob Guest

Similar Threads

  1. OT: ATTACK TO MY SYSTEM
    By Dan Muey in forum PERL Beginners
    Replies: 0
    Last Post: September 23rd, 10:01 PM
  2. OT: ATTACK TO MY SYSTEM
    By Dan Muey in forum PERL Beginners
    Replies: 1
    Last Post: September 23rd, 09:29 PM
  3. OT: ATTACK TO MY SYSTEM
    By Wiggins D'Anconia in forum PERL Beginners
    Replies: 4
    Last Post: September 23rd, 08:13 PM
  4. Replies: 15
    Last Post: July 20th, 11:58 PM
  5. XP Attack
    By Robert Michon in forum Windows Setup, Administration & Security
    Replies: 1
    Last Post: July 2nd, 03:31 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139