RCS and DNS: The NAPTR Record, (Mon, Jul 6th)
\n \t
\n
<\/BR>
\n
\n \t
\n
<\/BR><\/p>\n
Over the last year, with recent updates to iOS and Android, RCS (Rich Communication Services) has become an increasingly used protocol [1]. RCS is supposed to eventually replace SMS, and in addition to richer formatting, provides added (but optional) security. RCS messages may be end-to-end encrypted and digitally signed. Unlike SMS, which was “bolted on” to existing voice-focused phone standards. The SMS standard was based on old-fashioned pagers\u00a0and allowed for limited clear-text communications. RCS is built from the ground up around modern IP-based network infrastructure and behaves more like IP chat services (think iMessage, WhatsApp…). RCS defines\u00a0the message format, while protocols like SIP are used to establish connections and transport messages.<\/p>\n
“Do as you say”, I do from time to time take a look at odd DNS traffic on my network. An activity I recommend when teaching SEC503. Recently, I noticed more “NAPTR” queries, a record type I had not seen before. The record type is defined in RFC 2915 [2], which was ratified in 2000. It is not a new record. But so far, at least in my network, it has not really shown up before.<\/p>\n
The description of the record sounds rather ominous:<\/p>\n
\n“a Resource Record that included a regular expression that would be used by a client program to rewrite a string into a domain name.”<\/p>\n<\/blockquote>\n
Wow. Regular expressions to rewrite resource records? What could possibly go wrong? However, right now, I just want to talk about how it “goes right” and how these records are currently being used for RCS.<\/p>\n
Below is the relevant part of the t-shark decode of a record typical for what I have seen in my network:<\/p>\n
\n\u00a0 \u00a0 Queries
\n\u00a0 \u00a0 \u00a0 \u00a0 fp-us-verizon.rcs.telephony.goog: type NAPTR, class IN
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Name: fp-us-verizon.rcs.telephony.goog
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 [Name Length: 32]
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 [Label Count: 4]
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Type: NAPTR (35) (Naming Authority Pointer)
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Class: IN (0x0001)
\n\u00a0 \u00a0 Answers
\n\u00a0 \u00a0 \u00a0 \u00a0 fp-us-verizon.rcs.telephony.goog: type NAPTR, class IN, order 100, preference 100, flags s
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Name: fp-us-verizon.rcs.telephony.goog
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Type: NAPTR (35) (Naming Authority Pointer)
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Class: IN (0x0001)
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Time to live: 295 (4 minutes, 55 seconds)
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Data length: 61
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Order: 100
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Preference: 100
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Flags Length: 1
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Flags: s
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Service Length: 8
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Service: SIPS+D2T
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Regex Length: 0
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Regex:
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 [Replacement Length: 43]
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Replacement: _sips._tcp.fp-us-verizon.rcs.telephony.goog<\/tt><\/p>\n<\/blockquote>\n\u00a0<\/p>\n
This was the only applicable NAPTR record, so order and preference do not matter in this case. The “S” flag indicates that the next lookup should be a SRV record. And indeed, we do have a SRV query (see below). Only a “U” flag would result in a URI.\u00a0<\/p>\n
Remember that this record is about URIs,\u00a0not\u00a0IP addresses? The “Service” field indicates what service we may find at the to-be-determined URI. In this case, it is SIPS+D2T. SIPS+D2T is a transport protocol defined in the SIP standard (RFC 3263). SIPS+D2T stands for “Secure SIP Direct to TCP”. So we will be using SIP over TLS with TCP as the transport protocol. The SIP standard specifically calls for NAPTR records to find SIP servers. The reason for the NAPTR record is to allow\u00a0URIs to be returned, not just IP addresses\/hostnames (as an SRV record would).<\/p>\n
Lucky for us (and the DNS server), the regular expression is empty. And this appears to be normal for this use case. Instead, we just get a “SRV” record to request:<\/p>\n
\n
\u00a0 \u00a0 Queries
\n\u00a0 \u00a0 \u00a0 \u00a0 _sips._tcp.fp-us-verizon.rcs.telephony.goog: type SRV, class IN
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Name: _sips._tcp.fp-us-verizon.rcs.telephony.goog
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 [Name Length: 43]
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 [Label Count: 6]
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Type: SRV (33) (Server Selection)
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Class: IN (0x0001)
\n\u00a0 \u00a0 Answers
\n\u00a0 \u00a0 \u00a0 \u00a0 _sips._tcp.fp-us-verizon.rcs.telephony.goog: type SRV, class IN, priority 20, weight 0, port 5223, target fp-us-verizon.rcs.telephony.goog
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Service: _sips
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Protocol: _tcp
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Name: fp-us-verizon.rcs.telephony.goog
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Type: SRV (33) (Server Selection)
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Class: IN (0x0001)
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Time to live: 300 (5 minutes)
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Data length: 40
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Priority: 20
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Weight: 0
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Port: 5223
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Target: fp-us-verizon.rcs.telephony.goog
\n\u00a0 \u00a0 \u00a0 \u00a0 _sips._tcp.fp-us-verizon.rcs.telephony.goog: type SRV, class IN, priority 30, weight 0, port 443, target fp-us-verizon.rcs.telephony.goog
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Service: _sips
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Protocol: _tcp
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Name: fp-us-verizon.rcs.telephony.goog
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Type: SRV (33) (Server Selection)
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Class: IN (0x0001)
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Time to live: 300 (5 minutes)
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Data length: 40
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Priority: 30
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Weight: 0
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Port: 443
\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Target: fp-us-verizon.rcs.telephony.goog<\/code>???????<\/p>\n<\/blockquote>\nAnd yes, in the end, there is a “normal” A and AAAA lookup for\u00a0fp-us-verizon.rcs.telephony.goog.<\/p>\n
So far, NAPTR records do not appear to be used to their full potential. I am sure that the use of regular expressions will be of interest to bug hunters and penetration testers.\u00a0<\/p>\n
[1]\u00a0https:\/\/support.google.com\/messages\/answer\/13508703?hl=en
\n[2]\u00a0https:\/\/www.ietf.org\/rfc\/rfc2915.txt<\/p>\n—
\nJohannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu<\/a>
\nTwitter<\/a>|<\/p>\n(c) SANS Internet Storm Center. https:\/\/isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.<\/p><\/div>\n
\t
\n
<\/BR><\/p>\n