How serious security fails are born? - A fictional chain of events

Post date: Oct 10, 2014 4:26:31 PM

This is fictional story, but all individual parts and thoughts of this story are real. As any experienced ICT guy should know. Take the easiest shortcut to get something done, and then encounter some problems which need to be quickly and cheaply solved without thing what will follow from made decisions and actions.

Very powerful and complex API is required allowing to do 'all kind of things'. Conclusion, it's way too expensive, slow and complex to do such API. Question: Aren't there any better (faster & cheaper) ways to do it?

Of course there is. Let's just make POST form which allows executing SQL scripts as SA / ROOT. It'll be done in no time, and it's more powerful than most complex REST API. It takes just a day to do, and it'll be more powerful than any REST API you can come up, even if you work for years on it. Because it basically allows you to do everything and anything you'll ever want to do with the database.

SQL interface is being used, of course over HTTPS with client certificates. This is great, because client certificates make it very secure, and therefore there's no need to do other 'key & account management' features, because HTTP server takes care of it. In the initial configuration someone might think about security and even setup IP filter rules.

This is excellent, because now trusted partners and integrators as well as own maintenance staff can utilize this interface. It turns out to be great success, because it's just so handy to post arbitrary commands to SQL server and get things done using browser only.

After a while, there's for sure a case where customer is using dynamic IP or they have backup connectivity using NATed 4G connection or something similar. At this point, the IP firewall rule gets dropped, because... Things won't work because someone has misconfigured the firewall or something similar.

Next step in evolution is the usual case where there's some problems with SSL. Someone important doesn't get it to work, fails with client certificates, cert expires or whatever, as we all know the usual story. Well well, now we need to drop the HTTPS. It doesn't really matter because nobody really knows about this secret API anyway.

Mobile Application developer wants to make quick'n'dirty integration for customer who isn't willing to pay a lot for systems to work. Now there's this bright idea. We don't need to implement our own back-end system, if we use this SQL API directly from mobile app. It's great, we can get all the integrations you want to work with the system easily. As well as, it's really easy to extend it. Of course guys at the other end think that the interface will be used via their integration / client server, which verifies all content & does access control checks etc. But as usual, this crucial step is side stepped.

As result of this process, the end users mobile phone application now directly uses unauthenticated, non-encrypted, HTTP connection to database server's HTTP REST API running with SA / ROOT privileges allowing execution of arbitrary SQL commands. - What could go wrong? This is a great way to get things done, everything just works, and any required changes are easy and quick. Just change SQL commands in the final mobile app, and everything works. No need to do slow API changes, update documentation, security audits, and other slow and expensive stuff. Just get results, and fast.

Great, isn't it? I've seen so many projects where nobody's really interested about getting the complete picture of the system being created. Everyone is just working on very small part of the complex end result and don't care anything about the rest. Then the end result can be total disaster. Unfortunately customers also often tell vendors that do what ever dirty and quick solution which kind of works. It's extremely rare that anybody is interested about security matters. Even in cases when there's money directly involved and substantial abuse risk.

Yes, this might sound really horrible to some people. But this is the reality of just so many projects. I don't mean that this would be exact sample. But all these steps in some kind of random permuted fashion.

I've seen cases where Microsoft FTP is being used with Administrator account and remote desktop is enabled. As well it's very common to receive SFTP account information for file transfer, but when you investigate the situation a bit, you'll notice that they haven't prevented shell login either. Etc. Why bother, shouldn't we full trust integrators & partners anyways? Same applies for single purpose VPN tunnels, it's very common that the VPN end points aren't restricted correctly to the required services only.

But these are just a few old examples and small tip of the ice berg.

Last comment is that often it seems that people are really reluctant to talk about serious issues like these. They don't care, they just really don't care at all. As well as they do see the fix unnecessary and maybe costly and problematic. It works now, just don't touch it. Does this attitude make the problem go away? I personally think it just makes the problem a lot worse.

All that talk about refactoring and audits, is just silly. Customers usually want that things are done using what ever tricks and kludges so it's cheap and barely working. After that kind of orders and coding, it's just ridiculous to complain about security or usability issues. What is being done, is minimum viable code. Everything that's not absolutely essential, is left out. Things do work, when used in certain envelope, outside that envelope anything is possible.