[Full-disclosure] 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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx)
> > > > >
> > > > >
> > > > > 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/


Relevant Pages

  • Re: RLA ("Remote LanD Attack")
    ... from there I just called it Remote LanD attack. ... a simply drop of LanD packets would do it. ...
    (Bugtraq)
  • [Full-disclosure] Re: RLA ("Remote LanD Attack")
    ... Agreed, this and all attacks like this, fall under DoS. ... from there I just called it Remote LanD attack. ...
    (Full-Disclosure)
  • [Full-disclosure] RE: RLA ("Remote LanD Attack")
    ... so that people don't think this affects Windows XP SP2. ... and the LAND attack no longer works. ... hping2 on Comcast Cable connection behind Linksys Router ...
    (Full-Disclosure)
  • RE: RLA ("Remote LanD Attack")
    ... so that people don't think this affects Windows XP SP2. ... and the LAND attack no longer works. ... hping2 on Comcast Cable connection behind Linksys Router ...
    (Bugtraq)
  • Re: RLA ("Remote LanD Attack")
    ... LanD attack syntax/style. ... > A spoofed packet is sent from a machines echo to the chargen. ... >> Connection Latency - followed by the modem physically turning off. ...
    (Bugtraq)