Fw: Re: Odd Behavior - Windows Messenger Service

[Michael Gale <michael () bluesuperman com>]

Hello,

        Since everyone else has seemed to response to this thread I figured I would give my 2 cents. The way I see it 
is network security and computer security is the responsibility of the network admin(s) and no one else. 

Sure it would be great is Microsoft released secured versions of Windows but then average users like my parents and 
sales people would require a greater understanding of computers and security in order to use them because they would 
find all these features they so love to be disabled or blocked.

And I am not only pointing out M$ machines because some Linux distro's are just as bad (Red Hat for example).

So in any company the level of security at a network level and desktop level is the network admin's responsibility. 
They should not be accepting upper manager to understand RPC services.

The IT manager should have a security policy in place that has standards for desktop machines and servers. What type of 
network traffic is allowed and so on.

So I think the real concern here is not that M$ has network services running when the user is not logged because who 
cares if they login - so the hacker has to wait until the non-computer person logs in bit deal.

The concern is WHO is responsibly for these machines - which IT persons / department. Because it is there 
responsibility to ensure that everything is secure.

Michael.



Begin forwarded message:

Date: Sat, 19 Jul 2003 19:43:19 +1000
From: "gregh" <chows () ozemail com au>
To: <Bojan.Zdrnja () LSS hr>, "'Disclosure Full'" <full-disclosure () lists netsys com>
Subject: Re: [Full-disclosure] Odd Behavior - Windows Messenger Service



----- Original Message ----- 
From: Bojan Zdrnja 
To: 'gregh' ; 'Disclosure Full' 
Sent: Saturday, July 19, 2003 7:02 PM
Subject: RE: [Full-disclosure] Odd Behavior - Windows Messenger Service





> Well, "wide open" is same as anything else in the world. OP was talking
> about a *default* installation.

Well, as I was the first one to post anything at all on this issue, I would imagine what I had to say was relevant, 
too. However, to make you happy, please point out where I said it was or wasnt a default installation.

> I assume that you, as any other security aware person, will harden it's box
> before putting it on the Internet.

That was my entire point in one post. So many installations are badly handled. They WORK per se but there seems to be 
no thought given to in-house lans being properly secured in a lot of cases where the boxes used are Windows ones. I was 
the original poster on this subject and I pointed out that I found it by accident as I was only in a company for the 
first time just to fix a NIC. I would do any sort of work to get a foot in the door there so I was very happy to do 
that. When I tested, simply, by pinging f
rom another machine, the machine with the new NIC wasnt logged on at a local level. Yet, I had pinged it, I had done a 
tour of it's C drive, run a program on that machine etc. When I had left the machine it WAS logged on but by the time I 
had gotten to another on the lan, I had been intercepted by a question asker. The machine in question was a payroll 
machine and management didnt see it as a problem that anyone on the lan in the other offices could do what they wanted 
on !
 it even when it was thought that the machine should be secured at a local level by passwording logon. In other words, 
the mindset of a lot of companies is that a local logon with password is all you need to secure a lan connected 
machine. I tested it all out on my machines for the fun of it, just stuffing around and making things as normal as most 
people in the world would have them on a lan. Sure enough, it did it on mine, too. Not an ideal situation at all yet 
many lans around are likely to be that way s
imply because the people using them are in businesses that make money for them in a field other than anything to do 
with computers other than as a tool.

> And you can install a host based firewall and make it even more secure.

Sure but that wasnt the point. The installations of most small to medium companies dont have that sort of thing on a 
lan but would on a machine connected to Internet. So, if you have a script kiddy port scanning, you get the port scan 
blocked on the internet machine but if you have a real would-be hacker in the organisation who may have a grudge, you 
have problems. Security isnt JUST security from hacking on the net. You get employees who do such things for various 
reasons.

> Putting a 98 box on a LAN is equivalent with putting RedHat 6.2 on a LAN.

Where I live, it is a normal thing to do when a lan is required, believe me. I can name a lot of installations with 98, 
ME and one with 95 all connected. I can name you a few with XP on them, now, too. There are quite a few businesses 
within 30 minutes' drive of me and only 2 use *nix. Out of them, a good deal have lans of 4 or more. I realise 4 isnt 
big but that is still a business at risk the way I see it.

> I don't really see a point in implementing this. So, if I understood you
> correctly, they won't allow any network connection to a box until you log
> in???

No, you didnt get that correctly. It is an option that will be set somewhere so they say. The option will be that you 
can disallow any form of networking co-operation until the user has logged on or you can leave it the way it always has 
been to this point. Better than nothing.

> IMHO, that's not need feature at all. And besides, you won't be able to use
> it if you have a network logon (domain).

I dont see a problem if the user logs on and the network is discovered only after that point excepting depending on the 
care of the machine itself, the user may feel they are watching grass grow.

> What about when you lock your screen and go away?

That was really why I brought this up to Microsoft. The payroll machine in question had that feature and took the 
machine back to the welcome screen where, to get in at it's keyboard and do something, you had to logon, providing 
username and password. While the user was not at the desk, though, I could still run payroll applications though the 
user thought the machine safe from that sort of thing. It clearly wasnt. If I wanted to know what that payroll clerk's 
salary was, I could look it up using her own pr
ograms from another machine.
 

> Anyway, this is going waaaay from the list charter (IMHO, again) and I won't
> participate anymore and filling everyone's mailboxes unless it will be
> related to some security issues.

No problems here. This IS a real security issue/problem so it isnt off topic.

Greg.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html


-- 
Michael Gale
michael () bluesuperman com
Unix / Linux Network Administrator
Bluesuperman.com

Attachment: _bin
Description: