Archive
Monthly
Go
|
|
DNN Blog
May
18
Posted by:
cathal connolly
Monday, May 18, 2009 3:52:00 PM
Earlier today we received an email to the security@dotnetnuke.com address from a user concerned that there may be a potential DotNetNuke security issue (which we always appreciate, emails like this are vital to us ensuring the ongoing security of dotnetnuke - thousands of eyes are a lot better than our limited resources). They helpfully provided us with a link to a site that was hosting the vulnerability details, which showed an advisory with a posted date of yesterday, as well as the details of the exploit.
Based on the description of the exploit, and it's original quoted discovery date of May 2008, I was fairly sure this was an issue we'd resolved, but put together a test bed just in case (4.9.3, 5.0.1 and the forthcoming 5.1.0 releases), and was able to validate that it was an issue that we fixed it in the 4.8.3 release almost a year ago, so is not an issue for anyone running 4.8.3 or higher. You can view the original advistory at http://www.dotnetnuke.com/News/SecurityPolicy/SecurityBulletinno17/tabid/1162/Default.aspx . (note: Whilst the exploit is pretty limited, only allowing upload of files with safe extensions such as txt, if you're running an older version of DotNetNuke than that I recommend you upgrade to the latest version (4.9.3))
Just now, I also caught a post in the moderation queue from someone who had seen the same issue on another site, so though it was worth a quick blog post to reassure the community that this is not a new problem, and is only affecting sites that have not upgraded in over a year.
What's interesting is why this has happened now. As in the Windows world, most hacks do not come from unknown exploits (often called zero-day exploits), but in fact from older, known problems i.e. unpatched systems. It usually takes a little while for the knowledge of a problem to spread, and for someone to work out an effective way to use it. Over time, as well a number of vulnerability scanners will add code to detect this problem, which whilst important for organisations to ensure their software is up to date and safe, can also be used by potential hackers to track down vulnerable websites. Finally, you often see a sharp rise in exploits of a vulnerability when someone has taken the time to weaponize it i.e to write a tool that automatically performs the exploit, without any manual steps.
Judging by this issue suddenly being actively exploited a year after it was fixed, it's likely that either it's signature has been added to a vulnerability scanner, or else that a tool has been generated to aid in rapidly exploiting old DotNetNuke sites. An additional possibility is that a hacker group is trying to raise their profile by raising their hitcount of exploited sites. Whatever the reason, it's wise to check and make sure that you're sites are up to date.
|