The surveillance mass hysteria, the right to privacy and professionalism

I had the intention to make a commentary about the Snowden case and the mass anti-surveillance hysteria it provoked. I will defend the use of the term 'hysteria' in latter paragraphs. But then I realized that the consequences of Edward Snowden's case were far greater than I previously thought. This is not in terms of the diplomatic and geopolitical consequences of his whistle blowing acts. Government surveillance has sustained the Assange/Wikileaks blow and it will continue to do so (thankfully, because I do not agree with the acts of Snowden and Assange, but keep reading, I assure you I do not do Government propaganda here). In contrast, the thing I feared the most, was that this Snowden induced hysteria would eventually turn against hard working US businesses in the area of privacy protection. 

Unfortunately, I was proven right. A few hours prior starting the composition of these lines, I read sad news that announced the closure of Lavabit, one of the most reliable encrypted email providers. It turns out that Snowden had used Lavabit's service and this created some sort of friction, pressure and eventually service collapse of the provider. In an attempt to gauge public opinion, I opened my Twitter account. One of the comments from an individual was "I will never entrust any of my data to a US business!". Of course, surveillance is not only a US phenomenon. In Europe, Asia, Australia, the Middle East, the games of cat and mouse between those who want to safeguard their privacy and those who want to break it is on. So, it is safe to assume that a business is the worst possible place to entrust your digital assets? I am raising this question, because Lavabit is not the only company that is in this sort of business.

Now that I raised the question, I want to step back a bit. I want you to picture Edward Snowden, an IT person that ended up somehow working for the tech/contractor sector that surrounds the NSA. Did you really think that when he joined the ranks, he had no idea of what was going on in there? Do you really need a "hero" like Snowden to tell you that Governments have surveillance capability? Really?

I have started working on the Internet in 1998, and I worked on core TCP/IP protocols and Ethernet device drivers, which is what drives today most of the corporate networks. Today, I am tasked with securing some digital assets for various scientific communities, and I want to believe that I have a healthy dosage of paranoia in relation to whether my infrastructure is secure or not.

The assumption that the guy who sits on NSA/GCHQ has the will to listen to your personal communications one morning and can under all conditions is wrong and unhealthy. If you are an intelligence analyst, you are looking for needles in a haystack and you have specific problems to solve. Yes, there is data mining. Yes, there are ways to tap into your personal communications. Yes, you could be a bystander and accidentally tapped into in an attempt to locate someone, but this is less probable than you being the victim of a phishing/zero day exploit of some bandit that wants your machine for a botnet, or is after your bank account, etc.

Yes, we all have the right to privacy and trusting a communication system to deliver a message from person A to person B is important.  Read Simon Singh's  "The Code Book" and  you will see that most European Governments were operating surveillance rooms from the very early history and form of human communication. He writes about the so called "black rooms", mentioning some of the earlier examples of such a service: the Geheime Kabinetskanzlei, the secret Austrian Service, operated such a room in Vienna on the 18th century. The personnel would open certain letters of interest with care, leaving very few traces on the open envelope, they would make an exact and even translated/decoded copy of the letter, they would reseal the envelope and let the letter reach its final destination. This is one of the earliest form of industrial grade Government surveillance and a very good analogue of what is happening in our age.

Am I trying to increase your paranoia? To the contrary. Do you really think that a black room had the capacity to open/decode/translate all letters? The obvious answer is no. Cryptographers and skilled envelope openers/resealers were finite and there was a very careful targeting/sampling of senders and recipients. Is the whole process easier on the 21st Century? Well, yes and no. It is an interesting question.

The era of computers, the falling CPU/GPU/MIC hardware costs, the increased connectivity of social media and the mobile wireless technologies, the plethora of web scraping techniques and Deep Packet Inspection (DPI) software solutions have made it easier to perform surveillance on a grander scale than the era of the good old post office. However, we are far from the era of pressing a few buttons, having an email address and knowing everything about the life of every individual, as Snowden claims.

One of the greatest problems for the era of modern surveillance is "noise". In the context of surveillance data mining, "noise" is a collective term for a range of factors that prevent a mining algorithm for achieving its target (to get its info or estimate whether something is true or false: for example, whether a particular individual is related to a group of people or not. These factors include:

• a)Fuzzy or an incredibly large amount of info to mine, well beyond the capabilities of the data mining algorithm

• b)Inability of the mining/surveillance techniques to keep up with the amounts of information transmitted over a digital network.

• c)Susceptibility of the mining algorithm to false negatives/positives due to design inadequacies.

With respect to factor a) above, the Internet might be a great repository of information for data mining, however it is also "polluted" with redundant, false and distributed/incomplete information. The term information overload or information pollution should not only refer to the cognitive abilities of an individual to absorb, comprehend and act on the amount of information mined from the web. It also has a negative effect on surveillance data mining algorithms.

Lots of information means an ever increasing rate of information transfer (b). Modern data networking speeds increase all the time, especially large data backbones where we have speeds of even 100 Gigabits/sec at the time of writing. If one combines this fact with the use of encryption, as Bruce Schneier points out in this paper/article, it becomes evident that DPI techniques are falling behind. You will be surprised how difficult it is to silently decrypt traffic of an SSH tunnel with moderately adequate encryption. You can setup something like this between two cloud hosts, even amongst different cloud providers and protect your voice, ephemeral chat communication and everything else that is important to you.  No man in the middle will have an easy way into what your network packets really contain. This techniques have actually been employed successfully by knowledgeable individuals to bypass Government censorship and surveillance firewalls. Egypt, Iran and China are some notable examples.

For factor c), I am sure you must have had an example of false negative or positive in your anti-virus software. If not, you are an extremely lucky person. Are you a sysadmin of an IDS/IPS/firewall system? You should also be very lucky if you never dealt with a signature/rule that let bad traffic in or kept good/legitimate traffic out. It works the same way with surveillance mining algorithms. They are not perfect and they suffer from the same problems: wrong things are flagged up as dangerous and many dangerous things are not flagged at all. Associate Professor Gehan Gunasekara suggested that the public should try and test this susceptibility of the surveillance mining algorithms by polluting their Bayasian analysis modules and cause them to flood them with false negatives. I do not suggest that you do that, but I mention this as a sign of proof that the susceptibility is there and with or without disobedience, the problems exists.

Hopefully, you are convinced now that the claim of the "hero" Snowden is not exactly accurate and that if you take reasonable precautions and trust high stakes information to professionals, you can have a company protecting your digital assets. Not everything is point and click for a Government surveillance analyst and unless you do something really sinister, you can go and do your daily business without feeling threatened or be hysterical.

I would like to close with a statement which is even more serious than the previous ones. The closure of Lavabit is wrong. Innovative businesses that protect the privacy of individuals that have a non threatening interest to protect their private/business information is a core value of the information society. The US administration needs to understand that if they kill the trust of the public to privacy protecting businesses, they are going to strike a big blow at the heart of their digital economy. Whatever the issue was with Lavabit, it can be solved by

i)strengthening the admission requirements to such services and
ii)dealing more effectively within their own infrastructures with the problem of rogue insiders. Technologies to aid that process do exist!

After all, a stark contrast between Ladar Lavison and Edward Snowden is that the first complied with the law and offered a service to the people. Edward Snowden also offered a service to the people, but that is not his whistle blowing act. That was his personal choice. That's exactly why the first one is a professional and the second is a rogue insider. That is also why I would entrust my email data to Lavabit.

China: A nation of cyber attackers or the 'Wild West' of vulnerable systems?

An ascending nation creates waves in World Politics. At least, that is the case with China and the way it provokes the US Government when it comes to Cyber attack issues. There is one side (that of the US government) which states that China is the powerhouse of a new Cold War in the cyber front. On the other hand, a credible investigation finds that the Chinese government seems totally unprepared to fend off coordinated attacks on Chinese networks.

Well, they are both right. The mixup is in the detail of WHO attacks what. The fact that China (and many other countries) have a large number of vulnerable systems makes it an ideal ground to base the front end of large cyber attacks for two reasons:

• It requires little effort to locate thousands of vulnerable systems.
• It breaks the chain of evidence that leads to the real source of the attacks.

Both of these points are really important in the wishlist of a botnet/malware writer/coordinator: If I wanted to DDoS a site, would I target systems in a country where few vulnerable systems can be found, or in countries where most of the systems come from pirated copies (or at best unpatched copies of genuine software)?

The important point in my view is to really investigate how the chain of evidence can be preserved in these kinds of attacks. What Dillon Deresford found is really not surprising and it explains why China is often the ground for cyber attacks. The important thing is that someone should explain to US Federal funded bodies that instead of accusing a country at large, they should also investigate whether US based attackers use Chinese networks to attack US networks. Proving or disproving this possibility will be a winner and the greatest challenge of all. With many important changes in the global network infrastructure (IPv6 is already here), it will be interesting to see if an order or further chaos will emerge with every little device having a globally routable IP.

Catching an undesired guest in the penguin /tmp room

You might have come across LUARM, a prototype I have built to make an insider misuse detection platform. To cut the long story short, I have looked at various audit log engines and for good reasons, I decided to write my own one, as I found that most of them are really inadequate to provide useful logging in order to:

• Perform a good post mortem analysis of a security incident,
• Link events to user entities (accountability),
• Be able to use the logged data to perform event correlation easily.

There are of course many other goals of the prototype that I am hoping to present at the USENIX Security 11 event, if the paper is ready on time. What I wish to show here is how a good structure of an audit log makes life easier, with or without insiders in mind.

Using LUARM, I managed to catch a compromised penguin carrying a Perl IRC bot like this one. It  did get into the system, because a XAMPP server was running with lots of outdated components, especially when it comes to PHP, introducing many exploitable vulnerabilities . OK, the point is that we compile from source, we always update frequently, we take care of he permissions of /tmp dirs, etc,etc, that every professional sysadmin should know...But, sooner or later, you are going to miss something here and there, only to discover it from logs (or a network traffic log). Here is what happens with LUARM.

Before I start describing the incident, I should say a few words about LUARM, so you get a basic idea of how it works...Not that it is complicated, and of course the sources are at Sourceforge, but just for starters.

The above figure displays the module client-server architecture of the LUARM audit engine. On the left, we can see a set of audited computer clients. Every client is running a unique instance of a set of monitoring scripts. Each of the client scripts audits a particular system level aspect of the operating system: 'netactivity.pl' audits the addition and creation of endpoints, 'fileactivity.pl' records various file operations, 'psactivity.pl' provides process execution audit records and 'hwactivity.pl' keeps a log of hardware devices that are connected or disconnected from the system. The right hand side contains the centralized server part of the architecture where audit data are stored, maintained and queried in a MySQL based RDBMS (other RDBMS systems could be used as well). The Perl programming language is used to implement the modules and the communication between client and server is performed via a Perl DBI interface. 

On the server side we store the audit data, in order to safeguard audit integrity and audit volume scalability. Each client authenticates to the LUARM server using separate, unique credentials that do not interfere with the authentication domain of the client.

Starting with the database of the infected host in question, we sit at the basic MySQL console on the LUARM server and we try to get our bearings on the netinfo table, as my NIDS gave an alert about some unusual traffic patterns towards a number of hosts, the most persistent of them were the hosts 'undernet.irc.justedge.net' and 'dana.basefreak.nl', so we ask LUARM to verify activity towards these hosts :

mysql> show tables;

+---------------------+

| Tables_in_panoitpsl |

+---------------------+

| fileinfo            |

| groupinfo           |

| hostinfo            |

| hwinfo              |

| netinfo             |

| netint              |

| netroute            |

| psinfo              |

+---------------------+

8 rows in set (0.00 sec)

mysql> describe netinfo;

+--------------+-------------+------+-----+---------+----------------+

| Field        | Type        | Null | Key | Default | Extra          |

+--------------+-------------+------+-----+---------+----------------+

| endpointinfo | bigint(20)  | NO   | PRI | NULL    | auto_increment |

| cyear        | smallint(6) | NO   |     | NULL    |                |

| cmonth       | tinyint(4)  | NO   |     | NULL    |                |

| cday         | tinyint(4)  | NO   |     | NULL    |                |

| chour        | tinyint(4)  | NO   |     | NULL    |                |

| cmin         | tinyint(4)  | NO   |     | NULL    |                |

| csec         | tinyint(4)  | NO   |     | NULL    |                |

| transport    | tinytext    | NO   |     | NULL    |                |

| sourceip     | tinytext    | NO   |     | NULL    |                |

| sourcefqdn   | tinytext    | YES  |     | NULL    |                |

| sourceport   | smallint(6) | NO   |     | NULL    |                |

| destip       | tinytext    | NO   |     | NULL    |                |

| destfqdn     | tinytext    | YES  |     | NULL    |                |

| destport     | smallint(6) | NO   |     | NULL    |                |

| ipversion    | tinyint(4)  | NO   |     | NULL    |                |

| username     | tinytext    | NO   |     | NULL    |                |

| pid          | smallint(6) | NO   |     | NULL    |                |

| application  | tinytext    | NO   |     | NULL    |                |

| dyear        | smallint(6) | YES  |     | NULL    |                |

| dmonth       | tinyint(4)  | YES  |     | NULL    |                |

| dday         | tinyint(4)  | YES  |     | NULL    |                |

| dhour        | tinyint(4)  | YES  |     | NULL    |                |

| dmin         | tinyint(4)  | YES  |     | NULL    |                |

| dsec         | tinyint(4)  | YES  |     | NULL    |                |

| md5sum       | text        | NO   |     | NULL    |                |

+--------------+-------------+------+-----+---------+----------------+

25 rows in set (0.00 sec)

mysql> select COUNT(*) from netinfo where destfqdn='undernet.irc.justedge.net' ; 

+----------+

| COUNT(*) |

+----------+

|      963 |

+----------+

1 row in set (0.13 sec)

mysql> select COUNT(*) from netinfo where destfqdn='dana.basefreak.nl ' ;

+----------+

| COUNT(*) |

+----------+

|     1408 |

+----------+

1 row in set (0.12 sec)

Indeed, LUARM verifies a lot of hits towards these hosts, so given the fishy names, we need to dig out more from the LUARM endpoint information. In particular, we need to see which username and application created these endpoints, so we issue the following SQL queries, limiting the number of results to 5 (to prevent flooding our console with endpoint info):

mysql> select application,username,pid from netinfo where destfqdn='dana.basefreak.nl' LIMIT 5;

+-------------+----------+------+

| application | username | pid  |

+-------------+----------+------+

| crond       | nobody   | 7371 |

| crond       | nobody   | 7371 |

| crond       | nobody   | 7371 |

| crond       | nobody   | 7371 |

| crond       | nobody   | 7371 |

+-------------+----------+------+

5 rows in set (0.11 sec)

mysql> select application,username,pid from netinfo where destfqdn='undernet.irc.justedge.net' LIMIT 10;

+-------------+----------+------+

| application | username | pid  |

+-------------+----------+------+

| crond       | nobody   | 21995 |

| crond       | nobody   | 21995 |

| crond       | nobody   | 21995 |

| crond       | nobody   | 21995 |

| crond       | nobody   | 21995 |

+-------------+----------+-------+

5 rows in set (0.12 sec)

So, we have now a username of 'nobody' a crond application which appear to relate to these endpoints via two distinct PIDs, 7371 and 21995. We have to find out what did these two processes do, as this is something but not very helpful. Thus, we need to jump to the psinfo table:

mysql> describe psinfo;

+-----------+--------------+------+-----+---------+----------------+

| Field     | Type         | Null | Key | Default | Extra          |

+-----------+--------------+------+-----+---------+----------------+

| psentity  | bigint(20)   | NO   | PRI | NULL    | auto_increment |

| md5sum    | text         | NO   |     | NULL    |                |

| username  | tinytext     | NO   |     | NULL    |                |

| pid       | smallint(6)  | NO   |     | NULL    |                |

| ppid      | smallint(6)  | NO   |     | NULL    |                |

| pcpu      | decimal(3,1) | NO   |     | NULL    |                |

| pmem      | decimal(3,1) | NO   |     | NULL    |                |

| command   | text         | NO   |     | NULL    |                |

| arguments | mediumtext   | NO   |     | NULL    |                |

| cyear     | smallint(6)  | NO   |     | NULL    |                |

| cmonth    | tinyint(4)   | NO   |     | NULL    |                |

| cday      | tinyint(4)   | NO   |     | NULL    |                |

| cmin      | tinyint(4)   | NO   |     | NULL    |                |

| chour     | tinyint(4)   | NO   |     | NULL    |                |

| csec      | tinyint(4)   | NO   |     | NULL    |                |

| dyear     | smallint(6)  | YES  |     | NULL    |                |

| dmonth    | tinyint(4)   | YES  |     | NULL    |                |

| dday      | tinyint(4)   | YES  |     | NULL    |                |

| dhour     | tinyint(4)   | YES  |     | NULL    |                |

| dmin      | tinytext     | YES  |     | NULL    |                |

| dsec      | tinyint(4)   | YES  |     | NULL    |                |

+-----------+--------------+------+-----+---------+----------------+

21 rows in set (0.00 sec)

mysql> select COUNT(*) from psinfo where username='nobody' ;

+----------+

| COUNT(*) |

+----------+

|       57 |

+----------+

1 row in set (0.05 sec)

Well, we have had 57 intercepted executions of processes with that network credentials, which means that some of these will give us more info. So, we can expand the info on these 57 processes by issuing a:

mysql> select command,username,arguments,pid,ppid from psinfo where username='nobody' \G;

.... and amongst the many results from httpd apache we, we see the following:

*************************** 56. row ***************************

  command: /usr/bin/perl

 username: nobody

arguments: ./x 79.125.109.171 0 0

      pid: 9253

     ppid: 8343

*************************** 57. row ***************************

  command: /usr/bin/perl

 username: nobody

arguments: ./x 85.121.125.74 0 0

      pid: 29312

     ppid: 8343

57 rows in set (0.05 sec)

Clearly, we have traced down the offending application now, when it tried to communicate with the command servers (85.121.125.74 and 79.125.109.171). A quick navigation to the /tmp dir shows the culprit and the way to clean the perl bot infested penguin. Note how the psinfo table gives a pid and a Parent PID (ppid). Using that information in conjunction with the username and endpoint info, we can make very powerful an fast correlations on host events. As an example, let's take the pid 23913 and check to see the source, destination and exact time information of the endpoints created by that process:

mysql> select sourceport,destport,cday,chour,cmin  from netinfo where username='nobody' AND pid='29312' \G;

...........

*************************** 523. row ***************************

sourceport: 32767

  destport: 6670

      cday: 5

     chour: 7

      cmin: 12

*************************** 524. row ***************************

sourceport: 32767

  destport: 6670

      cday: 5

     chour: 7

      cmin: 13

*************************** 525. row ***************************

sourceport: 0

  destport: 0

      cday: 5

     chour: 19

      cmin: 0

525 rows in set (0.13 sec)

.......

I am sure some of you will say that a competent sysadmin could find that by simply looking at looking at a couple of files such as the Apache Logs for example. Sure, a competent sysadmin is likely to have faced a perl IRC bot before. However, what if you had to deal with something that you were not familiar with on a very busy box that was compromised and the logs were erased or logrotated. Are many tools able to offer you that level of detail and correlation? Think again and whether you look at legitimate users or general system auditing issues, give LUARM a go! 

The Julian Assange theater from an IT security perspective

I think the world of media has been taken hostage by an attention seeker...or maybe the media empires have decided to use an attention seeker to spice up their news. The second scenario seems more probable, even if it seems to be a cynical view.

I am NOT against Wikileaks. I find it useful as a third resource of evidence-based news records, which can help to cross-reference bits of information, when in doubt about various news bits coming from other sources. Despite the fact that sometimes I (and many others) question the source ethics and the authenticity of its published records. This seems to be a general problem with the Internet. It contains a lot of information, but not all of it is credible or useful. The recent diplomatic cable leaks may serve as evidence of various foreign policy misconducts, but if I raise the question "Does a reasonably educated and well informed person need Wikileaks to know the deal behind the US foreign policy, to infer the ties between China and North Korea?", the answer I will expect is a definitely negative. Thus, I question the noise made behind the Wikileaks "revelations".    

In fact, I have financially supported Wikileaks (before their accounts where shut down). What I am really against is the behaviour of its founder, for various reasons.

Julian Assange has a background of ethical hacking. There is no universal definition of the term "ethical hacker". I tend to think of it as a reference to a person with advanced technology skills, that puts them into good use to reveal the truth or inform people about potentially harmful situations, seeking no financial gain or other rewards from any affected parties. In the information security world, we have the classical argument of software vulnerability disclosures. Some people argue that all vulnerabilities should be made public, whereas others disagree and are of the view that vulnerabilities should be disclosed only to a limited number of parties, on a strict need-to-know-to-fix basis. Personally, I support the second view, and I never disclosed software vulnerabilities in public.


If I draw a parallel line to the software vulnerability disclosure issue, it would run along the Wikileaks disclosure of vital US sites around the world. I strongly dislike this action, even if I am not a US citizen (or US Government employee). The reason is simple and it has nothing to do with the breaching of any National Security policy. After all, if someone is really determined to do something nasty, surely they will find the resources to do harm without the Wikileaks disclosures. However, any reasonable person understands that revealing strategic infrastructure locations (some of which are not only US based, but they serve collectively many nations) is an act that adds very little to the truth. It is simply a reckless action, bound to also draw the attention of less serious folk with malicious intent.

An equally noteworthy issue with the Wikileaks case is that of the Denial of Service (DoS) attacks they had on their domain. I am not sure whether the slowness experienced on their domain was due to persistent DoS attacks or simply by the strong demand (probably by both) in anticipation of the forthcoming document leaks, but this is a strong lesson in distributing important information in a scalable and secure way. This seems to be the job of Peer to Peer (P2P) protocols and not a number of static HTTP/FTP servers mirrored around the world, which is the usual approach. Torrents distributing the content were of course active from day 1.


My final comment concerns the good old face value of the information origin. I will use an example that comes from the Linux/Unix sysadmin world. Every security conscious sysadmin (and user) that uses third party binary package repositories makes sure to validate them via either a secure hash algorithm based key (MD5, SHA) or public repository key prior installing them into computer systems. These mechanisms make it more difficult for someone to maliciously alter the contents of the binary package and make you install something nasty in your computer. However, they are not a panacea. We have had cases where world famous open source packages have been compromised. Nevertheless, this is a rare event, and each time we download a Linux kernel, an Apache binary or our latest IDE from our Linux distribution, we trust that the keys have not been compromised. This trust is there because we know that our favourite Linux distribution has capable folk to look after security issues, so we do use the good old face value rule.


Wikileaks has appeared so far to be a human-centric entity around the face of Julian Assange. Hence, it would be fair to say that Julian represents to the world the face value of Wikileaks, even if there are probably dozens of people behind the scenes that work to make Wikileaks tick.


It is also understandable that people that reveal the truth are also the subject of massive attacks at every level. Mr Assange had been hiding for quite a long time. I find that a bit odd. If Bob Woodward and Carl Bernstein managed to stay alive by revealing one of the largest scandals of the US political history during the horrible Nixon era, I am sure Assange could find ways not to hide. In the same way, I am sure that the lack of transparency and instant communication during the Nixon times could make it easier for someone to attack journalists then. And they did, but somehow, the journalists and the papers stood up to the challenge. No hiding was necessary.

In the same way, if Assange is not willing to understand that he has to face the Swedish prosecutors and clear his name, he will never gain the face value he needs to be trusted. Sweden is not known to be a corrupted state, so if the "rape" and "sexual misconduct" allegations are constructed to halt him down and he cares about the truth, he should raise to the challenge and pass the public face of Wikileaks to someone else. Sooner or later, he will face the facts.

Were google attacks an insider threat problem?

Recently, I came across Bruce Schneier's view on the Google "Chinese" hacking attacks. In essence, he analyzes the situation mentioning various facts (the existence of backdoors to various systems due to wire tap requirements) and concludes about the dangers of building the ultimate surveillance system and establishing a police state.

I think that the title of the article is a bit misleading though. In my honest opinion, the title should instead read : "US fails to handle the inside threat problem in critical surveillance infrastructures". I will explain my point of view.

Schneier's view is fundamentally correct. Indeed, we need to be careful about the procedures and the persons who handle surveillance systems (I am not going to discuss here whether we need these systems, this is a big issue. For the purposes of highlighting the insider issue I axiomatically accept that we do need them).  This essentially points to the insider problem, a big issue that is left to the side in the process of securing surveillance infrastructures.

I do not want to reveal details I do not know about, but from my experience as a system administrator and security researcher, I understand that it takes a lot more than knowing the existence of a backdoor to a system to exploit it. Google might have indeed left backdoors to Gmail, this creates a vulnerability. To exploit this vulnerability a catalyst is needed and that is the person who knows the failsafes (procedures/passwords) and hands them over (intentional misuse) or a person that is naive enough to design procedures that are too open (accidental misuse). Without these factors, it is difficult for me to accept that Google's systems could have been compromised.

Interestingly enough, Schneier mentions the high profile wiretap case of the Greek government in June 2004. In my view, the problem was not that Ericsson enabled the surveillance functionality into the ground stations for the Greek government, nor the fact that Vodafone Greece had issues with their procedures for enabling the issues. The very fundamental issue is that someone took a decision to consult/allow important members of the Government to discuss government issues using a normal private carrier and ordinary phones, with no further security failsafes (further encryption, VPN and other mechanisms). That is essentially a policy mistake made by an insider ( an advisor that the Government trusted to secure the communication channel or the lack of him).

I often argue that for every external breach of security, there is almost always an internal reason (naive users, laizy IT admins, absence of policies from CIOs). The same is true for surveillance systems. The funny thing is that these problems have been highlighted by many US government funded workshops of insider threats and other gatherings around the world. And my question is: "When will people listen to insider threat researchers?"

"Aurora" attacks: anti-virus/spyware versus intergrated application protection

(Disclaimer: I advise Promon AS  on some issues, so my opinion about Integrated Application Protection could be biased. In that case, feel free to point out tools from other sources that achieve the same functionality. I am also not on their payroll, so this not a sales pitch).

The recent targetting of Google, Adobe and IE flaws raised a lot of eyebrows and gives plenty of thought to the security analyst. This has nothing to do with  the specific Microsoft/Adobe vulnerabilities involved in the case. Software will always have vulnerabilities. It has also nothing to do with infrastructure vulnerabilities (spoofed SMTP headers, DNS targetting, more to come in a latter arcticle ). They will always be there. The question is why setups with highly capable people fail to address attacks that might be zero day (or near zero day) but they are still preventable.

In order to give an answer to this question, I can't help but notice the shortcomings of common desktop anti-virus/spyware packages. Today, most people have a desktop/server anti/virus/spyware package installed on their computer to defend themselves against various types of malware. The vendors that produce these tools do a tremendous amount of work to ensure that they protect you against many types of threats. In essence, they have industrialised the process of producing signatures (non ambigous ways of describing the malware) and then they throw a bit of heuristics to compensate for the things the signature will not catch (you cannot know everything in advance). This combination is good to catch most types of attacks, but not all (many of these products did not detect the recent aurora attacks for various reasons).

If we rely daily on computers for critical tasks, is a "good for most things" type of protection acceptable? Personally for me, it is certainly not. Sure, I use known desktop and servers anti/virus products and I always recommend them, but I always say their development strategy has many pitfalls. I am going to outline them in the next paragraphs and then prescribe a solution to these problems.

Anti-malware scanners tend to use heuristics to address (amongst other issues) the polymorphic payload of malware. Is is interesting to note that the recent "Aurora" style attacks used either malware with different payloads or different payload wrappings. This can downgrade the ability of the most carefully crafted heuristic signatures of anti-malware vendors. In fact, heuristic signatures are also responsible for "false positives", a known issue not only in the anti-malware world but also in the field of Intrusion Detection/Prevention (IDS/IPS).

Take the fact of the previous paragraph and combine it with the variety of attack techniques, operating system modules and the even greater number of applications and combine it with the need for an infrastructure to safely distribute (on almost a daily basis) the updates for the heuristics threshold and signatures and you get...the chaos. In my view, this is the very reason behind the fall back of many anti-malware vendors in the race of malware writers and
anti-malware analysts. They just can't and will not (I dare to say) keep up with these techniques. Their approach is useful but it needs a more focused complement.

As a side note, it is useful to note that beyond the anti-malware scanners, the "Aurora" style attacks can also bypass OS protection techniques such as the Data Execution Protection (DEP), at least Dan Kaminski thinks so. Other OS protection features such as Address Space Layout Randomization (ASLR) are considered immune to this type of attack when combined with DEP.

The next reasonable question is what can be a desirable complement. The answer is obvious. What is the most valuable component in the software stack that interacts and allows access to data? Yes, the application. And after the mail browser, the most critical (and for long time universal) application that gets data from the Internet and sends data to the Internet is the web browser. Application integrated protection is the key complement most people need to render stack overflow and other types of similar attacks useless.

It would also be good to minimize the reliance on a continuous update distribution channel. Infrequent updates would satisfy bad Internet connectivity scenarios, as well as lazy user and system administrators.

There are many companies out there that offer integrated application protection. And a notable one is the Norway based Promon.

Promon's Integrated Application Protection (IAP) achieves this functionality. The concept behind Promon's technology is unique and has a sound theoretical basis: If the data and the information flow are the most valuable things, the most important thing is to stop information leaking out and in to the application, making a virtual shield around it. The details of this shield are of course a trade secret and proprietary, so I hate I cannot analyze the details here. However, the important thing is that their tool caters for minimum installation hassle, minimum user intervention and a small number of updates.

I was curious to find out whether their tool could stop the "Aurora" attack payloads. It turns out that it does. showing the technology in action. Here is a video that demos their technology against "Aurora" payloads (thanks Sondov!):

demo video

md5sum: 45fc6ae7844baf243c005d0c9122d19f  aurora.mp4


On the left hand side you can see a Vmware instance simulating the victim's system and on the right hand side is the bad guy that likes to hand out malware payloads. Watch what happens on the first instance. The victim's system connects to 'evil.com' (effectively exploiting of the IE vulnerability) and then various things happen to the poor desktop. The second part repeats the experiment under the shield of Promon's guard. The application immediately detects the exploit by sensing essentially suspicious information flow in and out of IE and then it drops the bad application.

I will try to outline the technology behind promon's concept in a latter article. My point is to show that effective technology to protect (and complement other tools) vital applications in cyberinfrastructures does exist and is quite effective against professionally designed and executed attacks such as those of the recent "Aurora" wave.

The insecurity of being transparent in Norway and your right to privacy

This is a random mumbling about the state of transparency in Norway. Don't get me wrong, Norway is a beautiful country to live in. Taxation is heavy and used properly in comparison to other European countries. However, there is one thing that I personally fail to understand. Why on earth everyone's taxation records are on-line, available for everyone to browse.

You see, in Norway, all well known news or business portals have enabled a form into the Skattelister (tax records) data set . So, if you are curious enough to know how much a friend of yours made throughout a tax year, you type his/her first and last names and then you get all sorts of nice information such as:

• The exact amount of income of the person.
• The exact amount of tax they paid.
• The exact valued/declared amount of other property entries they have
• Nice comparative graphs to see how the person's income compares to the national/regional/average.
• Nice economic indicators of your income expressed in percentage of tax contributed to useful things (i.e. you paid %percentage of a stipendship salary, of a hospital operation).

On one side, this level of transparency promotes some sort of social justice order. You have valid data to observe the distribution of income. You can also spot the injustice by watching the logistical tricks of the super reach (they have zero income or zero property, as they skilfully transfer their income to funds or other financial arrangements abroad).

On the other hand, the data availability creates certain information and generic security risks. I explain what I mean:

• Each tax record reveals your age (4 digits). Every Norwegian has a social security number (fød.nummer)  of 11 digits in the form ddmmyynnnnn. Two of these digits are revealed. So, no big problem for brute force attacks, but still, there are other laws that prohibit the display of the year of birth without the permission of the individual.
• The same goes for your postcode (and hence the full details of your house address).

Apart from the fact that many passwords are made by using the birth year and the address as combination, if I was a burglar and wanted to see which houses I could "visit", I have hit a goldmine!

Apart from privacy concerns and identity theft scenarios, who is the idiot that decided that my entire data should be online to everyone, without my permission? The Norwegian Data Protection authority is sleeping quite heavily at the moment. Somebody should wake them up!