RE: [ActiveDir] Photos in AD

[joe]

The same question applies to any non-NOS data you want to throw into the directory, where will the info be consumed? Why is it needed?

 

In general, when people want photos it is for some address book type application that usually runs as a web app. In that case, I see no point in that data going into AD, it is unnecessary bloat.

 

 

 

 

As Guido points out, users directly populating photos or any data can be less than optimal for you. Say you have 100k users and they all get this cool new app that lets them upload pics, how well will your replication infrastructure and DCs handle an influx of 20,000 50,000 80,000 or even 100,000 photos in a short period of time? I know I know, you would control the uploading of that info. But what if some handy dandy intern figures it out, writes a short little program and starts handing it out? Do figure it out because DCs start running out of space, because DCs start slowing down, because DCs start replicating more slowly, or because customers call because they can't authenticate? What if that intern is an intern for "Hack and Bang Em Up Enterprises" and simply knows who to send email to you in your org?

 

There are of course other attributes to be concerned with. Locking down is good but at the same time you need to be very aware of what you are locking down. A complete lockdown will have unexpected results say on your ability to modify your public delegates or mail certs for Exchange for instance... Obviously Guido is on the same page here. Understand before you change.

 

Want to figure out your most dangerous attributes in terms of what users can hurt you with (or alternatively some application that does things on their behalf at their behest or because they opened the wrong email)? You need to find which attributes a user can write on their own object that lets you write large amounts of data. In general you can quickly focus in on Unicode attributes (attributeSyntax=2.5.5.12) that don't have a rangeUpper value. For bonus points look at whether or not they are multivalued or not[1]. If a user has write access to a multivalued unicode attribute with no rangeUpper they could theoretically, if I understand this stuff properly, write approximately 1300*10MB (~12.7GB) of information to a K3 directory for that one attribute without any help from an admin. I say theoretically because I haven't sat down and written anything to try it and possibly there is some admin limit you will encounter. I hope so, but wouldn't be terribly surprised if it worked.

 

Imagine, if you will, someone who chooses to attack AD who knows how to and is smart enough to write their bad app to look at what the current user has access to modify and calculates what can cause the most damage and does it. This could be devastating whether that user is an admin or a normal user (maybe a 13GB increase in your DIT in less than an hour wouldn't hurt you... would you at least notice it occurred?). They then combine that with a delivery system like "See Jessica Alba Nude!" and how many users do you have and how big can your DIT grow until you hear that pop of the impending implosion of your disk subsystem?

 

 

Let's see if we can find a bad attribute that users have access to...

 

 

1. Look at the ACL set on a user. Look for what SELF has access to.

 

K:\>adfind -b CN=pato,CN=Users,DC=joe,DC=com -sddl+ ntsecuritydescriptor -resolvesids |grep -i self

 

AdFind V01.31.00cpp Joe Richards ([EMAIL PROTECTED]) March 2006

 

File STDIN:
>nTSecurityDescriptor: [DACL] OA;;CR;Change Password;;NT AUTHORITY\SELF
>nTSecurityDescriptor: [DACL] OA;;CR;Send As;;NT AUTHORITY\SELF
>nTSecurityDescriptor: [DACL] OA;;CR;Receive As;;NT AUTHORITY\SELF
>nTSecurityDescriptor: [DACL] OA;;RPWP;Personal Information;;NT AUTHORITY\SELF
>nTSecurityDescriptor: [DACL] OA;;RPWP;Phone and Mail Options;;NT AUTHORITY\SELF
>nTSecurityDescriptor: [DACL] OA;;RPWP;Web Information;;NT AUTHORITY\SELF
>nTSecurityDescriptor: [DACL] A;;LCRPLORC;;;NT AUTHORITY\SELF

 

 

2. You see that you have three property sets involved: Personal Information, Phone and Mail Options, and Web Information. So then look up what attributes are involved. You can use the scripts that were previously posted by Sakari and/or myself to this very list or use adfind. We will start with Web Information as that seems innocuous. First you need to get the rightsGuid to chase across schema objects with...

 

K:\>adfind -sc findpropsetrg:"Web Information"

 

AdFind V01.31.00cpp Joe Richards ([EMAIL PROTECTED]) March 2006

 

Using server: 2k3dc01.joe.com:389
Directory: Windows Server 2003
Base DN: cn=extended-rights,CN=Configuration,DC=joe,DC=com

 

dn:CN=Web-Information,CN=Extended-Rights,CN=Configuration,DC=joe,DC=com
>rightsGuid: E45795B3-9455-11d1-AEBD-0000F80367C1

 

1 Objects returned

 

 

3. Now we want to use that rightsGUID and pull all attributes that have that GUID, are unicode (2.5.5.12) and are multivalued with no range upper as those are the most dangerous of the bunch...

 

K:\>adfind -sc propsetmembers:E45795B3-9455-11d1-AEBD-0000F80367C1 -af "&(issinglevalued=FALSE)(!(rangeupper=*))" ldapdisplayname rangeupper

 

AdFind V01.31.00cpp Joe Richards ([EMAIL PROTECTED]) March 2006

 

Transformed Filter: (&(&(objectcategory=attributeschema)(attributeSecurityGUID=\B3\95W\E4U\94\D1\11\AE\BD\00\00\F8\03g\C1))(&(issinglevalued=FALSE)(!(rangeupper=*))))
Using server: 2k3dc01.joe.com:389
Directory: Windows Server 2003
Base DN: CN=Schema,CN=Configuration,DC=joe,DC=com

 

dn:CN=WWW-Page-Other,CN=Schema,CN=Configuration,DC=joe,DC=com
>lDAPDisplayName: url

 

1 Objects returned

 

 

Ohhh.... There you go, bang, right off the bat. Who would have thought that one would have been dangerous? I didn't even get into personal information property set where I know bad things exist.

 

 

How can an automated system take advantage of that? Not all that tough really. If you don't need to do the max damage but just a considerable amount of damage you can use a combination of tools from batch or script directly. For instance, username from joeware to get DN of current user, then adfind to pull the list of attributes the user is allowed to populate (allowedAttributesEffective) and then something say like admod to populate the multivalue entries. Unicode attributes aren't the only ones to watch out for too... you need to be wary of any attributes that a user can write on their own account that doesn't have a rangeupper. Possibly there is something else to cap it, possibly not.

 

I will stop there, any more and I will be showing off the script that could be put into any old exploit vector to find all really bad exploitable attributes for the current user and slam them with data. What I have above is probably too much but hopefully it helps illustrate the possible danger here. As a community we have been lucky that no one with the capability has fed the script kiddies with a very simple very damaging script that they can share with all of your users. Truly this stuff isn't rocket science, people just don't pay much attention which appears to be both a good and bad thing.

 

 

    joe

 

 

[1] Even not multivalue attributes can be a pain if this stuff makes it into a worm or nice email message everyone runs. Say you have 100k users in a domain and they all have write access to one unranged single value unicode attribute. Say that fully 80% are silly enough to run something they shouldn't. You have now added at least ~781GB of data to your DIT. Maybe you have smart people and only 20% run something, that is still ~195GB. I don't know about you but my DIT disks didn't tend to have that much free space. It seems many DCs could start to experience issues with as few as one user with access to a single multivalue unranged attribute (~13GB) or a couple of thousand users with access to one single value attribute (~20GB).

 

 

 

 

--

O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm 

 

 

---

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mr Oteece
Sent: Wednesday, March 01, 2006 8:56 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Photos in AD

Storage of photos in AD using jpegPhoto or thumbnailPhoto - yay or nay?

 

I checked the archives on this and didn't see too much there beyond Guido saying "don't do it". To quote:

 

[Grillenmeier, Guido
Tue, 14 Dec 2004 12:35:42 -0800

 

that's likely the photo or the thumbnailPhoto attribute (both octet strings) - best way to kill your AD.  There are a couple of tools out there that allow uploading a user's photo to this attribute... The downside: every user has the right to do so on his own account (via the SELF security principal and the permissions granted to it with the PersonalInformation property set).  I can only recommend to take these permissions away (possible in 2k3 to remove unwanted attributes from the default property sets).

a link would certainly be better - I don't think there's a default attribute for this - you might want to introduce a new attribute to your schema.

/Guido]
 

 

I actually didn't see the jpegPhoto attribute in the Personal-Information attribute set (http://msdn.microsoft.com/library/default.asp?url="" ). Regardless, our users do not have the ability to update any of the photo attributes. So beyond DoS issues with users being able to upload large files into AD, what are the potential issues with having these out there? I certainly don't want to be flinging these bits to all corners of the world, and I would much rather use a link attribute. Coming up against management here though.

 

So, any real-world experience on populating photos in AD? Any more cons beyond DIT bloat and DoS?

 

Consider it a rather large AD implementation, with multiple child domains, >100K users, and a need to have the photo information in the global catalog