Category Archives: ICT

Marketing and Internet Surveillance

Posted on by

The blog post “The Internet of Things that Talk About You Behind Your Back” by Bruce Schneier is really creepy. But it isn’t new, it is just getting worse.

In IT Security, the problem of undetected communication covert channels is old and well known. Also the fact that internet marketing adopts approaches and technologies that some times are close to it, is well known.

What it is worrisome is the extent to which we are getting. There are various aspects to it.

One is the legal aspect, that is what the legislations allow and how much they protect citicizens from excesses: it would be interesting to compare current legislations between different countries, from the USA to EU, Canada, Brazil, Russia, India, China, Japan etc.

On the technical side, devices like PCs and some tablets allow the user some choices like use different browsers (even Tor), manage cookies (in particular 3rd party cookies) etc., even if it is usually difficult to really be anonymous on internet unless extra precautions are taken (and many users will not be able to adopt similar precautions).

On smaller devices, like smartphones and “smart” objects like watches etc., choices are much more limited but with a little bit of effort the user can do something to protect him/herself from this kind of surveillance.

On IoT devices at the moment there seems to be nothing that the user can do, it is either use it and be traced, or do not use / buy it at all. For these devices, legislation could be the only way of giving the user some choices.

Finally, how many users are even aware of this kind of Internet Surveillance? How many would object if they knew?

IT Security, Human Behaviour and Normalization of Deviance

Posted on by

Bruce Schneier has a quite interesting blog posting (read here) on “Normalization of Deviance”, that is the human behaviour for which errors, warnings and the violation of rules or acceptable actions, becomes the norm.

We all know that in IT Security, people are usually the weakest link. We should also be careful that IT security professionals do not fall into the “Normalization of Deviance” syndrome. I try to summarize it in the extreme as follows: the approach that if something bad has happened, like an intrusion in an IT system, but it did not have real consequences and did not cause real damage, then such kind of events can be ignored from now on.

This is a pretty dangerous human behaviour, but unfortunately, as discussed by Schneier and the sociologists who study this field, quite common.

One of the first examples of IoT and security risks

Posted on by

Among IT practitioners there are a lot of ideas and discussions on the “Internet of Things” (IoT) and the security risks associated to them.

If IoT has many positive and useful future developments, the security aspects are very difficult to manage to the point of posing a very big question mark on the idea itself of IoT.

One example is described in the research “House of Keys: Industry-Wide HTTPS Certificate and SSH Key Reuse Endangers Millions of Devices Worldwide” published by SEC Consult, which shows how many hosts, typically home and SOHO routers for internet access, use the same cryptographic keys, which are public and well know, so that anyone can impersonate them and anyone who can intercept their traffic can decrypt it.

Even if the impacts of this vulnerability are probably not very high, it seems extremely difficult to fix, since the new devices will be fixed but the millions already in use will probably never be fixed and will remain active for a few more years.

Even more worrisome is that these are IT devices developed, built and sold by IT companies that should known about IT and IT security. What will happen when billions of devices will be connected to internet (the real IoT) developed, built and sold by non IT companies?

Homomorphic encryption and trusting the Clouds

Posted on by

Homomorphic encryption is an old idea but only in 2009 and the work of Gentry started to have some possible practical applications. Since then there have been quite impressive improvements in the research in this field of cryptography, also due to the need to improve the security of data managed by Cloud systems.

In brief, homomorphic algorithms are cryptographic algorithms that allow to do computations, like sums, multiplications, searches etc., on encrypted data giving encrypted results, without knowing the encryption key.

It should be obvious that these algorithms would be very useful for Clouds’ applications since the owner of the data would be able to use the data remotely by keeping at the same time the data, and the result of the computations, always encrypted in the Cloud application.

Unfortunately homomorphic encryption is not ready yet for general use, but it has just appeared an interesting research paper by Microsoft Reasearch announcing the release of a SEAL (Simple Encryption Arithmetic Library), a library for using homomorphic encryption in bioinformatics, genomic and other research areas.

On Ashley-Madison passwords crack

Posted on by

The Ashley-Madison story just got more interesting with the news that it has been possible to crack the supposedly well encrypted users’ password. As Ars Technica (among others) reports, the account passwords have been managed with bcrypt, and this makes it practically impossible to decrypt.

But the account passwords have also been used to create tokens related to the user’s sessions. In this case the password has been hashed with the broken algorithm MD5. From the token it is then easy to recover a lowercase version of the password, and with just a few tries, in some cases even as few as 256 iterations, it is possible to recover the exact password from the bcrypt encrypted value.

This is again another confirmation that security is not a feature to add somewhere in our IT systems, but a fundamental component of each part of it. Everyone doing IT must at least be security aware . In this case it would have been enough to use the SHA2 hash algorithm instead of MD5 to prevent the cracking of the passwords.

A new Ransomware kind of attack

Posted on by

This describes a new kind of IT ransom which should be much more professional and profitable.

The attacker manages to access some company’s servers, then encrypts the data in the databases but he modifies the DBs access routines to encrypt/decrypt on the fly all data with his own encryption key. In this way for the company all continues to work. He then waits a few months so that all DB backups are encrypted with his keys and at this point deletes the encryption keys from the company’s systems and asks for a ransom to give it back.Notice that backups are unusable because they too are encrypted with the attacker key.

Obviously, strong IT security procedures should prevent and detect this, from off-line testing of backups to intrusion detection.

IT Security and Cars (and the IoT world)

Posted on by

This news is a very good example of how IT security is generally perceived, almost like an annoying add-on or an after-thought, in any case better to think about it later …

Security should be one of the pillar of any IT product and service but very seldom it is.

It will be very interesting to see how Security and IoT (Internet of Things) will go together, the first glimpses are not promising even if many people warn of the possible disasters ahead.

More Thougths on Maintenance, Updates and Fixing

Posted on by

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 ?

Posted on by

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.