Hack and / - Some Hacks from DEF CON
I don't think the timing could be better on the editorial calendar than to have the deadline for the Hacking issue coincide with the Black Hat and DEF CON conferences. Although I have long been interested in security, usually it's from the sysadmin defensive posture or from a post-hack forensics angle. This year, I was fortunate enough to look over the shoulder of a talented group of hackers from the neg9 team as they competed in an open CTF tournament. Essentially, the tournament pitted multiple teams against each other as they all attempted to solve various puzzles and security challenges against locked-down servers. I thought for this column, I would list some tips for the defensive sysadmin that came to mind as I viewed computer security from an offensive perspective, especially in a restricted environment like a hacking competition.
First, before I get too many angry letters, I'm well aware of the long controversy over the word “hacker” and its multiple connotations. I refer to both clever tricks and security breaches as hacks and their perpetrators as hackers in this article for a few reasons:
The English language has many words that can change meanings based on context, and I think everyone reading this article is intelligent enough to make the appropriate distinctions.
Our community already is capable of drawing the distinction between “hack” when it refers to either a prank, an elegant solution, a quick-and-dirty kludge, or even a writer or politician based on context, so I think we can handle an extra contextual definition.
The word “cracker” just reminds me of 1970s lingo for white people, and it's hard for me to keep a straight face when I hear it in either context.
Now that that's out of the way, the first thing I found interesting about security from the offensive position was just how important it is to learn basic, classic command-line tools like vi, nc and friends. In this competition and in a proper locked-down system, you not only run minimal services, you also try to restrict the set of programs you install on the machine so they won't be available to a would-be attacker. If you want to attack a system but only know how to edit text files in Emacs, port scan with Nmap or write Ruby scripts, what do you do when those tools aren't installed? Even in a restricted environment, you can count on certain tools to be installed, such as vi, nc, dd, sh and all the other great two-letter commands. From the offensive perspective, if you know how to use those commands, you won't be hamstrung if you do happen on a minimal system. From the defensive perspective, if you do limit the programs installed on your system only to those that are necessary, you will slow down hackers who expect newer, fancier tools to be on the system.
I think if you were going to master only one of these two-letter commands for hacking purposes besides vi, nc is the best candidate. If you are unfamiliar with nc (or netcat), it is an incredibly versatile tool that allows you to open or listen for TCP and UDP connections. It's the original network Swiss Army knife, and it's a valuable tool to have in your arsenal whether you're a sysadmin or a hacker. In the case of both hacking and troubleshooting, it's useful because you can use it like telnet to connect to a remote server and port and start an interactive session:
$ nc mail.example.org 25 220 mail.example.net ESMTP Postfix . . . QUIT
You also could open one nc session on a port in listen mode and start a second nc session on a remote host to connect to that port and send text back and forth like a basic chat program. On the listening host, run:
$ nc -l 31337
On the remote host, type:
$ nc hostname 31337
You also can substitute the IPs for hostnames in both examples. Once the connection is made, anything typed on one end is displayed on the other, and you can press Ctrl-D in either session to close the connection.
A number of sysadmins have long used this functionality as a quick-and-dirty file-transfer protocol. Start the first nc session in listen mode, and redirect its output to a file:
$ nc -l 31337 > output_file
On the remote machine from which you want to send the file, you would type:
$ nc hostname 31337 < input_file
Once the file has finished transferring, the connection will close automatically.
Kyle Rankin is a systems architect; and the author of DevOps Troubleshooting, The Official Ubuntu Server Book, Knoppix Hacks, Knoppix Pocket Reference, Linux Multimedia Hacks, and Ubuntu Hacks.
- Readers' Choice Awards 2013
- Mars Needs Women
- RSS Feeds
- Sublime Text: One Editor to Rule Them All?
- December 2013 Issue of Linux Journal: Readers' Choice
- Raspberry Pi: the Perfect Home Server
- IBM Will Minimize Impact of Future Disasters
- Linux Systems Administrator
- Tech Tip: Really Simple HTTP Server with Python
- Senior Perl Developer
- So girls had it better ?
2 hours 44 min ago
- Reply to comment | Linux Journal
3 hours 4 min ago
- why is GNOME 3 in the fifth position at 14.1 %?
8 hours 36 min ago
- Sublime Is Brilliant!
13 hours 39 min ago
13 hours 59 min ago
- Rapid[Disk,Cache] better than native ram caching?
14 hours 24 min ago
- Nothing is perfect
14 hours 37 min ago
- Mixtapes Community
20 hours 16 min ago
- KDE is one true DE
20 hours 50 min ago
- Command Line Shells (Bash, Zsh, etc.) are 2nd place
21 hours 19 min ago