Foreword (Lesley)

One of the hardest things to accept in information security is that we as individuals will simply never know everything there is to know about the field, or all of its many niches. Despite this absolute reality, we still often feel embarrassed to ask basic questions about topics we don’t understand, due to a misplaced fear of looking unknowledgeable.

The reality is that there are a number of subjects in information security which many people who are otherwise quite competent professionals in the field are confused by. To try to alleviate this problem, I anonymously polled hundreds of infosec students and professionals about what topics they’re still having trouble wrapping their heads around. A few subjects and concepts rose to the top immediately: Blockchain, the Frida framework, DNSSEC, ASLR (and various associated bypasses), and PKI.

Since information security has many areas of specialty, I’ve stepped aside today and asked people specifically working in each niche to tackle breaking down these topics. Where possible, I have provided two perspectives from people with different experiences with the subject matter. Each of these contributors was tremendously generous with his or her time and knowledge. Please visit their social media profiles and personal blogs!

ASLR (Skip Duckwall and Mohamed Shahat)

Perspective One: Skip

1) This is a pretty tough topic, so let’s start with an easy one. Can you tell us a little about yourself, and your expertise related to ASLR / ASLR bypassing?

Yikes, ask the easy ones first, eh?  I’m a former DOD Red team member (contractor) who did some stuff to some things somewhere at some point in time.  My biggest life achievement is being part of a group which got a multi-billion dollar MS client pissed off enough to call MS to the carpet and eventually MS wrote a whitepaper.  Now I’m a consultant.  My experiences with ASLR, etc are mostly from a “I have to explain why these are things to C-level folks and why they should care” standpoint.

2) ASLR bypasses are common in security news, but a lot of infosec folks don’t fully understand what ASLR does, and why bypassing it is a goal for attackers. Can you please give us a “500-words-or-less” explanation of the concepts? (Assume an audience with solid IT fundamentals)

Caveat:  This is a very technical question and in order to answer it in an easy to understand manner, I have to provide some background and gloss over a lot of very pertinent details.  My goal is to provide a GIST and context, not a dissertation ;-).
Ok, while I can assume people have solid IT fundamentals, I need to define a Computer Science fundamental, namely the concept of a stack.  A stack is a conceptual (or abstract) data structure where the last element in is the first element out (LIFO).  You put stuff into a stack by “pushing” it and you pull stuff out by “popping” them.  The wikipedia page for a stack (https://en.wikipedia.org/wiki/Stack_(abstract_data_type) ) is a good read.
This is relevant because stacks are used extensively as the means for an operating system to handle programs and their associated memory spaces.  Generally, the memory associated with a process has three areas (arranged in a stack), namely the Text area (generally the program’s machine code), the data area (used for static variables), and the process stack, which is used to handle the flow of execution through the process.  When a process executes and hits a subroutine, the current information for the process (variables, data, and a pointer to where the execution was last at) gets pushed onto the process stack.  This allows the subroutine to execute and do whatever it needs to do, and if further subroutines occur, the same thing happens.  When the subroutine is finished, the stack gets popped and the previous execution flow gets restored.

One of the earliest types of attacks against programming mistakes was called ‘stack smashing’ (seminal paper here: http://www-inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf by Aleph One).  In this kind of attack, the attacker would try to stuff too much information into a buffer (a block of data which sits on the process stack) which would overwrite the stack pointer and force the process to execute attacker-generated code included in the buffer.  Given the generally linear nature of how the stacks were handled, once you found a buffer overflow, exploiting it to make bad stuff happen was fairly straightforward.

ASLR (Address Space Layout Randomization) is an attempt to make the class of bugs called buffer overflows much more difficult to exploit.  When a process executes, it is generally given virtual memory space all to itself to work with.  So the idea was, rather than try to have all the process stack be clumped together, what if we just spread it out somewhat randomly throughout the virtual memory space?  This would mean that if somebody did find a buffer overflow, they would not know where the stack pointer was in order to affect the flow of the process and inject their code, raising the bar for attackers. (in theory)

Obviously bypassing ASLR is a goal for attackers because it is a potential gate barring access to code execution 😉

3) What are two or three essential concepts for us to grasp about ASLR and the various  bypass techniques available?

So when it comes to ASLR bypasses there are really only a couple different categories of methods, brute force or information leakage.

In many cases, ASLR implementations were limited somehow.  For example, maybe there were only 16 bits (65535) of randomness, so if you were trying to exploit a service which would automatically restart if it crashed, you could keep trying until you got lucky.  Many ASLR implementation suffer from some problem or another.

Another common problem with ASLR is that there may be segments of code which DON’T use ASLR (think external libraries) which are called from code that is using ASLR. So it might be possible to jump into code at a well known location and then leverage that to further exploit.

Information leakage is the final issue that commonly arises.  The idea is that a different vulnerability (format string vulns are the most common) has to be exploited which will provide the attacker with a snapshot of memory, which can be analyzed to find the requisite information to proceed with the attack.

4) What would you tell somebody in infosec who’s having trouble grasping how ASLR works and how it is bypassed? (For example, what niches in security really need to “get it”? What other things could they study up on first to grasp it better?)

Honestly, unless you are an exploit developer, an application developer, or into operating systems memory design, a gist should be all you need to know. If you are a developer, there’s usually a compiler option somewhere which you’d need to enable to make sure that your program is covered. It is also worth noting that generally 64-bit programs have better ASLR because they can have more randomness in their address space.

5) What about somebody who has a solid grasp on the basics and wants to delve deeper? (Any self-study suggestions? Are there any open source projects that could benefit from their help?)

This topic rapidly reaches into the computer science scholarly paper area (Googling ASLR bypass pdfs will find you a lot of stuff). Also, look through Blackhat / DEF CON / other security conference archives, as many people will present their research. If you want to delve deeper, look into how the Linux kernel implements it, read through the kernel developer mailing lists, etc… lots of info available.

Perspective 2: Mohamed

1) Thank you for joining us! Would you mind telling us a little about yourself, and your expertise related to ASLR / ASLR bypassing?

Hi Lesley! My name is Mohamed, I’m a software engineer who has a lot of passion towards security. Some may know me from my blog (abatchy.com) where I write about various security concepts/challenges.

I currently work as an engineer on the Windows Security team where we design/implement security features and do other cool stuff.

2) ASLR bypasses are common in security news, but a lot of infosec folks don’t fully understand what ASLR does, and why bypassing it is a goal for attackers. Can you please give us a “500-words-or-less” explanation of the concepts? (Assume an audience with solid IT fundamentals)

Address space layout randomization (ASLR) is a security mitigation that aims to prevent an attacker from creating a reliable exploit. Its first implementation was over a decade and it became a stable in modern operating systems.

What it does is simple, the address space of a process is randomized on rerun/reboot depending on the implementation, this can be applied to the base address of the executable and libraries it loads as well as other data structures like the stack and the heap among other internal structures as well as the kernel (KASLR).

Executables are expected to be position-independent. In Windows, linking must be done with /DYNAMICBASE flag, while Linux requires -fPIE as a flag for gcc/ld.

How does that help? Well, exploits rely on knowledge about the address space to be able to manipulate the execution flow (I control EIP, where do I go next?) and with this information taken away, attackers can no longer depend on predictable addresses. When combined with other fundamental mitigations like DEP (Data Execution Prevention), exploiting memory corruption bugs becomes much harder.

Before we discuss the common bypassing techniques, it’s important to stress on that bypassing ASLR doesn’t directly enable code execution or pose a risk by itself as this is only a part of the exploit chain and you still need to trigger a vulnerability that results in code execution. Yet, finding an ASLR bypass mean that broken exploits can utilize that bypass again.

There are a few ways to bypass ASLR, some of these techniques are less likely to be applicable in modern OS/software than others:

1.  Information Disclosure: Most commonly used method to bypass ASLR nowadays, the attacker aims to “trick” the application into leaking an address.
   

   Example: CVE-2012-0769

2.  Abusing non-ASLR modules: The presence of a single non-ASLR module means an attacker has a reliable place to jump to. Nowadays, this is becoming less common.
   

   Example: CVE-2013-3893, CVE-2013-5057

3.  Partial overwrite: Instead of overwriting EIP, overwrite the lower bytes only. This way you don’t have to deal with the higher bytes affected by ASLR.
   

   Example: CVE-2007-0038

4. Brute-forcing: Keep trying out different addresses. This assumes that the target won’t crash, and the virtual memory area is small (ASLR on 64-bit > ASLR on 32-bit).
   

   Example: CVE-2003-0201

5. Implementation flaws: Weak entropy, unexpected regression, logical mistakes or others. Lots of great research on this topic.
   

   Example: CVE-2015-1593, offset2lib

   In real world, attackers will need to bypass more than just ASLR.

3) What are two or three essential concepts for us to grasp about ASLR and the various bypass techniques available?

1. For ASLR to be efficient, all memory regions within a process (at least the executable ones) must be randomized, otherwise attackers have a reliable location to jump to. It’s possible that not all objects are randomized with the same entropy (randomization), in a way the object with the lowest entropy is the weakest link.
2. Bypassing ASLR doesn’t mean attackers can execute code. You still need an actual vulnerability that allows hijacking the execution flow.
3. Some bypasses aim to reduce the effective entropy

4) What would you tell somebody in infosec who’s having trouble grasping how ASLR works and how it is bypassed? (For example, what niches in security really need to “get it”? What other things could they study up on first to grasp it better?)

1. Understand the memory layout of a process for both Linux/Windows, see how they change on rerun/reboot.
2. Write a simple C++ program that prints the address of local variables/heap allocations with and without ASLR. Fire up a debugger and check the process layout of various segments.
3. Research past ASLR vulnerabilities and how they were used to bypass it and recreate them if possible.

5) What about somebody who has a solid grasp on the basics and wants to delve deeper? (Any self-study suggestions? Are there any open source projects that could benefit from their help?)

1. Understand the implementation differences for ASLR in Windows and Linux.
2. Familiarize yourself with other mitigations like DEP, stack cookies (Windows/Linux), AAAS, KSPP (Linux), policy-based mitigations like ACG/CIG (Windows). This list is in no way comprehensive but serves as a good start.
3. Solve exploitation challenges from CTFs, recreate public exploits that rely on bypassing ASLR.
4. Check PaX’s ASLR implementations.

Recommended reads:

1. Differences Between ASLR on Windows and Linux
2. On the effectiveness of DEP and ASLR
3. The info leak era on software exploitation
4. Exploiting Linux and PaX ASLR’s weaknesses on 32- and 64-bit systems

For hands-on experience I recommend the following:

1. RPISEC’s MBE course
2. https://exploit-exercises.com
3. CTFs

Blockchain (Tony Arcieri and Jesse Mundis)

Perspective One: Tony

1) Thanks for joining us. Would you mind telling us a little about your background, and your expertise with blockchain technology?

I’m probably most known in the space for the blog post: “On the dangers of a blockchain monoculture“, which covers both my (somewhat dated) views of blockchains and how alternative “next generation fintech” systems not based on blockchains might provide better alternatives. I spent the last year working for Chain.com, an enterprise blockchain company targeting cryptographic ledgers-as-a-service, which I recently left to pursue other interests.

2) Would you please give us a 500-words-or-less explanation of what a blockchain is, and why the technology is important to us as security professionals? (Assume an audience with solid IT fundamentals)

“Blockchain” is a buzzword which loosely refers to the immutable, append-only log of transactions used by Bitcoin, collectively agreed upon in a distributed manner using a novel consensus algorithm typically referred to as “Nakamoto consensus”. Other systems have adopted some of the ideas from Bitcoin, often changing them radically, but still referring to their design as a “blockchain”, furthering a lack of clarity around what the word actually refers to.

A “blockchain” is more or less analogous to a Merkle Tree with some questionable tweaks by Satoshi[2], which authenticates a batch of transactions which consist of input and output cryptographic authorization programs that lock/unlock stored values/assets using digital signature keys.

Bitcoin in particular uses a proof-of-work function to implement a sort of by-lottery distributed leader election algorithm. Being a buzzword, it’s unclear whether the use of a proof-of-work function is a requirement of a blockchain (the Bitcoin paper refers to the idea of a blockchain as a “proof-of-work chain”, for example), but in colloquial usage several other systems claiming to be based on a “blockchain” have adopted alternative authorization mechanisms, namely ones based around digital signatures rather than a proof-of-work function.

As a bit of trivia: the term “blockchain” does not appear in the original Bitcoin whitepaper. It appears to be a term originally used by Hal Finney prior to Bitcoin which Satoshi adopted from Hal.

[2]: It really appears like Satoshi didn’t understand Merkle Trees very well: https://github.com/bitcoin/bitcoin/blob/master/src/consensus/merkle.cpp#L9

3) What are a couple really critical concepts we should understand with regards to how blockchain technology functions?

Perhaps the most notable aspect of Bitcoin’s blockchain is its use of authorization programs as part of the “Nakamoto consensus” process: every transaction in Bitcoin involves two programs: an input program which has locked funds which will only unlock them if the authorization program’s requirements are met, and an output program which specifies how funds should be locked after being unlocked. Every validating node in the system executes every program to determine whether or not actions affecting the global state of the system are authorized.

This idea has been referred to as “smart contracts”, which get comparatively little attention with Bitcoin (versus, say, Ethereum) due to its restrictive nature of its scripting language, but every Bitcoin transaction involves unlocking and re-locking of stored value using authorization programs. In other words, “smart contracts” aren’t optional but instead the core mechanism by which the system transfers value. If there is one thing I think is truly notable about Bitcoin, it’s that it was the first wide-scale deployment of a system based on distributed consensus by authorization programs. I would refer to this idea more generally as “distributed authorization programs”.

Bitcoin in particular uses something called the “unspent transaction output” (UTXO) model. In this model, the system tracks a set of unspent values which have been locked by authorization programs/”smart contracts”. UTXOs once created are immutable and can only move from an unspent to spent state, at which point they are removed from the set. This makes the Bitcoin blockchain a sort of immutable functional data structure, which is a clean and reliable programming model.

Ethereum has experimented in abandoning this nice clean side effect-free programming model for one which is mutable and stateful. This has enabled much more expressive smart contracts, but generally ended in disaster as far as mutability/side effects allowing for new classes of program bugs, to the tune of the Ethereum system losing the equivalent of hundreds of millions of dollars worth of value.

4) What would you tell somebody in infosec who’s struggling to conceptualize how a blockchain works? (For example, does everybody in the field really need to “get it”? Why or why not? What other things could they study up on to grasp it better?)

There are other systems which are a bit more straightforward which share some of the same design goals as Bitcoin, but with a much narrower focus, a more well-defined threat model, and both a cleaner and more rigorous cryptographic design. These are so-called “transparency log” systems originally developed at Google, namely Certificate Transparency (CT), General Transparency (GT) a.k.a. Trillian, Key Transparency (KT), and Binary Transparency. These systems all maintain a “blockchain”-like append-only cryptographically authenticated log, but one whose structure is a pure Merkle Tree free of the wacky gizmos and doodads that Satoshi tried to add. I personally find these systems much easier to understand and consider their cryptographic design far superior to and far more elegant than what has been used in any extant “blockchain”-based system, to the point I would recommend anyone who is interested in blockchains study them first and use them as the basis of their cryptographic designs.

5) What about somebody who has a solid grasp on the basics and wants to delve deeper? (Any self-study suggestions? Are there any open source projects that could benefit from their help?)

Perspective Two: Jesse

1) Let’s start with the easy one. Would you please tell us a little about your background, and your expertise with blockchain technology?

I’m a C / Unix Senior Software Developer with a CISSP, who has worked with encryption and payment technologies throughout my career. I have a recently published paper on the possible implications of the GDPR (General Data Protection Regulation) on blockchain-based businesses, and have a pending patent application involving cryptographic keying material and cryptocurrencies. As an Info Sec professional, I enjoy the chance to share some knowledge with folks who wish to learn more about the field.

2) Would you please give us a 500-words-or-less explanation of what a blockchain is, and why the technology is important to us as security professionals? (Assume an audience with solid IT fundamentals)

A blockchain is fundamentally a ledger of transactions, with each “block” or set of transactions hashed in such a way as to link it to the previous block, forming a “chain.” There are many blockchains, with varying implementations and design goals, but at their core, they all provide for continuity and integrity of an ever-growing ledger of transactions. They provide an unalterable(*) record of events, in a distributed fashion, verifiable by any participant, and can be an important tool for providing “Integrity” in the CIA triad. The Bitcoin blockchain is the most famous, providing a basis for the BTC currency, so I will use it as a blockchain example. However, please understand that blockchain transactions don’t have to be financial in nature – they could be hashes of timestamped signed documents, or just about anything else you might want to keep an unalterable, witnessed record of.

(*) “unalterable” – In this case means that the network integrity as a whole is only secured by substantial ongoing compute power in a proof-of-work blockchain. Without that, you lose the core assurance the technology is trying to provide.

In the proof-of-work bitcoin blockchain, transactions are effectively of the form “At time Z, wallet number X paid wallet number Y the sum of N bitcoins.” Imagine many of these messages being dumped on a common message bus worldwide. “Miners” (who should more descriptively be thought of as “notaries”) collect up a “block” of these transactions, and along with the digital hash of the previous block in the chain, begin searching for a nonce value, which when added to their block, will make the hash of their block have a required number of leading zeros to be considered successful. The winning miner announces this block with their nonce to the world. All other miners confirm the block is valid, throw their in-progress block away, and begin working on a new block, which must now contain the winning block’s hash, thus adding an other link to the chain.

Checking the hash of a block is trivial, but finding the right nonce to create a valid hash takes time inversely proportional to the miner’s computing power. Once the chain has a sufficiently large number of blocks, each chaining back to the previous block, it becomes impractical to refute, change, or delete any records deep enough in the chain, without re-doing all the computational work which follows. An attacker would require a substantial percentage of the entire computational capacity of the network to do this.

In summary, a “block” is a set or group of transactions or entries plus a nonce, and the “chain” is formed by including the hash of the previous block as part of the next block. The weight of all future computations to find nonces for future blocks collectively secure the integrity of all the previous records in the chain.

3) What are a couple really critical concepts we should understand with regards to how blockchain technology functions?

“Blockchain” is not magical security pixie dust, and many new startup businesses pitching blockchain haven’t thought it through. As mentioned above, proof-of-work blockchains need a lot of compute power to secure them. Bitcoin is a fascinating social hack, in that by making the transactions about a new currency, the algorithm was designed to incentivize participants to donate compute power to secure the network in return for being paid fees in the new currency. On the other hand, private blockchains, kept within a single company may be no more secure against tampering than other existing record keeping mechanisms. That is not to say blockchains are useless outside of cryptocurrencies. The blockchain is applicable to “The Byzantine Generals Problem” [1] in that it can create a distributed, trusted, ledger of agreement, between parties who don’t necessarily trust each other. I fully expect the basics of blockchain technology to soon be taught in CS classes, right alongside data structures and algorithms.

[1] https://www.microsoft.com/en-us/research/publication/byzantine-generals-problem/

4) What would you tell somebody in infosec who’s struggling to conceptualize how a blockchain works? (For example, does everybody in the field really need to “get it”? Why or why not? What other things could they study up on to grasp it better?)

Keep it simple. A block is just a set of entries, and the next block is chained back to the previous block via inclusion of the previous block’s hash. The hash on each individual block is the integrity check for that block, and by including it in the next block, you get an inheritance of integrity. A change in any earlier block would be detected by the mismatched hash, and replacing it with a new hash would invalidate all the later blocks. Hashing is computationally easy, but finding a new nonce to make the altered hash valid in a proof-of-work scheme requires redoing all the work for all the blocks after the change. That’s really all you need to keep in mind.

Everyone in the security field does not need to understand blockchain to any deep level. You should have a basic understanding, like I’ve sketched out above, to understand if blockchain makes sense for your given use case. Again, using the more famous Bitcoin blockchain as an example, I’d strongly recommend everyone read the original 2008 Satoshi white paper initially describing Bitcoin[2]. It’s only eight pages, light on math, and very readable. It encapsulates many of the ideas all blockchains share, but I have to say again that while Bitcoin is implemented on the original blockchain, it is far from the only way to “do blockchains” today.

[2] https://bitcoin.org/bitcoin.pdf

5) What about somebody who has a solid grasp on the basics and wants to delve deeper? (Any self-study suggestions? Are there any open source projects that could benefit from their help?)

Blockchain startups, projects, and new cryptocurrencies are all hot. Ethereum is getting a lot of press due to its “smart contracts” which provide compute actions executed on their blockchain. There are over ten thousand hits on github for “blockchain” right now, and over one hundred and fifty for books and videos at Safari Online. The challenge really is to narrow down your interest. What do you want to do with blockchain technology? That should guide your next steps. Just to throw out some ideas, how about finding a more power efficient way to do proof-of-work? Currently the Bitcoin network as a whole is estimated to be running at about 12 petaHashes per second, and consuming 30 TerraWatt-Hours per year. This is environmentally unsustainable. Or, examine some of the proof-of-stake alt-coins. Figure out what kinds of problems can we solve with this nifty, distributed, trust-out-of-trustlessness tool.

In my opinion, blockchain technologies really are a tool searching for the right problem. An alt-currency was an interesting first experiment, which may or may not stand the test of time. Smart contracts don’t seem ready for production business use to me just yet, but what do I know – Ethereum has a 45 billion dollar market cap, second only to Bitcoin right now. I personally don’t see how inventory tracking within an enterprise is really done better with a private blockchain than traditional methods, but I do see how one might be of use for recording land title deed transfers in a government setting. All of these, and many more activities are having blockchain technologies slapped on to them, to see what works. My advice is to find something which excites you, and try it.

The distributed, immutable ledger a blockchain provides feels like it is an important new thing to me for our industry. Maybe one of you will figure out what it’s really good for.

DNSSEC (Paul Ebersman)

1) Nice to meet you, Paul. Could you please tell us a little about yourself, and a bit about your work with DNSSEC?

I’ve been supporting internet connected servers since 1984, large scale DNS since 1990. I’ve been involved with the IETF development of DNS/DNSSEC standards and the DNS-OARC organization. For 3+ years, I was the DNS/DNSSEC SME for Comcast, one of the largest users of DNSSEC signing and validation.

2) Would you please give us a brief explanation of what DNSSEC is, and why it’s important?

The DNS is used to convert human friendly strings, like http://www.example.com into the IP address or other information a computer or phone needs to connect a user to the desired service.

But if a malicious person can forge the DNS answer your device gets and give you the IP address of a “bad” machine instead of the server you think you’re connecting to, they can steal login information, infect your device with malware, etc.

DNSSEC is a technology that lets the owner of a domain, such as example.com, put cryptographic signatures on DNS records. If the user then uses a DNS resolver that does DNSSEC validation, the resolver can verify that the DNS answer it passes to the end user really is exactly what the domain owner signed, i.e. that the IP address for http://www.example.com is the IP address the example.com owner wanted you to connect to.

That validation means that the user will know that this answer is correct, or that someone has modified the answer and that it shouldn’t be trusted.

3) What are a couple really critical concepts we should understand with regards to how DNSSEC functions?

DNSSEC means that a 3rd party can’t modify DNS answers without it being detected.

However, this protection is only in place if the domain owner “signs” the zone data and if the user is using a DNS resolver that is doing DNSSSEC validation.

4) What would you tell somebody in infosec who’s struggling to conceptualize how DNSSEC works?

DNSSEC is end to end data integrity only. It does raise the bar on how hard it is to hijack the DNS zone, modify data in that zone or modify the answer in transit.

But it just means you know you got whatever the zone owner put into the zone and signed. There are some caveats:

– It does not mean that the data is “safe”, just unmodified in transit.
– This is data integrity, not encryption. Anyone in the data path can
see both the DNS query and response, who asked and who answered.
– It doesn’t guarantee delivery of the answer. If the zone data is DNSSEC signed and the user uses a DNSSEC validating resolver and the data doesn’t validate,the user gets no answer to the DNS query at all, making this a potential denial of service attack.

Because it does work for end to end data integrity, DNSSEC is being used to distribute certificates suitable for email/web (DANE) and to hold public keys for various PKI (PGP keys). Use of DNSSEC along with TLS/HTTPS greatly increases the security and privacy of internet use, since you don’t connect to a server unless DNSSEC validation for your answer succeeds.

5) What about somebody who has a solid grasp on the basics and wants to delve deeper?

Start with the documentation for your DNS authoritative server for information on signing your zones. Similarly, read the documentation for your recursive resolver and enable DNSSEC validation on your recursive resolver (or use a public validating resolver, such as 8.8.8.8 or 9.9.9.9).

Here are some good online resources:

For debugging DNSSEC problems or seeing if a zone is correctly signed: https:/www.dnsviz.com

For articles on DNSSEC: https://www.internetsociety.org/deploy360/dnssec/

PKI (Tarah M. Wheeler and Mohammed Aldoub)

Perspective One: Tarah

(Tarah Wheeler, principal security researcher at Red Queen Technologies, New America Cybersecurity Policy Fellow, author Women In Tech. Find her at @tarah on Twitter.)

1) Hi, Tarah! Why don’t we start off with you telling us a little about your background, and your expertise with PKI.

My tech journey started in academia, where I spent my time writing math in Java. As I transitioned more and more to tech, I ended up as the de facto PKI manager for several projects. I handled certificate management while I was at Microsoft Game Studios working on Lips for Xbox and Halo for Xbox, and debugged the cert management process internally for two teams I worked on. On my own projects and for two startups, I used a 2009 Thawte initiative that provided certificates free to open source projects, and then rolled my own local CA out of that experience. I managed certs from Entrust for one startup. I handled part of certificate management at Silent Circle, the company founded by Phil Zimmermann and Jon Callas, the creators of PGP. I was Principal Security Advocate at Symantec, and Senior Director of Engineering in Website Security—the certificate authority that owns familiar words like VeriSign, Thawte, GeoTrust, and others. I was one of the Symantec representatives to the CA/B (Certification Authority/Browser) Forum, the international body that hosts fora on standards for  certificates, adjudicates reliability/trustworthiness of certificate authorities, and provides a discussion ground for the appropriate issuance and implementation of certificates in browsers. Now, I use LetsEncrypt and Comodo certs for two WordPress servers. I have a varied and colorful, and fortunately broad experience with cert management, and it helped me get a perspective on the field and on good vs. bad policy.

2) Would you please give your best, “500 words or less” explanation of what PKIs are and what they’re used for today (assume an audience with solid IT fundamentals)?

PKI or public key infrastructure is about how two entities learn to trust each other in order to exchange messages securely. You may already know that Kerberos and the KDC (Key Distribution Center) work on a shared-secrets principle, where users can go to a central authority and get authorization to communicate and act in a given network. PKI is a more complex system that understands lots of different networks which may or may not share a common trust authority. In PKI, you’re negotiating trust with a root which then tells you all the other entities that you can trust by default. The central idea of public key infrastructure is that some keys you already trust can delegate their trust (and hence yours) to other keys you don’t yet know. Think of it as a very warm introduction by a friend to someone you don’t yet know!

There are five parts of certificate or web PKI.

1. Certificate authorities, the granting bodies for public/private keys, are in practice a form of verification to grease those wheels when there’s no other method of demonstrating that you are who you say you are…a function of identity. Yeah, I know I said that two entities can trust each other without a common authority, but humans aren’t good at that kind of trust without someone vouching for them. So, we have CAs.
2. Registration authorities have what is essentially a license to issue certificates based on being trusted by the CA, and dependent upon their ability to validate organizational identity in a trustworthy way. Certificate authorities may perform their own registration, or they might outsource it. CAs issue certificates, and RAs verify the information provided in those certificates.
3. Certificate databases store requests for certificates as opposed to the certificates themselves.
4. Certificate stores hold the actual certificates. I wasn’t in charge of naming these bloody things or I’d have switched this one with certificate databases because it’s not intuitive.
5. Key archival servers are a possible backup to the certificate database in case of some kind of disaster. This is optional and not used by all CAs.

Keys work like this: a pair of keys is generated from some kind of cryptographic algorithm. One common algorithm is the RSA (Rivest-Shamir-Adleman) algorithm, and ECDSA (Elliptic Curve Digital Signature Algorithm) is coming into more common use. Think of those as wildly complicated algebraic equations that spit out an ‘x’ string and a ‘y’ string at the end that are interrelated. You can give the ‘x’ to anyone anywhere, and they can encrypt any message, ‘m’ with that x. Now, while they know the original message, only you can unencrypt the message using your ‘y’ key. That’s why you can send the ‘x’ key to anyone who wants to talk to you, but you should protect the secrecy of your ‘y’ key with your teeth and nails.

The two major uses for PKI are for email and web traffic. On a very high level, remember that traffic over the Internet is just a series of packets—little chunks of bits and bytes. While we think of email messages and web requests as philosophically distinct, at the heart, they’re just packets with different port addresses. We define the difference between messages and web requests arbitrarily, but the bits and bytes are transmitted in an identical fashion. So, encrypting those packets is conceptually the same in PKI as well.

If you want to secure email back and forth between two people, the two most common forms of PKI are PGP (Pretty Good Privacy) and S/MIME (Secure/Multipurpose Internet Mail Extensions). PGP is the first commonly used form of email encryption. Created by Phil Zimmermann and Jon Callas in the early 1990s, PGP is notoriously both secure and difficult to configure for actual human usage, but remains the standard for hyper-secure communication such as with journalists or in government usage. S/MIME is the outsourced version of PKI that your email provider almost certainly uses (once they’ve machine-read your email for whatever commercial/advertising purposes they have) to transmit your email to another person over open Internet traffic. While S/MIME is something most users don’t have to think about, you’ll want to think about whether you trust both your email provider and the provider of the person you’re sending your email to.

The other major use for PKI is a web server authenticating and encrypting communications back and forth between a client—an SSL/TLS certificate that’s installed and working when you see “https” instead of “http” at the beginning of a URL. Most of the time, when we’re talking about PKI in a policy sense or in industry, this is what we mean. Certificate authorities such as DigiCert, Comodo, LetsEncrypt, and others will create those paired keys for websites to use to both verify that they are who they say they are, and to encrypt traffic between a client who’s then been assured that they’re talking to the correct web server and not a visually similar fake site created by an attacker.

This is the major way that we who create the Internet protect people’s personal information in transit from a client to a server.

Quick tangent: I’m casually using the terms “identification” and “authentication,” and to make sure we’re on the same page: identification is making sure someone is who they say they are. Authentication is making sure they’re allowed to do what they say they’re allowed to do. If I’m a night-time security guard, I can demand ID and verify the identity of anybody with their driver’s license, but that doesn’t tell me if they’re allowed to be in the building they’re in. The most famous example in literature of authentication without identification is the carte blanche letter Cardinal de Richelieu wrote for Madame de Winter in “The Three Musketeers,” saying that “By My Hand, and for the good of the State, the bearer has done what has been done.” Notably, D’Artagnan got away with literal murder by being authenticated without proof of identification when he presented this letter to Louis XIII at the end of the novel. Also: yes, this is a spoiler, but Alexandre Dumas wrote it in 1844. You’ve had 174 years to read it, so I’m calling it fair game.

There are a few other uses for PKI, including encrypting documents in XML and some Internet Of Things applications (but far, far fewer IoT products are using PKI well than should be, if I can mount my saponified standing cube for a brief moment).

Why do we use PKI and why do information security experts continue to push people and businesses to use encryption everywhere? It’s because encryption is the key (pun absolutely intended) to increasing the expense in terms of time for people who have no business watching your traffic to watch your traffic. Simple tools like Wireshark can sniff and read your mail and web traffic in open wireless access points without it.

3) What are a couple really critical concepts we as infosec people should understand with regards to how a modern PKI functions?

The difference between identity and security/encryption. We as security people understand the difference, but most of the time, the way we explain it to people is to say “are you at PayPal? See the big green bar? That’s how you know you’re at PayPal” as opposed to “whatever the site is that you’re at, your comms are encrypted on the way to them and back.

There’s a bit of a polite war on between people who think that CAs should help to verify identity and those who think it is solely a function of encryption/security. Extended validation (“EV certs”) certificates show up as those green bars in many desktop browsers, and are often used to show that a company is who they say they are, not just whether your traffic back and forth is safe.

Whether they *should* be used to identify websites and companies is a topic still up for debate and there are excellent arguments on both sides. An extended validation certificate can prove there’s a real company registered with the correct company name to own that site, but in rare cases, it may still not be the company you’re looking for. However, in practice and especially for nontechnical people, identifying the site is still a step up from being phished and is often the shortcut explanation we give our families at holidays when asked how to avoid bad links and giving out credit card info to the wrong site.

4) What would you tell somebody in infosec who’s struggling to conceptualize how PKI works? (For example, does everybody in the field really need to “get it”? Why or why not? What other things could they study up on to grasp it better?)

PKI has become an appliance with service providers and a functional oligopoly of certificate authorities that play well with the major browsers. That isn’t necessarily a bad thing; it’s simply how this technology evolved into its current form of staid usefulness and occasional security hiccups. In reality, most people would do better knowing how best to implement PKI, since vulnerabilities are in general about the endpoints of encryption, not in the encryption itself. For instance: don’t leave 777 perms on the directory with your private keys. If your security is compromised, it’s likely not because someone cracked your key encryption—they just snagged the files from a directory they shouldn’t have been allowed in. Most PKI security issues are actually sysadmin issues. A new 384-bit ECDSA key isn’t going to be cracked by the NSA brute forcing it. It’ll be stolen from a thumb drive at a coffee shop. PKI security is the same as all other kinds of security; if you don’t track your assets and keep them updated, you’ve got Schroedinger’s Vulnerability on your hands.

PKI isn’t the lowest-hanging fruit on the security tree, but having gaping network/system security holes is like leaving a convenient orchard ladder lying about.

5) What about somebody who has a solid grasp on the basics and wants to delve deeper? (Any self-study suggestions? Are there any open source projects that could benefit from their help?)

Roll your own certs and create your own CA. Do it for the practice. I was on Ubuntu years ago when I was rolling my own, and I used the excellent help docs. One best security practice is to regularly generate and use new keys, instead of keeping the same key for years and years, for the same reasons that changing your password regularly for high-security sites is a good idea—and that’s true whether you’re creating your own certs and local CA or if you’re simply purchasing a certificate from a CA. As with so much else, rolling your own crypto means that YMMV, so if you’re thinking of doing so formally and for a company or project that holds critical or personal information, get a pro to assess it. Think of this like a hobbyist building cars or airplanes at home. Most may be fine with riding in their own homebrewed contraptions, but wouldn’t put a child in it. If you don’t have the time to be a PKI professional, don’t keep other people’s data safe with your home-brewed certificate authority.

Most of the time, security issues aren’t with the encryption itself, but with how it’s been implemented and what happens on the endpoints—not with the math, but with the people. Focus on keeping your keys safe, your networks segmented, and your passwords unique, and you’ll be ok!

*I would like to thank Ryan Sleevi for feedback, and especially for providing the Kerberos/PKI analogy for comparison. All errors are mine.

Perspective Two: Mohammed

1) Thank you sharing your knowledge! When you reached out to me, you noted you had quite a unique perspective on PKI. Would you mind telling us a little about your background, and your expertise on the subject?

In my first information security job in the government of Kuwait, we had the opportunity to work on the country’s national PKI and Authentication project in its infancy, basically from the start, and together in a small team (5 at the time) we set out on a journey of ultra-accelerated and solid education, training and development for the country’s custom in-house solutions. Deciding that development of internal capability is far more useful, compliant with national security, and of course more fun, we began to develop our own tools and libraries for PKI, authentication, smartcards, and related technology. We produced our first version deployed to the public in 2010, much sooner than most (if not all) countries in the region, so it was for us a “throw them in the sea to learn swimming” type of experience. Developing certificate pinning in 2010 in C++ is not fun, but if there is one thing I learned, it’s this: chase the cutting edge, challenge yourself, and don’t belittle yourself or your background.

2) Would you please give your best, “500 words or less” explanation of what PKIs are and what they’re used for today (assume an audience with solid IT fundamentals)?

PKI (Public Key Infrastructure – ignore the name, it’s counterintuitive) is basically the set of technologies and standards/procedures that help you manage and utilize real-world cryptography.

PKI basically is a (major) field of applied cryptography.

If you ever took a cryptography course, while not being a total math nerd, and found out there’s lots of theory and math gibberish, then I can totally understand and sympathize. I personally believe math is one of the worst ways to get introduced to cryptography (just like grammar is a really bad way to start learning a new language). Cryptography should first be taught in an applied crypto fashion, then as one understands the main concepts and fundamentals, math can be slowly introduced when needed (You probably don’t need to understand Chinese Remainder Theorem to be able to use RSA!).

Ever visited an HTTPS website and wondered how you connected securely without having any shared keys to that website? That’s because of PKI.

Without asymmetric encryption, it would be impossible to create global-scale encrypted communication standards like SSL without presharing your keys with everyone in the world, and without PKI, managing global-scale asymmetric encryption deployments would be impossible at both the technical and management level.

So where is PKI in our world? Everywhere!

If you connected to HTTPS websites: PKI

Used Windows Update: PKI

Ran an application from a verified publisher: PKI

Email security? PKI

Connected through RDP or SSH? PKI

PKI encompasses technologies related to digital certificates, keys, encryption, signing, verification and procedures related to enrollment, registration, validation and other requirements that these technologies depend on.

Think of Let’s Encrypt. It’s now a Certificate Authority (entity that gives you certificates to put on your site and enable https/ssl/tls). To give you a certificate, they have certain procedures to check your identity and right to have a certificate issued to your domain name. This way anybody in the world can securely connect to your website without having to trust you personally through this delegated chain of trust.

For Let’s Encrypt to be trusted globally, proper application of PKI must be done, and must be verified by 3rd parties. If this trust is violated or abused through improper practices, compromise or negligence, you lose total or partial trust globally. DigitNotar went out of business after state actors compromised its CA and issued fake certificates to global websites, allowing them to have semi-automatic exploitation of wide scale communications. Symantec used improper certificate issuance practices and is now scheduled for full distrust in browser on September 2018 (They have already sold their PKI business to DigiCert).

The same idea applies to almost every popular software we run: It’s signed by trusted publishers to verify ownership. Software updates are, too.

Without PKI, you can’t boot your device with even a hint of security.

Fun exercise: Go check your device’s list of trusted Root Certificate authorities (Root CA: All powerful entities having -at least theoretical- power to compromise most of your communications and systems if their power is abused and targeted against you). You’d be surprised to find entries for so many foreign government CAs (sometimes even China) already trusted by your device!

3) What are a couple really critical concepts we as infosec people should understand with regards to how a modern PKI functions?

There are many concepts to understand in PKI, but I’ll list the ones I think are most important based on the mistakes I’ve seen in the wild:

– Learn the importance of securing and non-sharing of private keys (real world blunders: Superfish adware, VMWare VDP and Rapid7 Nexpose appliances ) https://blog.rapid7.com/2017/05/17/rapid7-nexpose-virtual-appliance-duplicate-ssh-host-key-cve-2017-5242/

– Know the secure and insecure protocol/algorithm configurations (real world blunders: Rapid7 CVE-2017-5243 SSH weak configs, Flame malware, FREAK vulnerability (using weak RSA_EXPORT configs) – Even NSA.GOV website was vulnerable! https://blog.cryptographyengineering.com/2015/03/03/attack-of-week-freak-or-factoring-nsa

– Don’t charge the bull; dance around it. Most PKI implementations can be attacked/bypassed not by trying to break the math involved but by abusing wrongly put trust, wide-open policies, bad management and wrong assumptions. Real world blunder: GoDaddy issued wrong certificates because they implemented a bad challenge-response method that was bypassed by 404 pages that reflected the requsted URL – so GoDaddy tool thought the server error was a valid response to their random code challenge: https://www.infoworld.com/article/3157535/security/godaddy-revokes-nearly-9000-ssl-certificates-issued-without-proper-validation.html

4) What would you tell somebody in infosec who’s struggling to conceptualize how PKI works? (For example, does everybody in the field really need to “get it”? Why or why not? What other things could they study up on to grasp it better?)

Learn it in an applied fashion. No math. Take a look at your own setup. Check out the Digital Signature tab in any signed EXE that you have on your system. Open wireshark and checkout the SSL handshake, or wait till an OCSP request/response is made and check how it looks in wireshark. Get familiar a bit with PKI tools such as openssl.
Or write a small program that connects over SSL to some SSL port, then write a small program that listens on an SSL interface. Use ready-made libraries at first.

5) What about somebody who has a solid grasp on the basics and wants to delve deeper? (Any self-study suggestions? Are there any open source projects that could benefit from their help?)

Check out the following topics/ideas:

– Certificate Transparency.

– OCSP stapling.

– Code signing.

– Checkout The Update Framework (https://theupdateframework.github.io/ ), to learn how to implement secure software updates.

– Implementing client certificates for server-to-server communications.

– Hardware security modules (HSMs). YubiHSM is an affordable such piece of hardware.

I believe understanding PKI is growing more important as we start automating more and more of our tools and workflows, and that using tools (such as certbot) is not a valid excuse to not learn the fundamentals.

Frida (Dawn Isabel and Jahmel [Jay] Harris)

Perspective One: Dawn

Perspective Two: Jay

1) Hi Jay! Thanks for taking the time to chat with us. Would you please tell us a little about yourself, and your expertise with Frida?

My name is Jahmel Harris but some people know me as Jay. I’m a freelance pentester in the UK (digitalinterruption.com) and run Manchester Grey Hats (https://twitter.com/mcrgreyhats) – a group where we put on free workshops, ctfs etc to help teach practical cyber security skills to our members. We live stream so no need to be in the UK to attend! Also, feel free to join our Slack (invite link on Twitter).

I started using Frida when performing mobile application testing and found it worked much better than Xposed which I was using at the time. Although XPosed and Frida allows us to do similar things, Frida allows us to do it in a faster and more iterative way. A simple task could take several hours in Xposed can be done in minutes in Frida. More recently, i’ve been using Frida in bug bounties as many mobile apps go unlooked at due to some (fairly easy to bypass) client side security controls.

2) Assume we work in infosec but have never used Frida. How would you briefly explain the framework to us? Why is it useful for security professionals? (Assume an audience with solid IT fundamentals)

Frida allows us to inject JavaScript into a running application. Why is this useful? Well, it means we have the ability to change the behaviour of applications at runtime. By changing the behaviour of the application, we can add logging which can help us understand the flow, remove security controls or even dump secrets and keys. I find frida helps take testing one step further, especially where mobile apps are concerned. We can test assumptions easier, and change parts of the code without changing the signature. The other advantage is that as it becomes more difficult to jailbreak some devices, Frida can still allow us to perform a thorough test.

3) What are a couple important things to know about Frida before we start using it?

Frida is a great framework but there are some things I remind people:

1. It is not very mature so you *will* discover bugs. Ole André V. Ravnås (the creator of Frida) is very friendly though and helps where he can so don’t be afraid to reach out to him.
2. It’s not only for mobile application testing. For some reason I tend to only see Frida being used for Android and iOS application testing. It supports Windows and Linux so can be used for instrumenting Desktop applications too!
3. Frida is bundled with a few tools such as frida-trace. This is where I start when trying to RE an application. Frida-trace will log functions that are called as well as generate the JavaScript handlers. This makes it super easy to start guessing interesting function names and tracing on them. As an example, if we’re looking at an IRC client, we can put traces on *send* or *irc* and we’re likely to get something interesting. Using Frida it’s then easy to start changing parameters to these functions or even change the behaviour of them *all at runtime without restarting the application!*

4) What would you tell somebody in infosec who’s having trouble using Frida? (For example, what niches in security really need to “get it”? What other things could they study up on first to grasp it better?)

Frida can really help mobile application testers go beyond the basics of app tests. Frida is also invaluable as it allows us perform a lot of useful tests from non rooted and non jailbroken devices which is something we struggle with with each new release of iOS. It’s important to understand though that Frida isn’t an exploitation framework. We still need to know what we’re looking for in an application or the controls we’re trying to disable. As an example, when doing a mobile application test, I might discover the application uses Certificate Pinning. To bypass this using Frida I will need to reverse the application, figure out the Certificate Pinning logic before writing a Frida hook to bypass it which of course requires some basic coding knowledge.

5) What about somebody who has a solid grasp on the basics and wants to delve deeper? (Any self-study suggestions? Are there any open source projects that could benefit from their help?)

As Frida is a framework and not an application per se, anyone using Frida that wants to help should work on more high level tooling using Frida. For example, more general purpose Certificate Pinning bypassing tools or fuzzing tools. The code for Frida is very well written so it’s easy to understand how Frida works and to contribute with bug fixes. As you find bugs or missing functionality in Frida, raise bug reports as it’s likely the same issue will be faced by many people.