Month: October 2016

SSH Start to Finish Architecture – Public Key Options

Since we’ve introduced a few ways of doing tunneling, I thought now would be a good time to bring out some ways of restricting what a user can do in the event that they have access to a private key they shouldn’t.

We already talked about setting a pass phrase on the private key side, but there is still the chance that the user was able to brute force that, so let’s assume they have usable access to that private key. What options do we have for keeping things secure?

For starters, we can restrict which source IP/DNS names a user can come from using this key. If we modify the public key entry in the authorized_keys file to include a “from” directive before the key starts, we can provide a list of IP addresses/hostnames we expect to be coming from. This prevents an attack from the user’s workstation, for example. One caveat of this is, you can’t be coming through a source NAT, since that would reduce the effectiveness of this restriction. Everyone coming into the box from a source NAT VLAN or subnet would look like they are coming from the same place.

In order to set this directive, we will need to modify the public key by hand. It’s better to modify the public key before adding it to the authorized_keys file, but you can modify the authorized_keys file entry for this key, if you prefer.

To use this directive, we need to put the a “from” option with all of its values, comma separated, BEFORE the key starts. An example of how this might look follows:
from=”172.16.84.1,lanturtle,lanturtle.mydomain” ssh-rsa AAAA User_A@lanturtle

Now, let’s assume you also want to prevent proxying with this key. In order to restrict that, we need to set several options:
no-X11-forwarding – Prevents forwarding X11 sessions back to an X server via the SSH tunnel.
no-port-forwarding – Prevents port forwarding via TCP, TUN devices, and direct stdin proxying.
no-agent-forwarding – Prevents “forwarding” of the ssh-agent for handling the private key.

To add these to the example above, we would use a comma separated list of options like this:
from=”172.16.84.1,lanturtle,lanturtle.mydomain”,no-X11-forwarding,no-port-forwarding,no-agent-forwarding ssh-rsa AAAA User_A@lanturtle

We can further restrict this to only allowing this particular key to be used for running a specific command. Doing this ignores any commands passed by the user upon connection, and prevents the user from obtaining a full login shell (unless that’s the forced command.)
command=”/usr/local/bin/ssh-restricted-command.sh” (where “/usr/local/bin/ssh-restricted-command.sh” is the command you want it to run. Put the actual command you want to use, here.)
from=”172.16.84.1,lanturtle,lanturtle.mydomain”,no-X11-forwarding,no-port-forwarding,no-agent-forwarding,command=”/usr/local/bin/ssh-restricted-command.sh” ssh-rsa AAAA User_A@lanturtle

Finally, if we want to be sure that there isn’t a land mine waiting on the user’s .ssh/rc file, we can tell it to not read this by using the following option:
no-user-rc
from=”172.16.84.1,lanturtle,lanturtle.mydomain”,no-X11-forwarding,no-port-forwarding,no-agent-forwarding,no-user-rc,command=”/usr/local/bin/ssh-restricted-command.sh” ssh-rsa AAAA User_A@lanturtle

When we get into managing a certificate authority, you’ll find that these options can be set by ssh-keygen for certificate related keys, but the option names are slightly different. Unfortunately, using ssh-keygen to generate the initial public/private key with these options doesn’t work. It only works on certificates. Modifying the public key entry by hand does restrict this, however.

We will go into more detail about the forced command option (and setting one in sshd_config) next week.

Thanks for reading!

Fun-Day Friday – National Novel Writing Month (NaNoWriMo)

Since this is the last Friday before November gets here, I thought I should bring this up. November is “National Novel Writing Month.” That’s NaNoWriMo for short. I’ve attempted to participate in this event year after year, and always gotten sidetracked or overwhelmed before completing a novel. Except for last year. That’s the first year I’ve ever actually made it to the end and come out the other side with a finished first draft novel.

I’m considering making another attempt at it this year. In case some of you dear readers are also aware of this month and are chomping at the bits to take a stab at it, here’s what helped me last year.

1) I used a site called 750words.com to help me track my words per day. You should probably do something similar. It was the greatest factor in helping me finish. Remember that if you intend to write “the bare minimum every day” that comes out to an average of 1667 words each day.

2) I finally let go of perfectionism. You can’t “write” and “edit” at the same time. The goal is to just write. The months AFTER NaNoWriMo are for editing. What you write might be, (okay, let’s face it… probably WILL be) a turd, but you will have plenty of time to turn that crap into something useful (like fertilizer or compost) AFTER you produce it. Just focus on the writing, and don’t worry about mistakes.

3) If you’re struggling with plot, write a few random sentences in a note pad and let one of those give you a sudden change in direction for your plot. You don’t have to know the gory details, just the broad overview of where you want to go with the story. As long as you can keep a good pace (both writing, AND within the story itself,) things will work out in the end.

4) It’s hard. It will be tough to maintain the pace. That’s okay. Do it anyway. Stay up late, get up early, whatever you have to do to find some extra writing time, do it. BUT more importantly than this…

5) Write at the SAME time every day if you can. Setting a schedule for your writing forms habit. Habit leads to eventual success.

6) Finally, “have fun with it.” It’s okay that what you write may be terrible, but remember this: There are books with story lines that are almost guaranteed to be worse than your own, and people have paid to read them. (Just google “Thorfinn Viking Vampire” at some point, and look at the books that pop up.)

Hopefully, everyone will be feeling much much better by the end of this month, so that I can do this. If not, I may have to choose between NaNoWriMo and UnixSecLab. If I have to choose, the WriMo is going to lose.

Are you planning to try for NaNoWriMo this year? Leave a comment below, and keep us updated on your progress!

Hacker-Tool Hump-Day – LAN Turtle Modules – netcat-revshell

Since we’ve covered netcat in the past (briefly,) this is a good module to jump in on for today.

This module creates an outbound netcat connection to an already listening netcat remote listener, and presents a shell to that connection. It almost sounds backwards, but here’s the set up.

Before you configure this module, you need a shell account on a target box that also has netcat installed. For my example, the box is OpenBSD based, so the “netcat” is “nc” and has all of the flags I care about by default. We’ll call this “Server_B” since you’re connecting to this as a target. The first step is to get the IP address of the server. An “ifconfig -a” shows all of the interfaces, or an nslookup of the domain name should get this for you. If it has multiple interfaces configured, you can check the routing tables with “netstat -nr” and look for the default gateway to figure out which IP belongs on that subnet. Whatever the case, the LAN Turtle needs to be able to talk to that same network from its ethernet jack.

For our purposes, we’ll assume the IP was 192.168.0.7.

We also need an available port. “netstat -an | grep LISTEN” will show the ports already taken. For this example, 8080 is free, so we’ll use it.

To set this up, run the following netcat command:
nc -k -l -v 192.168.0.7 8080

Now switch to your LAN Turtle interface, and go to the Modules menu. Select the netcat-revshell module and go to “Configure” to toss the IP and PORT into the fields. After you back out, you can hit “Start” and you should see activity on the netcat listener you started on Server_B. In our example, we got this line:
Connection from 192.168.0.174 58624 received!

Remember that the listening netcat process was just presented a shell back into the LAN Turtle. You won’t see a prompt, because it’s not a proper login, so your environment isn’t set up. However, you should be able to type commands and get responses back. For example, “uname -a” returns this:
Linux turtle 3.10.49 #7 Thu Jul 16 05:05:51 PDT 2015 mips GNU/Linux

You can stop the reverse shell at any time from the Turtle, using the menu option. If you “Enable” this, it will make an attempt at creating that reverse shell on start up next time it is plugged in or rebooted. In other words, if you want this to persist, you’ll need to keep the netcat listener running on that target box all the time.

The benefits to having this are the speed and efficiency in setting it up for getting a shell back into the Turtle from the LAN side of the interface. For example, if you plugged the Turtle into a USB power adapter, but wanted to be able to get into it for further configuration and work, you would want this module or one like it to present that shell for you. It’s not fancy, but it gets the job done.

The Hak5 LAN Turtle is a versatile tool for any hacker (or system’s administrator) to have on hand.

SSH Start to Finish Architecture – Tunneling IP with TUN device

We’ve covered the various tunneling / proxy capabilities of OpenSSH for tunneling TCP and setting up port proxies, but the “-w” flag can let you forward IP traffic. This happens by way of creation of a temporary “tun” device upon SSH connection, which can be configured like any network interface by standard tools such as “ifconfig.” There is some post connection set up that has to happen, including modifying route table information, so treat this like a right and proper VPN solution. That’s what it is meant to be. A VPN solution built into the SSH client and server software. I will do a proper write up with lab and examples later. For now, know that the server has to have the “PermitTunnel” option set, and it must be set to a value other than “no,” which is the default value.

The options are:
point-to-point – This allows a Layer 3 tunnel device to be configured.
ethernet – This allows a Layer 2 tunnel device to be configured.
yes – This allows either device type to be configured.

When connecting to the server, you need to pass the “-w” flag and provide a tun device id. You can also provide the remote tun device id. If you provide no remote id, it defaults to “any” which provides the next available. You may also specify “any” for the local tun device id.

The following example sets up a specific “tun0” on both the local and remote side.
ssh -w 0:0 User_B@Server_B

The following will set up a “tun” device using the next available ID on both the local and remote sides.
ssh -w any:any User_B@Server_B

The following will do the same as the example above, but saves 4 characters worth of typing.
ssh -w any User_B@Server_B

Just setting these up will not be sufficient. You will also need to configure the routes/interface information, of course. You will also need to configure any bastion host (local firewall) traffic rules as well, if you’re running one. The best explanation for this I’ve found is here:
Daemon Forums

When I do this as a lab exercise, I will show all of the detailed configuration for both the server set up, and the client set up. I feel like I half dropped the ball on this post for not having the lab set up already, but I think I got enough of the general overview across that this should help anyone interested in trying this out at least get started. We’re all still a little under the weather in the house, so a proper lab will have to wait, but I promise it will be done for this series before I am through.

Thanks for reading!

Fun-Day Friday – Guild Wars 2 Halloween content

I spent more time at home this week than at work, due to the heavy coughing fits from my sinuses being flared up. This has been a light week on the content, because of it. My apologies, again.

Last Tuesday, Guild Wars 2 released the Halloween content for this year. They added a track to the world vs. world rewards, brought back the labyrinth, clock tower, and other goodies from years past, and introduced a few new weapon skins. I was very much hoping for a return of some way to obtain the backpack items from the first year content, but maybe they’ll do that next year.

My wife doesn’t play this game often, but the Halloween and Wintersday content are both content we enjoy, so I’ll be spending some in game time with her.

Halloween is my favorite holiday of the year, so this content always gets me excited. Hopefully, I’ll feel better soon so I can enjoy it more than just a grumble and a hazy stare’s worth.

Is there a game you enjoy playing? Online, board, card, etc? Share in the comments!

Hacker-Tool Hump-Day – LAN Turtle module(s) – cron and uptime

I’m covering two modules, just because of the sheer shortness of the content.

The “cron” module’s “configure” menu is a raw interface to essentially “crontab -e.” In other words, you have to put in the cront entry by hand, using the crontab format you would use on the majority of standardized cron systems across the land of Unix in general. After you add all of the entries you want, you can “start” and/or “enable” as per any other normal module for the LAN Turtle. This will get your cron jobs loaded and ready to kick off whatever scheduled tasks you intended it to run.

minutes hours day-of-the-month month day-of-the-week command-to-run

The “uptime” module doesn’t need the “start” or “enable” menu options. The “configure” menu option simply displays the system uptime to the user.

I feel bad for cheesing out on two of the really short module topics, but I have a wicked cough still. I’ll try to pick a more exciting module to cover next week, I promise.

Thanks for reading.

SSH Start to Finish Architecture – TCP Forwarding of STDIN/STDOUT

Last week we covered the standard TCP forwarding flags: -L, -R, and -D.

I explicitly held off on showing -W and -w, because I felt they deserved their own coverage.

We’ll cover the -w (dealing with tunnel devices) next week. This week is all about -W. Before we continue, you should note that one of my Wednesday posts was a brief overview of the netcat family of tools. If you think of “-W :” as a built in netcat for ssh, you’ll grasp the power of this flag pretty quickly. The most common example given for using this flag is the use of the ProxyCommand option to call SSH against a jumphost, and passing this flag to that host. The old way of utilizing ProxyCommand in this fashion was to actually call netcat as the remote proxy command, like so:

ssh -o ProxyCommand=’ssh jumphost netcat target_server 22′ target_server

Or if “Server_B” is our jumphost and we want to actually end up on “Server_A” by utilizing “Server_B” as a proxy, we would do it like this:
ssh -o ProxyCommand=’ssh Server_B netcat Server_A 22′ Server_A

That was all well and good, if netcat was actually installed, but sometimes it wasn’t. Luckily, SSH has its own built in netcat of sorts, via the -W flag. To do the same thing as above, we would do this, instead:
ssh -o ProxyCommand=”ssh -W %h:%p Server_B” Server_A

This is shorter, cleaner, and doesn’t rely on netcat at the jump server proxy point. Now let’s take this a step further. Let’s assume you want to pull a page down using command line, and you want to proxy through Server_B to get that page from Server_A.

echo “GET /some/page.html” | ssh -W Server_A:80 Server_B >page.html

Why might you want to do this? If you don’t have a direct route to Server_A on that port, but you can get to Server_B via SSH, and IT has access to Server_A on that port, you have a quick and dirty makeshift proxy.

Let’s sideline this thought process for a moment, and think about how many people try to lock down local accounts (stored in /etc/passwd.) Many people will give an account the “/bin/false” process as the “shell” to prevent logins to a shell. However, if you never actually attempt to get a shell with that account, you can use that account to proxy around all day long with the default sshd_config settings. If you want to disable this functionality, (and you should consider it, for the reasons demonstrated above,) you should set AllowTCPForwarding to “no” in the sshd_config file, and restart sshd.

There is a conversation floating around on social media right now about the Internet of Things botnet that took down Krebs’ blog, recently. One of the security vendors has suggested that an attack they are calling “SSHowDowN,” and this kind of functionality is exactly what they are referring to.

This kind of thing is really cool, when used correctly, but it’s also dangerous for poking holes in router and firewall access control lists.

If you have any experiences with this you’d like to share, leave a comment!

Fun-Day Friday – Book Review – No More Lonesome Blue Rings

No More Lonesome Blue Rings – Book Review

If you haven’t figure it out by now, I’m a huge fan of Michael W. Lucas as a tech writer. The thing is, he also writes fiction, and his fiction (so far) is just as amazing. I’ve purchased and read both books currently available in the Immortal Clay series (Immortal Clay, and Kipuka Blues.) These two books are an excellent length for a short novel, and the premise of their story is engaging. I will probably do a review on each or both at some point in the future.

However, today I am going to review a very short book entitled “No More Lonesome Blue Rings.” This book is in a collection of books called the “Montague Portal” series. I’ve been sitting on the fence about snagging these books, because I am currently in the middle of a rather large tome from another author. That said, I receive this book as part of my “thank you” package for sponsoring the PAM Mastery book at the level it needed to be sponsored (in my humble opinion.) I’ve been asking him off and on randomly for a few years now to write that book, so as soon as I saw the sponsorship go live, I pulled the trigger on it with much gratitude and enthusiasm. Apparently, I “oversponsored” in Mr. Lucas’ opinion, so he sent me some extra books when the print copy became available. “No More Lonesome Blue Rings” was among the books received.

I was surprised at how short some of these books were, so I set aside my current reading project, (“”) and did some research on what the reading order should be for the Montague Portal series. Since this was the first one listed, it’s the first one I read. It took me an evening.

The book only has 58 printed pages, but the story moves at a pace that makes it hard to put down. The main character, Sherry, has a genetic disease that causes deteriorated nervous system function. The Montague Corporation has found a way to open portals to alternate universes, and among those is one where the disease is “paused” while visiting it. Sherry has been sent there to help manage her condition. The book is written in a perspective that mostly focuses on her internal dialogue. She is very coherent and intelligent, but she can’t communicate or move around well due to her condition. All of the patients diagnosed with various diseases wear a colored band to indicate which disease group they belong to. All of them wear a red band, except Sherry. Her’s is blue. This partially explains the title of the book.

Without giving away the details (because the story is so short, I don’t want to ruin it for anyone,) the general gist is that she ends up on an adventure to save herself and her best friend from an attack by the local inhabitants, ends up surviving her encounter, and manages to improve her situation with the Montague Corporation overseers without losing her humanity.

The only complaint I have is that the story was too short. I love the premise of the Montague Corporation Portals to other Universes, because the possibilities for different stories is endless, but everything gets tied together neatly in the end.

I’m looking forward to reading the next book in the series, (“Sticky Supersaturation.”) I anticipate that all of the books in this series will be well worth the read, but I recommend this book on its own merits, even if it is a touch short.

5 out of 5 stars for content and premise.

Hacker-Tool Hump-Day – Lan Turtle Module – autossh

Today, we’ll go over one of the simplest modules provide for the Hak5 LAN Turtle. The “autossh” module is used to create an ssh session from the Turtle out to a pre-designated target server, and use the SSH proxying features to present a port for logging back into the Turtle over this tunneled proxy connection. This can be used in an environment that allows outbound SSH connections to create a connection into the internal LAN via some outside listening system. While there might be legitimate uses for this, make sure you follow corporate policy on such things before taking advantage of this feature on your work network.

To set this up, go to the Turtle shell (menu) and select:
Modules => autossh => CONFIGURE.

There are three fields that need to be filled in. The first is the “User@Host” field, where you put the target user and the target hostname or IP address for logging into the remote system. In order to make that outbound connection, the Turtle needs to know who to login as, and where to login at. This is how you tell it that.

The second field is the “Remote Port” field, and defaults to 2222. This is the port that will get established for the “dial back in via the proxy” tunnel.

The last field is the “Local Port” field, which defaults to port 22 and is fine to leave as is.

After you configure the ports, you can try to use it right away by telling it to “start,” but I generated a key pair and pushed the public key out to the target system from the command line when I tested this. I don’t think it will work without setting up a key manually, first. The Turtle does include “ssh-copy-id” if you prefer to push your key that way, and “ssh-keygen” to generate that key, but the key type should be RSA and use the “id_rsa” default naming scheme. This appears to be hard coded within the module. If you prefer a different key type, you’ll need to modify the module script to call a different key. The script is at /etc/turtle/modules/autossh if you’re looking to customize this.

After you’ve pushed your key and set up the “config” options, you can go back to the Turtle shell (menu) and select the module again, then select “START” instead of “CONFIGURE” to test it. Log into your remote target machine and see if you have a listening port per your “Remote Port” setting (default 2222.) If you do, you can try logging into the Turtle from that machine by doing “ssh -p 2222 root@localhost” (replace 2222 with whatever port number you chose to use if you overrode this default value.) You should be able to connect. If it works as expected, you can go back to the Turtle shell (menu) and select the module one more time, this time to “ENABLE” it. This will make it autossh every time the Turtle is rebooted (or powered on.)

This is equivalent to using the -R flag discussed on Monday.

Disable it when you’re not intending to use it, though. If you’re not getting the expected connection back into the Turtle, make sure there’s not a conflicting service using that “Remote Port” option you chose. If there is, change it to a port that’s not in use. Also check that firewalls aren’t blocking that port per standard troubleshooting techniques (netstat, telnet, etc.)

That’s it for this week, folks. We’ll probably cover another module next week, but with the new kids, the schedule might change without warning.

Thanks for reading!

SSH – Start to Finish Architecture – TCP Tunneling

One of the great benefits of SSH is the ability to create port forwarding redirects for temporary access to a system that otherwise might not be able to access a machine. This is really easy to set up, and works quite well for many scenarios, but the downside to this is… it’s really easy to set up and works quite well for many scenarios you might not WANT it to work for. This can be used to punch holes in firewall rules, and that can get you in hot water with the wrong people, so make sure you understand your corporate policy before attempting to use anything like this at work.

SSH provides several kinds of TCP port forwarding, so we’ll cover them one at a time.
We will NOT be covering the tunneling of “TUN” devices via the -w flag this time. That will be covered at a later date.
We will also NOT be covering standard input/output forwarding via the -W flag this time. This is only going to cover TCP forwarding.

The first type of TCP forwarding we will look at is the Dynamic Port Forwarding (using SOCKS4/SOCKS5 protocol.) The flag for this is -D and takes an optional “bind_address” and a required “port” be passed to it.
-D [bind_address:]port

This creates a listening socket locally on the provided port and optionally the given bind_address that will act as a SOCKS4 / SOCKS5 application-level proxy. It’s best to set this up to bind to localhost, and then use one of the other tunneling options to point to this in order to protect the proxy from users you don’t want using it. Of course, anyone that can access the machine via ssh, will be able to use this, so be selective about where you set this up. Any application that is SOCKS aware may take advantage of this, as long as it can hit the listening port.

The next two options are really the same thing, but one sets up a listening port on the local (client) machine, and the other sets up a listening port on the remote (server) machine. The flags are -L and -R, respectively.

-L [bind_address:]port:host:hostport
-R [bind_address:]port:host:hostport

When you want to forward a local (client) listening port to the remote machine, use “L” for “local.”
When you want to forward a remote (server) listening port to the client machine, use “R” for “remote.”

In other words, that “listening port” is bound either locally, or remotely, and is one end of the tunnel. The “host” and “hostport” are not necessarily the same as the destination server you are connecting to with SSH. They just have to be a host and port that the remote system can actually get to.

“-L 8080:example.com:80” would bind a local port 8080 to the client when it establishes the connection to the remote ssh server. Then the remote ssh server would tie a connection to port 80 at example.com on its end. From there, you should be able to connect to port 8080 locally on your client machine, and talk to that remote example.com server on its port 80, all tunneled via ssh to the ssh server.

“-R 2222:localhost:22” would create a listening “localhost” bind on port 2222 on the remote server, that points to port 22 on the local client. If you were to connect outside of your network with this, it would allow people outside of the network to ssh in from that remote machine, assuming they have the correct credentials.

All of these options as given create a shell on login. You can establish JUST the tunnel by using the “-N” “-T” and “-f” options.

“-N” says to not call a remote command, just establish the tunnels.
“-T” says not to establish a pseudo TTY (PTY) terminal, which is appropriate since you aren’t passing any commands.
“-f” says to background ssh, since you probably want to do more work after the session is established.

ssh -fNT -L localhost:8080:google.com:80 User_B@jumphost

This says to background ssh after establishing a tunnel, and don’t allocate a PTY. Establish the tunnel with a locally bound port 8080, and have the remote ssh server “jumphost” establish a tunnel to “google.com” on port 80. Connect as User_B to the ssh server.

You can check with “netstat -an | grep LISTEN” to see if you have a listening port 8080 after establishing this. You can test the tunnel with netcat or telnet to localhost on port 8080 and enter “GET /” then hit enter. You might need to hit enter twice, depending. You’ll have to replace “User_B” and “jumphost” with an actual system you have access to, that also has access to the internet, of course.

I hope this didn’t muddy the waters more than it cleared them up a bit. If so, let me know in the comments, and I’ll try to clarify later.