changing root password with Knoppix?

Schraalhans Keukenmeester wrote:
> news@celticbear.com wrote:
> > Unruh wrote:
> >
> >>"news@celticbear.com" <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.
> >>>>
> >>>><snipped>
> >>>>
> >>>>>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.
> >
> >
> I'm baffled. So this is a critical machine in a way (must be or you
> would be able to simply shut it down) and you have never looked into
> securing it, yet it is in a DMZ? And then you _found_ an intrusion, and
> now you decide to temporarily look the other way...
>
> There's an English word for that: STUPID
>
> (That said, I feel for the situation you're probably in, you are only
> asked/told to do as management wants to, and they care more for extra
> bucks in the short term.)
>
> I'll refine your calculations, maybe you should reopen the discussion w/
> boss-peoples.
>
> a) shut it down, lose money from customer X (Would the customer really
> be happy to know he's served stuff from a hacked box? And would it be
> impossible/so hard to boot a LiveCD of sorts and serve the content from
> there temporarily?
>

[..]
OK, you 'bout lost me on the "stupid" crack (although not off base,
admittantly.)
Technically I agree with you.
And until someone else also mentioned running the services off a CD OS,
I hadn't even considered that as possible.
Of course I've "looked into" securing it. I have IP-Cop managing the
IDS and I've blocked every port to it except 80. I kept yum checking
for Apache updates every day. And I tried installing snort on it... but
I haven't really figured out yet how to read the data it gives me. =/
The one really stupid thing I've done (prior to yesterday, thank you)
is try to use the included FC firewall manager instead of learn
IPTables.
IPTables scare me. I look and look through the Web for help and guides,
and the whole concept of who to write IPTables is like a whole other
language. There just doesn't seem to be any guides out there written
for people whose extent of networking and security knowledge is knowing
the difference between an IP and a subnet. All the IPTables guides and
help I can find assume you're already an expert it seems.
=/

[..]
> Or, do a raindance, take out your rosary and ask the good lord for guidance.
>
> Good luck, and may smart decisions follow!
> Sh.

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!

John Stumbles wrote:
> 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:
> >>
> >> ><q>
> >> >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.
>

Yeah, pretty much pounded into submission on that one. =)

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

Ah! I didn't see that. Will have to take a look. Will certainly make a
lot of things easier!!

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

OK, sounds reasonable.
Thanks for the reply! Really appreciated. =)

Unruh wrote:
> "news@celticbear.com" <news@celticbear.com> writes:
>
>
> >Unruh wrote:
> >> "news@celticbear.com" <news@celticbear.com> writes:
[..]
> >> rpm -Va|grep '^..5'>/tmp/verify
> >> to find all files which have changed since you installed them. (actually
[..]
> >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.
>
Yeah, I didn't think (duh!) until later to do that, man rpm that is. =/
For some reason I had it in my head that with the grep and sending it
to a file output for some reason that was a unique... nevermind. I just
wasn't thinking.

Would something legit and innocent cause non-config files to change?
Like if an RPM package that came on the distro was updated or
reinstalled using a source package? Or using yum to upgrade a package,
esp. from say FreshRPMs instead of the FedoraCore RPM server?

[..]
> >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/*)
>
Oh! Maybe that's one reason I'm having a pain installing tripwire. =/
What do you recommend to protect it? Copy that directory to CD or
something, then copy it back to do the -V?
Does a nightly yum update affect this? (I guess I can find out tomorrow
and see.)

>
> >[..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:
> >>
> >> ><q>
> >> >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
>
Ah, yeah. This whole thing has me rattled, I'm forgetting obvious and
simple things. =/
Thanks for replying!
I appreciate the feedback.

ray wrote:
> On Wed, 19 Apr 2006 02:32:57 +0000, Cameron L. Spitzer wrote:
>
> > In article <pan.2006.04.19.00.55.13.220395@zianet.com>, 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,
[..]
>
> 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
[..]

Thanks for the replies and advice guys!
Much appreciated!

In article <pan.2006.04.19.03.29.43.114181@zianet.com>, ray wrote:
> On Wed, 19 Apr 2006 02:32:57 +0000, Cameron L. Spitzer wrote:
>
>> In article <pan.2006.04.19.00.55.13.220395@zianet.com>, 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.

Maybe you've got a specially built Linux installation where
passwd(8) is a statically linked binary that just makes
kernel calls. On my systems, passwd is built
the same way everything else is, so it links at run time to the
common /lib/libc.so.6 which is a symlink to libc-2.3.2.so.
That's one of the executables most likely to be messed with,
because just about everything uses it.
Likewise /lib/ld-linux.so.2.
passwd is a pretty good candidate, too, because the
intruder may want to steal passwords as they are changed.

This intruder is most plausibly using a root kit, not starting
from scratch on this particular victim's box.
The first goal of the root kit is not to be detected.
The next goal is to *keep* control of the compromised box.
They've most likely messed with *every* utility you might
use to reclaim the box. That's everything you could use to
try to copy in uncompromised files from another machine.
Everything that might help you see the root kit's parts.
Everything you might use to change access authorizations.
Not just passwd, but /lib/libpam.so.0 and /usr/sbin/sshd.
That's what root kits are *for*.


Cameron



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