Aetheric Research, Ltd.

The Register has an excellent (if somewhat snarky, though that is the milieu of the publication) article on some of the recent breaks to SSL’s effectiveness as a platform for secure communications.

The basic problem behind this round of vulnerabilities is the reliability of the certifying organizations.  After the recent breakin to Comodo that resulted in the issuance of several fraudulent certificates, more attention has been paid to this particular flaw in the way in which traffic is secured.

SSL works by means of PKI: public key infrastructure.  This means that a large string of data, known as a ‘key’, is sent out into the public for use by anyone wishing to communicate with the server.  The key has a certain mathematical relationship with another key stored on the server (known as the private key); when data is encrypted with one, it can be decrypted with the other if the proper mathematical steps are taken.

These keys are used to negotiate a secured connection to a server, which serves two purposes–first, it assures the person connecting to the server that they are connecting to the genuine article; the fact that the connection can be made successfully proves that the server has the requisite private information associated with the key.  Secondly, it allows the entire connection to be encrypted so that people between the computer and the server will be unable to determine the content of the transaction.

This only works, however, if the key is trusted–if anyone has access to the private key other than the server in question, then there is no assurance that the connection is being made to the correct server, and no assurance that someone in the middle is unable to eavesdrop.

Cerifying Authorities such as Comodo, VeriSign, and others are supposed to guarantee that they issue certificates only to the organizations that they identify.  However, this is not always the case; especially in the case of their licensees–companies that issue certificates under license from the CA houses, and whose certificates are intended to be just as trusted–the requisite identification of the certificate request is not always accomplished properly, resulting in certificates being issued to incorrect persons.

One particular certificate that has been mentioned is one for ‘localhost’–that is, one’s own computer.  While most articles on this subject have noted that this is an essentially frivolous certificate and have paid much more attention to the ‘exchange’ domain certificates that could be used for intercepting corporate email, it’s worth noting that a live ‘localhost’ certificate along with a maliciously-installed local proxy could intercept all internet traffic that a user attempts, thus providing no overt sign (unless the user was very security-conscious and checked carefully the certificates of all the sites that they connected to) to the user that they were being compromised and, for instance, their bank account details were being stolen.

Certain alternatives to the SSL system have been proposed, but as yet they all suffer from the difficulties of limited adoption.  Until a significant movement arises–or at least some of the ‘big players’ get involved–eCommerce and the like will likely continue to be only partly secured.

(On a side note, a service that actively tracks and validates certificates issued by all authorities–like the automated one run by Google on page 3 of the article linked–could be made very profitable)

RSA, a well-known manufacturer of two-factor authentication systems based around cryptographic tokens and developer of numerous other security-based products, announced last month that their security had been compromised, specifically that surrounding their flagship SecureID tokens.  Yesterday, they finally revealed some of the details behind how that particular compromise happened.

The description given by the WSJ above is one of an attack carried out with ‘sophistication’–but looking deeper in reveals that this is apparently face-saving propaganda, given that the description matches up with a textbook social engineering-mediated trojan installation.

In short, a spearphishing campaign–a phishing campaign focused at a specific person or group–was carried out to solicit a person with some level of privilege into opening a document in which was embedded malicious code–in this case, an Adobe Flash object.  This malicious code proceeded to install what’s known as a RAT–a remote-access trojan–which connected to a remote server to allow the infiltrator to observe his target’s activities and gain access to secured information.

At that point, the infiltrator was able to package and upload private information concerning the cryptography used in the SecureID token system to a server that he controlled elsewhere.

As per the usual texbook example–and the phrase is chosen deliberately, given that it is, in all respects, materially identical with the majority of examples given in this text on social engineering–the target was induced to deliberately open a suspicious attachment.  Said attachment had been put into the ‘spam’ bucket (though attachments had not been stripped, as best practices would dictate for such arrangements) and it was deliberately retrieved and opened by the target at the infiltrator’s inducing.  

This cannot be stressed enough: the initial infiltration was accomplished through mundane means, by convincing the target to act against standard security policies.

It was only through the user’s deliberate violation of standard secure practices that the infiltrator was able to gain access to the network and carry out his work.  

There were a few other failures in security that this appears to put into play–RSA has several products that they market specifically to prevent these sorts of infiltrations, to detect and counter intrusions; these were apparently not in use inside the company, which rather places doubts on their effectiveness.  Attachments, as mentioned above, were not automatically stripped from external emails; this is fairly standard practise with any reasonably well-administered mailserver, as it cuts down the possible attack surface significantly.  The corporate firewalls did not, apparently, block outgoing FTP traffic to sites not known-good; this allowed for easy exfiltration of private company data.  

Any one of these failures has the potential for a breach; all of them together combined to make that breach much easier and much less detectable than it might have been otherwise.

To RSA’s credit, they at least determined that a breach had happened before they were notified by some outside agency; oftentimes, insufficiently secure networks are infiltrated and no notice is taken of any odd function or other telltales of intrusion until, for instance, the company domain is blacklisted for being a spam origination point.

The countermeasures to prevent this sort of breach are obvious: secure the corporate network according to standard best practices.  Ensure that all users are fully aware of security policy, and ensure that all users follow said policies–even if that means disabling the accounts of executives until they have time to receive training.  Configure the mailserver to strip out unknown attachments–frankly, in an enterprise of that scale, email attachments are entirely unnecessary; a CMS should be used for departmental file storage and sharing.

The SecureID product is probably, given RSA’s extreme reluctance to disclose what information was leaked, irreperably compromised–at least until such time as RSA develops a new algorithm and a new implementation for it.  

RSA can learn some lessons from this breach, but it remains to be seen if they will put those lessons into practice.

McAfee, a noted provider of various antivirus and internet security products, has been revealed to be vulnerable to one of the security holes that they offer a product specifically to prevent.

As reported yesterday by Network World, McAfee’s website has a cross-site scripting (XSS) vulnerabilities that could lead to compromise in the same manner as the SQL.com compromise.

McAfee markets a product, “McAfee Secure”, which they claim will ‘scan a website daily’ to reveal a significant number of vulnerabilities.  Apparently not a fan of dogfooding, McAfee was found to be vulnerable to many of these same security issues.  Amongst them were, as mentioned, XSS holes; also found were references to internal hostnames and disclosures of source code.

The XSS vulnerabilities are quite bad enough on their own–this means that a malicious attacker could serve various kinds of javascript to, for instance, steal login credentials or otherwise gain access to resources that they were not supposed to, without having to compromise the security of the server in any other way.  

Revealing internal network structure is quite another kettle of beans–if an attacker knows the hostname to look for, then they have a specific target to attack; if the hostname was revealed in such a manner as to show its purpose (from the context of the reference, for instance) then the type of attack to use to compromise it would be far easier to select.  

Source code disclosure is not that bad in and of itself, except that McAfee is a closed-source shop, and their code has been vetted by only a limited community of programmers; more eyes will find more vulnerabilities in the code, and unlike an open-source model (where that is the intent, and the same eyes that find the bugs are likely to either fix it themselves or know who to tell to fix it) the persons who would find this code are likely to use it for attack purposes.

It may be possible that some of these vulnerabilities are the result of deliberately-crafted honeytraps–that is, “vulnerabilities” set up specifically to be as appealing to attackers as possible in order to convince them to attempt to exploit them, leading them into a controlled environment for study.  Many security companies are known to operate whole networks of honeytraps in order to study emergant threats and catalogue attack types.  However, given that McAfee has been found to be vulnerable to XSS before, and that these vulnerabilities have remained unrepaired for more than a month, it is apparent that McAfee does not take its public-facing security seriously.

This is a very serious problem.  Millions of systems are deployed in this country and elsewhere with McAfee’s security products enabled–from basic home systems up through large enterprise and government workstations.  If McAfee is this lax in addressing a threat to their own presence on the web, how much can they be trusted to address threats to customers?  If McAfee does not eat their own dogfood–that is, if they do not use their own products–then why should anybody else?

There is no reason for a home user to bother paying McAfee for antivirus protection; there are several free solutions available–both Avast and AVG offer free versions for home use that are, often, more capable of picking up infections than McAfee.   It is in everyone’s best interest to keep the internet ecosystem as free of malware as possible; the actions of companies like McAfee (and Symantec, as well, though they’re not in the news today for complete failures of security policy) in charging home users every year are borderline unethical.

This also throws into stark relief the necessity for security culture as a way of life rather than as an item to be addressed at meetings: without a secure culture, there is no assurance that security will be addressed with any regularity.  

There’s a quote from the early days of the internet that seems to show up fairly often when discussions of censorship, neutrality, and the like appear:”The Net interprets censorship as damage and routes around it.”

The internet was originally conceived by DARPA as a robust network capable of surviving immense disruptions caused by, specifically, nuclear war and other societal disruptions.  The whole point of all the protocols that underlie the internet as we know it today is to get data from point A to point B in as reliable a fashion as possible, and to make sure that the data at point B matches that at point A as closely as possible.  From a technical standpoint, any parts of the network between points A and B that filter out the data as objectionable will be avoided during the routing; even in a naive packet switched network, such a system that ‘damaged’ the transmission of the data would merely slow, rather than stop, transmission.  More intelligent networks with routers set to optimize the routing of their payloads will, in time, actively work to avoid such networks, as the dropping of packets containing censored payloads would be reported by the other endpoint and would, accordingly, count as a failed delivery.

However, the technical solutions aren’t always enough; some countries like, to pick a particularly large example, China, have sought to control their citizens’ access to the internet wholesale–they’ve split off their part of the internet as a sort of walled garden and have employed, to strain the metaphor, enormous guard dogs to examine all ingoing and outgoing traffic for subversive messages.

This is where another part of the network comes into play: the people who design and build communications technology.  While certainly there are any number of very competent hardware and software engineers working for the Chinese government to assist them in keeping their citizenry (and netizenry, as it were) with toes to the party line, there are just as many competent people within who want to know what goes on in the outside world–and even more people outside who have a dedication to ensuring that information be freely available to those within the firewall.  This layer of damage may cover layers one through seven of the networking model, but layer 8–the users–can always eventually find a way to route around a faulty connection.  

Several countries already consider internet access–that is, access to the full spectrum of information that the citizenry needs in order to make an educated and appropriate judgement about their affairs, and to participate in human society–as a fundamental human right.  It’s a required part of freedom of speech and of the press–two rights enshrined in the first amendment that recognize only through the free flow of information can an effective democracy exist.

It’s very telling that, during the recent unrest in Egypt, one of the first steps that the former government took to attempt to quash the protests against it was to shut down this information flow–all the ISPs were forbidden to route traffic out of the country, and Egypt more or less disappeared from the map.  Workarounds were available within hours, with network connections being routed to modems and the like; the damaged connections were bypassed–not in the most efficient manner, but bypassed nonetheless–and the flow of information resumed.  This same government that ordered the connections shut down (and, incidentally, harmed the economy of the country greatly, for no economy can exist today without significant information flow) was overturned.

As one means to combat censorship and the like, Google is spending a significant sum to develop a suite of tools that can help to detect various kinds of censorship, to enable layer 8 in making effective decisions about the lower layers of the network.  While Google’s motives may not be entirely altruistic–they’ll doubtless benefit from knowing what networks are most restrictive and the pressure that will be generated on them to open up–they are useful for the internet’s health at large; an undamaged network is an efficient–and useful–network for commerce, for entertainment, and for freedom.

People, in general, are lazy.  If you want to make an individual follow a course of action, one of the best ways to ensure that they follow the action that you want them to take is to make it the easiest option.  

This is a principle that systems administrators can use to secure their systems as well:  if they configure the system such that insecure behavior is more difficult than secure behavior, then the users will either avoid using the system (if done badly) or default to the secure behavior (if done correctly).

There are several things that a careful administrator can do to ensure that the secure way is the easy way–many of those things involve configuring client systems to, for instance, accept automatic updates to the operating system and to antivirus software from a centrally managed server.  Other useful configurations would include requiring credentials before performing potentially insecure actions–presumably the intent behind the much-reviled Vista and Windows 7 nag screens, though at least for home users who typically run everything under a privileged account such protection becomes more susceptable to the automatic-yes-click.

Password authentication is, perhaps, one of the stickiest points involved in the whole mess.  For typical username/password setups, the ‘easy way’ is generally to use a known and memorable password over all the systems that they have access to–a vastly insecure practise, given that these kinds of passwords are generally easily compromised and, if repeated, are often repeated with the same or similar usernames.

Training and warnings will do little to mitigate this, as well, because as simple as most schemes for generating and remembering individual secure passwords are, they still require marginally more thought than reusing a simple one everywhere.

Offering other means of authentication may help.  OpenID, for instance, offers an API for websites to allow for authentication on a single system to be carried across multiple systems; the OpenID servers maintain the authentication standards and provide those servers that support their system with tokens to prove identity for logins.  For businesses, a token and PIN combination may help–that is, a card or dongle on which a cryptographic token is maintained (together with the requisite public-key infrastructure, or PKI, to validate it being available on the network) which can be unlocked by a short password or PIN.  Combined with single sign-on procedures, this means that the user has only to remember to bring their login token and remember a short password in order to use any of the systems that the networks supports.  Combining the token with some means of entry authentication–e.g. an identity badge–helps to ensure that it will be easier to sign onto the computer within the approved system than without it.

Network file share permissions are another area where special attention needs to be directed.  Without clear and consistent direction, such fileshares will end up a chaotic mass of all-access folders, as those with the ability to grant permissions will be continually harassed to allow for various special cases of cross-departmental sharing and the like.  Consider installing a well known and well supported CMS–and there are several open-source options, such as Alfresco, to allow for proper management of files in a secure fashion that can be made easier to use than alternatives.

A system is only as secure as its weakest link; that link is often the willingness of users to cut corners in order to expedite their needs.  A careful administrator can, with proper setup and proper diligence towards securing the network, ensure that these weak links are strengthened enough to make the resources behind them more trouble to access than they are worth.