by Stuart Rorer

A Comedy of Errors

It has been said “to err is human, and to forgive divine”. However, I think sometimes it can be said errors come from humans, and what they give is divine. Error messages can be a treasure trove of information in any area of pentesting. While it seems like such a small issue, sometimes it can be just the thing to elevate an attack to the next level.

Poking the Beehive

The first step is to actually find an error. Sometimes this can be hard when the application has error messages turned off. If the developer has been careful, as they should, they should have the application provide a generic error message while logging the real issue on the backend.

One of my favorite things to do is just sending the most unexpected input in hopes that the response will result in an error message. For example, if the application asks for a number, I love to give it a string instead. Often, if the application isn’t configured on how to properly handle errors, it will respond in some very interesting ways. An example error is shown in the figure below:

Typically, the goal is to try and identify places within the application that can receive some form of input. Parameters within a request, values within a URL, even cookies can call be areas that you should test to see if an error message can be produced.

Information Gleaned

In my mind, I often equate getting error messages from apps like playing the slot machines. I may get a little info, some juicy info, or a whole lot of nothing. In the past I have received all kinds of information from the error responses including:

· Hashed passwords

· Usernames

· Directory Structure

· Internal System Information (IPs, Hostnames, etc…)

· Developer comments / notes.

· SQL query information

Using the Error Message to Our Advantage

Let’s go back to the example shown earlier:

Here we can see several things. One, we can see that the system is most likely running on Windows, given the C:\ directory string. The directory string itself tells us the directory the application is running from. We also see we are dealing with PHP. One other major issue that stands out is that the dangerous method eval() is in play.

All of these items are extremely helpful in launching more specific, and focused, attacks. For example, if we are able to find an area where we can get an LFI (local file inclusion) we now have the directory info to make that attack much easier. In addition we also know that eval() is in use, which is a JavaScript function that can be abused to execute arbitrary code. With that alone we can start trying to test for some nasty injection attacks.

Another example might be like this stack trace below:

Here we can extract several things. One, we can determine that the web server is running Apache Tomcat/8.5.47. With that alone, we can start trying to see if there are any known exploits available for that version of Tomcat. We can also discern some of the classes involved in the running code, such as the Http1InputBuffer, and also identify through the stack trace that the language used is JAVA.

While this information doesn’t seem like much, we have enough to start doing some research on potential security issues revolving around the framework in use.

Conclusion

Sometimes the simplest things can lead to greater findings. As testers, we often try to focus on finding the higher risk issues while overlooking the smaller things that can help lead to something critical. Even though they may seem innocuous, error messages can pack a heavy punch if they reveal too much about the backend and leak information an attacker can use to get a better foothold.

About Stuart Rorer, Security Consultant

Stuart has worked in the IT Industry for more than twenty years and has worked within Cyber Security for the past twelve. In the past he has held jobs in the education, government, and private sector, and for the last few years has specialized in web application penetration testing. Stuart has performed testing on clients in all sectors, many of which have been in the Fortune 500. He enjoys spending time in research and exploring new penetration testing tactics, and techniques.

Certifications:

CPT, ECPPT, ECSA, CEH, SEC+