[Full-disclosure] Re: RLA ("Remote LanD Attack")



Not a problem at all Roger. I agree, its a bit shocking, by I am
far less concerned about the Cisco devices and/or business networks.
What I am concerned over is consumer grade products, that do not
enforce all the RFC's. That lack security against spoofed packets,
and spoofed internal address on the external interface. Network
administrators for business will usually have such a rule set that
will keep them from being vulnerable of such an attack, if not, I hope
they will now set a rule, but Joe Smith and his $15 Verizon router
will have no clue what a packet is, let alone the RFC's. With such
devices being susceptible to attack, and with the delay in user
patches, or firmware updates.

I think it is such users we need to worry about, they have no
recourse. The devices will shut off. That's why I am hoping that the
vendors will release patches/updates.

As far as Win2K3, again, I am not sure, it was brought up in a
privet email about this exploit. And it was simply brought up to see
if what I released was related to that CVE. Of course they are
related in the fact they are LanD attacks, but mine is different in
many ways, (one, mines remote [outside networks], and two, my exploit
is for devices only). I do not have a of Win2K3 to even test. Sorry
if bringing it up has cause any more confusion.

By all means, if you have any further questions, I would be glad
to answer them. Again, thanks for your input and interests.

Thanks...

On 12/15/05, Roger A. Grimes <roger@xxxxxxxxxxxxxx> wrote:
> I appreciate you writing back. I'm not quarreling with what you wrote. A
> LAND attack being successful on a Cisco device is quite surprising. I
> tried a Syn LAND attack on my W2K3 server without WF enabled and it
> didn't do anything. I'm not sure what that reference is referring to.
>
> -----Original Message-----
> From: Synister Syntax [mailto:synistersyntaxlist@xxxxxxxxx]
> Sent: Thursday, December 15, 2005 5:11 PM
> To: Roger A. Grimes
> Subject: Re: RLA ("Remote LanD Attack")
>
> Here is the CVE I was referring to: *CVE-2005-0688*
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0688
>
> Again, my exploit has nothing to do with the CVE (MS Windows 2K3)
> exploit, and I am in no way stating such systems are susceptible. My
> reports are about Network Devices, namely Border/Perimeter devices
> (Routers, Modems, Switches, Firewalls). Hope this helps.
>
> Thanks...
>
> On 12/15/05, Roger A. Grimes <roger@xxxxxxxxxxxxxx> wrote:
> > I just tried it against W2K3 SP1 and it does not work. I don't have a
> > non-SP1 version to check at the moment.
> >
> > -----Original Message-----
> > From: Synister Syntax [mailto:synistersyntaxlist@xxxxxxxxx]
> > Sent: Thursday, December 15, 2005 2:32 PM
> > To: Roger A. Grimes
> > Subject: Re: RLA ("Remote LanD Attack")
> >
> > Sorry had a few spelling errors...
> >
> > Fixed below....
> >
> > " That is correct this affects network perimeter devices, such as
> > routers, switches, etc. This is not an accountant about an OS
> exploit.
> > Although Microsoft only recently patched the initial exploit, it is
> > patched for both external and internal attacks.
> > Windows 2003 may still be susceptible to such an attack, however that
> > is a different post, under CVE investigation, this has nothing to do
> > with such an exploit.
> >
> > I used the -k switch a few, times although, it seemed to work
> > either way. Although, to make sure it works, it would be best to use
> > such a switch. Also, I wanted to point out, using the -d switch and
> > increasing the data/payload size seems to cause the attack to be more
> optimized.
> > Works faster in some cases. It will work either way.
> > --
> > Regards,
> > SynSyn
> > Network Manager, Server Administrator, Security Specialist
> > (http://www.teamtrinix.com)"
> >
> > On 12/15/05, Synister Syntax <synistersyntaxlist@xxxxxxxxx> wrote:
> > > That is correct this affects network perminter devices, such as
>
> > > routers, switches, etc. This is not an accounment about an OS
> > > exploit. Although Microsoft only recently patched the initial
> > > exploit, it is patched for both external and internal attacks.
> > > Windows 2003 may still be susecpitble to such an attack, however
> > > that is a diffrent post, under CVE invesigation, this has nothing to
>
> > > do with such an exploit.
> > >
> > > I used the -k switch a few, times although, it seemed to work
> > > eitherway. Although, to make sure it workes, it would be best to
> > > use such a switch. Also, I wanted to point out, using the -d switch
>
> > > and increaseing the data/payload size seems to cause the attack to
> > > be more
> >
> > > optimiozed. Workes faster in some cases. It will work eitherway.
> > >
> > > On 12/15/05, Roger A. Grimes <roger@xxxxxxxxxxxxxx> wrote:
> > > > Just to clarify, so that people don't think this affects Windows
> > > > XP
> > SP2.
> > > > I've tested SP2 again, and the LAND attack no longer works. This
> > > > announcement concerns gateway network devices that computers may
> > > > attach to (the announcement is a little confusing at first).
> > > >
> > > > Also, to pull off the hping2 example, you'll need the -k parameter
>
> > > > to make sure the source port stays at port 80, else it will
> > > > increment up (80, 81, 82, etc.)
> > > >
> > > > Roger
> > > >
> > > > ******************************************************************
> > > > * *Roger A. Grimes, Banneret Computer Security, Consultant *CPA,
> > > > CISSP, MCSE: Security (2000/2003/MVP), CEH, yada...yada...
> > > > *email: roger@xxxxxxxxxxxxxx
> > > > *Author of Honeypots for Windows (Apress)
> > > > *http://www.apress.com/book/bookDisplay.html?bID=281
> > > > ******************************************************************
> > > > *
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Synister Syntax [mailto:synistersyntaxlist@xxxxxxxxx]
> > > > Sent: Wednesday, December 14, 2005 1:49 AM
> > > > To: bugtraq@xxxxxxxxxxxxxxxxx; full-disclosure@xxxxxxxxxxxxxxxxx;
> > > > vuln-dev@xxxxxxxxxxxxxxxxx; NTBUGTRAQ@xxxxxxxxxxxxxxxxxxxxxx
> > > > Subject: RLA ("Remote LanD Attack")
> > > >
> > > > 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)
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > SynSyn
> > > Network Manager, Server Administrator, Security Specialist
> > > (http://www.teamtrinix.com)
> > >
> >
> >
> > --
> > Regards,
> > SynSyn
> > Network Manager, Server Administrator, Security Specialist
> > (http://www.teamtrinix.com)
> >
>
>
> --
> 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

  • Tech paper on proposed future generation NIDS
    ... Data is aggregated from the network ... UDP packets, or other incongruity in data and packet types. ... to reduce IDS rule sets and attack proccessing. ... When people in security speak of correlation, ...
    (Focus-IDS)
  • RE: Intrusion Prevention Systems
    ... Network systems functioning as a bridge can prevent the traffic ... recognize the attack and prevent it from affecting the target is absurd. ... His point is that there are many techniques ... variables affecting the application's receipt of and response to the data. ...
    (Focus-IDS)
  • [Full-disclosure] Re: RLA ("Remote LanD Attack")
    ... > " That is correct this affects network perimeter devices, ... > I used the -k switch a few, times although, it seemed to work either ... > the data/payload size seems to cause the attack to be more optimized. ... >>> remotely against the central connectivity device. ...
    (Full-Disclosure)
  • RE: ForeScout ActiveScout (was: Re: Intrusion Prevention)
    ... The technology sounds interesting but I have doubts regarding the ... If I for example scan for port 80, ... How do you deal with real network problems that prevent legitimate ... put the product in alert mode waiting for an attack? ...
    (Focus-IDS)
  • Re: Emergency HT for non HAM?
    ... Even if there is no chance of them being in the attack itself, ... We have 3 1/2 cell phone carriers here, one runs a mixed AMPS CDMA network, ... Ham radio still works. ... and communicate when everything you think is normal stops working. ...
    (rec.radio.amateur.equipment)