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 dleblancat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:06:56 PDT