MBTA Shows MIT How Security Disclosure Really Works

The Massachusetts Bay Transit Authority (MBTA) had a problem last week – a group of students were prepared to deliver a presentation at Defcon, a high-profile security conference, on vulnerabilities they had identified in the transit card system employed by the MBTA. In a vain attempt to suppress this information, the MBTA filed anĀ injunction filed to stop the presentation. In doing so, the MBTA filed this document in their court documents, and provided far better disclosure of the vulnerabilities (see Exhibit 1) than would have been provided by any such presentation.

While I disagree with the actions of the MBTA, if they really wanted to quash the disclosure they could have at least tried to do it right. There can only be one of two possible conclusions: they didn’t really want to quash the disclosure but had to appear to do so for political reasons, or they’re incompetent. Does no one on the MBTA legal team realize that filed court documents are public records? And readily available on the Internet? No? OK then, you’re fired.

On a related note, I learned a new term: the Streisand Effect.

(Incidentally, I don’t see what the big deal is about this vulnerability. When I was in university, we were cloning our university the pre-paid printer stored value cards using only blank audio tape and a piece of Scotch tape. It’s not rocket science.)

“Security error accessing url” in Flash 9,0,124,0

Adobe FlashIt appears the April update of Flash Player’s security policies have some implications for Amazon’s web services. Per the release information, it appears that is is no longer sufficient to have a crossdomain.xml file that contains <allow-access-from domain="*"/>:

In order for a SWF to send a header anywhere other than its own host, the origin domain of the SWF must have explicit permission from the host to which the header is being sent, in the form of a policy file. The existing policy file model will apply, with the same file locations and ActionScript APIs, but a new syntax will be required. To specify header-sending rights, use this new tag: <allow-http-request-headers-from>.

Without such an entry, whenever you use the WebService tag in MXML to access an Amazon web service, you’ll get the “security error accessing url” message. I currently have this problem with the following use of WebService tag:



...

This code functioned without issue until I updated to Flash Player 9,0,124,0. I’ve started a thread on the Amazon Web Services Developer Connection, so hopefully someone at Amazon add the appropriate <allow-http-request-headers-from domain="*"/> entry into the crossdomain.xml file at webservices.amazon.com to address this problem.

Hopefully this post saves some people a few hours of beating their heads against a wall. Unless I’m totally mistaken, and there’s a workaround that doesn’t involve using a proxy?