Re: MS and security: good effort but no cigar

From: SlowJet (SlowJet_at_noTY2this.com)
Date: 02/23/05 

Date: Wed, 23 Feb 2005 20:29:28 GMT

Well Dan, wishfull thinking isn't going to change the facts of life, and
even thou there is a full Moon in Virgo perfecting DOS and 9x is way down on
the list of needs from things like a longer lasting light buld (coz we all
known there the GE bulbs are designed to burn out easily so you need to by
more. Up on a Gov building on Vancover Is. they have bulds still burning
that are 130 years old. I bought some of those 10 years bulds from the
handicap people. I was impressed that they did last over a year.)

Aside from rewriting history in one's own likeness, lol, how about just
hammering on about the basics.

Secure strong passowords, run under a user account for regular work. Two way
Firewall with as many ports close as possible, to the point of a little
inconvience. AV software, two kinds, one for the input streem, one for files
system and e-mail. Aware and spyware blockers and scanners - run often.

And last but not least, no fat, no dos, no multiboot.

The beat goes on, :)

SJ
"Dan" <spamyou@user.nec> wrote in message
news:eUf4JpdGFHA.580@TK2MSFTNGP15.phx.gbl...
> The core of XP PRO is based upon a command.com (cmd.com) prompt within a
> DOS
> (Disk Operating System) emulator that is encassed within a DOS shell.
> Microsoft saved money by making NT (New Technology) without a new
> maintenance
> operating system. The NT (Not There) according to Microsoft's own techs.
> according to a history book on Microsoft said that it was "crazy" to do it
> this way but they had orders and were not about to break them. As you can
> see a true hacker can attack the false MS-DOS core because it is insecure.
> At least 98SE based upon 9x source code has a true solid core that is
> based
> upon real DOS but with less capabilities. Some commands were removed
> instead
> of Microsoft updating them Microsoft saved money by just removing them.
> Parts of the NT (New Technology) source code have already been leaked out
> over the internet. This is not the case with 9x source code. It has not
> been leaked and the core is more stable than NT (XPPRO, XPHOME, 2000,
> etc.)
> Also, 98SE is easier to understand. Sure it does not have as many
> services
> but that means less points of entry for hackers to attack. I do not
> understand why people will not accept this. Microsoft XP PRO. is not
> secure.
> Its foundation is built upon sand and not rock. Microsoft needs to build
> a
> brand new maintenance operating system and stear clear of DOS with
> Longhorn
> or successors. DOS and 9x must either continue as a Classics line that
> Microsoft could continue to get revenue from or be sold or given to the
> open-source community for the good of all mankind. Have a nice day and I
> look forward to hearing from you.
> "mar" <anonymous@discussions.microsoft.com> wrote in message
> news:383siaF5h4h65U1@individual.net...
> : MS and security: good effort but no cigar
> : By Mark Burnett, SecurityFocus
> : Published Wednesday 23rd February 2005 10:42 GMT
> : http://www.theregister.co.uk/2005/02/23/ms_security_issues/
> :
> : Last week I watched the webcast of Bill Gates speaking at the RSA
> : conference in San Francisco. He talked about Microsoft's plans to
> : build upon the progress it's already made in security. These plans
> : included better protection against spyware and spam. Gates also
> : announced Microsoft's intention to release Internet Explorer 7,
> : complete with a number of security improvements, by the end of this
> : year.
> :
> : Looking back, the company has indeed made notable progress in the
> : security of its software. Windows XP SP2 is a significant achievement,
> : and Gates reported that over 170 million people have downloaded the
> : update. The low-hanging fruit of millions of insecure Windows machines
> : is rapidly falling from the tree.
> :
> :
> : But we're not out of the woods yet. If you can gain any user access to
> : a Windows system, it is still surprisingly easy to completely own that
> : box. So far, these problems have been overshadowed by the countless
> : remote holes we've seen in recent years, but privilege escalation by
> : authorized users is an important issue today that is still too easy to
> : exploit.
> :
> : Take, for example, the way that Windows handles file paths with
> : spaces. Suppose that you want to run the following command:
> :
> : C:\Program Files\Internet Explorer\iexplore
> :
> : One cool thing about Windows is that although the path contains a
> : space, it still runs the application fine, even if you don't place
> : quotes around the entire command and even if you don't use the
> : executable extension for iexplore.exe.
> :
> : But how does Windows know where the program path ends and the
> : program's command line parameters begin? How does it know that the
> : user isn't trying to run a program named "C:\Program.exe" with the
> : parameter "Files\Internet Explorer\iexplore?"
> :
> : The problem is that it doesn't know. It just starts at the beginning
> : and tries finding an executable until it finds a match. So in this
> : case, it will try these files every time you run the command:
> :
> : C:\Program.exe
> : C:\Program Files\Internet.exe
> : C:\Program Files\Internet Explorer\iexplore.exe
> :
> : You might see where I'm going with this: if you place an executable
> : named program.exe in the root directory, it will probably end up
> : running quite a bit. In fact, it will run anytime Windows launches a
> : Program Files executable that does not have quotes around the path.
> :
> : Microsoft certainly is aware of this issue. In fact, it was probably a
> : design decision at some point. If you run Windows XP, try placing an
> : executable named program.exe and reboot your system. When it restarts,
> : Windows will warn you about the complications of having that file
> : there.
> :
> : Here's the problem: there are thousands of paths in the registry that
> : do not have quotes around them, and many Windows systems have weak
> : NTFS permissions that allow any user to write to the root directory.
> : This is bad. As an experiment, I created a small program that simply
> : logged every time it ran and under what user context. I rebooted and
> : checked my Event Log. It turned out that on my system it ran eight
> : times, twice under the context of the SYSTEM account and the rest as
> : my own administrative account.
> :
> : Of course, I got the message box warning of the file, so I made a
> : slight modification to my program.exe. It turns out there is a
> : registry key that you can set to turn off this warning. I simply
> : change that setting every time my program runs. Since the first couple
> : instances executed before I even logged in, there was no warning at
> : all. And of course, there are plenty other executable name variations
> : that Windows does not check.
> : Criminals get smarter
> :
> : This could be a serious issue, and it's not the only one. Another
> : weakness is all the batch files and scripts that administrators use.
> : Sure, scripts are convenient, but you must take care to protect these
> : files. Too many administrators leaving them laying around in
> : directories where Everyone has write access to the files. All an
> : attacker with low-privileged access needs to do is add their code of
> : choice to the end of your script and it runs under your security
> : context the next time you use the script.
> :
> : Fortunately, Windows allows you to enforce script signing policies,
> : but there is no way to enforce signing of a batch file. You must also
> : protect files such as .reg, and .inf that an attacker might exploit.
> : If you use scripts on your servers, make sure they have strong NTFS
> : permissions.
> :
> : Then there's the issue of poorly secured server applications. In my
> : experience, third party Windows mail servers are particularly
> : vulnerable. Some let you run code based on an email message, use
> : executable auto-responders, and execute external virus and filtering
> : applications. But what happens if the user is able to run any
> : application of choice?
> :
> : I have seen many, many mail server directories that allow all users
> : full control over the files in that directory. Sometimes it's the mail
> : server installer that does this and sometimes it is the
> : administrator's fault. Some mail servers even require loose
> : permissions for some user features to work properly.
> :
> : This means that regular users can modify these settings and send
> : themselves an email to get executables running in the context of the
> : mail server's service - which is often the SYSTEM account. Obviously,
> : I'm oversimplifying what's involved here, but take a close look at the
> : file permissions for your server applications. Can users get the
> : server to run their code?
> :
> : Depending on your server, you should even consider denying all access
> : to any account besides the service account. Too many server
> : applications store user passwords using weak encryption and all an
> : attacker might need is Read access to that file. Many of these flaws
> : are well known, and there are many more that are still not publicly
> : known. Most users do not need Read access to these files.
> :
> : So far, I have only scratched the surface. There are problems with FTP
> : client apps storing passwords, browser issues, auto run issues, and of
> : course, the serious problems of physical server access. We have raised
> : the bar some, but we are nowhere near done. If you have any access to
> : a system, you can likely gain administrative access.
> :
> : Sure, Microsoft is eliminating the low-hanging fruit. But what happens
> : when there is no more low-hanging fruit? Crime doesn't stop because it
> : is harder. Criminals get smarter. The question is, will we be ready
> : when that time comes?
> :
> : Copyright © 2004,
> :
> : Mark Burnett is an independent researcher, consultant, and writer
> : specializing in Windows security. He is the author of Hacking the
> : Code: ASP.NET Web Application Security (Syngress), co-author of the
> : best-selling book Stealing The Network: How to Own the Box (Syngress),
> : and co-author of Maximum Windows 2000 Security (SAMS Publishing). He
> : is a contributor and technical editor for Special Ops: Host and
> : Network Security for Microsoft, UNIX, and Oracle. Mark speaks at
> : various security conferences and has published articles in Windows IT
> : Pro Magazine (formerly Windows & .NET Magazine), Redmond Magazine,
> : Information Security, Windows Web Solutions, Security Administrator
> : and various other print and online publications. Mark is a Microsoft
> : Windows Server Most Valued Professional for Internet Information
> : Services.
>
>

Relevant Pages

  • SecurityFocus Microsoft Newsletter #164
    ... Got Storage Security Risks? ... MICROSOFT VULNERABILITY SUMMARY ... Chat Client FTP Server Default Username Credential Weak... ... NetServe Web Server is a compact web server for Microsoft Windows ...
    (Focus-Microsoft)
  • Re: im being held in memory
    ... How can I harden my computer or server to secure it from hackers? ... Use firewall software and hardware and antivirus software that is ... Follow the instructions for hardening Windows and IIS at ... Install all service packs and security fixes from Microsoft and otherwise ...
    (microsoft.public.security)
  • MS and security: good effort but no cigar
    ... build upon the progress it's already made in security. ... The low-hanging fruit of millions of insecure Windows machines ... Then there's the issue of poorly secured server applications. ... and execute external virus and filtering ...
    (microsoft.public.windowsxp.general)
  • SecurityFocus Microsoft Newsletter #167
    ... MICROSOFT VULNERABILITY SUMMARY ... Multiple Vendor XML Parser SOAP Server Denial Of Service Vul... ... Proactive Windows Security Explorer ...
    (Focus-Microsoft)
  • Re: Group Policy broke my DCs
    ... to be very careful with tweaking services on domain controllers. ... Group Policy - security policy at the OU level which makes it much easier to ... complied from the Windows 2003 Server Security guide for baseline core ... Server - automatic ...
    (microsoft.public.windows.group_policy)