lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
From: jonathan at nuclearelephant.com (Jonathan A. Zdziarski)
Subject: [Fwd: Bugtraq: Linksys WRT54G Denial
	of	Service Vulnerability]

> What do you mean with "externally"? WLAN? Internet?
> I don't know this particular device, but I know that lots of other 
> Access Points that have a web interface regard any request from WLAN as 
> being internal. If this is also the case for the WRT54G, the attack can 
> be made from anyone who is in reach of the Access Point as described in 
> the vulnerability report.

I would hope that users of this device would at least be taking
advantage of the integrated WPA functionality to keep unwanted visitors
off the network - although this still presents a vulnerability, it is
(at the present time) more difficult to hack your way onto a
WPA-protected network than an unencrypted or WEP-encrypted system. 

> WRT54G is said to have an https? Or do you mean SSL for authentication 
> of users before they can access anything on (or behind) the network the 
> Access Point is attached to?

I was referring to https...if it supports it, that's great...they are
certainly working hard to make the newer hardware more secure.  For
authentication, WPA supports certificate-based authentication, but I
doubt any residential user would be using this.  Most would probably
just use the pre-shared key...which used alone doesn't quite make much
more sense than WEP (although it takes away some of the 'cracking wep'
fun).  If, for example, someone were to be a legitimate user on that
network or intercept or deduce the pre-shared key (somehow), it seems as
though it would be relatively easy to decode all subsequent packets for
any user by simply following the stream of new keys generated for each
packet.  This would require capturing every packet from the start of a
session, but appears to still leave a hole open for someone who wanted
to write such a tool (i'm sure WPA-PSK decoding will be part of some new
version of Kismet eventually, as WEP decoding is already).  'Course
being that WPA is new, there's plenty of time for people to spend
cracking it before it goes mainstream.

Jonathan



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ