Journalists In St. Louis Discover State Agency Is Revealing Teacher Social Security Numbers; Governors Vows To Prosecute Journalists As Hackers

from the wtf-missouri? dept

Last Friday, Missouri's Chief Information Security Officer Stephen Meyer stepped down after 21 years working for the state to go into the private sector. His timing is noteworthy because it seems like Missouri really could use someone in their government who understands basic cybersecurity right now.

We've seen plenty of stupid stories over the years about people who alert authorities to security vulnerabilities then being threatened for hacking, but this story may be the most ridiculous one we've seen. Journalists for the St. Louis Post-Dispatch discovered a pretty embarrassing leak of private information for teachers and school administrators. The state's Department of Elementary and Secondary Education (DESE) website included a flaw that allowed the journalists to find social security numbers of the teachers and administrators:

Though no private information was clearly visible nor searchable on any of the web pages, the newspaper found that teachers’ Social Security numbers were contained in the HTML source code of the pages involved.

The newspaper asked Shaji Khan, a cybersecurity professor at the University of Missouri-St. Louis, to confirm the findings. He called the vulnerability “a serious flaw.”

“We have known about this type of flaw for at least 10-12 years, if not more,” Khan wrote in an email. “The fact that this type of vulnerability is still present in the DESE web application is mind boggling!”

In the HTML source code means that it sent that information to the computers/browsers of those who knew what pages to go to. It also appears that the journalists used proper disclosure procedures, alerting the state and waiting until it had been patched before publishing their article:

The Post-Dispatch discovered the vulnerability in a web application that allowed the public to search teacher certifications and credentials. The department removed the affected pages from its website Tuesday after being notified of the problem by the Post-Dispatch.

Based on state pay records and other data, more than 100,000 Social Security numbers were vulnerable.

The newspaper delayed publishing this report to give the department time to take steps to protect teachers’ private information, and to allow the state to ensure no other agencies’ web applications contained similar vulnerabilities.

Also, it appears that the problems here go back a long ways, and the state should have been well aware that this problem existed:

The state auditor’s office has previously sounded warning bells about education-related data collection practices, with audits of DESE in 2015 and of school districts in 2016.

The 2015 audit found that DESE was unnecessarily storing students’ Social Security numbers and other personally identifiable information in its Missouri Student Information System. The audit urged the department to stop that practice and to create a comprehensive policy for responding to data breaches, among other recommendations. The department complied, but clearly at least one other system contained an undetected vulnerability.

This is where a competent and responsible government would thank the journalists for finding the vulnerability and disclosing it in an ethical manner designed to protect the info of the people the state failed to properly protect.

But that's not what happened.

Instead, first the Education Commissioner tried to make viewing the HTML source code nefarious:

In the letter to teachers, Education Commissioner Margie Vandeven said “an individual took the records of at least three educators, unencrypted the source code from the webpage, and viewed the social security number (SSN) of those specific educators.”

It was never "encrypted," Commissioner, if the journalists could simply look at the source code and get the info.

Then DESE took it up a notch and referred to the journalists as "hackers."

But in the press release, DESE called the person who discovered the vulnerability a “hacker” and said that individual “took the records of at least three educators” — instead of acknowledging that more than 100,000 numbers had been at risk, and that they had been available to anyone through DESE’s own search engine.

And then, it got even worse. Missouri Governor Mike Parson called a press conference in which he again called the journalists hackers and said he had notified prosecutors and the Highway Patrol's Digital Forensic Unit to investigate. Highway Patrol? He also claimed (again) that they had "decoded the HTML source code." That's... not difficult. It's called "view source" and it's built into every damn browser, Governor. It's not hacking. It's not unauthorized.

It gets worse. Governor Parson claims that this "hack" could cost $50 million. I only wish I was joking.

This incident alone may cost Missouri taxpayers up to $50 million and divert workers and resources from other state agencies. This matter is serious.

The state is committing to bring to justice anyone who hacked our system and anyone who aided or encouraged them — In accordance with what Missouri law allows AND requires.

A hacker is someone who gains unauthorized access to information or content. This individual did not have permission to do what they did. They had no authorization to convert and decode the code. This was clearly a hack.

We must address any wrongdoing committed by bad actors.

If it costs $50 million to properly secure the data on your website that previous audits had already alerted you as a problem, then that's on the incompetent government who failed to properly secure the data in the first place. Not on journalists ethically alerting you to fix the vulnerability. And, there's no "unauthorized access." Your system put that info into people's browsers. There's no "decoding" to view the source. That's not how any of this works.

As people started loudly mocking Governor Parson, he decided to double down, insisting that it was more than a simple "right click" and repeating that journalists had to "convert and decode the data."

Again, even if it took a few steps, that's still not hacking. It's still a case where the state agency made that info available. That's not on the journalists who responsibly disclosed it. It's on the state for failing to protect the data properly (and for collecting and storing too much data in the first place).

Indeed, in doing this ridiculous show of calling them hackers and threatening prosecution, all the state of Missouri has done is make damn sure that the next responsible/ethical journalists and/or security researchers will not alert the state to their stupidly bad security. Why take the risk?

Filed Under: blame the messenger, dese, disclosure, ethical disclosure, hacking, mike parson, private information, schools, social security numbers, st. louis, teachers, vulnerabilities
Companies: st. louis post-dispatch

FBI Sat On Ransomware Decryption Key For Weeks As Victims Lost Millions Of Dollars

from the is-this-one-of-those-'greater-good'-things-I-don't-understand-becaus dept

The vulnerability equities process meets the FBI's natural tendency to find and hoard illegal things until it's done using them. And no one walks away from it unscathed. Welcome to the cyberwar, collateral damage!

If an agency like the NSA comes across an exploit or unpatched security flaw, it's supposed to notify affected tech companies so they can fix the problem to protect their customers and users. That's the vulnerability equities process in theory. In practice, the NSA (and others) weigh the potential usefulness of the exploit versus the damage it might cause if it's not fixed and make a disclosure decision. The NSA claims in public statements it's very proactive about disclosing discovered exploits. The facts say something different.

Then there's the FBI, which has engaged in criminal acts to further investigations. Perhaps most famously, the FBI took control of a dark web child porn server and ran it for a few weeks so it could deploy its malware (Network Investigative Technique, according to the FBI) to users of the site. Not only did it continue to distribute child porn during this time, but it reportedly optimized the system to maximize its malware distribution.

The trend continues. As Ellen Nakashima and Rachel Lerman report for the Washington Post (alternative link here), the FBI could have stopped a massive ransomware attack but decided it would be better if it just sat on what it knew and watched things develop.

The FBI refrained for almost three weeks from helping to unlock the computers of hundreds of businesses and institutions hobbled by a major ransomware attack this summer, even though the bureau had secretly obtained the digital key needed to do so, according to several current and former U.S. officials.

The key was obtained through access to the servers of the Russia-based criminal gang behind the July attack. Deploying it immediately could have helped the victims, including schools and hospitals, avoid what analysts estimate was millions of dollars in recovery costs.

The worse news is it wasn't just the FBI, which is already known for running criminal enterprises while engaging in investigations. The report says this refusal to release the key was a joint agreement with "other agencies," all of which apparently felt the nation (and the rest of the world) would be better served by the FBI keeping the key to itself while it tried to hunt down the criminals behind the ransomware attack.

And it turned out to be totally worth it!

The planned takedown never occurred because in mid-July REvil’s platform went offline — without U.S. government intervention — and the hackers disappeared before the FBI had a chance to execute its plan, according to the current and former officials.

FBI Director Chris Wray, testifying before Congress, said the tradeoff was necessary because it could help prevent future attacks (unproven) and time was needed to develop a tool that would help those hit by the ransomware.

"These are complex . . . decisions, designed to create maximum impact, and that takes time in going against adversaries where we have to marshal resources not just around the country but all over the world.”

He also suggested that “testing and validating” the decryption key contributed to the delay.

I, too, would testify before Congress that things were complex and time-consuming, especially when the end result was the bad guys getting away while victims remained victims. I would, however, perhaps consider not belaboring the "it will be long and hard" point when the private sector has demonstrated that it actually won't be that long, and possibly not even all that hard.

Emsisoft, however, was able to act quickly. It extracted the key from what the FBI provided Kaseya, created a new decryptor and tested it — all within 10 minutes, according to Fabian Wosar, Emsisoft chief technology officer. The process was speedy because the firm was familiar with REvil’s ransomware. “If we had to go from scratch,” Wosar said, “it would have taken about four hours.”

The FBI took three weeks to turn over the key to the first of many victims. During that time, it apparently failed to accomplish what Emisisoft developed in 10 minutes, as well as failing to catch any of the perpetrators. Faced with this not-so-subtle undercutting of its "we really were just trying to save the world" narrative, the FBI -- via its parent organization -- has decided to shut the fuck up.

The Justice Department and White House declined to comment.

Sure, the FBI could still be pursuing some leads, but the timing of REvil's disappearance and the FBI's release of the key to one of ransomware victims suggests the FBI only decided to release because it was no longer of any use to the investigation. It may still possess some limited use to those whose data is still locked up, but pretty much every victim has moved on and attempted to recover from the incident. The cost -- as is detailed in the Washington Post report -- is in the hundreds of millions. Some victims are still trying to recover. Others are back in business, but only after losing millions to downtime.

Who pays for this? Well, the victims do. And taxpayers will too, if the government decides to compensate some of the companies victimized by ransomware and victimized again by the FBI. The FBI, however, will hardly feel a thing, since the going rate for temporary chagrin is a rounding error in the agency's reputational damage column.

Filed Under: decryption, doj, fbi, ransomware, revil, vep, vulnerabilities, vulnerabilities equities process

Germany's Constitutional Court Ponders Whether Government Users Of Zero-Day Surveillance Malware Have A Duty To Tell Software Developers About The Flaws

from the resolving-conflicting-aims dept

As Techdirt has reported previously, the use of malware to spy on suspects -- or even innocent citizens -- has long been regarded as legitimate by the German authorities. The recent leak of thousands of telephone numbers that may or may not be victims of the Pegasus spyware has suddenly brought this surveillance technique out of the shadows and into the limelight. People are finally starting to ask questions about the legitimacy of this approach when used by governments, given how easily the software can be -- and apparently has been -- abused. An interesting decision from Germany's constitutional court shows that even one of the biggest fans of legal malware is trying to work out how such programs based on zero-days can be deployed in a way that's compatible with fundamental rights. The court's press release explains:

The complainants [to the constitutional court] essentially assert that, by enacting the authorisation laid down in [the German Police Act], the Land Baden-Württemberg violated the guarantee of the confidentiality and integrity of information technology systems -- a guarantee arising from fundamental rights -- because under that provision, the authorities have no interest in notifying developers of any vulnerabilities that come to their attention since they can exploit these vulnerabilities to infiltrate IT systems for the purpose of source telecommunications surveillance, which is permitted under [the German Police Act]. Yet if the developers are not notified, these vulnerabilities and the associated dangers -- in particular the danger of third-party attacks on IT systems -- will continue to exist.

That is, the failure to notify developers about the vulnerabilities means the authorities are putting IT systems in Germany at risk, and should therefore be stopped. The complainants went on to argue that if the court nonetheless ruled that the use of such malware was not considered "inherently incompatible with the state’s duty of protection", at the very least administrative procedures should be be established for evaluating the seriousness of the threat that leaving them unpatched would represent, and then deciding on a case-by-case basis whether the relevant developers should be notified.

The German constitutional court dismissed the complaint, but on largely technical grounds. The judgment said that the complainants did not have standing, because they had failed to substantiate a breach of the government's duty of protection. Moreover, the top court said the question should first be considered exhaustively by the lower courts, before finally moving to the constitutional court if necessary. However, the judges did recognize that there was a tension between a desire to use zero-days to carry out surveillance, and the German government's duty to protect the country and its computer systems:

In the present case, the duty of protection encompasses the obligation for the legislator to set out how the police are to handle such IT security vulnerabilities. Under constitutional law, it is not inherently impermissible from the outset for source surveillance to be performed by exploiting unknown security vulnerabilities, although stricter requirements for the justification of such surveillance apply due to the dangers posed to the security of IT systems. Furthermore, fundamental rights do not give rise to a claim that authorities must notify developers about any IT security vulnerabilities immediately and in all circumstances. However, the duty of protection does necessitate a legal framework that governs how -- in a manner compatible with fundamental rights -- an authority is to resolve the conflicting aims of protecting IT systems against third-party attacks that exploit unknown IT security vulnerabilities on the one hand, and on the other hand keeping such vulnerabilities open so that source surveillance can be carried out for the purpose of maintaining public security.

It's not clear whether that call for a legal framework to regulate how the authorities can deploy malware, and when they must alert developers to the flaw it exploits, will be heeded any time soon in Germany. But in the light of the Pegasus leak, it seems likely that other countries around the world will start to ponder this same issue. That's particularly the case since such malware is arguably the only way that the authorities can reliably circumvent encrypted communications without mandating the flawed and unworkable backdoors they have been calling for. If more countries decide to follow Germany in deploying these programs, the need for a legal framework to regulate their use will become even more pressing.

Follow me @glynmoody on Twitter, Diaspora, or Mastodon.

Filed Under: germany, malware, surveillance, vulnerabilities, zero day

Signal Founder Cracks Cellebrite Phone Hacking Device, Finds It Full Of Vulns

from the distinct-lack-of-'what-if-this-feel-into-the-wrong-hands'-thinking-by-Ce dept

A pretty hilarious turn of events has led to Cellebrite's phone hacking tech being hacked by Signal's Moxie Marlinspike, revealing the tech law enforcement uses to pull data from seized phones is host to major security flaws.

According to Marlinspike, the Cellebrite came into his possession thanks to some careless package handling.

By a truly unbelievable coincidence, I was recently out for a walk when I saw a small package fall off a truck ahead of me. As I got closer, the dull enterprise typeface slowly came into focus: Cellebrite. Inside, we found the latest versions of the Cellebrite software, a hardware dongle designed to prevent piracy (tells you something about their customers I guess!), and a bizarrely large number of cable adapters.

This must be what actually happened. I mean, there's a photo of a Cellebrite lying on the street. That should end any senseless law enforcement speculation about this device's origin story.

The fun starts immediately, with Marlinspike finding all sorts of things wrong with Cellebrite's own device security. This would seem to be a crucial aspect considering Cellebrite performs raw extractions of unvetted data from seized phones, which could result in the forced delivery of malware residing on the target device. But that doesn't appear to concern Cellebrite, which seems to feel its products will remain unmolested because they're only sold to government agencies.

Since almost all of Cellebrite’s code exists to parse untrusted input that could be formatted in an unexpected way to exploit memory corruption or other vulnerabilities in the parsing software, one might expect Cellebrite to have been extremely cautious. Looking at both UFED and Physical Analyzer, though, we were surprised to find that very little care seems to have been given to Cellebrite’s own software security. Industry-standard exploit mitigation defenses are missing, and many opportunities for exploitation are present.

Just one example of this carelessness is unpatched DLLs residing in the Cellebrite system software. One DLL used to handle extracted video content hasn't been updated since 2012, ignoring more than 100 patches that have been made available since then.

This means it wouldn't be much of a hassle to target Cellebrite devices with code that could corrupt not only the current data extraction but also the results of every previous extraction performed by that device.

[B]y including a specially formatted but otherwise innocuous file in an app on a device that is then scanned by Cellebrite, it’s possible to execute code that modifies not just the Cellebrite report being created in that scan, but also all previous and future generated Cellebrite reports from all previously scanned devices and all future scanned devices in any arbitrary way (inserting or removing text, email, photos, contacts, files, or any other data), with no detectable timestamp changes or checksum failures. This could even be done at random, and would seriously call the data integrity of Cellebrite’s reports into question.

That's a major problem because phone extractions are performed to secure evidence to use in criminal cases. If law enforcement agencies can't trust the data they've extracted or rely on the reports generated by Cellebrite to perform searches, they're going to find their evidence tossed or impossible to submit in the first place.

Further inspection of Cellebrite's software also shows the company has ported over chunks of Apple's proprietary code intact and is using it to assist in iPhone extractions. Presumably, Cellebrite hasn't obtained a license from Apple to use this code in its devices (and redistribute the code with every device sold), so perhaps we'll be hearing something from Apple's lawyers in the near future.

This table-turning was likely provoked by Cellebrite's incredibly questionable claim it had "cracked" Signal's encryption. Instead, as more information came out -- including its use in criminal cases -- it became clear Cellebrite did nothing more than anyone could do with an unlocked phone: open up the Signal app and obtain the content of those messages.

Fortunately for everyone not currently working for Cellebrite, a delivery incident occurred and a phone-hacking device was impacted. Signal isn't worried that Cellebrite can break its encryption. In fact, it doesn't appear to be worried at all. This examination of Cellebrite hacking tools will only result in a small cosmetic refresh for Signal.

In completely unrelated news, upcoming versions of Signal will be periodically fetching files to place in app storage. These files are never used for anything inside Signal and never interact with Signal software or data, but they look nice, and aesthetics are important in software. [...] We have a few different versions of files that we think are aesthetically pleasing, and will iterate through those slowly over time. There is no other significance to these files.

Maybe this will force Cellebrite to care a bit more deeply about its security and the security of its customers. Or maybe it will brute force its way past this, assuming its customers still have that "our word against yours" thing that tends to work pretty well in court. But it's not the only player in the phone-cracking field. So it might want to step its security game up a bit. Or at least stop picking fights with encrypted services.

Filed Under: hacking, moxie marlinspike, signal, vulnerabilities
Companies: cellebrite

Still Not 'Going Dark:' Device Encryption Still Contains Plenty Of Exploitable Flaws

from the good-news-and-bad-news-(which-some-might-consider-good-news) dept

Law enforcement -- especially at the federal level -- has spent a great deal of time complaining about an oddity known only to the FBI and DOJ as "warrant-proof" encryption. Device users and customers just call this "encryption" and realize this protects them against criminals and malicious hackers. The federal government, however, sees device encryption as a Big Tech slap in the face. And so they complain. Endlessly. And disingenuously.

First off, law enforcement has access to a wide variety of tech solutions. It also has access to plenty of communications and other data stored in the cloud or by third parties that encryption can't protect. And it has the users themselves, who can often be persuaded to allow officers to search their devices without a warrant.

Then there's the protection being handed out to phone users. It's got its own problems, as Matthew Green points out:

Authorities don't need to break phone encryption in most cases, because modern phone encryption sort of sucks.

More specifically, even the gold standard (Apple's) for encryption still leaves some stuff unencrypted. Once unlocked after a period of rest (say, first thing in the morning), the phone is placed into an "AFU" (after first unlock) state where crypto keys are stored in the phone. These stay in memory until erased. Most common use of phones won't erase them. And they're only erased one at a time, leaving several sets resident in memory where cops (and criminals!) using phone-cracking tech can still access them.

A report [PDF] put together by Matthew Green, Maximilian Zinkus, and Tushar Jois highlights the exploitable flaws of device encryption efforts by Apple, Google, and other device manufacturers. And there's not a lot of darkness going on, despite law enforcement's protestations.

This reaction is best exemplified by the FBI’s “Going Dark” initiative, which seeks to increase law enforcement’s access to encrypted data via legislative and policy initiatives. These concerns have also motivated law enforcement agencies, in collaboration with industry partners, to invest in developing and acquiring technical means for bypassing smartphone security features. This dynamic broke into the public consciousness during the 2016 “Apple v. FBI” controversy, in which Apple contested an FBI demand to bypass technical security measures. However, a vigorous debate over these issues continues to this day. Since 2015 and in the US alone, hundreds of thousands of forensic searches of mobile devices have been executed by over 2,000 law enforcement agencies, in all 50 states and the District of Columbia, which have purchased tools implementing such bypass measures.

The research here shows there's no need for legislative mandates or court orders to access most of the contents of suspects' iPhones. There's plenty to be had just by exploiting the shortcomings of Apple's built-in encryption.

[W]e observed that a surprising amount of sensitive data maintained by built-in applications is protected using a weak “available after first unlock” (AFU) protection class, which does not evict decryption keys from memory when the phone is locked. The impact is that the vast majority of sensitive user data from Apple’s built-in applications can be accessed from a phone that is captured and logically exploited while it is in a powered-on (but locked) state.

This isn't theoretical. This has actually happened.

[W]e found circumstantial evidence in both the DHS procedures and investigative documents that law enforcement now routinely exploits the availability of decryption keys to capture large amounts of sensitive data from locked phones. Documents acquired by Upturn, a privacy advocate organization, support these conclusions, documenting law enforcement records of passcode recovery against both powered-off and simply locked iPhones of all generations.

Utilizing Apple's iCloud storage greatly increases the risk that a device's contents can be accessed. Using iCloud to sync messages results in the decryption key being uploaded to Apple's servers, which means law enforcement, Apple, and malicious hackers all have potential access. Device-specific file encryption keys also make their way to Apple via other iCloud services.

Over on the Android side, it's a bigger mess. Multiple providers and manufacturers all use their own update services. Devices are phased out for ongoing protection by both, resulting in user confusion as to which devices still offer software updates and the latest in encryption tech. Cheaper devices sometimes bypass these niceties entirely, leaving low-cost options the most vulnerable to exploitation. And, while the DOJ and FBI may spend the most time complaining about Apple, it only commands about 15% of the smartphone market. This means most devices law enforcement seizes aren't secured by the supposedly "impenetrable" encryption provided by Apple.

Google's cloud services offer almost no protection for Android users. App creators must opt in to certain security measures. In most cases, data backed up to Google's cloud services is only protected by encryption keys Google holds, rather than the user uploading the data. Not only is encryption not much of a barrier, but neither is the legal system. A great deal of third party data -- like the comprehensive data sets maintained by Google -- can be accessed with only a subpoena.

The rest of the report digs deep into the strengths and limitations of encryption offered to phone users. But the conclusion remains unaltered: law enforcement does have multiple ways to access the contents of encrypted devices. And some of these solutions scale pretty easily. While it's not cheap, it's definitely affordable. While there will always be those who "got away," law enforcement isn't being hindered much by encryption that provides security to all phone users, whether or not they're suspected of criminal activity.

Filed Under: encryption, going dark, law enforcement, vulnerabilities

Tradeoffs: Facebook Helping The FBI Hack Tails To Track Down A Truly Awful Child Predator Raises Many Questions

from the icky-in-many-ways dept

Last week, Lorenzo Franceschi-Bicchierai at Vice had a bombshell of a story about Facebook helping the FBI track down a horrible, horrible person by paying a cybersecurity firm to build a zero-day attack on Tails, the secure operating system setup that is recommended by many, including Ed Snowden, for people who want to keep secrets away from the prying eyes of the government.

The story should make you uncomfortable on multiple levels -- starting with the fact that the person at the center of the story, Buster Hernandez, is way up there on the list of truly terrible people, and there's simply no reason to feel bad that this person is now locked up:

The crimes Buster Hernandez committed were heinous. The FBI's indictment is a nauseating read. He messaged underage girls on Facebook and said something like “Hi, I have to ask you something. Kinda important. How many guys have you sent dirty pics to cause I have some of you?,” according to court records.

When a victim responded, he would then demand that she send sexually explicit videos and photos of herself, otherwise he would send the nude photos he already had to her friends and family (in reality, he didn’t have any nude photos). Then, and in some cases over the course of months or years, he would continue to terrorize his victims by threatening to make the photos and videos public. He would send victims long and graphic rape threats. He sent specific threats to attack and kill victims’ families, as well as shoot up or bomb their schools if they didn’t continue to send sexually explicit images and videos. In some cases, he told victims that if they killed themselves, he would post their nude photos on memorial pages for them.

And it gets worse from there. It's good that the FBI tracked him down.

But, from there, you suddenly start to run into a bunch of other uncomfortable questions regarding Facebook's involvement here. And each of those questions helps demonstrate the many tradeoffs that a company like Facebook (or lots of other internet companies) face in dealing with awful people online. And to be clear there is no "good" answer here. Every approach has some good elements (getting a horrible person away from continuing to terrorize young girls) and some not so great elements (helping the FBI hack Tails, which is used by journalists, whistleblowers, and dissidents around the globe).

The article notes that there was a vigorous debate within Facebook about this decision, but the folks in charge decided that tracking this person down outweighed the concerns on the other side:

“The only acceptable outcome to us was Buster Hernandez facing accountability for his abuse of young girls,” a Facebook spokesperson said. “This was a unique case, because he was using such sophisticated methods to hide his identity, that we took the extraordinary steps of working with security experts to help the FBI bring him to justice.”

Former employees at Facebook who are familiar with the situation told Motherboard that Hernandez's actions were so extreme that the company believed it had been backed into a corner and had to act.

“In this case, there was absolutely no risk to users other than this one person for which there was much more than probable cause. We never would have made a change that affected anybody else, like an encryption backdoor,” said a former Facebook employee with knowledge of the case. “Since there were no other privacy risks, and the human impact was so large, I don’t feel like we had another choice.”

That does sound like a balancing of the risk/rewards here, but the idea that handing over a backdoor to the FBI puts no one else's privacy at risk may raise some eyebrows. The description of the zero day certainly sounds like it could be used against others:

Facebook hired a cybersecurity consulting firm to develop a hacking tool, which cost six figures. Our sources described the tool as a zero-day exploit, which refers to a vulnerability in software that is unknown to the software developers. The firm worked with a Facebook engineer and wrote a program that would attach an exploit taking advantage of a flaw in Tails’ video player to reveal the real IP address of the person viewing the video. Finally, Facebook gave it to an intermediary who handed the tool to the feds, according to three current and former employees who have knowledge of the events.

And while the Facebook spokesperson tried to play down the idea that this was setting an expectation, it's not really clear that's true:

Facebook told Motherboard that it does not specialize in developing hacking exploits and did not want to set the expectation with law enforcement that this is something it would do regularly. Facebook says that it identified the approach that would be used but did not develop the specific exploit, and only pursued the hacking option after exhausting all other options.

But this may be hard to swallow, given that this is the very same FBI that has been pushing tech companies to develop backdoors to encryption for years, and in the famous San Bernardino case, tried to use the All Writs Act to force Apple to create a type of backdoor on iOS to break into a phone.

And obviously, cooperating one time doesn't mean you need to cooperate every time, but it will at least raise questions. Especially at a time when Facebook is supposedly moving all of its messaging systems to fully encrypted. Can the setup there be fully trusted after this story?

As Bruce Schneier rightfully points out, it's fine for the FBI to figure out how to use lawful hacking to track down Hernandez. That is it's job. It's much less clear, though, that Facebook should be handing that info over to the FBI which could then use it elsewhere as well. It certainly does not appear that the FBI or Facebook revealed to the developers of Tails that their system had this vulnerability. Indeed, Tails only found out about it from the Vice story:

A spokesperson for Tails said in an email that the project’s developers “didn't know about the story of Hernandez until now and we are not aware of which vulnerability was used to deanonymize him.” The spokesperson called this "new and possibly sensitive information," and said that the exploit was never explained to the Tails development team.

So... that's a problem. The FBI, under the Vulnerabilities Equities Program, is supposed to reveal these kinds of vulnerabilities -- though it frequently does not (or hangs on to them for a long time before sharing). At the very least, this confirms lots of people's suspicions that the Trump administration's updating of the VEP process was little more than window dressing.

Senator Ron Wyden -- who is often the only one in Congress paying attention to these things -- also seemed quite concerned about how this all went down:

“Did the FBI re-use it in other cases? Did it share the vulnerability with other agencies? Did it submit the zero-day for review by the inter-agency Vulnerabilities Equity Process?” Wyden said in a statement, referring to the government process that is supposed to establish whether a zero-day vulnerability should be disclosed to the developers of the software where the vulnerability is found. “It’s clear there needs to be much more sunlight on how the government uses hacking tools, and whether the rules in place provide adequate guardrails.”

And thus, we're all left in an uncomfortable place. It's good that the FBI was able to trackdown and find Hernandez, and stop him from preying on any more victims. But, Facebook's direct involvement raises tons of uncomfortable questions, as does the FBI's decision to keep this vulnerability a secret (at the very least, it seems like Facebook maybe should have tipped off the Tails folks as well, once the FBI nabbed Hernandez). In an ideal world, the FBI would have figured out how to track down Hernandez without Facebook paying a firm to build the zero-day attack -- and then the FBI would have notified Tails' developers of the vulnerability. But, of course, that's not what happened.

Filed Under: buster hernandez, fbi, hack, tails, tracking, vep, vulnerabilities, zero day
Companies: facebook

NSA Surprises Microsoft With A Vulnerability Disclosure Just In Time For Patch Tuesday

from the what-do-you-give-to-a-company-that-has-everything-but-knowledge-of-this-exploit dept

Given the NSA's track record with vulnerability disclosures, it's somewhat of an anomaly when it actually decides the security of millions of innocent computer users is more important than its exploitation of a security flaw. Ellen Nakishima has the details for the Washington Post:

The National Security Agency recently discovered a major flaw in Microsoft’s Windows operating system — one that could potentially expose computer users to significant breaches or surveillance — and alerted the firm of the problem rather than turn it into a hacking weapon, according to people familiar with the matter.

The flaw affects Windows 10 users, the largest user base Microsoft currently has. The vulnerability could have been weaponized by the NSA, as so many others have been. The agency has consistently withheld knowledge of vulnerabilities from affected companies until the exploits have outlived their uselessness.

The equity program, meant to ensure companies are notified of serious software flaws, has routinely been ignored by the NSA, leading directly to the EternalBlue cataclysm that saw malicious hackers repurpose the exploit and unleash ransomware attacks on multiple targets around the world.

Microsoft was not happy. It released a long statement decrying the Intelligence Community's refusal to completely participate in the Vulnerability Equities Process. As ransomware attacks brought multiple critical facilities to their knees, the NSA was justifying its "better way too late than never" approach with statements about the difficulty of developing useful surveillance tools.

It may have been Microsoft's response to the WannaCry attacks that prompted the NSA's proactive disclosure of this vulnerability. This security flaw is strikingly similar to the one exploited for years by the NSA -- the one that became ransomware once the Shadow Brokers made the vulnerability available to whoever wanted it.

The discovery has been likened to a slightly less severe version of the Microsoft flaw that the NSA once weaponized by creating a hacking tool dubbed EternalBlue, which one former agency hacker said was like “fishing with dynamite.”

Like EternalBlue, the vulnerability disclosed here is "God mode" for malicious hackers and surveillance agencies.

Companies like Microsoft and Adobe use digital signatures to stamp software as authentic. This helps to prevent malware infections that might try to disguise themselves as legitimate. The NSA discovered an error in the Microsoft code that verifies those signatures, potentially enabling a hacker to forge the signature and install spyware or ransomware on a computer.

Microsoft's patch will have been issued by the time you read this. The good news beyond the NSA's surprise disclosure is that Microsoft has not seen the flaw exploited. Yet. A patch is only as good as the end users' application of it. That's somewhat beyond Microsoft's control but Windows 10 is pretty aggressive about pushing updates, so it shouldn't take too long to close this hole.

This likely doesn't signal a large-scale change in the way the IC handles vulnerability disclosure. Exploits and vulnerabilities will continue to be hoarded, even if the potential collateral damage is billions of dollars. After all, billions will be lost by targets of attacks predicated on hoarded vulnerabilities. The NSA won't lose anything, not even a little sleep.

Filed Under: nsa, patch tuesdsay, veb, vulnerabilities, vulnerabilities equities program, windows 10
Companies: microsoft

The Ultimate Bad Take: Bloomberg's Leonid Bershidsky Thinks A WhatsApp Vulnerability Proves End To End Encryption Is Useless

from the no,-no,-wrong,-wrong dept

Bloomberg has really been on a roll lately with getting security stories hellishly wrong. Last fall it was its big story claiming that there was a supply chain hack that resulted in hacked SupermMicro chips being used by Amazon and Apple. That story has been almost entirely debunked, though Bloomberg still has not retracted the original. Then, just a few weeks ago, it flubbed another story, claiming that the presence (years ago) of telnet in some Huawei equipment was a nefarious backdoor, rather than a now obsolete but previously fairly common setup for lots of equipment for remote diagnostics and access.

The latest is an opinion piece, rather than reporting, but it's still really bad. Following yesterday's big revelation that a big security vulnerability was discovered in WhatsApp, opinion columnist Leonid Bersidsky declared it as evidence that end-to-end encryption is pointless. This is, to put it mildly, a really, really bad take. The whole article is a confused jumble of mostly nonsense, mixed with stuff that was already widely known and irrelevant:

The discovery that hackers could snoop on WhatsApp should alert users of supposedly secure messaging apps to an uncomfortable truth: “End-to-end encryption” sounds nice — but if anyone can get into your phone’s operating system, they will be able to read your messages without having to decrypt them.

Um. Duh? The whole point of end-to-end encryption is that it protects messages in transit and not at rest. That's the whole "end-to-end" bit. At the ends it's decrypted. You can also encrypt content on a device -- this is what the FBI is so annoyed about regarding Apple's iPhone encryption -- but to argue that end-to-end encryption is pointless because it doesn't do what it's not supposed to do in the first place is crazy.

It gets worse:

“End-to-end encryption” is a marketing device used by companies such as Facebook to lull consumers wary about cyber-surveillance into a false sense of security.

It is true that some people confuse "end-to-end encryption" with perfect security, which it is not. But it is simply wrong (laughably so) to say that it's merely a "marketing device." In actuality, end-to-end encryption is a hugely important part of what keeps your data protected when you communicate online. It provides real security for the conditions it's designed to provide security for -- and not other conditions, such as the one the hack takes advantage of.

Bershidsky complaining about on-device malware reading your WhatsApp messages as being evidence that end-to-end encryption is pointless is like arguing that you should never wear seatbelts because they won't protect you if you drive off a cliff. Seatbelts protect you in lots of common scenarios, but might not protect you in extreme scenarios like driving off a cliff. And end-to-end encryption protects you in lots of messaging scenarios, but won't protect you if someone can install something directly on your device.

The tug of war between tech firms touting end-to-end encryption as a way to avoid government snooping and state agencies protesting its use is a smokescreen. Government and private hackers are working feverishly on new methods to deploy malware with operating system-wide privileges.

It's not a "smokescreen." It's dealing with one type of attack. It's bizarre to suggest that end-to-end encryption is useless because there are some advanced ways that people can get around it, ignoring all the other ways that it helps protect most people. End-to-end encryption does much more to protect tons of people, and saying that we can ignore it just because it doesn't stop all attacks is really dangerous.

Bloomberg should be ashamed to be publishing such dangerous nonsense. It is the equivalent of anti-vax nonsense, telling people not to protect themselves.

Filed Under: at rest, cybersecurity, encryption, end to end encryption, in transit, leonid bersidsky, vulnerabilities
Companies: bloomberg, facebook, whatsapp

EternalSuffering: NSA Exploits Still Being Successfully Used To Hijack Computers More Than A Year After Patching

from the can't-stop-won't-stop dept

Everything old and awful is new again. And still awful. Zack Whittaker reports for TechCrunch that the NSA's purloined kit of computer nasties is still causing problems more than a year after security patches were issued by affected vendors.

[A]kamai says that attackers are using more powerful exploits to burrow through the router and infect individual computers on the network. That gives the attackers a far greater scope of devices it can target, and makes the malicious network far stronger.

“While it is unfortunate to see UPnProxy being actively leveraged to attack systems previously shielded behind the NAT, it was bound to happen eventually,” said Akamai’s Chad Seaman, who wrote the report.

There are more technical details in Akamai's report, which notes the deployment of EternalRed and EternalBlue, which target Linux and Windows machines respectively. It appears to be a massive crime of opportunity, with attackers possibly scanning the entire internet for vulnerable ports/paths and injecting code to gain control of computers and devices. The "shotgun approach" isn't efficient but it is getting the job done. Akamai refers to this new packaging of NSA exploits as EternalSilence, after the phrase "galleta silenciosa" ("silent cookie/cracker") found in the injected rulesets.

The damage caused by this latest wave of repurposed surveillance code could still be rather severe, even with several rounds of patches immunizing a large number of devices against this attack.

Currently, the 45,113 routers with confirmed injections expose a total of 1.7 million unique machines to the attackers. We've reached this conclusion by logging the number of unique IPs exposed per router, and then added them up. It is difficult to tell if these attempts led to a successful exposure as we don't know if a machine was assigned that IP at the time of the injection. Additionally, there is no way to tell if EternalBlue or EternalRed was used to successfully compromise the exposed machine. However, if only a fraction of the potentially exposed systems were successfully compromised and fell into the hands of the attackers, the situation would quickly turn from bad to worse.

More of the same, then. Perhaps not at the scale seen in the past, but more attacks using the NSA's hoarded exploits. Hoarding exploits is a pretty solid plan, so long as they don't fall into the hands of… well, anyone else really. Failing to plan for this inevitability is just one of the many problems with the NSA's half-assed participation in the Vulnerability Equities Process.

Since the tools began taking their toll on the world's computer systems last year, there's been no sign the NSA is reconsidering its stance on hunting and hoarding exploits. The intelligence gains are potentially too large to be sacrificed for the security of millions of non-target computer users. It may claim these tools are essential to national security, but for which nation? The exploits wreaked havoc all over the world, but it would appear the stash of exploits primarily benefited one nation before they were inadvertently dumped into the public domain. Do the net gains in national security outweigh the losses sustained worldwide? I'd like to see the NSA run the numbers on that.

Filed Under: exploits, malware, nsa, online security, vulnerabilities

GCHQ Propose A 'Going Dark' Workaround That Creates The Same User Trust Problem Encryption Backdoors Do

from the wiretaps-but-for-Whatsapp dept

Are we "going dark?" The FBI certainly seems to believe so, although its estimation of the size of the problem was based on extremely inflated numbers. Other government agencies haven't expressed nearly as much concern, even as default encryption has spread to cover devices and communications platforms.

There are solutions out there, if it is as much of a problem as certain people believe. (It really isn't… at least not yet.) But most of these solutions ignore workarounds like accessing cloud storage or consensual searches in favor of demanding across-the-board weakening/breaking of encryption.

A few more suggestions have surfaced over at Lawfare. The caveat is that both authors, Ian Levy and Crispin Robinson, work for GCHQ. So that should give you some idea of which shareholders are being represented in this addition to the encryption debate.

The idea (there's really only one presented here) isn't as horrible as others suggested by law enforcement and intelligence officials. But that doesn't mean it's a good one. And there's simply no way to plunge into this without addressing an assertion made without supporting evidence towards the beginning of this Lawfare piece.

Any functioning democracy will ensure that its law enforcement and intelligence methods are overseen independently, and that the public can be assured that any intrusions into people’s lives are necessary and proportionate.

By that definition, the authors' home country is excluded from the list of "functioning democracies." Multiple rulings have found GCHQ's surveillance efforts in violation of UK law. And a number of leaks over the past half-decade have shown its oversight is mostly ornamental.

The same can be said for the "functioning democracy" on this side of the pond. Leaked documents and court orders have shown the NSA frequently ignores its oversight when not actively hiding information from Congress, the Inspector General, and the FISA court. Oversight of our nation's law enforcement agencies is a patchwork of dysfunction, starting with friendly magistrates who care little about warrant affidavit contents and ending with various police oversight groups that are either filled with cops or cut out of the process by the agencies they nominally oversee. We can't even get a grip on routine misconduct, much less ensure "necessary and proportionate intrusions into people's lives."

According to the two GCHQ reps, there's a simple solution to eavesdropping on encrypted communications. All tech companies have to do is keep targets from knowing their communications are no longer secure.

In a world of encrypted services, a potential solution could be to go back a few decades. It’s relatively easy for a service provider to silently add a law enforcement participant to a group chat or call. The service provider usually controls the identity system and so really decides who’s who and which devices are involved - they’re usually involved in introducing the parties to a chat or call. You end up with everything still being end-to-end encrypted, but there’s an extra ‘end’ on this particular communication. This sort of solution seems to be no more intrusive than the virtual crocodile clips that our democratically elected representatives and judiciary authorise today in traditional voice intercept solutions and certainly doesn’t give any government power they shouldn’t have.

We’re not talking about weakening encryption or defeating the end-to-end nature of the service. In a solution like this, we’re normally talking about suppressing a notification on a target’s device, and only on the device of the target and possibly those they communicate with. That’s a very different proposition to discuss and you don’t even have to touch the encryption.

Suppressing notifications might be less harmful than key escrow or backdoors. It wouldn't require a restructuring of the underlying platform or its encryption. If everything is in place -- warrants, probable cause, exhaustion of less intrusive methods -- it could give law enforcement a chance to play man-in-the-middle with targeted communications.

But there's a downside -- one that isn't referenced in the Lawfare post. If both ends of a conversation are targeted, this may be workable. But what if one of the participants isn't a target? This leaves them unprotected because the suppressed messages wouldn't inform other non-target parties the conversation isn't protected. Obviously it wouldn't do the let anyone targets converse with know things are no longer normal on the target's end, as it's likely one of those participants will let the target know they've encountered a security warning while talking to them.

In that respect, it is analogous to a wiretap on someone's phones. It will capture innocent conversations irrelevant to the investigation. In those cases, investigators are told to stop eavesdropping. It's unclear how the same practice will work when the communications are being harvested digitally via unseen government additions to private conversations.

This proposal seems at odds with the authors' suggested limitations, especially this one:

Any exceptional access solution should not fundamentally change the trust relationship between a service provider and its users.

When a service provider starts suppressing warning messages, the trust relationship is going to be fundamentally altered. Even if users are made aware this is only happening in rare instances involving targets of investigations, the fact that their platform provider has chosen to mute these messages means they really can't trust a lack of warnings to mean everything is still secure.

On the whole, it's a more restrained solution than others have proposed -- but it still has the built-in exploitation avenue key escrow does. It's better than a backdoor but not by much. And the authors of this proposal shouldn't pretend the solution lives up to the expectations they set for it. Their own proposal falls short of their listed ideals… and the whole thing is delivered under the false pretense law enforcement/intelligence agencies are subject to robust oversight.

Filed Under: backdoors, encryption, gchq, going dark, third parties, vulnerabilities