SQL Injections and Election Security

Is your head in the sand? Not doing adequate security testing might make you feel safe, but not knowing the vulnerabilities of your code won’t keep your systems safe. Learn how to get more visibility and build security into your code.

Just as fair and accurate elections are a foundation of democracy, secure software is critical to our modern digital lives. I’m not comparing these to be cute, but rather, digging into the intersection of the two, which can be disastrous. Recent analysis of our voting systems in the USA have shown us that they are riddled with insecurities. Voter data is stolen easily and often. Now, when you think about this vulnerability across the approximately 10,000 local voting jurisdictions, of course it seems probable that some of these systems aren’t secure.

Perhaps the most frightening and informing of these stories is that at a recent DefCon Hackathon, an 11-year-old was able to access election results data on a test system by using my ol’ favorite, SQL injection. It took all of 10 minutes. I guess I’m not surprised, since I’ve long thought of SQL Injection as child’s play (that’s why I made the SQLi Hall-of-Shame). One DefCon organizer noted:

“These websites are so easy to hack we couldn’t give them to adult hackers — they’d be laughed off the stage”

Election officials, in this case, claim that the real systems are much harder to hack, but I’m skeptical. This kind of denial is common in the software security industry right up until the moment that an actual hack happens. Just look back to Heartbleed, which most didn’t take seriously until it was thoroughly proven. Or when vulnerabilities in tire pressure sensors were discovered after industry people saying it was too hard, with too many varieties, didn’t matter etc. The same for car key-fob attacks, which have happened as recently as a few weeks ago.

In another all-too-common move, many election officials haven’t done any testing. This head-in-the-sand approach may help them feel better, but not knowing what your security risks are doesn’t keep your systems safe. I guarantee that bad actors know exactly what vulnerabilities are out there.

We have to do better

We have to start doing a better job. It’s hard enough to secure internet-connected systems – we don’t need to give hackers easy access.

There is a common refrain in the cybersecurity community that 100% security isn’t possible. But while that is true, at the moment that’s NOT the problem. The problem is that we’re not even doing the easy stuff to secure our software – for instance, for neither the voter website or voting machines. I know that anyone who really wants my car can steal it, but I still lock the doors and I don’t leave the keys in it. Not securing your internet-connected application against input-based attacks means you’re letting someone drive away with all of your data.

How do we do a better job?

Regardless of the motivations of election hackers, be they nation-states, political organizations, or hackers in their basement looking for fun, it’s important to do what we can to increase the security and reliability of our voting systems. The problems can seem enormous, but in fact there are some basic things we can do that will be effective by plugging the most obvious holes in our leaky system.

Secure-by-design

Secure-by-design means that we have to starting thinking differently about application security and secure coding. It means we can’t test security into our software any more than we can test quality into a product. The “by-design” part means that we think about security first, and then we build secure applications, and we do security testing like penetration testing for the purpose of validating the security, NOT for the purpose of finding security flaws.

Ask yourself – what do you do when pen-test finds something? Do you follow it up with flow-analysis to find similar vulnerabilities? Do you then look for standards like those from CERT for strategies that show you how to code in a way to avoid what your pen test is finding? In the case of SQLi, this means doing input validation in a deterministic way that has no chances of missing user input.

Passwords

One common way attackers access devices is through passwords. If devices allow poor quality passwords, or don’t protect themselves against attempts to guess passwords, then they will be vulnerable. In the worst case, devices actually ship without any passwords until you configure one, or with some hard-coded default credentials. This is a problem that the industry has been aware of for several decades, but it still persists. Recent legislation in California requires device manufacturers to take basic steps in this area. It’s certainly not a complete solution, but an excellent start.

Secure coding standards

There are many cybersecurity standards and frameworks that you can use for guidance on what practices and processes one should implement to create secure code, such as unit testing, measuring coverage, running static analysis, peer review, etc. At a software level, this must ultimately lead to specific coding standards.

Coding standards include guidelines of different varieties. Some of them look for coding defects, identifying security issues without having to actually run the code. Others are anti-patterns, meaning they look for bad code that you should never use, or “code smells.” Still others are prescriptive and tell you a better way to code.

This last group is the only way to get ahead of cybersecurity. These standards are well-suited to a secure-by-design initiative, and will help you build code that is more secure in the first place. When you’re implementing your static analysis initiative for secure coding, make sure to look at the available checkers and be sure you have a good mix of detectors, smells, and prevention. Together, all three can harden your application, not only against SQL injection, but against all of the other common input-based attacks.

How to get started

Parasoft provides support for a wide variety of these rules for developers that use C, C++, Java, and .NET. We have support for common security standards like CWE, OWASP, CERT, and UL 2900, and because we started our static analysis offerings based on engineering standards, it seems to be the case that we have the largest set of preventive rules available anywhere. For example, we have a simple input validation rule that when followed ends the possibility of SQLi. It doesn’t do this by trying to chase tainted data through the myriad (and nearly infinite) flows of an application (secure-by-testing) but rather by creating code where there are no paths for input validation to be bypassed (secure-by-design).

This is a fundamentally different way of thinking about security. If you have an engineering degree, this kind of standards-based approach will be very familiar to you. If you’ve spent your life building software, this may seem new. But it will get you ahead of the curve in software security. Give us a call and try it for yourself.