Are you a hacker? Programmer? Software developer? Coder? Many of us are. And, as intelligent humans, we tend to concentrate on the new and not try to reinvent the wheel, instead benefitting from what has been already created elsewhere. So we have more time to produce something new, something adapted to our needs, and leave the basics to software packages already produced somewhere else. Standing on the shoulders of other hackers, programmers, developers and coders worldwide, Gitlab at CERN, Github around the world and Stack Overflow, to name just three, provide a vast variety of libraries and code snippets for already existing functionalities. All you need to do is download or copy-paste them. But what if those hackers, programmers, developers and coders turn rogue?
Open source code is great, but does not come without risks. As anyone can write and share code, it is an inherent fact that some code comes with blatant security vulnerabilities. These are not necessarily introduced with malicious intent but the openness of the source code allows anyone to verify the integrity of the code and correct it if needed. However, sometimes even the open source community fails to identify major vulnerabilities like “Heartbleed”. So reusing public libraries comes with a risk. And this risk becomes more severe if malicious third parties intentionally tamper with software libraries and just wait for software developers “driving by”, downloading those malicious libraries and running that code in their software. Code executed and… boom! It would not be the first time that companies have been compromised through malicious libraries or modifications thereof. For example, a backdoor was discovered in the Python module named “ssh-decorator” distributed through “PyPi”, a repository of software for the Python programming language. Any SSH connection credentials were forwarded to a malicious party. Similarly, some malicious libraries have been named to resemble the name of a real, widely used library like, e.g. “crossenv”. But the fake one (“cross-env”) was extorting local environment variables and, potentially, also credentials. Thirty-nine more typo-squatted libraries were identified and deleted from “NCM”, a popular package manager for the JavaScript programming language. And then there are legacy libraries, not maintained by anyone any more, but still in use. In this example, the ownership was naively passed over to a malicious evil-doer who then introduced some malicious code in the otherwise clean library…
So automatic integration of external software libraries e.g. from PyPi or through NCM comes with a risk! Like with surfing the web, STOP – THINK – DON’T CLICK (or rather, don’t import). Only install software libraries from trusted sources. And even then, inspect the code either manually (cumbersome as it is) or run at least a static code analysis tool on top of that. The CERN Computer Security Team provides a variety of static code checkers for that purpose. Also consider using a centralised software repository manager like Sonatype Nexus or Apache Maven. The former is provided by CERN IT department and used for accelerator control system development and in the ATLAS and CMS experiments.
________
Do you want to learn more about computer security incidents and issues at CERN? Follow our Monthly Report. For further information, questions or help, check our website or contact us at Computer.Security@cern.ch.