Interview with Brian Hatch, author of

Date: October 15, 2003
Source: Computer Crime Research Center


Brian Hatch is a hacker in the positive sense - a coder, tinkerer, and tester. I love to prod software into doing things it shouldn't be able to, be it for good or ill.
My love of Linux comes from the fact that all the code is there for your perusal, modifications, and bastardizations. I'm constantly testing and breaking my laptop, putting backdoors and Trojans on them, and occasionally need to reinstall my system from scratch to be sure I haven't irrevocably destroyed any hope of stability and security in my quest to do weird things.
When I'm not tinkering in Linux or security, I'm... Hmmn. Wait, I can't think of a time that I'm not tinkering in security. I should never have gotten a phone with an SSH client.



I first started playing with it in 1993, but it became my primary desktop OS in 1995. That was a laptop, and damn but was that a tricky beast to set up back then. It originally ran via loadlin and everything lived on a DOS partition because I needed to have Windows available for corporate email (Lotus Notes). Luckily I left that company and was able to ditch Windows for good. Of course I'd been using GNU software for a long time before I had Linux on my desktop. SunOS/Solaris and IRIX machines were my usual stomping grounds -- I still have my Indy somewhere in the attic.
The beautiful thing about Linux is that the entire kernel is Free Software/Open Source, as are most of the userland tools. Having the entire code base of your software makes tweaking possible, and allows me to have complete control of my system. For example I've occasionally modified the 'crypt' password hashing function on my systems. Since most password crackers are run offline, or have crypt written in optimized assembly, the results from password crackers would never be valid on my machine. This is the kind of ability you have when a system's source is completely available to you. I can't imagine going back to using something where I can't see each and every line of code.



I don't ever remember getting interested in it -- it seemed to be one of my innate desires for as long as I can remember. I guess I was always paranoid and mistrusting.
Back when I had my first Apple machine, you'd need to boot off the floppy drive or tape. The computer would run the program called 'hello' on the floppy if it was available. Well, I sure didn't want anyone looking at my files and programs, so my hello program was this paranoid thing that required two correct passwords (each more than 10 characters long) to get in or it would reboot the machine. If you correctly authenticated, the thing had a fully functional text file management/program execution environment.
Now not only was this exceedingly paranoid (aside from hello, the only other program on the disk was Snake Byte) but it was still vulnerable. Anyone could simply boot a different disk and then stick mine in to access what was on it. So I learned to modify the disk structure to foil that avenue of attack. Of course, anyone with a disk editor could still figure out what was on it if they tried hard enough. I considered adding some sort of encryption to the mix, but never got around to it, and likely I would have fallen pray to holy grail of all the newbie cryptographers -- XOR with a short ASCII key.



A lot of tools that are considered 'security' tools are excellent for general network connectivity testing and debugging. For example I use both nmap every day in a non-security-specific context, yet it is generally considered a security tool.
If I were stranded alone on a desert island with only one tool from the major security categories, I'd use Nmap for port scanning, P0f for passive OS detection, Nessus for vulnerability testing, Snort for intrusion detection, Hogwash for inline intrusion filtering, GnuPG for file encryption, OpenSSL for crypto libraries, OpenSSH for file transfer / remote login / remote execution / X11 forwarding / secure port forwarding, Netfilter/iptables for firewall/acls, vi for file editing, and Netcat and Perl for everything else.
You have suddenly been given the ultimate power to change the world in one of two ways: either you can make all programmers into perfect coders, or you can make all users knowledgeable about the security implications of their actions. Which do you choose?
This is a tough question. Even if all software is completely secure, then you still have a VEBKAC situation. (Vulnerability exists between keyboard and chair.) How many people click 'ok' when their browser says the remote site's SSL certificate isn't valid? How many use the same password for their home email as their work accounts, type it over unencrypted connections, and it's probably 'password' anyway?


Then again, if the user knows the correct response to any security-related action, that does no good if the underlying software is built poorly. Their only available response would be to not use any software at all.
So I'd need to pick the former. Magically modify all programmers to be flawless security geniuses. However, the best of both worlds could still be achieved. These uber-programmers will prevent user cluelessness from subverting security. The user will no longer have the opportunity to just click 'ok', instead you'll get a dialog box like this:
"The site to which you've connected does not have a certificate that is signed by a trusted CA. If you'd like to continue anyway, please explain the security ramifications of this decision and why you consider it necessary."


No "ok" button, just an empty text field. The user has a chance to provide a correct and applicable response, such as "The server's certificate is signed by my company's CA, not a global CA. I have verified the CA's information, including fingerprint, against the signed laminated card provided personally by my company's system administrator and they match, so I am reasonably sure that there is no chance of a man-in-the-middle attack."
Perhaps I should call this 'security through bullying the user into not accepting insecure modes of operation.'


Some believe the best security model is to have highly audited and secure code. Others believe that you should employ kernel modifications that go beyond the standard Unix security model. What are your thoughts?



The bare minimum standard for any secure system would be that the code itself is secure. Code auditing is one of the central tenants of OpenBSD, for example, and they've had bragging rights for many years by being able to point to internal code audits that fixed bugs before they were found to be exploitable, often years before. Unfortunately, in the Linux community there are less folks taking on this task of proactive code auditing. The Linux distro with the greatest emphasis on code audits is Openwall GNU/*/Linux, aka Owl. The OpenWall folks, which include such experts as Solar Designer, have stressed code audits, to the point that their code produces no warnings, even trivial ones, when compiled with 'gcc -Wall'.
Having secure, audited code, is a must. However I still prefer to use kernel security patches when possible. Audited code helps keep the bad guys off of the machine. However advanced kernel patches can both prevent them from getting in, and prevent them from doing damage if they do find a way in. Even if the software on your machine is completely locked down, a malicious cracker can find some avenue to get onto your system. For example if one of the administrator's desktop machines is broken into, and they access the secured server, the cracker can get in.
An advanced security kernel patch can protect your machines more than the traditional Unix model. If the cracker, even if they can get in as root, can not remount the partitions in read-write mode, cannot stop or start your daemons, cannot bind any network sockets or make outbound connections, cannot read protected files even as root, they'll probably move onto easier pickings.



Well, first of all, I still call it "Hacking Linux Exposed", and you can read my rant on the topic if you want...
As with HLEv1, one of the biggest problems with writing was the fact that the publisher required everything in Word. Yes, that's right, we had to write a Linux book in a proprietary document format. While VMWare (for HLEv1) and Crossover Office (for HLEv2) allowed me to run Word on my Linux box, it was still no more stable than Word on Windows, which means that I frequently lost huge chunks of my content and had to rewrite from scratch. Again, I'll stop ranting about this difficulty; I've managed to mostly suppress those memories.


We had a lot of organisation issues in HLEv1 that we wanted to fix, plus we wanted to re-write some of the content that was written by the original contributing editors. Then, naturally, we wanted to add a lot of new content. For example the 'post intrusion' chapter grew so much it became three chapters on their own, covering more back doors, encrypted access methods, Trojans, and loadable kernel modules.
I didn't want to create a book that was just umpteen hundred pages of "here's how tool foo works; now, here's how tool bar works." At heart, I am a teacher, and though I could have had fun showing each and every security-related tool out there, it wouldn't have taught the concepts I wanted to get across. Instead, I wanted to teach the theory of security, and the specific tools and methods to achieve it in the Linux/Unix world, illustrating it all with actual exploits and defences. The only way to really learn is by doing, and I wanted to get folks interested in going out and probing their own systems, testing or compromising their own...

---

Add comment  Email to a Friend