Dustin Kanske's Blog

My co-worker Austin created a nice “I Voted” sticker using Sprout. Click “Me too” to get your copy.

Yoshi: Ok so keep in my front pocket a black uni-ball vision elite. .08 writing thickness i believe.
Yoshi: It writes thicker than your “normal” pen.
Yoshi: so i keep that in my front pocket.
Yoshi: At work i keep a 1 black one and 1 red one. So i write out my GTD lists once a week now. Anything important that needs my attention that day is written in red. Red items are my must do.
Yoshi: Here are what the pens i use look like:

I did finally find the post he wrote that talked about the pen he uses: Notepad GTD

And so I don’t have to look it up again, Product page at officedepot.com

Thanks, Yoshi!

Luckily I only had a few hosts to update, and only the host keys, not any authorized_keys files. It’s important to review any public SSH keys that you’ve added to authorized_keys files, fix ssh host keys (apt-get dist-upgrade on debian), and deal with SSL certs generated on affected Debian (and derivative) distributions.

Ubuntu Security Notice USN-612-1

Weakness in Debian undermines crypto

• “A flaw in the way that OpenSSL is implemented in the Ubuntu and Debian distributions of Linux have earned the software an unenviable adjective in the world of encryption: Predictable.”
• “All OpenSSH and X.509 keys generated on such systems must be considered untrustworthy, regardless of the system on which they are used, even after the update has been applied”
• “This flaw is ugly because even systems that do not use the Debian software need to be audited in case any key is being used that was created on a Debian system.”

Debian OpenSSL Predictable PRNG Toys

• “All SSL and SSH keys generated on Debian-based systems (Ubuntu, Kubuntu, etc) between September 2006 and May 13th, 2008 may be affected. In the case of SSL keys, all generated certificates will be need to recreated and sent off to the Certificate Authority to sign. Any Certificate Authority keys generated on a Debian-based system will need be regenerated and revoked. All system administrators that allow users to access their servers with SSH and public key authentication need to audit those keys to see if any of them were created on a vulnerabile system. Any tools that relied on OpenSSL’s PRNG to secure the data they transferred may be vulnerable to an offline attack. Any SSH server that uses a host key generated by a flawed system is subject to traffic decryption and a man-in-the-middle attack would be invisible to the users. This flaw is ugly because even systems that do not use the Debian software need to be audited in case any key is being used that was created on a Debian system.”

Debian OpenSSL Predictable PRNG Bruteforce SSh Exploit

• “Enjoy the shell after some minutes (less than 20 minutes)”

In other news, brute-force SSH attacks are on the rise.

Admins warned of brute-force SSH attacks

A couple OpenSSH tips that come to mind:

• Have OpenSSH Listen on a non-standard port. This can reduce the risk of automated scans, etc. It can also make it more tedious to ssh to hosts. (“Listen addr:port” in sshd_config). I personally don’t like this option.
• Disable password-based authentication. (“PasswordAuthentication no” in sshd_config)
• Restrict access to accounts by IP address. sshd_config allowed users
• Watch your sshd logs and deny access.

Buddy Media, creator of AceBucks, buys Facebook Apps from ChipIn and then spams the users:

1. I am not an AceBucks member.
2. I did not express interest in receiving emails regarding AceBucks.
3. This email was in no way related to the Pirates vs Ninjas application itself.

The hotel across the street lost power:

They finally got power back after several hours:

(I need to get a tripod)

John Petrucci has a video out called “Rock Discipline”. This video attacks the speed that he plays at. I was in tears watching it.

Be careful if running your ruby application in a VPS that doesn’t have a standard MAC address (OpenVZ/Virtuozzo).


[rails@rails ~]$ irb
irb(main):001:0> require 'rubygems'
=> true
irb(main):002:0> require 'uuidtools'
=> true
irb(main):003:0> UUID.timestamp_create
NoMethodError: private method `split' called for nil:NilClass
from /usr/local/lib/ruby/gems/1.8/gems/uuidtools-1.0.0/lib/uuidtools.rb:236:in `timestamp_create'
from /usr/local/lib/ruby/gems/1.8/gems/uuidtools-1.0.0/lib/uuidtools.rb:226:in `synchronize'
from /usr/local/lib/ruby/gems/1.8/gems/uuidtools-1.0.0/lib/uuidtools.rb:226:in `timestamp_create'
from (irb):3
irb(main):004:0>


UUID.random_create works though


irb(main):005:0> UUID.random_create
=> #&ls;UUID:0x20254aac UUID:debe5522-85e3-4119-8e31-5746f8f52449>


As a side note, the uuid gem has problems determining the MAC address when creating its state file as well.


-bash-3.00# uuid-setup
uuid: No UUID state file found, attempting to create one for you:
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27: command not found: ipconfig /all
Could not find any IEEE 802 NIC MAC addresses for this machine.
You need to create the uuid.state file manually.


When using this I would manually create the uuid.state file and place it in /usr/local/lib/ruby/gems/1.8/gems/uuid-1.0.3 (I don’t remember exactly, and have since removedthe uuid gem). If you don’t your app will complain about the uuid.state file being missing.

I came across the following error trace when attempting to use Capistrano to set up my app:


$ cap -f config/deploy-client.rb setup
* executing task setup
* executing "umask 02 &&\n mkdir -p /u/apps/myapp /u/apps/myapp/releases /u/apps/myapp/shared
/u/apps/myapp/shared/system &&\n mkdir -p /u/apps/myapp/shared/log &&\n mkdir -p /u/apps/myapp/shared/pids"
servers: ["myapp.hostname.com"]
/sw/lib/ruby/gems/1.8/gems/net-ssh-1.0.10/lib/net/ssh/userauth/agent.rb:70:in `initialize':
No such file or directory - /tmp/501/nl.uu.phil.SSHAgent.socket (Errno::ENOENT)
from /sw/lib/ruby/gems/1.8/gems/net-ssh-1.0.10/lib/net/ssh/userauth/agent.rb:70:in `connect!'
--snip--


I haven’t had time to track down the issue yet, but starting up ssh-agent seems to fix the problem. I never had to use ssh-agent before to make Capistrano work.

$ ssh-agent bash
$ ssh-add

Then I run my cap tasks from that shell instance.

(It may seem trivial, and probably is trivial) I wrote about obfuscating the primary keys for your critical tables here: http://www.kanske.com/?p=7

I came across a reason why you do that recently when I discovered a potential chipin.com competitor.

A friend brought up the fact that we (chipin.com) have a competitor (Pledgie.com). The first thing that comes to mind is, how many customers do they have? How many events in their system? How much money have they collected? Do we need to worry about them?

They expose the primary key for both their account table and their event table. It appears that they have less than 42 campaigns (max campaign id at the time http://pledgie.com/campaign/show/42) and less than 87 users (max account id is 87 http://pledgie.com/account/show/87).

With a fixed number of events and users it’s possible to write a script to summarize how much money has been collected.

This isn’t the only source of such information, but it sure is low-hanging fruit.

Why are we using hex strings as unique identifiers for certain resources in our system?

Here are two sample URLS for accessing the same resource. One uses the primary key which in this case is a simple auto-incrementing integer field. The second case is a big random number in hex format.

• integer auto_increment key: http://example.com/product/100
• large random integer encoded in hex: http://example.com/product/de34f46a3b7fea74

They can be used for security. For things like sessions, you want to make a unique session ID ‘hard to guess’. You want to make it difficult to brute-force the ID to gain access to an individual session.

The point of this post is to address the other reasons for using a ‘large random integer encoded in hex’. Obscurity. By *not* using a simple auto_increment field as a primary key and using some sort of digest or random number encoded as a hex string, you are doing three things:

1. Obscuring counts for resources from the public.
2. Hiding Rates of change of those counts from the public.
3. Removing the ability for the public to easily enumerate items in the collection.

By exposing the value from a primary key field that uses a simple auto-increment for an id you are disclosing information about the number of records in a particular table. This may or may not be a concern. If you don’t care if your competition knows how many of a particular object (accounts) you have created, this isn’t an issue.

Not only do you get an absolute count, but you also can get the rate of change. Competitors can potentially monitor the primary keys and determine how many new accounts you signed up in a month (just an example). This doesn’t mean “rush to obscure this data”. Think about what you are disclosing. If it’s not a concern, move on.

You can remove the ability for a user of the system to iterate over the set of one of your collections. For example, if you include the email address in the profile for a user (even a rendered one), it would be more difficult for someone to collect all of the email addresses for your users directly through your system.

Questions:

Why don’t you just start the sequence out at some fixed number? This doesn’t stop someone from finding out the rate of change. Again, that may or may not be valuable information.

Why not start the sequence at some fixed number and increment by some random amount? This helps obscure, but you could still probably determine what the range was on the randomness that you added to the equation. With enough data points you could form an average and then determine the rate of change.

Summary:

Think about what you are disclosing. If that data is valuable, consider using a different identifier in public.

Also, keep in mind that there are other ways of find out counts of certain information. There are various reporting services out there that can measure your web-presence and give data based on that.

One of my co-workers also points out that they are nice to look at, ‘hexy‘ even. That’s one nice hexy digest right there!

2007-11-23 Update: At the time of writing this I had not considered any performance concerns of using a non-auto-increment primary key with InnoDB. Toad from #facebook on irc.freenode.net mentions “data is stored in PK order in innodb, which means there’s a lot more page splitting going on when you do inserts”. He goes on to suggest that obfuscating the id in the URL only is a better approach. You can use a symmetric cypher encryption mechanism to obfuscate the id when using it in an URL. There are some trade-offs with this method as well though. You have to take steps to protect that key you are using to encrypt the primary key, else developers on your project will hold the knowledge to figure out what your primary keys are based on the encrypted version. One other thing I’ve done is to not use the obfuscated unique id as the primary key, but as a separate unique key on the same table, while using an auto-increment field as the primary id.