Message-ID: <6b6aef210512150814u32ce7d59x9bd208392ddbe750@mail.gmail.com>
Date: Thu Dec 15 16:15:02 2005
From: synistersyntaxlist at gmail.com (Synister Syntax)
Subject: Re: RLA ("Remote LanD Attack")

     Agreed, this and all attacks like this, fall under DoS.  The
reason I originally classified this attack as a Remote LanD, was I was
originally testing a un-patched Windows SP2 machine, locally, and of
course watching the box lock up for 30 seconds or so.  I then thought,
there has to be a way for this to work remotely.  I started testing,
this was about four (4) months ago.  I knew then that it worked, but I
really wanted to find out what devices are susceptible to such
attacks.  I knew it, seeing as it was both the Linksys and Westell it
was more then just two vendors.

     So, from there I just called it Remote LanD attack.  As I
literally just tried sending LanD packets across the Internet.  (To a
second party who was helping me test the exploit/vuneribity.  I did in
fact have permission, with all the test I performed.)  It was then I
discovered the packets were lagging my colleges network.  I started
messing with an array of flag combinations, almost all caused some
reaction, mainly latency.  I then found the ASPU combination which
caused the most damage.

     Thanks :-) I really took the time to make this write-up organized
and understandable.   Hopefully the device vendors can more from here
and fix the problem, a simply drop of LanD packets would do it.

     Again, thanks for you comments.  If you have have anything else,
please feel free to reply.

On 12/15/05, service pack <sppride@...il.com> wrote:
> yeah i mean there is a fine line between the two. Sans has a good definition
> as well
>
>  A packet that causes problems by having the same source and destination
> (the target of course).
>
>  I still think of it as more if a talking yourself to death attack :)
>
>  They all fall under the umbrella of denial of service though.
>
>  Good write up I just thought the part about land was worded a little funny,
> or was lacking.
>
>  Thanks
>  SP
>
>
> On 12/15/05, Synister Syntax <synistersyntaxlist@...il.com> wrote:
> >      I agree that this is in fact a DoS, however it is using the old
> > LanD attack (from 1997) syntax/style.  That fact that it is a packet
> > to itself, from it's self, obviously spoofed.  As this was the same
> > way it was done back in the 90's.  The difference here, is the fact
> > that the LanD attack can be performed remotely, whereas before the
> > attack was only a Local (LAN) attack.
> >
> >      Also note that this is an attack on devices, not OS's.  Also let
> > me note that the device is unusable until it is physically reset.
> > Eitherway, I am fine by this being consedered a DoS, it is.  It will
> > shut doen your switch (rendering your network usaless) or your router
> > (keeping you from access the internet etc.).
> >
> > If you have any other questions, or comments please let me know.
> > Thanks for the input, I think I did infact not state that the attack
> > was a DoS.
> >
> > On 12/15/05, service pack <sppride@...il.com> wrote:
> > > Updated the wiki page. Your looking at a denial of service not a land
> > > attack.
> > >
> > >  Land attacks are caused when a machine floods itself.
> > >
> > >  First example,  Echo and Chargen (ICMP and Character generator (old
> unix
> > > service)) Are services that reply to anything.
> > >  A spoofed packet is sent from a machines echo (spoofed) to the chargen.
> The
> > > chargen replys with garbage, and the echo echo's it
> > >  back and so on until the resources are consumed.
> > >
> > >  Anything that doesn't have this effect is a Denial of service.
> > >
> > >  Now SNMP and windows Kerberos can talk themselves to death (an example
> of a
> > > non-cross service land).
> > >
> > >  Makes sense? :)
> > >
> > >  SP
> > >
> > >
> > > On 12/14/05, Synister Syntax < synistersyntaxlist@...il.com> wrote:
> > > > Below is a copy of my RLA exploit submission in ASCII.  Attached is a
> > > > MSWord (.doc) version with rich formatting, created with ease of view
> > > > in mind.
> > > >
> > > > Regards...
> > > >
> > > > ----------
> > > >
> > > > RLA
> > > > ("Remote LanD Attack")
> > > > 2005
> > > >
> > > >
> > > > As discovered by:
> > > > Justin M. Wray
> > > > (jayizkool@...il.com)
> > > >
> > > >
> > > > Devices/Vendors Vulnerable:
> > > > - Microsoft Windows XP, SP1 and SP2
> > > > - Linksys Routers
> > > > - Westell Routers/Modems
> > > > - Motorola Modems/Routers
> > > > - Cisco Firewalls, Switches, and Routers
> > > > - DSL Modems
> > > > - Cable Modems
> > > > - Consumer Routers
> > > > - All Central Connectivity Devices (any manufacturer)
> > > >
> > > > Devices/Vendors Tested:
> > > > - Linksys BEFW11S4
> > > > - Linksys WRT54GS
> > > > - Westell  Versalink 327W (Verizon Modem)
> > > > - Cisco Catalyst Series (Multiple)
> > > > - Scientific Atlantic DPX2100 (Comcast Modem)
> > > >
> > > > Definition:
> > > > A LAND attack is a DoS (Denial of Service) attack that consists of
> > > > sending a special poison spoofed packet to a computer, causing it to
> > > > lock up. The security flaw was first discovered in 1997 by someone
> > > > using the alias "m3lt", and has resurfaced many years later in
> > > > operating systems such as Windows Server 2003 and Windows XP SP2.
> > > > (http://en.wikipedia.org/wiki/LAND_attack)
> > > >
> > > > Explanation of LanD:
> > > > LanD uses a specially crafted ICMP  echo packet which has the same
> > > > source and destination address.  The receiving system stalls due to
> > > > the erroneous packet and not having instructions to handle the unique
> > > > packet.  In Windows 9x  variants, the systems will "blue screen. "  On
> > > > modern NT  variants, the systems will hang for approximately 30
> > > > seconds with full CPU usage before discarding the packet.  With a
> > > > looped script, the attacker can render the system useless.  UNIX
> > > > variants have been able to use a firewall rule to drop LanD packets ?
> > > > leaving most systems patched.
> > > >
> > > > Microsoft originally released an initial patch that secured Windows 9x
> > > > variants ? causing the exploit to lose popularity and become somewhat
> > > > obscure.  Later, when Windows NT variants were released, Microsoft
> > > > neglected to patch the security flaw; this caused Windows XP Service
> > > > Pack 2 to remain susceptible to such an attack.  Within the last four
> > > > (4) months, Microsoft has released a patch for Windows NT variants.
> > > >
> > > > LanD versus Remote LanD:
> > > > LanD was originally introduced in the late 1990s and was very popular
> > > > with educational and business networks.  The original LanD attack had
> > > > to be executed internally on the local network ? thereby giving rise
> > > > to the name "LanD" (indicating that access has been granted to the
> > > > local premises).  However, with a remote attack (Remote LanD),
> > > > crafting special packets and spoofing the destination and source IP
> > > > addresses will cause the attack to be carried out remotely against the
> > > > central connectivity device.
> > > >
> > > > Exploit / Proof of Concept:
> > > > There is no handwritten code needed to exploit this vulnerability.
> > > > The only requirement is an IP packet creation utility (such as HPing2
> > > > or IPSorcery). Below are some HPing2 examples:
> > > >                 Victim's IP Address: 63.24.122.59
> > > >                 Victim's Router IP Address: 192.168.1.1
> > > >                 hping2 -A -S -P -U 63.24.122.59 -s 80 -p 80 -a
> 192.168.1.1
> > > >
> > > > Remote LanD Specifications:
> > > > Although the exploit will work without the Ack, Syn, Push, and Urg
> > > > (flags), the device does not seem to shut off without these flags.
> > > > Sending just the LanD part of the packet seems to only create high
> > > > amounts of latency on the victim's end.  The spoofed source address
> > > > must be the address of the central connectivity device; although the
> > > > normal default is 192.168.1.1, some manufacturers use different
> > > > addresses (such as 192.168.1.100 or 192.168.0.1).  As a result, the IP
> > > > address should be checked prior to initiating any test.  Additionally,
> > > > a broadcast address will work for a source address as well, thereby
> > > > flooding the network with responses from all the machines connected to
> > > > the network.  Although it will not stale the Central Connectivity
> > > > Device, it will maximize the entire network usage - crippling the
> > > > network with extremely high latency.
> > > >
> > > > Test Environment:
> > > >
> > > > - Test One
> > > >   - Attacker:  hping2 on Comcast Cable connection behind Linksys
> Router
> > > >   - Victim:  DSL Modem/Router on Verizon DSL connection
> > > >
> > > > - Test Two
> > > >   - Attacker:  hping2 on Comcast Cable connection behind Linksys
> Router
> > > >   - Victim:  Linksys Router on Comcast Cable connection
> > > >
> > > > - Test Three
> > > >   - Attacker:  hping2 on Comcast connection behind Linksys Router
> > > >   - Victim:  Comcast Cable Modem
> > > >
> > > > - Test Four
> > > >   - Attacker:  hping2 on Comcast connection behind Linksys Router
> > > >   - Victim:  Cisco Router on T1 connection
> > > >
> > > > - Test Five
> > > >   - Attacker:  hping2 on Comcast connection behind Linksys Router
> > > >   - Victim:  Cisco Pix Firewall, on T1 connection
> > > >
> > > > Test Results:
> > > >
> > > > Test One:
> > > > Connection Latency - followed by the modem physically turning off.
> > > > Time elapsed: approximately 10 seconds (from beginning of packet
> > > > flooding to complete shutdown).
> > > >
> > > > Test Two:
> > > > Connection Latency, router reset, then connection lost.  Reset needed
> > > > before router would communicate online again.
> > > >
> > > > Test Three:
> > > > Modem lights flickered; the modem lost connection and sat with the
> > > > Data light completely out.
> > > >
> > > > Test Four:
> > > > Router lost connection to the internet.
> > > >
> > > > Test Five:
> > > > Firewall lost network connection.
> > > > Conclusion:
> > > > It appears that central connectivity device manufacturers need to
> > > > release firmware updates and/or patches to protect against LanD and
> > > > remote LanD attacks. The LanD attack is no longer simply a local
> > > > attack but has now evolved into having the capability of being
> > > > launched remotely.
> > > >
> > > > Acknowledgements:
> > > > - Casey O'Brien, M.S.
> > > >   - Assisted with test trials
> > > > - Matthew Wines
> > > >   - Assisted with test trials
> > > > - Yvonne M. Wray, M.S.
> > > >   - Report editor
> > > >
> > > > Submitted: 12/14/2005 by Justin M. Wray
> > > >
> > > > --
> > > > Regards,
> > > > SynSyn
> > > > Netowork Manager, Server Administrator, Security Specialist
> > > > ( http://www.teamtrinix.com)
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > ------------------------------
> > > www.trustedmatrix.org
> >
> >
> > --
> > Regards,
> > SynSyn
> > Netowork Manager, Server Administrator, Security Specialist
> > (http://www.teamtrinix.com)
> >
>
>
>
>  --
> ------------------------------
> www.trustedmatrix.org


--
Regards,
SynSyn
Network Manager, Server Administrator, Security Specialist
(http://www.teamtrinix.com)

Powered by blists - more mailing lists