Solved DNS Name Cannot Resolve Error for Security Tools

O

oprrr

Hi, I'm in this weird situation where I put IP and host in /etc/hosts, some tools that I use cannot revolve the hostname.

A bit about the situation:

I'm currently pivoting to cybersecurity, I've using FreeBSD for a long time and don't want to go to another platform. So I prefer doing everything just on my FreeBSD host.

Scenario:

1. HackTheBox, I'm behind their VPN;

2. IP and host name are listed in /etc/hosts;

3. Tools like dirsearch and feroxbuster just don't work, dirsearch reported "cannot connect to host", feroxbuster reported "Name cannot be resolved";

4. But ping command on the hostname works just find;

5. Host is on HTTP protocol, like: feroxbuster -u http://example.htb;

I wonder if there's any sysctl inet configuration that I should pay attention to in situation like this?

Thanks!
 
If any of the tools do an actual DNS lookup it will circumvent anything that's in /etc/hosts. Tools like dig(1) or drill(1) for example do DNS queries directly.
 
SirDice said:
If any of the tools do an actual DNS lookup it will circumvent anything that's in /etc/hosts. Tools like dig(1) or drill(1) for example do DNS queries directly.
Click to expand...
Thanks SirDice. I'm aware of that situation so I dug a little into the source code of those tools, but haven't found anything yet. I'll keep digging.
 
If they use the "normal" name resolving functions then it should respect /etc/nsswitch.conf and try the hosts file first.

Code: 
hosts: files dns
 
oprrr said:
I'm aware of that situation so I dug a little into the source code of those tools
Click to expand...
If this is C (or C++) source, they should only use getaddrinfo(3) and friends (or the legacy gethostbyname(3) and friends).

If it's some other language, I wouldn't be surprised to find some runtime libraries implementing their own DNS queries, circumventing the system's name resolving functionality. Maybe you could still just use some locally installed nameserver instead of putting everything in /etc/hosts.
 
zirias@ said:
If this is C (or C++) source, they should only use getaddrinfo(3) and friends (or the legacy gethostbyname(3) and friends).

If it's some other language, I wouldn't be surprised to find some runtime libraries implementing their own DNS queries, circumventing the system's name resolving functionality. Maybe you could still just use some locally installed nameserver instead of putting everything in /etc/hosts.
Click to expand...
Thanks for the tip. All those tools should be basically python, go or rust. Seems all working in Linux, that's one reason I have to find a way to make them work in FreeBSD :D
 
Had a quick look at dirsearch and it seems to use the 'standard' name resolving functions. So it should just work. It's possible you've made a typo in /etc/hosts and it's not working because of that?

Keep in mind that "cannot connect to host" doesn't imply name resolving isn't working. There could be a number of other reasons why it cannot connect to the host. Wrong port, service not running, firewall blocking the request or response, etc.

Simple way to verify is to keep a tcpdump(1) running to capture the traffic. Then you can actually verify if it attempts to make a connection or not.
 
SirDice said:
If they use the "normal" name resolving functions then it should respect /etc/nsswitch.conf and try the hosts file first.

Code: 
hosts: files dns
Click to expand...
Tested, they are not respecting /etc/nsswitch.conf, has hosts: files dns configured, but still cannot resolve hostname.
 
SirDice said:
Had a quick look at dirsearch and it seems to use the 'standard' name resolving functions. So it should just work. It's possible you've made a typo in /etc/hosts and it's not working because of that?

Keep in mind that "cannot connect to host" doesn't imply name resolving isn't working. There could be a number of other reasons why it cannot connect to the host. Wrong port, service not running, firewall blocking the request or response, etc.

Simple way to verify is to keep a tcpdump(1) running to capture the traffic. Then you can actually verify if it attempts to make a connection or not.
Click to expand...
That's something I have done, interestingly, gobuster works just fine, lots of traffic going through tun0, but nothing happens with dirsearch... :oops:
 
SirDice said:
Had a quick look at dirsearch and it seems to use the 'standard' name resolving functions. So it should just work. It's possible you've made a typo in /etc/hosts and it's not working because of that?

Keep in mind that "cannot connect to host" doesn't imply name resolving isn't working. There could be a number of other reasons why it cannot connect to the host. Wrong port, service not running, firewall blocking the request or response, etc.

Simple way to verify is to keep a tcpdump(1) running to capture the traffic. Then you can actually verify if it attempts to make a connection or not.
Click to expand...
I looked at the source code again, I think I know what happened here. Using Miniconda Linux might be a mistake here (idea is just to do version control...). Due to different socket implementation maybe? Using BSD socket I can resolve the name without problem, but in conda environment, Name or service not known...

conda env:
Code: 
>>> socket.getaddrinfo('2million.htb', 80)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/opr/.miniconda3/envs/dirsearch/lib/python3.9/socket.py", line 954, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -2] Name or service not known

BSD:

Code: 
>>> socket.getaddrinfo('2million.htb', 80)
[(<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_DGRAM: 2>, 17, '', ('10.10.11.221', 80)), 
(<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('10.10.11.221', 80)), 
(<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_SEQPACKET: 5>, 132, '', ('10.10.11.221', 80))]

I think this should just make dirsearch work, I might as well just use virtualenvwrapper. Next is feroxbuster :D
 
As far as I know conda (and similar) is just a fancy wrapper around Python's venv. And the code just runs on the host, it's not a container, jail or chroot.
 
SirDice said:
As far as I know conda (and similar) is just a fancy wrapper around Python's venv. And the code just runs on the host, it's not a container, jail or chroot.
Click to expand...
Yes. Problems have all been solved. It's me being silly. pipx install dirsearch, cargo install feroxbuster just sorted everything out. Trying to use linux version of some package on FreeBSD causes all the trouble. Thanks for your time SirDice.

Mark as solved.
 
oprrr said:
Trying to use linux version of some package on FreeBSD causes all the trouble.
Click to expand...
Possible to do, but you're going to need to enable the Linux compatibility layer. While it usually works it's not 100%, so some things might not work as expected.

docs.freebsd.org

Chapter 12. Linux Binary Compatibility

FreeBSD provides binary compatibility with Linux, allowing users to install and run most Linux binaries on a FreeBSD system without having to first modify the binary
docs.freebsd.org docs.freebsd.org

In this case however, these are Python modules/code. You can usually install (or compile) them for FreeBSD natively.
 
You must log in or register to reply here.
Back
Top