The academic freedom at CERN demands a rather open computing environment, which is reflected in the liberal nature of the CERN Computing Rules (http://cern.ch/security/ComputingRules). Depending on your project(s), you have the liberty to use whatever programming language you wish to use, be it to program your physics analyses, your controls software or your web application. For the CERN Computer Security Team, however, such a liberal environment poses an interesting challenge, because this freedom of choice is hard to control and even more difficult to secure. Even more interesting, this challenge has to maintain a justifiable balance between CERN's academic freedom and its security.

You are responsible for securing your systems

To keep this balance, you are obliged to assume your share of computer security at CERN: you are responsible for the security of your systems, your services, your programs. In order to help you, the Security Team has prepared three new means of finding security weaknesses in your AFS folders, your code and your web applications.

1. Find your credentials before attackers do

Protecting sensitive information is an important cornerstone of computer security. Just as misconfigurations or vulnerabilities in applications can be exploited to attack computer systems, disclosed sensitive information presents a potential security risk too. For example, the public disclosure of passwords or private keys might allow an attentive attacker to directly enter CERN computer systems like LXPLUS or Windows Terminal Servers. In particular, AFS is a worldwide-accessible file system, so sensitive information stored there must be well protected.

Control your AFS access rights

During the past months, many credentials have been exposed on public and unprotected AFS folders. In many cases this is due to users having accidently misconfigured certain AFS access rights by mistakenly using the LINUX-based "chmod" commands, where "fs setacl" should have been used. Previous CNL articles explained how data can be protected by AFS' built-in access control mechanisms (see "AFS revisited: Controlling access" in CNL issue 3, 2008). In addition, the Security Team provides a tool to check (and if desired to correct) the access control lists on a user's home directory. The tool is aware of the structure of home directories, such as the default locations of private keys, and checks the access restrictions accordingly. This ACL checker is available from http://cern.ch/security/AFS.

Enforcement of default AFS access rights

To identify information disclosure early, the Security Team, in collaboration with the AFS Team, has started to scan proactively AFS folders at CERN. The scans are supposed to identify world-readable files containing sensitive information like private SSH keys. Going one step further, a campaign will be started during the next months to enforce restrictive settings for a well defined set of AFS folders. Once applied, public read access to, for example, your AFS home folder (~/*), to your private folder (~/private) and to your hidden folders (~/.*) will be disabled, and kept disabled. Furthermore, public write access to any of your AFS folders will be withdrawn, if the same folder also has public read access.

2. Find your bugs before attackers do

Another important part of improving computer security at CERN is to make the attackers' job harder by minimizing the number of bugs and exploitable flaws in newly developed software. While it is very hard to write perfectly secure software, there are some simple means to improve the reliability and security of your piece of software. One of the easiest ways is using Static Source Code Analysers. These tools look at the code without executing it, but point out what they consider to be potential weaknesses. A typical example of what such tools can find is calls to the "gets" C function. This function is inherently insecure and can lead to buffer overflows. Specially crafted user input values can for instance allow an attacker to access or modify confidential data or even take control of any computer executing that piece of vulnerable software.

Of course, such automated source-code analysis tools are only able to find a fraction of bugs present in a piece of code. Still, you are strongly recommended to use them to find at least some of the existing weaknesses (of any type, not only security related) - especially given how easy it is to install and run these tools.Because these tools need to understand the code, they are language specific.

Static Source Code Analysers at your disposal

The Security Team has evaluated a number of such tools, for various programming languages (C/C++, Java, PHP, Perl and Python) and has compiled a shortlist of recommended analysers, selected for their ease of use, their simple configuration and their established benefit in pointing out potential bugs.

This list of tools is available at http://cern.ch/security/CodeTools, along with advice on installation, configuration and recommendations on how to fix the most common errors, as well as pointers to websites and books containing further information. Most of these tools are available in SLC yum repositories, making it easy to install and start using them.

RATS, shorthand for Rough Auditing Tool for Security, covers C, C++, PHP, Perl and Python. It mainly targets calls to commonly misused or exploited library functions. It is a very fast tool, available on Linux and Windows.

For C/C++, David Wheeler, a renowned IT security expert, provides Flawfinder, which looks for risks of buffer overflows and race conditions. It is unfortunately only available on Linux. Coverity is a security company with extensive experience in C/C++ static analysis, responsible for finding many bugs in major open-source projects, such as the Linux kernel or implementations of samba and is contracted by the US Department of Homeland Security and Yahoo among others. Currently, the PH/SFT group is arranging an agreement with Coverity, which will enable CERN to use this tool.

For Java, FindBugs will find various security-related and non-security-related errors, for example vulnerabilities to SQL injection. It is available both as an Eclipse plug-in and as a stand-alone Java application.

Pixy will review PHP code and warn against risks of SQL injection and cross-site scripting. It follows execution paths in PHP code, looking for insecure use of values coming from user input.

The Perl::Critic CPAN module will raise warnings for many risky Perl idioms and, used in conjunction with Perl's tainted mode, it should help to produce secure Perl code.

As for Python, the most important thing is simply to keep your version of Python up to date with security patches (for SLC machines, it is done for you – the security patches are back-ported to older versions of Python). One step further is to use pychecker, which is very good at finding various types of potential bugs (not only security related).

3. Find your web application vulnerabilities before attackers do

Websites and web applications are the part of the CERN computing infrastructure that is directly visible and accessible from outside the organization. This means that attackers can see them too and often actively browse the websites maintained by you, and search for vulnerabilities such as cross-site scripting, code or SQL injection, local or remote file execution, cross-site request forgery, etc. Successfully exploiting such weaknesses in websites or web applications could result in web defacement, unauthorized access to information or functionalities, stolen users credentials, etc.

Last year, the CERN Computer Security Team started various initiatives to address this potential issue. Several technical training courses are now regularly offered for developers, including web and PHP developers. In co-operation with the Web Services Team, defaults for newly created centrally hosted websites were changed to be more secure (e.g. made visible only to CERN-authenticated users, using only static pages). These settings can of course be opened if needed for a particular website.

Scanning for your vulnerabilities

Soon, the Security Team will start vulnerability scanning of all CERN websites. The goal of this scanning is to detect security vulnerabilities and to improve the quality of CERN sites. All websites and web applications at CERN, visible on the internet, or on the General Purpose Network (the CERN office network) will be scanned regularly. Issues found will be reported by e-mail to the relevant website owners and must be fixed in a timely manner. Website owners may also request a one-off scan of their site or web application, by sending an e-mail to Computer.Security@cern.ch.

These web scans will be performed with automated tools. Several web application scanners were evaluated, and two of them (W3AF and Wapiti - both open-source tools) were finally chosen. Such tools first crawl a given website, looking for all scripts and their arguments. Then, they provide specially crafted values to each argument of each script, to detect those that are vulnerable to one of the common web application attacks. As with the static source-code analysis tools discussed above, such an automated approach cannot guarantee to detect all problems, but it is good enough to pinpoint the most common.

These web scans at CERN are designed to limit the impact on the website being scanned. Nevertheless, in very rare cases these scans may cause undesired side effects, e.g. generating a large number of log entries, or crashing particularly badly designed or badly implemented web applications. If a website is affected by these security scans, it will also be susceptible to more-aggressive scans that can be performed at any time by a malicious attacker. Such web applications should be fixed and also additionally protected (e.g. by restricting their visibility).

More security measures to come

Our list of projects mitigating security weaknesses is much longer. For example, in the near future we will start to review the configuration of CERN's outer perimeter firewall. Therefore, current firewall openings of your devices will be reviewed and you will be asked to consider closing those that are no longer needed.

Let's work together to find the right balance to make CERN a more secure place while maintaining its academic freedom.

If you have any questions or comments, contact Computer.Security@cern.ch.