I was just hired to maintain and redesign various site the company has running on an old version of DNN. The site has been hacked and someone uploaded some directories and web.config files that were redirecting users to stream suspicious streaming sites. Also, the attacker added some scripts that show Google Ads on all the blog articles. Needless to say its a mess.
Nevertheless, I was able to go in there, deleted a super admin account (that's how they got in I think) , delete a few directories that had over a thousand html files for streaming sites and also deleted the old FCK Editor.
I am completely new to DNN and need some help with the directory and structure to try and see if I can resolve this. So far, I cannot get rid of the Google Ads in the blog and for the life of me I cannot find where the blog articles live inside the root/directory. When I go in there and delete the ads through the DNN UI the ads come back in hours or a couple of days. The directories with the html files have not returned. Just the ads.
I know that we have to upgrade but if I remove the ads I will have more to to develop the new sites without feeling rushed because of the current issue.
If anyone can point me in the right direction I would really appreciate it.
That sounds awful, as obviously someone (ore something) still manipulates your site from the outside (or inside?). There are a lot of issues on old DNN Versions, and the only thing I can really recommend is to find an upgrade path to the newest version. I don't know how big your site is, maybe it is easier to set it up from scratch with a new version (if the site is not too big).
The directory structure does not help you finding any content as everything is stored in a database. To be more specific I would need more information about the DNN version and the extensions (and versions of the extensions) in use, but disclosing this here in the public could be a security risk for you. You could write me a PM here if you wish to get in contact.
To find people (maybe in your area) who can help you could give these web sites a try: https://dnncommunity.org (Resources > Forums) and https://dodnn.work/.
It sounds like your site might have been impacted by a few different exploits, and most likely I would guess it is version 7.x or earlier and been upgraded from versions prior to that.
For the immediate need you are going to need to try and identify anything and everything that is out of the norm, this can be very daunting for those that are not familiar with the platform, but a few tips.
Look in the DB for data in the Header or Footer field of the TabModules table
Look for any rogue files that really should not be there, anything with an extension of (.php, .asp, etc.)
Look for rogue files in directories outside of the /Portals/* folder that don't match a DNN Install. (This takes a bit of personal experience.)
Look at your default.aspx file it should NOT have a recent modified date. If it does, compare it against the one that you get when you download the install package of that version of DNN
Now, once you have done this, be sure to do any mitigations that you can for known exploits. Including:
Delete /Install/Install.aspx
Delete /Install/InstallWizard.aspx
Disable any host account with a username of 'host' and create a new one if that was your only one
Feel free to email me directly as well if you need some help.
Related
My site is messed up and I am trying to fix it, and regardless of it I get help, it is going to take awhile likely, and it's really important that my site be live, even if it's a crappy version with just the articles and no template.
Would it not work to make a backup of the database, install Joomla fresh (the same version) and connect it to that duplicate database (then point my domain there) and then go back to working on fixing the current site that is live now? Are there any issues I should know about going in? There's a good chance the issues are related to the template or extensions (at least my understanding so far, see my other post for details on the issue) so I would think it would be faster to do this to get a working site rather than trying to turn off and on each extension, especially when I have to do it manually (and I don't know how yet) as I can't access the backend.
If this will work, do I choose the database when I install or just install empty and then change what database it connects to or do i install empty and import the tables (and how)? Still have to figure out if I can make a clone of the database and not all the files as it takes hours.
Thanks for the help, and if I should have appended this to the other post I apologize, but I figured its a separate issue.
First, ensure you have backups of both the files and the database. Then make a local copy of your site where you will work later.
The infection may lie:
in the Joomla core files, with extra content (which is usually fairly easy to spot, for example an eval of a large base64-encoded variable);
in extra files (keep in mind that even images could contain malicious code), these would be usually triggered outside of Joomla for spamming or other nefarious purposes
in the database content.
Fix:
Apply a fresh Joomla update package over your site; you will only fix n.1 above. This may restore some functionality for the first hour of survival.
Analyse the logs, and try to figure out how they got in. You need to step up security as obviously what you have is not enough.
Install a fresh Joomla, add all extensions that your site uses, copy the images folder, then connect it to a copy of the compromised database. This will fix n.1 and 2 above (as you got rid of any extra files). This may survive until they figure out you fixed it; but if you haven't patched your security, they will hack into your site again. Keep a copy of this, and restore as needed as you proceed with the following step.
Export the db to sql format (mysqldump or phpmyadmin may come in handy), then search for any xss traces, php code, javascripts that may have been injected. Since a complete control could take days, and assuming the malicious code links elsewhere, look for strings such as "https://" and "http://"; escape / as \/ and \\\/ to account for json-encoded data as well.
Once the db is clean, your local copy is reasonably safe; update all extensions and Joomla, and use it to restore the website until you fix your security.
It might work, i mean cloning the DB as far as joomla version is the same. It won't break like that, but may fail if files for extensions are not found. This is somewhat wrong, the question is how many extensions you are using and how much cleansing you need.
On the other side you mention that the site should be 'live'. Just do everything on localhost, test, fix templates, etc. Then if you're sure you're done, use akeeba backup and deploy new version to your server without long delays.
Any kind of cleansing needs some start.
You can clean the site while live, depends on complexity.
Clean might be done offline and deployed.
Sometimes import/export custom routines are needed, so you have to make own tools for everything. It occurs with large data, like when people used to made mess inside images folder or something like that.
4 ...
It's pointless to make copies of DB. You install the same version of Joomla on your local server, then you install the same template, you copy styles etc.
Then you import data with your own tools or paid ones. Estimated time is from few hours to few days, it's just data :)
We're designing a system for a client where they are allowing authenticated users to upload images. We've created an API to upload the files but the client only wants the latest file and delete all previous ones so that there would only ever be one.
We've looked through the docs and can't come across a way for ADAM to handle this in both 2SXC and DNN's file system.
Internally when deleting images we see API calls like the following to the internal 2SXC API, but we're wondering if this is exposed somewhere within the public API?
https://somedomain.com/api/2sxc/app/auto/data/61393528-b401-411f-a001-f423ea46700a/b7d04e2c-c565-496c-8efb-aa133cf90d33/Photo/delete?subfolder=&isFolder=false&id=189&usePortalRoot=false&appId=3
We could probably use the same endpoint above, but we'd likely run into permission issues or changes to the APIs that could be problematic.
Thank you for any advice you can give! Perhaps #iJungleBoy can provide some thoughts on this.
As a solution from a completely different direction, if you are on the later release of 2sxc (v12.8+, v13+), and comfortable programming in C#, you might consider doing this as a "cleanup" from a Dnn Scheduled Task. This can be done with a relatively easy setup. We have a Gist in place that we use as a starter. You simply put the code in the /App_Code folder then setup a normal Dnn Scheduled Task. NOTE that you can scroll down to the first comment on the Gist to see a screenshot of a complete working setup.
Accuraty's AccuTasks template on GitHub Gists
There are two more key things to note:
You need to install Dnn's CodeDom 3.6 because the example uses the later versions C#'s string interpolation - OR remove the few $"ASL2021 - {this.GetType().Name}, Task Scheduled Email", bits or convert to string.Format() or something.
Since your task's code is NOT running in a (2sxc) module, if needed, you'll do stuff like this: 2sxc Docs - Use 2sxc Instance or App Data from External C# Code
So, if you are comfortable writing code that "finds and deletes stuff older than NN days" - this might be the way to go.
I have finally my project ready to go live, is there a check list of things to go through before uploading the files to the webserver?
Are there any Files or Folders to be deleted before going live.
Version of cake: 2.3.8
I found out to set the debug level to 0.
Set the cookie in core.php
Do I need to remove the following folders?
/app/Console
/lib/Cake/Test
/lib/Cake/TestSuite
Any other security advise please?
Thanks a lot.
Don't deploy anything to production that isn't needed. If your project doesn't require those folders to function, then don't deploy them.
Make sure to check out the short deployment guide from the cake docs.
Also here's a more general website launch checklist.
I recommend making sure your deployment process resets caches appropriately. This can differ depending on how you have things set up, but by default CakePHP uses a file cache. Regardless, it can really hose you to let the cache linger when things should be updated like model schema, etc. For example, see my answer to another StackOverflow question.
i'm trying to find a good UAPROF website but only i can see that http://www.uaprof.com/ . I need UAPROFS of HTC and in that web a lot of links are broken. Do you know another web or resource to find that UAPROFS ?
Thank you in advance for your attention.
The Open Mobile Alliance validator keeps links to validated profiles. However the manufacturers do remove old profiles, or in some cases the manufacturers no longer exist, which is probably why you are seeing broken links at uaprof.com.
Google is another good source of profiles by searching for "uaprof filetype:xml" and "uaprof filetype:rdf".
Alternatively check out WURFL. This is not UAProf, but the data is derived from UAProf, it's XML so it is easier to process, and it is curated so it will not have the same problems.
There are more UAProf resources at the DELI website.
We have noticed that when after retracting a MOSS solution package, we are still left with incorrect leaf entries in the alldocs MOSS database table. This is an issue if for example we rename a feature that deploys the same artifacts - MOSS will then not let us deploy the solution as it thinks these items already exist.
Would be interested to hear if anyone else has had this problem.
Depending on the solution, SharePoint doesn't always clean everything up. However you must never touch the SharePoint database! Even querying it is not supported as this can cause locking issues that will make the application unreliable. Also see KB 841057.
There should always be a way to solve the problem via the SharePoint API. Once you've found it, add the clean up code to a feature receiver so that it executes when the feature is deactivated. If you need help, please ask in a new question with the code/schema you are using.
Depending on the error you are receiving, the tools on these pages may also help:
WssRemoveFeatureFromSite
Dealing with abducted SharePoint features
I Agree with Alex, this shouldn't concern you and the fact that you've noticed this means that you have more than a a healthy interest in the sharepoint DB.
Practical explanations maybe that you created assets (e.g. listitems) that have references to the solution (content types, site columns etc) and so these are orphaned when the solution is removed, of course when you re install the solution these assets will work correctly so its not all bad.