Phil Perry | www.pendre.co.uk

Security through obscurity and SSH

January 16th, 2009

Security through obscurity is generally considered to be a bad thing, especially when it relates to bugs in software or encryption methodologies. It is not about making a product or service more secure, but rather hiding some detail or vulnerability in the hope that no one finds it.

However, we can sometimes use the principle to good effect so long as we understand the limitations. Take securing the commonly used SSH service, for example. We often recommend running the SSH service on a non-standard port as a way to prevent the vast majority of brute-force attempts to crack system accounts. Anyone who operates an SSH server on the standard tcp port 22 will be very familiar with the many logged attempts to gain access and simply moving SSH to a non-standard port will eliminate the vast majority of these attempts. Why does this work? Well, the bad guys will typically scan a network segment for IP addresses running SSH services on port 22 and then run automated tools against identified hosts to attempt to gain access using commonly used username/password combinations. How successful are they? If they weren't getting some success then they wouldn't still be doing it. If you think your SSH server won't get detected or noticed amongst the millions of others out there then you are wrong. The average IP address will get probed on port 22 around 3-5 times per day. Interestingly, recent studies estimate that any reasonably sized botnet is capable of scanning the entire IPv4 address space for a single port in a single day so the bad guys have the capability to locate every single SSH server on the Internet running on port 22 in a day. That's scary!

By moving SSH to a non-standard port we are hiding our needle in the proverbial haystack of 65,535 available ports. But it's important to understand that it's still security through obscurity as we haven't improved the inherent security of the service, just made it harder to find. The popular nmap network scanning tool will by default scan about 1600 of those ports. However, if a determined attacker or one launching a targeted attack decides to probe your IP address they will still find the hidden SSH service if they happen to knock on the right port:

[root@Quad ~]# nmap -sS -sV -p 2222 -P0 172.27.6.10

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2009-01-15 23:59 GMT
Interesting ports on host.example.com (172.27.6.10):
PORT STATE SERVICE VERSION
2222/tcp open ssh OpenSSH 4.3 (protocol 2.0)

Nmap finished: 1 IP address (1 host up) scanned in 0.095 seconds

So picking a non-standard port a little less obvious than port 2222 is probably a good idea!

Taking it a stage further

However, we can take the concept a stage further. Besides hiding our SSH service on a non-standard port we can also run a second instance of the service on the standard port. Why would we possibly want to do that I hear you ask? Well, the second instance running on the standard port can be configured as a dummy service on which it is impossible to log in. The principle here is that we show attackers a door, the wrong door, in the hope that they will then hammer away at it rather than go looking for the real door. An example of how to run a second instance of SSH is detailed here. Once the second instance is set up it should be deliberately (mis-)configured to not allow logins. The simplest way to achieve this is probably with the AllowUsers directive by specifying a non-existant user (you MUST specify something - a blank AllowUsers will allow logins from ALL users):

# /etc/ssd/sshd_dummy_config

Port 22
PermitRootLogin no
AllowUsers none

Here we configure the dummy SSH daemon to run on the standard port 22, to not allow root logins (always a good idea) and to only allow logins from the user 'none' which (presumably) doesn't exist on the system. Now anyone attempting to gain access will be invited to enter their password none the wiser that it is impossible to log in as there are no valid username/password combinations.

Hopefully I have shown how with a little creative thinking we can use security through obscurity to our advantage to trick even the most determined of attackers into hammering away on the wrong door. Show the attacker what they are expecting to see whilst hiding away the real entry point. In addition, we can also use the dummy service for logging failed attempts and gaining valuable insight and information about those trying to gain access to our systems. But of course it's still security through obscurity.

MD5 collision vulnerability could lead to SSL certificate forgery

December 30th, 2008

Today researchers at the CCC congress in Berlin announced weaknesses in the MD5 hash algorithm used by some SSL certificates. Using these weaknesses, an attacker could obtain fraudulent SSL certificates for websites they don’t legitimately control.

SSL certificates are commonly used for the HTTPS protocol and serve two main purposes:

  • to confirm the authenticity of the website being visited
  • to encrypt communications between the website and user

So, for example, when you visit your online bank the certificate used by your bank firstly confirms to you that it really is your bank that you're communicating with and not some phishing site pretending to be your bank, and secondly the communications between the bank and you are encrypted so bad guys can't intercept your transactions and discover your details.

It's all about trust

SSL certificates are widely used on the web for anything requiring trust or encryption. SSL certificates are signed by a trusted certificate authority (CA) known as a root CA. Root CA certificates are bundled with your browser so that any certificate signed by a root CA is automatically trusted by your browser. We place our trust in these bodies (for example, VeriSign, Thawte etc) to make sure they only sign certificates for people once they have confirmed that they are indeed the rightful owners of that site. For example, you or I couldn't simply obtain a certificate for barclaysbank.com, set up a fake website and go phishing. Or at least we couldn't if users noticed that the site wasn't using the secure HTTPS protocol or had an invalid certificate.

The root of the problem

The root of the problem is that many root CA's still use an old insecure hashing algorithm (MD5) to sign certificates. In today's announcement, researchers disclosed that they had been able to exploit weaknesses in the MD5 hashing algorithm such that they could produce fake root CA certificates, thus allowing them to sign their own fake certificates for any site that would automatically be trusted by all web browsers.

This has huge implications because users can potentially no longer trust certificates. I say potentially, because of a number of important mitigating factors. Firstly there is no evidence of this being exploited in the wild already thus we can conclude it is still a new discovery. Secondly, the researchers disclosed the weakness responsibly - they have yet to reveal full technical details as to how to exploit the weakness. Thirdly, the researchers did not simply stumble across the weakness, but rather are a group of highly skilled mathematicians, cryptographic experts and programmers. It is unlikely that many will have the technical expertise to figure out the details even after this disclosure. Lastly, significant computer resources were required to compute the MD5 hash collision - it took the researchers 3 days of computing time on a 200 machine cluster. The last point is somewhat moot as bot masters often have thousands of PCs under their control so once technical details are in the public domain the threat becomes very real very quickly.

The implication of this weakness is that users can no longer 100% confirm the authenticity of the website being visited. Communications will still be encrypted, just that you may not know who you are communicating with. Combined with the major DNS flaw discovered by Dan Kaminsky (see 22nd July, 2008 entry), phishers now have everything they need to produce phishing sites that are virtually undetectable even to the most tech-savvy vigilant users. Furthermore, SSL certificates are not just used for the HTTPS protocol so other protocols using SSL/TLS are also vulnerable to this weakness. For example, SSL-based VPN, SSL/TLS encrypted SASL and/or POP3S email are also vulnerable (SSH is not affected).

Mitigation

This is not an easy threat to mitigate against. Vendors such as Microsoft and Mozilla have been quick to point out that this is not a bug or vulnerability in their software, nor is it a vulnerability in the protocols that use SSL. Rather it is a weakness in the way root CA's are signing certificates. A more secure hashing algorithm (SHA1) is available and root CA's are urged to stop using MD5 hashing and switch to SHA1 immediately. In the meantime there is little the end user can do other than stay vigilant and insist that any certificates you purchase for your own sites are not signed with MD5 hashing. Even so, that doesn't mitigate the fact that anyone could still fake a certificate for your site (or any other) regardless of the hashing algorithm used on the genuine certificate.

WPA Wi-Fi encryption cracked

November 6th, 2008

WPA Wi-Fi encryption, the security that prevents unautorised users from accessing your wireless networks, has been cracked. Researchers report that the TKIP keystream may be decrypted in as little as 12-15 minutes:

More information here

So with both older WEP and now WPA security compromised, the only way to currently secure a wireless network is with the newer WPA2 encryption protocol. However, much older hardware doesn't support this newer protocol so check your hardware for support, switch to WPA2 if available or upgrade/replace your hardware.

For those that don't take the potential threat seriously, allow me to put it in context by reminding you of T.K.Maxx who were in the process of upgrading the WEP encryption to WPA on their wireless cash registers used to transmit customer credit card transactions when they were hacked and subsequently lost hundreds of millions of customers credit card details in an incident that still remains one of the most widely publicised security breeches ever. I'm sure T.K.Maxx have learnt their lesson so let's make sure we learn from their mistake too rather than repeating it.

Firefox security update

September 24th, 2008

Mozilla have released a critical security update for version 3 (3.0.2) of their popular Firefox web browser.

Users are advised to update immediately.

Thunderbird 2.0.0.16 released

July 24th, 2008

Mozilla have just released a new version of their Thunderbird email client that fixes a number of security issues:

  • MFSA 2008-34 Remote code execution by overflowing CSS reference counter
  • MFSA 2008-33 Crash and remote code execution in block reflow
  • MFSA 2008-31 Peer-trusted certs can use alt names to spoof
  • MFSA 2008-29 Faulty .properties file results in uninitialized memory being used
  • MFSA 2008-26 Buffer length checks in MIME processing
  • MFSA 2008-25 Arbitrary code execution in mozIJSSubScriptLoader.loadSubScript()
  • MFSA 2008-24 Chrome script loading from fastload file
  • MFSA 2008-21 Crashes with evidence of memory corruption (rv:1.8.1.15)

Users are advised to upgrade immediately.

Major DNS security flaw

July 22nd, 2008

In a major collaborative effort over 80 vendors simultaneously released patches to their DNS software to address a critical vulnerability. DNS, the Domain Name System, forms the basis of how today's Internet works by translating domain names into IP addresses and vice versa. Without DNS you wouldn't be able to type a domain name (such as bbc.co.uk for example) into a web browser and reach that site.

The current flaw in DNS potentially allows hackers to poison the DNS system and redirect users to malicious sites rather than the site they intended to visit. The researcher that discovered the flaw, Dan Kaminsky, had attempted to keep technical details of the vulnerability secret until next month in order to give system administrators time to patch their servers against the flaw. However, details of the vulnerability were revealed yesterday before many systems have been patched.

In a worst case scenario a major ISPs DNS servers could be subverted redirecting a major site such as Google to a malicious site designed to infect visitors PCs with malware. Such a scenario could result in hudreds of thousands of computers being infected in a very short period of time. With such rewards on offer you can bet the bad guys will be all over this in a flash.

What should you do?

Users are strongly advised to test their DNS servers now to see if they're vulnerable. Dan Kaminsky has a "Check My DNS" applet available on his site here.

If your DNS servers are vulnerable you should contact your ISP (or whoever provides your DNS) and inform them, plus ask them when they intend to patch their servers.

If your DNS servers are vulnerable then you can use the freely available DNS servers provided by OpenDNS until your normal servers can be patched. Windows users should go to Control Panel > Network Connections and right click on the connection and select "Properties". Then select Internet Protocol (TCP/IP) and click Properties. Select "Use the following DNS server addresses" and enter the following two IP addresses for the Preferred and Alternate DNS servers, respectively: 208.67.222.222 and 208.67.220.220. Linux users should edit the nameserver values in /etc/resolv.conf

Additionally, if you use a home router to automatically assign network settings then you should also update the DNS server settings in your router.

Users are then advised to retest to ensure their DNS servers are no longer vulnerable.

Firefox security updates

July 17th, 2008

Mozilla have released security updates to both version 2 (2.0.0.16) and version 3 (3.0.1) of their popular Firefox web browser.

Firefox version 2 will be supported until December 2008 so users are encouraged to upgrade to version 3 if they have not already done so.

A rant about software updates

June 27th, 2008

Adobe have recently released a security bulletin for Acrobat (and Acrobat Reader) affecting the latest versions of both 7 and 8.

Nothing new there, so why the rant?

Well, firstly the security update is not picked up through the application's builtin update feature (Help menu > Check for Updates) so unless you happen to regularly follow security blogs, how are end users supposed to know it's been released. Secondly, the download is in the form of a Microsoft .msi file and how many end users would know what to do with one of these? Finally, after successfully updating a system there doesn't appear to be any easily visible record that the patch has been applied making it difficult for system administrators to track which systems have been updated and which haven't.

With the current trend of exploiting vulnerabilities in 3rd party applications (Adobe Acrobat) and browser plugins (Adobe Flash), software vendors need to do more to ensure they deliver software updates in a timely and coherent fashion. In short, they need to do more to ensure end user systems stay fully patched.

End users, and home users in particular, don't always have system administrators to look after their machines, ensuring that all the relevent security patches have been applied and the Bad Guys know this and take advantage by targeting these applications and browser plugins. All it takes is for one email with a link to a malicious PDF file hosted on some website, click on it and you're infected.

Delivering updates

One way to address the paradigm of delivering software updates might be for Microsft to open up their Microsoft Updates site to 3rd party software vendors and allow them to automatically deliver their updates through that system thus ensuring that all users receive them. A "one-stop-shop" for updates really is what's needed as it's no longer reasonable to expect users to go trawling the web in search of the security updates they need. Software with an automatic update feature built in was a step in the right direction, but as Adobe have just shown it's not infallible and only works when they deliver all updates through that mechanism.

In the meantime, services such as Secunia's Online Software Inspector provide a valuable service to end users for ensuring that their systems are kept up to date.

OpenSSL: Predictable PRNG in debian-based systems

May 13th, 2008

A critical bug has been found in the Pseudo Random Number Generator (PRNG) used in OpenSSL in debian Linux and it's derivative (e.g, Ubuntu etc) that renders random numbers predictable. The bug was introduced into debin unstable on September 17th, 2006 and has since propogated into the stable branch. All keys generated on affected systems should be considered compromised.

http://www.debian.org/security/2008/dsa-1571

http://www.ubuntu.com/usn/USN-612-1

I don't use debian (or Ubuntu), so how does this affect me?

The impact of this vulnerability is far reaching and goes way beyond debian-based systems. The vulnerability directly affects all debian-based systems using OpenSSL generated keys (OpenSSH, OpenVPN, website and mail server authentication by SSL/TLS, etc) and potentially affects anyone using SSL-based security or encryption.

OpenSSH

If you have a Linux server, then you almost certainly have SSH configured by default for remote access. If you use public/private key authentication and users have generated keys on affected systems, then brute-forcing those keys to gain remote access is trivial and there are already scripts available in the wild. The same applies to OpenVPN. The important facor here is the system the keys were generated on, not whether your server is running debian or other affected Linux distribution.

Additionally, all DSA keys that were ever used on a vulnerable debian-based system for signing or authentication should also be considered compromized due to a known attack on DSA keys.

System administrators are advised to conduct a full audit of all key pairs and regenerate new keys where appropriate.

SSL-encrypted websites and mail servers

Users of debian-based systems running SSL encrypted websites or mail servers using SSL/TLS certificates generated on affected systems should generate new certificates immediately. Additionally, if you have had your certificates signed by Root Certificate Authorities (eg, Twarte, VeriSign etc), then you will need to generate new certificates and get these resigned.

By definition, the public key is publicly known, and therefore it is trivial to generate a matching private key. It then becomes trivial to launch man-in-the-middle style attacks against encrypted or secured transactions such as credit card or other banking transactions or to obtain users login credentials. The potential for exploitation is huge and has the potential to affected all users of the Internet.

If you are at all unsure about how to generate new keys or certificates, please do not hesitate to contact us and we will be happy to assist in generating new OpenSSL keys or certificates for you.

Thunderbird 2.0.0.14 released

May 1st, 2008

Mozilla have just released a new version of their Thunderbird email client that contains a number of security fixes

  • MFSA 2008-15 Crashes with evidence of memory corruption (rv:1.8.1.13)
  • MFSA 2008-14 JavaScript privilege escalation and arbitrary code execution

Users are advised to upgrade immediately.

AVG Anti-Virus Free version 8 released

April 28th, 2008

Last week Grisoft, the makers of the popular AVG Anti-Virus program, released version 8 of their free product.

Users are recommended to upgrade, and the new version can be downloaded here

As Grisoft state, "AVG Anti-Virus Free Edition is only available for single computer use for home and non commercial use."

The six dumbest ideas in computer security

April 25th, 2008

Sometimes those of us working in the Information Security (InfoSec) business feel like it's nothing but doom and gloom, and for the most part, that's probably not an unrealistic synopsis. So here's a little lighthearted weekend reading:

The six dumbest ideas in computer security

"Let me introduce you to the six dumbest ideas in computer security. What are they? They're the anti-good ideas. They're the braindamage that makes your $100,000 ASIC-based turbo-stateful packet-mulching firewall transparent to hackers. Where do anti-good ideas come from? They come from misguided attempts to do the impossible - which is another way of saying "trying to ignore reality." Frequently those misguided attempts are sincere efforts by well-meaning people or companies who just don't fully understand the situation, but other times it's just a bunch of savvy entrepreneurs with a well-marketed piece of junk they're selling to make a fast buck. In either case, these dumb ideas are the fundamental reason(s) why all that money you spend on information security is going to be wasted, unless you somehow manage to avoid them.

For your convenience, I've listed the dumb ideas in descending order from the most-frequently-seen. If you can avoid falling into the the trap of the first three, you're among the few true computer security elite."

Another Firefox update (2.0.0.14) released

April 17th, 2008

Hot on the heels of last month's security release, Mozilla have just released another stability-related update to their Firefox web browser, this time fixing a JavaScript bug

Firefox 2.0.0.13 released

March 26th, 2008

Mozilla have just released a new version of their Firefox web browser that contains a number of security fixes

  • MFSA 2008-19 XUL popup spoofing variant (cross-tab popups)
  • MFSA 2008-18 Java socket connection to any local port via LiveConnect
  • MFSA 2008-17 Privacy issue with SSL Client Authentication
  • MFSA 2008-16 HTTP Referrer spoofing with malformed URLs
  • MFSA 2008-15 Crashes with evidence of memory corruption (rv:1.8.1.13)
  • MFSA 2008-14 JavaScript privilege escalation and arbitrary code execution

Users are advised to upgrade immediately.

Another major spam run of storm worm

March 3rd, 2008

Today we saw yet another major spam run of the storm worm. Messages typically referred to a funny postcard (or ecard) and provided a link of the form http://ip_address contained within the message body. Clicking on the link would take a user to a website that will infect their computer with the storm worm virus. Users are reminded never to click on links in emails.

Our email servers at Pendre successfully filtered these spam messages based on body checks for raw dotted quad ip addresses, a technique regularly used by storm worm and other such spam. As such, users of Pendre email servers were not at risk. Anti-Virus detection of these new storm worm variants is now reasonably good.

Thunderbird 2.0.0.12 released

February 27th, 2008

Mozilla have just released a new version of their Thunderbird email client that contains a number of security fixes

  • MFSA 2008-12 Heap buffer overflow in external MIME bodies
  • MFSA 2008-05 Directory traversal via chrome: URI
  • MFSA 2008-03 Privilege escalation, XSS, Remote Code Execution
  • MFSA 2008-01 Crashes with evidence of memory corruption (rv:1.8.1.12)

Users are advised to upgrade immediately.

vmsplice local privilege escalation in Linux kernel

February 11th, 2008

There is currently a local privilege escalation flaw in the current Linux Kernel, affecting all kernels from 2.6.17 to 2.6.24.1 inclusive.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0600

Exploit code for this vulnerability is available in the wild:

[phil@centos test]$ ls
exploit exploit.c
[phil@centos test]$ uname -a
Linux centos 2.6.18-53.1.6.el5 #1 SMP Wed Jan 23 11:30:20 EST 2008 i686 athlon i386 GNU/Linux
[phil@centos test]$ whoami
phil
[phil@centos test]$ ./exploit
-----------------------------------
Linux vmsplice Local Root Exploit
By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7f0c000 .. 0xb7f3e000
[+] root
[root@centos test]# whoami
root
[root@centos test]#

This vulnerability is not remotely exploitable so an attacker would first have to gain local access, however this could present significant risks for system administrators in shared environments with multiple system accounts.

Patches should be available shortly from distribution vendors and system administrators are advised to upgrade their kernel as soon as these become available.