Dear DNN Community,
We have a lot of clients that use DNN. Between 5:30AM and 6:00 am EDT on May 25th there were attempted attacks on everyone of their sites (which are hosted in different locations around North America). Many of the attacks successfully exploited the install wizard vulnerability. What through us off in our diagnosis is that even clients that were using the 7.04.02 build, which supposedly patched the vulnerability were exploited - so it took us some time to figure out what was happening. It turns out that even though they had 7.04.02, the security analyzer was not operating due to a bug in the install routine: clients that had first upgraded to 7.04.01 and then 7.04.02 were OK, but for those that went directly to 7.04.02 from an earlier version, the security analyzer was not operational and the vulnerable install files were still there after installing 7.04.02.
We went out and patched all of our clients sites (note that we also host but none of our hosted sites were compromised because they site behind an IDS and they were based upon a fresh DNN 7.04.02 installs and not upgrades). However, all of the sites which had been successfully exploited were infected with a procedure that will pop open a message for some but not all customers using their website saying that their computer's internet security was at risk and provided them instructions to call a number for technical support. This is a new twist on a scam that came up in 2015 where the user calls the number, the "technical support" on the other side says we can take care of it but we need to connect to your machine, and then they lock the user's machine and require a ransom to unlock it. Very scary stuff. The attack btw came from a Chinese IP address and the code that downloads to a user's machine (not really code - will explain) comes from a Russian web site. It's like your worst nightmare.
I surmise that many thousands of sites are compromised right now with this scam. So here is an explanation of how it works and how to remove it (this is based on an email I sent our web analysts at 3am on Thursday morning):
1) There was a security vulnerability in the install wizard in DNN prior to version 7.04.01. The sites that have been hacked are version 7.04.02 so they should not have been hacked. In 7.04.01 a new module was added called Security Analyzer and it closed the hack, basically by deleting the these files from the install folder: InstallWizard.aspx, InstallWizard.aspx.cs, UpgradeWizard.aspx and UpgradeWizard.aspx.cs.
2) However, there are reported cases of the installation process for the security analyzer module NOT properly installing when upgrading to 7.04.02 from a version prior to 7.04.01. There was a follow up patch that made sure it gets installed correctly under 7.04.02.
3) Last night at 3am I went to run the security analyzer on three websites that were hacked and it was there HOWEVER it was not enabled (the install issue). So I manually enabled it by creating a page called Security Analyzer under Host and adding the Security Analyzer module to it.
4) I also checked a bunch of other DNN sites for the hack, e.g., the sites on cvsapphire and Euclid’s own site and they were not hacked even though they also are version 7.04.02. THE DIFFERENCE IS THAT THE SECURITY ANALYZER was enabled.
5) Hence, DNN versions prior to 7.04.01 or those that do not have the security analyzer module properly installed are at risk.
6) The hackers are then using the security vulnerability to upload the malicious files with aspx or asp extensions into the images folder and in some cases create new super user accounts. In one client the files were named imgs.aspx and imgs.asp and in another client the files were named safm.asp and wso.aspx). These files are then executed from the images folder and the hacker gets access to files, but not above the portal (which is good because it means they could not get access to root files). The web.config file changed, but that was only done because the install was rerun and the web config file time stamp changed (I restored a copy of one of the clients web.config file from3 days ago and compared it to the current version and it is no different).
a. In two client’s case, they used the super user account to add iframe code to the header and/or footer of the banner module
b. In one client’s case they added the iframe source code to the default.aspx in the portal root but did not make changes in the database.
So here is what is needed to clean this up – Please go out to each client’s site that we have access to and patch them. Do not even get their approval (even if the site is not hosted by us) – we will follow up with them afterward.
NOTE: The security analyzer module is backward compatible to DNN v. 6.02. Hence, if clients are running versions of DNN prior to 7.04.01, they can just install the security analyzer extension and not upgrade right away (which could create other problems).
1) Delete the InstallWizard.aspx, InstallWizard.aspx.cs, UpgradeWizard.aspx and UpgradeWizard.cs files from the install folder. (this will prevent another hack)
2) Search the complete DNN folder for files changed in the last two days. Generally the initial file that allows for access will be in the images folder of the portal folder (e.g., the .asp or .aspx file). Get a copy of this file for records and then delete it. Also record any other suspicious files.
3) Use notepad ++ to look for any files containing %logsrigrip.top%. (in case they used the file modification method). Remove the iframe entry with this code in it. Usually it is the default.aspx file that is being modified.
4) Search the DNN database for the super user accounts that were created and for the %logsrigrip.top% by using the SQL Script below
--diagnostics
select * from dbo.users where IsSuperUser = 1
select * from TabModules where Header like '%logsrigrip%'
select * from TabModules where Footer like '%logsrigrip%'
-- select * from TabModules where LastModifiedOnDate >= '5/24/2016'
--fix data – look for accounts created in last 48 hours
delete from dbo.Users where Username='host'
delete from dbo.Users where Username='dnnuser'
update TabModules set Header = null where Header like '%logsrigrip%’
update TabModules set Footer = null where Footer like '%logsrigrip%'
Also for safety, use the searchtables utility stored procedure to look for '%logsrigrip%' in every table and every field, and if there, remove accordingly.
5) Using the host admin account (if we have access to it), delete the cache and recycle the application pool. Then for safety, restart IIS – we want to make sure that none of the pages are cached.
6) If they do not have Security Analyzer module installed, install it and then run the checks.
I'll see you early in the AM - this is of the most urgent matter.
Charlie