More Thougths on Maintenance, Updates and Fixing

The issue of maintenance, updates and software fixing actually deserves a few more considerations.

Since a long time, security experts have been saying that software updates are essential for the security of operating systems and applications. A long time ago instead, software updates were considered only when new features or features’ updates were needed. It took a long time but by now, at least for mainstream applications, periodic (eg. daily, weekly, monthly etc.) software updates, in particular for security issues, are standard.

Still there are many unresolved issues. First of all there are still systems which are not updated regularly, among them there are some “mission critical” ICT systems considered so critical that updates are not applied for fear of breaking the system or interrupting the service, and, at the opposite end, some consumer embedded systems considered to be of so little value that a security update feature has been dropped altogether. (In my previous post I briefly mentioned these two classes of systems.)

But there are two other aspects that must be considered. The first one is the time that it takes between the release of the security patch or update by the software vendor or maintainer, and its installation on the system. As in the case of both Bash Shellshock and OpenSSL Heartbleed, patches and updates have been released out of the normal schedule, and they should have been applied “immediately”. To apply “immediately” a patch released out of the normal schedule, one should at least have a way:

  1. to know “immediately” that the patch has been released
  2. to obtain and apply “immediately” the patch to the systems.

Obviously to do this one needs to have some established emergency security procedure in place. One cannot rely on someone reading/hearing the news somewhere and deciding by herself to act as a consequence.

The second aspect, again also relevant in the two incidents mentioned before, is what to do in the time between the announcement of the existence of the bug and the availability of the patch, what is called a 0-day vulnerability. Again there must be some well established emergency security procedure which indicates what to do. The minimum is to assess what is the security risk of running the systems un-patched, to investigate if there are other countermeasures (like signatures for IPS or other network filters, detailed monitoring etc.), and in the extreme case just to turn off the service until the patch is available.

It seems easy, but it is not yet easy to put in practice.

Why the Bash ShellShock bug is so threatening ?

This year we had already at least two bugs which someone claims “have threatened to take down Internet”: OpenSSL Heartbleed and Bash ShellShock.

I will probably be unconventional, but by now I believe that, in particular for the Bash ShellShock bug, a much bigger security problem lies elsewhere.

Indeed my personal experience with the Bash ShellShock has been that most affected systems have been fixed overnight by the next automatic scheduled system update. Some critical systems have been manually updated in a matter of a couple of minutes without any process interruption. So all systems have been fixed as a matter of usual maintenance of ICT systems.

So where is the problem? Why so much hysteria about it? How is it possible that even very large and well-know systems have been attacked exploiting this bug?

Since it seems that as of today there are still many (too many) systems vulnerable to both the OpenSSl Heartbleed and Bash ShellShock, we have to conclude that the problem does not lie with the availability of the fix but with the maintenance procedure of the systems themself.

It is then not so much a problem of the bug itself, but of those managing or designing the systems which adopt this software, and any software at this point.

I can see two major areas where there can be maintenance problems:

  • large systems which are built with the approach “if it is not broken, do not fix it”: often in this case maintenance, even security patches, is not applied, update and patching procedures are complex and executed rarely; of course, if the system has not been designed or configured with the possibility of being easily updated or patched, any vulnerability in any software component can become a real big problem
  • similarly but even worse, are embedded systems which have been designed with the “build it once and forget about it” approach: in this case just the idea of maintenance has not been considered, or it exists only in the form of re-installing the full software (but only if you know how to do it and if a fixed new version of the full software has been made available).

It seems to me that more than blaming those writing and maintaining these software components, we should first think about how to maintain the software on our systems, which are the procedures for normal updates and security updates, etc.

On Cryptolocker and the like

Cryptolocker and similar malware are getting more and more common. The latest versions that appeared work on also Android (one id called Simplelocker). In general what they do is to encrypt some or most of the files on your PC, tablet or smartphone, in particular text, sound, images and video files, which of course includes all your music video library.

Been a ransom, you are asked to pay some bitcoins (or similar untraceable currency) to get your files decrypted.The only defense, a part from keeping your PC clean, up-to-date, with good anti- … whatever … and being very careful on what you click and the email you open, is to keep very updated backups. Indeed once you get infected and locked / encrypted, there is absolutely nothing that you can do to decrypt the files (unless of course if you pay).

The only precaution is to have good and recent backups, and start all-over again from scratch.

But there is a very important point to remember here, not all backups are equal! Good backups are only those done on off-line media, like dvd, blu-ray disks, external usb disks that are connected only for the time of making the backup, and so on. In technical term it is often called an air-gapped backup, that is a storage that you cannot usually access from your device. This excludes most of the Clod storage and backup systems!

The reason for this is that if the backup is on a continuously or very often connected device, and the backup is done automatically as soon as new data is on your device, when the ransomware encrypts your file, the encrypted version is automatically copied on the backup device substituting the original data, and you can end up having also the backup data encrypted.

Note Added: Simplelocker is more a proof-of-concept than a real malware, in these two posts [1] and [2] Simon Bell describes the malware and how to decrypt the files.

Game Over Zeus and Banking Malware

This announcement by US-CERT made me think about the current status of the war (I think that at the moment this is actually the correct word) between attackers / thieves / fraudsters and ICT Security practitioners, Banks, FInancial Institutes etc.

Recently we have seen banking malware using Tor hidden services to hide C2C (Command-and-Control) servers, or as described in the US-CERT announcement, P2P (peer-to-peer) networks. The purpose is the same, to hide the controlling master of the malware, that is the attacker / thief / fraudster her/himself. This also means that recently security practitioners, law enforcement and bank personnel got very good in finding and at least disrupting the C2C servers, otherwise there would be no need to find new ways of hiding them.

But how is this war going, that is, who is winning? Let’s be clear, we, the good guys, are losing.

At first sight the reason for this is simple: there are just too many bugs in today’s software (and possibly in hardware, or at least in embedded software in hardware) and new bugs are added at such a rate that our efforts to ‘secure’ the software are improving the situation a little but not much. It is just a never-ending chase: find a bug, exploit the bug, fix the bug – repeat… It is true that bugs are getting more difficult to find, that software developers are getting better in writing software and fixing bugs, that Bugs-Bounties are awarded to bugs discoverers from software houses etc., but the same happens on the other side and a real market of exploits (to which even secret services and the like participate) of unknown (also called 0-day) bugs exists and flourishes.

In this situation the approach that it is often adopted to protect financial transactions online (web-based) is to balance the costs of defensive measures with the losses to attackers. In the losses one should consider both those direct and those indirect, like bad publicity and loss of customers. Investing too much in some defensive measures could work but could also be a waste of money since the next attack can just avoid the expensive defensive measure and exploit some other bugs or flow in the process or, even worse, human weakness.

This really looks like a never ending cat-and-mouse game.

Hacking ATMs

It is always interesting, almost amusing, to follow what thieves can come up to steal money from ATMs, POS etc. Here one of the latest stunts described by Krebs. How is it possible that the physical security of these devices is so weak? We should be good at least in physical security, since has been around for thousands of years. It is more understandable that we have difficulty in dealing with ICT security, which is a relatively new discipline, and quite complex at that.

Human Factor is Always the Weakest Point

The take-over of the RSA Conference website(see Krebs here for a nice summary) reminds us (as if it was needed) that is not the technology the weakest link (and even less cryptography as such), but us, humans. Two points should be stressed:

  • if system are too complex (like in this case, the relations between content providers of online information) we are not up to the task of managing their complexity and we fail to adopt the needed security measures
  • technology and technical security is best and most easily circumvented and avoided by exploiting the human factor: why deploy expensive and technologically complex malware when you can send an email (well-formed) to ask employees to provide their usernames and passwords to access even mission critical systems? Much easier, faster, less expensive and you are sure to get an obliging answer!

Some Considerations On Heartbleed

The OpenSSL Heartbleed vulnerability is by now well-known to anybody in the ICT security field. At first sight it looked catastrophic, Schneier wrote that on a scale 1 to 10 it was worth 11. At the moment it is not clear which damages it has directly produced, in particular before the public announcement. But what is possibly more worrisome is the future on which there is an ongoing big discussion of which I try to summarize a few points:

  • this is an extremely serious bug in a security library used but almost everybody, OpenSSL is indeed embedded in many software products, how long and how hard will it be to update all software? Major software producers have and will have a hard time to update all their programs to run with a patched version of the library.
  • but even more difficult is the process of getting all users of vulnerable applications to update them; in particular all embedded systems (think as a simple example about routers and firewalls with VPN capabilities) which often do not have simple ways of updating their software
  • and what about the Internet way of producing the so-called “Open Source” software (and sometime also hardware)? One of the great forces which helps the development of Internet is the “free” availability of fundamental components of it, but who is providing these components? There are some large companies which do support directly some of these, but other projects, like OpenSSL, are mostly run by volunteers in their free time, how can Internet rely on this? (Not from a technical competence point of view, most of these people are the brightest and more competent that there are, but from the availability and support point of view). How can we at the same time still have “open” or “free” software and guarantee availability, correctness, support etc., all characteristics which require infrastructure, commitment and first-of-all money?

On Target and other Breaches

These days one of the top IT security news is the one concerning the Target breach which allowed the criminals to steal up to 40 million credit and debit cards data (see Krebs On Security for details). What is very interesting is the complexity of the entire operation. This is not someone who stumbles almost by accident on a bug or a security weakness and exploits it. This, and other similar ones (it is at least a couple of years that similar frauds have been known to be realized), are really criminal operations, well designed, carefully planned and implemented.

It is enough to mention a few details of this breach to understand the complexity of the operation. The malware has been designed and/or modified to fit exactly the environment in which it has been installed. The way of accessing the the IT systems has been carefully studied and most probably has been through a most unlikely third part. The stealthiness of the operation has been extremely good, including the way of exporting the extracted credit/debit card data from the company network into the criminals’ systems.

These are targeted attacks which adopt the best of technologies, included IT technologies but not limited to the IT world. The biggest issue is that the target of the frauds is not the IT, but is the everyday business which must understand that these new kind of frauds are very real and can target everyone.

Home Banking Mobile Apps: unsecure at any speed

Security researchers at IO Active have tested 40 iOS-based banking apps from 60 banks around the world and the results are not reassuring. All apps could be installed on a jailbroken iOS device, 90 percent used also some non SSL links, roughly half of them lacked some security feature or left sensitive information non protected and easily readable.

We have a long way to go before mobile platforms will become safe to use for any use.