Today, we will describe the ways in which you can extract the further information from the app during an actual attack. Well, this actually mainly involves interfacing with the app in the unexpected and also malicious ways and exploiting anomalies in the app’s behavior to extract information that is of a value for you. Such an attack, if successful, will enable you to retrieve the sensitive data, such as the user’s credentials, or to gain a deeper understanding of an error condition for fine-tuning your attacks, or even to discover more details about the technologies which are in use. Besides that, you will be able to map that app’s internal structure and its functionality. So, let’s see.
Exploiting Error Messages
There are many web apps which return the informative error messages when the unexpected event occurs. Yes, that may range from a simple built-in-messages which disclose only the category of the error to full-blown debugging information which gives away a lot of details about the app’s state. But, the most apps subject to various kinds of the usability testing which is prior to deployment. That testing typically identifies most error conditions which may arise when the application is being used in a normal way. So, these conditions are usually handled in a graceful way which does not involve any technical messages being returned to the user. But, it is a good thing to know, that when the app is under the active attack, it is likely that a much wider range of error conditions will arise. That may result in more detailed information being returned to the user. An online bank and other most security-critical apps have been found to return the highly verbose debugging output when a sufficiently unusual error condition is generated.
Let’s talk about the script error messages now. So, when the error arises, such as VBS script (or in any other interpreted web scripting language), the app typically returns a simple message disclosing the nature of the error, and possibly the line number of the file where that error occurred. It typically does not contain any sensitive information about the state of the app or the data which is being processed. But, it may though help you narrow down the focus of your attack.
There are many different ways in which this type of the error message may assist you in giving you a better understanding of the logic which is implemented within the server-side app. And why is that so? Well, because the message discloses the line number where that error occurred, and in that case, you may be able to confirm whether two different malformed requests are triggering the same error or maybe the different errors. Besides that, you may also be able to determine the sequence in which the different parameters are processed by submitting the bad input within the multiple parameters and identifying the location at which an error occurs. So, you will also be able to map the different code paths which are being executed on the server.
Stack Traces
It is well known that the most web apps are written in the languages that are more complex than the simple scripts but that will run in a managed execution environment. The examples are Java, C#, Visual Basic etc. So, when the unhandled error occurs in these languages, it is common to see full stack traces which are being returned to the browser.
So, what is a stack trace actually? It is a structured error message which begins with a description of the actual error. Then it is followed by series of lines which are describing the state of the execution cell stack when the error occurred. That cell stack has a top line which shows the function which generated the error, and the next line shows the function which invoked the previous function, and so down the cell stack until the hierarchy of function cells is exhausted.
Let’s take a look what this kind of error message provides. First of all, it provides you a great amount of the useful information which may assist you in fine-tuning your attack against the app. Let’s a list what it does for you.
1.It usually describes precisely the reason why an error occurred. It will enable you to adjust your input to circumvent the error condition and to advance your attacks.
2.The second thing that the cell stack does is that it typically makes a reference to a number of the library and the third-party code components which are being used within the app. So, you can then review the documentation for these components for better understanding their intended behavior and assumptions. Besides that, you can also create your own local implementation and test this for understanding the ways in which it handles the unexpected input and potentially identifies the vulnerabilities.
3.The stack trace also includes the line numbers which enable you to probe and to understand the internal logic of the individual application components.
4.It also includes the names of the proprietary code components which are being used for processing the request. It allows you to infer the details about the app’s internal structure and its functionality.
5.You can determine the exact version of the error message information about the app, which has been used on the ASP.NET platform. It will enable you to investigate the platform for known or even new vulnerabilities, anomalous behavior, some common configuration errors and much more.
Server and Database Messages
The informative error messages are often returned with some back-end component which can be for example database, mail server or even SOAP server. So, when the completely unhandled error occurs, the app often responds with an HTTP 500 status code and then the response body may contain the further information about that error. But there are some other cases where the app might handle the error gracefully and to return a customized message to the user, sometimes even including error information which is generated by the back-end component. Also, there are the situations where the information disclosure can itself be used as a conduit for the attacks.
Using Public Information
Because there is the great amount of web app technologies in various ways and the components in common use, you can frequently expect to encounter unusual messages which you have not seen before and that may not immediately indicate the nature of the error that the app has experienced. So, when you find yourself in this situation, you can often obtain the further information about that message’s meaning from the various public sources.
The unusual error message in most cases is the result of a failure in a specific API. So, searching for the text of the message can lead you to the documentation for this API or to developer forums and also the other locations where the same problem is discussed.
There are many apps which employ the third-party components for performing the specific common attacks. You’ve probably heard about the third-party components, and they are mostly talked about when the topic is security, so they are always a part of the internet security tips.
So, any error messages which are generated by these components are likely to have arisen in other apps and will probably be discussed elsewhere.
Also, there are some apps which incorporate the source code which is publicly available. Here, you may discover the source code which implements the relevant function. After that, reviewing it for understanding exactly what processing is being performed on your input and how you are able to manipulate that app for exploiting the vulnerability.
Gathering Published Information
There is one another primary way in which you can access the apps sensitive data. That is actually by publishing it directly. The reasons why the apps might publish the information an attacker could use are:
-by design;
-when the unintended side effect happens on the other app;
-by debugging the functionality;
-broken access controls.
So, that is how you can access the valid usernames, document IDs, user profile details, log files, app details etc.
Using Inference
We will know about the case when the app doesn’t allow you the data directly. But, it behaves in the ways which will enable you to reliably infer the useful information. There are many instances of this phenomenon.
Those are:
-the registration function, enabling you to enumerate registered usernames;
-a search engine, allowing you to infer the contents of indexed docs;
-a blind SQL injection vulnerability, which will allow you to alter the app’s behavior;
-the ”padding Oracle” attack in .NET.
So, let’s see what have we learned today. I think that we encountered so many useful information for you, don’t you think the same? I know you do. Let’s make a summary.
Well, as we saw, the leakage of unnecessary information frequently does not present any kind of significant defect in the app’s security. But, you can discover the sources of the information which are of the great value in developing your attack. And by the way, you can take a look at the cyber security tips, you may find other ideas how to break through there.