Note: Many of the security articles I have written about Apple on this blog are negative and the reader could think I do not like Apple. This is actually very far from the truth, I am a big Apple fan; but I am also a security professional and I do not agree with their overall security strategy.

The title of this post is inspired directly from an Article I read on ZDnet, discussing the latest security threat that infected an estimated half a million Mac with malware: “BackDoor.Flashback.39″.

Mac Trojans are evolving and becoming more frequent, last August a Mac Trojan (Bash/Qhost.WB) was found in a fake Flash updater that once installed would redirect google search results to “bad sites”, then in September another Mac Trojan (OSX/Flashback.A) was found by Intego using a similar exploit mechanism  but with a different payload, this time it was more complex and disabling some security settings on the infected systems as well as attempting to inject some code in running processes to ultimately leak personal information.

Both Trojans had a relatively low success rate, as it relied either on the user to download a file and run it, or… for an attacker to adapt some kind of “EvilGrade” attacks where DNS MIT attacks could be leveraged to intercept legitimate software update requests and replace the update status answers with the need to upload the Mac Trojans.

However, a few days ago another variant surfaced. As mentioned by Intego, this latest threat to Mac Users is more of a “drive-by-download” threat than a “Trojan”. What it means is that malware can be pushed onto a Mac computer just by visiting a compromised site, it does not require for the user to take any actions such as entering their passwords or confirming for a new software to be installed. The compromise happens silently!

As a result, the infection rate is much stronger: More than half a million Mac users! and the impact is much worse: it will leave the victim’s computer vulnerable to be remotely commanded as part of a Botnet.

To check if your mac has been infected you can follow those STEPS.

It could be considered as the first major security crisis to affect the Mac OSX, one that will have the first major exposure in the media (BBC, CNN,  FORBES, etc) and one, I hope, that will pave the way for Apple to rethink their security strategy (although I have very little hope!). The fact this Java vulnerability was known a couple of months ago and that Oracle had provided a patch since the 14th of February does not play in Apple’s favor. By wanting to control everything (including Java updates) Apple is playing with fire when it comes to IT Security. This is hardly surprising, although I am very tempted to say “I told you so, HERE and HERE“, I will just echo the ZDnet article I mentioned at the beginning, this security mess is the result of Apple being in denial with the IT security landscape and the threats that every computer and user faces regardless of the Operating System they are on.

This state of denial is also exploited by the “Trojan” itself as it will apparently not install if it finds some software that could be used to analyse it and therefore not target a computer belonging a user that may be aware that there is more to security than a slogan “I am a Mac, I am secure”

[There is a video that cannot be displayed in this feed. Visit the blog entry to see the video.]

About a month ago, Arts Technica ran an article about the encryption standards used by satellite phones that have been broken.

This is yet another exemple of a proprietary encryption system which appears to have been weakly designed and implemented.
Although they have only been able to break the communication from the Satellite to the phone and not the other way around, it should still be of concern for anyone using those phones to transmit sensitive information without additional security.
Even if the audio codec still needs to be reversed engineered, this should be the easy part of this attack!

Someone is likely to get a great PhD as the paper exposing this issue was co-written by such student.

After looking at the new features listed for Windows 8, one in particular caught my attention: The Picture Password Login.
It is a very refreshing approach to authentication!

You are presented with a photo at log in and instead of entering a password, you have to touch the image according to the “allowed” touch sequence you registered your user with. In some respect it is similar to the existing gesture based authentication mechanisms you can find on some smartphones (anyone remember that feature on the Palm V?!), but I think it is taken to the next step.
Microsoft is maybe trying to do to passwords what Apple did to the Walkman.

By providing you with a photo of your choice (i.e.: your own family picture), and a restricted number of gestures (point, draw a line and circle) it is easier to remember a sequence, more natural and more personal. For exemple, you would circle the head of your best friend, touch the feet of your child and stroke your dog…
It is simple, yet secure because there is a very large  number of possible combinations. Or is there?

I can see the appeal but I wonder about the following:
a) Could someone who know about you guess what you are likely to touch on that photo first, second and third, etc
b) It would be visually very easy to remember, for you… and also for anyone looking over your shoulder!

I am therefore not 100% convinced, but it would make hardware keylogers more difficult to design (softwares one should just work as well as now by providing a screenshot with logged gestures). And it could actually improve security over a complex password on a post-it or a very simple “hello” password. However, how would this work in an open office environment where everyone can see your screen?

In any cases, well done Microsoft! as stated at the beginning of this article it is a very refreshing approach to authentication and a bold one!

More information can be found in that article and below is a demonstration video of this feature.

[There is a video that cannot be displayed in this feed. Visit the blog entry to see the video.]

John Nash is a famous mathematician whose life inspired the Hollywood movie “A beautiful Mind”. However, summerizing his life through that light hearted movie would be very inadequate!

So, this genius mathematician who worked in game theory, differential geometry, and partial differential equations as well as winning a Nobel Prize in 1994 appears to also have had some great insights into modern cryptography… back in the 1950s!

As seen in this article, NSA recently released a series of documents related to letters/conversationa between the NSA and Nash in 1955, where the mathematician made an unsuccessful but noted attempt to communicate his own take on a crypto machine.

If anything, reading at the hand written letters are very inspiring, especially since he was only 27 years old.

There is a new vulnerability with iOS5 powered device with a SIM card. I have tried it and it works.
You need to know the number of your victim and by combining a missed called, removing the SIM card, putting it back in and swiping the missed call alert it is possible to bypass the lock screen and access the phone.

Look at the video from the weirdly named group called iPhoneIslam, you need to get the timing right!
[There is a video that cannot be displayed in this feed. Visit the blog entry to see the video.]

There is an increasing level of noise in the enterprise about Bringing Your Own Device (BYOD). That you like it or not, it is most probably happening right now within your company unless your are “lucky enough” to be able to enforce strict controls as to what devices are allowed and able to access your data.

For a true BYOD concept, meaning with no restrictions on what that device might be, there are only 2 possible way to enable it:

1) To allow network access to your data/application directly from any devices
or
2) To make your data/application available from the Internet, and the easiest incarnation of that is through web applications.

With the first approach, focusing on the network access, the positives are that you can have more control over the environment from which the data/application is accessed from. Such as enforcing a minimum set of security controls and quarantine non compliant devices. The negatives, though, are the need for a relatively complex VPN framework that works on a variety of Hardware/OS to support access to your applications. It will also have a user impact, as if you enforce security policy changes to the user it is likely to change their user experience (i.e.: longer and more complex password, the dreaded password expiry, etc).

With the second solution, direct internet access, the advantage is an easy and fast deployment as well as having no impact on the user experience, their laptop behaviour will not be changed. But the drawback is obviously the security risks related to the front/back end of your internet facing application.

More importantly though, there is an inherent security risk with Web Applications: You cannot control the environment it is being accessed from. No longer do you check for the AV version, the GPO, the Firewall status, etc.

Could those security checks still be done as part of some sort of client java application that would do some security look up as part of the required credentials to access the app?
Yes.

Would it be intrusive?
Yes. Users will have to download some kind of client (Java?), would probably have to get through some warning messages, etc.

Is it done today by any internet facing application in your organisation?
No.

Is this a massive security risk?
Yes, because you are now allowing key applications to be accessed from anywhere in the world and from any devices that has an Internet Client such as a public Internet Kiosk with dozens of malware and key logger…

Whatever way you are looking at it, doing BYOD right from a security perspective is not easy.

The BBC has recently ran an article about a hacker who has published details on how to hack a certain type of webcam. This story is interesting for several reasons.

First, it further highlights how fragile our privacy has become since we live in a digital world with details of our life being kept on the internet: personal blogs, twitter feeds, Facebook or Government/Health records, etc. All this data is available online if you have the right access to the system it is held on. But it is not just still photos or lines of texts, it can also be live pictures through personal webcams or state surveillance cameras. Again, that data is available if you have the right credentials. In this case, hundreds of Trendnet webcam users thought/thinks their live video feed was protected through the use of a userid and password, but a bug in its firmware allows anyone to access it by adding a simple “/anony/mjpg.cgi” at the end of the webcam IP address. If you think about the number of devices around you that have a built-in camera, from computer screens to mobile phones, it is a scary thought if they were to be compromised in such manner. A quick google around will report many different ways to remotely access those cameras, and although they require user intervention, meaning the outcome is what is intended or for the “victim” to be a willing participant, couldn’t a worm be created to exploit those video streams and invade many people’s privacy?

Secondly, it shows how long it can take before such story makes the headline. It took a month from the vulnerability to be exposed and for most security websites to write about it. If means many Trendnet users had their privacy exposed for a long period of time!

Finally, Shodan. It is a website referenced in the original hacking article as a way to quickly identified vulnerable webcams out there (and many other things). I must admit I overlooked that website when I first heard of it on the Register over a year ago. It seems like a great resource but I am not sure if it serves Good or Evil.

It is maybe time to put that sticky tape on your built-in webcam when not using it :)

There has been wide coverage of the naming and shaming of the supposedly perpetrators behind the Koobface botnet that has affected Facebook and other social sites for a few years.

The gang leader was first named on Dancho Danchev’s blog, then the Facebook’s security team threaten and did reveal the gang’s real identity, the New York times even ran an article on it and finally Sophos published another in-depth look at how they also discovered their identity. In between, many other sites jumped in to share that information.

I am slightly uncomfortable with this approach.

It appeared to have worked in this instance as the bonnet Command & Centre has been turned off, and it also appears they named the right persons; but what if all those blogs/researchers made a mistake!? It would have been nothing more than a smear campaign that could have affected the lives of some innocent internet users.

This tactic is used by the police in some countries, so they can catch “real” criminals on the run. They name and shame, appealing for help from the public and thus making it more difficult for them to cary on with their illegal activities.
By “real” I mean criminals in the traditional sense of the term, who have broken the law physically as opposed to virtually. But as our lives become more and more entangled with the virtual world, criminal activities “there” can and do have an impact “here”.

Where I think there is a difference, is that the police conducts a thorough investigation before naming and shaming, more importantly they follow an established, documented and legally sound process to conduct such investigation. Although those security researchers are experts in their own right (pun intended), it is a dangerous game to become a vigilante…

To conclude, I am not fundamentally against this practise but I am concern it could spiral out of control. It also highlights how difficult it is to bring hackers to stop their activities as, this, is some kind of last resort solution.

By websites, I should really have said Web Applications, but the end result is the same: A server which is serving pages on the Internet could see its CPU usage increasing to a level making that server unusable for a few minutes or more. All that from a relatively small specially crafted malicious HTTP request.

This vulnerability exists in most languages used to develop web applications: PHP, ASP.Net, Java, Python, Ruby, etc. And it has been known to exist in theory since 2003!

Last week, Alexander Klink and Julian Wälde explained at the 28th Chaos Communication Congress in Germany how exactly the theory became reality and the impact on the different web application languages were affected.

The core of the issue is the way hash lists have been implemented in those languages. By “Hash” they both refer to a specific type of data structure and the cryptographic function. A Hash list is a type of data structure that is very popular because it stores and accesses data in a list very quickly. Before an object is inserted into a hash list, it is first hashed using a hash function to provide a “unique” hash reference which is then used to access and store the object in the list. To simplify, it replaces the usual [i] of a standard list with a [hash reference]. (“i” being an integer).

In reality those hash references are not so unique and collisions do occur. When it happens the objects with the same hash reference are daisy chained. The longer the chain and the least efficient hash lists become. Under normal operation it does not happen often and this is not a problem.

But as first highlighted by Scott Crosby and Dan Wallach in 2003, data/object stored into hash lists can be manipulated so collisions do happen more often. So much more in fact, it can degenerate the hash list resulting into the server’s CPU going overdrive and bringing the server to its knee in the process.

Alexander and Julian explained at 28c3, as shown in this video, that for Perl the issue was located in how the DJBX33A (PHP5) and DJBX33X (PHP4) functions were generating hashes. Other languages were also vulnerable because they were using very similar functions to generate their hashes.

With the help of CERT they communicated an advanced advisory to the relevant vendors and organisations in early November 2011, after they successfully implemented an attack for most of the languages used by Web Applications. They received different responses, some more satisfactory than others…

Ruby reacted very quickly and has a patch ready, Microsoft has issued a temporary work around for ASP.Net by limiting the number of parameters, PHP and Python needs more time and Oracle, although they have provided a patch for Tomcat and will in a near future do the same for Glassfish, stated that it isn’t an issue for Java. If you watch the 28c3 video you can easily understand they are wrong (clue for Oracle, go to the 32d minute or so). Therefore we should expect a Java patch for the HashTable and HashMap functions soon, albeit too late.

To conclude, this is a serious issue that has now a practical and known way to exploit it, with a global scope and high performance impact. Microsoft in a Technet article has provided a snort signature to detect this type of attack against ASP.Net, it should be fairly easy to adapt for other languages.

The recommendation is to both monitor for a patch related to your web applications (and implement it quickly when available) and to also monitor your network for such attacks (and try to block its source IP if not coming from a distributed attack). You should be reviewing what are the versions of the languages used by your Internet facing web applications and probably also ask your 3rd party partners what they plan to do about it!

A nice summary is also available on Arstechnica.

PS: Thanks to Thierry for pointing the story to me in the first place!

OpenDNS has just release a beta software to enable encryption of DNS queries called: DNSCrypt.

Not encrypting DNS queries can lead to two main type of attacks, as described by OpenDNS:
“First, it prevents man-in-the-middle attacks which can cause malicious DNS responses to be used to trick you into visiting a dangerous website or send traffic to an unintended third party. Second, it prevents snooping by your ISP or any other intermediary who might want to sniff your DNS traffic to see what domains you are resolving.”

DNSCrypt can significantly increase a user web security as until now there was no way to encrypt DNS queries. As stated by OpenDNS, DNSCrypt should be seen as complementary to Domain Name System Security Extensions (DNSSEC) because the later is not use to encrypt DNS queries, but to provide authentication and  chain of trusts.

DNSCrypt is not the answer to every DNS related threats though, as OpenDNS still acts as a relay to the real website’s IP to be accessed, and if the DNS servers it got some of its information from are compromised OpenDNS will still serve you the compromised IP. Also, one of the great advantage of OpenDNS is its ease of use, the fact you just have to point your Router to their DNS servers, with DNSCrypt you need a software to be installed on each machine you want to protect. It would be great to see future routers supporting/integrating DNSCrypt so it is seamless and would also protect any devices connected to that router, including smartphones, tablets, etc.

Nonetheless, this is definitely a step in the right direction! And although it is only available as a MAC Beta, a PC version should be coming up soon. Will it stay a free service, is also something that remains to be seen…