Travel-related tech

I recently took a trip, and here are a few notes about some of my technology-related experiences.

I knew I'd probably want Internet access at the hotel, but I figured it would be wireless, and I was hoping for some kind of VPN. In the past I've used ssh's socks proxy feature, but I've found it to be pretty slow. So I thought I'd give wonderproxy a try. You can get a VPN account for a month for around $5, and I thought it worked really well. It was fast, and it made me feel a little better about using the hotel's wireless.

I bought a Macbook Air not long ago, and I like it. So I took it with me on the trip. I took some pictures, and I used iPhoto to copy the pictures off the camera onto the laptop. Then I tried using iPhoto to upload the photos to flickr, and that didn't work well for me. iPhoto crashed at one point during an upload of a bunch a photos, and there was no obvious way to resume the upload. I was able to figure out where it quit, and then I just told it to upload the photos it missed. But many of the photos on flickr don't have the original size--the largest version of many of them is 1024x768 (there should be three larger sizes). So I have to upload those images again or just be OK with the smaller sizes on flickr. So I'm glad I hadn't told iPhoto to delete them off the camera.

I also told iPhoto to mark several of the photos as private, and they ended up as public on flickr.

So I probably won't be using iPhoto any more.

And although southwestvacations.com did a great job of booking the trip, they totally FAIL in password security. When I created the account, I used a password generator to create a long password with all four character classes, and I saved the password in my password wallet. At one point during the trip, I needed to access something in my account. But when I tried to log in, I got invalid username/password errors. I ended up using the "forgot my password" link, thinking it would send me a login token. Nope, it sent me my password. It wasn't even my original password (which is why I was having trouble logging in). The original was around 20 characters long, but what they sent me was the first 10 characters of the password I'd created. So southwestvacations.com

• restricts password complexity (they truncated my password at 10 characters--the 11th was a percent sign, so I don't know if it was the length or the character)
• they truncated my password without warning me
• they store non-hashed passwords
• and they'll send passwords by email

FAIL.

Otherwise, it was a lovely trip. Have a look, if you like.

shadow passwords with openssl

I once had to break in to a CentOS box, because I'd forgotten root's password and didn't know the passwords to any other users (I think it had been shut down for a while). So I booted with a rescue disc (I think it was a CentOS installation disk, and I typed "linux rescue" at the prompt). The rescue disc mounted the filesystems, and I tried running passwd in a chroot. I got some kind of error message, and it wouldn't reset the password for root in /etc/shadow on the filesystem. I ended up editing /etc/shadow by typing in a password I got out of /etc/shadow on another box.

As I'm writing this, it occurs to me that if I knew the password to some other user (at this point I don't remember if I did or not), I could have just edited /etc/sudoers to give root to that other user, rebooted, logged in as that user, and done "sudo passwd" to reset root's password.

But if you ever need to create /etc/shadow entries by hand for some weird situation, here are a few suggestions involving openssl's passwd utility.

Incidentally, if you have trouble finding the man page for openssl's passwd ("man passwd" is likely to get you the man page for thing that resets your login password), try "man 1ssl passwd" (Ubuntu) or "man sslpasswd" (Red Hat 5).

The hashed passwords in /etc/shadow look something like this:

$1$.oDCRZmb$mYZm6IzfMWVfe38Pr4fHt0

The shadow entry has three parts delimited by dollar signs. The 1 indicates that this shadow entry was computed with the MD5 password algorithm. The next section (".oDCRZmb") is the salt, and the final portion is the hashed password.

You can generate these yourself. If you type the following (the "-1" requests the MD5 algorithm)

echo password | openssl passwd -1 -stdin

you should get something resembling

$1$DcuakEM4$c4WDkEXKd6YXNYjAfN2Sh/

You can reproduce this by providing the salt:

carl@stilgar:~$ echo password | openssl passwd -1 -stdin -salt DcuakEM4
$1$DcuakEM4$c4WDkEXKd6YXNYjAfN2Sh/

And it looks like openssl is smart enough to strip the newline:

carl@stilgar:~$ echo -n password | openssl passwd -1 -stdin -salt DcuakEM4
$1$DcuakEM4$c4WDkEXKd6YXNYjAfN2Sh/

Without the "-1" argument, openssl uses the standard crypt algorithm. The first two characters from crypt output are the salt, and this is what the Apache webserver's htpasswd uses for making passwords (at least, crypt seems to be the default algorithm for the Ubuntu and Red Hat 5 packages):

carl@stilgar:~$ echo password | openssl passwd -stdin
BxZPctq22eZ4M
carl@stilgar:~$ echo password | openssl passwd -stdin -salt Bx
BxZPctq22eZ4M

passwd also knows the Apache variant of the MD5 algorithm:

carl@stilgar:~$ echo password | openssl passwd -apr1 -stdin
$apr1$z4cUIQjr$fXbDk6ypzyZIIIb/OIp0I.
carl@stilgar:~$ echo password | openssl passwd -apr1 -stdin -salt z4cUIQjr
$apr1$z4cUIQjr$fXbDk6ypzyZIIIb/OIp0I.

Looks like Ubuntu uses the sha-512 algorithm for hashing passwords, and openssl's passwd doesn't support this. If you want to try making /etc/shadow entries w/ sha-512, try saving the following file as passwd.c:

#define XOPEN_SOURCE
#include 
#include 

int main(int argc, char *argv[]) {
    if ( argc < 2 ) {
        printf("usage: %s password salt\n", argv[0]);
        return;
    }
    printf("%s\n", (char *)crypt(argv[1], argv[2]));
    return;
}

And then try this:

gcc -lcrypt -o passwd passwd.c
./passwd password '$6$salt$'

Testing an SSL-enabled service for cipher strength

Vulnerability scans sometimes find that an SSL-enabled service allows clients to connect using ciphers which have key lengths shorter than 128 bits. Most services have configuration directives to disable these connections. Here's how to test a service for key length (without doing a new nessus scan, or whatever).

openssl ciphers -v

This gives a list of ciphers that the openssl client can use, and the output indicates the key length. openssl's s_client command can take an argument which specifies the cipher(s) to use. So after reconfiguring the server, run the following two commands (the first should fail, and the second should succeed):

openssl s_client -ign_eof -connect target:port -cipher RC4-MD5

openssl s_client -ign_eof -connect target:port -cipher DHE-RSA-AES256-SHA

(You should replace target:port with something like www.example.com:443)

added READONLY option to password wallet

Made an update to my password wallet. You can now have the READONLY attribute in your .walletrc file: this disables updates to the wallet (w/ the -e option). I keep my wallet in two places (work and home), and a cron job copies from work to home daily. So I need to make sure that I only update the wallet at work. I once updated it at home, and the next run of that cron job overwrote the update (a new password).

panopticlick

I've seen several posts about the panopticlick project in the last few days. If you go to the panopticlick Web page and click the "test me" button, it'll tell you how identifiable your Web browser is. The idea is that it might be possible for someone to track your Web browsing based solely on certain characteristics of your Web browser (without using cookies or even IP addresses).

So I hit the "test me" page with several different kinds of browsers to see what kind of results I would get. The results are given below (all Firefox browsers below have the NoScript extension). In terms of security, these are like golf scores: you want low numbers in the second (BII="bits of identifying information") and third (NIF="number of identical fingerprints") columns. And in terms of security, being unique is bad (it makes it easy to identify you).

browser/platform	BII	NIF
MSIE7 on XP	17.64	unique in 204,788
Firefox 3.6 on XP	8.62	one in 392
Firefox 3.6 on Ubuntu	12.64	one in 6,364
MSIE6 via wine on Ubuntu	17.66	unique in 207,713
lynx on Ubuntu	14.67	one in 26,001
elinks on Ubuntu	17.67	unique in 208,111
wget on Ubuntu	9.57	one in 761
curl on CEntOS	17.67	unique in 208,688

Firefox 3.6 on XP did pretty well, so I captured the HTTP request headers from that browser:

GET / HTTP/1.1
Host: vmware:8000
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive

Then I installed the Modify Headers extension to Firefox on Ubuntu and set the User-Agent header to the value from the request headers above. After doing that, Firefox 3.6 on Ubuntu got panopticlick scores like Firefox 3.6 on XP.

An interesting side effect of this is that the Firefox Add-Ons site uses the User-Agent header. So if you do this and want to add extensions later, you will probably need to disable the header. And I've just done this today, so I don't yet know what effect this will have on updating extensions.

pager in wallet program

I recently got an email from someone who has been using the password wallet program. The reader asked about the possibility of using a different pager when viewing the password file (the "less" pager is hard-coded into the program).

I thought this was a good idea, so I've changed the wallet program to allow the user to specify the pager using the WALLET_PAGER environment variable (which defaults to "less"). You can also put this in the .walletrc file. The reader wants to use w3m, so this should now work in .walletrc:

WALLET_PAGER="w3m -o bg_color=blue"

I've updated the program in the google code repository.

mod_security

mod_security is an open source Web application firewall which operates as an Apache module. mod_security inspects incoming requests (and, I believe, can also inspect outgoing responses) and take certain actions if a request (or response) matches a pattern. These actions can include logging and/or blocking the request. mod_security works sort of like anti-virus software, in that it comes with a ruleset which can identify common malicious activity (like cross-site scripting and SQL injection attempts). Like anti-virus software, it's necessary to update the ruleset from time to time.

I installed mod_security on a couple of production RHEL5 Web servers lately, and here are a few of my observations.

Installing mod_security is pretty easy and is documented in the mod_security download. I found that I needed to install the following packages to meet some dependencies and to build mod_security:

• apr-devel
• gcc-c++
• httpd-devel
• pcre and pcre-devel
• libxml2-devel
  

I had the support of my managers to put mod_security in full blocking mode, so after copying the rules directory to /etc/httpd/modsecurity.d, I saved the following in /etc/httpd/conf.d/modsecurity.conf:

LoadFile /usr/lib/libxml2.so.2

LoadModule security2_module modules/mod_security2.so
LoadModule unique_id_module modules/mod_unique_id.so

<IfModule mod_security2.c>
Include modsecurity.d/*.conf
Include modsecurity.d/optional_rules/*.conf
</Ifmodule>

The Web servers run a variety of custom Web applications as well as some canned software like Webcalendar and Wordpress. I didn't experience any problems with the custom applications or Webcalendar, but mod_security took issue when someone tried to edit an existing blog post in Wordpress (curiously, there wasn't any trouble when submitting a new post). So I put the following in /etc/httpd/modsecurity.d/modsecurity_crs_15_customrules.conf:

<Directory /path/to/wordpress/wp-admin>
SecRuleEngine Off
</Directory>

I'm in the fortunate (and perhaps unusual) situation of being able to restrict access to the wp-admin directory by IP address, so I don't have the entire Internet hammering at the thing. Looks like blogsecurity.net has a custom mod_security configuration for Wordpress which I just haven't had time to try yet.

Another wrinkle I had was that some command-line Perl programs I run would be blocked because they weren't providing "accept" and "user-agent" request headers. One of these programs looked something like this:

#!/usr/bin/perl -w

use strict;
use HTTP::Request::Common;
use LWP::UserAgent;

my $ua = LWP::UserAgent->new();
my $uri = shift @ARGV;
my $res = $ua->request( GET $uri );
print $res->content();

I had to make the following two changes/addition:

$ua->agent('whinerack');
my $res = $ua->request( GET $uri, accept => 'text/html' );

(Looks like just about any non-blank user-agent will do.)

Another trick I've learned is that instead of using SecRuleEngine Off (like I did for the Wordpress wp-admin directory, which makes mod_security totally ignore that directory), you can use SecRuleEngine DetectionOnly, which makes mod_security log what it would do without actually blocking requests. This can be good for debugging.

And although I haven't needed it, the mod_security documentation suggests a way to whitelist requests from a specific host:

SecRule REMOTE_ADDR "^192\.168\.1\.100$" nolog,phase:1,allow

All in all, installing mod_security has been a fairly easy transition, and it's nice having another layer of protection.

HTML form attack

The other day I came across a post about the HTML form attack.

I don't think I'd seen this before, and I'm not well versed in JavaScript attacks (authors of the planet-websecurity.org blogs would probably point, laugh, and yell "NOOB!"). But when I sort of figured out what it was talking about, it occurred to me that a form on a page which is vulnerable to cross-site scripting could be made to POST to an arbitrary location. Try the following in a JavaScript-enabled browser, and see where it ends up taking you when you click the submit button:

<html>
<body>
<form id="gakkk" action="/good.html">
<input type="submit" />
</form>
<script type="text/javascript">
// <![CDATA[
document.getElementById('gakkk').action = '/bad.html';
// ]]>
</script>
</body>
</html>

root ssh access trick

Free Software Daily had an interesting post the other day about securing SSH services (that post points to a Tux Training article). This particular tutorial included a configuration item I hadn't seen before. It's a configuration value for the PermitRootLogin field.

If I'm running an SSH service which is visible to the Internet (or even a large intranet), I tend to disable PermitRootLogin (PermitRootLogin no), because the script kiddies can be reasonably sure that an SSH service will have a user called root, and if they try hard enough, they might get lucky with the password.

(I'm also a big fan of the AllowUsers option, which allows you to provide a list of users allowed to log in via ssh. If a valid user not on that list tries to log on, ssh acts as though the user has provided the wrong password.)

The new (new to me, anyway) trick in this tutorial is setting PermitRootLogin without-password. This allows root to log in with a key, but not with a password. This is a really good compromise if you have a server where you need root to be able to log in over ssh. Backups over rsync are a good example of this: to preserve file ownership and permissions, it's sometimes necessary to have rsync run as root.

updated WordPress security whitepaper

blogsecurity.net has released version 1.2 of their "How to secure WordPress" whitepaper. Looks like they've added some v2.5-specific details along with updated information about security-related plugins.

fopen($url) v. curl in PHP

Occasionally you'll see PHP code which uses require() or include() or fopen() or file_get_contents() to import code from a remote location (the argument to those functions can be a URL). This sort of thing is generally considered to be a bad security practice, especially if you don't control the code at the remote location (it could unexpectedly change in such a way as to do something destructive to your application).

Many PHP security experts tend to recommend disabling the allow_url_fopen option in php.ini. Disabling this feature can even serve to prevent inadvertent code injection. Imagine an application which calls require($file) where $file is dynamically determined. If your application has some sort of problem which allows an attacker to set the value of $file, the attacker can inject the code of his/her choosing into your application.

So I feel that disabling allow_url_fopen is a good idea, but sometimes you need to initiate HTTP requests in your PHP code. The curl extension provides a good way of doing this. The following snippet will put the contents of the Web page at $url into the $page variable:

$ch = curl_init($url);
curl_setopt( $ch, CURLOPT_RETURNTRANSFER, 1 );
curl_setopt( $ch, CURLOPT_HEADER, 0 );
$page = curl_exec($ch);
curl_close($ch);

The previous example is a GET request, but you can also do POST:

$postdata = 'var1=value1&var2=value2';
$ch = curl_init($url);
curl_setopt( $ch, CURLOPT_RETURNTRANSFER, 1 );
curl_setopt( $ch, CURLOPT_HEADER, 0 );
curl_setopt( $ch, CURLOPT_POSTFIELDS, $postdata );
$page = curl_exec($ch);
curl_close($ch);

rate-limiting in iptables

I recently learned about a useful feature in iptables which might help prevent denial of service (DOS) attacks. The iptables "recent" extension dynamically creates a list of source addresses against which your ruleset can match, for example, to block someone who is making too many connection attempts in a given time interval. The Debian Administration blog has a good example of using this to block DOS attacks against an ssh server.

password wallet update

Yesterday I discovered an interesting (and somewhat alarming) problem with my password wallet.

I use vim for my text editor (I have export VISUAL="/usr/bin/vim" in my ~/.bashrc). Yesterday I used the wallet script to update my password list, and then later I was using vim to edit a totally unrelated text file. I fat-fingered what I was doing and typed some magical set of keystrokes (still not sure just how I did that), and suddenly I was looking at several lines from my password file. I recognized those lines as lines that I had highlighted, deleted, and then pasted to a new location when editing the password file when I was using wallet. I then had a forehead-slapping moment when I realized that such edits are saved for posterity in the ~/.viminfo file.

Oops. That's a potential information leakage vulnerability.

But it is easily remedied by adding the following line to ~/.walletrc:

VISUAL="/usr/bin/vim -i NONE"

The -i option tells vim to use some file other than ~/.viminfo for its state information. In this case, it tells vim not to store state information at all. The trick of putting it in ~/.walletrc (rather than in ~/.bashrc) means that vim only skips storing state information when running wallet--vim will keep state information in ~.viminfo any other time you run vim.

So if you're using wallet with vim, I urge you to make the above change to your ~/.walletrc file.

securing WordPress with blogsecurity.net

I needed to set up a WordPress blog at work this week, and I decided to try following the WordPress Security Whitepaper at blogsecurity.net. It was pretty easy, and (hopefully) has made that WordPress installation a bit more secure.

blogsecurity.net is a blog about security issues relating to blogging. It's pretty interesting and has lots of good information and resources.

Ubuntu firewall

This post offers a way of telling your Ubuntu system to set up a simple firewall at boot time. It assumes that you have a single network adapter called eth0.

I saved my firewall rules (in iptables-save format) to /etc/network/fwrules. My firewall rules are fairly specific to my setup, but the following might serve as a good starting point if you want to try this:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT 
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT 
COMMIT

And then I just saved the following to /etc/network/if-pre-up.d/fw:

#!/bin/bash

iptables-restore < /etc/network/fwrules

(Be sure to make this file executable: sudo chmod 755 /etc/network/if-pre-up.d/fw).

This loads the firewall rules prior to bringing up the network interface, so that the firewall is in place by the time the network connection is active.

Inspekt PHP library

A recent post on the Planet-Websecurity.org blog got me interested in Inspekt. It's a secure input validation library for PHP. It reminds me a bit of Perl's taint switch, in that Inspekt prevents you from directly using $_POST, $_GET, and their ilk.

Looks like it hasn't really hit release status yet, but I think it's going to be worth watching.

identity theft

Bruce Schneier has posted about a report giving some interesting statistics about identity theft.

lock pick gun

Here's an interesting video showing someone defeating 8 locks in less than 80 seconds. The person in the video is using a lock pick gun. I'd only seen these in movies and TV before this. I don't really understand how the thing works, but it may be similar to bumping. Note the use of the torsion wrench in the video.

noscript

I've been using the flashblock Firefox extension for a long time. There's nothing more annoying (to me) than going to a Web site littered with a bunch of flash movies which slow the page load, distract me from the important content, or crash my browser. The flashblock extension replaces each flash movie with a link you can click to enable that flash movie, allowing you to enable only the individual movies you want to view.

The noscript Firefox extension disables all JavaScript in your browser. You can temporarily or permanently whitelist Web sites in noscript, allowing JavaScript from the sites you trust. This is a good idea: just start reading some of the stuff at Planet Websecurity if you need convincing.

Unfortunately, the two extensions are incompatible, because flashblock uses JavaScript to replace the movies (and noscript disables JavaScript). Until this week, I'd chosen flashblock over noscript, because my annoyance with flash exceeded my fear of JavaScript. I really can't defend that decision. shrug

But this week I took another look at noscript and discovered that noscript can disable flash in the same way that flashblock does. Looks like the developer(s) added that feature in version 1.1.0 (August 2005). Guess it's been that long since I'd tried noscript (or else I didn't look at the feature list very well). Anyway, I've switched to noscript.

Nuclear materials for the asking

The New York Times is reporting that the General Accounting Office (GAO) set up a fake construction company and requested a license from the Nuclear Regulatory Commission (NRC) to purchase nuclear materials. The GAO did this in order to audit the NRC's security protocols. The fake GAO company had no physical location, no Web site, no clients, no construction equipment, and no personnel--just a mailbox.

The NRC quite promptly (less than a month) sent the fake company the requested license. In fact, the GAO was able to alter the document so as to be able to purchase more nuclear material than the original license allowed. The GAO was then able to acquire enough americium-241 and cesium-137 (substances which are legitimately purchased by construction companies) to have been able to construct a dirty bomb (the GAO called off the order prior to delivery and never actually constructed a bomb).

So, next time you think the NRC's got your back, think again.