Botnet Making Fake SSL Connections

A recent report from CNet relates how a botnet is making fake SSL connections to a variety of popular hosts in order to hide the central control center of the botnet.

The list of affected hosts (from the botnet fighters at shadowserver.org) is enormous; it includes hosts from such people as Ubuntu Linux, Twitter, the US CIA, Last.fm, National Science Foundation (NSF), Dropbox, NASA, the US Army, the US Navy, the Pirate Bay, Wisconsin Unemployment Insurance, IEEE, US National Institutes of Health (NIH), Symantec, Sun, and so many more… Shadowserver.org has more about these fake SSL connects in their January calendar.

The Pushdo botnet is responsible; it reportedly has been around since 2007 and is the second largest botnet in the world. TrendMicro did an in-depth analysis of Pushdo a while back. SecureWorks also has a nice analysis of Pushdo as well. Microsoft’s Matt McCormack had a widely read article on Pushdo.

These SSL connections are never completed, and are mostly just a nuisance for web operators. However, on the other hand, the botnet is a serious problem – second largest in the world after all. We can only hope those that are in the know manage to shut it down soon.

Pay-for-Security: Is it Right?

Is it right for a company or a service to force you to pay in order to be secure? Put another way, you will not be secure from attackers and other nefarious goings-on unless you pay up. The most sinister possibility of these is the chance you could fall prey to identity thieves and spend the next many years cleaning up the mess an identity thief can create.

If you look at a lot of online web services, they will only provide you with secure sessions (using SSL) if you pay. What would be their liability, one wonders, if data sent in the clear was intercepted and used for some ill gain?

Alternately, some computer companies (and even security companies) have taken the stance that, in order to be secure, you must pay for a membership or support contract. If you do not pay, then you will remain insecure (though usually only for a few weeks instead of forever). Thus, patches and notifications of security risks are held back, placing servers across the Internet at risk and affecting thousands of users.

Certainly, enhanced security products may be sold to users and administrators, but what if even basic security requires an up-front payment? Who is liable for the lack of security when even the basic elements are missing?

When is it right to withhold information that would improve the security of servers on the Internet or of users at large? Perhaps the only time is when there is no way (yet) to mitigate the security risk – perhaps.

SSL Protocol Vulnerability – and Confidentiality

There was an SSL vulnerability revealed last week – a design flaw in the protocol itself. There are two very notable things in this news: the vulnerability being in the protocol itself (like DNS and SNMP before it), and the way news of the vulnerability was broken.

The flaw in the protocol was discovered in August by researchers at PhoneFactor, and the vulnerability was released confidentially to those who could fix its problems and produce fixes for the vulnerability.

This flaw was then discovered by an independent researcher, who likewise released the vulnerability confidentially to an IETF security mailing list.

The problem was that a reader of that mailing list did an irresponsible thing and let the news of the SSL protocol vulnerability loose by sending a tweet message about it on Twitter to all of their friends – which meant that the news was set to be released to everyone. Mark Twain said: “Three people can keep a secret if two of them are dead.”. This problem of vulnerabilities and of when and how to release the news is not new; nor is the problem of the unknowing releasing confidential details.

The problem with security vulnerabilities and confidentiality is legend: it has become one of those arguments that never quits: do you release the details of a vulnerability as soon as they are known or do you wait for the fix to be released after confidentially notifying affected vendors? The uneasy answer most often reached is that a combination of both is necessary.

The problem of tweet messages releasing confidential information has happened before; one most notable incident was when Congressman Pete Hoekstra (R-Mich.) let slip news in Twitter about his trip to Baghdad. This news was then picked up by Wired, the New York Times, CNet, and – of course – the Congressional Quarterly.

In the security arena, confidentiality is much more critical – as is evidenced by the fact that Twitter itself was attacked with this vulnerability just in the last few days.

When you “speak” on the Internet, the world will hear: so be careful what you say.

Converting LDAP-UX to use SSL (HP-UX)

The utility used to create and manipulate the keys is certutil, found as /opt/ldapux/contrib/bin/certutil. The certutil utiltiy is actually a tool created by the Mozilla project, and it has a detailed explaination available. HP only supports the use of Netscape Directory Server or Microsoft Windows Active Directory. Mainly, this means that the docs are there and that they will help you if need be; it doesn’t mean it doesn’t work. The relevant documentation (at least for my versions of HP-UX 11i) is:

It appears, however, that there is a more recent version of LDAP-UX:

A good description of the schema LDAP-UX wants was given by Simon Elder in this message. There is a copy of the HP LDAP-UX Schema available; it appears to be some sort of standard POSIX schema.

Here, we assume that LDAP-UX is already configured using non-SSL connections, that the /etc/pam.conf has been configured, and that the name service switch file /etc/nsswitch.conf has been configured.

The best time to set up SSL and TLS is before you run LDAP; however, it is possible to do it afterwards. First, you need the certificate authority (CA) certificate from the server (just one). Make sure your certificate database is cleared first:

rm -f /etc/opt/ldapux/key3.db
rm -f /etc/opt/ldapux/cert[78].db

Make sure that you are deleting the right files. Once these are deleted, change directories to /opt/ldapux and run this command against your server’s key (cert.ca in this example) in order to properly populate the database:

/opt/ldapux/contrib/bin/certutil -N -d /etc/opt/ldapux
/opt/ldapux/contrib/bin/certutil -A -n my-ca-cert -t "C,," -d /etc/opt/ldapux -a -i cert.ca

This will populate the database that the LDAP-UX client uses. Then run the set up to reconfigure:

cd /opt/ldapux/config
./setup

When the setup program asks if you want to re-enter the data (server, etc.) answer Yes. The program will then fully configure the client to use SSL, and will restart the client when necessary.