Tag Archives: Information Security

…but what about those printers?

Reprinted from my post at the now defunct IT risk management blog at UBC Sauder School of Business.

Given that we’re still not quite to the elusive paperless society so many futurists and technologists have promised us, our offices and homes have printers. Some of our offices have lots of printers and lots of different printers at that.This brings me to an interesting question. Have you considered your printers in your information security practise?

Now at this point, you might be laughing at that idea. After all, printers print things and not much more aside from the odd print/scan/fax/copy multi-function unit, which also doesn’t sound very scary. Right? The truth is, however, that printers are really computers in and of themselves and (if network printers) run network services, such as web serving, FTP, telnet, and others, in addition to their regular printing duties.

The rationale mentioned above leads many organizations to pay very little attention to their printer fleets and how they are configured and managed, which can be quite dangerous.

What’s dangerous for them is fun for hackers auditors. So let’s take a quick look at how it’s done! The following is a bit technical though not vital to getting the gist of this post so feel free to skip it if you wish.

Printers can be found on a given network with a simple port scan. Here’s what such a port scan looks like using the popular Nmap utility:

nmap -sS -p515,9100 192.168.1.*

What this line does is instruct Nmap to scan the entire 192.168.1.0 network for services listening on ports 515 or 9100 — ports commonly used for print services.

Once the printers are identified, one can begin probing further. Another scan against the printers for port 23 will reveal if telnet is running. If it is, you can attempt logging in to the printer via telnet. If you can get in via telnet, you can do all sorts of things, as detailed here and elsewhere, such as find information printed, faxed, or copied for a start.

If FTP is running on the machine, it can be used to store and serve files. As such, printers are used for hiding files on the network or run a somewhat stealthy file sharing server.

Most network printers these days have web servers for web based configuration and they are all too often left with no password protection enabled or have only default passwords. Once in to the web configuration console, any of it’s settings can be changed (many of these things can be changed via the telnet command line interface as well).

Lots of shenanigans are possible in exploiting printer security like changing the display and banner messages, putting paper clip images on every page so people think there is a paper clip stuck in the machine, or sending scan jobs to random users.

While much of the issues I have already mentioned are not major, in and of themselves, what’s really concerning is that compromised printers can also be used to map out entire networks or as a proxy for attacks on other devices.

So what can you do to protect yourself from threats involving printers? Mostly standard security measures apply. The web panels for them can be locked down with authentication. Some can even be centrally managed. Disable unnecessary services running on the devices (as with all devices), log and restrict access to administrative functions to only those who absolutely need it. Ensure any ports the printers are listening on are not accessible from untrusted networks (like the Internet). Most importantly, have a comprehensive information security plan at your organization that includes all information systems components and educate everyone on what it means as well as why it’s important.

The real lesson here is that security and risk management is really a way of thinking and operating. It is a continual process that encompasses the entire organization — devices, software, facilities, process, and (most of all) people, rather than a concrete set of rules or a software package that one can buy. Such a comprehensive posture toward security and risk is how these less obvious vulnerabilities can be found and properly mitigated.

 

Much of the information presented here was based on my experience in systems administration and security auditing. However these sources were also used in informing and writing this article:
http://www.schneier.com/blog/archives/2006/08/printer_securit.html
http://www.itbusinessedge.com/cm/blogs/weinschenk/its-not-exciting-but-n…
http://www.irongeek.com/i.php?page=security/networkprinterhacking

How to Rescue Data From a LUKS Encrypted Filesystem

With 10,000 laptops stolen from airports alone each year, data encryption is an absolute must. What happens, then, if your fully encrypted  system crashes and won’t boot? Here, we’re going to cover how you would go about recovering that data if it is encrypted with LUKS.

LUKS is an encryption standard most commonly used on Linux but can be used on other systems. It is the basis of Ubuntu/Debian’s (as well as others’) filesystem encryption, which can be installed using the alternate installation disc.

What you need:

The LUKS passphrase (Without that, you are out of  [ahem] luck. Otherwise, what would be the point of encryption.)   :)

Something to copy your data to like a USB drive or another machine on your network. I recommend this even if you are planning on fixing/rescuing your OS. This way your data is backed-up and safe no matter what happens afterwards.

A “live CD” like the Ubuntu desktop installation disc or a Debian installation disc.

The process:

- Boot the crashed machine with a “live CD” such as Ubuntu 4.09 or the Debian installation disc in recovery mode. When I did this on my own drive, I used an Ubuntu live CD. If you are using the Debian installation media, boot into rescue mode.

Become root to simplify things more:

sudo su -     (if using the Ubuntu CD)

su -                (if using pretty much anything else)

Install the needed LVM and encryption tools:

apt-get update
apt-get install cryptsetup

Check to see what your device names are:

fdisk -l

You’ll see something like:

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x41ab2316

Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1       18701   150215751   83  Linux
/dev/sda2           18702       19457     6072570    5  Extended
/dev/sda5           18702       19457     6072538+  82  Linux swap / Solaris

Take a look at your LUKS header information here to ensure you’re going after the right one:

cryptsetup -v luksDump /dev/sda1

The first several lines of output should look something like this:

LUKS header information for /dev/sdb1

Version:        1
Cipher name:    aes
Cipher mode:    cbc-essiv:sha256
Hash spec:      sha1
Payload offset: 2056
MK bits:        256

If you ran luksDump on a partition not encrypted with LUKS, you’ll get a message like, “Command failed: /dev/sda1 is not a LUKS partition”

If that’s the right device, then go ahead and unlock it:

cryptsetup -v luksOpen /dev/sda1 sda1_crypt

The system should prompt you for a password and after entering it, you should see something like:

key slot 0 unlocked.
Command successful.

See which volumes are available:

lvdisplay

Enable your logical volume. It is probably the same as the machine’s host name:

vgchange -a y volumename

Mount your filesystem:

mount -t ext4 /dev/volumename/root /mnt

Hopefully you can read your file system at this stage. If so, grab your files and back them up.

If the filesystem is corrupt and you can’t mount it, you can try the following. Your data may be lost if the filesystem is wrecked but it’s worth trying a few things to retrieve it.

Be sure the filesystem is not mounted when you do this. Also be sure to use the proper type of fsck (fsck or fsck.ext4) for your filesystem type. BIT ENGINE takes absolutely no responsibility for what happens when you perform these tasks — even if you follow them exactly as specified.

To identify where back-up superblocks are

dumpe2fs /dev/devicename | grep superblock

If your filesystem type is ext2 or ext3:

fsck -b 32768 /dev/devicename  (substitute 32768 for a back-up superblock in the list from the output of the previous line)

If your filesystem type is ext4:

fsck.ext4 -b 32768 -y /dev/devicename

Hopefully, that fixes any errors. Try mounting again:

mount -t ext4 /dev/volumename/root /mnt

If your journal is messed, you can try:

tune2fs -j

Then try mounting again:

mount -t ext4 /dev/volumename/root /mnt

In my situation, my filesystem and journal were corrupt. After running fsck.ext4 (I run ext4, obviously) and tune2fs -j, I was able to mount it and search /mnt/lost+found for files (find /mnt/lost+found/ -name *.odf should get you there, substituting odf for whichever file type you need). Fortunately for me, all my important data was backed up and I was going through this as a test run in case I needed to do it in the future.

The biggest lesson here is one that can not be overstated: always back-up your critical data! Keep back-ups current and to a secure medium.

This how-to was created with a lot of help from this document and a little help from this one.

Using ngrep

From the man page, “ngrep  strives  to provide most of GNU grep’s common features, applying them to the network layer.  ngrep is a pcap-aware tool that will allow you  to specify extended regular expressions to match against data pay?loads of packets.  It currently recognizes TCP,  UDP  and  ICMP  across Ethernet, PPP, SLIP, FDDI and null interfaces, and understands bpf filter logic in the same fashion as more common  packet  sniffing  tools, such as tcpdump(8) and snoop(1).”

Perhaps the most significant difference between ngrep and tcpdump is that ngrep can analyze packet payloads whereas tcpdump only looks at packet headers and such.

ngrep is incredibly powerful and useful in finding out what’s happening on your network. The best way to show you want ngrep can do and how it’s done is by example. See some below.

Watching all traffic on the default interface:

ngrep -itq -W byline

Watching all traffic on eth1:

ngrep -d eth1 -itq -W byline

Watching all traffic on the default interface while searching for the string “testing”.

ngrep -itq -W byline testing

Watching all traffic on the default interface originating from 192.168.1.1:

ngrep -itq -W byline src 192.168.1.1

Watching all traffic on the default interface destined for 192.168.1.2:

ngrep -itq -W byline dst 192.168.1.2

Watching all traffic on the default interface with the gateway of 192.168.1.100

ngrep -itq -W byline gateway 192.168.1.100

See more examples at http://ngrep.sourceforge.net/usage.html

Also check the man page for many more neat possibilities.

OpenConnect, an Excellent Alternative to Cisco AnyConnect for Unix Clients

I recently ran into trouble connecting to a Cisco AnyConnect SSL VPN gateway, which requires the Cisco AnyConnect client software, from my Linux workstation. Cisco does make a Linux AnyConnect client and seems to keep it fairly current but it suddenly stopped working for me (updates were performed on both the VPN and client machines within a couple of weeks of each other, so maybe the issues had something to do with that).

Eventually, I stumbled across OpenConnect, which is an open source client made for Unix systems (It has been tested on Linux, OpenBSD, FreeBSD, and Mac OSX). Installing OpenConnect was straightforward and once on my workstation, I was able to connect to the Cisco VPN again without issue.

By the way, if you are looking to connect to a Cisco IPsec VPN, you probably need to use vpnc instead of AnyConnect or OpenConnect. There are a few different GUI front-ends for vpnc such as KVpnc and the NetworkManager vpnc plug-in.

If you are a user of a recent Fedora release, you’re in luck — OpenConnect and its accompanying NetworkManager plug-in are available in the yum repositories so you can easily install them that way. Similarly, there is an OpenConnect package in the Debian unstable repository (though the plug-in is not available there).

To get OpenConnect going on your workstation from source code, read on.

First, ensure you have the prerequisites, libxml2 (Development files for the GNOME XML library) and OpenSSL.

I had to install libxml2 for my system. Since I am running Ubuntu on my PC, this was easily done via “sudo apt-get update” followed by “sudo apt-get install libxml2-dev.” I suspect this library is also in the yum repositories for popular RPM distributions — if not, try one of the RPM sites such as RPM Find or DAG.

Download the OpenConnect source from it’s web site.

Unpack the tarball as in tar -xvzf openconnect-*.tar.gz.

Run make (type “make” without the quotes at the command line).

Run make install. (I actually use checkinstall instead, myself,  so I can easily remove the application, if necessary).

Connecting to the VPN

Once installed, you can connect to the VPN by typing openconnect yourvpn.yourhost.com.

You will then be prompted separately for a user name, password, and group.  You should be connected after filling each of those in.

Press ctrl-c to terminate OpenConnect and disconnect from the VPN.

I wrote a simple script for myself, shown below, to make connecting a bit easier.

#!/bin/bash

sudo openconnect -u mike –authgroup=’TunnelAllTraffic(Advanced)’ vpn.mikestestnetwork.com

I didn’t bother with the NetworkManager plug-in since it had a bunch of dependencies and using this script at the command line works pretty well for me but remember the plug-in is a nice option to connect to your VPN in a few clicks.

There are many options and features for OpenConnect listed at the project page. Huge thanks to the OpenConnect developers for creating a vital application that works great!