VaultWiki News

This Tuesday, we released another set of patch releases, which addresses three (3) security-related issues in VaultWiki of varying severity:

The "Greedy Widget Vulnerability" enabled malicious users to create a denial of service condition using malformed WIDGET BB-Codes. The issue existed since VaultWiki 4.0.0 RC 3, but it did not affect VaultWiki Lite.

The "Blabbermouth Vulnerability" enabled users to bypass view restrictions on private forums and wiki areas in order to obtain the names of content items in those locations and certain metadata about those items. The issue existed since VaultWiki 4.0.0 RC 3, but it did not affect VaultWiki Lite.

The "Presumptuous Post Vulnerability" enabled users to bypass view restrictions on some deleted or moderated wiki content. The issue existed since VaultWiki 4.0.0 Beta 1, including VaultWiki Lite, but it only affected XenForo platforms.

We have published the following Patch Level releases to resolve these issues:

• 4.0.8 Patch Level 2
• 4.0.7 Patch Level 3
• 4.0.6 Patch Level 6
• 4.0.5 Patch Level 6
• 4.0.4 Patch Level 6
• 4.0.3 Patch Level 6
• 4.0.2 Patch Level 9

We highly recommend that all users running VaultWiki in a production environment update to a patched release as soon as possible.

On Thursday, we released a number of new patch releases. Over the preceding 2 weeks, users and developers had uncovered a combined total of three (3) major issues in VaultWiki:

The "Balloon Vulnerability" enabled malicious users to create a denial of service condition using specially crafted WIKI BB-Codes. The issue existed in all versions of VaultWiki 2.x, 3.x, and 4.x series, including VaultWiki Lite.

The "Relative Vulnerability" enabled malicious users to craft links on third-party sites pointing to VaultWiki content that would display embedded HTML/Javascript code in the wiki content when the link was followed. The issue existed in all versions of VaultWiki 4.x series, including VaultWiki Lite.

The "Bulk Overload Vulnerability" enabled malicious users to create a denial of service condition by abusing content creation tools. The issue existed in all versions starting with VaultWiki 4.0.4, including VaultWiki Lite.

We have published the following Patch Level releases to resolve these issues:

• 4.0.8 Patch Level 1
• 4.0.7 Patch Level 2
• 4.0.6 Patch Level 5
• 4.0.5 Patch Level 5
• 4.0.4 Patch Level 5
• 4.0.3 Patch Level 5
• 4.0.2 Patch Level 8
• 4.0.1 Patch Level 11

We highly recommend that all users running any version of VaultWiki in a production environment update to a patched release as soon as possible.

In response to the recent hack on our web server, as of January 23, 2016, we have implemented the following changes to our Support Ticket service and related policies.

Customers should feel confident that if our web server is ever compromised again, data submitted via the ticket system before the potential hack will still be secure.

Ticketing Changes

The first thing many users of our ticket system may notice is the changes to the submission form.

We are now more clear about which fields are required and which ones will be treated as sensitive data.

* indicates a required field
 indicates a field safe for sensitive data

This is important: with the new changes, some fields will become encrypted and will not be readable after they are saved. For better security, asymmetric encryption is used, so there are no unlock codes stored on the server anymore.

However, other fields which will be used to track the status of a ticket will still not be encrypted. It is important that users never enter sensitive data into a field unless it is marked with .

The distinction between sensitive and non-sensitive fields makes it easier to ensure that information that should not be duplicated when alerting support personnel about new tickets or when a customer and personnel discuss a ticket.

At the bottom of the submission form you will notice a new "Disclaimer" section. This section outlines how the data you enter is handled, what our responsibilities regarding that data are, and what your responsibilities are.



The disclaimer mentions this: we have changed the file structures and data management routines for saved tickets. Sensitive ticket data is now stored in a location would be harder to find in a compromised situation. The location is never included in any server backups and if it is found, is encrypted in a way that cannot be restored using information existing solely on the server. When a ticket is closed, the data in that location is removed, so a brute force attempt can never be attempted against it.

Our local encryption keys for unlocking ticket data will be changed on a frequent basis. Tickets created using old encryption keys will not be readable using new keys.

Customer Responsibility

You should never submit permanent or your everyday login information via the ticketing system. Always use temporary FTP and site user accounts for tickets.

When a ticket is submitted, support personnel will typically follow up via private messaging on the web site, as has been standard practice. However, you should NEVER submit sensitive information via private messaging, forum posts, or anywhere other than the ticketing system, because only the ticketing system is encrypted. If you receive a private message suggesting that there was an error in the sensitive data you submitted, you should submit a new ticket. Do not send the corrections over private message.

You will now receive clear notifications when someone is working on your ticket and when your ticket has been closed. When the ticket is closed, you should change the passwords of the temporary accounts you provided.

Summary

As always, the VaultWiki.org web site uses TLS encryption to handle form submissions and your data cannot be read directly by a MITM attack.

With these changes, the only ways an attacker would be able to gain unauthorized access to your server using credentials you provide via our ticketing system are as follows:

• A screen reader or keylogger on your own computer when you submit the ticket
• Your submission is captured by a MITM attack and a brute force attack is performed against the captured data
• A screen reader or keylogger on our computers when we respond to your ticket
• A brute force attack against the ticket data while the ticket remains open

Please note that hackers can attempt brute force attacks against data that was sent over encrypted connections anywhere, and although it might take many years to succeed, that is one reason why it is important for anyone to change passwords regularly.

Other Ticketing Improvements

We have added a new section to the Members tab called "Tickets". This makes it more obvious how to submit tickets, and also gives you a way to check on the status of your ticket later.

Conclusion

We hope you enjoy the new ticket system. This is just one of the steps we've taken this week to improving customer security, and one of the many that we need to take to rebuild your trust in us.

Update as of January 21, 2016: We have learned that our initial estimate that only tickets submitted after December 2014 could be accessed was incorrect. In fact, today we were able to locate archived versions of very old tickets as early as 2011. It would be safe to assume that if you EVER requested a service through our ticket system, the data was preserved somewhere, and you may be vulnerable. We are now in the process of removing all old tickets from the system.

---

After reviewing recent backup data, we have become aware that on January 9, 2016, masked by a period of peak activity, there was a security breach on the web server that hosts VaultWiki.org for a period of about 40 minutes.

If You Read Nothing Else

It is possible that the attacker has obtained email addresses of anyone who sent email messages to vaultwiki.org since January 2010 or who was a member of the vaultwiki.org web site since March 2008.

If you ever submitted a "Ticket Support", "Install", "Upgrade", or "Import" service, the attacker may have obtained the following information:

• FTP server address and login information as of the ticket date
• Forum address and admin login information as of the ticket date

If you think you may have submitted non-temporary or currently-valid login information, we STRONGLY urge you to update your FTP and forum admin passwords immediately.

Please take any other steps you deem necessary to protect yourself.

Details

We have mounted an investigation, and we have already identified and closed the vulnerability that the perpetrator used to enter our system. We are also taking further steps this week to improve the security of our systems should any other currently unknown vulnerability be exploited in the future.

Our logs for the minutes when the intruder was present suggest only that he (or she) was attempting to gain root privileges, and that it is unlikely that any significant amount of data was stolen, if any. However, you should still take steps to protect yourself.

The intruder certainly did have the opportunity to access the following data:

• Contact emails to our support staff. This includes email copies of Private Messages submitted to staff on our web site. This potentially includes every email message going back over 5 years. Some of those messages, dating back to March 2011, are known to contain sensitive login information.
• By using PHP to read and/or download it, the web site's database and daily database backups. Including the backups, this includes Support Tickets submitted on our web site as far back as December 2014.

How We Were Hacked

The attacker found our web site with a Google.com search for the vBSEO footer copyright. After obtaining a login, the attacker exploited a known remote code execution vulnerability in vBSEO. Unfortunately, since vBSEO has been defunct for a number of years, it was never patched by the developer Crawlability, Inc., and for whatever reason, we did not receive a notification when vBulletin Solutions made the goodwill gesture to notify their own clients of the issue. Thus, we remained vulnerable, and the attacker was able to upload a number of foreign PHP scripts onto our server on January 9. The attacker was tidy and did not cause a scene. It appears that he simply uploaded a few PHP scripts, then attempted to escalate privileges beyond the PHP user. When this failed, the attacker left.

Steps We Have Taken

• We have cleaned all suspicious PHP scripts from our server and our server backups.
• We have run system-wide scans, and are virus free.
• In defense of unknown vBSEO vulnerabilities, we have completely removed vBSEO from VaultWiki.org.
• To protect individual accounts and licensing, we have reset all VaultWiki.org user passwords. You will need to use the password recovery form in order to login again: https://www.vaultwiki.org/login.php?do=lostpw
• We have taken care to re-evaluate and tweak the PHP user's permissions to prevent similar attacks while maintaining functionality.
• We are currently working on a new ticket system design that does not store any credentials in the database and where the PHP user cannot read any credentials after they have been submitted. We hope to have it operational by week's end.
• We have notified our agents, should they advise a legal course against the perpetrator.

At this point in time, we believe that VaultWiki.org is now secure and that business can proceed normally. We certainly regret this has happened and consider that this situation as a violation of the trust between us and our customers. We hope that we can rebuild that trust in the coming weeks and months.

Late in December, we quietly released VaultWiki 4.0.8. It is a relatively large maintenance release compared to recent versions, containing roughly 100 bug fixes.

Customizable History Colors

In 4.0.8, we have added new style properties for each of the status colors used on history pages. You can now customize these colors to fit better with each of your site's themes.

Release Notes

The current release is VaultWiki 4.0.8, which should be usable on vBulletin-based and XenForo-based production sites.

Over the past week, our users and developers have uncovered a combined total of four (4) issues in VaultWiki, that can either be exploited to create a denial of service condition or will create a denial of service condition automatically.

The "Tag Duplication Vulnerability" creates the condition automatically, and it affects VaultWiki 4.0.7 on XenForo only.

The "Node Overload Vulnerability" and "Template Expansion Vulnerability" exist in all versions of VaultWiki 2.x, 3.x, and 4.x series.

The "Template Usage Vulnerability" exists in all versions of VaultWiki 2.3.x, 2.5.x, 3.x, and 4.x series.

These vulnerabilities do not require any technical expertise to exploit. Most of them simply require tedious work and abuse of existing features for an attacker (or group of attackers) to create the condition.

"Node Overload" affects VaultWiki Lite 4.0.0 - 4.0.7.

We have published the following Patch Level releases to resolve these issues:

• 4.0.7 Patch Level 1
• 4.0.6 Patch Level 4
• 4.0.5 Patch Level 4
• 4.0.4 Patch Level 4
• 4.0.3 Patch Level 4
• 4.0.2 Patch Level 7
• 4.0.1 Patch Level 10
• 4.0.0 Patch Level 9
• 4.0.0 RC 5 Patch Level 8

We highly recommend that all users running any version of VaultWiki in a production environment update to a patched release as soon as possible.