Resolving Issues with Security Compromised DNN Sites

Yesterday I published a blog posting about a recently re-surfaced security vulnerability within the DNN/Evoq platform. In that post, I provided the steps necessary to mitigate the risks associated with the exploit. If you have not yet taken the steps listed in that posting, please be sure to take those steps immediately. This posting is geared towards the proper auditing, review, and resolution of any issues that might be present on a compromised site. Please note, even if you do not believe you were compromised PLEASE review the first section of this post to be sure.

Determining If Your Site Was Compromised

On the surface of the reported exploit, it would seem that simply checking for a "host" named user account that was not created before would be a proper indicator of a site compromise. However, based on details that I received from a few other parties, and continued analysis of compromised sites it isn't quite that simple. The first step in determining if your site is compromised is to look for ANY host account that you cannot identify. The username COULD be "host," or any other username. If you find a user account that you do not recognize, your site was accessed and please complete all of the reviews listed below. If not, please continue to the following additional checks.

The next place to check for an issue is your /install/install.config file, if this file shows an updated date different than the date of other files in the folder, continue with all audit steps below. Lastly, search for any recently added .aspx, .asp or .php files. If any are discovered, continue to the cleanup steps below.

Full Recovery Option

Before I get into the individual cleanup operations, I will point out one of the better options for those that do not update their sites very often. If you have a backup from a date prior to the creation of the user account, a rollback of the database and site files will be a quick way to resolve the issues with any changes and then you can secure your installation.

Manual Security Steps

If a full rollback is not an option, it is possible to take a systematic approach to the cleanup. The following are key areas that I have identified that need to be researched and cleaned. Special notes will apply in many areas and caution should be exercised when making these changes.

Find & Remove Maliciously Created Host User(s)

The first step is to identify the Host User accounts that were created. Once you have a listing of these users make note of the "UserId" value for them. Once you have a record of the UserId, you can delete the users to prevent future access. However, we will want to investigate if the user modified any content thus the need to store the UserId of each of these users.

Identify DNN Pages, Modules, or Portal Settings Changed

Using the UserId values collected in the prior step, we want to query the database to see if the user changed anything that they shouldn't have been able to do. The following query shows us looking for changes by a user with an id of 146

DECLARE @UserId INT
SET @UserId = 146

--Identify Pages Updated
SELECT TabId, TabName, LastModifiedOnDate
FROM Tabs
WHERE LastModifiedByUserID = @UserId

--Identify Modules Updated
SELECT *
FROM Modules
WHERE LastModifiedByUserID = @UserId

--Identify HTML Changes
SELECT *
FROM HtmlText
WHERE LastModifiedByUserId = @UserId

--Identify any portal settings
SELECT *
FROM PortalSettings
WHERE LastModifiedByUserID = @UserId

If you find ANY results here, you should review each change individually. The exact diagnosis is a bit beyond the scope of this blog post, but something that you will want to take very seriously.

Secure Host Settings

Sadly, in the cost of most sites that we have seen impacted, all host setting values are reverted to the default. As such, each host setting should be reviewed individually to ensure that it is set correctly. However, a few specific items to confirm.

1. Host Details: Portal Name, Email Address, and URL. These are being reverted to DNN Software
2. Show Copyright Credits: I recommend disabled
3. Performance Settings: I recommend my default of Memory based caching and Heavy Caching. (Will have reverted to defaults.)
4. Client Resource Management: If you had this enabled, you will need to re-enable it
5. SMTP Settings: These are most likely missing, you will need to re-configure them
6. Event Log Buffer: If you had this enabled you will need to re-enable it
7. Allowed File Extensions: REMOVE .aspx, asp, php if they exist in this allowed list.

With any host configuration, you will want to be sure to have a backup and validate the site functionality after these changes. However, they should be changes that you already did in the past.

Identify Newly Added Files

The next step is a bit harder depending on your hosting environment. However, you should look at ALL files recently created or updated in your application. Specifically looking for files with a .aspx, .php, or .asp extension. If you find a recent update you will want to validate that the file should exist and that if it is supposed to be there, such as /default.aspx that it doesn't have any new content included in it.

Conclusion

At this point in time, the steps above seem to have good success in getting any compromised site back to the proper configuration. I hope the above steps were helpful for those of you that are most likely stressed while dealing with a situation such as this. If there is anything that I can do, or that my company IowaComputerGurus, Inc can do to assist with your site recovery please let us know.

Special thanks to Mark Saunders for some additional insight and examples.