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)