I recently came across an article on a UK newspaper, the Guardian, about Mt Kaspersky predicting a riot. Well, not exactly. He is predicting a major cyber terrorist attack on UK soil which will disrupt major critical infrastructure.
I find this interesting, not because it is new, it isn’t. I find it interesting because there has been an increasing media visibility and attention to this topic in the last few years. By the way, I am also a big believer of “it will happen soon”. The internet of things is not a secure affair.
And I also find it quite a coincidence that Mr Kaspersky is warning us about a real life Die Hard 4 risk scenario as only yesterday I came across that following article:
Where someone is about to demonstrate in an upcoming conference, in details, how to disrupt the traffic light system used in many countries. Something he has confirmed works and I would be surprised if he doesn’t get into trouble very soon!
The concept of the conference itself is interesting: Infiltrate 2014. No vendor, you do not wear a tag, no photograph, no video, etc.
The security issue related to OpenSSL has been all over the news in the last couple of days.
It is indeed a very bad issue, one that can let an attacker access the login details, including passwords, of registered users from vulnerable Websites/Servers. Yahoo mail, was one of those sites…out of nearly a million others!
This vulnerability has been around for 2 years, it affects servers using OpenSSL 1.0.1 through 1.0.1f (inclusive).
Those servers could be running consumer websites or other applications. For example, the Network Security Monitoring suit: Security Onion, was vulnerable until yesterday when a security fix/update was released. The same applies to the Penetration Testing platform Kali 1.06, which was vulnerable until today!
If those applications/environments were internet facing, userids and passwords may have been compromised in the last 2 years.
This issue allows the attacker to access the memory of a vulnerable server, it means that unless you have logged on recently to that server your credentials are unlikely to be in its memory. Although we don’t know who knew about the issue, now everyone knows! and a lot of people now have access to exploits to leverage this issue.
What does it mean? It means that by blindly changing your passwords on all the websites you have registered in the past, you might end up making it worse for yourself!
Indeed, if the servers you are changing your credentials on are still vulnerable, all you would be doing is loading your shiny new passwords into the servers’ memory waiting to be hacked!
Therefore you should only change your passwords on servers/websites that are no longer vulnerable. To find out, you can ask the relevant webmaster or use one of those online/scripts checks available in the following links:
What is important though, is not to panic. Stay calm, and carry on! You should soon receive emails from a lot of websites telling you they have patched their system and recommend you reset your password.
Along with those genuine emails, you can expect a lot of spam emails so it is even more important to take your time and check those “reset password links”.
EDIT – 11th of April:
As discussed in the link below, it is interesting to note this vulnerability is also impacting client applications using openssl to protect their connection. We have yet to see the full impact this issue will have for both servers and clients!
I have heard of Ubertooth for a while now and it seems it use to attack bluetooth devices keep growing. Once recent attack described HERE can leverage the Ubertooth sniffing capability to crack the encryption algorithm used by the Bluetooth Low Energy (BLE) standard. BLE is also referred to as Bluetooth Smart.
Sure, BLE/Bluetooth Smart is different from Bluetooth, but it is supported by most recent mobile devices (i.e.: the latest iPads and iPhone as well as some Android devices), and will be increasingly used in “smart” appliances, from toothbrushes to fridge if you believe this ARTICLE.
Nonetheless, if you were not convinced before that Ubertooth was a very useful piece of kit, you should reconsider it. Bluetooth is a technology that hasn’t seen much successful attacks until now, mainly because the attack vectors were limited to expensive kit or dark magic knowledge. This, may be about to change and it is as much a good think for driving better security, as it is worrying for the integrity of all our accessories and smart devices we use every day.
In light of all the noise created by the NSA and GCHQ surveillance programs you might be tempted to dismiss governments’ position and view when it comes to IT Security. However, I found that document quite good and high level enough to be understood by mid-level management at least :)
They do refer to an MDM solution for some of the controls without specifying which one, so I assume they are referring to a OS X Server Profile Management solution as described by Apple HERE.
There is an interesting paper from Georgia Tech College describing a clever proof of concept where a phone is used to eavesdrop on keystrokes.
This is done by leveraging the phone motion sensor capability and placing it next to a keyboard. They managed to create a dictionary of words/vibrations that is able to recognise words typed on a keyboard just by analysing the vibrations made from typing.
Of course, you are likely to notice someone’s else phone sitting next to your keyboard but what if your phone got hacked and that software loaded onto it?
They conducted their proof of concept on an iPhone 4 but this is likely to be also possible on other platforms/devices.
In fact, with upcoming smart watches this concept will be even more relevant! Now I can see a use for that Apple M7 chip! ;)
As I am typing this note, my phone is next to my keyboard. Maybe I should move it away…
Apple has just announced two new models of iPhones, one of them is the iPhone 5S which comes with a fingerprint reader. Like others I believe this is no silver bullet, but it is a step in the right direction in terms of helping the masses to secure their iPhones.
There are two main areas of potential security failures:
– Fingerprints can be copied and once compromised you can’t “change” for new ones;
– The Fingerprint reader security implementation will be very important, any defects or flawed could be exploited to gain unauthorised access.
Apple may not be the first company to provide an embedded fingerprint reader into their phones, but like it did for tablets and smartphones, it will be the company that will popularise its usage and set the direction for others to follow. This is likely to be emulated and we will soon see fingerprint reader probably everywhere.
Because it is actually a very convenient way to unlock/authenticate, it is very user-friendly if done right and somewhat secure/unique (as long as they are not compromised). It means users will love it, and prefer that way of authenticating over having to remember a very long password or a different one for each system they need to authenticate too. It makes sense for some kind of password safe to be release at some point, either by Apple or a 3rd party, that would leverage the use of a fingerprint reader to authenticate users to all their systems. In the background you would still be using long, random and unique passwords but as a user, all you would be asked for is to select which website/system you want to sign on and to authenticate with your fingerprint so it accesses that secret password for you and uses it to log you in.
All this is great, and I would love to use such a system. But as fingerprint readers become more and more popular and especially more and more available, so will be the points of failure…
If every device has a fingerprint “read-er”, every device could also act as a fingerprint “captur-er”!
And your precious fingerprints could be compromised through malware or social engineering by leveraging features like guest access, micro-payments, fun apps that pretend to predict your future by reading the shape of your fingerprints, etc.
More importantly, due to the very nature of smartphones today that are using “touch technology”, users’ fingerprints will be left all over the device’s touch screen. It means if someone steal your smartphone, they also steal the very information they need to gain access, your fingerprints. The challenge then becomes about “lifting” those fingerprints from the touch screen to re-use them.
Also, the more popular fingerprint readers become and the more embedded their usage will be in how the masses authenticate to different systems. It means, it will be increasingly attractive for attackers to target such means of authentication. There is already a hacking challenge that will do just that: Hackers iPhone5s bounty.
What Apple has just done is providing an answer to a problem people are increasingly aware off, protecting your password whilst making it simpler to authenticate in the process. This is bound to catch on.
To conclude, in the short term, this will be a huge security set-up for most people, “normal” people who do not handle state/corporate secrets. In the medium to long term, this may actually backfire, because fingerprint alone is no security silver bullet. However, combining fingerprint authentication with more traditional mechanisms such as passcodes or passwords might actually provide extra security through embedded dual factor authentication.
Nonetheless, well done Apple for aiming in the right direction!
The conclusion of that article is spot on:
“MDM solutions are great for employers to manage mobile devices. However, they are not without their problems. Not only was I able to bypass compliance for having a rooted device, but I was also able to bypass the need to encrypt my device from the profileGroupSetting table. Bypassing compliance restrictions for AirWatch is relatively trivial after a few hours and I’m sure it is probably similar with many others MDM solutions.”
An MDM container approach will only ensure your corporate data does not leave that secured container and stays safe within it. However, it does not ensure trojan/malware installed on the Operating System host has not made that hosting environment so “toxic” that low level API haven’t been compromised, i.e.: Bluetooth connection to a keyboard, ability to screenshot, access to memory, etc.
This is why a real improvement on today’s MDM solutions, will only occur when provided natively to the devices and offering OS level containers with specific containers/profiles according to the level of security required. One that needs to be provided through and by Apple/Google. Until then, MDM will just be a nice add-on that improves security against common miss-use but not against seasoned hackers. Depending on your business requirements, today’s MDM could be just enough!
An article was discussed last month in The Guardian and The BBC explaining how a research paper from the University of Birmingham had been barred by a judge from being published because it discussed weaknesses in the security related to cars starting mechanisms from many manufacturers (BMW, Porsche, Fiat, Peugeot, etc).
This was already discussed publicly at the 21st Usenix Security Sympposium, where an online video is available. A quick search on Google also produces a PDF paper explaining how a car can be gone in 360 seconds through hijacking car key transponders. If that was the paper stopped from publication, then I don’t think it provided enough details that warranted those legal actions.
This opened a debate about free speech, the right to do and publish research versus responsible vulnerability disclosure.
But what is a “responsible way” to disclose vulnerabilities? It seems the common consensus among white hat hackers and researchers is about giving time for the vendor/manufacturer and eventually publishing the vulnerabilities. “Time” is usually 6 months, after which most hackers/researchers will argue the vendor is not reacting fast enough and for the greater good the vulnerability should be published to kick those vendors into action.
But is it really always for the greater good?
In this recent car hijacking example, the researchers have indeed notified the car manufacturers and very little was done 6 months later. All those cars could be hijacked in a few minutes with their knowledge of the vulnerability (and the right RFID equipment), so by publishing a paper describing how this could be done it would force those vendors to finally fix that flaw. But it would also give further knowledge to criminals to potentially steal cars!
How this could be considered responsible disclosure? putting further pressure on vendors, yes. But facilitating in the process further criminal activities, maybe not.
Being responsible in disclosing vulnerabilities is not just about waiting a set amount of time, it is also considering the impact this could have on all the parties involved, including the end users! And therefore trying to balance the need to put pressure on the vendors whilst still protecting users from a given vulnerability, isn’t it the main goal to do the research in the first place?
It is human nature wanting to shout to the world our accomplishments, our Eureka moments, discoveries we feel will have a major impact, etc. That “responsible disclosure” principle goes in the way of this urge to claim/inform others about what is important to us; taking the time to reflect on it is therefore often lost in the process.