Why You Shouldn’t Allow root Login for SSH

/in , /by

A few years ago, a team of students and I did some research on my university’s honeypot network and put together a little presentation about what we found. For those not in the know, a honeypot is a purposefully exposed network system intended to either divert the attention of hackers from production systems or gather information about how hackers compromise systems and the tools they use to do it. While we did gather some information about various default ports that were scanned and attacked, the main focus of the project was on SSH. By using Kippo, a specially designed SSH honeypot service, we were able to acquire information about the usernames and passwords that were used to make SSH connection attempts, and see what commands were issued after a successful login.

The main takeaway regarding what we found is just how often root is used as the username in SSH brute force attacks. In fact, just over 64% of the SSH login attempts made on our honeypot were using root. I won’t be so brazen as to claim that 64% of the entire world’s SSH login attempts use root, but it is an alarming percentage even in a research scenario. If you could invalidate 64% or even half that percentage of attacks on your SSH-enabled systems, why wouldn’t you? Just why is root the low hanging fruit when it comes to attempted SSH logins? Well, it’s guaranteed to exist, and compromising the account gives you total and complete control over the system. Of course there are other ways to restrict SSH traffic using firewalls or VPN technologies, but if you aren’t very network savvy, disabling root access for SSH is a quick and achievable goal. Sometimes I think of the username as almost a sort of password. Of course a username is usually much easier to come across, since they are typically stored in plaintext or viewable by other users on a machine. But as far as a random brute force attack on an SSH service goes, it’s just another piece of information that the attacker isn’t likely to have in advance. So, feel free to create a custom account for SSH that isn’t something you’d expect someone to guess.

On the other end of the SSH login we have the password itself. The top passwords in use were very simple, as expected. “123456” was our top password, with “password” trailing behind in second place. “qwerty”, “test”, and “root” also make an appearance shortly after. It should go without saying that you shouldn’t use a simple password. Application and hardware-specific default usernames and passwords should also be changed or disabled–hackers and hacking tools take these into account.

Creating a strong password and restricting SSH access to specific users should always be one of the first steps to hardening an SSH service. Go forth and lock down your SSH service!

How To Use grep To Parse A Linux DHCP Lease File

/in , /by

If you’re using a Linux solution for your DHCP server, you can use cat and grep to quickly locate the IP address of a particular host based on their hostname. On our OpenSUSE Linux DHCP server, the DHCP lease file is stored at /var/lib/dhcp/db/dhcpd.leases. CentOS/Red Hat Enterprise Linux has the lease file at the same path minus the “db” directory, so it is at /var/lib/dhcp/dhcpd.leases. If we run a tail or cat on that log file, we can see some examples of a lease:

tail -27 /var/lib/dhcp/db/dhcpd.leases

This command will display the last 27 lines of the specified file, which happens to be the lease file in this case. The output we receive is seen below:

lease 10.10.0.216 {
starts 2 2013/06/25 00:03:59;
ends 3 2013/06/26 00:03:59;
binding state active;
next binding state free;
hardware ethernet 00:50:56:a3:44:2b;
uid “\001@l\217’\361\021”;
client-hostname “Frodo”;
}
lease 10.10.0.210 {
starts 2 2013/06/25 00:04:04;
ends 3 2013/06/26 00:04:04;
binding state active;
next binding state free;
hardware ethernet 40:6c:8f:27:f1:11;
uid “\001@l\114’\214\219”;
client-hostname “Bilbo”;
}
lease 10.10.1.1 {
starts 2 2013/06/25 00:08:09;
ends 3 2013/06/26 00:08:09;
binding state active;
next binding state free;
hardware ethernet 7c:6d:62:bf:87:e6;
uid “\001|mb\277\207\346”;
client-hostname “Aragorn”;
}

There are three leases for three different hosts shown above. Depending on your network there may be hundreds of leases, if not more, so searching  through them manually is a pain. Now that we know the format of the leases, we can use cat, pipe it to grep with some arguments, and find the IP address of a particular host using the hostname. Here’s the command we will use:

cat /var/lib/dhcp/db/dhcpd.leases | grep Bilbo -B 7 -A 1

In this command, cat will display the entire contents of a file on the screen, but then using the special character “pipe” (seen between “leases” and “grep”), we send the output of the cat command to the grep command. grep will print the entire line containing any string (text) that matches the string we supply. In this case, we have supplied the string, “Bilbo”, since that is the hostname we are hypothetically looking for. Without the -B 7 and -A 1 arguments, the output of the command would be only a single line:

client-hostname “Bilbo”;

But since we did use -B 7 and -A 1 arguments, we will receive the client-hostname line along with the 7 lines immediately above it and the 1 line directly below it:

lease 10.10.0.210 {
starts 2 2013/06/25 00:04:04;
ends 3 2013/06/26 00:04:04;
binding state active;
next binding state free;
hardware ethernet 40:6c:8f:27:f1:11;
uid “\001@l\217’\361\021”;
client-hostname “Bilbo”;
}

The curly bracket below the client-hostname line isn’t exactly important information–I’m just showing an example using both the -A and -B arguments. Finally, we’ll see how to display only the information we are looking for: the hostname and the IP address. What we need to do is use a grep command to match two different strings instead of just one. For that, we will use egrep, a special use of grep which allows us to use regular expressions. The command looks like this:

cat /var/lib/dhcp/db/dhcpd.leases | grep Bilbo -B 7 -A 1 | egrep 'Bilbo|lease'

It is the same command until the second pipe, where we use egrep to match both “Bilbo” and “lease”. Notice that this command uses single quotation marks. Now our output is nice and clean, and only relates the two pieces of information we care about:

lease 10.10.0.210 {
client-hostname “Bilbo”;

If we have more than one entry for “Bilbo”, the last one is the current or most recent entry. And that’s it for this article! Of course, if you had a client management solution which kept track of all client IP addresses, you wouldn’t even need to do this. But this method definitely beats walking a user through opening cmd.exe and typing ipconfig and reading you their IP address! You could also use a program like Angry IP Scanner to scan your network and resolve IP addresses to hostnames.

Are Shortened URLs Safe?

/in /by

Shortening a URL allows you to condense a long, obnoxious looking web address down to just a few characters and also allows tracking of visitors to that URL depending on which URL shortening service you use. But on the user side of things, do you really know what’s behind a shortened URL? With a normal link, you’re able to see where your browser will be directed by hovering over the link and viewing the information bar at the bottom of the window, regardless of what the hyperlink text is. While you don’t have any guarantee that you’ll end up at your intended destination and that your destination is malware free, you’re taking even more of a risk every time you click a shortened URL. Like most things in this world, shortened URLs are a trade off between convenience and security. For those links you find extra suspicious, try “unshortening” them with http://unshort.me before making that click. The site claims to be able to “unshorten” URLS shortened with the bit.ly, goo.gl, fb.me, t.co services and others. Will you use this before following every shortened link you want to click? I doubt it. But it can be handy for those links that you don’t quite fully trust. All it takes is one bad link and a browser exploit to compromise your security. Here’s to safe surfing!

How a Toshiba Copier DoS’d Our Network Using ARP

/in /by

A few years ago, I ran into an interesting networking problem. Some of our users at a particular site were reporting that they couldn’t connect to the network, and we quickly realized that it appeared to be a DHCP problem, as those users who were complaining couldn’t get an IP address. As we were checking the DHCP service, we realized that Windows XP computers weren’t being affected–it was only Windows 7 users who could not get an IP address. How strange!

I was quite the novice Wireshark user at the time, but since we had been using it in my university classes, I decided to fire it up and check things out from a packet level perspective. Part of the trace file I captured is displayed below and it has had all but the relevant packets removed for the purposes of this article.

dhcpissue

Shown here is a single DHCP exchange which resulted in the requesting client failing to hold onto the given IP address. The traffic from the DHCP client, a Dell Windows 7 computer, is colored green, while the traffic from our DHCP server is colored yellow. The gray packet is a response from the gateway for a request for its MAC address originating from our DHCP client. The packet marked in red is the evil packet–it came from the Toshiba copier on the network.

Up until packet 8, everything was going fine. In packet 1, our Windows 7 computer came alive, saw that he was configured for DHCP, and broadcasted a DHCP Discover packet on the network. Our DHCP server checked for an available IP address, found that 10.18.2.7 was free, sent an ARP broadcast to see if any clients were currently using that address, seen in packet 2, and then sent a DHCP Offer to allow our computer to have that address in packet 3. The Request and ACK in subsequent packets 4 and 5 finalized the DHCP process. Packet 6 displays our Windows 7 computer sending an ARP broadcast for the gateway’s MAC address, and packet 7 shows a response for that request from the gateway. In packet 8, a Toshiba copier also wants to know who has 10.18.2.7, and requests that the response be sent to 0.0.0.0, but that isn’t a valid IP address. Our Windows 7 computer gets the sense that something is wrong, and releases his IP address in packet 9. We are kicked off the network!

So, why was this happening? It turns out that the Toshiba copier was plugged into the network, but not configured with an IP address. So, the copier literally had an address of 0.0.0.0, which is bad! In fact, you can’t configure an IP address of 0.0.0.0 on most devices, as its a special reserved address. It happens to be the source IP address of DHCP clients before they receive a real IP address from the DHCP server. My guess is that, for whatever reason, this Toshiba copier likes to immediately update its ARP table whenever a new host is discovered on the network (i.e. whenever a DHCP process is completed). Unfortunately, its ARP request to tell 0.0.0.0 about the MAC address of the new client is read by that new client as a check to see if that IP address is in use. In other words, the new DHCP client thinks another client wants to use the address it just accepted, and so it releases it to avoid an IP address conflict. With this problem consistently occurring, our Windows 7 computer will never get an IP address. It’s worth stating that, in my personal opinion, Toshiba or the NIC manufacturer for the Toshiba copier dropped the ball here, as you shouldn’t be allowed to configure an IP address of 0.0.0.0 in the first place, and it definitely shouldn’t be the default setting out of the box.

I was able to replicate this issue on my personal VMWare test network using Nping, a utility that can generate custom network packets. Since this behavior is present on a virtualized Windows 7 machine, I have to conclude that it is not a response specific to Dell computers/NICs which is what we were using in our environment at the time. In fact, my guess would be that most modern OS’s would have a similar response to this situation. If you see this issue in the future, the immediate fix is to configure a real IP address on the device, physically disconnect the offending device from the network, or shut down the switchport that the device is connected to.

How To Use Multiple Google Accounts in Chrome

/in /by

I like to use Google Music while I’m at work sometimes, and I use it through my own personal Google account. Unfortunately we also use Gmail as our enterprise e-mail solution, and normally Chrome doesn’t like it when you try to sign into two different Google accounts in the same instance. The result is that when I try to log in to listen to Google Music it kicks me out of my work e-mail. I used to solve this problem by running Firefox and Chrome at the same time, but it’s a silly and inelegant workaround.

Thankfully, I’ve found that Chrome has a nifty feature that will let you run different instances that are attached to separate Google accounts. To access this feature, choose the menu button in Chrome, click Settings, and click “Add new user…” underneath users. You can choose an icon and “friendly name” for each user, like “work” and “personal”, and you also have the option to add a desktop shortcut for the account. After that, you’re prompted to sign into the relevant Google account. Once you have one or more accounts configured, you can always access your alternate accounts by left-clicking the icon at the top left of the Chrome window and choosing that account. If the account does not have a running Chrome instance associated with it, a new instance will be launched.

This setup allows me to stay productive at work while also being able to access Google Music. I hope this information helps you too!