mORMot Open Source

DonAlfredo

Member

Registered: 2023-10-31

Posts: 24

General safety warning.

Just a general warning.
Just a few minutes after deploying a simple mORMot2 relay-server on AWS (Amazon Web Services) behind an Apache proxy, I saw the below in the Apache logs.

91.168.172.13 - - [28/Sep/2025:06:45:01 +0000] "GET /root/TimeStamp HTTP/1.1" 301 257 "-" "Mozilla/5.0 (Windows; mORMot 1.18 TWinHTTP)"
91.168.172.13 - - [28/Sep/2025:06:45:01 +0000] "GET /root/TimeStamp HTTP/1.1" 200 12 "-" "Mozilla/5.0 (Windows; mORMot 1.18 TWinHTTP)"
91.168.172.13 - - [28/Sep/2025:06:45:01 +0000] "GET /root/Auth?UserName=User HTTP/1.1" 301 266 "-" "Mozilla/5.0 (Windows; mORMot 1.18 TWinHTTP)"
91.168.172.13 - - [28/Sep/2025:06:45:02 +0000] "GET /root/Auth?UserName=User HTTP/1.1" 200 77 "-" "Mozilla/5.0 (Windows; mORMot 1.18 TWinHTTP)"
91.168.172.13 - - [28/Sep/2025:06:45:02 +0000] "GET /root/Auth?UserName=User&Password=2f9814c4bef24ad962e182299c5cdfa3798785c6a62bb8ba3617dd3d05c03c50&ClientNonce=3ffd126ec71eede7f9b57a407528daa5ea5e69bb6eb53d782eef051d84058375 HTTP/1.1" 301 425 "-" "Mozilla/5.0 (Windows; mORMot 1.18 TWinHTTP)"
91.168.172.13 - - [28/Sep/2025:06:45:02 +0000] "GET /root/Auth?UserName=User&Password=2f9814c4bef24ad962e182299c5cdfa3798785c6a62bb8ba3617dd3d05c03c50&ClientNonce=3ffd126ec71eede7f9b57a407528daa5ea5e69bb6eb53d782eef051d84058375 HTTP/1.1" 200 219 "-" "Mozilla/5.0 (Windows; mORMot 1.18 TWinHTTP)"
3.249.207.130 - - [28/Sep/2025:06:45:02 +0000] "POST /root/Up?session_signature=67c5133bec86170e6b1888f3 HTTP/1.1" 201 - "-" "Mozilla/5.0 (Windows; mORMot 1.18 TWinHTTP)"
91.168.172.13 - - [28/Sep/2025:06:45:02 +0000] "POST /root/Up?session_signature=67c5133bec86170e6b1888f3 HTTP/1.1" 201 - "-" "Mozilla/5.0 (Windows; mORMot 1.18 TWinHTTP)"

This means that outsiders know the basic signature and setup of a mORMot http server.
Naturally, this is no cause of alarm when authentication or JWT is used.

But the logs suggests to do always 2 simple things:
1: change the servername to something not referencing our beloved mORMot.
2: change the Model root ('root') to something of your own choice.
These two simple changes will lower the changes of attackers being able to indentify the server and use (un)known vulnerabilities.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 15,226

Website

Re: General safety warning.

The signature is tied to the URI itself, and with the TCP connection itself if you enable the rsoPerConnectionNonce option (mORMot 2 only). So can't be replayed on another link.
But need a specific configuration behind a proxy - see https://synopse.info/forum/viewtopic.ph … 443#p44443

Note that there is a timestamp in the session signature, and that it is tied to the user session: once log out, everything is OK.

This is a mormot 1.18 log. On mORMot 2 there is no such "mORMot 1.18" in the logs.

Note that the session_signature applies to the URI: for instance, in your case it would apply only to '/root/Up'. To validate '/root/Two' you would need another session_signature value.

Your two obfuscation tips won't be enough if the logs are leaked.
A) use HTTPS always over the Internet
B) keep the logs private, or change the format string to not log the query: use %U instead of %r
C) of course, e.g. between sensitive services, I would switch to WebSockets, which offers callbacks for dual way notifications, and hide all this stuff.

I have created an issue to track this point:
https://github.com/synopse/mORMot2/issues/393
and another to make JWT use easier:
https://github.com/synopse/mORMot2/issues/394

We could discuss here.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 15,226

Website

Re: General safety warning.

In fact, I guess this could be enough:
https://github.com/synopse/mORMot2/comm … 1b80fb1e2d

Just enable the new rsoAuthenticationBearerHeader option at TRestServer level, and now clients should have proper hidden authentication as an "Authorization: Bearer #####" HTTP header in addition to the session_signature=xxx parameter.
So this session_signature=xxx parameter would not be enough to access the server.

Note that it requires the latest version of the client class to work as expected: TRestClientAuthentication has been modified.
And of course, it is for mORMot 2 only.