Author: Stefan

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.

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.

Fun-Day Friday – Sad News and Happy News

So today, I’m not going to go over any of my hobbies other than to mention that one of them is called “Permaculture.” It’s a design science driven by a specific set of ethics to improve the land and grow abundance (food, friends, and fun.) The ethics state that any decisions made when designing a system should first consider whether the actions taken will harm the earth. If they do not, then consider will they harm people. If neither the earth, nor the people are harmed, then finally take care to build in a balance such that you limit growth of any one element of the system such that it will not consume more than it should. This last ethic is often misunderstood, and is often represented as “if you have abundance, you should freely share it with others, and not charge anything for your efforts.” In other words (using the misunderstood third ethic,) they are often summed up as:
earth care
people care
fair share

The first two are pretty accurate. The last, not as much. It is good to share abundance, but there is nothing wrong with getting something in return for your efforts.

I digress. The sad news for today is that one of the founding fathers (and the most well recognized of them) has passed away. Bill Mollison died on September 24th. He gave a great gift to the world by sharing his experiences and ideas about how to better grow food, and it is a sad day knowing that he has passed on.

The happy news is that we are expanding our family via a foster care situation. A friend of the family has asked us to step in while she is away for a while, and we are happy to do so. We have seven children that are excited to meet their new foster-ish siblings, and this weekend should be exciting, since we are meeting them and bringing them home.

There’s nothing more important than family, and sometimes family is who you CHOOSE, not who you share blood ties with. My great wisdom to share for today is this: (in the words of one of my favorite authors, Michael W. Lucas) “Go do something in meatspace.”

Hacker-Tool Hump-Day – netcat

I was planning to do a continuation of the LAN Turtle exploration and experimentation today, but I’ve had several delays on getting my posts written. Friday’s post will explain a bit more on that. To keep things somewhat short and sweet, I decided to cover one of the Swiss Army knife tools in a hacker and/or a sysadmin’s pocket: netcat.

There are several versions of this program available, and they all have varying degrees of functionality, but for the most part you can expect that it will allow for at least a “one connection” listening socket function, and at least a “one connection” talking sending socket function. In other words, you can open a listening socket to receive one stream of information, or to send one stream of information. Usually this is terminated by an EOF (end of file) character. Some versions will keep the listening socket (when acting as a server) open. Some versions need to be placed inside a while loop to re-open that listening socket for persistence. Some versions allow for binding the output to a specific command, while others require some effort of juggling file descriptors to achieve the same kind of goal. Whatever version you have, it’s a handy tool for both troubleshooting, and swift involuntary copying of data (exfiltration.)

The command may be called “netcat,” “ncat,” or “nc,” depending on the version. To my knowledge, all versions have a “-l” flag for listening as a service, so the easiest example is to create a listening service on a port on one host, and then connect to that port from another host to send some information.
On host 1 (host1):
netcat -l 1234
On host 2 (host2):
cat somefile.txt | nc host1 1234

This will send the contents of “somefile.txt” to the standard out of the listening service on host1. You can redirect the output on that listening service to a file, if you like. Once the EOF is reached, the listening service will terminate.

If you have a version that has the “-k” flag, you can use this flag to keep the service open to receive more data even when the “client” has finished sending and terminates its connection.

netcat -k -l 1234

If you want to send or receive UDP packets instead of TCP, you can use the “-u” flag.

If you want to bind it to a process (usually a shell) and the flag is available, you would use “-e” for this.

netcat -k -l -e /bin/bash 1234

You won’t get a full login session doing it this way, so no prompt or any other indicators that you have a shell once you connect. You’ll have to learn to get used to this, but it’s not bad.

When the -e flag isn’t available, you can do something similar using redirects and a FIFO (also known as a named pipe.)

mkfifo /tmp/namedpipe
nc -k -l 1234 0/tmp/namedpipe

I will most likely go more in depth on this command later (especially when I get to the netcat module in the LAN Turtle,) but for now, this covers most of the basics a person might want.

I will also cover netcat’s beefier brother “socat” at some point down the road.

If you enjoyed this, leave a comment or hit me up on Twitter @stefanrjohnson