URL Manipulation

As my second post on this blog, I’ve chosen something a bit more interesting from my previous tests. This is about a URL manipulation vulnerability, where the attacker can change the content that is accessed or called by the application to some other function or content that he wishes.

The root cause of this vulnerability is often the lack of validation of user input, in other words, the application trusts anything that is sent by executing any commands issued to it. I’m planning to talk a little bit more about this topic in a future post, aiming for SDLC (Software Development Life Cycle) processes and best practices in application development.

About the application, it is a widely used cloud application with headquarters based in Brazil and in the US. I’m not disclosing the name or any other information of it just yet because I do think that the vulnerability is not fixed in all their clients websites.

So, here’s the deal…

The image above represents the application’s printing functionality, you can basically click on the printing icon and this window shows up. In every pen-test that I perform, I normally go through the entire application with a web debugger software to catch all the requests that are made to the server for later analysis. By doing this I was able to catch the request that was sent to the web server, whenever I clicked the print to .doc or .pdf function and this is what I got…

As you can see above, the big red rectangle is marking a bad development practice, the application is calling for a file in the web server, showing it’s full directory path and ultimately disclosing the server directory structure. This caught my attention of course and I started fuzzing the path looking for some interesting response until the vulnerability showed it’s full potential.

By modifying the path to a file that I knew existed (because it exists in most of Windows platforms), I was able to download anything from the web server, like system files for example. As shown in the figure above, the function that the application calls is the following:

• 192.168.200.160/desenvolvimento/.net/index.ashx/GetFileDownload?reportFile=

The path that feeds the “reportFile=” function is encoded, nothing to worry since you just need to google something like “URI encoder” and just drop the path to the file you want, something like this:

• C:\Windows\System32\mmc.exe

Becomes:

• C%3A%5CWindows%5CSystem32%5Cmmc.exe

For the evidence below I used the “hosts” file, located in “C:\Windows\System32\drivers\etc\hosts”

And there it is, we can now download anything from the web server, you just have to know where to find it or by simply brute forcing the possible paths. The awful part is that there are a bunch of published web sites with this vulnerability, take a look:

I’ve found this doing an assessment to one of our clients and we contacted the vendor who fixed the problem on the specific web server. By the time I made this post, the vulnerability still persists in other websites and I’m thinking of opening a CVE for this, since the vendor didn’t fix it in their other clients.

The possibilities here are endless and I just downloaded the hosts file to prove my concept since my time is really limited when I’m doing this kind of work.

Feel free to comment and criticize my post!