At the end of the cycle of articles on software security, let’s look closer into each of its categories that we need to defend against, which are policy issues, threat modeling and defense mechanism. I will give real examples to each of them from Amazon, Apple, Yahoo, Snapchat, Tinder and WhatsApp history.

Policy issues with examples

A policy is a statement of what our system is supposed to do and all the goals we are trying to achieve at some point. For example, it’s about confidentiality - who will have access to certain parts of the system. What’s more, important is integrity and modifying data or content but also availability to our users.

For example, saying that account X should have access to our admin panel is completely different policy than saying that no one else except account X can have access to our admin panel.

Real-life example can be a security question to reset accounts password. Knowing a password might be one thing but adding personal info like school, dog names etc. changes the deal. Especially for famous or public people. Years ago there was a case of Sarah Palin and her Yahoo account. Someone just simply figured out that all answers for all of those questions can be found on her Wikipedia account.

On Amazon, there was a case where you could buy something without logging in, by simply providing credit card details and account email and later use that new card info to reset the password.

Next, you could have used the previous card last 4 digits to reset someone's Apple account if u were lucky. That could have been a backup account for Google for example. I'm not joking, that was actually a case in the past.

Download Security Checklist and ask those 60 questions in your company to be up to date with the best security practices.

Threat modeling issues with examples

A  threat model is basically knowledge about the adversary. All the techniques, points of access and possible motivation for bad guys trying to compromise our data. It's basically trying to look through their eyes on our software to understand which parts should be specially taken care of. Good start for a risk assessment and for the team to look at the system holistically.

We should never assume that users passwords are safe, in most cases even with our password requirements. That's why we should be extra careful about users access rights.

Another thing is that computing power is increasing every year. Not updating, i.e. our encryption algorithms can be catastrophic over time. Like with Kerberos protocol developed on MIT in the mid-80s. Not using certificate pinning might mean that the bad guy needs to compromise just one certificate authority in the world.

The Defense Advanced Research Projects Agency (DARPA) was super sure that they created a secure system that they hired a bunch of people to try and break it. One of the teams has discovered that the system codebase is on a server in one of the employee rooms and its security wasn't best. So they broke in there, created a system backdoor in code, waited for the nest release and use that to compromise the system later on.

Mechanism issues with examples

Mechanisms concern all the software and hardware solutions that are making sure our policy is followed as long as the bad guy is following our assumptions from the threat modeling.

Again, I will point out that it's impossible to secure our system so it is unbreakable. It's a matter of making it really hard at least in a reasonable timeframe for them. Let me refer to more modern mobile problems that were discovered in recent years. By the way, all of them are already fixed.

Snapchat’s idea was to remove messages after a certain amount of time. It was done by sending a remove request from the client. Because it was optional, there were created a couple of apps using Snapchats API exploiting that vulnerability and then there was a leak of thousands of photos from those third-party servers.

Tinder as a dating app was showing (and still is) distance to your matches. It’s okay the distance is only an approximation, but as it turned out internally in a response from the API, there was for each match the exact last-long location provided. And that was not cool. So, of course, they have fixed that first by just sending only the distance that was being calculated on the server side so no locations in the response anymore. But another mistake was that that distance was provided with 15 digits accuracy. With that precision, you can easily find the users through knowing 3 different locations and trying to triangulate the exact locations of a particular match. Later on, also that problem was resolved.

WhatsApp is another interesting example and a super successful product with billions of users. Messaging apps, in general, are a category themselves in security, but let's focus on this one. Following vulnerabilities were found when it already had a dozen of millions of users. Firstly, the number verification process. It's a great idea that prevents someone else from using our private number. It turned out that verification code was created on the client (mobile) side and sent to a service, to then send it back as an SMS with that exact verification code to a specified number. It meant with a single device an attacker could easily verify every given number in the app. Also as a bonus, because there was no validation on that verification code that API could be used to send free SMS to any number worldwide. 120 characters were the limitation of an SMS itself, minus, a couple of words from WhatsApp.

Someone else has discovered that to change app number status you don't need to authenticate, it was a simple GET request. It was super simple to change anyone's status to whatever we wanted. There was even a website where you could do that easily. What is pretty scary was that the first quick fix was just to block all requests just from that website…

Also remembering to limit the number of requests is important. Especially for signing in purposes. Apple once had a problem with that, and because usually user passwords are rather simple it was very easy for someone to brute force all possible combinations. For WhatsApp, it was an API to retrieve statuses when uploading the contact book. In one request you could easily get millions of statuses for real phone numbers. Just imagine what a marketing tool that could have been…

Wrap up

At the end of my series of articles on various aspects of software security, I listed recent examples worth remembering when creating policies, threat models and mechanisms, including mishaps of Amazon, Apple, Yahoo, Snapchat, Tinder and WhatsApp.

The purpose of the series was of course not to teach how to write a secure system. It would be impossible! My idea is to evangelize security to raise awareness and educate people that should feel responsible for those tasks in their companies, so they would try to introduce some security-related activities into their process of software and hardware development.

Building a product for months or years and then losing everything in just one day isn't the best idea. That's why it's way better to prevent things from happening or at least trying to minimize the probability of it happening in production.

Dance like nobody's watching. Encrypt like everyone is.