vulnerability Rejetto HTTP File Server Remote Code Execution CVE-2014-6287

[leon]

Anyone aware of this problem and is there a way to mitigate this ?
according to Checkpoint advisory cpai-2019-0748  and mitre.org CVE ID CVE-2014-6287

Seems an old bug that emerged again. (?)

[skb]

Not sure if Danny's suggestion would solve the particular bug reported here, but does seem like a good way to limit the "noise" of random get requests that are fishing for vulnerabilities. E.g. my logs always have lots of crap like :

Code: [Select]

6/17/2019 2:21:39 AM 122.114.191.125 50639 Requested GET /help.php
6/17/2019 2:21:39 AM 122.114.191.125 50833 Requested GET /java.php
6/17/2019 2:21:43 AM 122.114.191.125 51098 Requested GET /_query.php
6/17/2019 2:21:43 AM 122.114.191.125 51361 Requested GET /test.php
6/17/2019 2:21:47 AM 122.114.191.125 51705 Requested GET /db_pma.php
6/17/2019 2:21:47 AM 122.114.191.125 51907 Requested GET /logon.php
6/17/2019 2:21:55 AM 122.114.191.125 52953 Requested GET /x.php
6/17/2019 2:21:59 AM 122.114.191.125 53179 Requested GET /htdocs.php
6/17/2019 2:22:27 AM 122.114.191.125 58081 Requested GET /desktop.ini.php
6/17/2019 2:22:31 AM 122.114.191.125 58606 Requested GET /lala.php
6/17/2019 2:22:35 AM 122.114.191.125 59500 Requested GET /t6nv.php
6/17/2019 2:22:36 AM 122.114.191.125 59661 Requested GET /muhstik.php
and etc.

[skb]

Wait, is this actually a new report of this issue, or merely an old bug report being duplicated and resurfaced by a different "Security Provider", so, a false alarm? 

The CheckPoint page at https://www.checkpoint.com/defense/advisories/public/2019/cpai-2019-0748.html references the 2014 CVE report, which says it was patched in version 2.3c :  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6287

I'm still going to try out Danny's filter. But, just because we disconnect them, I think they can still just try again. Not sure if it is more load for the server to send them a 404, or to process an event and disconnect.

[skb]

FWIW, using Danny's script to disconnecting on *.js requests seemed to break some of the buttons and controls on my template, but maybe it is just my quirky niche template.

I've added Danny's event with "*.js;" removed, but keepingthe other types, and will see if it cuts down on log entries like the ones I posted above. However, seems possible that those logs are generated by scripts that will just keep going through their lists of items to try, despite the disconnects.

[skb]

Thanks, Danny. I'm pretty sure the warning in this thread is just referring back to the issue patched in 2.3c. (Or, if it _is_ a real threat, there's no documentation of it provided. What do we need to do to test that we are still protected against this 2014 exploit? )

I'm fairly confident that if you add *.exe types to my filter, in addition to the js py and vbs, that a remote request just can't run those on the server

Ah, so that explains the problem I had with *.js, as parts of my template use Javascript. I will add *.exe as well, because I only use HFS to serve small (< 50KB) .csv input data files to some android devices, and then to accept the results (also *.csv) back from them.

[bmartino1]

yes Mars, i'm on the road a tad to much these days for construction in the states.
most of my time and comments are from a phone.

My apologies. Any ways here is what Im trying to say:

Anyone aware of this problem and is there a way to mitigate this ?
according to Checkpoint advisory cpai-2019-0748  and mitre.org CVE ID CVE-2014-6287

Seems an old bug that emerged again. (?)

So, I follow the "cve" and pay close attention to the cve reports and the comments and there responses here...
Most CVE reports regarding HFS as they are filed respond to older version regarding hfs 2.3b that had a bad template and base code in witch you could use machine code such as the null byte to do some command execution to the pc remotely...  This is one of those reports and as it has been fixed,patched and the stable is not affected by that report, i see no problem. I'm aware of a Security con that a Professor using HFS in a virtual machine to show how web browsing security works and he uses the hfs 2.3b version in his class and study for ethical hacking...

those are some of his reports which is why it looks like a false postie duplication, because the same info is added into the 2014 version of the cve in witch with rejeto responded too and patched/fixed.

the orginal CVE remote execution bug was a problem that from my understanding lied on the default hfs template, in witch a user can still (???potentialy use a bad template) and be affected. the stable default template (Some good users template such as DJ and Danny works) are all stable and don't exhibit bugs in this way.

It may be possible in the current version of hfs with that bad template that one might be able or can get similar remote execution.
I have not been able to replicate that issue since the patch version 2.3 h i believe...

Since then this CVE report is from a new Av pick up on the macro and its find in the the ".execute" macro command...

I was trying to find the original source and there test because it claims that there is still a issue in the pascal lib file that stable version of hfs uses...

*but from what i can find there is no remote execution issue with the latest default template and a fresh download of the current hfs version 2.3 m

The CVE reported a version "2.3 x" in the orginal report so the beta might be being tested as a stable... atm idk as im doing more research on it

----------------------------------------------

For all CVE repotr both new and old see here:

https://www.cvedetails.com/vulnerability-list/vendor_id-14180/Rejetto.html

to be clear the CVE that you are inquiring on is in regards to 2.3 b a bad version of hfs that does exhibit the remote execution code and atm as far as i can tell is only available via source compilation.

Qute from the CVE
"2.3x before 2.3c allows remote attackers to execute arbitrary programs via a %00 sequence in a search action."

to be clear This doesn't affect hfs version 2.3 m, and i believe it was a late post reply in regard to the old CVE report

----------------
@ to whom it may concern

you could adjust mime types to disallow the execution of file such as *.exe and what not via adding a mimetype and using "text/html"

or subtype for scripts to run: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types

[Mars]

Hello man

you have certainly had to write your message from an android tablet because a good part of the words remains incomprehensible
if you could take over the correction of the text so that it is more coherent,

thank you in advance
Mars.