CMS Vulnerability Mitigation


  • Insecure solution required by School Center in order to achieve unified authentication (Public Exposure of LDAP)
  • Identified additional security holes with School Center’s CSM framework, specifically the ability to make a cross site form post to their login web form
  • Exposed those flaws to build a middle-layer solution securely in Organization’s DMZ Network Layer
  • Required no additional resources from other internal IT Teams
  • Completely mitigated the security risk to the organization while retaining unified authentication for all users

Detailed Explaination

School Center is the Content Management Solution for the Blue Valley School District as of August 2013 for all public facing web sites. This solution provides a framework for all the School Sites and the main District Site.

Unfortunately, we found after being forced to migrate our School Center solution from a hosted solution on site to a remotely hosted solution managed by School Center that the only way to authenticate our users against the Blue Valley LDAP server would be to expose an LDAP Server publicly and limit its ability to communicate by IP specific to School Center. The fundamental issue with this requirement is it is clearly exposed to a Man-In-The-Middle IP Spoof, meaning that if another entity faked the IP of School Center when they would be able to communicate with our LDAP Server. Despite making this security violation clear to School Center they refused to allow us to create a more secure solution such as a VPN on their network or ours.

My solution to this problem was to create a middle-ware security layer that would not expose our LDAP Server publicly and still allow our users to authenticate against our LDAP Server. After running an audit of School Center’s basic HTML form login, I found that they do not block a cross site script attack. Thus I have the ability to make a form post from any outside website directly to their HTML form. This opening in their form security was a key vulnerability which would allow my middle-ware solution to communicate automatically between our DMZ’ed network and School Center’s login form. I then created an application which used various static information contained in our Active Directory to create a unique string for each user. I then encrypted that string in an MD5 hash. It is that hash that would serve as the new “password” as far as School Center accounts for our users was concerned.

After I updated all of the Blue Valley Accounts on the School Center solution with the new password hash, I then created a login form on the Blue Valley DMZ that would first authenticate securely on our DMZ with our LDAP Server, then if the authentication was successful I generated the password hash, and create an automatic post to School Center using JavaScript. The end result being when a user logs in on our DMZ’ed form, they end up logged in at the remotely hosted School Center solution using their own AD password and keeping our LDAP server secured.

This solution, despite my long winded description, only took a couple of days to build and saved our networking and systems team a ton of time and effort to create a least privileges LDAP server which we knew would still ultimately be exposed to the previously noted IP Spoof.