I realised the other day that I’ve been doing public speaking for quite a while now (started with doing internal training courses back in the 90’s, and graduated on to doing external speaking at seminars and conferences about 10 years back).
One of the perennial problems in security is the lack of hard data, so it’s been good to see over the last couple of years a growing number of reports coming out which seek to shed a bit more light on what’s happening in InfoSec. One of the more prominent of these reports is the Verizon Data Breach Investigation report and I always read it as it has some interesting insights into what’s happening in areas that I don’t get too much exposure too.
Last week I did a presentation for the Securi-Tay Conference. The title of the talk was “Security and ‘modern’ software development”, and the main theme of the talk was looking at library repositories like Rubygems, npm and NuGet and how an attacker could try and place malicous content into those locations.
Like most web application testers, I’m a fan of using Burp Suite for automation and generally making the process of completing a test a whole lot easier.
I’ve had cause to work with some of the more common Vulnerability Assessment scanners recently, and I couldn’t help but notice that a lot of the findings related to incorrect configuration of, or bugs with, SSL implementations.
So like most things in security, decisions are made based on a set of assumptions, and it’s when these assumptions prove to be faulty that security can go quite badly wrong.
I was thinking about a fairly common assumption recently in light of Apple’s new continuity feature. Over the last couple of years as the weaknesses in password based authentication models become ever more apparent, there’s obviously been a drive to improve authentication, and one method of doing this is through the use of different channels to send authentication tokens “out of band”.
One of the more common methods of doing this is to send authentication tokens over SMS messages. The theory is that this is a separate channel from the PC or tablet that is the primary device being used, so it should be harder for an attacker to compromise both channels, thereby improving security.
For example if we have an attacker who has access to a users PC (for example having placed malware on it which steals passwords and other data entered there), the idea goes, by adding in SMS, we make it harder for the attacker to compromise the whole authentication mechanism.
You can probably see, based on the starting paragraph, where this assumption is starting to fall down… With features like Continuity or, SMS to email applications or phone carriers who provide websites which allow for viewing and sending SMS messages, the barrier between these two channels is effectively pierced and SMS becomes much less useful as a second factor for authentication.
Now if an attacker can compromise the PC, it’s quite likely that they’ll get access to the users SMS messages at the same time, with all that entails.
Hopefully this line of thinking will penetrate with service operators and they’ll realise that if 2-factor/channel authentication is needed for their service, they’ll need to offer something more robustly separate.
The other thing I thought this was an interesting illustration of, is that this to me is a good example of differing incentives in the security world. Online service provides have the incentive for SMS messaging to be a good 2nd channel for authentication data as it’s something that almost all their subscribers already have access to, and it’s very cheap to use.
On the other hand, mobile operators and mobile ecosystem providers have no such incentive. Instead they’re working to make it easier for users to access all their information in a single place….
So how do we know that the sites we use are secure? It’s an obvious question with no brilliant answer but here’s an example of how we don’t.
This took me a little while to track down all the piece so possibly worth a blog post (if for no other reason that so I can find it again).
For a long time the subject of browser password storage has been a relatively contentious topic in the Information Security world.
Unless you’ve been living under a rock for the last couple of days you will have noticed a bit of a kerfuffle about a vulnerability in OpenSSL. One of the more notable parts of this story has been the wide variety of large companies who have been seriously affected by the problem.
