Dovestones Software AD Self Password Reset (CVE-2015-8267)

Software AD Self Password Reset v3.0 by Dovestones Software contains a critical vulnerability in the password change functionality, that allows unauthenticated users to change the password of arbitrary accounts.

The vendor has been working with customers to upgrade them to a fixed version.

The /Reset/ChangePass function doesn’t validate that the validation questions have been answered, or validate that the account in question is enrolled. This allows an attacker to reset any account that the service account is able to reset, even if they aren’t enrolled.

The PasswordReset.Controllers.ResetController.ChangePasswordIndex() method in PasswordReset.dll fails to properly validate the user, and performs the password reset on arbitrary accounts.


Successful response:

VU#757840 – Dovestones Software AD Self Password Reset fails to properly restrict password reset request to authorized users

CVE: CVE-2015-8267

access control


Dovestones Software AD Self Password Reset fails to properly validate users, which enables an unauthenticated attacker to reset passwords for arbitrary accounts.


CWE-284: Improper Access Control – CVE-2015-8267

Dovestones Software AD Self Password Reset contains a vulnerable method PasswordReset.Controllers.ResetController.ChangePasswordIndex() in PasswordReset.dll that fails to validate the requesting user. An attacker can reset passwords for arbitrary accounts by manipulating web application requests that call the vulnerable method.


A remote, unauthenticated attacker can reset passwords for arbitrary accounts where usernames are known or can be guessed.


Apply an update

The vendor has worked directly with customers to apply updates for this and other vulnerabilities. Users who have not received an update are encouraged to contact the vendor.



Thanks to Adam Caudill for reporting this vulnerability.

This document was written by Joel Land.

Special thanks to Dovestones for their quick response, and US CERT for their help in coordinating disclosure.

Making BadUSB Work For You – DerbyCon

Last week Brandon Wilson and I were honored to speak at DerbyCon, on the work we’ve been doing on the Phison controller found in many USB thumb drives. This was my first time speaking at DerbyCon – it’s a great event, with a fantastic team making the magic happen.


Video (which I’ve haven’t been able to bring myself to watch):

Now that the dust has settled, I would like to provide some updates, thoughts, and extra information – and maybe correct an error I made during the presentation.

The Demos

We did three demos – they were simple enough that I didn’t think there was any risk of having issues. Well, lesson learned.

The machine we used was a fresh Windows install just for the talk – though in the rush, there were a couple differences between it and the machine we had been testing with. In the panic of trying to get the talk done in the short 25-minute slot, I mistook these differences for a failing of one of the demos.

Custom HID Firmware

The first of the three demos was a completely custom firmware, that presents itself as a HID device (and as a mass storage device, though without media present – this is to make firmware updates easier) – the demo went without a hitch.

I would have liked to show the tools and the update process, though there just wasn’t time. Brandon is working on videos that will be posted to YouTube that walks through each demo step by step.

The team behind the Rubber Ducky saved us a lot of time, thanks to the tools they had built – as we were able to support the same encoded format they used.

Hidden Partition

The hidden partition is a great patch, as there’s no way to tell that it’s there – everything works as expected, no reason to suspect that anything has been altered.

It divides the NAND space into two partitions, and the firmware lies about the size, to indicate that only half of the space is there. The “public” section is the first that’s mounted, and only a specific action will cause the second, hidden partition to become visible.

It’s a simple change, but it sends a clear message that there can be more than meets the eye with these devices. From a forensics perspective, the only way to ensure that what you are getting is accurate and complete, is to dump the NAND directly – without allowing the controller to access it.

Password Protection Bypass

This demo seemed to go wrong, but it actually performed perfectly – I was just in too much of a rush to think though what was happening, and why I didn’t see what I expected.

When I plugged the device in, I was expecting to see two drives from it – one “public”, the other unmounted. I only saw one. Two things went wrong here:

  • “Show Empty Drives In Explorer” – By default Windows doesn’t show unmounted removable drives in “My Computer”; this is a setting I always change, and expected to see the unmounted drive. As this was a fresh install, the default setting was still set – the drive was there, I just couldn’t see it. This threw me off.
  • Wrong Password – During the demo I typed in some random junk to the password field of the “Lock” tool, and instead of it unlocking the drive as expected, it gave me the wrong password dialog. The issue here is a bug in the Phison code, when supplying a password more than 16 characters long it treats it as a bad password. So it was working, but the password I supplied was too long, triggering that bug.

We later tested that drive again, and sure enough – it worked flawlessly, as long as the random password wasn’t longer than 16 characters.

The patch works by altering the buffer that stores the data once received over USB; it forces it to 16 “A”s, so that any password will work. Because of how it works, the patch must be applied before the user sets their password – otherwise it’ll just make the data inaccessible.

That was painful.

The (maybe) error…

During the talk I referred to modes 7 and 8 as being encrypted – this is probably wrong, at least on the devices we demoed. The two modes are password protected, and according to some documentation are encrypted, and according to other documentation they aren’t.

The question came up in a conversation after the talk – we’ve not had the time to dig into this feature more since then, but it’s looking like it’s just a password check with no encryption.

The password changing patch was added at the last minute, to replace another demo that we didn’t like – we identified the USB command being sent, and patched it. Due to time constraints we didn’t dig into the feature to verify the document (from a device manufacturer) was correct; after the question was raised we dug into a little more and looked for other documentation and code to support the claim – it looks like the document we were referencing was incorrect.

So, it looks like I misspoke – the patch still works as expected, though the feature itself seems to provide less protection than we initially thought. Sorry!

The Code & Docs

We have everything on the repo now, and we’ve added some additional documentation to the wiki.

This isn’t simple to do – the code is complicated to write, and the effort to use the patches and custom firmware is a bit more than I’d like. We’ve tried to document things as well as we can, hopefully it’s easy enough to understand.

Next Steps

We really hope that releasing this will push device manufactures to insist on signed firmware updates, and that Phison will add support for signed updates to all of the controllers it sells.

Phison isn’t the only player here, though they are the most common – I’d love to see them take the lead in improving security for these devices. They have an opportunity to stand up and protect users – as the most common provider of these controllers, I’d truly love to see them take this as an opportunity to lead the industry.

What we’ve released just scratches the surface of what can be done here – until signed updates are enforced, there’s no telling what games these devices could be playing.

phpMyID: Fixing Abandoned OSS Software

phpMyID is a simple solution for those that want to run their own OpenID endpoint – the problem is that its author stopped maintaining the project in 2008. Despite this, there’s still quite a few people that use it, because it’s the easiest single-user OpenID option available.

Unfortunately, the author didn’t follow best practices when building the software, and as a result multiple security flaws were introduced. In 2008, a XSS was identified and never fixed (CVE-2008-4730), in the years since then it seems the software has been below the radar. While conducting a pentest I discovered a previously undocumented XSS (CVE-2014-2890) – which left me with a dilemma – what to do about it?

Looking at the code, I found a couple more potential XSS vulnerabilities – so the application clearly needed help, and if the author won’t do it, somebody should. Ethically, it seemed wrong to disclose the issue but leave users to fend for themselves; full disclosure is normally used to push a vendor into acting – but in this case it’s assured that there won’t be a vendor response.

Fixing The Code

One good thing is if a OSS project is abandoned, anyone can prepare patches to fix the issues. So, that’s what I did. I’ve committed fixes for both CVE-2008-4730 and CVE-2014-2890, as well as a couple potential issues. In both cases, the fix was easy:



I’ve only given the code a quick once-over, so there may be other issues – if I find time for a more thorough review I may commit additional fixes.

Status of phpMyID

I’m not taking over the maintenance of the project, I simply don’t have time to do the cleanup needed to bring it up to reasonable standards. I’d love to see somebody with a little time to invest cleanup the code and add more defensive measures. It needs some help, that’s clear.

One of the things I’d love to see fixed is the way the user’s password is stored – it’s currently stored in the MyID.config.php file as a MD5 hash – making brute-forcing entirely too easy. Hopefully this Internet Draft will be adopted soon, obsoleting RFC 2617, which will be an easy win to improve the security of the password when in transit. There are many places where the code can be improved by somebody with a little time.

If you are using phpMyID today, replace the MyID.php file with the one here (it also fixes compatibility with PHP 5.4).

Evernote for Windows, Arbitrary File Download via Update

Update: The Evernote security has reported that this issue is resolved.

Evernote for Windows downloads its update information via HTTP, making it subject to man-in-the-middle attacks – further, this allows an attacker to specify an arbitrary file for the updater to download. The good news is that Evernote will not execute the file thanks to signature validation – but the file isn’t removed, so it’s available for later use.

As the file isn’t executed, it isn’t a critical issue.

The update.xml (and the related release notes HTML file) is served over HTTP, not HTTPS; this allows an attacker to control the content of the file. This allows an attacker to indicate that there is an update, and provide a malicious file that the user will download; as the attacker can also control the release notes, the attacker can use that to encourage the user to upgrade (i.e. indicate that it’s a required update).

Evernote will download the file and save it to the C:\Users\<user>\AppData\Local\Evernote\Evernote\AutoUpdate directory, assuming that the malicious binary isn’t signed, the user will be alerted that Evernote was “Unable to download the update” – but the file is left in the above directory.


If combined with another issue, it may allow an attacker to gain additional access. This could also be used to plant a file on a victim’s machine (illegal content, false evidence, etc.).

VICIDIAL: Multiple Vulnerabilities

Update: The VICIDIAL team has publicly released a new version that, according to them, has corrected the issues I’ve pointed out here. Please make sure you are using the latest version available. If you aren’t sure if your instance is safe, contact your friendly local penetration tester to verify it’s secure as you expect it to be.

Update: The SQL Injection vulnerability has been assigned CVE-2013-4467, and Command Injection assigned CVE-2013-4468.


VICIDIAL (a.k.a. Asterisk GUI client) is an open-source dialer built on top of the Asterisk PBX. It’s written in PHP, and has a significant number of security issues.

In addition to the open-source project, the company behind VICIDIAL, The Vicidial Group, also offers VICIDIAL in a hosted environment.

At this time, the current release version is still vulnerable. Vendor reports hosted users are on a fixed version. Vendor proposed to release the OSS code in mid-July, as of October 23rd, no update or advisory has been released.

After discussions with other researchers, I have made the decision that after waiting more than 140 days for a release, patches, or an advisory warning users, that the next responsible step is to disclose the issue publicly.

This is not a decision I take lightly, but I believe at this point users of this application should understand the degree of risk involved, and have details so they can take action to minimize that risk.


Tested versions: 2.7RC1, 2.7, 2.8-403a; it is likely other versions are affected.

There are three vulnerabilities that I will discuss here:

  1. Pre-Auth SQL Injection in ./apc/SCRIPT_multirecording_AJAX.php
  2. Hard-Coded User Credentials
  3. Command Injection in ./agc/manager_send.php

There are pre and/or post authentication SQL injection flaws in nearly every file in the ./agc directory. The web portion is split between ./agc (which is the ‘agent’ interface) and ./vicidial (the administrative interface). My review did not include the ./vicidial directory, though a quick glance indicates that there are likely many issues there as well.

There are many other issues; from XSS to a possible DoS by allowing an attacker to write directly to a log file until the attacker has exhausted the free space on the server.

There’s also ./vicidial_mysql_errors.txt – it might be of interest as it contains query parameters.

I will not document all of the issues that I’ve found; partly because I don’t want to take the time, and also because I feel bad for the team at OSVDB – hundreds of entries for the same application wouldn’t be fun.

Pre-Auth SQL Injection

This is your typical, boring, SQL injection:

The $campaign variable is unsanitized and passed directly to the query. This isn’t the best SQL Injection ever, but it demonstrates the issue.

Hard-Coded User Credentials

There are two accounts that are created when you install VICIDIAL that have hard-coded passwords, that are used by the software. While these accounts have minimal permissions, they do allow an attacker to get to portions of the code not accessible without a valid user account.


  • VDAD
  • VDCL

Both accounts have the same password: donotedit.

Command Injection

In multiple locations, there are calls to passthru() that do not perform any filtering or sanitation on the input. In this case, we are looking at ./agc/manager_send.php line 429.

Here is the code in question:

To exploit this, the following values must be set:

  • enable_sipsak_messages=1
  • allow_sipsak_messages=1
  • protocol=sip
  • ACTION=OriginateVDRelogin
  • session_name=AAAAAAAAAAAA (or any other value at least 12 bytes long)
  • server_ip=' OR '1' = '1
  • user=VDCL
  • pass=donotedit

The payload is passed in the extension parameter, for my testing, I used the following:

extension=;id;uname -a;

As you’ve probably noticed, the value for server_ip isn’t just a dummy value, it’s taking advantage of a SQL Injection vulnerability on line 285:

This allows us to bypass the check for an active session, and we use the hard-coded credentials to get around the need for authentication.

When you execute this, it looks like this:

As you can see, when you run this, the returned text from the shell is included in the middle of the body in the server’s response.

Timeline & Vendor Response

The vendor quickly acknowledged the issues and promised quick fixes. As time has gone on, their hosted users received the security fixes, users of the open-source version remain unaware of the issue and unprotected.

  • 6/3/2013 – Vendor notified
  • 6/3/2013 – Vendor confirmed
  • 6/13/2013 – Vendor states first phase of changes complete; began rolling out fixes to hosted users.
  • 6/15/2013 – Requested release timeline.
  • 6/15/2013 – Vendor requests disclosure delay till mid-July 2013.
  • 7/3/2013 – Vendor advises second phase of changes complete and being pushed to hosted users.
  • 8/26/2013 – Requested status update.
  • 8/27/2013 – Vendor advises final phase of changes complete, hosted users update with all security changes. Expects to release OSS code in two weeks.
  • 9/20/2013 – Requested status update.
  • 9/25/2013 – Vendor advises of unrelated delay. Expected to complete work for next release by 9/30.
  • 10/23/2013 – Decision made that further delays not in the public interest.