Why The NSA's Vulnerability Equities Process Is A Joke (And Why It's Unlikely To Ever Get Better)

from the 'national'-security-still-the-best-kind-of-security,-apparently dept

Two contributors to Lawfare -- offensive security expert Dave Aitel and former GCHQ information security expert Matt Tait -- take on the government's Vulnerability Equities Process (VEP), which is back in the news thanks to a group of hackers absconding with some NSA zero-days.

The question is whether or not the VEP is being used properly. If the NSA discovered its exploits had been accessed by someone other than its own TAO (Tailored Access Operations) team, why did it choose to keep its exploits secret, rather than inform the developers affected? The vulnerabilities exposed so far seem to date as far back as 2013, but only now, after details have been exposed by the Shadow Brokers are companies like Cisco actually aware of these issues.

According to Lawfare's contributors, there are several reasons why the NSA would have kept quiet, even when confronted with evidence that these tools might be in the hands of criminals or antagonistic foreign powers. They claim the entire process -- which is supposed to push the NSA, FBI, et al towards disclosure -- is broken. But not for the reasons you might think.

The Office of the Director of National Intelligence claimed last year that the NSA divulges 90% of the exploits it discovers. Nowhere in this statement were any details as to what the NSA considered to be an acceptable timeframe for disclosure. It's always been assumed the NSA turns these exploits over to developers after they're no longer useful. The Obama administration may have reiterated the presumption of openness when reacting to yet another Snowden leak, but also made it clear that national security concerns will always trump personal security concerns -- even if the latter has the potential to affect more people.

The main thrust of the Lawfare article is that the "broken" part of the equities process is that there should be a presumption of disclosure at all. The authors point out that it might take years to discover or develop a useful exploit and -- given the nature of the NSA's business -- it should be under no pressure to make timely disclosures to developers whose software/hardware the agency is exploiting.

[F]rom an operational standpoint, it takes about two years to fully utilize and integrate a discovered vulnerability. For the intelligence officer charged with managing the offensive security process, the VEP injects uncertainty by requiring inexpert intergovernmental oversight of the actions of your offensive teams, effectively subjects certain classes of bugs to time limits and eventual public exposure—all without any strategic or tactical thought governing the overall process.

[...]

Individual exploitable software vulnerabilities are difficult to find in the first place. But to engineer the discovered vulnerability into an operationally deployable exploit that can bypass modern anti-exploit defenses is far harder. It is a challenge to get policymakers to appreciate how rare the skills are for building operationally reliable exploits. The skillset exists almost exclusively within the IC and in a small set of commercial vendors (many of whom were originally trained in intelligence). This is not an area where capacity can be easily increased by throwing money at it—meaningful development here requires monumental investment of time and resources in training and cultivating a workforce, as well as crafting mechanisms to identify traits of innate talent.

The authors do point out that disclosure can also be useful to intelligence services. If these disclosures result in safer computing for everyone else, then that's apparently an acceptable side effect.

[T]here are three major, non-technical reasons for vulnerability disclosure.

First, disclosure can provide cover in the event that an OPSEC failure leads you to believe a zero-day has been compromised—if there is a heightened risk of malicious use, it allows the vendor time to patch. Second, disclosing to vendors allows the government to out an enemy’s zero-day vulnerability without disclosing how it was found. And third, government disclosure can form the basis of building a better relationship with Silicon Valley.

Saddling intelligence agencies with a presumption of disclosure is possibly a dangerous idea. Less-than-useful exploits that could be divulged to developers might be tied to other exploits still being deployed by intelligence services. Any suggested timeframe for mandatory disclosure would likely cause further harm by forcing the NSA, FBI, etc. to turn over exploits just as they're generating optimal results. On top of that, the authors point out that a push towards disclosure hamstrings US intelligence services as agencies in unfriendly nations will never be constrained by requirements to put the public ahead of their own interests.

But the process is definitely broken, no matter whose side of the argument you take. The NSA says it discloses 90% of the vulnerabilities it discovers, but former personnel involved in these operations note they've never seen a vulnerability disclosed during their years in the agency.

It's unlikely that the process will ever be fixed to everyone's satisfaction. The most likely scenario is that the VEP will continue to trundle along doing absolutely nothing while being ineffectually attacked by those opposing intelligence community secrecy. As it stands now, the presumption of disclosure is completely subject to any national security concerns raised by intelligence and law enforcement agencies. Occasional political climate shifts may provoke transparency pledges from various administrations, but those should be viewed as sympathetic noises -- presidential pats on the head meant to fend off troubling questions and legislative pushes to put weight behind the administration's words.

Filed Under: 0days, exploits, nsa, sharing, surveillance, vep, vulnerabilities, vulnerabilities equities process, zero days

Emails Show Hillary Clinton's Email Server Was A Massive Security Headache, Set Up To Route Around FOIA Requests

from the breaking-badly dept

More bad news for Hillary Clinton and her ill-advised personal email server. Another set of emails released by the State Department shows the government agency had to disable several security processes just to get its server to accept email from Clinton's private email address.

The emails, reviewed by The Associated Press, show that State Department technical staff disabled software on their systems intended to block phishing emails that could deliver dangerous viruses. They were trying urgently to resolve delivery problems with emails sent from Clinton's private server.

"This should trump all other activities," a senior technical official, Ken LaVolpe, told IT employees in a Dec. 17, 2010, email. Another senior State Department official, Thomas W. Lawrence, wrote days later in an email that deputy chief of staff Huma Abedin personally was asking for an update about the repairs. Abedin and Clinton, who both used Clinton's private server, had complained that emails each sent to State Department employees were not being reliably received.

After technical staffers turned off some security features, Lawrence cautioned in an email, "We view this as a Band-Aid and fear it's not 100 percent fully effective."

While trial-and-error is generally useful when solving connection problems, the implication is undeniable: to make Clinton's private, insecure email server connect with the State Department's, it had to -- at least temporarily -- lower itself to Clinton's security level. The other workaround -- USE A DAMN STATE DEPARTMENT EMAIL ADDRESS -- was seriously discussed.

This latest stack of emails also exposed other interesting things... like the fact that Clinton's private email server was attacked multiple times in one day, resulting in staffers taking it offline in an attempt to prevent a breach. (h/t Pwn All The Things)

In addition to the security issues, there's also some discussion about why Clinton was choosing to use her own server.

In one email, the State Department's IT person explains the agency already has an email address set up for Clinton, but offers to delete anything contained in it -- and points out that using the State Dept. address would make future emails subject to FOIA requests.

[W]e actually have an account previously set up: SSHRC@state.gov. There are some old emails but none since Jan '11 -- we could get rid of them.

You should be aware that any email would go through the Department's infrastructure and subject to FOIA searches.

So, there's one reason Clinton would have opted to use a personal email address and server. More confirmation of the rationale behind this decision appears in an earlier email (2010) from Clinton to her aide, Huma Abedin.

Abedin: We should talk about putting you on state email or releasing your email to the department so you are not going to spam.

Clinton: Let's get separate address or device but I don't want any risk of the personal being accessible.

There appears to be some intent to dodge FOIA requests -- either by ensuring "no documents found" when Clinton's State Department email address was searched, or by being able to control any release by being the chokepoint for responsive documents.

To accomplish this, Clinton's team set up a private email server that was insecure and did not follow State Department guidelines. In fact, her team brushed off the agency more than once before finally informing it that they simply would not comply with State Department regulations.

In a blistering audit released last month, the State Department's inspector general concluded that Clinton and her team ignored clear internal guidance that her email setup broke federal standards and could leave sensitive material vulnerable to hackers. Her aides twice brushed aside concerns, in one case telling technical staff "the matter was not to be discussed further," the report said.

The FBI investigation that Clinton refuses to call an investigation continues. There may be no criminal charges forthcoming, but there's already plenty of evidence that Clinton's use of a private email server was not only dangerously insecure, but put into place in hopes of limiting her accountability.

Filed Under: email, foia, hillary clinton, security, state department, vulnerabilities

FBI Spent $1.3 Million To Not Even Learn The Details Of The iPhone Hack... So Now It Says It Can't Tell Apple

from the wtf dept

Once the DOJ told the court in San Bernardino that it had succeeded in hacking into the iPhone of Syed Farook, the big question people asked is whether or not the FBI would then tell Apple about the vulnerability. After all, the administration set up the so-called "Vulnerabilities Equities Policy" (VEP) with the idea of sharing most vulnerabilities it discovers with companies. The White House directly stated:

One thing is clear: This administration takes seriously its commitment to an open and interoperable, secure and reliable Internet, and in the majority of cases, responsibly disclosing a newly discovered vulnerability is clearly in the national interest. This has been and continues to be the case.

This spring, we re-invigorated our efforts to implement existing policy with respect to disclosing vulnerabilities – so that everyone can have confidence in the integrity of the process we use to make these decisions. We rely on the Internet and connected systems for much of our daily lives. Our economy would not function without them. Our ability to project power abroad would be crippled if we could not depend on them. For these reasons, disclosing vulnerabilities usually makes sense. We need these systems to be secure as much as, if not more so, than everyone else.

Of course, there's a big "but" there -- and it's that there's an "exception" for law enforcement. Last fall, after (yet another) big legal fight, the good folks over at the EFF finally got access to the VEP details and you can now read a (heavily redacted) version.

Still, one could make a strong case that this vulnerability should be disclosed... even if almost no one expected it to be. Amusingly, just a few days ago, Apple revealed that the FBI used the VEP to disclose a vulnerability for the very first time, on April 14th, just as everyone was arguing about this. Of course, the flaw it revealed was not about hacking into the iPhone, and was actually about a flaw that Apple had discovered and fixed... nine months ago. But, again, if this is the very first time the FBI has disclosed something to Apple, it certainly suggests that the VEP process generally means nothing gets disclosed. In fact, the timing of this really suggests that someone in the DOJ recently flipped out and realized that there's now going to be scrutiny on the VEP, so they might as well disclose something. Thus, they found an old bug that had already been patched and "revealed" it.

Either way, things got stranger a couple of days later, when the FBI -- which had already admitted to paying over $1 million to access Farook's iPhone, said that, for all that money, the people it hired never explained the vulnerability. They just opened the phone. Really.

“The F.B.I. purchased the method from an outside party so that we could unlock the San Bernardino device,” Amy S. Hess, executive assistant director for science and technology, said in a statement.

“We did not, however, purchase the rights to technical details about how the method functions, or the nature and extent of any vulnerability upon which the method may rely in order to operate. As a result, currently we do not have enough technical information about any vulnerability that would permit any meaningful review” by the White House examiners, she said.

Now, some are arguing that this suggests absolutely terrible bargaining on the side of the DOJ/FBI. But, another interpretation is that it's how the DOJ knew that it wouldn't have to reveal the flaw to Apple. Of course, this might also explain why the DOJ at one point appeared to claim that the hack in question only worked for Farook's phone. They later claimed that was a misstatement, and it really meant that it only applied to that iPhone configuration. But, if the FBI never actually got the details, then in some sense they'd be right that for the FBI the crack only worked for that one phone. And if they wanted to do it on another phone, they'd have to shell out another ~$1 million or so...

Filed Under: doj, encryption, fbi, going dark, vep, vulnerabilities, vulnerabilities equity policy
Companies: apple

Report Exposes Flaws In Link Shorteners That Reveal Sensitive Info About Users And Track Their Offline Movements

from the sna.fu dept

URL shorteners: not just for malware/spam delivery anymore!

TL;DR: short URLs produced by bit.ly, goo.gl, and similar services are so short that they can be scanned by brute force. Our scan discovered a large number of Microsoft OneDrive accounts with private documents. Many of these accounts are unlocked and allow anyone to inject malware that will be automatically downloaded to users’ devices. We also discovered many driving directions that reveal sensitive information for identifiable individuals, including their visits to specialized medical facilities, prisons, and adult establishments.

The Freedom to Tinker Foundation has just released a study it compiled over the last 18 months -- one in which it scanned thousands of shortened URLs and discovered what they unintentionally revealed. Microsoft's OneDrive -- which uses link-shortening -- could be made to reveal documents uploaders never intended to share with the public. Worse, Freedom to Tinker discovered a small percentage of brute-forced URLs linked to documents with "write" privileges enabled.

Around 7% of the OneDrive folders discovered in this fashion allow writing. This means that anyone who randomly scans bit.ly URLs will find thousands of unlocked OneDrive folders and can modify existing files in them or upload arbitrary content, potentially including malware.

And, because Microsoft's automatic virus/malware scanning for OneDrive contents is less than robust, it wouldn't take much for any random person to wreak havoc on any number of devices with access to those contents.

OneDrive “synchronizes” account contents across the user’s OneDrive clients. Therefore, the injected malware will be automatically downloaded to all of the user’s machines and devices running OneDrive.

Fortunately for OneDrive users, the scanning method deployed by FTTF no longer works as of March 2016. But this doesn't necessarily mean the accounts are completely secure -- just that one avenue for attack/access has been closed.

Just as disturbing -- but for different reasons -- is the automatic link shortening tied to Google Maps. The links could be manipulated to discover all sorts of inferential information about people's private activities… or at least the activities they never thought they were sharing with the world. The directions and searches uncovered by FTTF's scanning activity potentially reveal plenty of sensitive information about Google Maps users.

Our sample random scan of these URLs yielded 23,965,718 live links, of which 10% were for maps with driving directions. These include directions to and from many sensitive locations: clinics for specific diseases (including cancer and mental diseases), addiction treatment centers, abortion providers, correctional and juvenile detention facilities, payday and car-title lenders, gentlemen’s clubs, etc. The endpoints of driving directions often contain enough information (e.g., addresses of single-family residences) to uniquely identify the individuals who requested the directions. For instance, when analyzing one such endpoint, we uncovered the address, full name, and age of a young woman who shared directions to a planned parenthood facility.

The same privacy concerns associated with the indiscriminate use of automatic license plate readers by law enforcement and warrantless access to cell site location info are present here: the reconstruction of people's lives via the "tracking" of their movements. In this case, however, the information generated is more "voluntary" than either of the other listed collections, which are far more passive than searching for directions using a web service provided by a company with an unquenchable thirst for data.

The good news is that the method deployed for the report no longer works for Google Maps-shortened links. But, once again, that does not mean the problems with link shorteners have been eliminated. FTTF points out that the March 2016 change by Microsoft (which claims it had nothing to do with FTTF reporting the vulnerability to it) only affects links generated after that date. Any previous short URLs are still vulnerable to traversal scans.

Google, however, did make a more of a serious attempt to prevent abuse of its shortened links.

All newly generated goo.gl/maps URLs have 11- or 12-character tokens, and Google deployed defenses to limit the scanning of the existing URLs.

While this news should be of concern to users of these services, it definitely has to be great news for law enforcement and intelligence agencies. So much for "going dark." Vulnerabilities in web services apparently provide access to otherwise "locked" cloud storage contents and Google Maps -- at least until it was fixed -- generating tons of location data for the taking.

It's also worth pointing out that the method used by Freedom to Tinker to complile this report is basically the same method used by Andrew "Weev" Auernheimer to expose AT&T users' email addresses: altering URLs to uncover data presumed to be hidden. Of course, AT&T's vindictiveness resulted in a 3.5 year prison sentence for Auernheimer. No legal threats have been made towards FTTF, but the sad thing is that security research is inherently risky, as you can never tell whether the entity affected will respond with a bug fix or a police report -- not until after they've been informed.

Filed Under: link shorteners, onedrive, privacy, vulnerabilities
Companies: google, microsoft

John Oliver Explains Why You Should Side With Apple Over The FBI Better Than Most Journalists

from the and-better-than-apple dept

You had to know this was coming eventually, but the latest John Oliver main story was his take on the Apple v. FBI encryption fight. If you haven't seen it yet, here it is: Not surprisingly, Oliver's take is much clearer and much more accurate than many mainstream press reports on the issues in the case, appropriately mocking the many law enforcement officials who seem to think that, just because Apple employs smart engineers, they can somehow do the impossible and "safely" create a backdoor into an encrypted iPhone that won't have dangerous consequences. He even spends a bit of time reviewing the original Crypto Wars over the Clipper Chip and highlights cryptographer Matt Blaze's contribution in ending those wars by showing that the Clipper Chip could be hacked.

But the biggest contribution to the debate -- which I hope that people pay most attention to -- is the point that Oliver made in the end with his faux Apple commercial. Earlier in the piece, Oliver noted that this belief among law enforcement that Apple engineers can somehow magically do what they want is at least partially Apple's own fault, with its somewhat overstated marketing. So, Oliver's team made a "more realistic" Apple commercial which noted that Apple is constantly fighting security cracks and vulnerabilities and is consistently just half a step ahead of hackers with malicious intent (and, in many cases, half a step behind them).

This is the key point: Building secure products is very, very difficult and even the most secure products have security vulnerabilities in them that need to be constantly watched and patched. And what the government is doing here is not only asking Apple to not patch a security vulnerability that it has found, but actively forcing Apple to make a new vulnerability and then effectively forcing Apple to keep it open. For all the talk of how Apple can just create the backdoor just this once and throw it away, this more like asking Apple to set off a bomb that blows the back off all houses in a city, and then saying, "okay, just throw away the bomb after you set it off."

Hopefully, as in cases like net neutrality, Oliver's piece does it's job in informing the public what's really going on.

Filed Under: doj, encryption, fbi, going dark, iphone, john oliver, matt blaze, security, vulnerabilities
Companies: apple

NSA Pats Self On Back For Disclosing Vulnerabilities '90% Of The Time,' Doesn't Specify How Long It Uses Them Before Doing So

from the honest.-you'll-be-the-first-to-know-when-we're-finished-with-them. dept

The NSA likes its software vulnerabilities. There are those it discovers on its own and others it purchases from "weaponized software" dealers. There are also certain tech companies that hand over exploits to the NSA first before working on a patch for the rest of us.

Up until now, the NSA really hasn't discussed its policies regarding software vulnerabilities and exploits. A few months after the Snowden leaks began, the White House told the NSA to start informing software companies of any exploits/vulnerabilities it had discovered. The quasi-directive set no time limit for doing so and allowed the agency to withhold discovered exploits if there was a "clear national security or law enforcement" reason to do so.

While other parties have discussed the NSA's hoarding of software exploits, the agency itself hasn't. All information gathered to date has come from outside sources. Snowden provided some of the documents. The EFF knocked a couple more loose with an FOIA lawsuit against James Clapper's office.

The NSA has finally chosen to speak for itself. Its reassurances are far from reassuring.

The U.S. National Security Agency, seeking to rebut accusations that it hoards information about vulnerabilities in computer software, thereby leaving U.S. companies open to cyber attacks, said last week that it tells U.S. technology firms about the most serious flaws it finds more than 90 percent of the time.

Disclosing nine out of ten exploits sounds good, but these disclosures are likely only occurring after the vulnerability or exploit is no longer useful.

The re-assurances may be misleading, because the NSA often uses the vulnerabilities to make its own cyber-attacks first, according to current and former U.S. government officials. Only then does NSA disclose them to technology vendors so that they can fix the problems and ship updated programs to customers, the officials said.

Status remains quo. National security interests still override the security interest of millions of affected users. The NSA can't keep criminals from using the same security holes it's discovered. The only way to prevent a vulnerability from being exploited by malicious parties or unfriendly state actors is to disclose it. Eventual disclosure is better than no disclosure, but it's not nearly as altruistic as the NSA's 90% disclosure rate would make it appear.

Filed Under: attacks, cybersecurity, delay, disclosure, nsa, vulnerabilities

Given Spy Agencies' Love For Exploits And Malware, It's Never Been More Dangerous To Be A Security Researcher

from the only-acceptable-form-of-security-is-'national,'-apparently dept

There's probably never been a great time to be a security researcher, what with the attacks they suffer in response to their work, not to mention far too many corporations greeting the discovery of vulnerabilities with legal threats and criminal charges.

The worldwide adoption of the Wassenaar Arrangement threatens to treat the products of security research like weapons-grade plutonium, making every outbound flight with a laptop or USB drive akin to smuggling weapons out of the country.

But that's not the end of it. Security researchers work in the same shadowy areas as national security agencies, as well as other government entities focused on espionage. These agencies not only create their own malware and exploits, but also purchase them from companies in the vulnerabilities business.

Security researchers generally want to expose holes and dangerous software. Almost every other entity involved would prefer to keep these hidden. Any malicious software exposed and patched into irrelevance could carry national security implications. This puts researchers in the crosshairs of both governments and their exploit suppliers. And the system -- as it is -- has very little in the way of built-in protections for legitimate security research.

A paper published by Juan Andrés Guerrero-Saade of Kaspersky Lab points out the inherent dangers of security research in an age when one form of security (national) routinely takes precedent over another form (general computing). [h/t Slashdot]

Though private research teams and intelligence agencies will follow similar intelligence production cycles , we must not conflate their attributes.

(1) Intelligence agencies benefit from cover for action, meaning that other governmental institutions do not fi nd the agencies’ intelligence production activities suspect.
(2) Agency employees enjoy legal protections, even those involved in network exploitation activities. And finally,
(3) their work is shielded from political blowback or geopolitical incongruousness.

Each point is inversely applicable to security researchers and thus sets the tone for the power asymmetry:

1. Security researchers enjoy no cover for action for their production of intelligence reports into what may or may not constitute legitimate intelligence operations…
2. Security researchers are afforded no explicit legal protections for the grey areas regularly visited throughout the course of an investigation…
3. The companies too lack a cover for action and are in no way insulated from the political blowback that arises from the public disclosure of sensitive operations. They suffer from a further dimension of ‘guilt by association’ as research into sensitive operations and subsequent reporting is misconstrued as an act of geopolitical aggression when the victim and perpetrator are involved in any form of international tension...

On top of that, the "work cycles" are also inverted. Security researchers may not know they're treading on the cyber-toes of state operatives until long after the research has begun. Contrast that to the operations of intelligence agencies/exploit marketers, who are only seeking holes rather than fixes and know with certainty what they're deploying or who they're targeting. When security researchers stumble across vulnerabilities, they're not always aware of their origin and may find themselves facing prosecution or, at the very least, government interference and/or additional surveillance.

But those outcomes are the least worrying of the possibilities. Security researchers may find themselves involved with governments willing to deploy far more severe tactics.

The researcher as a private individual faces unique challenges when in the cross-hairs of a nation-state actor determined to enact some form of retribution. The operator of an espionage campaign is not a common criminal nor a simple citizen and his resources are truly manifold. As a special class of government insider responsible for a sensitive operation, the attacker can go so far as to legitimize special recourse in order to neutralize the threat posed by the meddling security researcher. The options available slide relative to the nature of the attacker, ranging from civilized to unscrupulous, and include: subtle pressure, patriotic enlistment, bribery, compromise and blackmail, legal repercussions, threat to livelihood, threat to viability of life in the actor’s area of influence, threat of force, or elimination.

With no built-in protections for researchers, the potential negative outcomes of their work may outweigh the intangible rewards of the work itself -- more secure computing.

With this in mind, a rather interesting awarded contract was posted to the Federal Business Opportunities (FBO) website. Kudu Dynamics -- which has secured previous DARPA/Dept. of Defense contracts related to cybersecurity -- apparently landed a $500,000 contract for a project that appears to give the company permission to spy on security researchers.

ACLU technologist Chris Soghoian phrased it this way:

DARPA awards 500k grant to spy on security vuln researchers. Seriously. (h/t/ @evacide) https://t.co/51cQHtJ4hY pic.twitter.com/w0Z5pW3hwo

— Christopher Soghoian (@csoghoian) October 26, 2015

DARPA awards 500k grant to spy on security vuln researchers. Seriously.

Here's the synopsis of the project (emphasis added):

The goal of Kudu's proposed effort, named "Internet Cyber Early Warning of Adversary Research and Development (ICEWARD)", is to determine whether it is possible to gain actionable insight into the intent of a cyber­ adversary by observing specific behaviors. In particular, the proposers hypothesize that vulnerability researchers make use of public information and resources (such as search engines and websites) that are relevant to their missions, targets, and techniques in such a way that it is possible to glean part of their intent if only we could observe such use and differentiate it from noise (e.g., search engine crawlers). The basis for this hypothesis is both the proposers' own experience as vulnerability researchers and a little ­noticed incident in 2010-2011. The proposed approach will investigate the feasibility of creating highly tailored information resources whose access via the public network will be inherently highly correlated with vulnerability research. A second aspect of the proposed work entails the creation of an evaluation methodology for proving or disproving this hypothesis.

What it seems to suggest is that Kudu would be allowed to read over the shoulders of security researchers as they used public resources, separate that use from the "noise" of bot activity, and extrapolate the researchers' intended goals.

I'm not as convinced as Soghoian that this means Kudu will be allowed to spy on/tap into security researchers' web browsing. It could mean that Kudu plans to use its own experience in the security research field to help refine processes and programs put in place to counter malicious activity -- a lot of which can seem almost indistinguishable from legitimate security research. This determination of intent would allow government agencies to focus on actual threats, rather than wasting resources chasing down legitimate security research.

Then again, certain government agencies would greatly benefit from this advance knowledge. It would give them a heads-up if researchers were probing exploits, vulnerabilties or malware they'd rather keep under wraps and in working condition.

What makes this murkier than it perhaps should be is the fact that the FBO scrubbed the synopsis from the listing a few hours after people began talking about it. (The EFF preserved the original post as a PDF.) There may be any number of non-nefarious reasons for it doing so, but considering most of the discussion centered around the theory that a government contractor was getting paid to spy on security researchers, the sudden burial of this contract info seems slightly suspicious.

Filed Under: computer security, darpa, fbi, malware, nsa, security research, surveillance, vulnerabilities, zero days

It Only Took GM Five Years To Patch Dangerous Vulnerability Impacting Millions Of Automobiles

from the good-job dept

For all the hype surrounding the "Internet of Things" (IOT), it's becoming abundantly clear that the security actually governing the sector is little more than hot garbage. Whether it's televisions that bleed unencrypted, recorded living room conversations, or refrigerators that expose your Gmail credentials, IOT developers were so excited to cash in on the brave new world of connectivity, security was an absolute afterthought. Entertainingly, that has resulted in many "smart" technologies being little more than advertisements for the fact that sometimes, it's ok for your device to be as stupid as possible.

And while it's annoying for your IOT toaster to be leaking login credentials or your new IOT toilet to be broadcasting bathroom habits on the Internet, when it comes to automobiles -- human lives are at stake. And yet auto infotainment and network security is somehow the poster child for flimsy security practices. That was illustrated perfectly when hackers recently revealed that they were able to all-but take over some Chrysler cars from anywhere in the world provided they simply had the car's IP address -- allowing intruders to rewrite the firmware on the car's head unit.

In that instance, Chrysler released a patch for the vulnerability before the research was even publicized, and quickly implemented a 1.4 million vehicle recall. But historically automakers aren't that quick on their feet (nor are the vulnerabilities that publicized). Millions of GM vehicles, for example, suffered from a similar flaw that allowed hackers to effectively take over everything in the vehicle except for the steering. That particular problem, it was revealed this month, took GM the better part of five years to actually fix despite being a relatively low-tech hack:

"The intrusion technique began with a phone call to the Impala’s OnStar computer. Because Verizon’s voice network coverage was more reliable than its data network, the OnStar computers were programmed to establish a connection to any computer that played a certain series of audio tones, like an old-fashioned modem. UW’s Koscher reverse engineered that audio protocol and created an mp3 file that could trigger a vulnerability in the computer known as a “buffer overflow.”

Put simply, “you play this song to it, and the car’s taken over,” says UCSD’s Savage. From that initial audio attack, the attackers could pivot to take control of the OnStar computer’s higher-bandwidth data connection and finally penetrate the car’s CAN bus, the collection of networked computers inside a vehicle that control everything from its windshield wipers to its brakes and transmission. Put simply, “you play this song to it, and the car’s taken over,” says UCSD’s Savage."

And yes, while this vulnerability in question (which impacted the 2009 Chevy Impala) saw much less media coverage because the hackers didn't publicly name the vehicle, the vulnerability still existed for any hacker or intelligence agency operative to play with at their leisure for half a decade. And while the hackers obscured the vehicle name with masking tape when demonstrating it repeatedly to "a wide variety of government and even military agencies" and the media (like in this 60 Minutes episode earlier this year), it likely wasn't very hard to guess which car they were talking about. Meanwhile, what's the over-under for local law enforcement accurately pinning the source of potential accidents on a vehicle's compromised infotainment firmware?

The hackers are quick to downplay GM's negligence here, but note that the company's failures are a symptom of a much bigger disease:

"But the researchers argue that GM’s years-long failure to fully protect its vehicles from that attack doesn’t reflect on GM’s negligence, so much as a lack of security preparation in the entire industry of Internet-connected cars. Automakers five years ago simply weren’t equipped to fix hackable bugs in their vehicles’ software, the way that Microsoft and Google have long fixed bugs within weeks or even hours after they are disclosed to them. And many of those companies may not be much better prepared today.

"They just didn’t have the capabilities we take for granted in the desktop and server world,” says Stefan Savage, the UCSD professor who led one of the two university teams who worked together to hack the Impala. “It’s kind of sad that the whole industry was not in a place to deal with this at the time, and that today, five years later, there still isn’t a universal incident response and update system that exists."

GM says that since this flaw was exposed, they've at least developed the ability to push over-the-air firmware updates to vehicles (though 90% of the time, even new vehicle updates require a user USB install or dealership visit). But the fact it took GM five years of hammering away at the exploit to fix it makes it abundantly clear that the auto-industry is out of its depth when it comes to securing its new generation gee whizzery. And if it took five years to develop a single fix for a single vehicle, just how long do we think it will take for the auto industry to overhaul its entire vulnerability response and reporting systems?

Filed Under: connected cars, patching, security, vulnerabilities
Companies: gm

Argentina Rewards Programmer Who Exposed E-Voting Vulnerabilities With A Complimentary Home Police Raid

from the shoot-all-the-messengers dept

An Argentinian programmer who was trying to do a good thing in exposing severe vulnerabilities in the country's e-voting system was rewarded for his actions -- with a police raid on his home. According to Argentinian news outlet La Nación, Joaquín Sorianello informed MSA, the company than makes the Vot.ar e-voting system, that the SSL certificates used by the system to encrypt transmissions between the voting stations and the central election office could be easily downloaded, allowing for potential voting fraud (or just a good old-fashioned DDOS attack).

Sorianello, who says he never received a phone call from MSA after reaching out to the company to report the flaw, suddenly found his home being raided by Argentinian police, who seized computers, Kindles, and numerous storage devices (from a Google translation of the source):

"The truth is amazing, you notify the company that they have a failure in their voting system and the next thing they do is (raid my home) instead of looking for the real culprits..."I'm just a programmer, I'm not a hacker." Sorianello told La Nacion that he contacted the police station in Caballito to corroborate the raid: "They said yes, but they could not tell me why or how it was going to take." He also said he did not receive any call from the company (after having told them about the flaw a week) ago."

Sorianello has pointed out to numerous news outlets that he's a programmer -- not a hacker, and if he had wanted to hack into the systems to cause damage, he certainly wouldn't have informed the company of the flaw first. He's also repeatedly pointed out that it was the protected @FraudeVotar Twitter account that published the core details of the e-voting internals, not him. That apparently didn't matter to the Argentinian legal system.

This isn't the first problem facing MSA and its e-voting technology, which is being used in Buenos Aires elections for the first time. Two weeks ago, the source code for the company's Vot.ar technology was leaked to Git.hub. A number of researchers also discovered that a smartphone with NFC capabilities (pretty common at this point) could be used to create a specialized e-ballot, capable of tricking the system into counting a single vote numerous times. And this is all before you realize that in many instances, the technology Argentina is using just doesn't appear to work very well:

"Earlier today, the Argentinian site La Política Online reported that 532 polling stations were unable to transmit their results electronically to the central electoral office, and had to be transported there physically for the 184,000 votes involved to be included in the final result. As the article points out, although this failure won't change the outcome of the election for the head of local government in Buenos Aires, it will make a difference to the allocation of seats in the legislature and community boards."

So not only is MSA's e-voting system completely open to several vectors of fraud and attack, it works so damn well you need to physically move the machines back to the central office to count the tallied votes. Meanwhile, Argentinian locals are claiming that the same Judge that thought it was a good idea to authorize the police raid on Sorianello's home, has also ordered Argentinian ISPs to block many of the websites where details on the e-voting flaws and source code can be found (like justpaste.it). Surely if you stop people from discussing the obvious flaws, the problem magically goes away, right? As we've seen with countless other e-voting scandals of this type, you can't operate a secure, successful e-voting system without trust. And you certainly don't gain the public's trust by shooting as many messengers as possible and playing a futile game of Whac-a-mole censorship with those who point out your system is utterly and painfully flawed. What you do successfully accomplish is make it perfectly clear that you appear to like the fact your electoral process can now be rigged.

Filed Under: argentina, arrest, blame the messenger, e-voting, joaquin sorianello, security, vot.ar, vulnerabilities
Companies: msa

Yes, Another Massive Vulnerability Was Found In OpenSSL, But This Is Actually A Good Sign

from the five-eyes... dept

Yes, just about the time that we announced that Techdirt had shifted to 100% SSL, it came out that there was another massive flaw in OpenSSL, and we started to scramble to update our SSL (that's now done). This latest vulnerability would make man-in-the-middle attacks easier, which is a serious and significant problem, but it's a very different vulnerability than the high profile Heartbleed, that would just let people go fishing for all sorts of information on various servers. There's a good technical overview here, which indicates that the bug has actually... been around since at least 1998. So, uh, yeah, this vulnerability has been sitting out there for a long, long time.

While some will react to this with (perhaps reasonable) horror, it's worth remembering that, despite being such an integral piece of internet security infrastructure, OpenSSL has mostly been a part time project for those involved, and only recently (after Heartbleed) have efforts really been made to bump up the resources behind it and the careful security analysis of OpenSSL for vulnerabilities. As security expert Matthew Green points out, "the sudden proliferation of OpenSSL bugs is to be expected and a good thing. Like finding dirty socks during spring cleaning." In other words, there's a lot more attention being paid to OpenSSL and its security these days, and it's inevitable that vulnerabilities are going to be found. Expect more. But, in the long run, that's a good thing. The more attention there is to cleaning up such software, the better.

Filed Under: bugs, openssl, security, vulnerabilities