-
VaultWiki News
by Published on January 23, 2016 11:14 AM
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.by Published on January 20, 2016 10:16 AM
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.by Published on January 8, 2016 10:10 AM
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.by Published on November 14, 2015 11:04 AM
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.by Published on October 31, 2015 9:03 PM
Today VaultWiki 4.0.7 is available. It fixes a slew of bugs since 4.0.6 and includes a handful of minor improvements.
Icon Color Properties
Most notably, you can now set the colors used by icons in the wiki content lists without modifying the CSS directly. There are a handful of new properties that let you customize the outline, fill color, gradient, and more.
Class Whitelist for TABLE, DIV, and SPAN BB-Codes
CSS class names that users could choose for TABLE, DIV, and SPAN elements have long been restricted to a small few of the default classes provided by the forum software. If admins wanted to allow other classes, they usually had to create plugins to change the whitelist.
As of 4.0.7, each BB-Code's whitelist can be modified on the admin edit screen for that BB-Code.
Expandable Headers
A major drawback of including wiki headers on other pages has been the amount of vertical real estate they use. In 4.0.7, we've added a new option to set header integrations to a collapsed state by default. This option can be set on a per-use basis.
Headers for Tags
When viewing the list of site content tagged with a certain term, you can now add a header integration to that list. This allows you to add a bit of much needed description about tags.
Release Notes
The current release is VaultWiki 4.0.7, which should be usable on vBulletin-based and XenForo-based production sites.by Published on October 31, 2015 7:05 PM
Earlier this month, we received a bug report in which a user had noticed that his wiki was sometimes giving the wrong users credit for certain tasks. After investigation, our developers noted that this bug could be leveraged to perform permissions escalation and inject HTML or Javascript into wiki content.
This issue affects all VaultWiki versions 4.0.0 Alpha 1 - 4.0.6, including VaultWiki Lite.
On October 14, we published the following Patch Level releases to resolve this issue:
- 4.0.6 Patch Level 3
- 4.0.5 Patch Level 3
- 4.0.4 Patch Level 3
- 4.0.3 Patch Level 3
- 4.0.2 Patch Level 6
- 4.0.1 Patch Level 9
- 4.0.0 Patch Level 8
- 4.0.0 RC 5 Patch Level 7
- 4.0.0 RC 4 Patch Level 8
If you are not already, we highly recommend that all users running VaultWiki 4.x in a production environment upgrade to a patched release as soon as possible to .by Published on October 11, 2015 12:02 PM
Last week, a user reported slow database activity that appeared to be related to normal VaultWiki usage. After an investigation, our developers determined that such a situation was the result of a security vulnerability.
Since this vulnerability is connected to normal forum and wiki activity, it does not require malicious intent for damage to result. At its core, it acts as a Denial of Service amplifier, which, after as little as 1 concurrent request to the vulnerable action (depending on other variables), can cripple the ability to perform basic tasks such as search or create posts for an unspecified length of time.
This issue affects VaultWiki versions 4.0.4 - 4.0.6, including VaultWiki Lite. This issue affects vBulletin-based installations only.
We have published the following Patch Level releases to resolve this issue:
4.0.6 Patch Level 2
4.0.5 Patch Level 2
4.0.4 Patch Level 2
We highly recommend that all users running VaultWiki 4.x under vBulletin in a production environment update to a patched release as soon as possible.
This site uses cookies to help personalize content, to tailor your experience, and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
By continuing to use this site, you are consenting to our use of cookies.