Tags:
create new tag
, view all tags

Question

Our TWiki instance has been running for a few years. Two years ago, in Dakar, someone launched a year-long spam assault on the site using SQL injection methods, and pages became riddled with drug advertisements and links to illegal pharmaceutical sites. At that time, we upgraded to 4.0.5, which I believe was said to have solved this issue. However, this did not satisfy our community of users at the time, who demanded that we do more to prevent any similar damage in the future. As a result, we implemented a rigorous security system, backed by Kerberos and BasicAuth. This certainly keeps out unwanted spammers, but it also takes a toll on performance and slows down all TWiki operations, and the account and login regime has been confusing to some.

We've considered an upgrade to a later 4.1.x version, but this would not be feasible unless it would also include the removal of our current security scheme, and a reliance on the inherent security of current TWiki versions.

Unfortunately, it will take more than my word to convince the powers that be that the vulnerabilities have been removed, and that similar attacks will not be possible.

Is there any documentation of these attacks, the fix, and why this can't happen again in TWiki's current security model? My web searches have not been productive.

Thank you!

Environment

TWiki version: TWikiRelease04x00x05
TWiki plugins: DefaultPlugin, EmptyPlugin, InterwikiPlugin
Server OS: RHEL4u5 Linux
Web server: Apache 2.0.52
Perl version: 5.8.5
Client OS: OS X, RHEL4
Web Browser: Firefox 2
Categories: Security, Authorisation

-- JohnDeStefano - 21 Sep 2007

Answer

ALERT! If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

There has been a number of vulnerabilities resolved over the years.

We plug holes all the time. We also add features and and new holes can arise. And plugins that are not in the default distribution are not generally being audited for security. We simply cannot manage everything users upload to twiki.org.

I would love to answer your question, but you will have to be a little more specific on the type of vulnerability you were exposed to back in the old days.

-- KennethLavrsen - 22 Sep 2007

If it is "just" the WikiSpam and HtmlAttachmentSpam issue you can install the BlackListPlugin. You do not necessary need slow Kerberos to guard against spammers. Simply require auth for all edit and attach operations, disable the guest account, create an EditorGroup, and add add new registrations to that group after review.

-- PeterThoeny - 22 Sep 2007

John, it would be useful to know what injection methods were used. We are currently working on plugging the kind of holes that bite on a public site, and want to make sure we are plugging the right holes! There is at least one known hole where a TWiki site can be used to launch cross-site scripting attacks, which is in the process of being plugged, but we are not aware of any vulnerabilities that would compromise content on a correctly configured site itself.

-- CrawfordCurrie - 22 Sep 2007

Hi, and thank you very much for your follow-ups. I apologize for my message, which was intentionally vague: when these "attacks" were discovered, our entire server host was immediately confiscated and very few details were given to us. I believe that the main issue was the same outlined on Codev.SecurityAlertExecuteCommandsWithSearch, and that the Sandbox webs were exploited to display inappropriate content and links to illegitimate online pharmaceutical sites. The hotfix given on that page was applied, and the TWiki instance was upgraded to a later version, but it was not enough to convince the user community and, especially, the security team that the fix had eradicated the issue, and I'm afraid that showing them the page above, which includes reports of buggy patches, would further complicate things.

It seems to me that you guys are on top of things and proactive with regard to attacking issues as they are brought to your attention. That's good enough for me. But is there a "cleaner" version of the page mentioned above, that I could show to people as a "report" to prove that this vulnerability has been addressed? Is there a good archive or site for similar hacks you've encountered and fixes you've created in response to those?

-- JohnDeStefano - 24 Sep 2007

The SecurityAlertExecuteCommandsWithSearch issue has been fixed already in TWikiRelease04Sep2004. This is unrelated to WikiSpam and HtmlAttachmentSpam. You can point your management to these pages:

-- PeterThoeny - 25 Sep 2007

I installed the latest TWiki version (4.1.2) on a fresh server, and left it fairly intact, except for the following:

  • I moved the Sandbox web to the Trash
  • I made the Trash web unlisted
  • I made the UserRegistration topic readable only by the TWiki administrator account.

I did this so that the cyber-security team here would scan the site for vulnerabilities, which is a prerequisite for getting any web-based apps onto the web here. They ran a "Web Application Assessment" with a tool called WebInspect; after running 3.5 hours of tests they said the connection was interrupted, so they would need to run the test again. However, they wouldn't do so until I addressed the following "critical vulnerabilities" in the TWiki installation; I hope you can help me in figuring out how to address these:

The following were listed as critical "Cross-Site Scripting" vulnerabilities:

If I visit any of these "links," I get "Note: This topic does not exist".

The following were reported as critical "Account Information Disclosure (passwd) vulnerabilities:

If I visit either of these "links" I get "Template "oopsmoreal" not found." The only "passwd" file I could find in the installation is bin/passwd.

I'm not sure what to do next, especially since I don't understand where these results are coming from, but that will not stop anyone from preventing me from putting this online. I also didn't mention the 2 "high" and 452 "medium" vulnerabilities that were reported so far, but the critical ones are what I need to address at the moment.

Thanks.

-- JohnDeStefano - 29 Oct 2007

Sorry, closing this after more than 30 days of inactivity. Please feel free to re-open if needed.

-- PeterThoeny - 03 Dec 2007

-- JohnDeStefano - 03 Dec 2007

You are correct, that output is nonsensical and does nothing to assist you to improve security, which was supposedly their goal.

Assuming your cyber-security team has at least the most rudimentary competencies, they will be quite capable of explaining their odd sounding conclusions to you, in a way that shows you something resembling a real vulnerability that can be addressed. Their aim should be to assist in identifying and removing real vulnerabilities, but it's fallen over at the first step through lack of the prime essential of information security management: communication. Maybe it's your duty to prod them to get back on track.

If they cannot explain exactly how these outputs fit their own criteria, and what those criteria are based on, then perhaps your organisation has security management issues that are more critical to its security than any single application can be. You only have to ask, to know.

If there turns out to be real vulnerabilities that need addressing, please report that so we can fix it, but I can't see anything of substance from those terse examples.

-- SueBlake - 14 Jan 2008

Closing this question after more than 30 days of inactivity. Feel free to re-open if needed.

Look also into the SafeWikiPlugin.

-- PeterThoeny - 02 Mar 2008

Change status to:
Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r11 - 2008-03-02 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.