Accidental SMS mgmnt point DOS attack:

myITforum.com Community Forum

Home Forums Blogs Live Support chat Search Articles Wiki FAQ Email Lists Register Login My Profile Inbox Address Book My Subscription My Forums

Photo Gallery Member List Search Calendars FAQ Ticket List Log Out

All Forums RSS Feed Subscription:

Accidental SMS mgmnt point DOS attack:

View related threads: (in this forum | in all forums)

Logged in as: Guest

Printable Version

All Forums >> [Management Products] >> Microsoft Systems Management Server >> SMS 2003 >> Accidental SMS mgmnt point DOS attack:

Page: [1]

Message

<< Older Topic Newer Topic >>

Accidental SMS mgmnt point DOS attack: - 6/30/2008 4:12:19 PM

pkobres

Posts: 8
Score: 0
Joined: 6/5/2007
Status: offline

I'm hoping someone on the forums might be able to help us understand the mechanism by which we DOSed our SMS advanced clients on a local subnet over the weekend. (besides the obvious....)

Senerio:

Advanced clients are deployed in a production environment w/ SMS2003 using advanced security (but no schema extensions).... The client's managment point is hard coded into the client installation command line. Clients are discovered by our production SMS server using AD methods only. Our site boundary is our AD (no networks).

Our SMS Test server, which is on a different AD, and uses different credentials, but happens to share the same site code, was unknowingly plugged into our production network for a short period of time. (Ding! Yes... fist problem right there...) The test server, was only partially configured, having no site boundaries defined, and all AD discovery methods were limited to a non-existant container in a different AD. Heartbeat discovery, however, was turned on , as was network discovery. Though "local subnets" were not defined, "search local subnet" was enabled.

The result was that a number of advanced clients on the same local subnet as the test server, changed their managment points to point to the IP address of the test box. The clients show up as assigned on the test box, even though they're in a different AD, and heart-beat discovery is the only method listed when looking at the discovery data for each client.

I'm trying to figure out under what security authority this happened. There was no WINS server setup. The SMS test box should have had no authority over machines in the production environment or within the production domain. Why would the previously installed production advanced clients just decide to trust an unknown managment point that happened to have the same site code?

I'd love to extend the schema, but we as of yet have no enterprise PKI (making certificates authentication of the managment point useless) and our environment has several independently run SMS or SCCM servers, which need different extensions as I understand.

Any thoughts would be appreciated! Thanks!

Post #: 1

RE: Accidental SMS mgmnt point DOS attack: - 6/30/2008 5:09:20 PM

rcrumbaker

Posts: 874
Score: 23
Joined: 5/13/2002
From: Kentucky (aka The Promise Land)
Status: offline

Fixed...silly COLON

_____________________________

Thanks,
Ron
Microsoft MVP - SMS
rdcrumbaker@gmail.com
My Blog

(in reply to pkobres)

Post #: 2

RE: Accidental SMS mgmnt point DOS attack: - 6/30/2008 5:18:28 PM

bmason505

Posts: 2031
Score: 114
Joined: 1/23/2003
From: Minneapolis, MN
Status: offline

They showed up as assigned because they're on the same subnet as the server, but they did not change assignment. Clients never do unless you change the assignment via GPO or script or manually.

I think back in the SMS 2.0 days, the local subnet was a 'gimme' for boundaries. Maybe it's the same for 2003.

So you pull the plug on this test box and you'll see clients can talk to their other server fine. All that happened was that the network discovery found the machines on the same subnet and show them as being assigned. The term should almost be "in boundaries" instead of assigned.

Also, if you have SCCM servers in the forest, odds are the schema has been extended already. If it hasn't, there isn't a PKI dependency for you to extend it.

_____________________________

Brian Mason
MCSA\MCSE\MS MVP - SCCM
Wells Fargo
http://www.miscusergroup.org/

(in reply to rcrumbaker)

Post #: 3

RE: Accidental SMS mgmnt point DOS attack: - 6/30/2008 8:15:29 PM

jnelson993

Posts: 959
Score: 132
Joined: 2/18/2005
From: Minneapolis, MN
Status: offline

quote:

Fixed...silly COLON

Wow, your spastic colon did a DOS attack on someone's clients?

_____________________________

Number2 (John Nelson)
MyITForum - Blog
MyITForum - Forum Posts

(in reply to rcrumbaker)

Post #: 4

RE: Accidental SMS mgmnt point DOS attack: - 7/1/2008 10:30:55 AM

pkobres

Posts: 8
Score: 0
Joined: 6/5/2007
Status: offline

quote:

ORIGINAL: bmason505

They showed up as assigned because they're on the same subnet as the server, but they did not change assignment. Clients never do unless you change the assignment via GPO or script or manually.

I think back in the SMS 2.0 days, the local subnet was a 'gimme' for boundaries. Maybe it's the same for 2003.

So you pull the plug on this test box and you'll see clients can talk to their other server fine. All that happened was that the network discovery found the machines on the same subnet and show them as being assigned. The term should almost be "in boundaries" instead of assigned.

Also, if you have SCCM servers in the forest, odds are the schema has been extended already. If it hasn't, there isn't a PKI dependency for you to extend it.

Thanks for your thoughts Brian,

I would have expected the same behavior based on the documentation about the Advanced Client/Advanced Security. I wouldn't care that they showed up as assigned to the test SMS server except that fact remains that all the Advanced Clients (27 of them) on the affected local subnet changed their management point assignment. Even after unplugging the test server, the management point reported on the "general" tab in "Systems Management Properties" of the SMS client on affected systems remains pointed at the IP address of the SMS test server that has been unplugged/offline for several days now. We can see from the DDR logs when the test server discovered the affected clients, but we havn't yet been able to find the logs on affected machines that show when/how they switched managment points. The affected clients, however, still show up as assigned on the production SMS server (as expected.) All the other non-affected advanced clients remain pointed at the DNS name of our production SMS server / management point.

We discovered that the test SMS server was plugged in and turned on (as was the test domain controller that provides the test domain the test SMS server is in) when we tried to send an Office package/advertisement from our production server to one of the affected systems. The Office package never showed up, but an OLD Trend AV installation package on the test SMS server/management point DID! It would not install however (access denied as one would hope...). I kind of feel like I've discovered a MS security flaw, but one year of SMS experience isn't enough for me to fully interpret what is going on.

The schema has definitely NOT been extended. I think we would extend it IF we knew how to make multiple independently run SMS and SCCM servers use the same extensions without stepping on each other’s toes. (I work at a University and there are multiple departments using SMS in the same AD -one Forrest -one Domain). I mentioned the lack of schema extensions extensions as the adv clients acted almost as if they were able to discover their management point (something I didn't think that they could do w/o extensions/rights granted to the SMS server). PKI would be nice as w/ extensions the mgmnt points could be validated via certificate.

Fixing this is a minor issue of running a script, but I'd still like to more fully understand what happened.

Again, thank you for answering my post! Much appreciated.

Paul Kobres
The University of South Carolina

< Message edited by pkobres -- 7/1/2008 10:55:05 AM >

(in reply to bmason505)

Post #: 5

RE: Accidental SMS mgmnt point DOS attack: - 7/1/2008 11:08:05 AM

pkobres

Posts: 8
Score: 0
Joined: 6/5/2007
Status: offline

I suspect that I'm jumping to conclusions here, but this is what is going through my mind:

The behavior we've experienced suggest that in certain situations an attacker could DOS an organization /take over PCs if:

1. They had physical access to their network.
2. The attacker knew the SMS Site code.
3. The organization did not have schema extensions.
4. The attacker set up a DC/SMS combo w/ the same site code & advertized malicious programs that would run under the authority of the end user.

I have GOT to be missing something....

Paul Kobres
The University of South Carolina

(in reply to pkobres)

Post #: 6

RE: Accidental SMS mgmnt point DOS attack: - 7/1/2008 12:23:19 PM

bmason505

Posts: 2031
Score: 114
Joined: 1/23/2003
From: Minneapolis, MN
Status: offline

Without AD, the client falls back to WINS. There can be only one SMS_SLP entry in WINS. You can't share it with lots of independent hierarchies. Just one machine gets that entry. My guess is you have an SLP enabled on the new\fake server and it simply updated WINS to say "I'm the new entry." Now, yes, that requires physical access to your network. I guess the only part that I'm surprised about is that an empty roaming boundary still allows the local server subnet (it really was empty?). So I guess your SLP told it where to find its MP and the clients on that subnet started talking to it.

_____________________________

Brian Mason
MCSA\MCSE\MS MVP - SCCM
Wells Fargo
http://www.miscusergroup.org/

(in reply to pkobres)

Post #: 7

RE: Accidental SMS mgmnt point DOS attack: - 7/1/2008 2:50:18 PM

pkobres

Posts: 8
Score: 0
Joined: 6/5/2007
Status: offline

quote:

ORIGINAL: bmason505

Without AD, the client falls back to WINS. There can be only one SMS_SLP entry in WINS. You can't share it with lots of independent hierarchies. Just one machine gets that entry. My guess is you have an SLP enabled on the new\fake server and it simply updated WINS to say "I'm the new entry." Now, yes, that requires physical access to your network. I guess the only part that I'm surprised about is that an empty roaming boundary still allows the local server subnet (it really was empty?). So I guess your SLP told it where to find its MP and the clients on that subnet started talking to it.

You are correct, the Test SMS server is a Server Locator Point. As far as I know, however, there is no WINS server in the area (unless there is a rogue that enables automatic configuration via unauthenticated sources). We did not configure a WINS server with an SMS_SLP entry. We also did not, however, prevent WINS by using the SMSNWINSLOOKUP switch during client installations. How would clients discover a WINS server though? How would one tell that the advanced client was utilizing WINS? I would have thought an enabled SLP would be ineffectual w/o extensions or WINS.

The "include site boundaries within the local roaming boundaries of this site" was checked on the test SMS server, but there were no explicit roaming boundaries and "Site Boundaries" was undefined.

(in reply to bmason505)

Post #: 8

RE: Accidental SMS mgmnt point DOS attack: - 7/1/2008 3:44:30 PM

bmason505

Posts: 2031
Score: 114
Joined: 1/23/2003
From: Minneapolis, MN
Status: offline

Wait, I know. It must be working off a subnet broadcast to get to their old MP first. Was the server the same name? (SLP's must be manually registered and it sure doesn't sound like you did that).

_____________________________

Brian Mason
MCSA\MCSE\MS MVP - SCCM
Wells Fargo
http://www.miscusergroup.org/

(in reply to pkobres)

Post #: 9

RE: Accidental SMS mgmnt point DOS attack: - 7/1/2008 5:15:51 PM

pkobres

Posts: 8
Score: 0
Joined: 6/5/2007
Status: offline

quote:

ORIGINAL: bmason505

Wait, I know. It must be working off a subnet broadcast to get to their old MP first. Was the server the same name? (SLP's must be manually registered and it sure doesn't sound like you did that).

Some sort of NetBIOS-like subnet broadcast does make sense, but the Test SMS server has a different name from the production server. The site code is identical, which has to be the key. The fact that the adv clients re-assigned their management point arbitrarily.... still disturbing...

I'm going to ask my co-worker to follow up w/ any more technical details that might reveal the explanation for this as I'll be out of the office for the next few days and may not be able to follow up on this thread.

Either way, thank you for lending your expertise to this small, but facinating problem....

Paul Kobres
The University of South Carolina

(in reply to bmason505)

Post #: 10