Neo-legacy applications

Published: 2010-01-29
Last Updated: 2011-01-24 23:56:36 UTC
by Adrien de Beaupre (Version: 1)
27 comment(s)

A friend of mine wrote in about a problem he has. He provides support to small businesses, one of which is in the financial industry. The problem is this, they make use of an application, which runs in a client server model. The 'server' shares out a folder for the clients to access, as well as a share on all of the workstations. The software requires that all NTFS and share permissions be set to 'Everyone - full control'. Sounds like a recipe for disaster to my friend, and I concur. This certainly violates the Principle of least privilege (POLP). In this case the client should be advised of the risk, as well as the software vendor. It also makes me wonder what other security best practices and secure programming principles were disregarded by the software vendor, and why they chose to do so? In this case the software is not legacy, it is current and supported by the vendor. The data within the application is considered highly confidential by the company, and the risk to the organization is high should it be lost, modified, or disclosed. If my friend chooses to disregard the vendor recommended configuration the software may not work properly, if at all, and may void vendor support or warranty.

Rob, a fellow ISC handler also points out the following issues he has also come across:

Applications that require users to be in the local admins group on the local workstation.
Applications that require users to have full rights on the app server.
Applications that require full rights in databases.
Applications that log every user into the application, the log them all into the  SQL database using a single account - usually  "sa"  (or equiv on oracle or mysql, but by far most prevalent on sql).

Oddly enough, where i personally see this the most is in financial apps - apps that run payroll, GL, order entry and warehouse management.  Also in support apps for banking clients if you can believe that !

So question #1 is - where have these appdev people been the last 10 years?  Is it just the same appdev people from 10 years ago, who haven't been thinking about security?  Is it new appdev people, who haven't seen security training?  Is it management in the application company who've decided not to develop the app with a secure access model?  Is it all 3?

Question #2 is - why aren't auditors reporting things like this as audit findings?  - I report this stuff, but it's always news to the client, even if they've had someone else auditing them in the past, this stuff never makes the audit.  Is this because there are too many "follow the script" auditors out there, and this just isn't on the script because maybe it's hard to describe?

Once you figure out you have a problem, what option do you have, other than finding a new business system with a better model?  You can't go change permissions on your own, even if it's the right thing to do, because the vendor will throw up their hands on the support side, and blame every problem you call them with on the permissions changes.  You can't change hard-coded db passwords without source code in most cases.

Adrien de Beaupré Inc.

27 comment(s)


My experience is that it usually is reported in the audit, but the audited organization just says "app necessary to business" and writes "firewall" under "Mitigation". All the boxes are checked, all the form blanks are filled, and everyone's happy.
I also find that many times something like this is not necessarily a requirement of the software but comes about through poorly trained support staff. They may have solved an issue by removing restrictions or elevating privileges once and now they instruct everyone to do it.
One of the biggest vendors insists that the sitting duck mode was required in all installs of their product so that the package can be installed on XP. Their name and flagship software product is very similar to Chex cereal. Nowadays we'd publish access to a cloistered server with this app via Citrix or Terminal server...but at the time it was cheaper to build a dedicated HR net. Their professional services staff had issues grappling with the idea that shares were not secure. It's all about what they think they can be sued for.
I have complained repeatedly to a vendor about their "client assumptions" and the file permissions they seem to think are 100% OK. They don't even recognise how bad an idea it is for ALL USERS to be given permission to OVERWRITE THE PROGRAM ITSELF. Even worse, some of the libraries involved (and which demand this soft of stupidity as well) were commissioned by the USPS, Candadian Post, and UK Postal service (and likely others as well).
Really makes one feel good about the amount of cash we shovel out the door for this stuff.
Maybe the business is too small to worry about separation of duties or principle of least privilege! They probably don't even have an IT staff! Maybe they're a small private company and have no auditors, nor do they require them...
I've witnessed this myself: a Win2k server with 'Administrator' account and a blank password, with networked (and Internet-enabled) client machines logging in with those credentials if they need read/write access to the company's electronically-stored accounts. Their annual turnover is probably in excess of £5 million.

I don't know how companies like this survive. Luck?
It blows my mind that people and applications are still insisting on this kind of stuff. We have been hardening the applications we sell for ages, and in the process testing all kinds of locked down configurations.
In my experience it's laziness, bean counters and at times momentum. I was contracted to build a system for ACH payment transfers to a large public utility. My end of things at the utility was fairly secure, however I could not get the bank to change their access passwords to the system on a regular basis. The folks that paid my bill told me to do as they asked (not implement any password policy at all). All I could do was advise, if they don't take it...well. This system was responsible for $2-3 million in payments per day.

Current place is getting better, however it took the impending PCI requirements to get any traction for security.

In many industries marketing drives development. Marketing wants features they can sell, security (so far) isn't really very marketable.

Just my 2 cents on that.
What's worse is when the software is supported (And actively being developed) by such companies as Microsoft
Just about everywhere there is one of these applications that just wipes out any attempt at security you might try to implement. When a data breach occurs and personally identifiable information is lost or credit transactions exposed there is a big to-do about it like they did something wrong and they get audited and held responsible. They were responsible, but if every organization has holes to poke right through, who is kidding who?

I find it hard to believe that anyone can be held accountable for something that the software vendor has implemented, and an auditor has accepted as safe. On the other hand, failure to update software, patch operating systems, tighten login credentials, limit IP access and the like is clear idiocy!

I know... the forms said "had to do it". The program is needed and we have to use it. Well.. not true! There are options always!

Chances are you can still be hacked, but at least it will take a master, not a script you can download for free to do it.

Those 10 year software engineers should know better, but most learn in the Windows world, where point and click is the easiest thing to do. Buying up parts of your package and integrating them is the biggest no-no out there, but it happens every day. Especially in Health Care, Banking and Government applications. No one knows what these things were written in half the time and no one can support them. After all... the company you bought doesn't exist anymore and the engineers are gone. S.O.L.

Sad... very sad that security is non-existent except at the border gateway. Even there.. not much.. not much at all!


Diary Archives