From Press Backspace 28 times to own unlucky Grub-by Linux boxes:

A pair of researchers from the University of Valencia’s Cybersecurity research group have found that if you press backspace 28 times, it’s possible to bypass authentication during boot-up on some Linux machines.

The problem’s not a kernel nor an operating system problem, but rather one in the very popular bootloader Grub2, which is used to boot an awful lot of flavours of Linux.

Essentially, if you enable Grub2’s password protection during system startup, it won’t do you much good – it can be easily defeated. (Luckily, the vast majority of distributions of Linux do not enable this by default.)

I don’t want to say this is a non-issue, because it’s not. That said, it helps to have some perspective on the impact of a potential vulnerability so you know what you should do about it at what priority.

When I worked in the TAC back when I was at Nokia, I was the guy who would decipher the latest “OMG, my scanner found your firewalls are vulnerable to this new CVE, fix it.” This meant reading the actual CVE to figure out if this could lead to remote code execution, cross-site scripting, or similar.

Because of how Nokia IPSO was hardened, many of the vulnerabilities had no particular impact, either because the vulnerable component wasn’t there or it was configured in a more secure configuration than the default.

Or, better yet, in order to leverage the exploit, you had to have a specific kind of access to the machine (say, shell access) that could lead to far more dangerous things than the vulnerability in question.

This Grub bug is one of those things. First of all, this bug only shows up in a non-default configuration and requires physical access to boot. Ok, so maybe also a serial console might work, too. Either way, this limits the potential scope of a potential attack. Furthermore, if you actually have physical access, unless you’ve performed some sort of drive encryption, that physical access could be leveraged to, say, steal or clone the drive. Which is a far more serious threat.

In the grand scheme of things, this bug would not be a huge priority to deploy a patch for in all cases. Unlike, say, the backdoor in Juniper/Netscreen gear which can be remotely exploited.

Bridging The Information Security Gap

You may have noticed a marked increase in the amount of posts I’ve done to this blog lately. Or maybe you haven’t because I’m just one of many people in your Twitter, RSS, LinkedIn, Medium, or however you read and/or ignore my stuff.

Whether you read these ports or not, all these new posts aren’t necessarily an accident. There is a underlying motivation driving me to put thoughts around Information Security to digital bits once again.

What is it? A sense of purpose that, quite honestly, I haven’t felt in a while. About the Information Security industry. About where I see things happening and some things we need to do to affect positive change, creating a more “secure by default” environment for everyone and everything.

Do I think it will happen overnight? No. Do I have all the answers about how to get there? No. That said, 20 years in this industry has given me some ideas about what works and what doesn’t.

What I do know is that the bottom-up approach that many are taking to affect change isn’t working that well. By that, I mean that initiatives for Information Security are usually not coming from the people in charge, but rather the IT (Security) personnel who, innately, understand something needs to be done, but they can’t explain it to the people who write the checks in a way that will get the necessary funding required to affect change.

Sometimes, security initiatives are actually driven from above as well. Frequently, it comes after a major incident that makes the news. I bet Information Security suddenly became a lot more important at the various retailers that had millions of PCI and/or PII data records stolen. However, there’s no evidence those efforts have resulted in improved security or that other, similar organizations have started taking the necessary actions to improve their information security practices before they are the next target.

There’s a lot of platitudes and sound bytes out there about how organizations can be more secure. There’s a lot of noise from vendors in the space about their solutions and how, if you buy and deploy their stuff, they will keep you secure (and those other vendors who have competing products won’t).

This problem, and the solutions, are far more nuanced than any sound byte can capture or any single product suite can solve. It’s about bridging the gap between the technical information security people who know what’s going on and the people making the strategic decisions and writing the checks.

This is the kernel of the idea I have. The details of how to do this need a bit more refinement. When I put these ideas out there, I expect the Internet to tell me how wrong I am:

I’m not afraid of that. In fact, I welcome it. One lesson I learned from maintaining the old FireWall-1 FAQ was that when I put wrong information out there (not intentionally, of course), someone will tell me and give me the right information. Then I can share that information with others, as I’ve done for 20 years.

When the time comes, I would like to share these ideas with a much wider audience than my old FireWall-1 FAQ was able to reach. If you have any suggestions or feedback, I’d love to hear your thoughts.

Cybersecurity: Protection From an Existential Threat

From Cybercrime poses a potential existential threat to our society, and we’re completely unprepared:

Connecting our cars and pacemakers and planes and power grids to computers gives us access to computing power that was unimaginable decades ago.

But it also means that we have security threats that were unimaginable decades ago, which Goodman says is a potential existential threat to society, the sort of thing that needs to be a national priority as big as the space race or the Manhattan project.

The premise of this article is that the lack of cybersecurity around critical infrastructure and the increased prevalence of cybercrime poses an existential threat to society. Existential meaning “of or relating to existence.”

It’s a pretty bold statement. It’s also, based on the cross-section of companies and security experts I’ve talked to, a very real possibility.

Where I disagree with the article is the fact that we need some sort of Manhattan Project-type effort to solve the problem. As if developing a single nuclear-type weapon will be enough to prevent all cybercrime.

Those of us who’ve been in the industry for a couple of decades already know how to significantly reduce the risks. It doesn’t even require new technology, though some organizations will undoubtedly need to acquire some.

The one thing that it will surely require from all organizations and all persons is applied effort. And sadly, the only way I see the majority committing to that is for a nuclear-type event to occur. Only, it will be much more harmful than Trinity was.

The Security Impediment

From Chip Cards Take So Long, Some Retailers Disabled Them For The Holidays:

It could be that, among other things, retailers are reacting to shoppers’ sentiments. One in five consumers names transaction time as their biggest concern when using an EMV-enabled credit or debit card, according to a recent survey by point-of-sale firm Harbortouch.

It takes about seven to 10 seconds to process a chip card at the register versus two to three seconds to process a swipe. “While seemingly small, during busy times like the holidays, these increased processing times could add up quickly,” Jared Isaacman, founder and CEO of HarborTouch, said in the press release.

This is not a hypothetical problem that’s pointed out here. In a super-busy store, slowing down the entire point-of-sale system for added security can mean less customers go through the checkout, meaning the retailers make less money.

The problem is even more acute in stock trading. Delays of even a fraction of a second in receiving a trade order can cost serious money.

Organizations of all kinds often make a tradeoff between transaction speed and ensuring that transaction is authorized and legitimate. They usually err on the side of speed versus secure.

There is no right or wrong answer, because part of security is accepting risk for specific behavior that is less secure. This can happen because:

  • The cost to mitigate the risk is too high
  • The cost of failure of a mitigating security control is exceptionally high
  • The likelihood of occurence of the relevant events are very low

Security measures are often viewed–rightfully so, in some cases–as impeding business. Of course, they also enable business as well. I doubt e-Commerce would have flourished the way it did had Netscape not invented Secure Sockets Layer.

Those of us in the security industry need to ensure the solutions we are offering are not impeding business while providing a high level of security and reliability. That way, organizations won’t have to accept as much risk as they do today.

Palo Alto Networks Is Evading The Truth

Here’s a summary from A Letter to Palo Alto Networks Employees and Customers:

  • Vulnerabilities in several intrusion detection products were reported by The SANS Institute 3 years ago in a white paper called Beating the IPS, including those sold by Palo Alto Networks.
  • A few weeks ago, NetSecVulns published a video showing Palo Alto Networks gateways are still susceptible to these flaws. (Note: This video is now private)
  • Rather than acknowledge the issue, Palo Alto Networks had their representatives send out emails to their customers claiming Check Point was cheating and misleading about the issue.
  • After providing a test bed demonstrating the vulnerability in action to Palo Alto Networks, a representative finally acknowledged the issue and promised to develop a fix.
  • Claims from Palo Alto Networks representatives that Check Point is cheating and misleading about the issue continue, despite receiving concrete proof to the contrary.

The issue is a little more nuanced than this of course, so I recommend reading the piece by Moti Sagey on LinkedIn. That said, I have a couple questions of my own:

  1. Previously unknown long-time vulnerabilities such as those recently discovered in some of Juniper’s legacy products are one thing. How can a company sit on widely reported security issues for three years and not do anything to fix them or even publicly acknowledge them? We can argue about the length of time that is acceptable per responsible disclosure guidelines, or whether the issue was responsibly disclosed in this case. I’ve yet to find any information security professional who thinks three years is reasonable, particularly when the issues are this widely known.
  2. How can a company require so many manual steps to configure their security gateways to be resilient against evasions? Imagine having to perform these steps on firewalls across your enterprise, not to mention tracking continued compliance with these best practices.
  3. If this hasn’t been an issue all along, how come there is no public statement from Palo Alto Networks like there was for the Firestorm issue? Which is, by the way, still a potential issue, but PAN at least responded saying they don’t believe it is.
  4. If you received—or worse, had to deliver—the communication from Palo Alto Networks about this Evader issue that has been proven false, how does that make you feel about Palo Alto Networks as an organization?

Disclaimer: I don’t know what Check Point’s formal stance on this issue is, I didn’t ask. These are my own thoughts.