Month: November 2016

SSH Start to Finish Architecture – Forced Commands

Last week, we covered SSH Key options that can restrict how a private key is used to connect to a server. One of those options was the “command=” option, which allows restricting the key to calling only one command, regardless of the command issued as part of the ssh connection attempt. There are actually several ways to enforce this.

You can do the public key “command=” option we already covered. You can also use the sshd_config settings to apply a ForceCommand option. This is most useful for applying the same kind of forced command scenario we described last week via a “Match User” directive. It’s also useful for applying an sftp-only situation to a given user, so that the only thing the user can do is transfer files. The option would look like this, if that is your goal:

ForceCommand internal-sftp

The user’s shell needs to be a valid one for this to work, since the forced command is invoked via “ -c.” This means a shell of /bin/false or /bin/nologin is a no go. Since you are forcing a command, this should be less of a problem, though.

Finally, there is also a way to force this command with ssh-keygen options when signing a key via the certificate authority system for OpenSSH, but we will go into more detail on that when we get to the CA stuff.

The force command options don’t allow running the user’s ~/.ssh/rc, so that would not be a work around that the user could use to hack this system. ControlMaster overrides the public key force command if the option is set after a master session has already been established, so you may need to terminate all ssh connections for that user after making changes that enforce restrictions, moving forward.

A lot of people grumble about the force command options, because they believe that a single key is needed for each command that gets passed, but there is actually a means for handling that. There is an environment variable that gets set when an ssh session that wants to call a remote command is used to connect while force command is in use for a user. That environment variable is SSH_ORIGINAL_COMMAND, and it retains the command that was requested. This means you could have a wrapper script that is your forced command, have it check this environment variable for sanity (are all of the commands in the list provided in our whitelist, or not? If not, log a rejection and terminate. If so, log the call and execute.) The variable is unset if the user just tries to ssh in without calling a remote command, so be sure to check for that if you go this route. Assume if the variable is unset/empty that they tried to log in for an interactive session, and handle that however you feel is best. I would assume “log a rejection and terminate” is better, though, since an interactive session can’t be restricted properly without a restricted shell, that may still be jail broken if misconfigured. Your own needs may vary, though. Just be very thorough in your design, and be sure to sanitize all input before executing, and you should be fine.

Thanks for reading!

Fun-Day Friday – Book Review and Recap of Week One of NaNoWriMo

So, before I get to the book review, I wanted to recap that November is National Novel Writing Month. I’ve written three full days thus far, and the word count comes out to:
Day 1 – 1804
Day 2 – 1924
Day 3 – 1683

Remember that the average minimum for each day is 1667 words, so I’m ahead of the curve, so far. Hopefully, I can keep up the momentum.

As for the book review, it’s really a set-of-books review. Last time I did one of these, I mentioned the Montague Portal series. I’ve read the rest of the books in the series, and I wanted to share my thoughts on them.

All of these books except the first one (already reviewed) follow a single person named Aidan Redding. She is a security officer for Montague Corporation, and she gets progressively better at her job as the stories progress.

In “Sticky Supersaturation” the premise is that the universe is a two dimensional space, so the laws of physics make everything sticky to the touch, tastes are bland, and so on. The lab gets overrun by some horny chipmunks that devour antimatter, and it all goes downhill from there. The antics are memorable, and the story takes a couple of twists before Redding saves the day. Again, my only complaint is that it was too short.

In “Forever Falls” the universe is literally on a cliff face with a never ending waterfall. Redding investigates the death of one of the researchers, ends up in some sky diving death defying situations, fights to survive, and gets her suspect in the end. Mostly because the suspect believed she was dead, and couldn’t handle himself when she showed up to announce his part in the murder. She only lost part of a hand for her efforts, though she also got a bit wind burned. This one is longer, labeled a “novella” and is almost just the right length for these kinds of stories.

In “Hydrogen Sleets” the universe is just like our own. The laws of physics are the same. The problem is, it’s right at the beginning of its birth, so most of the universe is composed of free floating hydrogen that hasn’t decided to form stars or other matter, yet. A space station is built for the research, and she gets a try at a political stint. As a liaison officer, she has to deal with both her boss from Montague, and the civilian Congolese workers on board. Politics play a big role in some of the tensions, but she manages to navigate her way through the issues without too much trouble. I mean, what’s a damaged hand (again) and almost getting crushed by super gravity, plus a nice jagged jab in the side among friends? Yeah, it went something like that. She gets sent back for medical leave (again) at the end, but gets compliments and reprimands in spades for her efforts. This was labeled a novel, and while short for one, it was pretty much the perfect length.

I hope more Montague Portal stories are forthcoming, because the concept is divine. I highly recommend all of these if you haven’t read them yet. I wonder if it would be too difficult to develop a tabletop RPG around the series. Hmm. Food for thought.

Hacker-Tool Hump-Day – OpenSSL

We’re skipping the LAN Turtle module that would have been show cased this week in favor of a short post. On the bright side, I got 1804 words written for my first day of NaNoWriMo 2016. On the less than shiny side, I’m oncall this week at work, and I’m short on time for the Wednesday post. So let’s get to it.

Today’s topic is a tool that some people may not realize can be used in the same vein as telnet, netcat, and socat for connecting to ports and testing them with manual manipulation of whatever the plain text protocol might be (such as HTTP or IRC, for example.) It can also be used to stand up a temporary SSL enabled service for testing how clients behave, similarly to how a netcat listener might be used.

To test connectivity, use the “s_client” module with the “-connect” flag. The target of the -connect flag should be an IP or hostname with a port, and separated by a colon. For example:
openssl s_client -connect google.com:443

Once you connect, you should see some information about the certificate along with a status code to indicate what the problem is if the certificate doesn’t meet expectations. It will then sit and wait for you to send whatever commands you might like just like a telnet or netcat connection would do. It handles the actual SSL handshake for you.

The listening option is the “s_server” module with the “-accept” flag. The target of the -accept flag is just a port number. Of course, the listening service should probably also be given a certificate to use for the listening connection, so use the “-cert” flag to pass a certificate to this command for use on the listening socket. You can set up a listening socket without a cert by using the “-nocert” flag, but this is kind of pointless.

Again, the primary focus of this for most people will be the s_client module, so that SSL enabled ports can be probed for banners and such. Alternatively, shell scripts can be written that call this in order to automate certain kinds of connections with intentionally malformed requests to test how the server behaves, or to pass known vulnerable requests to the server, and so on.

Of course, it can also be used to look at the server’s certificate and settings in case there is a vulnerability there, such as a weak cipher list, for example. Perhaps the certificate is due to expire, soon. A man in the middle situation might be easier to set up during that window between certificate expiration and certificate renewal if the site owner allows the cert to fully expire before renewing. Possibilities are almost endless.

That’s all for now. Thanks for reading!