19 Attacks - Attacking Software Implementation
Implementation Overview. A perfect design can still be made vulnerable by imperfect implementation. For example, the Kerberos authentication scheme is renowned as a well thought out and secure authentication scheme, yet the MIT implementation has had many serious security vulnerabilities in its implementation, most notably, buffer overruns. Indeed, we can ensure that every aspect of the design is secure and still produce an insecure product. The problem is that security is not communicated well down the design hierarchy.
Developers are usually given a list of requirements that emphasize which interfaces their component should extend to the rest of the application and the form of data that their component will receive. They are also given requirements for the computation to be performed on that data. However, specific requirements are seldom given as to exactly how that computation should be performed.
Attack 16: Get between time of check and time of use
Data is at risk whenever an attacker can separate the functions that
check security around a feature or a piece of data from the
functions that actually access and use these features or data. The
ideal situation would be to ensure that every time sensitive
operations are performed, checks are made to guarantee that they
will succeed securely. If too much time elapses between the time the
data is checked and the time it is used, then the possibility of the
attacker infiltrating such a transaction must be considered. It is
the old “bait and switch” con applied to computing: Bait the
application with legitimate information, and then switch that
information with illegitimate data before it notices. This
attack is designed to exploit this time delay and penetrate the
process between these two functions, with the goal being to force
the application to perform some unauthorized action.
Attack 17: Create files with the same name as files protected
with a higher classification
Some files enjoy special privileges based on their location. For
example, take dynamic link libraries (dlls). These libraries are
used to perform certain tasks and are loaded by the application
either at startup or when needed. Depending on where these libraries
are located in the directory structure, a user with restricted
privileges may not be allowed to alter them or write to the
directory that contains them. Attackers can take advantage of the
fact that these libraries are usually loaded by name, without any
further checks to make sure that they are indeed the desired files.
This can be exploited by creating a file with the same name and
placing it in a directory the user does have access to that the
application may search first.
A related issue is that some files are
given special privileges based solely on their names. This is a
common phenomenon, especially with antivirus software that operates
using a complex mesh of filtering rules based on filenames and their
extensions. This attack will target both behaviors and is applicable
any time an application makes execution or privilege decisions based
on filename.
Attack 18: Force all error messages
Error messages are used to convey information to a user. Their
purpose is to alert a user to some improper or disallowed action
that may have been attempted. Our goal in this attack is to try to
force the range of error messages that the application can display.
Those of you who read the original How to Break Software book may
remember this attack. In that book, our focus was to think through
the possible illegal values that could be entered into a field. By
trying to cause error messages, you are actually covering the range
of bad input to the application and testing its robustness to that
data; an example would be trying to enter a negative value into a
“number of siblings” Web field. Obviously, this is an illegal value,
but by trying to force the application to display an error message
indicating this, we are actually testing the application’s ability
to appropriately handle illegal input. The goal of this attack is to
find a situation that is not handled appropriately; that is, no
error message is displayed, and the application attempts to process
the bad value.
Attack 19: Use Holodeck to look for temporary files and screen
their contents for sensitive information
Applications routinely write data to the file system, which can
store both persistent (permanent) data and also temporary data.
Temporary files can be created to transfer data between components
or to hold data that may be either too large to hold in memory or
too inefficient to keep there. If this data (CD keys, encryption
keys, passwords, or other personal data) is sensitive, then the
mechanism for storing this data and access points to this data need
to be investigated. Testers, especially security testers, must be
aware of when, where, and how the application accesses file-system
data.
To be effective, we must identify which data should not be exposed to other potential users of the system. After sensitive data has been identified, we must find creative ways to gain insecure access to it. It is important to keep in mind that software lives in a multiuser, networked world, and just because our software created a file and deleted it doesn’t mean that those operations went unnoticed by prying third parties. Our primary observation tool for this attack is Holodeck, which can monitor the application for file-writes and log these behaviors so that we can sift through them. Holodeck can tell us the when, how and where of every file access an application makes. It’s up to us to investigate what was written and whether this data is supposed to be secret.
| Attacking Design (#9 - 15) |
 |
 |
Attacking Dependencies (#1 - 5) |
