changing root password with Knoppix? - Security

This is a discussion on changing root password with Knoppix? - Security ; I recently just had a FC2 box hacked. Unfortunately we simply can't take it offline at the moment because we have outside people needing to use files on it. I'm in the process of rebuilding the box over the next ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 24

Thread: changing root password with Knoppix?

  1. changing root password with Knoppix?

    I recently just had a FC2 box hacked.
    Unfortunately we simply can't take it offline at the moment because we
    have outside people needing to use files on it.
    I'm in the process of rebuilding the box over the next couple of days,
    but in the meantime, I have to keep the compromised machine up.

    While the crackper appeared to simply install a spam relay (didn't even
    delete the bash_history or anything,) I don't want to take any chances
    and need to change passwords on it, hoping he doesn't have bash storing
    information.

    It was recommended I use Knoppix to change the root password. I found a
    thread where Lew P. instructed someone how to delete the root password:


    Boot up with Knoppix, and log on as root
    Mount your hd somewhere
    Edit the HD /etc/passwd
    - delete the second field of the 'root' password entry (the text
    between the first and second colons), so that the entry looks
    something like
    root::0:0::/root:/bin/bash
    - save this change, and exit the editor
    Unmount your hard disk
    Log out
    Reboot from your HD


    But, when I boot back up with the system, IF bash IS being logged, when
    I change the root password won't it be logged?
    Will Knoppix only allow me to delete the password and not change it?

    Unrelated note, if I want to run "badblocks" on the PC with Knoppix, I
    mount the drive in question and run it like this, right?

    mount -t ext3 /dev/hdc1 /hdc1
    badblocks -s -v /hdc1

    Like that?
    (LOL I love this from the badblocks man: "This can be overriden using
    the -f flag, but should almost never be used --- if you think you're
    smarter than the bad-blocks program, you almost certainly
    aren't.")


  2. Re: changing root password with Knoppix?

    On 18 Apr 2006 14:29:42 -0700, news@celticbear.com wrote:
    > I recently just had a FC2 box hacked.
    > Unfortunately we simply can't take it offline at the moment because we
    > have outside people needing to use files on it.
    > I'm in the process of rebuilding the box over the next couple of days,
    > but in the meantime, I have to keep the compromised machine up.


    >
    > But, when I boot back up with the system, IF bash IS being logged, when
    > I change the root password won't it be logged?


    How sad, you want to leave a cracked system on the net, you have no
    problem with your users getting their password/information
    compromised, no idea what else is going on, on the system, but you
    want to protect root's password, and will get back to installing a
    clean system in a few days.

    Sounds like you are just asking for lawyer trouble.
    You can not trust any utility on that system to tell you the truth
    about what is going on.


  3. Re: changing root password with Knoppix?


    Bit Twister wrote:
    > On 18 Apr 2006 14:29:42 -0700, news@celticbear.com wrote:
    > > I recently just had a FC2 box hacked.
    > > Unfortunately we simply can't take it offline at the moment because we
    > > have outside people needing to use files on it.
    > > I'm in the process of rebuilding the box over the next couple of days,
    > > but in the meantime, I have to keep the compromised machine up.

    >
    > >
    > > But, when I boot back up with the system, IF bash IS being logged, when
    > > I change the root password won't it be logged?

    >
    > How sad, you want to leave a cracked system on the net, you have no
    > problem with your users getting their password/information
    > compromised, no idea what else is going on, on the system, but you
    > want to protect root's password, and will get back to installing a
    > clean system in a few days.
    >
    > Sounds like you are just asking for lawyer trouble.
    > You can not trust any utility on that system to tell you the truth
    > about what is going on.


    Well, let me put it this way:
    I can't build a new system until I get a new HD which we are
    overnighting from Newegg. Once I get that it takes me about a full day
    to install the OS and all the software we have to use on it, and copy
    over the 220 GB or data to the new system.
    So it's going to be a cpl of days before it's up and running, out of
    necessity, not out of lack of care.
    The current system is needed for our vendor to get product files in
    order to produce them, which they do using an .htaccess protected dir
    on the Web server... no customer logins to be compromised. The only
    data that can be compromised is our own, and we can't get it off there
    until we get a new drive (see above.)
    There are no other user accounts on the system aside from my own and
    the ones that are installed by default by Fedora Core.
    If we take the system down for two days, that is literally tens of
    thousands of dollars lost which since we're barely in the black, would
    mean laying off an employee for a month or so or not paying several
    bills and clients (who are in no way jeprodized by this machine.)
    And since I'm about 75% sure that the only modification to the system
    is the addition of a spam relay....
    Taking all that into account, we made the decision to keep the machine
    online as the negatives to taking it off until the new server was ready
    to swap places, WAY outweighed the minimal damage keeping it on COULD
    cause.

    Now that I've just layed out way more info than you needed and wasted a
    lot of space better left unused, I don't suppose you'd have an answer
    to my original question?
    No?
    OK, thanks for replying.


  4. Re: changing root password with Knoppix?

    news@celticbear.com wrote:

    > I recently just had a FC2 box hacked.
    > Unfortunately we simply can't take it offline at the moment


    OK so far.

    > because we
    > have outside people needing to use files on it.


    erm, no.

    >
    > While the crackper appeared to simply install a spam relay (didn't even
    > delete the bash_history or anything,)


    You obviously don't KNOW that's all the cracker did. Take some time to think
    about why not.

    > I don't want to take any chances
    > and need to change passwords on it, hoping he doesn't have bash storing
    > information.
    >


    Ah, hope, yes I forgot about that reliable method of ensuring security - you
    might try prayers and/or sacrifice too.

    > It was recommended I use Knoppix to change the root password. I found a
    > thread where Lew P. instructed someone how to delete the root password:
    >


    >
    > But, when I boot back up with the system, IF bash IS being logged, when
    > I change the root password won't it be logged?


    That's the least of your worries - apart from anything else - this tutorial
    isn't going to work on your machine.

    > Like that?
    > (LOL I love this from the badblocks man: "This can be overriden using
    > the -f flag, but should almost never be used --- if you think you're
    > smarter than the bad-blocks program, you almost certainly
    > aren't.")


    (I'm sooooooo tempted....)

    Let's try again.
    You WILL backup ONLY the files you MUST keep from this server.
    You WILL check them for executable content.
    You WILL reformat the hard disk and reinstall from distribution media
    You WILL install all vendor patches before running any services (preferably
    before plugging it into the internet)
    You WILL install an IDS to ensure that you can recover next time
    You WILL learn how to use it
    You may now restore the files you carried over from the previous life of the
    box.
    You WILL keep your security procedures under regular monitoring and review.

    C.

  5. Re: changing root password with Knoppix?


    Colin McKinnon wrote:
    > news@celticbear.com wrote:
    >
    > > I recently just had a FC2 box hacked.
    > > Unfortunately we simply can't take it offline at the moment

    >
    > OK so far.
    >
    > > because we
    > > have outside people needing to use files on it.

    >
    > erm, no.
    >
    > >
    > > While the crackper appeared to simply install a spam relay (didn't even
    > > delete the bash_history or anything,)

    >
    > You obviously don't KNOW that's all the cracker did. Take some time to think
    > about why not.
    >
    > > I don't want to take any chances
    > > and need to change passwords on it, hoping he doesn't have bash storing
    > > information.
    > >

    >
    > Ah, hope, yes I forgot about that reliable method of ensuring security - you
    > might try prayers and/or sacrifice too.
    >
    > > It was recommended I use Knoppix to change the root password. I found a
    > > thread where Lew P. instructed someone how to delete the root password:
    > >

    >
    > >
    > > But, when I boot back up with the system, IF bash IS being logged, when
    > > I change the root password won't it be logged?

    >
    > That's the least of your worries - apart from anything else - this tutorial
    > isn't going to work on your machine.
    >
    > > Like that?
    > > (LOL I love this from the badblocks man: "This can be overriden using
    > > the -f flag, but should almost never be used --- if you think you're
    > > smarter than the bad-blocks program, you almost certainly
    > > aren't.")

    >
    > (I'm sooooooo tempted....)
    >
    > Let's try again.
    > You WILL backup ONLY the files you MUST keep from this server.
    > You WILL check them for executable content.
    > You WILL reformat the hard disk and reinstall from distribution media
    > You WILL install all vendor patches before running any services (preferably
    > before plugging it into the internet)
    > You WILL install an IDS to ensure that you can recover next time
    > You WILL learn how to use it
    > You may now restore the files you carried over from the previous life of the
    > box.
    > You WILL keep your security procedures under regular monitoring and review.
    >


    How'bout this:

    You WILL not assume that I WASN'T planning on only backing up what we
    must keep.
    You WILL realize that you do not know that we are overnighting new HD's
    from Newegg to put into a new machine that is going to be replacing the
    old, compromised one.
    You WILL not assume that I won't install the patches, or that I wasn't
    before by running nightly "yum" updates (FedoraCore) or be subscribed
    to the Slackware lists alerting me of new patches with the new server
    (that will, to be redundant, be running Slackware.)
    You WILL not assume that I don't already have a separate IP-Cop serving
    as an IDS box, and that the compromised system was in the DMZ as it was
    being used as a Web server and thus was required to have SOME
    compromiseable access to the Internet.

    See my reply to the other rather rude, assuptive, and elitest responder
    for information as to why we're taking the chance with keeping the
    system up for another cpl days, and tedious information regarding
    getting new hardware which implies our copying only necessary data onto
    a rebuilt system, and reinforcement of my knowledge that I'm NOT
    certain that's all that was done to the system, but am mostly sure
    based on evidence.
    The fact I'm not possitive is evidenced in the fact that I'm completely
    rebuilding the system.

    Thank you.

    (Wow, it's funny. I thought the Slackware people over in that newsgroup
    would be pricks, but they've turned out to be extremely helpful,
    respectful, great people. Why is it over here I get slammed by elitest
    jerks who evidently were born with all knowledge and never had to learn
    anything themselves through experience or "the hard way" and so cut no
    slack. Weird.)


  6. Re: changing root password with Knoppix?

    "news@celticbear.com" writes:

    >I recently just had a FC2 box hacked.
    >Unfortunately we simply can't take it offline at the moment because we
    >have outside people needing to use files on it.
    >I'm in the process of rebuilding the box over the next couple of days,
    >but in the meantime, I have to keep the compromised machine up.


    You are in a race. As quickly as you fix the cracker can undo your fix. At
    least take it off the net for a while while you fix the cracks.

    As a minimal effort.

    rpm -Va|grep '^..5'>/tmp/verify
    to find all files which have changed since you installed them. (actually
    you should first reinstall rpm to make sure that it is good)
    Go through those files and reinstall (--force) all of the rpms containing
    altered files ( assuming of course that they are not altered because they
    are configuration files). Then do
    find / -perm +6000 -ls
    to find all files which are suid/sgid. Some of course should be. But no
    file in /dev, /tmp, /etc or other such weird places should be.
    (of course you have to be sure that your find is a good find. You might
    want to use the find and the rpm from a single disk like Mandrake One of
    Knopix or whatever.)





    >While the crackper appeared to simply install a spam relay (didn't even
    >delete the bash_history or anything,) I don't want to take any chances
    >and need to change passwords on it, hoping he doesn't have bash storing
    >information.


    Of course. But he may well have a little program which runs and captures
    the passwords, or bypasses them anyway ( replaced login, ssh, telnet
    programs)


    >It was recommended I use Knoppix to change the root password. I found a
    >thread where Lew P. instructed someone how to delete the root password:


    >
    >Boot up with Knoppix, and log on as root
    >Mount your hd somewhere
    >Edit the HD /etc/passwd
    > - delete the second field of the 'root' password entry (the text
    > between the first and second colons), so that the entry looks
    > something like
    > root::0:0::/root:/bin/bash
    > - save this change, and exit the editor
    >Unmount your hard disk
    >Log out
    >Reboot from your HD


    Uh, what this does is to remove the root password entirely. What you would
    be better off doing is to use knoppix to set another root password. and
    then copy that into /etc/shadow.

    >


    >But, when I boot back up with the system, IF bash IS being logged, when
    >I change the root password won't it be logged?
    >Will Knoppix only allow me to delete the password and not change it?


    You can trust NOTHING on the infected machine.



    >Unrelated note, if I want to run "badblocks" on the PC with Knoppix, I
    >mount the drive in question and run it like this, right?


    >mount -t ext3 /dev/hdc1 /hdc1
    >badblocks -s -v /hdc1


    This is completely off topic isn't it?


    >Like that?
    >(LOL I love this from the badblocks man: "This can be overriden using
    >the -f flag, but should almost never be used --- if you think you're
    >smarter than the bad-blocks program, you almost certainly
    >aren't.")



  7. Re: changing root password with Knoppix?

    "news@celticbear.com" writes:


    >Bit Twister wrote:
    >> On 18 Apr 2006 14:29:42 -0700, news@celticbear.com wrote:
    >> > I recently just had a FC2 box hacked.
    >> > Unfortunately we simply can't take it offline at the moment because we
    >> > have outside people needing to use files on it.
    >> > I'm in the process of rebuilding the box over the next couple of days,
    >> > but in the meantime, I have to keep the compromised machine up.

    >>
    >> >
    >> > But, when I boot back up with the system, IF bash IS being logged, when
    >> > I change the root password won't it be logged?

    >>
    >> How sad, you want to leave a cracked system on the net, you have no
    >> problem with your users getting their password/information
    >> compromised, no idea what else is going on, on the system, but you
    >> want to protect root's password, and will get back to installing a
    >> clean system in a few days.
    >>
    >> Sounds like you are just asking for lawyer trouble.
    >> You can not trust any utility on that system to tell you the truth
    >> about what is going on.


    >Well, let me put it this way:
    >I can't build a new system until I get a new HD which we are


    This is not an issue of a new HD. This is an issue of limiting the damage
    that could be caused. I understand the worry about taking this system
    offline (Now you understand why any business like yours should have two
    computers duplicating each other so one can be swapped in at almost any
    time for the other-- that costs you maybe $1000.)

    You can assume that the cracker is your worst competitor, who is determined
    to drive you out of business. He will change the data in your database, and
    then what is the use of keeping the database up?

    Take it offline immediately. Then patch the minimal patches I mentioned.

    Remember that there is a good chance that the attacker left easter eggs for
    himself-- say a suid root shell in amongst the files of your database,
    which means he can break in again at any time. Or a cron file in
    /etc/cron.daily which sets up a root connection to his machine and
    downloads a backdoor once a day. Or....

    >overnighting from Newegg. Once I get that it takes me about a full day
    >to install the OS and all the software we have to use on it, and copy
    >over the 220 GB or data to the new system.
    >So it's going to be a cpl of days before it's up and running, out of
    >necessity, not out of lack of care.
    >The current system is needed for our vendor to get product files in
    >order to produce them, which they do using an .htaccess protected dir
    >on the Web server... no customer logins to be compromised. The only


    That protection is now gone. That .htaccess could well be useless.


    >data that can be compromised is our own, and we can't get it off there
    >until we get a new drive (see above.)
    >There are no other user accounts on the system aside from my own and
    >the ones that are installed by default by Fedora Core.
    >If we take the system down for two days, that is literally tens of
    >thousands of dollars lost which since we're barely in the black, would
    >mean laying off an employee for a month or so or not paying several
    >bills and clients (who are in no way jeprodized by this machine.)
    >And since I'm about 75% sure that the only modification to the system
    >is the addition of a spam relay....
    >Taking all that into account, we made the decision to keep the machine
    >online as the negatives to taking it off until the new server was ready
    >to swap places, WAY outweighed the minimal damage keeping it on COULD
    >cause.


    >Now that I've just layed out way more info than you needed and wasted a
    >lot of space better left unused, I don't suppose you'd have an answer
    >to my original question?
    >No?
    >OK, thanks for replying.



  8. Re: changing root password with Knoppix?


    Unruh wrote:
    > "news@celticbear.com" writes:
    >
    >
    > >Bit Twister wrote:
    > >> On 18 Apr 2006 14:29:42 -0700, news@celticbear.com wrote:
    > >> > I recently just had a FC2 box hacked.
    > >> > Unfortunately we simply can't take it offline at the moment because we
    > >> > have outside people needing to use files on it.
    > >> > I'm in the process of rebuilding the box over the next couple of days,
    > >> > but in the meantime, I have to keep the compromised machine up.
    > >>
    > >> >
    > >> > But, when I boot back up with the system, IF bash IS being logged, when
    > >> > I change the root password won't it be logged?
    > >>
    > >> How sad, you want to leave a cracked system on the net, you have no
    > >> problem with your users getting their password/information
    > >> compromised, no idea what else is going on, on the system, but you
    > >> want to protect root's password, and will get back to installing a
    > >> clean system in a few days.
    > >>
    > >> Sounds like you are just asking for lawyer trouble.
    > >> You can not trust any utility on that system to tell you the truth
    > >> about what is going on.

    >
    > >Well, let me put it this way:
    > >I can't build a new system until I get a new HD which we are

    >
    > This is not an issue of a new HD. This is an issue of limiting the damage
    > that could be caused. I understand the worry about taking this system
    > offline (Now you understand why any business like yours should have two
    > computers duplicating each other so one can be swapped in at almost any
    > time for the other-- that costs you maybe $1000.)
    >

    No no, I know it's not a HD issue. But we have gigs of data spread over
    5 PC's, including this Web server in the DMZ, so I was able to convince
    the beancounters that we need a seperate fileserver inside the
    protected LAN and not shared with a Web server that's accessable by the
    'net.
    We don't have any place to put that data until those HD's get here.

    Redundant machines, yep, indeed! Would be nice. =)

    > You can assume that the cracker is your worst competitor, who is determined
    > to drive you out of business. He will change the data in your database, and
    > then what is the use of keeping the database up?
    >

    Fortunately this machine, in addition to having stored files that ARE
    at risk, it's just running a Web server (and ImageMagick to convert
    image files).
    Our DB and main Web server are on different machines in a hosted server
    farm off-site.
    This server in question is only for one particular vendor to be able to
    download ImageMagicked files for production. That's it.
    But, it's important enough that without it running, no production is
    run, and we lose money.

    a. Take it off line (the best thing to do, I fully agree!) = lost
    money.
    or
    b. Keep it online, continue generating revenue for a cpl days and at
    worst, lose a few gigs of old data that won't kill us, just be an
    annoyance, and MAYBE have the vendor download interrupted.

    Choice a. is a gaurenteed (sp) loss of money, choice b. is a MAYBE
    loss. We went with b.


    > Take it offline immediately. Then patch the minimal patches I mentioned.
    >
    > Remember that there is a good chance that the attacker left easter eggs for
    > himself-- say a suid root shell in amongst the files of your database,
    > which means he can break in again at any time. Or a cron file in
    > /etc/cron.daily which sets up a root connection to his machine and
    > downloads a backdoor once a day. Or....
    >


    See above, I am going to be rebuilding the Web server as well as a new
    machine to serve as a safe file server inaccessable from the 'Net.
    In the meantime, weighing the pros and cons, we've decided the definite
    loss of being off-line is worse than the maybe loss of online and
    something additional bad happening.

    This this were our main server, I'd pull it off in a second!
    But like I said, our main Web server, our database, all the main
    workings of the co. are on different managed servers.
    This is a small, 1-task only server with little more they can do to it
    than just shut it down themselves.

    > >overnighting from Newegg. Once I get that it takes me about a full day
    > >to install the OS and all the software we have to use on it, and copy
    > >over the 220 GB or data to the new system.
    > >So it's going to be a cpl of days before it's up and running, out of
    > >necessity, not out of lack of care.
    > >The current system is needed for our vendor to get product files in
    > >order to produce them, which they do using an .htaccess protected dir
    > >on the Web server... no customer logins to be compromised. The only

    >
    > That protection is now gone. That .htaccess could well be useless.
    >

    'fairnuff. I'm just saying, there's nothing else in /etc/passwd except
    root that's important. No one else is at risk.

    Thanks for replying!


  9. Re: changing root password with Knoppix?


    Unruh wrote:
    > "news@celticbear.com" writes:
    >
    > >I recently just had a FC2 box hacked.
    > >Unfortunately we simply can't take it offline at the moment because we
    > >have outside people needing to use files on it.
    > >I'm in the process of rebuilding the box over the next couple of days,
    > >but in the meantime, I have to keep the compromised machine up.

    >
    > You are in a race. As quickly as you fix the cracker can undo your fix. At
    > least take it off the net for a while while you fix the cracks.
    >
    > As a minimal effort.
    >
    > rpm -Va|grep '^..5'>/tmp/verify
    > to find all files which have changed since you installed them. (actually
    > you should first reinstall rpm to make sure that it is good)
    > Go through those files and reinstall (--force) all of the rpms containing
    > altered files ( assuming of course that they are not altered because they
    > are configuration files). Then do
    > find / -perm +6000 -ls
    > to find all files which are suid/sgid. Some of course should be. But no
    > file in /dev, /tmp, /etc or other such weird places should be.
    > (of course you have to be sure that your find is a good find. You might
    > want to use the find and the rpm from a single disk like Mandrake One of
    > Knopix or whatever.)


    OK, so I run that RPM verification and get results like:

    S.5....T c /usr/share/sgml/docbook/xmlcatalog
    SM5....T /etc/tripwire/twpol.txt
    S.5....T c /etc/cron.d/portsentry
    S.5....T c /etc/portsentry/portsentry.conf

    What do the colums mean?

    This is some great info I'm deffinitely going to keep track of for the
    future.
    Well, I'm going to keep looking to see what the extent of the possible
    damage is, just so I know... but the machine is going bye-bye in two
    days.

    I'm going to be installing tripwire in the new Slackware setup. Tried a
    test install on this machine, but uh... looks like I'm going to have to
    do some searching to see how to do it right, it looks like. =) And USE
    it to look for changes!

    [..snip..]

    > >It was recommended I use Knoppix to change the root password. I found a
    > >thread where Lew P. instructed someone how to delete the root password:

    >
    > >
    > >Boot up with Knoppix, and log on as root
    > >Mount your hd somewhere
    > >Edit the HD /etc/passwd
    > > - delete the second field of the 'root' password entry (the text
    > > between the first and second colons), so that the entry looks
    > > something like
    > > root::0:0::/root:/bin/bash
    > > - save this change, and exit the editor
    > >Unmount your hard disk
    > >Log out
    > >Reboot from your HD

    >
    > Uh, what this does is to remove the root password entirely. What you would
    > be better off doing is to use knoppix to set another root password. and
    > then copy that into /etc/shadow.


    Right, that was my problem. =) I want to be able to change it, not just
    remove it.
    So I ask, how do you change it in knoppix for the system in question?
    I just played around with it a little, and found the HD's are in
    read-only mode when booted up with knoppix. I tried to re-mount them
    manually, but the traditional:
    mount -t ext3 /mnt/hda2 /hda
    doesn't work in a read-only mode.
    Probably need to mount the "something" to a "somewhere" in the
    ramdrive?
    Oh, well, I'll figure it out!

    Thanks for replying. =)

    [..snip..]


  10. Re: changing root password with Knoppix?

    On 18 Apr 2006 17:10:06 -0700, news@celticbear.com wrote:

    > OK, so I run that RPM verification and get results like:
    >
    > S.5....T c /usr/share/sgml/docbook/xmlcatalog
    > SM5....T /etc/tripwire/twpol.txt
    > S.5....T c /etc/cron.d/portsentry
    > S.5....T c /etc/portsentry/portsentry.conf
    >
    > What do the colums mean?


    man rpm

    > I'm going to be installing tripwire in the new Slackware setup.


    You may want to look into samhain
    http://la-samhna.de/samhain/s_documentation.html

  11. Re: changing root password with Knoppix?

    On Tue, 18 Apr 2006 14:29:42 -0700, news@celticbear.com wrote:

    > I recently just had a FC2 box hacked.
    > Unfortunately we simply can't take it offline at the moment because we
    > have outside people needing to use files on it.
    > I'm in the process of rebuilding the box over the next couple of days,
    > but in the meantime, I have to keep the compromised machine up.
    >
    > While the crackper appeared to simply install a spam relay (didn't even
    > delete the bash_history or anything,) I don't want to take any chances
    > and need to change passwords on it, hoping he doesn't have bash storing
    > information.
    >
    > It was recommended I use Knoppix to change the root password. I found a
    > thread where Lew P. instructed someone how to delete the root password:
    >
    >
    > Boot up with Knoppix, and log on as root
    > Mount your hd somewhere
    > Edit the HD /etc/passwd
    > - delete the second field of the 'root' password entry (the text
    > between the first and second colons), so that the entry looks
    > something like
    > root::0:0::/root:/bin/bash
    > - save this change, and exit the editor
    > Unmount your hard disk
    > Log out
    > Reboot from your HD
    >

    >
    > But, when I boot back up with the system, IF bash IS being logged, when
    > I change the root password won't it be logged?
    > Will Knoppix only allow me to delete the password and not change it?


    If you 'chroot' to the affected system after booting a Live CD and then
    change the password, I think you may be home free.

    >
    > Unrelated note, if I want to run "badblocks" on the PC with Knoppix, I
    > mount the drive in question and run it like this, right?
    >
    > mount -t ext3 /dev/hdc1 /hdc1
    > badblocks -s -v /hdc1


    As I recall, badblocks does not require the system to be mounted - it is
    simply doing a block by block check of each and every sector.

    >
    > Like that?
    > (LOL I love this from the badblocks man: "This can be overriden using
    > the -f flag, but should almost never be used --- if you think you're
    > smarter than the bad-blocks program, you almost certainly
    > aren't.")



  12. Re: changing root password with Knoppix?

    On Tue, 18 Apr 2006 17:10:06 -0700, news@celticbear.com wrote:

    >> >It was recommended I use Knoppix to change the root password. I found
    >> >a thread where Lew P. instructed someone how to delete the root
    >> >password:

    >>
    >> >
    >> >Boot up with Knoppix, and log on as root Mount your hd somewhere
    >> >Edit the HD /etc/passwd
    >> > - delete the second field of the 'root' password entry (the text
    >> > between the first and second colons), so that the entry looks
    >> > something like
    >> > root::0:0::/root:/bin/bash
    >> > - save this change, and exit the editor
    >> >Unmount your hard disk
    >> >Log out
    >> >Reboot from your HD

    >>
    >> Uh, what this does is to remove the root password entirely. What you
    >> would be better off doing is to use knoppix to set another root
    >> password. and then copy that into /etc/shadow.

    >
    > Right, that was my problem. =) I want to be able to change it, not just
    > remove it.
    > So I ask, how do you change it in knoppix for the system in question? I
    > just played around with it a little, and found the HD's are in read-only
    > mode when booted up with knoppix. I tried to re-mount them manually,
    > but the traditional:
    > mount -t ext3 /mnt/hda2 /hda
    > doesn't work in a read-only mode.
    > Probably need to mount the "something" to a "somewhere" in the ramdrive?
    > Oh, well, I'll figure it out!



    I really wouldn't bother changing root's password: as others have
    pointed out the system is possibly so compromised a complete reinstall is
    the only right thing to do.

    But for future reference I recall the last time I played with
    Knoppix you could just right-click on the icons for the hdds it finds and
    tell it to remount them read-write. Or use option remount to the mount
    command.

    I think you could do 'passwd' as user knoppix and change the password hash
    for user knoppix, which you would then find in /etc/shadow (or maybe
    /etc/passwd) on the ram-based file system knoppix sets up, and cut&paste
    that into the /etc/shadow passwd hash for root on the hdd. (There's
    probably a cleaner way but I can't think what command gives you a passwd
    hash directly.) That's how you'd hack yourself out of losing the root
    password on a system.


  13. Re: changing root password with Knoppix?

    In article <1145404698.574860.147180@e56g2000cwe.googlegroups. com>, news@celticbear.com wrote:
    >>

    > Fortunately this machine, in addition to having stored files that ARE
    > at risk, it's just running a Web server (and ImageMagick to convert
    > image files).
    > Our DB and main Web server are on different machines in a hosted server
    > farm off-site.
    > This server in question is only for one particular vendor to be able to
    > download ImageMagicked files for production.


    If the application on the compromised machine is really that
    simple, static HTTP access, why not boot something like Knoppix on it,
    mount those valuable data partitions noexec,ro, and run the
    Web server and Imagemagick that come with the live CD?
    Don't even mount the partition with the intruder's
    modified cron jobs and libc and perl and wget.

    Hell, don't even run shutdown. Intruder might have
    a bomb in /etc/rc0.d that you can't see with his modified
    ls(1). He might have a bomb in shutdown(8).
    He might have messed up your kernel so even if
    you managed to get a clean, statically linked ls(1)
    in there you still couldn't see his bomb.
    Pull the plug and let the live CD run a more trustworthy
    fsck on that partition you need so badly.

    You're lucky you've got physical access to the machine.
    You're reckless as hell for letting the intruder have
    access for one more minute.


    Cameron


    --
    NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth

  14. Re: changing root password with Knoppix?

    In article , ray wrote:
    >
    > If you 'chroot' to the affected system after booting a Live CD and then
    > change the password, I think you may be home free.


    I don't think so. Once you chroot to the compromised system,
    every thing you run will be a possibly/probably compromised
    binary sharing compromised libraries through a compromised
    linking loader. You're running the stuff your PATH finds
    in the chroot, not the stuff you left behind.
    You can't trust executables on the compromised machine, period.
    They may not even be the same compromised executables
    they were before you ran the intruder's shutdown(8).

    You might be lucky and the intruder is just a spam
    criminal looking for another bot-controller. But luck
    is not a security discipline. Like the other guy
    said, your intruder may be working for your competitor.
    He may be a fired ex-employee, psychotic, and seeking
    revenge. He may be all of those, and that's the case you
    have to assume.


    Cameron



    --
    NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth

  15. Re: changing root password with Knoppix?

    On Wed, 19 Apr 2006 02:32:57 +0000, Cameron L. Spitzer wrote:

    > In article , ray wrote:
    >>
    >> If you 'chroot' to the affected system after booting a Live CD and then
    >> change the password, I think you may be home free.

    >
    > I don't think so. Once you chroot to the compromised system,
    > every thing you run will be a possibly/probably compromised
    > binary sharing compromised libraries through a compromised
    > linking loader. You're running the stuff your PATH finds
    > in the chroot, not the stuff you left behind.
    > You can't trust executables on the compromised machine, period.
    > They may not even be the same compromised executables
    > they were before you ran the intruder's shutdown(8).
    >


    You're right. But the only thing you need to run is passwd - then exit or
    pull the plug. There is the chance that passwd may be compromised, but
    maybe not.

    > You might be lucky and the intruder is just a spam
    > criminal looking for another bot-controller. But luck
    > is not a security discipline. Like the other guy
    > said, your intruder may be working for your competitor.
    > He may be a fired ex-employee, psychotic, and seeking
    > revenge. He may be all of those, and that's the case you
    > have to assume.
    >
    >
    > Cameron



  16. Re: changing root password with Knoppix?

    "news@celticbear.com" writes:


    >Unruh wrote:
    >> "news@celticbear.com" writes:
    >>
    >>
    >> >Bit Twister wrote:
    >> >> On 18 Apr 2006 14:29:42 -0700, news@celticbear.com wrote:
    >> >> > I recently just had a FC2 box hacked.
    >> >> > Unfortunately we simply can't take it offline at the moment because we
    >> >> > have outside people needing to use files on it.
    >> >> > I'm in the process of rebuilding the box over the next couple of days,
    >> >> > but in the meantime, I have to keep the compromised machine up.
    >> >>
    >> >> >
    >> >> > But, when I boot back up with the system, IF bash IS being logged, when
    >> >> > I change the root password won't it be logged?
    >> >>
    >> >> How sad, you want to leave a cracked system on the net, you have no
    >> >> problem with your users getting their password/information
    >> >> compromised, no idea what else is going on, on the system, but you
    >> >> want to protect root's password, and will get back to installing a
    >> >> clean system in a few days.
    >> >>
    >> >> Sounds like you are just asking for lawyer trouble.
    >> >> You can not trust any utility on that system to tell you the truth
    >> >> about what is going on.

    >>
    >> >Well, let me put it this way:
    >> >I can't build a new system until I get a new HD which we are

    >>
    >> This is not an issue of a new HD. This is an issue of limiting the damage
    >> that could be caused. I understand the worry about taking this system
    >> offline (Now you understand why any business like yours should have two
    >> computers duplicating each other so one can be swapped in at almost any
    >> time for the other-- that costs you maybe $1000.)
    >>

    >No no, I know it's not a HD issue. But we have gigs of data spread over
    >5 PC's, including this Web server in the DMZ, so I was able to convince
    >the beancounters that we need a seperate fileserver inside the
    >protected LAN and not shared with a Web server that's accessable by the
    >'net.
    >We don't have any place to put that data until those HD's get here.


    >Redundant machines, yep, indeed! Would be nice. =)


    >> You can assume that the cracker is your worst competitor, who is determined
    >> to drive you out of business. He will change the data in your database, and
    >> then what is the use of keeping the database up?
    >>

    >Fortunately this machine, in addition to having stored files that ARE
    >at risk, it's just running a Web server (and ImageMagick to convert
    >image files).
    >Our DB and main Web server are on different machines in a hosted server
    >farm off-site.
    >This server in question is only for one particular vendor to be able to
    >download ImageMagicked files for production. That's it.
    >But, it's important enough that without it running, no production is
    >run, and we lose money.


    >a. Take it off line (the best thing to do, I fully agree!) = lost
    >money.
    >or
    >b. Keep it online, continue generating revenue for a cpl days and at
    >worst, lose a few gigs of old data that won't kill us, just be an
    >annoyance, and MAYBE have the vendor download interrupted.


    I somehow doubt that your vendor is on it 24 hours a day. This is the
    evening. Let the vendor know that you have to take it offline for an hour,
    and do the minimal hardening.



    >Choice a. is a gaurenteed (sp) loss of money, choice b. is a MAYBE
    >loss. We went with b.



    >> Take it offline immediately. Then patch the minimal patches I mentioned.
    >>
    >> Remember that there is a good chance that the attacker left easter eggs for
    >> himself-- say a suid root shell in amongst the files of your database,
    >> which means he can break in again at any time. Or a cron file in
    >> /etc/cron.daily which sets up a root connection to his machine and
    >> downloads a backdoor once a day. Or....
    >>


    >See above, I am going to be rebuilding the Web server as well as a new
    >machine to serve as a safe file server inaccessable from the 'Net.
    >In the meantime, weighing the pros and cons, we've decided the definite
    >loss of being off-line is worse than the maybe loss of online and
    >something additional bad happening.


    >This this were our main server, I'd pull it off in a second!
    >But like I said, our main Web server, our database, all the main
    >workings of the co. are on different managed servers.
    >This is a small, 1-task only server with little more they can do to it
    >than just shut it down themselves.


    >> >overnighting from Newegg. Once I get that it takes me about a full day
    >> >to install the OS and all the software we have to use on it, and copy
    >> >over the 220 GB or data to the new system.
    >> >So it's going to be a cpl of days before it's up and running, out of
    >> >necessity, not out of lack of care.
    >> >The current system is needed for our vendor to get product files in
    >> >order to produce them, which they do using an .htaccess protected dir
    >> >on the Web server... no customer logins to be compromised. The only

    >>
    >> That protection is now gone. That .htaccess could well be useless.
    >>

    >'fairnuff. I'm just saying, there's nothing else in /etc/passwd except
    >root that's important. No one else is at risk.


    >Thanks for replying!



  17. Re: changing root password with Knoppix?

    "news@celticbear.com" writes:


    >Unruh wrote:
    >> "news@celticbear.com" writes:
    >>
    >> >I recently just had a FC2 box hacked.
    >> >Unfortunately we simply can't take it offline at the moment because we
    >> >have outside people needing to use files on it.
    >> >I'm in the process of rebuilding the box over the next couple of days,
    >> >but in the meantime, I have to keep the compromised machine up.

    >>
    >> You are in a race. As quickly as you fix the cracker can undo your fix. At
    >> least take it off the net for a while while you fix the cracks.
    >>
    >> As a minimal effort.
    >>
    >> rpm -Va|grep '^..5'>/tmp/verify
    >> to find all files which have changed since you installed them. (actually
    >> you should first reinstall rpm to make sure that it is good)
    >> Go through those files and reinstall (--force) all of the rpms containing
    >> altered files ( assuming of course that they are not altered because they
    >> are configuration files). Then do
    >> find / -perm +6000 -ls
    >> to find all files which are suid/sgid. Some of course should be. But no
    >> file in /dev, /tmp, /etc or other such weird places should be.
    >> (of course you have to be sure that your find is a good find. You might
    >> want to use the find and the rpm from a single disk like Mandrake One of
    >> Knopix or whatever.)


    >OK, so I run that RPM verification and get results like:


    >S.5....T c /usr/share/sgml/docbook/xmlcatalog
    >SM5....T /etc/tripwire/twpol.txt
    >S.5....T c /etc/cron.d/portsentry
    >S.5....T c /etc/portsentry/portsentry.conf


    It means that each of those files have changed since they were installed.
    Now, configuration files should be changed. But check them to make sure
    that that is what they are. And look for executable files that have
    changed.



    >What do the colums mean?


    man rpm

    S file Size differs
    M Mode differs (includes permissions and file type)
    5 MD5 sum differs
    D Device major/minor number mismatch
    L readLink(2) path mismatch
    U User ownership differs
    G Group ownership differs
    T mTime differs
    The key is the 5-- it says the files have changed.
    The c suggests this might be a config file (basically it is an ascii file)



    >This is some great info I'm deffinitely going to keep track of for the
    >future.
    >Well, I'm going to keep looking to see what the extent of the possible
    >damage is, just so I know... but the machine is going bye-bye in two
    >days.


    >I'm going to be installing tripwire in the new Slackware setup. Tried a
    >test install on this machine, but uh... looks like I'm going to have to
    >do some searching to see how to do it right, it looks like. =) And USE
    >it to look for changes!


    rpm -V IS tripwire from the installation. Of course you should protect the
    rpm database from being changed (/var/lib/rpm/*)


    >[..snip..]


    >> >It was recommended I use Knoppix to change the root password. I found a
    >> >thread where Lew P. instructed someone how to delete the root password:

    >>
    >> >
    >> >Boot up with Knoppix, and log on as root
    >> >Mount your hd somewhere
    >> >Edit the HD /etc/passwd
    >> > - delete the second field of the 'root' password entry (the text
    >> > between the first and second colons), so that the entry looks
    >> > something like
    >> > root::0:0::/root:/bin/bash
    >> > - save this change, and exit the editor
    >> >Unmount your hard disk
    >> >Log out
    >> >Reboot from your HD

    >>
    >> Uh, what this does is to remove the root password entirely. What you would
    >> be better off doing is to use knoppix to set another root password. and
    >> then copy that into /etc/shadow.


    >Right, that was my problem. =) I want to be able to change it, not just
    >remove it.
    >So I ask, how do you change it in knoppix for the system in question?
    >I just played around with it a little, and found the HD's are in
    >read-only mode when booted up with knoppix. I tried to re-mount them
    >manually, but the traditional:
    >mount -t ext3 /mnt/hda2 /hda


    mount -t ext3 /dev/hda2 /hda
    is what you wanted


    >doesn't work in a read-only mode.
    >Probably need to mount the "something" to a "somewhere" in the
    >ramdrive?
    >Oh, well, I'll figure it out!


    >Thanks for replying. =)


    >[..snip..]



  18. Re: changing root password with Knoppix?

    In comp.os.linux.misc, on Wed 19 April 2006 00:58, news@celticbear.com
    wrote:

    > This server in question is only for one particular vendor to be able
    > to download ImageMagicked files for production. That's it.


    And you don't mind that the vendor could be downloading files that have
    been altered to be detrimental to your business?

    > But, it's important enough that without it running, no production is
    > run, and we lose money.


    And with it running, you could be basing production on whatever tricks
    the cracker has decided to play on you? Do you understand that this
    could be more costly to your business than a couple of hours downtime?

    Does your supplier need to access the machine 24 hours a day? If not all
    your argument about lost production flies out of the window.
    >
    > a. Take it off line (the best thing to do, I fully agree!) = lost
    > money.


    Only if the vendor needs to access new files 24 hours a day.
    > or
    > b. Keep it online, continue generating revenue for a cpl days and


    Possibly face a massive law suit when it turns out that:

    a) You have done damage to your vendor's system

    OR

    b) You have violated someone's copyright due to changes introduced
    by the cracker

    OR

    c) You have damaged your own brand image due to changes introduced
    by the cracker

    OR

    d) None of the above, but you caused the vendor to lose production
    time due to changes introduced by the cracker

    You cannot guarantee that any of these will not be the case since you do
    not know what your system is doing.

    [snip]
    >
    > Choice a. is a gaurenteed (sp) loss of money,


    Not proven

    >
    > choice b. is a MAYBE loss. We went with b.


    Hope your legal insurance is good
    --
    Robert HULL

    Archival or publication of this article on any part of thisishull.net
    is without consent and is in direct breach of the Data Protection Act

  19. Re: changing root password with Knoppix?


    Cameron L. Spitzer wrote:
    > In article <1145404698.574860.147180@e56g2000cwe.googlegroups. com>, news@celticbear.com wrote:
    > >>

    > > Fortunately this machine, in addition to having stored files that ARE
    > > at risk, it's just running a Web server (and ImageMagick to convert
    > > image files).
    > > Our DB and main Web server are on different machines in a hosted server
    > > farm off-site.
    > > This server in question is only for one particular vendor to be able to
    > > download ImageMagicked files for production.

    >
    > If the application on the compromised machine is really that
    > simple, static HTTP access, why not boot something like Knoppix on it,
    > mount those valuable data partitions noexec,ro, and run the
    > Web server and Imagemagick that come with the live CD?
    > Don't even mount the partition with the intruder's
    > modified cron jobs and libc and perl and wget.
    >

    [..]
    Whoa! I hadn't even thought of that! That's a pretty cool idea.
    Thanks!


  20. Re: changing root password with Knoppix?


    Bit Twister wrote:
    > On 18 Apr 2006 17:10:06 -0700, news@celticbear.com wrote:
    >
    > > OK, so I run that RPM verification and get results like:
    > >
    > > S.5....T c /usr/share/sgml/docbook/xmlcatalog
    > > SM5....T /etc/tripwire/twpol.txt
    > > S.5....T c /etc/cron.d/portsentry
    > > S.5....T c /etc/portsentry/portsentry.conf
    > >
    > > What do the colums mean?

    >
    > man rpm
    >

    Gawd, if it wasn't obvious before, I'm an idiot.
    OK. there's a LOT of triggered entries. 206.
    Can something innocent cause an rpm verify to trigger?
    Like downloading an updated RPM from somewhere other than RedHat? Or,
    upgrading/reinstalling a package with source?

    > > I'm going to be installing tripwire in the new Slackware setup.

    >
    > You may want to look into samhain
    > http://la-samhna.de/samhain/s_documentation.html


    Well, if it installs easier than tripwire, I'll give it a try!


+ Reply to Thread
Page 1 of 2 1 2 LastLast