Author Archives: Robert Hansen

About Robert Hansen

Robert Hansen is the Vice President of WhiteHat Labs at WhiteHat Security. He's the former Chief Executive of SecTheory and Falling Rock Networks which focused on building a hardened OS. Mr. Hansen began his career in banner click fraud detection at ValueClick. Mr. Hansen has worked for Cable & Wireless doing managed security services, and eBay as a Sr. Global Product Manager of Trust and Safety. Mr. Hansen contributes to and sits on the board of several startup companies. Mr. Hansen has co-authored "XSS Exploits" by Syngress publishing and wrote the eBook, "Detecting Malice." Robert is a member of WASC, APWG, IACSP, ISSA, APWG and contributed to several OWASP projects, including originating the XSS Cheat Sheet. He is also a mentor at TechStars. His passion is breaking web technologies to make them better. Robert can be found on Twitter @RSnake.

The Parabola of Reported WebAppSec Vulnerabilities

The nice folks over at Risk Based Security’s VulnDB gave me access to take a look at their extensive collection of vulnerabilities that they have collected over the years. As you can probably imagine, I was primarily interested in their remotely exploitable web application issues.

Looking at the data, the immediate thing I notice is the nice upward trend as the web began to really take off, and then the real birth of web application vulnerabilities in the mid 2000’s. However, one thing I found that struck me as very odd was that we’re starting to see a downward trend in web application vulnerabilities since 2008.

  • 2014 – 1607 [as of August 27th]
  • 2013 – 2106
  • 2012 – 2965
  • 2011 – 2427
  • 2010 – 2554
  • 2009 – 3101
  • 2008 – 4615
  • 2007 – 3212
  • 2006 – 4167
  • 2005 – 2095
  • 2004 – 1152
  • 2003 – 631
  • 2002 – 563
  • 2001 – 242
  • 2000 – 208
  • 1999 – 91
  • 1998 – 25
  • 1997 – 21
  • 1996 – 7
  • 1995 – 11
  • 1994 – 8

Assuming we aren’t seeing a downward trend in total compromises (which I don’t think we are) here are the reasons I think this could be happening:

  1. Code quality is increasing: It could be that we saw a huge increase in code quality over the last few years. This could be coming from compliance initiatives, better reporting of vulnerabilities, better training, source code scanning, manual code review, or any number of other places.
  2. A more homogenous Internet: It could be that people are using fewer and fewer new pieces of code. As code matures, people who use it are less likely to switch in favor of something new, which means there are fewer threats to the incumbent code to be replaced, and it’s therefore more likely that new frameworks won’t get adopted. Software like WordPress, Joomla, or Drupal will likely take over more and more consumer publishing needs moving forward. All of the major Content Management Systems (CMS) have been heavily tested, and most have developed formal security response teams to address vulnerabilities. Even as they get tested more in the future, such platforms are likely a much safer alternative than anything else, therefore obviating the need for new players.
  3. Attacks may be moving towards custom web applications: We may be seeing a change in attacker tactics, where they are focusing on custom web application code (e.g. your local bank, Paypal, Facebook), rather than open source code used by many websites. That means they wouldn’t be reported in data like this, as vulnerability databases do not track site-specific vulnerabilities. The sites that do track such incidents are very incomplete for a variety of reasons.
  4. People are disclosing fewer vulns: This is always a possibility when the ecosystem evolves far enough where reporting vulnerabilities is more annoying to researchers, provides them fewer benefits, and ultimately makes their life more difficult than working with the vendors directly or holding onto their vulnerabilities. The presence of more bug bounties, where researchers get paid for disclosing their newly found vulnerability directly to the vendor, is one example of an influence that may affect such statistics.

Whatever the case, this is is an interesting trend and should be watched carefully. It could be a hybrid of a number of these issues as well, and we may never know for sure. But we should be aware of the data, because in it might hide some clues on how to further decrease the numbers. Another tidbit that is not expressed in the data above shows that there were 11,094 vulnerabilities disclosed in 2013, of which 6,122 were “web related” (meaning web application or web browser). While only 2,106 may be remotely exploitable (meaning it involves a remote attacker and there is published exploit code) context-dependent attacks (e.g. tricking a user to click a malicious link) are still a leading source of compromise at least amongst targeted attacks. While vulnerability disclosure trends may be going down, organizational compromises appear to be just as common or even more so than they have ever been. Said another way, compromises are flat or even up, and new remotely exploitable web application vulnerabilities being disclosed is down. Very interesting.

Thanks again to the Cyber Risk Analytics VulnDB guys for letting me play with their data.

#HackerKast 13 Bonus Round: FlashFlood – JavaScript DoS

In this week’s HackerKast bonus footage, I wrote a little prototype demonstrator script that shows various concepts regarding JavaScript flooding. I’ve run into the problem before where people seem to not understand how this works, or even that it’s possible to do this, despite multiple attempts at trying to explain it over the years. So, it’s demo time! This is not at all designed to take down a website by itself, though it could add extra strain on the system.

What you might find though, is that heavy database driven sites will start to falter if they rely on caching to protect themselves. Specifically Drupal sites tend to be fairly prone to this issue because of how Drupal is constructed, as an example.

It works by sending tons of HTTP requests using different paramater value pairs each time, to bypass caching servers like Varnish. Ultimately it’s not a good idea to ever use this kind of code as an adversary because it would be flooding from their own IP address. So instead this is much more likely to be used by an adversary who tricks a large swath of people into executing the code. And as Matt points out in the video, it’s probably going to end up in XSS code at some point.

Anyway, check out the code here. Thoughts are welcome, but hopefully this makes some of the concepts a lot more clear than our previous attempts.

Infancy of Code Vulnerabilities

I was reading something about modern browser behavior and it occurred to me that I hadn’t once looked at Matt’s Script Archive from the mid 1990s until now. I kind of like looking at old projects through the modern lens of hacking knowledge. What if we applied some of the modern day knowledge about web application security against 20-year-old tech? So I took at look at the web-board. According to Google there are still thousands of installs of WWWBoard lying around the web:

http://www.scriptarchive.com/download.cgi?s=wwwboard&c=txt&f=wwwboard.pl

I was a little disappointed to see the following bit of text. It appears someone had beat me to the punch – 18 years ago!

# Changes based in part on information contained in BugTraq archives
# message 'WWWBoard Vulnerability' posted by Samuel Sparling Nov-09-1998.
# Also requires that each followup number is in fact a number, to
# prevent message clobbering.

In taking a quick look there have been a number of vulns found in it over the years. Four CVEs in all. But I decided to take a look at the code anyway. Who knows – perhaps some vulnerabilities have been found but others haven’t. After all, this has been nearly 12 years since the last CVE was announced.

Sure enough its actually got some really vulnerable tidbits in it:

# Remove any NULL characters, Server Side Includes
$value =~ s/\0//g;
$value =~ s/<!--(.|\n)*-->//g;

The null removal is good, because there’s all kinds of ways to sneak things by Perl regex if you allow nulls. But that second string makes me shudder a bit. This code intentionally blocks typical SSI like:

<!--#exec cmd="ls -al" -->

But what if we break up the code? We’ve done this before for other things – like XSS where filters prevented parts of the exploit so you had to break it up into two chunks to be executed together once the page is re-assembled. But we’ve never (to my knowledge) talked about doing that for SSI! What if we slice it up into it’s required components where:

Subject is: <!--#exec cmd="ls -al" echo='
Body is: ' -->

That would effectively run SSI code. Full command execution! Thankfully SSI is all but dead these days not to mention Matt’s project is on it’s deathbed, so the real risk is negligible. Now let’s look a little lower:

$value =~ s/<([^>]|\n)*>//g;

This attempts to block any XSS. Ironically it should also block SSI, but let’s not get into the specifics here too much. It suffers from a similar issue.

Body is: <img src="" onerror='alert("XSS");'

Unlike SSI I don’t have to worry about there being a closing comment tag – end angle brackets are a dime a dozen on any HTML page, which means that no matter what this persistent XSS will fire on the page in question. While not as good as full command execution, it does work on modern browser more reliably than SSI does on websites.

As I kept looking I found all kinds of other issues that would lead the board to get spammed like crazy, and in practice when I went hunting for the board on the Internet all I could find were either heavily modified boards that were password protected, or broken boards. That’s probably the only reason those thousands of boards aren’t fully compromised.

It’s an interesting reminder of exactly where we have come from and why things are so broken. We’ve inherited a lot of code, and even I still have snippets of Matt’s code buried in places all over the web in long forgotten but still functional code. We’ve inherited a lot of vulnerabilities and our knowledge has substantially increased. It’s really fascinating to see how bad things really were though, and how little security there really was when the web was in it’s infancy.

#HackerKast 11 Bonus Round: The Latest with Clickjacking!

This week Jeremiah said it was my turn to do a little demo for our bonus video. So I went back and I decided to take a look at how Adobe had handled clickjacking in various browsers. My understanding was that they had done two things to prevent users from getting access to the camera and microphone. The first was that they wouldn’t allow you to make it a 1×1 pixel iframe that otherwise hid the permissions dialog.

My second understanding was that they prevented the browser from changing the opacity of the flash movie or surrounding iframe so that the dialog wasn’t obscured from view. So I decided to try it out!

It turns out that hiding it from view using opacity is still allowed in Chrome. Chrome has chosen to use a permissions dialog to prevent the user from being duped, that comes down from the ribbon. That is a fairly good defense. I would even argue that there is nothing exploitable here. But just because something isn’t exploitable doesn’t mean it’s clear to the user what’s going on so I decided to take a look at how I would social engineer someone into giving me access to their camera and microphone.

So I created a small script that pops open the victim domain (say https://www.google.com/) so that the user can look at the URL bar and see that they are indeed on the correct domain. Popups have long been banned but only automatic ones, the ones that are user initiated are still allowed and “pop” up into an adjacent tab. Because I still have a reference to the popup window from the parent I can can easily send it somewhere else, other than Google after some time elapses.

At this point I send it to a data: URL structure, that allows me to inject data onto the page. Using a little trick to make the browser look an awful lot like they’re still on Google makes this trick super useful for phishing and other social engineering attacks, but not necessarily a vuln either. This basically claims that the charset is “https://www.google.com/” followed by a bunch of spaces, instead of “utf8″ or whatever it would normally be. That makes it look an awful lot like you’re still on Google’s site, but you are in fact seeing content from ha.ckers.org. So yeah, imagine that being a login page instead of a clickjacking page and you’ve got a good idea how an attacker would be most likely to use it.

At that point the user is presented with a semi-opaque Flash movie and asked to click twice (once to instantiate the plugin and once to allow permissions). Typically if I were really doing this I would host it on a domain like “gcams.com” or “g-camz.com” or whatever so that the dialog would look like it’s trying to include content from a related domain.

The user is far more likely to allow Google to have access to the user’s camera and microphone than ha.ckers.org, of course, and this problem is exacerbated by the fact that people are accustomed to sites including tons of other domains and sub-domains of other companies and subsidiaries. In Google’s case, googleusercontent.com, gstatic.com etc… are all such places that people have come to recognize and trust as being part of Google, but the same is true with lots of domains out there.

Anyway, yes, this is probably not a vuln, and after talking with Adobe and Chrome they agree, so don’t expect any sort of fixes from what I can gather. This is just how it works. If you want to check it out you can click here with Chrome to try the demo. I hope you enjoyed the bonus video!

Resources:
Wikipedia: Clickjacking

Anonymity or Accountability?

Over a decade ago, when I was just starting in the computer security scene, I went to a conference for managed security services providers as the sole representative for my company. Near the end of the day-long conference there was a large discussion in which people were asked, “If you could change one thing with a magic wand to have the biggest impact on security, what would it be?”

When it finally got to me, I said the only thing that came to mind, “Attribution.” I explained, “If I had a magic wand and could change anything to have the largest impact on security, I’d make it so that everything on the Internet could be attributed to people so that we could have accountability. If you knew the packet you sent would be tagged with the information necessary for someone to track you down, you’d be extremely unlikely to commit any crimes using the Internet.”

I know it’s impossible to do that, but it was a magic wand after all. But that’s not the end of the story. Over the years I have become a privacy “guy” insomuch as I take people’s privacy seriously. However, I also have one foot squarely in the world of banking, finance, retail and so on – where attribution is hugely important for security, and also as an unintended consequence *ahem* marketing. So as much as I’d love to have people live in a free and open society, we all know what a bunch of jerks people can be when they know there’s nothing at risk when they break the law.

On the flip side, 100% attribution is terrible for privacy when you’re not doing anything illegal, or if you are a political dissident. The very last thing our forefathers wanted when they were talking amongst themselves in pubs on the East coast, considering creating a new nation, was attribution. They saw fit to write amendments to the constitution to limit unlawful search and seizures, and to allow freedom of speech.

So on one hand you have freedom and on the other hand you have safety. I have taken to asking people: “If you had to chose only one, which would it be? Accountability or Anonymity? Do you ever want there to be a way for you to do something anonymously or not? Do you ever want to be at risk of not finding someone who had committed a crime or not?”

I am somewhat surprised to find that when given only the choice between one or the other, it has been nearly an even split amongst people I talk to – usually at conference – about which they’d prefer. Right now, we teeter on the brink of having no anonymity at all. With enough vulnerabilities that allow full compromises of millions of machines, and enough listening posts all over the world, anonymity is slowly but surely getting harder and harder to get. Look at the most recent busts of various Tor hidden services like Silk Road 2 – people whose livelihoods and freedom depend on privacy still can’t manage it.

Most people would say that drug dealers and arms dealers deserve to be behind bars, so good riddance, regardless of how it happened. However, what about Colorado? Last year, being in possession of marijuana would land you in jail. This year it won’t. So are we as a society willing to indiscriminately put people in jail for breaking the law, even when the law later turns out to be unjust and/or bad for society?

Or worse yet, what if our government moves into a second age of McCarthyism – where they hunt down those who engage in civil disobedience with untold masses of siphoned information to decide whom to jail and whom to leave alone? What if adultery suddenly became a felony? Thought crimes could be punishable in such a dystopian world — not a pretty sight either. Though your banking passwords would be safe, certainly. (Except from the government.)

Perhaps releasing certain types of criminals or forgiving certain types of crimes, as California is about to do, might be a worthwhile exercise. A certain level of crime, while seemingly bad, is critical to allowing for a free society. It’s a complex issue, and of course there is always a middle-ground, but I think to properly understand the middle ground you have to explore the edges. What would a perfectly accountable Internet bring? It would bring with it a near zero cyber-crime rate but also limited freedoms. What would a perfectly anonymous Internet bring? It would bring unfettered cyber-crime but unlimited freedoms. It feels like you’d want some sort of middle ground, but there’s no such thing as “somewhat anonymous” when your life depends on it.

While my younger self would have said that “attribution” was the key to security, I would now tell my younger self to look beyond security, and really contemplate what a completely secure society would look like. Maybe a completely secure society with attribution for every act isn’t such a great idea after all, I would warn him. There are probably no easy answers, but it’s a conversation that needs to happen.

Assuming for a second that there was only one answer, if you had to chose one, which would it be: anonymity or accountability? And more importantly, why?

Oil Droplets and Your Banking Credentials

Warning: IANAQC (I am not a quantum cryptographer)

What does a droplet of oil have in common with the security of your banking credentials? Very little, you might think. However, there is research that came out a few months back, that confirms a theory made (and then dismissed) over 80 years ago about quantum effects. Bear with me.

For the last 80 years or so people have believed that particles are in two or more places at once, and only once measured do they “choose” a position and lock in. By virtue of being in two or more places at once, it is believed that a quantum computer can test all theories in a binary question simultaneously (on or off). Each binary question is effectively one bit of entropy, and if you get enough bits, you can build a very powerful computer.

From a computer security perspective it means that factoring large primes is a relatively easy thing to do – you get enough bits into your machine and you can factor the largest publicly available crypto-systems. While it is believed by the likes of Dr. Martin Helman (of Diffe-Hellman-Merkel key exchange infamy) that we have 10 years before such a machine is feasible and an additional 10 years before such a machine is usable, that still brings the time horizon of quantum cryptology into our lifetime.

That’s a scary thought if you have secrets that need to live beyond your lifetime – you only have 20 years before they are breakable by the military — or by anyone who could afford such a device in their evil lair; the only caveat would be the data collection and storage space for all that encrypted data.

However, recent findings suggest that particles might actually not be in multiple positions all at once; they might instead act like a droplet of oil dancing along the surface of a pool of water. Unlike a droplet of water, an oil droplet won’t go beneath the surface of the water (because of differing densities for oil and water). Instead, the oil droplet will bounce along on the surface. But when the oil droplet is first dropped, it causes a ripple, and that ripple will bounce around and could actually interact with the oil droplet again, causing it to move seemingly erratically.

So perhaps quantum particles, like oil, do not behave in “spooky” ways, but rather in very deterministic (as opposed to probabilistic) ways. That is to say that there may be no “magic” behind how particles behave – it may just be a very challenging fluid-dynamics problem. If we knew enough about the waves and the oil we might be able to predict exactly where the oil (or particle) would end up. Okay, but what does this have to do with your banking password?

If this theory is indeed true, cryptographers might be unable to build a quantum computer capable of being in a super-position (two positions at once), and therefore capable of factoring all possible variations at once in the way once envisioned. If that is true, we could be much safer in the near-term as our secrets stay safe from such a machine. That means that crypto-reliant technologies like SSL/TLS might actually have some greater longevity than previously thought (barring things like Poodle, BEAST, CRIME, etc.).

Although this is an unconventional theory, one that is not at all agreed upon by the scientific community (yet), and a difficult one to prove at that, it might make your banking passwords safe for a little longer than we previously thought. Who knew? Oil. Hmm! Read more about it in Wired.

So Your Nude Selfies Were Just Hacked…

If you haven’t been following the most recent news regarding a wide swath of celebrities whose accounts were hacked and private photos shared, you must have been having a lot of fun on Labor Day and I salute you.

Probably the very first thing most of the victimized celebrities are doing now is damage control – limiting their exposure as much as possible. Yes, their names are going to be put out there. Yes, it’s horribly embarrassing, but it’s also not a time to get caught up in self-pity (or self-blame): there’s work to be done. Being cool-headed and reducing the exposure will reduce the pain overall. Some people might go down the path of making examples out of the alleged perpetrators — but beware the Barbra Streisand effect. The harder you try to hide things, the more people want to see those things — like arial photos of Ms. Streisand’s lavish house, for instance.

But these events bring up an interesting point: What would you do if you were a celebrity who had dodged the bullet, but had similar incriminating photos on their computers, cell phones, etc.? More importantly, what should you be doing right now, this very minute, to make sure that anything you have posted to the cloud and want to keep private actually remains so?

First things first – locate every place that the sensitive information lives.
If it’s on a lover’s phone, an old computer that is collecting dust under your staircase, an old email account, or uploaded onto Dropbox – whatever the case may be, you need to find all of it and get an inventory of what those things are. Once you know what’s there, you have to find a way to securely delete that information. Just putting things in the trash can doesn’t work, unfortunately. Older computers have a knack for keeping lots of copies of things when discs defragment. So you need to securely wipe not only the data, but also the free-space on your computer.

Next use the “mud puddle” rule of thumb.
Ask the company that makes the system in question if there is any way to recover data after you have dumped it in a puddle of mud. If the answer is yes, you have a problem, because it means they have copies of your data and can decrypt it (if it was ever encrypted at all) and access it. Make sure that all copies are deleted and removed securely from all systems, and ask for some proof of that. In the worst case scenario, get your lawyer involved to make sure that all copies are securely and permanently deleted. You have two options with computers – either they are perfectly private and accessible only to you, or they have a high-level of convenience and availability. Choose one.

Next, remove all automated syncing to cloud-based systems.
There is no reason you should be sending all of your information to an environment that you don’t completely control. Find an IT guy to set up a private cloud instance that you can back up your computer to, and make sure you are the only one who can access that system once it’s set up if you have to store information off-site. There’s lots of precious family photos, and emails and documents that would be painful to lose. Back them up in a place that only you have access to.

Choose strong passwords.
It sounds simple but nearly every successful hack involving brute force relies on the individual accounts having weak passwords. Don’t fall for it: choose strong passwords, and make them unique. If your password for your free webmail is the same as for your critical systems that protect your nude pictures, you’re more likely to get hacked. It’s always the weakest link, so keep your passwords unique and strong. There’s a lot of password research out there that says that choosing a “passphrase” made up of several words in a row is the strongest sort of password. If you’re an actress, you are used to memorizing lines to get a part. Consider this just another script you need to memorize, but one that can protect your entire reputation. Or, even better, use “second factor authentication” – a physical token or something you have that cannot be stolen from the Internet, if your provider allows it.

Encrypt your nude selfies.
I’m not going to judge you — nude selfies aren’t bad, but they can be dangerous if you don’t encrypt them. There’s lots of encryption software out there and a great deal of it is free. You can choose something that encrypts your selfies when you’re not looking at them and decrypts them when you want to see them for some reason.

Send encrypted nude selfies.
Similar to the above, if you’re going to be sending nude selfies, make sure you do so in a way that self destructs. Software like Wickr can accomplish that for cell phones. There’s no reason to keep them around forever, and if you do need to keep them, you can always save them and re-send them later.

Don’t send nude selfies at all.
I know it sounds obvious and stupid, but once you become a celebrity, it’s really imperative to avoid sending anything incriminating or even keeping it around at all. If you do have to have it for some reason, make sure you keep it on a computer that isn’t capable of going online, so at least you can keep it compartmentalized. Systems that aren’t online are much harder to hack – and usually require physical access to your premises. This is the reason some militaries are reportedly going back to typewriters – it’s a lot harder to hack something physical without involving breaking and entering.

Pick strong secret questions.
One of the most often overlooked issues in computer security is the secret question. Most secret questions are terrible: “what is your favorite color?” Well, the chances that it’s one of a handful of colors is extremely high, and it’s even higher if you’re a celeb since no-doubt at some point someone asked you that on camera. This makes it extremely easy for someone to guess and therefore access your information. So lie and choose something else – some long string that only you know. Write it down somewhere so you don’t lose it, but keep it safe and unique – similar to passwords. Is your favorite color blue? I hope not. Is your birth date the same one that’s on IMDB? Please tell me no.

Disable everything you don’t need.
Living in LA does require you to use hands-free, and I’m sure driving down Venice Beach in your convertible sounds great, but at the same time every time you turn on wireless on your phone, or bluetooth or any additional service, you are putting yourself at greater risk. It’s all a matter of surface area, and the more things you can disable, the better.

Find a security pro.
I highly recommend you find a good security expert to analyze your life, and figure out how and where you are vulnerable. It might be something stupid and avoidable, like you leave your camera in a hotel room while you are away, or it might be something very complex having to do with configuration settings on your home Wifi. Whatever the case, you really should have someone who knows what they are doing take a look at how you live and give you practical advice on how to protect yourself.

It’s easy to blame the victims, and that’s the very last thing I’d ever want to do. I think, if anything, this just shows what a large percentage of people take nude pictures of themselves, so we can’t judge. But there are definitely a few steps people can take to avoid some of the embarrassment. For those who dodged the bullet, consider yourselves lucky; but perhaps it’s time to take your lucky winning streak and leave the blackjack table while there is still time.

Aviator (Default) Search Change

In an effort to find ways to work with a search provider, we spent a lot of time researching various models that would enable us to stay on the side of our users AND allow us to generate revenue to help us pay for Aviator development. Naturally we attempted to work with DuckDuckGo since they were already our search provider of choice. Unfortunately, the only way they were willing to work with us was to monetize ads, and we just aren’t willing to do that. Browsers monetizing ads is at the root of what’s causing issues for users, stifling security and eliminating privacy.

After months of work we decided that Disconnect Search was the best and most exciting path forward. We have a long-standing relationship with the Disconnect team because of their popular browser plugin, and their privacy record is spotless — and Disconnect was comfortable working a deal with us that didn’t rely on selling ads. You can’t beat that! We were thrilled to find a partner who cares enough about their users and ours to forgo the typical death cycle of mandatory partnerships that revolve around advertising, and instead just revolve around being the default search.

This is just another way we want to be clear that we are on our customer’s side, even in matters of business. Our transparency with our business model is the crux of why our users can trust our decisions to be in their best interest. So, in the coming update you will notice that the browser politely asks you if you want to switch from DuckDuckGo to Disconnect. The option is yours, of course, but this will help us continue to evolve the browser, and we believe Disconnect is the most private search engine we could find to boot. Two birds with one stone, right?!

As always, questions and comments are welcome!

DHS and Cyberterrorism

The DHS was recently polled on what groups and attacks they are personally most concerned about. This comes from a pretty wide range of intelligence officers at various levels of the military industrial complex. This underscores how the military is thinking and what they are currently most focused on. The tidbits I found interesting are on pages 7 and 8:

https://www.start.umd.edu/pubs/START_UnderstandingLawEnforcementIntelligenceProcesses_July2014.pdf

The DHS seems to be most concerned about Sovereign Citizens and Islamic Extremists/Jihadists (in that order). The rationale isn’t well explained, but I would presume that physical proximity and the radical nature of Sovereign Citizen groups trumps the extremist nature of Jihadists. I’m speculating, but that would seem to make sense. It could also be a reaction to FUD, but it’s hard to say.

More interestingly, the threat they find most viable is Cyberterrorism. That makes a lot of sense, because Cyberterrorism is cheap, can be done instantaneously, can be done remotely, and can be done with minimal skills and at minimal risk. It’s really hard to tell what’s Cyberterrorism versus what is just a normal for-profit attack, and attribution is largely an un-solvable problem if the attacker knows what they’re doing. Also, even if you can identify the correct adversary, extradition/rendition are tough problems.

There’s not a lot of substance here, because it’s all polls, but it’s interesting to see that our industry is at the top of the US intelligence community’s mind.