[LINK] It pays to read CERT advisories

[Chirgwin, Richard]

Glen et al

I will admit, without shame, that I probably don't understand TCP/IP well
enough to dissect this issue without help (I'll flatter myself however that
I'm better than a Reuters drone!).

Rather than ask a series of questions, I'm going to make a bunch of
statements. I invite correction; make it as brutal as you wish!

1) TCP RST/SYN attacks interrupt sessions, they don't reboot routers.

The reason this matters is that much of the Ignomerican tech press has made
this mistake. A router only restarts itself if the attacks happen often
enough to cause serious corruption in the route table.

2) TCP RST attacks are not specific to routers. Again, this is for
clarification: much of the reporting has treated it as router-specific
(Google News likes "Cisco Vulnerable" headline better than "TCP RST/SYN
Advisory").

3) RST and SYN attacks are only one of a general class of behaviours which
can upset routers. However, attacking a router is (to a degree)
self-defeating, because the attacker can easily find his own connection
"blacked out".

That's because I can only attack a session I can "see". A BGP session
between (say) a BT router in London and a Sprint router in New York is not
trivial to discover, if I am a BigPond user in Sydney. The solo attack has
limited reach. If a section of the network were successfully attacked, then
everything on the "far" side of the attack vector becomes invisible to the
attacker.

4) Therefore, a widespread attack would need:
- a Trojan capable of discovering BGP sessions, identifying the relevant
session information (for example the TCP window ID), and spoofing the right
IP address to have an RST accepted; and
- distribution of that Trojan on a wide scale, because the zombie machines
are likely to black out their own routes.

5) The symptoms of a widespread exploit, it seems to me, would be route
disruption, occurring in contracting "circles" which converge towards the
attack vector. A "zombie" in (say) Sydney manages to knock out a route; it
has no access to the "blacked out" networks, so its next attack must be
closer to home; if successful, its range shrinks again; and so on.

6) One task which may be too hard for a Trojan would be identifying
"valuable" routes (ie BGP sessions with greater impact than merely hammering
the nearest edge router). Even if the attack were executed by a user, the
backboune routes of greatest importance are also the most-managed. A serious
route - Telstra to Optus - is a long way from an attacker.

7) The most effective attack is as a man-in-the-middle. A corrupt employee
in a large ISP network has the greatest visibility of important devices,
sessions, and packet data (address etc). This is a more credible attack
vector than a stereotypical black-hat-teenage-cracker-in-the-bedroom.

I'm wearing the flameproof suit; fire away!

Richard Chirgwin

> -----Original Message-----
> From: Glen Turner [mailto:glen.turner at aarnet.edu.au] 
> Sent: Wednesday, April 21, 2004 3:54 PM
> To: Roger Clarke
> Cc: link at anu.edu.au
> Subject: Re: [LINK] It pays to read CERT advisories
> 
> 
> Roger Clarke wrote:
> > 
> > At *last*, a CERT author with a sense of humour:
> > 
> > From:
> >                 AL-2004.12 -- AusCERT ALERT
> >                         Vulnerability Issues in TCP
> >                     NISCC Vulnerability Advisory 236929
> >                                21 April 2004
> > 
> > "If exploited, the vulnerability could allow an attacker to 
> create a Denial
> > of Service condition against existing TCP connections, resulting in
> > premature session termination. The resulting session 
> termination will
> > affect the application layer, ...".
> 
> The CERT person is probably bemused.  I was.
> 
> The ability of a spoofed reset packet to close a connection
> has long been known.
> 
> It has concerned network operators for a long time, so much
> so that there are two RFCs -- TCP MD5 checksum (very old,
> most routers have it) and Generalised TTL Security (new,
> just in shipping equipment now) -- to address the issue.
> The MD5 checksum is in wide deployment.
> 
> When AARNet BGP peer with people we are inistent about
> running MD5 authentication. A few peers (who I won't name)
> refused to configure it.  All of those have contacted
> us this morning to turn it on.  If I'd known all it would
> take is a Security Advisor to result in a managerial
> direction...
> 
> BGP is particularly vulnerable because it assigns
> a dramatic semantic meaning when a session is RST --
> that routes learned through that connection should
> be removed.  Most application protocols don't assign
> such a dramatic meaning -- for example, a web session
> might partially display an image or text, something
> easily fixed with the Refresh button.
> 
> Non-BGP protocols will probably need to wait for
> IPSec to be available on a wide range of hosts
> before they are protected.  Although IPSec has
> problems of its own which make wide deployment
> an interesting challenge.
> 
> The original securtity advisory has many errors
> (especially in the vendor list, Juniper for one
> should be most upset).  It fails to mention the
> most effective response -- wide deployment of
> source address checking.
> 
> _______________________________________________
> Link mailing list
> Link at mailman.anu.edu.au
> http://mailman.anu.edu.au/mailman/listinfo/link
>