Message-ID: <6b6aef210512150857i41f853bfi1f180b79acc9f8b7@mail.gmail.com>
Date: Thu, 15 Dec 2005 11:57:00 -0500
From: Synister Syntax <synistersyntaxlist@...il.com>
To: bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk, 
	vuln-dev@...urityfocus.com, NTBUGTRAQ@...tserv.ntbugtraq.com
Subject: Re: RLA ("Remote LanD Attack")

To All:

     As requested:
MSWord (.doc):  http://www.teamtrinix.com/exploits/rla/RLA.doc
Plain Text (.txt):  http://www.teamtrinix.com/exploits/rla/RLA.txt
HTML: http://www.teamtrinix.com/exploits/rla/RLA.htm
PDF;  (Coming Soon)

     I will go ahead and create the PDF later this evening.  The HTML
version is by far the best in my opinion.  Feel free to share, link,
re-upload, etc.  But please do not edit any of the content.  Thanks...

On 12/15/05, Synister Syntax <synistersyntaxlist@...il.com> wrote:
>      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)
>


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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists