Software development security: learn from others’ mistakes

Disclaimer: since the word “hacker” has several meanings, one of which being “one who enjoys the intellectual challenge of creatively overcoming or circumventing limitations” as opposed to “a person who circumvents security and breaks into a network, computer, file, etc., usually with malicious intent” which is more popular today. Since I personally prefer to use the former meaning, I will use the term “cracker” for the latter one.

What are you afraid of?

First, let’s go back to 2015 when the action of “Back to the Future” takes place and Ashley Madison, an online dating website, was compromised by crackers from The Impact Team,  revealing several million users’ data. It’s needless to mention that many of them were cheating on their partners which lead to blackmailing. Not only did the website loose control over 300 GB of data, but also faced 30 million USD in fines.

Among numerous bad practices that this breach exposed, one is particularly worth talking about: the way to keep passwords. Although users’ passwords were kept with accordance to industry’s best practices, using strong bcrypt hashing algorithm, at the same time they were stored using a much weaker, MD5 algorithm. “How much is much weaker?” You might ask. Well, there are online tools that kids from primary schools can use to retrieve passwords without even knowing how is the process going.

What should we learn from this case? Well, you have to answer a really important question: “what I am afraid of?” And then take proper measures against a threat and check whether you have achieved your goal. If you store users’ passwords, you want them to remain secret. You will ask your developer to use the best techniques to secure them, but after they say the work is done, there’s time for verification. Maybe they also use some weak hashing algorithm somewhere else? Maybe the plaintext passwords are logged as it was in Twitter’s case? Is the threat being tackled and you are safe or you only think you are safe? Maybe there is a reason to implement Two-factor Authentication like django-trench?

Procedures are useful. When used.

Two years earlier, a Lithuan criminal creates clones of companies some big tech corporations regularly make business with. Sitting in his cozy flat he manages to convince these giants that they should send payments to his bank accounts. His secret weapon is not any sophisticated virus, but an email. How deadly it is? Well, only his attacks lead to $100 million USD losses. To put this in a perspective, Amazon offers service that sends 10 000 for $0.1. Assuming that he had to send 1000 emails to achieve this number, it means 10 000 000 000% revenue. Or a cheap version of the F-35 fighter. Or Falcon Heavy rocket. Or twice the GDP of Tuvalu island. This scam took place for two years, meaning that the amount of cash on the attacker’s account raised in about the same rate this little country’s economy produced goods. And this case is not the only one. Ubiquity lost 46 million dollars and Ryanair 5 million. Impressive, isn’t it?

Lesson learned: when you finally decide what are you afraid of and develop proper procedures to mitigate threats, always stick to them. For example, if your contractor changes bank account number it’s a good idea to confirm this change using different means of communication.

Patch, update, reboot

Now, let’s move forward to 2017. Imagine a small town with 80 000 citizens. This town manages every fifth container on the sea on one of its 800 vessels some being larger than aircraft carriers.

This entire town stops operating within a few minutes, all computers turn black and display the infamous screen “oops, your important files are encrypted”. The NotPetya attack that used EternalBlue exploit leaked from NSA’s labs, hit companies on Ukraine and those connected with them all around the world. When the malicious code leaked, Microsoft developed and released a patch for all their systems (including unsupported Windows Vista and Windows XP), but many users did not install it. The problem was even more severe due to the fact that once one machine got infected it got its passwords retrieved in order to try to log into patched machines and spread further.

So next time when you see a popup asking you to install security updates, do not postpone it forever. These few minutes when you wait before leaving the office until you get your system patched may save your job.

With great power comes great responsibility

And there are few companies that know this better than Google. Our last stop is in December 2009 in California, when today’s second largest company (among others) learns that it’s been attacked by Chinese crackers. Infamous Aurora attack got described on Google’s blog, where they presented what has been discovered. Huge scale operation targeted many other well-known companies who got their secrets stolen. How could it come to this? Did Google overlook some significant flaw in their infrastructure? It turns out that the attackers used something called a “zero-day vulnerability”, ie. such that has not yet been disclosed and that does not have patches against. In this case, it was Internet Explorer that became the target. Crackers used the access they gained for several months stealing Google’s secrets.

Each company, especially big ones, face the risk of getting under crackers’ attack, but really valuable ones face the risk of being under really sophisticated ones. Good news is that it’s only worth attacking really valuable targets since malware for such purpose can cost several million dollars. The bad news is that if you create your own infrastructure it can also contain some sort of “zero-days” due to the wrong usage of libraries and frameworks. It’s easy to overlook some non-trivial flaws, so it is a good idea to have someone take a look at your product and search for such bugs. This goes beyond typical quality assurance, but a well-trained staff can do some of the work in this field and similarly, well-trained developers can spot dangers while the product is still in development phase. You don’t have to have your own Project Zero, but introducing product analysis of vulnerabilities to take down threats before they go on production is advisable.

Final thoughts

This is only an overview of what you should think of when designing software in terms of security and privacy. I have deliberately avoided suggesting specific measures since each company has a different product and require different measures. A simple mobile app that never contacts a backend server will have to be checked against different threats than the shipping company. Are you processing sensitive data and are afraid that exposing them will damage your reputation and cause multi-million fines due to GDPR? Are you a government institution that could be targeted by foreign service? Are you a small company that has trusted contractors that could unexpectedly change their bank account? Keep those questions in mind and consult a specialist before making any decision.