Duqu - Stuxnet sibling

[shep]

The implications were alarming. Certificate authorities are at the core of the trust relationship that makes the internet function. Attacking such an authority would allow the attackers to issue themselves legitimate certificates in the name of any company and use it to sign malware.

One particularly interesting part was the component the attackers used to download additional payload modules to a victim’s machine to siphon data. Unlike every other Duqu and Stuxnet module, this one was written not in C or C++ but in a language Gostev and Raiu had never seen before. They tried for weeks to identify it and even consulted experts on programming languages, but still couldn’t figure it out. So they put out a call for help on their blog and were finally able to conclude, piecing bits of clues together, that the attackers had employed a rarely used custom dialect of C, along with special extensions to contort the code and make it small and portable. It was a programming style common to commercial software programs produced a decade ago, but not to modern-day programs, and certainly not to malware. It was clear these weren’t hot-shot coders using the latest techniques, but old-school programmers who were cautious and conservative.

The complete article here.

[jjstorm]

https needs to be redesigned so it's not vulnerable to "man in the middle attacks". Couldn't certificates be replaced with public key cryptography?

[jggimi]

X.509 certificates already use public key cryptography.

As I see it, the issue with certificates is not the cryptographic primitives they use -- instead problem is browser reliance on specific CAs and their chains of trust.

[jjstorm]

Originally Posted by jggimi

X.509 certificates already use public key cryptography.

As I see it, the issue with certificates is not the cryptographic primitives they use -- instead problem is browser reliance on specific CAs and their chains of trust.

So what could be the solution to the problem as these attacks are becoming more wide spread? I heard that there are companies that specialize in setting up MIM attacks.The way the MIM attack server works, is, it intercepts your request for https, it submits your request for you, gets your certificate, and then passes on the information to you, and your browser can't tell the difference.

[jggimi]

I'll try to explain why I believe the problem is the use of certification chains (chains of trust), and why that trust breaks down, with the cryptography being moot.

---

1. Pre-Shared Keys

Alice and Bob exchange messages, using keys they have shared previously, in a secure manner. They must trust each other. Each relies on the other to keep both the unencrypted messages (the plaintext) and the keys secure. That is, Alice must trust Bob not to publish, expose, nor permit the theft of any part of the plaintext or the keys. And Bob must trust Alice to do the same.

2. Public keys

Alice and Bob each create key pairs. A key pair contains two components: a public key and a private key. Bob and Alice can exchange their public keys without having to do so securely. They must still trust one another not to disclose, expose, or publish any portion of their private half of their key pairs, or of any plaintext. The trust is still two party as with pre-shared keys.

3. Certificates

A certificate is a key management tool, which adds lifespans, revocations, and the ability to add third parties to the trust mechanism.

3a. Self-signed certificates

Very similar to using public/private key pairs, as in 2. above. Alice and Bob must still trust each other. Bob can revoke a previous certificate he used with Alice, effectively terminating its lifespan early. He may do so if the private key were exposed, for example.

3b. Certificate Authorities

Alice and Bob can use a third party to manage their certificates, and authenticate that the CA issued them to Alice and to Bob. Alice and Bob must still trust each to keep their private keys and plaintext secure. And, Alice and Bob must now trust the CA they have engaged to do the same.

3c. CAs and chains of trust

CAs can be trusted by other CAs. Alice may engage Charlie and Bob may engage Eve to act as their certification authorities. Do Charlie and Eve trust each other? Maybe. But their connection may be indirect. Between Charlie and Eve there may be additional CAs Frank and George. Alice and Bob must now trust each other, and Charlie, Eve, Frank, George.

3d. Browsers and host certificates

The HTTPS protocol requires that the web server authenticate via certificate. The clients - browsers - can also authenticate with certificates but this is optional. (Most public-facing web applications do not use client certificates, requiring passwords or other forms of authentication when needed.) Certificates can be self-signed or can use CAs.

Browser developers provide a pre-set collection of certificates. These are certificates from CAs the browser developers happen to trust. Continuing our example, if the browser developer added Charlie to the list of valid certificates, any certificate issued by Charlie or issued by a CA Charlie trusts, or by a CA trusted by a CA Charlie trusts, or by a CA trusted by a CA trusted by a CA Charlie trusts....(ad infinitum) will be trusted by the browser.

----

And it's these long chains of trust which I believe are the problem.

CAs have been compromised. Not only private keys, but certificate production capabilities have been stolen, which permit bad actors to create what appear to be trusted certificates. Certificate revocations and CA revocations are always after-the-fact; because they only occur once these breaches (of trust!) come to light.

[jggimi]

Now, let's look at one form of MITM usage, "SSL Interception," commonly used with web proxies. To do this, we turn our attention again to Alice and Bob. Here's one common way this is done.

Alice wants to use Bob's web server. Alice is employed by Eve, who permits access to the Internet only through Eve's HTTP/HTTPS proxy server. Eve has provided Alice with a certificate for Eve's local CA, which is installed in Alice's browser. All workstations at Eve's company use the proxy and have this local certificate installed.

Eve's proxy server intercepts all URLs on behalf of Alice's workstation. For HTTPS connections, the proxy server generates certificates on-the-fly , which Alice's browser will trust ... because the local CA is trusted by Alice's browser. Bob's host certificate is provided to Eve's proxy, but never reaches Alice. Alice receives Eve's certificate, which she is forced to trust.

If Eve is using OpenBSD, Eve's proxy server can be relayd(8). SSL Interception was added at the end of 2012. The developer, reyk@, discusses it in this blog post.

[jjstorm]

Originally Posted by jggimi

Now, let's look at one form of MITM usage, "SSL Interception," commonly used with web proxies. To do this, we turn our attention again to Alice and Bob. Here's one common way this is done.

Alice wants to use Bob's web server. Alice is employed by Eve, who permits access to the Internet only through Eve's HTTP/HTTPS proxy server. Eve has provided Alice with a certificate for Eve's local CA, which is installed in Alice's browser. All workstations at Eve's company use the proxy and have this local certificate installed.

Eve's proxy server intercepts all URLs on behalf of Alice's workstation. For HTTPS connections, the proxy server generates certificates on-the-fly , which Alice's browser will trust ... because the local CA is trusted by Alice's browser. Bob's host certificate is provided to Eve's proxy, but never reaches Alice. Alice receives Eve's certificate, which she is forced to trust.

If Eve is using OpenBSD, Eve's proxy server can be relayd(8). SSL Interception was added at the end of 2012. The developer, reyk@, discusses it in this blog post.

excellent explanation. Thank-you!

[jggimi]

I was in error on the date -- the SSL inspection/interception feature was announced in January of 2013, but not committed until May. It was first included in OpenBSD 5.5.

[jggimi]

Here's an interesting paper, Security Collapse in the HTTPS Market: Assessing legal and technical solutions to secure HTTPS, published by the ACM.

...HTTPS, in short, is an absolutely critical but fundamentally flawed cybersecurity technology.

While the Heartbleed incident illuminated severe flaws in a widely used crypto-library of HTTPS (OpenSSL), the focus here is on the systemic security vulnerabilities in the HTTPS authentication model that precedes end-to-end encryption. Although some of these vulnerabilities have been known for years, the 2011 security breach at the small Dutch CA (certificate authority) known as DigiNotar was a watershed moment, demonstrating these theoretical man-in-the-middle vulnerabilities in the wild. Meanwhile, large CAs such as Comodo and Verisign have experienced breaches as well but didn't suffer similar consequences to DigiNotar. In fact, some large CAs actually benefited from the increased sense of HTTPS insecurity.

There's a discussion of the paper and its conclusions on Bruce Schneier's blog.