[NEWS] The Art of Unspoofing
From: support@securiteam.comDate: 09/22/02
- Previous message: support@securiteam.com: "[NT] Cryptographic Flaw in RDP Protocol Can Lead to Information Disclosure"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: support@securiteam.com To: list@securiteam.com Date: Sun, 22 Sep 2002 20:42:08 +0200 (CEST)
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -
The Art of Unspoofing
------------------------------------------------------------------------
SUMMARY
The amount and frequency of denial of service attacks are escalating. It
is becoming harder to track down the source who initiates them due to
trace-evasion techniques. A raw interface to the networking stack allows
anyone to send spoofed packets to a target host, eliminating the ability
of its administrator to determine the origin of the attack. In today's
world of e-commerce and globalization, the devastating attacks and the
inability to determine their source can be devastating. It gives small
companies a bad name, and destroys the good reputations of larger
companies.
The ability to track down the source that uses spoofing techniques will
certainly increase the chance to catch those attacking, and will force
people to think of more intricate ways to attack servers on the net. This
paper describes a few ways to track down these sort of attacks up to the
last link in the chain (the attacker himself), or at least his ISP.
DETAILS
The Resolution Theory
The idea is simple. Usually, when a denial of service attack is initiated
against a target host, it is something like:
# ./attack target.com
In order to send the spoofed packets to target.com, the attacker's
nameserver has to resolve its domain name to an IP address, and only then
can it inject the malicious packets. In theory, the nameservers for
target.com will receive packets originating from the true source host of
the attack or their nameserver. If we keep a log of these DNS queries, we
could later cross-reference logs of the attack and the queries, look for
equal or very small differences in the timestamps, and in most cases, we
will have a certain match.
We must also be careful in what we do log; too much data can be just as
useless as not enough logging. If we just log all external hosts
attempting to resolve an internal host, this should cut down the amount of
possibilities considerably.
How does this help us trace the attacker? Assuming the attacker uses his
ISPs nameservers, we can tell his ISP from our logs, contact them, and
have them do the cross-referencing. In fact, once we have a source host,
we can contact its owners, and have them look at logs and do the
cross-referencing for the respective times of the attack.
In short: The host we have in our logs is either the attacker himself
doing the DNS query, or a nameserver he used to perform the query. In
either case, assuming proper logging is in place, we have the true source
of the attack.
The Connectivity and Routing Request Theory
Many attackers will check connectivity and routing of their target before
or after launching an attack. Most of the time this is done with
traceroute and ping. All we have to do is log incoming UDP packets on
ports 33434 to 33524, and ICMP echo packets. We can later use this data
along with the Bind resolution requests to cross-reference and find the
source of the attack.
Little Black Dots
We figured out this simple way of tracing spoofed packets after looking at
code of several of the most popular denial of service programs. Almost all
of the programs contain host-resolving code. Here are a few examples to
where gethostbyname() is used to query the nameservers defined in
/etc/resolv.conf to resolve the target host:
smurf.c: if ((he = gethostbyname(argv[1])) == NULL) {
bonk.c: res = gethostbyname (host_name);
land.c: if ((hoste = gethostbyname (land_host)) != NULL)
pepsi.c: hp = gethostbyname(cp);
Even though this method is effective, it might be a little difficult to
grep through the querying hosts on busy servers. There could be hundreds
of requests in just a few seconds, hence making it difficult to decide
which host is associated with the attacker.
To bypass, or at least avoid, this obstacle, we could take advantage of
the TTL field in the IP header. As you know, on every hop a packet passes,
its TTL is decreased by one. Most denial of service programs uses an
initial TTL of 255, which is also the default value of the TTL field for
outgoing packets on many IP stack implementations. Now let us say we have
received spoofed packets with TTL of 248, and 10 resolution requests at
the same time the attack started. We could traceroute to each of the hosts
that queried us, and count hops. It is very likely that there will be at
least one host that is located 7 hops from us (255 - 248), and is related
to the attack. Either way (IE: even if we get more than one host that is
seven hops away) this technique narrows down our search for the attacker.
This method is, as denial of service programs are becoming more
sophisticated over time, becoming less accurate -- for example, in a case
of a random TTL for each spoofed packet.
A Quick Note on Unspoofing and Nameserver Caching
ISC's BIND nameserver, like all nameservers, will cache data. Caching is
required for recursion, and is a great help in both DNS performance and
bandwidth savings. Unfortunately, this can potentially break unspoofing,
as the perpetrator of the denial of service attack may be using a
nameserver that has a cached record. For example, if the attacker was
using Earthlink, and wanted to attack www.cnn.com, it would be unlikely
that Earthlinks nameservers would query CNN's nameservers, as CNN is a
popular site that many people visit. While you cannot disable caching as
it is needed for recursion, you can limit it with the following options
(Bind 9 only): max-cache-ttl (Bind 9.X) and max-cache-size (Bind 9.2 and
up). Please consult the Bind Administrators manual for the proper usage of
these options.
Who Needs It?
Implementing this idea could be very useful in some places, but also
useless in others.
* ISPs -- ISPs who'd like to keep out of lawsuits against them and their
clients after a malicious user performed a denial of service attack. Also,
ISPs with little bandwidth who would like to make sure the available
bandwidth is put to good use, and not abused.
* Public DNS providers -- Today there are many public DNS services
providers. If malicious users would use their servers to initiate a denial
of service attack, they might be in danger of being shut down. It could be
for the best that they will know about the attackers as well.
* Companies -- Many companies today have their own nameservers for their
websites. They could use this technique to be able to track down attacks,
if any, that are performed on their networks and servers.
* Home users (*) -- Most, or pretty much all, of the home users do not
need to implement this technique. It is highly unlikely that their
computers will be used to resolve a target host.
* It is important to say that many different variations of UNIX (including
Linux, several BSD distributions, and others) come with a nameserver that
is working out-of-the-box. In these cases, a malicious attacker could use
the nameserver of an innocent victim as a bouncing point for his DNS query
-- making it contact the targets nameservers itself, thus avoiding of
being logged. If that is the case, the home user might want to either shut
down the DNS server or implement this method.
Proof of Concept
To implement this idea Sean and Brian have created patches for the most
popular freely available DNS server software -- ISC Bind. Diffs,
installation instructions, etc., are available at
<http://www.innu.org/~sean/patches/> http://www.innu.org/~sean/patches/.
Versions exist for 8.3.3 and 4.9.9 as of the writing of this article.
ADDITIONAL INFORMATION
The information has been provided by <mailto:sean@innu.org> Sean Trifero
and <mailto:brian@innu.org> Brian Knox.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: support@securiteam.com: "[NT] Cryptographic Flaw in RDP Protocol Can Lead to Information Disclosure"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
