Tuesday, June 29, 2010

Datagram Transport Level Security - DTLS

With the never ending onslaught of mobile technology and greater security awareness, I though it might be interesting to look at Datagram Transport Level Security (DTLS). The two main methods of securing internet communication are Transport Level Security (TLS) and IPSec. TLS is most obvious for its implementation in securing HTTP traffic i.e. HTTPS but is also used in other areas such as for secure IMAP and SMTP. Its main limitation is that it requires a reliable transport channel, normally TCP and hence is unsuitable for UDP traffic which today includes Voice Over IP and several gaming protocols. IPSec is suitable for UDP traffic but its implementation is far more complicated than TLS as it is designed for peer to peer communication rather than client server.

This led to the emergence of DTLS which as the name suggests is Transport Level Security with UDP as the transport channel. A very readable paper on its detail can be found here.

One widely available implementation of DTLS is Cisco’s Anyconnect Secure Mobility client. It doesn’t appear to follow the full goals of DTLS as the key exchange and handshaking is established over TLS which results in two channels needing to be maintained.

With the emerging popularity of VoIP clients on smart phones, I expect we shall be hearing more about DTLS over the coming months.

Friday, June 25, 2010

Windows Powershell Remoting

Windows Powershell has always offered much promise but with version 1.0 at least often failed to deliver when you got into the detail. In contrast version 2 seems to offer more hope particularly when combined with the remote management feature that comes as standard with Windows Server 2008 R2 and is available as a download for R1.

My evaluation project was to use Powershell to obtain disk space, audit failures in the security event log and an instant processor reading on a couple of remote servers via a web service over HTTP(S).

The first step was to set up a ‘Listener’ on each of the remote servers for which there is “quick config” option that lets you automatically alter the relevant services, registry keys and other options to get you up and running. Making the changes manually isn’t too difficult if the quick config fails as it did for me.

Stage 2 was to establish a connection or session to each of my remote servers from my PC. There are plenty of options for this stage including authorisation and port number but nothing too complicated. The most difficult part was to get the password used for each session to be read from a file rather than needing to type it in each time. Powershell doesn’t allow you to store your password in plain text which although a ‘good’ thing hinders testing and evaluation.

The final stage was to issue the commands themselves. This proved to be extremely simple with the invoke-command and then either by using Powershell builtin commandlets or via WMI.

Of course the above has been possible before, even with vbscript, but Powershell offers some advantage over its predecessors, not least the following.

  • Commands issued to multiple servers run in parallel rather than sequentially.
  • A command can run in the background.
  • Powershell is extremely good at formatting output allowing the returned data to be easily read.
  • The remote connection is over HTTP(S) which is useful for servers in remote data centres or even in the cloud, e.g. with Amazon’s EC2.
  • The remote server listener can be configured to expose a limited set of functionality. Hence even someone with administrative credentials is restricted in the information they can gather.

My overall impression of Powershell 2, particularly the remoting feature is that it is now at the level where it is consistently useful. I’m looking forward to version 3, assuming there will be one.

Monday, June 14, 2010

Like Jacking – Facebook helps to spread the bad news

Facebook has been making the news a lot recently with its so called abuse of privacy. Although certainly important, it’s kind of naïve to post anything to a social network and expect it to be private for ever. I also believe that many people are relaxed about this and some individuals seem positively happy about the fact.

In my opinion Like Jacking poses a bigger threat than weak privacy settings. LikeJacking is based on the Facebook feature that allows web masters to insert a button on their web site which visitors can click on if the like the site content. A link back to the site then appears on the visitor’s Facebook page which is visible to all their friends. The Like Feature is easy to setup and indeed Facebook has a page that will even generate the code for you if you aren’t too hot on HTML and Javascript.

So far so good with no apparent danger. The exploit comes from the fact that it’s not necessary to get a visitor to click on a “Like” button for the link to appear on their Facebook page. There is a good example of how to achieve this here. It’s also easy to manipulate the link and the image displayed with it. It’s quite simple to imagine that someone who visits such a site in error, who also has a lot of Facebook friends, could allow the link to spread in an exponential fashion.

The most obvious use of this exploit is for SPAM purposes. Some people, (well me at least) think that Facebook is exclusively SPAM from people you know so what harm will a little bit more do? It is of course simple to manipulate the “Like” link so that it leads to a website that will attempt to install malicious content on your PC, e.g. keystroke loggers or some kind of botnet for which the consequences can be far more serious. Plenty of these sites exist including ones that you might normally trust. This article reports on a number of websites that have been poisoned via an SQL injection so that a visit to the site will result in an attempt to install Malware .

Thursday, June 3, 2010

HTML5 –The Next Best Thing and the End of Flash

Perhaps fed up with all things Cloud, the IT industry hype machine is turning its attention to HTML5. It shouldn’t really be a surprise given that Steve Jobs has been raving about how it can replace Flash and Microsoft sees their implementation of it as a major selling point for IE9.

When people say HTML5 they often mean CSS3 or one of certain other new web technologies. A good explanation of what is and isn’t HTML5 can be found in this blog from ExtJS.

Despite the hype, HTML5 and related technologies are showing much promise. A good collection of what can be achieved can be found at HTMLWatch. The results are certainly impressive.

Is this really the beginning of the end for Flash? Well Adobe products in general have been a nightmare from a security point of view over the past year, so a viable alternative might be desirable. However, at least part of the reason that so many vulnerabilities have been found in Flash is due to its massive installation base and the subsequent targeting by hackers. It’s not unreasonable to assume that subsequent versions of Flash will be more secure and that the developers who have Flash skills and tools will continue to produce Flash applications.

The real danger to Flash may come from Steve Jobs refusing to allow it on the iPhone and the iPad. Despite the miniscule market share that these products have, they dominate the media agenda. It’s not too difficult to imagine hype beating reason and there being a large scale move away from Flash to supposedly allow for maximum cross platform support irrespective of if this is really true.