James Kosin | 25 Jul 15:24
Favicon

DNS Attacks

Everyone,

The DNS attacks are starting!!!
Below is a snippet of a logwatch from last night.  Be sure all DNS 
servers are updated if at all possible.  The spooks are out in full on 
this security vulnerability in force.

THIS IS YOUR LAST WARNING...!!!
Patch or Upgrade NOW!

James Kosin
A long time Fedora / Redhat / Linux user

----

    client 143.215.143.11 query (cache) 'com/ANY/IN' denied: 30 Time(s)
    client 143.215.143.11 query (cache) 'gmail.com/ANY/IN' denied: 32 
Time(s)
    client 143.215.143.11 query (cache) 'hotmail.com/ANY/IN' denied: 31 
Time(s)
    client 143.215.143.11 query (cache) 'net/ANY/IN' denied: 30 Time(s)
    client 143.215.143.11 query (cache) 'nosuch.domain/ANY/IN' denied: 
30 Time(s)
    client 143.215.143.11 query (cache) 'search.live.com/ANY/IN' denied: 
30 Time(s)
    client 143.215.143.11 query (cache) 'www.ebay.com/ANY/IN' denied: 31 
Time(s)
    client 143.215.143.11 query (cache) 'www.facebook.com/ANY/IN' 
denied: 30 Time(s)
    client 143.215.143.11 query (cache) 'www.gmail.com/ANY/IN' denied: 
(Continue reading)

Jim van Wel | 25 Jul 16:30

Re: DNS Attacks

Zhe zombies are coming!!!! But we are all aware of this fact after release
of the patch ;)

Greetings,
Jim.

> Everyone,
>
> The DNS attacks are starting!!!
> Below is a snippet of a logwatch from last night.  Be sure all DNS
> servers are updated if at all possible.  The spooks are out in full on
> this security vulnerability in force.
>
> THIS IS YOUR LAST WARNING...!!!
> Patch or Upgrade NOW!
>
> James Kosin
> A long time Fedora / Redhat / Linux user
>
> ----
>
>     client 143.215.143.11 query (cache) 'com/ANY/IN' denied: 30 Time(s)
>     client 143.215.143.11 query (cache) 'gmail.com/ANY/IN' denied: 32
> Time(s)
>     client 143.215.143.11 query (cache) 'hotmail.com/ANY/IN' denied: 31
> Time(s)
>     client 143.215.143.11 query (cache) 'net/ANY/IN' denied: 30 Time(s)
>     client 143.215.143.11 query (cache) 'nosuch.domain/ANY/IN' denied:
> 30 Time(s)
>     client 143.215.143.11 query (cache) 'search.live.com/ANY/IN' denied:
(Continue reading)

James Kosin | 25 Jul 18:00
Favicon

Re: DNS Attacks

Jim van Wel wrote:
> Zhe zombies are coming!!!! But we are all aware of this fact after release
> of the patch ;)
> 
> Greetings,
> Jim.
> 

I know; but there is always somebody who always says, "It won't happen 
to me."  And sadly they usually never learn their lesson even if 
repeated multiple times.
I attached a snippet of a log to show how serious it really is.  The 
pishing people can use this as a back door to all web-sites.

All they have to do is find one site to push invalid DNS entries on 
others and the pollution begins.

James

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
ksh shrm | 25 Jul 18:07

Re: DNS Attacks

Is there anything we all care about.
We are normal users who don't have any server at home.

Just a PC with internet connection to surf.

adios

KSH SHRM

People don't care how much you know, until they know how much you care...

2008/7/25 James Kosin <jkosin <at> beta.intcomgrp.com>:
Jim van Wel wrote:
Zhe zombies are coming!!!! But we are all aware of this fact after release
of the patch ;)

Greetings,
Jim.


I know; but there is always somebody who always says, "It won't happen to me."  And sadly they usually never learn their lesson even if repeated multiple times.
I attached a snippet of a log to show how serious it really is.  The pishing people can use this as a back door to all web-sites.

All they have to do is find one site to push invalid DNS entries on others and the pollution begins.

James


--
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Mikkel L. Ellertson | 25 Jul 18:56
Favicon

Re: DNS Attacks

ksh shrm wrote:
> Is there anything we all care about.
> We are normal users who don't have any server at home.
> 
> Just a PC with internet connection to surf.
> 
> adios
> 
> KSH SHRM
> 
I guess there era a lot of abnormal users on this list them. And it 
is a concern even if you do not run a name server, because you could 
find yourself going to a web site other then the one you wanted.

Mikkel
-- 

A:  Because it messes up the order in which people normally read text.
Q:  Why is top-posting a bad thing?

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
bruce | 25 Jul 19:02
Favicon

RE: DNS Attacks

As I understand the issue. The issue is one of being able to poison the DNS
app on the DNS server. There's not really much the casual user can do, aside
from switching to another DNS/IP address that's safe. But the rub is, do you
really know if the DNS/IP you're switching to is safe!

The best approach, would probably be a system to allow you to poll a few DNS
servers, and to take the returned ip address that comes back from the most
of them as the "correct" ip address!! but this isn't implemented anywhere as
far as i know....

peace..

-----Original Message-----
From: fedora-list-bounces <at> redhat.com
[mailto:fedora-list-bounces <at> redhat.com]On Behalf Of Mikkel L. Ellertson
Sent: Friday, July 25, 2008 9:56 AM
To: For users of Fedora
Subject: Re: DNS Attacks

ksh shrm wrote:
> Is there anything we all care about.
> We are normal users who don't have any server at home.
>
> Just a PC with internet connection to surf.
>
> adios
>
> KSH SHRM
>
I guess there era a lot of abnormal users on this list them. And it
is a concern even if you do not run a name server, because you could
find yourself going to a web site other then the one you wanted.

Mikkel
--

A:  Because it messes up the order in which people normally read text.
Q:  Why is top-posting a bad thing?

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Les Mikesell | 25 Jul 19:23

Re: DNS Attacks

bruce wrote:
> As I understand the issue. The issue is one of being able to poison the DNS
> app on the DNS server. There's not really much the casual user can do, aside
> from switching to another DNS/IP address that's safe. But the rub is, do you
> really know if the DNS/IP you're switching to is safe!

If you are really paranoid (or about to do large transactions on what 
you hope is your banking site), you could do a 'whois' lookup for the 
target domain to find their own name servers and send a query directly 
there for the target site.

> The best approach, would probably be a system to allow you to poll a few DNS
> servers, and to take the returned ip address that comes back from the most
> of them as the "correct" ip address!! but this isn't implemented anywhere as
> far as i know....

dig @dns_server target_name
will send a query to a specified DNS resolver.  Most public-facing 
servers will only resolve the names of their own zones, especially now. 
  I think the current vulnerability only involves cached addresses for 
which the server is not primary or secondary.

-- 
   Les Mikesell
    lesmikesell <at> gmail.com

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

James Kosin | 25 Jul 19:47
Favicon

Re: DNS Attacks

Les Mikesell wrote:
> bruce wrote:
>> As I understand the issue. The issue is one of being able to poison 
>> the DNS
>> app on the DNS server. There's not really much the casual user can do, 
>> aside
>> from switching to another DNS/IP address that's safe. But the rub is, 
>> do you
>> really know if the DNS/IP you're switching to is safe!
> 
> If you are really paranoid (or about to do large transactions on what 
> you hope is your banking site), you could do a 'whois' lookup for the 
> target domain to find their own name servers and send a query directly 
> there for the target site.
> 
>> The best approach, would probably be a system to allow you to poll a 
>> few DNS
>> servers, and to take the returned ip address that comes back from the 
>> most
>> of them as the "correct" ip address!! but this isn't implemented 
>> anywhere as
>> far as i know....
> 
> dig @dns_server target_name
> will send a query to a specified DNS resolver.  Most public-facing 
> servers will only resolve the names of their own zones, especially now. 
>  I think the current vulnerability only involves cached addresses for 
> which the server is not primary or secondary.
> 
BUT, here is the really BAD news:
a)  99.9% of the internet is really a cached service.  The only true DNS 
entries are on the name servers that originated the DNS entry.  This is 
why when you put up a new domain they suggest waiting about 3-4 days for 
the internet to propagate the DNS names.  The information trickles down 
the DNS servers until everyone has the corrected information or update.

b)  If the DNS is corrupted you can't rely on the DNS resolver to be 
pointing to the correct IP.!!  You could be digging on the phishing site 
and they would be reporting false and bad information to you so they can 
scam you of your passwords and/or money.

James Kosin

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Les Mikesell | 25 Jul 20:40

Re: DNS Attacks

James Kosin wrote:

>>
>> If you are really paranoid (or about to do large transactions on what 
>> you hope is your banking site), you could do a 'whois' lookup for the 
>> target domain to find their own name servers and send a query directly 
>> there for the target site.
>>
>>> The best approach, would probably be a system to allow you to poll a 
>>> few DNS
>>> servers, and to take the returned ip address that comes back from the 
>>> most
>>> of them as the "correct" ip address!! but this isn't implemented 
>>> anywhere as
>>> far as i know....
>>
>> dig @dns_server target_name
>> will send a query to a specified DNS resolver.  Most public-facing 
>> servers will only resolve the names of their own zones, especially 
>> now.  I think the current vulnerability only involves cached addresses 
>> for which the server is not primary or secondary.
>>
> BUT, here is the really BAD news:
> a)  99.9% of the internet is really a cached service.  The only true DNS 
> entries are on the name servers that originated the DNS entry.  This is 
> why when you put up a new domain they suggest waiting about 3-4 days for 
> the internet to propagate the DNS names.  The information trickles down 
> the DNS servers until everyone has the corrected information or update.

The only real delay when adding something new is getting the registered 
servers for a domain into the root servers.  These should be the ones 
listed in the whois lookup.  There is a time-to-live associated with the 
addresses, so existing names may linger with the wrong addresses, though.

> b)  If the DNS is corrupted you can't rely on the DNS resolver to be 
> pointing to the correct IP.!!  You could be digging on the phishing site 
> and they would be reporting false and bad information to you so they can 
> scam you of your passwords and/or money.

They'd have to spoof several things at once to keep it from being 
obvious but you are right, the whois result will give names that you 
have to look up somehow.

-- 
   Les Mikesell
    lesmikesell <at> gmail.com

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Re: DNS Attacks


Les Mikesell <lesmikesell <at> gmail.com> writes:
> James> They'd have to spoof several things at once to keep it from being
> obvious but you are right, the whois result will give names that you
> have to look up somehow.

Go for the gusto.  Spoof the nameservers.  Why screw around?

-wolfgang
-- 
Wolfgang S. Rupprecht			http://www.wsrcc.com/wolfgang/

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Bruno Wolff III | 25 Jul 22:11

Re: DNS Attacks

On Fri, Jul 25, 2008 at 13:40:49 -0500,
  Les Mikesell <lesmikesell <at> gmail.com> wrote:
> James Kosin wrote:
>
> The only real delay when adding something new is getting the registered  
> servers for a domain into the root servers.  These should be the ones  

Generally you mean the appropiate TLD servers as most newly registered
domains don't go into the root servers.

> listed in the whois lookup.  There is a time-to-live associated with the  
> addresses, so existing names may linger with the wrong addresses, though.

And some ISPs have been known to fudge these to be longer than what they
are to cut down on queries. This breaks things like djbdns' feature of
having the ttl count down as a cutover time is approached.

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Les Mikesell | 25 Jul 22:26

Re: DNS Attacks

Bruno Wolff III wrote:
>>
>> The only real delay when adding something new is getting the registered  
>> servers for a domain into the root servers.  These should be the ones  
> 
> Generally you mean the appropiate TLD servers as most newly registered
> domains don't go into the root servers.

I guess things have changed - .com at least used to be known directly by 
the roots.  Anyway, a query for an unknown domain has to start at the 
root servers and will resolve as soon as they know where to send it.

>> listed in the whois lookup.  There is a time-to-live associated with the  
>> addresses, so existing names may linger with the wrong addresses, though.
> 
> And some ISPs have been known to fudge these to be longer than what they
> are to cut down on queries. This breaks things like djbdns' feature of
> having the ttl count down as a cutover time is approached.

And worse, applications may cache them for as long as they run.

-- 
   Les Mikesell
    lesmikesell <at> gmail.com

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

John Cornelius | 26 Jul 00:14

Re: DNS Attacks


Bruno Wolff III wrote:
> ------snip-----
> Generally you mean the appropiate TLD servers as most newly registered
> domains don't go into the root servers.
>
>   
Actually, I believe that they do but all that they do is provide a 
pointer to the appropriate name server for the domain. Perhaps that's 
what you meant but it didn't sound like it.
>> listed in the whois lookup.  There is a time-to-live associated with the  
>> addresses, so existing names may linger with the wrong addresses, though.
>>     
>
> And some ISPs have been known to fudge these to be longer than what they
> are to cut down on queries. This breaks things like djbdns' feature of
> having the ttl count down as a cutover time is approached.
>   

Indeed they do and it's tacky but what can you do?

--jc

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Bruno Wolff III | 26 Jul 05:48

Re: DNS Attacks

On Fri, Jul 25, 2008 at 15:14:15 -0700,
  John Cornelius <jc <at> hangarpilot.net> wrote:
>
>
> Bruno Wolff III wrote:
>> ------snip-----
>> Generally you mean the appropiate TLD servers as most newly registered
>> domains don't go into the root servers.
>>
>>   
> Actually, I believe that they do but all that they do is provide a  
> pointer to the appropriate name server for the domain. Perhaps that's  
> what you meant but it didn't sound like it.

No. The root servers have NS records for the TLD servers (some of which may
be on the same hardware as some root servers) and the TLD servers have NS
records for domains commonly registered. (Some domains are registered at
even lower levels, such as is common in several country code TLDs.)
The NS records include the name that points to the server that is authoritative
for that domain. (Though the domain pointed to may delegate that authority to
yet another server.) Along with the NS records a server being queried will
return glue records with the IP addresses of the servers being pointed to.
(The design of DNS isn't that great and the IP addresses really should have
been used in the NS records.) However, if the server being queried isn't
authoritative for the domain being pointed to you need to not trust that the IP
address applies for anything other than this query. (Some resolvers will
discard out of bailiwick glue records and you certainly don't want to cache
them where they could be used to resolve other queries.)

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Björn Persson | 25 Jul 20:13

Re: DNS Attacks

Les Mikesell wrote:
> If you are really paranoid (or about to do large transactions on what
> you hope is your banking site), you could do a 'whois' lookup for the
> target domain to find their own name servers and send a query directly
> there for the target site.

Check that the domain name in the address bar is right, that you're using 
HTTPS, and that the bank's certificate has been verified correctly. Then 
you're safe, unless the attacker has *also* managed to trick one of the 
certification authorities into issuing a false certificate, or somehow 
sneaked a false CA certificate into your browser.

Similarly for other protocols: Use TLS if the server's identity matters. This 
is what TLS is for. (Well, one of its two purposes.)

Björn Persson

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

bruce | 25 Jul 20:19
Favicon

RE: DNS Attacks

bjorn...

while what you say makes sense... the vast majority of people pop up their
favorite browser, and go to a site.. there's no way these guys (my mother
included) are going to get into the esoteric details of what goes on behind
the scenes for the browser/dns/certificates/etc...

it's up to the architects/developers to build a bullet proof (100%)
solution... it's ok to send me to a screwed up/fake flicker.com, not cool
for etrade.com...

peace

-----Original Message-----
From: fedora-list-bounces <at> redhat.com
[mailto:fedora-list-bounces <at> redhat.com]On Behalf Of Björn Persson
Sent: Friday, July 25, 2008 11:13 AM
To: For users of Fedora
Subject: Re: DNS Attacks

Les Mikesell wrote:
> If you are really paranoid (or about to do large transactions on what
> you hope is your banking site), you could do a 'whois' lookup for the
> target domain to find their own name servers and send a query directly
> there for the target site.

Check that the domain name in the address bar is right, that you're using
HTTPS, and that the bank's certificate has been verified correctly. Then
you're safe, unless the attacker has *also* managed to trick one of the
certification authorities into issuing a false certificate, or somehow
sneaked a false CA certificate into your browser.

Similarly for other protocols: Use TLS if the server's identity matters.
This
is what TLS is for. (Well, one of its two purposes.)

Björn Persson

--
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Björn Persson | 25 Jul 21:10

RE: DNS Attacks

bruce wrote:
> while what you say makes sense... the vast majority of people pop up their
> favorite browser, and go to a site.. there's no way these guys (my mother
> included) are going to get into the esoteric details of what goes on behind
> the scenes for the browser/dns/certificates/etc...

They aren't going to follow Les' advice and do whois lookups either. For those 
who do care about whose server they give their secrets to, TLS is a better 
solution than whois.

Oh, and please don't top-post.

Björn Persson

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Les Mikesell | 25 Jul 20:32

Re: DNS Attacks

Björn Persson wrote:
> 
>> If you are really paranoid (or about to do large transactions on what
>> you hope is your banking site), you could do a 'whois' lookup for the
>> target domain to find their own name servers and send a query directly
>> there for the target site.
> 
> Check that the domain name in the address bar is right, that you're using 
> HTTPS, and that the bank's certificate has been verified correctly. Then 
> you're safe, unless the attacker has *also* managed to trick one of the 
> certification authorities into issuing a false certificate, or somehow 
> sneaked a false CA certificate into your browser.

You aren't paranoid enough.  What if the spoofer is also a system 
administrator at the bank with access to a copy of the real certificate 
that he installs on the machine he's tricked your dns into reaching - 
with the expected name that you'll still see.

-- 
   Les Mikesell
    lesmikesell <at> gmail.com

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Björn Persson | 26 Jul 14:00

Re: DNS Attacks

Les Mikesell wrote:
> You aren't paranoid enough.  What if the spoofer is also a system
> administrator at the bank with access to a copy of the real certificate
> that he installs on the machine he's tricked your dns into reaching -
> with the expected name that you'll still see.

Then the bank has failed to protect its secret key. I expect banks to have 
rigorous security routines to control who can access sensitive systems, and 
to be able to check afterwards who did what.

Could you elaborate on how whois guards against malicious system 
administrators? Do you think security could be improved by having browsers 
and other programs make whois queries automatically?

Björn Persson

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Mikkel L. Ellertson | 26 Jul 15:00
Favicon

Re: DNS Attacks

Björn Persson wrote:
> Les Mikesell wrote:
>> You aren't paranoid enough.  What if the spoofer is also a system
>> administrator at the bank with access to a copy of the real certificate
>> that he installs on the machine he's tricked your dns into reaching -
>> with the expected name that you'll still see.
> 
> Then the bank has failed to protect its secret key. I expect banks to have 
> rigorous security routines to control who can access sensitive systems, and 
> to be able to check afterwards who did what.
> 
> Could you elaborate on how whois guards against malicious system 
> administrators? Do you think security could be improved by having browsers 
> and other programs make whois queries automatically?
> 
> Björn Persson
> 
Also, if it is the a system administrator at the bank, what is to 
prevent him from just changing the real name servers? Or putting in 
a program on the bank's web server to capture the username and 
password when you enter them? Lets face it, if a bank employee wants 
to embezzle money from the bank, there is not much we as costumers 
can do about it.

Mikkel
-- 

   Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
bruce | 26 Jul 17:15
Favicon

RE: DNS Attacks

but if a bank employee is involved in the taking of funds, then there is
somewhat of a trail. if the employee where to "change" the root dns servers,
there would be some trail of this with the service that the bank uses for
this setup.. this would be pretty easy to resolve, and the customer would
have protection (although suffer a hassle) as the bank would back up the
funds that were stolen...

the issue of dns poisoning would also be resolved in a matter of time, but
unfortunately, there might be multiple customers who are impacted...

after thinking on this for awhile, the only thing that i can really think of
to make a site "safe" is for you the customer to get your behind into a
physical setup/location/building when you initially setup the online
account!!! and then you should only use sites that incorporate multi-pass
(two factor) security processes. (although this has it's own set of
issues!!)

for my own $0.02 worth, i find myself going to different parts of a site to
see if i get links that return me back to where i should be prior to
inserting my login information... but this implies that you know what a
site's structure should be!

-----Original Message-----
From: fedora-list-bounces <at> redhat.com
[mailto:fedora-list-bounces <at> redhat.com]On Behalf Of Mikkel L. Ellertson
Sent: Saturday, July 26, 2008 6:01 AM
To: For users of Fedora
Subject: Re: DNS Attacks

Björn Persson wrote:
> Les Mikesell wrote:
>> You aren't paranoid enough.  What if the spoofer is also a system
>> administrator at the bank with access to a copy of the real certificate
>> that he installs on the machine he's tricked your dns into reaching -
>> with the expected name that you'll still see.
>
> Then the bank has failed to protect its secret key. I expect banks to have
> rigorous security routines to control who can access sensitive systems,
and
> to be able to check afterwards who did what.
>
> Could you elaborate on how whois guards against malicious system
> administrators? Do you think security could be improved by having browsers
> and other programs make whois queries automatically?
>
> Björn Persson
>
Also, if it is the a system administrator at the bank, what is to
prevent him from just changing the real name servers? Or putting in
a program on the bank's web server to capture the username and
password when you enter them? Lets face it, if a bank employee wants
to embezzle money from the bank, there is not much we as costumers
can do about it.

Mikkel
--

   Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Les Mikesell | 26 Jul 20:34

Re: DNS Attacks

Mikkel L. Ellertson wrote:
> 
>>> You aren't paranoid enough.  What if the spoofer is also a system
>>> administrator at the bank with access to a copy of the real certificate
>>> that he installs on the machine he's tricked your dns into reaching -
>>> with the expected name that you'll still see.
>>
>> Then the bank has failed to protect its secret key. I expect banks to 
>> have rigorous security routines to control who can access sensitive 
>> systems, and to be able to check afterwards who did what.

Yes, but controlling 'who does what' only works as long as the selected 
person does what you expect.  Are you following the case of the San 
Francisco network admin that refused to give the password to anyone 
else?  This may not even be malicious (he may just think everyone else 
would screw it up), but it isn't what anyone expected.

>> Could you elaborate on how whois guards against malicious system 
>> administrators?

It spreads the number of things that have to be compromised to fool you. 
The person who had access to copy the security certificate may not be 
the same one that registers the public DNS servers. Maybe it's a backup 
operator who knows how to restore a copy elsewhere

 >> Do you think security could be improved by having
>> browsers and other programs make whois queries automatically?

Slightly, but the DNS infrastructure probably would not handle having 
every query send to an authoritative source, which is why we have the 
caches that can be compromised in the first place.

> Also, if it is the a system administrator at the bank, what is to 

> prevent him from just changing the real name servers?

That's visible and would leave traces in obvious places.

 > Or putting in a
> program on the bank's web server to capture the username and password 
> when you enter them?

Likewise.

> Lets face it, if a bank employee wants to embezzle 
> money from the bank, there is not much we as costumers can do about it.

But you need to trust the combination of DNS and the target certificate. 
   If DNS can be compromised someone then only needs to have a copy of 
the certificate in a place that will be hard to find after the DNS cache 
expires.

-- 
   Les Mikesell
    lesmikesell <at> gmail.com

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Björn Persson | 26 Jul 22:07

Re: DNS Attacks

Les Mikesell wrote:
> Yes, but controlling 'who does what' only works as long as the selected
> person does what you expect.  Are you following the case of the San
> Francisco network admin that refused to give the password to anyone
> else?  This may not even be malicious (he may just think everyone else
> would screw it up), but it isn't what anyone expected.

I think I saw something about it. Relying entirely on one administrator is 
foolish even if he's guaranteed to never do anything malicious. There should 
always be some way for someone else to access the system in case the 
administrator suddenly dies for example.

> >> Could you elaborate on how whois guards against malicious system
> >> administrators?
>
> It spreads the number of things that have to be compromised to fool you.
> The person who had access to copy the security certificate may not be
> the same one that registers the public DNS servers.

OK, a slight improvement, but it still depends on the bank's security 
routines, just like the secrecy of the secret key does.

> Maybe it's a backup 
> operator who knows how to restore a copy elsewhere

Well, a backup copy of a secret key is just as secret as the "live" copy and 
must be protected by just as rigorous routines.

>  >> Do you think security could be improved by having
> >> browsers and other programs make whois queries automatically?
>
> Slightly, but the DNS infrastructure probably would not handle having
> every query send to an authoritative source, which is why we have the
> caches that can be compromised in the first place.

So doing that manually works for you only because most people don't do it?

> > Also, if it is the a system administrator at the bank, what is to
> > prevent him from just changing the real name servers?
>
> That's visible and would leave traces in obvious places.

As I already wrote, a bank should have things set up so that copying a secret 
key would also leave traces.

Björn Persson

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Les Mikesell | 26 Jul 22:40

Re: DNS Attacks

Björn Persson wrote:
> 
>>>> Could you elaborate on how whois guards against malicious system
>>>> administrators?
>> It spreads the number of things that have to be compromised to fool you.
>> The person who had access to copy the security certificate may not be
>> the same one that registers the public DNS servers.
> 
> OK, a slight improvement, but it still depends on the bank's security 
> routines, just like the secrecy of the secret key does.
> 
>> Maybe it's a backup 
>> operator who knows how to restore a copy elsewhere
> 
> Well, a backup copy of a secret key is just as secret as the "live" copy and 
> must be protected by just as rigorous routines.

Agreed, and this is probably is the case for banking institutions that 
only rarely lose control of a truckload of backup tapes.  But there are 
almost certainly places that have secure certificates that can't audit 
all the potential copies that might have been made.

>>  >> Do you think security could be improved by having
>>>> browsers and other programs make whois queries automatically?
>> Slightly, but the DNS infrastructure probably would not handle having
>> every query send to an authoritative source, which is why we have the
>> caches that can be compromised in the first place.
> 
> So doing that manually works for you only because most people don't do it?

Most internet operations aren't worth this tradeoff in trouble vs. 
security.  But if you have any reason to think your DNS is compromised, 
it might be worth an extra step before doing a secure transaction.

>>> Also, if it is the a system administrator at the bank, what is to
>>> prevent him from just changing the real name servers?
>> That's visible and would leave traces in obvious places.
> 
> As I already wrote, a bank should have things set up so that copying a secret 
> key would also leave traces.

If they haven't outsourced that job and left it up to someone else to 
comply.

-- 
    Les Mikesell
     lesmikesell <at> gmail.com

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Nifty Fedora Mitch | 27 Jul 05:28
Favicon

Re: DNS Attacks

On Fri, Jul 25, 2008 at 01:32:58PM -0500, Les Mikesell wrote:
> Björn Persson wrote:
>>
>>> If you are really paranoid (or about to do large transactions on what
>>> you hope is your banking site), you could do a 'whois' lookup for the
>>> target domain to find their own name servers and send a query directly
>>> there for the target site.
>>
>> Check that the domain name in the address bar is right, that you're 
>> using HTTPS, and that the bank's certificate has been verified 
>> correctly. Then you're safe, unless the attacker has *also* managed to 
>> trick one of the certification authorities into issuing a false 
>> certificate, or somehow sneaked a false CA certificate into your 
>> browser.
>
> You aren't paranoid enough.  What if the spoofer is also a system  
> administrator at the bank with access to a copy of the real certificate  
> that he installs on the machine he's tricked your dns into reaching -  
> with the expected name that you'll still see.
>

What does it take to collect 'correct' answers now and
then watch for poisioning and get it fixed promptly.

Banks and other key sites like google, yahoo, miscrosoft and many of
the big social network sites should be actively watching for abuse.
ISPs also need to watch their DNS servers and should be working with
the likes of Cert, the FBI etc. to nip this stuff in the bud should some
bad guys attempt to do bad stuff.   In the early days Universities were
central in keeping sanity on the early Internet perhaps they can also
pick up one of the balls in this game.

I have a very limited set of 'valuable' sites I connect with....  and have
already started caching key host IP addresses and DNS servers that I
believe I can rely on even when WiFI connected from the local coffee shop.

-- 
	T o m  M i t c h e l l 
	Looking for a place to hang my hat.

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Andrew Kelly | 28 Jul 10:58

Re: DNS Attacks


On Fri, 2008-07-25 at 13:32 -0500, Les Mikesell wrote:
> Björn Persson wrote:
> > 
> >> If you are really paranoid (or about to do large transactions on what
> >> you hope is your banking site), you could do a 'whois' lookup for the
> >> target domain to find their own name servers and send a query directly
> >> there for the target site.
> > 
> > Check that the domain name in the address bar is right, that you're using 
> > HTTPS, and that the bank's certificate has been verified correctly. Then 
> > you're safe, unless the attacker has *also* managed to trick one of the 
> > certification authorities into issuing a false certificate, or somehow 
> > sneaked a false CA certificate into your browser.
> 
> You aren't paranoid enough.  What if the spoofer is also a system 
> administrator at the bank with access to a copy of the real certificate 
> that he installs on the machine he's tricked your dns into reaching - 
> with the expected name that you'll still see.

Exactly.

I've made the decision to surf the Internet using only a sketch pad and
sticks of medium charcoal for the next several months, until this is all
resolved.
Last time something like this happened my cousin caught a trojan that
got into is toaster. It later grew and arm and stabbed him in the eye.

It was a big joke for a while (http://xkcd.com/293/) and eventually
attained urban myth status. But all myths have their basis in reality
and I was there for this one.

Remember, just because you're paranoid, doesn't mean your not in dire
need if immediate assistance from a mental health professional.

[sheesh]

Andy

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Tim | 28 Jul 12:51

Re: DNS Attacks

On Mon, 2008-07-28 at 10:58 +0200, Andrew Kelly wrote:
> I've made the decision to surf the Internet using only a sketch pad
> and sticks of medium charcoal for the next several months, until this
> is all resolved. Last time something like this happened my cousin
> caught a trojan that got into is toaster. It later grew and arm and
> stabbed him in the eye.

Hahaha...  I wonder what the internet fridge could get up to?

-- 
Don't send private replies to my address, the mailbox is ignored.  I
read messages from the public lists.

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Bruno Wolff III | 25 Jul 21:06

Re: DNS Attacks

On Fri, Jul 25, 2008 at 10:02:57 -0700,
  bruce <bedouglas <at> earthlink.net> wrote:
> As I understand the issue. The issue is one of being able to poison the DNS
> app on the DNS server. There's not really much the casual user can do, aside
> from switching to another DNS/IP address that's safe. But the rub is, do you
> really know if the DNS/IP you're switching to is safe!
> 
> The best approach, would probably be a system to allow you to poll a few DNS
> servers, and to take the returned ip address that comes back from the most
> of them as the "correct" ip address!! but this isn't implemented anywhere as
> far as i know....

You are better off running your own caching resolver than trying the above.

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Björn Persson | 25 Jul 20:12

Re: DNS Attacks

Mikkel L. Ellertson wrote:
> ksh shrm wrote:
> > Is there anything we all care about.
> > We are normal users who don't have any server at home.
>
> I guess there era a lot of abnormal users on this list them.

Yeah, I'm abnormal. And my DNS server is upgraded.

Björn Persson

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Bill Davidsen | 1 Aug 03:33

Re: DNS Attacks

ksh shrm wrote:
> Is there anything we all care about.
> We are normal users who don't have any server at home.
> 
> Just a PC with internet connection to surf.
> 
Then you are safe as long as you don't shop, bank, use a search engine, 
or ever provide any information of any nature you don't want to be 
public. And that includes the names of the sites you visit...

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Re: DNS Attacks


James Kosin <jkosin <at> beta.intcomgrp.com> writes:
>    client 143.215.143.11 query (cache) 'com/ANY/IN' denied: 30 Time(s)
>    client 143.215.143.11 query (cache) 'gmail.com/ANY/IN' denied: 32
> Time(s)
>    client 143.215.143.11 query (cache) 'hotmail.com/ANY/IN' denied: 31

Thanks for posting.  Maybe this will light a fire under the folks that
haven't upgraded yet.

Did you have to turn any extra logging on to get these message?

-wolfgang
-- 
Wolfgang S. Rupprecht			http://www.wsrcc.com/wolfgang/

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

James Kosin | 25 Jul 19:35
Favicon

Re: DNS Attacks

Wolfgang S. Rupprecht wrote:
> James Kosin <jkosin <at> beta.intcomgrp.com> writes:
>>    client 143.215.143.11 query (cache) 'com/ANY/IN' denied: 30 Time(s)
>>    client 143.215.143.11 query (cache) 'gmail.com/ANY/IN' denied: 32
>> Time(s)
>>    client 143.215.143.11 query (cache) 'hotmail.com/ANY/IN' denied: 31
> 
> Thanks for posting.  Maybe this will light a fire under the folks that
> haven't upgraded yet.
> 
> Did you have to turn any extra logging on to get these message?
> 
> -wolfgang
No, these are sent every day by logwatch.  I'm running a server 24/7; so 
logwatch runs as a cronjob.

But, the patches out don't fix the issue totally.  That would require a 
complete re-write of the DNS and how DNS works.  This is something 
already in the works.
The patch just makes it more difficult to trigger the issue.  I'm using 
the patched version of 9.4.2-P1.

Just look at your root email, if you check it or leave the computer ON 24/7.

James

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Re: DNS Attacks


James Kosin <jkosin <at> beta.intcomgrp.com> writes:
> But, the patches out don't fix the issue totally.  That would require
> a complete re-write of the DNS and how DNS works.  This is something
> already in the works.
> The patch just makes it more difficult to trigger the issue.  I'm
> using the patched version of 9.4.2-P1.

Thanks.  I'm running 9.5.0-P1 and haven't seen anything in my named or
system logs yet.  I guess I'm lucky. ;-) 

I have been looking since I just configured dnssec and was watching
for error messages.  (Using dnssec along with dlv.isc.org to find the
keys, seems to be as good a solution as today's DNS allows for.)

-wolfgang
-- 
Wolfgang S. Rupprecht			http://www.wsrcc.com/wolfgang/

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

DNS attacks


James Kosin posted a message on the fedora mailing list that he is
actually seeing DNS attack messages in his log files.  The message is
archived here: 

 http://permalink.gmane.org/gmane.linux.redhat.fedora.general/306278

Hopefully reports like this will get the folks to upgrade.

-wolfgang
--

-- 
Wolfgang S. Rupprecht			http://www.wsrcc.com/wolfgang/

Kevin Darcy | 26 Jul 01:00
Favicon

Re: DNS attacks

Wolfgang S. Rupprecht wrote:
> James Kosin posted a message on the fedora mailing list that he is
> actually seeing DNS attack messages in his log files.  The message is
> archived here: 
>
>  http://permalink.gmane.org/gmane.linux.redhat.fedora.general/306278
>
> Hopefully reports like this will get the folks to upgrade.
>   
It's definitely a probe of some kind, but AFAICT a bunch of repeated 
queries for a *small* number of names, isn't the attack profile 
associated with the Kaminsky exploit.

People should upgrade, of course. Even if the attacks aren't here yet, 
it's only a matter of time...

- Kevin

Michael Varre | 26 Jul 01:28

Re: DNS attacks

Sorry I meant to reply to all. What is the attack profile for this?

On 7/25/08, Kevin Darcy <kcd <at> chrysler.com> wrote:
> Wolfgang S. Rupprecht wrote:
>> James Kosin posted a message on the fedora mailing list that he is
>> actually seeing DNS attack messages in his log files.  The message is
>> archived here:
>>
>>  http://permalink.gmane.org/gmane.linux.redhat.fedora.general/306278
>>
>> Hopefully reports like this will get the folks to upgrade.
>>
> It's definitely a probe of some kind, but AFAICT a bunch of repeated
> queries for a *small* number of names, isn't the attack profile
> associated with the Kaminsky exploit.
>
> People should upgrade, of course. Even if the attacks aren't here yet,
> it's only a matter of time...
>
> - Kevin
>
>
>

--

-- 
Sent from Gmail for mobile | mobile.google.com

mv
315.952.5753

Kevin Darcy | 26 Jul 01:46
Favicon

Re: DNS attacks


I don't know that it would be appropriate for me to say any more than 
that, since the details of the exploit have not yet been "officially" 
disclosed.

                                                                   - Kevin

Michael Varre wrote:
> Sorry I meant to reply to all. What is the attack profile for this?
>
>
>
> On 7/25/08, Kevin Darcy <kcd <at> chrysler.com> wrote:
>   
>> Wolfgang S. Rupprecht wrote:
>>     
>>> James Kosin posted a message on the fedora mailing list that he is
>>> actually seeing DNS attack messages in his log files.  The message is
>>> archived here:
>>>
>>>  http://permalink.gmane.org/gmane.linux.redhat.fedora.general/306278
>>>
>>> Hopefully reports like this will get the folks to upgrade.
>>>
>>>       
>> It's definitely a probe of some kind, but AFAICT a bunch of repeated
>> queries for a *small* number of names, isn't the attack profile
>> associated with the Kaminsky exploit.
>>
>> People should upgrade, of course. Even if the attacks aren't here yet,
>> it's only a matter of time...
>>
>> - Kevin
>>
>>
>>
>>     
>
>   

Kevin Darcy | 26 Jul 01:57
Favicon

Re: DNS attacks

Allow me to clarify that a bit: there's a fine line here between giving 
enough information to administrators to allow them to identify 
_bona_fide_ Kaminsky-style attacks, on the one hand, and, on the other, 
giving yet more information to the would-be perpetrators of such attacks.

If you *really* need to know what the attack looks like, and you can 
read code at all, attack code has already been published, so you should 
be able to figure out the profile yourself.

                                                                         
                                    - Kevin

Kevin Darcy wrote:
> I don't know that it would be appropriate for me to say any more than 
> that, since the details of the exploit have not yet been "officially" 
> disclosed.
>
>                                                                    - Kevin
>
>
> Michael Varre wrote:
>   
>> Sorry I meant to reply to all. What is the attack profile for this?
>>
>>
>>
>> On 7/25/08, Kevin Darcy <kcd <at> chrysler.com> wrote:
>>   
>>     
>>> Wolfgang S. Rupprecht wrote:
>>>     
>>>       
>>>> James Kosin posted a message on the fedora mailing list that he is
>>>> actually seeing DNS attack messages in his log files.  The message is
>>>> archived here:
>>>>
>>>>  http://permalink.gmane.org/gmane.linux.redhat.fedora.general/306278
>>>>
>>>> Hopefully reports like this will get the folks to upgrade.
>>>>
>>>>       
>>>>         
>>> It's definitely a probe of some kind, but AFAICT a bunch of repeated
>>> queries for a *small* number of names, isn't the attack profile
>>> associated with the Kaminsky exploit.
>>>
>>> People should upgrade, of course. Even if the attacks aren't here yet,
>>> it's only a matter of time...
>>>
>>> - Kevin
>>>
>>>
>>>
>>>     
>>>       
>>   
>>     
>
>
>
>
>   

Graeme Fowler | 26 Jul 13:42

Re: DNS attacks

On Fri, 2008-07-25 at 09:46 -0700, Wolfgang S. Rupprecht wrote:
> James Kosin posted a message on the fedora mailing list that he is
> actually seeing DNS attack messages in his log files.  The message is
> archived here: 
> 
>  http://permalink.gmane.org/gmane.linux.redhat.fedora.general/306278

...if you look at the addresses in use there, and you look in your logs
and see the same thing, you might find some interesting queries which
make it pretty obvious what those queries are for. They're not
malicious; they're not an attack; they're data collection.

I emailed Dan Kaminsky about this and he told me

> That's the scan that's finding patches.

I've just asked for a bit of clarification on this; the pattern of the
queries is interesting - those who have the same type of queries in
their logs might take note of the unchanging source port...

The sky isn't falling... yet.

Graeme

Bill Davidsen | 1 Aug 03:38

Re: DNS Attacks

James Kosin wrote:
> Everyone,
> 
> The DNS attacks are starting!!!
> Below is a snippet of a logwatch from last night.  Be sure all DNS 
> servers are updated if at all possible.  The spooks are out in full on 
> this security vulnerability in force.
> 
> THIS IS YOUR LAST WARNING...!!!
> Patch or Upgrade NOW!
> 
Then test your connection, because some providers like Verizon NAT your 
packets to all use the same port, even with the patch in place. I did 
check, thankfully, and now have a bunch of entries for critical stuff in 
my internal files.

--

-- 
fedora-list mailing list
fedora-list <at> redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list


Gmane