Security Training
Security Certification
Cyber Security Graduate School
Internet Storm Center
Security Awareness Training
Computer Forensics
Penetration Testing
IT Audit
Software SecurityIntrusion Detection FAQ: What is the TSIG vulnerability?
|
Paul Asadoorian April 4, 2001 IntroductionAwareness for the Bind TSIG (short for transaction signature) attack was raised towards the end of January 2001. This attack effected all current versions of Bind version 4 and 8 (but not 9). Advisories are posted on Bugtraq (http://www.securityfocus.com/vdb/bottom.html?vid=2302), CVE (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0012), Cert (http://www.cert.org/advisories/CA-2001-02.html), and ISC’s web sites (Internet Software Consortium http://www.isc.org/products/BIND/bind-security.html). PGP’s COVERT Labs found the exploit. The initial press release can be found at http://www.pgp.com/research/covert/advisories/047.asp. This new buffer overflow attack allows the attacker to gain root access to any DNS server that is running the correct (or incorrect, depending on how your are looking at it) version of Bind. To understand how this attack works you must first understand how buffer overflows work, as well as a little about how Bind operates at the application layer [2]. Buffer OverflowsBuffer overflows occur when a program does not check to make sure the data it is putting into a space will actually fit into that space. Unfortunately computers don’t automatically detect when this condition occurs, and since this happens in memory, the data will overwrite whatever comes after the space you are trying to fill. The "spaces" I am referring to are called variables, which for all intensive purposes reside on what’s called the stack (or Program Memory). The following diagram represents what your program, or any other program such as bind, would look like in memory [1] [5]:
-------------------
------------------- Bind – Infoleak & TSIGThe TSIG, or Transaction Signature, is a resource record that needs to append a secure key to the message sent to the DNS server. It is when a TSIG record is sent without a secure key that code is executed which does not check the bounds of the data before storing it into a variable. There is one problem with exploiting the TSIG code; you need to gather information about environment variables whose values are contained on the stack. Access to this information is accomplished by sending an IQUERY (Inverse Query) to the DNS server that will, due to a bug, return the information needed. This bug is known as Infoleak. So now we can start to build pattern for this exploit. If someone wants to use this exploit they will need to perform an IQUERY, followed by a TSIG record [4] [6]. The AttackThe code was taken from http://neworder.box.sk/showme.php3?id=4037 and is also posted on hack.co.za http://www.hack.co.za/exploits/daemon/named/tsig.c (I give two references here because often times these sites fall victim to the exploits they contain). It can also be found in Appendix A. I was able to compile this code on a PC running Red Hat Linux 6.2. I ran it against another Red Hat Linux 6.2 machine, running Bind 8.2.2-P5. I was able to gain root access to the target machine. The following is what the attacker would see when the exploit is run (output has been sanitized):
[root@jabba /root]# ./tsig Analyzing & Detecting the AttackWhen I ran this exploit I was running snort 1.7 and told it to grab all packets on the network: (using ./snort –ved):
02/22-15:33:19.465555 0:40:33:54:52:42 -> 0:40:33:55:A0:55 type:0x800 len:0x206
15:33:19.465555 ATTACKER.1024 > VICTOM.domain: 48879 inv_q+ [b2&3=0x980] (476)
alert udp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"IDS277 - NAMED Iquery Probe"; content: Further Detection & Defensive RecommendationWe really need to be able to detect (and log if possible) two things, the UDP packet containing the TSIG overflow (and shellcode), as well as the TCP connection that is made if the attack is successful. We want to know if someone is trying to compromise of our machines, and if a TCP connection is made we can be almost positive that the machine has been compromised. The following snort rule takes care of these conditions:
activate udp any -> any 53 (msg:"Bind TSIG Overflow Attempt"; content: "|80 00 07 00 00
[**] IDS277 - NAMED Iquery/Infoleak Probe [**] Adding the above rules to your snort IDS and monitoring it closely will provide you with the necessary tools to successfully detect this attack. You should also put your DNS servers behind the firewall and block all other ports besides 53/udp (and maybe 53/tcp with a filter to prevent zone transfers and TCP port scanning). This will prevent attackers from being able to start a rootshell on higher ports numbers, such as 36864 as shown in the example above. You should also add Egress filtering to your router and/or firewall to prevent your DNS from sending out information it does not have to (i.e. mail, FTP, telnet, etc.). This way even if the attack is successful the hacker cannot launch attacks onto other machines, or at least is limited as to what they can do. The host, especially a high profile machine like your DNS server, should have some sort of host based intrusion detection (such as Portsentry http://www.psionic.com and/or Fcheck http://www.geocities.com/fcheck2000). Portsentry will log every connection attempt to each port that you tell it to, and Fcheck performs checksum operations on your binaries (or any other type of file) and alerts you of changes. Finally, always be sure that you are on the most current release of Bind, which is Bind 9.1.0 (http://www.isc.org/products/BIND/bind9.html) in the Bind 9.x series, Bind 8.2.3-REL (http://www.isc.org/products/BIND/bind8.html) in the Bind 8.x series, and Bind 4.9.8 (http://www.isc.org/products/BIND/bind4.html) in the 4x. series at this time [3]. Update: The LION wormOn March 23, 2001 SANS issued an alert describing the LION worm (http://www.sans.org/y2k/lion.htm). This worm attacks Red Hat Linux systems using the Bind TSIG buffer overflow. The program scans class B networks looking for vulnerable DNS servers. When it finds a vulnerable host it is compromised and the t0rn root kit is installed, as well as multiple backdoors and trojan binaries and logging is disabled. Since this trojan uses the Bind TSIG attack I submitted my rule to intrusion@sans.org and it was posted to the web site (http://www.sans.org/y2k/032601.htm). Even though the worm disables the logging on the target system snort will allow you to see the data travel across the network using the rule above. This new worm heightened the awareness of the Bind TSIG attack, and as a result many new snort rules were written. These rules cover the different strands of the Bind TSIG attack, including lion. From www.whitehats.com here are the current rules:
AcknowledgmentsSpecial thanks to Martin Roesch for personally helping me utilize the newer (and relatively untested at the time) features of snort to create the detection rule presented in this paper. Snort is one of the best examples of how successful an open source project can be. References[1] Aleph One. "Smashing The Stack." Phrack Magazine Volume Seven, Issue Forty-Nine 10-20. [2] Cohen, Cory F. Cert Coordination Center. "ISC BIND 8 contains buffer overflow in transaction signature (TSIG) handling code". Vulnerability Note VU#196945. URL: http://www.kb.cert.org/vuls/id/196945 (1 Mar. 2001). [3] Internet Software Consortium. "Bind Vulnerabilities" URL: http://www.isc.org/products/BIND/bind-security.html (15 Feb 2001). [4] Lanza, Jeffrey P. Cohen, Cory. "CERT® Advisory CA-2001-02 Multiple Vulnerabilities in BIND" CERT/CC. 29 January 2001. URL: http://www.cert.org/advisories/CA-2001-02.html. (22 Feb. 2001). [5] Mixter. "Writing buffer overflow exploits - a tutorial for beginners" URL: http://members.tripod.com/mixtersecurity/exploit.txt (12 Feb 2001). [6] Osborne , Anthony. McDonald, John. "Vulnerabilities in BIND 4 and 8". 29 January 2001. URL: http://www.pgp.com/research/covert/advisories/047.asp (10 Feb. 2001) [7] Roesch, Martin. Advanced Intrusion Detection: Snort Style. The SANS Institue, 2001. 139 - 150. |
Check Them Out!
Consistently some of the best training available. It is apparent that SANS updates their course content and SANS instructors are established experts in the field.
-Ryan Macfarlane, FBI
