DotNetNuke DNN Spam Registrations Problem Fixed

DotNetNuke DNN Sites getting spam registrations – How to stop them

In recent weeks, many of our DNN websites have systematically been targeted for Spam New User Registrations. There has been some discussion around the how and why, and as much as we can tell, the problem is this:

1. Some script kiddy has bothered to write a bot that finds DNN websites. It is not even a good bot, because it is not capable of validating registrations to automated active email addresses. (If you are the creator of the bot… “YOU ARE DOING IT WRONG” as it is not going to bring the Google results you are looking for.)

2. The bot will attempt access to:  www.yoursite.com /?ctl=Register
?ctl=Register

3. This brings into play the default DNN registration process module.

4. This page is currently available if your site has either Public or Verified registrations enabled.

5. Tricks on derating the bot by raising the password complexity appeared to work a short time only.

6. Enabling the inbuilt Captcha is as good as useless, as almost any OCR application can break it.

7. A better simple solution is needed.

 

ReCaptcha is the FIX that is working well

Here at InteractiveWebs, we decided that we would enable Recapcha (a cleaver Google Initiative https://www.google.com/recaptcha/ ) that is harder to be machine broken, and test the results. We found that all the spam registrations stopped once Recaptcha was used.

To do this we created two Free DNN Modules to add Recaptcha to the URL that this bot is using to register on sites. The two modules are to support DNN 6.2 +  and 7x +.

The modules replace the standard captcha control to a recaptcha

From this:

DNNCaptcha

To this:

DNN Spam Registration Stop

This is a good link explaining how Recaptcha came into existence, and why it works well: https://www.youtube.com/watch?v=cQl6jUjFjp4

The Free Solution and Installing iWebs Regsiter

The free modules are available of download here: http://www.interactivewebs.com/DotNetNukeModules/ModuleDownloads.aspx

To install them and fix your site you will need to follow the instructions below:

Step 1 – Register your site for Recaptcah

Go to: https://www.google.com/recaptcha/intro/index.html  and register your domain, or domains. This will give you the ability to use recaptcha on your DNN sites on any domain you like.

DN Google Recaptcha

Step 2 – Copy the Public Key and Private Key for your Domain

You are going to need they keys that this site provides:

DNN Recaptcha Keys

Similar to these.

 

Step 3 – For you DNN site, Turn on the DNN Captcha system.

ADMIN>>SITE SETTINGS>> USER ACCOUNT SETTINGS>>  “Use CAPTCHA for registration” Ticked.

DNN Enable Captcha

Step 4 – Download and Install iWebs – Register

Install our “iwebs- register” module, making sure you pick the one that is for your DNN version.

  • DNN 6.2 And laters: iWebsRegister 62.6.3.0 PA.zip (at time of writing this)
  • DNN 7 and later:  iWebsRegister 72.7.1.0 PA.zip (at time of writing this)

Once installed, you need to add the module to a page as you would any other. We recommend adding it to it’s own page in the DNN Admin menu, and keeping the page Admin Only.

DNN Recaptcha Module Downlaod DNN Recaptcha Module

Step 5 – Configure the iWebs Register Module.

The module you are looking for is called: iWeb’s – Register – You can select the Settings from the module drop down as you would any other DNN module.

DNN Module Settings

 

Enter the Public Key and Private Keu information that you received from your Google Recaptcha registration of your domain. THEN SELECT UPDATE to save the information.

DNN Captcha Settings

Step 6 – Install the Register Control

After saving your public and private keys by clicking “update” you are ready to:

Click on the “Install Register Control”

This will inject the recaptcha setting into your website. So when you hit any registration URL (www.yoursite.com /?ctl=Register) you now get the recaptcah box.

Update to V2 of Recaptcha

Google has released what they call V2 of Recaptcha. We have update the module to support this. The process of updating to V2 goes like this.

1. By default, previously created recaptcha keys are V1. Any updated installs of our module will need to be put into V1 mode (in the settings) to keep working with your V1 keys that you have previously configured into the module. So after updating our module to the latest release, go into the module settings and enable V1 mode for the module to keep working.

2. V2 recaptcha is better than V1. So we would suggest that all users of the module update to V2. To do this, you update our module to the latest release, then go into the Google Recaptcha management page, and delete your domains security keys, then generate new keys for V2. They have instructions on that process, all be is hard to understand.

Once you have new V2 recaptcha keys, you update these new keys back into our module and ensure that the V1 mode is NOT enabled. The V2 recaptcha will then run on your site.

To Remove and Uninstall

Step 1. From the iwebs – Register module settings, click the “Restore Register Control”

DNN Remove Recaptcha

2. Uninstall the iwebs – Register module as you would any other DNN module.

 

Thoughts

This was a quick solution to some script kiddies attempt to attack DNN. I’m actually struggling to find the purpose (if you wrote the bot and you are reading this, I would love to hear why).  There is little threat by the registrations that I can find. More annoying that anything else. While Recaptcah can be broken, it would take some smarts or costs to use online services for the bot, so I suspect they will not bother and recaptcha will reign for this problem. In any case, if they spend some time and effort making the bot work for recaptcah, it is easy enough for us to implement some of the loads of other solutions available to stop them.

Donations

We included a donation button. If you find the solution, blog, research we did, modules we created and responses we provide to be helpful. Please consider throwing us a few $

DotNetNuke Can’t Login Index #: 0

The Problem

Index #: 0

image

Recently while working with a DotNetNuke website, we found that attempting to login to the site generated this error:

SQL Exception
Error Details
File 
Error   Index #: 0
Source: .Net SqlClient Data Provider
Class: 17
Number: 1105
Procedure: AddEventLog
Message: System.Data.SqlClient.SqlException: Could not allocate space for object ‘dbo.EventLog’.’PK_EventLogMaster’ in database ‘www.sitedatabase.com’ because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup. at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj) at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj) at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString) at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async) at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result) at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe) at System.Data.SqlClient.SqlCommand.ExecuteNonQuery() at Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteNonQuery(SqlConnection connection, CommandType commandType, String commandText, SqlParameter[] commandParameters) at Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteNonQuery(String connectionString, CommandType commandType, String commandText, SqlParameter[] commandParameters) at Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteNonQuery(String connectionString, String spName, Object[] parameterValues) at DotNetNuke.Services.Log.EventLog.DBLoggingProvider.SqlDataProvider.AddLog(String logGUID, String logTypeKey, Int32 logUserID, String logUserName, Int32 logPortalID, String logPortalName, DateTime logCreateDate, String logServerName, String logProperties, Int32 logConfigID) at DotNetNuke.Services.Log.EventLog.DBLoggingProvider.DBLoggingProvider.WriteLog(LogQueueItem logQueueItem)

After a investigating the site and server we found that this was caused by the SQL server running out of room on the disk hosting the database connected to this DNN site.

The Solution

Free up more space on the SQL database disk.

DotNetNuke Event message: Forms authentication failed for the request. Reason: The ticket supplied was invalid. EventID 1315

image

The Problem

We were receiving some really really strange behaviour with a dotnetnuke website.

The log files showed:

Event message: Forms authentication failed for the request. Reason: The ticket supplied was invalid. with EVENT ID 1315

 

The behaviour was this:

Login with Internet Explorer worked.

Login with some versions of firefox failed others worked

Login with Chrome failed.

When login failed, the browser would refresh and then show the page you were on before login.

Now in this instance we tried nearly everything we could think of. we tried different application pools different.net settings in IIS. and we hand we have a good idea of both server management and asp.net.

He also had is particularly confused that other DotNetNuke websites on this particular server were running just fine.

To cut a long story short the problem turned out to be very specific that site we were using.

Solution

We were in the process of migrating somebody else’s site to our servers, and we had exported their site and site content using the DotNetNuke template feature. Ordinarily this would work just fine, however in this case the user on the other website had defined the login.aspx page to have administrator only privileges. They had set the login link from the skin to automatically directed to the login.aspx webpage. In the site settings they had defined no page for the DotNetNuke login page.

What this meant was that as the user attempted login to the DotNetNuke website, the attempt to call the login.aspx page was made and the DotNetNuke automatic lockout protection system was called in to play. This lockout protection system will throw up the standard DotNetNuke login screen, if the page is either undefined or unavailable as with both the case with this website. It just so happens that this lockout protection system doesn’t work particularly well with chrome. That’s a whole not a problem and I don’t intend to solve.

The solution here was to login using Internet Explorer, enable permissions on the login.aspx page which in the DotNetNuke website was simply called login. I was then able to select this page as the login page in the admin/site settings page. Once the login page was correctly defined I then ensured that the login module that come standard with DotNetNuke was included on this page.

After making these changes to the settings, we stopped receiving the error message:

DotNetNuke Event message: Forms authentication failed for the request. Reason: The ticket supplied was invalid. EventID 1315

And the site continued to operate correctly from there. Now whilst this was a very particular configuration that was imported from an invalid template website. I have noticed that in forums discussing this event ID, nobody has come up with a solution suggesting to look for the validity of your login settings within DotNetNuke. Hence the reason for this blog post.

I hope that saves somebody a lot of time, as I blew nearly 2 days try to resolve this one.

If anybody needs assistance with this type of problem, please feel free to contact us on our website.