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 director of engineering operations in the San Francisco Bay Area, the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal.
|Android Candy: Intercoms||Apr 23, 2015|
|"No Reboot" Kernel Patching - And Why You Should Care||Apr 22, 2015|
|Return of the Mac||Apr 20, 2015|
|DevOps: Better Than the Sum of Its Parts||Apr 20, 2015|
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
- DevOps: Better Than the Sum of Its Parts
- "No Reboot" Kernel Patching - And Why You Should Care
- Return of the Mac
- Android Candy: Intercoms
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Designing Foils with XFLR5
- Non-Linux FOSS: .NET?
- Play for Me, Jarvis
- Consent That Goes Both Ways