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.
Cheers,
Adrien de Beaupré
Intru-shun.ca Inc.
BoA Offline?
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.
Analyzing isc.sans.org weblogs, part 2, RFI attacks
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
Comments
www
Nov 17th 2022
6 months ago
EEW
Nov 17th 2022
6 months ago
qwq
Nov 17th 2022
6 months ago
mashood
Nov 17th 2022
6 months ago
isc.sans.edu
Nov 23rd 2022
6 months ago
isc.sans.edu
Nov 23rd 2022
6 months ago
isc.sans.edu
Dec 3rd 2022
6 months ago
isc.sans.edu
Dec 3rd 2022
6 months ago
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.
<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
isc.sans.edu
Dec 26th 2022
5 months ago
isc.sans.edu
Dec 26th 2022
5 months ago