Record High Number of Phishing Attacks in Q1 2016

From the APWG press release: “The Anti-Phishing Working Group (APWG) observed more phishing attacks in the first quarter of 2016 than at any other time in history” (here is the full report).

This is hardly surprising, but it quantifies with numbers the latest news about online frauds, like the “CEO Fraud”, the “Business Email Compromise” (eg. see this FBI announcement) etc.

On a Kernel Backdoor and IT Security

It just became public that a custom built Linux kernel for embedded devices has been shipped and installed in production with a root debug backdoor open to anyone, see here for the announcement and for example here for some more details.

Besides the gravity of this particular incident and the difficulty of remediating it (I expect that many devices shipped with this kernel will never be updated) a couple of considerations come to my mind:

  • first of all the need for IT Security Awareness and Education starting from everybody working in IT : anybody can make a mistake or even a blunder, but there should be safety nets proportional to the risks and IT professional should always be aware of the “security” consequences of what they do;
  • the process of “bringing into production” IT products (aka Change Management) should be improved: as of today most of the time the really important test of an IT product is the final User Acceptance Test, which means that it is only important that the features requested by the final users work as expected. But this is not enough, and it is not like this in many other industries, think for example of televisions, refrigerators, cars etc. they all need to pass safety tests and be labelled accordingly otherwise they cannot be sold on the market. Why is it not like this also for IT products? As of today it is difficult to think of security standards, tests and labels common to all IT products, but it should be possible to agree on and adopt some common IT security baseline.

Monitoring Outgoing Traffic to Detect Intrusions

Monitoring outgoing traffic to detect intrusions in IT systems is not a new concept but often it does not seem to be enough appreciated, understood and implemented.

IT security defences cannot guarantee us against every possibile attack, so we must be prepared to the event of an intrusion and to manage the associated incident.

The first step in incident management is to detect an intrusion. Traditional tools like Anti-Virus, Intrusion Detection/Prevention Systems (IDS/IPS) etc. do their job but they can be bypassed. But intrusions can also be detected by monitoring the outgoing traffic.

In my recent personal experience, some intrusions have been detected and stopped because the outgoing traffic was monitored and blocked. Since the deployed malware was not able to call back home, it did not do anything and there was no damage; and since the outgoing traffic was monitored, the intrusion was immediately detected.

But monitoring the outgoing traffic to detect intrusions is becoming more and more difficult. For example attackers are adopting more often stealth techniques like using fake DNS queries. An interesting example has been recently described by FireEye in “MULTIGRAIN – POINT OF SALE ATTACKERS MAKE AN UNHEALTHY ADDITION TO THE PANTRY” . In this case, malware is exfiltrating data by making DNS calls to domains with names like log.<encoded data to exfiltrate>.evildomain.com . Obviously the DNS query fails, but in the logs of the receiving DNS server it is written the name of the requested domain, that is the data that the malware is exfiltrating.

As attackers are getting more creative to hide the back communication between malware and their Command & Control services, IT Security will need to devise more proactive approaches to monitoring and blocking outgoing traffic.

NTIA Request for Comment on IoT Policies

The National Telecommunications and Information Administration (NTIA) of the US Department of Commerce’s Internet Policy Task Force, has announced a Request for Comment on the key issues regarding the deployment of Internet of Things.

This is one of the first steps towards creating some policies and / or regulations on IoT devices, and can be a very good occasion for stating clearly some security baselines.

IT Security Programme Cheat Sheet

Organizing my ideas, I came up with this IT Security Cheat Sheet, nothing really important should be missing, but in case drop me a line:

  1. Know your IT assets, often attackers know them better than you do

  2. Implement a strong IAM security programme, people are the first weak point

  3. Establish an IT security baseline and apply it to all your IT assets, no matter what or who

  4. Evaluate IT security risks from a business perspective and implement IT security measures to manage them; do not trust any IT system by default

  5. Detect, manage and solve IT security incidents, they happen even if you do not detect them

  6. Learn from the security incidents and feed the knowledge into the previous steps

  7. Review and re-implement all steps at least yearly (Governance).

On the Privacy of Webcams and Security of IoTs

The article ‘“Internet of Things” security is hilariously broken and getting worse’ of ARS Technica shows how, using Shodan , one can find pictures from millions of open Webcams on internet.

The issue is not new but the scale of the problem is threatening. As the article nicely points out:

  • people do not care about the security or privacy features of the devices they buy
  • the important points are cost and easiness to manage (which means it is better if there are no password to access it)
  • only to throw away the device the day they find themselves on Shodan or in a picture on a newspaper and say “never again”.

But who is going to do something about it? Who should defend the privacy of people and the security of Internet? Should the IoT market be regulated or self-regulated or something in between?

Marketing and Internet Surveillance

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

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.

Cryptography is too risky: should we use something else to secure IT systems?

Obviously the title of this post is provocative, but reading some recent news it is evident that us, IT professionals and IT industry, are not good in managing cryptography. The consequence is that we deploy cryptography in IT products and give a false sense of security to the users. This actually can have worse consequences than if we would not use cryptography at all. I will give just a couple of examples.

This research paper shows how a well-known brand of hard disks has implemented disk encryption in totally faulty ways, to the point that for some disk models hardly any security is provided by the built-in disk encryption functionalities. This is just another of many similar cases, where cryptographic protocols and algorithms are incorrectly implemented so to cancel all or most of the security that they should provide.

Another research paper shows how a well-funded agency or corporation can in practice break the encryption of any data encrypted with the Diffie-Hellmann (DH) key exchange algorithm using keys up to 1024 bits included. Should we be shocked by this news? Not really since already 10 years ago it was known that a key of 1024 bits is too short for DH. Indeed, as per RFC 7525, a 1024 bit DH key offers a security less than a conventional bit security of 80 bits, but again RFC 7525 states that the absolute (legacy) minimum required conventional bit security must be 112 bits, and the current minimum required conventional bit security is 128 bits, that would practically correspond to a 2048 bits DH key. Even if we, IT professionals and IT industry, have known for at least 10 years that 1024 bits DH keys are too short to offer security to the data that they should protect, as of today a too large number of HTTPS websites, VPNs and SSH servers use DH keys of 1024 bits or less (see again the research paper mentioned above).

Unfortunately these are not two isolated examples, recent news are full of similar facts. So I start to wonder if we are good enough to manage cryptography or if we should look into something else to protect IT systems.