.png)
Coming from a background in cybersecurity, I am keenly aware of the past few weeks’ activity in the world of information security. From the Google phishing scare to the current disaster of Wanna Decryptor, it has certainly been a fractious week or two for anyone who may have been infected or damaged by those recent events.
There are of course many more smaller hacks, ransomware attacks and phishing incidents that go completely unreported. Having moved into the world of QA testing, I have begun to examine whether or not any of these incidents could have been mitigated (note: not completely avoided) through the use of testing. It’s often hard to get much detail on less publicised hacking and breach incidents so for the purposes of this article I will focus on a few major news breaking pieces over the last few weeks.
Wanna Decryptor
Case: Starting with the most egregious and recent of malware attacks we can look at the Wanna Decryptor/WannaCry malware package. While Microsoft Security Bulletin MS17-010 takes care of the critical security patch for all major versions of Windows since XP, could QA have come to the rescue or at least helped identify the problem?
Verdict: No. Unfortunately, the remote code exploitation has been largely undetectable for years with many suggesting the original issue stems from National Security Agency leaked hacks. (link). For a more detailed technical analysis check out this great write up by Malwarebytes.
Google Apps Phishing
Case: In the beginning of May, reports began swirling of Gmail users that were being phished using a sophisticated Google Docs email. What made this phishing attempt particularly credible was a few things. First and foremost, the email itself was a legitimate Google Docs file request. Second, the doc asked the user to authorize Google Docs in order to view the document. Unless the user was paying particular attention, this looked like a legitimate request to access the document because the application name was Google Docs.
Verdict: Potentially. The problem in this case with Google Apps was that, until recently, anyone could create an application that had essentially full access to a Google account with any name they chose. When it comes to QA, with sufficient testing of the ability to create apps a suite of test cases could have been created to test various organisation names and combinations. Exploratory testers could have also attempted to create apps using fictitious names.
Touch Screen Chaos
Case: A recent analysis by researchers at Kaspersky found that many of the touch screen kiosks we see around the cities we live and work in are ridiculously easy to hack (link). Researchers were able to gain full, unfettered, system access by using a technique called fuzzing which essentially amounts to providing input to the devices which they weren’t designed to ignore properly. In one case, researchers merely needed to hold down their fingers on the printer button to escape the locked down system.
Verdict: Quite likely. Exploratory testers are accustomed to attempting to get devices, software and operating system environments to do things that they should not. Creative exploratory testing encourages testers to try things that aren’t scripted. In this kind of scenario, testing by humans is going to go much further than an automated test because you’d need to know to test that very printer button under strange circumstances.
These are just a few of the examples where proper QA strategy, approaches and attention might go a long way in helping develop secure software. To be sure, however, this is not meant to suggest that QA is a replacement for security testing or following secure coding protocols such as OWASP or CERT. The examples are merely meant to represent situations where QA may or may not have assisted with the discovery of bugs that lead to cybersecurity issues.
If you have other examples where you think good QA might have helped produce more secure software please drop them in the comments below!