Author: Dr. Philip Cao

Dr. Philip Cao (aka #DrPC), EDBA, MSCS, ZTX-I, CCISO, CISM, CMSC, CCSP, CCSK, CASP, GICSP, PCSPI is a Strategist, Advisor, Educator, Contributor and Motivator. He’s also a Cyber | Zero Trust Strategist & Evangelist and Chief Trust Officer. He has 24 years’ experience in IT/Cybersecurity industry in various sectors & positions.
Posted on

The Cybersecurity Canon: Secrets and Lies

For the past decade, I have held the notion that the security industry needs a Cybersecurity Canon: a list of must-read books where the content is timeless, genuinely represents an aspect of the community that is true and precise and that, if not read, leaves a hole in a cybersecurity professional’s education.

If you’d like to hear more about my Cybersecurity Canon idea, take a look at the presentations I made at this year’s RSA Conference and at Ignite 2014. As always, I love a good argument, so feel free to let me know what you think.

The Cybersecurity Canon: Secrets and Lies: Digital Security in a Networked World (2000) by Bruce Schneier

Secrets and Lies: Digital Security in a Networked World is the perfect book to hand to new bosses or new employees coming in the door who have not been exposed to cybersecurity in their past lives*. It is also the perfect book for seasoned security practitioners who want an overview of the key issues facing our community today. Schneier wrote it more than a decade ago, but he talks about a variety of ideas so ahead of their time that they are still relevant today. Concepts he touches on include:

  • The idea that “security is a process, not a product.” With that one line, Schneier captures the essence of what our cybersecurity community should be about.
  • No matter how advanced security technology becomes, people are the still the weakest link in the security chain.
  • The cyber-adversary as something more than just a hacker.
  • Making the Internet more secure by strengthening confidentiality, integrity, and availability (CIA), as well as improving Internet privacy and anonymity.
  • Challenging the idea that security practitioners must choose between security and privacy.
  • Holding software vendors accountable for security risks in their code.
  • The need for a Bitcoin-like capability long before Bitcoin became popular.

The content within Secrets and Lies is a good introduction to the cybersecurity community, and Schneier tells the story well.

The Story

Secrets and Lies demonstrates Schneier’s evolution as an early thought leader in the cybersecurity community and outlines some key concepts that are still valid today.

Security Is a Process

In the preface, Schneier freely admits to thinking in his earlier life that cryptology would solve all of our Internet security problems. In Secrets and Lies, however, he is forced to acknowledge upfront that technology by itself does not even come close to solving these problems. You do not get security out of a box. You get security by applying people, process, and technology to a problem set, and the more complex we make things, the more likely it is that we are going to screw up the process.

People Are the Weakest Link

The weak link in all of this is the people. You can have the best tools on the planet configured to defend your enterprise, but if you do not have the qualified people to maintain them and to understand what the tools are telling you, you have probably wasted your money. This goes hand in hand with the user community, too. It doesn’t matter that I spent a gazillion dollars on Internet security this year if the least-security-savvy people on your staff take their laptops home and unwittingly install malcode on their machines.

Risk

When it comes to business risk, cybersecurity isn’t its own category separate from more traditional risks. What I have noticed in my career is that many security-practitioners and senior-level company leaders treat “cyber risk” as a thing unto itself and throw the responsibility for it over to the “IT guys” or to the “security dorks.” In my mind, this is one of our community’s great failures. It is up to all of us to convey that essential idea to senior leadership in our organizations.

Software Liability

Every new piece of software deployed has the potential to expose additional threats to the enterprise in terms of new vulnerabilities, and vendors have no liability for this. In other industries, if a vendor were to produce a defective product that causes monetary damage to a company, that company would most likely sue that vendor with a high probability of success in court. It is not like that in the commercial software business or even in the open-source movement. Vendors will patch their systems for sure, but they accept no responsibility for, let’s say, hackers stealing 400 million credit cards from a major retail chain. Schneier is aghast at this development that the user community has let vendors get away with this stance.

Adversary Motivations

Secrets and Lies was the first time that I had seen an author characterize the adversary as a person or a group with motives and aspirations.

“Adversaries have varying objectives: raw damage, financial gain, information, and so on. This is important. The objectives of an industrial spy are different from the objectives of an organized-crime syndicate, and the countermeasures that stop the former might not even faze the latter. Understanding the objectives of likely attackers is the first step toward figuring out what countermeasures are going to be effective.”

This was a revelation to me. At this point in my career, I just thought “hackers” were trying to steal my stuff. This is Schneier’s first cut of a complete adversary list:

  • Hackers
  • Lone Criminals
  • Malicious Insiders
  • Industrial Espionage Actors
  • Press
  • Organized Criminals
  • Police
  • Terrorists
  • National Intelligence Organizations
  • Info warriors

In my work, I have found it useful to refine Schneier’s list of people into the following adversary motivations:

  • Cyber Crime
  • Cyber Espionage
  • Cyber Warfare
  • Cyber Hactivism
  • Cyber Terrorism
  • Cyber Mischief

The bottom line is that these adversaries have a purpose, and it helps network defenders if they understand what kind of adversaries are likely to attack the defender’s assets.

Things Stay the Same

Sadly, even though Schneier published Secrets and Lies in 2000, all of these things are still true, and there is no real solution is sight. Many organizations still think that installing the latest shiny security toy to hit the market will make their networks more secure. They don’t stop to think that they might be better off if they just made sure that the toys they already have installed on their network worked correctly.

People are still the weak link both in the security operations center (SOC) and in the general user community. As I have written elsewhere, talented SOC people are hard to come by, and many organizations still spend resources on robust employee-training programs, but the results are mixed at best.

CISOs are still struggling to convey the security risk message to the C-Suite. Most of us came up through the technical ranks and think colorful bar charts about the numbers of systems that have been patched are pretty cool. The CEO couldn’t care less about those charts and instead wants to know what the charts mean in terms of material risk to the business.

Finally, software vendors still have no liability when it comes to deploying faulty software that results in monetary loss to a customer. This just seems to be something we have all accepted, that it is much better to build a working piece of code first and then worry how to secure it later. I know entrepreneurs prefer this method because the alternative slows the economic engine down if developers spend time adding security features to a new product that drives no immediate revenue opportunities. But this is the great embarrassment to the computer science field: we have not eradicated bugs like buffer overflows in modern code. How is it possible that we can send people to the moon but we cannot eliminate buffer overflows in code development? Don’t get me wrong; the industry has made great strides in developing tools and techniques in these areas—just look at the Building Security in Maturity Model (BSIMM) project to see for yourself. But the fact that, as a cybersecurity community, we have not made it mandatory to use these techniques is one of the reasons we are still often considered a “field of study.”

What We Need

In the end, Schneier makes the case for things that the cybersecurity community needs in order to make the Internet more secure. Long before the acronym became a staple on Certified Information Systems Security Professional (CISSP) exams, he advocated the need to strengthen confidentiality, integrity, and availability (CIA). He does not call it CIA in the book, but he talks at length about the concepts. He was prescient in his emphasis on the need for Internet privacy and Internet anonymity and was one of the first thought leaders to start asking the question about security versus privacy in terms of government surveillance. He also anticipated the need for a Bitcoin-like capability long before Bitcoin became popular.

The Tech

Unfortunately, when you begin to write a technology book about the current state of the art surrounding cybersecurity, much of what you write about is already outdated as you go to press. As I was rereading Schneier’s book, I chuckled to myself when he referenced his blindingly fast Pentium III machines running Windows NT. The world has indeed changed since 2000.

Schneier wrote Secrets and Lies at the time when the industry had just accepted that a stateful inspection firewall was not sufficient to secure the enterprise.

“Today’s firewalls have to deal with multimedia traffic, downloadable programs, Java Applets, and all sorts of weird things. A Firewall has to make decisions with only partial information: It might have to decide whether or not to let a packet through before seeing all the packets in transmission.”

Besides firewalls, he describes other controls that the cybersecurity community has decided are necessary to secure the perimeter, such as demilitarized zones (DMZs), virtual private networks (VPNs), application gateways, intrusion detection systems, honeypots, vulnerability scanners, and email security. Since the book’s publication, security vendors have added even more tools to this conga line, tools like URL filters, Doman Name System (DNS) monitoring, sandboxing technology, security incident and event management systems (SIEMS), and protocol capture and analysis tools.

As of May 2014, the cybersecurity community is mounting a bit of a backlash against the vendor community’s conga line strategy. Practitioners simply can’t manage it all. The best and most recent example of this is the Target data breach. Like many of us, the Target security team installed the conga line of security products and even had a dedicated SOC to monitor them. According to published reports, the controls dutifully alerted the SOC that a breach was in progress but there was apparently so much noise in the system (and perhaps Target’s process was not as efficient as it could be) that nobody in the organization reacted to the breach until it was too late. It’s a perfect example of why many organizations are looking for simpler solutions rather than continuing to add new tools to the security stack.

Cryptology

According to Schneier, underlying everything is cryptology. As you would expect from a cryptologist, Schneier believes that his field of study is the linchpin of the entire idea of Internet security.

“Cryptography is pretty amazing. On one level, it’s a bunch of complicated mathematics. On another level, cryptography is a core technology of cyberspace. In order to understand security in cyberspace, you need to understand cryptography. You don’t have to understand the math, but you have to understand its ramifications. You need to know what cryptography can do, and more importantly, what cryptography cannot do.”

I agree. (Note: The difference between the terms cryptography, cryptanalysis, cryptology, and cryptologist is left as an exercise for the reader.) I would say that the cybersecurity community has failed in this regard. While it is true that cryptography is the underlying technology that makes it possible to secure the Internet, it is still too complicated for the general user to leverage. In light of the Edward Snowden revelations —that we not only have to worry about foreign governments spying on our electronic transmissions, but we also have to worry about our own government doing it—the fact that most people do not know how to encrypt their own email messages as a matter of course is a testament to our industry’s failure.

Kill Chain

Schneier makes a distinction between computer and network security, that the conga line of security tools that make up the security stack at the network perimeter is not the same as the set of tools you need to secure the endpoint. While this is still true today, the cybersecurity community has merged these two ideas together since Schneier’s book was published.

The thought is that it does not make sense to consider network and endpoint security separately; it makes more sense to think of everything as a system, as we do at Palo Alto Networks. As organizations develop indicators of compromise at both the network and endpoint layers, essentially the Kill Chain model, the cybersecurity community can develop advanced adversary profiles about the attacker’s campaign plan.

In conclusion, the ideas Schneier examines in Secrets and Lies were years ahead of their time.  They show the cybersecurity industry just how far we have come and how far we still have to go. Because of this, Secrets and Lies is a candidate for the cybersecurity canon, and you should have read it by now.

*Full disclosure: The first civilian job I took after I retired from the US Army was with the company that Bruce Schneier founded called Counterpane, so I may be a little biased. 

[Source: ]

Posted on

CVE-2014-1776: How Easy It Is To Attack These Days

This post originally appeared on Cyvera.com.

Just about a week ago, everyone was alarmed due to a new zero-day vulnerability affecting Internet Explorer 6 through 11. The vulnerability was used in attacks in the wild, which targeted IE 8 to IE 11. The impact was so severe that Microsoft hurried to issue an out-of-band patch. Today, I would like to show how relatively easy it is to attack these days, when you can just reuse code.

We will compare the attack that used CVE-2014-0322 (then, an IE zero-day) to the current attacks utilizing CVE-2014-1776. We will show an almost exact match between the two templates for the attacks, indicating that either the same group was behind the two campaigns, or that the ease of acquiring used exploit code (even from public sources) allows different groups to quickly reuse and adapt the same code to the next vulnerability.

Overview

Both attacks utilize use-after-free vulnerabilities in IE, and leverage Flash Player in order to easily bypass DEP and ASLR. In both cases the scheme is the same:

  • Load a Flash SWF file.
  • Spray the heap with ActionScript uint vector objects with 0x3FE elements, for a total of 0×1000 bytes (i.e., 1 page) of memory for each vector object (including the vector’s management information, which should be inaccessible directly from the ActionScript code).
  • Spray the heap with references to a Sound object, to be used later as the first trigger to the shellcode.
  • Call a JavaScript function in the HTML page and set a timer to invoke another AS function.
  • Trigger a UAF vulnerability using the JavaScript code, while spraying the heap in order to ensure that the used block is controlled.
  • Use the bug to change an AS vector’s size (which is inaccessible directly from AS).
  • Back in the timed function in the SWF, use the modified vector to change an adjacent vector’s size to encompass all virtual memory, effectively achieving full memory disclosure and writing abilities (where current permissions allow that).
  • Find a module in memory and reach NTDLL by hopping through modules’ import address tables.
  • Find a stack pivoting gadget in NTDLL as well as the address of ZwProtectVirtualMemory.
  • Overwrite the virtual function table pointer of the Sound object to initiate code execution by calling the Sound object’s (replaced) toString function. Then, use a few ROP gadgets to pivot the stack, change the permissions on the shellcode to RWX, and execute the shellcode.
  • Restore normal operation.

There are, however, some improvements in this CVE-2014-1776 attack over the CVE-2014-0322 attack. For example, while all the hard work is crammed into one big function in the CVE-2014-0322 attack, the authors of the CVE-2014-1776 attack strove for cleaner code and broke the huge pile of code into many smaller functions, which constitute basic primitives for the larger goal. In fact, now it is even easier to reuse this code for the next exploit…

The Flash Spray

In both cases vectors of uints are sprayed (with 0x3FE elements in each vector), as well as references to a Sound object. The values of the uints in the sprayed vectors are constructed so as to fit the address the attacker had chosen and the vulnerability (and the browser, if applicable).

CVE-2014-1776

CVE-2014-0322

The UAF Triggering

In both attacks, the JS code which triggers the vulnerability is called from the ActionScript code, using the external interface. The AS code then registers a function to be invoked at a later time and search for the artifacts of the triggered vulnerability. Although the code performing the actual UAF is almost the same, there are some differences in behavior here:

  • In the current attack, the JS function gets a parameter, which holds JavaScript code that is crucial for the vulnerability to arise. In contrast, in the previous attack, the entire JavaScript code was present in the HTML.
  • In the current attack, the JS code sent to the external function lies encrypted (using RC4) in the SWF file, and is decrypted only prior to sending it to the external interface. Other parts in the SWF (relating to the shellcode) are also encrypted. Consequently, if you only have the HTML file, you cannot reproduce the zero-day (and vice versa). In contrast, the previous attack had no encrypted elements at all.
  • In yet another effort to make sure the zero-day is not compromised even if one file falls into the wrong hands, in the current attack the HTML file was split into two files, the second one containing the JS code used for the heap-spray.

The heap-sprays, though, are very much alike.

CVE-2014-1776

CVE-2014-0322

Memory Ownage

In both cases this is pretty easy – look for the modified length of the vector (that is what the IE vulnerability was used for), use the modified vector to modify the adjacent vector’s length to span all memory, and use the second modified vector for memory read and write operations.

CVE-2014-1776

CVE-2014-0322

Looking for Modules and Functions

This is pretty straightforward – find a module in memory, go backwards to find its base, parse the PE header and look for a function imported from KERNEL32.DLL, repeat the same process to go from KERNEL32.DLL to NTDLL.DLL, and then parse its import table looking for the needed functions. However, the code for the recent attack has one improvement over the older code: The new code uses the Sound object’s vftable to get a function pointer which points inside the Flash OCX, while the older code scans the memory and tries to find an executable image by brute-forcing.

CVE-2014-1776

CVE-2014-0322

Running the Shellcode

In both cases, the Sound object’s vftable pointer is overwritten, pointing to a pre-crafted area in memory. Then, the Sound object’s toString method is called (#28 in the table), which runs a stack pivoting gadget chained to a gadget that uses ZwVirtualProtect on the shellcode, which immediately follows. The shellcode begins by saving information and restoring overwritten values.

CVE-2014-1776

CVE-2014-0322

Summary

We have shown a very high correlation between the exploit code used in the CVE-2014-1776 attack, and the exploit code used in the CVE-2014-0322 attack. Clearly, the same code base was used. Whether this is indicative of the same actor or not, we cannot tell, since all code was freely available on the net when the recent attack commenced.

Looking at the entire SWF file in both cases, it can be seen that some mistakes were made, and some code was copied without actually utilizing it or understanding why it is there. Nevertheless, the high correlation between the two exploits shows how easy it has become to reuse proven code from past exploits when preparing the next attack. This only means that organizations need to stay protected, as sophisticated attacks can be easily copied by teams who don’t possess the knowledge to construct such an attack on their own.

All endpoints on which Cyvera TRAPS was installed were (and are) protected from the CVE-2014-1776 attack: TRAPS stops this in-the-wild exploitation attempt at several different points. Since TRAPS does not rely on signatures or behaviors but on breaking the attacker’s core techniques, TRAPS stops even zero-day attacks (including this one) without any need for updates. Of course, TRAPS users were also protected from the CVE-2014-0322 attack.

[Source: Palo Alto Networks Research Center]

Posted on

Best Practices for Defending Against APTs

Advanced persistent threats (APTs) have changed the world of enterprise security and how networks and organizations are attacked. In a new Palo Alto Networks eBook, Cybersecurity for Dummies, we explore:

  • The cybersecurity landscape and why traditional security solutions fail
  • What next-generation security brings to the fight
  • Ten best practices for controlling APTs

Head to our Cybersecurity for Dummies landing page and request your free copy today!

For more on Palo Alto Networks solutions for APTs:

Posted on

Highlights from the NIST Privacy Engineering Workshop

In April, I presented at and attended the NIST Privacy Engineering Workshop on behalf of ISACA.

Throughout two days of sessions, attendees explored the Fair Information Practice Principles, privacy/technology research efforts, and the need to address privacy risks—to consider privacy from the planning stage of projects and close the longstanding communications gap between legal and engineering areas.

We joined breakout sessions to discuss the frameworks engineers use, explore privacy case studies, and determine ways in which engineering methods can address privacy risks. On day two of the event we focused on drone use, which prompted some lively, thought-provoking discussions.

My takeaways from the workshop:

  • Huge gaps in communication between the engineering areas and legal/policy areas need to be closed. Each group needs to listen to the other when it comes to privacy discussions. Each side has much to learn from the experiences of the other.
  • Privacy engineering is much more than a policy issue and much more than just getting software or systems to meet existing legal requirements for data protection. Because those laws/regulations were created in a reactionary atmosphere, they will always lag behind a significant number of new and emerging privacy risks. Engineers will be key in mitigating those privacy risks through the use of an effective privacy-engineering framework, and through the use of a catalog of vetted and reasonable privacy-use cases.
  • Engineers already have frameworks they have used for many years to build software and systems. Instead of trying to get them to use something completely different, efforts should be made to establish privacy standards that are integrated within these established frameworks, written in language appropriate for engineers.
  • Privacy engineering is not just for large organizations. There are many small and mid-size organizations that create software and systems; they must also know how to engineer privacy into their products. Often there is an even greater need for such organizations to practice privacy engineering for all the software and systems they create.

Naomi Lefkovitz, NIST senior privacy policy advisor who presided over the two-day event, indicated that NIST plans to produce a report based on the information, recommendations and comments collected during the workshop. NIST will host further workshops to refine what will likely become the privacy portion of the Cybersecurity Framework.

I found this workshop beneficial—an important first step toward identifying actionable privacy standards to include within the Cybersecurity Framework, which engineers will be able to effectively utilitize within their current frameworks to help build in the (currently missing) controls that are needed to help to protect privacy.

Rebecca Herold, CISM, CISA, CISSP, CIPP/US, CIPP/IT, CIPM, FLMI
CEO, The Privacy Professor®

[Source: ISACA]

Posted on

Building a Security Culture

Last month I had the great pleasure to speak at the 2014 ISACA Nordic Conference, where I shared my passion for security culture and how to build it.

In my view, security culture is, simply, about building and maintaining measures to help your employees feel safe and free from danger.

But let’s back up a bit to get a clearer picture. It helps to understand the origins of this culture. In this sense, culture is the collected security information in a society that is passed from one generation to the next. It can consist of norms, knowledge, tools, etc.

Naturally, this culture can be modified and transformed to suit each organization. Norms—the regulations, policies and other rules (written or not) that regulate how people in your organization function, from when and how they drink coffee to how they interact with their passwords—are malleable. They work best when they are adjusted for each enterprise and each situation.

Tools used with computers, information systems and software are most commonly considered “technology.” Much like their ancestors, such as the hammer, technology tools make it easier to reach a goal, such hammering a nail or ensuring proper security within a system.

Knowledge is the third piece of the puzzle, binding technology and norms together. Knowledge guides people in interacting with technology in the right manner. Knowledge enables people to understand why norms force them to do things according to the rules.

Culture is a critical part of society. It helps define a people. This holds true within the narrower scope of security culture. By taking what you have already—technology and norms—and adding knowledge to your organization, you are moving in the right direction. You are moving to a security culture.

Kai Roer
President of Cloud Security Alliance Norway Chapter
Founder of the Security Culture Framework
Member of the Security Culture Framework Community

[Source: ISACA]

English
English
Exit mobile version