FMS, bypass authorisation
Bypass authorization of FileMaker Server or “there is no such category”
Introduction
In the summer of 2023, I decided to investigate the internal communication protocol between FileMaker clients and the server. This led to the discovery of perhaps the most significant vulnerability in the platform’s history.
I discovered that it is possible to connect to any database hosted on any FileMaker Server with full administrator privileges without any authorization!
You don’t need to know the name of the database, or the user login or password. All you need is the IP address (or hostname) of the FileMaker Server.
Only knowing the IP, you can get full access with editing and deleting data to all databases, to all tables, to all records, to scripts, access settings, etc.
Enabling database encryption at rest did not help. Enabling two-factor authorization did not help either.
And the worst thing was that FileMaker Server logs did not record any unauthorized connection.
That is, full, unrestricted access and no traces of its use!
Bypass authorization demo
Before we get into the technical details, let’s take a brief peek at what it looks like:
That was hard to believe.
At one point in time, I felt like I owned the FileMaker platform. I could theoretically have complete control over any Claris database in the world. And that applied to Claris FileMaker Cloud as well.
Was this problem related to a particular version of FileMaker Server? Apparently not. The oldest version I’ve tested was v.14. So it seems that the platform has always had this problem. At least since the transition to Draco (around 2004).
Now in more detail, what is the problem ?
CORBA protocol
The main communication protocol between FileMaker client and server is the CORBA protocol:
FileMaker uses omniORB - implementation of this protocol:
You can find detailed documentation here:
Prior to version 12, communication between client and server (or between clients in the case of FileMaker Pro-level sharing) was in the clear, without encryption. Since v.12, FileMaker has added first the possibility and then the necessity of encryption, using an SSL certificate.
This made communication between client and server much more secure. Now it is almost impossible to intercept traffic and decrypt the contents of exchange packets.
But the CORBA protocol hasn’t gone anywhere. Let’s take a look at what the connection and authorization process looks like at a low level.
In unencrypted form, each request and response packet starts with the text phrase GIOP (in hex: 47 49 4F 50)
Connection phases
The connection and authorization process consists of 3 phases.
- Initial Connect
- Request DataBase
- Connect to DataBase
In the initial phase, the client sends to the server, among other things: the client’s license key, the client version, and the mac addresses of all network interfaces available on the client. In response, the server sends 4 bytes of Sequence ID, which are used later to identify the session.
In the second phase, the client sends a request - Sequence ID (from the first phase) and the name of the database to which we want to connect. In response, the server sends the database ID (DataBase Index) if the database with this name exists. Or DataBase Index=0 if there is no such database.
It should be noted that DataBase Index usually starts from 1 and goes in ascending order, i.e. 1,2,3,4, etc. A bit more below and you will understand why this is important.
In the third phase, the client sends Sequence ID (from the first phase), DataBase Index (from the second phase) and a hash of login and password. In case of successful authorization, the server sends the UserID of the found user. Interestingly, the UserID is also a number, usually starting with 1 and going upwards, 1,2,3…255
Also during my research, I discovered that after phase 1, you can send various commands to the FileMaker Server and it will happily respond, regardless of the fact that authorization has not yet occurred. I found a command where by substituting a sequential DataBase Index, FileMaker Server would return a list of the internal tables of a given database. So by changing the index from 1 to 255 you could find a list of all the databases located on the server.
Approximately the same story happens with the user ID. The server was actively responding to internal commands, returning the user name and privilege level simply because of the requested index. By running a short script, in less than one minute it was possible to get indexes of all databases located on the server, as well as all users of the found databases and their access level.
So, knowing how authorization happens, I decided to create a simple proxy server that would modify the responses from the server.
So, for example, during the second phase, I sent a random database name. In response, the server would send an error saying the database was not found and return a null DataBase Index. But I spoofed the server response, returning an existing database index.
The FileMaker client, proceeds to phase 3 and requests access to the specified database. The server of course responds with an error, since we don’t know the login and password. But it turned out that by substituting the server’s response during phase 3 with a successful one and returning the existing user ID, the FileMaker client proceeded through the subsequent connection phases as if the authorization had been successful!
The most interesting thing is that FileMaker Server did not suspect any trick, and despite the errors in phases 2 and 3, went to the standard operation as if the authorization had taken place.
And since, in fact, no real authorization took place, FileMaker Server did not register this connection in the logs, while providing full access to the databases!
Situation Analysis
FileMaker’s internal protocol of exchange between client and server was developed many years ago, when security issues were not so acute.
It can be seen that the company tries to strengthen the protection of its products, almost every new version improves the protection mechanisms of the transport protocol, removes support for obsolete cipher suites (traffic encryption algorithms), and updates the omniORB library. But the internal protocol based on CORBA is not updated in any way.
Connection through an intermediate proxy server allows easy modification of outgoing and incoming commands by manipulating the logic of client-server interaction.
That is, it is almost impossible to intercept someone else’s traffic, this part is well protected. But a bad actor can initiate his own connection to the server by easily manipulating the internal communication protocol.
It should be noted that the method of bypassing authorization that I found is not something super complicated. Spoofing the response from the server is on the surface. We don’t know how many years, or even decades, this could have been used by attackers, or how much sensitive information could have been compromised.
Problem solved
After discovering this vulnerability, I reported it to Apple and detailed the issue via the Apple Security Bounty program.
The vulnerability has been patched, Claris has issued a short notice:
Claris International has resolved an issue of potentially allowing unauthorized access to records stored in databases hosted on FileMaker Server. This issue has been fixed in FileMaker Server 20.3.2 and FileMaker Server 19.6.4 by validating transactions before replying to client requests. Claris strongly recommends that customers upgrade to the latest versions of FileMaker Server and FileMaker Pro. This issue was assigned to CVE-2024-27790. We would like to thank Alexey Dubov for reporting it to us.
Rewards or “there is no such category”
Claris is getting closer to its parent company, calling itself “Claris, an Apple company.”
The company has also joined the Apple Security Bounty program
“If you submit research for a security or privacy vulnerability, your report may be eligible for a reward. The Apple Security Bounty program is designed to recognize your work in helping us protect the security and privacy of our users.”
This program offers some pretty hefty rewards for finding vulnerabilities and helping to improve the security of their products.
Here are some examples of possible rewards: Bounty Categories
Note the highlighted category. If I had found the vulnerability described in this article, I would have expected to be rewarded according to this category.
But the reward for the FileMaker Server vulnerability I found was ….. 0$ 🤷♂️
The response said “…unfortunately, it does not qualify for bounty. This is because the issue does not demonstrate the categories listed on the Categories page”
Apparently Claris has joined Apple’s program, but the vulnerability categories have not been updated to reflect Claris products. Or the team involved in the program doesn’t quite understand what Claris products are.
So before participating in the Apple Security Bounty program on Claris products, you should consider that the effort and time spent will likely go unrewarded.
It should be noted that after opening a report on the FileMaker Server issue more than a month later, I also found that the FileMaker Cloud product has a similar vulnerability. If you didn’t know, this is a cloud service very similar to FileMaker Server, but from Claris itself. I opened a separate report and it is interesting that the company responded more actively to the vulnerability with FileMaker Cloud and even paid a reward. However, it was the lowest possible reward.
Apparently, this product is more important for Claris, because the responsibility for the safety of customer data is higher.
There is also another vulnerability related to privilege escalation that I also found. And it affected both versions, FileMaker Server and FileMaker Cloud. But that’s material for a separate article on this site.
We will keep an eye on the development of this program and if the situation improves, we will be happy to report it.
Timeline
| Date | Action |
|---|---|
| 16th September 2023 | I Reported |
| 26th October 2023 | I added, that FileMaker Cloud platform aslo has similar issue |
| Sometime in between | Bounty status changed to: Ineligible. Your report has been reviewed for the Apple Security Bounty and, unfortunately, it does not qualify for bounty. This is because the issue does not demonstrate the categories listed on the Categories page. |
| 1st December 2023 | Apple was not able to reproduce the issue and asked for video demonstration |
| 5st December 2023 | I sent a video demonstration and address of my own FMS server to test this issue on. |
| 28th March 2024 | Apple assigned it CVE-2024-27790 |
| April 2024 | Apple marked this issue as resolved. |