October 2016 – Page 2

Fun-Day Friday – Children Are Sweet

So one of the things that defines who I am is my family. I started out life as an only child, but had cousins who sometimes felt more like brothers and sisters than cousins. When my mom re-married, I suddenly had lots of siblings, most of whom were already grown and gone with kids of their own, but I had one brother younger than me. Experiencing both “only child” and “brothers and sisters,” I knew I wanted to be a dad. I knew I wanted kids of my own. I also knew I wanted lots of them, and I was lucky enough to find a soul mate who feels the same way, and we have had seven beautiful children together. A friend in need who can not be there for her children for a while asked us recently to take on two more. This last weekend, we did just that, and they have been here for a full “business” week so far. We feel blessed and honored to take on this responsibility, and the kids are all doing pretty well. They already behave like siblings, with all of the ups and downs that entails, but they “click” more than they “collide.”

Children aren’t everyone’s cup of tea, but for me, there is nothing more important that family. I don’t have anything “fun” to share today, because I’m exhausted from the trip to pick them up, and the oncall phone from work being noisy this week, but I felt compelled to share a little piece of my life with you. I hope everyone finds happiness in all you do. Thanks for reading.

Hacker-Tool Hump-Day – john the ripper

Another quickie today. Before we get to the technical goods, I thought I’d share an update on the family situation. We have both “bonus” children home safe and sound, and everyone is settling in just fine. The hectic nature of the trip, and post-trip excitement has reduced the time I have to work on a good detailed post this week, so I apologize in advance for the lack of substance I may be about to present. I will review this post, and possibly do a more in-depth review of this tool to flesh out the details another day. On to the spotlight!

John the Ripper is a staple tool for cracking passwords. If you can get your hands on a set of hashed passwords, you can use this tool to make an attempt at cracking them. It does a fair job on any standard system, but some people build elaborate rigs to throw as much computing power at the tool (or a modified version of it for distributed cracking) to reduce the time it takes to crack some of the more complex passwords a user might set.

You can feed it a dictionary file, tell it to try different permutations of each word, and even brute force all characters in a set using various flags. Different people have different routines for running it, but my general work flow is to kick it off on one machine with a dictionary of common words, and on another machine with a brute force crack, and just let it hum. I don’t have an elaborate rig, and I’ve never tried to crack a password I wasn’t asked to crack for work purposes (outside of my own lab/gear, of course.) It can take a while to crack some passwords, but if you have the time and / or horse power, you can crack most password hash schemes. It can handle simple hashes such as what you might generate with OpenSSL, as well as Windows hashes such as NTLM.

Oddly enough, during my SANS Sec504 class, the one hash scheme I had trouble with was md5. I used another tool (Cain/Abel) on a Windows machine to crack that while john sat and choked on it. I think it was because of the version of john that was provided with the class materials.

Just a reminder that John is used for brute forcing / dictionary attacking an already retrieved set of password hashes. Other tools are often used to brute force passwords as actual login attempts to a machine. This is a better tool if you can get the hashes, because it doesn’t actually attempt to log into anything, and thus doesn’t lock out any accounts due to too many failures, or leave a bunch of failed login attempts in a log file somewhere.

And after all of that, I’m not showing any examples for this command for today’s post. I think I will definitely do a follow up article for that, instead.

Until next time, go hug a family member. Or a friend. Your imaginary one, if noone else will do.

SSH – Start to Finish Architecture – The Connection Flow

Before we get into any more advanced stuff with configuring SSH, I thought we should take a look at what actually happens when a client connects to an OpenSSH server, and what the decision tree is for granting or not granting access.

From the sshd man pages:
When a user successfully logs in, sshd does the following:
1. If the login is on a tty, and no command has been specified, prints last login time and /etc/motd (unless prevented in the configuration file or by ~/.hushlogin; see the FILES section).
~/.hushlogin
This file is used to suppress printing the last login time and /etc/motd, if PrintLastLog and PrintMotd, respectively, are enabled. It does not suppress printing of the banner specified by Banner.
2. If the login is on a tty, records login time.
3. Checks /etc/nologin; if it exists, prints contents and quits (unless root).
4. Changes to run with normal user privileges.
5. Sets up basic environment.
6. Reads the file ~/.ssh/environment, if it exists, and users are allowed to change their environment. See the PermitUserEnvironment option in sshd_config(5).
~/.ssh/environment
This file is read into the environment at login (if it exists). It can only contain empty lines, comment lines (that start with ‘#’), and assignment lines of the form name=value. The file should be writable only bythe user; it need not be readable by anyone else. Environment processing is disabled by default and is controlled via the PermitUserEnvironment option.
7. Changes to user’s home directory.
8. If ~/.ssh/rc exists, runs it; else if /etc/ssh/sshrc exists, runs it; otherwise runs xauth. The “rc” files are given the X11 authentication protocol and cookie in standard input. See SSHRC, below.
~/.ssh/rc
Contains initialization routines to be run before the user’s home directory becomes accessible. This file should be writable only by the user, and need not be readable by anyone else.
9. Runs user’s shell or command.

So from the above, we can see a few more ways to control our client connection and what it outputs when we connect. We looked at “LogLevel QUIET” in the ~/.ssh/config file last week, but we can also take advantage of the “.hushlogin” file to suppress some information.

We also see that the login gets logged only if there is a TTY associated. This is important to remember for forensics purposes.

We can temporarily disable logging into a system with SSH (other than root) by creating an /etc/nologin file, and the contents of that file will be displayed when the connection attempt gets rejected. It’s dangerous to use this if you don’t have console access, so be careful with it.

The service drops privileges and sets up a basic environment, then adjusts it from the ~/.ssh/environment file if it exists, and users are allowed to change their environment. The default behavior is to disallow this, but it’s something to check when locking down your systems. Finally, it changes to the user’s home directory to finish the environment preparations.

Next it reads and automatically runs the ~/.ssh/rc file if it exists. This is also important to know for forensics and for locking down your system. This is an excellent spot to drop a persistent misbehaving script, so it’s worth looking for and reviewing.

Finally, it runs the shell or whatever command was requested. Seems pretty simple, right? Well, the man pages stop short at that point.

So from a defense perspective, we want to review more than just the ~/.ssh/{config,authorized_keys,authorized_keys2,known_hosts} files. We also want to look at any rc and environment files in that directory. This is especially true of the root user.

Next week we’ll look at the sshd_config file and cover how to check the running configuration against the written config file.