1
Everything else / Re: Best DynDNS alternative: FreeDNS.afraid.org
« Last post by rejetto on October 30, 2024, 01:13:45 PM »some modems have ddns updater feature. That may be the best option
Recent Posts
2
Everything else / Re: Best DynDNS alternative: FreeDNS.afraid.org
« Last post by LeoNeeson on October 19, 2024, 09:46:55 PM »I wonder, can HFS update it automatically?Yes, it's easy, but read a very important note at the end...
1. Login to your FreeDNS.Afraid.org account and go to "Dynamic DNS".
2. Copy the link from "Direct URL" for the domain you want to update.
3. From that link, change "https://" to "http://" (removing the 's'),
since HFS can't handle SSL connections (unless you are using v2.4 RC7).
Link example:
Code: [Select]
http://freedns.afraid.org/dynamic/update.php?xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx4. In HFS, press F5 (if you are not already in 'Expert mode'), and go to...
'Menu' > 'Dynamic DNS updater' > 'Custom...' and paste there the link.
5. It's all ready. Enjoy!
NOTE: My recommendation for FreeDNS.Afraid.org remains, but I currently do not recommend to use HFS to do the 'DNS update' (as a 'Dynamic DNS client'). It can be used along HFS, but it's better not within it. This is because, no matter what DynDNS service you do use, I've noticed that HFS it's not very reliable for this task (I've found a small bug when using the 'Custom' option, and although it seems to work, I can't guarantee it will always function). What kind of bug? HFS is -always- updating the DNS even if is not necessary, without checking first if the IP of the hostname has changed or not, and this leads to this "ERROR: Address 123.xxx.xxx.xxx has not changed." For casual use, it could work fine, but for use on as a permanent server, it's much better to use another DDNS client to update the IP.
3
Everything else / Re: Best DynDNS alternative: FreeDNS.afraid.org
« Last post by TekWiz on October 17, 2024, 08:14:37 PM »Thank you, I agree, I've been using afraid for many, many years now. It's a shame it's not more widely supported. Doing the auto updates in windows can be a bit tricky as a simple updater hasn't been updated for years... But can be done with a scheduled script easily. I wonder, can HFS update it automatically?
4
HFS ~ HTTP File Server / Re: Warning: HFS v2.x has a severe vulnerability
« Last post by rejetto on October 17, 2024, 12:02:23 PM »I think Mars' idea of restricting "exec" is good.
It's a pity I didn't have it at the time
I don't like the idea of having a specific folder, tho. I would rather have a way to configure what commands are allowed, so that the user must manually enable them.
It's a pity I didn't have it at the time
I don't like the idea of having a specific folder, tho. I would rather have a way to configure what commands are allowed, so that the user must manually enable them.
5
HFS ~ HTTP File Server / Re: Warning: HFS v2.x has a severe vulnerability
« Last post by sergio on October 09, 2024, 05:46:19 PM »Thank you very much for the clarification. I hope it can be resolved soon.
6
HFS ~ HTTP File Server / Re: Warning: HFS v2.x has a severe vulnerability
« Last post by LeoNeeson on October 09, 2024, 04:12:26 AM »But if hfs is under cloudflare, does the vulnerability continue?Yes, the vulnerability continues, and it could put at risk the PC (server) where HFS2 (v2.x) runs. Running it under Cloudflare somewhat makes the server more hidden (harder to be scanned by hackers), but once it's discovered and targeted by a hacker, he could run or install any program (malware or anything). Unless you run HFS2 on a VPS (or somewhere you don't have anything valuable), and you can recover your data in case of problems, you should think on updating to HFS3 (or take the risk and wait until we release an unofficial version of HFS2 with this vulnerability fixed). We are closer to find a solution to this, but the decision of waiting or updating is yours. Keep in mind that HFS3 is a completely different software (written from scratch) and its configuration is not compatible with HFS2, so you should have to configure everything again, but HFS3 is the currently recommended choice. If you have any questions about HFS3, please ask on the place dedicated to it (here), to avoid this thread going off-topic.
7
HFS ~ HTTP File Server / Re: Warning: HFS v2.x has a severe vulnerability
« Last post by sergio on October 08, 2024, 01:51:27 PM »Hi.
I don't know anything about security, nor about the C language.
But if hfs is under cloudflare, does the vulnerability continue?
I don't know anything about security, nor about the C language.
But if hfs is under cloudflare, does the vulnerability continue?
8
HFS ~ HTTP File Server / Re: Warning: HFS v2.x has a severe vulnerability
« Last post by Mars on October 06, 2024, 06:10:59 PM »Hello to both of you, even if I am not involved in HFS3 which for me represents a completely different project from HFS2.x, I keep an eye on the possible changes to be made to the latter.
With some similar approaches I did not arrive at a satisfactory result, there are indeed not only the urlvars to control but also the recursion of the attack used by using %url%, it is also necessary to take into account the postvars and as said rejecto the attacks by headers
I looked into a more restrictive use of the EXE macro, by limiting the programs to launch to those contained exclusively in a subdirectory of HFS, but I do not manage the %url% in the state in loop
put the file calc.exe (to test) inside a new exec\ subdir and use macro {.exec|calc.exe.} , bad syntax without extension {.exec|calc.} is stopped
This is a safe and absolute start for those who do not leave an executable in the exec\ directory.
What a hacker doesn't know about available resources is an obstacle to hacking.
With some similar approaches I did not arrive at a satisfactory result, there are indeed not only the urlvars to control but also the recursion of the attack used by using %url%, it is also necessary to take into account the postvars and as said rejecto the attacks by headers
I looked into a more restrictive use of the EXE macro, by limiting the programs to launch to those contained exclusively in a subdirectory of HFS, but I do not manage the %url% in the state in loop
Quote
procedure exec_();
var
s: string;
code: cardinal;
begin
if not fileExists(exepath+'exec\'+extractFileName(macroDequote(p))) then
begin
pars.clear();
result:='';
mainfrm.add2log('DISCONNECTED'+CRLF+exepath+'exec\'+extractFileName(macroDequote(p)));
disconnect();
exit;
end;
s:=macroDequote(par(1));
if fileOrDirExists(s) then
s:=quoteIfAnyChar(' ', s)
else
if unnamedPars < 2 then
s:='';
if parExist(['out']) or parExist(['timeout']) or parExist(['exit code']) then
try
spaceIf(captureExec(macroDequote(p)+nonEmptyConcat(' ', s), s, code, parF('timeout',2)));
try setVar(parEx('exit code'), intToStr(code)) except end;
setVar(parEx('out'), s);
except end
else
spaceIf(exec(macroDequote(p), s))
end; // exec_
put the file calc.exe (to test) inside a new exec\ subdir and use macro {.exec|calc.exe.} , bad syntax without extension {.exec|calc.} is stopped
This is a safe and absolute start for those who do not leave an executable in the exec\ directory.
What a hacker doesn't know about available resources is an obstacle to hacking.
9
HFS ~ HTTP File Server / Re: Warning: HFS v2.x has a severe vulnerability
« Last post by LeoNeeson on October 06, 2024, 06:46:05 AM »that's great, congratulations with your achievement, Leo!Thanks, it means a lot that you like it, I appreciate it.
To me, it's like an exercise to dip my toes on Delphi, although there is still a long way to go...you prefer 2.3 over 2.4 ?Not really, some parts of it only (2.4 has huge improvements), but mainly I'm using 2.3 in my tests because it is much easier for me to build it (using TD2006). And since it was the latest stable version published, it was the version I've used it as example.
Is the url the only way to use the vulnerability? Even if the POC of the CVE uses the url, be sure to consider the possibility of the attack coming from a header.Yes, I know what you mean ('Host' header is not covered, for example), that's why I'm not completely happy with my 'single line' fix (although it works). That's why I'm testing a completely new fix (instead the previous code). See...
ยป Alternative method to stop this macro vulnerability:
Add the line marked in green, after line 5084 in 'main.pas' (v2.3m)
Quote
runEventScript('pre-filter-request');
// Check macro leaks, prevent hack attempts
if anyMacroMarkerIn(conn.request.full) then
begin
data.disconnectReason:='Hack attempt blocked. This event has been logged!';
add2log('Hack attempt blocked: '+ansiToUTF8(conn.request.url));
getPage('deny', data);
conn.reply.mode:=HRM_BAD_REQUEST;
exit;
end;
It works, but even then, it's just a simple check and stop, not a true 'urlvar' filtering (and I can't be 100% sure if it is enough or if some hacker could think a workaround to bypass this measure). And if the browser asks for the 'favicon.ico' along with the same request, it gets logged as hack attempt too (and I don't like this, and I have to think how to handle it, perhaps with 'urlCmd'). Alternatively, I was thinking of doing a 'stringReplace' of macro markers on 'request.full' at an earlier stage, right on the 'handleHeaderData' procedure (which also works, as second measure), but I don't like this approach, since it could mess with other parts of the code.
Well, I think that's all I will be working with this at the moment, I don't have too much time to go deeper analyzing this, it's only a start for now.
10
HFS ~ HTTP File Server / Re: Warning: HFS v2.x has a severe vulnerability
« Last post by rejetto on October 05, 2024, 10:01:03 AM »that's great, congratulations with your achievement, Leo!
i cannot say anything about effectiveness of this fix, but i'm happy if you can find a solution.
Is the url the only way to use the vulnerability? Even if the POC of the CVE uses the url, be sure to consider the possibility of the attack coming from a header.
you prefer 2.3 over 2.4 ?
i cannot say anything about effectiveness of this fix, but i'm happy if you can find a solution.
Is the url the only way to use the vulnerability? Even if the POC of the CVE uses the url, be sure to consider the possibility of the attack coming from a header.
you prefer 2.3 over 2.4 ?