by Stuart Rorer, Security Consultant

Uncovering Technical Artifacts

One of my favorite childhood memories was going with my sister to look for artifacts after a solid rain. We lived near several areas that had been known for their past history and had seen their share of war skirmishes from the Civil War, and earlier. I recall finding several artifacts over a period of time, which included musket balls, broken pottery, arrowheads, and other interesting items. Every find came with this great feeling of connecting to someone in the past. For example, how did the musket ball find its way here? Was it dropped? What about the pottery, how did it get left behind? I always wondered who these items belonged to before they were found.

When performing a penetration test, there are times I feel like I’m searching for artifacts again. Every host has a story of its own, and these artifacts uncover that story bit by bit. Unfortunately, leaving certain items behind can also lead to trouble, especially if they are left open without protection.

How to Find Them

When I’m performing a web penetration test, I always like to get a feel for the app and the framework behind it. Developers are always adding, modifying, removing code and often things like configuration files, and pieces of past frameworks are left behind. I always get a little bit of a thrill when I find a system that is working together with legacy code, because I know it will make a great target.

I can recall one time in particular where the newer part of an application was well protected against input injection attacks. However, with some further digging, I was able to find some long lost legacy pages that led me to a complete compromise of the application.

Of course finding these things aren’t always easy. For web, your best bet is to do heavy reconnaissance with directory and file enumerators such as using Burp’s Discover feature, or tools like GoBuster.

Make sure to look through the source code of pages you are viewing, or again using a tool like Burp’s comment feature to see if you can find URL areas that have been commented out. Sometimes developers have commented out areas of the web application that are in development, or have been phased out. Make sure to especially look for debug related comments, these can help the tester to see known issues with the application.

Burp’s search feature is also handy to look for older frameworks such as looking for old school .asp files.

When coming across specific frameworks, take the time to research, download, install, and configure them. Knowing where the configuration files are stored might lead you to finding the configuration files on the target server. Web servers often change over periods of years, it’s amazing to find old frameworks still sitting on the web server. Finding these are like uncovering a bit of history of what was.

Don’t forget to check for files with common extensions such as .back, .bak, .config, .conf, .old. Sometimes you will find a well-meaning, but lazy developer, who has stored an old config in the folder. Finding these files may uncover sensitive information like passwords.

If all else fails, don’t forget to use the Internet Wayback Machine at https://web.archive.org/. Searching the archives can often lead to finding some of those old frameworks in play. Below is an example of the Netscape website from 1996. Sorry, I was feeling nostalgic.

Conclusion

Finding files like the above is like finding relics from the past. They tell us the story of the web server’s history, with past frameworks and old configuration files. These files may be long forgotten, but sometimes they can be used to gain a greater foothold on the application, or to use as leverage to launch a more dangerous attack. Making sure that old files and frameworks are removed from the server is practicing good security hygiene. Sometimes what’s left in the past is best forgotten, just make sure it’s also deleted.

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+