Oversight Report Shows NSA Failed To Secure Its Systems Following The Snowden Leaks

from the NSA-officials:-'feel-good-story-of-2015,-etc.' dept

It appears the NSA hasn't learned much since Ed Snowden left with several thousands of its super-secret documents. Agency officials were quick to claim the leaks would cause untold amounts of damage, but behind the scenes, not much was being done to make sure it didn't happen again.

A Defense Department Inspector General's report obtained via FOIA lawsuit by the New York Times shows the NSA fell short of several security goals in the post-Snowden cleanup. For an agency that was so concerned about being irreparably breached, the NSA still seems primed for more leakage. Charlie Savage reports:

The N.S.A. failed to consistently lock racks of servers storing highly classified data and to secure data center machine rooms, according to the report, an investigation by the Defense Department’s inspector general completed in 2016. The report was classified at the time and made public in redacted form this week in response to a Freedom of Information Act lawsuit by The New York Times.

The agency also failed to meaningfully reduce the number of officials and contractors who were empowered to download and transfer data classified as top secret, as well as the number of “privileged” users, who have greater power to access the N.S.A.’s most sensitive computer systems. And it did not fully implement software to monitor what those users were doing.

Let's not forget the NSA wants to be engaged in ensuring the cybersecurity of the nation. It's repeatedly asked for more power and a better seat in the CyberWar room. But it doesn't even take its OWN security seriously. The NSA told its oversight it was engaging in 40 "Secure the Net" initiatives, directly after the first Snowden leak. Two years later, it told Congress it had completed 34 of 40 STN initiatives. The term "completion" apparently has multiple definitions, depending on who's using the word. The IG sampled only seven of the initiatives and found four were mostly done and three were nowhere near completed. Extrapolating from the sampling, it's safe to assume the NSA's internal security efforts are only slightly more than half-baked.

The three the NSA failed to implement are of crucial importance, especially if it's looking to keep its in-house documents safe at home. From the report [PDF]:

NSA officials did not effectively implement three PRIVAC [Privileged Access]-related STN initiatives:

- fully implement technology to oversee privileged user activities;

- effectively reduce the number of privileged users; and

- effectively reduce the number of authorized DTAs [Data Transfer Agents].

First off, the NSA -- prior to the Snowden leaks -- had no idea how many users had privileged access. Post-Snowden, things hardly improved. Considering the tech capabilities of the agency, it's incredibly amusing to see how the NSA "tracked" privileged users.

NSA officials stated they used a manually kept spreadsheet, which they no longer had, to identify the initial number of privileged users.

Pretty much useless, considering this number the NSA couldn't verify (thanks to its missing spreadsheet) was supposed to be used to establish a baseline for the planned reduction in privileged users. Despite missing this key data, the NSA moved ahead, "arbitrarily revoking access" and asking users to reapply for privileged status. It then reported a reduction by citing the number of users it denied restoration of access privileges. It did not factor in any new users it granted privileged access to or tally up the number of accounts it never bothered to revoke.

As the fully-redacted chart presumably points out (according to the text above it), the NSA had a "continued and consistent increase in the number of privileged users once the [redacted] enrollment process began."

The NSA also claimed it had reduced the number of DTAs. And again, the NSA had no receipts.

Although repeatedly requested, NSA officials could not provide supporting documentation for the total number of DTAs before and after the purge or the actual number of users purged.

The NSA's objectively-terrible internal controls (again) ensured no number could be verified.

NSA did not know how many DTAs it had because the manually kept list was corrupted during the months leading up to the security breach.

The NSA handled these missing numbers the same way it had privileged users: it made up a new baseline, arbitrarily decided it could show a downtrend in DTAs, and delivered this as "proof" of another completed security initiative.

The report points out repeatedly the NSA's failure to provide documentation backing its STN claims -- either from before the initiatives took force or after they supposedly hag been completed. The IG's comments note the NSA's response to the report ignored its detailed description of multiple failures in order to spin this as a "win" for the agency.

Although the Director, Technology Directorate NSA/CSS Chief Information Officer, agreed, he did not address all the specifics of the recommendation. Therefore, we request that the director provide additional comments on the final report that identify specific actions NSA will take.

Here's how the NSA portrayed the report's findings:

While the Media Leak events that led to Secure the Net (STN) were both unforeseen and serious, we consider the extensive progress we made in a short time to be a "good news" story.

Sure, if you consider a half-done job securing NSA assets to be "good news," rather than just an ongoing series of security holes left halfway unplugged while agency officials testify before Congressional oversight in front of a "MISSION ACCOMPLISHED" banner backdrop.

Filed Under: cybersecurity, ed snowden, nsa, security

GOP Data Firm Left The Personal Data Of 198 Million American Voters On Openly-Accessible Amazon Server

from the whoops-a-daisy dept

A GOP data firm has accepted responsibility for leaving the personal data of 198 million Americans (aka: most of the country's voting populace) openly accessible on an Amazon server in the biggest voter data leak in global history. Deep Root Analytics, the owner of the data, has long been contracted by the Republican National Committee to measure voter opinions on a wide variety of issues, from health care to gun control. As part of their contract with the RNC, the group pulls voter information from a wide variety of sources, ranging from Reddit to the Karl Rove super PAC American Crossroads.

This data, which includes religious affiliation and ethnicity, is then utilized to help craft PR efforts and other messaging, as well as to determine turnout and voter preferences. And, according to analysis of the data and previous profiles of the company like this one over at Ad Age, this firm was hugely influential in getting Donald Trump's "populist" message out to voters during the last election cycle.

But last week, UpGuard cyber risk analyst Chris Vickery discovered that Deep Root had been storing a massive amount of this data on Amazon servers, publicly accessible via the internet, with absolutely no apparent security precautions whatsoever:

The data repository, an Amazon Web Services S3 bucket, lacked any protection against access. As such, anyone with an internet connection could have accessed the Republican data operation used to power Donald Trump’s presidential victory, simply by navigating to a six-character Amazon subdomain: “dra-dw”.

Vickery frequently hunts for misconfigured data sources on behalf of UpGuard's Cyber Risk Team, often finding everything from military engineering plans to lists of potential terrorists -- simply sitting out in the open. Vickery had recently exposed a top defense contractor for doing something similar, albeit on a notably smaller scale. In this instance, the openly-accessible data included names, addresses, birthdates, phone numbers, troves of stored online user posts, collected over the better part of the last decade:

"Within “data_trust” are two massive stores of personal information collectively representing up to 198 million potential voters. Consisting primarily of two file repositories, a 256 GB folder for the 2008 presidential election and a 233 GB folder for 2012, each containing fifty-one files - one for every state, as well as the District of Columbia. Each file, formatted as a comma separated value (.csv), lists an internal, 32-character alphanumeric “RNC ID”—such as, for example, 530C2598-6EF4-4A56-9A7X-2FCA466FX2E2—used to uniquely identify every potential voter in the database. These RNC IDS uniquely link disparate data sets together, combining dozens of sensitive and personally identifying data points, making it possible to piece together a striking amount of detail on individual Americans specified by name."

One segment of the files contained modeled data about each individual voter's likely positions on 46 different issues. Other portions of the data detail whether voters are registered, and whether they are currently on the federal "Do Not Call" list (you may recall that the RNC is currently supporting a proposal that would let them spam your voicemail inbox without your phone ringing). Collectively, this data was collected and used by a massive number of Republican outfits, including Americans for Prosperity, market research firm TargetPoint, Causeway Solutions, and more.

The security faux pas is considered one of the most monumental ever documented in any country. The 198 million American voters exposed by this screw up dwarves the previous biggest leak -- a leak of the voting data of 93.4 million Mexican citizens -- as well as the now-third biggest leak of this kind ever -- the exposure of the data of 55 million voters in the Philippines. On the plus side, a statement being provided by Deep Root to the media takes ownership of the screw up, without too much of the couching you often see after such breaches:

"We have engaged Stroz Freidberg to conduct a thorough review, and that process is underway. Based upon this review we have determined that the access that was made without our knowledge happened because of a change that was made in the files’ asset access protocols. We are in the process of determining how that change was made and take full responsibility for the change, but suffice to say we have updated the settings to prevent further access. We believe the change that was made happened post June 1 2017, which was when we last evaluated and updated our security settings. We do not believe that our systems have been hacked. To date, the only entity that we are aware of that had access to the data was Chris Vickery."

Still, it's not exactly a confidence builder to witness the largest leak of voter data in global history as we're busy trying to ascertain just how secure our clearly dysfunctional voting systems are to malicious outside influence -- and debating the slow-but-steady erosion of consumer privacy protections being spearheaded by the GOP.

Filed Under: chris vickery, gop, online security, privacy, rnc, security, voter data
Companies: deep root

Hospital Sends Legal Threats To Researcher, Then Asks For Her Help Identifying Breach Victims

from the sooooo-sorry-about-the-bullets... dept

Shooting the messenger is the most popular response to reported data breach, making the job of security researcher far more dangerous than it should ever be. The twist in the latest "shoot the messenger" story is the shooter coming back around to ask the shooting victim for help. Bad idea. Even if the body is still warm and breathing, it's probably not in the best of moods.

Dissent Doe runs databreaches.net, a site that covers all sorts of exposed data stories. Sometimes, Doe is asked by those discovering security holes to disclose the information to the affected parties. (See above paragraph for why.) In early May, Doe tried to alert the Bronx-Lebanon Hospital Center about confidential patient records left exposed by a contractor. The stuff exposed was deeply personal, containing write-ups of patients' substance abuse problems or mental illnesses.

This didn't go well. The hospital didn't want to talk about it or explain why a third-party had so much access to confidential health records, much less why it hadn't bothered to properly secure the hospital's database. One day after these mostly futile phone calls, someone (not specified in the post) contacted Dissent Doe to let her know the databases had been secured and thanking her for notifying them.

That should have been the end of the story. But it wasn't.

It was a brief honeymoon. On May 9, Kromtech published their report and I published my first report on the incident without any statement from the hospital or vendor, neither of whom had provided a promised statement.

Then on May 12, coordinated threat letters arrived via email from external counsel for both iHealth and Bronx-Lebanon Hospital. DataBreaches.net understands that Kromtech Security also received similar letters.

I’ll let that sink in for a minute: they threatened a person who went out of her way to alert them they were leaking protected health information. Instead of saying, “Thank you so much, and can we also ask you to please securely destroy any data you might have in your possession?” they sent me threat letters.

The stupid, angry letters contained stupid, angry threats. First, the letters accused Doe of improper access. Then they went on to demand she and everyone else in possession of this data delete it and send a certified letter (or something) back to the hospital and vendor confirming the destruction of the data. They also demanded she reveal her sources and not post anything further about the breach.

Doe didn't think much of the demands, but she did retain counsel just in case. An angry, non-stupid response letter from her legal rep changed the tone of the demands into more polite requests. Not that the change in tone won Doe over. A bridge only needs to be burnt once to render it useless. And, in one sense, the angry, stupid threat letter did work: while Doe didn't cave, it appeared that Kromtech did delete the data it had discovered. That resulted in a problem.

Apparently, the hospital and vendor forgot about their earlier bridge-torching efforts. They approached Doe again, this time asking for help identifying which patients had had their personal info exposed in order to notify them.

Now the entities could just notify everyone who had PHI/PII on the server, of course, but it seemed like they were trying to narrow the universe to only those whose data wound up in Kromtech’s hands – or this site’s – or NBC News’ hands. And now Kromtech could not tell them which patients had data in the 500 mb of data they had downloaded and then destroyed.

But Kromtech had sent a subset of that data to DataBreaches.net, who had not destroyed the data it possessed. If DataBreaches.net wanted to be helpful, it could go through all the data and let the entities know which patients had data in there, right?

But why should Doe do this? The two affected entities had already expressed their gratitude using legal threats, not exactly the best foundation for future collaborative efforts.

I might have been able to spare the vendor and hospital some notifications if I was willing to donate my time to going through files to compile information for them, but I’m not willing.

I’m not willing, in part, because I do not want to be going through PHI if it’s not for my reporting purposes. And I’m not willing because why should I have to spend my valuable time compiling information for entities that tried to bully me and who now need my help to help them clean up their mess??

Shooting the messenger kills potential allies. But far too many entities think it's better to shoot first and live with their regrets later. Security researchers aren't the enemy of privacy, but they're often treated as criminals and malcontents by entities who have screwed up their own security efforts.

Filed Under: dissent doe, leaks, reporting, security, shoot the messenger, threats
Companies: bronx-lebanon hospital center, kromtech

Could Firmware Expiration Dates Fix The Internet Of Broken Things...Before People Get Hurt?

from the the-looming-global-IOT-shitstorm dept

If you hadn't noticed, the incredibly flimsy security in most Internet of Things devices has resulted in a security and privacy dumpster fire of epic proportions. And while recent, massive DDoS attacks like the one leveled against DNS provider DYN last year are just one symptom of this problem, most security analysts expect things to get significantly, dramatically worse before they get better. And by worse, most of them mean dramatically worse; as in these vulnerabilities are going to result in attacks on core infrastructure that will inevitably result in human deaths... at scale.

Estimates suggest that 21 billion to 50 billion IoT devices are expected to come online by 2020. That's 21 to 50 billion new attack vectors on homes, businesses and governments. And many of these are products that are too large to replace every year (cars, refrigerators, ovens) but are being manufactured by companies for whom software -- and more importantly firmware updates -- aren't a particular forte or priority.

To date, there are a number of solutions being proposed to tackle this explosion in poorly-secured devices, none of which seem to really solve the issue. Agencies like Homeland Security have issued a number of toothless standards the companies that are making these poorly-secured products are free to ignore. And efforts at regulating the space, assuming regulators could even craft sensible regulations without hindering the emerging sector in the first place, can similarly be ignored by overseas manufacturers.

In the wake of the Wannacry ransomware, University of Pennsylvania researcher Sandy Clark has proposed something along these lines: firmware expiration dates. Clark argues that we've already figured out how to standardize our relationships with automobiles, with mandated regular inspection, maintenance and repairs governed by manufacturer recalls, DOT highway maintenance, and annual owner-obligated inspections. As such, she suggests similar requirements be imposed on internet-connected devices:

A requirement that all IoT software be upgradeable throughout the expected lifetime of the product. Many IoT devices on the market right now contain software (firmware) that cannot be patched even against known vulnerabilities.

A minimum time limit by which manufacturers must issue patches or software upgrades to fix known vulnerabilities.

A minimum time limit for users to install patches or upgrades, perhaps this could be facilitated by insurance providers (perhaps discounts for automated patching, and different price points for different levels of risk)."

Of course, none of this would be easy, especially when you consider this is a global problem that needs coordinated, cross-government solutions in an era where agreement on much of anything is cumbersome. And like previous suggestions, there's no guarantee that whoever crafted these requirements would do a particularly good job, that overseas companies would be consistently willing to comply, or that these mandated software upgrades would actually improve device security. And imagine being responsible for determining all of this for the 50 billion looming internet connected devices worldwide?

That's why many networking engineers aren't looking so much at the devices as they are at the networks they run on. Network operators say they can design more intelligent networks that can quickly spot, de-prioritize, or quarantine infected devices before they contribute to the next Wannacry or historically-massive DDoS attack. But again, none of this is going to be easy, and it's going to require multi-pronged, multi-country, ultra-flexible solutions. And while we take the time to hash out whatever solution we ultimately adopt, keep in mind that the 50 million IoT device count projected by 2020 -- is expected to balloon to 82 billion by 2025.

Filed Under: expiration dates, iot, patches, recalls, sandy clark, security, vulnerabilities

Samsung's 'Airtight' Iris Scanning Technology For The S8 Defeated With A Camera, Printer, And Contact Lens

from the a-new-theatre-for-security dept

The thing about biometric scanning as a security practice is it is one of those things that sounds great. "Lock your phone with your fingerprint or facial scan", shout the manufacturers and security companies that came up with the scans. Well, shit, thinks the average person, if nobody else has my face I'm in the clear. Even when movies and television tackle the subject, the methods for breaking the biometric security typically involve convoluted plans and insane stunts so brazen they would make Danny Ocean's jaw drop.

The problem is that the hype around this tech is typically more effective than the tech itself. Fingerprint scanners are easily fooled and facial recognition software has been shown to be defeatable by, and I swear this is true, printouts of a person's face. That isn't security, it's a punchline. So, when Samsung and its security partner decide to pimp the iris-scanning security feature of the Galaxy S8 with language like "airtight" and suggestions that owners of the phone can "finally trust that their phones are protected", one would expect those claims to be backed up by strong technology.

It isn't.

Hackers have broken the iris-based authentication in Samsung's Galaxy S8 smartphone in an easy-to-execute attack that's at odds with the manufacturer's claim that the mechanism is "one of the safest ways to keep your phone locked."

The cost of the hack is less than the $725 price for an unlocked Galaxy S8 phone, hackers with the Chaos Computer Club in Germany said Tuesday. All that was required was a digital camera, a laser printer (ironically, models made by Samsung provided the best results), and a contact lens. The hack required taking a picture of the subject's face, printing it on paper, superimposing the contact lens, and holding the image in front of the locked Galaxy S8. The photo need not be a close up, although using night-shot mode or removing the infrared filter helps. The hackers provided a video demonstration of the bypass.

As they did in the previous facial recognition flaw post referenced above, some will, at this point, be diving for their keyboards to point out that this type of security isn't really designed to make a device impermeable. Rather, it's to keep easy break-ins from occurring. And, hey, that's true! Good job, you guys! The problem here isn't that Samsung's security tech failed to be 100% effective. It's that it's barely effective, yet at the same time Samsung is pitching it as the end of phone break-ins. I'm not the one making wild claims here; they are.

And this tech is going to be rolled out in a big way, likely pitched to the public in the same manner.

"Iris recognition is the next big thing with mobile devices," Starbug wrote in an e-mail. "The technology, especially with the packed space and low computing power of mobile devices, is hard to make hack proof. You can't hide your iris, and it's even worse than fingerprints." At the same time, "mobile devices are holding more and more sensitive data."

Advertising this iris security as "airtight" is actively misleading the public on the security of a device becoming all the more important and one on which the public is more often storing sensitive information. For a company like Samsung to be so vociferous in its claims in light of this easy workaround ought to result in a ding to its credibility.

For biometrics generally, a good pin number is probably still your best bet. The tech may improve to the point of being the most effective option some day, but we're not there yet.

Filed Under: iris scan, privacy, s8, security
Companies: samsung

UK Government Using Manchester Attacks As An Excuse To Kill Encryption

from the say-what-now? dept

It's no secret that there are those in the current UK government who are just itching to kill encryption. Earlier this year, Home Secretary Amber Rudd made some profoundly ill-informed comments about how encryption on the internet was "completely unacceptable" and saying that they needed to stop companies from providing end-to-end encryption. And, in the recently leaked Tory Manifesto, it was made clear that the current government sees breaking encryption as a priority:

In addition, we do not believe that there should be a safe space for terrorists to be able to communicate online and will work to prevent them from having this capability.

As has been explained time and time again, the only way you prevent bad guys from having encryption is by preventing everyone from having effective encryption... and that makes everyone significantly less safe. Seriously, the only way to do this is to put dangerous vulnerabilities into encryption that will certainly be hacked fairly quickly. This doesn't make people safer. It makes them less safe.

But, of course, like so many politicians these days (of all major parties) it appears that the Conservative Party in the UK can't let a good tragedy go to waste. The Independent is reporting that, because of the attack in Manchester this week, the party is ramping up its plans to outlaw encrypted communications:

Government officials appear to have briefed newspapers that they will put many of the most invasive parts of the relatively new Investigatory Powers Act into effect after the bombing at Manchester Arena.

The specific powers being discussed – named Technical Capability Orders – require big technology and internet companies to break their own security so that messages can be read by intelligence agencies.

Again, in case you're just joining us, requiring that internet companies "break their own security so that messages can be read by intelligence agencies" is the nice way of saying "kill real encryption." It means that these companies will be deliberately forced to leave vulnerabilities in encryption that will be a goldmine for hackers of all kinds, from foreign surveillance to online criminals.

And, so far, there is zero evidence that the Manchester attack had anything to do with encryption. And, even if it did, so what? If the UK forced companies to break encryption, people planning terrorist attacks would just switch to other encryption products that don't have corporate entities in the UK. Or they'd come up with other ways to communicate. It will do basically nothing to stop terrorist attacks, but will instead make it much, much easier for all sorts of people with nefarious intent to hack into the private communications of everyone.

Filed Under: amber rudd, encryption, manchester, privacy, security, theresa may, uk

Personal Security Takes A Hit With Public Release Of NSA's Hacking Toolkit

from the national-security-still-healthy,-but-always-worth-panicking-over dept

Former members of Team Espionage recently expressed their concern that the Shadow Brokers' dump of NSA Windows exploits had done serious damage to the security of the nation. The unwanted exposure of NSA power tools supposedly harmed intelligence gathering efforts, even though the tools targeted outdated operating systems and network software.

However, there are still plenty of computers and networks online using outmoded software. This makes the released exploits a threat (especially those targeting XP users, as that version will never be patched). But not much of a threat to national security, despite the comments of anonymous former Intelligence Community members. It makes them a threat to personal security, as Chris Bing at CyberScoop points out:

One of these hacking tools, a backdoor implant codenamed DOUBLEPULSAR — which is used to run malicious code on an already compromised box — has already been installed on 30,000 to 50,000 hosts, according to Phobos Group founder Dan Tentler. Other researchers have also engineered different detection scripts to quickly scan the internet for infected computers.

John Matherly, the CEO of internet scanning-tool maker Shodan.io, said that upwards of 100,000 computers could be affected.

Rather surprisingly, data gathered by security researchers shows a majority of the infected computers are in the United States. This shows Microsoft's steady updating push still faces a sizable resistance right here at home. What it also shows is how fast exploits can be repurposed and redeployed once they're made public. The scans for DOUBLEPULSAR have turned up thousands of hits worldwide.

DOUBLEPULSAR is simply a backdoor, but an extremely handy one. Once installed, it makes targeted computers extremely receptive to further malware payloads.

“The presence of DOUBLEPULSAR doesn’t mean they’re infected by the NSA, it means there is a loading dock ready and waiting for whatever malware anyone wants to give it,” Tentler said. “The chances are none that all theses hosts [were hacked by] the NSA.

So, there's that small bit of comfort. It's not the NSA nosing around the innards of your Windows box, but a bunch of script kiddies playing with new toys… adding them to the normal rolls of malware purveyors seeking to zombify your device and/or make off with whatever information is needed to open fraudulent credit card accounts or whatever.

The NSA certainly could have informed Microsoft of these exploits before it ended support for certain platforms, thus ensuring late- (or never-) adopters were slightly more protected from malware merchants and state agencies. But that's the Vulnerabilities Equity Process for you: no forewarning until a third party threatens to turn your computing weapons over to the general public.

Filed Under: exploits, hacking tools, privacy, security, shadow brokers

Malware Hunts And Kills Poorly Secured Internet Of Things Devices Before They Can Be Integrated Into Botnets

from the battle-of-the-brick dept

Researchers say they've discovered a new wave of malware with one purpose: to disable poorly secured routers and internet of things devices before they can be compromised and integrated into botnets. We've often noted how internet-of-broken-things devices ("smart" doorbells, fridges, video cameras, etc.) have such flimsy security that they're often hacked and integrated into botnets in just a matter of seconds after being connected to the internet. These devices are then quickly integrated into botnets that have been responsible for some of the worst DDoS attacks we've ever seen (including last October's attack on DYN).

And most security researchers firmly believe we haven't seen anything yet.

Enter PDoS (permanent denial of service) attack bots, which scan the internet for routers with default, unchanged passwords, or "smart" doorbells, dolls or other devices with paper-mache grade security. From there, PDoS attack bots issue a series of commands that wipe device media, corrupt all storage, and disconnect the device from the internet. Last month, researchers from security firm Radware set up an intentionally poorly-secured honeypot that they say saw roughly 2,250 PDoS attempts during just a four-day span.

The lion's share of these attacks came from two botnets dubbed BrickerBot.1 and BrickerBot.2 -- with nodes busily bricking poorly-secured devices around the world. Initially researchers say they thought that somebody crafted malware specifically to tackle the IOT threat. But given the broad targeting of the botnets (including server-attached storage devices), they also think it's possible that the goal may just be good, old, vanilla mayhem:

"When I discovered the first BrickerBot, I thought it was a drastic attempt to stop the IoT Botnet DDoS threat," Radware researcher Pascal Geenens told Ars. "I thought this was a competitor hacker who wanted to take out his competition and get access to the list of IP [addresses] of bots that were in the competitor's botnet. But upon discovery of the second BrickerBot this theory changed, as the second one is targeting any Linux-based system—not only embedded, BusyBox-based Linux with flash storage. What motivates people to randomly destroy things? Anger, maybe? A troll, maybe?"

As it stands, BrickerBot.2 can only access machines that feature default administrative passwords and have the telnet protocol enabled, limiting the overall potential impact. Regardless, the end result still isn't pleasant for those on the receiving end of a BrickerBot.2 attack:

"...In addition to corrupting the storage device, BrickerBot.2 wipes all stored files, removes the default Internet gateway, disables TCP timestamps, and limits the maximum number of kernel threads to just one. That all but ensures that most damaged devices won't be restored without a major undertaking. Radware has more details about the attacks here."

It's still entirely possible the goal here is to actually help the internet by killing poorly-secured hardware before they can be conscripted into the shitshow that is the internet of things. After all, BrickerBot.2 appears to be an evolution of the Linux.Wifatch malware, which first appeared in October 2015. It seems more than likely that additional malware strains taking cues from the Mirai malware will inevitably appear in the wild, the goal potentially being not necessarily mayhem -- but preventing the massive, crippling DDoS attacks most security experts feel are inevitable in the next year or two.

The problem (aside from this being illegal and destructive) is that the type of person that's likely to go out and purchase a poorly-secured "gee whiz" IOT device or router without considering security -- is the same type of person that's not going to understand why that device just stopped working for no coherent reason. As a result, they're likely to rush out and buy another, poorly-secured device, bringing the incompetence full circle with a zero net gain. As such, Security expert Victor Gevers is urging malware authors like this to consider a more constructive path toward the same end goal:

"These attacks are very easy to execute, and I think this just the beginning," (Gevers) told Bleeping Computer. "I don't want to label this work as dark, but I think there are less destructive ways to achieve the same goal." "Instead of bricking you could also allow the devices to still work and just patch the vulnerability. This requires a bit more finesse."

Granted an even better solution? Stop selling (and buying) hardware with paper-mache grade security in the first place.

Filed Under: botnets, iot, malware, patching, security

Self Driving Taxis Are Going To Be A Nightmare To Secure, Warns Ex-Uber Security Researcher

from the I'm-sorry-I-can't-do-that,-Dave dept

So over the last few years you probably remember seeing white hat hackers demonstrate how easily most modern smart cars can be hacked, often with frightening results. Cybersecurity researchers Charlie Miller and Chris Valasek have made consistent headlines in particular by highlighting how they were able to manipulate and disable a Jeep Cherokee running Fiat Chrysler's UConnect platform. Initially, the duo documented how they were able to control the vehicle's internal systems -- or kill it's engine entirely -- from an IP address up to 10 miles away.

But the two would go on to highlight how things were notably worse, pointing out last year that they'd also found a way to kill the vehicle's brakes, cause unexpected acceleration, or even direct the vehicle to perform sudden and extreme turns:

"Last year, they remotely hacked into the car and paralyzed it on highway I-64—while I was driving in traffic. They could even disable the car’s brakes at low speeds. By sending carefully crafted messages on the vehicle’s internal network known as a CAN bus, they’re now able to pull off even more dangerous, unprecedented tricks like causing unintended acceleration and slamming on the car’s brakes or turning the vehicle’s steering wheel at any speed."

Just the gift for intelligence or private sector ne'er-do-wells looking to cause mayhem -- or worse.

After Miller and Valasek's hacks made consistent headlines, the two were quietly hired by Uber to help the company secure its self-driving taxi service. Miller has since moved on to Chinese competitor Didi, and tells Wired he's much more free to speak about the perils of securing automated cars and taxis. What he's saying isn't what you'd call comforting:

"Autonomous vehicles are at the apex of all the terrible things that can go wrong,” says Miller, who spent years on the NSA’s Tailored Access Operations team of elite hackers before stints at Twitter and Uber. “Cars are already insecure, and you’re adding a bunch of sensors and computers that are controlling them… If a bad guy gets control of that, it’s going to be even worse."

The problems that Miller highlighted with the Jeep Cherokee are significantly worse when you're talking about a taxi that sees significantly more use each day. A taxi that, under current federal law, won't be able to block consumer access to the vehicle's OBD2 port (something consumers want the freedom to tinker with in their own vehicle, but perhaps not so much in a communal car):

"There’s going to be someone you don’t necessarily trust sitting in your car for an extended period of time,” says Miller. “The OBD2 port is something that’s pretty easy for a passenger to plug something into and then hop out, and then they have access to your vehicle’s sensitive network."

Miller notes that securing an automated vehicle isn't impossible, but it's going to require the use of "codesigning," restrictions built into the OBD2 port, better internal segmentation and authentication -- and basically a complete retooling of how self-driving vehicle security is implemented. But Miller notes that companies like Uber are bolting their computer systems onto already built vehicles, which complicates things. And the slow pace of finding and patching security vulnerabilities in vehicles poses an additional layer of problems.

The solution will also involve greater "open conversation and cooperation" among carmakers and developers, something Miller says was lacking at Uber, and hasn't exactly been the trademark of other automated vehicle vendors.

Right now, we continue to find the lack of security in our smart fridges and TVs kind of cute. But it's threats like those being exposed by Miller that have some security researchers like Bruce Schneier consistently predicting some massive problems on the horizon that may result in notable human casualties. And we're not helping the problem by letting companies monopolize repair, or consistently erode our privacy rights or our freedom to tinker.

Filed Under: autonomous vehicles, security, self-driving cars

The Teddy Bear And Toaster Act Is Device Regulation Done Wrong

from the not-the-right-approach dept

Should government to protect us from snooping teddy bears and untrustworthy toasters? The California State Senate seems to think so.

With traditional devices on the decline, laptop and desktop computers now account for less than 25 percent of internet network traffic. Indeed, American households now use, on average, seven connected devices every day. As this so-called “internet of things” continues to expand, an array of connected objects—from toasters to lightbulbs to dishwashers—now include embedded microprocessors, multiplying the number of potential threat vectors for data breaches and cyberattacks.

Notably, security researchers revealed recently that CloudPets, a company that sells connected stuffed animal toys with voice-recording capabilities, had a security vulnerability that leaked the information of more than 500,000 people. In response to accounts like these and concerns about data collection by internet-of-things devices, California is considering S.B. 327, legislation that would require certain security and privacy features for any connected devices sold in the Golden State.

Device insecurity is a real threat and it's encouraging to see legislators thinking about consumer privacy and security. But this bill, facetiously called the “teddy bear and toaster act” by its critics, would create more problems than it solves. These concerns do not merit a heavy-handed and wide-reaching legislative response.

First introduced in February, the bill targets a broad range of products that include “any device, sensor, or other physical object that is capable of connecting to the internet, directly or indirectly, or to another connected device.” It would require that their manufacturers “equip the device with reasonable security features.”

The scope and scale of that definition would appear to cover everything from smartphones to cars to tweet-happy toasters. Sweeping such a broad range of connected devices under its rules ignores that all of these items have unique functions, capabilities, and vulnerabilities. What constitutes a “reasonable security feature” for one might be completely unreasonable for another. This one-size-fits-all regulatory approach threatens to chill innovation, as companies from a host of different sectors expend resources just to make sense of the rules.

Should the bill move forward, we should also expect a range of consumer items will be equipped to blink and buzz and beep in ways more annoying than informative. The bill decrees that: “a manufacturer that sells or offers to sell a connected device in this state shall design the device to indicate through visual, auditory, or other means when it is collecting information.”

For some types of devices—such as virtual and augmented reality systems and autonomous vehicles—this requirement is simply infeasible. These devices use sensors to collect data constantly in order to perform their core functions. For always-on devices like IP security cameras, Amazon Alexa or connected cars, an indicator would just be synonymous with an “on” button. Many of these indicators will be superfluous, misunderstood and costly to implement—costs that disproportionately would hit smaller businesses.

Other provisions of the bill urge sellers of connected devices to notify consumers at checkout where they can find the item's privacy policy and information about security patches and updates. This is valuable information, but the point-of-sale may not be the best time to communicate it. For many devices, a verbal or web-based tutorial likely would be more effective. Companies need the flexibility to figure out the best ways to inform their customers, while these design requirements would remove that flexibility.

In an interconnected world, balancing privacy rights and security is a hugely difficult undertaking. Enshrining that balance in law requires a nuanced and targeted approach. Policymakers at both the state and federal levels should focus their efforts on provable privacy or security harms, while empowering consumers with baseline information, where appropriate. Applying design requirements and compliance tasks in a haphazard way, as S.B. 327 does, will harm innovation without meaningfully improving data security.

Anne Hobson is technology policy fellow with the R Street Institute.

Filed Under: california, iot, mandates, security, teddy bear, toaster