Let's mention some aspects that you should be able to pay attention to at all times.
The first typical problem is embedding a password inside an application code even if it seems weird.
Situations like this still take place
an application producer can still save a password in the code for good.
This means that changing the password is tricky.
It requires essentially a software update and it's very easy to sniff the password out.
There's a number of copies of the software that are publicly available.
It's easy to take a copy home and spend some time to check.
For example using Process Monitor if a password is transmitted or saved somewhere assume that the password
is not forwarded externally.
At any rate you can view directly the data structures of the program.
All you need to be able to do this is to have a debugging permission
a classic example could look something like this.
There's a function that verifies if a user who has logged on is an administrator
these examples that are discussed now are real and derive from existing applications.
The verification procedure looked as follows.
The password was TR 4 or 5.
JH and back arrow 1 s exclamation point or a similar value.
This is a pretty strong password.
It's complicated and difficult to remember.
Definitely not easily crackable but it doesn't strengthen security at all since it's impossible to change
it.
All program users share it.
You should really try to avoid this type of problems.
The second typical problem is using default are blank passwords for common applications
a source of this problem is likely the fact that an application has to have an original password a password
is provided to protect accounts created an installation.
But if a setup service doesn't enforce password change there's a high risk that a number of users will
continue to use the default password.
The same risk applies not only to software but also to network devices as well.
As a result of this practice staggeringly popular Internet Web sites contain databases of default passwords
one search databases maintained by search and search dot net as you can see at the time of preparing
the presentation here.
There were 461 vendors and almost 2000 default passwords available in the database
the internet certainly offers even bigger databases of this sort.
This suggests that even if you purchase an expensive application that is secure well designed and used
for critical enterprise operations anyone who purchased it as well may know your password since your
unchanged password is the default password for this application.
How can you identify if you're in a risk group read user manuals carefully.
If after first log on you are required to provide a given password or a administrator's password is
provided.
This is a signal that should set off a red flag.
It's even worse if supported vendor data says that if you can't run the application or can't log on
you should call a help desk to retrieve your password.
Why should the support center know it.
After all the password is supposed to be the exclusive password to your application.
A lesson to be learned is that it's vital to change passwords in everything running your networks in
all programs web applications routers and manage switches.
If you neglect this the security level of your system will practically drop to zero.
The third source of the threat is requiring administrative permissions.
This is a widespread problem that has recently thankfully started to be addressed by software producers.
This is partially due to the advent and popularity of 64 bit systems
a number of programs including those produced by major producers and companies can only be run in Windows
by an administrator.
The programs in question aren't simply low level programs that can be assumed to need the permissions
for some reason.
For example a CD emulator this category can even include image editing software that for some reason
won't run unless it's granted administrative privileges This usually is due to some programming bugs
in the application.
The bug could potentially look something like this a program wants to access a selected text file.
Nothing unusual programs read and write to files all the time.
But for whatever reason this program demands full control access even though it only requires the read
write and exit permissions.
It demands to be granted all existing permissions
default folder ACL lists are usually determined in such a way that gives a standard user the permission
to modify folders but not to have full control over them.
This user can't for example take ownership of a folder because the above portion of the code is included
in the program for no reason.
The program doesn't run under standard user permissions most programming bugs originate in applications
attempting to refer to files folders or system registers that specific users do not have permissions
to access.
If a software producer does not plan on patching the problem you can do it on your own.
So this internal suite tools will be healthfulness process explorer in particular as well as process
monitor in one of the earlier lectures process monitor was covered extensively when you run this utility
you'll be able to monitor all activity of a selected process.
In this case of this program you'll know what registry key is and what folders the program tries to
access and see if the attempts were successful or failed.
If there's an error you'll be able to see if it's a permissions error.
If it is simply granted appropriate permissions to a specified registry keys in folders the program
should operate without problems after that until you do this the program will not be secure.
One of the most common problems is that applications have a longer lifetime than operating systems few
of us still use a 10 year old operating system in the world of computers 10 years amounts to 50 years
in the automotive industry.
You don't come across running cars that are 50 years old.
Users have grown so accustomed to it that they don't even think of updating it or replacing it with
a newer model.
It's become a fixed value in an enterprise.
This means that we will not be able to update the environment in which it operates.
Sooner or later it might turn out that the application only runs on specified systems or runs on a newer
edition of the system.
But for example without service pack 3 you've previously witnessed that earlier Windows systems Windows
XP not legacy additions are vulnerable to a number of attacks
user credentials are likewise not well protected
service packs are released for a reason.
One of the major reasons is to secure systems to eliminate known holes and flaws.
Their role is not to add to system functionalities.
This is done by feature packs.
You can for example read on an application vendor's website that the newest version of your purchased
product is not compatible with the latest security update issued last month by company x.
All you can do is to install it and test it at your own responsibility.
Vendors can also warn you that they have revealed that their product is unstable after a service pack
3 is installed.
If this is the case you should get rid of the application as soon as possible.
This is the only way to convince software manufacturers to respect their customers and to show consideration
for your security this module presented some typical problems focusing on problems related to application
security.
We've assumed that an administrator will not overlook critical problems and threats of this sort and
we'll know how to react to them or at least will know that the problem requires quick steps to solve
it.
Thank you.