LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityCyberoam deep packet inspection and certificatesThe Tor Project recently discovered a security flaw in a line of commercial deep packet inspection (DPI) products; a flaw which an attacker could use to intercept the SSL connections of third-party users. The manufacturer of the product quickly pushed out an update, but DPI products from other vendors may still be affected. Runa Sandvik wrote about the discovery on the Tor blog in a post dated July 3. According to that account, the discovery took place the week before, when a Tor user in Jordan contacted the project to report seeing a fake certificate for torproject.org, issued by Cyberoam. The project initially thought that a certificate authority (CA) might have been compromised (as in the DigiNotar incident in 2011), but upon investigation, that was not the case. Cyberoam is a network security vendor that sells DPI devices. The user in Jordan was not witnessing an attack, but rather the evidence that the SSL connection to Tor had been intercepted by a Cyberoam DPI device. It is not clear from Sandvik's post whether the user was behind a corporate Cyberoam barrier (in which case he or she may have explicitly or implicitly agreed to the DPI interception) or was being monitored unwillingly. Whatever the circumstances, though, it was not the DPI filtering that constituted the security vulnerability. CA certificate woes and default settingsCyberoam's devices monitor SSL connections without generating browser errors by having the user install a Cyberoam CA certificate into the browser's trusted certificate store. Subsequently, the device intercepts SSL connections, issuing generated certificates (signed by the now-trusted Cyberoam CA certificate) for the requested sites and establishing the server-side connection on the other side of the intercept. This had happened to the user in Jordan, which was why he or she saw a Cyberoam-issued certificate for the torproject.org domain. The problem is that all Cyberoam devices ship with identical CA certificates and identical private keys. Consequently, Sandvik wrote, anyone can use a Cyberoam device to intercept traffic on any other Cyberoam-filtered network, or even extract the key and install it on other devices and use those to intercept traffic. In either case, the users would not detect that their traffic was being monitored by someone other than the approved authority. Sandvik and Ben Laurie wrote a security advisory (CVE-2012-3372) about the issue and notified Cyberoam before publishing the blog post. Cyberoam wrote a post on its own blog detailing its response to the alert. According to Cyberoam's account, each affected device is capable of generating its own CA certificate, and the certificate shared by all devices was merely a "default." After Tor's alert, the company pushed out an update to all of its devices instructing administrators to generate a unique CA certificate, and it "forcefully generated unique keys for all the remaining appliances." The wording in that section is a bit ambiguous, but it appears that device administrators were encouraged to generate a new CA certificate locally, and those that did not do so quickly were updated to a unique certificate generated at Cyberoam, with further instructions on local key generation. Cyberoam (admirably) thanked Tor for the vulnerability report, and also said that the CA certificate update makes its DPI products significantly more secure than its competitors'. For the update to take effect, users on a Cyberoam-monitored network will need to import the newly-generated CA certificate into their browser's trusted certificate store. Whether they do so willingly depends on whether they have consented to be monitored by the device. For its part, Tor expresses little sympathy for organizations using DPI to intercept users' connections, repeatedly calling them "victims" in the security alert text, and adding the footnote: "In the corporate setting, willing victims are often known as 'employees'. Unwilling victims should not, of course, install the CA certificate, nor should they click through certificate warnings." On the other hand, the alert calls Cyberoam's approach "the only legitimate way to use these devices," in contrast with monitoring schemes that require persuading a CA to issue fake certificates. Security impactWithout knowing the details of the user who reported the issue initially, it is impossible to say whether or not Cyberoam devices are being used to monitor Internet users without their consent. There are legitimate uses for DPI, of course, such as protecting a corporate network. But the report hints at a different scenario, because the user reported that common web sites (such as Gmail and Twitter) showed the correct CA certificates — suggesting that torproject.org was being selectively targeted for interception. In comments on the Tor blog, some readers questioned whether the case was one of consenting monitoring done at an employer, or unwilling surveillance. One anonymous reader commented that the Cyberoam devices in question only intercept SSL connections to check for malware, and that Tor had "raised a non-existing vulnerability." Sandvik replied that there were two separate issues at play: the use of the device to intercept torproject.org traffic , and the fact that all Cyberoam devices shipped with the same CA certificate. Cyberoam's response should seal the second issue, assuming that future devices ship only with unique keys. A master CA certificate controlled by Cyberoam could still be used to sign the individual device keys. In that case, Cyberoam might sign a separate "intermediate" CA certificate for each individual device. Thus the users only need to install the original Cyberoam certificate in the browser's trust store, and the certificate trust chain still validates. If device administrators have to re-generate a new CA certificate for the device, they must have Cyberoam sign it, but they do not have to have every user install something new. But as Sandvik asked in the comment thread, "How can you be sure that the device being used in this case is not doing DPI, but 'just' HTTPS scanning for antivirus?" Implicitly, the answer is "you can't," which is one of the fundamental justifications for Tor and similar privacy-protecting projects. How the user in Jordan came to be behind a Cyberoam scanning device is unknown, but if he or she agreed to have web traffic monitored, particularly to the point of manually installing a CA certificate in the browser, then there is little or nothing to prevent the monitoring party from engaging in all sorts of mischief. Although, in an interesting side note, several anonymous commenters on the Tor blog posted what they claim to be the Cyberoam devices' default private key. So even if few people learn a lesson about the dangers of consenting to traffic monitoring, perhaps a few others will learn a lesson about leaving the default security settings in place.
Brief items Security quotes of the week
Popular pet names Rover, Cheryl and Kate could be a thing of the
past. Banks are now advising parents to think carefully before naming their
child’s first pet. For security reasons, the chosen name should have at
least eight characters, a capital letter and a digit. It should not be the
same as the name of any previous pet, and must never be written down,
especially on a collar as that is the first place anyone would
look. Ideally, children should consider changing the name of their pet
every 12 weeks.
-- NewsBiscuit
[...] We tried to call Barclays’ security expert R0b Ste!nway for a comment, but he was not available for 24 hours, having answered his phone incorrectly three times in succession.
A group of researchers led by Professor Todd Humphreys from the University of Texas at Austin Radionavigation Laboratory recently succeeded in raising the eyebrows of the US government. With just around $1,000 in parts, Humphreys’ team took control of an unmanned aerial vehicle owned by the college, all in front of the US Department of Homeland Security.
-- RT
After being challenged by his lab, the DHS dared Humphreys’ crew to hack into a drone and take command. Much to their chagrin, they did exactly that.
Just like the huge black eye that _every major US telecom company_ got
when they got caught colluding with the NSA to spy on Americans in
obvious violation of US law? You'll recall that it was such a *huge* PR
disaster... that they're all still doing it today(!), that Congress
retroactively changed the law(!), and that the whistleblower was
indicted for espionage(!).
-- Matt Mackall
I agree that Intel's hardware is very probably not backdoored, but that's simply not a standard by which threats should be measured in this field. Treating a backdoor scenario as outside the realm of possibility based on appeals to reputation given such obvious, massive, and recent precedent to the contrary is... not a typical security mindset, to put it mildly.
New vulnerabilities backuppc: cross-site scripting
ffmpeg: insecure frame threads
jruby: denial of service
keepalived: denial of service
kernel: denial of service
kernel: denial of service
libgdata: insufficient certificate verification
mod_security: modsecurity multipart bypasses
mod_security_crs: modsecurity core rule set multipart bypasses
openjpeg: code execution
pidgin: remote code execution
pidgin: information disclosure
python3: data leaks, memory damage, and crash
wireshark: denial of service
xorg-server: code execution
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||