Finding of installed domains / security flaw?

[Richard G]

I'm just wondering something.

How is it possible, that malicious guys are able to find which domains are on a server.
I've been monitoring this for a while now, and everytime I wonder how they know some domain is on a certain server.

At first I thought they found it via Google and then tried bruteforcing. But it seems they are able to get answers from the DNS database or something.

For example. We got some German domains hosted on one server, and since an "umlaut" like ö or ü is not possible in DNS you have to enter that like this in the named database:

xn--schlafzimmergnstig-tzb.de

This is an example.

However, I'm monitoring bruteforces (mainly chinese) and suddenly now they are bruteforcing this:

Sep 17 23:57:54 server16 pure-ftpd: ([email protected]) [WARNING] Authentication failed for user [xn--schlafzimmergnstig-tzb.de]

Normally in the url not even the "-tzb" at the end is used and is part of the code.

So some way or another, they must have managed to call or read this from the named database.

Is this a DA security flaw? Or how are they doing this and how can we fix it or protect us against this so it's not possible anymore?

 

[DirectAdmin Support]

I've seen websites that will tell you all the domains for a given IP. As a list of domains is available, they'd simply need to log the IP of all domains on the internet.. it would be a very big database, but not impossible to do.
I've googled it, and found a ton of them, and they return the answer in a matter of seconds.
I doubt it's a DNS flaw, more just the capacity for a database to log the A records for a very very large number of domains.

John

 

[Richard G]

Yes ofcourse ip logging can be done for domains, but would you not get schlafzimmergünstig.de instead of "xn--schlafzimmergnstig-tzb.de" which is the real A record? That is what I'm wondering about. In that case they have to convert to the real A record.
And after that attacking the real a record, which is strange also.

 

[zEitEr]

Probably bing.com does it for them

http://www.bing.com/search?q=IP:216.144.255.179

When I added IDN into FileZilla in order to connect to a FTP server it was converted to punycode:

Status: Disconnected from server
Status: Resolving address of xn--schlafzimmergnstig-y6b.de
Status: Connecting to 72.52.4.119:21...

Yes, I see the difference in the domain ending.

If you added the domain as xn--schlafzimmergnstig-tzb.de, then it could be that you've a malware on the server with the help of which they have a list of domains from your server.

 

[Richard G]

If you added the domain as xn--schlafzimmergnstig-tzb.de, then it could be that you've a malware on the server with the help of which they have a list of domains from your server.

No the domain added was very slightly different but I changed it a bit because I did not want to mention the domain in public, so the -tzb at the end is correct for the real domain. But thank your for noticing and warning me about it.

So it seems there are tools which convert automatically from ip to punycode too for the hackers. In that case I don't need to worry about it I guess.

 

[zEitEr]

Not from IP to punycode. I did not mention it.

 

[Richard G]

Well they were bruteforcing email with the punicode name, so they must have some way to find it.
I guess they can make tools for converting it or something.

 

[zEitEr]

My point is, that whenever you use IDN as a target host a FTP,HTTP,MAIL program might still need to convert it to punycode in order to find what IP is behind that name, thus in a process of communication between a client (bruteforce program) and your server a ASCII version of such a domain is used. That is what you see in logs. To make sure and to check you can try to connect to a server with that domain from FileZilla, first time specify IDN, the second time specify ASCII version of the domain. Use wrong login and password to simulate an attack, and see what you will get in logs. Of course do a limited number of tries to avoid being blocked.