4 Rock Impersonation Token Leak (RCKIPID) Shared by Chuck Bump, Southeast Christian Church 2 months ago 7.0 Operations, Web Intermediate Note: This recipe was written with the knowledge that this is less of a recipe on how to do something cool or how to put something appetizing together for your organization and more of a howto guide for when things go horribly wrong. The ScenarioSo, imagine you've created a really cool new feature on your website using Lava and then you decide to share about that via an email communication. In that communication you include a link to the feature and that link includes a Person Token (Impersonation Token) so the user will automatically be authenticated when they land on the page. In this scenario, you don't limit the usage of the Person Token to a single use or within a timeframe so the token will be good for the rest of eternity. One of the recipients of the email has a blog and often shares information about your church . . . and your really cool new feature is the subject of their latest blog post. Unfortunately, when they write about this they include the link including the token which automatically logs everyone in when they land on the site. As this blog post goes viral so does the number of browser sessions logged in as the blogger! HELP! 1. Delete the Person TokenThe first step is to ensure that the leak is fixed. Simply removing the token from the database is the easiest way to do this To get started, find the person id of the individual whose account has been exposed. Use the following query to delete any impersonation tokens connected to that person: DECLARE @PersonId INT = 0; DELETE FROM [PersonToken] WHERE PersonAliasId IN ( SELECT PersonId FROM [PersonAlias] WHERE PersonId = @PersonId ); 2. Log Everyone OutThis is a little trickier. Firstly, it's important to know why this is necessary. The default browser session within Rock can vary from church-to-church depending on how things are configured but, in general, if even 1 browser session exists out on the internet where that user is authenticated as the wrong person then you want to make sure a subsequent visit by that browser won't result in further compromise. To handle that it's easiest to just invalidate every single session on your Rock install (log EVERYONE out). The easiest way to do that is to rename the forms authentication cookie in your web.config file for your Rock install. Locate the following line in your web.config: <authentication mode="Forms"> <forms name=".ROCK" loginurl="Login" defaulturl="Page/12" timeout="43200"></forms> </authentication> In this situation, simply changing the name from ".ROCK" to something else (something like .YOURCHURCH) will automatically invalidate any authentication cookies in any browser out there. Also, please note, this will automatically log anyone out of any Rock site including the admin/internal sites! 3. Disclose the Situation In the event a situation like this occurs in your organization, it is best to disclose this as soon as possible to the parties affected. Our normal procedure involves reporting the issue to any leadership who may need to know (Legal, Audit/Insurance etc) and then contacting the individual who's account was exposed to let them about the situation. We usually also offer to pay for 1 year of identity theft insurance for anyone who's account information may have been viewed by a 3rd party. Be as prepared as possible for this conversation. Being able to explain what happened in both a technical and simple manner will help. Obviously, this conversation can be a bit uncomfortable but proactively handling this situation is best.