Iris / JSON Variable Issues?

[SysAdminSmith]

Have you read the documentation?

• [x] Yes, but it does not include related information regarding my question.
• [ ] Yes, but the steps described in the documentation do not work on my machine.
• [x] Yes, but I am having difficulty understanding it and want clarification.

You are setting up gotify in

• [ ] Docker
• [x] Linux native platform
• [ ] Windows native platform

Describe your problem Greetings, I am attempting to utilize DFIR Iris' webhook module to POST messages to my gotify server upon the occurrence of a certain type of event. This action is supported within Iris. Here is my webhook configuration within Iris (documentation):

{
    "instance_url": "https://foo.bar.local",
    "webhooks": [
        {
            "name": "Gotify",
            "active": true,
            "trigger_on": ["on_postload_alert_create"],
            "request_url": "https://gotify.foo.work/message?token=R4ND0MNUMB3R$",
            "use_rendering": false,
            "request_rendering": "none",
            "request_body": {
                "alert_title": "[ALERT] ${alerts.alert_title}",
                "alert_description": "${alerts.alert_description}"
            }
        }
    ]
}

When an alert comes in to Iris, it should send a POST to the gotify server. Unfortunately, it never gets there.

I attempted to do a quick test and, from the Iris server commandline, executed the following:

curl "https://gotify.foo.work/message?token=R4ND0MNUMB3R$" -F "title=[ALERT] ${{alerts.alert_title}}" -F "message=${{alerts.alert_description}}" -F "priority=7"

This produced this error: -bash: title=[ALERT] ${{alerts.alert_title}}: bad substitution

If, I removed the variables, the alert is received just fine.

So it seems the issue is the format of my request from the Iris Server. Is there a way to utilize variables such as are referenced above, to a gotify server and have it delivered?

Thank you!

[eternal-flame-AD]

Looks like the variable substitution format is not right? From the document it seems to be in the format of %VARIABLE%?

And probably request body should be named "title" and "message" for gotify to recognize it as a message

[SysAdminSmith]

Thank you for the suggestion. I tried both of the following formats, neither working:

{
    "instance_url": "https://foo.bar.local",
    "webhooks": [
        {
            "name": "Gotify",
            "active": true,
            "trigger_on": ["on_postload_alert_create"],
            "request_url": "https://gotify.foo.work/message?token=R4ND0MNUMB3R$",
            "use_rendering": true,
            "request_rendering": "markup",
            "request_body": {
                "title": "[ALERT] %TITLE%",
                "message": "%DESCRIPTION%",
                "priority": "7"
            }
        },
        {
            "name": "Gotify_v2",
            "active": true,
            "trigger_on": ["on_postload_alert_all"],
            "request_url": "'https://gotify.foo.work/message?token=R4ND0MNUMB3R$' -F 'title=[ALERT] %TITLE%' -F 'message=%DESCRIPTION%' -F 'priority=7'",
            "use_rendering": false,
            "request_rendering": "none",
                "request_body": {
                "title": "[ALERT] %TITLE%",
                "message": "%DESCRIPTION%",
                "priority": "7"
            }

        }
    ]
}

That being said, the following did work from the command line (of course the variables did not 'work' but thats okay for this POC): curl 'https://gotify.foo.work/message?token=R4ND0MNUMB3R$' -F 'title=[ALERT] %TITLE%' -F 'message=%DESCRIPTION%' -F 'priority=7'

So I am guessing it may be HOW Iris is sending the command? If so, does Gotify have a log I can tail to see where the issue may reside? Is there a specific format/protocol I need to know when sending the request to Gotify?

Thank you!

[eternal-flame-AD]

Webhook integrations are hard to debug without seeing what is being sent. Can you point a socat to your Iris system and see what is the actual payload being sent?

sudo cloudflared tunnel --url http://localhost:6060 (Or use any equivalent tunnel or just LAN if you are able to reach it)

socat tcp4-listen:6060 STDOUT trigger the webhook to the tunnel and see what is the payload

[SysAdminSmith]

Unfortunately I can't get Iris to produce any output at this point. I think I will need to attack this from the Iris standpoint. I'll be back.