Sci-fi movies seem to always have handheld scanners of one kind or another that tell future doctors everything they need to know about injuries. What better way to solve a health problem than to run a quick scan and look at a detailed color picture of someone’s insides? Spaceships send teams to remote and uncharted locations where medical resources are scarce (no cocoons or caskets that can repair or even completely rebuild a human), so portability is key.

Well, fiction is coming closer to reality again as a USB ultrasound device is waiting for FDA approval. Medical Technology Business Europe has reported the announcement by Direct Medical Systems:

Ppups is a complete ultrasound imaging system built into a small USB-compatible probe for B-mode imaging. The cost of the probe is under $3,700 and it weighs 7.5 ounces. The probe is operational by loading the software and plugging the USB cable into the USB (2.0) port.

I have to say, from my own experience building an Ultrasound network, that this seemed like the most likely medical technology to go portable since most of it already was fairly mobile. Now if they could just get that hand-held MR (or at least home-based) program off the ground, we could all rest a little bit better at night; especially those of us in remote and uncharted territory.

The news last week was that the Payment Card Industry Data Security Standard (PCI DSS) will be changing soon. In particular, a director from MasterCard was quoted at a conference:

this encryption requirement is causing so much trouble for merchants that credit card companies are having trouble dealing with requests for alternative measures, he said. In response, changes to PCI will let companies replace encryption with other types of security technology, such as additional firewalls and access controls, Maxwell said. ‘There will be more-acceptable compensating and mitigating controls,’ he said.

This quote appears to suggest that there will be a significant alteration of the encryption requirement, section 3.4, which today reads:

Render sensitive cardholder data unreadable anywhere it is stored, (including data on portable media, in logs, and data received from or stored by wireless networks) by using any of the following approaches:
– One-way hashes (hashed indexes) such as SHA-1
– Truncation
– Index tokens and PADs, with the PADs being securely stored
– Strong cryptography, such as Triple-DES 128-bit or AES 256-bit with associated key management processes and procedures. The MINIMUM account information that needs to be rendered unreadable is the payment card account number.

However, Visa has communicated that they did not agree to change this requirement and has reiterated that there are already multiple ways that are acceptable to render cardholder data unreadable. Compensating controls for encryption of stored data will be included in an appendix in the next version of the PCI DSS, but it is important to note that compensating controls are only allowed for short-term and they must still sufficiently mitigate the risk associated with the PCI requirement with the same/better preventive force as the original requirement.

The planned changes to the PCI DSS are actually fairly minor, intended to clarify the existing requirements, and not less stringent.

So, you have a computer on the network and you want virtual terminal access. You install RealVNC and, blammo! Compromised by a bot trolling the net.

No, I’m not kidding. Bascially the RealVNC 4.1.1 server responds to a request for access without verifying valid options. In other words, if you send it a “let me in without a password” even if it never suggested that was available to you, it still lets you in without a password.

This is like a hotel clerk saying “Welcome to Chez VNC, we have a room for you on the 1st floor with a view of the parking lot” and you say “Thanks, I’d be happy to take that penthouse on floor 29 with a view of the bay” and that’s it, you’re in the penthouse without needing to know the manager or having some other special credentials.

Evil exploit bots love this sort of thing, for obvious reasons; they can just scan blocks of IPs and then take over any vulnerable service they find. The bottom line is you really should not run virtual terminal connections without using some other authentication system (beyond the password) and/or a secure tunnel/wrapper like SSH. This has always been a best practice, but now you have a critical vulnerability to add some spice.

And that’s not even the end of the story. James Evans wrote a rather blunt explanation of a related issue on the full-disclosure list:

RealVNC is distributed under the GNU General Public License. As such, the complete source code of RealVNC *must* be freely distributed. When RealVNC (the company) received notice of this flaw in their software, they were quite prompt in patching it. Such action is normally worthy of praise. Yet, in this case, RealVNC immediately took down the source code to their software. While this was probably done out of fear rather than malice, I believe it violates both the spirit and law of the GNU GPL. As we can see from the above, it is also not beneficial to security. I was able to rediscover this flaw using only binaries, and a little thought. Allowing for the benefit of doubt, I posted to the RealVNC mailing list, congratulating them on patching the bug so quickly and asking when the source code would be released. I received one reply from another user, agreeing that he would like to see the source, as it is under GPL. Upon returning the next day to check if there were any more replies, I was surprised to see the entire mailing list was deleted along with its archives. This is unfortunate, and it clearly neither prevents discussion nor promotes security.

Ouch. The source reportedly was back online by the next day…