Schwer Log

Sometimes I want to view a GPG/PGP public key, but I don’t want to import it into my key ring, so here’s how to just view it:

gpg --with-fingerprint schwer.asc

Know your Enemy: Tracking Botnets
“Honeypots are a well known technique for discovering the tools, tactics, and motives of attackers. In this paper we look at a special kind of threat: the individuals and organizations who run botnets. A botnet is a network of compromised machines that can be remotely controlled by an attacker. Due to their immense size (tens of thousands of systems can be linked together), they pose a severe threat to the community. With the help of honeynets we can observe the people who run botnets – a task that is difficult using other techniques. Due to the wealth of data logged, it is possible to reconstruct the actions of attackers, the tools they use, and study them in detail. In this paper we take a closer look at botnets, common attack techniques, and the individuals involved.”

An excellent paper from the German Honeynet Project group. My favorite quote from the whole paper is; Script kiddies apparently consider DDoS an appropriate solution to every social problem.

Full disclosure of T-Mobile flaw (Simple to fix never fixed)
“Late last year I was in contact with T-Mobile’s CSO because of a
major flaw in their voicemail platform. As of early February 2005, it was still vulnerable. Using my own custom PBX system I am able to dump into any of their voicemail boxes by *default*. ”

Jake has been warning those of us around him about this forthcoming exploit for months and it looks like he is finally ready to publish. Cheers to Jake; jeers to T-Mobile.

As noted on slashdot ([1] , [2]) earlier this week; famed cryptologist Bruce Schneier noted in his blog entry that the hashing algorithm SHA-1 had been successfully broken. While the new advances against SHA-1 are computationally feasible they are still quite difficult, however the general recommendation is that people move away from SHA-1 for digital signatures.

Moving away from SHA-1 for digital signatures when using GPG may take a little bit of work since SHA-1 is the default hashing algorithm for digital signatures.

First you will need to upgrade to GnuPG 1.4 if you have not already; this is because the previous versions of GPG lacked support for writing SHA256, SHA384, and SHA512. Unfortunately the package maintainers for many of the Linux distributions have not been keeping up, so finding a GPG 1.4 package may be difficult; even though the announcement for 1.4 states that 1.2 reached its end of life cycle last month. I recommend contacting your distributions GPG package maintainer, and giving them a friendly nudge to keep up to date.

Once you have upgraded you can pass the command line option (or put it in your ~/.gnupg/options file) –digest-algo sha256 (or sha384, or sha512) to sign your messages with the updated hashing algorithm. However if you are like me and chose the default key pair when generating your keys, then you have a DSA signing key and an ElGamal encryption key; which due to limitations in the DSA algorithm means that you will get this error when trying to sign with anything other than a 160 bit hashing algorithm (which SHA-1 is):

gpg: DSA requires the use of a 160 bit hash algorithm

The solution is to generate a subkey. Subkeys are extremely handy for just such a job; when generating a new key pair would mean losing all of the signatures you have worked so hard to gather, but you need a new encrypting (or in this case signing) key.

To generate a new subkey begin by editing your key (–edit-key ‘name’), then choose addkey, and finally choose RSA (sign only). That’s it; now you can use the newer SHAs.

One final note: Enigmail the GPG plugin for Thunderbird does not support SHA256 and above for PGP/MIME. The reasoning behind this decision can be found on this Enigmail mailing list thread.

A friend of mine recently had his web server cracked, assumedly through an OpenSSH exploit. So I figured it was a good time to jot down a few of the tips and tricks I have found over the years for locking down an SSH server.

First off, anyone who wants to lock down sshd should get cozy with the manual for sshd_config.

• Use a non-standard port.

Usually the SSH server listens on port 22. You can thwart most port scans of your machine by running your services on non-standard ports. In the sshd_config file this is achieved with the Port attribute. Then on the client side you can specify your designated port with the -p option.

• Passwordless logins only.

A password is much more difficult to guess when it is a 1024 bit RSA key. So turn off PasswordAuthentication, and generate a key pair using the ssh-keygen tool. ssh-keygen -t rsa will generate two files: id_rsa (private key) and id_rsa.pub (public key) in your $HOME/.ssh/ directory. Just copy your public key file to $HOME/.ssh/authorized_keys on the server you wish to log in to.

• Dis-allow root logins.

You will compound the difficulty of gaining root access on your box through ssh if you simply don’t allow root to log in through ssh. Turn off PermitRootLogin. Now if someone wants to gain root access through ssh on your machine they will have to get through all the above defenses and then guess your root password once on the box.

• Use SSHv2.

It is generally accepted that SSHv2 is a more secure protocol than SSHv1, and it is simple enough to only use version 2. Set Protocol to 2 only.

Those are the basics to locking down sshd through the config file. Another option, if you know you will only connect to your SSH server from a specific machine or subnet, is to drop all other packets at your firewall, but that’s a topic for another entry.

Here is an interesting (albeit lengthy) paper detailing one persons experience interviewing for a job at the NSA.

http://www.fas.org/irp/eprint/nsa-interview.pdf

I saw this in December’s crypto-gram.