Next Page >>
DNS
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Cisco Security Advisory: Multiple Cisco Products Vulnerable to DNS Cache
Poisoning Attacks
Advisory ID: cisco-sa-20080708-dns
http://www.cisco.com/warp/public/707/cisco-sa-20080708-dns.shtml
Hash: SHA1
Core Security Technologies - CoreLabs Advisory
http://corelabs.coresecurity.com/
Windows SMTP Service DNS query Id vulnerabilities
1. *Advisory Information*
Severity: Medium
References: Microsoft Security Bulletin MS07-062, CVE-2007-3898
2) Vulnerability Description
Microsoft DNS server generates predictable DNS transaction IDs. If the
server is configured to allow recursive queries it is possible to insert
fake records in the DNS cache (DNS cache poisoning) by guessing the next
transaction ID that the server will use and sending a spoofed DNS reply
to the server. To observe the transaction IDs an attacker needs to
control a DNS server that is authoritative for some domain and to be
############################################################################
#####
Subject: DNS Multiple Race Exploiting Tool release
Homepage: http://www.securebits.org/dnsmre.html
Download: http://www.securebits.org/tools/dns_mre-v1.0.tar.gz
OS: The tool runs on Linux
Target OS: Tested against windows 2003 server
############################################################################
#####
After 6 months - fix available for Microsoft DNS cache poisoning
attack
On April this year I discovered a new vulnerability that enables
DNS cache poisoning attack against the Windows DNS server. Today
(November 13th, 2007) - six and a half months after being informed
- Microsoft released a fix for this vulnerability. As the fix is
now publicly available, I can finally share my research finding
with you.
BIND 8 EOL and BIND 8 DNS Cache Poisoning
Note: this is a different attack from BIND 9 DNS cache poisoning.
I discovered a new weakness in BIND 8 DNS server which enables "DNS
Forgery Pharming". An attacker can remotely poison the cache of any
BIND 8 caching DNS server and force users who use this DNS server to
reach fraudulent websites each time they try to access real websites.
BIND 8 is still a very popular DNS server nowadays thus this attack
applies to a big part of Internet users.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Cisco Security Advisory: Cisco Global Site Selector Appliances DNS
Vulnerability
Advisory ID: cisco-sa-20090107-gss
http://www.cisco.com/warp/public/707/cisco-sa-20090107-gss.shtml
Details:
It is possible to overflow buffor on stack in suid program - mtr. Remote attack
is possible too. Bug is in function which print result of runing program with parametr
'split' (-p). Victim must use DNS which we can control or we can try exploit this
vulnerability by spoofing technique. In remote exploiting this vulnerability we must
know which IP user gave to program - or he must simply run program and argument
must be IP adres which we can controle in DNS server.
Look for this code:
Hello BugTraq,
The Microsoft Windows DNS stub resolver (the component in Windows
that queries the upstream DNS server for address resolutions on
behalf of most Windows programs, e.g. browsers) sends predictable
DNS queries with respect to DNS transaction ID and source UDP
port. This allows some interesting attacks on DNS clients (i.e.
desktops), including DNS cache poisoning of the client's local
DNS cache (which is maintained by the stub resolver).
===============/========================================================
Exploit ID: CAU-EX-2008-0002
Release Date: 2008.07.23
Title: bailiwicked_host.rb
Description: Kaminsky DNS Cache Poisoning Flaw Exploit
Tested: BIND 9.4.1-9.4.2
Attributes: Remote, Poison, Resolver, Metasploit
Exploit URL: http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
Author/Email: I)ruid <druid (@) caughq.org>
H D Moore <hdm (@) metasploit.com>
Update+Errata for "OpenBSD DNS Cache Poisoning and Multiple O/S
Predictable IP ID Vulnerability"
(http://www.trusteer.com/docs/OpenBSD_DNS_Cache_Poisoning_and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf)
Update
******
OpenBSD
Hal Finney wrote:
> I thought of one possible mitigation that can protect OpenID end users
> against remote web sites which have not patched their DNS. OpenID
> providers who used weak OpenSSL certs would have to change their URLs
> so that their old X.509 CA certs on their old URLs no longer work on the
> new ones. This will require all of their clients (users who log in with
> their OpenID credentials) to change their identifiers. DNS based MITMs
> will not be able to forge messages related to the new identifiers.
Yeah, I considered this scheme. The problem is that it doesn't really
>
> ===============/========================================================
> Exploit ID: CAU-EX-2008-0002
> Release Date: 2008.07.23
> Title: bailiwicked_host.rb
> Description: Kaminsky DNS Cache Poisoning Flaw Exploit
> Tested: BIND 9.4.1-9.4.2
> Attributes: Remote, Poison, Resolver, Metasploit
> Exploit URL: http://www.caughq.org/exploits/CAU-EX-2008-0002.txt
> Author/Email: I)ruid <druid (@) caughq.org>
> H D Moore <hdm (@) metasploit.com>
[I feel a little uncomfortable replying with such a wide distribution!]
Getting browsers, or OpenID installations, to check CRLs or use OCSP to
check for freshness is likely to be slow going. At this point I think
the momentum still favors fixing the remaining DNS systems that are
vulnerable to cache poisoning. This turnkey-MITM bug makes OpenSSL bad
certs far more exploitable, as Dan Kaminsky pointed out in his report.
OpenID is just one example of many where this is going to keep happening
as long as DNS is unpatched.
=============================================================================
FreeBSD-SA-08:06.bind Security Advisory
The FreeBSD Project
Topic: DNS cache poisoning
Category: contrib
Module: bind
Announced: 2008-07-13
Credits: Dan Kaminsky
The DNS packet format allows names to be compressed by replacing the
suffix of a name with an encoded offset to another location in the
packet where the suffix already exists. Because of the encoding
scheme, valid offsets are limited to < 16384.
In djbdns 1.05, response.c handles name compression. Line 12 has a
comment "each < 16384" on the name_ptr array, but response_addname()
from the same file does not enforce this limitation. The result is
that when encoding names with a suffix that first appears >= 16384
bytes into the packet, response_addname() incorrectly tries to encode
Preferred lifetime: 10800
Valid lifetime: 21600
Domain Search List <<<--------------------------------------
option type: 24
option length: 1
DNS Domain Search List
Malformed option
DNS recursive name server
option type: 23
option length: 32
DNS servers address: fec0:0:beef:f00d::feed
I. BACKGROUND
The Webroot Desktop Firewall secures your computer from Internet threats and reduces the risks of being a victim of online crimes. Unlike the Windows XP and Vista Firewall, Webroot Desktop Firewall combines intelligent firewall technology with intrusion prevention for inbound and outbound protection that is both powerful and easy to use. http://www.webroot.com/
II. DESCRIPTION
DNS tunnelling involves inserting data into the DNS packet using "space" in the packet that can take additional data. For example, A DNS packet can contain a TXT record into which any text, up to 220 bytes, can be inserted. You fragment the data, maybe an HTTP request, add it to the packet, and send the modified DNS traffic over the web to a receiving server. It recompiles the sent data, and enables internet access. DNS packets can be used to transfer extra data and this is why they should be controlled by firewalls as any other packets.
III. ANALYSIS
Windows DNS API using can help an attacker to make data transfer possible. If the successfull recursive DNS query for “x-site” is done, it is possible to transfer information from your computer past personal and network firewalls. There is a "stealth" way of DNS connectivity checking using Windows System Services (services.exe / svchost.exe) and if it is not controlled there is a possibility of covert channel creating.
Additional links:
SUBJECT: Microsoft SWI blog inaccuracies
Hello BugTraq
As you know, 3 weeks ago I published my paper, "Microsoft
Windows DNS Stub Resolver Cache Poisoning"
(http://www.trusteer.com/docs/Microsoft_Windows_resolver_DNS_cache_poisoning.pdf),
simultaneously with Microsoft's release of MS08-020
(http://www.microsoft.com/technet/security/Bulletin/MS08-020.mspx).
A day later, Microsoft's Secure Windows
Details
=======
SCCP and SIP-Related Vulnerabilities
* DNS Response Parsing Overflow
Cisco Unified IP Phone 7940, 7940G, 7960 and 7960G devices
running SCCP and SIP firmware contain a buffer overflow
vulnerability in the handling of DNS responses. A
specially-crafted DNS response may be able to trigger a buffer
Hello BugTraq
Recently I've been looking at the OpenBSD PRNG implementation for
DNS transaction ID (OpenBSD ported BIND 9 into their code tree,
but rolled their own PRNG for the DNS transaction ID field). I
discovered a serious weakness in OpenBSD's PRNG, which allows an
attacker to predict the next transaction ID (typically up to 8-10
guesses) given a series of consecutive 12-15 transaction IDs. As
you may appreciate, this enables DNS cache poisoning for OpenBSD
much like my earlier attacks on BIND 9, BIND 8 and Microsoft
Debian Security Advisory DSA-1619-2 security@debian.org
http://www.debian.org/security/ Devin Carraway
September 22, 2008 http://www.debian.org/security/faq
- ------------------------------------------------------------------------
Package : python-dns
Vulnerability : DNS response spoofing
Problem type : remote
Debian-specific: no
CVE Id(s) : CVE-2008-1447
Debian Bug : 490217
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:http://security.FreeBSD.org/>.
I. Background
BIND 9 is an implementation of the Domain Name System (DNS) protocols.
The named(8) daemon is an Internet Domain Name Server. DNS requests
contain a query id which is used match a DNS request with the response
and to make it harder for anybody but the DNS server which received the
request to send a valid response.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
http://security.gentoo.org/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Severity: Normal
Title: dnsmasq: Denial of Service and DNS spoofing
Date: September 04, 2008
Bugs: #231282, #232523
ID: 200809-02
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
---------- Forwarded message ----------
Date: Tue, 4 Dec 2007 00:56:51 -0600 (CST)
From: Gadi Evron <ge@linuxbox.org>
To: Rickard Dahlstrand <rickard.dahlstrand@iis.se>
Cc: dns-operations@mail.oarc.isc.org
Subject: Re: [dns-operations] Web Proxy Auto-Discovery (WPAD) Information
Disclosure
On Tue, 4 Dec 2007, Rickard Dahlstrand wrote:
> Gadi Evron wrote:
Hello BugTraq
Once again, a DNS cache poisoning against a popular DNS cache
server. This time, it's PowerDNS (the third most popular DNS
server, servicing over 40 million users). The vendor coded
several impressive security measures against DNS spoofing (e.g.
UDP source port randomization and spoofed response detection),
but relied on the standard C randomization facility (the rand()
and srand() functions in <stdlib.h>). The two popular stdlib
implementations analyzed, glibc (used with GNU C++ for Linux/
As I've mentioned in my first comment,
I agree that hostname/port binding to cert saving could
reduce such attacks like the one proposed by Nils.
> Of course, we're ignoring what I'd say is the fundamental problem with X509
> - a CA is either authoritative for the entire DNS namespace, or for
> nothing. I might want to trust the CA of the Israeli government for
> *.gov.il, but for a bank in Egypt? Not so much...
>
> Cheers
> Mark
This update upgrades the service console rpms for bind-utils and
bind-lib to version 9.2.4-22.el3.
Version 9.2.4.-22.el3 addresses the recently discovered
vulnerability in the BIND software used for Domain Name
resolution (DNS). VMware doesn't install all the BIND packages
on ESX Server and is not vulnerable by default to the reported
vulnerability. Of the BIND packages, VMware only ships bind-util
and bind-lib in the service console and these components by
themselves cannot be used to setup a DNS server. Bind-lib and
bind-util are used in client DNS applications like nsupdate,
essentially "resource-free" algorithm, at least against some of the
potential "attacks".
Not all attacks stand on their own. The ID behaviour is typically
part of the problem space that an attacker has to deal with when some
other DNS problem is being attacked.
The main problem space people are talking regards DNS servers. But
the same (or similar) algorithm can also be used in resolver libraries
(ie. inside libc) to deal with other (different or similar...)
potential "attacks".
> the reverse zone in sync with the forward zone. Thus I have my doubts
> that proper reverse mappings for every name will become common practice
> anytime soon.
True, but there are other reasons why this is not such hot idea, as
outlined in the IETF draft "Considerations for the use of DNS Reverse
Mapping"[1]:
3.2 Utility and effectiveness of some reverse mapping uses
Especially in the absence of strong anti-spoofing
Next Page>>
|
