Bugtraq mailing list archives
Re: RFP9903: AeDubug vulnerabilty
From: dleblanc () MINDSPRING COM (David LeBlanc)
Date: Thu, 7 Oct 1999 08:37:53 -0700
At 04:34 PM 10/6/99 +1000, Mark Dixon ext3456 wrote:
Even though .rain.forest.puppy has cancelled RFP9903 I think it's worth making a couple of comments...
1) Find a machine with 139 listening
This is typically an issue when attacking remotely through the Internet. However, this seems to dissolve when you have internal access (inside job). Check out the numbers for the 1999 CSI-FBI incident survey, regarding internal security problems at www.gocsi.com/summary.htm
I have to agree with .rain.forest.puppy here. I need to secure my network against LAN users just as much as outside users. Just look at the number of exploits that appear on bugtraq that require local accounts. These types of problems are still very real.
I'm not saying the problems aren't real, or minimizing the extent of the problem. All I'm saying is that if you want to pull this exploit off, then it depends on several conditions. This is one. If I thought a condition was difficult to meet, I'd have noted it. The conclusion I'd draw from needing to meet this condition is that you'd be most likely to attack an internal network, or maybe a home user's machine - though a home user is unlikely to be running the server version, and you can't get to the registry in that area on a workstation as less than admin. So your population at risk is largely internal servers. Whether or not someone is likely to attack your own internal server is something I can't judge, though it is true that lots of attacks are inside jobs. [snip]
4) Put a binary on the system
If you can run programs, you can (attempt) to use ftp or rcp to pull files in. I realize this is dependant on outgoing firewall rules, access to the commands, etc. But it's not impossible--these methods have been used by many people contacting me on the RDS issue.
UNC paths work here. If you can setup your own share with guest access I believe you can run whatever you like from it.
UNC paths may not work in this instance. Not all paths contained in the registry can be remote. I'd have to test this to be sure, and also note that it may be dependent on what user caused the debugger to fire.
5) Make something crash that has higher access rights than you do
Well here's the real problem. ..I guess you'd just have to hang around and wait...
This one is likely to be sticky, unless you've got a good DoS that you know will work. David LeBlanc dleblanc () mindspring com
Current thread:
- Re: RFP9903: AeDubug vulnerabilty Mark Dixon ext3456 (Oct 05)
- Re: RFP9903: AeDubug vulnerabilty David LeBlanc (Oct 07)
- <Possible follow-ups>
- Re: RFP9903: AeDubug vulnerabilty Mark Dixon (Oct 09)
- Re: RFP9903: AeDubug vulnerabilty Steve Coleman (Oct 12)
- Re: RFP9903: AeDubug vulnerabilty David Zverina (Oct 14)
- Re: RFP9903: AeDubug vulnerabilty David LeBlanc (Oct 12)
- Re: RFP9903: AeDubug vulnerabilty Jesper M. Johansson (Oct 12)
- Resistance is futile, or what I learned trying to secure the scanner Blue Boar (Oct 12)
- SECURITY: RHSA-1999:040 New PAM packages available Cristian Gafton (Oct 12)
- Re: RFP9903: AeDubug vulnerabilty Steve Coleman (Oct 12)