We all heard already that the compiled software which runs in a native execution environment has historically been plagued by vulnerabilities such as buffer overflows and format string bugs. But, most web apps are written by using the languages and platforms which run in a managed execution environment where these classic vulnerabilities do not arise.
Well, one of the most significant advantages of the languages like it is C or C++ have given rise to the majority of critical bugs which were found in that software.
Also, you may occasionally encounter the web apps which are written in the native code. Those apps contain the portions of the native code or call external components which run in unmanaged context. So, unless you know surely that your target application does not contain any native code, it is worth performing some of the basic tests which are designed for uncovering any classic vulnerabilities that may exist.
The point of all is-if you believe that the app which you’re attacking contains substantial amounts of native code, it may be desirable to test every piece of user-supplied data which is processed by the app, also including the names and values of every parameter, request header, a cookie, or any other data.
We will cover here the three main categories of classic software vulnerabilities.
Buffer Overflow Vulnerabilities
These software vulnerabilities occur when the application copies user-controllable data into a memory buffer which is not sufficiently large for accommodating it. In this case, the destination buffer is overflowed, resulting in adjacent memory being overwritten with the user’s data. It depends on the nature of the vulnerability, but the attacker may be able to exploit it for executing the arbitrary code on the server or perform the other unauthorized actions. In native software, the buffer overflow vulnerabilities have been hugely prevalent over the years and also have been widely regarded as Public Enemy Number One which developers or such software need to avoid. They typically arise when the app uses the unbounded copy operation (strcpy in C ) for copying a variable-size buffer into a fixed-size buffer without even verifying that the fixed-sized buffer is actually large enough. So, let’s say a username string contains more than 32 characters and then the _username buffer is overflowed, so the attacker overwrites the data in the adjacent memory.
So, how to detect the buffer overflow vulnerabilities? The best way is to send the strong strings of data to an identified target and to monitor for the anomalous results if there are any. Although, some vulnerabilities can only be detected by sending the overlong strings of a specific length, or within a small range of lengths. But in most of the cases, vulnerabilities can be detected simply by sending a string which is longer than the app is actually expecting. Before we go to the second category of these vulnerabilities, you may take a break and remind yourself of very useful cyber security tips and internet security tips!
Integer Vulnerabilities
Okay now, we can go further then. These vulnerabilities typically arise when the app performs some arithmetic on a length value before performing some buffer operation but fails to take into the account certain features of how the compilers and the processors handle integers. There are the two types of the integer buggers, and those are integer overflows and signedness errors.
The integer overflows occur when the operation on the integer value cause it to increase above its max possible value or may even decrease below its minimum possible value. So what happens when it occurs? The number wraps, a very large number becomes very small, or the opposite.
Signedness errors. They occur when the app uses both signed and unsigned integer for measuring the lengths of buffers to confuses them all at some point. So, the app will eventually make a direct comparison between a signed or unsigned value, or it may pass a signed value as a parameter to a function which takes an unsigned value. But actually, in both of the cases, the signed value is treated as its unsigned equivalent, and that means that a negative number becomes a large positive number.
It is feasible only when the attacker can directly control the parameter of the length.
Detecting Integer Vulnerabilities
There are the primary locations to probe for the integer vulnerabilities. They are any instances where an integer value is submitted from the client to the server. This happens in two ways:
1.When the app passes an integer value in the normal way as parameters within the query string, cookies, message body etc. The numbers are usually represented in decimal forms and by using the standard ASCII characters.
2.An app may also past the integer values which are embedded within a larger binary data or blob. They may originate from a client-side component such as an ActiveX control. Also, it can be even transmitted through the client in some kind of a hidden form field or a cookie.
Format String Vulnerabilities
This is the third category of these vulnerabilities. They arise when the user-controllable input is passed as the format string parameter to a function which takes format specifiers which may be disused, as in the printf family of functions in C. Then the functions take a variable number of the parameters, that may consist of the different data types such as numbers and strings. The string which has specifiers is the format string and tells what kind of the data is contained in the variable parameters, and also in which format it should be rendered.
So, how to detect the format string vulnerabilities? The most reliable way is to submit data containing various format specifiers and to monitor for any anomalies in the app’s behavior.
We talked about some new kinds of vulnerabilities today. I hope we were totally clear. This chapter is shorter, but it doesn’t mean that it is less important than the others. This is all you need to know about these kinds of vulnerabilities.
Software code vulnerabilities represent a relative niche area in the relation to attacks of the web app. We talked how the most apps run in the managed execution environment, and in such a place the classic software flaws are described as not highly relevant. But, don’t let this trick you! They appear on hardware devices and in the other unmanaged environments. Stay informed and safe and I really hope you like our articles!
We have so much more to learn together and we will do it in a simple and understanding way. Don’t be afraid that you will stay confused with us!