19 Attacks - Attacking Software Dependencies
Software Dependencies Overview. Applications rely heavily on their environment in order to work
properly. They depend on the OS to provide
resources like memory and disk space; they rely on the file system
to read and write data; they use structures such as the Windows
Registry to store and retrieve information; the list goes on and on.
These resources all provide input to the software— not as overtly as
the human user does—but input nonetheless. Like any input, if the
software receives a value outside of its expected range, it can
fail. Inducing failure scenarios can allow us to watch an
application in its unintended environment and expose critical
vulnerabilities.
Attack 1:
Block access to libraries.
Software depends on libraries from the operating system, third-party
vendors, and components bundled with the application. The types of
libraries to target depends on your application. Sometimes DLLs have obscure names that give little clue to
what they’re used for. Others can give you hints to what services
they perform for the application. This attack is designed to
ensure that the application under test does not behave insecurely if
software libraries fail to load.
When environmental failures
occur, application error handlers get executed. However, sometimes
these situations are not considered during application design, and
the result is the dreaded unhandled exception. Even if there is code
to handle these types of errors, this code is a fertile breeding
ground for bugs, because it is likely that it was subjected to far
less testing than the rest of the application.
Attack 2:
Manipulate the application’s
registry values.
The Windows registry contains information crucial to the normal
operation of the operating system and installed applications. For
the OS, the registry keeps track of information like key file
locations, directory structure, execution paths, and library version
numbers. Applications rely on this and other information stored in
the registry to work properly. However, not all information stored
in the registry is secured from either users or other installed
applications. This attack tests that applications do not store
sensitive information in the registry or trust the registry to
always behave predictably.
Attack 3: Force the application to use corrupt files
Software can only do so much before it needs to store or read
persistent data. Data is the fuel that drives an application, so
sooner or later all applications will have to interact with the file
system. Corrupt files or file names are like putting sugar in your
car’s gas tank; if you don’t catch it before you start the car, the
damage may be unavoidable. This attack determines if applications can handle bad data gracefully, without
exposing sensitive information or allowing insecure behavior.
A large application may read from and write to hundreds of files in the process of carrying out its prescribed tasks. Every file that an application reads provides input; any of these files can be a potential point of failure and thus a good starting point for an attack. Particularly interesting files to check are those that are used exclusively by the application and not intended for the user to read or alter; they are files where it is least likely that appropriate checks on data integrity will be implemented.
Attack 4: Manipulate and replace files that the application
creates, reads from, writes to, or executes
Similar to Attack 3, this attack also involves file-system
dependencies. In previous attacks, we were trying to get the
application to process corrupt data. In this one, we manipulate
data, executables, or libraries in ways that force the application
to behave insecurely. This attack can be applied any time an
application reads or writes to the file system, launches another
executable, or accesses functionality from a library. The goal
of this attack is to test whether the application allows us to do
something we shouldn’t be able to do.
Attack 5: Force the application to operate in low memory,
disk-space and network-availability conditions
An application is a set of instructions for computer hardware to
execute. First, the computer will load the application into memory
and then give the application additional memory in which to store
and manipulate its internal data. Memory is only temporary, though;
to really be useful, an application needs to store persistent data.
That’s where the file system comes in, and with it, the need for
disk space. Without sufficient memory disk space, most applications
will not be able to perform their intended function.
The objective of this attack is to deprive the application of any of these resources so testers can understand how robust and secure their application is under stress. The decision regarding which failure scenarios to try (and when) can only be determined on a case-by-case basis. A general rule of thumb is to block a resource when an application seems most in need of it.
 |
Attacking User Interface (#6 - 8) |