SSL and internet security news

cybersecurity

Auto Added by WPeMatico

iOS XML Bug

This is a good explanation of an iOS bug that allowed someone to break out of the application sandbox. A summary:

What a crazy bug, and Siguza’s explanation is very cogent. Basically, it comes down to this:

  • XML is terrible.
  • iOS uses XML for Plists, and Plists are used everywhere in iOS (and MacOS).
  • iOS’s sandboxing system depends upon three different XML parsers, which interpret slightly invalid XML input in slightly different ways.

So Siguza’s exploit ­– which granted an app full access to the entire file system, and more ­- uses malformed XML comments constructed in a way that one of iOS’s XML parsers sees its declaration of entitlements one way, and another XML parser sees it another way. The XML parser used to check whether an application should be allowed to launch doesn’t see the fishy entitlements because it thinks they’re inside a comment. The XML parser used to determine whether an already running application has permission to do things that require entitlements sees the fishy entitlements and grants permission.

This is fixed in the new iOS release, 13.5 beta 3.

Comment:

Implementing 4 different parsers is just asking for trouble, and the “fix” is of the crappiest sort, bolting on more crap to check they’re doing the right thing in this single case. None of this is encouraging.

More commentary. Hacker News thread.

Powered by WPeMatico

Vulnerability Finding Using Machine Learning

Microsoft is training a machine-learning system to find software bugs:

At Microsoft, 47,000 developers generate nearly 30 thousand bugs a month. These items get stored across over 100 AzureDevOps and GitHub repositories. To better label and prioritize bugs at that scale, we couldn’t just apply more people to the problem. However, large volumes of semi-curated data are perfect for machine learning. Since 2001 Microsoft has collected 13 million work items and bugs. We used that data to develop a process and machine learning model that correctly distinguishes between security and non-security bugs 99 percent of the time and accurately identifies the critical, high priority security bugs, 97 percent of the time.

News article.

I wrote about this in 2018:

The problem of finding software vulnerabilities seems well-suited for ML systems. Going through code line by line is just the sort of tedious problem that computers excel at, if we can only teach them what a vulnerability looks like. There are challenges with that, of course, but there is already a healthy amount of academic literature on the topic — and research is continuing. There’s every reason to expect ML systems to get better at this as time goes on, and some reason to expect them to eventually become very good at it.

Finding vulnerabilities can benefit both attackers and defenders, but it’s not a fair fight. When an attacker’s ML system finds a vulnerability in software, the attacker can use it to compromise systems. When a defender’s ML system finds the same vulnerability, he or she can try to patch the system or program network defenses to watch for and block code that tries to exploit it.

But when the same system is in the hands of a software developer who uses it to find the vulnerability before the software is ever released, the developer fixes it so it can never be used in the first place. The ML system will probably be part of his or her software design tools and will automatically find and fix vulnerabilities while the code is still in development.

Fast-forward a decade or so into the future. We might say to each other, “Remember those years when software vulnerabilities were a thing, before ML vulnerability finders were built into every compiler and fixed them before the software was ever released? Wow, those were crazy years.” Not only is this future possible, but I would bet on it.

Getting from here to there will be a dangerous ride, though. Those vulnerability finders will first be unleashed on existing software, giving attackers hundreds if not thousands of vulnerabilities to exploit in real-world attacks. Sure, defenders can use the same systems, but many of today’s Internet of Things (IoT) systems have no engineering teams to write patches and no ability to download and install patches. The result will be hundreds of vulnerabilities that attackers can find and use.

Powered by WPeMatico

The DoD Isn’t Fixing Its Security Problems

It has produced several reports outlining what’s wrong and what needs to be fixed. It’s not fixing them:

GAO looked at three DoD-designed initiatives to see whether the Pentagon is following through on its own goals. In a majority of cases, DoD has not completed the cybersecurity training and awareness tasks it set out to. The status of various efforts is simply unknown because no one has tracked their progress. While an assessment of “cybersecurity hygiene” like this doesn’t directly analyze a network’s hardware and software vulnerabilities, it does underscore the need for people who use digital systems to interact with them in secure ways. Especially when those people work on national defense.

[…]

The report focuses on three ongoing DoD cybersecurity hygiene initiatives. The 2015 Cybersecurity Culture and Compliance Initiative outlined 11 education-related goals for 2016; the GAO found that the Pentagon completed only four of them. Similarly, the 2015 Cyber Discipline plan outlined 17 goals related to detecting and eliminating preventable vulnerabilities from DoD’s networks by the end of 2018. GAO found that DoD has met only six of those. Four are still pending, and the status of the seven others is unknown, because no one at DoD has kept track of the progress.

GAO repeatedly identified lack of status updates and accountability as core issues within DoD’s cybersecurity awareness and education efforts. It was unclear in many cases who had completed which training modules. There were even DoD departments lacking information on which users should have their network access revoked for failure to complete trainings.

The report.

Powered by WPeMatico

Cybersecurity During COVID-19

Three weeks ago (could it possibly be that long already?), I wrote about the increased risks of working remotely during the COVID-19 pandemic.

One, employees are working from their home networks and sometimes from their home computers. These systems are more likely to be out of date, unpatched, and unprotected. They are more vulnerable to attack simply because they are less secure.

Two, sensitive organizational data will likely migrate outside of the network. Employees working from home are going to save data on their own computers, where they aren’t protected by the organization’s security systems. This makes the data more likely to be hacked and stolen.

Three, employees are more likely to access their organizational networks insecurely. If the organization is lucky, they will have already set up a VPN for remote access. If not, they’re either trying to get one quickly or not bothering at all. Handing people VPN software to install and use with zero training is a recipe for security mistakes, but not using a VPN is even worse.

Four, employees are being asked to use new and unfamiliar tools like Zoom to replace face-to-face meetings. Again, these hastily set-up systems are likely to be insecure.

Five, the general chaos of “doing things differently” is an opening for attack. Tricks like business email compromise, where an employee gets a fake email from a senior executive asking him to transfer money to some account, will be more successful when the employee can’t walk down the hall to confirm the email’s validity — and when everyone is distracted and so many other things are being done differently.

NASA is reporting an increase in cyberattacks. From an agency memo:

A new wave of cyber-attacks is targeting Federal Agency Personnel, required to telework from home, during the Novel Coronavirus (COVID-19) outbreak. During the past few weeks, NASA’s Security Operations Center (SOC) mitigation tools have prevented success of these attempts. Here are some examples of what’s been observed in the past few days:

  • Doubling of email phishing attempts
  • Exponential increase in malware attacks on NASA systems
  • Double the number of mitigation-blocking of NASA systems trying to access malicious sites (often unknowingly) due to users accessing the Internet

Here’s another article that makes basically the same points I did:

But the rapid shift to remote working will inevitably create or exacerbate gaps in security. Employees using unfamiliar software will get settings wrong and leave themselves open to breaches. Staff forced to use their own ageing laptops from home will find their data to be less secure than those using modern equipment.

That’s a big problem because the security issues are not going away. For the last couple of months coronavirus-themed malware and phishing scams have been on the rise. Business email compromise scams — where crooks impersonate a CEO or other senior staff member and then try to trick workers into sending money to their accounts — could be made easier if staff primarily rely on email to communicate while at home.

Powered by WPeMatico

Internet Voting in Puerto Rico

Puerto Rico is considered allowing for Internet voting. I have joined a group of security experts in a letter opposing the bill.

Cybersecurity experts agree that under current technology, no practically proven method exists to securely, verifiably, or privately return voted materials over the internet. That means that votes could be manipulated or deleted on the voter’s computer without the voter’s knowledge, local elections officials cannot verify that the voter’s ballot reflects the voter’s intent, and the voter’s selections could be traceable back to the individual voter. Such a system could violate protections guaranteeing a secret ballot, as outlined in Section 2, Article II of the Puerto Rico Constitution.

The ACLU agrees.

Powered by WPeMatico

CIA Dirty Laundry Aired

Joshua Schulte, the CIA employee standing trial for leaking the Wikileaks Vault 7 CIA hacking tools, maintains his innocence. And during the trial, a lot of shoddy security and sysadmin practices are coming out:

All this raises a question, though: just how bad is the CIA’s security that it wasn’t able to keep Schulte out, even accounting for the fact that he is a hacking and computer specialist? And the answer is: absolutely terrible.

The password for the Confluence virtual machine that held all the hacking tools that were stolen and leaked? That’ll be 123ABCdef. And the root login for the main DevLAN server? mysweetsummer.

It actually gets worse than that. Those passwords were shared by the entire team and posted on the group’s intranet. IRC chats published during the trial even revealed team members talking about how terrible their infosec practices were, and joked that CIA internal security would go nuts if they knew. Their justification? The intranet was restricted to members of the Operational Support Branch (OSB): the elite programming unit that makes the CIA’s hacking tools.

The jury returned no verdict on the serous charges. He was convicted of contempt and lying to the FBI; a mistrial on everything else.

Powered by WPeMatico