O365 is not secure

I used to think it was.  After all the amazing things you read on the O365 Trust Center, you all but think it is Fort Knox (well, at least one part of it is right Bill Baer?) 

Let me go back to that title. "O365 is not secure…once you start adding users".  Last week I blogged about a security oversight in O365's partner sharing feature.  Basically what this means is that once you accept an invitation from a partner (aka a "user"), you become just another customer in their "customer management" portal. You can read more about this feature here:


Do you know who else they have as customers and who is accessing your data and when?  No. They don't really have any logs to tell you when a partner is accessing your portal for accountability.  Nor do you know who on the backend is working on your O365 deployment project.  Just too many unknowns to say it is secure.

O365/Azure Apps

But that's not the focus of this post.  A few weeks ago, O365 released the O365 APIs for Exchange (Mail, Contacts, Events and Files).  All of this piggybacks on Azure Active Directory for authorization utilizing the Consent Framework.  The Azure AD platform allows you to build an application that can make calls to Azure Active Directory or your O365 data. The permissions of the consent framework can allow an application to read the current mail item, all your mails items, your contacts, your calendar…your files. 

As a simple example, one of the more impressive abilities is to create a Mail App.  You can do this using Visual Studio 2013 and creating an App for Office project.  This isn't going to be a developer post so I'm not going to show you any code, but simply talk about the importance of "Mail Apps" and your users.

Once you have a Mail app created, you can deploy it to your O365 instance, or even post it in the Office store.   You can find a small set of mail apps in the following link (these have been publicly deployed to the office store, but you can have rogue apps that simply are registered somewhere in Azure AD and users give them ad hoc permissions):


Many of these are poorly designed (for example, the LinkedIn app is a total disaster, the cert is locally generated and not even a public CA).  In some cases, you may find the deployment endpoint isn't even available so the app install fails.  If you were to install one of these apps, you will find that they simply request access to the "current" mail item.  This is the preferred scenario if you were to use these apps.  In some cases however, you may find that the app is given "carte blanche" to your entire mail inbox.

So back to users and mail apps.  When you are in your Outlook, your users will ultimately find the settings icon and this nice menu item called "Manage Apps":


Clicking on this, they will be taken to the "Exchange" app center.  This is where you see administrator installed apps and user installed apps:


This is JUST for Exchange.  This has nothing to do with the bigger picture of Azure AD Apps and the consent framework.  There are some governance controls implemented in the Exchange app architecture, however, when it comes to Azure AD and your tenant, the story hasn't been written yet. This goes back to the premise of this blog post.  All it takes to make your highly secure O365 environment to be unsecure is:

  • A user
  • An App
  • A click 

The permissions given to that app can now comprise the integrity of your entire system.  When on-premise, you at least had the ability to prevent incoming requests using your router and DMZ.  In this instance, O365 doesn't have any of that, so once permissions have been given, that's all folks.  So what hacking scenario might come up?

  • Hacker builds an Azure app, puts your company name and logo on it
  • Hacker does some social engineering to find out your name, title, work phone number and other information
  • Hacker asks you to install the app and because it has your logo and company info, your user thinks nothing of it and clicks "trust"
  • Hacker can now gain access to an access token that can be used to download all your email and your my site files

If you are in defense or government, you know hacking enemy number one is China.  For those of you that think that insensitive to say, you haven't watched the traffic logs with the FBI and CIA as it happens, almost on a daily basis.  But the US is not a good guy when it comes to that stuff either, so all is fair in love and war.

O365/Azure App Governance

It is my suggestion, that you disable the ability for users to add apps.  It simply creates security holes that equate to users writing company checks that can't be cashed.  So, with that recommendation, can I provide you the steps to deny a user the ability for users to add apps" in your tenant, *sure*, thanks to some recently surfaced info (see below) [:D] (thanks to @richdizz, @jthake and @Matthias1o1) In terms of Exchange, there are some user roles in Exchange that you can "remove" to prevent users from deploying apps, these roles are enabled by default:


[UPDATE 6-5-2014]
After this post the following was brought to my attention from the O365 team.  It is a non-UI based way to disable all user consent, thanks to the O365 team for pushing this content out!:



Even with the above update, what is still not available to us is an Azure AD UI (to make it more apparent of the risk) that allows me to
disable apps, and/or designate a "safe/white list" of apps that my users *can* utilize in Exchange or Azure AD.

Just for kicks, I have created a UserVoice suggestion that more advanced App Governance features (such as a UI and white list) be added to Azure AD and O365, you can vote for it here:


My God, What Have You Done?

So, this brings up an interesting point.  Last night at the SanSpug.org meeting I announced that we have moved to Auth0.com as our auth mechanism as it provides the most flexibility and telemetry data.  One person asked, what is telemetry data?  I said every time you login, I get data about you (first name, last name, email, blah blah).  It freaked out half the group.  Only one person was educated enough to know which of the supported auth systems had the least amount of data being sent.  So again, this brings up that interesting point I started this paragraph with…do you know what apps you have simply just clicked on the "authorize" button just so you could use the app?  I bet you don't, my god, what have you done?  Think about all those apps across all your services (facebook, twitter, liveid, google, etc).  So in an effort to help you understand just how bad this is going to get with O365, based on how bad it has gotten in a general sense, here is the links to where you can check what you have authorized for each of the major platforms:














I suppose you could say that this page (http://youweburl/_layouts/15/viewlsts.aspx) is as close as it gets?  At a farm level, in O365:




Azure AD:


Back to the question…"My god, what have you done?"  After clicking on all those links, I'm sure you have an idea of just how bad the problem has gotten.  Some of you might be surprised to find out that your Hotmail/Outlook.com email and OneDrive (consumer) files have probably already been downloaded and analyzed by that cool app you gave permissions too.  Most of you that read my blogs are the cream of the intellectual crop.  You understand what that "Trust" dialog means.  For the rest of the population, not so much.  The meaning of the word "Trust" has been eroded by fancy graphics and the promise of a simple functionality at the expensive of selling your data soul to the app provider.  That all being said,  its time for enterprise solutions to have a "white list" to keep users from eroding the meaning of "Trust", to anyone's dog or cat.  One last thing on O365, no matter how secure you make the back end, its the front end that matters.


Azure Access Control Services (ACS) is dead

I recently went through the exciting process of setting up our SanSpug.org site to support various authentication mechanisms (LiveID, Google, Federated Auth, etc).  I started off using Azure Access Control Services (ACS) because I thought it had everything I could ever want in a login aggregation platform.  However, I soon realized that it just wasn't able to meet the simple needs of a small SharePoint User Group.  And now that I know it can't meet those needs, I doubt it really meets the needs of large organizations either. 

A bit about ACS

To be fair,  ACS was the first of its kind.  I remember when it was first released, it was sooooo cool.  It really was.  I built some cool labs off of it (the old UI), then the UI "disappeared" (at least, the link was gone from Azure at one point), only to reappear again in the latest incarnations.  ACS isn't a part of the main Azure portal.  It has its own interface, which has confused me to this day being that all the other services are moving into the current portal.  Here's a screen shot of the two:


Why they are separate probably has to do with (put some random excuse here, but likely because of "legacy" configurations). It would make much more sense that Azure added ACS as its own separate application in the Azure Portal. 

So what can we do with ACS?  If you are familiar with ADFS, then you get the point.  I can created "Identity Providers", "Relaying party applications" and claims rules between the two.  The latter being one of the strengths of ACS (Quick history lesson, ADFS 1.0 was a real piece of junk, that left only one option, that option being ACS. It could do all the things that ADFS 2.0 was about to do).  So what kinds of identity providers can we add?  Well, here they are:


Hmm, interesting.  So they have preconfigured providers for LiveID, Google and Yahoo.  Fair enough, those don't actually need an application (client id and client secret) created for them.  But "Facebook".  Ummm, that one needs an app created for it to do federated auth.  Ok, let's do it.  Added a facebook app used to be fairly easy back in the day, now the UI sucks.  And the process to get a simple "App Stub" created requires a canvas page?  Whatever.  Fail on facebook's part.  Ok, back to ACS.  So they are allowing us to do federated auth to OAuth providers.  Ok.  So how do I add others?  Like Twitter?  Maybe Yammer?  Oh…YOU CAN'T!  But you can do WS-Federation all day long.  Boring.  Oh, did I mention the Google one doesn't work anymore?  Yeah, Google seems to have disabled the interface that ACS was using.

Ok, so ACS is dead "to me".  So what do I do now?  Do I build my own?  Ugg, that means I need to register an app in EVERY possible OAuth provider on the planet.  Similar hoops to jump through (approve the app, screen shots, canvas page, terms…ugg, no thank you). 

Let's do some research, maybe someone built a better ACS?  Maybe someone did all that work to register an app EVERYWHERE? After a few google searches, some tweets…I find….Auth0.com. 

Auth0 is the ACS killer.  I have no doubt that after the right people at Microsoft see what they have built, Auth0 will be picked up in a M&A transaction.  I'm going to tell the guys to hold out and get 4-5 offers and bid the price up.  I have no doubt, they will go for $100Ms in a liquidity event.  So why are they so cool?  Because you can add ANYTHING!  Check this $^&%^% out!  Database, Social and Enterprise:

Database (think ASPNETDB – this is a biggy for SP2015 by they way):


Social (oh right…ACS gives us…Facebook…totally lame):



Wait…do you see the one at the bottom?  Yeah…that's SharePoint Apps for on-premises (courtesy of Chris Beckett consulting services).  Oh…do you see the O365 and Windows Azure AD one?  Oh yeah…that's Azure AD Apps…umm, so why are you using ACS again?

Telemetry and Metrics

Are you freaking kidding me?  ACS would never have thought this up.  You get telemetry on when and how your users are logging in:


The logs are also pretty sweet:


You see the profile JSON response in the Logs that contains the Access Token (if provided) so if you need to debug something, you have everything you need!


Wait…it gets better (but maybe a bit confusing for you that haven't been doing this stuff for a while).  In addition to allowing your Apps access to all these federated OAuth platforms, it itself is an App registry.  You can create your App in the Auth0 interface, which is then exposed as a WS-Federation end point!!!  Holy $%&^&$^!  Forced to use ACS, but you think it sucks like I do?  Hey…add your Auth0 WS-Federation endpoint, and just like one of those "I saw it on TV adds", "Set it and forget it!":



Oh baby…if they weren't already ahead of the competition.  This is the future.  Forget about all those APIs you have to write to and learn.  Why bother with the auth parts?  All you need is to call the API and get that JSON response back.  Here's what they support:



Do you have some ACS rules?  Yeah, they support that too…what they don't have is an ACS rule importer.  That would be so slick. Easily migrate from crappy old ACS, to shiny new Auth0:


Custom Emails:

Just to add insult to injury…woah…custom emails…custom whatever!  When someone hits your fed auth endpoint…send em an email based off the claims!


Is ACS Dead?  Yeah, to me it is.  To the masses that didn't know any better, consider yourself educated.  As the word spreads, I'm sure there will be a mass ACS exodus very soon!


SharePoint 2010 has explicit deny!

What?  Are you serious?  The DenyPermsMask column is used now???  Oh yeah my friends, it can be used now!  Unfortunately, it can't be used at the site/web level.  It is in the web application policy level where you can now specify the explicit deny on permissions.  We have been waiting for this since SP1 of SharePoint 2007!

You can configure explicit deny on the SharePoint Central Administration by:

  1. Open Central administration
  2. Click Applicaiton Management
  3. Select a web application
  4. In the ribbon click  Permission Policy
  5. Click "add Permission Policy Level"
  6. Give it a name like "My Deny Policy"
  7. Notice that all the site level permission are displayed with a Grant and a Deny check box!  Cool!


SharePoint 2010 Password Change Policy

SharePoint 2010 has a great new feature for setting your service account passwords for when your AD team has locked down the password policies.  In Central Administration you can click Security->Manage service accounts links, and after selecting the account, you can then set the passwords for these accounts from central administration.  You may get an Access Denied error via the Microsoft.SharePoint.Win32.SPNetApi32.NetUserChangePassword method.   This is very simply calling the C++ Netapi32.dll to change the password.  Reference this for more information:


In doing more research, any accounts that have "Do not allow user to change password" will fail to update the password.  The actual changing of the password is done as if it is the user changing it.  You should also watch out for the "Accounts can only change once per day setting", this would keep you from changing your password more than once in a single day.


SharePoint Site/List/Item Effective Permission Finder!

This is amazing, I was simply trying to figure out what the SharePoint Designer (Site->Contributor Settings) would do to permissions in the database.  So, I built this entire application to do it, but then realized after I got it built that SPDesigner simply creates a file in the _contributor_settings directory in the content database and doesn't tough anything else. DOH!  

This tool will find the effective permission for an object in a site.  It uses a combination of object model (to get the siteid) and direct calls to the content database (rather than slow object model).  This tool must be run by an administrator on a SP box in the farm.  I went ahead and added in my "Find empty permission objects" code too.

Oh, and by the way, there is a column called PermMaskDeny in the Roles table.  Even though SharePoint doesn't have a front end UI or object model deny mechanism…it seems they are thinking ahead to be able to implement explicit "deny" in SharePoint!  Maybe in 2010?  I did try setting it to something (all 1s), but it didn't do anything 🙁  Oh well…


Console program that dumps the contents of the Content Database (no SP Object Model)

I have been a big proponent of encrypting the content database for a long long time.  You can see that is proved via the event handlers and custom actions via SharePoint Designer labs that I have built in my 50064 course.  When you do encryption though, you gain security at the loss of functionality (Search, browsing, all kinds of things…).  But on the other hand, just leaving your content database for a DBA to handle means that you have a security hole (the DBA).  They simply have to run the attached program to dump the contents of the Content Database.  Super easy…super big hole…and…super fast!

using System;
using System.Collections;
using System.Collections.Generic;
using System.Data;
using System.Data.SqlClient;
using System.IO;
using System.Xml;
using System.Collections.Generic;
using System.Text;

namespace ConsoleApplication1
    class Program
        static void Main(string[] args)
            Hashtable ht = new Hashtable();
            SqlConnection conn = new SqlConnection("server=localhost;database=wss_Content;uid=sa;pwd=Pa$$w0rd");
            SqlCommand cmd = conn.CreateCommand();
            cmd.CommandType = CommandType.Text;
            cmd.CommandText = "select * from alldocs ad, alldocstreams ads where ad.id=ads.id";

            SqlDataReader reader = cmd.ExecuteReader();

            int count;

            while (reader.Read())
                string filename = reader["leafname"].ToString();

                if (ht.ContainsKey(filename))
                    int cnt = (int)ht[filename];
                    filename += cnt.ToString();
                    ht[filename] = cnt;
                    ht.Add(filename, 0);                   

                byte[] file = (byte[])reader["content"];
                File.WriteAllBytes("c:\" + filename, file);


            //Done stealing your data…press enter to walk away 🙂

Use auditing on your databases.


Most Commonly Missed Best Practice with Internet Sites

Wanna know what it is?  It is a disaster waiting to happen!  

Some day an IIS 6.0 vulnerability will come out that allows you to get administrator access to the _vti_bin directory of your SharePoint site.  You will then be able to execute a call to the Lists web service and delete the "Pages" document library!  

To prove it, do a search on Pages/default.aspx in google.  You will get a listing on all the sites on the internet that are running sharepoint as their internet site.  Check their _vti_bin directory access by appending /_vti_bin/lists.asmx

 If you get the web service page for the list service, that company has setup there site WRONG!

The correct way of doing things is to create an extended web application that HAS the _vti_bin and the original with the _vti_bin DELETED!  The original is the internet accessable one and the extended one is accessible only by internal staff (so you can use SharePoint Designer and such).

Anyone feel like writing a vulnerability and the code to delete all the pages  document libraries on the internet to prove my point???  Couldn't be too hard 🙂