Authentication flaws and responsible disclosure​

When I worked for the local council it was part of my job to review software and systems that were going to be installed or implemented.  On one occasion that led me to review a door entry system that was being offered as part of a tender, and I found an issue with the software's authentication mechanism.  This flaw was reported to the vendor via responsible disclosure, and in this post I'm going to discuss that experience.

For those that prefer to listen, I gave a talk with the same title at codeHarbour in September 2023, which you can watch on YouTube here.  You can also view my slides here [1] (a short set of slides, as some of the talk time was occupied by giving a demo, which is just about visible on the YouTube recording).

I discovered this issue at least three years ago now, hence I'm happy to give talks about this issue and publish this blog post.  Plus, it wasn't a particularly difficult flaw to find and exploit so would be easily tried by others.

What's an authentication flaw?

In this case, authentication is the process of confirming that someone is who they say they are.  For example, then I login to my blog's administration console to write a blog post, the process of logging in checks my username and password pair against a database of users.  If I get both parts correct, the system authenticates me presuming me to be, indeed, Jonathan.

Authentication flaws are when the mechanism for authentication can be bypassed or subverted in some way to believe I'm who I claim to be when I'm not.  For example:

• A bypass - the attacker doesn't go through the authentication check (like walking through an open side door, rather than the front door where identity is checked)
• Forgetting to check - the system has a bug that doesn't check for user authentication
• Not confirming the identity is valid for this system - perhaps it's only valid elsewhere, but the attacker gains access to their target anyway

There will be other authentication flaws, these are only some examples.  On the second point, "forgetting to check", I actually had an instance of such a flaw in eVitabu.  For the part of the interface that created tags (a way to categorise content), I had completely forgotten to ensure the user was authenticated first.  I only discovered the issue when I wrote some automated tests and those tests successfully created tags when not logged in - that shouldn't have been possible!  I wrote a blog post about automated testing, and mentioned this issue there too.

Authentication vs Authorisation

We've discussed what authentication is, and it closely links to something called authorisation.  Indeed, when you authenticate to a system, there's often a step that confirms you are authorised to access your desired resource.  Authorisation is the process of making sure a person (or identity) is allowed to do what it's trying to do.  In the physical world, this would be a case of checking you're allowed in a particular place (e.g. in a private office), and in software this could be checking you're allowed to access system settings.

What is responsible disclosure?

Responsible disclosure is the process of contacting a software vendor, site owner, or the entity ("vendor" hereafter) responsible for vulnerable thing, and letting them know about the problem so they have time to fix the issue.  Importantly, the vulnerability does not get published publicly for some time - hopefully not until after the vulnerability is fixed.

The amount of time given to the vendor can vary, but 90 days isn't uncommon.  Ideally the security researcher would work with the vendor to fully explain the issue, and perhaps confirm the issue is resolved.

The scenario

I had to review some door control software that was being considered for installation.  The software allowed fobs to be configured [2] to open doors on a building, and allowed a valid user to be able to login and make changes.

I installed the control software, PROA MS Videx, in my lab and ran it.  When the application first opened I got prompted to create a "site", and the username and password was automatically populated:

I found it interesting the password was automatically populated with five stars - I wasn't asked to choose a password.  After proceeding to login I configured a few doors and looked at the list of operators (admins for the system) I can see one user: admin.  Having logged out and back in I worked out the default password was admin (the same as the username).  I changed the password for the admin operator.  The default password is always populated when you open the software.

Next I  looked at the software's Database directory and found two files - AccessLock.accdb and my site database (for the purposes of this blog post, my site was CodeHarbour, so the file was called CodeHarbour.accdb).

The flaw

The presence of two files in the Database directory intrigued me.  I knew my new password worked for the admin user, but the name of the second file, AccessLock.accdb, made me wonder if it was the authentication database.  Remembering that I'm in a lab environment, I deleted the AccessLock.accdb file and ran the software again.

As before, the login screen populated the default password for the admin user.  Looking in the Database directory the AccessLock.accdb file had been recreated, so clearly the software needed it.  I entered my password for the admin user and my login was denied - "wrong username or password".  Next I tried the default password of admin and I was let in to the software.

This meant I could gain access to the software anywhere it was installed by simply deleting the AccessLock.accdb file (or swapping it temporarily).  My suspicion was that the authentication for the system was not tied to the database being edited.

Reporting to the vendor

I contacted the company that was tendering to install this door control system, and they put me in touch with the developers.  After giving the developers all the information they needed to reproduce the issue I waited for a response.

The vendor's response

After about three days the developers emailed me:

Please find a link below to download the new version of PROA MS (4.0.0). This alters the database structure so that the site password is stored within the database for that site and not the separate AccessLock file. ​

It will no longer be possible to reset the password by deleting the AccessLock file, and this file can be deleted without any effect as it is no longer used by the software.​

Pleasingly for me the developers confirmed my suspicion, that the authentication was handled by the AccessLock.accdb file and not by the site file.  I installed the new version (4.0.0) of the software and found my password had been reset to the default.  I changed the password and deleted the AccessLock.accdb file.  As promised, the default password didn't work with my site file, so the problem was fixed.  It was also noted that the new software version did not recreate the AccessLock.accdb file.

Conclusion

All in all, this was a really good response from the developer of the software.  They quickly reviewed and understood the problem and took steps to rectify it.  By preference I'll always aim for responsible disclosure first, and would recommend that to you.

Banner image: Screenshot of the icons for the application and its databases.

[1] You may view this presentation for academic purposes, but may not use this slide deck to give your own presentation (i.e. you may not attempt to pass my work off as your own).  You may not use this slide deck or the research within for commercial purposes.

[2] As a side note, it was the fob that was configured with the details of the doors it would unlock.  In my experience, generally the door controller contains details of the fobs that will perform the unlock, not the fob.  For this particular system, if you wanted to stop a fob from working then you had to reprogram the fob.  This was by design, but I can see a number of issues with that!