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.

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

27 comment(s)

BoA Offline?

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

The Bank of America web site appears to have been not available for parts of the day  today. No details on what happened have been released as of yet. Their twitter feed indicates they were aware of it and attempting mitigation. If anything does come out I will update this page. If you know anything please let us know!

Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.

Keywords:
3 comment(s)

Analyzing isc.sans.org weblogs, part 2, RFI attacks

Published: 2010-01-29
Last Updated: 2010-01-29 04:30:13 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

The 2nd part of the "Weathering the Storm" blog series is now live [1]. In this series, I am looking at our web logs from isc.sans.org for attacks.

I picked Remote File Inclusion (RFI) attacks because we are getting thousands a day. Just take a quick look at our web honeypot project [2]. Most of the attacks we detect are RFI attacks.

[1] http://blogs.sans.org/appsecstreetfighter/2010/01/29/weathering-the-storm-part-2-a-day-of-weblogs-at-the-internet-storm-center/
[2] http://isc.sans.org/weblogs/

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: logs php rfi webattacks
0 comment(s)

Comments


Diary Archives