Security Ripcord

I was on an IM channel with Paul Asadoorian of Pauldotcom the other day and I started to ask him a question about the Virtual Private Network (VPN) tool ike-scan because he had mentioned using it in podcast PDC Episode59. Before I could finish the question he told me that I had better stop using the program or at least be careful. The editor of his upcoming book, Raul Siles of RaDaJo, pointed him to an interesting “feature” within the ike-scan code during one of their conversations. Apparently ike-scan will make a Domain Name Service (DNS) query for the Fully Qualified Domain Name (FQDN) “ike-scan-target.test.nta-monitor.com” before it queries any of the FQDNs it is passed. In effect, information seepage occurs as the tool is calling home and thereby revealing to NTA Monitor the Internet Protocol (IP) address of the organization using the tool.

The overview of ike-scan provided on the NTA Monitor site describes the tool as: “a command-line tool that uses the IKE protocol to discover, fingerprint and test IPsec VPN servers. It is available for Linux, Unix, MacOS and Windows under the GPL license.” Like every good testing tool ike-scan accepts FQDNs like “www.cutawaysecurity.com”. In order to contact this system the tool has to resolve the IP address of this FQDN through DNS queries. Also, like most good testing tools, ike-scan has an option to disable DNS queries so that it operates a little quicker and quieter. From the ike-scan man page: “–nodns or -N Do not use DNS to resolve names. If this option is used, then all hosts must be specified as IP addresses.” All normal and seemingly innocuous behavior. However, an analysis of the tool�s source code or the network traffic it generates reveals that when the tool is passed a FQDN it does indeed perform a DNS query of “ike-scan-target.test.nta-monitor.com” before it attempts to resolve the supplied FQDN.

The following screen shots demonstrate this behavior. The first image shows the command used to run ike-scan. The following image shows the results of the network traffic as monitored by tshark. I decided to run the tool against my own FQDN “www.cutawaysecurity.com”. It should be noted that I do not have a VPN running on this system but this service is not necessary to get the results I am looking to find.

The network traffic shows the DNS query for “www.cutawaysecurity.com” and it also reveals a DNS query for “ike-scan-target.test.nta-monitor.com”. Although I do not show it here it should be noted that ike-scan does not produce this behavior if the tool is passed the “-N” flag. Of course, this means that the tool has to be given the VPN’s IP address instead of the FQDN. The other alternative to exclude this behavior would be to configure and compile the tool from source code. More on that in a minute.

Once I had confirmed this behavior it was time for me to look at the source code. Paul had pointed me to the specific lines but I needed to find them for myself. The NTA Monitor (http://www.nta-monitor.com) site does not have a specific link to the old software bundles but version 1.8 can still be retrieve by navigating to their downloads directory. After a quick download and untar I grepped for the FQDN that the tool searched for in its DNS query. The following image shows a list of files and then the results of the search for “ike-scan-target.test.nta-monitor.com”.

I navigated to the part of the code that contains the specific query for the FQDN in question. This is shown in the following image. The first thing ike-scan does when it is going to do a DNS query is search for this FQDN. The code to do a DNS query on the FQDN supplied to the tool at the command line is handled by a different function that is called later in the program. Notice the “#ifndef” statement for later reference.

From my limited coding knowledge this strikes me as a piece of code that was included for debugging. It appears that the NTA Monitor developers could have forgotten to remove this piece of code from the final version. Coincidentally, when I was visiting the NTA Monitor website I had noticed a newer version of the code, ike-scan version 1.9, was available. I decided to check this version for the same piece of code and behavior. Following the same procedures as the previous version, I downloaded the source of version 1.9, untarred it, grepped for the FQDN, compiled from source without changing any configuration options, and ran the tool. The following screen shots show the results of these actions. It seems that the DNS query for “ike-scan-target.test.nta-monitor.com” is no longer included in the tools code base.

Not finding anything in version 1.9 moved me further down the road of this whole issue being debugging code left in the production version of the tool. I decided to do one more check and to find out what the developers at NTA Monitor had to say about this section of code and their tool’s network activity. I emailed the developers using the contact information on the NTA Monitor website and I received a quick response. The following are the contents of the emails that were exchanged.

Outgoing Email:

In ike-scan 1.8 there was a section of code that did a DNS lookup on
ike-scan-target.test.nta-monitor.com prior to doing a DNS lookup for the
host that was supplied to the program. I am investigating why this
piece of code was included.

I have noticed that it is not a part of 1.9. I have also noticed that
although the hostname does resolve that the host does not respond to
pings. Is this host active?

I am going to be doing blog post and possibly a podcast on the subject
in the next couple of days. I am hoping to include your response.

Thank you for your time and effort,
Cutaway
http://blog.cutawaysecurity.com

The response:

Cutaway,

Regarding the DNS lookup thing. This was initially there for debugging,
but was never really needed for public use. It was made optional in version
1.8 with a configure option to disable it, and removed entirely in version 1.9.

If you’ve not already done so, it’s worth taking a look at the ike-scan
wiki. This was one of the things that I launched for version 1.9. It’s still
early days, but I’ve already put some useful information up there.

The ike-scan page on the wiki is:
http://www.nta-monitor.com/wiki/index.php/Ike-scan_Documentation

There’s also a wiki for arp-scan which is another one of my open-source
projects, but that’s another story.

It’s worth having a read through all the pages if you have the time. However,
the main bits worth looking at are:

a) The user guide - nowhere near finished, but it’s a start.
b) IKE Implementation analysis - shows how different products respond. Very useful for fingerprinting.
c) Recent changes - shows what’s changed in the various versions of ike-scan.

I’d be happy to get involved with your blog or podcast if it would help.

If you want any further information, or have any comments or suggestions, please let me know.

Regards,

Roy Hills

This exchange confirmed to me that this piece of code was only meant for debugging purposes. After receiving this information I caught up with Paul on IM again. I told him about this email exchange but he still sounded a little skeptical that the inclusion of this code was purely innocuous. I concluded this from the tone of his response but did not have time to confirm his thoughts because the conversation ended quickly.

This quick conversation got me thinking again. Is there more to this? I decided to look at the code a little more. This is where the “#ifndef” statement comes back into play. I decided to do a little searching on this statement. More precisely I searched the source code of version 1.8 for “DISABLE_LOOKUP”. The result of this query is shown in the following image.

I mentioned that I do not have a lot of experience in programming. What I ascertain from the information provided by this query is that the initial lookup feature can be disabled with a simple parameter change before compilation. To me this is a little weird though. Turning off this feature does not turn off the capability to do DNS queries. What is being turning off is the initial DNS query to “ike-scan-target.test.nta-monitor.com”. Also the statement “Define to disable initial lookup” is a bit odd.

Still wondering what this all means I decided to try and think through the whole scenario a little more. I scan a target with a FQDN. The program does a DNS query on “ike-scan-target.test.nta-monitor.com” and then moves on in an expected fashion. So, in order to understand how we are affected by this query we have to understand a little bit about DNS queries. In this case the tool queries the computer’s operating system which, in turn, queries the default gateway. The default gateway then starts going through the gambit of DNS servers. A good illustration of this query progression as well as a good description of DNS in general can be found on Wikipedia’s Domain Name System entry.

From this article and image, if the information for “ike-scan-target.test.nta-monitor.com” is not contained within the DNS cache a recursive query will be made all the way back to NTA Monitor’s domain server. Once an initial query has been made the information will be stored for a number of seconds specified by the TTL field in the DNS query information or when the DNS server decides to time out the information itself. A quick query using DNSStuff.com returns this information.

From this output the name server queried is “test.nta-monitor-com” and the information is set to time out after 28800 seconds which is equivalent to 8 hours. But the information from Wikipedia about DNS queries does not necessarily clarify whether the request for information will come from the requesting operating system, the organization’s default gateway, or from one of DNS servers that has been assigned to the default gateway. The fear is that the query to the NTA Monitor name server will come from the organization’s default gateway and thereby reveal the organization that is using ike-scan, which is information seepage. My initial fear was that NTA Monitor was forcing the initial DNS requests to their name server and, in effect, revealing information about the scanning organization and the target VPN. Both of which should not be disclosed to a third party. Of course, with a little more understanding of what is going on in the tool and how DNS queries work, I can see that my initial fears were unfounded. Information seepage can occur, however, because of the potential that the DNS query could originate from an organization’s default gateway thereby exposing its IP address to NTA Monitor’s name server.

My conclusion on this whole matter is that the phone home “feature” included in ike-scan version 1.8 is just some debugging code that found its way into the product released to the public. Certainly there is potential for some information seepage but the systems affected are not necessarily an organization’s critical resources or that of a client. Had this been the case then my conclusion might have been different. I do recommend upgrading to the new version of ike-scan which, at the time of this article is version 1.9. If, however, using ike-scan version 1.8 cannot be avoided, I have to recommend that people either use the “-N” option and supply the tool only specific IP addresses or that they recompile the program after setting the “DISABLE_LOOKUP” variable to “0″ so as to completely disable this “feature.”

Another issue that comes to mind is reviewing source code of software that will be used within a company’s environment. Information seepage of any type may be unacceptable to some organizations, companies, or governments. Code can be reviewed for security related problems that may occur due to situations such as buffer overflow errors, but software evaluation tools like those provided by Ounce Labs or Fortify Software are not going to find anomalous behavior such as the information seepage represented in the ike-scan version 1.8’s code base. There are really only two methods to detect this type of behavior. First, a detailed line by line review of the code can be conducted by experienced developers. Of course this method is time consuming and expensive and should only be initiated to alleviate risk to the most critical of assets. The second method, probably the best solution for all situations, is monitoring network traffic in a manner that will provide your network and system administrators and security personnel the ability to reconstruct events and respond to unwanted activity. Even extrusion content monitoring and network behavior analysis solutions may not be able to help if the network communications occur in a manner such that the information flies just below (or above) the radar of these tools’ alerting mechanisms. Simply put, only trained personnel who understand the normal network traffic patterns of an organization are going to be able to detect information seepage that does not match the alerting patterns of most network monitoring security solutions.

Go forth and do good things,
Cutaway

I would like to thank Paul Asadoorian for bringing this to my attention and giving me something interesting to work on, Raul Siles for pointing the “feature” out to him, Roy Hills of NTA Monitor for getting back to me in a prompt and informative manner, and Matt Zimmerman for his valuable editing assistance.

ike-scan, RaJaDo, Siles, PDC, Asadoorian, Hills, Zimmerman, Security Ripcord, NTA Monitor, Ounce Labs, Fortify Software

---

Help support my training and travel to security conferences. Get your SANS Training and GIAC Certifications through the Security Ripcord.

---

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.