5 simple practices to avoid cybersecurity blunders
It’s about how you use technology securely as a software engineer
Meaning of security, in digital world, is about securing information. Security is a cross cutting concern affecting all people associated with the information, be it users who are using digital application, developers who developed application and everyone else part of software team.
Earlier application developers had to go through painless process of fixing many security bugs by themselves. Nowadays application development is getting sophisticated with advanced tools, frameworks and libraries. Developers don’t need to worry about much in terms of application security, e.g. back in the days SQL injection was common though fix was easier people missed it, so ORM decided to abstract it. You may have guessed now that we are not going to discuss about how to handle vulnerabilities in code.
If you look at current state of cybersecurity, the highest number of attacks are not technical attacks, carried away by using state of the art vulnerability scanners or exploiting known vulnerability by writing fancy algorithms but they are Social Engineering attacks. It’s a deceptive technique involving humans.
Also due to increasing awareness of cybersecurity, people don’t fall prey for such attacks easily but that doesn’t mean whoever fall prey, the victims, are stupid. Everyone does a mistake in their life some point or other.
One of the basic rules of the universe is that nothing is perfect. Perfection simply doesn’t exist.....Without imperfection, neither you nor I would exist
— Stephen Hawking
In this article we are going to discuss about how we can avoid the simple mistakes done by software engineers, SWE doesn’t mean only developers, without getting too much technical, which may lead to catastrophic consequences.
1. Scan secrets on every commit
Most of times we have seen software engineers keeping different secrets or passwords in configuration files, as plain text, this itself is considered as an anti-pattern.
Still people keep them in plain text saying they are pushing code in Private Git Repository, but you never know someone new in your team may push a code in their own public repository (believe me this has happened with me) for reasons which i don’t want to get in(humans bend the rules for collaboration).
Other scenario could be, you are working on POC which involves tools and platforms needing passwords or secrets to access, like Cloud Platforms, Databases, External APIs protected with API Key and you push code to public repositories.
Simple solution to this problem can be using Git hooks, they are a great way to reduce human factor in making sure checks are always performed before code is committed or pushed. AWS Labs has open sources implementation which can be found here or the one by Thoughtworks Talisman. There are plenty of other implementations which you can choose from like Repo Supervisor, Git Hound etc.
Make sure every team member, involved in working with code, has these utilities installed and configured.
2. Double check what you are installing
Typosquatting attack or URL Hijacking is a social engineering attack where threat actors impersonate legitimate domains for malicious purposes such as fraud or malware spreading, in simple words it’s an attack leveraging spelling mistakes, typo errors.
Here we are applying same principle for dependencies we install in our applications by package managers like npm, gemor pip.
There is a really great thesis which explains how effective this attack can be, to gain access to a computer if a person makes a typo while installing a package using package managers. It’s an astonishing percentage of ~43% (out of total 17289) computers gave an administrative access to hacker.
Another surprising attack of Typosquatting with Packages is carried out with Docker images. Many software organisations are running their code in tons of docker containers and developers try to reuse existing docker images from DockerHub like registries. Though these registries can scan for malicious packages in docker images, attackers make sure to download malicious content at runtime to avoid flagged in vulnerability scans. You can see in this article
A dynamic analysis of the publicly available images on Docker Hub found that 51% had critical vulnerabilities and about 6,500 of the 4 million latest images could be considered malicious.
Though it looks horrifying, there are few basic measures we can take to avoid these attacks.
1. Double check package names before installing them
2. Before importing any package in source code, try to go through open security issues of the package/library and check code by yourself
3. Remove any unused dependencies from you code
4. Before pulling any docker image of open source tool, check Dockerfile and see if it’s installing all legit packages and at runtime it’s not going to pull any malicious code
3. Don’t post project details on public sites
It’s very hard to find a software engineer who doesn’t know about StackOverflow, no pun intended. We are very used to search for our software problems on such sites to get help from others.
When we are seeking help on such sites, sometimes we need to put some details like code, configurations etc. for giving a context of issue we are facing and this is when the mistake can happen by negligently copy/pasting internal information of your application such as secrets (Like mentioned in point 1), test login details
Similar observations are made in few project management tools, where software engineers manage their project related information. Detailed account can be read here, where it shows simple Google search of secrets or passwords targeted to public boards on Trello like project management applications can be a source of data to hackers.
To avoid issue of leaking software internal details, make sure you create a simple code snippet mimicking the issue you are facing in your software without using any actual variables, function or class names and only focused to the problem you are seeking solution for.
For second issue, make sure to convert all your public boards to private and if that’s not possible make sure to not add any sensitive information in cards. You can keep an eye on boards by running Google search queries mentioned in article, periodically.
4. Don’t copy/paste code blindly
I’m taking a liberty here and modifying Postel’s Law to “be conservative in what you send as well as what you accept". Like we mentioned in earlier on public sites you post your questions and expect for someone to answer them in terms of snippet of code and references to examples which can solve the problems.
There can be people who intentionally or unintentionally post the code snippet which can break your system or introduce vulnerability in your code, which later hackers can use to exploit your software. Don’t believe me ? Here is a blog by StackOverflow showing different vulnerabilities in sample codes posted as answers.
Look at this another example where simple 5 lines of code broke every intel processor
Whenever you are looking for sample code over the internet, make sure you understand what it’s doing. Don’t blindly take answers as truth and execute them on your machines or include in your software’s source code. If you can’t figure out what a particular piece of code is doing, stay away from it.
5. Check for vulnerabilities in dependencies
As we discussed in point 3, attackers can upload packages with similar names of legit popular packages. In this scenario packages are legit but they contain some vulnerabilities reported in say NVD (National Vulnerability Database) and can affect your software.
Nowadays SCM systems have integrated these scans, e.g. GitHub, where they scan the code on their platform and notify users if there is any vulnerability reported in specific version. Not only that but they also suggest the version of the package to include in you source which removes that specific vulnerability. This is one more reason, out of other hundreds, to use SCM.
OWASP Foundation (Open Web Application Security Project) also provides dependency check plugins/tools to scan vulnerable dependencies in your project.
TL;DR
Avoiding or Fixing security issues in a software is not only a job of Cybersecurity professionals, it is of every person involved in Software lifecycle. It’s not only a developer who can make software vulnerable because it’s not about only code. You should always be cautious while putting anything from a your software on public sites as well as while accepting anything from internet. Suspect everything that you are going to add in project which you are getting from open web, accept only if you have checked every aspect of it.
As per Peter Parker Principle “With great power comes great responsibility”
We, at KodeYoga, provide value consulting in Full stack development, Cloud Computing, Reactive programming following best practices to convert clients’ vision into reality. We have helped our clients to implement DevSecOps practices and adapt DevSecOps culture. Please follow us at Twitter and Linkedin for updates. Feel free to connect with us over email hello@kodeyoga.com for any questions, we will be happy to help.
