At the time of this writing, its be been over few months which gave the company involved time to fix the issue, which they did. I will not use real names of the parties involved in this post.

I happened to be shopping around for the best institutions to finance a mortgage. After consulting with several independent companies, I contacted one of my banks which is a federal credit union. When I reached out to their loan officer, she directed me to their website which had a link to their online portal, where I could apply for pre-approval. On this portal, I would fill in my whole financial life and family situation, and upload documents to support the same. This information included social security number, phone number, address, employers, etc.

As a good security practice, I use password managers to generate strong passwords and save them since I rarely re-use my passwords. I was using Roboform at that time. Roboform has a feature that alerts you when the URL you are trying to fill a password does not match that one you saved. The bank had done a great job integrating the mortgage vendor’s portal with an iframe to their banking site, you could not have easily notice the difference. Roboform alerted me of a mismatch and so, typical of me, I hit ctrl+shift+i to open developer tools and investigate further the site’s HTML code.

Long story short, I found the iFrame and navigated to the vendor’s portal, messed around with the URL patterns and discovered exposed directory listing. Inside the root directory was .txt configuration files that included their internal testing credentials and links to other servers. I tried one of them and was able to login successfully. By looking at how they had implemented the code, I was able to manipulate the portal by injecting code in their JavaScript using developer tools and masquerade as another user.

At this point, I had seen enough and it was time to get hold of their IT department. Luckily, the same configuration files provided me with information to the corporate website where I sent them an urgent note. I also contacted the bank to alert them of the issue. Both responded the following day. The vendor’s corporate IT team reached out and I sent them a detailed description of the bug with screenshots and how to replicate it. Within hours, they patched the system and sent me an Amazon gift card! While it was a nice gesture of appreciation, I would still have helped them further if needed.

I am not aware of which other clients this company served, how long the portal had been exposed, and if someone else had gain similar access before.

Take away:

• Disable directory listing in your server unless you have a specific need to and understand the potential risks
• Do not keep configuration files in a web accessible directory. For example, if using PHP the language interpreter crashes, your PHP files will be served as plain text and all the information is exposed.
• Protect direct querying of .evn and other config files. If using Apache server, use .htaccess to deny access
• Separate server-side logic from the front-end and do not expose how your protected server code functions with front-end code.
• Review your application from a hacker’s perspective to ensure that there are no obvious loopholes

For example, this is is a bad implementation in front-end JavaScript.

var user = authenticateUser();

if(user.isAuth == true && user.email =='[email protected]'){
  loadAdminDashboard(user);
}elseif(user.isAuth == true){
  loadUserDashboard(user);
}else{
  loadLoginPage();
}

Using developer tools console, a anyone can instantiate a user object and also assign user.isAuth == true and user.email=’[email protected]’ thus gaining access to admin dashboard.

Thanks for reading and stay secure online!