Threat Level: green Handler on Duty: Brad Duncan

SANS ISC: Neo-legacy applications - SANS Internet Storm Center SANS ISC InfoSec Forums

Participate: Learn more about our honeypot network

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Neo-legacy applications

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.

Adrien de Beaupre

353 Posts
ISC Handler
Jan 29th 2010
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.

4 Posts
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.

4 Posts
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.
3 Posts
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?
Steven C.

171 Posts
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.

43 Posts
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.
1 Posts
What's worse is when the software is supported (And actively being developed) by such companies as Microsoft
2 Posts
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!

Al of Your Data Center

80 Posts
My opinion on regulation or auditing of this sort of thing, is that there is a tendency to certify a set of 'ticky-box' proprietary systems as secure, because the vendor's marketing said so, the specs looked okay on paper and/or they paid the right people to get their product approved. Any competing (and potentially better) products would be essentially illegal to use in your company.

Maybe no real progress will be made until a whole new wave of cybercrime or cyberterrorism has necessitated it. Until then I feel that technology will seem to only go backwards, increasingly useless, and perhaps even dangerous. I think this applies equally to corporate and public-sector systems, and desktop computing.
Steven C.

171 Posts
That's why EULAs were created by software vendors, and situations like these are arguably a case for the use of open source alternatives to certain commercial products. EULAs and licensing terms don't generally benefit you.
Steven C.
4 Posts
So what did you have in mind as being the right solution ? "Security is a user management responsibility".

It was easy in the days when all users of a system were paid by the same business ... salesman in showroom plus back-office at 'central' ... and you could threaten to sack anyone who exploited a bug.

But we're Internet-connected now; no business is large enough to employ us all; and we all have different agendas.

I don't actually know where it leads; I suspect an 'Internet Melt-Down', followed by the world's engineers trying to build up a replacement system to facilitate communication again.

Other opinions welcome, of course.
Steven C.
9 Posts
This is almost a direct quote from one vendor when I brought up security concerns:

Security is YOUR problem. It is YOUR job to provide a safe environment for me. I should not have to make changes to my program because YOU are not doing YOUR JOB.

Sigh, and people wonder why breaking into a company is so easy.

11 Posts
I'm not convinced that this is actually new. Remember the amazing Litchfield rant? It provided a great glimpse into the economics of the situation.

"...gain SYS privileges - in other words gain full control of the database server. The example exploit I sent to Oracle contained a space in it. Oracle's fix was to ignore the user's request if the input had a space. What Oracle somehow failed to see or grasp was that no space is needed in the exploit."

"...In other cases Oracle have simply dropped the old procedures and added new ones - with the same vulnerable code"

To this day, the entire Litchfield rant should terrify people. Not because of Oracle, but because their customers actually tolerated such a product, continued to use it, and in fact deployed more of it.

Large scale or small, I'd suggest that Crappy Software Vendors are the least of our worries - and competence has little to do with it.

42 Posts
No surprise, really. Banking people peddle their applications with the same arrogance as they push their "financial products". More than once did I get to hear something along the lines of "Nobody else has complained about this. Do you want to use this [trading|ticker|analytics|charting] application that makes other firms billions per day, then shut up and use it as it is".

385 Posts
ISC Handler
This is an issue I have argued with vendors over the years and continually addressed with my techs. In May 2008 I made the following statement in a memo to our entire technical group:

". I challenge any tech to prove that any necessary end-user business related application actually requires administrative or even power user rights. Until you can do so, the assignment of end-users to groups with administrative and/or power user rights should cease immediately. "

Well, in nearly two years, I've only had one tech challenge me and that challenge fell very quickly. No users in our organization are to have admin or power user rights and our systems are scanned regularly for those that have users in these groups.

IMHO, Most vendors stipulate administrative rights are required as it is not expedient for them to determine, document, or support the necessary individual settings that may require elevated rights.

57 Posts
There are a few things at work here, I think:

- In many cases these are specialized applications with a small customer base. This means there's not much competition to spur improvements, and also not much money available to revamp the code.

- Many of these apps date back to more innocent times. At least one accounting package I had to support was an old MS-DOS BTRIEVE database app thinly wrapped in a Windows UI.
Sorry about the duplicate post, spastic finger syndrome struck. But feel free to issue my challenge to your own staff.

57 Posts
What I find particularly alarming/amusing are SIMs, network monitioring, and log management applications which require local admim rights.

48 Posts

Sign Up for Free or Log In to start participating in the conversation!