Category Archives: Information Security

CISA Gives Us A Starting Point

Posted on by

Everyone struggles with identifying the “right” vulnerabilities to patch. It’s a near universal problem. We are all wondering, “Which vulnerabilities in my long queue are going to get me?”

Most organizations calculate a CVSS (base score or amended) which a solid body of research starting with Alloddi & Massacci, 2014, demonstrates is inadequate to the task.

Exploit Prediction Scoring System (EPSS) is based in the above research, so it could provide a solution. But the web calculator cannot score each open vulnerability in our queue over time: we need to watch the deltas, not a point in time. There’s unfortunately, no working EPSS solution, despite the promise.

CISA have listed 300 “vulnerabilities -currently- being exploited in the wild” in Binding operational directive 22-01.

Finally, CISA have given us a list that isn’t confined to a “Top 10”: Start with these!

Top 10 lists provide some guidance, but what if attackers exploit your #13?

300 is an addressable number in my experience. Besides, you probably don’t have all of them in your apps. > 300. We all can do that much.

The CISA list provides a baseline, a “fix these, now” starting point of actively exploited issues that cuts through the morass of CVSS, EPSS, your security engineer’s discomfort, total vulnerabilities ==> organization “risk”. (If you’re running a programme based upon the total number of open vulnerabilities, you’re being misled.)

https://thehackernews.com/2021/12/why-everyone-needs-to-take-latest-cisa.html

Posted on by

I don’t typically amplify security tool vendors’ announcements.

However, for about 15 years, I’ve been urging vendors to address the millions of developers who do not work for a company large enough to afford million dollar tools, or even tools whose entrance is $10’s of thousands. Millions of programmers cannot afford commercial tools as currently priced; I’m sorry to be so very blunt.

ForAllSecure have done it! The Mayhem for API Free Plan*
This is a significant step in the right direction to everyone’s benefit.

(Please attend my keynote at FuzzCon, August 5th, for what’s wrong with #appsec and why multiple techniques that must include #fuzzing comprise our current best hope for software security.)

Kudos to the folk at ForAllSecure. You’re leading the way towards a brighter, more secure future.

To be fair, a couple of static analyzer vendors have offered open source projects free scanning for quite some time. Open source programmers: there’s no excuse for not taking advantage of these services!

Still, much software is proprietary with lot of that written by startups, small shops, lone programmers. These coders need tools, too. We all suffer because a large percentage of coders don’t have access to a broad selection of commercial grade tools.

Other vendors, are you listening? I hope so.

*50 free scans/month

cheers,

/brook

Threat Model Diveristy

Posted on by

“People and collaboration over processes, methodologies, and tools.”

–The Threat Modeling Manifesto, Value #2

During our panel, my dear friend and longtime collaborator, Izar Tarandach, mentioned something that occurs so often when threat modelling as to be usual and customary. This happens so often, it is to be expected rather than being merely typical. We were speaking on Threat modelling for Agile software development practices at OWASP BeNeLux Days 2020. Izar was addressing the need for broad participation in a threat model analysis. As an example, he described the situation when an architect is drawing and explaining a system’s structure (architecture) at a whiteboard, and another participant at the analysis, perhaps even a relatively junior member of the team says, “but that’s not how we had to implement that part. It doesn’t work that way”.

I cannot count the number of times I’ve observed a disparity between what designers believe about system behaviour and how it actually runs. This happens nearly every time! I long since worked the necessity for uncovering discrepancies into my threat modelling methods. That this problem persists might come as a surprise, since Agile methods are meant to address this sort of disconnect directly? Nevertheless, these disconnect continue to bedevil us.

To be honest, I haven’t kept count of the number of projects that I’ve reviewed where an implementer as had to correct a designer. I have no scientific survey to offer. However, when I mention this in my talks and classes, when I speak with security architects (which I’m privileged to do regularly), to a person, we all have experienced this repeatedly, we expect it to occur. 

In my understanding of Agile practice, and particularly SCRUM, with which I’m most familiar and practice, design is a team effort. Everyone involved should understand what is to be implemented, even if only a sub-team, or a single person actually codes and tests. What’s going on here?

I have not studied the cause and effect, so I’m merely guessing. I encourage others to comment and critique, please.  Still, as projects get bigger with greater complexity, there are two behaviours that emerge from the increased complexity that might be responsible for disconnection between designers and implementers:

  1. In larger projects, there will be a need to offer structure to and coordinate between multiple teams. I believe that this is what Agile Epics address. Some amount of “design”, if you will (for want of a better word) takes place outside and usually before SCRUM teams start their cycles of sprints. This structuring is intended to foster pieces of the system to be delivered by individual, empowered Agile teams while still coming together properly once each team delivers. My friend Noopur Davis calls this a “skeleton architecture”. The idea is that there will be sufficient structure to have these bits work together, but not so much as to get in the way of a creative and innovative Agile process. That may be a rather tricky razor’s edge to achieve, which is something to consider as we build big, complex systems involving multiple parts. Nonetheless, creating a “skeleton architecture” likely causes some separation between design and implementation.
  2. As this pre-structuring becomes a distinct set of tasks (what we usually call architecture), it fosters, by its very nature, structuring specialists, i.e., “architects”. Now we have separation of roles, one of the very things that SCRUM was meant to bridge, and collapsing of which lies at the heart of DevOps philosophy. I’ve written quite a lot about what skills make an architect. Please take a look at Securing Systems, and Secrets Of A Cyber Security Architect for my views, my experiences, and my attempts to describe security architecture as a discipline. A natural and organic separation occurs between structurers and doers, between architects and implementers as each role coalesces. 

Once structuring and implementing split into discrete roles, and I would add, disciplines, then the very nature of Agile empowerment to learn from implementing practically guarantees that implementations diverge from any plans. In the ideal world, these changes would be communicated as a feedback loop from implementation to design. But SCRUM does not specifically account for design divergences in its rituals. Designers need to be present during daily standup meetings, post-sprint retrospectives, and SCRUM planning rituals. Undoubtedly, this critical divergence feedback does occur in some organizations. But, as we see during threat modelling sessions, for whatever reasons, the communications fail, or all too often fail to lead to an appropriately updated design.

Interestingly, the threat model, if treated as a process and not a one-time product can provide precisely the right vehicle for coordination between doing and structure, between coding and architecture. 

“A journey of understanding over a security or privacy snapshot.”

–The Threat Modeling Manifesto, Value #3

Dialog is key to establishing the common understandings that lead to value, while documents record those understandings, and enable measurement.

–The Threat Modeling Manifesto, Principle #4

When implementors must change structures (or protocols, or flows, anything that affects the system’s architecture), this must be reflected in the threat model, which must mirror everyone’s current understanding of the system’s state. That’s because any change to structure has the potential for shifting which threats apply, and the negative impacts from successful exploitations. Threat modelling, by its very nature, must always be holistic. For further detail on why this is so, I suggest any of the threat modelling books, all of which explain this. My own Secrets Of A Cyber Security Architect devoted several sections specifically to the requirement for holism. 

Thus, a threat model that is continually updated can become the vehicle and repository for a design-implementation feedback loop.

Value #5:

“Continuous refinement over a single delivery.”

Threat model must, by its very nature deal in both structure (architecture) and details of implementation: engineering. Threat modelling today remains, as I’ve stated many times, both art and science. One imagines threats as they might proceed through a system – often times, a system that is yet to be built, or is currently in the process of building. So, we may have to imagine the system, as well. 

The threats are science: they operate in particular ways against particular technologies and implementations. That’s hard engineering. Most defenses also are science: they do what they do. No defense is security “magic”. They are all limited.

Threat modelling is an analysis that applies the science of threats and defenses to abstracted imaginings of system through mental activity, i.e., “analysis”. 

Even though a particular weakness may not be present today, or we simply don’t know yet whether it’s present, we think through how attackers would exploit it if it did exist. On the weakness side, we consider every potential weakness that has some likelihood of appearing in the system under analysis, based upon weaknesses of that sort that have appeared at some observable frequency in similar technologies and architectures. This is a conjunction of the art of imagining coupled to the science of past exploitation data, such as we can gather. Art and science.

The Threat Modeling Manifesto’s definition attempts to express this:

“Threat modeling is analyzing representations of a system to highlight concerns about security and privacy characteristics.”

Threat modelling then requires “representations”, that is, imaginings of aspects of the target of the analysis, typically, drawings and other artifacts. We “analyze”, which is to say, the art and science that I briefly described above for “characteristics”, another somewhat imprecise concept.

In order to be successful, we need experts in the structure of the system, its implementation, the system’s verification, experts in the relevant threats and defenses, and probably representatives who can speak to system stakeholder’s needs and expectations. It often helps to also include those people who are charged with driving and coordinating delivery efforts. In other words, one has to have all the art and all the science present in order to do a reasonably decent job. To misquote terribly, “It takes a village to threat model”[1].

Participation and collaboration are encapsulated in the Threat Modeling Manifesto.

Consider the suggested Threat Modeling Manifesto Pattern, “Varied Viewpoints”:

“Assemble a diverse team with appropriate subject matter experts and cross-functional collaboration.”

And, our Anti-pattern, “Hero Threat Modeler” speaks to a need to avoid over-dependence on a single individual:

“Threat modeling does not depend on one’s innate ability or unique mindset; everyone can and should do it.”

Another frequent occurrence during threat modelling sessions will be when a member of the team who would not have normally been included during leader-only threat modelling names a weakness of which the leaders were unaware, or which other active participants simply missed in their analysis. Diversity in threat modelling applies more system knowledge and understanding, which leads to more complete models. 

Since attackers are adaptive and creative and there are a multiplicity of objectives for attack, diversity while modelling counters attacker variety. I will note that through the many threat models I’ve built (probably 1000’s), I’ve been forced to recognize my limitations, that I am perfectly capable of missing something obvious. It’s my co-modelers who keep me honest and who check my work.

Failure to uncover the differences between representation and implementation risk failure of one’s threat model. As Izar explained, even a lead designer may very likely not understand how the system actually works. To counter this problem, both Izar and I, and probably all the co-authors of the Threat Modeling Manifesto account for these misunderstandings through our threat modelling processes. One way is to ensure that a diverse and knowledge collection of people participate. Another is to begin a session by correcting the current representations of the system through the collected knowledge of participants.

I often say that one of the outcomes of broad threat model participation has nothing to do with the threat model. Attendees come away with a fuller understanding of how the system actually works. The threat model becomes a valued communication mechanism with effects beyond its security and privacy purposes. As both art and science, we find it critical to be inclusive rather than exclusive when threat modelling. Your analyses will improve dramatically.

Cheers,

/brook

[1] Please don’t make assumptions about my personal politics just because I mangled the title of one of Hilary Clinton’s books. Thanks

Bad Design Decisions…

Posted on by

Bad Design Decisions…

Sometime in 2018, I noticed a pitch for a new “sport” watch that generated its energy from your body. That sounded cool, so I sent the pitch to my spouse. Then I forgot all about it.

Imagine my surprise when the brand new, version 1 watch appeared out from under our Christmas tree.

Immediately, things started to go South. The watch was supposed to turn on; it remained blank, silent, obviously inoperable no matter how I followed the single page of textual directions. Try as I might, it was just a hunk of metal, plastics, and circuits (presumably).

Naturally, I called the Matrix PowerWatch Support who patiently detailed exactly the instructions I’d already determined were not working. I always find that a bit patronizing, since I did take the time describe everything that I’d tried. They sent me the accessory USB charger, gratis, but still no joy with that particular watch. Another call to support.

I should have taken the initial experience as a sign. There would be many more exchanges over the following year+, until I had realized that Matrix PowerWatch had apparently intentionally burned all of its version one buyers.

After six weeks or so of wrangling, Matrix finally sent me a working watch, which, per instructions, started, paired, and appeared to function.

The PowerWatch keeps time, as expected. It also measures steps, though unlike my couple of early Fitbits, the PowerWatch has no ability to calibrate one’s stride. My longer than typical legs usually take in somewhat more distance than others more typically fitted.

Since the PowerWatch is constantly measuring my body temperature (and its disparity with ambient), the watch will “calculate” calories expended, as well. I found this last to be an interesting data point. I didn’t take the calory count as gospel. But the watch could definitely tell me when I’d had a good work out versus days spent at a computer.

The watch also has a stopwatch, timer, and lap counter. I found these almost unworkable given the way the two physical buttons on the watch work, or don’t work much of the time. So I never used these functions. My mobile phone is a lot easier.

The next sign of trouble was syncing the watch to my phone. The instructions said to go to the watch’s settings, scroll down to “Sync”, then press both buttons. This operation only sometimes worked. Pressing both buttons at the same time requires serious hand contortions that I found painful at times, certainly uncomfortable. Little did I know as I started having troubles that sync failures were a symptom of poor design choices for which there would be no remedy.

More calls and emails to Matrix Support, which often went unanswered for days. I suspect that there was actually only a single support person, maybe a couple? Anyway, as you may imagine, the process and the watch were becoming quite a time sink.

Finally, the support engineer told me that I could simply pull the app display down and the watch would sync. Eureka! Why wasn’t that in any instructions or described somewhere on the PowerWatch web site?

Finally, was I past issues and on to happy use? Um, no.

For, in their wisdom, the PowerWatch software engineers had chosen to either write their own Bluetooth stack, or muck with one in some way as to make the stack predictably unstable.

I have had and continue to use without trouble, dozens of Bluetooth devices, the vast majority of which pair and sync (if needed) with phones, tablets, computers nearly seamlessly. Some early devices had weak antennas, so syncing had to be performed in close proximity. But once paired, syncing just happens. Not so, the Matrix PowerWatch.

The watch would sync for a few days. Then the pairing between watch and phone would break in some way. The sync operation would timeout. If I restarted the app, syncing might occur. Once in a while, a reboot of the phone might get it going.

Meanwhile, all the other Bluetooth devices paired with that phone continued to work fine. Which has led me to believe that it’s the watch software at fault.

But you see, the PowerWatch designers, in their infinite lack of foresight and wisdom, provided no way to simply reboot the watch! Better would have been a way to restart the Bluetooth stack. Observing instability, one prepares for it. Actually, one prepares for instability, period, especially in version 1!

I’m pretty sure that a watch system reboot would have solved this problem. But no, the only recourse is to unpair the watch and reset it to start up mode: factory reset. That’s the only option.

Unpairing the watch removes all ones accumulated fitness data (and any personalization) from the watch and application. One is forced to start over completely. There is no other course.

Worse, if you don’t sync the watch for a few days (who wants to go through this horror even once/day?), it both loses fitness data AND the Bluetooth connection blows up. Everything is lost. This happens regularly, predictably.

One of the first design rules that I learned, years ago, was, “never, ever lose your customer’s data”. Failure one.

Rule 2: for difficult or tricky protocols, try to use a vetted implementation. Roll your own at you and your customers’ risk. Perhaps, failure two?

Rule 3: Plan for errors and crashes, especially from conditions you can’t anticipate during development. Failure three, for sure.

If I’d had a way to restart without losing data, say, turn Bluetooth off, then on again, or even a non-destructive reboot, I wouldn’t be writing this today. All software contains bugs. We have learned how to work around that. Except, not the Matrix folks.

As I worked through my debugging process with PowerWatch Customer Support, they promised me that in March, 2020, there would be a new version that “fixed this problem”.

I hope that I’ve learned how to be patient, especially with software fixes. After a lifetime designing, writing, debugging, securing software, I understand the difficulties in finding and fixing bugs, then getting the fixes into the field. I get it.

Waiting, I lived with resetting my watch every 2-4 weeks, losing whatever accumulated data I had, sure. Amongst the many things competing for my time, a sport watch isn’t really at the top of my list. I’d already spent far too much time on PowerWatch.

March finally arrived. I dutifully attempted the upgrade (that was a three-day battle in and of itself). Guess what? The promised upgrade was only for version 2 watches! My watch’s system was precisely the same after the upgrade as before. All problems still active, nothing changed. I’d been misled, purposely?

As you may imagine, I was upset. I still am. Matrix apparently decided that version 1 customers weren’t worth keeping. Maybe there’s some hardware or operating system limitation that prevents the upgrade? I really don’t care. That shouldn’t be my worry.

Was there an upgrade offer from Matrix? That’s often used as a path forward. Say, an offer of 50% off the retail for version 2? Nope. Crickets.

What I didn’t realize is that there was another lurking reason for burning version 1 customers: the battery died a month later. Now, no watch. Just a pile of metal, plastics, and circuits. The free charger still works. But I’ve no watch to charge on it.

I suspect that Matrix realized that not only is the watch inherently unstable due to its Bluetooth issues and poor design. But they also must have understood that these version 1 devices were going to stop functioning soon, anyway. Matrix threw away its first customers. They’ve turned their back on us. It’s “goodbye and good luck”.

My only recourse is to publish my sad story so that others will be wary of a company that clearly doesn’t much care about at least some of its customers. And, engineers who don’t program defensively, who fail to give users ways to deal with their mistakes.

Don’t buy PowerWatch, unless you understand with whom you’re going to be dealing.

Cheers,

/brook

Security Research Is Threat Modeling’s Constructive Criticism

Posted on by

(the following is partially excerpted from my next book)

Adam Shostack, author of Threat Modeling: Designing for Security has succinctly described a process of constructive critique within engineering:

“The back and forth of design and critique is not only a critical part of how an individual design gets better, but fields in which such criticism is the norm advance faster.”

The Spectre/Meltdown issues are the result of a design critique such as Shostack describes in his pithy quote given above.  In fact, one of the fundamental functions that I believe security research can play is providing designers with a constructive critique.

Using Spectre and Meltdown as an example of engineering critique, let’s look at some of the headlines from before the official issue announcement by the researchers:

“Kernel-memory-leaking Intel processor design flaw forces Linux, Windows redesign”, John Leyden and Chris Williams 2 Jan 2018 at 19:29, The Register, https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

“A CRITICAL INTEL FLAW BREAKS BASIC SECURITY FOR MOST COMPUTERS”, Andy Greenberg, January 3, 2018, Wired Magazine, https://www.wired.com/story/critical-intel-flaw-breaks-basic-security-for-most-computers/

There were dozens of similar headlines (many merely repeating the first few, especially, The Register’s), all declaiming a “flaw” in CPUs. I want to draw the reader’s attention to the word, “flaw”. Are these issues “flaws”? Or, are they the result of something else?

The Register headline and that first article were based upon speculation that had been occurring amongst the open source community supporting the Linux Kernel. A couple of apparently odd changes that had been made to kernel code. But, the issues to which these changes responded were “embargoed”, that is, the reasoning behind the changes was known only to those making the changes.

Unlike typical open source changes, whose reasoning is public and often discussed by members of the community, these kernel changes had been made in opaquely without public comment, which of course, set concerned kernel community members wondering.

To observers not familiar with the reasoning behind the changes, it was clear that something was amiss and likely in relation to CPU functions; anxious observers were guessing what might be the motivation for those code changes.

Within the digital security universe, there exists an important dialog between security research aimed at discovering new attack techniques and the designers of the systems and protocols upon which that research is carried out. As Adam noted so very wryly, achieving solid designs, even great ones, and most importantly, resilient designs in the face of omnipresent attack requires an interchange of constructive critique. That is how Spectre and Meltdown were discovered and presented.

Neither of this collection of (at the time of announcement) new techniques involved exercising a flaw, that is, a design error – in other words, the headlines quoted just above were erroneous and rather misleading[2].

Speculative execution and the use of kernel mapped user memory pages by operating systems were intentional design choices that had been working as designed for more than 10 years. Taken together, at least some of the increases in CPU performance over that period can directly be tied to speculative execution design.

Furthermore, and quite importantly to this discussion, these design choices were made within the context of a rather different threat landscape. Some of today’s very active threat actors didn’t exist, or at least, were not nearly as active and certainly not as technically sophisticated circa 2005 as they are today, May 2018.

If I recall correctly (and I should be able to remember, since I was the technical lead for Cisco’s Web infrastructure and application security team at that time), in 2005, network attacks were being eclipsed by application focused attack methods, especially, web attack methods.

Today, web attacks are very “ho, hum”, very run of the ordinary, garden variety. But in 2005, when the first CPU speculative execution pipelines were being released, web applications were targets of choice at the cutting edge of digital security. Endpoint worms and gaining entrance through poor network ingress controls had been security’s focus up until the web application attack boom (if I may title it so?). At about that time, targeting web applications was fast displacing network periphery concerns. Attackers were in the process of shifting to targets that used a standard protocol (HTTP) which was guaranteed to pass through organizational firewalls. Many of the new targets’ were becoming always  available via the Public Internet.

Since the web application attack boom, attacks and targets have continued to evolve. The threat landscape changed dramatically over the years since the initial design of speculative execution CPUs. Alongside the changes in types of attackers as well as their targets, attacker and researcher sophistication has grown, as has an attackers’ toolbox. 2018 is a different security world than 2005. I see no end to this curve of technical growth in my crystal ball.

The problem is, when threat modeling, whether in 2005 or 2018, one considers the attacks of the past, those of moment, and then one must try one’s best to project from current understanding to attacks that might arise within the foreseeable future. Ten or twelve years seems an awfully long horizon of prescience, especially when considering the rate at which technical change continues to take place.

As new research begins to chew at the edges of any design, I believe that the wise and diligent practitioner revisits their existing threat models in light of developments.

If I were to fault the CPU and operating system makers whose products are subject to Spectre or Meltdown, it would be for a failure to anticipate where research might lead, as research has unfolded. CPU threat modelers could have taken into account advances in research indicating unexpected uses of cache memory.

Speculative execution leaves remnants of a speculated execution branch in cache memory when a branch has not been taken. It is those remnants that lie at the heart of this line of research.

A close examination of the unfolding research might very well have led those responsible for updating CPU threat models to consider the potential for something like Spectre and Meltdown. (Or, perhaps the threat models were updated, but other challenges prevented updates to CPU designs? CPU threat modelers, please tell us all what the real story is)

I’ve found a publication chain during the 3 years previous that, to me, points towards the new techniques. Spectre and Meltdown are not stand-alone discoveries, but lie on a body of CPU research that had been published regularly for several years.

As I wrote for McAfee’s Security Matters blog in January of 2018 (as a member of McAfee’s Advanced Threat Research Team),

“Meltdown and Spectre are new techniques that build upon previous work, such as “KASLR”  and other papers that discuss practical side-channel attacks. The current disclosures build upon such side-channels attacks through the innovative use of speculative execution….An earlier example of side-channel based upon memory caches was posted to Github in 2016 by one of the Spectre/Meltdown researchers, Daniel Gruss.” Daniel Gruss is one of the Spectre and Meltdown paper authors.

Reading these earlier papers, it appears to me that some of the parent techniques that would be used for the Spectre and Meltdown breakthroughs could have been read (should have been read?) by CPU security architects in order to re-evaluate the CPU’s threat model. That previously published research was most certainly available.

Of course, hindsight is always 20/20; I had the Spectre and Meltdown papers in hand as I reviewed previous research. Going the other way might be more difficult?

Spectre and Meltdown did not just spring miraculously from the head of Zeus, as it were. They are the results of a fairly long and concerted effort to discover problems with and thus, hopefully, improve the designs of modern processors. Indeed, the researchers engaged in responsible disclosure, not wishing to publish until fixes could be made available.

To complete our story, the driver that tipped the researchers to an early, zero-day disclosure (that is, disclosure without available mitigations or repairs) were the numerous speculative (if you’ve forgive the pun?) journalism (headlines quoted above) that gained traction based upon misleading (at best) or wrong conclusions. Claiming a major design “flaw” in millions of processors is certainly a reader catching headline. But, unfortunately, these claims were vastly off the mark since no flaw existed in the CPU or operating system designs.

While it may be more “interesting” to imagine a multi-year conspiracy to cover up known design issues by evil CPU makers, no such conspiracy appears to have taken place.

Rather, in the spirit of responsible disclosure, the researchers were waiting for mitigations to be made available to customers; CPU manufacturers and operating system coders were heads down at work figuring out what appropriate mitigations might be, and just how to implement these with the least amount of disruption. None of these parties was publicly discussing just why changes were being made, especially to the open source Linux kernel.

Which is precisely what one would expect in order to protect millions of CPU users: embargo the technical details to foil attackers. There is actually nothing unusual about such a process; it’s all very normal and typical, and unfortunately for news media, quite banal[3].

What we see through the foregoing example about Spectre and Meltdown is precisely the sort of rich dialog that should occur between designers and critics (researchers, in this case).

Designs are built against the backdrop and within the context of their security “moment”. Our designs cannot improve without collective critique amongst the designers; such dialog internal to an organization or at least, a development team is essential. I have spoken about this process repeatedly at conferences: “It takes a village to threat model,” (to misquote a famous USA politician.)

But, there’s another level, if you will, that can reach for a greater constructive critique.

Once a design is made available to independent critics, that is, security researchers, research discoveries can and I believe, should become part of an ongoing re-evaluation of the threat model, that is, the security of the design. In this way, we can, as an industry, reach for the constructive critique called for by Adam Shostack.

[1]In my humble experience, Adam is particularly good at expressing complex processes briefly and clearly. One of his many gifts as a technologist and leader in the security architecture space.

[2]Though salacious headlines apparently increase readership and thus advertising revenue. Hence, the misleading but emotion plucking headlines.

[3]Disclosure: I’ve been involved in numerous embargoed issues over the years.

KRACKs Against Wi-Fi Serious But Not End of the World

Posted on by

On October 12, researcher Mathy Vanhoef announced a set of Wi-Fi attacks that he named KRACKs, for key reinstallation attacks. These attack scenarios are against the WPA2 authentication and encryption key establishment portions of the most recent set of protocols. The technique is through key reinstallation.

The attack can potentially allow attackers to send attacker controlled data to your Wi-Fi connected device. In some situations, the attacker can break the built in Wi-Fi protocol’s encryption to reveal users’ Wi-Fi messages to the attacker.

However key reinstallation depends on either working with the inherent timing of a Wi-Fi during a discreet, somewhat rare (in computer terms) exchange or the technique depends upon the attacker forcing the vulnerable exchange through some method (see below for examples). Both of these scenarios take a bit of attacker effort, perhaps more effort than using any one of the existing methods for attacking users over Wi-Fi?

For this reason, while KRACKs Attacks is a serious issue that should be fixed as soon as possible (see below), our collective digital lives probably won’t experience a tectonic shift from Wi-Fi key reinstallation attacks (“KRACKs Attacks”).

Please read on for a technical analysis of the issue.

“… because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. As a result, the client may receive message 3 multiple times. Each time it receives this message, it will reinstall the same encryption key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the encryption protocol. We show that an attacker can force these nonce resets by collecting and replaying retransmissions of message 3 of the 4-way handshake. By forcing nonce reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged.”

–Mathy Vanhoef, “Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2”

The highlighted text above is Vanhoef’s, not mine.

Depending upon which key establishment exchange is attacked, as Vanhoef notes, injection of messages might be the result. But, for some exchanges, decryption might also be possible.

For typical Wi-Fi traffic exchange, AES-CCMP is used between the client (user) and the access point (AP, the Wi-Fi router). Decryption using KRACKs is not thought to be possible. But decryption is not the only thing to worry about.

An attacker might craft a message that contains malware, or at least, a “dropper,” a small program that when run will attempt to install malware. Having received the dropper, even though the message may make no sense to the receiving program, the dropper is still retained in memory or temporary, perhaps even permanent, storage by the receiving computer. The attacker then has to figure out some way to run the dropper—in attack parlance, to detonate the exploit that has been set up through the Wi-Fi message forgery.

“Simplified, against AES-CCMP an adversary can replay and decrypt (but not forge) packets. This makes it possible to hijack TCP streams and inject malicious data into them. Against WPA-TKIP and GCMP the impact is catastrophic: packets can be replayed, decrypted, and forged.“

–Mathy Vanhoef, “Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2”

Packet forgery is worse, as the receiver may consider that the data is legitimate, making it easier for an attacker to have the receiver accept unexpected data items, influencing the course of an exchange and establish a basis upon which to conduct follow-on, next-step exploits.

In my opinion KRACKs are a serious problem to which the wise will wish to respond.

The essential problem with Wi-Fi is that it is free to intercept. Radio waves travel over the air, which, as we all know, is a shared medium. One need not “plug in” to capture Wi-Fi (or any radio-carried) packets. One simply must craft a receiver strong enough to “hear,” that is, receive the transmissions of interest.

But although certainly serious, are KRACKs Attacks the end of the known digital universe? I think not.

First, the attacker has to be present and alert to the four-way, WPA2 handshake. If this has already passed successfully, the attacker’s key reinstallation is no longer possible. The handshake must be interjected at exchange #3, which will require some precision. Or, the attacker must force the key exchange.

One could, I imagine, write an attack that would identify all WPA2 handshake exchanges within range, and inject the attacker’s message #3 to each handshake to deliver some sort of follow-on exploit. This would be a shotgun approach, and might on large, perhaps relatively open networks have potential attacker benefits.[1]

Supplicants (as Wi-Fi clients are called) do not constantly handshake. The handshake interchange takes place upon authentication and reauthentication, and in some networks upon shifting from one AP to another when the client changes location (a “handoff”). These are discreet triggers, not a constant flow of handshake message #3. Johnny or Janie attacker has to be ready and set up in anticipation of message #3. That is, right after message #3 goes by, attacker’s #3 must be sent. Once the completed handshake message #4 goes by, I believe that the attack opportunity closes.

I fear that the timing part might be tricky for the average criminal attacker. It would be much easier to employ readily available Wi-Fi sniffing tools to capture sufficient traffic to allow the attacker to crack weak Wi-Fi passwords.

There are well-understood methods for forcing Wi-Fi authentication (see DEAUTH, below). Since these methods can be used to reveal the password for the network or the user, using one of these may be a more productive attack?

There are other methods for obtaining a Wi-Fi password, as well: the password must be stored somewhere on each connecting device or the user would need to reenter the password upon every connection/reconnection. Any attack that gives attacker access to privileged information kept by any device’s operating system can be used to gain locally stored secrets like Wi-Fi passwords.

Wi-Fi password theft (whether WPA-Enterprise or WPA-Personal) through Wi-Fi deauthentication, “DEAUTH”, has been around for some time; there are numerous tools available to make the attack relatively trivial and straight forward.

Nation-state attackers may have access to banks of supercomputers or massive parallel processing systems that they can apply for rapid password cracking of even complex passwords. A targeted nation-state–sponsored Wi-Fi password-cracking attack is difficult to entirely prevent with today’s technologies. There are likely other adversaries with access to sufficient resources to crack complex passwords in a reasonable amount of time, as well[2].

Obviously, as Vanhoef suggests, as soon as your operating system or Wi-Fi client vendor offers an update to this issue, patch it quickly. Problem, hopefully, solved. Please see https://www.krackattacks.com for updates from security vendors that are working with the discoverer. Question your vendor. If your vendor does not respond, pressure them; that’s my suggestion.

Other actions that organizations can couple with good Wi-Fi hygiene are to use good traffic and event analysis tools, such as modern Security Information Event Management (SIEM) software, network ingress and egress capture for anomaly analysis, and perhaps ingress/egress gateways that prevent many types of attack and forms of traffic.

“One can use VPN, SSH2 tunnels, etc., to ensure some safety from ARP poisoning attacks. Mathy Vanhoef also uses an SSL stripper that depends on badly configured web servers. Make sure your TLS implementation is correct!” – Carric Dooley, Global Lead, Foundstone Consulting Services

Organization Wi-Fi hygiene includes rapidly removing rogue access points, Wi-Fi authentication based upon the organization’s central authentication mechanism (thus don’t employ a WPA password), strong password construction rules, and certificates issued to each Wi-Fi client without which access to Wi-Fi will be denied. Add Wi-Fi event logs to SIEM collection and analysis. Find out whether organization access points generate an event on key reinstallation. This is a fairly rare event. If above-normal events are being generated, your Wi-Fi may be suffering from a KRACK.

None of the foregoing measures will directly prevent key reinstallation attacks. Reasonable security practices do make gaining access to Wi-Fi more difficult, which will prevent or slow other Wi-Fi attacks. Plus, physical security ought to pay attention to anyone sitting in the parking lot with a Wi-Fi antenna pointing at a campus building. But that was just as true before KRACKs were discovered.

For home users, use a complex password on your home Wi-Fi. Make cracking your password difficult. Remember, you usually must enter the password only once for each client device.

Maintain multiple Wi-Fi networks (probably, multiple access points), each with different passwords: one for work or other sensitive use; and another for smart TVs and the like and other potentially vulnerable devices such as Internet of Things devices—isolate those from your network shares, printers, and other sensitive data and trusted devices. Install a third Wi-Fi for your guests. That network should be set up so that each session is isolated from the others; all your guests need is to get to the internet. Each SSID network must have a separate, highly varied password: numbers, lowercase, uppercase, symbols. Make it a long passphrase that resists dictionary attacks.

Wi-Fi routers are a commodity; I do not suggest spending a great deal of money. How much speed do your occasional guests really need? Few Internet connections are as fast as even bottom-tier home Wi-Fi. Most of your visitors probably do not need access to your sensitive data, yes? Should your kids have their own Wi-Fi so that their indiscretions do not become yours?

Multiple Wi-Fi networks will help to slow and perhaps confound KRACKs cybercriminals. “Which network should I focus on?” You increase the reconnaissance the attacker must perform to promulgate a successful attack. Maybe they will move on to simpler home network.

If you happen to notice someone sitting in a car in your neighborhood with an open laptop, be suspicious. If they have what looks like an antenna, maybe let law enforcement know.

Basic digital security practices can perhaps help? For instance, use a VPN even over Wi-Fi. Treat Wi-Fi, particularly, publicly available Wi-Fi as an untrustable network. Be cognizant of where the Wi-Fi exists. WPA2 is vulnerable to decryption, so don’t trust airports, hotels, cafes, anywhere where the implementers and maintainers of the network are unknown.

Users of some Android and Linux clients should be aware that an additional implementation error allows an attacker immediate access to the decryption of client and access point Wi-Fi traffic. Remember, all those smart TVs, smart scales, home automation centers, and thermostats are usually nothing more than specialized versions of Linux. Hence, each may be vulnerable. On the other hand, if these are segregated onto a separate, insecure Wi-Fi, at least attackers will not have readily gained your more sensitive network and devices. While waiting for a patch for your vulnerable Android device, perhaps it makes sense to put it on the untrusted home Wi-Fi as a precaution.

You may have noticed that I did not suggest changing the home Wi-Fi passwords. Doing so will not prevent this attack. Still, the harder your WPA2 password is to crack, the more likely common cybercriminals will move on to easier pickings.

As is often the case in these serious issues, reasonable security practices may help. At the same time, failure to patch quickly leaves one vulnerable for as long as it takes to patch. I try to remember that attackers will become ever more facile with these methods and what they can do with them. They will build tools, which, if these have value, will then become ever more widespread. It is a race between attacker capability and patching. To delay deploying patches is typically a dance with increasing risk of exploitation. In the meantime, the traffic from this attack will be anomalous. Watch for it, if you can.

Many thanks to Carric Dooley from Foundstone Professional Services for his suggestions to complete and round out this analysis as well as for keeping me technically accurate.

Cheers,

/brook

[1] “When a client joins a network, it […] will install this key after receiving message 3 of the 4-way handshake. Once the key is installed, it will be used to encrypt normal data frames using an encryption protocol. However, because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. […] Each time it receives this message, it will reinstall the same encryption key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the encryption protocol. We show that an attacker can force these nonce resets by collecting and replaying retransmissions of message 3 of the 4-way handshake. By forcing nonce reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged.”

[2] Interestingly, my LinkedIn password was among those stolen during the 2011 LinkedIn breach. A research team attempted to crack passwords. After 3 months, they cracked something like 75% of the passwords. However, my highly varied, but merely 6 character password was never cracked. While today’s cracking is factors more sophisticated and rapid, still, a varied non-dictionary password still slows the process down considerably.

Why no “S” in IoT?

Posted on by

My friend, Chris Romeo, a security architect and innovator for whom I have deep respect and from whom I learn a great deal just posted a blog about the lack of security (“S”) in Internet of Things (IoT), “The S In IoT Stands For Security“.

Of course, I agree with Chris about his three problem areas:

  1. Lack of industry knowledge
  2. Developer’s lack of security knowledge and understanding
  3. Time to market pressure, particularly as it exists for startups

I don’t think one can argue with these; in fact, these problems have been and continue to be pervasive, well beyond and before the advent of IoT. Still, I would like to add two more points to Chris’ explanation of the problem space, if I may add to what I hope will be an ongoing and lively conversation within the security industry?

First, IoT products are not just being produced at startups; big players are building IoT, too. Where we place sensors and for what purposes is a universe of different solutions, all the way from moisture sensors in soil (for farming), through networkable household gadgets like light bulbs and thermostats, to the activity monitor on a human’s wrist, to wired up athletes, to the by now famous, mirai botnet camera.

Differing use cases involve varying types and levels (postures) of security. It is a mistake to lump these all together.

When at Intel, I personally reviewed any number of IoT projects that involved significant security involvement, analysis, and implementation. I’m going to guess that most of the major activity monitoring server-side components should have had quite a lot of basic web and cloud security in-built? At least for some products, interaction between the device (IoT sensor) and any intermediary device, like a smart phone or personal computer, has also been given some significant security thought – and it turns out, that this is an area where security has been improving as device capabilities have grown.

It’s hard to make an all out statement on the state of IoT security, though I believe that there are troublesome areas, as Chris points out, most especially for startups. Another problem area continues to be medical devices, which have tended to lag badly because they’ve been produced with more open architectures, as has been presented at security conferences time and again. Then, there’s the Jeep Wrangler remote control hack.

Autonomous autos are going to push the envelop for security, since it’s a nexus between machine learning, big (Big BIG) data, consumer convenience, and physical safety. The companies that put the cars together are generally larger companies, though many of these do not lead in the cyber security space. Naturally, the technology that goes into the cars comes from a plethora of concerns, huge, mid-sized, tiny, and startup. Security consciousness and delivery will be a range from clueful to completely clueless across that range. A repeating problem area for security continues to be complex integrations where differing security postures are pasted together without sufficient thought about how interactions are changing the overall security of the integrated system.

Given the foregoing, I believe that it’s important to qualify IoT somewhat, since context, use case, and semantics/structure matter.

Next, and perhaps more important (save the most important for last?) are the economics of development and delivery. This is highlighted best by the mirai camera: it’s not just startups who have pressure. In the camera manufacturer’s case (as I understand it) they have near zero economic incentive to deliver a secure product. And this is after the mirai attack!

What’s going on here? Importantly, the camaras are still being sold. The access point with a well-known, default password is presumably still on the market, though new cameras may have been remediated. Security people may tear their hair out with an emphatic, “Don’t ever do that!” But, consider the following, please.

  • Product occurs distant (China, in this case) from the consumption of the product
  • Production and use occur within different (vastly different, in this case) legal jurisdictions
  • The incentive is to produce product as cheaply as possible
  • Eventual users do not buy “security” (whatever that means to the customer) from the manufacturer
  • The eventual user buys from manufacturer’s customer or that customer’s customer (multiple entities between consumer and producer)

Where’s the incentive to even consider security in the above picture? I don’t see it.

Instead, I see, as a Korean partner of a company that I once worked for said about acquiring a TCP/IP stack, “Get Internet for free?” – meaning of course, use an open source network stack that could be downloaded from the Internet with no cost.

The economics dictate that, manufacturer download an operating system, usually some Linux variant. Add an working driver, perhaps based upon an existing one? Maybe there’s a configuration thingy tied to a web server that perhaps, came with the Linux. Cheap. Fast. Let’s make some money.

We can try to regulate this up, down, sideways, but I do not believe that this will change much. Big companies will do the right thing, and charge more proportionately. Startups will try to work around the regulations. Companies operating under different jurisdictions or from places where adherence is not well policed or can be bribed away will continue to deliver default passwords to an open source operating system which delivers a host ripe for misuse (which is what mirai turns out to be).

Until we shift the economics of the situation, nothing will change. In the case of mirai, since the consumer of the botnet camera was likely not affected during that attack, she or he will not be applying pressure to the camera manufacturer, either. The manufacturer has little incentive to change; the consumer has little pressure to enforce via buying choices.

By the way, I don’t see consumers becoming more security knowledgeable. Concerned about digital security? Sure. Willing to change the default password on a camera or a wifi router? Many consumers don’t even go that far.

We’re in a bind here; the outlook does not look rosy to me. I open to suggestions.

Thanks, Chris, for furthering this discussion.

cheers,

/brook

RSA 2017: 5 Opportunities!

Posted on by

I feel incredibly grateful that RSA Conference 2017, Digital Guru and IOActive have given me so many opportunities this year to share with you, to meet you.

I will speak about the hard earned lessons that I (we’ve) gained through years of threat modeling programmes and training on Wednesday morning, February 15th. The very same day, I will give a shortened version of the threat model class that I, along with a couple of Intel practitioners, have developed. And Justin Cragin, Intel Principal Engineer and cloud guru, and I will share some of our thoughts on DevOps as a vehicle for product security on Thursday morning (see below for the schedule).

IOActive have asked me to participate in a panel discussion Tuesday afternoon at 3PM at their usual RSA event, “IOAsis“, at Elan on Howard Street, across from Moscone West. I believe that you may need to register beforehand to attend IOAsis. IOActive’s programme is always chock full of interesting information and lively interchange.

Finally, once again, I’ll sign books at 2PM on Wednesday in front of the Digital Guru official RSA bookstore. In the past, it’s been located in the South Lobby of Moscone during the RSA conference. One doesn’t need a pass to get to the book store. Please stop by just to say “hi”; book purchase not required, though, of course, I’m happy to personally sign copies of my books.

Follows, my RSA talks schedule:

Tuesday

3:00 P.M. PST – Security Plan Development: Move to a Better Security Reality
Presented by: Brad Hegrat, IOActive
IOAsis, Elan Event Venue 
Talk Description

Wednesday

Session ID

Title

Room

Start Time

End Time

AIR-W02

Threat Modeling the Trenches to the Clouds

Marriott Marquis | Yerba Buena 8

8:00 AM

8:45 AM

LAB3-W04

Threat Modeling Demystified

Moscone West | 2022

10:30 AM

12:30 PM

Book Signing, RSA Bookstore 2-2:30P

Thursday

Session ID

Title

Room

Start Time

End Time

ASD-R03

DevSecOps: Rapid Security for Rapid Delivery

Moscone West | 2005

9:15 AM

10:00 AM

Prevoty Make Important Points

Posted on by

In a blog post published today, Prevoty make a couple of key points:

“Application security is a people and economics issue. Developers are experts at building value — not security. Security teams are experts at security, but not code development. It is inefficient to ask developers to be security experts and vice versa. On top of that, our market suffers from a draught of both developers and security practitioners. How do we bridge that gap?”

Prevoty, of course, are trying to sell their product.

But that should not make us shy away from the painful truth of the problems that we face. Focusing tightly on vulnerability, in the absence of the context and impact that help us assess risk, is a continuing mistake. Which is at least partly, in my very humble opinion, why “Security teams are experts at security, but not code development”, as Prevoty put it.

If security people continue to scream about “vulnerabilities in your code”, developers will continue to experience that shouting as noise that must be blocked out in favor of helpful information and productive interchange. Which leads to the corollary truism, “Developers are experts at building value — not security.” If security people are seen as some sort of distracting noise, how will developers ever gain enough insight and skill to produce secure designs, which are then securely coded? Short answer: they haven’t and won’t unless security people change the way that they approach the problem.

I’ve proposed “developer-centric security” as a mindset, because, though of course secure design and secure implementation are a technical problem, ultimately, as Prevoty point out, people and economics must be attended to.

Software security people might consider working for a while as a developer. My 15 years (or so) as a developer, designer, lead designer have profoundly influenced the way that I execute software security, the way that I build software security programs. Further, developers will listen to me because I can speak their language and because I understand their problems. This is not just true for me, but for many of the hundreds of security architects whom I’ve taught, coached, and mentored over the years.

Software security is an interaction between the building of software (development community) and the practice of digital security (security practitioners). Acting as though you’re a SWAT team parachuting into a war zone will not help! You are likely to get active resistance. Don’t do it.

Don’t walk in and declare to a hard working development team that they have made a million errors; nobody likes their baby to be shredded. Remember that without developers’ careful execution, you’ve got what we have: mountains of exploitable conditions actively being exploited for every purpose imaginable, and then some. Ergo, the current situation.

cheers,

/brook

Finally Making JGERR Available

Posted on by

Originally conceived when I was at Cisco, Just Good Enough Risk Rating (JGERR) is a lightweight risk rating approach that attempts to solve some of the problems articulated by Jack Jones’ Factor Analysis Of Information Risk (FAIR). FAIR is a “real” methodology; JGERR might be said to be FAIR’s “poor cousin”.

FAIR, while relatively straightforward, requires some study. Vinay Bansal and I needed something that could be taught in a short time and applied to the sorts of risk assessment moments that regularly occur when assessing a system to uncover the risk posture and to produced a threat model.

Our security architects at Cisco were (probably still are?) very busy people who have to make a series of fast risk ratings during each assessment. A busy architect might have to assess more than one system in a day. That meant that whatever approach we developed had to be fast and easily understandable.

Vinay and I were building on Catherine Nelson and Rakesh Bharania’s Rapid Risk spreadsheet. But it had arithmetic problems as well as did not have a clear separation of risk impact from those terms that will substitute for probability in a risk rating calculation. We had collected hundreds of Rapid Risk scores and we were dissatisfied with the collected results.

Vinay and I developed a new spreadsheet and a new scoring method which actively followed FAIR’s example by separating out terms that need to be thought of (and calculated) separately. Just Good Enough Risk Rating (JGERR) was born. This was about 2008, if I recall correctly?

In 2010, when I was on the steering committee for the SANS What Works in Security Architecture Summits (they are no longer offering these), one of Alan Paller’s ideas was to write a series of short works explaining successful security treatments for common problems. The concept was to model these on the short diagnostic and treatment booklets used by medical doctors to inform each other of standard approaches and techniques.

Michele Guel, Vinay, and myself wrote a few of these as the first offerings. The works were to be peer-reviewed by qualified security architects, which all of our early attempts were. The first “Smart Guide” was published to coincide with a Summit held in September of 2011. However, SANS Institute has apparently cancelled not only the Summit series, but also the Smart Guide idea. None of the guides seem to have been posted to the SANS online library.

Over the years, I’ve presented JGERR at various conferences and it is the basis for Chapter 4 of Securing Systems. Cisco has by now, collected hundreds of JGERR scores. I spoke to a Director who oversaw that programme a year or so ago, and she said that JGERR is still in use. I know that several companies have considered  and/or adapted JGERR for their use.

Still, the JGERR Smart Guide was never published. I’ve been asked for a copy many times over the years. So, I’m making JGERR available from here at brookschoenfield.com should anyone continue to have interest.

cheers,

/brook schoenfield