A little trick in DNS

Last Friday, I played with DNS records. I know nothing about configuring a DNS. However, as an engineer, it is worth to (i have to) know more about DNS, not just in theory. I took a look at the record types in DNS, and I discovered that there is a trick which can confuse the DNS client. Let’s first take a look at the following DNS record type (from wiki),

Code	Defining RFC	Description	Function
CNAME	RFC 1035	Canonical name record	Alias of one name to another: the DNS lookup will continue by retrying the lookup with the new name. This helps when running multiple services (like an FTP and a webserver; each running on different ports) from a single IP address. Each service can then have its own entry in DNS (like ftp.example.com. and www.example.com.). Network administrators also use CNAMEs when running multiple HTTP servers on the same port, with different names, on the same physical host. This however requires host headers support for the two sites to both listen on the default port (port 80).

Let’s assume that we have a domain name (DN) whois.evil.org and we want it to be resolved as iam.evil.org, in the same zone file, the record can look like this

whois.evil.org    CNAME    iam.evil.org

When a client querying where whois.evil.org is, the DNS will discover this record, and try to resolve iam.evil.org for the client, or just return iam.evil.org back to the client. CNAME record also works to point the domain outside your zone (in this case, the zone is evil.org). For example, if we have a DN whereis.evil.org which resolved to hell.net, then our record can look like this

whereis.evil.org    CNAME    hell.net.

Ending with dot “.” means that the value is a fully qualified domain name (FQDN). The DNS server may return hell.net to the client if it cannot help to resolve it. Then what if I change the value hell.net to localhost? ie.

whereis.evil.org    CNAME   localhost.

localhost is a famous “domain name”, it will take you back home. Depends on what kinds of software you are using, it will have different outcome. The current approach of using CNAME record in this post is not aggressive enough, is it possible to harm the user? I am still thinking about this. Let me know if you have any great idea or existed attack using the similar technique.

Thanks Greg! Greg pointed me to this interesting trick.

Filed under: protocols, spec , cname, DNS, localhost

Smtp (RFC 2821)

I did not write a new entry for a very long time. This time, I would like to discuss the RFC 2821. This is the first time I read documents in RFC. Simple Mail Transfer Protocol (SMTP) is the simplest Internet standard for delivering emails across IP networks. The one I read is not the updated version of SMTP, the most updated one is RFC 5321, I may take a look on it later. But still, it is worth to take a look at RFC 2821, see how the engineers think about message delivery in the past.

Once the SMTP client connected to the SMTP server, the client should perform the command EHLO to introduce itself to the server, the server will reply with a list of extensions if it has. After initiate the connection between client and server, there are 3 basic steps the client need to perform to complete the mail submission.

MAIL FROM:<username@domain> – This is the command to declare the sender of the email, it can be used to identify the sender and can be used as the replying address (Of course you can specify the replying address with other commands).

RCPT TO:<username@domain> – In an opposite, this command is used to declare the receiver of the email, the SMTP server has to identify the recipients’ address before it accepts the mail submission. You can specify more than one recipients or even mailing list.

DATA – After this command is performed, the client can submit the content of the message to server. To declare the end of the message, client must provide an extra line with a single dot “.”. In Internet Message Format (RFC 2822), they defined some fields inside DATA block to represent different type of information, eg. SUBJECT.

The mail submission process can be visualized with the following diagram (Greatly simplfiied, give a better version later).

from RFC2821

The SMTP design may allow an attack at the very beginning, when client try to initialize the session. By design, the SMTP protocol allows server to formally reject a transaction while still allowing the initial connection; server can send a 554 (Transaction failed) response instead of 220 (<domain> service ready). However the server must wait for the QUIT command performed by the client. What if the client just leave the connection there and do not echo the QUIT command? and what if there are tons of clients (most likely is a tons of zombies) doing the same thing at the same time? Is server possible to handle that? The server may be overloaded because of these actions. In other words, it is a denial of service (DoS). In more accurate speaking, it is distributed denial of service (DDoS), because it needs more than one machine to cause the server overloaded.

I am still on the way to finish this RFC, next time I will discuss some extensions mentioned in the RFC 2821, which may help spammer to grab email addresses from the SMTP server. Let’s have a guess what are they before I really post the next entry. Enjoy!

Filed under: app sec, protocols, spec , DDoS, DoS, email, RFC, SMTP