am I NOT hacked?

Sat Apr 26 18:05:35 UTC 2014

Ok, thanks a lot for all your kind help.  I learned the pwd_mkdb manpage and the databases as you suggested.

To clarify, I understand 9.1 kernel contains the non-vulnerable version of openssl library, hence mere apache/https is not vulnerable.  However the vulnerable openssl port is installed for the mail software to provide imaps/pops/smtps services, so they are vulnerable.

The following reply is what I'm confused:
> In any case, heartbleed does *not* facilitate remote code execution or
> code injection, only information retrieval, so unless your passwords
> were stored in cleartext (or a weakly hashed form) in the memory of an
> Internet-facing SSL-enabled service (such as https, smtp with STARTTLS
> or imaps, but not ssh), you cannot have been "hacked" as a consequence
> of heartbleed.I ssh into the system, and I /usr/bin/su to become root.  Do my shell passwords show up in in clear text in the memory briefly, so the attacker could happen to harvest them?  In another word, on a system with the vulnerable openssl port, do we need to change the shell password for root and other users, if these passwords are ONLY used in ssh and /usr/bin/su ?

I googled and found few result, almost all are focused on changing user mail passwords and server certificates.  Only found this page said they changed server root password:

http://digitalopera.com/geek-rants/what-were-doing-to-combat-heartbleed/

Thanks, Joe

> From: bilbo at hobbiton.org
> Date: Sat, 26 Apr 2014 12:02:05 -0500
> Subject: Re: am I NOT hacked?
> To: jp4314 at outlook.com
> CC: freebsd-security at freebsd.org
> 
> Joe,
> 
> Just thinking about this practically, I don't think you were compromised.
> It seems more like you goofed the upgrade in the same way on each VM. Also,
> if I were attacking, I wouldn't leave such overt traces that one would
> immediately notice. And if the attacker were goofing up that badly, he'd
> likely not do it the same way on every VM. Not that assuming anything about
> an attacker's intelligence guarantees anything, but it does seem like an
> odd thing to do. Not to mention other's comments about pre-10 not being
> vulnerable, and local compromise requiring that your password or SSH key
> was read by a process serving SSL sockets.
> 
> If you decide it's likely your system was compromised while it was
> vulnerable, shutting off the system is a priority to stop ongoing damages.
> Then you have to mount its disks in a clean system so that whatever bad
> stuff (bots, backdoors, etc) the attacker added don't just start again at
> reboot, and to be sure the attacker doesn't merely add backdoors back while
> you take them away. It's hard to be sure you fixed every single file that
> was touched ...executables, dynamic libs, configs, and much more contain
> subtle ways to leave a back door, and one could even patch the kernel to
> hide a malicious process in memory. Starting from a fresh install and
> copying your data over is really the quickest and safest approach. Since
> "restore your data" usually means home directories, be sure to check
> everyone's .ssh/authorized_keys for unwanted entries before copying.
> 
> Try "man pwd_mkdb" for info on the password database; especially look under
> the "FILES" heading. It's a good subsystem to know more about anyway, and
> not complicated. It is perhaps easier to remember that using vipw to add a
> blank line will sync everything than to remember the cryptic "pwd_mkdb -p
> /etc/master.passwd" command though.
> 
> Actually having a machine compromised is no fun; I've been there. I do hope
> that's not the case for you.
> 
> - Leif
> 
> 
> On Sat, Apr 26, 2014 at 4:55 AM, Joe Parsons <jp4314 at outlook.com> wrote:
> 
> > I was slow to patch my multiple vms after that heartbleed disclosure.  I
> > just managed to upgrade these systems to 9.2, and installed the patched
> > openssl, then started changing passwords for root and other shell users.
> >  However I realized that, only the root password was changed.  For other
> > users, even though the "passwd userid" issued no warning, and "echo $?" is
> > 0, the password is NOT changed.
> >
> > For more debugging, I tried to "adduser", the command was successful, and
> > I can see the new entry "test" in /etc/passwd. However "finger test"
> > complains no such user!  Also, "rm test" complains there is no such user to
> > delete as well.
> >
> > Furthermore, the mail server got problem sending email, the log file said
> > there is no such user "postfix", and sure enough:
> >
> > # finger postfix
> > finger: postfix: no such user
> >
> > while this "postfix" user certainly existed for years, and I can see see
> > its entry in /etc/passwd.
> >
> > This appeared to all the multiple vms on multiple hosts, all running
> > FreeBSD 9.2 now.
> >
> > I was paranoid, I really should have patched all these systems immediately
> > reading that heartbleed news, as all these servers had the vulnerable
> > openssl port installed!
> >
> > Until googling and I found this:
> >
> > https://forums.freebsd.org/viewtopic.php?&t=29644
> >
> > it said "The user accounts are actually stored in a database. It's
> > possible it got out of sync with your [file]/etc/passwd[/file] file.", and
> > it suggested running "vipw" to fix it.
> >
> > I ran vipw, then saved, and quit.  No joy.  Then ran vipw again, made a
> > change, then undid the change, save again.  Now "finger postfix" found the
> > user, and I can change user password now, and all the above problem
> > disappeared.
> >
> > Am I right that, that I am NOT hacked?  Is the above problem produced by
> > the freebsd-update process?  Is this supposed to happen?  I just followed
> > the handbook to update from 9.1-RELEASE to 9.2-RELEASE, never compiled
> > kernel or tweak.
> >
> > Thank you!  Joe
> >
> > _______________________________________________
> > freebsd-security at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-security
> > To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org
> > "
> >
> 
> 
> 
> -- 
> 
> As implied by email protocols, the information in this message is
> not confidential.  Any middle-man or recipient may inspect, modify,
> copy, forward, reply to, delete, or filter email for any purpose unless
> said parties are otherwise obligated.  As the sender, I acknowledge that
> I have a lower expectation of the control and privacy of this message
> than I would a post-card.  Further, nothing in this message is
> legally binding without cryptographic evidence of its integrity.
> 
> http://bilbo.hobbiton.org/wiki/Eat_My_Sig
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"