Network Security Is An Application Layer Issue pt 2
Part 2 of a 3 part series
Continuing on the theme from Part 1. On another occasion, in an attempt to overcome what can only be described as “denial”, I sat in a conference room with the CEO and CTO of a small company (500~ employees), and with my laptop connected to a projector so they could follow the process, did something as simple as “right click” on a web page. Selecting “view source” allowed me to see the HTML that the page consisted of.
Additionally however, it allowed me to also see several references to included files, script libraries, network connections (server names and IP addresses), service account names and more than one database connection string…
Again, for the record, I am not in any way a “hacker”, and do not possess the required low level programming and network knowledge to be one. However, using the information from the include files and script directories and nothing more than basic network and SQL skills, I created a domain account, granting myself administrator privileges and went on to browse the various databases I could find. Eventually finding the PeopleSoft server, I brought up the HR/Payroll information for the CEO. The demonstration had the desired shock value. Unfortunately, denial runs deep. And once the CEO had regained some composure, he insisted that I was either in possession of inside information or that I was somehow unique and no one else would be able to so easily invade the network. As a result very few of the recommendations I made to harden the system were undertaken.
This was back in the days of classic ASP, and some of the shockingly easy ways to see secure information through the backend of a web page don’t exist with newer technology. But unfortunately some still do. And it seems for every hole in the security blanket we patch, we create 2 new ones.
If we then expand our view to the applications themselves, the pervasive nature of hard coded values is enough to drive a security minded person to drink. All of the same kinds of information mentioned earlier are commonly used as string or literal variables with the na?ve notion that it is secure because once the source is compiled, no one can view them in the binary state. This is unfortunately completely untrue.
Shortly after the very first executable program was written, the very first decompiler was written. These are tools that enable a compiled binary to be converted back into a high level programming language like C++ or C#. The output of readily available decompilers typically looks like the original source, and in the vast majority of cases can be compiled and executed as easily as the original. Along with the original programming language, all of the strings or literals are also visible. A couple of minutes with Notepad and the “Find” command and any entry level programmer can find account names, passwords, IP addresses etc, just by focusing on some common key terms.
As a result, whether we look at web based, client / server or traditional desktop applications, lazy coding practices still present a significant threat. Configuration, Meta Data, Include and Resource files that contain clear text information about accounts, servers and networks litter the landscape.
The good news is there is a two-step process to essentially solve the problem;
- Encrypt strings or literals.
- Obfuscate the application
The technical description on how to accomplish these two halves of the security puzzle is very different depending on the environment, platform(s) languages used and of course the deployment method. Different enough that it is not practical to try and delve deeper in the span of this article. Either in-house staff or paid consultants can provide the technical path and know how. That it should be done is the point here, not how to do so.
So if the solution to the problem is so readily available, why does the problem continue to exist? There are several contributing factors, which only vary in the extent to which they contribute.
Denial
The vast majority of management from mid-level and above, display exactly the kind of denial as the individual described above. Even when presented with incontrovertible evidence that the security flaws exist and either have been or could imminently be exploited, “management” steadfastly refuse to acknowledge the problem.
Faced with the repercussions of admitting to the defect, it is far easier to deny the problem exists. The scope of the problem, the scope of the fix and the risk to the business combine to create a culture of denial where people sit around conference tables and convince themselves “It can’t happen here”.
Politics
The politics involved can seem unimaginable to anyone who has not run headlong into the brick wall of a bureaucratic monolith of a security, governance, compliance or audit department. It happens far too often that individuals are more interested in justifying a payroll slot (or several), or growing political power. Using big words and vague policies these individuals and groups insist security is a treacherous minefield and only they can shepherd us safely through. If security practices we straight forward, simple and consistently practiced, those departments would lose headcount and prestige.
Inertia
Developers will not volunteer to make these changes in the way they work. They simply will not. They have enough policies, procedures, documents, rules, reviews and a seemingly never ending stream of tasks that are all serving at least some minor purpose, but the activities do not contribute to the fundamental work at hand. Adding tasks that do not add function or value to the code will not be volunteered. More to the point, there would be considerable mumbling and grumbling about the added work. So much so that managers are loathe to be the first one to declare it required.
But unless we strip away the denial, politics and inertia the end result is only one of three possible:
- My systems have been compromised.
- My systems have not been compromised…. Yet.
- The general public becomes aware of the absence of security, and the internet and eCommerce come to a screeching halt.
We must as a group, and as a profession insist that the issue be discussed. Enact functional requirements to implement security practices and enforce them. Let’s get past the egos, tempers and politics, and fix this before we are forced back to 3 part carbonless and inter-office mail pouches.