Good bear, bad bear

Assuming you didn't just arrive from another planet you've heard (plenty) about the hack of the Democratic National Committee's email. The aftershocks continue to reverberate through the American political spectrum as people debate who did it, why they did it, and what the implications for the Presidential election were. 

But that's not what I want to talk about.

As 2017 dawns, do you want it to be the year you put your legacy code behind you? Or do you want it to be the year your legacy code gets you hacked? If there's any conclusive takeaway from the DNC hacks it's that there are bad actors out there with very sophisticated techniques ("tradecraft") to get into your systems. And in cyber security you can't just be right 99.999% of the time--you have to be right 100% of the time. And even if you've done everything you can your users can still be the weak link. Some of the DNC hacks came through a "spearphishing" email that appeared to be Google requiring a password change. Users clicked on a shortened (bit.ly) link which took them to a very Google-looking page requiring account credentials. Except the URL wasn't accounts.google.com but instead something like accoounts-google.com and people are busy and don't look closely and bang! The Rooskies got in. 

Once they did they inserted malware that's just scary in what it did and how it did it. Buzzfeed had a good write up on this whole process. These guys, known by many names but commonly called Fancy Bear and/or Cozy Bear, have hacked journalists who have been critical of the Russian government. They hacked the World Anti-Doping Agency. They hacked an Android app used by the Ukrainian military to aim howitzers; the hack told the Russians where the howitzer was located so the Russians could launch a missile on the site. Blammo! No more nasty howitzer.

Assuming no one wants to be hacked, let's look at some thoughts. DHS and FBI issued a report with detailed prevention and mitigation guidance which you can find here. It makes for some interesting reading. 

What  does this have to do with legacy? Old can be vulnerable. A quick scan on a vulnerability database shows over 4k vulnerabilities in various MSFT products, including these:

• Server 2003: 414
• Server 2008: 565
• Windows XP: 968
• Windows Vista: 538
• Visual Basic: 22
• Visual C++: 28
• Office: 353

This doesn't mean the new stuff is devoid of vulnerabilites, but as vectors are found and understood it gets harder and harder to exploit newer systems. Old systems, on the other hand, have known vulnerabilities and bad actors constantly probe to find the ones that haven't been patched. To make your life even more interesting, when Microsoft (or anyone, for that matter) publishes patches to modern vulnerabilities, the bad guys immediately test those older systems (which aren't being patched anymore) to see if that vulnerability exists there as well. And you can imagine how that plays out shortly thereafter.

Here's what you should think about if you have legacy apps:

App Security

Hard as it is to believe, SQL injection attacks still succeed, especially since as far back as 2009 Heartland Payment Systems publicly wiped scrambled eggs all over their face when they admitted 100-160 million credit card were swiped via SQL injection. Jeez, how hard is it to do a little data validation? If you are going to have URLs like

http://mycorp.com/products.php?12345

 for lookups in a catalog, don't accept a URL like

http://mycorp.com/products.php?malicious SQL statements follow

Similarly, if you have a web form for people to request a new password, or retrieve their login info, make sure you parse that form input to ensure no random SQL strings are being sent to dump your database into an email response. And so on and so forth. SQL injection is so well understood and documented that falling victim in this day and age is practically criminally negligent. 

If they can't get in that way, there's always cross-site scripting (XSS). Again, if you've got web forms in front of your app with any kind of free form text fields you should validate the contents BEFORE it gets to the server to ensure it doesn't contain a payload. 

OS issues

If you're still deployed on ancient Windows platforms like XP, Vista, or Server 2003 you have vulnerabilities right there. Even if you're on newer versions still in support are all your users applying updates automatically? What's your vulnerability to zero-day exploits? Are you managing your network edge security against probes looking for ways to get in? There's no absolute reason that older platforms are necessarily more dangerous than newer ones, except in general they just are. The longer something is around the longer the bad actors have to study ways to attack them. 

3rd party components

VB6 was super popular in part because of the huge ecosystem built up by third party (i.e. non-Microsoft) vendors who built ActiveX components to make development easier. Those same components running in your app are vectors for malicious code execution. Most of the time this won't happen, but it can. 

Is this the year?

If the DNC hack does anything positive, let it be that we wake up in 2017 to the realization that sophisticated hacking is a real threat on multiple fronts. Countering this threat requires real vigilance, on-going remediation efforts, and constant education. One area you CAN focus on is moving critical applications off older, more vulnerable languages and platforms to more modern languages and platforms. 

And that's something we can help with.