To All:
As requested:MSWord (.doc): http://www.teamtrinix.com/exploits/rla/RLA.docPlain Text (.txt): http://www.teamtrinix.com/exploits/rla/RLA.txtHTML: http://www.teamtrinix.com/exploits/rla/RLA.htmPDF; (Coming Soon)
I will go ahead and create the PDF later this evening. The HTMLversion 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,SynSynNetwork Manager, Server Administrator, Security Specialist(http://www.teamtrinix.com)
